[c-nsp] NPE-G1 Interface errors / packetloss
Alexander Fossa
alex.fossa at xifos.net
Thu Sep 29 13:22:48 EDT 2011
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 [mksmith at adhost.com]
Sent: 29 September 2011 17:55
To: Alexander Fossa; cisco-nsp [cisco-nsp at puck.nether.net]
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 mksmith at adhost.com
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:alex.fossa at xifos.net]
> Sent: Thursday, September 29, 2011 9:20 AM
> To: Michael K. Smith - Adhost; cisco-nsp [cisco-nsp at puck.nether.net]
> 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 [mksmith at adhost.com]
> Sent: 29 September 2011 17:12
> To: Alexander Fossa; cisco-nsp [cisco-nsp at puck.nether.net]
> Subject: RE: NPE-G1 Interface errors / packetloss
>
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Alexander Fossa
> > Sent: Thursday, September 29, 2011 8:10 AM
> > To: cisco-nsp [cisco-nsp at puck.nether.net]
> > 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
More information about the cisco-nsp
mailing list