Routing & SwitchingNetworking SecurityAdvanced

BGP communities and route filtering: prefix lists, AS path regex, route maps and avoiding transit

By Mohamed Fayas 10 min readUpdated 15 October 2026

In short: Communities are tags attached to BGP routes that trigger policy elsewhere, such as "do not export" or "set local preference low". Filtering decides which routes you accept and send, using prefix lists, AS path regular expressions and route maps. Every multihomed enterprise must filter outbound routes so it never becomes a transit path between its providers.

Communities: tags that carry policy

A community is an optional transitive attribute: a 32-bit tag usually written as ASN:value, such as 64500:120. Routers do nothing with a community by itself; it is a label that route maps elsewhere match and act on. Providers publish lists of communities that customers can set, for example "64510:80 means set local preference 80 inside our network" or "64510:666 means blackhole this prefix", which lets you influence another network's policy.

Four well-known communities have fixed meanings:

NO_EXPORT: do not advertise to eBGP peers (confederation member ASes still receive it).
NO_ADVERTISE: do not advertise to any peer at all.
LOCAL_AS (NO_EXPORT_SUBCONFED): do not advertise outside the local member AS of a confederation.
BLACKHOLE (65535:666, RFC 7999): ask the neighbour to drop traffic to the prefix, used during DDoS attacks.

Cisco IOS does not send communities by default; add neighbor x send-community (or both to include extended communities), and ip bgp-community new-format to display them as ASN:value. With 4-byte ASNs, large communities (RFC 8092) use three 32-bit numbers, such as 4200000001:1:120.

Filtering with prefix lists

Figure 1. Prefix lists, AS path lists and community lists match routes; route maps combine them and change attributes. A maximum-prefix limit protects against a neighbour that suddenly sends far too many routes.

Prefix lists match a prefix and, optionally, a range of lengths with ge (greater or equal) and le (less or equal). They are the preferred tool for prefix filtering. Older configurations sometimes used extended ACLs, where the "source" field matched the network and the "destination" field the mask; this works but is hard to read.

ip prefix-list OUR-PREFIXES seq 5 permit 203.0.113.0/24
ip prefix-list NO-SMALL seq 5 permit 0.0.0.0/0 le 24
ipv6 prefix-list OUR-V6 seq 5 permit 2001:db8:4400::/48
!
router bgp 64500
 neighbor 198.51.100.1 prefix-list OUR-PREFIXES out
 neighbor 198.51.100.1 prefix-list NO-SMALL in
 neighbor 198.51.100.1 maximum-prefix 1100000 90
 address-family ipv6 unicast
  neighbor 2001:db8:ffff::1 prefix-list OUR-V6 out

IPv6 filtering works the same way under the IPv6 address family with ipv6 prefix-list.

AS path filters and regular expressions

AS path access lists match the AS_PATH string with regular expressions. A few patterns cover most needs:

Pattern	Matches
`^$`	An empty path: routes originated in your own AS
`^64510$`	Routes originated by neighbour 64510 itself
`^64510_`	Routes learned via 64510
`_64520$`	Routes originated by AS 64520, wherever they came from
`_64530_`	Routes passing through AS 64530 anywhere
`.*`	Everything

The underscore matches a space, the start or the end, so _64530_ does not accidentally match 645301.

Route maps and the transit AS problem

A multihomed enterprise learns the internet from provider A and from provider B. Without outbound filters, it advertises A's routes to B and B's routes to A, offering itself as a path between them. At best this wastes its links; at worst it causes an outage for other networks, a classic route leak. The fix is to advertise only your own prefixes:

ip as-path access-list 10 permit ^$
route-map TO-PROVIDERS permit 10
 match as-path 10
 match ip address prefix-list OUR-PREFIXES
router bgp 64500
 neighbor 198.51.100.1 route-map TO-PROVIDERS out
 neighbor 192.0.2.1 route-map TO-PROVIDERS out

Within one route map clause, different match types must all be true; anything not permitted by a clause is denied at the end. Another approach is to tag routes learned from each provider with NO_EXPORT on arrival.

Real-world example: a media company added a second internet provider and configured BGP quickly to meet a deadline, with no outbound filters. Within an hour its links were saturated: one provider had started sending part of its traffic for other networks through the company. Its own users were complaining of slow access. The engineers added an outbound route map permitting only the company's own prefixes with an empty AS path, plus a maximum-prefix limit inbound, and the stray traffic stopped as soon as the routes were withdrawn.

Practice

What does the NO_EXPORT community do?

It tells the receiving router not to advertise the route to any eBGP peer, keeping it inside the AS (or confederation).

Which AS path regex matches routes originated in your own AS?

^$ (an empty AS path).

Why must a multihomed enterprise filter its outbound BGP announcements?

Otherwise it re-advertises one provider's routes to the other and becomes a transit AS, carrying traffic for other networks.

Key takeaways

Communities are tags; route maps elsewhere act on them.
Well-known communities: NO_EXPORT, NO_ADVERTISE, LOCAL_AS and BLACKHOLE.
Cisco needs send-community before communities are passed to a neighbour.
Use prefix lists for prefixes and AS path regex for paths; combine them in route maps.
Announce only your own prefixes to providers so you never become a transit AS.

Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author