How to configure Route Tagging

This topic is to discuss the following lesson:

Excellent article, Rene. Is this a way to prevent what they call asymmetric routing?

It’s mostly used to prevent routing loops or sub-optimal routing paths that are caused by redistribution. Asymmetric routing doesn’t have to be a problem…when using IGPs (OSPF / EIGRP) you will mostly see symmetric routing but with BGP, asymmetric routing is likely to occur.

hello,
if the route map was writed in this way:

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

is the same thing?

Hi Frank,

It’s not the same thing. In the first permit 10 statement there is no “match” so it will match on everything and set the tag to 1. You will never make it to the “permit 20” statement since everything is permitted.

Rene

ip route 10.36.188.38 255.255.255.255 Serial0/0/0 10.36.148.222 tag 1
route-map STATIC-TO-EIGRP permit 10
 match tag 1

can you please explain this one to me please,

A tag of “1” is added to the static route. The route-map only matches on everything that has a tag of “1”.

So if you redistribute static routes into EIGRP with this route-map, only the ones that are tagged with “1” will be redistributed.

Can you confirm if this is my correct reading of this route-map
Networks from Protocol B ‘Jack’ are untagged until they enter Protocol A where they are Tagged - (The first statement is ignored because they are not Tagged)

Jack(config)#route-map TAG permit 20
Jack(config-route-map)#set tag 1 

When these now Tagged routes hit ‘John’ Still in Protocol A they are denied from re-entering Protocol B via the First statement.

 route-map TAG deny 10
    John(config-route-map)#match tag 1

But as you say the route-map has to deny the Tagged routes first or it will allow all routes that is why the deny comes before the permit?

Hi David,

You got it, that’s right. In short this is what the route-map does:

- First check (deny 10): If it has a tag, don’t redistribute it.
- Second check (permit 20): If it doesn’t have a tag…redistribute it.

This allows everything that hasn’t been redistributed to be redistributed, something that has been redistributed before will not be redistributed again.

Rene

Plus I also had to clear my routing tables for the route-map to take effect!

Yes that might help, doing a “clear ip route” helps to speed things up :slight_smile:

Thanks - Your reply was more concise and I shall be using that in my notes :slight_smile:

Hello.I try to understand set command,what are the differencies between match and set?why should we write set command?And you wrote we have to write same commands in another router but how?exactly same?

Hi Elvin,

The “match” command checks for criteria, for example an access-list. The “set” command changes something. This could be adding a tag but it’s also used for other things. If you want to see a simple example of a route-map, take a look at policy based routing:

https://networklessons.com/ip-routing/how-to-configure-policy-based-routing/

That’s where we use both the match and set commands.

Redistribution is a difficult topic. One thing to keep in mind is that you should never redistribute something from routing protocol A > B > A. This is something we can achieve with tagging. Each router that does redistribution should ignore tagged routes and tag everything else.

Rene

Hello Rene,

I have intlo0 with ip address of 1.1.1.1/24

I have access-list 1 permit 1.1.1.1 0.0.0.0 and route map route-map TST permit
route-map TST
set tag 222

match ip address 1
set tag 111

and redistribute into ospf from eigrp

redistribute eigrp 100 subnets route-map TST

but at the destination router I only see tag 222 for the prefix 1.1.1.1 instead of 111

as son as I change the access list wild card mask to 0.0.0.255 the destination router sees the correct tag of 111

Could you please explain this why with wilcard 0.0.0.0 the correct tag is not shown but with 0.0.0.255 the correct tag is shown?

Best Regards,
-Rouzbeh

Rouzbeh,
It looks to me that although your interface address for the loopback is 1.1.1.1, the actual route corresponding to that interface is /24 not /32. It is the route, not the host address that has tags applied to it. Since the 1.1.1.0/24 route is not matched by your access-list 1 statement of 1.1.1.1 0.0.0.0, your tag is not getting applied.

Here is another way to test this theory. Change your access-list back to what you had originally (1.1.1.1 0.0.0.0), but change your loopback address to 1.1.1.1/32 (1.1.1.1 255.255.255.255), and see whether you now have the tag 111 for 1.1.1.1.

Yes, I changed the address to /32 and access list with wild card 0.0.0.0 worked this time.

Thank you so much for the guidance,

-Rouzbeh

Hey Rene,

Great lesson.

However i think that you are missing a part. You are not talking how we should apply this feature inbound. We are taking the routes and redistributing them, but that’s outbound, correct?

When we tag the route’s and redistribute them there is nothing in our routing protocols that matches that inbound?

Maybe it would be good if you make this lesson as the other’s which are very detailed.

Thanks.

Best Regards,

George Milev

Rene,

Very good lesson.

However i believe you are missing something… You don’t mention anything about the distribute list, which will filter this on the inbound direction…

Although you covered this in the next lesson i think that it would be very nice to add some details to this one because this is a very important topic to cover.

Best Regards,

George Milev

George,
A distribute-list, in and of itself, cannot match on route tags–a route-map does this. While it is true that you can use a distribute-list to call a route-map to perform the same function, it is the route-map that is doing all the work. So for purposes of this lesson on route-tagging, the use of a distribution list as additional means of calling a route-map doesn’t add much to the understanding (because the lesson already demonstrates the use of a route-map).