SoftEther каскада: съзнателно свързване на два виртуални хъба
Каскадата свързва локален хъб с отдалечен под конфигурирана идентичност. Тя не е изходен възел и пренася всичко, което тези хъбове вече мостят.
Два хъба SoftEther, свързани с каскада, споделят един широкомовен домейн, затова цикъл или втори DHCP сървър престава да бъде локална грешка и става споделена. Това е целият модел на риска. Самата каскада е конфигурирана клиентска връзка: локалният виртуален хъб се свързва към хъба на отдалечен сървър под идентичност, която този сървър разрешава. Тя е градивен блок за по-голяма виртуална мрежа, никога не е изход към интернет.
1. Решете какво трябва да носи връзката
Започнете от изискването, а не от функцията. Каскадата пренася кадри от втори слой между хъбовете и това е, което искате, когато два обекта трябва да изглеждат като един Ethernet сегмент. Ако нуждата е само маршрутизиран достъп до няколко подмрежи, маршрутизираният път е по-прост и се проваля по-видимо. Изборът на каскада ви обвързва със споделено излъчване, споделено откриване и една топология на цикъл.
Напишете изискването в един ред, преди да пипате сървър: кои системи трябва да изглеждат на един и същ кабел и кои се нуждаят само от маршрут. Всичко, което отговаря «маршрут», остава извън каскадата. Това единствено изречение предотвратява повечето проекти, които завършват с дублирани адресни услуги.
2. Очертайте идентичността, която я разрешава
Данните за достъп, с които се администрира сървър, и идентичността, която каскадата използва за свързване, са различни тайни и смесването им е често срещан пряк път с дълга опашка. Отдалеченият хъб се нуждае от запис за потребител или политика, който позволява на тази каскада да се свърже. Този запис е разрешението; успешният вход не казва нищо за това какво стои зад отдалечения хъб.
Запишете кой хъб инициира, към кой отдалечен хъб се присъединява и какво може да достигне отдалечената идентичност. Сравнете двете архитектури, преди да се ангажирате:
| 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 |
Поддържайте актуални данните за достъп и инструкциите за възстановяване на двата края. Промяна на парола или редакция на политика на отдалечения хъб чупи каскадата, без да докосва локалните ви потребители, и повредата обикновено изглежда като връзка, която е вдигната, но празна.
3. Прегледайте какво хъбът вече носи
Хъбът рядко е изолиран. Той може вече да мости към физически адаптер, да маршрутизира през виртуален рутер или да каскадира другаде, и всяко от тези прикачвания се пренася в новата връзка. Затова «свързахме само два хъба» толкова често се превръща в «защо тези два обекта сега са един сегмент?».
Два хъба, мостени в един и същ физически сегмент и след това каскадирани един към друг, образуват цикъл. Добавете spanning tree или не го строете. Същият тест важи за хъб, който вече достига целта през друга каскада: втората връзка не добавя капацитет, а добавя път.
Не добавяйте връзка, защото липсва един маршрут; поправете маршрута. Първо нарисувайте топологията на хартия, включително всеки мост и каскада, защото диаграмата отнема две минути и хваща повечето цикли преди да съществуват.
4. Подредете адресирането преди присъединяване
Съединените сегменти носят дублирани подмрежи, а дублираните DHCP сървъри са класическият симптом: клиентите вземат наем от сървъра, който отговори пръв, затова поведението изглежда случайно и се мести между рестартиранията. Решете предварително коя страна притежава назначаването на адреси и дайте на далечния сегмент диапазон, който не се застъпва с нищо локално. Изключете другата DHCP услуга, преди каскадата да излезе онлайн, а не след първата жалба.
DNS е отделен въпрос. Каскадата пренася кадри; тя не конфигурира резолвери и име, което се решава от локалната страна, може да не се реши през връзката. Тествайте заявката отделно от IP пътя, защото работещ ping доказва само едно от двете.
5. Докажете го с реален ресурс
Изберете разрешена услуга в желания отдалечен сегмент и потвърдете, че отговорът се връща през каскадата. След това повторете за разрешаване на имена. Ако целта разчита на откриване чрез излъчване, очаквайте различно поведение през мостена връзка, отколкото на един кабел, и планирайте това, вместо да го записвате като дефект.
Накрая запишете топологията: кой хъб къде каскадира, коя идентичност го разрешава, кои сегменти са мостени и кой притежава назначаването на адреси във всеки. Тази бележка позволява на следващия човек да промени политика, без да сваля сегмент, за който не е знаел, че съществува.