ovs-vswitchd(8) راهنمای Open vSwitch ovs-vswitchd(8)

ovs-vswitchd - دیمن Open vSwitch

ovs-vswitchd [database]

دیمنی که هر تعداد سوئیچ Open vSwitch را بر روی سیستم محلی مدیریت و کنترل می‌کند.

آرگومان database چگونگی اتصال ovs-vswitchd به ovsdb-server را مشخص می‌کند. database ممکن است یک روش اتصال فعال (active) یا غیرفعال (passive) در OVSDB باشد، همان‌طور که در ovsdb(7) شرح داده شده است. مقدار پیش‌فرض برابر unix:/run/openvswitch/db.sock است.

دیمن ovs-vswitchd پیکربندی خود را هنگام راه‌اندازی از database دریافت می‌کند. این برنامه مسیرهای داده (datapaths) مربوط به Open vSwitch را برپا کرده و سپس عملیات سوئیچینگ را روی هر پل توصیف‌شده در فایل‌های پیکربندی اجرا می‌کند. همگام با تغییر پایگاه‌داده، ovs-vswitchd به طور خودکار پیکربندی خود را به‌روزرسانی می‌کند تا منطبق باقی بماند.

سوئیچ‌های ovs-vswitchd می‌توانند با هر یک از ویژگی‌های زیر پیکربندی شوند:

  • سوئیچینگ لایه L2 همراه با یادگیری آدرس MAC.
  • پیوند کارت‌های شبکه (NIC bonding) همراه با تغییر مسیر خودکار هنگام خرابی (fail-over) و متعادل‌سازی بار ارسال ترافیک (TX) بر اساس آدرس MAC مبدأ ("SLB").
  • پشتیبانی از 802.1Q VLAN.
  • آینه‌سازی درگاه (Port mirroring)، همراه با برچسب‌گذاری اختیاری VLAN.
  • ثبت وقایع جریان با NetFlow v5.
  • پایش ترافیک با sFlow(R).
  • قابلیت اتصال به کنترل‌کننده خارجی OpenFlow، مانند NOX.

در هر زمان تنها اجرای یک نمونه از ovs-vswitchd در نظر گرفته شده است. یک نمونه از ovs-vswitchd می‌تواند هر تعداد نمونه سوئیچ را، تا حداکثر تعداد مجاز مسیرهای داده پشتیبانی‌شده در Open vSwitch، مدیریت نماید.

برنامه ovs-vswitchd تمام مدیریت‌های لازم بر مسیرهای داده Open vSwitch را خودش انجام می‌دهد. بنابراین، ovs-dpctl(8) (و معادل‌های مسیر داده در فضای کاربری آن که از طریق ovs-appctl dpctl/command در دسترس هستند) در کنار ovs-vswitchd مورد نیاز نبوده و نباید استفاده شوند، زیرا می‌توانند در عملکرد آن تداخل ایجاد کنند. با این وجود، این ابزارها همچنان برای عیب‌یابی کاربرد دارند.

برای اینکه ovs-vswitchd کارایی داشته باشد، ماژول هسته مسیر داده Open vSwitch باید بارگذاری شده باشد. جهت مشاهده دستورالعمل‌های ساخت و بارگذاری ماژول هسته Open vSwitch، به مستندات آن مراجعه فرمایید.

باعث می‌شود ovs-vswitchd تابع mlockall() را فراخوانی کند تا تلاش نماید تمام حافظه فرآیند خود را هنگام وقوع نقص صفحه (page fault) در رم فیزیکی قفل کند (هنگام تخصیص حافظه در هسته لینوکس 4.4 یا قدیمی‌تر)، که مانع از انتقال حافظه توسط هسته به دیسک (paging) می‌شود. این کار به جلوگیری از وقفه در شبکه ناشی از فشار روی حافظه سیستم کمک می‌کند.
برخی سیستم‌ها اصلاً از mlockall() پشتیبانی نمی‌کنند، و برخی سیستم‌های دیگر تنها به کاربران ممتاز مانند مدیر ارشد (superuser) اجازه استفاده از آن را می‌دهند. در صورت در دسترس نبودن یا ناموفق بودن mlockall()، برنامه ovs-vswitchd یک پیام لاگ صادر می‌کند.

برای جزئیات مربوط به مقداردهی اولیه ovs-vswitchd جهت استفاده از درگاه‌های DPDK، به مستندات یا ovs-vswitchd.conf.db(5) مراجعه کنید.

به ovs-vswitchd می‌گوید که قابلیت CAP_SYS_RAWIO را حفظ کند تا به درایورهای فضای کاربری اجازه دسترسی مستقیم به حافظه سخت‌افزاری را بدهد. این کار همچنین به دیمن ovs-vswitchd اجازه می‌دهد تا توابع iopl() و ioperm() را فراخوانی کرده و به دستگاه‌های حافظه برای تنظیم دسترسی درگاه دست یابد. این یک قابلیت بسیار قدرتمند است، بنابراین عموماً فقط بر حسب نیاز برای سخت‌افزارهای خاص (به عنوان مثال mlx5 با بارگذاری کامل سخت‌افزاری از طریق rte_flow) فعال شود.

گزینه‌های زیر روی پلتفرم‌های مبتنی بر POSIX معتبر هستند.

باعث می‌شود فایلی (به طور پیش‌فرض ovs-vswitchd.pid) ایجاد شود که نشان‌دهنده PID فرآیند در حال اجرا است. اگر آرگومان pidfile مشخص نشده باشد، یا اگر با / آغاز نشود، در مسیر /run/openvswitch ایجاد می‌شود.
اگر --pidfile مشخص نشود، هیچ فایل پی‌آی‌دی ایجاد نمی‌شود.
به طور پیش‌فرض، هنگامی که --pidfile مشخص شده باشد و فایل pidfile مشخص‌شده از قبل وجود داشته و توسط یک فرآیند در حال اجرا قفل شده باشد، ovs-vswitchd از شروع به کار خودداری می‌کند. مشخص کردن --overwrite-pidfile باعث می‌شود تا به جای آن روی pidfile بازنویسی شود.
هنگامی که --pidfile مشخص نشده باشد، این گزینه هیچ اثری ندارد.
برنامه ovs-vswitchd را به عنوان یک فرآیند پس‌زمینه اجرا می‌کند. فرآیند فورک می‌شود، و در فرآیند فرزند یک نشست جدید آغاز می‌کند، توصیف‌کننده‌های استاندارد فایل را می‌بندد (که اثر جانبی آن غیرفعال شدن ثبت وقایع در کنسول است)، و دایرکتوری کاری جاری خود را به دایرکتوری ریشه تغییر می‌دهد (مگر اینکه --no-chdir مشخص شده باشد). پس از اینکه فرآیند فرزند مقداردهی اولیه خود را به پایان رساند، فرآیند والد خارج می‌شود. ovs-vswitchd تنها پس از اتصال به پایگاه‌داده، دریافت پیکربندی اولیه و اعمال آن پیکربندی در پس‌زمینه قرار می‌گیرد.
یک فرآیند اضافی برای نظارت بر دیمن ovs-vswitchd ایجاد می‌کند. اگر دیمن به دلیل سیگنالی که نشان‌دهنده خطای برنامه‌نویسی است (SIGABRT، SIGALRM، SIGBUS، SIGFPE، SIGILL، SIGPIPE، SIGSEGV، SIGXCPU یا SIGXFSZ) متوقف شود، آنگاه فرآیند ناظر نسخه جدیدی از آن را راه‌اندازی می‌کند. اگر دیمن از بین برود یا به دلیل دیگری خارج شود، فرآیند ناظر نیز پایان می‌یابد.
این گزینه معمولاً همراه با --detach استفاده می‌شود، اما بدون آن نیز کار می‌کند.
به طور پیش‌فرض، هنگامی که --detach مشخص شده باشد، ovs-vswitchd پس از جدا شدن، دایرکتوری کاری جاری خود را به دایرکتوری ریشه تغییر می‌دهد. در غیر این صورت، فراخوانی ovs-vswitchd از یک دایرکتوری که با بی‌دقتی انتخاب شده باشد مانع از این می‌شود که مدیر سیستم بتواند سیستم‌فایلی را که آن دایرکتوری را در بر دارد جدا (unmount) کند.
مشخص کردن --no-chdir این رفتار را متوقف کرده و مانع تغییر دایرکتوری کاری جاری توسط ovs-vswitchd می‌شود. این ویژگی ممکن است برای جمع‌آوری فایل‌های core مفید باشد، زیرا رفتار معمول این است که رونوشت‌های حافظه (core dumps) در دایرکتوری کاری جاری نوشته شوند و دایرکتوری ریشه گزینه مناسبی برای این منظور نیست.
این گزینه هنگامی که --detach مشخص نشده باشد هیچ اثری ندارد.
به طور پیش‌فرض، دیمن تلاش می‌کند تا خود را برای کار با فایل‌های زیر دایرکتوری‌های شناخته‌شده‌ای که در زمان ساخت تعیین شده‌اند محدود سازد. بهتر است به این رفتار پیش‌فرض پایبند باشید و از این پرچم استفاده نکنید مگر اینکه سیستم کنترل دسترسی دیگری برای محدودسازی دیمن به کار گرفته شده باشد. توجه داشته باشید که برخلاف سایر پیاده‌سازی‌های کنترل دسترسی که معمولاً از فضای هسته اعمال می‌شوند (مانند DAC یا MAC)، خود‌محدودسازی از سمت خود دیمن در فضای کاربری اعمال می‌شود و بنابراین نباید به عنوان یک راهبرد مهار کامل نگریسته شود، بلکه باید به عنوان یک لایه امنیتی افزوده در نظر گرفته شود.
باعث می‌شود ovs-vswitchd به عنوان کاربر متفاوتی که در قالب "user:group" تعیین شده اجرا شود، و در نتیجه بیشتر امتیازات ریشه را کنار بگذارد. فرم‌های کوتاه "user" و ":group" نیز مجاز هستند که به ترتیب برای کاربر یا گروه جاری لحاظ می‌شوند. تنها دیمن‌هایی که توسط کاربر ریشه راه‌اندازی شده باشند این آرگومان را می‌پذیرند.
در لینوکس، پیش از واگذاری امتیازات ریشه، قابلیت‌های CAP_IPC_LOCK و CAP_NET_BIND_SERVICES به دیمن‌ها اعطا خواهد شد. دیمن‌هایی که با یک مسیر داده تعامل دارند، مانند ovs-vswitchd، سه قابلیت دیگر یعنی CAP_NET_ADMIN، CAP_NET_BROADCAST و CAP_NET_RAW را نیز دریافت می‌کنند. تغییر قابلیت‌ها حتی در صورتی که کاربر جدید ریشه باشد اعمال خواهد شد.


یک فایل PEM حاوی کلید خصوصی مورد استفاده به عنوان هویت ovs-vswitchd برای اتصالات خروجی SSL/TLS را مشخص می‌کند.

یک فایل PEM حاوی گواهی را مشخص می‌کند که معتبر بودن کلید خصوصی مشخص‌شده در -p یا --private-key را تأیید می‌کند. گواهی باید توسط مرجع صدور گواهی (CA) امضا شده باشد که طرف مقابل در اتصالات SSL/TLS برای تأیید آن استفاده خواهد کرد.

یک فایل PEM حاوی گواهی CA را مشخص می‌کند که ovs-vswitchd باید برای اعتبارسنجی گواهی‌های ارائه‌شده توسط همتایان SSL/TLS استفاده کند. (این ممکن است همان گواهی باشد که همتایان SSL/TLS برای اعتبارسنجی گواهی تعیین‌شده در -c یا --certificate به کار می‌برند، یا بسته به طرح PKI مورد استفاده ممکن است گواهی دیگری باشد.)

اعتبارسنجی گواهی‌های ارائه‌شده توسط همتایان SSL/TLS را غیرفعال می‌کند. این کار یک ریسک امنیتی ایجاد می‌کند، زیرا موجب می‌شود نتوان گواهی‌ها را به عنوان میزبان‌های معتبر و شناخته‌شده تأیید کرد.
نام سرور را برای استفاده در نشانگر نام سرور TLS (SNI) تعیین می‌کند. به طور پیش‌فرض، نام میزبان برگرفته از رشته اتصال برای SNI استفاده می‌شود. این گزینه اجازه بازنویسی نام میزبان SNI را می‌دهد، که هنگام اتصال از طریق پروکسی‌ها یا سرویس‌مش‌هایی که نقطه اتصال با نام سرور مورد نظر متفاوت است مفید خواهد بود.
هنگامی که cacert.pem وجود داشته باشد، این گزینه همانند -C یا --ca-cert عمل می‌کند. اگر وجود نداشته باشد، آنگاه ovs-vswitchd تلاش خواهد کرد گواهی CA را در نخستین اتصال SSL/TLS خود از طرف مقابل دریافت کرده و در فایل PEM نام‌برده ذخیره کند. اگر موفقیت‌آمیز باشد، بلافاصله اتصال را قطع کرده و مجدداً متصل می‌شود، و از آن پس تمامی اتصالات SSL/TLS باید توسط گواهی امضاشده توسط گواهی CA به‌دست‌آمده احراز هویت شوند.
این گزینه اتصال SSL/TLS را در معرض حمله مرد میانی (man-in-the-middle) جهت تصاحب گواهی CA اولیه قرار می‌دهد، اما برای راه‌اندازی اولیه (bootstrapping) می‌تواند مفید باشد.
این گزینه تنها در صورتی مفید است که طرف مقابل SSL/TLS گواهی CA خود را به عنوان بخشی از زنجیره گواهی SSL/TLS ارسال کند. پروتکل‌های SSL/TLS سرور را ملزم به ارسال گواهی CA نمی‌کنند.
این گزینه با -C و --ca-cert ناسازگار و مانعة‌الجمع است.
یک فایل PEM حاوی یک یا چند گواهی تکمیلی برای ارسال به طرف‌های مقابل در SSL/TLS را مشخص می‌کند. فایل peer-cacert.pem باید همان گواهی CA باشد که برای امضای گواهی اختصاصی ovs-vswitchd استفاده شده است، یعنی همان گواهی تعیین‌شده در -c یا --certificate. اگر گواهی ovs-vswitchd خودامضا (self-signed) باشد، آنگاه --certificate و --peer-ca-cert باید فایل یکسانی را مشخص کنند.
این گزینه در عملکرد عادی کاربردی ندارد، زیرا همتای SSL/TLS باید از قبل گواهی CA را داشته باشد تا به هویت ovs-vswitchd اعتماد کند. با این حال، این ویژگی روشی برای یک نصب جدید فراهم می‌سازد تا در نخستین اتصال SSL/TLS خود گواهی CA را راه‌اندازی کند.


سطوح ثبت وقایع را مشخص می‌کند. بدون هیچ spec، سطح ثبت وقایع را برای تمام ماژول‌ها و مقصدها بر روی dbg تنظیم می‌کند. در غیر این صورت، spec فهرستی از کلمات است که با فاصله، کاما یا دونقطه از هم جدا شده‌اند، و حداکثر شامل یک مورد از هر یک از دسته‌های زیر خواهد بود:
  • یک نام ماژول معتبر، همان‌طور که توسط دستور vlog/list در ovs-appctl(8) نمایش داده می‌شود، تغییر سطح ثبت وقایع را به ماژول تعیین‌شده محدود می‌کند.
  • عبارت‌های syslog، console یا file، برای محدود کردن تغییر سطح ثبت وقایع صرفاً به لاگ سیستم، کنسول یا یک فایل. (اگر --detach مشخص شده باشد، ovs-vswitchd توصیف‌کننده‌های استاندارد فایل خود را می‌بندد، بنابراین لاگ‌گیری در کنسول اثری نخواهد داشت.)
  • عبارت‌های off، emer، err، warn، info یا dbg، برای کنترل سطح پیام‌ها. پیام‌های با سطح اهمیت تعیین‌شده یا بالاتر ثبت خواهند شد، و پیام‌های با اهمیت کمتر فیلتر می‌شوند. مقدار off تمام پیام‌ها را فیلتر می‌کند. برای مشاهده تعاریف مربوط به هر سطح لاگ به ovs-appctl(8) مراجعه فرمایید.
بزرگی و کوچکی حروف در spec نادیده گرفته می‌شود.
صرف‌نظر از سطوح تعیین‌شده برای file، ثبت وقایع در فایل صورت نخواهد گرفت مگر آنکه گزینه --log-file نیز مشخص شده باشد (پایین را ببینید).
جهت سازگاری با نسخه‌های قدیمی‌تر OVS، عبارت any به عنوان یک کلمه پذیرفته می‌شود ولی تأثیری ندارد.

بیشترین سطح پرگویی لاگ را اعمال می‌کند که معادل --verbose=dbg است.

الگوی قالب‌بندی لاگ را برای destination بر روی pattern تنظیم می‌کند. برای آگاهی از ساختار معتبر pattern به ovs-appctl(8) مراجعه نمایید.

شناسه facility استاندارد RFC5424 پیام لاگ را تنظیم می‌کند. آرگومان facility می‌تواند یکی از موارد kern، user، mail، daemon، auth، syslog، lpr، news، uucp، clock، ftp، ntp، audit، alert، clock2، local0، local1، local2، local3، local4، local5، local6 یا local7 باشد. اگر این گزینه مشخص نشود، مقدار daemon به عنوان پیش‌فرض برای syslog سیستم محلی استفاده شده و مقدار local0 برای ارسال پیام به هدف تعیین‌شده از طریق گزینه --syslog-target به کار می‌رود.
ثبت وقایع در فایل را فعال می‌کند. اگر file مشخص شده باشد، به عنوان نام دقیق فایل لاگ به کار می‌رود. نام پیش‌فرض فایل لاگ در صورت عدم ذکر file برابر با /var/log/openvswitch/ovs-vswitchd.log است.
پیام‌های syslog را علاوه بر syslog سیستم، به پورت UDP شماره port در میزبان host ارسال می‌کند. مقدار host باید یک نشانی عددی IP باشد و نه نام میزبان.
روش ارسال پیام‌های syslog به دیمن syslog را با method مشخص می‌کند. حالت‌های زیر پشتیبانی می‌شوند:
  • روش libc، استفاده از تابع syslog() موجود در کتابخانه libc. نقص این روش این است که libc پیش از ارسال واقعی پیام به دیمن syslog از طریق سوکت دامنه یونیکس /dev/log، یک پیشوند ثابت به تمام پیام‌ها می‌افزاید.
  • روش unix:file، استفاده مستقیم از سوکت دامنه یونیکس. با این گزینه می‌توان قالب دلخواه برای پیام مشخص کرد. با این وجود، rsyslogd 8.9 و نگارش‌های قدیمی‌تر در هر حال از تابع تجزیه‌کننده ثابت استفاده می‌کنند که استفاده از سوکت دامنه یونیکس را محدود می‌کند. اگر می‌خواهید با نگارش‌های قدیمی‌تر rsyslogd از قالب دلخواه برای پیام بهره بگیرید، از سوکت UDP به نشانی IP محلی استفاده نمایید.
  • روش udp:ip:port، استفاده از سوکت UDP. با این روش تعیین قالب دلخواه حتی در نگارش‌های قدیمی‌تر rsyslogd نیز میسر است. هنگام ارسال پیام‌های syslog روی سوکت UDP باید احتیاط‌های لازم را در نظر گرفت؛ برای مثال دیمن syslog باید برای شنود روی درگاه UDP تعیین‌شده پیکربندی شده باشد، قوانین تصادفی iptables ممکن است در ترافیک محلی syslog تداخل ایجاد کنند، و ملاحظات امنیتی ویژه‌ای وجود دارند که برای سوکت‌های UDP صدق می‌کنند اما شامل سوکت‌های دامنه یونیکس نمی‌شوند.
  • روش null، تمامی پیام‌های ارسال‌شده به syslog را دور می‌ریزد.
مقدار پیش‌فرض از متغیر محیطی OVS_SYSLOG_METHOD خوانده می‌شود؛ اگر این متغیر مقدار نداشته باشد، پیش‌فرض libc است.

نام سوکت کنترلی را تنظیم می‌کند که ovs-vswitchd روی آن به دستورات مدیریتی زمان اجرا گوش فرا می‌دهد (بخش دستورات مدیریت زمان اجرا (RUNTIME MANAGEMENT COMMANDS) را در ادامه ببینید). اگر socket با / آغاز نشود، به صورت نسبی با /run/openvswitch سنجیده می‌شود. اگر از گزینه --unixctl اصلاً استفاده نشود، سوکت پیش‌فرض /run/openvswitch/ovs-vswitchd.pid.ctl خواهد بود که در آن pid شناسه فرآیند ovs-vswitchd است.
تعیین none برای socket قابلیت سوکت کنترلی را غیرفعال می‌کند.

یک پیام راهنمای مختصر را در کنسول چاپ می‌کند.

اطلاعات نسخه برنامه را در کنسول چاپ می‌کند.

دستور ovs-appctl(8) می‌تواند دستوراتی را به یک فرآیند در حال اجرای ovs-vswitchd ارسال نماید. دستورات پشتیبانی‌شده در زیر شرح داده شده‌اند. توضیحات این دستورات نیازمند آشنایی با نحوه پیکربندی Open vSwitch است.

موجب خروج باوقار (graceful) دیمن ovs-vswitchd می‌شود. اگر --cleanup مشخص شده باشد، جریان‌ها را از مسیرهای داده پاک کرده و سایر منابع مسیر داده پیکربندی‌شده توسط ovs-vswitchd را آزاد می‌کند. در غیر این صورت، جریان‌های مسیر داده و سایر منابع حذف‌نشده باقی می‌مانند. منابع مربوط به مسیرهای داده‌ای که به طور مستقیم در ovs-vswitchd تعبیه شده‌اند (مانند مسیر داده با نوع netdev) همواره بدون در نظر گرفتن --cleanup آزاد می‌شوند، به جز درگاه‌هایی که دارای نوع internal هستند. برای آزادسازی درگاه‌های نوع internal نیز از گزینه --cleanup استفاده نمایید.
رابط مورد نظر را برای دریافت فهرستی از انواع کیفیت خدمات (QoS) که از طریق Open vSwitch برای interface مشخص‌شده قابل پیکربندی هستند پرس‌وجو می‌کند.
هسته سیستم‌عامل را برای اطلاعات پیکربندی و آمار کیفیت خدمات مرتبط با interface داده‌شده بررسی می‌کند.
اطلاعات تفصیلی درباره سازوکار تشخیص ارسال دوطرفه (BFD) پیکربندی‌شده روی interface را نمایش می‌دهد. اگر interface مشخص نشده باشد، اطلاعات تفصیلی درباره تمامی رابط‌هایی که BFD روی آن‌ها فعال است نشان داده می‌شود.
وضعیت خرابی ماژول BFD را در interface (یا تمامی رابط‌ها اگر موردی مشخص نشود) به مقدار status تحمیل می‌کند. مقدار status می‌تواند "true"، "false" یا "normal" باشد که حالت اخیر رفتار عادی سیستم را بازیابی می‌کند.
اطلاعات تفصیلی مربوط به مدیریت خطای پیوستگی (CFM) پیکربندی‌شده بر روی interface را نمایش می‌دهد. اگر interface مشخص نشده باشد، اطلاعات تمامی رابط‌های دارای CFM نمایش داده می‌شود.
وضعیت خرابی ماژول CFM را روی interface (یا تمامی رابط‌ها در صورت عدم تعیین) به مقدار status تحمیل می‌کند. پارامتر status می‌تواند مقادیر "true"، "false" یا "normal" را بپذیرد که گزینه normal رفتار پیش‌فرض را برمی‌گرداند.
در صورتی که پل bridge پروتکل STP را اجرا کند، رخداد تغییر همبندی (topology change) را به آن تحمیل می‌کند. این امر ممکن است موجب شود پل اعلان‌های تغییر همبندی (TCN) را برای همتایان خود بفرستد و جدول MAC خود را پاک کند. اگر پلی مشخص نشود، رخداد تغییر همبندی بر تمامی پل‌ها اعمال می‌شود.
اطلاعات تفصیلی درباره درخت پوشا (spanning tree) را روی bridge نمایش می‌دهد. اگر bridge ذکر نشود، اطلاعات تمامی پل‌های دارای STP فعال به تصویر کشیده می‌شود.
در صورتی که پل پروتکل RSTP را اجرا کند، رخداد تغییر همبندی را بر bridge تحمیل می‌نماید. این کار ممکن است باعث ارسال اعلان‌های تغییر همبندی به همتایان و تخلیه جدول آدرس‌های MAC آن شود. اگر پلی ذکر نشود، رخداد بر همه پل‌ها تحمیل می‌گردد.
اطلاعات تفصیلی پروتکل درخت پوشای سریع (rapid spanning tree) را در bridge نشان می‌دهد. اگر bridge مشخص نشود، اطلاعات تمام پل‌های دارای RSTP فعال نشان داده خواهد شد.

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

آدرس mac را به یک درگاه port و شناسه vlan در پل bridge می‌افزاید. از این ابزار می‌توان برای مقداردهی اولیه جدول fdb بدون اتکا به یادگیری پویای MAC بهره گرفت.
آدرس mac را از درگاه و vlan در پل bridge حذف می‌کند.
جدول یادگیری آدرس MAC در پل bridge، یا تمام جدول‌های یادگیری در صورت عدم ذکر bridge را پاک می‌کند.
هر یک از جفت‌های آدرس MAC و VLAN یادگرفته‌شده توسط پل تعیین‌شده bridge را به همراه درگاهی که روی آن یاد گرفته شده و طول عمر مدخل (age بر حسب ثانیه) فهرست می‌کند. می‌توان نام چند پل را جهت پرس‌وجو از آن‌ها در یک دستور مشخص کرد، و اگر نام پلی ذکر نشود جداول تمامی پل‌ها نمایش داده می‌شوند. هنگامی که بیش از یک پل نمایش داده شود، خروجی متنی یک ستون ابتدایی به نام "Bridge" خواهد داشت که ورودی‌های هر پل را دسته‌بندی نموده و نام پل را تنها در سطر نخست آن درج می‌کند؛ پلی که هیچ مدخلی نداشته باشد به صورت سطری با تنها نام پل نشان داده می‌شود. خروجی JSON شیئی است که کلیدهای آن نام پل‌ها بوده و مقادیر آن آرایه‌ای از ورودی‌های آن پل هستند.
آمار جدول یادگیری آدرس MAC را در پل bridge، یا در صورت عدم ذکر bridge تمامی آمارها را پاک می‌کند.
آمارهای جدول یادگیری آدرس MAC را برای پل مشخص‌شده bridge نمایش می‌دهد.
جدول ردیابی چندبخشی (multicast snooping table) در پل bridge، یا تمامی جداول در صورت عدم تعیین bridge را پاک می‌کند.
هر یک از جفت‌های گروه چندبخشی و VLAN فراگرفته‌شده توسط پل مشخص‌شده bridge را همراه با درگاهی که از طریق آن یاد گرفته شده و سن مدخل به ثانیه فهرست می‌کند.
باعث می‌شود پل bridge تمامی اتصالات کنترل‌کننده OpenFlow خود را قطع کرده و مجدداً متصل شود. اگر bridge تعیین نشود، تمام پل‌ها ارتباط کنترل‌کننده خود را قطع و دوباره متصل می‌کنند.
این دستور ممکن است برای اشکال‌زدایی مشکلات کنترل‌کننده OpenFlow مفید باشد.
تمام جریان‌های موجود در bridge را فهرست می‌کند، از جمله جریان‌هایی که معمولاً در برابر دستوراتی چون ovs-ofctl dump-flows پنهان هستند. جریان‌هایی که توسط سازوکارهایی مانند کنترل درون‌باندی (in-band) و fail-open ایجاد می‌شوند، از دید کنترل‌کننده پنهان هستند زیرا کنترل‌کننده مجاز به تغییر یا لغو آن‌ها نیست. اگر --offload-stats مشخص شود، آمار بسته‌ها و بایت‌های تخلیه‌شده روی سخت‌افزار (offloaded) که زیرمجموعه‌ای از کل بسته‌ها و بایت‌ها هستند نیز نمایش داده می‌شود.

این دستورات درگاه‌های پیوندخورده (bonded) روی پل‌های Open vSwitch را مدیریت می‌کنند. برای درک برخی از این دستورات، درک جزئیاتی از پیاده‌سازی پیوند موسوم به «متعادل‌سازی بار مبدأ» (SLB) ضروری است. پیاده‌سازی پیوند به جای تخصیص مستقیم آدرس‌های اترنت مبدأ به اعضا، تابعی را محاسبه می‌کند که آدرس‌های 48 بیتی اترنت مبدأ را به مقداری 8 بیتی (مقدار هش MAC) می‌نگارد. سپس تمام آدرس‌های اترنت که به یک مقدار 8 بیتی یکسان نگاشته شوند به یک عضو واحد تخصیص می‌یابند.

تمام پیوندها و اعضای آن‌ها را در هر پل فهرست می‌کند.
تمام اطلاعات مربوط به پیوند (تاخیر فعال‌سازی updelay، تاخیر غیرفعال‌سازی downdelay و زمان باقی‌مانده تا توازن مجدد بعدی) در مورد درگاه پیوندخورده port، یا همه درگاه‌های پیوندخورده در صورت عدم تعیین port را فهرست می‌کند. همچنین اطلاعات هر عضو را نشان می‌دهد: وضعیت فعال یا غیرفعال بودن، زمان باقی‌مانده تا تکمیل یک updelay یا downdelay در صورت جریان داشتن، عضو فعال بودن، و مقادیر هشی که به آن عضو اختصاص یافته‌اند. هرگونه اطلاعات LACP مرتبط با این پیوند را می‌توان با استفاده از دستور lacp/show به دست آورد.
تنها برای پیوندهای نوع SLB معتبر است. یک هش MAC تعیین‌شده را به یک عضو جدید منتقل می‌کند. مقدار port درگاه پیوند، پارامتر hash هش MAC برای انتقال (به عنوان عددی ده‌دهی بین 0 تا 255)، و پارامتر member عضو جدید تخصیص‌یافته را مشخص می‌سازد.
این تخصیص مجدد دائمی نیست: متعادل‌سازی بار یا رخداد fail-over باعث می‌شود که هش MAC طبق روال عادی به یک عضو جدید جابجا شود.
هش MAC را نمی‌توان به عضوی که غیرفعال است انتقال داد.
عضو member را به عنوان عضو فعال روی port تعیین می‌کند. عضو member باید در وضعیت فعال باشد.
این تنظیم دائمی نیست: در صورتی که عضو member غیرفعال شود، عضو فعال جدیدی انتخاب خواهد شد.

عضو member را در درگاه پیوند port فعال (یا غیرفعال) می‌کند، و هرگونه updelay (یا downdelay) را نادیده می‌گیرد.
این تنظیم دائمی نیست: تنها تا زمانی پایدار می‌ماند که وضعیت حامل فیزیکی (carrier) عضو member تغییر یابد.
مقدار هشی را برمی‌گرداند که برای آدرس mac همراه با vlan و basis (در صورت تعیین) مورد استفاده قرار می‌گیرد.
تمام اطلاعات مربوط به پروتکل LACP در درگاه port داده‌شده را فهرست می‌کند: فعال یا غیرفعال، کلید تجمیع، شناسه سیستم و اولویت سیستم. همچنین اطلاعات هر عضو را نشان می‌دهد: وضعیت فعال یا غیرفعال، متصل یا منفصل، شناسه و اولویت درگاه، اطلاعات actor و partner. اگر port مشخص نشود، اطلاعات تفصیلی برای همه رابط‌های دارای CFM فعال نمایش داده می‌شود.
آمارهای مختلفی پیرامون واحدهای داده پروتکل LACP (تعداد PDUهای ارسالی و دریافتی، بسته‌های PDU خراب دریافت شده) و وضعیت عضو (تعداد دفعات منقضی شدن/پیش‌فرض شدن وضعیت و تغییرات حامل) را برای درگاه داده‌شده port فهرست می‌کند. اگر port مشخص نشود، آمارهای تمامی رابط‌های دارای LACP فعال نمایش داده می‌شود.

روش اصلی برای پیکربندی ovs-vswitchd از طریق پایگاه‌داده Open vSwitch است، مثلاً با استفاده از ovs-vsctl(8). این دستورات یک واسط اشکال‌زدایی برای مدیریت مسیرهای داده فراهم می‌کنند. آن‌ها همان ویژگی‌ها (و ساختار نحوی) دستور ovs-dpctl(8) را پیاده‌سازی می‌کنند. بر خلاف ovs-dpctl(8)، این دستورات با مسیرهای داده‌ای که مستقیماً در ovs-vswitchd تعبیه شده‌اند (مانند مسیر داده با نوع netdev) نیز کار می‌کنند.

در صورتی که ovs-vswitchd در حال اجراست، از دستورات برای افزودن، حذف یا تغییر مسیرهای داده استفاده نکنید، زیرا با مدیریت مسیر داده اختصاصی ovs-vswitchd تداخل خواهد داشت.

مسیر داده dp را ایجاد می‌کند، همراه با یک درگاه محلی که آن هم dp نام دارد. اگر یک دستگاه شبکه به نام dp از قبل وجود داشته باشد این عملیات با شکست مواجه می‌شود.
اگر netdevها مشخص شده باشند، برنامه ovs-vswitchd آن‌ها را به مسیر داده جدید اضافه می‌کند، درست همان‌طور که گویی دستور add-if فراخوانی شده است.
مسیر داده dp را حذف می‌کند. اگر dp با دستگاه‌های شبکه‌ای مرتبط باشد، آن‌ها نیز به طور خودکار برداشته می‌شوند.
هر netdev را به مجموعه دستگاه‌های شبکه‌ای که توسط مسیر داده dp نظارت می‌شوند می‌افزاید، که در آن dp نام یک مسیر داده موجود و netdev نام یکی از دستگاه‌های شبکه میزبان است، مانند eth0. به محض افزوده شدن دستگاه شبکه به مسیر داده، مسیر داده مالکیت کامل ترافیک آن را در دست می‌گیرد و دستگاه در برابر سایر اجزای سیستم خاموش و بدون فعالیت به نظر خواهد رسید.
دستگاه netdev می‌تواند با فهرستی از گزینه‌ها همراه شود که با کاما از هم تفکیک شده‌اند. گزینه‌های زیر در حال حاضر پشتیبانی می‌شوند:
نوع درگاه مورد نظر را تعیین می‌کند. نوع پیش‌فرض system است.
شماره درگاه خاصی در داخل مسیر داده را درخواست می‌کند. اگر این گزینه تعیین نشود به طور خودکار مقداری به آن اختصاص خواهد یافت.
یک گزینه دلخواه به صورت جفت کلید-مقدار را به پیکربندی درگاه اضافه می‌کند.
سند ovs-vswitchd.conf.db(5) انواع درگاه‌های موجود و گزینه‌های آن‌ها را مستند کرده است.
هر درگاه port در dp را مطابق مشخصات بازپیکربندی می‌کند. گزینه‌ای به فرم key=value گزینه کلید-مقدار داده‌شده را به درگاه اضافه می‌کند یا مقدار یک کلید موجود را بازنویسی می‌نماید. گزینه‌ای به شکل key=، یعنی بدون مقدار، گزینه مشخص‌شده به نام key را حذف می‌کند. نوع و شماره درگاه قابل تغییر نیستند، بنابراین type و port_no تنها در صورتی مجاز هستند که با پیکربندی موجود مطابقت داشته باشند.
هر netdev را از لیست دستگاه‌های شبکه تحت نظارت مسیر داده dp حذف می‌کند.
نام هر مسیر داده پیکربندی‌شده را در سطری مجزا چاپ می‌کند.
خلاصه‌ای از مسیرهای داده پیکربندی‌شده را، شامل شماره‌های مسیر داده و فهرستی از درگاه‌های متصل به هر مسیر داده، چاپ می‌کند. (درگاه محلی به عنوان درگاه شماره 0 شناخته می‌شود.) اگر -s یا --statistics مشخص شود، شمارنده‌های بسته و بایت برای هر درگاه نیز چاپ می‌شوند.
شماره‌های مسیر داده از آمارهای جریان و آمارهای ماسک مگا‌جریان (mega flow mask) تشکیل شده‌اند.
ردیف "lookups" سه آمار مرتبط با جستجوی جریان را که بر اثر پردازش بسته‌های ورودی در مسیر داده رخ می‌دهند نمایش می‌دهد. مقدار "hit" تعداد بسته‌های منطبق بر جریان‌های موجود را نشان می‌دهد. مقدار "missed" بیانگر تعداد بسته‌هایی است که با هیچ جریانی مطابقت نیافته و نیازمند پردازش در فضای کاربری هستند. مقدار "lost" تعداد بسته‌هایی است که برای پردازش در فضای کاربری ارسال شده اما پیش از رسیدن به آن دور ریخته شده‌اند. مجموع مقادیر "hit" و "miss" برابر است با کل بسته‌های پردازش‌شده در مسیر داده.
ردیف "flows" تعداد جریان‌ها در مسیر داده را نشان می‌دهد.
ردیف "masks" آمار ماسک‌های مگا‌جریان را نمایش می‌دهد. این ردیف برای مسیرهای داده‌ای که مگا‌جریان را پیاده‌سازی نمی‌کنند نمایش داده نمی‌شود. پارامتر "hit" تعداد کل ماسک‌های بررسی‌شده برای تطبیق بسته‌های ورودی را نشان می‌دهد. پارامتر "total" تعداد ماسک‌های موجود در مسیر داده را نشان می‌دهد. مقدار "hit/pkt" میانگین ماسک‌های بررسی‌شده به ازای هر بسته را نشان می‌دهد؛ یعنی نسبت بین "hit" و مجموع بسته‌های پردازش‌شده توسط مسیر داده.
اگر یک یا چند مسیر داده مشخص شده باشد، اطلاعات تنها برای آن مسیرها نمایش می‌یابد. در غیر این صورت، ovs-vswitchd اطلاعات مربوط به تمامی مسیرهای داده پیکربندی‌شده را نمایش می‌دهد.

دستورات زیر اصولاً برای اشکال‌زدایی Open vSwitch مفید هستند. ورودی‌های جدول جریان (هم مطابقت‌ها و هم عملیات‌ها) که این دستورات با آن‌ها کار می‌کنند، ورودی‌های جریان OpenFlow نیستند. در عوض، آن‌ها جریان‌هایی متفاوت و به مراتب ساده‌تر هستند که توسط ماژول هسته Open vSwitch نگهداری می‌شوند. اگر ovs-vswitchd در حال اجراست، از دستورات برای افزودن، حذف یا تغییر جریان‌های مسیر داده استفاده نکنید زیرا در مدیریت جریان اختصاصی مسیر داده ovs-vswitchd تداخل ایجاد خواهد کرد. به جای آن، برای کار با ورودی‌های جریان OpenFlow از ovs-ofctl(8) استفاده کنید.

هنگامی که دقیقاً یک مسیر داده وجود داشته باشد، آرگومان dp در هر یک از این دستورات اختیاری است و مسیر پیش‌فرض در نظر گرفته می‌شود. هنگامی که چندین مسیر داده وجود دارد، ذکر نام مسیر داده الزامی خواهد بود.

تمام ورودی‌های جریان را در جدول جریان مسیر داده dp در کنسول چاپ می‌کند. بدون گزینه -m یا --more، خروجی از فیلدهایی که یک جریان آن‌ها را کاملاً به صورت عام (wildcard) در نظر گرفته صرف‌نظر می‌کند؛ با گزینه -m یا --more، خروجی شامل تمام فیلدهای عام نیز خواهد بود.
اگر filter=filter مشخص شده باشد، تنها جریان‌هایی را نمایش می‌دهد که با filter مطابقت داشته باشند. پارامتر filter جریانی به فرم مشابه قالب پذیرفته‌شده توسط دستور add-flow در ovs-ofctl(8) است. (این یک جریان OpenFlow نیست: گذشته از تفاوت‌های دیگر، هرگز حاوی کاراکترهای عام نیست.) گزینه filter همچنین برای تطبیق فیلدهای عام در جریان مسیر داده مفید است. به عنوان مثال، مقدار filter='tcp,tp_src=100' جریانی را تطبیق می‌دهد که حاوی 'tcp(src=80/0xff00,dst=8080/0xff)' باشد.
اگر pmd=pmd مشخص شده باشد، فقط جریان‌های مربوط به پردازنده pmd تعیین‌شده را نمایش می‌دهد. استفاده از pmd=-1 تخلیه اطلاعات را به جریان‌های ریسه اصلی (main thread) محدود می‌کند. این گزینه فقط توسط مسیر داده فضای کاربری (userspace datapath) پشتیبانی می‌شود.
اگر type=type مشخص شده باشد، فقط جریان‌های مربوط به انواع مشخص‌شده را نمایش می‌دهد. این گزینه تنها برای ovs-appctl dpctl/dump-flows پشتیبانی می‌شود. مقدار type فهرستی است که با کاما تفکیک شده و می‌تواند حاوی هر یک از موارد زیر باشد:
ovs - جریان‌های مدیریت‌شده در مسیر داده ovs را نمایش می‌دهد
tc - جریان‌های مدیریت‌شده در مسیر داده tc را نمایش می‌دهد
dpdk - جریان‌های تخلیه‌شده کامل روی dpdk را نمایش می‌دهد
offloaded - جریان‌های تخلیه‌شده روی سخت‌افزار (HW) را نمایش می‌دهد
non-offloaded - جریان‌های تخلیه‌نشده روی سخت‌افزار را نمایش می‌دهد
partially-offloaded - جریان‌هایی که بخشی از پردازش آن‌ها در سخت‌افزار انجام می‌شود را نشان می‌دهد
all - همه انواع جریان‌ها را نمایش می‌دهد
به طور پیش‌فرض تمام انواع جریان‌ها نمایش داده می‌شوند. برنامه ovs-dpctl همواره طوری رفتار می‌کند که گویی type برابر ovs بوده است.
جریانی را در جدول جریان dp اضافه یا تغییر می‌دهد که هنگام ورود بسته‌ای منطبق بر flow، عملیات‌های actions اجرا گردند.
دستور add-flow تنها در صورتی موفق می‌شود که flow از قبل در dp وجود نداشته باشد. در مقابل، دستور mod-flow بدون گزینه --may-create فقط اقدامات یک جریان موجود را اصلاح می‌کند. با گزینه --may-create، دستور mod-flow جریانی جدید اضافه کرده یا جریانی موجود را ویرایش می‌نماید.
اگر -s یا --statistics مشخص شود، آنگاه mod-flow آمارهای جریان ویرایش‌شده را چاپ می‌کند. آمارهای جریان شامل تعداد بسته‌ها و بایت‌هایی است که از جریان گذشته‌اند، زمان سپری‌شده از آخرین باری که جریان بسته‌ای را پردازش کرده است، و (برای جریان‌های TCP) اجتماع پرچم‌های TCP پردازش‌شده در جریان.
با گزینه --clear، دستور mod-flow آمارهای جریان را صفر می‌کند. آمارهای چاپ‌شده در صورت همراهی با -s یا --statistics مقادیری خواهند بود که دقیقاً پیش از صفر کردن آمار ثبت شده‌اند.
یادداشت: ساختار flow و actions با ساختار نحوی مورد استفاده در دستور add-flow متعلق به ovs-ofctl(8) یکسان نیست.
مثال‌های استفاده

هدایت بسته‌های ARP میان درگاه‌های 1 و 2 در مسیر داده myDP:

ovs-dpctl add-flow myDP .
"in_port(1),eth(),eth_type(0x0806),arp()" 2
ovs-dpctl add-flow myDP .
"in_port(2),eth(),eth_type(0x0806),arp()" 1

هدایت تمام ترافیک IPv4 میان دو نشانی روی درگاه‌های 1 و 2:

ovs-dpctl add-flow myDP .
"in_port(1),eth(),eth_type(0x800), ipv4(src=172.31.110.4,dst=172.31.110.5)" 2
ovs-dpctl add-flow myDP .
"in_port(2),eth(),eth_type(0x800), ipv4(src=172.31.110.5,dst=172.31.110.4)" 1
ورودی‌های جریان را از file (یا در صورت تعیین - برای file از stdin) خوانده و هر ورودی را به مسیر داده اضافه کرده، تغییر داده یا حذف می‌کند. هر مشخصه جریان (مثلاً هر خط در file) می‌تواند با یکی از کلمات کلیدی add، modify یا delete آغاز شود تا نشان دهد جریان باید افزوده، ویرایش یا حذف شود. مشخصه جریانی که فاقد این کلمات کلیدی باشد بر اساس دستوری که فراخوانی شده است مدیریت می‌شود. تمامی ویرایش‌های جریان به صورت تراکنش‌های مجزا و با همان ترتیب تعیین‌شده اجرا می‌گردند.
جریانی را که با flow تطبیق می‌یابد از جدول جریان dp حذف می‌کند. اگر -s یا --statistics تعیین شده باشد، آنگاه del-flow آمارهای جریان حذف‌شده را چاپ می‌نماید.
جریان با شناسه منحصر‌به‌فرد ufid را از جدول جریان dp واکشی می‌کند. پارامتر ufid باید به صورت یک رشته با 32 نویسه هگزادسیمال مشخص شود.
تمام ورودی‌های جریان را از جدول جریان مسیر داده dp حذف می‌کند.

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

اندازه‌های فعلی حافظه پنهان را در کنسول چاپ می‌کند.
حافظه پنهان cache مشخص در dp را روی اندازه size تنظیم می‌کند. نام کش را می‌توان با استفاده از دستور cache-get-size پیدا کرد.

دستورات زیر برای عیب‌یابی و پیکربندی جدول ردیابی اتصال (connection tracking) در مسیر داده مفید هستند.

هنگامی که دقیقاً یک مسیر داده موجود باشد، آرگومان dp برای هر یک از این دستورات اختیاری است و مسیر پیش‌فرض اعمال می‌شود. وقتی مسیرهای داده متعددی وجود داشته باشد، تعیین نام مسیر داده الزامی خواهد بود.

یادداشت مهم (ویژه لینوکس): مسیرهای داده system (یعنی مسیرهای داده Open vSwitch ماژول هسته لینوکس) یک جدول ردیابی اتصال مشترک دارند (که توسط سایر زیرسیستم‌های هسته نیز مورد استفاده است، مانند iptables، nftables و پشته معمولی شبکه میزبان). بنابراین، دستورات زیر به طور اختصاصی روی یک مسیر داده اعمال نمی‌شوند.

مدیریت قطعه‌بندی IP (fragmentation) را برای ردیاب اتصال فضای کاربری فعال یا غیرفعال می‌کند. باید یکی از موارد v4 یا v6 مشخص شود. سرهم‌بندی مجدد قطعات IPv4 و IPv6 به طور پیش‌فرض فعال است. این گزینه فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
حداقل اندازه قطعه (هدر L3 به اضافه داده‌ها) را برای قطعات غیرپایانی روی minfrag تنظیم می‌کند. باید v4 یا v6 مشخص گردد. برای افزایش امنیت در برابر حملات محروم‌سازی از سرویس (DOS)، معمولاً می‌توان از مقادیر بالاتری برای حداقل اندازه قطعه استفاده کرد. مقدار پیش‌فرض IPv4 برابر 1200 و حداقل مقدار مجاز آن 400 است. مقدار پیش‌فرض IPv6 برابر 1280، با حداقل مجاز 400 برای انعطاف‌پذیری در آزمون‌ها است. حداکثر اندازه قطعه محدودیتی ندارد، با این حال تنظیم این مقدار روی عدد خیلی بزرگ ممکن است موجب دور ریخته شدن قطعات معتبر شود. فقط برای مسیر داده در فضای کاربری پشتیبانی می‌شود.
حداکثر تعداد قطعاتی را که توسط ردیاب اتصال مسیر داده فضای کاربری ردیابی می‌شوند روی maxfrags قرار می‌دهد. مقدار پیش‌فرض 1000 و حداکثر مقدار مجاز آن 5000 است. توجه داشته باشید تا زمانی که قطعات ناقص هستند بافرهای بسته می‌توانند توسط ماژول قطعه‌بندی نگه داشته شوند، اما پس از 15 ثانیه منقضی (timeout) خواهند شد. اندازه مخزن حافظه (memory pool) در زمان فعال بودن قطعه‌بندی باید به تناسب تنظیم شود. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
تنظیمات پیکربندی و شمارنده‌های قطعه مرتبط با پردازش قطعه‌بندی در ردیاب اتصال مسیر داده فضای کاربری را دریافت می‌کند. با گزینه -m یا --more، فهرست قطعات IP را نیز نمایش می‌دهد. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
تمام ورودی‌های اتصال در ردیاب مورد استفاده توسط dp را در کنسول چاپ می‌کند. اگر zone=zone مشخص شود، تنها اتصالات موجود در zone را نشان می‌دهد. با --more، برخی جزئیات وابسته به پیاده‌سازی نیز گنجانده می‌شوند. با گزینه --statistics زمان‌های انقضا و برچسب‌های زمانی به خروجی افزوده می‌گردند.
تمام ورودی‌های انتظار (expectation) را در ردیاب اتصال مورد استفاده dp در کنسول چاپ می‌کند. اگر zone=zone مشخص شود، فقط انتظارات مربوط به منطقه zone را نمایش می‌دهد. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
ورودی‌های اتصال در ردیاب مورد استفاده توسط dp را بر پایه zone و تاپل ردیابی اتصال ct-origin-tuple پاکسازی می‌کند. اگر تاپل ردیابی مشخص نشود، تمامی ورودی‌های اتصال پاک خواهند شد. اگر zone=zone تعیین گردد، فقط اتصالات درون ناحیه zone تخلیه می‌شوند.
اگر ct-[orig|reply]-tuple ارائه شود، ورودی اتصالی را که توسط این تاپل در ناحیه zone مشخص شده است پاک می‌کند. منطقه در صورت عدم تعیین، پیش‌فرض 0 خواهد بود. ردیاب اتصال فضای کاربری نیازمند پاکسازی با تاپل اصلی پیش از اعمال NAT است و در غیر این صورت پیام هشداری صادر خواهد شد. تاپل می‌تواند به صورت جزئی ارائه شود و تمامی اتصالاتی را که با فیلدهای تعیین‌شده مطابقت دارند حذف خواهد کرد. جهت تعیین تنها ct-reply-tuple، مقدار ct-origin-tuple را رشته خالی در نظر بگیرید.
توجه: در حال حاضر محدودیتی در تطبیق روی ICMP وجود دارد؛ برای تطبیق جزئی پارامترهای ICMP، تاپل ct-[orig|reply]-tuple باید شامل IP مبدأ یا مقصد باشد.
یک مثال از تاپل IPv4 ICMP:
"ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=1,icmp_type=8,icmp_code=0,icmp_id=10"
یک مثال از تاپل IPv6 TCP:
"ct_ipv6_src=fc00::1,ct_ipv6_dst=fc00::2,ct_nw_proto=6,ct_tp_src=1,ct_tp_dst=2"
تعداد اتصالات را که بر اساس پروتکل مورد استفاده در dp گروه‌بندی شده‌اند نمایش می‌دهد. اگر zone=zone مشخص شود، اعداد به اتصالات موجود در آن منطقه اشاره خواهند داشت. با گزینه --more، اتصالات بر اساس وضعیت اتصال به ازای هر پروتکل گروه‌بندی می‌شوند.
برای هر باکت conntrack، تعداد اتصالات مورد استفاده توسط dp را نمایش می‌دهد. اگر gt=threshold مشخص شود، شماره باکت‌ها هنگامی نمایش داده می‌شوند که تعداد اتصالات در یک باکت بیشتر از threshold باشد.
حداکثر سقف مجاز برای ورودی‌های ردیاب اتصال را روی dp برابر با maxconns قرار می‌دهد. این دستور می‌تواند برای کاهش بار پردازشی سیستم ناشی از ردیابی اتصال، یا صرفاً برای محدودسازی تعداد اتصالات به کار رود. اگر تعداد اتصالات در حال حاضر فراتر از سقف جدید درخواست‌شده باشد، سقف جدید زمانی اعمال و تثبیت می‌شود که تعداد اتصالات بر اثر انقضا کاهش یابد. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
حداکثر سقف مجاز ورودی‌های ردیاب اتصال را روی dp چاپ می‌کند. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
تعداد فعلی ورودی‌های ردیاب اتصال در dp را چاپ می‌کند. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
بررسی شماره توالی TCP را فعال یا غیرفعال می‌کند. وقتی غیرفعال باشد، تمامی فرآیندهای راستی‌آزمایی شماره توالی خاموش می‌شوند، از جمله برای ریست‌های TCP. این عملکرد شبیه به حالت 'be_liberal' در Netfilter است، هرچند دقیقاً با آن یکسان نیست. غیرفعال کردن اعتبارسنجی شماره توالی به خودی خود یک بهینه‌سازی محسوب نمی‌شود، اما برای برخی قابلیت‌های بارگذاری سخت‌افزاری که ممکن است مزیت کارایی داشته باشند لازم است. بررسی شماره توالی به طور پیش‌فرض به منظور اعمال امنیت بهتر فعال است و تنها در صورت نیاز جهت پشتیبانی از تخلیه بار روی سخت‌افزار باید غیرفعال گردد. این دستور فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
چاپ می‌کند که آیا بررسی توالی TCP روی dp فعال است یا غیرفعال. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
فاصله زمانی جاروب و پاکسازی (sweep interval) را تنظیم می‌کند. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
فاصله زمانی جاروب فعلی را بر حسب میلی‌ثانیه چاپ می‌کند. فقط برای مسیر داده فضای کاربری پشتیبانی می‌شود.
حداکثر تعداد مجاز اتصالات را در یک منطقه ردیابی اتصال تنظیم می‌کند. یک zone خاص می‌تواند روی حد limit تنظیم شود، و مناطق متعدد را می‌توان با فهرستی تفکیک‌شده با کاما تعیین نمود. اگر حد مجاز برای منطقه‌ای خاص در مسیر داده تعیین نشود، مقدار پیش‌فرض هر منطقه بر آن حاکم خواهد شد. یک منطقه پیش‌فرض می‌تواند با آرگومان default=default_limit مشخص گردد. در ابتدا، حد پیش‌فرض هر منطقه نامحدود است. تعداد ورودی نامحدود را می‌توان با حد 0 تنظیم نمود.
حد ردیابی اتصال را برای zone حذف می‌کند. مناطق متعدد را می‌توان با فهرستی تفکیک‌شده با کاما مشخص کرد.
حداکثر تعداد مجاز اتصالات و شمارش‌های فعلی را به ازای هر منطقه بازیابی می‌کند. اگر zone تعیین شود، تنها منطقه(های) مشخص‌شده چاپ می‌شوند. اگر منطقه‌ای مشخص نگردد، تمامی حدود و شمارش‌های مناطق ارائه می‌شوند. این دستور همواره حد مجاز منطقه پیش‌فرض را نمایش می‌دهد.

این دستورات اجزای DPDK را مدیریت می‌کنند.

هسته‌های پردازشی منطقی (lcores) در DPDK و وابستگی پردازنده‌ای (cpu affinity) آن‌ها را فهرست می‌کند. هنگامی که هسته‌های منطقی به تعداد RTE_MAX_LCORE ثبت شده باشند، برخی ریسه‌های OVS PMD ظاهر نخواهند شد.
تمام اجزای DPDK را که گزارش لاگ تولید می‌کنند همراه با سطوح ثبت وقایع آن‌ها فهرست می‌کند.
سطح ثبت وقایع اجزای DPDK را تنظیم می‌کند. بدون هیچ spec، سطح ثبت وقایع برای تمام اجزای DPDK روی debug قرار می‌گیرد. در غیر این صورت، spec فهرستی از کلمات تفکیک‌شده با فاصله است: یک کلمه می‌تواند یک سطح لاگ باشد (emergency، alert، critical، error، warning، notice، info یا debug)، یا یک الگوی pattern منطبق بر اجزای DPDK (دستور dpdk/log-list را در ovs-appctl(8) ببینید) که با یک علامت دونقطه از سطح لاگ مورد نظر برای اعمال تفکیک شده است.
اطلاعات و آمارهای فضای هیپ (heap) مربوط به malloc در DPDK را چاپ می‌کند.
نواحی حافظه رزرو‌شده (memzones) را از DPDK چاپ می‌کند.

از این دستورات برای آشکارسازی اطلاعات داخلی (عمدتاً آمارها) درباره مسیر داده فضای کاربری "dpif-netdev" استفاده می‌شود. اگر تنها یک مسیر داده وجود داشته باشد (که اغلب بدین صورت است، مگر اینکه از دستورات dpctl/ استفاده شده باشد)، آرگومان dp را می‌توان نادیده گرفت. به طور پیش‌فرض، این دستورات اطلاعات را برای تمامی ریسه‌های pmd در مسیر داده ارائه می‌دهند. با تعیین گزینه "-pmd Core"; می‌توان خروجی را برای یک پردازنده pmd خاص در مسیر داده فیلتر کرد.

اعداد کارایی به ازای هر ریسه pmd را که توسط دستور dpif-netdev/pmd-perf-show نشان داده می‌شوند صفر می‌کند. این دستور آمارهای مسیر داده یا پل را ریست نمی‌کند، و فقط مقادیر نمایش‌داده‌شده توسط دستور فوق را پاک می‌سازد.
سنجه‌های عملکردی تفصیلی را برای یک یا تمام ریسه‌های pmd در مسیر داده فضای کاربری نشان می‌دهد. ریسه ویژه "main" مجموع آمارهای تمام ریسه‌های غیر pmd را جمع‌بندی می‌کند.

جمع‌آوری آمارهای تفصیلی اضافه می‌تواند توسط یک پارامتر پیکربندی به نام other-config:pmd-perf-metrics کنترل شود. این قابلیت به طور پیش‌فرض غیرفعال است. سربار زمان اجرا در هنگام فعال بودن در حدود 1 درصد خواهد بود.

آمارهای گردآوری‌شده عبارتند از:

—
سیکل‌های پردازشی استفاده‌شده (used cycles)
—
بسته‌های هدایت‌شده (forwarded packets)
—
تعداد دسته‌های دریافتی (rx batches)
—
بسته‌ها به ازای هر دسته دریافتی (packets/rx batch)
—
حداکثر سطح پر بودن صف vhostuser
—
تعداد فراخوانی‌های رو به بالا (upcalls)
—
سیکل‌های سپری‌شده در upcallها
این داده‌های خام ثبت‌شده در سه بخش استفاده می‌شوند:
1.
در بافت‌نگارها (هیستوگرام‌ها) برای هر یک از سنجه‌های زیر:
—
سیکل‌ها بر تکرار (لگاریتمی)
—
بسته‌ها بر تکرار (لگاریتمی)
—
سیکل‌ها بر بسته
—
بسته‌ها بر دسته
—
حداکثر طول صف vhostuser (لگاریتمی)
—
فراخوانی‌های رو به بالا (upcalls)
—
سیکل‌ها بر فراخوانی رو به بالا (لگاریتمی) خانه‌های هیستوگرام به صورت خطی یا لگاریتمی تقسیم‌بندی شده‌اند.
2.
تاریخچه دوره‌ای سنجه‌های بالا برای 1024 تکرار.
3.
تاریخچه دوره‌ای مقادیر تجمعی/میانگین به ازای هر میلی‌ثانیه ساعت واقعی برای 1024 میلی‌ثانیه گذشته:
—
تعداد تکرارها
—
میانگین سیکل‌ها بر تکرار
—
بسته‌ها (بر حسب کیلو بسته بر ثانیه - Kpps)
—
میانگین بسته‌ها بر دسته
—
میانگین حداکثر طول صف vhost
—
فراخوانی‌های رو به بالا (upcalls)
—
میانگین سیکل‌ها بر upcall
گزینه‌های دستور عبارتند از:
عدم نمایش بافت‌نگارها (هیستوگرام‌ها)
نمایش آمارهای مربوط به iter_len تکرار اخیر
نمایش آمار میلی‌ثانیه‌ای برای ms_len میلی‌ثانیه اخیر
خروجی همواره شامل آمارهای کلی PMD به شرح زیر است:
Time: 15:24:55.270
Measurement duration: 1.008 s
pmd thread numa_id 0 core_id 1:
  Iterations:              572817  (1.76 us/it)
  - Used TSC cycles:   2419034712  ( 99.9 % of total cycles)
  - idle iterations:       486808  ( 15.9 % of used cycles)
  - busy iterations:        86009  ( 84.1 % of used cycles)
  Rx packets:             2399607  (2381 Kpps, 848 cycles/pkt)
  Datapath passes:        3599415  (1.50 passes/pkt)
  - PHWOL hits:                 0  (  0.0 %)
  - Simple Match hits:          0  (  0.0 %)
  - EMC hits:              336472  (  9.3 %)
  - SMC hits:                   0  (  0.0 %)
  - Megaflow hits:        3262943  ( 90.7 %, 1.00 subtbl lookups/hit)
  - Upcalls:                    0  (  0.0 %, 0.0 us/upcall)
  - Lost upcalls:               0  (  0.0 %)
  Tx packets:             2399607  (2381 Kpps)
  Tx batches:              171400  (14.00 pkts/batch)
در اینجا "Rx packets" در واقع نشان‌دهنده تعداد بسته‌های هدایت‌شده توسط مسیر داده است.

مجموع مقادیر "PHWOL hits"، "Simple Match hits"، "EMC hits"، "SMC hits"، "Megaflow hits" و "Upcalls" بیانگر تعداد جستجوهای بسته انجام‌شده توسط مسیر داده است و به عنوان "Datapath passes" گزارش می‌شود. توجه داشته باشید که یک بسته بازچرخانی‌شده (recirculated) در هر بار بازچرخانی یک جستجوی اضافه را تجربه می‌کند، بنابراین ممکن است تعداد جستجوها از تعداد بسته‌های هدایت‌شده در مسیر داده بیشتر باشد.

عبارت "MFEX Opt hits" تعداد بسته‌هایی را نشان می‌دهد که توسط پیاده‌سازی‌های بهینه‌شده استخراج مینی‌جریان (miniflow extract) پردازش شده‌اند.

شمارش چرخه‌ها با استفاده از TSC یا امکانات مشابه سخت‌افزاری (در صورت در دسترس بودن روی پلتفرم) انجام می‌شود. مدت زمان یک چرخه به بستر پردازشی وابسته است. آمارهای مبتنی بر چرخه برای ریسه "main" گزارش نمی‌شوند، زیرا محاسبه دقیق چرخه‌های پردازنده در این حالت مقدور نیست.

عبارت "idle iterations" به تکرارهای PMD اشاره دارد که منجر به پردازش هیچ بسته‌ای نشده‌اند. عبارت "busy iterations" نشان‌دهنده تکرارهای PMD است که پردازش حداقل یک بسته را در بر داشته‌اند. چرخه‌های مصرفی TSC گزارش‌شده شامل هزینه پولینگ (polling)، پردازش و ارسال بسته‌های یادشده است.

جهت بازنشانی شمارنده‌ها و شروع یک اندازه‌گیری تازه از دستور dpif-netdev/pmd-stats-clear استفاده نمایید.

مسیر داده "netdev" در فضای کاربری قادر است سنجه‌های عملکردی PMD را نظارت کرده و تکرارهای دارای آمارهای مشکوک را بر اساس معیارهای زیر شناسایی کند:
—
تکرار بیش از usec میکروثانیه به درازا بکشد (پیش‌فرض 250). از این ویژگی می‌توان برای ثبت رخدادهایی استفاده کرد که یک PMD برای چنان بازه زمانی مسدود یا متوقف شده است که خطر دور ریخته شدن بسته‌ها روی هر یک از صف‌های دریافت (Rx) آن وجود دارد.
—
حداکثر طول صف vhost از آستانه qlen فراتر رود (پیش‌فرض 128). از این طریق می‌توان سرریز صف‌های virtio و دور ریز بسته‌ها در داخل یک ماشین مجازی را استنباط کرد، که در غیر این صورت در OVS قابل رویت نیستند.
چنین تکرارهای مشکوکی را می‌توان همراه با آمارهای تکرار آن‌ها در فایل ovs-vswitchd.log ثبت کرد تا بتوان آن‌ها را به افت بسته‌ها یا سایر رویدادهای خارج از OVS ربط داد.

دستور فوق نظارت و ثبت وقایع را در زمان اجرا فعال (on) یا غیرفعال (off) می‌کند و می‌تواند برای تنظیم آستانه‌های فوق جهت تشخیص تکرارهای مشکوک به کار رود. نظارت و ثبت وقایع به طور پیش‌فرض غیرفعال است.

گزینه‌های دستور عبارتند از:

تعداد تکرارهای پیش از تکرار مشکوک که باید ثبت شوند (پیش‌فرض 5).
تعداد تکرارهای پس از تکرار مشکوک که باید ثبت شوند (پیش‌فرض 5).
در صورتی که تکرار مشکوک دیگری پیش از وقوع ثبت وقایع شناسایی شود، بازه ثبت را تمدید می‌کند.
در صورت شناسایی تکرار مشکوک دیگر پیش از انجام ثبت، بازه ثبت وقایع را تمدید نمی‌کند (پیش‌فرض).
آستانه پر شدن صف مشکوک vhost. اگر Qemu از طول صف 1024 پشتیبانی می‌کند، این عدد را به 512 افزایش دهید (پیش‌فرض 128).
تغییر آستانه مدت‌زمان برای یک تکرار مشکوک (پیش‌فرض 250 میکروثانیه).

نکته: ثبت لاگ تکرارهای مشکوک به خودی خود بخش قابل توجهی از چرخه‌های پردازشی یک PMD را مصرف می‌کند که ممکن است در تاریخچه تکرارها نمود پیدا کند. در بدترین حالت، این امر می‌تواند باعث شود OVS تکرار مشکوک دیگری را به دلیل خود عملیات ثبت لاگ شناسایی کند.

اگر بیش از 100 تکرار در حوالی یک تکرار مشکوک ثبت شده باشد، OVS به مقادیر ایمن پیش‌فرض بازمی‌گردد (-b 5 -a 5 -ne) تا مانع از آن شود که ثبت وقایع به طور مداوم تکرارهای مشکوک بعدی را تولید کند.

برای یک یا تمامی ریسه‌های pmd در مسیر داده dp، فهرست شناسه‌های صف همراه با نام درگاه‌هایی را که این ریسه آن‌ها را پایش (poll) می‌کند نشان می‌دهد.
صف‌های دریافت (rxqs) را بر اساس میزان مصرف فعلی آن‌ها مجدداً به pmdها در مسیر داده dp اختصاص می‌دهد.
هنگامی که گزینه "other_config:lb-output-action" روی "true" تنظیم شود، مسیر داده فضای کاربری متعادل‌سازی بار پیوندها را مستقیماً انجام می‌دهد به جای اینکه به بازچرخانی جریان متکی باشد (تنها در حالت balance-tcp).

هنگامی که چنین باشد، دستور فوق اطلاعات متعادل‌سازی بار پیوندهای پیکربندی‌شده در مسیر داده dp را چاپ می‌کند و رابط متناظر با هر باکت (هش) را نشان می‌دهد.

از این دستورات برای دسترسی به اطلاعات درونی مسیر داده "dpif-netlink" در فضای هسته استفاده می‌شود.

حالت توزیع ("dispatch-mode") را برای تمام مسیرهای داده نمایش می‌دهد.

این دستورات درگاه‌های مربوط به DPDK را مدیریت می‌کنند (type=dpdk*).

وضعیت مدیریتی رابط DPDK را به up یا down تغییر می‌دهد. اگر interface مشخص نشود، بر تمامی درگاه‌های DPDK اعمال خواهد شد.
دستگاه متناظر با شناسه pci-address را از DPDK جدا می‌سازد. از این دستور می‌توان در حالتی استفاده کرد که دستگاه پس از حذف درگاه به صورت خودکار جدا نشده باشد. برای جزئیات به مستندات برنامه رجوع نمایید.
اطلاعات اشکال‌زدایی مخزن حافظه مورد استفاده رابط DPDK را چاپ می‌کند. اگر بدون آرگومان فراخوانی شود، اطلاعات تمام مخازن حافظه موجود چاپ خواهد شد. برای آمارهای تکمیلی مخزن حافظه، هنگام ساخت DPDK گزینه CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG را فعال نمایید.

این دستورات مسیرهای داده را بررسی و ویرایش می‌کنند. این دستورات مشابه دستورات ovs-dpctl(8) هستند. دستور dpif/show دارای قابلیت اضافه‌ای نسبت به dpctl/show برای چاپ شماره درگاه‌های OpenFlow است. سایر دستورات افزونه و تکراری بوده و در نگارش‌های آینده حذف خواهند شد.

نام هر یک از مسیرهای داده پیکربندی‌شده را در خطی جداگانه چاپ می‌کند.
خلاصه‌ای از مسیرهای داده پیکربندی‌شده شامل آمارها و فهرستی از درگاه‌های متصل را نمایش می‌دهد. اطلاعات درگاه شامل شماره درگاه OpenFlow، شماره درگاه مسیر داده، و نوع آن است. (درگاه محلی به عنوان درگاه OpenFlow شماره 65534 شناخته می‌شود.)
تمامی ورودی‌های جریان موجود در جدول جریان مسیر داده dp را در کنسول چاپ می‌کند. بدون گزینه -m، خروجی فیلدهایی را که یک جریان به طور کامل عام (wildcard) در نظر گرفته است نادیده می‌گیرد؛ با گزینه -m تمام فیلدهای عام نیز نمایش داده می‌شوند.
این دستور در درجه نخست برای اشکال‌زدایی Open vSwitch مفید است. ورودی‌های جدول جریان که در اینجا نشان داده می‌شوند، ورودی‌های جریان OpenFlow نیستند، بلکه جریان‌های ساده‌تر و متفاوتی هستند که توسط ماژول مسیر داده نگهداری می‌شوند. اگر مایل به مشاهده جریان‌های OpenFlow هستید، از دستور ovs-ofctl dump-flows استفاده نمایید.
تمامی ورودی‌های جریان را از جدول جریان مسیر داده dp و پیاده‌سازی زیربنایی مسیر داده (مانند ماژول مسیر داده در هسته) حذف می‌کند.
این دستور اصولاً برای اشکال‌زدایی Open vSwitch به کار می‌رود. همان‌طور که در توضیحات dpif/dump-flows ذکر شد، این ورودی‌ها جریان‌های OpenFlow محسوب نمی‌شوند.

این دستورات پیاده‌سازی هسته سوئیچ OpenFlow (موسوم به ofproto) را مدیریت می‌کنند.

نام نمونه‌های در حال اجرای ofproto را فهرست می‌کند. این‌ها نام‌هایی هستند که می‌توانند در دستور ofproto/trace به کار روند.



مسیر عبور یک بسته فرضی را در داخل switch ردیابی کرده و مسیر طی‌شده توسط آن را گزارش می‌دهد. پردازش اولیه بسته بر اساس دستور انتخابی متفاوت است:
  • دستور ofproto/trace بسته را در جدول جریان OpenFlow جستجو می‌کند، دقیقاً مانند اینکه بسته روی یک درگاه OpenFlow وارد شده باشد.
  • دستور ofproto/trace-packet-out عملیات‌های OpenFlow تعیین‌شده در actions را اعمال می‌کند، درست همان‌گونه که اگر بسته، جریان و عملیات‌ها در یک درخواست ``packet-out'' پروتکل OpenFlow مشخص شده بودند.
سرفصل‌ها یا هدرهای بسته (مانند مبدأ و مقصد) و فراداده آن (مانند درگاه ورودی)، که در مجموع «جریان» یا flow آن نامیده می‌شوند، معمولاً تنها مواردی هستند که به منظور ردگیری بسته اهمیت دارند. جریان را می‌توان به روش‌های زیر تعیین نمود:
مقدار odp_flow جریانی به قالبی است که توسط دستور dump-flows از ابزار ovs-dpctl(8) چاپ می‌شود. اگر همه پل‌های شما دارای نوع یکسانی باشند (که حالت متداول است)، می‌توانید از ذکر dpname صرف‌نظر کنید، اما اگر پل‌هایی از انواع گوناگون دارید (برای نمونه هم ovs-netdev و هم ovs-system)، برای رفع ابهام نیاز به تعیین dpname خواهید داشت.
مقدار br_flow جریانی به فرمی مشابه با ورودی پذیرفته‌شده توسط دستور add-flow در ovs-ofctl(8) است. (این یک جریان OpenFlow نیست: گذشته از تفاوت‌های دیگر، هرگز حاوی عام‌ساز یا wildcard نیست.) مقدار bridge نام پلی است که br_flow باید درون آن ردگیری شود.
این دستورات از گزینه‌های زیر پشتیبانی می‌کنند:
از روی جریان یک بسته تولید می‌کند (برای اطلاعات بیشتر به توضیحات زیر مراجعه نمایید).

تنها همراه با گزینه --generate پذیرفته می‌شود.
تنها توسط دستور ofproto-trace-packet-out پذیرفته می‌شود. با این گزینه، دستور اقداماتی (actions) را که با بسته مشخص‌شده ناسازگار هستند رد می‌کند. (نمونه‌ای از ناسازگاری، تلاش برای حذف برچسب VLAN از بسته‌ای است که برچسب VLAN ندارد.) برنامه Open vSwitch از بیشتر انواع ناسازگاری‌ها در OpenFlow 1.0 چشم‌پوشی می‌کند و ناسازگاری‌ها را در نگارش‌های بعدی OpenFlow رد می‌نماید. این گزینه لازم است زیرا دستور به طور معمول ویرایش خاصی از OpenFlow را تحمیل نمی‌کند. یک استثنا این است که وقتی actions شامل عملیاتی باشد که تنها در OpenFlow 1.1 و نسخه‌های بعدی پشتیبانی می‌شود (مانند push_vlan)، گزینه --consistent به طور خودکار فعال می‌گردد.
هنگامی که جریان ردیابی‌شده موجب راه‌اندازی اقدامات conntrack شود، دستور ofproto/trace به طور خودکار خط‌لوله پردازش بسته منشعب‌شده را با وضعیت ct_state تعیین‌شده از سوی کاربر ردگیری می‌کند. این گزینه پرچم‌های ct_state را که ماژول conntrack گزارش خواهد کرد تعیین می‌نماید. پارامتر flags باید فهرستی از پرچم‌های ردیابی اتصال زیر باشد که با کاما یا فاصله از هم تفکیک شده‌اند:
  • trk: برای نشان دادن اینکه ردیابی اتصال صورت گرفته است.
  • new: برای نشان دادن یک جریان جدید.
  • est: برای نشان دادن یک جریان برقرارشده و تثبیت‌شده.
  • rel: برای نشان دادن یک جریان مرتبط.
  • rpl: برای نشان دادن یک جریان پاسخی (reply flow).
  • inv: برای نشان دادن مدخل اتصال در یک وضعیت نامعتبر.
  • dnat: برای نشان دادن بسته‌ای که نشانی IP مقصد آن تغییر یافته است.
  • snat: برای نشان دادن بسته‌ای که نشانی IP مبدأ آن تغییر یافته است.
هنگامی که --ct-next مشخص نشده باشد، یا تعداد گزینه‌های --ct-next از اقدامات ct کمتر باشد، پرچم‌ها به طور پیش‌فرض روی trk,new قرار می‌گیرند.
در اکثر موارد، کاربر تنها یک جریان را با استفاده از یکی از حالت‌های فوق مشخص می‌کند، اما گاهی ممکن است به جای تنها یک جریان، نیاز به مشخص کردن یک بسته واقعی باشد:
اثرات جانبی (Side effects).
برخی اقدامات دارای اثرات جانبی هستند. برای نمونه، اقدام normal می‌تواند جدول یادگیری MAC را به‌روزرسانی کند، و اقدام learn می‌تواند جداول OpenFlow را تغییر دهد. دستورات trace تنها زمانی اثرات جانبی را اعمال می‌کنند که بسته‌ای واقعی مشخص شده باشد. اگر مایلید اثرات جانبی اعمال شوند، باید یک بسته فراهم کنید.
(اقدامات خروجی مسلماً جزء اثرات جانبی هستند، اما دستورات trace حتی در زمان تعیین بسته واقعی نیز هرگز آن‌ها را اجرا نمی‌کنند.)
اطلاعات ناقص (Incomplete information).
بیشتر اوقات، Open vSwitch می‌تواند همه ابعاد مسیر یک بسته را تنها با استفاده از جریان درک کند، اما در برخی شرایط خاص نیاز است بخش‌هایی از بسته بررسی شوند که در جریان گنجانده نشده‌اند. هنگامی که چنین وضعیتی رخ دهد و شما بسته‌ای ارائه نکرده باشید، دستور trace به شما اطلاع می‌دهد که نیازمند یک بسته است.
اگر می‌خواهید یک بسته را به عنوان بخشی از عملیات trace بگنجانید، دو روش برای این کار وجود دارد:
این گزینه، که به یکی از روش‌های تعیین جریان افزوده می‌شود، باعث می‌شود Open vSwitch به طور درونی بسته‌ای بر مبنای جریان توصیف‌شده ایجاد کرده و سپس از آن استفاده کند. اگر هدف شما اجرای اثرات جانبی باشد، گزینه --generate ساده‌ترین راه برای انجام آن است، اما راهکار مناسبی برای پر کردن اطلاعات ناقص نیست، زیرا بسته را فقط بر پایه اطلاعات جریان تولید می‌کند و بسته هیچ اطلاعات اضافه‌تری نسبت به خود جریان نخواهد داشت.
به طور پیش‌فرض، برای پروتکل‌هایی که محموله L7 دلخواه را مجاز می‌شمارند، بسته تولیدشده دارای 64 بایت محموله است. از --l7-len برای تغییر طول محموله یا از --l7 برای مشخص کردن محتوای دقیق بار داده استفاده کنید.
این روش یک بسته صریح packet را به صورت توالی‌ای از ارقام هگزادسیمال ارائه می‌دهد. یک فریم اترنت حداقل 14 بایت طول دارد، بنابراین باید حداقل 28 رقم هگزادسیمال وجود داشته باشد. بدیهی است که تایپ کردن ارقام هگزادسیمال با دست دشوار است، بنابراین ابزارهای ovs-pcap(1) و ovs-tcpundump(1) روش‌های ساده‌تری برای این کار فراهم می‌سازند.
در این حالت، هدرهای بسته مستقیماً از packet استخراج می‌شوند، بنابراین odp_flow یا br_flow باید فقط حاوی فراداده (metadata) باشند. این فراداده می‌تواند شامل موارد زیر باشد:
اولویت کیفیت خدمات (QoS) بسته.
علامت یا مارک بسته.
وضعیت اتصال بسته.
منطقه ردیابی اتصال برای بسته.
مارک ردیابی اتصال بسته.
برچسب ردیابی اتصال بسته.
شناسه تونلی که بسته از آن وارد شده است.
درگاهی که بسته از آن دریافت شده است.
مقدار in_port برای قالب نخست نشان‌دهنده شماره درگاه مسیر داده در هسته، و برای قالب دوم شماره درگاه OpenFlow است. شماره‌گذاری این دو نوع درگاه معمولاً با یکدیگر متفاوت بوده و ارتباطی میان آن‌ها وجود ندارد.
مثال‌های استفاده:

ردیابی یک درخواست اکوی ICMP تک‌بخشی (unicast) روی درگاه ورودی 1 به مقصد آدرس مک 00:00:5E:00:53:01

ofproto/trace br in_port=1,icmp,icmp_type=8,dl_dst=00:00:5E:00:53:01

ردیابی یک پاسخ اکوی ICMP تک‌بخشی روی درگاه ورودی 1 به مقصد آدرس مک 00:00:5E:00:53:01

ofproto/trace br in_port=1,icmp,icmp_type=0,dl_dst=00:00:5E:00:53:01

ردیابی یک درخواست ARP روی درگاه ورودی 1

ofproto/trace br in_port=1,arp,arp_op=1

ردیابی یک پاسخ ARP روی درگاه ورودی 1

ofproto/trace br in_port=1,arp,arp_op=2

این دستورات تنظیمات ثبت وقایع در ovs-vswitchd را مدیریت می‌کنند.

سطوح ثبت وقایع را تنظیم می‌کند. بدون هیچ پارامتر spec، سطح لاگ را برای تمامی ماژول‌ها و مقصدها روی dbg قرار می‌دهد. در غیر این صورت، spec فهرستی از واژگان است که با فاصله، کاما یا دونقطه از هم جدا شده‌اند، و حداکثر از هر یک از دسته‌های زیر یک مورد را در بر می‌گیرد:
  • یک نام ماژول معتبر، همان‌طور که توسط دستور vlog/list در ovs-appctl(8) نمایش داده می‌شود، تغییر سطح لاگ را به ماژول مشخص‌شده محدود می‌کند.
  • عبارت‌های syslog، console یا file، جهت محدودسازی تغییر سطح ثبت وقایع صرفاً به گزارش سیستم، کنسول یا یک فایل.
  • عبارت‌های off، emer، err، warn، info یا dbg، برای کنترل سطح لاگ. پیام‌های دارای درجه اهمیت مشخص‌شده یا بالاتر ثبت می‌گردند، و پیام‌های با اهمیت کمتر فیلتر خواهند شد. مقدار off تمام پیام‌ها را فیلتر می‌کند. برای مشاهده تعاریف مربوط به هر سطح لاگ به ovs-appctl(8) رجوع فرمایید.
بزرگی یا کوچکی حروف در spec تأثیری ندارد.
صرف‌نظر از سطوح لاگ تنظیم‌شده برای file، ثبت وقایع در فایل صورت نخواهد گرفت مگر آنکه ovs-vswitchd با گزینه --log-file فراخوانی شده باشد.
به منظور حفظ سازگاری با نسخه‌های پیشین OVS، عبارت any به عنوان یک واژه پذیرفته می‌شود اما هیچ تأثیری در عملکرد ندارد.

الگوی ثبت لاگ را برای destination روی pattern قرار می‌دهد. برای شرح قواعد نحوی معتبر pattern به ovs-appctl(8) مراجعه کنید.
ماژول‌های لاگ‌گیری پشتیبانی‌شده و سطوح کنونی آن‌ها را فهرست می‌کند.
الگوهای لاگ‌گیری مورد استفاده برای هر مقصد را فهرست می‌نماید.
باعث می‌شود ovs-vswitchd فایل لاگ خود را، در صورت باز بودن، ببندد. (برای بازگشایی مجدد آن بعداً از vlog/reopen استفاده کنید.)
موجب می‌شود ovs-vswitchd در صورت باز بودن فایل لاگ آن را ببندد و دوباره باز کند. (این دستور پس از چرخش دوره‌ای فایل‌های لاگ مفید است تا از فایل لاگ جدیدی استفاده شود.)
این دستور هیچ تأثیری ندارد مگر آنکه ovs-vswitchd همراه با گزینه --log-file اجرا شده باشد.

به طور پیش‌فرض، ovs-vswitchd نرخی را که طبق آن پیام‌های خاصی ثبت می‌شوند محدود می‌سازد. هنگامی که پیامی با بسامدی فراتر از حد مجاز ظاهر شود، ثبت آن متوقف می‌گردد. این امر موجب صرفه‌جویی در فضای دیسک، خوانایی بهتر گزارش‌ها و افزایش سرعت اجرا می‌شود، اما در برخی مواقع عیب‌یابی نیازمند جزئیات بیشتری است. از این رو، دستور vlog/disable-rate-limit اجازه می‌دهد محدودیت نرخ ثبت در سطح هر ماژول مجزا غیرفعال گردد. یک یا چند نام ماژول را، همان‌گونه که توسط دستور vlog/list فهرست شده‌اند، مشخص نمایید. عدم تعیین هیچ نام ماژول یا استفاده از کلمه کلیدی any محدودیت نرخ را برای تمامی ماژول‌های لاگ غیرفعال می‌سازد.
دستور vlog/enable-rate-limit، که ساختاری همانند vlog/disable-rate-limit دارد، می‌تواند جهت فعال‌سازی دوباره محدودیت نرخی که قبلاً خاموش شده بود به کار رود.

این دستورات میزان مصرف حافظه را گزارش می‌دهند.

برخی آمارهای پایه‌ای درباره مصرف حافظه ovs-vswitchd را نمایش می‌دهد. برنامه ovs-vswitchd همچنین این اطلاعات را اندکی پس از راه‌اندازی و به صورت دوره‌ای با افزایش مصرف حافظه ثبت می‌کند.

این دستورات «شمارنده‌های پوشش» (coverage counters) برنامه ovs-vswitchd را مدیریت می‌کنند که تعداد دفعات وقوع رخدادهای مشخص در طول مدت زمان اجرای دیمن را می‌شمارند. افزون بر این دستورات، زمانی که ovs-vswitchd متوجه شود حلقه اصلی دیمن به طور غیرمعمولی زمان زیادی برای اجرا می‌برد، به طور خودکار مقادیر شمارنده پوشش را در سطح INFO ثبت می‌کند.

شمارنده‌های پوشش در درجه اول برای بررسی کارایی و عیب‌یابی کاربرد دارند.

میانگین نرخ‌ها بر حسب ثانیه را برای چند ثانیه اخیر، دقیقه گذشته و یک ساعت اخیر، به همراه مجموع شمارش تمامی شمارنده‌های پوشش نمایش می‌دهد.
تعداد کل شمارش را برای شمارنده پوشش تعیین‌شده counter نمایش می‌دهد.

این دستورات اجزای تونل OVS را بررسی و ویرایش می‌کنند.

مسیر ip/plen را به جدول مسیریابی vswitchd می‌افزاید. پارامتر output_bridge باید نام پل OVS باشد. این دستور در صورتی مفید است که مسیرهای کش‌شده OVS نادرست به نظر برسند. می‌توان شناسه جدول غیراستانداردی را تعیین کرد، که در این صورت مسیر به آن جدول مسیریابی اضافه می‌شود. در صورت عدم وجود جدول، ساخته خواهد شد.
مسیرهای موجود در جدول مسیریابی OVS را چاپ می‌کند. این شامل مسیرهای کش‌شده از جدول مسیریابی سیستم و مسیرهای پیکربندی‌شده توسط کاربر است. به طور پیش‌فرض، محتویات تمامی جداول پیش‌فرض (local، main، default) نمایش داده می‌شود، مگر اینکه از طریق پارامتر table درخواست دیگری شده باشد. در این حالت محتویات شناسه جدول مشخص یا تمام جداول مسیریابی چاپ خواهد شد.
مسیر ip/plen را از جدول مسیریابی OVS حذف می‌کند. به طور پیش‌فرض جدول مسیریابی استاندارد به کار گرفته می‌شود، یا در صورت ارائه شناسه از طریق پارامتر table، یک جدول سفارشی خاص استفاده خواهد شد.
عملیات جستجوی مسیر را برای آدرس IP مقصد مشخص‌شده در جداول مسیریابی OVS انجام می‌دهد و اطلاعات مسیر منطبق را چاپ می‌کند. جستجو می‌تواند با استفاده از پارامترهای اضافی دقیق‌تر شود: pkt_mark و src.
قواعد مسیریابی در OVS را چاپ می‌کند. این شامل قواعد مسیریابی ذخیره‌شده از پایگاه‌داده خط‌مشی مسیریابی سیستم و قواعد مسیریابی پیکربندی‌شده توسط کاربر است. به طور پیش‌فرض فقط قواعد IPv4 نمایش داده می‌شوند. برای نمایش قواعد IPv6 گزینه -6 الزامی است.
قاعده مسیریابی پیکربندی‌شده توسط کاربر را به vswitchd اضافه می‌کند. این دستور می‌تواند برای ارجاع به جداول مسیریابی غیراستاندارد جهت پیکربندی خط‌مشی‌های پیشرفته مسیریابی، برای نمونه تطبیق بر روی آدرس IP مبدأ، سودمند باشد. اگر اولویت تعیین نشود، کمترین اولویت استفاده‌نشده به صورت خودکار انتخاب خواهد شد. چند قاعده با اولویت یکسان می‌توانند وجود داشته باشند. قواعد پیکربندی‌شده توسط کاربر و قواعد کش‌شده سیستم در کنار یکدیگر همزیستی دارند.
قاعده مسیریابی پیکربندی‌شده توسط کاربر را از vswitchd حذف می‌کند. اگر اولویت مشخص نشود، نخستین قاعده منطبق برای حذف انتخاب خواهد شد.
سامانه OVS حافظه پنهان ARP را با شنود پیام‌ها می‌سازد. این دستور جدول کش ARP را نمایش می‌دهد.
یک ورودی حافظه پنهان ARP را در پل bridge اضافه یا ویرایش می‌کند، که ip را به mac می‌نگارد.
تخلیه جدول ARP.
زمان انقضا و کهنگی (aging) را تغییر می‌دهد. مقادیر پذیرفته‌شده برای seconds بین 1 تا 3600 هستند. ورودی‌های جدید مقدار مشخص‌شده در seconds را دریافت می‌کنند. برای ورودی‌های موجود، زمان کهنگی تنها در صورتی به‌روزرسانی می‌شود که انقضای فعلی بزرگ‌تر از seconds باشد.
اگر بدون آرگومان استفاده شود، مقدار کهنگی فعلی را چاپ می‌کند.
محدوده پورت مبدأ UDP را که برای تونل‌های مبتنی بر UDP استفاده می‌شود تعیین می‌کند؛ مانند VxLAN. در صورت فراخوانی بدون آرگومان، این دستور محدوده جاری مورد استفاده را چاپ می‌نماید.

این بخش جنبه‌هایی از OpenFlow را مستند می‌کند که مشخصات فنی OpenFlow مستندسازی آن‌ها را الزامی کرده است.

مشخصات فنی OpenFlow، نگارش 1.2، بیان می‌کند:

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

سامانه Open vSwitch هیچ‌گونه بافر بسته‌ای را نگهداری نمی‌کند.

مشخصات فنی OpenFlow، نگارش 1.4، بیان می‌کند:

اگر سوئیچ در یک بازه زمانی تعریف‌شده بیش از 1 ثانیه هیچ پیام OFPT_BUNDLE_CONTROL یا OFPT_BUNDLE_ADD_MESSAGE برای یک شناسه بازشده bundle_id دریافت نکند، می‌تواند یک پیام ofp_error_msg با نوع OFPET_BUNDLE_FAILED و کد OFPBFC_TIMEOUT ارسال نماید. اگر سوئیچ به جز درخواست و پاسخ‌های echo در بازه زمانی تعیین‌شده فراتر از 1 ثانیه هیچ پیام جدیدی در یک بسته تغییرات دریافت نکند، می‌تواند یک پیام ofp_error_msg با نوع OFPET_BUNDLE_FAILED و کد OFPBFC_TIMEOUT صادر کند.

سامانه Open vSwitch طول عمر پیش‌فرض بیکاری بسته تغییرات را 10 ثانیه در نظر می‌گیرد. (این مقدار از طریق other-config:bundle-idle-timeout در جدول Open_vSwitch قابل پیکربندی است. جهت جزئیات به ovs-vswitchd.conf.db(5) مراجعه کنید.)

بر این باوریم که این محدودیت‌ها در زمان نگارش این متن دقیق هستند. این محدودیت‌ها بهره‌گیری از مسیر داده ماژول هسته لینوکس را مفروض می‌دانند.

  • برنامه ovs-vswitchd که از طریق ovs-ctl(8) راه‌اندازی شده باشد، محدودیت 65535 توصیف‌کننده فایل را فراهم می‌آورد. محدودیت در تعداد پل‌ها و درگاه‌ها بر اساس میزان در دسترس بودن توصیف‌کننده‌های فایل تعیین می‌شود. با مسیر داده هسته لینوکس، ایجاد یک پل منفرد سه توصیف‌کننده فایل مصرف می‌کند و هر درگاه یک توصیف‌کننده فایل اضافی مصرف می‌نماید. سایر سیستم‌عامل‌ها و بسترها ممکن است محدودیت‌های متفاوتی داشته باشند.
  • تعداد 8192 ورودی یادگیری MAC به ازای هر پل، به صورت پیش‌فرض. (این مقدار از طریق other-config:mac-table-size در جدول Bridge قابل تنظیم است. برای جزئیات به ovs-vswitchd.conf.db(5) مراجعه نمایید.)
  • جریان‌های هسته تنها توسط حافظه در دسترس هسته سیستم‌عامل محدود می‌شوند. کارایی سیستم فراتر از 1,048,576 جریان هسته به ازای هر پل در یک هسته 32 بیتی، و فراتر از 262,144 جریان در یک هسته 64 بیتی افت خواهد کرد. (ovs-vswitchd هرگز نباید مقداری حتی نزدیک به این تعداد جریان را نصب کند.)
  • جریان‌های OpenFlow تنها توسط حافظه در دسترس محدود می‌گردند. کارایی سیستم به طور خطی با تعداد الگوهای عام (wildcard) یکتا تغییر می‌کند. بدین معنا که یک جدول OpenFlow که شامل جریان‌های فراوانی است که همگی بر فیلدهای یکسان و با الگوی مشابه تطبیق می‌یابند زمان جستجوی ثابتی (constant-time) دارد، اما جدولی که حاوی جریان‌های متعدد منطبق بر فیلدهای متفاوت باشد، نیازمند زمان جستجوی متناسب و خطی با تعداد جریان‌ها خواهد بود.
  • حداکثر 255 درگاه به ازای هر پل در پروتکل درخت پوشا 802.1D شرکت می‌کنند.
  • تعداد 32 آینه (mirror) به ازای هر پل.
  • تعداد 15 بایت برای نام یک درگاه، برای درگاه‌هایی که در هسته لینوکس پیاده‌سازی شده‌اند. درگاه‌های پیاده‌سازی‌شده در فضای کاربری، مانند درگاه‌های پچ (patch ports)، این محدودیت طول اختیاری را ندارند. پروتکل OpenFlow نیز نام درگاه‌ها را به 15 بایت محدود می‌کند.

ovs-appctl(8)، ovsdb-server(1).

4.0.0 Open vSwitch