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.

More Posts

Follow Me:
Twitter

1 comment for “BGP Notes – Confederations

Leave a Reply

Your email address will not be published. Required fields are marked *