Re: OSPF & EIGRP redistribution

Hi Yuri,

Thanks for the reply. Yes, I figured it was using the interface,
itself, since the ospf route isn't in the RIB. That's explains how this
is happening, but not "why?" or "should it?". Putting the "it was
easier to code that way" reason aside, is there a specific reason they
did this intentionally?

Bottom line, I rolled back from 12.4(15)T14 to an older 12.2T version
and it's the same. If it's been this way this long, there's a slim
chance a ddts would have any effect and would just get closed. But this
is a good lesson for something that can send you down a rabbit-hole on
the lab trying to figure out why this extra route is there.

Thanks,
Scott

-----Original Message-----
From: Yuri Bank <yuribank_at_gmail.com>
To: Scott Strobeck <scott_at_strobeck.net>
Cc: ccielab <ccielab_at_groupstudy.com>
Subject: Re: OSPF & EIGRP redistribution
Date: Tue, 31 Jan 2012 11:38:49 -0800

This is normal behavior. OSPF will see the loopback as a special
'LOOPBACK' network type, and will advertise the interface as a /32. When
you redistribute OSPF into EIGRP, you're essentially matching any
interface with OSPF enabled, and of course any OSPF routes installed
into the RIB. The /32 route is not actually in your RIB, it is only in
your self-generated Type-1 LSA. This is why EIGRP is advertising that
route as a /24, just as it would if you had done a 'redistribute
connected'.

When you set the network type to 'Point-to-Point', OSPF advertises the
interface with its true prefix, and therefore you achieve consistency
between what OSPF is advertising, and what EIGRP is redistributing.

On Tue, Jan 31, 2012 at 11:07 AM, Scott Strobeck <scott_at_strobeck.net>
wrote:

        Hi everyone,
        
        I noticed today in my lab that I had an unexpected route. After
        chasing
        it down for a while, I found it seems to be an anomaly when
        redistributing ospf->eigrp.
        
        Consider a simple R1--R2--R3 lab where OSPF is running between
        R2&R3,
        and EIGRP between R2&R3. R1 & R2 have a loopback advertised
        into the
        OSPF with network statements. Full redistribution between OSPF
        & EIGRP
        is done on R2.
        
        R2's loopback, left at default, will have a network type of
        LOOPBACK and
        will show up in OSPF as a /32. However, in the EIGRP domain (on
        R3),
        this external route will show up as a /24.
        
        Is this expected behavior? Why would EIGRP have it as a /24
        when OSPF,
        where it came from, has it as a /32. R1's loopback shows up as
        a /32 on
        R3, as expected, so why should this be different for R2's
        loopback?
        
        This may not seem like such a problem until you take R4 and
        connect it
        to both the OSPF and EIGRP domains, and perform full
        redistribution,
        again. Now, the /24 route from R2's loopback will get
        redistributed
        into OSPF as an external route since there's not an internal
        equivalent
        to cancel it out. Ultimately, the route will get advertised
        back to
        R2.
        
        If you add a 3rd point of redistribution between the two IGP's
        (R5), now
        you've created a routing loop for this /24 route and if you shut
        down
        R2, the /24 route created by R2's loopback remains.
        
        I'm tempted to go ahead and open a new ddts for this, but wanted
        to
        check on here, first. There may a good reason why this happens,
        but I
        can't, for the life of me, think of it.
        
        (BTW, as it stands, this would be a great 'gotcha' for the
        lab. . . a
        potential workaround might be to change the loopback's ospf
        network
        type, or to filter off the route in the EIGRP domain.)
        
        Thanks,
        Scott
        
        
        Blogs and organic groups at http://www.ccie.net
        
        _______________________________________________________________________
        Subscription information may be found at:
        http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Jan 31 2012 - 15:25:06 ART