2

We have an unknown device causing broadcast storms on the network. I have applied storm control to ever single access port in the location, and yet the broadcast storm exists. I was wondering if I could apply Storm Control to an trunking interface to protect that switch by simply filtering excess broadcasts. So I setup storm control as follows

interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 storm-control broadcast level pps 1k 100
end

I then cleared the interface counters and checked the interface stats

show interface g0/1
GigabitEthernet0/1 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 0019.e781.b981 (bia 0019.e781.b981)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 2/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 00:00:00, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:00:04
  Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 8188000 bits/sec, 10874 packets/sec
  5 minute output rate 5000 bits/sec, 3 packets/sec
     43901 packets input, 4142320 bytes, 0 no buffer
     Received 43855 broadcasts (0 multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 43763 multicast, 0 pause input
     0 input packets with dribble condition detected
     33 packets output, 4676 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

So its been 4 seconds, and I've already got 43855. That was WAY above the 1,000 packets limit I set. However, it doesn't seem to care about filtering at all and just keeps forwarding/processing the traffic.

show storm-control g0/1
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Gi0/1      Forwarding         1k pps      100 pps       13 pps
show storm-control g0/1
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Gi0/1      Forwarding         1k pps      100 pps       29 pps

Does encapsulation prevent storm control from working? Does storm control simply not work on trunking ports? I'm worried that storm control might not be in effect at all on any of the switches, despite having it enabled.

Improve this question
6
  • a) what switch(es) are you working with? (models, blades, etc.) b) what exactly are the broadcasts? (arp?)
    – Ricky
    Commented Oct 23, 2014 at 22:46
  • @Ricky A) Working a wide variety of Cisco Switches, the switch in question is a WS-C3560-48PS running IOS 12.2(25)SEE2. B)I am unsure what of the broadcasts are at the moment. I will try and identify and get back to you.
    – iargue
    Commented Oct 23, 2014 at 22:58
  • In one place it's "0 multicast", but in the rx stats, it's clear they're all multicast. The best I can tell, BPDUs bypass storm-control, but cisco is very inconsistent across the various lines (and IOS releases)
    – Ricky
    Commented Oct 23, 2014 at 23:00
  • @Ricky We have spanning tree and bpdu protection on every access port, so i wouldn't say its BPDU's. When I am onsite tomorrow morning, I will do a wireshark packet capture from an access point to identify the storm (I did one earlier, but now I realize it had the wrong vlan on it). We have broadcast and multicast filtering on every access port, but only on the trunking port did I did broadcast (Because multicast will block all traffic, and I am working remotely). Every single access port is reporting 0.00% for storm-control.
    – iargue
    Commented Oct 23, 2014 at 23:06
  • Also, CDP doesn't get blocked.
    – Ricky
    Commented Oct 24, 2014 at 2:31

2 Answers 2

Reset to default
2

Try enabling "storm control multicast level pps 1k 100" and enable the action when the level you just configured is reached: "storm-control action {shutdown | trap}"

Improve this answer
1
  • I can't do multicast on the trunk port while I am working remotely, as if it does block it, it will prevent me from accessing that switch. However I do have multicast filtering and shutdown on every access point in the network with no change in the level of broadcasting. Every single port is reporting broadcast below that level. I will test multicast tomorrow morning, but I am sure that won't make a difference.
    – iargue
    Commented Oct 24, 2014 at 3:10
1

The answer to this question, in case someone comes across this from a google search, is that the multicast packets were IPv6, called by a bad HP driver that spammed the network when the devices went to sleep. Storm control does not protect from ipv6 multicast spam, and so it was not registering this packets are being broadcast/multicast traffic.

Improve this answer
1
  • You should accept your answer so that the question doesn't keep popping up forever, looking for an answer.
    – Ron Maupin ♦
    Commented May 8, 2017 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.