Wireless Access

Hi,

I want to understand the vlan-pool more:

1- Vlan pool will have more than 1 vlan each with its own subnet.

2- the advantage of pool vlan is to have a large number of user addresses without the need of creating different SSID ?

3- if I will have a single vlan with mask 255.0.0.0 then there would not be need for a pool vlan if this subnet is covering the users?

question: If I used pool vlan then I have to configure those vlans in the core/distributiion switch as well with the same vlan# as in the pool ?

question: If I used pool vlan and the default gate-way is the distribution switch then I have to define two ip addresses in the switch one for each vlan inside the vlan-pool ? and a single gateway address will not work because each will be in adifferent subnet ?

1.  Yes

2.  The purpose is really to allow a large number of users while keeping small subnet/broadcast domains, regardless if SSIDs

3.  True, but having a VLAN that large would likely produce poor performance.  Ideally VLANs should be /24; and pooled where necessary.

- Yes, the VLANs would need to be defined at the core and trunked t the controller

- Yes, you'd need an IP on each VLAN in your core to provide routing capabilities (the controller 'could' do this, but it is not recommended)

We are in a similar situation.  We have a subnet that we outgrew, so we allocated another one and decided to use vlan pooling.  The issue is that subet A is /21 and subnet B is /26.  I want to understand the alogorithm for vlan pooling and what happens if one subnet is all used up?  Any insight out there?

Following is a snippet from the Campus VRD available at 

http://www.arubanetworks.com/vrd/CampusWNetworksVRD/wwhelp/wwhimpl/js/html/wwhelp.htm

To determine which pool to put the user into, the user MAC address is run through a hash algorithm. The
output of this algorithm places the user into one of the VLANs in the pool and ensures that the user is always
placed into the same pool during a roaming event. As the user associates with the next AP, the address is
hashed. The user is again placed into the same VLAN on the new AP, because the hash algorithm generates the
same output as before. The user can continue to use their existing IP address with no break in their user
sessions.
A single VLAN or a VLAN pool can be named by the administrator. The VLAN names are global, but the VLAN IDs
associated with those names are local to the controller. The VLAN names are configured globally in the master
controller and are synchronized to the local controllers. The VLAN IDs that are associated to a particular VLAN
name are defined in the local controllers and can vary across the controllers.
The example network uses 10 VLANs (VLAN 150-159) split into these two pools:
 pool-7 is used by the employee and application VAPs in the AP group that uses the virtual IP (VIP) of
Virtual Router Redundancy Protocol (VRRP) instance 7 as the local management switch (LMS) IP.
 pool-8 is used by the employee and application VAPs in the AP group that uses the VIP of VRRP instance
8 as the LMS IP.

N O T E
The hashing algorithm does not place users into the available pool of VLANs in a
round-robin method. Ten clients that join a WLAN are not load balanced equally
among the VLANs. Instead, the distribution is based on the output of the hash. One
VLAN might have more users than the others. For example, consider 150 clients that
join a WLAN with just two VLANs in the pool and with 80 addresses per VLAN available
for clients. Based on the output of the hashing algorithm, 80 clients are placed in one
VLAN and 70 in the other. When the 151st client joins, the output of the hash might
place the client in the VLAN whose scope of 80 addresses has already exhausted. The
result is that the client cannot obtain an IP. To avoid such a rare situation, the network
administrator should design pools with sufficient number of user VLANs and DHCP
scopes to accommodate the user density.

Thanks HT!

I guess the follow up question would be this:

We currently have this setup as a primary and secondary network on the same vlan - no vlan pooling (where the IP definition is on an upstream connected router).  We use L3 IP mobility (no L2 mobility) on our campus now.  Can we add this secondary network to our hat table?

Ex.

hat 10.10.10.1 255.255.255.0 100 10.100.0.5

hat 10.10.20.1 255.255.255.9 100 10.100.0.5

Basically - 2 subnets from same controller on same vlan for L3 IP mobility??

 The VLAN IDs that are associated to a particular VLAN name are defined in the local controllers and can vary across the controllers,if the vlan ids will be different then how the trunk is going to work ?  especially if two users in the same subnet reside in a different controllers, then how the packets are going to reach one controller from the other if the vlan id is different ?

Thank you for your answer, if I am going to have my core switch as default gateway then do I have to disable the inter-vlan routing (which would be enabled in the controller by default) ? 

Disabling Inter-Vlan routing is a feature that was designed to mainly to stop guest users from changing their default gateway to the controller's ip address on their VLAN and routing through it.  In a regular campus network, inter-vlan routing should be enabled.