یکی از مزیتهای مهم Junos این است که تغییرها مستقیم روی running configuration نمینشینند. شما candidate configuration را آماده میکنید، آن را بررسی میکنید و بعد commit میزنید. همین مدل اگر درست استفاده شود، ریسک تغییر روی SRX، روتر یا سوئیچ Juniper را پایین میآورد. اما اگر فقط به commit ساده عادت کنیم، هنوز خطر قطع شدن دسترسی مدیریتی یا مسیر سرویس وجود دارد.
چرا commit confirmed مهم است؟
در تغییرهای حساس، commit confirmed مثل یک تایمر برگشت عمل میکند. اگر بعد از تغییر، دسترسی قطع شود یا سرویس حیاتی از کار بیفتد و شما نتوانید commit را تأیید کنید، Junos تغییر را برمیگرداند. این قابلیت مخصوصاً در تغییرهای مربوط به security zone، policy، NAT، route و دسترسی مدیریتی ارزش زیادی دارد.
commit check
commit confirmed 5
commit comment "SRX policy update with rollback window"
commitترتیب بالا ساده است، ولی در عمل باید با برنامه تست همراه باشد. بعد از commit confirmed باید همان چند دقیقه اول مسیر SSH، routeهای مهم، policyهای حساس، NAT و لاگ را بررسی کنید. اگر همه چیز درست بود، commit نهایی میزنید. اگر نه، دستگاه خودش بعد از زمان مشخص rollback میکند.
rollback و rescue config را جدی بگیرید
rollback فقط برای وقتی نیست که همه چیز خراب شده باشد. برای تحلیل تغییر هم مفید است، چون میتوانید بفهمید دقیقاً چه چیزی نسبت به نسخه قبل عوض شده است. rescue config هم باید برای حالت اضطراری آماده باشد؛ مخصوصاً روی دستگاههایی که دسترسی out-of-band ندارند یا در مسیر شعب و سرویسهای حساس قرار گرفتهاند.
- قبل از تغییر، خروجی configuration فعلی و rollback را ذخیره کنید.
- commit check را قبل از هر commit جدی اجرا کنید.
- برای تغییرهای remote از commit confirmed استفاده کنید.
- بعد از تغییر، فقط ping نگیرید؛ policy hit، route، NAT و log را هم ببینید.
- commit comment بنویسید تا history قابل فهم بماند.
این موضوع کنار طراحی Zone و Policy در Juniper SRX، NAT در Juniper SRX و HA و Chassis Cluster معنا پیدا میکند. اگر شاخه کامل Juniper را میخواهید، صفحه جونیپر Juniper مسیر اصلی است.
commit confirmed جای تست را نمیگیرد
commit confirmed یک کمربند ایمنی است، نه برنامه تست. اگر بعد از اجرای آن فقط صبر کنیم ببینیم تماسها زیاد میشود یا نه، عملاً فرصت rollback کنترلشده را از دست دادهایم. قبل از تغییر باید بدانیم در همان چند دقیقه اول دقیقاً چه چیزهایی را میسنجیم: دسترسی مدیریتی، route مسیرهای حساس، hit policy، NAT، VPN و وضعیت cluster اگر دستگاه HA دارد.
در SRX، تغییر در zone یا policy ممکن است فقط روی یک مسیر خاص اثر بگذارد و تست عمومی ping آن را نشان ندهد. برای همین بهتر است سناریوی تست با IP، zone، سرویس و جهت ترافیک مشخص نوشته شود. اگر تغییر روی NAT است، باید هم مسیر رفت و هم ترجمه آدرس بررسی شود. اگر تغییر روی دسترسی مدیریتی است، بهتر است session فعلی را معیار کافی ندانیم و ورود جدید را هم تست کنیم.
یک روال عملی قبل از تغییر Junos
- قبل از تغییر، خروجی configuration و rollback را ذخیره کنید.
- با commit check خطاهای syntax و reference را جدا کنید.
- برای تغییر remote، commit confirmed با زمان متناسب بزنید.
- در همان بازه، سناریوهای اصلی را تست و log را بررسی کنید.
- بعد از اطمینان، commit نهایی را با comment روشن ثبت کنید.
این روش شاید چند دقیقه بیشتر زمان بگیرد، اما در شبکهای که Juniper در مسیر سرویسهای مهم است، همین چند دقیقه تفاوت بین تغییر قابل دفاع و قطعی پرهزینه را میسازد.
منبع فنی
برای syntax و گزینههای دقیق، مستند رسمی Juniper درباره دستور commit در Junos OS مرجع اصلی است. در محیط production، زمان تایمر commit confirmed باید با زمان تست واقعی هماهنگ باشد.
commit confirmed فقط یک دستور راحت نیست
در Junos، commit confirmed برای این ساخته شده که تغییرهای پرریسک بدون مسیر بازگشت اجرا نشوند. ارزش اصلی آن وقتی مشخص میشود که تغییر روی دسترسی مدیریتی، routing، policy امنیتی یا interface uplink اثر میگذارد. اگر بعد از commit confirmed ارتباط قطع شود و شما نتوانید تغییر را تأیید کنید، دستگاه خودش rollback میکند. این رفتار ساده میتواند جلوی یک قطعی طولانی را بگیرد، اما فقط وقتی مفید است که قبل از تغییر، زمان تأیید و مسیر دسترسی جایگزین را درست انتخاب کرده باشید.
روال عملی برای تغییرهای حساس Junos
قبل از تغییر، diff را بخوانید و مطمئن شوید فقط همان بخش مورد نظر تغییر کرده است. بعد، اگر تغییر روی remote access یا مسیر ترافیک اثر دارد، commit confirmed را با زمان مناسب اجرا کنید؛ نه آنقدر کوتاه که فرصت تست نداشته باشید و نه آنقدر بلند که در صورت قطع شدن، شبکه مدت زیادی در وضعیت بد بماند. بعد از commit، تست را از دید کاربر یا سرویس واقعی انجام دهید: ping ساده کافی نیست؛ باید مسیر مدیریت، route، policy و سرویس هدف بررسی شود.
rescue config هم باید بخشی از استاندارد نگهداری باشد، نه کاری که فقط بعد از حادثه به آن فکر کنید. هر بار که طراحی پایدار و تأییدشده دارید، rescue configuration را بهروز کنید تا در حادثه، بازگشت به یک وضعیت شناختهشده ممکن باشد. ترکیب commit confirmed، rollback و rescue config باعث میشود تغییر روی SRX یا تجهیزات Juniper قابل دفاعتر و آرامتر انجام شود.
