Re: Cat 4000 Crazy Port Statistics.




hmadra wrote:
This Problem has been giving me sleepless nights from a Month now.

There is no evedince here of a need to worry.

We have a cisco 4006. We run OSPF and BGP. There are two ports on the
switch that are connected to the Core Routers. The Stats on these ports
are crazy.
The thing here is that you have another 'opinion' on the stats.
The equipment on the other end of the links should have the
opposite readings. If they disagree then at least
one of them is wrong.

reliability 255/255, txload 251/255, rxload 3/255
Full-duplex, 100Mb/s
Last input 00:00:00, output never, output hang never
The above line often does not seem to have the correct info.

Last clearing of "show interface" counters 6w2d
Input queue: 31402/75/0/0 (size/max/drops/flushes); Total output
Input Queue is ridiculous.

drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)

5 minute input rate 1383000 bits/sec, 920 packets/sec
1,400 bit average packet size. OK.
5 minute output rate 500224000 bits/sec, 33987277 packets/sec
15 bit average packet size.
Standard says min is 512 bits.

2481037660 packets input, 454955876 bytes, 0 no buffer
Received 3267143 broadcasts, 0 runts, 0 giants, 0 throttles
2047853408 packets output, 1214833509 bytes, 0 underruns

FastEthernet2/47 is up, line protocol is up

reliability 255/255, txload 246/255, rxload 1/255

Full-duplex, 100Mb/s
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 6w2d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 96648000 bits/sec, 5310567 packets/sec
1046861 packets input, 123914863 bytes, 0 no buffer
Received 934185 broadcasts, 0 runts, 0 giants, 0 throttles
1987 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
363290167 packets output, 3566189248 bytes, 0 underruns

These are 100Mb ports. Howcan they do like 500 Mb/sec. Doesnt make
sense to me.

The Ports would be less than 100Mb at one moment and then just shoot up
to 300-400 Mb another moment with millions of packets per second.
Doesnt make sense to me. However, the MRTG never shows more than 9-10
Mb. Any Clues.

In summary as you state these counters are impossible.
The switch has a bug or bugs, most likely in the software
but I guess just possibly a hardware fault.

My first idea is to instead use the counters on the other
end of the link.

Cisco counters are usually quite reliable although I have
seen, I think, something like it before.

/Much/ worwse that the 500Mbps (i.e. x5) are the
34 Million packets per second. This is say 200 times
the max packet rate of a fast ethernet which is 144,000
packets per second.

If you have a support consider contract upgrading the software.

If you post a show ver from the switches then I will have a
look for reported bugs.

One possibility is that the counters go wrong after time.
I would try issuing a "clear counters" and see if the
numbers are sane for a while. If you have never done
that before then I suggest that you do it out of
production hours. Just in case.


Good luck.

.



Relevant Pages

  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)
  • Re: Question regarding using AES in CTR mode to encrypt UDP
    ... but in CTR mode I have a problem synchronising the counter of the CTR ... Reject old packets with a soft error ... synchronization of the CTR counters (assuming I still want to use CTR, ... and I need the exact same counters in order to reverse the encryption ...
    (sci.crypt)
  • Re: Catalyst 4000 - Ciscos Response
    ... on a variety of factors such as Switch load and traffic patterns. ... Flooding packets ... database on the switch containing switch ports and the MAC addresses sourced ... Sniffer is on a different port than the workstation and servers. ...
    (Bugtraq)