Cisco CCNA · 200-301 v2.0

HSRP Failover و تفسیر Operational Status

هدف CCNA فقط نوشتن standby ip نیست؛ باید بتوانی از Output عملیاتی بفهمی Gateway مجازی در چه وضعیتی است و هنگام خرابی چه اتفاقی افتاده است. Failover را باید به‌صورت یک زنجیره ببینی: Failure Detection، تغییر Priority یا از دست رفتن Peer، Role Transition، Update هویت مجازی و بازیابی Traffic. سپس Recovery را نیز بررسی کنی تا معلوم شود Device Primary چه زمانی و چگونه به نقش قبلی برمی‌گردد.

در پایان این درس باید بتوانی
  • Failover را به مراحل منطقی تقسیم کنی
  • State Change را از Output و Log تفسیر کنی
  • Failover Device و Uplink را از هم جدا کنی
  • زمان بازیابی Traffic را اندازه‌گیری کنی
  • Recovery و Failback را مطابق Preempt/Tracking بررسی کنی

انواع Trigger برای Failover

Failover ممکن است به دلیل Down شدن خود Interface HSRP، خاموش شدن Device، از دست رفتن Hello Peer یا کاهش Priority ناشی از Tracking رخ دهد. این Triggerها نتیجه مشابه Role Change دارند اما Root Cause متفاوتی دارند.

Triggerهای متداول
Device failure
Interface failure
Peer hello loss
Tracked object failure -> priority decrease

در Incident باید بفهمی کدام Trigger اتفاق افتاده، نه اینکه فقط «R2 Active شد» را ثبت کنی. show standby، show track، Interface State و Log Timestamp این زنجیره را می‌سازند.

خواندن Operational State

show standby brief برای چند VLAN سریع است و show standby جزئیات Group خاص را می‌دهد. State، Active Peer، Standby Peer، Priority و Virtual IP را بخوان. اگر Active=local است، همان Device در حال سرویس VIP است.

نمونه مفهومی
Interface  Grp Pri State   Active Standby VIP
Vl20       20  100 Active  local  10.20.0.2 10.20.0.1

اگر Standby unknown است، ممکن است Peer در دسترس نباشد یا Hello Communication مشکل داشته باشد. اگر Active unknown/State غیرعادی است، Layer 2 و Configuration Group را بررسی کن.

روی چند VLAN ممکن است Load Sharing طراحی شده باشد؛ مثلاً R1 برای VLAN20 Active و R2 برای VLAN30 Active. پس «همه VLANها باید یک Active داشته باشند» فرض درستی نیست.

اندازه‌گیری Data Plane

برای اندازه‌گیری Failover می‌توان از Ping پیوسته از Client به VIP و سپس مقصد دور استفاده کرد. تعداد Packet Lost و زمان Recovery را ثبت کن. برای سرویس حساس، Test Application یا Sessionهای TCP نیز مهم‌اند.

تست ساده
ping -t 10.20.0.1
ping -t 10.50.50.10
# هم‌زمان show standby در دو Gateway

ممکن است VIP خیلی سریع برگردد اما Route Upstream روی Device جدید دیرتر آماده شود. مقایسه Ping VIP و مقصد دور دقیقاً این تفاوت را آشکار می‌کند.

Recovery و Failback

بعد از رفع Failure، Device قبلی ممکن است Standby بماند یا با Preempt دوباره Active شود. اگر Tracking Priority را برگرداند و Preempt فعال باشد، Failback رخ می‌دهد. Preempt Delay می‌تواند از انتقال زودهنگام Traffic جلوگیری کند.

Recovery را مثل Failure تست کن. فقط اینکه Alarm پاک شد کافی نیست. Role نهایی، Priority، Track State، Routing Table و Client Traffic را Verify کن.

زنجیره Recovery
Failure cleared -> track up -> priority restored -> preempt decision -> final role

Incident Runbook HSRP

Runbook عملی: 1) Client Gateway/VLAN؛ 2) show standby brief روی هر دو Peer؛ 3) SVI و Layer 2 Status؛ 4) show track؛ 5) Upstream Route/Interface؛ 6) Ping VIP و مقصد دور؛ 7) Logs/Timestamps؛ 8) Change History.

مسیر عیب‌یابی
client -> HSRP state -> L2/SVI -> track -> routing -> data plane -> logs

اگر هر دو Peer Active هستند، بین آن‌ها Hello Reachability را بررسی کن. اگر Active درست است ولی Traffic دور قطع است، Upstream را بررسی کن. اگر Track مکرراً Up/Down می‌شود، Flapping Object را حل کن.

سناریوی عملی

در Incident، کاربران ۱۲ ثانیه ارتباط ERP را از دست می‌دهند. VIP پس از ۳ ثانیه روی R2 پاسخ می‌دهد اما Route OSPF به ERP روی R2 9 ثانیه بعد نصب می‌شود. تیم متوجه می‌شود مشکل اصلی FHRP Timer نیست؛ Routing Convergence روی Backup Gateway دیرتر است. این تفاوت با تست هم‌زمان VIP و مقصد دور روشن می‌شود.

اشتباهات رایج

اشتباه‌های رایج و علت آن‌ها

  • نسبت دادن کل زمان Outage به HSRP بدون اندازه‌گیری Routing
  • تست فقط VIP
  • نادیده گرفتن Recovery و Failback
  • ثبت State نهایی بدون Timeline
تمرین عملی

تمرین عملی

  1. یک Failover Lab اجرا و Packet Loss VIP/Remote را جدا ثبت کن
  2. Timeline از Track Down تا Active Change بساز
  3. سناریوی Load Sharing چند VLAN را طراحی کن
  4. Runbook Incident را با Evidence لازم تکمیل کن

نکته‌هایی که باید با خودت ببری

  • Failover Triggerها Root Causeهای متفاوت دارند
  • Operational State باید روی هر دو Peer دیده شود
  • VIP و مقصد دور دو سطح مختلف را تست می‌کنند
  • Recovery به Preempt/Tracking وابسته است
  • Timeline برای تحلیل Failover ضروری است
خودسنجی

خودسنجی

چرا VIP و مقصد دور را جدا Ping می‌کنیم؟

برای جدا کردن زمان بازیابی First Hop از Routing/Upstream.

Standby unknown چه سرنخی می‌دهد؟

Peer یا HSRP Hello Communication ممکن است مشکل داشته باشد.

Failback به چه چیزی وابسته است؟

بازگشت Priority/Tracking و سیاست Preempt.

اولین خروجی خلاصه برای چند Group چیست؟

show standby brief.

منابع رسمی

منابع مرجع این درس

مطالعه همیشه آزاد است

برای ذخیره پیشرفت وارد حساب شو

حساب کاربری برای آزمون و ثبت مرحله‌ها استفاده می‌شود

ورود یا ثبت‌نام