SLA failure because certain IP addresses cannot be reached by ping

[LuigiDiFronzo9542]

We have a FTD managed by FMC.

For some reason it's nos possible to ping the address 8.8.8.8 and 1.1.1.1 for example. But if we ping the address 8.8.4.4, it responds to the ping.

We have a default static route to the internet provider, but when entering the command 'show route  8.8.8.8' or 'show route 1.1.1.1'  or 'show route 8.8.4.4', always get the answer '% Network not in table'.

However for internal networks the 'show route' command display the correct gateways.

Any ideas.

[MHM Cisco World]

Can I see show route 

MHM

[LuigiDiFronzo9542]

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
SI - Static InterVRF, BI - BGP InterVRF
Gateway of last resort is 10.232.255.11 to network 0.0.0.0

S* 0.0.0.0 0.0.0.0 [1/0] via 10.232.255.11, outside
S 10.63.0.0 255.255.0.0 [1/0] via 10.232.60.2, DMZ60
S 10.64.0.0 255.255.0.0 [1/0] via 10.232.60.2, DMZ60
S 10.170.2.0 255.255.255.128 [1/0] via 10.232.255.11, outside
S 10.232.0.0 255.255.0.0 [1/0] via 10.232.240.1, inside
S 10.232.0.20 255.255.255.252 [1/0] via 10.232.60.2, DMZ60
S 10.232.0.24 255.255.255.252 [1/0] via 10.232.60.2, DMZ60
D 10.232.14.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.15.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.20.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
C 10.232.22.0 255.255.255.252 is directly connected, Failover_Link
L 10.232.22.1 255.255.255.255 is directly connected, Failover_Link
C 10.232.22.4 255.255.255.252 is directly connected, State_Link
L 10.232.22.5 255.255.255.255 is directly connected, State_Link
D 10.232.30.0 255.255.255.192 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.40.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
S 10.232.40.8 255.255.255.255 [1/0] via 10.232.60.2, DMZ60
D 10.232.41.33 255.255.255.255
[90/195072] via 10.232.255.5, 12:12:17, inside
C 10.232.50.0 255.255.255.192 is directly connected, DMZ50
L 10.232.50.1 255.255.255.255 is directly connected, DMZ50
C 10.232.60.0 255.255.255.240 is directly connected, DMZ60
L 10.232.60.1 255.255.255.255 is directly connected, DMZ60
D 10.232.90.0 255.255.255.192
[90/25600512] via 10.232.255.5, 7w0d, inside
D 10.232.114.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.115.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.200.0 255.255.255.240 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.210.0 255.255.255.240 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.220.0 255.255.255.240 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.221.0 255.255.255.240 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.240.0 255.255.255.252 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.245.0 255.255.255.240 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.247.0 255.255.255.192 [90/3072] via 10.232.255.5, 7w0d, inside
V 10.232.249.22 255.255.255.255 connected by VPN (advertised), outside
V 10.232.249.175 255.255.255.255 connected by VPN (advertised), outside
V 10.232.249.176 255.255.255.255 connected by VPN (advertised), outside
V 10.232.249.177 255.255.255.255 connected by VPN (advertised), outside
V 10.232.249.178 255.255.255.255 connected by VPN (advertised), outside
V 10.232.249.179 255.255.255.255 connected by VPN (advertised), outside
V 10.232.249.180 255.255.255.255 connected by VPN (advertised), outside
D 10.232.251.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.252.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.253.0 255.255.255.0 [90/3072] via 10.232.255.5, 7w0d, inside
D 10.232.254.0 255.255.255.240 [90/3072] via 10.232.255.5, 7w0d, inside
C 10.232.255.0 255.255.255.248 is directly connected, inside
L 10.232.255.6 255.255.255.255 is directly connected, inside
C 10.232.255.8 255.255.255.248 is directly connected, outside
L 10.232.255.9 255.255.255.255 is directly connected, outside
D 10.234.0.28 255.255.255.252
[90/284672] via 10.232.255.5, 12:12:17, inside
D 10.234.81.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.234.181.0 255.255.255.128
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.234.210.0 255.255.255.128
[90/67584] via 10.232.255.5, 12:12:17, inside
S 10.240.0.0 255.255.0.0 [1/0] via 10.232.240.1, inside
D 10.240.0.0 255.255.255.252
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.1.0 255.255.255.128
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.1.128 255.255.255.128
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.2.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.3.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.5.0 255.255.255.192
[90/67328] via 10.232.255.5, 12:12:17, inside
D 10.240.20.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.40.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.41.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.42.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.43.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.44.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.45.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.46.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.47.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.48.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.50.0 255.255.254.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.60.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.61.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.66.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.67.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.72.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.73.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.78.0 255.255.255.128
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.78.128 255.255.255.128
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.80.0 255.255.255.240
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.80.16 255.255.255.240
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.81.16 255.255.255.240
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.82.0 255.255.255.240
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.82.16 255.255.255.240
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.83.0 255.255.255.224
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.83.32 255.255.255.240
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.84.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
D 10.240.247.0 255.255.255.0
[90/67584] via 10.232.255.5, 12:12:17, inside
V 10.250.0.0 255.255.0.0 connected by VPN (advertised), PRUEBA_ROUTER
S 10.250.20.0 255.255.255.0 [1/0] via 190.216.233.1, PRUEBA_ROUTER
S 97.65.232.134 255.255.255.255 [1/0] via 190.216.233.1, PRUEBA_ROUTER
S 104.106.235.41 255.255.255.255 [1/0] via 190.216.233.1, PRUEBA_ROUTER
S 172.18.86.0 255.255.255.0 [1/0] via 10.232.60.2, DMZ60
S 184.31.70.16 255.255.255.255 [1/0] via 190.216.233.1, PRUEBA_ROUTER
S 184.31.176.180 255.255.255.255 [1/0] via 190.216.233.1, PRUEBA_ROUTER
C 186.167.7.176 255.255.255.248 is directly connected, digitel
L 186.167.7.179 255.255.255.255 is directly connected, digitel
C 190.216.233.0 255.255.255.224 is directly connected, PRUEBA_ROUTER
L 190.216.233.17 255.255.255.255 is directly connected, PRUEBA_ROUTER
D 192.168.2.0 255.255.255.252 [90/67072] via 10.232.255.5, 7w0d, inside
D 192.168.3.1 255.255.255.255
[90/131072] via 10.232.255.5, 7w0d, inside
D 192.168.3.2 255.255.255.255
[90/195072] via 10.232.255.5, 12:12:17, inside
D 192.168.18.0 255.255.255.0
[90/67840] via 10.232.255.5, 12:12:17, inside
D 192.168.60.0 255.255.255.0
[90/67840] via 10.232.255.5, 12:12:17, inside
S 194.247.235.241 255.255.255.255
[1/0] via 190.216.233.1, PRUEBA_ROUTER
S 207.218.87.194 255.255.255.255 [1/0] via 190.216.233.1, PRUEBA_ROUTER
S 209.130.193.34 255.255.255.255 [1/0] via 190.216.233.1, PRUEBA_ROUTER

[MHM Cisco World]

there is 0.0.0.0 
so it seem show route 8.8.8.8 not work as we want in FTD like it work in other IOS device

why ping to 8.8.8.8 failed and ping to 8.8.4.4 success ?

check in fmc platform setting check in icmp if you allow ANY or 8.8.4.4

MHM 

[LuigiDiFronzo9542]

Thanks MHM,

Yes, the ping is permitted to Any, in fact we had a SLA monitor doing ping to 1.1.1.1 address but failed this morning because the unsucesfull ping. 

[MHM Cisco World]

S* 0.0.0.0 0.0.0.0 [1/0] via 10.232.255.11, outside

C 10.232.255.8 255.255.255.248 is directly connected, outside
L 10.232.255.9 255.255.255.255 is directly connected, outside

FTD is connect to router and router connect to ISP? Check if somehow one engineer add ACL in router deny 8.8.8.8

MHM

[ccieexpert]

can you run packet tracer with "trace detail" option and show the output for that

[ccieexpert]

couple of things as i already suggested:

1) is ping from the inside to outside for 8.8.8.8 working fine through the box ?

2) do packet trace from the box packet-tracer input inside icmp <inside host> 0 0 8.8.8.8

3) show asp table routing

4) try to put host route /32 for the 8.8.8.8 to point to default gateway..

BTW show route <network> doesnt work unless there is a exact match.

try

sh route 8.8.8.8 longer-prefixes

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
SI - Static InterVRF, BI - BGP InterVRF
Gateway of last resort is 192.168.254.254 to network 0.0.0.0

hope this helps..

[Marius Gunnerud]

The output that the Network is not in the routing table is expected. this just means that the default route will be used.

show route 8.8.8.8

% Network not in table

can you run a packet tracer for this traffic and post the output here.  This issue can be that there is an access list blocking the issue, security intelligence blocking the traffic for some reason, or that the ISP is dropping the traffic (though this is not very likely).

in addition to packet tracer do a packet capture on the inside interface and then run a connection test and post the output here.

[LuigiDiFronzo9542]

Executing a traceroute from the FTD on both IP address, you can see the diferent results.

For the one working this is the trace:

For the IP address that doesn´t respond this is the trace:

It seems like an external block for that IP adddress.

Regards.

[MHM Cisco World]

Traceroute different than ping so you cant depend on it 

As I mentioned above ftd connect to edge router from this router try ping 8.8.8.8 and check ACL on it

MHM

[LuigiDiFronzo9542]

Thank you for your response.

The FTD has a switch above it that is then connected to a balancing device that connects with the ISPs. We don't have direct access to the switch but from the balancing device there is a ping response for both addresses. According your indication, the blocking could be due to an ACL on the switch?

[MHM Cisco World]

ACL or NAT with balance issue. Check this point

MHM

[Marius Gunnerud]

Based on the traceroute you provided the issue is from 142.250.47.74, so either a routing issue on the device containing this subnet or a firewall at the next hop after this.

[ccieexpert]

Ciao friends

I will give you my analysis based on the traceroute.

First based on the traceroute nothing is blocked by upstream switch/router as the traceroute packet will have the same destination 8.8.8.8.. It is dropped by last hop 8.8.8.8 and the path seems to be the same..

Most likely something is happening on the last hop-maybe a blacklist of your ip or a problem with load balancer.. It is very clear with traceroute the last hop is not responding...It is ofcourse possible that there is a inbound ACL block on the upstream router for anything sourced from 8.8.8.8 - that is a possibility.

One way to for sure verify that the upstream first hop is not dropping is to do a ping with TTL of 6 hops from a inside windows or linux host where you can set the the TTL- If you get a TTL expired in transit on the the ping command, then that shows that it is not blocked by upstream device(first hope):

C:\Users\thoma>ping -i 6 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 45.52.201.115: TTL expired in transit.
Reply from 45.52.201.115: TTL expired in transit.

In this case the 45.52.201.115 is the 6th hop in traceroute also.. so just to confirm ...

Hope that helps friends