We currently have an issue out with our cisco support which we are awaiting a reply on..
If anyone has had anything similar it would be a great help if you could share with us.
We have two locations each with 2 Nexus 7k running IOS 6.2(2) using HRSP for redundancy.
We are trying to run an OTV vdc between the two locations .
In order to stop the local hsrp being broadcast between the two locations we have set an ACL
on the OTV vdc.
However this does not appear to be working as we can see the HSRP broadcasting over the
otv vdc. Which is causing problems.
This is some of the configuration for the OTV VDC to block hsrp broadcasts ....
redistribute filter route-map (xxxx)
otv site-vlan xxxx
spanning-tree vlan x priority 61440
mac-list HSRP-vmac-deny seq 10 deny (mac addr)
route-map stop-HSRP permit 10
match mac-list (list)
ip access-list HSRP_IP
10 permit udp any 224.0.0.x/32 eq 1985
20 permit udp any 224.0.0.x/32 eq 1985
mac access-list HSRP_VMAC
10 permit (mac addr)any
20 permit (mac addr) any
arp access-list HSRP_VMAC_ARP
10 deny ip any mac (mac addr)
20 deny ip any mac (mac addr)
30 permit ip any mac any
vlan access-map HSRP_Localization 10
match mac address HSRP_VMAC
match ip address HSRP_IP
vlan access-map HSRP_Localization 20
match mac address ALL_MACs
match ip address ALL_IPs
vlan filter HSRP_Localization vlan-list x,x-x,x
Many thanks for your help in advance
What kind of broadcasts are you seeing bleed through? Any log messages? The arp inspection is to filter out gratuitous arps from HSRP gateways. I believe OTV will proxy these to the other DC and this is used to filter them out.
This is an example of what we are seeing ...
2014 Jul 13 00:23:42 Rea-N7K-FabricB-SVI_VDC %ARP-3-DUP_VADDR_SRC_IP: arp [6628
] Source address of packet received from 0000.0c07.acf1 on Vlan241(port-channel
31) is duplicate of local virtual ip, 10.xx.xx.xxx
2014 Jul 13 00:23:53 Rea-N7K-FabricB-SVI_VDC %ARP-3-DUP_VADDR_SRC_IP: arp [6628
] Source address of packet received from 0000.0c9f.f0f3 on Vlan243(port-channel
31) is duplicate of local virtual ip, 10.xx.xxx.xxx
yep, ok, those logs are consistent with this issue.
Take a look here starting on page 23 and apply the arp inspection to your OTV VDC :
hmm ok. I would run a
show otv arp-nd-cache
on the otv vdc in the dc being affected. Look for the mac addresses you mention, 0000.0c07.acf1 and 0000.0c9f.f0f3. If you see these addresses in the output, it means that otv edge is still seeing arp messages coming in from the other dc, which means arp inspection might not be setup properly in the other dc to filter these out.
You can check to see which edge the mac is coming from by running
sh otv route 0000.0c07.acf1 vlan 241
sh otv route 0000.0c07.acf1 vlan 243
No joy i am afraid cannot see the mac addresses
when i input the show otv arp-nd-cache command
So no point running the sh otv route command
Anymore ideas ?