Výpadky IPv6 u Nordic Telecom

[maruncz]

Ahoj

mám problémy s IPv6. Poprvé jsem na to narazil na přelomu roku, projevovalo se to tak, že občas git přes ssh na gitlab.com trval dlouho. Teď jsem se dostal k tomu to řešit. Ve wiresharku je vidět, že se snaží pripojit přes IPv6 ale nedostane žádnou odpověď, tak po 180s přepne na IPv4 a projde to bez problémů. Ale není to pravidlo, občas IPv6 spojení funguje bez problémů. V příloze je záznam err-gitlab.pcap, kde je vidět problém, a ok-gitlab.pcap kde je vidět, že vše proběhne v pořádku.
Když ke gitlab.com přistupuju z prohlížeče, tak je vidět, že prohlížeč se pokudí vanázat obě spojení současně a použije to, které se chytí dřív (gitlab-http.pcap).
Dál jsem vypozoroval, že na stránce test-ipv6.com mě náhodně různé testy ohledně IPv6 selžou (viz obrázky, ale i jiné).
Mám podeření na blokované ICMPv6 packet too big, ale medokážu to nijak potvrdit.
Zkouším teď curl https://mtu1280.frankfurt.test-ipv6.com/ip/?callback=?&size=1600 s různými velikostmi a není tam jasná hranice, občas mi projde 1600, občas neprojde ani 1000.

Jak jsem naznačil v nadpise máme internet od Nordic Telekom, máme doma NX510v s logem O2. Prístup do toho mám ale nevím co kde kontrolovat nebo změnit.

Rád bych tento problém vyřešil, ideálně jinak než deaktivací IPv6. Uvažuju, že se providerovi ozvu, ale chtěl bych mít nějaký konkrétní důkaz nebo podklad.

[Reklama]

[Whoami68]

Od Nordika tam zůstal jen název . Jak milé, spadl pod O2, tak se začaly objevovat různé srač**. Klasika, O2 je O2.

[Radek Zajíc]

Popravde tady asi moc nepomuzeme. Osobne me nejvic prekvapuje, ze na Nordic LTE pripojkach prideluji IPv6, a dokonce z Nordic prefixu,

Osobne bych zkusil TCP MTR na cilovy server, je mozne, ze maji nekde load balancing pomoci ECMP a jedna z cest skutecne zahazuje PTB.

tj. neco jako
mtr -b -w --tcp --port 443 mtu1280.frankfurt.test-ipv6.com

S vystupem bych pak sel k O2 guru, at to predaji technikum.

Co je jeste zajimave: v tom pcapu je videt, ze odejde TCP SYN, ale uz se nevrati zadny SYN/ACK. Jako kdyby ty pakety nekdo po ceste zahodil. To by vubec nemelo souviset se zahazovanim ICMPv6, spis by to naznacovalo nejaky jiny problem.

I tohle bych napsal O2 Guru a cekal, co s tim udelaji. Nejspis navrhnou "vypnete IPv6", coz jim, prosim, omlatte o hlavu, protoze to nevyresi problem (ktery se dal bude projevovat u ostatnich uzivatelu), jen ho to zamaskuje,

(Alternativni pripojeni asi k dispozici neni...?)

[jjrsk]

Dokazes si po ty 6tce pingnout nejaky interni stroj? Myslim tim zvenku.

https://dnschecker.org/ping-ipv6.php

Trebas.

Neznam detaily ty routokrabice, ale uplne nejlepsi by bylo z ni udelat bridge a dat za to neco svyho co mas pod kontrolou a co se chova nejak pristojne. Prej to ma nejakej "zakladni" firewall, ale nevim co si pod tim mam predstavit. Kazdopadne bych ho zkusil vypnout.

Totiz to chovani ktery popisujes pomerne presne vystihuje i to co si sam zminil = (polo)nefunkcni icmp. Coz na 4ce zas tak moc nevadi, ale na ipv6 je to zcela zasadni vada.

[Radek Zajíc]

Pristup zvenku bude pravdepodobne zafirewallovany. Alespon na sve LTE/5G siti to tak O2 ma.

[Reklama]

[maruncz]

Ahoj, konečně mám zase čas se tomu věnovat.

Kód [Vybrat] Rozbalit

mtr -b -w --tcp --port 443 mtu1280.frankfurt.test-ipv6.com
Start: 2026-01-23T16:17:31+0100
HOST: cachyos-desktop                                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a02:258f:0:bb5:da44:89ff:fe61:ff4a                                             0.0%    10    0.5   1.9   0.5  12.6   3.8
  2.|-- ???                                                                            100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- 2001:41d8:1:442d::1                                                            10.0%    10  4125. 2428.  33.3 7189. 2167.3
        2001:41d8:1:443d::1
  4.|-- dynamic-2a00-1028-0001-00cc-0000-0000-0000-0002.ipv6.o2.cz (2a00:1028:1:cc::2) 50.0%    10   28.2  27.9  25.4  29.7   1.6
  5.|-- 2a07:cc80::a                                                                   40.0%    10   32.0  36.0  22.4  50.5   9.2
  6.|-- ???                                                                            100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 2001:978:2:81::3:4                                                             60.0%    10  7238. 3628.  29.1 7238. 3195.6
  8.|-- be8281.ccr21.bts01.atlas.cogentco.com (2001:550:0:1000::9a36:4959)             60.0%    10  5163. 1569.  27.6 5163. 2444.2
        be8282.ccr22.bts01.atlas.cogentco.com (2001:550:0:1000::9a36:495d)
  9.|-- be9463.ccr81.vie01.atlas.cogentco.com (2001:550:0:1000::9a36:48aa)             40.0%    10   33.3  37.9  28.1  56.8  11.4
        be9457.ccr82.vie01.atlas.cogentco.com (2001:550:0:1000::9a36:3f91)
10.|-- be9456.ccr22.muc03.atlas.cogentco.com (2001:550:0:1000::9a36:3f8e)             90.0%    10  7225. 7225. 7225. 7225.   0.0
11.|-- be7944.ccr42.fra05.atlas.cogentco.com (2001:550:0:1000::9a36:4b62)             80.0%    10  1119. 599.6  80.1 1119. 734.8
12.|-- be5485.rcr31.fra06.atlas.cogentco.com (2001:550:0:1000::9a36:4d36)             70.0%    10  3168. 2452.  63.9 4125. 2123.1
        be8232.rcr31.fra06.atlas.cogentco.com (2001:550:0:1000::9a36:2671)
13.|-- 2001:978:2:42::65                                                              40.0%    10   46.8  45.5  39.7  53.5   4.7
14.|-- ae9.r22.fra02.mag.netarch.akamai.com (2600:1488:600a:2::14)                    60.0%    10   35.6  52.7  35.6  78.2  20.0
        ae10.r22.fra03.mag.netarch.akamai.com (2600:1488:600a:2::30)
        ae10.r21.fra03.mag.netarch.akamai.com (2600:1488:600a:2::28)
        ae9.r21.fra02.mag.netarch.akamai.com (2600:1488:600a:2::6)
15.|-- ae0.r24.fra03.ien.netarch.akamai.com (2600:1488:600a:2::d)                     40.0%    10   58.7  49.5  38.5  58.7   7.9
        ae0.r22.fra02.ien.netarch.akamai.com (2600:1488:6009:2::1b)
        ae2.r24.fra03.ien.netarch.akamai.com (2600:1488:600a:2::2f)
16.|-- 2600:3c0f:10:32::2                                                             60.0%    10   44.5  50.7  44.5  60.3   6.8
        2600:3c0f:10:32::1
17.|-- 2600:3c0f:10:35::28                                                            40.0%    10   36.5  44.5  36.1  52.8   7.6
        2600:3c0f:10:35::27
18.|-- 2600:3c0f:10::700                                                              60.0%    10   38.4  44.6  38.4  51.5   6.4
19.|-- 2a01:7e01:e001:8a6::1280                                                       40.0%    10   45.9  41.9  34.1  47.5   5.6


Co je jeste zajimave: v tom pcapu je videt, ze odejde TCP SYN, ale uz se nevrati zadny SYN/ACK. Jako kdyby ty pakety nekdo po ceste zahodil. To by vubec nemelo souviset se zahazovanim ICMPv6, spis by to naznacovalo nejaky jiny problem.

tady by mohl být problém v tom, že nevím jak to zafiltrovat aby tam případně byly vidět i ICMPv6 ale jen ty související, ICMPv6 v lokální síti chodí hodně.

Dokazes si po ty 6tce pingnout nejaky interni stroj? Myslim tim zvenku.

Když v routeru vypnu IPv6 SPI Firewall tak se traceroute z dnscheck.org dostane až na mou IPv6, ale občas mě router odpoví a občas ne. Nechávám to teď zaplé, protože nevím co všechno se mi pak může dostat do sítě.

Když je ten firewall vypnutý tak stejně

Kód [Vybrat] Rozbalit

curl https://mtu1280.frankfurt.test-ipv6.com/ip/?callback=?&size=1600 chodí náhodně.

[dv1212]

Ahoj, byl jsem na dovolené a měl jsem problémy s přístupem ke svému serveru kvůli nestabilnímu spojení.
Vypadá to, že to vůbec nesouvisí s Nordic, protože já jsem u T-Mobile

Nedokázal jsem zjistit proč a strávil jsem spoustu času diagnostikou na mé straně, ale zdá se, že je problém spíše někde "na cestě".

Používám IPv4 ale hostname nodu be9457.ccr82.vie01.atlas.cogentco.com je stejný. Díky němu jsem našel tento příspěvek.

Můj tracert vypadal následovně

Kód [Vybrat] Rozbalit


7 17 ms 18 ms 15 ms be5504.ccr51.beg03.atlas.cogentco.com [154.54.62.69]
8 22 ms 23 ms 24 ms be3422.ccr31.bud01.atlas.cogentco.com [130.117.0.125]
9 31 ms 24 ms 22 ms be3263.ccr22.bts01.atlas.cogentco.com [154.54.59.177]
10 25 ms 30 ms 32 ms be9457.ccr82.vie01.atlas.cogentco.com [154.54.63.145]
11 * * * Request timed out.
12 36 ms 38 ms 41 ms f-ed11-i.F.DE.NET.DTAG.DE [62.154.4.162]
13 * * * Request timed out.
14 * * * Request timed out.

Teď už jsem doma a tracert vypadá jinak.
Zkoušel jsem ping na be9457.ccr82.vie01.atlas.cogentco.com [154.54.63.145] a má 18% packet loss

Kód [Vybrat] Rozbalit


Ping statistics for 154.54.63.145:
    Packets: Sent = 50, Received = 41, Lost = 9 (18% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 39ms, Average = 17ms

Kód [Vybrat] Rozbalit


  2     2 ms     1 ms     1 ms  62.141.11.116
  3     2 ms     2 ms     2 ms  89.24.28.9
  4     *        *        *     Request timed out.
  5    16 ms    15 ms     *     be3201.ccr81.prg01.atlas.cogentco.com [130.117.14.81]
  6    14 ms     *       14 ms  be9357.ccr22.bts01.atlas.cogentco.com [154.54.62.162]
  7     *       15 ms    15 ms  be9457.ccr82.vie01.atlas.cogentco.com [154.54.63.145]

Zkoušel jsem ping i na be3201.ccr81.prg01.atlas.cogentco.com [130.117.14.81] a stále mi to zahazuje packety. Podle hostname prg01 a GeoIP je to node někde v Praze, ale delay se zvedne ze 2ms->15ms takže je možné, že ať už be3201.ccr81.prg01.atlas.cogentco.com nebo node mezi 89.24.28.9 a 130.117.14.81 je ten, který způsobuje delay 2ms -> 16ms a packet loss kvůli přetížení.