Redistribution logic check for IGP`s

hello,

i would like to get some clarification on the topic of redistribution please.

 

Two routers do mutual redistribution , as per below

 

R1 , R2 have dual links between them

R1 , R2 have a single link in OSPF and a single link in RIP

R1 , R2 , R3 , R4 are in RIP

R1 , R2 are in OSPF

 

 

! This should be the same for either RIP or EIGRP as both protocols AD (120/170)is higher than OSPF (110)

 

  RIP             ospf

--------------R1------

           |                  |

           |                  |

           |                  |

--------------R2------

  |       |

  |       |

  |       |

  R4  R3 

 

 

 

1.ONLY R1 does mutual redistribution.

 

R1 will pass RIP redistributed routes in OSPF over to R2.

R1 will choose RIP routes for RIP and OSPF routes for OSPF.

R1 will not have routing issues as it only has RIP routes via the RIP domain.

 

R2 will have RIP native routes in RIP Dbase and OSPF native routes in OSPF dbase.

R2 will also have native RIP routes in OSPF Dbase and OSPF routes in RIP dbase, due to redistribution of routes on R1.

 

R2 will choose OSPF routes to get to RIP networks as this has a lower AD and put OSPF routes in its

IP routing table.

 

R3 will not get any RIP updates from R2 , as R2 will only have OSPF routes in its IP routing table.

 

R2 will pass these OSPF routes back to R1

R1 will ignore these routes as the router-ID of R1 will be in the Type-5 update to stop loop creation.

 

 

This is an AD issue and the fix here is to change the AD for RIP routes on R2 to choose the correct Protocol for prefix.

 

This will be the same for EIGRP as there both higher into lower.

 

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

 

 

2.R2 Also does mutual redistribution.

 

R1 will be the primary exit point ( it carried out the redistribution process first)

R2 will have received RIP routes via OSPF

R2 will not have the RIP routes in its IP routing table because it will have better routes to the nets in OSPF.

R2 RIP will not redistribute RIP routes into OSPF as per RIP/EIGRP redistribution rules (must be in routing table)

 

Possible issues

 

1.metric issues , IF R1 was first - it`s chosen gateway

 

If you redistribute ALL OSPF routes into RIP , with a metric of less than 15,  without filtering.

 

Then the RIP routes learned from R1 will get sent to R2 via OSPF and then redistributed into RIP on R2.

 

Potentially causing a metric issue , as the seed metric may well be less than the Actual metric.

 

R3 will now choose R2 to get to RIP routes via OSPF domain and NOT via R1 as the metric.

 

Routing would be ..

 

R3 Rip - R2 Rip - R2 OSPF - R1 OSPF - R1 RIP

 

To resolve this , i should make sure that routes redistributed by R1 will not get redistributed by R2 and vice-versa.

many thanks

Comments

  • You seem to have the general idea.

    When you do mutual redistribution on one router remember that routes will not transit to another protocol. So if you redistribute from RIP to OSPF and then from OSPF to EIGRP then the RIP routes will not be in EIGRP unless you do redistribution from RIP to EIGRP. So when doing mutual redistribution on one router you will usually have no issues.

    You could have suboptimal routing like you said due to routers choosing path across OSPF instead of RIP and this is usually solved by setting a higher distance for those routes.

    When doing redistribution from some protocol into RIP I usually set a high seed metric to not make those routes preferred to the native ones.

    When you have mutual redistribution on multiple routers you will have more potential issues like you have identified. These can be solved by route tagging, changing distance, using distribute lists etc.

    Generally for the lab you don't care about optimal routing unless told to. You do need to watch out for route feedback so that you don't create routing loops.

    Generally there will be issues when going from a higher AD protocol -> lower -> higher like RIP -> OSPF -> EIGRP

    I recommend you read Petrs posts on redistribution. I have blogged some about it as well.

  • This is an AD issue and the fix here is to change the AD for RIP routes on R2 to choose the correct Protocol for prefix.

     

    This will be the same for EIGRP as there both higher into lower.

     

    In case 1 where redistribution is performed only on R1 ; In this scenario if you have RIP and EIGRP(replaced by OSPF) then there will not be any issues because EIGRP have the sense of external routes with AD 170.

     

    R3 Rip - R2 Rip - R2 OSPF - R1 OSPF - R1 RIP

     To resolve this , i should make sure that routes redistributed by R1 will not get redistributed by R2 and vice-versa.

     

    Set the AD value larger then RIP AD say 121 for all the external ospf routes on both R1 and R2.

  • thanks daniel and dancerian

  • i would like to get some clarification on the topic of redistribution please

    Another really obvious point is redistributed routes are only taken from the routing table - this can cause all sorts of fun and games!

    For example R1 is running RIP to R2 and R3.

    R2 is running OSPF to R4 and R4 is running OPSF to R1.

    Redistribute mutually on R2 between RIP and OSPF

    So all the fun begins on R2 -

    • R3 advertises RIP routes from some test loopbacks to R1
    • R1 advertises these to R2
    • R2 installs routes in the routing table and redistributes them into OSPF
    • R2 and R4 and R1 in same area so have the same database
    • On R1 OPSF extenal routes (from RIP) have a better AD than the native RIP routes learnt from R3 so they are displaced
    • So R1 can no longer advertise these routes via RIP to R2!  They are eventually removed from R2's routing table
    • R2 can no longer redistribute these routes as they aren't there
    • So OPSF external routes are removed from R2 R4 and R1
    • On the next update from R3 R1 can install the RIP native routes and hey ho lets start again.

    This type of thing is quite easy to see if by using your friend debug ip routing and in my scenario is quite easy to fix by an AD change for OSPF external routes to at least 121 on R1.

    So in this particular case you could have reachability then not depending when you ping and from what device.  This is where TCL is your friend in the exam too.

    Another nasty is EIGRP External routes redistributed into a lower AD protocol and then back to EIGRP on another router.

     

    HTH

Sign In or Register to comment.