Wireless Access

I have a question regarding centralized licensing.  We have 3 sets of master-local controllers at 3 different sites.  I want to set the 2 controllers in SiteA to be the master and backup license servers.  This works fine.  Then I want the controllers in SiteB and SiteC to use the licensing servers in SiteA.  This works fine on the master controllers in SiteB and SiteC but the local controllers can not contact the license servers.

My scenario is a bit different then the scenarios listed in the user guide so I'm not sure if my config is right.  My controllers in SiteB and SiteC have this:

license server-ip x.x.x.x
license profile
   centralized-licensing-enable

Can you verify the following from the master/license server :

(controller) # show switches - to verify that those two controllers are locals to the master

(controller) #show  license client-table 

(controller) #show  license debug

Run the following on the local :

(controller) #show  license profile

(controller) #show  license debug

See attachments.  Master3 and local3 have the same output as master2 and local2 respectively.

Attachment(s)

master2_output.txt   1 KB 1 version

local2_output.txt   421 B 1 version

local1_output.txt   424 B 1 version

master1_output.txt   1 KB 1 version

The reason is not working for you is because local2 has the master2 as the license server but the master2 is configured as a License Client to Master1

So Local2 won't be able to pull licenses from master2 since its configured as a license client.

Please read the User Guide that it explains the Centralize Licensing for multi-controller environment (Page 109) .

I have attached the user guide 

Attachment(s)

ArubaOS_6.3UG.pdf   25.99 MB 1 version

ArubaOS_6.3UG.pdf   25.99 MB 1 version

ArubaOS_6.3UG.pdf   25.99 MB 1 version

OK.  But local2 gets it's config from master2, and it can't be configured independantly.  There's no way I know of to tell local2 to use master1 as it's license server.  If I try i get this:

(local2) (config) #license server-ip 192.168.224.106
This command can only be executed on the master or standby

So what you're saying is local controllers can only be a license client of their own master controller?  What I'm looking for can't be done in my scenario?

Just so I'm clear what my topology looks like I've added a diagram.  I have 3 separate master-local pairs.

From the ArubaOS 6.3 Manual:  here:  http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/New_Licenses/Multi__Network.htm

"You can use the centralized licensing feature in a master-local topology with a redundant backup master, or in a multi-master network where all the masters are connected to a single licensing server. In the master-local topology, the master controller acts as the primary licensing server, and the redundant backup master acts as the backup licensing server. In a multi-master network, one controller must be designated as a primary server and a secondcontroller configured as a backup licensing server."

There are also instructions at that link that mention how to configure it.

Ah Airwave.  That may be the detail I'm missing.  It doesn't say Airwave in the documentation as you have quoted.

I'm still a little lost as to how this is setup in Airwave.  The documentation doesn't mention how Airwave plays a role in the whole process.  The only mention of Airwave in the Centralized Licensing section of the user guide is under Pre-Configuration Setup in an All-Master Deployment.  I don't have an All-Master deployment.

---

@mthurb wrote:

Ah Airwave.  That may be the detail I'm missing.  It doesn't say Airwave in the documentation as you have quoted.

 

I'm still a little lost as to how this is setup in Airwave.  The documentation doesn't mention how Airwave plays a role in the whole process.  The only mention of Airwave in the Centralized Licensing section of the user guide is under Pre-Configuration Setup in an All-Master Deployment.  I don't have an All-Master deployment.

---

Nope.  I was incorrect.

If you use multiple masters, you designate a single master as the licensing server, the backup master as the backup.  You can then point the other masters to the VRRP between the single master and backup master, as its licensing server.  You only have to designate this on the master in each cluster to point to the VRRP.  You should not have to do anything on the locals.  On the master clusters that are NOT the licensing server, this is what you configure:

(host) (config) #license profile
(host) (License provisioning profile) #centralized-licensing-enable
(host) (config) #license server-ip <ip address of designated licensing master>

This is very similar to what I have done, except I did not create a VRRP cluster between the primary and backup license servers since they are master & local and the documentation seems to indicate that the redundancy is already builtin at that point.

So on master2 and master3 I set the commands you listed and I used the master1 ip instead of a VRRP address.  This all works fine, master2 and master3 work as license clients, but the corresponding local controllers do not contact the license server.  They seem to point to THEIR master controller as the licensing server even though the config they should get from their master controller is to use master1.

---

@mthurb wrote:

This is very similar to what I have done, except I did not create a VRRP cluster between the primary and backup license servers since they are master & local and the documentation seems to indicate that the redundancy is already builtin at that point.

 

So on master2 and master3 I set the commands you listed and I used the master1 ip instead of a VRRP address.  This all works fine, master2 and master3 work as license clients, but the corresponding local controllers do not contact the license server.  They seem to point to THEIR master controller as the licensing server even though the config they should get from their master controller is to use master1.

 

 

---

Okay,

It looks like for now there could be a limitation where Only individual Masters can be added to the licensing master, NOT their locals.  So you probably could only realistically do centralized licensing in a single master-local domain, or multi-master domain, but those masters cannot have locals attached.  Let me get clarification.

UPDATE:

That is the situation.  If you point additional masters to the licensing master, only the masters will have centralized licensing enabled,  Their locals will not get the centralized licenses, because it not supported.  For all practical purposes, let's just say that only Master/local clusters are supported.

OK thanks for the clarification.

Is this something that may change in the future?

I do not know.  Let me check.

Was there any news / information on if this setup will work with shared licences in the future?

There is no information currently, no.

Is this a new feature, or is it code dependent?  If so, when, or which code?

We are running VRRP on our 2 master controllers and have been purchasing separate licenses for each controller.   Always seemed kind of pointless to have to purchase an additional 56 AP/PEF licenses for a controller that has, thankfully, never been used.

Using centralized licensing would save us some money that I could redirect to more useful things like APs and licenses for my branch sites.

---

@COLE1 wrote:

Is this a new feature, or is it code dependent?  If so, when, or which code?

 

We are running VRRP on our 2 master controllers and have been purchasing separate licenses for each controller.   Always seemed kind of pointless to have to purchase an additional 56 AP/PEF licenses for a controller that has, thankfully, never been used.

 

Using centralized licensing would save us some money that I could redirect to more useful things like APs and licenses for my branch sites.

---

ArubaOS 6.3 and above.  Release notes below:

http://support.arubanetworks.com/DOCUMENTATION/tabid/77/DMXModule/512/Command/Core_Download/Default.aspx?EntryId=11847

Thanks.  Just now getting everything on 6.1.3.10.  Working towards 6.2 for DHCP fingerprinting, but guess we'll be looking at making the jump to 6.3 for the added features.