# BGP Confederation Explained

Lesson Contents

In this lesson, we’ll take a look at the BGP Confederation. As you might know, IBGP requires a full mesh of peerings which can become an administrative nightmare. If you don’t know why we need a full mesh, I recommend to start reading my IBGP lesson first.

To reduce the number of IBGP peerings there are two techniques:

Let’s talk about confederations, look at the picture below:

Above we have AS 1 with 6 routers running IBGP. The number of IBGP peerings can be calculated with the full mesh formula:

N(N-1)/2

So in our case that’s:

6 * (6-1 = 5) / 2  = 15 IBGP peerings.

A BGP confederation divides our AS into sub-ASes to reduce the number of required IBGP peerings. Within a sub-AS we still require full-mesh IBGP but between these sub-ASes we use something that looks like EBGP but behaves like IBGP (called confederation BGP) . Here’s an example of what a BGP confederation could look like:

By dividing our main AS into two sub-ASes we reduced the number of IBGP peerings from 15 to 8.

Within the sub-AS we still have the full-mesh IBGP requirement. Between sub-ASes it’s just like EBGP, it’s up to you how many peerings you want. The outside world will never see your sub-AS numbers, they will only see the main AS number.

Since the sub-AS numbers are not seen outside of your network you will often see private AS numbers used for the sub-ASes (64512 – 65535) but you can pick any number you like.

You should now have an idea what BGP confederations are like, let’s look at the configuration so I can add some more details. I’ll use the following topology:

Above we have AS 2 which is divided into two sub-ASes, AS 24 and AS 35. There’s also AS 1 on top that we can use to see how the outside world sees our confederation.

Let’s look at the configuration shall we?

## Configuration

Just like any other IBGP configuration it’s best practice to use loopback interfaces for the BGP sesssions. For this reason I created a loopback interface on all routers within AS 2 and I’ll use OSPF to advertise them.

### OSPF Configuration

``````R2(config)#router ospf 1
R2(config-router)#network 192.168.23.0 0.0.0.255 area 0
R2(config-router)#network 192.168.24.0 0.0.0.255 area 0
R2(config-router)#network 2.2.2.2 0.0.0.0 area 0``````
``````R3(config)#router ospf 1
R3(config-router)#network 192.168.23.0 0.0.0.255 area 0
R3(config-router)#network 192.168.35.0 0.0.0.255 area 0
R3(config-router)#network 3.3.3.3 0.0.0.0 area 0``````
``````R4(config)#router ospf 1
R4(config-router)#network 192.168.24.0 0.0.0.255 area 0
R4(config-router)#network 192.168.45.0 0.0.0.255 area 0
R4(config-router)#network 4.4.4.4 0.0.0.0 area 0``````
``````R5(config)#router ospf 1
R5(config-router)#network 192.168.35.0 0.0.0.255 area 0
R5(config-router)#network 192.168.45.0 0.0.0.255 area 0
R5(config-router)#network 5.5.5.5 0.0.0.0 area 0``````

Now we can worry about the BGP confederation configuration. I’ll explain all the different steps…

### BGP Confederation Configuration

Let’s start with R2:

``````R2(config)#router bgp 24
R2(config-router)#bgp confederation identifier 2
R2(config-router)#bgp confederation peers 35
R2(config-router)#neighbor 4.4.4.4 remote-as 24
R2(config-router)#neighbor 4.4.4.4 update-source loopback 0
R2(config-router)#neighbor 3.3.3.3 remote-as 35
R2(config-router)#neighbor 3.3.3.3 update-source loopback 0
R2(config-router)#neighbor 3.3.3.3 ebgp-multihop 2``````

The configuration of R2 requires some explanation. First of all, when you start the BGP process you have to use the AS number of the sub-AS. Secondly, you have to use the bgp confederation identifier command to tell BGP what the main AS number is.

We also have to configure all other sub-AS numbers with the bgp confederation peers command, in this case that’s only AS 35. R4 is in the same sub-as so you can configure this neighbor just like any other IBGP neighbor. R3 is a bit different though…since it’s in another sub-AS we have to use the same rules as EBGP, that means configuring multihop if you are using loopbacks.

Let’s take a look at R3:

``````R3(config)#router bgp 35
R3(config-router)#bgp confederation identifier 2
R3(config-router)#bgp confederation peers 24
R3(config-router)#neighbor 2.2.2.2 remote-as 24
R3(config-router)#neighbor 2.2.2.2 update-source loopback 0
R3(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R3(config-router)#neighbor 5.5.5.5 remote-as 35
R3(config-router)#neighbor 5.5.5.5 update-source loopback 0``````

The configuration of R3 is similar to R2. We configure it to use AS 35 while the main AS is 2. Our only sub-AS peer is 24 and we have two neighbors…one IBGP neighbor and one “EBGP” (confederation BGP) neighbor.

R4 and R5 look pretty much the same:

``````R4(config)#router bgp 24
R4(config-router)#bgp confederation identifier 2
R4(config-router)#bgp confederation peers 35
R4(config-router)#neighbor 2.2.2.2 remote-as 24
R4(config-router)#neighbor 2.2.2.2 update-source loopback 0
R4(config-router)#neighbor 5.5.5.5 remote-as 35
R4(config-router)#neighbor 5.5.5.5 update-source loopback 0
R4(config-router)#neighbor 5.5.5.5 ebgp-multihop 2``````
``````R5(config)#router bgp 35
R5(config-router)#bgp confederation identifier 2
R5(config-router)#bgp confederation peers 24
R5(config-router)#neighbor 4.4.4.4 remote-as 24
R5(config-router)#neighbor 4.4.4.4 update-source loopback 0
R5(config-router)#neighbor 4.4.4.4 ebgp-multihop 2
R5(config-router)#neighbor 3.3.3.3 remote-as 35
R5(config-router)#neighbor 3.3.3.3 update-source loopback 0``````

That takes care of configuring the neighbors. The more interesting part is of course using some show commands to see the differences with normal IBGP and EBGP. Let’s get going…

## Verification

To have something we can look at I will create a loopback interface on R5 and advertise a network in BGP:

``````R5(config)#interface loopback 5
R5(config-if)#ip address 55.55.55.55 255.255.255.255``````

Let’s advertise it in BGP:

``````R5(config)#router bgp 35
R5(config-router)#network 55.55.55.55 mask 255.255.255.255``````

Let’s look at R3 first, this router is in the same sub-AS as R5:

``````R3#show ip bgp 55.55.55.55
BGP routing table entry for 55.55.55.55/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
2
Local
5.5.5.5 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best``````

This entry looks pretty much the same as normal IBGP but there’s one important difference…

### We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

• Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
• Try for Just \$1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
• Full Access to our 722 Lessons. More Lessons Added Every Week!
• Content created by Rene Molenaar (CCIE #41726)

532 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:

## Forum Replies

1. Dear Ahammad,

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 11.11.11.11
BGP routing table entry for 11.11.11.11/32, version 19
Paths``````
... Continue reading in our forum

2. Dear Rene,

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 con

... Continue reading in our forum

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

... Continue reading in our forum

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

5. 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-tri``````
... Continue reading in our forum

51 more replies! Ask a question or join the discussion by visiting our Community Forum