Most networks do not run one routing protocol. Mergers bolt an EIGRP shop onto an OSPF backbone, a campus hands off to a service provider running BGP, or a legacy site keeps RIP alive years past its expiry date. Route redistribution is how you make those islands share routes, and it is one of the most error-prone tools in the IP routing toolbox. Done casually, it produces missing routes, suboptimal paths, and full-blown routing loops.
This guide walks through redistribution on Cisco IOS XE end to end: how seed metrics work, what each protocol demands before it will accept foreign routes, and what the routing table actually looks like at every stage. Every capture comes from a live CML lab, and we break it on purpose along the way (the broken cases feed our companion posts on loop prevention with route tags and troubleshooting redistribution).
The Lab
Four IOS XE routers in a chain. R1 and R2 run OSPF area 0. R3 and R4 run EIGRP named mode, autonomous system 100. The R2-R3 link is the domain boundary, and both protocols are active on it, which makes R2 and R3 both border routers (that becomes important later). R4 also owns 172.16.4.0/24 on a loopback that is deliberately kept out of EIGRP's network statements, so we can demonstrate redistributing connected routes.
VM (192.168.99.100) = R1 = R2 = R3 = R4
OSPF area 0: R1, R2, and the R2-R3 link | EIGRP AS 100: the R2-R3 link, R3, R4
R1-R2: 10.0.12.0/24 | R2-R3: 10.0.23.0/24 | R3-R4: 10.0.34.0/24 | Lo0 = N.N.N.N
What Redistribution Actually Does
Redistribution takes routes that one protocol installed in the routing table and injects them into another protocol's database as external routes. Two details in that sentence cause most real-world surprises.
First, redistribution pulls from the routing table, not from the source protocol's internal database. If OSPF learned a route but EIGRP won the installation battle for that prefix (lower administrative distance), then "redistribute ospf" will not export it, because the table says it is an EIGRP route. Second, the receiving protocol has no idea what the original metric meant. OSPF cost and EIGRP composite metrics are different currencies, so the receiving protocol stamps a seed metric onto every imported route, and each protocol has its own rules about it.
Seed Metrics: Each Protocol Has Different Defaults
Into OSPF
Default seed metric 20 (1 for BGP routes). Type E2 by default: the metric does not grow inside the domain. Subnets are included by default on modern IOS XE.
Into EIGRP
Default seed metric is infinity. No metric configured means the route is silently never advertised. This is the number one redistribution failure.
Into BGP
IGP metric is copied into MED. Redistribution into BGP is common at the edge; redistribution of BGP into an IGP is almost always a design mistake (full tables melt IGPs).
Into RIP
Default seed is also infinity. Legacy, but the same rule applies: set a hop-count seed metric or nothing is advertised.
The external routes also arrive with a different administrative distance. OSPF external routes keep AD 110, but EIGRP marks externals with AD 170 instead of the internal 90 (a built-in loop defense, as we will see).
Before Redistribution: Two Isolated Domains
R1 sits purely in the OSPF domain. Its routing table knows nothing about 10.0.34.0/24, the loopbacks of R3 and R4, or 172.16.4.0/24:
R1# show ip route ospf | begin Gateway
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11] via 10.0.12.2, 00:04:55, Ethernet0/1
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 10.0.23.0/24 [110/20] via 10.0.12.2, 00:04:53, Ethernet0/1R2, the border router, is more interesting. It sees both worlds natively and shows the two administrative distances side by side (110 for OSPF, 90 for internal EIGRP):
R2# show ip route | begin Gateway
O 1.1.1.1 [110/11] via 10.0.12.1, 00:08:03, Ethernet0/0
D 3.3.3.3 [90/1024640] via 10.0.23.3, 00:08:42, Ethernet0/1
D 4.4.4.4 [90/1536640] via 10.0.23.3, 00:08:30, Ethernet0/1
D 10.0.34.0/24 [90/1536000] via 10.0.23.3, 00:08:42, Ethernet0/1
O 192.168.99.0/24 [110/20] via 10.0.12.1, 00:08:03, Ethernet0/0Configuring Redistribution on IOS XE
We redistribute in both directions on R3. EIGRP named mode buries the redistribute statement under the topology base of the address family, which trips up people used to classic mode:
R3(config)# router ospf 1
R3(config-router)# redistribute eigrp 100 subnets
R3(config-router)# exit
R3(config)# router eigrp PINGLABZ
R3(config-router)# address-family ipv4 unicast autonomous-system 100
R3(config-router-af)# topology base
R3(config-router-af-topology)# redistribute ospf 1 metric 1000000 1 255 1 1500The EIGRP seed metric is five values: bandwidth in Kbit/s, delay in tens of microseconds, reliability, load, and MTU (here 1 Gbps, 10 microseconds, perfect reliability, minimal load, 1500 bytes). Only bandwidth and delay influence the composite metric with default K values, but all five are mandatory.
A note on the famous subnets keyword: on current IOS XE it is the default behavior. The running config confirms it with the line "eigrp, includes subnets in redistribution" under show ip protocols. On legacy IOS, omitting it silently limited redistribution to classful networks, and you will still find that behavior in the field, so we keep typing it out of habit and clarity.
What happens if you skip the EIGRP metric? Nothing is advertised, with no error message. We cover the failure signature in detail in the troubleshooting post, but the short version from this lab: show ip protocols happily lists "Redistributing: ospf 1" while the topology table reports "Total Redist Count: 0" and R4 answers show ip route 1.1.1.1 with "% Network not in table".
After Redistribution: Reading the External Routes
With the seed metric in place, R4 learns the entire OSPF domain as EIGRP externals:
R4# show ip route | begin Gateway
D EX 1.1.1.1 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0
D EX 2.2.2.2 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0
D EX 10.0.12.0/24 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0
D EX 10.0.112.0/24 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0
D EX 192.168.99.0/24 [170/1029120] via 10.0.34.3, 00:00:30, Ethernet0/0Note the D EX code and the AD of 170 in the brackets. Internal EIGRP routes sit at 90; external ones are deliberately less trusted. In the other direction, R1 receives the EIGRP domain as OSPF type E2 externals with the default seed metric of 20:
R1# show ip route ospf | begin Gateway
O 2.2.2.2 [110/11] via 10.0.12.2, 00:06:33, Ethernet0/1
O E2 3.3.3.3 [110/20] via 10.0.12.2, 00:00:36, Ethernet0/1
O E2 4.4.4.4 [110/20] via 10.0.12.2, 00:00:36, Ethernet0/1
O E2 10.0.34.0/24 [110/20] via 10.0.12.2, 00:00:36, Ethernet0/1
O E2 172.16.4.0 [110/20] via 10.0.12.2, 00:00:36, Ethernet0/1E2 metrics stay at 20 no matter how deep in the OSPF domain the route travels; only the forward metric (the internal cost to reach the ASBR) breaks ties. If you want the internal cost added to the seed metric as the route propagates, redistribute with metric-type 1 to produce E1 routes. E1 is the better choice when multiple ASBRs inject the same prefixes and you want OSPF to pick the closer exit honestly.
External Routes Carry Their History
EIGRP external routes carry the source protocol, the originating router, and the external metric inside the topology table. This is gold when auditing who injected what:
R3# show eigrp address-family ipv4 topology 172.16.4.0/24
10.0.34.4 (Ethernet0/1) ... route is External
External data:
External protocol is Connected, external metric is 0
Originating router is 4.4.4.4Here 172.16.4.0/24 entered EIGRP at R4 via redistribute connected, and every EIGRP router downstream can see that lineage.
One Border Router or Two?
Everything above used a single redistribution point, which is inherently loop-free: routes cross the boundary in one place, and there is no second door for them to sneak back through. The moment you add a second border router for redundancy (a very reasonable thing to want), you create a feedback path. A prefix redistributed from EIGRP into OSPF at R3 can travel through OSPF to R2 and be redistributed back into EIGRP, now wearing a fresh seed metric that may beat the original route.
In this lab, enabling the same two-way redistribution on R2 produced a genuine forwarding loop between R2 and R3 within seconds of a routine delay change. The traceroute ping-pongs between the two border routers until the TTL dies:
R1# traceroute 172.16.4.4 numeric timeout 1 probe 1 ttl 1 10
1 10.0.12.2 3 msec
2 10.0.23.3 3 msec
3 10.0.23.2 2 msec
4 10.0.23.3 4 msec
5 10.0.23.2 3 msec
6 10.0.23.3 4 msecThe full anatomy of that loop, and the route-tag design that fixes it permanently, gets its own deep dive: Redistribution Loop Prevention: Route Tags, AD, and Filtering. The one-sentence rule: any time you run two or more redistribution points, tag routes as they cross the boundary and deny your own tags from coming back.
Verification Commands That Earn Their Keep
Design Rules Worth Stealing
Prefer a single redistribution point unless you truly need redundancy, and when you need two, deploy route tags from day one rather than after the first loop. Always set an explicit seed metric into EIGRP and RIP (make it pessimistic, so external paths lose to internal ones on honest terms). Use E1 externals in OSPF when multiple ASBRs advertise the same prefixes. Filter what you redistribute with a route-map even when you think you want everything, because "everything" grows over time. And never redistribute BGP into an IGP without an aggressively specific filter.
Controlling What Crosses: Route-Maps at the Boundary
Bare redistribute statements move everything, and "everything" is rarely the intent six months later. A route-map on the redistribute command gives you a policy point for three jobs at once: filtering (only these prefixes may cross), tagging (mark everything that crosses, the loop-prevention backbone), and metric shaping (give this class of routes a worse seed so the backup domain stays a backup). The full tagged configuration from this lab's border routers looks like this and costs four short stanzas:
route-map EIGRP-TO-OSPF deny 10
match tag 200
route-map EIGRP-TO-OSPF permit 20
set tag 100
!
router ospf 1
redistribute eigrp 100 subnets route-map EIGRP-TO-OSPFFiltering by prefix uses match ip address prefix-list in the same structure. One subtlety worth engraving somewhere: a route-map applied to redistribution evaluates routes, not packets, so the counters in show route-map tick per prefix evaluation and are your fastest proof of whether a filter clause is actually catching anything.
Redistributing Between OSPF Processes
Not every boundary separates different protocols. Two OSPF processes on one router (a merger where both companies ran OSPF, or a VRF handoff) redistribute exactly like foreign protocols: redistribute ospf 2 under router ospf 1 and vice versa, routes arrive as E2 with everything that implies, and two-point designs loop just as enthusiastically. There is no special kinship between OSPF processes; the SPF domains are fully separate, and all the seed metric, tagging, and AD logic in this guide applies unchanged.
What About the Default Route?
Redistribute statements do not move the default route; each protocol has a dedicated mechanism instead. OSPF wants default-information originate (with always if the ASBR should advertise it even without holding a default itself), and EIGRP named mode is happiest with a summary address or a redistributed static to 0.0.0.0/0. In a two-domain design, decide deliberately which domain owns internet egress, originate the default only there, and let specific routes flow the other way; two domains both originating defaults into each other is a slow-motion loop generator that tags will not save you from, because the prefix is legitimately different on each origination.
FAQ
Do I need the subnets keyword on IOS XE?
Functionally no on current releases (the router reports "includes subnets in redistribution"), but it is free to type, self-documenting, and required on the legacy IOS still running in plenty of racks. Type it.
Why AD 170 for EIGRP externals but 110 for OSPF externals?
EIGRP deliberately distrusts routes that left the domain and came back, which single-handedly prevents many feedback loops on the EIGRP side. OSPF makes no internal/external AD distinction by default, which is why the OSPF side of a two-point design is where loops are born; you can retrofit the split with distance ospf external 175.
Should I redistribute BGP into my IGP?
Almost never wholesale. A full table is two orders of magnitude beyond what IGP flooding is designed for. Redistribute a filtered handful of prefixes if you must, or better, originate a default from the edge and let the IGP carry only internal state.
E1 or E2 externals?
E2 (the default) keeps the seed metric flat everywhere, fine when one ASBR injects the routes. E1 adds internal cost as the route propagates, correct when multiple ASBRs inject the same prefixes and routers should prefer their nearer exit.
Key Takeaways
Redistribution copies routes from the routing table into another protocol as externals, stamped with a seed metric. EIGRP's default seed is infinity, so forgetting the metric silently advertises nothing, while OSPF defaults to a flat E2 metric of 20. External routes carry reduced trust (EIGRP AD 170) and, in EIGRP's case, full lineage data in the topology table. Single-point redistribution is naturally loop-free; two-point redistribution demands route tags. For the wider context of how routing protocols fit together, head back to the IP Routing pillar, and when redistribution misbehaves, the troubleshooting guide walks the failure signatures with live captures.