Wireless Access

Alright, on to the next issue. Now that I'm able to get these APs provisioned, 2 out of the 8 so far are coming to an "up" state but the radios are not coming up. I'm provisioning them in alternating AP groups, but I've seen it happen with both, so I know it's not related to the AP Group.

Any ideas what would be preventing the radios from coming on?

Could you start by giving us the output from a "show ap database" command? You can always do a "| include 135" if this only releates to the AP-135 that you are troubleshooting.

Thanks!

Have you configured anything non default in the ARM or radio profiles for the groups? Mode aware ARM can cause this if the interference levels are high.

Oh, and a "show ap active" output will help show what it's doing too.

What's the configuration like within the AP group? How many VAPs did you add?

Interestingly enough, after rebooting sometimes the radios come right up. However, I'm just basing whether the radios are up or not based on whether I see a channel assigned to the radio. Sometimes I do see channels assigned to the radios but the radio LEDs are not lit up on the APs. Should I be concerned about this?

I haven't done anything weird in the ARM profile at all. The only thing I changed it to was multi-band (I think it defaults single-band?)

On the commandline, type "show audit-trail" to see what you typed.  You might be able to figure it out.

I think we need to see your config (AP groups, VAPs and radio/ARM settings). Just a snapshot of those bits. And an output from a "show audit-trail", "show ap active" and "show ap database long".

The radio lights should definately be on if the AP is functioning as a normal AP (with a VAP), and has a tunnel to the controller up.

Alright, here's a good example. AP shows as up but no channels assigned and no radio LEDs.

As far as the config goes - I have two AP groups (group_a and group_b) but they use the same VAP, ARM profile, SSID profile... the only difference is the AP system profile... each different one has swapped LMS IPs to provide load balancing.

And just to reiterate... this is one subnet... the two controllers and the AP are connected by a simple, dumb switch.

show ap active:

(TerminalRoad-Master) #show ap active

Active AP Table
---------------
Name  Group  IP Address  11g Clients  11g Ch/EIRP/MaxEIRP  11a Clients  11a Ch/E
IRP/MaxEIRP  AP Type  Flags  Uptime  Outer IP
----  -----  ----------  -----------  -------------------  -----------  --------
-----------  -------  -----  ------  --------

Flags: a = Reduce ARP packets in the air;  A = Enet1 in active/standby mode;
       B = Battery Boost On; C = Cellular; D = Disconn. Extra Calls On;
       d = Drop Mcast/Bcast On; E = Wired AP enabled; K = 802.11K Enabled;
       L = Client Balancing Enabled; M = Mesh; N = 802.11b protection disabled;

       P = PPPOE; R = Remote AP; X = Maintenance Mode;
       2 = Using IKE version 2;

Channel followed by "*" indicates channel selected due to unsupported configured
 channel.
"Spectrum" followed by "^" indicates Local Spectrum Override in effect.

Num APs:0

show ap database long:

(TerminalRoad-Master) #show ap database long

AP Database
-----------
Name               Group    AP Type  IP Address   Status     Flags  Switch IP
 Wired MAC Address  Serial #   Slot/Port  FQLN  Outer IP  User
----               -----    -------  ----------   ------     -----  ---------
 -----------------  --------   ---------  ----  --------  ----
d8:c7:c8:c0:c7:c0  Group_A  135      10.206.1.86  Up 3m:33s         10.206.1.81
 d8:c7:c8:c0:c7:c0  AX0025568             N/A   N/A
d8:c7:c8:cb:0a:fa  Group_B  134      10.206.1.99  Down              10.206.1.81
 d8:c7:c8:cb:0a:fa  AX0034173             N/A   N/A
d8:c7:c8:cb:10:54  Group_A  134      10.206.1.96  Down              10.206.1.80
 d8:c7:c8:cb:10:54  AX0034858             N/A   N/A
d8:c7:c8:cb:10:bc  Group_B  134      10.206.1.93  Down              10.206.1.81
 d8:c7:c8:cb:10:bc  AX0034910             N/A   N/A
d8:c7:c8:cb:10:f0  Group_B  134      10.206.1.91  Down              10.206.1.81
 d8:c7:c8:cb:10:f0  AX0034936             N/A   N/A

Flags: U = Unprovisioned; N = Duplicate name; G = No such group; L = Unlicensed
       I = Inactive; H = Using 802.11n license; D = Dirty or no config
       X = Maintenance Mode; P = PPPoE AP; B = Built-in AP
       R = Remote AP; R- = Remote AP requires Auth; C = Cellular RAP; c = CERT-b
ased RAP; 2=Using IKE version 2
       M = Mesh node; Y = Mesh Recovery

Total APs:5

show audit-trail: see attached file.

Here's something interesting... I've got a mix of AP134s and AP135s. I've noticed a difference between them. When the 134s boot up, after they upgrade their image they show up as unprovisioned access points. However, the 135s come up and automatically show as "up" with radio channels assigned, in the AP group 'default', but are flagged inactive, and while the radio LEDs are on, they are amber, not green. 

When I provision these I'm setting a static IP (which is still valid on the subnet) but assigning a default gateway that doesn't currently exist on the network. I would think this should matter since the controller is only 1 hop away anyway.... right?

Attachment(s)

audit.docx   16 KB 1 version

AP 134s need to be provisioned with the DB of the connected external antenna, otherwise they won't come up.

---

@cjoseph wrote:

AP 134s need to be provisioned with the DB of the connected external antenna, otherwise they won't come up.

---

 

I'm definitely entering that. Actually I don't think it'll even let you provision with those fields blank. Well, at least it didn't let you back in the 3.x.x.x times.

 

 

This looks like output from the master.  The master will show you the status of the AP (up/down), but won't show anything in "show ap active".  You will only see channel/power and user info from the controller where the AP terminates it's data tunnels.  Can you go to 10.206.1.81 and do "show ap active"?  Do you see the AP there?

Also, how are these APs being powered? According to the AP-130 series installation guide, they use 802.3at! Not 802.3af. Unless this is a typo, power may be your issue. Are they all going into the same PoE switch? Is that switch pushing out 802.3at power?

They run on standard 802.3af power.

See below from datasheet: 

Power
• 48 V DC 802.3af PoE or 802.3at PoE+
• 12 V DC external AC supplied power (adapter sold separately)
• Maximum power consumption: 15 watts

---

@jfernyc wrote:

They run on standard 802.3af power.

 

See below from datasheet: 

 

Power
• 48 V DC 802.3af PoE or 802.3at PoE+
• 12 V DC external AC supplied power (adapter sold separately)
• Maximum power consumption: 15 watts

---

Could be a mistake in the install guide then.

From the install guide:

Pre-Installation Checklist
Before installing your AP-130 series access point, be sure that you have the following:
 For the AP-134: External antennas as specified in the network deployment plan
 CAT5 or better UTP cable of required length
 One of the following power sources:
 IEEE 802.3at-compliant Power over Ethernet (PoE) source
 The POE source can be any power source equipment (PSE) controller or midspan PSE device
 Aruba 12 VDC AP AC-DC adapter kit (sold separately)

And under Electrical:

Power over Ethernet (IEEE 802.3at compliant), 48V DC/350mA (see Table 1 on page 9 for pin
configuration)

I've decided to go back to ground zero. I've wiped the config of both controllers. I am going to try to provision an AP with all defaults in a single controller environment and if that works I will slowly add what I need.

802.3at is only required if you want to use the eth1 port on the AP. Otherwise .af is fine.

These controllers are not just lab controllers, I am configuring them for a customer. They will be going on site early next year. What is the latest stable build?

On a somewhat unrelated note, how in the world do you change the console baud rate? 9600 is getting old with these long logs/etc.

Well, after wiping the configs clean I was able to get an AP provisioned and up with the radios operational. The only thing that I changed in ARM was setting the ARM mode from single-band to multi-band. Why did I? No idea. This is the first .11n system I've set up and thought it might be necessary. I wonder if that is what it was?

Nope.  That alone would not do it.

Maybe, but I doubt it.  The dual band vs single band knob was used for single band radios (mostly).  If you set it to multi-band and an AP only has one radio (like the AP-60/61 or the AP-92/93), the AP calculates its best channel and power across both spectums.  An AP running in the 2.4GHz spectrum may decide it has enough coverage and switch to the 5GHz spectrum.  If you set the ARM mode to single-band, the AP would stay in which ever band was specified in the AP system profile.

This is an old thread, but I just realized that creating an SSID profile and assigning a VLAN that hasn't been created on the controllers will disable the SSID on the APs, if that's the only SSID then the radios will be off as there is nothing assigned to them.

Hope this tip helps anyone.

Regards

Let me also reiterate that there's no consistency here at all. There are about 4 different scenarios I am seeing here.

1) AP comes up, radio light comes on, SSID is broadcast and all is hunky dorey.

2) AP comes up, radio channels are assigned, but radio LEDs are out.

3) AP comes up, no radio channels, no radio LEDS.

4) If I provision an AP to the default AP Group (only difference being AP system profile) the AP shows up, radio channels are assigned, LEDs are amber instead of green and AP is flagged as "inactive" when I 'show ap active' ...

I'm about ready to clear the config on both controllers, set up the master/local relationship, and start over with all default AP group/profile settings.

Which Aruba OS version are you running?

 

---

@zjennings wrote:

Which Aruba OS version are you running?

---

6.1.1.0. Should I upgrade? If so, to what?

AOS 6.1.2.5 is the latest code release in that code train.  (available on support site)

I would upgrade to 6.1.2.5, especially if this is just a lab controller.