CCNP SWITCH MST & STP SECURITY

Multiple Spanning Tree (MST)

Earlier in this guide, three versions of 802.1D STP were described:
• CST utilizes a single STP instance for all VLANs.
• PVST and PVST+ employ a separate STP instance for each VLAN.
PVST and PVST+ are more efficient, and allow STP to load balance
VLANs across links. This comes at a cost – maintaining a separate STP
instance for each VLAN adds overhead to the CPU and memory on a switch.
Multiple Spanning Tree (MST), defined in IEEE 802.1s, allows a group
of VLANs to be mapped to an STP instance.
Each MST instance (MSTI) builds its own RSTP topology database,
including electing its own Root Bridge. A VLAN can only be assigned to
one instance.
MST further separates the STP topology into regions. All switches in a
region must be configured with identical MST parameters:

• 32-byte configuration name
• 16-bit revision number
• VLAN-to-instance mapping database

If two switches are configured with different MST parameters, they belong
to different MST regions.
For most Cisco platforms, a region can contain a maximum of 16 MST
instances, numbered 0 through 15. By default, all VLANs belong to
instance 0.
The Internal Spanning Tree (IST) is responsible for maintaining the
topology for the entire region and all of the MSTIs. Only the IST can send
and receive BPDUs, and encapsulates the MSTI information within a BPDU
as an MST record (M-record).

The IST is always mapped to instance 0.
MST is compatible with all other implementations of STP. An MST region
is obfuscated from non-MST switches, which will see the entire MST region
as a single 802.1D or RSTP switch.

Multiple Spanning Tree (MST) (continued)
To enable MST globally on a switch:
Switch(config)# spanning-tree mode mst
Changes to MST parameters must be made from MST configuration mode:
Switch(config)# spanning-tree mst configuration
Switch(config-mst)#
To assign the MST configuration name and revision number:
Switch(config-mst)# name MYMSTNAME
Switch(config-mst)# revision 2
To map VLANs to a specific MST instances:
Switch(config-mst)# instance 2 vlan 1-100
Switch(config-mst)# instance 3 vlan 101-200

Remember: A maximum of 16 MST instances are supported, numbered 0 to
15. The MST configuration name, revision number, and VLAN-to-instance
mapping must be identical on all switches in the same region.
To view the changes to the configuration:
Switch(config-mst)# show pending
Pending MST configuration
Name [MYMSTNAME]
Revision 2
Instance Vlans mapped
-------- ------------------------
0 201-4094
2 1-100
3 101-200
All other MST parameters are configured identically to 802.1D STP, with
two exceptions:
• The mst parameter must be used on all commands
• All commands reference the MST instance instead of a VLAN.
Thus, to configure a switch as the Root Bridge for MST instance 2:
Switch(config)# spanning-tree mst 2 root primary



STP SECURITY:

Cisco added two STP features that help prevent the unexpected: Root Guard and BPDU Guard.
Root Guard

If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become the root. As long as the superior BPDUs are being received on the port, the port will be kept in the root-inconsistent STP state. No data can be sent or received in that state, but the switch can listen to BPDUs received on the port to detect a new root advertising itself.
You can enable Root Guard only on a per-port basis. By default, it is disabled on all switch
ports. To enable it, use the following interface configuration command:
Switch(config-if)# spanning-tree guard root

Lab on Root Guard

Switch(config)#HOST SW1
SW1(config)#INT FA0/2
SW1(config-if)#SPAnning-tree Guard Root

NOW MAKE THAT HACK SWITCH ROOT ....

Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#HOST HACK
HACK(config)#SPanning-tree Vlan 1 Root Primary


AND YOU WILL FIND SW1 GOES TO :

SW1(config-if)#%SPANTREE-2-ROOTGUARDBLOCK: Port 0/2 tried to become non-designated in VLAN 1.


Moved to root-inconsistent state

BPDU Guard

Note: Remember that enabling PortFast on a port is not the same as disabling the STP on it.

By definition, if you enable PortFast, you do not expect to find anything that can cause a bridging loop—especially another switch or device that produces BPDUs. Suppose that a switch is connected by mistake to a port where PortFast is enabled. Now there is a potential for a bridging loop to form. An even greater consequence is that the potential now exists for the newly connected device to advertise itself and become the new root bridge. The BPDU Guard feature was developed to further protect the integrity of switch ports
that have PortFast enabled. If any BPDU (whether superior to the current root or not) is received on a port where BPDU Guard is enabled, that port immediately is put into the errdisable state. The port is shut down in an error condition and must be either manually re-enabled or automatically recovered through the errdisable timeout function.

By default, BPDU Guard is disabled on all switch ports. You can configure BPDU Guard as a global default, affecting all switch ports with a single command. All ports that have Port- Fast enabled also have BPDU Guard automatically enabled. You can use the following global configuration command to enable BPDU Guard as the default:

Switch(config)# spanning-tree portfast bpduguard default

You also can enable or disable BPDU Guard on a per-port basis, using the following interface
configuration command:

Switch(config-if)# [no] spanning-tree bpduguard enable


Lab on BPDU GUARD

SW2(config)#int fa0/3
SW2(config-if)#switchport mode access
SW2(config-if)#spanning-tree portfast
SW2(config-if)#spanning-tree bpduguard enable

now move to HACK switch and try to decrement  the priority

hack2(config)#int fa0/1
hack2(config-if)#spanning-tree vlan 1 root primary

then output at SW2:

SW2(config-if)#%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port FastEthernet0/3 with BPDU Guard enabled. Disabling port.

%PM-4-ERR_DISABLE: bpduguard error detected on 0/3, putting 0/3 in err-disable state
%LINK-5-CHANGED: Interface FastEthernet0/3, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down

Protecting Against Sudden Loss of BPDUs

What happens if a switch doesn’t receive BPDUs in a timely manner or when it doesn’t receive any? The switch can view that condition as acceptable—perhaps an upstream switch or an upstream link is dead. In that case, the topology must have changed, so blocked ports eventually can be unblocked again.

However, if the absence of BPDUs is actually a mistake and BPDUs are not being received even though there is no topology change, bridging loops easily can form. Cisco has added two STP features that help detect or prevent the unexpected loss of BPDUs:
 Loop Guard
 Unidirectional Link Detection (UDLD)

 Loop Guard

If BPDUs are being sent over a link but the flow of BPDUs stops for some reason, the lastknown
BPDU is kept until the Max Age timer expires. Then that BPDU is flushed, and the switch thinks there is no longer a need to block the port. After all, if no BPDUs are received, there must not be another STP device connected there. The switch then moves the port through the STP states until it begins to forward traffic—
and forms a bridging loop. In its final state, the port becomes a designated port where it begins to relay or send BPDUs downstream, when it actually should be receiving BPDUs from upstream.

To prevent this situation, you can use the Loop Guard STP feature. When enabled, Loop Guard keeps track of the BPDU activity on nondesignated ports. While BPDUs are received, the port is allowed to behave normally. When BPDUs go missing, Loop Guard moves the port into the loop-inconsistent state. The port is effectively blocking at this point to prevent a loop from forming and to keep it in the nondesignated role.
When BPDUs are received on the port again, Loop Guard allows the port to move through the normal STP states and become active. In this fashion, Loop Guard automatically governs ports without the need for manual intervention. By default, Loop Guard is disabled on all switch ports. You can enable Loop Guard as a global default, affecting all switch ports, with the following global configuration command:

Switch(config)# spanning-tree loopguard default

You also can enable or disable Loop Guard on a specific switch port by using the following
interface-configuration command:
Switch(config-if)# [no] spanning-tree guard loop

UDLD

In some cases, the two switches still might see a functional bidirectional link, although traffic actually would be delivered in only one direction. This is known as a unidirectional link. A unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link. If that end of the link normally would be in the Blocking state, it will not be that way for long. A switch interprets the absence of BPDUs to mean that the port can be moved safely through the STP states so that traffic can be forwarded. However, if that is done on a unidirectional link, a bridging loop forms and the
switch never realizes the mistake.

To prevent this situation, you can use the Cisco-proprietary Unidirectional Link Detection
(UDLD) STP feature.

UDLD messages are sent at regular intervals, as long as the link is active. You can configure the message interval UDLD uses. (The default is 15 seconds.) The objective behind UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state. To do this, the target time must be less than the Max Age timer plus two intervals of the Forward Delay timer, or 50 seconds. UDLD can detect a unidirectional link after about three times the UDLD message interval (45 seconds total,
using the default).


UDLD has two modes of operation:

Normal mode—When a unidirectional link condition is detected, the port is allowed
to continue its operation. UDLD merely marks the port as having an undetermined
state and generates a syslog message.

Aggressive mode—When a unidirectional link condition is detected, the switch
takes action to reestablish the link. UDLD messages are sent out once a second for 8
seconds. If none of those messages is echoed back, the port is placed in the Errdisable
state so that it cannot be used.

Switch(config)# udld {enable | aggressive | message time seconds}

You also can enable or disable UDLD on individual switch ports, if needed, using the following
interface configuration command:
Switch(config-if)# udld {enable | aggressive | disable}

STP protection features

Permissible combinations on a switch port:
Loop guard and UDLD
Root guard and UDLD
Not permissible on a switch port:
Root guard and Loop guard
Root guard and BPDU guard