BGP: Really confused, can't find an answer..

[Joebananas]

Hello all, I am labbing up some BGP stuff and am confused as to what is going on here. R1 and R2 are in AS 15, R3, R4 and R5 arein AS 10 and R6 is in AS 5.

R1 and R2 have loop back interfaces in 100.100.100.0 and am advertising those using network statements.

All directly connected networks on each router are being advertised with network statements as well.

R5 is receiving a path to the 100.100.100.0 network from R6 and from R3, but not R4, why is that?

Additionally, I was labbing the best path selection based on network type by setting a route map inbound on R3 from R1 and R2 that prepended an AS entry so I could see that R4 and R5 selected the eBGP path towards R6 vs iBGP path towards R3 and I saw that take place, but when I did this, R3 and R4 both started receiving the path to 100.100.100.0 from each neighbor, as did R5.

I don't get what is going on here. Can someone explain this to me?

[Giuseppe Larosa · Accepted solution]

Hello @Joebananas ,

your network diagram is not totally clear I assume you are representing the routers R1 to R6 and the BGP sessions both eBGP and iBGP.

>> R1 and R2 are in AS 15, R3, R4 and R5 arein AS 10 and R6 is in AS 5.

>> R5 is receiving a path to the 100.100.100.0 network from R6 and from R3, but not R4, why is that?

According to your network diagram R4 has no direct eBGP sessions with R1 or R2, R4 has an eBGP session with R6 and iBGP sessions with R3 and R5. The shortest AS path should make the iBGP advertisement received from R3 the best choice both on R4 and R5.

as a result of this R4 having installed an iBGP advertisement is not allowed to propagate this to R5 that is another iBGP peer.

This is called the iBGP split horizon rule an iBGP speaker cannot advertise to another iBGP speaker what has learned by a another speaker .

The rule exists because in iBGP the AS path attribute is not updated within the AS and would require a full mesh of iBGP sessions.

There are two ways to overcome the iBGP split horizon rule / full mesh constraint : BGP Route Reflector servers or BGP confederations.

In the first option the BGP RRS can reflect an iBGP advertisement coming from a client to another client or non client by appending two additional BGP attributes:

Cluster-list: contains the BGP Router-id or cluster-id of the BGP RRS itself

Originator-id: contains the BGP router-id of the client that injected the prefix in the domain.

These additional attributes allow for safe reflection.

So what you see is normal and caused by iBGP split horizon rule.

Hope to help

Giuseppe

[Joebananas]

Oh my goodness thank you so much!! This makes absolute sense now.

I went back and went through the BGP table and saw where everything was coming from, and it is indeed the case.

Seriously appreciate you!!!!