Wireless Access

Dear Friends ,

 

I have a scenario where in we have 7 M3s and 4X6000 chassis. The total number of APS are 1550 and AP licences available are 5 X 512 AP Licences,  Planning to have the Master redundancy in inte management layer with 2X M3s,

4X Local controllers and 1 X  Backup local incase of the local failure. 

 

The question is regarding the physical placement of controllers, as we have 5  distributions in the network which are in different buildings. We decided to keep all the controllers in the Core layer of the network where only L3 interfaces are existing. All the Layer-2 vlans , Inter-Vlan routing is done at the  distribution. 

 

In this scenario, How do we handle the wireless user vlan traffic ? Where can we do the inter vlan routing ? is it scalable and best practice that controller doing the inter vlan routing. My issue is that those user vlans will not be existing in the core switches so i cannot have layer-2 trunk towards the core and let the core to handle the layer-3 & intervlan routing.

 

Can you sugesst which is the best redundancy option in this case and how to handle the intervlan routing. Design proposed  is attached.

There are VRDs about this but...

 

If my understanding of what you're saying is right, I take this to mean all your connections from all M3s into the core are essentially on layer 3 P2P routed links or similar? Is that right? If so, your VRRP between the master/backup isn't possible. Unless you're grafting it directly (physically) between the two M3s, and doing that won't achieve much anyway as the rest of the network won't be able to leverage it significantly.

 

If my above understanding is right, you're left with two options...

 

1. Create GRE maps and a schema to link the user VLANs between chassis (complex, but possible).

2. Create an IP mobility domain and HAT table to suit.

 

In either event, your resilience is going to have to leverage backup LMSs which will slow down failover (as opposed to VRRPs).

 

Both would work. I personally don't like option 2, as it tends to load the box cpus more than I'd like in big deployments.

 

To be honest, I'd be inclined to change if I were you and push the M3s out to the dist layer where you can tie contiguous VLANs between M3s and leverage VRRPs for resilience (again, create a balanced schema based on ap-groups). This will be faster (in terms of failover/box processing), and your config much simpler.

 

That's my 5 minute thinking time view! Might have missed something of course!

 

Thanks.

 

Thank you for the reply.

 

I did not catch up with the first option , can you explain bit more detail , or point me to any relavent docs.

 

Thanks..

Just in case you weren't aware or sure of it, GRE (generic routing encapsulation), is essentially a basic way of transporting packets between two devices transparently over any intermediate devices. In fact, it's the way "normal" campus Aruba APs send tunnel traffic to the controller.

 

It's possible to create static versions of these tunnels in your configs for the purpose of "bridging" a layer 2 VLAN between two or more controllers. When doing this, you do need to be careful not to create loops as these can be tricky to work out. I'm not aware of a way of creating a resilient version of this (as STP doesn't traverse them, and timing might be unreliable?), so it might actually not be a good option if this a big design with resilience being key? Anybody know if I'm wrong on this?

 

The most basic form of this might look like...

 

interface tunnel 100

 description "my-tunnel-1"

 tunnel source 1.1.1.1

 tunnel destination 2.2.2.2

 tunnel mode gre 50

 trusted

 tunnel vlan X

 

The tunnel number is logical. Doesn't matter too much what you set, as long as it makes sense and is unique. The source is THIS controller's address routable IP, destination is the other end/controller. GRE ID again is just logical and unique (needs to match end to end though i'm pretty sure). The X is the VLAN you want to bridge.

 

---

@ajinc@abc.com.qa wrote:

Dear Friends ,

 

I have a scenario where in we have 7 M3s and 4X6000 chassis. The total number of APS are 1550 and AP licences available are 5 X 512 AP Licences,  Planning to have the Master redundancy in inte management layer with 2X M3s,

4X Local controllers and 1 X  Backup local incase of the local failure. 

 

The question is regarding the physical placement of controllers, as we have 5  distributions in the network which are in different buildings. We decided to keep all the controllers in the Core layer of the network where only L3 interfaces are existing. All the Layer-2 vlans , Inter-Vlan routing is done at the  distribution. 

 

In this scenario, How do we handle the wireless user vlan traffic ? Where can we do the inter vlan routing ? is it scalable and best practice that controller doing the inter vlan routing. My issue is that those user vlans will not be existing in the core switches so i cannot have layer-2 trunk towards the core and let the core to handle the layer-3 & intervlan routing.

 

Can you sugesst which is the best redundancy option in this case and how to handle the intervlan routing. Design proposed  is attached.

---

Assuming you have fast connections (fiber?) everywhere:

 

Put all of your local controllers in the distribution layer.  (It looks like you have it there already)

 

Make your distribution layer routers are the default gateway for all of your client vlans (connect your controllers layer-2 to client VLANs), that way your controllers will simply be placing clients on an existing highly available wired infrastructure that you already have.  If you are doing some sort of VRRP or HSRP in your wired network, the Aruba controller will simply be placing those users into that already highly redundant situation.  Allow routers to do what they were purchased to do (route).

 

Having an extra controller in the distribution layer to backup others (n+1) will also be straightforward, because all the same layer-2 VLANs will be available to that extra controller when they are layer-2 connected.  When a controller fails, and access points move to the backup-lms (backup controller), the same Vlans will be available to all of your clients and 802.1x as well as PSK-based clients usually recover in between 10 to 30 seconds and continue to use the same ip addresses, because the ARP table will not change..  Captive Portal clients have to relogin.

 

Either way, based on your diagram, you have a good start.  As was mentioned before the thread, please review the redundancy chapter (Chatper 9) in the Validated Reference Design to see all of your options: here http://www.arubanetworks.com/pdf/technology/VRD_Aruba%20Mobility%20Controllers_8.pdf

 

Yes we have 10Gs everywhere, Also we had more clarity today, current wired network has 4 Distributions with P2P L3 connectivity to the core, there is no layer-2 between the distribution ( and they are hesitating to that ).

 

Our limitation is that we have only 4 Chassis , so where do we place the backup-local ?  If i decided to keep backup-local in one of the distribution, in the case of local failure the tunnels will be built from one distribution where local failed through the core back to other distribution. Does it create any performance issues as we will have voice and roaming.

 

Also if we are relaying on backup LMS for redundancy, referencing  Aruba Mobility Controller VRD document that APs will reboot to after the heart beat time and attemts to reestablish connection with primary. Will it not be  complete wireless down till the APs come up ?

 

Considering VRRP is the fastest way of redundancy and as we dont have any L2 connectivity between Local and BL , Can we run VRRP over a GRE tunnel. With reference to the other reply for my post.

 

 

 

 

 

You´ll get more trouble than what you gain by using GRE tunnels. Even if it may seem clear to you how to configure/troubleshoot this kind of network you have to take into account that problems DO happen and they rarely come on the CCIE's watch.

An ap finding a controller using backup lms is pretty fast. The ap transitioning between the lms (where he first goes) and the backup lms is comparable to the recovery with vrrp. The ap does not reboot, so no additional delay there.

Your first concern is what ip addresses your clients need to have during regular operation and during fail over and what you can do to make sure that is physically available to the controllers.

The easiest way to do this is to put all local controllers are physically in the same place. If your physical infrastructure has sufficient redundancy built in, this is a good option. No matter how you deploy, your wireless traffic will depend in your physical routing infrastructure.

Adding GRE tunnels to the mix adds management overhead and makes traffic less deterministic. Solve as much as you can by locating controllers in the same physical space and allowing the underlying routing infrastructure deal with any failures.

Vrrp should only be used with controllers that are physically close to each other so that an intermittent issue across a spread out physical fabric would not cause both controllers to take control of the vrrp. The same goes to GRE. The more deterministic that you make your network as well as matching it to the underlying routing infrastructure make fail over as well as troubleshooting easier.

With all those general things I said, please contact your local Aruba sales team to work closely with you to make sure you get the best solution that is in your best interest.

I was refering to vrd Aruba Mobility Controllers Validated Reference Design on Page - 47 and seen the follwing statement.

 

LMS / BLMS

 

Operates at Layer 3

 

The AP reboots after the heartbeats time and attempts to reestablish a connection to the primary before failing to the backup.

 

This was the reason why i was thinking AP will reboot during a failover in the LMS scenario, What is your thoughts on this ?

---

@ajinc@abc.com.qa wrote:

I was refering to vrd Aruba Mobility Controllers Validated Reference Design on Page - 47 and seen the follwing statement.

 

LMS / BLMS

 

Operates at Layer 3

 

The AP reboots after the heartbeats time and attempts to reestablish a connection to the primary before failing to the backup.

 

This was the reason why i was thinking AP will reboot during a failover in the LMS scenario, What is your thoughts on this ?

---

From what I have observed, the AP rebootstraps, which means it tries to reestablish connection to the controller.  I do not think that it reboots until it exhausts all discovery methods.  Let me check with the author to clarify.