Reply
Occasional Contributor I
Posts: 5
Registered: ‎05-20-2009

AP serverip

One of the environmental config parameters for Aruba APs is 'serverip'. I've been attempting to discern whether this parameter serves any useful function. The APs appear to use 'apboot', which is open-source software for AP config and initialization. The documentation for the package is thin, but it appears that 'serverip', for that package, is the IP address of a server providing AP firmware via TFTP. Since Aruba APs retrieve their firmware from a local controller, and -- based on a series of tcpdumps -- it appears to me that firmware is retrieved via FTP (rather than TFTP), I suspect that the 'serverip' config parameter serves no useful function for Aruba APs.

Can somebody verify whether this is true? If it is incorrect, what purpose does this parameter serve?
Aruba Employee
Posts: 455
Registered: ‎04-02-2007

Re: AP serverip

Yes, it is for TFTP boot of the AP and should be set to the controller IP if you were statically configuring your APs or needed to recover a stuck AP. The APs currently try FTP first, then fall back to TFTP if FTP fails. There is really no reason to set any of the parameters in AP boot unless requested by TAC, and even then you probably want to handle it through the AP provisioning process unless you can't reach the AP from the controller.

-awl
Andy Logan, ACDX
Director, Strategic Account Solutions
Aruba Networks
Occasional Contributor I
Posts: 5
Registered: ‎05-20-2009

AP serverip

There are a handful of reasons why, in our environment, configuring the APs via their console makes the most sense for us. In any case, I'm attempting -- based on what you say above -- to reason out when the AP will elect to use the TFTP mechanism to retrieve firmware. My understanding is that the AP locates a master controller (either via a static config parameter, a dhcp option, dns or ADP), and receives additional config parameters from it (it looks to me as though this happens via a UDP exchange, presumably using an Aruba defined protocol). I believe that the lms-ip parameter is communicated by the master at this point. Finally, I believe that the AP attempts a firmware download via FTP from the configured LMS IP.

If these things are true, I assume the AP will attempt a TFTP transfer really only if the configured LMS IP is unreachable or the FTP mechanism does not work as expected (i.e., an FTP connection to the lms-ip is rejected, the server provides a failure message in response to the authentication credentials, or the image is not in the correct place). The testing I performed suggests, for example, that a TFTP download does not happen if the master is unreachable or no local controller is configured (e.g., if an invalid ap-group is assigned to AP).

Are my understandings in the first paragraph accurate? If so, are the assumptions in the second paragraph also correct?
Aruba Employee
Posts: 455
Registered: ‎04-02-2007

Re: AP serverip

What you have to remember is that this mechanism is in place to get software updates from the controller. It needs the controller to be online for the updates to occur. This variable and download mechanism is set automatically when the AP reaches the controller, it will try to FTP to the controller followed by TFTP if that fails. If the controller is not online then nothing happens as these are dependent APs.

Can you elaborate on why neither option 43 in DHCP and aruba-master in DNS are not going to work for you so we can better understand the situation?

-awl
Andy Logan, ACDX
Director, Strategic Account Solutions
Aruba Networks
Occasional Contributor I
Posts: 5
Registered: ‎05-20-2009

AP serverip

That makes sense. What I don't fully grasp is under what situations Aruba expects that FTP would fail on a controller. Assuming it's never intended that a non-controller device would be set up to provide firmware images, aside from something in the path preventing FTP or a bug lurking in the controller's FTP module, it seems to me that TFTP would never really be necessary.

Perhaps a little background would be helpful to understand why I ask. In one wireless domain, we have 24 controllers -- 2 masters and 22 locals. When we perform minor version upgrades, it takes a while to upgrade all of the controllers. Specifically, we don't upload the new version to all of them, then just reboot them all at the same time. We upgrade one controller at a time to ensure that there are no problems. Moreover, because of the constraints imposed by our general network change management policy, we spread the last upgrade over a few days. This means that, for a non-zero period of time, the primary master is running a slightly different version than some set of local controllers. Mixed versions, I realize, are contrary to what Aruba advises, but unless all controllers are upgraded simultaneously or the domain is split in two (which we did when we went from 2.5 to 3.3, but for minor upgrades is more work than it's worth), I see no other option. We always set the serverip to the master controller vrrp address, which I believe conforms to best practices. I was seeking to understand when the serverip would be used for firmware retrieval (rather than the usual FTP to the defined lms-ip) in the event that it could or would cause issues in this mixed environment.

Largely, based on what you've said, the point is academic, but I do want to thoroughly understand the ramifications of our approach.

As to your second question, I assume that you're really asking why we configure the APs via their console, rather than allowing discovery of the master controller, and subsequently configuring the APs via the controller. If that's the case, the fundamental reason is that we use static IP addressing for APs (rather than DHCP). We do this for a few reasons, but the most important is that the NMS we use for monitoring and polling all network equipment relies on static addressing for equipment. Naturally, we could fix the IP address via DHCP based on MAC, but that's far more work than simply configuring the AP with a static address via its console. Alternatively, we could allow DHCP address acquisition, then later set the IP via the controller, but frankly that, too, is more work than simply setting it via the console. We also configure the name and group parameters via the console, because in the order of installation, this is simpler than subsequently provisioning this via the controller (especially when a contractor installs the APs; we don't want them touching the controller, but we also don't want to have to do post-install provisioning).

This leaves the master IP. I'm not sure if the APs do a DHCPINFORM request for option 43 even if they are configured using the ipaddr param. In any case, I suppose we could use DNS for master controller discovery. But based on our configuration method, I see this as advantageous only if the master IP vrrp address is changed. Naturally, this is a very rare occurrence. On the other hand, we have multiple wireless domains (and thus, multiple sets of master controllers, one per domain). So, we either have to use split DNS views, configure different DNS domains for APs based on where they are located, or make sure the DHCP option is correct on a per-domain basis. None of these seem as simple as simply setting the masterip parameter when the AP is configured.
Guru Elite
Posts: 21,512
Registered: ‎03-29-2007

Provisioning


That makes sense. What I don't fully grasp is under what situations Aruba expects that FTP would fail on a controller. Assuming it's never intended that a non-controller device would be set up to provide firmware images, aside from something in the path preventing FTP or a bug lurking in the controller's FTP module, it seems to me that TFTP would never really be necessary.

Perhaps a little background would be helpful to understand why I ask. In one wireless domain, we have 24 controllers -- 2 masters and 22 locals. When we perform minor version upgrades, it takes a while to upgrade all of the controllers. Specifically, we don't upload the new version to all of them, then just reboot them all at the same time. We upgrade one controller at a time to ensure that there are no problems. Moreover, because of the constraints imposed by our general network change management policy, we spread the last upgrade over a few days. This means that, for a non-zero period of time, the primary master is running a slightly different version than some set of local controllers. Mixed versions, I realize, are contrary to what Aruba advises, but unless all controllers are upgraded simultaneously or the domain is split in two (which we did when we went from 2.5 to 3.3, but for minor upgrades is more work than it's worth), I see no other option. We always set the serverip to the master controller vrrp address, which I believe conforms to best practices. I was seeking to understand when the serverip would be used for firmware retrieval (rather than the usual FTP to the defined lms-ip) in the event that it could or would cause issues in this mixed environment.

Largely, based on what you've said, the point is academic, but I do want to thoroughly understand the ramifications of our approach.

As to your second question, I assume that you're really asking why we configure the APs via their console, rather than allowing discovery of the master controller, and subsequently configuring the APs via the controller. If that's the case, the fundamental reason is that we use static IP addressing for APs (rather than DHCP). We do this for a few reasons, but the most important is that the NMS we use for monitoring and polling all network equipment relies on static addressing for equipment. Naturally, we could fix the IP address via DHCP based on MAC, but that's far more work than simply configuring the AP with a static address via its console. Alternatively, we could allow DHCP address acquisition, then later set the IP via the controller, but frankly that, too, is more work than simply setting it via the console. We also configure the name and group parameters via the console, because in the order of installation, this is simpler than subsequently provisioning this via the controller (especially when a contractor installs the APs; we don't want them touching the controller, but we also don't want to have to do post-install provisioning).

This leaves the master IP. I'm not sure if the APs do a DHCPINFORM request for option 43 even if they are configured using the ipaddr param. In any case, I suppose we could use DNS for master controller discovery. But based on our configuration method, I see this as advantageous only if the master IP vrrp address is changed. Naturally, this is a very rare occurrence. On the other hand, we have multiple wireless domains (and thus, multiple sets of master controllers, one per domain). So, we either have to use split DNS views, configure different DNS domains for APs based on where they are located, or make sure the DHCP option is correct on a per-domain basis. None of these seem as simple as simply setting the masterip parameter when the AP is configured.




boguese,

You bring up quite a few points. Just thinking out the box here, there are a number of things that you might want to do. Since you have a sizeable network, if you used Airwave to manage those APs, it would keep track of the device regardless of the IP address, as well as alert you if they are down/up/errored/overloaded/whatever. That way you would not have to manage fixed IP addresses; you could plug those APS in anywhere. With regards to discovering the master controller or "A" controller, period, your other option besides DHCP options, and DNS is multicast. The controller would advertise multicast on 239.0.82.11. If you would allow/filter that on certain subnets, and you could decide exactly which APs discover what controllers. With regards to naming the APs and putting them into ap-groups, the rename command takes the serialnumber or the wired mac address of the access point as a parameter, so if your contractor can give you a spreadsheet with the serialnumbers and the AP-name you can use the spreadsheet-and-paste method to rename dynamically addressed, new APs doing the following on the commandline:

(M3.arubanetworks.com) # ap-rename serial-num A50076272 mcmahon-room-365
(M3.arubanetworks.com) # ap-rename wired-mac 00:0b:86:c5:5e:50 mcmahon-room-365
(m3.arubanetworks.com) # ap-rename ?
ap-name Rename AP with this name
serial-num Rename AP with this serial number
wired-mac Rename AP at this MAC address


You can also paste in commands to re-group the APs, via wired mac address, serialnumber and as well:

(M3.arubanetworks.com) # ap-regroup ?                                          
ap-name Regroup AP with this name
serial-num Regroup AP with this serial number
wired-mac Regroup AP at this MAC address


You can use the excel to cli method to rename them here: http://airheads.arubanetworks.com/vBulletin/showthread.php?t=874

Even if you don't use Airwave, the controller maintains the last IP address that each AP has used to contact it permanently.

Just my 2 cents


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor I
Posts: 5
Registered: ‎05-20-2009

AP serverip

I definitely appreciate all of those thoughts.

We do have airwave (and, in fact, we must have it for WMS offloading, since the WMS function drowns the master controllers for our largest domain). However, we have an NMS for monitoring our other myriad of devices, and it's much easier for operations to use one system for monitoring and fault reporting than a series of systems. Moreover, it's easier to programmatically correlate events between device types when they are monitored as part of an integrated system. We also have a single system for device configuration management, and the controllers are integrated into that.

I am aware of the multicast discovery mechanism, and in fact, we do extend multicast everywhere that matters. One of the tricky things for us, though, is that we have multiple aruba domains (and thus, multiple sets of masters) in an integrated multicast route domain. An AP, then, might end up on any of the sets of masters, regardless of the aruba domain in which we want it to end up. There are a few ways to work around this (including, as you say, per-subnet filtering), which we will perhaps contemplate. There is an advantage, though, to have the contractor complete all of the AP configuration. We require that, after a build, the contractor validates the build by performing a site survey. If controller provisioning is required, the workflow would be: 1. contractor installs APs and collects serial numbers; 2. we provision APs via the controller; 3. contractor performs site survey. If there is a transcription error in step #1, then multiple iterations of #2 would possibly need to occur. Also, as you may have experienced, large organizations (like ours) can move somewhat slowly, so the lag between the steps might be somewhat large. Today, we configure any new groups that are part of a build, provide the contractor with the naming convention and the group(s) to which the APs belong, then they do the config, install and survey without needing additional intervention by us.

I hope you understand from all of this that we're definitely open to finding ways to make our operation more efficient, and I very much do appreciate your thoughts. This has been tremendously useful. I'm also not intending to suggest that our approach is the most effective. Sometimes, processes evolve as the underlying products evolve and/or as we grow to better understand the product's intended paradigms. In any case, it does sound like you'd like to understand our approach and the rationale behind it, and I presume this info can be useful to Aruba's development course.
Search Airheads
Showing results for 
Search instead for 
Did you mean: