Configuring and Verifying Load Balancing
Purpose
Load balancing is configured on the ingress router and uses the hash algorithm to distribute traffic equally across paths. The hash algorithm is designed to distribute packets to prevent any single link from being saturated. Before you can configure and verify load balancing in an MPLS network, you must have all the necessary MPLS components and protocols configured correctly. For information on configuring an MPLS network, see the Junos MPLS Network Operations Guide.
Keep the following information in mind when you configure load balancing:
- The load-balance per packet policy is configured on an ingress router with more than one LSP configured to the same egress router.
- Load balancing offers no guarantee of equal distribution of traffic over equal-cost links, nor does it guarantee that increasing the number of Internet flows will create a better hash distribution.
To configure and verify load balancing, follow these steps:
- Define a Load-Balancing Policy
- Apply the Load-Balancing Policy to the Forwarding Table
- Verify That Load Balancing Is Working
Define a Load-Balancing Policy
Purpose
On the ingress or transit router, you can include a policy statement that performs load balancing on all routes. For information on including a policy statement that performs load balancing on specific routes, see “Configuring Per-Packet Load Balancing” in the Junos Routing Protocols Configuration Guide.
Action
On the ingress or transit router, to define a load-balancing policy for all routes, follow these steps:
- In configuration mode, go to the following hierarchy level:[edit]user@host# edit policy-options
- Define the load-balance policy and action:[edit policy-options]user@host# set policy-statement policy-name then load-balance per-packet
- Verify and commit the configuration:user@host# showuser@host# commit
Sample Output
user@R6> edit
Entering configuration mode
[edit]
user@R6# edit policy-options
[edit policy-options]
user@R6# set policy-statement load-balance-traffic then load-balance per-packet
[edit policy-options]
user@R6# show
policy-statement load-balance-traffic {
then {
load-balance per-packet;
}
}
[edit policy-options]
user@R6# commit
commit complete
Meaning
The sample output from ingress router R6 shows the process for configuring load balancing. On an Internet Processor I ASIC, packets with the same parameters are spread across multiple equal-cost next hops; while an Internet Processor II ASIC sends packets with the same parameters to the same next hop, since they are in the same flow. The Junos OS command to turn on load balancing uses the action load-balance per-packet, which is misnamed in relation to the Internet Processor II ASIC. On the Internet Processor II ASIC, this command actually enables per-flow load balancing.
Apply the Load-Balancing Policy to the Forwarding Table
Purpose
Apply the policy configured in Step 1 to routes exported from the routing table to the forwarding table.
Action
To apply a load-balancing policy to the forwarding table, follow these steps:
- In configuration mode, go to the following hierarchy level:[edit]user@host# edit routing-options
- Define a load-balance per packet action:[edit routing-options]user@host#set forwarding-table export policy-name
- Verify and commit the configuration:user@host# showuser@host# commit
Sample Output
[edit]
user@R6# edit routing-options
[edit routing-options]
user@R6# set forwarding-table export load-balance-traffic
[edit routing-options]
user@R6# show
static {
[...Output truncated...]
}
router-id 192.168.6.1;
autonomous-system 65432;
forwarding-table {
export load-balance-traffic;
}
[edit routing-options]
user@R6# commit
commit complete
Meaning
The sample output shows the process for applying a load-balancing policy to export routes from the routing table to the forwarding table.
Verify That Load Balancing Is Working
Purpose
After configuring load balancing, check that traffic is load-balanced equally across paths. In this section, the command output reflects the load-balancing configuration of the example network shown in Load-Balancing Network Topology. The clear commands are used to reset LSP and interface counters to zero so that the values reflect the operation of the load-balancing configuration.
Action
To verify load balancing across interfaces and LSPs, use the following command on the ingress router:
To verify load balancing across interfaces and LSPs, use the following commands on a transit router:
Sample Output
The following sample output is for the configuration on ingress router R1:
user@R1> show configuration | no-more
[...Output truncated...]
routing-options {
[...Output truncated...]
forwarding-table {
export lbpp;
}
}
[...Output truncated...]
policy-options {
policy-statement lbpp {
then {
load-balance per-packet;
}
}
}
Meaning
The sample output for the show configuration command on ingress router R1 shows that load balancing is correctly configured with the lbpp policy statement. Also, the lbpp policy is exported into the forwarding table at the [edit routing-options] hierarchy level.
Sample Output
The following sample output is from transit router R2:
user@R2> show route 192.168.0.1 terse
inet.0: 25 destinations, 27 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 192.168.0.1/32 O 10 3 so-0/0/1.0
>so-0/0/2.0
[...Output truncated...]
Meaning
The sample output for the show route command issued on transit router R2 shows the two equal-cost paths (so-0/0/1 and so-0/0/2) through the network to the loopback address to R0 (192.168.0.1). Even though the right angle bracket (>) usually indicates the active route, in this instance it does not, as shown in the following four sample outputs.
Sample Output
The following sample output is from transit router R2:
user@R2> monitor interface traffic R2 Seconds: 65 Time: 11:41:14 Interface Link Input packets (pps) Output packets (pps) so-0/0/0 Up 0 (0) 0 (0) so-0/0/1 Up 126 (0) 164659 (2128) so-0/0/2 Up 85219 (1004) 164598 (2128) so-0/0/3 Up 0 (0) 0 (0) fe-0/1/0 Up 328954 (4265) 85475 (1094) fe-0/1/1 Up 0 (0) 0 (0) fe-0/1/2 Up 0 (0) 0 (0) fe-0/1/3 Up 0 (0) 0 (0) [...Output truncated...]
Meaning
The sample output for the monitor interface traffic command issued on transit router R2 shows that output traffic is evenly distributed across the two interfaces so-0/0/1 and so-0/0/2.
Sample Output
The following sample output is from transit router R2:
user@R2> show mpls lsp statistics Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 5 sessions To From State Packets Bytes LSPname 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp1 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp2 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp3 192.168.0.1 192.168.1.1 Up 87997 17951388 lsp4 192.168.6.1 192.168.0.1 Up 0 0 r0-r1 Total 5 displayed, Up 5, Down 0
Meaning
The sample output for the show mpls lsp statistics command issued on transit router R2 shows that output traffic is evenly distributed across the four LSPs configured on ingress router R6.
Sample Output
The following sample output is from transit router R2:
user@R2> show route forwarding-table destination 10.0.90.14
Routing table: inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.0.90.12/30 user 0 ulst 262144 6
ucst 345 5 so-0/0/1.0
ucst 339 2 so-0/0/2.0
Meaning
The sample output for the show route forwarding-table destination command issued on transit router R2 shows ulst in the Type field, which indicates that load balancing is working. The two unicast (ucst) entries in the Type field are the two next hops for the LSPs.
Sample Output
The following sample output is from transit router R2:
user@R2> show route forwarding-table | find mpls Routing table: mpls MPLS: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 dscd 38 1 0 user 0 recv 37 3 1 user 0 recv 37 3 2 user 0 recv 37 3 100112 user 0 Swap 100032 so-0/0/1.0 100128 user 0 Swap 100048 so-0/0/1.0 100144 user 0 10.0.12.13 Swap 100096 fe-0/1/0.0 100160 user 0 Swap 100112 so-0/0/2.0 100176 user 0 Swap 100128 so-0/0/2.0
Meaning
The sample output for the show route forwarding-table | find mpls command issued on transit router R2 shows the MPLS routing table that contains the labels received and used by this router to forward packets to the next-hop router. This routing table is used mostly on transit routers to route packets to the next router along an LSP. The first three labels in the Destination column (Label 0, Label 1, and Label 2) are automatically entered by MPLS when the protocol is enabled. These labels are reserved MPLS labels defined in RFC 3032. Label 0 is the IPv4 explicit null label. Label 1 is the MPLS equivalent of the IP Router Alert label, and Label 2 is the IPv6 explicit null label.
The remaining five labels in the Destination column are nonreserved labels that the router uses to forward traffic, and the last column Netif, shows the interfaces used to send the labeled traffic. For nonreserved labels, the second Type column shows the operation performed on matching packets. In this example, all non-reserved packets are swapped for outgoing packet labels. For example, packets with the label 100112 have their label swapped for 100032 before they are pushed out of interface so-0/0/1.0.

