yoel caspersen blog bloghoved

Software-routing i praksis - vores erfaringer

Det er nu næsten 3 år siden, vi hos Kviknet begyndte at anvende software-routing, og i dag vil jeg dele ud af vores praktiske driftserfaringer til inspiration for jer derude, der måtte gå med overvejelser om at give sig i kast med software-routing.

I starten brugte vi et par Linux-servere med Quagga som edge-routere med fuld BGP routing-tabel, men efter et halvt års tid udskiftede vi dem med hardware-routere i form af ZTE M9000.

Skiftet var primært motiveret af, at vi skulle bruge noget hardware med mange 10 Gbit/s porte og høj route-kapacitet, og desuden gjorde hardware-routerne det muligt for os at køre MPLS på vores netværk.

Software-routerne levede dog videre i form af CGN-routere, og undervejs er der kommet flere til.

Jeg har tidligere beskrevet, hvordan vi opnår redundans mellem vores CGN-routere ved at anvende dem i par, hvor den ene CGN-router vha. VRRP står klar til at tage over for den anden, hvis den skulle gå ned.

I den tid, vi har kørt med CGN-routere på Linux, har vi oplevet et enkelt crash på en CGN-router, der blev reddet af, at en anden CGN-router øjeblikkeligt overtog rollen.

I samme tidsrum har vi oplevet et sted mellem 5 og 10 crashes på vores ZTE M9000-routere, som har forårsaget en genstart af hardwaren, og konklusionen er derfor ret klar: Vores software-routere er langt mere stabile end vores hardware-routere.

Om konklusionen direkte kan overføres til andre netværk er usikkert, for der findes givetvis hardware-routere derude, som er mere stabile end ZTE's platform, og der kan være store forskelle på, hvordan netværket er konfigureret og dermed hvilke fejl, der udløses.

Lige for tiden er det store hit blandt netværksfolk Juniper, men jeg må blot konstatere, at en større underleverandør til Kviknet i august måned alene har udsat os for 3 regionale nedbrud, som alle kunne attribueres til fejl i deres Juniper-platform.

Man skal ikke lægge for meget i anekdotisk bevisførelse, men personligt har jeg ingen grund til at tro, at Junipers og ZTE's softwareudviklere er dygtigere end de udviklere, der står bag Linux-kernen, og en altoverskyggende fordel ved software-routere baseret på Linux er gennemsigtigheden - det er nemt at debugge, og når man finder en fejl, kan man rette den.

En hardware-router er derimod en black box med proprietær software, man som ejer af udstyret ikke kan undersøge i dybden. Man er derfor afhængig af dyre serviceaftaler hos producenten af hardware-routeren, og selv hvis routeren virker som den skal, må man som udgangspunkt gå ud fra, platformen er kompromitteret.

Historisk set har software-routerens svage side været antallet af pakker, der kan routes per sekund - men der er mange tegn på, at det problem så småt er ved at være løst.

Software-routing er splittet i to lejre - den ene lejr flytter software-routing ud af Linux-kernen og ind i dedikeret software baseret på bl.a. DPDK, mens den anden lejr optimerer Linux-kernen, så den kan følge med.

En særlig interessant variant af sidstnævnte finder vi i form af XDP, som vi lige nu er ved at undersøge mulighederne i.

Men hvad siger empirien - hvordan performer software-routere i praksis, når de udsættes for rigtige brugere og rigtig trafik?

Lad os se på et par grafer, der kan give os en del af svaret. Graferne dækker en enkelt CGN-router i tidsrummet fra 12. september 2018 kl. 06:00 til 13. september 2018 kl. 02:00.

CGN-routeren er en Fujitsu RX1330 M1 med 8 GB RAM, quad-core Intel Xeon E3-1220 v3 CPU samt et Intel x520-netkort med 2 stk. 10 Gbit/s porte, hvoraf den ene er koblet op til en ZTE M9000-router via et fiberkabel.

Illustration: Yoel Caspersen

Som det ses af ovenstående graf, flytter routeren 7,37 Gbit/s trafik ved peak, som typisk indtræder om aftenen mellem kl. 20 og 22.

En pakke fylder i gennemsnit lidt over 1000 bytes, og det ser ud til at være mere eller mindre konstant hen over døgnet:

Illustration: Yoel Caspersen

Derfor flytter Linux-kernen ca. 884.000 pakker hvert sekund ved peak:

Illustration: Yoel Caspersen

Det belaster CPU'en med ca. 40 %, der fordeles ligeligt over kernerne:

Illustration: Yoel Caspersen

Og ja, CPU utilization er en grov forsimpling.

Vi kan dog se, at CPU'ens strømforbrug og dermed temperaturen stiger nogenlunde proportionalt med mængden af trafik:

Illustration: Yoel Caspersen

Ovenstående grafer er et øjebliksbillede fra den rigtige verden - vores CGN-routere flytter IPv4-trafik, mens IPv6-trafik tager den direkte vej på nettet. Ca. 30 % af vores trafik er IPv6, og andelen er stigende.

Konklusionen på vores erfaringer er, at software-routing er kommet for at blive, og jeg vil ikke tøve et sekund med at anbefale andre at gå den vej.

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Baldur Norddahl

Det mest irriterende er at Linux mangler features. Normalt opfatter man Linux som værende platformen der har det hele, men har mangler der flere ting:

1) Der er reelt ingen MPLS support. Basal MPLS support blev indført med et lille patch for nogle år siden, men det er kun et proof of concept.

2) Som følge af #1 er der ingen support for L2VPN og L3VPN.

3) Håndtering af mange brugere med et VLAN per bruger i et Q-in-Q setup er ineffektivt, mangelfuldt og uhåndterligt. Selv hvis man i princippet kunne oprette tusinder af VLAN interfaces, så har ingen lyst til at manage en boks der kører på den måde.

4) Eksisterende og offentlige tilgængelige DHCP server og DHCP relay kan ikke håndtere interfaces uden IP adresse og kan ikke indsætte en brugbar option82 baseret på VLAN eller interface.

5) Svært at lave "supervlan" RFC3069.

Juniper har en BNG funktion, hvor routeren opsamler pakker med en ukendt VLAN kombination og herefter spørger en radius server om opsætning for denne VLAN kombination. Den slags er også svært at lave i en Linux løsning.

Det er lidt ærgerligt da Linux er en åbenlys løsning for mindre netværk (boligforeninger, WISP) eller ISP startups. Og hvis det kan skalere, så vil alene eksistensen af en Linux løsning, tvinge hardware producenterne til at prissætte lidt mere rimeligt.

Yoel Caspersen Blogger

1) Der er reelt ingen MPLS support. Basal MPLS support blev indført med et lille patch for nogle år siden, men det er kun et proof of concept.

2) Som følge af #1 er der ingen support for L2VPN og L3VPN.

Du har ret i, at der ikke umiddelbart er en fungerende MPLS-implementation på Linux p.t. Det skyldes umiddelbart, at udviklingen inden for software-routing primært finder sted inden for datacenter-miljøet, hvor SDN vinder frem.

Det der skal til, for at MPLS bliver understøttet, er at en stor ISP sætter et par dedikerede folk til at arbejde på sagen og deler resultatet med resten af verden.

Det ser ud som om, LDP et stykke hen ad vejen er understøttet:

https://frrouting.org/test-results/LDP_extended_results.pdf

LDP er selvfølgelig kun en del af ligningen - vi mangler også L2VPN og L3VPN, MPLS-TE osv.

Til gengæld er der (i princippet) ikke noget, der forhindrer os i selv at udvikle det. Hvis der er en bug eller en mangel i en Juniper-router, får vi ikke udleveret en kopi af kildekoden, så vi selv kan løse problemet.

3) Håndtering af mange brugere med et VLAN per bruger i et Q-in-Q setup er ineffektivt, mangelfuldt og uhåndterligt. Selv hvis man i princippet kunne oprette tusinder af VLAN interfaces, så har ingen lyst til at manage en boks der kører på den måde.

4) Eksisterende og offentlige tilgængelige DHCP server og DHCP relay kan ikke håndtere interfaces uden IP adresse og kan ikke indsætte en brugbar option baseret på VLAN eller interface.

5) Svært at lave "supervlan" RFC3069.

Kort sagt mangler der en BNG-funktion i Linux.

Jesper Brouer har klargjort nogle eksempler på XDP-kode, vi kan bruge til at udvikle de nødvendige features til super-VLAN. Det er umiddelbart ikke længere væk end en nyere Linux-kerne og et par regnvejrsdage med lidt C-kodning.

For den "almindelige" bruger, der ikke kan udvikle disse features selv, er Linux nok ikke det rigtige valg til alle dele af netværket - endnu. Men Linux er et oplagt valg til følgende dele af et bolignet eller en mindre ISP:

  • Edge-router (evt. med BGP i form af Quagga, FRRouting eller BIRD)
  • NAT-router/firewall
  • DHCP-server (ISC dhcpd eller Kea)

QinQ bliver først aktuelt når man kommer over 4.000 brugere pr. BNG, eller hvis man skal afvande eBSA eller FBSA fra TDC. Arbejder man ikke med eBSA eller FBSA, kan man komme rundt om problemerne ved at designe sit net efter det - isolering af kunderne på layer 2-niveau findes i mange billige layer 3-switches efterhånden.

Hvis man vil tildele faste IP-adresser til kunderne, og ikke har udstyr, der kan håndtere Option 82, kan man i yderste konsekvens gøre det ud fra MAC-adressen på CPE'en. Det er ikke specielt pænt, men det er præcis, hvad YouSee gør på deres coax-net i dag.

Baldur Norddahl

Linux BNG er der ikke endnu men Linux CGN er en anden historie. Her har Yoel fundet et sweet spot for Linux.

Hvis man vil køre CGN på sin router skal man købe et CGN kort til den. Det er sandt for Juniper, Cisco, ZTE og formodentlig de fleste andre. Det er dyrt. Derudover skal man typisk betale en per bruger licens. Derfor kan man udregne en pris per bruger.

Hvis selve BNG funktionen bliver ordnet af noget andet (hos Kviknet er det ZTE E9000 der laver BNG funktionen), så er det død simpelt at sætte Linux op til at udføre CGN. Det er i princippet bare en lille håndfuld iptables regler. Der er ikke noget med tusinder af interfaces eller andet uhåndterligt eller klodset opsætning.

En Linux server til 10.000 kr kan håndtere op imod 5.000 kunder. Det giver en pris per kunde på 2 kr. Det er 10 til 100 gange mindre end du betaler for en hardware løsning. Dertil kommer at du med en hardware løsning skal investere 100.000 kr eller mere bare for at komme i gang (uden redundans).

Det er helt ligetil at fordele kunderne på flere servere, ligesom der findes flere mulige løsninger for redundans. Løsningen skalerer perfekt.

Medmindre man absolut skal have alt inde i en boks der står Juniper eller Cisco på, så giver det simpelthen ikke økonomisk mening at købe hardware CGN.

Jens Jönsson

Som lille ISP benytter vi EdgeRouter Infinity fra UBNT.com. En 10 Gbit/s router baseret på Debian (https://help.ubnt.com/hc/en-us/articles/205202560-EdgeRouter-Add-Debian-...)

Vi har ikke pt. behov for den store avancerede MPLS løsning, til de funktioner vi bruger routererne til. Men til prisen er den ganske effektiv, den hoster aldrig.
Lidt "MPLS" kan den i form af VPLS og der udvikles løbende på EdgeOS, hvor mange bidrager med løsninger/patches, som man kan benytte, selvfølgelig hvis man tør.
F.eks. er der én der arbejder på at få VRF understøttelse.

Nuværende EdgeOS er v.1.10.6. EdgeOS v2.0 er i alpha (Upgraded base system to Debian-Stretch) og indeholder endnu flere funktioner, hvor community kommer med mange bidrag.

Derfor har vi ikke umiddelbart behov for selv at gå igang med software routere, da vi i EdgeRouter Infinity har en ganske kraftig æske, der for en skarp pris leverer den vare vi pt. har behov for, i den del af nettet vi benytter dem.
De er iøvrigt ekstremt stabile, og vi har kun haft bruge for at genstarte dem ifbm. ombygning af nettet (ikke nødvendigvis nødvendigt) eller ved firmware opgradering.

Benny Lyne Amorsen

Selv hvis man i princippet kunne oprette tusinder af VLAN interfaces, så har ingen lyst til at manage en boks der kører på den måde.

Jeg forstår stadig ikke denne modvilje mod mange interfaces. En Juniper-kasse har ligeså mange subinterfaces.

Juniper har en BNG funktion, hvor routeren opsamler pakker med en ukendt VLAN kombination og herefter spørger en radius server om opsætning for denne VLAN kombination. Den slags er også svært at lave i en Linux løsning.

Smæk en pcap op på hovedinterfacet, fang hver gang en DHCP-request kommer ind, hvis den kommer fra et subinterface som ikke er oprettet så send en RADIUS-request og opret subinterfacet.

Men ja, man får ingen MPLS. Man kan rimeligt nemt lave VRFlite, men rigtig tagged MPLS er ikke en realistisk mulighed.

Leif Neland

Du har tidligere skrevet om at i har en IPv6 tunnel til nogle brugere.

https://www.version2.dk/blog/oprop-derfor-skal-du-kraeve-ipv6-608409#com...

Er det muligt at bruge denne tunnel for andre?

Jeg har p.t. en IPv6 tunnel til HE, og jeg har så valgt at få tyske reklamer i stedet for svenske ;-)

HE har ikke en tunnel i DK, de nærmeste ender i Sverige og Tyskland.

Eller er der andre udbydere?

Jeg har et cronjob, der kører hvert halve år til at spørge Fibia hvornår de får IPv6, men det sker ikke foreløbig.

Log ind eller Opret konto for at kommentere