OSPF Deep Dive Part 4: Virtual Links, Summarization, and Redistribution

Area 2 in this series’ lab has a problem stated back in Part 1 and left alone since: it hangs off EDGE-MX with no direct link into Area 0. Every rule from Part 2 assumes every non-backbone area touches Area 0 directly, and Area 2 doesn’t. This post fixes that with a virtual link, then covers the two other things an ABR or ASBR does once areas are actually connected: summarizing routes at the boundary, and injecting routes that didn’t come from OSPF in the first place.

Virtual links: borrowing another area as a transit

A virtual link creates a logical Area 0 connection between two ABRs that aren’t physically adjacent, by treating some other already-connected area as a transit path between them. It doesn’t create a new adjacency type. It reuses the existing Area 0 mechanism, Type 1 router LSAs specifically, across routers that already share a non-backbone area.

Area 2’s ABR is EDGE-MX. The nearest area that already touches Area 0 is Area 1, whose ABR is BRANCH-FGT. A virtual link between EDGE-MX and BRANCH-FGT, transiting Area 1, gives EDGE-MX a logical path into the backbone without a new physical link.

Two rules constrain where a virtual link can go. The transit area can’t itself be a stub, totally stubby, or NSSA area, since none of those area types carry the Type 4 ASBR-summary information a virtual link depends on to resolve reachability across it. And a virtual link is always configured on both ABRs identically, each one naming the other’s router ID as the far end.

Cisco IOS-XE, on BRANCH-FGT’s peer would look like (adjusted for CORE-CSR if it were the ABR instead):

router ospf 1
 area 1 virtual-link 10.0.0.3

Junos, on EDGE-MX:

set protocols ospf area 0.0.0.0 virtual-link neighbor-id 10.0.0.2 transit-area 0.0.0.1

FortiOS, on BRANCH-FGT:

config router ospf
    config area
        edit 0.0.0.0
            config virtual-link
                edit "to-edge-mx"
                    set peer 10.0.0.3
                next
            end
        next
    end
end

Notice the asymmetry in how each vendor names the area the virtual link belongs to. Junos configures it under the transit area’s stanza directly (area 0.0.0.0 here is a quirk of this example, since Junos wants the virtual link listed under the area being transited, area 1 in dotted form, not the backbone). Cisco’s area 1 virtual-link syntax states the transit area explicitly as the first argument. FortiOS nests it under whichever area the virtual-link block sits inside. Getting the transit area backwards, naming Area 0 instead of Area 1 as the context, is the single most common virtual-link misconfiguration, and it fails silently: the command is accepted, no adjacency forms, and there’s no error pointing at the actual mistake. Part 10 covers how to actually spot this.

Summarization at the ABR

An ABR advertising Type 3 LSAs for every individual subnet in an area is correct but wasteful once an area has more than a handful of subnets, and it also means a single flapping subnet inside the area triggers a Type 3 re-flood into every other area, whether or not those areas have any reason to care about that specific subnet’s stability. Summarization collapses a contiguous range of subnets into a single Type 3 advertisement at the ABR.

This only works if the area’s addressing was actually planned as a contiguous block. Area 1’s 10.10.10.0/24 in this lab is a single subnet, too small to usefully demonstrate summarization on its own, but the syntax is the same regardless of how many subnets a real area contains:

Cisco: area 1 range 10.10.10.0 255.255.255.0 Junos: set protocols ospf area 0.0.0.1 area-range 10.10.10.0/24 FortiOS: under config area, edit 0.0.0.1 then config range / edit 1 / set prefix 10.10.10.0 255.255.255.0

All three terms mean the same thing and none of them are named the same thing, which is worth flagging on its own: “range” on Cisco and FortiOS, “area-range” on Junos. This is exactly the kind of vocabulary mismatch that costs time in a mixed-vendor team, not because the concept is hard, but because searching a Cisco engineer’s usual terms against Junos documentation returns nothing useful.

Redistribution: bringing in routes OSPF didn’t learn

Area 1 in this lab is NSSA, established in Part 2, specifically because BRANCH-FGT needs to redistribute a static default route into it. Redistribution is what turns a router into an ASBR in the first place, the moment it originates a Type 5 (or Type 7, inside an NSSA) for a route that came from somewhere other than OSPF’s own LSDB.

Cisco, redistributing statics as external type 1 with a seed metric:

router ospf 1
 redistribute static metric-type 1 metric 20 subnets

Junos, using a policy statement rather than an inline redistribute command, which is the bigger structural difference from the other two vendors covered later in Part 9:

set policy-options policy-statement REDIST-STATIC term 1 from protocol static
set policy-options policy-statement REDIST-STATIC term 1 then external metric-type 1
set policy-options policy-statement REDIST-STATIC term 1 then accept
set protocols ospf export REDIST-STATIC

FortiOS:

config router ospf
    config redistribute "static"
        set status enable
        set metric-type 1
        set metric 20
    end
end

The subnets keyword on the Cisco example is a genuine gotcha on its own: without it, classic Cisco redistribution only advertises classful summary routes for any redistributed subnet that isn’t the same length as its natural class boundary, silently dropping more specific routes that look identical to what was actually configured. It’s easy to write a redistribute statement, see routes appear on a neighboring router, and not notice they’re the wrong prefix length until something downstream depending on the more specific route breaks.

Metric type matters here for the same reason Part 3 covered it: E1 costs accumulate with internal distance, E2 costs don’t. A static default redistributed as E2 (Junos and FortiOS both default to E2 if metric-type isn’t specified; Cisco does too) looks identical in cost from every router in the domain regardless of how far that router actually is from the ASBR, which is usually not what’s wanted for a default route where the nearest exit should actually win.

With the virtual link up, Area 1 as NSSA redistributing a static, and Area 0 fully meshed, the lab in this series is now a genuinely complete three-area, three-vendor OSPF domain. The next post moves to OSPFv3 and running this same design over IPv6, before Part 6 covers locking it down with authentication.