T-2 - težave z IPv6, MTU, HTTP/3...

O tem sem že malo pisal v temi o IPv6, ampak nisem še prišel zadevi do dna...
Tako da imam še nekaj vprašanj za tiste, ki imate IPv6. Predvsem za tiste s T-2 povezavo, ampak tudi za ostale. Če pa nimate IPv6 (whatismyip.com) potem nima veze, ker na IPv4 teh problemov ni.

Za začetek naredite prosim ta test:
V Windowsih: ping -6 one.one.one.one -l 1234
V Linuxu: ping6 one.one.one.one -c 4 -s 1234
(Verjetno je v macOS kaj podobnega.)

Kakšen je rezultat? Gre normalno skozi ali se paketi izgubijo (request timed out, lost packets)?
Če se da, povejte še kakšna povezava je (FTTH ali DSL) in kateri modem.

Pri meni na T-2 z 1234 ne gre skozi, največ kar lahko uporabim je 1232. Na A1 (v bistvu bob preko telefona) pa gre in še precej več kot 1234.
Imam pa T-2 FTTH (GPON) in modem Innbox U92 (povezan sem direktno nanj).

-

Za kaj sploh gre? Nekatere strani se mi preko T-2 povezave ne odpirajo pravilno in rad bi ugotovil zakaj in če se še komu to dogaja. Se ne spoznam na te stvari, ampak glede na to kar sem našel na internetu, kaže na neko MTU omejitev ali ICMP filtriranje na T-2 povezavi. Zato ta ping test z večjimi paketi.
Ne vem pa koliko lahko razberem iz samega ping testa, zato je tu še vzorec teh problematičnih strani:
https://linegee.net/
https://daringfireball.net/
https://www.audiosciencereview.com/foru...
https://articlewedding.com/
https://www.alpinashop.si/

Pri meni je tako:
Chrome v Linuxu: normalno hitro nalaganje strani, ni težav.
Chrome v Windowsih: počasno nalaganje strani, traja ene 10 sekund da se naložijo do konca.
Firefox v Linuxu in Firefox v Windowsih: najslabše, večinoma se sploh ne naložijo do konca (npr. manjka CSS, slike...).

Skupno tem stranem je: vse so na Cloudflare in IPv6 in uporabljajo HTTP/3 oz. QUIC. Ampak ni problem pri vseh takšnih straneh, ampak samo pri nekaterih. Zakaj? Nimam pojma.
Če v Firefoxu izklopim HTTP/3 ali v Chromu izklopim QUIC, se te strani odprejo normalno. Ravno tako se odprejo normalno če izklopim IPv6 ali če uporabim A1 povezavo.

Poskusite jih odpret brez nič izklapljat in poročajte. Z IPvFoo (Firefox, Chrome) lahko tudi vidiš, če se dejansko odpre preko IPv6 ali pade na IPv4. Preko Inspectorja (F12, Network, Protocol) pa vidiš če se odpre preko HTTP/3 ali pade na HTTP/2.
Kot rečeno, največji problem je v Firefoxu (Windows in Linux), ampak je očiten problem tudi v Chromu v Windowsih. Za macOS pa ne vem.

Windows 10, T-2 ponudnik
Ping deluje brez izgubljanja paketkov, prav tako mi normalno odpre www.alpinashop.si (uporabljen seveda Firefox, kaj pa drugega :-)).

enako kot dunda. Imam pa svoj FW na pfsense, T-2jev router je v passthrouhg načinu

Hvala. Če še kdo lahko poskusi naj kar. Vsekakor kaže, da problem ni pri vseh T-2 uporabnikih. Mogoče samo na GPON? Mogoče v modemu U92 ali v kakšni vmesni mrežni opremi med modemom in T-2 strežniki?

Jaz sem na modemu poskusil uporabit še 4. port, ki se rabi za TV. Tako sem lahko pingal s 1234 bajti, ampak problemi s stranmi so še vedno. Na 4. portu lahko grem do največ 1345 bajtov.
Nekje sem bral da je meja za MTU fragmentiranja test s 1372 bajti. Tako da če lahko poskusite pingat še s to velikostjo bi bilo zanimivo videt če vam deluje.

Še ena stvar, ki me zanima: na kateri Cloudflare strežnik se povežete če obiščete te strani in ali vam deluje HTTP/3?
To se vidi, če dodaš /cdn-cgi/trace na koncu URLja, npr. https://daringfireball.net/cdn-cgi/trace
Relevantni vrstici sta ti dve:

colo=ZAG
http=http/2

Tako pri meni zgleda na T-2 povezavi, torej večinoma je Zagreb (kdaj tudi VIE) in vedno samo HTTP/2.
Medtem ko na A1 se mi ponavadi poveže na colo=FRA in HTTP/3. (Kdaj je treba dat parkrat reload strani da preklopi iz HTTP/2 na 3.)
Mogoče da je vendarle težava s Cloudflarovim zagrebškim strežnikom, čeprav verjetno se večina od vas povezuje tja.

Mimogrede, ravno v zadnjem tednu je bil Chrome stable posodobljen na 96.0 in so očitno nekaj izboljšali, tako da se vse te strani odpirajo hitro, enako kot v Chromu v Linuxu.
Tako da za Chrome Windows test je treba uporabit starejšo verzijo ali pa kak Chromium fork, ki še ni bil posodobljen. Npr. Vivaldi je trenutno še na 94.0.
Firefox test pa je bolj nekonsistenten. Meni vsake toliko tudi odpre te strani normalno, tako da je treba naredit več poskusov...

Očitno imaš nekje na povezavi res majhen MTU, plus ne deluje ti fragmentacija (verjetno zaradi blokiranega ICMPv6, ali pa ker je nekje na liniji kak tunel in usmerjevalnik misli, da lahko pošilja večje pakete, kot jih dejansko mrežna oprema potem sprejme).

Na nativni T-2 povezavi brez težav deluje tudi ping s 5k payloada, saj se zadeva privzeto fragmentira v več paketov. Če hočeš poslat ping v enem kosu brez fragmentacije, boš moral dodati flag "-M do" (prohibit fragmentation). V tem primeru gre ping payload na IPv6 do 1452, ostalo je IPv6 overhead (40b) in ping payload (8b). To seveda velja, ko je MTU 1500, kar na nativni T-2 optiki je.

IPv6 protokol zahteva minimalni MTU 1280 bytov, če od tega odšteješ -40-8, dobiš ravno tvojih 1232.

To, da tebi tudi brez "-M do" flaga ne deluje ping večji od 1232 pomeni, da je MTU na liniji dejansko samo 1280, plus ne deluje IPv6 MTU Path Discovery. Za test si lahko probaš na lokalni mašini MTU znižat na 1280 (ifconfig ethX mtu 1280), pa bi ti morale vse stvari normalno delovat, tudi ping -s 5000, saj ti bo že lokalna mašina pakete drobila na max 1280. Še prej lahko poženeš "tracepath -6 one.one.one.one", da vidiš kak MTU sistem misli da je sprejemljiv.

Prava rešitev je seveda te ugotovitve poslat na ipv6@t-2.net, fantje so načeloma zelo kooperativni. Na nativni T-2 optiki sicer deluje vse, kar si opisal in ni težav tudi z QUIC čez IPv6. Na T-2 GPON bi moralo biti načeloma enako, če je pa v igri OŠO je pa čisto možno, da se kaj dodatno tunelira.

za začetek priporočam branje ip/ipv4/ipv6 (de)fragmentation
kot so že zapisali - NE zapirati celoten icmp/icmpv6, ker pri slednjem bodo "preveliki" paketi ODVRŽENI.