Hey: Can you get the more descriptive errors on the Catalyst side? That's where the majority of errors are. I think it will do a "show int count error" or similar.
By the way, did you see this? http://www.cisco.com/en/US/tech/tk801/tk703/technologies_tech_note09186a008 0094c4f.shtml You might want to check your assumptions about the MTU settings again. Mike On 9/29/11 10:22 AM, "Alexander Fossa" <[email protected]> wrote: >Hi Mike, > >From the NPE-G1, it doesnt accept show int xx count error.... but here is >something > >DSL1.THE#show int gi0/1 | i error > 0 input errors, 0 CRC, 0 frame, 177 overrun, 0 ignored > 0 output errors, 0 collisions, 0 interface resets > >On the NPE-G1 > >interface GigabitEthernet0/1 > description Link to BabyBoy1/1 > mtu 9216 > no ip address > duplex full > speed 1000 > media-type rj45 > no negotiation auto > no cdp enable > hold-queue 1500 in >end > >and the sub interface > >interface GigabitEthernet0/1.89 > encapsulation dot1Q 89 > ip address xxxxx > no ip redirects > no ip proxy-arp > ip mtu 1590 > ip hold-time eigrp 55 60 > ip ospf authentication-key xxxxxx > ip ospf mtu-ignore >end > >From the SUP32 > >interface GigabitEthernet1/7 > description DSL1.THE_GI0/1 > switchport > switchport trunk encapsulation dot1q > switchport trunk allowed vlan 89 > switchport mode trunk > mtu 9216 > no cdp enable > no mop enabled > no mop sysid >end > >interface Vlan89 > mtu 9216 > ip address xxxxxx > no ip redirects > no ip unreachables > ip mtu 1590 > ip hold-time eigrp 55 60 > ip summary-address eigrp 100 0.0.0.0 0.0.0.0 255 > ip ospf authentication-key xxx > ip ospf mtu-ignore > no mop enabled > no mop sysid >end > >I've got the MTU high, as we use 1500byte for the PPP + L2TP header. > >Thanks, > >Alex >________________________________________ >From: Michael K. Smith - Adhost [[email protected]] >Sent: 29 September 2011 17:55 >To: Alexander Fossa; cisco-nsp ?[[email protected]]? >Subject: RE: NPE-G1 Interface errors / packetloss > >Can you do a "sho int x/x count error"? Also, have you tried setting the >MTU to 1500 on both sides of the link? What is the MTU on the VLAN >itself and for the chassis? > >Mike >-- >Michael K. Smith - CISSP, GSEC, GISP >Chief Technical Officer - Adhost Internet LLC [email protected] >w: +1 (206) 404-9500 f: +1 (206) 404-9050 >PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > >> -----Original Message----- >> From: Alexander Fossa [mailto:[email protected]] >> Sent: Thursday, September 29, 2011 9:20 AM >> To: Michael K. Smith - Adhost; cisco-nsp ?[[email protected]]? >> Subject: RE: NPE-G1 Interface errors / packetloss >> >> Hi, >> >> It seems you cannot disable flow-control on a NPE-G1.... I'm running >>12.3.6f >> >> "My understanding is software based flow-control has been disabled on >>the >> 7200 because it was not scalable. But there is a cosmetic bug on the sh >> interface which shown input flow control as XON instead of unsupported. >> >> It has been fixed via CSCsr53390" >> >> There are two interconnects between the two chassis... >> >> GI0/1 (npe) > Gi1/7 (sup32) - copper native on npe, to brand new cisco >>1000- >> T SFP >> GI0/3 (npe) > Gi1/4 (sup32) - fibre GBIC on npe, to brand new cisco SFP >>SX >> >> The wierd thing is the CRC / Frame errors followed the VLAN when it was >> moved from the fibre to the copper. Both are direct patch cables nothing >> else... distance is about 3m on each. >> >> Thanks, >> >> Alex >> >> >> ________________________________________ >> From: Michael K. Smith - Adhost [[email protected]] >> Sent: 29 September 2011 17:12 >> To: Alexander Fossa; cisco-nsp ?[[email protected]]? >> Subject: RE: NPE-G1 Interface errors / packetloss >> >> > -----Original Message----- >> > From: [email protected] [mailto:cisco-nsp- >> > [email protected]] On Behalf Of Alexander Fossa >> > Sent: Thursday, September 29, 2011 8:10 AM >> > To: cisco-nsp ?[[email protected]]? >> > Subject: [c-nsp] NPE-G1 Interface errors / packetloss >> > >> > Hi, >> > >> > We've been trying to diagnose a packetloss issue though one of our >>LNS's. >> > >> > The NPE-G1 is connected directly to a SUP32 with traffic in the >>region of >> > 50mbit. >> > >> > At first we thought it was a dirty fibre / failed SFP, both have been >>replaced >> > but the problem continues. >> > >> > We then moved the main infrastructure VLAN off Gi0/3 to Gi0/1, hence >> > ruling out the SUP32 port and the physical port on the NPE-G1. The >>errors >> > followed.... >> > >> > I've been doing quite a bit of reading and think this might be >>something to >> do >> > with microbursts.... but we've not had an increase in traffic, if >>anything a >> > decrease. >> > >> > Show interface stats from NPE-G1 >> > >> > GigabitEthernet0/1 is up, line protocol is up >> > Hardware is BCM1250 Internal MAC, address is 0008.203e.441b (bia >> > 0008.203e.441 >> > b) >> > Description: Link to BEDGE1.THE GI1/7 >> > MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec, >> > reliability 255/255, txload 5/255, rxload 4/255 >> > Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set >> > Keepalive set (10 sec) >> > Full-duplex, 1000Mb/s, media type is RJ45 >> > output flow-control is XON, input flow-control is XON >> > ARP type: ARPA, ARP Timeout 04:00:00 >> > Last input 00:00:00, output 00:00:00, output hang never >> > Last clearing of "show interface" counters 16:39:10 >> > Input queue: 0/1500/97/4 (size/max/drops/flushes); Total output >>drops: 0 >> > Queueing strategy: fifo >> > Output queue: 0/40 (size/max) >> > 5 minute input rate 18801000 bits/sec, 4990 packets/sec >> > 5 minute output rate 21289000 bits/sec, 5288 packets/sec >> > 152579806 packets input, 2828997929 bytes, 0 no buffer >> > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles >> > 0 input errors, 0 CRC, 0 frame, 142 overrun, 0 ignored >> > 0 watchdog, 265811 multicast, 0 pause input >> > 0 input packets with dribble condition detected >> > 161805464 packets output, 4109563833 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 >> > DSL1.THE# >> > >> > Show interface stats from SUP32 >> > >> > edge1.the#sh int gi1/7 >> > GigabitEthernet1/7 is up, line protocol is up (connected) >> > Hardware is C6k 1000Mb 802.3, address is 0016.465e.3732 (bia >> > 0016.465e.3732) >> > Description: DSL1.THE_GI0/1 >> > MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec, >> > reliability 255/255, txload 4/255, rxload 5/255 >> > Encapsulation ARPA, loopback not set >> > Keepalive set (10 sec) >> > Full-duplex, 1000Mb/s, media type is T >> > 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:21, output never, output hang never >> > Last clearing of "show interface" counters 16:25:18 >> > Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output >>drops: 0 >> > Queueing strategy: fifo >> > Output queue: 0/40 (size/max) >> > 5 minute input rate 21224000 bits/sec, 5233 packets/sec >> > 5 minute output rate 19475000 bits/sec, 4943 packets/sec >> > 160219198 packets input, 76742158873 bytes, 0 no buffer >> > Received 133662 broadcasts (133662 multicasts) >> > 47 runts, 0 giants, 0 throttles >> > 25065 input errors, 24986 CRC, 24939 frame, 0 overrun, 0 ignored >> > 0 watchdog, 0 multicast, 0 pause input >> > 0 input packets with dribble condition detected >> > 151327463 packets output, 65370785219 bytes, 0 underruns >> > 0 output errors, 0 collisions, 1 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 >> > edge1.the# >> > >> > As you can see lots of CRC & Frame errors the SUP32 side, and a few >> > overruns on the NPE-G1 side. >> > >> > Any ideas / thoughts? >> > >> > Thanks in advance, >> > >> > Alex >> > >> >> Hi Alex: >> >> Couple of things. >> >> 1) Flow Control - it looks like your NPE-G1 is set to XON/XON and your >>SUP32 >> has flow control off. I would disable flow control on the NPE-G1 to, >>if nothing >> else, make the sides match for testing. >> 2) Copper/Fiber? - you said you replaced fiber/SFP but the interface on >>both >> sides say this is a copper connection. With that, I would check for >>distance >> issues, bad cable, etc. >> 3) If anything, it looks like the issue is coming from the NPE-G1 side, >>given the >> huge amount of errors on the SUP32. >> >> Regards, >> >> Mike >> >> -- >> This message has been scanned for viruses and dangerous content by the >> Xifos Limited e-mail system. >> Further information can be found at www.xifos.net >> >> >> -- >> This message has been scanned for viruses and dangerous content by the >> Xifos Limited e-mail system. >> Further information can be found at www.xifos.net > > >-- >This message has been scanned for viruses and dangerous content by the >Xifos Limited e-mail system. >Further information can be found at www.xifos.net > > >-- >This message has been scanned for viruses and dangerous content by the >Xifos Limited e-mail system. >Further information can be found at www.xifos.net > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
