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

Wed May 23 16:40:46 EDT 2012

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/