Re: [WIRELESS-LAN] WLC interface groups?
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?
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 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.
