Need help with OSPF virtual Links

mikearama

I just don't understand this...

From the ciscopress book:
"The OSPF virutal link feature should be used only in very specific cases, for temporary connections or backup after a failure."
"In the example, area 0 is discontiguous because of network failure. Router A builds a virtual link to router B, and vica versa."

BUT, the link is physical! In the config, the routers connect over their serial connections. If someone had a router die inbetween RouterA and RouterB, and they then connect a serial link between them both, and they use the right "network area 0" command under the ospf process... haven't they just reconnected Area 0?

I understand the commands used, I just can't get straight why anyone would purposely throw Area 1 into a perfectly good Area 0.

I hope that made sense.
Mike

dtlokee

I don't knowwhat the example looks like you're talking about, but the case for a virtual link to "reconnect" a broken area 0 is typically a case when you have other areas that are also connected to one another allowing a different transit path between the routers. Because area 0 is typically the core of a network and is also redundant, it is typically not required to use virtual links to put a broken area 0 back together. But imagine you have 2 routers in area 0 that have connections to routers in area 1 and area 2. There is a link between routers in area 1 and area 2. The link between the area 0 routers fail and you now have a partitioned area 0, which can be repaired by creating virtual links across area 1 and area 2, or a tunnel interface in area 0.

mikearama

I like your example, dt... and thanks for the reply.

Using your example, a follow up question...

Area1 would still connect to a router in Area0, and Area2 would still connect to a router in the other half of Area0, since Area0 is partitioned. If you put a virtual link between Area1 and Area2, is it safe to say it would use another area besides 0? or can Area0 be used again?

dtlokee

You would need to create a virtual link from the abr between area 0 and 1 to the abr between area 1 and 2, then a virtual link from the abr between area 0 and area 2 to the abr between area 1 and area 2. So all in all you would need 2 virtual links. Alternatly you could create a tunnel interface between the 2 area 0 routers and then enable ospf area 0 on the tunnel link (just watch out for recursive routing through the tunnel interface where the shortest path to the remote end becomes the tunnel itself)

khristov

Also keep in mind the limitations that virtual-link impose. For example the transit area (if you want to connect ABR in area 2 to ABR in area 0 through area 1), area 1 should not be stub area. This area must have full visibility, all LSA type 3 should be allowed to enter in area 1.
In general virtual link is only used in case of a migration (for example service provider merge, or migrate one part of the network to OSPF behind normal areas).
Using tunnels to avoid virtual link feature is possible but does not scale at all because this tunnels has overhead and they are not inteded to carry large amount of traffic.

dtlokee

khristov wrote:

Using tunnels to avoid virtual link feature is possible but does not scale at all because this tunnels has overhead and they are not inteded to carry large amount of traffic.

I know it's off topic but WHAT!?!? since when, what did I miss? Tunnels can carry massive amounts of traffic, and can scale very well (mGRE anyone?), IPSec used in site to site VPNs is a form of tunneling and heck MPLS is a form of tunneling and they are all used very heavily in the networking world. In this example the tunnel would only be used to carry the OSPF traffic to link area 0 back together, so it should not carry too much traffic.

Yes tunnels will add overhead but sometimes they are just better, but there are cases where the amount of overhead can become excessive such as the case of voice across a VPN tunnel where what was an 20 byte payload every 20ms becomes a 300 byte packet every 20 ms, that's alot of overhead.

Paul Boz

With how fast switching technology is, tunnel overhead isn't an issue because hardware is designed around the higher load from tunneling. If your switch isn't capable of using tunneling for resources problems you should upgrade anyway.