Debug IP Packet Detail

[dcanady55]

Hello,

I have a device on my LAN that I can ping from the switch and ping from the router sourced from that subnets interface. I cannot ping the device sourced from the WAN interface. I did a debug IP packet detail and it returned the following.

WAN Interface 10.171.251.66

Device 10.73.66.80

On the router I can ping sourced from GigabitEthernet0/0/0.73 to 10.73.66.80 but not when I source from 10.171.251.66

IP: tableid=0, s=10.171.251.66 (local), d=10.73.66.80 (GigabitEthernet0/0/0.73), routed via FIB
IP: s=10.171.251.66 (local), d=10.73.66.80 (GigabitEthernet0/0/0.73), len 100, sending
ICMP type=8, code=0
IP: s=10.171.251.66 (local), d=10.73.66.80 (GigabitEthernet0/0/0.73), len 100, output feature
ICMP type=8, code=0, feature skipped, Access List(52), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

I'm not entirely sure if the Access List (52) is supposed to be the ACL's sequence number?  I don't have any ACLs with a sequence number of 52. I removed the access list on the interface 0/0/0.73 and it made no difference. I checked the CEF table and the device I'm trying to reach is there. I can ping other devices on that same lan 10.73.66.0/24 sourcing it from my interface 10.171.251.66.

thanks for any help

[Giuseppe Larosa]

Hello @dcanady55 ,

>> I can ping other devices on that same lan 10.73.66.0/24 sourcing it from my interface 10.171.251.66.

without entering the details of the debug output the fact that other hosts are able to answer to ICMP echo requests when the source is 10.171.251.66 means that the issue is likely on the device with IP address 10.73.66.80 that :

a) may be missing a default gateway

or

b) has a wrong default gateway and it is sending the echo replies to some other device that has no knowledge of subnet 10.171.251.0

Hope to help

Giuseppe

[dcanady55]

Hi Giuseppe,

That was my initial thought as this device is a third party device. I asked the tech to verify the gateway and it is 10.73.66.1. He also verified he could ping outside of the LAN to 8.8.8.8. I asked him if there was anything else on that device that could be blocking ICMP and he said no. I'm not sure where else to look at my end. You mention debug output. In my original post I entered the only section of the debug I found related to my ping when I sourced it from 10.171.251.66. The access list 52 comment peaks my interest as I don't know what that's referring to.

[dcanady55]

I'm going to SPAN the switchport and if I can see my pings make it to the machine and nothing gets returned I would say something is up with the device blocking ICMP.

[Giuseppe Larosa]

Hello @dcanady55 ,

if we look at the debug output lines we see the following:

>> IP: s=10.171.251.66 (local), d=10.73.66.80 (GigabitEthernet0/0/0.73), len 100, sending
ICMP type=8, code=0
IP: s=10.171.251.66 (local), d=10.73.66.80 (GigabitEthernet0/0/0.73), len 100, output feature
ICMP type=8, code=0, feature skipped, Access List(52), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

Now, because the packet is locally generated on the router itself it cannot be stopped by an outbound ACL applied to interface gi0/0/0/.73. An outbound ACL does not drop locally generated packets even if they do not match a permit statement.

I don't think the 52 has any special meaning here (it can be a way to say outgoing ACL applied)

I think that the sentence "feature skipped , Access List (52) " should simply mean this : a locally generated packet skips an outbound ACL on the exit interface.

>> this device is a third party device. I asked the tech to verify the gateway and it is 10.73.66.1.

Note that if this third party device and has more then one NIC it can have more specific static routes for subnet 10.171.251.0 going out another NIC, so I would ask to the people managing the device about this.

Hope to help

Giuseppe

[dcanady55]

Thanks for the info Giuseppe.

I managed to SPAN the port and did in fact see 5 ping request sourced from 10.171.251.66 to 10.73.66.80 and no response was found. I take that to mean something on the machine itself is preventing the return traffic or sending it out another NIC to unknown gateway. It cannot be blocking ICMP all together since I can ping it from the switch.

[Giuseppe Larosa · Accepted solution]

Hello @dcanady55 ,

>> managed to SPAN the port and did in fact see 5 ping request sourced from 10.171.251.66 to 10.73.66.80 and no response was found. I take that to mean something on the machine itself is preventing the return traffic or sending it out another NIC to unknown gateway. It cannot be blocking ICMP all together since I can ping it from the switch.

Yes I agree with your considerations

Hope to help

Giuseppe