You are correct in that you need a virtual link between Chicken and Pork in order to have a single contiguous Area 0. You can see that this is not the case since on Chicken you can see that the route to 126.96.36.199 is considered an Inter Area route since it was learned via an ABR, and thus via a Type 3 LSA. If the virtual link was there, Chicken would have learned about this route directly from Pork (in the same area) over the virtual link.
The second thing you have to do is connect Area 2 to area 0 using a virtual link. You can do this by creating a virtual link between FIsh and Chicken, or between Fish and Pork, the results should be the same…
In particular, the loopback behind fish cannot be seen in any routing tables because area 2 is not directly connected to the backbone area using an ABR. Because Fish has no interfaces on Area 0 it doesn’t fulfil its function as an ABR, since it cannot share LSAs between two non backbone areas. Take a look at the OSPF LSA Types Explained lesson to learn more about how LSAs and their various types are exchanged between areas.
I am not able to understand these given lines " Imagine the router on top was in area 0. Unfortunately this router crashed and the result is that area 0 is now split into two pieces". How can the area split into two parts when the router crashes?
The purpose of the virtual link is not to transmit user traffic. It is only used on the control plane, which means it is used to allow for the exchange of OSPF messages between area 0 and other OSPF areas that are not directly connected to area 0.
Since the virtual link doesn’t carry user traffic, there is no such concept as “metric over the virtual link”. The metric for each particular prefix is still based on the cost to get there via the path that OSPF chooses.
For the topology that you shared, in order to make it work with OSFP, you must create two virtual links. One between area 0 and area 2, and one between area 0 and area 3. If we name the ABRs from left to right as A, B, C, and D, then these virtual links will be created between ABRs A and B, as well as between ABRs A and C.
Thank you for your lessons and examples. I have an inquiry but just so you know I used a different setup and topology than you did. Regardless it is still the same concept. Anyway, I had some issues doing it my way. Then I finally found out what was causing my issue. It appears that these commands prevented me from getting routes. And I am wondering why?
ip ospf network point-to-point
ip ospf 100 area 80
The first command is an interface configuration mode command, and is used only for networks that are indeed point-to-point networks. This is used on serial links or on topologies that use non-broadcast technologies such as Frame-Relay. This allows OSPF to operate correctly in an environment where multicast is not available. More about how this command should be enabled can be found in this lesson:
This command should not be used in an Ethernet environment, as it could affect the neighbor relationships as well as the sharing of LSAs.
The second command is also an interface configuration mode command and simply enables OSPF on the interface, defining an OSPF process ID as well as an area. Now, this command is not incorrect, but if you specify an incorrect process ID or area, then the OSPF topology may indeed fail. If this command caused the virtual link to fail, then it could be that the process ID or the area ID was incorrect.
Yes indeed. R2 becomes an ABR between Area 2 and Area 0. It also becomes an ABR between Area 1 and Area 0. It does not become an ABR between Area 1 and Area 2 because by definition, an ABR connects a non-backbone area to the backbone area.
So to answer your second question, it does not propagate Type3 LSAs from Area 1 to Area 2 and visa versa. It only propagates LSAs between the backbone area and a non-backbone area.
It sounds inefficient but that is by definition how OSPF operates. This is also why a virtual link should only be deployed as a temporary solution and not as part of a permanent architecture of a production network.
It depends upon what you mean when you say “inherit attributes.” Remember, summarization in OSPF occurs on ABRs, and by definition, any router that terminates an OSPF virtual link is an ABR. Now having said that, such an ABR will not “inherit” any summarization configurations from the OSPF area 0, however, it can be configured to perform summarization simply because of the fact that it is an ABR.
In other words, a router that is connected via a virtual link will see the summarized routes from Area 0, but that’s simply because of its role as an ABR. It really has nothing to do with the virtual link itself.
Similarly, when it comes to authentication, it is configured on a per-interface or per-area basis. So, even if Area 0 is configured with certain authentication, this won’t be automatically inherited by routers connected through a virtual link. These routers would still need to have the same authentication configured explicitly.
So regarding summarization and authentication, an ABR of Area 0 will behave in much the same way regardless of whether it is connected “normally” or via a virtual link.
Just a note here, OSPF authentication configured between neighbors within an area is distinct from the configuration of virtual link authentication. The former authentications OSPF neighbors, while the latter authenticates the virtual link terminating routers.
The cost that OSPF assigns to the path taken by a virtual link is calculated in much the same way as you would calculate the cost of any path in OSPF. For a virtual link, the cost is determined based on the actual path that the virtual link takes through the transit area. The total cost of the virtual link is the sum of the costs of the individual links that comprise the path through the transit area.
So the cost of a virtual link is not a property of the virtual link itself, but is instead determined by the costs of the physical or logical links that comprise the path the virtual link follows through the transit area.
OSPF, by design, must have a contiguous backbone Area 0, and have all other areas directly connected to that backbone via ABRs. This is part of the fundamental design of the protocol. The primary reason for this is that the backbone area is used to efficiently distribute routing information throughout the network. It acts as a sort of hub, where routing information from non-backbone areas is advertised within the backbone, and then redistributed to other non-backbone areas. If you were to create a topology with a discontinuous backbone area, as depicted below, you may run into the following problems:
Routing Loops: If the backbone area is not contiguous, like the diagram above, it could lead to routing loops. This is because OSPF routers use the backbone area to share routing information. If the backbone area is discontiguous, some routers may not receive all the necessary routing information, which can lead to incorrect routing decisions and potential routing loops.
Incomplete Routing Tables: Another problem could be incomplete routing tables. If the backbone area is discontiguous, some routers might not have complete information about the network topology. This could lead to inefficient routing or even dropped packets if routers don’t know how to reach certain parts of the network.
Network Segmentation: In worst-case scenarios, a discontiguous backbone could lead to network segmentation, where parts of the network become unreachable from others.
To more fully understand the problems involved, try creating a topology like the one above, and don’t create a virtual link. See how routes are advertised to all the routers and see if routing is performed correctly.
An excellent reply! I’ve labbed up the topology and it turns out that when a router receives a Type 3 LSA from a non-backbone area, it will install it for that area but not propagate it to any other areas.