When you get into mutually redistributing routes (routes from protocol A into protocol B and vice-versa) with multiple routers, you run the risk of redistributing an already redistributed route. Thus the router may prefer a route because of administrative distance, and not because of route metrics. This can lead to route inefficiency, and at the worst of it, routing loops as traffic a redistribution boundary can loop back to itself. (Try this at 2am on your core network sometime. For fun. It’s a barrel of laughs, let me tell you.)
There are several techniques for dealing with these challenges.
- You can set the administrative distance on redistributed routes.
- The idea here is to assign an artificial AD to a redistributed route, such that it will not trump the route that may be learned natively. So if you were redistributing routes from EIGRP into OSPF, you could set the AD of the redistributed routes to 120, so that they would be higher than the 110 they would be normally when landing in the OSPF world.
- The “distance” command allows you to set the AD for external routes, either on all external routes, or on selected routes.
- “distance ospf external 180” would set an AD of 180 on all routes OSPF learned externally, i.e. were redistributed.
- “distance 185 18.104.22.168 255.255.255.0 tweak-ad” would set an AD of 185 on routes learned from router 22.214.171.124 with a mask of /24, assuming those routes were matched by the access list tweak-ad.
- You can use route tags as a way to identify routes that should be filtered.
- A tag is simply an empty 16 or 32 bit field in a route you can stick a number into. (At least, for routing protocols that support route tags.)
- The tags have no special meaning to the routing protocol itself. The routing protocol will pass along the tag you’ve set, but won’t inherently behave differently because of the presence or absence of the route tag.
- Therefore, you can tag a route as it’s redistributed with a value, let’s say 666. Then you can have other routers that redistribute from the same remote AS filter incoming routes tagged with 666. In this way, they won’t converge on a lousy route just because of a more desirable AD.
- The danger with this approach is that route filtering via tag will filter that tagged route no matter what. Ergo, if the route you just filtered because of the 666 tag happens to be the only remaining way to get to a remote network, you’ll be out of luck. The router filtering the 666 routes can’t converge on them. In that sense, tweak AD with the distance command may be a more elegant solution.
- You can tweak route metrics.
- The point here is that protocols like OSPF can make routing decisions based on rules other than metric. OSPF will always prefer an intra-area route over an inter-area route. In this case, you may find it desirable to set a metric from E1 to E2 or vice-versa to influence convergence to your liking.