Higher Education

I am in the process of reading the documentation for IP mobility and just want to confirm I understand it properly.

 

We have one master and two local controllers all with the same vlans.  Each controller has an IP on each vlan.

 

All of our buildings are on separate vlans and I would like our users to be able to roam between buildings.  Currently some devices don’t ask for a new IP address properly so when the user roams to a new building their devices don’t work.

 

Based on the documentation, I should add the Home agent address which would be the ip address of the master switch.  Do I also add all the ips for each vlan as home agents?  Do I add the ips of the local controllers and all the ips they have for each vlan?

 

 

Thank you for your time.

 

 

Gustie, I'm confused by your setup. Perhaps I misinterpreted . . .

You said your controllers share all the same VLANs. I presume you mean all the client vlans exist at all controllers. You said that buildings have separate vlans; are your controllers centrally located or is there one at each building? If it's the former, then your clients could be placed into the same vlan wherever they go, as traffic is tunneled from the AP back to the controller, at which point vlan placement is made, DHCP requests forwarded, etc.

I will say that we've had a lot of experience with MobileIP and recently disabled it across the board, as the risk vs. reward assessment indicated disabling was a better move. Unless you have an application that needs session persistence as it roams across controllers, you likely do not need MobileIP and would instead only incur added complexity to your configuration, and especially when it comes to troubleshooting. My $0.02, but I've battled a lot with this for whatever it's worth.

Nevertheless, to answer your question, the "Home Agent" portion of the MobileIP configuration should either be the controller-ip of the controller or the VRRP-IP address of a controller pair (active-standby).

- Ryan -

Yes i meant all clients vlans are on all three controllers.  All the controllers are centrally located.

 

We do have all the ap ports on the same vlan and they are tunneled back to the controller.  We have AP groups setup with Virtual AP's per bulding to set the client vlan for a specific ssid to that builidng.  These vlans are seperate subnets so when a client roams to another builidng and tries to use the same ip address (which some clients(iphones) seem to do) it doesn't work of course.

 

 

 

 

 

Gustie - 

 

We have a simular setup here at UPenn, expect that all of our APs are in different VLANs based on building.

 

As Ryan said, your HAT table should have the subnet, VLAN, and the controller that is housing subnet.

 

We have seen some of the issues you stated about clients not re-IPing correctly, and sadly we are at the mercy of the clients. What code train are you running? Aruba has re-written the IP Mobility for 6.3 that dosen't use the IP address, but uses the MAC address and a look up across controllers.

 

Also, are you running IPv6? There is a bug in the IP Mobility that casues all traffic to stop when running dual stack.

 

I wish that I could follow Ryan's lead and turn off IP Mobility in our setup. It would save me a ton of time and hassle.

I could be missing something here, but I just don't understand the business case for this design.

You are separating clients on separate vlans per building, segmenting them into logical building groups. I understand this. Clients in one building are on a different network than another. This could facilitate all sorts of things, such as file sharing, AppleTVs, etc. I get it.

Then, you want mobile IP enabled so that when a client leaves the building, they can retain their address. Now you have a client in building-2 with an IP/vlan from building-1. If this is an acceptable outcome, it conflicts with the first business case. If this is an acceptable outcome, your design will be incredibly simplified by simple aggregating your vlans into a pool back at the controller. Users will persist their vlan as they roam, without mobile IP.

(Caveat is that vlan pooling requires a significant amount of overhead in the pool, i.e., wasted IP address space. This is my challenge today.)

How can you aggregate all your vlans into one vlan and not notice horrible broadcast traffic.  This would be well above the suggested range for a wireless subnet.

I use to run a wireless network at another university that had a single VLAN with almost 9,000 clients, and didn't have any problems as long as you have broadcast/multicast suppression on. It does present some problems if you are using AppleTVs or anything that requires broadcast traffic.

How is there much wasted overhead in vlan pooling? It actually can make more efficient use of the ip addresses while reducing broadcast domains.

 

We hse /23 subnets in our pools using hashing.

Recently, we accidentally ran out of addresses in one pool. All subnets filled up at almost the same time. We quickly reduced lease time and then added additional subnets to the pool during a slack time.

I am very interested in looking into the ip pooling more.

 

We also need to support Apple TV's and projectors in all our classrooms that work the same way so that wouldn't be a good solution to use bcmc-optimization which is what I assume you are referring to.

 

We also use IPv6 which throws in a another wrench.

---

@gustie wrote:

I am very interested in looking into the ip pooling more.

 

We also need to support Apple TV's and projectors in all our classrooms that work the same way so that wouldn't be a good solution to use bcmc-optimization which is what I assume you are referring to.

 

We also use IPv6 which throws in a another wrench.

---

Gustie,

 

I don't mean to interrupt the communal flow of this thread, but you can:

 

- Turn on Drop Broadcast and Multicast at the Virtual AP level

- Have a single large VLAN for your wireless clients

- Support IPv6 on the same VLAN, depending on your configuration.

 

Broadcast suppression makes large VLANs possible and that can simplify your configuration to a single Virtual AP and at minimum a single AP-Group.

 

Bcmc optimization is something that can be applied at the VLAN level that will function like (supersede) the Drop Broadcast and Multicast at the Virtual AP level, and do the same thing on the wired network connected to the controller.  For example if you enable drop broadcast and multicast on vlan 10, any virtual AP you configure with traffic going to VLAN 10 will have broadcast and multicast dropped when bcmc optimization is configured on that VLAN.

 

In our case, we are using multicast IPTV on our pooled VLans

Ok, I have a few due replies. :-)

 

Gustie - I think it's clear now that I was suggesting aggregating into a vlan pool, not a single vlan.

 

Gustie - You mention that supporting AppleTVs and projectors in the classrooms is a requirement. If that's the case, I would definitely NOT use mobile IP. Otherwise, you'll have a client leave building-1 and enter a classroom in building-2; since they'll retain their IP from building-1, they will not be able to communicate with the AppleTV without some bonjour proxying (like airgroup, aerohive, cisco, etc).

 

bosborne - re: wasted overhead with vlan pooling . . . trust me. :-) The problem is that clients are placed into vlans by a hash of their mac address - that's all. There's no built-in intelligence to know whether or not they'll receive an IP on that vlan. Thus, there's a probability that some vlans will fill up while others still have [plenty of] leases. This is the variance associated with vlan pooling. I've attached a screen shot of client dispersion across the different networks in one of our pools. The pool consists of 23 /23s, equating to almost 11,500 IP address leases. Yesterday, during one of the problem times, we had 9,970 clients with an address. That's only 87% utilization, or 1,530 addresses still available. In other words, we had about three /23s worth of addresses not even touched, yet we had clients not getting an address. This is the flaw of Aruba's vlan pool implementation. I'm currently working with them to improve it; we'll see if something comes to fruition.

Aruba has had even vlan pooling available for some time. We have been pleased with the older hash pools, so we are using them.

The "even" algorithm came to be after we requested it, however, they implemented it without a coordination with other controllers. Plus, the vlan assignment per even algorithm is trumped if the client exists in the bridge table; the vlan associated with the client in the bridge table will take precedence. So, if a user is cached in the bridge table for an extended period of time (I've observed >1-2 hours), then when they come back and the controller wants to place them in the least utilized vlan, it won't and will instead reassign the same vlan as before.

Multiple that instance by tens of thousands of clients coming on and off the network throughout the day. . . on the surface, it appears equally inefficient. I have aruba going over some analytics right now to weigh the efficiency between the two options. Also have them brainstorming some enhancements.

Lastly, no one has been able to point me to a customer that is using the "even" algorithm.

Bruce - are you NAT/PAT'ing your wireless clients? Is that why this is not a problem for you?

Yes, we are. We only have a public /21, I believe.

I understand how the vlan pool would be beneficial and would like to implement it.  Perhaps I am not understanding how it works, but it is not clear to me how this would possibly work with Apple TV's, our projectors, anything that needs that broadcast traffic on the same vlan in any reliable way.  We rely on a user being able to see the projectors in their location only.

 

If I go with a vlan pool using one virtual ap assigned to the pool for all buildings, how will users be able to connect to the Apple TV's and projectors in their building?

 

Thank you for your time.

VLan pooling will not work for AirPlay without using Aruba's AirGroup feature in ArubaOS 6.3 with ClearPass Policy Manager 6.x.

 

Otherwise, the Apple TV and the remote controlling device need to be on the same subnet.

 

VLan pooling uses a hash of the client MAC address and the number of VLans in the pool to determine what VLan to place the client in.

We have seen what Ryan is saying about vlan pooling distribution for a long time.  Tried the "even" method, but like Ryan said, if you have multiple controllers this info is not shared between them, so we actually went back to "hash".  A few months back we finally moved to private addressing and /22 subnets with the BC/MC knob turned on.  We are finally not running out of IPs (at least for now)..

As fas as AirGroup on 6.3, you don't need CPPM, but it does add a ton of knobs.  We are testing AirGroup in our lab and it does work as advertised, but without CPPM you can only limit services (airplay, airprint, etc) based on vlans or role, not location, which is what we really wanted. 

Marcelo

gustie, my suggestion for vlan pooling was to simplify your operations. However, like you said, AppleTV stuff will break since you won't have clients in the same broadcast domain. This problem exists, too, in your initial mobile IP approach, however; a client will retain their address from their source buillding, thus they'll be on different networks.

 

This all seems to fall back to the ongoing "damnit, Apple, for not fixing your iOS interface to allow manual/saved AppleTV configurations" complaint. Either take the risk of using AirGroup (fairly new feature) w/ or w/o ClearPass, or slice up your network so that users in classrooms are on the same network with AppleTVs.