Q&A fra Discord
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
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.
Peace out!
