Case study
BGP communities customers can steer with
Summary
The problem
Communities had been added one at a time for years. The public page described behaviour some routers no longer had, graceful shutdown sent by customers was silently ignored, and peer classes had been inferred from old policy instead of set on purpose.
What we did
Designed a second version of the scheme to sit next to the first: informational communities that record where each route was learned and from which class of neighbour, and action communities customers set to keep a route out of a region, prepend, or drain a session with graceful shutdown. Built most of it as data in a peering management tool rather than as template changes, checked the route reflectors for routes already carrying each new value, and deployed to one router first, then in batches, with a check that predicts session resets.
Outcome
Rolled out in full without a single BGP session restart, with partner networks in their own class and a public page that lists only what the routers do.
In more detail
- Customer route
- Peer route
- Held back by a tag
Two kinds of community
Informational communities answer a question customers and peers ask all the time: where did this route come from? Each route carries where it was learned and what kind of neighbour sent it, so a customer can build their own policy on top without asking. Action communities go the other way: the customer attaches one to a route they announce, and the network acts on it. Keep it out of a region, prepend towards a set of neighbours, lower its preference, or blackhole an address under attack.
Add, don’t replace
Customers had built their own routing around the existing values, so none of them was changed. Every new value goes in next to an old one, the old ones keep working, and nothing is retired until the public page has announced it well ahead. One proposed set of aliases was dropped because it would have duplicated values customers were already using.
Checking before a value goes live
A configuration check shows whether a new value collides with policy already on the routers. It doesn’t show whether a customer is already sending that value for some other reason. Before each step, the routes carrying every new value were counted on the route reflectors, so switching a value on can’t silently change how someone’s traffic is handled.
A page that only lists what works
The public page is updated once each step has gone out. The first change was a correction pass: what local preference each kind of neighbour gets, which values reach other customers, and which ones aren’t honoured yet. After that, the page and the routers say the same thing.