Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

Configuring the Number of L2TP Control Message Retransmissions

L2TP peers maintain a queue of control messages that must be sent to the peer device. After a message is sent, the local peer waits for a response from the remote peer. If a response is not received, the local peer retransmits the message. You can configure how many times an unacknowledged message is retransmitted by the LAC or the LNS. For tunnels that have been established, include the retransmission-count-established statement at the [edit services l2tp tunnel] hierarchy level. For tunnels that are not yet established, include the retransmission-count-not-established statement.

The local peer waits one second for the first response to a control message. The retransmit timer then doubles the interval between each successive retransmission, up to a maximum interval of 16 seconds. This behavior allows the remote peer more time to respond. If the maximum retransmission count is reached and no response has been received, the tunnel and all its sessions are cleared.

Best Practice: Before you downgrade to a Junos OS release that does not support these statements, we recommend that you explicitly unconfigure the feature by including the no retransmission-count-established statement and the no retransmission-count-non-established statement at the [edit services l2tp tunnel] hierarchy level.

Best Practice: During a unified in-service software upgrade (unified ISSU) on an MX Series router configured as the LAC, the LAC does not respond to control messages from the LNS. This can result in dropping LAC L2TP sessions. You can avoid this situation by ensuring that the maximum retransmission count on the LNS is set to 16 or higher.

To set the maximum retransmission count for established tunnels:

To set the maximum retransmission count for non-established tunnels:

Published: 2012-11-29