Forgot to mention, let me know if you need logs I think i have it
thanks,
rahul.
----- Original Message -----
From: "Rahul Kachalia"
Newsgroups: groupstudy.cisco
Sent: Wednesday, October 30, 2002 2:26 PM
Subject: Re: Update: OSPF Route mystery - what am I missing [7:55975]
Chuck,
I may not all answers, but have few broken pieces which may help you...
When multiple ASBR advertises same LSA then router will choose an ASBR
that advertises lowest cost, if advertised cost from both ASBR is same then
lowest internal cost to reach ASBR will be considered. If advertised cost of
LSA & cost to reach ASBR is same in such case load-balancing will occur.
I tried identical scenario few months ago to check/debug loop &
following is my few findings (based on your topology)...
1. Upon receiving update from R4, R1 & R3 updates their RIP database &
redistributes into OSPF domain.
2. This will be flooded throughout the domain & both R1 & R3 prefers R2 for
route that is originated in RIP (This is because of adm.distance). And
flushes their RIP database.
3. Since RIP database is flushed LSA will removed or advertised as
unreachable to R2 by R1 & R3.
4. Within next 30 seconds, it repeats same story from step1 onwards.
You may have observed random ASBR selection by R2, this may be due to
timing-issue of updating & advertising on R1 & R3. First fix R1 & R3 by
route-map/distance etc to prefer R4 for routes advertised by R4, later you
will see R2 will choose R1 as ASBR but still has LSA info in LSDB. If you
want to load-balance then make equal cost between token ring & serial & see
if you can get your results. Make sure all the time you watch both RIP/OSPF
database changes while there is loop, its fun ;-)
thanks,
rahul.
""The Long and Winding Road"" wrote in
message news:200210210158.BAA20429@;groupstudy.com...
> in line ( like the skates )
>
>
> ""Nigel Taylor"" wrote in message
> news:200210202246.WAA27657@;groupstudy.com...
> > Chuck,
> > I can't believe anyone understood a word I wrote. After
> reading
> > my post I could only laugh. Nonetheless, I think you got what I was
> trying
> > to say and I do believe your thoughts and observations are correct. In
> > reading your post I was trying to recall what could have possibly
provided
> > the material for the discussion you mentioned.
> >
> > The author that comes to mind is no other than "Terry Slattery".
>
> CL: Slattery remains an interesting read. A lot different, and maybe not
a
> landmark work, a la Doyle, but still worth looking at.
>
>
> >I too did
> > notice the constant flapping of R4's common network using the "debug ip
> > routing" command.
> > I must say this is definitely interesting. Lately, I've had the
> opportunity
> > to look at a few situations where the use of RIP lead to some very
unique
> > results as it pertains to redistribution. (check this one out...
> > http://www.cisco.com/warp/public/104/10.html).
> > Look at the route table on r2504 take note of the 3.22.x.x and 3.44.x.x
> > networks. Why is it on r2507 that the routes show as ospf exteranl type2
> > routes. This is just another example of how rip simply works outside of
> the
> > rules.
>
> CL: I was going to say that it's because the routes are RIP routes that
have
> been redistributed into OSPF. However, looking at the configuration, I see
> the interfaces are in the OSPF domain as well. Maybe the configuration is
> being misreported? Maybe if an interface is in both a RIP and an OSPF
> domain, RIP takes preference? That can't be right.
>
> CL: hhhmmmmmmm...... fooling around with the configs a bit. Mystery upon
> mystery. I can't duplicate the result on the CCO link below. I'm wondering
> if there are some IOS bugs.
>
> CL: the other thing I got to wondering is if there is some provision in
the
> standard in the case of multiple ABSR's advertising the same route. I
can't
> find anything off hand. It might require a more careful read than I have
> time for right now.
>
>
> >
> > Although, at first look everything does seem to be very
straight-forward,
> > not until you get under the hood do you really see or observe the real
> > issues involved. Thanks for keeping us all sane :-)
> >
> > Nigel
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "The Long and Winding Road"
> > To:
> > Sent: Sunday, October 20, 2002 5:33 PM
> > Subject: Re: Update: OSPF Route mystery - what am I missing [7:55975]
> >
> >
> > > funny you should mention it. I've spent the last forty minutes looking
> at
> > > debugs on all of the routers involved.
> > >
> > > given the topology,
> > >
> > > R1--------tr----------R2
> > > | |
> > > | serial | serial
> > > | |
> > > R4--------tr----------R3
> > >
> > > R1, R2, and R3 are OSPF routers
> > > R1, R4, and R3 are RIP ver 2 routers
> > >
> > > 2 way redistribution occurs on R1 and R3. The configurations for
> > > redistribution are identical on both routers--
> > >
> > >
> > > here is what I believe I am seeing:
> > >
> > > R4 is advertising RIP routes to both R1 and R3
> > >
> > > R1 and R3, in turn, redistribute those routes into OSPF as E2's
> > >
> > > R2 receives those routes and installs them into the routing table.
> > >
> > > However, shortly thereafter R2 flushes those routes. Why? Well,
looking
> at
> > > the debugs on R3 and R1, what is happening is that the E2 routes are
> > > replacing the RIP routes on R1 and R3. Then, depending on the timing,
> the
> > R4
> > > routes show up in the R2 table sources from one router or the other.
> > >
> > > When I turn off mutual redistribution on R1 and R3, I start seeing
> results
> > > like this:
> > >
> > > O E2 160.160.30.0/24 is possibly down,
> > > routing via 160.160.255.2, TokenRing0
> > > O E2 160.160.31.0/24 is possibly down,
> > > routing via 160.160.255.2, TokenRing0
> > > O E2 160.160.32.0/24 is possibly down,
> > > routing via 160.160.255.2, TokenRing0
> > > O E2 160.160.33.0/24 is possibly down,
> > > routing via 160.160.255.2, TokenRing0
> > > O IA 160.160.39.0/26 is possibly down,
> > > routing via 160.160.255.2, TokenRing0
> > >
> > > Note that 160.160.3X.0 routes originate on R3. I have similar things
> > > happening on R3
> > >
> > > With mutual redistribution turned on, the situation is a bit
different.
> > The
> > > routes just go round and round from router to router, being
distributed
> > and
> > > redistributed forever, so that even though the domain is unstable, to
> the
> > > casual eye, everything is fine. All routes are reachable, although not
> > > necessarily via the interface over the protocol one would hope
> > >
> > > Nigel, I believe we have had this conversation before - about where
the
> > > redistribution process goes to get the information it uses in the
> > > redistribution process. It is reasonable to think that when one
> > redistribute
> > > OSPF into something else, that the redistribution process goes to the
> OSPF
> > > database. For rip, where can it go but the routing table, and if all
the
> > RIP
> > > routes have been replaced by OSPF routes, then it has nothing to
> > > redistribute?
> > >
> > > Not saying this is true, Just saying this is what appears to be true.
> > >
> > > Chuck
> > >
> > >
> > > ""Nigel Taylor"" wrote in message
> > > news:200210202001.UAA01188@;groupstudy.com...
> > > > Alright Chuck, John,
> > > > I looked at this little OSPF route
> > mystery
> > > > and let me say that whenever rip and ospf are involved in "mutual
> > > > redistribution" nothing is everything's a mystery. It took some
> thought
> > > but
> > > > I believe the answers to what you're observing resides within the
> > > > configuration of R1 and R3. Let's get the most important question
> > > > answered..
> > > >
> > > > Did you configure filtering when performing redistribution? Not that
> > this
> > > > will help :-)
> > > >
> > > > Basically, the problem is that on R1 and R3 the ospf learned route
for
> > the
> > > > common network on R4 is being proffered. The redistributing
> > routers(R1/R3)
> > > > see the best path to the r4 networks depending on which
router(R1/R3)
> > > > cleared their routes or shut down a specific interface most
recently.
> > This
> > > > is simply because the ospf form of the route(on R1/R3) has a better
AD
> > > which
> > > > overrides the propagated rip routes from R4. Therefore, all R1 and
R3
> > both
> > > > will at times show R2 as the path to the R4 common networks..
> > > >
> > > > Can someone say "distance" :-)
> > > >
> > > > Nigel
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "John Neiberger"
> > > > To:
> > > > Sent: Sunday, October 20, 2002 12:45 PM
> > > > Subject: Re: OSPF Route mystery - what am I missing. [7:55953]
> > > >
> > > >
> > > > > Chuck,
> > > > >
> > > > > I'm stumped so far, too. Did you try using some debugging?
Perhaps
> > the
> > > > R2
> > > > > might be able to give you a clue about why it's making that
> decision.
> > > > Debug
> > > > > ip routing might do the trick. If not, there must be some OSPF
> > debugging
> > > > > that would give us a hint.
> > > > >
> > > > > John
> > > > > ""The Long and Winding Road"" wrote in
> > > > > message news:200210200115.BAB17079@;groupstudy.com...
> > > > > > Or - what I believe versus what I see.
> > > > > >
> > > > > >
> > > > > > The topology:
> > > > > >
> > > > > > R1--------tr----------R2
> > > > > > | |
> > > > > > | serial | serial
> > > > > > | |
> > > > > > R4--------tr----------R3
> > > > > >
> > > > > >
> > > > > > R1, R2, and R3 are OSPF routers
> > > > > > R1, R4, and R3 are RIP ver 2 routers
> > > > > >
> > > > > > 2 way redistribution occurs on R1 and R3. The configurations for
> > > > > > redistribution are identical on both routers.
> > > > > >
> > > > > > There are uniquely identified routes assigned to loopback
> interfaces
> > > of
> > > > > all
> > > > > > routers.
> > > > > >
> > > > > > I believe I should see two paths to all of R2's interfaces on R4
(
> > one
> > > > > > through R1 and the other through R3 )
> > > > > >
> > > > > > I believe I should see two paths to all of R4's interfaces on R3
(
> > one
> > > > > > through R1 and the other through R3 )
> > > > > >
> > > > > > On R4 I do indeed see the two equal cost routes installed:
> > > > > >
> > > > > > R 160.160.254.254/32 [120/2] via 160.160.127.1, 00:00:18,
> > > Serial0
> > > > > > [120/2] via 160.160.125.3, 00:00:17,
> > > > TokenRing0
> > > > > > R 160.160.202.128/25 [120/2] via 160.160.127.1, 00:00:26,
> > > Serial0
> > > > > > [120/2] via 160.160.125.3, 00:00:25,
> > > > TokenRing0
> > > > > > R 160.160.200.0/24 [120/2] via 160.160.127.1, 00:00:27,
> > Serial0
> > > > > > [120/2] via 160.160.125.3, 00:00:26,
> > > TokenRing0
> > > > > > R 160.160.201.0/25 [120/2] via 160.160.127.1, 00:00:27,
> > Serial0
> > > > > > [120/2] via 160.160.125.3, 00:00:26,
> > > TokenRing0
> > > > > > R 160.160.204.0/27 [120/2] via 160.160.127.1, 00:00:27,
> > Serial0
> > > > > > [120/2] via 160.160.125.3, 00:00:26,
> > > TokenRing0
> > > > > > R 160.160.222.0/24 [120/2] via 160.160.127.1, 00:00:04,
> > Serial0
> > > > > > [120/2] via 160.160.125.3, 00:00:05,
> > > TokenRing0
> > > > > > Router_4#
> > > > > >
> > > > > > However, on R2, I do not see equal cost paths
> > > > > >
> > > > > > O E2 160.160.40.0/24 [110/20] via 160.160.254.3, 00:13:33,
> > Serial0
> > > > > > O E2 160.160.41.0/24 [110/20] via 160.160.254.3, 00:13:33,
> > Serial0
> > > > > > O E2 160.160.42.0/24 [110/20] via 160.160.254.3, 00:13:33,
> > Serial0
> > > > > > O E2 160.160.43.0/24 [110/20] via 160.160.254.3, 00:13:33,
> > Serial0
> > > > > > O E2 160.160.44.0/24 [110/20] via 160.160.254.3, 00:13:33,
> > Serial0
> > > > > > O E2 160.160.45.0/24 [110/20] via 160.160.254.3, 00:13:35,
> > Serial0
> > > > > >
> > > > > > Router_2#
> > > > > >
> > > > > > now here is the kicker. On R2, I shut down the serial interface
> > > between
> > > > R2
> > > > > > and R3. Note that all the routes I am looking for show up over
the
> > TR
> > > > > > interface. routes in the 160.160.10X.0 series are physically
> located
> > > on
> > > > > R1,
> > > > > > but are in the RIP domain.
> > > > > >
> > > > > > O E2 160.160.40.0/24 [110/20] via 160.160.255.1, 00:00:02,
> > > TokenRing0
> > > > > > O E2 160.160.41.0/24 [110/20] via 160.160.255.1, 00:00:02,
> > > TokenRing0
> > > > > > O E2 160.160.42.0/24 [110/20] via 160.160.255.1, 00:00:02,
> > > TokenRing0
> > > > > > O E2 160.160.43.0/24 [110/20] via 160.160.255.1, 00:00:02,
> > > TokenRing0
> > > > > > O E2 160.160.44.0/24 [110/20] via 160.160.255.1, 00:00:02,
> > > TokenRing0
> > > > > > O E2 160.160.45.0/24 [110/20] via 160.160.255.1, 00:00:02,
> > > TokenRing0
> > > > > > O E2 160.160.100.0/24 [110/20] via 160.160.255.1, 00:00:03,
> > > > TokenRing0
> > > > > > O E2 160.160.101.0/24 [110/20] via 160.160.255.1, 00:00:03,
> > > > TokenRing0
> > > > > > O E2 160.160.102.0/24 [110/20] via 160.160.255.1, 00:00:03,
> > > > TokenRing0
> > > > > > O E2 160.160.103.0/24 [110/20] via 160.160.255.1, 00:00:03,
> > > > TokenRing0
> > > > > > O E2 160.160.104.0/24 [110/20] via 160.160.255.1, 00:00:03,
> > > > TokenRing0
> > > > > > O E2
> > > > > >
> > > > > > Now I re-open the R2-R3 connection and observe that the routes
> homed
> > > on
> > > > R1
> > > > > > still appear via the token ring interface, but the routes homes
on
> > R4
> > > > show
> > > > > > up via the serial interface.
> > > > > >
> > > > > > O E2 160.160.40.0/24 [110/20] via 160.160.254.3, 00:00:36,
> > Serial0
> > > > > > O E2 160.160.41.0/24 [110/20] via 160.160.254.3, 00:00:36,
> > Serial0
> > > > > > O E2 160.160.42.0/24 [110/20] via 160.160.254.3, 00:00:36,
> > Serial0
> > > > > > O E2 160.160.43.0/24 [110/20] via 160.160.254.3, 00:00:36,
> > Serial0
> > > > > > O E2 160.160.44.0/24 [110/20] via 160.160.254.3, 00:00:36,
> > Serial0
> > > > > > O E2 160.160.45.0/24 [110/20] via 160.160.254.3, 00:00:36,
> > Serial0
> > > > > > O E2 160.160.100.0/24 [110/20] via 160.160.255.1, 00:00:34,
> > > > TokenRing0
> > > > > > O E2 160.160.101.0/24 [110/20] via 160.160.255.1, 00:00:34,
> > > > TokenRing0
> > > > > > O E2 160.160.102.0/24 [110/20] via 160.160.255.1, 00:00:34,
> > > > TokenRing0
> > > > > > O E2 160.160.103.0/24 [110/20] via 160.160.255.1, 00:00:34,
> > > > TokenRing0
> > > > > > O E2 160.160.104.0/24 [110/20] via 160.160.255.1, 00:00:34,
> > > > TokenRing0
> > > > > > O E2
> > > > > >
> > > > > >
> > > > > > Now I'm thinking that with two redistribution points, and the
> routes
> > > > > > redistributed as E2's, where the cost does not change.
> > > > > >
> > > > > > As a sanity check, I created a loopback on both R1 and R3 with
an
> > > > > identical
> > > > > > address 99.99.99.1/32. It took a bit of manipulating, but I
> managed
> > to
> > > > > > present both routes to R2 as equal cost. here is the routing
table
> > > > > excerpt.
> > > > > >
> > > > > > O IA 99.99.99.1 [110/26] via 160.160.254.3, 00:00:01, Serial0
> > > > > > [110/26] via 160.160.255.1, 00:00:01,
> TokenRing0
> > > > > >
> > > > > >
> > > > > > So now, why is it that E2 routes, sourced from two different
> > > interfaces,
> > > > > > both with equal costs of 20, do not both appear in the R2
routing
> > > table
> > > > > > simultaneously. I "believe" this should not happen.
> > > > > >
> > > > > > Anyone gotta clue? I sure don't.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > www.chuckslongroad.info
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=56555&t=55975
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
