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.

[LuigiDiFronzo9542]

Hello this is the test.

So according your comments the blocking could be in this case at the last hop (142.250.47.74, according the trace a Google address). In this case what could be the reason for this behavior?

Thanks.

[ccieexpert]

potential reason is they have blacklisted your ip or something else ...have you checked if your public ip is not blacklisted.... maybe contact google ??  do you have more than 1 public ip ? maybe try another public IP to see is the issues with blacklist.. did you by any chance send too much traffic (pings or other) to them ?

[Marius Gunnerud]

The issue is with whatever is after 142.250.47.74.  If the issue was at this IP we would not see the IP.  My guess is that after this IP there are at least two different paths to the destination and on one, or more of these paths there is either a routing issue for the return traffic or there is a firewall blocking for ping / traceroute.

I highly doubt that this is a blacklist issue as the drops would be more consistent.

[LuigiDiFronzo9542]

Yes, we have two Public IP addresses and searching in Cisco Talos they don't look suspicious.

Right now the ping 8.8.8.8 is working again but the 1.1.1.1 not yet.

Thanks all for your suggestions.

[ccieexpert · Accepted solution]

ok based on the suggestion with ping -i etc will help you and traceroutes.. but the problem seems elsewhere..

I think we have given enough ways to troubleshoot this

**Please rate as helpful if this was useful **

[MHM Cisco World]

It will appear again 

If the edge router connect to ftd have two ISP check NAT and ACL as I mention before.

MHM

[LuigiDiFronzo9542]

Hello MHM,

Thanks for your comments.

The FTD is connected to a balancing device whose function is to perform NAT for outgoing Internet traffic, as well as publish some services and balance traffic between two ISP's. What should be checked in the NAT?

Thanks.

[MHM Cisco World]

Friend when you ping from PC the ping success when ftd try to ping same IP 8.8.8.8 it failed 

The ip sla use source IP (you can see it in capture) 

Again check the edge router NAT entry see if FTD IP SLA IP have NAT and use correct ISP or not that it.

Your issue is not eleswhere it in edge router friend.

MHM

[ccieexpert]

just force the traffic to go over one ISP as a test and verify and switch to other ISP as a test and again compare the results... but based on the tracreoute the problem is on the last hop for sure...:)

[MHM Cisco World]

Friend

Again dont use traceroute to check some hop in internet' ISP reject to send ttl exceeded icmp for traceroute and hence it give false troubleshooting.

Use traceroute in internal network only.

I hope you get idea here

MHM

[ccieexpert]

friend - if traceroute fails everytime i can agree with you....  it looks like you are only using traceoute for inside inside traceroute is almost never needed... the traceroute is used heavily on the internet... if its blocked, then it will be blocked but 8.8.8.8 is never blocked

the load balancing device will generally not block 8.8.8.8.. most likely there one of the public ip is blacklisted

[MHM Cisco World]

it looks like you are only using traceoute for inside inside traceroute is almost never needed <<- because we are admin of all network (internal) and allow icmp ttl exceed we are all use traceroute to see route patg between two point.

Do you think that ISP router allow icmp exceed send from there high duty platform? Really I dont think so 

If yoh admin of ASA connect to ISP do you allow ASA to reply to traceroute?

MHM

[ccieexpert]

Most ISPs generally allow traceroute .. Traceroute are rate limited to avoid a DDOS for each traceroute 3 packets are sent, and if all are dropped multiple times, then its generally a indication of a block .. 8.8.8.8 is always been allowed in my experience....

There is nothing wrong with allowing tracroute through the firewall.. traceroute is a very important troubleshooting tool and is good to enable it through the firewall.

Anyway i have suggested to temporarily shutdown one ISP(and then other) for testing, that will prove if it is a ISP issue.. traceroute shows that the ISP is not blocking ..