Redistribute OSPF into RIP with Tags

[v_michael_]

When I redistribute an external route from OSPF into RIP, the route loses its tag value when I check the RIP router's routing table. So, in order for the specific tag to exist in RIP, I have to specifically reassign the tag value in the redistribution process from OSPF to RIP. Please shed some light on why the tag value is lost in the redistribution process between OSPF and RIP.

[Giuseppe Larosa]

Hello Michael,

I would suggest the following checks:

a) what RIP version are you running?

route tags should be supported in RIPv2

if you haven't done before use

router rip

version 2

on all RIP routers ( I suppose you are doing a lab)

b) the behaviour can be dependent on the IOS version too.

I did tests on this some years ago but perhaps I've done a simpler test like

route-map eigrp-into-rip deny 10

match tag 120

!

route-map eigrp-into-rip permit 20

set tag 252

!

for example I've found the following about ipv6 routes

Configuring Route Tags for IPv6 RIP Routes

When performing route redistribution, you can associate a numeric tag with a route. The tag is advertised with the route by RIP and will be installed along with the route in neighboring router's routing table.

If you redistribute a tagged route (for example, a route in the IPv6 routing table that already has a tag) into RIP, then RIP will automatically advertise the tag with the route

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-rip.html#wp1041727

and the match tag command in command reference reports no exceptions for RIP

http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_pi1.html#wp1014832

Hope to help

Giuseppe

[v_michael_]

a) I am running RIP v2 (IPv4).

b) The route-map in your example is exactly what I had to do, which was create a route-map to reassign the TAG value during the redistribution from OSPF into RIP.

From a high level, this is what seems to be going on if I don't reassign the Tag between OSPF and RIP:

(Insert Tag) (Tag exists) (Tag Lost)

EIGRP(Router1) --> OSPF(R2) --> RIP(Router3)

My concern is that I was expecting the tag to remain on the redistributed route all the way to the RIP router, without having to create an additional route-map to reassign the tag value.

Is this normal behavior?

[Giuseppe Larosa]

Hello Michael,

it is not normal this behaviour.

unless there is a problem of route tag field size:

for OSPF and EIGRP the route tag is a 32 bit integer.

I wonder if the route tag is a 16 bit integer for RIP in this case it wouldn't be possible to port a route tag from one protocol to RIP.

I've checked on Jeff Doyle's Routing TCP/IP vol I

RIPv2 route tag is 16bit integer

EIGRP tag in external routes is 32 bit integer

the same 32 bits for external routes is in OSPF LSA type 5.

So I think the explanation of this limited support is in this field size difference:

a route tag of 65536 cannot be copied in the 16bit field of RIPv2.

so you need to match on source protocol tag and to set tag for RIP routes

Hope to help

Giuseppe

[v_michael_]

That's a great point, however I was using a tag value of "999". So just to be safe I changed the tag to "9", but to no avail. Despite the change, the tag did not appear on the RIP router. Same outcome.

[Giuseppe Larosa · Accepted solution]

Hello Micheal,

it is the size of the field that matters not the value inside.

Think of if from a programming point of view in a language like C that has the types of variables.

For this reason I think the tag is not transported into RIP.

Hope to help

Giuseppe

[v_michael_]

That makes sense! I just reproduced this test scenario and the results reflected the size of the field requirements. In the test, I routed the tag in the opposite direction where I inserted the tag at RIP and it successfully reached EIGRP.

In other words, RIP to EIGRP works, but EIGRP to RIP fails.

Thanks a lot!