นโยบายส่งออกของ Junos: ชื่อไม่ใช่เงื่อนไขการจับคู่

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

ชื่อคือป้าย ไม่ใช่เงื่อนไข

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

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

หาการแนบก่อนเงื่อนไข

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

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

เงื่อนไขถูกประเมินตามลำดับ และการตัดสินใจแรกชนะ

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

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

ตัวอย่างที่ส่งออกเฉพาะเส้นทางสแตติก โดยแนบที่กลุ่ม:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

คำนำหน้าที่เรียนรู้ผ่าน OSPF แทนที่จะกำหนดค่าเป็นเส้นทางสแตติกจะไม่ผ่านการจับคู่และตกไป ไม่ว่าจะเรียกนโยบายว่าอะไร

การกระทำเปลี่ยนสำเนา ไม่ใช่เส้นทางต้นฉบับ

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

การยอมรับและการปฏิเสธเป็นการตัดสินใจที่สิ้นสุด การเปลี่ยนแปลงแอตทริบิวต์ไม่จำเป็นต้องเป็นเช่นนั้น อย่าสันนิษฐานว่าการตั้ง community จะจบนโยบาย เพราะการประเมินอาจดำเนินต่อไปยังเงื่อนไขที่คุณไม่ได้พิจารณา

เปรียบเทียบมุมมองที่ประกาศกับความคาดหวัง

ใช้มุมมองเฉพาะโปรโตคอลบน peer จริง เช่น show route advertising-protocol bgp 192.0.2.1 และอ่านในบริบทอินสแตนซ์การกำหนดเส้นทางที่ถูกต้อง เส้นทางที่มีอยู่ใน VRF ไม่จำเป็นต้องผ่านนโยบายส่งออก และเส้นทางที่ปรากฏในผลลัพธ์ที่ประกาศไม่จำเป็นต้องได้รับการยอมรับจากฝั่งไกล สิ่งเหล่านี้เป็นสามสถานะแยกกันและล้มเหลวต่างกัน

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