yoel caspersen blog bloghoved

Redundant internet med CGN

Som internetudbyder er ens værste mareridt, at netværket går ned, og kunderne står uden internet.

Derfor er en vigtig opgave at sikre, at det meste af netværket er redundant, så man minimerer skaderne ved nedbrud.

I dag skal det handle om, hvordan vi har gjort vores Carrier Grade NAT (CGN) redundant.

CGN - når der er mangel på IPv4-adresser

Allerførst skal vi have lidt teori omkring CGN. CGN er en teknik, der bruges, når man skal spare på de offentlige IP-adresser.

Det er ikke alle vores kunder, der kører CGN, for ca. 10 % af kunderne har behov for en offentlig IPv4-adresse og vælger derfor at tilkøbe en fra os.

Resten er ligeglade, for de har ikke nogen servere stående og bruger kun deres net til streaming og Facebook. Desuden har næsten alle kunder mulighed for at køre IPv6.

En kunde, der skal køre CGN, får uddelt en CGN-adresse af vores DHCP-servere.

En CGN-adresse er en IP-adresse i området 100.64.0.0 til 100.127.255.255 og er at sammenligne med en privat IP-adresse.

Den kan ikke nås fra internettet, men der er ikke noget overlap mellem CGN-adresserne og de IP-adresser, der bruges på lokale netværk, hvilket fjerner route-konflikter på kundernes udstyr.

Når kunden sender en forespørgsel til internettet, bliver trafikken routed til en af vores CGN-routere vha. policy based routing, hvor man kigger på source IP i stedet for destination IP.

En CGN-router er i vores tilfælde en Linux-server med et 10 Gbit/s netværkskort, som er forbundet til en af vores edge-routere.

Ved hjælp af iptables oversætter vi kundens CGN-adresse til en offentlig IP-adresse, hvorefter forespørgslen sendes videre ud på nettet.

iptables -t nat -A POSTROUTING -s 100.64.1.0/25 ! -d 100.64.0.0/10 -j SNAT --to-source 185.107.12.114
iptables -t nat -A POSTROUTING -s 100.64.1.128/25 ! -d 100.64.0.0/10 -j SNAT --to-source 185.107.12.115
iptables -t nat -A POSTROUTING -s 100.64.2.0/25 ! -d 100.64.0.0/10 -j SNAT --to-source 185.107.12.116
iptables -t nat -A POSTROUTING -s 100.64.2.128/25 ! -d 100.64.0.0/10 -j SNAT --to-source 185.107.12.117
...

Routeren husker forespørgslen, og når svaret kommer tilbage, routes det ind til kundens CGN-adresse igen.

Vi har inddelt vores kunder i puljer, således at maksimalt 128 kunder deles om den samme IP-adresse.

Det mindsker problemerne med blacklisting af IP-adresser, fordi en enkelt bruger har virus på sin PC eller ikke kan huske koden til sin Playstation-konto.

Single points of failure

Når vi skal indbygge redundans i vores løsning, skal vi have helt styr på hvilke risici, vi skal håndtere.

Netværksudstyr er som regel ret robust, mens servere har en tendens til at være mere sårbare. Der kan være softwareproblemer, og harddiske og strømforsyninger har en tendens til at dø over tid.

Passiv fysisk infrastruktur såsom fiberkabler går sjældent i stykker af sig selv, men kabler, der ligger i jorden, er sårbare over for overgravning, og derfor skal lange fiberstræk være redundante.

Det opnås som regel ved at bygge en ring, hvor trafikken kan løbe to veje.

Når man kigger på vores samlede netværk, findes single points of failure primært tæt på den enkelte kunde.

Illustration: Privatfoto

Kundens vej på internettet er symboliseret ved hhv. den blå og den røde streg. Den blå streg er trafik med CGN-adresser, mens den røde streg er trafik med offentlige IP-adresser.

En gennemsnitlig Kviknet-kunde er forbundet til en DSLAM vha. et telefonkabel fra TDC. Herfra går trafikken gennem TDC's ring og ind i Kviknets transportnet via et POI (point of interconnect).

Privatkunder vil ikke betale for redundans, så det kan ikke betale sig at etablere redundant kabling helt ud til den enkelte kunde.

Til gengæld stiger behovet for redundans, når flere kunder bruger den samme infrastruktur. I vores tilfælde accepterer vi et single point of failure på følgende steder:

  • Kundens telefonkabel
  • DSLAM på telefoncentralen
  • POI mellem TDC's router og transportnettet

Når antallet af kunder på den enkelte TDC-ring stiger, kan det give mening at have et redundant POI, men det gennemsnitlige antal kunder på en ring er ofte ret lavt for en udbyder som Kviknet, da der er mange ringe i TDC's net.

Transportnettet er redundant, og det samme er vores edge-routere.

Derfor er opgaven at sikre, at CGN-routerne også er redundante.

VRRP

Selv om CGN-routerne i bund og grund blot er Linux-servere, kan vi betragte dem som netværksudstyr.

Derfor giver det mening at bygge redundansen med nogle standardiserede netværksprotokoller.

Det betyder, at der er to oplagte valg: dynamisk routing eller statisk routing.

Ved dynamisk routing installerer vi en BGP speaker på en CGN-router og lader CGN-routeren indgå i vores mesh.

På den måde ved edge-routerne, hvor de skal sende trafikken fra CGN-brugerne hen, og hvis en CGN-router går ned, bliver routen automatisk fjernet fra route-tabellerne i CGN-routerne, så en anden CGN-router kan tage over.

Ulempen ved dette setup er, at det er mere komplekst, fordi der skal installeres og konfigureres en BGP-speaker på den enkelte CGN-router, og komplekse løsninger er sjældent optimale.

Derfor bruger vi statisk routing, hvor vi inddeler CGN-routerne i par.

Når to CGN-routere indgår i et par, lader vi dem være backup for hinanden ved hjælp af VRRP, som på Linux kan køres via Keepalived.

Med VRRP har vi et master-slave-setup, hvor slaven holder øje med, om masteren er i live. Hvis masteren dør, overtager slaven masterens IP-adresse, og alt kører videre som før.

Hvis en af vores edge-routere dør, dør CGN-routeren sammen med den, og den anden CGN-router overtager den førstes IP-adresse og rolle i netværket.

Konvergenstiden ved VRRP er kort - typisk går der kun et sekund eller to, fra masteren dør, til slaven overtager IP-adressen.

Da CGN-routerne ikke deler NAT-tabeller, vil alle igangværende kundesessioner blive afbrudt, men de kan umiddelbart startes op igen med det samme.

Det har vi valgt som et acceptabelt trade-off.

Var I ikke gået væk fra software routing?

Både og. Vores edge-routere er nogle ondskabsfulde ZTE M9000-routere, som hver især kan route 200 Gbit/s i ren hardware.

Vi har hørt rygter om, at der muligvis kommer et CGN-kort til dem, så de kan udføre NAT-funktionen også - men indtil videre har vi valgt at køre videre med Linux-servere til den del.

IPv6-trafik routes i hardware, og det samme gælder trafik fra kunder med offentlige IP-adresser - og da offentlig trafik rammer vores hardware-routere først, kan vi mitigere DDoS-angreb her.

CGN-routere baseret på Linux har endvidere en lang række andre fordele - lave omkostninger, kreative løsninger og muligheden for at scripte sig ud af alting.

Især det sidste er en stor fordel, hvilket vi skal se i næste indlæg, hvor vi gennemgår vores bud på offentlige IP-adresser til coax-kunder.

Relateret indhold

Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Yoel Caspersen Blogger

Tak for de pæne ord, og tak fordi du læste med.

Når man hører om endnu et sindssygt forslag fra politistatsliderlige letvægtere i den politiske klasse, kan man for en stund søge tilflugt i teknikken og glæde sig over, at tekniske udfordringer har en elegant og simpel løsning - modsat de politiske udfordringer, der er i en helt anden liga.

  • 10
  • 0
#3 Jesper Lund
  • 5
  • 0
#9 Yoel Caspersen Blogger

Står jeres CGN-routere fysisk på samme lokation, eller lever i med de problemer et geografisk distribueret layer 2 net giver?

Lige nu findes de i samme datacenter, men vi er i gang med en ændring af vores net, hvor vi flytter dem væk fra hinanden. Selv om vi har redundant strømforsyning på både edge-routere og CGN-routere, er der stadig en sårbarhed i forhold til brand - så derfor er vi nødt til at separere dem fysisk også.

Hvilke ulemper tænker du, der er ved et geografisk distribueret layer 2-net?

  • 2
  • 0
#10 Andreas Plesner

Hvilke ulemper tænker du, der er ved et geografisk distribueret layer 2-net?

Fx kan du have et spanning tree, der konvergerer på at al trafik flyder igennem et andet site end det, hvor din VRRP IP er aktiv, så trafikken skal krydse de lange links flere gange. Jeg har også set situationer, hvor trafikken endte med at være så assymetrisk at en switch aldrig så trafik sourcet fra en host, og derfor floodede al trafik til den.

Men helt generelt: At sikre kongruens mellem l2 og l3 kan være lidt af en hovedpine.

  • 1
  • 0
#11 Baldur Norddahl

Fx kan du have et spanning tree

Mange internetudbydere, herunder Kviknet og Gigabit, benytter MPLS. Der er ikke noget spanning tree. Vi har i stedet L2VPN (VPLS) som simulerer et redundant layer 2 net:

https://en.wikipedia.org/wiki/Layer_2_MPLS_VPN https://en.wikipedia.org/wiki/Virtual_Private_LAN_Service

Modsat spanning tree, så er alle links aktive med MPLS løsningen. Systemet bruger "split horizon" til at undgå loops.

Skulle man lave en løsning uden MPLS så vil det nok være smart at bruge TRILL eller SPB:

https://en.wikipedia.org/wiki/TRILL_(computing) https://en.wikipedia.org/wiki/IEEE_802.1aq

  • 1
  • 0
#12 Andreas Plesner

Mange internetudbydere, herunder Kviknet og Gigabit, benytter MPLS

Men så er det jo heller ikke layer 2, og du forudsætter også at man kører MPLS helt til kanten og ikke har noget (redundant) switchet net ude på de enkelte lokationer.

Systemet bruger "split horizon" til at undgå loops.

Split horizon kan desuden sagtens give nogle af de samme problemer i form af assymetri eller inkongruens mellem layer 3 og layer 2.

TRILL

Er heller ikke layer 2.

SPB

Kunne man også argumentere for ikke er layer 2.

Der er forskel på om du reelt kører layer 2 eller om du kører noget, der ligner layer 2 for dine enheder. Jeg ville nok betvivle den mentale sundhed i at simulere et layer 2 netværk, hvis endepunkterne faktisk er routere.

  • 0
  • 0
#13 Baldur Norddahl

Men så er det jo heller ikke layer 2, og du forudsætter også at man kører MPLS helt til kanten og ikke har noget (redundant) switchet net ude på de enkelte lokationer.

Nu var det jo altså dig selv der kun gav to muligheder da du skrev:

"Står jeres CGN-routere fysisk på samme lokation, eller lever i med de problemer et geografisk distribueret layer 2 net giver?"

Da vi har et samarbejde med Kviknet ved jeg tilfældigvis at det er et MPLS/VPLS netværk der benyttes. Og ja routeren er end point for VPLS samtidig med at den kører VRRP på samme VPLS. Vi benytter ikke switchet layer 2 noget sted i vores net, hvor du med layer 2 forstår gammeldags ethernet med spanning tree.

Split horizon kan desuden sagtens give nogle af de samme problemer i form af assymetri eller inkongruens mellem layer 3 og layer 2.

Hvordan det? Der er ingen konvergensprocess eller lignende i VPLS. Det er det underliggende MPLS netværk der står for at konvergere via OSPF eller ISIS. Vores net er i øvrigt tunet så at konvergenstiden ved link fejl er under 1 sekund, så VRRP skal bare konfigureres med timere større end det. Hvis vi en dag får tid til at konfigurere backup paths kan nedetiden nedbringes til teoretisk 50 ms.

Layer 3 er i dette tilfælde også en VPN teknologi, nemlig MPLS L3VPN. Hvis VPLS netværket ikke kan kommunikere, så kan L3VPN netværket hellere ikke, da det er de samme underliggende MPLS net der transporterer pakkerne.

Der er forskel på om du reelt kører layer 2 eller om du kører noget, der ligner layer 2 for dine enheder. Jeg ville nok betvivle den mentale sundhed i at simulere et layer 2 netværk, hvis endepunkterne faktisk er routere.

Nu er det nu engang det som VRRP forventer som kommunikationskanal og vi har ikke noget layer 2 net.

Mere generelt så fungere vores net ved at der er et MPLS netværk der består af ZTE M6000/E9000 core routere og ZTE 5900E MPLS routing switches. Alle links kører MPLS. Der er intet layer 2 net, dvs. ingen steder i nettet hvor en switch er konfigureret til at switche trafik mellem to eller flere porte som traditionel ethernet layer 2. Jeg skal dog ikke kunne sige om Kviknet har layer 2 switching, men vi har ikke.

Ude på telefoncentralerne har vi POI porte fra TDC. Disse bliver sendt ind i et VPLS og afleveret til M6000 routerne. M6000 fungerer både som VPLS end point og layer 3 router og der på den måde hellere intet sted i nettet hvor der er rå layer 3 pakker (undtagen i peering points med tredjepart og links til servere). Det underliggende MPLS netværk benytter naturligvis IPv4 layer 3 men det er et internt 10.0.0.0/8 management netværk.

Vi har endvidere GPON switche på telefoncentralerne. Disse er desværre for dumme til at indgå direkte i MPLS netværket. De er så helt simpelt koblet på en ZTE switch og hele GPON switchen behandles som om den var en POI port. Dvs. også en VPLS tilbage til M6000. Eneste forskel er at vi har et management VLAN så det er muligt at konfigurere GPON switchen udenom VPLS. Bemærk dog i det tilfælde eksistere management VLAN kun i mellem den direkte koblede ZTE switch og GPON switchen, idet ZTE switchen er layer 3 router, så der er ikke noget med at vi har et layer 2 management netværk. ZTE switchen er single point of failure overfor GPON switchen, og det lever vi med - men det kunne sagtens fixes hvis vi ville investere i en løsning (to ZTE switche per central eller et backup link til en ZTE switch på en anden central).

  • 2
  • 0
#14 Deleted User

@Yoel Caspersen

Selv om jeg for længst er stået af på det tekniske i debatsporet, så vil jeg sige tak for indsparket. Dine blogs er noget af det eneste indhold her på V2 der faktisk lever op til parolen om IT-stof for de professionelle. Det meste andet er en blanding af omskrevne pressemeddelelser og ligegyldige holdningsbaserede småhistorier, der ikke gør en klogere på noget som helst. Det gør dine blogindlæg altid.

Tak.

  • 10
  • 0
#15 Yoel Caspersen Blogger

Selv om jeg for længst er stået af på det tekniske i debatsporet, så vil jeg sige tak for indsparket.

Tak for de pæne ord om mine skriverier. Jeg er glad for, du har lyst til at læse med - og ja, debatterne kan hurtigt blive meget langhårede, når ildsjælene først går i gang ;-)

Jeg har altid været en stor fan af inspirerende fortællinger, hvor man bliver klogere undervejs - og der er rigtig mange spændende fortællinger derude.

Personligt har jeg en favorit på ing.dk, hvor Henrik Stiesdal fortæller levende og indsigtsfuldt om vindmøller og energibranchen. Det er altid interessant at høre på folk, der ved hvad de taler om, og tillige evner at formidle deres viden.

Det samme gælder Andreas Laustsens blog om slangegifte - super nørdet, og samtidig meget inspirerende, fordi Andreas fortæller om noget, han ved noget om og brænder for. Jeg kommer ikke til at arbejde med slanger af at læse hans blog, men den entusiastiske formidling smitter i den grad.

Det var også godt at se, at version2 tog bolden op og lavede en reportage om DAWA - for som vi bl.a. kan se i kommentarsporet, er der tale om et projekt, man kan lære noget af.

Mit håb med mine indlæg er at inspirere læserne og blive klogere selv. Lykkes det, er målet nået.

  • 4
  • 0
#16 Morten Toudahl

Under min uddannelse til datamatiker havde vi et semester der havde netværk som overordnet emne. Både på den praktiske del med en masse socket programmering, og diverse former for services over netværk. Men også en hel del teori omkring netværks lagene, og protokollerne etc der bliver anvendt til at kommunikere med.

Men her bliver jeg helt hægtet af... Hvilket jeg ikke er helt tilfreds med. :-P

Hvis jeg gerne vil have en dybere forståelse for computer netværk og alle de forkortelser i smider rundt med. Hvilke bøger skal jeg så læse? I skolen brugte vi computer networking - a top down approach"

  • 0
  • 0
#17 Baldur Norddahl

Måske Yoel får lyst til at skrive nogle flere blogindlæg :-)

Men ellers vil jeg sige start med wikipedia. Læs eller skim eventuelt de relevante RFC dokumenter. Google er også god da du typisk kan finde artikler eller blogs om teknologierne. Du finder også forklaringer i dokumentation fra specielt Cisco og Juniper.

  • 2
  • 0
#18 Yoel Caspersen Blogger

Men her bliver jeg helt hægtet af... Hvilket jeg ikke er helt tilfreds med. :-P

Det er en sund indstilling at have... altså til det at blive hægtet af ;-)

Det er min erfaring, at selv om bøger kan give et godt overblik over en given teknologi, er de skrevet med fokus på et bestemt område og en bestemt tilgang til løsning af et veldefineret problem. Det kan give en udfordring, når teorien møder virkeligheden og man for syvende gang må ty til Stackoverflow for at finde inspiration.

Hvis man vil tilegne sig viden om en given teknologi i IT-branchen og arbejde med den bagefter, er der ingen vej uden om massive selvstudier. Lange aftener med gennemlæsning af Wikipedia, referencemanualer og forumposts er et godt sted at begynde. Nå ja, og lab-tests en masse, og, hvis man er spændingssøgende eller fattig, tests på produktionssystemer midt om natten ledsaget af en stille bøn til de højere magter.

  • 1
  • 0
#19 Morten Toudahl

Tak for svarene.

Det er ren personlig tilfredsstillelse at vide mere. Det er ikke relevant i mit nuværende job.

Så der er ingen test miljøer at arbejde på, og ingen specifikke ting at slå op. Men jeg vil kigge mig lidt omkring hist og pist, og se hvad jeg kan finde

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