COMMUNITY ATTRIBUTE
The Community attribute is a set of destination addresses with the same characteristics. It simplifies routing policy applications and facilitates routing policy management and maintenance and allows a group of BGP devices in multiple ASs to share the same routing policies. This attribute is a route attribute and transmitted between BGP peers and not restricted within an AS. Before advertising a route with the Community attribute to peers, a BGP device can change the original Community attribute of this route.
The Community attribute is a set of 4-byte values, in the format AA:NN. As defined in RFC1997, the first two bytes indicate an AS number, and the last two bytes indicate a community identifier used for management.
The Community attribute is a BGP route tag that simplifies the implementation of routing policy. A specific Community attribute can be assigned to some routes. Based on this Community attribute, these routes can be managed and routing policy can be performed on these routes.
Figure 1 - Community attribute application
In Figure 1, a large number of routes in AS100 are imported into BGP, and these routes are used for voice calls and video surveillance. These routes are advertised to AS200 through BGP. Devices in AS200 need to carry out different policies on the routes used for voice calls and video surveillance. How to match these routes? You can use ACLs or IP prefix lists to match the routes one by one. This method, however, has a heavy workload and is inefficient because a large number of route prefixes exist.
You can use the Community attribute to address this issue. When these routes are imported into AS100, respective Community attributes are added to the routes to differentiate the routes used for voice calls and video surveillance. That is, the Community attribute 100:1 is added to the routes used for voice calls, and the Community attribute 100:2 is added to the routes used for video surveillance. These Community attributes are transmitted to AS200 along with the routes. In AS200, to carry out different policies for the routes used for voice calls and video surveillance, match the routes based on their respective Community attributes. For example, you can match all the routes used for voice calls based on the Community attribute 100:1.
BGP defines some well-known Community attributes. Table 1 lists these Community attributes.
| Community Attribute | Description |
| internet | By default, all routes belong to the internet community. A route with this attribute can be advertised to all BGP peers. |
| no-advertise | A route with this attribute cannot be advertised to any other BGP peers. |
| no-export | A route with this attribute cannot be advertised outside the local AS. If a confederation is defined, the route with this attribute cannot be advertised to the ASs outside the confederation but can be advertised to other sub-ASs in the confederation. |
| no-export-subconfed | A route with this attribute cannot be advertised outside the local AS or advertised to other sub-ASs in the confederation. |
Table 1 - BGP well-known Community attributes
SETTING THE COMMUNITY ATTRIBUTE FOR ROUTES
To use the Community filter, ensure that the Community attribute is carried in routes. The following describes how to set the Community attribute for routes.
Figure 2 - Setting the Community attribute for routes
Requirement Description
In Figure 2, LSW1 in AS100 advertises two routes 10.1.1.0/24 and 10.1.2.0/24 through BGP. In the BGP process of LSW1, use an export route-policy to modify the Community attribute of the route 10.1.1.0/24 to 100:1 so that downstream devices can carry out policies on the route based on this Community attribute.
Configuration
The key configuration of LSW1 is as follows:
#
ip ip-prefix huawei index 10 permit 10.1.1.0 24 //Define an IP prefix list to match the target route.
#
route-policy RP permit node 10 //Define a route-policy to set the Community attribute for the target route.
if-match ip-prefix huawei
apply community 100:1
route-policy RP permit node 20 //Permit the remaining routes.
#
bgp 100
router-id 1.1.1.1
peer 192.168.12.2 as-number 200
#
ipv4-family unicast
undo synchronization
network 10.1.1.0 255.255.255.0 //Advertise the route 10.1.1.0/24.
network 10.1.2.0 255.255.255.0 //Advertise the route 10.1.2.0/24.
peer 192.168.12.2 enable
peer 192.168.12.2 route-policy RP export //Apply the route-policy in the export direction of the specified BGP peer.
peer 192.168.12.2 advertise-community //Advertise the Community attribute to the specified BGP peer.
#
The key configuration of LSW2 is as follows:
#
bgp 200
router-id 2.2.2.2
peer 192.168.12.1 as-number 100
peer 192.168.23.2 as-number 300
#
ipv4-family unicast
undo synchronization
peer 192.168.12.1 enable
peer 192.168.23.2 enable
peer 192.168.23.2 advertise-community //Advertise the Community attribute to the specified BGP peer.
#
By default, the Community attribute is not updated to BGP peers along with the route prefix. Therefore, the peer advertise-community command needs to be configured on LSW1 and LSW2 to advertise this attribute to BGP peers.
Verification
After the preceding configurations are complete, check the BGP route 10.1.1.0 in the BGP routing table of LSW3.
<LSW3> display bgp routing-table 10.1.1.0
BGP local router ID : 3.3.3.3
Local AS number : 300
Paths: 1 available, 1 best, 1 select
BGP routing table entry information of 10.1.1.0/24:
From: 192.168.23.1 (2.2.2.2)
Route Duration: 01h08m07s
Direct Out-interface: Vlanif23
Original nexthop: 192.168.23.1
Qos information : 0x0
Community:<100:1> //This Community attribute is set and transmitted to downstream devices using a route-policy on LSW1.
AS-path 200 100, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
Not advertised to any peer yet
The preceding command output shows that after the Community attribute is set for the route, this route carries a Community attribute when reaching LSW3, which then can carry out some policies on the route based on the Community attribute.
Multiple methods are available to set the Community attribute for BGP routes. Table 2 lists common methods to set this attribute.
| Command | Description |
| apply community 100 | Changes the community name to 100. |
| apply community 100 150 | Changes the community name to 100 or 150. That is, BGP routes belong to two communities. |
| apply community 100 150 additive | Adds two Community attributes 100 and 150. That, BGP routes belong to three communities. |
| apply community none | Deletes the Community attribute of BGP routes. |
Table 2 - Example for setting the Community attribute for BGP routes
USING A COMMUNITY FILTER TO MATCH BGP ROUTES
The previous section describes how to set the Community attribute for BGP routes. After this attribute is set on an upstream router, it is transmitted along with routes so that downstream devices can carry out policies based on this attribute. BGP provides a tool, Community filter, to match BGP routes based on the Community attribute. The following describes how to use a Community filter to match BGP routes.
Figure 3 - Using a Community filter to match BGP routes
Requirement Description
In Figure 3, LSW1 in AS100 advertises three BGP routes. The Community attribute is set for the routes and transmitted along with the routes to LSW3 in AS300. Before policies are carried out, check the BGP routing table of LSW3.
<LSW3> display bgp routing-table
BGP Local router ID is 3.3.3.3
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 3
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.1.0/24 192.168.23.1 0 200 100i
*> 10.1.2.0/24 192.168.23.1 0 200 100i
*> 10.1.3.0/24 192.168.23.1 0 200 100iThe preceding command output shows that the BGP routing table of LSW3 contains three routes. Routing policy needs to be carried out on LSW3 to permit only the routes carrying the Community attribute 100:999.
Configuration
The previous section has described how to set the Community attribute. The following describes how to use a Community filter to filter routes.
The key configuration of LSW3 is as follows:
# ip community-filter 1 permit 100:999 # route-policy huawei permit node 10 if-match community-filter 1 # bgp 300 router-id 3.3.3.3 peer 192.168.23.1 as-number 200 # ipv4-family unicast undo synchronization peer 192.168.23.1 enable peer 192.168.23.1 route-policy huawei import #
Verification
After the preceding configurations are complete, check the BGP routing table of LSW3.
[LSW3] display bgp routing-table
BGP Local router ID is 3.3.3.3
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 2
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.1.0/24 192.168.23.1 0 200 100i
*> 10.1.2.0/24 192.168.23.1 0 200 100iThe defined Community filter matches the route carrying the Community attribute 100:999. Therefore, the two routes 10.1.1.0/24 and 10.1.2.0/24 are permitted on LSW3, and other BGP routes are denied.
For this scenario, the following provides three common methods to configure the Community filter:
Case 1:
ip community-filter 1 permit 100:1 100:999
//Only the routes that carry two Community attributes 100:1 and 100:999 can be matched. Therefore, the route 10.1.1.0/24 is matched.Case 2:
ip community-filter 1 permit 100:1
ip community-filter 1 permit 100:2
//The routes that carry the Community attribute 100:1 or 100:2 can be matched. Therefore, the routes 10.1.1.0/24 and 10.1.2.0/24 are matched.Case 3:
ip community-filter 1 permit internet
//By default, all routes carry the Internet attribute. Therefore, all routes are matched.Reference:
support.huawei.com
