Using BGP Communities

Problem

You want to configure BGP Communities to control routing and route propagation.

Solution

Configuring Cisco routers to use BGP Communities is a two-step process. You must specify the desired Community values by using a route map associated with a neighbor command:

Router3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router3(config)#ip prefix-list 10.101/16 seq 5 permit 10.101.0.0/16
Router3(config)#ip prefix-list 10.102/16 seq 5 permit 10.102.0.0/16
Router3(config)#ip prefix-list 10.103/16 seq 5 permit 10.103.0.0/16
Router3(config)#ip prefix-list 10.104/16 seq 5 permit 10.104.0.0/16
Router3(config)#ip prefix-list 10.105/16 seq 5 permit 10.105.0.0/16
Router3(config)#route-map APPLY_COMMUNITY_A permit 10
Router3(config-route-map)#match ip address prefix-list 10.101/16
Router3(config-route-map)#set community no-advertise
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 20
Router3(config-route-map)#match ip address prefix-list 10.102/16
Router3(config-route-map)#set community no-export
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 30
Router3(config-route-map)#match ip address prefix-list 10.103/16
Router3(config-route-map)#set community local-AS
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 40
Router3(config-route-map)#match ip address prefix-list 10.104/16
Router3(config-route-map)#set community internet
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 50
Router3(config-route-map)#match ip address prefix-list 10.105/16
Router3(config-route-map)#set community 4293328976
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 100
Router3(config-route-map)#exit
Router3(config)#router bgp 65500
Router3(config-router)#no synchronization
Router3(config-router)#neighbor 172.18.5.3 remote-as 65500
Router3(config-router)#neighbor 172.18.5.3 next-hop-self
Router3(config-router)#neighbor 172.18.5.3 send-community both
Router3(config-router)#neighbor 172.18.5.10 remote-as 65500
Router3(config-router)#neighbor 172.18.5.10 next-hop-self
Router3(config-router)#neighbor 172.18.5.10 send-community both
Router3(config-router)#neighbor 192.168.1.9 remote-as 65520
Router3(config-router)#neighbor 192.168.1.9 send-community both
Router3(config-router)#neighbor 192.168.1.9 route-map APPLY_COMMUNITY_A in
Router3(config-router)#exit
Router3(config)#end
Router3#

Then, for all of the downstream routers that you want to use and/or propagate the Community values that you are setting, you must include the neighbor send-community command:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.5.4 remote-as 65500
Router2(config-router)#neighbor 172.18.5.4 send-community both
Router2(config-router)#neighbor 172.18.5.10 remote-as 65500
Router2(config-router)#neighbor 172.18.5.10 send-community both
Router2(config-router)#no auto-summary
Router2(config-router)#exit
Router2(config)#end
Router2#

Discussion

A standard BGP Community is simply a 32-bit number that BGP can attach to routing prefixes. This attribute is defined in RFC 1997, which also specifies that the values 0x00000000 through 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are reserved. It is classed as an Optional Transitive attribute, which means that Community values are passed along with routes, across both iBGP and eBGP links, and whether the receiving router understands what to do with them or not. RFC 4360 defines the Extended Community attribute, which is nearly identical, except that it uses a 64-bit field to help reduce the potential for overlapping uses.

There are two common uses for Communities. The first simply uses the few Well Known Community attributes:

local-AS (Well Known Community)

This Community value indicates that the associated route should not be advertised outside of the AS. So it is distributed among iBGP peers, but not via eBGP.

no-advertisedo not advertise to any peer (Well Known Community)

The no-advertise Community instructs routers not to advertise this route to any other BGP peers, not even iBGP peers.

no-exportdo not export to next AS (Well Known Community)

Routes containing the no-export Community value are not advertised to any router outside of the Confederation or to any routers outside of the AS.

Internet (Well Known Community)

Routes tagged with the internet community are assumed to be associated with the Public Internet. There is no special action associated with this Community value.

Using these Well Known Community values allows you to exercise control over how routes are distributed throughout your AS and into neighboring ASs. For example, if you have a route in your BGP tables that you want to restrict to your own AS and not advertise it to any external peers, you would simply set the local-AS Community value. If you are using BGP Confederations, you can similarly restrict a route to within a given Confederation by tagging it with the no-export Community. If you are not using Confederations, then the local-AS and no-export Communities have an identical result.

The second use for Communities is a little bit more complicated and requires agreement between ISPs and their clients. The application suggested in RFC 1998 allows customers of an ISP to affect routing decisions for their own routes within their ISP's network. In this system, the customer can tag their routes with a community value containing an ASN and a Local Preference value. The ASN value defines the AS that the customer would like to affect, and is contained in the first 16 bits of the Community value. The remaining 16 bits then contain a Local Preference value. This allows the customer to affect inbound routing for their networks in real time on a prefix-by-prefix basis.

For example, suppose you have two ISPs with ASNs 65511 and 65512. If you want to specify that inbound traffic to your network for a particular prefix is to use the first ISP preferentially, you would include a Community value of 65511:100 (which is FFE7:0064 in hex or 4293328996 in decimal) to request that the ISP set a Local Preference of 100 for this route.

Conversely, if you wanted to make this ISP the backup link for this particular route prefix, you could request a lower Local Preference value such as 80 by including a Community value of 65511:80 (which is FFE7:0050 in hex or 4293328976 in decimal).

The reason why we include these different formats for Community values is because the router configuration file displays them as decimal numbers. However you can also configure them as colon-separated 16-bit decimal numbers to allow ASN:nn format:

Router3(config)#route-map APPLY_COMMUNITY_A permit 50
Router3(config-route-map)#match ip address prefix-list 10.105/16
Router3(config-route-map)#set community 65511:80

This set community command will be displayed as:

!
route-map APPLY_COMMUNITY_A permit 50
 match ip address prefix-list 10.105/16
 set community 4293328976
!

And some IOS versions even get confused by the 32-bit number and incorrectly display it as a signed integer:

!
route-map APPLY_COMMUNITY_A permit 50
 match ip address prefix-list 10.105/16
 set community -1638320
!

But however your router displays the values, they all function identically.

You use route maps to apply Communities to routes, exactly the same way that we handled Local Preference values in Recipe 9.7. For example, this part of the route map uses a prefix-list to select a particular route, and sets its Community value to no- export:

Router3(config)#ip prefix-list 10.102/16 seq 5 permit 10.102.0.0/16
Router3(config)#route-map APPLY_COMMUNITY_A permit 20
Router3(config-route-map)#match ip address prefix-list 10.102/16
Router3(config-route-map)#set community no-export
Router3(config-route-map)#exit

You then need apply this route map to a neighbor command:

Router3(config)#router bgp 65500
Router3(config-router)#neighbor 192.168.1.9 remote-as 65520
Router3(config-router)#neighbor 192.168.1.9 send-community both
Router3(config-router)#neighbor 192.168.1.9 route-map APPLY_COMMUNITY_A in

In this case, we have applied the route map to incoming routes from this eBGP peer. As a general rule of thumb, to ensure consistency across your AS, you should attach any Community values to routes on the first router to handle the routes. In this case, the required routes are outside of the AS. However, if the routes originate within the AS, then we would have applied the route map outbound on the router that originates them. In that case, we would need to be careful to apply the route map to all of the iBGP peers.

The other important command in dealing with Communities is the neighbor send-community command:

Router3(config-router)#neighbor 192.168.1.9 send-community both

By default, Cisco routers do not propagate Community values with BGP routes. So you must include this command for all of the peers that need to see this attribute. This is why, in the Solution section of this recipe, we have been careful to include this command on the other routers inside our AS, even if those routers don't update the Community attribute. The both keyword in this command indicates that this router should send both Standard 32-bit and Extended 64-bit Community values. You can configure the router to use just one or the other if you prefer, but in most cases, if you are using Communities, you will want to make sure that you a propagating all of the attributes, so we generally recommend forwarding both types.

There are three useful commands for looking at Community values on a router. The first is the common show ip bgp summary command:

Router2#show ip bgp summary
BGP router identifier 172.18.5.3, local AS number 65500
BGP table version is 37, main routing table version 37
12 network entries using 1212 bytes of memory
12 path entries using 576 bytes of memory
7 BGP path attribute entries using 420 bytes of memory
1 BGP rrinfo entries using 24 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
5 BGP community entries using 120 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2424 total bytes of memory
BGP activity 46/34 prefixes, 54/42 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

172.18.5.4 4 65500 54 45 37 0 0 00:00:31 4
172.18.5.10 4 65500 47 65 37 0 0 00:08:35 8
Router2#

This output shows that there are five BGP routes on this router that have Community values associated with them. We can see which routes they are with the command show ip bgp community:

Router2#show ip bgp community
BGP table version is 37, local router ID is 172.18.5.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network Next Hop Metric LocPrf Weight Path
*>i10.11.0.0/16 172.18.5.2 0 100 0 65510 i
*>i10.102.0.0/16 172.18.5.4 0 100 0 65520 i
*>i10.103.0.0/16 172.18.5.4 0 100 0 65520 i
*>i10.104.0.0/16 172.18.5.4 0 100 0 65520 i
*>i10.105.0.0/16 172.18.5.4 0 100 0 65520 i
Router2#

As you can see, the list includes four of the five routes that we tagged on Router3, plus another route that was tagged elsewhere in the network. It's worth pointing out that we don't see 10.101.0.0/16 in this table because it was tagged with the no-advertise community. Consequently, Router3 did not advertise this route to Router2. You can see exactly which communities are associated with these routes as follows:

Router3#show ip bgp 10.101.0.0/16
BGP routing table entry for 10.101.0.0/16, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to
any peer)
 Not advertised to any peer
 65520
 192.168.1.9 from 192.168.1.9 (10.104.0.1)
 Origin IGP, metric 0, localpref 100, valid, external, best
 Community: no-advertise
Router3#show ip bgp 10.102.0.0/16
BGP routing table entry for 10.102.0.0/16, version 11
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to
EBGP peer)
 Advertised to non peer-group peers:
 172.18.5.3 172.18.5.10
 65520
 192.168.1.9 from 192.168.1.9 (10.104.0.1)
 Origin IGP, metric 0, localpref 100, valid, external, best
 Community: no-export
Router3#

This shows that the route 10.101.0.0/16 has the no-advertise community, and consequently is not being advertised. The route 10.102.0.0/16 has a community value of no-export, and is being advertised to two BGP peer routers.

Of course, just being able to set arbitrary Community values is not of much use. Your routers also need to be able to read and react appropriately to these values. To do this, you use a special kind of ACL called a community-list, which specifies community values for use in route maps:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#ip community-list 10 permit 65511:80
Router2(config)#route-map MATCH-COMMUNITY permit 10
Router2(config-route-map)#match community 10
Router2(config-route-map)#set local-preference 80
Router2(config-route-map)#exit
Router2(config)#route-map MATCH-COMMUNITY permit 100
Router2(config-route-map)#exit
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.5.4 remote-as 65500
Router2(config-router)#neighbor 172.18.5.4 route-map MATCH-COMMUNITY in
Router2(config-router)#exit
Router2(config)#end
Router2#

If we do a show ip bgp community now and compare to the output above, you can see that the Local Preference value has been changed for this route:

Router2#show ip bgp community
BGP table version is 21, local router ID is 172.18.5.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network Next Hop Metric LocPrf Weight Path
*>i10.11.0.0/16 172.18.5.2 0 100 0 65510 i
*>i10.102.0.0/16 172.18.5.4 0 100 0 65520 i
*>i10.103.0.0/16 172.18.5.4 0 100 0 65520 i
*>i10.104.0.0/16 172.18.5.4 0 100 0 65520 i
*>i10.105.0.0/16 172.18.5.4 0 80 0 65520 i
Router2#

As you can see, the Local Preference value for this route has now been changed appropriately.