From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Fri Dec 01 2000 - 03:39:59 GMT-3
I'm not so sure that this would happen as you describe.
Assuming the RID is based on a non-OSPF interface address, and assuming that
the OSPF process initialized, and that the OSPF domain reached stability, I
don't believe the flapping of the non-OSPF interface, or even the
disappearance of the non-OSPF interface, would have any effect on the OSPF
side of things.
I am certain that once the RID is determined, it is permanently installed
into the OSPF process, and it is hell to remove it. I did some experiments
reported recently in another thread in answer to Howard's problem. I and I
am sure I have seen the question elsewhere as well.
Once the RID has been determined by the OSPF process, bringing up another
interface with a higher IP address, or changing the IP address of the
interface that is the basis of the RID, has no effect, until such time as
one reloads the router.
Reloading is the only way I have found to change the RID. Clear IP OSPF
Process does not do so. Re-addressing each and every interface, and removing
old network statements and installing new network statements does not do so.
This does bring to question the exact nature of a virtual link. In a
situation where the topology permits, will a virtual link re-establish
itself if it's first path interface fails?
EG:
RID1.1.1.1
RouterA------Area_0-----------RouterB
| |
| |
RouterC------Area_1----------RouterD
|
|
RouterE(Area_2)
RID 2.2.2.2
The virtual link on router C is defined as area 1 virtual-link 1.1.1.1
The virtual link on router A is defined as area 1 virtual-link 2.2.2.2
If the link between C and A goes down, will the virtual link remain alive,
because there is a path to router A via routers D and B?
Without trying another Q&D, I am surmising the answer is "no" because the
virtual link termination points must be on an ABR, and RouterA is not an ABR
with respect to RouterD
Damn, yet another experiment.....
Chuck
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Louie Belt
Sent: Thursday, November 30, 2000 7:23 PM
To: 'Jason'; 'Erick B.'; 'Chuck Larrieu'; 'CCIE_Lab Groupstudy List';
cisco@groupstudy.com
Subject: RE: OSPF Lab - DR behaviour with loopbacks WAS: RE: question ab
out
loopback interfaces
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: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Jason
Sent: Thursday, November 30, 2000 10:26 AM
To: Erick B.; Chuck Larrieu; CCIE_Lab Groupstudy List;
cisco@groupstudy.com
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." <erickbe@yahoo.com>
To: "Chuck Larrieu" <chuck@cl.cncdsl.com>; "CCIE_Lab Groupstudy List"
<ccielab@groupstudy.com>; <cisco@groupstudy.com>
Cc: "Priscilla Oppenheimer" <cilla@priscilla.com>
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 <chuck@cl.cncdsl.com> 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>
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:57 GMT-3