ipv4 vs ipv6 routing

[lothyriel]

curl -4 -s -I -H "flyio-debug: doit" https://pocket-planner.loty.click | grep flyio-debug

flyio-debug: {"n":"edge-cf-gru1-2179","nr":"gru","ra":"45.229.105.186","rf":"Verbatim","sr":"gru","sdc":"gru1","sid":"148e225fde5689","st":0,"nrtt":0,"bn":"worker-cf-gru1-5f0f","mhn":null,"mrtt":null}

curl -6 -s -I -H "flyio-debug: doit" https://pocket-planner.loty.click | grep flyio-debug

flyio-debug: {"n":"edge-cf-bog1-9540","nr":"bog","ra":"2804:4870:350e:3c00:982f:f8ad:b651:5","rf":"Verbatim","sr":"gru","sdc":"gru1","sid":"148e225fde5689","st":0,"nrtt":0,"bn":"worker-cf-gru1-5f0f","mhn":"worker-cf-gru1-2239","mrtt":113}

why is ipv6 traffic being routed through Colombia?

[lillian]

this is a misconfiguration re: region deprecation, I’m going to fix it on monday

[lillian]

this should be fixed now, let me know if you’re still seeing odd routes.

[lothyriel]

flyio-debug: {“n”:“edge-cf-fra2-8893”,“nr”:“fra”,“ra”:“2804:4870:350e:3c00:982f:f8ad:b651:5”,“rf”:“Verbatim”,“sr”:“gru”,“sdc”:“gru1”,“sid”:“148e225fde5689”,“st”:0,“nrtt”:0,“bn”:“worker-cf-gru1-5f0f”,“mhn”:“worker-cf-gru1-2239”,“mrtt”:190}

Now it’s going to Germany

[lillian]

can you send a traceroute/mtr so we can see what path the request is taking? mtr -6 -bzo "LSD NABVW" pocket-planner.loty.click

[lothyriel]

mtr -6 -b -z -o "LSD NABVW" -r pocket-planner.loty.click > report.txt

Start: 2025-11-19T10:16:24-0300
HOST: pc                          Loss%   Snt Drop   Last   Avg  Best StDev  Wrst

AS267121 2804:4870:3600:0:98  0.0%    10    0    1.6   1.7   1.5   0.1   1.8

AS267121 2804:4870:1::255:25  0.0%    10    0    2.7   3.6   2.6   1.8   8.5

AS22927  2804:1e20:aaa1:3bc:  0.0%    10    0   12.1  12.1  12.0   0.1  12.2

AS22927  2804:1e20:aaa1:3bc:  0.0%    10    0   11.7  11.8  11.7   0.1  12.0

AS267613 2001:13b4:5000:6::4  0.0%    10    0   12.2  11.8  11.7   0.1  12.2

AS3356   system.0.ear7.Frank 20.0%    10    2  203.6 203.7 203.6   0.1 203.8

AS3356   RETN-LTD.ear7.Frank 50.0%    10    5  203.9 203.6 203.1   0.3 203.9

AS9002   GW-CacheNetworks.re  0.0%    10    0  221.6 221.6 221.4   0.2 222.1

AS40509  2a09:8280:1::1f:a24  0.0%    10    0  221.0 220.8 220.3   0.2 221.0

[lillian]

hey @lothyriel, we’ve moved some routes around, is it looking better now? if not could you send another mtr (with --report-wide since it’s easier to read, sorry I forgot to mention that before )

[lothyriel]

We are going to the US now, but I’m almost 100% sure this is my ISP fault, had a friend ran this and he got the same straitghforward IPV4 route

curl -6 -s -I -H "flyio-debug: doit" https://pocket-planner.loty.click | grep flyio-debug

flyio-debug: {"n":"edge-cf-iad2-69b2","nr":"iad","ra":"2804:4870:350e:3c00:982f:f8ad:b651:5","rf":"Verbatim","sr":"gru","sdc":"gru1","sid":"148e225fde5689","st":0,"nrtt":0,"bn":"worker-cf-gru1-5f0f","mhn":"worker-cf-gru1-2239","mrtt":113}

[PeterCxy]

Can you run the same mtr command over IPv4 (with -4 instead of -6)? The IPv6 route is definitely problematic but I am wondering what transit provider does it use for IPv4. The IPv6 one seems to prefer Lumen, which we had to disable in GRU due to its tendency to “pull” over everyone in Canada / US to GRU. If the IPv4 route is normal, we may be able to somehow force IPv6 to the same route.

[lothyriel]

Sure! Here you go

[lothyriel]

any updates?

[PeterCxy]

No, unfortunately, it looks like your ISP is not peered with EdgeUno (one of our upstreams in GRU) over IPv6 but they are over IPv4. I tried to look at if there’s a better route we could take on IPv6 but unfortunately there doesn’t seem to be one except Lumen, but enabling that would cause routing issues in North America instead. I was to look into what we can do about the Lumen case but haven’t made much progress yet.

[PeterCxy]

we did some tuning today, @lothyriel can you check if things look better for you over IPv6?

[lothyriel]

It’s perfect now, same route as IPV4, thank you so much! Would you mind sharing what was done? (just for curiosity sake)