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?
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:
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.
I have intlo0 with ip address of 18.104.22.168/24
I have access-list 1 permit 22.214.171.124 0.0.0.0 and route map route-map TST permit
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 126.96.36.199 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?
It looks to me that although your interface address for the loopback is 188.8.131.52, 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 184.108.40.206/24 route is not matched by your access-list 1 statement of 220.127.116.11 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 (18.104.22.168 0.0.0.0), but change your loopback address to 22.214.171.124/32 (126.96.36.199 255.255.255.255), and see whether you now have the tag 111 for 188.8.131.52.
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,
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.
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.
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).
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.
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
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?
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!
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.
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.
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 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.
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.