While configuring STP in Datacenter on Nexus devices its good to keep in mind the following things to consider.
Spanning-Tree Protocol (STP) Mode
The RSTP (IEEE 802.1w) standard to be implemented on a per VLAN basis, which means that a single instance of STP runs on each configured VLAN. Each RSTP instance has a single root switch. STP can be enabled and disabled on a per-VLAN basis when running RSTP.
Spanning-Tree Port Type
Network ports are connected only to switches or bridges. Configuring a port as "network" while Bridge Assurance is enabled globally (by default) enables Bridge Assurance on that port.
In terms of configuration, in the NX-OS devices all ports can be configured by default to either “network” or “edge”:
• Default port type “edge” will be typically configured on the access layer, and only uplinks will be configured to a different port type (normal or network)
• Default port type “network” will be typically configured at the aggregation layer, and only links to switches that do not support “network” type will be configured as “normal”
STP network port configuration can be done globally or a per interface basis.
BA is a feature that provides additional protection in environments running the Spanning Tree Protocol (STP). BA works by forcing a bridge to send BPDUs on a “network” port, even if that port is not a designated port. Consequently, a bridge expects to receive BPDUs on a “network” port, even if it is the designated bridge.
If a Bridge Assurance-enabled network port does not receive any BPDU for a configurable period of time, the interface moves into the blocking state. After the network port receives a BPDU again, the port begins its normal spanning tree transitions.
Bridge Assurance is similar in many ways to the Loop Guard feature, which has been available for many years on other platforms. The main weakness of Loop Guard is that it needs to receive at least one BPDU to detect a peer. Bridge Assurance does not suffer from this issue as the existence of the peer is identified by configuration.
Bridge Assurance is enabled by default on all ports of type ‘Network’. Bridge Assurance requires both ends to be enabled for the feature – the port will not function if one end only supports it.
Cisco recommends enabling Bridge Assurance, with the following notes taken into account:
• Bridge Assurance should not be enabled when only one end of a link supports the feature. This will result in the link being blocked on the other end
• Bridge Assurance runs only on point-to-point spanning tree network ports
• On the Catalyst 6500s, support for Bridge Assurance has been introduced in IOS release 12.2(33)SXI.
• Bridge Assurance is configured at the time of deploying a new network link. No changes are required when adding or removing VLANs to the link
• Bridge Assurance blocks ports per VLAN. When adding a new VLAN to a port, the following message may be displayed “STP-2-BRIDGE_ASSURANCE_BLOCK: Bridge Assurance blocking port <port> VLAN<vlanid>”
Bridge assurance does not catch individual member failure in a channel, but it protects STP and prevents loops, even over a port channel. The trick is that BA will only detect the failure of the member transmitting BPDUs. If another member fails, then it's not BA's problem and LACP or UDLD will be needed to prevent the resulting black-holing situation.
Spanning Tree Root Placement
Spanning tree root placement is very important to deterministically allocate troubleshooting and switch resource. The STP priority is manipulated to achieve this.
Root and backup root can be hard coded. All Access layer switches to stay at the default STP priority, 32768. In case that Satellite switches are used, they will be configure with a STP priority of 61440, so they will never become root of STP under any circumstance.
Similar configuration of spanning tree will be in place for every deliverable. Leaving the Spanning tree root priorities at the default for the Access layer switches is the most common practices. (32768). The Aggregation switches will be STP root and standby root for all vlan ranges.
Spanning Tree Loopguard
Loop Guard can be enabled only on network and normal spanning tree port types. Bridge Assurance contains a superset of the features of Loopguard and enabling both of them on any given link is redundant. Therefore, Loopguard should be enabled on all Network ports in Datacenters where bridge assurance is not supported. When the solution is based on a fully Nexus switching architecture then no LoopGuard must be configured anywhere.
When the solution is based on a mix of devices that do not support Bridge Assurance, LoopGuard will have the main role regarding preventing Layer 2 loops on the network.
Spanning-Tree Path Costs
There are 2 methods for the STP path-cost calculation:
• The long path-cost calculation method, which uses all 32 bits available for path-cost calculations. The value range is 2 through 2,000,000,000
• The short path-cost calculation method, which uses 16 bits for path-cost calculation. The value range is 1 through 65535
The pathcost calculation method is configured globally, and used for all processes on the switch. It is recommended to apply a consistent pathcost method within the same STP domain. Using the Pathcost method long across the entire Datacenter is recommended.
Spanning Tree BPDU Guard
In the Access Layer of the network the ports connecting to end hosts are not expected to receive BPDUs. The BPDU Guard feature will be enabled on these ports. Use BPDU Guard only on access-switches and Service Appliances ports located at Aggregation Switches.
BPDU Guard should be configured globally and per interface because when enabled globally BPDU Guard applies to all interfaces that are in an *operational* Port Fast state. If the interface is not in an operational Port Fast state (i.e. it already received a BPDU) the BPDU Guard could have some problems. Configuring it both ways workarounds any possible issues regarding the feature.
Spanning Tree Root Guard
Root Guard prevents a port from becoming a root port (a port on the path to the root bridge). A port that receives better information from its neighbor is put in the discarding state, if this feature is enabled. Configuring Root Guard on the aggregation ports that connect to the access will help to isolate an access bridge claiming to be the root.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.