Re: [WIRELESS-LAN] WLC interface groups?

[Curtis, Bruce]

On Aug 28, 2019, at 4:42 PM, Jake Snyder 
mailto:jsnyde...@gmail.com>> wrote:

I’m a consultant and I HATE interface groups.

It’s more complexity and more things to go wrong. Not a big enough address 
block?  Re-subnet.  If the switch can’t handle the arp entries, it can’t handle 
the arp entries. Rarely does matter how many VLANs you spread them out from.  
And yes, I do get the amount of effort required to re-subnet.  I wouldn't 
suggest it if I didn’t feel it was worth the effort.

Remember the android bug where they would spam dhcp requests until the 
controller marked all the interfaces dirty?  I still have nightmares.  I 
continue to see interfaces in groups marked dirty at several universities and 
causing issues.

Also, option 3:
If you have broadcast from 32k clients, you have broadcast from 32k clients.  
Doing things like interface groups moves them from VLAN to VLAN, but does 
little to reduce the overall number or OTA, which is where it is the bigger 
problem.

  I agree that interface groups won’t decrease the total number of broadcast 
queries.
However with chatty protocols interface groups might reduce the number of 
replies to broadcasts.

We use interface groups for historical reasons from a time when we were still 
able to give each wireless client a public IPv4 address.
We have given each wireless client a public IPv6 address since 2008.

Interface groups does break mDNS discovery but Cisco’s mDNS gateway function 
has worked to fix that.

While we use interface groups on our main campus we use flex connect in our 
residence halls.


It also complicates things like IPv6 where due to a shared group encryption 
key, clients can hear RA from the other subnets.  This leads you down the 
“multicast to unicast conversion” solution to address, piling more complexity 
on to deal with the existing complexity.

However, I have one use case where interface groups make sense: public IP space 
where you don’t have a big enough single block.  I would prefer to keep them 
all in the same block, but this is a case where some orgs really can’t and with 
the shortage of IPv4, odds are you won’t be able to fix this without some huge 
cash outlays.

If you are going to use interface groups:
1. keep them all the same subnet size or the small ones will fill up first and 
cause issues.
2. Keep them them in 2^n sizes.  1, 2, 4, 8 it keeps the hashing easy and ends 
up with more evenly distributed usage.

Jake Snyder

Sent from my iPhone

On Aug 28, 2019, at 3:11 PM, Mark Duling 
mailto:mark.dul...@biola.edu>> wrote:

As James said, we use interface groups to select which set of networks to put 
users into based on their ldap membership within the same SSID. I also assumed 
at the time having small nets was better than larger ones as on wired networks, 
but I know it's different on wireless controllers so maybe thinking can be very 
different on that. But I'm not aware of a real argument against using interface 
groups.

We don't use public ip addresses, so running out of them isn't an issue for us. 
But there is the DHCP option in newer servers "one-lease-per-client" that 
allows a "single lease per client on a per member basis". I've never used it so 
I have no idea how well it works, but theoretically I guess that option might 
solve exhaustion issues when clients move between networks. But again, no 
experience with it but maybe others have  and can comment.

Mark


On Wed, Aug 28, 2019 at 1:16 PM James Helzerman 
mailto:jarh...@umich.edu>> wrote:
Hi.  On our main SSID we use Interface Groups so we can return a interface 
variable back via RADIUS that can be the same in each of our data nodes that 
has controllers.  This way VLAN numbers dont need to be same and in the case 
you mentioned if we ever need to add IP space for a quick short term its easy 
to add to the group.  We rely on the WLC to control the broadcasts and dont see 
any issues from it.  We dont do DHCP proxy on the controllers.  For our main 
SSID we currently have two /18 running at each of our three data nodes 
(different routers).  The biggest thing we have had to watch out and plan for 
was the routers resources in terms of ARP cache and timeout values.

We use Interface Groups on almost all our SSIDs by design.

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541


On Wed, Aug 28, 2019 at 3:56 PM Glinsky, Eric 
mailto:e...@uconn.edu>> wrote:
This question is for large universities with WLCs that tunnel traffic through a 
controller. Do you use a single interface (VLAN) for, say, 30k clients, or do 
you use two or more interfaces in an interface group, and why? Do you use DHCP 
proxy? Is there any documentation or generally-accepted rules of thumb on this?

Historically, on all three Cisco 8540 pairs, we had a core interface and an 
interface for res halls, and depending on the AP’s location (6k APs) our 
branded SSID would map clients to one interface or the other.

All our wireless 

Re: [WIRELESS-LAN] WLC interface groups?

[Jonathan Waldrep]

Disclaimer: we're an Aruba wireless shop. The specifics may vary, but the
concepts should translate. It sounds like interface groups is the Cisco
equivalent to vlan pooling on Aruba.

I agree with Jake and Richard. Go with one huge VLAN. Aruba put out a
Validated Reference Design [1] a few years back. We implemented it, and
haven't looked back. The short of it is VLAN pooling (or interface groups)
doesn't actually buy you anything except a lot of complexity.

[1]
https://community.arubanetworks.com/t5/Validated-Reference-Design/Single-VLAN-Architecture-for-WLAN/ta-p/508698

--
Jonathan Waldrep
Network Engineer
Network Infrastructure and Services
Virginia Tech


On Wed, Aug 28, 2019 at 8:00 PM Glinsky, Eric  wrote:

> Great information so far, everyone; thank you! Looking forward to hearing
> more.
>
> I guess I should have said earlier that we use SVIs on the wireless core
> (a 6500/Sup2T VSS pair) in the two VLANs. The SVIs have secondary
> interfaces for the various subnets.  Most are /24s, and a few odd /25s,
> /23s, and /22s, all public addresses. So, we don't need to have a series of
> interfaces in a group just for the sake of having multiple subnets, and
> it's pretty easy for us to re-subnet/re-balance if needed. The SVIs have
> DHCP helpers configured and DHCP requests go to Infoblox, where we have a
> shared network for each VLAN.
>
> We strictly use RADIUS for authentication; no dynamic VLAN assignments by
> AD group.
>
>
>
> Eric Glinsky
> Network Technician
> University of Connecticut
> ITS – Network Operations
> Temporary Administration Building
> 25 Gampel Service Drive | Storrs, CT 06269-1138
> (860) 486-9199
> e...@uconn.edu
>
> --
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Tariq Adnan <
> tariq.ad...@sydney.edu.au>
> *Sent:* Wednesday, August 28, 2019 6:44 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject:* Re: [WIRELESS-LAN] WLC interface groups?
>
>
> Hi Eric,
>
>
>
> We use Interface groups and they work fine. We have 4 x 8540 WLC’s, 6k x
> APs and we see 36K concurrent devices during semester.
>
>
>
>- Depending upon end user’s LDAP role (student or staff), radius
>server (Aruab CP server) returns a interface group to controller
>- For students, the interface group contains 64 interfaces, each /21
>private subnets (10.x.x.x/21)
>- For Staff, the interface group contains 32 interfaces, each /20
>private subnets (10.x.x.x/20)
>- The interface group failure mode is set to “non-aggressive” – this
>avoids interfaces getting dirty (frequently) and hence clients don’t jump
>from one interface to another and normally keeps same IP address (this
>avoids DHCP exhaustion).
>- We have enabled DHCP proxy on the controller
>
>
>
> -
>
> *Cheers,*
>
>
>
> *Kind regards,*
>
> *Tariq Adnan*  |  Senior Network Engineer
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Glinsky, Eric
> *Sent:* Thursday, 29 August 2019 5:36 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN] WLC interface groups?
>
>
>
> This question is for large universities with WLCs that tunnel traffic
> through a controller. Do you use a single interface (VLAN) for, say, 30k
> clients, or do you use two or more interfaces in an interface group, and
> why? Do you use DHCP proxy? Is there any documentation or
> generally-accepted rules of thumb on this?
>
>
>
> Historically, on all three Cisco 8540 pairs, we had a core interface and
> an interface for res halls, and depending on the AP’s location (6k APs) our
> branded SSID would map clients to one interface or the other.
>
>
>
> All our wireless clients have public IPs, and we’ve faced issues running
> out. Throughout the day, we’d see the majority of clients move from the res
> hall network to the core network, and vice versa at night. At one point, we
> merged both the interfaces in an interface group to utilize all IPs at all
> times. However, the way it’s currently set up, there are more IPs available
> in the core interface than in the res hall interface.
>
>
>
> We are considering these options on how to move forward with or without
> the interface group:
>
>
>
>1. Consolidating down to one interface. More efficient use of IP
>space, clients wouldn’t change IPs as often. Could probably increase lease
>time to 1 hour, but what about broadcast and ARP traffic for all 30k
>addresses in the VLAN at the router - understanding that

Re: WLC interface groups?

[Glinsky, Eric]

Great information so far, everyone; thank you! Looking forward to hearing more.

I guess I should have said earlier that we use SVIs on the wireless core (a 
6500/Sup2T VSS pair) in the two VLANs. The SVIs have secondary interfaces for 
the various subnets.  Most are /24s, and a few odd /25s, /23s, and /22s, all 
public addresses. So, we don't need to have a series of interfaces in a group 
just for the sake of having multiple subnets, and it's pretty easy for us to 
re-subnet/re-balance if needed. The SVIs have DHCP helpers configured and DHCP 
requests go to Infoblox, where we have a shared network for each VLAN.

We strictly use RADIUS for authentication; no dynamic VLAN assignments by AD 
group.




Eric Glinsky
Network Technician
University of Connecticut
ITS – Network Operations
Temporary Administration Building
25 Gampel Service Drive | Storrs, CT 06269-1138
(860) 486-9199
e...@uconn.edu<mailto:e...@uconn.edu>



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tariq Adnan 

Sent: Wednesday, August 28, 2019 6:44 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] WLC interface groups?


Hi Eric,



We use Interface groups and they work fine. We have 4 x 8540 WLC’s, 6k x APs 
and we see 36K concurrent devices during semester.



  *   Depending upon end user’s LDAP role (student or staff), radius server 
(Aruab CP server) returns a interface group to controller
  *   For students, the interface group contains 64 interfaces, each /21 
private subnets (10.x.x.x/21)
  *   For Staff, the interface group contains 32 interfaces, each /20 private 
subnets (10.x.x.x/20)
  *   The interface group failure mode is set to “non-aggressive” – this avoids 
interfaces getting dirty (frequently) and hence clients don’t jump from one 
interface to another and normally keeps same IP address (this avoids DHCP 
exhaustion).
  *   We have enabled DHCP proxy on the controller



-

Cheers,



Kind regards,

Tariq Adnan  |  Senior Network Engineer



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Glinsky, Eric
Sent: Thursday, 29 August 2019 5:36 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] WLC interface groups?



This question is for large universities with WLCs that tunnel traffic through a 
controller. Do you use a single interface (VLAN) for, say, 30k clients, or do 
you use two or more interfaces in an interface group, and why? Do you use DHCP 
proxy? Is there any documentation or generally-accepted rules of thumb on this?



Historically, on all three Cisco 8540 pairs, we had a core interface and an 
interface for res halls, and depending on the AP’s location (6k APs) our 
branded SSID would map clients to one interface or the other.



All our wireless clients have public IPs, and we’ve faced issues running out. 
Throughout the day, we’d see the majority of clients move from the res hall 
network to the core network, and vice versa at night. At one point, we merged 
both the interfaces in an interface group to utilize all IPs at all times. 
However, the way it’s currently set up, there are more IPs available in the 
core interface than in the res hall interface.



We are considering these options on how to move forward with or without the 
interface group:



  1.  Consolidating down to one interface. More efficient use of IP space, 
clients wouldn’t change IPs as often. Could probably increase lease time to 1 
hour, but what about broadcast and ARP traffic for all 30k addresses in the 
VLAN at the router - understanding that client device broadcast traffic doesn’t 
leave the controller except DHCP (we do not use DHCP proxy in the controllers).
  2.  Staying with the group of two interfaces and balancing the IP space 
between them. Avoids wasted IPs, depending how intelligent the 8540s are at 
distributing clients between all interfaces in the group.
  3.  Splitting out to more interfaces. We’d cut down on broadcast traffic but 
we’d be liable to have one client taking up three or more addresses between all 
the interfaces for up to the 30-minute lease time we have, and a client would 
change IPs more throughout the day as it re-associates and gets put in a 
different interface.



Interestingly, a consultant we’re working with hasn’t seen a single customer 
besides us use interface groups.



Eric Glinsky
Network Technician

University of Connecticut
ITS – Network Operations

Temporary Administration Building
25 Gampel Service Drive | Storrs, CT 06269-1138
(860) 486-9199

e...@uconn.edu<mailto:e...@uconn.edu>



**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam01.safelinks.protection.outlook

RE: WLC interface groups?

[Tariq Adnan]

Hi Eric,

We use Interface groups and they work fine. We have 4 x 8540 WLC's, 6k x APs 
and we see 36K concurrent devices during semester.


  *   Depending upon end user's LDAP role (student or staff), radius server 
(Aruab CP server) returns a interface group to controller
  *   For students, the interface group contains 64 interfaces, each /21 
private subnets (10.x.x.x/21)
  *   For Staff, the interface group contains 32 interfaces, each /20 private 
subnets (10.x.x.x/20)
  *   The interface group failure mode is set to "non-aggressive" - this avoids 
interfaces getting dirty (frequently) and hence clients don't jump from one 
interface to another and normally keeps same IP address (this avoids DHCP 
exhaustion).
  *   We have enabled DHCP proxy on the controller

-
Cheers,

Kind regards,
Tariq Adnan  |  Senior Network Engineer

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Glinsky, Eric
Sent: Thursday, 29 August 2019 5:36 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] WLC interface groups?

This question is for large universities with WLCs that tunnel traffic through a 
controller. Do you use a single interface (VLAN) for, say, 30k clients, or do 
you use two or more interfaces in an interface group, and why? Do you use DHCP 
proxy? Is there any documentation or generally-accepted rules of thumb on this?

Historically, on all three Cisco 8540 pairs, we had a core interface and an 
interface for res halls, and depending on the AP's location (6k APs) our 
branded SSID would map clients to one interface or the other.

All our wireless clients have public IPs, and we've faced issues running out. 
Throughout the day, we'd see the majority of clients move from the res hall 
network to the core network, and vice versa at night. At one point, we merged 
both the interfaces in an interface group to utilize all IPs at all times. 
However, the way it's currently set up, there are more IPs available in the 
core interface than in the res hall interface.

We are considering these options on how to move forward with or without the 
interface group:


  1.  Consolidating down to one interface. More efficient use of IP space, 
clients wouldn't change IPs as often. Could probably increase lease time to 1 
hour, but what about broadcast and ARP traffic for all 30k addresses in the 
VLAN at the router - understanding that client device broadcast traffic doesn't 
leave the controller except DHCP (we do not use DHCP proxy in the controllers).
  2.  Staying with the group of two interfaces and balancing the IP space 
between them. Avoids wasted IPs, depending how intelligent the 8540s are at 
distributing clients between all interfaces in the group.
  3.  Splitting out to more interfaces. We'd cut down on broadcast traffic but 
we'd be liable to have one client taking up three or more addresses between all 
the interfaces for up to the 30-minute lease time we have, and a client would 
change IPs more throughout the day as it re-associates and gets put in a 
different interface.

Interestingly, a consultant we're working with hasn't seen a single customer 
besides us use interface groups.

Eric Glinsky
Network Technician
University of Connecticut
ITS - Network Operations
Temporary Administration Building
25 Gampel Service Drive | Storrs, CT 06269-1138
(860) 486-9199
e...@uconn.edu<mailto:e...@uconn.edu>


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://protect-au.mimecast.com/s/wbhECD1jy9tz8ppvcW8JBh?domain=educause.edu>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] WLC interface groups?

[Mark Duling]

>
> If you are going to use interface groups:
> 1. keep them all the same subnet size or the small ones will fill up first
> and cause issues.
> 2. Keep them them in 2^n sizes.  1, 2, 4, 8 it keeps the hashing easy and
> ends up with more evenly distributed usage.


It would never have occurred to me that different sized subnets might be a
good idea, nor to use anything other than 2^n sizes. And vlan select is a
part of the whole thing, as Kitri mentioned.

On Wed, Aug 28, 2019 at 2:42 PM Jake Snyder  wrote:

> I’m a consultant and I HATE interface groups.
>
> It’s more complexity and more things to go wrong. Not a big enough address
> block?  Re-subnet.  If the switch can’t handle the arp entries, it can’t
> handle the arp entries. Rarely does matter how many VLANs you spread them
> out from.  And yes, I do get the amount of effort required to re-subnet.  I
> wouldn't suggest it if I didn’t feel it was worth the effort.
>
> Remember the android bug where they would spam dhcp requests until the
> controller marked all the interfaces dirty?  I still have nightmares.  I
> continue to see interfaces in groups marked dirty at several universities
> and causing issues.
>
> Also, option 3:
> If you have broadcast from 32k clients, you have broadcast from 32k
> clients.  Doing things like interface groups moves them from VLAN to VLAN,
> but does little to reduce the overall number or OTA, which is where it is
> the bigger problem.
>
> It also complicates things like IPv6 where due to a shared group
> encryption key, clients can hear RA from the other subnets.  This leads you
> down the “multicast to unicast conversion” solution to address, piling more
> complexity on to deal with the existing complexity.
>
> However, I have one use case where interface groups make sense: public IP
> space where you don’t have a big enough single block.  I would prefer to
> keep them all in the same block, but this is a case where some orgs really
> can’t and with the shortage of IPv4, odds are you won’t be able to fix this
> without some huge cash outlays.
>
> If you are going to use interface groups:
> 1. keep them all the same subnet size or the small ones will fill up
> first and cause issues.
> 2. Keep them them in 2^n sizes.  1, 2, 4, 8 it keeps the hashing easy and
> ends up with more evenly distributed usage.
>
> Jake Snyder
>
> Sent from my iPhone
>
> On Aug 28, 2019, at 3:11 PM, Mark Duling  wrote:
>
> As James said, we use interface groups to select which set of networks to
> put users into based on their ldap membership within the same SSID. I also
> assumed at the time having small nets was better than larger ones as on
> wired networks, but I know it's different on wireless controllers so maybe
> thinking can be very different on that. But I'm not aware of a real
> argument against using interface groups.
>
> We don't use public ip addresses, so running out of them isn't an issue
> for us. But there is the DHCP option in newer servers
> "one-lease-per-client" that allows a "single lease per client on a per
> member basis". I've never used it so I have no idea how well it works, but
> theoretically I guess that option might solve exhaustion issues when
> clients move between networks. But again, no experience with it but maybe
> others have  and can comment.
>
> Mark
>
>
> On Wed, Aug 28, 2019 at 1:16 PM James Helzerman  wrote:
>
>> Hi.  On our main SSID we use Interface Groups so we can return a
>> interface variable back via RADIUS that can be the same in each of our data
>> nodes that has controllers.  This way VLAN numbers dont need to be same and
>> in the case you mentioned if we ever need to add IP space for a quick short
>> term its easy to add to the group.  We rely on the WLC to control the
>> broadcasts and dont see any issues from it.  We dont do DHCP proxy on the
>> controllers.  For our main SSID we currently have two /18 running at each
>> of our three data nodes (different routers).  The biggest thing we have had
>> to watch out and plan for was the routers resources in terms of ARP cache
>> and timeout values.
>>
>> We use Interface Groups on almost all our SSIDs by design.
>>
>> -Jimmy
>>
>> --
>> James Helzerman
>> Wireless Network Engineer
>> University of Michigan - ITS
>> Phone: 734-615-9541
>>
>>
>> On Wed, Aug 28, 2019 at 3:56 PM Glinsky, Eric  wrote:
>>
>>> This question is for large universities with WLCs that tunnel traffic
>>> through a controller. Do you use a single interface (VLAN) for, say, 30k
>>> clients, or do you use two or more interfaces in an interface group, and
>>> why? Do you use DHCP proxy? Is there any documentation or
>>> generally-accepted rules of thumb on this?
>>>
>>>
>>>
>>> Historically, on all three Cisco 8540 pairs, we had a core interface and
>>> an interface for res halls, and depending on the AP’s location (6k APs) our
>>> branded SSID would map clients to one interface or the other.
>>>
>>>
>>>
>>> All our wireless clients have public IPs, and we’ve faced 

RE: WLC interface groups?

[Letts, Richard J]

I really recommend using a big block of private IP addresses and NAT them (I am 
on a 10.x.x.x /17 right now) - this allows you to have really big subnets where 
needed, with reasonable DHCP lease times.  DHCP goes through to our BlueCat 
servers. One can then arrange to have enough public IP addresses tied in your 
NAT service to support the numbers of clients...

If your router can't cope with the ARP traffic (which for a /17 is roughly 5 
packets per second assuming a default 4 hour ARP timeout) then it's going to be 
easy to take down with a single misbehaving client...

Richard Letts

Director, Networking and Telecommunications
ITaP Infrastructure Services
Purdue University
rle...@purdue.edu<mailto:rle...@purdue.edu>
O: 765-496-1663
C: 206-790-5837

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Glinsky, Eric
Sent: Wednesday, August 28, 2019 3:36 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] WLC interface groups?

This question is for large universities with WLCs that tunnel traffic through a 
controller. Do you use a single interface (VLAN) for, say, 30k clients, or do 
you use two or more interfaces in an interface group, and why? Do you use DHCP 
proxy? Is there any documentation or generally-accepted rules of thumb on this?

Historically, on all three Cisco 8540 pairs, we had a core interface and an 
interface for res halls, and depending on the AP's location (6k APs) our 
branded SSID would map clients to one interface or the other.

All our wireless clients have public IPs, and we've faced issues running out. 
Throughout the day, we'd see the majority of clients move from the res hall 
network to the core network, and vice versa at night. At one point, we merged 
both the interfaces in an interface group to utilize all IPs at all times. 
However, the way it's currently set up, there are more IPs available in the 
core interface than in the res hall interface.

We are considering these options on how to move forward with or without the 
interface group:


1.  Consolidating down to one interface. More efficient use of IP space, 
clients wouldn't change IPs as often. Could probably increase lease time to 1 
hour, but what about broadcast and ARP traffic for all 30k addresses in the 
VLAN at the router - understanding that client device broadcast traffic doesn't 
leave the controller except DHCP (we do not use DHCP proxy in the controllers).

2.  Staying with the group of two interfaces and balancing the IP space 
between them. Avoids wasted IPs, depending how intelligent the 8540s are at 
distributing clients between all interfaces in the group.

3.  Splitting out to more interfaces. We'd cut down on broadcast traffic 
but we'd be liable to have one client taking up three or more addresses between 
all the interfaces for up to the 30-minute lease time we have, and a client 
would change IPs more throughout the day as it re-associates and gets put in a 
different interface.

Interestingly, a consultant we're working with hasn't seen a single customer 
besides us use interface groups.

Eric Glinsky
Network Technician
University of Connecticut
ITS - Network Operations
Temporary Administration Building
25 Gampel Service Drive | Storrs, CT 06269-1138
(860) 486-9199
e...@uconn.edu<mailto:e...@uconn.edu>


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] WLC interface groups?

[Kitri Waterman]

Interface groups work great. Check out Vlan Select. You’ll also want to look at 
enabling Multicast Optimization (“Multicast Vlan Feature”).

Most large wifi setups I’ve seen drop broadcasts.

Kitri Waterman
Network Architect/Engineer
Enterprise Infrastructure Services
Western Washington University
360.650.4027
kitri.water...@wwu.edu



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Mark Duling 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Wednesday, August 28, 2019 at 2:12 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] WLC interface groups?

As James said, we use interface groups to select which set of networks to put 
users into based on their ldap membership within the same SSID. I also assumed 
at the time having small nets was better than larger ones as on wired networks, 
but I know it's different on wireless controllers so maybe thinking can be very 
different on that. But I'm not aware of a real argument against using interface 
groups.

We don't use public ip addresses, so running out of them isn't an issue for us. 
But there is the DHCP option in newer servers "one-lease-per-client" that 
allows a "single lease per client on a per member basis". I've never used it so 
I have no idea how well it works, but theoretically I guess that option might 
solve exhaustion issues when clients move between networks. But again, no 
experience with it but maybe others have  and can comment.

Mark


On Wed, Aug 28, 2019 at 1:16 PM James Helzerman 
mailto:jarh...@umich.edu>> wrote:
Hi.  On our main SSID we use Interface Groups so we can return a interface 
variable back via RADIUS that can be the same in each of our data nodes that 
has controllers.  This way VLAN numbers dont need to be same and in the case 
you mentioned if we ever need to add IP space for a quick short term its easy 
to add to the group.  We rely on the WLC to control the broadcasts and dont see 
any issues from it.  We dont do DHCP proxy on the controllers.  For our main 
SSID we currently have two /18 running at each of our three data nodes 
(different routers).  The biggest thing we have had to watch out and plan for 
was the routers resources in terms of ARP cache and timeout values.

We use Interface Groups on almost all our SSIDs by design.

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541


On Wed, Aug 28, 2019 at 3:56 PM Glinsky, Eric 
mailto:e...@uconn.edu>> wrote:
This question is for large universities with WLCs that tunnel traffic through a 
controller. Do you use a single interface (VLAN) for, say, 30k clients, or do 
you use two or more interfaces in an interface group, and why? Do you use DHCP 
proxy? Is there any documentation or generally-accepted rules of thumb on this?

Historically, on all three Cisco 8540 pairs, we had a core interface and an 
interface for res halls, and depending on the AP’s location (6k APs) our 
branded SSID would map clients to one interface or the other.

All our wireless clients have public IPs, and we’ve faced issues running out. 
Throughout the day, we’d see the majority of clients move from the res hall 
network to the core network, and vice versa at night. At one point, we merged 
both the interfaces in an interface group to utilize all IPs at all times. 
However, the way it’s currently set up, there are more IPs available in the 
core interface than in the res hall interface.

We are considering these options on how to move forward with or without the 
interface group:


1.  Consolidating down to one interface. More efficient use of IP space, 
clients wouldn’t change IPs as often. Could probably increase lease time to 1 
hour, but what about broadcast and ARP traffic for all 30k addresses in the 
VLAN at the router - understanding that client device broadcast traffic doesn’t 
leave the controller except DHCP (we do not use DHCP proxy in the controllers).

2.  Staying with the group of two interfaces and balancing the IP space 
between them. Avoids wasted IPs, depending how intelligent the 8540s are at 
distributing clients between all interfaces in the group.

3.  Splitting out to more interfaces. We’d cut down on broadcast traffic 
but we’d be liable to have one client taking up three or more addresses between 
all the interfaces for up to the 30-minute lease time we have, and a client 
would change IPs more throughout the day as it re-associates and gets put in a 
different interface.

Interestingly, a consultant we’re working with hasn’t seen a single customer 
besides us use interface groups.

Eric Glinsky
Network Technician
University of Connecticut
ITS – Network Operations
Temporary Administration Building
25 Gampel Service Drive | Storrs, CT 06269-1138
(860) 486-9199
e...@uconn.edu<mailto:e...@uconn.edu>


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
l

Re: [WIRELESS-LAN] WLC interface groups?

[Jake Snyder]

I’m a consultant and I HATE interface groups.

It’s more complexity and more things to go wrong. Not a big enough address 
block?  Re-subnet.  If the switch can’t handle the arp entries, it can’t handle 
the arp entries. Rarely does matter how many VLANs you spread them out from.  
And yes, I do get the amount of effort required to re-subnet.  I wouldn't 
suggest it if I didn’t feel it was worth the effort.

Remember the android bug where they would spam dhcp requests until the 
controller marked all the interfaces dirty?  I still have nightmares.  I 
continue to see interfaces in groups marked dirty at several universities and 
causing issues.

Also, option 3:
If you have broadcast from 32k clients, you have broadcast from 32k clients.  
Doing things like interface groups moves them from VLAN to VLAN, but does 
little to reduce the overall number or OTA, which is where it is the bigger 
problem.

It also complicates things like IPv6 where due to a shared group encryption 
key, clients can hear RA from the other subnets.  This leads you down the 
“multicast to unicast conversion” solution to address, piling more complexity 
on to deal with the existing complexity.

However, I have one use case where interface groups make sense: public IP space 
where you don’t have a big enough single block.  I would prefer to keep them 
all in the same block, but this is a case where some orgs really can’t and with 
the shortage of IPv4, odds are you won’t be able to fix this without some huge 
cash outlays.

If you are going to use interface groups:
1. keep them all the same subnet size or the small ones will fill up first and 
cause issues.
2. Keep them them in 2^n sizes.  1, 2, 4, 8 it keeps the hashing easy and ends 
up with more evenly distributed usage.

Jake Snyder

Sent from my iPhone

> On Aug 28, 2019, at 3:11 PM, Mark Duling  wrote:
> 
> As James said, we use interface groups to select which set of networks to put 
> users into based on their ldap membership within the same SSID. I also 
> assumed at the time having small nets was better than larger ones as on wired 
> networks, but I know it's different on wireless controllers so maybe thinking 
> can be very different on that. But I'm not aware of a real argument against 
> using interface groups.
> 
> We don't use public ip addresses, so running out of them isn't an issue for 
> us. But there is the DHCP option in newer servers "one-lease-per-client" that 
> allows a "single lease per client on a per member basis". I've never used it 
> so I have no idea how well it works, but theoretically I guess that option 
> might solve exhaustion issues when clients move between networks. But again, 
> no experience with it but maybe others have  and can comment. 
> 
> Mark
> 
> 
>> On Wed, Aug 28, 2019 at 1:16 PM James Helzerman  wrote:
>> Hi.  On our main SSID we use Interface Groups so we can return a interface 
>> variable back via RADIUS that can be the same in each of our data nodes that 
>> has controllers.  This way VLAN numbers dont need to be same and in the case 
>> you mentioned if we ever need to add IP space for a quick short term its 
>> easy to add to the group.  We rely on the WLC to control the broadcasts and 
>> dont see any issues from it.  We dont do DHCP proxy on the controllers.  For 
>> our main SSID we currently have two /18 running at each of our three data 
>> nodes (different routers).  The biggest thing we have had to watch out and 
>> plan for was the routers resources in terms of ARP cache and timeout values.
>> 
>> We use Interface Groups on almost all our SSIDs by design.
>> 
>> -Jimmy
>> 
>> -- 
>> James Helzerman
>> Wireless Network Engineer
>> University of Michigan - ITS
>> Phone: 734-615-9541
>> 
>> 
>>> On Wed, Aug 28, 2019 at 3:56 PM Glinsky, Eric  wrote:
>>> This question is for large universities with WLCs that tunnel traffic 
>>> through a controller. Do you use a single interface (VLAN) for, say, 30k 
>>> clients, or do you use two or more interfaces in an interface group, and 
>>> why? Do you use DHCP proxy? Is there any documentation or 
>>> generally-accepted rules of thumb on this?
>>> 
>>>  
>>> 
>>> Historically, on all three Cisco 8540 pairs, we had a core interface and an 
>>> interface for res halls, and depending on the AP’s location (6k APs) our 
>>> branded SSID would map clients to one interface or the other.
>>> 
>>>  
>>> 
>>> All our wireless clients have public IPs, and we’ve faced issues running 
>>> out. Throughout the day, we’d see the majority of clients move from the res 
>>> hall network to the core network, and vice versa at night. At one point, we 
>>> merged both the interfaces in an interface group to utilize all IPs at all 
>>> times. However, the way it’s currently set up, there are more IPs available 
>>> in the core interface than in the res hall interface.
>>> 
>>>  
>>> 
>>> We are considering these options on how to move forward with or without the 
>>> interface group:
>>> 
>>>  
>>> 
>>> 

Re: [WIRELESS-LAN] WLC interface groups?

[Mark Duling]

As James said, we use interface groups to select which set of networks to
put users into based on their ldap membership within the same SSID. I also
assumed at the time having small nets was better than larger ones as on
wired networks, but I know it's different on wireless controllers so maybe
thinking can be very different on that. But I'm not aware of a real
argument against using interface groups.

We don't use public ip addresses, so running out of them isn't an issue for
us. But there is the DHCP option in newer servers "one-lease-per-client"
that allows a "single lease per client on a per member basis". I've never
used it so I have no idea how well it works, but theoretically I guess that
option might solve exhaustion issues when clients move between networks.
But again, no experience with it but maybe others have  and can comment.

Mark


On Wed, Aug 28, 2019 at 1:16 PM James Helzerman  wrote:

> Hi.  On our main SSID we use Interface Groups so we can return a interface
> variable back via RADIUS that can be the same in each of our data nodes
> that has controllers.  This way VLAN numbers dont need to be same and in
> the case you mentioned if we ever need to add IP space for a quick short
> term its easy to add to the group.  We rely on the WLC to control the
> broadcasts and dont see any issues from it.  We dont do DHCP proxy on the
> controllers.  For our main SSID we currently have two /18 running at each
> of our three data nodes (different routers).  The biggest thing we have had
> to watch out and plan for was the routers resources in terms of ARP cache
> and timeout values.
>
> We use Interface Groups on almost all our SSIDs by design.
>
> -Jimmy
>
> --
> James Helzerman
> Wireless Network Engineer
> University of Michigan - ITS
> Phone: 734-615-9541
>
>
> On Wed, Aug 28, 2019 at 3:56 PM Glinsky, Eric  wrote:
>
>> This question is for large universities with WLCs that tunnel traffic
>> through a controller. Do you use a single interface (VLAN) for, say, 30k
>> clients, or do you use two or more interfaces in an interface group, and
>> why? Do you use DHCP proxy? Is there any documentation or
>> generally-accepted rules of thumb on this?
>>
>>
>>
>> Historically, on all three Cisco 8540 pairs, we had a core interface and
>> an interface for res halls, and depending on the AP’s location (6k APs) our
>> branded SSID would map clients to one interface or the other.
>>
>>
>>
>> All our wireless clients have public IPs, and we’ve faced issues running
>> out. Throughout the day, we’d see the majority of clients move from the res
>> hall network to the core network, and vice versa at night. At one point, we
>> merged both the interfaces in an interface group to utilize all IPs at all
>> times. However, the way it’s currently set up, there are more IPs available
>> in the core interface than in the res hall interface.
>>
>>
>>
>> We are considering these options on how to move forward with or without
>> the interface group:
>>
>>
>>
>> 1.  Consolidating down to one interface. More efficient use of IP
>> space, clients wouldn’t change IPs as often. Could probably increase lease
>> time to 1 hour, but what about broadcast and ARP traffic for all 30k
>> addresses in the VLAN at the router - understanding that client device
>> broadcast traffic doesn’t leave the controller except DHCP (we do not use
>> DHCP proxy in the controllers).
>>
>> 2.  Staying with the group of two interfaces and balancing the IP
>> space between them. Avoids wasted IPs, depending how intelligent the 8540s
>> are at distributing clients between all interfaces in the group.
>>
>> 3.  Splitting out to more interfaces. We’d cut down on broadcast
>> traffic but we’d be liable to have one client taking up three or more
>> addresses between all the interfaces for up to the 30-minute lease time we
>> have, and a client would change IPs more throughout the day as it
>> re-associates and gets put in a different interface.
>>
>>
>>
>> Interestingly, a consultant we’re working with hasn’t seen a single
>> customer besides us use interface groups.
>>
>>
>>
>> Eric Glinsky
>> Network Technician
>>
>> University of Connecticut
>> ITS – Network Operations
>>
>> Temporary Administration Building
>> 25 Gampel Service Drive | Storrs, CT 06269-1138
>> (860) 486-9199
>>
>> e...@uconn.edu
>>
>>
>>
>> **
>> Replies to EDUCAUSE Community Group emails are sent to the entire
>> community list. If you want to reply only to the person who sent the
>> message, copy and paste their email address and forward the email reply.
>> Additional participation and subscription information can be found at
>> https://www.educause.edu/community
>>
>
>
> --
> James Helzerman
> Wireless Network Engineer
> University of Michigan - ITS
> Phone: 734-615-9541
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email 

Re: [WIRELESS-LAN] WLC interface groups?

[James Helzerman]

Hi.  On our main SSID we use Interface Groups so we can return a interface
variable back via RADIUS that can be the same in each of our data nodes
that has controllers.  This way VLAN numbers dont need to be same and in
the case you mentioned if we ever need to add IP space for a quick short
term its easy to add to the group.  We rely on the WLC to control the
broadcasts and dont see any issues from it.  We dont do DHCP proxy on the
controllers.  For our main SSID we currently have two /18 running at each
of our three data nodes (different routers).  The biggest thing we have had
to watch out and plan for was the routers resources in terms of ARP cache
and timeout values.

We use Interface Groups on almost all our SSIDs by design.

-Jimmy

-- 
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541


On Wed, Aug 28, 2019 at 3:56 PM Glinsky, Eric  wrote:

> This question is for large universities with WLCs that tunnel traffic
> through a controller. Do you use a single interface (VLAN) for, say, 30k
> clients, or do you use two or more interfaces in an interface group, and
> why? Do you use DHCP proxy? Is there any documentation or
> generally-accepted rules of thumb on this?
>
>
>
> Historically, on all three Cisco 8540 pairs, we had a core interface and
> an interface for res halls, and depending on the AP’s location (6k APs) our
> branded SSID would map clients to one interface or the other.
>
>
>
> All our wireless clients have public IPs, and we’ve faced issues running
> out. Throughout the day, we’d see the majority of clients move from the res
> hall network to the core network, and vice versa at night. At one point, we
> merged both the interfaces in an interface group to utilize all IPs at all
> times. However, the way it’s currently set up, there are more IPs available
> in the core interface than in the res hall interface.
>
>
>
> We are considering these options on how to move forward with or without
> the interface group:
>
>
>
> 1.  Consolidating down to one interface. More efficient use of IP
> space, clients wouldn’t change IPs as often. Could probably increase lease
> time to 1 hour, but what about broadcast and ARP traffic for all 30k
> addresses in the VLAN at the router - understanding that client device
> broadcast traffic doesn’t leave the controller except DHCP (we do not use
> DHCP proxy in the controllers).
>
> 2.  Staying with the group of two interfaces and balancing the IP
> space between them. Avoids wasted IPs, depending how intelligent the 8540s
> are at distributing clients between all interfaces in the group.
>
> 3.  Splitting out to more interfaces. We’d cut down on broadcast
> traffic but we’d be liable to have one client taking up three or more
> addresses between all the interfaces for up to the 30-minute lease time we
> have, and a client would change IPs more throughout the day as it
> re-associates and gets put in a different interface.
>
>
>
> Interestingly, a consultant we’re working with hasn’t seen a single
> customer besides us use interface groups.
>
>
>
> Eric Glinsky
> Network Technician
>
> University of Connecticut
> ITS – Network Operations
>
> Temporary Administration Building
> 25 Gampel Service Drive | Storrs, CT 06269-1138
> (860) 486-9199
>
> e...@uconn.edu
>
>
>
> **
> Replies to EDUCAUSE Community Group emails are sent to the entire
> community list. If you want to reply only to the person who sent the
> message, copy and paste their email address and forward the email reply.
> Additional participation and subscription information can be found at
> https://www.educause.edu/community
>


-- 
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

WLC interface groups?

[Glinsky, Eric]

This question is for large universities with WLCs that tunnel traffic through a 
controller. Do you use a single interface (VLAN) for, say, 30k clients, or do 
you use two or more interfaces in an interface group, and why? Do you use DHCP 
proxy? Is there any documentation or generally-accepted rules of thumb on this?

Historically, on all three Cisco 8540 pairs, we had a core interface and an 
interface for res halls, and depending on the AP's location (6k APs) our 
branded SSID would map clients to one interface or the other.

All our wireless clients have public IPs, and we've faced issues running out. 
Throughout the day, we'd see the majority of clients move from the res hall 
network to the core network, and vice versa at night. At one point, we merged 
both the interfaces in an interface group to utilize all IPs at all times. 
However, the way it's currently set up, there are more IPs available in the 
core interface than in the res hall interface.

We are considering these options on how to move forward with or without the 
interface group:


1.  Consolidating down to one interface. More efficient use of IP space, 
clients wouldn't change IPs as often. Could probably increase lease time to 1 
hour, but what about broadcast and ARP traffic for all 30k addresses in the 
VLAN at the router - understanding that client device broadcast traffic doesn't 
leave the controller except DHCP (we do not use DHCP proxy in the controllers).

2.  Staying with the group of two interfaces and balancing the IP space 
between them. Avoids wasted IPs, depending how intelligent the 8540s are at 
distributing clients between all interfaces in the group.

3.  Splitting out to more interfaces. We'd cut down on broadcast traffic 
but we'd be liable to have one client taking up three or more addresses between 
all the interfaces for up to the 30-minute lease time we have, and a client 
would change IPs more throughout the day as it re-associates and gets put in a 
different interface.

Interestingly, a consultant we're working with hasn't seen a single customer 
besides us use interface groups.

Eric Glinsky
Network Technician
University of Connecticut
ITS - Network Operations
Temporary Administration Building
25 Gampel Service Drive | Storrs, CT 06269-1138
(860) 486-9199
e...@uconn.edu


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community