Nexus Mstp And Mxl Mstp Observations - Dell Force10 C150 Manual

Deploying the Dell Force10 MXL into a Cisco Nexus Network Environment
Force10 MXL blade switch was the link with the lowest path cost and should, from the Force10 MXL's
perspective, have always been in the Forwarding Status and Root Role when it was available.
In this lab 6 different tests were performed for the MSTP to MSTP testing, and then again for the Rapid
PVST+ to PVST testing. Each test was performed while a series of pings were in progress. The pings
originated from the N5K2 and were destined to a Switched Virtual Interface configured on the Force10
MXL2 blade switch. The pings were executed with an interval of 1 second and a count of 1000, causing
the system to execute 1000 pings, unless stopped, and to do so every 1 second. While the pings were in
progress, various tests involving failovers and failbacks were performed allowing the lab environment
to be monitored for the number of pings that were "lost" before the network could successfully re-
converge. By determining how many pings were "lost" and knowing that one per second was being
transmitted, it was possible to measure the failover and failback times with a granularity of 1 second.
The tests that were performed are as follows:
1) Failover: Local Interface Failure Simulation. In this test a shutdown was issued on the Force10
MXL blade switch's uplink interface which currently had a status of Forwarding and was in the Root
Role – that is, its interface 1/45. This simulated a failure of that interface. This should cause the
interface 1/43 to be placed in the Root Role with a Status of Forwarding.
2) Failback: Local Interface. In this test a no shutdown was issued on the Force10 MXL2's interface
1/45. Since this interface has the lowest path cost to the Root Bridge it should immediately be
placed in the Role of Root with a Status of Forwarding and the Force10 MXL2's interface 1/43
should be placed in the Role of Alternate with a Status of Blocking.
3) Failover: Uplink Failure Simulation (Uplink Fast). In this test a shutdown was issued on N5K1's
interface 1/5. This should cause the Force10 MXL2 blade switch to place its interface 1/45 into a
Status and Role of DIS(carding) and its interface 1/43 in to the role of Root with a Status of
Forwarding.
4) Failback: Uplink Failure Simulation (Uplink Fast). In this test a no shutdown was issued on N5K1's
interface 1/5. This should cause the Force10 MXL2 blade switch to failover to its interface 1/45
with a Status of Forwarding and a Role of Root since it has the lowest path cost to the Root Bridge.
5) Failover: Backbone Failure Simulation (Backbone Fast). In this test a shutdown was issued on
N5K1's interface 1/25. This should cause MXL2 to failover to its interface 1/43 interface with a
Role of Root.
6) Failback: Backbone Failure Simulation (Backbone Fast). In this test a no shut command was
issued on NX5K1's interface 1/25. This should cause STP on MXL2 to place its interface 1/43 into a
Role of Alternate and its interface 1/45 into the Role of Root since it has the lowest path cost to
the Root Bridge.
The agenda then was to run each of these 6 tests in 2 environments:
1) MSTP running on the Nexus Switches and MSTP running on the MXL
2) Rapid PVST+ running on the Nexus Switches and PVST running on the MXL
Using the ping command set at 1 second intervals, it was possible to tell how many seconds it took for
the Spanning Tree to re-converge after each failover and failback by counting the number of pings that
were "lost" – the number of pings that did not result in a response from the destination address.

Nexus MSTP and MXL MSTP Observations

32