IP Device Tracking

[apocalypse_nsl]

Hi,

According to IPDT technote

https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html

Enter the ip device tracking probe auto-source fallback 0.0.0.1 255.255.255.0 Command

1. Set the source to VLAN SVI if present.
2. Search for a source/MAC pair in the IP host table for the same subnet.
3. Compute the source IP from the destination IP with the host bit and mask provided.

If the command changed to ip device tracking probe auto-source fallback 0.0.0.0 255.255.255.255, does it works?

Regards,

Alan

[anthonylofreso · Accepted solution]

The switch will accept that command, but what's the reasoning for configuring it this way?

I may write a quick blog post about IPDT. We recently had a couple TAC cases focused heavily on this topic. One word of caution, I would not configure this command using '0.0.0.1' we did this during testing with TAC, and saw intermittent connectivity issues. Eventually we determined what was happening:

From TAC: "we found out that the problem was caused because the configuration was generating an ARP probe with the default gateway’s IP address, 10.207.72.1, but with the MAC address of the layer 2 4500 switch instead of the Nexus 7K’s, so the end-device must’ve been updating its ARP table with the incorrect MAC address thus causing connectivity issues that are solved automatically once the Gateway sends an ARP request again that updates the end-device’s MAC address"

As it's typically common to use .1 as a gateway, I wish this technote would recommend reserving an IP to be used specifically with IPDT.

For context when reading the notes from TAC above; Our client network SVIs are configured in the data center on our 7Ks in a client VDC. Our closet switches are L2-only 4500s trunked off that client VDC.

[apocalypse_nsl]

I just find someone using the command "ip device tracking probe auto-source fallback 0.0.0.0 255.255.255.255", so I would like to know the meaning of using 0.0.0.0 255.255.255.255 instead of 0.0.0.1

[paul]

I don't know how the 0.0.0.0 255.255.255.255 would even work because that would set the source IP of the ARP to the client IP which I think would cause duplicate IP message issues.  Yep you have to make sure to set the autosource to an unused IP in the client subnets.  Usually .1 is the DGs so I ask customers if .254 is a used IP address in their scheme.

[anthonylofreso]

I agree. I was just trying to test this, and couldn't get the proper debug messages to trigger in our lab (to actually see what IPDT would set the source IP to). But what you're saying here is what I imagine the result would be too.

[anthonylofreso]

I think this is what you're looking for:

This latest CLI command was introduced through Cisco bug ID CSCtn27420 in Cisco IOS Version 15.2(2)E. It was added in order to allow a user-defined ARP request source IP address instead of the requirement to use the default source IP address of 0.0.0.0. The new global command ip device tracking probe auto-source fallback 0.0.0.x 255.255.255.0 override allows the user to use the host address of 0.0.0.x in the subnet in order to avoid any duplicate IP address problems.  If there is no SVI for a particular VLAN the fallback host-ip will be used to source the probe instead.

Found on this page: Troubleshoot " Duplicate IP Address 0.0.0.0" Error Messages

[dawid.karol.bednarczyk]

We had the same issue. It should be written somewhere to reserve the IP for probes. Endhost learn arp entries for default gw ( in our case ) with mac address of switchport and this causes intermittent network connectivity issues.

We only figured out after some issues in the network what was the cause of it.

Since this command is a global one that applies to all vlans, we are wondering what happens when you have different vlan masks for your client vlans.

Let's say you have vlan with subnet 10.1.1.32/28 and second one 10.2.2.0/22, which ips will be used in this case?

ip device tracking probe auto-source fallback 0.0.0.1 255.255.255.0 Command

I can imagine that for the first case we will have :

11111111 11111111 11111111 11110000

10.1.1.33

0001010 00000001 00000001 00100001

you will get

0000000 00000000 00000000 00000001

10.1.1.1

and 10.1.1.1 is not in the same subnet as our host 10.1.1.33/28 and I suppose host might ignore this request? Did somebody test this?

For the second example 10.2.2.0/22

If host ip would be 10.2.2.2 we would use 10.2.2.1 and for host in the same subnet with ip 10.2.3.1 we would use 10.2.3.1. 

Which means for /22 subnet we would need to reserve 4 ips for probes when we have mask for the IPDT command with mask /24. 

To solve both issues we would need to make the mask as small as smallest subnet which uses NAC and reserver multiple ip addresses for big subnets, which would be really strage.

I guess it would be nice to have this command per vlan.

Creating SVI on each access swich would be bad idea because without vrfs on 2960 you would create l3 path without any firewall on access switches.

We tested also the command with delayed probe, but for us it doesnt work, we still get the issue with duplicated ip addresses ( client sends DHCP decline towards DHCP server and we depleate our DHCP pool )

[borzheng]

Hi,

The question you raise, do you have a solution to the problem?

I had the same problem, but there was no test environment.

[Damien Miller]

Is there a reason you can't leverage the default IPDT behavior where the ARPs are sent from 0.0.0.0? Sending an arp probe with 0.0.0.0 as the source IP is defined within the RFC standards. It may have had some issues in the past, but I haven't seen issues with it for many years.

On a core switch with SVIs for each vlan, you could use "ip device tracking probe use-svi", but this doesn't work on l2 access switches.

There is a quite through guide on this for what to do where and when to avoid issues.
https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html

[borzheng]

(C2960CX-UNIVERSALK9-M), Version 15.2(4)E7,

In fact, I have read this document. Since the customer is running IPDT in the L2 switch, all other commands in the document have been tested, but the problem still exists, so I suggest the customer configure "IP device tracking probe auto-source fallback 0.0.0.x 255.255.255.0".

So I want to know when you have different VLAN masks for your client VLANs, how should we configure this command?

Thanks

[Razvan1Despa]

Hi,

We have some 2960x as access switches using 15.2.x versions. To avoid the 0.0.0.0 IP Conflict, we have configured the "ip device tracking probe auto-source fallback 0.0.0.x 255.255.255.0 override" command, where x is the last bit of the managent IP of the switch.

When we have upgraded to 15.2(7)E5, we found that some other devices are showing IP conflict and these are from various vlans, these having the last bit the same as the last bit of the IP of the switch.

Example: Let's say we configured "ip device tracking probe auto-source fallback 192.168.0.190 255.255.255.0 override", this IP being in vlan 5 (Management of switch). After some time we found client having 192.168.1.190 IP from Vlan 10 (wireless device) being in conflict, then some Access Point 192.168.2.190 being in conflict (Vlan 11), etc. The MAC reported is either of the interface where the device or the AP connects to the switch. We did not had this problem using 15.2(7)E4.

Also, in some cases the "sh IP device tracking all" shows disabled the table with MAC is full. We also noticed that where we have 2960X is in stack, the table is being populated with MAC present on uplinks or physical interfaces of the other stack members, but never from the master stack member.

Did someone seen something similar?

Thanks a lot, Razvan

[akasing4]

Run #remote command all sh run | i classifier and verify if the feature device classifier is visible.

If that's the case, upgrade the switch to 15.2(7)E7.