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å.
