OSPF would not reconverge if the interface serving as the router ID was not
part of OSPF (i.e. a router with an interface in BGP or EIGRP that has a
higher IP address than any interface on the same router that is part of
OSPF). In that situation, a link flapping, would cause reconvergence (due
to the disappearing RID) even though there was no change in the OSPF
topology).
Of course this assumes no redistribution is taking place.
John Galt
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Jason
Sent: Thursday, November 30, 2000 10:26 AM
To: Erick B.; Chuck Larrieu; CCIE_Lab Groupstudy List;
[EMAIL PROTECTED]
Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question
about loopback interfaces
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
>
_________________________________
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
