तुमचे BGP सेशन VPC रूट टेबलमध्ये का दिसत नाही

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

येथे दोन वेगळ्या गोष्टी मिसळल्या जात आहेत: रूट सर्व्हरसोबत पीअरिंग, आणि टेबलमध्ये रूट इन्स्टॉल करणे.

दंतकथा: BGP वर आणा आणि VPC प्रीफिक्स शिकेल

BGP हा दोन बोलणाऱ्यांमधील संवाद आहे, आणि या रचनेत बोलणारे म्हणजे तुमच्या उपकरणावरील राउटिंग डेमॉन आणि AWS तुमच्या मालकीच्या सबनेटमध्ये ठेवत असलेला VPC Route Server एंडपॉइंट. तो संवाद प्रीफिक्स वाहतो. तो तुमच्या वर्कलोड सबनेटच्या रूट टेबलला स्पर्श करत नाही, कारण ती टेबल केवळ प्रसारातून शिकतात, आणि प्रसार प्रत्येकावर सुरू करावा लागतो. तो होईपर्यंत 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 आपली जागा तेव्हा कमावतो जेव्हा प्रीफिक्स यादी खरोखर बदलते आणि मागे घेण्याचे धोरण असे काही असते जे तुम्ही ऑन-कॉल व्यक्तीला समजावून सांगू शकता.