How to configure Route Tagging

Hello Babar

If you use the same tag for both 1.1.1.1 and 2.2.2.2, and you have a route-map that denies that particular tag on both WANs, then yes, 1.1.1.1 would not be redistributed into Pri/Sec WAN2. But under normal circumstances, you would want that redistribution to occur, because you want R2 to know how to reach 1.1.1.1.

If you were to use different tags, say tag 1 for 1.1.1.1 and tag 2 for 2.2.2.2, then you can selectively allow or deny tagged routes. This way you can avoid the redistribution of 1.1.1.1 into WAN1 while allowing the redistribution to occur at WAN2, and you can avoid the redistribution of 2.2.2.2 into WAN2 while allowing it at WAN1.

I hope this has been helpful!

Laz

1 Like

Thanks for the clarification Lazaros, appreciate it.

1 Like

hi Renè, the following config i think is better, what do you think?

R1(config)#route-map TAG deny 10
R1(config-route-map)#match tag 2  
R1(config-route-map)#exit
R1(config)#route-map TAG permit 20
R1(config-route-map)#set tag 1

R2(config)#route-map TAG deny 10
R2(config-route-map)#match tag 1
R2(config-route-map)#exit
R2(config)#route-map TAG permit 20
R2(config-route-map)#set tag 2

Hello Andrea

Yes, your configuration includes the tagging by both routers, and the blocking of the corresponding tag in order to avoid networks being re-redistributed back into the same routing protocol.

Thanks for sharing that!!

Laz

Hi Rene & Team,

Is route tagging part of the routing protocol’s standards (OSPF, RIP…) ? Would it be a feasible solution when mixing Cisco routers with routers from other vendors?

Thanks,
LP

Hello Luis

Route tagging is actually defined within each routing protocol. Looking at the RFCs of OSPF, RIP, and EIGRP, you can see that the messages exchanged by these protocols include a field for route tags. The logic of how they work is the same for all protocols.

BGP on the other hand, uses the term “tag” in a different way. BGP routes can be “tagged” with BGP communities. You can find out more about this at the following lesson:


Although not explicitly stated in the RFC for IS-IS, Cisco has implemented IS-IS to support route tagging. Other vendors, such as Juniper, have also implemented IS-IS extensions to support route tagging.

I hope this has been helpful!

Laz

1 Like

Hi,
I have a question about this topic because I don’t understand why route tagging is usefull (but I do understand how it works)

Like Rene says in the video; if you want to fix the issue of R1 and R2 pointing to each other as the next-hop for the 1.1.1.0/24 route instead of to R3, you have to change the AD. In other words only using route tagging will not work to fix the routing loop between the ABR’s.
If you use route tagging the routing loop between the ABR’s will not be fixed. R3 and R4 however will not have a routing loop anymore, so there is has a purpose of configuring it.
But, how I see it, if you fix the issue on the ABR by changing the AD of the routes, you also fix the flapping route in the RIB. As the RIB of the ABR’s is now fixed, the ABR’s will not re-redistribute the route back into the source protocol, because “In addition to the route being in the RIB, the source protocol that redistributes into the destination protocol must be the source for the route in the RIB.” (CCNP ENARSI guide pg. 645). And thus this should fix the routing loop on R3 and R4 I think.

I hope I explained this well…

Hello Mathias

Actually, that’s not quite the case. Looking at this diagram from the lesson:
image
Imagine routing protocol A is RIP and routing protocol B is OSPF. If you leave the ADs unchanged, you can configure both R1 and R2 to tag routes redistributed from RIP to OSPF. This means that all routes to 1.1.1.0/24 that are shared within the OSPF will be tagged. The route-maps in both R1 and R2 will disallow any redistribution of the tagged 1.1.1.0/24 route back into RIP from OSFP, thus avoiding any incorrect routing or even routing loops.

Alternatively, you can change the AD of RIP and OSPF so that RIP has a lower AD, and that would resolve the issue. Although this would be a solution for the specific topology, it is not a solution that can easily be applied universally in more complex topologies, and this is why route tagging is preferred.

I hope this has been helpful!

Laz

1 Like

Hi Lagapides,

Many thanks for the reply, but I still don’t understand what I’m missing.

I used this lab in GNS3 as displayed by the image, which I build from the ENARSI topology (pg 672 figure 17-1). But I changed the EIGRP process to ripv2 like in the networklessons lesson.

Basic setup
I advertised on the ASBR the 9.9.9.9/32 network via rip with a metric of 5. Then on R1 I advertise the rip routes into the OSPF process, no route-maps applied yet.
On R2 I advertise OSPF networks into rip again, with a lower metric of 1, so they are prefered in the RIP area.
The expected happens, and R3 ‘show ip route’ output says that the 9.9.9.9/32 network is via R2. Also R1 and R2 point to each other as the next hop for 9.9.9.9/32 via the OSPF interfaces.

Using route-tagging
Then I applied a route-map on R1 which sets a tag of 10 on routes redistributed from RIP to OSPF. On R2 I applied a route-map on the redistribute command that denies the redistribution of OSPF-learned routes into RIP with a tag of 10.
R3 now points to the ASBR again for the 9.9.9.9/32 network. But R2 still points to R1 via its OSPF interfaces for the 9.9.9.9/32 route, as expected.
So in my lab that routing loop is not solved, as mentioned by Rene in the lesson.
In the end further measures should be taken to fix the routing loop (suboptimal routing in my case) between R1 and R2. Like changing the AD.

Changing the AD instead
When I use don’t use route-maps, but set the distance of rip as 109 (lower then OSPF 110) on R2, R2 prefers R3 as the next-hop again for the 9.9.9.9/32 network.
And because the 9.9.9.9/32 route is in the routing table as a RIB route, and not anymore as an external OSPF route, the route will not be redistributed from OSPF into RIB and thus not being advertised to R3.

So I still don’t understand how in this scenario route-tagging could be of use, as changing the AD is necessary anyways and it solves both problems at once making route-tagging redundant. I just did this in a lab and no suboptiomal routing/loops occur, just by changing the AD.

I just read your answer a bit better, and I think your saying that in this scenario changing the AD indeed solves everyting, but this scenario is used for displaying route-tagging, not for displaying a scenerio were it’s crucial?
If that’s the case do you know a situation were route-tagging shows it true merrit?

Apologies for the long reply.

Hello Mathias

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.

I hope this has been helpful!

Laz

1 Like

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.

1 Like

Hi Rene,

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

Regards,

Hi Rene,

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

Regards,

Hello Dhruv

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 hope this has been helpful!

Laz

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?

Hello Vadim

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:
image
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.

I hope this has been helpful!

Laz

Hi i have this info and im confusing
I have this config

router ospf 1
redistribuite eigrp 65005 subnet tag 12345678
summary address 172.16.0.0 255.255.0.0

The question im redistrintuing eigrp into ospf but the subnet tag rappresent the network 172.16.0.0 ?

Thanks a lot

Hello Ugo

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:
image

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.

I hope this has been helpful!

Laz

Hello, everyone!

I’ve built a similar topology to the one in the video to see the suboptimal routing and routing loops in action.

There really does appear to be a loop because R1 also considers the path through G0/1 as valid for the 192.168.1.0/24 destination.

The question is, why is this loop only occuring with R2? Shouldn’t R3 also redistribute the route back into RIP and advertise it to R1?

Another question is, these loops cannot happen with OSPF and EIGRP? I’ve changed the topology to this


And now there are no loops

obrázok

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?

Hello David

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 hope this has been helpful!

Laz