SoftEther-cascade: twee virtuele hubs bewust verbinden
Een cascade verbindt een lokale hub met een externe onder een geconfigureerde identiteit. Het is geen uitgangsknooppunt en het draagt alles wat die hubs al overbruggen.
Twee SoftEther-hubs die door een cascade zijn verbonden, delen één broadcast-domein, dus een lus of een tweede DHCP-server is geen lokale fout meer maar een gedeelde. Dat is het hele risicomodel. De cascade zelf is een geconfigureerde cliëntrelatie: de lokale virtuele hub verbindt naar buiten met de hub van een externe server onder een identiteit die die server autoriseert. Het is een bouwsteen voor een groter virtueel netwerk, nooit een internetuitgang.
1. Beslis wat de link moet dragen
Begin bij de eis, niet bij de functie. Een cascade verplaatst frames van de tweede laag tussen hubs, en dat is wat je wilt wanneer twee locaties als één Ethernet-segment moeten lijken. Als de behoefte alleen gerouteerde toegang tot een paar subnetten is, is een gerouteerde route eenvoudiger en faalt die op manieren die makkelijker te zien zijn. Een cascade kiezen verplicht je tot gedeelde broadcast, gedeelde ontdekking en één lustopologie.
Schrijf de eis in één regel op voordat je een server aanraakt: welke systemen moeten op dezelfde draad lijken te zitten, en welke hebben alleen een route nodig. Alles wat «een route» antwoordt, hoort buiten de cascade. Deze ene zin voorkomt de meeste ontwerpen die eindigen met dubbele adresdiensten.
2. Begrens de identiteit die het autoriseert
De inloggegevens die een server beheren en de identiteit die een cascade gebruikt om te verbinden zijn verschillende geheimen, en ze mengen is een veelvoorkomende sluiproute met een lange staart. De externe hub heeft een gebruiker- of beleidsregel nodig die deze cascade laat verbinden. Die regel is de autorisatie; een geslaagde aanmelding zegt niets over wat er achter de externe hub staat.
Noteer welke hub initieert, bij welke externe hub die zich voegt en wat de externe identiteit kan bereiken. Vergelijk de twee architecturen voordat je je vastlegt:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
Houd de inloggegevens en herstelinstructies van beide kanten actueel. Een wachtwoordwijziging of beleidswijziging op de externe hub breekt de cascade zonder je lokale gebruikers te raken, en de storing verschijnt meestal als een link die omhoog staat maar leeg is.
3. Inspecteer wat de hub al draagt
Een hub is zelden geïsoleerd. Hij overbrugt misschien al een fysieke adapter, routeert via een virtuele router of cascadet ergens anders heen, en elk van die aansluitingen gaat mee de nieuwe relatie in. Daarom wordt «we hebben alleen twee hubs verbonden» zo vaak «waarom zijn deze twee locaties nu één segment?».
Twee hubs die in hetzelfde fysieke segment zijn overbrugd en daarna naar elkaar zijn gecascadet, vormen een lus. Voeg spanning tree toe of bouw het niet. Dezelfde test geldt voor een hub die het doel al via een andere cascade bereikt: een tweede link voegt geen capaciteit toe, hij voegt een pad toe.
Voeg geen link toe omdat er een route ontbreekt; repareer de route. Teken de topologie eerst op papier, inclusief elke brug en cascade, want het diagram kost twee minuten en vangt de meeste lussen voordat ze bestaan.
4. Regel de adressering voor het samenvoegen
Samengevoegde segmenten brengen dubbele subnetten mee, en dubbele DHCP-servers zijn het klassieke symptoom: clients nemen een lease van de server die het eerst antwoordt, dus het gedrag lijkt willekeurig en verschuift tussen herstarts. Beslis vooraf welke kant de adrestoewijzing bezit, en geef het verre segment een bereik dat nergens lokaal mee overlapt. Schakel de andere DHCP-dienst uit voordat de cascade online gaat, niet na de eerste klacht.
DNS is een aparte vraag. Een cascade draagt frames; hij configureert geen resolvers, en een naam die aan de lokale kant wordt opgelost, wordt misschien niet over de link opgelost. Test de opzoeking apart van het IP-pad, want een werkende ping bewijst maar één van de twee.
5. Bewijs het met een echte bron
Kies een toegestane dienst op het bedoelde verre segment en bevestig dat het antwoord via de cascade terugkomt. Herhaal dat daarna voor naamresolutie. Als het doel op broadcast-ontdekking leunt, verwacht dan ander gedrag over een overbrugde link dan op één draad, en plan daarvoor in plaats van het als defect te registreren.
Schrijf ten slotte de topologie op: welke hub waarheen cascadet, welke identiteit dat autoriseert, welke segmenten overbrugd zijn en wie de adrestoewijzing op elk bezit. Die notitie is wat de volgende persoon een beleid laat wijzigen zonder een segment neer te halen waarvan hij niet wist dat het bestond.