ब्रिज केलेल्या साइट्सना अजूनही स्थानिक इंटरनेट एक्झिटचा निर्णय आवश्यक आहे

VLAN विस्तार स्वच्छ पार पडला: दोन्ही साइट्सवरील होस्ट एकमेकांना पाहतात, फाइल शेअरिंग कार्य करते आणि प्रिंटर उत्तर देतात. नंतर लहान साइटवर कोणाच्या तरी लक्षात येते की प्रत्येक डाउनलोड दुसऱ्या साइटची इंटरनेट लाइन वापरत आहे, आणि तिकीट बँडविड्थ तक्रार म्हणून येते. ब्रिजने अगदी मागितले तेच केले. त्याने दोन इमारतींमध्ये फ्रेम्स वाहून नेल्या, आणि त्या फ्रेम्सने इंटरनेटसाठी कोणता राउटर वापरावा याबद्दल त्याला कधीही मत नव्हते.

ब्रिज फ्रेम्स वाहते, निर्णय नाही

लेयर 2 विस्तार दोन ठिकाणांना एकच ब्रॉडकास्ट डोमेन दाखवतो, त्यामुळे ARP विनंत्या, DHCP ब्रॉडकास्ट आणि त्याच सबनेटमधील रहदारी सर्व टनेल ओलांडतात. हीच ती देत असलेली संपूर्ण सेवा आहे. ब्रिजमध्ये काहीही गंतव्य पत्ता तपासत नाही, त्याची साइटच्या अपलिंकशी तुलना करत नाही किंवा रहदारी जवळच्या एक्झिटकडे वळवत नाही. प्रत्येक क्लायंट अजूनही ज्या पत्त्या आणि मास्कसह कॉन्फिगर केला होता त्याचा वापर करून स्वतःचा स्थानिक की दूरचा निर्णय स्वतः घेतो.

त्या सामायिक सबनेटवर दोन राउटर ठेवा आणि दोन्ही संभाव्य गेटवे बनतात, त्यांच्यापैकी एक वापरणाऱ्या क्लायंटजवळ असो वा नसो.

क्लायंट त्याचा गेटवे कसा निवडतो

RFC 1122 मध्ये वर्णन केलेला IPv4 निर्णय सोपा आहे. क्लायंटच्या जोडलेल्या सबनेटमधील गंतव्य सरळ ARP ने गाठले जाते, आणि त्याबाहेरील गंतव्य कॉन्फिगर केलेल्या डीफॉल्ट गेटवेवर जाते. म्हणूनच साइट्समधील त्याच सबनेटची रहदारी कोणत्याही राउटरच्या सहभागाशिवाय ब्रिज ओलांडू शकते, आणि म्हणूनच इंटरनेट रहदारी क्लायंटला मिळालेल्या गेटवे पत्त्यावर पूर्णपणे अवलंबून आहे. दोन्ही वर्तन स्वतंत्र आहेत, आणि कार्यरत फाइल शेअरिंग फक्त पहिले सिद्ध करते.

जर लहान साइटवरील क्लायंट मोठ्या साइटच्या राउटरसह कॉन्फिगर केला असेल, तर त्याच्या इंटरनेट फ्रेम्स आधी टनेल ओलांडतात आणि तिथून बाहेर पडतात.

VPN उपकरणाचा स्वतःचा डीफॉल्ट मार्ग बदलल्याने त्या क्लायंटचा गेटवे हलत नाही, कारण क्लायंट उपकरणाचा राउटर म्हणून अजिबात वापर करत नाही. त्या फ्रेम्स वाहून नेणारी टनेल टिकून राहण्यासाठी उपकरणाला त्याच्या दूरच्या पीअरसाठी वेगळा मार्गही आवश्यक आहे, आणि या दोन्हींचा गोंधळ हाच ब्रिज विस्तार आपलेच वाहतूक कोसळण्याचा मार्ग आहे.

DHCP ला इच्छित एक्झिट व्यक्त करू द्या

DHCP उत्तरातील पर्याय 3 क्लायंटच्या सबनेटवरील राउटर पत्त्यांची यादी प्राधान्यक्रमाने देतो, आणि क्लायंट सामान्यतः प्रथम उत्तर देणारा घेतात. यंत्रणा ठीक आहे; मालकी हीच नकाशे चुकतात ती जागा. जवळचा DHCP सर्व्हर जवळचा गेटवे देईल असे गृहीत धरण्याऐवजी प्रत्येक साइटवर प्रत्यक्ष लीज काय देते ते नोंदवा.

एक समन्वित वाटपकर्ता चालवा, किंवा त्याच धोरणासाठी स्पष्टपणे कॉन्फिगर केलेले दोन, आणि धोरणाला मालक द्या. दूरच्या साइटवर जोडलेला दुसरा स्वतंत्र वाटपकर्ता स्थानिकता निर्माण करत नाही, तो एकाच ब्रॉडकास्ट डोमेनसाठी दोन सत्ता निर्माण करतो.

दोन्ही साइट्सच्या सेटिंग्ज सारख्याच दिसाव्यात म्हणून एक गेटवे पत्ता दोन स्वतंत्रपणे सक्रिय राउटरना देऊ नका. ब्रिज केलेल्या विभागातील सामायिक व्हर्च्युअल पत्ता हा स्वतःच्या आवश्यकता असलेला पहिल्या हॉपचा रिडंडन्सी नकाशा आहे, आणि हाताने बनवलेली आवृत्ती अधूनमधून पॅकेट गमावल्यासारखे दिसणारे ARP संघर्ष निर्माण करते. जर अनुप्रयोगाला खरोखर सामायिक लेयर 2 विभागाची गरज नसेल, तर स्थानिक डीफॉल्टसह वेगळे राउटेड प्रीफिक्स चालवणे सोपे आणि घटनेच्या वेळी समजावणे सोपे आहे.

चार गोष्टी वेगवेगळ्या तपासा

एक नाही, चार निरीक्षणे मागा. प्रत्येक साइटवर नवीन DHCP लीज घ्या आणि मिळालेला राउटर व मास्क नोंदवा. दुसऱ्या साइटवर त्याच सबनेटच्या सेवेपर्यंत पोहोचा आणि मार्ग राउटेड वळसा नाही, ब्रिज आहे याची खात्री करा. प्रत्येक साइटवर सार्वजनिक इंटरनेटमधून काहीतरी आणा आणि कोणत्या अपलिंकने ते वाहून नेले ते सुनिश्चित करा. नंतर टनेल खाली आणा आणि काय तुटते ते पहा, कारण ब्रिज अयशस्वी झाल्यावर सर्व कनेक्टिव्हिटी गमावणारी साइट कोणाच्याही लक्षात न येता दूरच्या गेटवेवर अवलंबून होती.

ती चार निष्कर्ष तुम्हाला सांगतात की तुमच्याकडे साइट्समधील ब्रिज, स्थानिक एक्झिट की अपघाती बॅकहॉल आहे, आणि ते गोळा करण्यास दहा मिनिटे लागतात.

नकाशाचे तत्त्व चमकदार नाही: ब्रिजिंग पोहोच ठरवते, DHCP गेटवे ठरवते, आणि उपकरणावरील राउटिंग तक्ता टनेलचा स्वतःचा मार्ग ठरवतो. तिन्ही वेगळ्या संभाषणांत ठेवा, कारण तिन्ही सुधारण्याचा प्रयत्न करणारा एकच बदल सहसा दोन तोडतो.