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.