AWS VGW सबनेट रूट एक VPN टनल क्यों नहीं चुन सकता

दो Site-to-Site VPN कनेक्शन एक ही वर्चुअल प्राइवेट गेटवे पर समाप्त होते हैं और एक ही शाखा प्रीफ़िक्स का ऐलान करते हैं। सबनेट रूट तालिका में उस प्रीफ़िक्स के लिए एक प्रविष्टि है, जो गेटवे की ओर इशारा करती है, और टनल का नाम लेने वाला कोई फ़ील्ड नहीं है। इसलिए कनेक्शनों के बीच वरीयता कहीं ऐसी जगह तय होती है जिसे कंसोल रूटिंग नहीं कहता। यह जानना कि निर्णय किस परत के पास है, काम करने वाले स्टैंडबाय और कुछ न करने वाले बदलाव के बीच का अंतर है।

दो परतें खेल में हैं: VPC रूट जो बताता है कौन सा गेटवे, और गेटवे का अपना टनल चयन। दोनों को मिला देना ऐसे संपादन बनाता है जो रूट तालिका में सही दिखते हैं और कभी एक पैकेट भी नहीं हिलाते।

एक जैसी दिखने वाली दो परतें

सबनेट रूट एक ही प्रश्न का उत्तर देता है: इस गंतव्य के लिए कौन सा अटैचमेंट? इसका लक्ष्य वर्चुअल प्राइवेट गेटवे है, और इसका मेट्रिक केवल उसी तालिका के दूसरे रूट से प्रतिस्पर्धा करता है। उस प्रविष्टि में कुछ भी टनल एक को टनल दो से या कनेक्शन A को कनेक्शन B से अलग नहीं करता। अधिक विशिष्ट प्रीफ़िक्स एक अलग गंतव्य मेल है, बारीक पथ चयन नहीं।

गेटवे अगले प्रश्न का उत्तर देता है: उस प्रीफ़िक्स के लिए रखी गई टनलों में से कौन अब ट्रैफ़िक ढो रही है। वह निर्णय टनल के स्वास्थ्य और ग्राहक गेटवे से मिले BGP विशेषताओं से आता है, और वह कभी सबनेट रूट तालिका में नहीं दिखता।

VGW वास्तव में क्या तुलना करता है

स्वास्थ्य पहले आता है। डाउन टनल, या न उठा BGP सत्र, किसी भी विशेषता को देखे जाने से पहले हार जाता है। इसलिए पहले से विफल कनेक्शन पर पथ को आगे जोड़ने से कुछ नहीं बदलता।

एक ही प्रीफ़िक्स के योग्य पथों में AWS छोटा AS_PATH पसंद करता है। जब दो पथ लंबाई में बराबर हों, तो वह MED की तुलना करता है, पथ के पहले AS के बारे में प्रलेखित शर्त के अधीन। लोककथा वाले संस्करण के बजाय प्रकाशित क्रम पढ़ें, क्योंकि लोककथा आमतौर पर स्वास्थ्य चरण और स्थिर रूट के अपवाद को छोड़ देती है। एक परिणाम: बैकअप कनेक्शन पर तीन आगे जोड़ने से प्राथमिक कड़ाई से छोटा हो जाता है, और वरीयता व्यक्त करने का यही सामान्य तरीका है।

आगे जोड़ना, और कब वह कुछ नहीं करता

आगे जोड़ना ग्राहक गेटवे की बाहर जाने वाली घोषणाओं में होता है, AWS के भीतर नहीं। आप अपना ASN उस प्रीफ़िक्स में दो या तीन बार जोड़ते हैं जिससे AWS को बचना है, और तब AWS उस कनेक्शन के लिए लंबा पथ देखता है। प्राथमिक कनेक्शन बिना आगे जोड़े घोषणा रखता है। यदि दोनों कनेक्शन एक ही ASN से समान संख्या में आगे जोड़कर घोषणा करते हैं, तो आपने कोई वरीयता व्यक्त नहीं की।

बदलाव के बाद AWS की ओर प्राप्त पथ जाँचें। जो आगे जोड़ना ग्राहक उपकरण को कभी नहीं छोड़ा, वह ठीक वैसा ही दिखता है जैसा AWS ने अनदेखा किया हो।

स्थिर रूट पूरी दलील को अनदेखा करते हैं

यदि कनेक्शन स्थिर रूटिंग का उपयोग करता है तो लंबा करने के लिए कोई AS_PATH नहीं है। AWS स्थिर VPN रूट को उसी प्रीफ़िक्स के लिए BGP से सीखे गए रूट पर प्राथमिकता देने वाला प्रलेखित करता है, इसलिए मिश्रित डिज़ाइन पूरी तरह गतिशील जैसा व्यवहार नहीं करता। पहले रूटिंग का प्रकार तय करें, फिर उसके लिए मौजूद वरीयता तंत्र चुनें।

एक ही प्रीफ़िक्स का ऐलान करने वाले दो स्थिर कनेक्शनों के साथ उपयोगी लीवर प्रीफ़िक्स है: जिस कनेक्शन का उपयोग करना है उस पर अधिक विशिष्ट श्रेणी का ऐलान करें, और स्वीकारें कि आपने यह बदला है कि कौन सा गंतव्य मेल खाता है, यह नहीं कि कौन सा पथ जीतता है।

ट्रांज़िट गेटवे अलग उत्तर क्यों है

ट्रांज़िट गेटवे VPN अटैचमेंटों पर समान-लागत बहुपथ का समर्थन करता है, इसलिए दो कनेक्शन एक के स्टैंडबाय रहने के बजाय ट्रैफ़िक साझा कर सकते हैं। उस डिज़ाइन की विफलता सतह अलग है: प्रवाह टनलों पर फैलते हैं, और एक टनल का गिरना भार का केवल एक हिस्सा ही हिलाता है। VGW की विधि को ट्रांज़िट गेटवे पर, या उलटा, नकल करने से ऐसी अपेक्षाएँ बनती हैं जो दोनों में से कोई मंच पूरी नहीं करता।

तंत्र से पहले मॉडल चुनें: तय वरीयता के साथ सक्रिय और स्टैंडबाय, या ECMP के साथ सक्रिय और सक्रिय।

सेट करने के बाद क्या सत्यापित करें

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

फिर स्वीकृत फ़ेलओवर परीक्षण चलाएँ और देखें कि बचा हुआ पथ सेवा ढोता है। जो वरीयता केवल कॉन्फ़िगरेशन अंतर में मौजूद है वह अभी वरीयता नहीं है।