Internet Routing Architectures (CISCO):Configuring Basic BGP Functions and Attributes Previous Table of Contents Next The Community Attribute This example shows how the community attribute can be used to dynamically influence the routing decisions of another AS. With the network illustrated in figure 10-9, the following configuration example shows how AS3 can advertise route 172.16.65.0/26 to AS1 and dynamically instruct AS1 not to advertise this route externally. AS3 will assign route 172.16.65.0/26 the community attribute "no-export" when advertising it to AS1. Figure 10-9  Setting the community attribute. Notes:  The send-community option in the neighbor router subcommand is used to cause the assigned community to be sent out. RTA configuration: router bgp 3 no synchronization network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0 neighbor 172.16.1.2 remote-as 3 neighbor 172.16.1.2 update-source Loopback0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 send-community neighbor 172.16.20.1 route-map SETCOMMUNITY out no auto-summary access-list 1 permit 172.16.65.0 0.0.0.63 route-map SETCOMMUNITY permit 10 match ip address 1 set community no-export route-map SETCOMMUNITY permit 20 The preceding RTA configuration shows that RTA has defined a route map SETCOMMUNITY toward neighbor 172.16.20.1 (RTC). Instance 10 of the the route map will match on prefix 172.16.65.0/26 and will set its community attribute to no-export. The send-community keyword assigned to the neighbor session is required to enable the community attribute to be sent to the specified neighbor. Instance 20 of the route map will enable all other networks to be passed with no change. RTC's BGP entry for 172.16.65.0/26 will show the following: RTC#sh ip bgp 172.16.65.0 255.255.255.192 BGP routing table entry for 172.16.65.0/26, version 3 Paths: (1 available, best #1, not advertised to EBGP peer) 3 172.16.20.2 from 172.16.20.2 (172.16.2.254) Origin IGP, metric 20, valid, external, best Community: no-export Note how the entry has been assigned the community no-export and instructions that it is not to be advertised to EBGP peers. RTC will not propagate this entry to its external peer RTD. Note that in the following RTD BGP table, RTD did not receive an update about 172.16.65.0/26. RTD#sh ip bgp BGP table version is 22, local router ID is 192.68.10.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 *> 172.16.1.0/24 192.68.6.2 0 1 3 i *> 172.16.10.0/24 192.68.6.2 0 1 3 i *> 172.16.220.0/24 192.68.6.2 0 1 3 i *> 192.68.10.0 0.0.0.0 0 32768 i *> 192.68.11.0 192.68.6.2 0 0 1 i BGP4 Aggregation The following examples demonstrate different methods of aggregation that are seen on the Internet. The way aggregates are formed and advertised and whether they carry with them more specific routes will influence traffic patterns and sizes of BGP routing tables. Remember that aggregation applies to routes that exist in the BGP routing table. An aggregate can be sent if at least one more specific route of that aggregate exists in the BGP table. Aggregate Only, Suppressing the More Specific This example shows how an aggregate can be generated without propagating any of the more specific routes that fall under the aggregate. In the network illustrated in figure 10-10, RTA is sending prefixes 172.16.220.0/24, 172.16.1.0/24, 172.16.10.0/24, and 172.16.65.0/26 toward RTC. The following configuration shows how RTA can aggregate all these routes into a single prefix 172.16.0.0/16 and send it to RTC. This of course assumes that AS3 is the sole owner of the class B 172.16.0.0/16. RTF is also doing the same aggregation on its end with a configuration similar to RTA. Figure 10-10  BGP aggregation (suppressing the specific routes). RTA configuration: router bgp 3 no synchronization network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0 aggregate-address 172.16.0.0 255.255.0.0 summary-only neighbor 172.16.1.2 remote-as 3 neighbor 172.16.1.2 update-source Loopback0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 filter-list 10 out no auto-summary ip as-path access-list 10 permit ^$ RTA's configuration uses the aggregate-address command to aggregate all the more specific routes of 172.16.0.0/16 into a single address. RTA's BGP table (illustrated in the show command output that follows) indicates that a new aggregate 172.16.0.0/16 has been originated by this router (next hop is 0.0.0.0), whereas all the more specific prefixes have been suppressed (note the "s" at the far left). In this case, the same result could have been achieved by using auto-summary. RTA#sh ip bgp BGP table version is 14, local router ID is 172.16.2.254 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 *> 172.16.0.0 0.0.0.0 32768 i * i 172.16.1.2 100 0 i s> 172.16.1.0/24 0.0.0.0 0 32768 i s> 172.16.10.0/24 172.16.1.2 20 32768 i s> 172.16.65.0/26 172.16.1.2 20 32768 i s> 172.16.220.0/24 0.0.0.0 0 32768 i * 192.68.10.0 172.16.20.1 0 1 2 i *>i 172.16.1.2 0 100 0 2 i *> 192.68.11.0 172.16.20.1 0 0 1 i Previous Table of Contents Next