How to configure Redistribution between EIGRP and RIP

thanks for the explanation… this is also what I know about rip-eigrp redistribution…
however, I came across a website that used a different method of making AD=12 for eigrp routes in RIP… using the command: distance 12 network netmask
you have any clue about this… got me confused what the real method is
thanks in advance.

In my example there is only 1 router that is running EIGRP and RIP at the same time. When you have two routers doing redistribution, it is possible that you get a scenario like this:

Prefix from routing protocol A > B > A

This is a problem that can cause routing loops or sub-optimal routing. Imagine that we have prefix in EIGRP, by default it has a AD of 90.

Once it is redistributed into RIP, it has an AD of 120.

When we redistribute it back into EIGRP, the AD is 170 (external).

Since 170 (external) is higher than 90 (internal), EIGRP will never prefer a redistributed prefix over an internal route.

RIP doesn’t have this “failsafe”…when you redistribute into RIP, the AD is always 120. We can change the AD ourselves to solve some problems.

Besides the AD, we can also fix redistribution problems with route tagging and changing metrics. In the beginning it might be very confusing to understand so try to focus on the problems of redistribution scenarios and then see if it can be fixed by playing with the AD, metric or tagging :slight_smile:


Hi Rene,

Why the below command is not used here ? its being used in ospf->rip redistribution.

R2(config)#router rip
R2(config-router)#default-metric 5

Hi Deepak,

You can set a default seed metric globally with the “default-metric” command. That’s what I used for RIP in that example.

It’s also possible to specify the seed metric when redistributing. For example:

R1(config)#router rip
R1(config-router)#redistribute ospf 1 metric 5

This will accomplish the same thing.



Understood. Thanks a lot!


Hi Rene, what is the name of the program you are using in this video - looks very good i would like to try it.

Thanks :slight_smile:

Hello Rene,
Thanks a lot for you amazing explanation,
I still have a question how to decide what is the value of K1 to use.
or if I need to troubleshoot the K1 value if it’s correct or not, what to look for?
Thanks in advance.

Hello Wisam

In general, the default values of the K metrics should not be changed. They are configured so that EIGRP will function correctly under the most common circumstances. However, if there is strange behaviour on your network or if you want to configure an elaborate routing behaviour, then K1 as well as the rest of the K values can be adjusted.

K1 can be set to anything between 0 and 256 (yes, 256, not 255) as can all of the K values. Specifically, K1 involves taking into account the minimum configured bandwidth between the router in question and the destination network. If K1 is 0 then the bandwidth is not taken into account. This would not be a good idea if you have links in your network with widely varying bandwidths. If K1 is greater than 1 then, the bandwidth will be taken into account much more than the rest of the K values.

You can find out more about this in Rene’s lesson on EIGRP K Values.

I hope this has been helpful!


Hi, Can someone please explain why need to define metric when we are doing redistribution, I know it will not restribute the route if we don’t use it but i am not sure what the concept behind it, can someone please help to clear that.

Hello Navarj

RIP and EIGRP, although both distance vector routing algorithms, use very different metrics. RIP uses a number between 0 and 16 which indicates the number of routers, or hops, between the current router and the destination. EIGRP uses a complex composite metric that is derived from a formula from which the metric is derived. This metric has a range from 0 to several million.

So you see that the metric used by RIP is incompatible and essentially meaningless to EIGRP and visa versa. For this reason, when a route is redistributed from RIP to EIGRP for example, you must specify the cost to that route using metrics that EIGRP can understand. The same goes for redistribution in the opposite direction.

I hope this has been helpful!


Hi Laz,

That make sense thank you for helping, I have another question what matric we need to define how we know that, it can be anything random?

When we advertise OSPF in EIGRP at that time we have to specify OSPF metric why we have to, I know it will not advertise the route if we don’t do that but what is the logic behind it and how we know what values should be best for it to select.


Hello Navraj

You should choose the values that you will use for the metric when redistributing very carefully. These values will affect the way the routing protocol will interpret these routs, and thus will choose which routes to use. When redistributing into EIGRP, keep the following in mind:

Bandwidth - The bandwidth you use is probably the most crucial. Here you are stating what the lowest bandwidth is between the current location and the destination. If you generally have a high speed network with gigabit or 10gigabit links, make sure this is set appropriately. Remember, these values must be comparable in order to make a redistributed route have an appropriate metric to be used.

Delay - This value is also important because it too has to do with the speeds of interfaces that exist between network equipment. The lowest value is 10 microsoeconds, which corresponds to GigabitEthernet speeds. If only smaller links are available in your network, this should be tweaked to be comparable to those.

The other K values are not used by default, but if you choose to use them, then make sure that load, which can have values between 1 (low load) and 255 (high load) should be set low, and reliability also between 1 (low reliability) and 255 (high reliability) should be set high. The MTU configuration should remain at the default of 1500 as this does not affect the routing decisions.

I hope this has been helpful!


1 Like


Great video!.

Only one question, what is the reason why rip default metric permit a value as a 4294967295.

The max matric can be only 16 for rip process as Rene says.

Thank you

Hello Giovanni,

I think this is a cosmetic thing. They probably use the same “default-metric” command for all routing protocols.

R1(config)#router rip
R1(config-router)#default-metric ?
  <1-4294967295>  Default metric

It seems they changed this in NX-OS where you can oonly configure a value between 1 and 15.


1 Like

Hello Laz,

I have 3 routers R1,R2 and R3.
R2 has 2 vrfs. vrf1 and vrf2.

Interface on R2, which is connected with R1, is in vrf1.
Interface on R2, which is connected with R3, is in vrf2.

And R2 has the following eigrp configuration.

router eigrp 10
 address-family ipv4 vrf vrf1 autonomous-system 1
  redistribute eigrp 2 metric 1000000 100 0 1 1500
 address-family ipv4 vrf vrf2 autonomous-system 2

I am expecting routes of AS-2 in AS-1 because of redistribution. But I do not see any redistributed routes in AS-1. Is it not the expected behavior ?


Hello Sachin,
in your lab redistribution does not work because you are trying to redistribute between different VRFs. If you want redistribution to take place, then routes have to be in same VRF.

If you want to redistribute between VRFs it is called route leaking and you can learn it in this lesson.

You can achieve route leaking by using static routes or MP-BGP VPNv4 address-family.

To make you lab work you can apply a bit of configuration on R2.

Create VRFs and configure Route Distinguishers (RD) and Route Targets (RT). RD is used to make routes unique based on VRF they belong to. RT is used to import and export routes with specific extended community tag. These tags are controlled using route-target commands.

vrf definition vrf1
 rd 65000:1
 address-family ipv4
  route-target export 65000:1
  route-target import 65000:2

vrf definition vrf2
 rd 65000:2
 address-family ipv4
  route-target export 65000:2
  route-target import 65000:1  

Create BGP process, give it BGP router-id. Create BGP address-family that belongs to specific VRF and redistribute specific EIGRP AS into it.

router bgp 65000
 bgp router-id

 address-family ipv4 vrf vrf1
  redistribute eigrp 1

 address-family ipv4 vrf vrf2
  redistribute eigrp 2

Now you have routes from both VRFs in BGP VPNv4 address family table, you can check it using command “show bgp vpnv4 unicast all”.

Last, but not least, you have to redistribute routes from BGP into EIGRP. In your case it would look like this.

router eigrp 10

 address-family ipv4 vrf vrf1 autonomous-system 1
  redistribute bgp 65000 metric 1000 10 255 1 1500

 address-family ipv4 vrf vrf2 autonomous-system 2
  redistribute bgp 65000 metric 1000 10 255 1 1500

On R1 and R3 you should now see redistributed routes as “D EX”, these are leaked routes from the other VRF.

1 Like

Hello Sachin

@fugazz has got it right. Let me just add that the two options that can be used for route leaking between VRFs involve:

  1. Redistributing static routes from one VRF to the other via the global routing table. This solution avoids the use of BGP.
  2. The use of Multiprotocol BGP (MP-BGP) which essentially allows different address families to be redistributed between VRFs, which is the solution described by @fugazz above.

For an additional solution, take a look at this solution from the Cisco Support community:

I hope this has been helpful!


1 Like

Hi Guys,

Happy New Year! Quick question… any ideas why the order of K values when setting the EIGRP seed metric doesn’t run in sequential K value order? Seems illogical to me unless there is a reason?

router eigrp 100
default-metric ‘K1’ ‘K3’ ‘K4’ ‘K2’ ‘K5’

K1 - Bandwidth
K2 - Load
K3 - Delay
K4 - Reliability
K5 - MTU



Hello Gareth

That’s an interesting question. After doing some research I was unable to find any information that answers this question. The only thing I can offer as a partial explanation is that by default, K1 and K3 are taken into account while K2, K4, and K5 are not. So having K1 and K3 first, may have something to do with this. Secondly, K4 and K2 are load and reliability, which both are calculated on a scale of 0 to 255 and are seen as values determined within the interface of a network device. The fact that they are similar may have some logic in how they are grouped. Finally, K5 is MTU which is a parameter different from the rest, and is thus put in last.

Note also that in any Cisco IOS command reference, the command parameters are not referred to with their K values but with their names. There doesn’t seem to have been any correlation between the actual order of the K values and the order of the parameters.

Beyond this inference based on the nature of the parameters themselves, I haven’t been able to find any particular reason for the order of entry.

I hope this has been helpful!


Great answer Laz. I guess it makes sense that the two K values used by default are listed first and second.

It’s interesting to learn about the logic that goes into the design of the software…

Much appreciated!

1 Like