Virtual Links
You would never design a network with virtual links in mind, they are there to be used as a fix (band-aid) till you can fix/redesign the network;
Notice the lack of connection to AREA0 from AREA2... this could of been a company merger or take over, where AREA0 is the HQ, AREA 1 are the branch offices and AREA 2 is the competetion (which you just took over) so as a quick fix you can create a virtual link back into area 0
Lets see up Router2:
The command is adding a virtual link from the ABR (AREA1) that joins us to the backbone area (AREA0), Notice it is after the ID, which is the IP address of the neighbour (the RID), now we have to add the link the other way (back from R2 to R3)
Once we have applied the command, the neighbourship is formed, notice the VL0 (Virtual Link zero) now this interface will not appear under show ip int brief, but you can see it with show ip ospf virtual-links.
Now you could do this with the virtual link, with other tunnels ..GRE tunnels (as Jeremy mentions on the CCIE lab, you have to link an are back to AREA0 but without using the virtual-links command)*
We are now getting the route on R3 and also R4 :0)
* See Darrens blog for a lab which shows this "virtual link" but via a GRE tunnel:
http://mellowd.co.uk/ccie/?p=1683
OSPF AREAS AND ROUTER TYPES
RECAP:
We divide off areas of our network, to help with the load of the SPF algorighm running to often, updates being to numeours (when the network is to large), so by splitting it into smaller areas we make the topology database smaller which increases performance and we can also summarise on the area boundaries (the ABR's)
- LSA 1 (Router LSA)
Generated by all routers in an area to describe their directly attached links (Intra-area routes). These do not leave the area.
- LSA 2 (Network LSA)
Generated by the DR of a broadcast or
Nonbroadcast segment to describe the neighbors connected to the segment.
These do not leave the area.
- LSA 3 (Summary LSA)
Generated by the ABR to describe a route to neighbors outside the area. (Inter-area routes)
- LSA 4 (Summary LSA)
Generated by the ABR to describe a route to an ASBR to neighbors outside the area.
- LSA 5 (External LSA)
Generated by ASBR to describe routes
redistributed into the area. These routes appear as E1 or E2 in the
routing table. E2 (default) uses a static cost throughout the OSPF
domain as it only takes the cost into account that is reported at
redistribution. E1 uses a cumulative cost of the cost reported into the
OSPF domain at redistribution plus the local cost to the ASBR.
- LSA 6 (Multicast LSA)
Not supported on Cisco routers.
- LSA 7 (NSSA External LSA)
Generated by an ASBR inside a NSSA to
describe routes redistributed into the NSSA. LSA 7 is translated into
LSA 5 as it leaves the NSSA. These routes appear as N1 or N2 in the ip
routing table inside the NSSA. Much like LSA 5, N2 is a static cost
while N1 is a cumulative cost that includes the cost upto the ASBR.
Lets look at R1s routing table;
Notice how R1 is getting route information about the other WAN links, the RIP external routes, but in all honestly R1 doesn't need to know all this information as his only way out to the rest of the network is via R2....its like OSPF is overkill really, a simple static would surfice, but then this takes away the ease of administration etc etc ...
Thats where .....
the neighbourship will drop, as if you recall the stubby flags in the HELLO packet must match between neighbours, and currently they do not, so hence we had to change R1 and then neighbourship came back up
Notice, the routing table for R2 will not change:
the Stub config will only apply to the router within the AREA, not the ABR! So lets check R1:
Notice all the External routes are gone (192.....) and we have a default route in there from the ABR, which knows it is filtering some routes for R1, so it passes on this default route :0)
Next, lets look at the TOTALLY STUBBY area (This is cisco proprietary, although other vendors have implement it in similar ways, so the ABR has to be a cisco device with this config), now remember this will block everything from coming in, lets check R5's routing table first though:
lets config the routers:
Notice i do not have to put no-summary at the end of the config on R5, we can keep this industry standard, as it is only recieving the messsages.
Lets check the routing table:
Sweet, there it is....a default route from R4, everything else has been removed (all what we would see is routes from our own area, had we had any)
NOT SO STUBBY AREAS
If we now look at R5, it is configured a TOTALLY STUBBY area, but it is now connected to a RIP network, which makes it a ASBR .... BUT it cannot send this RIP routes into the OSPF network becuase it is a totally stubby area, thats where the NOT SO STUBBY config comes from:
we also need to remove the stub config we put in before:
lets check the routing table:
Excellent, there it is :0) lets get the redistribution of them RIP routes on the ASBR, here we need to use the subnets command so we dont get the classful networks along with setting the metric:
So if we check out OSPF database we can see the RIP routes in the type 7 LSA's
and if jump over to R4 he is recieving the TYPE7 LSA's but sending them out (externally) as TYPE 5 LSA's
See the 192.168..... addresses in the TYPE 7 and TYPE 5 section of the OPSF database.
So if we were to jump onto R2, this should not see TYPE7 LSA's as R4 is doing the conversion, lets check:
Excellent, its all working
These methods help reduce the routing tables and the OSPF load, although bear in mind that the router must only have 1 exit out of the network to be a stub.
