ed, fast tunneling enabled Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, o packets/sec 88293 packets input, 7429380 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 80860 packets output, 6801170 bytes, 0 underruns 0 output errors, 0 collisions, 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 met- rics to determine feasible distance, the tunnel appears to be a much less desirable 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 software device, which means that the processing delay for the interface is variable (unlike with a phys- ical interface). Tunnels should not be the most desirable paths by default. Chapter 12: Tunnels 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 r