Cisco – Junos feature to accept multiple BGP paths from multiple peer AS

bgp bestpath as-path multipath-relax was introduced by CSCea19918. Normally eBGP load-balancing requires the candidate routes to be equal-cost paths; i.e. identical BGP attributes:

• same Weight
• same Local-Pref
• same AS-Path (both the AS numbers, and the AS path length)
• same Origin
• same MED
• different next-hop

As you mentioned, this command relaxes the same AS-Path requirement so any candidate eBGP AS-Path with the same AS-path length could be used for eBGP load-balancing (this will not load-balance between eBGP and iBGP paths). If you run BGP between multiple ISPs and you are looking for better egress load-balancing between your upstream connections this may help you out.

What problems can it potentially cause?

There isn't much danger as long as you're an enterprise customer that doesn't give transit service to another ASN; for a transit provider it might be perfectly safe, but I can't be sure there aren't routing loops if a transit ASN uses this feature. At first, I thought there would easily be a loop in transit ASN cases, on more reflection I can't find a real problem.

Why will it is rarely used?

Good question, it's been around since at least 2005.

See the JUNOS route selection process and you'll find that you end up at rule 9:

For BGP, prefer the path whose next hop is resolved through the IGP route with the lowest metric.

Note: A path is considered a BGP equal-cost path (and will be used for forwarding) if a tie-break is performed after the previous step. All paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor, are considered. BGP multipath does not apply to paths that share the same MED-plus-IGP cost yet differ in IGP cost. Multipath path selection is based on the IGP cost metric, even if two paths have the same MED-plus-IGP cost.

The default load-balancing of JUNOS is to set the next-hop for a BGP route over one of the IGP paths, i.e. not to install multiple IGP next-hops for a given BGP route. If you add a second prefix in addition to your 77/22 you will see how it picks another next-hop for it so to achieve load balancing of your traffic on a per-prefix level. This works well when you have a lot of prefixes and your traffic is spread over all or many of these prefixes. If you are only looking at one prefix though, you will not achieve any load balancing of traffic.

This behaviour can be changed. If you want to install all IGP next-hops you can set load-balancing to per-packet (which really isn't true on most platforms, it's hash-bashed). See this document for further explanation on load-balancing in JUNOS.

Exactly how to calculate which IGP next-hop is picked for a given BGP route is trickier. I don't know the internal workings of it but I assume it is based on a hash of the prefix.