What Is BGP Communities in Networking?

Imagine you work in a huge office building with many floors. Every day, the mail room receives hundreds of packages addressed to different people. Without any system, each package would need individual instructions.

BGP communities are like colour-coded stickers the mail room puts on packages. A red sticker might mean "this package must be delivered before noon." A blue sticker might mean "this package is for temporary visitors and must be returned after one week." The mail room does not need to write these instructions on every package by hand; they just glance at the sticker and follow the rule for that colour.

Border Gateway Protocol (BGP) is the routing protocol that connects different networks across the internet. Networks exchange routes (paths to destinations) with each other. Without communities, network administrators would have to write individual configuration rules for thousands of routes to control how they are shared. That is like writing a different delivery note for every single package.

Communities let administrators tag routes with numeric codes (the stickers). Those codes tell other routers, "do this with this route" or "don't do that with this route." For example, a router in New York can send a route to a router in London with a community tag meaning "do not advertise this route to customers in Europe." The London router reads the tag and follows the rule automatically.

This system is powerful because it lets different organizations control traffic behaviour across multiple networks using simple tags, rather than complex per-neighbor policies. It is the internet's way of saying, "we have a common language for special handling instructions."

BGP communities are transitive optional path attributes defined in RFC 1997. They are 32-bit numeric values, traditionally represented as two 16-bit parts separated by a colon (for example, 100:300). The first part is usually the autonomous system (AS) number that defines the community, and the second part carries a specific meaning defined by that AS.

Communities are carried inside BGP update messages as attribute type code 8. When a router receives a route with a community attribute, it can match the community value in a route map or a prefix list and apply policies such as setting local preference, manipulating the AS path, or controlling route advertisement.

There are several well-known communities defined in RFC 1997 and later RFCs. NO_EXPORT (0xFFFFFF01) tells a router not to advertise the route outside the local AS confederation boundary. NO_ADVERTISE (0xFFFFFF02) tells a router not to advertise this route to any BGP peer at all. LOCAL_AS (0xFFFFFF03) prevents a route from being advertised to external peers outside the local AS. NO_PEER (0xFFFFFF04) prevents advertisement to peers that are not in the same AS.

Modern network implementations support extended communities (8 bytes, defined in RFC 4360) and large communities (12 bytes, defined in RFC 8092). Extended communities are used in MPLS VPN and VXLAN environments to carry additional information such as route targets. Large communities use a 4-byte AS number and are backward compatible.

In Cisco IOS and IOS-XE, communities can be configured using the "ip community-list" command to define a list of communities to match. Route maps then reference these community lists to apply policies. The "set community" command allows injection or modification of communities on outbound or inbound updates. Network operators commonly assign community values to control route preference, influence traffic engineering, or implement blackhole routes for DDoS mitigation.

Private communities are also widely used. For example, a service provider may define community 65535:100 to mean "prefer this route as a primary path" and 65535:200 to mean "treat this route as a backup path." These communities are only meaningful within the provider's network, but they allow customers to influence routing behaviour by tagging routes before sending them to the provider.

BGP communities are critical in real networks because they provide a scalable way to implement routing policies across thousands of routes. In a service provider environment, a single router may receive millions of routes from hundreds of peers. Applying individual policy to each route is impossible. Communities allow the provider to offer their customers simple tags that the customer can attach to their routes, and the provider's infrastructure automatically applies the correct treatment.

For example, a customer who wants to influence how traffic enters their network can tag their routes with a community like 12345:10 to request a higher local preference from the provider. The provider configures a single route map that matches community 12345:10 and sets local preference to 200. This works for every customer and every route that carries that tag, without adding per-customer configuration.

Communities are also essential for traffic engineering, DDoS mitigation, and multihoming. A network operator can define a community that causes matching routes to be advertised with a next hop of a null interface, effectively blackholing traffic toward a victim IP during an attack. This can be triggered in seconds by just tagging the route, without reconfiguring large router ACLs.

In enterprise networks with MPLS VPNs, extended communities carry route target values that control which VRFs import and export routes. Without communities, implementing Layer 3 VPNs would require complex and fragile redistribution filters. Communities make the whole system modular and transparent.

Finally, communities allow different organizations to cooperate without sharing full configurations. Two ISPs can agree on a set of community values that each will honour, enabling inter-AS traffic engineering without exposing internal policies. This fosters a collaborative internet ecosystem.

You will see BGP community questions in multiple forms on the CCNP and CCIE exams.

Scenario-based questions often describe a company that is dual-homed to two ISPs. The company wants traffic from a specific ISP to prefer a specific prefix for incoming traffic. The question provides a configuration snippet and asks what community value should be sent to that ISP. You must identify the correct community from the ISP's documented policy.

Configuration-based questions might give a partial route map and ask you to complete it. For example, "Given the route map RM_SET_COMMUNITY, configure it to set the community to NO_ADVERTISE for all routes from prefix 192.168.0.0/24." You would need to write or select the correct sequence: "set community no-advertise" and ensure the route map is applied to the right neighbor.

Troubleshooting questions are very common. A network administrator configures communities on a router, but the neighbor still does not see the community values. The question asks you to identify the missing configuration. The answer is likely the absence of "neighbor x.x.x.x send-community" or the use of "send-community standard" when extended communities are needed.

Multiprotocol BGP questions may involve extended communities in MPLS VPN contexts. You might be asked about route target communities and how they control VRF import and export. For example, "Given RT 100:200 configured on two VRFs, which routes will end up in which VRF?"

Comparison questions ask you to differentiate between standard, extended, and large communities. They may test your knowledge of the format (16-bit vs 32-bit vs 4-byte ASN) and the RFC numbers.

Finally, you might see questions about private communities and well-known communities. Be ready to recall that NO_EXPORT prevents a route from being advertised outside the confederation, while NO_ADVERTISE prevents it from being advertised to any BGP peer at all. These definitions are frequently tested.

BGP communities are one of the most powerful tools for routing policy control because they separate the definition of policy from its application. As a network engineer, you define once how certain community values are treated, and then anyone in the network can simply tag routes with that value to invoke the policy.

To configure communities in Cisco IOS, you start by defining a community list. For example, "ip community-list standard CUST_RED permit 65000:100" creates a list that matches community 65000:100. You can also use expanded lists for regex matching. Then, you create a route map that uses this community list as a match criterion. For instance, "route-map SET_PREF permit 10 match community CUST_RED set local-preference 200". This route map checks if a route has the community 65000:100, and if so, sets its local preference to 200.

To apply this on inbound traffic, you reference the route map under the BGP neighbor: "neighbor 10.0.0.1 route-map SET_PREF in". To apply it outbound, you change "in" to "out".

What can go wrong? The most common issue is forgetting to send communities. If you set a community on a route but the "send-community" command is missing, the router silently drops the attribute. Always verify with "show ip bgp neighbors x.x.x.x" to see if community exchange is enabled.

Another practical concern is community propagation through iBGP. By default, iBGP peers preserve community attributes, but if a route goes through a route reflector, the community is kept unless explicitly stripped. This means a community that was added at an edge router may propagate through the entire internal network, which may or may not be intended. You can use route maps to strip communities on specific sessions if needed.

In production, you often use communities in conjunction with prefix lists. For example, you might have a policy that only allows routes with a certain community to be accepted from a customer, thus enforcing routing contract terms. This is a common security and traffic engineering technique.

Large communities, defined in RFC 8092, solve the problem of AS number exhaustion in standard 32-bit communities. They use a format like "ASN:sub1:sub2", allowing for a 4-byte ASN. If your network uses 4-byte AS numbers, you must use large communities or extended communities to avoid overlap. Cisco IOS XR and modern IOS XE support large communities natively.

Finally, remember that communities are optional. Not every network uses them, and not every BGP speaker honours foreign communities. On the internet, only communities that are part of bilateral or multilateral peering agreements have meaning. Always document which communities your organisation supports and communicate them to your peers.