Go Configure!

BGP Multipath

4 min read

Most routing protocols, and static routes for that matter, will load balance over a certain amount of equal-cost paths out of the box, but BGP requires the BGP Multipath feature to be administratively enabled. This tutorial explains how to enable BGP Multipath on a Cisco router, and why we would want to do so.

What is an equal cost path? 

An equal-cost path is when multiple network paths from a source to a destination look equally favourable to the source router.

To be considered equal-cost, each path must have the following identical BGP path selection attributes:

  • Weight (Cisco only)
  • Local Preference
  • Origin
  • AS_PATH Length
  • MED
  • IGP metric

In addition to the above the next-hop IP addresses are expected to be different (this requirement can be removed with additional configuration – see this blog for additional information).

Video Tutorial

Take a look at the video which goes through the BGP Multipath configuration and validation steps.

What is BGP Multipath?

If you’d prefer to read on, here is the main topology and explanation:

Default BGP Behaviour.

BGP Multipath example topology

Let’s assume that we’ve configured standard eBGP on both Paris and London routers. The Paris router learns about the route located in London via both the and the neighbours.

With BGP’s default configuration only one of the routes appears in the routing table. It is this one link that will be used for all traffic to the network in London.

If we break the currently in use link by shutting down the associated interface on the Paris router, then BGP will failover to the other link instead.

But, we want to use both links at the same time; not to wait for one to fail. What a waste of available bandwidth! To make this happen we can use BGP Multipath. 

Configuring BGP Multipath

It is a very simple configuration, we go under the Paris router’s BGP process and enter the command maximum-paths 2

Remember that only equal-cost paths are eligible to be used for load-balancing. In the video I altered the local preference BGP attribute on just one of the links to prevent the links being seen as equal cost. This prevented multipath from taking effect.

There you go, multiple next hops should be available to use. Remember we we would also have to apply the BGP Multipath configuration on both routers if we wanted equal cost load balancing to work bi-directionally. 

Although this article focuses on eBGP, BGP Multipath works the same way on iBGP too.

Verification of BGP Multipath

There are several commands we can use to verify the correct operation of BGP Multipath over equal-cost links. 

One way is to look at the BGP RIB – show ip bgp. As in the below screenshot we can see that there are two listed next-hops for the network and crucially the route which does not have the greater than symbol next to it, has the letter “m” which denotes that multipath is in use for that route.

show ip bgp output showing multipath "m" denotation

Another way would be to look at the routing table with show ip route where we can see both next-hops displayed:

output from the routing table showing BGP paths

To be absolutely sure, you may wish to look inside the forwarding table (learn more about the FIB/CEF here) with show ip cef this command shows the hardware will actually do when forwarding packets. Again, both next-hops are shown for the prefix, and we can also see the exit interface in the right-most column:

output from show ip cef

Ok, ok, I get it you’re a stickler for verification. Another way to do this would be to simply run some traceroutes to the destination prefix. If you see different next-hops in your traceroutes then you’re golden.

Are there any gotchas to using BGP multipath?

The default load balancing with BGP Multipath uses is per-packet load balancing. Packet A goes down Link 1 Packet B goes down Link 2. 

In scaled up deployments of multipath with more intermediate hops, it’s possible that particularly VOIP or even sensitive TCP applications may baulk at having out of order packets. There may be higher rates of retransmissions as a result, potentially impacting user-experience. Most modern applications, and certainly cloud-era applications can cope with this absolutely fine. 

CEF is able to use other load-balancing methods such as per-flow, which may be more suitable in your environment – as always, a test environment may be a good place to iron this out.

I hope this tutorial helped you understand the fundamentals of equal-cost load balancing using BGP Multipath. I’d encourage you to give it a go yourself in GNS3 or your go-to network emulator/simulator!