Subject: RE: l2tp questions

From: "Verma, Rohit (US - Chicago)" <[email-masked]>
Date: Mon, 10 Apr 2000 23:27:56 -0500

Aha classic case of defensive programming. Technically you should not
cleanup the session until you receive an ack for your CDN.  Also, you should
keep the session active for atleast 3 times the RTT between the LAC and the
LNS. A good idea is to mark the session table entry as "READY_TO_DELETE". If
you do not recevie anything till 3 RTT do a cleanup.
If you receive a CDN from the remote side then cleanup any ways. In fact the
condition u described below can very easily lead to random disconnects.
Think about a case where you reallocated the session table entry for another
incoming call, there is a chance that your CDN from the previous call may
disrupt this. A good implementation should recycle table entries in a ring
buffer order also, make sure the tunnel and sequence number validity before
processing a CDN or any other control message.

Hope this helps.

Regards

Rohit Verma
Consultant
Deloitte Consulting
180, N. Stetson Avenue
Chicago, IL 60601
312-374-2475

-----Original Message-----
From: Ly Loi [mailto:[email-masked]]
Sent: Monday, April 10, 2000 8:35 PM
To: 'Rohit Verma'
Cc: Ly Loi
Subject: l2tp questions

Hi Rohit, how are you? I've got the following l2tp question and wonder
whether there's a solution to it.

1. LAC and LNS at the same time bring down the L2TP session
2. Both LAC and LNS send to each other a CDN.
3. LAC deletes its L2TP session, THEN receives the CDN generated by the LNS.
Since the LAC has freed its L2TP session, it doesn't recognize the L2TP
session id in the CDN, thus drops the pkt.
4. LNS retransmits the CDN n times.
5. Each time, the LAC drops the CDN.
6. LNS eventually times out and brings down the tunnel.

What can I do to avoid having the LNS bring down the tunnel? The LAC didn't
ack the CDN because it has already gotten rid of the L2TP session data
structures.
Even if I have the LAC send a keep alive to the LNS, the LNS will continue
retransmitting the CDN since it is at the head of its transmit Q. What to
do?

Thanks much,

- Ly

---

From: Evan Caves <[email-masked]>
Date: Tue, 11 Apr 2000 09:37:15 -0700

Since the LAC received the CDN it should update its Nr. What the LAC
does after this
(in most cases) does not affect Nr. The LAC should then send back a zlb
ack with new
Nr or piggy back Nr in the next message.

evan
-

"Verma, Rohit (US - Chicago)" wrote:

> cleanup the session until you receive an ack for your CDN.  Also, you
> should keep the session active for atleast 3 times the RTT between the
> LAC and the LNS. A good idea is to mark the session table entry as
> "READY_TO_DELETE". If you do not recevie anything till 3 RTT do a
> cleanup.
>
> If you receive a CDN from the remote side then cleanup any ways. In
> fact the condition u described below can very easily lead to random
> disconnects. Think about a case where you reallocated the session
> table entry for another incoming call, there is a chance that your CDN
> from the previous call may disrupt this. A good implementation should
> recycle table entries in a ring buffer order also, make sure the
> tunnel and sequence number validity before processing a CDN or any
> other control message.
>
> Hope this helps.
>
> Regards
>
> Rohit Verma
> Consultant
> Deloitte Consulting
> 180, N. Stetson Avenue
> Chicago, IL 60601
> 312-374-2475
>