Wired Intelligent Edge

 View Only
last person joined: yesterday 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

STP - broadcast storm (loop)

This thread has been viewed 26 times
  • 1.  STP - broadcast storm (loop)

    Posted Aug 17, 2022 11:29 AM
    I understand STP prevents topology loops or loops that are created by topology changes, failed links, config mistakes in trunk links  in a fully meshed topology.
    However, Will STP prevent a network loop(or broadcast storm) created by user error, on the edge ports? Like connecting two ends of a cable into two wall jacks. (or VoIP Phone - one jack to the phone and other jack again to the phone)  ? My answer would be "no" because no topology change occurs during a broadcast storm. STP ports will keep receiving the BPDUs and will keep the topology the same and the network will go down.
    Do you Agree/Disagree , and why ?

  • 2.  RE: STP - broadcast storm (loop)

    Posted Aug 18, 2022 02:00 AM

    STP will prevent a network loop that was created on the edge ports in most of the cases. When the switch starts every port is waiting for STP BPDUs for 3 seconds. If no BPDUs are received on the port it is assumed that and end device resides there, it transitions to edge port and goes in forwarding state. Every edge port continues sending out STP BPDUs every 2 seconds.  As soon as an edge port starts receiving BPDUs it will automaticaly transition to non-edge port and this will also trigger an STP topology change. In the scenarios you described the switch will start receiving its own BPDUs on both ports as soon as the loop is created. Both ports will transition to non-edge. The switch will put one of the ports - the one with lower priority in discarding state and this will prevent the loop. The port will remain in discarding state for as long as the switch is receiving the BPDUs on it.
    This is the reason why it is generally recommended to enable STP even if you don't have separate redundant links (meshed links) between switches which could create a loop. For example when all you uplinks are link-aggregations. STP can be used simply for preventing local loops.

    This will not work only if the device which creates the loop -for example the VOIP phone from your example or some cheap unmanaged switch drops the STP BPDUs for some reason while forwarding all other broadcast/multicasts between both ports. In such case STP cannot recognize the loop indeed.
    STP may also fail to detect loops through edge ports that enforce port-access authentication like 802.1x, mac-auth. In port-access user mode the port will only accept incoming packets with source MAC of the authenticated user and may drop STP BPDUs.
    For this reason on Aruba switches you can have loop-protect on the edge ports as an additional protection against local loops.

  • 3.  RE: STP - broadcast storm (loop)

    Posted Sep 19, 2022 10:48 AM
    Thank you for the quick response.
    I understand now, all ports continue to send out BPDUs every 2 secs , regardless of their state. Default auto-edge-port and continuous BPDU transmission will block the loop when the switch receives its own bpdu.  Otherwise I would think of configuring bpdu-guard which would prevent the loop by disabling the port(s) once it receives its own bpdu. I would never think a port in port-fast state would continue transmitting bpdu packets.

    Is there a way to enable bpdu-guard on the interface without enabling STP globally? Will it work, will it disable the port if it receives any bpdu? Looks like conf takes it but not sure if it will work ?

    interface 1/1/1
    no shutdown
    no routing
    vlan access 1
    spanning-tree bpdu-guard
    TEST-SWITCH(config)# exit
    TEST-SWITCH# sh spanning-tree int 1/1/1
    Spanning-tree is disabled