BGP multipath with different ASNs feasible for production networks?
on Cisco (this command is hidden for some reason)
#bgp bestpath as-path multipath-relax
The default BGP behavior only installs only routes with exact the same AS_PATH into RIB. With multipath-relax, the AS_PATH only needs to be of the same length.
What problems can it potentially cause? Why isn't is used more often?
As a transit provider, does this feature complicate troubleshooting (I am thinking about end-user complaints about network performance)? Does it make it more difficult to know the path specific traffic took at a given time? Is there something else to that can assist troubleshooting. I am not sure about scalability and cost for NetFlow in SP network.
I've instructed several customers to use it, I've not heard of any issues. draft-lapukhov-bgp-routing-large-dc-05 heavily relies on this feature
I'm looking for a similar feature in Juniper JunOS... Is there any? http://networkengineering.stackexchange.com/questions/6735/junos-similar-feature-to-ciscos-bgp-bestpath-as-path-multipath-relax
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide your own answer and accept it.
bgp bestpath as-path multipath-relaxwas 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.
The basic issue is that the BGP speaker configured with "multipath-relax" gets into a control plane <-> data plane inconsistency; i.e. it advertises only the best path, but installs multiple paths in the forwarding that have different ASPATHs than the best. This breaks the basic tool BGP has to detect loops - ASPATH loop check. A (distorted) scenario below. I am sure you can come up with a better example with a bit more time at hand. ............... : R4 AS1 (10/8) /:.............. ..../...... : R5 AS2 :....\..... / \ ............... / --:--R1 R6 AS4 : \ AS3 \--------:--- R2 : / : R3 (10/8) :.............. In this example, - R3 in AS3 and R4 in AS1 announce a prefix 10/8. R5 in AS2 receives the prefix from R1(AS3) and R4(AS1). - AS2 is configured with 'multipath-relax' and chooses both paths for multipath forwarding, though it selects AS1's path as best. - R5 advertises the prefix with AS_PATH "2 1" to R6, and R6 in turn to R2. - Because of some specific policy, it is possible that R2(AS3) chooses R6's path as best. If it happens, there is a loop. Note that R1-R2-R3 represents the physical connectivity of the routers in AS3.
Thanks for the example. Do you mean R3 selects R4 as the best path for 10/8, R5 forwards part of the traffic to 10/8 back to AS3 at R1? Why is this caused by multipath-relax? Without multipath-relax, the R2 - R6 - R5 -R1 loop can still exist if there isn't proper outbound filtering( or simple 10/8 to null0 at the originating AS). It appears to me the issue here is BGP hijacking. Am I understanding it wrong?
No. What I mean is: (a) R3 has its own external best path, (b) R1 chooses R3 as the best, but because of the physical connectivity, has to send traffic towards R2 to reach R3, (c) R2 selects the external path (received from R6) as best. This is related to multipath-relax, since R5 chooses a path from AS3 for multipath forwarding that it does not disclose. Thus ASPATH loop prevention technique fails in AS3.
I still don't get how this could be prevented without multipath-relax. R1 sends traffic to 10/8 via R2 and R2 chooses R6 as exit (weight), R5 can choose R1 as best for 10/8 even without multipath-relax and cause a loop. ASPATH loop prevent cannot prevent loops caused by preferring an external exit point for internal network. If R1 picks R5, R2 picks R6 as best for 10/8, loop is formed regardless, no?