[c-nsp] NPE-G1 Interface errors / packetloss
Michael K. Smith - Adhost
mksmith at adhost.com
Thu Sep 29 17:48:32 EDT 2011
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" <alex.fossa at xifos.net> 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 [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