आपका BGP सेशन VPC रूट टेबल में क्यों नहीं दिखता

जो कहानी बार-बार दोहराई जाती है वह यह है कि EC2 VPN उपकरण पर चलने वाला राउटिंग डेमॉन BGP के ऊपर आते ही VPC को उसके दूरस्थ प्रीफ़िक्स सिखा देगा। इसका आधा सच है। सेशन ऊपर आता है, और उसकी वजह से VPC की रूट टेबल में कुछ नहीं बदलता, इसलिए पहला लक्षण आमतौर पर एक सबनेट होता है जो ट्रैफ़िक को चुपचाप किसी काली खाई में गिरा देता है।

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

मिथक: BGP चालू करो और VPC प्रीफ़िक्स सीख जाएगा

BGP दो वक्ताओं के बीच बातचीत है, और इस डिज़ाइन में वक्ता आपके उपकरण पर चलने वाला राउटिंग डेमॉन और VPC Route Server का एक एंडपॉइंट हैं जिसे AWS आपकी अपनी सबनेट में रखता है। वह बातचीत प्रीफ़िक्स ले जाती है। वह आपके वर्कलोड सबनेट की रूट टेबल को नहीं छूती, क्योंकि वे टेबल केवल प्रसार के ज़रिये सीखती हैं जिसे हर एक पर सक्षम करना पड़ता है। जब तक ऐसा नहीं होता, VPC का ताना-बाना उस बात से अनजान रहता है जो उपकरण जानता है।

सेटअप के चरण किसी कारण से अलग हैं: जोड़ें, एंडपॉइंट बनाएँ, पीयर करें, फिर प्रसार सक्षम करें।

Route Server एक कंट्रोल प्लेन है, सुरंग नहीं

Route Server एक भी पैकेट को एन्क्रिप्ट, फ़ॉरवर्ड या निरीक्षण नहीं करता। वह इसलिए मौजूद है ताकि उपकरण के साथ BGP का आदान-प्रदान कर सके और परिणामी प्रीफ़िक्स उन रूट टेबलों को सौंप सके जो उन्हें प्राप्त करने के लिए कॉन्फ़िगर हैं। डेटा प्लेन अपरिवर्तित है: पैकेट अब भी उपकरण के नेटवर्क इंटरफ़ेस से निकलते हैं, उसके VPN से यात्रा करते हैं और उसी रास्ते लौटते हैं।

इसका मतलब है कि फ़ॉरवर्डिंग इंस्टेंस पर स्रोत और गंतव्य की जाँच अब भी मायने रखती है, क्योंकि इंस्टेंस अब किसी और को संबोधित ट्रैफ़िक फ़ॉरवर्ड कर रहा है।

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

प्रसार प्रति रूट टेबल है, पूरे VPC के लिए नहीं

रूट सर्वर को VPC से जोड़ना और किसी रूट टेबल पर प्रसार सक्षम करना दो फ़ैसले हैं, और केवल दूसरा ही बदलता है कि सबनेट क्या करता है। छह रूट टेबल वाला VPC एक में प्रसारित प्रीफ़िक्स प्राप्त कर सकता है और बाकी पाँच में नहीं, जो हब सबनेट के लिए बिल्कुल सही है और ठीक वही है जो «आधा काम करता है» वाला उलझाने वाला नतीजा पैदा करता है। जहाँ प्रसार चालू है वहाँ भी कोई प्रतिस्पर्धी रूट जीत सकता है, क्योंकि VPC का रूट चयन सबसे लंबे प्रीफ़िक्स को प्राथमिकता देता है और समान लंबाई पर स्टैटिक रूट को प्रसारित रूट से ऊपर रखता है। यह प्राथमिकता चुपचाप लागू होती है।

उपकरण जिन प्रीफ़िक्स की घोषणा करता है उनकी सूची के बजाय उस विशेष सबनेट की प्रभावी टेबल जाँचें। API इस सवाल का सीधा जवाब देता है: aws ec2 associate-route-server और aws ec2 enable-route-server-propagation --route-table-id <id> वे दो कदम हैं जिन्हें लोग भूल जाते हैं, और aws ec2 describe-route-tables --route-table-ids <id> दिखाता है कि प्रीफ़िक्स route server प्रविष्टि के रूप में आया भी या नहीं।

उपकरण अब भी हर पैकेट ढोता है

पहुँच की घोषणा करना उसे रखने के बराबर नहीं है. BGP सेशन स्थापित रह सकता है जबकि उपकरण का VPN बंद हो, और कभी न बदलने वाली स्टैटिक घोषणा ट्रैफ़िक को मृत रास्ते की ओर खींचती रहती है। Route Server BFD जैसी विफलता पहचान का समर्थन करता है, लेकिन वह पीयर की जीवंतता जाँचता है, उसके पीछे की हर चीज़ की सेहत नहीं।

घोषणा को असली दूरस्थ रूट से बाँधें: जब सुरंग और दूरस्थ नेटवर्क ऊपर हों तब प्रीफ़िक्स की घोषणा करें, और न हों तब उसे वापस लें।

कोई प्रीफ़िक्स वापस लें और देखें क्या होता है

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

किसी रूट को दूसरे उपकरण पर ले जाने से वे सेशन नहीं जाते जो वह ढो रहा था, क्योंकि NAT और फ़ायरवॉल की स्थिति पहले उपकरण पर ही रहती है।

दर्जन भर प्रीफ़िक्स के स्थिर सेट के लिए VPC टेबलों में स्टैटिक रूट ही सस्ता जवाब रहते हैं। Route Server अपनी जगह तब कमाता है जब प्रीफ़िक्स सूची सचमुच बदलती है और वापस लेने की नीति ऐसी चीज़ हो जिसे आप ऑन-कॉल व्यक्ति को समझा सकें।