How to configure Route Tagging

(Rene Molenaar) #11

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

0 Likes

(david p) #12

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

0 Likes

(Elvin H) #13

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?

0 Likes

(Rene Molenaar) #14

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:

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

0 Likes

(rouzbeh t) #15

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

0 Likes

(Andrew P) #16

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.

0 Likes

(rouzbeh t) #17

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

0 Likes

(george m) #18

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

0 Likes

(george m) #19

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

0 Likes

(Andrew P) #20

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).

0 Likes

(Nyi Nyi L) #21
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.

0 Likes

(Andrew P) #22

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
0 Likes

(Shantel - Networklessons.com) split this topic #23

19 posts were merged into an existing topic: How to configure Route Tagging

0 Likes

(Dmitrii Y) #24

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.

0 Likes

(Lazaros Agapides) #25

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

0 Likes

(Abdus S) #26

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

image

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.

0 Likes

(Rene Molenaar) #27

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

0 Likes

(Brian C) #28

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.

Capture

and topology:
Capture

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.

Capture

0 Likes

(Rene Molenaar) #29

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

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

(Trust_the P) #30

Thanks for sharing @wilder7bc

1 Like