Wireless Access

Im tyring to monitor lease pool usage, but noticed none of the APs off my subnet reply to pings, but the ones that are on the same as my wired pc do.  

 

We used to ping APs a few years back on one of our monitoring platforums, but have changed bardware and various codes since then.. but not sure why I cant ping APs on another subnet!

 

I did find a thread relating to this command, but this didnt help

no firewall enable-stateful-icmp

 

Any ideas?

thoughts....

pinging APs from where ? controller CLI ? other ?

are you using CAP? RAP ? CPSEC ? 

how are the APs getting an IP ?

Thought Id replied to this! :-(

 

Trying to ping an AP from my PC (wired connection).  Can ping an AP on same subnet as my PC, but not others...  

 

Using CAP, and APs getting IP from our primary DHCP servedrs.  The APs are connected to the network using the same vlan as wired clients, so I should be able to ping one the same as any other connected pc etc.  We used to be able to (going back a while), as we used a monitoring platoform to ping all APs. 

 

Im not wanting to ping APs to determine status, but to perform an audit of our IP scopes and not getting replies from the APs is skewing the results making them pretty useless!

 

Thanks

so no cpsec ?  I am going to presume not for now.

 

These two sentences seem contradictory:

Can ping an AP on same subnet as my PC, but not others...

and

The APs are connected to the network using the same vlan as wired clients, so I should be able to ping one the same as any other connected pc etc.

If I understood your first post, the issue is cross-subnet only and were you to move the 'pinger' to same subnet of an affected AP then the issue is resolved.

 

At any rate, for starters, see if the AP sees your inbound ping, e.g. setup a constant ping from your PC, and then run

show datapath session ap-name yourApName

have a look and see if you see the inbound icmp, will look like this (pardon the wrapping)

192.168.1.246   192.168.1.24    1    1     2048  0        0    0   0   dev2        13   --         --         FYCI

192.168.1.24    192.168.1.246   1    1     0     0        0    0   0   dev2        9    --         --         FYI

in this case .24 is the AP, .246 is the pinger. Ensure the flags are as you see here, and that you have a matched pair like this (src port is the icmp seq number, here is 1)

 

might be worth while just double checking the routing table in the AP too, use "show datapath route ap-name yourAPName" and also "show datapath route-cache ap-name yourApName" and make sure it all makes sense (e.g. the mac adddresses in the route-cache make sense for the default gateway of the AP etc.)

 

 

 

 

 

Hi, sorry, penny didnt drop at first what cpsec was, but yes, it is enabled.

Thanks for the troubleshooting tips, ill have a go and report back.

Ok that confirms what i was suspecting, cpsec is the reason i believe. The default route of the ap will be up the ipsec tunnel, the same thing happens to raps.

Your ping will be arriving at the ap and the response will be routed up the tunnel to the controller. I am not sure if it's getting dropped there due to policy or lack of a route. Take a look in the " show datapath session | include yourPCIpAddr" And see if it has a D flag on it.

It may be the case that you can reach it using the controller itself as a gateway - try that too.