From: Jason Madsen (madsen.jason@gmail.com)
Date: Sun Feb 22 2009 - 21:50:08 ARST
I feel like a broken record. distrib out in OSPF is permitted on an ASBR.
try the following scenario and then tell me if "distribute-list out is not
allowed:
topology:
R1 -- R2 --R3
configure OSPF area 0 between R1 and R2, EIGRP 100 between R2 and R3. R2 is
an ASBR. Redistribute on R2. Add loopback 0 on R3 with the address
3.3.3.3/32.
On R2:
router ospf 1
distribute-list 1 out
access-list 1 deny host 3.3.3.3
access-list 1 permit any
Is "distribute-list 1 out" not allowed? Look at your routing table on R1
before and after the above commands.
Jason
On Sun, Feb 22, 2009 at 4:34 PM, ALL From_NJ <all.from.nj@gmail.com> wrote:
> You guys have been really good about adding so much info / detail about
> distribute lists and OSPF.
>
> I had forgotten some of this ;-)
>
> Thankfully OSPF spits out a message telling you NO if you try it outbound
> ... I found out, that it did not work because OSPF told me so. Many thanks
> again for all the good info!
>
> I have not heard anything about tunnels and recursive routing, except to
> try it again with unnumbered. I have not labbed that up yet, but will
> hopefully get an opp tonight.
>
> Can I assume that the method I described (using distribute lists inbound)
> is the suggested way? Anything else to solve recursive routing that I
> should practice and study? Hoping I am not forgetting anything ...
>
> Many TIA!
>
> Andrew Lee Lissitz
>
>
>
>
> On Sun, Feb 22, 2009 at 3:53 PM, Jason Madsen <madsen.jason@gmail.com>wrote:
>
>> 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>
>>>
>>
>>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj@gmail.com
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