Thanks Taslim. I’ll add these two topics to my list.
Hello there! I noticed that you also have OSPF running. Is there any type of redistribution going on here?
No redistribution configs was listed, so I am just wondering. Can you please explain?
We require an IGP when we run IBGP to advertise loopback interfaces that are used for the neighbor adjacency. Take a look at this lesson, it explains everything:
Thanks Rene , keep going man
Nice explanation. I am bit confused about the use of the command bgp confederation identifier 2
Should we use this command only to that router (R2) connecting to EBGP peers-R1 (the External Autonomous System, in this case 1 )?
Or should we use the command also in the routers connecting to Sub-AS (inside the IBGP)?
I saw you have used the command in all Routers. But do we need to use in all the sub-as routers? I am bit confused. Your help is highly appreciated.
You have to configure this on all routers within the sub-AS otherwise they won’t consider themselves part of the confederation. They will be able to establish BGP peerings but they’ll consider other routers in the confederation as regular “external” or “internal” neighbors. They will also drop routes when they see a confederation path in it.
I tested this, here is the output of some show commands when I removed “bgp confederation identifier 2” on R3, R4 and R5:
R3#show ip bgp 22.214.171.124 BGP routing table entry for 126.96.36.199/32, version 19 Paths: (1 available, best #1, table default) Flag: 0x820 Advertised to update-groups: (Pending Update Generation) 3 Refresh Epoch 1 (24) 1 192.168.12.1 (metric 2) from 188.8.131.52 (184.108.40.206) Origin IGP, metric 0, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0
R4#show ip bgp 220.127.116.11 BGP routing table entry for 18.104.22.168/32, version 20 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 Refresh Epoch 1 1 192.168.12.1 (metric 2) from 22.214.171.124 (126.96.36.199) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0
R5#show ip bgp 188.8.131.52 BGP routing table entry for 184.108.40.206/32, version 25 Paths: (2 available, best #2, table default) Advertised to update-groups: 1 Refresh Epoch 1 24 1 192.168.12.1 (metric 3) from 220.127.116.11 (18.104.22.168) Origin IGP, metric 0, localpref 100, valid, external rx pathid: 0, tx pathid: 0 Refresh Epoch 1 (24) 1 192.168.12.1 (metric 3) from 22.214.171.124 (126.96.36.199) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0
Here’s one of the errors I noticed:
R4# %BGP-6-ASPATH: Invalid AS path 35 (24) received from 188.8.131.52: Confederation AS-path found in the middle
Hope this helps.
Thanks for the information. Yes that is correct.
However, I simulated a similar lab like yours but I have not connected R4 and R5 that you have done, only to see if those router can communicate with R1. And i found out that if i don’t connect R4 and R5 to each other as redundant link then those two router do not need the “bgp confederation peer” and “bgp confederation identifier” commands. Also I found out that those two commands are mandatory for R2 and R3. Since, R2 is connecting External AS router R1 and Internal “sub-as” router R3 and R3 is connecting internal “sub-as” router R2 so these R2 and R3 routers need those commands.
I truly appreciate your help to clear my concept on BGP confederation…
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? 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.
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 184.108.40.206 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 220.127.116.11 .
Is this case we can also use next-hop-self command ? or using igp like ospf is the only option?
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.
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??..
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.
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.
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?
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 18.104.22.168/24 22.214.171.124 Higher admin distance
This is for both the Sub AS, can you please tell how I can fix it?
router ospf 2 log-adjacency-changes network 126.96.36.199 0.0.0.255 area 0 network 188.8.131.52 0.0.0.255 area 0 ! router bgp 200 no synchronization bgp log-neighbor-changes bgp confederation identifier 2 neighbor 184.108.40.206 remote-as 200 neighbor 220.127.116.11 update-source Loopback0 neighbor 18.104.22.168 next-hop-self neighbor 22.214.171.124 remote-as 3 no auto-summary
R8#sh run | s bgp router bgp 3 no synchronization bgp log-neighbor-changes network 126.96.36.199 mask 255.255.255.0 network 188.8.131.52 mask 255.255.255.0 neighbor 184.108.40.206 remote-as 2 no auto-summary R8#
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!
220.127.116.11 is the interface of R8 from where I had configured BGP on this router which has interface add 18.104.22.168, 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.
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!
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
22.214.171.124/24 126.96.36.199 Higher admin distance
What is solution to fix it? Which node I have configure and why I am getting this problem.