Skip navigation
Cisco Learning Home > CCNP R&S Study Group > Discussions
This Question is Answered
22991 Views 5 Replies Latest reply: Aug 25, 2010 8:22 PM by IntegrationArchitect RSS

Currently Being Moderated

Broadcast Storm

Aug 25, 2010 4:37 PM

mickey61 75 posts since
Nov 3, 2009

What is the best way to finding what is causing a broadcast storm. Or better yet how would you began to trouble shoot and isolate the issue.

  • Paul Stewart  -  CCIE Security, CCSI 6,956 posts since
    Jul 18, 2008
    Currently Being Moderated
    1. Aug 25, 2010 5:00 PM (in response to mickey61)
    Re: Broadcast Storm

    If you have cam table instability and see frames multiple times, you likely have a loop.  If that is the case, I would investigate for areas of your layer two network that does not have spanning-tree enabled.

  • Paul Stewart  -  CCIE Security, CCSI 6,956 posts since
    Jul 18, 2008
    Currently Being Moderated
    3. Aug 25, 2010 6:15 PM (in response to mickey61)
    Re: Broadcast Storm

    If it is a hub connected to multiple enterprise switch segments, it can forward bpdu's.  So if the enterprise switch is producing bpdu's, it should break the loop.  Now if you had a hub or switch connected to a single port on the enterprise switch, it would also produce a loop.  If there was no way to break that loop, any frame that would be flooded or switched back into the enterprise network would cause a broadcast storm.  However, the storm would be limited to the capacity of the enterprise switch port that it is connected to.  In other words, the frames would not loop inside the enterprise switch network, but duplicates could be presented from the rogue device.

  • caosorio_01 2 posts since
    Jul 12, 2010
    Currently Being Moderated
    4. Aug 25, 2010 7:03 PM (in response to mickey61)
    Re: Broadcast Storm

    Hello:

     

    The best aproach for troubleshooting will be to isolate the problem to  a determined group of switches, i will go directly into the core part of the network and start with the comand:

     

    #sho mac address-table  / sho mac-address-table (depending on the IOS).

     

    From there you will note some duplicates over certain ports, that will lead you to section of the network where the problem is located.

     

    Once you find out the access layer switch that is giving you more of the MAC adresses repeated over its port, i belive you can start checking out phisically on the user side to verify there is no rogue device attached to it.

     

    Also try to keep record if the issue is being presented at a certain time of the day.

     

    Even though i believe that the Spanning tree portion of the switch affected will take care of the broadcast storm getting into the core / distribiution part of your network.

     

    BTW. try to enable some kind of port security at the access level so it will block those troubled ports.

     

    Try to verify any errdsbl state ports also, and if you are allowed set some SNMP traps to detect any errors.

     

     

     

    Any how the problem will be limited by some group of users screaming out at you via the phone... LOL

     

    Hope this helps out.

     

    Caosorio_01

  • IntegrationArchitect 1,126 posts since
    Aug 14, 2009
    Currently Being Moderated
    Re: Broadcast Storm

    In a properly configured core and workgroup switch environment, the Broadcast Storm from the beaconing rouge hub would be contained within the switch port.  The switch impacted would have to deal with the chatter from a CPU perspective too so that could slow things down on other switchports on that switch.

    .

    The switch could also have default Cisco STP loop guard feature or UniDirectional Link Detection (UDLD) loop detection IOS features disabled manually that could storm scenarios if two ports on the dumb hub were both connected to switchports in the same switch or chassis or to a pair of switches making a triangle.

     

    In switch config, look for "uplinkfast or portfast" on a given switchport and if you can validate the cable is actually ngt going to minihub. See link below

     

    However I have seen very dumb hubs from Netgear or Linksys actually self correct and disable a port when two ports are connected to the same switch.  So this scenario could be a defective hub that is beaconing  that is a low cost hub that should be thrown in the trash bin.  The MAC of the hub could be found with a probe easily if it's beaconing because it would flood the network with the same MAC all the time. and then the hub could be isolated as mentioned above.

    -----

     

    So it could also be a misbehaving NIC adapter on a single PC crying out for help and beakoning please replace me!   Or the PC could have malware virus trying to copy itself to any unprotected location that it can via known exploits.

     

    ----

    Finally, if you have a miniswitch that has several MACs showing when a "switchport mode access" is configured on the Cisco switch (there should be only one MAC)  and one of the MACs is being flooded then you found your problem.

     

    ref http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800b1500.shtml

Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)