cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5502
Views
20
Helpful
19
Replies

WLC - what is the purpose of the Interface/Interface Group field?

Mottok
Level 1
Level 1

Hi, I am trying to get my head round how a WLC works at a basic level and I just cannot figure it out. Can anyone please explain to me the following scenario we have:

 

An SSID named "Ipad_WLAN' which uses local MAC filtering so doesn't look at ISE at all.

 

An Interface Group called 'Students' that consists of 10 interfaces (including one called "STUDENT-MAIN").

 

In the WLANs > Edit 'Ipad_WLAN' section there is a field called 'Interface/Interface Group(G)' which is set to use the 'Students(G)'

 

Now can somebody please tell me, why use an interface group here (or what's the purpose) when the SSID always associates to the "STUDENT-MAIN" interface?

 

The same is also true on one of our other SSID's that goes through ISE. It uses the same interface group 'Students(G)' but associates to an interface that's not even in that group!

 

Please can someone explain this to frustrated noob. Many thanks.

1 Accepted Solution

Accepted Solutions

Jay Vivas
Cisco Employee
Cisco Employee

In the WLC we always take the most specific config for a client. In this case, the interface or interface group on the WLAN is the least specific config as it would apply to every client that joins it. If, for instance, you had an AP group with this WLAN tied to a different interface the clients on that WLAN and using APs in that group would take the interface from that AP group. This is a more specific config because not only do the clients have to be on that WLAN but they also have to be using APs in that group. In your case, when using the local mac database, there is a config for the interface to use when you add the mac address to the WLC. This config would be the most specific because it is only tied to one client. In ISE, you can send back an avp with the VLAN you want them to be put on. If the WLAN has AAA override enabled the WLC will apply the VLAN sent back from ISE.

 

I hope this answers your questions. Let me know if it doesn't.

View solution in original post

19 Replies 19

Jay Vivas
Cisco Employee
Cisco Employee

In the WLC we always take the most specific config for a client. In this case, the interface or interface group on the WLAN is the least specific config as it would apply to every client that joins it. If, for instance, you had an AP group with this WLAN tied to a different interface the clients on that WLAN and using APs in that group would take the interface from that AP group. This is a more specific config because not only do the clients have to be on that WLAN but they also have to be using APs in that group. In your case, when using the local mac database, there is a config for the interface to use when you add the mac address to the WLC. This config would be the most specific because it is only tied to one client. In ISE, you can send back an avp with the VLAN you want them to be put on. If the WLAN has AAA override enabled the WLC will apply the VLAN sent back from ISE.

 

I hope this answers your questions. Let me know if it doesn't.

Thank you so much for replying, that really helps. I like the explanation of “most specific”, that helps to visualise it better. I have gone through our setup again and you are indeed correct, we also have AP groups setup for each of our WLAN’s (both for the local MAC authentication and for the AAA override).

I don’t know who set our system up in the past but it seems to me that having an interface group is completely redundant in these scenarios?

I just have two outstanding questions from this if that’s ok?

1. When I added my own mobile phones MAC address to the filtering list I changed the interface but it remained in the original interface, is this because we are using an AP group that is assigning the interface because it is more specific for the client?

2. Why use interface groups at all? If you have a basic WLAN that uses an interface group, how does the WLC chooses which interface to assign it to? And do they not go against one use of VLANS I.e. to make sure traffic is assigned to a specific VLAN?

That turned in to a few questions sorry. Anything you or anyone can do to answer these is greatly appreciated, getting there!

When you added your mac with an interface it should take that interface. You would have had to re-authenticate as the interface would be applied then. Adding a mac address to the filter doesn't kick the client off and we wouldn't change the VLAN after the DHCP process or the client would get blackholed. Try removing it from the client database(config client deauth <client mac>). when it comes back on does it not take the interface you set in the mac filter?

 

Interface groups are used for a number of reasons. The most common is that there are a lot of users on one WLAN and the network admin didn't want to create a broadcast domain large enough to facilitate all the clients. To help with this problem you can create a group of interfaces(VLANs) and spread the client load out across all of them. Our docs say it is round-robin but actually, it is an algorithm runs against the mac address and the current load which is why clients might stay in the same interface every time they join.

 

Another reason for interface groups is redundancy. If we are unable to get clients an IP address on one interface we will mark it as dirty and not add any more clients to it for some time. This way if you had subnets with the gateway for each on a different router, and one router went down, all new clients would use the other one. Or if the DHCP pool on one interface filled up due to a network issue or just overutilization, we would start putting clients on the other interfaces in the group.

 

The third main reason would be that some devices have static IP addresses but they are in different subnets. All these clients would be able to connect to this WLAN with their static IPs and we would put them on the interface that matches the subnet they are in.

 

I'm not sure what you mean in the last part of question 2 but all interfaces on the WLC are tied to a specific VLAN and subnet so the interface they are put on would decide their VLAN/subnet.

Hi, many thanks again for your replies, they are really helping my understanding.

Re the Ipad_WLAN (MAC security list) - I tried removing my device from the list and disconnecting from wi-fi etc but it always connects to the "student" interface and not the "staff" one I assigned in the MAC list. The "student" interface is the one that is set in the AP group for the Ipad_WLAN SSID. I take it though, that you are saying that the MAC security list interface should be taking precedence as it is the most specific for the client?

I have not tried clearing the client database so will try that tomorrow when I return to work.

Regarding the interface groups - I understand now, the thing that was cinfusing me is that our organisation has setup the group to include VLAN's from all over the place (geographically) which doesn't make much sense from a VLAN perspective?
Many thanks.

One other thing - never used the CLI before, is the "config client deauth <client mac" CLI based and if so that's fine but is there a way to do this via GUI too? Thanks

On the GUI Monitor- Summary - Client Summary - Current Client Detail
Click on your client
Click the Remove button at top right (with the client device Wifi turned off)
That ensures the device is fully removed then will start afresh at next association.

Thanks for that, like it simple :-)

The device would have timed out overnight so you shouldn't need to deauth it this morning. On your WLAN Advanced tab, on the right side, you should see a setting called NAC. Is this set to RADIUS or ISE NAC? When you setup mac auth, if aaa is still enabled, it will check the local database first and then go to a server on the global list. If the mac state is set to ISE NAC or RADIUS NAC it will not check the local database and only use the AAA servers.

 

In the CLI(you should start using this :) we can run some debugs to see where the client is getting the vlan from.

 

debug client <client mac address>

debug aaa all enable

 

debug disable-all --- This will stop all debugs. These will probably fill your buffer so you will need to log this to a text file somewhere.

 

Are you able to open a TAC case with Cisco? If so let me know the sr number once you open it and will will get on a webex with you to show you how to do this and discuss the findings.

Hi, just checked and it the NAC is set to 'None'. I'll have a crack at that code when I get back to work and let you know. Many thanks for all your help.

Hi, checked again this morning and still on the "student-main" interface and not the "staff-main" one, hmmm. I want to run these commands to find out what's going on but wanted to check and will pipe to a txt file but when you say the buffer maybe full, do I need to do anything after I end logging to clear the buffer or am I ok to just exit the terminal at that stage?

Many thanks.

The buffer I was talking about was the session buffer. It depends on what you use to get into the box. Putty is the easiest. When you open putty there is a place where you put in the IP address to ssh(default) to the WLC. Before you open that, look to the left and under session, you will see logging. Here change it to log "all session output", then browse to where you want it stored and give it a name. This will print all the output from the WLC ssh session to a text file. Then open the session and run the two debugs. then bring the client on for a fresh session. If the client can be found in the client table remove it with the command "config client deauth <client mac>". To stop all the debugs from running, use the command "debug disable-all".

Hi, yes that's what I normally do when connecting to switches so that fine. I'll give that a go and let you know the results. Many thanks once again for all your help!

Well I managed to get some debugging up but struggling to understand it! Does the below give any clues at all to what's going on? Seems to assign the interface twice. It ends up on VLAN 385 and I would have expected 384 as that's what my MAC filtering interface is set to for my device. I've changed some of the numbers to *, probably for no reason at all :-) Thanks

*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Assigned interface 'block f' from interface group 'students' for the client
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Applying Interface(block f) policy on Mobile, role Local. Ms NAC State 2 Quarantine Vlan 0 Access Vlan 385

THEN

*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Applying site-specific Local Bridging override for station a4:50:**:0f:**:ef - vapId 4, site 'Admin-Block', interface 'student-main'
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Applying Local Bridging Interface Policy for station a4:50:**:0f:**:ef - vlan 385, interface id 10, interface 'student-main'
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef override from ap group, removing intf group from mscb
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Applying site-specific override for station a4:50:**:0f:**:ef - vapId 4, site 'Admin-Block', interface 'student-main'
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Applying Interface(student-main) policy on Mobile, role Local. Ms NAC State 2 Quarantine Vlan 0 Access Vlan 385

*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Re-applying interface policy for client

*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef 192.16*.13*.67 RUN (20) Changing IPv4 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2914)
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef 192.16*.13*.67 RUN (20) Changing IPv6 ACL 'none' (ACL ID 255) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:2955)
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef processSsidIE statusCode is 0 and status is 0
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef processSsidIE ssid_done_flag is 0 finish_flag is 0
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef STA - rates (6): 182 36 48 32 96 108 0 0 0 0 0 0 0 0 0 0
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef suppRates statusCode is 0 and gotSuppRatesElement is 1
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef pemApfDeleteMobileStation2: APF_MS_PEM_WAIT_L2_AUTH_COMPLETE = 0.
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef 192.16*.13*.67 RUN (20) Deleted mobile LWAPP rule on AP [38:*0:a5:*0:2d:*0]
*pemReceiveTask: Feb 24 15:22:03.318: a4:50:**:0f:**:ef 192.16*.13*.67 Removed NPU entry.
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef Updated location for station old AP 38:*0:a5:*0:2d:*0-1, new AP 38:*0:a5:*0:2d:*0-0
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef 192.16*.13*.67 RUN (20) Applied RADIUS override policy
*apfMsConnTask_0: Feb 24 15:22:03.318: a4:50:**:0f:**:ef 192.16*.13*.67 RUN (20) Adding Fast Path rule

Make sure you enable "Allow AAA override" on the advanced tab of the WLAN. I believe this is why we cant override the interface here.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card