Using communities to filter BGP announcements

Using communities to filter BGP announcements

    When first starting out with BGP, the typical way to advertise a network’s prefixes is using the network statement with a prefix filter and an AS path filter. Like this:

    !
    router bgp 65065
      network 192.0.2.0
      neighbor 10.0.0.66 remote-as 65066
      neighbor 10.0.0.66 description ISP
      neighbor 10.0.0.66 prefix-list export out
      neighbor 10.0.0.66 filter-list 1 out
    !
    ip as-path access-list 1 permit ^(65065_)*$
    !
    ip prefix-list export permit 192.0.2.0/24
    !

     

    (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:

    !
    ip as-path access-list 1 permit ^(65065_)*$
    ip as-path access-list 1 permit ^(65067_)+$
    !
    ip prefix-list export permit 192.0.2.0/24
    ip prefix-list export permit 198.51.100.0/24
    !

     

    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.

    !
    router bgp 65065
      network 192.0.2.0 route-map originate-comm
      redistribute connected route-map originate-comm
      redistribute static route-map originate-comm
    !
    ip prefix-list originate-prefixes permit 192.0.2.0/24
    ip prefix-list originate-prefixes permit 223.223.222.0/23 le 24
    !
    ip as-path access-list 1 deny ^(65065_)*$
    ip as-path access-list 1 permit .*
    !
    route-map originate-comm deny 10
      match as-path 1
    !
    route-map originate-comm permit 20
      match ip address prefix-list originate-prefixes
      set community 65065:1 additive
    !

     

    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.

    !
    router bgp 65065
      neighbor 192.0.2.67 remote-as 65067
      neighbor 192.0.2.67 description customer A
      neighbor 192.0.2.67 route-map cust-a-in in
    !
    ip prefix-list cust-a-prefixes permit 198.51.100.0/24 le 26
    !
    ip community-list expanded del-communities permit 65065:.*
    !
    ip as-path access-list 2 deny ^(65067_)+$
    ip as-path access-list 2 permit .*
    !
    route-map cust-a-in deny 10
      match as-path 2
    !
    route-map cust-a-in permit 20
      match ip address prefix-list cust-a-prefixes
      set comm-list del-communities delete
      set community 65065:2 additive
    !

     

    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:

    !
    router bgp 65065
      neighbor 10.0.0.66 remote-as 65066
      neighbor 10.0.0.66 description ISP
      neighbor 10.0.0.66 route-map comm-out out
    !
    ip community-list standard comm-allowed-out permit 65065:1
    ip community-list standard comm-allowed-out permit 65065:2
    !
    route-map comm-out permit 10
      match community comm-allowed-out
    !

     

    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.

    Boost BGP Preformance

    Automate BGP Routing optimization with Noction IRP

    NO COMMENTS

    Leave a Reply