Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

FHRP localization failure involving multi homing

 

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
 


 

 

 


 

 

 

  • Other Data Center Subjects
12 REPLIES
New Member

do you have any arp

do you have any arp inspection configured?

 

ip arp inspection filter HSRP_VMAC_ARP <OTV_Extended_VLANs>

 

New Member

Well jerry we don’t have it

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 ?

New Member

What kind of broadcasts are

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.

New Member

Hi Jerry This is an example

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

New Member

yep, ok, those logs are

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

 

New Member

Thanks Jerry That looks quite

Thanks Jerry

 

That looks quite convincing having read the document

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

 

Steve

New Member

Let us know how it goes. 

Let us know how it goes.

 

~jerry

New Member

Hi Jerry No i am afraid it

Hi Jerry

 

No i am afraid it didnt work

 

Steve

New Member

hmm ok. I would run a show

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

280
Views
5
Helpful
12
Replies