When I set about trying to determine the five most common routing issues I see, I didn't realize what a challenge it would be to narrow them down. I considered writing about the five most annoying routing errors but quickly realized all five would revolve around ISDN dial, and no one would want to read that. I eventually decided to eliminate all the host-based routing issues and focus on errors that involve routing protocols and that -- though not necessarily the most common -- are fairly common and easily avoided or resolved.
1. Filtering redistribution
When redistributing routing, you need to filter the routes properly to avoid routing loops and route feedback. Not applying filters at all is usually a significant problem, but managing the filters in a complex and poorly summarized network is such an administrative burden that missing a route here or there is extremely common. The best way to avoid this, of course, is not to do redistribution at all. In fact, it's almost always a bad decision. Friends don't let friends do mutual redistribution.
2. Mismatched neighbor parameters in OSPF
In order to form an adjacency, OSPF routers need to have quite a few parameters in common. These include authentication, area ID, mask, hello interval, router dead interval, and so on. As a result of fat fingers, nonstandard configurations or invalid passwords, deviant parameters will quite often prevent adjacencies from forming. Although it's hard to avoid typos, it's fairly easy to use the debug command for OSPF adjacencies, which will quickly let you know if mismatched parameters are a problem. Once you know that, it's trivial to correct the config.
3. 'subnets'
When redistributing routes into OSPF, it's fairly common to find several routes missing. The most common problem is that someone forgot to tack the "subnets" keyword to the end of the redistribute command. Cisco says, "The subnets keyword tells OSPF to redistribute all su...
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
bnet routes. Without the subnets keyword, only networks that are not subnetted will be redistributed by OSPF." They should know.
4. Metrics
If you're redistributing routes into EIGRP and find they're all missing, the problem is almost always that someone forgot to set the metrics. Oddly enough, Cisco declined the opportunity to set a default metric for EIGRP routes. Instead, they leave that up to the administrator. (Never mind the fact that it's not really a "default" if you have to set it....) Thus, if you don't set it, routes will not be redistributed. I suspect this is penance for making the decision to use EIGRP and do route redistribution at the same time.
To solve this problem, you must either set a default metric with the deceptively named "default-metric bandwidth delay reliability loading mtu" command -- and yes, you need to specify all of those -- or you can set the same parameters with the "metric" keyword as part of the redistribute command.
5. Tweaking EIGRP metrics
Speaking of EIGRP metrics, it's often hard for administrators to resist tweaking them in order to cause traffic to prefer one circuit over another. In my experience, this is almost always an attempt to send traffic over an Internet VPN instead of a low-bandwidth frame-relay circuit. The bandwidth and delay parameters just seem so simple to apply. Over time, though, all these tweaks add up to a little nightmare as administrators try to find all the metrics they've set and stuff them into the not-so-simple formula for the composite metric to determine how to get traffic to flow over the right circuit again.
My advice for avoiding unpredictable traffic flows is simple: If you're thinking about tweaking the EIGRP metrics, have a friend page you at 3 a.m. some night this week and give you the parameters to three paths through your network. Then, calculate the correct cost of each path and predict which will be preferred. If you get it right, and you enjoyed the exercise, then go ahead and make your changes.
About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
