o/1 10.100.100.100/32 is directly connected, Loopback0 10.200.200.200/32 90/297372416] via 172.16.0.2, 00:00:04, Tunnelo 192.168.1.0/24 is directly connected, Serial0/1 192.168.2.0/24 [120/1] via 192.168.1.2, 00:00:00, Serial0/1 192.168.3.0/24 [120/2] via 192.168.1.2, 00:00:00, Serial0/1 Once this occurs, the routers on both sides immediately recognize the problem, and shut down the tunnel. The EIGRP route is lost, and the RIP route returns. The router will then bring the tunnel back up, and the cycle will continue indefinitely until something is changed. The reason for the recursive route problem is the administrative distances of the protocols in play. RIP has an administrative distance of 120, while EIGRP has an administrative distance of 90. When the protocol with the better administrative dis- tance learns the route, that protocol's choice is placed into the routing table. Figure 12-4 shows how the different routing protocols are both learned by Router A. RIP administrative distance= 120 10.10.10.0/24 10.20.20.0/24 192.168.2.0/24 Router B Router C 192.168.1.0/24 RIP v2 192.168.3.0/24 Router A EIGRP 100 Router D 10.100.100.100/32 10.200.200.200/32 Tunnel 172.16.0.0/24 EIGRP administrative distance= 90 Figure 12-4. EIGRP route learned through tunnel GRE Tunnels and Routing Protocols In the case of the tunnel running EIGRP, the issue is that the route to the remote end of the tunnel is known through the tunnel itself. The tunnel relies on the route to the remote loopback interface, but the tunnel is also providing the route to the remote loopback interface. This is not allowed, SO the router shuts down the tunnel. Unfor- tunately, it then brings the tunnel back up, which causes the routes to constantly change, and the tunnel to become unstable. The solutions to this problem are either to stop using tunnels (recommended in this case), or to filter the remote side of the tunnel SO it is not included in the routing pro- tocol being run through the tunnel (EIGRP). Installing a VPN would work as well, as the VPN wou