Wireless Access

I'm going to build out controllers in a DMZ where RAPs will terminate and guest traffic will be tunneled to.  The VRDs make it clear that the DMZ controllers should be standalone, or separate from the master/local controllers on the inside.  The exact scenario I saw, included putting two controllers in the DMZ in a master/backup master configuration.  That works if both controllers are in the same L2 network, but what if you don't want that?  I want my controllers to be redudant across different DMZs at different sites.  Which roles should they be in since I can't use VRRP?  Also, since I'll be running AOS 6.3, will I be able to use shared licensing with the suggested controller roles?

--- Edit --

The controllers will have reachability between data centers so it would be feasible to do a master/local configuration if that feasible?  The master could LMS1 and local could be LMS2.  Thoughts on that?

The controllers will have reachability between data centers so it would be feasible to do a master/local configuration if that feasible?  The master could LMS1 and local could be LMS2.  Thoughts on that?

I think the master/local scenario should work much better since it will allow you use both controllers active serving APs  compare to your Master/Master standy (can't serve APs) and Master will could serve as the License server for your pool of licenses.

If you are concern about loosing your license server then you can then configure a master/master standby and since you already have layer 2 access between data centers 

If the licensing client can continue to operate when the master licensing server is down, does that just mean it will maintain the current set of licenses it has checked out, but will be unable to check out additional licenses until the master license server is back up?  If so, I think I can deal with that.

If I were to go with an all masters configuration, how does one master get its licensing information from another master designated as the primary license server?  The 6.3UG isn't too clear on the configuration.  It just says all the masters need connectivity to the same Airwave server.

---

@thecompnerd wrote:

If the licensing client can continue to operate when the master licensing server is down, does that just mean it will maintain the current set of licenses it has checked out, but will be unable to check out additional licenses until the master license server is back up?  If so, I think I can deal with that.

 

If I were to go with an all masters configuration, how does one master get its licensing information from another master designated as the primary license server?  The 6.3UG isn't too clear on the configuration.  It just says all the masters need connectivity to the same Airwave server.

---

Thecompnerd,

You need to break this down into multiple problems and prioritize based on importance.

1. You need to have a remote AP controller across DMZs

2. You need to have guest controllers across DMZs

3. You need to leverage centralized licensing

All three issues are complicated by themselves.  You should not combine them.

1.  Having remote APs across two different DMZs is not difficult in itself unless you are relying on seamless failover when one controller fails.  You could point your RAPs DNS with multiple a-records so that it will try one ip address then another.  The gotcha is that wired devices behind the RAP will probably not re-ip if the AP rebootstraps quickly, because they might not see the ethernet go down.  Ensuring that devices that are wired re-ip is an advanced topic that might require something like OSPF between controllers if you intend on maintaining ip addresses.  That could be really involved based on your infrastructure and your comfort with advertising OSPF to your internal network to provide reachability to your RAP clients

2.  Having guest controllers across two different DMZs is really involved due to state issues because guests will not know that the network routing their traffic has shifted to another controller and another DMZ.  This would require a combination of OSPF to shift the default gateway to another controller and the GRE tunnel group feature in 6.3 http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/Network_Parameters/Configuring_GRE_Tunnel_Group.htm to provide redundancy for a GRE tunnel between two different controllers.

3. With regards to licensing, you can have the topologies pictured below.  You can have every controller as a master pointing back to the centralized master, however.  You can also have locals of the centralized master involved in the scheme.  About the only topology not supported with centralized licensing is the locals of multiple masters:

Long story short, you should probably get professional advice to put a complicated solution like this into play, because they will have detailed information about your network that would result in a dealbreaker otherwise.  There is no reason why you have to reuse the same controllers for DMZ and RAP:  that will certainly complicate things more.

Good point that cjoseph made , if you have a very slow link between the two data centers then you need to be careful how you engineer this setup.

To answer your question about the license server , if the master/licenses server goes down and you don't have a standby master/license server then the local/client server will be able to use those licenses for 30 days 

cjoseph,

In our environment, the RAPs and Guest can afford to have downtime.  I'm trying to keep this as simple as possible since the RAP and Guest environment aren't mission critical.  I was a bit ambiguous in my first post, so I can re-iterate what I'm tryin to accomplish:

1) All RAPs will terminate on Controller A in DC1.  If Controller A fails, all RAPs will failover to Controller B in DC2.  In order to keep traffic predictable, there won't be any DNS load balancing.  The only wired connections should be networked printers, which would be unreachable if a failover occured.

2) Guests are the least critical and don't need to failover if Controller A is down.

As far as reusing controllers, I didn't want to have 2x the equipment to support the different environments, especially since our guest environment is not very large.

Thanks for your thoughts, I do appreciate them.

victor,

Thanks for the info on the licensing.

---

@thecompnerd wrote:

In our environment, the RAPs and Guest can afford to have downtime.  I'm trying to keep this as simple as possible since the RAP and Guest environment aren't mission critical.  I was a bit ambiguous in my first post, so I can re-iterate what I'm tryin to accomplish:

 

1) All RAPs will terminate on Controller A in DC1.  If Controller A fails, all RAPs will failover to Controller B in DC2.  In order to keep traffic predictable, there won't be any DNS load balancing.  The only wired connections should be networked printers, which would be unreachable if a failover occured.

 

2) Guests are the least critical and don't need to failover if Controller A is down.

 

As far as reusing controllers, I didn't want to have 2x the equipment to support the different environments, especially since our guest environment is not very large.

 

Thanks for your thoughts, I do appreciate them.

---

There is no problem having a combined DMZ/ Guest Controller.  Spanning it across multiple (two) DMZs is what makes it much more complicated.  You probably want to first start with the combined DMZ/Guest Controller and then attempt to span it.  Your centralized licensing would be supported in that mode, first.

The big question is, is your internal network configured to leverage the secondary DMZ if things fail?  If so, you might want to figure out how your redundancy can ride an already existing redundancy setup instead of creating a new one...