I ran into this situation on a recent project and thought it would make an excellent question on an exam. It could be worded something like this:

What is the behavior of a router or Layer 3 switch when a dynamic route is learned that partially overlaps with a directly connected network?

  1. The router reboots
  2. The network reboots
  3. That's um-possible
  4. None of the above

The answer, of course, is #4 but the specifics of what does happen is what's interesting. First, this is the scenario I'm trying to describe in the question above:

R12#show ip route
...
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
D        10.1.14.0/24 [90/1024640] via 123.1.1.14, 00:14:37, Ethernet0/1
C        10.10.10.0/24 is directly connected, Ethernet0/0    <<<<<<
L        10.10.10.12/32 is directly connected, Ethernet0/0
D        10.10.10.64/26 [90/1024640] via 123.1.1.14, 00:14:05, Ethernet0/1  <<<<<<

R12 has a directly connected network 10.10.10.0/24 on its e0/0 interface. It has also learned a route for 10.10.10.64/26 via an EIGRP neighbor on its e0/1 interface. We can see both networks are present in the routing table.

Everything seems fine, however here's the issue: a host (R11) at 10.10.10.111 is trying to reach the rest of the network via R12 (10.10.10.12 is its default gateway) but is unsuccessful.

R11#ping 10.1.14.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.14.14, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

In fact, R11 can't even ping its default gateway:

R11#ping 10.10.10.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.12, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

However, if R11 is readdressed to 10.10.10.11, everything works fine.

R11(config)#int e0/0
R11(config-if)#ip addr 10.10.10.11 255.255.255.0
R11(config-if)#^Z
R11#ping 10.1.14.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.14.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

What's going on?

Well, since R11 and R12 are directly connected, we're most likely looking at a Layer 2 issue. So let's start by putting R11 back to 10.10.10.111 and checking the ARP cache on both devices.

R11#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.12             0   aabb.cc00.0c00  ARPA   Ethernet0/0
Internet  10.10.10.111            -   aabb.cc00.0b00  ARPA   Ethernet0/0

R12#show ip arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.11             2   aabb.cc00.0b00  ARPA   Ethernet0/0
Internet  10.10.10.12             -   aabb.cc00.0c00  ARPA   Ethernet0/0
Internet  10.10.10.111            1   aabb.cc00.0b00  ARPA   Ethernet0/0

There's an ARP reply in both caches, however they cannot ping each other. And no, there is nothing in between that's blocking traffic and the hardware addresses in the ARP caches are correct on both routers.

So what in the name of John Chambers is going on?

Ok, enough games, let's get right to it. This is an example of the order of operations that are followed when the router looks for a path to a destination. The 10.10.10.64/26 route is more specific than the 10.10.10.0/24 route so even though the /24 route is directly connected, the /26 route takes precedence in the RIB. Because of this, R12 considers 10.10.10.64 through .127 to be "over there" somewhere and not directly connected on e0/0. We can prove this by inspecting the RIB:

R12#show ip route 10.10.10.111
Routing entry for 10.10.10.64/26
  Known via "eigrp 65201", distance 90, metric 1024640, type internal
  Redistributing via eigrp 65201
  Last update from 123.1.1.14 on Ethernet0/1, 01:06:23 ago
  Routing Descriptor Blocks:
  * 123.1.1.14, from 123.1.1.14, 01:06:23 ago, via Ethernet0/1
      Route metric is 1024640, traffic share count is 1
      Total delay is 1002 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1400 bytes
      Loading 1/255, Hops 1

Yes the directly connected network has a much better admin distance than the EIGRP route (0 vs 90) however longest prefix match takes priority over admin distance. Since a /26 is more specific than a /24, traffic for 10.10.10.64 - .127 will follow the /26 route.

We can independently verify this by inspecting some debug info on R12 to see what its doing with the ICMP echo request and reply messages:

R12#debug ip packet detail 2000
IP packet debugging is on (detailed) for access list 2000
R12#

!>>> Incoming ICMP echo request:
*Jul 11 17:30:33.303: IP: s=10.10.10.111 (Ethernet0/0), d=10.10.10.12, len 100, input feature
*Jul 11 17:30:33.303:     ICMP type=8, code=0, Common Flow Table(5), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

!>>> Outgoing ICMP echo reply:
*Jul 11 17:30:33.304: FIBipv4-packet-proc: route packet from (local) src 10.10.10.12 dst 10.10.10.111
*Jul 11 17:30:33.304: FIBfwd-proc: packet routed by adj to Ethernet0/1 123.1.1.14
*Jul 11 17:30:33.304: FIBipv4-packet-proc: packet routing succeeded
*Jul 11 17:30:33.304: IP: s=10.10.10.12 (local), d=10.10.10.111 (Ethernet0/1), len 100, sending
*Jul 11 17:30:33.304:     ICMP type=0, code=0

This confirms that R12 is receiving the echo request from R11 on its e0/0 interface but is sending the echo reply out the e0/1 interface.

So, what's the answer to the question posed above?

What is the behavior of a router or Layer 3 switch when a dynamic route is learned that partially overlaps with a directly connected network?

Traffic always follows the longest prefix match (ie, most specific match) in the RIB. This is true for traffic sourced by a router and for traffic transiting a router. Administrative distance is only compared if the prefix length of two or more routes is the same.