Dynamic vlan using Cisco ISE

[sasanka1912]

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

[sasanka1912]

@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. 

[sasanka1912]

@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]

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.

[sasanka1912]

@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]

@sasanka1912 - 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