yoel caspersen blog bloghoved

Software-router del 3: Fantastiske Linux

Vi har nu haft vores setup med 2 stk. open source software-routere kørende i et godt stykke tid, og det er nu på tide at gøre status.

Den korte konklusion: Software-routing virker rigtig godt for en up-and-coming ISP.

De to routere har kørt uden nedbrud siden opstarten i december, og bortset fra en enkelt, træls bug i Quagga, har det til fulde levet op til mine forventninger. Som en ekstra bonus gav Linux-serveren mulighed for at køre OpenVPN, hvilket viste sig at være guld værd, da vi skulle binde to netværk sammen over internettet.

Da jeg byggede vores setup med 2 stk. BGP-routere baseret på Quagga og Ubuntu Linux, brugte jeg min hidtidige erfaring med Linux som netværksserver som grundlag. Linux er et godt og stabilt styresystem, og selv om netværksguruerne siger, at man ikke kan køre ISP-drift på software-routere, var jeg optimistisk, for jeg har tidligere opsat lignende systemer og har set, at man kan få et Linux-setup til at performe ganske hæderligt, hvis man ellers kender begrænsningerne.

Software-routerens akilleshæl

Begrænsningerne i en software-router kan koges ned til en eneste ting: Packets per second, eller PPS. Når en netværkspakke ankommer til routeren, skal den gennem netværksstakken, hvor kernen vil foretage et opslag i route-tabellen for at finde ud af, hvem den skal sendes videre til.

Lige netop dette opslag er en flaskehals: Da den store BGP-tabel indeholder lidt over en halv million rækker p.t., og route-opslaget skal bruge longest prefix match, er det en operation, der koster et større antal opslag i RAM. Hvert opslag kommer med en forsinkelse, og når man ganger denne forsinkelse med antallet af opslag pr. pakke, der skal routes, finder man ud af, hvor mange PPS en server kan håndtere i et worst case scenario.

I normal drift er det ikke et problem, for trafikken gennem serveren vil have en tendens til at gå til de samme dele af internettet, og serveren cacher hvert route-opslag. Desuden vil en gennemsnitlig pakke-størrelse ligge på lige omkring 1.500 bytes, hvilket giver et pænt throughput målt i Gbit/s.

Problemet kan opstå, hvis man bliver ramt af et DDoS-angreb, hvor routeren typisk vil modtage mange små datapakker. Typisk er angrebet dog rettet mod en enkelt kunde, så problemet kan håndteres - det vil være den samme IP-adresse, der skal slås op i route-tabellen hver gang, og den vil derfor ligge i route-cachen. Desuden vil man typisk null-route kundens IP-adresse, når angrebet opdages, så trafikken bliver afvist ved den første edge router, der modtager pakkerne fra angrebet.

Selve opsætningen af vores to routere forløb uden de store problemer, og hvad jeg i første omgang troede var en bug i Quagga, var blot et hul i min viden om dens konfiguration. Jeg havde uforvarende aktiveret en IPv6 neighbor under IPv4-konfigurationen, hvilket gjorde, at de to routere forsøgte at udveksle IPv6-routes over en IPv4 BGP-session. Da jeg deaktiverede den pågældende IPv6 neighbor under IPv4-konfigurationen, virkede alt som det skulle: IPv4-routes blev udvekslet via IPv4-sessionen og IPv6-routes blev udvekslet via IPv6-sessionen.

Da vi begyndte at koble vores bolignet-kunder på systemet, opdagede vi, at TDC på Post Danmarks vegne havde blacklisted vores IP scope. Det blev heldigvis løst, da vi fik identificeret problemet og fik fat i TDC.

GRE er smart, men kan ikke stå alene

I marts måned skulle vi binde vores nye eBSA-netværk sammen med resten af vores netværk. Der blev bestilt en sort fiber til formålet, men indtil den var på plads, måtte vi finde på en anden løsning. Den kom i form af en GRE-tunnel, så vi kunne binde de to netværk sammen hen over internettet.

Konceptet i GRE er simpelt: Man definerer en stateless tunnel fra A til B. Afsenderen pakker en IP-pakke ind i en GRE-pakke og sender dem afsted som en ny IP-pakke - heraf forkortelsen GRE: Generic Routing Encapsulation. Modtageren fisker den oprindelige IP-pakke ud af GRE-pakken og sender den videre, som om ingenting var hændt.

Problemet opstår, når GRE-pakkerne skal hen over internettet. På et lokalnetværk kan man ofte forvente, at der er support for IP-pakker, der er større end 1500 bytes, men det kan man ikke på internettet - her kan vi kun sende pakker på 1500 bytes. Når vi så pakker en IP-pakke ind i en GRE-pakke, der kun må fylde 1500 bytes inkl. ethernet header, må IP-pakken nødvendigvis være mindre end normalt.

Hvis vi modtager en IP-pakke, der er for stor til at passe ind i en GRE-pakke på 1500 bytes, vil den enten blive fragmenteret, dvs. splittet op i to dele, som sendes hver for sig, eller også vil den blive afvist, hvis afsenderen har sat DF-flaget (Don't fragment) på pakken.

Hvis pakkerne fragmenteres, falder ydelsen, da de skal samles igen hos modtageren, men hvis DF-flaget er sat, bliver pakken smidt væk, og der sendes en ICMP "Destination Unreachable, Fragmentation Needed"-pakke til afsenderen.

Ideen er så, at afsenderen skal sende pakken igen, men denne gang i en mindre størrelse, så den ikke bliver fragmenteret, eller uden DF-flaget, så routeren kan fragmentere pakken på afsenderens vegne. Dette koncept er også kendt som Path MTU Discovery.

Problemet opstår, når systemadministratorer konsekvent lukker for ICMP-trafik - så holder Path MTU Discovery op med at virke, og i vores case ville det betyde, at vores kunder ikke ville kunne komme ind på visse websites.

Det går ikke, så vi måtte finde en anden løsning - og løsningen blev en OpenVPN-tunnel, der selv fragmenterer pakkerne i den ene ende af tunnelen og samler dem igen i den anden ende. Processen er transparent set fra kundernes side, og det koster kun en smule CPU på vores router samt et øget båndbreddeforbrug på vores tunnel. Latency hen over tunnelen var 2 ms, så det var til at leve med.

VRF på Linux

I hardware-routere i ISP-klassen finder vi VRF, som står for Virtual Routing and Forwarding. Det er et koncept, der indebærer, at man kan lave et antal virtuelle routere inde i en enkelt fysisk router. Hver virtuel router, eller VRF-instans, har sin egen route-tabel og opfører sig, som om den ikke havde noget med resten af hardware-routeren at gøre. Det er smart, da man så kan forwarde trafik for flere netværk samtidig, uden at blande trafikken sammen.

Lad os tage et eksempel: Vi skal bygge to virtuelle routere, VRF1 og VRF2. VRF1 skal route mellem 10.0.0.0/24 og 10.0.1.0/24, mens VRF2 router mellem 192.168.0.0/24 og 192.168.1.0/24. Begge routere skal have deres egen default gateway, og vi anvender forskellige interfaces til hver VRF.

På Linux findes der to måder at implementere VRF.

Den ene metode er policy based routing - her kan man sætte nogle regler op, der afgør hvilken route-tabel, en pakke skal forwardes efter. Det fungerer, men det kan være relativt langhåret at sætte op, da man skal holde tungen lige i munden, når man definerer sine policies.

# VRF1
ip addr add 10.0.0.1/24 dev eth0
ip addr add 10.0.1.1/24 dev eth1
ip route add 10.0.0.0/24 dev eth0 table 1
ip route add 10.0.1.0/24 dev eth1 table 1
ip route add default via 10.0.0.254 table 1
 
# VRF2
ip addr add 192.168.0.1/24 dev eth2
ip addr add 192.168.1.1/24 dev eth3
ip route add 192.168.0.0/24 dev eth2 table 2
ip route add 192.168.1.0/24 dev eth3 table 2
ip route add default via 192.168.0.254 table 2
 
# Magic
ip rule add from 10.0.0.0/8 lookup 1
ip rule add from 192.168.0.0/16 lookup 2

En pænere løsning er at bruge Network Namespaces - et network namespace er en sandkasse, som kan bruges til at segmentere netværket på Linux-maskinen i flere uafhængige dele. Hvis et program på Linux køres i sit eget namespace, har det ikke adgang til noget netværk, medmindre man eksplicit definerer dette.

# Add namespaces for VRF instances
ip netns add vrf1
ip netns add vrf2
 
# Add loopback interfaces to VRF instances
ip netns exec vrf1 ip addr add 127.0.0.1/8 dev lo
ip netns exec vrf1 ip link set lo up
ip netns exec vrf2 ip addr add 127.0.0.1/8 dev lo
ip netns exec vrf2 ip link set lo up
 
# Move interfaces to VRF instances
ip link set eth0 netns vrf1 up
ip link set eth1 netns vrf1 up
ip link set eth2 netns vrf2 up
ip link set eth3 netns vrf2 up
 
# Add routes to VRF1
ip netns exec vrf1 ip addr add 10.0.0.1/24 dev eth0
ip netns exec vrf1 ip addr add 10.0.1.1/24 dev eth1
ip netns exec vrf1 ip route add default via 10.0.0.254
 
# Add routes to VRF2
ip netns exec vrf2 ip addr add 192.168.0.1/24 dev eth2
ip netns exec vrf2 ip addr add 192.168.1.1/24 dev eth3
ip netns exec vrf2 ip route add default via 192.168.0.254

Man kan flytte et fysisk interface på en Linux-server til et separat network namespace, og herved kan man i praksis opbygge en VRF-instans. En vigtig undtagelse, vi fandt, er dog, at man ikke kan flytte et tunnel-interface, der er oprettet af OpenVPN - så hvis man skal anvende sin OpenVPN-tunnel i et network namespace, skal tunnelen også startes her:

ip netns exec vrf1 /etc/init.d/openvpn start

Ligeledes kan ethvert andet program startes i et separat network namespace.

Er software-routing fremtiden?

Ja, til rigtig mange formål er det, og det er rigtig sundt at udfordre den traditionelle måde at tænke netværk på - selv Spotify forsøger at presse grænserne med deres spændende hybrid-setup, hvor den hårde del af packet-forwarding lægges i en billig switch, mens resten foregår i software.

For vores eget vedkommende er vi dog nået til et punkt, hvor vi skal håndtere trafik i en størrelsesorden, der ligger et godt stykke over, hvad vi har lyst til at udsætte vores software-routere for.

Empirien viser nemlig, at software-routing fungerer godt indtil ca. 10 Gbit/s, men når man kommer over dette, begynder vores setup at blive sårbart. Desuden forventer vi at skulle sælge trafik til andre ISP'er, der har en mere traditionel tilgang til tingene end vi selv har, og her vil et par hardware-routere give dem ro i maven.

Derfor har vi investeret i 2 stk. ZTE M9000 3E-routere, som er et par kraftige carrier grade hardware-routere.

Illustration: Privatfoto

I den konfiguration, vi har valgt, har hver router en kapacitet på 20 x 10 Gbit/s, og vi forventer, det holder et stykke tid endnu.

Det betyder ikke, at vi lægger software-routing på hylden, men det betyder, at vi kommer til at bruge det i sammenhænge, hvor mængden af trafik er begrænset til et niveau, hvor vores low-end Fujitsu-servere fint kan være med.

Kommentarer (44)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jn Madsen

Jeps,- BGP tables, det er altid værd at overveje, hvor og hvorfor man eventuelt behøver fulde BGP tables. Ofte er det kunden der ønsker det, hvis kunden kører med flere uplink ISP'er, og så er man nødt til at kunne levere. Ofte,- men stærkt afhængigt af design, kan man bruge Route Reflektorer som kører i baggrunden på små routere med lav throughput evne, men meget ram. Man skal huske, at Route Reflektoren jo slet ikke behøver at forwarde trafik selv.

DOS er og bliver noget ged,- der er masser af leverandører der vil sælge anti-DOS grej til ISP'erne, jeg har endnu ikke hørt om noget der bare virker. Alle i virker i en eller anden grad, og alt er rygende dyrt.

SDN bliver mere og mere spændende, men der er et stykke vej endnu :-)

  • 1
  • 0
#2 Yoel Caspersen Blogger

Ofte,- men stærkt afhængigt af design, kan man bruge Route Reflektorer som kører i baggrunden på små routere med lav throughput evne, men meget ram. Man skal huske, at Route Reflektoren jo slet ikke behøver at forwarde trafik selv.

Rygtet går, at det lige netop er her, at mange større ISP'er anvender en Linux-server med Quagga eller BIRD som BGP speaker. De vil dog næppe indrømme det, da det gør kunderne nervøse ;-)

Fun fact: Vores leverandør af wifi-routere påstår i øvrigt, at man kan køre Quagga på dem, hvis man har lyst. Throughput er næppe imponerende, men det ville kunne konkurrere med en mindre Mikrotik-box.

Alle i virker i en eller anden grad, og alt er rygende dyrt.

Og det er her, hybrid-løsninger som den fra Spotify kommer til sin ret. Uden ret meget ekstra besvær kan man offloade den tunge del af arbejdet med at route pakker til en billig switch, samtidig med at man har intelligensen i software.

Når vi vælger en "traditionel" carrier grade router fra ZTE med plads til den fulde BGP-tabel, skyldes det, at ZTE er voldsomt meget billigere end en tilsvarende Cisco eller Juniper - alternativet havde helt sikkert været en hybrid-løsning.

  • 1
  • 0
#3 Jn Madsen

Og det er her, hybrid-løsninger som den fra Spotify kommer til sin ret. Uden ret meget ekstra besvær kan man offloade den tunge del af arbejdet med at route pakker til en billig switch, samtidig med at man har intelligensen i software.

Som vi har sludret om før, Yoel, så er vi vist begge meget interesserede i SDN. Det er det alle roder med om 10-20 år. Som datacenter og L2 tech er SDN meget udviklet, og det bevæger sig mere og mere ind på L3, sikkerhed, VPN osv. Ting tager tid, og netværksverdenen er meget konservativ og lider af tryghedsnarkomani. Ikke uden grund.

  • 0
  • 0
#4 Poul-Henning Kamp Blogger

Når du ikke er transit router for ret meget, kan det normalt godt betale sig at lade en "route server" filterere BGP input før du sender det videre til dine traffic-routere.

Den halve million rækker kan koges ganske gevaldigt ned på den vis.

  • 3
  • 0
#5 Yoel Caspersen Blogger

Når du ikke er transit router for ret meget, kan det normalt godt betale sig at lade en "route server" filterere BGP input før du sender det videre til dine traffic-routere.

Den halve million rækker kan koges ganske gevaldigt ned på den vis.

Lad os antage, at vi kan aggregere routes, så routes til fx 185.107.12.0/24 og 185.107.13.0/24 kan erstattes af 185.107.12.0/23 - det giver en lossless komprimering, hvis next-hop for begge routes er den samme.

Men selv hvis vi kan halvere route-tabellens størrelse, er jeg i tvivl om, hvorvidt det vil gøre den store forskel for PPS på en software-router. Hvis route-tabellen bliver gemt i et binært træ, vil vi i worst case gå fra 19 opslag til 18 opslag, hvis vi halverer størrelsen på træet.

Vi skal derfor save betydeligt mere af route-tabellerne, hvis det rigtig skal batte - og jeg er i tvivl om, hvor meget vi kan opnå, hvis komprimeringen skal være lossless. Hvis vi kun har to udgående transit peers hjælper det på situationen, men jeg har ikke regnet på, hvordan en aggregeret route-tabel ville se ud - og det er i øvrigt heller ikke til at sige noget kvalificeret om, før man har de pågældende BGP sessions oppe at køre, da der kan være stor forskel på hvor direkte de to peers er forbundet til resten af nettet.

Hvis vi derimod accepterer et vist informationstab i vores komprimering, kan vi bygge en hybrid-løsning, hvor vi vedtager at læse de 10.000 vigtigste routes ind i en billig hardware-switch og bruge default-route for resten. Det er nok den økonomisk mest optimale model, men den kræver et vist vedligehold.

Poul-Henning - nu hvor du har vist verden, hvad Varnish kan gøre for webcaching, var det så ikke et oplagt projekt at udvikle en software-router, der kan holde route-tabellen i CPU-cachen og slå en fed streg over Ciscos og Junipers forretning? 10 Gbit/s kort og servere med mange CPU-kerner er jo billige hyldevarer i dag, så det eneste, vi mangler, er et stykke optimeret software til packet forwarding. Det er langt fra trivielt at udvikle, men potentialet er enormt.

  • 5
  • 0
#6 Jn Madsen

Det er her SDN begynder at stikke sit hovede frem,- hvorfor overhovede lade de trafik-bærende bokse have intelligens? Centrale servere som rådgivere til de "dumme" kasser,- i modsætning til de sidste 40 års design, hvor hver boks er autonom og selv-tænkene.

Det kommer, der er mange der arbejder på det, men det er helvedes indviklet. Det største problem er nok, at der i arbejdsgrupperne er medlemmer fra de store traditionelle leverandører. De har nok ikke alt for travlt med at vedtaget velfungerende standarter :-)

Yoel's konkrete problem er, at hvis han har en kunde der ønsker fuld routing tabel, så skal Yoel's peering router også have det.

  • 1
  • 0
#7 Baldur Norddahl

Et problem er overhovedet at få lov. I branchen er der en uvilje imod at tillade multihop BGP. Man forventer at BGP daemonen kører på samme hardware som står for at flytte pakkerne. Typisk begrundet med argumenter som at det garanterer hurtig responstid hvis linket går ned og BGP daemonen får direkte besked fra hardwaren om link down events. Man kan implementere BFD og få næsten samme responstid, men kun få udbydere tilbyder BFD.

Der er også nogle operationelle problemer. Tag en typisk IX hvor hver ISP har fået tildelt en IP adresse af IX. Det er meget sjældent at de giver dig to IP-adresser. Du er derfor nødt til at konfigurere din IP-adresse på din hardware switch. Din BGP server må få en anden IP adresse, typisk en af dine egne adresser. Din peer skal nu lave en BGP session til dig - men fordi der endnu ikke er en session, så er der ingen route til din BGP server der går via IX. I stedet vil trafikken gå via transit (dvs internettet generelt). Det er måske ikke en god ide at køre BGP trafik over internettet...

Så vi har brug for at transit udbydere og IX operatører ser lyset og implementerer løsning der er venlige overfor folk der ønsker at adskille router og BGP server.

Man KAN også lave nogle indviklede tricks, f.eks. med VRF, hvor man via en ACL regel får flyttet BGP over i en VRF, således at BGP serveren kan have samme IP adresse som routeren. Det er ikke brugervenligt. I en krisesituation er brugervenligt altid en fordel.

  • 2
  • 0
#8 Jn Madsen

Man forventer at BGP daemonen kører på samme hardware som står for at flytte pakkerne

Jeg er ikke sikker på at det er det man "vil have". Det er mere det design, man er endt med. Autonome routere. Typiske implementationer af BGP er "sløve", man ønsker ikke at BGP'en hopper og danser hver eneste gang et link lige slår en bøvs. "Helvedes hurtig" er normalt ikke ønskværdigt i BGP design.

Jeg er sikker på, at SDN grupperne (eller andre) kommer med nyt i den kommende tid (5-10 år) :-)

  • 1
  • 0
#9 Baldur Norddahl

Yoel's konkrete problem er, at hvis han har en kunde der ønsker fuld routing tabel, så skal Yoel's peering router også have det.

I det konkrete tilfælde er der ingen vej udenom. Hvis du giver din kunde en fuld routing tabel, så fortæller du ham også hvordan du har tænkt dig at route pakkerne. Så dur det ikke hvis dit netværk i praksis flytter pakkerne efter et andet system.

  • 1
  • 0
#10 Baldur Norddahl
  • 0
  • 0
#12 Baldur Norddahl

Jeg hører folk sige at 99% af ruterne forsvinder.

Der er en ugelig rapport over hvor meget man kan få ud af at aggregere routing tabellen: http://mailman.nanog.org/pipermail/nanog/2016-May/085639.html

BGP routing table entries examined: 593234 Prefixes after maximum aggregation (per Origin AS): 217584 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 290983

Det er den generiske algoritme der altid gælder. Herefter er der en mulighed for at slå routing entries sammen hvis de ligger i forlængelse af hinanden og har samme next-hop. Hvor meget du får ud af det afhænger af hvor mange peers du har - jo flere du har, jo mindre chance for at det er tilfældet.

Her spiller det imod at prefix length er meget varierende. Hvis du har en /19 og en /20 i forlængelse af hinanden med samme next hop efterfulgt af en /21 med en anden next hop, så kan du ikke slå noget sammen.

Jeg gætter på at du ikke kommer under 100k routes i bedste fald.

  • 1
  • 0
#13 Baldur Norddahl

Det skal i øvrigt bemærkes at det er præcis således det er implementeret i din "Carrier Grade" hardware box :-)

Det er iøvrigt ikke tilfældet. ZTE gemmer FIB i TCAM hukommelse: https://en.wikipedia.org/wiki/Content-addressable_memory#Ternary_CAMs

Der er plads til 2 millioner routes i FIB. Brugen af TCAM betyder at man kan lave opslag i FIB i konstant tid uanset antallet af routes.

  • 2
  • 0
#14 Jens Jönsson

Poul-Henning - nu hvor du har vist verden, hvad Varnish kan gøre for webcaching, var det så ikke et oplagt projekt at udvikle en software-router, der kan holde route-tabellen i CPU-cachen og slå en fed streg over Ciscos og Junipers forretning? 10 Gbit/s kort og servere med mange CPU-kerner er jo billige hyldevarer i dag, så det eneste, vi mangler, er et stykke optimeret software til packet forwarding. Det er langt fra trivielt at udvikle, men potentialet er enormt.

Det lyder da til at netop PHK måske kunne knække den nød, som Mikrotik kæmper med mht. multithreaded routing ?

Der er mange der ville sige tak og velkommen til en Open Source Router der kan laves af en dual processor PC m/10 Gbit/s netkort, og som så ville kunne flytte nogle små pakker i raketfart og håndtere fuld routingtabel etc. etc.....

  • 0
  • 0
#15 Jn Madsen

Sådan lidt uden for trådens oprindelige emne.

Jeg har set flere eksempler på refurbished udstyr. Hvis man kan leve med ikke at have sidste nye skrig,- så kan man lave rigtigt gode handler der.

Jeg har nogle venner der driver en mindre ISP virksomhed,- de indkøbte lige nogle glimrende Juniper kasser i SRX serien til omkring 30-40% af nypris. Måske ikke så fancy og på forkant med fremtiden,- men de leverer varen. "Get the job done". Kører nok de næste 10 år uden at bøvse.

  • 1
  • 0
#17 Jens Jönsson

Men pfSense som kører på sidste nye FreeBSD,- de skulle da netop kunne køre multithreaded,- eller er der noget jeg ikke fatter?

Næh, det er nok snarere mig der ikke er klar nok i spyttet. Det er vist nok multithreaded BGP, som der vist er udfordringer med i Mikrotik æsken, som er en prisbillig 10 Gbit/s router. http://www.stubarea51.com/2015/07/10/mikrotik-ccr1072-1g-8s-review-part-...

  • 0
  • 0
#18 Baldur Norddahl

Mikrotik bruger en langsom CPU der til gengæld har mange kerner (36 eller 72 kerner). Derfor har de brug for at kunne køre multithreaded. Hvis du bruger en PC så har du typisk en hurtig CPU med få kerner, hvorfor din BGP process er rimelig hurtig selvom den måtte være single threaded.

Problemet med routing er størrelsen på CPU cachen. Måske man kan lave et cache system hvor man flytter lidt rundt på hvad der er i cachen. Hvis pakken kan routes efter det der er i den aktuelt indlæste cache, så routes pakken. Ellers sættes den i kø indtil at den næste cache er indlæst. Ideen er så at man indlæser en cache, router alle de pakker der er i kø for denne cache, når køen er tom skifter man til næste cache og kø.

Hvis eksempelvis CPU cachen kan indeholde 1/4 af den globale routing tabel, så kan man have 4 køer. Du har en tråd der indlæser pakker fra netkortet og sætter dem i kø. Du kan nemt forudsige hvilken kø der er den rigtige. En anden tråd skifter rundt mellem caches og køer for at udføre routing algoritmen.

CPU cachen er hurtig nok til at du på den måde kan route med fuld hastighed også på 10+ Gbit/s.

Men vi mangler måske at overveje en enkelt egenskab ved den router Joel har købt. Den har 20x 10 Gbit/s. Det kan ingen PC løsning følge med til. Når man kommer op i de rigtig store båndbredder, så er der kun hardware løsninger der kan være med.

  • 2
  • 0
#19 Jn Madsen

Mikrotik æsken, som er en prisbillig 10 Gbit/s router.

Jeps, Mikrotik har et godt rygte, lidt bugs hist og pist, men der er mange der bruger dem. Jeg har lige stukket snuden i pfSense, glimrende gennemtestet produkt. Helt på høje med de dyre "købe-løsninger",- tror jeg.

Men vi mangler måske at overveje en enkelt egenskab ved den router Joel har købt

Det er den samme historie man hører igen og igen. Linux løsninger begynder at svede når hastighederne bliver store. Der er åbenbart nogle nødder der, man ikke kan få knækket. Måske SDN bliver nøddeknækkeren?

  • 0
  • 0
#21 Claus Andersen

Der er mange der ville sige tak og velkommen til en Open Source Router der kan laves af en dual processor PC m/10 Gbit/s netkort, og som så ville kunne flytte nogle små pakker i raketfart og håndtere fuld routingtabel etc. etc.....

De er der skam!

MikroTik RouterOS er baseret på en Linux kernel. Men som Baldur skriver længere nede, så har de en relativ langsom CPU, men rigtig mange kerner (på deres egen hardware). En af de nødder de så skal have knækket er at få det til at skalere lineært med antallet af kerner. Det er så en ikke helt triviel opgave. Det er hverken Linux eller FreeBSD der fejler noget. De er brugt i de underliggende systemer af mange af de "store" leverandører.

Modsat Yoel så var jeg nok ikke startet med en generisk distirbution som Ubuntu. Jeg forstår godt hvorfor han gjorde det: "The devil you know". Mængden af netværksoptimeringer og fejl man selv begår gør dog, at jeg hellere ville starte med en dedikeret distrubution.Lær af andres fejl og byg videre på dem.

Der er flere fine baseret på Linux, men da jeg selv er til FreeBSD, så ville mit valg være BSD Router Project

Deres test viser, at de skalerer rimeligt lineært til 4 kerner, men ser et dropoff på vej mod de 8. Men helt ringe er det nu ikke, da de kan få 10Mpps igennem på PC hardware. Er man interesseret i dette emne, så er deres performance sektion interessant læsning.

Skulle jeg starte min egen kælder ISP og har Carrier Grade drømme, så ville jeg starte der. Her vil fokus nemlig være på pris og performance. Skulle jeg lege "stor virksomhed" (som jo også starter i kældre! :-)), med de netværksbehov de har, så ville jeg nok istedet gå pfSense vejen. Her kan du være med på pris og features. Ikke at pfSense performer dårligt, men et spørgsmål om fokus.

Venligst, Claus

  • 1
  • 0
#22 Baldur Norddahl

Deres test viser, at de skalerer rimeligt lineært til 4 kerner, men ser et dropoff på vej mod de 8. Men helt ringe er det nu ikke, da de kan få 10Mpps igennem på PC hardware. Er man interesseret i dette emne, så er deres performance sektion interessant læsning.

Det ligner mere 2-4 Mpps medmindre man kører en eksperimentel branch med den helt rigtige hardware og flere tweaks. Jeg kan sige at det er rigtigt svært når man driver en ISP - kunderne har ingen forståelse for at de er nede fordi du lige skal tweake lidt :-).

Det er også ren forwarding performance med 2000 flows. Det kan være at der kommer et noget andet resultat ud hvis den skal håndtere en fuld routingtabel og et DDoS angreb med millioner af flows, eller bare normal drift også med fuld routingtabel og mangle flere flows.

Så selvom det ser positivt ud, så mener jeg ikke at ovenstående viser at det er en løsning der er klar til en ISP der har trafik i multi gigabit/s klassen.

  • 2
  • 0
#24 Yoel Caspersen Blogger

Mikrotik bruger en langsom CPU der til gengæld har mange kerner (36 eller 72 kerner). Derfor har de brug for at kunne køre multithreaded. Hvis du bruger en PC så har du typisk en hurtig CPU med få kerner, hvorfor din BGP process er rimelig hurtig selvom den måtte være single threaded.

Det er nok relevant at skelne kraftigt mellem selve BGP-processen (session-håndtering, beregning af routes m.v.) og så selve forwarding af packets ud fra de routes, der er installeret i FIB'en. I princippet er det tæt på ligegyldigt, hvor hurtigt BGP-processen kører, bare den er hurtig nok til at følge med de løbende opdateringer, der tikker ind. Det er mit indtryk, at Mikrotiks største problem er en sløv BGP-proces, men det er muligt, jeg tager fejl.

Hvis eksempelvis CPU cachen kan indeholde 1/4 af den globale routing tabel, så kan man have 4 køer. Du har en tråd der indlæser pakker fra netkortet og sætter dem i kø. Du kan nemt forudsige hvilken kø der er den rigtige. En anden tråd skifter rundt mellem caches og køer for at udføre routing algoritmen.

Se det er spændende tanker, du bringer til torvs her. Normalt vil RSS (Receive Side Scaling) forsøge at styre pakkerne ind i en given kø efter et 4-tuple hash - det har til formål at sørge for, at pakker tilhørende den samme session lander i den samme kø, så pakkerne ikke skal sorteres men kan bruges i den rækkefølge, de er ankommet.

På visse netkort kan man programmere RSS-filteret, så man fx udelader portnumre og udelukkende hasher på destinations-IP, men jeg ved ikke, om de er til at betale sig fra.

Jeg kan umiddelbart se to alternativer: Enten lader man RSS fordele pakkerne efter den normale algoritme, og selv fordele pakkerne på de rigtige CPU'er, som du foreslår, eller også må man bruge en zero-copy-driver a'la PF_RING og kode netværkslaget selv. Sidstnævnte er sandsynligvis det, der skal til, hvis det skal køre rigtig stærkt, men førstnævnte er nok nemmere at gå til.

Under alle omstændigheder bør man som det første slå irqbalance fra, når man kører high performance networking på en Linux-server. Herefter sætter man IRQ affinity, så hver rx- og tilhørende tx-kø på netkortet får tildelt en dedikeret CPU-kerne - så sparer man en del context switching.

Den har 20x 10 Gbit/s. Det kan ingen PC løsning følge med til.

Nej, ikke endnu, men tæt på. Jeg har et tilbud liggende fra Dell på en server, der skulle kunne håndtere 100 Gbit/s i sin backplane og har plads til 8 stk. Intel x520-kort, dvs. 16 x 10 Gbit/s i alt - og den er ikke urimeligt dyr.

Men man kan spørge sig selv, hvorfor det egentlig er nødvendigt med så høje båndbredder på en enkelt maskine. I en tidligere debat har der været argumenteret for, at det starter med fiberen - det er den dyre komponent, og derfor skal den være omgivet af high-performance hardware. Men denne hardware kan jo være en switch - hvis man opdeler trafikken i flere flows, kan der jo sagtens sidde mere end 1 software-router i hver ende af fiberen, så længe der er en kraftig (og billig) switch indimellem.

  • 2
  • 0
#25 Claus Andersen

ZTE E9000-3S har et backplane der klarer 1,2 Tbit/s. Det er bare ikke muligt med en PC løsning.

Backplanet er en seriøs vigtig pointe. Du har 100% ret.

Men har jeg har lidt en fornemmelse som når jeg stod nede i legetøjsbutikken. Min far sagde jeg måtte få en dims fra en af de nederste 2 hylder, men mit blik blev ved med at løbe op på de øverste hylder. Og det er jo sandheden om os drenge: Vi bliver ældre, og legetøjet større.

Ja - en ZTE E9000 er et lækkert stykke legetøj. Men hvad var behovet?

Disse blogindlæg har haft et teknisk fokus - hvilket jo er interessant i sig selv. Men det egentlige valg af en ZTE var jo ikke et teknisk funderet valg som sådan. Det er jo i højere grad en konstatering af, at tid er penge. Det er (formentligt!) mindre risikofyldt for Kviknet at benytte proven hardware med en til formålet optimeret software. Nu har de pengene til at kaste efter en ZTE, så derfor gør de det nu.

Men ud over "lækker" hardware, så leverer "de store" jo også gennemtestet software. Dette er jo også en væsentlig del af prisen.

Det vi desærre er kommet bort fra er, at det højeste antal pakker du kan nå at behandle er vigtigere end din båndbredde. Her oplever jeg lidt for megen viften med hånden. Køber man dyr dedikeret hardware følger der løfter omkring dette med. Men når man satser butikken på open source og hylde hardware, så er der kun anekdoter på nettet at støtte sig til. Det var her jeg gerne ville have haft guldkornene fra Yoel.

1) Erfaring over tid. Nu valgte han et generisk OS (Ubuntu) og smed pakker på. Føler han, at han over tid vandt ved det - eller ville han vælge en dedikeret distribution hvis han skulle prøve igen. 2) Hvilket reelt throughput fik han? 3) Og hvor mange pps blev der reelt skubbet igennem? 4) Implcit givet af ovenstående: Hvor stort et gap er der imellem det setup han lavede, og hvad de dedikerede distrubutioner praler med (10Mpps).

Dette er for mig vigtige datapunkter i forhold til hvor godt en PC baseret router kan fungere. Når vi har det på plads, så kan vi snakke om hvad trafik vi kan presse igennem på backplane (PCI bussen) - og om vi kan trylle med highend netkort. Hvor langt kan vi komme med en 4-ports adapter hvis vi ikke skal have pakkerne ned omkring PCI bussen?

Sidst følger så en interessant topologi diskussion. Det meste trafik skal de samme steder hen. PHK berører emnet, og Yoel medgiver, at man kunne bygge en billig løsning ved at smide 10.000 routes i switche. Og så er vi tilbage i pps og vedligehold. Hvor slem er den nu når det kommer til stykket?

Hvis man nu benytter exabgp til at omsætte BGP til noget der nemt at håndtere med et script. Så er det vel ikke den værste opgave at skrive et script der samler routes op for de mest interessante AS numre og pushe dem til dine switche? Senere kan man vel skrive et script der hjælper dig med at vælge de mest spændende AS numre fra den trafik der rent faktisk belaster din BGP router.

Jeg ved godt "bare lige" - men når vi nu er ude og lige ISP-on-a-shoestring :-)

Venligst, Claus

  • 0
  • 0
#26 Claus Andersen

Så selvom det ser positivt ud, så mener jeg ikke at ovenstående viser at det er en løsning der er klar til en ISP der har trafik i multi gigabit/s klassen.

Der er jeg langt mere enig end det måske så ud til.

Men Yoel startede med:

Den korte konklusion: Software-routing virker rigtig godt for en up-and-coming ISP.

Og hvis man læser det som fanden læser visse bøger, så er konstateringen jo: Det virkede perfekt, men så fik vi penge til det vi gerne ville istedet :-)

Gode datapunkter du kommer med. Og det ville være fedt hvis Yoel kunne be- eller afkræfte dette.

Udtrykket "Carrier Grade" er ikke kun fra marketingsafdelingen. Men hvor er breakpointet idag?

  • 0
  • 0
#27 Yoel Caspersen Blogger

Claus, jeg håber ikke, du er skuffet over os, fordi vi valgte at købe et par hardware-routere ;-)

Ja - en ZTE E9000 er et lækkert stykke legetøj. Men hvad var behovet?

Helt konkret:

  • Vi skal kunne forwarde op til 40 Gbit/s her og nu, på sigt betydeligt mere
  • Vi skal kunne overleve et DDoS-angreb
  • Det skal være muligt at sælge IP transit til andre internetudbydere
  • Vi vil gerne køre MPLS på vores netværk

Det kunne sagtens have været løst med en kreativ switch-løsning - men det ville tage en del tid, og tid er efterhånden min mest knappe ressource.

Den afgørende faktor er dog, at ZTE-løsningen ikke er voldsomt dyr, når man sammenligner den med en tilsvarende løsning fra Cisco, Juniper eller Brocade. Skulle vi have købt en af disse mærker, var det helt sikkert blevet en kreativ switch-løsning til en tiendedel af prisen.

1) Erfaring over tid. Nu valgte han et generisk OS (Ubuntu) og smed pakker på. Føler han, at han over tid vandt ved det - eller ville han vælge en dedikeret distribution hvis han skulle prøve igen.

Jeg har brugt minimal tid på opsætning og tuning af Ubuntu i dette projekt - jeg har arbejdet med en række andre projekter, hvor vi har optimeret en webserver langt ud over det rimelige, og det har resulteret i en fornuftig sysctl.conf-fil, som vi har kunnet genbruge. Derfor var jeg ikke så bange for at bruge Ubuntu, og jeg ville nok gøre det igen. Hvis ikke Brocade havde kvalt udviklingen i Vyatta, kunne jeg godt have overvejet denne, men ellers er det ikke mit indtryk, at en dedikeret distribution giver os nogen speciel fordel.

En vigtig flaskehals, vi fik elimineret fra starten pga. tidligere erfaringer med dette, var connection tracking. Det skal slås fra, da det dræber performance på en Linux-router.

2) Hvilket reelt throughput fik han?

Bortset fra en række uformelle, indledende tests har jeg ikke gennemført en formel benchmark af vores løsning, så her har jeg ingen relevante data at give - dette gælder også spørgsmål 3 og 4. Opgraderingen til hardware-routere skal således også ses som en proaktiv handling, der skal forhindre at vi rammer loftet og yder en dårlig service over for vores kunder, fordi vi ikke reagerede i tide.

Du skal se dette blogindlæg som et forsøg på at inspirere læserne til at turde tænke ud af boksen. Det er ikke en tutorial eller en benchmark - det er en opgave, mange andre har løftet bedre før mig. Jeg påstår heller ikke at have fundet de vises sten - men vi har brugt et setup, der har virket fint for os.

Og hvis man læser det som fanden læser visse bøger, så er konstateringen jo: Det virkede perfekt, men så fik vi penge til det vi gerne ville istedet :-)

Du kan også læse det som: Vi havde en fin løsning, men vi ved, den har et indbygget loft, som vi når før eller siden. Nu indfører vi et element i vores netværk, der gør at vi ikke behøver bekymre os om loftet det næste lange stykke tid.

Hvis du har en række konkrete tests, du gerne vil have udført på vores software-routere, må du sige til - så kan vi få nogle konkrete tal på bordet.

  • 3
  • 0
#28 Jn Madsen

Yoel

Der er intet nyt under solen,- alle starter med hjemmestrikkede ting eller gamle routere. På et tidspunkt slår man over på de kendte leverandører. De har rodet med det i 40 år,- og ved en del om det. Der er ikke andet hardware på markedet der sådan lige kan bruges (når der virkeligt skal sparkes r**). Netværks teknologi sætter nogle andre krav.

Ingen skade i det. Du får rigeligt brug for dine evner til finpudsning af databaser, overvågning, fejlanalyse værktøjer, automatisering osv osv. Det er faktisk der fårene bliver skilt fra bukkene. Kunne udvikle en effektiv forretning, der holder hvad den lover uden at varerne koster en millionmilliard.

Fidusen er at holde sig fra leverandør proprietære løsninger, så sidder man i saksen. Åbne standarter, gennemtænkt design og rettidig omhu er vejen frem.

Fede tråde du starter :-)

  • 3
  • 0
#29 Claus Andersen

Claus, jeg håber ikke, du er skuffet over os, fordi vi valgte at købe et par hardware-routere ;-)

Jeg er ikke et splitsekund i tvivl om, at det var det rette valg. Jeres forretning vokser, og den vigtigste ressource (din tid) er knap.

Og som Baldur vittigt kommenterede: Kunderne har ikke den helt samme forståelse for, at man lige skal tweak'e. Men jo - jeg er da skuffet :-)

Vi skal kunne overleve et DDoS-angreb

Det er her jeg sværmer om pps. Hvilket pps vil du kunne leve med?

(Og forstår fint hvis du undlader at svare for ikke at inspirere script kiddies)

så her har jeg ingen relevante data at give

Hele min pointe er, at det netop er det du har. Der er masser af blogs med tutorials skrevet af fra hinanden og syntetiske benchmarks. Du sidder med de virkelige data. Du har kørt produktion med boksene. Det jeg syntes er spændende er hvilket throughput (mbps) og routing kapacitet (pps) havde du i peak og gns.

Bsdrp kan f.eks. prale af syntetisk test med 10Mpps. Baldur kommer så med det yderst relevante datapunkt, at han i praksis ikke mener at man ser mere end 2-4 Mpps.

Jeg syntes derfor det er superspændende at vide hvordan det så ud for Jer. Måske har I ikke haft nok trafik, men ethvert tal vil være et godt datapunkt fra virkeligheden.

Altså ingen tests - blot hvad du så.

Du kan også læse det som:

Det var præcist sådan jeg læste det! Jeg udtrykte det blot langt mere provokerende. Og jeg er 100% enig i dit valg. Men du valgte en open source løsning i første omgang fordi den var billig. Dernæst håbede du på, at den kunne præstere godt nok. Dette er jo derfor kæmpe instpiration for andre. Det bliver nemmere for den næste, da han kan sige "Kviknet gjorde det", og det virkede fint for dem. Argumentet vil blot være endnu stærkere hvis man kunne sige "Kviknet gjorde det op til X pps".

Hvis du har en række konkrete tests, du gerne vil have udført på vores software-routere, må du sige til - så kan vi få nogle konkrete tal på bordet.

De kunne være sjovt at køre BoNeSi og se hvad setup'et kan klare. Men som du selv har konstateret, så er tid den knappe ressource. Men tak for tilbuddet!

Venligst, Claus

  • 2
  • 0
#31 Yoel Caspersen Blogger

Det er her jeg sværmer om pps. Hvilket pps vil du kunne leve med?

(Og forstår fint hvis du undlader at svare for ikke at inspirere script kiddies)

Det er et godt spørgsmål. Kan vi som ny udbyder på et mindre setup opnå 2 Mpps er det faktisk ikke helt skidt. Det vil betyde følgende båndbredder:

  • Ved 64 bytes pakker, worst case ved DDoS-angreb: ca. 1 Gbit/s
  • Ved 512 bytes pakker, normal drift: ca. 8 Gbit/s
  • Ved 1500 bytes pakker, best case: 24 Gbit/s

Jeg syntes derfor det er superspændende at vide hvordan det så ud for Jer. Måske har I ikke haft nok trafik, men ethvert tal vil være et godt datapunkt fra virkeligheden.

Vores udfordring er, at vi ikke har presset hardwaren på nuværende tidspunkt. Vores routere, som p.t. betjener en lille del af vores kunder, kører LACP bonding på 2 stk. 1 Gbit/s interfaces, hvilket giver et teoretisk max på 4 Gbit/s i alt. Valget stod derfor mellem at installere 10 Gbit/s interfaces (og ramme loftet inden så længe) eller gå direkte til hardware-router. Da vi står for at skulle flytte en stor del af kunderne over på vores eget netværk og øge datamængden betragteligt (op til 40 Gbit/s) var valget ligetil.

4 Gbit/s som ISP bør kunne opnås med det meste slags hardware under normal drift - ved en gennemsnitlig pakkestørrelse på 512 bytes giver det lige knap 1 Mpps.

Vi har måske været heldige, men vi har ikke set nogen DDoS-angreb, der har bragt vores system i knæ.

De kunne være sjovt at køre BoNeSi og se hvad setup'et kan klare. Men som du selv har konstateret, så er tid den knappe ressource. Men tak for tilbuddet!

Claus, jeg synes, vi skal se hvad vi kan få ud af en software-router under reelle forhold - mit indtryk er stadig, at man kan nå rigtig langt med en software-router, også selv om vi med vores moderate load ikke har ramt loftet endnu.

Når vi har flyttet kunderne væk fra vores software-routere og over på hardware-routerne, laver vi et test-setup, så vi kan få afklaret, hvor meget vi egentlig kan presse ud af hardwaren. Det sidste ord er ikke sagt i den sag ;-)

  • 2
  • 0
#32 Henrik Kramselund Jereminsen Blogger

Hvis nogen læser en masse PPS og der snakkes "et par millioner" og tænker om det er meget eller lidt. Så kan jeg til sammenligning fortælle at en Kali Linux på en ældre server med 10Gbit netkort kun skal bruge ca. 3 cores på at lave fuld wirespeed 14millioner pakker per sekund, pps. En mindre virtuel server som er hacket kan snildt producere 1 mill pps med DDoS lignende traffik. Så en angriber har relativt nemt ved at finde pakkekanoner.

Så, hvis man skal modstå DDoS skal man være lidt på tæerne, evt. interesserede kan se på min præsentation fra RIPE72 :-D

https://ripe72.ripe.net/wp-content/uploads/presentations/32-simulated-dd...

og hvis man er særligt interesseret kan man tage på BornHack og lege med DDoS værktøjer og routing - på et lukket segment :-D

  • 3
  • 0
#33 Yoel Caspersen Blogger

Så kan jeg til sammenligning fortælle at en Kali Linux på en ældre server med 10Gbit netkort kun skal bruge ca. 3 cores på at lave fuld wirespeed 14millioner pakker per sekund, pps.

Fed gennemgang du har lavet, Henrik.

Hvis vi deler vores udfordring med software-routere op i følgende to dele:

  • Modtag og send ved wirespeed
  • Opslag i route-tabellen

mener jeg, at du med dit setup har bevist, at den første del af udfordringen faktisk mere eller mindre er løst i dag. 14 Mpps ved 64 bytes pakker er lidt over 7 Gbit/s - hvilket er meget tæt på line rate, hvis vi bruger et 10 Gbit/s interface.

Og hvis vi skal have det til at gå endnu stærkere, skal vi måske kigge på ideerne i C10M challenge - måske kan vi opnå højere throughput, hvis vi bypasser kernen.

Så har vi den anden del af udfordringen - opslag i route-tabellen.

Spørgsmålet er, om ikke det problem reelt også er løst, i og med at et DDoS-angreb vil have et meget lille antal modtager-adresser, hvis prefixes fint kan ligge i route-cachen?

Det værste scenarie for en software-router er hvis mange kunder bag routeren deltager i hver deres DDoS-angreb og derved sender en myriade af udgående pakker til komplet forskellige destinationer. Det er et meget lidt sandsynligt scenarie, og skulle det ske, kan man lukke for de pågældende kunders internetadgang og derved bringe angrebene til ophør.

Så har vi diskussionen om, hvor meget data man egentlig kan få igennem en server, der agerer router. Nej, vi kommer ikke op på 200 Gbit/s med consumer hardware, men er det overhovedet nødvendigt? Vi kan parallellisere routing ved at aggregere de enkelte routeres kapacitet i en switch - så kan vi opnå både 10, 40 og 100 Gbit/s på en enkelt fiber. Det kræver dog, at modparten, vi peerer med, er indstillet på at deltage i legen - selv om porten er 100 Gbit/s, skal den bære fx 5 eller 10 P2P-forbindelser.

Der er ikke noget af det her, der er nemt - men jeg mener ikke, det er umuligt. Hvad mener du? ;-)

  • 0
  • 0
#34 Bent Jensen

Har lige skimtet hele tråden, men synes ikke det er nævt noget om strømforbrug ? Der er forskeld på at bruge 200 Kw til en lille hardware FW med indbyget VPN, eller op til 2000 Kw årligt til en server.

  • 0
  • 0
#36 Christian Nobel

Jeg har haft en Ubuntu 14.04 kørende som captive portal, og det har kørt pænt i ret lang tid, men her for et par dage siden, så blev den dræbende langsom.

Dhcpd'en stod i top for 85% af maskinens hukommelse - det viste sig at lease tabellen (som åbenbart loades i RAM) over tid var krøbet op til at fylde 2G!

Slettede tabellen og alt spillede igen - men er der andre der har oplevet det samme?

  • 0
  • 0
#37 Yoel Caspersen Blogger

Har lige skimtet hele tråden, men synes ikke det er nævt noget om strømforbrug ? Der er forskeld på at bruge 200 Kw til en lille hardware FW med indbyget VPN, eller op til 2000 Kw årligt til en server.

Nu mener du nok 200 kWh - og ja, hvis man måler pr. Gbit/s vil en software-router være dyrere i strøm.

En ZTE-router af den nævnte slags tager ca. 800 W, og var det ikke for vægten på ca. 45 kg ville den sandsynligvis lette, når den starter op og kører self-test på blæserne. Men den kan flytte 200 Gbit/s i vores konfiguration, og hvis vi skulle lave noget tilsvarende med software-routere, ville vi anslået skulle bruge 20 stk. lowend-servere eller 5 stk. highend-servere, dvs. ca. 4.000 W.

  • 1
  • 0
#38 Yoel Caspersen Blogger

Dhcpd'en stod i top for 85% af maskinens hukommelse - det viste sig at lease tabellen (som åbenbart loades i RAM) over tid var krøbet op til at fylde 2G!

Slettede tabellen og alt spillede igen - men er der andre der har oplevet det samme?

Er det ISC DHCP? Og er det nyeste version?

Jeg ved, der tidligere har været memory leaks, men det er ikke noget, vi selv har været plaget af. Hvis det ikke hjælper at opgradere, kan du jo prøve at kompilere den selv med passende debug-flag og køre den med valgrind - det bør afsløre memory leaks efter relativt kort tid.

  • 1
  • 0
#39 Christian Nobel

Er det ISC DHCP? Og er det nyeste version?

Ja, det er ISC - og ja nu er det nyeste version ;-D

Så det er meget muligt at jeg ikke løber ind i problemet mere, jeg var ikke klar over det før tabellen løb fuld, så nu vil jeg selvfølgelig holde øje med det.

Det der bare undrede mig var, at jeg prøvede at søge om andre havde oplevet noget tilsvarende uden at kunne finde andet end lidt vage kommentarer omkring memory leaks, men ikke ret konkret.

Problemet med søgemaskiner er selvfølgelig at de som regel er ret gode til at finde svar, men det kan være mega besværligt at stille spørgsmålet - derfor nysgerrigheden om der er andre der har oplevet noget tilsvarende.

  • 0
  • 0
#41 Baldur Norddahl

En ZTE-router af den nævnte slags tager ca. 800 W

Vores spiser noget mindre:

albertslund-edge1#show power   
[shelf 0 LCC]:  
Total power capacity   : 5350.50W   Total used power    : 313.00W  
Power type             : AC         Power group numbers : 2  
Power modules per group: 1          Division numbers    : 1  
Redundancy type        : 1+1         
   
Group A power capacity : 2675.50W  
Group B power capacity : 2675.00W  
Used power             : 312.99W  
   
Supply   Power  Power       Phy      Power    Com      Run  
Division Module Name        Status   Status   Status   Status  
0        A0     PPC34 A008  online   normal   normal   normal  
0        B0     PPC34 A008  online   normal   normal   normal  
   
Power  Power       Power     Output   Output  Power     Power     Software  
Module Temperature Capacity  Voltage  Current Alloted   Available Version  
A0     N/A         2675.50W  53.51V   2.83A   151.43W   2524.07W  V0.9  
B0     N/A         2675.00W  53.50V   3.02A   161.56W   2513.44W  V0.9
  • 1
  • 0
#42 Christian Nobel

Hvordan har du lavet din captive portal? Ikke at jeg tror det har noget med dit memory-problem at gøre, men det er altid spændende at høre, hvordan andre har grebet opgaven an.

Kort fortalt:

Jeg bruger IP tables, hvor en ny bruger så redirigeres til en aktiv side jeg har lavet i FreePascal (jeg laver alt i FreePascal, har efterhånden fået lavet et framework så jeg kan alt og mere til i sammenligning med PHP, men langt hurtigere og sikrere).

Her valideres password (som jeg bare har i en SQLite3 database, da der jo kun er mit program som klient - det fungerer upåklageligt), og hvis validering er ok indsættes hans MAC adresse i IP tables.

Så har jeg selvfølgelig også et administrationsmodul, hvor eksempelvis VPN klienter, som ikke umiddelbart må gå på fremmed net, og som derfor ikke kan fange port 80 på mit net, direkte kan oprettes i IP tables ud fra MAC navn.

Og så kører jeg et Cron job en gang i døgnet til at lave oprydning i IP tabeller og min klient database.

Det kører på en miniserver fra HP, og bortset fra DHCP sagen så triller det bare, typisk med et par hundrede brugere - men der har været underholdende læring undervejs, f.eks. det at æble klienter ikke kan gå på et åbent WiFi uden først at skulle snakke med Cupertino, så jeg har lavet en fast regel i IP-tables til Apples ET-phone-home side.

  • 2
  • 0
#44 Baldur Norddahl

Jeg tror ikke den bruger væsentligt mere bare fordi den skal flytte flere bits. Vores har ikke rigtig nogen varians i strømforbrug over døgnet. Der er ligefrem negativ korrelation da den af vores routere der flytter mest trafik lige nu bruger 10 watt mindre end den anden...

Det ser ud til at strømforsyningerne er voldsomt overdimensionerede. I en modul switch ser man det ofte fordi de skal kunne levere strøm til power over ethernet og hvis man fylder den op med PoE porte, så bliver det til en hel del. Men PoE giver ikke mening på en router i denne klasse, så jeg ved ikke helt.

En ZTE 5960-64DL kan flytte 1,3 Tbit/s med et maksimalt strømforbrug på 345W og typisk forbrug på 160W.

http://www.edgetech.lv/wp-content/uploads/2015/03/ZTE-ZXR10-5960-Series-...

  • 0
  • 0
Log ind eller Opret konto for at kommentere