Je hebt de diagrammen gezien. Busnetwerken. Ringtopologieën. Ze hebben allemaal één fatale fout. Eén enkele breuk in de keten en alles stopt.
Sterrennetwerken zien er veiliger uit. Je hebt een centrale schakelaar. Elk knooppunt wordt erop aangesloten. Als één computer uitvalt, blijft de rest online. Maar er zit een valkuil. Die centrale schakelaar? Het is een enkel punt van mislukking.
Kijk naar de onderstaande opstelling.
![Diagrambeschrijving: Een netwerk met schakelaar A, schakelaar B en schakelaar C. Op elke schakelaar zijn knooppunten aangesloten. Schakelaar A en C zijn verbonden met schakelaar B.]
In dit scenario vormt schakelaar B de ruggengraat. Het verbindt schakelaar A en schakelaar C.
Als schakelaar A faalt, worden de knooppunten op A donker. Maar de knooppunten op B en C praten nog steeds met elkaar. Hetzelfde als schakelaar C faalt. Gedeeltelijke uitval. Beheersbaar.
Maar als Schakelaar B sterft?
Alles gaat naar nul. Het hele netwerk stort in. Waarom? Omdat B de brug is. Geen brug, geen verkeer.
Dit is waar redundantie om de hoek komt kijken. Het gaat niet alleen om back-upstroom of extra harde schijven. Het gaat over architectonische veerkracht.
Wat als we de fysieke indeling veranderen?
Stel je voor dat je een directe link toevoegt tussen Switch A en Switch C. Een redundant segment.
Als schakelaar B faalt, kan A nog steeds met C praten. Het pad verandert. Het verkeer wordt omgeleid. Het netwerk blijft in stand.
Dat is de kern van netwerkredundantie. Het is geen magie. Het is slechts een tweede manier om van punt X naar punt Y te komen.
Maar het toevoegen van kabel is niet genoeg. U hebt protocollen nodig die deze redundantie begrijpen. Anders creëer je lussen. En loops laten netwerken sneller crashen dan een dode schakelaar.
We krabben hier slechts aan de oppervlakte. Het echte werk gebeurt als je begint te praten over spanning tree-protocollen en failover-tijden.
Maar eerst moet je het probleem zien. En het probleem is simpel.
Afhankelijkheid van één enkel punt van falen.
Elimineer dat, en je overleeft de volgende hardwarefout.
De eerste schakelaar sterft. De tweede neemt het over. Het verkeer blijft in beweging.
Dit is het mooie van netwerkredundantie. Je hebt het enige punt van mislukking gedood. Als één stuk hardware zichzelf versteent, blijft de lus gesloten. Het netwerk ademt.
Maar nu hebben we een nieuw probleem.
De lus van de dood
Stel je twee schakelaars voor die met twee verschillende kabels zijn verbonden. Of misschien komt er nog een derde schakelaar bij. Nu heb je overal paden.
Het werkt uitstekend voor redundantie. Totdat dat niet het geval is.
Wanneer een switch een frame verzendt en niet weet waar het naartoe gaat, stroomt het naar elke poort. In een eenvoudige lijntopologie raakt dat frame het einde en stopt het. In een lus? Het stuitert voor altijd.
Uitzendingen vermenigvuldigen zich. Unicast-frames stuiteren heen en weer. Plotseling is uw netwerk niet alleen traag. Het is dood. De CPU op elke switch piekt naar 100%. Pakketten vallen. De hele infrastructuur komt tot stilstand.
Dit is de uitzendstorm. Het is geen functie. Het is een brandoefening.
De lus stoppen
Dus hoe behoud je de fysieke redundantie zonder de logische chaos?
Je hebt een protocol nodig. Iets dat zegt: “Hé, ik zie twee paden. Ik blokkeer er één. Als deze kapot gaat, zal ik de andere deblokkeren.”
Voer Spanning Tree Protocol (STP) in.
Het bestaat al sinds de jaren 80. Het is oud. Het is onhandig. Maar het werkt. STP kijkt naar alle koppelingen tussen schakelaars. Het berekent het beste pad naar de hoofdbrug (de hoofdschakelaar). Vervolgens wordt elke andere redundante link in een blokkeerstatus gezet.
Verkeersstromen. De back-uplijn staat daar stil. Klaar.
Als de primaire kabel wordt doorgesneden? De blokkerende poort wordt wakker. Het wordt actief. Het netwerk geneest.
Het duurt echter een paar seconden. Misschien dertig. In die tijd staren gebruikers naar laadbalken.
De snellere oplossing: snel overspannende boom
Dertig seconden is een eeuwigheid in servertijd. Als u een datacenter runt, of zelfs maar een druk kantoor, is dertig seconden downtime onaanvaardbaar.
Voer Rapid Spanning Tree Protocol (RSTP) of 802.1w in.
Het is hetzelfde basisidee. Blokkeer overbodige links. Deblokkeer ze wanneer dat nodig is. Maar RSTP verkort de convergentietijd van seconden naar fracties van een seconde.
Dit gebeurt door sneller opnieuw te onderhandelen over havenrollen. Er wordt niet gewacht op time-outs. Het praat. Het beslist. Het werkt.
Welke moet je gebruiken?
Als u een modern netwerk bouwt, gebruikt u geen standaard STP. Je gebruikt RSTP. Of zijn neef, Multiple Spanning Tree Protocol (MSTP), waarmee u verschillende spanning tree’s voor verschillende VLAN’s kunt uitvoeren.
Waarom?
Omdat u misschien wilt dat spraak-VLAN’s een ander pad volgen dan data-VLAN’s. Met MSTP kunt u die belasting in evenwicht brengen. Of houd ze tenminste uit elkaars buurt.
Als u Cisco-apparatuur gebruikt, kijkt u waarschijnlijk naar PVST+ (Per-VLAN Spanning Tree). Het is eigendom. Het voert voor elk VLAN een afzonderlijk STP-exemplaar uit.
Het is zwaar voor de CPU. Maar het geeft je gedetailleerde controle.
Het eindresultaat
Redundantie is niet onderhandelbaar
