nown through the serial link, is still known through the serial link, and not the tunnel. If the tunnel is theoretically directly connected to both routers, why isn't the tunnel the preferred path? Digging into our EIGRP expertise, we can use the show ip eigrp topology command to see what EIGRP knows about the paths: Router-A# sho ip eigrp top 5d18h: %SYS-5-CONFIG I: Configured from console by console IP-EIGRP Topology Table for AS(100)/ID(192.168.1.1) Codes: P - Passive, A - Active, U - Update, 0 - Query, R - Reply, r - reply Status, S - sia Status P 10.20.20.0/24, 1 successors, FD is 3196416 via 192.168.1.2 (3196416/2684416), Serial0/1 via 172.16.0.2 (297246976/28160), Tunnelo P 10.10.10.0/24, 1 successors, FD is 281600 via Connected, Etherneto/1 P 192.168.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0/1 Both paths appear in the table, but the distance on the tunnel path is huge com- pared with that of the serial interface. To find out why, let's take a look at the virtual tunnel interface: Router-A# sho int tu 0 Tunnelo is up, line protocol is up Hardware is Tunnel Internet address is 172.16.0.1/24 MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 10.100.100.100 (Loopbacko), destination 10.200.200.200 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Checksumming of packets disabled, 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, 0 packets/sec 88293 packets input, 7429380 bytes, 0 no buffer GRE Tunnels 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 collision