Keep getting D/C symbol

[Rydis]

It looks to be the same as most everyone else that has taken a closer look at their route. Issues persist in the way you are being routed. Changing ISP's doesn't automatically prevent you from getting sent to the same exchange point--nor even the same routing partner...it could just send you through a different exchange point but you wind up with the same ISP that is having problems.

In the pic you posted of a Windows Tracert, you have signs of trouble right there in Tampa, before you get handed off into Level3--which is also showing signs of trouble. The later spike could be due to the earlier spike though...but with Level3's history, I wouldn't be too quick to dismiss them either.

We frequently see Level3 having issues with various ISP's---more frequently with Verizon in the north east, Texas, and a few other places...but other ISP's have had issues with them as well. Every time I get put on their routes, they usually last about a week before we have to get it switched back to either TATA or Cogent.

And yes... it is an issue your ISP can and SHOULD address for you. If they can't/aren't willing to work things out with their peering partner (in that case Level3) to clean things up, then they should be able to arrange for you to use someone else for the peering. Mine gets changed often...was changed just before this weekend in fact--TATA was having issues in the Ashburn/DC area and TWC flipped me to Cogent and I'm going through Atlanta now. As a result, I no longer slingshot Toronto on the way to Montreal either--knocking two hops off my route.

Edit: Just did a quick lookup on your gateway...Bright House Networks. Close ties to Time Warner. They also peer with TWC, Qwest, XO, and Verizon. Not the greatest options...but through some of them they should be able to get to either TATA or Cogent. Perhaps if they took advantage of their peering with Time Warner it may pan out better for you in the long run, even though it may mean a few more hops (could go BHN -> TWC/RR -> TATA -> Ormuco). It will likely involve pushing for someone higher up the chain to escalate the issue to Tier3/Engineering though. You may find you fair better going through the online contacts than the phone. DSL Reports has forums set up with more direct access to the higher support tiers that may help you move things along. Here is a link to their Bright House forum:

https://www.dslreports.com/forum/bhousedirect

is basically what I was told

"The route you showed actually had no loss. That is called ICMP deprioritization and is non-impactful and completely normal. It simply means the router you were pinging was too busy doing real things to be bothered with your pings. Based on what I see at the moment there is nothing wrong on our end. If you have more I'm more than happy to look at it."

[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

[Raist]

is basically what I was told

"The route you showed actually had no loss. That is called ICMP deprioritization and is non-impactful and completely normal. It simply means the router you were pinging was too busy doing real things to be bothered with your pings. Based on what I see at the moment there is nothing wrong on our end. If you have more I'm more than happy to look at it."

Oh wow...you do realize they just admitted there is a problem with over-utilization, right?

They admitted that the load has ramped up to the point that it has to enforce prioritization rules. In other words it is intentionally ignoring/delaying/discarding what they consider lower priority traffic in order to preserve bandwidth for what they deem is higher priority traffic. Basically it is overloaded and they are throttling the traffic. If traffic was in the normal range (below 80%), there would be no need to enforce such rules.

Ties in quite well with some of the Level3 blog posts we've often linked to in these threads over the last year or so...especially the two I quoted from recently in one of the Verizon threads:

http://blog.level3.com/open-internet...tal-mea-culpa/

So let’s look at what that means in one of those locations. The one Verizon picked in its diagram: Los Angeles. All of the Verizon FiOS customers in Southern California likely get some of their content through this interconnection location. It is in a single building. And boils down to a router Level 3 owns, a router Verizon owns and four 10Gbps Ethernet ports on each router. A small cable runs between each of those ports to connect them together. This diagram is far simpler than the Verizon diagram and shows exactly where the congestion exists.

Verizon has confirmed that everything between that router in their network and their subscribers is uncongested – in fact has plenty of capacity sitting there waiting to be used. Above, I confirmed exactly the same thing for the Level 3 network. So in fact, we could fix this congestion in about five minutes simply by connecting up more 10Gbps ports on those routers. Simple. Something we’ve been asking Verizon to do for many, many months, and something other providers regularly do in similar circumstances. But Verizon has refused. So Verizon, not Level 3 or Netflix, causes the congestion. Why is that? Maybe they can’t afford a new port card because they’ve run out – even though these cards are very cheap, just a few thousand dollars for each 10 Gbps card which could support 5,000 streams or more. If that’s the case, we’ll buy one for them. Maybe they can’t afford the small piece of cable between our two ports. If that’s the case, we’ll provide it. Heck, we’ll even install it.

http://blog.level3.com/open-internet/not-neutrality/

But it is now late September. So what has changed? Well, let us look at three large Local Exchange Carriers (LECs) in the United States. These LECs are telephone companies that built broadband networks on the back of monopoly-funded telephone infrastructure. Over the past six months, the utilization of each interconnection location between their networks and Level 3’s has changed as shown in the following diagram.

Each number shows utilization at one of the interconnection locations in various cities throughout the United States between Level 3 and the LECs. Utilization above 85% indicates the LEC is causing congestion in that city by refusing to add interconnection capacity

This shows a dramatic improvement for LEC1 and LEC3, but a continued degradation for LEC2. You might say that it’s good news overall. But if you value an open Internet underpinned by a dynamic competitive environment, you may have a different opinion.

And that’s because the reason the interconnect utilization between Level 3 and LEC1 and LEC3 improved is that these LECs forced Netflix to pay them to interconnect directly with them. And as Netflix CEO Reed Hastings has pointed out several times, Netflix didn’t do that because they were taking advantage of a highly competitive Internet marketplace. They did it because they had no choice: all third-party content that LEC broadband users want to see eventually has to go through LEC interconnection points. When the LEC tries to turn these interconnection points into Internet tollbooths there is no alternate path for the content to take to reach the consumers.

[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