Virtual Link Across an NSSA Transit Area
An enterprise runs OSPF on Nokia SR OS routers. R1 is in area 0.0.0.0 and owns the only border-router uplink. R2 is an ABR between area 0 and area 1. Area 1 was configured as an NSSA two years ago because R5, a legacy ASBR, redistributes 172.16.0.0/12 there. R3 sits between area 1 and area 2, and R4 is internal to area 2. Area 2 has no direct link to area 0. To give area 2 a backbone connection, an engineer configured on R3: virtual-link 10.0.0.1 transit-area 0.0.0.1, where 10.0.0.1 is R1's loopback. After three days, show router ospf virtual-link on R3 still reports the virtual link down, although R3 has a full adjacency with R2 in area 1. R4 receives no inter-area routes from the backbone, and R3 logs no authentication errors. The team wants to keep R5's redistributed routes inside the NSSA and avoid redesigning the address plan.
1. Why does the virtual link remain down, and which OSPF rule does this design violate?
Read the worked answer
The virtual link is an unnumbered point-to-point link that is carried inside a transit area. OSPF requires that transit area to be a normal area. A stub area or an NSSA cannot be a virtual-link transit area, because those area types do not carry the full set of transit LSAs and are not allowed to act as transit areas.
Area 1 is an NSSA, so R3's virtual-link 10.0.0.1 transit-area 0.0.0.1 cannot come up even though R3 has a full adjacency with R2. The full adjacency only proves that area 1 hellos work; it does not make area 1 a legal transit area. show router ospf area 0.0.0.1 on R2 or R3 should show the NSSA flag, and show router ospf virtual-link on R3 shows the link down.
The secondary symptom follows from the first. Until the virtual link is up, R3 has no interface in area 0 and therefore is not a true ABR. It cannot inject backbone inter-area routes into area 2, so R4 sees no backbone routes. The absence of authentication errors is expected: this is an area-type restriction, not a key mismatch.
2. Propose two designs that preserve R5's redistribution inside an NSSA and restore area 2's backbone connectivity. State the main trade-off of each.
Read the worked answer
Option 1: Convert area 1 back to a normal area and keep R5 where it is. The virtual link from R3 to R1 over area 1 then becomes legal. The trade-off is that R5's external LSAs flood throughout area 1. If that is unacceptable, filter R5's redistributed prefixes at R2 with an export or import policy, or move R5 into a separate NSSA. This option requires no new links, but it changes the area type on every area 1 router and may require a maintenance window.
Option 2: Leave area 1 as an NSSA and give R3 a real area 0 attachment. This can be a new physical link from R3 to R1, or a GRE tunnel whose tunnel interface is placed in area 0. The virtual link is then unnecessary. The trade-off is cost and complexity: a new link needs fiber and ports, while a GRE tunnel adds encapsulation overhead and depends on area 1 reachability. A third variant is to move R5 into a new NSSA attached to R2 and convert area 1 to normal; that is the cleanest separation of policy but requires readdressing and more planning. In all cases, verify roles with show router ospf neighbor, show router ospf interface, and show router ospf area before and after the change.
3. What verification would you perform before changing the area type, and what would you warn the change window about?
Read the worked answer
Before the change, capture show router ospf neighbor on R1, R2, R3, and R5 to confirm that all adjacencies are Full and to identify the DR/BDR on any broadcast segments. Capture show router ospf database self-originate on R5 to see exactly which Type-5 LSAs it generates, and show router ospf routes on R4 to document the missing inter-area routes. On R2 and R3, show router ospf area confirms the current NSSA setting and the default-cost and summary behavior.
During the window, warn that changing area 1 from NSSA to normal will flush and re-originate LSAs, which will cause a short outage in area 1 and may briefly affect area 2. R5's Type-5 LSAs will start flooding area 1, so check whether any area 1 router has a small LSDB or a policy that would now receive unwanted externals. Also warn that R3's virtual link may come up only after both endpoints agree on the new area type; if the virtual link flaps, area 2 will lose its backbone connection again.