# BGP Confederation Explained **URL:** \ **Category:** Lessons Discussion\ **Created:** [December 27, 2016, 4:15pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130 "2016-12-27T16:15:10Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [January 3, 2022, 8:46am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/63 "2022-01-03T08:46:46Z")
Hello Pui Lai So then from my understanding, you want to put R1 and R3 into their own sub-AS, correct? Well, I wasn’t sure about this so I went in and labbed it up. The fundamental question here is, can two BGP routers be put into the same sub-AS if they are not directly connected, that is, if they have to pass through another sub-AS to reach each other. Typically, BGP routers can become neighbors even if they’re not directly connected. In the case of iBGP, this is true without any additional configurations. For eBGP, you need to add features such as [multhop](https://networklessons.com/bgp/ebgp-multihop). Now, what about iBGP routers within the same sub-AS? Do they need to be directly connected or can they become neighbors if they can communicate through another sub-AS? Well, it seems that they cannot. iBGP routers that belong to the same sub-AS must connect to each other either directly, or via another iBGP router in the same sub-AS. I’ve labbed it up and confirmed it. So it seems that for your topology, the only solution is to either connect R1 and R3, or don’t create another sub-AS. I hope this has been helpful! Laz ---
**Author:** ![chan.puilai](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/c/67e7ee/32.png) [@chan.puilai](https://forum.networklessons.com/u/chan.puilai)\ **Post date:** [January 3, 2022, 10:42am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/64 "2022-01-03T10:42:25Z")
Thanks Laz, My topology is like that: requirement: R4-\>R5 is reachable R5-\>R4 is reachable R1,R21,R22,R3 should be within iBGP AS 123. R4 is AS4. eBGP peer with AS123. R5 is AS5. eBGP peer with AS123. I don’t care about if R1 and R3 should be inside the same sub-AS or not. I just like R4 and R5 reachable to each other and nothing else. But I am not sure about the exact configuration of them(R1,R21,R22,R3(or even R4 or R5 if they are not simply eBGP)) ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [January 5, 2022, 9:46am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/65 "2022-01-05T09:46:35Z")
Hello Pui Lai Based on your explanation, in order to get your topology to work with your requirements, you do not need to implement confederations at all. (The dark inner rectangle encompassing R21 and R22 was confusing, it looked like a sub-AS). To achieve it you will need: 1. A full mesh of iBGP peerings within AS 123 2. eBGP peerings between R4 and R1 as well as between R5 and R3. 3. Either static routing or a dynamic routing protocol such as OSPF between all routers in AS123 to make them all reachable to each other 4. Advertising of the appropriate networks by all the BGP routers to ensure convergence. For such a configuration, you can follow the configuration in the following lesson: > **[Internal BGP (Border Gateway Protocol) explained](https://networklessons.com/bgp/internal-bgp-border-gateway-protocol-explained)** > > This lesson explains why we need Internal BGP, what IBGP split horizon is about and how to configure IBGP on Cisco IOS Routers. The topology is actually almost the same as the one in your post, except that there are 3 routers in the middle AS instead of your four. Take a look at that, try it out, and if you run into any specific problems, please let us know! I hope this has been helpful! Laz ---
**Author:** ![chan.puilai](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/c/67e7ee/32.png) [@chan.puilai](https://forum.networklessons.com/u/chan.puilai)\ **Post date:** [January 5, 2022, 12:16pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/66 "2022-01-05T12:16:06Z")
> [@lagapidis](#): > > Laz Hi Laz, Thank you. Is there any route refector required? ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [January 10, 2022, 6:06am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/67 "2022-01-10T06:06:24Z")
Hello Pui Lai A route reflector is not required in such a topology. It can be used if you like, but it is unnecessary. Remember, a route reflector solves the problem of the requirement of full mesh peerings between iBGP routers within a single AS **when there are many routers**. How many is “many routers”? I would say dozens or even over one hundred. It also depends upon the number of prefixes being shared as well, which increases the demand on CPU and memory resources on the devices. Although you can configure a route reflector, the topology is nowhere near large enough to actually need one. More info on route reflectors can be found at this [NetworkLessons note on the subject](https://notes.networklessons.com/bgp-route-reflector), as well as at the following lesson: > **[BGP Route Reflector](https://networklessons.com/bgp/bgp-route-reflector)** > > The route reflector helps to reduce the number of IBGP peerings. This lesson explains how it works and how to configure it. I hope this has been helpful! Laz ---
**Author:** ![vsmathur.csco](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@vsmathur.csco](https://forum.networklessons.com/u/vsmathur.csco)\ **Post date:** [March 6, 2022, 3:34am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/68 "2022-03-06T03:34:36Z")
My question is since we are using ibgp and ospf, do we need to redistribute routes from ospf within ibgp on the router towards BGP? i have created a topology similar to discussed, i am able to see peering formed between ibgp peers, all routers configured ospf area 0. and eBGP peers formed between r1 and cata3 and 4. but not seeing any prefixes exchanged on any bgp Cat 3 ```auto Router#sh run | sec bgp router bgp 24 bgp log-neighbor-changes bgp confederation identifier 2 bgp confederation peers 99 network 25.25.25.0 neighbor 7.7.7.7 remote-as 24 neighbor 7.7.7.7 update-source Loopback3 neighbor 25.25.25.25 remote-as 1000 neighbor 50.50.50.50 remote-as 99 neighbor 50.50.50.50 ebgp-multihop 2 neighbor 50.50.50.50 update-source Loopback3 Router#sh run | sec ospf router ospf 2 network 1.1.1.0 0.0.0.255 area 0 network 14.14.14.0 0.0.0.255 area 0 network 15.15.15.0 0.0.0.255 area 0 ``` Cat 4 ```auto Router#sh run | sec bgp router bgp 24 bgp log-neighbor-changes bgp confederation identifier 2 bgp confederation peers 99 neighbor 11.11.11.11 remote-as 99 neighbor 11.11.11.11 ebgp-multihop 2 neighbor 11.11.11.11 update-source Loopback4 neighbor 14.14.14.14 remote-as 24 neighbor 14.14.14.14 update-source Loopback4 neighbor 75.75.75.75 remote-as 1000 Router#sh run | sec ospf router ospf 2 network 1.1.1.0 0.0.0.255 area 0 network 7.7.7.0 0.0.0.255 area 0 network 17.17.17.0 0.0.0.255 area 0 ``` R1 ```auto R1#sh run | sec bgp router bgp 1000 no synchronization bgp log-neighbor-changes network 55.55.55.55 mask 255.255.255.255 neighbor 25.25.25.26 remote-as 2 neighbor 75.75.75.76 remote-as 2 no auto-summary Cat 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 11.11.11.11 4 99 66 67 1 0 0 00:57:32 0 14.14.14.14 4 24 75 76 1 0 0 01:05:19 0 Cat 2 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 7.7.7.7 4 24 62 62 1 0 0 00:53:08 0 50.50.50.50 4 99 67 67 1 0 0 00:57:53 0 Cat 3 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 7.7.7.7 4 24 58 58 1 0 0 00:49:57 0 25.25.25.25 4 1000 33 36 1 0 0 00:29:19 0 50.50.50.50 4 99 77 76 1 0 0 01:06:00 0 Cat4 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 11.11.11.11 4 99 63 63 1 0 0 00:53:51 0 14.14.14.14 4 24 59 58 1 0 0 00:50:20 0 75.75.75.75 4 1000 30 32 1 0 0 00:26:27 0 R1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 25.25.25.26 4 2 37 34 4 0 0 00:30:02 0 75.75.75.76 4 2 32 30 4 0 0 00:26:47 0 ``` Any help is appreciated 🙂 thanks in advance. ![image](https://cdn-forum.networklessons.com/uploads/default/original/2X/c/c771b3e7ecf75ba2074b7bbcb772856aa3e97a25.png) ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [March 8, 2022, 9:39am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/69 "2022-03-08T09:39:04Z")
Hello Vivek > [@vsmathur.csco](#): > > My question is since we are using ibgp and ospf, do we need to redistribute routes from ospf within ibgp on the router towards BGP? The IGP that you use within an AS (such as OSPF) should remain only within that AS. There should be no redistribution of IGP routes into other ASes. In this particular case, OSPF should share all routes within your AS2, and only eBGP should be used to share routes between AS2 and AS1000. This is best practice, and it is also the very reason why BGP was created. Now having said that, why would R1 not contain any of the prefixes advertised within AS2? Well, first I see that your BGP peerings look correct, with the correct AS numbers. I suggest you take a look at the following: 1. CAT 3 and CAT 4 are only advertising the 25.25.25.0/24 and 75.75.75.0/24 networks to which they are directly connected, so there are no networks beyond those, advertised by these two devices. 2. Check to see what other networks are being advertised by CAT1 and CAT2 to see what exists within the BGP tables of all of the routers in AS 2. Remember that BGP will only advertise networks indicated with the `network` command or networks that are redistributed. More about this can be found in the following lesson: > **[How to advertise networks in BGP](https://networklessons.com/bgp/how-to-advertise-networks-in-bgp)** > > This lesson teaches you the different methods how you can advertises networks in BGP (Border Gateway Protocol) on Cisco IOS devices. Remember also that prerequisites to a prefix being advertised is that the prefix itself is found in the local routing table with the exact same subnet mask. Let us know how you get along and if you need any additional help in your troubleshooting process. I hope this has been helpful! Laz ---
**Author:** ![vaze.v](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/v/49beb7/32.png) [@vaze.v](https://forum.networklessons.com/u/vaze.v)\ **Post date:** [August 12, 2022, 7:56am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/70 "2022-08-12T07:56:05Z")
Hello Rene, Thanks alot for this amazing explaination ! I just had one small doubt considering the topology that is used. We see that the route advertised by R1 appears on R5 with two paths available. One from the confed-Internal and one is from confed-External, as mentioned if BGP doest not distinguish between confed and normal internal/external peerings for best path selection, then why R5 selects route to R1’s loopback through R3 (internal bgp) instead of through R4(external bgp) as we usually prefer external bgp routes to internal. Thanks in advance for answering ! ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [August 17, 2022, 12:30pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/71 "2022-08-17T12:30:54Z")
Hello Vikrant When we apply confederations, as far as BGP is concerned, you are using iBGP regardless of whether you are communicating with a router in your own sub-AS or a different sub-AS, as long as the routers are both in the same normal AS. As Rene says: > In the BGP best path selection algorithm, there is no distinction between confederation external or internal. So from the point of view of R5, the peerings with R3 and R4 **are considered the same, that is, both use iBGP** because they’re in the same normal AS of 2. So the only thing that will make R5 choose one peer over the other is the lowest router ID which is that of R3. I hope this has been helpful! Laz ---
**Author:** ![vaze.v](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/v/49beb7/32.png) [@vaze.v](https://forum.networklessons.com/u/vaze.v)\ **Post date:** [August 17, 2022, 6:35pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/72 "2022-08-17T18:35:14Z")
Thanks a lot !!! This surely clears it !!! ---
**Author:** ![davidilles](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/davidilles/32/9686_2.png) [@davidilles](https://forum.networklessons.com/u/davidilles)\ **Post date:** [July 16, 2023, 9:23am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/73 "2023-07-16T09:23:41Z")
Hello, everyone! In the real world, what’s more commonly used to avoid the iBGP full-mesh requirement? Route Reflectors or Confederations? Or does it depend? Because I find RRs way easier to understand and also configure. Confederations also require some more planning, correct? Thank you in advance for your help. David ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [July 20, 2023, 5:53am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/74 "2023-07-20T05:53:27Z")
Hello David You are indeed correct that both RRs and confederations are used to manage large ASes where a conventional iBGP full-mesh would be too cumbersome to deploy. And it is also true that in general, RRs are simpler to deploy than confederations. So when should we use one or the other? Here are some guidelines that will help to make such a decision: RRs are generally preferred in networks where **simplicity of configuration and maintenance are paramount**. The primary use case for RRs is within a single, large AS. One drawback of using RRs is the fact that you have a single point of failure (the RR) but that can be remedied by applying a redundant RR. Confederations, on the other hand, are typically used in complex network environments where the organization has a need for extensive control over routing policy and wants to manage it in a hierarchical way. They are particularly useful for large, complex networks divided into many different segments or subnetworks. Essentially we are saying that confederations scale better than RRs simply because you are breaking your AS into smaller ASes. Additionally, confederations give you a higher degree of control over routing policies between different parts of your AS, assuming your AS can be organized in such a way that it is effectively divided into sub-ASes with a clear hierarchy. Of course, as you mentioned, there is a tradeoff. Confederations are more complex, but they give you more control. So in a nutshell, while both techniques can be used to simplify iBGP configurations, RRs are typically easier to implement and manage, making them suitable for simpler networks. Confederations, while more complex, offer more fine-grained control and flexibility, making them more suitable for larger or more complex networks. I hope this has been helpful! Laz ---
**Author:** ![davidilles](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/davidilles/32/9686_2.png) [@davidilles](https://forum.networklessons.com/u/davidilles)\ **Post date:** [July 21, 2023, 1:00pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/75 "2023-07-21T13:00:20Z")
Hello Laz! I appreciate your help here, thank you very much 🙂 It’s probably a nitpicky detail but there’s one more thing that I would like to know. I know that routers in a Sub-AS prepend a path attribute called “AS\_CONFED\_SEQ” which is an organized list of Sub-ASes the traffic traversed through to the AS Path field ![obrázok](https://forum.networklessons.com/uploads/default/original/2X/f/fe6e686bb180f54f2b9d6b04b9d5e54572e92750.png) However, as you can see, these ASNs are also prepended to the AS Path field itself. Any idea why? From what I’ve read, they are not used when determining the shortest path to any destinations and there’s already a path attribute called AS\_CONFED\_SEQ which is an ordered list of confederation ASNs the UPDATE packet traversed through. So can’t the router just use AS\_CONFED\_SEQ to see which Sub-ASes did the traffic pass through? Why’s there also the need to prepend it to the AS Path field itself? David ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [July 28, 2023, 5:40am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/76 "2023-07-28T05:40:04Z")
Hello David It’s interesting to look at the inner workings of BGP and how the format of its updates changes depending on whether or not confederations are used. [RFC 3065](https://datatracker.ietf.org/doc/html/rfc3065#section-6.1) explains in detail the use of the AS\_CONFED\_SEQUENCE attribute, and there are specific modification rules that are used to determine how and when it is used. Now that takes care of how the mechanism works. The question now is why is it done this way? Well, first of all, we have to keep in mind that the AS\_PATH itself has no notion of sub-ASes. The ASes in the path are those that have been traversed, and it makes no distinction between whether they are normal ASes or sub-ASes. For this reason, we need another attribute (the AS\_CONFED\_SEQUENCE attribute) to identify which of those ASes are sub-ASes. These must be identified so that they are dealt with correctly under all circumstances, as described in the RFC. Does that make sense? I hope this has been helpful! Laz ---
**Author:** ![ernesto.herrerab](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/e/94ad74/32.png) [@ernesto.herrerab](https://forum.networklessons.com/u/ernesto.herrerab)\ **Post date:** [December 18, 2023, 4:58pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/77 "2023-12-18T16:58:00Z")
Hello there, I saw that the lesson states that the AS\_CONFED\_SET is created as a path attriubute. I was using Wireshark to check this anc could not find it. It seems this is now not recommended according to the below: [https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/](https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/) so I am guessing the routers I am using do not use this attribute. Thanks ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [December 20, 2023, 6:39am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/78 "2023-12-20T06:39:41Z")
Hello Ernesto You’re correct. The AS\_CONFED\_SET is indeed a path attribute that was previously utilized. However, as per the draft you linked, it is now recommended to deprecate the use of AS\_SET and AS\_CONFED\_SET in BGP. This is due to the fact that these attributes can create routing loops if not managed correctly. This draft is quite new, not even a half year old at the time of the writing of this post. Even so, it is possible the routers you’re using have updated their software to align with this recommendation, hence why you’re not seeing the AS\_CONFED\_SET attribute in Wireshark. What routers and IOS are you using? I hope this has been helpful! Laz ---
**Author:** ![mpdr0406](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/m/839c29/32.png) [@mpdr0406](https://forum.networklessons.com/u/mpdr0406)\ **Post date:** [January 8, 2024, 1:15pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/79 "2024-01-08T13:15:41Z")
There are two things which i would like to highlight 1. you might need to change the statement as “There’s one more thing we have to do…since the next hop doesn’t change with iBGP” _ **Configuration example** _ There’s one more thing we have to do…since the next hop doesn’t change with BGP, our routers will not know how to reach 192.168.12.1 (R1). I’ll fix this by advertising the 192.168.12.0 /24 network in BGP: ```auto R2(config)#router bgp 24 R2(config-router)#network 192.168.12.0 mask 255.255.255.0 ``` 1. We normally do not advertise external links into BGP , in the above configuration example you have advertised 192.168.12.0/24 into bgp , instead we can change the next hop behaviour with the command “next-hop-self” . cant we just configure R2 as below ```auto R2(config-router)#neighbor 192.168.23.3 next-hop-self R2(config-router)#neighbor 192.168.24.4 next-hop-self ``` ---
**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\ **Post date:** [January 10, 2024, 5:28am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/80 "2024-01-10T05:28:34Z")
Hello Deepak > [@mpdr0406](#): > > 1. you might need to change the statement as “There’s one more thing we have to do…since the next hop doesn’t change with iBGP” I will let Rene know to reword this so that it is more accurate. The next hop does not change when R2 shares its route to the destination with its **iBGP** peers. > [@mpdr0406](#): > > 1. We normally do not advertise external links into BGP , in the above configuration example you have advertised 192.168.12.0/24 into bgp , instead we can change the next hop behaviour with the command “next-hop-self” . cant we just configure R2 as below Best practice is indeed to use the `next-hop-self` command in this case. However, for the purposes of this lesson, Rene has chosen to use the `network` command to advertise this network for simplicity and quickness. If he introduced the `next-hop-self` feature now, he would have to explain it, but the focus of the lesson is on the explanation of confederations. There is another lesson that deals with the `next-hop-self` feature. > **[BGP Next Hop Self](https://networklessons.com/bgp/bgp-next-hop-self)** > > When you advertise something in iBGP then the next hop IP address doesn't change. We can change this with the next-hop-self command. Thanks for the feedback! I hope this has been helpful! Laz ---
**Author:** ![ReneMolenaar](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/renemolenaar/32/488_2.png) [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)\ **Post date:** [January 17, 2024, 3:55pm UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/81 "2024-01-17T15:55:00Z")
Hi @mpdr0406 Thanks for the suggestion. Like @lagapidis said, I used the `network` command to keep it simple. I added a note with a link to the BGP next hop self lesson though. Rene ---
**Author:** ![Joey\_Doe](https://cdn-forum.networklessons.com/letter_avatar_proxy/v4/letter/j/a587f6/32.png) [@Joey\_Doe](https://forum.networklessons.com/u/Joey_Doe)\ **Post date:** [January 18, 2024, 8:00am UTC](https://forum.networklessons.com/t/bgp-confederation-explained/1130/82 "2024-01-18T08:00:42Z")
Hi team, Very simple question: R3 learns R1’s Loopback from R2. But how come R3 does not learn R1’s Loopback from R5? I see that it could create a loop: R3 going to R5 and vice versa for R1’s Loopback if R2 had a higher router-ID than R5. I know I miss something [Previous page](https://forum.networklessons.com/t/bgp-confederation-explained/1130.md?page=3) [Next page](https://forum.networklessons.com/t/bgp-confederation-explained/1130.md?page=5)