Jack(config)#route-map TAG deny 10
Jack(config-route-map)#match tag 1
Jack(config-route-map)#exit
Jack(config)#route-map TAG permit 20
Jack(config-route-map)#set tag 1
can I give any number of match tag? not only 1.
Nyi,
Yes, you can do this, but you need to be aware of how the difference in writing a route-map determines whether your conditions are logical ANDs or ORs.
The following route-map would only act on a route that has all of the tags 10, 20, and 30
route-map TAG deny 10
match tag 10
match tag 20
match tag 30
Whereas, the following route-map would act on a route that has any of the tags 10, 20 or 30
route-map TAG deny 10
match tag 10 20 30
19 posts were merged into an existing topic: How to configure Route Tagging
Hello Rene,
If I have OSPF and EIGRP domains and I configure 2-way redistribution on 2 router should be used route taging or any other rotue filtering techniques?
As we know either of these protocols have their internal mechanism to defirentiate external routes so does it make sense to use any filtering and if es then in which cases?
Thanks.
Hello Dimitrii
It is true that both of these protocols have internal mechanisms to differentiate between external and internal routes. However, tagging should be implemented when there is multipoint redistribution. That is, when there are two or more locations via which the EIGRP and OSPF domains meet. This is important because if R1 and R2 (in the diagram in the lesson) use just their internal mechanisms for determining internal and external routes, a routing loop will occur.
Now you can use other techniques such as route map filtering where you choose which routes to filter and which not to using route maps and access lists. This can be deployed if you choose to, however, tagging is a simpler and more elegant way of implementing the necessary functionality to avoid routing loops. Note tagging, in the event that you donât want to filter specific routes for other purposes, is ideal for multipoint redistribution.
I hope this has been helpful!
Laz
Hi Rene,
Please please help me out regarding redistribution. when redistributing mutually between ospf and bgp by tagging and i m getting an error
% âTAG1â used as redistribute ospf into bgp route-map, set tag not supported"
route-map TAG1 deny 10
match tag 1
route-map TAG1 permit 20
set tag 1
according to the topology, I have to redistribute mutually bet OSPF and BGP at R3 and R4. I have to advertise 10.2.0.0/16 from R3 and R4 towards R1 and R2. simple redistribution shows 10.2.0.0/16 as âOE2â route in OSPF domain. but it should be âOâ route for OSPF domain.
Also, need to redistribute mutually at R5 (Betw OSPF and BGP) and R6 (Betw EIGRP and BGP). Kindly give an idea how to do the redistribution so that no loop occurs.
Not clear how to prevent the redistributed route from bgp to ospf back to bgp again by ospf redistribution in bgp.
Your prompt reply highly appreciated regarding this issue.
Hi Abdus,
Route tagging when redistributing into BGP is not supported. Thatâs why you get that error:
R1(config)#route-map SET_TAG permit 10
R1(config-route-map)#set tag 10
R1(config)#router bgp 1
R1(config-router)#redistribute ospf 1 route-map SET_TAG
% "SET_TAG" used as redistribute ospf into bgp route-map, set tag not supported
You can use something else in BGP to âtagâ redistributed routes, like a community value. Between OSPF and EIGRP, you can use tags to prevent routing loops.
Letâs think about the things that could go wrong in a topology like this if you redistribute between OSPF-EIGRP, OSPF-BGP, and EIGRP-BGP:
* Everything you redistribute into OSPF will always show up as an external route. Even if a route that originated in OSPF gets redistributed in OSPF, this wonât cause any issues since an O (inter-area) route is always preferred over an external (O E1 or O E2) route. You do have to watch out if you have O E1 or O E2 routes that originated in your OSPF domain.
* Everything you redistribute into EIGRP will always show up as an external route. Even if the route originated in EIGRP, it wonât be a problem since EIGRP external routes have a higher AD than internal routes. You do have to watch out when you redistribute EIGRP external routes that originated in your EIGRP domain.
* Routes that originated in BGP could be redistributed into OSPF > EIGRP and get back to BGP, or the other way around, into EIGRP > OSPF > BGP.
If you donât have OSPF external routes that originated in OSPF or EIGRP external routes that originated in EIGRP, then you donât really have to worry about OSPF or EIGRP. You should ensure that BGP routes donât loop around though.
If you redistribute from BGP into OSPF on R3/R4 then you can set a tag. Configure R5 to deny everything that is tagged when you redistribute into BGP. This prevents the EIGRP domain from learning BGP routes that originated in the BGP domain.
Do the same thing on R7, tag the routes you receive and that are redistributed into EIGRP. Configure R6 to deny routes that are tagged from being redistributed from EIGRP into BGP.
This prevents your BGP domain from receiving any prefixes that originated there. The only downside to this solution is that the EIGRP domain canât use the OSPF as a backup path to get to the BGP domain (or the other way around, from OSPF > EIGRP > BGP).
If you want this, then you could do something like this:
- Configure R1/R2 to advertise a community value for all internal BGP prefixes to R3/R4.
- Configure R3/R4 to redistribute OSPF and set a tag for the prefixes with the community value.
- R5 can redistribute from OSPF to BGP and set a community value based on the tag.
- R6 can redistribute from BGP into EIGRP, set a tag based on the community value.
- R7 can redistribute from EIGRP into BGP, denying everything that has the tag.
This prevents from feeding BGP prefixes going from OSPF > EIGRP > BGP while allowing the EIGRP domain to use the OSPF domain to get to the BGP domain. You can do the same thing for BGP prefixes that go from R8 > R7 > R6 > R5 > R3/R4 > R1/R2.
I hope this helps! Redistribution with three redistribution points and three routing protocols can get complex 
This would have been a lesson that a functioning topology would have been really nice. I had created one myself and had some issues and had a ten mile post but I figured out what my issue was. I basically didnt have a completed route-map configuration on R2. I have fixed that now and everything is working.
Basically I was interested in the path of the traffic and the incomplete configuration on R2 was making it where nothing made sense but after I added the exact same configuration route-map wise on R2 everything was good.
and topology:
below is how the traffic flows and it makes sense now Blue is the 192.168.2.0 goes from R2>R4 to R1 where it is picked up but will deny any tag that matches 1. So it denies 192.168.2.0 from R2 thus preventing issues.
Red traffic 192.168.1.0 does same thing R1 redistributes the RIP route into OSPF and Tags it with 1 which then travels to R4 and then to R2 where R2 will deny it.
R1(config)#route-map TAG deny 10
R1(config-route-map)#match tag 1
R1(config-route-map)#exit
R1(config)#route-map TAG permit 20
R1(config-route-map)#set tag 1
Basically this method allows R3 and R4 to get all the traffic that needs to be redistributed but it keeps other issues from happening.
The only curious thing is that it still shows up with the TAG even though its denied. I would have thought since it was Denied it would not show up in the routing table but it seems to show up in the route even though its denied. Else if that was not the case we would not be seeing the TAG 1 and we know where it comes from because the IP route x.x.x.x tells us its path.
so using Follow the Path trouble shooting that says that must be the case?
If I have this wrong please let me know.
Hi Brian,
I agree 100%, itâs on the to-do list to improve this lesson. The topology you created in GNS3 is the best topology to test redistribution scenarios where you have the risk of getting routes from A > B and back into A.
We only deny redistributing the route that has the tagâŚnot âinstallingâ the route in the routing table. That still happens 
In your topology, R1 will redistribute 192.168.1.0/24 from B > A and adds the â1â tag.
R2 sees the redistributed 192.168.1.0/24 route. It might even install it if the AD is lower but it will not redistribute it from A > B.
Rene
1 Like
Thanks for sharing @wilder7bc
1 Like
Hi Rene & Team,
What I understood regarding tagging, the route-map in lesson wouldnât work for the topology below:
The route 1.1.1.1:tag 1 would not be redistributed at Pri/Sec WAN2 as the WAN2 routers would deny the tag 1.
Am I right ?
Just want to be sure that I am not missing something and understood the concept.
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 2Hello 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:
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.