Open Source router

Det er længe siden, så mon ikke et kort blogindlæg er en god opstart efter sommer :-)

Emnet routere er ikke noget de fleste bekymrer sig om i hverdagen, det er noget man får fra sin internetudbyder og internet kommer ind der. De andre enheder i netværket lider ofte samme skæbne, når de virker skænker ingen dem en tanke ...

I denne uge skete der så noget som påvirkede netværket, faktisk hele internet, se Gamle routere med stopfyldt hukommelse sendte internettet til tælling . Det blev også diskuteret i Danmark, blandt andet folkene fra DKNOG der spurgte om danske virksomheder var påvirket direkte af dette. Det svar kan jeg ikke give, men jeg kan fortælle noget andet at det kan lade sig gøre at komme langt med en Open Source router.

En router idag har et antal interfaces, hvor Ethernet KLART er det mest benyttede, serielle forbindelser, token-ring og X.25 er heldigvis ikke noget de fleste bekymrer sig om. Det kan så være en blanding af standard Ethernet 1Gbit kobber (1000BASE-T), fiberporte hvor SFP+ er meget populært og enten 1Gbit eller 10Gbit - eller 100Gbit hvis man er Netflix. (Lad være med at nævne 10Gbit kobber Ethernet 10GBASE-T, så kaster jeg lidt op).

Hardwaren i en router i den høje ende er typisk en kombination af FPGA, ASICs og specieldesignede switch-boards - eksempelvis MX960 SCBE eksempel. Dette switchboard er et eksempel og har "160 Gbps/slot bandwidth with redundant fabric support" - nice. Det er ikke standardkomponenter når man taler om routere i den høje ende. Vi kan dog idag med eksempelvis Intel E5 og moderne netkort komme meget langt, og der findes gode specialnetkort - så hvor lang tid er der til vi kan erstatte den dyre specialrouters hardware med hyldevarer?

Softwaren på routere er idag oftest egenudviklet a la Cisco IOS Internet Operating System, eller en afart af noget Unix med services som OSPF og BGP lagt ovenpå. Det afvikles desværre ofte på noget relativt dårligt hardware routing engine, hvis man sammenligner med vores servere idag. Det kan vel til dels forklares med en længere udviklingstid og ønske om at holde det stabilt. Det er således ikke unormalt at finde CPU'er som er under eller omkring 1GHz plus/minus at disse kan være PowerPC eller andre arkitekturer. Ram er åbenbart også sindsygt dyrt at inkorporere på en router engine for disse er tit mindre end 4Gb. En tilfældig oversigt fra Juniper PTX serien findes på http://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/routing-engine-m-mx-t-series-specifications-by-model.html - lol 1GHz Pentium med 2Gb memory - dog op til 16/32Gb. PTX serien er en STOR model eksempelvis er PTX3000 en 22 RU router!

Så ideen kommer jo hurtigt, hvis det kører Unix og routing engine kører på noget basal CPU kan man så lave en open source router? Ideen har været bragt frem mange gange, men det bliver mere og mere nærliggende og igår stødte jeg igen på Jespers blog http://netoptimizer.blogspot.dk/ som viser hvad der sker når man presser citronen på PC server hardware med Linux. Det er kommet så langt at til setups med få porte, dvs ikke ISP service provider, men enterprise - kan man nok klare sig med en PC server med eksempelvis dual-port 10Gbit netkort til ~3.000kr stk.

Så kort fortalt, internet kører med gamle små routing engines men ved at skifte til Linux (el anden favorit Unix) kan man i det store hele få en router med +16Gb memory - som snildt kan behandle fuld routing tabel uden problemer i mange år. Vi har kunder som kører PFsense med den type setup, det virker. Så hvad er jeres årsag til IKKE at gøre det? Har I gjort det? Har I forkastet ideen?

Kommentarer (34)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anders Johansen

For år tilbage røg Zyxel på porten til fordel for et PFsense baseret setup. For en brøkdel af prisen i hardwareomkostninger outperformer de selv nogle forholdsvis store Zyxel kasser, og supporten (de sjældne gange den har været nødvendigt) har været langt bedre hos PFsense end hos Zyxel...

  • 7
  • 0
Niklas Pedersen

Jeg vedligeholder og administrerer en bird[1] BGP server for en dansk internet udbyder - det fungerer glimrende, så for vores vedkommende er vi allerede skiftet væk fra hardware routere.

Mest interessant er det at flere IXs viser interesse for bird og at den så vidt jeg husker allerede er i produktion brug @ LINX.

[1] - http://bird.network.cz/

  • 2
  • 0
Thue Kristensen

Så kort fortalt, internet kører med gamle små routing engines men ved at skifte til Linux (el anden favorit Unix) kan man i det store hele få en router med +16Gb memory

Bare lige for at være pedantisk, så går jeg ud fra at du faktisk mener 16GB, og ikke 2GB(=16Gb=16Gbit)?

Når vi nu taler om networking, hvor man hele tiden bruger enheden Gb og mener gigabit, så synes jeg det er vigtigt at bruge de rigtige enheder.

  • 3
  • 0
Ivan Skytte Jørgensen

Jeg skiftede til en linux-baseret router for mange år siden. Årsagen var at jeg blev træt at begrænsninger i min adsl-router (kun 8 port forwardings, forstod kun TCP og UDP, kunne ikke forwarde IPsec og protocol 41, elendig debugging, ingen VLAN-understøttelse...). Det har ganske vist kostet en del timer at konfigurere, men fordelene har været ret store i forhold til en black-box-router. Strømforbruget har dog været højere.

Jeg kan nemt forestille mig at man har tilsvarende fordele ved high-end router (jeg har kun brug for at route 100-200Mbps). Så medmindre man skal understøtte forældede protokoller (SPX, SNA, ...) så bør man seriøst overveje en unix-baseret router.

  • 1
  • 0
Keld Simonsen

Fordelen er vel også at software er open source. Dvs det er nok noget sikrere end Ciscos routere, hvor man har historier om at der er installeret overvågningshardware rutinemæssigt i tolden. Og vi véd ikke hvor mange huller der er i Ciscos software.

  • 1
  • 0
Anders Bruun Olsen

Jeg samlede mig for et par måneder siden en router selv. Det blev et mini-itx, dual-core Atom N525 board fra Jetway med 4gb RAM og et daughter board med ekstra netkort, således at der er 4stk 1gb/s porte at lege med. Det blev bestilt hos Logicsupply.eu og alt inkl. kostede det mig ca. 3500kr (kabinet og 30gb SSD fra en anden forhandler er også inkl. i den pris). Herpå er så installeret PFSense. Så kan mine to netforbindelser derhjemme (en ADSL og et kabelmodem) kombineres, således at båndbredden fra begge udnyttes, og når en af dem så er nede falder hastigheden bare lidt, men man har stadig en funktionel netforbindelse. Det har nu kørt i et par måneder, og har været klippestabilt, og meget nemt at tilpasse fx firewall regler. PFSense kan varmt anbefales!

  • 1
  • 0
Mogens Bluhme

På lag2 er der allerede nogle startups som Big Switch, Pica8 og Cumulus, som tilbyder white boxes eller bare metal ethernet switche. Mange producenter af chipset, f.eks. Broadcom har lagt en bootloader, ONIE ind, som kan boote det netværksoperativsystem, man ønsker via en SDN controller. Det eneste man skal have af software i chipsettet, er ONIE. Så kan man via en SDN controller opgradere, skifte NetOS og opgradere via denne controller, som bare er et stykke software, der kører på en x86-server. Og det ligger også i fremtiden at kunne blive protokolafhængig, f.eks. af Openflow. At integrere proprietær software i switche betyder at med ny funktionalitet skal man hurtigt ud og købe nyt - langsommelighed i udvikling, producenter tager en bondegård for dette. Faktisk har Software Defined Networking været undervejs i IETF siden 1995, men ikke før Openflow blev almindeligt udbredt,kom der gang i tingene. Det skyltes naturligvis, at brands som Juniper, HP og Cisco ikke har været interesseret i at fremme udvikling, da de så ikke kunne pelse deres kunder. Nu er ånden sluppet ud af flasken og det samme sker med routere men det tager tid fordi der er stærke kræfter, som vil modarbejde det.

  • 1
  • 0
Baldur Norddahl

Det svære ser ud til at være at håndtere mange pakker per sekund (pps) samtidig med at computeren har den store routingtabel (500k+ routes). Det er ikke CPU'en der er begrænsningen, men RAM båndbredde. Det tager lidt tid at slå op i den tabel og den er for stor til at ligge i CPU'ens cache.

Jeg kigger på en alternativ løsning, hvor vi vil bruge NEXT HOP attributten til at sende trafikken udenom serveren. Typisk får man en /30 (snakker IPv4 her) fra en transitudbyder. Det giver to IP-adresser, hvor den ene er deres router og den anden er din router. Hos Cogent fik vi dog muligheden for at få en /29 i stedet. Så er der plads til:

IP #1 deres router
IP #2 vores BGP talende server
IP #3 en relativt billig L3 10 Gbps switch

Ideen er så at serveren angiver switchens IP adresse som NEXT HOP. Trafikken fra upstream rammer så direkte ind i switchen udenom serveren. Switchen kan godt overskue vores begrænsede antal interne routes.

Det virker så kun for indadgående trafik. I vores tilfælde er det så også den vigtigste retning.

Vores switch kan håndtere 8k routes. Så udadående kunne vi indlæse top 8k routes og lade resten ramme serveren som en default route. Top 8k routes kan beregnes efter trafikmængde.

Så vi har en hardware switch til under 20.000 kroner der tager det største slæb og computeren klarer BGP + en lille del af den udgående trafik.

  • 2
  • 0
Henrik Kramshøj Blogger

Hvad er strømforbruget på en almen datamat med Linux i forhold til en specialbygget router?

Lidt forskelligt, hjemme bruger jeg en Soekris som ikke bruger mere end en "special router". Den kan gå op til nogle 100Mbit. En lille HP server som 320e med dual-port 10Gbit vil formentlig være i omegnen af en tilsvarende router fra Juniper.

Der findes en lille oversigt over en MX480 router - 8RU som kan klare ~2Tbit
http://www.juniper.net/documentation/en_US/release-independent/junos/top...

TL;DR tror ikke det er strømforbruget der gør udslaget

  • 1
  • 0
Morten Brørup

Almindelige routere er typisk opdelt i et dataplan og et kontrolplan.

Dataplanet sorterer og videresender datapakkerne ved bl.a. at slå modtageradressen op i en route-tabel. Dataplanet består typisk af en chip, hvor tabellerne ligger i en TCAM, der er meget hurtig til at finde det rigtige resultat i tabellen.

Kontrolplanet opdaterer dataplanets tabeller på basis af BGP og manuel konfiguration. Kontrolplanet består typisk af en CPU med RAM osv., der arbejder i samspil med nogle funktioner i chippen i dataplanet, så kontrol-pakkerne bliver sendt op til kontrolplanet for at blive behandlet her, i stedet for at blive sendt videre i dataplanet.

Som Baldur nævner, tager dataplanets opslag i tabellerne meget lang tid i en software-baseret ISP-router, hvor route-tabellen har 500.0000+ routes. Det er en af grundene til, at dataplanet i en softwarebaseret router slet ikke kan hamle op med et chipbaseret dataplan.

Hvis vi derimod taler om firewalls eller NAT-routere, er sagen en helt anden. Her er det ikke nok at slå nogle få informationer op i nogle tabeller, men her skal udføres en masse komplekse operationer på hver eneste pakke. Og så er software-baserede produkter på sin plads. Software er nemlig meget lettere at opdatere end chips.

Mht. strømforbrug kan jeg oplyse, at SmartShare 4000-serien, der er en mellemstørrelse software-baseret firewall med 250+250 Mbit/s real-life throughput (testet med 10.000+ samtidige brugere og blandede pakkestørrelser), kun bruger 35 W (fuldt belastet), så strømforbruget er i småtingsafdelingen for de fleste. Vores hardware er selvfølgelig specialbygget til formålet, men en almindelig PC-baseret firewall med samme throughput bruger nok omtrent det samme, hvis harddisken og graffikkortet sættes i dvale-tilstand.

Og endelig kommer mit svar på Henriks oprindelige spørgsmål:
1. I bunden af vores firewall-produkter ligger Linux og håndterer en stor del af dataplanet. Vi har masser af kunder (også ISP'er) til disse produkter, så brugen af open source routing er - i mine øjne - temmelig udbredt.
2. Bagsiden af medaljen er, at ikke en eneste kunde har købt en SmartShare-firewall, fordi den indeholder open source; men derimod fordi den har indbygget automatisk båndbreddestyring, der fordeler båndbredden og reducerer svartiden for kundens brugere. ;-)

mvh
Morten Brørup
CTO, SmartShare Systems

  • 4
  • 0
Morten Jagd Christensen

Jeg ser ingen performance relaterede grunde til ikke at lave en open source router på helt almindeligt hardware (med mindre man er Netflix).

Jeg har rigtig god erfaring med Intel's Data Plane Development Kit (DPDK) på Linux i kombination med all-Intel chipsets: Dual Xeon E5, 82599 2x10Gbit/s NICs, Cave /Coleto Creek coprocessors og Intel transceivers (giver mindst bøvl med DPDK).

Her har vi for eksempel 10Gbit/s på TCP mellem to 10G porte og blot 2 ud af i alt 32 hyperthreads. Vi har også set mere end 6M TCP connections/s og det er ikke langt fra wirespeed i pps.

En af serverne har 128G RAM så der er plads til de største routing tabeller hvis det skulle være.

Derfor kan der godt være strømforbrug, varme genererings, holdbarhedsmæssige, sourcing og andre grunde til ikke at gøre det, men performance er allerede nu ganske god og der er nyere og hurtigere NIC's og CPU'er på vej.

  • 1
  • 0
Baldur Norddahl

Her har vi for eksempel 10Gbit/s på TCP mellem to 10G porte og blot 2 ud af i alt 32 hyperthreads.

Det er bare ikke hvad en router laver. Serveren har DDR3 ram med omkring 10 ns latenstid: http://en.wikipedia.org/wiki/DDR3_SDRAM#Latencies

Det vil sige at CPU'en maksimalt kan hente data 100 millioner gange per sekund. Et binært træ med 500k elementer har en dybde på 19. Det giver så mulighed for at lave 5 millioner route opslag per sekund - teoretisk. Det giver maksimalt mulighed for at route 2,5 Gbps hvis du skal flytte 64 bytes pakker i forbindelse med et DoS angreb.

I praksis er det naturligvis meget mindre. CPU'en skal også bruge RAM til andet end at slå routes op. Jeg ser omkring 400 Kpps på en maskine med nævnte Intel netkort.

Flere kerner og tråde ændrer intet. Begrænsningen ligger i at bruges DRAM. Hardware switche og routere bruger noget specielt RAM kaldet TCAM http://en.wikipedia.org/wiki/Content-addressable_memory#Ternary_CAMs.

Jeg ved ikke om Intel netkortene har en smule TCAM, men de har helt sikkert ikke nok til at du kan indlæse en routingtabel direkte i netkortet.

Det kunne være spændene hvis nogen udviklede et PCI kort med TCAM for at løse det problem.

  • 3
  • 0
Morten Jagd Christensen

Nej jeg er klar over at en router laver noget andet, men så væsensforskelligt er det ikke: Der modtages en pakke på en port, udfra headeren skal der slås et element op i en 'tabel' og udfra det element skal der findes en output port, så skal der modificeres lidt i IP headeren, og skiftes mac adresse og beregnes checksum.

Det er stort set de samme operationer der skal til for at servicere en tcp pakke på klient/server siden.

Xeon E5 har 20M L3 cache og benytter RSS til at reducere dybden af søgetræet, og netop fordi CPU'en også laver andre ting har flere cores en positiv indflydelse på performance.

Så jo der kan sagtens pines mere ud end de tal du nævner - også teoretisk.

Men det var nu også mest for at gøre lidt reklame for DPDK som er en meget interessant ny(ere) spiller på pakke processerings arenaen, nu da bloggeren spørger.

Så hvis man er nysgerrig så besøg https://www.dpdk.org

  • 0
  • 0
Henrik Kramshøj Blogger

Fede indlæg der kommer, allesammen. Jeg leger selv primært med DPDK til scannere og pakkegenerator delene - DDoS test af udstyr :-D

@baldur, snakken om TCAM bliver meget cisco centreret - Juniper bruger en anden strategi med reduced- latency dynamic random access memory (RLDRAM) i deres "lookup block" del af chippen. http://juniper.cluepon.net/index.php/Trio_architecture fortæller lidt om deres chips.

Blandt andet fik jeg slået op i OReilly Juniper MX Series bogen og som jeg forstår det er de gået væk fra TCAM på kortene, fordi det blev for begrænsende, de skriver:

Simple Filter
Simple filters are available to provide some level of filtering support on FPCs that use commercial off-the-shelf (COTS) TCAM for firewall structures, namely IQ2 PICs and the MX’s EQ-DPC, both of which are based on the EZChip. Simple filters aredefinedatthe[set firewall family inet simple-filter]hierarchy.Thereare many restrictions to this type of filter because existing Junos match conditions were deemed too demanding for a TCAM-based engine; combined with their support on a limited and now long in the tooth hardware set, this explains why simple filters are rarely used.

Juniper har så også tradition for at lave ASICs til IP processing - og havde vist som de første IPv6 i hardware med i-chip - fandt ikke lige reference til dette, men jeg fandt forøvrigt This work presents the VHDL design of the IPv6 datagram processing module.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6... - lyder spændende, hvis man havde tid til NetFPGA osv.

Så opsummeret:

  • er glad for at høre I bruger Open Source routere
  • DPDK+Intel E5+intel netkort kan en masse spændende, måske nemmere at komme igang med end FPGA, men FPGA er også på vej til at blive hvermands eje
  • Linux kan beskytte imod ca. 5.5 mill pps på en server, se Jesper Brouers slides
  • Forwarding kræver hurtig RAM, men ikke nødvendigvis TCAM space

PS DPDK har ikke https, men prøv http://www.dpdk.org

  • 2
  • 0
Baldur Norddahl

Vi bruger to Linux servere som routere hos Gigabit. Jeg ser det ikke som den endelige løsning, men som et skridt henimod noget mere skalerbart.

De to maskiner er identiske. Fra "lshw":

           *-network  
                description: Ethernet interface  
                product: Ethernet Controller 10-Gigabit X540-AT2  
                vendor: Intel Corporation  
                physical id: 0  
                bus info: pci@0000:01:00.0  
                logical name: eth2  
                version: 01  
                serial: a0:36:9f:1a:55:40  
                capacity: 1Gbit/s  
                width: 64 bits  
                clock: 33MHz  
                capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 100bt-fd 1000bt-fd autonegotiation  
                configuration: autonegotiation=on broadcast=yes driver=ixgbe driverversion=3.13.10-k duplex=full firmware=0x8000037c latency=0 link=yes multicast=yes port=twisted pair  
                resources: irq:24 memory:d0000000-d01fffff memory:d0200000-d0203fff memory:d0280000-d02fffff memory:d0c00000-d0cfffff memory:d0d00000-d0dfffff  
           *-network:0  
                description: Ethernet interface  
                product: 82599ES 10-Gigabit SFI/SFP+ Network Connection  
                vendor: Intel Corporation  
                physical id: 0  
                bus info: pci@0000:07:00.0  
                logical name: eth3  
                version: 01  
                serial: 90:e2:ba:5c:c6:50  
                capacity: 1Gbit/s  
                width: 64 bits  
                clock: 33MHz  
                capabilities: pm msi msix pciexpress bus_master cap_list ethernet physical fibre 1000bt-fd autonegotiation  
                configuration: autonegotiation=on broadcast=yes driver=ixgbe driverversion=3.13.10-k duplex=full firmware=0x61c10001 latency=0 link=yes multicast=yes port=fibre  
                resources: irq:32 memory:d0480000-d04fffff ioport:c020(size=32) memory:d0504000-d0507fff memory:d0800000-d08fffff memory:d0900000-d09fffff  
   
     *-cpu  
          description: CPU  
          product: AMD FX(tm)-8350 Eight-Core Processor

De to maskiner er forbundet direkte til hinanden med 10 Gbps på eth2. De kører BIRD og står for at route til henholdsvis TDC og Cogent.

Den store routingtabel:

baldur@ballerup1:~$ ip route show | wc -l  
501224

Interesserede kan lave en simpel hastighedstest med følgende kommandoer:

wget http://ballerup1.gigabit.dk/10g -O /dev/null  
wget http://ballerup2.gigabit.dk/10g -O /dev/null

Afhængig om du rammer os igennem TDC eller Cogent, så vil den ene maskine levere direkte og den anden maskine vil route via den første maskine. Så man kan direkte sammenligne effekten af pakkerne bliver routet.

Det giver naturligvis mest mening at køre testen hvis man har adgang til 10 Gbps.

Vi fik nogle venner til at køre wget for os. De får 6 Gbps når trafikken kommer direkte fra serveren og 4 Gbps når det bliver routet. Det er ikke helt optimalt - men brugbart i vores nuværende stadie.

  • 2
  • 0
Jens Jönsson

Jeg kan kun anbefale EdgeMax produktserien. Vi benytter dem og f.eks. EdgeRouter Pro kan du selv sætte mere RAM i, så der er plads til BGP tabellen.

Softwaren er under løbende udvikling (Jeg venter på VRF-lite) og bliver primært opdateret med ønsker fra kunderne.
Stabiliteten er rigtig god. Nogle af vores har snurret uden problemer i over 1 år.

Jeg foreslog i øvrigt UBNT at lave EdgeRouter PoE modellen. Som tak modtog jeg ét af de første eksemplarer :-)

  • 1
  • 0
Rune Larsen

Det vil sige at CPU'en maksimalt kan hente data 100 millioner gange per sekund. Et binært træ med 500k elementer har en dybde på 19. Det giver så mulighed for at lave 5 millioner route opslag per sekund - teoretisk. Det giver maksimalt mulighed for at route 2,5 Gbps hvis du skal flytte 64 bytes pakker i forbindelse med et DoS angreb.

I praksis er det naturligvis meget mindre. CPU'en skal også bruge RAM til andet end at slå routes op. Jeg ser omkring 400 Kpps på en maskine med nævnte Intel netkort.


Baldur, på mellemstørrelse og større servere har processerne typisk hver deres dedikerede RAM-controller med egen RAM tilknyttet. Hvis man ikke respekterer dette, så rammer man nemt flaskehalse, når en processor skal tilgå RAM fra en anden processers RAM-controller. NUMA bruges til at styre affinity mellem processer og RAM.

I øvrigt ville mindst de 10 første niveauer af dit binære træ jo nok være cachet :-)

I øvrigt smart metode med at kombinere hardware-routeren til de mest populære routes med software til resten.

  • 0
  • 0
Baldur Norddahl

Jeg er ikke i tvivl om at man kunne gøre meget for at optimere en PC-router. Men jeg har mine tvivl om hvorvidt Linux-kernen i praksis udnytter de muligheder.

Min erfaring indtil nu er at man måske kan få noget der performer. Men du kaster dig ud i et ikke-trivielt projekt, som det bagefter er meget svært at røre ved. Jeg har f.eks. svært ved at afprøve noget som helst på mine to BGP routere (ballerup1/ballerup2) da de altså er i produktion. De er no-touch. Jeg lægger dem ikke lige ned, for at teste om noget hjemmebryg på DPDK kunne være bedre, om en ny kerne er en forbedring eller (gys) forværring.

At lave et test setup er hverken billigt eller trivielt.

Lige nu sider jeg med et rigtigt godt tilbud på en M6000-S router fra ZTE og overvejer om det er tiden og risikoen værd at kæmpe videre med en Linux-løsning. Jeg tænker at jeg vil beholde min Linux-router som backup-router, for at skabe noget redundans til hardware routeren.

  • 0
  • 0
Nikolaj Brinch Jørgensen

Vi fik nogle venner til at køre wget for os. De får 6 Gbps når trafikken kommer direkte fra serveren og 4 Gbps når det bliver routet. Det er ikke helt optimalt - men brugbart i vores nuværende stadie.


Hej Baldur,

Et spørgsmål. Hvad betyder dette så når du har f.eks. 100 kunder som har 1000/1000. Vil de så opleve problemer i forhold til den indkøbte hastighed, fordi routerne ikke kan følge med?
Er 1000/1000 så den teoretiske hastighed, som man aldrig i praksis vil opnå, da routerne har for travlt?

Eller hænger routerens performance ikke sammen med wirespeed?

  • 0
  • 0
Baldur Norddahl

Nikolaj, serverne leverer jo fint 1 Gbps - faktisk levere de jo mindst 4 Gbps i test (og det er oveni vores normale trafik). Jeg er lidt i tvivl om hvor godt de performer hvis det er små pakker i forbindelse med et DoS angreb, men det er heldigvis ikke noget vi oplever hver dag endnu.

Indtil videre passer det med at en bruger øger belastningen på nettet med cirka 1 Mbps. Der skal altså pænt mange brugere til, før at vi har et reelt problem. At brugerne har adgang til 1000/1000 betyder ikke noget særligt - forbruget jævner sig ud alligevel. Der skal bare være "luft" på mindst 1 Gbps over det normalle forbrug og det er der.

  • 2
  • 0
Henrik Kramshøj Blogger

Nikolaj, serverne leverer jo fint 1 Gbps - faktisk levere de jo mindst 4 Gbps i test (og det er oveni vores normale trafik). Jeg er lidt i tvivl om hvor godt de performer hvis det er små pakker i forbindelse med et DoS angreb, men det er heldigvis ikke noget vi oplever hver dag endnu.

Du siger bare til ;-D

Vi har udstyr som vi bruger til DDoS test af kunder, og da vi har både TDC og Cogent vil vi formentlig kunne teste dig med et par mill pakker efter dit eget ønske, eller et mix. Vi bruger standard Kali Linux på E5 blade 26xxsomething og Intel netkort, t50, pktgen m.fl. er vilde pakke generatorer, plus tips fra Jespers Netoptimizers blog, masscan og andre tools hjemmesider. Se eksempelvis https://github.com/robertdavidgraham/masscan http://t50.sourceforge.net/ http://netoptimizer.blogspot.dk/2014/06/pktgen-for-network-overload-test...

Vi har faktisk en NWWC planlagt her i august, og du skal være velkommen til at kigge ud et par timer, evt. v nattetide - så kan vi smide lidt pakker mod dit netværk udefra. Se mere på http://NWWC.dk - gælder også jer andre, men tilmelding nødvendig.

  • 0
  • 0
Baldur Norddahl

Hermed en beskrivelse af en redundant load-balanced open source router med ekstern hardware acceleration:

Hardwaren består af to ZTE 5952E switche og 2 servere. Serverne har et Intel netkort med 2 porte.

ZTE switchen er en modulswitch der koster cirka 14.000 kroner. Et modul med 4x 10 Gbps koster cirka 3.500 kroner og der kan være op til 20x 10 Gbps i switchen. Det er en layer 3 switch, der kan klare op til 9000 dynamiske routes. Den kan derudover køre MPLS.

Jeg beskriver her en enkelt transitprovider/peer men der skal naturligvis være 2 eller flere for at det giver mening. Jeg beskriver også kun en enkelt switch - den anden er kun nødvendig hvis man vil have redundans.

Transitprovideren har oprettet et /30 subnet til BGP. Der køres med fuld routingtabel:

192.0.2.1/30 Transitproviderens router
192.0.2.2/30 Vores BGP router

Vi laver IKKE det /30 subnet vi har fået tildelt. I stedet laves der to /32 statiske routes, der peger på henholdsvis 192.0.2.1/32 på transitproviderens port og 192.0.2.1/32 på serverens port. Vi enabler endvidere proxy-arp på transitproviderporten.

Proxy-arp er en funktion, hvor switchen ved modtagelser af ARP "WHO-IS" pakker, tjekker om der findes en route på en anden port. Hvis det er tilfældet, så vil switchen udgive sig for at være destinationen og svare tilbage med dens egen MAC-adresse. Når transitproviderens router spørger efter 192.0.2.2 så vil switchen svare at det er den selv. Dermed kan der kommunikeres mellem 192.0.2.1 og 192.0.2.2 selvom de ikke er på det samme broadcast domæne.

Proxy-arp muliggør at der kan etableres en BGP session. Du kan selv vælge en BGP daemon - vi bruger BIRD.

Herefter begynder der at komme trafik ind fra internettet. Set fra transitudbyderens synsvinkel, så router han det til 192.0.2.2, som på grund af proxy-arp er ZTE switchens MAC-adresse. ZTE-switchen samler trafikken op. Og nu sker det spændende: ZTE switchen router trafikken baseret på dens egen routing-tabel i stedet for at aflevere det til Linux serveren. Vores BGP server bliver altså ikke belastet af at skulle håndtere inbound trafik.

Det kan man bruge til en masse. Der er ingen tvivl om at ZTE switchen kan route trafikken med line-speed - også selvom det er DoS trafik med små pakker. Hvis du har en cluster med webservere, så kan du bruge equal cost muliple path routing, til at lade ZTE switchen load balance trafikken direkte til dine webservere.

Hvis inbound trafik er din primære trafik, f.eks. fordi du er en lille internetudbyder, så behøver din BGP server end ikke at have et 10 Gbps netkort.

Du kan også bruge ACL til at fjerne UDP og rate-limite andet typisk DoS trafik, så at du har din grovsortering i hardware.

Du får redundans og automatisk failover ved at bruge OSPF til at distribuere dine interne routes.

Nu til den svære del: outbound trafik.

Din BGP server annoncerer en default route ud med OSPF. ZTE switchen ved derfra at den skal aflevere outbound trafik hos BGP serveren. Hvis du har to (eller flere) BGP servere, så kan du igen bruge equal cost multiple path routing til at fordele trafikken på dem begge.

BGP serveren har den store routingtabel og finder ud af om trafikken skal sendes til transitprovider1, transitprovider2 eller transitproviderN. Problemet er at når den har fundet ud af det, så skal trafikken sendes tilbage til ZTE switchen, så den kan aflevere det til transitprovideren. Men ZTE switchen vil route trafikken ifølge dens egen routingtabel, hvor der er en default route der sender trafikken lige tilbage til din BGP server.

Så hvordan afleverer vi outbound trafik?

Vi enabler MPLS på switchen. Med MPLS kan man opsætte en LSP tunnel (manuelt). Du siger at når ZTE switchen modtager en pakke med label A fra BGP serveren, så skal label A fjernes og trafikken sendes til next-hop 192.0.2.1. Dermed forsøger switchen ikke lave layer 3 routing på egen hånd. Den følger bare kommandoen fra Linux serveren.

Vi skal simpelt bare lave en label per transit/peer vi har.

Det er vist endnu ikke helt afgjort hvor mange pakker per sekund en Linux server med stor tabel kan håndtere. Men med ovenstående er det kun et spørgsmål om hvor mange servere du skal købe. Der er ikke nogen øvre grænse for hvor mange servere, du kan have til at sætte labels på dine pakker. Principielt kan du lade dine webservere gøre det direkte.

Et basalt setup bestående af én ZTE switch, med 4x 10 Gbps porte og én Linux server koster mindre end 25.000 kroner. Det synes ganske rimeligt, til f.eks. et bolignetværk, hvor dette vil kunne route alt indgående trafik i hardware.

Der er kun et mindre problem: Der er ingen MPLS support i Linux.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize