Most multi-homed ISPs get their BGP sessions up, confirm routes are being received and advertised correctly, and stop there. The sessions work, traffic flows, and BGP communities never enter the picture because nothing forced the question. The problem shows up later: an upstream gets congested, a peering relationship needs different treatment than a transit relationship, or a single link failure sends traffic down a path three times more expensive than it needs to be, and there's no mechanism in place to control any of it beyond renegotiating with the upstream directly.
BGP communities are how you get that control back. This is a practical walkthrough of what they actually do, how to design a tagging scheme that holds up as your peering relationships grow, and where it tends to go wrong.
What BGP Communities Actually Do
A BGP community is a 32-bit tag attached to a route advertisement, readable by any router along the path that's configured to look for it. On their own, communities don't do anything, they're just metadata. The behavior comes from the routing policy your routers, and your peers' routers, apply based on that tag. This is what makes them powerful: you can signal intent about how a route should be treated without needing a separate session or a manual policy change every time conditions shift.
The distinction that trips people up early is between communities you set for your own internal use, read only by your own routers, and communities your upstreams or peers publish for you to use, which influence how they treat your advertisements. Both matter, and conflating them is a common source of traffic engineering that doesn't behave as expected.
Well-Known Communities vs Custom Communities
A handful of communities are standardized and universally recognized: NO_EXPORT keeps a route from being advertised outside the local AS or confederation, NO_ADVERTISE prevents advertisement to any peer at all, and NO_EXPORT_SUBCONFED is a more specific variant of NO_EXPORT. These are useful for internal signaling but don't help with the upstream-facing control most ISPs actually need.
That control comes from custom communities, typically formatted as ASN:value, where the ASN identifies who defined the community and the value encodes the action. Most upstream providers publish their own community scheme in their peering documentation: communities to set local preference, communities to prepend their AS a specific number of times before advertising further, communities to control advertisement scope by region. Before designing anything, pull the actual community documentation from each of your upstreams, because their schemes are not interchangeable, and assuming one provider's convention applies to another is a fast way to misconfigure traffic engineering without any error being thrown.
Common Use Cases: Local Preference, MED, and Selective Advertisement
Three mechanisms cover most practical traffic engineering needs for a multi-homed ISP:
Local preference controls outbound path selection within your own AS. If you're multi-homed to two upstreams and want one preferred for cost or performance reasons, setting local preference on routes received from that upstream, higher value wins, makes every router in your AS prefer that path for matching destinations, without touching individual route advertisements one at a time.
MED, the multi-exit discriminator, signals to an adjacent AS which of multiple entry points into your network it should prefer, when you have more than one connection to the same neighbor. Unlike local preference, MED only influences the neighboring AS's decision, and only when that AS is configured to honor it, which not all are by default.
Selective advertisement, often via community-triggered prepending or by simply not advertising certain prefixes to certain peers, controls inbound traffic engineering: which paths the rest of the internet uses to reach you. This is the lever most ISPs underuse, because it requires thinking about your advertisements as a control surface rather than just a fact you publish.
A Practical Tagging Scheme for Multi-Homed ISPs
For an ISP with two or three upstreams and a handful of peering sessions, a workable internal tagging scheme typically separates communities into three functional categories: route source tags, identifying which upstream or peer a route arrived from, so policy downstream can act on origin without re-deriving it from the AS path every time; treatment tags, marking routes for specific handling such as do-not-export-to-peers or prefer-this-path; and customer or service tags if you're also originating routes on behalf of downstream customers, which lets you apply consistent policy to customer-originated routes without manually tracking which prefixes belong to which customer at every router.
Keep the scheme as flat as you can justify. The most common failure mode in BGP traffic engineering isn't choosing the wrong mechanism, it's building a tagging scheme so elaborate that nobody besides the person who designed it can safely modify it six months later. If a community's purpose isn't obvious from a comment next to its definition, the scheme is already more complex than your team can maintain.
Implementing Community Tags on MikroTik RouterOS
On RouterOS, communities are set and matched within routing filter chains, using set bgp-communities to attach a tag to a route and bgp-communities as a match condition in filter rules to act on tags already present. A typical pattern looks like tagging routes as they're received from a given peer, inside that peer's input filter chain, then referencing that tag later in output filter chains toward other peers to decide what gets advertised where.
The practical gotcha specific to RouterOS deployments: community attributes need to be explicitly preserved through filter chains, since a poorly written filter can silently strip communities a downstream rule depends on, with no error logged anywhere. If traffic engineering you've configured doesn't seem to be taking effect, checking whether the expected community survived the full filter chain, not just whether it was set initially, is usually where the answer is.
Common Mistakes That Break Traffic Engineering
The most frequent failure isn't a misunderstanding of BGP itself, it's assuming a community tag is doing something it isn't, because the peer on the other end isn't configured to honor it. A community only works if the AS reading it has policy written to act on it. Sending an upstream's prepend-3x community correctly means nothing if you've misread their documentation and they're matching on a different value than the one you're setting.
The second most common issue is local preference and MED getting applied inconsistently across redundant routers, so different paths through your own network make different decisions for the same destination, creating asymmetric routing that's difficult to diagnose because each individual router's behavior looks correct in isolation. Consistency across your edge routers matters as much as the policy itself.
The third is treating traffic engineering as a one-time setup rather than something that needs revisiting as peering relationships change. A community scheme built for two upstreams doesn't necessarily extend cleanly to four, and tagging conventions that made sense at a smaller scale can become a liability once enough exceptions accumulate that nobody remembers why a particular rule exists.
Where PeerIQ Fits In
Designing a tagging scheme is one problem. Knowing whether your current peering and transit mix is actually cost-effective, and whether your routing security posture, RPKI, MANRS alignment, anti-spoofing, holds up, is a separate and ongoing one. That's the gap PeerIQ is built for: route path analysis, traffic-weighted upstream utilization, IX opportunity scoring, and routing security posture, specifically for the Pakistani peering landscape including PKIX.
If you're working through a multi-homing design or a BGP architecture decision from scratch, that's the kind of work we do directly under Network Design & Optimization, and for broader infrastructure strategy questions, ISP Consulting & Advisory covers the architecture-level decisions this article assumes you've already made.