Re: OSPF & EIGRP redistribution

I'll read it as well. Hoping I don't end up in the 5%.

On Wed, Feb 1, 2012 at 4:52 AM, Aaron <aaron1_at_gvtc.com> wrote:

> Brian thanks for volunteering a write-up on redistribution! ;) While on
> the
> plane to London feel free to write that up and send back to us on GS....I
> promise I'll read it
>
> Please include a few things about mitigating loops and how and when to use
> AD over tagging to aid in avoiding suboptimal routing or oscillation or
> loops. (these are just things I've either seen or heard or read or labbed
> that I could always use more info on)
>
> Thanks Brian
> Aaron
>
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Brian Dennis
> Sent: Wednesday, February 01, 2012 1:09 AM
> To: ccielab_at_groupstudy.com
> Subject: Re: OSPF & EIGRP redistribution
>
> This is the expected behaviour. When you redistribute EIGRP into OSPF,
> EIGRP will do this in a two step manner. First off it will get all of
> routes from the "show ip route ospf" command. Secondly it will then get
> all of the connected interfaces (show ip route connected) that OSPF is
> enabled on (show ip ospf interface brief). Since OSPF is enabled on the
> loopback and it has a /24 mask, EIGRP will bring it in as a /24. The
> concept of loopback network type in regards to OSPF has nothing to do
> with the local redistribution as redistribution occurs between routes in
> the routing table and not from a particular routing protocol's database.
>
> If you remember this two step process that route redistribution goes
> through, your preparation will be a lot easier as it holds true for all
> routing protocols.
>
> I demonstrate this along with the root cause of routing loops in my
> bootcamps. Route redistribution complexity is way overblown and the
> reason is people are attacking a problem without knowing the root cause
> and the process the IOS goes through to perform redistribution. I'll
> venture to bet I could write a blog post on it and keep it about one or
> two pages max and 95% of the people who read it will have a full
> understanding and never fear route redistribution again. It's one of
> the most misunderstood topics in CCIE preparation and really kind of the
> most worthless topic as complex route distribution problems are few and
> far between these days.
>
> Hope to see some of you all in London this week at Cisco Live!
>
> --
> Brian Dennis, CCIEx5 #2210 (R&S/ISP-Dial/Security/SP/Voice)
> bdennis_at_ine.com
>
> Internetwork Expert, Inc.
> http://www.INE.com
>
>
>
> On 01/31/2012 11:07 AM, Scott Strobeck 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> 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 Wed Feb 01 2012 - 10:43:34 ART