The following are the most common mistakes that will be performed by the candiates who are doing CCIE Perperation-- These can 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 subnet 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.
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.
Try avoiding unpredictable traffic flows is simple: If you're thinking about tweaking the EIGRP metrics, 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.
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 subnet 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.
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.
Try avoiding unpredictable traffic flows is simple: If you're thinking about tweaking the EIGRP metrics, 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.
No comments:
Post a Comment