Hands-On Lab: Configuring BGP Communities

This hands-on lab configures a BGP community value on a specific route and uses it downstream to apply a matching policy, demonstrating how communities let routers tag routes with metadata that any downstream router can act on without re-examining the original matching criteria.

BGP Community AttributeCommunity-Based Route-Map MatchingSend-Community

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure a route-map on an edge router that tags a specific route with a BGP community value, enable community propagation to an iBGP neighbor, and configure that downstream neighbor to match on the community value alone to apply a distinct policy.

Lab Purpose

Every path-manipulation technique covered earlier in this series — weight, local preference, AS-path prepending, MED — requires re-matching the same original criteria (an ACL, a prefix list) at every point in the network where a policy decision is needed. Communities solve this by tagging a route once at the edge with an arbitrary label, letting every downstream router make policy decisions based purely on that label without needing to know or re-implement the original matching logic.

Lab Topology

R1 (edge router, learns routes from a partner
    via eBGP) ---- iBGP ---- R2 (core router,
                              applies a policy
                              based on community)

R1 learns 192.168.60.0/24 from an external
partner and wants to tag it as "customer-route"
for special handling elsewhere in the network

Task 1: Configure a Route-Map Setting a Community on Inbound Routes

On R1, configure a route-map matching 192.168.60.0/24 and setting a specific community value on it.

Task 2: Apply the Route-Map to the Inbound eBGP Session

Apply the route-map inbound on R1's session with the external partner.

Task 3: Enable Community Propagation Toward R2

Configure R1's iBGP session with R2 to actually send community attributes, since this is not enabled by default.

Task 4: Verify R2 Receives the Community

Confirm R2 sees the community value attached to the route.

Task 5: Configure R2 to Apply a Policy Based Solely on the Community

On R2, configure a route-map matching only the community value (not the original prefix) and apply a distinct local preference to it.

Solution and Verification

R1(config)# ip prefix-list CUSTOMER-ROUTE permit 192.168.60.0/24

R1(config)# route-map TAG-CUSTOMER permit 10
R1(config-route-map)# match ip address prefix-list CUSTOMER-ROUTE
R1(config-route-map)# set community 65050:100
R1(config-route-map)# exit
R1(config)# route-map TAG-CUSTOMER permit 20
-- Sequence 20 with no match/set passes
-- everything else through unmodified

R1(config)# router bgp 65050
R1(config-router)# neighbor [partner address] route-map TAG-CUSTOMER in

R1(config-router)# neighbor [R2 address] send-community

-- Community values are NOT sent by default
-- in BGP updates -- send-community must be
-- explicitly enabled on each session where
-- the attribute needs to propagate

R2# show ip bgp 192.168.60.0

BGP routing table entry for 192.168.60.0/24
  65099
    [R1 address] from [R1 address] (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 65050:100
-- R2 correctly received the community
-- tag attached by R1, without R2 needing
-- to know anything about the original
-- prefix-list matching logic that created it

R2(config)# ip community-list standard CUSTOMER-COMM permit 65050:100

R2(config)# route-map APPLY-CUSTOMER-POLICY permit 10
R2(config-route-map)# match community CUSTOMER-COMM
R2(config-route-map)# set local-preference 150
R2(config-route-map)# exit
R2(config)# route-map APPLY-CUSTOMER-POLICY permit 20

R2(config)# router bgp 65050
R2(config-router)# neighbor [R1 address] route-map APPLY-CUSTOMER-POLICY in

R2# show ip bgp 192.168.60.0

BGP routing table entry for 192.168.60.0/24
  65099
    [R1 address] from [R1 address] (1.1.1.1)
      Origin IGP, metric 0, localpref 150, valid, internal, best
      Community: 65050:100
-- Local preference of 150 was applied
-- purely by matching the community tag,
-- entirely independent of any awareness
-- of the 192.168.60.0/24 prefix itself

Key Takeaway

Communities decouple the act of classifying a route from the act of applying policy to it — a route is tagged once, typically at the network edge where the original classification criteria naturally lives, and every downstream router applies its own policy purely by matching that tag, eliminating the need to duplicate prefix lists or ACLs at every policy point throughout a large network; send-community must be explicitly configured on every session the tag needs to cross, since it is never propagated by default.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue