EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

VPC Enhancements

VPC Enhancements

Posted on Jan 24, 2020 (0)

VPC Enhancements

vPC systems provide various advance concepts which can be used to enhance the vPC system. Following are the vPC enhancement we are going to study one by one:

  • vPC Peer-Gateway
  • vPC Peer-Gateway Exclude VLAN
  • vPC ARP SYNC
  • vPC Delay Restore
  • vPC Graceful Tye-1 Check
  • vPC Auto-Recovery
  • vPC Orphan Port Suspended

vPC Peer-gateway:

As we are aware that, In HSRP/VRRP systems, Both Nexus switch can route packet to HSRP Virtual VMAC and all upstream traffic will be load balanced through vPC Port-channel in access switches and Access switch sends the traffic to HSRP VMAC of SVI for Routing.

But in some cases like NAS servers, Servers with particular teaming technique might not send the any ARP request to discover gateway MAC address rather they use the MAC address received on the original request to build its response and NAS would reply to client request   and these reply will be directed to SVI MAC address and not to HSRP VMAC address.

Due to this it can create the undesired traffic flow in vPC. Let’s understand this by below example:

In above figure let’s say,

  • NAS sends the IP Packet for destination MAC 0012:980d: 53c3 which is SVI MAC of VLAN 5 on N7K1 using the interface connected to N7K2 due to port Channel hash algorithms.
  • Once N7K2 receives this frame and checks the MAC address table and based on result, it will forward this to N7K1 .
  • N7K1 will block this packet if this has to be forwarded out to a vPC port due to vPC loop avoidance method.

This issue can be solved easily by Peer-gateway command under vPC Domain. If both vPC peer is configured with this command each of them can route packet out to vPC port because  VLAN 5 SVI MAC of N7K1 will also be present on N&K2 and vice Versa , as shown in above figure.

To activate vPC peer-gateway capability, use the following command line (under vPC configuration context mode):

N7k(config-vpc-domain)# peer-gateway

Both vPC peer devices need to be configured with this command.

vPC Peer-Gateway Exclude VLAN

This feature is used in NX-OS 5.1.3 to address specific topology with peer-link on F1 ports in Mixed Chassis mode. This feature is only helpful when the Peer-link is on F1 link and not with Chassis only having F1 cards or Chassis only having M cards.

This feature is used to avoid transit traffic between vPC peer using vPC peer-link to be punted to CPU and allow direct HW switching.

Typical application for vPC peer-gateway exclude-vlan is with L3 backup routed path when a dedicated VLAN over vPC peer-link (also called transit VLAN) is used for this purpose. If all L3 uplinks on the vPC peer device fail down, backup routed path is used to carry traffic to the other vPC peer device which still has connectivity to the L3 core.

In this case, transit VLAN carrying the traffic from one vPC peer device to the other vPC peer device must be declared using the command below to work properly (otherwise transit traffic will be limited to some Mbps):

N7k(config-vpc-domain)# peer-gateway exclude-vlan

vPC ARP SYNC

This feature is used when the Peer-link fails due to which SVI and vPC member ports on Secondary switch goes down and in this case all traffic and new traffic flows from primary and there will be huge ARP Table entry mis match and as soon as Peer-link recovers it would take time to synchronize the ARP table between Peer-devices.

But when we configure the ARP SYNC on vPC and when the Peer-link fails and recovers than vPC ARP SYNC perform the bulk ARP synchronization over CFS from Primary to secondary switch.

vPC ARP Sync needs to be enabled on both vPC peer devices using the command:

N7k(config-vpc-domain)# ip arp synchronize

vPC delay Restore

After a vPC peer device reloads and comes back up, the routing protocol needs time to reconverge.

The recovering vPCs leg may black-hole routed traffic from access to core until Layer 3 connectivity is reestablished.

vPC Delay Restore feature delays vPCs leg bring up on the recovering vPC peer device. vPC Delay Restore allows for Layer 3 routing protocols to converge before allowing any traffic on vPC leg. Result is a more graceful restoration and zero packet loss during the recovery phase (traffic still get diverted on the alive vPC peer device).

This feature is enabled by default with a vPC restoration default timer of 30 seconds. The timer can be tuned according to a specific Layer 3 convergence baseline from 1 to 3600 seconds.

Command to configure vPC Delay Restore is:

N7K(config-vpc-domain)# delay restore <1-3600 sec>

Both vPC peer devices need to be configured with this command.

A similar command - delay restore interface-vlan <1-3600 sec > - can be used to delay the SVI bring-up timing upon vPC peer device failure and recovery.

vPC graceful Type-1 Check

If any inconsistency is found or detected as type-1, all the VLANs on both vPC member port goes down.

With the vPC graceful type-1 check capability, only member ports on Secondary vPC peer-device is brought down while the vPC member ports on primary switch remain UP and traffic flows from it.

vPC graceful type-a is enabled by default and if you want to enable manually it can be done by :

N7K(config-vpc-domain)# graceful consistency-check

vPC Auto-recovery

Let’s understand this by event wide:

Event 1: suppose, Peer- link goes down and Keepalive link is up which causes on VPC member ports and vPC VAN SVI go down on secondary switch.

Event 2: As soon as this above event happened, another event happened which causes Primary Nexus goes down.

Due to these consecutive there will be no any active path through which traffic flows to northbound and causing black hole for all traffic.

To avoid this scenario , we should configure auto-recovery command in vPC domain , while doing as , as soon as Event 1 and Event 2 occurs , auto-recovery feature makes the vPC VLAN SVI and vPC member ports UP on Secondary switch and make one path active via secondary switch.

It will work as below steps:

  • vPC peer-link goes down: vPC secondary peer device (7K2) shuts all its vPC member ports.
  • Primary vPC peer-device (7K1) then goes down. 7K2 receive no more any messages on vPC peer-keepalive link.
  • After 3 consecutive keepalive timeouts, vPC secondary peer device (7K2) changes role to operational primary peer device and then brings backs its vPC member ports to UP state.

vPC auto-recovery for the purpose of previous case is not enabled by default. Activate vPC auto-recovery by using this command:

N7K(config-vpc-domain)# auto-recovery

Both vPC peer devices need to be configured with this command.

vPC Orphan Port Suspended:

vPC orphan ports suspend feature was developed for single-attached devices to vPC domain and optionally working in active/standby mode (firewall or load-balancer for instance).

When a vPC peer-link goes down, the vPC secondary peer device shuts all of its vPC member ports, but it does not shut down vPC orphan ports. With vPC orphan-ports suspend configured, an orphan port is also shut down along with the vPC member ports when the peer-link goes down below figure.

When the vPC peer-link is restored, configured vPC orphan ports on the secondary vPC peer device are brought up along with vPC member ports.

vPC orphan port that must be suspended when vPC peer-link fails must be explicitly configured using the command:

N7K (config)# int eth 1/1
N7K (config-if)# vpc orphan-ports suspend

vPC orphan-port suspend CLI is available only on physical ports, not on port-channels. To configure orphan ports suspend for the port-channel, apply the above configuration for all member ports of the port-channel.


Comment

  • Super Duper Explanation


LEAVE A COMMENT

Please login here to comment.