[AUDIO LOGO]
So remember that we have a rule in OSPF
that says all other areas must be directly connected
to area 0, and area 0 must be contiguous--
meaning there can only be one area 0
and all the routers in area 0 have
to have at least one neighbor ship
to another router in area 0.
Now, the reason this is done is to prevent loops in OSPF.
Type 3 LSAs that are passed by the ABRs between the areas
could potentially loop around between multiple ABRs
connecting one area to area 0.
So to prevent this, we have sort of a very simple rule--
an ABR may not receive a type 3 LSA
on any interface that is not a member of area 0.
Because of this, if there is a discontiguous
area 0, or an area not connected to area 0 at all,
this will prevent the OSPF updates
from entering that area.
Now, sometimes these things can't be avoided.
Now, as we jump into this topic, keep in mind
we're going to be talking about virtual links.
And virtual links should really never
be part of your actual design.
We don't generally start off in OSPF saying,
oh, well, let's build it like this and like this.
And well, that means this area doesn't touch area 0,
so we'll just build a virtual link for that
and that's how we'll fix it.
No.
This is going to be to fix something that happened usually
because of an outage or maybe a merger between two companies,
and there's just some reason that we have to put up with a--
we'll say less than optimal OSPF design
for one reason or another.
Now, hopefully, of course, the long-term goal
here is going to be to either fix the problem
or in the case of something like a merger,
maybe redesign our network.
And within a relatively short amount of time,
hopefully fix this issue so that we
don't need to continue using virtual links.
But in this video, we're going to jump
in we're going to take a look at virtual links, a little bit
about their attributes, how they have to be run,
some of their rules and regulations and such.
And then in our next video, we'll
jump into the command line, set some of these
up, and see how they work.
So let's jump in and start talking about some
of the rules and attributes of our virtual links.
So as we said during our introduction there,
virtual links are used to correct some rather
specific area issues, specifically areas that
are not connected to area 0.
Again, remember that is one of our requirements.
And if needed, to repair a discontinuous area 0.
So these are the two things that we're really going
to use our virtual links for.
The primary issues with this are, of course,
if there is no area 0 on a router,
the router will not consider itself to even be an ABR.
And if the router is not an ABR, it's sure as heck
not going to generate type 3 LSAs.
Even if there is an area 0, the router
will consider itself an ABR.
However, as we mentioned, OSPF loop prevention
is going to kick in.
And again, the effect is that these type 3 LSAs are not
going to be allowed to show up on any interface that is not
in area 0.
Now, we'll still learn it in the database
because the fundamental rule of OSPF
is that all routers in an area have
to share the same database, but we will not
set the routing bit.
This means that we will not be using it.
So yes, it will be in the database,
but we will not be allowed to actually use it.
In other words, putting it into our routing table, of course.
Now, just some other attributes and rules
with OSPF virtual links is that this is really just
to correct and fix, hopefully, temporary situations.
Again, maybe because of outages, maybe
because of a merger with another company,
but these really should not be built into our OSPF design.
Also keep in mind that virtual links are just a control plane
tunnel.
They are not a data plane tunnel.
This can actually lead to loops in some rather poor designs
if you don't understand this.
The routers in the middle are not
going to be aware of the virtual link and the traffic itself
is not tunneled.
As a quick example, imagine that we simply had four routers--
two of these are ABRs.
We'll simply connect them together
like this and these two ABRs connect out
to the rest of the network where maybe there's a network
X that we're trying to get to.
We're not going to get into all the details of why we would
need a virtual link here, but again,
for the sake of argument, let's say
that we build a virtual link and we build it
from this router to this router.
Again, the reason could be maybe this
is area 0 over here on the left and maybe
this router up here is connected to some other area 0 as well.
So we're trying to join our area 0.
Here's where the problem could potentially come in.
What if this link down here had a cost of 100
where all the other links have a cost of 1?
What could potentially happen is traffic
coming in from area 0 on this router
would figuratively speaking go through the virtual link.
But again, the virtual link is only a control plane tunnel.
This is where the problem comes in.
From a physical perspective, it's
going to try to forward the traffic towards this ABR.
And from this top router's perspective,
that best path would be to go down this way.
And right here is where the problem comes in.
When the traffic hits this router on the bottom right,
all it's looking at is the destination.
It's looking at how to get to network X over here,
and it sees a cost of 100 to go to the left and only a cost
of 2 to go across the top.
So what does it do?
It sends the traffic right back up this way--
and just like that, you have a routing loop.
Now, there are, of course, numerous ways
to fix this problem.
First, I could build a virtual link to both ABRs
and then it wouldn't necessarily be a problem.
I can adjust these costs so that the router on the bottom right
there agrees on which way to send the traffic.
There's a couple of ways we could fix this.
But the point is since this is only
a control plane tunnel, not a data plane
tunnel, just be aware that in--
we'll call them really bad designs--
this could, in fact, potentially create a loop.
So this is something we want to watch out for.
Next, just as a general rule here,
a virtual link can only traverse a normal area.
In other words, it cannot go across a stub or an NSSA,
it has to be a normal area.
Also keep in mind that the virtual link just by its nature
is always a member of area 0.
What we were doing with our virtual link
here in our diagram is we were simply connecting this area
0 with this area 0 because this virtual link is also, again,
by nature in area 0 therefore we made a contiguous area 0.
Another rule here is that a virtual link can only
traverse one area at a time, but they can be changed together.
That simply means that if we say,
for example, had a router here, a router here, a router here,
and we say, for example, they're just linked together.
Over here we have area 0, maybe between these, we have area 51.
Over here is area 37.
And then over here, we have area 0 again.
Again, the virtual link can only be built between the ABRs
in one area.
However, I could build one virtual link
through area 51 like this, and then
simply build another virtual link through area 37
and therefore, once again join area 0 because, again, these
are members, of course, of area 0.
Again, this would be an absolutely horrible design,
but it could be done.
Just a couple other things to keep in mind.
If area 0 is authenticated like we talked about
in our last video, we also have to put a key
on the virtual link.
Now, there is some default behavior what happens here.
We'll talk about that as we go through configuration.
So it does depend a little bit on the IOS
what actually happens here, so that will take a little bit
more discussion.
But just as a general rule, don't
forget to authenticate the virtual link because it
is a member of area 0.
Virtual links are run as demand circuits.
What that simply means is that the hellos are suppressed.
There's no need to send hellos over the virtual link.
It simply relies on the underlying hellos
to ensure that all of the neighbors are up.
Also as part of being a demand circuit,
we also use Do Not Age, or DNA, on all of the LSAs
in the database.
This means they will not age out the same way
that they do with normal LSAs.
This can actually become an issue
with clearing up the database if you
have to get rid of the virtual link later.
So again, you put it in as a temporary repair hopefully,
and then later, you're going to get rid of it.
These LSAs will just stay in the database
potentially until you reset all of your OSPF routers,
or at least all the routers in that area.
Now, they will go to unused.
So is this really a massive problem?
No.
But they'll also never age out.
So this is something to keep in mind.
You may see these entries and wonder why
they're still in your database.
Even after you get rid of the virtual link,
they'll stay there.
So at some point, maybe during a maintenance window,
you might want to reload some of these routers
or at least clear the OSPF processes to clear
these out of the database.
Also keep in mind just when it comes to configuration
that these are configured or built between OSPF router IDs.
We do not use IP addresses when we're building virtual links.
They're formatted like IP addresses
just because router IDs are, in fact, 32 bits, but they're not.
One final thing to keep in mind is in RFC 3509,
there's reference to something called an inactive area 0.
This is essentially a router that has an area 0,
but has zero neighbors in area 0.
It sort of makes it like a pseudo ABR.
It's not really an ABR because it has no neighbors in area 0,
but on the other hand, it does have interfaces in area 0.
So it's sort of a pseudo ABR and because it cannot create a loop
without that link or neighbor ship in area 0,
we actually break the loop prevention rule and it allows
those type 3 LSAs to arrive on that non-area 0 interface.
Remember that that rule is for loop prevention
and we don't need that if there's
zero possibility of a loop.
So in this video, we got an introduction to virtual links.
We took a look at some of their attributes,
when we should or shouldn't use them,
which not using them should really be most of the time.
We shouldn't design our networks to use virtual links.
These are something that are used
to fix a problem that comes up later,
again, usually due to some sort of a failure
or possibly a merger between companies.
Either way, these should be used temporarily
until we can find a more permanent and better solution
to the problem.
I hope this has been informative for you.
And I'd like to thank you for viewing.