Internet Routing Architectures, Second Edition
Looking Ahead
Mastering routing at the edges of your domain gives you full control over traffic into and out of your autonomous system. Another piece of the puzzle is how the traffic flows inside the AS before it gets out. Not all routers inside the AS run BGP. IGP-only routers usually do not carry a full list of Internet routes due to memory constraints. Running defaults inside the AS to reach external routes is one of the most common ways for internal routers to reach destinations outside the AS. With defaults comes the threat of routing loops if conflicting policies exist between your BGP and your IGP. The following chapter discusses these issues of how to make BGP policies flow hand-in-hand with IGP defaults. That chapter also discusses the use of policy routing in achieving total control over routing behaviors based on the sources of IP addresses rather than the traditional destination-based routing.
Frequently Asked Questions
Q—
I statically defined a default toward my provider by pointing toward a network I am learning via BGP. What happens if that network goes up and down?
A—
Your default will appear and disappear. That is why you should not point your default to a specific subnet. Always point to an aggregate or supernet, because they are less likely to flipflop.
Q—
I have the option of getting the 0/0 default via BGP or defining a static default. Which do you think is best?
A—
For the border router, both methods are the same as long as the aggregate you are pointing to is stable. On the other hand, after you receive the 0/0 via BGP, it will get flooded to all your IBGP peers, and there is a chance that you will end up sending it to your other EBGP peers. When you define the default statically, you will have better control.
Q—
My AS is connected to two providers, one in SF and one in NY. I want the traffic from and toward my SJ site to go in and out on the SF link. All other traffic should flow over the NY link. What do I need to do to achieve this behavior?
A—
Because there are two different providers, MEDs should be used. The only methods are AS path manipulation (or perhaps methods such as those proposed in RFC 1998) for inbound traffic and local preference manipulation for outbound traffic. For your inbound traffic toward San Jose, you can use the AS path manipulation technique to make your path longer for all SJ
page 214
Internet Routing Architectures, Second Edition
routes advertised on the NY link. The problem is with your outbound traffic. If you know exactly what networks the SJ users are trying to reach, you can give those destinations better local preference on the SF exit. If the SJ site needs to reach any destination, setting a better local preference on the SF link will cause all your outbound traffic to leave via the SF link. However, that doesn't meet your requirement for the NY link to carry all other traffic.
Another way of dealing with this scenario is policy routing, in which a router can track source addresses and direct traffic accordingly. This is described in Chapter 8, "Controlling Routing Inside the Autonomous System."
Q—
I am prepending AS numbers to my routes to tip the balance of my traffic. I am not seeing any effect. Why?
A—
Remember that your updates are exchanged by multiple providers. A provider along the way can use local preference to override your path length. Check with your provider.
Q—
Do I have to set BGP policies? Why can't I leave it to BGP to figure out the correct path?
A—
You do not have to set policies. Remember, though, that BGP is not taking into account the speed of your links and your user traffic requirements. If you are happy with your traffic pattern the way it is, you do not need to change any attributes.
References
1.RFC 826, "Address Resolution Protocol (ARP)," http://www.isi.edu/innotes/rfc826.txt
2.RFC 1998, "An Application of the BGP Community Attribute in Multi-home Routing," http://www.isi.edu/in-notes/rfc1998.txt
page 215
Internet Routing Architectures, Second Edition
Chapter 8. Controlling Routing Inside the
Autonomous System
This chapter covers the following key topics:
•Interaction of non-BGP routers with BGP routers— A brief overview of the methods by which non-BGP routers inside an AS can reach the outside world.
•Defaults inside the AS: primary/backup policy— Different methods by which to avoid potential loops when default routing inside an AS conflicts with the goal of providing a primary and a backup link to outside the AS.
•Defaults inside the AS: other BGP policies— An overview of routing policies other than primary/backup, which can lead to routing loops within the AS.
•Policy routing— A definition and sample of a method of controlling routes, based on traffic source IP addresses or source and destination IP addresses rather than destination only.
The preceding chapter focused on the interaction between different ASs and how BGP attributes can be manipulated to address symmetry, redundancy, and load balancing. The 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, perhaps with some leaf nodes running only Interior Gateway Protocols (IGPs). On the other hand, most customers have few routers running BGP, and the majority of their internal IGP routers default routing 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.
Interaction of Non-BGP Routers with BGP Routers
Non-BGP routers inside the AS can reach the outside world by using the following two methods:
•Injecting BGP into the IGP
•Following default routes inside the AS
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, perhaps in addition to a small number of exterior routes from other IGPs.
This does not mean that BGP routes should never be injected into IGPs. Depending on the number of BGP routes and how critical it is for them to be in the IGP, injecting partial BGP routes into IGP might be appropriate. If you follow this course, you should exercise caution to
page 216
Internet Routing Architectures, Second Edition
control routes leaked into the IGP. Discussing all the potential issues associated with BGP redistribution into IGPs is beyond the scope of this book. However, here are some things worthy of consideration: the amount of available memory, CPU resources available for calculating paths and processing routing updates, link utilization from routing control traffic, impact on convergence, IGP limitations, and network topology. All of these factors, and numerous others, should be considered.
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. For instance, if the IGP is classful (such as RIP-1 or Interior Gateway Routing Protocol [IGRP]), information about classless interdomain routing (CIDR) blocks will be lost. The other major problem is the potential for instability in the injected BGP routes, causing further instability of the IGP. Some major network meltdowns have been caused by IGPs failing due to fluctuations of a large number of external routes.
Following Defaults Inside an AS
The more practical solution for non-BGP routers inside the AS to reach the outside world is to follow defaults inside your AS to the closest exterior gateway 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. Each IGP router chooses the best path to an exterior destination based on the internal cost or metric to reach the default. After the traffic reaches the BGP routers, the traffic propagates according to how BGP has determined the best path. Figure 8-1 illustrates non-BGP routers inside an AS following defaults to reach the closest BGP router.
Figure 8-1. Example of Following Defaults
page 217