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

จากนั้นเรียกใช้การทดสอบการสลับที่ได้รับอนุมัติและดูเส้นทางที่เหลือรอดขนส่งบริการ ความชอบที่มีอยู่เพียงในส่วนต่างของการกำหนดค่าคงยังไม่ใช่ความชอบ