06-10-2024 01:43 PM - edited 06-10-2024 02:04 PM
We have a campus network which is distributed across buildings using different data and voice networks. These vlans on the MDF are labelled as vlan 20 (data) and vlan 30 (voice). When deploying the wired NAC configurations on the distribution switches with ONLY vlan 20 and 30 is not a a problem. But some MDF has vlan 20 and 30 as voice and data and also vlan 21 and 31 as part of another network which resides on the same MDF. How do I deploy NAC on those switches? I know the hard way to do it is configuring multiple templates, service map and policy maps on those switches and then apply different template to the switch port as per the vlan needed.
There is got to be an easy way that I am not aware of. Can someone help me? If I have not explained my ongoing issue clearly do let me know.
Solved! Go to Solution.
06-12-2024 03:26 PM
Regarding what @MHM Cisco World mentioned about the NAS-Port-ID - if you had a 100% consistent switch setup where EVERY switch had the same pattern, e.g.
Gig1/0/1-48 - VLAN 20
Gig2/0/1-48 - VLAN20
Gig3/0/1-48 - VLAN21
etc.
Then using NAS-Port-ID would make sense. What are the chances that ALL your switches are like that? And anyway, if your switch port assignments are so regimental, then what's the point of doing dynamic VLAN assignment? You may as well just set the access vlan to be static on all those interfaces accordingly, and just return an Access-Accept & dACL etc. The whole point of making life and configuration on switch and ISE easier/repeatable, is not to rely on any rules/constructs. Instead, the "work" involves making the endpoints and switches play their part (DHCP)
What happens then all RADIUS servers are dead? There is a critical auth vlan that will be applied in that case. Whether it's IBNS 1.0 or IBNS 2.0 - same logic applies - you can tell the switch to go into emergency mode for DATA VLAN and set the voice domain. But, you guessed it, it's the same logic for all interfaces. So you would not use a VLAN ID - you'd use a VLAN Name (which is a VLAN Group containing multiple VLAN IDs). If that VLAN group ID doesn't work for you, then in IBNS 2.0 you would have to create multiple Policy Maps, each of which has it's own Critical Auth VLAN definition. And then put that Policy Map into a distinct Interface Template, and then assign those templates to the respective interfaces. It's all explained in the Wired Prescriptive Guide.
The ultimate solution for all of this would be SDA (Cisco Software Defined Access) - no messing around with access VLANs for endpoints - using SGTs instead. I thought I would mention it, although the upheaval is often more than most customers would entertain. But it's something to strive for.
06-10-2024 02:22 PM
The better way is to NOT use VLANIDs in the ISE Authorization Profile, but instead, return a VLAN Name. E.g. each switch can have the same named VLAN, but with its own VLAN ID
Switch1: VLAN Name: Corp_Data - VLANID 20
Switch2: VLAN Name: Corp_Data - VLANID 20
Switch3: VLAN Name: Corp_Data - VLANID 21
etc.
When ISE returns the AuthZ Profile containing the VLAN Name of "Corp_Data" then the switch translates that into the corresponding VLANID for the switchport.
if you have many VLANs on the same switch (e.g. large stack) and you need one VLAN per switch stack member, then you can use VLAN Groups. A VLAN Group is a collection of VLANs (VLAN20,21,22,23,etc), and you are not in control over which VLAN the endpoint lands up in - the switch applies a hashing algorithm to select a VLAN in the group, and then listens for the DHCP Ack to ensure that the client got an IP - if it doesn't (e.g. DHCP scope exhausted), then it re-hashes. This assumes all endpoints use DHCP.
06-11-2024 06:26 AM
Arne, Thank you for your response. assigning it with vlan name in ISE does make sense if there was one data vlan across those switches.
The only problem in this solution is that devices in those vlans we have static IP addresses and we are limiting access to the network as well.
if you have many VLANs on the same switch (e.g. large stack) and you need one VLAN per switch stack member, then you can use VLAN Groups. A VLAN Group is a collection of VLANs (VLAN20,21,22,23,etc), and you are not in control over which VLAN the endpoint lands up in - the switch applies a hashing algorithm to select a VLAN in the group, and then listens for the DHCP Ack to ensure that the client got an IP - if it doesn't (e.g. DHCP scope exhausted), then it re-hashes. This assumes all endpoints use DHCP.
06-12-2024 06:26 AM
you can config Authz policy and select NAS-ID (SW ID) with action return specific VLAN ID or NAME to that SW
i.e.
authz policy for each SW
MHM
06-12-2024 10:54 AM
Yes, but how would I assign the port that particular vlan ? How would ISE identify which device to handover the respective data vlan ?
The whole scenario is to make two data vlans work on the same switch.
06-12-2024 11:00 AM
The whole scenario is to make two data vlans work on the same switch. <<- that the key
there is NAS-ID for SW
NAS-Port-ID for Port in same SW
so instead of using Authz policy per SW use it per Port
MHM
06-12-2024 01:55 PM
https://community.cisco.com/t5/network-access-control/ise-nas-condition-for-port-range/td-p/3724467
This for you @arane0001
Take look about my suggestion for your issue
MHM
06-12-2024 02:57 PM
I see your solution. the only problem is it will be a nightmare to manage. Also, I will endup creating lot of policies in ISE. I can still use it in some places.
06-12-2024 01:44 PM
@MHM Cisco World - what would the ISE AuthZ look like (give us an example) in an environment of different Cisco switch models, and interface types (Gig, Twe, Ten, etc.) ?
I still believe that if you've go so many ports that you had to create more VLANs (20,21,22, etc.) then you must be dealing with something like desktop PCs? Surely you're not using static IPs on those? What are the devices that you need static IPs for? Can't you put them in their own VLAN instead? I guess that would require some addressing changes and L3 planning.
Either way - there is no simple way out. ISE cannot do the job easily without some guidance (NAD-Port-ID) and then it will have a very complex set of rules and logic to apply.
I am still of the opinion that returning the VLAN Name to the switch is the cleanest option (in cases where a single switch(stack/chassis) has VLAN_Name = VLANID
But in cases where you have multiple VLANIDs for the same function, then the VLAN Group concept (which is widely used on wireless controllers BTW) is the way to go - you don't make the switch's problem, ISE's problem. Let the switch hash it out.
Devices with static IPs are always a problem (making profiling tricky, and just a PITA in general) - easy for me to say, but if the device supports DHCP, rather use that and make static reservations in your IPAM/DHCP.
06-12-2024 03:04 PM
@Arne Bier PCs are not the problem but we have some old applications which run on devices that are directly pointing to static IP address across the internal network which has been set years ago ( i will have to spend time digging those devices). Once I group the vlans, those devices will be handed DHCP addresses but I won't know which devices they will be. The user will just report to us saying it's not working and I am talking about a /20 network.
Here is another question when PSN nodes are not responding or if ISE deployment is down how will the multiple data VLAN scenario work?
06-12-2024 03:26 PM
Regarding what @MHM Cisco World mentioned about the NAS-Port-ID - if you had a 100% consistent switch setup where EVERY switch had the same pattern, e.g.
Gig1/0/1-48 - VLAN 20
Gig2/0/1-48 - VLAN20
Gig3/0/1-48 - VLAN21
etc.
Then using NAS-Port-ID would make sense. What are the chances that ALL your switches are like that? And anyway, if your switch port assignments are so regimental, then what's the point of doing dynamic VLAN assignment? You may as well just set the access vlan to be static on all those interfaces accordingly, and just return an Access-Accept & dACL etc. The whole point of making life and configuration on switch and ISE easier/repeatable, is not to rely on any rules/constructs. Instead, the "work" involves making the endpoints and switches play their part (DHCP)
What happens then all RADIUS servers are dead? There is a critical auth vlan that will be applied in that case. Whether it's IBNS 1.0 or IBNS 2.0 - same logic applies - you can tell the switch to go into emergency mode for DATA VLAN and set the voice domain. But, you guessed it, it's the same logic for all interfaces. So you would not use a VLAN ID - you'd use a VLAN Name (which is a VLAN Group containing multiple VLAN IDs). If that VLAN group ID doesn't work for you, then in IBNS 2.0 you would have to create multiple Policy Maps, each of which has it's own Critical Auth VLAN definition. And then put that Policy Map into a distinct Interface Template, and then assign those templates to the respective interfaces. It's all explained in the Wired Prescriptive Guide.
The ultimate solution for all of this would be SDA (Cisco Software Defined Access) - no messing around with access VLANs for endpoints - using SGTs instead. I thought I would mention it, although the upheaval is often more than most customers would entertain. But it's something to strive for.
06-13-2024 07:21 AM
Thanks @Arne Bier @MHM Cisco World . I have even asked Cisco Rep they had no answer within the internal team as well. They instead told me to ask in the cisco forum. I appreciate your help!!
06-13-2024 07:29 AM
You are so so welcome
Have a nice summer
MHM
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