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 <[email protected]> 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
> [email protected]
>
> ------------------------------
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> [email protected]> on behalf of Tariq Adnan <
> [email protected]>
> *Sent:* Wednesday, August 28, 2019 6:44 PM
> *To:* [email protected] <
> [email protected]>
> *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 <
> [email protected]> *On Behalf Of *Glinsky, Eric
> *Sent:* Thursday, 29 August 2019 5:36 AM
> *To:* [email protected]
> *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
>
> [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
> <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-au.mimecast.com%2Fs%2FwbhECD1jy9tz8ppvcW8JBh%3Fdomain%3Deducause.edu&data=02%7C01%7Ceg%40UCONN.EDU%7C4408935032f9459f0ebd08d72c095ccd%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C637026291043727391&sdata=MQMNAD2%2Bv8KOBE2YLTLWiULM10McYCYNiMphVkXVo%2F4%3D&reserved=0>
>
> **********
> 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.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity&data=02%7C01%7Ceg%40UCONN.EDU%7C4408935032f9459f0ebd08d72c095ccd%7C17f1a87e2a254eaab9df9d439034b080%7C0%7C0%7C637026291043727391&sdata=dUlCUozaOIDVf29jgDBQaxhMh2cL71tib3jvCkENEwk%3D&reserved=0>
>
> **********
> 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

Reply via email to