راینو

در پایان این درس باید بتوانی

IPv4/IPv6 Address و Prefix را از پایه توضیح بدهی
DHCP Client/Server/Relay را در یک سناریوی واقعی تحلیل کنی
Gateway، Neighbor و Reachability را با روش کنترل‌شده پیاده‌سازی کنی
DNS Record و Name Resolution را با Evidence بررسی کنی
NAT/PAT و Internet Edge را مرحله‌به‌مرحله عیب‌یابی کنی

IPv4/IPv6 Address و Prefix

برای IPv4 آدرس، Mask، Gateway و Subnet را Validate کن؛ برای IPv6 Prefix Length، Link-Local Gateway، RA/SLAAC و Route را ببین. /64 باید به‌صورت Prefix Length صحیح در Context IPv6 تفسیر شود و نمایش RTL نباید معنا را تغییر دهد.

برای فهم این مفهوم باید مرز آن با فناوری‌های مجاور روشن باشد. در شبکه واقعی، یک علامت مشابه می‌تواند از چند لایه ایجاد شود؛ بنابراین تعریف دقیق باعث می‌شود از تغییر Configuration نامرتبط جلوگیری شود.

Address validation

IPv4: address/mask/gateway
IPv6: address/prefix/link-local gateway/route

برای Troubleshooting IPv4/IPv6، DHCP، DNS و NAT/PAT، فهم IPv4/IPv6 Address و Prefix باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد می‌کند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع می‌شوند که یک علامت مشترک به فناوری اشتباه نسبت داده می‌شود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند»، هنگام Incident به‌جای حدس زدن، Failure Domain را کوچک می‌کنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.

DHCP Client/Server/Relay

DHCP را با DORA و Relay Path دنبال کن. Client Discover می‌فرستد، Server Offer می‌دهد، Request/ACK تکمیل Lease می‌کند. اگر Server در Subnet دیگر است، ip helper-address/Relay و Routing لازم‌اند. DHCP Snooping می‌تواند Server Response را نیز Filter کند.

جریان را از دید Packet یا State دنبال کن، نه فقط از دید Command. هر مرحله باید Input، تصمیم و Output مشخص داشته باشد و بتوانی بگویی شکست در آن مرحله چه علامتی تولید می‌کند.

DHCP flow

DHCPDISCOVER -> DHCPOFFER -> DHCPREQUEST -> DHCPACK

برای تحلیل عملی DHCP Client/Server/Relay یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در Troubleshooting IPv4/IPv6، DHCP، DNS و NAT/PAT کمک می‌کند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحله‌ای شکست می‌خورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث می‌شود Troubleshooting حتی در شبکه‌ای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.

Gateway، Neighbor و Reachability

پس از IP، First Hop را Test کن و ARP/Neighbor Table را بررسی کن. اگر Gateway Reach نمی‌شود، DNS/NAT دورتر اولویت ندارد. در IPv6 وجود Global Address بدون Default Route کافی نیست.

Configuration باید بعد از Baseline و با Scope مشخص انجام شود. نمونه دستور برای Lab است و Syntax یا Capability دقیق می‌تواند با Platform و IOS XE Release تفاوت داشته باشد؛ Contextual Help و مستندات همان Device مرجع نهایی‌اند.

First hop

ping <gateway>
arp -a
ip -6 route

پیاده‌سازی Gateway، Neighbor و Reachability در شبکه شرکت باید به سه فاز 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 سازمان سازگار بماند.

DNS Record و Name Resolution

اگر IP مستقیم Application کار می‌کند ولی Name نه، A/AAAA/CNAME/MX/NS/PTR را متناسب با سرویس Query کن و Resolver/Authoritative/TTL را جدا ببین. در Dual Stack A و AAAA باید هر دو بررسی شوند.

Verification یعنی مقایسه State عملیاتی با Intent. وجود خط Configuration فقط Desired State را نشان می‌دهد؛ Counter، Table، Log یا Test End-to-End ثابت می‌کند Feature واقعاً چگونه کار می‌کند.

DNS

nslookup app.example.com
dig app.example.com A
dig app.example.com AAAA

در Verification مربوط به DNS Record و Name Resolution، خروجی 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 IPv4/IPv6، DHCP، DNS و NAT/PAT بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.

NAT/PAT و Internet Edge

در Edge، Default Route، NAT Inside/Outside، ACL Match و Translation Table را هم‌زمان با Test Client بررسی کن. Translation وجود دارد ولی Reply نیست؟ Upstream/Firewall/Server. Translation نیست؟ Match/Role/Route را بررسی کن.

در Troubleshooting ابتدا Scope و Flow را ثبت کن، سپس کم‌هزینه‌ترین Test را اجرا کن که یک فرضیه را تأیید یا رد می‌کند. قبل از Clear، Reload یا Disable کردن Feature، Evidence را جمع کن تا Root Cause از بین نرود.

NAT

show ip nat translations
show ip nat statistics
show access-lists

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

سناریوی عملی

یک VLAN جدید IP می‌گیرد و Gateway را Ping می‌کند اما Internet ندارد. DNS و Remote IP هر دو Fail. NAT Translation برای Client ساخته نمی‌شود و ACL NAT Subnet جدید را Match نمی‌کند. اضافه کردن Match صحیح مشکل را حل می‌کند؛ DHCP سالم بود.

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

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

تغییر Troubleshooting IPv4/IPv6، DHCP، DNS و NAT/PAT بدون Baseline و Scope مشخص
قضاوت درباره Troubleshooting IPv4/IPv6، DHCP، DNS و NAT/PAT فقط از روی وجود Configuration
نادیده گرفتن Dependencyها و مسیر واقعی Packet/State
انجام Clear/Disable گسترده قبل از جمع‌آوری Evidence

تمرین عملی

یک Diagram یا State Flow برای Troubleshooting IPv4/IPv6، DHCP، DNS و NAT/PAT رسم کن
نمونه Configuration/Policy Troubleshooting IPv4/IPv6، DHCP، DNS و NAT/PAT را در Lab بررسی کن
خروجی Verification را قبل و بعد از یک Test مقایسه کن
یک Failure عمدی بساز و Root Cause را با Runbook پیدا کن

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

برای IPv4 آدرس، Mask، Gateway و Subnet را Validate کن؛ برای IPv6 Prefix Length، Link-Local Gateway، RA/SLAAC و Route را ببین
DHCP را با DORA و Relay Path دنبال کن
پس از IP، First Hop را Test کن و ARP/Neighbor Table را بررسی کن
اگر IP مستقیم Application کار می‌کند ولی Name نه، A/AAAA/CNAME/MX/NS/PTR را متناسب با سرویس Query کن و Resolver/Authoritative/TTL را جدا ببین
در Edge، Default Route، NAT Inside/Outside، ACL Match و Translation Table را هم‌زمان با Test Client بررسی کن

خودسنجی

IPv4/IPv6 Address و Prefix چه مسئله‌ای را حل یا توضیح می‌دهد؟

برای IPv4 آدرس، Mask، Gateway و Subnet را Validate کن؛ برای IPv6 Prefix Length، Link-Local Gateway، RA/SLAAC و Route را ببین.

در DHCP Client/Server/Relay مهم‌ترین State یا جریان چیست؟

DHCP را با DORA و Relay Path دنبال کن.

قبل از Gateway، Neighbor و Reachability چه کاری ضروری است؟

Baseline، Scope و Rollback مشخص شود.

اصل کلیدی NAT/PAT و Internet Edge چیست؟

هر Test باید یک فرضیه را با Evidence تأیید یا رد کند.

منابع رسمی

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

Cisco CCNA 200-301 v2.0 Exam Topics (۲۰۲۶)

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

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

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

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

بازگشت به صفحه دوره CCNA