Wireless Access

I have N+1 sparing for resiliency using LMS and backup LMS IP. That is I have N local controllers and 1 backup controller. All the controllers are on a switch so that all the user VLANs go to all the controllers. I am also routing from the controller to the uplink router - that is the controller has all the users gateway addresses.

Now, when a controller fails, its traffic goes to the backup LMS. Since the VLANs are already there, all the sessions can continue with a very short interruption - in theory. But here is the problem. The uplink router has a route back to the controller for each user vlan. When the controller fails, traffic goes to the backup controller but the uplink gateway still has a route to the failed controller. How can I fix this while maintaining the L3 forwarding to the uplink router?  Perhaps OSPF with link priority/weight is the answer.  When a controller fails, OSFP will update the routes at the uplink router.

Thanks

---

@MortKaye wrote:

I have N+1 sparing for resiliency using LMS and backup LMS IP. That is I have N local controllers and 1 backup controller. All the controllers are on a switch so that all the user VLANs go to all the controllers. I am also routing from the controller to the uplink router - that is the controller has all the users gateway addresses.

 

Now, when a controller fails, its traffic goes to the backup LMS. Since the VLANs are already there, all the sessions can continue with a very short interruption - in theory. But here is the problem. The uplink router has a route back to the controller for each user vlan. When the controller fails, traffic goes to the backup controller but the uplink gateway still has a route to the failed controller. How can I fix this while maintaining the L3 forwarding to the uplink router?  Perhaps OSPF with link priority/weight is the answer.  When a controller fails, OSFP will update the routes at the uplink router.

 

Thanks

---

Make the Router the Layer3 for all clients.  Make the controller ONLY layer2 for the client VLANs.

That is the best   easiest way to do that.

You can try running OSPF on the controllers and have it update the upstream router, but that can be complicated and is not straightforward.

 I believe my controllers are L2 (ie gateway) for the users and the uplink router is L3 (ie next hop).  The router has static routes back the controllers for each VLAN/subnet.  I need help to understand your answer.

Thank-you.

---

@MortKaye wrote:

 I believe my controllers are L2 (ie gateway) for the users and the uplink router is L3 (ie next hop).  The router has static routes back the controllers for each VLAN/subnet.  I need help to understand your answer.

 

Thank-you.

---

The controllers need to share the same layer 2 VLAN to put clients on the same subnets, otherwise you will have the issue you described.  Let me say this, and I hope it makes sense:

Controller 1 - Client VLAN 3

Controller 2 - Client VLAN 3

Controller 3 - Client VLAN 3

Router A that they are connected to, is the default gateway for client VLAN3 and the ip interface on the router for VLAN3 has a helper address that points to a DHCP server that will give out the same address to a client, no matter what controller he is on, because his traffic is always being bridged to VLAN 3 on router A.

I think I understand.  I was trying to avoid making the router the default gateway for the vlans because, of MAC table size issues.  I have a lot of controllers (and clients) using the same uplink router which causes problems with MAC table size.  That is why I needed the controllers to be the default gateway and then route to the uplink router.  Perhaps I am still missing something.   Thanks.

---

@MortKaye wrote:

I think I understand.  I was trying to avoid making the router the default gateway for the vlans because, of MAC table size issues.  I have a lot of controllers (and clients) using the same uplink router which causes problems with MAC table size.  That is why I needed the controllers to be the default gateway and then route to the uplink router.  Perhaps I am still missing something.   Thanks.

---

The majority of high redundancy deployments are done this way.  I have not personally observed anyone with mac table size issues in their router.  Is this a particular model that has this particular issue?

Without getting too specific, I may have more client associations then there are supported MAC addresses because it is a large deployment. However,  if this is the recommended approach, then perhaps I need to reconsider my scaling.

Thank-you.

To cjoseph,

Further to the solution of extending vlans to the uplink router, can you please tell me what router redundancy method is used?  If I extend 100 VLANs to the router, VRRP on the router gets very complicated. 

Thanks.

---

@MortKaye wrote:

To cjoseph,

Further to the solution of extending vlans to the uplink router, can you please tell me what router redundancy method is used?  If I extend 100 VLANs to the router, VRRP on the router gets very complicated. 

 

Thanks.

---

I have never seen a deployment with 100 VLANs so I assume that you are just joking.  If your controller is only connected to a single router, there is no redundancy, because that is your only path out.  If there are two routers, you would create a VRRP or HSRP (Cisco) between those routers on that client VLAN and the client's default gateway would be that VRRP or HSRP instance.

When controller A fails, the AP fails over to controller B and traffic is bridged to the same VLAN, the default router in the ARP table is the same, the DHCP server is the same (external), etc.

The 100 number is the sum of the VLANs over all the controllers, not per controller.

---

@MortKaye wrote:

The 100 number is the sum of the VLANs over all the controllers, not per controller.

---

In that case, you can consolidate.  No more static routes to controllers.

To cjoseph,

What do you mean by consolidate?

To mike,

Good points on the OSPF. I am also concerned about lots of VRRP instances on the router.

Thanks.

---

@MortKaye wrote:

To cjoseph,

What do you mean by consolidate?

 

To mike,

Good points on the OSPF. I am also concerned about lots of VRRP instances on the router.

 

Thanks.

---

Mortkaye,

Instead of having Vlan A on Controller A, Vlan B on Controller B and Vlan C on controller C, you would just have VLAN A that all three controllers would use to put users on, trunked to the layer 3 switch.

With regards to the router, if you only have one router, why would you need VRRP?

My understanding is that Aruba recommends keeping User VLANs to about 1 class C subnet in size.  Did you mean put 3 subnets in 1 VLAN or consolidate the 3 subnets into 1 subnet if it fits the recommendations or make the subnets larger than the recommendations?

I do have 2 routers for resiliency. I should have pluralized "router".

Thanks.

---

@MortKaye wrote:

My understanding is that Aruba recommends keeping User VLANs to about 1 class C subnet in size.  Did you mean put 3 subnets in 1 VLAN or consolidate the 3 subnets into 1 subnet if it fits the recommendations or make the subnets larger than the recommendations?

I do have 2 routers for resiliency. I should have pluralized "router".

 

Thanks.

---

Instead of me borrowing and reprinting all the ideas from Aruba documents,  let me refer you to the Aruba Campus Networks Validated Reference Design here:  http://www.arubanetworks.com/pdf/technology/VRD_Campus_Networks.pdf

"For campus networks, Aruba recommends that you do not deploy the controllers as the default gateway for user VLANs. The existing Layer 3 switches should remain the default gateways for all user VLANs. The Aruba controllers should be deployed as a Layer 2 switched solution that extends from the distribution layer. The controllers should be the default gateway and DHCP server only for the guest VLAN."

Also, the main reason why anyone in general would want to limit the size of VLANs is so that they do not extend a broadcast domain.  Since Aruba has features to control broadcast traffic, VLAN size does not need to be limited simply due to broadcasts.

In the document there is much more information about redundancy and other things that will affect your deployment.  If you have over 100 VLANs, you should take a look to see what best practices you could possibly employ.  You should also take a look at the "Aruba Mobility Controllers" Validated Reference design here:  http://www.arubanetworks.com/pdf/technology/VRD_Aruba%20Mobility%20Controllers_8.pdf

Just find chapters in the documents that you are interested in, for Aruba Best practices.  No need to read the whole thing..

What kind of router is it?    There are some other things you may be able to do like conditional static routes.

I think OSPF is an ok option, but if a single AP happens to fall to a backup controller for some reason, that controller will start advertising that AP group's VLAN subnet and your downstream router will have two equal cost routes and you will end up blackholing traffic. 

Like Colin said, in a large campus deployment like you have, using the downstream router as the L3 gateway is your better option.

As far as router redundancy protocols, you can use whatever your router supports.  VRRP, HSRP, GLBP, etc.

Keep in mind, you're going to have to change your controller and router (switch) ethernet ports from access ports to .1q trunk ports as well to carry all those VLANs.