Questions about Redistribution Case #2 in the Workbook

Hi everyone,

I have been doing the redistribution lab case 2 and I think I have been stuck at some point.

I understand that after R1 redistributes routes from EIGRP to OSPF, R3 makes the route to 150.1.9.9 via R1 preferable as the path has the lower AD of 110. Then R3 redistributes the route from OSPF to EIGRP to R1, which in turn makes R1 prefers the path via R3 because of the lower metric after the redistribution on R3. The redistribution on both routers are then performed on and on between the two routers and that is where the loop is.

I have a couple of questions for this.

1, Based on the debug output below, why does R3 keep flushing its route to 150.1.9.9? Let's say R3 has installed the route via R1 since the first redistribution on R1. At that point, R3's routing table to 150.1.9.9 is via R1 with the AD of 110 and the metric of 20. Even though the route is later on redistributed back from R1, the update from R1 is still telling R3 to go via it and with the AD of 110 and metric of 20. Why would R3 see that update from R1 differently from what it has installed in its routing table and decide to flush the route again and again?

RT: closer admin distance for 150.1.9.9, flushing 1 routes
RT: add 150.1.9.9/32 via 155.1.13.1, ospf metric [110/20]
RT: updating eigrp 150.1.9.9/32 (0x0):
via 155.1.37.7 Fa0/1.37

RT: rib update return code: 17
RT: updating eigrp 150.1.9.9/32 (0x0):
via 155.1.13.1 Fa0/1.13

RT: rib update return code: 17
RT: updating eigrp 150.1.9.9/32 (0x0):
via 155.1.13.1 Fa0/1.13

RT: rib update return code: 17
R3#
RT: del 150.1.9.9 via 155.1.13.1, ospf metric [110/20]
RT: delete subnet route to 150.1.9.9/32
RT: updating eigrp 150.1.9.9/32 (0x0):
via 155.1.13.1 Fa0/1.13

RT: add 150.1.9.9/32 via 155.1.13.1, eigrp metric [170/36096]
RT: updating eigrp 150.1.9.9/32 (0x0):
via 155.1.37.7 Fa0/1.37

RT: del 150.1.9.9/32 via 155.1.13.1, eigrp metric [170/36096]
RT: add 150.1.9.9/32 via 155.1.37.7, eigrp metric [170/30976]
RT: updating eigrp 150.1.9.9/32 (0x0):
via 155.1.37.7 Fa0/1.37

R3#u
RT: updating ospf 150.1.9.9/32 (0x0):
via 155.1.13.1 Fa0/1.13

RT: closer admin distance for 150.1.9.9, flushing 1 routes
RT: add 150.1.9.9/32 via 155.1.13.1, ospf metric [110/20]
RT: updating eigrp 150.1.9.9/32 (0x0):
via 155.1.37.7 Fa0/1.37

2, Question 2 is based on question 1. I also notice on R3's routing table to 150.1.9.9 that it will install the path via R7. Why would R3 has a chance to install this path when it has the "better" path to R1 with the lower AD of 110? As mentioned earlier, even though R1 is redistributing the route to R3 indefinitely, the route update still has the AD of 110 and metric of 20.

R3#show ip route 150.1.9.9
Routing entry for 150.1.9.9/32
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
Redistributing via eigrp 100
Advertised by eigrp 100 metric 1000000 1 255 1 1500
Last update from 155.1.13.1 on FastEthernet0/1.13, 00:00:03 ago
Routing Descriptor Blocks:
* 155.1.13.1, from 150.1.1.1, 00:00:03 ago, via FastEthernet0/1.13
Route metric is 20, traffic share count is 1

R3#show ip route 150.1.9.9
Routing entry for 150.1.9.9/32
Known via "eigrp 100", distance 170, metric 30976, type external
Redistributing via eigrp 100
Last update from 155.1.37.7 on FastEthernet0/1.37, 00:00:01 ago
Routing Descriptor Blocks:
* 155.1.37.7, from 155.1.37.7, 00:00:01 ago, via FastEthernet0/1.37
Route metric is 30976, traffic share count is 1
Total delay is 210 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

Sign In or Register to comment.