Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

Configuring Protocol-Independent Load Balancing in Layer 3 VPNs

Protocol-independent load balancing for Layer 3 VPNs allows the forwarding next hops of both the active route and alternative paths to be used for load balancing. Protocol-independent load balancing works in conjunction with Layer 3 VPNs. It supports the load balancing of VPN routes independently of the assigned route distinguisher. When protocol-independent load balancing is enabled, both routes to other PE routers and routes to directly connected CE routers are load-balanced.

When load-balancing information is created for a given route, the active path is marked as Routing Use Only in the output of the show route table command.

The following sections describe how to configure protocol-independent load balancing and how this configuration can affect routing policies:

Configuring Load Balancing for Layer 3 VPNs

The configuration of protocol-independent load balancing for Layer 3 VPNs is a little different for IPv4 versus IPv6:

  • IPv4—You only need to configure the multipath statement at either the [edit routing-instances routing-instance-name routing-options] hierarchy level or the [edit routing-instances routing-instance-name routing-options rib routing-table-name] hierarchy level.
  • IPv6—You need to configure the multipath statement at both the [edit routing-instances routing-instance-name routing-options] hierarchy level and the [edit routing-instances routing-instance-name routing-options rib routing-table-name] hierarchy level.

Note: You cannot configure the multipath statement and sub-statements at the same time that you have configured the l3vpn statement.

To configure protocol-independent load balancing for Layer 3 VPNs, include the multipath statement:

multipath {vpn-unequal-cost equal-external-internal;}

When you include the multipath statement at the following hierarchy levels, protocol-independent load balancing is applied to the default routing table for that routing instance (routing-instance-name.inet.0):

  • [edit routing-instances routing-instance-name routing-options]
  • [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options]

When you include the multipath statement at the following hierarchy levels, protocol-independent load balancing is applied to the specified routing table:

  • [edit routing-instances routing-instance-name routing-options rib routing-table-name]
  • [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options rib routing-table-name]

The vpn-unequal-cost statement is optional:

  • When you include it, protocol-independent load balancing is applied to VPN routes that are equal until the IGP metric with regard to route selection.
  • When you do not include it, protocol-independent load balancing is applied to VPN routes that are equal until the router identifier with regard to route selection.

The equal-external-internal statement is also optional. When you include it, protocol-independent load balancing is applied to both internal and external BGP paths. You can configure this in conjunction with egress IP header filtering (enabled with the vrf-table-label statement). For more information, see Load Balancing and IP Header Filtering for Layer 3 VPNs.

Note: You can include the vpn-unequal-cost equal-external-internal statement and the l3vpn statement at the [edit routing-options forwarding-options chained-composite-next-hop ingress] hierarchy level simultaneously. However, if you do this, EBGP does not work. This means that when there are both paths with chained next hops and paths with nonchained next hops as candidates for EBGP equal-cost multipath (ECMP), the paths using chained next hops are excluded. In a typical case, the excluded paths are the internal paths.

Configuring Load Balancing and Routing Policies

If you enable protocol-independent load balancing for Layer 3 VPNs by including the multipath statement and if you also include the load-balance per-packet statement in the routing policy configuration, packets are not load-balanced.

For example, a PE router has the following VRF routing instance configured:

[edit routing-instances]
load-balance-example {instance-type vrf;interface fe-0/1/1.0;interface fe-0/1/1.1;route-distinguisher 2222:2;vrf-target target:2222:2;routing-options {multipath;}protocols {bgp {group group-example {import import-policy;family inet {unicast;}export export-policy;peer-as 4444;local-as 3333;multipath;as-override;neighbor 10.12.33.22;}}}}

The PE router also has the following policy statement configured:

[edit policy-options policy-statement export-policy]from protocol bgp;
then {load-balance per-packet;}

When you include the multipath statement in the VRF routing instance configuration, the paths are no longer marked as BGP paths but are instead marked as multipath paths. Packets from the PE router are not load-balanced.

To ensure that VPN load-balancing functions as expected, do not include the from protocol statement in the policy statement configuration. The policy statement should be configured as follows:

[edit policy-options policy-statement export-policy]
then {load-balance per-packet;}

For more information about how to configure per-packet load balancing, see the Routing Policy Feature Guide for Routing Devices.

Published: 2013-07-31

Supported Platforms

Published: 2013-07-31