[c-nsp] Lot of input errors on a NPE-G1 interface
gal.9430 at googlemail.com
gal.9430 at googlemail.com
Thu May 24 01:49:35 EDT 2012
Sibbi,
No errors on the second interface with LX optic:
GigabitEthernet0/2 is up, line protocol is up
Hardware is BCM1250 Internal MAC, address is 0006.52f4.d81a (bia
0006.52f4.d81a)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is autonegotiation, media type is LX
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 never
Input queue: 0/75/1018/467 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 6692000 bits/sec, 1543 packets/sec
5 minute output rate 8629000 bits/sec, 2402 packets/sec
240944267 packets input, 764868435 bytes, 20 no buffer
Received 665 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 8 multicast, 0 pause input
0 input packets with dribble condition detected
307328333 packets output, 3150334452 bytes, 0 underruns
5 output errors, 0 collisions, 4 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
5 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
It is a good time to start with a layer-1 diagnostic and change the optics.
On Thu, May 24, 2012 at 1:10 AM, Sigurbjörn Birkir Lárusson
<sigurbjornl at vodafone.is> wrote:
> Similar traffic on the other port I assume, outbound port for the router?
> No input errors there?
>
> If you also see input errors and overruns on the other port, the CPU is
> probably having issues emptying the buffer before it runs out of buffer
> space which would suggest high CPU usage during the times when the
> overruns are occuring. Then you should look at why that is the case, it's
> not enough traffic to really cause that issue, but you might have other
> features enabled that are causing the box to use a lot of cpu.
>
> If there are no errors on the other port, it's more likely that this is a
> layer 1 problem, and you should try replacing the optics if you have
> spares or cleaning the existing ones
>
> Kind regards,
> Sibbi
>
> On 23.5.2012 21:24, "gal.9430 at googlemail.com" <gal.9430 at googlemail.com>
> wrote:
>
>>> Are you getting bursts of traffic that might not register on traffic
>>>graphs polling at 5 minute intervals?
>>
>>No, I don't think so. Burst traffic never exceeds 80-100 Mbps. We're
>>polling in a 1 min interval.
>>
>>
>>On Wed, May 23, 2012 at 11:16 PM, Edward Salonia
>><Edward.Salonia at ipsoft.com> wrote:
>>> Drops and overruns... Sounds like you are overloading your port buffer.
>>>Are you getting bursts of traffic that might not register on traffic
>>>graphs polling at 5 minute intervals?
>>>
>>> - Ed
>>>
>>> -----Original Message-----
>>> From: cisco-nsp-bounces at puck.nether.net
>>>[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>>>gal.9430 at googlemail.com
>>> Sent: Wednesday, May 23, 2012 5:00 PM
>>> To: Sigurbjörn Birkir Lárusson
>>> Cc: cisco-nsp at puck.nether.net
>>> Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface
>>>
>>>> Is this the only traffic going through this 7200?
>>>
>>> No. Gi0/1 is connected via 2960G to another router (iBGP). Gi0/2 is
>>> connected to an eBGP peer
>>> who sends a full table.
>>>
>>>> How is your scheduler allocate set on the 7200...
>>>
>>> Default value, not changed.
>>>
>>>> ...have you tried a new cable and cleaning the optics?
>>>
>>> New cable: yes
>>> Cleaning the optics: no
>>>
>>>
>>>
>>> On Wed, May 23, 2012 at 10:40 PM, Sigurbjörn Birkir Lárusson
>>> <sigurbjornl at vodafone.is> wrote:
>>>> Is this the only traffic going through this 7200?
>>>>
>>>> How is your scheduler allocate set on the 7200, have you tried a new
>>>>cable
>>>> and cleaning the optics?
>>>>
>>>> Kind regards,
>>>> Sibbi
>>>>
>>>> On 23.5.2012 19:33, "gal.9430 at googlemail.com" <gal.9430 at googlemail.com>
>>>> wrote:
>>>>
>>>>>Hi,
>>>>>
>>>>>thanks all for the input.
>>>>>
>>>>>Increasing the hold-queue (from default to 100) doesn't seem to help at
>>>>>all:
>>>>>
>>>>>GigabitEthernet0/1 is up, line protocol is up
>>>>> Hardware is BCM1250 Internal MAC, address is 0006.52f4.d81b (bia
>>>>>0006.52f4.d81b)
>>>>> Internet address is x.x.x.x/28
>>>>> MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
>>>>> reliability 255/255, txload 1/255, rxload 2/255
>>>>> Encapsulation ARPA, loopback not set
>>>>> Keepalive set (10 sec)
>>>>> Full-duplex, 1000Mb/s, link type is autonegotiation, media type is SX
>>>>> 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 02:17:11
>>>>> Input queue: 0/100/742/0 (size/max/drops/flushes); Total output
>>>>>drops: 0
>>>>> Queueing strategy: fifo
>>>>> Output queue: 0/40 (size/max)
>>>>> 5 minute input rate 10536000 bits/sec, 1824 packets/sec
>>>>> 5 minute output rate 6813000 bits/sec, 2121 packets/sec
>>>>> 11770910 packets input, 2922271410 bytes, 0 no buffer
>>>>> Received 215 broadcasts, 0 runts, 0 giants, 0 throttles
>>>>> 341 input errors, 0 CRC, 0 frame, 341 overrun, 0 ignored
>>>>> 0 watchdog, 4242 multicast, 0 pause input
>>>>> 0 input packets with dribble condition detected
>>>>> 14975201 packets output, 1820911878 bytes, 0 underruns
>>>>> 0 output errors, 0 collisions, 0 interface resets
>>>>> 137 unknown protocol drops
>>>>> 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
>>>>>
>>>>>Will go from 100 to 150 and see whats happen.
>>>>>
>>>>>
>>>>>
>>>>>On Wed, May 23, 2012 at 9:27 PM, Phil Mayers <p.mayers at imperial.ac.uk>
>>>>>wrote:
>>>>>> On 05/23/2012 08:18 PM, Chris Gotstein wrote:
>>>>>>>
>>>>>>> %Warning: portfast should only be enabled on ports connected to a
>>>>>>>single
>>>>>>> host. Connecting hubs, concentrators, switches, bridges, etcŠ to
>>>>>>>this
>>>>>>> interface when portfast is enabled, can cause temporary bridging
>>>>>>>loops.
>>>>>>>
>>>>>>> My understanding of this was a router would be included as well
>>>>>>>since
>>>>>>> it's used to connect multiple hosts.
>>>>>>
>>>>>>
>>>>>> If you don't enable portfast, you have to suffer the STP state
>>>>>>transitions,
>>>>>> which lead to delays in traffic forwarding after link-up.
>>>>>>
>>>>>> Portfast basically means: "This port is unlikely to be connected to
>>>>>>another
>>>>>> bridge or hub, so skip the LISTENING/LEARNING transitions and jump
>>>>>>straight
>>>>>> to forwarding; if it goes wrong, STP will close the loop shortly."
>>>>>>
>>>>>> It's not magic; and it should be enabled on all host ports. Routers
>>>>>>are
>>>>>> hosts, at layer2.
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>
>>>>>_______________________________________________
>>>>>cisco-nsp mailing list cisco-nsp at puck.nether.net
>>>>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>>archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list