Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Load Balancing for a BGP Session

Understanding BGP Multipath

BGP multipath allows you to install multiple internal BGP paths and multiple external BGP paths to the forwarding table. Selecting multiple paths enables BGP to load-balance traffic across multiple links.

A path is considered a BGP equal-cost path (and is used for forwarding) if the BGP path selection process performs a tie-break after comparing the IGP cost to the next-hop. By default, all paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor are considered in the multipath selection process.

BGP typically selects only one best path for each prefix and installs that route in the forwarding table. When BGP multipath is enabled, the device selects multiple equal-cost BGP paths to reach a given destination, and all these paths are installed in the forwarding table. BGP advertises only the active path to its neighbors, unless add-path is in use.

The Junos OS BGP multipath feature supports the following applications:

  • Load balancing across multiple links between two routing devices belonging to different autonomous systems (ASs)

  • Load balancing across a common subnet or multiple subnets to different routing devices belonging to the same peer AS

  • Load balancing across multiple links between two routing devices belonging to different external confederation peers

  • Load balancing across a common subnet or multiple subnets to different routing devices belonging to external confederation peers

In a common scenario for load balancing, a customer is multihomed to multiple routers or switches in a point of presence (POP). The default behavior is to send all traffic across only one of the available links. Load balancing causes traffic to use two or more of the links.

BGP multipath does not apply to paths that share the same MED-plus-IGP cost, yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

Starting in Junos OS Release 18.1R1 BGP multipath is supported globally at [edit protocols bgp] hierarchy level. You can selectively disable multipath on some BGP groups and neighbors. Include disable at [edit protocols bgp group group-name multipath] hierarchy level to disable multipath option for a group or a specific BGP neighbor.

Starting in Junos OS Release 18.1R1, you can defer multipath calculation until all BGP routes are received. When multipath is enabled, BGP inserts the route into the multipath queue each time a new route is added or whenever an existing route changes. When multiple paths are received through BGP add-path feature, BGP might calculate one multipath route multiple times. Multipath calculation slows down the RIB (also known as the routing table) learning rate. To speed up RIB learning, multipath calculation can be either deferred until the BGP routes are received or you can lower the priority of the multipath build job as per your requirements until the BGP routes are resolved. To defer the multipath calculation configure defer-initial-multipath-build at [edit protocols bgp] hierarchy level. Alternatively, you can lower the BGP multipath build job priority using multipath-build-priority configuration statement at [edit protocols bgp] hierarchy level to speed up RIB learning.

Example: Load Balancing BGP Traffic

This example shows how to configure BGP to select multiple equal-cost external BGP (EBGP) or internal BGP (IBGP) paths as active paths.

Requirements

Before you begin:

  • 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:

    Note:

    To enable load-balancing among multiple EBGP paths and multiple IBGP paths , include the multipath statement globally at the [edit protocols bgp] hierarchy level. You cannot enable load-balancing of BGP traffic without including the multipath statement globally, or for a BGP group at the [edit protocols bgp group group-name hierarchy level, or for specific BGP neighbors at the [edit protocols bgp group group-name neighbor address] hierarchy level.

  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:

    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, 64, 128, 256, or 512 (the maximum number varies per platform—see maximum-ecmp.) Starting with Junos OS Release 19.1R1, you can specify a maximum number of 128 equal-cost paths on QFX10000 switches. Starting with Junos OS Release 19.2R1, you can specify a maximum number of 512 equal-cost paths on QFX10000 switches.—see Understanding Configuration of Up to 512 Equal-Cost Paths With Optional Consistent Load Balancing.

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

Topology

Figure 1 shows the topology used in this example.

Figure 1: BGP Load BalancingBGP Load Balancing

Configuration

Procedure

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

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure the BGP peer sessions:

  1. Configure the BGP group.

  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.

  3. Configure the load-balancing policy.

  4. Apply the load-balancing policy.

  5. Configure the local autonomous system (AS) number.

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

Purpose

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

Action

From operational mode, run the show route command.

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.

Understanding Configuration of Up to 512 Equal-Cost Paths With Optional Consistent Load Balancing

You can configure the equal-cost multipath (ECMP) feature with up to 512 paths for external BGP peers. Having the ability to configure up to 512 ECMP next hops allows you to increase the number of direct BGP peer connections with your specified routing device, thus improving latency and optimizing data flow. You can optionally include consistent load balancing in that ECMP configuration. Consistent load balancing ensures that if an ECMP member (that is, a path) fails, only flows flowing through the failed member are redistributed to other active ECMP members. Consistent load balancing also ensures that if an ECMP member is added, redistribution of flows from existing EMCP members to the new ECMP member is minimal.

Guidelines and Limitations for Configuring from 256 to 512 Equal-Cost Paths, Optionally with Consistent Load Balancing

  • The feature applies only to single-hop external BGP peers. (This feature does not apply to MPLS routes.)

  • The device’s routing process (RPD) must support 64-bit mode; 32-bit RPD is not supported.

  • The feature applies only to unicast traffic.

  • Traffic distribution might not be even across all group members—it depends on the traffic pattern and on the organization of the hashing flow set table in hardware. Consistent hashing minimizes remapping of flows to destination links when members are added to or deleted from the group.

  • If you configure set forwarding-options enhanced-hash-key with one of the options hash-mode, inet, inet6, or layer2, some flows might change destination links, because the new hash parameters might generate new hash indexes for the flows, resulting in new destination links.

  • To achieve the best-possible hashing accuracy, this feature uses a cascaded topology to implement the next-hop structure for configurations of more than 128 next hops. Hashing accuracy is therefore somewhat lesser than it is for ECMP next-hop configurations of less than 128, which do not require a cascaded topology.

  • Existing flows on affected ECMP paths and new flows flowing over those affected ECMP paths might switch paths during local route repair, and traffic skewing might be noticeable. However, any such skewing is corrected during the subsequent global route repair.

  • When you increase the maximum-ecmp value, consistency hashing is lost during the next next-hop-change event for the route prefix.

  • If you add a new path to an existing ECMP group, some flows over unaffected paths might move to the newly added path.

  • Fast reroute (FRR) might not work with consistent hashing.

  • Perfect ECMP-like traffic distribution cannot be achieved. Paths that have more “buckets” than other paths have more traffic flows than paths with fewer buckets (a bucket is an entry in the load-balancing table’s distribution list that is mapped to an ECMP member index).

  • During network topology change events, consistent hashing is lost for network prefixes in some instances because those prefixes point to a new ECMP next hop that does not have all properties of the prefixes’ previous ECMP next hops.

  • If multiple network prefixes point to the same ECMP next hop and one or more of those prefixes is enabled with the consistent-hash statement, all network prefixes pointing to that same ECMP next hop display consistent–hashing behavior.

  • Consistent hashing is supported on the equal-cost BGP routes–based ECMP group only. When other protocols or static routes are configured that have priority over BGP routes, consistent hashing is not supported.

  • Consistent hashing might have limitations when the configuration is combined with configurations for the following features, because these features have tunnel terminations or traffic engineering that does not use hashing for selecting paths—GRE tunneling; BUM traffic; EVPN-VXLAN; and MPLS TE, autobandwidth.

Instructions for Configuring Up to 512 ECMP Next Hops, and Optionally Configuring Consistent Load Balancing

When you are ready to configure up to 512 next hops, use the following configuration instructions:

  1. Configure the maximum number of ECMP next hops—for example, configure 512 ECMP next hops:

  2. Creating a routing policy and enable per-packet load balancing, thus enabling ECMP globally on the system:

  3. Enable resiliency on selected prefixes by creating a separate routing policy to match incoming routes to one or more destination prefixes—for example:

  4. Apply an eBGP import policy (for example, “c-hash”) to the BGP group of external peers:

For more detail on configuring equal-cost paths, see Example: Load Balancing BGP Traffic, which appears earlier in this document.

(Optional) For more detail on configuring consistent load balancing (also known as consistent hashing), see Configuring Consistent Load Balancing for ECMP Groups

Example: Configuring Single-Hop EBGP Peers to Accept Remote Next Hops

This example shows how to configure a single-hop external BGP (EBGP) peer to accept a remote next hop with which it does not share a common subnet.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

In some situations, it is necessary to configure a single-hop EBGP peer to accept a remote next hop with which it does not share a common subnet. The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded. The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses. Configuring the accept-remote-nexthop statement allows a single-hop EBGP peer to accept a remote next hop, which restores multipath functionality for routes that are resolved over these next-hop addresses. You can configure this statement at the global, group, and neighbor hierarchy levels for BGP. The statement is also supported on logical systems and the VPN routing and forwarding (VRF) routing instance type. Both the remote next-hop and the EBGP peer must support BGP route refresh as defined in RFC 2918, Route Refresh Capability in BGP-4. If the remote peer does not support BGP route refresh, the session is reset.

A single-hop EBGP peer advertises its own address as the next hop by default. if you want to advertise a different next hop you must define an import routing policy on the EBGP peer. When you enable a single-hop EBGP peer to accept a remote next hop, you can also configure an import routing policy on the EBGP peer. However, a routing policy is not required if you have configured a remote next hop.

This example includes an import routing policy, agg_route, that enables a single-hop external BGP peer (Device R1) to accept the remote next-hop 10.1.10.10 for the route to the 10.1.230.0/23 network. At the [edit protocols bgp] hierarchy level, the example includes the import agg_route statement to apply the policy to the external BGP peer and includes the accept-remote-nexthop statement to enable the single-hop EBGP peer to accept the remote next hop.

Figure 2 shows the sample topology.

Figure 2: Topology for Accepting a Remote Next HopTopology for Accepting a Remote Next Hop

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.

Device R0

Device R1

Device R2

Device R0

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R0:

  1. Configure the interfaces.

  2. Configure EBGP.

  3. Enable multipath BGP between Device R0 and Device R1.

  4. Configure static routes to remote networks. These routes are not part of the topology. The purpose of these routes is to demonstrate the functionality in this example.

  5. Configure routing policies that accept the static routes.

  6. Export the agg_route and test_route policies from the routing table into BGP.

  7. Configure the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, 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.

Configuring Device R1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1:

  1. Configure the interfaces.

  2. Configure OSPF.

  3. Enable Device R1 to accept the remote next hop.

  4. Configure IBGP.

  5. Configure EBGP.

  6. Enable multipath BGP between Device R0 and Device R1.

  7. Configure a routing policy that enables a single-hop external BGP peer (Device R1) to accept the remote next-hop 10.1.10.10 for the route to the 10.1.230.0/23 network.

  8. Import the agg_route policy into the routing table on Device R1.

  9. Configure the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, 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.

Configuring Device R2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R2:

  1. Configure the interfaces.

  2. Configure OSPF.

  3. Configure IBGP.

  4. Configure the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 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 That the Multipath Route with the Indirect Next Hop Is in the Routing Table

Purpose

Verify that Device R1 has a route to the 10.1.230.0/23 network.

Action

From operational mode, enter the show route 10.1.230.0 extensive command.

Meaning

The output shows that Device R1 has a route to the 10.1.230.0 network with the multipath feature enabled (Accepted Multipath). The output also shows that the route has an indirect next hop of 10.1.10.10.

Deactivating and Reactivating the accept-remote-nexthop Statement

Purpose

Make sure that the multipath route with the indirect next hop is removed from the routing table when you deactivate the accept-remote-nexthop statement.

Action
  1. From configuration mode, enter the deactivate protocols bgp accept-remote-nexthop command.

  2. From operational mode, enter the show route 10.1.230.0 command.

  3. From configuration mode, reactivate the statement by entering the activate protocols bgp accept-remote-nexthop command.

  4. From operational mode, reenter the show route 10.1.230.0 command.

Meaning

When the accept-remote-nexthop statement is deactivated, the multipath route to the 10.1.230.0 network is removed from the routing table .

Understanding Load Balancing for BGP Traffic with Unequal Bandwidth Allocated to the Paths

The multipath option removes the tiebreakers from the active route decision process, thereby allowing otherwise equal cost BGP routes learned from multiple sources to be installed into the forwarding table. However, when the available paths are not equal cost, you may wish to load balance the traffic asymmetrically.

Once multiple next hops are installed in the forwarding table, a specific forwarding next hop is selected by the Junos OS per-prefix load-balancing algorithm. This process hashes against a packet’s source and destination addresses to deterministically map the prefix pairing onto one of the available next hops. Per-prefix mapping works best when the hash function is presented with a large number of prefixes, such as might occur on an Internet peering exchange, and it serves to prevent packet reordering among pairs of communicating nodes.

An enterprise network normally wants to alter the default behavior to evoke a per-packet load-balancing algorithm. Per-packet is emphasized here because its use is a misnomer that stems from the historic behavior of the original Internet Processor ASIC. In reality, current Juniper Networks routers support per-prefix (default) and per-flow load balancing. The latter involves hashing against various Layer 3 and Layer 4 headers, including portions of the source address, destination address, transport protocol, incoming interface, and application ports. The effect is that now individual flows are hashed to a specific next hop, resulting in a more even distribution across available next hops, especially when routing between fewer source and destination pairs.

With per-packet load balancing, packets comprising a communication stream between two endpoints might be resequenced, but packets within individual flows maintain correct sequencing. Whether you opt for per-prefix or per-packet load balancing, asymmetry of access links can present a technical challenge. Either way, the prefixes or flows that are mapped to, for example, a T1 link will exhibit degraded performance when compared to those flows that map to, for example, a Fast Ethernet access link. Worse yet, with heavy traffic loads, any attempt at equal load balancing is likely to result in total saturation of the T1 link and session disruption stemming from packet loss.

Fortunately, the Juniper Networks BGP implementation supports the notion of a bandwidth community. This extended community encodes the bandwidth of a given next hop, and when combined with multipath, the load-balancing algorithm distributes flows across the set of next hops proportional to their relative bandwidths. Put another way, if you have a 10-Mbps and a 1-Mbps next hop, on average nine flows will map to the high-speed next hop for every one that uses the low speed.

Use of BGP bandwidth community is supported only with per-packet load balancing.

The configuration task has two parts:

  • Configure the external BGP (EBGP) peering sessions, enable multipath, and define an import policy to tag routes with a bandwidth community that reflects link speed.

  • Enable per-packet (really per-flow) load balancing for optimal distribution of traffic.

Example: Load Balancing BGP Traffic with Unequal Bandwidth Allocated to the Paths

This example shows how to configure BGP to select multiple unequal-cost paths as active paths.

BGP communities can help you control routing policy. An example of a good use for BGP communities is unequal load balancing. When an autonomous system border router (ASBR) receives routes from directly connected external BGP (EBGP) neighbors, the ASBR then advertises those routes to internal neighbors, using IBGP advertisements. In the IBGP adverisements, you can attach the link-bandwidth community to communicate the bandwidth of the advertised external link. This is useful when multiple external links are available, and you want to do unequal load balancing over the links. You configure the link-bandwidth extended community on all ingress links of the AS. The bandwidth information in the link-bandwidth extended community is based on the configured bandwidth of the EBGP link. It is not based on the amount of traffic on the link. Junos OS supports BGP link-bandwidth and multipath load balancing, as described in Internet draft draft-ietf-idr-link-bandwidth-06, BGP Link Bandwidth Extended Community. Note that even though draft-ietf-idr-link-bandwidth-06 specifies non-transitive communities, the Junos OS implementation is limited to transitive communities.

Requirements

Before you begin:

  • 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

In this example, Device R1 is in AS 64500 and is connected to both Device R2 and Device R3, which are in AS 64501.

The example uses the bandwidth extended community.

By default, when BGP multipath is used, traffic is distributed equally among the several paths calculated. The bandwidth extended community allows an additional attribute to be added to BGP paths, thus allowing the traffic to be distributed unequally. The primary application is a scenario where multiple external paths exist for a given network with asymmetric bandwidth capabilities. In such a scenario, you can tag routes received with the bandwidth extended community. When BGP multipath (internal or external) operates among routes that contain the bandwidth attribute, the forwarding engine can unequally distribute traffic according to the bandwidth corresponding to each path.

When BGP has several candidate paths available for multipath purposes, BGP does not perform unequal cost load balancing according to the bandwidth community unless all candidate paths have this attribute.

The applicability of the bandwidth extended community is limited by the restrictions under which BGP multipath accepts multiple paths for consideration. Explicitly, the IGP distance, as far as BGP is concerned, between the router performing load balancing and the multiple exit points needs to be the same. This can be achieved by using a full mesh of label-switched paths (LSPs) that do not track the corresponding IGP metric. However, in a network in which the propagation delay of circuits is significant (for example, if long-haul circuits are present), it is often valuable to take into account the delay characteristics of different paths.

Configure the bandwidth community as follows:

The first 16-bit number represents the local autonomous system. The second 32-bit number represents the link bandwidth in bytes per second.

For example:

Where 10458 is the local AS number. The values correspond to the bandwidth of the T1, T3, and OC-3 paths in bytes per second. The value specified as the bandwidth value does not need to correspond to the actual bandwidth of a specific interface. The balance factors used are calculated as a function of the total bandwidth specified. To tag a route with this extended community, define a policy statement, as follows:

Apply this as an import policy on the BGP peering sessions facing the asymmetrical bandwidth links. Although in theory the community attribute can be added or removed at any point in the network, in the scenario described above, applying the community as an import policy in the EBGP peering session facing the external link allows for that attribute to influence the local multipath decision, and is potentially easier to manage.

Topology

Figure 3 shows the topology used in this example.

Figure 3: BGP Load BalancingBGP Load Balancing

CLI Quick Configuration shows the configuration for all of the devices in Figure 3. The section#d29e113__d29e376 describes the steps on Device R1.

Configuration

Procedure

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.

Device R1

Device R2

Device R3

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure the BGP peer sessions:

  1. Configure the interfaces.

  2. Configure the BGP group.

  3. 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. Use the multiple-as option if the neighbors are in different ASs.

  4. Configure the load-balancing policy.

  5. Apply the load-balancing policy.

  6. Configure the BGP community members.

    This example assumes a bandwidth of 1 Gbps and allocates 60 percent to bw-high and 40 percent to bw-low. The reference bandwidth does not need to be the same as the link bandwidth.

  7. Configure the bandwidth distribution policy.

  8. Configure the local autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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

Purpose

Verify that both routes are selected and that the next hops on the routes show a 60%/40% balance.

Action

From operational mode, run the show route protocol bgp detail command.

Meaning

The active path, denoted with an asterisk (*), has two next hops: 10.0.1.1 and 10.0.0.2 to the 172.16/16 destination.

Likewise, 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.

In both cases, the 10.0.1.1 next hop is copied from the inactive path to the active path.

The balance of 40 percent and 60 percent is shown in the show route output. This indicates that traffic is being distributed between two next hops and that 60 percent of the traffic is following the first path, while 40 percent is following the second path.

Example: Configuring a Policy to Advertise Aggregate Bandwidth Across External BGP Links for Load Balancing

This example shows how to configure a policy to advertise aggregate bandwidth across External BGP links for load balancing and to specify a threshold for the configured aggregate bandwidth. BGP adds up the available link bandwidth of multipaths and calculates the aggregated bandwidth. In case of a link failure, the aggregated bandwidth is adjusted to reflect the current status of the available bandwidth.

Requirements

This example uses the following hardware and software components:

  • Four routers with load balancing capability

  • Junos OS Release 17.4 or later running on all the devices

Overview

Starting in Junos OS Release 17.4R1, a BGP speaker that receives multiple paths from its internal peers load balances traffic among these paths. In earlier Junos OS releases, a BGP speaker receiving multiple paths from its internal peers advertised only the link bandwidth associated with the active route. BGP uses a new link bandwidth extended community with the aggregated bandwidth to tag multipaths and advertises the aggregated bandwidth for these multiple routes across its DMZ link. To advertise aggregated multiple routes, configure a policy with aggregate-bandwidth and limit bandwidth actions at the [edit policy-options policy-statement name then] hierarchy level.

Topology

Figure 5: Configuring a Policy to Advertise Aggregate Bandwidth Across External BGP Links for Load BalancingConfiguring a Policy to Advertise Aggregate Bandwidth Across External BGP Links for Load Balancing

In Figure 5, Router R1 load balances traffic to a remote destination through next-hop 10.0.1.1 in Router R2 at 60,000,000 bytes per second and through 10.0.0.2 in Router R3 at 40,000,000 bytes per second. Router R1 advertises destination 10.0.2.0 to Router R4. Router R1 calculates the aggregate of the available bandwidth, which is 10000000 bytes per second. However, a policy configured on Router R1 sets the threshold for the aggregate bandwidth to 80,000,000 bytes per second. Therefore, R1 advertises 80,000,000 bytes per second instead of the 10,000,000 bytes per second.

Note:

If one of the multipath links goes down, then the bandwidth of the failed link is not added to the aggregate bandwidth that is advertised to BGP neighbors.

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router R1

Router R2

Router R3

Router R4

Configuring Routers, Starting with R1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a policy to advertise an aggregated bandwidth to BGP peers (starting with Router R1):

Note:

Repeat this procedure on routers R2, R3, and R4 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv4 addresses.

  2. Configure the loopback address.

  3. Configure the autonomous system for BGP hosts.

  4. Configure EBGP on the external edge routers.

  5. Define a bandwidth distribution policy to assign a high bandwidth community to traffic destined to Router R3.

  6. Define a bandwidth distribution policy to assign a low bandwidth community to traffic destined to Router R2.

  7. Enable the feature to advertise aggregated bandwidth of 80,000,000 bytes to EBGP peer Router R4 over BGP sessions.

  8. Apply the aggregate_bw_and limit_capacity policy to EBGP group external2.

  9. Define a load balancing policy.

  10. Apply the load balancing policy.

  11. Configure the BGP community members. The first 16-bit number represents the local autonomous system. The second 32-bit number represents the link bandwidth in bytes per second. Configure a bw-high community with 60 percent of a 1-Gbps link and another community bw-low with 40 percent of a 1-Gbps link.

    Configure 60 percent of a 1-Gbps link to bw-high community and 40 percent to bw-low community.

Results

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

Verification

Verifying BGP Session Is Established

Purpose

To verify that BGP peering is complete and a BGP session is established between the routers,

Action
Meaning

Router R1 has completed peering with Routers R2, R3, and R4.

Verifying That the Aggregate Bandwidth Is Present in Each Path

Purpose

To verify that the extended community is present for each route path.

Action

From operational mode, run the show route protocol bgp detail command.

Meaning

Verifying That Router R1 Is Advertising the Aggregate Bandwidth to Its Neighbor Router R4

Purpose

To verify that Router R1 is advertising the aggregate bandwidth to its external neighbors.

Action
Meaning

Router R1 is advertising the aggregated bandwidth of 80,000,000 bytes to its neighbors.

Understanding the Advertisement of Multiple Paths to a Single Destination in BGP

BGP peers advertise routes to each other in update messages. BGP stores its routes in the Junos OS routing table (inet.0). For each prefix in the routing table, the routing protocol process selects a single best path, called the active path. Unless you configure BGP to advertise multiple paths to the same destination, BGP advertises only the active path.

Instead of advertising only the active path to a destination, you can configure BGP to advertise multiple paths to the destination. Within an autonomous system (AS), the availability of multiple exit points to reach a destination provides the following benefits:

  • Fault tolerance—Path diversity leads to reduction in restoration time after failure. For instance, a border after receiving multiple paths to the same destination can precompute a backup path and have it ready so that when the primary path becomes invalid, the border routing device can use the backup to quickly restore connectivity. Without a backup path, the restoration time depends on BGP reconvergence, which includes withdraw and advertisement messages in the network before a new best path can be learned.

  • Load balancing—The availability of multiple paths to reach the same destination enables load balancing of traffic, if the routing within the AS meets certain constraints.

  • Maintenance—The availability of alternate exit points allows for graceful maintenance operation of routers.

The following limitations apply to advertising multiple routes in BGP:

  • Address families supported:

    • IPv4 unicast (family inet unicast)

    • IPv6 unicast (family inet6 unicast)

    • IPv4 labeled unicast (family inet labeled-unicast)

    • IPv6 labeled unicast (family inet6 labeled-unicast)

    • IPv4 VPN unicast (family inet-vpn unicast)

    • IPv6 VPN unicast (family inet6-vpn unicast)

    The following example shows the configuration of IPv4 VPN unicast and IPv6 VPN unicast families:

  • We support add-path for internal BGP (IBGP) and external BGP (EBGP) peers.

    Note:
    • We support add-path receive for IBGP and EBGP peers.

    • We support add-path send only for IBGP peers.

    • We do not support add-path send for EBGP peers. When you try to commit the configuration for add-path send for EBGP peers, the CLI throws a commit error.

  • Master instance only. No support for routing instances.

  • Graceful restart and nonstop active routing (NSR) are supported.

  • No BGP Monitoring Protocol (BMP) support.

  • Prefix policies enable you to filter routes on a router that is configured to advertise multiple paths to a destination. Prefix policies can only match prefixes. They cannot match route attributes, and they cannot change the attributes of routes.

Starting in Junos OS Release 18.4R1, BGP can advertise a maximum of 2 add-path routes in addition to the multiple ECMP paths.

To advertise all add-paths up to 64 add-paths or only equal-cost-paths, include path-selection-mode at the [edit protocols bgp group group-name family name addpath send] hierarchy level. You cannot enable both multipath and path-selection-mode at the same time.

Example: Advertising Multiple Paths in BGP

In this example, BGP routers are configured to advertise multiple paths instead of advertising only the active path. Advertising multiple paths in BGP is specified in RFC 7911, Advertisement of Multiple Paths in BGP.

Requirements

This example uses the following hardware and software components:

  • Eight BGP-enabled devices.

  • Five of the BGP-enabled devices do not necessarily need to be routers. For example, they can be EX Series Ethernet Switches.

  • Three of the BGP-enabled devices are configured to send multiple paths or receive multiple paths (or both send and receive multiple paths). These three BGP-enabled devices must be M Series Multiservice Edge Routers, MX Series 5G Universal Routing Platforms, or T Series Core Routers.

  • The three routers must be running Junos OS Release 11.4 or later.

Overview

The following statements are used for configuring multiple paths to a destination:

In this example, Router R5, Router R6, and Router R7 redistribute static routes into BGP. Router R1 and Router R4 are route reflectors. Router R2 and Router R3 are clients to Route Reflector R1. Router R8 is a client to Route Reflector R4.

Route reflection is optional when multiple-path advertisement is enabled in BGP.

With the add-path send path-count 6 configuration, Router R1 is configured to send up to six paths (per destination) to Router R4.

With the add-path receive configuration, Router R4 is configured to receive multiple paths from Router R1.

With the add-path send path-count 6 configuration, Router R4 is configured to send up to six paths to Router R8.

With the add-path receive configuration, Router R8 is configured to receive multiple paths from Router R4.

The add-path send prefix-policy allow_199 policy configuration (along with the corresponding route filter) limits Router R4 to sending multiple paths for only the 172.16.199.1/32 route.

Topology Diagram

Figure 6 shows the topology used in this example.

Figure 6: Advertisement of Multiple Paths in BGPAdvertisement of Multiple Paths in BGP

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.

Router R1

Router R2

Router R3

Router R4

Router R5

Router R6

Router R7

Router R8

Configuring Router R1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Router R1:

  1. Configure the interfaces to Router R2, Router R3, Router R4, and Router R5, and configure the loopback (lo0) interface.

  2. Configure BGP on the interfaces, and configure IBGP route reflection.

  3. Configure Router R1 to send up to six paths to its neighbor, Router R4.

    The destination of the paths can be any destination that Router R1 can reach through multiple paths.

  4. Configure OSPF on the interfaces.

  5. Configure the router ID and the autonomous system number.

  6. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Configuring Router R2

Step-by-Step Procedure

To configure Router R2:

  1. Configure the loopback (lo0) interface and the interfaces to Router R6 and Router R1.

  2. Configure BGP and OSPF on Router R2’s interfaces.

  3. For routes sent from Router R2 to Router R1, advertise Router R2 as the next hop, because Router R1 does not have a route to Router R6’s address on the 10.0.26.0/24 network.

  4. Configure the autonomous system number.

  5. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Configuring Router R3

Step-by-Step Procedure

To configure Router R3:

  1. Configure the loopback (lo0) interface and the interfaces to Router R7 and Router R1.

  2. Configure BGP and OSPF on Router R3’s interfaces.

  3. For routes sent from Router R3 to Router R1, advertise Router R3 as the next hop, because Router R1 does not have a route to Router R7’s address on the 10.0.37.0/24 network.

  4. Configure the autonomous system number.

  5. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Configuring Router R4

Step-by-Step Procedure

To configure Router R4:

  1. Configure the interfaces to Router R1 and Router R8, and configure the loopback (lo0) interface.

  2. Configure BGP on the interfaces, and configure IBGP route reflection.

  3. Configure Router R4 to send up to six paths to its neighbor, Router R8.

    The destination of the paths can be any destination that Router R4 can reach through multiple paths.

  4. Configure Router R4 to receive multiple paths from its neighbor, Router R1.

    The destination of the paths can be any destination that Router R1 can reach through multiple paths.

  5. Configure OSPF on the interfaces.

  6. Configure a policy that allows Router R4 to send Router R8 multiple paths to the 172.16.199.1/32 route.

    • Router R4 receives multiple paths for the 172.16.198.1/32 route and the 172.16.199.1/32 route. However, because of this policy, Router R4 only sends multiple paths for the 172.16.199.1/32 route.

    • Router R4 can also be configured to send up-to 20 BGP add-path routes for a subset of add-path advertised prefixes.

  7. Configure the autonomous system number.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Configuring Router R5

Step-by-Step Procedure

To configure Router R5:

  1. Configure the loopback (lo0) interface and the interface to Router R1.

  2. Configure BGP on Router R5’s interface.

  3. Create static routes for redistribution into BGP.

  4. Redistribute static and direct routes into BGP.

  5. Configure the autonomous system number.

  6. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Configuring Router R6

Step-by-Step Procedure

To configure Router R6:

  1. Configure the loopback (lo0) interface and the interface to Router R2.

  2. Configure BGP on Router R6’s interface.

  3. Create static routes for redistribution into BGP.

  4. Redistribute static and direct routes from Router R6’s routing table into BGP.

  5. Configure the autonomous system number.

  6. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Configuring Router R7

Step-by-Step Procedure

To configure Router R7:

  1. Configure the loopback (lo0) interface and the interface to Router R3.

  2. Configure BGP on Router R7’s interface.

  3. Create a static route for redistribution into BGP.

  4. Redistribute static and direct routes from Router R7’s routing table into BGP.

  5. Configure the autonomous system number.

  6. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Configuring Router R8

Step-by-Step Procedure

To configure Router R8:

  1. Configure the loopback (lo0) interface and the interface to Router R4.

  2. Configure BGP and OSPF on Router R8’s interface.

  3. Configure Router R8 to receive multiple paths from its neighbor, Router R4.

    The destination of the paths can be any destination that Router R4 can reach through multiple paths.

  4. Configure the autonomous system number.

  5. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, 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.

Verification

Confirm that the configuration is working properly.

Verifying That the BGP Peers Have the Ability to Send and Receive Multiple Paths

Purpose

Make sure that one or both of the following strings appear in the output of the show bgp neighbor command:

  • NLRI's for which peer can receive multiple paths: inet-unicast

  • NLRI's for which peer can send multiple paths: inet-unicast

Action

Verifying That Router R1 Is Advertising Multiple Paths

Purpose

Make sure that multiple paths to the 172.16.198.1/32 destination and multiple paths to the 172.16.199.1/32 destination are advertised to Router R4.

Action
Meaning

When you see one prefix and more than one next hop, it means that multiple paths are advertised to Router R4.

Verifying That Router R4 Is Receiving and Advertising Multiple Paths

Purpose

Make sure that multiple paths to the 172.16.199.1/32 destination are received from Router R1 and advertised to Router R8. Make sure that multiple paths to the 172.16.198.1/32 destination are received from Router R1, but only one path to this destination is advertised to Router R8.

Action
Meaning

The show route receive-protocol command shows that Router R4 receives two paths to the 172.16.198.1/32 destination and three paths to the 172.16.199.1/32 destination. The show route advertising-protocol command shows that Router R4 advertises only one path to the 172.16.198.1/32 destination and advertises all three paths to the 172.16.199.1/32 destination.

Because of the prefix policy that is applied to Router R4, Router R4 does not advertise multiple paths to the 172.16.198.1/32 destination. Router R4 advertises only one path to the 172.16.198.1/32 destination even though it receives multiple paths to this destination.

Verifying That Router R8 Is Receiving Multiple Paths

Purpose

Make sure that Router R8 receives multiple paths to the 172.16.199.1/32 destination through Router R4. Make sure that Router R8 receives only one path to the 172.16.198.1/32 destination through Router R4.

Action

Checking the Path ID

Purpose

On the downstream devices, Router R4 and Router R8, verify that a path ID uniquely identifies the path. Look for the Addpath Path ID: string.

Action

Example: Configuring Selective Advertising of BGP Multiple Paths for Load Balancing

This example shows how to configure selective advertising of BGP multiple paths. Advertising all available multiple paths might result in a large overhead of processing on device memory and is a scaling consideration, too. You can configure a BGP route reflector to advertise only contributor multipaths for load balancing.

Requirements

No special configuration beyond device initialization is required before configuring this example.

This example uses the following hardware and software components:

  • Eight routers that can be a combination of M Series, MX Series, or T Series routers

  • Junos OS Release 16.1R2 or later on the device

Overview

Beginning with Junos OS Release 16.1R2, you can restrict BGP add-path to advertise contributor multiple paths only. You can limit and configure up to six prefixes that the BGP multipath algorithm selects. Selective advertising of multiple paths facilitates Internet service providers and data centers that use route reflector to build in-path diversity in IBGP. You can enable a BGP route reflector to advertise multipaths that are contributor paths for load balancing.

Topology

In Figure 7, RR1 and RR4 are route reflectors. Router R2 and R3 are clients to the route reflector RR1. Router R8 is a client to route reflector RR4. The RR1 group with neighbors R2 and R3 is configured for multipath. Routers R5, R6, and Router R7 redistribute static routes 199.1.1.1/32 and 198.1.1.1/32 into BGP.

A load-balancing policy is configured at Router RR1 such that the 199.1.1.1/32 routes have multipath calculated. The multipath feature is configured under add-path for neighbor RR4. However, Router RR4 does not have load-balancing multipath configured. Router RR1 is configured to send Router RR4 up to six add path routes to 199.1.1.1/32 chosen from multipath candidate routes.

Figure 7: Example: Configuring Selective Advertising of BGP Multiple Paths for Load BalancingExample: Configuring Selective Advertising of BGP Multiple Paths for 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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router RR1

Router R2

Router R3

Router RR4

Router R5

Router R6

Router R7

Router R8

Configuring Router RR1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router RR1:

Note:

Repeat this procedure for other routers after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv4 addresses.

  2. Configure the loopback address.

  3. Configure interior gateway protocol (IGP) such as OSPF or IS-IS.

  4. Configure internal group rr for interfaces connecting to internal routers R2 and R3.

  5. Configure load balancing for internal BGP group rr.

  6. Configure internal group rr_rr for route reflectors.

  7. Configure the addpath multipath feature to advertise contributor multiple paths only and limit the number of advertised multipaths to 6.

  8. Configure EBGP on interfaces connecting to the external edge routers.

  9. Define a policy loadbal_199 for per packet load balancing.

  10. Apply the defined export policy loadbal_199.

  11. Configure the router ID and the autonomous system for BGP hosts.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, and show policy-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, commit the configuration.

Verification

Confirm that the configuration is working properly.

Verifying the Multipath Routes for the Static Route 199.1.1.1/32

Purpose

Verify the available multipath routes for destination 199.1.1.1/32.

Action

From operational mode, run the show route 199.1.1.1/32 detail command on Router RR1.

Meaning

The selective advertising multipath feature is enabled on Router RR1 and there is more than one nexthop available for route 199.1.1.1/32. The two available next hops for route 199.1.1.1/32 are 10.0.0.20 and 10.0.0.30.

Verifying That the Multipath Routes are Advertised from Router RR1 to Router RR4

Purpose

Verify that Router RR1 is advertising the multipath routes.

Action

From operational mode, run the show route advertising-protocol bgp 10.0.0.40 command on Router RR1.

Meaning

Router RR1 is advertising two next hops 10.0.0.20 and 10.0.0.30 for route 199.1.1.1/32 to Router RR4.

Verifying that Router RR4 Advertises One Route for 199.1.1.1/32 to Router R8

Purpose

Multipath is not configured on Router RR4, therefore route 199.1.1.1/32 is not eligible for add-path. Verify that Router RR4 advertises only one route for 199.1.1.1/32 to Router R8.

Action

From operational mode, run the show route advertising-protocol bgp 10.0.0.80 command on Router RR4.

Meaning

Since multipath is not enabled on Router RR4, only one path 10.0.0.20 is advertised to Router R8.

Example: Configuring a Routing Policy to Select and Advertise Multipaths Based on BGP Community Value

Advertising all available multiple paths might result in a large overhead of processing on device memory. If you want to advertise a limited subset of prefixes without actually knowing the prefixes in advance, you can use the BGP community value to identify prefix routes that need to be advertised to BGP neighbors. This example shows how to define a routing policy to filter and advertise multiple paths based on a known BGP community value.

Requirements

No special configuration beyond device initialization is required before configuring this example.

This example uses the following hardware and software components:

  • Eight routers that can be a combination of M Series, MX Series, or T Series routers

  • Junos OS Release 16.1R2 or later on the device

Overview

Beginning with Junos OS 16.1R2, you can define a policy to identify eligible multiple path prefixes based on community values. BGP advertises these community-tagged routes in addition to the active path to a given destination. If the community value of a route does not match the community value defined in the policy, then BGP does not advertise that route. This feature allows BGP to advertise not more than 20 paths to a given destination. You can limit and configure the number of prefixes that BGP considers for multiple paths without actually knowing the prefixes in advance. Instead, a known BGP community value determines whether or not a prefix is advertised.

Topology

In Figure 8, RR1 and RR4 are route reflectors. Router R2 and R3 are clients to the route reflector RR1. Router R8 is a client to route reflector RR4. Routers R5, R6, and Router R7 redistribute static routes into BGP. Router R5 advertises static routes 199.1.1.1/32 and 198.1.1.1/32 with community value 4713:100.

Router RR1 is configured to send up to six paths (per destination) to Router RR4. Router RR4 is configured to send up to six paths to Router R8. Router R8 is configured to receive multiple paths from Router RR4. The add-path community configuration restricts Router RR4 to send multiple paths for routes that contain only the 4713:100 community value. Router RR4 filters and advertises multipaths that contain only 4714:100 community value.

Figure 8: Example: Configuring BGP to Advertise Multipaths Based on Community ValueExample: Configuring BGP to Advertise Multipaths Based on Community Value

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router RR1

Router R2

Router R3

Router RR4

Router R5

Router R6

Router R7

Router R8

Configuring Router RR4

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router RR4:

Note:

Repeat this procedure for other routers after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the interfaces with IPv4 addresses.

  2. Configure the loopback address.

  3. Configure OSPF or any other interior gateway protocol (IGP).

  4. Configure two IBGP groups rr for route reflectors and rr_client for clients of route reflectors.

  5. Configure the feature to send multiple paths that contain 4713:100 community value only and limit the number of advertised multipaths to 6.

  6. Define a policy addpath-community-members 4713:100 to filter prefixes with the community value 4713:100 and restrict the device to send up to 16 paths to Router R8. This limit overrides the previously configured add-path send path-count of 6 at the BGP group hierarchy level.

  7. Configure the router ID and the autonomous system for BGP hosts.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, and show policy-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, commit the configuration.

Verification

Confirm that the configuration is working properly.

Verifying That the Multipath Routes are Advertised from Router RR4 to Router R8

Purpose

Verify that Router RR4 can send multiple paths to Router R8.

Action

From operational mode, run the show route advertising-protocol bgp neighbor-address command on Router RR4.

Meaning

Router RR4 is advertising multiple paths 10.0.0.20, 10.0.0.30, and 10.0.15.2 to Router R8.

Verifying That Router R8 Receives the Multipath Routes That Router RR4 Advertises

Purpose

Verify that Router R8 is receiving the multipath routes from Router RR4.

Action

From operational mode, run the show route receive-protocol bgp neighbor-address command on Router R8.

Meaning

Router R8 is receiving multiple next hops 10.0.0.20, 10.0.0.30, and 10.0.15.2 for route 199.1.1.1/32 from Router RR4.

Verifying That Router RR4 is Advertising only Multipath Routes with Community Value 4713:100 to Router R8

Purpose

Router RR4 must advertise multipath routes with community value of 4713:100 only to Router R8.

Action

From operational mode, run the show route 199.1.1.1/32 detail command on Router RR4.

Meaning

Router RR4, is advertising three paths with community value of 4713:100 to Router R8.

Configuring Recursive Resolution over BGP Multipath

Starting in Junos OS Release 17.3R1, when a BGP prefix that has a single protocol next hop is resolved over another BGP prefix that has multiple resolved paths (unilist), all the paths are selected for protocol next-hop resolution. In earlier Junos OS releases, only one of the paths is picked for protocol next-hop resolution because the resolver did not support load-balancing across all paths of the IBGP multipath route. The resolver in the routing protocol process (rpd) resolves the protocol next-hop address (PNH) into immediate forwarding next hops. The BGP recursive resolution feature enhances the resolver to resolve routes over IBGP multipath route and use all the feasible paths as next hops. This feature benefits densely connected networks where BGP is used to establish infrastructure connectivity such as WAN networks with high equal-cost multipath and seamless MPLS topology.

Before you begin configuring recursive resolution of BGP multipath, you must do the following:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure MPLS and LDP.

  4. Configure BGP.

To configure recursive resolution over multipath,

  1. Define a policy that includes the multipath-resolve action .
  2. Import the policy to resolve all the available paths of IBGP multipath route.
  3. Verify that BGP is resolving multipaths recursively and multiple next hops are available for load balancing traffic.

    From operational mode, enter the show route resolution detail command:

Configuring ECMP Next Hops for RSVP and LDP LSPs for Load Balancing

The Junos OS supports configurations of 16, 32, 64, or 128 equal-cost multipath (ECMP) next hops for RSVP and LDP LSP.s. For networks with high-volume traffic, this provides more flexibility to load-balance the traffic over as many as 128 LSPs.

To configure the maximum limit for ECMP next hops, include the maximum-ecmp next-hops statement at the [edit chassis] hierarchy level:

You can configure a maximum ECMP next-hop limit of 16, 32, 64, or 128 using this statement. The default limit is 16.

Note:

MX Series routers with one or more Modular Port Concentrator (MPC) cards and with Junos OS 11.4 or earlier installed, support the configuration of the maximum-ecmp statement with only 16 next hops. You should not configure the maximum-ecmp statement with 32 or 64 next hops. When you commit the configuration with 32 or 64 next hops, the following warning message appears:

Error: Number of members in Unilist NH exceeds the maximum supported 16 on Trio.

The following types of routes support the ECMP maximum next-hop configuration for as many as 128 ECMP gateways:

  • Static IPv4 and IPv6 routes with direct and indirect next-hop ECMPs

  • LDP ingress and transit routes learned through associated IGP routes

  • RSVP ECMP next hops created for LSPs

  • OSPF IPv4 and IPv6 route ECMPs

  • IS-IS IPv4 and IPv6 route ECMPs

  • EBGP IPv4 and IPv6 route ECMPs

  • IBGP (resolving over IGP routes) IPv4 and IPv6 route ECMPs

The enhanced ECMP limit of up to 128 ECMP next hops is also applicable for Layer 3 VPNs, Layer 2 VPNs, Layer 2 circuits, and VPLS services that resolve over an MPLS route, because the available ECMP paths in the MPLS route can also be used by such traffic.

Note:
Note:

If RSVP LSPs are configured with bandwidth allocation, for ECMP next hops with more than 16 LSPs, traffic is not distributed optimally based on bandwidths configured. Some LSPs with smaller allocated bandwidths receive more traffic than the ones configured with higher bandwidths. Traffic distribution does not strictly comply with the configured bandwidth allocation. This caveat is applicable to the following routers:

  • MX Series routers with all types of FPCs and DPCs, excluding MPCs. This caveat is not applicable to MX Series routers with line cards based on the Junos Trio chipset.

To view the details of the ECMP next hops, issue the show route command. The show route summary command also shows the current configuration for the maximum ECMP limit. To view details of the ECMP LDP paths, issue the traceroute mpls ldp command.

Configuring Consistent Load Balancing for ECMP Groups

Per-packet load balancing allows you to spread traffic across multiple equal-cost paths. By default, when a failure occurs in one or more paths, the hashing algorithm recalculates the next hop for all paths, typically resulting in the redistribution of all flows. Consistent load balancing enables you to override this behavior so that only flows for links that are inactive are redirected. All existing active flows are maintained without disruption. In a data center environment, the redistribution of all flows when a link fails potentially results in significant traffic loss or a loss of service to servers whose links remain active. Consistent load balancing maintains all active links and instead remaps only those flows affected by one or more link failures. This feature ensures that flows connected to links that remain active continue uninterrupted.

This feature applies to topologies where members of an equal-cost multipath (ECMP) group are external BGP neighbors in a single-hop BGP session. Consistent load balancing does not apply when you add a new ECMP path or modify an existing path in any way. To add a new path with minimal disruption, define a new ECMP group without modifying the existing paths. In this way, clients can be moved to the new group gradually without terminating existing connections.

  • (On MX Series) Only Modular Port Concentrators (MPCs) are supported.

  • Both IPv4 and IPv6 paths are supported.

  • ECMP groups that are part of a virtual routing and forwarding (VRF) instance or other routing instance are also supported.

  • Multicast traffic is not supported.

  • Aggregated interfaces are supported, but consistent load balancing is not supported among members of the link aggregation (LAG) bundle. Traffic from active members of the LAG bundle might be moved to another active member when one or more member links fail. Flows are rehashed when one or more LAG member links fail.

  • We strongly recommend that you apply consistent load balancing to no more than a maximum of 1,000 IP prefixes per router or switch.

  • Layer 3 adjacency over integrated routing and bridging (IRB) interfaces is supported.

You can configure the BGP add-path feature to enable replacement of a failed path with a new active path when one or more paths in the ECMP group fail. Configuring replacement of failed paths ensures that traffic flow on the failed paths only are redirected. Traffic flow on active paths will remain unaltered.

Note:
  • When you configure consistent load balancing on generic routing encapsulation (GRE) tunnel interfaces, you must specify the inet address of the far end GRE interface so that the Layer 3 adjacencies over the GRE tunnel interfaces are installed correctly in the forwarding table. However, ECMP fast reroute (FRR) over GRE tunnel interfaces is not supported during consistent load balancing. You can specify the destination address on the router configured with consistent load balancing at the [edit interfaces interface name unit unit name family inet address address] hierarchy level. For example:

    For more information on generic routing encapsulation see Configuring Generic Routing Encapsulation Tunneling.

  • Consistent load balancing does not support BGP multihop for EBGP neighbors. Therefore, do not enable the multihop option on devices configured with consistent load balancing.

To configure consistent load balancing for ECMP groups:

  1. Configure BGP and enable the BGP group of external peers to use multiple paths.
  2. Create a routing policy to match incoming routes to one or more destination prefixes.
  3. Apply consistent load balancing to the routing policy so that only traffic flows to one or more destination prefixes that experience a link failure are redirected to an active link.
  4. Create a separate routing policy and enable per-packet load balancing.
    Note:

    You must configure and apply a per-packet load-balancing policy to install all routes in the forwarding table.

  5. Apply the routing policy for consistent load balancing to the BGP group of external peers.
    Note:

    Consistent load balancing can be applied only to BGP external peers. This policy cannot be applied globally.

  6. (Optional) Enable bidirectional forwarding detection (BFD) for each external BGP neighbor.
    Note:

    This step shows the minimum BFD configuration required. You can configure additional options for BFD.

  7. Apply the per-prefix load-balancing policy globally to install all next-hop routes in the forwarding table.
  8. (Optional) Enable fast reroute for ECMP routes.
  9. Verify the status of one or more ECMP routes for which you enabled consistent load balancing.

    The output of the command displays the following flag when consistent load balancing is enabled:State: <Active Ext LoadBalConsistentHash>

Understanding Entropy Label for BGP Labeled Unicast LSP

What Is an Entropy Label?

An entropy label is a special load-balancing label that enhances the router’s ability to load-balance traffic across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs). The entropy label allows routers to efficiently load-balance traffic using just the label stack rather than deep packet inspection (DPI). DPI requires more of the router’s processing power and is not a capability shared by all routers.

When an IP packet has multiple paths to reach its destination, Junos OS uses certain fields of the packet headers to hash the packet to a deterministic path. The source or destination addresses and port numbers of the packet are used to hash, in order to avoid packet reordering of a given flow. If a core label-switching router (LSR) is not capable of performing a DPI to identify the flow or can not do so at line rate, the label stack alone is used for ECMP hashing. This requires an entropy label, a special load-balancing label that can carry the flow information. The ingress LSR has more context and information about incoming packets than transit LSRs. Therefore, the ingress label edge router (LER) can inspect the flow information of a packet, map it to an entropy label, and insert it into the label stack. LSRs in the core simply use the entropy label as the key to hash the packet to the right path.

An entropy label can be any label value between 16 to 1048575 (regular 20-bit label range). Since this range overlaps with the existing regular label range, a special label called entropy label indicator (ELI) is inserted before the entropy label. ELI is a special label assigned by IANA with the value of 7.

Figure 9 illustrates the entropy label in an RSVP label-switched path (LSP) packet label stack. The label stack consists of the entropy label indicator (ELI), the entropy label, and the IP packet.

Figure 9: Entropy Label for RSVP LSPEntropy Label for RSVP LSP

Entropy Label for BGP Labeled Unicast

BGP labeled unicasts concatenate RSVP or LDP LSPs across multiple interior gateway protocol (IGP) areas or multiple autonomous systems (inter-AS LSPs). Inter-area BGP labeled unicast LSPs usually carry VPN and IP traffic when ingress PEs and egress PEs are in different IGP areas. When BGP labeled unicasts concatenate RSVP or LDP LSPs, Junos OS inserts the entropy labels at the BGP labeled unicast LSP ingress to achieve end-to-end entropy label load balancing. This is because RSVP or LDP entropy labels are usually popped at the penultimate hop node, together with the RSVP or LDP label, and there are no entropy labels at the stitching points, that is, the routers between two areas or two ASs. Therefore, in the absence of entropy labels, the router at the stitching point uses the BGP labels to forward packets. Figure 10 illustrates the BGP labeled unicast packet label stack with the entropy label in an RSVP label stack. The RSVP label stack consists of the entropy label indicator (ELI), the entropy label, the BGP label, and the IP packet. The RSVP entropy labels are popped at the penultimate hop node.

Figure 10: Inter-Area BGP Labeled Unicast with RSVP Entropy LabelInter-Area BGP Labeled Unicast with RSVP Entropy Label

The BGP labeled unicast stitching node cannot use the entropy labels for load balancing unless the stitching node signals the entropy label capability at the BGP egress. If the BGP labeled unicast stitching node signals BGP entropy label capability (ELC) to the provider edge routers, the BGP labeled unicast LSP ingress is aware that the BGP labeled unicast LSP egress can handle entropy labels and inserts an entropy label indicator and entropy label underneath the BGP label. All of the LSRs are able to use the entropy label for load balancing. While BGP labeled unicast LSP might cross many routers in different areas and ASs, it is possible that some of the segments might support entropy labels while others might not. Figure 11 illustrates the entropy label in the BGP label stack. The label stack at the stitching node consists of the ELI, the entropy label, and the IP packet.

Figure 11: Inter-Area BGP Labeled Unicast with BGP Entropy Label at Stitching PointInter-Area BGP Labeled Unicast with BGP Entropy Label at Stitching Point
Note:

To disable entropy label capability for BGP labeled unicast at the egress node, define a policy with the option no-entropy-label-capability at the [edit policy-options policy-statement policy-name then] hierarchy level.

By default, routers that support entropy labels are configured with the load-balance-label-capability statement at the [edit forwarding-options] hierarchy level to signal the labels on a per-LSP basis. If the peer router is not equipped to handle load-balancing labels, you can prevent the signaling of entropy label capability by configuring the no-load-balance-label-capability statement at the [edit forwarding-options] hierarchy level.

By default, a BGP speaker uses the Entropy Label Capability (ELCv3) attribute defined within the IETF BGP Router Capability Attribute (RCA) for load balancing. It sends and receives only the ELCv3 attribute. If you need to use the ELCv2 attribute interoperable with the RCA draft, explicitly configure the elc-v2-compatible knob at the labeled-unicast entropy-label hierarchy. In such a scenario, both ELCv3 and ELCv2 are sent and received.

Supported and Unsupported Features

Junos OS supports an entropy label for BGP labeled unicast in the following scenarios:

  • All the nodes of the LSPs have entropy label capability.

  • Some of the nodes of the LSPs have entropy label capability.

  • The LSPs tunnel through another carrier’s VPN.

  • Define an ingress policy to select a subset of BGP labeled unicast LSPs to insert an entropy label at ingress.

  • Define an egress policy to disable entropy label capability advertisement.

Junos OS does not support the following features for an entropy label for BGP labeled unicast:

  • When BGP labeled unicast LSPs are tunneling through another carrier’s VPN, there is no true end-to-end entropy label because Junos OS does not insert an entropy label indicator or entropy label underneath VPN labels at the carrier-of-carriers network.

  • Currently, Junos OS does not support IPv6 BGP labeled unicast LSPs with their own entropy labels. However, IPv6 BGP labeled unicast LSPs might use the entropy labels from the underlying RSVP, LDP, or BGP LSPs.

Configuring an Entropy Label for a BGP Labeled Unicast LSP

Configure an entropy label for BGP labeled unicast LSP to achieve end-to-end entropy label load balancing. An entropy label is a special load-balancing label that can carry the flow information of the packets. BGP labeled unicasts generally concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems (ASs). RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. This feature enables the use of an entropy label at the stitching point, that is, the routers between two areas or ASs, to achieve end-to-end entropy label load balancing for BGP traffic. This feature enables the insertion of entropy labels at the BGP labeled unicast LSP ingress.

An entropy label can be any label value between 16 to 1048575 (regular 20-bit label range). Since this range overlaps with the existing regular label range, a special label called entropy label indicator (ELI) is inserted before the entropy label. ELI is a special label assigned by IANA with the value of 7.

Before you configure an entropy label for BGP labeled unicast, make sure you:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure BGP.

  4. Configure LDP.

  5. Configure RSVP.

  6. Configure MPLS.

To configure an entropy label for BGP labeled unicast LSP:

  1. On the ingress router, include the entropy-label statement at the [edit protocols bgp family inet labeled-unicast] hierarchy level to enable entropy label capability for BGP labeled unicast at a global level.

    You can also enable the use of an entropy label at a BGP group or a specific BGP neighbor level by including the entropy-label statement at the [edit protocols bgp group group name family inet labeled-unicast] or [edit protocols bgp group group name neighbor address labeled-unicast] hierarchy level.

  2. (Optional) Specify an additional policy to define the routes that have the entropy label capability.

    Apply the policy at the ingress router.

  3. (Optional) Include the option no-next-hop-validation if you do not want Junos OS to validate the next-hop field in the entropy label capability attribute against the route next hop.
  4. (Optional) To explicitly disable advertising entropy label capability on the egress router, define a policy with the no-entropy-label-capability option for routes specified in the policy, and include the no-entropy-label-capability option in the specified policy at the [edit policy-options policy statement policy-name then] hierarchy level.

Example: Configuring an Entropy Label for a BGP Labeled Unicast LSP

This example shows how to configure an entropy label for a BGP labeled unicast to achieve end-to-end load balancing using entropy labels. When an IP packet has multiple paths to reach its destination, Junos OS uses certain fields of the packet headers to hash the packet to a deterministic path. This requires an entropy label, a special load-balancing label that can carry the flow information. LSRs in the core simply use the entropy label as the key to hash the packet to the correct path. An entropy label can be any label value between 16 to 1048575 (regular 20-bit label range). Since this range overlaps with the existing regular label range, a special label called entropy label indicator (ELI) is inserted before the entropy label. ELI is a special label assigned by IANA with the value of 7.

BGP labeled unicasts generally concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems. RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. This feature enables the use of entropy labels at the stitching points to bridge the gap between the penultimate hop node and the stitching point, in order to achieve end-to-end entropy label load balancing for BGP traffic.

Requirements

This example uses the following hardware and software components:

  • Seven MX Series routers with MPCs

  • Junos OS Release 15.1 or later running on all the devices

    • Revalidated using Junos OS Relese 22.4

Before you configure an entropy label for BGP labeled unicast, make sure you:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure BGP.

  4. Configure RSVP.

  5. Configure MPLS.

Overview

When BGP labeled unicasts concatenate RSVP or LDP LSPs across multiple IGP areas or multiple autonomous systems, RSVP or LDP entropy labels are popped at the penultimate hop node, together with the RSVP or LDP label. However, there are no entropy labels at the stitching points, that is, the routers between two areas. Therefore, the routers at the stitching points used the BGP labels to forward packets.

Beginning with Junos OS Release 15.1, you can configure an entropy label for BGP labeled unicast to achieve end-to-end entropy label load balancing. This feature enables the use of an entropy label at the stitching points in order to achieve end-to-end entropy label load balancing for BGP traffic. Junos OS allows the insertion of entropy labels at the BGP labeled unicast LSP ingress.

By default, routers that support entropy labels are configured with the load-balance-label-capability statement at the [edit forwarding-options] hierarchy level to signal the labels on a per-LSP basis. If the peer router is not equipped to handle load-balancing labels, you can prevent the signaling of entropy label capability by configuring the no-load-balance-label-capability at the [edit forwarding-options] hierarchy level.

Note:

You can explicitly disable advertising entropy label capability at egress for routes specified in the policy with the no-entropy-label-capability option at the [edit policy-options policy-statement policy name then] hierarchy level.

Topology

In Figure 12 , Router PE1 is the ingress router and Router PE2 is the egress router. Routers P1 and P2 are the transit routers. Router ABR is the area bridge router between Area 0 and Area 1. Two LSPs are configured on the ABR to PE2 for load balancing the traffic. Entropy label capability for BGP labeled unicast is enabled on the ingress Router PE1. Host 1 is connected to P1 for packet captures so that we can show the entropy label.

Figure 12: Configuring an Entropy Label for BGP Labeled UnicastConfiguring an Entropy Label for BGP Labeled Unicast

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router CE1

Router PE1

Router P1

Router ABR

Router P2

Router PE2

Router CE2

Configuring Router PE1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router PE1:

Note:

Repeat this procedure for Router PE2 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the physical interfaces. Ensure to configure family mpls on the core facing interface.

  2. Configure the loopback interfaces. The secondary loopback is optional and is applied under the routing instance in a later step.

  3. Configure the router ID and the autonomous system number.

  4. Configure the OSPF protocol.

  5. Configure the RSVP protocol.

  6. Configure the MPLS protocol and an LSP towards the ABR. Include the entropy-label option to add the entropy label to the MPLS label stack.

  7. Configure IBGP using family inet labeled-unicast for the ABR peering and family inet-vpn for the PE2 peering. Enable entropy label capability for BGP labeled unicast.

  8. Define a policy to export BGP VPN routes into OSPF. The policy is applied under OSPF in the routing instance.

  9. Define a load balancing policy and apply it under the routing-options forwarding-table. PE1 only has one path in the example therefore this step is not needed, but for this example we are applying the same load balancing policy on all devices.

  10. Configure the Layer 3 VPN routing instance.

  11. Assign the interfaces to the routing instance.

  12. Configure the route distinguisher for the routing instance.

  13. Configure a VPN routing and forwarding (VRF) target for the routing instance.

  14. Configure the protocol OSPF under the routing instance and apply the previously configured bgp-to-ospf policy.

Configuring Router P1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router P1:

Note:

Repeat this procedure for Router P2 after modifying the appropriate interface names, addresses, and other parameters.

  1. Configure the physical interfaces.

  2. Configure the loopback interface.

  3. Configure the router ID.

  4. Configure the OSPF protocol.

  5. Configure the RSVP protocol.

  6. Configure the MPLS protocol.

Configuring Router ABR

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router ABR:

  1. Configure the physical interfaces.

  2. Configure the loopback interface.

  3. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing.

  4. Configure the router ID and the autonomous system number.

  5. Configure the OSPF protocol.

  6. Configure the RSVP protocol.

  7. Configure the MPLS protocol and specify the LSPs towards PE1 and PE2. Two LSPs are created towards PE2 for the purpose of load balancing traffic to show different LSPs and interfaces are used.

  8. Configure IBGP to both PE1 and PE2 using family inet labeled-unicast. Apply the policy to advertise the inet.3 loopback route from both PE1 and PE2. We show the policy in the next step.

  9. Define a policy to match on the loopback addresses for PE1 and PE2.

  10. Define a policy for load balancing and apply it under the routing-options forwarding-table.

(Optional) Port-Mirroring Configuration

To see the entropy label that is applied you can capture the traffic. In this example a filter is applied on the PE1 facing interface on P1 to capture the CE1 to CE2 traffic. The traffic is sent to Host 1 for viewing. There are different ways to capture traffic than what we use in this example. For more information see Understanding Port Mirroring and Analyzers.

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router P1:

  1. Configure the interfaces. In this example we are putting the interface connected to Host1 in a bridge domain and creating an IRB interface for verifying connectivity to Host1.

  2. Configure the bridge domain.

  3. Configure a filter to capture the traffic. For this example we are capturing all traffic.

  4. Apply the filter to the PE1 facing interface.

  5. Configure the port mirroring options. For this example we are mirroring all traffic and sending it to Host1 connected to interface ge-0/0/4.

Verification

Confirm that the configuration is working properly.

Verifying That the Entropy Label Capability Is Being Advertised

Purpose

Verify that the entropy label capability path attribute is being advertised from the ABR to PE1 for the route to PE2.

Action

From operational mode, run the show route advertising-protocol bgp 10.1.255.2 detail command on Router ABR.

Meaning

The output shows that the host PE2 with the IP address of 10.1.255.6 has the entropy label capability and the route label that is used. The host is advertising the entropy label capability to its BGP neighbors.

Verifying That Router PE1 Receives the Entropy Label Advertisement

Purpose

Verify that Router PE1 receives the entropy label advertisement for Router PE2.

Action

From operational mode, run the show route protocol bgp 10.1.255.6 extensive command on Router PE1.

Meaning

Router PE1 receives the entropy label capability advertisement from its BGP neighbor.

Verifying ECMP at the ABR to PE2

Purpose

Verify equal-cost multipath (ECMP) to PE2.

Action

From operational mode, run the show route table mpls.0 and show route forwarding-table label <label>commands on Router ABR.

Meaning

The output shows an ECMP for the label used for the BGP labeled unicast route.

Show Routes to CE2 on PE1

Purpose

Verify the routes to CE2.

Action

From operational mode, run the show route table VPN-l3vpn.inet.0 172.16.255.7 extensive and show route table VPN-l3vpn.inet.0 192.168.255.7 extensivecommands on Router PE1.

Meaning

The output shows the same labels are used for both routes.

Ping CE2 from CE1

Purpose

Verify connectivity and to use for verifying load balancing.

Action

From operational mode, run the ping 172.16.255.7 source 172.16.12.1 rapid count 100 and ping 192.168.255.7 source 192.168.255.1 rapid count 200commands on Router PE1.

Meaning

The output shows pings are successful.

Verify Load Balancing

Purpose

Verify load balancing.

Action

From operational mode, run the show mpls lsp ingress statistics command on the ABR.

Meaning

The output shows the first ping from the previous command used LSP abr-pe2-2 and the second ping used LSP abr-pe2.

Verify the Entropy Label

Purpose

Verify the entropy label is different between the pings that were used.

Action

On Host 1, run the tcpdump -i eth1 -n.

Meaning

The output shows the different value for the entropy label for the two different ping commands.

Use Case for BGP Prefix Independent Convergence for Inet, Inet6, or Labeled Unicast

In the instance of a router failure, a BGP network can take from a few seconds to minutes to recover, depending on parameters such as the size of the network or router performance. When the BGP Prefix Independent Convergence (PIC) feature is enabled on a router, BGP installs to the Packet Forwarding Engine the second best path in addition to the calculated best path to a destination. The router uses this backup path when an egress router fails in a network and drastically reduces the outage time. You can enable this feature to reduce the network downtime if the egress router fails.

When reachability to an egress router in a network fails, the IGP detects this outage, and the link state propagates this information throughout the network and advertises the BGP next hop for that prefix as unreachable. BGP reevaluates alternative paths and if an alternative path is available, reinstalls this alternate next hop into the Packet Forwarding Engine. This kind of egress failure usually impacts multiple prefixes at the same time, and BGP has to update all these prefixes one at a time. On the ingress routers, the IGP completes the shortest path first (SPF) and updates the next hops. Junos OS then determines the prefixes that have become unreachable and signals to the protocol that these need to be updated. BGP gets the notification and updates the next hop for every prefix that is now invalid. This process could impact the connectivity and could take a few minutes to recover from the outage. BGP PIC can reduce this down time as the backup path is already installed in the Packet Forwarding Engine.

Beginning with Junos OS Release 15.1, the BGP PIC feature, which was initially supported for Layer 3 VPN routers, is extended to BGP with multiple routes in the global tables such as inet and inet6 unicast, and inet and inet6 labeled unicast. On a BGP PIC enabled router, Junos OS installs the backup path for the indirect next hop on the Routing Engine and also provides this route to the Packet Forwarding Engine and IGP. When an IGP loses reachability to a prefix with one or more routes, it signals to the Routing Engine with a single message prior to updating the routing tables. The Routing Engine signals to the Packet Forwarding Engine that an indirect next hop has failed, and traffic must be rerouted using the backup path. Routing to the impacted destination prefix continues using the backup path even before BGP starts recalculating the new next hops for the BGP prefixes. The router uses this backup path to reduce traffic loss until the global convergence through the BGP is resolved.

The time at which the outage occurs to the time until the loss of reachability is signaled actually depends on the failure detection time of the nearest router and the IGP convergence time. Once the local router detects the outage, the route convergence without the BGP PIC feature enabled depends heavily on the number of prefixes affected and the performance of the router due to recalculation of each affected prefix. However, with the BGP PIC feature enabled, even before BGP recalculates the best path for those affected prefixes, the Routing Engine signals the data plane to switch to the standby next best path. Hence traffic loss is minimum. The new routes are calculated even while the traffic is being forwarded, and these new routes are pushed down to the data plane. Therefore, the number of BGP prefixes affected does not impact the time taken from the time traffic outage occurs to the point of time at which BGP signals the loss of reachability.

Configuring BGP Prefix Independent Convergence for Inet

On a BGP Prefix Independent Convergence (PIC) enabled router, Junos OS installs the backup path for the indirect next hop on the Routing Engine and also provides this route to the Packet Forwarding Engine and IGP. When an IGP loses reachability to a prefix with one or more routes, it signals to the Routing Engine with a single message prior to updating the routing tables. The Routing Engine signals to the Packet Forwarding Engine that an indirect next hop has failed, and traffic must be rerouted using the backup path. Routing to the impacted destination prefix continues using the backup path even before BGP starts recalculating the new next hops for the BGP prefixes. The router uses this backup path to reduce traffic loss until the global convergence through the BGP is resolved. The BGP PIC feature, which was initially supported for Layer 3 VPN routers, is extended to BGP with multiple routes in the global tables such as inet and inet6 unicast, and inet and inet6 labeled unicast.

Before you begin:

  1. Configure the device interfaces.

  2. Configure OSPF or any other IGP protocol.

  3. Configure MPLS and LDP.

  4. Configure BGP.

Note:

The BGP PIC feature is supported only on routers with MPC interfaces.

Best Practice:

On routers with Modular Port Concentrators (MPCs), enable enhanced IP network services as shown here:

To configure BGP PIC for inet:

  1. Enable BGP PIC for inet.
    Note:

    The BGP PIC edge feature is supported only on routers with MPC interfaces.

  2. Configure per-packet load balancing.
  3. Apply the per-packet load-balancing policy to routes exported from the routing table to the forwarding table.
  4. Verify that BGP PIC is working.

    From operational mode, enter the show route extensive command:

    The output lines that contain Indirect next hop: weight follow next hops that the software can use to repair paths where a link failure occurs. The next-hop weight has one of the following values:

    • 0x1 indicates active next hops.

    • 0x4000 indicates passive next hops.

Example: Configuring BGP Prefix Independent Convergence for Inet

This example shows how to configure BGP PIC for inet. In the instance of a router failure, a BGP network can take from a few seconds to minutes to recover, depending on parameters such as the size of the network or router performance. When the BGP Prefix Independent Convergence (PIC) feature is enabled on a router, BGP with multiple routes in the global tables, such as inet and inet6 unicast, and inet and inet6 labeled unicast, installs to the Packet Forwarding Engine the second best path in addition to the calculated best path to a destination. The router uses this backup path when an egress router fails in a network and drastically reduces the outage time.

Requirements

No special configuration beyond device initialization is required before configuring this example.

This example uses the following hardware and software components:

  • One MX Series router with MPCs to configure the BGP PIC feature

  • Seven routers that can be a combination of M Series, MX Series, T Series, or PTX Series routers

  • Junos OS Release 15.1 or later on the device with BGP PIC configured

Overview

Beginning with Junos OS Release 15.1, BGP PIC, which was initially supported for Layer 3 VPN routers, is extended to BGP with multiple routes in the global tables such as inet and inet6 unicast, and inet and inet6 labeled unicast. BGP installs to the Packet Forwarding Engine the second best path in addition to the calculated best path to a destination. When an IGP loses reachability to a prefix, the router uses this backup path to reduce traffic loss until the global convergence through the BGP is resolved, thereby reducing the outage duration.

Note:

The BGP PIC feature is supported only on routers with MPCs.

Topology

This example shows three customer edge (CE) routers, Device CE0, CE1, and CE2. Routers PE0, PE1, and PE2 are the provider edge (PE) routers. Router P0 and P1 are the provider core routers. BGP PIC is configured on Router PE0. For testing, the address 192.168.1.5 is added as a second loopback interface address on Device CE1. The address is announced to Routers PE1 and PE2 and is relayed by the internal BGP (IBGP) to Router PE0. On Router PE0, there are two paths to the 192.168.1.5 network. These are the primary path and a backup path. Figure 13 shows the sample network.

Figure 13: Configuring BGP PIC for InetConfiguring BGP PIC for Inet

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Router PE0

Router P0

Router P1

Router PE1

Router PE2

Device CE0

Device CE1

Device CE2

Configuring Device PE0

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device PE0:

  1. On routers with Modular Port Concentrators (MPCs), enable enhanced IP network services.

  2. Configure the device interfaces.

  3. Configure the loopback interface.

  4. Configure MPLS and LDP on all interfaces excluding the management interface.

  5. Configure an IGP on the core-facing interfaces.

  6. Configure IBGP connections with the other PE devices.

  7. Configure EBGP connections with the customer devices.

  8. Configure the load-balancing policy.

  9. Configure a next-hop self policy.

  10. Enable the BGP PIC edge feature.

  11. Apply the load-balancing policy.

  12. Assign the router ID and autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show chassis, show interfaces, 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.

Verification

Confirm that the configuration is working properly.

Displaying Extensive Route Information

Purpose

Confirm that BGP PIC edge is working.

Action

From Device PE0, run the show route extensive command.

Meaning

Junos OS uses the next hops and the weight values to select a backup path when a link failure occurs. The next-hop weight has one of the following values:

  • 0x1 indicates the primary path with active next hops.

  • 0x4000 indicates the backup path with passive next hops.

Displaying the Forwarding Table

Purpose

Check the forwarding and kernel routing-table state by using the show route forwarding-table command.

Action

From Device PE0, run the show route forwarding-table destination 192.168.1.5 extensive command.

Meaning

Junos OS uses the next hops and the weight values to select a backup path when a link failure occurs. The next-hop weight has one of the following values:

  • 0x1 indicates the primary path with active next hops.

  • 0x4000 indicates the backup path with passive next hops.

BGP PIC Edge Using BGP Labeled Unicast Overview

This section talks about the benefits and overview of BGP PIC Edge using BGP labeled unicast as the transport protocol.

Benefits of BGP PIC Edge Using BGP Labeled Unicast

This feature provides the following benefits:

  • Provides traffic protection in case of border (ABR and ASBR) node failures in multi-domain networks.

  • Provides faster restoration of network connectivity and reduces traffic loss if the primary path becomes unavailable.

How does BGP Prefix Independent Convergence Work?

BGP Prefix Independent Convergence (PIC) improves BGP convergence on network node failures. BGP PIC creates and stores primary and backup paths for the indirect next hop on the Routing Engine and also provides the indirect next hop route information to the Packet Forwarding Engine. When a network node failure occurs, the Routing Engine signals the Packet Forwarding Engine that an indirect next hop has failed, and that the traffic is rerouted to a pre-calculated equal-cost or backup path without modifying BGP prefixes. Routing the traffic to the destination prefix continues by using the backup path to reduce traffic loss until the global convergence through BGP is resolved.

BGP convergence is applicable to both core and edge network node failures. In the case of BGP PIC Core, adjustments to the forwarding chains are made as a result of node or core link failures. In the case of BGP PIC Edge, adjustments to the forwarding chains are made as a result of edge node or edge link failures.

BGP PIC Edge Using BGP Labeled Unicast as the Transport Protocol

BGP PIC Edge using the BGP labeled unicast transport protocol helps to protect and reroute traffic when border nodes (ABR and ASBR) failures happen in multi-domain networks. Multi-domain networks are typically used in Metro Ethernet aggregation and mobile backhaul network designs.

On Juniper Networks MX Series, EX Series, and PTX Series devices, BGP PIC Edge supports Layer 3 services with BGP labeled unicast as the transport protocol. Additionally, on Juniper Networks MX Series, EX9204, EX9208, EX9214, EX9251, and EX9253 devices, BGP PIC Edge supports Layer 2 circuit, Layer 2 VPN, and VPLS (BGP VPLS, LDP VPLS and FEC 129 VPLS) services with BGP labeled unicast as transport protocol. These BGP services are multipath (learned from multiple PEs) and resolved through BGP labeled unicast routes, which could again be a multipath learnt from other ABRs. Transport protocols supported over BGP PIC Edge are RSVP, LDP, OSPF, and ISIS. Starting from Junos OS Release 20.2R1, MX Series, EX9204, EX9208, EX9214, EX9251, and EX9253 devices support BGP PIC Edge protection for Layer 2 circuit, Layer 2 VPN, and VPLS (BGP VPLS, LDP VPLS and FEC 129 VPLS) services with BGP labeled unicast as the transport protocol.

On Juniper Networks MX Series, EX Series and PTX Series devices, BGP PIC Edge protection with BGP labeled unicast as the transport is supported for the following services:

  • IPv4 services over IPv4 BGP labeled unicast

  • IPv6 BGP labeled unicast service over IPv4 BGP labeled unicast

  • IPv4 Layer 3 VPN services over IPv4 BGP labeled unicast

  • IPv6 Layer 3 VPN services over IPv4 BGP labeled unicast

On Juniper Networks MX Series and EX Series devices, BGP PIC Edge protection with BGP labeled unicast as the transport is supported for the following services:

  • Layer 2 circuit services over IPv4 BGP labeled unicast

  • Layer 2 VPN services over IPv4 BGP labeled unicast

  • VPLS (BGP VPLS, LDP VPLS, and FEC 129 VPLS) services over IPv4 BGP labeled unicast

Configuring BGP PIC Edge Using BGP Labeled Unicast for Layer 2 Services

MX Series, EX9204, EX9208, EX9214, EX9251, and EX9253 devices support BGP PIC Edge protection for Layer 2 circuit, Layer 2 VPN, and VPLS (BGP VPLS, LDP VPLS and FEC 129 VPLS) services with BGP labeled unicast as the transport protocol. BGP PIC Edge using the BGP labeled unicast transport protocol helps to protect traffic failures over border nodes (ABR and ASBR) in multi-domain networks. Multi-domain networks are typically used in metro-aggregation and mobile backhaul networks designs.

A prerequisite for BGP PIC Edge protection is to program the Packet Forwarding Engine (PFE) with expanded next-hop hierarchy.

To enable expanded next-hop hierarchy for BGP labeled unicast family, you need to configure the following CLI configuration statement at the [edit protocols] hierarchy level:

To enable BGP PIC for MPLS load balance nexthops, you need to configure the following CLI configuration statement at the [edit routing-options] hierarchy level:

To enable fast convergence for Layer 2 services, you need to configure the following CLI configuration statements at the [edit protocols] hierarchy level:

For Layer 2 circuit and LDP VPLS:

For Layer 2 VPN, BGP VPLS, and FEC129:

Example: Protecting IPv4 Traffic over Layer 3 VPN Running BGP Labeled Unicast

This example shows how to configure BGP prefix-independent convergence (PIC) edge labeled unicast and protect IPv4 traffic over Layer 3 VPN. When an IPv4 traffic from a CE router is sent to a PE router, the IPv4 traffic is routed over a Layer 3 VPN, where BGP labeled unicast is configured as the transport protocol.

Requirements

This example uses the following hardware and software components:

  • MX Series routers.

  • Junos OS Release 19.4R1 or later running on all devices.

Overview

The following topology provides both ABR and ASBR protection by switching the traffic to backup paths whenever the primary path becomes unavailable.

Topology

Figure 14 illustrates Layer 3 VPN running BGP labeled unicast as the inter-domain transport protocol.

Figure 14: Layer 3 VPN over BGP Labeled Unicast Using LDP Transport Protocol
Topology

The following table describes the components used in the topology:

Primary Components

Device Type

Position

CE1

MX Series

Connected to customer network.

PE1

MX Series

Configured with primary and backup routing paths to protect and reroute traffic from CE1 to CE2.

P1-P3

MX Series

Core routers to transport traffic.

ABR1-ABR2

MX Series

Area border routers

ABSR1-ABSR4

MX Series

Autonomous System Boundary Router

RR1-RR3

MX Series

Route Reflector

PE2-PE3

MX Series

PE routers connected to customer edge router (CE2).

CE2

MX Series

Connected to customer network.

PE2 and PE3 device addresses are learned from both ABR1 and ABR2 as labeled unicast routes. These routes are resolved over IGP/LDP protocols. PE1 learns CE2 routes from both PE2 and PE3 devices.

Configuration

To configure BGP PIC Edge using BGP Label Unicast with LDP as the transport protocol, perform these tasks:

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Device CE1

Device PE1

Device P1

Device RR1

Device ABR1

Device ABR2

Device P2

Device RR2

Device ASBR1

Device ASBR2

Device ASBR3

Device ASBR4

Device RR3

Device P3

Device PE2

Device PE3

Device CE2

Configuring CE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device CE1:

  1. Configure the interfaces to enable IP and MPLS transport.

  2. Configure the loopback interface to be used as router ID and termination interface for LDP and BGP sessions.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Configure routing options.

  5. Configure BGP labeled unicast to ABRs to exchange loopback IP addresses as BGP labeled unicast prefixes.

Results

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

Configuring PE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device PE1:

  1. Configure the interfaces to enable IP and MPLS transport.

  2. Configure the loopback interface to be used as router ID and termination interface for LDP and BGP sessions.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Configure Layer 3 VPN routing instance to provide customer services.

  5. Configure resolver RIB import policies and resolution RIBs to enable expanded hierarchical nexthop structure for selected Layer 3 VPN prefixes specified in the policy.

  6. Configure OSPF protocol.

  7. Configure routing protocols to establish IP and MPLS connectivity across the domain.

  8. Configure BGP labeled unicast to ABRs to exchange loopback IP addresses as BGP labeled unicast prefixes.

Results

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

Configuring P1 Device

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device P1:

  1. Configure the interfaces.

  2. Configure the loopback interface.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Configure routing options.

  5. Configure ISIS, RSVP, LDP, and MPLS protocols on the interface.

Results

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

Configuring RR1 Device

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device RR1:

  1. Configure the interfaces.

  2. Configure the loopback interface.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Configure routing options.

  5. Configure ISIS, RSVP, LDP, and MPLS protocols on the interface.

  6. Configure BGP labeled unicast to exchange loopback IP addresses as BGP labeled unicast prefixes.

Results

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

Configuring ABR1 Device

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device ABR1:

  1. Configure the interfaces to enable IP and MPLS transport.

  2. Configure the loopback interface to be used as router ID and termination interface for LDP and BGP sessions.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Apply per flow load balance policy to enable traffic protection.

  5. Configure ISIS, RSVP, MPLS, and LDP protocols on the interface.

  6. Configure BGP labeled unicast to exchange loopback IP addresses as BGP labeled unicast prefixes.

Results

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

Configuring ABR2 Device

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device ABR2:

  1. Configure the interfaces to enable IP and MPLS transport.

  2. Configure the loopback interface to be used as router ID and termination interface for LDP and BGP sessions.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Apply per flow load balance policy to enable traffic protection.

  5. Configure ISIS, RSVP, MPLS, and LDP protocols on the interface.

  6. Configure BGP labeled unicast to exchange loopback IP addresses as BGP labeled unicast prefixes.

Results

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

Configuring P2 Device

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device P2:

  1. Configure the interfaces to enable IP and MPLS transport.

  2. Configure the loopback interface to be used as router ID and termination interface for LDP and BGP sessions.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Configure routing options.

  5. Configure ISIS, RSVP, MPLS, and LDP protocols on the interface.

Results

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

Configuring RR2 Device

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure device RR2:

  1. Configure the interfaces to enable IP and MPLS transport.

  2. Configure the loopback interface to be used as router ID and termination interface for LDP and BGP sessions.

  3. Configure multipath resolution policies to install hierarchical multipaths into PFE.

  4. Apply per flow load balance policy to enable traffic protection.

  5. Configure ISIS, RSVP, MPLS, and LDP protocols on the interface.

  6. Configure BGP labeled unicast to exchange loopback IP addresses as BGP labeled unicast prefixes.

Results

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

Verification

Confirm that the configuration is working properly.

Verifying that Nexthops are Resolved

Purpose

Verify that PE2 and PE3 nexthops are resolved at PE1.

Action

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

Meaning

You can see weights 0x1 and 0x4000 for primary and backup nexthops.

Verifying the Nexthop Entries in the Routing Table

Purpose

Verify the active nexthop routing entries at PE1.

Action

From operational mode, run the show route extensive expanded-nh command.

Meaning

You can see the weights 0x1 and 0x4000 for primary and backup nexthops.

FAT Pseudowire Support for BGP L2VPN and VPLS Overview

A pseudowire is a Layer 2 circuit or service that emulates the essential attributes of a telecommunications service, such as a T1 line, over an MPLS packet-switched network (PSN). The pseudowire is intended to provide only the minimum necessary functionality to emulate the wire with the required resiliency requirements for the given service definition.

In an MPLS network, the flow-aware transport (FAT) of pseudowires flow label, as described in draft-keyupdate-l2vpn-fat-pw-bgp, is used for load-balancing traffic across BGP-signaled pseudowires for the Layer 2 virtual private network (L2VPN) and virtual private LAN service (VPLS).

FAT flow label is configured only on the label edge routers (LERs). This causes the transit routers or label-switching routers (LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs) without the need for deep packet inspection of the payload.

FAT flow label can be used for LDP-signaled forwarding equivalence class (FEC 128 and FEC 129) pseudowires for VPWS and VPLS pseudowires. The interface parameter (Sub-TLV) is used both for FEC 128 and FEC 129 pseudowires. The sub-TLV defined for LDP contains the transmit (T) and receive (R) bits. The T bit advertises the ability to push the flow label. The R bit advertises the ability to pop the flow label. By default, the signaling behavior of the provider edge (PE) router for any of these pseudowires is to advertise the T and R bits in the label set to 0.

The flow-label-transmit and flow-label-receive configuration statements provide the ability to set the T bit and R bit advertisement to 1 in the Sub-TLV field, which is part of the interface parameters of the FEC for the LDP label-mapping message. You can use these statements to control the pushing of the load-balancing label and the advertisement of the label to the routing peers in the control plane for BGP signaled pseudowires like L2VPN and VPLS.

Configuring FAT Pseudowire Support for BGP L2VPN to Load-Balance MPLS Traffic

The flow-aware transport (FAT) or flow label is supported for BGP-signaled pseudowires such as L2VPN to be configured only on the label edge routers (LERs). This enables the transit routers or the label-switching routers (LSRs) to perform load balancing of MPLS packets across equal-cost multipath paths (ECMP) or link aggregation groups (LAGs) without the need for deep packet inspection of the payload. FAT pseudowires or flow label can be used with LDP-signaled L2VPNs with forwarding equivalence class (FEC128 and FEC129), and the support for flow label is extended for BGP-signaled pseudowires for point-to-point or point–to-multipoint Layer 2 services.

Before you configure FAT pseudowire support for BGP L2VPN to load-balance MPLS traffic:

  • Configure the device interfaces and enable MPLS on all the interfaces.

  • Configure RSVP.

  • Configure MPLS and an LSP to the remote PE router.

  • Configure BGP and OSPF.

To configure FAT pseudowire support for BGP L2VPN to load-balance MPLS traffic, you must do the following:

  1. Configure the sites connected to the provider equipment for a given routing instance for the L2VPN protocols.
  2. Configure the L2VPN protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE.
  3. Configure the L2VPN protocol to provide advertising capability to push the flow label in the transmit direction to the remote PE.
  4. Configure the sites connected to the provider equipment for a given routing instance for the VPLS protocol.
  5. Configure the VPLS protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE.
  6. Configure the VPLS protocol to provide advertising capability to push the flow label in the transmit direction to the remote PE.

Example: Configuring FAT Pseudowire Support for BGP L2VPN to Load-Balance MPLS Traffic

This example shows how to implement FAT pseudowire support for BGP L2VPN to help load-balance MPLS traffic.

Requirements

This example uses the following hardware and software components:

  • Five MX Series routers

  • Junos OS Release 16.1 or later running on all devices

Before you configure FAT pseudowire support for BGP L2VPN, be sure you configure the routing and signaling protocols.

Overview

Junos OS allows the flow-aware transport (FAT) flow label that is supported for BGP-signaled pseudowires such as L2VPN to be configured only on the label edge routers (LERs). This causes the transit routers or the label-switching routers(LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs) without the need for deep packet inspection of the payload. The FAT flow label can be used for LDP-signaled forwarding equivalence class (FEC 128 and FEC 129) pseudowires for VPWS and VPLS pseudowires.

Topology

Figure 15, shows the FAT pseudowire support for BGP L2VPN configured on Device PE1 and Device PE2.

Figure 15: Example FAT Pseudowire Support for BGP L2VPNExample FAT Pseudowire Support for BGP L2VPN

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

CE1

PE1

P

PE2

CE2

Configuring PE1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.

  2. Configure nonstop routing, and configure the router ID.

  3. Configure the autonomous system (AS) number, and apply the policy to the forwarding table of the local router with the export statement.

  4. Configure the RSVP protocol on the interfaces.

  5. Apply the label-switched path attributes to the MPLS protocol, and configure the interface.

  6. Define a peer group, and configure the address of the local-end address of the BGP session for peer group vpls-pe.

  7. Configure attributes of the protocol family for NLRIs in updates.

  8. Configure neighbors for the peer group vpls-pe.

  9. Configure traffic engineering, and configure the interfaces of OSPF area 0.0.0.0.

  10. Configure the routing policy and the BGP community information.

  11. Configure the type of routing instance, and configure the interface.

  12. Configure the route distinguisher for instance l2vpn-inst, and configure the VRF target community.

  13. Configure the type of encapsulation required for the L2VPN protocol.

  14. Configure the sites connected to the provider equipment.

  15. Configure the L2VPN protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE and to provide advertising capability to push the flow label in the transmit direction to the remote PE.

  16. Configure the type of routing instance, and configure the interface.

  17. Configure the route distinguisher for instance vp1, and configure the VRF target community.

  18. Assign the maximum site identifier for the VPLS domain.

  19. Configure to not use the tunnel services for the VPLS instance, and assign a site identifier to the site connected to the provider equipment.

  20. Configure the VPLS protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE and to provide advertising capability to push the flow label in the transmit direction to the remote PE.

Results

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

Verification

Confirm that the configuration is working properly.

Verifying the BGP Summary Information
Purpose

Verify the BGP summary information.

Action

From operational mode, enter the show bgp summary command.

Meaning

The output displays the BGP summary information.

Verifying the L2VPN Connections Information
Purpose

Verify the Layer 2 VPN connections information.

Action

From operational mode, run the show l2vpn connections command to display the Layer 2 VPN connections information.

Meaning

The output displays the Layer 2 VPN connections information along with the flow label transmit and flow label receive information.

Verifying the Routes
Purpose

Verify that the expected routes are learned.

Action

From operational mode, run the show route command to display the routes in the routing table.

Meaning

The output shows all the routes in the routing table.

Configuring PE2

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device PE2:

  1. Configure the interfaces.

  2. Configure the router ID.

  3. Configure the autonomous system (AS) number, and apply the policy to the forwarding table of the local router with the export statement.

  4. Configure the RSVP protocol on the interfaces.

  5. Apply the label-switched path attributes to the MPLS protocol, and configure the interface.

  6. Define a peer group, and configure the local-end address of the BGP session for the peer group vpls-pe.

  7. Configure the attributes of the protocol family for NLRIs in updates.

  8. Configure the neighbors for peer group vpls-pe.

  9. Configure traffic engineering, and configure the interfaces of OSPF area 0.0.0.0.

  10. Configure the routing policy and the BGP community information.

  11. Configure the type of routing instance, and configure the interface.

  12. Configure the route distinguisher for instance l2vpn-inst, and configure the VRF target community.

  13. Configure the type of encapsulation required for the L2VPN protocol.

  14. Configure the sites connected to the provider equipment.

  15. Configure the L2VPN protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE and to provide advertising capability to push the flow label in the transmit direction to the remote PE.

  16. Configure the type of routing instance, and configure the interface.

  17. Configure the route distinguisher for instance vpl1, and configure the VRF target community.

  18. Assign the maximum site identifier for the VPLS domain.

  19. Configure to not use the tunnel services for the VPLS instance, and assign a site identifier to the site connected to the provider equipment.

  20. Configure the VPLS protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE and to provide advertising capability to the push flow label in the transmit direction to the remote PE.

Results

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

Verification

Confirm that the configuration is working properly.

Verifying the BGP Summary Information

Purpose

Verify the BGP summary information.

Action

From operational mode, enter the show bgp summary command.

Meaning

The output displays the BGP summary information.

Verifying the L2VPN Connections Information

Purpose

Verify the Layer 2 VPN connections information.

Action

From operational mode, run the show l2vpn connections command to display the Layer 2 VPN connections information.

Meaning

The output displays the Layer 2 VPN connections information along with the flow label transmit and flow label receive information.

Verifying the Routes

Purpose

Verify that the expected routes are learned.

Action

From operational mode, run the show route command to display the routes in the routing table.

Meaning

The output shows all the routes in the routing table.

Configuring FAT Pseudowire Support for BGP VPLS to Load-Balance MPLS Traffic

The flow-aware transport (FAT) or flow label is supported for BGP-signaled pseudowires such as VPLS and is to be configured only on the label edge routers (LERs). This enables the transit routers or the label-switching routers (LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) or link aggregation groups (LAGs) without the need for deep packet inspection of the payload. FAT pseudowires or flow label can be used with LDP-signaled VPLS with forwarding equivalence class (FEC128 and FEC129), and the support for flow label is extended for BGP-signaled pseudowires for point-to-point or point-to-multipoint Layer 2 services.

Before you configure FAT pseudowire support for BGP VPLS to load-balance MPLS traffic:

  • Configure the device interfaces and enable MPLS on all the interfaces.

  • Configure RSVP.

  • Configure MPLS and an LSP to the remote PE router.

  • Configure BGP and OSPF.

To configure FAT pseudowire support for BGP VPLS to load-balance MPLS traffic, you must do the following:

  1. Configure the sites connected to the provider equipment for a given routing instance for the VPLS protocols.
  2. Configure the VPLS protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE.
  3. Configure the VPLS protocol to provide advertising capability to push the flow label in the transmit direction to the remote PE.

Example: Configuring FAT Pseudowire Support for BGP VPLS to Load-Balance MPLS Traffic

This example shows how to implement FAT pseudowire support for BGP VPLS to help load-balance MPLS traffic.

Requirements

This example uses the following hardware and software components:

  • Five MX Series routers

  • Junos OS Release 16.1 or later running on all devices

Before you configure FAT pseudowire support for BGP VPLS, be sure you configure the routing and signaling protocols.

Overview

Junos OS allows the flow-aware transport (FAT) flow label that is supported for BGP-signaled pseudowires such as VPLS to be configured only on the label edge routers (LERs). This causes the transit routers or the label-switching routers (LSRs) to perform load balancing of MPLS packets across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs) without the need for deep packet inspection of the payload. The FAT flow label can be used for LDP-signaled forwarding equivalence class (FEC 128 and FEC 129) pseudowires for VPWS and VPLS pseudowires.

Topology

Figure 16 shows the FAT pseudowire support for BGP VPLS configured on Device PE1 and Device PE2.

Figure 16: Example FAT Pseudowire Support for BGP VPLSExample FAT Pseudowire Support for BGP VPLS

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

CE1

PE1

P

PE2

CE2

Configuring PE1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.

  2. Configure nonstop routing, and configure the router ID.

  3. Configure the autonomous system (AS) number, and apply the policy to the forwarding table of the local router with the export statement.

  4. Configure the RSVP protocol on the interfaces.

  5. Apply the label-switched path attributes to the MPLS protocol, and configure the interface.

  6. Define a peer group, and configure the address of the local end of the BGP session for peer group vpls-pe.

  7. Configure attributes of the protocol family for NLRIs in updates.

  8. Configure neighbors for the peer group vpls-pe.

  9. Configure traffic engineering, and configure the interfaces of OSPF area 0.0.0.0.

  10. Configure the routing policy and the BGP community information.

  11. Configure the type of routing instance, and configure the interface.

  12. Configure the route distinguisher for instance vpl1, and configure the VRF target community.

  13. Assign the maximum site identifier for the VPLS domain.

  14. Configure the VPLS protocol to not use the tunnel services for the VPLS instance, and assign the site identifier to the site connected to the provider equipment.

  15. Configure the VPLS protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE and to provide advertising capability to push the flow label in the transmit direction to the remote PE.

Results

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

Configuring PE2

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device PE2:

  1. Configure the interfaces.

  2. Configure the router ID.

  3. Configure the autonomous system (AS) number, and apply the policy to the forwarding table of the local router with the export statement.

  4. Configure the RSVP protocol on the interfaces.

  5. Apply the label-switched path attributes to the MPLS protocol, and configure the interface.

  6. Define a peer group, and configure the local-end address of the BGP session for peer group vpls-pe.

  7. Configure attributes of the protocol family for NLRIs in updates.

  8. Configure neighbors for the peer group vpls-pe.

  9. Configure traffic engineering, and configure the interfaces of OSPF area 0.0.0.0.

  10. Configure the routing policy and the BGP community information.

  11. Configure the type of routing instance, and configure the interface.

  12. Configure the route distinguisher for instance vp11, and configure the VRF target community.

  13. Assign the maximum site identifier for the VPLS domain.

  14. Configure the VPLS protocol to not use the tunnel services for the VPLS instance, and assign the site identifier to the site connected to the provider equipment.

  15. Configure the VPLS protocol for the routing instance to provide advertising capability to pop the flow label in the receive direction to the remote PE and to provide advertising capability to push the flow label in the transmit direction to the remote PE.

Results

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

Verification

Confirm that the configuration is working properly.

Verifying the VPLS Connection Information
Purpose

Verify the VPLS connection information.

Action

From operational mode, run the show vpls connections command to display the VPLS connections information.

Meaning

The output displays the VPLS connection information along with the flow label receive and flow label transmit information.

Verification

Confirm that the configuration is working properly.

Verifying the VPLS Connection Information

Purpose

Verify the VPLS connection information.

Action

From operational mode, run the show vpls connections command to display the VPLS connections information.

Meaning

The output displays the VPLS connection information along with the flow label receive and flow label transmit information.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
20.2R1
Starting from Junos OS Release 20.2R1, MX Series, EX9204, EX9208, EX9214, EX9251, and EX9253 devices support BGP PIC Edge protection for Layer 2 circuit, Layer 2 VPN, and VPLS (BGP VPLS, LDP VPLS and FEC 129 VPLS) services with BGP labeled unicast as the transport protocol.
19.2R1
Starting with Junos OS Release 19.2R1, you can specify a maximum number of 512 equal-cost paths on QFX10000 switches.
19.1R1
Starting with Junos OS Release 19.1R1, you can specify a maximum number of 128 equal-cost paths on QFX10000 switches.
18.4R1
Starting in Junos OS Release 18.4R1, BGP can advertise a maximum of 2 add-path routes in addition to the multiple ECMP paths.
18.1R1
Starting in Junos OS Release 18.1R1 BGP multipath is supported globally at [edit protocols bgp] hierarchy level. You can selectively disable multipath on some BGP groups and neighbors. Include disable at [edit protocols bgp group group-name multipath] hierarchy level to disable multipath option for a group or a specific BGP neighbor.
18.1R1
Starting in Junos OS Release 18.1R1, you can defer multipath calculation until all BGP routes are received. When multipath is enabled, BGP inserts the route into the multipath queue each time a new route is added or whenever an existing route changes. When multiple paths are received through BGP add-path feature, BGP might calculate one multipath route multiple times. Multipath calculation slows down the RIB (also known as the routing table) learning rate. To speed up RIB learning, multipath calculation can be either deferred until the BGP routes are received or you can lower the priority of the multipath build job as per your requirements until the BGP routes are resolved. To defer the multipath calculation configure defer-initial-multipath-build at [edit protocols bgp] hierarchy level. Alternatively, you can lower the BGP multipath build job priority using multipath-build-priority configuration statement at [edit protocols bgp] hierarchy level to speed up RIB learning.