A router will accept whatever its neighbor sends it, and announce whatever it has been told to announce. Filtering is how you decide, in advance, what those two things are allowed to be. It is the part of running BGP that nobody notices until it is missing.

There are two directions, and they fail differently.

What you accept. A full table from an upstream contains a few hundred thousand routes you want and, now and then, one you do not: a more specific prefix for your own address space, a bogon, a default route you never asked for, a prefix with a path so long it should not exist. An inbound filter drops those before they reach your forwarding table. For customers who announce to you, the filter is stricter still: a prefix list built from what they are entitled to originate, a maximum prefix count so a mistake on their side stops at the session, and a check that the origin AS is theirs.

What you announce. This is where the well known accidents happen. A network buys transit from two providers, sets up both sessions, and forgets the export filter on one of them. The routes learned from provider A are passed to provider B. For a few minutes the network is transit for a slice of the Internet it never intended to carry, and the links fill. The one line fix is an export policy that announces your own prefixes and your customers’ prefixes and nothing else.

Where the entitlement comes from. Twenty years ago a filter was built from the routing registry objects a network published, and many providers still build customer filters that way, so keeping your IRR objects accurate is still part of the job. Today there is a second source: route origin authorizations, signed by the address holder, that let any network validate whether an origin AS is allowed to announce a prefix. Most large carriers now drop announcements that fail that check. If your prefixes have no authorization, you are depending on their tolerance. If your authorization is wrong, your routes vanish. We check both, the registry objects and the signed authorizations, and fix what disagrees.

Communities are filtering too. The communities your upstream lets you set are described in their customer guide. The communities you let your customers set, and the ones you strip at the edge so internal tags never leak to a peer, are your own policy. We treat them as part of the filter design, not an afterthought.

A filtering policy is small. The one we write for a typical network fits on a page. What takes the time is deciding what it should say, writing it down so the next engineer understands it, and reviewing it when the network changes. We have been doing that for operators since 2003.

If you run BGP and cannot say from memory what your export filter announces, that is the place to start. Talk with us.