Everyone, this has been, and continues to be an excellent thread. My thanks
to all of you for participating. I for on have learned a new thing or two.
Furthermore, I have enjoyed reading all of the responses.
I probably didn't make it clear in my original post that the genesis of this
Q&D lab was to demonstrate one way or another the value of configuring a
loopback address for a particular reason. Someone stated the belief that
having a RID based on a loopback address would prevent the loss of the DR on
a segment even though the interface on that segment went down, because the
loopback remained up, and the BDR would continue to be aware of the DR, and
therefore would not be promoted. I believe that my Q&D amply demonstrated
that this supposition was false.
That led to my wondering about the value of the loopback in terms of route
stability in general.
You all have made several excellent points about the purpose of the RID in
the OSPF process. Enough so that you have convinced me that in OSPF design
in particular it is far better to include a well thought out loopback
addressing scheme as f the overall design than it is to just leave things to
chance.
Thanks again for this wonderful discussion.
Chuck
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tony
Olzak
Sent: Thursday, November 30, 2000 7:15 PM
To: Jason; Erick B.; Chuck Larrieu; CCIE_Lab Groupstudy List;
[EMAIL PROTECTED]
Subject: Re: OSPF Lab - DR behaviour with loopbacks WAS: RE: question about
loopback interfaces
Yes, a convergence would occur anyway, but if the Router ID changes, a lot
more things could go wrong. For example, virtual links are configured using
the Router ID. If the router ID changes (like by having a serial interface
your RID), the virtual link goes down.
Having loopbacks as your Router IDs also allows for you to more easily
manage your OSPF network. All entries in the OSPF database are based on
RIDs. If you make all your loopbacks in the same network (i.e. R1 is
10.0.0.1, R2 is 10.0.0.2), it makes it easier to identify the routers. Since
the loopback itself does not need to be in OSPF, it doesn't matter that
they're all on the same network. Or, you could just use a mask of /32.
I'm not saying you'll be able to do this in the lab, just real world tips.
Tony
----- Original Message -----
From: "Jason" <[EMAIL PROTECTED]>
To: "Erick B." <[EMAIL PROTECTED]>; "Chuck Larrieu" <[EMAIL PROTECTED]>;
"CCIE_Lab Groupstudy List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, November 30, 2000 11:26 AM
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
> >
>
> _______________________________________________________
> To unsubscribe from the CCIELAB list, send a message to
> [EMAIL PROTECTED] with the body containing:
> unsubscribe ccielab
>
_______________________________________________________
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]
