BGP Notes – Confederations

  • RFC 3065
  • BGP confederations reduce the size of full mesh iBGP ASes by dividing it up into different areas.
  • Confederations also remove the need for BGP synchronization since all iBGP routers will have all routes.
  • In effect, your iBGP AS gets chopped up into different sub-ASes.
  • Each router is a member of a sub-AS and is a neighbor with every other router in that sub-AS (full mesh).
    • Neighbors within a sub-AS are called confederation iBGP neighbors.
    • Confederation iBGP neighbors act just like any other iBGP neighbor.
  • At least one member of each sub-AS is neighbored with members of different sub-ASes.
    • Neighbors in different sub-ASes are called confederation eBGP neighbors.
    • Confederation eBGP neighbors have a default TTL of 1 just like true eBGP neighbors.
    • The NEXT_HOP PA is not changed when passing routes between sub-ASes.
    • LOCAL_PREF is also preserved.
  • Confederations use the AS_CONFED_SEQ and AS_CONFED_SET fields in the AS_PATH PA.
    • These fields act like AS_PATHs to prevent loops.
    • These fields are cleared out when the route is passed to an eBGP neighbor.
    • If components of a summary route (an aggregate-address) have different AS_CONFED_SEQ values, the AS_CONFED_SET is used.
  • Confederations ASes are not included when the router decides which route is best.
  • BGP confederation routers are configured to be in a private ASN.
    • The confederations should be private to avoid AS conflicts.
    • The confederation identifier defines the AS at it appears to the world.

Comment with corrections, please.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. If you have any questions, the best way to contact me is through Twitter at @aconaway.

More Posts

Follow Me:

1 comment for “BGP Notes – Confederations

Leave a Reply

Your email address will not be published.