Example: Load Balancing BGP Traffic

Requirements

• Configure the device interfaces.
• Configure an interior gateway protocol (IGP).
• Configure BGP.
• Configure a routing policy that exports routes (such as direct routes or IGP routes) from the routing table into BGP.

Overview

The following steps show how to configure per-packet load balancing:

1. Define a load-balancing routing policy by including one or more policy-statement statements at the [edit policy-options] hierarchy level, defining an action of load-balance per-packet:
   policy-statement policy-name {from {match-conditions;route-filter destination-prefix match-type <actions>;prefix-list name;}then {load-balance per-packet;}}
2. Apply the policy to routes exported from the routing table to the forwarding table. To do this, include the forwarding-table and export statements:
   forwarding-table {export policy-name;}

   You cannot apply the export policy to VRF routing instances.

3. Specify all next hops of that route, if more than one exists, when allocating a label corresponding to a route that is being advertised.
4. Configure the forwarding-options hash key for MPLS to include the IP payload.

Note: On some platforms, you can increase the number of paths that are load balanced by using the chassis maximum-ecmp statement. With this statement, you can change the maximum number of equal-cost load-balanced paths to 32 or 64.

In this example, Device R1 is in AS 65000 and is connected to both Device R2 and Device R3, which are in AS 65001. This example shows the configuration on Device R1.

Topology

Figure 1 shows the topology used in this example.

Figure 1: BGP Load Balancing

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

1. Configure the BGP group.
   [edit protocols bgp group external]user@R1# set type external user@R1# set peer-as 65001 user@R1# set neighbor 10.0.1.1 user@R1# set neighbor 10.0.0.2
2. Enable the BGP group to use multiple paths.

   Note: To disable the default check requiring that paths accepted by BGP multipath must have the same neighboring autonomous system (AS), include the multiple-as option.

   [edit protocols bgp group external]user@R1# set multipath
3. Configure the load-balancing policy.
   [edit policy-options policy-statement loadbal]user@R1# set from route-filter 10.0.0.0/16 orlonger user@R1# set then load-balance per-packet
4. Apply the load-balancing policy.
   [edit routing-options]user@R1# set forwarding-table export loadbal
5. Configure the local autonomous system (AS) number.
   [edit routing-options]user@R1# set autonomous-system 65000

Results

From configuration mode, confirm your configuration by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly:

• Verifying Routes
• Verifying Forwarding

Verifying Routes

Purpose

Verify that routes are learned from both routers in the neighboring AS.

Action

From operational mode, run the show route command.

inet.0: 12 destinations, 15 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.2.0/30        *[BGP/170] 03:12:32, localpref 100
                      AS path: 65001 I
                      to 10.0.1.1 via ge-1/2/0.0
                    > to 10.0.0.2 via ge-1/2/1.0
                    [BGP/170] 03:12:32, localpref 100
                      AS path: 65001 I
                    > to 10.0.1.1 via ge-1/2/0.0

inet.0: 12 destinations, 15 routes (12 active, 0 holddown, 0 hidden)
10.0.2.0/30 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 262142
                Next-hop reference count: 3
                Source: 10.0.0.2
                Next hop: 10.0.1.1 via ge-1/2/0.0
                Next hop: 10.0.0.2 via ge-1/2/1.0, selected
                State: <Active Ext>
                Local AS: 65000 Peer AS: 65001
                Age: 3:18:30 
                Task: BGP_65001.10.0.0.2+55402
                Announcement bits (1): 2-KRT 
                AS path: 65001 I
                Accepted Multipath
                Localpref: 100
                Router ID: 192.168.2.1
         BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 602
                Next-hop reference count: 5
                Source: 10.0.1.1
                Next hop: 10.0.1.1 via ge-1/2/0.0, selected
                State: <NotBest Ext>
                Inactive reason: Not Best in its group - Active preferred
                Local AS: 65000 Peer AS: 65001
                Age: 3:18:30 
                Task: BGP_65001.10.0.1.1+53135
                AS path: 65001 I
                Accepted
                Localpref: 100
                Router ID: 192.168.3.1

Meaning

The active path, denoted with an asterisk (*), has two next hops: 10.0.1.1 and 10.0.0.2 to the 10.0.2.0 destination. The 10.0.1.1 next hop is copied from the inactive path to the active path.

Note: The show route detail command output designates one gateway as selected. This output is potentially confusing in the context of load balancing. The selected gateway is used for many purposes in addition to deciding which gateway to install into the kernel when Junos OS is not performing per-packet load-balancing. For instance, the ping mpls command uses the selected gateway when sending packets. Multicast protocols use the selected gateway in some cases to determine the upstream interface. Therefore, even when Junos OS is performing per-packet load-balancing by way of a forwarding-table policy, the selected gateway information is still required for other purposes. It is useful to display the selected gateway for troubleshooting purposes. Additionally, it is possible to use forwarding-table policy to override what is installed into the kernel (for example, by using the install-nexthop action). In this case, the next-hop gateway installed in the forwarding table might be a subset of the total gateways displayed in the show route command.

Verifying Forwarding

Purpose

Verify that both next hops are installed in the forwarding table.

Action

From operational mode, run the show route forwarding-table command.

Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
10.0.2.0/30        user     0                    ulst 262142     2
                              10.0.1.1           ucst   602     5 ge-1/2/0.0
                              10.0.0.2           ucst   522     6 ge-1/2/1.0