From: sabrina pittarel (sabri_esame@yahoo.com)
Date: Fri Aug 11 2006 - 20:33:06 ART
Ohh btw,
the source of my troubles was IEWB lab 13 task 4.7
When I did the lab I came out with the same cfg as the
proposed solution but it wasn't working.
So now that I'm done with the labs I'm going back to
the tasks that I had trouble solving and I'm trying
them again.
So I ended up running in the OSPF/distance task once
again and I started experimenting trying to find a
logic behind what I was seeing. No use.
I even thought of a bug and I switched image but it
didn't help. I searched the Cisco documentation for
some caveat, couldn't find anything.
So, you are my last hope.
Sabrina
--- sabrina pittarel <sabri_esame@yahoo.com> wrote:
> Hi Michael,
> I know the theory behind the use of the distance
> command, and I know that the reason why the ping to
> R6
> and/or R5 loopbacks fails because R1 sends the echo
> request to R2 and even if it'll make it all the why
> to
> R4, R4 it'll send it back to R3.
> What puzzles me is why the router doesn't do what
> is
> supposed to in my topology.
> I'm explicitly telling him to set the distance to
> 109
> for routes coming from a particular route-source.
> Why
> the hell is not doing it!!
> Sorry. It is driving me crazy.
>
> Sabrina
>
> --- Michael Stout <michaelgstout@hotmail.com> wrote:
>
> > I don't think you network is a good candidate for
> > studying distannce.
> >
> > try this
> > r1-----------r2---------r3------r4
> > r1----------r6---------r5-------r4
> > OSPF on top RIP on bottom>
> > redistriburte mutually using default rip metric of
> > 1>
> > from r1 trace to R5 rip>
> > You trace will go r2--r3--r4--r5
> > that is because ospf has a better DISTANCE and r1
> > thinks the path to r5
> > is one hop away if it uses the ospf path but it
> > thinks the path to R5 is
> > 2 hops away if it takes the path through r6.
> > You need distance so you use the native protocol
> >
> > Next ad loopbacks to R6 and R5.
> > You will not be able to trace to the loopbacks
> from
> > the ospf network
> > You need to use distance to kill the loop
> >
> >
> >
>
--------------------------------------------------------------------
> >
> > From: sabri_esame@yahoo.com
> > Reply-To: sabri_esame@yahoo.com
> > To: ccielab@groupstudy.com
> > Subject: OSPF and the distance command
> > Date: Fri, 11 Aug 2006 17:50:07 -0400
> > Hi all,
> > I'm trying to understand how ospf behaves in
> > relation with the
> > following command:
> >
> > distance <#> <route-source> <wildcard> <acl>
> >
> > I have the following topology:
> >
> > R1 --------
> > |
> > R3
> > |
> > R2 --------
> >
> > R1, R2 and R3 are all in area 0. All routers
> have
> > their loopbacks
> > advertised in area0.
> >
> > R1 and R2 are also ASBRs and can reach the same
> > set of external
> > networks.
> >
> > I want to configure R3 in such a way it will
> > forward all traffic for
> > external networks to R2.
> > I know I can accomplish that modifying the
> > redistribution metrics in
> > R1
> > and R2, but as I said I'm trying to understand
> how
> > the *distance*
> > command behaves.
> >
> > I thought I could solve the problem doing the
> > following:
> >
> > R3
> > ---
> >
> > router ospf #
> > distance 109 <R2 RID> 0.0.0.0 1
> >
> > access-list 1 deny <R1's loopback>
> > access-list 1 permit any
> >
> > but it doesn't work.
> >
> > All external routes are still load balanced
> > between R1 and R2 and
> > show
> > up in the routing table with AD 110.
> > The only route with AD = 109 is R2's loopback.
> If
> > I remove the acl
> > from
> > the distance command, i.e.
> >
> > distance 109 <R2 RID> 0.0.0.0
> >
> > also R1's loopback will be shown with distance
> 109
> > and R2 will be
> > preferred (!!!). All other routes will still be
> > load balanced and
> > will have
> > AD 110
> >
> > Only if I shut the link between R1 and R3 I
> > finally see these routes
> > with an AD of 109.
> >
> > I really don't understand what is going on, any
> > ideas?
> >
> > Thanks
> > Sabrina
> >
> >
> >
>
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:56 ART