Internet Routing Architectures (CISCO):Configuring Basic BGP Functions and Attributes

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

Table of Contents