BGP Communities Explained for Regional ISPs and IX Networks
BGP communities let you influence inbound traffic without constantly manipulating AS path length. Instead of making routes look artificially longer, you attach metadata to a prefix and let the upstream provider apply policy changes based on that tag. Regional ISPs use this heavily when balancing traffic between Internet exchanges like FD-IX and upstream transit providers.
A BGP community is just a 32-bit value attached to a route:
The number itself means nothing until a provider maps it to a policy action. One provider may treat 65000:80 as “lower local preference.” Another may use the same value to stop advertising the route to peers. This is why every upstream publishes a community guide. Without the provider policy attached to it, a community is just a tag riding along with the prefix.
AS path prepending depends on remote networks making path decisions the way you hope they will. Communities change provider policy directly. That makes traffic movement more predictable, especially when multiple upstreams already have direct relationships with each other.
Regional ISPs can connect to an IX alongside two transit providers. Local traffic stays on the exchange while Internet-bound traffic leaves through transit. This reduces paid transit usage and prevents unnecessary upstream backbone crossings by nearby traffic.
Consider this layout:
- Transit A is primary.
- Transit B is a backup
- FD-IX carries regional peer traffic
If Transit B supports a “lower local preference” community, you can tag outbound advertisements toward that provider. That community tells Transit B to lower the preference on the route before sending it upstream. Inbound traffic then favors Transit A even though both providers still receive the same prefix announcement. The route itself did not change. Only the provider policy attached to it has changed.
This becomes more useful once IX traffic is introduced. ISPs want local eyeball traffic to stay within the exchange fabric, while long-haul traffic exits via transit.
Example:
- No policy changes on IX routes
- Normal preference on Transit A
- Lower preference on Transit B
The result is usually stable traffic flow:
- IX peers exchange local traffic directly
- Transit A handles most upstream return traffic
- Transit B remains mostly idle until failure conditions occur
Traffic patterns become more consistent because backup transit links stop pulling inbound traffic during normal operation. Transit usage also becomes easier to forecast since most return traffic stays on the preferred upstream instead of shifting between providers.
Geographic Controls
Some providers extend communities further with geographic controls. A route can be advertised only in certain regions or suppressed in others. This is common with large national or international carriers trying to reduce unnecessary route propagation.
This changes where the route enters the provider’s backbone. Traffic from another country may take different upstream paths entirely instead of crossing an ocean only to return toward a Midwest regional ISP. The packets usually show up as lower latency and cleaner traffic engineering during congestion periods.
I have seen many providers prioritize local preference before AS path length, so the longer path may still win. Some networks also keep the prepended route because the exit point might be geographically closer. Communities work better here because the provider can change policy directly rather than relying on remote AS path decisions. Once a packet leaves your network, you have very little control over it. Heavy prepending does not always shift traffic the way you want it to.
Pitfalls and troubleshooting
Confirm the correct community tags are attached to the correct prefixes. After that, validate propagation using looking glass servers. If inbound traffic does not shift, the provider may ignore the community entirely or override it. Keep in mind, your upstream providers are trying to engineer traffic themselves. Sometimes this is for the same reasons you are, just from their viewpoint.
Route servers at IXPs add another wrinkle. Some support large community sets for controlling advertisement behavior. Others strip communities or support only a limited subset. Engineers often assume that route server behavior matches transit provider behavior and later discover that communities were discarded before propagation. Consult your IXP for a route server guide. FD-IX publishes one.
Conflicting communities also create problems. One tag may lower preference, while another may suppress peer advertisement completely. Instead of shifting traffic, the route can vanish from portions of the Internet. This usually shows up as partial reachability, where some ASNs still see the route while others lose it entirely. As I have said many times, philosophy plays a role in network engineering. The safest deployment pattern is to ease in communities one at a time. Apply one policy change then watch the traffic.
That process matters more in smaller regional networks because traffic shifts become visible immediately. A single incorrect community can unexpectedly move gigabits of traffic and push it the wrong way right away.
https://j2sw.com
https://startawisp.info
https://indycolo.net
#packetsdownrange #routethelight