EMAIL SUPPORT

dclessons@dclessons.com

LOCATION

NZ

OTV FHRP Isolation & Stability Conditions

OTV FHRP Isolation & Stability Conditions

Posted on Jan 24, 2020 (0)

OTV FHRP Isolation & Stability Conditions

OTV FHRP Isolation:

When FHRP is implemented, OTV filter FHRP messages across overlay. This is very much required on OTV domain because by this, same default gateway can be used at different site. Let’s understand what issue will occur if the FHRP isolation is not done by OTV.

Let’s Suppose the VLAN/IP subnet are configured at different site  and FHRP message are exchanged between them , which would cause the SITE-2 VLAN acts as FHRP Active and Standby . Now if any host want to reach to its VLAN gateway, it has to travel all across OTV Overlay to another site SITE-2 and route the traffic in different subnet which may cause suboptimal path selection for routing between different subnets.

Now let’s suppose OTV provides the FHRP isolation, where FHRP packets are filtered and are not allowed to cross the OTV Overlay, this will cause the same FHRP gateway at both location with same Virtual MAC address on both site and any traffic which has to be routed between different subnets need not to be traversed across OTV Overlay to reach to another site for Gateway.

To enable Filtering two steps are required :

Step1: 1Configure a VLAN ACL (VACL) on the OTV VDC.

The VLAN ACL is required for the traffic that needs to be filtered. The configuration below applies to the HSRP version 1 protocol, which is enabled by default on NX-OS and in bold are highlighted the specific commands required to filter HSRP version 2 packets. Notice how it is also required to apply a specific filter to ensure suppression of the Gratuitous ARP (GARP) messages that may be received across the OTV Overlay from the remote sites. This can be achieved by ip arp inspection filter command.

ip access-list ALL_IPs
10 permit ip any any
!
mac access-list ALL_MACs
10 permit any any
!
ip access-list HSRP_IP
10 permit udp any 224.0.0.2/32 eq 1985
20 permit udp any 224.0.0.102/32 eq 1985
!
mac access-list HSRP_VMAC
10 permit 0000.0c07.ac00 0000.0000.00ff any
20 permit 0000.0c9f.f000 0000.0000.0fff any
!
arp access-list HSRP_VMAC_ARP
10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00
20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000
30 permit ip any mac any
!
vlan access-map HSRP_Localization 10
match mac address HSRP_VMAC
match ip address HSRP_IP
action drop
!
vlan access-map HSRP_Localization 20
match mac address ALL_MACs
match ip address ALL_IPs
action forward
!
feature dhcp
ip arp inspection filter HSRP_VMAC_ARP
vlan filter HSRP_Localization vlan-list
!

After applying the configuration above to the set of VLANs that are trunked from the Agg VDC to the OTV VDC, all HSRP messages will be dropped once received by the OTV VDC.

Step2: Apply a route-map to the OTV control protocol (IS-IS).

Even though HSRP traffic is filtered via the VACL defined in the step above, the vMAC used to source the HSRP packets is still learned by the OTV VDC. Therefore, OTV advertises this MAC address information to the other sites via an IS-IS update. While this in itself is not causing harm, it would cause the remote OTV the edge devices to see constant MAC moves happening for the vMAC (from the internal interface to the overlay interface and vice versa). To prevent these MAC moves from being advertised and allow for a cleaner design, the following OTV route-map has to be configured (once again, this configuration applies to HSRP version 1 and 2).

mac-list OTV_HSRP_VMAC_deny seq 10 deny 0000.0c07.ac00 ffff.ffff.ff00
mac-list OTV_HSRP_VMAC_deny seq 11 deny 0000.0c9f.f000 ffff.ffff.f000
mac-list OTV_HSRP_VMAC_deny seq 20 permit 0000.0000.0000 0000.0000.0000
!
route-map OTV_HSRP_filter permit 10
match mac-list OTV_HSRP_VMAC_deny
!
otv-isis default
vpn Overlay0
redistribute filter route-map OTV_HSRP_filter

OTV & SVI Existence:

It is recommended by Cisco that there must be two VDC if you configure SVI and OTV. ON one VDC OTV configuration is to be done and on another VDC all L3 SVI configuration is to be done which provides the Routing.

Two different deployment models are considered for the OTV VDC based on the availability of uplinks to the DCI Transport:

  • OTV Appliance on a Stick: where a common set of uplinks from the Routing VDC are used for both the routing and DCI extension
  • Inline OTV Appliance: where a dedicated link from the OTV VDC is used for the DCI extension

OTV Scalability Guidelines:

From NXOS version 5.2(1) onwards following OTV scalability consideration can be used.

  • 10 Overlays
  • 6 sites
  • 2 Edge Device Per sites
  • 256 VLANs via OTV

These values can be increased in future releases. If an VDC contains the F1 and M1 ports you can use the f1 ports for internal interfaces and M1 port for L3 and join interfaces. 
[/pms-restrict]


Comment

    You are will be the first.

LEAVE A COMMENT

Please login here to comment.