Route Tagging not enough?


(JAMES H) #1

Rene,

I have a question when it comes to route tagging.

When using route tagging for mutual redistribution with more than one point of redistribution, am I correct in saying that using route tagging should be used IN CONJUNCTION with methods to control administrative distance? E.g. when redistributing between OSPF and RIP, route tagging is used to prevent routing loops, by preventing routes from being redistributed back in to their original domain. This however, is not enough to prevent a router from accepting a RIP-originated route learned through OSPF, (110) over the RIP option (120). Some distance configuration would be required to remedy this.


(Lazaros Agapides) #2

Hello James

Route tagging alone should be enough to prevent a routing loop due to re-redistribution of a route back into the routing domain or AS from which it came. The solution is quite simple and elegant: If your router sees a tagged route it will not be redistributed. If it sees an untagged route, it will be redistributed and a tag will be set. No other configs should be necessary. Take a look at the following lesson about tagging.


Can you give a specific example of the scenario that you are presenting in your post?

I hope this has been helpful!

Laz


(JAMES H) #3

Hi Laz - thank you for the reply. I’m annoyed with myself, as redistribution is probably the single topic which has rattled me the most whilst preparing for the ROUTE exam. I’ve spent so long on it, and cannot believe I don’t have it down to CCIE level!!

The scenario which bothers me is redistribution between OSPF and RIP. I’ve attached the topology, along with the config for the redistribution routers (R1 and R2). I completely get what the tags are supposed to do, and that the route maps can deny a tag from being redistributed a second time. Even with the posted config, there is no way in which the routing table on R1 or R2 (dependent on where redistribution was configured first) both use the internal RIP networks of 13.13.13.0 or 23.23.23.0 to reach the RIP loopbacks. At least R1 or R2 will use sub-optimal routing (going through OSPF) to reach them. I can achieve the desired result by setting the OSPF external routes to use a value greater than 120.


(JAMES H) #4

Any thoughts Laz? Rene?


(Lazaros Agapides) #5

Hello James

Sorry about the late reply!!

Hmm, trying to get my head around that. Not sure I agree, but I may be off so I’ll talk through it. So with your configs as they are, R1 will receive information about the 10.0.0.0/22 subnets (all the loopbacks on R3) directly from R3 via RIP. R1 will potentially receive info about these loopbacks via OSPF from R4. BUT, R2 has been configured to add a tag of 120 to any routes learned via RIP that have been redistributed into OSPF. So these routes when they reach R1 via OSPF, will be tagged. But R1 is configured to deny any routes with a tag of 120. So it won’t redistribute them back to RIP, but it will place it in its own routing table… hmm I see. And since OSPF has a smaller AD than RIP, it will choose that instead… Yes, that means that by setting the OSPF external routes to have an AD of greater than 120, the router will prefer the RIP learned routes and send it correctly. I see now, and I was originally incorrect.

So this is a good exercise because it actually clarifies what tags are for. They ARE for the prevention of re-redistributing (yes two re’s) networks into a routing protocol AS that they originally came from thus avoiding routing loops. Tags DO NOT prevent the sub-optimal routing decisions similar to that described in your exercise. This must be dealt with by adjusting the AD of external OSPF routes as you very rightly mentioned.

I hope this was as helpful for you as it was for me!

Laz


(JAMES H) #6

Hi Laz,

Thanks for the reply. No probs on it being late!

That’s great then - my time has been well spent. I’ve lost count of how many articles approach route tagging with the intention of them being a ‘one-hit’ solution for all redistribution. What many fail to mention is that it should act as a supplement, and alone is not enough to prevent sub-optimal routing caused by AD differences. Thank you for clarifying.

James.