AWS VGW सबनेट मार्ग एक VPN बोगदा का निवडू शकत नाही असे का

दोन Site-to-Site VPN कनेक्शन एकाच व्हर्च्युअल खाजगी गेटवेवर संपतात आणि तोच शाखा उपसर्ग जाहीर करतात। सबनेट मार्ग तक्त्यात त्या उपसर्गासाठी गेटवेकडे निर्देश करणारी एक नोंद आहे, आणि बोगद्याचे नाव घेणारे कोणतेही क्षेत्र नाही। म्हणून कनेक्शनमधील प्राधान्य अशा ठिकाणी ठरते ज्याला कन्सोल मार्गनिर्देशन म्हणत नाही। कोणता स्तर निर्णयाचा मालक आहे हे जाणणे म्हणजे कार्यरत स्टँडबाय आणि काहीही न करणारा बदल यातील फरक।

दोन स्तर खेळात आहेत: कोणते गेटवे हे सांगणारा VPC मार्ग, आणि गेटवेची स्वतःची बोगदा निवड। दोन्ही एकत्र केल्यास मार्ग तक्त्यात बरोबर दिसणारे पण एकही पॅकेट न हलवणारे बदल तयार होतात।

एकासारखे दिसणारे दोन स्तर

सबनेट मार्ग एकाच प्रश्नाचे उत्तर देतो: या गंतव्यासाठी कोणती जोडणी? त्याचे लक्ष्य व्हर्च्युअल खाजगी गेटवे आहे, आणि त्याचे मेट्रिक त्याच तक्त्यातील इतर मार्गांशीच स्पर्धा करते। त्या नोंदीत बोगदा एकाला बोगदा दोनपासून किंवा कनेक्शन A ला कनेक्शन B पासून वेगळे करणारे काहीही नाही। अधिक विशिष्ट उपसर्ग हे दुसरे गंतव्य जुळणी आहे, बारीक मार्ग निवड नाही।

गेटवे पुढील प्रश्नाचे उत्तर देतो: त्या उपसर्गासाठी त्याच्याकडे असलेल्या बोगद्यांपैकी कोणता आता रहदारी वाहतो। हा निर्णय बोगद्याच्या आरोग्यावरून आणि ग्राहक गेटवेकडून मिळालेल्या BGP गुणधर्मांवरून येतो, आणि तो कधीही सबनेट मार्ग तक्त्यात दिसत नाही।

VGW प्रत्यक्षात काय तुलना करतो

आरोग्य प्रथम येते। खाली असलेला बोगदा, किंवा न उठलेले BGP सत्र, कोणताही गुणधर्म तपासण्यापूर्वीच हरते। म्हणूनच आधीच अयशस्वी होणाऱ्या कनेक्शनवर मार्ग पुढे जोडल्याने काहीही बदलत नाही।

एकाच उपसर्गासाठी पात्र मार्गांमध्ये AWS लहान AS_PATH ला प्राधान्य देतो। दोन मार्ग लांबीने समान असल्यास तो MED ची तुलना करतो, मार्गातील पहिल्या AS बद्दलच्या नोंदवलेल्या अटींच्या अधीन। लोककथेतील आवृत्तीऐवजी प्रकाशित क्रम वाचा, कारण लोककथा सहसा आरोग्याची पायरी आणि स्थिर मार्गाचा अपवाद वगळते। एक परिणाम: बॅकअप कनेक्शनवर तीन वेळा पुढे जोडल्यास प्राथमिक कठोरपणे लहान होतो, आणि प्राधान्य व्यक्त करण्याची नेहमीची पद्धत हीच आहे।

पुढे जोडणे, आणि ते कधी काहीही करत नाही

पुढे जोडणे ग्राहक गेटवेच्या बाहेर जाणाऱ्या जाहिरातींमध्ये होते, AWS च्या आत नाही। AWS ने टाळावे अशा उपसर्गाला तुम्ही तुमचे ASN दोन किंवा तीन वेळा जोडता, आणि मग AWS त्या कनेक्शनसाठी मोठा मार्ग पाहतो। प्राथमिक कनेक्शन पुढे न जोडलेली जाहिरात ठेवते। दोन्ही कनेक्शन एकाच ASN मधून समान संख्येने पुढे जोडून जाहीर करत असतील, तर तुम्ही कोणतेही प्राधान्य व्यक्त केलेले नाही।

बदलानंतर AWS बाजूला मिळालेला मार्ग तपासा। ग्राहक उपकरण कधीही न सोडलेले पुढे जोडणे AWS ने दुर्लक्ष केलेल्या जोडण्यासारखेच दिसते।

स्थिर मार्ग संपूर्ण युक्तिवादाकडे दुर्लक्ष करतात

कनेक्शन स्थिर मार्गनिर्देशन वापरत असल्यास लांब करण्यासाठी AS_PATH नाही। AWS स्थिर VPN मार्गांना त्याच उपसर्गासाठी BGP ने शिकलेल्या मार्गांवर प्राधान्य असल्याचे नोंदवते, त्यामुळे मिश्र रचना पूर्णपणे गतिशीलसारखी वागत नाही। आधी मार्गनिर्देशनाचा प्रकार ठरवा, नंतर त्यासाठी असलेली प्राधान्य यंत्रणा निवडा।

एकाच उपसर्गाची जाहिरात करणाऱ्या दोन स्थिर कनेक्शनसह उपयुक्त तोटा म्हणजे उपसर्ग: ज्या कनेक्शनचा वापर करायचा आहे त्यावर अधिक विशिष्ट श्रेणीची जाहिरात करा, आणि कोणता मार्ग जिंकतो हे नाही तर कोणते गंतव्य जुळते हे तुम्ही बदलले आहे हे स्वीकारा।

ट्रान्झिट गेटवे वेगळे उत्तर का आहे

ट्रान्झिट गेटवे VPN जोडण्यांवर समान-खर्च बहुमार्गाला आधार देतो, त्यामुळे दोन कनेक्शन एक स्टँडबाय उभे राहण्याऐवजी रहदारी वाटून घेऊ शकतात। त्या रचनेचा अयशस्वी होण्याचा पृष्ठभाग वेगळा आहे: प्रवाह बोगद्यांवर पसरतात, आणि एक बोगदा पडल्यास भाराचा फक्त एक भाग सरकतो। VGW ची कृती ट्रान्झिट गेटवेवर, किंवा उलट, नकलल्यास दोन्ही प्लॅटफॉर्म पूर्ण न करणाऱ्या अपेक्षा निर्माण होतात।

यंत्रणेपूर्वी नमुना निवडा: निश्चित प्राधान्यासह सक्रिय आणि स्टँडबाय, किंवा ECMP सह सक्रिय आणि सक्रिय।

सेट केल्यानंतर काय पडताळायचे

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

मग मंजूर फेलओव्हर चाचणी चालवा आणि टिकून राहिलेला मार्ग सेवा वाहत असल्याचे पाहा। केवळ संरचना भेदात असलेले प्राधान्य अजून प्राधान्य नाही।