Revisted - OSPF Virtual Links and RIDs

From: Nigel Taylor (nigel_taylor@xxxxxxxxxxx)
Date: Sat Dec 30 2000 - 08:05:59 GMT-3


   
Chuck,
                I finally got a chance to mock this up in the lab and I've
got
some pretty cool results....First of all when I did this using pretty much
the same scenario the virtual link never went down at any time when
 the connection to r3 from r2 was shutdown. After clearing the routes
and ospf redistribution the virtual-link was still up/up.

Theory that stood the test........I then used a external routing
 info.(rip) to advertise routes to the loopback identified with the
virtual-link command. With a direct path/route between both
loopbacks I then shut down the physical link between R1 and R2.
As expected, the virtual-link stayed down and never came back up.

In Doyle's book (Routing TCP/IP) he states that the virtual-link must be
configured between two ABR's and the area it transits must having full
routing info. I take the meaning of this as having a full map of the
network.
There is also a mention of using a non-backbone area, which I also
take to mean - "An OSPF Area" in which case any external routing
info used to obtain a path to the loopback would prove useless if not
 part of an OSPF area that is either directly connected to area or
is connected by the same process a virtual-link

Just some observations..

Any thoughts...!

This is some really cool stuff.

Nigel.

----- Original Message -----
From: Chuck Larrieu <chuck@cl.cncdsl.com>
To: CCIE_Lab Groupstudy List <ccielab@groupstudy.com>
Sent: Sunday, December 24, 2000 1:12 PM
Subject: OSPF Virtual Links and RIDs

> Just got through with one of the multiprotocol redistribution practice
labs
> ( Mentor Labs 4141 )
>
> Got a question regarding virtual links and loopback RIDs.
>
> In the realm of OSPF, when direct ( meaning through the OSPF process )
> access to a particular router is lost, does that mean that any virtual
link
> associated with that router is lost? Well, yes, I know, and duh!
>
> But my question has to do with the placement of the RID into the routing
> process.
>
> The deal is that there is an alternative link to the OSPF area 0. However
it
> is through a different routing protocol. All routes are redistributed
> through that protocol, and when the direct i.e. OSPF link between the two
> endpoints of the virtual link are severed, even though the route to the
RID
> is seen via the redistribution process, the virtual link apparently does
not
> come back up.
>
> This leads back to the question of the value of loopback addresses as a
cure
> all for routing process interruptions. In the scenario I ran, there was a
> classic virtual link.
>
> R1---------R2-------R3 connected via serial links
> Area2....area1.....area0
>
> All routers have loopbacks, which under the rules of the game have become
> the RID's
>
> There is also an external routing domain connecting R1 and R3 via the
> ethernet ports. Redistribution is established, and works just fine.
>
> When I severed the serial link between R2 and R3, the virtual link goes
> down, and does not re-establish itself, even though the RID is being
> advertised as a route into the exterior domain, and remains in the routing
> tables of all routers as external routes.
>
> I kinda expected this behaviour, but it still raises the question of the
> supposed benefit of loopbacks as an interface that is "always up" and
> therefore advantageous to use.
>
> One of those "pitfalls" someone was asking about a couple of weeks back, I
> suppose.
>
> Chuck
> ----------------------
> I am Locutus, a CCIE Lab Proctor. Xx_Brain_dumps_xX are futile. Your life
as
> it has been is over ( if you hope to pass ) From this time forward, you
will
> study US!
> ( apologies to the folks at Star Trek TNG )
>



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:26:13 GMT-3