[Beginner] iBGP behaviour

[Americo Massotti]

Hello guys.

I've a question about iBGP behaviour.

I built a simple topology like this

There is a ebgp peering and a full mesh ibgp with eigrp ( network 0.0.0.0 for simplicity ) as underlay routing protocol.

on R2, my edge router, I config a network statement under bgp process to advertise the loopbacks of router inside AS2 to R1 in AS1.

This is the config of R2:

router bgp 2
bgp log-neighbor-changes
network 2.2.2.2 mask 255.255.255.255
network 3.3.3.3 mask 255.255.255.255
network 4.4.4.4 mask 255.255.255.255
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback0
neighbor 192.168.12.1 remote-as 1

and this is its (R2) bgp routing table

Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 192.168.23.3 409600 32768 i
*> 4.4.4.4/32 192.168.23.3 435200 32768 i

Since I have a full mesh ibgp topology, I expected to receive on R3 and R4 an update from R2 about the lookpack.

On R4 all clear

Network Next Hop Metric LocPrf Weight Path
r>i 2.2.2.2/32 2.2.2.2 0 100 0 i
r>i 3.3.3.3/32 192.168.23.3 409600 100 0 i
r>i 4.4.4.4/32 192.168.23.3 435200 100 0 i

 but on R3 this is the result

Network Next Hop Metric LocPrf Weight Path
r>i 2.2.2.2/32 2.2.2.2 0 100 0 i

I receive only R2 loopback, no the R3 lookback or R4.

Why? R3 it did not have to be like as R4 bgp routing table?

This is the config of R3

router bgp 2
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback0

and this is R4 config

router bgp 2
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback0

Thanks a lot for your support and collaboration.

Have a nice day.

Americo

[Georg Pauwen]

Hello,

post the full configs of all 4 routers. From the drawing it is not clear how you have configured the full mesh, it looks more like a serial setup R2-R3-R4...

[Americo Massotti]

Hi Georg thanks a lot for your support.

In attachment you can find the full show run of routers.

Thanks once again

[Georg Pauwen]

Hello,

thanks, I'll have a look...

[Americo Massotti]

Thanks!

[Georg Pauwen]

Hello,

you don't have a full iBGP mesh. Either way, you need to announce the loopbacks on the routers where they are physically configured. So the R2, R3, and R4 configs need to look like this:

R2

!

router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
network 2.2.2.2 mask 255.255.255.255
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 192.168.12.1 remote-as 1

R3

!

router bgp 2
bgp router-id 3.3.3.3
bgp log-neighbor-changes
network 3.3.3.3 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback0

R4

!

router bgp 2
bgp router-id 4.4.4.4
bgp log-neighbor-changes
network 4.4.4.4 mask 255.255.255.255
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback0

[Americo Massotti]

Hi Georg.

Thanks for your explanation.

Why you say that there isn't full mesh?

R2 has a peering statment with R3 and R4.

R3 has a peering with R2 and R4

R4 with R3 and R2.

It isn't a ibgp full mesh topology?

I replicate a network statement injection on R2 edge router about loopback to replicate a lab of INE CCIE v5, where Brian McGahan do this.

However I try to understand why R3 dont receive the prefix update? Whats is the reason.

Thanks

[Harold Ritter · Accepted solution]

Hi Americo,

R2 has 192.168.23.3 as the next hop for 3.3.3.3 and 4.4.4.4 and that is what it announces to R3. R3 rejects it as 192.168.23.3 is a local address.

Regards,

[Americo Massotti]

Thanks Harold.
I expected that R3 however received the prefix from R2 with a rib failure in bgp table.
Instead R3 discard it all without process it.

[Harold Ritter · Accepted solution]

The RIB failure is because the router has the same route from another protocol with a better preference. In this case, the update is rejected based on the fact that the next hop is the local router itself. It would not make any sense for the local router to keep such an update.

Regards,

[Americo Massotti]

Hi Harold.

Thanks once again for your explanation.