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

ovs-testcontroller - کنترل‌کننده ساده OpenFlow برای آزمایش

ovs-testcontroller [گزینه‌ها] method [method]...

دستور ovs-testcontroller یک کنترل‌کننده ساده OpenFlow است که هر تعداد سوییچ را از طریق پروتکل OpenFlow مدیریت کرده و باعث می‌شود آن‌ها به عنوان سوییچ‌های L2 با یادگیری مک (MAC-learning) یا هاب کار کنند. این ابزار برای آزمایش اولیه شبکه‌های OpenFlow مناسب است. این برنامه بخشی ضروری یا مطلوب از یک پیاده‌سازی عملیاتی OpenFlow نیست.

ابزار ovs-testcontroller یک یا چند سوییچ OpenFlow را که از طریق یک یا چند روش اتصال OpenFlow زیر مشخص شده‌اند کنترل می‌کند:


برای اتصالات OpenFlow روی port مشخص‌شده گوش می‌دهد. مقدار پیش‌فرض port برابر 6653 است. به طور پیش‌فرض، اتصالات از هر نشانی IPv4 مجاز هستند. مقدار host را به عنوان یک نشانی IPv4 یا یک نشانی IPv6 درون قلاب مشخص کنید (مانند ptcp:6653:[::1]). در لینوکس، از %device برای تعیین دامنه (scope) نشانی‌های پیوند-محلی IPv6 استفاده کنید، مانند ptcp:6653:[fe80::1234%eth0]. در صورت کامپایل با کتابخانه unbound، می‌توان از نام‌های DNS نیز استفاده کرد. برای pssl، گزینه‌های --private-key، --certificate و --ca-cert اجباری هستند.
برای اتصالات OpenFlow روی سوکت سرور دامنه یونیکس به نام file گوش می‌دهد.

اتصال به port مشخص‌شده روی host داده‌شده، که می‌تواند به صورت یک نام DNS (در صورت ساخت با کتابخانه unbound) یا یک نشانی IP در قالب IPv4 یا IPv6 بیان شود. نشانی‌های IPv6 را درون براکت قرار دهید، مانند tcp:[::1]:6653. در لینوکس، از %device برای تعیین دامنه نشانی‌های پیوند-محلی IPv6 استفاده کنید، مانند tcp:[fe80::1234%eth0]:6653. برای ssl، گزینه‌های --private-key، --certificate و --ca-cert اجباری هستند.
اگر port مشخص نشده باشد، مقدار پیش‌فرض آن 6653 خواهد بود.
در سیستم‌های پازیکس (POSIX)، سوکت سرور دامنه یونیکس با نام file.


به طور پیش‌فرض، ovs-testcontroller هر زمان که بسته‌ای دریافت کند که مقصد آن بر اساس یادگیری MAC شناخته شده باشد، یک جریان (flow) در هر سوییچ OpenFlow برقرار می‌کند. این گزینه راه‌اندازی جریان را غیرفعال می‌کند، به طوری که تمام بسته‌های شبکه از کنترل‌کننده عبور می‌کنند.
این گزینه بیشتر برای اشکال‌زدایی مفید است. کارایی سوئیچینگ را کاهش می‌دهد، بنابراین نباید در محیط‌های عملیاتی استفاده شود.
مقدار secs را به عنوان تعداد ثانیه‌هایی تعیین می‌کند که یک جریان ایجادشده توسط کنترل‌کننده بدون مشاهده هیچ بسته منطبقی در جدول جریان سوییچ باقی می‌ماند. اگر permanent مشخص شود (که توصیه نمی‌شود)، جریان‌ها هرگز منقضی نخواهند شد. مقدار پیش‌فرض 60 ثانیه است.
این گزینه هنگامی که -n (یا --noflow) در حال استفاده است هیچ تأثیری ندارد (زیرا کنترل‌کننده در این حالت جریانی برقرار نمی‌کند).

به طور پیش‌فرض، کنترل‌کننده به عنوان یک سوییچ L2 با قابلیت یادگیری MAC عمل می‌کند. این گزینه رفتار آن را به یک هاب تغییر می‌دهد که بسته‌ها را روی تمام درگاه‌ها به جز درگاه ورودی ارسال می‌کند (flood).
اگر -H (یا --hub) و -n (یا --noflow) با هم استفاده شوند، اثر تجمعی آن‌ها این است که تمام بسته‌ها از کنترل‌کننده عبور می‌کنند و همه بسته‌ها فیلود (flood) می‌شوند.
این گزینه بیشتر برای اشکال‌زدایی مفید است. کارایی سوئیچینگ را کاهش می‌دهد، بنابراین نباید در محیط‌های عملیاتی استفاده شود.

به طور پیش‌فرض، ovs-testcontroller جریان‌هایی با تطابق دقیق (exact-match) را برقرار می‌کند. این گزینه امکان ایجاد جریان‌های دارای کاراکتر عام (wildcarded) را فراهم می‌آورد، که ممکن است با ارسال ترافیک کمتر به سمت کنترل‌کننده، تأخیر راه‌اندازی جریان را کاهش دهد.
مقدار اختیاری wildcard_mask یک بیت‌ماسک هگزادسیمال عام OpenFlow است که فیلدهای مشمول عام‌بودن را مشخص می‌کند. اگر هیچ wildcard_mask مشخص نشود، مقدار پیش‌فرض 0x2820F0 استفاده می‌شود که سوئیچینگ صرفاً لایه L2 را مشخص کرده و فیلدهای L3 و L4 را به صورت عام قرار می‌دهد. مقدار جالب دیگر 0x2000EC است که سوئیچینگ صرفاً لایه L3 را مشخص می‌کند و فیلدهای L2 و L4 را عام می‌سازد.
این گزینه هنگامی که -n (یا --noflow) در حال استفاده است هیچ تأثیری ندارد (زیرا کنترل‌کننده در این حالت جریانی برقرار نمی‌کند).

به طور پیش‌فرض، ovs-testcontroller بسته‌ها را به یک درگاه مشخص هدایت کرده یا آن‌ها را سیلاب (flood) می‌کند. این گزینه باعث می‌شود که بسته‌های غیرسیلابی به درگاه OpenFlow با نام OFPP_NORMAL هدایت شوند. این کار به خود سوییچ اجازه می‌دهد درباره مقصد بسته‌ها تصمیم‌گیری کند. پشتیبانی از OFPP_NORMAL در OpenFlow اختیاری است، بنابراین ممکن است این گزینه با برخی سوییچ‌های غیر Open vSwitch به درستی کار نکند.
از پاسخ دادن ovs-testcontroller به پیام‌های OpenFlow ارسال‌شده از سوی سوییچ‌ها جلوگیری می‌کند.
این گزینه فقط برای اشکال‌زدایی پیاده‌سازی حالت ``fail open'' در Open vSwitch است. نباید در محیط‌های عملیاتی استفاده شود.

به طور پیش‌فرض، ovs-testcontroller از صف پیش‌فرض OpenFlow برای ارسال بسته‌ها و راه‌اندازی جریان‌ها استفاده می‌کند. با استفاده از یکی از این گزینه‌ها و مشخص کردن id به عنوان شناسه صف OpenFlow به صورت یک عدد ده‌دهی، می‌توان از آن صف مشخص استفاده کرد.
این گزینه با -N یا --normal و با -H یا --hub ناسازگار است. اگر بیش از یک مورد مشخص شود، این گزینه اولویت دارد.
این گزینه ممکن است برای آزمایش یا اشکال‌زدایی پیکربندی‌های کیفیت خدمات (QoS) مفید باشد.
بسته‌های دریافتی روی درگاه به نام port-name (مانند eth0) را پیکربندی می‌کند تا روی صف OpenFlow با شناسه queue-id (مشخص‌شده به صورت عدد ده‌دهی) خروجی داده شوند. برای درگاه مشخص‌شده، این گزینه مقدار پیش‌فرض ارائه‌شده در -q یا --queue را لغو می‌کند.
این گزینه را می‌توان به هر تعداد بار با آرگومان‌های مختلف port-name مشخص کرد.
این گزینه با -N یا --normal و با -H یا --hub ناسازگار است. اگر بیش از یک مورد مشخص شود، این گزینه اولویت دارد.
این گزینه ممکن است برای آزمایش یا اشکال‌زدایی پیکربندی‌های کیفیت خدمات (QoS) مفید باشد.
هنگامی که یک سوییچ متصل می‌شود، ورودی‌های جریان شرح داده شده در file را ارسال می‌کند. هر خط در file یک ورودی جریان در قالبی است که برای دستور add-flows در بخش Flow Syntax از صفحه راهنمای ovs-ofctl(8) شرح داده شده است.
برای افزودن جریان‌ها از چندین فایل، این گزینه را بیش از یک بار به کار ببرید.


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

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

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

اعتبارسنجی گواهی‌های ارائه‌شده توسط طرف‌های مقابل SSL/TLS را غیرفعال می‌کند. این کار یک ریسک امنیتی ایجاد می‌کند، زیرا به این معنی است که نمی‌توان مطمئن شد گواهی‌ها متعلق به میزبان‌های مورد اعتماد و شناخته‌شده هستند.
نام سرور مورد استفاده برای TLS Server Name Indication (SNI) را مشخص می‌کند. به طور پیش‌فرض، نام میزبان برگرفته از رشته اتصال برای SNI استفاده می‌شود. این گزینه امکان بازنویسی نام میزبان SNI را فراهم می‌کند، که در صورت اتصال از طریق پروکسی‌ها یا سرویس‌مش‌ها که نقطه پایانی اتصال با نام سرور مورد نظر تفاوت دارد، مفید است.
یک فایل PEM حاوی یک یا چند گواهی اضافی برای ارسال به همتایان SSL/TLS را مشخص می‌کند. فایل peer-cacert.pem باید گواهی CA مورد استفاده برای امضای گواهی خود ovs-testcontroller باشد، یعنی همان گواهی مشخص‌شده در -c یا --certificate. اگر گواهی ovs-testcontroller خودامضا (self-signed) است، آنگاه --certificate و --peer-ca-cert باید به فایل یکسانی اشاره کنند.
این گزینه در عملکرد عادی مفید نیست، زیرا همتای SSL/TLS باید از قبل گواهی CA را داشته باشد تا به هویت ovs-testcontroller اطمینان حاصل کند. با این حال، این گزینه راهکاری را برای یک نصب جدید فراهم می‌کند تا در اولین اتصال SSL/TLS خود گواهی CA را راه‌اندازی (bootstrap) کند.

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

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

سطوح لاگ‌گیری را تنظیم می‌کند. بدون هیچ spec، سطح لاگ را برای تمام ماژول‌ها و مقصدها روی dbg تنظیم می‌کند. در غیر این صورت، spec فهرستی از کلمات است که با فاصله، کاما یا دونقطه از هم جدا شده‌اند و حداکثر شامل یک کلمه از هر یک از دسته‌های زیر است:
  • یک نام معتبر ماژول، همان‌طور که توسط دستور vlog/list در ovs-appctl(8) نمایش داده می‌شود، تغییر سطح لاگ را به ماژول مشخص‌شده محدود می‌کند.
  • عبارت syslog، console، یا file، برای محدود کردن تغییر سطح لاگ به ترتیب تنها به لاگ سیستم، به کنسول، یا به یک فایل. (اگر --detach مشخص شده باشد، ovs-testcontroller توصیف‌کننده‌های استاندارد فایل خود را می‌بندد، بنابراین لاگ‌گیری در کنسول هیچ اثری نخواهد داشت.)
  • عبارت‌های 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 به عنوان پیش‌فرض برای لاگ سیستم محلی استفاده می‌شود و local0 هنگام ارسال پیام به مقصدی که از طریق گزینه --syslog-target تعیین شده به کار می‌رود.
لاگ‌گیری در یک فایل را فعال می‌کند. اگر file مشخص شده باشد، به عنوان نام دقیق فایل لاگ استفاده می‌شود. نام پیش‌فرض فایل لاگ در صورت عدم ذکر file برابر /var/log/openvswitch/ovs-testcontroller.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 محلی (localhost) استفاده نمایید.
  • روش udp:ip:port، استفاده از سوکت UDP. با این روش می‌توان از قالب دلخواه پیام حتی در نسخه‌های قدیمی‌تر rsyslogd نیز استفاده کرد. هنگام ارسال پیام‌های syslog از طریق سوکت UDP باید احتیاط‌های لازم را در نظر گرفت، برای نمونه دیمن syslog باید طوری پیکربندی شود که روی پورت UDP مشخص‌شده گوش دهد، قوانین تصادفی iptables ممکن است با ترافیک syslog محلی تداخل داشته باشند و ملاحظات امنیتی خاصی برای سوکت‌های UDP اعمال می‌شود که در سوکت‌های دامنه یونیکس وجود ندارد.
  • روش null، تمام پیام‌های ارسالی به syslog را دور می‌ریزد.
مقدار پیش‌فرض از متغیر محیطی OVS_SYSLOG_METHOD خوانده می‌شود؛ اگر این متغیر تنظیم نشده باشد، مقدار پیش‌فرض libc است.
نام سوکت کنترلی را تنظیم می‌کند که ovs-testcontroller روی آن به دستورات مدیریتی حین اجرا گوش می‌دهد (بخش RUNTIME MANAGEMENT COMMANDS را در زیر ببینید). اگر socket با / آغاز نشود، نسبت به /run/openvswitch در نظر گرفته می‌شود. اگر --unixctl اصلاً استفاده نشود، سوکت پیش‌فرض برابر /run/openvswitch/ovs-testcontroller.pid.ctl خواهد بود که در آن pid شناسه فرآیند ovs-testcontroller است.
تعیین none برای socket ویژگی سوکت کنترلی را غیرفعال می‌کند.

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

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

نگارش‌های مجاز پروتکل OpenFlow را هنگام برقراری یک نشست OpenFlow تنظیم می‌کند.
این نگارش‌های پروتکل به طور پیش‌فرض فعال هستند:
•
OpenFlow10، برای OpenFlow 1.0.
نسخه‌های پروتکل زیر عموماً پشتیبانی می‌شوند، اما برای سازگاری با نسخه‌های قدیمی‌تر Open vSwitch به طور پیش‌فرض فعال نیستند:
  • OpenFlow11، برای OpenFlow 1.1.
  • OpenFlow12، برای OpenFlow 1.2.
  • OpenFlow13، برای OpenFlow 1.3.
  • OpenFlow14، برای OpenFlow 1.4.
  • OpenFlow15، برای OpenFlow 1.5.

برای اتصال محلی به پورت 6653 (پیش‌فرض) و انتظار برای اتصالات ورودی از سوییچ‌های OpenFlow:

% ovs-testcontroller ptcp:

ovs-appctl(8), ovs-ofctl(8), ovs-dpctl(8)

4.0.0 Open vSwitch