معماری شبکه مجازی با Open vSwitch

مقدمه

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

مواردی مانند:

• VLAN
• Trunk
• ایزوله‌سازی شبکه
• اتصال به فایروال مجازی
• کنترل پهنای باند
• امنیت پورت‌ها
• اتصال چند شبکه مجازی به شبکه فیزیکی
• مدیریت متمرکز ترافیک ماشین‌های مجازی و کانتینرها

باعث می‌شوند به سمت Open vSwitch یا به اختصار OVS حرکت کنیم.

📌 هدف این مستند

این مستند قصد آموزش از طریق Plaivid یا Command-Line را ندارد. هدف اصلی این است که معماری را یاد بگیرید.

پس از مطالعه این مستند، پاسخ سؤالات زیر را خواهید دانست:

• OVS چیست؟
• چرا استفاده می‌شود؟
• یک سوئیچ مجازی چه چیزی را ایجاد می‌کند؟
• پروفایل روی سوئیچ چیست؟
• پروفایل Access چیست؟
• پروفایل Trunk چیست؟
• VLAN کجا اعمال می‌شود؟
• IP را کجا باید قرار داد؟
• وقتی پورت فیزیکی سرور به سوئیچ فیزیکی وصل است، چه معماری‌ای درست است؟
• وقتی پورت فیزیکی Trunk است، چه کنیم؟
• وقتی pfSense مجازی داریم، معماری چگونه است؟
• طراحی LACP چگونه است؟
• وقتی اتصال مستقیم به فایروال داریم، چه طراحی‌ای استاندارد است؟

OVS چیست؟

Open vSwitch یا OVS یک سوئیچ مجازی نرم‌افزاری است. این سوئیچ در لایه ۲ مدل OSI کار می‌کند و می‌تواند ترافیک بین ماشین‌های مجازی، کانتینرها و شبکه فیزیکی را مدیریت کند.

💡 به زبان ساده

OVS مثل یک سوئیچ شبکه است، اما به جای اینکه یک دستگاه فیزیکی باشد، داخل سرور مجازی‌ساز اجرا می‌شود.

این سوئیچ می‌تواند کارهایی شبیه سوئیچ‌های فیزیکی انجام دهد:

• ساخت چند پورت مجازی
• اتصال ماشین‌های مجازی به یکدیگر
• اتصال ماشین‌های مجازی به شبکه فیزیکی
• اعمال VLAN
• ایجاد پورت Access
• ایجاد پورت Trunk
• کنترل پهنای باند
• ایزوله کردن شبکه‌ها
• اتصال به فایروال مجازی
• ساخت شبکه‌های داخلی جدا از شبکه سازمان

چرا از بریج عادی به OVS مهاجرت می‌کنیم؟

بریج ساده برای سناریوهای اولیه مناسب است، اما وقتی زیرساخت بزرگ‌تر می‌شود، محدودیت‌های آن مشخص می‌شود.

ویژگی	بریج عادی	OVS
شبکه ساده بدون VLAN	✅	✅
چند ماشین مجازی ساده	✅	✅
VLANهای متعدد	❌	✅
Trunk بین سرور و سوئیچ فیزیکی	❌	✅
اتصال به فایروال مجازی (pfSense)	❌	✅
جداسازی شبکه مدیریت، VMها و DMZ	❌	✅
کنترل پهنای باند	❌	✅
معماری قابل توسعه	❌	✅
هماهنگی دقیق با شبکه فیزیکی	❌	✅

📝 یادداشت

وقتی زیرساخت به سمت استانداردسازی می‌رود، استفاده از OVS منطقی‌تر است.

سوئیچ مجازی چیست؟

⚠️ مفهوم بسیار مهم

وقتی در OVS یک سوئیچ مجازی ایجاد می‌کنید، در واقع یک محوطه سوئیچینگ مجازی ساخته‌اید. این سوئیچ هنوز به تنهایی یک رفتار شبکه‌ای کامل ندارد.

صرفاً ساختن سوئیچ، به معنی داشتن VLAN، IP، Trunk یا Access نیست.

سوئیچ مجازی مثل یک شاسی یا بدنه سوئیچ است. برای اینکه رفتار شبکه مشخص شود، باید روی این سوئیچ پروفایل و پورت تعریف کنید.

ℹ️ اطلاعات

ساخت سوئیچ مجازی فقط زیرساخت را ایجاد می‌کند. این پروفایل‌ها هستند که مشخص می‌کنند هر پورت چه رفتاری داشته باشد.

پروفایل OVS چیست؟

پروفایل در واقع یک قالب تنظیمات برای یک پورت است. وقتی می‌خواهید یک کارت شبکه فیزیکی، یک ماشین مجازی یا یک کانتینر را به سوئیچ مجازی وصل کنید، باید مشخص کنید این اتصال چه ویژگی‌هایی داشته باشد.

به این مجموعه ویژگی‌ها می‌گوییم Profile:

• این پورت Access باشد یا Trunk؟
• عضو کدام VLAN باشد؟
• کدام VLANها را عبور دهد؟
• VLAN بومی یا Native آن چیست؟
• آیا محدودیت پهنای باند دارد؟
• آیا برای مدیریت است یا برای دیتا؟
• به کدام بخش شبکه فیزیکی متصل می‌شود؟

اجزای اصلی معماری OVS

سوئیچ مجازی

سوئیچ مجازی نقطه مرکزی اتصال است. ممکن است چندین سوئیچ مجازی با کاربردهای مختلف داشته باشید:

• سوئیچ مجازی برای شبکه اصلی VMها
• سوئیچ مجازی برای شبکه مدیریت
• سوئیچ مجازی برای DMZ
• سوئیچ مجازی برای WAN فایروال
• سوئیچ مجازی برای LAN فایروال
• سوئیچ مجازی برای شبکه ایزوله تست

پورت فیزیکی (Uplink)

پورت فیزیکی سرور، پلی است بین دنیای مجازی داخل سرور و شبکه فیزیکی.

اگر سرور دارای دو کارت شبکه باشد:

• کارت شبکه اول: ممکن است برای مدیریت سرور باشد.
• کارت شبکه دوم: ممکن است برای اتصال VMها و کانتینرها به شبکه فیزیکی باشد.

به پورت فیزیکی که به شبکه بیرون وصل می‌شود معمولاً Uplink می‌گوییم.

پورت مجازی

هر ماشین مجازی یا کانتینر یک کارت شبکه مجازی دارد. این کارت شبکه مجازی باید به یک پروفایل روی سوئیچ OVS متصل شود:

• پورت VM وب‌سرور
• پورت VM دیتابیس
• پورت کانتینر App
• پورت LAN فایروال pfSense
• پورت WAN فایروال pfSense

پروفایل داخلی (Internal)

گاهی خود سرور مجازی‌ساز نیاز دارد در یک VLAN یا شبکه خاص IP داشته باشد. مثلاً برای مدیریت، Backup، Monitoring یا ارتباط با سرویس‌های سازمانی.

🔴 خطر

در این حالت نباید IP را مستقیم روی کارت شبکه فیزیکی گذاشت. بهتر است یک پروفایل داخلی روی OVS ساخته شود و IP سرور روی آن پروفایل داخلی قرار بگیرد.

پروفایل Access

پروفایل Access برای دستگاه‌هایی استفاده می‌شود که نباید تگ VLAN را ببینند:

• ماشین مجازی معمولی
• کانتینر معمولی
• سرویسی که فقط باید در یک VLAN خاص باشد

در پروفایل Access:

• ترافیک ورودی از VM بدون تگ است.
• OVS آن را به VLAN مشخص‌شده نسبت می‌دهد.
• وقتی ترافیک از سمت شبکه برمی‌گردد، OVS تگ را برمی‌دارد و فریم بدون تگ به VM می‌رسد.

💡 نکته

خلاصه: پروفایل Access سمت End Deviceها استفاده می‌شود.

پروفایل Trunk

پروفایل Trunk برای عبور چند VLAN استفاده می‌شود. این حالت معمولاً بین:

• سرور مجازی‌ساز و سوئیچ فیزیکی
• سرور مجازی‌ساز و فایروال
• سوئیچ مجازی و روتر مجازی
• فایروال مجازی و شبکه‌های مختلف

در پروفایل Trunk:

• فریم‌ها معمولاً با تگ VLAN عبور می‌کنند.
• می‌توان مشخص کرد فقط چه VLANهایی اجازه عبور دارند.
• می‌توان یک VLAN را به عنوان Native یا بدون تگ تعریف کرد.

VLAN چیست و چرا در OVS مهم است؟

VLAN یعنی تقسیم یک شبکه فیزیکی به چند شبکه منطقی. VLAN یک شبکه مجازی است که به صورت منطقی از شبکه‌های دیگر جدا می‌شود.

مثلاً شبکه فیزیکی ممکن است این VLANها را داشته باشد:

VLAN	کاربرد
VLAN 10	کاربران
VLAN 20	سرورها
VLAN 30	مدیریت
VLAN 40	DMZ
VLAN 50	Guest

وقتی سرور مجازی‌ساز به شبکه فیزیکی وصل می‌شود، باید دقیقاً مطابق همان VLANها رفتار کند.

🔴 اگر VLAN اشتباه تنظیم شود

• ترافیک به شبکه اشتباه می‌رود.
• ممکن است ترافیک Drop شود.
• ممکن است Broadcast Domain اشتباهی ایجاد شود.
• ممکن است امنیت شبکه به خطر بیفتد.
• ممکن است ماشین مجازی IP اشتباه بگیرد یا به gateway اشتباه برود.

مفهوم Access و Trunk در معماری واقعی

Access

پورتی است که معمولاً یک دستگاه نهایی به آن وصل می‌شود. یک پورت فقط برای یک VLAN استفاده می‌شود و دستگاه پشت آن معمولاً تگ VLAN را نمی‌بیند.

Trunk

یک پورت می‌تواند ترافیک چند VLAN را عبور دهد و معمولاً تگ VLAN را حفظ می‌کند.

💡 مزیت Trunk

به جای اینکه برای هر VLAN یک کابل جدا بین دو سوئیچ بکشید، یک کابل را Trunk می‌کنید. در نتیجه همان یک کابل می‌تواند ترافیک VLAN 10، VLAN 20 و VLAN 30 را حمل کند.

VLAN Tag چیست؟

وقتی فریم از یک Trunk عبور می‌کند، سوئیچ معمولاً یک VLAN Tag به آن اضافه می‌کند تا مشخص شود این فریم متعلق به کدام VLAN است. استاندارد رایج این کار 802.1Q است.

مفهوم	توضیح
Access	این پورت متعلق به یک VLAN است.
Trunk	این پورت می‌تواند چند VLAN را عبور دهد.
Tag	مشخص می‌کند فریمی که روی Trunk حرکت می‌کند متعلق به کدام VLAN است.

استاندارد نام‌گذاری

⚠️ هشدار

یکی از مهم‌ترین بخش‌های استانداردسازی، نام‌گذاری درست است. اگر نام‌گذاری استاندارد نداشته باشید، بعد از مدتی نمی‌دانید هر پروفایل برای چه چیزی است.

نام‌گذاری سوئیچ مجازی

نام پیشنهادی	کاربرد
ovs-edge	سوئیچ متصل به شبکه بیرونی
ovs-lan	سوئیچ داخلی برای VMها
ovs-dmz	سوئیچ برای سرویس‌های DMZ
ovs-mgmt	سوئیچ مدیریت
ovs-fw-wan	سوئیچ سمت WAN فایروال
ovs-fw-lan	سوئیچ سمت LAN فایروال
ovs-isolated	سوئیچ ایزوله و بدون دسترسی بیرونی

نام‌گذاری پروفایل

نام پیشنهادی	کاربرد
uplink-phys-trunk-vlan20	پروفایل پورت فیزیکی به صورت Trunk برای VLAN 20
uplink-phys-access-vlan10	پروفایل پورت فیزیکی به صورت Access برای VLAN 10
vm-web-access-vlan20	پروفایل ماشین مجازی وب در VLAN 20
ct-app-access-vlan20	پروفایل کانتینر اپلیکیشن در VLAN 20
fw-wan-vlan20	پروفایل WAN فایروال در VLAN 20
fw-lan-private	پروفایل LAN داخلی فایروال
mgmt-internal-vlan30	پروفایل داخلی برای مدیریت سرور در VLAN 30

اصول طلایی استاندارد OVS

🔒 امنیت

قبل از ورود به سناریوها، این اصول را حتماً رعایت کنید.

اصل ۱: اول معماری، بعد اتصال

قبل از ساخت هر پروفایل باید بدانید:

• این ترافیک قرار است به کجا برود؟
• VLAN آن چیست؟
• Gateway آن کجاست؟
• آیا فایروال لازم است؟
• آیا این شبکه باید ایزوله باشد؟
• آیا شبکه فیزیکی Trunk داده یا Access؟
• چه IP Range استفاده می‌شود؟

اصل ۲: هر شبکه منطقی باید هویت مشخص داشته باشد

هر VLAN یا هر Zone باید موارد زیر را داشته باشد:

• VLAN ID
• Subnet
• Gateway
• کاربرد
• سطح دسترسی
• مسئول فنی
• محدودیت‌های امنیتی

اصل ۳: پورت فیزیکی را مستقیم IP ندهید

🔴 خطر

وقتی پورت فیزیکی وارد OVS می‌شود، بهتر است دیگر مستقیم IP نداشته باشد. اگر خود سرور نیاز به IP دارد، باید IP را روی یک پروفایل داخلی قرار دهید.

اصل ۴: Access برای endpoint، Trunk برای لینک‌های شبکه‌ای

هدف اتصال	حالت پیشنهادی
VM و کانتینر	Access
لینک به سوئیچ فیزیکی	Access یا Trunk (بسته به نوع پورت فیزیکی)
لینک به فایروال مجازی	Access یا Trunk (اکثراً Access)
لینک بین سوئیچ‌های مجازی یا روتر مجازی	معمولاً Trunk

اصل ۵: حداقل VLANهای ممکن را Allow کنید

🔒 امنیت

اگر فقط VLAN 20 نیاز است، نباید همه VLANها را روی Trunk باز بگذارید. این موضوع هم امنیتی است و هم از خطاهای شبکه جلوگیری می‌کند.

اگر موقع ساخت پروفایل در حالت Trunk، Tag VLAN را خالی بگذارید، تمامی ترافیک‌های هر VLAN عبور داده می‌شود.

اصل ۶: Native VLAN باید مشخص و کنترل‌شده باشد

اگر از Trunk استفاده می‌کنید، حتماً بدانید Native VLAN چیست. اگر Native VLAN اشتباه تنظیم شود، ممکن است ترافیک بدون تگ وارد VLAN اشتباهی شود.

اصل ۷: IP مربوط به لایه ۳ است، OVS ذاتاً لایه ۲ است

ℹ️ اطلاعات

OVS به تنهایی یک سوئیچ لایه ۲ است. اگر نیاز به routing بین VLANها دارید، باید یک روتر یا فایروال مثل pfSense در مسیر باشد.

فرآیند استاندارد راه‌اندازی OVS

در هر محیط مجازی‌سازی، فارغ از اینکه پنل آن چیست، روند کلی تقریباً یکسان است.

مرحله ۱: شناسایی کارت شبکه فیزیکی

ابتدا مشخص کنید کدام کارت شبکه سرور به شبکه فیزیکی وصل است:

• کارت شبکه اول: مدیریت سرور
• کارت شبکه دوم: اتصال VMها و کانتینرها به شبکه فیزیکی

📝 یادداشت

از اینجا به بعد فرض می‌کنیم کارت شبکه دوم قرار است از طریق OVS به شبکه فیزیکی وصل شود.

مرحله ۲: ساخت سوئیچ مجازی

یک سوئیچ مجازی ایجاد می‌کنید. این سوئیچ مثل یک سوئیچ داخلی در سرور عمل می‌کند.

⚠️ هشدار

نام آن را طبق استاندارد نام‌گذاری انتخاب کنید، نه به دلخواه. تا این مرحله هنوز VLAN، Trunk یا Access تعریف نشده است. فقط یک سوئیچ خالی ساخته شده است.

مرحله ۳: ساخت پروفایل برای کارت شبکه فیزیکی

حالا باید مشخص کنید کارت شبکه فیزیکی سرور چگونه به شبکه فیزیکی وصل شود. در این پروفایل مشخص می‌کنید:

• نوع پورت: فیزیکی
• حالت: Access یا Trunk
• VLAN یا VLANهای مجاز
• محدودیت پهنای باند در صورت نیاز
• توضیحات

مرحله ۴: ساخت پروفایل برای ماشین‌های مجازی یا کانتینرها

برای هر VM یا کانتینر یک پروفایل متصل به همان سوئیچ مجازی ایجاد می‌کنید. در این پروفایل مشخص می‌کنید:

• نوع پورت: مجازی
• حالت: Access یا Trunk
• VLAN مورد نظر
• محدودیت پهنای باند
• توضیحات

مرحله ۵: اتصال پروفایل به ماشین مجازی یا کانتینر

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

مرحله ۶: تنظیم IP داخل ماشین مجازی یا کانتینر

اگر شبکه فیزیکی DHCP دارد، VM یا کانتینر می‌تواند IP بگیرد. اگر DHCP ندارد، باید IP دستی تنظیم شود:

• IP Address
• Subnet Mask
• Gateway
• DNS

💡 نکته

در صورتی که از کانتینر استفاده می‌شود، باید pfSense یا Ubuntu به‌عنوان DHCP Server راه‌اندازی شده و پروفایل Uplink به‌عنوان کارت شبکه WAN روی آن تنظیم شود.

سناریو اول: پورت Access سوئیچ فیزیکی

شرح سناریو

یک سرور مجازی‌ساز داریم. پورت دوم این سرور با کابل به یکی از پورت‌های سوئیچ فیزیکی وصل شده است. پورت سوئیچ فیزیکی روی حالت Access تنظیم شده است.

ℹ️ پیام شبکه‌کارها

این پورت Access است. VLAN 20 است. هر دستگاهی که به این پورت وصل شود، وارد VLAN 20 می‌شود.

منطق سناریو

وقتی پورت سوئیچ فیزیکی Access است، یعنی سوئیچ انتظار دارد دستگاه متصل‌شده ترافیک را بدون تگ بفرستد.

فریم‌هایی که از پورت سرور وارد سوئیچ می‌شوند، به‌صورت خودکار عضو VLAN 20 در نظر گرفته می‌شوند، زیرا پورت مربوطه روی سوئیچ به VLAN 20 اختصاص داده شده است.

⚠️ هشدار

VLAN توسط پورت Access سوئیچ تعیین می‌شود، نه توسط کانتینر.

پس سرور مجازی‌ساز نباید به سمت سوئیچ فیزیکی تگ VLAN بفرستد. در این حالت پروفایل پورت فیزیکی سرور باید به صورت Access تعریف شود.

پروفایل‌های مورد نیاز

پروفایل Uplink فیزیکی:

این پروفایل برای اتصال OVS به سوئیچ فیزیکی هست !

ویژگی	مقدار پیشنهادی
نام پروفایل	uplink-phys-access-vlan20
نوع پورت	فیزیکی
متصل به	کارت شبکه دوم سرور
سوئیچ OVS	Internal-Switch
حالت	Access
VLAN	20
توضیحات	اتصال به پورت Access سوئیچ فیزیکی

پروفایل ماشین مجازی یا کانتینر:

ویژگی	مقدار پیشنهادی
نام پروفایل	vm-access-vlan20
نوع پورت	مجازی
متصل به	کارت شبکه VM یا کانتینر
سوئیچ OVS	Internal-Switch
حالت	Access
VLAN	20
توضیحات	اتصال VM به VLAN 20 فیزیکی

چرا به دو پروفایل نیاز داریم؟

برای درک بهتر، OVS را مانند یک سوئیچ فیزیکی واقعی در نظر بگیریم.

💡 قیاس با سوئیچ فیزیکی

فرض کنید یک سوئیچ فیزیکی دارید و می‌خواهید آن را به سوئیچ دیگری متصل کنید. یک کابل شبکه از یکی از پورت‌های سوئیچ خودتان به سوئیچ مقصد متصل می‌کنید. این پورت نقش Uplink را دارد.

حالا فرض کنید می‌خواهید یک کامپیوتر را به سوئیچ وصل کنید. این پورت دیگر Uplink نیست؛ بلکه پورتی است که یک End Device به آن متصل می‌شود.

ساختار فیزیکی را درنظر بگیرید :

اتصال بین دو سوئیچ = Uplink

اتصال سرور به سوئیچ = End Device

در OVS نیز دقیقاً همین مفهوم وجود دارد:

1. پروفایل Uplink: اتصال OVS به کارت شبکه دوم سرور و ایجاد مسیر ارتباطی با سوئیچ شبکه فیزیکی.
2. پروفایل End Device: اتصال ماشین‌های مجازی و کانتینرها به OVS.

جریان ترافیک

وقتی VM ترافیک می‌فرستد:

1. VM فریم بدون تگ می‌فرستد.

2. OVS آن را در VLAN 20 قرار می‌دهد.

3. فریم بدون تگ از پورت فیزیکی سرور خارج می‌شود.

4. سوئیچ فیزیکی آن را به عنوان VLAN 20 می‌پذیرد.

ℹ️ اطلاعات

وقتی Frame وارد OVS می‌شود، داخل محیط OVS تگ مربوط به VLAN 20 را می‌گیرد. وقتی قرار است از یک پورت Access خارج شود، منطق سوئیچ تگ VLAN را حذف می‌کند تا Frame به‌صورت Untagged از پورت خارج شود. دقیقاً همان منطقی که در یک سوئیچ واقعی وجود دارد.

وقتی ترافیک از شبکه برمی‌گردد:

1. سوئیچ فیزیکی فریم را در VLAN 20 می‌فرستد.
2. فریم بدون تگ وارد پورت فیزیکی سرور می‌شود.
3. OVS آن را به پورت VM در VLAN 20 تحویل می‌دهد.
4. VM فریم بدون تگ دریافت می‌کند.

اگر خود سرور هم نیاز به IP داشت

🔴 خطر

اگر خود سرور مجازی‌ساز باید در VLAN 20 مدیریت شود، نباید IP را مستقیم روی کارت شبکه فیزیکی گذاشت.

یعنی روی پروفایلی که به کارت شبکه NIC2 متصل شده است (Profile-Uplink)، نباید IP تنظیم شود.

IP باید روی پروفایل End Userها یا یک پروفایل جدید با حالت Access و VLAN Tag 20 تنظیم شود.

چرا این تنظیمات درست است؟

چون پورت سوئیچ فیزیکی Access است. در پورت Access:

• سوئیچ انتظار تگ ندارد.
• دستگاه متصل‌شده نباید تگ بفرستد.
• همه ترافیک به یک VLAN تعلق دارد.
• VLAN توسط سوئیچ فیزیکی مدیریت می‌شود.

⚠️ هشدار

اگر شما در این حالت پورت فیزیکی سرور را Trunk کنید و تگ بفرستید، ممکن است سوئیچ فیزیکی ترافیک را Drop کند یا رفتار نامشخص داشته باشد.

محدودیت این سناریو

📝 یادداشت

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

سناریو دوم: پورت Trunk سوئیچ فیزیکی

شرح سناریو

در این سناریو، پورت دوم سرور به سوئیچ فیزیکی وصل است. اما پورت سوئیچ فیزیکی Access نیست.

ℹ️ پیام شبکه‌کارها

ممکن است بگویند:

• این پورت Trunk است.
• VLAN 20 روی آن Allow است.
• ترافیک VLAN 20 باید با تگ عبور کند.

یا ممکن است سناریو از ابتدا با هدف تفکیک ترافیک ماشین‌های مجازی بر اساس VLAN طراحی شده باشد:

• برای ماشین‌های مجازی مشخص، VLAN 20 تنظیم شود.
• برای ماشین‌های مجازی دیگر، VLAN 30 اختصاص داده شود.
• سایر ماشین‌های مجازی نیز در VLAN 40 قرار بگیرند.

منطق سناریو

وقتی پورت سوئیچ فیزیکی Trunk است، یعنی چند VLAN می‌تواند از آن عبور کند. برای اینکه سوئیچ بفهمد هر فریم متعلق به کدام VLAN است، فریم‌ها معمولاً با تگ VLAN فرستاده می‌شوند.

پس پورت فیزیکی سرور باید به صورت Trunk تنظیم شود و فقط VLANهای مورد نیاز را عبور دهد.

پروفایل‌های مورد نیاز

پروفایل Uplink فیزیکی (Trunk):

ویژگی	مقدار پیشنهادی
نام پروفایل	uplink-phys-trunk-multivlan
نوع پورت	فیزیکی
متصل به	کارت شبکه دوم سرور
سوئیچ OVS	Internal-Switch
حالت	Trunk
VLANهای مجاز	20, 30, 40
توضیحات	اتصال به پورت Trunk سوئیچ فیزیکی

پروفایل‌های VM (هر VLAN یک پروفایل):

📝 یادداشت

در خصوص پروفایل ماشین‌های مجازی، به ازای هر VLAN باید یک پروفایل مجزا ایجاد شود.

نام پروفایل	حالت	VLAN
vm-access-vlan20	Access	20
vm-access-vlan30	Access	30
vm-access-vlan40	Access	40

معماری سناریو برای درک بهتر:

جریان ترافیک

وقتی VM ترافیک می‌فرستد:

1. VM فریم بدون تگ می‌فرستد.
2. OVS فریم را به VLAN 20 نسبت می‌دهد.
3. OVS روی فریم تگ VLAN 20 قرار می‌دهد.
4. فریم تگ‌دار از پورت فیزیکی سرور خارج می‌شود.
5. سوئیچ فیزیکی تگ VLAN 20 را می‌خواند.
6. فریم وارد VLAN 20 سازمان می‌شود.

وقتی ترافیک برمی‌گردد:

1. سوئیچ فیزیکی فریم را با تگ VLAN 20 به سرور می‌فرستد.
2. پورت فیزیکی سرور آن را به OVS وارد می‌کند.
3. OVS تگ VLAN 20 را می‌خواند.
4. فریم را به پورت مجازی مربوط به VLAN 20 می‌فرستد.
5. OVS تگ را برمی‌دارد.
6. VM فریم بدون تگ دریافت می‌کند.

چه زمانی Frame با تگ VLAN از سوئیچ خارج می‌شود؟

ℹ️ دو شرط مهم برای ارسال Frame به‌صورت Tagged

1. Frame باید از یک پورت Access مربوط به همان VLAN وارد سوئیچ شده باشد.
2. پورت خروجی باید Trunk باشد و VLAN موردنظر نیز در لیست VLANهای Allowed آن پورت قرار داشته باشد.

بر اساس این منطق، در OVS نیز به دو نوع پروفایل نیاز داریم:

1. پروفایل Access VLAN: برای اتصال ماشین‌های مجازی یا کلاینت‌ها. وقتی ترافیک از سمت کلاینت وارد OVS می‌شود، OVS آن را در محیط داخلی خود متعلق به آن VLAN در نظر می‌گیرد.

2. پروفایل Trunk: برای اتصال OVS به شبکه بالادست و کارت شبکه فیزیکی. در این پروفایل، VLANهای موردنظر به‌عنوان Allowed VLAN مشخص می‌شوند.

نحوه IP دادن در این سناریو

🔴 نکته بسیار مهم

در صورتی که نیاز باشد روی این ارتباط Trunk یک IP تنظیم شود، نباید IP را مستقیماً روی کارت شبکه یا پروفایل Trunk که به کارت شبکه متصل است تنظیم کنید.

همان‌طور که در یک سوئیچ لایه ۳ برای اختصاص IP به یک VLAN از SVI استفاده می‌کنیم، در OVS نیز باید یک پروفایل Access با VLAN موردنظر ایجاد کرده و Internal IP را روی همان پروفایل تنظیم کنید.

در غیر این صورت، منطق VLAN موردنظر اعمال نمی‌شود و دو شرط لازم برای حفظ VLAN Tag برقرار نخواهد بود.

اگر چند VLAN نیاز باشد

مثلاً VLAN 20 و VLAN 30 و VLAN 40 نیاز باشد. در این حالت پروفایل Uplink باید Trunk باشد و این VLANها را Allow کند:

ویژگی	مقدار پیشنهادی
حالت	Trunk
VLANهای مجاز	20, 30, 40

سپس برای هر VLAN یک پروفایل Access جداگانه برای VMها می‌سازید:

پروفایل	VLAN
vm-web-access-vlan20	20
vm-db-access-vlan30	30
ct-app-access-vlan40	40

سناریو سوم: pfSense مجازی

شرح سناریو

در بسیاری از محیط‌ها نمی‌خواهیم ماشین‌های مجازی را مستقیم به شبکه فیزیکی وصل کنیم. دلایل:

• نیاز به فایروال بین VMها و شبکه فیزیکی
• نیاز به NAT
• نیاز به کنترل ترافیک
• نیاز به ایزوله‌سازی
• نیاز به DHCP داخلی ⭐
• نیاز به Routing بین شبکه‌ها
• نیاز به امنیت بیشتر

در این حالت یک pfSense مجازی ایجاد می‌کنیم. pfSense دو سمت دارد:

• سمت WAN: به شبکه فیزیکی وصل می‌شود.
• سمت LAN: به VMها و کانتینرهای داخلی وصل می‌شود.

منطق سناریو

در این معماری، VMها مستقیم به شبکه فیزیکی وصل نیستند. آن‌ها به یک شبکه داخلی پشت pfSense وصل می‌شوند.

• ترافیک VMها ابتدا به pfSense می‌رود.
• pfSense تصمیم می‌گیرد ترافیک عبور کند یا خیر.
• در صورت نیاز NAT انجام می‌شود.
• سپس ترافیک به شبکه فیزیکی می‌رود.

سوئیچ‌ها و پروفایل‌های مورد نیاز

در این سناریو به یک سوئیچ با نام Internal-FW-Switch به همراه دو پروفایل جدا نیاز داریم.

پروفایل WAN برای pfSense:

ویژگی	مقدار پیشنهادی
نام پروفایل	ovs-fw-wan-uplink
نوع پورت	مجازی برای pfSense
متصل به	کارت شبکه WAN در pfSense
سوئیچ OVS	ovs-fw-wan
حالت	Access یا Trunk (بسته به شبکه فیزیکی)
VLAN	طبق توافق با شبکه فیزیکی
توضیحات	اتصال WAN فایروال به شبکه فیزیکی

پروفایل LAN برای pfSense:

ویژگی	مقدار پیشنهادی
نام پروفایل	ovs-fw-lan
نوع پورت	مجازی برای pfSense
متصل به	کارت شبکه LAN در pfSense
سوئیچ OVS	ovs-fw-lan
حالت	Access
VLAN	با VLANهای انتخابی
توضیحات	اتصال LAN فایروال به شبکه داخلی VMها

💡 نکته

برای هر پروفایل ovs-fw-lan که ساخته می‌شود، یک VLAN متفاوت انتخاب کنید تا Broadcast Domain با پروفایل‌های دیگر و همچنین پروفایل Uplink جدا شود و از ازدحام شبکه جلوگیری شود.

پروفایل VMها و کانتینرها:

⚠️ هشدار

VMها و کانتینرها نباید به پروفایل WAN وصل شوند. آن‌ها باید به پروفایل LAN وصل شوند.

هر کدام از پروفایل‌های LAN باید VLAN متفاوتی داشته باشد:

نام پروفایل	حالت	VLAN
vm-servers-access-vlan20	Access	20
vm-mgmt-access-vlan30	Access	30
vm-dmz-access-vlan40	Access	40

تنظیمات IP

IP سمت WAN فایروال:

pfSense در سمت WAN باید IP ای در شبکه فیزیکی داشته باشد:

ویژگی	مقدار
Subnet	192.168.20.0/24
Gateway	192.168.20.1
WAN IP	192.168.20.10

💡 نکته

اگر شبکه فیزیکی DHCP بدهد، pfSense می‌تواند WAN را روی DHCP بگذارد.

IP سمت LAN فایروال:

سمت LAN معمولاً یک شبکه خصوصی جداگانه است:

ویژگی	مقدار
LAN Subnet	10.10.10.0/24
pfSense LAN IP	10.10.10.1
VM IP (مثال)	10.10.10.20
VM Gateway	10.10.10.1

💡 نکته

اگر pfSense DHCP Server داخلی داشته باشد، VMها می‌توانند IP را خودکار بگیرند.

حالت NAT یا Routing

حالت اول — NAT:

اگر IPهای سمت LAN خصوصی هستند و شبکه فیزیکی آن‌ها را نمی‌شناسد، pfSense معمولاً NAT انجام می‌دهد. VMها با IP داخلی خودشان ترافیک را می‌فرستند، اما pfSense آن را با IP سمت WAN به بیرون می‌فرستد.

این حالت وقتی رایج است که:

• شبکه VMها خصوصی است.
• شبکه بیرونی فقط به فایروال IP داده است.
• نمی‌خواهیم IP داخلی VMها در شبکه فیزیکی دیده شود.

حالت دوم — Routing بدون NAT:

اگر شبکه فیزیکی، شبکه پشت pfSense را می‌شناسد و route دارد، ممکن است NAT لازم نباشد:

شبکه	رنج
شبکه فیزیکی	192.168.20.0/24
شبکه VM	10.10.10.0/24

📝 یادداشت

اگر شبکه فیزیکی بداند که شبکه 10.10.10.0/24 پشت IP فایروال است، می‌تواند ترافیک را بدون NAT مسیریابی کند. این حالت بیشتر در محیط‌های سازمانی کنترل‌شده استفاده می‌شود.

اگر pfSense نیاز به VLAN داشته باشد

اگر شبکه فیزیکی چند VLAN به شما می‌دهد و می‌خواهید pfSense چند شبکه را مدیریت کند، می‌توانید پروفایل WAN را Trunk کنید:

ویژگی	مقدار پیشنهادی
حالت پروفایل WAN	Trunk
VLANهای مجاز	20, 30, 40

سپس داخل pfSense برای هر VLAN یک interface یا VLAN interface تعریف می‌کنید. در این حالت pfSense می‌تواند بین VLANها routing یا firewalling انجام دهد.

چرا این معماری درست است؟

• VMها مستقیم در معرض شبکه فیزیکی نیستند.
• کنترل ترافیک در pfSense انجام می‌شود.
• می‌توانید NAT، Firewall و DHCP داخلی داشته باشید.
• معماری قابل توسعه است.
• امنیت بیشتر می‌شود.
• می‌توانید شبکه داخلی را از شبکه کارفرما جدا کنید.

سناریو چهارم: اتصال مستقیم به فایروال کارفرما

شرح سناریو

گاهی پورت فیزیکی سرور مستقیم به یک فایروال فیزیکی کارفرما وصل است، نه به سوئیچ. در این حالت سوئیچ فیزیکی بین راه نیست، اما از نظر منطقی هنوز همان قواعد لایه ۲ برقرار است.

حالت‌های ممکن

حالت اول — فایروال پورت را بدون VLAN تحویل می‌دهد:

یعنی یک شبکه بدون تگ روی آن پورت وجود دارد. در این حالت پروفایل پورت فیزیکی سرور باید Access بدون تگ VLAN (VLAN 0) باشد.

حالت دوم — فایروال پورت را با تک VLAN تحویل می‌دهد:

در این حالت پروفایل پورت فیزیکی سرور باید Access آن VLAN باشد.

حالت سوم — فایروال پورت را مثل Trunk رفتار می‌دهد:

یعنی چند VLAN با تگ از آن پورت عبور می‌کنند. در این حالت پروفایل پورت فیزیکی سرور باید Trunk باشد و VLANهای مورد نیاز را Allow کند.

تنظیم IP

ℹ️ اطلاعات

• VM/Containerها باید از DHCP آن فایروال تغذیه شوند.
• اگر امکان DHCP نبود و Container استفاده می‌شود، باید pfSense مجازی راه‌اندازی شود.
• اگر VM استفاده می‌شود، به صورت دستی IP در رنج فایروال تنظیم شود.

چرا این سناریو فرق چندانی ندارد؟

💡 نکته

از نظر OVS مهم نیست طرف مقابل سوئیچ است یا فایروال. مهم این است که طرف مقابل:

• تگ می‌خواهد یا نه؟
• Access است یا Trunk؟
• کدام VLAN را قبول می‌کند؟
• IP و gateway چیست؟
• آیا DHCP دارد یا نه؟

بنابراین معماری OVS بر اساس رفتار لایه ۲ طرف مقابل تنظیم می‌شود.

سناریو پنجم: LACP و Link Aggregation

LACP چیست؟

LACP مخفف Link Aggregation Control Protocol است و یک پروتکل استاندارد مبتنی بر IEEE 802.3ad (که بعداً به IEEE 802.1AX منتقل شد) برای ترکیب چند لینک فیزیکی به یک لینک منطقی واحد است.

به زبان ساده، اگر سرور شما دو یا چند کارت شبکه فیزیکی دارد و می‌خواهید:

• پهنای باند بیشتری داشته باشید
• افزونگی (Redundancy) داشته باشید تا اگر یک لینک قطع شد، ترافیک از لینک دیگر عبور کند
• توزیع بار (Load Balancing) بین لینک‌ها انجام شود

از LACP استفاده می‌کنید.

ℹ️ اطلاعات

LACP یک پروتکل لایه ۲ است و در سطح فریم‌های اترنت کار می‌کند. هر دو طرف لینک (سرور و سوئیچ فیزیکی) باید از LACP پشتیبانی کنند و آن را فعال کرده باشند.

LACP دقیقاً چگونه کار می‌کند؟

LACP از طریق ارسال فریم‌های کنترلی به نام LACPDU (LACP Data Unit) بین دو طرف لینک کار می‌کند. فرآیند کلی به این صورت است:

مرحله ۱ — کشف و مذاکره:

هر طرف لینک (سرور و سوئیچ فیزیکی) فریم‌های LACPDU را روی هر پورت فیزیکی ارسال می‌کند. این فریم‌ها شامل اطلاعاتی مانند:

• System ID: شناسه یکتای دستگاه (معمولاً MAC Address + اولویت سیستم)
• Port ID: شناسه پورت فیزیکی
• Key: کلید تجمیع (پورت‌هایی که Key یکسان دارند می‌توانند در یک گروه قرار بگیرند)
• State: وضعیت فعلی پورت (Active، Passive، Timeout و ...)

مرحله ۲ — تشکیل گروه تجمیع:

وقتی دو طرف LACPDU یکدیگر را دریافت کردند و شرایط زیر برقرار بود، لینک‌ها در یک LAG (Link Aggregation Group) قرار می‌گیرند:

• سرعت پورت‌ها یکسان باشد
• حالت Duplex یکسان باشد
• Key یکسان باشد
• هر دو طرف LACP را قبول کرده باشند

مرحله ۳ — نگهداری و مانیتورینگ:

پس از تشکیل LAG، فریم‌های LACPDU به صورت دوره‌ای (هر ۱ ثانیه در حالت Fast یا هر ۳۰ ثانیه در حالت Slow) ارسال می‌شوند. اگر یک طرف فریم‌های LACPDU را دریافت نکند، آن لینک را از گروه خارج می‌کند.

⚠️ هشدار

اگر یک طرف LACP فعال باشد و طرف دیگر LACP نداشته باشد، لینک تجمیع تشکیل نمی‌شود و ترافیک ممکن است Drop شود یا فقط از یک لینک عبور کند.

حالت‌های LACP: Active و Passive

LACP دو حالت عملکردی دارد که نحوه آغاز مذاکره را مشخص می‌کند:

حالت	رفتار	آغازکننده مذاکره؟
Active	دستگاه خودش فریم‌های LACPDU را ارسال می‌کند و مذاکره را آغاز می‌کند.	✅ بله
Passive	دستگاه فقط منتظر دریافت LACPDU از طرف مقابل می‌ماند و در صورت دریافت، پاسخ می‌دهد.	❌ خیر

ترکیب‌های ممکن و نتیجه آن‌ها:

سمت سرور (OVS)	سمت سوئیچ فیزیکی	نتیجه
Active	Active	✅ LACP تشکیل می‌شود (هر دو طرف مذاکره را آغاز می‌کنند)
Active	Passive	✅ LACP تشکیل می‌شود (سرور آغازکننده است)
Passive	Active	✅ LACP تشکیل می‌شود (سوئیچ آغازکننده است)
Passive	Passive	❌ LACP تشکیل نمی‌شود (هیچ‌کدام مذاکره را آغاز نمی‌کنند)

🔴 خطر

اگر هر دو طرف Passive باشند، هیچ‌وقت LACP تشکیل نمی‌شود. حتماً حداقل یک طرف باید Active باشد.

💡 نکته

بهترین حالت این است که هر دو طرف Active باشند. این حالت سریع‌ترین زمان مذاکره و بالاترین پایداری را دارد.

تفاوت LACP با Static LAG

ویژگی	LACP (Dynamic)	Static LAG (Manual)
مذاکره خودکار	✅ بله	❌ خیر
تشخیص خرابی لینک	✅ بله (از طریق LACPDU)	❌ فقط اگر لینک فیزیکی قطع شود
تشخیص اتصال اشتباه	✅ بله	❌ خیر
استاندارد	IEEE 802.3ad / 802.1AX	وابسته به vendor
پیشنهاد استفاده	✅ توصیه می‌شود	⚠️ فقط در موارد خاص

⚠️ هشدار

در حالت Static LAG اگر یک کابل را به پورت اشتباه سوئیچ فیزیکی وصل کنید، سوئیچ متوجه نمی‌شود و ممکن است Loop ایجاد شود. اما در LACP چون مذاکره وجود دارد، این اشتباه تشخیص داده می‌شود.

الگوریتم‌های توزیع بار در LACP

وقتی چند لینک در یک LAG قرار می‌گیرند، سوئیچ و سرور باید تصمیم بگیرند هر فریم از کدام لینک ارسال شود. این تصمیم توسط الگوریتم Hashing گرفته می‌شود.

الگوریتم‌های رایج:

الگوریتم	بر اساس	توضیح
balance-slb	MAC مبدأ	توزیع بر اساس آدرس MAC فرستنده. ساده و سازگار با همه سوئیچ‌ها.
balance-tcp	IP + Port مبدأ و مقصد	توزیع دقیق‌تر بر اساس ترکیب IP و پورت TCP/UDP. نیاز به پشتیبانی سوئیچ دارد.
src-mac	MAC مبدأ	فقط بر اساس MAC مبدأ.
dst-mac	MAC مقصد	فقط بر اساس MAC مقصد.
src-dst-mac	MAC مبدأ + مقصد	ترکیب هر دو MAC.
src-dst-ip	IP مبدأ + مقصد	ترکیب هر دو IP.

💡 نکته

در OVS معمولاً از balance-slb یا balance-tcp استفاده می‌شود.

• balance-slb نیازی به پیکربندی خاص سمت سوئیچ ندارد و با هر سوئیچی کار می‌کند.
• balance-tcp عملکرد بهتری دارد اما حتماً نیاز به LACP فعال در هر دو طرف دارد.

شرح سناریو

یک سرور مجازی‌ساز داریم که دو کارت شبکه فیزیکی برای اتصال VMها و کانتینرها به شبکه فیزیکی دارد (مثلاً NIC2 و NIC3).

شبکه‌کارها می‌گویند:

ℹ️ پیام شبکه‌کارها

• دو پورت سوئیچ فیزیکی برای سرور شما تخصیص داده شده است.
• این دو پورت در یک Port-Channel یا LAG قرار دارند.
• حالت LACP Active روی سوئیچ فعال است.
• VLAN 20 و VLAN 30 روی این LAG به صورت Trunk تنظیم شده است.

معماری سناریو

در این معماری:

• دو کارت شبکه فیزیکی سرور (NIC2 و NIC3) وارد یک Bond در OVS می‌شوند.
• Bond به عنوان Uplink سوئیچ مجازی OVS عمل می‌کند.
• VMها و کانتینرها مثل سناریوهای قبلی به پروفایل‌های Access وصل می‌شوند.

نمونه پیکربندی سمت سوئیچ فیزیکی

برای اینکه LACP به درستی کار کند، سمت سوئیچ فیزیکی هم باید پیکربندی شده باشد.

نمونه برای سوئیچ Cisco:

interface range GigabitEthernet0/1 - 2
  channel-group 1 mode active
  switchport mode trunk
  switchport trunk allowed vlan 20,30

interface Port-channel1
  switchport mode trunk
  switchport trunk allowed vlan 20,30

نمونه برای سوئیچ MikroTik:

/interface bonding
add name=bond1 slaves=ether1,ether2 mode=802.3ad \
    lacp-rate=1sec transmit-hash-policy=layer3-and-4

/interface bridge port
add bridge=bridge1 interface=bond1

/interface bridge vlan
add bridge=bridge1 tagged=bond1 vlan-ids=20,30

نمونه برای سوئیچ Juniper (JunOS):

set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN20
set interfaces ae0 unit 0 family ethernet-switching vlan members VLAN30

set interfaces ge-0/0/0 ether-options 802.3ad ae0
set interfaces ge-0/0/1 ether-options 802.3ad ae0

📝 یادداشت

نمونه‌های بالا صرفاً الگوی کلی هستند. دستورات دقیق بسته به مدل و نسخه نرم‌افزار سوئیچ ممکن است تفاوت جزئی داشته باشد. حتماً مستندات vendor خود را بررسی کنید.

پروفایل‌های مورد نیاز

پروفایل Bond (Uplink):

ویژگی	مقدار پیشنهادی
نام	bond0
نوع	Bond (LACP)
اعضا	NIC2 + NIC3 (باید از بخش Physical port دو کارت شبکه به این پروفایل assign کنید)
سوئیچ OVS	ovs-lan
حالت LACP	Active
الگوریتم توزیع بار	balance-tcp
LACP Rate	Fast (هر ۱ ثانیه)
حالت Trunk/Access	Trunk
VLANهای مجاز	20, 30

پروفایل‌های VM:

نام پروفایل	حالت	VLAN
vm-web-access-vlan20	Access	20
vm-db-access-vlan30	Access	30

جریان ترافیک با LACP

وقتی VM ترافیک می‌فرستد:

1. VM فریم بدون تگ می‌فرستد.
2. OVS فریم را به VLAN 20 نسبت می‌دهد (بر اساس پروفایل Access).
3. OVS روی فریم تگ VLAN 20 قرار می‌دهد.
4. OVS بر اساس الگوریتم Hashing تصمیم می‌گیرد فریم از کدام لینک فیزیکی (eth1 یا eth2) ارسال شود.
5. فریم تگ‌دار از لینک انتخاب‌شده خارج می‌شود.
6. سوئیچ فیزیکی فریم را از طریق Port-Channel دریافت می‌کند.
7. سوئیچ فیزیکی تگ VLAN 20 را می‌خواند و فریم را وارد VLAN 20 سازمان می‌کند.

وقتی ترافیک برمی‌گردد:

1. سوئیچ فیزیکی فریم را با تگ VLAN 20 از طریق Port-Channel ارسال می‌کند.
2. سوئیچ فیزیکی بر اساس الگوریتم خودش، یکی از لینک‌ها را انتخاب می‌کند.
3. فریم وارد OVS می‌شود.
4. OVS تگ VLAN 20 را می‌خواند.
5. فریم را به پورت مجازی مربوط به VLAN 20 ارسال می‌کند.
6. OVS تگ را برمی‌دارد.
7. VM فریم بدون تگ دریافت می‌کند.

Failover — وقتی یک لینک قطع می‌شود

یکی از مهم‌ترین مزایای LACP، تشخیص خودکار خرابی لینک است.

سناریوی خرابی:

1. فرض کنید eth1 قطع می‌شود (کابل قطع، پورت سوئیچ خراب، یا ...).

2. OVS دیگر LACPDU از eth1 دریافت نمی‌کند.
3. بعد از ۳ بار عدم دریافت LACPDU (در حالت Fast یعنی بعد از ۳ ثانیه)، OVS آن لینک را غیرفعال اعلام می‌کند.
4. تمام ترافیک به‌صورت خودکار از eth2 عبور می‌کند.

5. وقتی eth1 دوباره فعال شود و LACPDU ارسال کند، OVS آن را مجدداً به Bond اضافه می‌کند.

💡 نکته

در حالت Fast LACP (lacp-time=fast)، تشخیص خرابی در حدود ۳ ثانیه انجام می‌شود. در حالت Slow LACP (lacp-time=slow)، این زمان حدود ۹۰ ثانیه است.

برای محیط‌های Production، حتماً از حالت Fast استفاده کنید.

نکات مهم و اشتباهات رایج

🔴 خطر — اشتباهات رایج

۱. عدم تطابق حالت LACP: اگر سمت OVS حالت active باشد ولی سمت سوئیچ اصلاً LACP فعال نباشد (حالت on یا Static)، LACP تشکیل نمی‌شود و ترافیک ممکن است Drop شود.

۲. عدم تطابق سرعت پورت‌ها: اگر یک پورت ۱Gbps و پورت دیگر ۱۰Gbps باشد، LACP آن‌ها را در یک گروه قرار نمی‌دهد.

۳. عدم تطابق VLANهای مجاز: اگر سمت OVS ویلن‌های 20 و 30 Allow شده باشد ولی سمت سوئیچ فقط VLAN 20 Allow باشد، ترافیک VLAN 30 Drop می‌شود.

۴. اتصال کابل‌ها به پورت‌های اشتباه: هر دو کابل باید به پورت‌هایی وصل شوند که در یک Port-Channel قرار دارند. اگر یک کابل به پورت آزاد دیگری وصل شود، LACP آن لینک را رد می‌کند.

🔒 امنیت

هرگز کابل‌های Bond را به سوئیچ‌های مختلف وصل نکنید مگر اینکه سوئیچ‌ها از MLAG (Multi-Chassis Link Aggregation) پشتیبانی کنند. در غیر این صورت LACP تشکیل نمی‌شود یا Loop ایجاد می‌شود.

تفاوت LACP با حالت Active-Backup

گاهی به جای LACP از حالت Active-Backup استفاده می‌شود. در این حالت فقط یک لینک فعال است و لینک دیگر فقط در صورت خرابی لینک اول فعال می‌شود.

ویژگی	LACP	Active-Backup
تعداد لینک‌های فعال	همه لینک‌ها همزمان فعال	فقط یک لینک فعال
افزایش پهنای باند	✅ بله	❌ خیر
افزونگی (Redundancy)	✅ بله	✅ بله
نیاز به پیکربندی سوئیچ	✅ بله (Port-Channel)	❌ خیر
پیچیدگی	متوسط	کم
پیشنهاد استفاده	محیط‌های Production با نیاز به پهنای باند بالا	محیط‌های ساده یا وقتی سوئیچ LAG پشتیبانی نمی‌کند

📝 یادداشت

در حالت Active-Backup نیازی به پیکربندی سمت سوئیچ نیست. سوئیچ فیزیکی هر پورت را به صورت مستقل می‌بیند و فقط لینک فعال ترافیک ارسال می‌کند.

چرا از LACP استفاده کنیم؟

• افزایش پهنای باند: دو لینک ۱Gbps در مجموع تا ۲Gbps ظرفیت خواهند داشت.
• افزونگی: اگر یک لینک قطع شود، ترافیک به‌صورت خودکار از لینک دیگر عبور می‌کند.
• تشخیص خرابی هوشمند: از طریق LACPDU، خرابی لینک در عرض ۳ ثانیه تشخیص داده می‌شود.
• تشخیص اتصال اشتباه: اگر کابل به پورت اشتباه وصل شود، LACP آن را رد می‌کند.
• استاندارد بودن: مبتنی بر استاندارد IEEE و با تمام vendorها سازگار است.
• ترکیب با Trunk: می‌توان LACP را با VLANهای Trunk ترکیب کرد.

خلاصه پیکربندی

مرحله	سمت سرور (OVS)	سمت سوئیچ فیزیکی
۱	ساخت سوئیچ مجازی (ovs-lan)	ساخت Port-Channel (LAG)
۲	ساخت Bond با lacp=active	فعال‌سازی LACP Active روی پورت‌ها
۳	تنظیم bond_mode=balance-tcp	تنظیم الگوریتم توزیع بار
۴	تنظیم Trunk و VLANهای مجاز روی Bond	تنظیم Trunk و VLANهای مجاز روی Port-Channel
۵	ساخت پروفایل Access برای VMها	—
۶	بررسی وضعیت با lacp/show	بررسی وضعیت با دستور مربوط به vendor

جمع‌بندی نهایی

Open vSwitch یک سوئیچ مجازی قدرتمند است که به شما امکان می‌دهد شبکه ماشین‌های مجازی و کانتینرها را به شکل استاندارد، قابل توسعه و قابل مدیریت به شبکه فیزیکی کارفرما متصل کنید.

🏢 نکات کلیدی

• ساخت سوئیچ OVS به تنهایی فقط یک سوئیچ خالی ایجاد می‌کند.
• رفتار شبکه با پروفایل‌ها مشخص می‌شود.
• پروفایل تعیین می‌کند که پورت Access باشد یا Trunk.
• اگر سوئیچ کارفرما Access است، پورت فیزیکی سرور هم باید Access باشد.
• اگر سوئیچ کارفرما Trunk است، پورت فیزیکی سرور باید Trunk باشد.
• اگر نیاز به امنیت، NAT یا کنترل ترافیک دارید، pfSense مجازی قرار دهید.
• پورت فیزیکی که به OVS داده شده معمولاً نباید IP مستقیم داشته باشد.
• نام‌گذاری استاندارد و مستندسازی برای مدیریت بلندمدت ضروری است.

چک‌لیست نهایی

آیا این موارد را درک کرده‌اید؟

• پورت فیزیکی باید Access باشد یا Trunk؟
• VM باید Access باشد یا Trunk؟
• آیا نیاز به pfSense است؟
• IP کجا قرار بگیرد؟
• VLANها چگونه به شبکه کارفرما وصل شوند؟
• LACP چگونه به حفظ پایداری کمک میکند
• چگونه امنیت و ایزولاسیون حفظ شود؟

✅ پایان مستند

اگر این معماری را درست درک کنید، در هر سناریویی می‌توانید تصمیم‌گیری درست انجام دهید. این دقیقاً همان چیزی است که برای طراحی استاندارد شبکه در زیرساخت مجازی‌سازی نیاز دارید.