OSPF Area 0 Split Across a Metro Ethernet Link Left in Area 10
Your company runs OSPF process 1 across two regional hubs and 30 branches. Hub-A is in area 0 and connects to area 1 branches; Hub-B was added last year and connects to area 2 branches. The only path between Hub-A and Hub-B is a provider Layer 2 metro Ethernet link, which was placed in area 10 during a migration and never moved back. Each hub has a default route to its local internet edge, and both advertise it into OSPF. Branch routers in area 1 can reach Hub-A's networks but not Hub-B's, and area 2 branches see only Hub-B's prefixes. Traceroutes between areas 1 and 2 often take a longer path through a third-party MPLS cloud that is not under your control. The provider link has 0% loss and 4 ms RTT. You need to restore full inter-area reachability and keep the design supportable.
1. Explain why area 1 and area 2 do not exchange routes even though both hubs run OSPF and the metro link is up.
Read the worked answer
The backbone is discontiguous. Hub-A is an ABR because it has interfaces in area 0 and area 1, and it also has the metro link in area 10. Hub-B has area 2 and area 10 interfaces but no area 0 interface, so it is not an ABR. An OSPF router that is not attached to the backbone does not originate type 3 summary LSAs between areas in the way an ABR does. Area 10 is a transit area between the two hubs, but it is not area 0, so type 3 LSAs from area 1 are not propagated through it to area 2 as backbone summaries. As a result, area 1 learns Hub-A's prefixes, area 2 learns Hub-B's prefixes, and the two domains rely on the default routes or external MPLS paths. The link being up and loss-free is irrelevant; the problem is OSPF area topology and ABR status, not transport. Verify with show ip ospf interface brief on both hubs and show ip ospf database summary to confirm which type 3 LSAs exist.
2. Compare three fixes: moving the metro link into area 0, configuring a virtual link across area 10, and building a GRE tunnel in area 0. Recommend one.
Read the worked answer
Moving the metro link into area 0 is the cleanest fix because the provider already delivers Layer 2, so changing the OSPF area on both ends restores a physical backbone link. It avoids tunnel overhead and virtual-link fragility, and it makes both hubs true ABRs with a direct backbone path. A virtual link across area 10 is possible only if Hub-B also has an area 0 interface, such as a loopback, and area 10 is not stub; it would work but it depends on a transit area that was left over from a migration and is harder to support. GRE in area 0 also works, but it adds encapsulation, reduces MTU, and creates a logical link over the same provider path, which is unnecessary when Layer 2 is available. Recommend scheduling a maintenance window to move the metro link to area 0 on both hubs, with GRE as a temporary fallback if the provider change window slips. Do not leave area 10 as the permanent backbone transit.
3. What summarization and default-route rules should you apply after the fix?
Read the worked answer
After area 0 is contiguous, summarize at the ABRs: Hub-A should use an area range for area 1, and Hub-B should use an area range for area 2, so the backbone carries aggregate prefixes rather than every branch subnet. Do not summarize area 0 into itself, and do not advertise a summary that overlaps a more specific backbone route. Both hubs currently originate a default route, so control it with default-information originate and a route map that sets different metrics, or suppress one default so branches prefer the nearest internet edge. If both defaults remain, verify that area 1 and area 2 choose the intended exit and do not create a loop through the MPLS cloud. Also confirm that the virtual-link or GRE alternative is removed, and that area 10 is either deleted or documented as a non-backbone transit. Use show ip ospf database summary and show ip route on branch routers to validate the aggregates and default selection.