BGP Confederation

This is feature is used to split an autonomous system into smaller autonomous systems or the reverse which is to combine several autonomous systems into one. Reasons of splitting might be IGP's like OSPF might not be able to handle the routes of a really big enterprise so splitting the AS into smaller will help OSPF scale better, or perhaps the enterprise wants to have separate administrative control per region and wants to control the routing policies on their specific regions. This could also be used if there are company mergers and they want to appear as one AS to other EBGP peers. One thing that intrigues me though is that one of the materials I was using mentioned that this could also be a work around for the BGP Split Horizon Rule. I really doubt that Confederations can be a work around for that. I'll find out for sure in this lab.

The diagram below shows 5 Routers with each its own AS number. The goal here to group these routers into one confederation and make them appear as AS1234 to R5 in AS5.


Below are the configurations I have placed on the routers.


R1#sh run | section router bgp
router bgp 1
no synchronization
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
no auto-summary

R2#sh run | section router bgp
router bgp 2
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

R3#sh run | section router bgp
router bgp 3
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

R4#sh run | section router bgp
router bgp 4
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 ebgp-multihop 2
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 5.5.5.5 remote-as 5
neighbor 5.5.5.5 ebgp-multihop 2
neighbor 5.5.5.5 update-source Loopback0
no auto-summary

R5#sh run | section router bgp
router bgp 5
no synchronization
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 4
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

I have configured static routes for reachability. Notice as well that I am using EBGP-multihop feature for EBGP neighbors. I have configured Loopback10 11.11.11.11/32 in R1 and lets see how R2,R3,R4 and R5 see this prefix.


R2# sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 0 1 i

R3#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* 11.11.11.11/32 4.4.4.4 0 4 2 1 i
*> 1.1.1.1 0 0 1 i

R4#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* 11.11.11.11/32 3.3.3.3 0 3 1 i
*> 2.2.2.2 0 2 1 i

R5#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 4.4.4.4 0 4 2 1 i

All of them is seeing this prefix sourcing from an EBGP. Now let's configure R1, R2, R3 and R4 as one confederation and let's see how the BGP table looks like after that. To configure BGP confederations, what are needed is the confederation ID and the peer ASes belonging to that confederation.


R1(config)#router bgp 1
R1(config-router)#bgp confederation identifier 1234
R1(config-router)#bgp confederation peers 2 3 4

R2(config)#router bgp 2
R2(config-router)#bgp confederation identifier 1234
R2(config-router)#bgp confederation peers 1 3 4

R3(config)#router bgp 3
R3(config-router)#bgp confederation identifier 1234
R3(config-router)#bgp confederation peers 1 2 4

R4(config)#router bgp 4
R4(config-router)#bgp confederation identifier 1234
R4(config-router)#bgp confederation peers 1 2 3
R4(config-router)#bgp confederation peers 4
4 Local member-AS not allowed in confed peer list
4 Local member-AS not allowed in confed peer list

As you noticed, you are not allowed to configure your own AS on the "bgp confederation peer command". Ok now let's check how R2,R3,R4 and R5 sees this prefix.


R2#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 100 0 (1) i

R3#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 100 0 (1) i

R4#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* 11.11.11.11/32 1.1.1.1 0 100 0 (3 1) i
* 1.1.1.1 0 100 0 (2 1) i

R5#sh ip bgp

It's clear that its now behaving like they are in one AS. In R4, you can see that it enclosed the AS path in parenthesis, which means AS is using BGP confederation. I have not configured any route reflector here but R4 is still learning the prefix as advertised by R2 and R3. Therefore in some way it circumvents the BGP Split Horizon rule. In a confederation, it may appear like its one AS but it functions how the peering is configured whether its IBGP or EBGP. Going back, R5 is not seeing anything. You know why? It's because R4 doesn't know how to get to 1.1.1.1 inorder to reach 11.11.11.11/32. It won't advertise anything to R5 until it knows how to get to the destination. Let's configure a static route.


R4(config)#ip route 1.1.1.1 255.255.255.255 24.24.24.2
R4(config)#ip route 1.1.1.1 255.255.255.255 34.34.34.3

Then let's see if R4 now sees the best path to 11.11.11.11 in its BGP table.


R4#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 1.1.1.1 0 100 0 (2 1) i

EBGP peering between R4 and R5 is still there but R5 is still using 4 as the remote-as of R4. It may learn the prefix even though the remote-as number for 4.4.4.4 hasn't been changed, however if the link goes down or the BGP session is cleared, BGP will generate now an error that neighbor in wrong AS. Let's change that config to 1234 and check if R5 now sees 11.11.11.11/32.


R5(config)#router bgp 5
R5(config-router)#neighbor 4.4.4.4 remote 1234
R5(config-router)#neighbor 4.4.4.4 update-source Lo0
*Aug 6 16:09:00.259: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Down Remote AS changed.4.4.4
*Aug 6 16:09:02.567: %BGP-5-ADJCHANGE: neighbor 4.4.4.4 Up update lo0
R5(config-router)#neighbor 4.4.4.4 ebgp 2

R5#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 11.11.11.11/32 4.4.4.4 0 1234 i

The AS path to get to 11.11.11.11/32 is now only 1234 and R5 is now seeing the groups of AS as one AS. Well that's all about it regarding Confederations.

Comments

5 Responses to "BGP Confederation"

Ciscoer said... January 7, 2012 at 10:23 PM

Nice!!!!

Anonymous said... June 14, 2012 at 1:29 AM

nice post

Anonymous said... May 27, 2013 at 12:31 AM

Wow lot's of questions on this one. I must be missing something. Why doesn't R2 in the first sh ip bgp show 2nd path through R4? Why does R4 choose the path through R2 over R3? Why does R4 not indicate a selected path with the > ? I do appreciate you taking the time to post.

Anonymous said... August 19, 2013 at 8:59 PM

simple yet powerful explanation..

thanks bro

Hefny said... July 21, 2014 at 3:25 PM

Good explain :)

Post a Comment

Certifications

Certifications

The Dreamer

A fun loving person who enjoys learning new things. Currently working as a Network Engineer supporting the global network of a Fortune 500 company. This blog serves as my notes for the labs I created for my CCIE journey. I can guarantee there are errors in my posts. If you spot them, please let me know.

Join my Facebook Page I WANT TO BE A CCIE

Donate to the Cause

My aim is to create materials for free and possibly a free lab. If you wish to help out, please send any amount. Thanks.

Join my Bandwagon

Blogs that I Read