[c-nsp] Packet Loss on 6513
Mesiatowsky, Shawn
SMESIATO at petro-canada.ca
Tue Apr 7 11:53:16 EDT 2009
We currently have 2 6513's in our core, and we have seen packet loss on our network. I was trying to locate the source of the packet loss. We did see some input queue drops on the SVI's and physical interfaces. I had increased our queue size on the vlan interfaces to 500, and our packet drops on the svi's decreased signifigantly. Now I am trying to figure out why there is packet loss on the physical interfaces. We have a sup 720, and our line cards are WS-X6724-SFP and WS-X6748-SFP.
Here is a sample of an interface with high drops
GigabitEthernet2/23 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 001a.2f68.7bc2 (bia 001a.2f68.7bc2)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 38/255, rxload 32/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is SX
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:31, output hang never
Last clearing of "show interface" counters 1d00h
Input queue: 0/2000/91560/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 126671000 bits/sec, 28888 packets/sec
5 minute output rate 151605000 bits/sec, 26499 packets/sec
942611654 packets input, 633784740348 bytes, 0 no buffer
Received 7319979 broadcasts (6903850 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 91560 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
891230426 packets output, 579042873963 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
I also looked at the utilization of this interface with our snmp tool, and utilixzation of this interface never went over %40
I also noticed the following, and was not sure if this was completely accurate:
show platform hardware capacity interface
Interface Resources
Interface drops:
Module Total drops: Tx Rx Highest drop port: Tx Rx
1 0 466 0 1
2 0 154228 0 23
3 0 123 0 1
4 0 190102 0 21
5 0 446318 0 21
7 3940684041 0 1 0
9 0 34280 0 7
10 0 5 0 42
11 0 433 0 46
12 0 1686 0 44
13 66042 119859 1 1
Interface buffer sizes:
Module Bytes: Tx buffer Rx buffer
1 1221120 152000
2 1221120 152000
3 1221120 152000
4 1221120 152000
5 1221120 152000
6 1221120 152000
9 1221120 152000
10 1221120 152000
11 1221120 152000
12 1221120 152000
13 1221120 152000
Does this mean that 3940684041 packets were dropped on the egress queue on the sup? Does this seem extremly high, and shat can cause this?
Thanks for your help
________________________________
This email communication is intended as a private communication for the sole use of the primary addressee and those individuals listed for copies in the original message. The information contained in this email is private and confidential and If you are not an intended recipient you are hereby notified that copying, forwarding or other dissemination or distribution of this communication by any means is prohibited. If you are not specifically authorized to receive this email and if you believe that you received it in error please notify the original sender immediately. We honour similar requests relating to the privacy of email communications.
Cette communication par courrier ?lectronique est une communication priv?e ? l'usage exclusif du destinataire principal ainsi que des personnes dont les noms figurent en copie. Les renseignements contenus dans ce courriel sont confidentiels et si vous n'?tes pas le destinataire pr?vu, vous ?tes avis?, par les pr?sentes que toute reproduction, transfert ou autre forme de diffusion de cette communication par quelque moyen que ce soit est interdite. Si vous n'?tes pas sp?cifiquement autoris? ? recevoir ce courriel ou si vous croyez l'avoir re?u par erreur, veuillez en aviser l'exp?diteur original imm?diatement. Nous respectons les demandes similaires qui touchent la confidentialit? des communications par courrier ?lectronique.
More information about the cisco-nsp
mailing list