Hello -- I am configuring 3x - 1242 access points. I have 2 configured as an AP, and one as a WGB. My configs are identical except for the management IP on interface bvi1, for each device. The WGB will be on a mobile crane. Hard to get to for many reasons. During testing of my configs, I am able to associate the WGB with either of the 2 APs. I can always get traffic from my PC on the WGB, across the wireless link to the LAN (the traffic is on a different IP NW than the managment IP). I can take down either access point and see the WGB associate to the other one AOK.
What happens is occaisionally the management IP on the WGB becomes innaccessible from my management PC on the LAN. If I power down the associated AP, the WGB mgmt IP will come back. I can also bring it back by the command "Clear ip arp a.b.c.d" where a.b.c.d is the IP of the mgmt PC.
Is there an arp cache or arp timeout on one of the devices that affects this? If so I can't figure it out. A small summary of my config is below. Note: My LAN and this wireless is FLAT topology. There is a router port for the 10.2.x.y/16 traffic, but no gateway between the 10.2 and the 15 nets. This is working everywhere except in this example.
AP-1 mgmt IP: 22.214.171.124/8
AP-2 mgmt IP: 126.96.36.199/8
WGB mgmt IP: 188.8.131.52/8
Mgmt PC: 184.108.40.206/8
LAN TEST PC connected to WGB: 10.2.25.30/16
TFTP Server: 220.127.116.11
The 2 APs are connected to a switch, along with the Mgmt PC. The switch is uplinked to my LAN (I.E.; for the tftp server access).
The WGB is isolated (because it is wireless), and connected to the LAN TEST PC.
As I was typing this up, the WGB mgmt IP address started timing out from the mgmt PC. Traffic is still going across the WGB at all times (I am remotely connected to another PC via this WGB - typing this example!).
I forced a re-association to AP-2 and the WGB mgmt IP address started pinging again from the Mgmt PC.
so - it goes. It dies, and I reassociate and it comes back.
Another interesting item is if it dies, without reassociating to the other AP, I can do the "clear ip arp a.b.c.d" command (on the WGB), and it will restore connectivity. Show dot11 associations shows that the arp entry is gone from the associated AP also, but issuing that command on the AP fails (because it isn't there to clear).
;-) Yes it is a waste of IP addresses, but not the point. I have dozens of WGBs so that mask wouldn't work and this IP is only fo rmgmt. I have other 1230 APs, and 1310 APs and the configs are almost identical. The network is flat, so multiple vlans between the APs and WGBs? Why would that fix this? There are legacy reasons for this.
and another note of interest: From (any) mgmt PC with a 15.x.y.z address, the ping to the WGB quits responding preciesly 10 mins after association to an AP (as described), or reassociation, or using the "clear ip arp 15.x.y.z" command on the offending WGB... hmmm...
In once again answering my own questions - I've asked a Cisco rep why this is. This is a security feature against DOS ICMP attacks. When pinging from a single IP address every second, continuously - you will find that the AP will stop responding at 600 seconds. Then - 3hr and 50m later - it will start again, for another 600 seconds. I monitored this system by only pinging once every 15 secs and it never failed. My fix was:
arp timeout 300 (or something less than 600)
I couldn't actually find the command or default command that casued the 600 second timeout, but fixing it at this point became a challenge, so there it is...
Any debate further although interesting would be unneccesary!
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...