ทำไมเซสชัน BGP ของคุณไม่ปรากฏในตารางเส้นทางของ VPC

เรื่องเล่าที่ถูกพูดซ้ำคือเดมอนจัดเส้นทางบนอุปกรณ์ VPN ใน EC2 จะสอน VPC ให้รู้จักคำนำหน้าเส้นทางระยะไกลของมันทันทีที่ BGP ขึ้น ครึ่งหนึ่งของเรื่องนี้เป็นความจริง เซสชันขึ้นแล้ว แต่ไม่มีอะไรเปลี่ยนในตารางเส้นทางของ 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 คุ้มค่ากับตำแหน่งเมื่อรายการคำนำหน้าเปลี่ยนจริง และนโยบายการถอนเป็นสิ่งที่คุณอธิบายให้คนที่อยู่เวรได้