Every few months I get stumped why a RAP cannot register on the network. I'll struggle with it for a few days and then suddenly realize that maybe my VPN Address Pool is an issue. Today I had that same thing happen and found that our pool seemed to be too small. We have it defined as 22.214.171.124 through 126.96.36.199 (started at 100 and outgrew that). I upped it to 188.8.131.52 to give myself breathing room while I figure out the answer to these two questions:
1. Why do these addresses never get reused? I only have 73 APs of which 39 are RAPs, so why have I burned through 200 VPN addresses? We do pull back RAPs and re-deploy them with a new name and on a new network connection from time to time, but I don't think we've done it 200 times, though I could be wrong. Even still, once 184.108.40.206 is no longer in use, shouldn't it become available again?
2. Can I extend this Address Pool past a Class C? Could I just set it from 220.127.116.11 to 18.104.22.168 or something crazy huge so I don't have to worry about this again? What would be the drawbacks of doing this?
I appreciate any input you guys can provide.
Hi Ryan,From your description, it sounds client keeps the address in use even though the client has got disconnected.Basically it should release the address which is the concern for us. Please let me know what is the code version running on the controller.
Whenever a system disconnects from an L2TP VPN Pool, the IP will be aged out based upon 6 * the l2tp hello timer.The hello timer is 60 seconds by default; so 6 minutes should be the ageout here.
Find below output from my lab controller
(Aruba) #show vpdn l2tp configuration
EnabledHello timeout: 60 secondsDNS primary server: 22.214.171.124DNS secondary server: 126.96.36.199WINS primary server: 0.0.0.0WINS secondary server: 0.0.0.0PPP client authentication methods:PAPIP LOCAL POOLS:test: 188.8.131.52 - 184.108.40.206However this timer is still configurable on the controller.
config terminalvpdn group l2tpl2tp tunnel hello <timer>
To understand how many addresses are in user in your VPN pool either by clients or remote AP`s.Please use the below command.In the below case it is just none, if there are VPN user present on the controller this should give the list.(Aruba) #show vpdn l2tp local pool
IP addresses used in pool testnone
Total:-0 IPs used - 50 IPs free - 50 IPs configuredIP pool allocations / de-allocations - L2TP: 0/0 IKE: 0/0
For now, you could bump up the Address pool to avoid any network disruption and enable below debugging to capture more info.
(Aruba) (config) #logging level debugging security(Aruba) (config) #logging level debugging security process l2tp
Note:- It is recommended to disable the debugging once we collected the debug info and logs.tar from controller.
If this issue is time sensitive, please open up TAC case to validate along with the above debugging to understand root cause.
As we discussed, here is the procedure to download the logs from the controller.
Navigate to Maintenance > File / Copy Logs.
You can directly download logs from the controller by checking the "Download Logs" radio button and clicking Apply.
If you want to include the tech-support log in the downloaded file for troubleshooting purposes, check the "Include technical support information" box before downloading.
To save a snapshot of the logs into flash:
tar logs tech-support
To copy the file to another device:
copy flash: logs.tar ftp: <server IP> <user> <password> <remote filename>
copy flash: logs.tar tftp: <server IP> <remote filename>
copy flash: logs.tar scp: <server IP> <user> <remote filename>
Password:***** <-------- enter your password
Are you sure you want to continue(y/n): y <--------- press 'y'
I ran debug logs for 20 minutes tonight and sent you the results via the ticket along with the output from the other commands. The results are very similar to what you showed, including having over 150 available addresses. I widened the pool by 50 to buy ourselves a litle time until we figure out why they are not getting reused.
Thanks much for uploading logs.tar with tech-support information. From logs, I could notice l2tpd process is getting crashed.
Jul 11 22:13:58 <nanny 303073> <ERRS> |nanny| Process /mswitch/bin/l2tpd [pid 1624] died: got signal SIGABRTJul 11 22:14:04 <nanny 303029> <ERRS> |nanny| Process /mswitch/bin/l2tpd [pid 1624]: crash data saved in dir /flash/crash/process/7-11-2013@22-13-58/l2tpdJul 11 22:14:04 <nanny 303025> <ERRS> |nanny| Found core file /tmp/core.1624.l2tpd.A6xxx_32786, 5242880 bytes, compressing...Jul 11 22:14:20 <nanny 303079> <ERRS> |nanny| Restarted process /mswitch/bin/l2tpd, new pid 25763Jul 11 22:14:20 <nanny 303080> <ERRS> |nanny| Please tar and email the file crash.tar to email@example.comJul 11 22:14:20 <nanny 303081> <ERRS> |nanny| To tar type the following commands at the Command Line Interface: (1) tar crash (2) copy flash: crash.tar tftp: [serverip] [destn filename]Jul 11 22:26:16 <authmgr 132149> <ERRS> |authmgr| Station 4c:b1:99:40:a1:db d8:c7:c8:1c:d2:b8 lookup failedJul 11 22:27:07 <rtpa 339302> <ERRS> |rtpa| papi_handler, papi_handler: Length mismatch expected 0 received 844Large files under /tmp======================Large files under /tmp
Could you please upload the crash.tar either to support ticket or attach it on the forums to analyze further.
To extract the crash:-
Go to Maintenance tab --> click on copy crash files --> Choose TFTP server (ip address and file name to push it to server)
Aruba#copy : flash : crash.tar: tftp <ip address of the server> <file name of the server>
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.