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 Balancing
BGP Load Balancing

Configuration

CLI Quick Configuration

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

Step-by-Step Procedure

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

user@R1> show route 10.0.2.0
user@R1> show route 10.0.2.0 detail

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.

user@R1> show route forwarding-table destination 10.0.2.0

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.

When you enable a single-hop EBGP peer to accept a remote next hop, you must also configure an import routing policy on the EBGP peer that specifies the remote next-hop address.

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 1.1.10.10 for the route to the 1.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 Hop
Topology 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 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 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 1.1.10.10 for the route to the 1.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 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 1.1.230.0/23 network.

Action

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

user@R1> show route 1.1.230.0 extensive

Meaning

The output shows that Device R1 has a route to the 1.1.230.0 network with the multipath feature enabled (Accepted Multipath). The output also shows that the route has an indirect next hop of 1.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.

    user@R1# deactivate protocols bgp accept-remote-nexthop
    user@R1# commit
  2. From operational mode, enter the show route 1.1.230.0 command.

    user@R1> show route 1.1.230.0
  3. From configuration mode, reactivate the statement by entering the activate protocols bgp accept-remote-nexthop command.

    user@R1# activate protocols bgp accept-remote-nexthop
    user@R1# commit
  4. From operational mode, reenter the show route 1.1.230.0 command.

    user@R1> show route 1.1.230.0

Meaning

When the accept-remote-nexthop statement is deactivated, the multipath route to the 1.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 Balancing
BGP Load Balancing

CLI Quick Configuration shows the configuration for all of the devices in Figure 3. The sectionStep-by-Step Procedure describes the steps on Device R1.

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

user@R1> show route 172.16/16 protocol bgp detail


user@R1> show route 10.0.2.0 protocol bgp detail

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.

A BGP peer 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 the link bandwidth extended community, to advertise the aggregated bandwidth of multiple routes across external links. BGP calculates the aggregate bandwidth of multipaths that have unequal bandwidth allocation and advertises the aggregated bandwidth to external BGP peers. A threshold to the aggregate bandwidth can be configured to restrict the bandwidth usage of a BGP group. Both IPv4 and IPv6 routes including anycast addresses support aggregate bandwidth.

To advertise aggregate bandwidth of multipath routes and to set a maximum threshold, configure a policy with aggregate-bandwidth and limit bandwidth actions at the [edit policy-options policy-statement name then] hierarchy level.

Figure 4: Advertising Aggregate Bandwidth Across External BGP Links for Load Balancing
Advertising Aggregate Bandwidth
Across External BGP Links for Load Balancing

In Figure 4, autonomous system 1 (AS1) aggregates the bandwidth of its 3 multipath routes to a remote prefix and advertises it to autonomous system 4 (AS4) with a bandwidth of 30 using the link bandwidth extended community. In case of a link failure between AS3 and AS4, AS4 subtracts 60 from the bandwidth it advertises to AS6 and modifies the bandwidth it was advertising from 130 to 70.

When a BGP peer propagates multipath routes configured with an aggregate bandwidth community, a new link bandwidth community is added with the sum of the bandwidth from the incoming bandwidth communities or that prefix. The available link bandwidth is dynamically derived from interface speed. The link bandwidth is sent as a transitive extended community. However, If the device receives the link bandwidth as a non-transitive link bandwidth extended community, Junos OS ignores this community but propagates it along with the transitive link bandwidth extended community. If the link-bandwidth community is not received for each one of the incoming multipath routes then a link bandwidth community is not advertised to its external peers.

When one of the multipath links fails, BGP readvertises the route with the bandwidth of the failed link subtracted from the outgoing link bandwidth community. If the aggregate link bandwidth is found to exceed the configured limit, the advertised aggregate bandwidth is truncated to the configured link bandwidth limit between the two peers.

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

user@R1> show bgp summary

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.
user@R1> show route 10.0.2.0 protocol bgp detail

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

user@R1> show route advertising-protocol bgp 10.0.4.2 10.0.2.0/30 detail

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:

  • Internal BGP (IBGP) peers only. No support on external BGP (EBGP) peers.

  • Master instance only. No support for routing instances.

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

  • No BGP Monitoring Protocol (BMP) support.

  • No support for EBGP sessions between confederations.

  • 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 64 add-path routes and a second best path as a backup 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.

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

user@R1> show bgp neighbor 10.0.0.40
user@R4> show bgp neighbor 10.0.0.10
user@R4> show bgp neighbor 10.0.0.80
user@R8> show bgp neighbor 10.0.0.40

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

user@R1> show route advertising-protocol bgp 10.0.0.40

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

user@R4> show route receive-protocol bgp 10.0.0.10
user@R4> show route advertising-protocol bgp 10.0.0.80

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

user@R8> show route receive-protocol bgp 10.0.0.40

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

user@R4> show route 172.16.199.1/32 detail
user@R8> show route 172.16.199.1/32 detail

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 Balancing
Example: 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.

user@RR1> show route 199.1.1.1/32 detail

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.

user@RR1> show route advertising-protocol bgp 10.0.0.40
user@RR1> show route advertising-protocol bgp 10.0.0.40 detail

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.

user@RR4> show route advertising-protocol bgp 10.0.0.80 detail

Meaning

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

See also

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 Value
Example: 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.

user@RR4> show route advertising-protocol bgp 10.0.0.80

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.

user@R8> show route receive-protocol bgp 10.0.0.40

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.

user@RR4> show route 199.1.1.1/32 detail

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:

    user@host> show route resolution detail 10.1.1.2
    user@host> show route 10.1.1.2 extensive

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

The Junos OS supports configurations of 16, 32, or 64 equal-cost multipath (ECMP) next hops for RSVP and LDP LSPs on M10i routers with an Enhanced CFEB, M320, M120, MX Series, and T Series routers, and routing devices. For networks with high-volume traffic, this provides more flexibility to load-balance the traffic over as many as 64 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, or 64 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 64 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

  • ISIS 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 64 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

The following FPCs on M320, T640, and T1600 routers only support 16 ECMP next hops:

  • (M320, T640, and T1600 routers only) Enhanced II FPC1

  • (M320, T640, and T1600 routers only) Enhanced II FPC2

  • (M320 and T640 routers only) Enhanced II FPC3

  • (T640 and T1600 routers only) FPC2

  • (T640 and T1600 routers only) FPC3

If a maximum ECMP next-hop limit of 32 or 64 is configured on an M320, T640, or T1600 router with any of these FPCs installed, the Packet Forwarding Engines on these FPCs use only the first 16 ECMP next hops. For Packet Forwarding Engines on FPCs that support only 16 ECMP next hops, the Junos OS generates a system log message if a maximum ECMP next-hop limit of 32 or 64 is configured. However, for Packet Forwarding Engines on other FPCs installed on the router, a maximum configured ECMP limit of 32 or 64 ECMP next hops is applicable.

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:

  • T1600 and T640 routers with Enhanced Scaling FPC1, Enhanced Scaling FPC2, Enhanced Scaling FPC3, Enhanced Scaling FPC 4, and all Type 4 FPCs

  • M320 routers with Enhanced III FPC1, Enhanced III FPC2, and Enhanced III FPC3

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

  • M120 routers with Type 1, Type 2, and Type 3 FPCs

  • M10i routers with Enhanced CFEB

Next-hop cloning and permutations are disabled on T Series routers with Enhanced Scaling FPCs (Enhanced Scaling FPC1, Enhanced Scaling FPC2, Enhanced Scaling FPC3, and Enhanced Scaling FPC 4) that support enhanced load-balancing capability. As a result, memory utilization is reduced for a highly scaled system with a high number of next hops on ECMP or aggregated interfaces. Next-hop cloning and permutations are also disabled on T Series routers with Type-4 FPCs.

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.

See also

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 LSP
Entropy 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 Label
Inter-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 Point
Inter-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.

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

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. LAG is configured on the provider routers for load balancing the traffic. Entropy label capability for BGP labeled unicast is enabled on the ingress Router PE1.

Figure 12: Configuring an Entropy Label for BGP Labeled Unicast
Configuring 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 PE1

Router P1

Router ABR

Router P2

Router PE2

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 interfaces with IPv4 and IPv6 addresses.
  2. Configure the loopback interface.
  3. Set the router ID and the autonomous system number.
  4. Configure RSVP protocol for all interfaces.
  5. Enable MPLS on all the interfaces of Router PE1 and specify the LSP.
  6. Configure IBGP on the internal routers.
  7. Enable entropy label capability for BGP labeled unicast for internal BGP group ibgp.
  8. Enable the OSPF protocol on all the interfaces of the area border router (ABR).
  9. Define prefix lists to specify the routes with entropy label capability.
  10. Define a policy EL to specify the routes with entropy label capability.
  11. Define another policy EL-2 to specify the routes with entropy label capability.
  12. Define a policy to export BGP routes to the OSPF routing table.
  13. Define a policy to export OSPF routes to the BGP routing table.
  14. Define a policy to export static routes to the BGP routing table.
  15. Configure a VPN target for the VPN community.
  16. Configure the Layer 3 VPN routing instance VPN-l3vpn.
  17. Assign the interfaces for the VPN-l3vpn routing instance.
  18. Configure the route distinguisher for the VPN-l3vpn routing instance.
  19. Configure a VPN routing and forwarding (VRF) target for the VPN-l3vpn routing instance.
  20. Configure a static route to Device CE1 using the Layer 3 VPN protocol for the VPN-l3vpn routing instance.
  21. Export the BGP routes to the OSPF routing table for the VPN-l3vpn routing instance.
  22. Assign the OSPF interface for the VPN-l3vpn routing instance.

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 interfaces with IPv4 and IPv6 addresses.
  2. Configure link aggregation on the interfaces.
  3. Configure the loopback interface.
  4. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing.
  5. Set the router ID and the autonomous system number.
  6. Enable per packet load balancing.
  7. Configure the RSVP protocol for all interfaces.
  8. Enable MPLS on all the interfaces of Router P1 and specify the LSP.
  9. Enable the OSPF protocol on all the interfaces of Router P1 excluding the management interface.
  10. Define a policy for per packet load balancing.

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 interfaces with IPv4 and IPv6 addresses.
  2. Configure the loopback interface.
  3. Configure link aggregation on the interfaces.
  4. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing.
  5. Set the router ID and the autonomous system number.
  6. Enable per packet load balancing.
  7. Configure the RSVP protocol for all interfaces.
  8. Enable MPLS on all the interfaces of Router P1 and specify the LSP.
  9. Configure IBGP on the internal routers.
  10. Enable the OSPF protocol on all the interfaces of ABR.
  11. Define a policy to specify the routes with entropy label capability.

Results

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

Confirm that the configuration is working properly.

Verifying That the Entropy Label Capability Is Being Advertised from Router PE2

Purpose

Verify that the entropy label capability path attribute is being advertised from the upstream Router PE2 at egress.

Action

From operational mode, run the show route 10.255.101.200 advertising-protocol bgp 10.255.102.102 command on Router PE2.

user@PE2> show route 10.255.101.200 advertising-protocol bgp 10.255.102.102

Meaning

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

Verifying That Router ABR Receives the Entropy Label Advertisement

Purpose

Verify that Router ABR receives the entropy label advertisement at ingress from Router PE2.

Action

From operational mode, run the show route 10.255.101.200 receiving-protocol bgp 10.255.101.200 command on Router ABR.

user@ABR> show route 10.255.101.200 receiving-protocol bgp 10.255.101.200

Meaning

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

Verifying That the Entropy Label Flag Is Set

Purpose

Verify that the entropy label flag is set for the label elements at the ingress.

Action

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

user@PE1> show route protocol bgp detail

Meaning

An entropy label is enabled on Router PE1. The output shows that the entropy label is being used for the BGP labeled unicast to achieve end-to-end load balancing.

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 Routine 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.

Note

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

Before you begin:

  1. Configure the device interfaces.
  2. Configure OSPF or any other IGP protocol.
  3. Configure MPLS and LDP.
  4. Configure BGP.
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:

    user@host> show route 20.1.1.1 extensive
    user@host> show route forwarding-table destination 20.1.1.1 extensive

    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 Inet
Configuring 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 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.

user@PE0> show route 192.168.1.5 extensive

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.

user@PE0> show route forwarding-table destination 192.168.1.5 extensive

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.

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 14, shows the FAT pseudowire support for BGP L2VPN configured on Device PE1 and Device PE2.

Figure 14: Example FAT Pseudowire Support for BGP L2VPN
Example 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 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.

user@PE1> show bgp summary

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.

user@PE1> show l2vpn connections

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.

user@PE1> show route

Meaning

The output shows all the routes in the routing table.

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

user@PE2> show bgp summary

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.

user@PE2> show l2vpn connections

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.

user@PE2> show route

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 15 shows the FAT pseudowire support for BGP VPLS configured on Device PE1 and Device PE2.

Figure 15: Example FAT Pseudowire Support for BGP VPLS
Example 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 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.

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.

user@PE1> show vpls connections

Meaning

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

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

user@PE2> show vpls connections

Meaning

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

Release History Table
Release
Description
Starting with Junos OS Release 19.2R1, you can specify a maximum number of 512 equal-cost paths on QFX10000 switches.
Starting with Junos OS Release 19.1R1, you can specify a maximum number of 128 equal-cost paths on QFX10000 switches.
Starting in Junos OS Release 18.4R1, BGP can advertise a maximum of 64 add-path routes and a second best path as a backup in addition to the multiple ECMP paths.
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.