Dallas - CloudFlare Packet Loss

I am experiencing high levels packet loss in my route to the closest CF server, in Dallas, Texas, USA. Unfortunately it has been ongoing for around a month and did get better for a few days after Dallas had scheduled maintenance.

Here is an MTR from a problematic path.

 Host                                                                        Loss%   Snt   Last   Avg  Best  Wrst StDev
...
 6. dls-b23-link.ip.twelve99.net                                              0.0%    28   21.5  20.9  18.5  27.9   1.9
 7. cloudflare-ic-328260.ip.twelve99-cust.net                                17.9%    28   31.9  35.0  29.4  54.0   5.8
 8. 172.71.164.2                                                             11.1%    27   30.4  33.3  30.1  41.7   2.6
 9. 104.18.37.228                                                             3.8%    27   30.9  30.8  28.5  33.3   1.4

Unfortunately I believe I have finally exhausted all the steps I can take. On one website I have control over that the issue presented itself on, I de-orange clouded and received no packet loss.

At speed cloudflare com I get a persistent 10 - 30 percent packet loss as it connects to the Dallas datacenter.

I have confirmed this is only Cloudflare websites. I saw nowhere else I could report this.

3 Likes

I’m having the same issue here.

I’m in Gulfport, MS and getting routed to DFW/Dallas CF servers and I’m getting average 13% packet loss from pings. From the CF speedtest it’s higher at like 18-25%.

Running ping test from a vpn to route it away gives me zero loss. I’m at a loss of what to do as well, it’s only Cloudflare websites and servers.

2 Likes

I’m in D’Iberville, MS and I’ve been having the same problem since late August. It only happens during specific hours of the day, and I get similar double-digit packet loss during those hours. This causes Cloudflare sites to become near unusable because of how badly their performance is affected.

I have heard that others in the area are experiencing similar, so this is a widespread issue. I don’t understand why this isn’t being addressed.

1 Like

East Texas here routed through Dallas. Anything Cloudflare related after 2PM is between a 15-20% packet loss over a 5-minute span. Makes all CF sites unusable. Below is to the Shopify Admin portal.


Target Name: admin.shopify.com
         IP: 23.227.38.33
  Date/Time: 10/3/2023 16:51:35 - 10/3/2023 16:56:35

Hop  Sent  PL%    Min     Max    Avg  Host Name / [IP]
  1   302    0   0.16   14.57   0.85  XXX  [XXX.XXX.XXX.XXX]
  2   300  100      0       0      0   [-]
  3   302    1   0.68   38.82   2.36  10.224.17.25 [10.224.17.25]
  4   302    1   3.41   39.96   4.92  10.224.91.1 [10.224.91.1]
  5   299  100      0       0      0  lag-107.ear5.Dallas1.Level3.net [4.7.200.49]
  6   299   96   3.83   17.32   5.66  ae2.3613.ear4.Dallas1.level3.net [4.69.211.229]
  7   299   89  15.54   30.55  18.58  4.16.234.182 [4.16.234.182]
  8   302   13  15.07   44.05  18.32  172.71.172.2 [172.71.172.2]
  9   302   14  15.00  153.57  17.14  admin.shopify.com [23.227.38.33]
1 Like

I ran the Cloudflare speed test a few times during the hours the problem occurs, below is a sceenshot of just one of the results. It connects to Dallas each time.

@itsme: Seems like you left out a lot of traceroute information, which is most often going to do much more harm than it will do good. Can you share what AS number you are coming from?

@benelliottm93 & @robmail87: Could you please share a traceroute (e.g. mtr, WinMTR, PingPlotter, …), and what AS number you are coming from?

@andy61 Also, what AS number are you coming from?

The AS number can be found here:

  1. https://1.1.1.1/help
    → AS Number
  2. https://bgp.tools/
    → The AS number shown under “You are connecting from” like this: “Cloudflare, Inc. (AS13335)
  3. https://bgp.he.net/
    → The AS number shown like this: “Your ISP is AS13335 (Cloudflare, Inc.)

This information (especially the AS number) would be essential for Cloudflare (and/or any other network) in order to be able to dig further in to such issues, such as for example attempting to find an alternative path that may cause less packet loss (if technically possible).

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| - 0 |3191 | 3191 | 0 | 0 | 12 | 0 |
| - 0 | 3191 | 3191 | 6 | 10 | 53 | 9 |
| - 0 | 3191 | 3191 | 6 | 10 | 50 | 10 |
| - 0 | 3191 | 3191 | 19 | 22 | 35 | 22 |
|ipv4.de-cix.dfw.us.as13335.cloudflare . com - 14 | 2115 | 1837 | 31 | 37 | 104 | 35 |
| 172.71.168.2 - 13 | 2162 | 1895 | 32 | 39 | 146 | 35 |
| one.one.one.one - 12 | 2206 | 1951 | 31 | 33 | 53 | 32 |

This is one I have saved from Oct 2nd, I left it running for a bit.
My AS I’m coming from is: AS11492

Mine is AS11492 as well, though our towns are only about 20 minutes apart. If necessary, I’ll run a traceroute tonight and post the results.

I don’t know what happened tonight, but things have improved dramatically. I ran traceroutes and the CF speed test a few times in the past few hours, and so far I haven’t seen any packet loss coming from Cloudflare addresses. The speeds from the CF speed test, while not perfect, are now much much better.

The only packet loss I do get are from the Level 3 addresses that very rarely pop up among the Cloudflare addresses on a traceroute. They are from Dallas too, so there’s probably a larger problem happening over there. Below is a traceroute I ran for a minute where I was able to catch a couple of Level 3 addresses. “No response from host” seems to be a common occurrence when they appear.

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| - 0 | 76 | 76 | 0 | 0 | 0 | 0 |
| - 0 | 76 | 76 | 9 | 13 | 20 | 12 |
| - 0 | 76 | 76 | 8 | 13 | 47 | 13 |
| - 0 | 76 | 76 | 28 | 31 | 41 | 34 |
| No response from host - 100 | 16 | 0 | 0 | 0 | 0 | 0 |
| ae1.3509.edge2.Dallas2.level3 . net - 3 | 68 | 66 | 25 | 32 | 60 | 26 |
| 4.4.128.2 - 35 | 32 | 21 | 0 | 29 | 44 | 32 |
| 172.71.172.4 - 0 | 76 | 76 | 29 | 34 | 61 | 29 |
| 172.67.133.187 - 0 | 76 | 76 | 29 | 32 | 41 | 32 |

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.