SoftEther-kaskad: koppla ihop två virtuella hubbar med avsikt
En kaskad kopplar en lokal hubb till en fjärr under en konfigurerad identitet. Den är inte en utgångsnod, och den bär allt dessa hubbar redan bryggar.
Två SoftEther-hubbar som kopplas ihop med en kaskad delar en enda broadcast-domän, så en slinga eller en andra DHCP-server slutar vara ett lokalt fel och blir ett gemensamt. Det är hela riskmodellen. Själva kaskaden är en konfigurerad klientrelation: den lokala virtuella hubben ansluter utåt till en fjärrservers hubb under en identitet som servern tillåter. Den är en byggsten för ett större virtuellt nätverk, aldrig en internetutgång.
1. Bestäm vad länken ska bära
Börja med kravet, inte funktionen. En kaskad flyttar ramar på lager två mellan hubbar, och det är vad du vill när två platser ska se ut som ett enda Ethernet-segment. Om behovet bara är routad åtkomst till några få subnät är en routad väg enklare och misslyckas på sätt som är lättare att se. Att välja en kaskad binder dig till gemensam broadcast, gemensam upptäckt och en enda slingtopologi.
Skriv kravet på en rad innan du rör en server: vilka system som måste se ut att vara på samma ledning, och vilka som bara behöver en rutt. Allt som svarar «en rutt» hör utanför kaskaden. Den här enda meningen förhindrar de flesta konstruktioner som slutar med dubbla adresstjänster.
2. Avgränsa identiteten som auktoriserar det
De inloggningsuppgifter som administrerar en server och den identitet en kaskad använder för att ansluta är olika hemligheter, och att blanda dem är en vanlig genväg med lång svans. Fjärrhubben behöver en användar- eller policy-post som tillåter denna kaskad att ansluta. Den posten är auktorisationen; en lyckad inloggning säger inget om vad som ligger bakom fjärrhubben.
Notera vilken hubb som initierar, vilken fjärrhubb den ansluter till och vad fjärridentiteten kan nå. Jämför de två arkitekturerna innan du förbinder dig:
| 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 |
Håll båda ändarnas inloggningsuppgifter och återställningsinstruktioner aktuella. En lösenordsändring eller policyredigering på fjärrhubben bryter kaskaden utan att röra dina lokala användare, och felet visar sig vanligtvis som en länk som är uppe men tom.
3. Inspektera vad hubben redan bär
En hubb är sällan isolerad. Den bryggar kanske redan till en fysisk adapter, routar genom en virtuell router eller kaskaderar någon annanstans, och var och en av dessa anslutningar följer med in i den nya relationen. Därför blir «vi kopplade bara ihop två hubbar» så ofta till «varför är dessa två platser nu ett segment?».
Två hubbar som bryggas in i samma fysiska segment och sedan kaskadas till varandra bildar en slinga. Lägg till spanning tree eller bygg det inte. Samma test gäller en hubb som redan når målet genom en annan kaskad: en andra länk lägger inte till kapacitet, den lägger till en väg.
Lägg inte till en länk för att en rutt saknas; rätta rutten. Rita topologin på papper först, inklusive varje brygga och kaskad, eftersom diagrammet tar två minuter och fångar de flesta slingor innan de finns.
4. Rensa upp adresseringen innan sammankoppling
Sammanslagna segment för med sig dubbla subnät, och dubbla DHCP-servrar är det klassiska symptomet: klienter tar ett lån från den server som svarar först, så beteendet verkar slumpmässigt och flyttar sig mellan omstarter. Bestäm i förväg vilken sida som äger adresstilldelningen, och ge det avlägsna segmentet ett intervall som inte överlappar något lokalt. Inaktivera den andra DHCP-tjänsten innan kaskaden går online, inte efter det första klagomålet.
DNS är en separat fråga. En kaskad bär ramar; den konfigurerar inte resolvers, och ett namn som löses på den lokala sidan löses kanske inte över länken. Testa uppslaget separat från IP-vägen, eftersom en fungerande ping bara bevisar en av de två.
5. Bevisa det med en riktig resurs
Välj en tillåten tjänst på det avsedda avlägsna segmentet och bekräfta att svaret kommer tillbaka genom kaskaden. Upprepa sedan för namnmatchning. Om målet bygger på broadcast-upptäckt, förvänta dig annat beteende över en bryggad länk än på en enda ledning, och planera för det i stället för att registrera det som ett fel.
Skriv slutligen ned topologin: vilken hubb som kaskaderar vart, vilken identitet som auktoriserar det, vilka segment som är bryggade och vem som äger adresstilldelningen på varje. Den anteckningen är det som låter nästa person ändra en policy utan att ta ned ett segment den inte visste fanns.