Tags
7010, ccie, ccie data center, cisco, data center, etherchannel, Fryguy, fryguy_pa, labs, nexus, nexus 7000, nexus 7010, nxos, port-channel, vPC
The other day I received a question on Ether-channel and the Nexus 7000 - based on the question I felt it would be also good to include the information here. This will be a 2-part post, first part is the Nexus configuration for vPC, the second post will be on the mutli-chassis ether-channel configuration around the 3750 as well as the Nexus 7000 switches. What are the benefits of Multi-chassis (vPC) ether-channel? Basically all your up-links from your switches are in FORWARDING mode, nothing is in blocking mode in your spanning tree domain. What this means is that you have a loop free topology in your data center and all links can be utilized. Below is the diagram of the configuration that I will be showing here. There will be a Layer 2 Ether-channel vPC between the Nexus 7010-1 and Nexus 7010-2 (Orangish line), a Layer 3 Ether-channel for vPC keep-alive (Red line), as well as a mutli-chassis (vPC) ether-channel from a 3750 stack to Nexus 7010-1 and Nexus 7010-2 with all links in a single ether-channel bundle. Configuration for both of the Nexus switches is the same except where noted. Configuration for the Nexus switches First thing to do is enable the vPC feature: feature vpc Once you have enabled the vPC feature, you should create your keep-alive links. Here I create a port-channel via LACP over ports 9/1 and 10/1. You will also notice that I have spread the channel over two line cards. This has been done to help assure maximum redundancy. If a card where to go bad, the other card would still be active in the port-channel. interface Ethernet9/1 description [----[ vPC KeepAlive to CoreSwitch2 ]----] channel-group 101 mode active ! Assign port to port-channel 101 via LACP no shutdown interface Ethernet10/1 description [----[ vPC KeepAlive to CoreSwitch2 ]----] channel-group 101 mode active no shutdown Now we can create the VRF for the keep-alive link. I suggest using a dedicated VRF for security and sanity purpose. This VRF will not participate in your global routing table, thus allowing for more stability and also the prevention of duplicate IP addresses in the network. vrf context VPC100_KA Now we can create the Layer 3 interface on the port-channel and assign it to the new VRF, VPC100_KA interface port-channel101 description [----[ vPC Keep-Alive link between CoreSwitches ]----] vrf member VPC100_KA ! Assign this interface into the appropriate VRF ip address 10.10.10.1/30 ! The other side of the link is .2/30 Now you can configuration the vPC Peer links (Orangish lines). Since I am using 10G links for this connection, I have set the rate mode to Dedicated. This prevents any chance for over subscription on the 10G port. It also disables the other 3 ports in group, so you need to keep that in mind when you are designing your deployment. interface Ethernet7/1 description [-[ vPC Connection to Nexus 7010-2 - E7/1 ]-] switchport switchport mode trunk ! Set the mode to trunk rate-mode dedicated force ! Force the rate-mode mtu 9216 udld enable ! Since this is also fiber, enable UDLD channel-group 100 mode active ! Assign to port-channel 100 no shutdown ! interface Ethernet8/1 description [-[ vPC Connection to Nexus 7010-2 - E8/1 ]-] switchport switchport mode trunk rate-mode dedicated force mtu 9216 udld enable channel-group 100 mode active no shutdown ! Now to configure the port-channel as a vPC link as well as the vPC domain information. interface port-channel100 description [-[ vPC Peer-Link between Nexus Switches ]-] switchport switchport mode trunk vpc peer-link ! Assign this port-channel as a vpc peer-link spanning-tree port type network mtu 9216 ! vpc domain 100 role priority 16000 ! Here I hard-coded switch 1 to be the vPC master. switch 2 was left as the default peer-keepalive destination 10.10.10.2 source 10.10.10.1 vrf VPC100_KA ! The other side has the IP addresses reversed Had to move the formatting above to get the command to fit, sorry. Let's check the port-channel and make sure it is up with the appropriate members. As you can see from the output, Eth7/1 and Eth8/1 are members of the channel. N7K1# sh int port-channel 100 port-channel100 is up [------ SNIP - Output omitted! ------] Members in this channel: Eth7/1, Eth8/1 N7K1# Also check the vPC and the vPC keep-alive link N7K1# sh vpc Legend: (*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 100 Peer status : peer adjacency formed ok vPC keep-alive status : peer is alive Configuration consistency status : success Type-2 consistency status : success vPC role : primary, operational secondary Number of vPCs configured : 9 Peer Gateway : Disabled Dual-active excluded VLANs : - vPC Peer-link status --------------------------------------------------------------------- id Port Status Active vlans -- ---- ------ -------------------------------------------------- 1 Po100 up 1-224 N7K1# sh vpc peer-keepalive vPC keep-alive status : peer is alive --Peer is alive for : (1486816) seconds, (684) msec --Send status : Success --Last send at : 2010.09.11 12:38:36 872 ms --Sent on interface : Po101 --Receive status : Success --Last receive at : 2010.09.11 12:38:36 872 ms --Received on interface : Po101 --Last update from peer : (0) seconds, (161) msec vPC Keep-alive parameters --Destination : 10.10.10.2 --Keepalive interval : 1000 msec --Keepalive timeout : 5 seconds --Keepalive hold timeout : 3 seconds --Keepalive vrf : VPC100_KA --Keepalive udp port : 3200 --Keepalive tos : 192 N7K1# As of now, both switches are connected via vPC. This concludes the first post, the second post will be up shortly and will focus around the Cisco 3750 configuration as well as the associated configs on the Nexus 7000 switches.
jasmas said:
Nice write-up! One quick question: The 10.10.10.x addresses you use in the peer-keepalive destination command, I assume those are the loopback addresses you have configured on each 7k? Do those loopbacks need to be configured in the VPC100_KA vrf as well? I haven't gotten hands on a 7k yet, but I've seen vpc-keepalive in docs as a default vrf, similar to management. Any pros/cons to using this default vrf name?
fryguypa said:
Actually that IP is on the L3 etherchannel between the two switches. I chose that approach as it is simple and easy for people to see when they look at the config.
I just noticed that I did not change the IP on port-channel 101 when writing this. That error has been corrected – thank you for noticing that.
jasmas said:
Thanks! That all makes sense now.
ipvaid said:
Can we configure this somehow on 5k’s ?
Cheers
Rope said:
Thanks for sharing. Your post is a useful contribution.
Pingback: Google