Hello, I am currently familiarizing myself with the BGP Multipath Algorithm and unfortunately, I haven’t found much information about it, especially for Cisco. I came across a lot of material about it on Juniper.
Does the algorithm support ECMP (Equal Cost Multi-Path Routing) and Multipathing for Unequal Bandwidth? Are there other methods that Cisco supports as well? Additionally, what about Per-Destination and Per-Packet Load Balancing? Juniper supports these features, but does Cisco also support them?
By default, BGP will only advertise the best path for a particular destination. However, it is possible to configure BGP to load balance traffic using several methods, both for ECMP and unequal-cost multipath routing. Specifically, you can take a look at these lessons:
You can also find information at the following NetworkLessons notes:
Finally, for more information about fine-tuning your BGP configuration to get a more specific split of load balancing, you can use BGP traffic engineering, a technique that helps you optimize and control traffic flow. More info can be found at this NetworkLessons note on BGP traffic engineering as well as at the following post:
Take a look at this content and if you have further questions on the specific topic, let us know!
Why didn’t you configure next-hop-self on the two border routers in iBGP multipath example? It doesn’t look like you advertised the external links to OSPF as an alternative
You bring up a good point here. If we try to ping 4.4.4.4 from R1 in the iBGP example in the lesson, the ping will fail. This is because R1 sees the IP addresses of the Gi0/1 and Gi0/2 interfaces of R4 as the next hop IPs. This is normal behavior for iBGP, but if not fixed, communication will indeed fail.
The purpose of the lesson was to show how the BGP table can contain multiple paths to a particular destination using the maximum-paths command appropriately. Having the two paths show up in the BGP table was the only requirement for this particular lab.
However, if this were a production network, you would need to complete the configuration correctly using the next-hop-self command and any other necessary configurations to ensure correct communication.
The command, maximum-paths …, it will applied to all prefixes that have the same attributes that you mentioned?, there is a way to just apply ECMP to just certain prefixes?
The BGP command maximum-paths is used to control the maximum number of parallel paths that can be used for load sharing. As stated in the lesson, this command applies to all prefixes that have the same AS path, next-hop, origin code, MED, and IGP metric, and have a different next hop address. This is how BGP achieves ECMP routing.
However, if you want to apply ECMP to only certain prefixes, they way you could go about doing it is by modifying these attributes of specific prefixes so that you can make them eligible or ineleiglbe for ECMP. You can do this by applying route maps to the prefixes you choose. This is kind of a round about way of doing it, and it can quickly get complex. But it is doable.
Scenario:
Multi Hub & Spokes topology using DMVPN with BGP overlay
Two Hubs & spoke are configured for multi path
Confirmed Routes advertised to Spokes
confirmed BGP routes are received from both HUBs at spokes across tunnel
One router- two routes appear in the global table & BGP sets second route as “mi” in the iBGP table
Router Two-The other router sees both routes in BGP table but the second route doesn’t have status code set to “mi” and therefor only one route appears in the routing table
Data is across a tunnel from Two Hubs in HA configuration sending that advertise the same routes to the spokes.
Hopefully this all makes sense.
You are deploying various network features and capabilities in the same topology (HA DMVPN, BGP multipath, NHRP), and this can complicate the required configuration as well as the troubleshooting process. So I don’t have a clear cut solution for you, but I can share with you some principles you can use in your troubleshooting.
First of all, the mi status code in the BGP table indicates a multipath, which means BGP has chosen multiple best paths. In your case, the second router isn’t setting the second route to mibecause it’s not considering it as a best path. This is the aspect you must focus your troubleshooting on.
Why could this be? It could be due to several reasons including:
Differing BGP attributes. Multipath will only work if the weight, local preference, AS path, origin type, MED, and IGP metric are the same.
The configuration of maximum-paths. If maximum-paths is not configured or is set to a value less than the number of paths available, then only one path will be chosen as the best path.
Consider how NHRP is interacting with BGP multipath:
If NHRP shortcuts (spoke-to-spoke tunnels) are not correctly established, traffic might be forced to take a less optimal path via the hub(s), impacting the effectiveness of BGP multipath.
Next Hop Resolution - BGP relies on correct next-hop information for routing decisions. If NHRP is not correctly resolving these next hops, especially in a setup with multiple hubs, BGP might not make the optimal path selections.
NHRP and BGP Synchronization - In a dynamic environment like DMVPN, the synchronization between NHRP and BGP is vital. Delays or mismatches in updates between these two can lead to routing inconsistencies.
To resolve this issue, you can start by checking the BGP attributes of the routes on the second router. If they are the same, then check the router’s configuration for maximum-paths. If it’s not configured or is set to 1, then you should configure it to a value equal to or greater than the number of paths available.
If the problem still persists, the next thing you should check is how NHRP interacts with BGP and the multipath feature by examining NHRP mappings and BGP next hop addresses to see how NHRP is leading BGP to route traffic.
Hopefully, this information will help you get started in your troubleshooting. Let us know how you get along!
I am taking the BGP course now, and this lesson is cool, however, you explained how to load balance between if the same route is received from two iBGP or eBGP and that was clear. ,my question is can i load balance if i received the same route one from iBGP and another from eBGP ?
That’s an excellent question. The answer is, you cannot.
Both eBGP and iBGP are part of the same routing protocol. However, routers view routes learned from eBGP and iBGP peers very differently. They view them as if they were learned from two different routing protocols. So in the same way that you cannot load balance between routes learned via OSPF and EIGRP, you cannot load balance between routes learned via eBGP and iBGP.
A prerequisite of all load balancing is that two or more routes to the same destination are present in the routing table. However, you will never have a route to the same destination learned via both eBGP and iBGP in the routing table at the same time. It all comes down to administrative distance (AD).
If such a route is learned via both eBGP and iBGP, only the eBGP-learned route will appear in the routing table. This is because the AD of eBGP learned routes is 20 and the AD of iBGP learned routes is 200. eBGP will always win.
But you can change the AD. What happens if you manually change the AD of the iBGP-learned route to be the same as that of the eBGP-learned route? Well, if a BGP router receives routes to the same destination via both eBGP and iBGP with the same AD, then the priority of appearance in the routing table will be the same as the default AD values. So only the eBGP route will appear in the routing table. Take a look at this NetworkLessons note on the topic for more information.
We can see that the weight, local_pref, as path, origin code and med are the same. However, if we check the RIB, the IGP metric to reach those two next hops is not the same.
So why is the path over 8.8.8.8 being considered for multipathing? This clearly doesn’t follow the rules here.
There seems to be some discrepancy about the use of the IGP metric as part of the prerequisites for multipath load sharing in BGP. The official Cisco BGP Configuration Guide agrees with the lesson that the IGP distance for the multiple candidate routes must be the same. Although it doesn’t state it explicitly, this is assumed to be the IGP metric to the next hop of each candidate route, as you too have assumed.
Now looking at some other Cisco documentation, specifically Cisco’s official description of the BGP Best Path Algorithm, we can see that the IGP distance is not always used. It agrees on the first five attributes, but when it comes to the next step, it has some additional details that you can read for yourself. But one thing it does state is:
Some BGP Multipath features put additional requirements on multipath candidates.
These are the additional requirements for eBGP multipath:
The path must be learned from an external or confederation-external neighbor (eBGP).
The IGP metric to the BGP next hop must be equal to the best-path IGP metric.
Based on this wording, I am led to believe that the IGP prerequisite is not always implemented, and I would assume that this is the case in your lab. I was also unable to find any specifics in any RFCs referring to BGP multipath concerning which attributes must be the same for routes to be considered for BGP multipath. From my research, I have concluded that this feature is highly vendor-specific and implementation-specific.
But this is definitely a very interesting topic to delve into and to see how various platforms behave.
→ R4 is advertising the prefix 4.4.4.4/32 , whereas R1 has 2 path reach the destination.
With BGP default behavior it will add the best path in the forwarding table for prefix 4.4.4.4/32.
→ For Situation1 : loadbalancing we be used with “multipath” , we need another cmd “bgp bestpath as-path multipath-relax” to bypass the different AS_Number ( learning on R1) with same AS_Length.
→ However Situation 2: R1 configured with “mutipath” and “bgp bestpath as-path multipath-relax” which is not allowing ECMP here. Is it because of different As_Length ?
R1#sh run | s bgp
router bgp 1
bgp router-id 1.1.1.1
bgp log-neighbor-changes
bgp bestpath as-path multipath-relax
network 11.11.11.11 mask 255.255.255.255
neighbor 192.168.12.2 remote-as 2
neighbor 192.168.12.2 allowas-in
neighbor 192.168.13.3 remote-as 3
maximum-paths 3
R1#
* 44.44.44.44/32 192.168.12.2 0 2 5 4 i
*> 192.168.13.3 0 3 4 i
R1#
44.0.0.0/32 is subnetted, 1 subnets
B 44.44.44.44 [20/0] via 192.168.13.3, 00:00:25
R1#
