cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3588
Views
5
Helpful
10
Replies

DHCP Snooping for Device Senor Profiling

Good morning experts,

I have a question in regards to DHCP snooping as I understand this feature must be enabled for the Device Classifier.  So here we go...

We have a couple of branch locations that utilize a router-on-a-stick design.  Basically we have an ISR with a couple of stack switches behind the ISR.  Our SVI's live/reside on the stack switches.  Do we still need to enable dhcp snooping on the access ports?  If so, do we need to enabled dhcp snooping trust on the uplinks?  What affect does this have if we do not enable DHCP snooping on the access ports.

Normally, this isn't a problem since must of our campuses do not follow this model as we do utilize DHCP snooping on our access ports. 

Just trying to piece all of this together for a future deployment.

Thanks a million!

-Robert

1 Accepted Solution

Accepted Solutions

Greg Gibbs
Cisco Employee
Cisco Employee

The DHCP Snooping binding table is used by the IP Device Tracking (IPDT) feature on the switch to map the MAC address to the IP address and keep the mapping current. If you do not enable DHCP Snooping (both globally and on all relevant VLANs), then the switch cannot track the IP address associated with the endpoint MAC address.

This will result in no IP address being seen in the 'show access-session interface gigx/y details' output on the switch (assuming IBNS 2.0 syntax) as well as no IP address shown in the live logs or reporting in ISE (since the switch cannot include this in the RADIUS messages).

Yes, you will need to enable dhcp snooping trust on the uplinks toward the DHCP servers.

- Regards

Greg

View solution in original post

10 Replies 10

Greg Gibbs
Cisco Employee
Cisco Employee

The DHCP Snooping binding table is used by the IP Device Tracking (IPDT) feature on the switch to map the MAC address to the IP address and keep the mapping current. If you do not enable DHCP Snooping (both globally and on all relevant VLANs), then the switch cannot track the IP address associated with the endpoint MAC address.

This will result in no IP address being seen in the 'show access-session interface gigx/y details' output on the switch (assuming IBNS 2.0 syntax) as well as no IP address shown in the live logs or reporting in ISE (since the switch cannot include this in the RADIUS messages).

Yes, you will need to enable dhcp snooping trust on the uplinks toward the DHCP servers.

- Regards

Greg

*you will need to enable dhcp snooping trust on the uplinks toward the DHCP servers*

That's the key and that's what I wanted to confirm.

Thank you very much Gregory and appreciate the timely reply!

-Robert

Note that it is worth testing without DHCP Snooping.  Although listed as a requirement, it does depend on the switch version, I have often been able to get Sensor working without Snooping.

Craig and Greg, will you please help clarify this point?

 

As Greg states, DHCP snooping is used by IPDT feature specifically for having IP address information in the RADIUS access session.

 

As Craig states, Device Sensor doesn't use DHCP snooping? This is unrelated to the IPTD feature though. In other words, is DHCP snooping required for RADIUS Accounting-based DHCP profiling in ISE?

 

Also, is "DHCP Profiling" (ip helper based) setting required in ISE profiling configuration? Or is it enough to enabled RADIUS Accounting profiling in order to use DHCP profiling information that came from RADIUS Accounting messages from IOS XE Device Sensor?

 

 

This is an old post and the technology has evolved somewhat since. As Craig mentioned, the functionality could vary depending on the switch hardware/software versions.

If you're using current IOS-XE based switching platforms (like the Cat9k), you should follow the guidance around device sensor and device tracking in the Secure Wired Access Prescriptive Deployment Guide.

 

The DHCP Probe in ISE (ip helper based) should be disabled unless you need to accommodate switch platforms that do not support Device Sensor.

Hi romanrodichev@iementor.com ,

 beyond what @Greg Gibbs said ...

 Please take a look at Configure Device Sensor for ISE Profiling:

"... Device Sensor is a feature of Access Devices. It allows to collect information about connected endpoints. Mostly, information collected by Device Sensor can come from the following protocols:

Cisco Discovery Protocol (CDP)
Link Layer Discovery Protocol (LLDP)
Dynamic Host Configuration Protocol (DHCP)

Once the information is collected, it can be encapsulated in RADIUS Accounting and send to a Profiling Server (ISE)..."

Enable RADIUS Probe on ISE to collect that information.

 

Hope this helps !!!

Does Device Sensor for DHCP require DHCP snooping?

Hi romanrodichev@iementor.com ,

 please yo can also take a look at the following post: ISE and DHCP Snooping.

 

Hope this helps !!!

Thank you Greg and Marcelo, I will review this document. Marcelo, your link confirms that Device Sensor’s DHCP profiling also requires dhcp snooping. So both features, IPDT and Device Sensor, require DHCP snooping, unless some IOS XE versions have a different behavior. I'm trying to figure out what are these differences and which versions. I am also curious if IPDT is still needed in today's deployments (latest 9Ks).

 

The main reason I am asking these questions is that I would like to pinpoint what, if any, behavior changes for IPDT, device sensor, and DHCP snooping in cat9Ks?

A change was made from the IOS-XE 16.x code to move from the traditional IPDT to SISF-based Device Tracking.

The deployment guide I suggested uses configuration based on this newer feature.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: