06-24-2009 06:19 AM
Removing power and reapplying sometimes works, but generally not always. After removing power with no luck, we replace the cables, but still generally no luck. The AP (in this latest instance, AP-65s), show two green lights "on" on the "PWR" & "ENET" LEDs, but not on the "A" & "BG" LEDs.
What tricks (commands) are available to bring a down AP back up?
06-25-2009 12:18 PM
Wireless Eng. OSU
06-30-2009 10:06 AM
Funny that you see it a few times and are not concerned about it -- we see it every time we reboot one of our controllers. Booted one last night to do firmware upgrade, now I have 5 APs that won't come back online. Removed and reapplied power, but still nothing.
Don't have a Y serial splitter cable.
06-30-2009 11:21 AM
IOS (tm) C2950 Software (C2950-I6Q4L2-M), Version 12.1(22)EA2, RELEASE SOFTWARE (fc1)
IOS (tm) C2970 Software (C2970-I6L2-M), Version 12.1(19)EA1d, RELEASE SOFTWARE (fc1)
There are other APs on the same exact switches that are continuing to work just fine after the reboot.
06-30-2009 12:21 PM
sh int fa0/48
FastEthernet0/48 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0013.607c.2930 (bia 0013.607c.2930)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is unsupported output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 02:35:24, output 00:00:01, output hang never
Last clearing of "show interface" counters 9w6d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 34000 bits/sec, 16 packets/sec
40912261 packets input, 2611677374 bytes, 0 no buffer
Received 20 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 3 multicast, 0 pause input
0 input packets with dribble condition detected
145320584 packets output, 4252423030 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
06-30-2009 12:38 PM
The APs that are down might have a flag next to them that says WHY they are down. If that doesn't work, do "show datapath session table
Last but not least, make sure there is no firewall blocking traffic between those access points and the the management IP of the controller.
If you open a case, of course, support can give you a much better idea.
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
06-30-2009 12:55 PM
06-30-2009 01:18 PM
Colin is inline with what we do. I generally follow the process that the AP would take:
- Check for link connectivity on switch
- Check if mac address has been learned on switch port
- Perform shut/no shut on switchport (especially useful for POE switches)
- Check DHCP logs to see if it pulled an address
- Run "show datapath session table
Many times with APs, however, the information needed is on the AP itself. Unfortunately, Aruba engineering has yet to implement a mechanism for the AP to keep a small buffer for the purpose of retaining the last few lines of logs -- instead, they are cleared when the AP goes down. :(
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University