Spanning tree is the only commonly deployed Ethernet control plane protocol today.  Eventually, something like TRILL or maybe Shortest Path Bridging will probably eliminate the need for Spanning Tree, but we’re definitely not there yet.

Since access ports are designed to only have a single device connected to them, their participation in spanning tree should be minimal.  Spanning tree has several features that can be enabled on the access ports to make this happen.  Some of these features could probably be considered as “safety” features rather than “security”, but I think they fit in this series.

Note – the configuration examples here are for IOS.  NX-OS is a bit different.

PortFast

By default, normal ports on a switch running Spanning Tree will be in a listening state (listening for STP BPDU’s from another switch) before they begin forwarding traffic.  On ports connected to end hosts, this shouldn’t really be necessary, and it can cause issues if the host is trying to use DHCP to obtain an address.  The DHCP process might time out before the port begins forwarding, so the host wouldn’t get an IP.  If nothing else, it’s annoying that the connection doesn’t start working until 30 seconds or more after a cable is plugged in.

Portfast will cause the port to immediately begin forwarding once the link is brought up.  BPDU’s can still be sent or received over the port (but another switch shouldn’t be connected to a portfast port).

Configuration Example

interface GigabitEthernet0/3
 description "ACCESS PORT"
 switchport access vlan 3
 switchport mode access
 spanning-tree portfast

This enables portfast on an invidiual port. It can also be enabled by default on all access (non-trunk) ports:

spanning-tree portfast default

If you have portfast enabled by default on all access ports, you’ll need to specifically disable it on any access ports that are connected to other network devices:

interface GigabitEthernet0/4
 description "UPLINK PORT"
 switchport access vlan 3
 switchport mode access
 spanning-tree portfast disable

What it Protects Against

Not really a security mechanism by itself, it’s just a setting to make host facing ports work a bit better.  It is necessary for some of the security settings below though.

Root Guard

The spanning tree root bridge for a network should be one of the devices that acts as the default gateway for the network.  Ideally it should be the one that’s configured to be the primary default gateway with whichever FHRP (first-hop routing protocol, like HSRP or VRRP) you’re using.

Root guard will prevent a port from being seen as the root port for a spanning tree instance.  Root guard can be configured on access ports (though – using BPDU guard as described later would make this unnecessary).  In some topologies, it should also be enabled on the “downward” facing end of uplinks.

If BPDU’s advertising a lower priority (preferred) root bridge are received on a port configured with root guard, the port will be in a broken state as far as spanning tree is concerned.

image

Configuration Example

interface GigabitEthernet0/3 
 description "ACCESS PORT"
 switchport access vlan 3
 switchport mode access
 spanning-tree guard root

On some other Cisco switches, the syntax is “spanning-tree rootguard”.

What it Protects Against

An attacker could potentially try to connect to multiple ports, and send BPDU’s with a lower priority in order to become the root bridge.  This would result in very sub-optimal traffic flow, and would also be forwarding traffic from other hosts through the attacker’s connections.

A more likely scenario though is that someone connects a switch that has been misconfigured and would unintentionally become the root bridge.  Root guard helps enforce your desired spanning tree topology.

BPDU Guard

This is a fairly import safety feature that should typically be configured along with portfast.  Portfast assumes that a single host device is connected to the port, and that it should not be participating in spanning tree.

BPDU guard will error disable a port if a spanning tree BPDU is received on it.  Since only hosts should be connected to portfast access ports, there’s a problem if a BPDU is received on one of them.  If you’re using this, you don’t really need root guard on the port – it will never be the root port since it will never receive BPDU’s.

Configuration Example

interface GigabitEthernet0/3 
 description "ACCESS PORT"
 switchport access vlan 3
 switchport mode access
 spanning-tree bpduguard enable

BPDU guard can also be enabled globally for all ports that are configured with portfast:

spanning-tree portfast bpduguard default

Best practice would probably be to enable it by default for all portfast ports, unless there is some specific reason you know of in your environment why not to.

What it Protects Against

BPDU guard protects against someone accidently or intentionally connecting a network device to a host port.  It protects your spanning tree topology from devices that shouldn’t be participating in spanning tree.

BPDU Filter

BPDU filter is dangerous.  You probably shouldn’t use it unless you’re fairly careful.

BPDU filter tells the switch to not send spanning tree BPDU’s out of a port, and ignore any BPDU’s that it receives.  This essentially breaks spanning tree, so you can cause a loop if you do this.

Service providers might enable BPDU filter on customer facing Ethernet connections.  Spanning tree isn’t a secure protocol that should be used with untrusted entities, so the service provider would not want their switches to send or receive BPDU’s to the customer’s device.

If the service provider is providing a Layer 2 service to the customer, a better option would probably be to tunnel the BPDU’s and forward them on the to the customer’s device at the other side of the Layer 2 connection.  This way, the customer could still use spanning tree themselves, between their own devices, but this would not impact the service provider’s network.

On other important thing to note about BPDU filter is that its behavior differs significantly depending on whether it’s specifically enabled on an interface, or if it’s configured as a default for portfast ports.

If it’s specifically enabled on an interface, no BPDU’s will be sent, and it will filter all BPDU’s that are received.  If BPDU guard is also enabled on the interface, it will be ineffective, BPDU filter will filter out the BPDU’s before BPDU guard sees them.

On the other hand, if it’s enabled as the default for all portfast ports, the switch will still send out a few BPDU’s when the port is brought up (after which, it will cease transmitting BPDU’s).  If a BPDU is received on the port however, the interface will be taken out of portfast mode.  This will also disable BPDU filter on the interface.  I blogged about this behavior with some examples a couple weeks ago.

Configuration Example

If you’re wanting to enable it only on a specific ports -

interface GigabitEthernet0/3 
 description "ACCESS PORT"
 switchport access vlan 3
 switchport mode access
 spanning-tree bpdufilter enable

To configure it as the default for all portfast ports -

spanning-tree portfast bpdufilter default
interface GigabitEthernet0/3 
 description "ACCESS PORT"
 switchport access vlan 3
 switchport mode access
 spanning-tree portfast

What it Protects Against

BPDU filter protects your switches from receiving BPDU’s from untrusted devices. An attacker could possibly use BPDU’s to cause unexpected spanning-tree behavior in your network. But it also opens you up to a risk of a bridging loop that Spanning Tree is unable to detect / prevent. On connections within a enterprise network, the second scenario is far more likely.

Bridge Assurance

This is somewhat of a new feature, and as far as I know it’s only supported on the Catalyst 6500 and on the Nexus gear.  It’s designed to be used on network ports that are connected to other switches.  It is kind of the opposite of BPDU guard.  BPDU guard will disable a port if BPDU’s are received on it.  Bridge Assurance will disable a port if it stops receiving BPDU’s on the port.  This could happen if someone accidently plugs a host into the port configured for the switch, or more dangerously, if the control plane / spanning tree process on the switch that’s connected dies.

Configuration

In NX-OS, bridging assurance is enabled by setting the port to be a “network"port.

interface Ethernet1/1 
 description "NETWORK PORT"
 spanning-tree port type network

In IOS, the syntax is a little different -

interface GigabitEthernet0/3 
 description "NETWORK PORT"
 spanning-tree portfast network

What it Protects Against

It helps constrain spanning tree behavior to ensure that a port is used as expected.