yoel caspersen blog bloghoved

Genoplivning for begyndere

Af 25

Da vi overtog driften af vores første bolignet for snart 2 år siden, var den overordnede opgave at forvandle et døende bolignet med vigende opbakning til en god forretning med et stærkt produkt og loyale kunder.

Boligforeningen havde etableret netværket i midten af 0'erne, og som beboer i boligforeningen betalte man et obligatorisk netbidrag, der gav adgang til en basal internetforbindelse på under 128 Kbit/s samt en analog telefonlinie. Eksterne samtaler var ikke inkluderet i netbidraget, men da boligforeningen tidligere havde investeret i et IP-telefonsystem, var opkald "ud i byen" relativt billige.

Mod merbetaling kunne man tilkøbe en højere hastighed på sin internetforbindelse, faktisk helt op til 40 Mbit/s.

Teknikken bag

Selve netværket bestod af 22 fysiske krydsfelter, der var placeret strategisk rundt omkring i boligforeningen og forbundet til et hovedkrydsfelt via 1 Gbit/s multimode fiber i en stjernestruktur. Hvert krydsfelt var udstyret med en HP 5304xl access switch, der samtidig fungerede som router.

Den enkelte access switch betjente et sted mellem 24 og 48 beboere på 100 Mbit/s porte, der var koblet op til switchen via PDS. Hver beboer havde sit eget VLAN og et tilhørende /29 IP scope, der gav dem mulighed for at tilslutte en switch direkte til PDS-udtaget i lejligheden og tilslutte op til 5 samtidige enheder.

IP-adresserne var RFC 1918-adresser, også kendt som private IP-adresser, og access switchene og core routeren udvekslede routes via RIP. Core routeren var en HP 5308xl routing switch, der var koblet op til en Linux-server, der fungerede som NAT-firewall og styrede den enkelte beboers båndbredde vha. TC. NAT-firewall'en havde en offentlig IP-adresse og en 100 Mbit/s fiber-forbindelse fra et regionalt energiselskab.

Når en ny beboer meldte sin ankomst i boligforeningen, blev der udleveret et dokument med en statisk IP-adresse, netmaske, gateway og DNS-servere samt et login til administrationssystemet, hvor man kunne følge sit samtaleforbrug, optanke taletid til fastnet-telefonen og bestille en anden hastighed.

Når der var problemer med at koble computeren til internettet første gang, og det var der tit, endte aben hos administrationskontoret, der brugte uforholdsmæssigt mange ressourcer på at hjælpe beboerne i gang.

Sales is king

Det hjælper intet at have et fantastisk produkt, hvis ingen gider købe det. Første delopgave var derfor at finde ud af, hvor skoen trykkede - hvad var det, der fik beboerne til at fravælge bolignettet?

Yousee var til stede i boligforeningen, og alle beboere betalte til TV-grundpakken gennem huslejen. Desuden havde TDC analoge telefonlinier til hver eneste lejlighed fra forsyningspligtens tid, så der var reelt tre mulige leverandører af internet.

Det største problem, vi identificerede, var fraværet af DHCP. Stort set alle hjemmeroutere kommer med DHCP-klient som standard, og fru Jensen var på herrens mark, når hun skulle ind at konfigurere en statisk IP-adresse på sin nyindkøbte trådløse router.

Ejendomsinspektøren og hans folk forsøgte efter bedste evne at hjælpe beboerne, men med et utal af forskellige router-typer og styresystemer var det forståeligt, at de var trætte af situationen.

Et andet problem, vi identificerede, var, at brugerne skulle logge ind for at købe en brugbar hastighed. Det er en gylden regel inden for nethandel, at man aldrig må gøre det besværligt at købe ens produkt - brugeren skal afgive et minimum af oplysninger up front, så barren er så lav som muligt, og et tvunget login, før købet er gennemført, er et no-go.

Det er i øvrigt en generel ting, mange leverandører til erhvervslivet får galt i halsen - i frygt for at kunderne opdager, at de bliver tørret, har disse virksomheder gemt deres latterligt høje listepriser væk på beskyttede sider, som man skal være særligt inviteret for at få adgang til.

Et tredie problem, vi fandt, var, at visse af kunderne havde behov for en dedikeret, offentlig IP-adresse. Når man sætter op til 600 brugere bag den samme NAT-firewall og lader dem dele en enkelt, offentlig IP-adresse, opstår der en række udfordringer, der skal tages hånd om.

For 90 % af brugerne vil der ikke være noget problem, hvis løsningen er designet rigtigt, men for de sidste 10 % er det et stort problem ikke at kunne råde over sin egen offentlige IP-adresse.

At lade mange brugere dele en offentlig IPv4-adresse er kendt som Carrier Grade NAT, CGN, eller Large Scale NAT, LSN. Det ses primært i større virksomheder og i bolignet-løsninger, men de seneste år har det vundet frem på grund af manglen på offentlige IPv4-adresser. Det er en klassisk problematik, som vi kommer til at behandle i et separat blogindlæg.

Visionen blev til virkelighed

Det første, vi gjorde, var at indføre en DHCP-server på netværket. Samtidig slog vi to fluer med et smæk, da vi fjernede hastighedspakkerne og indførte 100/100 Mbit/s til alle kunder. Hermed behøvede vi ingen båndbreddestyring, da alle kunder havde samme produkt, og vi satte prisen så lavt, at alle kunne være med.

Det gjorde, at vi fik mange ældre beboere som kunder, og ældre mennesker er de bedste kunder, man som ISP kan ønske sig. De er høflige og taknemmelige, når man hjælper dem i gang, de sætter en ære i at betale til tiden og så har de samtidig et yderst moderat båndbreddeforbrug - og har man først vundet deres tillid, forbliver de kunder i lang tid. Den tillid forpligter.

Desuden anbefalede vi boligforeningen at fjerne tilslutningspligten til bolignettet, da vi herved kunne tvinge os selv til holde os skarpe og konkurrencedygtige på sigt.

Var det et dumt valg? Det mener jeg ikke - langt de fleste møgsager, der opstår i en ISP-virksomhed som vores, skyldes situationer, hvor man er nødt til at holde en kunde op på en aftale, kunden ikke har lyst til at være en del af længere, og ved at fjerne tilslutningspligten kunne vi effektivt fjerne samtlige af den slags sager.

Desuden gjorde det, at vi kunne skrotte IP-telefonsystemet, som var en af hjørnestenene i den gamle tilslutningspligt. Fastnettelefoni gennemgår i disse år en hastig afvikling blandt privatkunder, og det er sjældent en god forretning at holde fast i en døende teknologi.

I næste blogindlæg gennemgår jeg de lavpraktiske løsninger, vi anvendte - valg af DHCP-server, opsætning af DHCP relays m.v. Jeg kommer også ind på vores captive portal, der gør det nemt for kunderne at komme i gang.

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

Beskrivelsen minder lidt om bolignettet i Farum Midtpunkt, som jeg var med at etablere. Dog er nettet i FM formodentligt nyere og vi fik lavet noget lidt smartere valg (hvis jeg selv skal sige det).

Nettet i FM består af 60 krydsfelter. Hvert krydsfelt har en HP 2910G-48 switche med 48 gigabit porte. Herfra går der et dobbelt cat5e kabel op i hver lejlighed. Uplink er single mode fiber til et centralt krydsfelt (stjernestruktur) hvor der står en HP 5406 switch.

Beboerne får tildelt en offentlig IP-adresse via DHCP. Man kan få op til 3 adresser (så vidt jeg husker). Fast IP kan tilkøbes. Der er intet NAT. Nettet er gratis at bruge og man deles om en fælles 1 gigabit internet linie.

Det er ikke et vlan per lejlighed. I stedet bruger man DHCP-Snooping og andre mekanismer, som forhindrer at brugerne forstyrrer hinanden. Det var ikke lavet helt så smart, som jeg ville lave det i dag. Men jeg tror også vi havde nogle begrænsninger i hvad vores switche kunne.

Da vi startede var den fælles internet på 500 Mbit/s og det fungerede fint. I praksis var hastigheden for den enkelte altid mindst 100 Mbit/s og ofte meget mere. Sidst jeg hørte var den blevet opgraderet til 1 gigabit/s men var på trods af dette stærkt overbelastet. Så det er vigtigt at sørge for nok båndbredde. Dengang var der ingen der ville fortælle hvor meget nok båndbredde er, men svaret er cirka 1-2 Mbit/s peak per bruger, såfremt du har "mange" brugere. Dette tal udvikler sig løbende efterhånden som streaming bliver mere udbredt.

FM nettet har ikke haft de samme problemer som Yoel beskriver. Det er plug and play uanset om du sætter en computer direkte til eller om du sætter en router til. Det bliver drevet af en ekstern internetleverandør, så der er et kundesupport nummer man kan ringe til, hvis man har brug for hjælp.

Vi havde til gengæld en del problemer med leverandøren samt nogle tekniske problemer. De tekniske problemer var blandt andet driftsforstyrrelser der opstod på baggrund af broadcast storm foranlediget af nogle defekte SIP telefoner (brugt af ejendommens dørtelefonisystem), samt nedbrud i udbyderens eget net. De ting var mere eller mindre løst sidst jeg hørte fra FM.

PS. Jeg var beboer i FM da nettet blev etableret. Jeg har i dag ikke noget at gøre med FM eller bolignettet i FM.

  • 3
  • 0
#2 Yoel Caspersen Blogger

Nettet i FM består af 60 krydsfelter. Hvert krydsfelt har en HP 2910G-48 switche med 48 gigabit porte. Herfra går der et dobbelt cat5e kabel op i hver lejlighed. Uplink er single mode fiber til et centralt krydsfelt (stjernestruktur) hvor der står en HP 5406 switch.

HP switches (Procurve!) er nemme at arbejde med, de er billige, og så er der livstidsgaranti. Man kan endda købe dem til halv pris, hvis man går efter refurbished eller parallelimport. Til gengæld er de bedst til de rene switching-opgaver. 5400zl-serien er fx begrænset til 16 bit AS-numre, så selv hvis man kan leve med det begrænsede antal routes i FIB er det upraktisk at anvende dem som internet facing routere, hvis man har et 32-bit AS-nummer (og det har de fleste nye ISP'er). HP's Comware-serie er et noget bedre valg til et ISP-netværk, men de koster også væsentligt mere, og de er på ingen måde lige så nemme at arbejde med, selv om de har et væld af features til prisen.

Det er ikke et vlan per lejlighed. I stedet bruger man DHCP-Snooping og andre mekanismer, som forhindrer at brugerne forstyrrer hinanden. Det var ikke lavet helt så smart, som jeg ville lave det i dag. Men jeg tror også vi havde nogle begrænsninger i hvad vores switche kunne.

Og det er som regel her, man ser forskellen på et "amatør"-netværk og et professionelt et af slagsen. Mange bolignet opstår ved, at nogen deler en internetforbindelse med naboerne, og problemerne opstår, når der er mange brugere, og de deler det samme layer 2 segment - det gælder alt lige fra ARP-injection, IP-konflikter, broadcast storms m.v. til brugere, der tilslutter deres egen wifi-router forkert, så DHCP-serveren i wifi-routeren overstyrer den autoritative DHCP-server på netværket. Der er mange måder at løse den slags problemer på, men det er sjældent, at de organisk opståede netværk adresserer udfordringerne.

Til gengæld er det svinebilligt at dele internet med naboerne, og kan man leve med ustabile forbindelser af svingende kvalitet, er der mange penge at spare ;-)

  • 3
  • 0
#3 Kristian Klausen

Til gengæld er det svinebilligt at dele internet med naboerne, og kan man leve med ustabile forbindelser af svingende kvalitet, er der mange penge at spare ;-)

Må man det? I betingelserne ved min internetudbyder/energiselskab står der:

Kunden/Lejeren må ikke lade andre end medlemmer af Kundens husstand eller husstandens gæster (i sædvanligt omfang) benytte Fibernetadgangen. Kunden/Lejeren må ikke videresælge Fibernetadgangen til andre eller få leveret Tjenester via Fibernetadgangen fra andre end Altibox.

Måske bare mit selskab der har det sådan, at mange så gør det alligevel er en anden sag.

  • 1
  • 0
#4 Baldur Norddahl

Må man det? I betingelserne ved min internetudbyder/energiselskab står der:

En boligforening køber en erhvervsforbindelse hvor det på forhånd er aftalt at den skal deles mellem alle beboerne. Prisen er noget højere, eksempelvis 2000-3000 kr/måned. Men hvis man har 100-500 brugere der deles om dette, så giver det jo en ganske lav pris per bruger.

  • 2
  • 0
#5 Yoel Caspersen Blogger

Må man det?

Stort set alle selskaber har den klausul i deres privat-abonnementer. Det skyldes, at de alle sammen, os selv inklusive, håber på, at brugerne ikke anvender hele deres kapacitet hele tiden - som Baldur pointerede, er det gennemsnitlige forbrug på en kunde ca. 1-2 Mbit/s, så hvis du køber en 20 Mbit/s forbindelse, forventer din udbyder at du i gennemsnit kun bruger mellem 5 og 10 % af den. Hvis du deler den med dine naboer, stiger gennemsnitsforbruget, og det går ud over udbyderens business case.

Når det så er sagt, har vi ikke en jordisk chance for at opdage, at kunderne deler deres forbindelse med naboen, og personligt er jeg af den holdning, at det er bedre at kunden deler forbindelsen med naboen og derved udbreder kendskabet til os, end at naboen køber internet fra en af vores konkurrenter. ;-)

  • 4
  • 0
#6 Yoel Caspersen Blogger

Det var ikke lavet helt så smart, som jeg ville lave det i dag.

Baldur, har du lyst til at uddybe, hvordan du ville lave det i dag? Lad os sige, at målet er, at en bruger skal have 1 offentlig IPv4-adresse, men vi skal undgå at spilde for mange IPv4-adresser, da de er i short supply. Samtidig skal vi undgå, at brugeren forstyrrer de andre brugere på samme switch, både af hensyn til sikkerheden og stabiliteten i nettet.

Når TDC i dag uddeler IP-adresser til DSL-kunder, uddeler de et /30 scope med 4 IP-adresser (netværksadressen, gateway, kundens adresse og broadcast). Det betyder, at der spildes 3 IP-adresser pr. tildeling, men til gengæld er brugeren isoleret i sit eget broadcast domain og har også sit eget VLAN - dvs. total layer 2-isolation fra andre brugere.

Vi har selv kigget på løsninger, hvor man uddeler IPv4-adresser fra fx et /24 scope (256 IP-adresser) og isolerer brugeren på sin egen switch port vha. Private VLAN og sætter en ARP proxy op, der gør det muligt for alle brugere at kommunikere med gateway-adressen og hinanden på layer 2, uden at man går på kompromis med sikkerheden, men det er umiddelbart en bøvlet løsning.

Vi har også kigget på tildeling af /32 scopes (1 IP-adresse), hvor klienten får tildelt en gateway uden for sit eget subnet. Det virker fint på Linux, men det er langt fra alle hjemmeroutere, der understøtter det, og jeg ved heller ikke, hvor godt det virker på Windows.

Er der nogen gode forslag til, hvordan man kan spare på de dyrebare IPv4-adresser uden at gå på kompromis med sikkerheden og stabiliteten i netværket?

  • 0
  • 0
#7 Brian Hansen

Vi har også kigget på tildeling af /32 scopes (1 IP-adresse), hvor klienten får tildelt en gateway uden for sit eget subnet. Det virker fint på Linux, men det er langt fra alle hjemmeroutere, der understøtter det, og jeg ved heller ikke, hvor godt det virker på Windows.

Uden at være den helt store netværksguru, så tror jeg faktisk det er sådan min Netgear R7000 får det serveret fra Syd Energi, det virker fint, har så aldrig haft lyst til at sætte en PC direkte på linjen :)

  • 1
  • 0
#8 Henning Wangerin

Uden at være den helt store netværksguru, så tror jeg faktisk det er sådan min Netgear R7000 får det serveret fra Syd Energi, det virker fint, har så aldrig haft lyst til at sætte en PC direkte på linjen :)

Jeg har også meget dårlige erfaringer med at sætte specielt ændre routere på net som levrere /32 net.

Jeg har så lidt svært ved at se fidusen i at bruge en masse /32 net i stedet for at bruge et /24. Det er blevet skrevet en masse om sikkerheden, men hvori ligger forskellen på de to?

  • 0
  • 0
#9 Baldur Norddahl

Baldur, har du lyst til at uddybe, hvordan du ville lave det i dag?

Du nævner det sådan set selv. Brugerne deles om et fælles subnet (vi bruger /26) men broadcast isoleres via enten private vlan eller et vlan per kunde.

Private vlan betyder at kunderne er på det samme vlan, men der kan ikke flyde trafik direkte fra en kundeport til en anden kundeport. Enten kan kunder på det samme subnet ikke kommunikere med hinanden (det er der forbavsende få der opdager) eller man bruger proxy arp til at tvinge trafikken via routeren.

Et vlan per kunde kræver at routeren supportere noget der typisk kaldes for "supervlan". Det er en bunke vlans der deler samme subnet. Man er nødt til at mestre denne teknik hvis man vil sælge på TDCs net via en POI port, da kunderne her netop leveres som et vlan per kunde.

Supervlan er beskrevet her: https://tools.ietf.org/html/rfc3069

  • 3
  • 0
#10 Yoel Caspersen Blogger

Jeg har så lidt svært ved at se fidusen i at bruge en masse /32 net i stedet for at bruge et /24. Det er blevet skrevet en masse om sikkerheden, men hvori ligger forskellen på de to?

For så vidt angår sikkerheden er der ingen forskel, hvis det eneste, man gør, er at uddele /32 i stedet for /24 eller /30. Det kan dog nedsætte støj på netværket, da broadcasts elimineres. Hvis man derimod kombinerer /32 med DHCP snooping kan man undgå, at brugeren kan anvende en anden IP-adresse, end den der er tildelt af den autoritative DHCP-server, og hermed bør man i princippet kunne isolere kunderne fra hinanden på layer 2, selv om de deler samme IP-pulje.

Men, som du selv skriver, kan man ikke regne med, at alle typer udstyr understøtter en /32 WAN-adresse, så løsningen kan kun bruges i et miljø, hvor man har kendt CPE-udstyr ude hos slutbrugeren.

  • 1
  • 0
#11 Yoel Caspersen Blogger

Et vlan per kunde kræver at routeren supportere noget der typisk kaldes for "supervlan". Det er en bunke vlans der deler samme subnet. Man er nødt til at mestre denne teknik hvis man vil sælge på TDCs net via en POI port, da kunderne her netop leveres som et vlan per kunde.

Supervlan er beskrevet her: https://tools.ietf.org/html/rfc3069

Tak for uddybningen, Baldur. Det lyder som den helt rigtige løsning - men er der dannet en standard for det, eller er det udelukkende vendor-specifikke løsninger?

TDC anbefaler officielt at anvende /30-netværk til slutbrugere, så det lugter jo lidt af en traditionel løsning uden super vlan, men det skyldes nok en kombination af at de har legacy hardware og rigeligt med IPv4-adresser.

  • 2
  • 0
#12 Baldur Norddahl

men er der dannet en standard for det

Ja, den hedder RFC 3069 :-)

I praksis er implementeringerne af konceptet meget varieret. Det er langt fra alt hardware der kan det. Du kan ikke regne med at eksempelvis en HP switch kan sådan noget.

At anvende /30 per bruger er ikke alene spild af adresser, der er også andre problemer. Du får et layer 3 vlan interface per bruger. Ofte er antallet af sådanne begrænset foruden at det også er almindeligt at switchen kun kan have et begrænset antal IP-adresser. Med /30 per bruger bliver switchens IP-adresse begrænsning samtidig til grænsen for antallet af brugere du kan have.

Jeg har engang testet at loade en opsætning på 1024 /30 vlans ind på en af vores switche. 1024 er grænsen for både antal layer 3 vlans og antal IP adresser den kan håndtere. Det fungerede, men den var 30 minutter om at reboote. Man måtte også vente 10 minutter på en "show running-config" kommando, foruden at opsætningen naturligvis var umulig at læse direkte når den er så stor.

Husk at på en POI3 port kan du have tusinder af brugere på én enkelt port. Så det er helt anderledes end bolignettet. På bolignettet kan du eksportere opgaven ud decentralt, således at den enkelte switch kun behøver håndtere et antal brugere og layer 3 vlans, som svarer til det antal porte den har.

  • 3
  • 0
#13 Yoel Caspersen Blogger

Husk at på en POI3 port kan du have tusinder af brugere på én enkelt port. Så det er helt anderledes end bolignettet. På bolignettet kan du eksportere opgaven ud decentralt, således at den enkelte switch kun behøver håndtere et antal brugere og layer 3 vlans, som svarer til det antal porte den har.

Det er rigtigt, og POI3-porten kommer således til at være et single point of failure - TDC mente ikke, at det var "normalt" at sætte redundans op på en POI3-port, da porten typisk termineres mellem to switche i det samme datacenter.

Til de uindviede: En POI-port er TDC-lingo for en netværksport, hvor trafikken forlader TDC's net og sendes ind i operatørens netværk (fx Gigabit eller Kviknet). Tallet efter POI angiver, hvor tæt på kunden man er - og POI3 er så langt væk fra kunden, man kan komme, og derved opsamler man som operatør trafik fra mange kunder gennem en POI3-port. Man kan også vælge at have et større antal POI2-porte - så er man tættere på kunden, og prisen for trafikken gennem TDC's net falder. Til gengæld skal man have flere POI2-porte og være til stede på et større antal centraler for at aftage trafikken fra TDC.

Er der noget bud på konkret hardware til en fornuftig pris, der kan håndtere super vlans og ultimativt kan kobles til en POI3-port fra TDC?

  • 3
  • 0
#14 Baldur Norddahl

Er der noget bud på konkret hardware til en fornuftig pris, der kan håndtere super vlans og ultimativt kan kobles til en POI3-port fra TDC?

Supervlan ja, men en POI port er også Q-in-Q (dobbelt vlan tagged) så du skal bruge noget der kan klare "SuperQinQ". Jeg kender kun dyrt hardware der kan dette. Det er dog ganske nemt at få en Linux til at udføre tricket.

Vi sender trafik fra vores POI2 og POI3 porte ind i en MPLS layer 2 tunnel, som termineres i to redundante routere i den tunge ende af skalaen.

  • 2
  • 0
#15 Jn Madsen

Hvis jeg i dag skulle skrue sådan noget sammen, så vi jeg kigge på SDN. (Og jeg går faktisk med planer om det) Enorme besparelser på hardware er ikke at foragte, og selve topologien er rimeligt simpel. SDN er modnet meget det sidste år eller 2,- mit valg her uden tvivl.

RYU's controller understøtter QinQ, og når NSA kan bruge RYU i deres core, så kan jeg også :) : https://media.readthedocs.org/pdf/ryu/latest/ryu.pdf

For dem der vil vide mere TDC's POI struktur: https://wholesale.tdc.dk/Produkter/PT_ETrans_Bilag_1_Prod_spec_v_std_280...

Linux kan lave meget,- men jeg ville godt nok være lidt nervøs for throughput her,- hvilke Linux kasser turde du smække på her, Baldur?

  • 2
  • 0
#16 Jn Madsen

Hov,- jeg glemte at skrive,- at nu hvor i snakker om gammelt HP udstyr,- så er der meget af det der netop understøtter SDN, hvis man skifter firmware.

Det var egenligt det, der var ideen med mit første indlæg :)

  • 0
  • 0
#17 Baldur Norddahl

Linux kan lave meget,- men jeg ville godt nok være lidt nervøs for throughput her,- hvilke Linux kasser turde du smække på her, Baldur?

Det turde jeg netop ikke, hvilket er hvorfor det ikke er Linux der flytter vores pakker :-)

Dog vil jeg sige at Linux kun har et problem med "pps", det vil sige packets per second. Små pakker giver mange pakker. Små pakker er typisk for et denial of service angreb. Så i daglig drift kan man køre fint på Linux men man risikerer at det går galt hvis man kommer under angreb.

Vi startede med Linux og har siden opgraderet.

Med hensyn til HP og SDN så er det største problem at de ikke har support for særlig mange openflow regler i hardware. Det er typisk noget med max 4096 regler men ACL og andet tager af det samme hukommelse, så i praksis kan du måske have omkring 3000 regler.

Jeg udregnede engang et system til en ISP implementeret med OpenFlow. Jeg husker ikke helt hvor mange regler der skulle bruges per bruger, men det var en håndfuld. Dermed er det ikke vildt mange kunder du vil kunne køre på en HP switch.

  • 1
  • 0
#18 Yoel Caspersen Blogger

Hov,- jeg glemte at skrive,- at nu hvor i snakker om gammelt HP udstyr,- så er der meget af det der netop understøtter SDN, hvis man skifter firmware.

Og det er en af de fede ting ved HP's netværksudstyr - softwaren er frit tilgængelig, så man skal ikke betale en løbende vedligeholdelsesfee for at få rettet fejl, der også var tilstede da man købte udstyret. Og af og til kommer der også nye features til, som fx SDN - men low-end hardware bliver ikke til high-end hardware af en firmwareopgradering. ;-)

Apropos throughput på Linux - jeg har i forbindelse med nogle andre projekter sat BGP-routere op på Linux, nærmere specifikt med Quagga som BGP speaker. En af projekterne involverede en router til IP-TV med et throughput på op til 10 Gbit/s på en enkelt IBM x3550 M3-maskine med 8 GB RAM og et Intel x520 10 Gbit/s NIC. Systemet kører live den dag i dag og fungerer fint, men det er tydeligt, at der er nogle indbyggede begrænsninger i at anvende Linux til routing når man kommer op i større båndbredder.

Dels er der et overhead ved at IP-pakkerne skal gennem Linux-kernen, men det kan fjernes vha. zero-copy-teknologier a'la PF_RING. Men der er også et issue, der er lidt sværere at komme ud over, og det er latency ved opslag i route-tabellen, da det sætter en øvre begrænsning for PPS, da den globale IPv4 route-tabel har en størrelse på over 500.000 entries p.t. og ikke ser ud til at blive mindre foreløbig.

Der forskes i at fjerne en del af latency ved opslag i route-tabellen ved at pakke route-tabellen effektivt, så den kan ligge i CPU-cachen, men jeg ved ikke, hvor moden teknologien er, og hvornår den eventuelt slår igennem i en standard Linux-kerne.

  • 2
  • 0
#19 Jn Madsen

Hehe Baldur,- nu fik du mig til at kigge på HP spec's.

HP understøtter heller ikke QinQ,- ja, så har de meldt sig ud af forretningen :-)

Men der er andre på banen,- f.eks. har jeg et godt øje til Pica8. Til backbone har de f.eks. en 5401,- 2,5T backplane, 32x40G porte ... til 100.000 før man vrider rabat ud af dem. Til den pris kan man dårligt købe en brochure hos en af de "store" netværks-leverandører.

Boligforeninger er et oplagt SDN market,- og alt andet for den sags skyld. Jeg ville godt tage udfordringen op med at lave en komplet ISP på SDN, der vanker garanteret nogle lussinger forude,- men SDN er modnet meget.

  • 0
  • 0
#21 Jn Madsen

men low-end hardware bliver ikke til high-end hardware af en firmwareopgradering

Det er rigtigt, specifikt her forestillede jeg mig du havde en masse gamle støvede switche ude hos kunderne. Der kunne måske hives lidt ud af dem med en firmware upgrade,- f.eks. i forbindelse med en SDN-konstruktion. Og begrænsningen som Baldur nævner med antal kodelinier i boksen,- den rammer man nok ikke med en kunde pr. port.

Det lyder som om du har styr på netværk, Linux og kodning,- så er du den perfekte mand til at skrue SDN sammen :-)

Tak for info om Linux kasserne,- jeg har set et par Linux kasser hoste gevaldigt når der kom tung trafik på,- så der er jeg blevet lidt håndsky :-)

  • 0
  • 0
#23 Yoel Caspersen Blogger

Det lyder som om du har styr på netværk, Linux og kodning,- så er du den perfekte mand til at skrue SDN sammen :-)

Tak for info om Linux kasserne,- jeg har set et par Linux kasser hoste gevaldigt når der kom tung trafik på,- så der er jeg blevet lidt håndsky :-)

SDN, og software baseret networking i det hele taget, er et rigtig spændende område med et enormt potentiale, da der bruges voldsomme summer på hardware i dag. Som Linux-udvikler bliver man ramt af en følelse af, at alt kan lade sig gøre, hvis man bare koder den rigtige software til formålet, og at hardwaren er tæt på ligegyldig. Det passer i mange tilfælde, men man skal nok ikke være blind for, at alle problemerne ligner søm, hvis ens værktøj er en hammer ;-)

Apropos Linux-bokse, der kaster op: Det er ikke nødvendigvis nogen fordel at vælge en maskine med mange kerner - jeg troede, jeg havde fundet de vises sten, da jeg konfigurerede en voldsom Dell-server med 64 CPU-kerner som BGP-router med et antal Intel x520-NIC'er. Det fungerede relativt skidt - dels var 64 CPU-kerner mere end kortet kunne udnytte, selv med en nøje opsat IRQ affinity, dels tror jeg, en stor del af performance forsvandt i alt andet end CPU'erne (bus, RAM, cache misses m.v.). Det var ellers ærgerligt, for samme server fungerede fantastisk til CPU-intensiv video encoding og prisen var ca. 40.000 kr. Læren er, at Linux som router fungerer bedst, når der er et mindre antal CPU'er, som til gengæld er hurtigere.

Har du nogen erfaring med Cumulus Networks?

  • 1
  • 0
#25 Jn Madsen

Cumulus Networks

Nixen, jeg har læst om det,- og holder øje med dem, men ingen praktisk erfaring. Men det er en seriøs spiller.

Hele netværksmarkedet er i forandring, personligt har jeg et godt øje til SDN. De tunge drenge = de store ISP'er, vil bevæge sig langsomt. Deres struktur og milliard investeringer vil gøre dem træge, og man skal ikke undervurdere 40 års traditionel netværkserfaring. Forandringen kommer hos de små, der ikke har investeret så meget,- og hos de nye. Google, Amazon, Facebook har virkeligt skubbet på udviklingen af SDN. Spændende tider :)

Du får lige et nakkedrag på LinkedIn :-)

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen