How to Troubleshoot Five Common Routing Errors

Troubleshoot Five Common Routing Errors

Finding these tiny routing errors in customer networks during an install or change window is, as you undoubtedly already know, one of the pleasures of working as a network reseller, consulting, or on projects.

Situations where a previous administrator made one of these mistakes and was unable to fix them are not uncommon; as a result, the administrator "fixed" the error by adding static routes or adjusting the protocol's administrative distance.

This creates a minefield in the network where changes you make don't propagate as expected, forcing you to locate and remove the "fix" and then track down and fix the underlying issue. However, you must exercise extreme caution in this situation, as your "fix" may introduce a deluge of new routes into the network, altering traffic patterns that users may not be aware of.

Error 1: Redistribution Filtering

In order to prevent route feedback and routeing loops, you must appropriately filter the routes before redistributing routeing. While it is usually a severe issue to apply filters at all, it is widespread to miss a path occasionally due to the administrative burden of managing the filters in a complicated and poorly summarised network.

Of course, avoiding redistribution altogether is the best way to prevent this. Redistribution is, in fact, nearly never a wise choice. Mutual redistribution is not permitted between friends.

Error 2: Inconsistencies Between Neighbour Parameters in OSPF

These OSPF routers must share a good number of parameters in order to form an adjacency. Area ID, mask, hello interval, router dead interval, authentication, and so forth are some examples of these. Deviant parameters frequently prevent adjacencies from forming because of fat fingers, non-standard configurations, or poorly typed passwords.

Typing errors are inevitable, but you can quickly find out if there is a problem with mismatched parameters by using the debug command for OSPF adjacencies. It is effortless to fix the configuration once you realise that.

Error 3: 'Subnets’

When redistributing routes into OSPF, it's common to discover that some need to be included. The most frequent cause of errors in redistribute commands is the accidental omission of the subnets keyword.

According to Cisco, "OSPF is directed to use the subnet keyword to redistribute all subnet routes. Only unsubmitted networks will be redistributed by OSPF in the absence of the subnet keyword." They ought to be aware.

Error 4: Metrics

The issue is nearly always that someone needs to remember to set the metrics if you're redistributing routes into EIGRP and discover they're all missing. Remarkably, Cisco turned down the chance to establish a default EIGRP route metric.

They leave that up to the administrator instead. (Never mind that if you have to set it, it's not really a 'default.') Therefore, routes will only be redistributed if you fix them. I believe this is retribution for choosing to use EIGRP and redistribute routes simultaneously.

Error 5: Changing EIGRP Measurements

Speaking of EIGRP metrics, administrators frequently find it difficult to refrain from adjusting them to make traffic favour one circuit over another. This is nearly always an attempt to send traffic over an Internet VPN rather than a frame-relay circuit with a low bandwidth.

The bandwidth and delay parameters appear to be relatively straightforward to implement; however, as administrators attempt to locate and incorporate all of their set metrics into the complex formula for the composite metric, they encounter difficulties that eventually lead to a nightmare.