IP assignments for different zones to the same origin

Actually thats all/(mostly) explained in the linked article.

Your different domains will have different IP addresses and these will be routed differently by your provider. That is not specific to “people” but to ISPs, so depending on your visitors there is a good chance most will be routed through their local PoPs anyhow, but then again, that depends on their ISPs.

It probably is a bit more complicated than, but overall it is (mostly) ISP dependent.

But I told: these Domains have the same NameServer and point to the same IP (behind CloudFlare) but if you check

nslookup domain.de
nslookup domain.ch

They point to different IPs but why?
Its not up to my ISP as I use CloudFlare to resolve IPs. So again this is up to ClouFlare.
I for myself would like to change how my domains get routed!

For my domain.ch it is important to not be fast over all of the world but just in switzerland
For my domain.de the same but just in germany.

Again: even if I call these two domains the one is faster for me then the other (domain.ch is faster, and does have a better TTFB by 15ms) which is noticable as my content is mostly static

You did, but I didnt refer to that.

Thats something you will have to take up with the people who designed Cloudflare’s architecture :slight_smile:

It is up to your ISP where to route packets for IP addresses.

1 Like

Yeah but they are not even responding/answering to my Ticket, which I created 1 Week ago.
I also added Infos from time to time but they just ignore it. :man_shrugging:

Considering you replied to it, it is open right now, correct?

Can you post the ticket number?

Yes Status is “open” here you go: 1772052

1 Like

@cloonan

1 Like

Have to mention that I changed to “cache everything” (1 day ago) as I do not often change content on my page for getting rid of this problem. Btw: making it less noticable as for swiss visitors the page had been very slow.

(I added these Infos also to the Ticket)

Caching everything will keep your content on Cloudflare’s proxies, but wont reduce any higher latency to these proxies.

I cant comment on what you exactly asked support but I’d assume they wont be able to answer why things are the way they are either. In theory it should be probably possible to change everything to the same IP address pair *) but whether they could or would do that is a different subject.

@cloonan mostly likely wont provide a definitive explanation either, however I tagged him to clarify why your ticket appears to have turned silent.


*) Your domains are all on the same plan level, right? If not, that would explain it.

Yes I know how Cache everything works. It also caches the dynamic content and yes it would not solve the issue, but making it “better” as swiss visitors do not have to get routed to AMS, then waiting for my server to deliver the package to AMS (from Karlsruhe) and then again to Switzerland.
So this is ‘setting’ the TTFB to the time it needs to go to AMS as it will be delivered by the CloudFlare Cache.

Yes my Domains are all on the same plan level.

I just think its not routed very good. Also let us decide how to route it (domain.ch to Switzerland, domain.de to somewhere in germany) would speed things up (maybe not overall) but at the target clients, as all who are calling domain.ch are from switzerland

Have to says, in the meantime the domain.de domain gets served from LHR not ZRH anymore but again its like 1000km away and cant be faster then FRK or MUC

Really sorry for the issues, @M4rt1n, I see your ticket and the detail you’ve added to it, thank you. I will keep an eye out on the ticket and get with the Support team to review.

2 Likes

Is that one on a free plan?
I have a .cf domain (free plan, server location is Strasbourg) which is routed via London. A .de domain (business) is routed through FRA. But I don’t see any issues, even with large files . :thinking:

Fun fact: my VPN breakout is next door to Cloudflare‘s edge in FRA.

Let it know the outcome please :slight_smile:

1 Like

Yes both domains I’m speaking of are FreePlan Domains.

I also tought about switching to Pro but this topic is already explained here --> LINK

So for the moment I’m not switching to pro, also I saw a lot of pages getting routed through FRA which would be as good as MUC for germany (maybe FRA is even better as more in the middle)

Some additional things

I did a traceroute from my VPN node and I am routed via LHR.
Another system within the same AS but different Class C is routed via FRA.

VPN 

jumper (172.30.0.43)                                   2019-10-30T08:20:38+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                           0.0%   788    0.3   0.2   0.2   0.5   0.1
 2. 62.XX.XXX.XXX                      0.0%   788    1.1   1.4   0.3 133.4   9.4
 3. gi7-2.                             0.0%   788    1.7   1.1   0.7   2.2   0.3
 4. tengige0-1-1-1-                    0.0%   788   10.9  11.0  10.4  15.2   0.6
 5. tengige0-1-1-1-                    0.0%   788   10.3  10.7  10.1  22.8   0.9
 6. linx-lon1.as13335.net              0.0%   788   16.4  12.8  10.5  38.1   4.0
 7. 104.28.18.186                      0.0%   788   10.5  10.1   9.8  11.9   0.3

Second server

localhost (x)           2019-10-30T09:22:25+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 2axx:xxxx:xxx:xx                  0.0%     8    0.2   0.2   0.2   0.3   0.0
2. fa0-2-172.                        0.0%     8    1.2   1.1   1.0   1.3   0.1
3. de-cix2.                          0.0%     7    1.4   1.5   1.3   1.7   0.1
4. de-cix-frankfurt.as13335.net      0.0%     7    1.6   1.7   1.3   2.4   0.3
5. 2606:4700:30::681c:12ba           0.0%     7    0.8   0.7   0.7   0.8   0.0

Is it possible that this is an IPv6 thing? Every time I use v6 I get routed to FRA, on IPv4 LHR, AMS, VIE… :thinking:

No sure as my Server does not use IPv6 but on CloudFlare I overwrite the header so IPv6 visitors can visit, even if my server does not have a IPv6

Sorry, I was indistinct. It seems different when the client is using IPv4.

Just re-checked that via /cdn-cgi/trace

LTE, IPv6: FRA

VPN, IPv4: AMS
From our office, IPv6: FRA
(Both on the same ASN)

VDSL at home: IPv6: FRA.
With IPv6 disabled in Windows: LHR

Several public WiFis with IPv4 only: AMS, VIE, LHR

No matter if Free or Business

Have you seen this?
https://cloudflare-test.judge.sh/

When a POP is congested, you get rerouted to other POPs, and that will depend on how much you pay (Free plans first, then Pro, etc).

You won’t necessarily be rerouted to the second nearest POP. I’m in LIS and when this last happened websites were rerouted to either AMS or LRH depending on the ISP. This was pretty common, then it stopped (always get LIS now), which is consistent with LIS getting a capacity upgrade. LHR and AMS are probably the highest capacity (and cheapest to run) European POPs.

Also, not sure if this is still true, but a while ago some POPs never served Free traffic from certain ISPs, because of deals those ISPs failed to strike with Cloudflare (free peering). This was mostly in Australia (also I guess India) but it’s not something I’ve personally witnessed in large scale in Europe.

You get what you pay for. Is the latency that bad to AMS/LHR? Also ZHR doesn’t strike me as bad for FRA traffic.

Finally, if you want traffic being served from the POP closest to your server (not your users), you should enable Argo, and use Argo tunnel. That’ll also cost you.

This topic was automatically closed after 14 days. New replies are no longer allowed.