Understanding Network Infrastructure · Part 5 · Connecting the enterprise network to branches, clouds, and the Internet
Why can an OSPF route come back through another protocol?
Adapting route information between routing domains and preventing feedback
Between OSPF and another routing protocol, passing routes across the boundary does not preserve their original metrics and source information unchanged. A boundary router must define permitted prefixes and new metrics, and use route tags to help keep the same routes from returning to their original domain. We follow one prefix across both boundaries to find where loops can form and how to set and verify policy.
Across different routing protocols, does a route retain its meaning?↑
OSPF cost and LSA types are not equivalent to BGP AS_PATH or LOCAL_PREF. When a boundary router redistributes an OSPF route into another protocol, it does not transfer the entire original calculation. It uses the selected prefix and next-hop information in the destination protocol to create a new route.
Eligible route sources, whether only paths installed in the RIB are considered, and whether connected and static routes need separate inclusion all depend on the implementation and command. First establish exactly which prefixes a line such as 'redistribute ospf' includes.
Even if a boundary router's RIB selects 10.20.30.0/24 as an OSPF route, redistribution into another protocol does not carry over the entire OSPF topology and cost calculation. The boundary presents the prefix as a newly originated external route with the destination protocol's attributes. The receiving router does not inherently know it began as an internal OSPF route.
Which routes qualify for redistribution also requires platform-specific care. A protocol database may hold entries that the RIB has not selected as routes. Commands also differ in whether they include connected interfaces, static defaults, and summaries. Do not infer the scope from the source protocol's name alone. In the route map or policy, specify allowed prefixes and original RIB sources. Display the candidate list before applying policy to check that a broader route set will not cross the boundary.
'We connected OSPF to BGP' is therefore not specific enough. State which VRF, route sources, and prefixes cross which boundary, with which attributes and metrics. Check whether connected or static routes are included and when a default route is created, using both the route map and actual advertisements.
Sources for this section IETF RFC 2328 · IETF RFC 4271 · Cisco Routing Protocol Redistribution
In another protocol, a route needs a new metric and route type↑
For a route crossing a boundary, the destination protocol needs a comparable metric. External routes introduced into OSPF need an external type and external metric; another IGP may require its own composite metric or hop count.
Some implementations treat the default seed metric as infinity, preventing advertisement. An excessively low value can also make an external route as attractive as an internal one. Do not just match metric numbers: decide which path should win during a failure, then express that intent in the destination protocol's terms.
When OSPF imports an external route, E1 accounts for both the external metric and the internal cost to the ASBR (or to the forwarding address if it is nonzero); E2 generally uses the external metric as its primary value. The right type depends on whether internal cost should affect selection among exits. Other protocols give metrics different meanings. Copying a source cost of 20 does not preserve the same preference.
Assigning one seed metric to every prefix can make WAN and static routes with different origins and quality appear to have the same external cost. For each prefix group and entry point, classify the metric and type, and work out which boundary should be preferred during a failure. Check the device documentation for defaults and specify them explicitly in the configuration. A value change can alter the selected routes across the target domain, so review not just representative prefixes but also the total number of accepted routes.
For OSPF external routes, E1 adds the internal cost to the ASBR—or to a nonzero forwarding address—to the external metric, while E2 generally prioritizes the external metric. The route type therefore affects selection, too. Check detailed tie-breaking against the implementation and topology. First decide which boundary should be preferred within the destination domain, then assign metrics and types to express that choice.
Sources for this section IETF RFC 2328 · Cisco Routing Protocol Redistribution
Two-way route redistribution at two boundaries can send a prefix back to its original domain↑
Suppose Boundary A imports an OSPF prefix into protocol X, and Boundary B imports protocol X routes into OSPF. Unless B can separately identify that a route originally came from OSPF, it may advertise it back as a new OSPF external route.
If the returned external route survives after a failure removes the original internal route, traffic may head for the wrong boundary or enter a loop. This is hard to detect from the normal-state routing table alone. Failure tests need to take links down and deliberately withdraw routes.
Suppose OSPF prefix 10.20.30.0/24 crosses Boundary A into EIGRP and reenters OSPF at Boundary B as an external route. The original and the returned copy coexist. While the original OSPF link works, the internal route may win and hide the problem. Once it is withdrawn, the remaining external copy may point toward B while EIGRP points back toward A, exposing a forwarding loop.
This problem can exist even when every protocol neighbor appears connected. To validate bidirectional redistribution, test blocking just one boundary, withdrawing only the original prefix, and restoring the two boundaries in different orders. TTL Exceeded messages, recurring next hops, and route age are clues. The simplest solution is to center the design on one protocol and reduce the number of redistribution directions. Where redistribution is unavoidable, apply consistent origin identification and input filtering at every boundary.
Changing administrative distance alone does not solve this in every failure state. Mark each prefix's originating domain and explicitly filter routes from reentering their source domain. Simulate the loss of one boundary, one protocol, and the original prefix, not just the state where both boundaries work.
Sources for this section IETF RFC 2328 · IETF RFC 4271 · Cisco Routing Protocol Redistribution
Route tags and prefix policies identify routes that must not return↑
First, define each prefix's original owning domain and the boundaries allowed to advertise it. Use a prefix list or policy to redistribute only approved ranges, handling more-specific exceptions and the default route separately. If one broad summary replaces many internal routes, verify that actual reachability supports it.
A route tag can mark the source of a route crossing a boundary. Boundary A can tag routes from OSPF, and Boundary B can reject reentry into OSPF for that tag to prevent route feedback. The tag is not carried in packets and does not automatically stop loops. It works only when policies at all boundaries interpret it consistently.
The address plan might assign 10.20.0.0/16 to the OSPF domain and 10.30.0.0/16 to another domain. Each boundary exports only the required lengths of its own prefixes. If those same owned prefixes return from the other domain, import policy rejects them. This prefix-ownership filter is the basic defense; route tags provide finer-grained source markings across boundaries.
If tag 100 means 'OSPF routes exported to EIGRP,' every boundary must use the same meaning and match order. Check that the destination protocol preserves the tag, including when the route later enters another protocol. The tag is not in an IP packet header and does not directly stop data-plane loops. Policy must read it and reject the route or change an attribute. Verify both the tag in route output and the relevant policy hits.
Do not rely on tags alone. Also use prefix lists, route sources, interfaces, VRFs, and attributes such as communities in the destination protocol. An allowlist reduces the risk of automatically leaking new internal prefixes, but it needs an update process. For each rule, document the source, permitted direction, tag/metric to set, and the matching rejection condition at the opposite boundary.
Sources for this section IETF RFC 2328 · Cisco Routing Protocol Redistribution
What to look for A route exported from one domain receives route tag 100. If a route with that tag returns through another boundary, it is rejected. Compare the policy directions and rejection conditions on the two ASBRs. The tag identifies the origin of a redistributed route; it is not a value added to the IP header of a user's packet.
↔ Scroll horizontally to explore the diagram.
A default route or summary can redirect far more traffic than expected↑
Default-route redistribution draws traffic for otherwise unknown destinations toward the boundary. Unless you distinguish default-route presence, unconditional advertisement, and the original next hop's state, internal routers may keep sending traffic there after external connectivity fails.
A summary route reduces route count and propagation of changes, but can remain after some child prefixes disappear. Review null routes for loop prevention, preference between redundant boundaries, and conditions for advertising more-specific routes. Redistribution provides connectivity, but its policy also determines the scope of a failure.
If a boundary always advertises a default regardless of actual Internet reachability, internal routers keep sending traffic for otherwise unknown destinations there after its upstream circuit fails. Even when origination depends on tracking or RIB presence, verify that the condition represents the remote scope you want to protect. With redundant boundaries, define primary and backup through metrics and policy, and plan internal behavior if both defaults are withdrawn.
Advertising summary 10.20.0.0/16 when only 10.20.30.0/24 exists can attract traffic for the rest of the /16. A null route at the boundary prevents looping by discarding that traffic. When some child prefixes move to another boundary, verify that their more-specific routes take precedence over the summary. Defaults and summaries reduce route count, but also determine where traffic is dropped during failures.
Decide whether to originate a default unconditionally or only when an upstream route or tracking condition exists. For summaries, review the aggregating device's discard route and partial-failure behavior. If another boundary advertises a more-specific exception prefix, longest prefix match takes precedence over default-route preference. Check actual FIB results for sample destinations in normal, partial-failure, and total-failure states.
Sources for this section IETF RFC 2328 · IETF RFC 4271
Trace a prefix back to its source protocol and across every boundary it crossed↑
Scenario: Everything works normally, but when one boundary goes down, traffic for 10.20.30.0/24 loops between the two domains.
- State the prefix's original owning domain and permitted advertisement direction in one line.
- At each boundary, record the pre-redistribution RIB source and the post-redistribution route type, metric, and tag.
- Check the order in which inbound and export policies match prefixes and tags.
- Withdraw the original internal route and observe whether the returning external route remains.
- Check whether defaults or summaries are hiding more-specific failures.
- After the correction, take each boundary down in turn, test failures in one and both directions, and check recovery behavior.
Start tracing the affected prefix in its source domain's protocol database. Build a table following the source RIB, boundary export policy, destination protocol database, remote boundary import policy, and the source domain's RIB again. At each stage, record route type, metric, next hop, tag, age, and policy name. Where the source information disappears or a new tag appears tells you exactly where to apply the loop-prevention policy.
Before changing policy, check whether current traffic depends on any returned routes and assess the impact of blocking them immediately. Apply a filter to a limited set of prefixes, observe route counts and policy hits, then withdraw the original route to test backup behavior. Bring each boundary down and up in turn. Verify that routes appear and disappear in the expected order, and that the FIB matches the hops taken by actual packets. Include tags, metrics, and filters in the rollback procedure.
This approach explains a 'redistribution loop' through changes to a prefix's source and meaning across boundaries, not just two lines of configuration. After a change, mechanically compare the affected prefix, every other prefix matched by the same policy, and the effects on defaults and summaries.
Sources for this section IETF RFC 2328 · IETF RFC 4271 · Cisco Routing Protocol Redistribution
Glossary↑
Sources and verification
- IETF RFC 2328 — OSPF external LSAs, metric types, and route tags
- IETF RFC 4271 — Standard behavior of BGP routes and path attributes
- Cisco Routing Protocol Redistribution — Seed metrics and mutual redistribution in a vendor implementation
Redistribution is not one common procedure shared by all standard protocols. It is a router's local implementation and policy. Check vendor documentation for command defaults, included route sources, tag preservation, and metric conversion.