Diverse probleme cu accesul la internet

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?!?
 
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.
 
puterfixer said:
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.
Click to expand...
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?
 
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.
 
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.
 
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?
 
Marius '95 said:
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.
Click to expand...
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ă.
 
jarod said:
Ș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 :smile: ).
Click to expand...
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.
 
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.
 
Ma racaie pe creier MTU de 1492 prin PPPoE. Stie cineva daca RDS accepta MTU de 1508 pe ethernet astfel incat sa ramana 1500 prin PPPoE?
 
Marius '95 said:
Ma racaie pe creier MTU de 1492 prin PPPoE. Stie cineva daca RDS accepta MTU de 1508 pe ethernet astfel incat sa ramana 1500 prin PPPoE?
Click to expand...
Pai MTU discovery si afli. Daca o fi posibil.
Dar ma indoiesc ca au ei 1492 degeaba, deci e pierdere de timp sa incerci.
 
You must log in or register to reply here.
Back
Top