Trace Route !N !N !N

[Harmeet Singh]

Hi,

I have two firewall. A subnet 172.30.1.0/24 is hosted at inside interface on FW 1. When I am trying to ping from FW 2 to a host 172.30.1.127 (Hosted on FW 1 inside), it is getting ping but when I am trying to ping 172.30.1.126 it is not getting ping. I have checked all the ACL and there is no specific configuration for 172.30.1.126.

Trace Route from FW 2:-

MPLS-FW-01# traceroute 172.30.1.126

Type escape sequence to abort.

Tracing the route to 172.30.1.126

 1  10.3.133.2 0 msec 0 msec 0 msec

 2  172.30.91.8 0 msec 0 msec 0 msec

 3  172.30.91.8 10 msec 0 msec 0 msec

 4  172.30.36.131 !N  !N  !N

MPLS-FW-01# traceroute 172.30.1.127

Type escape sequence to abort.

Tracing the route to 172.30.1.127

 1  10.3.133.2 10 msec 0 msec 0 msec

 2  172.30.91.8 0 msec 0 msec 10 msec

 3  172.30.91.8 0 msec 0 msec 0 msec

 4  172.30.1.127 10 msec 10 msec 10 msec

What is the meaning of !N !N !N in Trace Route.

Attached file is a diagram for reference.

Thanks

Harmeet

[Dinesh Moudgil]

Hi Harmeet,

"!N" means "network unreachable.
Ref: http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12778-ping-traceroute.html#traceroute

This means that FW1 is sending you network unreachable message for 172.30.1.126.

Can you run a packet capture on egress and ingress interface on FW1 to see packets are coming in and going out properly.

Commands:
capture capi interface <interface connected to FW2> match icmp host <FW2_SourceIP> host 172.30.1.126

capture capo interface <interface connected to host_172.30.1.126> match icmp host <FW2_SourceIP> host 172.30.1.126

cap asp type asp-drop all
This command will show you if packets are getting dropped on the ASA

you can check the packet captures via

show cap capi
show cap capo
show cap asp | in 172.30.1.126

To remove the captures:

no cap capi

no cap capo

no cap asp

Also check if icmp inspection is enabled.

Regards,
Dinesh Moudgil

P.S. Please rate helpful posts.

[Harmeet Singh]

Hi Dinesh,

Thanks for reply.

There is a limitation here. We have asa module "WS-SVC-FWM-1" installed in "WS-C6509-E" and there is no capture command.

Can you confirm what is happening here:

When we are trying to ping from FW2 to 172.30.1.125 (This IP is not live/not in production) we are getting  * * * * in traceroute. When we are trying to ping from FW2 to 172.30.1.126 (This IP is live/in production) we are getting  172.30.36.131 !N  !N  !N. What is the difference between these two outcome. 172.30.36.131 is outside interface IP of FW1. Why the firewall interface IP is showing in traceroute.

Regards,

Harmeet

[Andrii Oliinyk]

Hi Harmeet

surprisingly i've found yours the same Q in learningnetwork timestamped with 2020 of Feb or smthng like this. so just in case if u r still on the same point...

i'm not big expert in FWSM, but there r some observations which can give u a clue:

1) according to to diagram your FW1 inside has IP 172.30.36.131, meaning that in case of traceroute to 172.30.1.126 from FW2 u receive ICMP NetUn from the FW (for whatever reason including simplest of subnet is not in routing table of FW1 if latter doesnt have a default route :0)

2) but when u traceroute to 172.30.1.127 there is no ICMP TTLexp from FW1. instead u have it from penultimate host with IP 172.30.91.8 (which is pre-penultimate hop in case of traceroute to 172.30.1.126), & then ICMP PortUn from  172.30.1.127 itself.

this makes me to think that on 172.30.91.8 u have some PBR which is forwarding traffic destined to 172.30.1.126 via 172.30.36.131 (FW1==FWSM) while in case of 172.30.1.127 traffic follows regular routing & terminates somewhere on the subnet attached to device with IP 172.30.91.8 (i assume it's your C6K which is hosting FWSM). i'd start in this case with very basic connectivity tests/diagnosis (MAC, ARP-tables inspections on the C6K & FWSM, other traceroutes like to 172.30.1.1)