Step 1: Configuring MPLS Labels and IP Payload to Load-Balance LSP Traffic
If the outbound traffic across equal-cost next hops is not well balanced after you have load balancing configured, you can use MPLS labels and IP payload to provide additional information to further identify traffic flows and balance traffic more evenly, particularly between aggregated interfaces. With an aggregated interface, when you configure load balancing using the per-packet statement, the JUNOS software uses the first MPLS label in the hash algorithm to determine the next hop for the LSP. This behavior can result in an uneven distribution of traffic for aggregated interfaces.
You configure MPLS labels on a transit router because the transit router uses MPLS labels to forward traffic. Configuring the first two MPLS labels and the IP header is useful in the following circumstances:
- If there are many circuit cross-connect (CCC) MPLS LSPs using remote interface switching over an aggregated interface, configuring the first label can load-balance traffic between the component links of an aggregated interface. However, in other circumstances, such as an RSVP LSP, there is no benefit in configuring the first MPLS label by itself because load balancing using the
per-packetstatement uses the first label by default. - If there are many CCC MPLS LSPs using remote interface switching over an aggregated interface with Martini Layer 1 VPN or Layer 2 VPN traffic, configuring the second MPLS label can load-balance traffic between component links of an aggregated interface.
- If there are CCC MPLS LSPs using remote interface switching over an aggregated interface with Layer 3 VPN traffic, Layer 2 VPN, or Martini Layer 2 VPN translational cross-connect (TCC) traffic, configuring the first and second MPLS labels and IP payload can balance traffic between component links of an aggregated interface.
Essentially, load balancing is similar across platforms even though there are slight differences between platforms. On M-series platforms, only Label 1 and the IP payload are used in the hash-key algorithm. On T-series platforms and the M320, all three labels (Label 1, Label 2, and IP payload) are used in the hash-key algorithm. However, there is no harm done if you configure all three labels on an M-series router. The router simply ignores Label 2.
Before you use MPLS labels and IP payload to load-balance traffic, you must have the load-balance per-packet statement configured at the [edit policy-options] hierarchy level and that policy applied as an export policy at the [edit forwarding-options] hierarchy level. For more information about configuring load balancing, see Configuring and Verifying Load Balancing.
Action
To configure the hash key to load-balance LSP traffic, follow these steps:
- Ensure that you have load balancing configured; see Configuring and Verifying Load Balancing.
- In configuration mode, go to the following hierarchy level:
- Depending on your network configuration, include a combination of MPLS labels to include in the configuration:
- Verify and commit the configuration:
[edit]
user@host# edit forwarding-options hash-key
[edit forwarding-options hash-key]
user@host#set family mpls label-1
user@host#set family mpls label-2
user@host#set family mpls payload ip
user@host# show
user@host# commit
Sample Output
user@R2> edit
Entering configuration mode
[edit]
user@R2# edit forwarding-options hash-key
[edit forwarding-options hash-key]
user@R2# set family mpls label-1
[edit forwarding-options hash-key]
user@R2# set family mpls label-2
[edit forwarding-options hash-key]
user@R2# set family mpls payload ip
[edit forwarding-options hash-key]
user@R2# show
family mpls {
label-1;
label-2;
payload {
ip;
}
}
[edit forwarding-options hash-key]
user@R2# commit
commit complete
What It Means
The sample output shows the configuration of all three MPLS labels and verification that the configuration is correct.