I appreciate your thoroughness and your clarity in your descriptions! Yes, you are indeed correct that we need both route tagging and a change in the AD to make this happen. However, you must keep in mind that the route tagging and the change in AD resolve two different issues.
Tagging and implementing the route maps will make sure that a route that was originally advertised in routing domain A is not readvertised back into routing domain A via another routing protocol in routing domain B. You have achieved this, and it has been verified that after applying the tags, R3 uses the correct next-hop IP to reach the destination.
This does indeed introduce the routing loop on the OSPF side, and this must be resolved as you described.
Now the key to the question that you are very correctly asking is, why donât we simply change the AD and be done with it? Well, imagine you change the AD, and you add another network, say 8.8.8.8 at router B in the OSPF domain. This network would be redistributed into RIP, but due to the change in AD, it would be re-redistributed back into OSPF, resulting in the same problem, but from the other side.
So you could simply use a change in AD to resolve the specific issue of the specific topology, but any networks shared in the other direction will experience the same type of loop. So you need a combination of both tagging and a change in AD to resolve the issue.
Ah yes, I followed the ENARSI topology at first, which uses EIGRP instead of RIP. So the reverse problem does not occur in that case if you configure external EIGRP routes with a distance lower then the one from OSPF but still higher then internal EIGRP. And that is only IF external EIGRP routes are redistributed. But as RIP only has type and thus one AD, so lowering it below the AD of OSPF will only reverse the problem if route redistribution is also performed in the other direction.
Thank you for the extra example. Now I see why changing the AD only works for everything in my specific example.
Thank you for the explanation, but I donât understand why you specified TAG when re-distributing OSPF into RIP ? I agree your move in specifying TAG when you re-distribute RIP into OSPF, as other router can see the TAG. However, router running RIP only cannot see the tag in show ip route 1.0.0.0.
R1(config)#router rip
R1(config-router)#redistribute ospf 1 metric 5 route-map TAG
Thank you for the explanation, but I donât understand why you specified TAG when re-distributing OSPF into RIP ? I agree your move in specifying TAG when you re-distribute RIP into OSPF, as other router can see the TAG. However, router running RIP only cannot see the tag in show ip route 1.0.0.0.
R1(config)#router rip
R1(config-router)#redistribute ospf 1 metric 5 route-map TAG
Youâll notice that the route map does two things. In statement 10, it will look for a tag, and if it is found, it will match it. Second, if statement 10 doesnât find a tag, it will go to statement 20 and will set a tag on the route.
This means that the route map can be used to both tag untagged routes, as well as match tagged routes.
So in this particular case, when the 1.1.1.0/24 route is redistributed from OSPF to RIP since it doesnât originally have a tag, it will be tagged using statement 10 in the route map and redistributed into RIP. Now if that route is redistributed back into OSPF, it will already have a tag, so the route map will match statement 10, and will deny it, thus preventing it from being re-redistributed.
So the route map actually does both tagging of untagged routes and denying of tagged routes, and this is why it is applied in both directions.
I think understanding of how route tagging works is not complete without defining where it is applicable. At least if the goal is some practical application. The way it works seems depends on protocols used with ultimate restriction in BGP where it simply does not work at all. Considering how often we need in practical applications redistribute routes between protocols, the study of tags usefulness in case redistributions seems would be very important. The obvious question, for instance, how tagged routes in OSPF would work when they need to be redistributed into BGP? All bets (pardon, tags) are off then? Its all messed up now? Set tag is not supported but worse, match tag is not supported, either. So how would it be handled then?
Route tagging is only useful when used between two IGP routing domains. The practical application is to prevent the âre-redistributionâ of a route back into the routing domain that originated it. BGP however, does not support tags, because tags are not a BGP attribute, so there is no field in the BGP header to accommodate tags.
Actually, BGP doesnât need tags because the purpose of redistribution from an IGP to BGP is to allow BGP to learn and advertise networks internal to the local AS. Those learned networks are then advertised to other ASes via eBGP. Now if BGP attempts to advertise those networks back to their originating AS, there are already built-in loop prevention mechanisms, and in particular, the AS_PATH check that will prevent this from happening before it ever reaches redistribution. Specifically, an eBGP router will not accept a prefix that contains its own AS in the AS_PATH.
In addition, BGP and IGPs coexist within the same AS, thus you donât have a situation that is described by this diagram in the lesson:
where each routing protocol has a separate domain. But because IGPs operate like this, such a diagram makes sense.
However, if you want to implement something similar to route tagging using BGP, then you can use communities to carry information about prefixes, and you can act upon those communities using route-maps.
The tag keyword is part of a feature known as route tagging. Route tagging is used in conjunction with redistribution between routing protocols, especially in an environment where the two routing domains have more than one path between them, just like in the following diagram:
In such a situation, the network 1.1.1.0/24 may be redistributed at R2 from routing protocol A into routing protocol B. But then it may be re-redistributed from routing protocol B back to routing protocol A via R1. This can cause a routing loop. So tagging is used in such situations to prevent this from happening. Take a look at this lesson on route tagging, and if you have any further questions, let us know.
Same with OSPF, it has its own network (192.168.2.0/24) which is not getting redistributed back from OSPF - EIGRP - OSPF.
So how exactly do these loops even work? Why is it that with OSPF and EIGRP, the routes are not getting redistributed back into them, while they do with RIP?
This is a great experiment to determine how these routing protocols behave when there is more than one entry point between multiple routing domains.
Let me say first of all that a routing loop is not necessarily present simply because there are two entries in the routing table. Yes, in your first scenario, R1 sees a valid route to the 192.168.1.0/24 network via R5 as well as R2. A routing loop will only be confirmed if you take a look at the routing tables of all routers in the alleged loop and see that they route to each other.
For example, for the 192.168.1.0/24 destination,
if R1 routes traffic to R2,
and R2 routes this traffic to R4,
and if R4 routes this traffic to R3,
and if R3 routes this traffic back to R1,
âŚonly then will you confirm a routing loop.
Having said that however, what you see in the routing table of R1 would be considered sub optimal routing at best.
This depends upon the metric of the route learned from R3. Remember, RIP will only install routes of equal cost. R1 may have received the route from R3, but the metric may be higher for some reason, and it was not installed. You can use debugs or packet captures to determine if such RIP updates were sent from R3.
Again, the fact that you see only one next hop doesnât mean that the destination wasnât re-redistributed into the EIGRP domain. It simply means that the metric was not the same, so it was not installed in the routing table.
