Een persoonlijk stukje internet — in dezelfde categorie als mijn eigen mailserver: niet omdat het moet, maar om zelf te blijven volgen wat er in de internet-engineering-wereld gebeurt.
FROP bestaat om zelf bij te blijven in de wereld van BGP, IP-ruimte en routering — niet als studieobject op een testbank, maar als iets dat daadwerkelijk meedraait op het echte internet. Dezelfde reden als achter mijn eigen mailserver: het kan makkelijker via een grote partij, maar dan mis je precies het soort dingen die het interessant maken.
Ik praat sowieso al veel met anderen over IP-ruimte, BGP-beleid en RPKI — "adviseren" is eigenlijk te groot woord, praten dekt de lading beter — maar zelf had ik nog nooit een eigen ASN aangevraagd. Dat voelde krom. Dus: mijn eigen stukje internet, om te snappen wat er speelt in plaats van er alleen over te horen.
FROP stamt uit mijn studietijd in Enschede: een veelgebruikte placeholder-term daar, zoals "bla" dat elders is. Ook makkelijk te typen — twee lettercombinaties die toevallig lekker dicht bij elkaar op het toetsenbord liggen. Shoutout naar SNT en DND, waar die gewoonte vandaan kwam.
Het RIPE-contactobject voor abuse-meldingen heet officieel "FROP Blackhole Operations", nic-hdl HOLE1. Volledig overbodig serieus voor een netwerk van deze omvang. Precies daarom bestaat het.
De IPv4-ruimte (150.251.61.0/24) heeft trouwens een verrassend verleden: het maakt deel uit van een blok dat IANA in 1991 rechtstreeks toewees aan Solvay S.A., een Belgisch chemieconcern. Pre-RIR-adresruimte, decennia later via een handelaar op de markt gebracht en na opsplitsing bij dit netwerk terechtgekomen.
FROP draait op buggy, een gedeelde hypervisor die gehost is in en verbonden is via ColoClue's DC3-infrastructuur (die toevallig ook een stuk of tien andere VM's host — dit is geen dedicated routertje, dus geheugengebruik is altijd een reële zorg, geen theoretische).
De volledige BGP-configuratie wordt gegenereerd vanuit NetBox: peers, filters, prefix-lists, IRR-macro's — alles komt uit één source-of-truth en wordt met Jinja2 naar een werkende openbgpd-configuratie gerenderd. Handmatig een configregel aanpassen is hier letterlijk niet de bedoeling.
Kant-en-klaar boven knutselwerk. Zelf kunnen snappen wat er draait, boven blindelings een tutorial volgen.
Dat betekent niet dat er geen werk in zit: tussen kant-en-klare bouwstenen is altijd lijm nodig om ze aan elkaar te knopen, en die lijm — de configuratie, de scripts, de integratie — is precies het deel dat ik zelf wil snappen en bouwen.
En, om maar eerlijk te zijn: dit project — deze website incluis — komt tot stand met de nodige hulp van AI. Geen autopilot die zelf een ASN aanvraagt, meer een oneindig geduldige stagiair die net zo lang blijft uitzoeken waarom bgpd -n weer klaagt.
Niet direct FROP-gerelateerd, maar wel tekenend voor hoe dit soort projecten hier lopen: per ongeluk een complete fotomap gewist via sshfs — zonder dat er ooit een shell-commando aan te pas kwam. Ext4-forensics (debugfs, lsdel) liep vervolgens dood: verwijderingen via sshfs komen niet als een gewone unlink in het filesystem-journal terecht, dus "0 deleted inodes found". De uiteindelijke redding kwam niet van het filesystem, maar van de dagelijkse borgmatic-backup: die bleek een sneller en betrouwbaarder zoekregister voor "wat was hier vlak vóór het ongeluk" dan alle forensische trucs bij elkaar.
Een eigen AS live krijgen ging niet in één keer goed. Een kleine bloemlezing van dingen die daadwerkelijk zijn misgegaan, ter geruststelling van iedereen die denkt dat BGP vanzelf werkt:
Een hardnekkige foutmelding leidde tot de conclusie dat de kernel netlink-berichten liet vallen — sockbuffers verhoogd, daemon herstart, probleem "opgelost". Bleek achteraf toeval: het getal waar de diagnose op gebaseerd was, was niet de drop-teller maar de inode-kolom van /proc/net/netlink. Drops stonden gewoon op 0. De echte oorzaak (hieronder) kwam pas boven via strace.
Iemand stuurde een traceroute door met 30 hops en veel heen-en-weer-gekaats tussen mij en mijn upstream. Oorzaak: mijn eigen geadverteerde ruimte was niet lokaal weggegooid (blackhole), dus viel verkeer naar niet-toegewezen adressen terug op de default route — die de upstream vervolgens weer naar mij terugstuurde, want ik ben toch de origin AS. Klassieke "je announcet het, maar routeert het zelf niet af"-blunder.
Een peer van "disabled" naar "enabled" gezet, configuratie herladen — en de sessie bleef gewoon op Idle staan, terwijl de andere kant zichtbaar bleef proberen te verbinden. RFC 4271-detail: een sessie in de Idle-state weigert per specificatie alle inkomende verbindingen, en een reload genereert geen nieuw "start"-signaal voor een sessie die al in Idle geparkeerd stond. Oplossing: een simpel bgpctl neighbor <ip> up. Twee keer tegengekomen tijdens hetzelfde project — dus blijkbaar een les die niet in één keer beklijft.
Zit je op Frys-IX of ColoClue en lijkt het je leuk om te peeren met een AS dat vooral bestaat omdat het kon? Neem gerust contact op via de contactgegevens in het RIPE-object van AS219265.
Drempel voor peering: je netwerk originate minimaal 100 prefixes — een praktische ondergrens om te voorkomen dat een sessie meer beheerslast oplevert dan hij waard is. Ken ik je persoonlijk, dan geldt die drempel niet; dat is dan gewoon aan mij.
IRR — registreer je route/route6-objecten (en je AS-SET) netjes bij een IRR. Prefix-filters worden daaruit gegenereerd, dus als het daar niet klopt, komt het er bij mij ook niet doorheen.
RPKI — Route Origin Validation staat aan: invalid wordt geweigerd, unknown mag. Zorg dat je eigen ROA's kloppen.
ASPA — waar beschikbaar wordt ook op ASPA gevalideerd, als extra check tegen route leaks naast IRR en RPKI.
RTBH is de minimale eis: we kunnen elkaar via een blackhole-community vragen om verkeer naar een specifiek doelwit te droppen, zodat een DDoS niet meteen de hele sessie — of het hele netwerk — belast.
BGP Flowspec heeft mijn voorkeur boven RTBH: geen botte blackhole van een heel prefix, maar gericht filteren op bijvoorbeeld protocol, poort of pakketgrootte. Draai je dat al, dan zet ik dat graag op naast (of in plaats van) RTBH.