Short answer: A BGP community is a 32-bit tag attached to a route so routers and networks can apply policy consistently. Communities do not change forwarding by themselves: a route policy must match the tag and take an action such as setting local preference, controlling advertisement, or requesting a provider service.[1][2]
What a standard BGP community is
RFC 1997 defines the BGP Communities attribute as an optional transitive path attribute. A standard community is 32 bits, commonly displayed as two 16-bit decimal values, such as 65000:100. The first field is often an ASN and the second a locally chosen meaning, but this convention is not enforced by BGP. A community is metadata; consistent policy gives it operational meaning.[1]
Well-known communities
Common well-known values include no-export, which signals that a route should not be advertised outside the BGP confederation boundary, and no-advertise, which signals that it should not be advertised to any BGP peer. internet indicates that the route may be advertised to the Internet. Check the current registry and platform behavior before relying on a value.[1][4]
How communities influence traffic
- Outbound from your AS: A received community can trigger local policy to set LOCAL_PREF, choose an exit, or reject the route. The community itself does not select the path.
- Inbound toward your AS: You can attach a provider-documented community requesting lower preference at a peer, selective prepending, or blackholing. It works only if the provider supports it.
- Limits: Communities cannot force another network to honor a request, guarantee symmetric paths, or override stronger policy.
Configuration example
Cisco IOS-style illustration; adapt policy direction to your release:
ip prefix-list CUSTOMER seq 10 permit 198.51.100.0/24
route-map FROM-CUSTOMER permit 10
match ip address prefix-list CUSTOMER
set community 65000:100 additive
set local-preference 200
!
router bgp 65000
neighbor 192.0.2.2 route-map FROM-CUSTOMER in
additive preserves existing communities while adding the new tag. This example tags and prefers the route locally. It does not signal an external provider unless the tag is advertised and recognized.[3]
Verification commands
show ip bgp 198.51.100.0
show ip bgp community 65000:100
show ip bgp neighbors 192.0.2.2 received-routes
show ip bgp neighbors 192.0.2.2 advertised-routes
Check the prefix, community, policy direction, and actual advertisements. Command availability depends on platform and inbound soft reconfiguration.
Troubleshooting checklist
- Is the community attached to the exact prefix and address family?
- Does policy match in the correct direction?
- Did a later policy overwrite communities? Is
additiverequired? - Is the community sent to the peer (for example, is send-community enabled)?
- Does the provider recognize the exact value and action?
- For blackholing, is the prefix authorized and narrowly constrained?
Modern use
Providers and enterprises use communities to classify routes and apply policy at scale. At cloud and dual-ISP edges, provider documentation defines any supported request. In EVPN/VXLAN, standard communities can tag routes, while extended communities—especially Route Targets—have distinct VPN/EVPN distribution roles.
Interview answer
A BGP community is a transitive policy tag carried with a route. It has no forwarding effect by itself; route policy maps it to actions. It can classify routes internally or request documented provider handling, but another AS is not obligated to honor it.
Post a Comment