OSPF Virtual Links and Routing Filters

What it is

A virtual link is a tunnel in the OSPF sense that connects an area to the backbone, and routing filters control which routes OSPF uses or advertises.

Every area must touch area 0. When an area cannot do so physically, a virtual link can borrow another area as a bridge to the backbone.

Filters work on routes, not on the database. That difference explains most of their limits.

How it works

The virtual link joins two area border routers across a transit area, and filters act when routes enter or leave the routing table.

Virtual links

A virtual link connects two ABRs. At least one of them must be attached to the backbone, and both must share a non backbone area, called the transit area.

The link acts as if it were a point to point link in area 0. It lets a detached area reach the backbone, or lets two pieces of a split backbone act as one.

/routing ospf virtual-link add neighbor-id=2.2.2.2 transit-area=area1

On the other ABR, the neighbour ID is the router ID of the first one. The command is entered on both ends, and each side names the router ID of the other.

RouterOS v7 configures virtual links in its restructured OSPF menus. The idea is the same, but the commands differ.

When to use a virtual link

Use it for temporary needs, such as a link that is not yet installed, or to repair a backbone that a link failure has split. It is a workaround, not a design goal.

A better design connects the area to area 0 directly, or adds a real link.

Limits of virtual links

The transit area must be a regular area. A stub area cannot be the transit area of a virtual link.

The link depends on the transit area. If a failure in the transit area breaks the path, the virtual link goes down, and the detached area loses the backbone.

Virtual links also make the network harder to read, because the real path differs from the logical one.

Routing filters

Filters let you accept, change or discard routes. In RouterOS v6, filter rules are written in /routing filter and chosen by chain name.

/routing filter add chain=ospf-in prefix=10.99.0.0/16 action=discard
/routing ospf instance set [find default=yes] in-filter=ospf-in out-filter=ospf-out

The in-filter applies to routes that OSPF learns, before they enter the routing table. The out-filter applies to routes that this router advertises into OSPF, such as redistributed routes. RouterOS v7 uses a rule syntax with its own chain settings on the instance, so the v6 commands do not carry over.

Limits of filters

OSPF is link state, and every router in an area must hold the same database. A filter cannot remove an LSA from the area, because that would break the shared map.

A filter on routes affects only the routing table of the router where it runs. The LSA is still in the database, and it is still flooded to others. Other routers keep the route.

Filtering is therefore possible at the borders. You can filter external routes at the ASBR, and summaries at the ABR with area ranges. Inside one area, the only way to hide a network is not to advertise it.

Verifying

/routing ospf virtual-link print
/routing ospf neighbor print
/ip route print

The neighbour list shows the virtual link as a neighbour with its own state. If the filter works, the unwanted prefix is absent from the route table but still present in the LSA list.