HOW TO: Secure Spanning-tree on Cisco IOS switches

LinkedIn
Facebook
Facebook
Google+
https://netfixpro.com/secure-spt-on-cisco-ios-switches/
RSS
Follow by Email

With 3 tier campus network design, layer 2 configurations, and spanning-tree are often implemented throughout the access and the disruption layer switches. In this article, using some Why? and How? questions, I will demonstrate securing the network against possible spanning-tree disruptions, such as rogue access point additions and the loss of stability to the root bridge by the addition of switches to the network. The improper addition of switches to the network can be either malicious or accidental. In either case, the network can be secured against such a disruption.

To best describe, I am using this simple topology of 4 Cisco IOS switches, running 15.4 IOS code and connected as shown in the above-mentioned diagram. Here is the initial configuration of all 4 switches.

SW1-4

conf t
 vlan 10
 vlan 20
exit
!
spanning-tree mode rapid-pvst
exit
!
interface range Ethernet1/0-2
 switchport trunk encapsulation dot1q
 switchport mode trunk 
 no shutdown
end
Spanning-tree Root Bridge placement
Why?

Spanning-tree elects the root bridge based on the priority and MAC address fields of the Bridge ID. The device with the lowest priority value is elected the root. If there is a tie in priority, the device with the lowest MAC address is elected root. It is advisable to manually configure the root bridge of spanning-tree to ensure optimized paths throughout the Layer 2 network.

How?

In this example, I will configure SW1 as spanning-tree root for VLAN 1 & 10, and SW2 as spanning-tree root for VLAN 20.

Configuration

SW1(config)#spanning-tree vlan 1,10 root primary
SW1(config)#spanning-tree vlan 20 root secondary
SW2(config)#spanning-tree vlan 1,10 root secondary
SW2(config)#spanning-tree vlan 20 root primary

Verification

SW1#show spanning-tree vlan 10

VLAN0010
  Spanning tree enabled protocol rstp
  Root ID    Priority    24586
             Address     aabb.cc00.0100
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24586  (priority 24576 sys-id-ext 10)
             Address     aabb.cc00.0100
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/0               Desg FWD 100       128.5    Shr
Et1/1               Desg FWD 100       128.6    Shr
Et1/2               Desg FWD 100       128.7    Shr
SW2#show spanning-tree vlan 20

VLAN0020
  Spanning tree enabled protocol rstp
  Root ID    Priority    24596
             Address     aabb.cc00.0200
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24596  (priority 24576 sys-id-ext 20)
             Address     aabb.cc00.0200
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et1/0               Desg FWD 100       128.5    Shr
Et1/1               Desg FWD 100       128.6    Shr
Et1/2               Desg FWD 100       128.7    Shr
Implement Root Guard
Why?

If a new switch is maliciously or accidentally added to the network, the STP topology could be changed if the new switch has
a lower bridge ID than the current root bridge. Root guard helps prevent this by putting a port that hears these BPDUs in the root-inconsistent state. In the root-inconsistent state, BPDUs are not sent outbound but accepted inbound, and all received frames are dropped by the switch-port. The switch automatically recovers the port from Root Inconsistent and starts negotiating the new port state and role, as soon as superior BPDUs are no longer received inbound.

How?

Root guard is enabled on a per-port basis with the spanning-tree guard root command. You should use root guard on switch ports where you would never expect to nd the root bridge for a VLAN.

In this example, I will enable root guard on SW1’s port Eth2/0 and Eth2/1.

Configuration

SW1(config)#interface range Ethernet2/0-1
SW1(config-if-range)# spanning-tree guard root

Verification

If the correct logging is ON, you will receive following log message indicating root guard implementation.

*Nov 6 14:40:56.065: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port Ethernet2/0.
*Nov 6 14:40:56.065: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port Ethernet2/1.

 

You can also verify inconsistent ports using this command. Right now, there is no interface shown because there is no violation occurred yet.

SW1#show spanning-tree inconsistentports

Name Interface Inconsistency
-------------------- ------------------------ ------------------

Number of inconsistent ports (segments) in the system : 0
Implement spanning-tree portfast
Why?

A switchport configured with Portfast will immediately start transmitting data in the ‘forwarding’ state bypassing the other spanning-tree states rather than waiting for normal STP convergence time.

There is also another great reason to configure Portfast on your client edge ports, that is not such widely known. Whenever a switchport participating in spanning-tree goes up or down the switch generates a TCN (Topology Change Notification) packet and sends this TCN packet to the root bridge, which starts SPT convergence. Now depending on the size of your layer 2 network this can waste a lot of resources on your switches which unnecessarily cause temporary traffic loss. Keep in mind also, that if CAM table entries start expiring this can cause unnecessary ARP traffic for additional information the switch already had.

Spanning-tree Portfast is certainly a great feature to have configured on your downstream ports connecting to your end-user workstation or your servers.

How?

Portfast can be configured using spanning-tree portfast command on an access port (interface subcommand) or by spanning-tree portfast trunk command on a trunk port (interface subcommand) or by spanning-tree portfast default (global command). The port must be an access port for this to work. If the port is configured as a trunk, the global portfast command will not convert the port to an edge port.

In this example, I will enable portfast on SW3 and SW4’s switchport Eth0/0.

Configuration

SW3(config)#interface Ethernet0/0
SW3(config-if)# switchport access vlan 10
SW3(config-if)# switchport mode access
SW3(config-if)# spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

%Portfast has been configured on Ethernet0/0 but will only
have effect when the interface is in a non-trunking mode.
SW3(config-if)#end
SW4(config)#interface Ethernet0/0
SW4(config-if)# switchport trunk encapsulation dot1q
SW4(config-if)# switchport mode trunk
SW4(config-if)# switchport trunk allowed vlan add 10,20
SW4(config-if)# duplex auto
SW4(config-if)# spanning-tree portfast trunk
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

SW4(config-if)#exit

Verification

You can verify if the portfast is enabled or not using this command.

SW3#show spanning-tree interface ethernet 0/0 portfast
VLAN0010            enabled

SW4#show spanning-tree interface ethernet 0/0 portfast
VLAN0001            enabled
VLAN0010            enabled
VLAN0020            enabled

Or you can also verify the Edge status of switchport because of portfast configuration using this command.

SW4#show spanning-tree interface ethernet 0/0

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001            Desg FWD 100       128.1    Shr Edge
VLAN0010            Desg FWD 100       128.1    Shr Edge
VLAN0020            Desg FWD 100       128.1    Shr Edge
NOTE:
Spanning-tree Loopguard has no effect on portfast enabled ports.
Implement spanning-tree BPDUGuard
Why?

BPDU Guard ensures that unauthorized switches cannot be plugged in to the network. BPDU guard protects ports from this type of situation by placing the interface in the error-disable state. With BPDU Guard, the port does not recover from the err-disabled state unless errdisable recovery related additional configuration is added. You can tell the switch to change from err-disabled state back to an up state after a certain amount of time.

How?

To enable BPDU guard on all PortFast-enabled ports, use the spanning-tree portfast bpduguard default global configuration command. Use an interface level command spanning-tree bpduguard enable to enable BPDU guard on a specific port.

In this example, I will enable BPDU guard globally on SW3 and use interface level command on Eth0/0 interface of SW4. I will also configure both switches to recover the switchports from the error-disable state after 120 sec.

Configuration

SW3(config)#spanning-tree portfast bpduguard default
SW3(config)#!
SW3(config)#errdisable recovery cause bpduguard
SW3(config)#errdisable recovery interval 120
SW4(config)#interface Ethernet0/0
SW4(config-if)# spanning-tree bpduguard enable
SW4(config-if)# exit
SW4(config)#errdisable recovery cause bpduguard
SW4(config)#errdisable recovery interval 120

Verification

SW3# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: none
EtherChannel misconfig guard is enabled
Extended system ID           is enabled
Portfast Default             is disabled
PortFast BPDU Guard Default  is enabled
Portfast BPDU Filter Default is disabled
Loopguard Default            is disabled
UplinkFast                   is disabled
BackboneFast                 is disabled
Configured Pathcost method used is short

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001                     1         0        0         14         15
VLAN0010                     1         0        0          3          4
VLAN0020                     1         0        0          2          3
---------------------- -------- --------- -------- ---------- ----------
3 vlans                      3         0        0         19         22
SW4# show errdisable recovery | i Time|bpdu
ErrDisable Reason Timer Status
bpduguard               Enabled
Timer interval: 120 seconds
NOTE:
In some corner cases, BPDU filtering is more recommended than BPDU guard. When BPDU filtering is enabled on an individual port, it prevents unnecessary BPDUs from being transmitted to & from the host device. BPDU filtering doesn’t error-disable the switchport like BPDU guard.
Implement Strom-Control
Why?

Strom control can be handy to protect against broadcast storms resulting from spanning tree misconfiguration, or even unicast storms created by malfunction host NICs.

How?

Configuring storm control on an interface is simple. At a minimum you’ll need to specify a traffic type (unicast, multicast, or broadcast) and a rising threshold:

In this example, I will configure SW3 and SW4’s switchport Eth1/0 to restrict broadcast storm to 50% of interface capacity and switchport Eth0/0 to only allow 100 unicast packets per seconds.

Configuration

SW3(config)#interface Ethernet0/0
SW3(config-if)# storm-control unicast level pps 100

SW3(config)#interface Ethernet1/0
SW3(config-if)# storm-control broadcast level 50
SW4(config)#interface Ethernet0/0
SW4(config-if)# storm-control unicast level pps 100

SW4(config)#interface Ethernet1/0
SW4(config-if)# storm-control broadcast level 50

Verification

SW3#show storm-control
Interface  Filter State   Upper        Lower        Current
---------  -------------  -----------  -----------  ----------
Eth0/0     Forwarding         100 pps     100 pps        0 pps
Eth0/1     Forwarding         50.00%      50.00%         0.00%
Implement UDLD
Why?

Unidirectional Link Detection (UDLD) is a Cisco-proprietary protocol, detects the existence of unidirectional links. In other words, detects the loss of bidirectional communication on a link. A unidirectional link occurs when traffic is transmitted between neighbors in one direction only. Unidirectional links can cause spanning-tree topology loops. UDLD allows devices to detect when a unidirectional link exists and shut down the affected interface. UDLD can be run on both fiber-optic and twisted-pair copper links.

How?

You can configure UDLD on a per-port basis using udld enable [aggressive] command or globally for all fiber-optic gigabit interfaces using udld { enable | aggressive } command . The aggressive keyword places the port in the error-disable state when a violation occurs on the port.

In this example, I will enable UDLD on interface Eth1/0-2 of all 4 switches.

Configuration

SW1(config)# interface range Ethenet1/0-2
SW1(config-if)# udld port aggressive

SW2(config)# interface range Ethenet1/0-2
SW2(config-if)# udld port aggressive

SW3(config)# interface range Ethenet1/0-2
SW3(config-if)# udld port aggressive

SW4(config)# interface range Ethenet1/0-2
SW4(config-if)# udld port aggressive

Verification

SW3# show udld Eth1/0 | i Current
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
    Current neighbor state: Bidirectional
NOTE: 
UDLD can only detect unidirectional links when UDLD is enabled on both ends of a link.
Thoughts on Loop Guard

Although not configured in this lab, loop guard can be configured as an alternative or in addition to UDLD. UDLD and Loop Guard features prevent network device failures that are due to faulty hardware or software errors. Problems such as link duplex mismatch, unidirectional link failure, frame corruption, resource errors, and misconfigurations can disrupt the spanning tree, which in turn disrupts network traffic.

Here are some of the limitations with Loop Guard interoperability.

  • The root guard is mutually exclusive with the loop guard. The root guard is used on designated ports, and it does not allow the port to become non-designated. The loop guard works on non-designated ports and does not allow the port to become designated through the expiration of max_age. The root guard cannot be enabled on the same port as the loop guard. When the loop guard is configured on the port, it disables the root guard configured on the same port. NOTE: you can use UDLD and root guard on same port to achieve the same results.
  • Both uplink fast and backbone fast are transparent to the loop guard feature.
  • Loop guard cannot be enabled for ports on which portfast is enabled. Since BPDU Guard works on portfast-enabled ports, some restrictions apply to BPDU Guard.
  • Loop guard should not be enabled on shared links. If you enable loop guard on shared links, traffic from hosts connected to shared segments might be blocked.
  • Loop guard functions correctly in the MST environment. When the switch is operating in MST mode, BPDUs are not sent on non-boundary ports only if the interface is blocked by loop guard in all MST instances. On a boundary port, loop guard blocks the interface in all MST instances.

 


I hope you enjoyed reading this article. Please feel free to leave any comment or feedback.

LinkedIn
Facebook
Facebook
Google+
https://netfixpro.com/secure-spt-on-cisco-ios-switches/
RSS
Follow by Email

Ashutosh Patel

Ashutosh Patel is the Author and editor of netfixpro.com. He currently works as a Network Security Architect. Follow him on following social media to know more about him.

6 thoughts on “HOW TO: Secure Spanning-tree on Cisco IOS switches

  • November 10, 2016 at 6:22 AM
    Permalink

    I really enjoyed reading your article on spanning tree protocol (STP) ,though you should have mention also VTP (vlan trunking protocol) as part of securing your L2 switches,using the global config
    vtp password WORD (hidden|secret).
    this will guard against rogue L2 switches
    good job

    Reply
  • November 10, 2016 at 6:09 PM
    Permalink

    Hi! You write
    “Keep in mind also, that if CAM table entries start expiring this can cause unnecessary ARP traffic for additional information the switch already had.”

    Don’t you mean that receiving TCN casues the CAM to be flushed and we will see unknown unicast flooding.
    You would only see ARP requests,traffic, if a station has no entry for a specific IP in the ARP cache.

    Reply
    • November 10, 2016 at 6:10 PM
      Permalink

      Otherwise it was a good summary!

      Reply
  • Pingback: Best Practice: Securing Layer 2 Cisco IOS switch – NetFixPro

  • December 3, 2016 at 11:10 PM
    Permalink

    Really very much useful thank u

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Show Buttons
Hide Buttons

Enjoy this article? Please spread the word :)