Wireless Access

Out of 473 APs, I can only ping 20 of them.  For those that I cannot ping, they are pingable from the same subnet, but not from outside the subnet.  

The APs are configured exactly the same and I cannot see any difference between the ones that are pingable and the ones that are not.  In all cases I can ping other devices that are in the same subnet as the AP.  It is only the APs that do not respond to ping.

I've checked firewall logs and confirmed that the pings are getting through.

It seems to me that the pings are reaching the APs, but for whatever reason they are not getting back.  Any ideas of what may be the issue or where to look?

Ddi you check the default gateway of the APs?

If they are not correctly set you wont be able to ping them from another network....

Did you statically put the IP to the AP? or its through a DHCP?

If the controller is in the same vlan than the APS then they wont need a default gateway to work in tunnel mode.... you will see everything working perfectly as all the traffic is send to the Wireless controller...

If you manually set it... you can check the AP default gateway under ap installation and checking it there on the configuration.

Cheers

Carlos

I've confirmed that the default gateways are correct.  The IPs are all set statically and the APs are not on the same VLAN as the controller.

The APs function normally except for the fact that I cannot ping most of them.

are yout pinging it from your computer? can you try pinging it from the wirrless controller instead? if it work from the controller then it must be a routing issue... do you know if the aps that you can ping are on an specific vlan or vlans? and the ones you cannot ping are on other specific vlans

I'm unable to ping them from anywhere outside of the VLAN, including my computer and the controller.  It can't be a routing issue because I can ping other devices in the same VLAN.  

All of the APs are remote APs on different VLANs that are specific to each remote location.  I do not see any pattern or difference in configuration between the 20 that are pingable and the 473 that are not.  One thing that I have noticed is that if I can ping one AP in a specific VLAN, I can ping all of the APs from that particular VLAN.

There is no difference between the VLANs that are pinging and the ones that are not other than they are in a different physical location.

Oh all those aps are remote APs?  though they were campuses APs...

Do you mean they are on RAP mode? right?

Because thats different...

ALL of them? are you pinging the outside address ip of the RAP?

Also on the System profile of those RAPS that you cannot ping,  can you tell me what ACL is applied on the paramether Session ACL can you tell me on the access list that selected there the firewall rules of it?

 Also Are those RAPS are going over a private link or over intenret? i suppose they are going through a private link... right?

A nice network diagram will help us to help you.... remenber we are trying to imaginate what you got in there..

Couple of other thoughts/questions:

- You say these are remote APs; I assume you mean true RAPs and not just APs are a remote site?  

- If they are RAPs, are you pinging the AP IP (inner L2TP pool IP) or the Outer AP IP?  The inner IP should respond if the RAP is terminated on the controller that handed out that address.  The outer IP will likely not be pingable from the controller.

- Are you sure the controller you are pinging from is the one the RAPs are terminated on?  If not, you can add a route to the inner IP on the controller (or your network) to direct the next hop to the controller's IP

We have several hundred remote locations and each has anywhere from 2-5 APs.  Our controller is located at our central datacenter.  The APs communicate with our controller via our MPLS network.  They are mostly 125's and a few 105's.

Here is the configuration of our APs:

AP "s012aruba01" Provisioning Parameters
----------------------------------------
Item Value
---- -----
AP Name s012aruba01
AP Group RETAIL-L1
Location name N/A
SNMP sysLocation N/A
Master 10.186.1.100
Gateway 10.11.1.1
Netmask 255.255.255.0
IP Addr 10.11.1.3
DNS IP N/A
Domain Name N/A
Server Name aruba-master
Server IP 10.186.1.100
Antenna gain for 802.11a N/A
Antenna gain for 802.11g N/A
Antenna for 802.11a both
Antenna for 802.11g both
IKE PSK N/A
PAP User Name N/A
PAP Password N/A
PPPOE User Name N/A
PPPOE Password N/A
PPPOE Service Name N/A
USB User Name N/A
USB Password N/A
USB Device Type any
USB Device Identifier N/A
USB Dial String N/A
USB Initialization String N/A
USB TTY device path N/A
USB modeswitch parameters N/A
Remote AP Yes
Link Priority Ethernet 0
Link Priority Cellular 0
Mesh Role none
Installation default
Latitude N/A
Longitude N/A
Altitude N/A
Antenna bearing for 802.11a N/A
Antenna bearing for 802.11g N/A
Antenna tilt angle for 802.11a N/A
Antenna tilt angle for 802.11g N/A
Mesh SAE sae-disable

Here is the configuration of the system-profile:

AP system profile "RETAIL-L1"
----------------------------------
Parameter Value
--------- -----
LMS IP 10.186.1.101
Backup LMS IP 10.186.1.100
LMS Preemption Enabled
LMS Hold-down Period 600 sec
Number of IPSEC retries 360
LED operating mode (AP-9x/AP-10x/AP-12x/RAP-5x only) normal
RF Band g
Double Encrypt Disabled
Native VLAN ID 11
SAP MTU N/A
Bootstrap threshold 8
Request Retry Interval 10 sec
Maximum Request Retries 10
Keepalive Interval 60 sec
Dump Server N/A
Telnet Disabled
SNMP sysContact N/A
AeroScout RTLS Server N/A
RTLS Server configuration N/A
Remote-AP DHCP Server VLAN N/A
Remote-AP DHCP Server Id 192.168.11.1
Remote-AP DHCP Default Router 192.168.11.1
Remote-AP DHCP DNS Server N/A
Remote-AP DHCP Pool Start 192.168.11.2
Remote-AP DHCP Pool End 192.168.11.254
Remote-AP DHCP Pool Netmask 255.255.255.0
Remote-AP DHCP Lease Time 0 days
Remote-AP Backup Ports Enabled
Remote-AP uplink total bandwidth 0 kbps
Remote-AP bw reservation 1 N/A
Remote-AP bw reservation 2 N/A
Remote-AP bw reservation 3 N/A
Heartbeat DSCP 0
Session ACL allowall
Corporate DNS Domain N/A
Maintenance Mode Disabled
WISPr Location-ID ISO Country Code N/A
WISPr Location-ID E.164 Country Code N/A
WISPr Location-ID E.164 Area Code N/A
WISPr Location-ID SSID/Zone N/A
WISPr Operator Name N/A
WISPr Location Name N/A
Remote-AP Local Network Access Disabled

Would you please answer the question i asked you in my previus post please?

Which question are you referring to?

These are all RAPs on a private network and I am pinging the outside interface.  The session ACL is set to allowall.

the  Session ACL under the AP system profile is set to allow all?

So you changed it from the default to test ?

This is what we've had it to set to.

You can see, while you are pinging that AP, what traffic is going through it by typing:

show datapath session ap-name <name of remote ap>

That will determine if it is even seeing that traffic.

Yes, the pings are reaching the AP.  I've also run this command on one of the APs that is pinging and the output is pretty much identical to the one that is not pinging.  As I've mentioned before, I have no problem pinging other devices on the same VLAN, so it can't be a routing issue.

PING NOT WORKING

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags 

-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- -----
10.186.6.90 10.11.1.3 1 55934 2048 0/0 0 0 1 dev4 21 FYCI
10.186.6.90 10.11.1.3 1 55928 2048 0/0 0 0 1 dev4 3a FYCI
10.186.6.90 10.11.1.3 1 55946 2048 0/0 0 0 0 dev4 1a FYCI
10.186.6.90 10.11.1.3 1 55940 2048 0/0 0 0 0 dev4 33 FYCI
10.186.6.90 10.11.1.3 1 55952 2048 0/0 0 0 0 dev4 2 FYCI
10.11.1.3 10.186.6.90 1 55946 0 0/0 0 0 0 dev4 1b FYI
10.11.1.3 10.186.6.90 1 55940 0 0/0 0 0 0 dev4 34 FYI
10.11.1.3 10.186.6.90 1 55952 0 0/0 0 0 0 dev4 2 FYI
10.11.1.3 10.186.6.90 1 55934 0 0/0 0 0 1 dev4 54 FYI
10.11.1.3 10.186.6.90 1 55928 0 0/0 0 0 1 dev4 6d FYI

C:\Users\jbyun>ping 10.11.1.3

Pinging 10.11.1.3 with 32 bytes of data&colon;
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.11.1.3:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

PING WORKING

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags 
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- -----
10.186.6.90 10.186.127.99 1 57352 2048 0/0 0 0 0 dev4 14 FYCI
10.186.6.90 10.186.127.99 1 57358 2048 0/0 0 0 0 dev4 5 FYCI
10.186.6.90 10.186.127.99 1 57356 2048 0/0 0 0 0 dev4 a FYCI
10.186.6.90 10.186.127.99 1 57350 2048 0/0 0 0 0 dev4 19 FYCI
10.186.6.90 10.186.127.99 1 57348 2048 0/0 0 0 0 dev4 1e FYCI
10.186.6.90 10.186.127.99 1 57360 2048 0/0 0 0 0 dev4 3 FYCI
10.186.127.99 10.186.6.90 1 57368 0 0/0 0 0 0 dev4 8 FYI
10.186.127.99 10.186.6.90 1 57370 0 0/0 0 0 0 dev4 3 FYI
10.186.127.99 10.186.6.90 1 57364 0 0/0 0 0 0 dev4 12 FYI
10.186.127.99 10.186.6.90 1 57366 0 0/0 0 0 0 dev4 d FYI
10.186.127.99 10.186.6.90 1 57360 0 0/0 0 0 0 dev4 1d FYI

C:\Users\jbyun>ping 10.186.127.99

Pinging 10.186.127.99 with 32 bytes of data&colon;
Reply from 10.186.127.99: bytes=32 time=46ms TTL=58
Reply from 10.186.127.99: bytes=32 time=47ms TTL=58
Reply from 10.186.127.99: bytes=32 time=47ms TTL=58
Reply from 10.186.127.99: bytes=32 time=46ms TTL=58

Ping statistics for 10.186.127.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 47ms, Average = 46ms

I would open a support case.  Depending on how your network is summarized, the access point "could" be responding through the tunnel interface to the controller as opposed to on the local lan.  Only support would be able to determine that.

I am not sure if deploying APs as RAPs is supported in the Campus, and the way they are designed they might not expect to be pinged across a layer3 subnet.  They expect to be at a remote site behind a firewall..

Campus APs can be pinged with no issue....

Collin you an correct me if im wrong and also i would like to know

As far i know the acl in the system AP profile the Session ACL is the one that control that kind of thing and its applied to the ports on the RAPS....

If the acl on the ap system profile says that it cannot ping then he would have not be able to ping... but as he has allowed all then he would have permition to ping.. right?

jbyun

On your computer

I would do a tracert -d 10.11.1.3

To see Where the last jump responding to the packet

Also i would do  a  tracert -d 10.186.127.99

To compare

Cheers

Carlos

These APs are at remote sites behind a firewall.  As I mentioned in my original post, I have no problem pinging the APs from the same subnet.  As you can see, the packets are reaching the AP and the AP is even responding, but getting dropped on the way back it appears.  The gateway is correct.

The APs are fully functional except for the fact that I cannot ping them.  I've compared the 20 working APs with the rest and there is no difference in any of the configurations.

I've tried those traces and the last hop shows as our firewall's external interface which is the last hop.  The next hop is the device itself.

C:\Users\jbyun>tracert -d 10.11.1.3

Tracing route to 10.11.1.3 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.186.6.1
...
9 58 ms 61 ms 56 ms 10.11.1.28
10 * * * Request timed out.
11 * ^C
C:\Users\jbyun>tracert -d 10.11.1.2

Tracing route to 10.11.1.2 over a maximum of 30 hops

1 <1 ms 1 ms <1 ms 10.186.6.1
...

9    62 ms    56 ms    61 ms  10.11.1.28

10 66 ms 56 ms 63 ms 10.11.1.2

Trace complete.

---

@NightShade1 wrote:

Collin you an correct me if im wrong and also i would like to know

As far i know the acl in the system AP profile the Session ACL is the one that control that kind of thing and its applied to the ports on the RAPS....

If the acl on the ap system profile says that it cannot ping then he would have not be able to ping... but as he has allowed all then he would have permition to ping.. right?

---

That is one aspect of it.  The other aspect of it is that the AP itself may be designed to route everything that is not going to the controller or the local subnet through the tunnel.  It is not meant to be managed locally VIA ip.  The session ACL also is to control gratuitous traffic to the bridged users on the AP.  Again, it is not meant to be managed externally otherwise.

Did you know that the AP you cannot do ping is reporting to the Backup LMS? instead of the primary?

Can you check that if the APs that you can ping are reporting to the LMS? instead the backup LMS

Or that AP should report to the controller 10.186.1.100 instead of the 10.186.1.101 ?

Is this is a master local deployment?  or what kind of deployment is this?

This is areally weird case as Collin advised you should open a support case.

We have a master-local deployment.  We opened a support case before and the issue was not resolved.  :smileyfrustrated:

I'm going to go to the remote location and do a packet capture sometime soon.

Did you see that if the ones you can ping terminate in one WC and the ones you cannto ping terminate in the other?

For example one you could not ping was terminating on the backup lms it hink

No, they are all the same which is why it makes even less sense.

It would be really nice if after the tac help you to resolve this you could post what was the issue becasue im really interested in the resoltuion... and what is causing this issue...

jbyun did you ever work this out?

Same here, did you manage to resolve this with the support ?

We can't ping the RAP, it makes them reboot.

since i asked last time i learned that APs just behave like this, once the tunnel is setup they dont reply to traffic from outside the local subnet, they send this back via the tunnel through the controller and often then you dont see it anymore.

as for the RAP rebooting when you ping it, that sounds a little odd, if you are 100% sure i would open a TAC case for that.

Hi

I faced similar issue. I suggested to ping tunnel IPs. My customer wrote a route to controller for tunnel ip subnet. So it worked. I mean now they can ping from monitoring server to tunnel ip through controller. Packets goes from tunnel and comes from same way. For this reason there is no asymmetric routing problem. Meanwhile we used vrrp ip address for route destination for redundancy. 

Regards

is this issue ever get resolved? could you post the result from TAC?

i am facing exact similiar issue.

Tac said this is Aruba behavior