mboost-dp1
Hvordan kan 100Mbit/s DoS et 1Gbit/s netværk
Jeg har et netværk bestående af tre 1Gbit/s switches, hvor jeg har tilsluttet et antal 1Gbit/s enheder og nogle 100Mbit/s enheder.
Jeg har testet overførsel imellem to computere der skulle igennem alle tre switches og målte at jeg fik tæt på 1Gbit/s igennem, så alle tre switches kan forwarde 1Gbit/s.
Til gengæld opdagede jeg til min overraskelse at en overførsel der involverede en 100Mbit/s enhed kunne forårsage et DoS af hele netværket. Der var tale om en well-behaved TCP implementation i hver ende, så det burde ikke resultere i mere end 1/10 af den belastning af netværket som en 1Gbit/s overførsel medførte.
Alligevel var det 100Mbit/s der bragte netværket i knæ, men 1Gbit/s var ikke noget problem.
Det var ikke blot de computere som var indvolveret i overførslen af de 100Mbit/s der blev berørt. Et DNS opslag imellem to andre computere kunne heller ikke lade sig gøre imens der blev overført 100Mbit/s.
Jeg undersøgte problemet nærmere og fandt ud af at det tilsyneladende kun opstår når jeg overfører 100Mbit/s fra en computer med 1Gbit/s netkort til en computer med 100Mbit/s netkort.
Mit gæt er derfor at problemet skyldes at en eller flere af switchene på mit netværk har et problem med buffering. Computeren med 1Gbit/s netkort sender sikkert lidt mere end 100Mbit/s hvilket så bliver bufferet på switchene undervejs. Når buffers så bliver fyldt op begynder switchene at droppe pakker som ikke er på vej til maskinen med 100Mbit/s netkort (men måske skal over et af de samme 1Gbit/s links).
Er her nogen som ved om man kan finde en beskrivelse af hvilke switches der lider af dette problem og hvilke der ikke gør?
Jeg har testet overførsel imellem to computere der skulle igennem alle tre switches og målte at jeg fik tæt på 1Gbit/s igennem, så alle tre switches kan forwarde 1Gbit/s.
Til gengæld opdagede jeg til min overraskelse at en overførsel der involverede en 100Mbit/s enhed kunne forårsage et DoS af hele netværket. Der var tale om en well-behaved TCP implementation i hver ende, så det burde ikke resultere i mere end 1/10 af den belastning af netværket som en 1Gbit/s overførsel medførte.
Alligevel var det 100Mbit/s der bragte netværket i knæ, men 1Gbit/s var ikke noget problem.
Det var ikke blot de computere som var indvolveret i overførslen af de 100Mbit/s der blev berørt. Et DNS opslag imellem to andre computere kunne heller ikke lade sig gøre imens der blev overført 100Mbit/s.
Jeg undersøgte problemet nærmere og fandt ud af at det tilsyneladende kun opstår når jeg overfører 100Mbit/s fra en computer med 1Gbit/s netkort til en computer med 100Mbit/s netkort.
Mit gæt er derfor at problemet skyldes at en eller flere af switchene på mit netværk har et problem med buffering. Computeren med 1Gbit/s netkort sender sikkert lidt mere end 100Mbit/s hvilket så bliver bufferet på switchene undervejs. Når buffers så bliver fyldt op begynder switchene at droppe pakker som ikke er på vej til maskinen med 100Mbit/s netkort (men måske skal over et af de samme 1Gbit/s links).
Er her nogen som ved om man kan finde en beskrivelse af hvilke switches der lider af dette problem og hvilke der ikke gør?
Jeg fandt en artikel som beskriver nogle af problemerne. http://citeseerx.ist.psu.edu/viewdoc/download?doi=.... Afsnit 3.2.1 og figur 10 ligger meget tæt op af det setup jeg havde problemer med.
Det lyder som om problemet blev beskrevet lidt for sent til at få en løsning med i standarden for gigabit Ethernet i første omgang. Jeg ved ikke om senere versioner af Ethernet har løst problemet.
Men jeg tror til gengæld godt at switches kan gøre lidt for at forhindre problemet uden at det kræver ændringer på standarden.
Grunden til at back-pressure blev introduceret var for at reducere mængden af pakketab og dermed opnå bedre performance end hvis TCP skal retransmittere. Det er måske den feature jeg skal takke for at jeg opnår de 100Mbit/s i første omgang og 1Gbit/s når begge maskiner har det. Det er lidt vanskeligt at finde ud af hvilken performance jeg ville have fået uden back-pressure, da der ikke findes nogen mulighed for at konfigurere på disse switches.
Back-pressure er godt når der kun er et enkelt flow. Men når flere flows kombineres bliver det problematisk, og det er derfor back-pressure kun bruges på LAN og ikke over Internettet. Og det er der TCP er designet til at give god håndtering af congestion.
Jeg gætter på at TCP ville kunne opnå over 50% udnyttelse på et LAN uden back-pressure til at reducere pakketab.
Hvis det er et nogenlunde korrekt gæt ville det give et mål for hvornår back-pressure ikke længere er en god idé. Idet back-pressure presser et link under 50% udnyttelse, og der er nogle af de modtagne pakker på linket som skal sendes over udgående links uden congestion, så er back-pressure ikke længere løsningen men derimod problemet. Og switchen kunne i den situation opgive back-pressure og i stedet smide pakker væk. Og så længe et link modtager en betydelig procentdel af pakker som skal sendes over links uden congestion bør der ikke udøves back-pressure på det indgående link selvom nogle af pakkerne skal sendes på links med congestion.
Det er metoder som en switch kunne implementere udelukkende udfra lokale oplysninger. Da det ikke kræver koordinering med de andre enheder kan det altså implementeres uden det ville kræve tilføjelser til standarden.
Selektiv back-pressure ville selvfølgelig være endnu bedre, men kræver koordinering imellem switches, så det ville kræve en ny standard.
Jeg spekulerer så stadigvæk på om der findes nogle unmanaged gigabit switches som kan finde ud af at slå back-pressure fra når det begynder at forringe performance i stedet for at forbedre det.
Men jeg tror til gengæld godt at switches kan gøre lidt for at forhindre problemet uden at det kræver ændringer på standarden.
Grunden til at back-pressure blev introduceret var for at reducere mængden af pakketab og dermed opnå bedre performance end hvis TCP skal retransmittere. Det er måske den feature jeg skal takke for at jeg opnår de 100Mbit/s i første omgang og 1Gbit/s når begge maskiner har det. Det er lidt vanskeligt at finde ud af hvilken performance jeg ville have fået uden back-pressure, da der ikke findes nogen mulighed for at konfigurere på disse switches.
Back-pressure er godt når der kun er et enkelt flow. Men når flere flows kombineres bliver det problematisk, og det er derfor back-pressure kun bruges på LAN og ikke over Internettet. Og det er der TCP er designet til at give god håndtering af congestion.
Jeg gætter på at TCP ville kunne opnå over 50% udnyttelse på et LAN uden back-pressure til at reducere pakketab.
Hvis det er et nogenlunde korrekt gæt ville det give et mål for hvornår back-pressure ikke længere er en god idé. Idet back-pressure presser et link under 50% udnyttelse, og der er nogle af de modtagne pakker på linket som skal sendes over udgående links uden congestion, så er back-pressure ikke længere løsningen men derimod problemet. Og switchen kunne i den situation opgive back-pressure og i stedet smide pakker væk. Og så længe et link modtager en betydelig procentdel af pakker som skal sendes over links uden congestion bør der ikke udøves back-pressure på det indgående link selvom nogle af pakkerne skal sendes på links med congestion.
Det er metoder som en switch kunne implementere udelukkende udfra lokale oplysninger. Da det ikke kræver koordinering med de andre enheder kan det altså implementeres uden det ville kræve tilføjelser til standarden.
Selektiv back-pressure ville selvfølgelig være endnu bedre, men kræver koordinering imellem switches, så det ville kræve en ny standard.
Jeg spekulerer så stadigvæk på om der findes nogle unmanaged gigabit switches som kan finde ud af at slå back-pressure fra når det begynder at forringe performance i stedet for at forbedre det.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Hardware
Gå til bund