A tunnel spec (that evaluates into a tunnel) is temporary unusable if that corresponding peer or the tunnel is denylisted. The following events trigger placement of the tunnel into the denylist:
Explicit termination of the L2TP session that is in the process of being established within this tunnel. The following CDN Result Codes places a tunnel to a denylist (text in parenthesis are CLI keywords that enable specific Result Codes as triggers and [rx,tx] is direction of the messages from the LAC perspective):
02 DisconnectedSeeErrorCode, rx (cdn-err-code)
04 TempMissingFacilities, rx (cdn-tmp-no-facilities)
Transmit CDN when no session can be allocated
Audit not yet complete
05 PermanentMissingFacilities, rx (cdn-perm-no-facilities)
No result code available
06 InvalidDestination, rx (cdn-inv-dest)
Tunnel is not usable (for example, lns-group is not configured on LNS)
10 NotEstablishedInAllotedTime, tx (tx-cdn-not-established-in-time)
Explicit termination of the L2TP tunnel in the process of establishment by Stop-CCN Result-Codes:
(1) General request to clear control connection, rx (stop-ccn-other)
(2) General error, rx (stop-ccn-err-code)
(4) Requester is not authorized to establish a control channel, rx, tx (stop-ccn-other)
(5) Protocol version not supported, rx, tx (stop-ccn-other)
(6) Requester is being shut down, rx (stop-ccn-other)
Error messages identified by the received Result-Codes can be interpreted as the inability of the LNS to accept additional L2TP sessions within the tunnel (for example because of resource depletion) or to accept additional new tunnels.
The following statements further describe behavior related to the placement of tunnels into the denylist:
A new L2TP session establishment attempt does not trigger on the tunnel that is in the denylist. Instead, another tunnel is searched according to the configured preference model.
The tunnel or session initialization failure always triggers the selection mechanism for another tunnel. However, it is possible to control through configuration whether to denylist or not the tunnel for which the L2TP initialization process failed because of specific Result Codes in CDN or Stop CCN messages.
After the L2TP tunnel or session is established, no events other than the timeout can force the tunnel (and the peer) into the denylist. In other words, a tunnel Stop or Call disconnect message for a stable tunnel or session does not force the tunnel into the denylist.
Existing sessions within the L2TP tunnel are not purposefully terminated if that the tunnel is forced into the denylist because of an explicit reply from LNS indicating the tunnel or session initialization failure. In other words, although the L2TP tunnel may be denylisted and therefore prevented from serving new L2TP sessions, the existing L2TP session over this tunnel is not affected.
A peer is not forced into the denylist if the explicit failure response from that peer. Only tunnels are denylisted in that case, if the configuration trigger is enabled. Peers are denylisted only based on timeouts and not explicit responses.
When the end-point is not in the routing table (unreachable through routing), the end-point is marked as permanently unavailable (removed from the L2TP process). Such end-point is never denylisted.