Redistribution concept — why redistribute, route-map filtering, metric preservation, seed metric

Redistribution is the bridge between routing protocols that do not natively share routes. OSPF does not know about BGP routes; BGP does not know about OSPF routes; the Linux kernel does not know about either until one is told. On a network that runs multiple protocols, the operator must explicitly configure the redistribution that carries routes from one protocol to another.

A correctly configured redistribution is small, deliberate, and auditable. An incorrectly configured one is the source of route leaks, suboptimal routing, and feedback loops.

This lesson introduces the vocabulary (source protocol, seed metric, metric preservation, route-map filter, administrative distance trap) and the production failure modes.

Why redistribution is necessary

Two routing protocols that coexist on a router have separate RIBs:

• OSPF has its Link-State Database (LSDB) and computes routes into the OSPF RIB.
• BGP has its Loc-RIB and computes routes into the BGP RIB.
• Static routes are in the kernel FIB; connected routes are auto-installed.

If the operator wants a route that lives in OSPF to be advertised by BGP (or vice versa), the operator must redistribute it: tell BGP “take this OSPF route and put it in your Loc-RIB” or tell OSPF “take this BGP route and put it in your LSDB”.

flowchart LR
  O["OSPF RIB<br/>10.10.0.0/16<br/>cost 50"] --> RM{"Filter<br/>route-map"}
  S["Static route<br/>192.168.100.0/24"] --> RM
  K["Kernel<br/>203.0.113.0/24"] --> RM
  C["Connected<br/>172.16.0.0/24"] --> RM
  RM -->|redistribute| BGP["BGP Loc-RIB<br/>origin: incomplete<br/>MED: configured seed"]

The redistribution has a source (the protocol the route came from), a destination (the protocol the route is being put into), and a filter (the route-map that decides which routes are eligible). Without a filter, every route from the source protocol is redistributed; with a filter, only the routes the operator enumerates are eligible.

The seed metric

A route being redistributed into a new protocol needs a metric. The seed metric is the metric value applied to the route when the source protocol has no meaningful metric to carry forward.

On VyOS 1.5 the BGP redistribution lives under the address family, and the OSPF one takes a numeric metric type:

configure
# BGP redistributing OSPF with a seed metric of 100
set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast redistribute ospf metric 100

# OSPF redistributing BGP with metric 200 as a type-2 external
set protocols ospf redistribute bgp metric 200
set protocols ospf redistribute bgp metric-type 2
commit
save

Two details that bite:

• metric-type takes 1 or 2, not external-1 / external-2. The words belong to the OSPF literature and to some other vendors’ CLIs; VyOS wants the digit.
• The metric ranges start at 1. BGP accepts 1–4294967295 and OSPF 1–16777214, so metric 0 is not a value you can configure. If you want the redistributed routes to carry MED 0, you get that by omitting metric entirely, which is a different thing from asking for it and a much easier thing to do by accident.

The seed metric is the default for everything the redistribution carries; a route-map can override it per prefix with set metric.

The route-map filter

The route-map is the production pattern for redistribution filtering. It selects which routes are eligible for redistribution and how they are manipulated:

configure
# Prefix-list enumerating the routes to redistribute
set policy prefix-list TO-BGP rule 10 action 'permit'
set policy prefix-list TO-BGP rule 10 prefix '10.10.0.0/16'
set policy prefix-list TO-BGP rule 20 action 'permit'
set policy prefix-list TO-BGP rule 20 prefix '192.168.0.0/16'
set policy prefix-list TO-BGP rule 20 le '24'

# Route-map applying the filter and stamping a community
set policy route-map OSPF-TO-BGP rule 10 action 'permit'
set policy route-map OSPF-TO-BGP rule 10 match ip address prefix-list 'TO-BGP'
set policy route-map OSPF-TO-BGP rule 10 set metric '100'
set policy route-map OSPF-TO-BGP rule 10 set community add '64512:400'

# Redistribution statement referencing the route-map
set protocols bgp address-family ipv4-unicast redistribute ospf route-map 'OSPF-TO-BGP'
commit
save

Three shapes in that block are easy to get wrong:

• A prefix-list rule needs a prefix. There is no way to write a bare “deny everything else” rule, and you do not need one: a prefix-list ends in an implicit deny. The old habit of appending rule 100 action deny with no prefix produces an incomplete rule, not a catch-all.
• ge and le are their own nodes, not modifiers appended to the prefix. prefix '192.168.0.0/16' and le '24' are two commands.
• Community is set community add <value> on 1.4 and 1.5 — add or replace, with delete and none for the other operations. The 1.3-era set community 64512:400 additive is not this tree.

The route-map does three things:

• Filters — match ip address prefix-list TO-BGP restricts the redistribution to the enumerated prefixes.
• Manipulates — set metric 100 and set community 64512:400 additive write attributes to the redistributed routes.
• Implicit deny — routes that do not match a permit rule in the route-map are filtered.

Without the route-map, every route from the source protocol is redistributed. This is the production anti-pattern: it leaks routes the operator did not enumerate and creates suboptimal paths.

The administrative-distance trap

When two routing protocols both learn the same prefix, the administrative distance (AD) decides which protocol wins in the kernel FIB. The redistribution can create situations where the wrong protocol wins.

The classic trap: R1 redistributes BGP into OSPF, so every other router in the OSPF area now learns those prefixes as OSPF externals at AD 110. Whether that is a problem depends entirely on how those routers were also learning the prefix, and the two cases point in opposite directions:

• iBGP at AD 200 loses to the OSPF external at 110. A router with both an iBGP path and the redistributed OSPF external installs the OSPF one. That may be exactly what you wanted — or it may route traffic to the ASBR that redistributed it rather than to the exit closest to the destination.
• eBGP at AD 20 beats the OSPF external at 110. Here the redistribution changes nothing on that router, which is its own kind of confusing: the OSPF external is in show ip route as a candidate and never installed, so the redistribution looks broken when it is working.

Say the direction out loud before configuring it. “Redistributing BGP into OSPF will make routers that only had iBGP prefer the path through the ASBR” is a design statement you can check against the topology. “Redistributing makes the routes available” is not, and it is the sentence that produces the traffic-through-the-wrong-exit incident.

The levers, in the order worth reaching for them:

• Do not redistribute if the routes are already reachable. Most instances of this trap exist because someone redistributed to solve a problem that iBGP already solved.
• Filter with a route-map. A redistribution that carries only enumerated prefixes has a bounded blast radius; one that carries everything does not.
• Choose the metric-type deliberately. Type 1 adds the cost to the ASBR, so different routers prefer different ASBRs — usually what you want with several exits. Type 2 carries a constant, so every router sees the same metric and the tie is broken by the internal cost to the ASBR (the “forwarding cost”). Type 2 is the FRR default.
• Adjust administrative distance only as a last resort, and only where you can name the routers you are changing. set protocols ospf distance ospf external <n> moves the OSPF external distance; it is a big lever with effects well beyond the prefixes you were thinking about.

Failure modes

Unfiltered redistribution leaks routes

The operator configures redistribute ospf without a route-map. Every OSPF route is advertised into BGP. Internal prefixes (10.0.0.0/8, 192.168.0.0/16, …) leak to the eBGP peer.

Diagnostic:

• show bgp ipv4 neighbors 10.0.0.2 advertised-routes shows internal prefixes.
• The peer receives the internal prefixes and may advertise them to its peers.

Fix: add a route-map that enumerates the prefixes to redistribute.

The seed metric was never set

The operator configures redistribute ospf with no metric. The routes enter BGP with MED 0 — the lowest possible value, and the one a peer reads as “prefer this”. The operator intended these routes to be a backup.

Note that this failure is reached by omission, not by misconfiguration: metric 0 is outside the accepted range and would have been rejected, so nobody typed it. The default is just the same as what the rejected value would have meant.

Diagnostic:

• show bgp ipv4 10.10.0.0/16 shows the local route with metric 0 (or no metric shown, which for MED means the same thing to most peers).
• show bgp ipv4 neighbors 10.0.0.2 advertised-routes shows what the peer is actually being sent.
• Ask the peer what MED they see on the competing path. MED is only compared between routes from the same neighbouring AS, so if the alternative comes from a different AS, MED is not the attribute deciding this and raising it will change nothing.

Fix: set the metric explicitly, to a value chosen against the competing path rather than to a round number.

Feedback loop through mutual redistribution

R1 redistributes OSPF into BGP. R2 (a BGP peer) redistributes BGP back into OSPF. R1 sees its own OSPF routes come back through OSPF as external routes. The metric oscillates; the routes flap; the network becomes unpredictable.

Diagnostic:

• show ip ospf database external self-originate on R1 lists the type-5 LSAs R1 is originating. A prefix R1 believes it learned from OSPF appearing in its own external LSAs is the loop, visible in one command.
• show bgp ipv4 on R1 shows the same prefixes with an AS_PATH or community that came back from the far side.

Fix: tag routes on redistribution and deny the tag on re-redistribution. See xxxiv-06-redist-anti-patterns.

An OSPF external never displaces an OSPF internal

The operator redistributes BGP into OSPF for a prefix the OSPF domain already carries internally. The external route is generated, the LSA is flooded, and nothing changes. Raising or lowering the redistribution metric changes nothing either.

This is not a bug and no metric will fix it. OSPF’s route preference is by type first, cost second. The order is intra-area, then inter-area, then external type 1, then external type 2, and a route of a more preferred type wins regardless of cost. An intra-area route at cost 5000 beats a type-2 external at cost 1. Cost only breaks ties within one type.

Diagnostic:

• show ip route 10.10.0.0/16 shows the intra-area OSPF route installed.
• show ip ospf database external shows your type-5 LSA is being originated — so the redistribution is working; it is just losing.
• Cross-check on a router that has no internal path to that prefix. If the external is installed there, the type-precedence explanation is confirmed and the configuration is not at fault.

Fix: recognise that this is the design telling you the redistribution is redundant for this prefix. If you genuinely need traffic to take the external path, the answer is to stop advertising the prefix internally, not to fight the type precedence with metrics.

Rollback

A redistribution change is reversible through the standard VyOS mechanisms:

• delete protocols bgp address-family ipv4-unicast redistribute ospf and commit removes the redistribution entirely. This is the narrow undo and usually the right one.
• delete protocols bgp address-family ipv4-unicast redistribute ospf route-map removes only the filter. Read that twice before running it: the redistribution stays, now unfiltered, which is strictly worse than either having it filtered or not having it. This is a step in a rewrite, never a rollback.
• delete policy route-map OSPF-TO-BGP while a redistribution still references it is rejected at commit. VyOS’s verify_route_map helper checks that every referenced route-map exists and raises Specified route-map "OSPF-TO-BGP" does not exist!. You cannot silently break the reference, which is a genuinely useful guarantee — though note it checks existence, not that the route-map contains any rules. An empty route-map passes the validator and denies everything.
• rollback <N> reverts the whole configuration to a stored revision and currently requires a reboot on VyOS. It is not the tool for undoing one redistribution statement.

Do the change under commit-confirm when the redistribution feeds the routes you are reaching the router over.

Production discipline

Cross-course references

• XXV-VyOS-BGPAdvertise (vyos-xxv-03-bgp-redistribute-static, vyos-xxv-04-bgp-redistribute-ospf) covers specific redistribution cases in detail.
• XXXIII-VyOS-RoutePolicy (this course’s Part XXXIII) covers the route-map filtering that is the basis for redistribution discipline.
• XXXIV-VyOS-Redistribution (the next lessons in this part) covers each redistribution source (static, OSPF, connected, kernel) and the anti-patterns.

Quiz