BGP Confederation Explained

Hi Laz,

Thank you. Is there any route refector required?

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, as well as at the following lesson:

I hope this has been helpful!

Laz

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

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

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

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 :slight_smile: thanks in advance.

Hello Vivek

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:

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

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 !

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

1 Like

Thanks a lot !!! This surely clears it !!!

1 Like

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

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

Hello Laz!

I appreciate your help here, thank you very much :slight_smile:

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

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

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 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

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/ so I am guessing the routers I am using do not use this attribute.

Thanks

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

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:

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
R2(config-router)#neighbor 192.168.23.3 next-hop-self
R2(config-router)#neighbor 192.168.24.4 next-hop-self

Hello Deepak

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.

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.

Thanks for the feedback!

I hope this has been helpful!

Laz

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

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

Hello Guillaume

If you look at the BGP best path algorithm and take a look at all of the attributes that are chosen and examined, you will find that the tie breaker in this particular case for R3 to learn about R1’s loopback from R2 and not from R5 is the “eBGP over iBGP routes” attribute. Take a look at the topology once again:

R3 will learn about 11.11.11.11 from both R2 and R5, but will prefer the route learned via R2 because it was learned from an eBGP peer rather than an iBGP peer. Even within a confederation, BGP routers prefer routes learned from other sub-ASes rather than those learned from within their own sub-AS. All the previous attributes would be equal. So you never get o the “higher router ID” attribute.

I hope this has been helpful!

Laz

Hi Laz,

Thanks for the answer. That’s what I thought initially. But considering this sentence in the document:

“R5 has two options: it learns about this route from R3 (confed-internal) or R4 (confed-external). The BGP best path selection algorithm has no distinction between confederation external or internal. In this case, the path was chosen based on the lowest router ID.”

I thought that BGP confederation changed that somehow. Would you care to explain why R5 would prefer a prefix from R3 (iBGP) rather than from R4 (eBGP) when you just stated that eBGP is always preferred over iBGP even in BGP confederation?

Cheers

Hello Guillaume

You’re absolutely correct, my apologies. Indeed, when dealing with confederations, the best path algorithm does not prefer routes learned from BGP peers in another sub-AS over those learned from BGP peers in the same sub-AS.

After thinking about this a little bit more, I realized the the reason R3 doesn’t learn about the loopback of R1 via R5 is because of the iBGP split horizon rule. Note that R5 has learned about the 11.11.11.11/32 network from R3. Thus, it will not re-advertise that route back to R3. So R3 never gets informed about this network from R5, thus it only has the route via R2 in its BGP table. Does that make sense?

I hope this has been helpful!

Laz