Contents · PDF fileAppendix C – VDX 3.0 VCS Fabric Switches and Nexus 7K with vPC ... Cisco Nexus vPC Interoperability with Brocade VDX Switch Port Channels

Data Center Network Infrastructure Test Engineer’s Journal Cisco Nexus vPC Interoperability with Brocade VDX Switch Port Channels

Solutions Lab Test Engineer’s Journal 1

Contents Overview ....................................................................................................................................................... 1

Key Contributors ........................................................................................................................................... 1

Test Configuration ......................................................................................................................................... 2

Test Cases ...................................................................................................................................................... 2

Test Case 1: Burn In .................................................................................................................................. 2

Test Case 2: Fault Injection ...................................................................................................................... 3

Test Case 3: Fault Injections ..................................................................................................................... 4

Test Case 4: Nexus 7000 VDC “restart” .................................................................................................... 4

Test Case 5: Stress Testing the Network .................................................................................................. 5

Appendix A – Difference Between NX-OS and IOS STP ................................................................................. 7

Appendix B – Additional Design Tips ............................................................................................................ 9

Appendix C – VDX 3.0 VCS Fabric Switches and Nexus 7K with vPC ........................................................... 12

Test bed setup ......................................................................................................................................... 12

Cisco Nexus NX-OS RSTP ......................................................................................................................... 22

Prerequisites for Configuring Nexus Rapid PVST+ .................................................................................. 22

Guidelines and Limitations for Configuring Rapid PVST+ ....................................................................... 22

STP Interoperability Reconfiguring ......................................................................................................... 23

Overview This document is the test engineer’s journal with notes complied during testing of interoperability of Cisco Nexus using vPC with Brocade VDX Switches and port-channels. Please see the companion Validation Test Summary: Cisco Nexus vPC Interoperability with Brocade VDX Switches document for additional details about this test and a companion test of Cisco Nexus vPC interoperability with Brocade VCS Fabric with vLAG.

References

Data Center Infrastructure-Validation Test: Cisco Nexus vPC Interoperability with

Brocade VDX Switches

Key Contributors The content in this guide was provided by the following key contributors.

Test Engineer: Mike O’Conner, Strategic Solution Lab

http://community.brocade.com/docs/DOC-3138

http://community.brocade.com/docs/DOC-3138



Test Configuration This is the test configuration for VDX port-channels on individual VDX switches.

Validation Test Configuration with Single VDX Switches Using Port Channels

Test Cases

Test Case 1: Burn In

DUT Nexus 7K’s Brocade VDX’s

Purpose The purpose of this test is to stress our topology as a entrance criteria before beginning the other tests.



Test Procedure Note: For our tests unless otherwise noted, were going to use the Spirent Test Center, you could use Ixia, JDSU or some other vendor’s test equipment. You could also possibly use hosts and storage or some sort of VM setup, but you would need to make the needed adjustments to the tests to reflect this. For our tests, we will use the Spirent tester and we will configure (4) tester ports 1-4 on VDX-32 and (4) ports 5-8 on VDX-33. Next we’ll configure ports 1-8, 2-7, 3-6 and 4-5 in a paired full duplex with mix frame sizes say from 64-1200 as an example. You might very well have to find the right throughput setting, i.e. is it 60% line rate etc. etc. were there’s no frame loss. Once you’ve found this, you will let this run non-stop for 72 hours.

Expected Result You shouldn’t see any frame loss.

Actual Result Verified, no frame loss.

Test Case 2: Fault Injection This test simulates faults via cable pulls from our port-channel.

DUT Nexus 7K Brocade VDX’s

Purpose The purpose of this test is to if the OSPF network will remain stable when the primary controller on the Nexus 7K fails and the backup controller takes over.

Test Procedure We’ll use the setup we did in Test 1 and then we start the IO. Using the topology diagram, you can begin to pull cable(s), record the results. Reinstall the cables and record the results again.

Expected Result Record the output of the from your test gear. You will drop a number of frames, this will be a function of frame size, line rate, number of tester ports etc. etc. The other thing as an architect, you need to know that because we have in our case (2) VDX’s connected into a pair of Nexus 7K’s. We cannot leverage Brocade’s Frame Trunking technology when connected to these N7K’s since were not using VCS Fabric nor does the N7K support Brocade’s frame-based trunking.

Actual Result Verified some frame loss depending on your configuration.



Test Case 3: Fault Injections This test simulates faults via port shutdown and re-enabling ports from our port-channels.

DUT Nexus 7K Brocade VDX

Purpose This is a continuation of the previous test, were just inserting the fault(s) from within the network devices.

Test Procedure This is just like in the previous test put now your shutting down or enabling those port(s) from the pc’s.

Expected Result Record the output of the from your test gear. You will drop a number of frames, this will be a function of frame size, line rate, number of tester ports etc. etc. The other thing as an architect, you need to know that because we have in our case (2) VDX’s connected into a pair of Nexus 7K’s. We cannot leverage Brocade’s Frame Trunking technology when connected to these N7K’s since were not using VCS nor does the N7K support Brocade’s Frame Based Trunking.

Actual Result Verified some frame loss depending on your configuration.

Test Case 4: Nexus 7000 VDC “restart” This test simulates a catastrophic failure of a Nexus switch in a vPC configuration


Purpose To insert near catastrophic failure into our topology and see how our network recovers from it.

Test Procedure We’ll use the setup we did in Test 1, and then we start the IO, then on the vPC who’s the primary. You will then “restart” this VDC. This will have the same effect of interrupting vPC and show that restarting a VDC that’s configured for vPC will not disturb the other VDC’s as well as vPC coming back online. Note: Check vPC, STP and the port-channels on both N7K’s and the VDX’s connecting into the vPC. Note2 You cannot reload the default or admin VDC; you will get an error message.



To “restart” a VDC, below is an example, first we use the “vdc vdc-name”, and then enter the “reload vdc” command. The “vdc restart” command was replaced by the “vdc reload” command.

To work around this if this is your ONLY VDC, is to reload the module that is associated with the default VDC as shown below.

You see we reloaded module 3 and its being powered up, during this time were taking frame loss and vPC issues. If you keep running the “show module” command, you will see that this line card is coming back online. Once it does, the status will change to “ok”. Once everything comes back online, from the Spirent testers POV, you should see no more frame loss accumulating. Note3: What is a VDC (Virtual Device Context)? In a nutshell, the Nexus 7K’s have the ability to physically carve up a N7K chassis consisting of X number and type of line cards into a series of smaller N7K’s within the SAME physical chassis.

Expected Result The network comes back up and online, but will experience frame loss.

Actual Result Network fully recovered and started passing traffic. Frame loss occured

Test Case 5: Stress Testing the Network


Purpose Is to inject traffic into our VDX/Nexus 7K network and see if there are any places where we could see frame loss.



Test Procedure For our tests, we will use the Spirent tester and we will configure (4) tester ports 1-4 on VDX-32 and (4) ports 5-8 on VDX-33. Next we’ll configure ports 1-8, 2-7, 3-6 and 4-5 in a paired full duplex with mix frame sizes say from 64-1200 as an example. Then beginning with 10% line rate, you will run the test for 300 seconds. Once the test is finished, you will record the results. You will then use 20% line rate and after 300 seconds, you’ll stop the test and record the results. You will repeat this all the way to 100% line rate.

Expected Result You will more than likely drop a number of frames, this will be a function of frame size, line rate, number of tester ports etc. etc. The other thing as an architect, you need to know that because we have in our case (2) VDX’s connected into a pair of Nexus 7K’s. We cannot leverage Brocade’s Frame Trunking technology when connected to these N7K’s since were not using VCS nor does the N7K support Brocade’s Frame Based Trunking.

Actual Result Depending on your topology, you will see some frame loss.



Appendix A – Difference Between NX-OS and IOS STP

Important Cisco NX-OS and Cisco IOS Software Differences

In Cisco NX-OS:

STP supports stateful process restarts and In-Service-Software-Upgrades (ISSU) if two

supervisors are present in a chassis.

Rapid-PVST+ and the MST protocols are supported.

Rapid-PVST+ is enabled by default.

VLANs 3968-4047,4094 are reserved for internal use. Cisco IOS Software reserves

VLANs 1002-1005,4095 for internal use by default.

VLAN ranges can be configured in ascending or descending order (IE. vlan 10-20 or vlan

20-10), whereas Cisco IOS Software only supports configuring VLAN ranges in

ascending order.

The STP spanning-tree global configuration commands with VLAN ranges can be

configured in ascending or descending order (IE. spanning-tree vlan 10-20 root

primary or spanning-tree vlan 20-10 root primary), whereas the Cisco IOS software

only supports configuring spanning-tree ranges in ascending order.

The STP extended system-id is always enabled. Cisco IOS software requires the global

spanning-tree extend system-id configuration command.

The STP port types are identified with the port type designation as opposed to the

portfast designation in Cisco IOS Software.

Things You Should Know

The following list provides some additional facts about the Cisco NX-OS that should be helpful

when designing, configuring, and maintaining a network configured with the STP.

Rapid-PVST+ is interoperable with the 802.1d STP.

Rapid-PVST+ is interoperable with MST. (Enabled by default)

Only one STP can be enabled per VDC.

Bridge Assurance is enabled globally by default, but is disabled on an interface by

default.

Bridge Assurance can be enabled for an interface using the spanning-tree port type

network interface command.

The clear spanning-tree counters command clears the counters for an STP interface or a

VLAN.

STP enhancements such as BPDU Guard, Loop Guard, Root Guard, and BPDU Filtering

are supported.



Spanning-Tree best practices are applicable to both Cisco NX-OS and Cisco IOS Software

Do not disable STP. Even if the layer-2 topology does not require STP, it should always

be enabled as a safeguard for configuration and/or cabling errors.

Changing the STP mode can disrupt traffic.

Enabling Bridge Assurance is recommended. However, only enable Bridge Assurance on

layer-2 links if both devices on each end of the link support it.

Bridge Assurance should only be configured on the vPC peer-link (configured by default)

and not on any other vPC interfaces in a vPC domain.

Typically the core/backbone devices should be configured as the primary and secondary

root bridges.

The default bridge priority is 32,768 (plus the VLAN #). The lower the value, the more

likely it will become the root bridge.

Configure 802.1q trunk ports as edge trunk port type when connecting to layer-3 hosts

such as firewalls, load-balancers, or servers for faster convergence.

The above NX-OS and IOS STP comparison information came from the following Cisco wikidoc: http://docwiki.cisco.com/wiki/Cisco_NX-OS/IOS_STP_Comparison

http://docwiki.cisco.com/wiki/Cisco_NX-OS/IOS_STP_Comparison



Appendix B – Additional Design Tips 1. When we configured our port-channels on both the Nexus 7K’s to the VDX’s that they

were connecting to. The pc’s came up and are fully functional. But were you might run

into an issue when traffic tries to pass over these pc’s as described below.

From the Nexus7K port-channel connected to the VDX:

Now let’s look on one of the VDX’s that is connected to this N7K:

As long as the traffic stays within 1500 bytes, you will see no issues like drop frames or crazy latency numbers. To make this clean, decide on a MTU for these ports channels connected from the Nexus 7K’s down into the VDX’s. Also, on those southbound VDX’s (VDX-32 and VDX-33), the MTU is set to its default of 2500 bytes, again you need to decide if this will work for what your trying to do. Note: See Design Tip #2 about configuring MTU on the Nexus 7K.

2. When you created those port-channels in our network, we just had a single VLAN. Again, as part

of y our design you can adjust things and make allowances as to what VLAN(s) can cross these

port-channels.

On the VDX: Part 1

a. Go to configuration mode => configure b. Creating port channel =>interface port‐channel 1 c. Defining as switchport => switchport d. Setting the mode of the pc to trunk=>switchport mode trunk e. Setting VLAN(s) that can cross our trunk. => switchport trunk allowed vlan all f. Setting flow control =>qos flowcontrol tx on rx on g. Setting mtu => mtu 9208 h. Turning it on => no shutdown

Part 2 i. Go to each interface => interface TenGigabitEthernet 0/5 j. Place into LAG => channel‐group 1 mode active type standard k. Enable the interface => no shut l. Save the configuration => copy running-config startup-config m. Repeat for all interfaces that you want to be in this LAG



On the Nexus: a. Go to configuration mode => configure b. Creating port channel =>interface port‐channel 555 c. Defining as switchport => switchport d. Setting the mode of the pc to trunk=>switchport mode trunk e. Setting VLAN(s) that can cross our trunk. => switchport trunk allowed vlan all f. Setting flow control =>flowcontrol send on g. Setting flow control =>flowcontrol receive on h. Setting flow control => mtu 9208

ERROR: port-channel555: MTU on L2 interfaces can only be set to default or system-jumboMTU

Note: You will need to configure the jumbo before you configure the mtu down on the interface.

a. Go to configuration mode => configure b. Set the system jumbo size => system jumbomtu 9208 c. Creating port channel =>interface port‐channel 555 d. Setting flow control => mtu 9208 e. Save the config => copy running-config startup-config

If we do a “show run” on our Nexus 7K and we will see the following output for our trunked enabled port-channel 555: interface port-channel555 switchport mode trunk flowcontrol receive on flowcontrol send on mtu 9208 Note: The reason you do not see the allowed vlans on here because it is the default and will not be display. Now let’s go add in the port(s) that will be part of port-channel 555 on our N7K.



If you look at what is highlighted, when we tried to add the physical port to our pc, we got an MTU compatibility error. This is expected because the default MTU size for a L2 port is 1500. So we will use the “force” option to add in our port as shown above. For L3 with NX-OS, the MTU size is between 576-9216 bytes. Then we run the “sh interface Ethernet 3/22” command, and in the partial output above, you will see that the mtu is 9208, the port mode is trunk, flow-control is on in both directions. Note: In the Brocade NOS 3.x configuration guide, it is recommended to enable flow-control on both ends. The guidance doesn’t state if this applies to third party networking devices as well and I’m just making the reader of this document aware of this.

3. Instead of the (2) Cisco Nexus 7K’s that were used in our vPC Domain, this could have easily

been (2) Nexus 5K’s. And were you would see such a design would be on the leaf-side N55K’s in

a spine-leaf topology.



Appendix C – VDX 3.0 VCS Fabric Switches and Nexus 7K with vPC

Test bed setup VDX Port-Channel Configuration We’re going to configure our (2) PC’s on VDX-1 and VDX-2 that will connect into our N7K’s and our southbound VDX’s. The follow configuration applies to both VDX-1 and VDX-2.



The following VDX Port-Channel configuration is for both VDX-32 and VDX-33 which are our southbound VDX’s.

!

We have a 20G L2 LACP based PC connecting the two N7K’s and we’ve made this a trunk before we begin configuring vPC. Configuring vPC on Nexus7009 Nexus7009(config)# feature vpc Nexus7009(config)# vpc domain 100 Nexus7009(config-vpc-domain)# peer-keepalive destination 10.18.233.60 Note: --------:: Management VRF will be used as the default VRF ::-------- Nexus7009(config-vpc-domain)# auto-recovery Nexus7009(config-vpc-domain)# system-priority 4000 Nexus7009(config-vpc-domain)# role priority 200 Warning: !!:: vPCs will be flapped on current primary vPC switch while attempting role change ::!! Note: --------:: Change will take effect after user has re-initd the vPC peer-link ::-------- Nexus7009(config-vpc-domain)# int port-channel 100 Nexus7009(config-if)# vpc peer-link Please note that spanning tree port type is changed to "network" port type on vPC peer-link.This will enable spanning tree Bridge Assurance on vPC peer-link provided the STP Bridge Assurance (which is enabled by default) is not disabled. Configuring vPC on Nexus7010 Nexus7010(config)# feature vpc



Nexus7010(config)# vpc domain 100 Nexus7010(config-vpc-domain)# peer-keepalive destination 10.18.233.82 Note: --------:: Management VRF will be used as the default VRF ::-------- Nexus7010(config-vpc-domain)# auto-recovery Nexus7010(config-vpc-domain)# system-priority 4000 (make this number the same on both switches) Nexus7010(config-vpc-domain)# role priority 200 (lower priority is vPC master!) Warning: !!:: vPCs will be flapped on current primary vPC switch while attempting role change ::!! Note: --------:: Change will take effect after user has re-initd the vPC peer-link ::-------- Nexus7010(config-vpc-domain)# int port-channel 100 Nexus7010(config-if)# vpc peer-link Please note that spanning tree port type is changed to "network" port type on vPC peer-link.This will enable spanning tree Bridge Assurance on vPC peer-link provided the STP Bridge Assurance (which is enabled by default) is not disabled. Last vPC step - configuration vPC on both N7K's and this must be done for every unique device you want to have a vPC with. In our case, we have (2) vPC’s that will connect into our (2) VDX’s. Nexus 7009 Nexus7009(config)#interface e3/7 Nexus7009(config-if)channel-group 10 Nexus7009(config-if)# interface port-channel 10 Nexus7009(config-if)# vpc 10 Nexus7009(config-if)# no shut Nexus7009(config)#interface e3/9 Nexus7009(config-if)channel-group 20 Nexus7009(config-if)# interface port-channel 20 Nexus7009(config-if)# vpc 20 Nexus7009(config-if)# no shut Nexus 7010 Nexus7010(config)#interface Ethernet1/10 Nexus7010(config-if)#channel-group 10 mode active Nexus7010(config-if)#interface port-channel 10 Nexus7010(config-if)#vpc 10 Nexus7010(config-if)# no shut Nexus7010(config)#interface Ethernet1/14



Nexus7010(config-if)#channel-group 20 mode active Nexus7010(config-if)#interface port-channel 20 Nexus7010(config-if)#vpc 20 Nexus7010(config-if)# no shut system-priority and role-priority are optional, but the default value for both is 32768. Documentation says you should configure the system-priority when running LACP. Configure the peer-link pc as a trunk as well. You also need to enable LACP feature besides vpc. Nexus 7K PC and vPC Verification Nexus 7009

Note: vPC 10 and vPC 20 are connected to our (2) VDX’s



Nexus 7010

Note: vPC 10 and vPC 20 are connected to our (2) VDX’s VDX Port-Channel Verification



So now we have our port-channels on our (4) VDX’s up and operational along with our pc’s on our (2) N7K’s. We also have verified our (2) Nexus 7K vPC’s are also operational in this topology. If we reference our topology diagram, we see that port-channel 100 from our (2) L2 VDX’s are connected up into our Nexus vPC Domain. Then between each pair of VDX’s, we have another port-channel connecting them. Because these VDX’s are NOT in VCS mode, we are required to enable some flavor of spanning-tree. Since the N7K’s run RSTP by default (more on this later), we’ll enable RSTP on all (4) VDX’s. VDX-1(config)# protocol spanning-tree rstp VDX-1(config-rstp)# do copy run startup-config



This operation will modify your startup configuration. Do you want to continue? [y/n]:y The above procedure was repeated on the other (3) VDX switches.







Nexus 7K STP Verification



Port-channel 10 and 20 are our vPC’s that are connected into our (2) VDX’s. Port-channel100 is our vPC peer-link that connects our (2) N7K’s together in vPC Domain 100. You will also notice that our vPC ports have a special STP Type, Eth1/2 will be used to inject traffic from this N7K and the same goes for Eth3/2 on Nexus7009.

Cisco Nexus NX-OS RSTP Enter the show spanning-tree command on the Nexus 7K’s, it shows that RSTP is enabled and used by default. In Nexus NX-OS terms, what it’s really running is Rapid PVST+. Rapid PVST+ uses point-to-point wiring to provide rapid convergence of the spanning tree. The spanning tree reconfiguration can occur in less than 1 second with Rapid PVST+ (in contrast to 50 seconds with the default settings in the 802.1D STP).

Prerequisites for Configuring Nexus Rapid PVST+

Rapid PVST+ has the following prerequisites:

You must be logged onto the device.

If required, install the Advanced Services license and enter the desired VDC.

If you are working in another VDC than the default VDC, that VDC must be created already.

Guidelines and Limitations for Configuring Rapid PVST+

Rapid PVST+ has the following configuration guidelines and limitations:

There is a total of 4000 Rapid PVST+ for each VDC.

The maximum number of VLANs and ports is 16,000.

Only Rapid PVST+ or MST can be active at any time for each VDC.



Port channeling—The port-channel bundle is considered as a single port. The port cost is the

aggregation of all the configured port costs assigned to that channel.

For Private VLANs, on a normal VLAN trunk port, the primary and secondary private VLANs are

two different logical ports and must have the exact STP topology. On access ports, STP sees only

the primary VLAN.

We recommend that you configure all ports connected to Layer 2 hosts as STP edge ports.

Always leave STP enabled.

Do not change timers because changing timers can adversely affect stability.

Keep user traffic off the management VLAN; keep the management VLAN separate from the

user data.

Choose the distribution and core layers as the location of the primary and secondary root

switches.

When you connect two Cisco devices through 802.1Q trunks, the switches exchange spanning

tree BPDUs on each VLAN allowed on the trunks. The BPDUs on the native VLAN of the trunk are

sent untagged to the reserved 802.1D spanning tree multicast MAC address (01-80-C2-00-00-

00). The BPDUs on all VLANs on the trunk are sent tagged to the reserved Cisco Shared Spanning

Tree Protocol (SSTP) multicast MAC address (01-00-0c-cc-cc-cd).

For more information including all the default Rapid PVST+ settings, please see the following url: http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/layer2/configuration/guide/b_Cisco_Nexus_7000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_chapter_0111.html#con_1492209

STP Interoperability Reconfiguring Because Cisco Nexus RSTP is really R-PVST+, we need to reconfigure our VDX’s to use R-PVST+ which Brocade supports on the VDX along with PVST+. Why are we moving from RSTP to R-PVST+? The N7K’s run this by default and since were connecting into the Nexus vPC fabric; let’s just keep things as straight forward as possible! First we’ll need to disable RSTP and then enable R-PVST+ on all (4) VDX’s and then enabled R-PVST+ on these same VDX’s again.

Note: The lesson here is that when you’re mixing the same technology from different vendors, make sure it’s really what you think it is! So now that our network is running R-PVST+, where is our root at? Based on our topology it should be one of the Nexus 7K’s…

http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/layer2/configuration/guide/b_Cisco_Nexus_7000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_chapter_0111.html#con_1492209





So what we see at least from our (2) Nexus 7K’s is that neither device is the root for our R-PVST+ topology for VLAN1. Now let’s check our VDX’s with regards to R-PVST+, one of them has to be the root…

VDX-1 is not the root…





We found that VDX-33 is the root for VLAN 1 in our R-PVST+ spanning-tree topology, based on our design we want the N7K’s to be the root for all our VLAN’s. Design Tip: Do not flip on every possible feature with Cisco Nexus vPC-STP Best Practice. You might bring down your Cisco-Brocade Nexus7K-VDX network. So, the first order of business is that we’ll need to change the Bridge priority on the N7K’s in order to make it our root in our network. To make sure the N7K’s are always the root and or secondary, we’ll use the following command on the N7K’s with the root device being assigned to the vPC primary and the secondary device being assigned to the vPC backup (ie secondary in vPC speak). On both Nexus 7K’s we need to run the “show vpc role” command before we assigned which one will be our STP root.



Now we’ll make Nexus7K our root and Nexus7009 our secondary for our STP network.

Now we need to check to see if Nexus7K is our root for our STP network…

Note: The MAC address that is highlighted above is our STP root.



Note: Previously, VDX-33 was our STP root device and no longer is!



If you look at the MAC address that’s highlighted along with the address circled in red on Nexux7K, you will see that it is indeed our root in our STP network. So now we’ve meet one of our design goals. Design Tip: Remember when we ran the following command on each of our N7K’s:

Right now we just have a single vlan and our N7K’s have been configured to ALWAYS be either the root or secondary STP device for this vlan. We could have run this command for just VLAN 1 only which would be fine if you were never going to have another vlan configured. Chances are, you’re going to have more than one vlan. So in our design, we’ve made plans for no more than 100. It’s just something you need to plan for. If you follow Cisco’s Nexus, you will know that Cisco will give you the following caution notice in the documentation.



To the Brocade implementer, you might be wondering why we are spending so much time on STP if were using vPC which has been compared to Brocade’s VCS and doesn’t use any type of STP. Cisco vPC which currently is supported with NX-OS on the Nexus 7K and Nexus 5K switches does indeed USE STP! The following was recently discussed at Cisco Networkers conference with regards to STP and vPC interoperability. STP Uses:

- Loop detection (failsafe for vPC)

- Non-vPC attached device

- Loop management on vPC addition/removal

Requirements: - Needs to remain enabled.

Best Practices: - Make sure all switches in your layer 2 domain are running the same STP mode (R-PVST or

MST)

- Remember to configure port type edge on host facing ports.

So if you see from the line just right above us, if were to follow Cisco’s BP’s, we need to configure all of our hosts ports as an “edge or portfast” port type in our STP topology. Because were using R-PVST+ in our network, we will need to use the VDX spanning-tree edgeport

command. This is documented in the NOS 3.0.1 admin Guide on page 326. So on each of the hosts port on the VDX’s we need to configure the port as an edgeport and then we’ll check and see if STP picked up the change.

After we configure our host port as an edgeport, we checked our STP network and we do indeed see that the host port is indeed an edge port.



Design Tip: So what else do we need to do or even care about with regards to STP and vPC in our mixed device network? At the outset, you should care about everything period! Why? If we implement all the STP recommendations that were discussed at Cisco’s Networker’s Conference, you run the risk of shutting down parts of your network! So how could this happen? This is spanning-tree and Brocade supports both RPVST+ and MST just like the Cisco Nexus switches. Let’s look at the following diagram that was shown at the conference. Note: The following picture was shown as part of a presentation at the recent Cisco Networkers Conference.

In the Aggregation layer, we have our (2) nexus 7K’s configured for vPC along with both being the root and secondary STP for all of our vlan instances. Now look at the ports on these N7K’s that are connected to our devices in the Access Layer. One of the things you will see is a Gold band around these same ports that are connected to our Access switches. This Gold band is representing UDLD and as you can see it’s recommended in this type of topology. The issue here is if you configure UDLD on these N7K’s ports, Cisco mandates you also configure UDLD on the associated ports on these access layer switches. Currently, we do not support UDLD with VDX, the other thing is that Cisco Nexus UDLD implementation is proprietary. The following was taken straight from the Nexus Configuration Guide about UDLD: The Cisco Nexus 7000 Series device periodically transmits UDLD frames to neighbor devices on LAN ports with UDLD enabled. If the frames are echoed back within a specific time frame and they lack a specific acknowledgment (echo), the link is flagged as unidirectional and the LAN port is shut down. Devices on both ends of the link must support UDLD in order for the protocol to successfully identify and disable unidirectional links.



So in our mixed topology, do not enable UDLD on those ports connected to the VDX’s! For more information on Nexus 7K’s UDLD, see the following url: http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/interfaces/configuration/guide/if_basic.html#wp2266337 Note: Brocade plans to support UDLD with the NOS Leo release scheduled for 7/12. So based on the Cisco STP-vPC recommendations, we still need to configure Rootguard on the N7K ports that are attached to our VDX’s in our design. On each of the N7K’s, we need to find out the ports that are attached to our VDX’s, in our card it’s the ports that are part of port-channel 10 and 20.

From the output above, we know which ports we need to configure Rootguard on. So on each of these (4) ports, you will run the following command to enable Rootguard, but we get a strange error as shown below…

In our case, we need to do this under the associated port-channels that are connected to our VDX’s.

If we go check our spanning-tree and vPC, we will see that it’s still up and operational.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/interfaces/configuration/guide/if_basic.html#wp2266337

http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/interfaces/configuration/guide/if_basic.html#wp2266337



Note: if you run the show spanning-tree detailcommand, you will also see that rootguard has been enabled on these port-channel’s. Design Tip: During all this time when we were configuring all of our STP stuff in our network. We had IO running non-stop and we had lost some frames during this part of the configuration. The point that where trying to get across is if you make changes like this on a production network. You run the risk of losing some frames which could have serious effects on your network, so schedule a maintenance window to do this as an example.

Documents

Contents · PDF fileAppendix C – VDX 3.0 VCS Fabric Switches and Nexus 7K with vPC ... Cisco Nexus vPC Interoperability with Brocade VDX Switch Port Channels