BGP Confederation Explained

Dear Ahammad,

I guess you could make that work, R5 would probably see R2 as a regular iBGP neighbor that advertises an external route (from R1). The question is, why would you want this? :slight_smile: As soon as they do learn something with a sub-as path then they’ll refuse the route. Better to just add the confederation identifier (and peers) to all devices in the confederation.

Rene

Hi Rene

Thank you for this article.

I had a question though

When R1 advertises route to R2 that’s external and learned via ebgp. For ibgp protocol states that next hop advertised by ebgp should be carried into ibgp. So when R1 advertises 11.11.11.11 to R2 it uses next hop address as 192.168.12.1. So when R2 advertises this route to its ibgp peers it should have next hop as 192.168.12.1 and not as 2.2.2.2 .
Is this case we can also use next-hop-self command ? or using igp like ospf is the only option?

thank you
Kandhla

Hi Kandhla,
Yes, you can absolutely use the next-help-self option with iBGP. In fact, in some circumstances you might HAVE to. For example, let’s say you have a router (R1) with an external BGP relationship with an ISP, and your highly available site has been given two separate circuits from that ISP. To ensure that R1’s BGP neighborship with the ISP is also highly available, you have configured R1 to use the ISP’s router’s loopback address (you would also have to use the ebgp-multihop option for this). To do this you would create static routes on R1 to get to the ISP’s loopback through both of your circuits.

Now, suppose that R1 also has an iBGP relationship with other routers you have inside your company (say, R2 and R3). What would happen to all the routes that R1 would learn from the ISP, when it shares them with R2 and R3? The answer is that the routes would not appear in the routing table, and the reason is the next-hop attribute associated with the routes.

In order for BGP to consider a route valid, the very first thing it checks for is the reachability of the next-hop address. From the perspective of R2 and R3, they have no idea how to get to the loopback of the ISP’s BGP router. The best way to fix this would be to do what you said–turn on the “next-hop-self” option for R1.

--Andrew

Excellent Work Rene ! Simple and precise.

Both are working on the same manner in order to overcome the drawback of IBGP full mesh…what is the difference between route reflector and bgp confederation??..

Hi Shiva,

Route reflectors solve the IBGP full mesh issue by using a central RR that has clients, instead of a full mesh.

Confederations reduce the IBGP full mesh by chopping an AS into multiple sub-ASes. Keep in mind that each sub-AS still has the full mesh IBGP requirement, or you can use RRs within a sub-AS.

Both options have (dis)advantages so it depends on your network design if you use one or both options.

Rene

Hello Rene,

Can you tell me if in GNS we have any kind of incompatibility with Confederations.

I did a lab on the GNS3 Cisco Router 7200, when I set up EBGP between R1 x R2 look at the messages.

Configurations?
R1:
image

R2:
image

AS error:
R2:


R1:

Thx

Hi Fabio,

Your config looks fine, it’s the same as mine:

R1#show run | section bgp
router bgp 1
 neighbor 192.168.12.2 remote-as 2
R2#show run | section bgp
router bgp 24
 bgp confederation identifier 2
 neighbor 192.168.12.1 remote-as 1

The error you get is about the BGP router ID:

BGP identifier wrong

Any chance you have the same router ID on R1 and R2?

Rene

Hi Rene,

I was making my own topology for BGP Confederation, I had divided one AS 2 into two sub AS, 100 and 200 and in each sub AS I had configured route -reflector, the router which is connected to the EBGP on both the Sub As is having an error for

 RIB-failure   RIB-NH Matches
88.1.1.0/24        88.1.1.2            Higher admin distance 

This is for both the Sub AS, can you please tell how I can fix it?

R7:

router ospf 2
 log-adjacency-changes
 network 7.7.7.0 0.0.0.255 area 0
 network 14.1.1.0 0.0.0.255 area 0
!
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 2
 neighbor 6.6.6.6 remote-as 200
 neighbor 6.6.6.6 update-source Loopback0
 neighbor 6.6.6.6 next-hop-self
 neighbor 88.1.1.2 remote-as 3
 no auto-summary

R8:

R8#sh run | s bgp
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 network 8.8.8.0 mask 255.255.255.0
 network 88.1.1.0 mask 255.255.255.0
 neighbor 88.1.1.1 remote-as 2
 no auto-summary
R8#

Hello navarj

This failure is due to the fact that there seems to be routing information about this route that is coming from another source that has a lower administrative distance (BGP has the higher AD so it fails or loses, and the route is not added). Can you check to see the source of that higher AD and see where it is coming from? If you find that out, then you can adjust ADs to result in the BGP routes that you want installed.

I hope this has been helpful!

Laz

Hi Laz,

88.1.1.2 is the interface of R8 from where I had configured BGP on this router which has interface add 88.1.1.1, I need to increase AD on R8 as it is on different AS 3 and R7 is on A2.
Can you please upload any videos on it so which can help why it occur where we use iBGP internally and what is the best solution to fix this issue.

Hello Navaraj

Forgive me, but I’m still trying to understand the nature of the problem. Why are you changing the AD on R8, and if so, I don’t see it in your configuration. And if you’re getting an issue with AD, this means that the router is learning of the route from a different source, which we don’t see in what you provided. Can you clarify further so that we can aid in troubleshooting?

Thanks in advance!

Laz

Hi Laz,

R1 is in AS 1, R2, R3, R4, R5, R6, R7 are in AS 2, R3 is in AS 3.
All the neighborship between AS are done via loopback address and in AS2 I am using OSPF to advertise the connectivity, in iBGP I had configured two RR servers that is R3 and R6, I am able to ping from AS 3 to AS 1, but internally in AS 2 i am not able to ping R8 or R1 and the router R2 and R7 are showing

RIB-failure RIB-NH Matches
88.1.1.0/24 88.1.1.2 Higher admin distance

What is solution to fix it? Which node I have configure and why I am getting this problem.

Hello Navaraj

The RIB failure is not necessarily a problem. It seems here that R7 sees that it has a directly connected route of 88.1.1.0/24 in its routing table, which automatically outranks the AD of the route learned via BGP, which is as it should be.

My question is, why does R7 receive routing information to a network that is directly connected? Is 88.1.1.0/24 being advertised via OSPF as well? Can you clarify this information so we can further troubleshoot?

Thanks!

Laz

Hi Laz,

Yes, 88.1.1.0/24 is directly connected between R7 and R8, EBGP is configured via R7 and R8 on the interface which has ip add 88.1.1.0/24. I had advertised 88.1.1.0/24 on R8 via BGP, there is no OSPF advertisement of this network.

Hello Navaraj

The RIB-failure statement you are getting states that the router is learning of the 88.1.1.0/24 network from BGP. This however is a directly connected network, and should be in your routing table as such. The conflict comes from the fact that the AD of the directly connected route outranks the AD of the route being learned via BGP. However, my question is WHY is BGP advertising this route to a router that is directly connected to it? Can you investigate in this direction?

I hope this has been helpful!

Laz

Hi Laz,

I had advertised this network on R8 under BGP, that’s why it is advertised.

Hello Navaraj

Then it is natural that you will have such a message from BGP. This is not necessarily incorrect, and based on the design, is to be expected. The problem you are facing is independent of the specific BGP message that you are sharing. You will have to look elsewhere for the specific problem.

Our goal here is to help you pinpoint the problem by giving some guidelines, or information concerning the next steps to take. I hop this helps you in your troubleshooting procedures.

Laz

Hi Navraj,
As Laz said this is independent of the RIB failure likely as its a connected network for R7. You need to break it down to see where is the connectivity getting lost ? Have you tried some basic checks? May be a traceroute from your internal AS2 router to R8 ? See where is it getting broken. Look at the routing table of it and see if it has a route ? Also it is very important to understand that unless you advertise your internal prefixes in AS2 , there wont be return route in R8 or R1. So this is something to troubleshoot step by step. Hope this helps.
Thanks,
M

1 Like

Infact I set up a similar lab and I don’t see any problem. I am able to ping between R1<<>>R8

R8#ping 1.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 8.8.8.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/102/132 ms
R8#
R1#ping 8.8.8.8 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/137/220 ms
R1#

And if I ping from the AS2 I am not able to ping.

R4#ping 8.8.8.8 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4 
.....
Success rate is 0 percent (0/5)
R4#

Its because R8 or R1 don’t have any return routes to R4.

R8#show ip route 4.4.4.4
% Network not in table
R8#

As soon as I advertize 4.4.4.4 in my IBGP , I am able to ping it.

R4#sh run | s bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 2
 bgp confederation peers 200 
 **network 4.4.4.4 mask 255.255.255.255  >>>>>>> Advertizing 4.4.4.4**
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 5.5.5.5 remote-as 200
 neighbor 5.5.5.5 ebgp-multihop 2
 neighbor 5.5.5.5 update-source Loopback0
 no auto-summary
R4#
R4#ping 8.8.8.8 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4 
!!!!!

So it has no relation to RIB failure or Confedaration or Route-reflector within Sub-AS. I assume you are not advertising the internal subnet of AS 2 in your BGP.

Hope this helps.

Thanks,
Madhu

1 Like