BGP Communities and Route Filtering: Controlling Your Routing

Once you are running BGP with your own ASN, the difference between a well-behaved network and one that ends up in a public outage report comes down to control. BGP is a trusting protocol by design — it accepts and propagates what its neighbours tell it — so the safety and the precision of your routing depend entirely on the policy you wrap around it. That policy has two halves: filtering, which decides what routes you accept and announce, and steering, which decides which of the available paths traffic actually takes.

Get filtering wrong and you become the network that leaked the internet to a peer and broke connectivity for thousands of people. Get steering wrong and you simply overpay or deliver worse latency than you could. Both deserve deliberate design, and the good news is that the tools — prefix filters, RPKI validation, max-prefix limits, communities, local preference, and AS-path prepending — are well understood and available on every serious router. The discipline is in applying them consistently.

Why BGP needs a safety belt at all

BGP has no built-in sense of whether an announcement is legitimate. If a neighbour tells you it can reach a prefix, BGP will, by default, believe it and may pass that claim along to others. This is what makes route leaks and hijacks possible: a misconfiguration or a malicious actor announces prefixes it should not, and without filtering those announcements propagate and divert traffic. Every famous BGP incident in internet history shares this root cause — somewhere, a network accepted or announced routes it should have filtered. Your filters are the mechanism that stops your network from being either the victim or the cause.

Inbound filtering: protecting yourself from others

Inbound filtering governs what you accept from neighbours, and its job is to reject anything that cannot legitimately be there. Several layers work together. First, drop bogons — private, reserved, and unallocated address ranges that should never appear in the global routing table. Second, enforce a maximum prefix limit on each session: if a peer that normally sends you a few thousand routes suddenly sends hundreds of thousands, that is almost certainly a leak, and the max-prefix limit tears the session down before the flood reaches your routers and your memory.

Third, and increasingly essential, validate route origins with RPKI. Route Origin Validation lets you check, against cryptographically signed records, whether the network originating a prefix is actually authorised to do so. Routes that fail validation can be dropped or de-preferred, which directly blunts the most common form of route hijack. Together, bogon filters, max-prefix limits, and RPKI form a defence in depth: each catches a different class of bad announcement, and running all three is now standard practice for a responsible network.

Outbound filtering: protecting everyone from you

Outbound filtering is the half that protects the rest of the internet from your mistakes, and it is the one that prevents the most catastrophic class of incident. The rule is simple to state and easy to get wrong: announce only your own prefixes and your customers' prefixes, and nothing else. In particular, never re-announce to one peer the full internet table you learned from another. Doing so tells the world you are a transit path to everywhere, traffic floods toward you, and you melt down while disrupting connectivity far beyond your own network. That is the classic route leak, and strict, explicit outbound filters are what prevent it.

The safest posture is a default-deny outbound policy: build an explicit list of exactly which prefixes you are allowed to announce — your own allocations and your authenticated customers' — and announce only those. Anything not on the list is dropped. This turns the dangerous default of BGP, where it is easy to accidentally announce too much, into a controlled list where announcing something requires a deliberate addition.

Filtering directions at a glance

BGP communities: tags that carry intent

A community is a label you attach to a route. On its own it changes nothing — it is metadata, a tag that routing policy can match against and act upon. That indirection is exactly what makes communities powerful: instead of writing a separate rule for every individual prefix, you tag routes by some shared property and write one policy that acts on the tag. The result is policy that is consistent, readable, and far easier to maintain as your network grows.

Two patterns dominate. Internally, you tag routes by where they entered your network — which peer, which region, which type of relationship — so that downstream policy can treat all routes from, say, a particular IXP consistently without anyone hand-listing prefixes. Externally, many transit providers publish a catalogue of communities you can set on the routes you send them, which instruct their network how to handle your routes: prepend toward a specific region, suppress an announcement to a particular peer, or adjust local preference inside their network. This lets you steer how the rest of the world reaches you in a clean, standardised, self-service way — no emails to a provider's NOC required.

Steering traffic: local-pref and AS-path prepending

Filtering decides which routes exist in your view; steering decides which of those you actually use, and which paths others use to reach you. The two primary levers point in opposite directions. Local preference controls your outbound traffic: it is the highest-weight tie-breaker in BGP's path selection, so setting a higher local-pref on routes learned from a preferred upstream makes your network send traffic out that way. Operators routinely use it to prefer cheaper peering over more expensive transit, or to prefer a lower-latency path.

AS-path prepending influences inbound traffic. Because BGP tends to prefer shorter AS paths, artificially lengthening the path you advertise out one link — by repeating your own ASN a few times — makes that path look less attractive to the outside world, nudging incoming traffic toward your other links. It is a blunt instrument with limited granularity, but it is widely understood and works without anyone else's cooperation. Used together with provider communities, local-pref and prepending let you balance cost and performance across multiple upstreams with reasonable precision.

Common mistakes

The most dangerous mistake is weak or absent outbound filtering, which is how networks accidentally become the internet's unintended transit and trigger major leaks. The second is forgetting max-prefix limits, leaving a single misbehaving session free to flood your routers. The third is treating RPKI as optional; origin validation has become baseline hygiene, and skipping it leaves you exposed to common hijacks. On the steering side, the frequent error is over-prepending — stacking on so many path repetitions that traffic engineering becomes unpredictable — or building an undocumented community scheme that no one but its author can decode six months later. Communities are only as useful as their documentation.

How to choose your approach

Start from default-deny in both directions and explicitly permit what belongs: a strict outbound list of your own and customers' prefixes, and inbound acceptance gated by bogon filters, max-prefix limits, and RPKI. Layer communities on top to make policy consistent rather than per-prefix, and document the scheme as carefully as you build it. Reserve local-pref and prepending for genuine traffic-engineering needs, applied sparingly and observed for their actual effect. The networks that operate BGP cleanly are the ones that are deliberate about every accept, announce, and steer — and the wider internet community quickly learns which networks those are.

The takeaway

Filtering keeps you and everyone else safe; communities and steering let you express intent precisely. Filter strictly so mistakes cannot escape, tag routes so policy stays consistent and readable, validate origins with RPKI, and steer with local-pref and prepending only where it earns its keep. These controls sit on top of solid BGP fundamentals and a clean interior routing foundation, and they are what turn a working BGP deployment into a trustworthy one. For ISP operators managing the customers, prefixes, and provisioning behind that routing, ISP Digital is built to keep the operational side organised as your network grows.