Cisco Catalyst IP DEVICE TRACKING

[Ditter]

Hi to All,

i was looking in the ip device tracking command trying to find a use - outside off course of its use with ISE and dACLs.

I use a mix environment with some clients having static IP addresses and some other clients having dhcp based ip addresses and as i mentioned above i am trying to find out an application (apart from ISE & dACL) where ip device tracking can be used.

In my case as far as the dhcp clients are concerned i am utilizing dhcp snooping.

In addition i noticed that in my Cat4500s (Version 15.0(2)SG6) the ip device tracking is there but in my newer 9400 with 16.6.4 the command does not exist and is subsituded from the command device-tracking  with a  whole lot of choices

access-sw1(config)#device-tracking ?
  ar-relay     Configure AR Relay on the interface
  binding      Configure device tracking binding table
  logging      Configure snooping Security logging
  policy       Configure a policy for feature device-tracking
  tracking     Configures device-tracking tracking behaviour
  unit-test    Run unit-test
  upgrade-cli  Converts legacy ipv6 snooping cli to device-tracking

Is device-tracking command in 9400 switches replacing the old ip device tracking command?

Thank you,

Ditter.

[Rob Ingram · Accepted solution]

Hi,
You would define a device-tracking policy and then reference that policy under the interface. Reference here.

HTH

[Ditter]

Thanks, very helpful guide.

Reading from this guide:

"The device-tracking configuration is very critical to learn an endpoint’s IP address and map that to its network access session. The device-tracking configuration is also essential for many features, such as downloadable ACLs, device profiling, URL redirection, and more."

I understand the correlation between the device tracking feauture and the dACL , but for example how is device tracking according to the extract above , correlating to device profiling?  I suppose that the device sensor feature correlates to device profiling and not the device tracking feature.  Am i missing something here?

Thanks again,

Ditter.

[paul · Accepted solution]

The learning of the IP is crucial to many of the ISE profilers:

1. Once the IP is learned ISE will do a DNS reverse look-up if enabled and get the FQDN of the system.
2. Once the FQDN is learned ISE can do an AD look-up using the AD profiler to see if the FQDN is a member of AD and then pull AD attributes.
3. Once the IP is learned ISE can then NMAP scan the device.
4. If NMAP learns SNMP is open on the device the SNMP profiler will scan it.

So that is 4 profilers dependent on learning the IP.

[Ditter]

Thanks Paul, i got the idea.

If DHCP Snooping is enabled, i suppose that ISE could also use this info in order to learn the IP address hanging out of a port.

I mean instead of device tracking, DHCP snooping could also be used , so if your whole network is DHCP based there is no need for device tracking if you have dhcp snooping enabled.  Correct?

Ditter

[paul]

I don't believe DHCP snooping will populate the IP Address field for the authentication session on the switch, but I have never tried.

[Ditter]

Paul, i am missing a piece here.

IP device tracking is a process necessary for interfaces that are part of 802.1x or MAB configuration.

But ISE profiling is independent  of 802.1x or MAB or Web Auth. What i mean is the learning of P addresses does not rely to ip device tracking as with use of SNMP , IP addresses can be learned.

I have around 10K Ethernet ports and 802.1x runs only on 1 switch. All of the profiling is done through SNMP polling.

[paul · Accepted solution]

SNMP polling works if you want a delay in profiling for certain attributes or want to poll more network devices than needed.  If you simply poll the L2 client switch you won't get IP information.  If you poll the L3 gateway device for the clients then you will get ARP information to correlate learned MAC addresses to IP addresses.

With new switches we are trying to optimize everything and use device sensor on the client switches.  In this way ISE doesn't need to poll anything or receive DHCP forwarded packets.  The switch will collect all the information (IP, DHCP, CDP and LLDP info) and sent it to ISE via RADIUS accounting packets.

[Ditter]

Thanks Paul, that is how i do it currently.

ISE polls not only the switches but also the routers , so it correlates these two sources in order to successfully have the knowledge of IP hosts.

In our new 9400 and 9300 i will surely use the device sensor feature.

Thanks again,

Ditter.

[Nadav]

Hi,

How would device IP tracking send that information to ISE? Via RADIUS?

I'm wondering what the minimum configuration is to learn the IP addressses of the supplicants without using ISE profiling.

Edit:  For clarification, if I have a new switch (Cat 9k) and I would like for the RADIUS logs to show the IP addresses of all endpoints, can someone supply the minimum configurations to be done on Cat 9k and ISE to do so via RADIUS?