چرا بعضی VLANها عبور می‌کنند و بعضی نه؟ 7 علت رایج در سوئیچ سیسکو

اگر بعضی VLANها عبور می‌کنند و بعضی نه، در اغلب موارد مشکل از Allowed VLAN در Trunk، نبود VLAN در یکی از سوئیچ‌ها، وضعیت SVI یا ACL اشتباه است؛ مسیر عیب‌یابی باید از لایه 2 شروع و تا Routing و سیاست‌های امنیتی ادامه یابد. این مقاله دقیقاً 7 علت رایج را بر اساس تجربه پروژه‌های واقعی توضیح می‌دهد.

در بیش از صد پروژه طراحی و عیب‌یابی شبکه‌های سازمانی، این سناریو بارها تکرار شده است: VLAN 10 بدون مشکل کار می‌کند، اما VLAN 20 یا 30 به مقصد نمی‌رسد. اغلب تیم‌ها مستقیماً سراغ تغییر تجهیزات می‌روند، در حالی‌که ریشه مشکل معمولاً در تنظیمات است، نه سخت‌افزار.

  VLAN در Trunk Allow نشده است

رایج‌ترین علت عبور نکردن یک VLAN، عدم Allow شدن آن در لینک Trunk بین سوئیچ‌هاست.

در شبکه‌های مبتنی بر Access Switchهایی مانند WS-C2960-24TC-L، معمولاً VLAN جدید روی سوئیچ Access تعریف می‌شود اما در لینک Trunk به Distribution اضافه نمی‌شود. نتیجه این است که برخی VLANها عبور می‌کنند (چون از قبل Allow شده‌اند) و VLAN جدید عبور نمی‌کند.

در یک پروژه سازمانی که مدیریت آن را بر عهده داشتم، VLAN جدید برای تیم مالی ایجاد شد، اما Allowed VLAN روی یکی از لینک‌های Distribution به‌روزرسانی نشد. از دید کاربران، فقط “بعضی شبکه‌ها کار می‌کردند”. بررسی show interface trunk مشکل را آشکار کرد.

قاعده قطعی: اگر VLAN در تمام لینک‌های Trunk مسیر خود Allow نشده باشد، هرگز به مقصد نخواهد رسید.

 VLAN در یکی از سوئیچ‌ها اصلاً ایجاد نشده است

اگر VLAN روی یک سوئیچ تعریف نشده باشد، حتی اگر Trunk درست باشد، آن VLAN Drop می‌شود.

در شبکه‌های چندسوییچه، گاهی VLAN در Access تعریف می‌شود اما در Distribution یا Core وجود ندارد. این موضوع به‌ویژه در محیط‌هایی که تغییرات توسط تیم‌های مختلف انجام می‌شود، رایج است.

در پروژه‌ای مبتنی بر WS-C2960C-8PC-L در یک شعبه سازمانی، VLAN روی Access ایجاد شده بود اما روی سوئیچ لایه 3 تعریف نشده بود. Trunk سالم بود، اما چون VLAN در مقصد شناخته نمی‌شد، ترافیک عبور نمی‌کرد. این مشکل با یک بررسی ساده show vlan برطرف شد.

اصل مهم: تعریف VLAN باید در تمام سوئیچ‌های مسیر وجود داشته باشد، نه فقط در مبدا.

 Native VLAN ناهماهنگ در Trunk

عدم تطابق Native VLAN بین دو سمت Trunk می‌تواند باعث عبور نامنظم یا اختلال در برخی VLANها شود.

در یکی از شبکه‌هایی که روی بستر سوئیچ سیسکو 3750 طراحی شده بود، یک سمت Trunk Native VLAN 1 و سمت دیگر Native VLAN 99 داشت. در ظاهر برخی VLANها کار می‌کردند اما ترافیک خاصی دچار اختلال بود. این نوع خطا معمولاً به‌صورت intermittent دیده می‌شود.

در پروژه‌ای که توسط تیم‌های ساختاری مانند آنچه در وینو سرور اجرا شده دیده‌ام، Native VLAN به‌صورت استاندارد مستندسازی و یکنواخت تعریف می‌شود تا از این نوع خطا جلوگیری شود.

مرزبندی روشن: Native VLAN باید در هر دو سمت Trunk کاملاً یکسان باشد.

مشکل در SVI یا Gateway VLAN

اگر SVI مربوط به یک VLAN Down باشد یا IP اشتباه داشته باشد، آن VLAN Routing نخواهد شد.

در شبکه‌هایی که Inter-VLAN Routing روی سوئیچ لایه 3 انجام می‌شود، هر VLAN باید SVI فعال و Up داشته باشد. در یک پروژه Migration، VLAN جدید تعریف شد اما SVI آن Shutdown باقی ماند. کاربران آن VLAN نمی‌توانستند به شبکه‌های دیگر دسترسی داشته باشند، در حالی‌که VLANهای قدیمی بدون مشکل کار می‌کردند.

همچنین اگر IP Gateway اشتباه تعریف شده باشد، ارتباط فقط در همان VLAN برقرار است اما بین VLANها قطع می‌شود. بررسی show ip interface brief در این مرحله حیاتی است.

قاعده قطعی: اگر VLAN در لایه 2 عبور می‌کند اما به VLAN دیگر نمی‌رسد، وضعیت SVI را بررسی کنید.

  ACL یا سیاست امنیتی اشتباه

گاهی فقط برخی VLANها به‌دلیل ACL یا Policy امنیتی مسدود می‌شوند، در حالی‌که بقیه عبور می‌کنند.

در یک سازمان چندسایتی، VLAN کاربران به سرور دسترسی داشت اما VLAN مهمان مسدود بود. تیم تصور می‌کرد مشکل از Trunk است، اما بررسی ACL روی Distribution نشان داد که یک Rule اشتباه Subnet مربوط به VLAN جدید را Deny کرده است.

در تجربه عملی، بسیاری از مشکلات “عبور نکردن بعضی VLANها” در واقع نتیجه سیاست‌های امنیتی ناقص یا بدون مستندات است. ACL باید دقیق و تست‌شده باشد، نه براساس حدس.

اشتباه در DHCP یا IP Plan

اگر یک VLAN از نظر لایه 2 عبور می‌کند اما کلاینت IP معتبر دریافت نمی‌کند، ممکن است مشکل از DHCP Scope یا IP Plan باشد.

در یکی از پروژه‌ها، VLAN جدید تعریف شد و Trunk سالم بود، اما کاربران IP از Subnet اشتباه دریافت می‌کردند. دلیل آن، عدم تعریف DHCP Scope جدید بود. از دید کاربر، VLAN “کار نمی‌کرد”، اما در واقع IP Addressing اشتباه بود.

این خطا به‌ویژه در شبکه‌هایی که هم‌زمان چند VLAN اضافه می‌شود، رایج است. بررسی DHCP Binding و ARP Table در این مرحله ضروری است.

اصل مهم: عبور VLAN به معنای داشتن IP صحیح نیست.

 Loop یا STP Blocking در یک مسیر خاص

در برخی سناریوها، STP یک لینک خاص را برای یک VLAN Block می‌کند و باعث می‌شود فقط برخی VLANها از مسیر خاصی عبور کنند.

در شبکه‌ای که مبتنی بر چندین سوئیچ Access و Distribution بود، برای برخی VLANها Root Bridge متفاوتی تعریف شده بود. در نتیجه مسیر عبور برای VLAN 10 و VLAN 20 متفاوت شد. یکی از مسیرها به‌دلیل Loop موقت Block شده بود و فقط VLAN خاصی تحت تأثیر قرار گرفت.

این نوع خطا پیچیده‌تر است و نیاز به بررسی show spanning-tree vlan دارد. در پروژه‌هایی که معماری به‌درستی طراحی نشده، این سناریو بیشتر دیده می‌شود.

قاعده قطعی: اگر همه تنظیمات درست است اما مشکل فقط در یک مسیر رخ می‌دهد، STP را بررسی کنید.

کیس استادی: اختلال مقطعی در VLAN مالی

در یک سازمان دولتی، VLAN مالی به‌صورت مقطعی قطع می‌شد اما VLANهای دیگر پایدار بودند. تیم داخلی تصور می‌کرد سوئیچ Access مشکل دارد. بررسی مرحله‌به‌مرحله نشان داد Allowed VLAN در یکی از لینک‌های Redundant به‌درستی به‌روزرسانی نشده بود.

به‌عنوان مدیر پروژه بررسی، با مقایسه تنظیمات Trunk در هر دو لینک، اختلاف آشکار شد. اصلاح Allowed List مشکل را به‌طور کامل رفع کرد. این تجربه نشان داد که ترتیب عیب‌یابی مهم‌تر از حدس زدن است.

جمع‌بندی اجرایی برای مدیران IT و خرید

اگر بعضی VLANها عبور می‌کنند و بعضی نه، تقریباً همیشه مشکل در یکی از این هفت لایه است: Allowed VLAN، تعریف VLAN، Native VLAN، SVI، ACL، DHCP یا STP. مسیر عیب‌یابی باید از لایه 2 شروع و به لایه 3 و امنیت ختم شود.

برای مدیر IT، توصیه روشن است: قبل از هر تصمیم برای تعویض تجهیزات یا ارتقاء شبکه، یک بررسی ساختاری مرحله‌به‌مرحله انجام دهید. در اغلب پروژه‌ها، مشکل با اصلاح یک خط تنظیم حل شده است، نه با خرید سخت‌افزار جدید.

برای مدیر خرید نیز پیام واضح است: مشکل عبور نکردن VLANها به‌ندرت ناشی از ضعف سخت‌افزار است. چه روی WS-C2960-24TC-L کار کنید و چه روی سوئیچ سیسکو 3750، کیفیت طراحی و تنظیمات تعیین‌کننده است.

در نهایت، عیب‌یابی Inter-VLAN یک فرآیند منطقی و سیستماتیک است. اگر از Trunk شروع کنید و تا Routing و ACL پیش بروید، بدون حدس و هزینه اضافی به ریشه مشکل خواهید رسید. شبکه پایدار نتیجه طراحی دقیق و مستندسازی منظم است، نه واکنش هیجانی به اختلال.