CCDE – BGP Confederations

Introduction

BGP Confederations are one of two tools a network designer has to work around the full mesh requirement of iBGP. BGP confederations are defined in RFC 5065 which obsoletes RFC 3065. This is how the RFC defines BGP confederations:

This document describes an extension to BGP that may be used
to create a confederation of autonomous systems that is
represented as a single autonomous system to BGP peers
external to the confederation, thereby removing the “full mesh”
requirement. The intention of this extension is to aid in
policy administration and reduce the management complexity
of maintaining a large autonomous system.

The other option to work around the full mesh requirement is of course route reflection.

BGP Confederation Operation and Use Case

BGP confederations work by having several sub AS or member AS that are used internally to divide the BGP domain. From the outside they all look like they are the same AS though. By breaking up the BGP domain, there will be less iBGP peerings which makes the full mesh requirements easier to handle. Do note though that it’s entirely possible to use route reflection within a member AS to combine the two technologies.

BGP confederations made a lot more sense in the early days of BGP when router CPUs were very slow. Today almost all service providers will have moved to route reflection and I doubt many green field deployments would consider confederations today.

When does it make sense to use confederations? Confederations make sense if the organization is such that different teams handle different parts of the network. Choosing to use confederations is then more of a business choice than a technology choice. Imagine a scenario where different teams handle different regions within a country or an international SP consisting of national teams where the SP wants to act as one AS from the outside but use different policies and therefore different member AS on the inside.

Migrating a network to a confederation will be disruptive. Routers that are part of a member AS will need to change their BGP configuration to use the member AS instead of the real AS. They will then use a BGP confederation identifier which is used to replace the member AS with the real AS on real eBGP peerings. There are a few reasons why confederations are not very popular:

• Route reflection solves the same problem as confederations
• Migrating to a confederation is disruptive
• There is a feature called local-as which can be used to act as if you are a different AS

Breaking Up an IGP Domain

Another use case for confederations is to break up the IGP domain. If the IGP domain is very large, it could be divided into areas/levels to decrease the fault domain and the flooding scope. This division of the IGP could then align with the assignment of member AS per region or PoP.

BGP Confederation Operation

Let us then take a look at how BGP confederations work and then we will discuss the advantage of it and some things to be aware of when using confederations.

Standard BGP uses these segment types to modify the AS path:

AS_SET – Unordered set of autonomous systems that a route in the UPDATE message has traversed

AS_SEQUENCE – Ordered set of autonomous systems that a route in the UPDATE message has traversed

The AS path is normally an ordered set of AS numbers unless some form of aggregation has been performed. BGP confederations need to have similar segment types to be able to modify the AS path inside of a confederation.

AS_CONFED_SEQUENCE – Ordered set of Member Autonomous Systems in the local confederation that the UPDATE message has traversed

AS_CONFED_SET – Unordered set of Member Autonomous Systems in the local confederation that the UPDATE message has traversed

BGP routers within a member AS peering are iBGP peers. BGP routers in different member AS peering are eBGP peers which means that the AS path gets prepended when an update travels between member AS. So far, a confederation acts like eBGP but there are some differences between a real eBGP session. On a confederation eBGP session, MED, local pref and the next-hop are sent unmodified which is how an iBGP session acts. Because the next-hop is sent unmodified, that means that either an IGP needs to run across the entire confederation or the border routers need to set the next-hop to themself.

Even though the member AS is prepended when traveling to another member AS, these are not counted as an AS when the BGP best path algorithm runs. So the number of member AS travelled does not affect the AS path length. To make it appear as one AS to all real eBGP peers, the member AS in the AS path need to be stripped when sending updates to these peers. The member AS is normally displayed within paranthesis on Cisco routers internal to the confederation.

What is then the strength of confederations? The advantage of running a confederation is that a policy can be applied for the member AS which does not apply for the entire real AS. One way of doing this is by using communities. There is a BGP community that stops updates from travelling beyond a member AS.

NO_EXPORT_SUBCONFED – All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation).

A member AS can set local preference on an inbound update and set this community to make sure that the update does not travel to another member AS. Different teams within the SP can then use different policies to influence paths in and out of the AS.

Providing Services With BGP Confederations

Service providers run applications such as MPLS VPN and L2 VPNS in their networks. How does running a BGP confederation affect these applications? The first potential issue is that of IP reachability. If a single IGP domain is used, then there is no issue. If there are multiple IGP domains, then there may not be reachability to loopbacks of PEs unless leaking is done between the IGP domains.

The second problem you run into is that you have different BGP AS on your PEs. Normally, VPNv4 is only setup between iBGP peers. This means that to provide a VPN within your confederation you will need to configure your VPNs as if it was an inter provider VPN. More specifically, Inter AS Option B would be used where the confederation eBGP peers would exchange VPNv4 routes. Confederation eBGP peers do not change the next-hop by default which means that either next-hop-self must be configured towards the eBGP peer or the link between the eBGP peers needs to be known in the IGP to generate a label for it so that the LSP does not break. It is also necessary to disable the automatic route target filter on the ASBR or it will discard the VPNv4 updates if it does not have a VRF with an RT matching the update.

This all makes the design much more complex and more likely to break. Providing L2 VPNS also becomes more challenging and I’ll look more at inter AS solutions in another post. It is possible to use Option A and Option C with confederations as well. The most challenging part of the confederation is that the next-hop is not modified.

Closing Words

I would personally think very hard before moving to a BGP design based on confederations. The use case of splitting up IGP domains is valid but there is a better solution called Unified MPLS or seamless MPLS for that. It’s a valid use case to work around the full mesh iBGP restriction but there is a “better” solution for that as well, route reflection. The only valid use case I can think of for confederations is when the structure of the organization requires it.

Do you use BGP confederations? What’s your use case? I would love to hear from you in the comments.