دستورات مدیریت سوئیچ OpenFlow (OpenFlow Switch Management Commands)

این دستورات به ovs-ofctl اجازه می‌دهند تا یک سوئیچ OpenFlow را پایش و مدیریت کند. این برنامه قادر است وضعیت جاری یک سوئیچ، از جمله ویژگی‌ها، پیکربندی، و مدخل‌های جدول را نمایش دهد.

بیشتر این دستورات آرگومانی را می‌پذیرند که روش اتصال به یک سوئیچ OpenFlow را مشخص می‌کند. روش‌های اتصال زیر پشتیبانی می‌شوند:

show switch

اطلاعات مربوط به switch، از جمله اطلاعات جدول‌های جریان و درگاه‌های آن را روی کنسول چاپ می‌کند.

dump-tables switch

آمار هر یک از جدول‌های جریان مورد استفاده توسط switch را روی کنسول چاپ می‌کند.

dump-table-features switch

ویژگی‌های هر یک از جدول‌های جریان مورد استفاده توسط switch را روی کنسول چاپ می‌کند.

dump-table-desc switch

پیکربندی هر یک از جدول‌های جریان مورد استفاده توسط switch را برای OpenFlow 1.4+ روی کنسول چاپ می‌کند.

mod-table switch table setting

این دستور تنظیمات جدول جریان در switch را برای جدول OpenFlow به نام table پیکربندی می‌کند، که ممکن است به صورت یک عدد یا (مگر اینکه --no-names مشخص شده باشد) یک نام بیان شود.

تنظیمات موجود به نسخه OpenFlow مورد استفاده بستگی دارد. فقط در OpenFlow 1.1 و 1.2 (که باید با گزینه -O فعال شوند)، mod-table رفتار سوئیچ را زمانی که هنگام جستجوی بسته در جدول جریان هیچ جریانی یافت نمی‌شود، پیکربندی می‌کند. مقادیر setting زیر در دسترس هستند:

در OpenFlow 1.3 و بالاتر (که باید با گزینه -O فعال شود) و Open vSwitch 2.11 و بالاتر، mod-table می‌تواند نام یک جدول را تغییر دهد:

فقط در OpenFlow 1.4 و بالاتر (که باید با گزینه -O فعال شود)، mod-table رفتار سوئیچ را هنگامی که کنترل‌کننده قصد افزودن یک جریان به جدول جریان پرشده را دارد، پیکربندی می‌کند. مقادیر setting زیر در دسترس هستند:

dump-ports switch [netdev]

آمار دستگاه‌های شبکه مرتبط با switch را روی کنسول چاپ می‌کند. اگر netdev مشخص شده باشد، تنها آمار مربوط به آن دستگاه چاپ خواهد شد. netdev می‌تواند شماره درگاه اختصاص‌یافته در OpenFlow یا نام دستگاه باشد، مانند eth0.

dump-ports-desc switch [port]

اطلاعات دقیق در مورد دستگاه‌های شبکه مرتبط با switch را روی کنسول چاپ می‌کند. برای دریافت اطلاعات یک درگاه خاص، شماره آن را به عنوان port مشخص کنید. در غیر این صورت، اگر port حذف شود، یا اگر به عنوان ANY تعیین شود، تمام درگاه‌ها چاپ می‌شوند. این زیرمجموعه‌ای از اطلاعات ارائه‌شده توسط دستور show است.

اگر اتصال به switch نسخه OpenFlow 1.0، 1.2 یا 1.2 را مذاکره کند، این دستور از یک افزونه OpenFlow استفاده می‌کند که تنها در Open vSwitch (نسخه 1.7 و بالاتر) پیاده‌سازی شده است.

تنها OpenFlow 1.5 و بالاتر از استخراج اطلاعات یک درگاه خاص پشتیبانی می‌کنند. نسخه‌های قبلی OpenFlow همیشه تمام درگاه‌ها را تخلیه می‌کنند.

mod-port switch port action

ویژگی‌های درگاه port در switch را اصلاح می‌کند. port ممکن است شماره یا نام درگاه OpenFlow باشد (مگر اینکه --no-names مشخص شده باشد) یا کلیدواژه LOCAL (روش ارجح برای اشاره به درگاه محلی OpenFlow). آرگومان action می‌تواند هر یک از موارد زیر باشد:

دستور show پیکربندی تغییریافته توسط mod-port را (در میان اطلاعات دیگر) نمایش می‌دهد.

get-frags switch

حالت مدیریت قطعات (fragments) در switch را چاپ می‌کند. برای شرح هر حالت مدیریت قطعات، به set-frags در زیر مراجعه فرمایید.

دستور show نیز حالت مدیریت قطعات را در میان سایر خروجی‌های خود چاپ می‌کند.

set-frags switch frag_mode

نحوه برخورد switch با قطعات IPv4 و IPv6 را پیکربندی می‌کند. گزینه‌های موجود برای frag_mode عبارتند از:

برای روش تطبیق بر اساس اینکه آیا بسته یک قطعه است و بر اساس آفست قطعه آن، به توضیحات ip_frag در ovs-fields(7) مراجعه کنید.

dump-flows switch [flows]

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

به طور پیش‌فرض، ovs-ofctl مدخل‌های جریان را به همان ترتیبی که سوئیچ ارسال می‌کند چاپ می‌نماید، که بعید است شهودی یا یکنواخت باشد. برای کنترل ترتیب نمایش از --sort و --rsort استفاده کنید. گزینه‌های --names/--no-names و --stats/--no-stats نیز قالب‌بندی خروجی را تحت تأثیر قرار می‌دهند. برای اطلاعات بیشتر، توضیحات این گزینه‌ها را در بخش گزینه‌ها در زیر ببینید.

dump-aggregate switch [flows]

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

queue-stats switch [port [queue]]

آمار صف مشخص‌شده queue روی درگاه port در switch را روی کنسول چاپ می‌کند. port می‌تواند یک شماره یا نام درگاه OpenFlow، کلیدواژه LOCAL (روش ارجح برای اشاره به درگاه محلی OpenFlow)، یا کلیدواژه ALL باشد. هر یک از port یا queue یا هر دو ممکن است حذف شوند (یا معادل آن کلیدواژه ALL). اگر هر دو حذف شوند، آمار برای تمام صف‌ها روی همه درگاه‌ها چاپ می‌شود. اگر فقط queue حذف شود، آمار تمام صف‌های موجود در port چاپ می‌شود؛ اگر فقط port حذف شود، آمار برای queue روی تمام درگاه‌هایی که در آن‌ها وجود دارد چاپ می‌شود.

queue-get-config switch [port [queue]]

پیکربندی صف queue روی درگاه port در switch را روی کنسول چاپ می‌کند. اگر port حذف شود یا برابر ANY باشد، صف‌های تمام درگاه‌ها گزارش می‌شود. اگر queue حذف شود یا برابر ANY باشد، تمام صف‌ها گزارش می‌شوند. برای OpenFlow 1.3 و نسخه‌های پیشین، خروجی همیشه تمام صف‌ها را شامل می‌شود و در صورت مشخص شدن queue آن را نادیده می‌گیرد.

این دستور کاربرد محدودی دارد، زیرا درگاه‌ها اغلب هیچ صف پیکربندی‌شده‌ای ندارند و پروتکل OpenFlow تنها اطلاعات بسیار محدودی درباره پیکربندی یک صف ارائه می‌دهد.

dump-ipfix-bridge switch

آمار IPFIX پل را برای switch روی کنسول چاپ می‌کند. اگر IPFIX پل روی switch پیکربندی شده باشد، آمار IPFIX قابل بازیابی است؛ در غیر این صورت پیام خطا چاپ خواهد شد.

این دستور از یک افزونه Open vSwitch استفاده می‌کند که فقط در Open vSwitch 2.6 و بالاتر موجود است.

dump-ipfix-flow switch

آمار IPFIX مبتنی بر جریان را برای switch روی کنسول چاپ می‌کند. اگر IPFIX مبتنی بر جریان روی switch پیکربندی شده باشد، آمار تمام شناسه‌های مجموعه جمع‌آوری‌کننده در switch چاپ می‌شود؛ در غیر این صورت پیام خطا چاپ خواهد شد.

برای جزئیات بیشتر در مورد پیکربندی IPFIX مبتنی بر جریان و شناسه‌های مجموعه جمع‌آوری‌کننده به ovs-vswitchd.conf.db(5) مراجعه کنید.

این دستور از یک افزونه Open vSwitch استفاده می‌کند که فقط در Open vSwitch 2.6 و بالاتر وجود دارد.

ct-flush-zone switch zone

مدخل‌های ردیابی اتصال را در منطقه zone روی switch پاکسازی (flush) می‌کند.

این دستور از یک افزونه Open vSwitch استفاده می‌کند که فقط در Open vSwitch 2.6 و بالاتر وجود دارد.

ct-flush switch [zone=N] [mark=X[/M]] [labels=Y[/N]] [ct-orig-tuple [ct-reply-tuple]]

مدخل‌های اتصال را روی switch بر اساس zone، mark، labels و چندتایی‌های ردیابی اتصال ct-[orig|reply]-tuple پاکسازی می‌کند.

اگر ct-[orig|reply]-tuple ارائه نشود، تمام مدخل‌های اتصال را پاک می‌کند. اگر zone مشخص شده باشد، تنها اتصالات موجود در zone را پاک می‌کند. اگر mark یا labels ارائه شود، تنها مدخل‌هایی را که با mark/labels مشخص مطابقت دارند پاک خواهد کرد.

اگر ct-[orig|reply]-tuple ارائه شود، مدخل اتصال مشخص‌شده توسط ct-[orig|reply]-tuple در zone را پاک می‌کند. منطقه در صورت عدم تعیین، به طور پیش‌فرض 0 است. مقادیر mark و labels در صورت ارائه نشدن به طور پیش‌فرض "0/0" هستند. ردیاب اتصال فضای کاربری نیازمند پاکسازی با چندتایی اصلی پیش از اعمال NAT است و در غیر این صورت یک پیام هشدار ثبت خواهد شد. این چندتایی می‌تواند جزئی باشد و تمام اتصالاتی را که روی فیلدهای مشخص‌شده مطابقت دارند حذف خواهد کرد. به منظور مشخص کردن تنها ct-reply-tuple، یک رشته خالی به عنوان ct-orig-tuple ارائه دهید.

نکته: در حال حاضر برای تطبیق روی ICMP محدودیت وجود دارد؛ برای تطبیق جزئی روی پارامترهای ICMP، چندتایی ct-[orig|reply]-tuple باید شامل IP مبدأ یا مقصد باشد.

یک مثال از ct-[orig|reply]-tuple پروتکل 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"

یک مثال از ct-[orig|reply]-tuple پروتکل IPv6 TCP:

"ct_ipv6_src=fc00::1,ct_ipv6_dst=fc00::2,ct_nw_proto=6,ct_tp_src=1,ct_tp_dst=2"

این دستور از یک افزونه Open vSwitch استفاده می‌کند که فقط در Open vSwitch 3.1 و بالاتر موجود است. پشتیبانی از تطبیق بر روی mark و labels تنها در Open vSwitch 3.3 و بالاتر اضافه شده است.

دستورات جدول جریان سوئیچ OpenFlow (OpenFlow Switch Flow Table Commands)

این دستورات جدول جریان را در یک سوئیچ OpenFlow مدیریت می‌کنند. در هر مورد، flow یک مدخل جریان را در قالبی که در بخش نحو جریان در زیر شرح داده شده مشخص می‌کند، file یک فایل متنی حاوی صفر یا چند جریان با همان نحو (یک جریان در هر خط) است، و گزینه اختیاری --bundle دستور را به صورت یک تراکنش اتمیک منفرد به اجرا درمی‌آورد (به گزینه --bundle در زیر مراجعه فرمایید).

[--bundle] add-flow switch flow

[--bundle] add-flow switch - < file

[--bundle] add-flows switch file

هر یک از مدخل‌های جریان را به جدول‌های switch اضافه می‌کند. هر مشخصه جریان (مثلاً هر خط در file) می‌تواند با یکی از کلیدواژه‌های add، modify، delete، modify_strict یا delete_strict آغاز شود تا مشخص کند که جریان قرار است افزوده، ویرایش یا حذف گردد، و اینکه آیا ویرایش یا حذف دقیق (strict) است یا خیر. برای سازگاری با گذشته، مشخصه جریان فاقد یکی از این کلیدواژه‌ها به عنوان افزودن جریان در نظر گرفته می‌شود. تمام تغییرات جریان به ترتیبی که مشخص شده است اجرا می‌شوند.

[--bundle] [--strict] mod-flows switch flow

[--bundle] [--strict] mod-flows switch - < file

اقدامات (actions) موجود در مدخل‌های جدول‌های switch را که با جریان‌های مشخص‌شده مطابقت دارند، تغییر می‌دهد. با مشخص کردن --strict، نویسه‌های عام برای مقاصد تطبیق فعال در نظر گرفته نمی‌شوند.

[--bundle] del-flows switch

[--bundle] [--strict] del-flows switch [flow]

[--bundle] [--strict] del-flows switch - < file

مدخل‌ها را از جدول جریان switch حذف می‌کند. تنها با آرگومان switch، تمام جریان‌ها را حذف می‌نماید. در غیر این صورت، مدخل‌های جریانی را که با جریان‌های مشخص‌شده مطابقت دارند حذف می‌کند. با استفاده از --strict، نویسه‌های عام برای مقاصد تطبیق فعال در نظر گرفته نمی‌شوند.

[--bundle] [--readd] replace-flows switch file

مدخل‌های جریان را از file (یا در صورت استفاده از - از ورودی استاندارد stdin) خوانده و جدول جریان را از switch استعلام می‌کند. سپس هرگونه تفاوت را اصلاح می‌نماید: جریان‌هایی از file را که در switch وجود ندارند اضافه می‌کند، جریان‌هایی از switch را که در file نیستند حذف می‌کند، و جریان‌هایی را در switch که اقدامات، کوکی، یا مهلت‌های زمانی آن‌ها در file تفاوت دارد به‌روزرسانی می‌کند.

با مشخص کردن --readd، برنامه ovs-ofctl تمام جریان‌های file را اضافه می‌کند، حتی مواردی که با همان اقدامات، کوکی و مهلت زمانی در switch وجود دارند. در OpenFlow 1.0 و 1.1، افزودن مجدد یک جریان همواره شمارنده‌های بسته و بایت جریان را به 0 بازنشانی می‌کند، و در OpenFlow 1.2 و بالاتر، این کار تنها در صورتی رخ می‌دهد که پرچم reset_counts تنظیم شده باشد.

diff-flows source1 source2

مدخل‌های جریان را از source1 و source2 خوانده و تفاوت‌ها را چاپ می‌کند. جریانی که در source1 وجود دارد ولی در source2 نیست با پیشوند - چاپ می‌شود، و جریانی که در source2 هست ولی در source1 وجود ندارد با پیشوند + چاپ می‌گردد. اگر جریانی در هر دو منبع source1 و source2 با اقدامات، کوکی یا مهلت‌های زمانی متفاوتی وجود داشته باشد، آنگاه هر دو نسخه به ترتیب با پیشوندهای - و + چاپ می‌شوند.

هر یک از source1 و source2 ممکن است نام یک فایل یا یک سوئیچ باشند. اگر نامی با / یا . آغاز شود، نام یک فایل تلقی می‌گردد. نامی که شامل : باشد به عنوان یک سوئیچ در نظر گرفته می‌شود. در غیر این صورت، چنانچه فایلی با آن نام موجود باشد یک فایل، و در غیر این صورت یک سوئیچ به شمار می‌آید.

برای این دستور، وضعیت خروج 0 نشان‌دهنده یافت نشدن هیچ تفاوتی است، 1 نشان می‌دهد خطایی رخ داده است، و 2 به این معنی است که تفاوت‌هایی یافت شده است.

packet-out switch packet-out

به switch متصل شده و به آن دستور می‌دهد پیام OpenFlow به نام packet-out را اجرا کند، که همان‌گونه که در بخش نحو خروج بسته (Packet-Out Syntax) تعریف شده است مشخص می‌گردد.

دستورات جدول گروه (Group Table Commands)

این دستورات جدول گروه (group table) را در یک سوئیچ OpenFlow مدیریت می‌کنند. در هر مورد، group یک مدخل گروه را در قالبی که در بخش نحو گروه در زیر توصیف شده است مشخص می‌کند، file یک فایل متنی حاوی صفر یا چند گروه با همان نحو (یک گروه در هر خط) است، و گزینه اختیاری --bundle دستور را به صورت یک تراکنش اتمیک منفرد اجرا می‌نماید (به گزینه --bundle در زیر مراجعه کنید).

دستورات گروه تنها با سوئیچ‌هایی کار می‌کنند که از OpenFlow 1.1 یا بالاتر، یا افزونه‌های گروه Open vSwitch برای OpenFlow 1.0 (اضافه‌شده در Open vSwitch 2.9.90) پشتیبانی نمایند. برای OpenFlow 1.1 یا بالاتر، لازم است این نسخه‌های پروتکل به صراحت در ovs-ofctl (با استفاده از -O) فعال شوند. برای اطلاعات بیشتر، پرسش «Q: What versions of OpenFlow does Open vSwitch support?» را در بخش پرسش‌های متداول Open vSwitch مطالعه فرمایید.

[--bundle] add-group switch group

[--bundle] add-group switch - < file

[--bundle] add-groups switch file

هر یک از مدخل‌های گروه را به جدول‌های switch اضافه می‌کند. هر مشخصه گروه (مانند هر خط در file) می‌تواند با یکی از کلیدواژه‌های add، modify، add_or_mod، delete، insert_bucket یا remove_bucket شروع شود تا مشخص کند آیا یک گروه قرار است اضافه، ویرایش یا حذف شود، یا اینکه یک باکت گروه قرار است افزوده یا حذف گردد. برای سازگاری با گذشته، یک مشخصه گروه فاقد یکی از این کلیدواژه‌ها به عنوان افزودن گروه تلقی می‌شود. تمام تغییرات گروه به ترتیبی که تعیین شده‌اند اجرا می‌شوند.

[--bundle] [--may-create] mod-group switch group

[--bundle] [--may-create] mod-group switch - < file

باکت‌های اقدام را در مدخل‌های جدول‌های switch برای هر مدخل گروه اصلاح می‌کند. اگر یک گروه مشخص‌شده از قبل وجود نداشته باشد، بدون --may-create این دستور هیچ اثری نخواهد داشت؛ با --may-create، یک گروه جدید ایجاد می‌کند. گزینه --may-create از یک افزونه Open vSwitch برای OpenFlow استفاده می‌کند که تنها در Open vSwitch 2.6 و بالاتر پیاده‌سازی شده است.

[--bundle] del-groups switch

[--bundle] del-groups switch [group]

[--bundle] del-groups switch - < file

مدخل‌ها را از جدول گروه switch حذف می‌کند. تنها با آرگومان switch، تمام گروه‌ها را حذف می‌نماید. در غیر این صورت، گروه متناظر با هر مدخل گروه را حذف می‌کند.

[--bundle] insert-buckets switch group

[--bundle] insert-buckets switch - < file

باکت‌هایی را به یک گروه موجود در جدول گروه switch اضافه می‌کند. اگر هیچ command_bucket_id در مشخصه گروه وجود نداشته باشد، تمام باکت‌های گروه حذف می‌شوند.

[--bundle] remove-buckets switch group

[--bundle] remove-buckets switch - < file

باکت‌هایی را از یک گروه موجود در جدول گروه switch حذف می‌کند. اگر هیچ command_bucket_id در مشخصه گروه موجود نباشد، تمام باکت‌های گروه حذف می‌شوند.

dump-groups switch [group]

مدخل‌های گروه در جدول‌های switch را روی کنسول چاپ می‌کند. برای نمایش فقط یک گروه خاص، شماره آن را به عنوان group مشخص کنید. در غیر این صورت، اگر group حذف شود یا ALL مشخص گردد، تمام گروه‌ها چاپ می‌شوند.

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

dump-group-features switch

ویژگی‌های گروه در switch را روی کنسول چاپ می‌کند.

dump-group-stats switch [group]

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

دستورات جدول سنجشگر سوئیچ OpenFlow 1.3+ (OpenFlow 1.3+ Switch Meter Table Commands)

این دستورات جدول سنجشگر (meter table) را در یک سوئیچ OpenFlow مدیریت می‌کنند. در هر مورد، meter یک مدخل سنجشگر را در قالبی که در بخش نحو سنجشگر در زیر شرح داده شده است مشخص می‌کند.

پروتکل OpenFlow 1.3 پشتیبانی از سنجشگرها را معرفی کرد، بنابراین این دستورات فقط با سوئیچ‌هایی کار می‌کنند که از OpenFlow 1.3 یا بالاتر پشتیبانی کنند. لازم است این نسخه‌های پروتکل را به طور صریح در ovs-ofctl (با استفاده از -O) و در خود سوئیچ (با ستون protocols در جدول Bridge) فعال نمایید. برای اطلاعات بیشتر، پرسش «Q: What versions of OpenFlow does Open vSwitch support?» را در بخش پرسش‌های متداول Open vSwitch مطالعه فرمایید.

add-meter switch meter

یک مدخل سنجشگر به جدول‌های switch اضافه می‌کند. نحو meter در بخش نحو سنجشگر در زیر شرح داده شده است.

mod-meter switch meter

یک سنجشگر موجود را اصلاح می‌کند.

del-meters switch [meter]

مدخل‌ها را از جدول سنجشگر switch حذف می‌کند. برای حذف فقط یک سنجشگر خاص، شماره آن را به عنوان meter مشخص کنید. در غیر این صورت، اگر meter حذف شود، یا اگر به عنوان all مشخص گردد، تمام سنجشگرها حذف می‌شوند.

dump-meters switch [meter]

مدخل‌های جدول سنجشگر switch را چاپ می‌کند. برای چاپ فقط یک سنجشگر خاص، شماره آن را به عنوان meter مشخص کنید. در غیر این صورت، اگر meter حذف شود، یا اگر به عنوان all مشخص گردد، تمام سنجشگرها چاپ می‌شوند.

meter-stats switch [meter]

آمار سنجشگر را چاپ می‌کند. آرگومان meter می‌تواند یک سنجشگر منفرد را با نحو meter=id مشخص کند، یا همه سنجشگرها را با نحو meter=all تعیین نماید.

meter-features switch

ویژگی‌های سنجشگر را چاپ می‌کند.

دستور بسته تغییرات سوئیچ OpenFlow (OpenFlow Switch Bundle Command)

به‌روزرسانی‌های تراکنشی را می‌توان همزمان روی هر دو جدول جریان و گروه با دستور bundle انجام داد. آرگومان file یک فایل متنی است که شامل صفر یا چند تغییر جریان (flow mod)، تغییر گروه (group mod) یا ارسال بسته به بیرون (packet-out) با استفاده از نحو جریان، نحو گروه یا نحو خروج بسته است، که هر خط به ترتیب با یکی از کلیدواژه‌های flow، group یا packet-out آغاز می‌شود. کلیدواژه flow ممکن است به صورت اختیاری با یکی از کلیدواژه‌های add، modify، modify_strict، delete یا delete_strict دنبال شود که در صورت ارائه فقط flow، حالت add فرض می‌گردد. به طور مشابه، کلیدواژه group ممکن است به صورت اختیاری با یکی از کلیدواژه‌های add، modify، add_or_mod، delete، insert_bucket یا remove_bucket دنبال شود که در صورت ارائه فقط group، حالت add فرض می‌شود.

bundle switch file

تمام تغییرات جریان و گروه را در file به عنوان یک تراکنش اتمیک منفرد بر روی جدول‌های switch اجرا می‌کند. تمام تغییرات بسته‌بندی‌شده به ترتیبی که تعیین شده‌اند اجرا می‌شوند.

دستورات جدول TLV تونل سوئیچ OpenFlow (OpenFlow Switch Tunnel TLV Table Commands)

سامانه Open vSwitch یک جدول نگاشت بین TLVهای گزینه تونل (تعریف‌شده توسط <class, type, length>) و فیلدهای NXM با نام tun_metadatan (که در آن n از 0 تا 63 متغیر است) نگهداری می‌کند، که می‌توانند برای اهداف تطبیق، اقدامات و غیره به کار گرفته شوند. این جدول TLV می‌تواند برای TLVهای گزینه Geneve یا سایر پروتکل‌های دارای گزینه‌هایی در همان قالب TLV گزینه‌های Geneve استفاده شود. این نگاشت باید صراحتاً توسط کاربر از طریق دستورات زیر تعیین گردد.

یک نگاشت TLV با نحو زیر مشخص می‌شود:
{class=class,type=type,len=length}->tun_metadatan

هنگامی که یک نگاشت گزینه برای یک tun_metadatan مشخص وجود داشته باشد، تطبیق روی فیلد تعریف‌شده امکان‌پذیر می‌شود، مثلاً:

یک نگاشت نباید در حالی که به طور فعال توسط یک جریان در حال استفاده است تغییر کند؛ نتیجه انجام این کار تعریف‌نشده خواهد بود.

این دستورات افزونه‌های Nicira برای OpenFlow هستند و به Open vSwitch نسخه 2.5 یا بالاتر نیاز دارند.

add-tlv-map switch option[,option]...

هر option را به جدول‌های switch اضافه می‌کند. فیلدهای تکراری رد می‌شوند.

del-tlv-map switch [option[,option]]...

هر option را از جدول switch حذف می‌کند، یا در صورتی که هیچ option تعیین نشده باشد تمام نگاشت‌های TLV گزینه را پاک می‌نماید. فیلدهایی که نگاشت نشده‌اند نادیده گرفته می‌شوند.

dump-tlv-map switch

فیلدهای نگاشت‌شده جاری در جدول گزینه سوئیچ و همچنین قابلیت‌های سوئیچ را نمایش می‌دهد.

دستورات پایش سوئیچ OpenFlow (OpenFlow Switch Monitoring Commands)

snoop switch

به switch متصل شده و تمام پیام‌های OpenFlow دریافتی را روی کنسول چاپ می‌کند. بر خلاف سایر دستورات ovs-ofctl، اگر switch نام یک پل باشد، آنگاه دستور snoop به یک سوکت دامنه یونیکس به نام /run/openvswitch/switch.snoop متصل می‌شود. دیمن ovs-vswitchd برای هر پل روی چنین سوکتی گوش فرامی‌دهد و تمام پیام‌های OpenFlow ارسالی یا دریافتی از کنترل‌کننده OpenFlow پیکربندی‌شده‌اش را به آن می‌فرستد. بنابراین، از این دستور می‌توان برای مشاهده فعالیت پروتکل OpenFlow بین یک سوئیچ و کنترل‌کننده آن استفاده کرد.

هنگامی که یک سوئیچ بیش از یک کنترل‌کننده پیکربندی‌شده داشته باشد، تنها ترافیک به مقصد و از مبدأ یک کنترل‌کننده چاپ می‌شود. اگر هیچ‌یک از کنترل‌کننده‌ها به عنوان اولیه یا ثانویه پیکربندی نشده باشند (با استفاده از یک افزونه Nicira برای OpenFlow 1.0 یا 1.1، یا یک درخواست استاندارد در OpenFlow 1.2 یا بالاتر)، یک کنترل‌کننده به طور تصادفی از بین آن‌ها انتخاب می‌شود. اگر یک کنترل‌کننده اولیه وجود داشته باشد، آن انتخاب می‌شود؛ در غیر این صورت، اگر کنترل‌کننده‌هایی وجود داشته باشند که اولیه یا ثانویه نباشند، یکی به دلخواه انتخاب می‌شود؛ در غیر این صورت، یک کنترل‌کننده ثانویه به طور تصادفی انتخاب می‌گردد. این انتخاب یک‌بار در زمان اتصال انجام شده و با تغییر نقش کنترل‌کننده‌ها تغییر نمی‌کند.

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

monitor switch [miss-len] [invalid_ttl] [watch:[spec...]]

به switch متصل شده و تمام پیام‌های OpenFlow دریافتی را روی کنسول چاپ می‌کند. معمولاً switch باید نام یک پل را در پایگاه‌داده ovs-vswitchd مشخص کند. این امکان فقط در OpenFlow 1.0 به عنوان افزونه Nicira در دسترس است.

اگر miss-len ارائه شود، ovs-ofctl یک پیام «تنظیم پیکربندی» (set configuration) در پروتکل OpenFlow در زمان برقراری اتصال ارسال می‌کند که درخواست miss-len بایت از هر بسته‌ای را می‌دهد که با جدول جریان مطابقت ندارد. سامانه Open vSwitch این پیام‌ها و سایر پیام‌های ناهمگام را به اتصال کلاینت ovs-ofctl monitor ارسال نمی‌کند مگر اینکه یک مقدار غیرصفر در این آرگومان مشخص شده باشد. (بنابراین، اگر miss-len مشخص نشود، به طور معمول ترافیک بسیار کمی چاپ خواهد شد.)

اگر invalid_ttl ارسال شود، ovs-ofctl یک پیام «تنظیم پیکربندی» در OpenFlow در زمان برقراری اتصال ارسال می‌کند که درخواست INVALID_TTL_TO_CONTROLLER می‌دهد، تا ovs-ofctl monitor بتواند پیام‌های «packet-in» را هنگامی که TTL در اقدام dec_ttl به صفر می‌رسد دریافت کند. فقط OpenFlow 1.1 و 1.2 از invalid_ttl پشتیبانی می‌کنند؛ Open vSwitch همچنین آن را برای OpenFlow 1.0 به عنوان یک افزونه پیاده‌سازی کرده است.

عبارت watch:[spec...] باعث می‌شود ovs-ofctl یک پیام افزونه Nicira با عنوان «monitor request» در زمان راه‌اندازی اتصال به سوئیچ ارسال کند. این پیام باعث می‌شود سوئیچ اطلاعات مربوط به تغییرات جدول جریان را به محض وقوع ارسال کند. نحو spec زیر که با کاما جدا می‌شوند در دسترس است:

این دستور ممکن است برای اشکال‌زدایی پیاده‌سازی‌های سوئیچ یا کنترل‌کننده مفید باشد. همراه با watch:، به ویژه برای مشاهده نحوه به‌روزرسانی جدول‌های جریان توسط یک کنترل‌کننده سودمند است.

دستورات سوئیچ و کنترل‌کننده OpenFlow (OpenFlow Switch and Controller Commands)

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

probe target

یک پیام منفرد echo-request در OpenFlow به target ارسال کرده و منتظر پاسخ می‌ماند. همراه با گزینه -t یا --timeout، این دستور می‌تواند در حال اجرا بودن یک سوئیچ یا کنترل‌کننده OpenFlow را بررسی کند.

ping target [n]

مجموعه‌ای متشکل از 10 بسته درخواست پژواک (echo request) را به target ارسال کرده و زمان هر پاسخ را می‌سنجد. بسته‌های درخواست پژواک شامل یک هدر OpenFlow به علاوه n بایت (پیش‌فرض: 64) بار داده تصادفی تولیدشده هستند. این دستور تأخیر درخواست‌های منفرد را اندازه‌گیری می‌کند.

benchmark target n count

تعداد count بسته درخواست پژواک که هرکدام شامل یک هدر OpenFlow به همراه n بایت بار داده هستند ارسال کرده و منتظر دریافت هر پاسخ می‌ماند. زمان کل مورد نیاز را گزارش می‌دهد. این معیاری از حداکثر پهنای باند به target برای رفت و برگشت پیام‌های n بایتی است.

سایر دستورات (Other Commands)

ofp-parse file

فایل file (یا در صورت تعیین - از stdin) را به عنوان مجموعه‌ای از پیام‌های OpenFlow در قالب باینری مورد استفاده در اتصال OpenFlow می‌خواند و آن‌ها را روی کنسول چاپ می‌کند. این دستور می‌تواند برای چاپ پیام‌های OpenFlow ضبط‌شده از یک جریان TCP مفید باشد.

ofp-parse-pcap file [port...]

فایل file را که باید در قالب PCAP مورد استفاده ابزارهای ضبط شبکه مانند tcpdump یا wireshark باشد می‌خواند، تمام جریان‌های TCP برای اتصالات OpenFlow را استخراج می‌کند، و پیام‌های OpenFlow موجود در آن اتصالات را در قالب خوانا برای انسان روی خروجی استاندارد stdout چاپ می‌کند.

اتصالات OpenFlow با شماره درگاه TCP متمایز می‌شوند. بسته‌های غیر OpenFlow نادیده گرفته می‌شوند. به طور پیش‌فرض، داده‌های روی درگاه‌های TCP شماره 6633 و 6653 به عنوان OpenFlow در نظر گرفته می‌شوند. برای نادیده گرفتن این پیش‌فرض، یک یا چند آرگومان port را مشخص کنید.

این دستور نمی‌تواند ترافیک رمزگذاری‌شده با SSL/TLS را به صورت مفید چاپ کند. همچنین از IPv6 پشتیبانی نمی‌کند.

نحو جریان (Flow Syntax)

برخی از دستورات ovs-ofctl آرگومانی را می‌پذیرند که یک یا چند جریان را توصیف می‌کند. چنین توصیف‌های جریانی شامل مجموعه‌ای از انتساب‌های field=value هستند که با ویرگول یا فضای خالی از یکدیگر جدا می‌شوند. (قرار دادن فاصله‌ها در توصیف جریان معمولاً نیازمند نقل‌قول است تا از تجزیه توصیف به چندین آرگومان توسط پوسته جلوگیری شود.)

توصیف‌های جریان باید در فرم نرمال (normal form) باشند. این به این معنی است که یک جریان تنها در صورتی می‌تواند مقداری را برای یک فیلد L3 تعیین کند که یک پروتکل خاص L2 را نیز مشخص کرده باشد، و یک جریان تنها در صورتی می‌تواند یک فیلد L4 را تعیین کند که انواع پروتکل خاص L2 و L3 را نیز تعیین نموده باشد. به عنوان مثال، اگر نوع پروتکل L2 به نام dl_type دارای نویسه عام (wildcard) باشد، آنگاه فیلدهای L3 شامل nw_src، nw_dst و nw_proto نیز باید دارای نویسه عام باشند. به طور مشابه، اگر dl_type یا nw_proto (نوع پروتکل L3) دارای نویسه عام باشد، فیلدهای L4 شامل tcp_dst و tcp_src نیز باید عام باشند. برنامه ovs-ofctl در مورد جریان‌هایی که در فرم نرمال نیستند هشدار خواهد داد.

صفحه راهنمای ovs-fields(7) فیلدهای پشتیبانی‌شده و نحوه تطبیق آن‌ها را شرح می‌دهد. علاوه بر فیلدهای تطبیق، دستوراتی که روی جریان‌ها عمل می‌کنند چند جفت کلید-مقدار اضافی را نیز می‌پذیرند:

table=table

برای دستورات استخراج جریان، جریان‌های استخراج‌شده را به جریان‌های موجود در جدول table محدود می‌کند، که می‌تواند به صورت یک عدد بین 0 و 255 یا (مگر اینکه --no-names مشخص شده باشد) یک نام بیان شود. اگر مشخص نشود (یا اگر 255 به عنوان table مشخص گردد)، آنگاه جریان‌های موجود در تمام جدول‌ها استخراج می‌شوند.

برای دستورات اصلاح جدول جریان، رفتار بر اساس نسخه OpenFlow مورد استفاده برای اتصال به سوئیچ متغیر است:

duration=...

n_packet=...

n_bytes=...

برنامه ovs-ofctl انتساب‌ها به این «فیلدها» را نادیده می‌گیرد تا امکان استفاده از خروجی دستور dump-flows به عنوان ورودی برای سایر دستورات تجزیه‌کننده جریان فراهم باشد.

دستورات add-flow، add-flows و mod-flows به یک فیلد اضافی نیاز دارند که باید آخرین فیلد مشخص‌شده باشد:

actions=[action][,action...]

فهرستی از اقدامات جداشده با کاما را مشخص می‌کند که هنگام مطابقت مدخل جریان باید روی بسته انجام شوند. اگر هیچ action تعیین نشود، بسته‌های منطبق با جریان دور ریخته می‌شوند. برای جزئیات مربوط به نحو و معنای اقدامات به ovs-actions(7) مراجعه فرمایید.

از یک شناسه مات به نام کوکی (cookie) می‌توان به عنوان دستگیره‌ای برای شناسایی مجموعه‌ای از جریان‌ها استفاده کرد:

cookie=value

می‌توان با استفاده از دستورات add-flow، add-flows و mod-flows یک کوکی را با یک جریان مرتبط ساخت. مقدار value می‌تواند هر عدد 64 بیتی باشد و نیازی نیست در میان جریان‌ها یکتا باشد. اگر این فیلد حذف شود، مقدار پیش‌فرض کوکی برابر با 0 استفاده می‌شود.

cookie=value/mask

هنگام استفاده از NXM، کوکی می‌تواند به عنوان دستگیره‌ای برای پرس‌وجو، ویرایش و حذف جریان‌ها به کار رود. مقادیر value و mask می‌توانند برای دستورات del-flows، mod-flows، dump-flows و dump-aggregate برای محدود کردن کوکی‌های منطبق ارائه شوند. بیت 1 در mask نشان می‌دهد که بیت متناظر در cookie باید دقیقاً مطابقت داشته باشد، و بیت 0 آن بیت را عام در نظر می‌گیرد. ماسک -1 می‌تواند برای تطبیق دقیق کوکی استفاده شود.

دستور mod-flows می‌تواند کوکی‌های جریان‌های منطبق با یک کوکی را با تعیین دو بار فیلد cookie به‌روزرسانی کند (یک بار همراه با ماسک برای تطبیق و یک بار بدون ماسک برای نشان دادن مقدار جدید):

قابلیت تطبیق روی کوکی‌ها در Open vSwitch 1.5.0 افزوده شد.

فیلد اضافی زیر اولویت جریان‌های اضافه‌شده توسط دستورات add-flow و add-flows را تعیین می‌کند. برای mod-flows و del-flows هنگامی که --strict مشخص شده باشد، اولویت باید همراه با سایر مشخصات جریان مطابقت داشته باشد. برای mod-flows بدون --strict، اولویت تنها در صورتی مهم است که دستور یک جریان جدید ایجاد کند، یعنی mod-flows غیر دقیق بر اساس اولویت تطبیق نمی‌دهد و اولویت جریان‌های موجود را تغییر نخواهد داد. سایر دستورات اجازه تعیین اولویت را نمی‌دهند.

priority=value

اولویت تطبیق یک مدخل دارای نویسه عام را در مقایسه با سایرین مشخص می‌کند. مقدار value عددی بین 0 و 65535 (شامل هر دو) است. یک value بالاتر پیش از مقدار پایین‌تر مطابقت داده خواهد شد. مدخلی با تطبیق دقیق همیشه بر مدخل حاوی نویسه‌های عام اولویت دارد، بنابراین دارای مقدار اولویت ضمنی 65535 است. هنگام افزودن یک جریان، اگر فیلد مشخص نشود، اولویت جریان به طور پیش‌فرض 32768 خواهد بود.

پروتکل OpenFlow زمانی که دو یا چند جریان با اولویت یکسان بتوانند با یک بسته منفرد مطابقت پیدا کنند، رفتار را نامشخص رها می‌کند. برخی از کاربران انتظار رفتار «معقول» دارند، مانند اینکه جریان‌های مشخص‌تر بر جریان‌های عام‌تر اولویت داشته باشند، اما OpenFlow این را مشخص نکرده و Open vSwitch آن را پیاده‌سازی نمی‌کند. بنابراین کاربران باید دقت کنند که از اولویت‌ها برای اطمینان از رفتاری که انتظار دارند استفاده نمایند.

دستورات add-flow، add-flows و mod-flows از گزینه‌های اضافی زیر پشتیبانی می‌کنند. این گزینه‌ها تنها بر جریان‌های جدید تأثیر می‌گذارند. بنابراین، برای add-flow و add-flows این گزینه‌ها همیشه مهم هستند، اما برای mod-flows آن‌ها تنها در صورتی مهم هستند که دستور جریان جدیدی ایجاد کند، به این معنی که مقادیر آن‌ها جریان‌های موجود را به‌روزرسانی نکرده و تحت تأثیر قرار نمی‌دهد.

idle_timeout=seconds

باعث انقضای جریان پس از تعداد ثانیه‌های عدم فعالیت داده‌شده می‌شود. مقدار 0 (پیش‌فرض) از انقضای جریان به دلیل عدم فعالیت جلوگیری می‌کند.

hard_timeout=seconds

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

importance=value

میزان اهمیت یک جریان را تعیین می‌کند. سازوکار اخراج مدخل جریان می‌تواند از اهمیت به عنوان عاملی در تصمیم‌گیری برای اخراج جریان استفاده کند. مقدار 0 (پیش‌فرض) جریان را بر اساس اهمیت غیرقابل اخراج می‌سازد. مقداری بین 0 تا 65535 مشخص کنید.

تنها OpenFlow 1.4 و بالاتر از importance پشتیبانی می‌کنند.

send_flow_rem

جریان را با پرچمی علامت‌گذاری می‌کند که باعث می‌شود وقتی جریان بعداً منقضی یا حذف شد، سوئیچ یک پیام «flow removed» تولید کرده و آن را به کنترل‌کننده‌های علاقه‌مند ارسال کند.

check_overlap

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

reset_counts

هنگامی که این پرچم روی جریانی که به سوئیچ اضافه می‌شود مشخص گردد و سوئیچ از قبل جریانی با تطبیق یکسان داشته باشد، یک سوئیچ OpenFlow 1.2 (یا بالاتر) شمارنده‌های بسته و بایت جریان را به 0 بازنشانی می‌کند. بدون این پرچم، شمارنده‌های بسته و بایت حفظ می‌شوند.

سوئیچ‌های OpenFlow 1.0 و 1.1 همیشه در این شرایط شمارنده‌ها را بازنشانی می‌کنند، گویی reset_counts همیشه مشخص شده است.

سامانه Open vSwitch نسخه 1.10 پشتیبانی از reset_counts را اضافه کرد.

no_packet_counts

no_byte_counts

افزودن این پرچم‌ها به یک جریان، به یک سوئیچ OpenFlow 1.3 (یا بالاتر) اعلام می‌کند که کنترل‌کننده به ترتیب نیازی به شمارنده‌های بسته یا بایت برای این جریان ندارد. برخی از پیاده‌سازی‌های سوئیچ ممکن است در زمان استفاده از این پرچم‌ها به عملکرد بالاتر دست یابند یا مصرف منابع را کاهش دهند. این پرچم‌ها هیچ مزیتی برای پیاده‌سازی سوئیچ نرم‌افزاری Open vSwitch ندارند.

پروتکل OpenFlow 1.2 و قبل از آن از این پرچم‌ها پشتیبانی نمی‌کنند.

سامانه Open vSwitch نسخه 1.10 پشتیبانی از no_packet_counts و no_byte_counts را افزود.

دستورات dump-flows، dump-aggregate، del-flow و del-flows از این فیلدهای اختیاری اضافی پشتیبانی می‌کنند:

out_port=port

در صورت تنظیم، یک جریان منطبق باید شامل یک اقدام خروجی به port باشد که باید شماره یا نام یک درگاه OpenFlow باشد (مثلاً local).

out_group=group

در صورت تنظیم، یک جریان منطبق باید شامل یک اقدام group با نام group باشد که باید یک شماره گروه OpenFlow باشد. این فیلد در Open vSwitch 2.5 و بالاتر پشتیبانی می‌شود و به OpenFlow 1.1 یا بالاتر نیاز دارد.

خروجی مدخل‌های جدول (Table Entry Output)

دستورات dump-tables و dump-aggregate اطلاعات مربوط به مدخل‌های موجود در جدول‌های یک مسیر داده را چاپ می‌کنند. هر خط خروجی یک مدخل جریان است که در نحو جریان در بالا توصیف شد، به همراه چند فیلد اضافی:

duration=secs

مدت زمانی، بر حسب ثانیه، که مدخل در جدول بوده است. مقدار secs شامل بیشترین دقتی است که سوئیچ ارائه می‌دهد، که احتمالاً با دقت نانوثانیه است.

n_packets

تعداد بسته‌هایی که با این مدخل مطابقت داشته‌اند.

n_bytes

تعداد کل بایت‌های حاصل از بسته‌هایی که با این مدخل مطابقت یافته‌اند.

فیلدهای اضافی زیر تنها در صورتی گنجانده می‌شوند که سوئیچ Open vSwitch 1.6 یا بالاتر باشد و از قالب جریان NXM برای استخراج جریان استفاده شود (توضیحات گزینه --flow-format در زیر را ببینید). مقادیر این فیلدهای اضافی تنها تقریب هستند و به ویژه مقدار idle_age گاهی حتی برای جریان‌های شلوغ نیز غیرصفر می‌شود.

hard_age=secs

تعداد ثانیه‌های صحیح سپری‌شده از زمان افزودن یا ویرایش جریان. مقدار hard_age تنها در صورتی نمایش داده می‌شود که با بخش صحیح duration تفاوت داشته باشد. (این فیلد از duration جدا است زیرا mod-flows تایمر hard_timeout را بدون صفر کردن duration مجدداً راه‌اندازی می‌کند.)

idle_age=secs

تعداد ثانیه‌های صحیح سپری‌شده بدون عبور هیچ بسته‌ای از این جریان.

نحو خروج بسته (Packet-Out Syntax)

دستور ovs-ofctl bundle اجازه می‌دهد پیام‌های packet-out در فایل بسته مشخص شوند. هر packet-out شامل مجموعه‌ای از انتساب‌های field=value است که با ویرگول یا فضای خالی از هم جدا شده‌اند. (قرار دادن فاصله‌ها درون توصیف packet-out معمولاً نیازمند نقل‌قول است تا از شکسته شدن توصیف به چندین آرگومان توسط پوسته جلوگیری شود.) مگر اینکه خلاف آن ذکر شده باشد، تنها آخرین نمونه از هر فیلد لحاظ می‌شود. همین نحو توسط دستور ovs-ofctl packet-out نیز پشتیبانی می‌گردد.

in_port=port

شماره درگاهی که هنگام پردازش اقدامات به عنوان in_port در نظر گرفته می‌شود. این می‌تواند هر شماره درگاه معتبر OpenFlow یا هر یک از موارد LOCAL، CONTROLLER یا NONE باشد. این فیلد الزامی است.

pipeline_field=value

به صورت اختیاری، کاربر می‌تواند فهرستی از فیلدهای خط لوله (pipeline fields) را برای یک پیام packet-out مشخص کند. فیلدهای خط لوله پشتیبانی‌شده شامل فیلدهای تونل و فیلدهای ثبات همان‌طور که در ovs-fields(7) تعریف شده است، می‌باشند.

packet=hex-string

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

actions=[action][,action...]

نحو اقدامات با فیلد actions= که در نحو جریان در بالا توضیح داده شد یکسان است. تعیین actions= اختیاری است، اما حذف اقدامات به عنوان دور انداختن (drop) تفسیر می‌شود، بنابراین بسته به هیچ مقصدی از سوئیچ ارسال نخواهد شد. فیلد actions باید در انتهای هر خط مشخص شود، مشابه با تغییرات جریان.

نحو گروه (Group Syntax)

برخی از دستورات ovs-ofctl آرگومانی را می‌پذیرند که یک گروه یا گروه‌هایی را توصیف می‌کند. چنین توصیف‌هایی شامل مجموعه‌ای از انتساب‌های field=value هستند که با کاما یا فضای خالی از هم جدا شده‌اند. (قرار دادن فاصله درون توصیف گروه معمولاً نیازمند نقل‌قول است تا از شکسته شدن توصیف به چندین آرگومان توسط پوسته جلوگیری شود.) مگر اینکه خلاف آن ذکر شده باشد، تنها آخرین نمونه از هر فیلد لحاظ می‌گردد.

group_id=id

شناسه صحیح گروه. هنگامی که این فیلد در del-groups یا dump-groups مشخص شود، می‌توان از کلیدواژه "all" برای تعیین همه گروه‌ها استفاده کرد. این فیلد الزامی است.

type=type

نوع گروه. دستورات add-group، add-groups و mod-groups به این فیلد نیاز دارند. استفاده از آن برای سایر دستورات ممنوع است. کلیدواژه‌های زیر انواع مجاز را تعیین می‌کنند:

command_bucket_id=id

باکتی که عملیات باید روی آن انجام شود. دستورات insert-buckets و remove-buckets به این فیلد نیاز دارند. برای سایر دستورات ممنوع است. مقدار id می‌تواند یک عدد صحیح یا یکی از کلیدواژه‌های زیر باشد:

اگر id یک عدد صحیح باشد، باید متناظر با bucket_id یک باکت موجود در گروه باشد. در مورد دستور insert-buckets، اثر آن درج باکت‌ها دقیقاً پیش از باکتی در گروه است که شناسه bucket_id آن برابر id باشد. در مورد دستور remove-buckets، اثر آن حذف باکتی در گروه است که شناسه bucket_id آن برابر id باشد. چنانچه هیچ باکتی در گروه وجود نداشته باشد که شناسه bucket_id آن برابر id باشد، این یک خطا محسوب می‌شود.

selection_method=method

روش انتخاب مورد استفاده برای برگزیدن یک باکت برای گروه نوع select. این یک رشته با طول 1 تا 15 بایت است که برای لایه‌های پایین‌تر شناخته شده است. این فیلد برای دستورات add-group، add-groups و mod-group روی گروه‌های از نوع select اختیاری است و در غیر این صورت ممنوع می‌باشد. اگر هیچ روش انتخابی مشخص نشود، Open vSwitch تا نگارش 2.9 روش hash را با فیلدهای پیش‌فرض اعمال می‌کند. از نسخه 2.10 به بعد، Open vSwitch به طور پیش‌فرض از روش dp_hash با الگوریتم هش متقارن L3/L4 استفاده می‌کند، تا زمانی که بتوان باکت‌های وزن‌دار گروه را با دقت کافی به مقادیر dp_hash نگاشت کرد. در نسخه 2.10 این محدودیت حداکثر به 64 باکت منحصر بود، و در نسخه 2.17 به 256 باکت ارتقا یافت. در آن موارد نادر، Open vSwitch 2.10 و بعد از آن به روش hash با مجموعه پیش‌فرض فیلدهای هش بازمی‌گردند.

این گزینه از یک افزونه Netronome OpenFlow استفاده می‌کند که تنها هنگام استفاده از Open vSwitch 2.4 و بالاتر با OpenFlow 1.5 و بالاتر پشتیبانی می‌شود.

selection_method_param=param

یک پارامتر عدد صحیح 64 بیتی برای روش انتخاب انتخاب‌شده توسط فیلد selection_method. کاربرد این پارامتر توسط لایه پایینی که selection_method را پیاده‌سازی می‌کند تعریف می‌شود. اگر فیلد selection_method به عنوان یک رشته غیرخالی تعیین شده باشد اختیاری است؛ در غیر این صورت ممنوع است. مقدار پیش‌فرض صفر است.

این گزینه از یک افزونه Netronome OpenFlow استفاده می‌کند که تنها هنگام استفاده از Open vSwitch 2.4 و بالاتر با OpenFlow 1.5 و بالاتر پشتیبانی می‌شود.

fields=field

fields(field[=mask]...)

پارامترهای فیلد برای روش انتخاب مشخص‌شده توسط فیلد selection_method. نحو در بخش نحو جریان با این محدودیت‌های اضافی شرح داده شده است که اگر مقداری ارائه شود، به عنوان ماسک نویسه عام در نظر گرفته می‌شود و ماسک‌های نویسه عام پس از یک اسلش ممنوع هستند. پیش‌نیازهای فیلدها باید توسط هر جریانی که خروجی آن به گروه هدایت می‌شود تأمین گردد. کاربرد فیلدها توسط لایه پایینی که selection_method را پیاده‌سازی می‌کند تعریف می‌شود. اگر فیلد selection_method برابر با «hash» تعیین شده باشد این پارامترها اختیاری هستند، و در غیر این صورت ممنوع می‌باشند. حالت پیش‌فرض عدم وجود هیچ فیلدی است.

این گزینه از یک افزونه Netronome OpenFlow استفاده می‌کند که تنها هنگام استفاده از Open vSwitch 2.4 و بالاتر با OpenFlow 1.5 و بالاتر پشتیبانی می‌شود.

bucket=bucket_parameters

دستورات add-group، add-groups و mod-group حداقل به یک فیلد باکت نیاز دارند. فیلدهای باکت باید پس از تمام فیلدهای دیگر ظاهر شوند. برای تعیین چندین باکت از چندین فیلد باکت استفاده می‌شود. ترتیبی که باکت‌ها مشخص می‌شوند متناظر با ترتیب آن‌ها در گروه است. اگر نوع گروه "indirect" باشد، تنها یک گروه ممکن است تعیین شود. پارامتر bucket_parameters شامل فهرستی از انتساب‌های field=value است که با کاما یا فضای خالی از هم جدا شده و به دنبال آن‌ها فهرستی از اقدامات جداشده با کاما می‌آید. فیلدهای مربوط به bucket_parameters عبارتند از:

نحو سنجشگر (Meter Syntax)

دستورات جدول سنجشگر آرگومانی را می‌پذیرند که یک سنجشگر را توصیف می‌کند. چنین توصیف‌هایی شامل مجموعه‌ای از انتساب‌های field=value هستند که با ویرگول یا فضای خالی از یکدیگر جدا می‌شوند. (قرار دادن فاصله‌ها در توصیف سنجشگر معمولاً نیازمند نقل‌قول است تا از تجزیه توصیف به چندین آرگومان توسط پوسته جلوگیری شود.) مگر اینکه خلاف آن ذکر شده باشد، تنها آخرین نمونه از هر فیلد لحاظ می‌شود.

meter=id

شناسه سنجشگر. یک عدد صحیح برای مشخص کردن یک سنجشگر تعریف‌شده توسط کاربر استفاده می‌شود. علاوه بر این، کلیدواژه‌های "all"، "controller" و "slowpath" نیز به عنوان سنجشگرهای مجازی پشتیبانی می‌شوند. سنجشگرهای مجازی "controller" و "slowpath" به ترتیب برای بسته‌های ارسال‌شده به کنترل‌کننده و به فضای کاربری OVS اعمال می‌گردند.

هنگامی که این فیلد در del-meter، dump-meter یا meter-stats مشخص شود، می‌توان از کلیدواژه "all" برای اشاره به تمام سنجشگرها استفاده کرد. این فیلد الزامی است، به جز برای meter-stats که در صورت عدم تعیین این فیلد، تمام آمارها را استخراج و چاپ می‌کند.

kbps

pktps

واحد پارامترهای باند rate و burst_size. عبارت kbps نشان‌دهنده کیلوبیت بر ثانیه، و pktps نشان‌دهنده بسته بر ثانیه است. تعیین واحد برای دستورات add-meter و mod-meter الزامی است.

burst

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

stats

در صورت تنظیم، جمع‌آوری آمار سنجشگر و باند را فعال می‌سازد.

bands=band_parameters

دستورات add-meter و mod-meter حداقل به یک مشخصه باند نیاز دارند. باندها باید پس از تمام فیلدهای دیگر ظاهر شوند.

گزینه‌های دیمن (Daemon Options)

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

--pidfile[=pidfile]

باعث می‌شود فایلی (به طور پیش‌فرض ovs-ofctl.pid) ایجاد شود که نشان‌دهنده PID فرآیند در حال اجرا است. اگر آرگومان pidfile مشخص نشده باشد، یا اگر با / آغاز نشود، در مسیر /run/openvswitch ایجاد می‌شود.

اگر --pidfile مشخص نشود، هیچ فایل pidfile ایجاد نمی‌شود.

--overwrite-pidfile

به طور پیش‌فرض، هنگامی که --pidfile مشخص شده باشد و فایل pidfile مشخص‌شده از قبل وجود داشته و توسط یک فرآیند در حال اجرا قفل شده باشد، ovs-ofctl از شروع به کار خودداری می‌کند. مشخص کردن --overwrite-pidfile باعث می‌شود تا به جای آن روی pidfile بازنویسی شود.

هنگامی که --pidfile مشخص نشده باشد، این گزینه هیچ اثری ندارد.

--detach

برنامه ovs-ofctl را به عنوان یک فرآیند پس‌زمینه اجرا می‌کند. فرآیند فورک می‌شود، و در فرآیند فرزند یک نشست جدید آغاز می‌کند، توصیف‌کننده‌های استاندارد فایل را می‌بندد (که اثر جانبی آن غیرفعال شدن ثبت وقایع در کنسول است)، و دایرکتوری کاری جاری خود را به دایرکتوری ریشه تغییر می‌دهد (مگر اینکه --no-chdir مشخص شده باشد). پس از اینکه فرآیند فرزند مقداردهی اولیه خود را به پایان رساند، فرآیند والد خارج می‌شود. ovs-ofctl تنها هنگام اجرای دستورات monitor یا snoop در پس‌زمینه قرار می‌گیرد.

--monitor

یک فرآیند اضافی برای نظارت بر دیمن ovs-ofctl ایجاد می‌کند. اگر دیمن به دلیل سیگنالی که نشان‌دهنده خطای برنامه‌نویسی است (SIGABRT، SIGALRM، SIGBUS، SIGFPE، SIGILL، SIGPIPE، SIGSEGV، SIGXCPU یا SIGXFSZ) متوقف شود، آنگاه فرآیند ناظر نسخه جدیدی از آن را راه‌اندازی می‌کند. اگر دیمن از بین برود یا به دلیل دیگری خارج شود، فرآیند ناظر نیز پایان می‌یابد.

این گزینه معمولاً همراه با --detach استفاده می‌شود، اما بدون آن نیز کار می‌کند.

--no-chdir

به طور پیش‌فرض، هنگامی که --detach مشخص شده باشد، ovs-ofctl پس از جدا شدن، دایرکتوری کاری جاری خود را به دایرکتوری ریشه تغییر می‌دهد. در غیر این صورت، فراخوانی ovs-ofctl از یک دایرکتوری که با بی‌دقتی انتخاب شده باشد مانع از این می‌شود که مدیر سیستم بتواند سیستم‌فایلی را که آن دایرکتوری را در بر دارد جدا (unmount) کند.

مشخص کردن --no-chdir این رفتار را متوقف کرده و مانع تغییر دایرکتوری کاری جاری توسط ovs-ofctl می‌شود. این ویژگی ممکن است برای جمع‌آوری فایل‌های core مفید باشد، زیرا رفتار معمول این است که رونوشت‌های حافظه (core dumps) در دایرکتوری کاری جاری نوشته شوند و دایرکتوری ریشه گزینه مناسبی برای این منظور نیست.

این گزینه هنگامی که --detach مشخص نشده باشد هیچ اثری ندارد.

--no-self-confinement

به طور پیش‌فرض، دیمن تلاش می‌کند تا خود را برای کار با فایل‌های زیر دایرکتوری‌های شناخته‌شده‌ای که در زمان ساخت تعیین شده‌اند محدود سازد. بهتر است به این رفتار پیش‌فرض پایبند باشید و از این پرچم استفاده نکنید مگر اینکه سیستم کنترل دسترسی دیگری برای محدودسازی دیمن به کار گرفته شده باشد. توجه داشته باشید که برخلاف سایر پیاده‌سازی‌های کنترل دسترسی که معمولاً از فضای هسته اعمال می‌شوند (مانند DAC یا MAC)، خود‌محدودسازی از سمت خود دیمن در فضای کاربری اعمال می‌شود و بنابراین نباید به عنوان یک راهبرد مهار کامل نگریسته شود، بلکه باید به عنوان یک لایه امنیتی افزوده در نظر گرفته شود.

--user

باعث می‌شود ovs-ofctl به عنوان کاربر متفاوتی که در قالب "user:group" تعیین شده اجرا شود، و در نتیجه بیشتر امتیازات ریشه را کنار بگذارد. فرم‌های کوتاه "user" و ":group" نیز مجاز هستند که به ترتیب برای کاربر یا گروه جاری لحاظ می‌شوند. تنها دیمن‌هایی که توسط کاربر ریشه راه‌اندازی شده باشند این آرگومان را می‌پذیرند.

در لینوکس، پیش از واگذاری امتیازات ریشه، قابلیت‌های CAP_IPC_LOCK و CAP_NET_BIND_SERVICES به دیمن‌ها اعطا خواهد شد. دیمن‌هایی که با یک مسیر داده تعامل دارند، مانند ovs-vswitchd، سه قابلیت دیگر یعنی CAP_NET_ADMIN، CAP_NET_BROADCAST و CAP_NET_RAW را نیز دریافت می‌کنند. تغییر قابلیت‌ها حتی در صورتی که کاربر جدید ریشه باشد اعمال خواهد شد.

--unixctl=socket

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

مشخص کردن none برای socket ویژگی سوکت کنترلی را غیرفعال می‌سازد.

گزینه‌های زیرساخت کلید عمومی (Public Key Infrastructure Options)

-p privkey.pem

--private-key=privkey.pem

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

-c cert.pem

--certificate=cert.pem

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

-C cacert.pem

--ca-cert=cacert.pem

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

-C none

--ca-cert=none

تأیید اعتبار گواهی‌های ارائه‌شده توسط همتایان SSL/TLS را غیرفعال می‌کند. این یک خطر امنیتی ایجاد می‌کند، زیرا به این معنی است که گواهی‌ها را نمی‌توان برای اطمینان از تعلق آن‌ها به میزبان‌های معتمد شناخته‌شده تأیید کرد.

--ssl-server-name=servername

نام سرور مورد استفاده برای شناسه نام سرور در TLS (یا SNI) را مشخص می‌کند. به طور پیش‌فرض، نام میزبان برگرفته از رشته اتصال برای SNI استفاده می‌شود. این گزینه اجازه می‌دهد نام میزبان SNI بازنویسی شود، که هنگام اتصال از طریق پروکسی‌ها یا مش‌های خدمات (service meshes) که نقطه پایانی اتصال با نام سرور مورد نظر متفاوت است مفید است.

-v[spec]

--verbose=[spec]

سطوح ثبت وقایع (logging) را تعیین می‌کند. بدون هیچ آرگومان spec، سطح لاگ برای هر ماژول و مقصد روی dbg تنظیم می‌شود. در غیر این صورت، spec فهرستی از کلمات جداشده با فاصله یا ویرگول یا دونقطه است، حداکثر یکی از هر دسته زیر:

بزرگی و کوچکی حروف در spec اهمیتی ندارد.

صرف نظر از سطوح لاگ تعیین‌شده برای file، ثبت وقایع در فایل انجام نخواهد شد مگر اینکه --log-file نیز مشخص شده باشد (زیر را ببینید).

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

-v

--verbose

حداکثر سطح پرحرفی (verbosity) لاگ را تنظیم می‌کند که معادل --verbose=dbg است.

-vPATTERN:destination:pattern

--verbose=PATTERN:destination:pattern

الگوی لاگ را برای destination روی pattern تنظیم می‌کند. برای شرح نحو معتبر برای pattern به ovs-appctl(8) مراجعه کنید.

-vFACILITY:facility

--verbose=FACILITY:facility

تسهیلات (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 سیستم محلی استفاده می‌شود و هنگام ارسال پیام به مقصد ارائه‌شده از طریق گزینه --syslog-target از local0 استفاده می‌شود.

--log-file[=file]

ثبت وقایع در یک فایل را فعال می‌کند. اگر file مشخص شده باشد، به عنوان نام دقیق فایل لاگ استفاده می‌شود. نام پیش‌فرض فایل لاگ در صورت حذف file برابر با /var/log/openvswitch/ovs-ofctl.log است.

--syslog-target=host:port

علاوه بر syslog سیستم، پیام‌های syslog را به درگاه UDP مشخص‌شده port روی میزبان host ارسال می‌کند. آرگومان host باید یک آدرس IP عددی باشد و نه یک نام میزبان.

--syslog-method=method

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

مقدار پیش‌فرض از متغیر محیطی OVS_SYSLOG_METHOD گرفته می‌شود؛ در صورت عدم تنظیم، مقدار پیش‌فرض libc است.

--color[=when]

رنگ‌آمیزی خروجی (برای برخی دستورات)؛ مقدار when می‌تواند never، always یا auto (پیش‌فرض) باشد.

-h

--help

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

-V

--version

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