Neutron در OpenStack چگونه کار می‌کند؟ از Network و Port تا عیب‌یابی ارتباط Instance

در این مقاله، موضوع «Neutron» را بررسی می‌کنیم. ساختن یک ماشین مجازی در OpenStack معمولاً قسمت سخت ماجرا نیست.

چالش واقعی خیلی وقت‌ها از جایی شروع می‌شود که Instance ساخته شده، وضعیت آن ACTIVE است، Console باز می‌شود و سیستم‌عامل هم کاملاً Boot شده، اما شبکه کار نمی‌کند.

ماشین IP دارد ولی Gateway را Ping نمی‌کند.

Gateway را Ping می‌کند ولی اینترنت ندارد.

Floating IP اختصاص داده شده ولی از بیرون قابل دسترسی نیست.

دو Instance روی یک Network همدیگر را نمی‌بینند.

DHCP کار نمی‌کند.

Metadata در دسترس نیست.

یا سناریوی آشناتر: Ping با Packet کوچک جواب می‌دهد، ولی بعضی Connectionها یا Packetهای بزرگ‌تر رفتار عجیبی دارند.

در Labهای OpenStack، مخصوصاً زمانی که با OVN/OVS و Overlay Network کار کردم، همین مشکلات باعث شدند متوجه شوم Troubleshooting شبکه در OpenStack با نگاه کردن به صفحه Networks در Horizon حل نمی‌شود.

برای پیدا کردن مشکل باید بتوانیم Packet را دنبال کنیم.

از داخل Guest شروع کنیم و بپرسیم:

این Packet برای رسیدن به مقصد دقیقاً از چه مسیرهایی عبور می‌کند؟

وقتی این سؤال را بتوانیم جواب بدهیم، Neutron از یکی از پیچیده‌ترین بخش‌های OpenStack به یکی از منطقی‌ترین بخش‌های آن تبدیل می‌شود.

---

Neutron دقیقاً چه کاری انجام می‌دهد؟

Neutron سرویس Networking در OpenStack است.

اما گفتن همین جمله تقریباً چیزی درباره معماری آن به ما نمی‌گوید.

وقتی یک Instance می‌سازیم، Nova مسئول Compute است، ولی ماشین برای ارتباط با بقیه محیط به Network Interface نیاز دارد.

اینجاست که Nova و Neutron با یکدیگر کار می‌کنند.

به شکل بسیار ساده:

Instance
   |
   v
Virtual NIC
   |
   v
Neutron Port
   |
   v
Network
   |
   v
Subnet

اگر ارتباط خارج از Network موردنیاز باشد، Router هم وارد مسیر می‌شود.

Instance
   |
   v
Port
   |
   v
Tenant / Project Network
   |
   v
Router
   |
   v
External Network
   |
   v
Physical Network

اما پشت همین دیاگرام ساده ممکن است OVS، OVN، Geneve/VXLAN، VLAN، Bridge، Physical NIC و Routing وجود داشته باشند.

بنابراین برای Troubleshooting باید ابتدا Objectهای منطقی Neutron را بفهمیم و بعد سراغ Data Plane برویم.

---

Network چیست؟

اولین Object اصلی Neutron، Network است.

برای مشاهده Networkها:

openstack network list

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

+--------------------------------------+--------------+
| ID                                   | Name         |
+--------------------------------------+--------------+
| ...                                  | internal-net |
| ...                                  | external-net |
+--------------------------------------+--------------+

اما Network را نباید صرفاً معادل یک Subnet IP در نظر گرفت.

Network بیشتر یک Broadcast Domain منطقی Layer 2 است.

Subnet بعداً IP addressing را روی آن تعریف می‌کند.

این تفاوت مهم است:

Network = Layer 2 logical connectivity

Subnet = Layer 3 addressing information

یک Network حتی می‌تواند بیش از یک Subnet داشته باشد.

---

Subnet چه چیزی به Network اضافه می‌کند؟

فرض کنیم Network داریم:

internal-net

و روی آن Subnet ایجاد می‌کنیم:

openstack subnet create \
  --network internal-net \
  --subnet-range 10.10.10.0/24 \
  internal-subnet

حالا Neutron اطلاعات Layer 3 را می‌داند.

مثلاً:

CIDR:       10.10.10.0/24
Gateway:    10.10.10.1
IP Version: IPv4

برای مشاهده:

openstack subnet list

و:

openstack subnet show internal-subnet

اینجا اطلاعاتی مثل:

cidr
gateway_ip
allocation_pools
dns_nameservers
enable_dhcp

برای Troubleshooting اهمیت پیدا می‌کنند.

مثلاً اگر Instance IP نگرفته، قبل از اینکه OVS را متهم کنیم باید ببینیم:

DHCP برای Subnet فعال است؟

---

Port؛ یکی از مهم‌ترین Objectهای Neutron

اگر بخواهم فقط یک Object را برای Troubleshooting شبکه OpenStack انتخاب کنم، Port یکی از مهم‌ترین‌هاست.

وقتی Instance به Network متصل می‌شود، Neutron برای آن Port دارد.

برای مشاهده:

openstack port list

برای یک Instance خاص:

openstack port list --server <INSTANCE-ID>

Port اطلاعات بسیار مهمی دارد:

MAC Address
Fixed IP
Network
Device ID
Device Owner
Status
Binding
Security Groups

در واقع Interface ماشین از دید Neutron همین Port است.

به همین دلیل اگر VM شبکه ندارد، یکی از اولین سؤال‌های من این است:

Port مربوط به این VM چه وضعیتی دارد؟

---

چرا Port برای Troubleshooting این‌قدر مهم است؟

فرض کنیم Instance در Nova وجود دارد.

openstack server show test-vm

همه‌چیز عادی به نظر می‌رسد.

ولی Network کار نمی‌کند.

حالا:

openstack port list --server test-vm

را اجرا می‌کنم.

بعد:

openstack port show <PORT-ID>

حالا می‌توانم ببینم:

آیا Fixed IP دارد؟

MAC Address چیست؟

Port روی Network صحیح است؟

Security Group چیست؟

Binding درست انجام شده؟

Status چیست؟

این اطلاعات نقطه اتصال Control Plane و Data Plane هستند.

---

Router چرا لازم است؟

دو Instance که روی یک Network هستند معمولاً برای ارتباط Layer 2 به Router نیاز ندارند.

اما اگر بخواهیم از یک Subnet به Network دیگری برویم، Routing لازم می‌شود.

Neutron Router این نقش را دارد.

مثلاً:

internal-net
10.10.10.0/24
      |
      |
   Router
      |
      |
external-net

برای مشاهده Routerها:

openstack router list

و:

openstack router show <ROUTER>

می‌توان Interface داخلی Router را به Subnet اضافه کرد:

openstack router add subnet router1 internal-subnet

و Gateway خارجی تعریف کرد:

openstack router set \
  --external-gateway external-net \
  router1

حالا مسیر North-South Traffic شکل می‌گیرد.

---

East-West و North-South Traffic

این دو اصطلاح در Troubleshooting Neutron خیلی کمک می‌کنند.

East-West

ترافیک بین Workloadهای داخل Cloud.

مثلاً:

VM1
 |
 | 10.10.10.0/24
 |
VM2

یا ارتباط بین Networkهای داخلی.

North-South

ترافیک بین Cloud و Network خارجی.

مثلاً:

VM
 |
Internal Network
 |
Router
 |
External Network
 |
Physical Network
 |
Internet / Datacenter LAN

این تفکیک بسیار مهم است.

اگر VM1 و VM2 همدیگر را Ping می‌کنند ولی External Network در دسترس نیست، احتمالاً نباید Troubleshooting را از Interface خود VM شروع کنیم.

بخش قابل‌توجهی از Packet Path داخلی سالم است.

حالا باید بیشتر روی Routing، External Connectivity و Provider Network تمرکز کنیم.

---

Provider Network؛ جایی که OpenStack به شبکه فیزیکی می‌رسد

یکی از مهم‌ترین قسمت‌های طراحی Neutron همین است.

بالاخره Packet باید از Virtual Network خارج شود و وارد Physical Network شود.

Provider Network این ارتباط را برقرار می‌کند.

Provider Network می‌تواند مثلاً:

Flat

یا:

VLAN

باشد.

فرض کنیم Physical Network ما:

physnet1

است.

یک Provider Network ممکن است به این Mapping متصل شود.

در این مرحله دیگر فقط OpenStack مطرح نیست.

Switch فیزیکی هم اهمیت پیدا می‌کند.

VLAN Configuration اهمیت پیدا می‌کند.

NIC سرور اهمیت پیدا می‌کند.

Bridge Mapping اهمیت پیدا می‌کند.

یعنی ممکن است Configuration داخل OpenStack کاملاً درست باشد، ولی Switch Port اشتباه Config شده باشد.

---

تجربه‌ای که با External Interface داشتم

در Kolla-Ansible یکی از تنظیماتی که برای Neutron اهمیت پیدا کرد:

neutron_external_interface

بود.

در نگاه اول فقط نام یک Interface است.

اما این Interface در واقع یکی از نقاط اتصال Cloud به Physical Network است.

اگر Interface اشتباه انتخاب شود، ممکن است Control Plane کاملاً سالم باشد.

Horizon باز شود.

Instance ساخته شود.

Internal Network حتی کار کند.

ولی External Connectivity نداشته باشیم.

این مثال خوبی است از اینکه:

سلامت OpenStack API هیچ تضمینی برای سلامت Data Plane نیست.

---

Floating IP دقیقاً چیست؟

یکی از برداشت‌های رایج این است که Floating IP یک IP دوم است که مستقیماً داخل Guest قرار می‌گیرد.

معمولاً این‌طور نیست.

Guest ممکن است فقط Fixed IP خودش را داشته باشد.

مثلاً:

10.10.10.25

بعد Floating IP:

192.168.100.50

به آن Associate می‌شود.

برای ساخت:

openstack floating ip create external-net

برای اتصال:

openstack server add floating ip \
  test-vm \
  192.168.100.50

از دید Guest ممکن است همچنان فقط:

10.10.10.25

وجود داشته باشد.

Translation و Routing در Infrastructure شبکه OpenStack انجام می‌شود.

پس اگر Floating IP Ping نمی‌شود، لزوماً نباید دنبال آن IP داخل ip addr ماشین بگردیم.

---

Security Group؛ Firewall را فراموش نکنیم

یکی از رایج‌ترین مشکلات:

«Floating IP دارم ولی Ping نمی‌شود.»

یا:

«SSH کار نمی‌کند.»

قبل از اینکه سراغ OVN Database برویم، Security Group را بررسی می‌کنم.

مثلاً:

openstack security group list

و:

openstack security group rule list <SECURITY-GROUP>

ممکن است ICMP اصلاً Allow نشده باشد.

برای مثال:

openstack security group rule create \
  --protocol icmp \
  default

برای SSH:

openstack security group rule create \
  --protocol tcp \
  --dst-port 22 \
  default

اگر Packet توسط Policy عمداً Block شده، دستکاری OVS Bridge فقط Troubleshooting را پیچیده‌تر می‌کند.

---

اما Security Group تنها Firewall نیست

در معماری شبکه OpenStack باید بدانیم Driver مورد استفاده چگونه Security Group را پیاده‌سازی می‌کند.

در محیط‌های OVN رفتار Data Plane با معماری قدیمی‌تر مبتنی بر Agentهای سنتی یکسان نیست.

به همین دلیل قبل از استفاده از Commandهای Troubleshooting یک مقاله اینترنتی باید بدانیم:

Deployment من ML2/OVS است یا ML2/OVN؟

این سؤال خیلی مهم است.

چون دو محیط ممکن است از دید Horizon کاملاً شبیه باشند ولی Backend Networking متفاوتی داشته باشند.

---

ML2 چیست؟

در Neutron زیاد با عبارت:

ML2

مواجه می‌شویم.

ML2 مخفف:

Modular Layer 2

است.

هدفش این است که Neutron بتواند Backendهای مختلف Networking را از طریق Mechanism Driverها پشتیبانی کند.

مثلاً:

ML2/OVS

یا:

ML2/OVN

در Labهای من تمرکز اصلی روی:

ML2/OVN

بود.

این انتخاب روی معماری Data Plane و روش Troubleshooting اثر مستقیم دارد.

---

OVS و OVN یک چیز نیستند

این یکی از مفاهیمی است که قبل از مقاله بعدی باید روشن باشد.

Open vSwitch یا OVS یک Virtual Switch است.

اما:

OVN یا Open Virtual Network یک سیستم Network Virtualization بالاتر از OVS است.

خیلی ساده:

Neutron
   |
   v
OVN
   |
   v
OVS
   |
   v
Linux / NIC

البته معماری واقعی جزئیات بیشتری دارد.

OVN دارای Northbound و Southbound Database و Componentهای دیگری است که در مقاله اختصاصی OVN باز می‌کنیم.

فعلاً مهم است بدانیم:

OVS همان OVN نیست.

---

اولین برخورد جدی من با Packet Path

در Troubleshootingهای اولیه، وقتی Instance شبکه نداشت، وسوسه طبیعی این بود که چند سرویس را Restart کنم.

ولی خیلی زود مشخص شد این روش مقیاس‌پذیر نیست.

روش بهتر این بود که Packet را مرحله‌به‌مرحله دنبال کنم.

مثلاً:

Guest
 ↓
Virtual NIC
 ↓
Neutron Port
 ↓
OVS
 ↓
Overlay / Local Switching
 ↓
Router
 ↓
External Network
 ↓
Physical NIC
 ↓
Physical Switch

حالا به جای سؤال کلی:

«چرا شبکه کار نمی‌کند؟»

می‌توانیم بپرسیم:

«آخرین نقطه‌ای که Packet را می‌بینم کجاست؟»

این سؤال Troubleshooting شبکه را کاملاً تغییر می‌دهد.

---

از داخل Guest شروع می‌کنم

فرض کنیم VM اینترنت ندارد.

اول از خود Guest شروع می‌کنم.

در Linux:

ip addr

آیا Interface وجود دارد؟

IP گرفته؟

بعد:

ip route

آیا Default Route داریم؟

بعد:

ping <GATEWAY-IP>

اگر Gateway هم Ping نمی‌شود، هنوز رفتن سراغ اینترنت بی‌معنی است.

بعد:

ip neigh

را بررسی می‌کنم.

آیا MAC مربوط به Gateway Resolve شده؟

این اطلاعات مشخص می‌کنند Failure چقدر به Guest نزدیک است.

---

اگر Guest IP ندارد

اگر DHCP انتظار داریم ولی IP نداریم، مسیر Investigation عوض می‌شود.

ابتدا:

openstack port list --server <INSTANCE-ID>

آیا Neutron Fixed IP برای Port رزرو کرده؟

اگر Neutron می‌گوید:

fixed_ips = 10.10.10.25

ولی Guest IP ندارد، مسئله جالب‌تر می‌شود.

Control Plane IP را تخصیص داده، ولی Guest آن را دریافت نکرده.

حالا باید DHCP Path، Interface داخل Guest، Driver و Backend Network را بررسی کنیم.

این تفاوت مهم است:

IP Allocation در Neutron با IP Configuration داخل Guest یک چیز نیست.

---

MTU؛ مشکلی که می‌تواند خیلی گمراه‌کننده باشد

یکی از مشکلات واقعی که در Lab با آن درگیر شدم MTU بود.

وقتی Overlay Network داریم، Packet اصلی داخل Headerهای دیگری Encapsulate می‌شود.

یعنی Underlay باید فضای لازم برای Header اضافه را داشته باشد.

فرض کنیم Physical Network MTU برابر:

1500

است.

اگر Guest هم بدون درنظر گرفتن Overlay با MTU نامناسب Packet ارسال کند، ممکن است Packetهای بزرگ‌تر دچار مشکل شوند.

در Lab برای رسیدن به Connectivity پایدارتر، MTU را روی:

1400

تنظیم کردم.

این تجربه باعث شد MTU را یکی از Checkهای اصلی مشکلات عجیب Network قرار دهم.

---

چرا MTU Problem گمراه‌کننده است؟

چون شبکه الزاماً کاملاً Down نمی‌شود.

ممکن است:

Ping کوچک کار کند.

SSH Connect شود.

ولی Transfer بزرگ Fail شود.

بعضی HTTPS Connectionها Hang کنند.

Packetهای خاص Drop شوند.

در نتیجه Administrator می‌گوید:

«شبکه که کار می‌کند؛ پس مشکل MTU نیست.»

در حالی که Partial Connectivity دقیقاً می‌تواند یکی از نشانه‌های MTU Problem باشد.

---

چطور MTU را تست می‌کنم؟

روی Linux می‌توان از Ping با Don't Fragment استفاده کرد.

مثلاً:

ping -M do -s 1472 <DESTINATION>

عدد دقیق قابل استفاده به Headerها و Path بستگی دارد.

اگر Packet بزرگ Fail شود ولی Packet کوچک کار کند، MTU یکی از فرضیه‌های جدی می‌شود.

بعد:

ip link

MTU Interfaceها را بررسی می‌کنم.

اما فقط Guest مهم نیست.

باید مسیر را ببینیم:

Guest MTU
   ↓
Virtual Port
   ↓
OVS
   ↓
Tunnel
   ↓
Physical NIC
   ↓
Physical Network

کوچک‌ترین MTU مؤثر در Path می‌تواند تعیین‌کننده باشد.

---

Overlay Network یعنی چه؟

در Cloud نمی‌خواهیم برای هر Project الزاماً یک VLAN فیزیکی جدا در تمام Datacenter ایجاد کنیم.

Overlay Networking اجازه می‌دهد Networkهای منطقی را روی یک Underlay IP Network حمل کنیم.

پروتکل‌هایی مثل VXLAN یا Geneve برای این کار استفاده می‌شوند.

به شکل ساده:

Tenant Packet
     |
     v
Encapsulation
     |
     v
Physical IP Network
     |
     v
Decapsulation
     |
     v
Destination VM

در نتیجه دو VM روی دو Compute مختلف می‌توانند تصور کنند روی یک Network منطقی هستند، در حالی که Traffic بین Computeها از Underlay عبور می‌کند.

---

Overlay و Underlay را از هم جدا می‌کنم

این تفکیک در Troubleshooting بسیار مهم است.

Underlay

شبکه واقعی بین Nodeها.

مثلاً:

Compute01
192.168.11.21

Compute02
192.168.11.22

این Nodeها باید در شبکه فیزیکی به هم دسترسی داشته باشند.

Overlay

Network منطقی Tenant.

مثلاً:

10.10.10.0/24

اگر Underlay مشکل داشته باشد، Overlay هم نمی‌تواند معجزه کند.

بنابراین اگر VMهای روی یک Compute با هم ارتباط دارند ولی VMهای روی دو Compute مختلف ندارند، Underlay/Tunnel Path یکی از نقاط مهم Investigation است.

---

ovs-vsctl show چه چیزی به من می‌دهد؟

در محیط OVS یکی از Commandهای پایه:

ovs-vsctl show

است.

این Command Structure کلی OVS را نشان می‌دهد:

Bridgeها

Portها

Interfaceها

Controller

و اطلاعات مرتبط.

ولی یک اشتباه رایج این است که Output را بگیریم و فقط نگاه کنیم که «خیلی چیزها وجود دارد».

Command زمانی مفید است که سؤال مشخص داشته باشیم.

مثلاً:

آیا Interface مورد انتظار روی Bridge وجود دارد؟

یا:

Bridge Mapping چیزی است که انتظار دارم؟

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

---

Control Plane و Data Plane را جدا می‌کنم

این یکی از مهم‌ترین مفاهیم Troubleshooting Neutron است.

Control Plane

تعریف می‌کند چه چیزی باید وجود داشته باشد.

مثلاً:

Network
Subnet
Port
Router
Floating IP
Security Group

Data Plane

Packet واقعاً از کجا عبور می‌کند.

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

Port ACTIVE
Floating IP Associated
Router Connected

اما Packet در Data Plane به مقصد نرسد.

بنابراین همیشه دو سؤال دارم:

Configuration منطقی درست است؟

و:

Packet واقعاً حرکت می‌کند؟

این دو سؤال الزاماً جواب یکسان ندارند.

---

tcpdump؛ وقتی می‌خواهم حدس زدن را متوقف کنم

یکی از مفیدترین ابزارهای Troubleshooting شبکه هنوز همان ابزار قدیمی Linux است:

tcpdump

فرض کنیم Ping از VM خارج می‌شود ولی جواب نمی‌رسد.

اگر بتوانیم Packet را روی نقاط مختلف Path Capture کنیم، محل Failure کوچک‌تر می‌شود.

مثلاً:

tcpdump -ni <INTERFACE> icmp

اگر Packet روی Interface اول دیده می‌شود ولی روی Interface بعدی نه، حالا یک Boundary داریم.

این بسیار ارزشمندتر از Restart کردن سرویس است.

---

سناریو: VM به Gateway دسترسی ندارد

مسیر من تقریباً این است.

اول داخل VM:

ip addr
ip route
ip neigh

بعد:

ping <GATEWAY>

در Control Plane:

openstack port list --server <INSTANCE>

بعد:

openstack port show <PORT-ID>

Subnet:

openstack subnet show <SUBNET>

Router:

openstack router show <ROUTER>

بعد Data Plane.

OVS/OVN و Packet Capture.

این ترتیب مهم است.

من از Database OVN شروع نمی‌کنم وقتی هنوز نمی‌دانم Guest Default Route دارد یا نه.

---

سناریو: Gateway Ping می‌شود ولی اینترنت نداریم

اینجا اطلاعات مهمی داریم.

Guest Interface احتمالاً کار می‌کند.

Fixed IP داریم.

بخش داخلی Network تا Gateway کار می‌کند.

پس Investigation را جلوتر می‌برم.

External Gateway؟

Provider Network؟

SNAT؟

Physical Interface؟

Default Route روی Infrastructure؟

Switch/VLAN؟

Upstream Router؟

این همان مزیت Packet Path Thinking است.

هر Test بخشی از مسیر را تأیید یا رد می‌کند.

---

سناریو: Floating IP کار نمی‌کند

اول:

openstack floating ip list

آیا Floating IP واقعاً به Port صحیح متصل است؟

بعد:

openstack port list --server <INSTANCE>

Security Group؟

Router External Gateway؟

External Network؟

Provider Network؟

Physical Connectivity؟

و بعد Data Plane.

اگر داخل Guest سرویس روی Port 22 Listen نمی‌کند، حتی سالم‌ترین Neutron دنیا هم SSH ایجاد نمی‌کند.

پس Guest Service را هم فراموش نمی‌کنم.

---

سناریو: VMهای یک Network فقط روی یک Compute با هم ارتباط دارند

این سناریو برای من بلافاصله سؤال ایجاد می‌کند:

آیا مشکل Cross-Compute است؟

اگر VM1 و VM2 روی Compute01 ارتباط دارند، ولی VM3 روی Compute02 قابل دسترسی نیست، احتمالاً بخشی از Local Switching سالم است.

حالا بیشتر به مواردی مثل:

Tunnel Connectivity
Underlay
OVS
OVN Chassis
MTU
Firewall
Encapsulation

فکر می‌کنم.

این مثال خوبی است که چرا محل قرارگیری Instanceها در Troubleshooting Network اهمیت دارد.

---

DNS را با Network Connectivity اشتباه نمی‌گیرم

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

«اینترنت ندارم.»

اما:

ping 8.8.8.8

کار می‌کند.

در حالی که:

ping example.com

Fail می‌شود.

این دیگر لزوماً Routing Problem نیست.

DNS را بررسی می‌کنیم.

مثلاً:

cat /etc/resolv.conf

یا ابزارهای Resolver سیستم‌عامل.

در Subnet هم:

openstack subnet show <SUBNET>

و DNS Nameserverهای Config شده را می‌بینیم.

قبل از Troubleshooting پیچیده Neutron، باید مشخص کنیم Failure واقعاً Network Connectivity است یا Name Resolution.

---

Metadata؛ شبکه‌ای که شاید دیده نشود ولی مهم است

Instanceها معمولاً برای دریافت Metadata به سرویس Metadata نیاز دارند.

Cloud-init و ابزارهای مشابه می‌توانند از Metadata برای دریافت اطلاعاتی مثل:

Hostname

SSH Key

User Data

Configuration

استفاده کنند.

بنابراین ممکن است Network عمومی VM کار کند ولی Metadata Path مشکل داشته باشد.

در چنین حالتی VM Boot می‌شود اما Initial Configuration مورد انتظار انجام نمی‌شود.

این نوع Failure نشان می‌دهد «Network Working» خودش چند معنی مختلف دارد.

---

در OVN معماری کمی متفاوت می‌شود

در Deploymentهای ML2/OVN بسیاری از Functionهای Networking توسط OVN پیاده‌سازی می‌شوند.

Northbound Database وضعیت منطقی Network را نگه می‌دارد.

Southbound Database اطلاعات موردنیاز برای پیاده‌سازی آن روی Chassisها را نگه می‌دارد.

ovn-controller روی Nodeها State موردنیاز را به OVS منتقل می‌کند.

به شکل بسیار ساده:

Neutron
   |
   v
OVN Northbound DB
   |
   v
ovn-northd
   |
   v
OVN Southbound DB
   |
   v
ovn-controller
   |
   v
Open vSwitch
   |
   v
Packets

این دقیقاً موضوع مقاله بعدی ما خواهد بود.

---

چرا مستقیم سراغ ovn-nbctl و ovn-sbctl نمی‌روم؟

چون اول باید بدانم دنبال چه چیزی هستم.

اگر Neutron Port را نمی‌شناسم، دیدن صدها Logical Switch Port در OVN کمکی نمی‌کند.

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

OpenStack Object
       ↓
Neutron Port
       ↓
Logical Network State
       ↓
OVN
       ↓
OVS
       ↓
Linux Interface
       ↓
Physical Network

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

---

Troubleshooting Layered برای Neutron

برای اینکه بین ده‌ها Component گم نشوم، شبکه را به Layerهای مشخص تقسیم می‌کنم.

لایه اول: Guest

NIC
IP
Route
DNS
Driver
Firewall

لایه دوم: Neutron Objects

Network
Subnet
Port
Router
Floating IP
Security Group

لایه سوم: SDN

ML2
OVN
OVS
Logical Ports
Flows

لایه چهارم: Transport

Overlay
Tunnel
MTU
Underlay IP

لایه پنجم: Physical Network

NIC
Bond
VLAN
Switch
Router
Firewall
Upstream

این مدل برای من از حفظ کردن تعداد زیادی Command کاربردی‌تر است.

---

Checklist عملی من برای VM بدون Network

اگر یک Instance ACTIVE باشد ولی Network نداشته باشد، مسیر اولیه من تقریباً این است.

داخل Guest

ip addr
ip route
ip neigh

وضعیت Instance

openstack server show <INSTANCE-ID>

Port

openstack port list --server <INSTANCE-ID>

openstack port show <PORT-ID>

Network

openstack network show <NETWORK>

Subnet

openstack subnet show <SUBNET>

Router

openstack router show <ROUTER>

Security Group

openstack security group rule list <SECURITY-GROUP>

Floating IP

openstack floating ip list

بعد از اینکه Control Plane را فهمیدم، وارد Backend می‌شوم.

در محیط OVS:

ovs-vsctl show

و اگر لازم باشد Packet Capture:

tcpdump -ni <INTERFACE>

و بعد OVN.

نه برعکس.

---

چیزی که MTU در Lab به من یاد داد

یکی از مفیدترین درس‌های کار عملی با شبکه OpenStack برای من این بود که:

Up بودن Interface به معنی سالم بودن Network Path نیست.

ممکن است:

Port Active باشد.

IP داشته باشیم.

Gateway در بعضی شرایط پاسخ دهد.

ولی Application درست کار نکند.

مشکلی مثل MTU دقیقاً همین نوع رفتار را ایجاد می‌کند.

به همین دلیل در Troubleshooting Network سعی می‌کنم فقط Boolean فکر نکنم:

Network Works
Network Doesn't Work

بلکه سؤال می‌کنم:

کدام Packet؟
با چه Size؟
از چه Source؟
به چه Destination؟
روی کدام Protocol؟
تا کدام Hop؟

این سؤال‌ها Network Troubleshooting را بسیار دقیق‌تر می‌کنند.

---

Neutron در Production فقط Network و Subnet نیست

وقتی از Lab فاصله می‌گیریم، موضوعات دیگری هم وارد طراحی می‌شوند:

Provider Networks

VLAN

Overlay Networks

HA Routing

Multiple External Networks

IPv6

QoS

SR-IOV

DPDK

BGP

Network Availability Zones

Trunk Ports

RBAC

Port Security

DNS Integration

Metadata

Routed Provider Networks

هرکدام از این موارد می‌توانند روی Architecture و Performance اثر جدی بگذارند.

بنابراین مقاله فعلی را پایه Neutron می‌دانم، نه پایان آن.

---

یک تغییر مهم در Neutron 2026.1

در نسخه‌های جدید باید به تغییر نام بعضی Optionها هم توجه کنیم.

در Neutron 2026.1 گزینه قدیمی:

tenant_network_types

Deprecated شده و:

project_network_types

جایگزین آن شده است.

نام قدیمی فعلاً کار می‌کند، اما برای حذف در نسخه آینده برنامه‌ریزی شده است.

این تغییر کوچک به نظر می‌رسد، ولی در Environmentهای Production و مخصوصاً هنگام Upgrade مهم است.

Configuration قدیمی ممکن است امروز کار کند، اما نباید بدون بررسی Release Notes فرض کنیم برای همیشه معتبر می‌ماند.

---

چرا Release Note شبکه مهم‌تر از چیزی است که به نظر می‌رسد؟

Network یکی از حساس‌ترین بخش‌های Infrastructure است.

در Compute اگر یک Host مشکل داشته باشد ممکن است فقط Workloadهای همان Host تحت تأثیر قرار بگیرند.

ولی یک تغییر اشتباه در Network Configuration می‌تواند تعداد زیادی Workload را همزمان تحت تأثیر قرار دهد.

برای مثال در Neutron 2026.1 رفتار Validation مربوط به VLAN Rangeها سخت‌گیرانه‌تر شده است.

اگر VLAN IDهایی که Network Segmentهای موجود استفاده می‌کنند دیگر در network_vlan_ranges پوشش داده نشوند، Neutron می‌تواند از Start شدن خودداری کند و VLAN/Physical Network مشکل‌دار را مشخص کند.

از نظر من این نوع تغییر دقیقاً چیزی است که Operator قبل از Upgrade باید بداند.

---

چیزی که Neutron به من یاد داد

در Troubleshooting Compute معمولاً دنبال State هستیم.

ولی در Troubleshooting Network باید علاوه بر State، Path را هم بفهمیم.

یک Port می‌تواند وجود داشته باشد.

Router می‌تواند وجود داشته باشد.

Floating IP می‌تواند Associate شده باشد.

Security Group هم صحیح باشد.

ولی در نهایت چیزی که اهمیت دارد این است:

آیا Packet واقعاً از Source به Destination می‌رسد؟

برای همین امروز وقتی یک Instance شبکه ندارد، اولین واکنش من Restart کردن Neutron نیست.

یک Packet را انتخاب می‌کنم.

مثلاً:

VM → Gateway

بعد مسیرش را دنبال می‌کنم.

اگر این مسیر سالم بود:

VM → External Gateway

بعد:

VM → Upstream

و همین‌طور جلو می‌روم.

هر مرحله بخشی از Infrastructure را تأیید می‌کند.

به نظرم این مهم‌ترین تغییری است که کار عملی با Neutron در روش Troubleshooting من ایجاد کرد:

به جای اینکه دنبال سرویس خراب بگردم، دنبال نقطه‌ای می‌گردم که Packet دیگر از آن عبور نمی‌کند.

وقتی آن نقطه پیدا شود، تازه Commandها، Logها و Componentهای Neutron معنی واقعی پیدا می‌کنند.