Subject: (usr-tc) SNMP bug?

From: [email-masked]
Date: Thu, 02 Dec 1999 04:16:00 +0000

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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 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.

---

From: [email-masked]
Date: Thu, 02 Dec 1999 05:20:08 +0000

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
[email-masked]	Onslow County's PREMIER InterNet Service 
Voice (910) 346-0835		    824 Gumbranch Square, Suite R3
FAX   (910) 455-1933		     Jacksonville, Nc  28540-6269
==============================================================================

-

---

From: Mike Andrews <[email-masked]>
Date: Thu, 02 Dec 1999 07:35:01 +0000

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) * [email-masked] * 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

-

---

From: [email-masked]
Date: Thu, 02 Dec 1999 16:19:39 +0000

Yes, I know.  But then why didn't it idle timeout?  

Paul Farber
Farber Technology
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: [email-masked]
Date: Thu, 02 Dec 1999 16:37:00 +0000

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: [email-masked]
**********************************************

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Thu, 02 Dec 1999 16:49:20 +0000

> verified my script with TCM and it also showed 0 in/out with online time

Nope Idle time will not handle this.  This is lcp echo/reply within ppp.

krish

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Thu, 02 Dec 1999 17:32:26 +0000

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 ............   \
		----------------------------------------------/
[email-masked]  
----------------------------/ http://interproc.ae.usr.com ----/
-------------------------------------------------------------------------\
	Any Sufficiently advanced bug is indistinguishable for a feature.
						- Rick Kulawiec
-------------------------------------------------------------------------/

-

---

From: [email-masked]
Date: Thu, 02 Dec 1999 17:32:26 +0000

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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: [email-masked]
Date: Thu, 02 Dec 1999 20:25:10 +0000

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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Tatai SV Krishnan <[email-masked]>
Date: Thu, 02 Dec 1999 20:34:45 +0000

> is something wrong with the link because of these lcp echo/req packets

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

-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 02 Dec 1999 20:50:36 +0000

Thus spake Tatai SV Krishnan

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Jeff Carneal <[email-masked]>
Date: Thu, 02 Dec 1999 22:15:24 +0000

> 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          
  [email-masked] 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. 

-

---

From: [email-masked]
Date: Thu, 02 Dec 1999 23:44:36 +0000

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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: [email-masked]
Date: Thu, 02 Dec 1999 23:44:55 +0000

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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 03 Dec 1999 00:04:23 +0000

Thus spake [email-masked]
>that is my question.  if LCP echo/reply is traffic, why is the bytes

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.

>would seem by your explination that no link would ever idle timeout if lcp

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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Wronski <[email-masked]>
Date: Fri, 03 Dec 1999 00:42:49 +0000

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Jeff Mcadams
|Sent: Thursday, December 02, 1999 4:01 PM
|To: [email-masked]
|Subject: Re: (usr-tc) SNMP bug?
|
|
|Thus spake [email-masked]
|>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

-

---

From: [email-masked]
Date: Thu, 02 Dec 1999 17:53:07 -0500

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
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 03 Dec 1999 04:00:05 +0000

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: [email-masked]
Date: Fri, 03 Dec 1999 17:12:08 +0000

Just providing info.  No changed were made to the arc in 6+ months.

Paul Farber
Farber Technology
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Brian <[email-masked]>
Date: Fri, 03 Dec 1999 18:25:42 +0000

You have to tell us what versions of code you are running..........

brian

> any help you can give me.

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-

---

From: [email-masked]
Date: Fri, 03 Dec 1999 18:48:58 +0000

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.

-