Redistributing Metrics

[Patrick McHenry]

I'm going to be mutually redistributing OSPF into EIGRP and EIGRP into OSPF on our headend DMVPN routers. I noticed that the old config had redistribute ospf 1 metric 1.1.1.1 as the redistributing metric . What does this mean?

Also, I would like to change this to something meaningful. What should I assign it? 100000 10 255 1 1500?

Also. redistributing EIGRP into OSPF, I would like to use the metric-type 1.

Thanks, Pat

[cadet alain]

Hi,

to redistribute into EIGRP you must use a seed metric otherwise the default is infinity  so metric 1 1 1 1 1 is a correct

config and it will give you some composite metric value. If you want a specific metric then do the math with the numbers specified in the metric command.

For OSPF as OE1: redistribute eigrp x metric-type 1  or use a route-map where you set the metric-type

Regards.

Alain

Don't forget to rate helpful posts.

[blue phoenix]

Thanks for this Alain!!!

Now I know what metric type 1 is used for in redistribution.  It is to have an OE1 route in OSPF ;)

[Peter Paluch]

Hello Patrick,

Just to add to Alain's perfect answer.

I noticed that the old config had redistribute ospf 1 metric 1.1.1.1 as the redistributing metric . What does this mean? 

I assume this command was put into EIGRP configuration and looked as follows:

redistribute ospf 1 metric 1 1 1 1 1

As  you know, EIGRP uses a composite metric that consists of bandwidth,  delay, reliability, load, and MTU components, and it uses the first four  components to compute the resulting total metric. The resulting metric  is never advertised as a single number in EIGRP, rather, EIGRP always  advertises the component metrics and each router computes its own total  metric. When redistributing into EIGRP, the redistributed routes must  also have these five component metrics specified individually. That is  the meaning of the five "1" in the redistribute command.  There is no special meaning to have these five metric components set to  1 - on the contrary, it seems that someone was simply lazy specifying  more realistic metrics.

However, I strongly suggest using more realistic  metrics. The "1 1 1 1 1" metrics are simple to write but they result in  an EIGRP metric that is impractically high and may under circumstances  grow to the maximum value that represents infinity - and in that case,  routes will start to be ignored and you will end up with incomplete  routing tables.

Therefore, I often suggest using a metric typical for 100Mbps Ethernet:

• Bandwidth: 100000
• Delay: 1
• Reliability: 255
• Load: 1
• MTU: 1500

This directly translates into:

redistribute ospf 1 metric 100000 1 255 1 1500

Your suggestion of 100000 10 255 1 1500 is also sensible.

Also. redistributing EIGRP into OSPF, I would like to use the metric-type 1.

Sure, you can do it. The command would be:

redistribute eigrp X subnets metric-type 1 metric 100

Here, substitute X with the EIGRP AS number and replace the seed metric if necessary.

One  thing to consider: if you plan to perform this redistribution in both  directions on multiple routers, you have to be very careful about not  advertising routes from OSPF through EIGRP back to OSPF, and vice versa.  Otherwise you could form permanent routing loops. Ideally, this mutual  OSPF-and-EIGRP redistribution should be performed on a single router  only. If multiple routers are required, you will need to use route  tagging or administrative distance manipulation to prevent routing loops  from occuring.

Best regards,

Peter

[Patrick McHenry]

Thanks, Peter

I was also going to add tagging as you mentioned:

How do you think this looks?

For MK-1001-VPN

router eigrp 99
network 172.20.68.0 0.0.3.255
redistribute ospf 1 metric 100000 1 255 1 1500 route-map stop-tag-1035100

!
router ospf 1
router-id 172.20.64.102
redistribute eigrp 99 subnets metric-type 1 route-map set-tag-17220681
network 172.20.64.0 0.0.0.255 area 0
!
route-map set-tag-17220681 permit 10
set tag 17220681
!
route-map stop-tag-1035100 deny 10
match tag 1035100
!
router-map stop-tag-1035100 permit 10
!

--------------------------------------------------------------------------------

For AP-1001-VPN

router eigrp 99
network 10.3.68.0 0.0.3.255
redistribute ospf 1 metric 100000 1 255 1 1500 route-map stop-tag-17220681
!
router ospf 1
router-id 10.3.5.100
redistribute eigrp 99 subnets metric-type 1 route-map set-tag-1035100
network 10.3.5.0 0.0.0.255 area 0
!
route-map set-tag-1035100 permit 10
set tag 1035100
!
route-map stop-tag-17220681 deny 10
match tag 17220681
!
router-map stop-tag-17220681 permit 10
!

I think you were saying above that I should also do the opposite for routes being redistributed from OSPF into EIGRP?

Is this correct?

I created a diagram but, couldn't figure out how to upload. We used to be able to do this. Is the ability disabled?

Thanks, Pat.

[Peter Paluch · Accepted solution]

Hello Pat,

I don't think that the route-maps are currently correct. Each of the route-maps controlling redistribution should first check for a particular tag value and drop the tagged routes, then permit the redistribution (of the remaining routes) and mark them with a different tag.

So, regardless of which router you are configuring, the route-maps should look as follows:

route-map EIGRP2OSPF deny 10
 match tag 110 ! Routes came from OSPF
!
route-map EIGRP2OSPF permit 20
 set tag 90 ! Routes come from EIGRP
!
route-map OSPF2EIGRP deny 10
 match tag 90 ! Routes came from EIGRP
!
route-map OSPF2EIGRP permit 20
 set tag 110 ! Routes come from OSPF
!
router ospf 1
 redistribute eigrp 99 route-map EIGRP2OSPF metric-type 1 subnets
!
router eigrp 99
 redistribute ospf 1 route-map OSPF2EIGRP metric 100000 1 255 1 1500

Does this make sense? It is a little convoluted... Please feel welcome to ask further!

Best regards,

Peter

[Patrick McHenry]

Thanks, Peter.

Took me a bit to figure it out but, I understand what your example is doing now. It is tagging both routing protocols on the one router. I need to apply this to both headends.

Correct me if I am wrong but,  I wasn't tagging both routing protocols on both routers in my example.

In router eigrp 99, you are tagging the redistributed ospf routes with 110 - this will prevent them from being redistributed back into ospf because in ospf 1, you are denying anything with a tag of 110 to redistributed back in.

In router ospf 1, you are tagging the redistributed eigrp routes with 90 - this will prevent them from being redistributed back int eigrp because in eigrp 99, you are denying anything with a tag of 90.

Does it sound like I understand?

Thanks, again.

[Peter Paluch]

Hi Pat,

You got it correctly. And yes, the problem with your original route-maps was that they did not prevent the routes from being actually injected back - in the OSPF, you always performed only tagging and never drop any redistributed routes. So this could potentially cause OSPF to redistribute its own routes back. I know there are several internal mechanisms in both EIGRP and OSPF that try to prefer internal routes to external but nevertheless, the possibility of a routing protocol actually feeding itself should be removed.

Best regards,

Peter