SoftEther-kaszkád: két virtuális hub szándékos összekapcsolása
A kaszkád egy helyi hubot kapcsol össze egy távolival egy beállított identitás alatt. Nem kilépési csomópont, és mindent továbbít, amit ezek a hubok már áthidalnak.
A kaszkáddal összekapcsolt két SoftEther-hub egyetlen üzenetszórási tartományt oszt meg, így egy hurok vagy egy második DHCP-kiszolgáló megszűnik helyi hibának lenni, és közös hibává válik. Ez a teljes kockázati modell. Maga a kaszkád beállított klienskapcsolat: a helyi virtuális hub egy távoli kiszolgáló hubjához kapcsolódik kifelé egy identitás alatt, amelyet az a kiszolgáló engedélyez. Építőelem egy nagyobb virtuális hálózathoz, soha nem internetes kilépés.
1. Döntse el, mit kell a kapcsolatnak továbbítania
A követelményből induljon ki, ne a funkcióból. A kaszkád második rétegbeli kereteket mozgat a hubok között, és erre akkor van szükség, amikor két telephelynek egyetlen Ethernet-szegmensnek kell látszania. Ha az igény csak néhány alhálózat felé irányított hozzáférés, az irányított útvonal egyszerűbb, és könnyebben látható módon hibázik. A kaszkád választása megköti Önt a közös üzenetszórás, a közös felderítés és egyetlen huroktopológia mellett.
Írja fel a követelményt egy sorban, mielőtt kiszolgálóhoz nyúl: mely rendszereknek kell ugyanazon a vezetéken látszaniuk, és melyeknek kell csak útvonal. Minden, ami «útvonal» választ ad, a kaszkádon kívül van. Ez az egyetlen mondat megakadályozza a legtöbb olyan tervet, amely kettős címzési szolgáltatásokkal végződik.
2. Határolja be az engedélyező identitást
A kiszolgálót adminisztráló hitelesítő adatok és a kaszkád által használt identitás különböző titkok, és ezek keverése gyakori rövidítés hosszú farokkal. A távoli hubnak olyan felhasználói vagy házirend-bejegyzésre van szüksége, amely engedélyezi ennek a kaszkádnak a csatlakozást. Ez a bejegyzés az engedélyezés; a sikeres bejelentkezés semmit nem mond arról, mi áll a távoli hub mögött.
Jegyezze fel, melyik hub kezdeményez, melyik távoli hubhoz csatlakozik, és mit érhet el a távoli identitás. Mielőtt elköteleződne, hasonlítsa össze a két architektúrát:
| 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 |
Tartsa naprakészen mindkét vég hitelesítő adatait és helyreállítási utasításait. A jelszóváltás vagy házirend-szerkesztés a távoli hubon megszakítja a kaszkádot anélkül, hogy a helyi felhasználókat érintené, és a hiba általában úgy jelenik meg, hogy a kapcsolat él, de üres.
3. Vizsgálja meg, mit továbbít már a hub
Egy hub ritkán elszigetelt. Lehet, hogy már áthidal egy fizikai adaptert, virtuális routeren keresztül irányít, vagy máshová kaszkádol, és ezek a csatlakozások mind bekerülnek az új kapcsolatba. Ezért válik «csak két hubot kapcsoltunk össze» olyan gyakran azzá a kérdéssé, hogy miért egyetlen szegmens ez a két telephely most.
Két hub, amelyeket ugyanabba a fizikai szegmensbe hidaltak, majd egymáshoz kaszkádoltak, hurkot alkot. Adjon hozzá spanning tree-t, vagy ne építse meg. Ugyanez a teszt érvényes arra a hubra, amely már egy másik kaszkádon keresztül eléri a célt: egy második kapcsolat nem ad kapacitást, hanem utat ad.
Ne adjon hozzá kapcsolatot azért, mert hiányzik egy útvonal; javítsa az útvonalat. Először rajzolja fel a topológiát papírra, minden híddal és kaszkáddal, mert az ábra két percet vesz igénybe, és a legtöbb hurkot még létrejöttük előtt elkapja.
4. Rendezze a címzést a csatlakozás előtt
Az összekapcsolt szegmensek kettős alhálózatokat hoznak, és a kettős DHCP-kiszolgálók a klasszikus tünet: az ügyfelek attól a kiszolgálótól vesznek bérletet, amelyik először válaszol, ezért a viselkedés véletlenszerűnek látszik, és újraindítások között mozog. Döntse el előre, melyik oldal birtokolja a címkiosztást, és adjon a távoli szegmensnek olyan tartományt, amely nem fedi semmi helyit. Kapcsolja ki a másik DHCP-szolgáltatást, mielőtt a kaszkád online állapotba kerül, ne az első panasz után.
A DNS külön kérdés. A kaszkád kereteket továbbít; nem állít be feloldókat, és egy helyben feloldódó név lehet, hogy nem oldódik fel a kapcsolaton át. Tesztelje a lekérdezést az IP-útvonaltól külön, mert egy működő ping csak egyet bizonyít a kettőből.
5. Bizonyítsa valódi erőforrással
Válasszon engedélyezett szolgáltatást a szándékolt távoli szegmensen, és erősítse meg, hogy a válasz a kaszkádon keresztül jön vissza. Ezután ismételje meg a névfeloldásra. Ha a cél üzenetszórásos felderítésre támaszkodik, számítson eltérő viselkedésre áthidalt kapcsolat esetén, mint egyetlen vezetéken, és tervezze meg ezt ahelyett, hogy hibaként rögzítené.
Végül írja le a topológiát: melyik hub hová kaszkádol, melyik identitás engedélyezi, mely szegmensek vannak áthidalva, és ki birtokolja a címkiosztást mindegyiken. Ez a feljegyzés teszi lehetővé, hogy a következő ember úgy módosítson házirendet, hogy nem dönti le azt a szegmenst, amelyről nem tudott.