Dynamic vlan using Cisco ISE

[Chaminda1912]

Hi all,

we have deployed voice solution across the estate using dynamic vlan via Cisco ISE. All the switches configured with vlan 5 as the default vlan and voice vlan will be vlan 488 ,deployed via cisco ISE using dynamic vlan.

My question is , if both ISE nodes (primary and secondary) goes down , will it break the voice traffic as dynamic vlan will enforce via cisco ISE and if both ISE nodes gone down , default vlan (vlan 5) will be passing traffic oppose to voice vlan (488).

Appreciate your advise on this 

[Aref Alsouqi]

Assuming you have two ISE node deployment, if both nodes go down the authentication of the new sessions will be failing in the first place. However, the old sessions that passed the authentication and been authorized to the newtork will not be affected until the sessions lifetime expired. One thing you could potentially configure to work around this potential risk is to configure critical VLANs. The critical VLANs will kick in when both ISE nodes are down, and they will assign the critical VLANs you defined until ISE is back online.

Critical Voice VLAN Support

[Chaminda1912]

@Aref Alsouqi when ISE nodes goes down completely , will  voice vlan fallback from vlan 488  to vlan 5 as ISE cannot enforce the dynamic vlan

[Jonatan Jonasson]

This entirely depends on your switch config in combination with your environment.

To start with, if the voice-vlan is relatively static across your deployment, you can have the voice-vlan statically assigned while using dynamic vlan for the data traffic. 

But if you want to use dynamic vlans for both voice and data, and If you're using IBNS-2.0 type config, you can suspend periodic re-authentications when the switch detects that all radius servers are down.
This keeps currently connected devices still online while you work on getting both ISE nodes back online.
(In many cases the collaboration equipment (phones & video equipment) aren't frequently disconnected/rebooted, so as long as they remain connected they maintain the previously allocated voice vlan.)

And then as Aref mentions, you can configure a fallback(critical) vlan if you want traffic to pass when the ISE nodes go down.

But ideally the focus should also be on making a design where the possibility of both ISE nodes going down at the same time is minimal.

[Arne Bier]

Regarding dynamic VLAN assignment for the DATA VLANs during a total RADIUS outage, there is a way to engineer  the critical auth VLAN assignment to be a little more intelligent. As mentioned already, existing sessions will have their re-auth paused. But what about NEW endpoints connecting?  The voice VLAN permission will be assigned to the configured Voice VLAN on the interface - since voice VLANs are not dynamically assignable via RADIUS, this is a safe solution. But for the access/DATA VLAN, the critical auth VLAN depends on the Service-Template that is assigned to the Policy Map, which is tied to the interface. If you use the same Policy Map on all interfaces, then the critical auth VLAN will always be the same for all new endpoints connecting. The trick to making this a bit more deterministic, is to create multiple Service Templates - one for each VLAN you need a critical auth for - then create duplicates of your Policy Map, and edit the Service Template assignment in each one. Lastly, duplicate your Interface Templates that refer to the customised Policy Maps - and finally, assign the custom Interface Templates to targeted interfaces where you know you have critical devices that need their custom critical VLANs.

Realistically though, I would only do this if there was a 100% requirement to always assign the correct VLAN to the interface even in the event that RADIUS has a total failure.  The probability of total RADIUS failure should be really low, multiplied by the probability of a new wired endpoint connection at the same time ... even lower.

What I propose is a lot of. And if you're after an alternative solution, then don't do dynamic VLAN assignment - but rather set the access VLAN on each interface, and have your IBNS 2.0 Critical Auth perform an "authorize" - which has the same effect. 

There is no silver bullet - but with some effort, you can engineer some intelligence into each switch. 

[Chaminda1912]

@Arne Bier Data vlan is not deployed via Dynamic vlan . Its only for the voice traffic . we have a dedicated data vlan deployed as default vlan 5 and using dynamic vlan via cisco ISE to enforce vlan 488 for Voice .

So to be clear, for vlan 488 , i have configured svi in sdwan routing ,trunked via switches and dhcp scope created for vlan 488. 

Question is , in case if both ISE nodes go down , will it impact the voice traffic for existing connected handsets ? As it cannot enforce vlan 488 via cisco ISE and does that mean it will fall back to its configured default data vlan ?

[Aref Alsouqi · Accepted solution]

The existing sessions won't be affected as those ones would have gotten their attributes applied already, so those existing sessions will keep working just fine until they need to reauthenticate. In that case given ISE nodes will be down the switch won't be able to rely on ISE for any authentication or authorization attributes, and if you have configured the critical VLANs, the switch will apply the data critical VLAN for date, and the voice critical VLAN for voice. The end result from the users experience perspective is that they will still be able to do their job and they won't notice anything from what's happening in the background. When ISE nodes come back online those sessions will be reauthenticated and reauthorized again.

[Chaminda1912]

@Aref Alsouqi  Thanks Aref, we have tested yesterday  in our Pre-prod environment and remove the ISE configuration from switches ( sort of to have a scenario where ISE nodes are down) and checked today after 24hrs and connected handsets are working as expected with no issues and our default re-auth time period is 1hr. But I couldn't check if voice vlan has failed back to default data vlan (vlan 5)

[Arne Bier]

@Chaminda1912 - what you are describing is not dynamic VLAN assignment. A RADIUS server returning the voice-permission attribute to the switch is not dong anything to set the VLAN - the voice permission simply tells the switch to process that MAC address in a different "domain" (the VOICE domain). The voice VLAN is already set on the interface and cannot be dynamically set via RADIUS attributes.

Dynamic VLAN assignment only concerns itself with the changing of the "access vlan" part of the interface config. 

In your scenario, your IBNS 2.0 is simply authorizing the voice permission. Show us what your IBNS 2.0 config looks like (in particular, the Service Template). But include all the parts (policy map and service template). You can choose which VLAN you want to set during critical auth - and I think you can also choose to not set a value, but just authorize what is configured on the "access vlan ..." on the interface.

ISE Secure Wired Access Prescriptive Deployment Guide - Cisco Community

[Chaminda1912]

@Arne Bier Can I respectfully disagree with the above explanation .

What we have set up is as below .

we have dedicated data subnet (vlan 5) configured on the access port . When a voice handset connects , radius server will recognise the mac adddress of that handset (as we have created a profile and add all the mac addresses ) that its a voice handset and radius rule has created to dynamically assign a vlan (Vlan 485) for that voice traffic .

Also once the port has dynamically assign to vlan 485 ,appropriate trunking ,svi's in sdwan and related dhcp scope has created for vlan 485 where voice handset will get an ip from.

So far testing was quite promising , just some questions highlighted above to get bot more clarity..

[Arne Bier]

@Chaminda1912 - sure no problem - let me explain a bit further.

It is technically possible to operate a desk phone on the access VLAN (as you have demonstrated). This means that the phone's control/voice/signalling traffic is in the untagged state, and the MAC address of the phone is in the DATA domain for that switch interface.

However, typical corporate setup is to have a phone and a PC at a desk - we don't want to run two Ethernet cables to each desk. So we plug the phone into the Ethernet, and piggy-back (daisy chain) the PC onto the back of the phone (if the phone has a PC port for this purpose).  Now you have two MAC addresses on the same LAN switch port (phone MAC and PC MAC addr). If you wanted to keep the PC traffic segmented from the voice traffic, you need a VLAN. How do you segment an access VLAN?  You can't. You'd need a trunk, but we don't do it that way.  We configure a voice VLAN on the switch and an access VLAN. The phone has to be either hard coded to tag all its traffic with the voice VLAN ID, or, it can learn this via LLDP/CDP. This is the typical way a phone is connected to a switch. It ensures that the phone traffic gets treated properly in its own voice VLAN (security and QoS etc) while the PC is using untagged traffic on the access vlan. ISE/RADIUS can dynamically set the access VLAN - but it cannot dynamically set the voice VLAN (not sure why). RADIUS servers signal that the MAC address must use the VOICE domain by setting the voice-permission Cisco AVPair RADIUS attribute. 

If you are connecting a PC to the back of your phone in your current configuration, you should see that the PC's MAC address is in the same VLAN as the phone's MAC address. If that's what you want, then happy days.

[Greg Gibbs · Accepted solution]

Actually, this statement is no longer true...

"ISE/RADIUS can dynamically set the access VLAN - but it cannot dynamically set the voice VLAN (not sure why)"

If the Authorization Profile is configured for both 'Voice domain permission' and 'VLAN' settings, the dynamic VLAN assignment will apply to the Voice Domain. I'm not sure at what point this enhancement was made, but I've tested with recent ISE versions (3.3+) and Catalyst 9k switches, and it works as expected.

[Arne Bier]

thanks @Greg Gibbs - I'll have to test that in the lab - it would be useful to know what version of IOS-XE this was introduced.

[Chaminda1912]

@egregre Thanks for the reply. My question was: let's say both ISE nodes go offline. ISE will no longer be able to enforce the dynamic VLAN, hence it will fail back to the configured access VLAN on the physical port. (If so, will that receive a new DHCP IP from the configured VLAN?) Planning to test next week.

[Greg Gibbs · Accepted solution]

Depending on how you've configured your switch and reauth timers, the loss of connectivity to ISE will not impact already authorized ports. Any new endpoints connected would be subject to the Critical Authorization configurations defined (critical ACL, critical voice VLAN enablement, etc) if you are using IBNS 2.0 (which is highly recommended).

See the ISE Secure Wired Access Prescriptive Deployment Guide for more details and examples - https://cs.co/ise-wired