Hello all... I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out. Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got: Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1 Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27 Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66 Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27 meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Seems to me I remember reading something about the way the HiperArc handles bytes in /out We use TSmon and the author recommends not doing any limits for users based on bytes in/out.... Maybe Krish can enlighten us on this. I believe 3Com does it in a nON-Standard way?? ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
Hello all...
I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out.
Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got:
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+.
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Well, for what it's worth, these are LCP echoes... which works at the PPP layer, which is further down the stack than the TCP/IP layer. So from a TCP/IP perspective there really isn't any traffic if that's all you're seeing. My guess is the idle timeout is based on TCP/IP traffic (or IPX if you do that). Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925 On Wed, 1 Dec 1999 pferraro@wna-linknet.com wrote:
Seems to me I remember reading something about the way the HiperArc handles bytes in /out We use TSmon and the author recommends not doing any limits for users based on bytes in/out.... Maybe Krish can enlighten us on this. I believe 3Com does it in a nON-Standard way??
============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
Hello all...
I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out.
Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got:
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+.
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Yes, I know. But then why didn't it idle timeout? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 2 Dec 1999, Mike Andrews wrote:
Well, for what it's worth, these are LCP echoes... which works at the PPP layer, which is further down the stack than the TCP/IP layer. So from a TCP/IP perspective there really isn't any traffic if that's all you're seeing. My guess is the idle timeout is based on TCP/IP traffic (or IPX if you do that).
Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925
On Wed, 1 Dec 1999 pferraro@wna-linknet.com wrote:
Seems to me I remember reading something about the way the HiperArc handles bytes in /out We use TSmon and the author recommends not doing any limits for users based on bytes in/out.... Maybe Krish can enlighten us on this. I believe 3Com does it in a nON-Standard way??
============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
Hello all...
I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out.
Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got:
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+.
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Becasue lcp/echo/reply is actual traffic - just like ping, the session was never idle for the set time, there was always traffic thus idletime was never reached. krish ----------------------------------------- \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ -------------------------------------------------------------------------\ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec -------------------------------------------------------------------------/ On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Yes, I know. But then why didn't it idle timeout?
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
On Thu, 2 Dec 1999, Mike Andrews wrote:
Well, for what it's worth, these are LCP echoes... which works at the PPP layer, which is further down the stack than the TCP/IP layer. So from a TCP/IP perspective there really isn't any traffic if that's all you're seeing. My guess is the idle timeout is based on TCP/IP traffic (or IPX if you do that).
Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925
On Wed, 1 Dec 1999 pferraro@wna-linknet.com wrote:
Seems to me I remember reading something about the way the HiperArc handles bytes in /out We use TSmon and the author recommends not doing any limits for users based on bytes in/out.... Maybe Krish can enlighten us on this. I believe 3Com does it in a nON-Standard way??
============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
Hello all...
I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out.
Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got:
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+.
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Then either no link should ever time out due to lcp traffic or there is something wrong with the link because of these lcp echo/req packets every 10 seconds. Which is more correct? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 1 Dec 1999, Tatai SV Krishnan wrote:
Becasue lcp/echo/reply is actual traffic - just like ping, the session was never idle for the set time, there was always traffic thus idletime was never reached.
krish
----------------------------------------- \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ -------------------------------------------------------------------------\ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec -------------------------------------------------------------------------/
On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Yes, I know. But then why didn't it idle timeout?
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
On Thu, 2 Dec 1999, Mike Andrews wrote:
Well, for what it's worth, these are LCP echoes... which works at the PPP layer, which is further down the stack than the TCP/IP layer. So from a TCP/IP perspective there really isn't any traffic if that's all you're seeing. My guess is the idle timeout is based on TCP/IP traffic (or IPX if you do that).
Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925
On Wed, 1 Dec 1999 pferraro@wna-linknet.com wrote:
Seems to me I remember reading something about the way the HiperArc handles bytes in /out We use TSmon and the author recommends not doing any limits for users based on bytes in/out.... Maybe Krish can enlighten us on this. I believe 3Com does it in a nON-Standard way??
============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
Hello all...
I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out.
Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got:
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+.
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Then either no link should ever time out due to lcp traffic or there is something wrong with the link because of these lcp echo/req packets every 10 seconds.
Which is more correct?
I did not understand your question. Idle time out basically means if the line is idle for a set number of seconds/min then disconnect the same. lcp echo is a normal lcp type ping if you will that is done by certain clients. If this happens it means that there is traffic on the wire so the line is not idle. So do not disconnect the same. krish
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
On Wed, 1 Dec 1999, Tatai SV Krishnan wrote:
Becasue lcp/echo/reply is actual traffic - just like ping, the session was never idle for the set time, there was always traffic thus idletime was never reached.
krish
----------------------------------------- \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ -------------------------------------------------------------------------\ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec -------------------------------------------------------------------------/
On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Yes, I know. But then why didn't it idle timeout?
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
On Thu, 2 Dec 1999, Mike Andrews wrote:
Well, for what it's worth, these are LCP echoes... which works at the PPP layer, which is further down the stack than the TCP/IP layer. So from a TCP/IP perspective there really isn't any traffic if that's all you're seeing. My guess is the idle timeout is based on TCP/IP traffic (or IPX if you do that).
Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925
On Wed, 1 Dec 1999 pferraro@wna-linknet.com wrote:
Seems to me I remember reading something about the way the HiperArc handles bytes in /out We use TSmon and the author recommends not doing any limits for users based on bytes in/out.... Maybe Krish can enlighten us on this. I believe 3Com does it in a nON-Standard way??
============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
Hello all...
I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out.
Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got:
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+.
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Thus spake Tatai SV Krishnan
On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Then either no link should ever time out due to lcp traffic or there is something wrong with the link because of these lcp echo/req packets every 10 seconds.
Which is more correct?
I did not understand your question. Idle time out basically means if the line is idle for a set number of seconds/min then disconnect the same. lcp echo is a normal lcp type ping if you will that is done by certain clients. If this happens it means that there is traffic on the wire so the line is not idle. So do not disconnect the same.
Hrmm...kinda violates the concept of least surprise there. :/ Anyway...this would be reason enough to renew my age-old call for the ability to specify what traffic is to reset the idle time. (Useful also for those of us that would like to prevent someone from setting their POP mail reader to check mail every 2 minutes to defeat idle timeouts). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Thu, 2 Dec 1999, Jeff Mcadams wrote:
Hrmm...kinda violates the concept of least surprise there. :/
Anyway...this would be reason enough to renew my age-old call for the ability to specify what traffic is to reset the idle time. (Useful also for those of us that would like to prevent someone from setting their POP mail reader to check mail every 2 minutes to defeat idle timeouts).
Ciscos do this and have for a while. You could always get some of those :) -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (270) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
I have a php3 that is going to do just that.... but first I need to make sure that the snmp values gotten from the NMC card are at least somewhat accurate. I have a person online for 1+ hr with 0 in/out, also I get the occasional user with 1K or so out, but 0 in. It may be a good thing to disconnect these people if by these indications the link is just not performing correctly. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 2 Dec 1999, Jeff Mcadams wrote:
Thus spake Tatai SV Krishnan
On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Then either no link should ever time out due to lcp traffic or there is something wrong with the link because of these lcp echo/req packets every 10 seconds.
Which is more correct?
I did not understand your question. Idle time out basically means if the line is idle for a set number of seconds/min then disconnect the same. lcp echo is a normal lcp type ping if you will that is done by certain clients. If this happens it means that there is traffic on the wire so the line is not idle. So do not disconnect the same.
Hrmm...kinda violates the concept of least surprise there. :/
Anyway...this would be reason enough to renew my age-old call for the ability to specify what traffic is to reset the idle time. (Useful also for those of us that would like to prevent someone from setting their POP mail reader to check mail every 2 minutes to defeat idle timeouts). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
that is my question. if LCP echo/reply is traffic, why is the bytes in/out staying at 0? Also, what is the normal lcp echo/reply timing? once every second? it would seem by your explination that no link would ever idle timeout if lcp echo's are being sent. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 2 Dec 1999, Tatai SV Krishnan wrote:
On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Then either no link should ever time out due to lcp traffic or there is something wrong with the link because of these lcp echo/req packets every 10 seconds.
Which is more correct?
I did not understand your question. Idle time out basically means if the line is idle for a set number of seconds/min then disconnect the same. lcp echo is a normal lcp type ping if you will that is done by certain clients. If this happens it means that there is traffic on the wire so the line is not idle. So do not disconnect the same.
krish
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
On Wed, 1 Dec 1999, Tatai SV Krishnan wrote:
Becasue lcp/echo/reply is actual traffic - just like ping, the session was never idle for the set time, there was always traffic thus idletime was never reached.
krish
----------------------------------------- \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ -------------------------------------------------------------------------\ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec -------------------------------------------------------------------------/
On Thu, 2 Dec 1999 farber@admin.f-tech.net wrote:
Yes, I know. But then why didn't it idle timeout?
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
On Thu, 2 Dec 1999, Mike Andrews wrote:
Well, for what it's worth, these are LCP echoes... which works at the PPP layer, which is further down the stack than the TCP/IP layer. So from a TCP/IP perspective there really isn't any traffic if that's all you're seeing. My guess is the idle timeout is based on TCP/IP traffic (or IPX if you do that).
Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925
On Wed, 1 Dec 1999 pferraro@wna-linknet.com wrote:
Seems to me I remember reading something about the way the HiperArc handles bytes in /out We use TSmon and the author recommends not doing any limits for users based on bytes in/out.... Maybe Krish can enlighten us on this. I believe 3Com does it in a nON-Standard way??
============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================
On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
> Hello all... > > I have a neat-o little php3 script that shows me users, time on line, > speed, and bytes in/out. > > Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon > PPP on the modem and got: > > Incoming PPP Data on interface: slot:3/mod:2 > LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1 > > Outgoing PPP Data on interface: slot:3/mod:2 > LCP ECHO_RPLY 81 e7 42 27 > > Incoming PPP Data on interface: slot:3/mod:2 > LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66 > > Outgoing PPP Data on interface: slot:3/mod:2 > LCP ECHO_RPLY 81 e7 42 27 > > meaning that they *are* there. Wouldn't the idle timeout handle this? I > verified my script with TCM and it also showed 0 in/out with online time > of 1hr+. > > > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Thus spake farber@admin.f-tech.net
that is my question. if LCP echo/reply is traffic, why is the bytes in/out staying at 0?
Because the bytes in/out is almost assuredly reporting network level traffic...which LCP isn't...LCP is a lower level...the idle timer seems to be functioning at the PPP level (and this tracks with what I've been told in the past) while the byte counters are functioning at the IP (IPX, appletalk, etc.) level....so the LCP echo req's and responses are resetting the idle timer, but not tripping the byte counters.
Also, what is the normal lcp echo/reply timing? once every second? it would seem by your explination that no link would ever idle timeout if lcp echo's are being sent.
There is no "normal" timing...its implementation specific as to how often it wants to send out echo reqs...and a requirement of PPP to respond to echo requests whenever they're received (I'm pretty sure I have this all right). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Thursday, December 02, 1999 4:01 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) SNMP bug? | | |Thus spake farber@admin.f-tech.net |>that is my question. if LCP echo/reply is traffic, why is the bytes |>in/out staying at 0? | |Because the bytes in/out is almost assuredly reporting network level |traffic...which LCP isn't...LCP is a lower level...the idle timer seems |to be functioning at the PPP level (and this tracks with what I've been |told in the past) while the byte counters are functioning at the IP |(IPX, appletalk, etc.) level....so the LCP echo req's and responses are |resetting the idle timer, but not tripping the byte counters. This is correct.. If the LCP echo is reseting the idle timer, that is a bug. LCP like routing prots, should not be reseting the idle timer. I will look into this. -M - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
FYI my code levels are: DSP 2.0.60 ARC 4.1.59-6 NMC 5.6.2 I just flashed all cards up to 2.0.60 from 2.0.81 and from what little I remember it's only started recently (with the upgrade).... not sure but that's the last thing I did. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 2 Dec 1999, Mike Wronski wrote:
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Thursday, December 02, 1999 4:01 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) SNMP bug? | | |Thus spake farber@admin.f-tech.net |>that is my question. if LCP echo/reply is traffic, why is the bytes |>in/out staying at 0? | |Because the bytes in/out is almost assuredly reporting network level |traffic...which LCP isn't...LCP is a lower level...the idle timer seems |to be functioning at the PPP level (and this tracks with what I've been |told in the past) while the byte counters are functioning at the IP |(IPX, appletalk, etc.) level....so the LCP echo req's and responses are |resetting the idle timer, but not tripping the byte counters.
This is correct.. If the LCP echo is reseting the idle timer, that is a bug. LCP like routing prots, should not be reseting the idle timer. I will look into this.
-M
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Thus spake farber@admin.f-tech.net
FYI my code levels are:
DSP 2.0.60 ARC 4.1.59-6 NMC 5.6.2
I just flashed all cards up to 2.0.60 from 2.0.81 and from what little I remember it's only started recently (with the upgrade).... not sure but that's the last thing I did.
I know you're just reporting what you're seeing, but I have a hard time believing the DSP code has anything to do with this. The DSP's don't really have anything to do with what type of traffic is going by them. You can do the PPP offloading which tells the DSP's to do the PPP framing, which, if I understand correctly, just means that the DSP's have enough intelligence to see the beginning and end of HDLC frames and sends the data to the Arcs in one unit rather than byte by byte. Interpretation of the traffic to determine whether its LCP, or IP, or IPCP, or whatever doesn't happen until the traffic is at the Arc...so it would almost have to be an issue with the Arc. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Just providing info. No changed were made to the arc in 6+ months. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 2 Dec 1999, Jeff Mcadams wrote:
Thus spake farber@admin.f-tech.net
FYI my code levels are:
DSP 2.0.60 ARC 4.1.59-6 NMC 5.6.2
I just flashed all cards up to 2.0.60 from 2.0.81 and from what little I remember it's only started recently (with the upgrade).... not sure but that's the last thing I did.
I know you're just reporting what you're seeing, but I have a hard time believing the DSP code has anything to do with this. The DSP's don't really have anything to do with what type of traffic is going by them. You can do the PPP offloading which tells the DSP's to do the PPP framing, which, if I understand correctly, just means that the DSP's have enough intelligence to see the beginning and end of HDLC frames and sends the data to the Arcs in one unit rather than byte by byte. Interpretation of the traffic to determine whether its LCP, or IP, or IPCP, or whatever doesn't happen until the traffic is at the Arc...so it would almost have to be an issue with the Arc. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
I have yet to see this particular problem on the list, so I'm going to throw it out there and see what swims back... For the past several months, on and off, I have been plagued by a problem where a chassis in a particular spot on my rack suddenly stops taking calls and returns a fast busy signal. I have: 1] Power cycled the chassis <--this works for about 8 hours 2] Replaced all the cards 3] Replaced the chassis 4] Swapped out the chassis with a test chassis 5] Swapped the T1s going into the DSPs 6] Removed *all* the cards except for one DSP, one ARC, one NMC, and two PSUs. 7] Tried rebooting the DSPs. Firmware is at current levels. At one point, I actually sent the whole chassis back to 3Com and received a brand new one. This morning, I took a look at the performance monitor and saw, under "Reason for Call Termination": pbReceivedLsWhileLinkUp(55) Under "Reason for Call Failure", I see: pbGenericError(46) Anyone know what the heck is going on? I'm ready to call a priest! Incidentally, is there someplace out there where I can get a "dictionary" of those reason for disconnect messages? I have tried the knowledge base and wound up going 'round in circles. Thanks for any help you can give me. ********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
pbReceivedLsWhileLinkUp(55) Link Start Received (HiperDSP) = DESCRIPTION An error accured in the packet bus physcal layer. The modem received a request to start a new link while it was in a link, This caused the current link to drop and a new link to be attempted. TROUBLE CLEARING NOTES: This is an unlikely reason. If this reason does occur with any frequency, reboot the NETserver. If it still occurs, try to isolate which NIC is having the problem. Test and replace the NIC if necessary.
From Ch24: Modem disconnect and Fail to connect Reasons. This is about a year old doc.
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 2 Dec 1999 mmm3@cornell.edu wrote:
I have yet to see this particular problem on the list, so I'm going to throw it out there and see what swims back...
For the past several months, on and off, I have been plagued by a problem where a chassis in a particular spot on my rack suddenly stops taking calls and returns a fast busy signal. I have:
1] Power cycled the chassis <--this works for about 8 hours 2] Replaced all the cards 3] Replaced the chassis 4] Swapped out the chassis with a test chassis 5] Swapped the T1s going into the DSPs 6] Removed *all* the cards except for one DSP, one ARC, one NMC, and two PSUs. 7] Tried rebooting the DSPs.
Firmware is at current levels. At one point, I actually sent the whole chassis back to 3Com and received a brand new one. This morning, I took a look at the performance monitor and saw, under "Reason for Call Termination":
pbReceivedLsWhileLinkUp(55)
Under "Reason for Call Failure", I see:
pbGenericError(46)
Anyone know what the heck is going on? I'm ready to call a priest! Incidentally, is there someplace out there where I can get a "dictionary" of those reason for disconnect messages? I have tried the knowledge base and wound up going 'round in circles. Thanks for any help you can give me. ********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
You have to tell us what versions of code you are running.......... brian On Thu, 2 Dec 1999 mmm3@cornell.edu wrote:
I have yet to see this particular problem on the list, so I'm going to throw it out there and see what swims back...
For the past several months, on and off, I have been plagued by a problem where a chassis in a particular spot on my rack suddenly stops taking calls and returns a fast busy signal. I have:
1] Power cycled the chassis <--this works for about 8 hours 2] Replaced all the cards 3] Replaced the chassis 4] Swapped out the chassis with a test chassis 5] Swapped the T1s going into the DSPs 6] Removed *all* the cards except for one DSP, one ARC, one NMC, and two PSUs. 7] Tried rebooting the DSPs.
Firmware is at current levels. At one point, I actually sent the whole chassis back to 3Com and received a brand new one. This morning, I took a look at the performance monitor and saw, under "Reason for Call Termination":
pbReceivedLsWhileLinkUp(55)
Under "Reason for Call Failure", I see:
pbGenericError(46)
Anyone know what the heck is going on? I'm ready to call a priest! Incidentally, is there someplace out there where I can get a "dictionary" of those reason for disconnect messages? I have tried the knowledge base and wound up going 'round in circles. Thanks for any help you can give me. ********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
brian said...
You have to tell us what versions of code you are running..........
Okay... NMC 6.1.17 ARC 4.1.59-6 DSPs 2.0.81 Quads 6.1.6 <--single-sided quads PRI 3.1.5 Don't think it's got anything to do with code versions, though. Been running the above versions and the same configuration on nine other chassis for months and months and nothing like this happened to the other chassis. Since I relocated the power source, I've had no reports of problems, so I'm going with that theory. Forgot my little circuit tester thingy this morning, darn it.
On Thu, 2 Dec 1999 mmm3@cornell.edu wrote:
I have yet to see this particular problem on the list, so I'm going to throw it out there and see what swims back...
For the past several months, on and off, I have been plagued by a problem where a chassis in a particular spot on my rack suddenly stops taking calls and returns a fast busy signal. I have:
1] Power cycled the chassis <--this works for about 8 hours 2] Replaced all the cards 3] Replaced the chassis 4] Swapped out the chassis with a test chassis 5] Swapped the T1s going into the DSPs 6] Removed *all* the cards except for one DSP, one ARC, one NMC, and two PSUs. 7] Tried rebooting the DSPs.
Firmware is at current levels. At one point, I actually sent the whole chassis back to 3Com and received a brand new one. This morning, I took a look at the performance monitor and saw, under "Reason for Call Termination":
pbReceivedLsWhileLinkUp(55)
Under "Reason for Call Failure", I see:
pbGenericError(46)
Anyone know what the heck is going on? I'm ready to call a priest! Incidentally, is there someplace out there where I can get a "dictionary" of those reason for disconnect messages? I have tried the knowledge base and wound up going 'round in circles. Thanks for any help you can give me.
********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Wed, 1 Dec 1999 farber@admin.f-tech.net wrote:
Hello all...
I have a neat-o little php3 script that shows me users, time on line, speed, and bytes in/out.
Several users will be on for 1hr+ but have 0 bytes in/out. I did a mon PPP on the modem and got:
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb e3 d0 95 a1
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
Incoming PPP Data on interface: slot:3/mod:2 LCP ECHO_REQ 28 0c 3e bb 0c 04 60 66
Outgoing PPP Data on interface: slot:3/mod:2 LCP ECHO_RPLY 81 e7 42 27
meaning that they *are* there. Wouldn't the idle timeout handle this? I verified my script with TCM and it also showed 0 in/out with online time of 1hr+.
Nope Idle time will not handle this. This is lcp echo/reply within ppp. krish
Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
participants (9)
-
Brian -
farber＠admin.f-tech.net -
Jeff Carneal -
Jeff Mcadams -
Mike Andrews -
Mike Wronski -
mmm3＠cornell.edu -
pferraro＠wna-linknet.com -
Tatai SV Krishnan