OSPF Advanced Configuration

OSPF Advanced Configuration

This guide covers four advanced OSPF configuration topics in RouterOS 7: virtual links for areas without direct backbone connectivity, area ranges for inter-area route summarization, route redistribution from connected/static/BGP sources, and routing filters that control which routes enter or leave the OSPF domain.

All examples use RouterOS 7 syntax. RouterOS 7 uses /routing ospf interface-template for interface assignment; the legacy /routing ospf interface and /routing ospf network menus from RouterOS 6 are not used here.

---

Virtual Links

A virtual link is a logical OSPF link through a transit area that provides backbone connectivity for an area that cannot physically connect to Area 0. Virtual links are also used to repair a partitioned backbone when the backbone loses connectivity between two segments.

When Virtual Links Are Needed

OSPF requires all non-backbone areas to connect directly to the backbone (Area 0). Two situations arise where this is not possible:

1. Area without direct backbone attachment — a new area is added to the network and can only reach the backbone through an intermediate (transit) area.
2. Partitioned backbone — Area 0 loses physical continuity, splitting into two disconnected segments. A virtual link through an adjacent area reconnects the backbone.

                     Area 0 (backbone)
    ┌─────────────────────────────────────────┐
    │                                         │
  R1 (1.1.1.1)                           R3 (3.3.3.3)
    │                                         │
    │        Area 2 (transit area)            │
  R1 ─── ether2 ─── Area2 ─── ether1 ─── R2 (2.2.2.2)
                                              │
                                         Area 3 (remote)
                                        needs backbone access

In this diagram, R2 connects Area 3 but has no direct link to Area 0. A virtual link through Area 2 between R1 and R2 gives R2 logical backbone connectivity.

Virtual Link Configuration (RouterOS 7)

In RouterOS 7, virtual links are configured as interface-template entries with type=virtual-link. Each end of the virtual link requires:

• type=virtual-link — marks this template as a virtual link endpoint
• vlink-transit-area — the intermediate area the virtual link traverses
• vlink-neighbor-id — the router ID of the remote ABR at the other end
• area — must be the backbone area (backbone), since virtual links extend the backbone

Both ABRs must configure the virtual link pointing at each other.

R1 (backbone-connected ABR, router-id 1.1.1.1):

/routing ospf instance
add name=ospf1 version=2 router-id=1.1.1.1

/routing ospf area
add name=backbone   area-id=0.0.0.0 instance=ospf1
add name=area2      area-id=0.0.0.2 instance=ospf1

/routing ospf interface-template
add interfaces=ether1 area=backbone   # backbone link
add interfaces=ether2 area=area2                                   # transit area link

# Virtual link to R2 through Area 2
add type=virtual-link area=backbone vlink-transit-area=area2 vlink-neighbor-id=2.2.2.2

R2 (remote ABR, router-id 2.2.2.2):

/routing ospf instance
add name=ospf1 version=2 router-id=2.2.2.2

/routing ospf area
add name=backbone   area-id=0.0.0.0 instance=ospf1
add name=area2      area-id=0.0.0.2 instance=ospf1
add name=area3      area-id=0.0.0.3 instance=ospf1

/routing ospf interface-template
add interfaces=ether1 area=area2                                   # transit area link to R1
add interfaces=ether2 area=area3                                   # remote area link

# Virtual link to R1 through Area 2
add type=virtual-link area=backbone vlink-transit-area=area2 vlink-neighbor-id=1.1.1.1

Virtual Link Requirements

Virtual links have specific constraints that differ from physical OSPF links:

• The transit area must be a standard area — stub, totally stubby, and NSSA areas cannot be used as transit areas.
• Both endpoints must have full OSPF connectivity through the transit area before the virtual link can form.
• Virtual link timers (hello and dead intervals) must match between the two endpoints.
• Authentication must be configured consistently on both virtual link endpoints if the backbone area uses authentication.

Verifying Virtual Links

# Check virtual link neighbor state (should reach FULL)
/routing ospf neighbor print

# View virtual link details including transit area and neighbor router-id
/routing ospf interface-template print detail where type=virtual-link

# Verify backbone connectivity has been restored (look for area 0 LSAs)
/routing ospf lsa print where area=backbone

# Check that Area 3 routes appear in the routing table on R1
/ip route print where ospf~"."

A healthy virtual link shows the neighbor in Full state in /routing ospf neighbor print. If the neighbor is absent or stuck in Init, verify:

1. The transit area has physical OSPF adjacencies between R1 and R2.
2. Both sides specify the same vlink-transit-area and each points vlink-neighbor-id at the other router’s router-id.
3. Firewall rules permit IP protocol 89 on the transit area interfaces.

Virtual Link Authentication

If the backbone area uses MD5 authentication, the virtual link must also authenticate. Authentication is configured on the interface-template entry for the virtual link:

/routing ospf interface-template
add type=virtual-link area=backbone vlink-transit-area=area2 vlink-neighbor-id=2.2.2.2 \
    auth=md5 auth-key=SecretKey

Both ABRs must use matching auth-key values. Note: the parameter is auth=md5, not authentication=md5, and there is no auth-key-id parameter on interface-template entries.

When to Avoid Virtual Links

Virtual links are a workaround for topological constraints, not a design goal. They increase troubleshooting complexity, add a dependency on transit area stability, and can behave unexpectedly during reconvergence. Prefer resolving connectivity issues by adding a physical backbone link. Use virtual links only when:

• Physical links to Area 0 are not feasible.
• The backbone has partitioned temporarily and needs immediate repair pending a physical fix.

---

Area Ranges for Route Summarization

Area ranges configure an ABR to aggregate multiple routes from one area into a single summary advertisement before injecting them into adjacent areas. Without summarization, every individual prefix in an area appears as a separate Type 3 LSA in the backbone and other areas. Summarization reduces LSDB size and dampens the propagation of topology changes.

Sub-menu: /routing ospf area range

How Area Ranges Work

An area range is configured on the ABR that connects the area being summarized to the backbone. When the ABR generates Type 3 LSAs to advertise routes from Area X into Area 0, it replaces all prefixes that fall within the configured range with a single aggregate LSA. The metric of the aggregate is the highest metric among all covered prefixes.

Area 1 contains:
  10.1.1.0/24 (cost 10)
  10.1.2.0/24 (cost 15)
  10.1.3.0/24 (cost 20)

Area range configured on ABR: 10.1.0.0/16

Backbone sees only: 10.1.0.0/16 (cost 20)

Configuring Area Ranges

# Summarize the entire 10.1.0.0/16 block from area1 into the backbone
/routing ospf area range
add area=area1 prefix=10.1.0.0/16 advertise=yes

# Summarize NSSA external routes from a branch area
/routing ospf area range
add area=nssa-branch prefix=192.168.100.0/22 advertise=yes

# Suppress a specific sub-range (do not advertise it at all)
/routing ospf area range
add area=area1 prefix=10.1.99.0/24 advertise=no

Setting advertise=no suppresses the matched prefixes entirely — they do not appear in adjacent areas. This is useful for hiding maintenance or management prefixes from the backbone.

Setting a Cost on the Summary

By default the summary inherits the highest metric of its component routes. To override this:

/routing ospf area range
add area=area1 prefix=10.1.0.0/16 advertise=yes cost=50

Summarization Pitfalls

Black holes from gaps in the summarized range. If the summary covers 10.1.0.0/16 but some subnets within that range do not exist on any router, traffic to those subnets arrives at the ABR and finds no more-specific route. The ABR forwards based on a less-specific route, potentially looping or dropping traffic. Always verify that no gaps exist in the summarized space, or add explicit null routes on the ABR for the summary:

# Null route to prevent black-holing if gaps exist
/ip route add dst-address=10.1.0.0/16 type=blackhole

Area ranges only take effect on ABRs. An area range configured on an internal router (all interfaces in one area) has no effect. Confirm the router spans multiple areas:

/routing ospf interface-template print
/routing ospf area range print

---

Route Redistribution

Route redistribution introduces external routes — routes from outside OSPF — into the OSPF domain. Any router that redistributes routes becomes an ASBR (autonomous system boundary router), generating Type 5 external LSAs that flood throughout all non-stub areas.

RouterOS 7 controls redistribution through the redistribute parameter on the OSPF instance, with an optional out-filter-chain for per-prefix policy.

Redistributing Connected Routes

Redistributing connected routes advertises the IP prefixes of all local interfaces into OSPF as external routes. Apply an output filter to restrict redistribution to specific interfaces or prefix ranges.

/routing ospf instance
set ospf1 redistribute=connected out-filter-chain=ospf-ext-out

/routing filter rule
# Redistribute only loopback addresses (/32) as type 1 for closer-ASBR selection
add chain=ospf-ext-out rule="if (protocol connected && dst-len == 32) { \
    set ospf-ext-type type1; set ospf-ext-metric 10; accept }"

# Redistribute LAN ranges
add chain=ospf-ext-out rule="if (protocol connected && dst in 10.0.0.0/8) { \
    set ospf-ext-type type2; set ospf-ext-metric 20; accept }"

# Reject everything else — do not redistribute transit or WAN interface addresses
add chain=ospf-ext-out rule="reject"

Redistributing Static Routes

Redistributing static routes injects manually configured routes into OSPF. This is common for aggregating branch network summaries or advertising a management prefix.

/routing ospf instance
set ospf1 redistribute=static out-filter-chain=ospf-ext-out

/routing filter rule
# Redistribute only explicit summary static routes — not host routes or defaults
add chain=ospf-ext-out rule="if (protocol static && dst in 172.16.0.0/12 && dst-len <= 20) { \
    set ospf-ext-type type2; set ospf-ext-metric 50; accept }"
add chain=ospf-ext-out rule="reject"

Redistributing BGP Routes

Redistributing BGP into OSPF requires strict filtering. An unfiltered BGP table can flood thousands of external LSAs into the OSPF domain, overwhelming router memory and causing SPF instability.

/routing ospf instance
set ospf1 redistribute=connected,bgp out-filter-chain=ospf-ext-out

/routing filter rule
# Connected loopback only (not transit interfaces)
add chain=ospf-ext-out rule="if (protocol connected && dst-len == 32) { \
    set ospf-ext-type type1; set ospf-ext-metric 10; accept }"

# Accept only customer prefixes /22–/24 in the known allocation block
# Never redistribute the default route, full BGP table, or transit routes
add chain=ospf-ext-out rule="if (protocol bgp && dst in 203.0.113.0/22 \
    && dst-len >= 22 && dst-len <= 24) { \
    set ospf-ext-type type2; set ospf-ext-metric 100; accept }"

# Explicitly reject everything else including BGP default
add chain=ospf-ext-out rule="reject"

Safety rules for BGP redistribution:

• Never configure redistribute=bgp without an out-filter-chain — unfiltered redistribution floods the entire BGP table into OSPF.
• Exclude 0.0.0.0/0 from redistribution; use originate-default to originate a default route deliberately.
• Bound dst-len to prevent leaking more-specific BGP routes beyond the intended range.
• If two ASBRs redistribute the same BGP prefixes, use type 1 metrics so routers prefer the closer ASBR.

External Metric Types

Type	Cost formula	Use when
type2 (default)	External metric only	Single ASBR, or policy takes precedence over topology
type1	Internal cost to ASBR + external metric	Multiple ASBRs advertising the same prefix; prefer closest ASBR

/routing filter rule
# Type 1 — two ASBRs, routers should prefer the closer one
add chain=ospf-ext-out rule="if (protocol bgp) { set ospf-ext-type type1; \
    set ospf-ext-metric 100; accept }"

Default Route Distribution

Use originate-default to originate 0.0.0.0/0 into OSPF independently of the redistribute parameter:

# Originate default route only while WAN default exists (safe for edge routers)
/routing ospf instance
set ospf1 originate-default=if-installed

# Always originate default (aggregation/core routers)
/routing ospf instance
set ospf1 originate-default=always

For detailed redistribution guidance, NSSA ASBR configuration, and redistribution troubleshooting, see OSPF Route Redistribution.

---

OSPF Filtering with Routing Filters

RouterOS 7 OSPF filtering uses the same /routing filter rule syntax as other routing protocols. Filters attach to the OSPF instance and are evaluated on a per-route basis.

Filter parameter	Direction	Effect
in-filter-chain	Inbound (import)	Applied to OSPF-learned routes before installation into the routing table
out-filter-chain	Outbound (export/redistribution)	Applied to routes being redistributed into OSPF as external LSAs

Inbound Filters (Import Policy)

Inbound filtering controls which OSPF-learned routes are accepted into the local routing table. This does not affect LSA propagation — the routes still exist in the LSDB and propagate to other routers. The filter only affects whether this router installs the route locally.

Attach the filter via in-filter-chain:

/routing ospf instance
set ospf1 in-filter-chain=ospf-import

Filter rules are evaluated top-to-bottom. Routes that match no accept rule are implicitly rejected. Always include an explicit accept at the end unless you intend to reject all unmatched routes.

Block a Specific Prefix

/routing filter rule
add chain=ospf-import rule="if (dst == 192.168.50.0/24) { reject }"
add chain=ospf-import rule="accept"

/routing ospf instance
set ospf1 in-filter-chain=ospf-import

Block More-Specific Routes Beyond a Prefix Length

Prevents overly long prefixes from entering the routing table while allowing aggregates:

/routing filter rule
# Accept the aggregate but reject anything more specific than /24
add chain=ospf-import rule="if (dst in 10.20.0.0/16 && dst-len > 24) { reject }"
add chain=ospf-import rule="accept"

Multiple Prefix Blocks (Prefix-List Style)

RouterOS 7 does not have a dedicated ip prefix-list object. Implement the equivalent using sequential filter rules in a single chain:

/routing filter rule
# Block specific prefixes
add chain=ospf-import rule="if (dst == 172.16.10.0/24) { reject }"
add chain=ospf-import rule="if (dst == 172.16.11.0/24) { reject }"

# Block host routes from OSPF (common with leaked connected routes)
add chain=ospf-import rule="if (dst in 172.16.0.0/16 && dst-len >= 30) { reject }"

# Accept everything else
add chain=ospf-import rule="accept"

Filter by OSPF Route Type

Filter rules can match on OSPF-specific attributes:

Property	Values	Description
ospf-type	intra, inter, ext1, ext2	Route category
ospf-metric	integer	OSPF metric of the route
ospf-tag	integer	External route tag

/routing filter rule
# Block all type-2 external routes from a specific prefix
add chain=ospf-import rule="if (dst in 203.0.113.0/24 && ospf-type ext2) { reject }"

# Block all inter-area routes from a distrusted range
add chain=ospf-import rule="if (ospf-type inter && dst in 10.99.0.0/16) { reject }"

# Accept all intra-area and inter-area routes; reject uncontrolled externals
add chain=ospf-import rule="if (ospf-type intra || ospf-type inter) { accept }"
add chain=ospf-import rule="reject"

Outbound Filters (Redistribution Policy)

Outbound filters control which routes are redistributed into OSPF as external LSAs. These are described in detail in the redistribution section above and in OSPF Route Redistribution.

/routing ospf instance
set ospf1 redistribute=connected,static,bgp out-filter-chain=ospf-ext-out

Debugging Filter Behavior

When a filter rejects routes unexpectedly, enable system-level route debug logging to observe routing decisions, then check the routing table to see which routes were accepted:

# Enable route debug logging
/system logging add topics=route,debug action=memory

# Trigger a routing update (e.g., clear OSPF neighbor or wait for LSA refresh)
# Then check the log for routing filter decisions
/log print where topics~"route"

# View which routes were accepted into the routing table
/ip route print where ospf~"."

# Disable debug logging after investigation
/system logging remove [find where topics~"route"]

RouterOS 7 routing filter rules do not support log or passthrough actions. Valid actions are accept, reject, and return.

To verify which filter chains are attached to the instance:

/routing ospf instance print detail

---

Complete Example: Multi-Area Network with Virtual Link and Filtering

This example combines the topics above: a three-area network with a remote area connected via virtual link, route redistribution with filtering, and import policy.

 Internet
    │
  R1 (1.1.1.1) ── Area 0 ── R2 (2.2.2.2)
    │                              │
  Area 1 (stub)              Area 2 (transit)
                                   │
                              R3 (3.3.3.3)
                                   │
                              Area 3 (remote — virtual link to R1 through Area 2)

R1 — backbone + stub ABR + internet edge (ASBR):

/routing ospf instance
add name=ospf1 version=2 router-id=1.1.1.1 \
    redistribute=connected \
    out-filter-chain=edge-out \
    originate-default=if-installed \
    in-filter-chain=ospf-import

/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf1
add name=area1    area-id=0.0.0.1 instance=ospf1 type=stub
add name=area2    area-id=0.0.0.2 instance=ospf1

/routing ospf interface-template
add interfaces=ether1 area=backbone   # to R2
add interfaces=ether2 area=area1                                   # stub branch
add interfaces=ether3 area=area2   # transit to R3
add interfaces=lo0    area=backbone passive=yes
# Virtual link to R3 through Area 2
add type=virtual-link area=backbone vlink-transit-area=area2 vlink-neighbor-id=3.3.3.3

/routing ospf area range
add area=area1 prefix=10.1.0.0/16 advertise=yes

/routing filter rule
# Redistribute only loopback
add chain=edge-out rule="if (protocol connected && dst-len == 32) { \
    set ospf-ext-type type2; set ospf-ext-metric 10; accept }"
add chain=edge-out rule="reject"

# Import: block host routes from entering routing table
add chain=ospf-import rule="if (dst-len == 32 && ospf-type ext2) { reject }"
add chain=ospf-import rule="accept"

R3 — remote ABR, Area 3 + virtual link to backbone through Area 2:

/routing ospf instance
add name=ospf1 version=2 router-id=3.3.3.3 \
    redistribute=connected \
    out-filter-chain=r3-out

/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf1
add name=area2    area-id=0.0.0.2 instance=ospf1
add name=area3    area-id=0.0.0.3 instance=ospf1

/routing ospf interface-template
add interfaces=ether1 area=area2   # transit to R1
add interfaces=ether2 area=area3                                   # remote area link
# Virtual link back to R1 through Area 2
add type=virtual-link area=backbone vlink-transit-area=area2 vlink-neighbor-id=1.1.1.1

/routing ospf area range
add area=area3 prefix=10.3.0.0/16 advertise=yes

/routing filter rule
add chain=r3-out rule="if (protocol connected && dst in 10.3.0.0/16) { \
    set ospf-ext-type type2; set ospf-ext-metric 20; accept }"
add chain=r3-out rule="reject"

---

Troubleshooting

Virtual Link Neighbor Not Forming

# Check virtual link template exists on both ABRs
/routing ospf interface-template print detail where type=virtual-link

# Verify the transit area has OSPF adjacency between the two ABRs
/routing ospf neighbor print

# Confirm router-IDs match vlink-neighbor-id values
/routing ospf instance print detail

Common causes:

• The transit area is a stub or NSSA — change it to a standard area.
• vlink-neighbor-id does not match the remote router’s router-id.
• No physical OSPF adjacency through the transit area yet (the virtual link depends on transit area reachability).
• Firewall blocking protocol 89 on the transit area interfaces.

Area Range Not Summarizing

# Verify this router is an ABR (has interfaces in multiple areas)
/routing ospf interface-template print

# Check that the range covers the actual prefixes
/routing ospf area range print
/ip route print where ospf~"."

Area ranges only apply on ABRs. If all interfaces are in a single area, the range has no effect.

Routing Filter Rejecting Unexpected Routes

# View filter rules in the import chain
/routing filter rule print where chain=ospf-import

# Enable system route debug logging to observe filter decisions
/system logging add topics=route,debug action=memory
/log print where topics~"route"
# Disable after investigation
/system logging remove [find where topics~"route"]

External Routes Not Redistributed

# Confirm redistribute and filter chain settings
/routing ospf instance print detail

# Verify the filter chain has an accept rule for the intended protocols
/routing filter rule print where chain=ospf-ext-out

# Temporarily remove filter to confirm redistribution itself works
/routing ospf instance set ospf1 out-filter-chain=""
/routing ospf lsa print where type=external

---

Related Documentation

• OSPF — Fundamentals, LSA types, neighbor states, authentication
• OSPF Area Types — Stub, totally stubby, NSSA, and interface-template area assignment
• OSPF Configuration — Multi-area setup and DR/BDR election
• OSPF Route Redistribution — Detailed redistribution guide with NSSA ASBR, default route, and loop prevention
• Route Filters — Routing filter rule syntax and available matchers