ब्रिज किए गए साइटों को अब भी स्थानीय इंटरनेट एग्ज़िट का निर्णय चाहिए

VLAN विस्तार साफ़ तौर पर पास हुआ: दोनों साइटों के होस्ट एक-दूसरे को देखते हैं, फ़ाइल शेयर काम करता है और प्रिंटर जवाब देते हैं। फिर छोटी साइट पर किसी को ध्यान आता है कि हर डाउनलोड दूसरी साइट की इंटरनेट लाइन इस्तेमाल कर रहा है, और टिकट बैंडविड्थ शिकायत के रूप में आता है। ब्रिज ने ठीक वही किया जो उससे माँगा गया था। उसने दो इमारतों के बीच फ़्रेम ढोए, और इंटरनेट के लिए उन फ़्रेमों को कौन सा राउटर उपयोग करना चाहिए, इस पर उसकी कभी कोई राय नहीं थी।

ब्रिज फ़्रेम ढोता है, निर्णय नहीं

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

उस साझा सबनेट पर दो राउटर रखें और दोनों संभावित गेटवे बन जाते हैं, चाहे उनमें से कोई उस क्लाइंट के पास हो जो उसे उपयोग करता है या न हो।

क्लाइंट अपना गेटवे कैसे चुनता है

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

अगर छोटी साइट के क्लाइंट को बड़ी साइट के राउटर के साथ कॉन्फ़िगर किया गया था, तो उसके इंटरनेट फ़्रेम पहले टनल पार करते हैं और वहीं से बाहर निकलते हैं।

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

DHCP को इच्छित एग्ज़िट व्यक्त करने दें

DHCP उत्तर में विकल्प 3 क्लाइंट के सबनेट पर राउटर पतों की सूची प्राथमिकता क्रम में देता है, और क्लाइंट आम तौर पर पहला उत्तर देने वाला ले लेते हैं। तंत्र ठीक है; स्वामित्व वह जगह है जहाँ डिज़ाइन गड़बड़ाते हैं। यह मानने के बजाय कि नज़दीकी DHCP सर्वर नज़दीकी गेटवे देगा, हर साइट पर दर्ज करें कि वास्तविक लीज़ क्या देती है।

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

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

चार चीज़ें अलग-अलग जाँचें

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

वे चार नतीजे बताते हैं कि आपके पास साइट-के-बीच ब्रिज, स्थानीय एग्ज़िट या आकस्मिक बैकहॉल है, और उन्हें इकट्ठा करने में दस मिनट लगते हैं।

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