Her kommer en liten forklaring på hvordan vi bruker utstyret vi har lånt fra sponsorer, og KANDU sitt eget utstyr. PS: om bildene blir for små så kan man åpne bildet i ny tab, og fikse URL-en så man fjerner skaleringa >:-{D
Disclaimer
Her går det i norsk og english om eachother.
Dette er ikke en uttømmende oversikt, “ringen”, leveranser til crew o.l. er ikke tatt med her.
Wifi er ikke tatt med i stor grad
Først en tegning
Hva som har blitt levert, og hvordan vi bruker det
Arista har levert utstyr til å bygge en lag 3 spine/leaf-arktitektur, bestående av 2 x spines (d1-*-roof, Arista DCS-7050CX3-32S, plassert oppe i taket) og litt forskjellige type leafs alt ettersom hva vi trenger hvor. denne arkitekturen går gjerne under navnet “fabricen” (fæbriken!) i NOC-en.
Arista CCS-720XP-96ZC2 leafs brukt som distroer på gulvet (d*-floor)
Arista DCS-7050SX3-48YC8 leafs brukt som distro/aksess i stand (d2-*-stand)
Arista DCS-7280SR3K-48YC8 stand-alone, brukt som internettrutere
Arista 7010TX-48-F switcher brukt til out-of-band management med flatt lag2-nettverk
Arista AP-C460/AP-C360/AP-C260 aksesspunkter
Noen bokser brukt som aksess-switcher for spesialfunksjoner som gamecompo o.l.
Palo Alto leverer brannmurer som vi ruter all deltagertrafikk igjennom. Vi har et sett med PA-5430 brannmurer, som vi har satt opp i cluster. Vi bruker det til litt forskjellige ting, som bl.a.:
Beskytte deltagere mot “known malicious” adresser på nettet. Vi ønsker ikke at deltagere sin virusinfiserte maskin skal få kontakte botnets for å bli med angrep, eller at man fra infiserte nettsider skal bli sendt til adresser som sprer gøgg
Vi gjør v4-NAT, slik at vi kan holde oss til å bruke KANDU sine v4-adresser
Vi henter ut data som vi grafer og lager stats av. Som hvor mye trafikk som går til Steam, og hvilke land vi kommusierer mest med i skipet
GlobalFiber leverer den optikken som KANDU selv ikke har. Det gjør at vi har plenty med 100G, 25G og 10G optikk når vi finner på nettverkssprell.
Nextron leverer servere, som gjør at vi kan hoste og produsere mye av innholdet og de funksjonene vi trenger, og kule ting som å dele ut VM-er til deltagere som har lyst til å leke med linux.
nLogic er paraplyen som leverer “pakken” av Palo Alto, GlobalFiber og Arista, som muliggjør The Gathering i 2025
PS: Grunnen til at vi fremhever våre sponsorer er at TG ikke hadde gått å arrangere uten. Vi er avhengige av å få spons for å kunne arrangere og bygge det vi bygger, og da er vi heldige med velvillige og gode sponsorer som leverer heftig utstyr. Utstyret vi låner har markedsverdi på mange millioner kroner, og er helt i toppsjiktet av infrastruktur.
Q&A
Hvordan flyter trafikken min fra min PC til internett?
IPv4 og IPv6 rutes samme path. I fabricen har vi flere VRF-er, for å separere ulike nett og selektivt kunne sende trafikk gjennom brannmurclusteret. Så en deltager befinner seg i CLIENTS VRF-et som rutes igjennom brannmurclusteret. Der gjøres source-NAT på IPv4, og sikkerhet for IPv4 og IPv6. Deretter rutes det videre til fabricen, men da inn i VRF-et INET. Derifra går det strake veien ut til Telenor/internett.
Hvorfor NAT-es jeg i år? Slik har det ikke vært før?
Av flere årsaker, der det viktigste er:
Promotere bruk av IPv6
Kun bruke KANDU sine offentlige IPv4-adresser. Det gjør at vi ikke opplever at adressene har blitt flyttet rundt og geolokalisert i ulike land til ulike tider. Vi har hatt Steam på Russisk et tidligere år, det unngår det problemet.
Moderne applikasjoner håndterer NAT helt fint
Men det er ikke utelukkende positivt. Det fører til at “ende til ende” kommunikasjon med IPv4 ikke fungerer. Men det gjør det på IPv6, så det er greit.
Hvorfor får min Iphone/Android-telefon kun IPv6-adresse?
Fordi vi bruker “IPv6 mostly”, som vil si at SLAAC i kombinasjon med DHCPv4 gjør at klienter som støtter det ikke vil få tildelt en brukbar IPv4-adresse. Klienten vil tunnelere trafikk som skal til IPv4-adresser i IPv6, og Paloene våre vil bruke NAT64 til å få trafikken frem.
Spørsmål?
Noe du vil vite mer om? Kom på Discord (#tech) og fortell om hva du vil vite, så skal vi prøve å fylle på med info her på bloggen 😀
Tech:nett har nå vært i skipet noen dager, og det er 21 timer igjen til deltagerne kommer brasende inn. 21 timer igjen til alt må fungere. Til tross for at vi har hatt ett døgn mindre å rigge på i år, så er vi godt i rute.
Hva har fungert bra
Mer eller mindre alt. Mye mindre kaos i templating i år kontra i fjor (TG-fjor…), kabeltrekking, Netbox for inventory er mer modent, eksisterende TG-fiber rundt i i skipet er gull. De nye som er tatt opp i tech:nett i år gjør en kjempeinnsats, og det er som om de har vært med å bygge TG i mange år.
Sponsorene våre (<3) har stått på, noen har vært her i flere dager alt, andre kommer i dag og blir litt utover påska. Her har vi tilgang til spisskompetanse på produkter og løsninger som er godt å ha.
Hva har fungert mindre bra
Dette er ikke nødnvigvis noe som ikke fungerer, men…
TG tech har alltid hatt en ganske stor grad av nettverksautomatisering. Datastrukturer og pipelines blir fort komplisert og uoversiktlig, og i år er vi enda mer (buzzword-warning!) datadrevet. Vi er en god miks av mennesker her, med forskjellig kompetanse. Man må være ganske utvikler-rettet for å henge med i alle kriker og kroker av hvordan litt JSON på en server blir til et VXLAN VNI spredd utover leaf-switchene i Arista IP-fabricen. Det fungerer ikke dårlig som et team, heller tvert imot, men noen av oss kjenner nok på at utvikler-delen av nettverk har en høy terskel for å jobbe i. Men det betyr også at mange i tech:nett utvikler seg enormt i løpet av TG.
Her har vi noe(!) av dataflyten fra definisjoner til faktisk config/oppsett:
Hva skjer videre nå de neste timene
Det meste er oppe, bortsett fra “gulvet” (det området deltagerne sitter på). Det er det viktigste å få opp, samtidig som det er noe av det siste som kan settes opp. Alt er klart for at aksesswitchene på gulvet kobles til distroene i rackene ute i hallen, og autoprovisjonerer seg.
Ellers har vi noen leveranser igjen til ulike deler av crewfunksjoner, som f.eks. noen sponsorstands. Det må leveres.
Planlegging av nettverket til The Gathering 2025 foregår nå for fullt. Nytt i år er nye sponsorer, som låner oss heftig utstyr og bistår oss med å komme i gang med utstyret deres.
Vi kommer tilbake med mye mer info når vi er klare for å dele. Enn så lenge, takk til Arista for stort engasjement og fleksibilitet, og Palo for lån av kule bokser!
Andre sponsorer, som alle gjør mye for oss, er Nextron, nLogic, Telenor og Nexthop.
En interessert Discord-bruker fyrte av noen gode innspill på hva vi kan skrive om på bloggen. Da følger vi opp, og prøver å skrive noe semifornuftig!
WAN-linken
VI har, som kanskje kjent, en 50 Gbit/s linje fra Telenor. Det er et sponsorat, der vi får kapasitet fra de, mot at vi reklamerer for de.
KANDU, arrangøren av TG, er en LIR hos RIPE. Det vil si at KANDU eier et AS-nummer, med tilknyttet IPv4 og IPv6-prefixer. Via Telenor kan vi annonsere de prefixene KANDU eier. I tillegg har vi fått låne et prefix fra RIPE, og et prefix fra Telenor. Vi har vært heldige, for dette er ingen selvfølge.
Til sammen har vi følgende prefixer vi kan annonsere:
88.92.0.0/17
185.110.148.0/22
151.216.128.0/17
2a06:5840::/29
Det tilsvarer ~65000 IPv4-adresser og ~32 milliarder /64-blokker (ja….)
For å forenkle håndteringen av den (både for Telenor og oss) har vi den levert som 5 x 10 Gbit i et linkaggregat.
Håndtering av DDoS
Vi lever dessverre i en verden der vi må være i stand til å håndtere DDoS. Vi har primært to metoder for å beskytte oss når vi trenger det, og mulighet til å “ringe en venn”.
DDoS-vasking i Telenor sitt nett. Det vil si at Telenor lytter på “flows” (rent volumetrisk), og om de ser en enorm økning av trafikk mot enkeltadresser kobles automagisk “vaskemaskina” til Telenor inn. Den vil da begynne å filtrere.
Vi har også klart ett oppsett for å utføre “remote triggered black hole” via BGP communities. Det gjør at vi enkelt kan ofre en IP-adresse i skipet, ved å via BGP å fortelle at Telenor skal droppe trafikken mot den adressen.
Vi har i tillegg alternativet å kontakte Telenor SOC-en for å håndtere hendelser individuelt.
Vi har noen fornuftige filtere hos Telenor for å police protokoller som er mye benyttet til “DDoS amplification attacks”.
NAT
“This is fine” av Gunshow
Vi vil ikke alltid ha muligheten til å låne IPv4-adresser. Vi ønsker å belage oss på å kun benytte KANDU sitt IPv4 prefix (~1000 adresser), og med det må vi begynne å bruke NAT på IPv4-adresser.
I år gjør vi noe litt utradisjonelt med NAT, med gode grunner.
NAT på wifi
Vi deler ut public adresser fra 151.216.144.0/20 til alle på wifi. Disse public-adressene blir igjen “source NAT-et” bak 85.110.150.0/25. Dette gjør at vi veldig enkelt, uten å vente på at DHCP-leases skal time ut, kan flytte hele nettet inn og ut av NAT.
NAT på kablet nett
Vi vil utover TG23 NAT’e halvparten av deltagerne som er koblet til “multirate 10G”-switchene. Dette for å kunne gjøre en A/B-test av hvor godt det fungerer.
I tillegg vil visse crew NAT-es. Vi får se hvem de heldige blir 🙂
Vi vil source NAT-e disse nettene bak 85.110.150.128/25
Notater om NAT
Vi NAT-er kun IPv4-trafikk
Vi NAT-er ikke trafikk internt i skipet. Kun trafikk som har destination-adresse utenfor skipet blir NAT-et.
Vi ønsker ikke å NAT-e, men ser det som en nødvendig onde. Vi bruker TG23 for å bygge erfaring.
natfw1.tele
Dette er brannmurene vi bruker for å utføre NAT. Det er cluster med 2 x Juniper SRX4600, i et aktiv/passiv-oppsett. Herlighetene ser sånn ut:
PS: Den ene SSD-en sitter veldig løst. _veldig_ løst. Og om man blir fristet til å kjenne etter hvor løst de sitter løst, så blir det stygg kræsj, og noden må formateres. Vi prøvde. To ganger. Så da kommer gaffa til unnsetning.
Det har vært litt frem og tilbake i designet, hovedsakelig rundt følgende
Skal vi terminere L3 for NAT-WIFI og NAT-LAN på r1.tele eller natfw1.tele?
Skal vi ha et “switchelag” mellom natfw1.tele og r1.tele?
Vi får til veldig mye rart, men med mange valg kommer det også en liten haug med pros and cons. Vi valgte å prioritere enkelhet i feilsøk (pga. at flere i tech:net skal kunne feilsøke og jobbe på løsningene), og at provisjoneringssystemene (fap-awx-gondul-tech-template-sammensuriumet) ikke skal bli mer kompliserte enn nødvendige.
Løsningen rent logisk (L3) landet på å bli seende slik ut:
Dette gir oss muligheten til å med én enkelt configlinje velge om et nett skal NAT-es eller ikke. Enten termineres det i VRF:NAT-WIFI eller VRF:NAT-LAN (og dermed NAT-es), eller i “global”, og dermed ikke NAT-es.
Om nettet skal NAT-es styres med denne logikken via én tag i Netbox. Neat stuff!
Wifi vil Martin, med den tyngste Wifi-kompetansen, komme tilbake til 😀
10G til deltagerne kommer vi tilbake til når vi har fått summet oss, og samlet litt mer data. Hittil tilsier statistikken at det er mange med høy båndbredde på NIC-et, men at de gjerne kunne pushet en del mer trafikk. Distroene d1.floor og d2.floor har likt forbruk ingress, mens alle 10G-switchene til deltagerne henger på d1.floor.
Deltagere strømmer inn i skipet og finner plassene sine. Vi tech:net ser utover gulvet, og i våre systemer, at vi nok et år har klart å lage et godt nettverk. (jinx’d!).
Dette får vi til pga. en super innsats fra crew, og pga. sponsorer som strekker seg langt ❤️
Jeg vil spesielt trekke frem tech:support, og deres enorme innsats i å håndterminere mange kilometer med nettverkskabel.
En liten (og langt ifra ukomplett) oversikt over hva som har gitt oss i tech:net hodebry under opprigg
Templating, og alle mulige cornercases som må løses på stående fot
DHCPv6 option 18 injection på en del nettverksswitcher, som gjorde at IPv6 DHCP fungerte dårlig på wifi de fleste steder i skipet. DHCPv6 option 18-pakker ble droppet på r1.tele
Redesign av NAT-løsninga flere ganger
I skrivende stund har vi 657 IPv4-klienter og 370 IPv6-klienter på nett, som tygger unna rundt 2,5 Gbit/s ingress/0,5 Gbit egress 😎
PS: Det er 2. april i dag. Dette er altså ikke en aprilsnarrspøk.
Vi sliter med for mange muggabytes i TP-kablene våre. Kablene har rett og slett blitt mugne under kaldlagring de siste årene.
Av helsemessige årsaker vil ikke de mugne kablene benyttes.
Det pågår nå en heftig koordinering mellom leverandører, Tech-crewet og Logistikk-crewet for å fremskaffe såpass mye kabling. Så får vi se om det blir manuell terminering av plugger, eller om de er ferdigterminert. Mange timer jobb blir det uansett.
Til deg som deltager: Dette er ikke noe å bekymre seg for. Vi håndterer dette, og lager tidenes beste TG \o/
Heia bloggen! Tech:net har holdt på i skipet i rundt ett døgn nå, og vi har fått gjort mye.
Status badstue
Vi har løst varmeproblemene på “tele-rommet”; døra står åpen, og noen av boksene er flyttet ut av rommet. Kjølemaskina på rommet er defekt. Hurra!
Her ser vi r1.tele før vi fikk kontroll på temperaturen:
Status natfw1.tele
Dette clusteret (SRX4600) er flyttet ut av tele-rommet for å få ned varmen i rommet. I tillegg har den ene noden i clusteret dødd, og nLogic og Juniper har skaffet ny boks for den defekte. Takk for fin og problemfri støtte ♥
Status d1.roof
Her har den ene Juniper QFX5120-en dødd. Den skulle stått i et virtual-chassis oppe i taket, og fungere som aggregering for alle distroene på gulvet.
Den fungerte fint da vi preprovisjonerte den på Frivillighetshuset i Oslo, men når den skulle bootes på Hamar så er den jojo under boot. Dette er switcher som kommer fra demodepoet til Juniper, så de kan ha blitt hardt håndtert tidligere.
Juniper og nLogic vil forsøke å få erstattet den før onsdags morgen. Om ikke så blir d1.roof bestående av 2 x QFX5110 istedenfor. Me får sjå.
