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 अर्कोभन्दा लामो छ। र त्यो सबनेटको इन्स्ट्यान्सबाट वास्तविक प्रवाह अपेक्षित सुरुङबाट जान्छ, हरियो स्थितिबाट अनुमान नगरी दुवै छेउमा अवलोकन गरिएको।

त्यसपछि स्वीकृत फेलओभर परीक्षण चलाउनुहोस् र बाँकी रहेको मार्गले सेवा बोकेको हेर्नुहोस्। केवल कन्फिगरेसन भिन्नतामा मात्र भएको प्राथमिकता अझै प्राथमिकता होइन।