Wireless Access

Our wireless has 4 SSIDs, where every ssid is on a different VLAN. 

User = 172.19.0.0 / 16         // BROADCAST / MULTICAST TRAFFIC OFF

Student = 172.20.0.0 / 16          // BROADCAST / MULTICAST TRAFFIC ON

WIFI = 172.21.0.0 / 16          // BROADCAST / MULTICAST TRAFFIC OFF

Guest = 172.22.0.0 / 16           // BROADCAST / MULTICAST TRAFFIC OFF

We are an entirely Mac school. We have almost 1300 + Macbook Pros, Macbook and iMacs and around 600+ iOS devices, plus another 1,000+ BYODs.

Our concurrent connection tops at 1,500. We had to DROP BROADCAST AND MULTICAST traffic on all of our VAP profile except on one, as when we hit a certain number of connection, the entire wireless network is unuseable. As soon as we enable the option to drop multicast/broadcast, the network will be back to normal. At presetnt, broadcast and multicast traffic are only allowed in one of our SSID (Student). With this setup, our network is normal. However, users would need to switch to Student SSID to be able to user AirPlay or AirPrint.

My question would be:

If we will reduce our broadcast domain to a smaller subnet say /20 (or even smaller) per VLAN would that help at all? Or is the amount of broadcast packet does not rely on subnet configution but on the actual live nodes?

thanks in advance.

Marlon

Okay let me explain you something

Wifi is  half duplex

Also just one client can speak to the AP at once...

Everytime a broadcast happen none of the clients can transmit! which is your problem...

Now are you sharing those wireless networks with Wired networks... let say

Student network you got wired and wireless users in there? because if you have it like it its recommened to have just wireless network in a vlan... and do not mix them....

As for the  size of the network well

it is recommended a /24

You could build a vlan pool with named vlan for example

Student

with 10 vlans of /24 all pointing to a named vlan with the name students....

You should not go up of 10 vlans.

There is something  that the HD reference guide says

Thanks for the quick reply..

Here's my answer to your questions:

- We separate our wired and wireless clients into different VLAN. 

- 3000 devices on wireless  (scattered into our 4 SSIDs, where each SSID is in a separate VLAN)

..... here's a breakdown:

• 1000 devices on Student SSID
• 1300 devices on Staff SSID
• 500 ~ in our WIFI SSID
• 200 ~ in our Guest SSID

- around 200 devices on wired network 

Thanks

3000 devices distribuited in your 4 ssids?

You can think like what would be the top number of clients in one SSID.

For example if you know that  on Wifi SSID the top clients will be something around 1500 devices

I would configure one named vlan with the name Wifi and a vlan pool of  6 vlans of /24 of 250 per each vlan...

You got the idea? if you reduce the broadcast domain it will be better for your network.. and thats why the vlan pool was created to help with this.

Instead of having a big vlan you can have one name vlan and many vlans pointing to that one...

You know what i mean?

Cheers

Carlos

Oh didnt read the breakdown sorry...

• 1000 devices on Student SSID
• 1300 devices on Staff SSID
• 500 ~ in our WIFI SSID
• 200 ~ in our Guest SSID

1 name vlan students with  a vlan pool of  4 vlan /24 each 250 users

1 name vlan staff with a vlan pool of 6 /24 each 250 users

1 name vlan Wifi of a vlan pool of 2 /24 each 250 users

1 named vlan guest of a vlan pool of 1 / 24

I would do it like that...

Also i would try to implement 802.1x and mix 2 SSIDs and use derived roles...  it is recommened having  3 or less SSIDs...
 because of the managment BW overhead.

Cheers

Carlos

Here is a document which explain what i told you of the managment overhead.

Read the VRDs here is the links of the full list of VRD they will help you a LOT!

http://www.arubanetworks.com/technology/reference-design-guides/

Attachment(s)

wp_Virtual-Access-Points.pdf   769 KB 1 version

Wow! Super helpful!  Thank you so much. 

My 2c - broadcasts do bad things to wifi.  Even with vlan pools setup to reduce your broadcast domain I would imagine you would see a lot of broadcast traffic within those pools.

You may want to simply take note (do some packet captures) and see what type of broadcasts these machines are producing... Because of the HD nature of wifi you may hit the ceiling again because of some chatty applications...

So, based on what I am seeing lately, if you use "Drop Broadcasts and Multicast" it almost does not matter the size of your subnet.  Let us take an extreme example:

I am running a /16 subnet with 16,000 hosts extended all across my infrastructure.  A client connected to an access point sends a broadcast packet into the infrastructure.  None of the clients connected to the same access point can send traffic at the same time; the same as a unicast.  If there is another access point on the same channel at a good signal strength, those clients will be affected, as well.  The "broadcast" gets tunneled back to the controller and the controller does not rebroadcast it back out to the infrastructure with the "drop broadcast" option enabled.

The behavior that we just described is pretty much identical to unicast traffic behavior since the traffic pattern of unicast traffic is into the infrastructure.  The only difference is that there is never a reply or an ack to this "broadcast" traffic.

Using this simple example, no matter how many clients are in a broadcast domain, you are more limited by how many clients are on an access point, as opposed to what VLAN they are on..

Any opinions about this?

---

@cjoseph wrote:

So, based on what I am seeing lately, if you use "Drop Broadcasts and Multicast" it almost does not matter the size of your subnet.  Let us take an extreme example:

 

I am running a /16 subnet with 16,000 hosts extended all across my infrastructure.  A client connected to an access point sends a broadcast packet into the infrastructure.  None of the clients connected to the same access point can send traffic at the same time; the same as a unicast.  If there is another access point on the same channel at a good signal strength, those clients will be affected, as well.  The "broadcast" gets tunneled back to the controller and the controller does not rebroadcast it back out to the infrastructure with the "drop broadcast" option enabled.

 

The behavior that we just described is pretty much identical to unicast traffic behavior since the traffic pattern of unicast traffic is into the infrastructure.  The only difference is that there is never a reply or an ack to this "broadcast" traffic.

 

Using this simple example, no matter how many clients are in a broadcast domain, you are more limited by how many clients are on an access point, as opposed to what VLAN they are on..

 

Any opinions about this?

 

---

I like this :)  This is what we do... (we still have our students/faculty/guests, on different vlans though, but this is mainly so I can easily setup vlan traffic shaping on our firewall.) I have a hard time justifying the use of multicast and broadcasts on wifi networks - they are too destructive to air time.  Unless you have an application that absolutely needs them.

Heck we even removed HT support for all our bands, we saw little need, and because we have quite a lot of G clients still HT simply kills your channel usage, as well as overall throughput....  Removing HT from our 5Ghz is fine as well - 90%+ of our traffic is internet traffic now, and well one n client (non HT) can totally saturate our connection.... We have much better wireless throughput (overall) with HT disabled.

Broadcasts aside, you disabling HT is very interesting.  Do you see 802.11n clients dominating the spectrum causing other clients to starve, as a result?

---

@cjoseph wrote:

Broadcasts aside, you disabling HT is very interesting.  Do you see 802.11n clients dominating the spectrum causing other clients to starve, as a result?

 

---

We were seeing some channel congestion, and also had lots of our G clients getting low goodput levels, for kicks we turned off HT and now things are much better.  I am not sure why it was causing goodput issues, but maybe contention?  All I know is that we are much happier with HT off.. Though some of my users are mad because they can only connect at 54Mb and they are like I get 108Mb at home... what gives... :)

---

@danstl wrote:

---

@cjoseph wrote:

Broadcasts aside, you disabling HT is very interesting.  Do you see 802.11n clients dominating the spectrum causing other clients to starve, as a result?

 

---

We were seeing some channel congestion, and also had lots of our G clients getting low goodput levels, for kicks we turned off HT and now things are much better.  I am not sure why it was causing goodput issues, but maybe contention?  All I know is that we are much happier with HT off.. Though some of my users are mad because they can only connect at 54Mb and they are like I get 108Mb at home... what gives... :)

---

It may be an issue specific to your clients.  Quite frankly, it is the non-802.11n clients that slow down the 802.11n clients, usually.  Pound-for-pound 802.11n clients transmit their traffic more quickly and efficiently and give more airtime back to non-802.11n clients.  With that being said, there are pre-standard 802.11n clients that do not do well with ratified 802.11n access points and turning off HT is sometimes the only solution with those.

Collin

Do you consider vlan pool unnecessary when you have drop broadcast and multicast on?

Cheers

Carlos

Nightshade1,

Because in the centralized model, we can see and control whatever traffic comes from every client, vlan pooling is not necessary to deal with broadcast propagation.  Vlan pooling was really designed to quickly add capacity to the wired network without modifying existing subnets.

We normally encourage users to create subnets the same size as their wired network so that things are similar to what they do on the wired side for uniformity and ease of management.   For users that have many, many users managing alot of VLANs becomes a serious challenge.  Those users are able to simplify things by replacing VLAN pools  with a single large subnet because the controller can see and remove all unnecessary traffic before it is put back out onto the network.  In environments that do not rely on broadcast and/or multicast traffic it is entirely possible.

Of course, there are some networks that cannot do this because of bandwidth, design issues or the need to propagate broadcast and multicast traffic.  For those environments that have good bandwidth between the controller, access points and the infrastructure and do not rely on broadcast or multicast traffic a single large vlan with adequate broadcast suppression is certainly worth looking into.

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.

Just one last question on the VRD it says limiting the broadcast domain size is crucial to limiting over-the -air management traffic, what is referring to?

I mean dropping broadcast would help with the air time in general as it wouldlnt be sending uncesary broadcast all around, and wound not stop transmitting becasue of this... but it says specifically air managment time traffic
can you enlight me in this last one please colllin :)

Cheers

Carlos

---

@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.

 

Just one last question on the VRD it says limiting the broadcast domain size is crucial to limiting over-the -air management traffic, what is referring to?

 

I mean dropping broadcast would help with the air time in general as it wouldlnt be sending uncesary broadcast all around, and couldnt wound not stop transmitting becasue of this... but it says specifically air managment time traffic
can you enlight me in this last one please colllin :)

 

Cheers

Carlos

 

 

---

Nightshade1,

I did not post above to re-write what is in the VRD or to suggest that everyone do anything different.  All of that information is still valid.  My post is just to answer the user who opened this thread specifically and let him know that it is possible to use a large VLAN successfully and the benefits/drawbacks of such.

Okay Collin

Thanks for the explanation from before again

Cheers

Carlos