From: Jason Madsen (madsen.jason@gmail.com)
Date: Sun Feb 22 2009 - 18:53:36 ARST
Hi Net,
"distribute-list out" IS allowed under your OSPF process IF your device is
an ASBR (meaning that your OSPF router is also running another routing
protocol). I would try your test again, but use an ASBR this time.
Knowning the nuances of distribute lists is hugely fundamental in lab
prep'. Although distribute-list out in OSPF isn't really too common, I'd
make sure you're comfortable with it.
Jason
On Sun, Feb 22, 2009 at 1:47 PM, NET HE <he_net@hotmail.com> wrote:
> Jason,
>
> Firstly, I'd like to say thank you for your correcting my understanding.
>
> And I labbed it up, to sum it up
>
> -OSPF
> Under ospf process, distribute-list out is not allowed "OUT direction is
> not allowed in the case of OSPF"
>
> -EIGRP
> Under EIGRP process, distribute-list out followed by routing process such
> as RIP, static, connected etc, is used to prevent specific routes sourced by
> the defined routing process from advertising out in EIGRP process
>
> -RIP
> the same as eigrp
>
>
> Best Regards,
> Net (Xin) He
>
>
>
>
> ------------------------------
> Date: Sun, 22 Feb 2009 12:16:02 -0700
> Subject: Re: Recursive Routing and Tunnels
> From: madsen.jason@gmail.com
> To: he_net@hotmail.com
> CC: all.from.nj@gmail.com; mcnever@gmail.com; ccielab@groupstudy.com
>
>
> well...yes and no. keep in mind "distribute-list out" in OSPF only works
> for external routes (E1 or E2). it can be used to prevent the passing of
> OSPF external routes into another routing protocol / AS, but it can also be
> used to prevent externally learned routes from going into OSPF. I know, if
> we want to prevent routes from going "into" OSPF than why not just use
> distribute-list in? Well, it's just another way to do it. As we all know
> if there are 5 ways to do a task, it's highly possible that the CCIE lab
> will tell us we can't use 4 of the ways.
>
> if OSPF is learning of the 3.3.3.0/24 route from EIGRP, than you can use
> "distribute-list 1 out" in your OSPF process on your ASBR to prevent it from
> entering your OSPF domain. you can use options like " distribute-list 1 out
> eigrp 100" to specify not only the routes, but which protocol they should be
> coming / learned from also. You can't specify an interface however like you
> can with distribute-list in.
>
> Jason
> #23420
>
> On Sun, Feb 22, 2009 at 9:28 AM, NET HE <he_net@hotmail.com> wrote:
>
> I think the command "distribute-list out" Jason referred to is used to
> control routes being redistributed into other routing process. For example,
> redistributing OSPF routes into RIP, you can use either redistribution
> route-map under RIP process to control routes redistributed into RIP or
> distribute-list route-map out RIP under OSPF process to control routes
> redistributed into RIP.
>
> Best Regards,
> Net (Xin) He
>
>
>
>
> > Date: Sat, 21 Feb 2009 22:05:22 -0700
> > Subject: Re: Recursive Routing and Tunnels
> > From: madsen.jason@gmail.com
> > To: all.from.nj@gmail.com
> > CC: mcnever@gmail.com; ccielab@groupstudy.com
> >
> > no, the command is distribute list out...not data-base filter. you can
> do
> > it on ASBRs for external routes. try it out.
> >
> > Jason
> >
> > On Sat, Feb 21, 2009 at 10:03 PM, ALL From_NJ <all.from.nj@gmail.com>
> wrote:
> >
> > > Yeah ... I seem to remember something about this distribute list rule
> ...
> > > Thanks for mentioning this.
> > >
> > > The command:
> > > ip ospf database-filter all out
> > >
> > > This command filters the LSA outgoing, but ... it is not a distribute
> > > list.
> > >
> > >
> > >
> > >
> > > On Sun, Feb 22, 2009 at 12:00 AM, Jason Madsen <madsen.jason@gmail.com
> >wrote:
> > >
> > >> you can do them outbound if you're an ASBR.
> > >>
> > >> Jason
> > >>
> > >> On Sat, Feb 21, 2009 at 9:56 PM, Jason Morris <mcnever@gmail.com
> >wrote:
> > >>
> > >>> something to keep in mind about how ospf distribute lists work
> > >>>
> > >>> you can never do a distribute list OUT with OSPF.
> > >>>
> > >>> OSPF filters LSAs from the ospf database to the routing table vs
> > >>> filtering
> > >>> routes advertised or recieced from a neightbor like eigrp or rip
> does.
> > >>>
> > >>> all the databases in an area have to have the same info or ospf can't
> > >>> calculate paths correctly.
> > >>>
> > >>> if that makes since.
> > >>>
> > >>> jason
> > >>>
> > >>>
> > >>>
> > >>> On Sat, Feb 21, 2009 at 11:35 PM, ALL From_NJ <all.from.nj@gmail.com
> >
> > >>> wrote:
> > >>>
> > >>> > Interesting lab testing tonight, was playing w/ tunnel interfaces
> and
> > >>> OSPF.
> > >>> >
> > >>> >
> > >>> > I had a scenario I was practicing, basically it was:
> > >>> >
> > >>> > NBMA w/ network type of non-broadcast. Can not use neighbor command
> or
> > >>> > make
> > >>> > any config changes to the physical interface on either sides.
> > >>> >
> > >>> > So I created a tunnel and added it to OSPF.
> > >>> >
> > >>> > As you would expect, recursive routing began to occur.
> > >>> >
> > >>> > Here is a nifty debug output which quickly showed why the neighbor
> > >>> bounces:
> > >>> >
> > >>> > R2#debu ip ospf adj
> > >>> > OSPF adjacency events debugging is on
> > >>> >
> > >>> > *Mar 1 04:34:36.531: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled
> > >>> due to
> > >>> > recursive routing
> > >>> > *Mar 1 04:34:37.531: %LINEPROTO-5-UPDOWN: Line protocol on
> Interface
> > >>> > Tunnel1, changed state to down
> > >>> > *Mar 1 04:34:37.531: OSPF: Interface Tunnel1 going Down
> > >>> >
> > >>> > I know one answer to solve this is to simply remove the physical
> link's
> > >>> > network address from OSPF. Odd learning though, as I tried to
> > >>> configure
> > >>> > other method of filters.
> > >>> >
> > >>> > OSPF would not take a distribute list OUT for the tunnel interface
> ...
> > >>> > figured I would simply keep the local physical link's network from
> > >>> being
> > >>> > advertised out via the tunnel. No-go on this.
> > >>> >
> > >>> > OSPF did take a Distribute list IN via the tunnel. I denied the
> local
> > >>> > link's network ... and all was well in la-la land (where I live).
> > >>> >
> > >>> > R1(config-router)#distribute-list 12 in tunnel 1
> > >>> >
> > >>> > Would have been easier and quicker for me to simply remove the
> physical
> > >>> > link's network from OSPF, but I was / am learning ...
> > >>> >
> > >>> > Also, ... I actually prefer a distribute list IN, since if I am
> able to
> > >>> > keep
> > >>> > the physical link's network in OSPF on my hub router, other peers
> will
> > >>> > still
> > >>> > learn about it. I am only filtering via these two routers, and all
> > >>> other
> > >>> > routers still learn about the local link's network.
> > >>> >
> > >>> > Question for the group:
> > >>> >
> > >>> > For recursive learning, any additional thoughts on ways for me to
> learn
> > >>> > this
> > >>> > / explore this / solve this?
> > >>> >
> > >>> > I suppose in all of life, the kiss method is the best ... Just
> figured
> > >>> I
> > >>> > would ping yall to see what insights I might learn.
> > >>> >
> > >>> > Many TIA,
> > >>> >
> > >>> > Andrew Lee Lissitz
> > >>> >
> > >>> > --
> > >>> > Andrew Lee Lissitz
> > >>> > all.from.nj@gmail.com
> > >>> >
> > >>> >
> > >>> > 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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > > --
> > > Andrew Lee Lissitz
> > > all.from.nj@gmail.com
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
>
> ------------------------------
> How fun is this? IMing with Windows Live Messenger just got better.<http://www.microsoft.com/windows/windowslive/products/messenger.aspx>
>
>
>
> ------------------------------
> Windows Live Messenger. Multitasking at its finest.<http://www.microsoft.com/windows/windowslive/products/messenger.aspx>
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:12 ARST