Virtual Port Channel (vPC)
Virtual Port Channel (vPC)
The Nexus line of switches provides a robust Layer 2 feature set. Now we will cover the implementation and syntax for Layer2 feature such as VLAN, STP & Virtual Port Channel (vPC)
Virtual Port Channels
The Nexus 9K series switches take port-channel functionality to the next level by enabling links that are connected to different devices to be aggregated into a single logical link. This technology is called Virtual Port Channel (vPC). In addition to link redundancy provided by port-channels.
VPC allows links that are physically connected to two different Nexus 9000 switches to appear as a single port-channel by another device.
The other device can be a switch, a server, or any other networking device that supports port channels. By utilizing vPCs for connections to other switches, spanning-tree topologies can be greatly simplified as there should be no uplink ports in BLOCKING mode.
The components used in vPCs:
vPC : The combined port channel between the vPC peer devices and the downstream device.
vPC peer device : One of a pair of devices that are connected with the special port channel known as the vPC peer link.
vPC peer link : The link used to synchronize states between the vPC peer devices. Both ends must be on 10-Gigabit Ethernet interfaces.
vPC domain : This domain includes both vPC peer devices, the vPC peer-keepalive link, and all of the port channels in the vPC connected to the downstream devices. It is also associated to the configuration mode that you must use to assign vPC global parameters.
vPC peer-keepalive link : The peer-keepalive link monitors the vitality of a vPC peer
vPC member port - port channels of vPC peer devices connected to the downstream device.
VPC Order of Operations:
Establish IP connectivity for Peer Keepalive
Enable vPC & LACP features globally
Create vPC domain
Define Peer Keepalive address
Establish Port Channel for vPC Peer Link
Verify vPC Consistency Parameters (show vpc consistency-parameters interface po1)
Configure vPC Member Ports
Enable vPC Member Ports on Primary
Enable vPC Member Ports on Secondary
Configuration Steps Configuring VPC Between Nexus 9K1- 9K2
Step 1: Define vPC domain number on Nexus 9K1. This identifies the vPC domain to be common between the switches . #Vpc domain 100 Step 2: Configure vPC peer keepalive on Cisco Nexus 9K1 #peer-keepalive destination 2.2.2.2 source 2.2.2.1 vrf keepalive_vrf The peer-keepalive is ideally an alternate physical path between the two Cisco Nexus 9K switches running vPC to ensure that they are aware of one another’s health even in the case where the main peer link fails. The peer-keepalive source IP address is the address being used on the Eth2/1 interface of the N9K1. The destination address is the Eth2/1 interface on the vPC peer i.e. Nexus 9K2
Step 3: Create a port channel interface on Nexus 9K1 to be used as the peer link between the two vPC switches. The peer link is the primary link for communications and for forwarding of control plane information to the peer switch
#interface port-channel100 #description ***VPC-PEER_LINK*** #switchport mode trunk #spanning-tree port type network #vpc peer-link Step 4: On Cisco Nexus 9K1 configured the physical interfaces that connect the two Cisco Nexus 9K switches together to the port channel. Two physical interfaces are configured for link resiliency. The channel-group number must match the port-channel number used in the previous step. #interface Ethernet1/1
#switchport mode trunk
#channel-group 100 mode active
#interface Ethernet1/2
#switchport mode trunk
#channel-group 100 mode active Step 5: Configure the corresponding vpc commands on Cisco Nexus 9K2 switch. Change the destination and source IP addresses for Cisco Nexus 9K2 Switch.
Step 6: Verify that the vPC peer relationship has formed successfully by using show vpc command.
Step 7: Verify successful configuration by looking for the peer status of “peer adjacency formed ok” and the keepalive status of “peer is alive”
Step 8: Configure vPC member port on both the switches, as mentioned below. Kindly note that member port configuration on both vpc peers should be identical (same). #interface Ethernet2/12
#description DC-REP-SW-01_GigabitEthernet1/0/1 (VPC 202 MEMBER)
#switchport access vlan 105
#channel-group 202 mode active
#no shutdown #interface port-channel202
#description **Uplink to Replication sw-1**
#switchport access vlan 105
#vpc 202 Step 9: Verification for member port
Status should be up and consistency should be success. To troubleshoot consistency for particular port channel or say for particular vPC member port, following command should be issued. Local value indicates value on device which you have logged in and peer value indicates other device’s value.
Concept of ORPHAN PORT:- • Orphan ports are downstream ports which has a single connectivity to nexus switch (FEX to 9K in our scenario)
Failure Scenario:- VPC MEMBER PORT DOWN
In the above snap-shot portchannel 302 is showing down, due to compatibility check failed for MTU. Now to check exact mismatch value of MTU (any mismatch parameter) below command will be used.
VPC PEER LINK DOWN
If vPC peer link goes down but keep-alive link is up, secondary device will wait for keep-alive timeout default is 5 Sec. and additional 3 seconds which is keepalive hold timeout, after that secondary device will came to know that primary device is still live through keep-alive link.
Only peer link is down so it (secondary) will shut down its all member port as well as layer 3 (SVI) interface. As SVI goes down ORPHAN port will not be able to communicate with other network, it means devices connected to ORPHAN port will be isolated from network until the peer link comes up. To avoid this situation there is a only one solution currently and which is just don’t use the orphan ports in your network architecture (hahaha…). Once secondary has shut down its all member ports it will not monitor the primary device, which can create a problem in one scenario. Let us take the above scenario again in which secondary has shutdown its all member port as well as SVI. Now primary device get completely fail (for ex. It get rebooted) in this scenario whole network remain down for that particular period of time. To overcome this we have to add command under vPC. By adding this command secondary device will continuously monitor the primary device and if primary goes down, secondary will become active and it will unshut its all member port as well as SVI interface.
VPC KEEPALIVE LINK DOWN If VPC keepalive goes down nothing will happen as it is backup for vPC peer link. But kindly note that this link should come up or it can also create a problem in one situation, where initially keep-alive goes down and after that peer link goes down; then there will be a chances of dual active situation. Means both the switch will act as a primary and which will create total network outage. CONCEPT OF PEER GATEWAY As we know that how HSRP works. If I have 2 routers or 2 layer3 switch with hsrp configured on it one device will act as a active and other will act as a standby and once primary goes down secondary will become active. This behavior of HSRP is changed in VPC, where both devices will work as active. If you check with show hsrp brief, it will show one active and other as a standbyBut still it will work as a active.
Lets take above example in which host X-192.168.2.2 wants to communicate with host Y-192.168.1.2.
As both are not in a same subnet, X will go to default-gateway; whose Mac add will be F (virtual Mac of vlan 20). Packet will reach to SW2 first. Now SW2 has configured port channel. so it will select one of the port based on the port channel load balancing algorithm, let us say it select the port connected to
Nexus-9K-01 which is primary switch. Now 9K-01 is active device in HSRP so it will do the routing and forward this traffic to SW1.
So the packet received at host Y will have sip-192.168.2.2, dip-192.168.1.2, smac-E, dmac-B. Now Y has to send a reply to this packet how it will send a reply?...
Usually host Y will check for the destn ip which is not in a same subnet hence it will try for default-gateway (i.e. 192.168.1.1 with V mac -C)
So when host Y send a packet it will have sip-192.168.1.2, dip-192.168.2.2, smac-B, dmac-C (which is virtual mac of vlan10). Packet will reach to SW1 first. Now SW1 has configured port channel so it will select one of the port based on the port channel load balancing algorithm, let us say it select the port connected to Nexus-9K-02 which is standby device in HSRP. Now 9K-2 will not send this packet back to the 9k-01. Instead of that, 1st it will check destination mac which is virtual mac for vlan 10, then it will check destination ip which is not the virtual ip(192.168.1.1) of active device for that vlan, so it will do the routing itself. And the packet will directly go to the host X through SW2. Everything will work fine here. But what if host Y replied directly to the packet which it has received (sip-192.168.2.2, dip-192.168.1.2, smac-E, dmac-B)? The reply packet (sip-192.168.1.2, dip-192.168.2.2, smac-B, dmac-E) will go to sw01 first, now suppose sw01 has selected a port connected to 9K-02. What 9K-02 will do now? It will check the dest mac address which is physical mac address of primary. So it will send a packet back to the primary and primary will send a packet to the host-X through SW02. In this scenario packet will unnecessarily moved from 9k-02 to 9k-01. In order to avoid this we use peer gateway. By using this command secondary device will do the routing itself, even though the dmac addres is a physical mac address of primary device.
