Validation Of Lcp Peer Magic Number - Juniper JUNOSE SOFTWARE 11.0.X - LINK LAYER CONFIGURATION GUIDE 4-1-2010 Configuration Manual

If they are not successful, and the magic numbers remain the same, the session
terminates because of the loopback that is detected. Magic numbers are always
accepted.
By default, the router always attempts to negotiate a local magic number. The
peer can also determine whether to negotiate its magic number the peer magic
number. The router always accepts a peer's attempt to negotiate its magic
number.
If the peer does not attempt to negotiate its magic number, you can configure
the router to ignore a mismatch of the peer magic number and retain the PPP
connection. For details, see "Validation of LCP Peer Magic Number" on page 229.
Authentication Requested if configured.
Protocol-Field-Compression (PFC) and Address-and-Control-Field-Compression
(ACFC) Accepted, but never requested.
Multilink PPP Additional options can be negotiated when Multilink PPP is
configured. See "Configuring Multilink PPP" on page 267.
Async-Control-Character-Map (ACCM Supported by PPP when used with an
L2TP Network Server (LNS). ACCM allows PPP to indirectly support asynchronous
PPP connections tunneled via a third-party L2TP Access Concentrator (LAC). PPP
on the router uses the ACCM configuration data as supplied by the LAC via proxy
LCP. The router does not directly support asynchronous PPP connections and
will not negotiate an ACCM option unless directed to do so by a third-party LAC.
PPP can also detect a loopback that occurs after LCP is negotiated, provided that:
No loopback occurs during LCP negotiations.
A loopback is introduced after LCP negotiation without forcing LCP renegotiation.
(LCP is renegotiated if the lower layer goes down or if an LCP confReq is received
from the other end.)

Validation of LCP Peer Magic Number

If the peer has not negotiated an LCP magic number, you can configure the router
to ignore a mismatch of the LCP peer magic number and retain the PPP connection.
Previously, the router terminated a PPP connection with a non-conforming peer
when it received LCP echo request packets or LCP echo reply packets from the peer
with a magic number that did not match the LCP peer magic number on the router.
This is still the current default behavior if you do not explicitly configure the router
to ignore the LCP peer magic number mismatch if the peer has not negotiated the
magic number and retain the PPP connection.
Configuring the router to ignore the peer magic number mismatch and retain the
PPP connection is useful if your network includes peers that send a non-null or invalid
magic number in the LCP echo request and reply packets despite having not
negotiated the magic number. In this situation, the router expects to receive a null
magic number from the peer, and terminates the PPP connection unless you configure
it to ignore the peer magic number mismatch and retain the connection.
Chapter 7: Configuring Point-to-Point Protocol
Overview
229