Issue profiling non cisco phones in ISE

[CSCO10576352]

Hi all, I’m reaching out to the community to see if anyone can hopefully provide and input/guidance to an issue we are encountering when trying to profile non Cisco phone handsets with Cisco ISE.

We are encountering the same issue with both Polycom CCX series phones and Yealink MP58 series phones.

We are using various DHCP criteria forwarded onto to ISE from the phones as the primary basis on which to create the profiling rules (for example dhcp-class-identifier and dhcp-parameter-request-list).

The VLANs is question are correctly setup to forward on DHCP request info from clients to our ISE node (IP helper entry for ISE IP addresses under VLAN SVI's), end to end routing is in place and there are no firewalls in the path.

With ISE/dot1x authentication turned off on the phones  switchport (no authentication port-control auto), ISE is able to see DHCP data generated by the phone.

However when ISE/dot1x authentication is enabled on the phone using the below example switchport template, ISE never see’s the DHCP criteria come through from the phone.

interface GigabitEthernet1/0/1

 description *** 802.1x for workstations and phones ***

 switchport access vlan 100

 switchport mode access

 switchport voice vlan 200

 authentication event fail action authorize vlan 999

 authentication event server dead action authorize

 authentication event server dead action authorize voice

 authentication host-mode multi-domain

 authentication order mab dot1x

 authentication priority dot1x mab

 authentication port-control auto

 mab

 dot1x pae authenticator

 spanning-tree portfast

 spanning-tree bpduguard enable

end

After much testing the only way we are able to ensure ISE see’s the DHCP information from the phone when ISE/dotx authentication is enabled on the phone is by removing the command “authentication host-mode multi-domain". DHCP information then arrives at ISE and ISE authorises the phone for access, the problem with this is that this command is required to allow the authentication of a second device through the same switch port  (i.e. the users laptop/PC) when connected through the back of the phone.

The authorisation profile in the profiling rules also has the “voice domain permission” enabled/ticked under common tasks to allow the phone access to the voice LAN so we do not believe that to be the issue. The associated DACL is open permit ip any any.

Is anyone aware of what may be preventing the DHCP criteria being either generated by the phone and/or forwarded to ISE when we have the command “authentication host-mode multi-domain" enabled under the switchport?

Additionally, where does the logic take place such that the phone knows that it should sit within the voice vlan and the PC connected through the phone should sit on the data VLAN, is this intelligence something that is built into the phone handsets themselves or is there a piece of logic in ISE that handles this aspect that we may have overlooked?

If anyone is able to offer any guidance it is much appreciated, thanks for taking the time to read through.

[Arne Bier]

Hi @CSCO10576352 

A Cisco switch port has two "domains" in which a single port can handle more than one MAC address. In the VOICE domain you can have one MAC address, and in the DATA domain you can have one or more MAC addresses (multi-domain allows one voice MAC and one data MAC). I don't see why this would single out DHCP data when in multi-domain mode. I have this setup working in many deployments.

ISE needs to send the "allow voice domain" RADIUS attribute when authenticating the phone - this configures the port's voice domain to allow the phone's MAC address to live there. Any other device(s) attached to the phone must not have that "allow voice domain" set - those devices will land in the data domain.  You will see this with the command "show access-session int xyz detail" - or in older IOS versions it would be "show authentication session ...."

If you have a relatively new IOS or IOS-XE then you can also try the Cisco Device Sensor feature to glean DHCP and CDP/LLDP info from the devices. If you can do this then you don't' need to send ip-helper data to ISE. Non-Cisco phones will most likely use LLDP and this is a great source of profiling data for ISE.

Setting up Device Sensor is a lot of commands - but it's pretty standard (and sometimes a bit fussy on the syntax, depending on IOS versions) - but it's a great feature. It will send profiling data to ISE via RADIUS Accounting updates. Check the Wired Prescriptive Guide here for more info.

[Marcelo Morais]

Hi @CSCO10576352 ,

 about your question "... where does the logic take place such that the phone knows that it should sit within the voice vlan and the PC connected through the phone should sit on the data VLAN ...", the switchport voice vlan & switchport data vlan command with the CDP packets (that informs the IP Phone about the Voice VLAN to be used) does "the magic" (in some cases you have to manually configure a Voice VLAN on the IP Phone).

Hope this helps !!!

[CSCO10576352]

Hi Marcelo, thanks for your response.

Its interesting you mention CDP being in play I wonder if that if where its falling down if the third party phones are unable to parse the CDP responses correctly. The option of manually setting the voice and data vlans on the phone side isn't something I had considered either as an option so i will definitely look into that. 

Thanks again for the helpful advice and for taking the time to respond.

[CSCO10576352]

Hi Arne, thanks for your response.

That confirms the reason we need the allow voice domain setting enabled in ISE, to also confirm this is not setup on the rule/policy that is used to authenticate/authorize the users PC/laptop so should be causing us any funnies in that regard.

I will take a look a the Cisco Device Sensor you mention, the problem we have currently given a recent IOS version is a mix of new/old switches and IOS version across the estate but this will be addressed in the future so it will be interesting to have a read up on this feature as both phones in question (Polycom/Yealink) do run CDP/LLDP.

Thanks again for the helpful advice and for taking the time to respond.