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.
I was reviewing some past lab configurations, and I noticed some differences between the examples provided here and those I have previously worked on. Below is an example
route-map eigrp-to-ospf deny 5
match tag 200
!
route-map eigrp-to-ospf permit 10
set tag 100
!
route-map ospf-to-eigrp deny 5
match tag 100
!
route-map ospf-to-eigrp permit 10
set tag 200
Could you please provide configuration lab examples that include OSPF and EIGRP for both routers?
The configuration in the lab deals with RIP and OSPF, but it will be much the same when you apply it to OSPF and EIGRP as well. In the lesson, the configuration uses a single route map that sets the tag to 1 before being redistributed, and denies redistribution if the tag is set.
In your case above, you have created two different route maps, one for each direction, and with different tag values for each case. In your case, you would apply the eigrp-to-ospf route map for redistribution from EIGRP to OSPF, and the ospf-to-eigrp route map for redistribution from OSPF into EIGRP.
The result will be the same as far as the operation of the actual redistribution goes. In your case, youâre using two different values for tags, whereas in the lab one value is used. Does that make sense?
I was just curious about why the same tag ID was being used. From my understanding, and please correct me if Iâm mistaken, we could theoretically use the same tag ID and apply it to both routing protocols when redistributingâsuch as in the case of EIGRP to OSPF and vice versa. However, would it be considered best practice to assign a unique tag ID for each instance?
You can use the same tag ID as was done in the lesson. This is because each tag exists only within the routing domain of each routing protocol. Take a look at this diagram:
Here you can see two different networks and how they are being tagged when redistributed into the other routing protocolâs domain. The tag ID of 1 remains constant throughout each domain. Now whether those values are the same or whether they are 1 and 2 for example, makes no difference from a functional point of view.
However, I would consider it best practice to use a different tag just for the sake of making it clearer which tag corresponds to which routing protocol. From an administrative point of view, it makes the configuration easier to manage.
I understand the concept and I know how to implement (or at least I think I do) but Iâm struggling to verify or see the difference before and after as I seem to be getting the same outcome from traceroute or ip routes (minus the tag being displayed in ip route 1.1.1.0 on both routers). For sanity checking, whatâs the best way I can verify that the implementation is actually working. Route-maps are not showing any packets so that isnât really helping.
The route tagging configuration cannot be verified directly using traceroute or ping. By applying route tags, you are simply adding some information to the route that has been advertised. The only way to verify that the config has been applied correctly is using the various show commands shown in the lesson.
Now I did lab this up with OSPF and RIP to see how the topology behaves differently with tagging and without, and the truth is that you will see no difference in the routing itself. Specifically, if you redistribute at both R1 and R2 without tagging, you will not have any routing loops. But thatâs the case only because the topology is somewhat forgiving. Hereâs the topology again for reference:
If routing protocol B, which in our case is OSPF, redistributes the 1.1.1.0/24 network back into RIP (routing protocol A) the router at the bottom will be receiving updates about how to reach the 1.1.1.0/24 network via RIP. However, because the network is directly connected, it prefers the directly connected route due to the lower administrative distance. But if you had more routers in the routing protocol A domain, those would get updates to the 1.1.1.0/24 network both from the bottom router and from routers R1 and R2, which would be a problem.
One way you can see this more clearly is if you take a look at the OSPF database on R2. If you issue the show ip ospf database external command, you will see that the 1.1.1.0/24 network has been learned as a type 5 LSA from R1.
