Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Understanding MLPPP and Fragmentation-Maps

You enable link fragmentation and interleaving (LFI) on inline service (si) interface bundles by configuring fragmentation-maps. For multilink PPP (MLPPP) bundle support, you must configure fragmentation-maps in class-of-services and reference them in either the bundle dynamic-profile or bundle logical interface (IFL) configuration.

Best Practice:

For MX Series and class-of-service (CoS) implementation, you can configure a fragmentation map to have two forwarding classes pointing to the same queue. However, if you assign multiple forwarding classes to a single queue, you must also reference all of those forwarding classes in a fragmentation map to enable the expected behavior.

If you reference only one of the forwarding classes assigned to a queue, then the other forwarding classes in that queue can clog that queue with large packets. For previous existing fragmentation-map implementations, this condition did not occur because the other forwarding classes inherited this fragmentation behavior assigned to that queue.

If you assign multiple forwarding classes to a queue, create a fragmentation map that addresses each of those forwarding classes. This results in fragmentation-map behavior that more closely reflects the expected behavior based on the fragmentation CLI, while the existing fragmentation-map behavior remains unchanged.

This section contains the following topics:

Fragmentation-Map Settings

By setting fragmentation-maps under class-of-service, you can configure the fragmentation properties on a particular forwarding class, as shown in the following sample output:

Note:

The per-forwarding class drop-timeout statement enabling you to change the resequencing interval in milliseconds for each fragmentation class is not supported in the fragmentation map.

You can configure the following settings for fragmentation-maps:

  • (Optional) fragment-threshold—Sets a per-forwarding class fragmentation threshold in bytes. fragment-threshold sets the maximum size of each multilink fragment. An extra MLPPP header is prepended to these multilink fragments. This same header is also prepended to packets of these forwarding classes that are smaller than the fragmentation threshold.

    • For MLPPP bundle interface configuration, you can set the fragment-threshold for all forwarding classes. Any fragmentation threshold defined by a fragmentation-map and applied to that interface takes precedence for the forwarding classes referenced by that fragmentation-map.

    • For si bundle IFL configuration, the fragment-threshold applies to all forwarding classes. The fragment-threshold setting in fragmentation-maps for a particular forwarding class, if configured, overrides the threshold configured in si bundle IFL for that class. If no fragment-threshold is configured anywhere, packets are still fragmented if the threshold exceeds the smallest MTU or MRRU of all links in the bundle.

      Note:

      The per-forwarding class multilink-class statement enabling you to map a forwarding class into a multiclass MLPPP is not supported for si MLPPP bundles.

  • (Required) no-fragmentation—Sets traffic on a particular forwarding class to be interleaved rather than fragmented. The no-fragmentation setting is required to define high priority traffic and indicates that an extra fragmentation header is not prepended to the packets of this forwarding class

Note:

For a given forwarding class, you can include either the fragment-threshold setting or the no-fragmentation setting; they are mutually exclusive.

Understanding Fragmentation-Map Bindings

Using MLPPP in this manner generates two subscriber interfaces for each subscriber:

  • The inline services (si) bundle interface IFL.

  • The PPP member link IFL.

The data plane traffic destined for the subscriber exits through the (si) bundle interface IFL, and passes through the PPP member link IFL. Queuing is provided for both of these IFLs, which then requires the ability to define class of service.

When you are creating the two subscriber interfaces, the MX Series authenticates only a single user, and the RADIUS server only provides a single set of class-of-service (CoS) attributes. These CoS RADIUS attributes are then applied to both the (si) bundle interface IFL and the PPP member link IFL.

Note:

For this scenario to succeed, you must have already configured the dynamic profiles for these IFLs to accept CoS RADIUS attributes enabling both the (si) bundle interface IFL and the PPP member link IFL to have the same CoS attributes.

To apply different CoS to the (si) bundle interface IFL and the PPP member link IFL, you can set CoS RADIUS attributes to specify the Transmission Control Protocol (TCP) name to which the attribute is intended. The dynamic profile associated with the (si) bundle interface IFL contains the CoS TCP for that IFL, and the dynamic profile associated with the PPP member link IFL contains the CoS TCP for that IFL.

The RADIUS attributes each include a target TCP. When configured, two sets of CoS RADIUS attributes are retrieved with the member link authentication; one set with the (si) bundle interface IFL TCP specified, and the other set with the PPP member link IFL TCP specified.

Related Documentation