Wireless Access

Hi all,

when CPsec is enabled, all mgmt traffic goes through an IPsec tunnel to the controller. It means that if I try to ping my APs from a different VLAN, I'm going to have an asymmetric routing, as follows:

Ping Request
 
PC(subnet B) ---ping req---> AP(subnet A) ===>Does not go through Controller

Ping Reply
 
AP(subnet A) ---ping reply---> tun0(default route) ---ESP(ipsec)---> Controller ---ping reply---> PC(subnet B)

 

It means that having Controllers in DMZ, traffic will go through firewalls and ping will be dropped, due to asymmetric routing.

This is really annoying, since I can't monitor my APs with my own network monitoring system (that is obviously in the LAN).

How can I solve this issue, without disabling CPsec?

Are you sure that your ping is going the way you describe?

AFAIK the IPSec tunnel for management between controller and AP only routes the two ip addresses( controller and AP) over the IPSec. Not complete subnets.

Is your controller the gateway in the subnets?

Hi,

such ping way has been decribed by the Aruba Tech support (so I hope it is ok).

The controller is on L2, the gateway is made the firewall

cpsec and raps will hijack the default route, it's just the way it is. We can see it happening below.

 

First, the route table of the AP, from its shell, shows a host route for the controller (.120) and also a default route pointing to the same tun0 device.

 

~ # netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.1.120   0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
192.168.11.0    0.0.0.0         255.255.255.0   U         0 0          0 br0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 br0
~ # 

Now start a ping to some IP that will use the default route

~ # ping 1.1.1.1 -t
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=53 time=4.2 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=4.5 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=5.4 ms
...

and now on the controller .120, check the datapath for 1.1.1.1

(controller) #show datapath session | include 1.1.1.1
1.1.1.1         192.168.1.21    1    2     0      0/0     0    0   1   tunnel 11   3    0          0          FYI             
192.168.1.21    1.1.1.1         1    2     2048   0/0     0    0   0   tunnel 11   3    1          84         FCI             
1.1.1.1         192.168.1.21    1    3     0      0/0     0    0   0   tunnel 11   2    0          0          FYI             
192.168.1.21    1.1.1.1         1    3     2048   0/0     0    0   0   tunnel 11   2    1          84         FCI             

and it's present with tunnel 11 as being the destination, which as we suspect is the IPSec tunnel to this AP

(controller) #show datapath tunnel | include "11  "
11      SPI5EB01300 in  192.168.1.120   50   IPSE  1500  0    routeDest 0000     0                              596          0                              0           0
(controller) #

so... options.... if you cannot be L2 local with the AP, then if you're prepared to accept using the tunnel to reach the APs, you can route the ping traffic to the controller first. It will then be placed into the tunnel (as th controller always will reach the AP via the tunnel for cpsec, then AP will reply back up the tunnel.

 

(controller) #show datapath route-cache 
       IP              MAC             VLAN       Flags
---------------  -----------------  -----------  ------
192.168.1.21     AC:A3:1E:C5:1E:F4  tunnel    9  PItA   <<<

you can see that it will work by running a ping and then checking the two parts of the tunnel, in my case it's id 9 and 11

 

Asymetric, can see the count of Decaps going up but not Encaps

(controller) #show datapath tunnel | include "11    ,9    ,Enc,---"
 #          Source       Destination    Prt  Type  MTU   VLAN       Acls                    BSSID          Decaps     Encaps   Heartbeats Flags  EncapKBytes  DecapKBytes
------  --------------  --------------  ---  ----  ----  ---- -----------------------  ----------------- ---------- ---------- ---------- ----- ------------- -----------
11      SPI5EB01300 in  192.168.1.120   50   IPSE  1500  0    routeDest 0000     0                               30          0                              0           0
9       SPIED19F500out  192.168.1.21    50   IPSE  1500  0    routeDest 0001     0                                0          0                              0           0

(controller) #show datapath tunnel | include "11    ,9    ,Enc,---"
 #          Source       Destination    Prt  Type  MTU   VLAN       Acls                    BSSID          Decaps     Encaps   Heartbeats Flags  EncapKBytes  DecapKBytes
------  --------------  --------------  ---  ----  ----  ---- -----------------------  ----------------- ---------- ---------- ---------- ----- ------------- -----------
11      SPI5EB01300 in  192.168.1.120   50   IPSE  1500  0    routeDest 0000     0                               36          0                              0           0
9       SPIED19F500out  192.168.1.21    50   IPSE  1500  0    routeDest 0001     0                                0          0                              0           0

(controller) #

Now, on the ping machine, set a route to 192.168.1.21 via the controller, and now the encap and decap are going up (there's some extra stuff being sent up the tunnel by the AP so it's not a perfect 1:1 count)

(controller) #show datapath tunnel | include "11    ,9    ,Enc,---"
 #          Source       Destination    Prt  Type  MTU   VLAN       Acls                    BSSID          Decaps     Encaps   Heartbeats Flags  EncapKBytes  DecapKBytes
------  --------------  --------------  ---  ----  ----  ---- -----------------------  ----------------- ---------- ---------- ---------- ----- ------------- -----------
11      SPI5EB01300 in  192.168.1.120   50   IPSE  1500  0    routeDest 0000     0                               18          0                              0           0
9       SPIED19F500out  192.168.1.21    50   IPSE  1500  0    routeDest 0001     0                                0          8                              0           0

(controller) #show datapath tunnel | include "11    ,9    ,Enc,---"
 #          Source       Destination    Prt  Type  MTU   VLAN       Acls                    BSSID          Decaps     Encaps   Heartbeats Flags  EncapKBytes  DecapKBytes
------  --------------  --------------  ---  ----  ----  ---- -----------------------  ----------------- ---------- ---------- ---------- ----- ------------- -----------
11      SPI5EB01300 in  192.168.1.120   50   IPSE  1500  0    routeDest 0000     0                               21          0                              0           0
9       SPIED19F500out  192.168.1.21    50   IPSE  1500  0    routeDest 0001     0                                0         11                              0           0

hopefully that formats ok in this horible little window.

 

tl;dr; have your ping station route to your AP subnet via the controller itself (ditto for inner IP pools if this were RAP)

 

p.s. take a look at the "ap ip health-check" feature.

 

hth.

 

 

 

 

 

 

Most customers will monitor the AP status from the controller, with Airwave that is really easy, but you can query the controller via SNMP as well.

 

It is not so usual to monitor the individual APs with ping, as in most deployments the APs will use a dynamic IP via DHCP and the AP IP is not really relevant nor practical in that case. All relevant information (and more) is available from the controller and Airwave.

---

@Herman Robers wrote:

Most customers will monitor the AP status from the controller, with Airwave that is really easy, but you can query the controller via SNMP as well.

 

It is not so usual to monitor the individual APs with ping, as in most deployments the APs will use a dynamic IP via DHCP and the AP IP is not really relevant nor practical in that case. All relevant information (and more) is available from the controller and Airwave.

---

agreed, mostly :)

 

DHCP in a stable network, esp. with long leases is unlikely to churn IPs much. But, it would be nicer if the controller exposed the ip health check results in a MIB or other, but for now a simple AP up and Down is all we get, which doesnt give any appreciation for loss or latency (not that we should have to worry about that in a campus (as opposed to RAP), but, it does happen from time to time, duplex mismatch, cables, connectors, bad qos etc).

 

The answer is probably more practical for people who may stumble upon this for trying to ping RAP inner IPs, which does provide some useful info about the state of the WAN (if involved), especially when bolted to something like smokeping.

 

A compromise might be to scrape the health check results out of the CLI and merge it with show ap debug counters and use that to create alerts, but that's beyond the scope of this post.

 

$0.02...