سیاست خروج 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 سیاست را پایان می‌دهد، زیرا ارزیابی ممکن است به عبارت‌هایی ادامه یابد که در نظر نگرفته‌اید.

نمای اعلام‌شده را با انتظار مقایسه کنید

از نمای مخصوص پروتکل روی همسایهٔ واقعی استفاده کنید، مانند show route advertising-protocol bgp 192.0.2.1، و آن را در زمینهٔ درست نمونهٔ مسیریابی بخوانید. مسیری که در یک VRF وجود دارد لزوماً از سیاست خروج نگذشته است، و مسیری که در خروجی اعلام‌شده ظاهر می‌شود لزوماً توسط طرف دور پذیرفته نشده است. این‌ها سه وضعیت جداگانه‌اند و به شکل‌های متفاوت شکست می‌خورند.

طرح را با یک پیشوند که باید اعلام شود و یکی که باید محلی بماند بپذیرید. این به سیاست قراردادی می‌دهد که می‌توانید بیازمایید، و از راه‌حل جایگزین گسترش خروج تا زمانی که سرانجام یک مسیر نام‌دار ظاهر شود پرهیز می‌کند.