Validation Of Lcp Peer Magic Number; Configuring Point-To-Point Protocol - Juniper JUNOSE SOFTWARE 11.2.X - LINK LAYER CONFIGURATION GUIDE 7-7-2010 Configuration Manual

Copyright © 2010, Juniper Networks, Inc.
negotiating are the same, each side attempts to change its magic number. 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 261.
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 299.
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 8: Configuring Point-to-Point Protocol
261