IP Tracking and DNA Center

[Pete89]

Hello,

We recently have had issues of where IP tracking was causing some Windows PCs and IOT devices to detect (falsely) that another device was using the same IP, and so in the case of Windows the user would see a duplicate IP message, and in the case of the IoT device, it would drop from the network for an hour.

We opened a TAC case and they showed us how to disable IP tracking so those problems are gone.

BUT!!

From a DNA center perspective what are losing by disabling IP tracking?

Thanks for any advice or ideas you can share.

Pete

[Mike.Cifelli]

From a DNA center perspective what are losing by disabling IP tracking?

-Adding some opinions here.  IMO disabling IPDT does not gain you much, if anything it hurts you.  IPDT is a critical feature that enables snooping and device tracking.  IPDT is a key component in device context visibility.  Not only does it learn an endpoint's IP, but it allows the ability to do the following too: Map IPs to access sessions, plays a role in dacls/acls, plays a role in device profiling, and url redirection among other items.  See here for more info (section Device Tracking): ISE Secure Wired Access Prescriptive Deployment Guide - Cisco Community

Lastly, I personally think IPDT aides in troubleshooting.  HTH!

 

[Preston Chilcote]

I didn't think IPDT would have any influence on end hosts since it's just a database stored in the switch, and not as if the host can access that information in anyway. So I did some research and found:

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

which explains:

"If the switch sends out an ARP Probe for the client while the host (for example, a Microsoft Windows PC) is in its Duplicate-Address Detection phase, the host detects the probe as a duplicate IP address and presents the user with a message that a duplicate IP address was found on the network. The PC might not obtain an address, and the user must manually release/renew the address, disconnect and reconnect to the network, or reboot the PC in order to gain network access.'

With a recommendation of configuring a delay for the probes: "ip device tracking probe delay 10"

Did you try that command already?  That sounds like a nice option so that you can keep IPDT enabled.

[Pete89]

After looking around, we found that disabling IP tracking wasn't necessary with these two commands:

New format (newer switches):

device-tracking tracking auto-source fallback 0.0.0.1 255.255.255.0

Old format (older switches):

ip device tracking probe auto-source fallback 0.0.0.1 255.255.255.0

This gave us everything we wanted. Keep IP Tracking enabled and stopped the IoT devices from dropping off the network.

At first we tried creating a policy and attached it to the interface where IoT devices lived and the trunks, but we were worried how this would affect other devices. It worked in stopping the errors from the IoT devices but we weren't sure if other devices were also being affected.

device-tracking policy IPDT_disable

trusted-port

device-role switch

Attach policy:

interface X

device-tracking attach-policy IPDT_disable

We hope this will help someone else someday

[marco.merlo]

Hi Pete,

about "device-tracking tracking auto-source fallback 0.0.0.1 255.255.255.0"

was the  switch a layer 2 only switch or did it provided layer 3 functionalities as default gateway for the attached devices?

Regards

MM

[Pete89]

Hey MM,
We put these commands on both L2 and L3 switches to be sure we didn't get bit.
But since writing that post our strategy has changed (we found that the prior commands weren't enough) as we have had CPU issues on access switches where we had thousands of clients.
SPARE.140#sh device-tracking database
Load for five secs: 41%/5%; one minute: 39%; five minutes: 39%
Time source is NTP, 22:18:04.863 UTC Mon Oct 17 2022
Binding Table has 18384 entries, 18383 dynamic (limit 100000)

SPARE.140#sh proc cpu | ex 0.00
Load for five secs: 78%/11%; one minute: 79%; five minutes: 79%
Time source is NTP, 22:00:37.967 UTC Mon Oct 17 2022

Here is the new approach:
First, we create a policy:
device-tracking policy DT_trunk_policy
trusted-port
device-role switch

Then anywhere you have a trunk port (port-channel or individual ports) you need to apply the policy:
interface GigabitEthernet1/0/1
description EEM_CDP_SWITCH, configured trunk to GigabitEthernet3/0/46 of MDF, cisco WS-C3850-24S
switchport trunk native vlan 999
switchport mode trunk
device-tracking attach-policy DT_trunk_policy
ip dhcp snooping trust

After applying this to the switch you can see the difference.

SPARE.140#sh device-tracking database
Load for five secs: 20%/5%; one minute: 42%; five minutes: 41%
Time source is NTP, 01:21:42.047 UTC Tue Oct 18 2022
Binding Table has 4 entries, 3 dynamic (limit 100000)

Be on the lookout for this SYSLOG message on your switches:


%PLATFORM_MATM-4-QUEUE_OVERLIMIT: MATM dropped learn cache batch messages as queue limit has reached.



Here is a Cisco doc talking about the subject.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-5/configuration_guide/sec/b_165_sec_9300_cg/b_165_sec_9300_cg_chapter_010100.pdf



Hope that helps!

Pete

[marco.merlo]

Thanks for the reply!

My aim is to reproduce the same behavior that  I used to see on first IOS-XE switches before SISF introduction.
On old IOS-XE switches running legacy IPDT, device tracking was enebled by default on 802.1x configured ports and we had to arrange probe timers in order to avoid the 0.0.0.0 duplicate address issue.
On the newer switches device tracking is not enabled when configuring 802.1x on an access port.
What I do is to configure a very simple policy
device-tracking policy IPDEVTRACK
no protocol udp
tracking enable
and attach it just to access ports on which we enabled 802.1x.
We do not explicitally disable tracking on trunk ports.

What I am seeng is that:
1)No issues about duplicate ip address even on thw switches on which
we forgot to use
device-tracking tracking auto-source fallback 0.0.0.1 255.255.255.0
2)No issues on CPU

To be honest I am not able to understand why every thing is working (dhcp snooping is disabled).
Regards
MM

[IanGraham95756]

Late to the party here but according to release notes, the newer SIFS has the probe delay "Set to the default value, and cannot be changed."

I am guessing the default value is the recommended 10 second delay to avoid issues with Windows without having to deal with sourcing from a different SVI/unique IP. I am guessing @Pete89  is running an older version which does not implement the delay properly. There are some older IOS 15 configuration guides which mention the probe delay being preferred over the source interface configuration so it makes sense that this would be default otherwise the default DNA configuration of IPDT would cause a ton of issues.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-5/configuration_guide/sec/b_165_sec_3850_cg/b_165_sec_3850_cg_chapter_010110.pdf