From: Jason Madsen (madsen.jason@gmail.com)
Date: Mon Feb 23 2009 - 03:28:21 ARST
any way to make your physical tunnel end-points less preferred or not
learnable through / via the tunnel will prevent recursion e.g. filtering,
modifying the AD etc.
Jason
On Sun, Feb 22, 2009 at 10:20 PM, ALL From_NJ <all.from.nj@gmail.com> wrote:
> Hey team,
>
> I think most of you already knew the answer, but I wanted to try it just
> the same. I did the tunnel and recursive routing test again tonight ... it
> is easier to understand when you can re-create it and 'play with it'. Any
> who ...
>
> This time I configured the tunnel as unnumbered, and the same results ...
> recursive routing. Same solutions to fix this, either:
>
> 1) Distribute list in and deny the local link (in my case it is the
> 10.1.1.0 network)
> 2) Remove the local link from the OSPF configs. IMO, not advisable since
> this would keep this network from being advertised throughout your domain.
>
> BTW - if anyone wants to do some testing as well, here are the configs for
> you to quickly set it up. These configs will cause recursive routing
> errors. You can practice fixing it if you like. ;-))
>
> You only need two routers w/ a cross-over cable / switch between them.
> Have a good night, and HTH,
>
> Andrew Lee Lissitz
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> R4
> !
> interface Loopback44
> ip address 44.44.44.44 255.255.255.255
> !
> interface Tunnel1
> ip unnumbered Loopback44
> tunnel source 10.1.1.4
> tunnel destination 10.1.1.3
> !
> ! (The 10.1.1.0 network is the network between the two routers)
> !
> router ospf 1
> log-adjacency-changes
> network 44.44.44.44 0.0.0.0 area 0
> network 10.1.1.4 0.0.0.0 are 0
> !
> ~~~~~~~~
> R3
> !
> interface Loopback33
> ip address 33.33.33.33 255.255.255.255
> !
> interface Tunnel1
> ip unnumbered Loopback33
> tunnel source 10.1.1.3
> tunnel destination 10.1.1.4
> !
> router ospf 1
> log-adjacency-changes
> network 10.1.1.3 0.0.0.0 area 0
> network 33.33.33.33 0.0.0.0 area 0
>
>
>
>
> On Sun, Feb 22, 2009 at 7:45 PM, ALL From_NJ <all.from.nj@gmail.com>wrote:
>
>> I did not have a ASBR in my testing, was not part of any labs I was doing,
>> ...
>>
>> You are not being a broken record ... repetition is the best teacher (at
>> least this is me hope while with all the labs I am doing!!!).
>>
>> ;-)
>>
>> Am hoping to learn more about recursive routing, was the original reason
>> for this email, but without any feedback, I suppose the method I used
>> (described in my first email) is the best for this. I would love to solve
>> this other ways too, and hope that if anyone has any other ideas, they would
>> share them.
>>
>> Many thanks group,
>>
>> Andrew
>>
>>
>>
>>
>>
>> On Sun, Feb 22, 2009 at 6:50 PM, Jason Madsen <madsen.jason@gmail.com>wrote:
>>
>>> 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
>>>>
>>>
>>>
>>
>>
>> --
>> Andrew Lee Lissitz
>> all.from.nj@gmail.com
>>
>
>
>
> --
> 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