[nsp] PA-MC-2T3+ reporting traffic way too high

[Jeff Chan]

Update: our TAC rep says the snmp counter bug has been fixed
and is undergoing regression testing.  He says "any upcoming
12.2(21)S or higher will have the fix."  It should be released
in a few weeks when testing is completed.  bugID is:

  CSCeb81930

Jeff C.
__

On Thursday, October 16, 2003, 11:13:57 AM, Jeff Chan wrote:
> Good news: Cisco appears to have found a solution to the counter
> bug with MC/CT3 interfaces, and is reportedly testing it in an
> interim release now.  Apparently it will take a while for the fix
> to get integrated into public IOS versions due to regression
> testing, and 12.2S ran into some kind of compilation issue that
> may delay the fix for that train.

> That said, it's good to know they're finally doing something
> about this.

> When I get word of an available release, I'll forward it here.

> Cheers,

> Jeff C.
> __

> On Monday, July 21, 2003, 2:12:52 PM, Jared Mauch wrote:
>> On Mon, Jul 21, 2003 at 01:56:38PM -0700, Jeff Chan wrote:
>>> Hi All,
>>> A netadmin friend suggested I sign up for this list so I thought
>>> I'd see if you guys had some ideas about a possible bug we're
>>> seeing.
>>> 
>>> We recently upgraded to 12.2(14)S3 and notice that the traffic
>>> reported on a PA-MC-2T3+ in a 7513 on a VIP-2/50 is way too high:

>>         I have a bug for this.

>>         CSCeb68858

>>         I've seen it both on all types of CT3 itnerfaces, both on
>> PA-2T3+, PA-MC-2T3 series, and CT3IP50 boards.

>>         - Jared

>>> > supranet01>sh int Serial10/1/1/8:0
>>> > Serial10/1/1/8:0 is up, line protocol is up
>>> >   Hardware is cyBus 2CT3+
>>> >   Description: AA Peering Point #1
>>> >   Internet address is NN/30
>>> >   MTU 1500 bytes, BW 1536 Kbit, DLY 20000 usec,
>>> >      reliability 255/255, txload 26/255, rxload 48/255
>>> >   Encapsulation PPP, crc 16, loopback not set
>>> >   Keepalive set (10 sec)
>>> >   LCP Open
>>> >   Open: IPCP
>>> >   Last input 00:00:11, output 00:00:00, output hang never
>>> >   Last clearing of "show interface" counters 16:30:49
>>> >   Input queue: 0/75/0/11 (size/max/drops/flushes); Total output drops: 1569
>>> >   Queueing strategy: fifo
>>> >   Output queue: 0/40 (size/max)
>>> >   5 minute input rate 9545000 bits/sec, 3026 packets/sec
>>> >   5 minute output rate 12496000 bits/sec, 2970 packets/sec
>>> >      2341811 packets input, 778137258 bytes, 0 no buffer
>>> >      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>>> >      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 1 abort
>>> >      2477327 packets output, 1393787280 bytes, 0 underruns
>>> >      0 output errors, 0 collisions, 0 interface resets
>>> >      0 output buffer failures, 0 output buffers swapped out
>>> >      2 carrier transitions no alarm present
>>> >   Timeslot(s) Used: 1-24, Transmitter delay is 0 flags, transmit queue length 5
>>> >   non-inverted data
>>> 
>>> How can an interface with 1536 Kb of bandwidth report or do 9
>>> and 12 megabits of traffic?  The answer is that it can't.  :)
>>> The 5 minute average values our mrtg is picking up by snmp also
>>> got spikey after the upgrade.  The peak values may be correct
>>> but the average seems missing, filtered out, or too low.
>>> 
>>> We did turn of cef since it seemed to cause a problem, possibly
>>> with ISL.  (We plan to move to Dot1Q for trunking vlans later.)
>>> 
>>> Has anyone else seen this?
>>> 
>>> Cheers,
>>> 
>>> Jeff C.
>>> -- 
>>> Jeff Chan
>>> mailto:cisco-nsp at jeffchan.com
>>> http://www.jeffchan.com/
>>> 
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/



-- 
Jeff Chan
mailto:cisco-nsp at jeffchan.com
http://www.supranet.net/