خطای IP تکراری و BAD_ADDRESS در DHCP ویندوز؛ از تشخیص تا اصلاح

وجود BAD_ADDRESS در DHCP همیشه به معنی حضور دو رایانه با یک IP نیست. باید تداخل واقعی آدرس را از تشخیص اشتباه ناشی از ARP Probe جدا کنید. پاک‌کردن این رکوردها بدون بررسی علت، ممکن است فقط مشکل را چند ساعت پنهان کند. این راهنما برای شبکه IPv4 با DHCP ویندوز و کلاینت‌های Windows نوشته شده است.

۱. قبل از هر تغییر، شواهد را نگه دارید

از Scope، محدوده آدرس‌ها، Exclusionها و Reservationها گزارش بگیرید. نام کلاینت، زمان قطع ارتباط، VLAN و MAC دستگاه را کنار IP درگیر ثبت کنید. مشخص کنید مشکل پس از تعویض سوییچ، فعال‌کردن یک قابلیت امنیتی یا اضافه‌شدن یک دستگاه ثابت شروع شده است یا خیر. ارتباط زمانی سرنخ است، اما به‌تنهایی علت را ثابت نمی‌کند.

ipconfig /all
Get-NetIPConfiguration

دستور اول را در Command Prompt و دستور دوم را در PowerShell کلاینت اجرا کنید. DHCP Enabled، آدرس DHCP Server، IPv4، Gateway و DNS را بخوانید. آدرس 169.254 در وضعیت خودکار معمولاً نشانه دریافت‌نشدن تنظیمات معتبر است؛ این مشاهده هنوز نمی‌گوید اختلال در سرور، VLAN یا مسیر Relay قرار دارد.

۲. تداخل واقعی آدرس را بررسی کنید

پرینتر، دوربین، تلفن IP و تجهیزات مدیریتی ممکن است دستی آدرسی گرفته باشند که داخل محدوده توزیع DHCP قرار دارد. فهرست آدرس‌های ثابت را با Scope تطبیق دهید. در یک بازه نگهداری، آدرس دستگاه ثابت را به محدوده طراحی‌شده منتقل کنید یا برای آن آدرس Exclusion مناسب بسازید؛ انتخاب روش باید با مستند آدرس‌دهی شبکه هماهنگ باشد.

از جدول MAC سوییچ و جدول ARP برای پیدا کردن محل دستگاه کمک بگیرید. تغییر MAC مشاهده‌شده برای یک IP در چند زمان می‌تواند سرنخ تداخل باشد، اما وجود پروکسی ARP یا تجهیزات خاص را نیز در نظر بگیرید. به یک پاسخ Ping اکتفا نکنید؛ برخی دستگاه‌ها به ICMP پاسخ نمی‌دهند و نبود پاسخ، آزادبودن IP را تضمین نمی‌کند.

۳. Event 4199 و ARP Probe را جداگانه بررسی کنید

در Event Viewer کلاینت، بخش System را در زمان بروز مشکل بخوانید. در سرور، گزارش‌های DHCP در مسیر زیر قرار می‌گیرند:

%windir%\System32\dhcp

Microsoft یک حالت مشخص را مستند کرده است: اگر سوییچ یا روتر هنگام تشخیص تداخل آدرس توسط کلاینت، ARP Probe بفرستد، ویندوز ممکن است آن را تداخل تشخیص دهد و آدرس پیشنهادی را رد کند. این وضعیت می‌تواند با Event 4199 و رکوردهای BAD_ADDRESS همراه شود. برای اثبات این سناریو، زمان رویداد و بسته‌های ARP باید با هم تطبیق داده شوند.

اگر این علت تأیید شد، تنظیم IP Device Tracking یا زمان ارسال Probe را مطابق مستندات مدل سوییچ بررسی کنید. غیرفعال‌کردن تشخیص تداخل در کلاینت، راهکار عمومی مناسبی نیست؛ هشدار لازم در برابر تداخل واقعی را از بین می‌برد. اصلاح را ابتدا روی یک پورت آزمایشی و با امکان برگشت انجام دهید.

۴. مسیر DHCP و نتیجه اصلاح را کنترل کنید

اگر سرور و کلاینت در VLANهای متفاوت‌اند، Relay باید درخواست و پاسخ را منتقل کند. DHCP برای IPv4 از UDP 67 و 68 استفاده می‌کند. نبود Lease می‌تواند به این مسیر مربوط باشد، در حالی که BAD_ADDRESS بررسی جداگانه‌ای لازم دارد. بنابراین خطاهای متفاوت را با یک اقدام واحد مانند افزایش Pool درمان نکنید.

بعد از اصلاح علت و در زمان مناسب، یک کلاینت آزمایشی را دوباره به دریافت آدرس هدایت کنید. Renew ممکن است ارتباط آن دستگاه را تغییر دهد؛ روی سیستمی که تنها مسیر مدیریت شماست آزمون نکنید. نتیجه مطلوب شامل دریافت Lease معتبر، نبود رویداد تازه تداخل و پایداری دسترسی در چند نوبت است.

آیا حذف BAD_ADDRESS کافی است؟

خیر. ابتدا علت را رفع کنید و سپس رکوردهای مربوط را با ثبت تغییر مدیریت کنید. گزارش تحویل باید علت تأییدشده، دستگاه یا پورت درگیر و نتیجه آزمون را نشان دهد. برای شناخت روند رسیدگی، پشتیبانی شبکه شرکت‌ها و خدمات پشتیبانی دوره‌ای را بررسی کنید.

منابع رسمی

Microsoft: Event 4199 و BAD_ADDRESS؛ Microsoft: فرآیند و عیب‌یابی DHCP.