Per-packet load balancing in routing-instance

By default, whenever there are multiple next-hops available to a destination, Junos installs only one next-hop in the forwarding-table, although the routing-table will show both next-hops.

The user has the possibility to install multiple next-hops in the forwarding-table for the active route. This is called per-packet load balancing. Keep in mind that the load balancing is done per flow, not per packet. The name of the feature might lead to misinterpretation.

The per-packet load balancing is achieved by configuring a policy-statement with a key knob which is then exported under “routing-options forwarding-table” configuration stanza.

This is how is done. This is the policy:

[edit]
root@r2# show policy-options
policy-statement lb {
    then {
        load-balance per-packet;
    }
}

[edit]
root@r2#

And this is how it is exported:

[edit]
root@r2# show routing-options
forwarding-table {
    export lb;
}

[edit]
root@r2#

But how about if you need to achieve per-packet load balancing for routes in a routing-instance?

Let’s consider this topology:

R2 will learn the 1.1.100.6/32 route in both routing-instances through OSPF.

Well, you cannot configure per-packet load-balancing by exporting the policy inside the routing-instance configuration. There is no such command:

[edit]
root@r2# set routing-instances VRF-12 routing-options forwarding-table ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  unicast-reverse-path  Unicast reverse path (RP) verification
[edit]
root@r2#

The good thing is that once you configure per-packet load balancing in default route table, it will be applied for the routes in all the routing-instances.

Let’s check on R2 how 1.1.100.6/32 route is seen in the routing table and forwarding-table for the two routing-instances:

[edit]
root@r2# run show route 1.1.100.6

VRF-12.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.100.6/32       *[OSPF/10] 00:23:18, metric 1
                    > to 1.1.20.6 via ge-0/0/3.200
                      to 1.1.10.6 via ge-0/0/3.100

VRF-34.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.100.6/32       *[OSPF/10] 00:23:18, metric 1
                      to 1.1.40.6 via ge-0/0/3.400
                    > to 1.1.30.6 via ge-0/0/3.300

[edit]
root@r2#

And this is the forwarding-table for the route:

[edit]
root@r2# run show route forwarding-table family inet destination 1.1.100.6
Routing table: VRF-12.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.100.6/32       user     0 1.1.20.6           ucst      629     4 ge-0/0/3.200

Routing table: VRF-34.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.100.6/32       user     0 1.1.30.6           ucst      628     4 ge-0/0/3.300

[edit]
root@r2#

So we want to achieve per-packet load balancing only for 1.1.1006/32 route in routing-instances.

Once this configuration is applied:

[edit]
root@r2# set policy-options policy-statement lb from route-filter 1.1.100.6/32 exact

[edit]
root@r2# set policy-options policy-statement lb then load-balance per-packet

[edit]
root@r2# set routing-options forwarding-table export lb

We can see both next-hops installed in the forwarding-table.

[edit]
root@r2# run show route forwarding-table family inet destination 1.1.100.6
Routing table: VRF-12.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.100.6/32       user     0                    ulst   262142     2
                              1.1.20.6           ucst      629     2 ge-0/0/3.200
                              1.1.10.6           ucst      627     2 ge-0/0/3.100

Routing table: VRF-34.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.100.6/32       user     0                    ulst   262143     2
                              1.1.40.6           ucst      630     2 ge-0/0/3.400
                              1.1.30.6           ucst      628     2 ge-0/0/3.300

[edit]
root@r2#

But let’s say that you want to load balance the traffic towards 1.1.100.6/32 prefix only for routing-instance VRF-12.

You will need to add another match criteria to the export policy, like this to specify for which routing-instance you want to load balance the traffic:

[edit]
root@r2# show policy-options
policy-statement lb {
    from {
        instance VRF-12;
        route-filter 1.1.100.6/32 exact;
    }
    then {
        load-balance per-packet;
    }
}

[edit]
root@r2#

Now, the traffic is load balanced only for routing-instance VRF-12:

[edit]
root@r2# run show route forwarding-table family inet destination 1.1.100.6
Routing table: VRF-12.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.100.6/32       user     0                    ulst   262142     2
                              1.1.20.6           ucst      629     2 ge-0/0/3.200
                              1.1.10.6           ucst      627     2 ge-0/0/3.100

Routing table: VRF-34.inet
Internet:
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.100.6/32       user     0 1.1.30.6           ucst      628     4 ge-0/0/3.300

[edit]
root@r2#

So now you know what is the default behaviour applied to routing-instances routes when you configure globally the per-packet load balancing.

Also, you saw a way how to match specific routes from specific routing-instances to which per-packet load balancing will be applied.

I hope you found this post useful.

The following two tabs change content below.

• Bio
• Latest Posts

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Latest posts by Paris ARAU (see all)

• Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
• Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
• Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
• Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
• Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018