CCNP ROUTE TSHOOT Lab: Redistributing RIP Into EIGRP
Here’s the topology for this EIGRP route redistribution lab. The last octet of each router’s IP address will be the router number — R1 has 172.12.123.1 /24 on the serial network, and so forth.
We’re going to perform one-way route redistribution in this lab, moving that one RIP route (10.1.1.0 /24) into EIGRP.
EIGRP requires a seed metric that’s just a tad more complex than that of RIP, and there are two different ways to define that seed metric. We can apply a seed metric for routes from a specific source as part of the redistribute command itself, or we can use default-metric to set that value for all routes learned via redistribution.
R3(config)#router eigrp 100 R3(config-router)#no auto R3(config-router)#? Router configuration commands: address-family Enter Address Family command mode auto-summary Enable automatic network number summarization bfd BFD configuration commands default Set a command to its defaults default-information Control distribution of default information default-metric Set metric of redistributed routes
In this lab, we’ll take the first approach, defining the five necessary metrics as we go along in the command. Before we get started, let’s make sure R3 has that RIP route in its routing table:
R3#show ip route rip 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:23, Serial0/1/0
Thar she blows! Let’s get that route redistributed. I’ll use IOS Help to show you the five required values.
R3(config)#router eigrp 100 R3(config-router)#redistribute rip ? metric Metric for redistributed routes route-map Route map reference <cr> R3(config-router)#redistribute rip metric ? <1-4294967295> Bandwidth metric in Kbits per second R3(config-router)#redistribute rip metric 1544 ? <0-4294967295> EIGRP delay metric, in 10 microsecond units R3(config-router)#redistribute rip metric 1544 10 ? <0-255> EIGRP reliability metric where 255 is 100% reliable R3(config-router)#redistribute rip metric 1544 10 255 ? <1-255> EIGRP Effective bandwidth metric (Loading) where 255 is 100% loaded R3(config-router)#redistribute rip metric 1544 10 255 1 ? <1-65535> EIGRP MTU of the path R3(config-router)#redistribute rip metric 1544 10 255 1 1544 ? route-map Route map reference <cr> R3(config-router)#redistribute rip metric 1544 10 255 1 1544
Previous IOS versions mentioned “IGRP” where you see “EIGRP” in IOS Help above. That’s just an IOS quirk – don’t sweat it if you see it. Right now, let’s have a look at the EIGRP tables on R4 and R5.
R4#show ip route eigrp 100 Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [170/1662976] via 30.1.1.3, 00:01:25, FastEthernet0/0 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/1662976] via 30.1.1.3, 00:01:25, FastEthernet0/0
R5#show ip route eigrp 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [170/1662976] via 30.1.1.3, 00:00:26, GigabitEthernet0/0 172.12.0.0/24 is subnetted, 1 subnets D EX 172.12.123.0 [170/1662976] via 30.1.1.3, 00:00:26, GigabitEthernet0/0
Victory! The routes are both marked “D EX,” indicating an EIGRP External route — in other words, a route learned via redistribution. The AD of each route is 170, as opposed to an EIGRP Internal route (90).
We always check the point-of-redistribution router for any routing shenanigans, so let’s have a look at R2’s routing table, before and after redistribution.
Before:
R2#show ip route 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:17, Serial0/1/0
After:
R2#show ip route 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:26, Serial0/1/0
R2 has this route as a RIP route before and after redistribution, even though R2 hears about the route via EIGRP and RIP. We do tend to think of EIGRP as superior to RIP, so what’s going on here?
The EIGRP external route AD of 170 is higher than that of RIP’s 120, so the RIP route is preferred over the EIGRP external route. That’s all there is to it. Should R2’s serial interface mysteriously go down again (heh heh heh), the EIGRP external path will be put into the routing table.
R2(config)#int serial 0/1/0 R2(config-if)#shut R2#show ip route 10.0.0.0/24 is subnetted, 1 subnets D EX 10.1.1.0 [170/1662976] via 30.1.1.3, 00:00:04, FastEthernet0/0
I’ll reopen that interface, the route is again a RIP route, and we press on!
R2(config)#int serial 0/1/0 R2(config-if)#no shut R2#show ip route 10.0.0.0/24 is subnetted, 1 subnets R 10.1.1.0 [120/1] via 172.12.123.1, 00:00:02, Serial0/1/0
Let’s say we want the EIGRP route to be preferred over the RIP route. We’ll change the AD of EIGRP external routes on R2 to 119, just one less than RIP’s AD, and that should do it. This particular command requires you to enter both the internal and external AD, even if you’re just changing one.
R2(config)#router eigrp 100 R2(config-router)#distance ? <1-255> Set route administrative distance eigrp Set distance for internal and external routes R2(config-router)#distance eigrp ? <1-255> Distance for internal routes R2(config-router)#distance eigrp 90 ? <1-255> Distance for external routes R2(config-router)#distance eigrp 90 119 ? <cr> R2(config-router)#distance eigrp 90 119
This command will not take effect immediately. At the very least, you have to clear your routing table. You could tear the EIGRP adjacencies down, but we’ll just clear the routing table and see what happens.
R2#clear ip route * %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 30.1.1.5 (FastEthernet0/0) is down: route configuration changed %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 30.1.1.3 (FastEthernet0/0) is down: route configuration changed %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 30.1.1.4 (FastEthernet0/0) is down: route configuration changed %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 30.1.1.5 (FastEthernet0/0) is up: new adjacency %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 30.1.1.4 (FastEthernet0/0) is up: new adjacency %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 30.1.1.3 (FastEthernet0/0) is up: new adjacency
And that’s what happens! The adjacencies came down due to the change in the AD. That’s something to keep in mind when you work with this command in a production network. In the lab, as long as the adjacencies come back up, we’re fine with the very temporary down.
Coming up next, we’ll introduce ACLs to our redistribution labs. That’s coming up on July 26, 2018. Right now, follow these links to learn from other labs on the site. There’s also a huge (and free!) CCNP ROUTE playlist on YouTube with tons of great redistribution info.