Wireless Access

I've read a few posts in airheads on the vlan pool vs. large subnet topic but they seemed more focused on smaller networks. (10 pools at most and /24's) So I am posting to get opinions.

Currently on my network:

It is a single campus
peak time concurrent clients are around 20,000

In the 6 months I have been running airwave I have seen 75,000 client devices

We currently do vlan pooling, we have 26 /22 subnets in the pool.

We do not allow inter client communication

We convert all bcast/mcast to unicast

there is only one class of wireless user

the number of devices is always creeping upwards

We are doing a large upgrade to 7200 series controllers so we now have an opportunity to revisit the vlan pooling / large subnet question.  Moving to a large subnet would simplify a lot of configurations and make it easier to look at.

Would a /15 subnet be too large and not recommened (we have no intention over ever allowing interclient communications or enabling bcast/mcast)?  (when I think about switched networks it just feels extremely wrong...)

Airplay is something we may consider in the future.

If you have a large campus and evaluated vlan pools versus the large subnet, why did you choose one over the other?

Would Aruba NOT recomened a large flat subnet in this case?

Thanks,

You could do a combination of both :

Have 5 - 7 VLANs per pool with large subnets and split those VLANs pools accross different Virtual APs . Also enable bcmc-optimization on the VLANs to decrease the amount of bcast/mcast on the wired side of things

Aruba recommend VLAN pool sizes for M3's to be 10 but since you are planning on migrating to the 7240's those are more powerful.

---

@mverlis wrote:

I've read a few posts in airheads on the vlan pool vs. large subnet topic but they seemed more focused on smaller networks. (10 pools at most and /24's) So I am posting to get opinions.

 

Currently on my network:

It is a single campus
peak time concurrent clients are around 20,000

In the 6 months I have been running airwave I have seen 75,000 client devices

We currently do vlan pooling, we have 26 /22 subnets in the pool.

We do not allow inter client communication

We convert all bcast/mcast to unicast

there is only one class of wireless user

the number of devices is always creeping upwards

 

We are doing a large upgrade to 7200 series controllers so we now have an opportunity to revisit the vlan pooling / large subnet question.  Moving to a large subnet would simplify a lot of configurations and make it easier to look at.

 

Would a /15 subnet be too large and not recommened (we have no intention over ever allowing interclient communications or enabling bcast/mcast)?  (when I think about switched networks it just feels extremely wrong...)

Airplay is something we may consider in the future.

 

If you have a large campus and evaluated vlan pools versus the large subnet, why did you choose one over the other?

 

Would Aruba NOT recomened a large flat subnet in this case?

Thanks,

---

mverilis,

I am going to paraphrase someone who I have been speaking to about this topic lately who has been doing testing with large subnets.  Here is what he suggests:

- Turn on bcmc optimization on that VLAN on every controller hosting that VLAN.

- Make sure broadcast filter all and broadcast filter ARP are enabled on that Virtual AP

- Make sure that wireless VLAN does not have wired users in it

- On the wireless side, the incoming broadcast and multicast from a client is first unicast to the AP/controller which then can determine what to do with the packet, so there is inherent flow control over there

-Tthe ability for a client to generate uncontrolled bc/mc is limited by the wireless bandwidth that this particular device can get. 

There are also benefits from moving to a single VLAN such as:

- Not fragmenting IP address space, not running out of space in a VLAN that the pooling hash assigns a user to while there are free spots available in other VLANs - i.e., make more efficient use of address space without a whole lot of planning.

- No L3 mobility issues

- IPv6 deployment becomes much simpler with a single VLAN - only one RA to be advertised to the entire user population across all APs and these can be simply multicast

Your main consideration is your switching fabric needs to be able to handle all those mac addresses in its table.

This is certainly  cutting edge deployment, so if you want us to have someone talk to you about this, please let me know. (please don't corner your Aruba SE).

We have the bcmc optimization enabled in the SSID profiles
On the VAPS we have Drop Broadcast and Multicast, Convert Broadcast ARP requests to unicast enabled
We don't have any wired users on these vlans

The switch our controllers will hook up to can handle the macs

I would like to talk to someone about this.

Thanks

Please do BCMC Optimization on the VLANs, as well.

BCMC optimization on the SSID profile allows us to send multicast and broadcast traffic at higher than the basic rates.  BCMC optimization at the VLAN level drops all of the wired and wireless broadcasts (supersedes Drop Broadcasts and Multicast at the VAP level).

I sent you a PM.

We will be chaning to the very large flat subnets.

I have BCMC optimization on the vlan now.  I have a follow up regarding it however.

If I do not enable BCMC-optimization on the vlan, would the bcasts/mcasts be allowed through to the APs and then be dropped if I have "Drop Broadcast and Multicast" on the VAP enabled?  

So the bcast/mcast would be on the wired link but not get to the wireless?
We only care about keeping it off the wireless in all locations except for one exception we have.  If it is on the wire, it is OK.


The exception where we have is a specific set of residences with no wired drops.  We will be isntalling access points and need to provide a multicast IPTV stream to them.  With bcmc-optimization on the vlan it will not work.
I would rather prefer not having a seperate set of vlans for this specific group.  But I want to know what you would recommend.

Thanks

I will also add that the subnets contain ONLY wireless users and interclient communication is disabled.

Bcmc optimization at the VLAN level will drop broadcasts on the vlan on the wired and wireless sides.

You might want a separate SSID for IPTV and enable IGMP proxy/snooping so that the multicast will only go to access points with users on it that are subscribed to the stream.

We are in a similar situation and would like to get the community’s feedback on an alternative solution to using vlan pools or having large subnets.

We currently have a single vlan pool for each pair of M3 controllers (one pool name, but different set of vlans mapped to it at the local).   This was done for redundancy.   We currently have 12 – 15  /23 subnets mapped to each pool.

In a couple of weeks we will be migrating to RFC 1918 private addresses and at that time we will do away with vlan pooling and use a single appropriately sized subnet per building.  The subnet size will range from a /24 for very small buildings to a /21 for larger buildings.  The /21 for the larger buildings does not represent the actual concurrent connections, but is oversized to allow for a 4 hour lease time.  This will be a huge improvement over the current 15 minute lease time.

Classroom buildings may require some initial adjusting because of the high turn over of clients, but we fell that this route along with the multicast/broadcast enhancement knobs will make for a more efficient network.  The biggest drawback to this route is that the vlan is applied on the virtual AP profile (so instead of using a single profile with the generic pool name for all buildings) and now we will have to create a new profile for all 200+ buildings on campus.

We look forward to your comments and suggestions.

Thanks

James Nesbitt

Not to oversimplify things, but you would not need a virtual AP or individual VLAN for each building.  You can group buildings and put that ENTIRE population into the same VLAN/VAP.  You can have an ap-group for each building, if you want, but have them share the same Virtual AP on a larger VLAN.  Consolidation and simplification is the goal of this approach.

Each building does have it's own AP Group and the virtual AP for our standard campus ssid is currently configured to use the same named vlan (this is the pool).  When we move to a single vlan per building a vlan specific virtual AP will have to be configured per building.  Am I wrong in this logic?

Thanks

If you intend to recycle your Virtual APs exactly how you have them now, yes.

If you create Virtual APs specifically for the new larger VLANs and replace the old with the new, no.

We would be creating new virtual APs for each building.

Are you suggesting that the larger single vlan for the entire campus is the best option, provided that all of the broadcast and multicast optimizations are correctly configured?

Thanks

Why would you create a separate Virtual AP per building?

The larger single VLAN is a good option, provided that you have fiber everywhere and a router that will accept all of the mac addresses that you would be bridging to it.

  "Why would you create a separate Virtual AP per building?"

Maybe I'm a little behind the time and still have a fresh memory of the large flat network with loops and all sorts of issues.  Aside from my bias against large subnets, a building based vlan provides us the options of providing customized services to departments or groups. 

Nezz,

What you are planning to do is just fine.  The person who started this thread wanted to create very large VLANs that spanned multiple buildings, and we are providing support for people who would seek to do that in this thread.

If a VLAN is only wireless, there should not be a potential for a loop.  Wired and wireless clients would not share the same VLAN.  Wireless "Broadcasts" from clients are first sent unicast to the controller, where they should be dropped.  Using a larger VLAN would enable many organizations to eliminate the "slack" created when VLANs are created per building and allows the organization to leverage a single pool of addresses, sized to the consumption of the larger group.  While bulding-based VLANs would provide customized applications for wired applications, there are quite a few users who would connect to access points in that building who do not belong there and never access resources there.  In the all wireless world the ip address will end up being just a means to deliver traffic to a client that requested it.  With that being said, of course wired clients and assets will have fixed addresses assigned to them where they are located, but there is little need for wireless clients to have that restriction.

Cjoseph,

Actually, this thread is relative to my alternative architecture/issue.  After reading several other threads related to broadcast, multicast, and vlan pooling, I finally get the picture.  And as another contributor suggested in a different thread:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

NightShade1 wrote:

“Thanks for the explanation.

It would be nice if that explanation where in some part of the VRDs.. they just mention that we should use vlan pools for this, and well thats what i have been doing, i did also turn  drop broadcast and multicast when broadcast and multicast are not needed in the enviroment.ghtShade1 wrote:”

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I agree that the simplicity and functionality of a single large vlan appears to be a better solution.  The idea of a dedicated vlan per building came about because the vlan pooling is not working for us.  I’m sure that there are others who may share the same bias towards large subnets as I did.

Please have someone contact me as well so that “I don’t have to corner my Aruba SE”.

Nezz,

Quite frankly, the "single large subnet" approach is very new.  It also goes completely against what people think of large subnets, so it will not show up in a VRD anytime soon until we can validate it with more deployments.  We do have it running in quite a few environments, currently, but we are trying to make sure that users that do it, have proper information on what to avoid and how to configure it.  All of that information is in this thread here.  It is not complicated conceptually.

Again, your deployment seeks to put a VLAN per building.  We are looking for people who are looking to do a VLAN for an entire campus.  Again, this is a cutting edge approach and we definitely want to counsel users who would like to take the single large VLAN for an entire campus approach.

Cjoseph,

Now that I'm are aware that a single large vlan is a feasible option I would like to pursue it.  So please have someone contact me or would you like for me to open a TAC case?

Thanks

Nezz,

I will PM you.

---

@cjoseph wrote:

Nezz,

 

Quite frankly, the "single large subnet" approach is very new.  It also goes completely against what people think of large subnets, so it will not show up in a VRD anytime soon until we can validate it with more deployments.  We do have it running in quite a few environments, currently, but we are trying to make sure that users that do it, have proper information on what to avoid and how to configure it.  All of that information is in this thread here.  It is not complicated conceptually.

 

Again, your deployment seeks to put a VLAN per building.  We are looking for people who are looking to do a VLAN for an entire campus.  Again, this is a cutting edge approach and we definitely want to counsel users who would like to take the single large VLAN for an entire campus approach.

 

---

We are doing seperate vlans for students and faculty, but are keeping each of those as a single subnet.  I would like to just have a single one, but it makes it so much easier to handle our content filtering and bandwidth shaping (sonicwall firewall) based on vlan membership (we can simply check the source and then apply our policies...). That being said I want to see what happens with these sites that use the single subnet/vlan approach.  Can we get a sticky on this subject and or keep this thread or something similar active?

danstl,

We will probably not have anything to report publicly.  The only reason it was even mentioned because it is possible.  This is not a formal initiative.

Colin, 

I'm interested as well in having this conversation as we prepare to build out our new campus. Please PM me

We are now running with these large subnets.
On my VAPS
i have DROP broadcast and multicast enabled
i have Convert Broadcast ARP requests to unicast enabled

The SSID profile has
BC/MC Rate Optimization enabled

The VLAN IP profile has
Enable IGMP and Snooping both enabled

---> I do not have bc/mc optimization on the vlan ip profile enabled because I do have one SSID needing multicast to work.

OTHER INFO:
ARuba 7240's in master, standby master, and locals configuration

version 6.2.1.2

I have and use ipv6 as well as ipv4

What I see happening is:
on the vaps where I do not want multicast, I am unabled to access the test stream i have.
on the vaps where I do want multicst, I am able to access the test stream i have.

Currently I have no AP's configured with multicast enabled VAP.

I see some problems (I think) occuring.

I see 15- 30 % multicast traffic from the AP's to the clients (According to the dashboards)

in my controller logs I see these errors a lot.

Jul 23 17:52:48 pim[3291]: <204203> <ERRS> |pim| Could not add IP multicast group member 10.20.97.2 to group 224.0.0.251
Jul 23 17:52:48 pim[3291]: <204299> <ERRS> |pim| Could not add member 20:c9:d0:63:4c:52 to IP multicast group (10.20.97.2, 224.0.0.251), limit of 300 per group reached

Any suggestions/ideas?

MattV,

I will speak in general, without knowing the details of your deployment.  This thread is specifically about accomodating large client populations and  did not have multicast in mind.

- For a multicast application, you would need a dedicated SSID (VAP)  that does not have "Drop Broadcast and Multicast" enabled

For more tips on Multicast Optimization, please see  the knowledgebase article here:  https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-1645

Please also see the page on multicast in the document here:  http://www.arubanetworks.com/wp-content/uploads/NextGenAppNote_2012-06_28.pdf?repo=tech

BCMC rate optimization on the SSID profile will send multicast, at the highest control rate (24m) instead of the management trafic rate.  That can be enabled safely on any SSID.

We are currently looking to transfer from a multiple vlan/subnet environment to a single subnet/vlan setup.

Our wireless population is 1000+, could u pm me some info regarding this topic?

---

@Jef wrote:

We are currently looking to transfer from a multiple vlan/subnet environment to a single subnet/vlan setup.

Our wireless population is 1000+, could u pm me some info regarding this topic?

---

Jef,

Please ask all questions here.  There is no secret to large subnets, besides robust broadcast controls.

Our current setup:

- Aruba 4324 controller (x2)

- 1000+ users

- Multiple /23 vlan pools

- 802.1x + NPS authentication

- One SSID

New setup:

- Aruba 7200 controller (x2)

- One /20 or /21 vlan pool

More info:

- No wired clients connected to the wireless network.

During busy parts of the day some scopes get full and users can't obtain an IP address. Therefore In our new setup we want to simplify our dhcp setup and chose for fewer, but larger subnets. Can we choose for /21 or even /20 subnets or will this have a negative peformance impact? 

/21 and /22 is the new trend. I've heard of some as large as /18. As long as you have Drop BC/MC enabled, you should be fine.

---

@cjoseph wrote:

Please do BCMC Optimization on the VLANs, as well.

  

---

Where is that setting? 

Because Network -> VLAN would be too obvious I guess. :)

Thanks.

Hi cjoseph,

Now that this thread is 8 months old, have there been any issues that you have seen with this approach?

I generally would love to be able to eliminate the complex VAP/AP groups that were caused by the need for different vlans.

We currently have 2 3600s in our DC with 100 remote locations (2 AP105s per site) supporting 10-40 users on average at any time at any site. At design stages based on the old ways of thinking we were advised to have 10 sites per a vlan, which if we expanded to all 1600+ sites would just be unbareable.

It sounds like that since we are a wireless only deployment we may be able to cut this down to one vlan/vap and regain controll of the massive number of AP groups that we had to create. Do you see any problems with this with a remote AP network?

Thanks

Alex

We switched over from smaller vlan's (pooling) to three large /16 subnets.

No problems so far and everything runs smooth.

A less complex situation and no problems with full scopes and inappropriate scope distribution.

Hi everybody, good thread here.

We are changing a VAP with /22 vlan scope to a /20 scope.

First of all:

- This VAP is in tunnel mode. I think :-), because the users are in a different vlan of APs.

- The default gateway of this vlan is a Check Point firewall, not the controller.

- 802.1x auth over a NPS server.

- 3400/3200 model controllers with ArubaOS 6.1.3.7

- We don't have multicast services

What I need to do a good configuration?

1. Convert Broadcast ARP requests to unicast at VAP already enabled.

2. broadcast-filter all at VAP?

3. BC/MC Rate Optimization at SSID profile?

4. firewall broadcast-filter arp enabled at all controllers?

5. BC/MC optimization at interface vlan? But this vlan don't have IP configured.

What more?

Thank you.

Hi Zemarcio,

We got more or less the same setup with router address being a Checkpoint Firewall and 802.1x authentication through a Windows NPS server.

We checked the Drop and Convert options at the Virtual AP level and configured tunnel mode.

Our Windows NPS returns vendor specific attributes, so they get recognized by the Aruba Controller as the User Vlan and User Role. Different users on the same SSID are assigned to various Roles.

Pay attention when u use PEF (Policy Enforcement Firewall), so these rules don't contradict your Checkpoint firewall rule set.

Thank you.

We are currently dropping broadcasts at VAP level, so no problem there.

Should we enable "Convert Broadcast ARP requests to unicast" or not?

As you are deployed today, you should not have any problems. You would enable drop broadcast and Multicast on the Virtual AP. Bcmc optimization would also need to be deployed on the VLAN interface if you also have any wired traffic.

Thank you Tim.