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
Thanks - Your reply was more concise and I shall be using that in my notes
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).