vPC with HSRP – Part IV

Today our focus will on First Hop Redundancy Protocol (HSRP) and see how it behaves when configured in conjunction with vPC.

While writing this post, I am assuming that reader has a basic knowledge of HSRP and its functionality.

There are two versions of HSRP : v1 and v2. Differences between v1 and v2:

• Version 1 is the default version of HSRP and uses 224.0.0.2 multicast address  to send hellos for peer discovery. Version 2 uses new IP multicast address 224.0.0.102 to send hello packets.
• In HSRP version 1, group numbers are restricted to the range from 0 to 255. HSRP version 2 expands the group number range from 0 to 4095
• HSRP version 2 provides improved management and troubleshooting. With HSRP version 1, you cannot use HSRP active hello messages to identify which physical device sent the message because the source MAC address is the HSRP virtual MAC address. The HSRP version 2 packet format includes a 6-byte identifier field that is used to uniquely identify the sender of the message. Typically, this field is populated with the interface MAC address.
• HSRP version 2 permits an expanded group number range, 0 to 4095, and consequently uses a new MAC address range 0000.0C9F.F000 to 0000.0C9F.FFFF.
• V1 only supports text authentication with cisco password. With v2, MD5 authentication support was also included.
• V1 and v2 packet format are different from each other. Both are not compatible, so both ends need to have same version configured.

In a normal scenario, HSRP works in Active/Standby fashion. Only one device behaves as Active and is responsible for all control and data plane traffic processing. The Standby router will take over the Active role in case of failure.

So what is the difference in behavior when HSRP is configured on the vPC peers. As we know vPC peers adopts Active/Standby role for Control Plane and Active/Active role for Data Plane traffic.

Same is the case with HSRP when configured with vPC.

Control Plane:

As explained earlier, any traffic sent to the Nexus switch itself is known as Control Plane Traffic. For example, ARP requests. Only Active HSRP switch is responsible for replying to ARP requests with Virtual MAC address.

Data Plane:

Both the HSRP vPC peers are responsible for forwarding the data traffic. The end host can use any of the link in port channel based on hashing algorithm to send the traffic. It doesn’t matter which link it use as both the switches are able to forward the traffic for the HSRP virtual MAC. Hence, not using the vPC peer link for unnecessary flooding.

No additional configuration is required to make HSRP as Active/Active, this is done by default for HSRP with vPC.

In traditional non-VPC case, only active HSRP switch will act as Gateway (G flag)  for HSRP MAC in the MAC table. However with vPC, both the switches will set G flag for the HSRP MAC, hence enabling them to forward the traffic.

As explained in previous blog about the “peer-gateway” feature, the same is applicable here as well. Some applications may consider the Source ethernet mac address of the frame to be response to the ARP request instead of the Actual Source MAC in the ARP reply field. So peer-gateway is required to be configured on both devices so that they can reply to the packet destined for peer’s BIA address.

It is always recommended to have one switch as vPC primary and HSRP Active device.

Now, lets take a look at the configuration and Verification.

• Enable HSRP with “feature hsrp” command
• Configured HSRP on the SVI interface and assign virtual HSRP IP address from the same subnet.
• The device with highest priority takes the Active role and in case of tie, the device with highest IP address wins the election.
• Below is the PCAP for HSRPv2 Hello packet which shows that the packet is destined to MCAST address 224.0.0.102

• In case of failover, Standby router takes over the Active role. Once the Active comes backup, it does not preempt until unless “preempt” command is not configured under HSRP.

• Server-1 and Server-2 will have default gateway configured as HSRP virtual IP address.

• MAC table on both the vPC peers indicate HSRP vMAC as gateway.

vPC Series:

vPC Design Variations

Virtual Port Channel Series: 

Today we are going to discuss different design types in which vPC can be implemented:

1. Host vPC
2. Fabric vPC
3. Enhanced vPC
4. Back to Back vPC
5. vPC+
6. Anycast vPC

• Host vPC: Host vPC is a simplest design where Nexus vPC switches are directly connected to host device.

• Fabric vPC: In this vPC design, the Nexus switches are connected to host via Fabric Extenders (FEX).

       

• Enhanced vPC: This is the enhancement to Fabric vPC where vPC is extended till hosts connected to FEX so both the FEX are behaving as Active/Active. With Enhance we have two options:

• Single-homed FEX topology where hosts are multihomed to FEX but FEX are in turn single homed to Parent Nexus switches.

• Dual-home FEX topology where both the FEX and hosts are dual homed.

• Back to Back vPC: A back-to-back vPC is a way of connecting two pairs of Nexus switches with vPC. Depending on the documentation, it is also known as Multi-Layer vPC or Double-Sided vPC. With this design, both ends think they have a connection to single switch. So logically, it’s a port channel between two switches. We will demonstrate Back to Back vPC in next Section.

• vPC+ : vPC when configured alongwith Fabricpath is known as vPC+. It enables both vPC switches to be represented as a single unique virtual switch to the rest of the Fabricpath enabled network. This is done by assigning a same switch id to both switches.

• Anycast vPC: vPC with VXLAN is referred to as Anycast vPC. The term anycast comes from the fact that same secondary loopback IP address is used on both switches to identify them as a single switch to the VXLAN network. We will discuss more about this in VXLAN configuration post.

Back to Back vPC Configuration and Verification:

1. Configured Peer link on the Port channel12 between Spine-1 and Spine-2.
2. Before configuring member ports, lets verify some features.

• Under normal conditions , one link between Spines and Leaf will be in Forwarding and all the other three links will be in blocking as per traditional STP.

• Lets ping SVI (10.0.0.13) on Spine-1 and SVI (10.0.0.14) on Spine-2.

• Verify the mac address table on Leaf. It is learned via only one designated port E1/3.

3. Configure Member ports on Spine towards Leaf and on Leaf towards Spine.

4. Now the Spine’s MAC will be learned over vPC Member port Po57.

5. All the 4 links will now be used for forwarding.

6. The twist here is that Secondary vPC Spine will have two Root ports
   1. One Root port towards Primary vPC over Peer link.
   2. Second Root port towards Leaf vPC Member Port.

With this, we have covered all the topics under vPC series. In case you want any other topic to be covered as well, please do write to us or comment below

F5 BIG-IP LTM VE with VMware Workstation or VirtualBox || NetworKHelp