BGP Routes missing in IBGP neighbors

[theBGPguy]

I have a simple scenario as in the diagram:

I am advertising a route 40.40.40.0/24 from R4 to AS 100.

When I verify BGP table in the R1,R2,R3:

R1#show ip bgp
BGP table version is 8, local router ID is 1.1.1.1



Network Next Hop Metric LocPrf Weight Path
* i40.40.40.0/24 3.3.3.3 0 100 0 200 i
*>i 2.2.2.2 0 100 0 200 i




R2#show ip bgp
BGP table version is 7, local router ID is 2.2.2.2



Network Next Hop Metric LocPrf Weight Path
* i40.40.40.0/24 10.34.0.4 0 100 0 200 i
*> 10.24.0.4 0 0 200 i




R3#show ip bgp
BGP table version is 4, local router ID is 3.3.3.3



Network Next Hop Metric LocPrf Weight Path
*> 40.40.40.0/24 10.34.0.4 0 0 200 i
* i 10.24.0.4 0 100 0 200 i

=============================================================================================

Problem is when I am applying MED value on the advertised route towards R2 the bgp table of R1 and R3 only shows one entry.

R4#show run | s bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 40.40.40.0 mask 255.255.255.0
neighbor 10.24.0.2 remote-as 100
neighbor 10.24.0.2 route-map MED_OUT out
neighbor 10.34.0.3 remote-as 100
no auto-summary


route-map MED_OUT permit 10
match ip address prefix-list ADV_ROUTE
set metric 444

R4#show ip prefix-list
ip prefix-list ADV_ROUTE: 1 entries
seq 10 permit 40.40.40.0/24







R1#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i40.40.40.0/24 3.3.3.3 0 100 0 200 i







R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i40.40.40.0/24 10.34.0.4 0 100 0 200 i
* 10.24.0.4 444 0 200 i




R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 40.40.40.0/24 10.34.0.4 0 0 200 i

Why on R1 and R3 the route with metric 444 is not shown, I saw an example in the GNS3 Lab which is showing the routes??

Is this is issue with GNS or IOS?

I used c3640 and c7200.

This also happens when I configure

LOCAL_PREF

[Jon Marshall]

Firstly on R1 and R2 you should use the

next-hop-self

command for the IBGP peering between each other as at the moment it looks like you aren't. 

Before you applied the MED R1 receives the BGP route from R4 and advertises it to R2 and R3 and the same thing happens on R2 ie. it receives the route from R4 and advertises to R1 and R3 so they all have two entries for the same route. 

When you apply the MED to R2 it receives the route with a metric of 0 from R1 and the route with a metric of 444 from R4 and it chooses the lower metric and this is the one it uses so it cannot then advertise the route with a metric of 444 to either R1 or R3 which is why you don't see it. 

Jon

[theBGPguy]

I am using 

next-hop-self

in AS100. R2 and R3 are the EBGP Routers. I am applying MED to 40.40.40.0/24 on R4 towards R2.

So R2 and R3 should both see two entries in BGP table for 40.40.40.0 one with metric 0 and other with 444.

R1 should also see the same in the BGP table and chose the route with lower metric.

R1#show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
bgp deterministic-med
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback0
no auto-summary

--------------------------------------

R2#show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
bgp deterministic-med
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback0

neighbor 3.3.3.3 next-hop-self
neighbor 10.24.0.4 remote-as 200
no auto-summary

-------------------------------------------

R3#show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
bgp deterministic-med
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback0

neighbor 2.2.2.2 next-hop-self
neighbor 10.34.0.4 remote-as 200
no auto-summary




--------------------------------------------

R4#show run | s bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 40.40.40.0 mask 255.255.255.0
redistribute connected
neighbor 10.24.0.2 remote-as 100
neighbor 10.24.0.2 route-map MED_OUT out
neighbor 10.34.0.3 remote-as 100
no auto-summary

[Jon Marshall]

BGP router advertises routes it uses. 

Before MED, R2 uses route to R4 and advertises it to R1 and R3,  R1 uses route to R4 and advertises to R2 and R3. 

After MED, R2 does not use route advertised by R4 because it's metric is worse and because it does not use that route it does not advertise to R1 or R3 which is why you don't see it on those routers.

Jon

[MHM Cisco World]

see my below comment 

[MHM Cisco World]

see my below comment 

[Giuseppe Larosa]

Hello @theBGPguy ,

what @Jon Marshall  is trying to explain to you is that until you don't configure the MED = Multi Exit Discriiminator  on R4 eBGP session to R2, R2 will prefer the eBGP router over the iBGP route.

>> R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i40.40.40.0/24 10.34.0.4 0 100 0 200 i
* 10.24.0.4 444 0 200 i

You need to be aware that by default a missing MED is considered 0 by Cisco routers unless you use a specific command

that will revert a missing MED attribute to 4 billions

bgp bestpath med missing-as-worst

In addition you should know that a metric the lowest value is preferred like in an IGP ( OSPF, EIGRP, RIP , IS-IS)

So setting a MED a 444 on eBGP session R4 to R2 makes that eBGP session a backup path for the prefix, R2 elects as best path the iBGP received route from R3 you can see this by the ">" symbol  and as a result of this the backup path is not propagated to internal iBGP peers.

For local preference is the opposite iif you rise the local preference from default value 100 to a greater value you create a primary path to prefix. But the effects in your topology are the same.

In short before making a lot of GNS3 simulations you should study BGP theory more deeply and you need to learn to read the show commands too.

There is not shortcut to learning.

Hope to help

Giuseppe

[MHM Cisco World]

...

[Harold Ritter]

Hi @MHM Cisco World ,

> 1- the connect between peer must never learn through the BGP
> R2#show ip bgp
> BGP table version is 7, local router ID is 2.2.2.2
> Network Next Hop Metric LocPrf Weight Path
> * i40.40.40.0/24 10.34.0.4 0 100 0 200 i
> *> 10.24.0.4 0 0 200 i <<<<<<- this make suboptimal and some times flapping issue remove redistribute connect or use > filter to deny advertise the direct connect between BGP Peer.

The line you are referring to is not another prefix, but rather a second path for prefix 40.40.40.0/24 via next hop 10.24.0.4.

Regards,

[MHM Cisco World]

thanks a lot 

[theBGPguy]

Thanks for all of your insights. However after fiddling with the configs. I found that on R2 and R3 I was using

network 0.0.0.0 255.255.255.255

for ospf area 0.

When I removed OSPF on the interfaces R2-R4 and R3-R4.

R1 started showing both the routes.

R2#show run | s ospf
router ospf 1
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 10.12.0.0 0.0.0.255 area 0
network 10.23.0.0 0.0.0.255 area 0




R3#show run | s ospf
router ospf 1
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 0
network 10.13.0.0 0.0.0.255 area 0
network 10.23.0.0 0.0.0.255 area 0







R1#show ip bgp
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i40.40.40.0/24 3.3.3.3 0 100 0 200 i
*>i 2.2.2.2 444 100 0 200 i

Somehow the networks 10.24.0.0/24 and 10.34.0.0/24 being advertised in OSPF was influencing the R2 (after MED) not to advertise the route with higher metric to R1.

[Jon Marshall]

Okay, we probably need to see the full configs because I originally said you had not used the

next-hop-self 

command between R2 and R3 and you said you had but your output suggested otherwise eg. - 

R2#show ip bgp
BGP table version is 7, local router ID is 2.2.2.2



Network Next Hop Metric LocPrf Weight Path
* i40.40.40.0/24 10.34.0.4 0 100 0 200 i
*> 10.24.0.4 0 0 200 i

the first entry has a

next hop IP

of 10.34.0.4 which is R4 but with

next-hop-self

it should be 3.3.3.3 which is R3. 

So something is not working or we are not seeing the full picture. 

It is also interesting as to why R3 is choosing the BGP route with the worst metric after you changed the OSPF configuration. 

Full configurations plus "sh ip bgp" and "sh ip route" from each router would be useful. 

Jon

[theBGPguy]

Hi Jon,

I did not use "next-hop-self" between R2 and R3. Also the above output:

R1#show ip bgp
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i40.40.40.0/24 3.3.3.3 0 100 0 200 i
*>i 2.2.2.2 444 100 0 200 i <<<  incorrect as the above route should be the route. may be I copied when BGP was still calculating the path.

Correct ONE:

R1#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i40.40.40.0/24 3.3.3.3 0 100 0 200 i
* i 2.2.2.2 444 100 0 200 i

When I configured

next-hop-self 

between R2 and R3, again R1 started showing only one entry in the BGP table.

R1#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i40.40.40.0/24 3.3.3.3 0 100 0 200 i




R2#show ip bgp
*>i40.40.40.0/24 3.3.3.3 0 100 0 200 i
* 10.24.0.4 444 0 200 i




R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 40.40.40.0/24 10.34.0.4 0 0 200 i

I am attaching all the configs.

[Jon Marshall · Accepted solution]

Okay, this is getting confusing because you said you did use

next-hop-self

when I initially pointed it out and the configurations you posted earlier showed it configured on all neighbors. 

That aside, R1 now makes sense because it should indeed be selecting the route with the lower metric. 

With your original setup both R2 and R3 could use the IBGP route advertised between them for R4's subnet because the

next hop IP

was reachable because you were running OSPF on the R2 -> R4 and R3 -> R4 interfaces so they knew how to get to R4. 

When you removed OSPF off those interfaces and without

next-hop-self 

being configured the

next hop IP 

was no longer reachable so BGP cannot use that route and this is the reason you saw both routes on R1 ie. R2 could not use the IBGP route from R3 any more because it could not reach the

next hop

so it could use the route with the higher metric and so it advertised that to R1. 

Once you configured

next-hop-self 

on R2 and R3 you are back to what I described originally ie. R2 can now use the IBGP route from R3 because the

next hop 

is R3 so it chooses that one and so it does not advertise the route with the higher metric to R1. 

Jon

[theBGPguy]

Thanks Jon, I now understand how it is working. Great insights thanks..