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