topic Re: DHCP option parameters of third party switch in Network Access Control

DHCP option parameters of third party switch

pgamage — Tue, 24 Sep 2024 11:13:20 GMT

We have added 3rd party switch to the ISE and switch send MAB authentication request along with DHCP options.

HW-DHCP-Option=SEP70DA48E8B074;
HW-DHCP-Option=1 28 3 15 6 12 42 119 242 120 66 150 43 252;
HW-DHCP-Option=Cisco:Codec:1.0;

The label "HW-DHCP-Option" is vendor specific, we can translate this name to the name desired by ISE.

Can someone tell me what label I should use to convert so that ISE would accept it?

Re: DHCP option parameters of third party switch

ahollifield — Tue, 24 Sep 2024 15:54:12 GMT

So you mean like Cisco Device Sensor? Are these sent via RADIUS Accounting from the access switch in question? https://cs.co/ise-interop

Re: DHCP option parameters of third party switch

MHM Cisco World — Tue, 24 Sep 2024 16:01:06 GMT

Why you want these dhcp op.?

MHM

Re: DHCP option parameters of third party switch

pgamage — Tue, 24 Sep 2024 16:29:47 GMT

Phones and codec devices need to be authenticated by the ISE. Switch send phone and codec data collected by DHCP snooping to the ISE for profiling. Its Mac Address Bypass authentication. Everything is RADIUS.

Re: DHCP option parameters of third party switch

Aref Alsouqi — Tue, 24 Sep 2024 17:06:35 GMT

Please take a look at DHCP Attributes section in this guide:

ISE Profiling Design Guide - Cisco Community

Re: DHCP option parameters of third party switch

ahollifield — Tue, 24 Sep 2024 17:08:40 GMT

So this switch uses RADIUS accounting to send these attributes? This will most likely be an enhancement request, I’m not aware of there being any customizations to Device Sensor/RADIUS probe behavior. I would open a TAC case and ask your account team.

Re: DHCP option parameters of third party switch

pgamage — Tue, 24 Sep 2024 17:42:22 GMT

No, these are sent with RADIUS authentication request. I guessed these information may help device profiling. I may be wrong. TAC would help but not an option in my situation. Kind of dead end.

Re: DHCP option parameters of third party switch

ahollifield — Tue, 24 Sep 2024 18:29:40 GMT

Why isn’t TAC an option? You can also always relay to ISE using an IP helper upstream. The access switch doesn’t have to send this information.

Re: DHCP option parameters of third party switch

pgamage — Tue, 24 Sep 2024 18:29:55 GMT

I will study this in depth. It suggest me that I must consider broader profiling data.

Re: DHCP option parameters of third party switch

MHM Cisco World — Tue, 24 Sep 2024 19:17:13 GMT

3rd party SW' can I know exactly what is SW model

MHM

Re: DHCP option parameters of third party switch

Arne Bier — Tue, 24 Sep 2024 21:47:40 GMT

Have you tried making a Network Device Profile for this vendor product? You can start by creating a RADIUS dictionary definition into ISE to populate the custom attribute(s) you need, and then you can craft your own MAB and 802.1X authentication detection Rules based on that. It means that ISE will do all the attribute matching/checks for you, based on your custom logic.

If you're only after one RADIUS attribute "DHCP Option" then you could also create that one manually, and ensure you set it as a STRING and has tick box set for "Allow multiple instances of this attribute in a profile". I just made up the Attribute ID "5" (you can get the true values from a tcpdump/wireshark decode)

Once you have this Device Profile, you can apply it to your 3rd party switch Network Device configuration (instead of the default Cisco value). But also be aware, that any Authorization Profiles sent to such a custom device, must also be tagged with this Vendor Profile, or they must be "blank" (i.e. apply to all vendors - as an example of this, the ISE built-in Access-Accept is vendor neutral)

I believe that, by adding the 3rd party device into ISE's RADIUS Dictionary, you will have access to these attributes in your Policy Set logic, and also Profiling logic (Type:RADIUS Attribute Name: VendorSpecific Operator: EQUALS Attribute Value: {VendorID})

I reckon this should be worth a try.