Dos hubs de SoftEther units per una cascada comparteixen un sol domini de difusió, de manera que un bucle o un segon servidor DHCP deixa de ser un error local i es converteix en un error compartit. Aquest és tot el model de risc. La cascada en si és una relació de client configurada: el hub virtual local es connecta al hub d’un servidor remot sota una identitat que aquell servidor autoritza. És una peça per a una xarxa virtual més gran, mai una sortida a internet.

1. Decidiu què ha de transportar l’enllaç

Comenceu pel requisit, no per la funció. Una cascada mou trames de capa dos entre hubs, que és el que voleu quan dos llocs han de semblar un sol segment Ethernet. Si la necessitat és només accés encaminat a unes quantes subxarxes, una ruta encaminada és més simple i falla de maneres més fàcils de veure. Triar una cascada us compromet amb difusió compartida, descobriment compartit i una sola topologia de bucle.

Escriviu el requisit en una línia abans de tocar cap servidor: quins sistemes han d’aparèixer al mateix cable i quins només necessiten una ruta. Tot el que respon «una ruta» queda fora de la cascada. Aquesta sola frase evita la majoria de dissenys que acaben amb serveis d’adreces duplicats.

2. Delimiteu la identitat que ho autoritza

Les credencials que administren un servidor i la identitat que una cascada fa servir per connectar-se són secrets diferents, i barrejar-los és una drecera habitual amb cua llarga. El hub remot necessita una entrada d’usuari o de política que permeti connectar aquesta cascada. Aquesta entrada és l’autorització; un inici de sessió correcte no diu res sobre què hi ha darrere del hub remot.

Anoteu quin hub inicia, a quin hub remot s’uneix i què pot assolir la identitat remota. Compareu les dues arquitectures abans de comprometre-us:

RequirementRouted pathCascaded segment
Broadcast domainSeparate on each sideShared across the link
Address serviceOne DHCP server per sideMust not run two on one domain
Loop riskRoute loops onlyLayer-two loops if segments overlap

Manteniu al dia les credencials i les instruccions de recuperació dels dos extrems. Un canvi de contrasenya o una edició de política al hub remot trenca la cascada sense tocar els usuaris locals, i la fallada sol aparèixer com un enllaç que està actiu però buit.

3. Inspeccioneu què ja transporta el hub

Un hub poques vegades està aïllat. Potser ja pont a un adaptador físic, encamina a través d’un encaminador virtual o cascada en un altre lloc, i cadascuna d’aquestes connexions es trasllada a la nova relació. Per això «només hem unit dos hubs» tantes vegades es converteix en «per què aquests dos llocs ara són un sol segment?».

Dos hubs pontats al mateix segment físic i després cascadats l’un a l’altre formen un bucle. Afegiu spanning tree o no ho construïu. La mateixa prova s’aplica a un hub que ja arriba a l’objectiu per una altra cascada: un segon enllaç no afegeix capacitat, afegeix un camí.

No afegiu un enllaç perquè falta una ruta; arregleu la ruta. Dibuixeu la topologia en paper primer, incloent-hi cada pont i cascada, perquè el diagrama triga dos minuts i atrapa la majoria de bucles abans que existeixin.

4. Resoleu l’adreçament abans d’unir

Els segments units porten subxarxes duplicades, i els servidors DHCP duplicats són el símptoma clàssic: els clients prenen una concessió del servidor que respon primer, així que el comportament sembla aleatori i es mou entre reinicis. Decidiu per endavant quin costat posseeix l’assignació d’adreces i doneu al segment llunyà un rang que no se solapi amb res local. Desactiveu l’altre servei DHCP abans que la cascada estigui en línia, no després de la primera queixa.

DNS és una qüestió a part. Una cascada transporta trames; no configura resoledors, i un nom que es resol al costat local potser no es resol a través de l’enllaç. Proveu la consulta per separat del camí IP, perquè un ping que funciona només demostra una de les dues coses.

5. Demostreu-ho amb un recurs real

Trieu un servei permès al segment remot previst i confirmeu que la resposta torna per la cascada. Després repetiu-ho per a la resolució de noms. Si l’objectiu depèn del descobriment per difusió, espereu un comportament diferent en un enllaç pontat que en un sol cable, i planifiqueu-ho en lloc d’enregistrar-ho com un defecte.

Finalment, escriviu la topologia: quin hub cascada on, quina identitat ho autoritza, quins segments estan pontats i qui posseeix l’assignació d’adreces a cadascun. Aquesta nota és el que permet a la persona següent canviar una política sense enderrocar un segment que no sabia que existia.

Articles relacionats