menu

Unequal Cost load-balancing with BGP

Did you know that you can loadbalance over unequal cost paths with BGP, just as we can do with EIGRP?

It is true. As long as bestpath selection is equal for all attributes up to MED – weight, local pref, as_path, origin, metric. And the neighbor type have to be external. To enable this feature in EIGRP we have to rely on the feasibility check to be sure that we avoid routing loops, in BGP we rely on the AS-path check. So for external routes with equal attributes including MED we can import multiple paths and loadbalance between them.

A quick lookback at the attributes and path selection

The path attributes used for best path decision is:

  1. weight
  2. local preference
  3. locally injected
  4. shortest AS_PATH
  5. Origin
  6. MED/Metric
  7. neighbor type
  8. IGP metric to next_hop

Tiebreakers:

  1. Keep the oldst eBGP path
  2. Lowest RID
  3. Lowest neighbor id

So to accomplish a topology that fulfills these requirements we can use a single router which is dualhomed, and simply not do any PA manipuliation. The link between R1 – R3 is gigabit, and the link between R2 – R3 is fast ethernet.

R3 has two eBGP peerings to AS100. We dont configure anything else than BGP peering and advertise a prefix from AS100.

On R3 we can now see that both our eBGP peers are advertising the prefix 1.1.1.1/32.

Currently only one of the paths are being used, the oldest one.

Importing multiple paths

Next step would also be simple, we need to tell BGP on R3 to use more than one path and install them to its RIB:

We added the “maximum-paths” command, and as expected we now see two paths imported – not really rocket science.

What we see more in the output of “sh ip bgp 1.1.1.1/32” is that “multipath” is added to both paths.

We can also see in the routing table that both are actually installed and used, but the traffic share count is 1 on both. Even though one interface is gigabit and the other is fast ethernet. This is what we would want to loadbalance with a traffic share in the same ratio as the bandwidth.

Unequal cost taken into consideration

The command used here is called “dmz-link bw”. The idea with the name is that it is used to take the bandwith from the interfaces into consideration. Configuration is still quite simple:

  1. Enable the function globally under the BGP process.
  2. Enable the function on each BGP neighbor that we want to apply the unequal cost load-balancing to.

And that should be it. Now since one path is gig and the other one 100mbit, I would expect the traffic share to be a ratio of 1:10. We could also ofcourse manipulat this more with the interface command bandwidth. 

Now let’s see the final output from the routingtable of R3:

  Note that now the traffic share count is 1 and 10, only one tenth of the traffic should be directed over the fastethernet link.

Leave a Reply

Your email address will not be published. Required fields are marked *