Keep getting D/C symbol

[Raist]

It means there is a strong chance the node is indeed overly congested...which could be part of your instability--and something they can address. THAT is what the tracert is for...to help identify potential points of instability in the route. Without being able to see how consistently or inconsistently it manages traffic at that hop, we have no way to test that theory. Notice they are ONLY dropping ICMP at that one particular hop---it isn't a rule across all nodes, just that one spot. What makes that one hop so special?

Follow the link to that mea culpa blog post. The scenario is near identical to what you are describing--everything appears just fine on either end of the network, but somewhere along the path things are breaking down. In that scenario, there is one exchange point that is running 100% utilization on 4 of 4 port cards--meaning it is at full capacity and going into congestive failure (discarding packets). It could be easily remedied (or at least dramatically diminished) by adding one or more additional port cards. One 10Gbit port card would increase the bandwidth available by 25%, and have a profound impact on the congestion between the client and the content server--but Verizon was unwilling to do the upgrade.

What you are being told is all is good on their end, and all is good on SE's end---but there is one point in between them that you can't verify if that is true or not. You are left with taking their word for it that everything is fine at that point in the route. BUT... and it is a very big one at that---they admitted that the "router you were pinging was too busy" and was thus ignoring the ICMP ECHO request. That is a rule that is often enforced specifically to help stave off high levels of congestion. That rep basically just told you the node is indeed congested or at least is prone to frequently high enough utilization for it to be on full time. Would be interesting to see if it actually responds during off-peak times...if it does, then you have a clear indication that it is getting overloaded periodically and that needs to be addressed.

Try running a pathping instead of a tracert (it will take a while to run). At the very start of the process, it will give a list of the route's IP addresses. If you actually get an IP for that hop in that list, you might be able to ping it directly to see how it is behaving. The default results are for 4 pings. If it does in fact respond to normal pings, you can use the -n switch to tell it how many times to ping to see a larger sample, like this:

ping -n 25 199.91.189.74

That would ping the neo2lobby.ffxiv.com service 25 times. Note you can use either the DNS name or the IP address for that command.

A pathping report may also show signs of issues in forwarding as well. If it indeed demonstrates problems exist with that function of the routers along the route, then you have signs of smoke and they need to be checking for the fire.

Just for comparison's sake, here is my current tracert (they just changed me back to TATA again, so I'm going through Raleigh/Durham and Toronto again.. bleh). Notice how not ONE of my hops is set to ignore ICMP--because utilization has more or less been brought into check now:

Tracing route to neolobby02.ffxiv.com [199.91.189.74]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  LPTSRV [10.10.100.1]
  2    32 ms    31 ms    38 ms  cpe-75-176-160-1.sc.res.rr.com [75.176.160.1]
  3    26 ms    22 ms    31 ms  cpe-024-031-198-005.sc.res.rr.com [24.31.198.5]
  4    13 ms    11 ms    13 ms  clmasoutheastmyr-rtr2.sc.rr.com [24.31.196.210]
  5    28 ms    26 ms    25 ms  be33.drhmncev01r.southeast.rr.com [24.93.64.180]
  6    35 ms    29 ms    34 ms  bu-ether35.asbnva1611w-bcr00.tbone.rr.com [107.14.19.42]
  7    32 ms    29 ms    32 ms  0.ae2.pr1.dca10.tbone.rr.com [107.14.17.204]
  8    31 ms    31 ms    32 ms  ix-17-0.tcore2.AEQ-Ashburn.as6453.net [216.6.87.149]
  9    51 ms    54 ms    54 ms  if-2-2.tcore1.AEQ-Ashburn.as6453.net [216.6.87.2]
 10    52 ms    66 ms    55 ms  64.86.85.1
 11    52 ms    52 ms    53 ms  if-10-2.tcore1.TTT-Toronto.as6453.net [64.86.32.33]
 12    54 ms    52 ms    53 ms  if-9-9.tcore1.TNK-Toronto.as6453.net [64.86.33.25]
 13    54 ms    53 ms    53 ms  if-7-2.tcore1.W6C-Montreal.as6453.net [66.198.96.61]
 14    54 ms    52 ms    55 ms  66.198.96.50
 15    52 ms    54 ms    53 ms  192.34.76.2
 16    54 ms    55 ms    54 ms  199.91.189.234
 17    53 ms    52 ms    54 ms  199.91.189.74

Trace complete.

That is more along the lines of what you should be seeing...barring them clamping down because of potential security issues (like they are experiencing DDoS attacks and such). Under NORMAL conditions though, there should be no reason to ignore ICMP ECHO---unless there are stability concerns at that point in the route. And they just told you this is the case...their reason was because the "router you were pinging was too busy".