03-21-2025 03:22 AM
We have SDA deployment with ISE. For authentication we use mainly MAB. Here is how ISE is configured:
This works beautifully for most devices but the issues has been reported that these type of devices stopped getting IP addresses once the switch ports were enabled with authentication (even if its only open-auth):
All these devices have one thing in common – they all considered as ‘IP Phones” and can do CDP or LLDP.
After investigation we found that ISE is doing what it supposed to be doing. The authentication succeeds and the correct authorization profile is applied. We can see on the switch that the mac address of the device is put on the correct access vlan. But Wireshark shows complete different picture. It shows that the device is using voice vlan and trying to get DHCP IP on that vlan. The device is using ‘critical’ vlan deployed by DNAC by default. It’s vlan 2046 (VOICE_VLAN).
If we manually install command ‘no CDP enable’ (or no lldp, depending on what device that is) on the switch port then the device is successfully using ISE assigned vlan and all is good.
Is this expected behaviour? How can we authenticate CDP and LLDP capable devices on non voice vlan? We can’t go around the estate disable CDP and LLDP on random interfaces. Especially LLDP, this is needed for proper IP phones that need to be on voice vlan.
We thought of using dynamic interface templates, but the problem with those is that CDP and LLDP is not an option for those templates. On catalyst 9300 switches in template configuration there is no option for CDP and LLDP. Any other ideas?
I would be interested to know how other people solve this problem?
03-23-2025 02:08 PM
I haven't seen a wireshark decode of this in a while, but I recall that the CDP and LLDP is sent as untagged traffic. One of the reasons for having CDP and/or LLDP on interfaces is to exchange information between switch and voice endpoint about which VLAN to use for voice traffic. I can't recall who tells whom, but IIRC, the e.g. if the switch has a "switchport voice vlan 100" then this is communicated to the endpoint and the end point will tag the voice data with VLAN 100. I have seen the same behaviour as what you're describing when there is no voice VLAN configured. Telephony devices CAN operate on the access VLAN but it's not the best way to operate them - mostly because deskphones have the additional Ethernet port to attach another DATA device such as PC etc - and in that case, the voice traffic must be separate from the data traffic - instead of using an 802.1Q trunk, the Cisco switch support DATA and VOICE domains - traffic tagged with the voice vlan is in the VOICE domain. And the untagged traffic is in the DATA domain.
The issue with voice VLAN and NAC, has always been that you cannot dynamically assign the voice VLAN via RADIUS attributes. The voice vlan is statically set on the interface. You might get lucky with interface templates if your IOS supports it.
Not sure if that helps
03-24-2025 02:20 AM
Thanks for the reply. For normal IP Phones we of course use voice vlan and that works fine with ISE authentication. For the other devices that I listed above we must use access vlans as they have nothing to do with our voice vlan.
We are not trying to dynamically assign voice vlan, we are trying to make sure that device is not using voice vlan and dynamically asign access vlan. No vlans or voice vlans are statically set on the interface.
If authentication is disabled on the port and we manually set required access vlan then those devices work just fine on that vlan. What is it with aaa authentication that prevents the device from using access vlan assigned by ISE?
I cant find a way to use interface templates unfortunately as described above.
03-24-2025 01:37 PM
"What is it with aaa authentication that prevents the device from using access vlan assigned by ISE?"
Ah ok - I think I understand your question now. With those devices that must NOT communicate on the voice VLAN (if a voice VLAN is configured on the interface) then ISE must NOT return the Cisco AVPair (cisco-av-pair = device-traffic-class=voice) that tells the switch to assign that endpoint to the VOICE domain (untick "Voice Domain Permission").
Create a new Authorization Profile for those devices (and of course, have a corresponding Authorization Rule that applies to these devices, however best you can - e.g. if you have Advantage Licenses, then use Profiling, else use Endpoint Identity Groups etc.)
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