No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


NE40E V800R010C00 Feature Description - WAN Access 01

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
PPP Magic Number Check

PPP Magic Number Check


When two devices are connected through the interfaces over an intermediate transmission device, their connection will be adjusted if the connection is found incorrect during traffic transmission. However, the interfaces cannot detect the connection adjustment because the interfaces do not go Down, and therefore LCP renegotiation is not triggered. However, PPP allows the interfaces to learn the 32-bit host routes from each other only during the LCP negotiation. As a result, the interfaces continue to transmit traffic using the host routes learned during the original connection even after the connection change, and traffic is transmitted incorrectly.

To address this issue, deploy PPP magic number check on these devices. Even if the interfaces do not detect the connection change, PPP magic number check can trigger LCP renegotiation. The interfaces then re-learn the host routes from each other.


Magic numbers are generated by communication devices independently. To prevent devices from generating identical magic numbers, each device generates a unique magic number using its serial number, hardware address, or clock randomly.

Devices negotiate their magic numbers during LCP negotiation and send Echo packets carrying their negotiated magic numbers to their peers after the LCP negotiation.

In Figure 4-8, Device A and Device B are connected over a transmission device, and Device C and Device D are also connected over this transmission device. PPP connections have been established, and LCP negotiation is complete between Device A and Device B and between Device C and Device D. If the connections are found incorrect, an adjustment is required to establish a PPP connection between Device A and Device C. In this situation, PPP magic number check can be used to trigger the LCP renegotiation as follows:
  1. Device A sends to Device C an Echo-Request packet carrying Device A's negotiated magic number.

  2. When receiving the Echo-Request packet, Device C compares the magic number carried in the packet with its peer's negotiated magic number (Device D's). The magic numbers are different, and the error counter on Device C increases by one.

  3. Device C replies to Device A with an Echo-Reply packet carrying Device D's negotiated magic number.

  4. When receiving the Echo-Reply packet, Device A compares the magic number carried in the packet with the local magic number. The magic numbers are different. Device A then compares the magic number in the packet with its peer's negotiated magic number (Device B's). The magic numbers are also different, and the error counter on Device A increases by one.

  5. The preceding steps are repeated. If the error counter reaches a specified value, LCP goes Down, and LCP renegotiation is triggered.

Figure 4-8  Triggering LCP renegotiation

Figure 4-8 shows the connection status before LCP renegotiation. Device A and Device C still use the local and peer's magic numbers that are negotiated previously. These magic numbers are not updated until the LCP renegotiation.
Updated: 2018-07-04

Document ID: EDOC1100027168

Views: 11278

Downloads: 40

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Previous Next