Why isn't iBGP peer announcing external route it learned to its only peer?

Question

I'm using VyOS to create a BGP lab. It has 6 routers, each in an iBGP pair, and 3 autonomous systems.

• Routers 1 & 2 - AS1111
• Routers 3 & 4 - AS2222
• Routers 5 & 6 - AS3333

All routers are connected in a loop. The connection between each pair is configured as iBGP, the rest are eBGP as follows..

R1 ibgp> R2 ebgp> R3 ibgp> R4 ebgp> R5 ibgp> R6 ebgp> R1..

I am trying to simulate a transit situation where an AS can reach a subnet from 2 different eBGP peers, each in its own AS.

R1 & R2 each have a /24 and a summary /20 that they advertise. R1 (AS1111) announces to R3 (AS2222) just fine, and R3 to R4 is good too.

Now starting from R2 going the other way around the circle..

R1 (AS1111) announces to R6 (AS333), R6 to R5 (AS3333), and finally R5 to R4 all good.

R4 is learning the routes from both R3 & R5 as expected and installing the best path. But R3 only learns from R2. It doesn't look like R4 is even sending these routes to R3. It seems since these routes were learned via eBGP and R4 & R3 are directly peered that R4 should send these to R3, but I don't see them. See below..

vyos@vyos-03:~$ sho ip bgp
BGP table version is 52, local router ID is 14.16.16.0, vrf id 0
Default local pref 100, local AS 2222
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 14.16.0.0/20     14.16.0.2                              0 1111 i
*> 14.16.2.0/24     14.16.0.2                              0 1111 i
*> 14.16.3.0/24     14.16.0.2                0             0 1111 i

Displayed  3 routes and 3 total paths

vyos@vyos-04:~$ sho ip bgp
BGP table version is 44, local router ID is 14.16.16.2, vrf id 0
Default local pref 100, local AS 2222
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  14.16.0.0/20     14.16.16.3                             0 3333 1111 i
*>i                 14.16.16.0                    100      0 1111 i
*>i14.16.2.0/24     14.16.16.0                    100      0 1111 i
*                   14.16.16.3                             0 3333 1111 i
*>i14.16.3.0/24     14.16.16.0               0    100      0 1111 i
*                   14.16.16.3                             0 3333 1111 i

Displayed  3 routes and 6 total paths

Now, if I shutdown the session between R2 and R3, then R3 does learn the routes from R4 which is the long way around the circle.

vyos@vyos-03:~$ sho ip bgp
BGP table version is 64, local router ID is 14.16.16.0, vrf id 0
Default local pref 100, local AS 2222
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i14.16.0.0/20     14.16.16.1                    100      0 3333 1111 i
*>i14.16.2.0/24     14.16.16.1                    100      0 3333 1111 i
*>i14.16.3.0/24     14.16.16.1                    100      0 3333 1111 i

Displayed  3 routes and 3 total paths

Does anyone know what I am missing here? I can't make sense of it. I think since there are only 2 iBGP peers in AS2222 that R4 should announce those routes to R3, but since they are clearly a longer path that R3 shouldn't choose to install them into the routing table. I do have 'next hop self' configured, add to that when R2 is shutdown and the loop is broken the routes are propagated from R4 to R3 so I know the iBGP peering is correct.

The only thing I can think of is split-horizon. But when I search split-horizon on BGP I only get results regarding the iBGP loop prevention mechanism and this is clearly different than split-horizon in something like EIGRP. So anyway, I'm stuck :/

Thanks to anyone who knows what's going on here and can explain it. And hopefully it's not something small I am overlooking.

NOTE: My config is basically minimal. I just created the basic peerings with a 'remote-as' neighbor statement. I added the 'next hop self' statement to all iBGP neighbor statements and that's it. All router's config is identical with exception to subnets, AS, hostname, etc.. I'm not using route maps or anything fancy.

Answer 1

R3 learns the route from R4 which is an ibgp route, and from R2, which is an ebgp route.

Ebgp is preferred over ibgp, so that's the route that gets installed.

Answer 2

The IP addressing is difficult to follow. Be kind to yourself while labbing. lol

R3 = 14.16.16.0

R4 = 14.16.16.2

R5 = 14.16.16.1 ???

One thing that is confusing is the local preference. Maybe this is a VyOS thing.

At first, R4 is showing local-preference 100 towards R3 ....while R3 isn't showing that local preference for the same prefixes (it would in ciscoland).

Then with R2-R3 neighbors down, suddenly R4 is seeing a 100 local-preference in the other direction.