BGP communities for route filtering

Published 2026-08-28 | Updated 2026-09-03

I'd like to share a BGP route filtering design I keep coming back to in my work as a network engineer. It's based on BGP communities, a tool that is widely used by Internet Service Providers, although the way they use them are different from what I will explain below.

The idea is to tag (or label) BGP routes with a community, grouping them together. This then allows you to act on that group of routes, controlling how routes are advertised.

This is the topology we'll be playing with. Our main focus is R1, but we also control R2 and R3. We have two internet circuits via separate ISPs. We shall receive a default route from each via BGP. We want to advertise our DMZ route (11.22.0/24) to both ISPs. BGP will also exchange routes with R2 over the IPVPN private WAN circuit. Lastly there's an IPsec tunnel to R3, over which BGP will exchange internal routes.

We will use a two-step process: label incoming routes with BGP communities, then use the communities to filter outbound routes.

Origin labeling

The first step is labeling each route with its origin. For R1 I have identifies the origins DMZ, INET, IPSEC, IPVPN and LAN. The default routes I receive from my two ISPs are labeled INET. The routes I receive from R2 will be labeled IPVPN. R1's local 10.1/16 prefix is labeled as LAN when redistributed into BGP. Routes from R3 are labeled with IPSEC.

These labels are applied using BGP communities. They are two-field numbers that are attached to BGP routes. The first number usually represent the local AS, giving the community a local scope. The second number is the community itself. The value doesn't matter, it's up to you to give each number a meaning.

In this example I will use the following BGP communities:

65000:0 DMZ
65000:1 INET
65000:2 IPSEC
65000:3 IPVPN
65000:4 LAN

I will use inbound route-maps on each BGP neighbor to apply a community to routes received from that neighbor. This is what such a configuration might look like on a Cisco IOS device:

ip bgp-community new-format!route-map RM_BGP_INET_IN permit 10 set community 65000:1route-map RM_BGP_IPSEC_IN permit 10 set community 65000:2route-map RM_BGP_IPVPN_IN permit 10 set community 65000:3route-map RM_BGP_SETCOM_DMZ permit 10 set community 65000:0route-map RM_BGP_SETCOM_LAN permit 10 set community 65000:4!router bgp 65000 network 10.1.0.0 mask 255.255.0.0 route-map RM_BGP_SETCOM_LAN network 11.22.0.0 mask 255.255.255.0 route-map RM_BGP_SETCOM_DMZ ! neighbor 12.99.0.1 local-as 1122 no-prepend replace-as neighbor 12.99.0.1 remote-as 1299 neighbor 12.99.0.1 route-map RM_BGP_INET_IN in ! neighbor 17.4.0.1 local-as 1122 no-prepend replace-as neighbor 17.4.0.1 remote-as 174 neighbor 17.4.0.1 route-map RM_BGP_INET_IN in ! neighbor 172.31.0.1 remote-as 65000 neighbor 172.31.0.1 route-map RM_BGP_IPVPN_IN in ! neighbor 172.31.0.5 remote-as 65000 neighbor 172.31.0.5 route-map RM_BGP_IPSEC_IN in

Syntax is Cisco IOS but this works on any Network OS supporting BGP communities

Filtering

Now that all routes that enter the BGP RIB are labeled with a community, we can start filtering. We achieve this with an outbound route-map on each BGP neighbor. For example, we don't want routes learned from ISP1 to be forwarded to ISP2. The fix is simple; deny routes labeled with the INET community from being advertised to INET neighbors. Even better, we should only advertise DMZ routes to our INET neighbors; all other route origins are for internal use.

Likewise, we technically only need to advertise a default route to R2 as R1 is its connection to the rest of the world. R3 (on the other side of an IPsec tunnel) require some finesse as it should receive LAN and IPVPN routes. Whether to advertise DMZ routes to R3 over the tunnel is debatable, but I'll choose to advertise it in this example.

This is what the outbound route-maps may look like:

ip community-list standard DMZ permit 65000:0ip community-list standard INET permit 65000:1ip community-list standard IPSEC permit 65000:2ip community-list standard IPVPN permit 65000:3ip community-list standard LAN permit 65000:4!route-map RM_BGP_INET_OUT permit 10 match community DMZroute-map RM_BGP_IPVPN_OUT permit 10 match community INETroute-map RM_BGP_IPSEC_OUT permit 10 match community DMZ IPVPN LAN!router bgp 1122 neighbor 12.99.0.1 route-map RM_BGP_INET_OUT out // ISP1 neighbor 17.4.0.1 route-map RM_BGP_INET_OUT out  // ISP2 neighbor 172.31.0.1 route-map RM_BGP_IPVPN_OUT out // R2 neighbor 172.31.0.5 route-map RM_BGP_IPSEC_OUT out // R3

Readability is king

That's it!

That's all we have to do. For example, routes are only advertised to ISP1 and ISP2 if they have the DMZ community applied. Because we don't allow sending INET routes to INET neighbors, we avoid possibly becoming a transit AS. R3 receive only internal and DMZ prefixes as per the design.

The main benefit for me is how readable the outbound route-maps become. It is clear which routes are advertised to whom. It scales well as new routes matching these communities are automatically filtered according to existing rules. It also reduces human error as routes with no community set are not advertised anywhere, minimizing the risk of configuration errors causing routing issues.

Any time I have a moderately complex BGP setup like above I find myself implementing this solution. The hard part is taking the time to identify the different origins. Once you have them defined, implementation is often quick and flow naturally. Although, I may honestly have overdone it in the example above. The LAN, IPVPN and IPSEC communities could all be consolidated into a PRIVATE (or INTERNAL) community. I made it a bit verbose in an attempt to help highlight the concepts.

Taking it further

But wait, there's more! I mentioned earlier that BGP communities are used by most ISPs. BGP communities can be sent along with the route when it's advertised to other BGP neighbors. This is how ISPs label and prioritize routes in their network. We can do that too. If R2 adds the community (65000:4) to a route, then it makes sense for R1 and R3 to trust and use that community in their own route-maps.

Implementing this actually means removing the R2 and R3 inbound route-maps on R1 as they would otherwise overwrite the communities already set by the sender. We then add the following config on R1-R3:

ip bgp-community new-formatip prefix-list LAN seq 5 permit 10.0.0.0/8 le 32!route-map RM_BGP_REDIST_CONNECTED permit 10 match ip address prefix-list LAN set community 65000:4!route-map RM_BGP_REDIST_CONNECTED permit 100 // Permit all other routes, but add no community!router bgp 65000 redistribute connected route-map RM_BGP_REDIST_CONNECTED neighbor 172.31.0.2 remote-as 65000 // R1 neighbor 172.31.0.2 send-community

Connected routes inside the 10/8 IP-range are now labeled with the LAN community

This is what the BGP RIB looks like on R1 when filtering on the LAN community:

R1#sh ip bgp community 65000:4 // LAN community     Network          Next Hop            Metric LocPrf Weight Path *>  10.1.0.0/16      0.0.0.0                  0         32768 i *>i 10.2.0.0/16      172.31.0.1               0    100      0 ? *>i 10.3.0.0/16      172.31.0.5               0    100      0 ? R1#sh ip bgp community 65000:0 // DMZ community     Network          Next Hop            Metric LocPrf Weight Path *>  11.22.0.0/24     0.0.0.0                  0         32768 i

Pretty sweet if you ask me

Going crazy with it

Large-scale ISPs may use communities to signal if a route came from one of their customers or one of their ISP peers. They identify what continent or country originated the route. Routes you advertise to them can be made more or less interesting, increasing or lowering the local-preference for that route inside their network. This makes the route more or less likely to be advertised to other ASes. This is useful if you are doing planned maintenance and want to steer traffic away from the node you're working on. Or you can tell your upstream ISP to AS-prepend routes, but only when the route is advertised from one continent to another.

If you want to learn what ISPs may use BGP communities for, check out these two resources:

If you are a customer to ISPs with features like these, you get access to these tools to influence how traffic enter your network. All you have to do is apply the corresponding community to the routes you advertise to them.

Conclusion

My system is not perfect. I find that it can break if I receive multiple route "origins" from a single neighbor or when the number of origins grow too large. However, the way ISPs use BGP communities is mind blowing to me. I guess it's one way to stand out in the competition.

Thanks for reading this far. I hope this post provided some inspiration for you. Bye for now!