This topic is to discuss the following lesson:
1 Like
Hi
here you have created the route-map SET_WEIGHT_INBOUND, but seems like you missed to set the weight to 32768 under it, in the write up. Please check. looks like a small typo.
Great content, thank you.
1 Like
Hello Rajni
Yes, you are correct, thanks for pointing that out. I will let Rene know to make the correction.
Glad to hear tat you’re enjoying the content!
Laz
Thank you @rajni.genius1104 . I just fixed this.
Rene
Hi,
I have an observation regarding the following statement:
You can recognize these because the next hop is always 0.0.0.0.
I created the following lab:
1.1.1.0/24—(R1)—OSPF—(R2)—iBGP----(R3)----1.1.1.0/24
Redistribution was used for 1.1.1.0/24 on R2 and the network command on R3. On R2, weight was modified to be the same, LocalPref of 100 remained the same. BGP selected the locally redistributed route over the one learned via the network command on R3, as expected.
However, the next hop was not 0.0.0.0 and is set the the IGP’s (OSPF) next hop. It seems next hop is only 0.0.0.0 if it is a directly connected route.
R2:
Hello Samir
First of all, you mention that:
I think you mean that redistribution was used on R1, correct?
Now assuming that is indeed correct, the next thing I’d like to point out is that the locally originated routes attribute refers to routes that have been originated on the local router. So the only router you will see 0.0.0.0 as a next hop is the router in which the network command or redistribution has been applied. If you look at the BGP table of either R1 or R3, you will see 0.0.0.0 as the next hop for the 1.1.1.0/24 network.
From the point of view of R2, neither route is locally originated.
Now having said that, looking at your BGP table, I’m trying to figure out why the second entry has been chosen as the best route. I can infer the following:
- The route from R3 was learned from an iBGP peering while the route from R1 was an eBGP peering (see the “i” at the beginning of the first entry)
- The origin code of “i” appears for the first route, which means that the
networkcommand was indeed used to advertise this into BGP, while the incomplete origin code of “?” is used for the second entry, which means it was redistributed. - Since one path is learned via eBGP and the other via iBGP, MED is not considered.
So going through the attributes:
- Weight is the same
- Local preference is ignored
- Neither route is locally originated
- AS path length is the same
- Origin code is different, and “i” should be chosen over “?” but it is not.
- MED is not considered
- eBGP is chosen over iBGP, and this seems to be what is happening.
It seems like the eBGP route is being chosen over the iBGP route. But that’s not in the correct order of BGP path selection. So there must be some information we’re missing. Can you share with us the configuration of the BGP section of your routers so we can take a closer look?
I hope this has been helpful!
Laz
Hi Laz,
Redistribution is occurring on R2 (see below). There is only OSPF on R1, OSPF and BGP on R2, and only BGP on R3. R2 and R3 are in BPG AS 2.
R2:
router bgp 2
bgp log-neighbor-changes
redistribute ospf 1
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 3.3.3.3 route-map WEIGHT in
The reason I chose to redistribute on R2 and use the network command on R3 was to be certain that it was using the locally originated tie-breaker and not one further down the priority list, such as origin, which it isn’t because igp > egp > ?.
Apologies, I should have been clearer.
Btw, I just tried using the network command on R2 instead of redistributing, and the next hop is still retained (and the origin code is now i instead of ?).
R2(config-router)#do sh run | s bgp
router bgp 2
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 3.3.3.3 route-map WEIGHT in
Thanks.
Sam