The only mechanism to set BGP community in Cisco IOS is the set community command
in a route-map.
BGP has default 4 well known communities that can be used to mark prefixes; listed as follows :
- Internet: advertise these routes to all neighbors.
- Local-as: prevent sending routes outside the local As within the confederation.
- No-Advertise: do not advertise this route to any peer, internal or external.
- No-Export: do not advertise this route to external BGP peers.
To implement communities we have to follow this process :
!
- First need to identify traffic and policies for traffic.
- Then we have to define a community and apply to particular prefixes by using route-maps.
- Then configure neighbor ip address send community for particular neighbors.
- As the routing update will received by other neighbors, that time router will look the associated
community and on the basis of that policy will be applied.
Processing of Communities :
!
- Prefixes are tagged with route-map with defined community values.
- Prefixes are advertised with communities to neighbors.
- As neighboring router will see the route associated with community, it will apply policies as
per configurations. Ex: Community 100:10 will say that the local preference of route should be
lowered to 50 as per configured policy.
Configuration Steps of BGP communities :
!
- Configure communities and tag the prefixes using route-map.
- Configure BGP community advertisement to particular neighbors. Since communities will be not
advertised to all neighbors with updates
- Configure BGP community access-lists to match BGP communities on receiving routers.
- Configure route-maps and define policies for particular receiving communities as per requirement.
- Apply the route-map to incoming or outgoing updates.
The BGP communities are transitive BGP attribute, meaning that they should be propagated to
all BGP neighbors.
Why using BGP communities?
Communities can be used to mark a set of prefixes that share a common property.
Upstream providers can use these marks to apply a common routing policy such as filtering or assigning
a specific local preference.
As a service provider you can make an agreement with your customers on a specific policy to be
applied to their prefixes using communities; this gives your customers the freedom to change the policy
of a prefix just by changing the community attribute value with no support from your side.
Using BGP communities to influence routing :
Our service provider, AS 65001, allows us to use the communities attribute of BGP to influence
how they route our traffic. In this (simplified) example, there are three different communities
we can use:
- 200: set local preference to 200
- 500: set local preference to 500
!
We are the customer (AS 65065) and R1 is our router. We are multi-homed to our service provider
(AS 65001) with a 100 Mbit/s connection to R2 and a T-1 connection to R3.
R2 and R3 are connected over a 100 Mbit/s connection as well.
If we send routes to AS 65001 with a community of 65001:200, the SP’s routers will set the
local preference on those routes to 200.
If we send routes to AS 65001 with a community of 65001:500, the SP’s routers will set the
local preference on those routes to 500. How handy is that?
Because of how the BGP best path selection algorithm works, we want our SP’s routers to assign a higher
local preference to the routes it receives from us over that 100 Mbit/s connection, so we’ll send
those routes with a community of 65001:500.
Just for good measure, we’ll attach community 65001:200 to the routers
we send to 172.16.13.3 over the T-1 connection as well.
Let’s go ahead and set up BGP, but don’t start advertising any routes just yet :
R1(config)# ip bgp-community new-format
R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 next-hop-self
R1(config-router)# neighbor 172.16.12.2 send-community
R1(config-router)# neighbor 172.16.13.3 remote-as 65001
R1(config-router)# neighbor 172.16.13.3 next-hop-self
R1(config-router)# neighbor 172.16.13.3 send-community
We are all set to begin advertising our routes, with the appropriate communities attached.
The next thing we need to do is create a pair of route maps. We’ll apply these route maps outbound to the
BGP peers and these are what we will use to attach our communities to the routes:
R1(config)# route-map LOCAL_PREF_200 permit 10
R1(config-route-map)# set community 65001:200
R1(config-route-map)# route-map LOCAL_PREF_500 permit 10
R1(config-route-map)# set community 65001:500
Lookin’ good so far, right? Let’s apply those route map to our BGP peers :
R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# neighbor 172.16.13.3 route-map LOCAL_PREF_200 out
That was easy enough. Now, let’s advertise those loopbacks :
R1(config-router)# network 172.31.0.0 mask 255.255.255.0
R1(config-router)# network 172.31.1.0 mask 255.255.255.0
R1(config-router)# network 172.31.2.0 mask 255.255.255.0
R1(config-router)# network 172.31.3.0 mask 255.255.255.0
Let’s take a look at how the SP sees our routes :
R2# sh ip bgp | in 65065
*> 172.31.0.0/24 172.16.12.1 0 500 0 65065 i
*> 172.31.1.0/24 172.16.12.1 0 500 0 65065 i
*> 172.31.2.0/24 172.16.12.1 0 500 0 65065 i
*> 172.31.3.0/24 172.16.12.1 0 500 0 65065 i
R3# sh ip bgp | in 65065
*>i172.31.0.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
*>i172.31.1.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
*>i172.31.2.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
*>i172.31.3.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
If we ping/traceroute from R3 to one of R1′s loopbacks, we should see that traffic first passes to
R2 before being sent to R1 (which is our goal):
R3# ping 172.31.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/17/36 ms
R3# traceroute 172.31.0.1
Type escape sequence to abort.
Tracing the route to 172.31.0.1
1 172.16.23.2 4 msec 12 msec 16 msec
2 172.16.12.1 16 msec * 32 msec
Success !
Suppose you want router Albany to set metrics for routes that it forwards to router Boston based
on the communities to which the routes belong. You can create community lists and filter the routes
with a route map that matches on the community list.
To configure router Albany :
host1(config)#router bgp 293
host1(config-router)#neighbor 10.5.5.2 remote-as 32
host1(config-router)#neighbor 10.2.2.1 remote-as 451
host1(config-router)#neighbor 10.2.2.4 remote-as 17
host1(config-router)#neighbor 10.2.2.4 route-map commtrc out
!
host1(config)#route-map commtrc permit 1
host1(config-route-map)#match community 1
host1(config-route-map)#set metric 20
!
host1(config)#route-map commtrc permit 2
host1(config-route-map)#match community 2
host1(config-route-map)#set metric 75
!
host1(config)#route-map commtrc permit 3
host1(config-route-map)#match community 3
host1(config-route-map)#set metric 85
!
host1(config)#ip community-list 1 permit 25
host1(config)#ip community-list 2 permit 62
host1(config)#ip community-list 3 permit internet
Show commands for monitoring Communities :
!
Show ip bgp prefix
Show ip bgp community – display all community associated routes
Show ip bgp community as:nn – display the particular prefixes with that community.
Show ip bgp community-list – display community list.
