Version 15.2(1)E on 4900M globally enables ip device tracking and can't remove it

Tom Vanhout · ‎09-13-2013

We wanted to upgrade our 4900M devices to version 15.2(1)E due to some feature for ipv6.

Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-ENTSERVICESK9-M), Version 15.2(1)E, RELEASE SOFTWARE (fc3)

After the upgrade we started to get error-reports from users that they got duplicate-ip error messages.

The violating mac-address turned out to be from the upgraded switch where the vlan passed through, but the switch itself does not have an ip-address in that vlan. The devices reporting the error are also not connected to the switch.

We were a bit puzzled about that but then we found that after the upgrade there is an extra line in the config

"ip device tracking"

which is something we do not use, but we can't seem to remove it.

switchname(config)#no ip device tracking

% IP device tracking is disabled at the interface level by removing the relevant configs

however, there is no config defined on interface level, and even tried to disable it on interface level anyway, it makes no difference.

All the interfaces are enabled for ip device tracking as well, and we are also not able to remove an interface.

Searching the web we find that ip device tracking has been known to be responsable for duplicate-ip errors.

I have now configured the "workaround"

ip device tracking probe delay 10

Don't know yet if it will make a difference but i don't want to finetune or configure a feature we don't use, i would like to disable something which shouldn't have been there in the first place.

Any thoughts on how to disable the ip device tracking?

Giuseppe Tanzilli · ‎09-17-2013

we same issue on 2960-S series with 15.2(1)E

seems it send mac of the interfaces over the uplinks

We do not nweed this and we will like to disable that ip device tracking feature

dwilliams27 · ‎09-26-2016

Just adding my two cents, just in case someone thinks this is an 'old' issue. We are a manufacturer and our PLC's stopped comms with our HMI's as our PLC's reported duplicate IP's. No IPDT was enabled on the VLAN in question, and, it only happened on one VLAN. This propagated through 3850's, 3750's, 2960's and Stratix switches. It started after I introduced (2) 3850's as aggregate switches, and a 4503 with a Sup7, which has a bug associated with it to the network. The VLAN which had the issue was routed at the 3850, which is below the 4503 in the hierarchy. Working with Rockwell and Cisco, no one can tell me what triggered the IPDT to enable itself, but I did enable macro auto processing on the 4503 right before the issue began. Please note - the 4503 does not show IP device tracking enabled in the config - you have to look for it. I heard that adding the device tracking 0 on all interfaces is the cure, but, I have a lot of disparate switches in the network, some unmananged (but manageable - working on that) port channels, etc, and the device tracking 0 is on the stratix switches (connected to the PLC's) but the problem persisted anyway. Still working with Rockwell & CIsco on best way to mitigate my network. This has the potential to cross all vlans, and even WAN links if I understand correctly. No windows devices were impacted and no animals were hurt.

Damien Miller · ‎09-19-2013

The bug seems to have been documented. We upgraded from ios 12 to 15 on our access layer switches and ran into the ip address conflicts. It appears that ip device tracking is now enabled by default as I cannot find it in our config archives. My experience was with 2960 switches as well.
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtn27420

If you suspect the Cisco "bug" is affecting you just look in the host event log for event id 4199 and it will tell you that and ip address 0.0.0.0 conflicted. The offending MAC will be a port on your switch as seen in example. sh interface gi1/0/48

enpingado · ‎10-07-2013

So what is the workaround for this?

I tried setting the max devices to zero but i get the same message when i do a global no ip device tracking.

i.e.

% IP device tracking is disabled at the interface level by removing the relevant configs

Does setthing the delays and counts to maximums offer any protection?

Leo Laohoo · ‎10-07-2013

To remove IP Device Tracking from an interface, use the command "ip device tracking max 0".

Leo Laohoo · ‎10-07-2013

Folks,

Please see Richard Primm's response here. He's posted a work-around.

Tom Vanhout · ‎10-08-2013

Thanks for the link Leo.

Unfortunately the workaround doesn't seem to work for me.

jofrench · ‎10-08-2013

Starting in 15.2(1)E, device sensor uses IPDT. You can disable device sensor using "no macro auto monitor". Assuming you have no other non-default features configured that trigger IPDT, that should eliminate IPDT from being active on the port.

Tom Vanhout · ‎10-09-2013

Thanks John,

after configuring "no macro auto monitor" all the physical interfaces are removed from being IPDT enabled.

On the 4500-x switch in the lab that even meant all the interfaces and IPDT was disabled globally as well.

On our production switch (4900M) i seemed to see some different behaviour.

At first when i tried it, all the physical interfaces where "nmsp attachment suppress" was in place were removed from the IPDT.

After some investigation it turns out i also had placed globally "nmsp enable", since the suppress didn't seem to do anything.

Having "nmsp enabled" is thus a feature that makes ipdt active on a port, but you can counter it by setting nmsp attachment suppress.

In my case, since i originally didn't have nmsp enabled, i just disabled it again globally.

The "macro auto monitor" is apparently, as you point out, also a feature that will enable IPDT on a port.

Turning it off disabled IPDT on all the physical interfaces.

Which means i am close to a workaround but not quite, because it doesn't seem to work for the active port-channels.

It's a bit weird for the port-channels at first sight.

- configured port-channel, state not-connected -> not IPDT enabled

- configured port-channel, state up -> IPDT enabled

- if I shut down a port-channel , so state admin down -> the port-channel as well as the physical member-interfaces are made IPDT enabled. (which considering they are down shouldn't matter much, it is just odd)

Any thoughts on IPDT with port-channels?

wimatwork · ‎10-15-2013

The workaround found on http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCuj04986 is working on portchannels.

It's fixed by using 'ip device tracking max 0' on the interfaces,

Admin admin · ‎11-03-2013

The problem solved with me using the below command:

ip device tracking probe delay 10

Orginal article from Cisco.

http://www.cisco.com/en/US/products/ps6638/products_white_paper09186a0080c1dbb1.shtml

desweiler · ‎03-31-2014

I have the same problems. "No macro auto monitor" and/or disabling nmsp works but doesn't apply to portchannels.

We noticed the Windows 7 duplicate IP errors. When using DHCP Snooping as well they are apparently not happening so often. "show ip device tracking all" shows source DHCP then. Maybe the switch is not sending ARP probes this way? A workaround is probably setting the delay.

We also get duplicate IP errors in logs on Nexus 5000 and Brocade Loadbalancers when Cisco switches with IPDT are connected to them. This is annyoing.

We also supect instable database interconnects because of IPDT.

We are really annoyed because we can't easily disable IPDT and we don't feel Cisco realizes this as a real problem.