iESI เดียวกันภายในไซต์ แต่ไม่ซ้ำระหว่างไซต์: การเย็บ Junos

เกตเวย์สองคู่ให้บริการศูนย์ข้อมูลสองแห่ง และต้องมีคนตัดสินใจว่าการออกแบบต้องใช้ค่า interconnect ESI กี่ค่า คำตอบคือหนึ่งค่าต่อกลุ่มเกตเวย์ ไม่ใช่หนึ่งค่าต่อ fabric และไม่ใช่หนึ่งค่าต่อเกตเวย์ การทำผิดพลาดจะสร้าง fabric ที่ดูเหมือนกำหนดค่าไว้แล้วแต่เลือก forwarder ผิด หรือรวมสองไซต์ที่ควรแยกจากกันเข้าด้วยกัน กฎและข้อยกเว้นของกฎนี้ควรเขียนไว้ข้างรายการเกตเวย์

สองขอบเขต สองกฎ

ภายในไซต์ เกตเวย์ interconnect ที่สำรองกันทำหน้าที่เป็นจุดปลาย multihomed เดียว จึงใช้ interconnect ESI ค่าเดียวร่วมกัน peer ของเกตเวย์เหล่านี้ต้องเห็นสมาชิกเชิงตรรกะหนึ่งราย ไม่ใช่สองรายที่เป็นอิสระ นั่นคือประเด็นทั้งหมดของค่าที่ใช้ร่วมกัน

ระหว่างไซต์ แต่ละกลุ่มเกตเวย์ได้ค่าของตัวเอง ศูนย์ข้อมูลสองแห่งที่ใช้ตัวระบุร่วมกันจะกลายเป็นกลุ่ม multihomed เดียวในระนาบควบคุม ซึ่งโดยปกติไม่ใช่สิ่งที่การออกแบบการเย็บข้าม WAN ตั้งใจ สองไซต์ในกลุ่มเดียวกันยังสืบทอดโหมดความล้มเหลวของกันและกันด้วย

ภายในไซต์: อัตลักษณ์เดียวสำหรับกลุ่ม

ให้ค่าที่เหมือนกันแก่คู่เกตเวย์บน peer ทั้งสอง ในบริบทบริการเดียวกัน และบันทึกไว้ในทะเบียนตัวระบุของเครือข่าย ไม่ใช่ในเธรดแชต ความไม่ตรงกันระหว่างสมาชิกสองรายคือโหมดความล้มเหลวที่ทำให้เกิดกลุ่มที่มีสมาชิกเดียวและไม่มีสัญญาณเตือนที่ชัดเจน เปรียบเทียบสมาชิกทั้งสองก่อนจะเชื่อว่ามีเซสชันที่ใช้งานได้

โมเดลที่รองรับคือ all-active เอกสารอ้างอิงเดียวกันไม่รวมการทำงานแบบ single-active ตัวระบุ LACP ที่อนุมานอัตโนมัติ และตัวเลือก source-bmac สำหรับอัตลักษณ์การเย็บนี้ การออกแบบที่ถือว่ามีอย่างใดอย่างหนึ่งจึงต้องทบทวนก่อนจะเลือกตัวระบุด้วยซ้ำ ข้อจำกัดนี้เป็นข้อมูลนำเข้าของการออกแบบ ไม่ใช่เชิงอรรถ

ระหว่างไซต์: ค่าที่ต่างกัน หรือการรวมโดยเจตนา

ค่าที่ไม่ซ้ำต่อไซต์ทำให้กลุ่มเกตเวย์สองกลุ่มแยกจากกัน หากเจตนาคือการขยายกลุ่ม multihomed หนึ่งกลุ่มข้ามไซต์จริง ๆ นั่นคือสถาปัตยกรรมอีกแบบที่มีผลต่อความหน่วง ความล้มเหลว และการส่งต่อของตัวเอง และควรตัดสินในฐานะสถาปัตยกรรม ไม่ใช่ในฐานะการเลือกตัวระบุ ขอการตัดสินใจนั้นเป็นลายลักษณ์อักษรก่อนหน้าต่างบำรุงรักษา

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

ข้อความ peer เป็นส่วนหนึ่งของอัตลักษณ์

เกตเวย์แต่ละตัวในกลุ่มแสดงรายการ peer ภายในของตนตามที่อยู่ loopback และความสัมพันธ์นั้นอยู่ที่ระดับ EVPN ส่วนกลาง ไม่ใช่ภายใน MAC-VRF เดี่ยว การวางไว้ในลำดับชั้นที่ผิดเป็นวิธีทั่วไปที่ทำให้เกิดการกำหนดค่าที่ commit ได้แต่ไม่เคยสร้างกลุ่ม อ่านลำดับชั้นอ้างอิงสักครั้งแล้วยึดตามนั้น

ชื่อของข้อความก็ย้ายเช่นกัน Juniper เปลี่ยนชื่อข้อความ interconnect peer-gateways ใน 24.2R1 และคืนรูปแบบเฉพาะ interconnect สำหรับ interconnect ของศูนย์ข้อมูลใน 24.4R1 ดังนั้นตัวอย่างที่นำมาจากรีลีสกลางอาจใช้ชื่อที่เวอร์ชันที่ติดตั้งไม่ยอมรับ หรือกลับกัน บันทึกรีลีสที่ตัวอย่างนั้นมาจากไว้ข้างตัวอย่างนั้นเอง

สิ่งที่การแชร์ iESI ไม่ได้ทำ

ไม่ได้กำหนด route target, VNI หรืออินสแตนซ์ EVPN ท้องถิ่นให้คุณ สิ่งเหล่านั้นยังเป็นการกำหนดค่าแยกที่ต้องตรงกันทั้งสองฝั่ง และ ตัวระบุที่ตรงกันแต่ route target ไม่ตรงกันจะสร้างกลุ่มที่ก่อตัวขึ้นแต่ไม่พาอะไรไปเลย เปรียบเทียบทั้งสองฝั่งของการตั้งค่าเหล่านั้นในการตรวจรอบเดียวกัน

ยังไม่ได้พิสูจน์การเข้าถึงของ peer หรือการเลือก designated forwarder ทดสอบ unicast และพฤติกรรม broadcast และ multicast ที่จำเป็นในกรณีปกติ แล้วทำซ้ำโดยถอดเกตเวย์ออกหนึ่งตัวเพื่อให้สมาชิกที่เหลือพากลุ่มไปคนเดียว

การรันครั้งที่สองนั่นเองที่พิสูจน์ว่ากลุ่มนี้มีจริง

เก็บสมาชิกภาพที่สังเกตได้และบริบทบริการไว้กับผลการทดสอบ การเปลี่ยนแปลงตัวระบุในภายหลังจึงสามารถตรวจได้ในฐานะการเปลี่ยนแปลง multihoming ซึ่งเป็นอย่างนั้นจริง ไม่ใช่การแก้ไขเชิงเครื่องสำอางของสตริง ผลลัพธ์คือหลักฐานเดียวว่าตัวระบุทำสิ่งที่แบบแปลนระบุไว้