Device Tracking probe with "auto-source" keyword...

[rezaalikhani]

Hi all;

Based on Cisco's documents, when using "auto-source" keyword for Device Tracking probilng operation, the following sequence of events occur:

1. The first preference is to set the source address to the SVI, if an SVI is configured.
2. The second preference is to locate an IP-MAC binding entry in Device Tracking table, from same subnet and use that as the source address.
3. The third and last preference is to use 0.0.0.0 as the source address.

Unfortunately, I cannot understand the second operation. Can anyone explain it with some real examples?

Thanks

[MHM Cisco World]

Any entry in table that have IP same subnet of device track is use as source. 

Normal all use op1

MHM

[rezaalikhani]

Can you please explain it by example, as your comment is exactly based on Cisco's documents which I can't understand. Thanks

[MHM Cisco World]

Did you check this doc.

https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

MHM

[rezaalikhani]

Yes I did...

[Arne Bier]

The question you're asking (if I understand correctly), has to do with "What IP address does the switch put in the IP Source Address field of the ARP packet" ?  If Device-Tracker has learned an IPv4 address via DHCP snooping, or via method 1 (ARP probe) then henceforth, the switch latches that IP address, and uses that as the ongoing IP address in the probe requests. 

I have seen cases where this goes wrong and causes confusion. E.g. endpoint takes a while to set its own static IP, and in the meantime, the switch sends a probe because IP<>MAC mapping is unknown - the endpoint returns 169.254.x.y address because the static IP has not activated yet. Then it gets activate, but by then it's too late, and the switch latches this APIPA address. And since there is no DHCP configured on the endpoint, the "IP learning via Device-Tracking" of the true IP address will never happen. Customers who still use static IPv4 addresses can only have themselves to blame. 

[rezaalikhani]

Thanks for your sharing thoughts and invaluable experience...

Based on RFC 5227:

For ARP probes traffic, the endpoint should choose 0.0.0.0 in 'Sender IP Address' field. The 'Sender IP Address' field must be set to all zeroes; this is to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host.

Does choosing an existing IP address (possibly from another endpoint) violate the RFC and possibly create problems for the existing client?

In cases you have mentioned, does delay configuration on the switch for sending ARP probes by the switch resolves the problem?

Thanks

[Arne Bier]

Is there an IOS command to delay the ARP probing? I can give that a try.

The last time I saw one of these weird cases (where IP address in device-tracking database was latched as a 169.254 address) I cleared the device-tracking database entry for that interface, and that resolved it. But it was a short-term workaround only. I don't know what the proper fix would entail.

[rezaalikhani]

[Arne Bier]

What device type and IOS version is that from? It doesn't exist on the 3860 IOS-XE 16.12 for example.

[rezaalikhani]

This command was introduced in version 15.0(1)SE on 2900, 3500, and 3700 Series switch platforms but has removed from IOS XE. The screenshot is from a device with IOS 15.x.