การกำหนดเส้นทางและการถ่ายโอนข้อมูลเมื่อเกิดความล้มเหลว
ในการออกแบบระบบความพร้อมใช้งานสูงในระดับการกำหนดเส้นทาง (routing-level high-availability) แต่ละไซต์ Customer Edge (CE) จะสร้างพรีฟิกซ์บริการเดียวกันผ่าน Border Gateway Protocol (BGP) เราเตอร์ขาออก (northbound router) จะติดตั้งโฆษณาเส้นทางที่ใช้งานได้เป็นเน็กซ์ฮ็อป Equal-Cost Multi-Path (ECMP) และกลายเป็นจุดที่กระจายทราฟฟิกและลบเส้นทางที่ล้มเหลวออก
VIP บริการ /32 |เราเตอร์ต้นทาง: เน็กซ์ฮ็อปที่มีต้นทุนเท่ากัน | | | ไซต์ CE 1 ไซต์ CE 2 ไซต์ CE 3โฆษณาที่อยู่บริการเป็นเส้นทาง
หัวข้อที่มีชื่อว่า “โฆษณาที่อยู่บริการเป็นเส้นทาง”โฆษณาที่อยู่ IP เสมือน (VIP) แต่ละรายการเป็นเส้นทางโฮสต์ /32 เมื่อบริการเป็น IPv4 สำรองพรีฟิกซ์สำหรับกำหนดเส้นทางเท่านั้น (route-only) สำหรับที่อยู่บริการเหล่านี้ และอย่าเชื่อมโยงพรีฟิกซ์นั้นกับ Virtual Private Cloud (VPC), Virtual Network (VNet), VLAN หรือซับเน็ตในระดับท้องถิ่น เครือข่ายควรเรียนรู้ที่อยู่บริการจากโฆษณาการกำหนดเส้นทาง แทนที่จะเป็น Address Resolution Protocol (ARP) บนเซ็กเมนต์ที่เชื่อมต่ออยู่
การแยกพรีฟิกซ์บริการไว้ต่างหากจะช่วยหลีกเลี่ยงความคลุมเครือระหว่างเส้นทางที่เชื่อมต่อและเส้นทาง BGP นอกจากนี้ยังทำให้นโยบายเส้นทาง การกรอง และการวางแผนกำลังการรองรับมีความชัดเจน จัดสรรพรีฟิกซ์ตามกระบวนการจัดการที่อยู่ขององค์กร และอย่าคัดลอกพรีฟิกซ์สำหรับห้องปฏิบัติการ (lab prefix) ไปยังเครือข่ายอื่น
ให้การกำหนดเส้นทางลบเส้นทางที่ล้มเหลวออก
หัวข้อที่มีชื่อว่า “ให้การกำหนดเส้นทางลบเส้นทางที่ล้มเหลวออก”เซสชัน BGP ที่จัดตั้งขึ้นจะให้สัญญาณความเคลื่อนไหว (liveness signal) แก่เราเตอร์ต้นทาง เมื่อเซสชันถูกปิดหรือตัวจับเวลาการถือครอง (hold timer) หมดอายุ อุปกรณ์ปลายทางอื่น (peer) จะถอนเส้นทางที่เรียนรู้ผ่านเซสชันนั้นออก Bidirectional Forwarding Detection (BFD) ในกรณีที่อุปกรณ์ทั้งสองฝั่งรองรับและเปิดใช้งาน จะสามารถตรวจจับความล้มเหลวได้รวดเร็วยิ่งขึ้น ดังนั้น เวลาในการลู่เข้าหากัน (convergence time) จึงขึ้นอยู่กับโปรโตคอลและตัวจับเวลาที่กำหนดค่าไว้ ซึ่งไม่ได้เกิดขึ้นในทันทีทันใด
เส้นทางสแตติกไม่มีสถานะเซสชันที่เทียบเท่า เส้นทาง ECMP แบบสแตติกยังคงมีสิทธิ์ใช้งานได้หลังจากที่ CE ล้มเหลว เว้นแต่เราเตอร์ของลูกค้าหรือตัวควบคุม Software-Defined Wide Area Network (SD-WAN) จะติดตามเน็กซ์ฮ็อปด้วยกลไกการตรวจสอบความสมบูรณ์ที่รองรับและลบเส้นทางนั้นออก หากไม่มีกลไกดังกล่าว เราเตอร์ก็อาจจะยังคงเลือก CE ที่ล้มเหลวต่อไปและทำให้บางโฟลว์สูญหายไป (blackhole)
กำหนดขนาดเราเตอร์ก่อนกองทัพ CE
หัวข้อที่มีชื่อว่า “กำหนดขนาดเราเตอร์ก่อนกองทัพ CE”เราเตอร์จะเป็นผู้กำหนดจำนวนเส้นทางที่มีต้นทุนเท่ากันที่จะติดตั้ง เปรียบเทียบจำนวนเส้นทาง ECMP สูงสุดกับจำนวนการโฆษณา CE ที่คาดไว้สำหรับแต่ละ VIP เมื่อจำนวนการโฆษณามีมากกว่าขีดจำกัดเส้นทางที่ติดตั้ง ไซต์ CE ที่สมบูรณ์เพิ่มเติมก็อาจจะไม่ถูกใช้งานสำหรับพรีฟิกซ์นั้น
ตรวจสอบตารางการส่งต่อ (forwarding table) ที่ติดตั้ง แทนที่จะพึ่งพาเพียงมุมมองเส้นทางที่ได้รับของ BGP เท่านั้น เนื่องจากคอนโทรลเพลน (control plane) สามารถเก็บผู้สมัครไว้ได้มากกว่าที่ดาต้าเพลน (data plane) ติดตั้งจริง
ถือนโยบายลำดับความชอบ (preference) และ ECMP แยกจากกัน
หัวข้อที่มีชื่อว่า “ถือนโยบายลำดับความชอบ (preference) และ ECMP แยกจากกัน”เส้นทางจะมีต้นทุนเท่ากันก็ต่อเมื่อคุณลักษณะการเลือกเส้นทางและเมตริกทำให้เส้นทางเหล่านั้นเท่ากันเท่านั้น การเปลี่ยนลำดับความชอบในระดับท้องถิ่น (local preference), Multi-Exit Discriminator (MED), ระยะทางระดับการจัดการ (administrative distance) หรือเมตริกเส้นทางสแตติก สามารถทำให้ CE หนึ่งได้รับการเลือกมากกว่าสำหรับ VIP นั่นเป็นนโยบายการนำทางทราฟฟิกที่ถูกต้อง แต่เป็นพฤติกรรมแบบทำงาน/เลือกใช้ (active/preferred) ไม่ใช่การกระจายอย่างเท่าเทียมกัน
ใช้ลำดับความชอบต่อพรีฟิกซ์เฉพาะเมื่อความไม่สมมาตรนั้นเป็นความตั้งใจเท่านั้น ยืนยันว่าเส้นทางที่มีความชอบน้อยกว่าจะสามารถใช้งานได้เมื่อเส้นทางที่ชอบมากกว่าถูกถอนออก และอย่าทิ้งเส้นทางสแตติกที่ชอบมากกว่าไว้โดยไม่มีการติดตามซึ่งยังคงอยู่หลังจากการทำงานของ CE สิ้นสุดลง
แยกเลเบลคอนโทรลเพลนออกจากหลักฐานการรับส่งทราฟฟิก
หัวข้อที่มีชื่อว่า “แยกเลเบลคอนโทรลเพลนออกจากหลักฐานการรับส่งทราฟฟิก”ในการออกแบบที่มีหลายอุโมงค์หรือหลายเส้นทาง เลเบล ACTIVE สามารถระบุเส้นทางที่เลือกสำหรับการซิงโครไนซ์คอนโทรลเพลน โดยไม่ได้พิสูจน์ว่าเส้นทาง ECMP อื่นๆ ไม่ได้นำส่งข้อมูล อย่าอนุมานสถานะการส่งต่อจากเลเบลนั้นเพียงอย่างเดียว ให้ตรวจสอบตารางเส้นทางหรืออุโมงค์ และสังเกตตัวนับทราฟฟิกในทุกเส้นทางที่คาดหวัง
ตรวจสอบเส้นทางที่สมบูรณ์
หัวข้อที่มีชื่อว่า “ตรวจสอบเส้นทางที่สมบูรณ์”สำหรับแต่ละพรีฟิกซ์บริการ ให้ตรวจสอบดังต่อไปนี้ทั้งหมด:
- ทุก CE ที่ตั้งใจจะใช้งานต้องโฆษณาพรีฟิกซ์;
- ตาราง BGP ต้นทางยอมรับเส้นทางที่คาดหวัง;
- ตารางการส่งต่อต้องติดตั้งเส้นทางไม่มากและไม่น้อยไปกว่าที่แพลตฟอร์มรองรับ;
- การถอนการโฆษณาหนึ่งรายการต้องลบเน็กซ์ฮ็อปนั้นออกหลังจากช่วงเวลาการตรวจจับและการลู่เข้าหากันที่กำหนดค่าไว้;
- การตรวจสอบแอปพลิเคชันทำงานสำเร็จผ่านเส้นทางที่เหลืออยู่
ใช้ เวิร์กโฟลว์การวินิจฉัย BGP ของพื้นที่จัดเก็บบทเรียนนี้เพื่อแยกแยะปัญหาการโฆษณา CE ออกจากปัญหาการส่งต่อของระบบต้นทาง