Unstable Routes

Injecting the IGPs in BGP dynamically or semidynamically results in the dependency of the BGP routes on the IGP routes. Although you could argue that this is good because it reflects the actual status of networks, it can have drawbacks as well. Remember that with today's global network connectivity, route fluctuation within your AS will affect your provider if you are a customer or other providers if you are a provider. The IGP route you advertise will translate into a BGP route. If that route goes down, a WITHDRAWN message will be sent via BGP requesting peers to remove that route from their tables. A route constantly going up and down in your AS has the effect of being constantly sent and withdrawn by other ASs. The example of one fluctuating route is very simplistic; imagine having hundreds of these routes fluctuating in hundreds of ASs. Internet stability will be affected very negatively.

Strict measures are being put in place to try to mitigate the effect of route fluctuation on the Internet. As you will see in Chapter 9, "Designing Stable Internets," by a process called route dampening, fluctuating routes are penalized and stopped from being advertised depending on their degree of instability. Your routes might be "held hostage" for minutes and hours—until they stabilize—by an interconnected provider.

Controlling route instability is not an easy matter because it usually depends on factors that are beyond your control. Such factors could be instable access links or faulty hardware. One way to minimize route instability is aggregation. When the aggregate represents more than one route, the fluctuation of any single route does not cause fluctuation in the aggregate itself. Aggregation could be done on the customer boundary or the provider boundary, depending on the level of information exchanged between the customer and the provider. If done on the customer boundary, this would alleviate the provider from seeing the fluctuations of individual customer routes. If aggregation is done on the provider boundary, then the customer fluctuation would leak to the provider but will not be propagated to the Internet. BGP4 aggregation is discussed at the end of this chapter after you have acquired enough techniques in BGP tuning.

Another way of controlling route instability is to decouple route advertisement from the existence of the route itself. This is called static injection of routes into BGP, as described in the following section.

Injecting Information Statically into BGP

Today, injecting information statically into BGP has proven to be the most effective in ensuring route stability. Of course, this method also has drawbacks.

To statically inject information into BGP, IGP routes (or aggregates) that need to be advertised to other peers are manually defined as static routes. This ensures that these routes will never disappear from the IP routing table and hence will always be advertised. Because administrators are often uncomfortable advertising routes to networks that might be down or unreachable, the appropriateness of injecting information statically depends on the particular situation.

---

Troubleshooting:  
Example: Ch. 10, pp. 323-324. Injecting Information Statically into BGP

---

If, for example, the route is advertised to the Internet from a single point, then advertising a route that is actually down is not a big issue. Hosts trying to access that destination will fail irrespective of whether the route is advertised.

On the other hand, if a route is advertised to the Internet from multiple points, then advertising the route statically at all times might end up black-holing the traffic. If problems inside the AS prevent the border router from being able to reach the network it is advertising, traffic to that destination will be dropped even though it could have been reached from some other entry point.

The actual advertisement of the static route can be done with either of the methods described in the "Injecting Information Dynamically into BGP" section. Advertisement can be done by redistributing all the static routes via the redistribute command or a subset of the static routes via the network command. The latter method enables a more controlled route injection because redistribution might cause some unwanted static routes to be sent via BGP.

ORIGIN of Routes

BGP considers the networks advertised via the network command or via aggregation as being internal to the AS and will include the ORIGIN attribute in each route as being IGP (i). On the other hand, whenever a route is injected into BGP via redistribution (whether statically or dynamically), the ORIGIN of the route will be INCOMPLETE because the redistributed routes could have come from anywhere.

Figure 5-6 illustrates these issues. In Scenario 1, all networks have been listed under the BGP process via the network command. Note that BGP has considered 10.0.0.0 and 11.0.0.0 as having a known origin of IGP. Network 12.0.0.0 is the only network that is not known to the router (does not exist in the IP routing table). As you can see, 12.0.0.0 is not being advertised via BGP, even though it has been listed via the network command.

Figure 5-6  Behavior comparison for the ORIGIN attribute.

In Scenario 2, networks 10.0.0.0, 11.0.0.0, and 12.0.0.0 have been statically defined. Network 11.0.0.0 has also been defined via the network command. Finally, network 13.0.0.0 is learned dynamically by the router via IGP. All these networks have been injected into BGP via redistribution. As a result, networks 10.0.0.0, 12.0.0.0, and 13.0.0.0 have been advertised with an ORIGIN of INCOMPLETE because these networks have been injected into BGP via redistribution.

Although network 11.0.0.0 has been injected via redistribution, it is also defined natively to BGP via the network command, which is why it will be sent out with an ORIGIN of IGP. If it had not been defined natively, it would have been sent out with an ORIGIN of INCOMPLETE. Actually, network 11.0.0.0 did not need to be redistributed because defining it statically and listing it via the network command would suffice to inject it into BGP.

Although the ORIGIN is immaterial at this point, it is used later on to favor one route over the other by the BGP decision process.