Peer Resynchronization After an L2TP Failover
L2TP Failover and Peer Resynchronization
L2TP failover enables a failed L2TP endpoint to resynchronize with its nonfailed peer during recovery and restart of the L2TP protocol on the failed endpoint. L2TP failover is enabled by default.
The failover and L2TP peer resynchronization process does all of the following:
Prevents the nonfailed endpoint from prematurely terminating a tunnel while the failed endpoint is recovering.
Reestablishes the sequence numbers required for the operation of the L2TP control protocol.
Resolves inconsistencies in the tunnel and session databases of the failed endpoint and the nonfailed endpoint.
The router supports both the L2TP failover protocol method (described in RFC 4951, Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover") and the L2TP silent failover method. The differences between these two methods are as follows:
The L2TP failover protocol method requires a nonfailed endpoint to wait an additional recovery time period while the failed endpoint is recovering to prevent the nonfailed endpoint from prematurely disconnecting the tunnel. The additional recovery period delays the detection of tunnel keepalive failures.
If a peer on an MX series router negotiates failover protocol with an MX Series peer that is not configured for failover protocol, both use the silent failover method. If the negotiation is with a third-party device that does not support failover protocol, the MX Series peer falls back to silent failover; whether the third-party peer recovers in this case depends on how resynchronization is implemented on that device.
Silent failover operates entirely within the failed endpoint and does not require nonfailed endpoint support—this improves interoperability between peers. Silent failover does not require additional recovery time by the nonfailed endpoint, which also eliminates the potential for degraded responsiveness to the loss of tunnel connectivity. Starting in Junos OS Release 15.1R6, 16.1R5, 16.2R2, 17.1R2, and 17.2R1, silent failover is the default resynchronization method in Junos OS.
In lower-numbered releases, the default resynchronization method is failover-protocol-fall-back-to-silent-failover. The recovery method used depends on the results of the failover capability negotiation that takes place between L2TP peers when they establish a tunnel, which works as follows:
L2TP on the LAC by default attempts to negotiate the L2TP failover protocol first. When L2TP determines that the remote peer supports the L2TP failover protocol, then the L2TP failover protocol method is used.
When L2TP determines that the remote peer does not support the L2TP failover protocol, then the L2TP silent failover method is used. Falling back on this secondary method prevents the failover from forcing a disconnection of the tunnel to the peer and all its sessions.
In Junos OS releases where failover-protocol-fall-back-to-silent-failover
is the default method, you can change the default behavior by including
the disable-failover-protocol statement at the [edit services l2tp] hierarchy
level. This statement forces the configured LAC or LNS endpoint to
operate only in silent failover mode. This configuration can be used
to prevent the device from negotiating failover protocol with the
peer even if the peer tries to negotiate it. When you issue this statement
and the peer supports only failover protocol, the nonfailed endpoint
(LAC or LNS) uses silent failover for recovery. Starting in Junos OS Release 15.1R6, 16.1R5, 16.2R2,
17.1R2, and 17.2R1, the disable-failover-protocol statement
is deprecated, because the change in default resynchronization method
makes it unnecessary.
Configuring the L2TP Peer Resynchronization Method
The L2TP implementation on MX Series routers supports resynchronization between a failed L2TP endpoint and its peer nonfailed endpoint. Peer resynchronization enables L2TP to recover from a daemon or router restart or a Routing Engine switchover.
L2TP peer resynchronization:
Prevents the nonfailed endpoint from prematurely terminating a tunnel while the failed endpoint is recovering.
Reestablishes the sequence numbers required for the operation of the L2TP control protocol.
Resolves inconsistencies in the tunnel and session databases of the failed endpoint and the nonfailed endpoint.
You can configure the peer resynchronization method you want the router to use. Both the L2TP failover protocol method and the L2TP silent failover method are supported.
In Junos OS Releases through 15.1R5, 16.1R4, 16.2R1, and 17.1R1, the default behavior is for L2TP on the LAC to attempt to negotiate the L2TP failover protocol with the LNS. When the LNS supports this method and negotiation is successful, the L2TP failover protocol is used when either peer fails. When negotiation for L2TP failover protocol fails, then the peers use silent failover when either peer fails. This behavior is called failover-protocol-fall-back-to-silent-failover. Falling back to the silent failover method when failover protocol negotiation is unsuccessful prevents a subsequent peer failure from forcing a disconnection of the tunnel to the peer and all the associated sessions.
The behavior just described applies when both peers are MX Series routers. If one endpoint is a third-party device, then the behavior for that device depends on its L2TP implementation.
You can disable the default behavior and force the LAC or the LNS to operate only in silent failover mode. This configuration can be useful when the peer routers either are configured for silent failover or incorrectly negotiate to use the failover protocol even though they do not support it. Another reason to use this statement is that the failover protocol method keeps the tunnel open with the failed peer, in case the failed peer is able to recover from the failure and resynchronize with the nonfailed peer. This behavior keeps the tunnel up and the subscribers logged in while traffic is not flowing, preventing service level agreements from being met. When you issue this statement and the peer supports only failover protocol, the nonfailed endpoint (LAC or LNS) uses silent failover for recovery.
To disable negotiation of the L2TP failover protocol:
Configure disabling.
[edit services l2tp] user@host# set disable-failover-protocol
Starting in Junos OS
Releases 15.1R6, 16.1R5, 16.2R2, 17.1R2, and 17.2R1, the default failover
resynchronization method is changed to silent failover. Consequently,
the disable-failover-protocol statement no longer needs
to be used and is deprecated. If you upgrade
from a lower-numbered release where the default method is failover-protocol-fall-back-to-silent-failover,
and your configuration includes the disable-failover-protocol statement, the configuration is still supported, but the CLI notifies
you that the statement is deprecated.
In these releases, you can still configure which method you want an endpoint to use, failover protocol or silent failover.
To configure the LAC or LNS to negotiate the L2TP failover protocol:
Specify the failover protocol.
[edit services l2tp tunnel] user@host# set failover-resync failover-protocol
If the negotiation fails, the endpoint falls back to the silent failover method.
To restore the default resynchronization method for the LAC or LNS:
Specify the silent failover method.
[edit services l2tp tunnel] user@host# set failover-resync silent-failover
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
disable-failover-protocol statement
is deprecated, because the change in default resynchronization method
makes it unnecessary.disable-failover-protocol statement no longer needs
to be used and is deprecated.