Troubleshooting و Hardening عملی Access Layer

از Symptom تا مرحله Protocol

«شبکه ندارم» را به مرحله تبدیل کن: Link Up است؟ MAC Learn شده؟ Port Security Violation دارد؟ DHCP Lease گرفته؟ ARP Gateway Resolve می‌شود؟ IPv6 RA/Default Route وجود دارد؟ Broadcast Drop غیرعادی است؟ این ترتیب Failure Domain را سریع کوچک می‌کند.

هر مرحله Output خاص دارد. ترکیب show interfaces، MAC Table، Port Security، Snooping Binding، DAI Statistics و Log به‌مراتب بهتر از reboot کردن Switch است.

Link -> MAC admission -> DHCP -> ARP -> IPv6 RA -> routing/application

برای Troubleshooting و Hardening عملی Access Layer، فهم از Symptom تا مرحله Protocol باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد می‌کند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع می‌شوند که یک علامت مشترک به فناوری اشتباه نسبت داده می‌شود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند»، هنگام Incident به‌جای حدس زدن، Failure Domain را کوچک می‌کنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.

Feature-specific Evidence

Port Security: violation/current MAC. DHCP Snooping: trust/binding. DAI: validation/drop. RA Guard: RA policy/drop. Storm Control: threshold/drop/action. Counterها باید هم‌زمان با Test دیده شوند.

یک Counter قدیمی بدون Timestamp ممکن است مربوط به Incident فعلی نباشد؛ Trend و Last Change را در نظر بگیر.

show port-security interface <port>
show ip dhcp snooping binding
show ip arp inspection statistics
show storm-control
show logging

برای تحلیل عملی Feature-specific Evidence یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در Troubleshooting و Hardening عملی Access Layer کمک می‌کند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحله‌ای شکست می‌خورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث می‌شود Troubleshooting حتی در شبکه‌ای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.

Config Diff و Template Drift

اگر فقط یک Switch مشکل دارد، Config Port مشکل‌دار را با Port سالم هم‌نقش مقایسه کن. اختلاف Trust، Maximum MAC، VLAN، RA Guard Policy یا Storm Threshold سریعاً مشخص می‌شود.

Template Drift در شبکه بزرگ رایج است. Automation/IaC در فصل‌های بعدی می‌تواند Consistency را بهتر کند، اما حتی دستی نیز Diff روشمند از حدس بهتر است.

پیاده‌سازی Config Diff و Template Drift در شبکه شرکت باید به سه فاز Pre-check، Change و Post-check تقسیم شود. در Pre-check وضعیت فعلی، Dependencyها و مسیر مدیریت را ذخیره کن؛ در Change فقط Scope لازم را تغییر بده؛ در Post-check هم State فنی و هم سرویس کاربر را Verify کن. برای Changeهایی که ممکن است Access مدیریت، Routing یا Security را تحت تأثیر قرار دهند، Rollback را قبل از اجرای دستور بنویس و مسیر Recovery را مشخص کن. هدف این نیست که Configuration فقط از نظر Syntax پذیرفته شود؛ Desired State باید با Design، مستندات، Address Plan و Security Policy سازمان سازگار بماند.

Fix کم‌دامنه

اگر یک Sticky MAC قدیمی مشکل دارد، همان Secure Address را طبق Change اصلاح کن؛ DHCP Snooping کل VLAN را خاموش نکن. اگر Uplink Trust فراموش شده، فقط همان Port معتبر را Trust کن؛ همه Portها را Trusted نکن.

Least Change هم Availability و هم Security را بهتر حفظ می‌کند. بعد از Fix باید Negative Test نیز انجام شود تا Protection هنوز مانع Traffic غیرمجاز باشد.

در Verification مربوط به Fix کم‌دامنه، خروجی Command را به‌صورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان می‌دهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان می‌دهد Feature واقعاً چه می‌کند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در Troubleshooting و Hardening عملی Access Layer بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.

Post-check و مستندسازی

بعد از Restore سرویس، Feature State، Binding/Counter و User Test را دوباره بررسی کن. Root Cause، Trigger، Impact، Fix و Preventive Action را ثبت کن. اگر Template اشتباه بوده، فقط یک Port را Fix نکن؛ Scope Potential Drift را بررسی کن.

هدف عملیات حرفه‌ای این است که Incident مشابه دوباره رخ ندهد. Monitoring Alert، Documentation یا Template Update بخشی از Fix کامل است.

show running-config interface <port>
show logging
show interfaces status
! Compare with a known-good port template

مسیر Troubleshooting Post-check و مستندسازی را با کم‌هزینه‌ترین Test شروع کن که بیشترین اطلاعات را می‌دهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیک‌ترین Boundary سالم به کاربر یا Source را پیدا کن و قدم‌به‌قدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بی‌دلیل دست‌کاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات می‌توانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.