ON THIS PAGE
Multilink and Link Services Logical Interface Configuration Overview
Configuring Encapsulation for Multilink and Link Services Logical Interfaces
Configuring the Drop Timeout Period on Multilink and Link Services Logical Interfaces
Limiting Packet Payload Size on Multilink and Link Services Logical Interfaces
Configuring the Minimum Number of Active Links on Multilink and Link Services Logical Interfaces
Configuring MRRU on Multilink and Link Services Logical Interfaces
Configuring the Sequence Header Format on Multilink and Link Services Logical Interfaces
Configuring Link and Multilink Services Logical Interfaces
Multilink and Link Services Logical Interface Configuration Overview
You configure multilink and link services interface properties at the logical unit level. Default settings for multilink and link services logical interface properties are described in Default Settings for Multilink and Link Services Logical Interfaces.
For general information about logical unit properties or family inet properties, see the Junos OS Network Interfaces Library for Routing Devices.
For information about multilink and link services properties you configure
at the family inet hierarchy level, see Configuring the Links in a Multilink or Link Services
Bundle.
On DS0, E1, or T1 interfaces in LSQ bundles, you can configure
the bandwidth statement, but the router does not use the
bandwidth value if the interfaces are included in an MLPPP or MLFR
bundle. The bandwidth is calculated internally according to the time
slots, framing, and byte-encoding of the interface. For more
information about logical interface properties, see the Junos OS Network Interfaces Library for Routing Devices.
Default Settings for Multilink and Link Services Logical Interfaces
Table 1 lists the default settings for multilink and link services statements, together with the other permitted values or value ranges.
Option |
Default Value |
Possible Values |
|---|---|---|
DLCI |
None |
16 through 1022 |
Drop timeout period |
500 ms for bundles greater than or equal to the T1 bandwidth value and 1500 ms for other bundles. |
0 through 2000 milliseconds |
Encapsulation |
For multilink interfaces, |
|
Fragmentation threshold |
0 bytes |
128 through 16,320 bytes (Nx64) |
Interleave fragments |
disabled |
enabled, disabled |
Minimum links |
1 link |
1 through 8 links |
Maximum received reconstructed unit (MRRU) |
1504 bytes |
1500 through 4500 bytes |
Sequence ID format for MLPPP |
24 bits |
12 or 24 bits |
Sequence ID format for MLFR FRF.15 and FRF.16 |
12 bits |
12 bits |
See Default Settings for Link Services Interfaces for statements that apply to link services physical interfaces only.
See Also
Configuring Encapsulation for Multilink and Link Services Logical Interfaces
Multilink and link services interfaces support the following logical interface encapsulation types:
MLPPP
Multilink Frame Relay (MLFR) end-to-end
By default, the logical interface encapsulation type on multilink interfaces is MLPPP. The default logical interface encapsulation type on link services interfaces is MLFR end-to-end. For general information on encapsulation, see the Junos OS Network Interfaces Library for Routing Devices.
You can also configure physical interface encapsulation on link services interfaces. For more information, see Configuring Encapsulation for Link Services Physical Interfaces.
To configure multilink or link services encapsulation, include
the encapsulation type 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]
You must also configure the T1, E1, or DS0 physical interface with the same encapsulation type.
ACX Series routers do not support DS0 physical interface as member links.
When you configure the first MLFR encapsulated unit or delete the last MLFR encapsulated unit on a port, it triggers an interface encapsulation change on the port, which causes an interface flap on the other units within the port that are configured with generic Frame Relay.
See Also
Configuring the Drop Timeout Period on Multilink and Link Services Logical Interfaces
By default, the drop timeout parameter is disabled. You can configure a drop timeout value to provide a recovery mechanism if individual links in the multilink or link services bundle drop one or more packets. Drop timeout is not a differential delay tolerance setting, and does not limit the overall latency. However, you need to make sure the value you set is larger than the expected differential delay across the links, so that the timeout period does not elapse under normal jitter conditions, but only when there is actual packet loss. You can configure differential delay tolerance for link services interfaces only. For more information, see Configuring Differential Delay Alarms on Link Services Physical Interfaces with MLFR FRF.16.
To configure the drop timeout value, include the drop-timeout statement:
drop-timeout milliseconds;
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]
For link services interfaces, you also can configure the drop
timeout value at the physical interface level by including the drop-timeout statement at the [edit interfaces ls-fpc/pic/port:channel mlfr-uni-nni-bundle-options] hierarchy
level:
drop-timeout milliseconds;
By default, the drop timer has a value of 500 ms for bundles greater than or equal to the T1 bandwidth value, and 1500 ms for other bundles. Any CLI-configured value overrides these defaults. Values can range from 1 through 2000 milliseconds. Values less than 5 milliseconds are not recommended, and a configured value of 0 reverts to the default value of 2000 milliseconds.
For multilink or link services interfaces, if a packet or fragment encounters an error condition and is destined for a disabled bundle or link, it does not contribute to the dropped packet and frame counts in the per-bundle statistics. The packet is counted under the global error statistics and is not included in the global output bytes and output packet counts. This unusual accounting happens only if the error conditions are generated inside the multilink interface, not if the packet encounters errors on the wire or elsewhere in the network.
If you configure the drop-timeout statement with
a value of 0, it disables any resequencing by the PIC for
the specified class of MLPPP traffic. Packets are forwarded with the
assumption that they arrived in sequence, and forwarding of fragmented
packets is disabled for all classes. Fragments dropped as a result
of this setting will increment the counter at the class level.
Alternatively, you can configure the drop-timeout statement at the [edit class-of-service fragmentation-maps map-name forwarding-class class] hierarchy level. The behavior and the default and range values are
identical, but the setting applies only to the specified forwarding
class. Configuration at the bundle level overrides configuration at
the class-of-service level.
By default, compression of the inner PPP header in the MLPPP
payload is enabled. To disable compression, include the disable-mlppp-inner-ppp-pfc statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level.
For example:
interfaces lsq-1/2/0 {
unit 0 {
encapsulation multilink-ppp;
disable-mlppp-inner-ppp-pfc;
multilink-max-classes 4;
family inet {
address 10.50.1.2/30;
}
}
}
For more information about CoS configuration, see the Junos OS Class of Service User Guide for Routing Devices.
You can view the configured drop-timeout value and the status of inner
PPP header compression by issuing the show interfaces interface-name extensive command.
Limiting Packet Payload Size on Multilink and Link Services Logical Interfaces
For multilink and link services logical interfaces with MLPPP encapsulation only, you can configure a fragmentation threshold to limit the size of packet payloads transmitted across the individual links within the multilink circuit. The software splits any incoming packet that exceeds the fragmentation threshold into smaller units suitable for the circuit size; it reassembles the fragments at the other end, but does not affect the output traffic stream. The threshold value affects the payload only; it does not affect the MLPPP header. By default, the fragmentation threshold parameter is disabled.
To ensure proper load balancing:
For Link Services MLFR (FRF.15 and FRF.16) interfaces, do not include the
fragment-thresholdstatement in the configuration.For MLPPP interfaces, do not include both the
fragment-thresholdstatement and theshort-sequencestatement in the configuration.For MLFR (FRF.15 and FRF.16) and MLPPP interfaces, if the MTU of links in a bundle is less than the bundle MTU plus encapsulation overhead, then fragmentation is automatically enabled. You should avoid this situation for MLFR (FRF.15 and FRF.16) interfaces and for MLPPP interfaces on which short-sequencing is enabled.
To configure a fragmentation threshold value, include the fragment-threshold statement:
fragment-threshold bytes;
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]
For link services interfaces, you also can configure a fragmentation
threshold value at the physical interface level by including the fragment-threshold statement at the [edit interfaces ls-fpc/pic/port:channel mlfr-uni-nni-bundle-options] hierarchy
level:
fragment-threshold bytes;
The maximum fragment size can be from 128 through 16,320 bytes. The Junos OS automatically subdivides packet payloads that exceed this value. Any value you set must be a multiple of 64 bytes (Nx64). The default value, 0, results in no fragmentation.
See Also
Configuring the Minimum Number of Active Links on Multilink and Link Services Logical Interfaces
Only MLPPP is supported on ACX Series routers. MLFR is not supported on ACX Series routers.
You can set the minimum number of links that must be up for the multilink bundle as a whole to be labeled up. By default, only one link must be up for the bundle to be labeled up. A member link is considered up when the PPP Link Control Protocol (LCP) phase transitions to open state.
The minimum-links value should be identical on both
ends of the bundle.
To set the minimum number, include the minimum-links statement:
minimum-links number;
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]
For link services interfaces, you also can configure the minimum
number of links at the physical interface level by including the minimum-links statement at the [edit interfaces ls-fpc/pic/port:channel mlfr-uni-nni-bundle-options] hierarchy
level:
minimum-links number;
The number can be from 1 through 8. The maximum number of links supported in a bundle is 8. When 8 is specified, all configured links of a bundle must be up.
Configuring MRRU on Multilink and Link Services Logical Interfaces
The maximum received reconstructed unit (MRRU) is the maximum packet size that the multilink interface can process. It is similar to a maximum transmission unit (MTU), but applies only to multilink bundles. By default, the MRRU is set to 1500 bytes. You can configure a different MRRU value if the peer equipment allows this. The MRRU accounts for the original payload, for example the Layer 3 protocol payload, but does not include the 2-byte PPP header or the additional MLPPP or MLFR header applied while the individual multilink packets are traversing separate links in the bundle.
To configure a different MRRU value, include the mrru statement:
mrru bytes;
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]
ACX Series routers do not support logical systems.
For link services interfaces, you also can configure a different
MRRU at the physical interface level by including the mrru bytes statement at the [edit interfaces ls-fpc/pic/port:channel mlfr-uni-nni-bundle-options] hierarchy
level. The MRRU size can range from 1500 through 4500 bytes.
If you set the MRRU on a bundle to a value larger than the MTU of the individual links within it, you must enable a fragmentation threshold for that bundle. Set the threshold to a value no larger than the smallest MTU of any link included in the bundle.
Determine the appropriate MTU size for the bundle by ensuring that the MTU size does not exceed the sum of the encapsulation overhead and the MTU sizes for the links in the bundle.
You can configure separate family mtu values on the
following protocol families under bundle interfaces: inet, inet6, iso, and mpls. If not configured,
the default value of 1500 is used on all except for mpls configurations, in which the value 1488 is used.
ACX Series routers do not support family inet6 on MLPPP interfaces.
The effective family MTU might be different from the MTU value specified for MLPPP configurations, because it is adjusted downward by the remote MRRU’s constraints. The remote MRRU configuration is not supported on M120 routers.
Configuring the Sequence Header Format on Multilink and Link Services Logical Interfaces
For MLPPP, the sequence header format is set to 24 bits by default. You can configure an alternative value of 12 bits, but 24 bits is considered the more robust value for most networks.
To configure a different sequence header value, include the short-sequence statement:
short-sequence;
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]
For MLFR FRF.15, the sequence header format is set to 24 bits by default. This is the only valid option.
Only MLPPP is supported on ACX Series routers. MLFR is not supported on ACX Series routers.
Configuring CoS on Link Services Interfaces
For link services IQ (lsq-) interfaces, Junos OS
class of service (CoS) is fully supported and functions as described
in the Junos OS Class of Service User Guide for Routing Devices. For more information and detailed configuration
examples, see Layer 2 Service Package Capabilities and Interfaces.
On SRX Series Firewalls, the lsq- interface is an internal
interface, which is not associated with a physical interface. For
information about link services on SRX Series Firewalls, see the Junos OS Interfaces Configuration Guide for Security Devices.
For information about CoS functions and link services on M Series or T Series routers, see the following sections:
- CoS for Link Services Interfaces on M Series and T Series Routers
- Example: Configuring CoS on Link Services Interfaces
CoS for Link Services Interfaces on M Series and T Series Routers
For Link Services PIC interfaces (ls) on M Series
and T Series routers, queue 0 is the only queue that you should configure
to receive fragmented packets. Configure all other queues to be higher-priority
queues.
Table 2 summarizes how CoS queues
work on link services (ls) interfaces.
Supported Bundling Type |
Queue 0 |
Higher-Priority Queues |
|---|---|---|
Hash-based load balancing |
No |
Yes |
MLFR FRF.15 |
Yes |
No |
MLFR FRF.16 |
Yes |
No |
MLPPP |
Yes |
No |
For M Series and T Series routers, CoS on link services (ls) interfaces works as follows:
On all platforms, the Link Services PIC currently supports up to four queues: 0, 1, 2, and 3.
Queue 0 uses MLFR FRF.15, MLFR FRF.16, or MLPPP to bundle packets.
Higher-priority queues (1, 2, and 3) use hash-based load balancing to bundle packets. IP and MPLS header information is included in the hash.
MLPPP packets traversing link services interfaces using queue 0 are fragmented and distributed across the constituent links. Queue 0 packets are sent on the least utilized link, proportional to its bandwidth. The queue 0 load balancer attempts to maintain even distribution of all traffic across all constituent links. In situations with a small number of high-priority traffic flows (queues 1, 2, and 3), queue 0 traffic might be unevenly distributed.
For the MLFR FRF.16 protocol, only queue 0 works. If you configure a bundled interface to use MLFR FRF.16 with queue 0, then you must ensure the classifier does not send any traffic to queues 1, 2, and 3 on that interface.
To carry high-priority traffic correctly on MLFR FRF.16 interfaces, you must configure an output firewall filter that forces all traffic into queue 0 on the ls-
fpc/pic/port.channelinterface.MLFR FRF.15 and MLPPP interfaces support CoS through packet interleaving. The MLFR FRF.16 standard does not support packet interleaving, so all packets destined for an FRF.16 PVC interface must egress from the same queue.
For constituent link interfaces of Link Services PICs, you can configure standard scheduler maps.
For input packets and fragments received from constituent links, you can use regular input firewall filters and standard CoS classifiers on the link services interface.
For packets that pass through a link services interface and are destined for a constituent link interface, all traffic using queue 0 is fragmented. Traffic using higher-priority queues (1, 2, and 3) is not fragmented.
For MLFR FRF.15 and MLPPP, routing protocol packets smaller than 128 bytes are sent to queue 3; routing protocol packets that exceed 128 bytes are sent to queue 0 and fragmented accordingly. For MLFR FRF.16, queue 0 is used for all packet sizes.
You must configure output firewall classification for egress traffic on the link services interface, not directly on the constituent link interface directly.
Inverse multiplexing for ATM (IMA) is not supported on link services interfaces.
For more information, see Configuring Delay-Sensitive Packet Interleaving on Link Services Logical Interfaces and the Routing Policies, Firewall Filters, and Traffic Policers User Guide.
Example: Configuring CoS on Link Services Interfaces
Configure CoS on a link services interface and its constituent link interfaces.
This example applies to M Series and T Series routers. For examples that apply to SRX Series Firewalls, see the Junos OS Interfaces Configuration Guide for Security Devices.
Packets that do not match the firewall filters are sent to a queue that performs load balancing by sending fragments to all constituent links.
Packets that match the firewall filters are sent to a queue that does not support packet fragmentation and reassembly; instead, this traffic is load-balanced by sending each packet flow to a different constituent link. Each packet that matches a firewall filter is subjected to a hash on the IP source address and the IP destination address to determine the packet flow to which each packet belongs.
When you configure the MLPPP encapsulation type or the multilink FRF.15 Frame Relay end-to-end encapsulation type, routing protocol packets smaller than 128 bytes are sent to the network-control queue on the constituent link interface. This keeps routing protocols operating normally, even when low-speed links are congested by regular packets.
[edit interfaces]
ls-7/0/0 {
unit 0 {
encapsulation multilink-ppp;
interleave-fragments;
family inet {
filter {
output lfi_ls_filter;
}
address 10.54.0.2/32 {
destination 10.54.0.1;
}
}
}
}
ge-7/2/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ce1-7/3/6 {
no-partition interface-type e1;
}
e1-7/3/6 {
encapsulation ppp;
unit 0 {
family mlppp {
bundle ls-7/0/0.0;
}
}
}
ce1-7/3/7 {
no-partition interface-type e1;
}
e1-7/3/7 {
encapsulation ppp;
unit 0 {
family mlppp {
bundle ls-7/0/0.0;
}
}
}
[edit class-of-service]
classifiers {
dscp dscp_default {
import default;
}
inet-precedence inet-precedence_default {
import default;
}
}
code-point-aliases {
dscp {
af11 001010;
af12 001100;
af13 001110;
af21 010010;
af22 010100;
af23 010110;
af31 011010;
af32 011100;
af33 011110;
af41 100010;
af42 100100;
af43 100110;
be 000000;
cs1 001000;
cs2 010000;
cs3 011000;
cs4 100000;
cs5 101000;
cs6 110000;
cs7 111000;
ef 101110;
}
inet-precedence {
af11 001;
af21 010;
af31 011;
af41 100;
be 000;
cs6 110;
cs7 111;
ef 101;
nc1 110;
nc2 111;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
interfaces {
ge-7/2/0 {
scheduler-map sched-map;
unit 0 {
classifiers {
dscp dscp_default;
}
}
}
e1-7/3/6 {
scheduler-map sched-map;
}
e1-7/3/7 {
scheduler-map sched-map;
}
ls-7/0/0 {
scheduler-map sched-map;
unit 0 {
classifiers {
inet-precedence inet-precedence_default;
}
}
}
}
scheduler-maps {
sched-map {
forwarding-class af scheduler af-scheduler;
forwarding-class be scheduler be-scheduler;
forwarding-class ef scheduler ef-scheduler;
forwarding-class nc scheduler nc-scheduler;
}
}
schedulers {
af-scheduler {
transmit-rate percent 25;
buffer-size percent 25;
}
be-scheduler {
transmit-rate percent 25;
buffer-size percent 25;
}
ef-scheduler {
transmit-rate percent 25;
buffer-size percent 25;
}
nc-scheduler {
transmit-rate percent 25;
buffer-size percent 25;
}
}
[edit firewall]
filter lfi_ls_filter {
term term0 {
from {
destination-address {
192.168.1.3/32;
}
precedence 5;
}
then {
count count-192-168-1-3;
forwarding-class af;
accept;
}
}
term default {
then {
log;
forwarding-class best effort;
accept;
}
}
}