Keep getting D/C symbol

[Rydis]

Im currently at level 2 support without any responses back. Sending again.

Hopefully can get the help you got.

[Rydis]

http://i.imgur.com/m8l0JAB.jpg

so this is todays, is a lot better than yesterday. Oddly, Im having this issue today, and didn't yesterday. Same route as yesterday, better results, have issue today, but not yesterday...

ill check out the link, didn't see before.

But like I said..todays trace looks really good..and im having this issue..dont know if that can convince them..

Edit: Found this and ran it. Posted on that website. Hopefully will help.

http://i.imgur.com/YefR6Vy.png

[Rydis]

i have not spoken with ISP again and SE again, and replaced the router. I have done every possible solution on my end and still have this issue.

Both ISP and SE says..they have 0 issues

[Rydis]

so what does that mean for me?

I did mention that fact to him and it said its just because traceroutes are not as important as other traffic and that the depriorization isn't effect my actual connection to the game. Hence they only de-prioritize ICMP requests and only them.

[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".

[Rydis]

i can't because my 2nd hope never responds..it just stops there

[Raist]

At the head end? Then something odd may be going on indeed. If you have a combo router from them, you might be able to connect through your local gateway address (192.168.0.1, sometimes it may be 192.168.100.1) and pull up a utility section from there that will let you run traceroute and such that may reveal more information. Depends on how you are setup. Sometimes the user/pass are really simple like admin/password, admin/admin, user/password, etc. There may even be a FAQ out there telling you how to pull up your signal/event logs on their website that will provide you the address and login details.

If you can't get to a utilities section built into the router, the modem's connection/signal status pages and such may give you the primary gateway and/or CMTS addresses you can test against. You may indeed have some issues closer to home that they don't want you to see--and for good reason I guess. Because if you can show them there is a problem, they need to fix it.

Edit:
Try running this command from a command prompt to see if you get the list of IP's for the route:

pathping -n neolobby02.ffxiv.com

The -n switch tells it not to try resolving the host names for the IP's, so it should be able to report just the IP addresses. If you want to see the host data on a particular IP, you may be able to get that from sites like myip.ms or arin.net.

If using the -n switch fails to give the IP, then you can try looking up your real-world IP address through speedguide.net's TCP Analyzer and from there we may be able to dig a little bit into what may be going on once we know the subnet you are on (if you click the address on that page, you will get some info and tools you can use to do some testing--may need to set your router/firewall to respond to pings either globally or from their server).

[Rydis]

At the head end? Then something odd may be going on indeed. If you have a combo router from them, you might be able to connect through your local gateway address (192.168.0.1, sometimes it may be 192.168.100.1) and pull up a utility section from there that will let you run traceroute and such that may reveal more information. Depends on how you are setup. Sometimes the user/pass are really simple like admin/password, admin/admin, user/password, etc. There may even be a FAQ out there telling you how to pull up your signal/event logs on their website that will provide you the address and login details.

If you can't get to a utilities section built into the router, the modem's connection/signal status pages and such may give you the primary gateway and/or CMTS addresses you can test against. You may indeed have some issues closer to home that they don't want you to see--and for good reason I guess. Because if you can show them there is a problem, they need to fix it.

Edit:
Try running this command from a command prompt to see if you get the list of IP's for the route:

pathping -n neolobby02.ffxiv.com

The -n switch tells it not to try resolving the host names for the IP's, so it should be able to report just the IP addresses. If you want to see the host data on a particular IP, you may be able to get that from sites like myip.ms or arin.net.

If using the -n switch fails to give the IP, then you can try looking up your real-world IP address through speedguide.net's TCP Analyzer and from there we may be able to dig a little bit into what may be going on once we know the subnet you are on (if you click the address on that page, you will get some info and tools you can use to do some testing--may need to set your router/firewall to respond to pings either globally or from their server).

has nothing to do with it. If pathping encounters a spot that doesn't allow it to receive the commands it ends it there. My ISP doesn't allow any echo type commands to its server at all, so every traceroute and such will always show it as *** and 100% fail. Pathping will always end here because it can't pass. its just how pathping works

Either way ISP wont do anything they said..so unfortunate I just can't play the game.

[Raist]

That 2nd hop should be your gateway on their network. There should be a simple way to identify it. You should at least get the route list from pathping. At least I would in the past. Even though I would have starred events along the way, I could always get the list of IP addresses for the route so we had a road map and knew were to look for problems.

Perhaps there is something stronger clamping down access to that gateway (firewall or ACL)? Who knows... but without being able to test against it, you are in a bad pickle because you can't confirm that things are indeed good on their side of the equation. You can have signs of potential trouble show up down the route that are actually from something in your first 5 hops.

[Rydis]

just to show...

http://i.imgur.com/AFvs8Ze.png