‚ < ‚ Free Open Study ‚ > ‚ |
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:
You need to understand two important rules for the setup shown in Figure 14-8:
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-8R1#: 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 RuleThis 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. |
‚ < ‚ Free Open Study ‚ > ‚ |