09-20-2018 09:44 PM
Hi,
According to IPDT technote
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
Solved! Go to Solution.
09-21-2018 05:21 AM
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.
09-21-2018 05:21 AM
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.
09-23-2018 08:33 AM
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
09-24-2018 05:01 AM
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.
09-24-2018 05:34 AM
09-24-2018 05:31 AM
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
11-21-2018 07:20 AM - edited 11-21-2018 07:39 AM
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 )
04-15-2020 07:32 PM
Hi,
The question you raise, do you have a solution to the problem?
I had the same problem, but there was no test environment.
04-16-2020 09:34 AM
04-16-2020 06:47 PM
(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
07-11-2022 07:44 AM
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
06-16-2023 01:33 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide