Introduction

In the previous posts, I’ve covered BGP attributes that control traffic flow:

• Weight, Local Preference, AS-Path: Control which path traffic takes
• MED: Influence inbound traffic selection

Now it’s time for a different kind of BGP attribute: BGP Communities. Instead of influencing which path to take, communities control how far routes propagate through the network.

BGP Communities are tags attached to routes that signal routing policy information. Think of them as labels that say “hey, treat this route specially.” The two most fundamental standard communities are:

• no-export: “You can use this route within your AS, but don’t advertise it outside your AS”
• no-advertise: “You can use this route yourself, but don’t advertise it to anyone – not even your iBGP neighbors”

These communities are incredibly powerful for implementing routing policies like:

• Keeping internal routes from leaking to the internet
• Implementing customer-specific routing policies
• Controlling route visibility in complex AS topologies
• Preventing route distribution to specific peers

Understanding BGP Communities

What are BGP Communities?

BGP Communities are a 32-bit optional transitive attribute:

• Purpose: Tag routes with metadata for policy signaling
• Format: Typically written as ASN:value (e.g., 65000:100)
• Types: Well-known (standard) and Extended
• Propagation: Transitive – communities propagate by default once attached

The Critical Configuration Requirement

BY DEFAULT, BGP ROUTERS DO NOT SEND COMMUNITY ATTRIBUTES.

This is the #1 gotcha with communities. You must explicitly enable community transmission on each neighbor:

router bgp 2000
 neighbor 10.7.7.7 send-community      ! iBGP neighbor
 neighbor 192.1.48.4 send-community    ! eBGP neighbor

Without this configuration, communities are stripped before routes are advertised to neighbors, rendering the entire mechanism useless.

Standard vs Extended Communities

There are two types of communities:

Standard Communities:

• 32-bit value, formatted as ASN:value or a single integer
• Includes well-known communities: no-export, no-advertise, internet
• Enabled with send-community standard or just send-community

Extended Communities:

• 64-bit value, additional structure
• Used for MPLS VPNs, route targets, etc.
• Enabled with send-community extended

This post focuses on standard communities, specifically the well-known ones.

Well-Known Standard Communities

Three well-known communities are defined in BGP standards:

Community	Value	Meaning
no-export	65535:65281 (0xFFFFFF01)	Do not advertise to eBGP peers
no-advertise	65535:65282 (0xFFFFFF02)	Do not advertise to any peer (iBGP or eBGP)

no-export vs no-advertise: The Key Difference

no-export:
  iBGP neighbors:  CAN receive ✓
  eBGP neighbors:  CANNOT receive ✗
  Use: Keep routes within your AS

no-advertise:
  iBGP neighbors:  CANNOT receive ✗
  eBGP neighbors:  CANNOT receive ✗
  Use: Keep routes on the receiving router only

Lab Topology

Same topology from previous BGP attributes posts:

• AS 2000: R7, R8, R9 (iBGP mesh)
  • R7: eBGP to R4 (AS 1000)
  • R8: eBGP to R4 (AS 1000)
  • R9: eBGP to R11 (AS 110)
• AS 110: R11 (connected to R9)
• AS 1000: R4

AS 110 (R11) advertises routes to AS 2000 (R9). By default, AS 2000 will propagate these routes to AS 1000 (R4). Communities allow AS 110 to control this propagation.

Example 1: no-export Community

Requirement

AS 110 would like to keep its routes limited to AS 2000. AS 2000 should not forward the routes outside of AS 2000.

Translation:

• R11’s routes (111.0.0.0/8, 112.112.112.0/24) can be seen by R9, R7, R8 (all in AS 2000)
• But AS 2000 should NOT advertise these routes to AS 1000 (R4)

This is a common scenario: a small customer wants connectivity through a provider, but doesn’t want to be visible to the broader internet.

Initial State (Before no-export)

R9 (eBGP neighbor receiving from R11):

R9#sh ip bgp 111.0.0.0
BGP routing table entry for 111.0.0.0/8, version 21
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  110
    192.1.190.11 from 192.1.190.11 (112.112.112.11)
      Origin IGP, metric 0, localpref 100, valid, external, best

R9 receives the route from R11 and advertises it to update-groups (both iBGP and eBGP neighbors).

R7 (iBGP neighbor within AS 2000):

R7#sh ip bgp 111.0.0.0
BGP routing table entry for 111.0.0.0/8, version 21
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  110
    10.9.9.9 (metric 20) from 10.9.9.9 (99.9.9.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best

R7 receives the route via iBGP from R9 and also advertises it to update-groups (eBGP neighbors, specifically R4).

R4 (eBGP neighbor in AS 1000):

R4#sh ip bgp 111.0.0.0
BGP routing table entry for 111.0.0.0/8, version 27
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  2000 110
    192.1.48.8 from 192.1.48.8 (88.8.8.8)
      Origin IGP, localpref 100, valid, external, best
  2000 2000 2000 2000 110
    192.1.47.7 from 192.1.47.7 (77.7.7.7)
      Origin IGP, localpref 100, valid, external

R4 sees the route via two paths (from R8 and R7) and advertises it further to its update-groups.

Problem: AS 110’s route is visible to AS 1000 and beyond. AS 110 wants to prevent this.

Configuration

On R11 (AS 110), set no-export community and send it to R9:

route-map SETCOMM permit 10
 set community no-export

router bgp 110
 neighbor 192.1.190.9 route-map SETCOMM out
 neighbor 192.1.190.9 send-community standard

On R9 (AS 2000), enable sending communities to iBGP neighbors:

router bgp 2000
 neighbor 10.7.7.7 send-community standard
 neighbor 10.8.8.8 send-community standard

Breaking it down:

R11 configuration:

• Route-map SETCOMM sets the no-export community on all routes
• Applied outbound to R9 (neighbor 192.1.190.9)
• send-community standard enables sending the community attribute to R9

R9 configuration:

• send-community standard to iBGP neighbors ensures the community propagates within AS 2000
• This allows R7 and R8 to see the no-export tag and honor it

Critical: Both sending and receiving routers need send-community configured. R11 needs it to send to R9, R9 needs it to forward to R7/R8.

Results After Configuration

R9 (shows no-export, advertises to iBGP only):

R9#sh ip bgp 111.0.0.0
BGP routing table entry for 111.0.0.0/8, version 25
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Advertised to update-groups:
     1         
  110
    192.1.190.11 from 192.1.190.11 (112.112.112.11)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-export

Key changes:

• Community: no-export appears in the route attributes
• not advertised to EBGP peer status message
• Still advertised to update-groups (iBGP neighbors)

R9 honors the no-export community by not advertising this route to any eBGP neighbors (there are none directly connected to R9 in this topology, but the principle holds).

R7 (sees no-export, does NOT advertise to eBGP):

R7#sh ip bgp 111.0.0.0
BGP routing table entry for 111.0.0.0/8, version 25
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Not advertised to any peer
  110
    10.9.9.9 (metric 20) from 10.9.9.9 (99.9.9.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: no-export

Critical changes:

• Community: no-export is present (propagated via iBGP from R9)
• not advertised to EBGP peer status message
• Not advertised to any peer – R7 has eBGP neighbor R4, but suppresses advertisement due to no-export

R7 can use this route locally and knows about it, but will NOT advertise it to R4 (eBGP).

R4 (route completely gone):

R4#sh ip bgp 111.0.0.0
BGP routing table entry for 111.0.0.0/8, version 29
Paths: (0 available, no best path)
  Not advertised to any peer

R4 no longer has any path to 111.0.0.0/8. Both R7 and R8 suppress advertisement due to the no-export community.

Result: AS 110’s routes are confined to AS 2000. Mission accomplished!

Traffic Flow with no-export

AS 110 (R11) ─── 111.0.0.0/8 ───> AS 2000 (R9, R7, R8)
                                   ↓
                         no-export community prevents
                                   ↓
                              AS 1000 (R4)
                          [route not visible]

• AS 2000 can route traffic to AS 110 ✓
• AS 1000 cannot route traffic to AS 110 (no route) ✗

This creates unidirectional reachability. AS 110 can reach AS 1000 (via default route or other routes), but AS 1000 cannot reach AS 110 directly.

Example 2: no-advertise Community

Requirement

AS 110 wants most routes to propagate within AS 2000 (using no-export), BUT route 112.112.112.0/24 should not be allowed to propagate beyond R9 – not even to iBGP neighbors in AS 2000.

Translation:

• 111.0.0.0/8: Use no-export (visible throughout AS 2000, not beyond)
• 112.112.112.0/24: Use no-advertise (visible only on R9, nowhere else)

This scenario occurs when:

• A specific network is for management/monitoring purposes only
• Direct neighbor (R9) needs the route for reachability
• But no other router should even know it exists

Configuration

On R11 (AS 110), use selective community assignment:

access-list 1 permit 112.112.112.0 0.0.0.255

route-map SETCOMM permit 5
 match ip address 1
 set community no-advertise

route-map SETCOMM permit 10
 set community no-export

router bgp 110
 neighbor 192.1.190.9 route-map SETCOMM out
 neighbor 192.1.190.9 send-community standard

Breaking it down:

Sequence 5 (specific route):

• Matches 112.112.112.0/24 via ACL 1
• Sets community to no-advertise

Sequence 10 (everything else):

• No match clause = matches all routes not matched by sequence 5
• Sets community to no-export

Result: 112.112.112.0/24 gets no-advertise, all other routes get no-export.

R9 configuration (unchanged from Example 1):

router bgp 2000
 neighbor 10.7.7.7 send-community standard
 neighbor 10.8.8.8 send-community standard

Results After Configuration

R9 (sees 112.112.112.0/24 with no-advertise):

R9#sh ip bgp 112.112.112.0
BGP routing table entry for 112.112.112.0/24, version 27
Paths: (1 available, best #1, table default, not advertised to any peer)
  Not advertised to any peer
  110
    192.1.190.11 from 192.1.190.11 (112.112.112.11)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-advertise

Key observations:

• Community: no-advertise is present
• not advertised to any peer – includes iBGP and eBGP
• Route is installed locally in R9’s routing table (R9 can use it)

R9 receives the route, uses it for forwarding, but does not advertise it to ANYONE – not even iBGP neighbors R7 and R8.

R7 (route doesn’t exist):

R7#sh ip bgp 112.112.112.0
% Network not in table

R7 has no knowledge of 112.112.112.0/24 whatsoever.

R8 (route doesn’t exist):

R8#sh ip bgp 112.112.112.0
% Network not in table

R8 also has no knowledge of 112.112.112.0/24.

Result: 112.112.112.0/24 exists only on R9. No other router in AS 2000 (or beyond) knows about it.

Comparing no-export vs no-advertise

Using the same source AS (AS 110), here’s the visibility difference:

Route	Community	R9	R7/R8 (iBGP)	R4 (eBGP)
111.0.0.0/8	no-export	✓	✓	✗
112.112.112.0/24	no-advertise	✓	✗	✗

• no-export: Stops at AS boundary (iBGP ok, eBGP blocked)
• no-advertise: Stops at receiving router (nothing beyond)