IN THIS PAGE
Example: Load Balancing Layer 3 VPN Traffic While Simultaneously Using IP Header Filtering
This example shows how to configure load balancing in a Layer 3 VPN (with internal and external BGP paths) while simultaneously using IP header filtering.
Requirements
This example requires the following hardware and software components:
M Series Multiservice Edge Routers (M120 and M320 only), MX Series 3D Universal Edge Routers,T Series Core Routers, or PTX Series Transport Switches.
Junos OS Release 12.1 or later
This configuration example has been tested using the software release listed and is assumed to work on all later releases.
Overview
The following example shows how to configure load balancing while simultaneously using IP header filtering in a Layer 3 VPN.
This example demonstrates how load balancing and IP header filtering work together. The testing of IP header filtering is out of the scope of this example.
The Junos OS BGP provides a multipath feature that allows load balancing between peers in the same or different autonomous systems (ASs). This example uses the equal-external-internal statement at the [edit routing-instances instance-name routing-options multipath vpn-unequal-cost] hierarchy level to perform load balancing. The vrf-table-label statement is configured at the [edit routing-instances instance-name] hierarchy level to enable IP header filtering.
These statements are available only in the context of a routing instance.
In this example, Device CE1 is in AS1 and connected to Device PE1. Devices PE1, PE2, PE3, and P are in AS2. Device CE2 is connected to Devices PE2 and PE3 and is in AS3. Device CE3 is connected to Device PE3 and is in AS4. BGP and MPLS are configured through the network. OSPF is the interior gateway protocol (IGP) that is used in this network.
The configuration for Devices PE1, PE2, and PE3 includes the equal-external-internal statement at the [edit routing-instances instance-name routing-options multipath vpn-unequal-cost] hierarchy level to enable load balancing in the network. IP header filtering is enabled when the vrf-table-label statement is configured at the [edit routing-instances instance-name] hierarchy level on the PE devices.
Figure 1 shows the topology used in this example.
Table 1 shows the list of IP addresses used in this example for quick reference.
Table 1: Device IP Address Quick Reference
Device | AS | Device ID | Device Interface Units | Device Interface Unit IPs |
|---|---|---|---|---|
CE1 | 1 | 1.1.1.1/32 | Unit 1 | 10.1.1.1/30 |
PE1 | 2 | 1.1.1.2/32 | Unit 2 | 10.1.1.2/30 |
Unit 5 | 10.1.2.5/30 | |||
Unit 9 | 10.1.3.9/30 | |||
PE2 | 2 | 1.1.1.3/32 | Unit 6 | 10.1.2.6/30 |
Unit 13 | 10.1.4.13/30 | |||
Unit 21 | 10.1.6.21/30 | |||
PE3 | 2 | 1.1.1.4/32 | Unit 10 | 10.1.3.10/30 |
Unit 18 | 10.1.5.18/30 | |||
Unit 25 | 10.1.7.25/30 | |||
Unit 29 | 10.1.8.29/30 | |||
P | 2 | 1.1.1.5/32 | Unit 14 | 10.1.4.14/30 |
Unit 17 | 10.1.5.17/30 | |||
CE2 | 3 | 1.1.1.6/32 | Unit 22 | 10.1.6.22/30 |
Unit 26 | 10.1.7.26/30 | |||
CE3 | 4 | 1.1.1.7/32 | Unit 30 | 10.1.8.30/30 |
This example was tested using logical systems (logical routers). Therefore all the physical interfaces in the example are the same and the configuration is done on separate logical interfaces. In an non-test network, you will use separate physical routers and separate physical interfaces for the connections to other devices.
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 CE1
Device PE1
Device PE2
Device PE3
Device P
Device CE2
Device CE3
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 unequal-cost load balancing across the VPN setup:
- Configure the router ID on Device CE1, and assign the
device to its autonomous system.[edit routing-options]user@CE1# set routing-options router-id 1.1.1.1user@CE1# set routing-options autonomous-system 1
Similarly, configure all other devices.
- Configure BGP groups for traffic through the entire network.
Configure the BGP group for traffic to and from the MPLS network (CE devices).
[edit protocols bgp group toPE1]user@CE1# set type externaluser@CE1# set peer-as 2user@CE1# set neighbor 10.1.1.2Configure similar BGP groups (toAS2 and toPE3) on Devices CE2 and CE3 by modifying the peer-as and neighbor statements accordingly.
Configure the BGP group for traffic through the MPLS network (PE devices).
[edit protocols bgp group toInternal]user@PE1# set type internaluser@PE1# set family inet-vpn unicastuser@PE1# set local-address 1.1.1.2user@PE1# set neighbor 1.1.1.3user@PE1# set neighbor 1.1.1.4Configure the same BGP group (toInternal) on Devices PE2 and PE3 by modifying the local-address and neighbor statements accordingly.
- Configure a routing policy for exporting routes to and
from the MPLS network (send-direct policy) and a policy
for load balancing traffic network across the MPLS network (lb policy).
Configure a policy (send-direct) for exporting routes from the routing table into BGP on Device CE1.
[edit policy-options policy-statement send-direct]user@CE1# set from protocol directuser@CE1# set then accept[edit protocols bgp group toPE1]user@CE1# set export send-directSimilarly, configure the send-direct policy on Devices CE2 and CE3.
Configure a policy (lb) for exporting routes from the routing table into the forwarding table on Device PE1.
The lb policy configures per-packet load balancing, which ensures that all next-hop addresses for a destination are installed in the forwarding table.
[edit policy-options policy-statement lb]user@PE1# set then load-balance per-packet[edit routing-options]user@PE1# set forwarding-table export lbSimilarly, configure the lb policy on Devices PE2, and PE3.
- Configure the following:
Configure the routing instance on the PE devices for exporting routes through the autonomous systems.
Include the equal-external-internal statement at the [edit routing-instances instance-name routing-options multipath vpn-unequal-cost] hierarchy level to enable load balancing in the network.
Include the vrf-table-label statement at the [edit routing-instances instance-name] hierarchy level for filtering traffic prior to exiting the egress device (Device CE3).
Device PE1
[edit routing-instances purple]user@PE1# set instance-type vrfuser@PE1# set interface ge-2/1/10.2user@PE1# set route-distinguisher 2:1user@PE1# set vrf-target target:2:1user@PE1# set vrf-table-labeluser@PE1# set protocols bgp group toCE1 type externaluser@PE1# set protocols bgp group toCE1 peer-as 1user@PE1# set protocols bgp group toCE1 neighbor 10.1.1.1user@PE1# set routing-options multipath vpn-unequal-cost equal-external-internalDevice PE2
[edit routing-instances purple]user@PE2# set instance-type vrfuser@PE2# set interface ge-2/1/10.21user@PE2# set route-distinguisher 2:1user@PE2# set vrf-target target:2:1user@PE2# set vrf-table-labeluser@PE2# set protocols bgp group toCE2 type externaluser@PE2# set protocols bgp group toCE2 peer-as 3user@PE2# set protocols bgp group toCE2 neighbor 10.1.6.22user@PE2# set routing-options multipath vpn-unequal-cost equal-external-internalDevice PE3
[edit routing-instances purple]user@PE3# set instance-type vrfuser@PE3# set interface ge-2/1/10.25user@PE3# set interface ge-2/1/10.29user@PE3# set route-distinguisher 2:1user@PE3# set vrf-target target:2:1user@PE3# set vrf-table-labeluser@PE3# set protocols bgp group toCE2 type externaluser@PE3# set protocols bgp group toCE2 peer-as 3user@PE3# set protocols bgp group toCE2 neighbor 10.1.7.26user@PE3# set protocols bgp group toCE3 type externaluser@PE3# set protocols bgp group toCE3 peer-as 4user@PE3# set protocols bgp group toCE3 neighbor 10.1.8.30user@PE3# set routing-options multipath vpn-unequal-cost equal-external-internal
Results
From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, show routing-options, and show routing-instances 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 BGP
Purpose
Verify that BGP is working.
Action
From operational mode, run the show route protocol bgp command.
user@PE3> show route protocol bgp
inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
purple.inet.0: 9 destinations, 14 routes (9 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 04:47:14, localpref 100, from 1.1.1.2
AS path: 1 I
> to 10.1.3.9 via ge-2/1/10.10, Push 16
1.1.1.6/32 @[BGP/170] 00:13:28, localpref 100
AS path: 3 I
> to 10.1.7.26 via ge-2/1/10.25
[BGP/170] 00:10:36, localpref 100, from 1.1.1.3
AS path: 3 I
> to 10.1.5.17 via ge-2/1/10.18, Push 16, Push 299776(top)
1.1.1.7/32 *[BGP/170] 00:10:56, localpref 100
AS path: 4 I
> to 10.1.8.30 via ge-2/1/10.29
10.1.1.0/30 *[BGP/170] 04:47:14, localpref 100, from 1.1.1.2
AS path: I
> to 10.1.3.9 via ge-2/1/10.10, Push 16
10.1.6.20/30 *[BGP/170] 04:47:03, localpref 100, from 1.1.1.3
AS path: I
> to 10.1.5.17 via ge-2/1/10.18, Push 16, Push 299776(top)
[BGP/170] 00:13:28, localpref 100
AS path: 3 I
> to 10.1.7.26 via ge-2/1/10.25
10.1.7.24/30 [BGP/170] 00:13:28, localpref 100
AS path: 3 I
> to 10.1.7.26 via ge-2/1/10.25
10.1.8.28/30 [BGP/170] 00:10:56, localpref 100
AS path: 4 I
> to 10.1.8.30 via ge-2/1/10.29
mpls.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2:1:1.1.1.1/32
*[BGP/170] 04:47:14, localpref 100, from 1.1.1.2
AS path: 1 I
> to 10.1.3.9 via ge-2/1/10.10, Push 16
2:1:1.1.1.6/32
*[BGP/170] 00:10:36, localpref 100, from 1.1.1.3
AS path: 3 I
> to 10.1.5.17 via ge-2/1/10.18, Push 16, Push 299776(top)
2:1:10.1.1.0/30
*[BGP/170] 04:47:14, localpref 100, from 1.1.1.2
AS path: I
> to 10.1.3.9 via ge-2/1/10.10, Push 16
2:1:10.1.6.20/30
*[BGP/170] 04:47:03, localpref 100, from 1.1.1.3
The output lists the BGP routes installed into the routing table. The lines of output that start with 1.1.1.1/32, 10.1.1.0/30, and 2:1:1.1.1.1/32 show the BGP routes to Device CE1, which is in AS1. The lines of output that start with 1.1.1.6/32, 2:1:1.1.1.6/32, and 2:1:10.1.6.20/30 show the BGP routes to Device CE2, which is in AS3. The line of output that starts with 1.1.1.7/32 shows the BGP route to Device CE3, which is in AS4.
Meaning
BGP is functional in the network.
Verifying Load Balancing
Purpose
Verify that forwarding is taking place in both directions by checking:
If both next hops are installed in the forwarding table for a route.
If external BGP routes are installed in the forwarding table for a route.
Action
From operational mode, run the show route forwarding-table and show route forwarding-table destination <destination IP> commands.
user@PE3> show route forwarding-table
Router: PE3
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 593 1
0.0.0.0/32 perm 0 dscd 579 1
1.1.1.2/32 user 1 10.1.3.9 ucst 999 8 ge-2/1/10.10
1.1.1.3/32 user 1 10.1.5.17 ucst 1243 12 ge-2/1/10.18
1.1.1.4/32 intf 0 1.1.1.4 locl 895 1
1.1.1.5/32 user 1 10.1.5.17 ucst 1243 12 ge-2/1/10.18
10.1.2.4/30 user 0 ulst 1048580 2
10.1.3.9 ucst 999 8 ge-2/1/10.10
10.1.5.17 ucst 1243 12 ge-2/1/10.18
10.1.3.8/30 intf 0 rslv 899 1 ge-2/1/10.10
10.1.3.8/32 dest 0 10.1.3.8 recv 897 1 ge-2/1/10.10
10.1.3.9/32 dest 0 0.6.80.3.0.21.59.d.c5.d9.0.21.59.d.c5.da.8.0
ucst 999 8 ge-2/1/10.10
10.1.3.10/32 intf 0 10.1.3.10 locl 898 2
10.1.3.10/32 dest 0 10.1.3.10 locl 898 2
10.1.3.11/32 dest 0 10.1.3.11 bcst 896 1 ge-2/1/10.10
10.1.4.12/30 user 0 10.1.5.17 ucst 1243 12 ge-2/1/10.18
10.1.5.16/30 intf 0 rslv 903 1 ge-2/1/10.18
10.1.5.16/32 dest 0 10.1.5.16 recv 901 1 ge-2/1/10.18
10.1.5.17/32 dest 0 0.e.80.3.0.21.59.d.c5.d9.0.21.59.d.c5.da.8.0
ucst 1243 12 ge-2/1/10.18
10.1.5.18/32 intf 0 10.1.5.18 locl 902 2
10.1.5.18/32 dest 0 10.1.5.18 locl 902 2
10.1.5.19/32 dest 0 10.1.5.19 bcst 900 1 ge-2/1/10.18
224.0.0.0/4 perm 2 mdsc 592 1
224.0.0.1/32 perm 0 224.0.0.1 mcst 576 3
224.0.0.5/32 user 1 224.0.0.5 mcst 576 3
255.255.255.255/32 perm 0 bcst 577 1
Router: PE3
Routing table: __master.anon__.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 909 1
0.0.0.0/32 perm 0 dscd 907 1
224.0.0.0/4 perm 0 mdsc 908 1
224.0.0.1/32 perm 0 224.0.0.1 mcst 904 1
255.255.255.255/32 perm 0 bcst 905 1
Router: PE3
Routing table: purple.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 918 1
0.0.0.0/32 perm 0 dscd 916 1
1.1.1.1/32 user 0 indr 1048576 3
10.1.3.9 Push 16 1187 2 ge-2/1/10.10
1.1.1.6/32 user 0 ulst 1048587 2
10.1.7.26 ucst 1239 4 ge-2/1/10.25
indr 1048579 3
10.1.5.17 Push 16, Push 299776(top) 1306 2 ge-2/1/10.18
1.1.1.7/32 user 0 10.1.8.30 ucst 1299 4 ge-2/1/10.29
299808(S=0) user 0 10.1.5.17 Pop 1304 2 ge-2/1/10.18
...In the default.inet routing table, which is the forwarding table, the line of output that starts with 10.1.2.4/30 shows that for a route to Device PE2 in the same AS, two next hops are installed in the table: 10.1.3.9 and 10.1.5.17.
In the purple.inet routing table, which is the external routing table, the line of output that starts with 1.1.1.6/32 shows that for a route to Device CE2 in AS3, an internal next hop of 10.1.5.17 and an external next hop of 10.1.7.26 are installed in the table. This indicates that both internal and external BGP routes are operational in the network.
user@PE3> show route forwarding-table destination
10.1.2.6
Router: PE3
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.1.2.4/30 user 0 ulst 1048580 2
10.1.3.9 ucst 999 8 ge-2/1/10.10
10.1.5.17 ucst 1243 12 ge-2/1/10.18
Router: PE3
Routing table: __master.anon__.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 909 1
Router: PE3
Routing table: purple.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 918 1
The line of output that starts with 10.1.2.4/30 shows that for a route from Device PE3 to Device PE2 in the same AS, two next hops are installed in the table: 10.1.3.9 through the ge-2/1/10.10 interface, and 10.1.5.17 through the ge-2/1/10.18 interface.
Meaning
Multiple next hops for a route, including external BGP routes, are installed in the forwarding tables.
Verifying Load Balancing While Using IP Header Filtering
Purpose
Verify that filtered traffic reaches the egress CE devices after load balancing has been configured on the PE devices.
Action
Configure a firewall filter on Device PE3 on the interface connecting to Device CE2.
Similarly, configure a firewall filter on Device PE3 on the interface facing Device CE3, and another on Device PE2 on the interface facing Device CE2.
Count the packets exiting the egress interfaces on Devices PE2 and PE3 by using the show firewall filter <filter name> counter <counter name> operational mode command. The output confirms if load balancing takes place with IP header filtering configured (enabled by the vrf-table-label statement). If all transmitted packets have been load-balanced between the paths PE3->CE2, PE3->CE3, and PE2->CE2, then it means that the IP header filtering feature works in a load-balanced Layer 3 network.
You can clear the counter by using the clear firewall filter <filter name> counter <counter name> operational mode command.
Meaning
Load balancing takes place with IP header filtering configured.