Route redistribution can make two routing domains reachable while quietly creating a path for routes to return to their origin. The interview question is: what can go wrong when redistributing OSPF, EIGRP and BGP, and how do you prevent it?
Short answer: the main risks are route feedback, unexpected path selection, incompatible metrics and unwanted prefix propagation; Cisco documents filtering and route-tag policies as ways to control these risks.[2] My recommended starting point is a narrow prefix allowlist, explicit target-protocol metrics, origin tagging with return-path rejection, and failure testing at every redistribution boundary.
What redistribution actually changes
Redistribution advertises reachability learned through one routing source into another routing protocol; it is not the same as forming a neighbor relationship between OSPF and EIGRP.[2] The receiving protocol needs a metric it understands, so comparing an OSPF cost directly with an EIGRP composite metric is not meaningful.[2] For ordinary Cisco learned-route redistribution, first check which source owns the installed route in the routing table, not merely whether the prefix appears in a protocol database.[2] Connected networks associated with a redistributed routing process have special behavior, so do not simplify this into “every connected route requires redistribute connected.”[2]
Treat redistribution as a policy boundary. Before configuring it, write down which prefixes should cross, in which direction, and who owns each prefix.
The main risks and their controls
| Risk | What can happen | Recommended control |
|---|---|---|
| Route feedback | A route crosses into another protocol and is advertised back into its original domain.[2] | Tag at entry and deny re-entry at every return boundary. |
| Unexpected preference | Administrative distance selects a different source than intended, causing inefficient routing or convergence problems.[2] | Inspect actual route ownership on both border routers, including during failure. |
| Wrong seed metric | Target-protocol metrics are missing or unsuitable.[2] | Configure explicit metrics and verify the remote result. |
| Route leak | Unfiltered redistribution exports unintended prefixes.[2] | Use an explicit prefix allowlist and review denied routes. |
| Unsafe rollback | Removing only a redistribution option can leave redistribution running without its filter.[1] | Test rollback syntax and inspect the resulting running configuration. |
A two-border route-feedback example
This fictional topology is a teaching example, not output from an executed router lab:
OSPF domain
/ \
Edge-A Edge-B
\ /
EIGRP domain
OSPF-owned test prefix: 192.0.2.0/24
EIGRP-owned test prefix: 198.51.100.0/24
Imagine the following control-plane flow:
- Edge-A learns the OSPF-owned prefix through OSPF.
- Edge-A exports it into EIGRP as an external route.
- Edge-B receives that EIGRP advertisement.
- If its route eligibility and redistribution policy permit, Edge-B can advertise the prefix back into OSPF.
This is the feedback pattern Cisco's mutual-redistribution example warns about; whether it produces a selected wrong path, a forwarding loop or only redundant advertisements depends on route selection and topology.[2] Do not claim that mutual redistribution automatically creates a forwarding loop in every stable network.
The desired policy outcome is simpler: OSPF-origin routes may enter EIGRP, but may not return from EIGRP into OSPF. Apply the equivalent rule to EIGRP-origin routes in the opposite direction.[2]
Why administrative distance alone is not enough
On Cisco, the common default distances are eBGP 20, internal EIGRP 90, OSPF 110, external EIGRP 170 and iBGP 200.[1] For competing eligible sources of the same prefix and mask, lower administrative distance normally wins installation in the routing table.[1]
For example, an OSPF route normally beats an external EIGRP copy of that same prefix; an OSPF copy can also beat an iBGP route because of these defaults.[1] But administrative distance is a route-selection control, not an origin-based export filter, and Cisco warns that redistribution can still produce loops, inefficient routing or convergence problems.[2]
My recommendation: do not start by lowering distances until a ping works. First document route ownership and block feedback explicitly; then evaluate whether any scoped distance policy is actually required.
A restrictive OSPF-to-EIGRP policy example
The following is an original illustrative Cisco IOS/IOS XE classic-mode configuration, not a tested device transcript. It assumes existing OSPF process 10 and EIGRP AS 100, working adjacencies, and only the two documentation prefixes shown above. Adapt syntax to your software and VRF.
The policy uses tags as origin markers, following Cisco's set-tag/match-tag redistribution pattern.[2]
ip prefix-list OSPF-OWNED seq 10 permit 192.0.2.0/24
ip prefix-list EIGRP-OWNED seq 10 permit 198.51.100.0/24
!
route-map OSPF-TO-EIGRP deny 10
match tag 200
route-map OSPF-TO-EIGRP permit 20
match ip address prefix-list OSPF-OWNED
set tag 100
!
route-map EIGRP-TO-OSPF deny 10
match tag 100
route-map EIGRP-TO-OSPF permit 20
match ip address prefix-list EIGRP-OWNED
set tag 200
!
router eigrp 100
redistribute ospf 10 metric 100000 100 255 1 1500 route-map OSPF-TO-EIGRP
!
router ospf 10
redistribute eigrp 100 metric 20 metric-type 1 subnets route-map EIGRP-TO-OSPF
Tag 100 means “entered from OSPF”; tag 200 means “entered from EIGRP” in this example. These values are our policy convention, not reserved protocol constants. The deny sequence rejects a returning route before the permit sequence can retag it; setting a tag without matching it on a return path does not implement this rejection.[2] The allowlists intentionally restrict exports to the owned prefixes. Do not add an unconditional final permit merely to make missing routes appear.
Use the same origin convention and equivalent return-path checks at both border routers. With three protocols or additional boundaries, draw the complete export graph and verify how origin information survives every transition; do not assume one pair of tags solves an arbitrary topology.
Metric and OSPF details to check
The EIGRP seed fields specify bandwidth, delay, reliability, load and MTU; Cisco expresses bandwidth in kbps and delay in tens of microseconds.[2]
The five fields are configuration inputs, not a claim that all five contribute to the default composite metric.
The OSPF example explicitly selects a metric and external type, and includes subnets for subnet redistribution in classic IOS syntax.[2]
Treat the chosen metric values as lab inputs, not universal production recommendations. Verify that the intended border is selected from several remote routers.
What changes when BGP is involved?
In Cisco's documented default behavior, redistribute bgp makes eBGP-learned information eligible for IGP redistribution; iBGP routes require bgp redistribute-internal, which Cisco explicitly cautions can introduce loops.[2]
Do not enable that command simply because an expected route is missing. Check the route source, installed route, export filter and intended architecture first.
I recommend exporting only the small set of BGP prefixes the IGP actually needs, or evaluating a deliberately originated default where the design allows it. Do not use unrestricted Internet-table redistribution as a connectivity shortcut.
For Cisco OSPF, default-route origination uses default-information originate; an ordinary redistribute static statement is not a substitute for originating the default.[1]
A BGP session being Established is only the start of this investigation. Separate session health from route eligibility, filtering and forwarding.
Troubleshooting: follow one prefix end to end
Illustrative verification commands for a classic IPv4 lab:
show ip route 192.0.2.0
show ip protocols
show route-map
show ip prefix-list
show ip ospf database external 192.0.2.0
show ip eigrp topology 192.0.2.0 255.255.255.0
show ip bgp 192.0.2.0
show ip cef 192.0.2.1
Recommended checklist:
- Identify the context: exact prefix/mask, address family and VRF.
- Inspect the exporting border's RIB: which source actually owns the route?
- Read policy in order: does an earlier deny reject it, and does the permit match the exact intended prefix?
- Inspect the receiving domain: confirm route type, metric, tag and next hop, not just prefix presence.
- Inspect the other border: prove that the route cannot return to its origin under the intended policy.
- Check forwarding both ways: compare FIB entries and test from representative endpoints.
- Test withdrawal and recovery in a lab: remove the original advertisement and confirm that a stale returned copy does not keep the prefix falsely reachable.
For rollback, beware the documented Cisco behavior where removing only the route-map option from a redistribution statement can leave unfiltered redistribution enabled.[1] Review the exact remaining command rather than treating a successful CLI response as proof that redistribution stopped.
Common interview pitfalls
- “Tags automatically prevent loops.” Cisco's policy examples require both setting tags and rejecting matching return routes.[2]
- “One protocol's loop prevention protects the whole multi-protocol design.” Cisco documents feedback across redistribution boundaries as a separate risk.[2]
- “The route is in the protocol database, so it must be exported.” Check installed-route ownership and applicable redistribution rules.[2]
- “Enable every route category until connectivity works.” Start with the explicit prefix inventory instead.
- “A successful ping proves failover is safe.” Require route withdrawal, recovery and return-path tests as well.
A concise interview answer
“Redistribution is a controlled export of reachability between routing sources, and the main risks are feedback, bad path preference, incompatible metrics and route leaks.[2] I would allow only required prefixes, assign target-protocol metrics, mark origins and reject routes returning to their original domain at every boundary.[2] I would check the installed route and remote next hop, then test loss of the original route rather than only steady-state reachability. With Cisco BGP-to-IGP redistribution, I would also check the default iBGP restriction before considering any change.”[2]
Related reading
Summary
Use redistribution as an explicit routing policy, not a blanket bridge between protocols. My practical rule is: allowlist, set metrics, preserve origin, reject feedback, and test withdrawal.
Preparing for a network engineering interview? Draw two redistribution routers, trace one prefix through both domains, and explain exactly where your policy stops it from coming back.
Post a Comment