FHRP localization failure involving multi homing

[steve switzer]

Hi All

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 ....

otv-isis default
  vpn Overlay10
    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
        action drop
vlan access-map HSRP_Localization 20
        match mac address ALL_MACs
        match ip address ALL_IPs
        action forward
vlan filter HSRP_Localization vlan-list x,x-x,x

Many thanks for your help in advance

Steve
 

[jerry.bonner]

do you have any arp inspection configured?

ip arp inspection filter HSRP_VMAC_ARP <OTV_Extended_VLANs>

[steve switzer]

Well jerry we don’t have it enabled on the OTV SVI because we are not using DHCP on that VDC.

Do you mean to put it in the SVI vdc ?

[jerry.bonner]

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.

[steve switzer]

Hi Jerry

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

[jerry.bonner]

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 :

http://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-7000-series-switches/guide_c07-728315.pdf

[steve switzer]

Thanks Jerry

That looks quite convincing having read the document

So we probably need the arp inspection commands on the OTV VDC

Steve

[jerry.bonner]

Let us know how it goes.

~jerry

[steve switzer]

Hi Jerry

No i am afraid it didnt work

Steve

[jerry.bonner]

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

~jerry

[steve switzer]

Hi Jerry

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

Thanks Anyway

Anymore ideas ?

Steve

[jerry.bonner]

I would run the show otv route commands anyway to ensure that the traffic is coming from the otv tunnels.

[steve switzer]

Incidentally we also have a case with TAC and they havent got a clue so dont feel  bad about it