कैस्केड से जुड़े दो SoftEther हब एक ही ब्रॉडकास्ट डोमेन साझा करते हैं, इसलिए लूप या दूसरा DHCP सर्वर स्थानीय गलती होना बंद कर देता है और साझा गलती बन जाता है। पूरा जोखिम मॉडल यही है। कैस्केड स्वयं एक कॉन्फ़िगर किया गया क्लाइंट संबंध है: स्थानीय वर्चुअल हब उस पहचान के तहत दूरस्थ सर्वर के हब से जुड़ता है जिसे वह सर्वर अधिकृत करता है। यह बड़े वर्चुअल नेटवर्क के लिए एक निर्माण खंड है, कभी इंटरनेट एग्ज़िट नहीं।

1. तय करें कि लिंक को क्या ले जाना चाहिए

आवश्यकता से शुरू करें, सुविधा से नहीं। कैस्केड हब के बीच दूसरी परत के फ़्रेम ले जाता है, और यही तब चाहिए जब दो साइटों को एक ही Ethernet सेगमेंट जैसा दिखना हो। अगर ज़रूरत केवल कुछ सबनेट तक राउटेड पहुँच है, तो राउटेड पथ सरल है और ऐसे तरीक़ों से विफल होता है जिन्हें देखना आसान है। कैस्केड चुनना आपको साझा ब्रॉडकास्ट, साझा खोज और एक लूप टोपोलॉजी से बाँधता है।

सर्वर को छूने से पहले आवश्यकता एक पंक्ति में लिखें: कौन-सी प्रणालियाँ एक ही तार पर दिखनी चाहिए, और किनको केवल एक रूट चाहिए। जो भी «रूट» कहता है, वह कैस्केड के बाहर है। यही एक वाक्य उन अधिकांश डिज़ाइनों को रोकता है जो डुप्लिकेट पता सेवाओं पर ख़त्म होते हैं।

2. अधिकृत करने वाली पहचान का दायरा तय करें

सर्वर का प्रबंधन करने वाले क्रेडेंशियल और कैस्केड जिस पहचान से जुड़ता है, अलग-अलग रहस्य हैं, और उन्हें मिलाना लंबी पूँछ वाला आम शॉर्टकट है। दूरस्थ हब को एक उपयोगकर्ता या नीति प्रविष्टि चाहिए जो इस कैस्केड को जुड़ने दे। वही प्रविष्टि अधिकृति है; सफल लॉगिन इस बारे में कुछ नहीं कहता कि दूरस्थ हब के पीछे क्या है।

दर्ज करें कि कौन-सा हब शुरू करता है, किस दूरस्थ हब से जुड़ता है और दूरस्थ पहचान कहाँ तक पहुँच सकती है। प्रतिबद्ध होने से पहले दोनों आर्किटेक्चर की तुलना करें:

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

दोनों सिरों के क्रेडेंशियल और पुनर्प्राप्ति निर्देश अद्यतन रखें। दूरस्थ हब पर पासवर्ड बदलना या नीति संपादित करना आपके स्थानीय उपयोगकर्ताओं को छुए बिना कैस्केड तोड़ देता है, और विफलता आम तौर पर चालू पर ख़ाली लिंक के रूप में दिखती है।

3. देखें कि हब पहले से क्या ले जाता है

हब शायद ही अलग-थलग होता है। यह पहले से ही किसी भौतिक एडाप्टर से ब्रिज कर सकता है, वर्चुअल राउटर से राउट कर सकता है या कहीं और कैस्केड कर सकता है, और इनमें से हर जुड़ाव नए संबंध में आ जाता है। इसीलिए «हमने बस दो हब जोड़े» इतनी बार यह सवाल बन जाता है कि ये दो साइटें अब एक ही सेगमेंट क्यों हैं।

एक ही भौतिक सेगमेंट में ब्रिज किए गए और फिर एक-दूसरे से कैस्केड किए गए दो हब लूप बनाते हैं। स्पैनिंग ट्री जोड़ें या इसे न बनाएँ। वही परीक्षण उस हब पर लागू होता है जो पहले से किसी अन्य कैस्केड से लक्ष्य तक पहुँचता है: दूसरा लिंक क्षमता नहीं जोड़ता, वह पथ जोड़ता है।

केवल एक रूट गायब होने के कारण लिंक न जोड़ें; रूट ठीक करें। पहले कागज़ पर टोपोलॉजी बनाएँ, हर ब्रिज और कैस्केड सहित, क्योंकि आरेख दो मिनट लेता है और अधिकांश लूपों को उनके होने से पहले पकड़ लेता है।

4. जुड़ने से पहले पता व्यवस्था सुलझाएँ

जुड़े सेगमेंट डुप्लिकेट सबनेट लाते हैं, और डुप्लिकेट DHCP सर्वर विशिष्ट लक्षण हैं: क्लाइंट जो सर्वर पहले उत्तर देता है उससे लीज़ लेते हैं, इसलिए व्यवहार बेतरतीब दिखता है और रीबूट के बीच बदलता है। पहले से तय करें कि कौन-सा पक्ष पता आवंटन का स्वामी है, और दूरस्थ सेगमेंट को ऐसी श्रेणी दें जो स्थानीय किसी चीज़ से मेल न खाए। दूसरी DHCP सेवा को कैस्केड के ऑनलाइन आने से पहले बंद करें, पहली शिकायत के बाद नहीं।

DNS एक अलग प्रश्न है। कैस्केड फ़्रेम ले जाता है; यह रिज़ॉल्वर कॉन्फ़िगर नहीं करता, और स्थानीय पक्ष पर हल होने वाला नाम लिंक के पार न हल हो सकता है। लुकअप को IP पथ से अलग जाँचें, क्योंकि चलता हुआ ping दोनों में से केवल एक साबित करता है।

5. वास्तविक संसाधन से इसे साबित करें

इच्छित दूरस्थ सेगमेंट पर एक अनुमत सेवा चुनें और पुष्टि करें कि उत्तर कैस्केड से वापस आता है। फिर नाम समाधान के लिए दोहराएँ। यदि लक्ष्य ब्रॉडकास्ट खोज पर निर्भर है, तो एक तार की तुलना में ब्रिज किए गए लिंक पर अलग व्यवहार की अपेक्षा करें, और इसे दोष के रूप में दर्ज करने के बजाय उसकी योजना बनाएँ।

अंत में, टोपोलॉजी लिखें: कौन-सा हब कहाँ कैस्केड करता है, कौन-सी पहचान अधिकृत करती है, कौन-से सेगमेंट ब्रिज हैं और प्रत्येक पर पता आवंटन का स्वामी कौन है। वही टिप्पणी अगले व्यक्ति को ऐसा सेगमेंट गिराए बिना नीति बदलने देती है जिसके होने की उसे जानकारी नहीं थी।

संबंधित लेख