Using communities to filter BGP announcements

(The ^(65065_)*$ regular expression allows our AS number 65065 zero or more times, so we can perform AS path prepending if necessary.) If then our network gains some BGP customers of its own, the prefixes and ASes used by those customers are also added to the filters:

The annoying part about this is that the customer connects to one or maybe two of our routers, but these filters need to be updated on all routers that have eBGP sessions to transit providers and peers. This can easily be a large number of routers.

Fortunately, there’s a better way to accomplish the same result: rather than filter prefixes where they leave the local AS, filter them where they enter the local AS and at that point, attach a BGP community value to those prefixes. Then, the routers that talk to transit providers and peers can have a simple filter that allows prefixes to be advertised if they have the right community attached. First, let’s have a look at prefixes that the router itself originates and tag those with a community. We’ll use 65065:1 for this, with our AS number before the colon to make sure our communities don’t clash with those used by other ASes.

This configuration uses three different ways to originate prefixes: using the network statement and by redistributing connected and static prefixes. This means that if prefix 223.223.220.0/23 is configured on one of the router’s interfaces or is configured as a static route, respectively, it’s injected into BGP and advertised to iBGP and eBGP neighbors, if allowed by applicable filters.

In each case, the route map “originate-comm” is applied. This route map has two clauses. The first is deny 10. A deny clause in a route map means that prefixes that match the match statement are filtered out. In this case that means that all prefixes that match AS path access list 1 are not added to the BGP table. And AS path access list 1 rejects AS paths that contain our AS 65065 zero or more times and allows everything else. So only prefixes with paths that only contain our own AS continue to the permit 20 clause.

The permit 20 clause checks if any prefixes are allowed by the “originate-prefixes” prefix list. If that’s the case, the community 65065:1 is added to the prefix (leaving all existing communities in place as per the additive keyword) and the prefix is entered into the BGP table. If a prefix isn’t allowed by the “originate-prefixes” prefix list, the set action isn’t performed. And since there is no third clause to the route map, the prefix hits the “implicit deny” at the end of the route map and is filtered out. So in effect, only prefixes that are in “orginate-prefixes” are allowed in the BGP table, and those prefixes are tagged with community 65065:1.

Now let’s have a look at prefixes learned from a customer.

Similar to the previous configuration, the route map “cust-a-in” first uses AS path access list 2 to get rid of all prefixes that have AS numbers in the AS path that aren’t the customer’s AS 65067. Then the permit 20 clause of the route map checks for prefixes that are allowed using a prefix list, “cust-a-prefixes” in this case. This prefix list only has a single prefix, a /24. The exact /24 as well as all prefixes within that /24 up to a maximum prefix length of /26 are accepted.

Then the first set statement in “cust-a-in” uses the community list “del-communities” to filter out the communities with special meanings within our AS so the customer can’t trigger unwanted actions. The community list “del-communities” is an extended community list, which means it filters using regular expressions. The regular expression “65065:.*” catches all communities that start with “65065:”.

The next set statement adds the community 65065:2, which we’ll use to tag customer prefixes as we use 65065:1 for prefixes we originate ourselves. At this point, the prefix is added to the BGP table and thus propagated to BGP neighbors as far as filters allow.

This is the configuration that allows prefixes tagged with communities 65065:1 and 65065:2 to be announced to transit providers and peers:

The eBGP session towards the ISP has the route map “comm-out” applied to it. This route map matches all prefixes that are allowed by community list “comm-allowed-out”. This is a standard community list, which means that it works on individual community values, 65065:1 and 65065:2 in this case. As always, the “implicit deny” makes sure that everything that isn’t explicitly listed is filtered out. So the effect is that prefixes tagged with either community 65065:1 or community 65065:2 are advertised to the BGP neighbor, and all other prefixes are filtered out.

Of course this is significantly more complex than just having some network statements in the BGP configuration. So why is it better?

The big advantage of filtering BGP announcements this way is that the last piece of the configuration never changes. No matter how many new prefixes or customers you add to your network, the outgoing filters towards service providers and peers remain the same. I.e., allow all prefixes with communities 65065:1 or 65065:2. That’s it.

Of course when you add new prefixes to your AS, you still need to configure a few routers to originate those prefixes. But that’s only two routers or so that need to be reconfigured to inject those new prefixes in BGP with community 65065:1.

And when you connect a new customer, you need a route map and a prefix list specific to that customer on the router that the customer connects to—but only the router that the customer connects to.

So when your network starts growing beyond a handful of routers, it starts making sense to use communities to filter your BGP announcements.