04-22-2022 06:04 AM
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.
04-22-2022 03:35 PM
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.
04-23-2022 10:28 AM
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 !!!
04-25-2022 03:26 AM
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.
04-25-2022 02:58 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide