Advertising Routes

A BGP router can advertise or receive updates from its BGP peer only if it has achieved the Established state with its neighbor. A router running BGP will advertise only a prefix to other neighbors that it is going to use in its routing table. Such a prefix is called the best path (defined later in the chapter). A rule similar to the split-horizon works in BGP as well. A prefix learned from a neighbor will not be advertised back to that neighbor if that was the best route.

Cisco IOS Software offers multiple ways to advertise prefixes in BGP. One rule that BGP follows when advertising prefixes to other neighbors is that the prefix being advertised must exist in the routing table of the advertising router.

In Figure 14-7, R1 advertises 131.108.1.0/24 through BGP to its BGP peer, R2.

Figure 14-7. Route Advertisement

In Cisco IOS Software BGP, there are three ways to advertise the prefix:

• Using the network statement ‚ As with other routing protocols, this is the first option. The following configuration advertises 131.108.1.0/24 through the network statement in R1:

    router bgp 109   network 131.108.1.0 mask 255.255.255.0  

  131.108.1.0/24 must exist in the routing table of R1; otherwise , 131.108.1.0/24 will not be advertised in BGP. The mask keyword followed by the actual mask of the prefix is needed when subnetted routes are being advertised.

• Using the redistribute command ‚ If 131.108.1.0/24 is a connected route in R1's routing table, the following configuration will advertise 131.108.1.0/24 in BGP:

    router bgp 109   redistribute connected   no auto-summary  

  With this configuration, all the connected routes, including 131.108.1.0/24, are advertised. To allow only 131.108.1.0/24 to advertise, BGP must use the filtering mechanism explained later in this chapter. Command no auto-summary is used because BGPs by default advertises redistributed routes to their natural Classful mask. For example, 131.108.1.0/24 being a Class B prefix would go as 131.108.0.0/16 without this command.

• Using the aggregate statement ‚ Prefixes are aggregated or summarized to reduce the number of prefix announcements and reduce the size of the routing table. The Cisco IOS Software aggregate feature in BGP announces summarized routes.

  If more specific routes of 131.108.1.0/24 are present in the BGP table ‚ for example, 131.108.1.128/26 ‚ the following configuration advertises 131.108.1.0/24 in BGP:

    R1#:   router bgp 109   aggregate-address 131.108.1.0 255.255.255.0  

You need to understand two important rules for the setup shown in Figure 14-8:

• Rule 1 ‚ Aggregation or summarization of subnets can happen only if those subnet exist in BGP table.

• Rule 2 ‚ For the aggregated (summarized) route, Cisco IOS installs an IP route with the next hop to Null0 in the IP routing table. This is done to insure that a valid route exists in the routing table to annouce it to other BGP peers.

Figure 14-8. Demonstrating the Rules for Aggregated Routes/Summarized Subnets

As Figure 14-8 illustrates, per Rule 1, R1 has 131.108.1.128/25 and 131.108.1.192/26 in its BGP table, but it is configured to advertise 131.108.1.0/24 to R2.

For Rule 2, when the aggregate-address command is used, Cisco IOS Software automatically installs 131.108.1.0/24 with a next-hop interface of NULL0 in its routing table. The output in Example 14-2 illustrates that R1 is configured to advertise 131.108.1.128/25 and 131.108.1.192/26. R1 is also generating an aggregate of 131.108.1.0/24. The first portion displays the BGP table to show that all three routes, including the aggregate, are in the BGP table. The second portion shows the detailed display of the aggregated route in R1. The third portion indicates that Cisco IOS Software automatically installs a Null0 route for the aggregate statement.

Example 14-2 Configuration and Output for Setup in Figure 14-8

 R1#: router bgp 1  network 131.108.1.192 mask 255.255.255.192  network 131.108.1.128 mask 255.255.255.128  aggregate-address 131.108.1.0 255.255.255.0 R1#show ip bgp BGP table version is 5, local router ID is 1.1.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 *> 131.108.1.0/24   0.0.0.0                           32768 i *> 131.108.1.128/25 0.0.0.0               0           32768 i *> 131.108.1.192/26 0.0.0.0               0           32768 i _____________________________________________________________________________________ R1#show ip bgp 131.108.1.0 255.255.255.0 BGP routing table entry for 131.108.1.0/24, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) Local, (aggregated by 1 1.1.1.1) 0.0.0.0 from 0.0.0.0 (1.1.1.1) Origin IGP, localpref 100, weight 32768, valid,  aggregated  , local, atomic-aggregate,         best _____________________________________________________________________________________ R1#show ip route 131.108.1.0 Routing entry for 131.108.1.0/25   Known via "static", distance 1, metric 0 (connected)   Routing Descriptor Blocks:   *  directly connected, via Null0  Route metric is 0, traffic share count is 1 

Null0 is a bit bucket and will not cause any harm for the data traffic because data traffic is switched based on more specific /25 and /26 routes, not this /24 NULL 0 route.

With the aggregate-address command in Cisco IOS Software, BGP advertises the aggregate and the subnetted routes as well. Cisco IOS allows a knob in configuration that will suppress these subnetted routes; only the aggregated prefix will be announced:

 R1#  router bgp 1   aggregate-address 131.108.1.0 255.255.255.0    summary-only   

Synchronization Rule

This rule in RFC 1771 states that the IGP routing table must be synchronized with the IBGP routing table. This can happen only if EBGP-learned routes are redistributed in IGP (OSPF) as the ASBR. The potential of black-holing traffic exists if IGP is not synchronized with IBGP-learned routes.

Figure 14-9 shows how synchronization rule can black-hole traffic. R2, R3, and R4 are in AS 110 running IBGP and also OSPF. R1 in AS 109 advertises prefix 131.108.1.0/24 through EBGP to R2, which advertises this prefix to R3 and R4; and R4 advertises to its EBGP neighbor R5.

Figure 14-9. Network Traffic Susceptible to Black-Holing

Assume that all the routers except R3 have processed this BGP update and have installed the route for 131.108.1.0/24 in their routing tables. If sources behind R5 start sending traffic to 131.108.1.0/24, packets arrive at R4, and the R4 routing table might report that the next hop to reach 131.108.1.0/24 is through R3. As a result, data traffic arrives at R3 and is dropped because R3 is still processing the update and does not have the route to reach 131.108.1.0/24. This is called transient black-holing of traffic. Over time, R3 will have the route and will be capable of passing traffic for 131.108.1.0/24. By the RFC 1771 synchronization rule, R5 should have waited until its IGP (OSPF) would have also received the route for 131.108.1.0/24; then it could have advertised the route to external peer R5 to attract traffic.

Announcing all EBGP routes in IGP requires manual redistribution at ASBR (R1) in this example. R1 must redistribute 131.108.1.0/24 in OSPF so that all routers in AS 110 definitely receive the prefix. However, with the size of Internet routing tables today, it is not possible or scalable to redistribute a full Internet feed into IGP. Therefore, all BGP speakers running Cisco IOS Software turn off synchronization using the following command:

 R2#  router bgp 110   no Sysnchronization  

Transient black-holing can still happen, but by turning off synchronization, IGP is not required to carry full BGP routes. In cases where some routers are not running BGP and they are in transit path of the IBGP neighbor, synchronization cannot be turned off and BGP must be redistributed in the IGP.