BGP Confederation Explained

Hello Leroy

Yes, that is exactly the reason why. To resolve the issue, you can use either one of the two solutions you have indicated, either multihop or disable-connected-check. Both will work as you have confirmed in this particular case.

There is a difference however between the two commands. The disable-connected-check command will disable the check an eBGP router will make to see if the neighbor’s IP address is on the same subnet as one of the local router’s interfaces. This command will not change the TTL count. So this command will enable you to create an eBGP peer with the loopback address of a directly connected router. It will not allow you to create a peering with an eBGP router that may be two or more hops away.

Alternatively, the multihop command will allow you to create a peering between eBGP routers that are two or more hops away simply because it increases the TTL.

More info about these two commands can be found here:

I hope this has been helpful!

Laz

1 Like

Awesome, this is exactly what I needed to see if I was missing something. Thanks for confirming Laz and great write up!

1 Like

Hi Rene,

May I know the confederation design for R21 and R22?
attached diagram and configuration(unfinished). Thank you!
RRweBGP_Confederation.rar (3.6 KB)
)

Chan

Hello Pui Lai

Hmm, I’m not sure what you’re asking. Are you asking for the configurations of R21 and R22? you can take a look at the lesson and see how R2 and R4 have been configured to create a sub-AS. If you follow the same logic, you can create the appropriate configurations on your topology here as well.

Let us know how you get along!

I hope this has been helpful!

Laz

Hi Laz,

Thanks for your reply. But there is a little bit different from the BGP Confederation topology in the example because R1 and R3 in my topology don’t have a connection between them. It is different from the R2 and R4 in the example.
So, should I assign R1 and R3 in my topology a sub-AS in standard configuration?

Chan

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.

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

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

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:

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

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