Maak kennis met Radia Perlman en leer hoe Spanning Tree Protocol Ethernet‑lussen voorkomt, redundantie mogelijk maakt en grote netwerken stabiel en betrouwbaar maakte.
Ethernet begon als een eenvoudige manier om computers in hetzelfde gebouw te verbinden. Toen het zich verspreidde over kantoren, campussen en datacenters, veranderden de verwachtingen: lokale netwerken waren niet langer "leuk om te hebben"—ze werden de leidingen voor e-mail, bestanddeling, printers, telefoons en uiteindelijk volledige bedrijfsworkflows. Als die leidingen faalden, faalde alles wat daarvan afhankelijk was.
Netwerkbouwers leerden ook een harde les over betrouwbaarheid: als je een netwerk ontwerpt met slechts één pad tussen apparaten, kan één kapotte kabel of switch een heel gebied platleggen. De voor de hand liggende oplossing is redundantie—extra verbindingen en extra switches.
Op Ethernet's laag 2 brengt redundantie echter een gevaarlijk bijeffect met zich mee: lussen.
Radia Perlman ontwierp het Spanning Tree Protocol (STP), het mechanisme dat Ethernet-netwerken redundantie laat hebben zonder dat ze door lussen in elkaar storten. Haar bijdrage was niet "grotere pijpen" maar een praktische, gedistribueerde manier waarop switches kunnen samenwerken, het eens worden over een veilige forwarding-structuur en automatisch aanpassen als de topologie verandert.
STP is het soort systeem dat je alleen opmerkt als het ontbreekt of verkeerd is geconfigureerd. Als het werkt, lijkt er niets bijzonders: verkeer stroomt, links blijven actief en het netwerk verdraagt storingen. Het blokkeert stilletjes precies genoeg paden om lussen te voorkomen, terwijl het alternatieven gereedhoudt voor het geval een actief pad faalt.
We maken het probleem tastbaar door te laten zien hoe een Ethernet-lus eruitziet en waarom die stormen en uitval veroorzaakt. Daarna lopen we door het kernidee van STP—hoe het redundantie behoudt maar lussen uitschakelt—en leggen we in eenvoudige termen uit hoe switches beslissen welke links forwarden en welke in reserve wachten. Aan het einde heb je een intuïtief model voor waarom STP fundamenteel werd voor laag‑2 switching en waarom Perlmans ontwerp nog steeds van belang is, zelfs nu Ethernet veel groter is gegroeid dan de vroege kantoorscenario's.
Vroege Ethernet-netwerken waren vaak klein en overzichtelijk: een paar machines op een gedeeld segment, of later een paar switches (of "bridges", de oudere term) die segmenten met elkaar verbonden. Als één kabel werd losgekoppeld, viel dat op—maar de fout was makkelijk te doorzien.
Toen organisaties meer kamers, verdiepingen en gebouwen toevoegden, groeide het netwerk zelden als een netjes aangelegd plan. Het groeide als een levend organisme: een nieuwe switch hier, een "nood"-kabel daar, een tijdelijke work-around die stilletjes permanent werd.
Als netwerken zo groeien, worden extra links om praktische redenen toegevoegd:
Op zich lijkt elke wijziging onschuldig. Gezamenlijk kunnen ze echter meerdere paden tussen dezelfde switches creëren.
Redundantie is wenselijk omdat het de uptime verbetert. Als één link faalt, kan verkeer een ander pad nemen en blijven gebruikers productief.
Maar op laag 2 (switching) was Ethernet niet ontworpen om automatisch één pad te kiezen en de anderen te negeren. Switches forwarden frames op basis van geleerde adressen en zonder coördinerend control plane kunnen meerdere paden een lus vormen.
Dat is de kernspanning: meer kabels kunnen per ongeluk het netwerk breken. De verbindingen die zijn toegevoegd om de boel veiliger te maken, kunnen omstandigheden creëren waarin verkeer eindeloos circuleert en links en apparatuur overweldigt. Spanning Tree is bedacht om de voordelen van redundantie te behouden terwijl het deze per ongeluk veroorzaakte, netwerkbrede storingen voorkomt.
Een Ethernet switching-lus ontstaat wanneer er twee (of meer) actieve laag‑2 paden zijn tussen dezelfde switches—vaak omdat iemand een "backup"-kabel toevoegde, beide uplinks op hetzelfde netwerk plugde of switches in een ring verbond zonder een controlemechanisme. Frames hebben op laag 2 geen hoplimiet, dus ze kunnen oneindig blijven circuleren.
Sommige verkeer moet geflood worden: broadcasts (zoals ARP-requests) en "onbekende bestemming"-frames (wanneer een switch nog niet weet op welke poort een MAC-adres zit). In een lus wordt dat gefloodde frame gekopieerd en rond de lus gestuurd, dan weer gekopieerd, enzovoort.
Een simpel voorbeeld: een pc vraagt via ARP "Wie heeft 10.0.0.5?" (broadcast). Met een lus kopieert elke switch die broadcast naar meerdere poorten, en de herhaalde kopieën komen voortdurend bij andere switches terug. Heel snel besteden links en switch-CPU’s het grootste deel van hun tijd aan het verwerken van duplicaten, waardoor er weinig ruimte overblijft voor echt verkeer.
Switches leren waar apparaten zijn door te kijken op welke poort een source MAC-adres binnenkomt. In een lus kunnen frames van hetzelfde apparaat binnen milliseconden op verschillende poorten aankomen. De switch blijft "van gedachten veranderen" over waar die MAC zich bevindt en schrijft zijn tabel steeds opnieuw. Het gevolg is dat verkeer naar de verkeerde poort wordt geforward, daarna geflood en weer verkeerd geleerd.
Deze effecten leiden tot herkenbare symptomen: plotselinge netwerkbrede vertragingen, intermitterende disconnects, telefoons die gesprekken verliezen, Wi‑Fi dat "werkt maar onbruikbaar is" en soms volledige uitval als switches verzadigen en niet meer reageren. Een enkele per ongeluk aangelegde patchkabel kan veel meer platleggen dan de twee apparaten die ermee verbonden zijn.
Ethernet krijgt zijn veerkracht door meer dan één mogelijk pad tussen switches te hebben. Als een kabel wordt doorgesneden, kan verkeer een andere route nemen. Het probleem is dat extra paden per ongeluk een cirkel kunnen vormen—en Ethernet-frames hebben geen "time to live" om ze te stoppen.
Spanning Tree Protocol (STP) lost dit op met een eenvoudige afspraak: houd de redundante links fysiek verbonden, maar schakel er logisch een paar uit zodat het actieve netwerk een lusvrije boom vormt.
Denk aan een stad die extra wegen bouwt zodat ambulances nog steeds elk buurtje kunnen bereiken bij een afsluiting. Als de stad alle wegen opent zonder regels, kunnen verwarrende cirkelroutes ontstaan waar bestuurders steeds om hetzelfde blok blijven rijden.
STP werkt als verkeersregeling:
Een belangrijk onderdeel van Perlmans ontwerp is dat het niet afhankelijk is van een controller die elke switch vertelt wat te doen. Elke switch doet mee, wisselt kleine berichten uit en komt zelfstandig tot dezelfde conclusie over welke links moeten forwarden en welke in reserve moeten blijven.
Dat maakt STP praktisch in echte netwerken: je kunt switches toevoegen, links verwijderen of storingen hebben en het netwerk convergeert naar een veilige forwarding‑staat.
Goed uitgevoerd levert STP twee ogenschijnlijk tegenstrijdige uitkomsten:
Het Spanning Tree Protocol heeft één taak: redundantie bieden zonder dat verkeer voor altijd in een lus blijft draaien. Het doet dat door alle switches hetzelfde "beste" setje links te laten kiezen—de zogenaamde spanning tree—en de extra links in een reserve‑staat te zetten.
STP kiest eerst een root bridge, de switch die als referentiepunt voor het hele netwerk fungeert. Zie het als "het centrum van de kaart." De root wordt bepaald door een priority‑waarde (geconfigureerd of standaard) en een unieke switch‑identifier; de laagste wint.
Elke switch vraagt vervolgens: "Wat is mijn beste pad naar de root?" STP kent aan elke link een path cost toe (snellere links krijgen meestal een lagere cost). Elke switch telt de kosten op langs mogelijke routes en kiest de route met de laagste totale cost als voorkeursroute naar de root.
De poort die een niet‑root switch gebruikt om die beste route naar de root te bereiken, wordt zijn root port.
Op elke gedeelde verbinding tussen switches (een "segment") heeft STP precies één switch nodig die verkeer naar de root forwardt. Die forwarding‑poort is de designated port voor het segment. De switch die het laagste‑cost pad naar de root adverteert op dat segment krijgt de designated‑rol.
Poorten die niet zijn gekozen als root port of designated port worden in blocking (STP) of een vergelijkbare niet‑forwarding‑staat (nieuwere varianten) geplaatst. Blokkeren verwijdert de kabel niet en elimineert geen redundantie—het voorkomt slechts dat die poort normaal Ethernet‑verkeer forwardt, zodat er geen lus kan ontstaan. Als een actief link faalt, kan STP een backuppad ontblokkeren en de connectiviteit behouden.
Laten we STP concreet maken met een klein netwerk van vier switches:
STP begint met het kiezen van één referentiepunt: de root bridge. Elke switch adverteert een identifier (de "bridge ID") en de laagste ID wint.
Stel dat S1 de laagste bridge ID heeft. Nu is iedereen het eens: S1 is de root.
Elke niet‑root switch kiest precies één poort als zijn root port: de poort die het beste pad terug naar S1 biedt.
Voor elk linksegment kiest STP één kant als designated port (de kant die moet forwarden voor dat segment). Elke poort die noch root port noch designated port is, wordt blocking.
In dit voorbeeld wordt de lus geknipt op de link S3–S4. Als S3 al via S2 de root bereikt, kan STP S3's poort naar S4 (of S4's poort naar S3, afhankelijk van tie‑breaks) in blocking zetten.
Resultaat: alle kabels blijven aangesloten, maar er is slechts één actief pad tussen twee punten—geen lus.
Als het actieve pad breekt (bijv. S2–S3 valt uit), evalueert STP opnieuw. De eerder geblokkeerde link S3–S4 kan naar forwarding overgaan en de connectiviteit herstellen via S3 → S4 → S1.
Die verandering is niet meteen; STP heeft tijd nodig om veilig te herstellen (convergentie) zodat de forwarding‑staat kan worden bijgewerkt zonder lussen opnieuw te introduceren.
Spanning Tree werkt alleen als elke switch in het netwerk het eens is over dezelfde regels. Daarom zijn standaarden belangrijk: de meeste echte netwerken zijn multi‑vendor, opgebouwd uit wat er door de jaren heen is aangeschaft. Zonder een gedeeld protocol kan de "luspreventie" van het ene merk het andere merk niet begrijpen, en kan redundantie in een storing veranderen.
Het traditionele Spanning Tree Protocol is gedefinieerd in IEEE 802.1D. Je hoeft de normen niet door te lezen om er baat bij te hebben—het belangrijkste is dat 802.1D verschillende leveranciers een gemeenschappelijke taal geeft voor hoe je een root bridge kiest, path cost berekent en beslist welke poorten forwarden of blokkeren.
Zelfs als je later naar nieuwere varianten (zoals RSTP of MSTP) overstapt, is de reden dat upgrades mogelijk zijn hetzelfde: het gedrag is gestandaardiseerd genoeg zodat apparaten kunnen samenwerken in plaats van te gissen.
Switches coördineren met kleine controleframes genaamd BPDUs (Bridge Protocol Data Units). Zie BPDUs als de "hallo‑berichten" van STP: ze dragen de informatie die switches nodig hebben om een gedeeld beeld van de topologie op te bouwen—wie ze als root zien, hoe ver die is (cost) en timinginformatie.
Omdat BPDUs continu worden uitgewisseld, kan STP reageren als er iets verandert. Als een link faalt, verandert ook het BPDU‑gesprek en kunnen switches reconvergeren en een eerder geblokkeerd pad openen.
Een praktische kanttekening: leveranciers gebruiken vaak verschillende namen voor dezelfde instellingen. Een instelling als "port cost", "edge/PortFast" of "bpdu guard" kan onder andere menu’s verschijnen of anders geformuleerd zijn. De onderliggende STP‑concepten zijn consistent, maar de interface‑vocabulaire niet—dus het helpt functies terug te vertalen naar wat 802.1D probeert te bereiken.
Klassieke STP (IEEE 802.1D) loste lussen op, maar kon erg traag zijn in het "genezen" na een link‑ of switch‑storing. De reden is simpel: STP was voorzichtig. Poorten begonnen niet meteen te forwarden—ze doorliepen getimede staten (blocking → listening → learning → forwarding). Met standaard timers kon reconvergentie tientallen seconden duren (vaak ~30–50 seconden), lang genoeg om telefoongesprekken te laten wegvallen, applicaties time‑outs te laten krijgen of gebruikers te laten denken dat "het netwerk down is".
Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) behoudt hetzelfde doel—lusvrije forwarding met redundantie—maar verandert hoe switches tot overeenstemming komen.
In plaats van lange vaste timers te gebruiken, gebruikt RSTP een snellere handshake tussen switches om te bevestigen welke poorten veilig kunnen forwarden.
Daarnaast herkent RSTP dat sommige poorten direct kunnen overgaan:
In eenvoudige termen: RSTP blokkeert nog steeds de juiste links om lussen te voorkomen; het behandelt veranderingen alleen niet altijd als een worst‑case‑gebeurtenis.
Naarmate netwerken groeiden, werd het draaien van één enkele boom voor alles beperkend—vooral met veel VLANs en complexe topologieën. Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) laat je meerdere spanning‑tree instanties maken en groepen VLANs aan elke instantie toewijzen.
Dat betekent dat je:
De algemene verbetering van STP → RSTP → MSTP is consistent: behoud redundantie, voorkom lussen en herstel forwarding sneller en voorspelbaarder.
Het meest ondergewaardeerde voordeel van Spanning Tree is hoe het "extra kabels en switches" verandert in voorspelbare betrouwbaarheid. Op ondernemingsschaal—veel kastjes, veel access switches, constante verhuizingen/wijzigingen—kan laag‑2 redundantie een geschenk of een valstrik zijn. STP maakt het waarschijnlijker dat het een geschenk is.
Grote netwerken falen zelden omdat één link wordt doorgesneden; ze falen omdat herstel rommelig is. STP helpt door een gecontroleerde manier te bieden waarop het netwerk reageert als er iets verandert:
Veel organisaties laten STP ingeschakeld, zelfs als ze denken dat hun topologie lusvrij is. De reden is pragmatisch: mensen maken fouten, documentatie vervaagt en onverwachte laag‑2 paden ontstaan. Met STP aan is een per ongeluk extra patchkabel waarschijnlijker een geblokkeerde poort dan een gebouwbrede uitval.
Moderne datacenters geven vaak de voorkeur aan gerouteerde leaf–spine‑ontwerpen (laag 3) of specifieke laag‑2 multi‑path technologieën om actief/actief bandbreedte te krijgen zonder afhankelijk te zijn van klassieke STP‑convergentie. Dat gezegd hebbende, STP (of varianten zoals RSTP/MSTP) wordt nog veel gebruikt in campusnetwerken, op randsegmenten en als compatibiliteitslaag waar puur laag 3 niet praktisch is.
Op schaal is STP's echte prestatie net zozeer operationeel als technisch: het maakt redundantie beheersbaar voor gewone teams, niet alleen specialisten.
STP is in concept simpel—voorkom laag‑2 lussen en behoud backuppaden—maar een paar hardnekkige mythen zorgen dat mensen het uitschakelen, verkeerd configureren of "optimaliseren" tot een storing.
Het is waar dat moderne netwerken vaak vertrouwen op laag‑3 routing, MLAG en overlay‑ontwerpen die de behoefte aan klassieke IEEE 802.1D verminderen. Maar STP (of nieuwere vormen zoals RSTP/MSTP) biedt nog steeds een veiligheidsnet waar Ethernet per ongeluk een lus kan vormen: access switches, tijdelijke netwerken bij evenementen, labs, kleine vestigingen en elke omgeving waar iemand twee poorten met elkaar kan verbinden om "even te testen."
Het uitschakelen van STP kan een onschuldige bekabelingsfout veranderen in een broadcast storm die een heel VLAN platlegt.
Een geblokkeerde poort is niet "dood." Het is een vooraf gevalideerd standby‑pad. STP ruilt bewust wat actieve capaciteit in voor stabiliteit: als het forwarding‑pad faalt, kan het geblokkeerde pad direct het nieuwe pad worden zonder dat iemand snel moet herkabelen.
Teams proberen soms alle links forwardend te krijgen door STP uit te zetten, VLANs te flattenen of unmanaged switches toe te voegen. Dat lijkt efficiënt—tot de eerste lus het netwerk smelt.
Redundantie helpt alleen als die doordacht is ontworpen. Extra crosslinks tussen switches toevoegen zonder planning vergroot het aantal mogelijke lus‑scenario’s en maakt STP‑gedrag moeilijker te voorspellen. Het resultaat kan onverwachte verkeerspaden, geblokkeerde uplinks of langere reconvergentie na een storing zijn.
Zelfs met STP ingeschakeld kunnen verkeerde instellingen echte schade aanrichten:
De conclusie: STP is niet zomaar een vinkje—het is een control plane. Behandel het als zodanig, documenteer intentie en valideer wijzigingen voordat je ze breed uitrolt.
STP‑problemen verschijnen vaak als "het netwerk is traag" voordat iemand beseft dat er een laag‑2 probleem is. Een paar gerichte controles kunnen uren giswerk besparen.
Bij een Ethernet‑lus of STP‑instabiliteit zie je vaak:
Begin met de fundamenten:
Goede STP‑hygiëne is vooral proces:
Als je een uitgebreider checklist wilt voor netwerkdiagnose buiten STP, zie de tekstverwijzing naar /blog/network-troubleshooting-basics.
STP is een goed voorbeeld van "stille infrastructuur" en faalt vaak op zeer menselijke manieren: onduidelijke intentie, ongedocumenteerde bekabeling, inconsistente configuraties en ad‑hoc troubleshooting. Een praktische manier om dat risico te verkleinen is door lichte interne tools en runbooks rond je STP‑operaties te bouwen.
Met Koder.ai kunnen teams snel kleine webdashboards of utilities genereren vanuit een eenvoudige chat—zoals een tool die switchoutputs inleest, de huidige root bridge markeert, onverwachte geblokkeerde poorten flagt of topology‑change events in de tijd volgt. Omdat Koder.ai export van broncode en hosting (met rollback en snapshots) ondersteunt, is het ook handig om "tribal knowledge" om te zetten in een onderhouden interne service in plaats van éénmalige scripts op iemands laptop.
Radia Perlmans spanning tree‑werk herinnert ons eraan dat sommige van de belangrijkste infrastructuren niet flashy zijn—ze voorkomen simpelweg chaos. Door Ethernet een praktische manier te geven om redundante links te gebruiken zonder lussen te creëren, maakte STP van "voeg een backuppad toe" een veilige standaard in plaats van een riskant experiment. Die verschuiving maakte grotere, veerkrachtigere laag‑2 netwerken mogelijk in enterprises, campussen en datacenters.
STP gaat ervan uit dat er iets mis zal gaan: een kabel wordt verkeerd aangesloten, een switch reboot, een link flapt. In plaats van hopen dat operators geen fouten maken, bouwt het een systeem dat fouten kan opvangen en toch naar een veilige staat convergeert. De les is breder dan netwerken: behandel faalwijzen als eersteklas eisen.
Spanning Tree blokkeert bewust sommige links zodat het netwerk stabiel blijft. Die "verspilde capaciteit" is een ruilofferte ten gunste van voorspelbaar gedrag. Goede systemen houden vaak ruimte vrij—extra tijd, extra checks, extra vangrails—omdat het vermijden van catastrofale fouten meer waard is dan het uitpersen van het laatste procentje benutting.
STP werkt omdat elke switch dezelfde gedistribueerde regels volgt en kleine controleberichten uitwisselt om het lusvrije gedrag eensgezind te bepalen. Je hoeft niet dat één operator elke verandering handmatig te laten uitvoeren. De les: als veel componenten moeten samenwerken, investeer in protocollen en defaults die het veilige gedrag het makkelijkst maken.
Als je maar een paar punten onthoudt: bouw redundantie, ga uit van menselijke fouten en automatiseer de "veilige keuze." Die denkwijze—meer dan een enkele feature—verklaart waarom spanning tree zo’n stille essentie werd.
Als je meer toegankelijke netwerkfundamenten wilt, bekijk dan de verwijzing naar /blog.
Een Layer 2-lus ontstaat wanneer switches twee of meer actieve paden tussen dezelfde segmenten hebben, waardoor er een cyclus ontstaat. Omdat Ethernet-frames op laag 2 geen hoplimiet hebben, kunnen gefloodde frames (broadcasts en onbekende unicasts) onbeperkt rondcirculeren en zich vermenigvuldigen, waardoor links en switch-CPU’s overbelast raken.
Redundantie voegt alternatieve paden toe, maar zonder coördinatie kunnen switches op al die paden tegelijk forwarden. Dat creëert een lus waarin gefloodde frames herhaaldelijk worden gerepliceerd, wat leidt tot broadcast storms en instabiel MAC-learning—vaak resulterend in netwerkbrede uitval door één extra patchkabel.
STP laat redundante links fysiek aanwezig blijven maar schakelt sommige poorten logisch uit zodat de actieve topologie een lusvrije boom wordt. Als een actief pad uitvalt, kan STP een eerder geblokkeerde poort naar forwarding overzetten om de connectiviteit te herstellen.
STP kiest een root bridge als referentiepunt voor het hele Layer 2-domein. De switch met de laagste bridge ID (prioriteit + unieke identifier) wordt root; het helpt als de bedoelde core/distributieswitch root is, zodat verkeerspaden voorspelbaar blijven.
Elke niet-root switch selecteert één root port: de poort met de laagste totale path cost terug naar de root. Path cost is gebaseerd op link-snelheid (snellere links krijgen doorgaans een lagere cost) en bij gelijkheid worden IDs gebruikt als tie-breaker.
Op elk switch‑naar‑switch segment kiest STP één designated port om voor dat segment te forwarden (de kant die het beste pad naar de root adverteert). Elke poort die noch root port noch designated port is, wordt blocking/discarding—dat is hoe STP lussen doorbreekt.
Het betekent dat de poort geen normaal gebruikersverkeer doorstuurt, zodat die niet kan deelnemen aan een lus. De kabel blijft fysiek verbonden en de poort kan nog STP-controleverkeer verzenden/ontvangen; bij topologieveranderingen kan die geblokkeerde poort worden gepromoveerd naar forwarding.
BPDUs (Bridge Protocol Data Units) zijn STP-controleframes die switches verzenden om topologie-informatie te delen: wie ze als root zien, hun path cost naar die root en timingdetails. Door continu BPDUs uit te wisselen kunnen switches falen of veranderingen detecteren en reconvergeren naar een veilige lusvrije topologie.
Klassieke STP (IEEE 802.1D) kan tientallen seconden nodig hebben om te reconvergeren omdat het vasthoudt aan conservatieve timers en poortstaten. RSTP (802.1w) versnelt dit met snellere handshakes en rapid transitions (vooral voor edge/PortFast-poorten), waardoor uitvaltijd na een storing afneemt.
Een praktische checklist is:
