OSPF redistribution — static, connected, BGP, and route-map filtering

OSPF’s LSDB is built from three sources: LSAs the router originates (Type-1 Router, Type-2 Network, Type-3 Summary at ABRs, Type-5 External at ASBRs), LSAs flooded in from neighbours, and routes redistributed from outside OSPF. This lesson covers the third source: how an operator pulls routes from other sources (static, connected, BGP, kernel, other routing daemons) into OSPF, what the metric-type choice means, and how a route-map filters what gets in.

The redistribution configuration block

The redistribution block in VyOS 1.5 LTS:

set protocols ospf redistribute static
set protocols ospf redistribute connected
set protocols ospf redistribute bgp
set protocols ospf redistribute kernel

Each source is enabled independently. The block also accepts a metric, a metric-type, a route-map, and a route-tag:

set protocols ospf redistribute static metric 10
set protocols ospf redistribute static metric-type 1
set protocols ospf redistribute static route-map FILTER-STATICS
set protocols ospf redistribute static route-tag 100
commit
save

The defaults are: metric 20, metric-type 2, no route-map, no tag. Every production deployment should set an explicit metric and should pair redistribution with a route-map; the defaults silently leak too much.

flowchart LR
  subgraph "Sources"
    S1["static routes<br/>set protocols static route ..."]
    S2["connected routes<br/>(auto-derived from interface addresses)"]
    S3["BGP routes<br/>bgpd RIB"]
    S4["kernel routes<br/>ip route show"]
    S5["other routing daemons<br/>ripd, isisd, eigrpd"]
  end
  subgraph "OSPF ASBR"
    ASBR["redistribute block<br/>(route-map filter<br/>+ metric<br/>+ metric-type<br/>+ tag)"]
  end
  subgraph "OSPF domain"
    LSDB["Type-5 LSAs in the LSDB"]
    FIB["OSPF routes in the FIB"]
  end
  S1 --> ASBR
  S2 --> ASBR
  S3 --> ASBR
  S4 --> ASBR
  S5 --> ASBR
  ASBR -- "Type-5 LSA per prefix" --> LSDB
  LSDB --> FIB

Static and connected — the basic cases

Redistributing static routes is the canonical pattern at an upstream edge with a static default route to the ISP. The operator has configured:

set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
set protocols static route 10.99.0.0/16 next-hop 192.168.50.1

…and wants the OSPF domain to learn both. The redistribution:

set protocols ospf redistribute static metric 10 metric-type 1
commit
save

The two static routes are converted into Type-5 External LSAs and flooded into the OSPF domain.

Redistributing connected routes is rarer but useful. The operator who has an interface attached to a non-OSPF subnet (e.g. a partner’s LAN) can let OSPF learn about the connected route without configuring a network statement:

set protocols ospf redistribute connected metric 20 metric-type 2
commit
save

This is the right pattern when the partner’s subnet is on an interface that should NOT participate in OSPF adjacency formation but the prefix should still be advertised. The redistribute connected path keeps the interface out of OSPF (no Hello packets) but includes the connected prefix in the LSDB as a Type-5 LSA.

BGP into OSPF — the inter-domain bridge

The classic multi-domain redistribution pattern: an OSPF IGP inside a site, an eBGP session to the upstream or to a partner, and the operator wants the BGP-learned routes to be visible inside the OSPF domain.

set protocols ospf redistribute bgp metric 50 metric-type 1 route-map BGP-INTO-OSPF
set policy route-map BGP-INTO-OSPF rule 10 action permit
set policy route-map BGP-INTO-OSPF rule 10 match ip address prefix-list ALLOWED-PARTNERS
commit
save

The route-map is the critical piece. Without it, every BGP route — every full Internet table if the BGP peer is a default-free zone — is redistributed into OSPF. The OSPF LSDB and FIB grow by 900,000 prefixes; the router’s CPU climbs to handle SPF; the network effectively dies.

The route-map filter is the line between “OSPF knows about the partner’s three prefixes” and “OSPF knows about the entire Internet”. The route-map in the example above uses a prefix-list to enumerate the partner’s prefixes explicitly.

Metric-type 1 vs metric-type 2

OSPF external LSAs carry an external metric and a metric type. The metric type controls whether the external metric is cumulative as the LSA traverses the OSPF domain.

The pragmatic production rule: use Type 1 by default; it produces the correct cost when there are multiple paths to the ASBR through the OSPF domain. Use Type 2 when the ASBR is a single, fixed point and the operator specifically wants the external metric to dominate.

flowchart TB
  subgraph "Type 2 (E2): constant metric"
    A1["ASBR<br/>metric 50 (E2)"] --> R3["R3<br/>sees 50"]
    A1 --> R4["R4<br/>sees 50"]
    A1 --> R5["R5<br/>sees 50"]
  end
  subgraph "Type 1 (E1): cumulative metric"
    ASB["ASBR<br/>metric 10 (E1)"] --> R3a["R3 (cost 5)<br/>sees 10 + 5 = 15"]
    ASB --> R4a["R4 (cost 10)<br/>sees 10 + 10 = 20"]
    ASB --> R5a["R5 (cost 100)<br/>sees 10 + 100 = 110"]
  end

Route-map filtering and route-tagging

The route-map applied to the redistribution is the filter. The canonical pattern is to enumerate the prefixes that may be redistributed and deny everything else:

set policy prefix-list PARTNER-PREFIXES rule 10 permit 203.0.113.0/24
set policy prefix-list PARTNER-PREFIXES rule 20 permit 198.51.100.0/24
set policy route-map BGP-INTO-OSPF rule 10 action permit
set policy route-map BGP-INTO-OSPF rule 10 match ip address prefix-list PARTNER-PREFIXES
set policy route-map BGP-INTO-OSPF rule 20 action deny
set protocols ospf redistribute bgp metric 50 metric-type 1 route-map BGP-INTO-OSPF
commit
save

This configuration says: redistribute BGP into OSPF with metric 50, type 1, and only the prefixes in PARTNER-PREFIXES. Every other BGP route is denied. The deny rule at the end is the implicit default (FRR’s default action is deny when a route-map has at least one deny rule), so explicit rule 20 action deny is documentation as much as enforcement.

The route-tag is the audit trail. Every Type-5 LSA the ASBR originates carries a 32-bit tag the operator can read in show ip ospf database:

set protocols ospf redistribute bgp route-tag 65001
commit
save

sequenceDiagram
  participant BGP as bgpd RIB
  participant RM as route-map BGP-INTO-OSPF
  participant ASBR as OSPF ASBR
  participant LSDB as OSPF LSDB
  BGP->>RM: prefix 203.0.113.0/24
  RM->>RM: match prefix-list PARTNER-PREFIXES
  RM->>ASBR: permit 203.0.113.0/24
  ASBR->>LSDB: Type-5 LSA: 203.0.113.0/24, metric 50, metric-type 1, tag 65001
  BGP->>RM: prefix 8.8.8.0/24
  RM->>RM: match prefix-list PARTNER-PREFIXES -> no match
  RM-->>BGP: deny

How the result is validated

show ip ospf database external self-originate     # Type-5 LSAs this router originated
show ip ospf database nssa-external self-originate # Type-7 in an NSSA
show ip route ospf                                  # routes OSPF has installed
show ip route 10.99.0.0/16                          # specific prefix the operator expects

A working redistribution shows:

• A Type-5 LSA per expected prefix in show ip ospf database external.
• The expected metric, metric-type, and tag.
• The expected prefix in show ip route as an OSPF external (O E1 or O E2).

If the operator has a route-map, the database should show exactly the prefixes the route-map permits. Any other prefix is a route-map misconfiguration.

How it fails

The production failure modes the engineer must recognise:

• Redistribution loop. Two routers redistribute the same source into OSPF and OSPF into the source. Each router sees the other’s redistributed routes, re-originates them, and the LSDB oscillates. The fix is to use route-tagging: tag routes on the way in; deny routes with the tag on the way out.
• No route-map on BGP redistribution. The full BGP table floods into OSPF. The router becomes SPF-bound; the network becomes unstable. The fix is to add a route-map immediately.
• Metric-type mismatch with multiple ASBRs. Two ASBRs redistribute the same set of prefixes with different metric-types. The router that runs SPF picks one and rejects the other; the route may flap between the two paths. The fix is to standardise metric-type across ASBRs.
• Redistribution into a stub area. A router inside a stub area is configured to redistribute BGP into OSPF. OSPF refuses: stub areas cannot originate Type-5 LSAs. The fix is to redistribute at the ABR (which is outside the stub area) or to convert the area to NSSA (which permits Type-7).
• Default-route redistribution when default-information originate already exists. The operator has both. OSPF generates one Type-5 for the default; the operator does not realise why. Use one or the other, not both.

Rollback

The recovery from a bad redistribution:

• Remove a single redistribution. delete protocols ospf redistribute bgp and commit; save. The Type-5 LSAs from this redistribution are withdrawn; downstream routers lose the routes within the LSA refresh cycle.
• Tighten a route-map. Replace a permissive route-map with a restrictive one. The new Type-5 LSAs use the new route-map; the old ones are withdrawn when the route-map denies the prefix.
• Remove a route-tag. delete protocols ospf redistribute bgp route-tag 65001 and commit; save. The next Type-5 LSAs are originated without the tag. There is no transition period; the tag is per-LSA.

For any of these, rollback N inside configure reverts to a known-good revision.

Cross-course references

The VyOS lessons vyos-xviii-03-lsa-types covers the LSA types (Type-5 External, Type-7 NSSA-external) that the redistribution generates. The lesson vyos-xix-01-ospf-basics covers the default-information originate block which is the special case of redistribution for 0.0.0.0/0. The lesson vyos-xix-03-ospf-area-config covers the area-type restrictions on redistribution (stub areas refuse Type-5). The VyOS lessons on policy (Part XXVIII) cover the prefix-list and route-map primitives used in the route-map filter. The VyOS lessons on redistribution (Part XXXIV) cover the general redistribution concepts across multiple protocols.

Quiz