ब्रिज गरिएका साइटहरूलाई अझै स्थानीय इन्टरनेट एक्जिटको निर्णय चाहिन्छ

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

ब्रिजले फ्रेम बोक्छ, निर्णय होइन

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

त्यो साझा सबनेटमा दुई राउटर राख्नुहोस् र दुवै सम्भावित गेटवे बन्छन्, तीमध्ये कुनै एउटा प्रयोग गर्ने ग्राहकको नजिक होस् वा नहोस्।

ग्राहकले आफ्नो गेटवे कसरी छान्छ

RFC 1122 मा वर्णन गरिएको IPv4 निर्णय सरल छ। ग्राहकको जोडिएको सबनेटभित्रको गन्तव्य सिधै ARP मार्फत पुगिन्छ, र त्यसबाहिरको गन्तव्य कन्फिगर गरिएको पूर्वनिर्धारित गेटवेतर्फ जान्छ। यसैकारण साइटहरूबीच एउटै सबनेटको ट्राफिक कुनै राउटरको संलग्नता बिना ब्रिज पार गर्न सक्छ, र यसैकारण इन्टरनेट ट्राफिक ग्राहकले पाएको गेटवे ठेगानामा पूर्ण रूपमा निर्भर छ। दुवै व्यवहार स्वतन्त्र छन्, र काम गर्ने फाइल साझेदारीले पहिलो मात्र प्रमाणित गर्छ।

यदि सानो साइटको ग्राहक ठूलो साइटको राउटरसँग कन्फिगर गरिएको थियो भने, उसका इन्टरनेट फ्रेम पहिले टनेल पार गर्छन् र त्यहीँबाट बाहिर निस्कन्छन्।

VPN उपकरणको आफ्नै पूर्वनिर्धारित मार्ग परिवर्तन गर्दा त्यो ग्राहकको गेटवे सर्दैन, किनकि ग्राहकले उपकरणलाई राउटरको रूपमा प्रयोग नै गर्दैन। उपकरणलाई आफ्नो टाढाको पीयरका लागि छुट्टै मार्ग पनि चाहिन्छ ताकि ती फ्रेम बोक्ने टनेल कायम रहोस्, र यी दुईलाई मिसाउनु नै ब्रिज विस्तारले आफ्नै यातायात ढल्ने बाटो हो।

DHCP लाई अभिप्रेत एक्जिट व्यक्त गर्न दिनुहोस्

DHCP जवाफको विकल्प 3 ले ग्राहकको सबनेटमा राउटर ठेगानाहरूको सूची प्राथमिकता क्रममा दिन्छ, र ग्राहकहरू सामान्यतया पहिलो जवाफ दिने लिन्छन्। संयन्त्र राम्रो छ; स्वामित्व त्यहीँ हो जहाँ डिजाइन बिग्रन्छ। नजिकको DHCP सर्भरले नजिकको गेटवे दिन्छ भनी मान्नुको सट्टा प्रत्येक साइटमा वास्तविक लिजले के दिन्छ लेख्नुहोस्।

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

दुवै साइटका सेटिङ एकै जस्तो देखियोस् भनेर मात्र एउटा गेटवे ठेगाना दुई स्वतन्त्र रूपमा सक्रिय राउटरलाई नदिनुहोस्। ब्रिज गरिएको खण्डभरि साझा भर्चुअल ठेगाना आफ्नै आवश्यकताहरू भएको पहिलो-हप अनावश्यकता डिजाइन हो, र हातले बनाइएको संस्करणले बीचबीचमा प्याकेट हराएको जस्तो देखिने ARP द्वन्द्व उत्पन्न गर्छ। यदि अनुप्रयोगलाई साँच्चै साझा लेयर 2 खण्ड चाहिँदैन भने, स्थानीय पूर्वनिर्धारितसहित छुट्टै राउटेड प्रिफिक्सहरू चलाउन सजिलो र घटनाको समयमा व्याख्या गर्न पनि सजिलो हुन्छ।

चारवटा कुरा अलगअलग परीक्षण गर्नुहोस्

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

ती चार नतिजाले तपाईंलाई साइटहरूबीचको ब्रिज, स्थानीय एक्जिट वा आकस्मिक ब्याकहल छ कि भनी बताउँछन्, र तिनीहरू जम्मा गर्न दस मिनेट लाग्छ।

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