Spanning Tree Protocol Visualization - Initial Convergence

Spanning tree: everyone's favorite protocol! Thousands of pages have already been written about spanning tree, so I've decided to take a different approach.

I find it helpful to visualize protocol elections and traffic flow in order to better understand protocol behavior, so I created a visualization illustrating the initial spanning convergence process. This visualization only addresses the initial root bridge election and STP convergence process, for example, if all switches were to boot at the same time. This does not address converging a new STP topology after a topology change.

The visualization below is basically an embedded slideshow that can be advanced by clicking on the image. There are notes for each slide that briefly explain each step of the convergence process. The numbers on each side of the links between switches represent the port number of each uplink.

Here are the basic steps of the initial STP convergence process:

1. Elect the root bridge.
2. Determine the root ports.
3. Determine the designated ports.
4. Remaining ports are blocking ports.

Click the image to advance the visualization. 

Tap here if you are on a mobile device.



As you can see, the resulting topology (the logical forwarding topology that is created after STP blocks redundant links) looks something like an upside-down tree.

Here is an example of of what this tree might look like when redundant links are blocked by STP in a larger L2 topology (although hopefully your network looks nothing like this). The links shown in black can be used, because each port is in the forwarding state. The links shown in red cannot be used, because one of the ports is in the blocking state. Reducing the topology to a tree of forwarding links is how spanning tree maintains a loop free L2 topology.

Once again, this is not meant to be a complete description of STP, but rather a visualization and basic description of the initial convergence process.

Feel free to leave questions or comments below.

Configuring ERSPAN on Cisco Routers and Switches

In two recent posts, I covered SPAN, for mirroring traffic to a port on a local switch, and RSPAN, for mirroring traffic across a VLAN to a port on a remote switch.  What if we want to mirror traffic traffic to a destination across a L3 link?  Cisco provides the ability to do this natively with a feature called ERSPAN, or encapsulated RSPAN.  However, this feature is only available on higher end platforms such as Catalyst 6500 and 6800 series switches, 7600 series routers, ASR1000, and CSR1000v (this is not a complete list).

ERSPAN

Like SPAN and RSPAN, configuring ERSPAN is pretty straightforward.  ERSPAN simply requires L3 connectivity between source and destination devices.  The ERSPAN monitor session then builds a GRE tunnel that transports mirrored frames from the source port to the destination port.

Basic ERSPAN configuration is as follows:

! Source switch
monitor session SESSION-NUMBER type erspan-source 
 source-interface INTERFACE(S)|VLAN(S) {TX|RX|BOTH}
 no shutdown
 destination
  erspan-id ERSPAN-ID
  ip address DESTINATION-IP
  origin ip address ORIGIN-IP

! Destination switch
monitor session SESSION-NUMBER type erspan-destination
 destination-interface INTERFACE(S)
 no shutdown
 source
  erspan-id ERSPAN-ID
  ip address SOURCE-IP

It is important to note that when configuring the destination switch "source IP," you should select the source IP on the destination switch itself - the GRE tunnel endpoint.  Source IP does not refer to the GRE tunnel origin IP address.  Therefore, the "ip address" command should match on the source and destination.

Below is a basic ERSPAN config to mirror data from R1 interface g3 to R3 interface g3.  I created this topology using VIRL using CSR1000V routers for R1 and R3.

Configuring RSPAN on Cisco Catalyst Switches

I recently wrote a post on configuring port mirroring (SPAN) on Cisco Catalyst switches.  SPAN (switched port analyzer) allows you to mirror traffic from a source or multiple sources on a switch to a destination interface or interfaces on the same switch.  RSPAN (remote SPAN) takes this a step further and allows you to mirror traffic to an interface on a remote switch or switches.

RSPAN

RSPAN configuration is relatively simple and builds upon existing SPAN functionality and configuration syntax.

• Create an RSPAN VLAN on the source switch, destination switch, and all switches in the transit path.
• Take traffic from a specified source on switch A, and mirror it to an RSPAN VLAN.  
• Then, on switch B, use traffic from this VLAN as the source and mirror it to a physical interface

As shown below, traffic mirrored from the switch on the right to the switch on the left can traverse other switches as long as there is end to end L2 connectivity between them (ie. the RSPAN VLAN exists on all switches).

Basic RSPAN configuration is as follows:

Configuring Port Mirroring (SPAN) on Cisco Catalyst Switches

So you have a network issue.  Or perhaps you don't, but you need to help find the root cause of a performance issue and conclusively show that it's not network related.  In either case, packet analysis is your friend.

At times, it can be convenient (and effective) to capture directly on an affected server or host.  However, you may not always be able to access the affected device.  Even you can, capturing from the affected device is not always the best option due to TCP segmentation offload, checksum offload, and a number of other factors.  (These are outside of the scope of this post, but Kary over at packetbomb.com has a ton of great content on packet analysis including why you shouldn't capture on a host.  See here.)

A network tap is the best solution when absolute precision is required.  However, this can be impractical and is often overkill.  This is where port mirroring comes into play.  Cisco gear provides a number of ways to mirror traffic from a specified source (or sources) and get frames from point A to point B for analysis.