One possible side effect of this is that the customer will experience some short outages even if his routes become stable. In figure 9-3, route R2 in the customer network is flapping. When the customer's ISP is running route dampening, R2 will be penalized and suppressed according to its level of oscillation. R2 could be dampened for minutes. Even if R2 stops oscillating, the penalty it had accumulated still might be far above the reuse limit, and it has to be decayed before the route can be used. In the meantime, some poor soul on the customer's network is pulling out his or her hair trying to figure out why some subnets are not reachable from the outside world. If administrators are unaware that their routes are being dampened, they might try to remedy the situation by some other means, which makes their routes flap even more and become more penalized. The better approach is to check with the provider on whether he is receiving the routes, and if he is, why they are not being advertised. Providers have strict policies and might not change the dampening behavior per the customer's request.

Figure 9-3  Route dampening ISP environment.

What the provider can do is "flush" the history information of the routes being dampened to advertise the route. This is, of course, under the condition that the customer will investigate the routing problems causing the routes to fluctuate.

On the other hand, instabilities can be caused by the providers themselves, and the effect can be much larger. If a link carrying full routes between a provider and customer or a provider and another provider oscillates, the border routers will feel the impact.

Suppose that you are getting full Internet routes (about 42,000 routes in 1996) from multiple providers. Now imagine that five percent of theses routes (about 2,100 routes) are toggling every two minutes. Your border router will be unable to handle this load.

Without route dampening, it will be difficult to determine what is really happening. All you know is that the process utilization on your border router is increasing rapidly. With route dampening, all the unstable routes will generate a history entry that shows the level of stability of the routes. After the unstable routes are identified, it is easy to determine where they are coming from by looking at the next hop address. Although route dampening in this case did not help solve the problem, it helped identify who is causing the problem. After you identify the culprit, you can temporarily remove your BGP session with the ISP at fault. Pick up the phone, call the ISP, and start complaining.

In conclusion, route instabilities in the Internet will affect everybody one way or the other. It is everyone's responsibility to minimize route oscillation by being more aware of the things we do and why we do them. Providers are becoming more tough on culprits; there is even talk about charging an additional fee per route flap. This might sound like overkill, but it is getting harder and harder to get the Internet under control. Having a "routing patrol" issue tickets whenever someone breaks the rules may become necessary.

Looking Ahead

We have talked enough about architectures and routing behaviors. For the reader who wants to put things into perspective by learning actual routing implementations, the best is yet to come. The following chapters touch upon key designs and architectures already discussed in the book by presenting actual configuration by using the Cisco IOS software language.

The configuration examples are accompanied by complete explanations on why a certain action is taken and what outcome results from it. Actual displays are taken from Cisco routers to point out multiple BGP attributes and how the configuration has affected the routing tables. By going through the examples in the next two chapters, we hope that you will achieve a high-level of expertise in integrating your networks in the global Internet.