[an error occurred while processing this directive][an error occurred while processing this directive]

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:

  1. Define a Load-Balancing Policy
  2. Apply the Load-Balancing Policy to the Forwarding Table
  3. 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:

  1. In configuration mode, go to the following hierarchy level:
    [edit]user@host# edit policy-options
  2. Define the load-balance policy and action:
    [edit policy-options]user@host# set policy-statement policy-name then load-balance per-packet
  3. 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 software 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:

  1. In configuration mode, go to the following hierarchy level:
    [edit]user@host# edit routing-options
  2. Define a load-balance per packet action:
    [edit routing-options]user@host#set forwarding-table export policy-name
  3. 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:

user@host# show configuration

To verify load balancing across interfaces and LSPs, use the following commands on a transit router:

user@host# show route user@host# show route forwarding-table user@host# show mpls lsp statistics user@host# monitor interface traffic user@host# clear mpls lsp statistics user@host# clear interface statistics

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.


Published: 2010-01-30

[an error occurred while processing this directive]