[c-nsp] Lot of input errors on a NPE-G1 interface

Wed May 23 17:24:43 EDT 2012

> 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/