sir, i was thinking that the step-10 that the oldest ebgp route will be used as a tie breaker in bgp best path selection process one path HAS TO BE received first and processed first and the other path has to received milleseconds later . which means the steps
lowest RID
lowest neighbor ip address
are useless . and also the command
maximum-paths x
is also useless command because we SHOULD HAVE only one ebgp path is better than the other path .
10-oldest ebgp peer
This is not actually what step 10 is, though kind of. Here is the selection process for 10 from the Cisco documentation.
“When both paths are external, prefer the path that was received first (the oldest one).”
This one needs a bit of detail to explain. So, the purpose of the oldest route is to maintain route stability in BGP (one of the most important things in all of BGP is stability). What this says is, if I get a route from router 2, and I did not have this route before, it will be installed in my routing table.
Now, I get routers 3 and 4 advertising the same route, after I’ve already chosen a route. Well, I had router 2 selected first, so I won’t change over to the others unless I am told there is a higher priority (higher up in the selection process, like maybe weight or local preference). This is because I’ve had this route through router 2 the longest, and therefore it is the most stable path I know of.
Now comes the confusing part, BGP does NOT track how long it has known a route. This means, it doesn’t know if it learned the route from router 3 or router 4 first. So let’s say router 2 goes down, I lose the route from that neighbor. Now I no longer have an “oldest route” at all, because BGP doesn’t track the age of routes learned. This means that among the routes I have from router 3 and router 4, I will use the lowest RID.
So “oldest route” means all else being equal, I chose this as my route for a reason, and unless you can tell me this other route is better, I’m not changing. If I forget this route, we then skip this test. we will then move on to router ID.
Amusingly enough though, once I select let’s say router 3 based on router ID. That route will now become my “oldest route” for the purposes of BGP routes in future. So if router 2 comes back online, I will go through, see that all other metrics are equal, and I will get to the oldest route step, and decide to keep the route from router 3.
It’s kind of poorly worded and can be a bit confusing, but basically step 10 in the BGP selection process is saying if I have already picked a route, that one wins. Just because another router comes in with a lower router ID doesn’t mean I’m going to shift my traffic over to it, because I’ve already got a perfectly good route in use and I don’t want to risk that the newest route is less stable.
This naturally lowers priority for less stable routes. Let’s say Router 2 has a habit of going down once a week. Well, because router 3 is stable and is my new “oldest route”, I don’t swap over to router 2 every single time it goes down and comes back up, which provides a better connection for the end users. The Internet is all about stability.
TLDR: Step 10 in the process is saying if my route isn’t broken, I don’t see a need to fix it. If it does get broken, move on to step 11.
@Network_Eric
sir, i`m not agree with this at all :-
sir, please look here
R5 is already keep tracking for the routes is received from the other peer . look at the “path is younger”
If you look at the above output you’ll see that the metric to the next hop is equal among all 3 paths and MED for the path from 4.4.4.4 is the highest but it is labeled “best” and the best path reason is “Overall best path”. Why? Look at the best path reasons for the other two options. They are “Path is younger”. So in this case, 4.4.4.4’s path is the oldest (ie, most stable) path.
Hey Major,
That is correct, and exactly how I said it would behave. It doesn’t state this path is older, but it does tell you why the other options weren’t picked. This is because they are considered younger. BGP does not track how long it has had a route for. There is no metric or value stored within BGP for that information. There is no show command you can issue that can tell you how long you’ve had a route. You might be able to see when a route was last updated, or how long a neighbor has been there, but not individual route tracking for how long it is known.
They are showing as “younger” because they were added to BGP AFTER the best path from router 4 was already learned, as I described. You can test this yourself by following what I said. There is no tracking between which was learned first, the route from 1.1.1.1 and 2.2.2.2. So, to test this, shut ports to both of those routers. No shut the port to 2.2.2.2, wait a couple of minutes and then no shut the port to 1.1.1.1. Now, both will still show as younger in your output, just as before.
For the final test, shut the port to router 4. If you are correct and BGP tracks age of routes, then router 2 will become the new best route, as it is older. If I am correct, then router 1 will be the new best route, because BGP has no tracking for which is the oldest route, so both are considered to be equal. It will then select based on lowest router ID.
@Network_Eric
WHAT ?!!!
what is going on? you`re right ? the lowest RID is selected .
but why the oldest eBGP update criteria is not evaluated here ?
here on step-10 they said “When both paths are external, prefer the path that was received first (the oldest one).”
and on step-11 they said “Prefer the route that comes from the BGP router with the lowest router ID.”
of course the step-10 is done first before the step-11 . but why the step-10 is skipped and evaluated based on the lowest RID NOT based on the oldest eBGP route ?
Hey Major,
Yep, it basically comes down to “Oldest Path” = I have this currently selected as my best path when you get to step 10. Since BGP has nothing that actually tracks how long it has known a given route from a neighbor, once the currently selected route goes away, step 10 is considered to be equal and it will move on to step 11. I know it’s counter intuitive and not worded well in the documentation, that’s why I presented that test for you to see exactly how it behaves because it can really throw you off it you don’t know it does that.
now on R9,R10,R11,R12
eBGP peering between R9 and R10
eBGP peering between R9 and R11
eBGP peering between R9 and R12
R10,R11 and R12 are advertising the exact same subnet 75.0.0.0/24
what i`m going to do is to shutdown all the eBGP peerings between R9,R10,R11,R12
R9(config-router)#neighbor 10.10.10.10 shutdown
*Mar 9 22:57:13.867: %BGP-5-ADJCHANGE: neighbor 10.10.10.10 Down Admin. shutdown
*Mar 9 22:57:13.871: %BGP_SESSION-5-ADJCHANGE: neighbor 10.10.10.10 IPv4 Unicast topology base removed from session Admin. shutdown
R9(config-router)#neighbor 11.11.11.11 shutdown
*Mar 9 22:57:21.019: %BGP-5-ADJCHANGE: neighbor 11.11.11.11 Down Admin. shutdown
*Mar 9 22:57:21.019: %BGP_SESSION-5-ADJCHANGE: neighbor 11.11.11.11 IPv4 Unicast topology base removed from session Admin. shutdown
R9(config-router)#neighbor 12.12.12.12 shutdown
and then i`m going to bring up the ebgp peering between
first R9-R12
R9(config-router)#no neighbor 12.12.12.12 shutdown
R9(config-router)#
*Mar 9 22:59:34.835: %BGP-5-ADJCHANGE: neighbor 12.12.12.12 Up
R9(config-router)#
then i`m going to bring up the ebgp peering between
R9-R11
R9(config-router)#no neighbor 11.11.11.11 shutdown
R9(config-router)#
*Mar 9 23:00:03.615: %BGP-5-ADJCHANGE: neighbor 11.11.11.11 Up
then i`m going to bring up the ebgp peering between
R9-R10
R9(config-router)#no neighbor 10.10.10.10 shutdown
R9(config-router)#
*Mar 9 23:01:19.315: %BGP-5-ADJCHANGE: neighbor 10.10.10.10 Up
R9(config-router)#
what i did now is the first (oldest)ebgp route for 75.0.0.0/24 is via R12 . if i shutdown the ebgp peering between R9-R12 that is causing R9 to select the best ebgp route for 75.0.0.0/24 by using the (oldest) ebgp route by using the route via R11 because it comes up second.
but look here
R9(config-router)# neighbor 12.12.12.12 shutdown
*Mar 9 23:04:31.019: %BGP-5-ADJCHANGE: neighbor 12.12.12.12 Down Admin. shutdown
*Mar 9 23:04:31.023: %BGP_SESSION-5-ADJCHANGE: neighbor 12.12.12.12 IPv4 Unicast topology base removed from session Admin. shutdown
R9#show ip bgp
*Mar 9 23:04:50.211: %SYS-5-CONFIG_I: Configured from console by console
R9#show ip bgp 75.0.0.0
BGP routing table entry for 75.0.0.0/24, version 7
Paths: (2 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
10
10.10.10.10 (metric 2) from 10.10.10.10 (10.10.10.10)
Origin IGP, metric 0, localpref 100, valid, external, best
Refresh Epoch 1
11
11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, valid, external
the route via the lowest RID is evaluated NOT the (OLDEST)eBGP route.
===============================================
let`s bring back the eBGP connection between R9-R12
R9(config)#router bgp 9
R9(config-router)#no neighbor 12.12.12.12 shutdown
R9(config-router)#
*Mar 10 22:03:34.443: %BGP-5-ADJCHANGE: neighbor 12.12.12.12 Up
R9#show ip bgp 75.0.0.0
BGP routing table entry for 75.0.0.0/24, version 2
Paths: (3 available, best #3, table default)
Advertised to update-groups:
1
Refresh Epoch 1
12
12.12.12.12 (metric 2) from 12.12.12.12 (12.12.12.12)
Origin IGP, metric 0, localpref 100, valid, external
Refresh Epoch 1
11
11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, valid, external
Refresh Epoch 1
10
10.10.10.10 (metric 2) from 10.10.10.10 (10.10.10.10)
Origin IGP, metric 0, localpref 100, valid, external, best
let`s change the bgp weight on R9-R11
R9(config)#ip prefix-list test permit 75.0.0.0/24
R9(config-route-map)#match ip address prefix-list test
R9(config-route-map)#set weight 999
R9(config-route-map)#route-map ine permit 20
R9(config-route-map)#router bgp 9
R9(config-router)#neighbor 11.11.11.11 route-map ine in
R9(config-router)#end
R9#clear ip bgp * soft in
R9#show ip bgp 75.0.0.0
BGP routing table entry for 75.0.0.0/24, version 4
Paths: (3 available, best #2, table default)
Advertised to update-groups:
1
Refresh Epoch 2
12
12.12.12.12 (metric 2) from 12.12.12.12 (12.12.12.12)
Origin IGP, metric 0, localpref 100, valid, external
Refresh Epoch 2
11
11.11.11.11 (metric 2) from 11.11.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, weight 999, valid, external, best
Refresh Epoch 2
10
10.10.10.10 (metric 2) from 10.10.10.10 (10.10.10.10)
Origin IGP, metric 0, localpref 100, valid, external
the route via R11 is the best route NOT the route via R10 using the lowest RID.
what i understand about selecting the bgp best path is
using the " clear ip bgp" is cause the local bgp speaking device to start the ENTIRE BGP best path selection process all over again. and that is why R9 selecting the eBGP route via R11 because he start the bgp best path selection process and conclude the weight via R11 is higher than any other ebgp paths and select it.
if im wrong , what R9 is going to do after "clear ip bgp"? of course R9 is now at step-10 and is going to continue from step-11 which is the lowest RID and the lowest RID is R10 . but since R9 didnt select the path via R10 and select the path via R11 which means R9 starting the ENTIRE BGP best path selection proces all over again like what i said.
but if we don`t use" clear ip bgp" command that is going to cause R9 to continue the best path selection process from step-11
Hey Major,
Close. So, it isn’t that BGP doesn’t do the entire best path selection process again. It does. It’s just when the route-map gets applied. So, when a neighbor sends you the updates, this goes in a special incoming table. This table is completely unfiltered, exactly how it left the neighbor. Your BGP router then takes the information from this table, and applies the route-map to it. When it does so, it might filter out some routes, tag some others, or in your case, modify the weight of a route. Once it applies these changes, it stores it in the local BGP table. Now, depending on how your soft reconfiguration settings are setup, will determine if BGP clears the first table or not.
When you send routes outbound, you take from the local BGP table, apply modifiers from your route-maps, and then store it in an outgoing table. This modified table is what gets sent to the neighbor, who will then place it in their incoming table, and the process repeats down the line.
So, we only apply rules when we check the incoming table, we never modify what is in the local BGP table with routes from an external source. So, your change with the route-map will either wait until the neighbor sends the entire NLRI information again, or you can force it to check, with the clear IP BGP command. How the clear IP BGP command behaves, depends entirely on which for of updates you have.
Now, it’s worth noting, that the route-map you put in place, will eventually take effect without clear ip bgp. It just waits until the neighbor resends information to you, which could be cause by an adjacency going down, it losing a route in its own tables, etc, etc. Could be 5 minutes, could be 5 years.
TLDR:
The best path selection gets made on your LOCAL BGP table, which is after the route-map has been applied. So, when you bring down the router after having applied the route map, it still goes through and checks NWLLA OMNI OLL, it is just that none of the local BGP table changed after you applied the route-map, because it doesn’t impact the local bgp table, only when adding to the local table from the incoming table.
You can verify by changing things locally on the device, which does update the table directly, and changes the table without having to clear IP BGP. For instance, you can advertise a new route from R9, perhaps even the same 75.0.0.0, this will cause the local table to update and the new selection will be made properly, without receiving an update from the neighbors.
