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/
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
