AFI และ SAFI: อ่านคู่หมายเลขก่อนชื่อบริการ
AFI 25 กับ SAFI 65 ไม่ใช่บริการเดียวกับ AFI 25 กับ SAFI 70 อ่านคู่ก่อน แล้วตรวจการแลกเปลี่ยนแฟมิลี เส้นทาง และผลลัพธ์การส่งต่อ
คุณอาจเห็นเซสชันขึ้นมา เห็นเส้นทางปรากฏ และยังอ่านบริการผิดอยู่ คู่หมายเลขที่ขึ้นต้นทุกประกาศ ตัวระบุแฟมิลีที่อยู่และตัวระบุแฟมิลีที่อยู่ถัดไปเป็นตัวกำหนดว่าตัวแยกวิเคราะห์ตัวใดอ่านเพย์โหลดและตารางใดเก็บผลลัพธ์ ผิดคู่แล้วนโยบายนำเข้า การจับคู่เป้าหมายเส้นทาง และการค้นหาฮอปถัดไปก็ทำงานกับโครงสร้างที่ไม่มีใครประกาศ การเดินด้านล่างเริ่มที่คู่นั้นและจบที่ผลการส่งต่อ
ตัวเลขสองตัวกำหนดว่าเส้นทางอยู่ในตารางใด
คู่ปรากฏสองครั้ง คือภายในความสามารถหลายโปรโตคอลซึ่งผู้พูดประกาศแฟมิลี และหน้า NLRI ทุกตัวที่แฟมิลีนั้นพาไป จึงเป็นคุณสมบัติของเส้นทาง ไม่ใช่การตั้งค่าบนกล่องต้นทาง ผู้ผลิตพิมพ์เป็นชื่ออย่าง Address family VPNv4 Unicast และถ้อยคำเลื่อนไปตามรุ่น ขณะที่ตัวเลขอยู่กับที่
| Where you meet it | Family pair | Boundary of what it proves |
|---|---|---|
| VPNv4 unicast capability on a neighbour | 1 / 128 | the peer will signal labelled VPN-IPv4, nothing about import |
| VPNv6 unicast capability on a neighbour | 2 / 128 | the peer will signal VPN-IPv6, silent about the transport below |
| VPLS NLRI with a VE ID and a label base | 25 / 65 | a pseudowire is signalled, not that a bridge learned a MAC |
| EVPN MAC/IP advertisement route | 25 / 70 | a binding is advertised, not that the host answers |
การเข้ารหัสสี่แบบครอบคลุมเกือบทุกกรณีองค์กร: 1 กับ 128 สำหรับ VPN-IPv4 ที่ติดป้าย MPLS, 2 กับ 128 สำหรับคู่เทียบ IPv6, 25 กับ 65 สำหรับ VPLS ที่ส่งสัญญาณด้วย BGP และ 25 กับ 70 สำหรับ EVPN ข้อผิดพลาดแรกคือสมมติว่าบริการ Layer 2 ทุกตัวอยู่หลัง 25 กับ 65 ซึ่งซ่อน EVPN ข้อที่สองคือถือว่าแฟมิลี IP สองแฟมิลีเป็นแฟมิลีเดียวที่มีที่อยู่ยาวกว่า ทั้งที่เจรจากันแยกและรับได้บนพีเรียร์ต่างกัน ข้อที่สามปรากฏเมื่อคัดลอกแม่แบบจากรุ่นที่รู้จักเพียงตัวเดียว การค้นในทะเบียนตัดสินทั้งสามได้เร็วกว่าการเดาจากชื่อบริการ
ถือสี่แถวเป็นตัวอย่างจากทะเบียน IANA ไม่ใช่ทะเบียนเอง เมื่อหมายเลขไม่ตรงกับสิ่งใดที่รู้จัก ให้ค้นดูก่อนสร้างนโยบายรอบมัน
AFI 25 พาสองรูปแบบ NLRI ที่ไม่เกี่ยวข้องกัน
แฟมิลี Layer 2 ทั้งสองอยู่ใต้ AFI 25 และความคล้ายกันจบตรงนั้น NLRI ของ VPLS ใน RFC 4761 section 3.2.2 พาความยาว ตัวจำแนกเส้นทาง VE ID การเลื่อนบล็อก VE ขนาดบล็อก VE และฐานป้าย ซึ่งรวมกันตั้งชื่อปลายทาง pseudowire และป้ายของมัน EVPN เก็บ AFI 25 ไว้และย้ายไป SAFI 70 ซึ่งเพย์โหลดเป็นชนิดเส้นทาง: การค้นพบอีเทอร์เน็ตอัตโนมัติ การประกาศ MAC/IP มัลติแคสต์แบบรวม ส่วนอีเทอร์เน็ต คำนำหน้า IP ดังนั้นการเลื่อนไบต์เดียวกันจึงหมายถึงคนละอย่างในสองแฟมิลี ตัวแยกวิเคราะห์ที่เขียนสำหรับตัวหนึ่งอ่านอีกตัวได้โดยไม่บ่นและให้ผลไร้ความหมาย คู่นี้คือคำเตือนเดียวว่าการตีความผิด
ฟิลด์ที่หมายถึงการเลื่อนบล็อก VE ในแฟมิลีหนึ่งไม่มีคู่เทียบในอีกแฟมิลี และเส้นทางประกาศ MAC/IP มีเฉพาะใน EVPN การอ้างคุณลักษณะราวกับใช้กับทั้งสองคือทางที่การทบทวนแคปเจอร์จะผิดพลาด
เมื่อมีคนให้แคปเจอร์หรือตารางผู้ผลิต คุณถามว่าแฟมิลีใดเป็นเจ้าของคุณลักษณะนั้น แล้วยืนยันว่าการใช้งานฝั่งรับรองรับแฟมิลีนั้น ไม่ใช่ชื่อบริการบนเอกสารข้อมูล สองแพลตฟอร์มอาจอ้างสนับสนุน VPLS ทั้งคู่ขณะใช้งานแฟมิลีสัญญาณต่างกัน คู่นี้แยกมันออกจากกัน ป้ายผลิตภัณฑ์ไม่ทำ
แฟมิลีที่อยู่ของเซสชันเองเป็นคำถามแยก
VPN-IPv6 ถูกประกาศเป็นปกติผ่านเซสชันที่การเชื่อมต่อ TCP วิ่งบน IPv4 และนั่นคือการออกแบบที่รองรับ ไม่ใช่ข้อบกพร่อง การอ่านเพียงสรุปเซสชันจึงไม่บอกอะไรเกี่ยวกับแฟมิลี VPN ที่พีเรียร์แลกเปลี่ยนกัน
แฟมิลี NLRI แฟมิลีการขนส่ง และแฟมิลีการส่งต่อเป็นสามการตัดสินใจอิสระ เราเตอร์อาจพูด IPv4 กับพีเรียร์ รับการเข้าถึง VPN-IPv6 และติดตั้งเส้นทางที่ฮอปถัดไปเป็นที่อยู่ IPv6 ที่เข้าถึงได้ผ่านเส้นทางที่คุณไม่ได้ตั้งใจ แต่ละชั้นต้องการการยืนยันของตัวเอง ไซต์ที่รายงานปลายทาง IPv6 เข้าไม่ถึงขณะประกาศดูถูกต้องมักสูญเสียการแก้ไขฮอปถัดไป ไม่ใช่การเจรจาแฟมิลี
ทดสอบแฟมิลีที่อยู่ของเซสชันแยก แล้วจึงแฟมิลีที่มันพาไป แล้วจึงสิ่งที่คอร์ส่งต่อได้ การแยกสามอย่างไว้ออกจากกันป้องกันการวินิจฉัยผิดทั่วไปที่อ่านประกาศที่ถูกต้องเป็นหลักฐานว่า IPv6 ทำงานตั้งแต่ต้นจนจบ มันพิสูจน์เพียงว่าพีเรียร์หนึ่งบอกอีกตัวเกี่ยวกับคำนำหน้า
เจรจาแล้ว รับแล้ว นำเข้าแล้ว ติดตั้งแล้ว
สำหรับเส้นทางที่คาดหวังหนึ่งเส้น สี่สถานะต้องเกิดตามลำดับ และแต่ละอย่างสังเกตได้ แฟมิลีต้องถูกเจรจากับพีเรียร์นั้น เส้นทางต้องมาถึง เป้าหมายเส้นทางต้องนำมันเข้าบริบทที่ตั้งใจ และฮอปถัดไปต้องแก้ได้เพื่อให้เส้นทางติดตั้ง การข้ามสถานะแรกทำให้สามข้อที่เหลือตอบไม่ได้ เพราะแฟมิลีที่ไม่ถูกเจรจาไม่สร้างเส้นทางให้ตรวจ บนแพลตฟอร์มสไตล์ Cisco สรุปแฟมิลีและความสามารถรายพีเรียร์เป็นคำสั่งแยกกัน
show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address familyการเจรจาปรากฏในการแลกเปลี่ยนความสามารถที่พิมพ์รายพีเรียร์ และเซสชันที่สร้างแล้วโดยไม่มีแฟมิลีใดระบุไว้พาไม่มีอะไรที่คุณขอ การนำเข้าถูกตัดสินโดยเป้าหมายเส้นทางที่พาเป็นคอมมิวนิตี้แบบขยาย ดังนั้นคู่ที่ถูกต้องกับเป้าหมายที่พิมพ์ผิดทำให้ตารางว่าง การติดตั้งจึงขึ้นกับการแก้ฮอปถัดไปในบริบทฝั่งรับ ซึ่งอาจล้มเหลวขณะทุกประกาศดูสมบูรณ์
ยืนยันระนาบข้อมูลเป็นลำดับสุดท้าย เพราะเส้นทางในตารางคือข้อกล่าวอ้าง ไม่ใช่การส่งมอบ สี่สถานะเดิมใช้กับทุกแฟมิลี เปลี่ยนเพียงคำสั่งและชื่อตาราง
สิ่งที่คู่แฟมิลีไม่เคยพิสูจน์
การอ่านคู่อย่างถูกต้องบอกวิธีตีความข้อมูลเส้นทางที่ตามมา และนั่นคือข้อกล่าวอ้างทั้งหมด มันไม่บอกอะไรเกี่ยวกับการเข้าถึง นโยบาย หรือสุขภาพของระนาบข้อมูล การสับสนสองอย่างนี้สร้างถ้อยคำมั่นใจเกี่ยวกับเครือข่ายที่ไม่มีใครตรวจสอบ ความไม่ตรงกันของเป้าหมายเส้นทางและฮอปถัดไปที่พังดูเหมือนกันเมื่อดูจากคู่เท่านั้น คู่คือคำแนะนำการอ่าน ไม่ใช่คำตัดสิน
เมื่อยกระดับ ให้ใส่คู่ เป้าหมายเส้นทาง และฮอปถัดไปที่แก้แล้วไว้ในบันทึกเดียวกัน แล้ววิศวกรคนถัดไปมีสามอย่างอิสระให้ทดสอบแทนการตีความชื่อบริการใหม่ ถ้าไม่มีการเจรจาพวกเขาเห็นทันที เป้าหมายผิดทำให้การนำเข้าหายไปอย่างเห็นได้ชัด และฮอปถัดไปที่ยังไม่แก้ทำให้เส้นทางอยู่แต่ใช้ไม่ได้