Connecting an internal OSPF network to a new BGP-speaking edge, an ISP handoff, a data center BGP core, a merger bringing two OSPF domains together through a shared boundary, is one of the more common jobs a mid-level network engineer gets handed. Routes need to flow both ways: OSPF routes need to reach BGP so the rest of the network is reachable from outside, and BGP-learned routes need to come back into OSPF so the internal network can reach out. The redistribute command on both sides looks like the obvious, complete answer.
It isn't, and the reason is worth understanding before you type it rather than after a ticket opens.
OSPF and BGP don't measure route quality the same way. OSPF's metric is link-state cost, cumulative bandwidth-derived numbers that only mean something inside OSPF's own topology. BGP's decision process runs on path attributes, AS-path length, local preference, MED, that only mean something inside BGP's own view of the internet or the WAN. When you redistribute one into the other, the receiving protocol can't actually evaluate the borrowed route on its merits, it just assigns it a default seed metric and treats it as a normal route of its own from that point forward. That's fine in one direction. It's the reason two-way redistribution without any filtering is dangerous: a route that originated in OSPF, once redistributed into BGP, looks to OSPF like any other BGP-learned route if it gets redistributed back in on the other boundary router, somewhere else in the topology. OSPF has no memory that this route used to be its own. If the reinjected version arrives with a lower cost than the original ever had, which the seed metric on redistribution can absolutely produce, OSPF will believe the new, worse path over the correct one, sending traffic on a two-hop or three-hop detour through BGP and back for a destination that was one hop away the whole time. Worse, with more than one redistribution boundary in the topology, this can settle into an actual routing loop instead of just a suboptimal path, because each boundary router has a locally correct-looking reason to prefer the reinjected route.
The fix is route tagging, and it's standard practice for exactly this reason: when redistributing OSPF into BGP, apply a route-map that sets a distinctive tag on every route as it crosses the boundary. Then, on the redistribution running the other direction, BGP into OSPF, apply a route-map that explicitly denies any route carrying that tag before it's allowed back in. The tag travels with the route as metadata; a route that already picked up the tag on its way out is recognizably not a fresh BGP route, it's an OSPF route coming home, and the filter stops it from ever completing the loop. The pattern generalizes: whichever protocol a route originated in, mark it on the way out, filter on that mark on the way back in, so redistribution becomes two one-way flows instead of one loop-shaped two-way flow that happens to work until the topology gets one boundary router more complex than whoever configured it originally tested.
This is the actual content of enterprise routing and automation work, not a corner case saved for a whiteboard interview question, and it's exactly the ground the Network Engineer L2 book covers: 256 pages, 20 labs and 151 interview questions on enterprise routing, switching, BGP and the automation tooling that manages it at scale: https://resources.codelivly.com/product/network-engineer-l2/
The free Network Automation & Scripting learning path on codelivly.com is a hands-on way to work the automation half of the same job before spending anything: https://codelivly.com/learning-paths/network-automation-scripting
