First, discovering APs using a remote file works fine, this is not a problem. This said, problem is that MAC field is required. If this field is empty, file is simply not imported, job comes out with an instantaneous error. If this field contains a dummy MAC address, APs are detected twice, hence consuming two licences per AP: one for the dummy MAC, the other with the right MAC (after getting audited). By the way, the one with the dummy MAC shows -obviously- an alarm about MACs being different. In my customer's case, they do not have the MAC address for each AP. And doing the inventory of their APs is one of the reasons for them to use ADSP! It does not make much sense to tell them to first inventory the MAC addresses of their APs (by the way, about 2000) in order to be able to fully inventory them with ADSP afterwards. Or to "spoil" half of the expensive licences. In my opinion, using a dummy MAC address should come out with one single licence used, with the logical expected alarm about, of course. Am I right? If not, how can we sort this out? Another issue would be when APs are replaced due to repairs -while keeping the same IP address. MAC may vary. I can though assume this is part of this tricky "reallocation" licencing policy, which happens to be half of the total licences (1250 in my case, they have 2500 licences). Thanks!
Discovering APs via remote file |
5 Replies
On the automated method for import you do have options in the appliance CLI to do a discovery outside of the GUI. To find details on how to do a discovery from the CLI simply enter "discover -help" to view details on what needs to be used. The documentation on CLI commands can be found at: http://supportcentral.motorola.com/support/search.do?cmd=displayKC&… 0 304678006 On the duplicate device problem it does look like you are importing the incorrect MAC address. An SNMP walk will provide all the MAC addresses the device supports so it's very possible to get different results from different tools. Once the ADSP system attempts communication with that device it will create a new object if the MAC address is not identical. Now that you know the pattern if you adjust the MAC address for import you will not experience the duplicate devices. Nathan
Discovery doesn't always have to be a subnet search for device it could be also viewed as method to import specific APs. If you know the IP address but not the MAC address you can do a "discovery" on just those APs which would effectively be an import. Discovery can be done scheduled, manually or from the appliance CLI. To find details on how to do a discovery from the CLI simply enter "discover -help" to view details on what needs to be used.
Thanks, but unfortunately there is no way to do a SMNP discovery via remote file, i.e, importing a simple list of IP addresses (say, via SCP or FTP) so ADSP performs a SNMP discovery on these data. If this way existed, it would be a good feature indeed. All you can do now is manually "pasting" the list to the GUI interface and then do the SNMP discovery. What Correos wants is automating discovery/audit procedure, via importing remote files. By the way, I found a new issue today, again regarding MAC addresses. Correos managed to create the right file with the (supposedly) right MAC addresses, using their SMARTS SNMP tool. Good! When we imported the file, after all their 1716 APs were getting audited, device number started increasing up to their total 2500 licences. Obviously, APs were duplicated. But MAC was corrected. Was it? I do not really know. Let's see an example: AP whose IP is 10.150.1.11 has LAN1 MAC address 00:15:70:e2:ba:f3. This has been detected by SMARTS and I also checked it on the very AP GUI interface. This entry was detected as a Stand alone AP, which is right, despite all these APs are also managed by RFS7000 (only the wireless part, that's why we need ADSP). AP fw was not reported. However, it has an alarm saying that its MAC is incorrect, it should be 00:15:70:e2:ba:f2 !! And there is another duplicated entry, this time detected as Adaptive and reporting fw version, with MAC address being 00:15:70:e2:ba:f2. I have attached a file with 4 samples of the same issue. Correos' SMARTS guys have found that this MAC-1 address is actually an undocumented OID (framework or so) and they need to know which is the right MAC that has to be declared in the file. What is most strange is that I earlier tested 11 APs with LAN1's very MAC address and this issue did not happen. Another side effect issue of all this is that we ran out of licences, especially "reallocation" ones (just 1250) are not enough to go back to a stable situation to start from scratch once we know which MAC address is to be used. May anyone give me a hand on this? Thanks!
Is there a reason you are looking to import the APs via remote file instead of discovering them via SNMP?
Yes, of course. Spanish Post (my customer) is currently doing this with Cisco Works, to manage their Cisco APs. They do not massively discover them, they just create a file containing the actual IP addresses (and maybe some more things), some autoplacing rules and finally the tree of their locations. ADSP can do it as well, it is featured. The thing is that it does not do the neat way they'd wish. For instance, importing the Tree requires a manual Apply -I have raised an SPR about, by the way. Having to specify the MAC addresses beforehand is an incovenient too. The good thing is that all of the AP5131s are currently adopted by RFS7000s, so eventually we could figure out how to get the MAC addresses from them (and matching the corresponding IP address). But this might be an enduring task, considering they have about 2000 AP5131!