Previous | Table of Contents | Next |
This chapter covers the following key topics:
The preceding chapter focused on the interaction between different ASs and how BGP attributes can be manipulated to address symmetry and load balancing. Our discussion concentrated on the behavior of the BGP border routers that connect the AS to other ASs.
ISPs usually have most of their routers running BGP, with some leaf nodes running IGP. On the other hand, most customers have few routers running BGP and the majority of their internal IGP routers running defaults toward the BGP routers. In these scenarios, it is important to have the BGP policies go hand-in-hand with routing inside the AS. Conflicting policies might result in routing loops if the AS's physical layout does not complement the logical layout. This chapter discusses the interaction of BGP routes with IGPs inside the AS and presents the options of controlling routes via policy routing.
Non-BGP routers inside the AS can reach the outside world by using the following two methods:
Injecting BGP into the IGP
Injecting full BGP routes into an IGP is not recommended. Doing so will add excessive routing overhead to any IGP. Interior routing protocols were never meant to handle more than the networks inside your AS, plus some exterior routes from other IGPs.
This does not mean that BGP routes should never be injected into IGPs. Depending on the number of the BGP routes and how critical the need for them to be in the IGP, injecting partial BGP routes into IGP may well be appropriate.
Injecting partial BGP routes into the IGP from specific points of the AS can help direct the corresponding outbound traffic toward specific exit points.Outbound traffic toward other Internet routes will still have to follow defaults toward the BGP routers. Although injecting BGP routes into the IGP seems like the optimal routing solution, it has its drawbacks. If, for instance, the IGP is classfull (such as RIP v1 or IGRP), information about CIDR blocks will be lost. The other major problem is the potential instabilities in the injected BGP routes causing instabilities in the IGP. Some major network meltdowns have occured because the fluctuations of a large number of external routes have caused IGPs to fail.
Following Defaults Inside an AS
The more practical solution is to follow defaults inside your AS to the closest router that can get you outside the AS. A default route can be injected into the AS from each autonomous system border router. Each IGP router might receive the default route from one or multiple routers. The IGP router chooses the best path based on the internal cost or metric to reach the default. After the traffic reaches the BGP routers, the traffic will propagate according to how BGP has picked the best path.
Troubleshooting: Ch. 11, pp. 399-418. Following Defaults Inside an AS
Figure 7-1 illustrates non-BGP routers inside an AS following defaults to reach the closest BGP router. RTC and RTD are BGP border routers that are injecting the default 0/0 inside AS1. RTB is an internal BGP transit router running a full IBGP mesh with RTC and RTD. Internal non-BGP routers, such as RTA, will receive the default from different directions and choose the default with the smallest IGP metric. In figure 7-1, RTA is receiving the 0/0 from RTB with a metric of 10, from RTE with a metric of 20 (10 + 10), and from RTF with a metric of 30 (10 + 10 + 10). RTA will prefer the default via its link to RTB because it has the lowest internal metric (10). After the traffic arrives at RTB, it follows the BGP routing table to reach destinations external to the AS.
Figure 7-1 Example of following defaults
Running IBGP inside an AS is an important element in helping to control how traffic exits the AS and to carry transit traffic in case there is a need to do so. Also, most of the symmetry techniques discussed in the preceding chapter cannot be applied if multiple BGP routers are not running IBGP.
Previous | Table of Contents | Next |