I've been enrolled to "Implementing Cisco Data Center Infrastructure (DCII) v6.2" course as part of work training. The DCII series will track my notes from the course. These have also been posted on Twitter (@dotonebit).
Rapid PVST+ Overview:
• RPVST+ is the default STP mode on Cisco Nexus switches
• + sign indicates Cisco proprietary implementation
• Nexus also supports MST
• Nexus will not run non-rapid version of STP but can support interoperability with switches running 802.1D
MST Overview:
• main purpose is to reduce STP instances to the number of active paths available (also enables load balancing)
• uses (standard) RSTP mechanisms
• backwards-compatible with other STP forms
• VLANs are mapped to MST instances (number in Ext Sys ID field)
MST Regions:
• switches must have the same name, revision number, and VLAN association table
• only a digest of the VLAN-to-instance mapping, along with the revision number and name, are sent in a BPDU
• the digest is used to identify switches in the same region
NOTE: The configuration revision number gives you a method of tracking the changes in the MST region but it does not automatically increase. Each time that you make a change, you should manually increase the revision number by 1.
Nexus STP Options:
• STP edge port (previously known as PortFast): configures access port to transition directly to forwarding state
• BDPU guard: disables STP edge port feature when a port receives a BPDU
• BPDU filter: suppresses BPDUs on ports
• Root guard: prevents unintended switches from becoming root
• Loop guard: prevents an alternate port from becoming the designated port if switch does not receive BPDUs
• Bridge assurance: prevents bridging loops caused by STP failures
STP edge port:
• formerly known as PortFast
• bypass listening and learning states and enter the forwarding state immediately
• does not generate topology changes when the link state changes
• should only be used on access ports
BPDU Filter:
• stops sending and receiving of BPDUs (effectively disables STP)
• example: you might see BPDU filter in company networks that have multiple administrators or service providers who provide Layer 2 access for customers and they don’t want to share STP info
BPDU Guard:
• STP edge ports will listen for BPDUs
• if a BPDU is received on an STP edge port, BDPU guard will put it into an error-disabled state (must be shut down and re-enabled or automatically recovered)
• BDPU guard should be enabled on all STP edge ports
Root Guard:
• some switches should never become STP root bridge
• enable root guard on all ports where the root bridge is not anticipated
• if a port that has root guard enabled receives a superior BPDU, it will go into root-inconsistent state
Protecting against loops:
• if a blocking port no longer receives BPDUs (due to send/receive fails), the switch starts transitioning it to the forwarding state ➡️ this creates a loop
• three mechanisms to protect agains loops: loop guard, bridge assurance, and UDLD
Loop Guard:
• if BPDUs are not received in a non-designated port, that port is moved to the STP loop-inconsistent blocking state (instead of the designated forwarding state)
• when BDPUs are received again, the port is removed from the loop-inconsistent state automatically
Bridge Assurance:
• applicable to RPVST+ and MST
• the port always sends BPDUs regardless of its role
• BPDUs essentially become a hello mechanism (if no BDPUs ➡️ blocking)
• not supported on all platforms
• do not use both bridge assurance (preferred) and loop guard
UDLD:
• not dependent on STP
• the port periodically transmits UDLD packets ➡️ if the packets are not echoed back in specific time, the link is flagged as unidirectional and the port is error-disabled
• recommended: use both UDLD and bridge assurance (or loop guard)
Rapid PVST+ Overview:
• RPVST+ is the default STP mode on Cisco Nexus switches
• + sign indicates Cisco proprietary implementation
• Nexus also supports MST
• Nexus will not run non-rapid version of STP but can support interoperability with switches running 802.1D
MST Overview:
• main purpose is to reduce STP instances to the number of active paths available (also enables load balancing)
• uses (standard) RSTP mechanisms
• backwards-compatible with other STP forms
• VLANs are mapped to MST instances (number in Ext Sys ID field)
MST Regions:
• switches must have the same name, revision number, and VLAN association table
• only a digest of the VLAN-to-instance mapping, along with the revision number and name, are sent in a BPDU
• the digest is used to identify switches in the same region
NOTE: The configuration revision number gives you a method of tracking the changes in the MST region but it does not automatically increase. Each time that you make a change, you should manually increase the revision number by 1.
Nexus STP Options:
• STP edge port (previously known as PortFast): configures access port to transition directly to forwarding state
• BDPU guard: disables STP edge port feature when a port receives a BPDU
• BPDU filter: suppresses BPDUs on ports
• Root guard: prevents unintended switches from becoming root
• Loop guard: prevents an alternate port from becoming the designated port if switch does not receive BPDUs
• Bridge assurance: prevents bridging loops caused by STP failures
STP edge port:
• formerly known as PortFast
• bypass listening and learning states and enter the forwarding state immediately
• does not generate topology changes when the link state changes
• should only be used on access ports
BPDU Filter:
• stops sending and receiving of BPDUs (effectively disables STP)
• example: you might see BPDU filter in company networks that have multiple administrators or service providers who provide Layer 2 access for customers and they don’t want to share STP info
BPDU Guard:
• STP edge ports will listen for BPDUs
• if a BPDU is received on an STP edge port, BDPU guard will put it into an error-disabled state (must be shut down and re-enabled or automatically recovered)
• BDPU guard should be enabled on all STP edge ports
Root Guard:
• some switches should never become STP root bridge
• enable root guard on all ports where the root bridge is not anticipated
• if a port that has root guard enabled receives a superior BPDU, it will go into root-inconsistent state
Protecting against loops:
• if a blocking port no longer receives BPDUs (due to send/receive fails), the switch starts transitioning it to the forwarding state ➡️ this creates a loop
• three mechanisms to protect agains loops: loop guard, bridge assurance, and UDLD
Loop Guard:
• if BPDUs are not received in a non-designated port, that port is moved to the STP loop-inconsistent blocking state (instead of the designated forwarding state)
• when BDPUs are received again, the port is removed from the loop-inconsistent state automatically
Bridge Assurance:
• applicable to RPVST+ and MST
• the port always sends BPDUs regardless of its role
• BPDUs essentially become a hello mechanism (if no BDPUs ➡️ blocking)
• not supported on all platforms
• do not use both bridge assurance (preferred) and loop guard
UDLD:
• not dependent on STP
• the port periodically transmits UDLD packets ➡️ if the packets are not echoed back in specific time, the link is flagged as unidirectional and the port is error-disabled
• recommended: use both UDLD and bridge assurance (or loop guard)
Comments
Post a Comment