Reply
Occasional Contributor II

RAP disconnecting

Hi,

i have a lab install with RAPs. They are establishing a tunnel to the controller but 2-4 min. after that they just disconnect. I don't have a LMS-IP in the ap profile. I provision them using a public IP (NATted through by the corp firewall) The RAPs are provisioned using a RAP user (RAP 2WG, 800 controller, OS 5.0.2).

I can see the log entries below. In short they say (1) tunnel succeeded (main mode, quick mode) (2) Auth Ip down (???) (3) deleting tunnel. End of story.


Nov 2 11:50:03
isakmpd: <103063> |ike| Setup the incoming IPSEC SA --- DONE !!

Nov 2 11:50:03
isakmpd: <103063> |ike| ipc_ike_recv_packet: RAP increment session-count 1

Nov 2 11:50:03
isakmpd: <103063> |ike| ***** Adding to the DB Tunnel ESP ? SHA ******

Nov 2 11:50:28
fpapps: PAPI RxPacket: Timer already removed - could be a duplicate ACK

Nov 2 11:51:52
authmgr: <199802> |authmgr| ldapclient.c, ldap_client_bind_admin:666: LDAP Server demo-ldap-server: Could not connect to server

Nov 2 11:55:00
isakmpd: <103060> |ike| ipc.c:ipc_rcvcb:1053 Auth ip down message. ip=10.10.10.13

Nov 2 11:55:00
isakmpd: <103063> |ike| sa_release: RAP decrement sessions 1

Nov 2 11:55:00
isakmpd: <103063> |ike| ipsec_sa 0x102fac9c, proto 0x102f29f4

Nov 2 11:55:00
isakmpd: <103063> |ike| ipc_setup_ipsec_dp_sa add=0, out=1, sa=0x102f8aac, proto=0x102f29f4

Nov 2 11:55:00
isakmpd: <103063> |ike| ipc_setup_ipsec_dp_sa sa src=0xc0a86415, dst=0x54961693

Nov 2 11:55:00
isakmpd: <103060> |ike| ipc.c:ipc_print_dp_packet:2187 DP: :TUNNEL::SA_DEL::L2TP: OFF::outgoing::ESP::AES256::Auth = SHA1:, SPI 3CA7B300, esrc C0A86415, edst_ip 54961693, dst_ip A0A0A0D, natt 1, natt_dport 4500, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello 0

Nov 2 11:55:00
isakmpd: <103060> |ike| ipc.c:ipc_modify_sb_data:1653 IPSEC dst_ip=10.10.10.13, dst_mask 0.0.0.0 inner_ip 10.10.10.13 client:yestrusted:no, Master-Local:no

Nov 2 11:55:00
isakmpd: <103063> |ike| Setup the outgoing IPSEC SA --- DONE !!

Nov 2 11:55:00
isakmpd: <103063> |ike| ipc_setup_ipsec_dp_sa add=0, out=0, sa=0x*******, proto=0x102f29f4

Nov 2 11:55:00
isakmpd: <103063> |ike| ipc_setup_ipsec_dp_sa sa src=0x********, dst=0x********

Nov 2 11:55:00
isakmpd: <103060> |ike| ipc.c:ipc_print_dp_packet:2187 DP: :TUNNEL::SA_DEL::L2TP: OFF::incoming::ESP::AES256::Auth = SHA1:, SPI EC95B000, esrc 54961693, edst_ip C0A86415, dst_ip A0A0A0D, natt 1, natt_dport 4500, l2tp_tunid 0, l2tp_sessid 0, l2tp_hello 0

Nov 2 11:55:00
isakmpd: <103063> |ike| Setup the incoming IPSEC SA --- DONE !!

Nov 2 11:55:00
isakmpd: <103063> |ike| sa_release phase:2 calling client_auth_ip_down with ip=0x0a0a0a0d, extip=*********

Nov 2 11:55:00
isakmpd: <103063> |ike| freeL2TPIP freeing IP 10.10.10.13 from pool

Nov 2 11:55:00
isakmpd: <103056> |ike| IKE XAuth client down IP:10.10.10.13 External w.x.y.z

Nov 2 11:55:00
isakmpd: <103069> |ike| IKE received AP DOWN for 10.10.10.13 (External w.x.y.z)
Guru Elite

5.0.3

There is a current bug with remote access points rebootstrapping on 5.0.2.x The soon-coming 5.0.3.0 will fix this issue.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

obi
Contributor II

Re: RAP disconnecting

I have same problem. Any quick way around this, downgrade to 5.0.1.0? Tried 6.0 but problem persisted.
Occasional Contributor I

Similar issue with my A3600 Series

I have a problem which has been plaguing me for months. It seems each time the RAPS bootstrap they obtain a new IP address from the local IP Pool (which has 254 addresses) we have 55 RAPS. but the controller does not release the old IP address to the available pool. After a while (a week or so) all 254 Addresses are taken up and RAPS start to drop off. The only solution is to restart the controller or use SSH command line to drop the IP local pool and re-create.

Having sought advice from the Aruba techs they have changed the IPSEC retries to 6 but this is just prolonging the inevitable.

Also it has been suggested by the Aruba techs to widen the Pool range but again this is a prolonging of the inevitable.

The change in OS version 5.0.3.0 will this work for us? I am going to give it a go tomorrow to see.

This is really a pain for us as 40% of work is done remotely.

Appreciate any help or advice on top of what I am getting from Aruba themselves.

thanks
Guru Elite

Re: RAP disconnecting

Central to your problem is WHY the APs are bootstrapping. If TAC cannot tell you why, it will not hurt to upgrade to 5.0.3.0 You can also try by locating a possible degradation between your access points and your controller. May sure all your interfaces have negotiated properly and there are no errors on them.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor I

Re: RAP disconnecting

Thanks, I have been monitoring the network interfaces for a while. Sometimes the IP Packets from some RAPs do not even hit the external facing ethernet port. Looking at possible packet loss from our ISP and had it confirmed that from our ISP they are not experiencing packet loss. Our ISP is local government and they have a direct feed into the net so monitoring their internet facing firewall has showed the results explained.

They boostrap because the IPSEC tunnel drops after it misses 30 heartbeats. We raised this from 8 to see if it would help. We cannot be responsible for any packet loss by users ISP so we have raised the heartbeat threshold to account for this.

However, it is envitable that RAPS will bootstrap at some point so whether they do it twice a day or twice a month eventually the local IP pool will be fully used and restart of controller required. From TAC I am getting the impression that this is something I will have to live with, the only solution is to prolong the inevitable which isn't really a solution at all.
Guru Elite

Re: RAP disconnecting

There are two things that you can do outside of this forum:

- Have your case escalated by TAC, which you have every right to do. TAC, of course is limited by the visibility that you can give it into your infrastructure. They could ask you to do a wired packet capture at the source of the AP and a corresponding wired packet capture at the controller to ensure that every packet that is being sent is being received. That is the only surefire method of knowing what is and what is not being sent and received.

- You should schedule an upgrade window and consider upgrading to ArubaOS 5.0.3.0, because there is a legitimate bootstrapping bug that is addressed and it certainly could be causing your issue.

With regards to sending traffic over the internet, it is of course, best effort, but it is good enough to run voice and data over it for remote workers and a great deal of our customers, in addition to the entire Aruba remote workforce rely on it to get business done. If this were happening with 1 or two access points, I would look at the location of those access points. Since it is happening to all, at least do the upgrade to see if it corrects this.


Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: