> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # BGP Communities: Tag, Match, and Act on Cisco IOS XE - URL: https://www.pinglabz.com/bgp-communities/ - Published: 2026-03-28T06:51:59.000Z - Updated: 2026-08-24T05:05:21.000Z - Description: Most community write-ups stop at the set community line. This one follows the tag all the way through: R1 tags a prefix with 65001:200 and no-export, R2 prints the community and flags it as not advertised to EBGP peer, and R3 answers with % Network not in table. Captured on IOS XE 17.18.2 in CML. - Author: Jaime - Tags: BGP, #Import 2026-08-01 19:54 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 neighbor 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](https://www.pinglabz.com/bgp/) 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 behavior 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 no-export Value65535:65281 Behavior Do not advertise this route to any eBGP peer no-advertise Value65535:65282 Behavior Do not advertise this route to any peer (iBGP or eBGP) internet Value0:0 Behavior Advertise to all peers (the default behavior) local-AS Value65535:65283 Behavior Do not advertise outside the local confederation sub-AS 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. R1 (AS 65001)Originates both /24s, applies the tagging route-map outbound to R2 R2 (AS 65002)Transit AS, eBGP to R1 on 10.0.12.0/30 and to R3 on 10.0.23.0/30 R3 (AS 65003)The far side, the router that must never see the tagged prefix 100.100.100.0/24The control. Advertised plain, no community, should reach R3 100.100.200.0/24Tagged with 65001:200 and no-export, should stop at R2 PlatformCML iol-xe, IOS XE 17.18.2, `send-community` on every eBGP session 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](https://www.pinglabz.com/bgp-route-filtering-prefix-lists/) 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](https://www.pinglabz.com/bgp-route-maps/) 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](https://www.pinglabz.com/bgp-local-preference/). If the result surprises you, knowing [which BGP path wins and why](https://www.pinglabz.com/bgp-best-path-selection/) 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. Unlike standard communities, each extended community carries a transitive bit (RFC 4360): transitive ones can cross AS boundaries unless stripped, while non-transitive ones (route targets in practice stay inside the provider network) are never propagated to another AS. 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](https://www.pinglabz.com/mpls-rd-vs-rt-explained/) 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: 65010:100 MeaningNormal announcement ISP Action Advertise to all peers with standard attributes 65010:200 MeaningReduce preference ISP Action Set local-pref to 80 (backup path) 65010:300 MeaningBlackhole ISP Action Set next-hop to null route (DDoS mitigation) 65010:666 MeaningRTBH trigger ISP Action Remotely triggered blackhole - drop traffic to this prefix 65010:10XX MeaningRegional control ISP Action Only advertise in region XX (e.g., 1001 = US, 1002 = EU) 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](https://www.pinglabz.com/bgp-community-policy-design/) 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. `show ip bgp`Did the prefix arrive at all? Communities are not shown here `show ip bgp `The Community: line, plus "not advertised to EBGP peer" if a tag is blocking it `show ip bgp community `Which prefixes carry this tag. Add exact-match to exclude routes carrying extras `show ip community-list`What your lists actually contain, when a match is not matching Start on the receiving router, not the sending one. If `show ip bgp ` on the neighbor 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 Communities not appearing on received routes Cause `send-community` not configured on the advertising peer Fix Add `neighbor [ip] send-community` on the sending router. For both standard and extended: `send-community both`. Community set but existing communities overwritten Cause Missing `additive` keyword in `set community` Fix Add `additive`: `set community 65001:100 additive`. `show ip bgp` not displaying communities Cause The summary table never shows communities; display format may also be decimal Fix Use `show ip bgp [prefix]` for the detailed view. Check `ip bgp-community new-format` for AA:NN display. Only one prefix reaches the neighbor after adding a route-map Cause Missing empty permit clause; the implicit deny drops everything the map did not match Fix Add a trailing `route-map RM-OUT permit 20` with no match or set statements. no-export did not stop the route inside your AS Cause `no-export` only blocks eBGP advertisement; iBGP peers still learn the prefix Fix Use `no-advertise` if the prefix must not leave the receiving router at all. match community matches nothing on a tagged route Cause `exact-match` in use, or several values on one community-list line (AND, not OR) Fix Drop `exact-match`, or split the values onto separate `permit` lines. 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. - Use `additive` with `set community` when you mean to append; without it, set community replaces the whole list, which is only correct when a full rewrite is what you intend. 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 ` on the neighbor proves the tag arrived, `show ip bgp community ` 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](https://www.pinglabz.com/bgp/), the pillar guide lays out how the pieces fit together.