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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >>> [email protected] >>> >>> >>> >>> ********** >>> 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 >> > > ********** > 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
