Load Balancing

<Course Title> and Filter-Based

LY
Forwarding

N
O
SE
U
AL
N
R
TE
IN
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Equal-Cost Multipath Load Sharing

N

Equal-cost multipath load sharing (or load balancing) enables the ability to distribute traffic destined
to the same destination prefix over paths with equal costs. Using equal-cost paths for traffic destined
R

to the same destination prefix allows you to make use of redundant paths simultaneously rather
than one of multiple paths.
TE

Load-balancing methods include per-packet and per-flow. We cover these methods in detail on
subsequent pages.
IN

2 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Per-Packet Load Balancing

N

When a router performs per-packet load balancing, it forwards packets, in a round-robin fashion, out
the egress interfaces, which connect to the equal-cost paths that lead to the destination. This
R

load-balancing method appears to have some key benefits, such as equal distribution over the
equal-cost paths; however, per-packet load balancing can actually decrease network performance.
TE

In the example on the slide, R1 receives two packets (Packet A and Packet B). R1 sends Packet A out
one interface and Packet B out the other interface. R2 receives both packets and forwards them on
to the destination. There is no guarantee that R2 will receive and process Packet A before Packet B.
Assuming that both packets belong to a common session (or flow), this out-of-sequence processing
might require the destination device to reorder the packets or the source device to retransmit the
IN

packets, thus causing a reduction in performance.

Note that modern Junos devices do not implement per-packet load balancing. We highlight the
current load-balancing implementation used in modern Junos devices in greater detail on a
subsequent slide.

www.juniper.net 3
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Per-Flow Load Balancing

N

Unlike per-packet load balancing, per-flow load balancing maintains individual traffic flows between
end stations, which results in a number of benefits. One benefit is that the packets generally arrive
R

at the destination in the order they were sent. Thus, the end station does not have to reorder the
packets, and the applications experience less delay. In addition, because similar user traffic uses
TE

the same path through the network, network-wide policies such as quality of service (QoS) are easier
to implement. All protocols—not just TCP—can benefit from the establishment of flows through a
network.
By default, the Junos operating system considers traffic that enters the same ingress interface and
has the same source and destination addresses and the same protocol a single flow. You can
IN

change the elements of a packet that constitute a flow to include Layer 3 and Layer 4 port data. We
cover the required configuration for this option on a subsequent slide.
All traffic belonging to the same flow is forwarded by the system out the same egress interface. The
example on the slide illustrates two distinct traffic flows that R1 forwards out ge-0/0/2 and
ge-0/0/3, which are the egress interfaces associated with the equal-cost paths that lead to the
destination network.

4 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Default Behavior for the Junos OS

N

The default IGP load-balancing behavior for the Junos OS is to choose one of the available equal-cost
paths over which traffic for the received destination prefixes will be sent. This process comes down
R

to an issue of control. You know exactly where traffic is flowing on your network at any point in time.
So when multiple, equal-cost paths exist in the routing table, the Junos OS selects one of the next
TE

hops from the available next-hop set and installs that next hop into the forwarding table.
If the information in the next-hop set changes, the Junos OS repeats the selection process. The
next-hop set could change because of the addition or subtraction of a next hop. It could change
because of the actual next-hop value changing for any of the possible paths.
IN

The default BGP load balancing is slightly different from the load balancing described previously,
which applies to IGPs. The default BGP load balancing is known as per-prefix load balancing.
Per-prefix load balancing occurs when routes are received from an internal BGP peer and some of
those routes have identical BGP next-hop attributes (an IP address). When the router performs the
lookup to find the BGP next-hop attribute value, the router might find multiple, equal-cost paths to
that IP address. In this case, the total number of received BGP routes that fits this criterion are
spread across the available network paths. However, each individual BGP route still uses only one
path through the network.
Continued on next page.

www.juniper.net 5
Load Balancing and Filter-Based Forwarding
Default Behavior for the Junos OS (contd.)
For example, suppose that IBGP advertises 100 routes from R2 to R1. R2 performs a next-hop self,
so R1 now has multiple, equal-cost paths to R2’s loopback address. In this case, the 100 routes will
be randomly distributed across the equal-cost paths to R2. Note that a perfect distribution of the
routes is not guaranteed because of the nature of the hashing algorithm used to select a next hop for
a given prefix. In operation, the actual load-balancing distribution approximates an ideal distribution
when a large number of prefixes is being factored.
The Junos OS gives you policy controls to alter these default load-balancing behaviors.

LY
N
O
SE
U
AL
N
R
TE
IN

6 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Viewing the Tables

N

The slide highlights the routing table and forwarding table when the default behavior is in effect.
Notice that only the selected next hop is installed in the forwarding table for the referenced
R

destination prefixes. On a subsequent slide, we show a sample capture once the default
load-balancing behavior has been altered to contrast with this output.
TE
IN

www.juniper.net 7
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Changing the Default Behavior

N

You can alter the default load-balancing behavior using routing policy. Once a load-balancing policy is
properly defined and applied, you see all equal-cost paths installed in the forwarding table as shown
R

on the slide. You can contrast this sample output with the output shown in the previous section
where a load-balancing policy is not in place. We examine load-balancing configuration examples on
TE

subsequent slides in this section.

IN

8 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Configuration Examples
N

To load-balance traffic for all routes in the routing table, create a policy that matches all routes or
select routes similar to the examples shown on the slide. The top example matches all destination
R

prefixes because no from statement is configured. The second example matches only the listed
destination prefixes using the from statement.
TE

Because we are working with routing policy, we can use any of the policy match criteria to decide
which routes are load-balanced and which routes are not load-balanced.
The action for both policies is load-balance per-packet. This action does not necessarily
mean the software will perform a per-packet load-balancing operation. The actual load-balancing
IN

operation is platform dependant and is discussed in greater detail on the next slide.
To perform load balancing, you must apply this policy as an export policy under the [edit
routing-options] configuration hierarchy to the forwarding table. Once committed, this
configuration starts to load-balance traffic for all routes having multiple, equal-cost paths through
the network. We show a policy application example on a subsequent slide.
Keep in mind that a load-balancing policy affects only the local router’s forwarding behavior. To have
all routers in the network load-balance traffic, you must create and apply a similar policy on each
router.

www.juniper.net 9
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Behavior Is Platform Dependent

N

The load-balancing policy created in the Junos OS always contains the same configuration syntax of
load-balance per-packet. However, the actual load-balancing behavior is platform
R

dependent.
For platforms with the Internet Processor II functionality, packets are forwarded based on traffic
TE

flows. Depending on the actual platform and hardware, you can install up to 64 equal-cost paths in
to the forwarding table. Check your product-specific documentation for support details. With the
per-flow load-balancing method, all packets headed for a destination route that contain the same
flow characteristics are all forwarded out the same outbound interface. This process avoids issues of
packet arrival sequence and the need to resequence packets, which can slow TCP operation
IN

considerably.
For older routers still using the Internet Processor I ASIC, the balancing behavior is truly per-packet.
The traffic is spread across the active equal-cost paths randomly, with the forwarding table
performing the load distribution. Each packet that matches a destination route is forwarded across a
different outbound interface in a round-robin fashion. The Internet Processor I ASIC can support up
to eight different equal-cost paths per destination route.

10 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Applying a Load-Balancing Policy

N

Once the load-balancing policy is defined, you must apply the policy as an export policy under the
[edit routing-options] configuration hierarchy to the forwarding table. Once committed, this
R

configuration starts to load-balance traffic for the routes referenced within the routing policy that
have multiple, equal-cost paths through the network.
TE

Note that defining and applying a load-balancing policy affects only the forwarding table. The routing
table remains as it was before you defined and applied the load-balancing policy.
IN

www.juniper.net 11
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Determining Traffic Flows

N

By default, the Junos OS considers traffic that enters the same ingress interface and has the same
source and destination addresses and the same protocol a single flow. You can change the elements
R

of a packet that constitute a flow to also include Layer 4 port data. Once the software determines the
criteria for a given flow, the system forwards all traffic that matches the flow out the same egress
TE

interface.

Including Port Data when Determining Traffic Flows

If you want the flow calculation to include IP Layer 4 source and destination port information along
IN

with the default Layer 3 parameters, you must configure the hash-key accordingly under the
[edit forwarding-options] section. An example of the required configuration is shown on
the slide. Note that you must include both the Layer 3 and Layer 4 options and not just the Layer 4
option. If you omit the Layer 3 option, the Junos OS will not use all of the listed Layer 3 and Layer 4
parameters when determining the flow calculation.
You can also optimize MPLS and VPLS flows by modifying the hash-key options under the [edit
forwarding-options] section using the appropriate set family mpls and set family
multiservice statements respectively.
By default, IP version 6 (IPv6) packets are automatically load-balanced based on Layer 3 and Layer 4
information and traffic class.

12 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Topology and Objectives

N

The slide displays the topology and objectives for our case study.
R
TE
IN

www.juniper.net 13
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Configuring Load Balancing

N

The slide displays the required configuration to accomplish the stated objectives on the previous
slide. Remember that a commit is required once the highlighted configuration tasks are complete.
R
TE
IN

14 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Monitoring Load Balancing

N

The slide shows the output for the show route forwarding-table command, which is the
primary verification step to ensure that the load-balancing policy took effect. In the sample output,
R

we see that both forwarding next hops were installed in the forwarding table for both destination
prefixes.
TE
IN

www.juniper.net 15
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Test Your Knowledge

N

Assuming we still have the previously defined configuration in place, R1 will select one of the two
equal-cost paths. Remember that our load-balancing policy matched only on the 172.24.0.0/24 and
R

172.24.1.0/24 prefixes.
[edit policy-options]
TE

user@R1# show
policy-statement load-balance {
from {
route-filter 172.24.0.0/24 exact;
IN

route-filter 172.24.1.0/24 exact;

}
then {
load-balance per-packet;
}
}
If you want to match on all destination prefixes with equal-cost paths, you must remove the from
statement from the load-balancing policy.

16 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Traditional Routing
N

In a typical routing scenario, a router looks only at the incoming packet’s destination address when
determining the forwarding next hop. Although this approach works, it does not provide much
R

flexibility. We discuss filter-based forwarding on the next slide, which provides you with flexibility for
determining distinct forwarding paths for traffic based on a wide variety of options.
TE
IN

www.juniper.net 17
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Filter-Based Forwarding
N

Filter-based forwarding allows a router to make forwarding decisions based on criteria in addition to
the destination prefix. A match filter is created and applied to the interface on which traffic is
R

received. The Junos OS uses the filter to classify packets and determine their forwarding path within
the router.
TE

Filter-based forwarding is supported for Internet Protocol version 4 (IPv4) and Internet Protocol
version 6 (IPv6).
As shown on the slide, you can use filter-based forwarding for service-provider selection when you
have Internet connectivity provided by different ISPs. We illustrate the configuration and verification
IN

steps for filter-based forwarding in the next section.

18 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Configuring Filter-Based Forwarding

N

The slide illustrates the three primary configuration tasks when implementing filter-based
forwarding. The subsequent slides provide configuration examples for these stated configuration
R

tasks.
If you are planning to implement filter-based forwarding, you should know that source-class usage
TE

filter matching and unicast reverse-path forwarding checks are not supported on interfaces
configured for filter-based forwarding. We do not cover source-class usage or unicast reverse-path
forwarding (RPF) in this material. For more details on these topics, refer to http://www.juniper.net.
IN

www.juniper.net 19
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Step 1: Create and Apply a Match Filter

N

The slide shows a sample match filter configuration. Match filters are standard firewall filters used to
classify traffic based on a desired match criteria, such as source IP address. You use an action of
R

routing-instance along with the name of the desired routing instance to which you want the
traffic forwarded. We define the routing instance in the next step, and we provide a sample
TE

configuration on the next slide.

Although not explicitly shown on the slide, you must apply the match filter as an input filter on the
ingress interface where the traffic will be received. We provide a full configuration example, which
includes the definition and application of a match filter, in the case study later in this section.
IN

Remember that the default action for traffic not specifically permitted through a firewall filter is
discard. Because of this default action, you should ensure that all traffic is accounted for in the
defined firewall filter. We highlight this point on a subsequent slide.

20 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Step 2: Create the Routing Instances

N

Once a packet meets the criteria defined within the match filter, that packet is evaluated against the
routing table associated with the routing instance specified in the match filter’s action statement.
R

The software then forwards the packet to the next hop that corresponds to the destination address
entry in the routing table associated with the routing instance. You can include a default static route,
TE

as shown in the example on the slide, or you can include less specific static routes. These static
routes typically use a forwarding next hop IP address, but can also direct traffic to a different routing
instance using the next-table option, as shown in the following capture:
routing-instances {
IN

instance-name {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
}
As illustrated on the slide, you create routing instances that specify the routing tables and the
destination to which a packet is forwarded at the [edit routing-instances] hierarchy level.
The instance type used for filter-based forwarding is forwarding. The number of routing instances
you define depends on the number of next-hop forwarding paths you will use.

www.juniper.net 21
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Step 3: Create a RIB Group

N

In this step you create a routing table (or RIB) group that adds interface routes to the forwarding
routing instances used in FBF, as well as to the default routing instance inet.0. This part of the
R

configuration resolves the routes installed in the routing instances to directly connected next hops
on that interface. You create routing table groups at the [edit routing-options] hierarchy
TE

level.
The configuration example on the slide installs interface routes into the default routing instance
inet.0, as well as the instance-name.inet.0 routing tables. You must specify inet.0 as
one of the routing instances that the interface routes are imported into. If inet.0 is not specified,
interface routes are not imported into the default routing instance.
IN

22 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Topology and Objective

N

The slide provides us with the topology and objective for the case study.
R
TE
IN

www.juniper.net 23
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Configure the Match Filter

N

The slide displays the sample match filter configuration.

R
TE
IN

24 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Apply the Match Filter

N

The slide shows the application of the match filter defined on the previous slide.
R
TE
IN

www.juniper.net 25
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Configure the Routing Instances

N

The slide shows the sample configuration of the routing instances that will be used to establish
distinct forwarding paths within R1.
R
TE
IN

26 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Configure the RIB Group

N

The slide shows a sample RIB group, which is used to share interface routes. You must share
interface routes for next-hop resolution when forwarding traffic between routing instances.
R
TE
IN

www.juniper.net 27
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Verify the Results—Part 1

N

Once the configuration shown on the previous slides is committed, you can verify the entries in the
relevant routing tables using the show route table table-name command. The slide shows
R

the contents of the ISP-A.inet.0 routing table, which includes all interface routes for inet.0,
ISP-A.inet.0, and ISP-B.inet.0, along with the default static route defined for the routing
TE

instance.
Continued on next page.
IN

28 www.juniper.net
 Load Balancing and Filter-Based Forwarding
Case Study: Verify the Results—Part 1 (contd.)
The contents of the ISP-B.inet.0 routing table are identical and are shown in the following
output:
user@R1> show route table ISP-B.inet.0

ISP-B.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 03:32:41

> to 172.20.1.2 via ge-0/0/3.0
172.20.0.0/30 *[Direct/0] 03:32:41
> via ge-0/0/2.0

LY
172.20.0.1/32 *[Local/0] 03:19:07
Local via ge-0/0/2.0
172.20.1.0/30 *[Direct/0] 03:32:41
> via ge-0/0/3.0

N
172.20.1.1/32 *[Local/0] 03:19:09
Local via ge-0/0/3.0
172.25.0.0/24 *[Direct/0] 03:32:41

O
> via ge-0/0/1.0
172.25.0.1/32 *[Local/0] 03:19:09
Local via ge-0/0/1.0
172.25.1.0/24 *[Direct/0] 03:32:41

172.25.1.1/32
> via ge-0/0/1.0
*[Local/0] 03:19:09
Local via ge-0/0/1.0 SE
U
AL
N
R
TE
IN

www.juniper.net 29
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Verify the Results—Part 2

N

As indicated on the slide, you can also perform a traceroute operation from a host on the subnets for
which FBF is being performed to verify that the traffic takes the correct forwarding path.
R

As stated earlier, our objective was to ensure that traffic sourced from the 172.25.0.0/24 subnet
used ISP A and traffic sourced from the 172.25.1.0/24 subnet used ISP B. The captures shown on
TE

the slide, which display the traceroute results from hosts on the two previously mentioned subnets,
indicate that our FBF implementation works as designed.
IN

30 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Test Your Knowledge

N

This slide is designed to make you think through the overall affects of the configuration implemented
in the preceding case study.
R

Continued on next page.

TE
IN

www.juniper.net 31
Load Balancing and Filter-Based Forwarding
Test Your Knowledge (contd.)
Because the configuration used in the preceding case study only accepts traffic sourced from the
172.25.0.0/24 and 172.25.1.0/24 subnets, you must either modify the existing terms or include a
third term to accept traffic with a different source address. The following example illustrates the use
of a third term named else-accept which permits all other traffic:
[edit firewall]
user@R1# show family inet filter my-match-filter
term match-subnet-A {
from {
source-address {
172.25.0.0/24;
}

LY
}
then {
routing-instance ISP-A;
}

N
}
term match-subnet-B {
from {

O
source-address {
172.25.1.0/24;
}
}

}
then {

}
routing-instance ISP-B;

term else-accept {
SE
U
then {
accept;
}
AL

}
The else-accept term accepts all traffic that does not match the preceding terms. The system
forwards the traffic that matches the else-accept term out the appropriate egress interface
using the normal route lookup process based on the destination prefix. We recommend you use a
N

similar approach when implementing filter-based forwarding so traffic is not dropped unintentionally.
R
TE
IN

32 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Using the instance-import Option

N

In earlier releases of the Junos OS, interinstance route sharing often required configuration of
routing table groups by means of the rib-group statement. Although these configurations
R

performed well, the routing table group technique has several limitations:
• Lack of intuitiveness—A routing table group is an unfamiliar configuration construct for
TE

many users.
• Complex configuration requirements—Routing table groups specify a primary import
routing table that must match the routing table of the VRF instance on which they are
applied. Thus, a different routing table group is defined for each of the instances that
IN

participate in interinstance route export.

• Redundancy—The information imported and exported by the routing table groups is
already present in the router or can be deduced from most configurations (for example,
overlapping VPNs).
• Per-protocol configuration—Routing table groups must be applied to every protocol
containing routes designated for export.

www.juniper.net 33
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Configuring the instance-import Option

N

In Junos Release 5.4 and later, you can use the instance-import policy keywords to perform
nonforwarding, interinstance route sharing. The keywords are assigned at the [edit
R

routing-instances instance-name routing-options] hierarchy level.

In the example on the slide, no routes currently exist in the ISP-A.inet.0 route table. After
TE

committing the configuration shown on the slide, we verify on the next slide that the routes from the
inet.0 table have been imported into the ISP-A.inet.0 table.
IN

34 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Verify the Results

N

Using the same example as in the previous FBF case study, you can see that the results are the
same. All inet.0 routes have been imported.
R
TE
IN

www.juniper.net 35
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Multitopology Routing Basics

N

Although detailed coverage of Multitopology routing is outside the scope of this material, we will go
over some basics. Multitopology routing enables you to configure class-based forwarding for different
R

types of traffic, such as voice, video, and data. Each type of traffic is defined by a topology that is
used to create a new routing table for that topology. Multitopology routing provides the ability to
TE

generate forwarding tables based on the resolved entries in the routing tables for the custom
topologies you create. In this way, packets of different classes can be routed independently from one
another.
IN

36 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Configuring Topologies
N

For Multitopology routing to run on the router, you must configure one or more topologies. For each
topology, you specify a string value, such as video, that defines the type of traffic, as well as an
R

interface family, such as IPv4 or IPv6. Each topology that you configure creates a new routing table
and populates it with direct routes from the topology.
TE
IN

www.juniper.net 37
Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Configuring Filter-Based Forwarding for Multitopology Routing

N

Normally, each routing instance supports only one default topology to which all forwarding classes
R

are forwarded. With Multitopology routing, you can configure a firewall filter on the ingress interface
to map a specific forwarding class, such as expedited forwarding, with a specific topology. The traffic
that matches the specified forwarding class is then added to the routing table for that topology.
TE
IN

38 www.juniper.net
 Load Balancing and Filter-Based Forwarding

LY
N
O
SE
U
AL

Case Study: Apply the Match Filter

N

The slide shows the application of the match filter defined on the previous slide.
R
TE
IN

www.juniper.net 39