Troubleshooting AD Redistribution

Hi Rene and staff,

i want to add another comment for the final solution. Perhaps it could help someone
"
R4 will use the EIGRP external entry (AD 170) for 1.1.1.0 /24. R2 and R3 both redistribute 1.1.1.0 /24 into EIGRP, the route that R4 installs depends on the seed metric
"
In the lesson R2 redistribute RIP into EIGRP with BW=1000
And R3 redistribute OSPF into EIGRP with BW=1500
So in my opinion R4 will install the route via R3
I don’t know why so low values are used in the lesson with FastEthernet (?)

But in my GNS3 lab, i set R2 and R3 both to redistribute 1.1.1.0/24 into EIGRP with the same composite metrics (BW= 100 000, DL, etc…) So, with this topology and the same redistribution composite metrics and the same K-values, from the perspective of R4 there are two paths with the same metric, and EIGRP could load balance between these paths. Let’s find the R4’s RIB from my lab (in my lab the name of interfaces are not the same)
Image13

Regards

2 Likes

Hello Dominique

Even if the route on R4 is installed and removed so quickly that you can’t see it with a show ip route command, if you issue the ip route profile command, as shown in the lesson, it will show you how many times the route was installed and removed. Do you see these counters going up as they should in your topology?

If so, then the only thing I can say is that it is just by chance, or for some reason, the route remains in the routing table for such a small amount of time, compared to R2. Remember that the route flapping in R2 is occurring between routes that are learned between RIP and OSPF, where on R4, the route flapping is occurring with EIGRP only. The variation in timers that are used by the particular protocols plays a role in how quickly a routing protocol converges. It can be said that EIGRP converges very quickly, and for this reason, you cannot “catch” the route in the table.

I hope this has been helpful!

Laz

Hello Dominique

Yes you are correct.

Split horizon says, as you very well know, that you cannot learn about a route from the same interface that you advertised it out of. Because we have a loop here, R2, R3, R4, each router will always learn about 1.1.1.0/24 from an interface from which it did not learn about it. It learns about it from one interface, and informs the next router from another interface. This happens on R2, R3, R4, and then again on R2, from an interface other than the one it was sent out of. Regardless of which routing protocol is being used, the fact that we have a physical loop with redistribution can allow a route to cause such a routing malfunction and split horizon is helpless to rectify it.

I hope this has been helpful!

Laz

Hello Rene/Laz,

I configured the same AD redistribution topology on GNS3 and resolved the issue using the first method i . e by applying a lower AD for the RIP route from R1 for 1.1.1.0/24 and I am seeing results in the routing table that R2 is learning 1.1.1.0/24 from R1 with the AD 100. All good there however I am not able to ping 1.1.1.0/24 from R3 and R4 even though these routers have route to 1.1.1.0/24 in their routing table. Also I redistributed connected network under RIP on R2 but 192.168.23.0/24 is still unreachable from R1. All configs were done exactly per the lesson. Can you please help clarifying this issue?

R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
**Success rate is 0 percent (0/5)**

R3#sh ip route | begin Gateway
Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
**D EX     1.1.1.0 [170/2636800] via 192.168.34.4, 00:08:08, Ethernet0/1**

R4#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
**Success rate is 0 percent (0/5)**

R4#sh ip route | begin Gateway
Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
**D EX     1.1.1.0 [170/2611200] via 192.168.24.2, 00:09:48, Ethernet0/1**

R1#ping 192.168.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.2, timeout is 2 seconds:
.....
**Success rate is 0 percent (0/5)**

R1#ping 192.168.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds:
.....
**Success rate is 0 percent (0/5)**

I found the issue and fixed. It was a silly mistake I made on R2. I missed “version 2” command on R2 and R1 was configured with version 2. Now I have full connectivity after I configured version 2 command on R2. Thank you anyway!

R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

R4#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R1#sh ip route | begin Gateway
Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        1.1.1.0/24 is directly connected, Loopback0
L        1.1.1.1/32 is directly connected, Loopback0
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, Ethernet0/0
L        192.168.12.1/32 is directly connected, Ethernet0/0
R     192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:03, Ethernet0/0
R     192.168.24.0/24 [120/1] via 192.168.12.2, 00:00:03, Ethernet0/0
R     192.168.34.0/24 [120/1] via 192.168.12.2, 00:00:03, Ethernet0/0

Hello Philip

Thanks for sharing your solution with us, it’s always helpful to see your solutions to the problems that you face. If you have any other issues, you know where to find us!

Laz

I am wrong or we can fix this issue with tag the redistribution?

Hello Angelo

Yes, you could use route tagging to resolve this issue. You could tag the route when it is being redistributed from RIP to EIGRP on R2, so that when this is re-redistributed from R3 to R2 via OSPF, it is simply not accepted.

Although this solution would be fine for this topology, making changes to the AD would be more appropriate than using tagged routes. This is because in the event that a specific route does indeed fail, you would want the alternate route to be installed in the routing table. When using route tagging, the alternate route would not be installed, however by adjusting the ADs, that alternate route would be installed, making this solution a more robust and preferable one.

I hope this has been helpful!

Laz