How does an ARP table handle duplicate MAC address for same IP?

jfraasch · ‎04-07-2011

I have a weird application.

On one NIC I have a single mac address of course. But I have a real, configured IP and then I also have a Virtual IP.

So my mac address would be say 0000.0000.0000.0001 and this MAC would be for both (real) 172.21.0.25 and (virtual) 172.21.0.27.

When I am on a local subnet, there is no problem pinging both IP addresses. However, when I am on a different subnet, I can always ping the real IP but very sporadically can I ping the virtual IP.

My question has to do with ARP tables. I am basically pinging through a Cisco 6500 and am wondering how the ARP table on the 6500 is going to handle this?

For instance, will it always keep the mac to ip mapping even if the mac is the same for both IPs? Or will it flush it when it sees a duplicate. Often I see an "incomplete" for the virtual mac and am wondering if that is a function of the 6500 or of my virtual nic.

Thanks for any help you can provide.

James

sarabbi · ‎04-09-2011

Hi James,

This should work fine, it's okay for multiple ip addresses to be tied to the same mac address in your ARP cache.

---START---

***LOCAL SUBNET***

F340.11.10-6500-1#ping 14.1.106.118

Sending 5, 100-byte ICMP Echos to 14.1.106.118, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

F340.11.10-6500-1#ping 14.1.106.119

Sending 5, 100-byte ICMP Echos to 14.1.106.119, timeout is 2 seconds:

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

F340.11.10-6500-1#sh ip arp 14.1.106.118

Protocol Address Age (min) Hardware Addr Type Interface

Internet 14.1.106.118 1 000c.860b.4400 ARPA Vlan1

F340.11.10-6500-1#sh ip arp 14.1.106.119

Protocol Address Age (min) Hardware Addr Type Interface

Internet 14.1.106.119 0 000c.860b.4400 ARPA Vlan1

***REMOTE SUBNET***

sarabbi-mac:~ samirfazlerabbi$ ping 14.1.106.119

PING 14.1.106.119 (14.1.106.119): 56 data bytes

Request timeout for icmp_seq 0

64 bytes from 14.1.106.119: icmp_seq=1 ttl=252 time=19.095 ms

64 bytes from 14.1.106.119: icmp_seq=2 ttl=252 time=20.340 ms

64 bytes from 14.1.106.119: icmp_seq=3 ttl=252 time=18.356 ms

64 bytes from 14.1.106.119: icmp_seq=4 ttl=252 time=19.943 ms

64 bytes from 14.1.106.119: icmp_seq=5 ttl=252 time=20.866 ms

64 bytes from 14.1.106.119: icmp_seq=6 ttl=252 time=19.383 ms

64 bytes from 14.1.106.119: icmp_seq=7 ttl=252 time=20.468 ms

64 bytes from 14.1.106.119: icmp_seq=8 ttl=252 time=18.670 ms

^C

F340.11.09-6500-2#sh netdr captured-packets | i ttl

df 0, mf 0, fo 0, ttl 61, src 14.0.25.148, dst 14.1.106.119

df 0, mf 0, fo 0, ttl 61, src 14.0.25.148, dst 14.1.106.119

F340.11.09-6500-2#sh ip int br | i Vlan1

Vlan1 14.1.106.118 YES NVRAM up up

F340.11.09-6500-2#sh run int vlan 1 | i 14.1.106|bia

ip address 14.1.106.118 255.255.255.0

standby use-bia

standby ip 14.1.106.119

F340.11.09-6500-2#sh int vlan 1 | i bia

Hardware is EtherSVI, address is 000c.860b.4400 (bia 000c.860b.4400)

F340.11.09-6500-2#

---END---

It sounds almost like MS Network Load Balancing (MS NLB). They use a virtual multicast mac address for the virtual ip address and a unicast mac address for the regular "non virtual" ip address. Here's a link about MS NLB:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml#backinfo

What is the exact mac address being used?

Can you please collect the following from the 6500?

- ping 172.21.0.25

- ping 172.21.0.27

- sh ip arp 172.21.0.25

- sh ip arp 172.21.0.27

- sh int vlan x | i bia, where x=vlan for 172.21.0.n subnet

For more advanced troubleshooting, from 6500:

- debug netdr capture and-filter vlan x ethertype 0x806

- debug netdr clear-cap

- clear ip arp 172.21.0.25

- clear ip arp 172.21.0.27

- no debug netdr capture

- show netdr capture | inc protocol

You can also do the following

- debug netdr capture and-filter vlan x ethertype 0x806

- debug netdr clear-cap

- config t->int vlan x->shut->no shut

- no debug netdr capture

- show netdr capture | inc protocol

thanks,

samir