ทำไม MAC ของ QFX จึงปรากฏใน EVPN แต่ไม่ปรากฏในตารางส่งต่อ

การพบ MAC ในฐานข้อมูล EVPN พิสูจน์ว่า MAC นั้นถูกประกาศหรือรับมาเป็นเส้นทาง และไม่มีอะไรเกินกว่านั้น ตารางส่งต่อเป็นโครงสร้างอีกอย่างหนึ่งที่ถูกโปรแกรมภายหลัง ดังนั้น MAC เดียวกันอาจปรากฏในตารางหนึ่งและหายไปจากอีกตารางหนึ่งได้ ในขณะที่ทุกโปรโตคอลทำงานถูกต้อง การมองผลลัพธ์สองอย่างนี้เป็นสำเนาของกันและกันทำให้วิศวกรไล่ตามความผิดพลาดของ BGP ในขณะที่ช่องว่างจริงคือนโยบายนำเข้าหรือฮอปถัดไปที่ยังแก้ไม่ได้ คำถามที่คุ้มค่าจะถามไม่ใช่แค่ว่า fabric รู้จัก MAC หรือไม่ แต่คือ ขั้นตอนใดที่หยุดส่งต่อ MAC นั้น.

สองตารางที่ตอบคำถามต่างกัน

ใน Junos EVPN ฐานข้อมูลแสดงรายการที่อยู่ MAC แยกตามอินสแตนซ์ พร้อมวิธีที่แต่ละรายการมาถึง: เรียนรู้จากพอร์ตเข้าถึง รับมาในเส้นทาง Type 2 หรือถูกทำเครื่องหมายเป็นส่วนหนึ่งของกลุ่ม multihoming เอกสารอ้างอิงของ Juniper show evpn database ครอบคลุมตัวกรองแยกตาม MAC และแยกตามอินสแตนซ์ที่ทำให้มุมมองอ่านได้ นี่คือสรุประนาบควบคุมที่ใช้คีย์อินสแตนซ์และ MAC ไม่ใช่ตารางที่ฮาร์ดแวร์ใช้สลับเฟรม

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

เส้นทาง Type 2 พา MAC, IP ที่ไม่บังคับ, ป้ายหรือ VNI, ตัวแยกเส้นทาง และฮอปถัดไปที่ระบุ VTEP ปลายทาง สี่สิ่งสามารถพังได้ระหว่างสายกับเส้นทางนั้น: โฮสต์ไม่เคยถูกเรียนรู้ เส้นทางไม่เคยถูกประกาศ ถูกปฏิเสธตอนนำเข้า หรือฮอปถัดไปแก้ไม่ได้ ความล้มเหลวแต่ละแบบทิ้งชุดตารางที่ถูกเติมไว้ต่างกัน และนั่นคือเหตุผลที่ลำดับนี้วินิจฉัยได้

การเรียนรู้ในเครื่องยังคงเกิดขึ้นก่อน

สมมติฐานทั่วไปคือ EVPN เข้ามารับช่วงการเรียนรู้ MAC ดังนั้นฐานข้อมูลว่างต้องหมายถึงปัญหา overlay การเรียนรู้ในเครื่องยังทำงานฝั่งเข้าถึงเหมือนก่อนมี VXLAN: สวิตช์เรียนรู้ MAC ต้นทางของเฟรมที่อนุญาตใน VLAN และบริการที่ถูกต้อง แล้วจึงสร้าง Type 2 ให้เท่านั้น โฮสต์ที่ไม่ได้ส่งเฟรมที่เกี่ยวข้องไม่มีอะไรจะประกาศ. โฮสต์ที่เฟรมถูกทิ้งเพราะสมาชิกภาพ VLAN ตัวกรอง หรือสมาชิกที่ล่มของกลุ่มรวมลิงก์ ดูเหมือนกันจากมุมมองของ overlay

เริ่มที่จุดเชื่อมต่อและเดินหน้าด้วยคำสั่งอ่านอย่างเดียว เป้าหมายคือพิสูจน์ว่าเฟรมจากโฮสต์ผ่านบริการที่ตั้งใจไว้ เพราะไม่มีสิ่งใดปลายทางชดเชยเฟรมที่ไม่เคยมาถึง

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

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

MAC ระยะไกลหายไปที่ใด

MAC ระยะไกลล้มเหลวในทิศทางตรงข้าม และอย่างเงียบ ๆ เส้นทาง Type 2 มาถึง แต่จะเข้าสู่อินสแตนซ์ก็ต่อเมื่อเป้าหมายเส้นทางและ VNI ตรงกับการกำหนดค่าในเครื่อง และจะใช้งานได้ก็ต่อเมื่อฮอปถัดไปแก้เป็น VTEP ที่เข้าถึงได้ ความไม่ตรงกันของเป้าหมายเส้นทางทิ้งเส้นทางที่ถูกต้องไว้ในตาราง BGP ซึ่งไม่มีอินสแตนซ์ใดร้องขอ

อ่านสามมุมมองตามลำดับ: การมีอยู่ของเส้นทาง บันทึกในฐานข้อมูล บันทึกส่งต่อ คำสั่งด้านล่างถาม MAC เดียวกันในแต่ละขั้นตอน และที่อยู่ตัวอย่างทำให้ผลลัพธ์เทียบกันได้

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

ผลลัพธ์เหล่านั้นตอบคำถามแยกกันสามข้อ เส้นทางใน bgp.evpn.0 ที่ไม่มีบันทึกในฐานข้อมูลชี้ไปที่นโยบายนำเข้า เป้าหมายเส้นทาง หรือการกำหนดค่าอินสแตนซ์ บันทึกในฐานข้อมูลที่ไม่มีบันทึกส่งต่อชี้ไปที่การโปรแกรมแพลตฟอร์ม ซึ่งอยู่ในเส้นทางยกระดับอีกเส้นหนึ่ง เส้นทางที่ใช้งานอยู่ซึ่งฮอปถัดไปแก้ไม่ได้เป็นปัญหาการขนส่งหรือป้าย และการดีบัก MAC เท่าใดก็ไม่ซ่อมมัน

การรีบูตที่แก้ปัญหานั้นพิสูจน์ได้น้อยมาก

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

ก่อนหน้าต่างบำรุงรักษาใด ๆ ให้บันทึกสิ่งที่การรีสตาร์ทจะลบ สามคำสั่งนี้พอสำหรับเทียบก่อนและหลัง และไม่เปลี่ยนสิ่งใดบนอุปกรณ์

show evpn database instance blue
show route table bgp.evpn.0
show version

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

สี่ข้อสังเกตที่ตัดสินกรณีส่วนใหญ่

สี่ข้อสังเกตครอบคลุมเกือบทุกกรณี: จุดเชื่อมต่อและบริการของมัน MAC ในฐานะค่าตัวอย่าง สถานะของเส้นทางและฐานข้อมูล และบิลด์ที่ใช้อยู่ เลือก MAC ที่เป็นตัวอย่างชัด ๆ เพื่อไม่ให้ใครเข้าใจผิดว่าเป็นที่อยู่โปรดักชัน: ออกเต็ตแรก 02 หมายถึงที่อยู่ unicast ที่จัดการภายในเครื่อง ออกเต็ตที่เหลือว่าง และดังนั้น 02:00:00:00:00:5c จึงเป็นตัวยึดที่ปลอดภัย

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