OTV FHRP filtering on a ASR router
We configured a OTV DCI in my previous post and it was working as expected and by design. But during testing of all the VLANs I discovered a problem with HSRP over OTV, but only for 1 specific VLAN. The test results:
- A ping from a host in DC1 in VLAN 10 to the HSRP address gives random drops
- A ping from a host in DC1 in any VLAN to the HSRP address pings without any problems
- Shutdown the SVI of VLAN 10 in DC2, A ping from a host in DC1 in VLAN 10 to the HSRP address without any problems
- VLAN 10 is still disabled in DC2, but a host can ping the HSRP address from DC2 to DC1. This should be impossible because of the FHRP filtering
- Changing the standby group number (they are the same in DC1 and DC2 to keep the same MAC address) partially solved the problem, but some hosts in DC1 got the HSRP MAC of DC2 in the ARP table. This is not what we want.
- Moving the SVI from a 6500 switch to a 3750 switch in DC1, none of the above problems
I still have no idea why this problem only exists for VLAN 10, all other VLANs work as expected but I’ve found a good workaround for this in the configuration guide:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/wan/command/wan-cr-book/wan-m1.html#wp3953249580
First, configure a MAC access-list on both ASR routers
mac access-list extended otv_fhrp deny 0000.0c07.ac00 0000.0000.00ff host 0000.0000.0000 deny 0000.0c9f.f000 0000.0000.0fff host 0000.0000.0000 deny 0007.b400.0000 0000.00ff.ffff host 0000.0000.0000 deny 0000.5e00.0100 0000.0000.00ff host 0000.0000.0000 permit host 0000.0000.0000 host 0000.0000.0000
Apply this MAC ACL:
interface Overlay1 service instance 10 ethernet mac access-group otv_fhrp out
And to make 100% sure OTV filtering is globally enabled:
interface overlay 1 otv filter-fhrp
Start testing again and you’ll see that the ping drops are gone and HSRP (FHRP) filtering is working correctly.
I’ll update this post when TAC comes up with an explanation why this is only happening to VLAN 10 and why the problem does not exists when I move the SVI to a 3750.
so what did TAC come up with?
TAC didn’t give me a real answer. I only got a “this is best practice and you have to configure it”.
if you had performed a show otv route, i suspect you would have seen the HSRP virtual MAC address learned on both the site interface and via ISIS for the OTV link. show otv route displays the MAC routing table used by OTV. similar to an IP routing table, the MAC routing table uses administrative distance. if a MAC is learned both from the local site interface and via ISIS, both will be inserted into the OTV routing table, but AD will be different for both. now here’s the interesting part, OTV uses a lower AD for the ISIS-learned MAC address, meaning that ISIS learning is trusted more over a locally learned address. if the OTV router receives a frame addressed to the HSRP VIP, it will send it over the OTV link.
but! i cannot figure out why your setup is actually doing this because the layer 3 device performing HSRP will have a static cam table entry on itself for the HSRP mac address. i would assume that the local HSRP device would be able to respond faster to ARP replies than the device across the HSRP link, thereby meaning all local layer 2 switches should have the local HSRP mac installed in their cam tables so frames addressed to the HSRP mac should never make it to the OTV router and have to be sent across the link.
i have to conclude that your local switches are installing the HSRP mac address into their cam tables that point to the OTV router. that is the only explanation. so by filtering the mac address in the OTV link, frames destined to the VIP can only be answered by the local gateway.
here’s the show otv route command showing the HSRP mac address learned on both the ISIS link and the local interface. note the lower AD from the remotely learned MAC address.
01R_OTV_01#sh otv route
Codes: BD – Bridge-Domain, AD – Admin-Distance,
SI – Service Instance, * – Backup Route
OTV Unicast MAC Routing Table for Overlay1
Inst VLAN BD MAC Address AD Owner Next Hops(s)
———————————————————-
0 333 333 0000.0c07.ac00 30 ISIS 01R_OTV_01
*0 333 333 0000.0c07.ac00 40 BD Eng Po1:SI333
I actually just figured out why your local switches have the VIP mac pointing to the OTV router: your OTV device will proxy respond to ARP requests. so both your local HSRP device and your OTV router are responding to ARP requests for the VIP. this means that the switches closest to the OTV router will point to the OTV router for the HSRP mac.
this is why it is best practice to filter the HSRP mac across the OTV link.