BGP Communities: Tag, Match, and Act on Cisco IOS XE

As your BGP policy grows beyond a handful of prefix lists and route maps, you need a way to tag routes with meaning - "this is a customer route," "prefer this path," "don't advertise this outside our region." BGP communities provide exactly this. They're optional transitive attributes (carried across AS boundaries by default) that let you signal intent without having to build complex match conditions on every router.

The trouble with most community write-ups is that they stop at the set community line. You can configure a tag, but you never watch the loop close: where the tag gets attached, how the neighbour displays it, and what "act on it" actually looks like a router or two later. This article closes that loop on captured output. Every block below came from a three-router eBGP chain running Cisco IOS XE 17.18.2 (iol-xe nodes in CML), where R1 tags one prefix with 65001:200 plus no-export, R2 receives it and prints the community, and R3 never sees the prefix at all.

If you want the bigger picture first, the BGP complete guide covers the architecture this article plugs into.

Standard Communities (RFC 1997)

A standard community is a 32-bit value, typically written as two 16-bit numbers separated by a colon: ASN:VALUE. For example, 65001:100 means "defined by AS 65001, value 100." The meaning is entirely up to the operator - communities are just tags with no inherent behavior (except for a few well-known ones).

That last point is the one people trip over. A community you invent does nothing on its own. Tag a prefix 65001:200 and, if nobody writes a route-map that matches 65001:200, it is forwarded exactly as if you had never tagged it. The behaviour lives in whatever policy reads the tag, which may sit on a different router in a different AS owned by a different company.

The exceptions are the well-known communities. Those are baked into every conforming BGP implementation, so they act whether or not anyone wrote policy for them.

Well-Known Communities

On IOS you refer to these by keyword, not by number: set community no-export is what you type, 65535:65281 is what goes on the wire. The keyword is also what appears in show output, which is handy, because a well-known community is the one case where reading the attribute tells you what is about to happen.

Two of them get confused constantly. no-export stops a prefix from leaving the AS: your iBGP peers still learn it, your eBGP peers do not. no-advertise stops the prefix dead at the router that received it, iBGP included. If you want a route to be usable across your own backbone but never leak to a transit provider or peer, no-export is the one you want. That is the case the lab below proves end to end.

The Lab: Three Autonomous Systems, Two Prefixes

The topology is deliberately small so nothing hides. Three IOS XE routers in a straight eBGP chain, one prefix that carries a community and one that does not, so every capture has its own control.

Both prefixes are loopbacks on R1 (Lo100 and Lo200) advertised with network statements. Nothing else differs between them, so any difference downstream is caused by the community.

Tag: Setting the Community on R1

Tagging is three pieces of configuration that have to line up: something that selects the prefix, something that sets the attribute, and something that permits everything you did not select. Here is all of R1's policy.

ip prefix-list PL-TAG seq 5 permit 100.100.200.0/24
!
route-map RM-OUT permit 10
 match ip address prefix-list PL-TAG
 set community 65001:200 no-export
route-map RM-OUT permit 20
!
router bgp 65001
 network 100.100.100.0 mask 255.255.255.0
 network 100.100.200.0 mask 255.255.255.0
 neighbor 10.0.12.2 remote-as 65002
 neighbor 10.0.12.2 send-community
 neighbor 10.0.12.2 route-map RM-OUT out

The prefix-list is the selector, and it matches exactly one /24, which is why only one /24 gets tagged. If you are fuzzy on how ge and le change what a prefix-list catches, read how to filter BGP routes with a prefix-list first: a sloppy one here tags routes you never intended to tag.

Clause 20 is the part that gets left out and then costs an hour. A route-map applied outbound has an implicit deny at the end, so that empty permit 20 clause is what lets 100.100.100.0/24 out of the router at all. Delete it and R2 receives one prefix instead of two, which looks exactly like a broken advertisement rather than a policy mistake. Have how route-map clauses are evaluated in order straight before you deploy one on a live session.

The set line does two things at once: it attaches the private community 65001:200 and the well-known no-export. Note what is missing. There is no additive keyword, so this set replaces whatever the prefix was already carrying. On a locally originated route that is harmless (there was nothing to replace). On a customer route you are passing upstream it is destructive: their tags vanish and the next AS never sees information it may have been relying on. Hence the habit:

route-map TAG-CUSTOMERS permit 10
 match ip address prefix-list CUSTOMER-NETS
 set community 65001:100 additive
!
route-map TAG-CUSTOMERS permit 20

The additive keyword is critical - without it, set community replaces all existing communities. With additive, it appends to the existing community list.

send-community: The Line Everyone Forgets

Communities are not sent to a neighbor by default on IOS. You can configure a perfect route-map, watch it match, confirm the community is attached locally, and the peer will still receive a naked prefix, because the attribute is stripped on the way out unless you ask for it per neighbor:

R1-HQ(config-router)# neighbor 172.16.0.2 send-community
R1-HQ(config-router)# neighbor 2.2.2.2 send-community

Three details make this worse than it sounds. It is per neighbor, so adding a peer means remembering it again. It is per address family, so an IPv4 session that sends communities says nothing about your IPv6 or VPNv4 sessions. And plain send-community covers standard communities only; extended communities need send-community both. Every session in the lab has it configured, which is the only reason any output below shows a community at all.

The failure mode is quiet. Nothing logs, no session bounces, the prefix arrives and installs normally. You just get a route with no tag, and policy on the far side falls through to whatever your default clause does.

Match: Seeing the Community Land on R2

First, the sanity check. R2 has both prefixes from R1, so the eBGP session and the route-map's permit clause are both doing their jobs:

R2# show ip bgp
BGP table version is 3, local router ID is 10.0.23.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
 *>   100.100.100.0/24 10.0.12.1                0             0 65001 i
 *>   100.100.200.0/24 10.0.12.1                0             0 65001 i

Two prefixes, both valid, both best, both learned from 10.0.12.1 with AS-path 65001. From this view they are identical twins, because the summary table does not show communities at all. That is exactly why people assume their tag did not stick and start rewriting the route-map. You have to ask for the per-prefix detail to see it.

R2# show ip bgp 100.100.200.0/24
BGP routing table entry for 100.100.200.0/24, version 2
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Not advertised to any peer
  Refresh Epoch 1
  65001
    10.0.12.1 from 10.0.12.1 (100.100.200.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 4259905736 no-export        <-- the tag arrived intact
      rx pathid: 0, tx pathid: 0x0
      Updated on Jul 20 2026 21:04:14 UTC

Two lines in that block matter more than the rest.

Community: 4259905736 no-export is the tag itself, both halves of it. no-export printed as a keyword because it is well known. The private community printed as a raw decimal, which brings us to the next section.

not advertised to EBGP peer, tucked into the Paths: line, is the smoking gun. That is IOS telling you, on the router that received the route, that it has already decided not to pass this prefix to any external neighbor. You do not have to log into R3 to know what happened. The mechanism names itself right here, one hop before the symptom.

Why the Community Prints as a 10-Digit Number

The device printed 4259905736, not 65001:200. That is not a different community, it is the same 32 bits shown in the old flat decimal format instead of the AA:NN format. The conversion is straightforward: the high 16 bits are the AS number and the low 16 bits are the value, so 65001 * 65536 + 200 = 4259905736. Going the other way, divide by 65536 for the AS and take the remainder for the value.

If you see decimals where you expected AA:NN, the knob is ip bgp-community new-format. It is a display setting only: nothing changes on the wire, matching is unaffected, and a router showing decimals still matches a community-list written as 65001:200. Worth knowing anyway, because a mismatch between two routers' display formats has convinced more than one engineer that a tag changed in transit when it did not.

Filtering the Table by Community

Per-prefix detail is fine when you already know which prefix to look at. When you want the reverse question, which prefixes carry this tag, filter the table by community:

R2# show ip bgp community no-export
BGP table version is 3, local router ID is 10.0.23.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
 *>   100.100.200.0/24 10.0.12.1                0             0 65001 i

One prefix, not two. 100.100.100.0/24 is absent because it carries no community at all. That is the cleanest proof the tag is attached to one prefix and only one, because the router is doing the matching, not you. Swap the keyword for a value (show ip bgp community 65001:200) to filter on a private community, and add exact-match when you want prefixes carrying that community and nothing else.

Act: What no-export Actually Stopped

R2 announced its intention. R3 shows the result:

R3# show ip bgp
BGP table version is 2, local router ID is 10.0.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
 *>   100.100.100.0/24 10.0.23.1                              0 65002 65001 i

One prefix where R2 had two. The control route made it and the tagged route did not. The per-path detail confirms the control really did transit R2 rather than arriving by some other route:

R3# show ip bgp 100.100.100.0/24
BGP routing table entry for 100.100.100.0/24, version 2
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65002 65001                               <-- transited R2, no community attached
    10.0.23.1 from 10.0.23.1 (10.0.23.1)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Jul 20 2026 21:04:14 UTC

AS-path 65002 65001 reads right to left: originated in 65001, passed through 65002, landed in 65003. No Community: line, because R1 only tagged the other prefix. And the tagged one:

R3# show ip bgp 100.100.200.0/24
% Network not in table

That is the whole story in four words. It was never withdrawn, never filtered by R3, never rejected for a bad next hop; it simply never arrived, because R2 declined to advertise it across an eBGP boundary.

Notice what R2 did. It honoured a community it did not define, attached by a router in a different AS, with no matching policy configured on R2 at all. That is the difference between well-known communities and your own: no-export works because every BGP implementation agrees on what it means, while 65001:200 rode along and did nothing, because nobody in AS 65002 wrote policy for it.

Be precise about two boundaries. no-export stops eBGP propagation, not iBGP: if AS 65002 had ten routers, all ten would have learned 100.100.200.0/24 and used it happily. Only the exit to another AS is blocked. And the block happens at the AS that received the tagged route, which is why the evidence lives on R2 rather than R1.

Matching on Communities

Well-known communities act by themselves. Your own communities need a community-list plus a route-map, and that is where the "act" half of the cycle becomes your own to design. Create a community list, then reference it in a route-map:

ip community-list standard CUSTOMERS permit 65001:100
!
route-map PREFER-CUSTOMERS permit 10
 match community CUSTOMERS
 set local-preference 200
route-map PREFER-CUSTOMERS permit 20

Applied inbound, that turns a tag into a path preference: anything a customer marked 65001:100 now wins over the same prefix learned anywhere else. Local preference is the second tiebreaker BGP consults, which makes it the usual first stop when you want to raise local preference on a path you want to win. If the result surprises you, knowing which BGP path wins and why saves the guessing. Communities are how you drive that decision at scale instead of one neighbor statement at a time.

Community lists can be standard (exact match on specific values) or expanded (regex-based matching):

! Standard: match exact community value
ip community-list standard CUSTOMERS permit 65001:100

! Expanded: match using regex - any community from AS 65001
ip community-list expanded ANY-65001 permit 65001:[0-9]+

A standard list with several permit lines behaves as OR: a route matches if it carries any one of the values. Put multiple values on one line and it becomes AND. Add exact-match to match community and the route must carry those communities and no others, which is stricter than most people expect and a common reason a match "does not work" on a route that visibly has the right tag among several.

Extended Communities (RFC 4360)

Extended communities are 8 bytes (vs 4 for standard), providing more structure. They're primarily used in MPLS VPN environments for route targets and site-of-origin:

! Route target (used in VRF import/export)
ip vrf CUSTOMER-A
 rd 65001:1
 route-target export 65001:100
 route-target import 65001:100

Extended communities are less commonly manipulated in pure internet BGP - they're an MPLS/VPN tool. But they follow the same transitive behavior: they're carried across AS boundaries unless explicitly stripped.

The type field is what makes them more than a wider standard community: a route target and a site-of-origin are both extended communities, and the type tells a PE which one it is looking at. If the import and export values above look like they do the same job as a route distinguisher, they do not, and the difference between a route distinguisher and a route target is the thing to get straight before you debug a VRF missing routes. Note also that a session carrying route targets needs send-community both.

Large Communities (RFC 8092)

Standard communities have a 16-bit ASN field, which doesn't fit 4-byte ASNs (anything over 65535). Large communities solve this with a 12-byte format: ASN:Function:Parameter.

! Large community example for 4-byte ASN
set large-community 394210:100:1 additive

! Matching
ip large-community-list standard LC-EXAMPLE permit 394210:100:1
!
route-map MATCH-LC permit 10
 match large-community LC-EXAMPLE

The three-field format also provides more semantic structure - for example: ASN:Action:Region where Action=100 means "set local-pref" and Region=1 means "US-East."

Before large communities existed, operators with 4-byte ASNs borrowed a 2-byte ASN they happened to own, or encoded their AS into the value field and hoped nobody collided with them. Both workarounds are still out there, which is why you will occasionally meet a scheme whose AS field has nothing to do with the AS that set it. Designing a new scheme above 65535 today? Use large communities.

Community-Based Policy Design

A well-designed community scheme lets customers signal routing preferences to their ISP without needing per-customer configuration changes on the ISP side. Common ISP community schemes:

The ISP implements this with a single inbound route-map that matches community values and takes the appropriate action. Adding a new customer or changing policy doesn't require config changes - just different community tags on the customer's advertisements.

The mechanics on this page are the prerequisite for that, not the whole job. Once you can tag, match and act reliably, the hard part becomes the scheme itself: carving up the value space so it survives five years of growth, and stopping a customer tag from triggering an action you meant only for internal use. That is a design problem rather than a syntax problem, so work through how to design a community scheme your customers can actually use before you commit to values you will be stuck with.

Stripping Communities

You should strip internal communities before advertising to eBGP peers - they're your internal policy tags and leaking them reveals your routing strategy:

route-map STRIP-INTERNAL-OUT permit 10
 set community none
!
router bgp 65001
 neighbor 172.16.0.2 route-map STRIP-INTERNAL-OUT out

Or selectively delete specific communities while preserving others:

ip community-list standard INTERNAL permit 65001:100
ip community-list standard INTERNAL permit 65001:200
!
route-map CLEAN-OUT permit 10
 set comm-list INTERNAL delete

Prefer the second form. set community none is a sledgehammer: it removes the well-known communities too, so a route a customer marked no-export loses that protection on the way out of your network and gets announced to the world. set comm-list ... delete removes only the values you listed, which is what you almost always meant. Remember the trailing empty permit clause here too.

Verification

Four commands cover almost every community question, and each answers a different one. All four were used to produce the captures above.

Start on the receiving router, not the sending one. If show ip bgp <prefix> on the neighbour shows no Community: line, the tag never crossed the session and you are looking for a missing send-community or a route-map that did not match. If the community is there but your policy did not fire, the fault is local: the community-list, the clause order, or an exact-match you forgot you wrote.

Common Mistakes and Gotchas

One more is less a mistake than a fact of life: a community you send upstream is only as durable as the next AS's inbound policy, and plenty of networks strip everything they do not recognise on ingress. If your tag has to survive two AS hops to do its job, verify that it does rather than assuming transitive means permanent.

Key Takeaways

• Communities are tags (not actions) - they carry no inherent behavior but enable policy decisions on routers that match them. The exceptions are the well-known communities, which act everywhere without any policy configured.
• Enable send-community per neighbor - Cisco doesn't send communities by default. It is also per address family, and you need send-community both to carry extended communities such as route targets.
• Always use additive with set community to append rather than replace existing communities, and keep the trailing empty permit clause on any route-map you apply to a neighbor.
• The tag/match/act cycle is visible in three commands: show ip bgp <prefix> on the neighbour proves the tag arrived, show ip bgp community <value> proves which prefixes carry it, and "% Network not in table" one hop further on proves the action took effect.
• A community printed as a 10-digit decimal is the same attribute as AA:NN (divide by 65536 for the AS, remainder for the value). Large communities (RFC 8092) solve the 4-byte ASN limitation the old format cannot.
• Strip internal communities before advertising to eBGP peers to avoid exposing your policy design, and prefer set comm-list ... delete over set community none so you do not discard a customer's no-export along with your own tags.

Communities are the cheapest lever in BGP: one attribute, set once, acted on by routers you do not administer. To see where they sit against local preference, MED, AS-path prepending and the rest of the BGP attribute toolkit, the pillar guide lays out how the pieces fit together.