Wireless Access

We send RAP to work-from-home users with instruction connect RAP directly to their home router and RAP tunnel secured traffic to controller. All work well but when the user's router DHCP release, RAP reboot, network down. Asking users to change DHCP lease time or reserve MAC address of RAP at home-router work, but not all users can help with this task.
Question: anyway to increase RAP - I assume it is VPN tunel “keep alive”- time?
I tried change these in RAP AP system profiles without success:
“Bootstrap-threshold” from default 8 to 1000
“number_ipsec_retries” from default 85 to 1000
AOS 6.5, RAP 155, 303.

Thanks,

hi Trinh,

DHCP protocol should attempt to renew 50% into the lease, meaning the lease generally should not expire if there is continuous connectivity between the RAP and the home router. Did the RAP reboot reason indicate it was due to DHCP lease expiry ?

It may be the case that the RAP is not renewing correctly, or, maybe the home router DHCP server has some bug - you may have to find a way to port mirror and capture the DHCP interaction between the RAP and the offending device to see what happens (e.g. watch the dhcp interaction, check there is a renewal attempt at 50% etc).

There is no way to increase the uptime with config knobs, RAPs ignore bootstrap-threshold; and the problem here is that the RAP is built to reboot if the lease fails or the IP changes, there is no protocol level workaround that is going to stop that AFAIK.

regards

-jeff

Jeff,
Thanks for responding.
To answer your question: No RAP did not report the reason why it is reboot but if I check the log I can see RAP is rebooting every hour consistently (see the log below). If I can check the user home router now, I bet you the DHCP lease time is 1 hour.

Surprisingly many home routers DHCP lease time is 1 hour by default. This behavior confirms in two routers that I have tested: Zyxel that provides by CenturyLink and Arris that provides by Cox.

Thu Jul 11 08:16:51 2019
System Tunnel IP changed from x.x.x.x to x.x.x.x. 
Thu Jul 11 08:05:47 2019
System Status changed to 'OK' 
Thu Jul 11 08:05:47 2019
System Up 
Thu Jul 11 08:05:46 2019
System Down 
Thu Jul 11 08:05:46 2019
System
Device has rebooted: Device uptime value changed (current: 2 mins 49 secs, calculated: 1 hr 11 mins 56 secs) and Change in number of reboots detected (got 2028, expected 2027) 
Thu Jul 11 08:00:34 2019
System Status changed to 'Poll missed 1 SNMP pings' 
Thu Jul 11 07:00:41 2019
System Tunnel IP changed from x.x.x.x to x.x.x.x. 
Thu Jul 11 06:57:54 2019
System Status changed to 'OK' 
Thu Jul 11 06:57:54 2019
System Up 
Thu Jul 11 06:57:53 2019
System Down 
Thu Jul 11 06:57:53 2019
System
Device has rebooted: Device uptime value changed (current: 4 mins 3 secs, calculated: 1 hr 13 mins 10 secs) and Change in number of reboots detected (got 2027, expected 2026) 

hi Trinh

even with 1 hour lease, the renewal should come at 30 mins to avoid this happening. can you check "show ap debug system-status ap-name <the ap>" , that should report back the APs reason for its reboot

regards

-jeff

Jeff,

This is the debug info of the RAP:

Reboot Information
------------------
AP rebooted Tue Jul 16 13:33:15 CDT 2019; Unable to get IP address using DHCP af ter 10 tries, total DHCP retry:10
-------------------------------------------------------------------------------- ---------------------------------

Thanks for your help.

I set up a lab DHCP server with 20 minutes’ clients lease duration. I also run Wireshark at this server with capture filter on client IP address 10.11.11.2. We can see client does DHCPREQ and received DHCPACK every 50% of lease time duration which is every 10 minutes or 600 seconds.

DHCP capture
So the problem is NOT with the DHCP server at user home router. RAP renews at ½ DHCP duration, but still reboots every 20 minutes that correlates with DHCP duration.
We know that RAP is the VPN tunnel that requires two IP addresses, the interface IP address (interface br0) configures at user home router, and the tunnel IP address (tun0) configures at controller l2tp local IPSEC pool. I observe that every time RAP reboots, the interface br0 IP address does NOT change but the interface tun0 IP address changes.

(LAB) #show ap debug log ap-name TN-Test | include reboot
Sep  8 14:45:15 nanny[1855]: <303022> <WARN> |AP TN-Test@172.31.50.155 nanny|  ^[reason AP rebooted Sun Sep 8 14:41:29 CDT 2019; Unable to get IP address using DHCP after 10 tries, total DHCP retry:10 ]

(LAB) #show ap debug system-status ap-name TN-Test

Output omit ...
…
ifconfig output for br0
-----------------------
br0       Link encap:Ethernet  HWaddr 
---------------------------------------------------------
          inet addr:10.11.11.2  Bcast:10.11.11.255  Mask:255.255.255.0
          inet6 addr: fe80::224c:3ff:fe0f:2ec/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:3165 errors:0 dropped:13 overruns:0 frame:0
          TX packets:793 errors:0 dropped:49 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

          Rx broadcast packet:2         Rx broadcast packet per second:0
          Rx multicast packet:2155      Rx multicast packet per second:9
          Tx broadcast packet:2         Tx broadcast packet per second:0
          Tx multicast packet:47        Tx multicast packet per second:0

ifconfig output for tun0
------------------------
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00                                                                                                             -00
--------------------------------------------------------------------------------                                                                                                             -----
          inet addr:172.31.50.155  P-t-P:172.31.50.155  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1300  Metric:1
          RX packets:2130 errors:0 dropped:0 overruns:0 frame:0
          TX packets:726 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:64
          RX bytes:280476 (273.9 KiB)  TX bytes:142961 (139.6 KiB)

I'll open TAC case and update with any resolution. 

The problem resolve when move RAPs termination to 8.4.0.4 of 7220 cluster.  

Sorry, duplicate post