Virtual Port-Channel (vPC) with HSRP [Explained with Configuration Example]

HSRP and vPC

  • Data Plane (Active / Active):

HSRP and VRRP operate in active-active mode from a data plane standpoint, as opposed to classical active/standby implementation with STP-based network.

From the data plane perspective, both peer devices are forwarding. This is implemented by imposing the G bit (Gateway bit) for HSRP/VRRP vMAC in the MAC address table on both vPC peer devices.


  • Control Plane (Active / Standby):

From a control plane standpoint, the active-standby mode still applies for HSRP/VRRP in the context of vPC, the active HSRP/VRRP instance responds to ARP request.

A particularity of the active HSRP/VRRP peer device is that it is the only one to respond to ARP requests for HSRP/VRRP VIP (Virtual IP). ARP response will contain the HSRP/VRRP vMAC which is the same on both vPC peer devices.

The standby HSRP/VRRP vPC peer device just relays the ARP request to the active HSRP/VRRP peer device through the vPC peer link.


Let’s put this to work:

  • HSRP configuration:
On NX01:
--------
feature hsrp
interface Vlan10
 no shutdown
 ip address 172.31.20.251/24
 hsrp version 2
 hsrp 10
 preempt
 priority 105
 ip 172.31.20.254

On NX02:
---------
feature hsrp
interface Vlan10
 no shutdown
 ip address 172.31.20.252/24
 hsrp version 2
 hsrp 10
 preempt
 ip 172.31.20.254


Let’s first check the MAC of the HSRP VIP (vMAC):

NX01# show hsrp interface vlan 10
Vlan10 - Group 10 (HSRP-V2) (IPv4)
  Local state is Active, priority 105 (Cfged 105), may preempt
    Forwarding threshold(for vPC), lower: 0 upper: 105
  Hellotime 3 sec, holdtime 10 sec
  Next hello sent in 2.512000 sec(s)
  Virtual IP address is 172.31.20.254 (Cfged)
  Active router is local
  Standby router is 172.31.20.252 , priority 100 expires in 9.102000 sec(s)
  Authentication text "cisco"
  Virtual mac address is 0000.0c9f.f00a (Default MAC)
  2 state changes, last state change 00:00:40
  IP redundancy name is hsrp-Vlan10-10 (default)

The HSRP vMAC is: 0000.0c9f.f00a


Now, we verify the MAC address table. We see that the vMAC have a G flag with it, which will leverage the active-active traffic flow, the vMAC is ready to route traffic on both vPC peer, but keep in mind that only the Active HSRP peer will process control plane packets like ARP for the vMAC (other switch will just bridge them via the peer link)

NX01# show mac address-table vlan 10
Legend:
        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
        age - seconds since last seen,+ - primary entry using vPC Peer-Link,
        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
   VLAN     MAC Address      Type      age     Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
*   10     0050.0000.0600   dynamic  0         F      F    Po10
G   10     0000.0c9f.f00a   static   -         F      F    sup-eth1(R)
G   10     5001.0000.1b08   static   -         F      F    sup-eth1(R)
*   10     5002.0000.1b08   static   -         F      F    vPC Peer-Link(R)


NX02# show mac address-table vlan 10
Legend:
        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
        age - seconds since last seen,+ - primary entry using vPC Peer-Link,
        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
   VLAN     MAC Address      Type      age     Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
+   10     0050.0000.0600   dynamic  0         F      F    Po10
G   10     0000.0c9f.f00a   static   -         F      F    vPC Peer-Link(R)
*   10     5001.0000.1b08   static   -         F      F    vPC Peer-Link(R)
G   10     5002.0000.1b08   static   -         F      F    sup-eth1(R)

Even with this active-active topology, we can still have an issue with devices that do not leverage ARP, as an example, if a NAS sends a packet with the destination MAC of the SW2 interface VLAN toward SW1, by default SW1 will bridge the traffic via the peer-link to its peer device.

But, if the traffic needs to be forwarded back to the vPC member ports (inter-VLAN routing), the vPC Loop avoidance mechanism with blocking it, which will cause a packet drop.

To resolve this, you may need to enable peer-gateway (best practice)

Note: when the endpoint sends a packet with the destination MAC of vMAC, we have no issue.

Bilel A

Bilel A

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments
Learn Duty
0
Would love your thoughts, please comment.x
()
x