Using Extended ACLs for BGP Filtering

Prior to the support of prefix-lists in the IOS advanced filtering for BGP needed to be done using extended ACLs.  The syntax for using extended ACLs is shown below:
access-list permit ip
The source portion of the extended ACL is used to match the network portion of the BGP route and the destination portion of the ACL is used to match the subnet mask of the BGP route.  Here are some examples:
access-list 100 permit ip 10.0.0.0 0.0.0.0 255.255.0.0 0.0.0.0
Matches 10.0.0.0/16 – Only
access-list 100 permit ip 10.0.0.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.0.0.0/24 – Only
access-list 100 permit ip 10.1.1.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.1.1.0/24 – Only
access-list 100 permit ip 10.0.0.0 0.0.255.0 255.255.255.0 0.0.0.0
Matches 10.0.X.0/24 – Any number in the 3rd octet of the network with a /24 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.0 255.255.255.0 0.0.0.0
Matches 10.X.X.0/24 – Any number in the 2nd & 3rd octet of the network with a /24 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.240 0.0.0.0
Matches 10.X.X.X/28 – Any number in the 2nd, 3rd & 4th octet of the network with a /28 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.0 0.0.0.255
Matches 10.X.X.X/24 to 10.X.X.X/32 – Any number in the 2nd, 3rd & 4th octet of the network with a /24 to /32 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.128 0.0.0.127
Matches 10.X.X.X/25 to 10.X.X.X/32 – Any number in the 2nd, 3rd & 4th octet of the network with a /25 to /32 subnet mask

By Brian Dennis, CCIE #2210

Understanding BGP Port Numbers

Guys,
I ran into a task in a lab to configure an ACL to allow BGP and the book has it configured like this:
Permit tcp host 150.1.5.5 eq bgp host 150.1.4.4
Permit tcp host 150.1.5.5 host 150.1.4.4 eq bgp
Is there a reason why it is configured like that instead of ‘Permit tcp host 150.1.5.5 eq bgp host 150.1.4.4 eq bgp’ ?
The only reason I could think of was to allow source/destination traffic from tcp 179 to a different port.
Ted

Hi Ted,
Your reasoning is correct; it is because BGP uses different source and destination ports other than 179 depending on who originates the session. BGP is essentially a standard TCP based protocol, which means that it is client and server based.
When a TCP client attempts to establish a connection to a TCP server it first sends a TCP SYN packet to the server with the destination port as the well known port. This first SYN essentially is a request to open a session. If the server permits the session it will respond with a TCP SYN ACK saying that it acknowledges the request to open the session, and that it also wants to open the session. In this SYN ACK response the server uses the well known port as the source port, and a randomly negotiated destination port. The last step of the three way handshake is the client responding to the server with a TCP ACK, which acknowledges the server’s response and completes the connection establishment.
Now from the perspective of BGP specifically the TCP clients and servers are routers. When the “client” router initiates the BGP session is sends a request to the server with a destination port of 179 and a random source port X. The server then responds with a source port of 179 and a destination port of X. Therefore all client to server traffic uses destination 179, while all server to client traffic uses source 179. We can also verify this from the debug output in IOS.
In the below topology R1 and R2 are directly connected BGP peers on an Ethernet segment with configurations as follows:

R1:
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
router bgp 1
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.0.0.2 remote-as 1

R2:
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
router bgp 1
 network 2.2.2.2 mask 255.255.255.255
 neighbor 10.0.0.1 remote-as 1

From the “debug ip packet detail” output we can see the initial TCP session establishment for BGP between these neighbors as follows:

R1:
IP: tableid=0, s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), routed via RIB
IP: s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), len 44, rcvd 3
    TCP src=11000, dst=179, seq=3564860120, ack=0, win=16384 SYN

R2:
IP: tableid=0, s=10.0.0.1 (Ethernet0/0), d=10.0.0.2 (Ethernet0/0), routed via RIB
IP: s=10.0.0.1 (Ethernet0/0), d=10.0.0.2 (Ethernet0/0), len 44, rcvd 3
    TCP src=179, dst=11000, seq=1977460611, ack=3564860121, win=16384 ACK SYN

R1:
IP: tableid=0, s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), routed via RIB
IP: s=10.0.0.2 (Ethernet0/0), d=10.0.0.1 (Ethernet0/0), len 40, rcvd 3
    TCP src=11000, dst=179, seq=3564860121, ack=1977460612, win=16384 ACK

In the first code snippet we can see that R1 has received a TCP packet from R2. This packet was sourced from 10.0.0.2 (R2), destined to 10.0.0.1 (R1), has a TCP source port of 11000 (the random port), a destination TCP port of 179 (the well known port), and is a SYN packet (1st step of three way handshake).
Next R2 receives the response from R1 that is a TCP SYN ACK, but in this case we can see that the port numbers are swapped. R1, the TCP server, now uses TCP port 179 as the source port, and the randomly negotiated port 11000 as the destination.
Further debugging of the BGP flow between these neighbors will show R1 using destination 179 (as the TCP client) and R2 using source 179 (as the TCP server).
The implication of this operation is that if BGP needs to be matched for some reason, i.e. to filter it out in an access-list, to match it in a QoS policy, we must account for traffic that is both going to TCP port 179 and coming from TCP port 179.

By Brian McGahan, CCIE #8593

BGP LINKS from CISCO

 BGP Case Studies 

 Configuring BGP 

 BGP: Frequently Asked Questions 

 Troubleshooting BGP 

 Border Gateway Protocol (BGP)

 

 

 

 

 

How to Block One or More Networks From a BGP Peer

Introduction

Route filtering is the basis by which Border Gateway Protocol (BGP) policies are set. There are number of ways to filter one or more networks from a BGP peer, including Network Layer Reachability Information (NLRI) and AS_Path and Community attributes. This document discusses filtering based on NLRI only.

Identifying and Filtering Routes based on NLRI

To restrict routing information that the router learns or advertises, you can use filters based on routing updates. The filters consist of an access list or a prefix list, which is applied to updates to neighbors and from neighbors. This document explores these options with this network diagram:

Network Diagram

Filtering Using distribute-list with a Standard Access List

Router 200 announces these networks to its peer Router 100:

• 192.168.10.0/24
  
• 10.10.10.0/24
  
• 10.10.0.0/19
  

This sample configuration enables Router 100 to deny an update for network 10.10.10.0/24 and permit the updates of networks 192.168.10.0/24 and 10.10.0.0/19 in its BGP table:

Router 100
hostname Router 100 ! router bgp 100 neighbor 172.16.1.2 remote-as 200 neighbor 172.16.1.2 distribute-list 1 in ! access-list 1 deny 10.10.10.0 0.0.0.255 access-list 1 permit any

Router 200
hostname Router 200 ! router bgp 200 no synchronization network 192.168.10.0 network 10.10.10.0 mask 255.255.255.0 network 10.10.0.0 mask 255.255.224.0 no auto-summary neighbor 172.16.1.1 remote-as 100

This show ip bgp command output confirms the actions of Router 100:

Router 100# show ip bgp

BGP table version is 3, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.0.0/19     172.16.1.2               0             0 200 i
*> 192.168.10.0/24  172.16.1.2               0             0 200 i

Filtering Using distribute-list with an Extended Access List

It can be tricky to use a standard access list to filter supernets. Assume Router 200 announces these networks:

• 10.10.1.0/24 through 10.10.31.0/24
  
• 10.10.0.0/19 (its aggregate)
  

Router 100 wishes to receive only the aggregate network, 10.10.0.0/19, and to filter out all specific networks.
A standard access list, such as access-list 1 permit 10.10.0.0 0.0.31.255, will not work because it permits more networks than desired. The standard access list looks at the network address only and can not check the length of the network mask. That standard access-list will permit the /19 aggregate as well as the more specific /24 networks.
To permit only the supernet 10.10.0.0/19, use an extended access list, such as access-list 101 permit ip 10.10.0.0 0.0.0.0 255.255.224.0 0.0.0.0. Refer to access-list (IP extended) for the format of the extended access-list command.
In our example, the source is 10.10.0.0 and the source-wildcard of 0.0.0.0 is configured for an exact match of source. A mask of 255.255.224.0, and a mask-wildcard of 0.0.0.0 is configured for an exact match of source mask. If any one of them (source or mask) does not have a exact match, the access list denies it.
This allows the extended access-list command to permit an exact match of source network number 10.10.0.0 with mask 255.255.224.0 (and thus, 10.10.0.0/19). The other more specific /24 networks will be filtered out.
Note: When configuring wild cards, 0 means that it is an exact match bit and 1 is a do-not-care-bit.
This is the configuration on Router 100:

Router 100
hostname Router 100 ! router bgp 100 !--- Output suppressed. neighbor 172.16.1.2 remote-as 200 neighbor 172.17.1.2 distribute-list 101 in ! ! access-list 101 permit ip 10.10.0.0 0.0.0.0 255.255.224.0 0.0.0.0

The show ip bgp command output from Router 100 confirms that the access list is working as expected.

Router 100# show ip bgp

BGP table version is 2, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.0.0/19     172.16.1.2               0             0 200 i

As seen in this section, extended access lists are more convenient to use when some networks must be allowed and some disallowed, within the same major network. These examples provide more insight on how an extended access list can help in some situations:

• access-list 101 permit ip 192.168.0.0 0.0.0.0 255.255.252.0 0.0.0.0
  This access-list permits only the supernet 192.168.0.0/22.
  
• access-list 102 permit ip 192.168.10.0 0.0.0.255 255.255.255.0 0.0.0.255
  This access-list permits all the subnets of 192.168.10.0/24. In other words, it will allow 192.168.10.0/24, 192.168.10.0/25, 192.168.10.128/25, and so forth: any of the 192.168.10.x networks with a mask that ranges from 24 to 32.
  
• access-list 103 permit ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.255
  This access list permits any network prefix with a mask that ranges from 24 to 32.
  

Filtering Using the ip prefix-list Command

Router 200 announces these networks to its peer Router 100:

• 192.168.10.0/24
  
• 10.10.10.0/24
  
• 10.10.0.0/19
  

The sample configurations in this section use the ip prefix-list command, which enables Router 100 to do two things:

• Permit updates for any network with a prefix mask length less than or equal to 19.
  
• Deny all network updates with a network mask length greater than 19.
  

Router 100
hostname Router 100 ! router bgp 100 neighbor 172.16.1.2 remote-as 200 neighbor 172.16.1.2 prefix-list cisco in ! ip prefix-list cisco seq 10 permit 0.0.0.0/0 le 19

Router 200
hostname Router 200 ! router bgp 200 no synchronization network 192.168.10.0 network 10.10.10.0 mask 255.255.255.0 network 10.10.0.0 mask 255.255.224.0 no auto-summary neighbor 172.16.1.1 remote-as 100

The show ip bgp command output confirms that the prefix list is working as expected on Router 100.

Router 100# show ip bgp

BGP table version is 2, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.0.0/19     172.16.1.2               0             0 200 i

In conclusion, the use of prefix lists is the most convenient way to filter networks in BGP. In some cases, however—for example, when you want to filter odd and even networks while you also control the mask length—extended access lists will offer you greater flexibility and control than prefix lists.

Using Regular Expressions

AS-path Lists

You can use regular expressions when you define AS-path access lists and community lists to more easily filter routes. A regular expression uses special characters—often referred to as metacharacters—to define a pattern that is compared with an input string.

For an AS-path access list, the input string is the AS path of the routes to which the list is applied with the route-map or neighbor filter-list commands. If the AS path matches the regular expression in the access list, the route matches the access list.

Example

The following commands apply access list 1 to routes inbound from BGP peer 10.5.5.2. Access list 1 uses a regular expression to deny routes that originate in autonomous system 32.

host1(config-router)#neighbor 10.5.5.2 remote-as 32

host1(config-router)#neighbor 10.5.5.2 filter-list 1 in

host1(config-router)#exit

host1(config)#ip as-path access-list 1 deny 32$

 

Community Lists

For a community list, the input string is the community attribute of the routes to which the list is applied using a route-map command. If the community attribute matches the regular expression in the community list, the route matches the community list.

Example

The following commands apply route map 5 to routes forwarded to BGP peer 10.5.5.4. Route map 5 uses a regular expression to match community numbers ending with 305, setting the weight of matching routes to 150.

host1(config-router)#neighbor 10.5.5.4 remote-as 425

host1(config-router)#neighbor 10.5.5.4 route-map 5 out

host1(config-router)#exit

host1(config)#route-map 5 permit 10

host1(config-route-map)#match community 305$

host1(config-route-map)#set weight 150

 

 

Community Numbers

When you use a regular expression to match a community number, use the appropriate format for the community number in the community list. If you issue the ip bgp-community new-format command, the community number has the format AA:NN where AA is a number that identifies the autonomous system, and NN is a number that identifies the community within the autonomous system. Otherwise, the community number is an integer in the range 1–4294967295.

Metacharacters

Each regular expression consists of one or more metacharacters and zero or more complete or partial AS or community numbers. Table 6 describes the metacharacters supported for regular expression pattern-matching.

Table 6: Supported Regular Expression Metacharacters

Metacharacter	Description
^	Matches the beginning of the input string. Alternatively, when used as the first character within brackets—[^ ]—matches any number except the ones specified within the brackets.
$	Matches the end of the input string.
.	Matches any single character, including white space.
*	Matches zero or more sequences of the immediately previous character or pattern.
+	Matches one or more sequences of the immediately previous character or pattern.
?	Matches zero or one sequence of the immediately previous character or pattern.
()	Specifies patterns for multiple use when followed by one of the multiplier metacharacters: asterisk (*), plus sign (+), or question mark (?).
[ ]	Matches any enclosed character; specifies a range of single characters.
– (hyphen)	Used within brackets to specify a range of AS or community numbers.
_ (underscore)	Matches a ^, a $, a comma, a space, a {, or a }. Placed on either side of a string to specify a literal and disallow substring matching. Numerals enclosed by underscores can be preceded or followed by any of the characters listed above.
|	Matches characters on either side of the metacharacter; logical OR.

Using Metacharacters as Literal Tokens

You can remove the special meaning of a metacharacter by preceding it with a backslash (\). Such a construction denotes that the metacharacter is not treated as a metacharacter for that regular expression. It is simply a character or token with no special meaning, just as a numeral has no special meaning. The backslash applies only to the character immediately following it in the regular expression.

On an E-series router, you are likely to use the backslash only for the parentheses characters, ( or ). BGP indicates a segment of an AS path that is of type AS-confed-set or AS-confed-seq by enclosing that segment with parentheses.

Example

The following AS-path access list uses a regular expression to match routes that have an AS-path attribute that begins with any AS-confed-set or AS-confed-seq:

host1(config)#ip as-path access-list 1 permit ^\(

The following AS-path access list uses a regular expression to match routes that have an AS-path attribute that ends with any AS-confed-set or AS-confed-seq:

host1(config)#ip as-path access-list 1 permit \)$

The following AS-path access list uses a regular expression to match routes that have an AS-path attribute that includes the specific AS-confed-set or AS-confed-seq, (100 200):

host1(config)#ip as-path access-list 1 permit \(100 200\)

 

Regular Expression Examples

Table 7 lists some representative regular expressions that you might use in an AS-path access list or community list, along with sample attribute values that match or do not match the regular expression.

Table 7: Sample Regular Expressions

Regular Expression	Matched AS-Path or Community Attribute	Example
^12	Begins with 12	12 23 4212 629 121245 19 but not 58 12 7
[^12]	Includes any numeral except 1 or 2	44 73 465 69 8 but not 1145 1912 2 49
305$	Ends with 305	89 611 305305 42 30519 1305 6666:305
.5	Includes any one character followed by the numeral 5	89 611 3533 252 12 998 600:500
1.9	Includes a sequence of three characters, where the first character is numeral 1 and the third character is numeral 9	179 35 2433 252 129 48 2129 14600:2129 321:94
.*	Includes any character; matches all AS paths and community lists
42*	Includes a number that has a numeral 4 followed by zero or more instances of the numeral 2	67 42 51314 33 252 422 483142 4 339 7831422
1(37)*	Includes a sequence that has a numeral 1 followed by zero or more instances of the pattern 37	137 42 211373737 29 4 1 but not 4 3737 78
42+	Includes a number that has a numeral 4 immediately followed by one or more instances of the numeral 2	67 42 2133 252 422 48 but not 4 329 78
1(37)+	Includes a sequence that has a numeral 1 immediately followed by one or more instances of the pattern 37	1373737 29 44 37137 78 137 42 21 but not 4 372 2121 37 5 1 456 881
42?	Includes a number that has a numeral 4 followed by zero or only one instance of the numeral 2	67 42 714 359 78 but not 33 252 422 48
1(37)?	Includes a sequence that has a numeral 1 followed by zero or only one instance of the pattern 37	137 42 2153 612 49 1 but not 4 13737 78
7..	Includes a sequence of three characters, where the first character is numeral 7	600 700 10025 7771 In the following examples, the three characters are 7, space, 8: 307 800 6127 888 999
^7..	Includes a number in the range 700 – 799	6127 723 999 700 100 600 but not 25 7771307 800
^7..$	Consists only of a number in the range 700 – 799	723 700 but not 25 7771307 800 6127 723 999700 100 600
[621]	Includes any of the numerals 6, 2, or 1	60 4334 545 92 200710 86 53 The regular expression [162] has the same results.
[0-9]	Includes any number in the range 0–9
^\(22 431\)	(AS-path attribute only) Begins with the AS-confed-set or AS-confed-seq (22 431)	(22 431) 102(22 431) 55 76 but not 43 (22 431) 522 431 59
{41 19}	(AS-path attribute only) Includes the AS-set or AS-seq {41 19}	{41 19} 53 76 {41 19} 17 255 {41 19} but not 3 41 19 41 19 532
101 102 | 103 105	Includes either sequence 101 102 or sequence 103 105	43 101 102 5103 105 22 but not 19 102 101102 103
_200_	Includes the number 200 (as opposed to the pattern consisting of numeral 2, numeral 0, numeral 0) Our implementation of regular expressions is not literal. Substring matching is enabled by default. Specifying 200 (no underscores) results in a match on 200 and on 2005. The underscore metacharacter disables substring matching.	33 200 422 48^200$ ^200 500$ but not 33 20 422 48 51 2005

 

 

Extended Community Lists

The router supports the BGP extended community attribute defined in
Internet draft BGP Extended Communities Attribute— draft-ietf-idr-bgp-ext-communities-07.txt (February 2004 expiration). This attribute enables the definition of a type of IP extended community and extended community list unrelated to the community list that uses regular expressions.

Note: IETF drafts are valid for only six months from the date of issuance. They must be considered as works in progress. For the latest drafts, please see the IETF Web site at http://www.ietf.org.

BGP devices can use the extended community attribute to control routes much like they use the community attribute to determine routes that they accept, reject, or redistribute. A BGP device can append the extended community attribute to a route that does not have the attribute before it advertises the route. For routes that do have the attribute, BGP can modify the attribute.

ip extcommunity-list

• Use to create an extended community list for BGP and control access to it.
• A route can belong to any number of communities, so an extended community list can have many entries comprising many communities.
• You can specify one or more community values when you create an extended community list. A clause in a route map that includes a list that has more than one value matches only a route that has all of the values; that is, the multiple values are logical ANDed.
• Use the rt keyword to specify a route target community, which consists of one or more routers that can receive a set of routes advertised by BGP that carry the extended community attribute.
• Use the soo keyword to specify a site-of-origin community, which consists of one or more routers that inject into BGP a set of routes that carry the extended community attribute.
• Example
  

  host1(config)#ip extcommunity-list boston1 permit rt 100:2 rt 100:3 rt 100:4

  host1(config)#route-map marengo permit 10

  host1(config-route-map)#match extcommunity boston1

  
  

  A route matches this community list only if it belongs to at least all three communities in extended community list boston1: communities 100:2, 100:3, and 100:4.
  


• Use the no version to remove a single extended community list entry if you specify the permit or deny keyword and a path expression. Otherwise, the router removes the entire community list.


• See ip extcommunity-list.

match extcommunity

• Use to match an extended community list in a route map.
• You can specify one or more extended community list names in a match clause. If you specify more than one extended community list, the lists are logically ORed.
• Example
  

  host1(config-route-map)#match extcommunity topeka10

  
  



• Use the no version to remove the match clause from a route map or a specified value from the match clause.


• See match extcommunity.

set extcommunity

• Use to set the extended community attributes in a route map for BGP updates.
• Use the rt keyword to specify a route target community, which consists of one or more routers that can receive a set of routes advertised by BGP that carry the extended community attribute.
• Use the soo keyword to specify a site-of-origin community, which consists of one or more routers that inject into BGP a set of routes that carry the extended community attribute.
• You can specify both a route target community and a site-of-origin community at the same time in a set clause without them overwriting each other.
• Example
  

  host1(config)#route-map 1

  host1(config-route-map)#set extcommunity rt 10.10.10.2:325

  
  



• Use the no version to remove the set clause from the route map.


• See set extcommunity.

show ip extcommunity-list

• Use to display information about a specific extended community list or all extended community lists.
• Example

  host1#show ip extcommunity-list
  IP Extended Community List dresden1:
      permit soo 10.10.10.10:15
  IP Extended Community List bonn:
      deny rt 12:12 

• See show ip extcommunity-list.

Community Lists

A community is a logical group of prefixes that share some common attribute. Community members can reside on different networks and in different autonomous systems. BGP enables 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 the routing information that a BGP device can accept, prefer, or distribute to other neighbors according to community membership. When a route is learned, advertised, or redistributed, a BGP device 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 are predefined. Table 5 describes how a BGP device handles a route based on the setting of its community attribute.

Table 5: Action Based on Well-Known Community Membership

Well-Known Community	BGP Device Action
no-export	Does not advertise the route beyond the BGP confederation boundary
no-advertise	Does not advertise the route to any peers, IBGP, or EBGP
local-as (also known as no-export-subconfed)	Does not advertise the route to any external peers
internet	Advertises this route to the Internet community; by default, all prefixes are members of the Internet community

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 could be expressed as 23:411. Use the ip bgp-community new-format command to specify that the show commands display communities in this format. You can also use a regular expression to specify the community attribute.

Use the set community command in route maps to configure the community attributes. You can add one or more communities to the attribute, or you can use the list keyword to add a list of communities to the attribute. 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.

A community list is a sequential collection of permit and deny conditions. Each condition describes the community number to be matched. If you issued the ip bgp-community new-format command, the community number is in AA:NN format; otherwise, it is in decimal format (the hexadecimal octets converted to decimal).

The router tests the community attribute of a route against each condition in a community list. The first match determines whether the router accepts (the route is permitted) or rejects (the route is denied) a route that has the specified community. Because the router stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the router rejects the route.

Consider the network structure shown in Figure 5.

Figure 5: Community Lists

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. The following example configures 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-router)#exit

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)#exit

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)#exit

host1(config)#route-map commtrc permit 3

host1(config-route-map)#match community 3

host1(config-route-map)#set metric 85

host1(config-route-map)#exit

host1(config)#ip community-list 1 permit 25

host1(config)#ip community-list 2 permit 62

host1(config)#ip community-list 3 permit internet

Community list 1 comprises routes with a community of 25; their metric is set to 20. Community list 2 comprises routes with a community of 62; their metric is set to 75. Community 3 catches all remaining routes by matching the Internet community; their metric is set to 85.

ip bgp-community new-format

• Use to specify that communities must be displayed in AA:NN format, where AA is a number that identifies the autonomous system and NN is a number that identifies the community within the autonomous system.
• Example
  
  

  host1(config)#ip bgp-community new-format

  
  

  
  
  
  


• Use the no version to restore the default display.




• See ip bgp-community new-format.

ip community-list

• Use to create a community list for BGP and control access to it.
• The list name can be up to 32 characters long.
• A route can belong to any number of communities, so a community list can have many entries comprising many communities.
• You can specify one or more community values when you create a community list. A clause in a route map that includes a list that has more than one value matches only a route that has all of the values; that is, the multiple values are logical ANDed.
• You can specify community values with a number or a regular expression.
• Example
  
  

  host1(config)#ip community-list 1 permit 100:2 100:3 100:4

  host1(config)#route-map marengo permit 10

  host1(config-route-map)#match community 1

  
  

  A route matches this community list only if it belongs to at least all three communities in community list 1: communities 100:2, 100:3, and 100:4.
  
  
  
  
  


• Use the no version to remove the specified community list, including all list entries.




• See ip community-list.

neighbor send-community

• Use to specify that a community attribute be sent to a BGP neighbor.
• If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group inherit the characteristic configured with this command.
• Example
  
  

  host1:vr1(config-router)#neighbor 192.3.4.5 send-community standard

  
  

  
  
  
  


• Use the no version to specify that common attributes not be sent to a BGP neighbor.




• See neighbor send-community.

set community

• Use to set the community attribute in BGP updates.
• You can specify a community list number in the range 1–4294967295, or in the new community format of AA:NN, or you can specify one of the following well-known communities:
  
  • local-as—Prevents advertisement outside the local AS
  • no-advertise—Prevents advertisement to any peer
  • no-export—Prevents advertisement beyond the BGP confederation boundary
  
  
• Alternatively, you can use the list keyword to specify the name of a community list that you previously created with the ip community-list command.
• You can use this command with inbound, outbound, and redistribution route maps.
• Use the none keyword to remove the community attribute from a route.
• Example
  
  

  host1(config)#route-map 1

  host1(config-route-map)#set community no-advertise

  
  

  
  
  
  


• Use the no version to remove the set clause from a route map.




• See set community.