OSPF<->EIGRP Mutual Redistribution - little long

From: badger (badger@pongo.org)
Date: Sat Jul 05 2003 - 13:29:31 GMT-3

Hello ccielab,

  I need a little help in understanding the stated lab requirements
  concerning "must be able to ping every router from every router," -
  I think it goes something like that.

  Here is my point...I've been doing various lab scenarios that have
  those same basic stated requirements and find that, at least to my
  understanding, their solutions do not always meet the requirements.
   Here is an example and maybe someone can tell me what I'm missing.

   For example, when doing mutual redistribution between OSPF and
   EIGRP, I notice that the connected networks under the respective
   routing processes get redistributed between the processes - here is
   a graphic - hope it comes out correct:

                   OSPF EIGRP
                                |
                Lo 200.0.0.1 |
                      | |
                      | |
   150.50.100.x-------R1--------|----150.50.12.x-----R2------150.50.77.x
                      | | |
                      | | |
                150.50.24.x | Lo 200.0.0.2
                                |
When doing redistribution in the above case, the OSPF connected
networks, 100.x and 24.x, and the EIGRP connected networks, 12.x and
77.x, are mutually seen by both processes. So, if I'm on say another
OSPF router, say R8, then I can ping the EIGRP 12.x interface -
everything is great.

Now here's the catch and something I've observed in doing my
scenarios. If I now redistribute my connected loopbacks into their
respective routing processes, the loopsbacks get their mutual
redistribution between OSPF and EIGRP, but now the connected networks
disappear from the mutual redistribution. In other words, if I'm on
the OSPF router R8 now and try to ping the 12.x (EIGRP) interface, I
can't because it has been dropped for the redistribution.

My solution would be to add the 12.x network under my OSPF
"redistribute connected" of R1, but the lab solutions don't do this and
I'm not certain if my solution violates the requirement of putting
this network under a routing process to which it doesn't belong. The
lab scenario solutions to seem to care about not having a route to
this 12.x network.

So, what's wrong here?

Thanks

-
Best regards,
 badger mailto:badger@pongo.org

This archive was generated by hypermail 2.1.4 : Wed Aug 06 2003 - 06:52:24 GMT-3