13 dec. 2025·8 min
Radia Perlmans Spanning Tree: Ett tyst ryggradsnät för Ethernet
Möt Radia Perlman och lär dig hur Spanning Tree Protocol förhindrar Ethernet‑loopar, möjliggör redundans och gjorde stora nätverk stabila och tillförlitliga.
Möt Radia Perlman och lär dig hur Spanning Tree Protocol förhindrar Ethernet‑loopar, möjliggör redundans och gjorde stora nätverk stabila och tillförlitliga.
Ethernet började som ett enkelt sätt att koppla ihop datorer i samma byggnad. När det spreds genom kontor, campus och datacenter förändrades förväntningarna: lokala nät blev inte längre bara ”bra att ha” — de blev rördragningen för e‑post, fildelning, skrivare, telefoner och så småningom hela affärsflöden. När den rördragningen gick sönder, fick allt uppströms problem.
Nätverksbyggare lärde sig också en hård läxa om tillförlitlighet: om du designar ett nät med endast en väg mellan enheter kan en enda trasig kabel eller switch ta ner ett helt område. Den uppenbara lösningen är redundans — extra länkar och extra switchar.
På Ethernets lager 2 kommer redundans dock med en farlig bieffekt: loopar.
Radia Perlman designade Spanning Tree Protocol (STP), mekanismen som låter Ethernet‑nät ha redundans utan att kollapsa av loopar. Hennes bidrag var inte ”större rör” — det var ett praktiskt, distribuerat sätt för switchar att koordinera, enas om en säker vidarebefordringsstruktur och automatiskt anpassa sig när topologin ändras.
STP är en sådan systemkomponent du bara lägger märke till när den saknas eller är felkonfigurerad. När den fungerar ser inget speciellt ut: trafiken flyter, länkarna är uppe och nätet tål fel. Den blockerar tyst precis tillräckligt många vägar för att förhindra loopar, samtidigt som den håller alternativ redo om en aktiv väg går ner.
Vi gör problemet konkret genom att visa hur en Ethernet‑loop ser ut och varför den orsakar stormar och avbrott. Sedan går vi igenom kärnidén bakom STP — hur den behåller redundans men eliminerar loopar — och förklarar, i enkla termer, hur switchar bestämmer vilka länkar som forwardar och vilka som väntar i reserv. I slutet får du en intuitiv modell för varför STP blev grundläggande för lager‑2‑switching och varför Perlmans design fortfarande är viktig även när Ethernet växt långt bortom sina tidiga kontorsrötter.
Tidiga Ethernet‑nät var ofta små och okomplicerade: ett fåtal maskiner på ett delat segment eller, senare, några switchar (och ”bridges”, den äldre termen) som kopplade ihop segment. Om en kabel drogs ur märktes det — men felet var lätt att förstå.
När organisationer lade till fler rum, våningar och byggnader växte nätet sällan som en prydlig ritning. Det växte som en levande varelse: en ny switch här, en "nödkörning" av kabel där, en temporär lösning som tyst blev permanent.
När nät växer på detta sätt läggs extra länkar till av praktiska skäl:
Individuellt kan varje förändring verka harmlös. Tillsammans kan de skapa flera vägar mellan samma switchar.
Redundans är önskvärt eftersom det förbättrar tillgänglighet. Om en länk fallerar kan trafiken ta en annan väg och användarna fortsätta arbeta.
Men på lager 2 (switching) var Ethernet inte designat för att automatiskt ”välja” en väg och ignorera de andra. Switchar forwardar ramar baserat på inlärda adresser och utan ett koordinerande protokoll kan flera vägar bilda en loop.
Det är kärnspänningen: fler kablar kan av misstag bryta nätet. De kopplingar som lades till för att göra saker säkrare kan skapa förhållanden där trafik cirkulerar oändligt och överbelastar länkar och enheter. Spanning Tree skapades för att behålla fördelarna med redundans samtidigt som den förhindrar dessa oavsiktliga, nätverksomfattande självspoisoneringar.
En Ethernet‑switchloop händer när det finns två (eller fler) aktiva lager‑2‑vägar mellan samma switchar — ofta för att någon lagt till en ”backup”‑kabel, kopplat båda uplinks till samma nät eller kopplat switchar i en ring utan en kontrollmekanism. Ramar har ingen hop‑gräns på lager 2, så de kan cirkulera obegränsat.
Viss trafik är menad att översvämmas: broadcasts (som ARP‑förfrågningar) och ”unknown destination”‑ramar (när en switch ännu inte vet vilken port som leder till en MAC‑adress). I en loop kopieras den översvämmade ramen och skickas runt i loopen, sedan kopieras den igen, och igen.
Ett enkelt exempel: en PC frågar ”Vem har 10.0.0.5?” via ARP (broadcast). Med en loop upprepar varje switch broadcasten ut flera portar, och de upprepade kopiorna återkommer till andra switchar. Mycket snabbt spenderar länkar och switch‑CPU mest tid på att hantera dubbletter, med liten kapacitet kvar för verklig trafik.
Switchar lär sig var enheter finns genom att se vilken port en källa MAC‑adress kommer in på. I en loop kan samma enhets ramar komma in på olika portar millisekunder från varandra. Switchen ”byter ständigt åsikt” om var den MAC:en finns och skriver om sin tabell upprepade gånger. Resultatet blir att trafik skickas till fel port, sedan översvämmas och läras om igen.
Dessa effekter kombineras till symtom som folk känner igen: plötsliga nätverksbredda fördröjningar, intermittenta bortkopplingar, telefoner som tappar samtal, Wi‑Fi som “fungerar men är oanvändbart” och ibland ett komplett avbrott när switchar mättas och slutar svara. En enda oavsiktlig patchkabel kan ta ner långt mer än de två enheter den kopplar ihop.
Ethernet får sin resilien från att ha mer än en möjlig väg mellan switchar. Om en kabel klipps kan trafiken ta en annan väg. Men fången är att extra vägar kan av misstag bilda en cirkel — och Ethernet‑ramar har ingen “time to live” för att stoppa dem från att cirkulera för evigt.
Spanning Tree Protocol (STP) löser detta med ett enkelt avtal: behåll redundanta länkar fysiskt anslutna, men gör vissa logiskt inaktiva så att det aktiva nätet bildar ett loopfritt träd.
Tänk på en stad som bygger extra vägar så ambulanser ändå kan nå varje område vid avstängning. Om staden öppnar alla vägar utan regler kan du skapa förvirrande cirkulära rutter där bilister kör runt samma kvarter om och om.
STP fungerar som trafikkontroll:
En nyckel i Radia Perlmans design är att den inte förlitar sig på en controller som talar om för varje switch vad den ska göra. Varje switch deltar, utbyter små meddelanden och når självständigt samma slutsats om vilka länkar som ska forwarda och vilka som ska stå i reserv.
Det gör STP praktiskt i verkliga nät: du kan lägga till switchar, ta bort länkar eller råka ut för fel, och nätet konvergerar till ett säkert vidarebefordringsmönster.
Görs det rätt ger STP två utfall som normalt konfliktar:
Spanning Tree Protocols uppgift är enkel: behåll Ethernet‑redundans utan att låta trafik snurra för evigt i en loop. Den gör det genom att få alla switchar att enas om en enda ”bästa” uppsättning länkar att använda vid varje ögonblick — kallad en spanning‑tree — och sätta extra länkar i standby.
STP väljer först en root bridge, switchen som blir referenspunkten för hela nätet. Tänk på den som ”kartans centrum”. Root bestäms av ett priority‑värde (konfigurerat eller standard) och en unik switch‑identifierare; det lägsta vinner.
Varje switch frågar sedan: “Vad är min bästa väg till root?” STP tilldelar en path cost till varje länk (snabbare länkar får vanligtvis lägre kostnad). Varje switch summerar kostnader längs möjliga rutter och väljer den lägsta summan som sin föredragna väg till root.
Porten som en icke‑root‑switch använder för att nå root på den bästa vägen blir dess root port.
På varje delad förbindelse mellan switchar (ett ”segment”) behöver STP exakt en switch som forwardar trafik mot root. Denna forwardande port är designated port för segmentet. Switchen som annonserar den lägsta kostnaden till root på det segmentet får designated‑rollen.
Portar som inte väljs som root port eller designated port sätts i blocking (STP) eller ett liknande icke‑forwardande tillstånd (nyare varianter). Blocking tar inte bort kabeln eller eliminerar redundans — det stoppar bara porten från att forwarda vanliga Ethernet‑ramar så att en loop inte kan bildas. Om en aktiv länk fallerar kan STP låsa upp en backup‑väg och hålla nätet sammanbundet.
Låt oss göra STP konkret med ett litet nät av fyra switchar:
STP börjar med att välja en referenspunkt: root bridge. Varje switch annonserar ett identifierare ("bridge ID") och det lägsta ID:t vinner.
Anta att S1 har lägst bridge ID. Nu är alla överens: S1 är root.
Varje icke‑root‑switch väljer exakt en port som sin root port: den port som ger bästa väg tillbaka till S1.
För varje länksegment väljer STP en sida att vara designated port (den sida som forwardar trafik för segmentet). Alla portar som varken är root‑port eller designated port blir blocking.
I det här exemplet är det länken S3–S4 där loopen bryts. Om S3 redan når root via S2 kan STP sätta S3:s port mot S4 (eller S4:s port mot S3, beroende på tie‑breaks) i blocking.
Resultat: alla kablar är fortfarande isatta, men det finns bara en aktiv väg mellan två punkter — ingen loop.
Om den aktiva vägen bryts (säg att S2–S3 går ner) utvärderar STP igen. Den tidigare blockerade länken S3–S4 kan övergå till forwarding och återställa anslutningen via S3 → S4 → S1.
Den förändringen är inte omedelbar; STP behöver tid att konvergera för att säkert uppdatera forwarding‑tillståndet utan att återintroducera loopar.
Spanning Tree fungerar bara om varje switch i nätet följer samma regler. Därför spelar standarder roll: många verkliga nät är multi‑vendor, byggda av det som köpts över flera år. Utan ett delat protokoll kanske en leverantörs ”loop‑prevention” inte förstår en annan, och redundans kan bli ett avbrott.
Den traditionella Spanning Tree‑protokollet definieras i IEEE 802.1D. Du behöver inte läsa alla klausuler för att dra nytta av det — huvudpoängen är att 802.1D ger olika leverantörer ett gemensamt språk för hur man väljer root bridge, beräknar path cost och bestämmer vilka portar som ska forwarda eller blockera.
Även när du uppgraderar till nyare varianter (som RSTP eller MSTP) är orsaken densamma: beteendet är standardiserat nog för att enheter ska kunna samordna istället för att gissa.
Switchar koordinerar med små kontrollramar kallade BPDUs (Bridge Protocol Data Units). Tänk på BPDUs som STP:s ”hej‑meddelanden”: de bär de fakta switcharna behöver för att bygga en gemensam bild av topologin — vem de tror är root, hur långt bort det är (cost) och timing‑information.
Eftersom BPDUs utbyts kontinuerligt kan STP reagera när något ändras. Om en länk faller ändras BPDU‑samtalet också och switcharna kan rekonvergera och öppna en tidigare blockerad väg.
En praktisk hake: leverantörer använder ofta olika namn för samma inställningar. En inställning som “port cost”, “edge/PortFast” eller “bpdu guard” kan dyka upp under olika menyer eller formuleras olika. De underliggande STP‑koncepten är konsekventa, men gränssnittsordförrådet är inte alltid det — så det hjälper att översätta funktioner tillbaka till vad 802.1D försöker åstadkomma.
Klassisk STP (IEEE 802.1D) löste loopar, men den kunde vara smärtsamt långsam på att ”läka” efter ett länk‑ eller switchfel. Anledningen är enkel: STP var försiktig. Portar började inte forwarda direkt — de gick igenom tidsstyrda tillstånd (blocking → listening → learning → forwarding). Med standardtimers kunde rekonvergens ta tiotals sekunder (ofta ~30–50 sekunder), tillräckligt länge för att samtal ska tappas, applikationer time‑out:as eller att användare antar att ”nätet är nere”.
Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) behåller samma mål — loopfri forwarding med redundans — men ändrar hur switchar når enighet.
Istället för att vänta ut långa, fasta timers använder RSTP en snabbare handshake mellan switchar för att bekräfta vilka portar som säkert kan forwarda. Den känner också igen att vissa portar kan gå omedelbart:
I enkla termer: RSTP blockerar fortfarande rätt länkar för att förhindra loopar; den behandlar bara inte varje förändring som ett worst‑case‑scenario.
När nät växte blev det begränsande att köra ett enda träd för allt — särskilt med många VLAN och komplex topologi. Multiple Spanning Tree Protocol (MSTP, IEEE 802.1s) låter dig skapa flera spanning‑tree‑instanser och mappa grupper av VLAN till varje instans.
Det betyder att du kan:
Huvudpoängen genom STP → RSTP → MSTP är konsekvent: behåll redundans, förhindra loopar och återställ forwarding snabbare och mer förutsägbart.
Spanning Trees mest underskattade fördel är hur den gör ”extra kablar och switchar” till förutsägbar tillförlitlighet. I företagsmiljö — många skåp, många access‑switchar, ständiga flyttar/tillägg/ändringar — kan lager‑2‑redundans vara en gåva eller en fälla. STP gör det mer sannolikt att det blir en gåva.
Stora nät går sällan ner för att en länk klipps; de går ner för att återhämtningen är rörig. STP hjälper genom att ge ett kontrollerat sätt för nätet att reagera när något ändras:
Många organisationer har STP aktiverat även om de tror att deras topologi är loopfri. Anledningen är pragmatisk: människor gör misstag, dokumentation glider isär och oväntade lager‑2‑vägar uppstår. Med STP på är en oavsiktlig extra patchkabel mer sannolik att leda till en blockerad port än ett hela‑byggnaden‑avbrott.
Moderna datacenter föredrar ofta routade leaf–spine‑arkitekturer (lager 3) eller specifika lager‑2 multipath‑tekniker för att få aktiv/aktiv bandbredd utan att förlita sig på klassisk STP‑konvergens. Det sagt används STP (eller varianter som RSTP/MSTP) fortfarande i campusnät, i edge‑segment och som kompatibilitetslager där ren lager‑3‑drift inte är praktisk.
På stor skala är STP:s verkliga prestation lika mycket operationell som teknisk: den gör redundans hanterbar för vanliga team, inte bara specialister.
STP är enkelt i koncept — förhindra lager‑2‑loopar samtidigt som backup‑vägar finns — men några ihärdiga myter gör att folk stänger av det, felkonfigurerar det eller ”optimerar” det till ett avbrott.
Det är sant att moderna nät ofta förlitar sig på lager‑3‑routing, MLAG och overlay‑designer som minskar behovet av klassisk IEEE 802.1D. Men STP (eller nyare former som RSTP/MSTP) lägger fortfarande ett säkerhetsnät varhelst Ethernet kan bilda en loop av misstag: access‑switchar, tillfälliga eventnät, labb, små filialer och alla miljöer där någon kan koppla två portar samman ”bara för att testa”.
Att inaktivera STP kan förvandla ett harmlöst kabelmisstag till en broadcast‑storm som tar ner ett helt VLAN.
En blockerad port är inte ”död”. Det är en förvaliderad standby‑väg. STP byter medvetet bort en del aktiv kapacitet mot stabilitet: om forwarding‑länken fallerar kan den blockerade länken bli ny väg utan att någon människa skyndar för att lägga om kablar. Team försöker ibland tvinga alla länkar att forwarda genom att stänga av STP, platta ut VLAN eller lägga till unmanaged switches. Det kan se effektivt ut — tills den första loopen smälter nätet.
Redundans hjälper bara när den är designad. Att lägga till extra korslänkar mellan switchar utan plan ökar antalet möjliga loop‑scenarier och gör STP‑beteendet svårare att förutse. Resultatet kan bli oväntade trafikvägar, blockerade uplinks eller längre rekonvergenstid efter ett fel.
Även med STP på kan dåliga inställningar göra verklig skada:
Sammanfattning: STP är inte bara en kryssruta — behandla det som ett kontrollplan. Dokumentera avsikten och validera ändringar innan du rullar ut dem brett.
Spanning Tree‑problem visar sig ofta som ”nätet är långsamt” innan någon inser att det är ett lager‑2‑problem. Några fokuserade kontroller kan spara timmar av gissningsarbete.
När en Ethernet‑loop eller STP‑instabilitet uppträder ser du ofta:
Börja med grunderna:
Bra STP‑hygien är mest process:
Om du vill ha en bredare checklista för att isolera nätverksproblem utöver STP, se network-troubleshooting-basics.
STP är ett bra exempel på ”tyst infrastruktur” och tenderar att felas på väldigt mänskliga sätt: otydlig avsikt, odokumenterad kabling, inkonsekventa konfigurationer och ad‑hoc‑felsökning. Ett praktiskt sätt att minska den risken är att bygga lätta interna verktyg och runbooks kring dina STP‑rutiner.
Med Koder.ai kan team snabbt skapa små webb‑dashboards eller verktyg från en enkel chatt — till exempel ett verktyg som läser in switch‑utdata, markerar aktuell root bridge, flaggar oväntade blockerade portar eller spårar topologiförändringar över tid. Eftersom Koder.ai stöder export av källkod och distribution/hostning (med rollback och snapshots) är det också ett bekvämt sätt att göra ”tribal knowledge” till en underhållen intern tjänst istället för ett enstaka skript på någons laptop.
Radia Perlmans spanning tree‑arbete påminner om att den viktigaste infrastrukturen ofta inte är flashig — den förhindrar helt enkelt kaos. Genom att ge Ethernet ett praktiskt sätt att använda redundanta länkar utan att skapa loopar gjorde STP det säkert att ”lägga till en backupväg” som standard i stället för ett riskfyllt experiment. Den förändringen möjliggjorde större, mer motståndskraftiga lager‑2‑nät i företag, campus och datacenter.
STP antar att något kommer gå fel: en kabel kopplas i fel port, en switch startar om, en länk fladdrar. Istället för att hoppas att operatörer aldrig gör misstag bygger STP ett system som kan absorbera misstag och ändå konvergera till ett säkert tillstånd. Lärdomen är bredare än nätverk: behandla fel som primära krav.
Spanning tree blockerar medvetet vissa länkar så att nätet förblir stabilt. Denna ”spillda kapacitet” är ett byte för förutsägbart beteende. Bra system reserverar ofta marginaler — extra tid, extra kontroller, extra skydd — eftersom att undvika katastrofalt fel är mer värt än att pressa ut sista procenten av utnyttjande.
STP fungerar eftersom varje switch följer samma distribuerade regler och utbyter små kontrollmeddelanden för att enas om en loopfri topologi. Du behöver inte en operatör som manuellt bestämmer vilka portar som ska stängas vid varje ändring. Slutsatsen: när många komponenter måste samarbeta, investera i protokoll och standarder som gör det säkra beteendet till det enklaste beteendet.
Om du bara tar med dig några punkter, låt dem vara: bygg redundans, anta mänskliga fel och automatisera det säkra valet. Den här tankesättet — mer än någon enskild funktion — förklarar varför spanning tree blev en sådan tyst nödvändighet.
Om du vill ha fler lättillgängliga nätverksgrunder, bläddra i bloggen.
Ett Layer‑2‑loop uppstår när switchar har två eller flera aktiva vägar mellan samma segment och bildar en cykel. Eftersom Ethernet‑ramar inte har en hop‑gräns på Layer 2 kan översvämmad trafik (broadcasts och unknown unicasts) cirkulera oändligt och multipliceras, vilket överväldigar länkar och switch‑CPU.
Redundans lägger till alternativa vägar, men utan koordination kan switchar börja forwarda på alla dem. Det skapar en loop där översvämmade ramar replikeras upprepade gånger, vilket leder till broadcast‑stormar och instabil MAC‑inlärning – ofta med nätverks‑vid‑utslag från en enda extra patchkabel.
STP låter redundanta länkar vara fysiskt anslutna men logiskt inaktiva genom att blockera vissa portar så att den aktiva topologin blir ett loopfritt träd. Om en aktiv väg fallerar kan STP överföra en tidigare blockerad port till forwarding för att återställa anslutningen.
STP väljer en root bridge som referenspunkt för hela Layer‑2‑domänen. Den switch med lägst bridge ID (prioritet + unik identifierare) blir root; att välja en avsedd core/distribution‑switch som root hjälper till att hålla trafikvägarna förutsägbara.
Varje icke‑root‑switch väljer en root port: den port som ger lägsta totala path cost tillbaka till root. Path cost baseras på länkhastighet (snabbare länkar får normalt lägre kostnad), och tie‑breakers använder ID för att göra valet deterministiskt.
På varje switch‑till‑switch‑segment väljer STP en designated port som får forwarda för det segmentet (den sida som annonserar bästa vägen till root). Alla portar som varken är root‑port eller designated port blir blocking/discarding, vilket är hur STP bryter loopar.
Det betyder att porten inte forwardar normal användartrafik, så den kan inte delta i en loop. Länken hålls up och kan fortfarande bära STP‑kontrolltrafik; om topologin ändras (t.ex. vid ett fel) kan den blockerade porten bli promoted till forwarding.
BPDUs (Bridge Protocol Data Units) är STP‑kontrollramar som switchar skickar för att dela topologiinfo: vem de tror är root, deras path cost till root och timing‑detaljer. Genom att kontinuerligt utbyta BPDUs kan switcharna upptäcka fel/ändringar och rekonvergera till en säker loopfri topologi.
Klassisk STP (IEEE 802.1D) kan ta tiotals sekunder att rekonvergera eftersom den förlitar sig på försiktiga timers och porttillstånd. RSTP (802.1w) snabbar upp detta med snabbare handskakningar och omedelbara övergångar för vissa portar (särskilt edge/PortFast‑portar), vilket minskar avbrottstiden efter fel.
En praktisk felsökningschecklista är: