Mailing List Archive

storm-control errdisable with no traffic or vlan
I have a vendor trying to turn up a 10gb link from their juniper mx to a
cisco 4900M, using typical X2 LR.

The link was being upgraded from a functioning 1gb. Same traffic.

Even with switchport mode trunk and switchport allowed vlan none, with
input counters in single digits, storm control immediately takes the
port down after link up. There was negligible traffic on the link before
or after the attempt.

Vendor's best idea is to turn off storm control, which I am only going
to do with an isolated switch on site, anyone seen anything like this or
have any other ideas?

Joe
_______________________________________________
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: storm-control errdisable with no traffic or vlan [ In reply to ]
On Thu, 4 Aug 2022 at 02:06, Joe Maimon via cisco-nsp
<cisco-nsp@puck.nether.net> wrote:

> I have a vendor trying to turn up a 10gb link from their juniper mx to a
> cisco 4900M, using typical X2 LR.
>
> The link was being upgraded from a functioning 1gb. Same traffic.

10G will serialise packets 10x faster. Even if the average packet rate
is the same, you can have a 10x faster traffic rate on smaller
sampling intervals, which may exceed configured protection rates.

> Even with switchport mode trunk and switchport allowed vlan none, with
> input counters in single digits, storm control immediately takes the
> port down after link up. There was negligible traffic on the link before
> or after the attempt.

Broadcast, multicast or unicast storm-control? What rate? Have you
tried increasing the rate? Can you provide the logs of storm-control
taking the port down?

--
++ytti
_______________________________________________
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: storm-control errdisable with no traffic or vlan [ In reply to ]
Hi,

On Wed, Aug 03, 2022 at 07:05:59PM -0400, Joe Maimon via cisco-nsp wrote:
> Even with switchport mode trunk and switchport allowed vlan none, with
> input counters in single digits, storm control immediately takes the
> port down after link up. There was negligible traffic on the link before
> or after the attempt.
>
> Vendor's best idea is to turn off storm control, which I am only going
> to do with an isolated switch on site, anyone seen anything like this or
> have any other ideas?

Make the port a routed port (= ingress packets go nowhere), set up
a SPAN session, find out what sort of packets are coming in (broacast,
multicast, unknown-unicast) and how many of them. Adjust limits,
as ytti said.

While I agree to "have storm-control anywhere" - if this is intended
to be a routed link, limits can be fairly high (the only reason why
you want storm-control is to protect the 4900M's CPU, not anything
else in the network).

OTOH, a 4900M? really?

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: storm-control errdisable with no traffic or vlan [ In reply to ]
Gert Doering wrote:
> Hi,
>
>
> Make the port a routed port (= ingress packets go nowhere), set up
> a SPAN session, find out what sort of packets are coming in (broacast,
> multicast, unknown-unicast) and how many of them. Adjust limits,
> as ytti said.

Interesting approach, even if not sure it will get anywhere on this one.
>
> While I agree to "have storm-control anywhere" - if this is intended
> to be a routed link, limits can be fairly high (the only reason why
> you want storm-control is to protect the 4900M's CPU, not anything
> else in the network).

10k is typical value I use for network protection purposes, anything
serious is gonna exceed that in a heartbeat.

>
> OTOH, a 4900M? really?
>
> gert
>
1) 200-300 used
2) 8 onboard X2, 2 slots for modules for 4/8 X2, 8port X2 modules
support twingig, or 20 GigT, or 8 10gT (those are pricey)
3) 4500 platform vs. 3xxx
4) no licensing subscriptions
5) Software only 4 years old

Cisco IOS Software, Catalyst 4500 L3 Switch Software
(cat4500e-ENTSERVICESK9-M), Version 15.2(4)E7, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2018 by Cisco Systems, Inc.
Compiled Tue 18-Sep-18 13:49 by prod_rel_team

6) 2U, Dual PS, external CF, 4 post mounting
7) Rock stable.

uptime is 3 years, 27 weeks, 23 hours, 5 minutes


There are plenty of places left for gear like this, especially as CPE
and especially considering the alternatives I see people putting in.

If you got suggestions for gear less than 4figures with similar or
better qualities, I am all ears.

Joe
_______________________________________________
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: storm-control errdisable with no traffic or vlan [ In reply to ]
Thanks for responding. I was looking for a controller like command to
see maybe there were some malformed frames or something, but couldnt
find one on this platform.



Saku Ytti wrote:
> On Thu, 4 Aug 2022 at 02:06, Joe Maimon via cisco-nsp
> <cisco-nsp@puck.nether.net> wrote:
>
>> I have a vendor trying to turn up a 10gb link from their juniper mx to a
>> cisco 4900M, using typical X2 LR.
>>
>> The link was being upgraded from a functioning 1gb. Same traffic.
GigabitEthernet2/21 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 588d.xxxx.a8f8 (bia
588d.xxxx.a8f8)
Description: Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
MTU 9198 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 auto, media type is 1000BaseLH
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 263000 bits/sec, 147 packets/sec
30 second output rate 663000 bits/sec, 201 packets/sec
5900382712 packets input, 1369541098917 bytes, 0 no buffer
Received 100294521 broadcasts (100294050 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
7240868168 packets output, 6306357851288 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

interface GigabitEthernet2/21
description Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
switchport trunk allowed vlan 1660-1679
switchport trunk native vlan 1001
switchport mode trunk
switchport nonegotiate
switchport port-security maximum 100
switchport port-security aging time 3
switchport port-security aging type inactivity
switchport port-security
mtu 9198
load-interval 30
no cdp enable
storm-control broadcast level pps 10k
storm-control action shutdown
spanning-tree portfast edge


>
>> Even with switchport mode trunk and switchport allowed vlan none, with
>> input counters in single digits, storm control immediately takes the
>> port down after link up. There was negligible traffic on the link before
>> or after the attempt.
> Broadcast, multicast or unicast storm-control? What rate? Have you
> tried increasing the rate? Can you provide the logs of storm-control
> taking the port down?

Gobs of this

Aug 2 22:18:22: %PM-4-ERR_DISABLE: storm-control error detected on
Te1/3, putting Te1/3 in err-disable state
Aug 2 22:18:22: %STORM_CONTROL-3-SHUTDOWN: A packet storm was detected
on Te1/3. The interface has been disabled.
Aug 2 22:19:07: %PM-4-ERR_RECOVER: Attempting to recover from
storm-control err-disable state on Te1/3
Aug 2 22:19:10: %PM-4-ERR_DISABLE: storm-control error detected on
Te1/3, putting Te1/3 in err-disable state

Tried another X2

Aug 2 22:31:33: %C4K_IOSINTF-5-TRANSCEIVERREMOVED: Slot=1 Port=3:
Transceiver has been removed
Aug 2 22:31:48: %C4K_IOSINTF-5-TRANSCEIVERINSERTED: Slot=1 Port=3:
Transceiver has been inserted
Aug 2 22:31:50: %SFF8472-5-THRESHOLD_VIOLATION: Te1/3: Tx power low
alarm; Operating value: -40.0 dBm, Threshold value: -12.2 dBm.
Aug 2 22:32:09: %SYS-5-CONFIG_I: Configured from console by joe on vty0
(216.222.148.103)
Aug 2 22:32:14: %PM-4-ERR_RECOVER: Attempting to recover from
storm-control err-disable state on Te1/3
Aug 2 22:32:17: %PM-4-ERR_DISABLE: storm-control error detected on
Te1/3, putting Te1/3 in err-disable state
Aug 2 22:32:17: %STORM_CONTROL-3-SHUTDOWN: A packet storm was detected
on Te1/3. The interface has been disabled.

Tried another port

Aug 2 22:52:05: %C4K_IOSINTF-5-TRANSCEIVERINSERTED: Slot=3 Port=1:
Transceiver has been inserted
Aug 2 22:52:08: %LINK-3-UPDOWN: Interface TenGigabitEthernet3/1,
changed state to up
Aug 2 22:52:08: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
on Te3/1. A packet filter action has been applied on the interface.
Aug 2 22:52:09: %LINEPROTO-5-UPDOWN: Line protocol on Interface
TenGigabitEthernet3/1, changed state to up
Aug 2 22:52:14: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
on Te3/1. A packet filter action has been applied on the interface.
Aug 2 22:52:17: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
on Te3/1. A packet filter action has been applied on the interface.
Aug 2 22:52:20: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
on Te3/1. A packet filter action has been applied on the interface.
Aug 2 22:52:23: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
on Te3/1. A packet filter action has been applied on the interface.

noc12sw15#sh int te1/3
TenGigabitEthernet1/3 is down, line protocol is down (notconnect)
Hardware is Ten Gigabit Ethernet Port, address is 6073.xxxx.ae82 (bia
6073.xxxx.ae82)
Description: Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
MTU 9198 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 10Gb/s, link type is auto, media type is No X2
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 1d11h, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
27 packets input, 1732 bytes, 0 no buffer
Received 26 broadcasts (26 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
12 packets output, 864 bytes, 0 underruns
0 output errors, 0 collisions, 5 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

TenGigabitEthernet3/1 is down, line protocol is down (notconnect)
Hardware is Ten Gigabit Ethernet Port, address is d48c.xxxx.ca50 (bia
d48c.xxxx.ca50)
MTU 9198 bytes, BW 10000000 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, 10Gb/s, link type is auto, media type is No X2
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 1d11h, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
42 packets input, 2688 bytes, 0 no buffer
Received 42 broadcasts (42 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
24 packets output, 1566 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

interface TenGigabitEthernet1/3
description Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
switchport trunk allowed vlan 1660-1679
switchport trunk native vlan 1001
switchport mode trunk
switchport nonegotiate
switchport port-security maximum 100
switchport port-security aging time 3
switchport port-security aging type inactivity
switchport port-security
mtu 9198
load-interval 30
no cdp enable
storm-control broadcast level pps 10k
storm-control action shutdown
no keepalive
no lldp transmit
no lldp receive
spanning-tree portfast edge
spanning-tree bpdufilter enable

interface TenGigabitEthernet3/1
mtu 9198
storm-control broadcast level pps 10k
!

Current light

Temperature Voltage Tx Power Rx Power
Port (Celsius) (Volts) (dBm) (dBm)
--------- ----------- ------- -------- --------
Gi2/21 26.5 3.26 -6.0 -28.2

At that time, light was -4 -6 or -6 -4

Joe
_______________________________________________
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: storm-control errdisable with no traffic or vlan [ In reply to ]
Are you sure packet based storm-control is even supported in the platform?

What does 'show storm-control' say?

It is interesting that all packets are multicast packets in the Ten
interfaces, but the packet count is so low, I don't think we can put a
lot of weight into it.

On Thu, 4 Aug 2022 at 13:52, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
> Thanks for responding. I was looking for a controller like command to
> see maybe there were some malformed frames or something, but couldnt
> find one on this platform.
>
>
>
> Saku Ytti wrote:
> > On Thu, 4 Aug 2022 at 02:06, Joe Maimon via cisco-nsp
> > <cisco-nsp@puck.nether.net> wrote:
> >
> >> I have a vendor trying to turn up a 10gb link from their juniper mx to a
> >> cisco 4900M, using typical X2 LR.
> >>
> >> The link was being upgraded from a functioning 1gb. Same traffic.
> GigabitEthernet2/21 is up, line protocol is up (connected)
> Hardware is Gigabit Ethernet Port, address is 588d.xxxx.a8f8 (bia
> 588d.xxxx.a8f8)
> Description: Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
> MTU 9198 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 auto, media type is 1000BaseLH
> input flow-control is off, output flow-control is off
> ARP type: ARPA, ARP Timeout 04:00:00
> Last input 00:00:00, output never, output hang never
> Last clearing of "show interface" counters never
> Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
> Queueing strategy: fifo
> Output queue: 0/40 (size/max)
> 30 second input rate 263000 bits/sec, 147 packets/sec
> 30 second output rate 663000 bits/sec, 201 packets/sec
> 5900382712 packets input, 1369541098917 bytes, 0 no buffer
> Received 100294521 broadcasts (100294050 multicasts)
> 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> 0 input packets with dribble condition detected
> 7240868168 packets output, 6306357851288 bytes, 0 underruns
> 0 output errors, 0 collisions, 3 interface resets
> 0 unknown protocol drops
> 0 babbles, 0 late collision, 0 deferred
> 0 lost carrier, 0 no carrier
> 0 output buffer failures, 0 output buffers swapped out
>
> interface GigabitEthernet2/21
> description Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
> switchport trunk allowed vlan 1660-1679
> switchport trunk native vlan 1001
> switchport mode trunk
> switchport nonegotiate
> switchport port-security maximum 100
> switchport port-security aging time 3
> switchport port-security aging type inactivity
> switchport port-security
> mtu 9198
> load-interval 30
> no cdp enable
> storm-control broadcast level pps 10k
> storm-control action shutdown
> spanning-tree portfast edge
>
>
> >
> >> Even with switchport mode trunk and switchport allowed vlan none, with
> >> input counters in single digits, storm control immediately takes the
> >> port down after link up. There was negligible traffic on the link before
> >> or after the attempt.
> > Broadcast, multicast or unicast storm-control? What rate? Have you
> > tried increasing the rate? Can you provide the logs of storm-control
> > taking the port down?
>
> Gobs of this
>
> Aug 2 22:18:22: %PM-4-ERR_DISABLE: storm-control error detected on
> Te1/3, putting Te1/3 in err-disable state
> Aug 2 22:18:22: %STORM_CONTROL-3-SHUTDOWN: A packet storm was detected
> on Te1/3. The interface has been disabled.
> Aug 2 22:19:07: %PM-4-ERR_RECOVER: Attempting to recover from
> storm-control err-disable state on Te1/3
> Aug 2 22:19:10: %PM-4-ERR_DISABLE: storm-control error detected on
> Te1/3, putting Te1/3 in err-disable state
>
> Tried another X2
>
> Aug 2 22:31:33: %C4K_IOSINTF-5-TRANSCEIVERREMOVED: Slot=1 Port=3:
> Transceiver has been removed
> Aug 2 22:31:48: %C4K_IOSINTF-5-TRANSCEIVERINSERTED: Slot=1 Port=3:
> Transceiver has been inserted
> Aug 2 22:31:50: %SFF8472-5-THRESHOLD_VIOLATION: Te1/3: Tx power low
> alarm; Operating value: -40.0 dBm, Threshold value: -12.2 dBm.
> Aug 2 22:32:09: %SYS-5-CONFIG_I: Configured from console by joe on vty0
> (216.222.148.103)
> Aug 2 22:32:14: %PM-4-ERR_RECOVER: Attempting to recover from
> storm-control err-disable state on Te1/3
> Aug 2 22:32:17: %PM-4-ERR_DISABLE: storm-control error detected on
> Te1/3, putting Te1/3 in err-disable state
> Aug 2 22:32:17: %STORM_CONTROL-3-SHUTDOWN: A packet storm was detected
> on Te1/3. The interface has been disabled.
>
> Tried another port
>
> Aug 2 22:52:05: %C4K_IOSINTF-5-TRANSCEIVERINSERTED: Slot=3 Port=1:
> Transceiver has been inserted
> Aug 2 22:52:08: %LINK-3-UPDOWN: Interface TenGigabitEthernet3/1,
> changed state to up
> Aug 2 22:52:08: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
> on Te3/1. A packet filter action has been applied on the interface.
> Aug 2 22:52:09: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> TenGigabitEthernet3/1, changed state to up
> Aug 2 22:52:14: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
> on Te3/1. A packet filter action has been applied on the interface.
> Aug 2 22:52:17: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
> on Te3/1. A packet filter action has been applied on the interface.
> Aug 2 22:52:20: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
> on Te3/1. A packet filter action has been applied on the interface.
> Aug 2 22:52:23: %STORM_CONTROL-3-FILTERED: A Broadcast storm detected
> on Te3/1. A packet filter action has been applied on the interface.
>
> noc12sw15#sh int te1/3
> TenGigabitEthernet1/3 is down, line protocol is down (notconnect)
> Hardware is Ten Gigabit Ethernet Port, address is 6073.xxxx.ae82 (bia
> 6073.xxxx.ae82)
> Description: Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
> MTU 9198 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
> reliability 255/255, txload 1/255, rxload 1/255
> Encapsulation ARPA, loopback not set
> Keepalive not set
> Full-duplex, 10Gb/s, link type is auto, media type is No X2
> input flow-control is off, output flow-control is off
> ARP type: ARPA, ARP Timeout 04:00:00
> Last input 1d11h, output never, output hang never
> Last clearing of "show interface" counters never
> Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
> Queueing strategy: fifo
> Output queue: 0/40 (size/max)
> 30 second input rate 0 bits/sec, 0 packets/sec
> 30 second output rate 0 bits/sec, 0 packets/sec
> 27 packets input, 1732 bytes, 0 no buffer
> Received 26 broadcasts (26 multicasts)
> 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> 0 input packets with dribble condition detected
> 12 packets output, 864 bytes, 0 underruns
> 0 output errors, 0 collisions, 5 interface resets
> 0 unknown protocol drops
> 0 babbles, 0 late collision, 0 deferred
> 0 lost carrier, 0 no carrier
> 0 output buffer failures, 0 output buffers swapped out
>
> TenGigabitEthernet3/1 is down, line protocol is down (notconnect)
> Hardware is Ten Gigabit Ethernet Port, address is d48c.xxxx.ca50 (bia
> d48c.xxxx.ca50)
> MTU 9198 bytes, BW 10000000 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, 10Gb/s, link type is auto, media type is No X2
> input flow-control is off, output flow-control is off
> ARP type: ARPA, ARP Timeout 04:00:00
> Last input 1d11h, output never, output hang never
> Last clearing of "show interface" counters never
> Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
> Queueing strategy: fifo
> Output queue: 0/40 (size/max)
> 5 minute input rate 0 bits/sec, 0 packets/sec
> 5 minute output rate 0 bits/sec, 0 packets/sec
> 42 packets input, 2688 bytes, 0 no buffer
> Received 42 broadcasts (42 multicasts)
> 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> 0 input packets with dribble condition detected
> 24 packets output, 1566 bytes, 0 underruns
> 0 output errors, 0 collisions, 3 interface resets
> 0 unknown protocol drops
> 0 babbles, 0 late collision, 0 deferred
> 0 lost carrier, 0 no carrier
> 0 output buffer failures, 0 output buffers swapped out
>
> interface TenGigabitEthernet1/3
> description Cxxxxxxxxx 12.KFxxxxxxxxxxxxxxx
> switchport trunk allowed vlan 1660-1679
> switchport trunk native vlan 1001
> switchport mode trunk
> switchport nonegotiate
> switchport port-security maximum 100
> switchport port-security aging time 3
> switchport port-security aging type inactivity
> switchport port-security
> mtu 9198
> load-interval 30
> no cdp enable
> storm-control broadcast level pps 10k
> storm-control action shutdown
> no keepalive
> no lldp transmit
> no lldp receive
> spanning-tree portfast edge
> spanning-tree bpdufilter enable
>
> interface TenGigabitEthernet3/1
> mtu 9198
> storm-control broadcast level pps 10k
> !
>
> Current light
>
> Temperature Voltage Tx Power Rx Power
> Port (Celsius) (Volts) (dBm) (dBm)
> --------- ----------- ------- -------- --------
> Gi2/21 26.5 3.26 -6.0 -28.2
>
> At that time, light was -4 -6 or -6 -4
>
> Joe



--
++ytti
_______________________________________________
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: storm-control errdisable with no traffic or vlan [ In reply to ]
Storm control pps is bugged on the 10g ports on the older 4900
platforms, 4948E , 4900M, sup6 platforms.

Use storm control percentage based on the 10g ports instead of PPS and
the problem won't happen.


On 8/3/2022 7:05 PM, Joe Maimon via cisco-nsp wrote:
> I have a vendor trying to turn up a 10gb link from their juniper mx to
> a cisco 4900M, using typical X2 LR.
>
> The link was being upgraded from a functioning 1gb. Same traffic.
>
> Even with switchport mode trunk and switchport allowed vlan none, with
> input counters in single digits, storm control immediately takes the
> port down after link up. There was negligible traffic on the link
> before or after the attempt.
>
> Vendor's best idea is to turn off storm control, which I am only going
> to do with an isolated switch on site, anyone seen anything like this
> or have any other ideas?
>
> Joe
> _______________________________________________
> 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: storm-control errdisable with no traffic or vlan [ In reply to ]
On Sat, 6 Aug 2022 at 05:27, Paul via cisco-nsp
<cisco-nsp@puck.nether.net> wrote:

> Storm control pps is bugged on the 10g ports on the older 4900
> platforms, 4948E , 4900M, sup6 platforms.

When you say 'bugged', what do you specifically mean? Do you mean the
platform can do PPS accounting in HW and there is DDTS or do you mean
the platform cannot do PPS accounting?
It is not given at all that the platform does PPS accounting, for
example much more modern JNPR paradise chip doesn't do it, while their
next-generation triton does it. And I know most Cisco pipeline gear
didn't do it either.

My guess would be that PPS is not supported by the hardware and
behaviour is undefined, and you would need to poke hardware to
understand what was actually programmed when you asked it to PPS, i.e.
it hasn't worked as desired in the 1GE either.

--
++ytti
_______________________________________________
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: storm-control errdisable with no traffic or vlan [ In reply to ]
On 2022-08-06 06:15, Saku Ytti via cisco-nsp wrote:
> On Sat, 6 Aug 2022 at 05:27, Paul via cisco-nsp
> <cisco-nsp@puck.nether.net> wrote:
>
>> Storm control pps is bugged on the 10g ports on the older 4900
>> platforms, 4948E , 4900M, sup6 platforms.
>
> My guess would be that PPS is not supported by the hardware and
> behaviour is undefined, and you would need to poke hardware to
> understand what was actually programmed when you asked it to PPS, i.e.
> it hasn't worked as desired in the 1GE either.

An aside, but an example of where this can go wrong...

I once came a-cropper of an Extreme X440 doing something interesting
with its configured broadcast/multicast limits; if you configured
'5000pps' as the storm-control limit, it would be divided by 1000 &
measured every millisecond, so in fact the "real limit" was 5 frames per
millisecond. This undocumented (at the time?) behaviour meant that any
ports with multiple VLANs - especially those carrying FHRP - would
immediately shutdown, because more than 5 multicast frames would be
received more or less together.

The alternative is, of course, to have a counter that can be read/reset
every second - but what if your ASIC can't do that?

Given the era of hardware, I do wonder if simply multiplying the
configured storm-control limit by 10 will be sufficient to elect the
exact same behaviour on the TE port. I'd hazard a guess that some bit of
code is dividing by ten, and that's why it can't do 'per second'
storm-control. I loved my 4900Ms muchly (gert is a big meanie) but I
must confess I don't think I ever had (nor wanted) a customer-facing L2
TenGig port.

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