MLP

The MLP is relatively complex and is designed to solve several problems that are related to load balancing multilink wide-area network (WAN) links. The problems it solves include the following:

• Multivendor interoperability, as specified by RFC 1717

• Packet fragmentation, improving the latency of each packet

• Packet sequence

• Load calculation

Cisco IOS Software supports MPPP and takes advantage of ISDN's access technology to split a single connection across two separate circuits. Originally defined in RFC 1717 of the Internet Engineering Task Force (IETF), and updated by RFC 1990, MLP was initially developed to assist emerging ISDN deployments. It is designed to fragment packets and transmit them over parallel connections such as ISDN BRI and Primary Rate Interface (PRI) access lines. This feature provides load balancing over dialer interfaces, including ISDN synchronous and asynchronous interfaces, improving throughput, and reducing latency between systems. Starting with a relatively simple configuration command, such as ppp multilink , the feature includes endpoint definitions for the multilink bundle (a multi-link logical grouping is called a bundle ) , fragmentations, interleave , and threshold features.

Figure 10-2 provides an example of how incoming (IN) packets are divided up into fragments, and sent over two separate ISDN lines (or two separate B channels). At the destination, another MLP peer receives the fragments and reassembles them back into the correct order.

Figure 10-2. Multilink Point-to-Point Protocol (MLP)

MLP is suitable for a small office/home office (SOHO) environment because of the dynamic nature of bandwidth requirements, and because MLP works over any interface that supports DDR rotary groups and PPP. Multilink systems must do the following:

• Receive protocol data units (PDUs) of a negotiated size

• Combine multiple physical links into one logical link (bundle)

• Receive and reassemble upper-layer PDUs

The MLP feature negotiates the Maximum Received Reconstructed Unit (MRRU) option during the Link Control Protocol (LCP) negotiation, to indicate to its peer that it can combine multiple physical links into a bundle. Also, to indicate that it is willing to multilink by sending the MRRU option as part of the initial LCP option negotiation. In Example 10-20, I and O are input and output messages of the LCP stage of PPP, and MRRU is the negotiated parameter.

Example 10-20. Negotiation of MRRU

 *Mar  2 06:56:14.744: BR0:1 LCP:  O  CONFREQ [Closed] id 29 len 30 *Mar  2 06:56:14.744: BR0:1 LCP:    MagicNumber 0xB765FD17 (0x0506B765FD17) *Mar  2 06:56:14.748: BR0:1 LCP:  MRRU 1524 (0x110405F4)  *Mar  2 06:56:14.748: BR0:1 LCP:    EndpointDisc 1 Local   (0x131001706E6564656C74632D6973646E) *Mar  2 06:56:14.776: BR0:1 LCP:  I  CONFREQ [REQsent] id 249 len 32 *Mar  2 06:56:14.776: BR0:1 LCP:    AuthProto CHAP (0x0305C22305) *Mar  2 06:56:14.776: BR0:1 LCP:    MagicNumber 0x2101ED36 (0x05062101ED36) *Mar  2 06:56:14.780: BR0:1 LCP:  MRRU 1524 (0x110405F4)  *Mar  2 06:56:14.780: BR0:1 LCP:    EndpointDisc 1 Local   (0x130D016163636573732D677731) *Mar  2 06:56:14.784: BR0:1 LCP:  O  CONFACK [REQsent] id 249 len 32 *Mar  2 06:56:14.784: BR0:1 LCP:    AuthProto CHAP (0x0305C22305) *Mar  2 06:56:14.788: BR0:1 LCP:    MagicNumber 0x2101ED36 (0x05062101ED36) *Mar  2 06:56:14.788: BR0:1 LCP:  MRRU 1524 (0x110405F4)  *Mar  2 06:56:14.788: BR0:1 LCP:    EndpointDisc 1 Local   (0x130D016163636573732D677731) *Mar  2 06:56:14.792: BR0:1 LCP:  I  CONFACK [ACKsent] id 29 len 30 *Mar  2 06:56:14.792: BR0:1 LCP:    MagicNumber 0xB765FD17 (0x0506B765FD17) *Mar  2 06:56:14.796: BR0:1 LCP:  MRRU 1524 (0x110405F4)  

After the LCP negotiation has completed successfully, the remote destination must be authenticated, and a dialer map with the remote system name must be configured. The authenticated username ( "804-isdn" ) or callerID determines which bundle to add the link to.

In Example 10-21, one-way authentication with host name authentication is used, where the line *Mar 2 06:56:15.628: BR0:1 PPP : Phase is VIRTUALIZED shows that the process is complete, and it starts a new phasevirtualization and MLP is ON.

Example 10-21. One-Way Authentication of the Remote User Preceding the MLP

 *Mar  2 06:56:14.796: BR0:1 LCP:    EndpointDisc 1 Local   (0x131001706E6564656C74632D6973646E) *Mar  2 06:56:14.800: BR0:1 LCP: State is Open *Mar  2 06:56:14.800: BR0:1 PPP: Phase is AUTHENTICATING,  by the peer *Mar  2 06:56:14.816: BR0:1 CHAP: I CHALLENGE id 130 len 31 from gateway *Mar  2 06:56:14.820: BR0:1 CHAP: O RESPONSE id 130 len 34 from 804-isdn *Mar  2 06:56:15.628: BR0:1 CHAP: I SUCCESS id 130 len 4 *Mar  2 06:56:15.628: BR0:1 PPP: Phase is VIRTUALIZED 

To check if MLP is up and running, use the show ppp multilink command, as shown in Example 10-22.

Example 10-22. Determining if MLP Is Up and Running

 804-isdn#  show ppp multilink  Virtual-Access1, bundle name is access-gw1   Bundle up for 00:00:18   Dialer interface is Dialer1   1 lost fragments, 1 reordered, 0 unassigned   0 discarded, 0 lost received, 1/255 load   0x7 received sequence, 0x0 sent sequence   Member links: 2 (max not set, min not set)  BRI0:1, since 00:00:18   BRI0:2, since 00:00:04  804-isdn# 

The last two lines show two MLP members . Example 10-23 shows the output from the show negotiation command.

Example 10-23. Output from the show negotiation Command for 776 Router

 776-isdn>  show negotiation  System Parameters     PPP Negotiation Parameters       Integrity Interval       10       Retry Count                10       Retry Interval            3000       Terminate Count         2       Multilink                 ON  ! Profile Parameters  Compression               STAC       BACP                      ON       Address Negotiation Local OFF  ! Negotiated Parameters  Connection   1            Virtual       Connection   2            PPP  IPCP MLCP       Connection   3            Virtual 

In the global configuration, MLP supports two functions:

  multilink bundle-name {authenticated   endpoint   both} multilink virtual-template   1-25  

The virtual-template function is known to networkers ; however, the multilink bundle-name endpoint is relatively unknown. This feature was introduced in Cisco IOS Software Release 12.0. During the LCP negotiation of PPP, the endpoint discriminator (ED) option can be negotiated, but it is not required. As previously mentioned, after the LCP negotiation is complete, the remote destination must be authenticated, and a dialer map with the remote system name has to be configured. The dialer maps are not the only solution. See Chapter 11, "Cisco ISDN Configuration Solutions," for more detail. The authenticated username or callerid determines which bundle to add the link. Its primary use is to make a MLP bundle that is unique among different attached users. MLP bundles are either created or supplemented, based on the following four scenarios, and using the ED option in conjunction with an authenticated username. Refer to the output in Example 10-20:

 *Mar  2 06:56:14.744: BR0:1 LCP: O CONFREQ [Closed] id 29 len 30 *Mar  2 06:56:14.744: BR0:1 LCP:    MagicNumber 0xB765FD17 (0x0506B765FD17) *Mar  2 06:56:14.748: BR0:1 LCP:    MRRU 1524 (0x110405F4) *Mar  2 06:56:14.748: BR0:1 LCP:    EndpointDisc 1 Local  :  

• Scenario 1:

  In the first scenario, there is no discriminator, and no authentication; all new links must be joined into one bundle.

  This scenario is not a good idea for any dial service platform where users are not configured to authenticate nor to send an ED. The only time that this is likely to be used is between two fixed systems, where links from an outside device cannot be physically introduced. The debug ppp negotiation output shows that EndpointDisc is missing. Cisco IOS Software uses the Calling Line ID (CLID) to identify the MLP bundle.

• Scenario 2:

  In the second scenario, there is a discriminator, but no authentication. A discriminator match must join a matching bundle, and a discriminator mismatch must establish a new bundle.

  The debug ppp negotiation command shows the endPoint discriminator ( EndpointDisc ) negotiation:

   Se3/0:2 LCP: EndpointDisc 1 804-isdn (0x1308013137323061) <-- ED negotiated with Class 1 (Locally Assigned Address), value =  Hostname (  804-isdn) 

  
  

• Scenario 3:

  In the third scenario, there is no discriminator, but there is authentication. The authenticated match must join the matching bundle, and the authenticated mismatch must establish a new bundle. The debug ppp negotiation will show that the EndpointDisc is missing again.

• Scenario 4:

  In the last scenario, there is a discriminator and user authentication. The discriminator match and authenticated match must join the bundle, and either a discriminator mismatch or authenticated mismatch must establish a new bundle. Again, the command debug ppp negotiation command shows that the EndpointDisc is negotiated:

   Se3/0:2 LCP: EndpointDisc 1 804-isdn (0x1308013137323061)  <--  ED negotiated 

  
  

You can find more detailed information about MLP at Cisco.com.