Home > CCIE, Cisco > BGP Route Reflectors and Confederations

BGP Route Reflectors and Confederations

The Border gateway protocol (BGP) is used to exchange network layer reachability information (NLRI) between Autonomous Systems. Like most routing protocols, BGP also has methods of preventing routing loops within networks. iBGP in particular uses the Split Horizon rule to prevent routing loops. The iBGP Split Horizon rule basically states that an iBGP router will not forward any prefixes learned via iBGP to other iBGP speakers because it assumes a full mesh topology. This means that if you have four routers, R1, R2, R3, R4 connected in a daisy chain. R1 being in AS 100 and R2, R3, R4 being in AS 200, any routes learned by R2 via its eBGP peering to R1 wouldn’t be advertised to R4.

To combat this problem, BGP uses two technologies with the goal of allowing your iBGP routers to still receive all routing updates and not require a full mesh topology.

  • BGP Route-Reflectors
    • Route-reflectors allow iBGP speakers to have a partial mesh topology while still propagating all iBGP learned routes to all iBGP speakers
    • Route-reflectors consist of route-reflector servers and route-reflector clients
    • eBGP routes learned by route-reflector servers are advertised to other eBGP neighbors, route-reflector clients and non-clients.
    • iBGP routes learned from non-clients are advertised to eBGP neighbors and route-reflector clients
    • iBGP routes learned from route-reflector clients are advertised to other clients, non-clients and eBGP neighbors.
  • BGP Confederation
    • Confederations achieve the same goal as Route-reflectors
    • This is done by dividing the main AS into several smaller sub-autonomous systems.
    • Typically  the private range used for these sub ASs are in the range 6451-65535
    • Neighbors in each sub-as must still be fully meshed
    • Confederation iBGP/eBGP peers act the same way as BGP iBGP/eBGP peers.

Let’s first take a look at how we would configure route-reflectors followed by confederations. We’ll be using the topology consisting of 4 routers, R1-R4 as shown below.



Base Configuration for R1

R1#sh run | s router bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 network 2.2.2.2 mask 255.255.255.255
 network 3.3.3.3 mask 255.255.255.255
 network 4.4.4.4 mask 255.255.255.255
 network 192.168.1.0
 neighbor 192.168.1.2 remote-as 200
 no auto-summary

Base Configuration for R2

R2#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.1.0
network 192.168.2.0
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.2.3 remote-as 200
no auto-summary

Base Configuration for R3

R3#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.2.0
network 192.168.3.0
neighbor 192.168.2.2 remote-as 200
neighbor 192.168.3.4 remote-as 200
no auto-summary

Base Configuration for R4

R4#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.3.0
neighbor 192.168.3.3 remote-as 200
no auto-summary


Now let’s take a look at the output of the “show ip bpg” command.

Notice that R2 has learned about the loopbacks that are configured on R1 via it’s eBGP relationship with R1.

R2#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.1.1              0             0 100 i
*> 2.2.2.2/32       192.168.1.1              0             0 100 i
*> 3.3.3.3/32       192.168.1.1              0             0 100 i
*> 4.4.4.4/32       192.168.1.1              0             0 100 i
*  192.168.1.0      192.168.1.1              0             0 100 i
*>                  0.0.0.0                  0         32768 i
* i192.168.2.0      192.168.2.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i
*>i192.168.3.0      192.168.2.3              0    100      0 i

Notice R3 also learns of R1’s loopbacks but this time via iBGP as indicated by the “i” in front of the networks.

R3#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.1/32       192.168.1.1              0    100      0 100 i
*>i2.2.2.2/32       192.168.1.1              0    100      0 100 i
*>i3.3.3.3/32       192.168.1.1              0    100      0 100 i
*>i4.4.4.4/32       192.168.1.1              0    100      0 100 i
*>i192.168.1.0      192.168.2.2              0    100      0 i
* i192.168.2.0      192.168.2.2              0    100      0 i
*>                  0.0.0.0                  0         32768 i
* i192.168.3.0      192.168.3.4              0    100      0 i
*>                  0.0.0.0                  0         32768 i

Here on R4 we see the iBGP split horizon rule in effect.

R4#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.2.0      192.168.3.3              0    100      0 i
* i192.168.3.0      192.168.3.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i

R4 doesn’t learn of R1’s loopback interfaces because R3 isn’t passing the routes on. To correct this problem we’re going to use the first solution available to us, by making R3 a route-reflector server and R4 a route-reflector client. This will then allow R3 to advertise R1’s loopback interfaces to R4. The configuration to make all this happen only needs to be configured on the route-reflector server which is R3 in this case.

Route-reflector configuration for R3

R3(config)#router bgp 200
R3(config-router)#neighbor 192.168.3.4 route-reflector-client

Now let’s take another look at the output of the “show ip bgp” command on R4 to see if it did indeed learn those routes.

R4#sh ip bgp 

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.1/32       192.168.1.1              0    100      0 100 i
*>i2.2.2.2/32       192.168.1.1              0    100      0 100 i
*>i3.3.3.3/32       192.168.1.1              0    100      0 100 i
*>i4.4.4.4/32       192.168.1.1              0    100      0 100 i
*>i192.168.1.0      192.168.2.2              0    100      0 i
*>i192.168.2.0      192.168.3.3              0    100      0 i
* i192.168.3.0      192.168.3.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i
R4#
R4#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Success!!! We see that R4 is indeed now learning the routes via it’s iBGP neighbor R3 and we also have reachability.

Moving onto BGP Confederations. For this example we’re going to use the same topology however we’re going to sub-divide AS200 into As6500 and AS6501

One thing to note about Confederation configurations is that we first create the sub AS and then identify what our actual AS is within BGP sub configuration mode. I personally don’ t know why Cisco decided to implement Confederations in this way but this wouldn’t be the first time we’ve all scratched our heads at how Cisco chooses to implement stuff. Configurations for R1 will remain exactly the same, however for all other routers in AS200 (Confed AS 6500 and AD6501), we’re going to have to first remove the “router bgp 200” configs then proceed with the configurations. R2 and R3 are going to be placed into sub AS 6500 while R4 will be placed in sub AS6501.

The reason for us placing R4 into a separate sub AS to R2 and R3 is because Confederation iBGP/eBGP peers act exactly the same way as iBGP/eBGP peers. This means that a full mesh would still be required for all routers within the same sub AS. Had we placed R4 into the same sub AS as R2 and R3 the split horizon rule would have prevented R3 from advertising the networks on R1, to R4.

Confederations config on R2

R2#sh run | s router bgp
router bgp 6500
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6501
 network 192.168.1.0
 network 192.168.2.0
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.2.3 remote-as 6500
 no auto-summary

Confederations config on R3

R3#sh run | s router bgp
router bgp 6500
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6501
 network 192.168.2.0
 network 192.168.3.0
 neighbor 192.168.2.2 remote-as 6500
 neighbor 192.168.3.4 remote-as 6501
 no auto-summary

Confederations config on R4

R4#sh run | s router bgp
router bgp 6501
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6500
 network 192.168.3.0
 neighbor 192.168.3.3 remote-as 6500
 no auto-summary

Output of “show ip bgp” on R4

R4#sh ip bgp 

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.1.1              0    100      0 (6500) 100 i
*> 2.2.2.2/32       192.168.1.1              0    100      0 (6500) 100 i
*> 3.3.3.3/32       192.168.1.1              0    100      0 (6500) 100 i
*> 4.4.4.4/32       192.168.1.1              0    100      0 (6500) 100 i
*> 192.168.1.0      192.168.2.2              0    100      0 (6500) i
*> 192.168.2.0      192.168.3.3              0    100      0 (6500) i
*  192.168.3.0      192.168.3.3              0    100      0 (6500) i
*>                  0.0.0.0                  0         32768 i

Success!!! R4 learns of R1’s networks via it’s Confederation eBGP relationship with R3. Notice that the networks do not list the “i” in front of them to indicate it as being learnt via iBGP. This shows clearly how similar Confederation eBGP peers and normal eBGP peers are in terms of their neighbor relationships.

As we’ve seen throughout this post, both Route-Reflectors and Confederations can be used to solve the iBGP Split Horizon problem without the need for a full mesh topology within your BGP networks. I personally don’t have any production experience dealing with these technologies but if I had to choose one, I’d go with route-reflector just because the configuration is a lot simpler :-). Also one other advantage that came up during my group  study session with @aconaway was that you would need to plan ahead if you ever wanted to implement Confederations. Reason for this is because the way in which BGP Confederations are configured in IOS. Let’s say we had some eBGP peers early in our network when it was a lot smaller but now your network has grown to a size that requires Confederations. You would need to remove the “router bgp AS” command thereby removing all BGP configurations on that router, then proceed with your Confederation configs where as with route-reflectors you simply need to place the “neighbor x.x.x.x route-reflector-client” command to achieve the same result.

Disclaimer

This post was mainly written to aid me with my studies. The views expressed are based on my understanding and research of the technologies. Because this is a learning process mistakes may be committed to which I would greatly appreciate it if you would point those out via the comments section.

Advertisements
  1. June 20, 2011 at 9:34 PM

    nice share, thank you

  2. Lamma1337
    June 16, 2012 at 8:14 PM

    God, the amount of time you have saved me

  3. hassan
    October 9, 2012 at 2:33 AM

    Good Post …. Thanks

  4. selvam
    January 16, 2013 at 4:32 AM

    Good explanation, Thanks

  5. Kat
    July 10, 2013 at 12:52 AM

    that’s damn good! but the question is where’s the full meshed implementation there? if we are going to make it full mesh, there will be connection from R4 and R2.. what happens next?

  6. Nabarun
    December 3, 2013 at 6:22 AM

    Hi Kat ….. Good question ….. .

    After R4 and R2 connection is possible .After this scenario only configure Confederations and not require route-reflector

    “R3(config)#router bgp 200
    R3(config-router)#neighbor 192.168.3.4 route-reflector-client ”

    .

  7. o.koltsov@t-online.de
    January 15, 2014 at 10:56 AM

    I think confederations are NOT ONLY for solving split horizon. The intention was also to hide your internal structure. RRs can’t handle that…

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: