ide, thus alleviating the problem. Looking at our configurations, we can see the problem is that we've in- cluded the loopback networks in our EIGRP processes. Removing them solves our recursive route problems: Router-A (config)#router eigrp 100 Router-A(config-router)# no network 10.100.100.0 0.0.0.255 Here's the new configuration for Router A: router eigrp 100 network 10.10.10.0 0.0.0.255 network 172.16.0.0 0.0.0.255 no auto-summary We'll do the same on Router D for its loopback network, and then we'll be able to see the desired result on Router A. Now the route to the remote loopback address has been learned through RIP, and the route to the remote Ethernet has been learned through EIGRP: Router-A#sho ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets 172.16.0.0 is directly connected, Tunnelo 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks 10.20.20.0/24 90/297246976] via 172.16.0.2, 00:03:23, Tunnelo 10.10.10.0/24 is directly connected, Etherneto/1 10.100.100.100/32 is directly connected, Loopback0 10.200.200.200/32 [120/3] via 192.168.1.2, 00:00:11, Serial0/1 192.168.1.0/24 is directly connected, Serial0/1 192.168.2.0/24 [120/1] via 192.168.1.2, 00:00:12, Serial0/1 192.168.3.0/24 [120/2] via 192.168.1.2, 00:00:12, Serial0/1 GRE tunnels are not usually a good idea, because they complicate networks. If someone were troubleshooting the network we just built, the tunnel would only add complexity. Usually, introducing a GRE tunnel into a network without a clear need is the result of poor planning or design. Routing across a VPN is one of the few legitimate needs for a GRE tunnel (IPSec, the protocol widely used in VPN, does not forward multicast or broadcast packets, SO GRE is required). Running a GRE tunnel through a VPN tunnel can get you the routing protocol link you need. Why not just run the GRE tunnel? Remember that GRE does not encrypt data. Figure 12-5 shows a common layout incorporating GRE over VPN. GRE Tunnels and Routing Protocols 10.10.10.0/24 10.20.20.0/24 VPN tunne