2

I read a Junos documentation which said that:

In case of equal-cost paths for the same destination, the routing protocol daemon(rpd) randomly selects one of the available paths to balance load, while maintain packet ordering in case of equal paths

In addition, there was a following screenshot illustrating this statement:

equal-cost paths

When I try to replicate this behavior on MX series router, then looks like the random selection does not work:

root@vmx> show route 10.1/16    

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

10.1.1.0/24        *[Static/5] 00:00:01
                      to 172.20.66.2 via ge-0/0/4.0
                    > to 172.20.77.2 via ge-0/0/5.0
10.1.2.0/24        *[Static/5] 00:00:01
                      to 172.20.66.2 via ge-0/0/4.0
                    > to 172.20.77.2 via ge-0/0/5.0
10.1.3.0/24        *[Static/5] 00:00:01
                      to 172.20.66.2 via ge-0/0/4.0
                    > to 172.20.77.2 via ge-0/0/5.0
10.1.4.0/24        *[Static/5] 00:00:01
                      to 172.20.66.2 via ge-0/0/4.0
                    > to 172.20.77.2 via ge-0/0/5.0

root@vmx> 

What might cause this?

3
+50

The short answer is that what you're seeing is a cosmetic issue. The > placement doesn't matter.

Routing Table

As you can see, 3 of the routes in my lab are appearing similarly to the example you provided. However, the actual forwarding is determined by looking at the forwarding table.

root@vmx1# run show route protocol static

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

10.10.0.0/24       *[Static/5] 00:00:45
                    > to 1.1.1.2 via ge-0/0/0.0
                      to 3.3.3.0 via ge-0/0/2.0
10.20.0.0/24       *[Static/5] 00:00:09
                      to 1.1.1.2 via ge-0/0/0.0
                    > to 3.3.3.0 via ge-0/0/2.0
10.30.0.0/24       *[Static/5] 00:00:09
                    > to 1.1.1.2 via ge-0/0/0.0
                      to 3.3.3.0 via ge-0/0/2.0
10.40.0.0/24       *[Static/5] 00:00:09
                    > to 1.1.1.2 via ge-0/0/0.0
                      to 3.3.3.0 via ge-0/0/2.0

Forwarding Table

I just have one route as an example, but they would all appear the same way. As Jeff Wheeler mentioned, you do need the load-balance per-packet policy configured, please note that per-packet is a misnomer in Juniper, it does actually mean per-flow.

The ulst entry, stands for unicast list (of ucst next-hops), as you can see both interfaces are present. Random selection happens between anything present in a ulst. This is the authoritative place to verify forwarding behavior.

root@vmx1# run show route forwarding-table destination 10.10.0.0/24
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.10.0.0/24       user     0                    ulst   262142     5
                              1.1.1.2            ucst      556     3 ge-0/0/0.0
                              3.3.3.0            ucst      559     3 ge-0/0/2.0

Forwarding Table (without load-balance per-packet)

Conversely, if we remove the policy, you would see the same output from show route, but the forwarding behavior would only select one next-hop. The key difference here is that ulst is not present, meaning that no load balancing will occur.

root@vmx1# run show route forwarding-table destination 10.10.0.0/24
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.10.0.0/24       user     0 1.1.1.2            ucst      556     5 ge-0/0/0.0
1
  • 1
    Thanks! I tried this out in practice by creating several traffic flows to addresses in the networks seen in the output of show route protocol static command. Traffic is indeed load-balanced per-flow. Looks like some sort of hashing algorithm is used to load-balance the traffic. – Martin May 18 '20 at 21:39
1

Is it possible you were reading a document for a platform that doesn't support load-balance per-packet? Perhaps you can link where you were reading.

The vMX will allow you to install both routes at once. Configure as below, and see the documentation for details.

routing-options {
    forwarding-table {
        export FWDTBL;
    }
}
policy-options {
    policy-statement FWDTBL {
        term all {
            then {
                accept;
                load-balance per-packet;
            }
        }
    }
}
2
  • 1
    It was a JNCIA-Junos study material at Junos Genius environment. I tried with the per-packet load-balance mode, but unfortunately it didn't help. I also configured enhanced-ip mode under chassis configuration and rebooted the vMX, but the random selection does not work. There are no "unsupported platform" or similar comments in the configuration. – Martin May 16 '20 at 9:42
  • Maybe they've used a generous definition of "random" on the vMX implementation. – Jeff Wheeler May 16 '20 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.