CAP3502I not responding for traceroute_tracert

[Martin Jelinek]

Hello all techs

I would like to kindly ask if anyone has any experience with same behavior as I have.

Problem description:

- I have 1 cisco AP (CAP3502I) which is not able to associate with WLC (version 7.0.235.0), using CAPWAP. Simply from debug I can see that AP is trying to contact WLC on port udp/5246 but can't see any response from WLC.

*Oct 19 07:06:50.055: UDP: sent src=x.x.x.x(4271), dst=wlc.wlc.wlc.wcl(5246), length=47

AP is getting config about WLC from DHCP option 43 and have own reservation to get same IP address (+default GW). AP is NOT associated but as it has IP address from DHCP then it is pingable. But don't know why, but I'm not able to tracert/traceroute to this AP, as I can see it is getting packets but it is not responding.

But on different locations, where are same APs model (associated with WLC) I have no problem with traceroute it, as APs are responding.

My question:

It is not related that AP is not able to associate with WLC (still working on it, driving me crazy but working on it ^_^) BUT should I be able to traceroute/tracert to unassociated AP (to his IP) and get response???

NOTE:

==> WLC is in DC and AP on one location, so diagram could be: WLC ---- L3 device ---- Provider MPLS router..........Provider MPLS router ---- L3 device -- L2 switch --- AP (CAPWAP)

@it means that there is NO FW on tha way

I check many other APs with same model and non of them has problem to respond for traceroute, but this particular unassociated one has :-/.

Does anyone has any idea why or at least same experience to know that I'm not alone ?

Thanks in advance for any idea

[Saravanan Lakshmanan]

It is not related that AP is not able to associate with WLC (still working on it, driving me crazy but working on it ^_^) BUT should I be able to traceroute/tracert to unassociated AP (to his IP) and get response???

Yes. check any other device having similar IP or try static ip or Move AP to different vlan.

Are other AP from same VLAN works as expected.

Do traceroute from AP.

does wlc got discovery request for that AP.

what's the AP join status on WLC for this AP.

what's rtt btw AP & WLC.

[Martin Jelinek]

Hello Saravanan,

Thanks for your response.

As I suspected, connection should be working, but actually it is not.

Unfortunetally there is no other AP in that particular VLAN neither location. We have tested AP on other location where it worked correctly, but AP needs to be use on that location where it is not working.

Are other AP from same VLAN works as expected.

     - there are no other APs

Do traceroute from AP.

     - traceroute FROM access point TO WLC is working fine.

does wlc got discovery request for that AP.

     - on WLC can be seen only that DTLS failed as below log line:

          "

*spamApTask3: Oct 22 11:38:38.991: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:631 Failed to complete DTLS handshake with peer x.x.x.x

"

     - there are no other logs messages related to this AP ip address (AP obtains IP address from DHCP reservation)

what's the AP join status on WLC for this AP.

     - Can you tell me where I can see any join status? As I believe that if DTLS is not established then joining is not in place.

what's rtt btw AP & WLC.

     - average delay is around 30ms so pretty fine :-)

When we have tested connectivity, we were able to see that connection is working through backup line (WAN), but not working through primary line, problem is of course to force provider to check what is wrong on primary line.

But when I saw that AP is not responding for tracert I got confused if it responding only in case when AP is associated...

As AP is using capwap then ports udp/5246 and 5247 are used, and these are not blocked on our side for sure.

I got confused because AP is not responding for traceroute from it's default gateway (which I have even statically configred on AP itself).

Thank you

[Martin Jelinek]

Issue has been solved.

Solution:

- we have find out that CAPWAP traffic (UDP/5246,5247) has been wrongly clasified by QoS policy on WAN routers. Simply traffic has been dropped as it violate policies.