Diverse probleme cu accesul la internet

[Marius '95]

Da, am primit IP public dupa ce am activat DDNS.
Multumesc.

 

[Marius '95]

Alta chestie ciudata rau...
- ONT-ul Digi (un Huawei sinistru) conectat la internet si in mod bridge.
- Router conectat la ONT prin ethernet 100 (ca a trebuit sa impart in doua unicul cablu), face PPPoE-ul. MTU 1492.
- Server conectat la router prin gigabit, MTU 1500. Proxy server pe server.
- Desktop conectat la server prin gigabit, MTU 1500. Browser pe desktop prin proxy. SpeedTest pe serverul Digi Bucuresti:
11MB/s download, ~9MB/s upload.
- Activez jumbo frames intre desktop si server. MTU ~8500, vazut fizic pe Wireshark.
Viteza internet: 50-100KB/s download, ~9MB/s upload.
What?!?

 

[Thor]

Desktopul e conectat direct la server? Sau trece prin router?

 

[puterfixer]

Nu pot zice că mă surprinde, routerul trebuie să fragmenteze fiecare pachet și endpoint-ul celălalt să-l reasambleze după ce a primit toate bucățelele, iar asta penalizează viteza.

Jumbo frames merg bine în niște cazuri de nișă, între sisteme din LAN care nu au nevoie de acces (rapid) la internet. Altfel, câștigul obținut din reducerea overhead-ului este minimal, dar lovește mult mai nasol în performanța comunicării în internet.

 

[Marius '95]

Desktopul e conectat direct la server? Sau trece prin router?

Direct.

 

[Marius '95]

Nu pot zice că mă surprinde, routerul trebuie să fragmenteze fiecare pachet și endpoint-ul celălalt să-l reasambleze după ce a primit toate bucățelele, iar asta penalizează viteza.

N-am priceput. Desktop-ul cere un site (html, imagine, orice) proxy-ului printr-o conexiune cu jumbo frames. Proxy-ul deschide propria lui conexiune catre site, cu alt MTU, care, BTW, ar trebui sa faca si Path MTU Discovery => 1492.
Deci care fragmentare?

 

[miahi]

Am întâlnit diferențe așa de mari în performanță la fragmentare doar atunci când clientul trimite flag-ul do not fragment (caz în care fiecare pachet trebuie să se întoarcă la client pentru re-fragmentare, nu poate fi fragmentat de router). Iar MTU discovery funcționează dubios uneori (mai ales în medii virtualizate, care fac skip la networking stack care pe unde). Fără wireshark/tcpdump nu cred că scapi în cazul ăsta, să vezi de unde vine problema.

 

[Marius '95]

Pai nu prea am reusit cu wireshark. Site-urile au sute de chestii downloadate la o singura pagina web si de cand cu httpS, nu mai "vad" nimic. E totul opac pe ambele parti ale proxy-ului.

 

[puterfixer]

Io doar zic că mi s-a luat de experimente cu Jumbo Frames, și să ghicesc de ce stack-ul face chestii dubioase cu MTU-ul pe interfețe diferite. Câte ore sau zeci de ore de debugging să fac, pentru a satisface literalmente un pitic ce ține la teoria lui că "tre' să meargă", când beneficiul practic e neglijabil?

 

[miahi]

Pai nu prea am reusit cu wireshark. Site-urile au sute de chestii downloadate la o singura pagina web si de cand cu httpS, nu mai "vad" nimic. E totul opac pe ambele parti ale proxy-ului.

Păi urmărești o singură sesiune, vezi ce face. Filtrare de tipul tcp.stream eq 2 (mă rog, schimbi 2 până găsești ce-ți trebuie; poți ajunge la ce îți trebuie și cu right click pe un pachet / follow / tcp stream). Cam tot ce e TCP e probabil cu don't fragment, distracția ta e la aflat cine nu negociază.

 

[miahi]

Și/sau încearcă să activezi DNS dinamic. Mă gândesc că dacă e activ, ar trebui să-ți dea automat IP public (altfel, nu prea are rost activarea ).

Am avut niște reconectări de curând. Am activat DNS dinamic de când am discutat, n-are nici o treabă cu cgnat, când are chef tot bagă IP-uri din 100.64/10. Pus script în router să se reconecteze când primește bălării.

 

[jarod]

Poți încerca să deschizi tichet din interfața web și să zici că vrei IP public tot timpul. Ar trebui măcar să-ți dea un feedback.