Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring Link and Multilink Services Bundles

 

MX240, MX480, and MX960 Universal Routing Platforms support MLPPP and MLFR multilink encapsulations. MLPPP enables you to bundle multiple PPP links into a single multilink bundle, and MLFR enables you to bundle multiple Frame Relay data-link connection identifiers (DLCIs) into a single multilink bundle. Multilink bundles provide additional bandwidth, load balancing, and redundancy by aggregating low-speed links, such as T1, E1, and serial links.

You configure multilink bundles as logical units or channels on the link services interface lsq-0/0/0:

  • With MLPPP and MLFR FRF.15, multilink bundles are configured as logical units on lsq-0/0/0—for example, lsq-0/0/0.0 and lsq-0/0/0.1.

  • With MLFR FRF.16, multilink bundles are configured as channels on lsq-0/0/0—for example, lsq-0/0/0:0 and lsq-0/0/0:1.

After creating multilink bundles, you add constituent links to the bundle. The constituent links are the low-speed physical links that are to be aggregated. Depending on the system license and hardware, you can create up to 1023 multilink bundles per Chassis, and on each multilink bundle add up to 8 constituent links. See Multilink and Link Services PICs Overview for more information.

The following rules apply when you add constituent links to a multilink bundle:

  • On each multilink bundle, add only interfaces of the same type. For example, you can add either T1 or E1, but not both.

  • Only interfaces with a PPP encapsulation can be added to an MLPPP bundle, and only interfaces with a Frame Relay encapsulation can be added to an MLFR bundle.

  • If an interface is a member of an existing bundle and you add it to a new bundle, the interface is automatically deleted from the existing bundle and added to the new bundle.

Configuring a multilink bundle on the two serial links increases the bandwidth by 70 percent from approximately 1 Mbps to 1.7 Mbps and prepends each packet with a multilink header as specified in the FRF.12 standard. To increase the bandwidth further, you can add up to eight serial links to the bundle. In addition to a higher bandwidth, configuring the multilink bundle provides load balancing and redundancy. If one of the serial links fails, traffic continues to be transmitted on the other links without any interruption. In contrast, independent links require routing policies for load balancing and redundancy. Independent links also require IP addresses for each link as opposed to one IP address for the bundle. In the routing table, the multilink bundle is represented as a single interface.

Starting with Junos OS Release 13.3, if you attempt to delete or deactivate a static inline service (si) MLPPP bundle interface that is still referenced by a member link interface, which could be PPPoE (pp0) or si logical interfaces, and commit the configuration, the commit operation fails. You must reactivate such MLPPP bundle interface before committing the settings. Alternatively, you must ensure that member links do not refer a static MLPPP bundle before you delete or deactivate the bundle. This method of deactivation and reactivation of an MLPPP bundle is not applicable for interfaces other than si- interfaces, such as link services IQ (lsq-) and virtual LSQ redundancy (rlsq-) interfaces.

You can combine MLFR FRF.16, MLPPP, and MLFR FRF.15 bundles on a single Link Services PIC. For a sample configuration, see Example: Configuring a Link Services Interface with Two Links.

To configure the number of bundles on a Link Services PIC, include the mlfr-uni-nni-bundles statement at the [edit chassis fpc slot-number pic pic-number] hierarchy level:

Each Link Services PIC can accommodate a maximum of 256 MLFR UNI NNI bundles. For more information, see the Junos OS Administration Library.

A link can associate with one link services bundle only. All Link Services PICs support up to 256 single-link bundles and up to 256 DLCIs. For an example configuration, see the configuration examples.

Note

When one or more links in a bundle are put in loopback, reassembly buffering and hence processing are reduced so as to not affect other bundles. This prevents packet loss on other bundles, while reducing the reassembly buffers available for the bundle with looped links.

To complete a multilink or link services interface configuration, you need to configure both the physical interface and the multilink or link services bundle. For multilink interfaces, you configure the link bundle on the logical unit. For link services interfaces, you configure the link bundle as a channel (see Figure 1). The physical interface is usually connected to networks capable of supporting MLPPP or MLFR (FRF.15 or FRF.16).

Figure 1: Multilink Interface Configuration
Multilink Interface Configuration

The following sample configuration refers to the topology in Figure 1 and configures a multilink or link services bundle over a T1 connection (for which the T1 physical interface is already configured).

  1. To configure a physical T1 link for MLPPP, include the following statements at the [edit interfaces t1-fpc/pic/port] hierarchy level:

    You do not need to configure an IP address on this link.

    To configure a physical T1 link for MLFR FRF.16, include the following statements at the [edit interfaces t1-fpc/pic/port] hierarchy level:

    You do not need to configure an IP address or a DLCI on this link.

  2. To configure the logical address for the MLPPP, MLFR FRF.15, or MLFR FRF.16 bundle, include the address and destination statements:

    You can include these statements at the following hierarchy levels:

    • [edit interfaces interface-name unit logical-unit-number family inet]

    • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet]

    When you add statements such as mrru to the configuration and commit, the T1 interface becomes part of the multilink bundle.

Note

For MLPPP and MLFR (FRF.15 and FRF.16) links, you must specify the subnet address as /32 or /30. Any other subnet designation is treated as a mismatch.

This example uses the MLFR UNI NNI protocol between Router A and Router B and logically connects link services bundles ls-1/1/0.3 and ls-0/0/0.10, as specified in Table 1.

Table 1: Link Services Bundle

Router A

Router B

t1-0/1/0 (ls-1/1/0:3)

t1-0/3/0 (ls-0/0/0:10)

t1-0/1/1 (ls-1/1/0:3)

t1-0/3/1 (ls-0/0/0:10)

For LMI to work properly, you must configure one router to be a DCE.

Configuration on Router A

Configuration on Router B

On Router B:

MLPPP enables you to bundle multiple PPP links into a single multilink bundle. MLPPP bundle support on an inline LSQ interface is identical to a non-inline LSQ interface, because the configuration to enable fragmentation, link fragmentation and interleaving (LFI), and timeout is identical.

Priority scheduling on a multilink bundle determines the order in which an output interface transmits traffic from an output queue. The queues are serviced in a weighted round-robin fashion. But when a queue containing large packets starts using the multilink bundle, small and delay-sensitive packets must wait their turn for transmission. Because of this delay, some slow links, such as T1 and E1, can become useless for delay-sensitive traffic.

Link fragmentation and interleaving (LFI) solves this problem. It reduces delay and jitter on links by fragmenting large packets and interleaving delay-sensitive packets with the resulting smaller packets for simultaneous transmission across multiple links of a multilink bundle.

To configure schedule maps and fragmentation maps for MLPPP LFI:

  1. Assign each forwarding class to an internal queue number by including the forwarding-classes statement at the [edit class-of-service] hierarchy level.

    For example, to set four output transmission queues:

  2. To set a per-forwarding class fragmentation threshold, include the fragment-threshold statement in the fragmentation-maps.

    For example, to create two fragmentation maps and set a per-forwarding class fragmentation threshold:

    The fragment-threshold statement in the LSQ bundle logical interface configuration applies to all forwarding classes. The fragment-threshold statement in fragmentation-maps for a particular forwarding class, if present, overrides the statement configured in the LSQ bundle logical interface for that class. If fragment-threshold is not configured anywhere in the configuration, packets are still fragmented if fragment-threshold exceeds the smallest maximum transmission unit (MTU) or maximum received reconstructed unit (MRRU) of all links in the bundle.

  3. Configure transmission scheduling parameters.

    For example, to set the transmit-rate percentage and the priority-level:

  4. After defining a scheduler, associate it with a specified forwarding class by including it in a scheduler-map.

    For example, to associate the af-scheduler, be-scheduler, ef-scheduler, and nc-scheduler schedulers, with the af, be, ef, and nc forwarding-classes:

  5. Configure traffic shaping and scheduling profiles.

    For example, to set the traffic-control policies:

  6. Configure interface-specific CoS properties for incoming packets.

    For example, to apply the specified CoS traffic control profile (traffic scheduling and shaping configuration objects) to the output traffic at the logical interface:

The following partial configuration shows when the fragment threshold for low priority queues inherits from the fragment threshold configured in the bundle IFL and will have the value of 640.

For link services FRF.15 and MLPPP interfaces only, you can configure link fragment interleaving (LFI). LFI reduces excessive delays of Frame Relay packets by fragmenting long packets into smaller packets and interleaving them with real-time frames. This allows real-time and non-real-time data frames to be carried together on lower-speed links without causing excessive delays to the real-time traffic. When the peer interface receives the smaller fragments, it reassembles the fragments into their original packet. For example, short delay-sensitive packets, such as packetized voice, can race ahead of larger delay-insensitive packets, such as common data packets.

Note

All Link Services PICs (4-multilink bundle, 32-multilink bundle, and 128-multilink bundle) support up to 256 link services interfaces with LFI enabled, if those link services interfaces contain only one constituent link each. For the Link Services PIC, multiple-link LFI bundles are simply multilink bundles, and are limited based on the type of PIC (4-multilink bundle, 32-multilink bundle, and 128-multilink bundle).

In addition, the multilink bundles you configure subtract from the total of 256 possible LFI-enabled link services interfaces. For example, if a 32-multilink bundle Link Services PIC has 24 multilink bundles configured and active, then you can configure 256 – 24 = 232 LFI-enabled link services interfaces, each with a single constituent link.

For link services IQ interfaces (lsq), the interleave-fragments statement is not valid. Instead, you can enable LFI by configuring fragmentation maps. For more information, see Configuring CoS Fragmentation by Forwarding Class on LSQ Interfaces.

You can configure multiple links in a bundle and configure packet interleaving. However, if you use packet interleaving, high-priority, nonmultilink-encapsulated packets use a hash-based algorithm to choose a single link.

Per-bundle CoS queuing is supported on link services IQ interfaces (lsq). For more information about link services IQ interfaces, see Layer 2 Service Package Capabilities and Interfaces.

The Junos OS supports end-to-end fragmentation in compliance with the FRF.12 Frame Relay Fragmentation Implementation Agreement standard. Unlike user-to-network interface (UNI) and network-to-network (NNI) fragmentation, end-to-end supports fragmentation only at the endpoints.

By default, packet interleaving is disabled. To enable packet interleaving, include the interleave-fragments statement:

You can include this statement at the following hierarchy levels:

  • [edit interfaces interface-name unit logical-unit-number]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]

Configuring LFI with DLCI Scheduling

For Link Services and Channelized DS3 IQ PICs, you can configure LFI and DLCI scheduling. For channelized DS3 interfaces, LFI is supported with FRF.15 only, and on M10i and M20 platforms only.

Configuring LFI with DLCI scheduling enables packets entering the Link Services PIC to be fragmented before being transmitted to the Channelized DS3 IQ PIC. Once the fragmented packets enter the Channelized DS3 IQ PIC, they are scheduled at the DLCI level, to allow priority transmission for real-time applications.

For more information about associating a scheduler with a DLCI, see the Class of Service User Guide (Routers and EX9200 Switches).

Example: Configuring LFI with DLCI Scheduling

Configure packets entering the Link Services PIC to be fragmented before being transmitted to the Channelized DS3 IQ PIC. Once the fragmented packets enter the Channelized DS3 IQ PIC, they are scheduled at the DLCI level, to allow priority transmission for real-time applications.