क्यास्केडद्वारा जोडिएका दुई 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. वास्तविक स्रोतले प्रमाणित गर्नुहोस्

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

अन्तमा टोपोलोजी लेख्नुहोस्: कुन हब कहाँ क्यास्केड गर्छ, कुन पहिचानले अनुमति दिन्छ, कुन खण्डहरू ब्रिज छन् र प्रत्येकमा ठेगाना बाँडफाँटको मालिक को हो। त्यही टिप्पणीले अर्को व्यक्तिलाई अस्तित्व थाहा नभएको खण्ड नखसाली नीति बदल्न दिन्छ।

सम्बन्धित लेखहरू