EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

VPC and L3 Design Scenarios

VPC and L3 Design Scenarios

Posted on Jan 24, 2020 (0)

VPC and L3 Design Scenarios

Whenever any layer 3 is connected to vPC domain through vPC, each vPC peer device is seen as distinct L3 device by rest of the network.

Below figure shows the distinct views depending on layer 2 and Layer 3 version on network.

Connecting any L3 device to vPC domain using vPC is not supported because of vPC loop avoidance rule. If you want to connect any Layer 3 device to vPC domain than use L3 links from l3 device to each vPC peer device where these link can be one and to up to 16 and thus provides ECMP function and load balances the traffic across all L3 links.

L3 device will not initiate the L3 routing protocol adjacencies with both vPC peer devices. Traffic from L3 device to vPC domain (i.e. vPC peer device 1 and vPC peer device 2) can be load-balanced across all the L3 links interconnecting the 2 entities together.

There is then no penalty to use L3 links to connect L3 device to vPC domain compared to a vPC connection (in the sense that multiple links can also be leveraged with L3 connectivity)

vPC & L3 connectivity Designs

Following are some supported topology and shows how we should connect the Layer 3 device to vPC domain.


Strong Recommendations:

  • Use separate Layer 3 links to connect L3 device (like router or firewall in routed mode for instance) to a vPC domain (Figure 50).
  • Do not use a Layer 2 vPC to attach L3 device to a vPC domain unless L3 device can statically route to the HSRP address configured on vPC peer devices.
  • Use individual Layer 3 links for routed traffic and a separate Layer 2 port-channel for bridged traffic if both routed and bridged traffic are required.
  • Enable Layer 3 connectivity between vPC peer device by configuring a VLAN network interface for the same VLAN from both devices or by using a dedicated L3 link between the 2 peer devices (for L3 backup routing path purposes).

In this design, vPC is used as a pure L2 transit path. Because there is no direct routing protocol peering adjacency from L3 device to any vPC peer device, this topology is entirely valid and fully supported

Peering between the 2 vPC peer devices is fully functional and primary use case for this type of design deals with L3 backup routed path. In case L3 uplinks on vPC peer device 1 or peer device 2 fail down, the path between the 2 peer devices is used to redirect traffic to the switch having L3 uplinks in UP state.

L3 backup routing path can be implemented using dedicated interface VLAN (i.e SVI) over vPC peer-link or using dedicated L2 or L3 links across the 2 vPC peer devices.

L3 device can be connected to vPC domain using STP interconnect links. Non-vPC VLAN must be used for this type of connection. A dedicated inter-switch link needs to be added across the 2 vPC peer devices to carry non-vPC VLAN traffic. vPC peer-link must not be used for this purpose

Below is the some Layer 3 unsupported design with vPC.

L3 backup Routing path & VPC

Backup path is used to provide the alternate layer 3 path to core in case of L3 uplink failure.

Let’s understand this by example and by given figure:

L3 Routing path across two vPC peer switch is a point to point link on which any dynamic routing protocols forms the peering adjacency between two routers or switches.

Let’s say in above dig if L3 uplinks on N7K2 fails and when any routed traffic which is sent from any access layer switch to N7K2, N7K2 will use it backup path to send the traffic to its Operating L3 uplinks.

There are several ways to configure Layer 3 Backup path.

  • Use a dedicated Layer 3 point-to-point link between the vPC peer devices to establish a Layer 3 backup path to the core.
  • Use the already existing Layer 2 port-channel trunk ISL (Inter Switch Link) for non-vPC VLAN and create dedicated VLAN/SVI to establish a Layer 3 neighborship
  • Use vPC peer-link and create dedicated VLAN/SVI to establish a Layer 3 neighborship (least recommended solution)

HSRP/VRRP Behaviour in vPC

Whenever we configure the HSRP and VRRP in vPC domain , it behaves or operates in active-active mode, means all the ARP request and replay are handled by HSRP Active but for data traffic both Active and Standby acts as active-active . From a control plane standpoint, active-standby mode still applies for HSRP/VRRP in context of vPC; the active HSRP/VRRP instance responds to ARP request. HSRP and VRRP operate in active-active mode from data plane standpoint, as opposed to classical active/standby implementation with STP based network.

If any traffic is send to HSRP standby, instead of sending to HSRP Active over vPC peer-link it acts as Active gateway and forwards the traffic to northbound.

The standby HSRP/VRRP vPC peer device just relays the ARP request to active HSRP/VRRP peer device through vPC peer-link.Here also same vMAC is used as Gateway MAC address at both Active and Standby switch. You can see this by following output:

7K1# sh hsrp group 100
Vlan400 - Group 100 (HSRP-V2) (IPv4)
Local state is Active, priority 100 (Cfged 100)
Forwarding threshold(for vPC), lower: 1 upper: 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.383000 sec(s)
Virtual IP address is 10.10.10.254 (Cfged)
Active router is local
Standby router is 10.10.10.2, priority 100 expires in 7.386000 sec(s)
Authentication text "cisco"
Virtual mac address is 0000.0c9f.f190 (Default MAC)
2 state changes, last state change 6d01h
IP redundancy name is hsrp-Vlan100-100 (default)
!
!
7K2# sh hsrp group 100
Vlan400 - Group 100 (HSRP-V2) (IPv4)
Local state is Standby, priority 100 (Cfged 100)
Forwarding threshold(for vPC), lower: 1 upper: 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.848000 sec(s)
Virtual IP address is 10.10.10.254 (Cfged)
Active router is 10.10.01.1, priority 100 expires in 7.852000 sec(s)
Standby router is local
Authentication text "cisco"
Virtual mac address is 0000.0c9f.f190 (Default MAC)
7 state changes, last state change 01:08:24
IP redundancy name is hsrp-Vlan100-100 (default)

Now from data point of view both peer devices are forwarding because of G bit (gateway bit) implementation for HSRP/ VRRP vMAC in MAC address table.

7K1# sh mac address-table address 0000.0c9f.f190
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN   MAC Address Type      age Secure NTFY  Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+---------+------------------
G 100   0000.0c9f.f190 static     -          F        F           sup-eth1(R)
7K2# sh mac address-table address 0000.0c9f.f190
!
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN    MAC Address    Type     age     Secure      NTFY     Ports/SWID.SSID.LID
---------+--------------------+--------+---------+-------------+---------+------------------
G 100    0000.0c9f.f190 static       -            F                F             vPC Peer-Link(R)

Recommendation:

  • When running HSRP/VRRP in active-active mode (data plane standpoint), aggressive timers can be relaxed: use the default HSRP/VRRP timers.
  • Define the SVI associated with FHRP/VRRP as passive routing interface in order to avoid forming routing adjacency over vPC peer-link.
  • Define vPC primary peer device as the active HSRP/VRRP instance and vPC secondary peer device as standby HSRP/VRRP (from control plane standpoint) for ease of operations.
  • Disable ip redirect on the interface VLAN where HSRP/VRRP is configured (command is no ip redirect). This is a general best practice related to HSRP/VRRP.

vPC & HSRP/VRRP Object Tracking:

When we use HSRP and VRRP in vPC we should not use object tracking to track the L3 uplink failure because this event causes the resulting SVI and its associated HSRP/VRRP configuration to DOWN state.

So every time 7K2 receives a frame destined to HSRP/VRRP vMAC, it bridges this frame over vPC peer-link because the other vPC peer device is able to process this frame (as SVI with associated HSRP/VRRP configuration is still in UP state).

Using vPC with HSRP/VRRP object tracking may leads to traffic black holing in case object tracking is triggered: the reason is that vPC systems will not forward a packet back on a vPC once it has crossed the peer-link (because of the vPC loop avoidance rule), except in the case of a remote vPC member port failure.


Comment

  • Super Duper Explanation


LEAVE A COMMENT

Please login here to comment.