I have a question regarding OSPF behavior and the loopback address. Our
backbone is running OSPF and we have installed a Cache-Flow server to cache
webpages. The cache-flow does not support OSPF so I attempted to
redistribute OSPF into RIP. I use a private address for the loopback on all
of our routers and the advertisement to the cacheflow shows the loopback as
the interface the advertisement is coming from. So, say a network of
192.168.5.1 lies of router A's serial port and the loopback of that router
is set to 10.0.2.2. The route in the cache-flow is: 192.168.5.1 via
10.0.2.2 even though the ethernet address is a totally different network.
Can someone explain why this is happening and what I can do about it? I
have static routes configured now, but I would like to make it dynamic if
possible.
Thanks,
--
Anthony Anderson, MCSE, CCNA
"Man's life, as required by his nature, is not the life of a mindless brute,
of a looting thug or a mooching mystic, but the life of a thinking being --
not life by means of force or fraud, but life by means of achievement."- Ayn
Rand
""Erick B."" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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]
>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
