Wireless Access

I like VLAN pools. But I am bitterly disappointed that you can't pass a VLAN pool over radius as vsa. Guest networks I want to disable inter VLAN routing, but might I ever have a requirement where they have some access to talk to each other? If I disable broadcast and multi cast does it matter if I have a massive broadcast domain? Any thoughts? How big are your guest subnets?

---

@soapdish wrote:
I like VLAN pools. But I am bitterly disappointed that you can't pass a VLAN pool over radius as vsa. Guest networks I want to disable inter VLAN routing, but might I ever have a requirement where they have some access to talk to each other? If I disable broadcast and multi cast does it matter if I have a massive broadcast domain? Any thoughts? How big are your guest subnets?

---

I'll throw in my two cents...

 

• I like VLAN pools. But I am bitterly disappointed that you can't pass a VLAN pool over radius as vsa.
• ----- [Mike] This is a much-requested feature. I won't speak for Product Management, but it will hopefully be added soon.
• Guest networks I want to disable inter VLAN routing, but might I ever have a requirement where they have some access to talk to each other?
• ----- [Mike] Who is your gateway for the guests? (Aruba? A core switch? A DMZ firewall?) Let me outline why I ask: you have a DMZ firewall for your guests' gateway. The DHCP given to them defines this DMZ firewall as the gateway. But the Aruba controller has an IP in there, so it can serve Captive Portal pages to guests. If a guest were to give themselves a static gateway, set to the Aruba controller, the controller will accept that packet and route it according to its routing table, which could give that user internal access. If you disable that feature, we won't route through that interface. On the other hand, if the controller is your gateway, you need to modify your guest role to block internal access, which is not a bad idea regardless. (Did that make sense?)
• If I disable broadcast and multi cast does it matter if I have a massive broadcast domain?
• ----- [Mike] This is a mostly religious debate, if you're dropping BC/MC. If so, then bigger subnets are OK, as long as they aren't shared with other non-Aruba networks. For example, I have some customers that are transitioning from another vendor to Aruba, and both networks deposit clients into the same VLANs. We can control much of the BC/MC from our clients, but BC/MC from other sources is much harder to manage. 6.1.3.2 has some proxy-ARP enhancements and such to help with this.
• How big are your guest subnets?
• ----- [Mike] Just slightly bigger than you need them to be. :) OK, but really... this varies WIDELY. I'm not sure of the size of your network... but in general, guest networks can be a bit larger because generally anything non-HTTP/HTTPS is dropped for guests. This limits BC/MC problems tremendously. I don't see VLAN Pooling as often as I see larger guest nets.

 

Good luck! (And of course, check our VRD's, which discuss all of these things in detail. :)

ArubaMike

Thanks for the response mike. Is there a particularly good vrd you can recommend? I have got a bit confused about guest management since the the clear pass product rebranding. And can't seem to find the docs to well. :-(

This is from the high density VRD here: http://www.arubanetworks.com/wp-content/uploads/DG_HighDensity_VRD.pdf

 

 

"VLAN Pooling

Use VLAN pools in the virtual AP profile for large networks that require more than one subnet for HD WLAN clients within a specific floor or building. Doing so restricts the size of the broadcast domain, thereby limiting unnecessary traffic.

 Keep each VLAN subnet within a VLAN pool to a 24-bit subnet mask.  Do not have more than 10 VLANs within a pool so that broadcast or multicast traffic does not

consume too much air time access."

 

Amigopd and ArubaOS integration VRD here:   http://www.arubanetworks.com/wp-content/uploads/Amigopod-AOS-Integration-AppNote.pdf

 

Awsome thanks again guys :smileywink: have a virtual beer on me LOL, I got some reading to do!