اجرای خودکار دستور در Cisco با IP SLA، Track و EEM

در تجهیزات سیسکو خیلی وقت‌ها فقط مانیتور کردن وضعیت کافی نیست. مثلاً با IP SLA می‌توانیم بفهمیم مسیر WAN جواب می‌دهد یا نه، delay از حد مشخصی بیشتر شده یا نه، یا یک سرویس HTTP هنوز پاسخ می‌دهد یا نه. اما سؤال اصلی این است: بعد از اینکه فهمیدیم وضعیت خراب شده، چه کاری باید انجام شود؟

اینجا ترکیب IP SLA، Track و EEM به درد می‌خورد. IP SLA وضعیت را اندازه‌گیری می‌کند، Track نتیجه را به یک وضعیت ساده up/down تبدیل می‌کند و EEM می‌تواند بر اساس آن وضعیت، دستورهای مشخصی را روی خود دستگاه اجرا کند.

چرا فقط IP SLA کافی نیست؟

IP SLA ابزار خوبی برای مانیتورینگ داخل خود روتر یا سوییچ است. می‌شود با آن reachability، latency، jitter، packet loss و حتی پاسخ‌گویی بعضی سرویس‌ها را بررسی کرد. اما IP SLA به‌تنهایی action اجرایی روی همه بخش‌ها ندارد. برای بعضی سناریوها می‌توان Track را مستقیم به static route، HSRP، VRRP یا GLBP وصل کرد، ولی همیشه چنین امکانی وجود ندارد.

فرض کنید می‌خواهیم اگر یک Track خاص down شد، یک اینترفیس shut شود، یک route خاص حذف شود، یک log سفارشی ثبت شود یا چند دستور پشت سر هم اجرا شود. همه featureها مستقیم Track نمی‌گیرند. در این حالت EEM راه‌حل تمیزتری است.

سناریوی نمونه: خاموش کردن اینترفیس با down شدن Track

در این مثال، وضعیت line-protocol یک اینترفیس را track می‌کنیم. اگر Track شماره 100 down شود، یک EEM applet اجرا می‌شود و اینترفیس دیگری را shutdown می‌کند. این فقط یک نمونه آموزشی است؛ در محیط واقعی باید حتماً اثر این کار روی routing و دسترسی مدیریتی بررسی شود.

track 100 interface FastEthernet0/1 line-protocol

event manager applet shut_interface
 event track 100 state down
 action 0 cli command "enable"
 action 1 cli command "configure terminal"
 action 2 cli command "interface FastEthernet0/0"
 action 3 cli command "shutdown"
 action 4 cli command "end"

در این نمونه، وقتی Track شماره 100 به وضعیت down برسد، applet با نام shut_interface اجرا می‌شود و دستورهای تعریف‌شده را به‌ترتیب می‌زند. ترتیب actionها مهم است، چون EEM مثل یک سناریوی CLI جلو می‌رود.

چند نکته مهم قبل از اجرا در شبکه واقعی

اول اینکه همیشه سناریوی برگشت را هم طراحی کنید. اگر فقط در حالت down اینترفیس را shut کنید ولی برای up شدن دوباره برنامه‌ای نداشته باشید، ممکن است خودتان یک قطعی پایدار بسازید. در خیلی از طراحی‌ها باید یک applet جدا برای state up نوشته شود یا تصمیم بگیرید برگشت فقط دستی انجام شود.

دوم اینکه EEM را روی مسیر مدیریتی دستگاه بدون احتیاط اجرا نکنید. اگر دستورهای شما باعث قطع SSH، قطع route مدیریتی یا خاموش شدن اینترفیس دسترسی شود، برای برگشت ممکن است مجبور شوید از console یا دسترسی out-of-band استفاده کنید.

سوم اینکه commandها باید با privilege مناسب اجرا شوند. بعضی IOSها برای اجرای دستورهای config از داخل EEM نیاز به تنظیمات AAA یا authorization دقیق دارند. اگر AAA command authorization فعال است، قبل از اجرای سناریو در production حتماً تست کنید که applet اجازه اجرای دستورها را دارد.

مانیتورینگ و عیب‌یابی

برای دیدن وضعیت Track می‌توانید از دستور زیر استفاده کنید:

show track

نمونه خروجی ممکن است چیزی شبیه این باشد:

Track 100
 Interface FastEthernet0/1 line-protocol
 Line protocol is Down
 Tracked by:
   EEM applet shut_interface

برای بررسی اجرای actionهای EEM هم می‌شود از debug استفاده کرد، البته روی تجهیزات production باید با احتیاط و در بازه کنترل‌شده باشد:

debug event manager action cli

جمع‌بندی

ترکیب IP SLA، Track و EEM یکی از روش‌های کاربردی برای automation سبک داخل تجهیزات Cisco است. وقتی feature مورد نظر مستقیم Track را پشتیبانی نمی‌کند، EEM کمک می‌کند بر اساس تغییر وضعیت، دستورهای لازم اجرا شوند. فقط باید قبل از استفاده، سناریوی برگشت، اثر روی دسترسی مدیریتی و رفتار در شرایط flap شدن لینک را دقیق طراحی کرد.

علیرضا عربیان

متخصص شبکه و امنیت شبکه، مدرس امنیت شبکه و نویسنده وبلاگ arabiyan.ir

Share
Published by
علیرضا عربیان

Recent Posts

راه‌اندازی FortiWeb بدون دردسر False Positive؛ از Monitor تا Block

مسیر عملی راه‌اندازی FortiWeb از monitor تا block؛ بررسی لاگ، کاهش false positive، ساخت exception…

6 روز ago

طراحی Health Monitor درست در F5 BIG-IP؛ فقط TCP کافی نیست

راهنمای عملی طراحی Health Monitor در F5 BIG-IP؛ تفاوت TCP و HTTP Monitor، خطاهای رایج،…

6 روز ago

عیب‌یابی Deploy نشدن Policy در Cisco FMC/FTD

راهنمای عملی عیب‌یابی Deploy نشدن Policy در Cisco FMC و FTD با بررسی health، connectivity،…

1 هفته ago

کاهش False Positive در FortiWeb WAF؛ تنظیم امن بدون کور کردن دفاع

راهنمای عملی کاهش False Positive در FortiWeb WAF با بررسی لاگ، rule، parameter، exception محدود…

1 هفته ago

Persistence در F5 چیست و چه زمانی Source Address یا Cookie بهتر است؟

راهنمای عملی Persistence در F5 BIG-IP؛ تفاوت Source Address و Cookie Persistence، زمان استفاده، خطاهای…

1 هفته ago

امن‌سازی دسترسی مدیریتی FortiGate؛ اشتباهاتی که نباید انجام داد

چک‌لیست عملی امن‌سازی دسترسی مدیریتی FortiGate؛ محدودسازی WAN، trusted hosts، MFA، حساب‌های جداگانه، لاگ ورود…

1 هفته ago