s, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Take a look at the bandwidth and delay for the tunnel interface. The defaults are an extremely low speed, and an extremely high delay, and because EIGRP uses these metrics to determine feasible distance, the tunnel appears to be a much less desir- able path than the existing serial links. This is beneficial because the tunnel is built over what could potentially be a multitude of links and routers. A tunnel is a soft- ware device, which means that the processing delay for the interface is variable (unlike with a physical interface). Tunnels should not be the most desirable paths by default. To prove that the tunnel is running, and to show how the virtual link behaves, here is a traceroute from Router A to the closest serial interface on Router D, which is 192.168.3.2 on S0/1: Router-A# trace 192.168.3.2 Type escape sequence to abort. Tracing the route to 192.168.3.2 1 192.168.1.2 4 msec 4 msec 0 msec 2 192.168.2.2 4 msec 4 msec 4 msec 3 192.168.3.2 4 msec 4 msec 4 msec Router-A# And here's a traceroute to the remote end of the tunnel on Router D (172.16.0.2), which is on the same router some three physical hops away: Router-A# trace 172.16.0.2 Type escape sequence to abort. Tracing the route to 172.16.0.2 1 172.16.0.2 4 msec 4 msec 4 msec Router-A# The other end of the tunnel appears to the router to be the other end of a wire or link, but in reality, the tunnel is a logical construct composed of many intermediary devices that are not visible. Specifically, the tunnel hides the fact that Routers B and Care in the path. GRE Tunnels and Routing Protocols The introduction of a routing protocol across a GRE tunnel can cause some interest- ing problems. Take, for example, our network, now altered as shown in Figure 12-3. This time we have the links between the routers updating routes using RIPv2. The Chapter 12: Tunnels other interfaces on Router A and Router D are included in RIP using the redistribute connected command. EIGRP is running on 