Broadcast Storm Cisco switch commands

It depends on what was the cause of a broadcast storm...
Not sure if the next helps: Spanning tree is meant prevent broadcast storms due to misconfiguration & network loops.

Hi,

There was a 4 port unmanaged switch, someone plugged both ends of a cable causing a loop. In running the command above, concerned about the line that says -   Received 1071365 broadcasts (517836 multicasts), is that something normal or do we need to investigate.

Thanks,

Interesting.   STP on the Cisco should have detected the loop and blocked one of the two ports.  Unless the unmanaged switch was filtering BPDU's.

But beyond that, the only other thing I can think of is storm control (which may or may not be available on your switch/IOS version).

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_53_se/configuration/guide/3750xscg/swtrafc.html

Hi All,

Thanks, we are re-configuring our switches to ensure its set up correctly and have the proper safeguards going forward.

The second part of my question is when I run the command - show interface | include (.*Ethernet)|(.*broadcast)  , I get the below output on multiple ports. I traced this particular port to an APC unit, should we be concerned that it received 1021365 broadcasts or is it normal. Our network is not being affected now, but still getting the output below.

GigabitEthernet3/0/47 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is f8a5.c5bd.ab2f (bia f8a5.c5bd.ab2f)
     Received 1071365 broadcasts (517836 multicasts)

Number of broadcasts is not significant unless compared with the total number of frames.  For example, 1,000,000 broadcasts with 5,000,000,000,000 total frames is almost no broadcasts.  But 1,000,000 broadcasts with 10,000,000 total frames is a lot of broadcasts.

Post the full output of the interface.

Hi,

Please set int below

9thData#sh int gi3/0/47
GigabitEthernet3/0/47 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is f8a5.c5bd.ab2f (bia f8a5.c5bd.ab2f)
  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, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 00:00:49, 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 0 bits/sec, 0 packets/sec
  5 minute output rate 25000 bits/sec, 18 packets/sec
     1553767 packets input, 279998554 bytes, 0 no buffer
     Received 1072929 broadcasts (519234 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 519234 multicast, 0 pause input
     0 input packets with dribble condition detected
     4192478520 packets output, 338478784747 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 pause output
     0 output buffer failures, 0 output buffers swapped out

Hi Don,

Now that you said that, what I just did is clear the counters and check, it could be related to the broadcast storm issue we had never cleared the counters, going monitor over the next day.

Also, maybe hard to tell, but I have a question, when the broadcast issue happened we shut the port down that was reporting errors, and it was 4 port switch at a workstation with network cable both ends plugged into the switch. However part of our trying to figure out how it happened is
 1. someone plugged it in at that time and started it
 2. the cable was always plugged in at some point and broadcast was kept in check by stp
however, on that particular day, there was a high volume scanning done and caused the issue to escalate

I know it fishing but just trying to figure out what happened and prevent it, as well were working with vendors to review our config and make necessary changes.

Was STP actually configured on the ports...,  in that case the port should become blocked for ALL traffic, not just broadcast storms, and it should not become alive again unless the other port got disconnected.
The blocking would occur on the first BDPU received in a loop.  (aka  a switch receives it's own BDPU sent on one port on another port).
(converging to a stable state would be fast if Fast Spanning Tree would be used).

Hi,

Below is the output from the int. Assuming that spanning-tree portfast is on based on the output.

interface GigabitEthernet3/0/39
 switchport access vlan 10
 switchport voice vlan 20
 spanning-tree portfast

spanning-tree portfast does not disable spanning tree BUT

When a the interface starts then it assumed to be correct and immediately starts forwarding packets..,
without portfast a slight delay will occur (30 seconds timeout) before the port starts forwarding packets (aka working).

This will allow a trickle of broadcasts (storms) on every cable insert/removal or powerup of the device connected to the port.

Hi All,

Thank you for all your input, very helpful. Were moving offices and re-doing all our switches vlans, etc.

Thank you.