Capturing L2TP Sessions

Lately, we're been seeing more and more instances of create session timeouts with the cause code 100 - "remote peer not responding".

With constant tunnel failure, it's likely to be due to unreliable transport. Either lost packets or the LAC/LNS getting the sequence numbers wrong, requiring a tunnel re-establishment. Best way to check is to get a trace and verify that the correct Nr/Ns sequence numbers are being used.

When capturing packets from an L2TP interface, you're getting both control messages and payload packets (both port 1701). Bulk of the traffic would be the latter, which does not really help with troubleshooting. To capture only the control messages, use this filter:

udp[8]>>7=1, where highest bit in the first byte of the UDP payload is the control flag

Obviously, if talking to multiple LNS, use the appropriate host IP as extra qualifier.

Good if your requests come in one at a time, and answered in sequence, like so:

More often than not, they come in bursts, and the LNS responds to some but not all. And some responses are delayed, which makes session tracking a challenge.

Best way to handle this is to look at the Assigned Session ID and Session ID in ICRQ, ICRP, and ICCN messages.

1. ICRQ will have Session ID = 0 and an Assigned Session ID chosen by the LAC.
2. When the LNS responds with an ICRP, it copies the original Session ID into the Assigned Session ID, and assigns its own Session ID.
3. Then, in the ICCN, the LAC copies the Assigned Session ID from the preceding ICRQ into the Session ID field.
4. And the final ZLB from the LNS increments the Nr accordingly.