จากเส้นทาง RIP บน CE สู่ VRF ระยะไกล: export เกิดขึ้นที่ใด

อัปเดต RIPv2 มาถึง provider edge เข้าสู่ตาราง routing ของ VRF และหยุดอยู่ตรงนั้น เว้นแต่มีบางอย่าง export มันอย่างชัดเจน การตัดสินใจสามอย่างเกิดขึ้นตามลำดับ และแต่ละอย่างสามารถปฏิเสธคำนำหน้าได้ด้วยเหตุผลของตัวเอง การอ่านพวกมันเป็นเหตุการณ์เดียวคือเหตุผลที่ผู้คนไปตามหาอุปกรณ์ผิดเครื่องเมื่อไซต์ระยะไกลไม่สามารถเข้าถึงเครือข่ายที่ CE ประกาศอย่างชัดเจน ติดตามเส้นทางผ่าน PE แล้วลำดับจะชัดเจนขึ้น

PE ทำอะไรกับอัปเดต RIP

PE รับอัปเดตบนอินเทอร์เฟซ VRF ตรวจสอบว่าต้นทางเป็นเพื่อนบ้านที่ได้รับอนุญาต และติดตั้งคำนำหน้าเข้าสู่ตาราง routing ของ VRF ด้วยจำนวน hop ที่ได้จากการประกาศ ตารางนั้นเป็นตาราง routing ปกติที่มี administrative distance ของตัวเองและการเลือกเส้นทางที่ดีที่สุดของตัวเอง หาก CE ประกาศคำนำหน้าเดิมสองครั้งด้วย metric ที่ต่างกัน มีเพียงตัวที่ดีกว่าเท่านั้นที่อยู่รอดในตาราง ไม่มีขั้นตอนใดในนี้เกี่ยวข้องกับ backbone ของผู้ให้บริการ

ตอนนี้คำนำหน้าอยู่ภายในบริบท routing ของลูกค้ารายเดียว ซึ่งห่างไกลจากการเข้าถึงได้ที่อื่น

Export เป็นการกระทำเชิงนโยบาย ไม่ใช่ผลของโปรโตคอล

การจะออกจาก VRF เส้นทางต้องถูก redistribute เข้าสู่กระบวนการ MP-BGP ที่บรรทุกเส้นทาง VPN และต้องมี route target extended community ที่ระบุว่า VRF ระยะไกลใดสามารถ import ได้ สถาปัตยกรรมใน RFC 4364 แยกการแลกเปลี่ยนเหล่านั้นออกจากโปรโตคอล CE-PE ด้วยเหตุผลนี้เอง การใช้ RIP ที่ขอบไม่ได้บอกอะไรเกี่ยวกับสิ่งที่ควรข้ามเครือข่ายของผู้ให้บริการ

เขียนสัญญา export ก่อนกำหนดค่าใด ๆ: คำนำหน้าของลูกค้าที่ต้องเข้าถึงได้จากระยะไกล เส้นทางที่ต้องอยู่ภายใน และ default ใด ๆ เส้นทางที่เฉพาะเจาะจงกว่าหรือข้อยกเว้นสำหรับบริการที่ใช้ร่วมกัน จับคู่สัญญานั้นกับ VRF จริง ไม่ใช่กับ VRF ที่ชื่อคล้ายกันซึ่งเป็นของลูกค้ารายอื่น

ด้าน import เป็นนโยบายที่สองที่มี route target ของตัวเอง และ export ที่ตรงกันกับ import ที่ไม่ตรงกันจะสร้างคำนำหน้าที่มีอยู่ใน backbone และไม่ปรากฏในตารางระยะไกลใดเลย

Redistribution และ explicit origination ทำงานต่างกัน

Redistribution นำเส้นทางที่มีอยู่แล้วในตาราง VRF มาคัดลอกเข้า BGP โดยกรองด้วย route map แผนที่ตัดสินว่าคำนำหน้าใดมีสิทธิ์และมี attribute อะไรติดมาบ้าง และต้องตั้ง metric อย่างชัดเจนเพราะจำนวน hop ของ RIP ไม่มีความหมายในฐานะ metric ของ BGP สิ่งใดที่คุณปล่อยไว้ไม่ตั้งจะถูกสืบทอดในลักษณะที่มักทำให้คนที่อ่าน config หกเดือนให้หลังประหลาดใจ

Redistribution สองทางคือจุดที่ความเสียหายเงียบเกิดขึ้น คำนำหน้าที่ export เข้า BGP สามารถกลับมาได้ผ่านจุด redistribution จุดที่สอง และหากไม่มี tag หรือ filter เส้นทางจะแกว่งไปมาในขณะที่ทั้งสองตารางดูสมเหตุสมผลในทุกขณะ กรองด้วย tag ที่ใช้ที่ขอบแทนการไว้วางใจให้ topology ป้องกันเส้นทางย้อนกลับ

Explicit origination ดูเรียบร้อยกว่าและไม่ได้เป็นไปโดยไม่มีเงื่อนไข network statement ปกติต้องมีเส้นทางที่ตรงกันในตาราง routing ก่อนที่คำนำหน้าจะถูก originate ดังนั้นการประกาศจะหายไปในทันทีที่ CE เลิกประกาศมัน นั่นมักเป็นพฤติกรรมที่คุณต้องการ และไม่เหมือนกับ static route ที่ยังคงกำหนดค่าไว้ตลอดไป ตรวจสอบกฎจริงของแพลตฟอร์มแทนการสันนิษฐานเอาพฤติกรรมใดพฤติกรรมหนึ่ง

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

ตรวจสอบห่วงโซ่ในสี่จุด

ดูการประกาศของ CE ตาราง routing ของ VRF ตารางเส้นทาง VPN พร้อม route target และ import ใน VRF ระยะไกล ตามลำดับนั้น บน IOS นั่นหมายถึงผลลัพธ์ของเพื่อนบ้าน CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, และคำสั่งเดียวกันบน PE ระยะไกล บน IOS-XR ผลลัพธ์ที่เทียบเท่าอยู่ใต้ show bgp vrf CUSTOMER ipv4 unicast ชื่อคำสั่งต่างกัน แต่จุดตรวจสอบทั้งสี่ไม่ต่าง

ตรวจสอบคำนำหน้าที่ควรถูกปฏิเสธอย่างระมัดระวังพอ ๆ กับคำนำหน้าที่ควรผ่าน เพราะนโยบายที่อนุญาตทุกอย่างดูเหมือนนโยบายที่ถูกต้องจนกว่าข้อยกเว้นแรกจะมาถึง จากนั้นดูการ withdrawal: ปิดอินเทอร์เฟซ CE และยืนยันว่ารายการระยะไกลหายไปภายใน timer ที่คาดไว้ ไม่ใช่คงอยู่ต่อ

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