Right. But if a interface bounces that isn't part of
OSPF that shouldn't cause a OSPF reconvergence to
occur. Thats what I was attempting to say below.
--- Jason <[EMAIL PROTECTED]> wrote:
> I thought OSPF is suppose to converge whenever you
> have a change in the
> route. I.e whenever any interface bounce..
> regardless of the OSPF Router ID.
> The difference is probably in terms of the amount of
> "data" being sent.. but
> definitely a covergence would occur..
>
>
>
> ----- Original Message -----
> From: "Erick B." <[EMAIL PROTECTED]>
> To: "Chuck Larrieu" <[EMAIL PROTECTED]>; "CCIE_Lab
> Groupstudy List"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Cc: "Priscilla Oppenheimer" <[EMAIL PROTECTED]>
> Sent: Thursday, November 30, 2000 8:04 PM
> Subject: Re: OSPF Lab - DR behaviour with loopbacks
> WAS: RE: question about
> loopback interfaces
>
>
> > Chuck and others,
> >
> > I've been following this conversation and it is a
> good
> > review.
> >
> > Without a loopback interface, the OSPF RID (Router
> ID)
> > will be the highest IP address on the router when
> the
> > OSPF process becomes active. If that interface
> isn't
> > stable (say the highest IP is on a WAN circuit)
> then
> > when that interface bounces it will cause OSPF to
> > re-converge.
> >
> > Using a loopback interface, the OSPF RID will be
> the
> > highest IP on a loopback when the OSPF process
> starts.
> > If you have OSPF running already and add loopback
> > interfaces OSPF doesn't use the loopback IP
> address
> > for a RID until the OSPF process is restarted,
> removed
> > and added back (copy-paste), or the router is
> rebooted
> > on saved cfg.
> >
> > So for a stable OSPF environment, using loopbacks
> > reduces the chances of un-necessary OSPF
> > re-convergance and updates occuring when a
> interface
> > bounces. Example, if you had no loopbacks and had
> s1
> > and e1 interfaces. s1 having highest IP and was
> RID
> > but s1 wasn't running OSPF - when s1 bounced for
> > whatever reason OSPF would re-converge because the
> > OSPF RID went down and came back up.
> >
> > Also, you don't need to advertise the loopback IP
> > address into routing protocols unless you want to
> > reach that from another device.
> >
> > I hope this clears things up... it's late so I
> hope my
> > explanation makes sense. :) If not, hit me for the
> > mistakes if your ever in Chicago area.
> >
> > Erick B. - Prepping for attempt 2.
> > (Why am I still up at 6am?)
> >
> > --- Chuck Larrieu <[EMAIL PROTECTED]> wrote:
> > > Much as I personally rant about cross posting
> the
> > > two lists, I believe this
> > > one might be worth examination from all levels.
> > >
> > > Recall the questions and answers about the
> purpose
> > > of the loopback
> > > interface, particularly in OSPF. Among the
> answers
> > > proposed is that the
> > > loopback, being always up, provides continuity,
> in
> > > case an interface fails.
> > > In particular, the book answer is that because
> the
> > > loopback is always up, it
> > > provides the means of reaching a router so long
> as
> > > the loopback is reachable
> > > via any interface that remains operational.
> >
> > I wish this lab had been a bit quicker and less
> > > dirty. But it has provided
> > > an interesting learning experience for me.
> Thought I
> > > would pass along my
> > > observations for those who want to ponder yet
> > > another protocol behaviour.
> > >
> > > My supposition:
> > >
> > > ------------------------------------- ethernet
> > > | | |
> > > DR BDR DR/other
> > > | | |
> > > (---frame relay cloud ----)
> > >
> > > >DR ethernet hardware fails.
> > > >
> > > >I would venture a guess that the BDR
> > > >would be promoted because even though there is
> an
> > > alternative route to the
> > > >DR loopback, hellos go only to adjacent
> routers,
> > > and the DR is no longer
> > > >adjacent.
> > >
> > > Well, I proved my point. Under this scenario,
> when I
> > > unplug the DR ethernet
> > > port, the BDR becomes the DR.
> > >
> > > Some router outputs are listed below. I hope
> this
> > > message falls below the
> > > reject size threshold.
> > >
> > > OK. The observations:
> > >
> > > 1) I am correct that in the case of the ethernet
> DR
> > > becoming disabled, the
> > > BDR still becomes the DR.
> > >
> > > 2) If the frame cloud is a different area than
> the
> > > ethernet segment, the
> > > loopback route disappears. This behaviour is
> > > specific to OSPF, because of
> > > the fact that all inter-area traffic MUST pass
> > > through area 0. When the area
> > > 0 link goes down, the route to the loopback may
> > > disappear, depending upon
> > > the OSPF topology.
> > >
> > > 3) When I reconfigured everything so that both
> the
> > > frame relay and ethernet
> > > segments were area 0, and the loopback
> interfaces
> > > remained visible via the
> > > frame segment after disconnecting the ethernet
> > > segment, the process still
> > > occurred as predicted. That is, the BDR became
> the
> > > DR and the DR/Other
> > > became the BDR. The fact that the loopback route
> > > remained visible had NO
> > > EFFECT whatsoever on the DR/BDR situation. Why?
> > > Because the DR/BDR
> > > relationship is unique to a segment. Again, this
> is
> > > a behaviour specific to
> > > OSPF.
> > >
> > > 4) My frame cloud was configured as a point to
> > > multipoint network. As you
> > > will see in the outputs, the routers form full
> > > adjacencies on the frame
> > > segment, but elect no DR or BDR. I believe that
> if I
> > > were to configure the
> > > frame segment as a broadcast network, that DR
> and
> > > BDR's would be elected,
> > > but that those designations would remain local
> to
> > > that segment, and would
> > > have no effect on any transactions on the
> ethernet
> > > segment. I leave that
> > > experiment to some other brave soul.
> > >
> > > Conclusion:
> > >
> > > With regards to OSPF, at least, the idea that
> the
> > > loopback interface
> > > provides any kind of reliability is in and of
> itself
> > > not true. Problems
> > > arise with the advertising of the loopback
> > > throughout the OSPF domain,
> > > particularly when the area 0 connection is lost,
> and
> > > the alternate routes do
> > > not propogate.
> > >
> > > This of course is not an issue with IGRP or
> EIGRP or
> > > even RIP, which do not
> > > have the same restriction with regards to
> routing
> > > behaviours. So while in
> > > OSPF the existence of a loopback interface might
> > > prove to be of no use, and
> > > probably more often than one might care to
> imagine,
> > > it still will prove
> > > quite useful within other routing protocols.
> >
> > <rest snipped to reduce mail size>
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Shopping - Thousands of Stores. Millions of
> Products.
> > http://shopping.yahoo.com/
> >
> >
>
_______________________________________________________
> > To unsubscribe from the CCIELAB list, send a
> message to
> > [EMAIL PROTECTED] with the body containing:
> > unsubscribe ccielab
> >
>
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
