Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Cisco>
  3. NSP
1 2  View All
Lot of input errors on a NPE-G1 interface
gal.9430 at googlemail
May 22, 2012, 11:04 PM
Post #1 of 44 (15403 views)
Permalink
Hi,

I've some trouble with a NPE-G1 interface connected to a Catalyst
2960G switch via multimode cable. Input errors increases very fast.
Optics on both sides are original cisco. Average bandwidth is ~30-50
Mbps, burst bandwidth ~80-100 Mbps for a short period.

Configuration NPE-G1 interface:
----------------------------------------------
interface GigabitEthernet0/1
ip address x.x.x.x 255.255.255.240
no ip proxy-arp
ip route-cache flow
duplex full
speed 1000
media-type gbic
negotiation auto
ipv6 address x:x:x::x/64
no cdp enable

Configuration switch interface:
--------------------------------------------
!
interface GigabitEthernet0/23
description Cisco7204VXR
switchport access vlan 250
switchport mode access
spanning-tree portfast
!

Uptime:
-----------
Router uptime is 9 hours, 14 minutes
System returned to ROM by bus error at PC 0x621E0668, address
0x18680DD8 at 22:37:34 MET Tue May 22 2012
System restarted at 22:40:33 MET Tue May 22 2012
System image file is "disk2:c7200-adventerprisek9-mz.124-15.T13.bin"

NPE-G1:
------------
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 1/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 never
Input queue: 0/75/1321/1 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 4264000 bits/sec, 871 packets/sec
5 minute output rate 5859000 bits/sec, 1597 packets/sec
27479327 packets input, 3434822229 bytes, 0 no buffer
Received 941 broadcasts, 0 runts, 0 giants, 0 throttles
989 input errors, 0 CRC, 0 frame, 989 overrun, 0 ignored
0 watchdog, 17119 multicast, 0 pause input
0 input packets with dribble condition detected
43616309 packets output, 2243854018 bytes, 0 underruns
5 output errors, 0 collisions, 4 interface resets
561 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

Catalyst:
--------------
GigabitEthernet0/23 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 04fe.7f65.2197 (bia 04fe.7f65.2197)
Description: Cisco7204VXR
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 5582000 bits/sec, 1596 packets/sec
5 minute output rate 5445000 bits/sec, 1002 packets/sec
160765357185 packets input, 75815081907836 bytes, 0 no buffer
Received 580911 broadcasts (468086 multicasts)
0 runts, 0 giants, 0 throttles
5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 468086 multicast, 343548 pause input
0 input packets with dribble condition detected
116641123524 packets output, 71833102673211 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

The last uptime was nearly 70 days and input errors round about 96k.
Does anyone have an explanation for that?


Thanks
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
chris at uplogon
May 23, 2012, 8:18 AM
Post #2 of 44 (15251 views)
Permalink
First suggestion i would make is removing spanning-tree portfast from
the switch config.

You can also try increasing your hold queue on the 7204 with the command:

hold-queue <length> in

The recommendation is to increase in small increments, so i would
suggest starting with 100.

http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml

On 5/23/2012 1:04 AM, gal.9430@googlemail.com wrote:
> Hi,
>
> I've some trouble with a NPE-G1 interface connected to a Catalyst
> 2960G switch via multimode cable. Input errors increases very fast.
> Optics on both sides are original cisco. Average bandwidth is ~30-50
> Mbps, burst bandwidth ~80-100 Mbps for a short period.
>
> Configuration NPE-G1 interface:
> ----------------------------------------------
> interface GigabitEthernet0/1
> ip address x.x.x.x 255.255.255.240
> no ip proxy-arp
> ip route-cache flow
> duplex full
> speed 1000
> media-type gbic
> negotiation auto
> ipv6 address x:x:x::x/64
> no cdp enable
>
> Configuration switch interface:
> --------------------------------------------
> !
> interface GigabitEthernet0/23
> description Cisco7204VXR
> switchport access vlan 250
> switchport mode access
> spanning-tree portfast
> !
>
> Uptime:
> -----------
> Router uptime is 9 hours, 14 minutes
> System returned to ROM by bus error at PC 0x621E0668, address
> 0x18680DD8 at 22:37:34 MET Tue May 22 2012
> System restarted at 22:40:33 MET Tue May 22 2012
> System image file is "disk2:c7200-adventerprisek9-mz.124-15.T13.bin"
>
> NPE-G1:
> ------------
> 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 1/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 never
> Input queue: 0/75/1321/1 (size/max/drops/flushes); Total output drops: 0
> Queueing strategy: fifo
> Output queue: 0/40 (size/max)
> 5 minute input rate 4264000 bits/sec, 871 packets/sec
> 5 minute output rate 5859000 bits/sec, 1597 packets/sec
> 27479327 packets input, 3434822229 bytes, 0 no buffer
> Received 941 broadcasts, 0 runts, 0 giants, 0 throttles
> 989 input errors, 0 CRC, 0 frame, 989 overrun, 0 ignored
> 0 watchdog, 17119 multicast, 0 pause input
> 0 input packets with dribble condition detected
> 43616309 packets output, 2243854018 bytes, 0 underruns
> 5 output errors, 0 collisions, 4 interface resets
> 561 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
>
> Catalyst:
> --------------
> GigabitEthernet0/23 is up, line protocol is up (connected)
> Hardware is Gigabit Ethernet, address is 04fe.7f65.2197 (bia 04fe.7f65.2197)
> Description: Cisco7204VXR
> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> reliability 255/255, txload 1/255, rxload 1/255
> Encapsulation ARPA, loopback not set
> Keepalive not set
> Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP
> input flow-control is off, output flow-control is unsupported
> ARP type: ARPA, ARP Timeout 04:00:00
> Last input never, output 00:00:01, output hang never
> Last clearing of "show interface" counters never
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
> Queueing strategy: fifo
> Output queue: 0/40 (size/max)
> 5 minute input rate 5582000 bits/sec, 1596 packets/sec
> 5 minute output rate 5445000 bits/sec, 1002 packets/sec
> 160765357185 packets input, 75815081907836 bytes, 0 no buffer
> Received 580911 broadcasts (468086 multicasts)
> 0 runts, 0 giants, 0 throttles
> 5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> 0 watchdog, 468086 multicast, 343548 pause input
> 0 input packets with dribble condition detected
> 116641123524 packets output, 71833102673211 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
>
> The last uptime was nearly 70 days and input errors round about 96k.
> Does anyone have an explanation for that?
>
>
> Thanks
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
---- ---- ---- ----
Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gal.9430 at googlemail
May 23, 2012, 9:25 AM
Post #3 of 44 (15251 views)
Permalink
Hi Chris,

thx for pointing this out! But what happened if I increase the hold-queue
from 75 (default) to 200 or 400?


On Wed, May 23, 2012 at 5:18 PM, Chris Gotstein <chris@uplogon.com> wrote:
> First suggestion i would make is removing spanning-tree portfast from the
> switch config.
>
> You can also try increasing your hold queue on the 7204 with the command:
>
> hold-queue <length> in
>
> The recommendation is to increase in small increments, so i would suggest
> starting with 100.
>
> http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml
>
>
> On 5/23/2012 1:04 AM, gal.9430@googlemail.com wrote:
>>
>> Hi,
>>
>> I've some trouble with a NPE-G1 interface connected to a Catalyst
>> 2960G switch via multimode cable. Input errors increases very fast.
>> Optics on both sides are original cisco. Average bandwidth is ~30-50
>> Mbps, burst bandwidth ~80-100 Mbps for a short period.
>>
>> Configuration NPE-G1 interface:
>> ----------------------------------------------
>> interface GigabitEthernet0/1
>>  ip address x.x.x.x 255.255.255.240
>>  no ip proxy-arp
>>  ip route-cache flow
>>  duplex full
>>  speed 1000
>>  media-type gbic
>>  negotiation auto
>>  ipv6 address x:x:x::x/64
>>  no cdp enable
>>
>> Configuration switch interface:
>> --------------------------------------------
>> !
>> interface GigabitEthernet0/23
>>  description Cisco7204VXR
>>  switchport access vlan 250
>>  switchport mode access
>>  spanning-tree portfast
>> !
>>
>> Uptime:
>> -----------
>> Router uptime is 9 hours, 14 minutes
>> System returned to ROM by bus error at PC 0x621E0668, address
>> 0x18680DD8 at 22:37:34 MET Tue May 22 2012
>> System restarted at 22:40:33 MET Tue May 22 2012
>> System image file is "disk2:c7200-adventerprisek9-mz.124-15.T13.bin"
>>
>> NPE-G1:
>> ------------
>> 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 1/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 never
>>   Input queue: 0/75/1321/1 (size/max/drops/flushes); Total output drops: 0
>>   Queueing strategy: fifo
>>   Output queue: 0/40 (size/max)
>>   5 minute input rate 4264000 bits/sec, 871 packets/sec
>>   5 minute output rate 5859000 bits/sec, 1597 packets/sec
>>      27479327 packets input, 3434822229 bytes, 0 no buffer
>>      Received 941 broadcasts, 0 runts, 0 giants, 0 throttles
>>      989 input errors, 0 CRC, 0 frame, 989 overrun, 0 ignored
>>      0 watchdog, 17119 multicast, 0 pause input
>>      0 input packets with dribble condition detected
>>      43616309 packets output, 2243854018 bytes, 0 underruns
>>      5 output errors, 0 collisions, 4 interface resets
>>      561 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
>>
>> Catalyst:
>> --------------
>> GigabitEthernet0/23 is up, line protocol is up (connected)
>>   Hardware is Gigabit Ethernet, address is 04fe.7f65.2197 (bia
>> 04fe.7f65.2197)
>>   Description: Cisco7204VXR
>>   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>>      reliability 255/255, txload 1/255, rxload 1/255
>>   Encapsulation ARPA, loopback not set
>>   Keepalive not set
>>   Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP
>>   input flow-control is off, output flow-control is unsupported
>>   ARP type: ARPA, ARP Timeout 04:00:00
>>   Last input never, output 00:00:01, output hang never
>>   Last clearing of "show interface" counters never
>>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>>   Queueing strategy: fifo
>>   Output queue: 0/40 (size/max)
>>   5 minute input rate 5582000 bits/sec, 1596 packets/sec
>>   5 minute output rate 5445000 bits/sec, 1002 packets/sec
>>      160765357185 packets input, 75815081907836 bytes, 0 no buffer
>>      Received 580911 broadcasts (468086 multicasts)
>>      0 runts, 0 giants, 0 throttles
>>      5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>>      0 watchdog, 468086 multicast, 343548 pause input
>>      0 input packets with dribble condition detected
>>      116641123524 packets output, 71833102673211 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
>>
>> The last uptime was nearly 70 days and input errors round about 96k.
>> Does anyone have an explanation for that?
>>
>>
>> Thanks
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> --
> ---- ---- ---- ----
> Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
> http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
chris at uplogon
May 23, 2012, 9:30 AM
Post #4 of 44 (15242 views)
Permalink
From Cisco:

Caution: An increase in the hold queue can have detrimental effects on
network routing and response times. For protocols that use SEQ/ACK
packets to determine round-trip times, do not increase the output queue.
Dropping packets instead informs hosts to slow down transmissions to
match available bandwidth. This is generally better than duplicate
copies of the same packet within the network, which can happen with
large hold queues.

Start small, i won't go much over 100, maybe 150. Clear counters and
see what the stats look like after you make the change.

On 5/23/2012 11:25 AM, gal.9430@googlemail.com wrote:
> Hi Chris,
>
> thx for pointing this out! But what happened if I increase the hold-queue
> from 75 (default) to 200 or 400?
>
>
> On Wed, May 23, 2012 at 5:18 PM, Chris Gotstein<chris@uplogon.com> wrote:
>> First suggestion i would make is removing spanning-tree portfast from the
>> switch config.
>>
>> You can also try increasing your hold queue on the 7204 with the command:
>>
>> hold-queue<length> in
>>
>> The recommendation is to increase in small increments, so i would suggest
>> starting with 100.
>>
>> http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml
>>
>>
>> On 5/23/2012 1:04 AM, gal.9430@googlemail.com wrote:
>>>
>>> Hi,
>>>
>>> I've some trouble with a NPE-G1 interface connected to a Catalyst
>>> 2960G switch via multimode cable. Input errors increases very fast.
>>> Optics on both sides are original cisco. Average bandwidth is ~30-50
>>> Mbps, burst bandwidth ~80-100 Mbps for a short period.
>>>
>>> Configuration NPE-G1 interface:
>>> ----------------------------------------------
>>> interface GigabitEthernet0/1
>>> ip address x.x.x.x 255.255.255.240
>>> no ip proxy-arp
>>> ip route-cache flow
>>> duplex full
>>> speed 1000
>>> media-type gbic
>>> negotiation auto
>>> ipv6 address x:x:x::x/64
>>> no cdp enable
>>>
>>> Configuration switch interface:
>>> --------------------------------------------
>>> !
>>> interface GigabitEthernet0/23
>>> description Cisco7204VXR
>>> switchport access vlan 250
>>> switchport mode access
>>> spanning-tree portfast
>>> !
>>>
>>> Uptime:
>>> -----------
>>> Router uptime is 9 hours, 14 minutes
>>> System returned to ROM by bus error at PC 0x621E0668, address
>>> 0x18680DD8 at 22:37:34 MET Tue May 22 2012
>>> System restarted at 22:40:33 MET Tue May 22 2012
>>> System image file is "disk2:c7200-adventerprisek9-mz.124-15.T13.bin"
>>>
>>> NPE-G1:
>>> ------------
>>> 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 1/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 never
>>> Input queue: 0/75/1321/1 (size/max/drops/flushes); Total output drops: 0
>>> Queueing strategy: fifo
>>> Output queue: 0/40 (size/max)
>>> 5 minute input rate 4264000 bits/sec, 871 packets/sec
>>> 5 minute output rate 5859000 bits/sec, 1597 packets/sec
>>> 27479327 packets input, 3434822229 bytes, 0 no buffer
>>> Received 941 broadcasts, 0 runts, 0 giants, 0 throttles
>>> 989 input errors, 0 CRC, 0 frame, 989 overrun, 0 ignored
>>> 0 watchdog, 17119 multicast, 0 pause input
>>> 0 input packets with dribble condition detected
>>> 43616309 packets output, 2243854018 bytes, 0 underruns
>>> 5 output errors, 0 collisions, 4 interface resets
>>> 561 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
>>>
>>> Catalyst:
>>> --------------
>>> GigabitEthernet0/23 is up, line protocol is up (connected)
>>> Hardware is Gigabit Ethernet, address is 04fe.7f65.2197 (bia
>>> 04fe.7f65.2197)
>>> Description: Cisco7204VXR
>>> MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>>> reliability 255/255, txload 1/255, rxload 1/255
>>> Encapsulation ARPA, loopback not set
>>> Keepalive not set
>>> Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP
>>> input flow-control is off, output flow-control is unsupported
>>> ARP type: ARPA, ARP Timeout 04:00:00
>>> Last input never, output 00:00:01, output hang never
>>> Last clearing of "show interface" counters never
>>> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>>> Queueing strategy: fifo
>>> Output queue: 0/40 (size/max)
>>> 5 minute input rate 5582000 bits/sec, 1596 packets/sec
>>> 5 minute output rate 5445000 bits/sec, 1002 packets/sec
>>> 160765357185 packets input, 75815081907836 bytes, 0 no buffer
>>> Received 580911 broadcasts (468086 multicasts)
>>> 0 runts, 0 giants, 0 throttles
>>> 5 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>>> 0 watchdog, 468086 multicast, 343548 pause input
>>> 0 input packets with dribble condition detected
>>> 116641123524 packets output, 71833102673211 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
>>>
>>> The last uptime was nearly 70 days and input errors round about 96k.
>>> Does anyone have an explanation for that?
>>>
>>>
>>> Thanks
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>> --
>> ---- ---- ---- ----
>> Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
>> http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
---- ---- ---- ----
Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gert at greenie
May 23, 2012, 10:57 AM
Post #5 of 44 (15224 views)
Permalink
Hi,

On Wed, May 23, 2012 at 10:18:45AM -0500, Chris Gotstein wrote:
> First suggestion i would make is removing spanning-tree portfast from
> the switch config.

How exactly is that going to *help* with overruns?

All it will do is annoy you after a link flap, and if you run rstp, it
will annoy half your network after a flap on that link.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
chris at uplogon
May 23, 2012, 11:15 AM
Post #6 of 44 (15229 views)
Permalink
It's probably not going to address the overrun issue, but from a best
practices stand point, it should not be enabled on interfaces that
connected to other connected devices, ie a router or switch.

On 5/23/2012 12:57 PM, Gert Doering wrote:
> Hi,
>
> On Wed, May 23, 2012 at 10:18:45AM -0500, Chris Gotstein wrote:
>> First suggestion i would make is removing spanning-tree portfast from
>> the switch config.
>
> How exactly is that going to *help* with overruns?
>
> All it will do is annoy you after a link flap, and if you run rstp, it
> will annoy half your network after a flap on that link.
>
> gert

--
---- ---- ---- ----
Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
mhuff at ox
May 23, 2012, 11:23 AM
Post #7 of 44 (15272 views)
Permalink
Can you explain why it is a best practice to disable portfast connected to a
L3 device such as a router? Switch, obviously, but a router?


----
Matthew Huff  | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC | Phone: 914-460-4039
aim: matthewbhuff  | Fax:   914-460-4139


> -----Original Message-----
> From: cisco-nsp-bounces@puck.nether.net [mailto:cisco-nsp-
> bounces@puck.nether.net] On Behalf Of Chris Gotstein
> Sent: Wednesday, May 23, 2012 2:15 PM
> To: Gert Doering
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface
>
> It's probably not going to address the overrun issue, but from a best
> practices stand point, it should not be enabled on interfaces that
> connected to other connected devices, ie a router or switch.
>
> On 5/23/2012 12:57 PM, Gert Doering wrote:
> > Hi,
> >
> > On Wed, May 23, 2012 at 10:18:45AM -0500, Chris Gotstein wrote:
> >> First suggestion i would make is removing spanning-tree portfast
> from
> >> the switch config.
> >
> > How exactly is that going to *help* with overruns?
> >
> > All it will do is annoy you after a link flap, and if you run rstp,
> it
> > will annoy half your network after a flap on that link.
> >
> > gert
>
> --
> ---- ---- ---- ----
> Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
> http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

Attached Files:

Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gert at greenie
May 23, 2012, 11:29 AM
Post #8 of 44 (15183 views)
Permalink
Hi,

On Wed, May 23, 2012 at 01:15:16PM -0500, Chris Gotstein wrote:
> It's probably not going to address the overrun issue, but from a best
> practices stand point, it should not be enabled on interfaces that
> connected to other connected devices, ie a router or switch.

Uh, so it should only be turned on for switchports that connect to...
"no device"?

Anyway: right for "to switch", dead wrong for "to router". It should be
turned on for any connection that is known to not go to a switch or hub,
and doubly so if rapid-pvstp is used (due to TCNs being sent on a link
flap otherwise, possibly causing stalls elsewhere).

As far as a switch is concerned, a "router" is the same thing as "a host" -
it doesn't forward layer2 things, so can't cause a routing loop.

gert

--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
chris at uplogon
May 23, 2012, 12:18 PM
Post #9 of 44 (15226 views)
Permalink
%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. I only enable portfast on ports
connected to end-user devices. I don't see a good reason to enable it
on ports connected to routers, but that's just how it was explained to
me, I very well could be wrong.

On 5/23/2012 1:29 PM, Gert Doering wrote:
> Hi,
>
> On Wed, May 23, 2012 at 01:15:16PM -0500, Chris Gotstein wrote:
>> It's probably not going to address the overrun issue, but from a best
>> practices stand point, it should not be enabled on interfaces that
>> connected to other connected devices, ie a router or switch.
>
> Uh, so it should only be turned on for switchports that connect to...
> "no device"?
>
> Anyway: right for "to switch", dead wrong for "to router". It should be
> turned on for any connection that is known to not go to a switch or hub,
> and doubly so if rapid-pvstp is used (due to TCNs being sent on a link
> flap otherwise, possibly causing stalls elsewhere).
>
> As far as a switch is concerned, a "router" is the same thing as "a host" -
> it doesn't forward layer2 things, so can't cause a routing loop.
>
> gert
>

--
---- ---- ---- ----
Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
MatlockK at exempla
May 23, 2012, 12:23 PM
Post #10 of 44 (15193 views)
Permalink
" hubs, concentrators, switches, bridges, etc... to this interface
when portfast is enabled, can cause temporary bridging loops."

Those are all Layer 2 devices. A router is a layer 3 device (unless you
explicitly turn bridging on).

Ken Matlock
Network Analyst
303-467-4671
matlockk@exempla.org




-----Original Message-----
From: cisco-nsp-bounces@puck.nether.net
[mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of Chris Gotstein
Sent: Wednesday, May 23, 2012 1:19 PM
To: Gert Doering
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface

%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. I only enable portfast on ports
connected to end-user devices. I don't see a good reason to enable it
on ports connected to routers, but that's just how it was explained to
me, I very well could be wrong.

On 5/23/2012 1:29 PM, Gert Doering wrote:
> Hi,
>
> On Wed, May 23, 2012 at 01:15:16PM -0500, Chris Gotstein wrote:
>> It's probably not going to address the overrun issue, but from a best

>> practices stand point, it should not be enabled on interfaces that
>> connected to other connected devices, ie a router or switch.
>
> Uh, so it should only be turned on for switchports that connect to...
> "no device"?
>
> Anyway: right for "to switch", dead wrong for "to router". It should
> be turned on for any connection that is known to not go to a switch or

> hub, and doubly so if rapid-pvstp is used (due to TCNs being sent on a

> link flap otherwise, possibly causing stalls elsewhere).
>
> As far as a switch is concerned, a "router" is the same thing as "a
> host" - it doesn't forward layer2 things, so can't cause a routing
loop.
>
> gert
>

--
---- ---- ---- ----
Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
*** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice ***


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
p.mayers at imperial
May 23, 2012, 12:27 PM
Post #11 of 44 (15175 views)
Permalink
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gal.9430 at googlemail
May 23, 2012, 12:33 PM
Post #12 of 44 (15240 views)
Permalink
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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
chris at uplogon
May 23, 2012, 1:02 PM
Post #13 of 44 (15209 views)
Permalink
I always just played it safe, but now i'm better informed, thank you.

On 5/23/2012 2:27 PM, Phil Mayers 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--
---- ---- ---- ----
Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
mark.tinka at seacom
May 23, 2012, 1:03 PM
Post #14 of 44 (15198 views)
Permalink
On Wednesday, May 23, 2012 09:23:03 PM Matlock, Kenneth L
wrote:

> " hubs, concentrators, switches, bridges, etc... to this
> interface when portfast is enabled, can cause temporary
> bridging loops."
>
> Those are all Layer 2 devices. A router is a layer 3
> device (unless you explicitly turn bridging on).

We disable Portfast for all 802.1Q trunks, regardless of
whether they're going to routers or switches.

If an engineer moves connections by mistake, or plugs the
trunk from the switch into another switch by mistake,
instead of a router, you have that protection.

The 50-odd seconds required for the STP state machine to
raech a Forwarding situation is a small price to pay for
this safety, in my opinion (Lord knows how many times we've
been saved by blocking Edge ports on BPDU receipt).

Of course, the topologies have a part to play in one's
thought process; if there is redundancy between the switches
and their uplink routers, it's not such a big deal. But if
services that rely on things like TFTP or DHCP are of
importance, one has to rethink this for their network.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
MatlockK at exempla
May 23, 2012, 1:04 PM
Post #15 of 44 (15232 views)
Permalink
Think of it this way. What does Portfast do? It allows you to skip from
blocking to forwarding, bypassing listening and learning states.

If you have portfast enabled to a L2 device, and that L2 device also has
another connection to the same L2 you've created a bridging loop until
the first BPDU comes in and the switch disables one of the ports
involved.

Now, configuring portfast on a port going to and end host or router is
fairly benign since there's no other link to the same L2 bridged through
the device. You'd have to plug 2 ports from the end device (or router)
into the same L2, and explicitly configure them to be bridged in order
to create a bridging loop. But normally you're only going to plug a
single cable from an end device into the L2 so you know bridging loops
won't get created, so it's 'safe' to skip listening/learning steps and
go right to forwarding, to decrease the time it takes for the device to
be 'live'.

Make sense?

Ken Matlock
Network Analyst
303-467-4671
matlockk@exempla.org




-----Original Message-----
From: cisco-nsp-bounces@puck.nether.net
[mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of Matlock, Kenneth
L
Sent: Wednesday, May 23, 2012 1:23 PM
To: Chris Gotstein; Gert Doering
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface

" hubs, concentrators, switches, bridges, etc... to this interface when
portfast is enabled, can cause temporary bridging loops."

Those are all Layer 2 devices. A router is a layer 3 device (unless you
explicitly turn bridging on).

Ken Matlock
Network Analyst
303-467-4671
matlockk@exempla.org




-----Original Message-----
From: cisco-nsp-bounces@puck.nether.net
[mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of Chris Gotstein
Sent: Wednesday, May 23, 2012 1:19 PM
To: Gert Doering
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface

%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. I only enable portfast on ports
connected to end-user devices. I don't see a good reason to enable it
on ports connected to routers, but that's just how it was explained to
me, I very well could be wrong.

On 5/23/2012 1:29 PM, Gert Doering wrote:
> Hi,
>
> On Wed, May 23, 2012 at 01:15:16PM -0500, Chris Gotstein wrote:
>> It's probably not going to address the overrun issue, but from a best

>> practices stand point, it should not be enabled on interfaces that
>> connected to other connected devices, ie a router or switch.
>
> Uh, so it should only be turned on for switchports that connect to...
> "no device"?
>
> Anyway: right for "to switch", dead wrong for "to router". It should
> be turned on for any connection that is known to not go to a switch or

> hub, and doubly so if rapid-pvstp is used (due to TCNs being sent on a

> link flap otherwise, possibly causing stalls elsewhere).
>
> As far as a switch is concerned, a "router" is the same thing as "a
> host" - it doesn't forward layer2 things, so can't cause a routing
loop.
>
> gert
>

--
---- ---- ---- ----
Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P.
http://uplogon.com | +1 906 774 4847 | chris@uplogon.com
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
*** Exempla Confidentiality Notice *** The information contained in this
message may be privileged and confidential and protected from
disclosure. If the reader of this message is not the intended recipient,
or an employee or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any other
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please
notify me immediately by replying to the message and deleting it from
your computer. Thank you. *** Exempla Confidentiality Notice ***


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
*** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice ***


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gert at greenie
May 23, 2012, 1:24 PM
Post #16 of 44 (15198 views)
Permalink
Hi,

On Wed, May 23, 2012 at 02:04:58PM -0600, Matlock, Kenneth L wrote:
> Think of it this way. What does Portfast do? It allows you to skip from
> blocking to forwarding, bypassing listening and learning states.

Plus, it changes TCN behaviour for rapid-pvstp for flaps on that port.

That's one of the often-overlooked side effects.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
MatlockK at exempla
May 23, 2012, 1:30 PM
Post #17 of 44 (15180 views)
Permalink
True, if a portfast port bounces it doesn't trigger a TCN, which then
doesn't trigger CAM table flushes.

Ken Matlock
Network Analyst
303-467-4671
matlockk@exempla.org




-----Original Message-----
From: Gert Doering [mailto:gert@greenie.muc.de]
Sent: Wednesday, May 23, 2012 2:25 PM
To: Matlock, Kenneth L
Cc: Chris Gotstein; Gert Doering; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface

Hi,

On Wed, May 23, 2012 at 02:04:58PM -0600, Matlock, Kenneth L wrote:
> Think of it this way. What does Portfast do? It allows you to skip
> from blocking to forwarding, bypassing listening and learning states.

Plus, it changes TCN behaviour for rapid-pvstp for flaps on that port.

That's one of the often-overlooked side effects.

gert
--
USENET is *not* the non-clickable part of WWW!

//www.muc.de/~gert/
Gert Doering - Munich, Germany
gert@greenie.muc.de
fax: +49-89-35655025
gert@net.informatik.tu-muenchen.de
*** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice ***


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
sigurbjornl at vodafone
May 23, 2012, 1:40 PM
Post #18 of 44 (15190 views)
Permalink
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@googlemail.com" <gal.9430@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gal.9430 at googlemail
May 23, 2012, 2:00 PM
Post #19 of 44 (15176 views)
Permalink
> 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@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@googlemail.com" <gal.9430@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
Edward.Salonia at ipsoft
May 23, 2012, 2:16 PM
Post #20 of 44 (15240 views)
Permalink
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@puck.nether.net [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of gal.9430@googlemail.com
Sent: Wednesday, May 23, 2012 5:00 PM
To: Sigurbjörn Birkir Lárusson
Cc: cisco-nsp@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@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@googlemail.com" <gal.9430@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@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gal.9430 at googlemail
May 23, 2012, 2:24 PM
Post #21 of 44 (15177 views)
Permalink
> 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@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@puck.nether.net [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of gal.9430@googlemail.com
> Sent: Wednesday, May 23, 2012 5:00 PM
> To: Sigurbjörn Birkir Lárusson
> Cc: cisco-nsp@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@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@googlemail.com" <gal.9430@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@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
sigurbjornl at vodafone
May 23, 2012, 4:10 PM
Post #22 of 44 (15184 views)
Permalink
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@googlemail.com" <gal.9430@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@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@puck.nether.net
>>[mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of
>>gal.9430@googlemail.com
>> Sent: Wednesday, May 23, 2012 5:00 PM
>> To: Sigurbjörn Birkir Lárusson
>> Cc: cisco-nsp@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@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@googlemail.com" <gal.9430@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@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
MatlockK at exempla
May 23, 2012, 4:13 PM
Post #23 of 44 (15203 views)
Permalink
The problem with a 1 minute interval is that you can EASILY be bursting well above that for short periods of time. remember that 80-100Mbps is an average over the entire 1 minute.

Are you running QoS or Netflow on this box?

Ken

________________________________

From: cisco-nsp-bounces@puck.nether.net on behalf of gal.9430@googlemail.com
Sent: Wed 5/23/2012 3:24 PM
To: Edward Salonia
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Lot of input errors on a NPE-G1 interface



> 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@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@puck.nether.net [mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of gal.9430@googlemail.com
> Sent: Wednesday, May 23, 2012 5:00 PM
> To: Sigurbjörn Birkir Lárusson
> Cc: cisco-nsp@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@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@googlemail.com" <gal.9430@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@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, etcS 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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

*** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice ***


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
dfarrell at tibus
May 23, 2012, 10:16 PM
Post #24 of 44 (15178 views)
Permalink
On 23/05/2012 20:27, Phil Mayers wrote:
> If you don't enable portfast, you have to suffer the STP state
> transitions, which lead to delays in traffic forwarding after link-up.
I wondered what people's feelings/experiences were with respect to
completely disabling STP where appropriate?

I have 100% control over topology and some PtP dotq trunk links, I
thought of placing 'spanning-tree bpdufilter enable' rather than
'portfast trunk' on these ports. I have no need to to send or receive
STP BPDUs on these ports, even though the underlying technology is
Ethernet. Hosts are a mixture of L3 switches and routers, but
configuration should limit the extent of the broadcast domains in
question to exist only on the PtP link.

Cheers,

David.

--
DAVID FARRELL
IP Engineer
Tibus
Hosting& Connectivity

Follow us on Twitter: http://twitter.com/tibus

T: +44 (0)28 9033 1122
F: +44 (0)28 9042 4709
E: dfarrell@tibus.com
W: www.tibus.com | www.tibushost.com | www.tibusconnect.com

Tibus is a trading name of The Internet Business Ltd, a company limited by share capital and registered in Northern Ireland, NI31235. It is a part of UTV Media Plc.

This e-mail and any attachment may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorised to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: Lot of input errors on a NPE-G1 interface [ In reply to ]
gal.9430 at googlemail
May 23, 2012, 10:49 PM
Post #25 of 44 (15167 views)
Permalink
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@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@googlemail.com" <gal.9430@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@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@puck.nether.net
>>>[mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of
>>>gal.9430@googlemail.com
>>> Sent: Wednesday, May 23, 2012 5:00 PM
>>> To: Sigurbjörn Birkir Lárusson
>>> Cc: cisco-nsp@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@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@googlemail.com" <gal.9430@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@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@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
1 2  View All

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal