cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
639
Views
0
Helpful
13
Replies
Highlighted
Beginner

Final traceroute hop failing

Does anyone have any insight on why I would be able to successfully ping a loopback address, but cannot successfully traceroute to it without the last hop timing out? I am not using any ACLs/NAT/Firewalls in this test.

 

Example topology:

R3<->R1<->R2

R1 Loopback = 1.1.1.1/32

R2 Loopback = 2.2.2.2/32

R3 Loopback = 3.3.3.3/32

 

I am using GNS3 with CSR1000v 16.06.07 images.

 

Each routers interface is inheriting the IP address from the loopback through IP unnumbered. OSPF is routing throughout this topology, with the only networks advertised being the loopbacks of each router (which are also the router ID for each).

 

In the attached screenshot, R3 initiates a traceroute to R2 (2.2.2.2). R1 responds back with an ICMP port-unreachable for 1.1.1.1, but we do not receive anything from R3. I'm wondering why this is, and if it's related to the IP unnumbered configuration.

 

Any insight would be greatly appreciated.

 

 

13 REPLIES 13
Highlighted
Enthusiast

You have an ACL on 2.2.2.2?

 

Linux does not use ICMP in traceroute, rather uses UDP (33434-33534) so would explain this.

 

Martin

Highlighted

Thanks for your reply. No ACL's on either of the 3 routers whatsoever. Bare bones config, with the exception of IP addressing and OSPF, and hostname.

 

I understand that Linux sends UDP datagrams for traceroute, but each hop along the way will send an ICMP "time exceeded" to the sender, and when the final destination is reached, an ICMP "Port Unreachable" is sent to the source. My guess is that it is not being sent back to the source. Again, not sure if it has to do with the loopback/IP unnumbered.

Highlighted

It is odd that you are able to ping but not able to traceroute. Perhaps if you post the config from 1.1.1.1 we might get some understanding. Also might help if you run debug ip packet, try the traceroute and post the debug output.

HTH

Rick
Highlighted

Thanks Richard.

 

Below is the config for R1. Please note that all 3 routers are configured identially with the exclusion of the loopbacks, router ID, interface number, and hostname.

 

R1#show run
Building configuration...

Current configuration : 1678 bytes
!
! Last configuration change at 14:52:12 UTC Thu Apr 16 2020
!
version 16.6
service timestamps debug datetime msec
service timestamps log datetime msec
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
platform console serial
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
!
!
!
!
!
!
!
no login on-success log
!
!
!
!
!
!
!
subscriber templating
!
!
!
!
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
crypto pki trustpoint TP-self-signed-194500863
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-194500863
revocation-check none
rsakeypair TP-self-signed-194500863
!
!
crypto pki certificate chain TP-self-signed-194500863
!
!
!
!
!
!
!
!
!
license udi pid CSR1000V sn 91J22CWGWPT
diagnostic bootup level minimal
spanning-tree extend system-id
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback101
ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet1
ip unnumbered Loopback101
negotiation auto
medium p2p
no mop enabled
no mop sysid
!
interface GigabitEthernet2
ip unnumbered Loopback101
negotiation auto
medium p2p
no mop enabled
no mop sysid
!
interface GigabitEthernet3
no ip address
shutdown
negotiation auto
no mop enabled
no mop sysid
!
interface GigabitEthernet4
no ip address
shutdown
negotiation auto
no mop enabled
no mop sysid
!
router ospf 100
router-id 1.1.1.1
network 0.0.0.0 255.255.255.255 area 0
!
!
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
!
!
!
!
!
!
control-plane
!
!
!
!
!
!
line con 0
stopbits 1
line vty 0 4
login
!
!
!
!
!
!
end

 

I'm not sure from what router you wanted the debugs enabled, so below is R3 which is sourcing the traceroute to 2.2.2.2, as well as R2 which is the destination. I am attempting to traceroute from R3->R1->R2. Topology picuture attached for reference if needed.

 

R3#debug ip packet
IP packet debugging is on
R3#
*Apr 16 14:57:23.040: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast
R3#trace 2.2.2.2
Type escape sequence to abort.
Tracing the route to
*Apr 16 14:57:32.494: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast
*Apr 16 14:57:34.346: IP: s=3.3.3.3 (local), d=255.255.255.255 (GigabitEthernet2), len 77, sending broad/multicast
*Apr 16 14:57:34.347: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending broad/multicast
*Apr 16 14:57:34.348: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending full packet
*Apr 16 14:57:34.350: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, input feature, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Apr 16 14:57:34.351: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, unroutable
*Apr 16 14:57:38.352: IP: s=3.3.3.3 (local), d=255.255.255.255 (GigabitEthernet2), len 77, sending broad/multicast
*Apr 16 14:57:38.356: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending broad/multicast
*Apr 16 14:57:38.358: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending full packet
*Apr 16 14:57:38.360: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, input feature, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Apr 16 14:57:38.362: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, unroutable2.2.2.2
VRF info: (vrf in name/id, vrf out name/id)
1
*Apr 16 14:57:41.694: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast
*Apr 16 14:57:42.367: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:57:42.367: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending
*Apr 16 14:57:42.385: IP: s=3.3.3.3 (local), d=255.255.255.255 (GigabitEthernet2), len 77, sending broad/multicast
*Apr 16 14:57:42.388: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending broad/multicast
*Apr 16 14:57:42.389: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending full packet
*Apr 16 14:57:42.390: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, input feature, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Apr 16 14:57:42.391: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, unroutable
*Apr 16 14:57:46.391: IP: s=3.3.3.3 (local), d=255.255.255.255 (GigabitEthernet2), len 77, sending broad/multicast
*Apr 16 14:57:46.394: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending broad/multicast
*Apr 16 14:57:46.395: IP: s=3.3.3.3 (local), d=255.255.255.255 (Loopback101), len 77, sending full packet
*Apr 16 14:57:46.396: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, input feature, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE
*Apr 16 14:57:46.397: IP: s=3.3.3.3 (Loopback101), d=255.255.255.255 (nil), len 77, unroutable1.1.1.1 6 msec 5 msec 6 msec
2
*Apr 16 14:57:50.401: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:57:50.401: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending
*Apr 16 14:57:50.408: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:57:50.408: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending
*Apr 16 14:57:50.416: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:57:50.416: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending
*Apr 16 14:57:51.412: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast *
*Apr 16 14:57:53.422: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:57:53.422: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending *
*Apr 16 14:57:56.436: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:57:56.437: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending *
3
*Apr 16 14:57:59.441: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:57:59.441: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending
*Apr 16 14:58:00.422: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast *
*Apr 16 14:58:02.456: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:58:02.457: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending *
*Apr 16 14:58:05.464: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:58:05.464: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending *
4
R3#
*Apr 16 14:58:08.465: IP: tableid=0, s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2) nexthop=2.2.2.2, routed via FIB
*Apr 16 14:58:08.465: IP: s=3.3.3.3 (local), d=2.2.2.2 (GigabitEthernet2), len 28, sending
*Apr 16 14:58:10.288: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast
*Apr 16 14:58:19.336: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast
R3#
*Apr 16 14:58:29.181: IP: s=3.3.3.3 (local), d=224.0.0.5 (GigabitEthernet2), len 100, sending broad/multicast

u all
All possible debugging has been turned off

 

R2#
*Apr 16 14:57:31.012: IP: s=2.2.2.2 (local), d=224.0.0.5 (GigabitEthernet1), len 100, sending broad/multicast
*Apr 16 14:57:40.230: IP: s=2.2.2.2 (local), d=224.0.0.5 (GigabitEthernet1), len 100, sending broad/multicast
*Apr 16 14:57:49.638: IP: s=2.2.2.2 (local), d=224.0.0.5 (GigabitEthernet1), len 100, sending broad/multicast
*Apr 16 14:57:50.346: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 16 14:57:53.353: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 16 14:57:56.366: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 16 14:57:58.969: IP: s=2.2.2.2 (local), d=224.0.0.5 (GigabitEthernet1), len 100, sending broad/multicast
*Apr 16 14:57:59.370: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 16 14:58:02.391: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 16 14:58:05.393: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 16 14:58:08.285: IP: s=2.2.2.2 (local), d=224.0.0.5 (GigabitEthernet1), len 100, sending broad/multicast
*Apr 16 14:58:08.395: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 16 14:58:17.866: IP: s=2.2.2.2 (local), d=224.0.0.5 (GigabitEthernet1), len 100, sending broad/multicast

u all
All possible debugging has been turned off
R2#

 

 

Highlighted

Thank you for the output. Would you post the output of these commands from each of the routers.

show ip route

show arp

HTH

Rick
Highlighted

Of course:

 

R2#show ip route | b Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 1.1.1.1, 00:35:03, GigabitEthernet1
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback101
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/3] via 1.1.1.1, 00:34:39, GigabitEthernet1
R2#
R2#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 2.2.2.2 - 0c2a.d7ff.d000 ARPA GigabitEthernet1

 

R1#show ip route | b Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback101
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 2.2.2.2, 00:35:39, GigabitEthernet1
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 3.3.3.3, 00:35:21, GigabitEthernet2
R1#
R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 1.1.1.1 - 0c2a.d796.5a00 ARPA GigabitEthernet1
Internet 1.1.1.1 - 0c2a.d796.5a01 ARPA GigabitEthernet2

R3#show ip route | b Gate
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 1.1.1.1, 00:36:11, GigabitEthernet2
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/3] via 1.1.1.1, 00:36:11, GigabitEthernet2
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback101
R3#
R3#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 3.3.3.3 - 0c2a.d779.0801 ARPA GigabitEthernet2

 

 

 

 

Highlighted

Thanks for the outputs. In the results I find some good news and some puzzling things.

Among the good news is:

- the routers have formed OSPF neighbor relationships and have learned prefixes on the other routers.

- so the routers do have appropriate forwarding logic for each of the IP addresses used in the network.

Among the puzzling things is:

- since the neighbor router IP address is in a different subnet I am surprised that they are able to form neighbor relationships. I assume that the explanation for this is based on behaviors of ip unnumbered.

- each router arp table has entries for its own IP but no entry for either of the neighbors. In thinking about it I realize that none of the other routers would arp for the neighbor address (because you do not arp for addresses that are in remote networks, only arp for local addresses). And if one of these routers did receive an arp request or an arp response from a neighbor it would reject the packet with an error of wrong wire.

- for many of us for whom arp on Ethernet is an article of faith it is quite remarkable that the routers are able to communicate with neighbors with no arp. I assume that the explanation for this is related to the medium p2p configuration.

- ping is successful but traceroute fails. Obviously when R3 pings R2 then R2 sends a response. But the output of debug shows pretty clearly that R2 receives the traceroute packet from R3 but does not send a response. In looking at the debug output I notice this

*Apr 16 14:58:08.395: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB

I am a bit puzzled about the next hop=2.2.2.2. And I am puzzled that there does not seem to be any recognition that R2 is the destination. But clearly R2 is not sending the expected response.

 

Perhaps it has something to do with the behavior of IP unnumbered. But I do not think so. I have used IP unnumbered many time (in the long ago past) and do not remember issues about traceroute. Perhaps it has something to do with the behavior of medium p2p? Or perhaps this is just one of the strange things we find when we use emulators like GNS3.

HTH

Rick
Highlighted

Thanks so much for your thorough explanation and taking the time to go through this issue.

 

Regarding the OSPF adjacency forming via different subnets - you are correct in assuming that is related to the ip unnumbered feature. If you're interested, RFC 5309 goes into detail about stating that the check for the subnet of the source address of the ARP request matching the local interface address, needs to be relaxed for ip unnumbered interfaces (section 4.3). This isn't limited for just /32 either. You could use 192.168.1.1/24 on R1's loopback, and 172.16.1.1/16 on R3's loopback - and as long you're using ip unnumbered on the interfaces facing each other - the OSPF adjacency will still form.

 

It is very interesting that R2 is acting as if it is not the destination. I think you're right in assuming it could be something to do with the medium p2p command, or even just the emulation within GNS3.

 

Thanks!

 

 

Highlighted

I had another thought about this and ask if you would post the output of the command show ip interface for the Ethernet and Loopback interfaces on R2?

HTH

Rick
Highlighted

Sure:

 

R2#show ip int g1
GigabitEthernet1 is up, line protocol is up
Interface is unnumbered. Using address of Loopback101 (2.2.2.2)
Broadcast address is 255.255.255.255
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.5
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP Null turbo vector
Associated unicast routing topologies:
Topology "base", operation state is UP
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
Input features: MCI Check
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled

 

R2#show int lo101
Loopback101 is up, line protocol is up
Hardware is Loopback
Internet address is 2.2.2.2/32
MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation LOOPBACK, loopback not set
Keepalive set (10 sec)
Last input 00:02:10, output never, 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
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
10 packets output, 600 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out

 

One other thing worth mentioning. I enabled debug ip packet detail, and I see the following on R2:

*Apr 17 15:23:40.028: FIBipv4-packet-proc: route packet from GigabitEthernet1 src 3.3.3.3 dst 2.2.2.2
*Apr 17 15:23:40.029: FIBfwd-proc: Default:2.2.2.2/32 receive entry
*Apr 17 15:23:40.030: FIBipv4-packet-proc: packet routing failed
*Apr 17 15:23:40.030: IP: tableid=0, s=3.3.3.3 (GigabitEthernet1), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB

 

So for some reason which I can't figure out, the FIB fails when trying to route the packet to the local 2.2.2.2 address. There's clearly a receive entry:

 

R2#show ip cef 2.2.2.2/32 detail
2.2.2.2/32, epoch 2, flags [attached, connected, receive, local, source eligible]
Interface source: Loopback101 flags: local, source eligible flags3: none
receive for Loopback101

 

Interestingly enough, if I was to traceroute to the local 2.2.2.2 address from R2, I see the same FIB packet routing failure, but it sends the ICMP type 3:

*Apr 17 15:27:03.223: FIBipv4-packet-proc: route packet from (local) src 2.2.2.2 dst 2.2.2.2
*Apr 17 15:27:03.224: FIBfwd-proc: Default:2.2.2.2/32 receive entry
*Apr 17 15:27:03.225: FIBipv4-packet-proc: packet routing failed
*Apr 17 15:27:03.225: IP: tableid=0, s=2.2.2.2 (local), d=2.2.2.2 (Loopback101) nexthop=2.2.2.2, routed via RIB
*Apr 17 15:27:03.226: IP: s=2.2.2.2 (local), d=2.2.2.2 (Loopback101), len 56, sending
*Apr 17 15:27:03.227: ICMP type=3, code=3

Highlighted

Thanks for the output. I have been wondering about why ping is successful between the switches but traceroute fails. One possibility that occurred to me was that perhaps ip unreachable had been disabled on the interfaces. But the output from the Ethernet clearly shows this

ICMP unreachables are always sent

We can not be sure about the loopback interface because you did show interface rather that show ip interface. But I would think that the Ethernet interface would be the critical one for this since it is where the packet would be received and would be used to send the unreachable.

 

The debug output is very interesting. I had hoped to see something like this the first time that you ran debug.

FIBipv4-packet-proc: packet routing failed

I wonder if there is a similar message when R3 is trying to ping R2.

HTH

Rick
Highlighted

Sorry about that. Show IP int lo101 is below:

 

R2#show ip int lo101
Loopback101 is up, line protocol is up
Internet address is 2.2.2.2/32
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1514 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.5
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP Null turbo vector
Associated unicast routing topologies:
Topology "base", operation state is UP
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
Input features: MCI Check
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled

 

I am not seeing anything when I enable "debug ip packet detail" on R2 and ping from R3 to R2. On R2, I have also enabled "debug ip cef drops detail", "debug ip cef events", "debug ip cef local", debug ip cef packet gigabitEthernet 1 input/output rate 0, debug ip cef packet loopback101 input/output rate 0, "debug ip cef receive detail", "debug ip cef redirect". Still nothing for pings from R3->R2, as well as traceroute.



Highlighted

Thanks for the output for the loopback interface. As I expected it shows that unreachables are not disabled. I am surprised at the lack of debug output, especially if the ping is successful. At this point I believe that it is likely that you are encountering some flaw in the emulator.

HTH

Rick