What is a BGP Community?

A BGP community is a path attribute that tags one or more routes with a shared property, so routing policy can match, filter, or modify that whole group together instead of one prefix at a time. Well-known values such as no-export and no-advertise control how far a tagged route is allowed to propagate.

Key takeaways

• A BGP community groups routes by a shared property for policy matching.
• Standard communities use an AS:value or plain decimal number format.
• Well-known communities like no-export and no-advertise control propagation.
• Extended and large communities carry more bits for finer-grained tagging.
• Versa VOS devices match and set communities in eBGP and redistribution policy.

On this page: Why it matters · How it works · Types · BGP Communities & Versa · FAQ

Why are BGP communities important?

Without communities, a routing policy has to enumerate every prefix it wants to treat differently – a list that drifts out of date as a network changes. Communities let an operator tag routes once, where they enter the network, and write policy against the tag everywhere else: at every peering router, redistribution point, or route reflector. Every downstream policy matching that community treats the route the same way, without needing the specific prefix.

This is what makes communities central to large-scale BGP traffic engineering. Enterprises mark routes as internal-only, region-specific, or bound for a particular VRF; providers signal blackholing or selective advertisement to peers. Because a community is a standard BGP attribute, it travels unmodified between vendors – the common language independently managed networks use to negotiate route behavior.

What is a BGP community?

A BGP community is an optional transitive path attribute – RFC 1997 defines it as a 32-bit value, usually written as two 16-bit halves separated by a colon (AS:value, for example 65000:100) – attached to a route in a BGP update message. The attribute is a list, so a single route can carry several community values at once.

Two extended formats exist beyond the original standard community. Extended communities, from RFC 4360, use 64 bits split into a type field and a value field, encoding richer information such as MPLS VPN route targets. Large communities, from RFC 8092, use three 4-byte fields to support 4-byte AS numbers cleanly. A handful of well-known communities are reserved by the standard itself – no-export keeps a route inside the local AS, and no-advertise stops it reaching any BGP peer at all.

Types of BGP communities

BGP communities fall into three format families plus a reserved set of well-known values.

Standard communities are the original 32-bit attribute, written as a 2-byte AS number and a 2-byte value (65000:100) or a single decimal number – the most widely supported format across vendors.

Extended communities double the width to 64 bits, split into a type/subtype and a value field. They carry structured data, most commonly MPLS Layer 3 VPN route targets, and use different formats for matching versus setting.

Large communities use three separate 4-byte fields instead of one split into two 2-byte halves, so a 4-byte AS number can be expressed without borrowing bits from the value.

Well-known communities are reserved values with standardized meaning regardless of vendor: no-export, no-advertise, and no-export-subconfed control how far a route propagates, independent of any other policy.

BGP Communities & Versa

Versa VOS devices match and set BGP communities directly in eBGP routing policy. When you configure eBGP, each outbound or inbound rule can match on a Community field using a 2-byte or 4-byte decimal number, a 2-byte:2-byte pair, or a regular expression, alongside prefix criteria. On an Allow rule, the same policy can set a community value and prepend the local AS number to the AS path.

In Concerto, redistribution policies extend the same model to routes moving between protocols – BGP, OSPF, static, and SD-WAN. A term can match on a community or extended community string, and its action can set a community, an extended community, or a well-known community on the redistributed route – tagging routes as they cross from OSPF into BGP so downstream policy can act on the tag instead of re-matching prefixes.

Frequently asked questions

What is the difference between a standard and an extended BGP community?

A standard community is a 32-bit value, typically written as AS:value. An extended community doubles that to 64 bits, split into a type and value field, letting it encode data such as MPLS VPN route targets. The two use different formats for matching and setting.

What does the no-export community do?

no-export tells every BGP speaker that receives the route not to advertise it outside the local autonomous system or confederation. It is a well-known community defined by the BGP standard itself, so any compliant router honors it without extra configuration.

What is the difference between BGP communities and large communities?

Large communities, defined in RFC 8092, use three separate 4-byte fields instead of a single 4-byte value split into two halves. That extra space lets networks running 4-byte AS numbers express communities cleanly, without the encoding workarounds standard communities otherwise need.

Can a route carry more than one BGP community?

Yes. The community attribute is a list, so a route can carry several values at once – for example, a region tag and a no-export flag together. Routing policy can then match on any one value or on a combination of them.

How do BGP communities differ from an AS path?

An AS path records every autonomous system a route has traversed, in order, mainly for loop prevention. A community is an attribute an operator sets deliberately to tag a route for policy – it carries no history and is not populated automatically.

More on BGP Communities

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about BGP communities, these are worth looking at next.