On Aug 28, 2019, at 4:42 PM, Jake Snyder <jsnyde...@gmail.com<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 <mark.dul...@biola.edu<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 <jarh...@umich.edu<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 <e...@uconn.edu<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 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 — Bruce Curtis bruce.cur...@ndsu.edu<mailto:bruce.cur...@ndsu.edu> Certified NetAnalyst II 701-231-8527 North Dakota State University ********** 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
