Dagbog-bloggen

Juleopgave del 1: Opgradering af bolignet

Det pusler for tiden i buske og krat i et stille og roligt rækkehuskvarter i Nyborg.

Internetforbindelsen forsvinder et kort øjeblik, og hvis du kigger ud af vinduet, ser du muligvis et par skygger, der haster forbi, før de pludselig er væk.

Åbner du døren og lytter, er den konstante summen fra gadeskabet for enden af rækkehuset afløst af øredøvende stilhed. Og før du ved af det, virker internettet igen.

Det er ikke julenisser, der er på spil, men det er næsten lige så godt - det er nemlig et par teknikere fra Kviknet, som går rundt og opgraderer udstyr, så du kan komme op på de magiske 1000 Mbit/s.

Det oprindelige bolignet

Da vi overtog bolignettet i Nyborg i 2014, stod det klart, at vi skulle tilpasse netværket, så det kunne følge med til fremtidens behov.

Bolignettet var baseret på en træstruktur, hvor den enkelte lejlighed var forbundet til et underkrydsfelt ved hjælp af PDS-kabel. I underkrydsfeltet sad der en access-switch, en HP 5304xl, som er en modulbaseret layer 3-switch.

Foto: Kviknet

Underkrydsfeltet var forbundet til et hovedkrydsfelt med fiber, og hovedkrydsfeltet var forbundet til internettet med en fiberforbindelse.

Foto: Kviknet

Den enkelte lejlighed havde fået tildelt sit eget VLAN og 8 private IPv4-adresser, og den enkelte access-switch agerede default gateway for den enkelte kunde, som i øvrigt skulle konfigurere sit udstyr med statisk IP-opsætning.

Foto: Kviknet

Det første, vi gjorde, var at indføre en DHCP-server - så kunne kunderne tilkoble WiFi-routere og computere, der virkede out-of-the-box, og viceværten i boligforeningen slap for at skulle agere first-level-support.

Det næste, vi gjorde, var at rydde op i priserne og indføre en captive portal, så kunderne nemt kunne komme til at betale for deres net. Selve processen er beskrevet i et af mine første indlæg på denne blog.

Det fungerede fint i et stykke tid, og vi fik udnyttet de gamle HP-switches maksimalt.

Så vidt vi ved, var de indkøbt engang i første halvdel af 0'erne, og selv om det er overkill at installere en layer 3-switch som access switch, fik boligforeningen i sin tid et rigtig godt tilbud fra HP, som insisterede på at vinde ordren. Dertil kommer, at HP har livstidssupport på deres switches, hvilket er et plus.

Fra distribueret til centraliseret net

Kundens default gateway er også det, man kalder for en BNG - en Border Network Gateway. Det er her, netværket går fra layer 2 til layer 3, dvs. fra at være et switched netværk til at være et routed netværk, og det er derfor her, at kundens VLAN ender.

Der er gode argumenter for at placere BNG'en tæt på den enkelte kunde. Det gør netværket robust, og fra et trafikmæssigt synspunkt er det også den mest optimale opsætning, da trafik mellem to kunder på samme netværk skal ind forbi en BNG. Jo tættere på kunden, BNG'en er, jo kortere vej skal trafikken tage.

Der er dog også et par ulemper ved at placere BNG'en tæt på kunden. Hver eneste BNG skal i vores netværk have følgende:

  • Et scope af offentlige IPv4-adresser
  • Et scope af IPv4 CGN-adresser til de kunder, der ikke har behov for offentlige IPv4-adresser
  • Et scope af offentlige IPv6-adresser til samtlige kunder

Derudover skal BNG'en også kunne route både IPv4- og IPv6-trafik - og en HP 5304xl kan ikke route IPv6-trafik.

Idet man skal sætte et scope af offentlige IPv4-adresser af til hver eneste BNG, er man nødt til at holde antallet af BNG'er nede, da hvert eneste afsatte scope medfører et spild på minimum 3 stk. IPv4-adresser, og som regel væsentligt mere, da antallet af kunder med behov for offentlige IPv4-adresser sjældent passer præcist sammen med størrelsen på det enkelte scope.

Derfor kan det være en fordel at flytte BNG'en længere væk fra den enkelte kunde, så den i stedet dækker mange kunder, og man dermed kan sætte færre, men større IPv4-scopes af.

Hvis man flytter BNG'en længere ind i nettet, væk fra kunden, skal kundens VLAN flyttes med ind i nettet. Det betyder, at samtlige switches mellem kunden og BNG'en skal understøtte 802.1q, som er standarden for VLAN, og jo flere kunder, en switch skal håndtere, jo flere VLANs og MAC-adresser skal den understøtte.

Foto: Kviknet

Vi planlagde at slå vores bolignet sammen med andre netværk rundt omkring i landet og placere BNG'en i København, hvor vi i forvejen har en del af vores infrastruktur.

I selve boligforeningen skulle den enkelte kundes VLAN forlænges ind til hovedkrydsfeltet, og herfra skulle samtlige VLANs pakkes ind i en QinQ-trunk, som transporteres gennem det nationale transportnet til København.

En QinQ-trunk betyder, at man har to VLAN-tags for hver ethernet-pakke. Dels har man et outer tag, som bruges til at adskille de enkelte access-netværk, dels har man et inner tag, som bruges til at adskille den enkelte kunde i et access-netværk fra de andre.

Med et enkelt VLAN-tag har man 4096 mulige kombinationer, men med to VLAN-tags har man 4096^2 mulige kombinationer, dvs. ca. 16 mio. kombinationer i alt. Det rækker til et stort antal kunder.

En HP 5300xl-switch understøtter max 256 VLANs. Derfor var vi nødt til at udskifte switchen i hovedkrydsfeltet, da alle boligforeningens lidt over 600 lejligheder hver især skulle have et VLAN transporteret igennem til København.

Da vi havde udskiftet switchen i hovedkrydsfeltet med en ZTE 5928-switch, var næste øvelse at omlægge netværket fra layer 3 til layer 2, samt omlægge adresserummet fra det private IP-scope 172.16.0.0/16 til en kombination af CGN-adresserne 100.64.0.0/10 og offentlige IPv4-adresser.

Det gav os en del udfordringer, da vi konstaterede, at mange kunder, som allerede var på bolignettet i 2014, da vi overtog det, havde beholdt deres statiske IP-opsætning på routere og computere.

Da vi i 2014 indførte DHCP, beholdt vi adresseplanen for at mindske supportbyrden, og vi havde forventet, at de gamle kunder lige så stille ville forsvinde, og at problemet dermed ville løse sig selv, da nye kunder ville køre DHCP.

Men de gamle kunder blev hængende i noget højere grad, end vi havde regnet med.

I en overgangsfase hen over sommeren i år var vi derfor nødt til at have to parallelle net - det gamle, routede net, og et nyt switched net med DHCP. Vi sendte en tekniker ud, som gik fra dør til dør for at hjælpe de gamle kunder over på DHCP, og i løbet af en lille uges tid var opgaven løst.

Fra 100 Mbit/s til 1 Gbit/s

Næste udfordring var, at den primære porttype på en HP 5304xl er 100 Mbit/s kobberporte. Selv om man kan købe 1 Gbit/s moduler til den, er port-densiteten for 1 Gbit/s porte meget lav - et modul med 4 stk. 1 Gbit/s porte fylder lige så meget som et modul med 24 stk. 100 Mbit/s porte.

Selv om 100 Mbit/s her og nu er fint for de fleste, må vi erkende, at efterspørgslen i fremtiden vil gå mod højere hastigheder.

Løsningen blev derfor at udskifte samtlige access-switche til Fiberstore S3800-switches med 1 Gbit/s kobberport til den enkelte kunde og 10 Gbit/s fiberport til uplink. Det giver også den store fordel, at vi faktisk kan levere 1 Gbit/s til den enkelte kunde, hvor hastigheden ikke er delt med de andre kunder på switchen.

De nye access-switches landede på kontoret for et par uger siden, og vores teknikere gik straks i gang med at konfigurere dem og gøre dem klar til installation i det enkelte krydsfelt.

Foto: Kviknet

Vi anvendte et script til at konvertere konfigurationsfilen fra HP 5304xl til Fiberstores format, hvilket nedsatte arbejdsbyrden og mængden af manuelle fejl.

Foto: Kviknet

Efter varsling af de enkelte kunder pr. mail og SMS kørte vores teknikere ud og udskiftede switchene - og bortset fra en enkelt case, hvor en gren fra en busk havde forvildet sig ind i et teknikskab og faktisk vokset videre derinde, gik det ganske smertefrit.

Nu hvor internetforbindelsens hastighed for den enkelte bolignet-kunde kan tæt på 10-dobles, går næste del af juleopgaven på at få optimeret det trådløse netværk i det enkelte hjem, så man også får glæde af de høje hastigheder i praksis.

Følg med i næste indlæg, hvor vi ser på, hvordan det kan gøres.

Relateret indhold

Kommentarer (14)
Glenn Dufke

Som altid velskrevet og spændene læsning :)

Jeg glæder mig til at læse om hvordan i har grejet det trådløse net hos kunderne, det er som bekendt en stor udfordring i blokbyggerier pga densiteten :)

Af ren nysgerrighed, har i haft SDN switche med i overvejelserne ved valg af hardware til opgraderingen? :)

Yoel Caspersen Blogger

Af ren nysgerrighed, har i haft SDN switche med i overvejelserne ved valg af hardware til opgraderingen? :)

Både og. SDN som begreb virker på nuværende tidspunkt mest som varm luft fra marketingsafdelingen, men selve grundtanken er interessant og har helt sikkert sin berettigelse.

I og med at vi har ændret arkitekturen, så BNG'en er flyttet væk fra boligforeningen, er behovet for løbende konfigurationsændringer forsvundet - åbning og lukning af abonnementer sker nu på BNG'en. Hver eneste access-port er bundet op på en fysisk adresse, og bortset fra et større renovationsprojekt for et par år siden, hvor boligforeningen sammenlagde nogle lejligheder, er der ikke behov for at ændre på den del.

Så umiddelbart har vi ikke haft behov for at kigge på SDN, om end jeg har overvejet, om det var på tide at lave et værktøj, som i realtid kan oversætte CLI-kommandoer mellem de forskellige hardware-typer, vi kører med. Vi har på nuværende tidspunkt 4-5 forskellige hardwareleverandører i vores netværk, og det kunne være lækkert at have en enkelt CLI, som kan håndtere samtlige typer, så man kun skal huske en enkelt syntax.

Et sådant værktøj ville i princippet være en genopfindelse af SNMP, og kunne sikkert også bruge delelementer fra SNMP, men det er mit indtryk, at mange især billigere switches har ringe understøttelse for SNMP - og i disse tilfælde kunne systemet bruge HTTP/HTTPS til kommunikation med hardwaren. Samtidig ville det være en stor mundfuld, hvis systemet skulle understøtte mange forskellige typer hardware og firmware-versioner, idet features og syntax kan varierere utrolig meget.

Nå ja, og så er det en af den slags ideer, som helt sikkert har været luftet før, og som i bund og grund leder til koncepter som SDN. Mere unik er den heller ikke ;-)

Yoel Caspersen Blogger

Glæder mig til at høre om jeres erfaring med FS switchene...

Vi var faktisk gået i gang med at udskifte HP 5304xl-switches til HP 1920-48G. Sidstnævnte er (var) en billig switch, som med en simpel kommando kunne unlockes til en full fledged layer 3-switch med Comware OS. Prisen for 48 porte var ca. 3.000 kr - men i starten af oktober fordoblede HP prisen ud af det blå.

Da vi i andre sammenhænge har haft gode erfaringer med Fiberstore, valgte vi at prøve deres nye switch-serie af. Der er tale om re-brandede switches fra en eller anden asiatisk producent, men prisen er så lav, at vi godt kan tillade os at eksperimentere.

Indtil videre har vi fået følgende erfaringer:

  • Syntaxen for CLI minder meget om Cisco / ZTE osv.
  • Dokumentationen er OK, og så er den frit tilgængelig
  • Portene er nummereret lidt spøjst. Den øverste række indeholder porte med lige numre, mens den nederste række indeholder ulige numre
  • Vi har fundet en kosmetisk bug i deres SNMP-agent - den rapporterer IP-adresser i omvendt rækkefølge, dvs. 127.0.0.1 bliver til 1.0.0.127, hvilket kunne indikere et endianness-problem et sted i deres firmware - der mangler nok en htonl()-funktion i SNMP-agenten. Fejlen er rapporteret til Fiberstore, der har lovet at frigive en ny software i marts 2018, som fixer dette
  • Den indbyggede HTTP-server er useless og bør ikke aktiveres - anvend i stedet CLI
  • Switchen accepterer umiddelbart alle typer SFP/SFP+ moduler i uplink-portene
  • Dobbelt strømforsyning er tilgængeligt for en beskeden merpris

Så det er i korte træk erfaringerne på nuværende tidspunkt. Vi savner dog en switch med MPLS-support til en fair pris - her er ZTE indtil videre det bedste bud.

Ivo Santos

Jeg bor i en boligforening hvor trådløs netværk næsten er umuligt fordi næsten alle har hver deres egen router, så derfor har jeg helt droppet trådløs teknologi og kører i stedet med kabel, men det fungere til gengæld upåklageligt.

Så var det jeg tænkte på om fremtiden for trådløs internet i boligforeninger måske burde ændres på det nuværende system.
Her tænker jeg på at i stedet for at alle lejligheder har hver deres egen trådløs boks, så kunne man sætte en fælles boks op et sted som for eksempel kunne deles af f.eks. 4 lejemål, en etage, eller hvad der nu er praktisk, det burde da kunne løse problemet med ustabil trådløs internet, men kræver så til gengæld at man benytter nogle stærkere bokse, som naturligvis så også er dyrere.

Yoel Caspersen Blogger

Her tænker jeg på at i stedet for at alle lejligheder har hver deres egen trådløs boks, så kunne man sætte en fælles boks op et sted som for eksempel kunne deles af f.eks. 4 lejemål, en etage, eller hvad der nu er praktisk, det burde da kunne løse problemet med ustabil trådløs internet, men kræver så til gengæld at man benytter nogle stærkere bokse, som naturligvis så også er dyrere.

Hvis man skal have held med at indføre ny teknologi, tror jeg, man skal satse på løsninger, der kan sameksistere med gammel teknologi, og som i øvrigt tager højde for, at ikke alle har lyst til at skifte samtidig.

Det gælder fx også ved selvkørende biler - en selvkørende bil vinder kun udbredelse, hvis den kan køre på vejen samtidig med manuelt førte biler og selvkørende biler af andre fabrikater.

Heldigvis kan den stigende udbredelse af 802.11ac på 5 GHz-båndet faktisk løse en del af problemerne med interferens i en boligblok, da rækkevidden simpelthen er kortere. Dertil kommer automatisk kanalskift m.v., som sikrer at udstyret selv forsøger at finde en optimal frekvens.

Men mere om det næste gang :-)

Baldur Norddahl

Den maksimale kabellængde for 100 Mbps og 1000 Mbps ethernet er den samme. Det er officielt 100 meter plus 5 meter patchkabel i hver ende. I praksis kan man ofte køre længere. 1000 Mbps kræver cat 5e kabel.

Det er først ved 10 Gbps at man indførte kortere maksimale kabellængder. På 10 Gbps afhænger det af kabeltypen. Cat6 kabel giver 55 meter og cat6a giver 100 meter.

Yoel Caspersen Blogger

Du taler om 1 Gb på kobber. Hvor langt kan du skyde der? Allerede på CAT5 var grænsen 100 m. Hvad med de øgede krav til kabelføring (bøjning af kabler m.m.)

Vi har ikke oplevet nogen problemer på grund af kabellængden. Af og til oplever vi problemer med en konnektor i et stik i en lejlighed, og vi har også set eksempler på, at en elektriker havde byttet rundt på to lejligheder i et krydsfelt.

Uden at jeg har præcise tal på det, tror jeg ikke, vi noget sted kommer op på de 100 meter, som standarden understøtter.

Skal man over 1 G, bør man ubetinget vælge fiber i stedet for PDS. Det er meget nemmere at finde udstyr, der kører 10 Gbit/s fiber end 10 Gbit/s kobber, og rækkevidden er betydeligt længere - fra 500 meter på multimode fiber til 40-80 km på singlemode afhængigt af dæmpningen på kablet og de anvendte transceivers.

En anden stor fordel ved fiber er, at det ikke leder strøm. Et PDS-net, der er gravet ned i jorden, er følsomt over for lynnedslag, krybestrømme m.v.

Yoel Caspersen Blogger

Så svært er det vel heller ikke. En søgning på ebay, 10GBASE-T, giver her 783 resultater.

Det kan selvfølgelig lade sig gøre, men der er mange gode grunde til at vælge udstyr med native SFP+ i stedet for native 10GBASE-T:

  1. Ved lange afstande kan man anvende fiber-moduler
  2. Til intern kabling i racks kan man anvende Direct Attach cables (DAC)
  3. SFP+ har lavere strømforbrug
  4. SFP+ har lavere latency
  5. SFP+ kan indgå i et WDM-setup
  6. Større udvalg af kompatibel hardware
  7. Man kan gå fra SFP+ til 10GBASE-T vha. en adaptor, men ikke den anden vej

Den eneste umiddelbare fordel ved 10GBASE-T er, at man kan genbruge eksisterende PDS-kabling, så længe afstanden er kort.

Log ind eller Opret konto for at kommentere