Wireless Access

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 1.1.1.1 through 1.1.1.200 (started at 100 and outgrew that).  I upped it to 1.1.1.254 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 1.1.1.107 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 1.1.1.1 to 1.1.254.254 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

Enabled
Hello timeout: 60 seconds
DNS primary server: 8.8.8.8
DNS secondary server: 4.2.2.2
WINS primary server: 0.0.0.0
WINS secondary server: 0.0.0.0
PPP client authentication methods:
PAP
IP LOCAL POOLS:
test: 1.1.1.1 - 1.1.1.50

However this timer is still configurable on the controller.

config terminal
vpdn group l2tp
l2tp 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 test
none

Total:-
0 IPs used - 50 IPs free - 50 IPs configured
IP 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.

Regards

Sriram

Hi Ryan,

As we discussed, here is the procedure to download the logs from the controller.

From Webui:-

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.

CLI

To save a snapshot of the logs into flash:

tar logs tech-support

To copy the file to another device:

[FTP]

copy flash: logs.tar ftp: <server IP> <user> <password> <remote filename>

[TFTP]

copy flash: logs.tar tftp: <server IP> <remote filename>

[SCP]

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'

Thank you,

Sriram

Sriram,

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.

Find below.

Jul 11 22:13:58 <nanny 303073> <ERRS> |nanny| Process /mswitch/bin/l2tpd [pid 1624] died: got signal SIGABRT
Jul 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/l2tpd
Jul 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 25763
Jul 11 22:14:20 <nanny 303080> <ERRS> |nanny| Please tar and email the file crash.tar to support@arubanetworks.com
Jul 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 failed
Jul 11 22:27:07 <rtpa 339302> <ERRS> |rtpa| papi_handler, papi_handler: Length mismatch expected 0 received 844
Large 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:-

WEBUI

Go to Maintenance tab --> click on copy crash files --> Choose TFTP server (ip address and file name to push it to server)

CLI

Aruba#copy : flash : crash.tar: tftp <ip address of the server>  <file name of the server>

Thank you,

Sriram