A community is a logical group of prefixes that share some common attribute. Community members can be on different networks and in different autonomous systems. BGP allows you to define the community to which a prefix belongs. A prefix can belong to more than one community. The community attribute lists the communities to which a prefix belongs.
You can use communities to simplify routing policies by configuring which routing information a BGP speaker will accept, prefer, or distribute to other neighbors according to community membership. When a route is learned, advertised, or redistributed, a BGP speaker can set, append, or modify the community of a route. When routes are aggregated, the resulting BGP update contains a community attribute that contains all communities from all of the aggregated routes (if the aggregate is an AS-set aggregate).
Several well-known communities have been predefined. Table 20 describes how a BGP speaker handles a route based on the setting of its community attribute.
Table 20: Action Based on Well-Known Community Membership
In addition to the well-known communities, you can define local-use communities, also known as private communities or general communities. These communities serve as a convenient way to categorize groups of routes to facilitate the use of routing policies. The community attribute consists of four octets, but it is common practice to designate communities in the AA:NN format. The autonomous system number (AA) comprises the higher two octets, and the community number (NN) comprises the lower two octets. Both are expressed as decimal numbers. For example, if a prefix in AS 23 belongs to community 411, the attribute can be expressed as 23:411. Use the ip bgp-community new-format command to specify that the show commands display communities in this format.
Use the set community command in route maps to configure the community attributes. By default, the community attribute is not sent to BGP peers. To send the community attribute to a neighbor, use the neighbor send-community command.
Consider the network structure shown in Figure 26. The following sample configurations illustrate some of the capabilities of using the community attribute.
Figure 26: Communities

The following commands configure router NY to apply route map setcomm to routes going out to 10.72.4.3. If the community attribute of such a route matches instance 10 of the route map, router NY sets the community attribute to 31:15. All locally originated routes will match this instance of the route map.
- host1(config)#router bgp 31
- host1(config-router)#network 10.16.22.0 mask
255.255.254.0
- host1(config-router)#neighbor 10.72.4.3 remote-as
425
- host1(config-router)#neighbor 10.72.4.3 send-community
- host1(config-router)#neighbor 10.72.4.3 route-map
setcomm out
- host1(config-router)#exit
- host1(config)#ip as-path access-list 1 permit ^$
- host1(config)#route-map setcomm permit 10
- host1(config-route-map)#match as-path 1
- host1(config-route-map)#set community 31:15
The following commands configure router LA to apply route map matchcomm to routes coming in from 10.72.4.2. If the community attribute of such a route matches instance 10 of the route map, router LA sets the weight of the route to 25.
- host2(config)#router bgp 425
- host2(config-router)#network 172.24.160 mask
255.255.224.0
- host2(config-router)#neighbor 10.72.4.2 remote-as
31
- host2(config-router)#neighbor 10.72.4.2 send-community
- host2(config-router)#neighbor 10.72.4.2 route-map
matchcomm in
- host2(config-router)#neighbor 10.5.5.1 remote-as
122
- host2(config-router)#neighbor 10.5.5.1 send-community
- host2(config-router)#exit
- host2(config)#ip community-list 1 permit 31:15
- host2(config)#route-map matchcomm permit 10
- host2(config-route-map)#match community 1
- host2(config-route-map)#set weight 25
The following commands configure router Boston to apply route map 5 to routes going out to 10.5.5.4. If the destination IP address of such a route matches instance 10 of the route map, router Boston sets the community attribute of the route to no-export.
- host3(config)#router bgp 122
- host3(config-router)#network 192.168.144.0
mask 255.255.240.0
- host3(config-router)#neighbor 10.5.5.4 remote-as
425
- host3(config-router)#neighbor 10.5.5.4 send-community
- host3(config-router)#neighbor 10.5.5.4 route-map
5 out
- host3(config-router)#exit
- host3(config)#route-map 5 permit 10
- host3(config-route-map)#match ip address access5
- host3(config-route-map)#set community no-export
- host3(config-route-map)#exit
- host3(config)#access-list access5 permit 10.16.22.112
Suppose router Boston forwards a route destined for 10.16.22.112 through router LA. Route map 5 matches and sets the community attribute to no-export. As a consequence router LA does not export the route to router NY; the route does not reach its destination.
ip bgp-community new-format
neighbor send-community
- host1(config-router)#neighbor send-community
westcoast extended
To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
set community
- host1(config)#route-map nyc1 permit 10
- host1(config-route-map)#set community no-advertise