cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1024
Views
7
Helpful
12
Replies

multiple data vlans across wired NAC

arane0001
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

Arne Bier
VIP
VIP

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.

View solution in original post

12 Replies 12

Arne Bier
VIP
VIP

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. 

 

arane0001
Level 1
Level 1

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. 

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

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. 

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

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. 

Arne Bier
VIP
VIP

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

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

Arne Bier
VIP
VIP

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.

arane0001
Level 1
Level 1

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!! 

You are so so welcome 

Have a nice summer 

MHM