KEA-ARM(1) Kea KEA-ARM(1)

kea-arm - مستندات راهنمای مرجع مدیر سیستم Kea [تصویر]

‏Kea یک پیاده‌سازی متن‌باز از سرورهای پروتکل پیکربندی پویای میزبان (DHCP) است که توسط Internet Systems Consortium (ISC) توسعه یافته و نگهداری می‌شود.

این راهنمای مرجع برای Kea نسخهٔ 3.2.0 است. پیوندهای مربوط به جدیدترین نسخهٔ این سند (در قالب‌های PDF، HTML و متن ساده) را می‌توان در Read the Docs به نشانی https://kea.readthedocs.io یافت. سایر اطلاعات مفید Kea در پایگاه دانش ما به نشانی https://kb.isc.org در دسترس است.

‏Kea نسل بعدی نرم‌افزارهای DHCP است که توسط Internet Systems Consortium (ISC) توسعه یافته است. این برنامه هم از پروتکل‌های DHCPv4 و هم از DHCPv6 به همراه الحاقات آن‌ها، مانند واگذاری پیشوند (prefix delegation) و به‌روزرسانی‌های پویای DNS پشتیبانی می‌کند.

این راهنما نسخهٔ 3.2.0 Kea را پوشش می‌دهد.

برای دریافت اطلاعات دربارهٔ پلتفرم‌های پشتیبانی‌شده، بخش پلتفرم‌های پشتیبانی‌شده (Supported Platforms) را ببینید.

به‌طور کلی، این نسخه از Kea روی هر سیستم سازگار با POSIX که دارای کامپایلر ++C (با پشتیبانی از C++14)، کتابخانهٔ رمزنگاری Botan، کتابخانهٔ ثبت لاگ log4cplus و کتابخانهٔ سیستمی Boost باشد ساخته و اجرا می‌شود.

‏ISC به‌طور منظم Kea را روی سیستم‌عامل‌ها و معماری‌های متعددی آزمایش می‌کند، اما منابع کافی برای آزمایش همهٔ آن‌ها را ندارد. در نتیجه، ISC تنها می‌تواند پشتیبانی را بر پایهٔ "بیشترین تلاش (best-effort)" برای برخی از آن‌ها ارائه دهد.

‏Kea به‌طور رسمی روی سیستم‌های Alpine، Debian، Fedora، FreeBSD، RHEL و Ubuntu پشتیبانی می‌شود. ساخت‌های Kea-3.2.0 روی سیستم‌های زیر آزمایش شده‌اند:

  • Alpine — 3.21, 3.22, 3.23, 3.24
  • Debian — 11, 12, 13
  • Fedora — 44
  • FreeBSD — 15
  • RHEL — 8, 9, 10
  • Ubuntu — 22.04, 24.04, 26.04

در حال حاضر برنامه‌ای برای پورت کردن Kea به سیستم‌های Windows وجود ندارد.

موارد زیر پلتفرم‌هایی هستند که ساخته‌شدن و اجرای Kea روی آن‌ها تأیید شده است. ‏ISC تمام توان خود را برای رفع باگ‌ها در این پلتفرم‌ها به کار می‌گیرد، اما ممکن است به دلیل کمبود سخت‌افزار، آشنایی کمتر کادر مهندسی و سایر محدودیت‌ها قادر به انجام سریع آن نباشد.

•
macOS — 14, 15, 26

این سیستم‌ها زمانی به‌طور منظم آزمایش می‌شدند، اما پشتیبانی رسمی از آن‌ها متوقف شده است؛ که معمولاً به دلیل پایان یافتن پشتیبانی از سوی توسعه‌دهندگان خود آن سیستم‌ها است. نسخه‌های قدیمی‌تر ممکن است پیش‌نیازهای لازم برای ساخت آسان Kea را در دسترس نداشته باشند، هرچند در بسیاری از موارد امکان کامپایل مستقیم از روی کد منبع روی آن‌ها وجود دارد. جامعهٔ کاربری و افراد علاقه‌مند می‌توانند در نگه‌داری کمک کنند و ما از مشارکت در قالب وصله (patch) استقبال می‌کنیم، اگرچه نمی‌توانیم پذیرش آن‌ها را تضمین نماییم. تمام مشارکت‌ها از نظر ریسک تأثیر منفی بر پلتفرم‌های رسماً پشتیبانی‌شده سنجیده می‌شوند.

این پلتفرم‌ها مواردی را در بر می‌گیرند که تاریخ پایان عمر (EOL) آن‌ها گذشته است، مانند:

  • Alpine — 3.20 (EOL 1 Apr 2026) و قدیمی‌تر
  • Debian — 10 (EOL 30 Jun 2024) و قدیمی‌تر
  • Fedora — 43 (EOL 9 Dec 2026) و قدیمی‌تر
  • FreeBSD — 14 (EOL 31 Dec 2026) و قدیمی‌تر
  • RHEL — 7 (EOL 30 Jun 2024) و قدیمی‌تر
  • Ubuntu — 20.04 (EOL 31 May 2025) و قدیمی‌تر
  • macOS — 13 (EOL 15 Sep 2025) و قدیمی‌تر

    این‌ها پلتفرم‌هایی هستند که مشخص شده است نسخه‌های Kea از نگارش 1.7 به بعد روی آن‌ها ساخته یا اجرا نمی‌شوند:

  • Windows (همه نسخه‌ها)
  • Windows Server (همه نسخه‌ها)
  • هر پلتفرمی با OpenSSL نسخه 1.0.1 یا قدیمی‌تر که به عنوان جایگزین Botan ندارد
  • هر پلتفرمی با log4cplus نسخه 1.0.2 یا قدیمی‌تر.
  • هر پلتفرمی با کامپایلری که از C++14 پشتیبانی نمی‌کند.

‏Kea از بسته‌های نرم‌افزاری جانبی متعددی استفاده می‌کند که ممکن است در نصب پیش‌فرض برخی از سیستم‌عامل‌ها یا در مخازن بسته‌های استاندارد ارائه نشده باشند. ممکن است لازم باشد این نرم‌افزارهای مورد نیاز به‌طور جداگانه نصب شوند. (برای پیش‌نیازهای ساخت، همچنین پیش‌نیازهای ساخت <#build-requirements> را ببینید.)

  • ‏Kea از دو کتابخانه رمزنگاری پشتیبانی می‌کند: Botan و OpenSSL. در هنگام کامپایل تنها نصب یکی از آن‌ها الزامی است. Kea از کتابخانه Botan برای C++ (https://botan.randombit.net)، نسخه 2.0 یا جدیدتر استفاده می‌کند؛ پشتیبانی از نسخه‌های Botan قدیمی‌تر از 2.0 از زمان انتشار Kea 1.7.0 حذف شد. به عنوان جایگزینی برای Botan، نرم‌افزار Kea می‌تواند از کتابخانه رمزنگاری OpenSSL (https://www.openssl.org)، نسخه 1.0.2 یا بالاتر استفاده کند.
  • ‏Kea از کتابخانه لاگ‌گیری log4cplus برای C++ (https://sourceforge.net/p/log4cplus/wiki/Home) استفاده می‌کند. این برنامه به log4cplus نسخه 1.0.3 یا جدیدتر نیاز دارد.
  • ‏Kea به کتابخانه سیستمی Boost (https://www.boost.org) نیاز دارد. ساخت با نسخه header-only کتابخانه Boost دیگر توصیه نمی‌شود.

برخی از ویژگی‌های اختیاری Kea دارای وابستگی‌های بیشتری هستند.

  • برای ذخیره اطلاعات اجاره (lease) در یک پایگاه داده MySQL، برنامه Kea به هدرها و کتابخانه‌های MySQL نیاز دارد. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از MySQL ساخته شود.
  • برای ذخیره اطلاعات اجاره در یک پایگاه داده PostgreSQL، برنامه Kea به هدرها و کتابخانه‌های PostgreSQL نیاز دارد. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از PostgreSQL ساخته شود.
  • ‏Kea یک رابط NETCONF با عامل kea-netconf ارائه می‌دهد. این ماژول Kea هنگام استفاده به نرم‌افزار Sysrepo نیاز دارد. ساخت Kea با پشتیبانی از NETCONF نیازمند نصب وابستگی‌های متعددی است که در نصب NETCONF <#netconf-install> با جزئیات بیشتر شرح داده شده است. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از NETCONF ساخته شود.
  • برای امضا و اعتبارسنجی به‌روزرسانی‌های DNS، سرور Kea DDNS ممکن است از GSS-TSIG استفاده کند که به کتابخانه‌های MIT Kerberos 5 یا Heimdal نیاز دارد. وابستگی‌هایی که باید نصب شوند با جزئیات بیشتر در کامپایل GSS-TSIG <#gss-tsig-install> توضیح داده شده‌اند. این یک وابستگی اختیاری است؛ Kea می‌تواند بدون پشتیبانی از GSS-TSIG ساخته شود.

‏Kea یک راهکار ماژولار سرور DHCP است. این ماژولار بودن با به‌کارگیری چندین فرآیند همکار محقق می‌شود که در کنار یکدیگر عملکردهای سرور را فراهم می‌آورند. نرم‌افزارهای زیر همراه با Kea ارائه شده‌اند:

  • keactrl <#std-iscman-keactrl> — این ابزار سرورهای Kea را راه‌اندازی و متوقف کرده، مجدداً پیکربندی نموده و وضعیت آن‌ها را گزارش می‌دهد.
  • kea-dhcp4 <#std-iscman-kea-dhcp4> — فرآیند سرور DHCPv4. این فرآیند به درخواست‌های DHCPv4 از سوی کلاینت‌ها پاسخ می‌دهد.
  • kea-dhcp6 <#std-iscman-kea-dhcp6> — فرآیند سرور DHCPv6. این فرآیند به درخواست‌های DHCPv6 از سوی کلاینت‌ها پاسخ می‌دهد.
  • kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> — فرآیند Dynamic DNS مربوط به DHCP. این فرآیند به عنوان یک واسطه بین سرورهای DHCP و سرورهای خارجی DNS عمل می‌کند؛ درخواست‌های به‌روزرسانی نام را از سرورهای DHCP دریافت کرده و پیام‌های به‌روزرسانی DNS را به سرورهای DNS ارسال می‌کند.
  • kea-admin <#std-iscman-kea-admin> — این ابزاری مفید برای نگهداری بک‌اند پایگاه داده است (ایجاد پایگاه داده جدید، بررسی نسخه‌ها، ارتقا و غیره).
  • kea-lfc <#std-iscman-kea-lfc> — این فرآیند اطلاعات تکراری و اضافی را از فایل‌هایی که برای ذخیره‌سازی پایدار بک‌اند پایگاه داده memfile استفاده می‌شوند، حذف می‌کند. اگرچه می‌تواند به صورت مستقل اجرا شود، معمولاً در زمان و صورت نیاز توسط سرورهای DHCP Kea اجرا می‌شود.
  • kea-netconf <#std-iscman-kea-netconf> - عامل kea-netconf رابطی بر پایه YANG/NETCONF برای پیکربندی Kea فراهم می‌کند.
  • kea-shell <#std-iscman-kea-shell> — این کلاینت متنی ساده از رابط REST برای اتصال به سرور Kea استفاده می‌کند.
  • perfdhcp <#std-iscman-perfdhcp> — این ابزاری برای محک‌زدن (benchmarking) کارایی DHCP است که چندین کلاینت را شبیه‌سازی می‌کند تا عملکرد هر دو سرور DHCPv4 و DHCPv6 را آزمایش کند.

ابزارها و ماژول‌ها با جزئیات کامل در این راهنما پوشش داده شده‌اند. افزون بر این، صفحات راهنما (man pages) نیز در نصب پیش‌فرض ارائه شده‌اند.

‏Kea همچنین کتابخانه‌های C++ و رابط‌های برنامه‌نویسی برای DHCP فراهم می‌کند. این موارد شامل مستندات جامع توسعه‌دهنده و نمونه‌کدها هستند.

این بخش گام‌های اولیه‌ی لازم برای راه‌اندازی و اجرای Kea را شرح می‌دهد. برای جزئیات بیشتر، سفارشی‌سازی‌های کامل و عیب‌یابی، به فصل‌های مربوطه در سایر بخش‌های این «راهنمای مرجع مدیر سیستم Kea» (ARM) مراجعه کنید.

1.
وابستگی‌های لازم برای زمان اجرا و ساخت را نصب کنید. برای جزئیات به پیش‌نیازهای ساخت <#build-requirements> مراجعه کنید.
2.
بسته tarball سورس Kea را از صفحه اصلی دانلودهای isc.org https://www.isc.org/download، سایت دانلودهای ISC https://downloads.isc.org/isc/kea یا صفحه Cloudsmith مربوط به ISC https://cloudsmith.io/~isc/packages/?q=format%3Araw دریافت کنید.
3.
بسته tarball را استخراج کنید. برای مثال:
$ tar -Jxvf kea-3.2.0.tar.xz
4.
به دایرکتوری سورس بروید و فرآیند ساخت را برپا کنید:
$ cd kea-3.2.0
$ meson setup build [your extra parameters]
5.
آن را بسازید:
$ meson compile -C build
6.
آن را نصب کنید (به‌طور پیش‌فرض در /usr/local/ قرار خواهد گرفت، بنابراین به احتمال زیاد برای این مرحله به دسترسی‌های ریشه (root) نیاز است):
$ meson install -C build

شرکت ISC بسته‌های بومی Alpine، deb و RPM را ارائه می‌دهد که نصب Kea را بسیار آسان‌تر از ساخت آن از کد منبع می‌سازد. مگر در مواردی که گزینه‌های کامپایل خاصی مد نظر باشد، معمولاً نصب Kea با استفاده از بسته‌های بومی ساده‌تر است.

1.
به صفحهٔ Kea در cloudsmith.io بروید: https://cloudsmith.io/~isc/repos.
2.
مخزن Cloudsmith مورد نظر را انتخاب کنید؛ برای نمونه kea-3-2 برای Kea 3.2.0.

نکته:

تمامی نسخه‌های پایدار در مخازن جداگانه نگهداری می‌شوند، مانند kea-2-6، kea-3-0 و غیره. تمامی نسخه‌های در حال توسعه، که استفاده از آن‌ها در محیط‌های عملیاتی توصیه نمی‌شود، در مخزن kea-dev قرار دارند.
3.
روی پیکان کنار دکمهٔ "Set Me Up" کلیک کرده و توزیع سیستم‌عامل مورد نظر را انتخاب کنید: Alpine، Debian یا RedHat.
4.
دستورالعمل‌های روی صفحه را دنبال کنید.

نکته:

برای نمونه، دستورالعمل‌های راه‌اندازی Debian برای Kea 3.0 در اینجا در دسترس است: https://cloudsmith.io/~isc/repos/kea-3-0/setup/#formats-deb

منوی کشویی بالای صفحه، دستورالعمل‌های مربوط به سایر سیستم‌عامل‌ها را ارائه می‌دهد.

5.
برنامهٔ Kea به بسته‌های گوناگونی تقسیم شده است. کل فهرست در صفحهٔ مخزن Cloudsmith زیر بخش Packages موجود است، یا می‌توان آن را با استفاده از apk/apt/dnf دریافت کرد.
Debian/Ubuntu 0.0 3.5 $ apt search isc-kea 168u 168u نکته: 0.0 3.5 بسته‌های isc-kea-dhcp4-server و isc-kea-dhcp6-server بسته‌های خالی انتقالی (transitional) هستند. بسته‌های اصلی سرور isc-kea-dhcp4 و isc-kea-dhcp6 می‌باشند. 168u 168u
Fedora/RedHat 0.0 3.5 $ dnf search 'isc-kea*' 168u 168u
Alpine 0.0 3.5 $ apk search isc-kea 168u 168u
6.
نصب فرا-بسته (metapackage) شامل تمامی ابزارها، کتابخانه‌ها، سرورها، مستندات و هوک‌های (hooks) متن‌باز:
Debian/Ubuntu 0.0 3.5 $ sudo apt install isc-kea 168u 168u
Fedora/RedHat 0.0 3.5 $ sudo dnf install isc-kea 168u 168u
Alpine 0.0 3.5 # apk add isc-kea 168u 168u

یا بسته‌های مشخص:

Debian/Ubuntu 0.0 3.5 $ sudo apt install isc-kea-dhcp6 168u 168u
Fedora/RedHat 0.0 3.5 $ sudo dnf install isc-kea-dhcp6 168u 168u
Alpine 0.0 3.5 $ apk add isc-kea-dhcp6 168u 168u

یا تمامی بسته‌های مرتبط با Kea، شامل هدرهای توسعه، نمادهای اشکال‌زدایی (debug symbols) و هوک‌های مشترکین (در صورت موجود بودن):

Debian/Ubuntu 0.0 3.5 $ sudo apt install 'isc-kea*' 168u 168u
Fedora/RedHat 0.0 3.5 $ sudo dnf install 'isc-kea*' 168u 168u
Alpine نصب بسته‌ها از طریق الگوهای تطبیق نام (*) در Alpine در دسترس نیست، اما می‌توان آن را با دستور زیر شبیه‌سازی کرد: 0.0 3.5 # apk search isc-kea | sed 's/-[0-9].*//g' | xargs apk add 168u 168u

یا تمامی بسته‌ها با یک شماره نسخهٔ مشخص:

Debian/Ubuntu 0.0 3.5 $ sudo apt install 'isc-kea*=2.4.0-isc20230921141113' 168u 168u
Fedora/RedHat 0.0 3.5 $ sudo dnf install 'isc-kea*2.4.0-isc20230921141113*' 168u 168u
Alpine نصب بسته‌ها از طریق الگوهای تطبیق نام (*) در Alpine در دسترس نیست، اما می‌توان آن را با دستور زیر شبیه‌سازی کرد: 0.0 3.5 # apk search isc-kea | sed 's/-[0-9].*//g' | grep r20230921141113 | xargs apk add 168u 168u
اکنون تمام بسته‌های نصب‌شده باید در دسترس باشند.
می‌توانید سرور را به‌صورت دستی راه‌اندازی کنید:
# kea-dhcp6 -c /etc/kea/kea-dhcp6.conf

یا با استفاده از systemd:

# systemctl restart kea-dhcp6

یا با استفاده از OpenRC در Alpine:

# service kea-dhcp6 restart

نکته:

ابزار keactrl <#std-iscman-keactrl> در بسته‌ها ارائه نشده است، چرا که عملکرد مشابه توسط اسکریپت‌های بومی systemctl فراهم شده است.
9.
در سیستم‌های Debian/Ubuntu، هنگام نصب بسته، سرویس به‌طور خودکار در زمان بوت فعال می‌شود. در Fedora/RHEL و Alpine، سرویس به‌صورت خودکار فعال نمی‌شود؛ بنابراین در صورت نیاز، باید به‌طور دستی فعال گردد.
با systemd در Fedora/RedHat:
# systemctl enable kea-dhcp6

با OpenRC در Alpine:

# rc-update add kea-dhcp6

1.
به مخزن داکر ISC در cloudsmith.io https://cloudsmith.io/~isc/repos/docker/packages بروید.
2.
یک شبکه ipvlan متصل به رابط میزبان رو به کلاینت و اختصاص‌یافته به زیرشبکه‌ای که توسط Kea سرویس‌دهی می‌شود، ایجاد کنید.
$ docker network create --driver ipvlan --ipv6 --subnet 2001:db8::/64 --opt parent=eth0 ipvlan0
3.
ایمیج دلخواه را انتخاب کرده و آن را به‌صورت محلی pull کنید.
$ docker pull docker.cloudsmith.io/isc/docker/kea-dhcp6
4.
یک کانتینر از ایمیج بسازید. در صورت نیاز، حجم پیکربندی و حجم داده را سوار (mount) کنید.
$ docker create \
    --name kea-dhcp6 \
    --network ipvlan0 \
    --volume /local/kea/config:/etc/kea \
    --volume /local/kea/data:/var/lib/kea \
    docker.cloudsmith.io/isc/docker/kea-dhcp6
5.
کانتینر داکر را راه‌اندازی کنید.
$ docker start kea-dhcp6
6.
برای متوقف کردن کانتینر داکر، اجرا کنید:
$ docker stop kea-dhcp6

نکته:

برای سناریوهای پیچیده‌تر، به راهنمای kea-docker در https://gitlab.isc.org/isc-projects/kea-docker#user-content-docker-files-for-building-kea-containers مراجعه کنید.
1.
فایل‌های پیکربندی Kea را که به‌طور پیش‌فرض در دایرکتوری "[kea-install-dir]/etc/kea/" نصب می‌شوند ویرایش کنید. این فایل‌ها عبارتند از: kea-dhcp4.conf، kea-dhcp6.conf، kea-dhcp-ddns.conf، و keactrl.conf که به‌ترتیب مربوط به کارساز DHCPv4، کارساز DHCPv6، D2 و اسکریپت keactrl هستند.
2.
برای راه‌اندازی کارساز DHCPv4 در پس‌زمینه، دستور زیر را (به‌عنوان root) اجرا کنید:
# keactrl start -s dhcp4

یا دستور زیر را برای راه‌اندازی کارساز DHCPv6 اجرا کنید:

# keactrl start -s dhcp6

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

# keactrl start
3.
بررسی کنید که کارساز(های) Kea در حال اجرا هستند:
# keactrl status

وضعیت "inactive" برای یک کارساز می‌تواند نشان‌دهنده خطای پیکربندی باشد. لطفاً فایل گزارش لاگ را (که به‌طور پیش‌فرض با نام "[kea-install-dir]/var/log/kea/kea-dhcp4.log"، "[kea-install-dir]/var/log/kea/kea-dhcp6.log"، یا "[kea-install-dir]/var/log/kea/kea-ddns.log" شناخته می‌شود) برای مشاهده جزئیات خطاها بررسی کنید.

4.
اگر کارساز با موفقیت راه‌اندازی شد، آزمایش کنید که آیا به پرس‌وجوهای DHCP پاسخ می‌دهد و کلاینت پیکربندی را از کارساز دریافت می‌کند یا خیر؛ برای مثال، از کلاینت ISC DHCP در https://www.isc.org/download استفاده کنید.
5.
برای متوقف کردن کارساز(ها):
# keactrl stop

برای دستورالعمل‌های ویژه‌ی هر سیستم، لطفاً یادداشت‌های اختصاصی سیستم https://kb.isc.org/docs/installing-kea را که در بخش Kea در پایگاه دانش ISC به نشانی https://kb.isc.org/docs موجود است مطالعه کنید.

جزئیات مربوط به نحوه استفاده از اسکریپت keactrl <#std-iscman-keactrl> را می‌توانید در Managing Kea with keactrl <#keactrl> بیابید.

پس از راه‌اندازی و اجرای سرویس‌های Kea، استقرار یک راهکار داشبورد را برای نظارت بر سرویس‌های فعال در نظر بگیرید. برای جزئیات بیشتر، Monitoring Kea With Stork <#stork> را ببینید.

کارسازهای Kea را می‌توان مستقیماً و بدون نیاز به استفاده از keactrl <#std-iscman-keactrl> یا systemctl راه‌اندازی کرد. برای راه‌اندازی کارساز DHCPv4 دستور زیر را اجرا کنید:

# kea-dhcp4 -c /path/to/your/kea4/config/file.json

به همین ترتیب، برای راه‌اندازی کارساز DHCPv6، دستور زیر را اجرا کنید:

# kea-dhcp6 -c /path/to/your/kea6/config/file.json

سازمان ISC بسته‌های محلی RPM، deb و APK و همچنین فایل‌های فشرده tarball حاوی کد منبع را منتشر می‌کند. این بسته‌ها در مخازن Cloudsmith مربوط به ISC به نشانی https://cloudsmith.io/~isc/repos در دسترس هستند. بسته‌های بومی را می‌توان با استفاده از سیستم مدیریت بسته موجود در توزیع مورد نظر (مانند dpkg یا rpm) دریافت و نصب کرد. همچنین می‌توان مخزن Kea را به سیستم اضافه کرد تا نصب به‌روزرسانی‌ها آسان‌تر شود. برای دریافت جزئیات، لطفاً به https://cloudsmith.io/~isc/repos مراجعه کرده، نسخه Kea مورد نظر را انتخاب نمایید، و سپس بر روی دکمه "Set Me Up" کلیک کنید. برای دستورالعمل‌های دقیق‌تر، لطفاً به این مقاله در پایگاه دانش https://kb.isc.org/docs/isc-kea-packages مراجعه فرمایید.

سازمان ISC دو نوع مخزن را نگهداری می‌کند: پایدار (stable) و توسعه (development). مخازن پایدار شامل یک انتشار پایدار مشخص (مانند kea-2-6 یا kea-3-0) به همراه تمامی به‌روزرسانی‌های نگهداری آن هستند. ایجاد مخازن مجزا برای به حداقل رساندن خطر ارتقای ناخواسته از یک انتشار پایدار به انتشار پایدار دیگر صورت گرفته است.

مخزن توسعه، با عنوان kea-dev، شامل نسخه‌های توسعه فعلی و آتی است که ISC استفاده از آن‌ها را برای محیط‌های عملیاتی توصیه نمی‌کند. بسته‌های موجود در مخزن kea-dev مشمول پاک‌سازی دوره‌ای هستند و ممکن است نسخه‌های قدیمی‌تر از روی آن حذف شوند..SS نصب از طریق بسته‌های Cloudsmith

شرکت ISC بسته‌های Kea را برای Alpine، Debian، Fedora، RHEL و Ubuntu ارائه می‌دهد. روش پیشنهادی برای نصب Kea روی هر یک از این سیستم‌ها، نصب فرابسته isc-kea از مخزن Cloudsmith است. این فرابسته در تمام توزیع‌های پشتیبانی‌شده موجود است و تمامی سرویس‌های ارائه‌شده توسط مجموعه نرم‌افزاری Kea را نصب می‌کند.

اجزای خاص Kea را می‌توان به‌صورت جداگانه از طریق هر یک از بسته‌های زیر نصب کرد:

  • isc-kea-dhcp4 — بسته کارگزار Kea DHCPv4
  • isc-kea-dhcp6 — بسته کارگزار Kea DHCPv6
  • isc-kea-dhcp-ddns — کارگزار Kea DHCP DDNS
  • isc-kea-admin — ابزارهای مدیریت پایگاه‌داده Kea
  • isc-kea-hooks — قلاب‌های متن‌باز Kea DHCP

بسته‌های قلاب مشترکین Kea در بسته isc-kea-hooks گنجانده نشده‌اند. برای مشتریان ISC با دسترسی به قلاب‌های مشترکین، آن بسته‌ها دارای پیشوند isc-kea-subscriber- هستند. کاربرانی که علاقه‌مند به خرید خدمات پشتیبانی حرفه‌ای از ISC و دسترسی به قلاب‌های مشترکین هستند، می‌توانند فرم تماس را در https://www.isc.org/contact تکمیل نمایند.

پس از نصب، سرویس‌ها را می‌توان از طریق مدیر سرویس توزیع مدیریت کرد. نام این سرویس‌ها عبارت است از: kea-dhcp4 <#std-iscman-kea-dhcp4>، kea-dhcp6 <#std-iscman-kea-dhcp6> و kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>.

نکته:

نام‌های واقعی سرویس در Debian و Ubuntu جهت حفظ سازگاری با برخی اسکریپت‌های قدیمی‌تر، کمی با نام بسته‌ها تفاوت دارند. از یک نام مستعار در سرویس systemd استفاده شده است تا کاربران بتوانند با نام‌های کوتاه‌تر به آن‌ها ارجاع دهند. اجرای دستور systemctl enable روی این سرویس‌ها نیازمند نام‌های واقعی سرویس است، که عبارتند از: isc-kea-dhcp4-server، isc-kea-dhcp6-server و isc-kea-dhcp-ddns-server.

برای ارتقا به نسخه فعلی Kea از نسخه 2.3.2 یا پیش‌تر روی سیستم‌های Debian و Ubuntu، به جای دستور معمول apt upgrade دستور apt dist-upgrade را اجرا کنید. پس از تکمیل این ارتقا، می‌توان به‌صورت معمول با استفاده از apt upgrade در سیستم‌های Debian و Ubuntu نسخه‌های بعدی را ارتقا داد.

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

به‌ویژه، بسته به اینکه در ابتدا چه بسته‌هایی نصب شده بودند، احتمال دارد بسته‌های زیر طی ارتقا حذف شوند:

  • isc-kea-dhcp4
  • isc-kea-dhcp6
  • isc-kea-dhcp-ddns
  • isc-kea-hooks

برای نصب کامل مجموعه نرم‌افزاری Kea، کافی است پس از ارتقا دستور apt install isc-kea را اجرا کنید که تمامی زیربسته‌های مرتبط تشکیل‌دهنده Kea را نصب خواهد کرد.

این مشکل مسیر ارتقا برای سیستم‌های RPM و Alpine وجود ندارد.

از مشتریان دارای قرارداد پشتیبانی ISC که در ارتقا با دشواری مواجه می‌شوند دعوت می‌شود یک تیکت در صف پشتیبانی خود ثبت کنند. به سایر کاربران توصیه می‌شود وضعیت خود را در فهرست پستی kea-users در https://lists.isc.org/mailman/listinfo/kea-users مطرح کنند تا از پشتیبانی دیگر اعضای فهرست بهره‌مند گردند.

در زیر ساختار دایرکتوری‌های یک نصب کامل Kea آورده شده است. (تمام مسیرهای دایرکتوری نسبت به دایرکتوری نصب در نظر گرفته شده‌اند.)

  • etc/kea/ — فایل‌های پیکربندی.
  • include/ — فایل‌های هدر توسعه C++.
  • lib/ — کتابخانه‌ها.
  • lib/kea/hooks — کتابخانه‌های قلاب الحاقی.
  • sbin/ — نرم‌افزار کارگزار و دستورهای مورد استفاده مدیر سیستم.
  • share/doc/kea/ — این راهنما، سایر مستندات تکمیلی، و مثال‌ها.
  • share/kea/ — مثال‌های دستورات API و اسکریپت‌های طرحواره پایگاه‌داده (schema).
  • share/man/ — صفحات راهنما (مستندات برخط).
  • var/lib/kea/ — فایل‌های شناسه کارگزار (DHCPv6) و پایگاه‌داده اجاره (lease).
  • var/log/kea/ - فایل‌های گزارش (log).
  • var/run/kea - فایل PID و فایل قفل لاگر.

علاوه بر پیش‌نیازهای زمان اجرا (فهرست‌شده در نرم‌افزارهای مورد نیاز در زمان اجرا <#required-software>)، ساخت Kea از کد منبع نیازمند هدرهای مختلف توسعه و ابزارهای تولید برنامه است.

نکته:

برخی سیستم‌عامل‌ها بسته‌های توزیع خود را به دو بسته زمان اجرا و توسعه تفکیک کرده‌اند. برای ساخت Kea از کد منبع، باید نسخه‌های بسته توسعه که حاوی فایل‌های هدر و کتابخانه‌ها هستند نصب شوند.

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

  • ابزارهای توسعه meson، ninja و pkg-config.
  • کتابخانه‌های C++ بست Boost (https://www.boost.org) (حداقل نسخه 1.66). روی نسخه‌های قدیمی‌تر از 1.69 کتابخانه Boost system نیز باید نصب باشد.
  • ‏OpenSSL (حداقل نسخه 1.0.2) یا Botan (حداقل نسخه 3.4.0). نسخه 1.1.1 یا جدیدتر OpenSSL اکیداً توصیه می‌شود.
  • هدرهای توسعه log4cplus (حداقل نسخه 1.0.3).
  • یک کامپایلر C++ (با پشتیبانی از C++14) و هدرهای استاندارد توسعه.
  • کلاینت MySQL و کتابخانه‌های توسعه کلاینت، هنگام استفاده از پرچم پیکربندی -D mysql=enabled برای ساخت بک‌اند پایگاه‌داده MySQL نرم‌افزار Kea. در این حالت، به یک نمونه در حال اجرای سرور MySQL به صورت محلی یا روی ماشینی در دسترس از طریق شبکه نیاز است. توجه داشته باشید که اجرای آزمون‌های واحد (unit tests) نیازمند سرور MySQL محلی است.
  • کلاینت PostgreSQL و کتابخانه‌های توسعه کلاینت، هنگام استفاده از پرچم پیکربندی -D postgresql=enabled برای ساخت بک‌اند پایگاه‌داده PostgreSQL نرم‌افزار Kea. در این حالت به یک نمونه در حال اجرای سرور PostgreSQL به صورت محلی یا روی ماشینی در دسترس از طریق شبکه نیاز است. توجه داشته باشید که اجرای آزمون‌های واحد نیازمند سرور PostgreSQL محلی است.
  • ‏Sysrepo نسخه 1.4.140 و libyang نسخه 1.0.240، که برای اتصال به یک پایگاه داده Sysrepo مورد نیاز هستند. نسخه‌های قبلی دیگر پشتیبانی نمی‌شوند. هنگام کامپایل از کد منبع، سوییچ پیکربندی قابل استفاده -D netconf=enabled است. اگر این وابستگی‌ها در مسیرهای سفارشی نصب شده‌اند، PKG_CONFIG_PATH را به سمت آن‌ها تنظیم کنید.
  • کتابخانه‌های MIT Kerberos 5 یا Heimdal توسط سرور Kea DDNS برای امضا و اعتبارسنجی به‌روزرسانی‌های DNS با استفاده از GSS-TSIG نیاز هستند. سوییچ پیکربندی که این قابلیت را فعال می‌کند -D krb5=enabled است. اگر این وابستگی در مسیری سفارشی نصب شده است، PKG_CONFIG_PATH را به فایل .pc یا PATH را به ابزار krb5-config هدایت نمایید.
  • ‏googletest (نسخه 1.8 یا بالاتر) هنگام استفاده از گزینه پیکربندی -D tests=enabled برای ساخت آزمون‌های واحد الزامی است.
  • ابزارهای تولید مستندات Sphinx https://www.sphinx-doc.org، ‏texlive به همراه افزونه‌های آن، و Doxygen برای ایجاد مستندات. به‌ویژه در Fedora بسته‌های python3-sphinx، python3-sphinx_rtd_theme، texlive و texlive-collection-latexextra ضروری هستند. در Ubuntu بسته‌های python3-sphinx، python3-sphinx-rtd-theme، texlive و texlive-latex-extra مورد نیاز می‌باشند. چنانچه بسته‌های LaTeX یافت نشوند، Kea از ساخت PDF صرف‌نظر کرده و تنها اسناد HTML تولید می‌کند.

برای نکات نصب اختصاصی هر سیستم، از پایگاه دانش ISC به نشانی https://kb.isc.org/docs/installing-kea دیدن کنید..SS نصب از کد منبع

اگرچه ممکن است Kea به‌صورت بسته‌های از پیش کامپایل‌شده و آمادهٔ استفاده از سوی توزیع‌کنندگان سیستم‌عامل ارائه شده باشد، اما این نرم‌افزار، یک نرم‌افزار متن‌باز است که به زبان ++C نوشته شده است. به همین جهت، به‌صورت کد منبع آزاد و در قالب یک فایل tar قابل بارگیری از سوی ISC عرضه می‌شود. همچنین کد منبع را می‌توان از مخزن گیت‌لب Kea در https://gitlab.isc.org/isc-projects/kea دریافت کرد. این بخش نحوهٔ ساخت Kea از روی کد منبع را شرح می‌دهد.

فایل‌های فشردهٔ (tarball) انتشار Kea را می‌توان از نشانی زیر بارگیری کرد: https://downloads.isc.org/isc/kea.

فایل tar حاوی کد منبع به همراه امضای GPG آن توزیع می‌شود. امضا، فایلی هم‌نام با فایل tar است که پسوند .asc به انتهای آن اضافه شده است. می‌توانید فایل امضا را در صفحهٔ بارگیری ما، FTP یا CloudSmith پیدا کنید.

این امضا با استفاده از کلید امضای کد ISC ایجاد شده است. مجموعهٔ فعلی کلیدهای امضای کد ISC از طریق وب‌سایت ISC در https://www.isc.org/pgpkey (پیوند Current Set of ISC Code-Signing Keys در https://www.isc.org/docs/isc-keyblock.asc) در دسترس است.

امضا را می‌توان با استفاده از ابزار gpg از GnuPG اعتبارسنجی کرد. دستورهای زیر کلیدهای امضای کد (isc-keyblock.asc) را وارد (import) کرده و امضا را بررسی می‌کنند:

$ gpg --import isc-keyblock.asc
$ gpg --verify kea-X.Y.Z.tar.xz.asc kea-X.Y.Z.tar.xz

این اعتبارسنجی به کاربران اجازه می‌دهد مطمئن شوند فایل tar دستکاری نشده و توسط ISC ساخته شده است.

جدیدترین کدهای در حال توسعه در GitLab در دسترس است (ببینید: https://gitlab.isc.org/isc-projects/kea). کد منبع Kea عمومی است و توسعه در شاخهٔ «master» انجام می‌شود.

بارگیری این کدِ "bleeding edge" تنها به توسعه‌دهندگان یا کاربران پیشرفته پیشنهاد می‌شود. استفاده از کدهای در حال توسعه در محیط‌های عملیاتی توصیه نمی‌شود.

نکته:

هنگام ساخت از روی کد منبع دریافت‌شده از طریق git، به نرم‌افزارهای جانبی نیاز است: automake (نسخهٔ 1.11 یا بالاتر)، libtoolize و autoconf (نسخهٔ 2.69 یا بالاتر). ممکن است نیاز به نصب این موارد داشته باشید.

کد را می‌توان از https://gitlab.isc.org/isc-projects/kea.git دریافت (clone) کرد:

$ git clone https://gitlab.isc.org/isc-projects/kea.git

کد دریافت شده از مخزن git شامل فایل‌های ساخت نیست. آن‌ها را می‌توان با اجرای meson setup build ایجاد کرد.

دسترسی نوشتن به مخزن Kea تنها به کارکنان ISC اعطا می‌شود. توسعه‌دهندگانی که قصد مشارکت در Kea را دارند باید به راهنمای مشارکت‌کنندگان (Contributor's Guide) در https://gitlab.isc.org/isc-projects/kea/blob/master/contributors-guide.md مراجعه کنند. راهنمای توسعه‌دهندگان Kea (Kea Developer's Guide) در https://reports.kea.isc.org/dev_guide حاوی اطلاعات بیشتری دربارهٔ این فرآیند است و نیازمندی‌های پذیرش کد مشارکت‌شده توسط ISC را شرح می‌دهد.

نرم‌افزار Kea از ابزار Meson برای شناسایی جزئیات محیط ساخت استفاده می‌کند. برای تولید فایل ninja با استفاده از مقادیر پیش‌فرض، کافی است دستور زیر را اجرا کنید:

$ meson setup build

برای مشاهدهٔ گزینه‌های مختلف ساخت، دستور meson configure را اجرا کنید. برخی از گزینه‌های پرکاربرد عبارت‌اند از:

  • --prefix تعیین محل نصب (پیش‌فرض /usr/local است).
  • -D mysql=enabled ساخت Kea به همراه کدی که امکان ذخیرهٔ اجاره‌ها (leases) و رزروهای میزبان (host reservations) را در یک پایگاه‌دادهٔ MySQL فراهم می‌کند.
  • -D postgresql=enabled ساخت Kea به همراه کدی که امکان ذخیرهٔ اجاره‌ها و رزروهای میزبان را در یک پایگاه‌دادهٔ PostgreSQL فراهم می‌کند.
  • -D krb5=enabled ساخت Kea با پشتیبانی از Kerberos5 به همراه GSS-API که توسط libddns_gss_tsig.so <#std-ischooklib-libddns_gss_tsig.so> الزامی است.
  • -D netconf=enabled ساخت Kea با پشتیبانی از libyang و sysrepo که توسط kea-netconf <#std-iscman-kea-netconf> الزامی است.
  • -D crypto=botan استفاده از کتابخانهٔ رمزنگاری Botan به جای OpenSSL. ابزار Meson کتابخانه‌های pkg-config مربوط به 'botan-3' و 'botan' را جستجو می‌کند.
  • --D crypto=openssl استفاده از کتابخانهٔ رمزنگاری OpenSSL. به‌طور پیش‌فرض مقدار گزینهٔ 'crypto' برابر با 'openssl' است.

نکته:

برای دستورالعمل‌های مربوط به نصب و پیکربندی بک‌اند‌های پایگاه‌داده برای Kea، بخش DHCP Database Installation and Configuration را ببینید.

اگر اجرای meson setup build ناموفق بود، ممکن است به دلیل وابستگی‌های مفقود یا قدیمی باشد.

هنگامی که meson setup build با موفقیت انجام شود، گزارشی از پارامترهای استفاده‌شده برای ساخت کد را نمایش می‌دهد. این گزارش در فایل build/config.report ذخیره شده و همچنین در باینری‌های اجرایی تعبیه می‌شود؛ مانند kea-dhcp6 <#std-iscman-kea-dhcp6>..SS ساخت

پس از تکمیل مرحلهٔ برپایی (setup)، با اجرای فرمان زیر فایل‌های اجرایی را از کد C++ ساخته و اسکریپت‌های Python را آماده کنید:

$ meson compile -C build

برای نصب فایل‌های اجرایی، فایل‌های پشتیبان، و مستندات Kea، فرمان زیر را صادر کنید:

$ meson install -C build

نکته:

مرحلهٔ نصب ممکن است به دسترسی‌های مدیر سیستم (superuser) نیاز داشته باشد.

این کار نباید لازم باشد، اما اگر کتابخانه‌های اشتراکی در زمان اجرا پیدا نشدند، می‌توانید ldconfig را با دسترسی ریشه (root) و قرار دادن /usr/local/lib (یا با ${prefix}/lib اگر با --prefix برپا شده باشد) در /etc/ld.so.conf (یا فایل پیکربندی مربوط به کش پیونددهنده در سیستم‌عامل) اجرا کنید:

$ ldconfig

اگر ldconfig در جایی که لازم است اجرا نشود، کاربران ممکن است با خطاهایی مانند زیر مواجه شوند:

program: error while loading shared libraries: libkea-something.so.1:
cannot open shared object file: No such file or directory

Kea اطلاعات اجاره‌های خود (leases) را در یک پایگاه‌دادهٔ اجاره ذخیره می‌کند. این نرم‌افزار به گونه‌ای نوشته شده است که امکان انتخاب محصول پایگاه‌داده برای ذخیرهٔ اطلاعات اجاره را فراهم می‌سازد. Kea از سه backend پایگاه‌داده پشتیبانی می‌کند: MySQL، PostgreSQL، و memfile. برای محدود کردن وابستگی‌های خارجی، پشتیبانی از MySQL و PostgreSQL به‌طور پیش‌فرض غیرفعال است و تنها memfile در دسترس می‌باشد. پشتیبانی از backend اختیاری پایگاه‌دادهٔ خارجی باید هنگام ساخت Kea به‌صراحت گنجانده شود. این بخش نحوهٔ ساخت Kea به همراه یکی از backendهای اختیاری و ایجاد پایگاه‌دادهٔ اجاره را پوشش می‌دهد.

نکته:

هنگامی که آزمون‌های واحد (unit tests) به همراه Kea ساخته می‌شوند (یعنی گزینهٔ پیکربندی -D tests=enabled مشخص شده باشد)، پایگاه‌های داده برای اجرای آزمون‌های واحد باید به‌صورت دستی از پیش پیکربندی شوند. جزئیات این پیکربندی را می‌توان در Kea Developer's Guide https://reports.kea.isc.org/dev_guide یافت.

MySQL را بر اساس دستورالعمل‌های سیستم خود نصب کنید. کتابخانه‌های توسعهٔ کلاینت (client development libraries) باید نصب شده باشند.

Kea را طبق آنچه در بخش Installation شرح داده شده است بسازید و نصب کنید، با این تغییر که: برای فعال‌سازی کد پایگاه‌دادهٔ MySQL، در مرحلهٔ برپایی (نگاه کنید به Set Up the Build)، سوییچ -D mysql=enabled باید مشخص شود:

$ meson setup build -D mysql=enabled

اگر MySQL در مکان پیش‌فرض نصب نشده باشد، می‌توان این مکان را با مقداردهی PKG_CONFIG_PATH=/path/to/mariadb.pc:${PKG_CONFIG_PATH} یا PATH=/path/to/mariadb-config:${PATH} پیش از اجرای meson setup مشخص کرد.

$ PKG_CONFIG_PATH=/opt/mariadb/lib/pkgconfig PATH=/opt/mariadb/bin meson setup build -D mysql=enabled

برای جزئیات مربوط به پیکربندی پایگاه‌دادهٔ MySQL، به First-Time Creation of the MySQL Database <#mysql-database-create> مراجعه کنید.

PostgreSQL را بر اساس دستورالعمل‌های سیستم نصب کنید. کتابخانه‌های توسعهٔ کلاینت باید نصب شده باشند. کتابخانه‌های توسعهٔ کلاینت اغلب در بسته‌ای به نام libpq عرضه می‌شوند.

Kea را همان‌طور که در بخش Installation شرح داده شده است بسازید و نصب کنید، با این تغییر که: برای فعال‌سازی کد پایگاه‌دادهٔ PostgreSQL، در مرحلهٔ برپایی (نگاه کنید به Set Up the Build)، سوییچ -D postgresql=enabled باید مشخص شود.

اگر PostgreSQL در مکان پیش‌فرض نصب نشده باشد، می‌توان این مکان را با مقداردهی PKG_CONFIG_PATH=/path/to/libpq.pc:${PKG_CONFIG_PATH} یا PATH=/path/to/pg_config:${PATH} پیش از اجرای meson setup تعیین کرد.

$ PKG_CONFIG_PATH=/opt/postgresql/lib/pkgconfig PATH=/opt/postgresql/bin meson setup build -D postgresql=enabled

برای جزئیات مربوط به پیکربندی پایگاه‌دادهٔ PostgreSQL، به First-Time Creation of the PostgreSQL Database <#pgsql-database-create> مراجعه کنید..SS ابزار ساخت Hammer

برنامهٔ Hammer یک اسکریپت Python 3 است که به کاربران اجازه می‌دهد وظایف مربوط به ساخت Kea را به‌طور خودکار انجام دهند، مانند راه‌اندازی ماشین‌های مجازی، نصب وابستگی‌های Kea، کامپایل Kea با گزینه‌های گوناگون، اجرای unit-testها و موارد دیگر. این ابزار اساساً برای اهداف تضمین کیفیت (QA) داخلی در ISC ایجاد شده است و در توزیع Kea گنجانده نشده است؛ با این حال، در مخزن git متعلق به Kea در دسترس است. این ابزار اساساً برای اهداف داخلی توسعه یافته است و ISC نمی‌تواند عملکرد صحیح آن را تضمین کند. مدیران سیستمی که تصمیم به استفاده از آن می‌گیرند باید این کار را با احتیاط انجام دهند.

نکته:

استفاده از این ابزار کاملاً اختیاری است. هر کاری که این ابزار انجام می‌دهد را می‌توان به‌صورت دستی انجام داد.

به کاربری که برای نخستین بار از آن استفاده می‌کند اکیداً توصیه می‌شود به راهنمای توکار Hammer نگاهی بیندازد:

$ ./hammer.py --help

این دستور پارامترهای موجود را فهرست خواهد کرد.

ابزار Hammer قادر است سیستم‌عامل‌های گوناگونی را که در LXC یا VirtualBox اجرا می‌شوند راه‌اندازی کند. برای مشاهدهٔ فهرستی از سیستم‌های پشتیبانی‌شده، از دستور supported-systems استفاده کنید:

$ ./hammer.py supported-systems
fedora:
  - 37: lxc
  - 38:
centos:
  - 8: lxc, virtualbox
  - 9:
rhel:
  - 8: virtualbox
  - 9:
ubuntu:
  - 18.04: lxc, virtualbox
  - 20.04: lxc
  - 22.04: lxc
debian:
  - 10: lxc, virtualbox
  - 11: lxc
  - 12: lxc
freebsd:
  - 12.0: virtualbox
  - 12.1:
  - 13.0: virtualbox
alpine:
  - 3.15: lxc
  - 3.16: lxc
  - 3.17: lxc

همچنین امکان اجرای ساخت به‌صورت محلی، در سیستم جاری وجود دارد (اگر سیستم‌عامل پشتیبانی شود).

نخست، باید وابستگی‌های Hammer نصب شوند: Vagrant و یکی از دو برنامهٔ VirtualBox یا LXC. برنامهٔ Hammer می‌تواند Vagrant و افزونه‌های مورد نیاز Vagrant را با استفاده از دستور زیر نصب کند:

$ ./hammer.py ensure-hammer-deps

برنامه‌های VirtualBox و LXC باید به‌صورت دستی نصب شوند.

کارکردهای پایه‌ای ارائه‌شده توسط Hammer عبارتند از آماده‌سازی محیط ساخت و انجام فرآیند واقعی ساخت، و اجرای unit testها به‌صورت محلی در سیستم جاری. این کار را می‌توان با اجرای دستور زیر انجام داد:

$ ./hammer.py build -p local

دامنهٔ فرآیند را می‌توان با استفاده از گزینه‌های --with (-w) و --without (-x) تعیین کرد. به‌طور پیش‌فرض، دستور build برنامهٔ Kea را به همراه مستندات می‌سازد، آن را به‌صورت محلی نصب می‌کند، و unit testها را اجرا می‌نماید.

برای مستثنی کردن نصب و تولید مستندات، وارد کنید:

$ ./hammer.py build -p local -x install docs

دامنهٔ پایه را می‌توان با mysql، pgsql، native-pkg، shell و forge گسترش داد. لطفاً برای جزئیات بیشتر به ./hammer.py build --help مراجعه کنید.

نکته:

در صورت ساخت محلی Kea، به وابستگی‌های Hammer مانند Vagrant نیازی نیست.

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

$ ./hammer.py prepare-system -p virtualbox -s freebsd -r 12.0

به این ترتیب، می‌توان سیستمی را برای استفادهٔ خود آماده کرد.

برای آماده‌سازی چنین سیستمی با استفاده از SSH، دستور زیر را اجرا کنید:

$ ./hammer.py ssh -p virtualbox -s freebsd -r 12.0

می‌توان سرعت ساخت‌های بعدی Hammer را از طریق ccache https://ccache.samba.org افزایش داد. در حین کامپایل، ccache اشیاء را در یک پوشهٔ اشتراکی ذخیره می‌کند. در اجراهای بعدی، ccache به‌جای انجام یک کامپایل واقعی، اشیاء ذخیره‌شدهٔ پیشین را بازمی‌گرداند. حافظهٔ کش محتوی این اشیاء جهت استفادهٔ مجدد باید در خارج از VM یا LXC ذخیره شود. برای مشخص کردن این پوشه، پارامتر --ccache-dir باید برای Hammer درج شود. در پوشهٔ تعیین‌شده، برای هر سیستم‌عامل مقصد اشیاء ذخیره‌شدهٔ جداگانه‌ای وجود دارد.

$ ./hammer.py build -p lxc -s ubuntu -r 18.04 --ccache-dir ~/kea-ccache

نکته:

در حال حاضر ccache در Hammer فقط برای LXC پشتیبانی می‌شود؛ پشتیبانی از VirtualBox ممکن است بعداً افزوده شود.

برای اطلاعات بیشتر بررسی کنید:

$ ./hammer.py --help

هر دو کارساز DHCPv4 و DHCPv6 در Kea عملیاتی را انجام می‌دهند که به‌طور کلی نیازمند دسترسی‌ها و امتیازات کاربر ریشه (root) است. به‌ویژه، DHCPv4 سوکت‌های raw را باز می‌کند و هر دو کارساز DHCPv4 و DHCPv6 سوکت‌های UDP را روی درگاه‌های ممتاز (privileged) باز می‌کنند. با این حال، با انجام برخی پیکربندی‌های سیستمی اضافی، امکان اجرای Kea از حساب‌های کاربری غیرریشه وجود دارد.

ابتدا، باید یک حساب کاربری عادی ایجاد شود:

useradd admin

سپس، مالکیت و گروه فایل‌های اجرایی (binaries) را به کاربر جدید تغییر دهید. توجه داشته باشید که مسیر دقیق ممکن است متفاوت باشد. لطفاً به پارامتر --prefix که به meson setup داده شده است مراجعه کنید:

chown -R admin /opt/kea
chgrp -R admin /opt/kea
chown -R admin /var/log/kea/kea-dhcp4.log
chgrp -R admin /var/log/kea/kea-dhcp4.log
chown -R admin /var/log/kea/kea-dhcp6.log
chgrp -R admin /var/log/kea/kea-dhcp6.log

در صورت استفاده از systemd، فایل سرویس آن را ویرایش کنید (برای نمونه /etc/systemd/system/kea-dhcp6.service):

User=admin
Group=admin

مهم‌ترین مرحله، تنظیم قابلیت‌های (capabilities) فایل‌های باینری است. برای اطلاعات بیشتر به صفحهٔ راهنمای سیستم‌عامل برای capabilities مراجعه کنید.

setcap 'cap_net_bind_service,cap_net_raw=+ep' /opt/kea/sbin/kea-dhcp4
setcap 'cap_net_bind_service=+ep' /opt/kea/sbin/kea-dhcp6

در صورت استفاده از systemd، این مقدار را نیز به فایل سرویس اضافه کنید (برای نمونه /etc/systemd/system/kea-dhcp6.service):

ExecStartPre=setcap 'cap_net_bind_service=+ep' /opt/kea/sbin/kea-dhcp6

پس از تکمیل این مرحله، کاربر admin باید قادر به اجرای Kea باشد. توجه داشته باشید که کارساز DHCPv4 به‌طور پیش‌فرض سوکت‌های raw را باز می‌کند. اگر شبکه فقط از ترافیک بازپخش‌شده (relayed) استفاده می‌کند، می‌توان Kea را طوری تنظیم کرد که از سوکت‌های معمولی UDP استفاده کند (به پارامتر dhcp-socket-type در بخش پیکربندی رابط <#dhcp4-interface-configuration> مراجعه کنید) و در نتیجه می‌توان از قابلیت cap_net_raw صرف‌نظر کرد.

نکته:

امکان جلوگیری از اجرای Kea با امتیازات ریشه با هدایت Kea به استفاده از درگاه‌های غیرممتاز (بزرگ‌تر از 1024) و بازهدایت (redirecting) ترافیک وجود دارد. با این حال، این روش فقط برای ترافیک رله‌شده کار می‌کند. این رویکرد به‌طور کلی آزمایشی در نظر گرفته می‌شود و برای به‌کارگیری در محیط‌های عملیاتی آزمایش نشده است. با احتیاط استفاده کنید!

برای استفاده از این روش، کارساز را طوری پیکربندی کنید که با اجرای فرایند به همراه گزینهٔ -p در /etc/systemd/system/kea-dhcp4.service روی دیگر درگاه‌های غیرممتاز (مانند 1547 و 1548) شنود کند:

ExecStart=/opt/kea/sbin/kea-dhcp4 -d -c /etc/kea/kea-dhcp4.conf -p 2067

و در /etc/systemd/system/kea-dhcp4.service:

ExecStart=/opt/kea/sbin/kea-dhcp6 -d -c /etc/kea/kea-dhcp6.conf -p 1547

سپس بازهدایت درگاه را با iptables و ip6tables برای درگاه‌های جدید (مانند 1547 و 1548) پیکربندی کنید. حتماً ens4 را با نام رابط شبکهٔ موردنظر جایگزین کنید.

iptables -t nat -A PREROUTING -i ens4 -p udp --dport 67 -j REDIRECT --to-port 2067
iptables -t nat -A PREROUTING -i ens4 -p udp --dport 2068 -j REDIRECT --to-port 68
ip6tables -t nat -A PREROUTING -i ens4 -p udp --dport 547 -j REDIRECT --to-port 1547
ip6tables -t nat -A PREROUTING -i ens4 -p udp --dport 1548 -j REDIRECT --to-port 548

این بخش ویژگی‌های مهمی را که حذف شده‌اند یا قرار است حذف شوند فهرست می‌کند. ما تلاش می‌کنیم پیش از حذف ویژگی‌ها، آن‌ها را منسوخ اعلام کنیم تا کاربران فعلی فرصت برنامه‌ریزی برای مهاجرت را داشته باشند. کاربران جدید نباید به ویژگی‌های منسوخ‌شده تکیه کنند..SS Sysrepo 0.x یا 1.x

در نسخه 2.3.2 از Kea پشتیبانی از Sysrepo 2.x معرفی شد. متأسفانه Sysrepo همچنان دستخوش تغییرات اساسی ناسازگار با نسخه‌های پیشین (backward-incompatible) است، و نسخه‌های کنونی Kea از نگارش‌های پیش از 2.x در Sysrepo پشتیبانی نمی‌کنند.

می‌توان Kea را به گونه‌ای پیکربندی کرد که از یک پایگاه داده به عنوان محل ذخیره‌سازی اجاره‌ها (leases) یا به عنوان منبعی برای پیکربندی سرورها و رزروهای میزبان (یعنی تخصیص ایستا برای نشانی‌ها، پیشوندها، گزینه‌ها و غیره) استفاده نماید. با به‌روزرسانی Kea، اسکیماهای (schemas) جدیدی برای پایگاه داده معرفی می‌شوند تا پیاده‌سازی قابلیت‌های جدید تسهیل شده و اشکالات کشف‌شده در اسکیماهای پیشین برطرف گردند.

هر نسخه از Kea ساختار اسکیمای مشخصی را انتظار دارد و با بررسی نسخه پایگاه داده‌ای که استفاده می‌کند، این مورد را ارزیابی می‌نماید. شماره نسخه‌های مجزایی برای اسکیماها مستقل از نسخه خودِ Kea نگهداری می‌شوند. این امکان وجود دارد که نسخه اسکیما در طول چندین بازنگری Kea ثابت بماند؛ به همین ترتیب این احتمال وجود دارد که نسخه اسکیما در جریان یک ارتقای تکی نسخه Kea، چندین نگارش افزایش یابد. نسخه‌ها برای هر نوع بک‌اند (backend) نیز مستقل هستند، بنابراین افزایش نسخه در بک‌اند MySQL به معنای افزایش در نسخه PostgreSQL نخواهد بود.

نسخه‌های اسکیما در قالب major.minor مشخص می‌شوند. در جدیدترین نسخه‌ها، نسخه minor همیشه صفر بوده و تنها نسخه major افزایش می‌یابد.

از نظر تاریخی، نسخه minor زمانی افزایش می‌یافت که تغییرات سازگار با گذشته (backward-compatible) در اسکیما اعمال می‌شد؛ برای نمونه، هنگامی که یک نمایه (index) جدید افزوده می‌شد. این امر در مقابل افزایش نسخه major بود که تغییر ناسازگار در اسکیما را نشان می‌داد؛ برای نمونه تغییر نوع یک ستون موجود. اگر Kea تلاش کند روی اسکیمایی اجرا شود که بیش از حد قدیمی است (همان‌طور که از عدم تطابق نسخه اسکیما مشخص می‌شود)، ناموفق خواهد بود؛ در این حالت برای ارتقای اسکیما به اقدام مدیریتی نیاز است.

برای مدیریت پایگاه‌های داده، Kea ابزار kea-admin <#std-iscman-kea-admin> را ارائه می‌دهد. این ابزار می‌تواند یک بک‌اند جدید را مقداردهی اولیه کند، شماره نسخه آن را بررسی نماید، ارتقای بک‌اند را انجام دهد، و داده‌های اجاره (lease) را در یک فایل متنی ذخیره (dump) کند.

دستور kea-admin <#std-iscman-kea-admin> دو پارامتر اجباری دریافت می‌کند: command و backend. گزینه‌های غیراجباری دیگری نیز ممکن است مشخص شوند. دستورهای پشتیبانی‌شده کنونی عبارتند از:

  • db-init — یک اسکیمای جدید پایگاه داده را مقداردهی اولیه می‌کند که هنگام نصب تازه Kea سودمند است. پایگاه داده جدید مطابق با نسخه Kea در حال نصب به‌روزرسانی می‌شود. در صورتی که حین راه‌اندازی یا پیکربندی مجدد سرورهای Kea DHCP عدم وجود اسکیما تشخیص داده شود، kea-admin <#std-iscman-kea-admin> به طور خودکار با این دستور فراخوانی می‌شود.
  • db-version — شماره نسخه بک‌اند پایگاه داده را گزارش می‌دهد. این مقدار لزوماً با شماره نسخه Kea یکسان نیست، چرا که هر بک‌اند طرح نسخه‌گذاری مختص به خود را دارد.
  • db-upgrade — یک ارتقای اسکیمای پایگاه داده را انجام می‌دهد. این دستور هنگام ارتقای Kea کاربرد دارد.
  • lease-dump — محتویات پایگاه داده اجاره را (برای بک‌اندهای MySQL یا PostgreSQL) در یک فایل متنی CSV (مقادیر جداشده با کاما) استخراج می‌کند (dump).

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

  • lease-upload — اجاره‌ها را از یک فایل متنی CSV (مقادیر جداشده با کاما) به یک پایگاه داده اجاره MySQL یا PostgreSQL بارگذاری می‌کند. فایل CSV باید در قالب memfile باشد.

پارامتر backend نوع پایگاه داده بک‌اند را مشخص می‌کند. انواع پشتیبانی‌شده کنونی عبارتند از:

  • memfile — اطلاعات اجاره بر روی دیسک در یک فایل متنی ذخیره می‌شود.
  • mysql — اطلاعات در یک پایگاه داده رابطه‌ای MySQL ذخیره می‌شود.
  • pgsql — اطلاعات در یک پایگاه داده رابطه‌ای PostgreSQL ذخیره می‌شود.

بسته به راه‌اندازی و عملیات مورد نظر، ممکن است به پارامترهای بیشتری نیاز باشد: نام کاربری (username)، گذرواژه (password)، و نام پایگاه داده یا دایرکتوری محل قرارگیری فایل‌های مشخص. برای جزئیات به صفحه راهنمای مربوطه مراجعه کنید (man 8 kea-admin).

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

ویژگی Memfile MySQL PostgreSQL
وضعیت پایدار پایدار پایدار
قالب داده فایل CSV SQL RMDB SQL RMDB
اجاره‌ها بله بله بله
رزروهای میزبان خیر بله بله
گزینه‌های تعریف‌شده برای هر میزبان خیر بله بله
بک‌اند پیکربندی خیر بله بله
Memfile
بک‌اند memfile قادر به ذخیره اطلاعات اجاره (lease) است، اما نمی‌تواند
جزئیات رزرو میزبان را ذخیره کند؛ این اطلاعات باید در فایل
پیکربندی ذخیره شوند. (هیچ برنامه‌ای برای افزودن قابلیت ذخیره‌سازی
رزروهای میزبان به این بک‌اند وجود ندارد.)
هیچ مرحله راه‌اندازی اولیه‌ی خاصی برای بک‌اند memfile لازم نیست.
در طول نخستین اجرا، هم kea-dhcp4 <#std-iscman-kea-dhcp4> و هم kea-dhcp6 <#std-iscman-kea-dhcp6> در
صورت عدم وجود فایل اجاره، یک فایل اجاره‌ی خالی ایجاد می‌کنند. داشتن
مجوز لازم برای نوشتن روی دیسک مورد نیاز است.
"ارتقای فایل‌های اجاره Memfile از نسخه‌های پیشین Kea"
برای ارتقای فایل‌های اجاره memfile میان نسخه‌های Kea به هیچ
مرحله‌ی خاصی نیاز نیست. در زمان راه‌اندازی، کارسازها
نسخه شمای فایل‌های اجاره را با نسخه شمای خود بررسی و تطبیق می‌دهند.
اگر عدم تطابقی وجود داشته باشد، کارسازها به‌طور خودکار فرایند
LFC را اجرا می‌کنند تا فایل‌ها را به نسخه شمای کارساز تبدیل کند. در حالی که
هدف اصلی این سازوکار تسهیل فرایند ارتقا به نسخه‌های
جدیدتر Kea است، در صورت نیاز می‌تواند برای تنزیل نسخه (downgrade) نیز
به کار رود. هنگام ارتقا، به هر مقداری که در فایل‌های اجاره اولیه
موجود نباشد، مقادیر پیش‌فرض مناسب اختصاص می‌یابد. هنگام تنزیل، هر
داده‌ای که در فایل‌ها موجود باشد اما در شمای کارساز وجود نداشته باشد،
حذف می‌شود. برای تبدیل دستی فایل‌ها پیش از راه‌اندازی
کارسازها، فرایند پاک‌سازی فایل اجاره (LFC) را اجرا کنید. برای اطلاعات بیشتر بخش «فرایند LFC» <#kea-lfc> را ببینید.
MySQL
پایگاه داده MySQL قادر است اجاره‌ها، رزروهای میزبان، گزینه‌های تعریف‌شده به‌ازای
هر میزبان، و زیرمجموعه‌ای از پارامترهای پیکربندی کارساز را ذخیره کند
(و به‌عنوان بک‌اند پیکربندی عمل نماید).
"مقایسه MySQL 5.7 با MySQL 8 و MariaDB 10 و 11"
در آزمایش‌های کارایی Kea، نسخه MySQL 8 افتی ۶۰ تا ۹۰ درصدی در سرعت
در مقایسه با MySQL 5.7 نشان می‌دهد.
با توجه به پایان عمر (EOL) قریب‌الوقوع MySQL 5.7، توصیه می‌کنیم به جای MySQL 8 از MariaDB استفاده کنید.
نسخه‌های MySQL 5.7، MySQL 8، MariaDB 10، و MariaDB 11 کاملاً سازگار،
قابل جایگزینی با یکدیگر، و همراه با Kea آزمایش شده‌اند.
نکته:
0.0
3.5
نگارش MySQL یا MariaDB مورد استفاده شما باید از پردازش JSON پشتیبانی کند. مواردی که در بالا
فهرست شده‌اند یا جدیدتر باید پشتیبانی کنند. این موضوع را می‌توان با دستور SQL زیر بررسی کرد:
0.0
3.5
mysql> SELECT JSON_EXTRACT('{ "foo-bar": 1 }', '$."foo-bar"');
+-------------------------------------------------+
| JSON_EXTRACT('{ "foo-bar": 1 }', '$."foo-bar"') |
+-------------------------------------------------+
| 1 |
+-------------------------------------------------+
1 row in set (0.01 sec)
168u
168u
هر نتیجه‌ی دیگری نشان می‌دهد که از JSON پشتیبانی نمی‌شود.
168u
168u
"ایجاد پایگاه داده MySQL برای نخستین بار"
پیش از آماده‌سازی هر پایگاه داده و جدول‌های ویژه Kea، پایگاه داده MySQL
باید طوری پیکربندی شود که از منطقه زمانی سیستم استفاده کند. توصیه می‌شود هم
برای سیستم و هم برای پایگاه داده MySQL از UTC به‌عنوان منطقه زمانی استفاده شود.
برای بررسی منطقه زمانی سیستم:
0.0
3.5
0.0
3.5
date +%Z
168u
168u
168u
168u
برای بررسی منطقه زمانی MySQL:
0.0
3.5
0.0
3.5
mysql> SELECT @@system_time_zone;
mysql> SELECT @@global.time_zone;
mysql> SELECT @@session.time_zone;
168u
168u
168u
168u
برای پیکربندی منطقه زمانی MySQL برای یک کارساز خاص، لطفاً به
مستندات نسخه نصب‌شده مراجعه کنید.
معمولاً این تنظیم در بخش [mysqld] در فایل‌های /etc/mysql/my.cnf،
/etc/mysql/mysql.cnf، /etc/mysql/mysqld.cnf، یا
/etc/mysql/mysql.conf.d/mysqld.cnf پیکربندی می‌شود.
0.0
3.5
0.0
3.5
[mysqld]
# using default-time-zone
default-time-zone='+00:00'
# or using timezone
timezone='UTC'
168u
168u
168u
168u
هنگام راه‌اندازی پایگاه داده MySQL برای نخستین بار، فضای
پایگاه داده باید در MySQL ایجاد شده و شناسه کاربری MySQL که Kea از طریق
آن به پایگاه داده دسترسی خواهد داشت تنظیم شود. این کار باید به‌صورت دستی انجام شود،
نه از طریق kea-admin <#std-iscman-kea-admin>.
برای ساخت پایگاه داده:
0.0
1. 3
با کاربر "root" وارد MySQL شوید:
3.0
3.5
$ mysql -u root -p
Enter password:
mysql>
168u
168u
2. 3
پایگاه داده MySQL را ایجاد کنید:
3.0
3.5
mysql> CREATE DATABASE database_name;
168u
168u
(database_name نام انتخاب‌شده برای پایگاه داده است.)
3. 3
کاربری را که Kea از طریق آن به پایگاه داده دسترسی خواهد داشت ایجاد کنید (و به
آن گذرواژه بدهید)، سپس دسترسی به جدول‌های پایگاه داده را به آن اعطا کنید:
3.0
3.5
mysql> CREATE USER 'user-name'@'localhost' IDENTIFIED BY '1234';
mysql> GRANT ALL ON database-name.* TO 'user-name'@'localhost';
168u
168u
(user-name و password شناسه کاربری و گذرواژه‌ای هستند که برای
دسترسی دادن به Kea به نمونه MySQL استفاده می‌شوند. تمام علامت‌های آپوستروف در
خطوط فرمان بالا الزامی هستند.)
4. 3
پایگاه داده را بسازید.
3.0
3.5
از کلاینت MySQL خارج شوید
0.0
3.5
mysql> quit
Bye
168u
168u
سپس از ابزار kea-admin <#std-iscman-kea-admin> برای ایجاد پایگاه داده استفاده کنید.
0.0
3.5
$ kea-admin db-init mysql -u database-user -p database-password -n database-name
168u
168u
اگرچه امکان ساخت پایگاه داده از داخل کلاینت MySQL وجود دارد، توصیه می‌کنیم
از ابزار kea-admin <#std-iscman-kea-admin> استفاده کنید؛ چرا که این ابزار برخی اعتبارسنجی‌های لازم را انجام می‌دهد تا اطمینان حاصل شود Kea می‌تواند
در زمان اجرا به پایگاه داده دسترسی داشته باشد. از جمله این بررسی‌ها، اطمینان از این است که شما فاقد
هرگونه جدول از پیش موجود باشد؛ هر جدول از پیش موجود باید به‌صورت
دستی حذف شود. یک بررسی دیگر، توانایی کاربر در ساخت توابع و
تریگرها را ارزیابی می‌کند. خطای زیر نشان می‌دهد که کاربر مجوزهای لازم
برای ایجاد توابع یا تریگرها را ندارد:
0.0
3.5
ERROR 1419 (HY000) at line 1: You do not have the SUPER privilege and binary logging is
enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
ERROR/kea-admin: mysql_can_create cannot trigger, check user permissions, mysql status = 1
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR/kea-admin: Create failed, the user, keatest, has insufficient privileges.
168u
168u
ساده‌ترین راهکار برای حل این مشکل، تنظیم متغیر سراسری MySQL یعنی
log_bin_trust_function_creators روی 1 از طریق کلاینت MySQL است.
توجه داشته باشید که این کار باید توسط کاربری با امتیازات SUPER انجام شود:
0.0
3.5
mysql> set @@global.log_bin_trust_function_creators = 1;
Query OK, 0 rows affected (0.00 sec)
168u
168u
برای ایجاد مستقیم پایگاه داده با MySQL، مراحل زیر را دنبال کنید:
0.0
3.5
mysql> CONNECT database-name;
mysql> SOURCE path-to-kea/share/kea/scripts/mysql/dhcpdb_create.mysql
168u
168u
168u
168u
(که در آن path-to-kea مکانی است که Kea در آن نصب شده است.)
3.0
3.5
همچنین می‌توان پایگاه داده را به‌صورت دستی به شکل زیر حذف (drop) کرد:
0.0
3.5
mysql> CONNECT database-name;
mysql> SOURCE path-to-kea/share/kea/scripts/mysql/dhcpdb_drop.mysql
168u
168u
168u
168u
(که در آن path-to-kea مکانی است که Kea در آن نصب شده است.)
168u
هشدار:
0.0
3.5
حذف پایگاه داده منجر به از دست رفتن غیرقابل بازیابی تمامی داده‌های موجود در آن می‌شود.
168u
168u
0.0.IP
خروج از MySQL:
3.0
3.5
mysql> quit
Bye
168u
168u
168u
اگر جدول‌ها در مرحله 4 ساخته نشده‌اند، اکنون ابزار kea-admin <#std-iscman-kea-admin> را
برای ایجاد آن‌ها اجرا کنید:
0.0
3.5
$ kea-admin db-init mysql -u database-user -p database-password -n database-name
168u
168u
اگر جدول‌ها در مرحله 4 ساخته شده‌اند، این کار را انجام ندهید. ابزار kea-admin <#std-iscman-kea-admin>
بررسی‌های اولیه‌ای انجام می‌دهد؛ اگر پایگاه داده حاوی هرگونه جدول موجود باشد، از مقداردهی
اولیه آن خودداری خواهد کرد. برای شروع از ابتدا،
همه داده‌ها باید به‌صورت دستی حذف شوند. (این فرآیند عمداً
یک عملیات دستی است تا از خطاهای تصادفی و جبران‌ناپذیر توسط kea-admin <#std-iscman-kea-admin> جلوگیری شود.)
ارتقای پایگاه داده MySQL از نسخه پیشین Kea
گاهی یک نسخه جدید Kea از شمای پایگاه داده جدیدتری استفاده می‌کند، بنابراین
پایگاه داده موجود باید ارتقا یابد. این کار را می‌توان با استفاده از
دستور kea-admin db-upgrade انجام داد.
برای بررسی نسخه فعلی پایگاه داده، از دستور زیر استفاده کنید:
0.0
3.5
$ kea-admin db-version mysql -u database-user -p database-password -n database-name
168u
168u
(برای بحث درباره نسخه‌بندی، بخش Databases and Schema Versions
را ببینید.) اگر نسخه با حداقل مقدار لازم برای نسخه جدید Kea
(همان‌طور که در یادداشت‌های انتشار آمده است) مطابقت ندارد، پایگاه داده باید ارتقا یابد.
پیش از ارتقا، لطفاً اطمینان حاصل کنید که از پایگاه داده نسخه پشتیبان تهیه شده است. فرآیند
ارتقا هیچ داده‌ای را حذف نمی‌کند، اما بسته به ماهیت تغییرات، ممکن است
پس از آن امکان بازگشت (downgrade) به نسخه پیشین وجود نداشته باشد.
برای انجام ارتقا، دستور زیر را اجرا کنید:
0.0
3.5
$ kea-admin db-upgrade mysql -u database-user -p database-password -n database-name
168u
168u
نکته:
0.0
3.5
برای جستجوی رزروهای میزبان (host reservations) بر اساس hostname، بسیار حیاتی است که ترتیب تطبیق (collation)
ستون hostname در جدول host به بزرگی و کوچکی حروف حساس نباشد (case-insensitive). خوشبختانه این
حالت پیش‌فرض در MySQL است، اما می‌توان با این دستور آن را تایید کرد:
0.0
3.5
mysql> SELECT COLLATION('');
+-----------------+
| COLLATION('') |
+-----------------+
| utf8_general_ci |
+-----------------+
168u
168u
طبق قواعد نام‌گذاری MySQL، هنگامی که نام به _ci ختم می‌شود،
تطبیق (collation) به بزرگی و کوچکی حروف غیرحساس است.
168u
168u
بهبود کارایی با MySQL
تغییر مقدار درونی MySQL یعنی innodb_flush_log_at_trx_commit از مقدار پیش‌فرض
1 به 2 می‌تواند منجر به بهبود چشمگیری در کارایی Kea شود. در برخی از پیاده‌سازی‌ها، این
بهبود بیش از 1000% بوده است (هنگام تنظیم روی 2، در مقایسه با مقدار پیش‌فرض 1، ۱۰ برابر سریع‌تر شده است).
برای آزمایش، می‌توان آن را به‌ازای هر نشست (per-session) تنظیم کرد:
0.0
3.5
mysql> SET GLOBAL innodb_flush_log_at_trx_commit=2;
mysql> SHOW SESSION VARIABLES LIKE 'innodb_flush_log%';
168u
168u
یا به‌صورت دائمی در /etc/mysql/my.cnf:
0.0
3.5
[mysqld]
innodb_flush_log_at_trx_commit=2
168u
168u
توجه داشته باشید که تغییر این مقدار ممکن است در طول بازیابی داده‌ها پس از فروپاشی (crash)
مشکلاتی ایجاد کند، بنابراین پیشنهاد می‌کنیم مستندات MySQL https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit را بررسی کنید.
با مقدار پیش‌فرض 1، MySQL پس از هر پرس‌وجوی INSERT یا UPDATE تغییرات را روی دیسک می‌نویسد
(در اصطلاح Kea، هر بار که یک کلاینت یک اجاره جدید دریافت می‌کند یا اجاره موجود را تمدید می‌کند). هنگامی که
innodb_flush_log_at_trx_commit روی 2 تنظیم شده باشد، MySQL تغییرات را در فواصل زمانی
حداکثر ۱ ثانیه می‌نویسد. دسته‌بندی عملیات‌های نوشتن، شتاب قابل‌توجهی به کارایی می‌دهد. با این حال،
موازنه این است که در بدترین سناریو، ممکن است تمام تغییرات در آخرین ثانیه قبل از فروپاشی
از دست بروند. با توجه به اینکه Kea نرم‌افزاری پایدار است و بسیار به‌ندرت دچار فروپاشی می‌شود،
بیشتر پیاده‌سازی‌ها این موازنه را سودمند می‌دانند..SS PostgreSQL
پایگاه داده‌ی PostgreSQL می‌تواند اجاره‌ها (leases)، رزروهای میزبان (host reservations) و گزینه‌های تعریف‌شده بر اساس هر میزبان (per-host) را ذخیره کند.
نکته:
0.0
3.5
نسخهٔ PostgreSQL مورد استفاده شما باید از پردازش JSON پشتیبانی کند. هر نسخه‌ای از 9.4 به بعد باید از آن پشتیبانی نماید. این موضوع را می‌توان با دستور SQL زیر بررسی کرد:
0.0
3.5
=> SELECT proname FROM pg_proc WHERE proname = 'json_extract_path';
proname
-------------------
json_extract_path
(1 row)
168u
168u
هر نتیجهٔ دیگری نشان‌دهندهٔ عدم پشتیبانی از JSON است.
168u
168u
ساخت اولیه پایگاه داده PostgreSQL
پیش از آماده‌سازی هرگونه پایگاه داده و جدول‌های ویژهٔ Kea، پایگاه دادهٔ PostgreSQL باید طوری پیکربندی شود که از منطقه زمانی (timezone) سیستم استفاده کند. توصیه می‌شود برای منطقه زمانی سیستم و پایگاه دادهٔ PostgreSQL از UTC استفاده شود.
برای بررسی منطقه زمانی سیستم:
0.0
3.5
0.0
3.5
date +%Z
168u
168u
168u
168u
برای بررسی منطقه زمانی PostgreSQL:
0.0
3.5
0.0
3.5
postgres=# show timezone;
postgres=# SELECT * FROM pg_timezone_names WHERE name = current_setting('TIMEZONE');
168u
168u
168u
168u
برای پیکربندی منطقه زمانی PostgreSQL برای یک سرور خاص، لطفاً به مستندات نسخهٔ نصب‌شده مراجعه کنید.
معمولاً این تنظیم در فایل postgresql.conf با مسیر متغیر بر اساس نسخه یعنی /etc/postgresql/<version>/main/postgresql.conf پیکربندی می‌شود، اما در برخی سیستم‌ها ممکن است این فایل‌ها در /var/lib/pgsql/data قرار داشته باشند.
0.0
3.5
0.0
3.5
timezone = 'UTC'
168u
168u
168u
168u
نخستین کار، ساخت پایگاه داده و کاربری است که کارگزارها با آن به پایگاه داده دسترسی خواهند داشت. چندین مرحله لازم است:
0.0
1. 3
با کاربر "postgres" به PostgreSQL وارد شوید:
3.0
3.5
$ sudo -u postgres psql postgres
Enter password:
postgres=#
168u
168u
2. 3
پایگاه داده را بسازید:
3.0
3.5
postgres=# CREATE DATABASE database-name;
CREATE DATABASE
postgres=#
168u
168u
(database-name نام انتخاب‌شده برای پایگاه داده است.)
3. 3
کاربری را که Kea از طریق آن به پایگاه داده دسترسی خواهد داشت بسازید (و برای آن گذرواژه‌ای تعیین کنید)، سپس دسترسی به پایگاه داده را به آن اعطا نمایید:
3.0
3.5
postgres=# CREATE USER user-name WITH PASSWORD '1234';
CREATE ROLE
postgres=# GRANT ALL PRIVILEGES ON DATABASE database-name TO user-name;
GRANT
postgres=# \c database-name
You are now connected to database "database-name" as user "postgres".
postgres=# GRANT ALL PRIVILEGES ON SCHEMA public TO user-name;
GRANT
postgres=#
168u
168u
4. 3
از PostgreSQL خارج شوید:
3.0
3.5
postgres=# \q
Bye
$
168u
168u
5. 3
در این مرحله، جدول‌های پایگاه داده را یا با استفاده از ابزار kea-admin <#std-iscman-kea-admin> آن‌گونه که در بخش بعدی توضیح داده شده است بسازید (توصیه‌شده)، یا به صورت دستی. برای ساخت دستی جدول‌ها، دستور زیر را وارد کنید. PostgreSQL از مدیر سیستم می‌خواهد گذرواژهٔ کاربر جدید را که در مرحله ۳ تعیین شده بود وارد کند. پس از تکمیل دستور، Kea به اعلان خط فرمان بازخواهد گشت. خروجی باید شبیه به موارد زیر باشد:
3.0
3.5
$ psql -d database-name -U user-name -f path-to-kea/share/kea/scripts/pgsql/dhcpdb_create.pgsql
Password for user user-name:
CREATE TABLE
CREATE INDEX
CREATE INDEX
CREATE TABLE
CREATE INDEX
CREATE TABLE
START TRANSACTION
INSERT 0 1
INSERT 0 1
INSERT 0 1
COMMIT
CREATE TABLE
START TRANSACTION
INSERT 0 1
COMMIT
$
168u
168u
(path-to-kea محل نصب Kea است.)
چنانچه به جای آن با خطایی مواجه شدید، مانند:
3.0
3.5
psql: FATAL: no pg_hba.conf entry for host "[local]", user "user-name", database "database-name", SSL off
168u
168u
... پیکربندی PostgreSQL نیاز به تغییر خواهد داشت. Kea هنگام اتصال به پایگاه داده از احراز هویت با گذرواژه استفاده می‌کند و باید مدخل‌های مناسب به فایل pg_hba.conf در PostgreSQL اضافه شوند. این فایل معمولاً در دایرکتوری اصلی داده‌های کارگزار PostgreSQL قرار دارد. مسیر دقیق ممکن است بسته به سیستم‌عامل و نسخه متفاوت باشد، اما مکان پیش‌فرض برای PostgreSQL مسیر /etc/postgresql/*/main/postgresql.conf است. با این حال، در برخی سیستم‌ها این فایل ممکن است در /var/lib/pgsql/data قرار داشته باشد.
با این فرض که Kea روی همان میزبانِ PostgreSQL اجرا می‌شود، افزودن خطوطی شبیه به موارد زیر برای فراهم کردن دسترسی مبتنی بر احراز هویت گذرواژه‌ای به پایگاه دادهٔ Kea کافی خواهد بود:
3.0
3.5
local database-name user-name password
host database-name user-name 127.0.0.1/32 password
host database-name user-name ::1/128 password
168u
168u
این ویرایش‌ها عمدتاً به عنوان یک نقطهٔ شروع در نظر گرفته شده‌اند و مرجعی قطعی برای مدیریت PostgreSQL یا امنیت پایگاه داده نیستند. لطفاً پیش از اعمال این تغییرات با راهنمای کاربری PostgreSQL مشورت کنید، زیرا این کار ممکن است سایر پایگاه‌های دادهٔ در حال اجرا را در معرض دسترسی قرار دهد. برای اعمال تغییرات ممکن است راه‌اندازی مجدد PostgreSQL لازم باشد.
اگر جدول‌ها به‌صورت دستی ایجاد نشده‌اند، اکنون با
اجرای ابزار kea-admin <#std-iscman-kea-admin> این کار را انجام دهید:
0.0
3.5
$ kea-admin db-init pgsql -u database-user -p database-password -n database-name
168u
168u
اگر جدول‌ها قبلاً به‌صورت دستی ایجاد شده‌اند، این کار را انجام ندهید. kea-admin <#std-iscman-kea-admin>
بررسی‌های اولیه‌ای انجام می‌دهد؛ اگر پایگاه داده شامل هرگونه جدول موجود باشد،
از مقداردهی اولیه آن خودداری خواهد کرد. برای شروع از ابتدا،
تمام داده‌ها باید به‌صورت دستی حذف شوند. (این فرآیند عمداً یک عملیات
دستی در نظر گرفته شده است تا از خطاهای تصادفی و جبران‌ناپذیر توسط kea-admin <#std-iscman-kea-admin> جلوگیری شود.)
ارتقای موتور PostgreSQL از یک نسخه قدیمی‌تر
اگر PostgreSQL خود را از نسخه‌ای قدیمی‌تر از 15.0 ارتقا داده‌اید، نیاز است
مجوزهای اضافی به کاربر اعطا کنید:
ابتدا، با عنوان کاربر "postgres" وارد PostgreSQL شوید:
0.0
3.5
0.0
3.5
$ sudo -u postgres psql -d database-name -U postgres
Enter password:
postgres=#
168u
168u
168u
168u
سپس، دسترسی به طرح‌واره (schema) public را اعطا کنید.
0.0
3.5
0.0
3.5
postgres=# GRANT ALL PRIVILEGES ON SCHEMA public TO user-name;
GRANT
postgres=#
168u
168u
168u
168u
اکنون، از کلاینت PostgreSQL خارج شوید:
0.0
3.5
0.0
3.5
postgres=# \q
Bye
$
168u
168u
168u
168u
ارتقای پایگاه داده PostgreSQL از نسخه قدیمی‌تر Kea
طرح‌واره پایگاه داده PostgreSQL را می‌توان با استفاده از همان ابزار و
دستورهای شرح‌داده‌شده در «ارتقای پایگاه داده MySQL از نسخه قدیمی‌تر Kea» ارتقا داد، با این استثنا که باید
از نوع backend پایگاه داده "pgsql" در دستورها استفاده شود.
برای بررسی نسخه فعلی طرح‌واره از دستور زیر استفاده کنید:
0.0
3.5
$ kea-admin db-version pgsql -u database-user -p database-password -n database-name
168u
168u
برای انجام ارتقا از دستور زیر استفاده کنید:
0.0
3.5
$ kea-admin db-upgrade pgsql -u database-user -p database-password -n database-name
168u
168u
بهبود کارایی با PostgreSQL
تغییر مقدار داخلی synchronous_commit در PostgreSQL از مقدار پیش‌فرض
ON به OFF می‌تواند منجر به بهبود چشمگیر کارایی Kea شود؛ در سیستم‌های کند، این بهبود
می‌تواند بیش از ۱۰۰۰٪ باشد. برای آزمایش، می‌توان آن را به ازای هر نشست (per-session) تنظیم کرد:
0.0
3.5
postgres=# SET synchronous_commit = OFF;
168u
168u
یا به صورت دائمی از طریق دستور (روش ترجیحی):
0.0
3.5
postgres=# ALTER SYSTEM SET synchronous_commit=OFF;
168u
168u
یا به صورت دائمی در فایل /etc/postgresql/[version]/main/postgresql.conf:
0.0
3.5
synchronous_commit = off
168u
168u
تغییر این مقدار می‌تواند در طول بازیابی داده‌ها پس از خرابی ناگهانی (crash)
مشکلاتی ایجاد کند، بنابراین توصیه می‌کنیم مستندات PostgreSQL را به نشانی https://www.postgresql.org/docs/current/wal-async-commit.html با دقت مطالعه کنید.
با مقدار پیش‌فرض ON، پایگاه داده PostgreSQL تغییرات را پس از هر پرس‌وجوی INSERT یا UPDATE روی دیسک می‌نویسد
(در اصطلاح Kea، هر بار که یک کلاینت یک اجاره (lease) جدید دریافت می‌کند یا اجاره موجود را تمدید می‌کند). هنگامی که
synchronous_commit روی OFF تنظیم شود، PostgreSQL قبل از نوشتن تغییرات مقداری تأخیر ایجاد می‌کند.
دسته‌بندی نوشتن‌ها بهبود کارایی قابل‌توجهی به همراه دارد،
اما در بدترین سناریو، ممکن است تمام تغییرات در آخرین لحظات قبل از خرابی ناگهانی
از دست بروند. از آنجا که Kea نرم‌افزاری پایدار است و بسیار به‌ندرت دچار خرابی می‌شود،
در اغلب استقرارها مزایای کارایی بر خطرات احتمالی برتری دارد..SS استفاده از پایگاه‌های داده فقط‌خواندنی با رزروهای میزبان
اگر از یک پایگاه داده فقط‌خواندنی برای ذخیره رزروهای میزبان (host reservations) استفاده شود، Kea باید
صریحاً برای کار با پایگاه داده در حالت فقط‌خواندنی (read-only) پیکربندی شود.
بخش‌های Using Read-Only Databases for Host Reservations With DHCPv4 <#read-only-database-configuration4> و
Using Read-Only Databases for Host Reservations with DHCPv6 <#read-only-database-configuration6> توضیح می‌دهند که چه زمانی
چنین پیکربندی‌ای ممکن است لازم باشد و چگونه Kea را برای کار به این شیوه برای هر دو پروتکل DHCPv4 و DHCPv6 پیکربندی کنید.
محدودیت‌های مربوط به استفاده از پایگاه‌های داده SQL
مسئله سال ۲۰۳۸
زمان انقضای اجاره (lease) در Kea برای هر اجاره به عنوان یک مقدار برچسب زمان (timestamp) در پایگاه داده SQL ذخیره
می‌شود. توسعه‌دهندگان Kea مشاهده کرده‌اند که پایگاه داده MySQL برچسب‌های زمانی فراتر از 2147483647 ثانیه (بیشینه عدد علامت‌دار
۳۲ بیتی) از ابتدای مبدأ یونیکس (00:00:00 در ۱ ژانویه ۱۹۷۰) را نمی‌پذیرد. برخی از نسخه‌های PostgreSQL مقادیر
بزرگ‌تر را می‌پذیرند، اما مقدار هنگام بازخوانی دستخوش تغییر می‌شود. به همین دلیل، بخش‌های پشتیبان (backends) پایگاه داده
اجاره، محدودیتی را بر روی بیشینه برچسب زمانی قابل ذخیره در پایگاه داده اعمال می‌کنند که برابر با بیشینه عدد علامت‌دار
۳۲ بیتی است. این امر عملاً به این معنی است که نسخه فعلی Kea نمی‌تواند اجاره‌هایی را ذخیره کند که زمان انقضای آن‌ها دیرتر
از 2147483647 ثانیه از آغاز مبدأ زمانی (حدود سال ۲۰۳۸) باشد. این مورد هنگامی که پشتیبانی پایگاه داده از برچسب‌های
زمانی طولانی‌تر فراهم شود، برطرف خواهد شد.
"امنیت KEA (KEA SECURITY)"
نرم‌افزار Kea در ابتدا برای نصب در یک محیط محافظت‌شده، در یک مرکز داده شبکه طراحی شده بود؛ این نرم‌افزار امکانات امنیتی
سخت‌گیرانه‌ای ارائه نمی‌داد. با این حال، به دلیل تقاضای کاربران و نیازمندی‌های رو به تحول شبکه، پشتیبانی از احراز هویت
پایه‌ای HTTP و پروتکل امنیت لایه انتقال (TLS) به Kea اضافه شده است.
پشتیبانی از TLS/HTTPS
از نسخه Kea 1.9.6، می‌توان از TLS برای امن‌سازی ارتباطات HTTP استفاده کرد. سه سطح حفاظتی ممکن وجود دارد:
0.0
• 2
بدون TLS. اتصال به صورت متن ساده (plain-text) و HTTP رمزگذاری‌نشده است. (این تنها گزینه موجود در نسخه‌های پیش از Kea 1.9.6 است.)
• 2
رمزنگاری، که در برابر حملات غیرفعال (passive) و شنود محافظت می‌کند. در این حالت، هویت کارگزار احراز می‌شود اما کلاینت
احراز هویت نمی‌شود. این حالت معمول هنگام امن‌سازی یک وب‌سایت است، جایی که کلاینت‌ها و کارگزارها تحت کنترل یک نهاد
مشترک نیستند.
• 2
احراز هویت متقابل (دوطرفه) بین کلاینت و کارگزار. این سخت‌گیرانه‌ترین حالت امنیتی است و هنگامی که TLS فعال باشد،
حالت پیش‌فرض است.
168u
نکته:
0.0
3.5
احراز هویت متقابل TLS صرفاً مختص موجودیت‌های TLS است. هنگامی که TLS و یک طرح احراز هویت HTTP همراه با یکدیگر استفاده می‌شوند،
هیچ پیوندی بین این دو سازوکار امنیتی وجود ندارد، و بنابراین هیچ اثباتی مبنی بر اینکه کلاینت و کارگزار TLS همان کلاینت و کارگزار
احراز هویت HTTP هستند وجود ندارد.
168u
168u
نکته:
0.0
3.5
توصیه می‌شود برای مقابله با حملات محلی (توسط کاربرانی که به سیستمی که کارگزارها/عامل‌های Kea روی آن اجرا می‌شوند متصل هستند)،
از پورت‌های دارای دسترسی ویژه (privileged ports) برای HTTP/HTTPS استفاده شود. این اقدام همچنین از جعل هویت در HTTP و به‌طور
کلی از حملات منع خدمت (Denial of Service) جلوگیری می‌کند.
168u
168u
نکته:
0.0
3.5
کارگزار هنگام تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از آدرس و پورت یکسان، خطا صادر خواهد کرد.
این عمل مجاز نیست چرا که ممکن است به دلیل اشتباه سهوی کاربر، یک رخنه امنیتی ایجاد کند.
هنگام استفاده از دستور "config-set" برای جابه‌جایی از HTTP به HTTPS یا از HTTPS به HTTP، باید یک آدرس یا پورت متفاوت
مشخص شود. همین موضوع هنگام ویرایش فایل پیکربندی و سپس اجرای دستور "config-reload" نیز صدق می‌کند.
168u
168u
ساخت Kea با پشتیبانی از TLS/HTTPS
پشتیبانی از TLS/HTTPS با هر دو کتابخانه رمزنگاری OpenSSL یا Botan در دسترس است. محدودیت‌هایی بر روی کتابخانه Boost وجود دارد
که باید رعایت شوند:
0.0
• 2
نسخه‌های OpenSSL قدیمی‌تر از 1.0.2 منسوخ شده‌اند و نباید استفاده شوند. پشتیبانی Kea از TLS با این نسخه‌ها آزمایش نشده و پشتیبانی نمی‌شود.
• 2
نسخه OpenSSL 1.0.2 دارای پشتیبانی تمدیدشده است، اما فقط برای مشتریان ویژه OpenSSL. پشتیبانی TLS در Kea با این نسخه آزمایش شده اما پشتیبانی نمی‌شود.
• 2
نسخه‌های OpenSSL 1.1.x و جدیدتر آزمایش شده‌اند و پشتیبانی می‌شوند. بسیاری از نسخه‌های اخیر سیستم‌عامل‌ها شامل پشتیبانی از TLS 1.3 هستند.
• 2
نسخه OpenSSL 3.x منتشر شده است و Kea با آن کامپایل و ساخته می‌شود.
• 2
نسخه LibreSSL 3.2.4 آزمایش شده است. LibreSSL دارای رابط برنامه‌نویسی (API) مشترک با OpenSSL 1.0.2 است، بنابراین باید کار کند، اما پشتیبانی نمی‌شود.
• 2
نسخه‌های Botan 1.x و 2.x منسوخ شده‌اند و نباید استفاده شوند.
• 2
نسخه‌های Botan 3.4.0 و جدیدتر آزمایش شده‌اند و پشتیبانی می‌شوند. پشتیبانی Kea از TLS نیازمند چهار فایل سرآیند Asio است که در بسته‌های
Botan گنجانده شده‌اند و تنها در صورتی نصب می‌شوند که Botan با گزینه --with-boost پیکربندی شده باشد.
بسیاری از بسته‌های ارائه‌شده توسط سیستم‌عامل‌ها، مانند Ubuntu 20.10، کتابخانه Botan را با پشتیبانی Boost نمی‌سازند،
که باعث می‌شود این بسته‌ها برای Kea همراه با TLS غیرقابل استفاده باشند.
همچنان امکان دریافت این فایل‌ها از توزیع متناظر Botan و نصب دستی آن‌ها در پوشه include مربوط به Botan وجود دارد،
اما این کار باید به عنوان آخرین راهکار در نظر گرفته شود.
بدون این فایل‌های سرآیند، یا با نسخه‌ای از Botan قدیمی‌تر از 3.4.0، برنامه Kea ساخته نمی‌شود زیرا پشتیبانی TLS/HTTPS
برای امنیت، ضروری در نظر گرفته می‌شود.
• 2
نسخه‌های بسیار قدیمی Boost پشتیبانی از SSL را (بر پایه OpenSSL) بدون ارائه امکان انتخاب نسخه TLS فراهم می‌کنند؛ Kea
همچنان می‌تواند از آن‌ها استفاده کند، اما توصیه نمی‌شوند.
• 2
نسخه‌های Boost پیش از 1.64 پشتیبانی از SSL را با یک نسخه ثابت TLS ارائه می‌دهند؛ Kea در این نسخه‌ها استفاده از TLS 1.2 را اجباری می‌کند.
• 2
نسخه‌های Boost 1.64 یا جدیدتر، پشتیبانی از SSL را با نسخه عمومی TLS ارائه می‌دهند؛ بهترین (بالاترین) نسخه موجود در هر دو
طرف ارتباط انتخاب می‌شود.
پارامترهای پیکربندی TLS عبارتند از:
0.0
• 2
trust-anchor - این پارامتر رشته‌ای، نام یک فایل یا دایرکتوری را مشخص می‌کند که گواهی مرجع صدور گواهی (CA) طرف مقابل در آن یافت می‌شود. در OpenSSL، دایرکتوری باید شامل پیوندهای نمادین هش (hash symbolic links) باشد. در Botan، دایرکتوری به‌صورت بازگشتی برای یافتن گواهی‌ها جستجو می‌شود.
• 2
cert-file - این پارامتر رشته‌ای، نام فایلی را مشخص می‌کند که حاوی گواهی نهاد نهایی (end-entity) نمونه‌ی Kea در حال پیکربندی است.
• 2
key-file - این پارامتر رشته‌ای، کلید خصوصی گواهی نهاد نهایی نمونه‌ی Kea در حال پیکربندی را مشخص می‌کند. این فایل نباید رمزگذاری شده باشد؛ اکیداً توصیه می‌شود دسترسی به آن محدود گردد.
168u
این سه پارامتر رشته‌ای باید یا همگی نامشخص باشند (TLS غیرفعال) یا همگی مشخص شوند (TLS فعال).
پروتکل TLS نامتقارن است: احراز هویت سرور توسط کلاینت اجباری است، اما احراز هویت کلاینت توسط سرور اختیاری می‌باشد. از نظر اصطلاحات TLS، این بدان معناست که سرور ممکن است گواهی کلاینت را الزامی بداند یا نداند؛ یک پارامتر TLS مخصوص سرور برای این منظور وجود دارد.
0.0
• 2
cert-required - این پارامتر بولی (boolean) به سرور اجازه می‌دهد که گواهی کلاینت را الزامی نداند. مقدار پیش‌فرض آن true است، به این معنی که گواهی کلاینت الزامی است و کلاینت باید احراز هویت شود. این پرچم در سمت کلاینت هیچ مفهومی ندارد؛ سرور همواره گواهی‌ای ارائه می‌دهد که توسط کلاینت اعتبارسنجی می‌شود.
168u
اشیاء درون فایل‌ها باید در قالب PEM باشند. فایل‌ها می‌توانند حاوی بیش از یک گواهی باشند، اما این مورد آزمایش نشده و پشتیبانی نمی‌شود.
کتابخانه Botan الزام می‌کند که گواهی‌های CA دارای ویژگی‌های استاندارد گواهی CA باشند، بررسی می‌کند که گواهی‌های نهاد نهایی حتماً نسخه ۳ باشند (همان‌طور که استاندارد TLS الزامی کرده است)، و برای کلید خصوصی فقط از فایل‌های PKCS 8 پشتیبانی می‌کند.
نکته:
0.0
3.5
برخی از کتابخانه‌های رمزنگاری (مانند Botan و نگارش‌های اخیر OpenSSL) حداقل استحکام (یعنی طول کلید) را اعمال می‌کنند، به عنوان مثال حداقل ۲۰۴۸ برای RSA.
168u
168u
مجموعه‌ای نمونه از گواهی‌ها و اشیاء وابسته در مسیر src/lib/asiolink/testutils/ca در سورس‌های Kea به همراه فایل doc.txt که نحوه تولید آن‌ها با استفاده از دستور openssl را توضیح می‌دهد، موجود است. این فایل‌ها صرفاً برای اهداف آزمایشی هستند. از آن‌ها در محیط عملیاتی استفاده نکنید.
دست‌تکانی TLS (یا TLS handshake)، مرحله‌ای که در آن پارامترهای رمزنگاری تبادل شده و احراز هویت اعتبارسنجی می‌شود، می‌تواند به روش‌های گوناگونی با شکست مواجه شود. پیام‌های خطا اغلب برای شناسایی دقیق منبع مشکل کمکی نمی‌کنند. هر دو ابزار OpenSSL و Botan یک ابزار خط فرمانی به همراه دستور verify ارائه می‌دهند که می‌توان از آن برای درک و رفع مشکلات دست‌تکانی استفاده کرد.
تنظیم دقیق OpenSSL
نرم‌افزار Kea پارامترهای پیش‌فرض پیکربندی OpenSSL را می‌پذیرد، اما مدیران سیستم همچنین می‌توانند تنظیمات OpenSSL را به‌دقت تنظیم کنند. به عنوان مثال، ممکن است محدود کردن نسخه TLS مطلوب باشد.
فایل پیکربندی پیش‌فرض OpenSSL با نام openssl.cnf شناخته می‌شود. این فایل در یک دایرکتوری etc وابسته به سیستم قرار دارد و مکان آن را می‌توان با استفاده از متغیر محیطی OPENSSL_CONF بازنویسی کرد. برای نگارش‌های OpenSSL بالاتر از 1.0.2، حداقل پروتکل قابل قبول را می‌توان از طریق متغیر MinProtocol تعیین کرد.
برای این مثال‌ها فرض می‌کنیم که هیچ متغیری از قبل تنظیم نشده و هیچ بخشی از قبل وجود ندارد؛ البته امکان استفاده مجدد از متغیرها و بخش‌های موجود نیز وجود دارد.
در برنامه کاربردی پیش‌فرض، یعنی openssl_conf، متغیر مربوطه باید روی نام بخشی تنظیم شود که مقادیر پیش‌فرض را مدیریت می‌کند: در این مثال، default_conf. اگر openssl_conf هنوز تنظیم نشده است، این خط را در ابتدای فایل پیکربندی OpenSSL (پیش از بخش نخست) اضافه کنید:
0.0
3.5
openssl_conf = default_conf
168u
168u
در بخش default_conf، متغیر ssl_conf باید روی نام بخشی تنظیم شود که پیش‌فرض‌های SSL/TLS را مدیریت می‌کند: در این مثال، ssl_sect.
0.0
3.5
[ default_conf ]
ssl_conf = ssl_sect
168u
168u
در بخش ssl_sect، متغیر system_default باید روی نام بخشی تنظیم شود که پیش‌فرض‌های سیستم را مدیریت می‌کند: در این مثال، system_default_sect.
0.0
3.5
[ ssl_sect ]
system_default = system_default_sect
168u
168u
در بخش system_default_sect، متغیر MinProtocol باید روی حداقل نگارش مطلوب SSL/TLS تنظیم شود: در این مثال، TLSv1.2.
0.0
3.5
[ system_default_sect ]
MinProtocol = TLSv1.2
168u
168u
در صورت تمایل، می‌توان از همین مراحل برای اعمال سایر پارامترهای رمزنگاری نیز استفاده کرد.
اکیداً توصیه می‌شود صفحه راهنمای openssl.cnf مطالعه شود، که معمولاً config.5ssl نامیده شده و با دستور man config نمایش داده می‌شود..SS کانال کنترلی امن Kea
نکته:
0.0
3.5
این بخش مربوط به Kea Control Agent بود که اکنون منسوخ (حذف) شده است، اما برای سوکت‌های کنترلی HTTPS پشتیبانی‌شده توسط کارگزارهای Kea نیز صدق می‌کند.
168u
168u
سوکت‌های کنترلی کارگزارهای Kea به‌طور ذاتی از اتصال‌های امن HTTP با استفاده از TLS پشتیبانی می‌کنند. این امر امکان محافظت در برابر کاربرانی از گره محل اجرای عامل را فراهم می‌سازد؛ چیزی که یک پروکسی معکوس (reverse proxy) قادر به ارائهٔ آن نیست. اطلاعات بیشتر دربارهٔ پشتیبانی از TLS/HTTPS در Kea را می‌توان در TLS/HTTPS Support یافت.
پیکربندی TLS با استفاده از سه پارامتر رشته‌ای حاوی نام فایل‌ها و یک پارامتر بولی (boolean) انجام می‌شود:
0.0
• 2
پارامتر trust-anchor نام فایل یا مسیر دایرکتوری مرجع صدور گواهی (Certification Authority) را مشخص می‌کند.
• 2
پارامتر cert-file نام فایل گواهی کارگزار را مشخص می‌کند.
• 2
پارامتر key-file نام فایل کلید خصوصی را مشخص می‌کند. این فایل نباید رمزنگاری شده باشد.
• 2
پارامتر cert-required مشخص می‌کند که آیا گواهی‌های کلاینت الزامی هستند یا اختیاری. پیش‌فرض بر الزامی بودن آن‌ها و انجام احراز هویت متقابل (mutual authentication) است.
168u
قالب فایل PEM است. یا باید تمام پارامترهای رشته‌ای مشخص شوند و HTTP روی TLS (همان HTTPS) استفاده گردد، یا هیچ‌کدام مشخص نشوند و HTTP معمولی به کار رود. پیکربندی تنها یک یا دو پارامتر رشته‌ای منجر به خطا خواهد شد.
نکته:
0.0
3.5
هنگامی که گواهی‌های کلاینت الزامی نباشند، تنها سمت کارگزار احراز هویت می‌شود، یعنی ارتباط با یک کلاینت ناشناس رمزنگاری می‌گردد. این حالت تنها در برابر حملات غیرفعال (passive) محافظت می‌کند؛ حملات فعال مانند "مرد میانی" (man-in-the-middle) همچنان امکان‌پذیر خواهند بود.
168u
168u
نکته:
0.0
3.5
هیچ طرح احراز هویت استاندارد HTTP موجودیت پایانی (end entity) خود را به‌صورت رمزنگاری‌شده به TLS مقید نمی‌کند. این بدان معناست که کلاینت و کارگزار TLS می‌توانند احراز هویت متقابل شوند، اما هیچ اثباتی وجود ندارد که آن‌ها همان هویت‌های احراز هویت HTTP باشند.
168u
168u
ابزار kea-shell <#std-iscman-kea-shell> نیز از TLS پشتیبانی می‌کند.
ایمن‌سازی استقرار Kea
در ادامه فهرستی از ملاحظات برای مدیران سیستمی که مایل به ارتقای امنیت Kea هستند آورده شده است. در بسیاری از موارد، بین راحتی و امنیت مصالحه‌هایی وجود دارد.
طراحی مبتنی بر مؤلفه
معماری Kea ماژولار است و از دیمن‌های مجزا برای وظایف مختلف بهره می‌برد. یک استقرار Kea ممکن است شامل دیمن‌های DHCPv4، DHCPv6 و Dynamic DNS باشد؛ ابزار کمکی kea-lfc <#std-iscman-kea-lfc> برای پاک‌سازی دوره‌ای فایل‌های اجاره (lease)؛ پایگاه‌های دادهٔ MySQL و یا PostgreSQL که یا به‌صورت محلی روی کارگزارهای برنامه اجرا می‌شوند یا از طریق شبکهٔ داخلی در دسترس هستند؛ یک دیمن Netconf برای انجام نظارت بر پیکربندی و آمار کارگزارهای Kea؛ و یک سامانهٔ مانیتورینگ Stork.
این معماری ماژولار به مدیر سیستم اجازه می‌دهد تا با به حداقل رساندن کدهای بارگذاری و اجرا شده، سطح حمله (attack surface) را به کمترین میزان برساند.
به‌عنوان مثال، kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> نباید اجرا شود مگر اینکه به‌روزرسانی‌های DNS مورد نیاز باشد.
به همین ترتیب، اگر memfile استفاده نشود، kea-lfc <#std-iscman-kea-lfc> هرگز فراخوانی نمی‌شود (و می‌توان آن را با خیال راحت حذف کرد یا هرگز نصب ننمود).
مشکلات امنیتی بالقوهٔ Kea را می‌توان با اجرای تنها آن فرایندهایی که در محیط محلی مورد نیاز هستند به حداقل رساند.
نکته:
0.0
3.5
از نسخهٔ Kea 2.7.9 به بعد، data-directory (فقط در DHCPv6) منسوخ شده است. فایل‌های اجاره (DHCPv4 و DHCPv6) و فایل duid (فقط در DHCPv6) تنها می‌توانند از دایرکتوری تعیین‌شده در حین کامپایل بارگذاری شوند: "[kea-install-dir]/var/lib/kea".
این مسیر می‌تواند در هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_DHCP_DATA_DIR به مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در name یا data-directory استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند.
این محدودیت برای نوشتن فایل اجاره با استفاده از دستورهای lease4-write و lease6-write نیز اعمال می‌شود. اگر مسیری غیر از این مقدار در filename استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت خواهد کرد. برای سهولت در تعیین یک نام فایل سفارشی، کافی است بخش مسیر را از filename حذف کنید. همین محدودیت همچنین برای نوشتن فایل حافظهٔ پنهان (cache) با استفاده از دستور cache-write اعمال می‌شود. برای سهولت در تعیین یک نام فایل سفارشی، کافی است بخش مسیر را از filename حذف کنید.
متغیر محیطی KEA_DHCP_DATA_DIR همچنین برای تغییر مکان پیش‌فرض فایل شناسه کارگزار تولیدشدهٔ DHCPv6 (kea-dhcp6-serverid) استفاده می‌شود.
168u
168u
محدود کردن مجوزهای برنامه کاربردی
پروتکل‌های DHCPv4 و DHCPv6 فرض می‌کنند که کارگزار پورت دارای امتیاز UDP 67 (در DHCPv4) یا 547 (در DHCPv6) را باز می‌کند که در شرایط عادی به دسترسی ریشه (root) نیاز دارد. با این حال، از طریق سازوکار قابلیت‌ها (capabilities) در سیستم‌های لینوکس، Kea می‌تواند از یک حساب کاربری بدون امتیاز اجرا شود. برای جزئیات در مورد نحوهٔ اجرای Kea بدون دسترسی ریشه، «Running Kea From a Non-root Account on Linux» <#non-root> را ببینید.
ایمن‌سازی دسترسی مدیریتی Kea
هر سه دیمن اصلی Kea (kea-dhcp4 <#std-iscman-kea-dhcp4>، kea-dhcp6 <#std-iscman-kea-dhcp6> و kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>) همگی از یک کانال کنترلی که به‌صورت سوکت UNIX پیاده‌سازی شده است پشتیبانی می‌کنند. این کانال کنترلی که یک سوکت UNIX باز می‌کند، به‌طور پیش‌فرض غیرفعال است؛ با این حال، نمونه‌های پیکربندی متعددی آن را فعال کرده‌اند، زیرا ویژگی بسیار محبوبی است. برای خواندن از این سوکت یا نوشتن در آن، عموماً به دسترسی ریشه (root) نیاز است، هرچند اگر Kea برای اجرا به عنوان کاربر غیرریشه (non-root) پیکربندی شده باشد، مالک فرایند می‌تواند در آن بنویسد. دسترسی را می‌توان با استفاده از کنترل دسترسی معمول به فایل در سیستم‌های POSIX (مالک، گروه، سایرین، خواندن/نوشتن) کنترل کرد.
نکته:
0.0
3.5
از نسخهٔ Kea 2.7.9 به بعد، سوکت‌های کنترلی تنها می‌توانند در دایرکتوری تعیین‌شده در حین کامپایل یعنی "[kea-install-dir]/var/run/kea" قرار گیرند که همچنین باید دارای مجوزهای دسترسی 0750 باشد. این مسیر می‌تواند در هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_CONTROL_SOCKET_DIR به مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در socket-name استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی امتناع می‌ورزد یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. برای سهولت در استفاده، کافی است مؤلفهٔ مسیر را از socket-name حذف کنید.
168u
168u
از نسخهٔ Kea 2.7.2 به بعد، کارگزارهای DHCP از کانال‌های کنترلی HTTP/HTTPS پشتیبانی می‌کنند و از نسخهٔ Kea 3.1.8 عامل کنترلی (Control Agent) حذف شده است.
از نسخهٔ Kea-2.7.6 به بعد، Kea از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هر دو نشانی IPv4 و IPv6 قابل استفاده هستند. با پیکربندی اتصال‌های HTTPS برای تمام دیمن‌ها، می‌توان امنیت را ارتقا داد.
پیکربندی Kea توسط یک فایل JSON بر روی کارگزار Kea کنترل می‌شود. این فایل می‌تواند توسط هر کاربری با مجوزهای فایل مربوطه (که توسط سیستم‌عامل کنترل می‌شود) مشاهده یا ویرایش گردد. توجه داشته باشید که گذرواژه‌ها به‌صورت متن ساده (clear text) در فایل پیکربندی ذخیره می‌شوند، بنابراین هر کسی با دسترسی خواندن فایل پیکربندی می‌تواند این اطلاعات را بیابد. از منظر عملی، هر کسی با مجوز ویرایش فایل پیکربندی، کنترل Kea را در دست دارد.
محدود کردن مجوزهای کاربر برای خواندن یا نوشتن فایل پیکربندی Kea، یک اقدام امنیتی مهم است.
نکته:
0.0
3.5
از نسخهٔ Kea 2.7.9 به بعد، فایل پیکربندی (با استفاده از دستور config-write) تنها می‌تواند در همان دایرکتوری‌ای نوشته شود که فایل پیکربندی استفاده‌شده هنگام راه‌اندازی Kea (ارائه‌شده به عنوان آرگومان -c) در آن قرار دارد.
168u
Kea می‌تواند از یک پایگاه داده خارجی MySQL یا PostgreSQL برای ذخیره‌سازی پیکربندی، رزروهای میزبان،
و/یا اجاره‌ها (leases)، و/یا برای لاگ‌گیری قانونی (forensic logging) استفاده کند. استفاده از پایگاه‌های داده یک ویژگی محبوب است، اما اختیاری است؛
همچنین ذخیره داده‌ها در یک فایل ساده (flat file) روی دیسک نیز امکان‌پذیر است.
هنگام استفاده از پایگاه داده، Kea مشخصات اعتبارسنجی زیر را برای احراز هویت در پایگاه داده ذخیره کرده و به کار می‌برد:
نام کاربری، گذرواژه، میزبان، درگاه (port) و نام پایگاه داده. این مقادیر به صورت متن آشکار (clear text)
در فایل پیکربندی ذخیره می‌شوند.
بسته به پیکربندی پایگاه داده، بررسی تطابق کاربر سیستم با نام کاربری پایگاه داده نیز امکان‌پذیر است.
برای جزئیات بیشتر به راهنمای MySQL یا PostgreSQL مراجعه کنید.
Kea از تنظیمات کلاینت SSL/TLS برای پایگاه داده MySQL و PostgreSQL پشتیبانی می‌کند
و باید به‌طور صریح برای تمام اتصال‌های مورد استفاده (پیکربندی،
رزروها، اجاره‌ها، لاگ‌گیری قانونی) پیکربندی شود. برای جزئیات بخش
اتصال پایگاه داده (Database Connectivity <#database-connectivity>) را ببینید.
نشت اطلاعات از طریق لاگ‌گیری
امکان دارد که Kea کل یک فایل پیکربندی، از جمله گذرواژه‌ها و داده‌های محرمانه را لاگ کند.
از نسخه 1.9.7 در Kea، این مشکل با جایگزینی مقدار تمام ورودی‌هایی که به
password یا secret ختم می‌شوند با علامت ستاره برطرف شده است، همان‌طور که پیش‌تر برای لاگ‌های پایگاه داده انجام می‌شد.
لاگ‌ها به stdout، stderr، فایل‌ها یا syslog ارسال می‌شوند؛ مجوزهای فایل‌های سیستم برای
stdout/stderr و فایل‌ها اعمال می‌گردد. syslog ممکن است لاگ‌ها را روی شبکه ارسال کند که این امر آن‌ها را بیشتر در معرض شنود احتمالی قرار می‌دهد.
نکته:
0.0
3.5
از نسخه 2.7.9 در Kea، فایل‌های لاگ فقط می‌توانند در دایرکتوری خروجی تعیین‌شده
در زمان کامپایل نوشته شوند: "[kea-install-dir]/var/log/kea". این
مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی
KEA_LOG_FILE_DIR به مسیر دلخواه جایگزین (override) شود. اگر مسیری غیر از
این مقدار در output استفاده شود، Kea خطا داده و از اجرا خودداری می‌کند
یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی ثبت خواهد کرد. برای سهولت در استفاده، بخش
مسیر را از output حذف کرده و تنها نام فایل را مشخص کنید.
168u
168u
نکته:
0.0
3.5
از نسخه 2.7.9 در Kea، فایل‌های لاگ قانونی (legal log) فقط می‌توانند در دایرکتوری خروجی
تعیین‌شده در زمان کامپایل نوشته شوند: "[kea-install-dir]/var/log/kea". این
مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی
KEA_LEGAL_LOG_DIR به مسیر دلخواه جایگزین شود. اگر مسیری غیر از این مقدار
در path استفاده شود، Kea خطا داده و از راه‌اندازی امتناع می‌کند یا در صورت
در حال اجرا بودن، یک خطای غیرقابل‌بازیابی ثبت خواهد کرد. برای سهولت در استفاده، کافی است پارامتر
path را حذف کنید.
168u
168u
خلاصه‌ای از محدودیت‌های مسیر
محدودیت‌های مسیر ذکرشده در این بخش را می‌توان طبق جدول
زیر خلاصه کرد:
box center;
l|l|l.
عنصر محدودشده مقدار پیش‌فرض بازنویسی با متغیر محیطی
فایل‌های پیکربندی (config-write) دایرکتوری یکسان با فایل پیکربندی اولیه N/A
فایل‌های حافظه موقت میزبان (cache-write) var/lib/kea KEA_DHCP_DATA_DIR
فایل‌های اجاره (Lease) var/lib/kea KEA_DHCP_DATA_DIR
فایل شناسه کارگزار DHCPv6 var/lib/kea KEA_DHCP_DATA_DIR
فایل‌های لاگ var/log/kea KEA_LOG_FILE_DIR
فایل‌های لاگ قانونی (Forensic) var/log/kea KEA_LEGAL_LOG_DIR
سوکت‌های یونیکس (Unix Sockets) var/run/kea KEA_CONTROL_SOCKET_DIR
اسکریپت‌های مورد استفاده کتابخانه‌های Hook share/kea/scripts/ KEA_HOOK_SCRIPTS_PATH
Kea از هر یک از دو کتابخانه رمزنگاری زیر پشتیبانی می‌کند: Botan یا OpenSSL.
این انتخاب در زمان کامپایل انجام می‌شود و وابستگی‌های زمان کامپایل و زمان اجرا
را میان Kea و کتابخانه انتخاب‌شده ایجاد می‌کند. با وجود اینکه OpenSSL محبوب‌ترین
انتخاب برای محیط‌های عملیاتی است، Botan نیز یک جایگزین کاملاً پشتیبانی‌شده باقی می‌ماند.
موارد کاربرد اصلی کتابخانه‌های رمزنگاری عبارتند از:
0.0
• 2
پشتیبانی از TLS برای کانال‌های کنترلی HTTPS، معرفی‌شده در Kea 1.9.6.
• 2
امضاهای TSIG هنگام ارسال به‌روزرسانی‌های DNS.
• 2
محاسبه رکوردهای DHCID هنگام ارسال به‌روزرسانی‌های DNS.
• 2
تولید اعداد تصادفی (اما نه برای مواردی که به تولیدکننده در سطح رمزنگاری پیشرفته نیاز دارند).
168u
برای OpenSSL و Botan، تنها از رابط رمزنگاری سطح پایین استفاده می‌شود (مانند libcrypto). برنامه Kea
با libssl پیوند (link) برقرار نمی‌کند. برخی از سامانه‌های نرم‌افزاری وابسته، مانند کتابخانه‌های کلاینت پایگاه داده،
نیز می‌توانند به یک کتابخانه رمزنگاری وابسته باشند.
یک راه برای محدود کردن خطرات ناشی از آسیب‌پذیری‌های بالقوه OpenSSL یا Botan، عدم استفاده از DDNS است.
کتابخانه‌ها همچنان برای ساخت و اجرای Kea مورد نیاز خواهند بود، اما کدهای آن‌ها هرگز اجرا نخواهد شد، بنابراین
هرگونه باگ بالقوه در کتابخانه‌ها قابل بهره‌برداری نخواهد بود.
امضاهای TSIG
برنامه Kea هنگام امضای به‌روزرسانی‌های DNS با امضاهای TSIG، از الگوریتم‌های زیر پشتیبانی می‌کند:
0.0
• 2
HMAC-MD5
• 2
HMAC-SHA1
• 2
HMAC-SHA224
• 2
HMAC-SHA256
• 2
HMAC-SHA384
• 2
HMAC-SHA512
168u
برای دیدن فهرست به‌روز، فهرست کلیدهای TSIG را در <#d2-tsig-key-list-config> ببینید.
برنامه Kea برای محاسبه رکوردهای DHCID از SHA256 استفاده می‌کند. این موضوع از دیدگاه رمزنگاری
حائز اهمیت نیست، زیرا رکورد DHCID صرفاً برای ایجاد شناسه‌های منحصربه‌فرد برای دو دستگاهی به کار می‌رود که
ممکن است در زمان‌های مختلف یک آدرس IP یکسان به آن‌ها اختصاص یافته باشد.
پشتیبانی از سوکت خام (Raw Socket)
به طور کلی، Kea DHCPv4 از سوکت‌های خام (raw sockets) برای دریافت ترافیک از کلاینت‌ها استفاده می‌کند. چالش اصلی،
دریافت بسته‌ها از دستگاه‌هایی است که هنوز هیچ آدرس IPv4 ندارند. هنگام مدیریت ترافیک مستقیم
(حالتی که کلاینت و سرور هر دو به یک پیوند متصل هستند و رله‌ها آن‌ها را جدا نکرده‌اند)، کرنل
به طور پیش‌فرض بسته را دور می‌اندازد زیرا آدرس IP مبدأ 0.0.0.0 است. بنابراین، Kea باید سوکت‌های خام را باز کند
تا بتواند این ترافیک را دریافت کند.
با این حال، اگر تمام ترافیک از طریق رله‌ها عبور کند (که در بسیاری از شبکه‌ها رایج است)، این کار
ضرورتی ندارد. در این حالت می‌توان به‌جای آن از سوکت‌های استاندارد UDP استفاده کرد. پارامتری به نام
dhcp-socket-type وجود دارد که این رفتار را کنترل می‌کند.
حالت پیش‌فرض، مجاز دانستن استفاده از سوکت خام است، چرا که انعطاف‌پذیری بیشتری دارد.
هنگام استفاده از سوکت‌های خام، Kea می‌تواند بسته‌های خام لایه ۲ را دریافت کرده و اکثر فایروال‌ها
(شامل iptables) را دور بزند. این عملاً بدین معناست که هنگام استفاده از سوکت‌های خام، نمی‌توان از iptables برای
مسدود کردن ترافیک DHCP استفاده کرد. این ویژگی، از تصمیمات طراحی در کرنل لینوکس است.
می‌توان Kea را طوری تنظیم کرد که از سوکت‌های UDP استفاده کند. این گزینه زمانی کاربرد دارد که تمام ترافیک رله شود.
با این حال، برای دستگاه‌هایی که مستقیماً متصل هستند کارایی ندارد. اگر Kea به سوکت‌های UDP محدود شود،
iptables باید به درستی عمل کند.
در صورتی که نیازی به سوکت‌های خام نباشد، غیرفعال کردن این دسترسی می‌تواند امنیت را افزایش دهد.
دسترسی مدیریتی از راه دور
سرورهای DHCP و DDNS یک RESTful API را روی HTTP یا HTTPS (یعنی HTTP بر بستر TLS) ارائه می‌دهند.
این کانال‌های کنترلی ویژگی‌های اختیاری هستند که به صورت پیش‌فرض غیرفعال‌اند، اما کاربرد فراوانی دارند. در صورت فعال‌سازی،
به صورت پیش‌فرض روی آدرس loopback (یعنی 127.0.0.1 یا ::1) شنود می‌کنند، مگر اینکه طور دیگری پیکربندی شده باشند. برای
کسب اطلاعات بیشتر در مورد حفاظت از ترافیک TLS، بخش پشتیبانی از TLS/HTTPS را ببینید. محدود کردن اتصالات ورودی با یک فایروال،
مانند iptables، اکیداً توصیه می‌شود.
توجه داشته باشید که در استقرارهای دارای دسترسی‌پذیری بالا (HA)، می‌توان یک شنونده اختصاصی چندنخی (multi-threaded)
را برای ارائه پروتکل HA از طریق RESTful API با گره‌های همتا (peers) پیکربندی کرد.
برنامه Kea همچنین از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هر دو آدرس IPv4 و IPv6 قابل استفاده هستند.
با پیکربندی اتصالات HTTPS برای تمامی دیمن‌ها، می‌توان امنیت را ارتقا داد.
احراز هویت برای RESTful API در Kea
در Kea 1.9.0 پشتیبانی از احراز هویت پایه HTTP (استاندارد RFC 7617 https://datatracker.ietf.org/doc/html/rfc7617)
برای کنترل دسترسی دستورات ورودی REST روی HTTP اضافه شد. اطلاعات هویتی (نام کاربری، گذرواژه)
در یک فایل پیکربندی محلی Kea بر روی دیسک ذخیره می‌شوند. نام کاربری همراه با دستور API ثبت می‌شود، بنابراین
می‌توان مشخص کرد که کدام کاربر احراز هویت‌شده هر دستور را اجرا کرده است. جزئیات کنترل دسترسی با استفاده از یک
ثبت‌کننده وقایع (logger) اختصاصی به نام auth ثبت می‌شود. احراز هویت پایه HTTP به خودی خود ضعیف است زیرا
در معرض حملات دیکشنری شناخته‌شده قرار دارد، اما این حملات نیازمند یک «حمله مرد میانی» ("man in the middle")
برای دستیابی به ترافیک HTTP هستند. این مشکل را می‌توان با استفاده انحصاری از احراز هویت پایه HTTP روی TLS برطرف کرد.
در حقیقت، در صورت امکان، استفاده از گواهی‌های کلاینت برای TLS بهتر از استفاده از احراز هویت پایه HTTP است.
در Kea 1.9.2 یک نقطه قلاب (hook point) جدید به نام auth معرفی شد. با استفاده از این نقطه قلاب جدید، می‌توان یک
کتابخانه قلاب خارجی را برای گسترش کنترل‌های دسترسی، ادغام با سایر مراجع احراز هویت، یا افزودن کنترل دسترسی مبتنی بر نقش (RBAC)
به کانال‌های کنترلی توسعه داد. این نقطه قلاب به http_auth تغییر نام یافت و از نسخه 2.7.2 Kea توسط سرورهای DHCP
و DDNS نیز پشتیبانی می‌شود.
هر سه دیمن اصلی Kea (kea-dhcp4 <#std-iscman-kea-dhcp4>، kea-dhcp6 <#std-iscman-kea-dhcp6> و kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>) همگی
از یک کانال کنترلی که به عنوان سوکت UNIX پیاده‌سازی شده، پشتیبانی می‌کنند. این کانال کنترلی که یک سوکت UNIX باز می‌کند، به صورت پیش‌فرض غیرفعال است.
آسیب‌پذیری Blast RADIUS
آسیب‌پذیری Blast-RADIUS نقصی است که بر پروتکل RADIUS پیاده‌سازی‌شده توسط
کتابخانه قلاب RADIUS تأثیر می‌گذارد. برای جزئیات بیشتر، هشدار امنیتی <#radius-security-warning> را ببینید.
بررسی خط‌مشی امنیتی زمان اجرای Kea
بررسی خط‌مشی امنیتی در زمان اجرا ابتدا در نسخه 2.7.9 Kea به دیمن‌های Kea شامل kea-dhcp4 <#std-iscman-kea-dhcp4>،
kea-dhcp6 <#std-iscman-kea-dhcp6> و kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> اضافه شد. در Kea 3.0 بررسی‌های بیشتری افزوده شدند. به طور پیش‌فرض،
هنگامی که یک دیمن نقض خط‌مشی امنیتی را تشخیص می‌دهد، یک پیام خطای لاگ ارسال کرده و خارج می‌شود. بررسی‌های زیر
انجام می‌شوند:
0.0
• 2
استفاده از مسیرهای فایل یا مجوزهای پشتیبانی‌نشده بر اساس جزئیات ارائه‌شده در خلاصه محدودیت‌های مسیر
• 2
استفاده از عبارت متنی واضح (clear text) برای 'user' یا 'password' در احراز هویت HTTP (در Kea 3.0)
• 2
استفاده از عبارت متنی واضح برای 'secret' در پیکربندی کلید TSIG (در Kea 3.0)
• 2
استفاده از کانال‌های API پروتکل HTTP بدون احراز هویت (در Kea 3.0)
• 2
اجرای سرور Kea تحت کاربر root. (توجه داشته باشید که این مورد تنها یک لاگ هشدار ایجاد می‌کند و هرگز متوقف‌کننده نیست)
168u
از نسخه 3.0 Kea، راه‌اندازی دیمن‌ها با گزینه خط فرمان '-X' به آن‌ها دستور می‌دهد
که در مورد خطرات امنیتی هشدار دهند اما در هر صورت به کار خود ادامه دهند.
شناسه‌های پیام برای تمام این هشدارها به پسوند "_SECURITY_WARNING" ختم می‌شوند.
هشدار:
0.0
3.5
سرورها را بدون ارزیابی دقیق و اعمال اقدامات احتیاطی لازم با گزینه '-X'
اجرا نکنید. عدم رعایت این نکته می‌تواند استقرارها را در معرض آسیب‌پذیری‌های
امنیتی قرار دهد.
168u
بخش‌های زیر نحوه اطمینان تیم توسعه Kea DHCP از کیفیت کد و مدیریت آسیب‌پذیری‌ها را شرح می‌دهند.
مدیریت آسیب‌پذیری‌ها (Vulnerability Handling)
مجموعه ISC مشارکت‌کننده‌ای باسابقه و فعال در فرآیند استاندارد صنعتی افشای آسیب‌پذیری‌ها است و مستندات دقیقی درباره فرآیندها و آسیب‌پذیری‌های نرم‌افزارهای ISC نگهداری می‌کند.
برای مشاهده خط‌مشی افشای نقایص نرم‌افزاری و آسیب‌پذیری‌های امنیتی ISC به https://kb.isc.org/docs/aa-00861 مراجعه کنید.
در صورت بروز یک آسیب‌پذیری امنیتی در Kea، ISC پیش از هرگونه افشای عمومی، به مشتریان پشتیبانی اطلاع داده و وصله (patch) و/یا بسته نصبی به‌روزشده‌ای را برای رفع آسیب‌پذیری ارائه می‌دهد.
هنگامی که یک به‌روزرسانی امنیتی منتشر می‌شود، فایل‌های فشرده سورس (tarball) و بسته‌های نگهداری‌شده توسط ISC در همان روز منتشر می‌گردند. این امر کاربران سازوکارهای به‌روزرسانی بومی لینوکس (مانند apt در Debian و Ubuntu یا dnf در RedHat) را قادر می‌سازد تا سیستم‌های خود را فوراً به‌روزرسانی کنند.
کیفیت کد و آزمایش (Code Quality and Testing)
پروژه Kea در طول فرآیند توسعه خود تحت آزمایش‌های گسترده‌ای قرار می‌گیرد. موارد زیر برخی از فرآیندهایی هستند که برای اطمینان از کیفیت مناسب کد استفاده می‌شوند:
0.0
• 2
هر خط کد پیش از پذیرفته شدن، از یک بازبینی رسمی (formal review) عبور می‌کند. فرآیند بازبینی مستند شده و به صورت عمومی در دسترس است.
• 2
تقریباً ۵۰٪ از کد منبع به آزمون‌های واحد (unit tests) اختصاص دارد. تا مه ۲۰۲۴، بیش از ۱۲۰۰۰ آزمون واحد وجود داشت و این تعداد با گذشت زمان در حال افزایش است. گذراندن آزمون‌های واحد برای commit کردن هر ویژگی جدید الزامی است.
• 2
حدود ۲۰۰۰ آزمون سیستم برای Kea وجود دارد. این آزمون‌ها هم وضعیت‌های صحیح و هم وضعیت‌های نامعتبر را شبیه‌سازی می‌کنند و بسته‌های شبکه (عمدتاً DHCP، و همچنین DNS، HTTP، HTTPS و غیره)، استفاده از خط فرمان، فراخوانی‌های API، تعاملات پایگاه داده، اسکریپت‌ها و موارد دیگر را پوشش می‌دهند.
• 2
آزمون‌های کارایی با بیش از ۸۰ سناریو وجود دارند که کارایی کلی و تاب‌آوری Kea را در سطوح مختلف ترافیک می‌سنجند و معیارهای گوناگونی را اندازه‌گیری می‌کنند (تأخیر، اجاره‌ها بر ثانیه، بسته‌ها بر ثانیه، مصرف CPU، بهره‌وری حافظه و موارد دیگر).
• 2
پروژه Kea از یکپارچه‌سازی مداوم (CI) استفاده می‌کند. این بدان معناست که بخش عمده آزمایش‌ها (همه آزمون‌های واحد و سیستم، و در برخی موارد آزمون‌های کارایی) به ازای هر commit اجرا می‌شوند. بسیاری از آزمایش‌های "سبک‌تر" روی شاخه‌ها، حتی پیش از پذیرفته شدن کد اجرا می‌شوند.
• 2
بسیاری از آزمون‌های واحد و سیستم سناریوهای منفی را بررسی می‌کنند؛ مانند بسته‌ها، دستورات API و فایل‌های پیکربندی ناقص، خراب یا بریده‌شده (truncated)، و همچنین توالی‌های نادرست (مانند ارسال بسته‌ها با ترتیبی نامعتبر) و موارد دیگر.
• 2
تیم توسعه Kea از ابزارهای متعددی استفاده می‌کند که بررسی‌های خودکار کیفیت کد را انجام می‌دهند، مانند danger و همچنین ابزارهای بررسی سلامت (sanity checkers) که در داخل تیم توسعه یافته‌اند.
• 2
تیم Kea از تحلیل‌گرهای ایستای کد (static code analyzers) زیر استفاده می‌کند: Coverity Scan، cppcheck، clang-static-analyzer، shellcheck، flawfinder، semgrep و danger.
• 2
تیم Kea از تحلیل‌گرهای پویای کد (dynamic code analyzers) زیر استفاده می‌کند: Valgrind، Thread Sanitizer (TSAN)، Address Sanitizer (ASAN) و Undefined Behavior Sanitizer (UBSAN).
168u
آزمون فازینگ (Fuzz Testing)
تیم Kea فرآیندی برای اجرای آزمون فازینگ دارد.
فازینگ یک روش آزمون نرم‌افزار است که در آن داده‌های تولیدشده گوناگونی به عنوان ورودی به برنامه داده می‌شود و رفتارهای غیرعادی برنامه مانند فروپاشی (crash) یا قفل کردن (hang) مورد پایش قرار می‌گیرد.
دو روش برای فاز کردن Kea وجود دارد:
گزینه ۱. با تابع مهارکننده (harness function) مربوط به libfuzzer به نام LLVMFuzzerTestOneInput.
گزینه ۲. با کامپایلر AFL (American Fuzzy Lop https://github.com/google/AFL).
استفاده از تابع مهارکننده LLVMFuzzerTestOneInput:
این حالت از فازینگ تقریباً با هر کامپایلری کار می‌کند.
چهار نوع فازر در این حالت پیاده‌سازی شده است:
0.0
• 2
فازر Config
• 2
فازر نقطه پایانی HTTP
• 2
فازر Packet
• 2
فازر سوکت Unix
168u
دو فایل باینری تحت آزمون وجود دارند:
0.0
• 2
kea-dhcp4
• 2
kea-dhcp6
168u
یکپارچگی انتشار (Release Integrity)
تمام نسخه‌های منتشرشده نرم‌افزارهای ISC با PGP امضا شده و از طریق وب‌سایت ISC توزیع می‌شوند؛ وب‌سایتی که خود با DNSSEC امضا شده است، بنابراین کاربران می‌توانند مطمئن باشند که در نرم‌افزار دستکاری صورت نگرفته است.
ضریب اتوبوس (Bus Factor)
طبق اعلام پروژه Core Infrastructure https://bestpractices.coreinfrastructure.org، "ضریب اتوبوس" یا "ضریب کامیون" حداقل تعداد اعضای پروژه است که باید ناگهان از پروژه ناپدید شوند ("با یک اتوبوس تصادف کنند") قبل از اینکه پروژه به دلیل کمبود افراد آگاه یا دارای صلاحیت متوقف شود. تخمین دقیق آن دشوار است، اما ضریب اتوبوس برای Kea حدود پنج نفر است. تا سال ۲۰۲۱، شش توسعه‌دهنده اصلی و دو مهندس تضمین کیفیت به همراه مشارکت‌کنندگان جانبی متعدد (مدیر محصول، تیم پشتیبانی، IT و غیره) وجود دارند. این تیم از نظر جغرافیایی پراکنده است.
متفرقه (Miscellaneous)
ایجاد فایل‌های core dump
کرنل‌ها در صورت فعال بودن این ویژگی، هنگام فروپاشی یک فرآیند یا دریافت سیگنالی متناظر با این عمل، فایل‌های core dump ایجاد می‌کنند. روش فعال‌سازی فایل‌های core dump وابسته به سیستم است، اما دارای کنترل‌های مشترکی نظیر محدودیت coredumpsize یا core file size است که می‌توان آن‌ها را با استفاده از دستورات ulimit یا limit یا دستورات توکار شل مشاهده کرد و تغییر داد.
مستند پایگاه دانش با عنوان «What to do if your BIND, Kea DHCP, Stork, or ISC DHCP server has crashed» در https://kb.isc.org/docs/aa-00340 جزئیات مربوط به هر سیستم را در بخش Things to check if a core file does not get generated توضیح می‌دهد.
روش دیگر برای ایجاد یک فایل core dump، دستور gcore است که چنین فایل‌ها / ایمیج‌هایی را از یک فرآیند در حال اجرا ایجاد می‌کند. لطفاً برای درک نحوه استفاده از آن، به صفحه راهنمای آن مراجعه کنید. دو نکته حائز اهمیت است:
0.0
• 2
آیا gcore فرآیندی را که از آن dump گرفته می‌شود معلق (suspend) می‌کند یا گزینه‌ای برای تعلیق آن ارائه می‌دهد؟
• 2
نام فایل core dump تولیدشده (که برای فایل‌های core dump ایجادشده توسط هسته نیز کاربرد دارد).
168u
هشدار:
0.0
3.5
توجه داشته باشید که فایل‌های core dump ممکن است بسیار حجیم باشند و به راحتی سیستم فایلی که در آن ذخیره می‌شوند را پر کنند... برای مثال فراموش نکنید در صورتی که نیازی به این ویژگی نیست یا دیگر نیازی به آن ندارید، آن را فعال رها نکنید.
168u
"پیکربندی KEA (KEA CONFIGURATION)"
‏Kea از ساختارهای JSON برای نمایش پیکربندی‌های کارساز استفاده می‌کند. بخش‌های زیر نحوه سازمان‌دهی این ساختارهای پیکربندی را شرح می‌دهند.
"پیکربندی JSON (JSON Configuration)"
‏JSON نشانه‌گذاری مورد استفاده در سراسر پروژه Kea است. آشکارترین کاربرد آن برای فایل پیکربندی است، اما از JSON برای ارسال دستورها از طریق Management API (ببینید: Management API <#ctrl-channel>) و ارتباط بین کارسازهای DHCP و دیمن به‌روزرسانی DDNS نیز استفاده می‌شود.
کاربرد معمول بر این فرض است که کارسازها از خط فرمان، به‌صورت مستقیم یا با استفاده از یک اسکریپت مانند keactrl <#std-iscman-keactrl> راه‌اندازی می‌شوند. فایل پیکربندی هنگام راه‌اندازی با استفاده از پارامتر -c مشخص می‌شود.
"نحو JSON (JSON Syntax)"
فایل‌های پیکربندی برای ماژول‌های DHCPv4، DHCPv6، DDNS و NETCONF در قالب گسترش‌یافته‌ای از JSON تعریف می‌شوند. نگارش پایه JSON در RFC 7159 https://datatracker.ietf.org/doc/html/rfc7159 و ECMA 404 https://www.ecma-international.org/publications/standards/Ecma-404.htm تعریف شده است. به‌ویژه، تنها مقادیر بولی مجاز true یا false (تماماً با حروف کوچک) هستند. نگارش‌های با حروف بزرگ (True یا False) پذیرفته نمی‌شوند.
اگرچه استاندارد JSON (یا ECMA 404) نیازی ندارد که اشیای JSON (یعنی نگاشت‌های نام/مقدار) ورودی‌های یکتا داشته باشند، Kea آن‌ها را با استفاده از map در C++ STL با ورودی‌های یکتا پیاده‌سازی می‌کند. از این رو، اگر چندین مقدار برای یک نام در یک شیء/نگاشت وجود داشته باشد، آخرین مقدار بر مقادیر قبلی بازنویسی می‌شود. از نسخه Kea 1.9.0 به بعد، تجزیه‌کننده‌های فایل پیکربندی در چنین مواردی خطای نحو برمی‌انگیزند.
مؤلفه‌های Kea از JSON گسترش‌یافته با قابلیت‌های اضافی مجاز زیر استفاده می‌کنند:
0.0
• 2
کامنت‌های شل: هر متنی پس از نویسه هش (#) نادیده گرفته می‌شود.
• 2
کامنت‌های C: هر متنی پس از نویسه دو اسلش (//) نادیده گرفته می‌شود.
• 2
کامنت‌های چندخطی: هر متنی بین /* و */ نادیده گرفته می‌شود. این کامنت می‌تواند در چند خط امتداد یابد.
• 2
شامل‌سازی فایل: فایل‌های JSON می‌توانند فایل‌های JSON دیگر را با استفاده از گزاره‌ای به شکل <?include "file.json"?> شامل شوند.
• 2
ویرگول‌های اضافی: جهت رفع مشکل خطاهای ناشی از ویرگول‌های باقی‌مانده پس از اعمال تغییرات در پیکربندی. هنگام تجزیه، هشداری همراه با مکان ویرگول چاپ می‌شود تا به کاربر امکان اصلاح اشتباه احتمالی داده شود.
168u
هشدار:
0.0
3.5
این قابلیت‌ها برای استفاده در فایل پیکربندی JSON در نظر گرفته شده‌اند. استفاده از آن‌ها به هر روش دیگر ممکن است به بروز خطا منجر شود.
168u
168u
فایل پیکربندی از یک شیء منفرد (که اغلب در اصطلاح عامیانه نگاشت نامیده می‌شود) تشکیل شده است که با یک آکوالاد باز شروع می‌شود. این فایل تنها شامل یکی از اشیای "Dhcp4"، "Dhcp6"، "DhcpDdns" یا "Netconf" است. تعریف عناصر اضافی امکان‌پذیر است اما نادیده گرفته خواهند شد.
یک پیکربندی بسیار ساده برای DHCPv4 می‌تواند به این شکل باشد:
0.0
3.5
# The whole configuration starts here.
{
# DHCPv4 specific configuration starts here.
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth0" ],
"dhcp-socket-type": "raw"
},
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"subnet4": [{
"pools": [ { "pool": "192.0.2.1-192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"id": 1
}],
# Now loggers are inside the DHCPv4 object.
"loggers": [{
"name": "*",
"severity": "DEBUG"
}]
}
# The whole configuration structure ends here.
}
168u
168u
مثال‌های بیشتر در دایرکتوری نصب‌شده share/doc/kea/examples در دسترس هستند.
برای جلوگیری از تکرار ساختارهای عمدتاً مشابه، مثال‌های بخش‌های بعدی این راهنما تنها زیرمجموعه‌ای از پارامترهای مناسب برای یک بافت مشخص را نمایش می‌دهند. برای مثال، هنگام بحث درباره پیکربندی زیرشبکه‌های IPv6 در DHCPv6، تنها پارامترهای subnet6 ذکر خواهند شد. بدیهی است که سایر عناصر (نگاشت سراسری که شامل Dhcp6 است) وجود دارند، اما برای وضوح بیشتر حذف شده‌اند. معمولاً مکان‌هایی که پارامترهای اضافی ممکن است ظاهر شوند با سه‌نقطه (...) مشخص شده‌اند.
"کامنت‌ها و بافت کاربری (Comments and User Context)"
در صورتی که فایل پیکربندی JSON به‌صورت محلی استفاده شود، کامنت‌های به سبک شل، C یا C++ همگی در آن مجاز هستند. این روش راحت است و در موارد ساده‌ای که پیکربندی به‌صورت ایستا با استفاده از یک فایل محلی نگهداری می‌شود کارایی دارد. با این حال، از آنجا که کامنت‌ها بخشی از نحو JSON نیستند، بیشتر ابزارهای JSON آن‌ها را به عنوان خطا تشخیص می‌دهند. مشکل دیگر این است که به محض بارگیری پیکربندی توسط Kea، کامنت‌های به سبک شل، C و C++ نادیده گرفته می‌شوند. اگر دستورهایی مانند config-get <#std-isccmd-config-get> یا config-write <#std-isccmd-config-write> استفاده شوند، آن کامنت‌ها از دست می‌روند. نمونه‌ای از این کامنت‌ها در بخش پیشین ارائه شد.
از نظر تاریخی، برای رفع این مشکل، کد Kea استفاده از رشته‌های comment را به عنوان موجودیت‌های معتبر JSON مجاز دانست. این ویژگی این مزیت را داشت که در طول عملیات مختلف (مانند config-get <#std-isccmd-config-get>) حفظ می‌شد یا امکان پردازش توسط ابزارهای JSON را فراهم می‌کرد. نمونه‌ای از یک کامنت JSON بدین صورت است:
0.0
3.5
"Dhcp4": {
"subnet4": [{
"id": 1,
"subnet": "192.0.2.0/24",
"pools": [{ "pool": "192.0.2.10 - 192.0.2.20" }],
"comment": "second floor"
}]
}
168u
168u
با این حال، این واقعیت که کامنت تنها می‌توانست تک‌خطی باشد و امکان افزودن اطلاعات دیگر در قالبی ساختاریافته‌تر وجود نداشت، ناامیدکننده بود. یک نمونه مشخص، درخواست برای افزودن شماره طبقات و ساختمان‌ها به زیرشبکه‌ها بود. این امر یکی از دلایلی بود که مفهوم بافت کاربری (user context) معرفی شد؛ مفهومی که اجازه افزودن یک ساختار دلخواه JSON را به اکثر ساختارهای پیکربندی Kea می‌دهد.
این روش در مقایسه با رویکردهای پیشین مزایای متعددی دارد. اولاً کاملاً با ابزارهای JSON و دستورهای Kea سازگار است. ثانیاً علاوه بر ذخیره رشته‌های ساده کامنت، می‌تواند داده‌های بسیار پیچیده‌تری را ذخیره کند، مانند چند خط (به‌صورت آرایه‌ای از رشته‌ها)، داده‌های نوع‌دار اضافی (مانند شماره طبقات به‌صورت عددی واقعی) و موارد دیگر. ثالثاً این داده‌ها در دسترس قلاب‌ها قرار می‌گیرند، بنابراین امکان توسعه قلاب‌های شخص ثالث که از این اطلاعات اضافی بهره می‌برند وجود دارد. نمونه‌ای از یک بافت کاربری بدین شکل است:
0.0
3.5
"Dhcp4": {
"subnet4": [{
"id": 1,
"subnet": "192.0.2.0/24",
"pools": [{ "pool": "192.0.2.10 - 192.0.2.20" }],
"user-context": {
"comment": "second floor",
"floor": 2
}
}]
}
168u
168u
بافت‌های کاربری تا زمانی که از نحو معتبر JSON پیروی کنند و عنصر سطح بالای آن‌ها یک نگاشت باشد (یعنی داده‌ها باید درون آکوالاد قرار گیرند)، می‌توانند هر فایل داده دلخواهی را ذخیره کنند. با این حال، برخی از کتابخانه‌های قلاب ممکن است قالب‌بندی خاصی را انتظار داشته باشند؛ لطفاً برای جزئیات به مستندات کتابخانه قلاب مربوطه مراجعه کنید.
سازوکار user-context جایگزین قابلیت‌های کامنت JSON شده است؛ ISC به مدیران سیستم توصیه می‌کند به‌جای سازوکارهای قدیمی‌تر، از user context استفاده کنند. برای ترویج این شیوه ذخیره کامنت‌ها، Kea کامنت‌های JSON را به‌صورت خودکار و بلادرنگ به user context تبدیل می‌کند.
با این حال، اگر پیکربندی از روش قدیمی کامنت JSON استفاده کند، دستور config-get <#std-isccmd-config-get> یک پیکربندی اندکی تغییریافته را برمی‌گرداند. این مورد غیرمعمول نیست که فراخوانی config-set <#std-isccmd-config-set> و به دنبال آن config-get <#std-isccmd-config-get> ساختاری کمی متفاوت را دریافت کند. بهترین راه برای جلوگیری از این مشکل این است که استفاده از کامنت‌های JSON را کنار گذاشته و از user context استفاده کنید.
‏Kea از بافت‌های کاربری در سطوح زیر پشتیبانی می‌کند: دامنه سراسری (global scope)، پیکربندی رابط‌ها (interfaces configuration)، چندریسمانی (multi-threading)، شبکه‌های اشتراکی (shared networks)، زیرشبکه‌ها (subnets)، کلاس‌های کلاینت (client classes)، داده‌ها و تعاریف گزینه‌ها (option data and definitions)، استخرها (pools)، استخرهای واگذاری پیشوند (prefix delegation pools)، رزروهای میزبان (host reservations)، سوکت کنترل (control socket)، سرآیند HTTP، احراز هویت (authentication)، کلاینت‌ها (clients)، کنترل صف (queue control)، ‏DHCP-DDNS، ثبت‌کننده‌ها (loggers)، اجاره‌ها (leases) و شناسه سرور (server ID). این موارد در هر دو DHCPv4 و DHCPv6 پشتیبانی می‌شوند، به استثنای استخرهای واگذاری پیشوند و شناسه سرور که تنها مختص DHCPv6 هستند.
بافت کاربری را می‌توان در ساختارهای پشتیبانی‌شده توسط دستورها افزود و ویرایش کرد.
ما کاربران Kea را تشویق می‌کنیم که از این توابع برای ذخیره اطلاعات مورد استفاده سایر سامانه‌ها و قلاب‌های سفارشی استفاده کنند.
برای مثال، می‌توان از دستور subnet4-update <#std-isccmd-subnet4-update> برای افزودن داده‌های بافت کاربری به یک زیرشبکه موجود استفاده کرد.
0.0
3.5
{
"subnet4": [ {
"id": 1,
"subnet": "10.20.30.0/24",
"user-context": {
"building": "Main",
"floor": 1
}
} ]
}
168u
168u
همین کار را می‌توان با بسیاری از دستورهای دیگر، مانند lease6-add <#std-isccmd-lease6-add> و غیره نیز انجام داد.
‏Kea همچنین از بافت کاربری برای ذخیره داده‌های غیراستاندارد استفاده می‌کند. در حال حاضر، تنها Storing Extended Lease Information <#dhcp4-store-extended-info> از این قابلیت استفاده می‌کند.
در صورت فعال بودن، کلید ISC در user-context اضافه می‌شود تا محتوای اضافه‌شده خودکار را متمایز کند.
نمونه‌ای از اطلاعات رله ذخیره‌شده در یک اجاره:
0.0
3.5
{
"arguments": {
"client-id": "42:42:42:42:42:42:42:42",
"cltt": 12345678,
"fqdn-fwd": false,
"fqdn-rev": true,
"hostname": "myhost.example.com.",
"hw-address": "08:08:08:08:08:08",
"ip-address": "192.0.2.1",
"state": 0,
"subnet-id": 44,
"valid-lft": 3600,
"user-context": {
"ISC": {
"relays": [
{
"hop": 2,
"link": "2001:db8::1",
"peer": "2001:db8::2"
},
{
"hop": 1,
"link": "2001:db8::3",
"options": "0x00C800080102030405060708",
"peer": "2001:db8::4"
}]
}
}
}
}
168u
168u
بافت کاربری می‌تواند پیکربندی مربوط به چندین قلاب و کامنت را به‌طور هم‌زمان ذخیره کند.
برای بررسی نحوه استفاده از بافت کاربری در قلاب‌ها، به User Contexts in Hooks <#user-context-hooks> مراجعه کنید..SS "نشانه‌گذاری ساده‌شده (Simplified Notation)"
گاهی اوقات ارجاع به یک عنصر خاص در سلسله‌مراتب پیکربندی راحت‌تر است. هر سطح سلسله‌مراتب با یک اسلش جدا می‌شود.
اگر آرایه‌ای وجود داشته باشد، به نمونه‌ای خاص درون آن آرایه با عددی در داخل قلاب‌ها ارجاع داده می‌شود (با شماره‌گذاری که از
صفر آغاز می‌شود). برای نمونه، در پیکربندی بالا، valid-lifetime در مؤلفه
Dhcp4 می‌تواند به‌صورت Dhcp4/valid-lifetime، و pool
در نخستین زیرشبکه تعریف‌شده در پیکربندی DHCPv4 به‌صورت
Dhcp4/subnet4[0]/pool ارجاع داده شود.
"گنجاندن فایل‌های پیکربندی (Configuration Files Inclusion)"
تجزیه‌کننده قابلیت گنجاندن فایل‌ها را فراهم می‌آورد. نحو دستور به‌گونه‌ای انتخاب شده است
که شبیه به نحوه گنجاندن اسکریپت‌های PHP در کد HTML توسط Apache به نظر برسد. این نحو
خاص برای تأکید بر این موضوع انتخاب شده است که دستور include یک ویژگی اضافی است
و بخشی از نحو JSON به شمار نمی‌رود.
گنجاندن به‌صورت پشته‌ای از فایل‌ها پیاده‌سازی شده است. می‌توانید از دستور include
در گنجاندن‌های تودرتو استفاده کنید. حداکثر ده سطح تودرتویی پشتیبانی می‌شود. این محدودیت
که به‌طور دلخواه انتخاب شده، محافظتی در برابر گنجاندن‌های بازگشتی است.
دستور include فرم زیر را دارد:
0.0
3.5
<?include "[PATH]"?>
168u
168u
الگوی [PATH] باید با یک مسیر مطلق یا یک مسیر نسبت به
دایرکتوری کاری جاری در زمان اجرای فرایند Kea جایگزین شود.
برای گنجاندن یک فایل درون فایلی دیگر، از نحو زیر استفاده کنید:
0.0
3.5
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "*" ]},
"preferred-lifetime": 3000,
"rebind-timer": 2000,
"renew-timer": 1000,
<?include "subnets.json"?>
"valid-lifetime": 4000
}
}
168u
168u
جایی که محتوای "subnets.json" می‌تواند چنین باشد:
0.0
3.5
{
"subnet4": [
{
"id": 123,
"subnet": "192.0.2.0/24"
},
{
"id": 234,
"subnet": "192.0.3.0/24"
},
{
"id": 345,
"subnet": "10.0.0.0/8"
}
],
...
}
168u
168u
"پس‌زمینه پیکربندی Kea (Kea Configuration Backend)"
"کاربردپذیری (Applicability)"
پس‌زمینه پیکربندی Kea (به اختصار CB یا config backend) به سرورهای Kea این
قابلیت را می‌دهد تا تقریباً همه پیکربندی خود را در یک یا چند پایگاه‌داده ذخیره کنند.
ویژگی‌ها و مزایای بالقوه شامل موارد زیر است:
0.0
• 2
استفاده مجدد از بخش‌های پیکربندی یکسان در چندین سرور Kea
• 2
یک "منبع واحد حقیقت" برای همه سرورهای Kea
• 2
انجام تمام پیکربندی‌ها از طریق یک API به همراه بررسی‌های منطقی بی‌درنگ
• 2
یکپارچه‌سازی آسان‌تر با ابزارهای شخص ثالث یا خودکارسازی‌های درون‌سازمانی
• 2
معماری پایگاه‌داده همزمانی، سازگاری و تفکیک‌ناپذیری (atomicity) را فراهم می‌کند
• 2
قابلیت کاوش در پایگاه‌داده برای استخراج آمار و گزارش‌گیری
• 2
استفاده از همانندسازی (replication) پایگاه‌داده برای تحمل خطای بی‌درنگ
168u
معایب بالقوه شامل موارد زیر است:
0.0
• 2
تلاش اولیه قابل‌توجه برای آماده‌سازی یکپارچه‌سازی و/یا خودکارسازی
• 2
سناریوهای پشتیبانی‌شده برای بیشتر پیکربندی‌ها به استفاده از API نیاز دارند
• 2
این API تنها برای مشتریان ISC با یک قرارداد پشتیبانی پولی در دسترس است
• 2
ناسازگار با برخی کاربردها، نرم‌افزارها و سناریوها
168u
نکته:
0.0
3.5
استفاده از یک پایگاه‌داده برای ذخیره‌سازی اجاره‌ها (leases) و/یا رزروهای میزبان (host reservations)
بدون استفاده از CB امکان‌پذیر است. دستورالعمل‌های پیکربندی host-databases و
lease-database را ببینید.
168u
سازمان بزرگی را با چندین شعبه (site) در نظر بگیرید که در هر یک، یک جفت کارساز Kea در پیکربندی دسترسی‌پذیری بالا (HA) مستقر شده است. معمولاً چنین استقرارهایی از پیکربندی‌های استانداردسازی‌شده استفاده می‌کنند که منجر به پارامترهای پیکربندی مشابه برای هر شعبه می‌شود. اعضای هر جفت HA اغلب تقریباً کاملاً یکسان هستند و فقط در نام با یکدیگر تفاوت دارند. اغلب استقرارهایی با این ابعاد از سطح بالایی از اتوماسیون، شامل سامانه‌های تدارک (provisioning) و مدیریت بهره می‌برند.
بک‌اند پیکربندی (CB) برای چنین استقرارهایی ایده‌آل است. اگرچه ادغام آن با اتوماسیون تدارک به مقداری تلاش نیاز دارد، اما پس از انجام، استقرار کارسازهای جدید Kea می‌تواند تقریباً خودکار باشد. می‌توان از یک پیکربندی JSON اولیه و حداقلی ("stub") که برای هر کارساز یکسان است استفاده کرد و تمام پیکربندی‌های باقی‌مانده (شبکه‌های مشترک، زیرشبکه‌ها، استخرها و غیره) را از پایگاه‌داده مرکزی CB بارگذاری نمود. هرگونه به‌روزرسانی در پایگاه‌داده مرکزی CB به‌طور خودکار به تمام نمونه‌های Kea منتشر می‌شود. بدین ترتیب CB به "تنها منبع حقیقت" (single source of truth) برای DHCP در سراسر سازمان تبدیل می‌شود.
محدودیت‌ها و هشدارها
دسترسی‌پذیری
libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس است. برای کسب اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در https://www.isc.org/contact را تکمیل کنید. اگرچه از نظر تئوری استفاده از CB بدون این قلاب (hook) امکان‌پذیر است، اما این کار نه پشتیبانی می‌شود و نه توصیه می‌گردد.
نیازمندی به آماده‌سازی
بک‌اند پیکربندی (Configuration Backend) یک راهکار آماده و خودکار ("plug-and-play") نیست. سناریوهای پشتیبانی‌شده به استفاده از دستورهای CB API نیاز دارند. اطلاعات پیکربندی باید با استفاده از API در پایگاه‌داده CB بارگذاری شوند تا CB تأثیرگذار باشد. هدف کلی این است که CB به عنوان بخشی از یک راهکار تدارک (provisioning) بزرگ‌تر یکپارچه شود. لطفاً تا زمانی که کارهای آماده‌سازی لازم را انجام نداده‌اید، config-databases را تعریف نکنید.
مدیریت پایگاه‌داده
تنها روش پشتیبانی‌شده برای مدیریت محتوای پایگاه‌داده CB، از طریق قلاب libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> است که دستورهای API را برای بک‌اندهای پیکربندی ارائه می‌دهد. از نظر عملی، برای استفاده از CB، باید تقریباً تمام پیکربندی Kea را از طریق CB API انجام دهید.
اگرچه از نظر تئوری امکان استفاده از CB بدون API (با استفاده از ابزارهایی مانند MySQL Workbench یا کلاینت خط فرمانی MySQL) وجود دارد، اما این روش‌ها نه توصیه می‌شوند و نه پشتیبانی دارند.
تداخل‌های پیکربندی
ما قویاً توصیه می‌کنیم از ادغام اطلاعات پیکربندی CB و فایل پیکربندی JSON خودداری کنید. به عبارت دیگر، از هر دو روش تعاریف پیکربندی JSON و CB برای پیکربندی انواع یکسان اشیاء استفاده نکنید. در حالت ایده‌آل، هنگام استفاده از CB، فایل‌های پیکربندی Kea باید حاوی حداقل‌های ضروری مطلق باشند و هر چیز دیگری از طریق CB تأمین شود.
استفاده هم‌زمان از CB و JSON به عنوان منبع پیکربندی، خطر تداخل تعاریف را به همراه دارد. چنین تداخل‌هایی در بهترین حالت گیج‌کننده هستند و معمولاً منجر به رفتارهای ناخواسته یا بروز خطا از جانب Kea می‌شوند.
در صورت بروز تداخل، دستورالعمل‌های پیکربندی پایگاه‌داده CB معمولاً نسبت به دستورالعمل‌های فایل JSON اولویت دارند.
در برخی سناریوهای به‌دقت کنترل‌شده، ممکن است از نظر فنی استفاده از هر دو روش امکان‌پذیر باشد. به عنوان مثال، تعریف یک زیرشبکه در فایل JSON و زیرشبکه دوم (متفاوت) در پایگاه‌داده CB تداخلی ایجاد نمی‌کند. با این حال، ساختارهای دیگر به طور کامل جایگزین می‌شوند. برای مثال، اگر کلاس‌های کلاینت (client classes) در پایگاه‌داده CB تعریف شده باشند، کارساز DHCP تمام کلاس‌های کلاینت تعریف‌شده در فایل JSON را نادیده می‌گیرد.
به طور خلاصه، اگر از CB استفاده می‌کنید، باید تنها از CB استفاده کنید.
نرم‌افزارهای ناسازگار
دستورهای API که پیکربندی Kea را تغییر می‌دهند (به غیر از CB API) منع شده‌اند. این شامل قلاب libdhcp_subnet_cmds.so <#std-ischooklib-libdhcp_subnet_cmds.so> نیز می‌شود. توابع API این قلاب پیکربندی درون حافظه (in-memory) کارساز Kea را تغییر می‌دهند و این تغییرات تنها با استفاده از config-write جهت نوشتن یک فایل پیکربندی JSON جدید ماندگار می‌شوند.
مجموعه مدیریتی Stork https://stork.readthedocs.io در حال حاضر از CB پشتیبانی نمی‌کند. Stork تمامی تغییرات پیکربندی را از طریق روش‌های API انجام می‌دهد که انتظار دارند تغییرات در فایل پیکربندی JSON نوشته شوند. پشتیبانی از CB برای انتشار آینده Stork برنامه‌ریزی شده است.
در برخی سناریوهای به‌دقت کنترل‌شده، ممکن است استفاده از این ابزارها همراه با CB امکان‌پذیر باشد؛ به ویژه اگر به صورت کاملاً "فقط‌خواندنی" (read-only) صرفاً برای بازیابی اطلاعات Kea و نه هرگز برای تغییر آن به کار روند. با این حال، هیچ محافظتی در برابر تغییرات تصادفی وجود ندارد، بنابراین این روش توصیه نمی‌شود.
محدودیت‌ها
در حال حاضر، Kea CB دارای محدودیت‌های زیر است:
0.0
• 2
تنها برای پایگاه‌های داده MySQL و PostgreSQL پشتیبانی می‌شود.
• 2
تنها برای دیمن‌های DHCPv4 و DHCPv6 پشتیبانی می‌شود؛ دیمن D2 و دیمن NETCONF را نمی‌توان از پایگاه‌داده پیکربندی کرد.
• 2
تنها پارامترهای پیکربندی خاصی از DHCP را می‌توان در پایگاه‌داده تنظیم کرد: پارامترهای سراسری، تعاریف گزینه‌ها، گزینه‌های سراسری، کلاس‌های کلاینت، شبکه‌های مشترک و زیرشبکه‌ها. سایر پارامترهای پیکربندی باید از یک فایل پیکربندی JSON تأمین شوند.
168u
گزینه‌های سفارشی
استفاده از قالب‌های گزینه‌ سفارشی نیازمند ایجاد تعاریف برای این گزینه‌ها است. فرض کنید کاربری بخواهد داده‌های گزینه را در بک‌اند پیکربندی تنظیم کند. در این صورت، توصیه می‌کنیم تعریف مربوط به آن گزینه را نیز در بک‌اند پیکربندی مشخص نمایید. این امر زمانی ضروری است که چندین کارساز از طریق بک‌اند پیکربندی مدیریت می‌شوند و ممکن است پیکربندی‌های متفاوتی داشته باشند. تجزیه‌گر داده‌های گزینه می‌تواند تعاریف گزینه‌ای را جستجو کند که متناسب با کارسازی باشد که داده‌های گزینه برای آن تعیین شده است.
در یک استقرار تک‌کارساز، یا زمانی که همه کارسازها اطلاعات فایل پیکربندی یکسانی را به اشتراک می‌گذارند، می‌توان تعاریف گزینه‌ها را در فایل‌های پیکربندی و داده‌های گزینه را در بک‌اند پیکربندی مشخص کرد. کارسازی که دستوری برای تنظیم داده‌های گزینه دریافت می‌کند، حتی زمانی که داده‌های گزینه را برای کارساز دیگری تنظیم می‌کند، باید تعریفی معتبر در فایل پیکربندی خود داشته باشد.
مشخص کردن تعاریف گزینه‌ها در بک‌اند پیکربندی و داده‌های متناظر گزینه در فایل‌های پیکربندی کارساز پشتیبانی نمی‌شود.
اجزاء
راهکار Kea Configuration Backend متشکل از ماژول‌های CB (کتابخانه‌های قلاب)، رابط برنامه‌نویسی دستورهای CB (کتابخانه قلاب اختصاصی خود)، نرم‌افزار پایگاه‌داده خارجی (MySQL یا PostgreSQL)، طرح‌واره (schema) پایگاه‌داده و اطلاعات پیکربندی Kea ذخیره‌شده در پایگاه‌داده است.
در این مستندات، اصطلاح "Configuration Backend" ممکن است به ماژول خاصی از Kea نیز اشاره داشته باشد که پشتیبانی از آن نوع پایگاه‌داده را فراهم می‌کند. به عنوان مثال، بک‌اند پیکربندی MySQL، یعنی libdhcp_mysql.so <#std-ischooklib-libdhcp_mysql.so>، مجموعه‌ای کامل از توابع را برای مدیریت و واکشی اطلاعات پیکربندی از یک پایگاه‌داده MySQL فراهم می‌سازد. بک‌اند پیکربندی PostgreSQL، یعنی libdhcp_pgsql.so <#std-ischooklib-libdhcp_pgsql.so>، ماژول متناظر برای PostgreSQL است. به همین ترتیب، اصطلاح "پایگاه‌داده" برای اشاره به هر دو پایگاه‌داده MySQL یا PostgreSQL به کار می‌رود.
رابط برنامه‌نویسی دستورهای CB مجموعه‌ای کامل از دستورها را برای مدیریت اطلاعات پیکربندی Kea، همان‌گونه که در پایگاه‌داده ذخیره شده است، ارائه می‌دهد. این API در کتابخانه قلاب اختصاصی خود، یعنی libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> پیاده‌سازی شده است. این کتابخانه را می‌توان به هر دو نمونه کارساز DHCPv4 و DHCPv6 متصل کرد. این ماژول بسیاری از عملیات متداول، مانند فهرست‌کردن، افزودن، واکشی و حذف پارامترهای سراسری، شبکه‌های مشترک، زیرشبکه‌ها، استخرها، گزینه‌ها، تعاریف گزینه‌ها و کلاس‌های کلاینت را ساده می‌کند. علاوه بر این، منطق تجاری ضروری را برای تضمین یکپارچگی منطقی داده‌ها فراهم می‌آورد. تمامی دستورهای CB API با remote- آغاز می‌شوند. برای اطلاعات بیشتر به libdhcp_cb_cmds.so: Configuration Backend Commands <#hooks-cb-cmds> مراجعه کنید.
نصب و نگهداری نرم‌افزارهای پایگاه‌داده خارجی فراتر از حوزه این راهنما است.
طرح‌واره (schema) پایگاه‌داده معمولاً از طریق ابزار kea-admin <#std-iscman-kea-admin> نصب می‌شود. برای اطلاعات بیشتر به Installation مراجعه کنید. اسکریپت‌های خام ایجاد طرح‌واره عبارتند از:
dhcpdb_create.mysql https://gitlab.isc.org/isc-projects/kea/blob/master/src/share/database/scripts/mysql/dhcpdb_create.mysql
و
dhcpdb_create.pgsql https://gitlab.isc.org/isc-projects/kea/blob/master/src/share/database/scripts/pgsql/dhcpdb_create.pgsql.
برای مقداردهی و پر کردن پایگاه‌داده با اطلاعات پیکربندی Kea، از API دستورهای CB استفاده کنید.
اسناد طراحی مرتبط در GitLab ما در دسترس هستند:
0.0
• 2
طراحی CB https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/configuration-in-db-design
• 2
طراحی کلاس‌های کلاینت در CB https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/client-classes-in-cb
برای استفاده از هر یک از Backendهای پیکربندی، کتابخانهٔ ماژول مناسب
(libdhcp_mysql.so <#std-ischooklib-libdhcp_mysql.so> یا libdhcp_pgsql.so <#std-ischooklib-libdhcp_pgsql.so>) باید
در حین ساخت Kea کامپایل شود. سوییچ -D مشخص می‌کند که در صورت وجود،
کدام ماژول پایگاه‌داده ساخته شود: -D mysql=enabled یا -D postgresql=enabled. کتابخانه‌های
کلاینت پایگاه‌داده و فایل‌های هدر مناسب باید پیش از ساخت نصب شده باشند. برای
اطلاعات بیشتر دربارهٔ ساخت Kea با پشتیبانی از پایگاه‌داده، به «نصب و پیکربندی پایگاه‌دادهٔ DHCP» <#dhcp-install-configure> مراجعه کنید.
بسته‌بندی‌های Kea ارائه‌شده توسط ISC، و همچنین برخی از توزیع‌های شخص ثالث، بسته‌های
جداگانه‌ای را برای هر نوع پایگاه‌داده ارائه می‌دهند.
سرور پایگاه‌داده‌ای که میزبان جدول‌های CB است باید با شِمای Kea
آماده‌سازی شود. هنگام ارتقای یک نصب موجود از Kea، ممکن است شِمای پایگاه‌داده نیز
به ارتقا نیاز داشته باشد. از ابزار kea-admin <#std-iscman-kea-admin> می‌توان برای اعمال
راحت‌تر شِما استفاده کرد، همان‌طور که در «ابزار kea-admin» <#kea-admin> شرح داده شده است.
در زمان اجرا، سرورهای DHCP باید برای بارگیری ماژول در بخش
hooks-libraries پیکربندی شوند. سپس باید از دستورالعمل config-databases
برای هدایت Kea به بارگیری پیکربندی با استفاده از backend پایگاه‌داده استفاده شود.
پیکربندی‌های خاص سرورهای DHCPv4 و DHCPv6 برای CB و همچنین فهرست پارامترهای
پیکربندی پشتیبانی‌شده، به‌ترتیب در «Backend پیکربندی در DHCPv4» <#dhcp4-cb>
و «Backend پیکربندی در DHCPv6» <#dhcp6-cb> یافت می‌شوند.
پس از اتمام نصب، می‌توان از API دستورات CB برای پر کردن پایگاه‌داده با اطلاعات پیکربندی Kea استفاده کرد.
"اشتراک‌گذاری پیکربندی و برچسب‌های سرور (Configuration Sharing and Server Tags)"
پایگاه‌دادهٔ پیکربندی برای ذخیرهٔ اطلاعات پیکربندی چندین سرور Kea طراحی شده است.
بسته به مورد استفاده، کل پیکربندی ممکن است میان تمام سرورها به اشتراک گذاشته شود؛
بخش‌هایی از پیکربندی ممکن است توسط چندین سرور به اشتراک گذاشته شده و باقی پیکربندی
برای این سرورها متفاوت باشد؛ یا هر سرور ممکن است پیکربندی غیرمشترک مخصوص به خود را داشته باشد.
عناصر پیکربندی در پایگاه‌داده با استفاده از "برچسب‌های سرور" (server tags) به سرورها منتسب می‌شوند.
برچسب سرور یک رشتهٔ دلخواه حاوی نام نمونهٔ سرور Kea است. برچسب‌های سرورهای DHCPv4 و DHCPv6
در پایگاه‌داده مستقل هستند، یعنی می‌توان همان برچسب سرور را برای هر دو سرور DHCPv4 و DHCPv6 ایجاد کرد.
این مقدار با استفاده از پارامتر server-tag در حوزهٔ Dhcp4 یا Dhcp6 پیکربندی می‌شود.
برچسب سرور فعلی را می‌توان با دستور server-tag-get <#std-isccmd-server-tag-get> بررسی کرد.
تعریف سرور، که شامل برچسب سرور و توضیحات سرور است، باید پیش از ایجاد
پیکربندی اختصاصی برای آن سرور، در پایگاه‌دادهٔ پیکربندی ذخیره شود. در مواردی
که همهٔ سرورها از پیکربندی یکسانی استفاده می‌کنند، مانند یک جفت سرور که به‌عنوان
همتایان دسترسی‌پذیری بالا (High Availability) اجرا می‌شوند، نیازی به پیکربندی
برچسب‌های سرور برای این سرورها در پایگاه‌داده نیست.
دستوراتی که شامل سرور منطقی all هستند بر تمام سرورهای متصل به
پایگاه‌داده اعمال می‌شوند. سرور all را نمی‌توان حذف یا ویرایش کرد،
و در نتیجهٔ دستورهای remote-server4-get-all <#std-isccmd-remote-server4-get-all> و
remote-server6-get-all <#std-isccmd-remote-server6-get-all> در میان سرورهای دیگر بازگردانده نمی‌شود.
در بیشتر موارد، هیچ برچسب سروری در پایگاه‌دادهٔ پیکربندی تعریف نشده است؛
همهٔ سرورهای متصل‌شونده، بدون در نظر گرفتن برچسب سروری که استفاده می‌کنند،
پیکربندی یکسانی دریافت می‌کنند. برچسب سروری که یک نمونهٔ خاص Kea برای دریافت
پیکربندی خود به پایگاه‌داده ارائه می‌دهد، در فایل پیکربندی Kea با استفاده از نگاشت
config-control مشخص می‌شود (لطفاً برای جزئیات به «فعال‌سازی Backend پیکربندی» <#dhcp4-cb-json> و
«فعال‌سازی Backend پیکربندی» <#dhcp6-cb-json> مراجعه کنید). به تمام نمونه‌های Kea که برچسب سرور
یکسانی را به پایگاه‌دادهٔ پیکربندی ارائه می‌دهند، پیکربندی یکسانی داده می‌شود.
این به انتخاب مدیر سیستم بستگی دارد که چندین نمونهٔ Kea از یک برچسب سرور
استفاده کنند یا هر نمونهٔ Kea از برچسب سرور متفاوتی بهره ببرد. هیچ الزامی وجود
ندارد که نمونه‌های در حال اجرا بر روی یک ماشین فیزیکی یا مجازی یکسان، از برچسب
سرور مشابهی استفاده کنند. حتی امکان پیکربندی سرور Kea بدون انتساب برچسب سرور به آن نیز
وجود دارد. در چنین حالتی، به سرور پیکربندیِ مشخص‌شده برای سرورهای all داده خواهد شد.
برای تفکیک میان پیکربندی‌های مختلف سرور Kea، فهرستی از برچسب‌های سرور استفاده‌شده
توسط سرورها باید در پایگاه‌داده ذخیره شود. برای سرورهای DHCPv4 و DHCPv6، این کار می‌تواند با استفاده از
دستورهای remote-server4-set <#std-isccmd-remote-server4-set> و remote-server6-set <#std-isccmd-remote-server6-set> انجام شود.
سپس می‌توان از برچسب‌های سرور برای انتساب اطلاعات پیکربندی به سرورها استفاده کرد. با این حال،
توجه به این نکته مهم است که برخی از عناصر پیکربندی DHCP ممکن است با چندین برچسب سرور مرتبط شوند (معروف به
عناصر "اشتراک‌پذیر")، در حالی که سایر عناصر پیکربندی ممکن است تنها با یک برچسب سرور مرتبط باشند
(عناصر "غیرقابل‌اشتراک"). بخش‌های «Backend پیکربندی در DHCPv4» <#dhcp4-cb>
و «Backend پیکربندی در DHCPv6» <#dhcp6-cb> عناصر پیکربندی اشتراک‌پذیر و غیرقابل‌اشتراک مختص DHCP را
فهرست می‌کنند؛ با این حال، در این بخش تفاوت‌های میان آن‌ها را به اختصار شرح می‌دهیم.
یک عنصر پیکربندی اشتراک‌پذیر عنصری است که دارای یک ویژگی منحصربه‌فردِ شناسایی‌کننده بوده
و ممکن است تنها یک‌بار در پایگاه‌داده وجود داشته باشد. مثالی از یک عنصر DHCP اشتراک‌پذیر،
نمونهٔ یک زیرشبکه (subnet) است: زیرشبکه بخشی از توپولوژی شبکه است و فرض می‌کنیم
که هر زیرشبکهٔ خاص تنها می‌تواند یک تعریف در این شبکه داشته باشد. هر زیرشبکه دارای دو شناسهٔ منحصربه‌فرد است:
شناسهٔ زیرشبکه و پیشوند زیرشبکه. شناسهٔ زیرشبکه در Kea برای شناسایی یکتای زیرشبکه در شبکه و
اتصال آن به سایر عناصر پیکربندی، مثلاً در رزروهای میزبان (host reservations)، استفاده می‌شود. برخی از دستورات
ارائه‌شده توسط libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> امکان دسترسی
به اطلاعات زیرشبکه را از طریق شناسهٔ زیرشبکه یا پیشوند فراهم می‌کنند، و استفاده از برچسب سرور را برای
دسترسی به زیرشبکه صراحتاً منع می‌نمایند. علت این است که به‌طور کلی، تعریف زیرشبکه به‌جای یک سرور واحد،
با چندین سرور مرتبط است. در واقع، حتی ممکن است با هیچ سروری مرتبط نباشد (تخصیص‌نیافته یا unassigned). با این وجود،
زیرشبکهٔ تخصیص‌نیافته دارای شناسه و پیشوندی است که می‌توان از آن‌ها برای دسترسی به زیرشبکه استفاده کرد.
یک عنصر پیکربندی اشتراک‌پذیر ممکن است با چندین سرور، یک سرور، یا هیچ سروری مرتبط باشد.
حذف سروری که با عنصر اشتراک‌پذیر مرتبط است موجب حذف عنصر اشتراک‌پذیر نمی‌شود.
این کار صرفاً ارتباطِ سرورِ حذف‌شده را با آن عنصر پاک می‌کند.
برخلاف یک عنصر اشتراک‌پذیر، یک عنصر غیرقابل‌اشتراک نباید صراحتاً با بیش از یک سرور مرتبط شود
و پس از حذف سرور نباید باقی بماند (نباید بدون تخصیص باقی بماند). یک عنصر غیرقابل‌اشتراک
فقط در بافتار (context) سرور وجود دارد. نمونه‌ای از یک عنصر غیرقابل‌اشتراک در DHCP، یک پارامتر سراسری
مانند renew-timer است. تایمر تمدید مقداری است که باید توسط یک سرور خاص و صرفاً همین
سرور استفاده شود. سرورهای دیگر ممکن است تایمرهای تمدید مربوط به خود را با مقادیر یکسان یا متفاوتی
تنظیم کرده باشند. پارامتر تایمر تمدید فاقد هرگونه شناسهٔ منحصربه‌فردی است که بتوان از طریق آن بدان
دسترسی یافت، ویرایشش کرد، یا به شیوهٔ دیگری از آن استفاده نمود. پارامترهای سراسری مانند تایمر تمدید
می‌توانند با نام پارامتر و برچسب سروری که برای آن پیکربندی شده‌اند در دسترس قرار گیرند. برای مثال، دستورهای
remote-global-parameter4-get <#std-isccmd-remote-global-parameter4-get> و
remote-global-parameter6-get <#std-isccmd-remote-global-parameter6-get> امکان دریافت
مقدار پارامتر سراسری را با نام پارامتر و نام سرور فراهم می‌آورند. دریافت پارامتر سراسری صرفاً بر اساس نام آن
(بدون مشخص کردن برچسب سرور) امکان‌پذیر نیست، زیرا ممکن است پارامترهای سراسری متعددی با یک نام مشخص در پایگاه‌داده وجود داشته باشد.
هنگامی که سرور مرتبط با یک عنصر پیکربندی غیرقابل‌اشتراک حذف می‌شود، عنصر پیکربندی
به‌طور خودکار به همراه سرور از پایگاه‌داده حذف می‌گردد زیرا عنصر غیرقابل‌اشتراک باید همواره
به یک سرور (یا سرور منطقی all) تخصیص یافته باشد.
اصطلاحات "اشتراک‌پذیر" و "غیرقابل‌اشتراک" تنها برای ارتباطات با سرورهای تعریف‌شده توسط کاربر
به‌کار می‌روند؛ تمامی عناصر پیکربندی مرتبط با سرور منطقی all بنا به تعریف، اشتراک‌پذیر هستند.
برای مثال: پارامتر renew-timer مرتبط با سرورهای all توسط تمامی سرورهای متصل به پایگاه‌داده که
تایمرهای تمدید خاص خود را تعریف نکرده‌اند استفاده می‌شود. در یک حالت خاص، زمانی که هیچ‌یک از عناصر
پیکربندی با سرورهای تعریف‌شده توسط کاربر مرتبط نباشند، کل پیکربندی موجود در پایگاه‌داده اشتراک‌پذیر است زیرا
تمامی بخش‌های آن به سرورهای all تعلق دارند.
نکته:
0.0
3.5
هنگام مرتبط کردن عناصر پیکربندی با برچسب‌های سرور مختلف بسیار محتاط باشید. Backend پیکربندی در
برابر برخی از پیکربندی‌های نادرست احتمالی که ممکن است ناشی از انتساب‌های اشتباه برچسب‌های سرور باشند،
محافظت نمی‌کند. برای مثال: اگر یک شبکهٔ مشترک (shared network) به یک سرور و زیرشبکه‌های متعلق به این
شبکهٔ مشترک به سرور دیگری اختصاص داده شوند، سرورها در هنگام تلاش برای دریافت و استفاده از این پیکربندی
با خطا مواجه خواهند شد. سروری که زیرشبکه‌ها را واکشی می‌کند آگاه خواهد بود که این زیرشبکه‌ها با شبکهٔ مشترک
مرتبط هستند، اما شبکهٔ مشترک توسط این سرور پیدا نخواهد شد زیرا متعلق به آن نیست. در چنین حالتی، هم شبکهٔ
مشترک و هم زیرشبکه‌ها باید به مجموعهٔ یکسانی از سرورها اختصاص یابند.
168u
"نمای کلی (Overview)"
اسکریپت شل keactrl <#std-iscman-keactrl> راه‌اندازی، خاموش کردن و پیکربندی مجدد سرورهای Kea (شامل kea-dhcp4 <#std-iscman-kea-dhcp4>، kea-dhcp6 <#std-iscman-kea-dhcp6>، kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> و kea-netconf <#std-iscman-kea-netconf>) را کنترل می‌کند. این اسکریپت همچنین امکاناتی را برای بررسی وضعیت فعلی سرورها و تعیین فایل‌های پیکربندی در حال استفاده فراهم می‌آورد.
ابزار keactrl <#std-iscman-keactrl> تنها زمانی در دسترس است که Kea از سورس ساخته شده باشد. هنگام نصب Kea با استفاده از بسته‌های بومی توزیع، اسکریپت‌های بومی systemd ارائه می‌شوند. برای جزئیات، به بخش Native Packages and systemd مراجعه کنید.
"گزینه‌های خط فرمان (Command Line Options)"
keactrl <#std-iscman-keactrl> به صورت زیر اجرا می‌شود:
0.0
3.5
# keactrl <command> [-c keactrl-config-file] [-s server[,server,...]]
168u
168u
آرگومان <command> یکی از دستورات شرح داده شده در Commands است.
گزینه اختیاری -c keactrl-config-file امکان تعیین یک فایل پیکربندی جایگزین برای keactrl <#std-iscman-keactrl> را فراهم می‌کند. (--ctrl-config مترادفی برای -c است.) در صورت عدم استفاده از -c، keactrl <#std-iscman-keactrl> از فایل پیکربندی پیش‌فرض "[kea-install-dir]/etc/kea/keactrl.conf" استفاده می‌کند.
گزینه اختیاری -s server[,server,...] سرورهایی را که دستور برای آن‌ها صادر می‌شود مشخص می‌کند. (--server مترادفی برای -s است.) در صورت عدم استفاده، دستور به تمامی سرورهای فعال‌شده در فایل پیکربندی keactrl <#std-iscman-keactrl> ارسال می‌شود. اگر چندین سرور مشخص شوند، باید با کاما و بدون فاصله میان آن‌ها از یکدیگر جدا شوند.
"فایل پیکربندی keactrl <#std-iscman-keactrl>"
بسته به نیازمندی‌های مدیر سیستم، ممکن است نیازی به اجرای تمام سرورهای موجود نباشد.
فایل پیکربندی keactrl <#std-iscman-keactrl> مشخص می‌کند که کدام سرورها فعال و کدام غیرفعال هستند. فایل پیکربندی پیش‌فرض "[kea-install-dir]/etc/kea/keactrl.conf" است، اما می‌توان آن را برای هر دستور به صورت جداگانه با استفاده از گزینه -c بازنویسی کرد.
محتویات keactrl.conf به صورت زیر است:
0.0
3.5
# This is a configuration file for keactrl script which controls
# the startup, shutdown, reconfiguration and gathering the status
# of the Kea processes.
# prefix holds the location where the Kea is installed.
prefix=@prefix@
# Location of Kea configuration file.
kea_dhcp4_config_file=@sysconfdir@/@PACKAGE@/kea-dhcp4.conf
kea_dhcp6_config_file=@sysconfdir@/@PACKAGE@/kea-dhcp6.conf
kea_dhcp_ddns_config_file=@sysconfdir@/@PACKAGE@/kea-dhcp-ddns.conf
kea_netconf_config_file=@sysconfdir@/@PACKAGE@/kea-netconf.conf
# Location of Kea binaries.
exec_prefix=@exec_prefix@
dhcp4_srv=@sbindir@/kea-dhcp4
dhcp6_srv=@sbindir@/kea-dhcp6
dhcp_ddns_srv=@sbindir@/kea-dhcp-ddns
netconf_srv=@sbindir@/kea-netconf
# Start DHCPv4 server?
dhcp4=yes
# Start DHCPv6 server?
dhcp6=yes
# Start DHCP DDNS server?
dhcp_ddns=no
# Start Netconf?
netconf=no
# Be verbose?
kea_verbose=no
168u
168u
نکته:
0.0
3.5
در مثال بالا، رشته‌هایی به شکل @something@ هنگام نصب Kea با مقادیر مناسب جایگزین می‌شوند.
168u
168u
تنظیم پارامترهای dhcp4، dhcp6، dhcp_ddns و netconf روی مقدار "yes"، ابزار keactrl <#std-iscman-keactrl> را برای مدیریت (راه‌اندازی، پیکربندی مجدد) تمام سرورها پیکربندی می‌کند، یعنی kea-dhcp4 <#std-iscman-kea-dhcp4>، kea-dhcp6 <#std-iscman-kea-dhcp6>، kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> و kea-netconf <#std-iscman-kea-netconf>. هنگامی که هر یک از این پارامترها روی "no" تنظیم شود، keactrl <#std-iscman-keactrl> سرور مربوطه را در هنگام راه‌اندازی یا پیکربندی مجدد Kea نادیده می‌گیرد. برخی دیمن‌ها (dhcp_ddns و netconf) به‌طور پیش‌فرض غیرفعال هستند.
به‌طور پیش‌فرض، سرورهای Kea که توسط keactrl <#std-iscman-keactrl> مدیریت می‌شوند در مسیر "[kea-install-dir]/sbin" قرار دارند. این مسیر برای بیشتر نصب‌ها مناسب است. اگر نیاز به تغییر مکان پیش‌فرض باشد، باید مسیرهای مشخص‌شده در پارامترهای dhcp4_srv، dhcp6_srv، dhcp_ddns_srv و netconf_srv ویرایش شوند.
پارامتر kea_verbose میزان پرگویی گزارش‌ها را برای سرورهای در حال راه‌اندازی مشخص می‌کند. هنگامی که kea_verbose روی yes تنظیم شود، سطح گزارش‌گیری سرور روی DEBUG قرار می‌گیرد. تغییر سطح اهمیت گزارش‌گیری در فایل پیکربندی، همان‌طور که در Logging <#logging> شرح داده شده است، تا زمانی که kea_verbose روی "yes" تنظیم باشد هیچ اثری نخواهد داشت. تنظیم آن روی "no" باعث می‌شود سرور از سطوح گزارش‌گیری مشخص‌شده در فایل پیکربندی Kea استفاده کند. اگر هیچ پیکربندی برای گزارش‌گیری تعیین نشده باشد، تنظیمات پیش‌فرض به کار گرفته می‌شوند.
نکته:
0.0
3.5
میزان پرگویی گزارش‌ها هنگام راه‌اندازی سرور تنظیم می‌شود. پس از راه‌اندازی، این میزان تنها با متوقف کردن سرور و اجرای مجدد آن با مقدار جدید پارامتر kea_verbose قابل تغییر است.
168u
دستورهای زیر توسط keactrl <#std-iscman-keactrl> پشتیبانی می‌شوند:
0.0
• 2
start - سرورهای انتخاب‌شده را راه‌اندازی می‌کند.
• 2
stop - تمام سرورهای در حال اجرا را متوقف می‌کند.
• 2
reload - با ارسال سیگنال SIGHUP به سرورهای انتخاب‌شده، پیکربندی مجدد آن‌ها را فعال می‌کند.
• 2
status - وضعیت سرورها (فعال یا غیرفعال) و نام فایل‌های پیکربندی در حال استفاده را بازمی‌گرداند.
• 2
version - نسخه خود ابزار keactrl <#std-iscman-keactrl> را به همراه نسخه دیمن‌های Kea چاپ می‌کند.
168u
خروجی معمول keactrl <#std-iscman-keactrl> هنگام راه‌اندازی سرورها شبیه به مورد زیر است:
0.0
3.5
$ keactrl start
INFO/keactrl: Starting kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf -d
INFO/keactrl: Starting kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf -d
INFO/keactrl: Starting kea-dhcp-ddns -c /usr/local/etc/kea/kea-dhcp-ddns.conf -d
INFO/keactrl: Starting kea-netconf -c /usr/local/etc/kea/kea-netconf.conf -d
168u
168u
سرورهای Kea هنگام راه‌اندازی، فایل‌های PID ایجاد می‌کنند. این فایل‌ها توسط
keactrl <#std-iscman-keactrl> برای تعیین اینکه آیا یک سرور مشخص در حال اجرا است یا خیر استفاده می‌شوند. اگر هنگام اجرای دستور start، یک یا چند
سرور در حال اجرا باشند، خروجی مشابه زیر خواهد بود:
0.0
3.5
$ keactrl start
INFO/keactrl: kea-dhcp4 appears to be running, see: PID 10918, PID file: /usr/local/var/run/kea/kea.kea-dhcp4.pid.
INFO/keactrl: kea-dhcp6 appears to be running, see: PID 10924, PID file: /usr/local/var/run/kea/kea.kea-dhcp6.pid.
INFO/keactrl: kea-dhcp-ddns appears to be running, see: PID 10930, PID file: /usr/local/var/run/kea/kea.kea-dhcp-ddns.pid.
INFO/keactrl: kea-netconf appears to be running, see: PID 10123, PID file: /usr/local/var/run/kea/kea.kea-netconf.pid.
168u
168u
در طول خاموش شدن‌های عادی، این فایل‌های PID حذف می‌شوند؛ با این حال، ممکن است
پس از فروپاشی سیستم (crash) به عنوان بقایا باقی بمانند. این امکان وجود دارد،
اگرچه بسیار بعید است، که پس از راه‌اندازی مجدد سیستم، PIDهایی که این فایل‌ها شامل می‌شوند در واقع به فرآیندهای نامرتبط با Kea اشاره کنند. این وضعیت
باعث می‌شود keactrl <#std-iscman-keactrl> تشخیص دهد که سرورها در حال اجرا هستند، در حالی که در واقعیت این‌گونه
نیست. در چنین مواردی فایل‌های PID فهرست‌شده در خروجی keactrl <#std-iscman-keactrl>
باید به صورت دستی حذف شوند.
دستور زیر تمام سرورها را متوقف می‌کند:
0.0
3.5
$ keactrl stop
INFO/keactrl: Stopping kea-dhcp4...
INFO/keactrl: Stopping kea-dhcp6...
INFO/keactrl: Stopping kea-dhcp-ddns...
INFO/keactrl: Stopping kea-netconf...
168u
168u
توجه داشته باشید که دستور stop تلاش می‌کند تمام سرورها را صرف‌نظر از اینکه
در keactrl.conf "فعال" (enabled) شده‌اند یا خیر متوقف کند. اگر هر یک
از سرورها در حال اجرا نباشند، یک پیام اطلاعاتی مانند خروجی دستور stop در زیر نمایش داده می‌شود.
0.0
3.5
$ keactrl stop
INFO/keactrl: kea-dhcp4 isn't running.
INFO/keactrl: kea-dhcp6 isn't running.
INFO/keactrl: kea-dhcp-ddns isn't running.
INFO/keactrl: kea-netconf isn't running.
168u
168u
همان‌طور که پیش‌تر اشاره شد، پیکربندی مجدد هر سرور Kea با
سیگنال SIGHUP آغاز می‌شود. دستور reload سیگنال SIGHUP را
به هر سروری که در فایل پیکربندی keactrl <#std-iscman-keactrl> فعال شده باشد
و در حال حاضر در حال اجرا باشد ارسال می‌کند. هنگامی که یک سرور سیگنال SIGHUP را دریافت می‌کند،
فایل پیکربندی خود را دوباره می‌خواند و در صورتی که پیکربندی جدید معتبر باشد،
از پیکربندی جدید استفاده می‌کند.
اگر پیکربندی جدید نامعتبر باشد، سرور پیکربندی فعلی خود را حفظ می‌کند؛
با این حال، در برخی موارد یک پیام خطای مهلک ثبت می‌شود که نشان می‌دهد سرور
دیگر هیچ سرویسی ارائه نمی‌دهد: در این حالت یک پیکربندی سالم باید در اسرع وقت بارگذاری شود.
یک بارگذاری مجدد به صورت زیر اجرا می‌شود:
0.0
3.5
$ keactrl reload
INFO/keactrl: Reloading kea-dhcp4...
INFO/keactrl: Reloading kea-dhcp6...
INFO/keactrl: Reloading kea-dhcp-ddns...
168u
168u
اگر هر یک از سرورها در حال اجرا نباشند، یک پیام اطلاعاتی مانند
خروجی دستور reload در زیر نمایش داده می‌شود.
kea-netconf <#std-iscman-kea-netconf> از سیگنال SIGHUP پشتیبانی نمی‌کند. در صورتی
که پیکربندی آن تغییر کرده است، لطفاً آن را متوقف کرده و مجدداً راه‌اندازی کنید تا تغییرات
اعمال شوند.
0.0
3.5
$ keactrl stop
INFO/keactrl: kea-dhcp4 isn't running.
INFO/keactrl: kea-dhcp6 isn't running.
INFO/keactrl: kea-dhcp-ddns isn't running.
INFO/keactrl: kea-netconf isn't running.
168u
168u
نکته:
0.0
3.5
ویژگی NETCONF یک قابلیت اختیاری است که به صورت پیش‌فرض غیرفعال است و می‌تواند
در زمان کامپایل فعال شود. اگر Kea بدون پشتیبانی از NETCONF کامپایل شده باشد،
keactrl <#std-iscman-keactrl> اطلاعاتی درباره آن ارائه نمی‌دهد. ورودی‌های NETCONF
همچنان در فایل keactrl.conf موجود هستند، اما وضعیت NETCONF نمایش داده نمی‌شود و
سایر دستورها آن را نادیده می‌گیرند.
168u
168u
نکته:
0.0
3.5
در حال حاضر keactrl <#std-iscman-keactrl> در هنگام راه‌اندازی یا پیکربندی مجدد سرور،
خطاهای پیکربندی را گزارش نمی‌کند. برای بررسی اینکه آیا پیکربندی سرور موفقیت‌آمیز بوده است یا خیر،
لاگ Kea باید برای یافتن خطاها بررسی شود. به صورت پیش‌فرض، لاگ‌ها در فایل syslog
نوشته می‌شوند.
168u
168u
گاهی اوقات بررسی اینکه کدام سرورها در حال اجرا هستند مفید است.
دستور status این موضوع را گزارش می‌دهد و خروجی نمونه آن به صورت زیر است:
0.0
3.5
$ keactrl status
DHCPv4 server: active
DHCPv6 server: inactive
DHCP DDNS: active
Netconf agent: inactive
Kea configuration file: /usr/local/etc/kea/kea.conf
Kea DHCPv4 configuration file: /usr/local/etc/kea/kea-dhcp4.conf
Kea DHCPv6 configuration file: /usr/local/etc/kea/kea-dhcp6.conf
Kea DHCP DDNS configuration file: /usr/local/etc/kea/kea-dhcp-ddns.conf
Kea Netconf configuration file: /usr/local/etc/kea/kea-netconf.conf
keactrl configuration file: /usr/local/etc/kea/keactrl.conf
168u
168u
دستور keactrl status قابلیت‌های گزارش‌دهی پایه‌ای را ارائه می‌دهد. برای به دست آوردن دیدگاه جامع‌تر
نسبت به سلامت و وضعیت Kea، استقرار Stork را مد نظر قرار دهید. برای اطلاعات بیشتر، به Monitoring Kea With Stork <#stork> مراجعه کنید..SS "بازنویسی انتخاب سرور (Overriding the Server Selection)"
گزینه اختیاری -s امکان انتخاب سرور(هایی) را فراهم می‌کند که دستور keactrl <#std-iscman-keactrl> برای آن‌ها صادر می‌شود. برای نمونه، دستور زیر به keactrl <#std-iscman-keactrl> اعلام می‌کند که سرورهای kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> را متوقف کرده و اجازه دهد kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> در حال اجرا باقی بماند:
0.0
3.5
$ keactrl stop -s dhcp4,dhcp6
168u
168u
به‌طور مشابه، دستور زیر تنها سرورهای kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> را اجرا می‌کند، اما نه kea-dhcp6 <#std-iscman-kea-dhcp6>.
0.0
3.5
$ keactrl start -s dhcp4,dhcp_ddns
168u
168u
توجه داشته باشید که رفتار گزینه -s در دستورهای start و reload با رفتار آن در دستور stop متفاوت است. در دستورهای start و reload، برنامه keactrl <#std-iscman-keactrl> بررسی می‌کند که آیا سرورهای ارائه‌شده به عنوان پارامتر به گزینه -s در فایل پیکربندی keactrl <#std-iscman-keactrl> فعال شده‌اند یا خیر؛ در غیر این صورت، سرور نادیده گرفته می‌شود. اما برای stop، این بررسی انجام نمی‌شود؛ دستور بدون در نظر گرفتن اینکه سرورها در فایل فعال شده باشند یا خیر، بر روی تمام سرورهای فهرست‌شده اعمال می‌گردد.
کلیدواژه‌های زیر می‌توانند با گزینه خط فرمان -s استفاده شوند:
0.0
• 2
dhcp4 برای kea-dhcp4 <#std-iscman-kea-dhcp4>.
• 2
dhcp6 برای kea-dhcp6 <#std-iscman-kea-dhcp6>.
• 2
dhcp_ddns برای kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>.
• 2
netconf برای kea-netconf <#std-iscman-kea-netconf>.
• 2
all برای همه سرورها (پیش‌فرض).
168u
"بسته‌های بومی و systemd (Native Packages and systemd)"
اسکریپت keactrl <#std-iscman-keactrl> برای کمک به مدیریت فرایندهای Kea توسعه یافته است.
با این حال، تمامی سیستم‌عامل‌های امروزی اسکریپت‌های مدیریت فرایند اختصاصی خود را دارند،
مانند systemd. به‌طور کلی، توصیه می‌شود از این اسکریپت‌های بومی استفاده شود،
زیرا دارای چندین مزیت هستند. اسکریپت‌های systemd فرایندها را به روشی یکپارچه
مدیریت می‌کنند، بنابراین با Kea مشابه با یک سرور HTTP یا سرور ایمیل
رفتار می‌شود. دوم و مهم‌تر از آن، systemd امکان تعریف وابستگی‌ها بین سرویس‌ها را
فراهم می‌کند. برای نمونه، به‌راحتی می‌توان مشخص کرد که سرور Kea تا زمانی که رابط‌های
شبکه عملیاتی نشده‌اند شروع به کار نکند. استفاده از اسکریپت‌های بومی مزایای دیگری نیز دارد، مانند
امکان فعال‌سازی یا غیرفعال‌سازی سرویس‌ها با استفاده از دستورها، و قابلیت اجرای موقت یک
سرویس غیرفعال‌شده.
بنابراین، توصیه می‌شود در صورت دردسترس بودن، از دستورهای systemctl استفاده شود. بسته‌های
بومی Kea اسکریپت keactrl <#std-iscman-keactrl> را ارائه نمی‌دهند؛ در عوض تعاریف سرویس systemctl
ارائه شده‌اند. برای جزئیات به مستندات سیستم مراجعه کنید.
به‌طور خلاصه، در اینجا نمونه دستورهایی برای بررسی وضعیت، آغاز، توقف، و راه‌اندازی دوباره دیمن‌های مختلف Kea آورده شده است:
0.0
3.5
# systemctl start kea-dhcp4
# systemctl stop kea-dhcp6
# systemctl restart kea-dhcp-ddns
168u
168u
توجه داشته باشید که نام سرویس‌ها ممکن است در توزیع‌های مختلف لینوکس کمی تفاوت داشته باشد؛ به‌طور کلی،
ما از قواعد نام‌گذاری بسته‌های شخص ثالث پیروی کرده‌ایم. به‌ویژه،
ممکن است در برخی سیستم‌ها پیشوند isc- وجود نداشته باشد.
"سرور DHCPV4 (THE DHCPV4 SERVER)"
"راه‌اندازی و توقف سرور DHCPv4 (Starting and Stopping the DHCPv4 Server)"
توصیه می‌شود که سرور Kea DHCPv4 با استفاده از keactrl <#std-iscman-keactrl> آغاز و متوقف
شود (که در «مدیریت Kea با keactrl» <#keactrl> توضیح داده شده است)؛ با این حال، اجرای
مستقیم سرور از طریق دستور kea-dhcp4 <#std-iscman-kea-dhcp4> نیز امکان‌پذیر است، که
سوئیچ‌های خط فرمان زیر را می‌پذیرد:
0.0
• 2
-c file - فایل پیکربندی را مشخص می‌کند. این تنها
سوئیچ اجباری است.
• 2
-d - مشخص می‌کند که آیا ثبت وقایع سرور باید به حالت اشکال‌زدایی/پُرگویی
تغییر یابد یا خیر. در حالت پرگویی، سطح شدت ثبت وقایع و debuglevel
تعیین‌شده در فایل پیکربندی نادیده گرفته می‌شوند؛ شدت "debug"
و بیشترین debuglevel (عدد 99) فرض می‌شوند. این پرچم برای
تغییر موقت سرور به حداکثر سطح گزارش‌دهی، مثلاً هنگام اشکال‌زدایی،
مناسب است.
• 2
-p server-port - پورت محلی UDP را که سرور روی آن
گوش می‌دهد مشخص می‌کند. این گزینه فقط در حین آزمایش مفید است، زیرا یک سرور DHCPv4
که روی پورت‌هایی غیر از پورت‌های استاندارد گوش می‌دهد، قادر به
پردازش پرس‌وجوهای معمول DHCPv4 نخواهد بود.
• 2
-P client-port - پورت دوردست UDP را مشخص می‌کند که
سرور تمام پاسخ‌ها را به آن ارسال می‌کند. این گزینه تنها در حین آزمایش کاربرد دارد،
زیرا یک سرور DHCPv4 که پاسخ‌ها را به پورت‌هایی غیر از پورت‌های استاندارد
ارسال می‌کند، قادر به مدیریت پرس‌وجوهای معمول DHCPv4 نخواهد بود.
• 2
-t file - یک فایل پیکربندی را برای آزمایش مشخص می‌کند. kea-dhcp4 <#std-iscman-kea-dhcp4>
آن را بارگذاری کرده، صحت آن را بررسی نموده و خارج می‌شود. در حین آزمایش، پیام‌های گزارش
در خروجی استاندارد و پیام‌های خطا در خطای استاندارد چاپ می‌شوند. نتیجه
آزمایش از طریق وضعیت خروج گزارش می‌شود (0 = پیکربندی
درست به نظر می‌رسد، 1 = خطا رخ داده است). این بررسی
جامع نیست؛ بررسی‌های مشخصی تنها هنگام اجرای زنده
سرور امکان‌پذیر هستند.
• 2
-T file - یک فایل پیکربندی را برای آزمایش مشخص می‌کند. kea-dhcp4 <#std-iscman-kea-dhcp4>
آن را بارگذاری کرده، بررسی می‌کند و خارج می‌شود. این گزینه بررسی‌های بیشتری فراتر از آنچه -t
ارائه می‌دهد انجام می‌دهد، مانند برقراری اتصال‌های پایگاه‌داده (برای lease backend،
پیشانه host reservations، پیشانه configuration و پیشانه forensic logging)،
بارگذاری کتابخانه‌های قلاب (hook)، تجزیه پیکربندی‌های کتابخانه قلاب و غیره.
این گزینه سوکت‌های UNIX یا TCP/UDP را باز نمی‌کند، فایل‌ها را قفل نمی‌کند، و همچنین فایل‌ها را باز نکرده
یا دوره‌ای جایگزین (rotate) نمی‌کند، چرا که هرکدام از این اقدامات می‌تواند با یک فرایند در حال اجرا روی همان
ماشین تداخل داشته باشد.
• 2
-v - نسخه Kea را نمایش داده و خارج می‌شود.
• 2
-V - نسخه تفصیلی Kea را به همراه پارامترهای اضافی نمایش
داده و خارج می‌شود. این فهرست شامل نسخه‌های کتابخانه‌هایی است که
به‌طور پویا با Kea پیوند خورده‌اند.
• 2
-W - گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش
رونوشتی از فایل config.report است که توسط meson setup تولید شده؛
این گزارش در فایل اجرایی باینری تعبیه شده است.
محتویات فایل config.report را همچنین می‌توان با بررسی
برخی کتابخانه‌ها در درخت نصب یا در درخت کد منبع به دست آورد.
2.0
3.5
# from installation using libkea-process.so
$ strings ${prefix}/lib/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.so
$ strings src/lib/process/.libs/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.a
$ strings src/lib/process/.libs/libkea-process.a | sed -n 's/;;;; //p'
# from sources using libcfgrpt.a
$ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed -n 's/;;;; //p'
168u
168u
• 2
-X - از نسخه Kea 3.0 به بعد، محدودیت‌های امنیتی را غیرفعال می‌کند. سرور همچنان
موارد نقض را بررسی می‌کند، اما در صورت یافتن آن‌ها به جای متوقف شدن با خطا، هشدارهایی
صادر خواهد کرد. لطفاً برای جزئیات به
«بررسی خط‌مشی امنیتی زمان اجرای Kea» <#sec-kea-runtime-security-policy-checking> مراجعه کنید.
168u
هنگام راه‌اندازی، سرور رابط‌های شبکه موجود را شناسایی کرده و
تلاش می‌کند سوکت‌های UDP را روی تمام رابط‌های فهرست‌شده در
فایل پیکربندی باز کند. از آنجا که سرور DHCPv4 پورت‌های ممتاز (privileged) را باز می‌کند،
به دسترسی ریشه (root) نیاز دارد؛ این دیمن باید توسط کاربر ریشه اجرا شود.
در طول راه‌اندازی، سرور تلاش می‌کند یک فایل PID به فرم
[pidfile_dir]/[conf name].kea-dhcp4.pid ایجاد کند که در آن:
0.0
• 2
pidfile_dir - برابر است با [prefix]/[localstatedir]/run/kea که در آن
prefix و localstatedir مقادیری هستند که با استفاده از --prefix و
--localstatedir به meson setup منتقل شده‌اند و به‌طور پیش‌فرض به ترتیب /usr/local و
var هستند. بنابراین کل مسیر pidfile_dir به‌طور پیش‌فرض برابر با
/usr/local/var است. توجه داشته باشید که این مقدار ممکن است در زمان اجرا با
تنظیم متغیر محیطی KEA_PIDFILE_DIR که اساساً برای اهداف
آزمایشی در نظر گرفته شده، بازنویسی شود.
• 2
conf name: نام فایل پیکربندی که برای راه‌اندازی سرور استفاده شده است،
بدون تمام مسیرهای قبل از آن و پسوند فایل. برای مثال، به ازای
یک نام مسیر مانند /usr/local/etc/kea/myconf.txt، بخش استفاده‌شده
myconf خواهد بود.
168u
اگر این فایل از قبل وجود داشته باشد و شامل PID یک فرایند در حال اجرا باشد،
سرور یک پیام گزارش DHCP4_ALREADY_RUNNING صادر کرده و خارج می‌شود. این
احتمال وجود دارد، هرچند بعید، که فایل باقی‌مانده از یک فروپاشی سیستم (system crash)
باشد و فرایندی که PID متعلق به آن است ارتباطی به Kea نداشته باشد. در چنین
حالتی، حذف دستی فایل PID ضروری خواهد بود.
سرور را می‌توان با استفاده از دستور kill متوقف کرد. هنگام اجرا در یک
کنسول، سرور همچنین می‌تواند با فشردن Ctrl-c متوقف شود. Kea این
ترکیب کلید را شناسایی کرده و به‌صورت روان و تمیز خاموش می‌شود.
پیکربندی مجدد هر سرور Kea با دریافت سیگنال SIGHUP آغاز می‌شود.
هنگامی که یک سرور سیگنال SIGHUP را دریافت می‌کند، فایل پیکربندی خود را دوباره می‌خواند و
اگر پیکربندی جدید معتبر باشد، از آن استفاده می‌کند.
چنانچه مشخص شود پیکربندی جدید نامعتبر است، سرور پیکربندی
فعلی خود را حفظ می‌کند؛ با این حال، در برخی موارد یک پیام خطای مهلک ثبت می‌شود
که نشان می‌دهد سرور دیگر هیچ سرویسی ارائه نمی‌دهد: در این صورت باید یک
پیکربندی سالم در اسرع وقت بارگذاری شود..SS پیکربندی سرور DHCPv4
مقدمه
این بخش نحوهٔ پیکربندی سرور DHCPv4 مربوط به Kea را با استفاده از یک فایل
پیکربندی شرح می‌دهد.
پیش از راه‌اندازی DHCPv4، باید فایل پیکربندی آن ایجاد
شود. پیکربندی پایه به شرح زیر است:
0.0
3.5
{
# DHCPv4 configuration starts on the next line
"Dhcp4": {
# First we set up global values
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
# Next we set up the interfaces to be used by the server.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
# And we specify the type of lease database
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases"
},
# Finally, we list the subnets from which we will be leasing addresses.
"subnet4": [
{
"id": 1,
"subnet": "192.0.2.0/24",
"pools": [
{
"pool": "192.0.2.1 - 192.0.2.200"
}
]
}
]
# DHCPv4 configuration ends with the next line
}
}
168u
168u
بندهای زیر پیش‌نمایشی اجمالی از پارامترهای موجود در مثال بالا به همراه
قالب آن‌ها ارائه می‌دهند. بخش‌های بعدی این فصل، این پارامترها و پارامترهای دیگر را با
جزئیات بسیار بیشتری بررسی می‌کنند.
خطوطی که با هش (#) آغاز می‌شوند، توضیح (کامنت) هستند و سرور آن‌ها را
نادیده می‌گیرد؛ آن‌ها به هیچ شکلی بر عملکرد آن اثر نمی‌گذارند.
پیکربندی در خط نخست با براکت مجعد بازشوندهٔ اولیه (یا آکولاد باز) شروع می‌شود. هر
پیکربندی باید شامل شیئی باشد که پیکربندی ماژول Kea به‌کارگیرندهٔ آن را مشخص
کند. در مثال بالا، این شیء Dhcp4 نام دارد.
پیکربندی Dhcp4 با خط "Dhcp4": { آغاز شده و با آکولاد بستهٔ
متناظر آن (در مثال بالا، آکولاد پس از آخرین توضیح) به پایان می‌رسد. هر آنچه میان
این خطوط تعریف شده باشد، پیکربندی Dhcp4 به شمار می‌آید.
به‌طور کلی، ترتیبی که این پارامترها درج می‌شوند اهمیتی ندارد،
اما دو نکته وجود دارد. نکتهٔ نخست این است که فایل
پیکربندی باید یک JSON خوش‌ساخت (well-formed) باشد؛ بدین معنا که پارامترها برای
هر حوزهٔ (scope) معین باید با کاما از هم جدا شوند، و نباید بعد از آخرین پارامتر کامایی
قرار گیرد. هنگام مرتب‌سازی مجدد یک فایل پیکربندی، انتقال یک پارامتر به آخرین جایگاه
در یک حوزه یا خارج کردن آن از آخرین جایگاه ممکن است نیازمند جابه‌جایی کاما نیز باشد.
نکتهٔ دوم این است که تکرار چندین‌بارهٔ یک پارامتر، گرچه در ساختار JSON مجاز است،
اما نامعمول می‌باشد. در صورت وقوع این اتفاق، آخرین تکرار یک پارامتر معین در یک حوزهٔ
خاص استفاده می‌شود، در حالی که تمامی موارد پیشین نادیده گرفته می‌شوند. بعید است
این موضوع سبب سردرگمی شود، چرا که در عمل هیچ دلیلی برای نگهداری چندین نسخه از
یک پارامتر یکسان در فایل پیکربندی وجود ندارد.
چند مؤلفهٔ نخست پیکربندی DHCPv4 برخی پارامترهای سراسری (global) را
تعریف می‌کنند. valid-lifetime تعیین می‌کند نشانی‌های (اجاره‌های) واگذارشده
توسط سرور تا چه مدت معتبر هستند؛ حالت پیش‌فرض این است که یک کلاینت مجاز
باشد از یک نشانی مشخص برای ۴۰۰۰ ثانیه استفاده کند. (توجه داشته باشید که اعداد صحیح به همان
صورت، بدون هیچ‌گونه گیومه در اطرافشان، مشخص می‌شوند.) renew-timer و rebind-timer
مقادیری (همچنین به ثانیه) هستند که زمان‌سنج‌های T1 و T2 را تعریف می‌کنند؛ این زمان‌سنج‌ها
زمان آغاز فرایندهای تمدید (renewal) و اتصال مجدد (rebind) توسط کلاینت را کنترل می‌کنند.
نکته:
0.0
3.5
طول‌عمر معتبر اجاره به‌صورت یک سه‌تایی با مقادیر کمینه، پیش‌فرض، و
بیشینه با استفاده از مدخل‌های پیکربندی
min-valid-lifetime، valid-lifetime و max-valid-lifetime بیان می‌شود.
از نسخهٔ Kea 1.9.5 به بعد، این مقادیر می‌توانند در کلاس‌های کلاینت مشخص شوند. روالی
که سرور برای انتخاب مقدار طول‌عمر مورد استفاده به کار می‌برد به شرح زیر است:
اگر پرس‌وجوی کلاینت یک پرس‌وجوی BOOTP باشد، سرور همواره از زمان اجارهٔ
نامحدود (مانند 0xffffffff) استفاده می‌کند. در غیر این صورت، سرور باید با جستجو
در تمامی کلاس‌های اختصاص‌یافته به پرس‌وجو و سپس زیرشبکهٔ انتخاب‌شده برای
پرس‌وجو، تعیین کند کدام سه‌تاییِ پیکربندی‌شده باید استفاده شود.
کلاس‌ها به همان ترتیبی که به پرس‌وجو اختصاص یافته‌اند جستجو می‌شوند؛ سرور
از سه‌تاییِ نخستین کلاسی که آن را مشخص کرده باشد استفاده می‌کند.
اگر هیچ کلاسی این سه‌تایی را مشخص نکرده باشد، سرور از سه‌تایی مشخص‌شده
توسط زیرشبکهٔ انتخاب‌شده برای کلاینت استفاده می‌کند. اگر زیرشبکه صراحتاً
آن را مشخص نکرده باشد، سرور در مرحلهٔ بعد shared-network مربوط به
زیرشبکه را (در صورت وجود) بررسی می‌کند، سپس به دنبال مشخصهٔ سراسری می‌گردد، و
در نهایت مقدار پیش‌فرض سراسری را به کار می‌گیرد.
اگر کلاینت مقدار طول‌عمری را از طریق DHCP option 51 درخواست کرده باشد، آن‌گاه
مقدار طول‌عمر استفاده‌شده همان مقدار درخواستی خواهد بود که توسط سه‌تاییِ
پیکربندی‌شده محدود می‌شود. به عبارت دیگر، اگر طول‌عمر درخواستی کمتر از کمینهٔ
پیکربندی‌شده باشد، کمینهٔ پیکربندی‌شده استفاده می‌شود؛ اگر بیشتر از بیشینهٔ
پیکربندی‌شده باشد، بیشینهٔ پیکربندی‌شده به کار می‌رود. اگر کلاینت مقداری را
درخواست نکرده باشد، مقدار طول‌عمر استفاده‌شده، مقدار پیش‌فرض سه‌تایی خواهد بود.
168u
168u
نکته:
0.0
3.5
هر دو پارامتر renew-timer و rebind-timer
اختیاری هستند. سرور تنها در صورتی rebind-timer را از طریق DHCPv4 option code 59 به کلاینت
ارسال می‌کند که کمتر از valid-lifetime باشد؛ و تنها در صورتی renew-timer را از طریق
DHCPv4 option code 58 ارسال می‌کند که کمتر از rebind-timer باشد
(یا کمتر از valid-lifetime اگر rebind-timer مشخص نشده باشد). در غیاب آن‌ها، کلاینت باید مقادیر
زمان‌سنج‌های T1 و T2 را بر اساس RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131 انتخاب کند.
برای جزئیات بیشتر در مورد تولید T1 و T2، به بخش Sending T1 (Option 58) and T2 (Option 59)
مراجعه کنید.
168u
168u
نگاشت interfaces-config رابط‌های شبکه‌ای را مشخص می‌کند که سرور
باید روی آن‌ها به پیام‌های DHCP گوش دهد. پارامتر interfaces
فهرستی از رابط‌های شبکه را که سرور باید روی آن‌ها شنود کند مشخص می‌سازد. فهرست‌ها
با براکت‌های مربعی (قلاب) باز و بسته می‌شوند و عناصر با کاما از هم جدا می‌گردند. برای
شنود روی دو رابط، عنصر interfaces-config باید بدین صورت باشد:
0.0
3.5
{
"interfaces-config": {
"interfaces": [ "eth0", "eth1" ]
},
...
}
168u
168u
خطوط بعدی پایگاه‌دادهٔ اجاره (lease database) را تعریف می‌کنند؛ محلی که
سرور اطلاعات اجاره‌های خود را در آن ذخیره می‌کند. این مثال ویژه به
سرور دستور می‌دهد از memfile استفاده کند که ساده‌ترین و سریع‌ترین backend پایگاه‌داده
است. این بک‌اند از یک پایگاه‌داده در حافظه (in-memory) استفاده کرده و اجاره‌ها را روی دیسک
در یک فایل CSV (مقادیر جداشده با کاما) ذخیره می‌کند. این یک مثال پیکربندی بسیار ساده
است؛ معمولاً پیکربندی پایگاه‌دادهٔ اجاره جامع‌تر بوده و دربردارندهٔ
پارامترهای اضافی است. توجه داشته باشید که lease-database یک شیء است و یک حوزهٔ
جدید را با استفاده از یک آکولاد باز آغاز می‌کند. پارامترهای آن (در این مثال تنها یک مورد:
type) در ادامه می‌آیند. اگر بیش از یکی وجود داشت، با کاما از هم
جدا می‌شدند. این حوزه با یک آکولاد بسته خاتمه می‌یابد. از آنجا که پارامترهای
بیشتری برای تعریف Dhcp4 به دنبال آن می‌آیند، یک کامای پایانی وجود دارد.
در نهایت، باید فهرستی از زیرشبکه‌های IPv4 را تعریف کنیم. این مهم‌ترین
ساختار پیکربندی DHCPv4 است، چرا که سرور از این اطلاعات برای
پردازش درخواست‌های کلاینت‌ها استفاده می‌کند. این ساختار تمام زیرشبکه‌هایی را که
انتظار می‌رود سرور درخواست‌های DHCP را از آن‌ها دریافت کند، تعریف می‌کند. زیرشبکه‌ها
با پارامتر subnet4 مشخص می‌شوند. این پارامتر یک فهرست است، بنابراین با
براکت‌های مربعی باز و بسته می‌شود. هر تعریف زیرشبکه در فهرست، دارای
چندین مشخصهٔ مرتبط با خود است، بنابراین یک ساختار بوده و با
آکولاد باز و بسته می‌شود. در کمترین حالت، یک تعریف زیرشبکه باید دست‌کم
دو پارامتر داشته باشد: subnet، که کل زیرشبکه را تعریف می‌کند؛ و
pools، که فهرستی از استخرهای تخصیص‌پذیر پویا (dynamically allocated pools) تحت
مدیریت سرور DHCP است.
این مثال شامل یک زیرشبکهٔ منفرد است. اگر بیش از یک مورد تعریف می‌شد،
عناصر اضافی در پارامتر subnet4 مشخص شده و با کاما از هم جدا می‌شدند.
برای نمونه، جهت تعریف سه زیرشبکه، از نحو (syntax) زیر استفاده می‌شد:
0.0
3.5
{
"subnet4": [
{
"id": 1,
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24"
},
{
"id": 2,
"pools": [ { "pool": "192.0.3.100 - 192.0.3.200" } ],
"subnet": "192.0.3.0/24"
},
{
"id": 3,
"pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ],
"subnet": "192.0.4.0/24"
}
],
...
}
168u
168u
توجه داشته باشید که تورفتگی اختیاری است و صرفاً برای خوانایی
و زیبایی به کار می‌رود. در برخی موارد ممکن است ترجیح داده شود از نشانه‌گذاری فشرده‌تری استفاده گردد.
پس از اینکه تمام پارامترها مشخص شدند، دو زمینه (context) باز وجود دارد:
global و Dhcp4؛ از این رو، باید از دو براکت مجعد بسته (آکولاد بسته) برای بستن
آن‌ها استفاده شود..SS "ذخیره‌سازی اجاره‌ها (Lease Storage)"
همهٔ اجاره‌های صادرشده توسط سرور در پایگاه دادهٔ اجاره ذخیره می‌شوند.
سه بک‌اند پایگاه داده در دسترس است: memfile
(پیش‌فرض)، MySQL و PostgreSQL.
"Memfile - ذخیره‌سازی پایه برای اجاره‌ها (Memfile - Basic Storage for Leases)"
سرور قادر است داده‌های اجاره را در مخازن مختلفی ذخیره کند. در استقرارهای
بزرگ‌تر ممکن است ذخیرهٔ اجاره‌ها در یک پایگاه داده ترجیح داده شود؛
بخش Lease Database Configuration این گزینه را شرح می‌دهد. با این حال، در
استقرارهای معمولی و کوچک‌تر، سرور اطلاعات اجاره را به جای پایگاه داده در
یک فایل CSV ذخیره می‌کند. استفاده از یک فایل برای ذخیره‌سازی علاوه بر اینکه
به مدیریت کمتری نیاز دارد، این مزیت را نیز دارد که
وابستگی به نرم‌افزارهای پایگاه دادهٔ شخص ثالث را از بین می‌برد.
پیکربندی بک‌اند memfile از طریق پارامترهای
Dhcp4/lease-database کنترل می‌شود. پارامتر type اجباری است
و از طریق مقدار "memfile" مشخص می‌کند که سرور باید از کدام فضای ذخیره‌سازی
برای اجاره‌ها استفاده کند. فهرست زیر پارامترهای اختیاری دیگری را ارائه می‌دهد
که می‌توان از آن‌ها برای پیکربندی بک‌اند memfile استفاده کرد.
0.0
• 2
persist: کنترل می‌کند که آیا اجاره‌های جدید و به‌روزرسانی‌های اجاره‌های موجود
روی فایل نوشته شوند یا خیر. اکیداً توصیه می‌شود مقدار این پارامتر در تمام
طول فعالیت عادی سرور همواره روی true تنظیم باشد. ننوشتن اجاره‌ها روی دیسک به این معناست
که اگر سرور مجدداً راه‌اندازی شود (مثلاً پس از قطع برق)، متوجه نخواهد شد
که چه آدرس‌هایی اختصاص داده شده‌اند. در نتیجه، ممکن است به کلاینت‌های جدید
آدرس‌هایی را تخصیص دهد که هم‌اکنون در حال استفاده هستند. مقدار
false عمدتاً برای اهداف آزمایش عملکرد مفید است. مقدار
پیش‌فرض پارامتر persist برابر با true است که فعال‌سازِ
نوشتن به‌روزرسانی‌های اجاره در فایل اجاره می‌باشد.
• 2
name: فایل اجاره‌ای را که اجاره‌های جدید و به‌روزرسانی‌های اجاره در آن
ثبت می‌شوند مشخص می‌کند. مقدار پیش‌فرض این پارامتر برابر است با:
"[kea-install-dir]/var/lib/kea/kea-leases4.csv".
168u
نکته:
0.0
3.5
از نسخهٔ Kea 2.7.9 به بعد، فایل‌های اجاره تنها می‌توانند از دایرکتوری داده‌ای که در
حین کامپایل مشخص شده است بارگذاری شوند: "[kea-install-dir]/var/lib/kea". این
مسیر را می‌توان در هنگام راه‌اندازی با تنظیم متغیر محیطی
KEA_DHCP_DATA_DIR روی مسیر مورد نظر بازنویسی (override) کرد. اگر مسیری به غیر از
این مقدار در name استفاده شود، Kea با صدور خطا از راه‌اندازی خودداری می‌کند،
یا در صورتی که در حال اجرا باشد، یک خطای غیرقابل‌بازیابی را ثبت خواهد کرد. جهت سهولت در
تعیین یک نام فایل سفارشی، کافی است بخش مسیر را از name حذف کنید.
168u
168u
0.0
• 2
lfc-interval: بازهٔ زمانی را بر حسب ثانیه مشخص می‌کند که سرور در آن،
پاک‌سازی فایل اجاره (LFC) را انجام می‌دهد. این عملیات اطلاعات
اضافی (تاریخچه‌ای) را از فایل اجاره حذف کرده و
به‌طور مؤثری حجم فایل اجاره را کاهش می‌دهد. فرایند پاک‌سازی
در ادامهٔ این بخش با جزئیات بیشتری توضیح داده شده است. مقدار پیش‌فرض
lfc-interval برابر با 3600 است. مقدار 0 قابلیت LFC را غیرفعال می‌کند.
• 2
max-row-errors: تعداد خطاهای ردیف را قبل از اینکه سرور از تلاش
برای بارگذاری فایل اجاره دست بکشد مشخص می‌کند. هنگامی که سرور یک فایل اجاره را بارگذاری می‌کند، آن را
ردیف به ردیف پردازش می‌نماید که هر ردیف حاوی یک اجاره است. اگر ردیفی معیوب باشد و
نتواند به درستی پردازش شود، سرور آن را لاگ کرده، ردیف را نادیده می‌گیرد
و به سراغ ردیف بعدی می‌رود. از این پارامتر می‌توان برای تعیین سقف مجاز بر روی
تعداد چنین ردیف‌های نادیده‌گرفته‌شده‌ای استفاده کرد، که پس از آن سرور تلاش را متوقف کرده و خارج می‌شود. مقدار پیش‌فرض
0 این محدودیت را غیرفعال می‌کند و به سرور اجازه می‌دهد بدون در نظر گرفتن تعداد
ردیف‌های نادیده‌گرفته‌شده، کل فایل را پردازش کند.
168u
یک نمونه از پیکربندی بک‌اند memfile در زیر ارائه شده است:
0.0
3.5
"Dhcp4": {
"lease-database": {
"type": "memfile",
"persist": true,
"name": "kea-leases4.csv",
"lfc-interval": 1800,
"max-row-errors": 100
}
}
168u
168u
این پیکربندی، فایل kea-leases4.csv را به عنوان فضای ذخیره‌سازی
اطلاعات اجاره انتخاب کرده و پایایی (نوشتن به‌روزرسانی‌های اجاره در این فایل) را
فعال می‌سازد. همچنین بک‌اند را به‌گونه‌ای تنظیم می‌کند که پاک‌سازی دوره‌ای فایل
اجاره را هر 1800 ثانیه (30 دقیقه) انجام دهد و حداکثر تعداد خطاهای ردیف
را روی 100 تعیین می‌نماید.
"چرا پاک‌سازی فایل اجاره ضروری است؟ (Why Is Lease File Cleanup Necessary?)"
برای درک اینکه چرا پاک‌سازی دوره‌ای فایل اجاره ضروری است، مهم است بدانیم که محتویات
فایل اجاره چگونه سازمان‌دهی می‌شوند. هر بار که سرور اجاره‌ای را به‌روزرسانی می‌کند یا
اجارهٔ جدیدی برای یک کلاینت ایجاد می‌نماید، اطلاعات اجارهٔ جدید باید در فایل اجاره ثبت شود.
سرور به دلایل کارایی و عملکرد، اجارهٔ موجود کلاینت را در فایل بازنویسی نمی‌کند، چرا که
این کار بالقوه نیازمند بازنویسی کل فایل است. در عوض، به سادگی اطلاعات اجارهٔ جدید را به انتهای
فایل اضافه (append) می‌کند؛ ورودی‌های قبلی اجاره برای آن کلاینت حذف نمی‌شوند. هنگامی
که سرور اجاره‌ها را از فایل اجاره بارگذاری می‌کند (مثلاً هنگام راه‌اندازی سرور)، فرض را بر این می‌گذارد
که آخرین ورودی اجاره برای کلاینت، ورودی معتبر است. ورودی‌های پیشین نادیده گرفته می‌شوند،
بدین معنی که سرور می‌تواند اطلاعات دقیقی دربارهٔ اجاره‌ها بازسازی کند، حتی اگر
ورودی‌های متعددی برای هر کلاینت وجود داشته باشد. با این حال، ذخیرهٔ ورودی‌های زیاد
برای هر کلاینت منجر به حجیم شدن بیش از حد فایل اجاره شده و به عملکرد راه‌اندازی و
بازپیکربندی سرور آسیب می‌زند، چرا که نیاز به پردازش تعداد بیشتری از ورودی‌های اجاره خواهد داشت.
پاک‌سازی فایل اجاره (LFC) تمام ورودی‌های پیشین مربوط به هر کلاینت را حذف کرده و
تنها آخرین ورودی‌ها را باقی می‌گذارد. بازه‌ای که پاک‌سازی در آن انجام می‌شود قابل‌پیکربندی است
و باید با توجه به بسامد تمدید اجاره توسط کلاینت‌ها انتخاب گردد. هرچه تمدیدها مکررتر
باشد، مقدار lfc-interval باید کوچک‌تر باشد. با این حال توجه داشته باشید که
عملیات LFC زمان‌بر است و بنابراین این احتمال (هرچند نامحتمل) وجود دارد که اگر lfc-interval
بیش از حد کوتاه باشد، یک پاک‌سازی جدید در حالی آغاز شود که پاک‌سازی پیشین هنوز در حال اجراست.
سرور با نادیده گرفتن پاک‌سازی جدید در هنگام تشخیص در جریان بودن پاک‌سازی قبلی، این وضعیت را
مدیریت می‌کند، اما این امر بدین معناست که پاک‌سازی‌های واقعی در فواصل طولانی‌تری نسبت به بازهٔ
پیکربندی‌شده انجام خواهند شد. علاوه بر این، راه‌اندازی یک پاک‌سازی جدید بار اضافی (overhead) بر سرور
تحمیل می‌کند، زیرا در بازهٔ زمانی کوتاهی که فرایند پاک‌سازی جدید ایجاد (spawn) می‌شود،
سرور قادر به پاسخگویی به درخواست‌های جدید نیست. بنابراین، توصیه می‌شود مقدار
lfc-interval به گونه‌ای انتخاب شود که به LFC اجازه دهد پیش از شروع یک پاک‌سازی جدید،
فرایند پاک‌سازی فعلی را تکمیل کند.
پاک‌سازی فایل اجاره توسط یک فرایند جداگانه (در پس‌زمینه) انجام می‌شود تا از تأثیر منفی
بر عملکرد فرایند اصلی سرور جلوگیری شود. برای جلوگیری از تداخل بین دو فرایند که از فایل‌های
اجارهٔ یکسانی استفاده می‌کنند، فرایند LFC با باز کردن یک فایل اجارهٔ جدید توسط Kea آغاز
می‌شود؛ فرایند واقعی LFC بر روی فایل اجاره‌ای عمل می‌کند که دیگر توسط سرور استفاده نمی‌شود.
همچنین فایل‌های دیگری نیز به عنوان اثر جانبی پاک‌سازی فایل اجاره ایجاد می‌شوند. شرح تفصیلی
فرایند LFC در بخش‌های بعدی این Kea Administrator's Reference Manual تحت عنوان
The LFC Process <#kea-lfc> آمده است..SS پیکربندی پایگاه‌داده اجاره‌ها (Lease Database Configuration)
نکته:
0.0
3.5
اطلاعات دسترسی به پایگاه‌داده اجاره‌ها باید برای کارساز DHCPv4 پیکربندی شود، حتی اگر پیش‌تر برای کارساز DHCPv6 پیکربندی شده باشد. کارسازها اطلاعات خود را به‌طور مستقل ذخیره می‌کنند، بنابراین هر کارساز می‌تواند از یک پایگاه‌داده جداگانه استفاده کند یا هر دو کارساز می‌توانند از یک پایگاه‌داده یکسان استفاده نمایند.
168u
168u
نکته:
0.0
3.5
برنامه Kea نیازمند آن است که منطقه زمانی (timezone) پایگاه‌داده با منطقه زمانی سیستم مطابقت داشته باشد. برای جزئیات بیشتر، First-Time Creation of the MySQL Database <#mysql-database-create> و First-Time Creation of the PostgreSQL Database <#pgsql-database-create> را ببینید.
168u
168u
پیکربندی پایگاه‌داده اجاره‌ها از طریق پارامترهای Dhcp4/lease-database کنترل می‌شود. نوع پایگاه‌داده باید روی memfile، mysql یا postgresql تنظیم شود، برای مثال:
0.0
3.5
"Dhcp4": { "lease-database": { "type": "mysql", ... }, ... }
168u
168u
سپس، نام پایگاه‌داده‌ای که اجاره‌ها را در خود نگه می‌دارد باید مشخص شود؛ این همان نامی است که هنگام ایجاد پایگاه‌داده استفاده شده است (ببینید First-Time Creation of the MySQL Database <#mysql-database-create> یا First-Time Creation of the PostgreSQL Database <#pgsql-database-create>).
برای MySQL یا PostgreSQL:
0.0
3.5
"Dhcp4": { "lease-database": { "name": "database-name" , ... }, ... }
168u
168u
اگر پایگاه‌داده در سیستمی متفاوت از کارساز DHCPv4 قرار دارد، نام میزبان (host name) پایگاه‌داده نیز باید مشخص شود:
0.0
3.5
"Dhcp4": { "lease-database": { "host": "remote-host-name", ... }, ... }
168u
168u
به‌طور معمول، پایگاه‌داده روی همان ماشین کارساز DHCPv4 قرار دارد. در این حالت، مقدار را روی رشته خالی تنظیم کنید:
0.0
3.5
"Dhcp4": { "lease-database": { "host" : "", ... }, ... }
168u
168u
اگر پایگاه‌داده از درگاهی به غیر از درگاه پیش‌فرض استفاده کند، می‌توان آن را نیز مشخص کرد:
0.0
3.5
"Dhcp4": { "lease-database": { "port" : 12345, ... }, ... }
168u
168u
چنانچه پایگاه‌داده در سیستم دیگری قرار داشته باشد، ممکن است مدیر سیستم نیاز داشته باشد بازه زمانی طولانی‌تری را برای مهلت زمانی اتصال (connection timeout) مشخص کند:
0.0
3.5
"Dhcp4": { "lease-database": { "connect-timeout" : timeout-in-seconds, ... }, ... }
168u
168u
مقدار پیش‌فرض پنج ثانیه باید برای اتصالات محلی کاملاً کافی باشد. با این حال، در صورت تعیین مهلت زمانی، این مقدار باید یک عدد صحیح بزرگ‌تر از صفر باشد.
حداکثر دفعاتی که کارساز پس از قطع ارتباط، به‌طور خودکار تلاش می‌کند تا دوباره به پایگاه‌داده اجاره‌ها متصل شود، می‌تواند مشخص شود:
0.0
3.5
"Dhcp4": { "lease-database": { "max-reconnect-tries" : number-of-tries, ... }, ... }
168u
168u
اگر کارساز پس از انجام حداکثر دفعات تلاش نتواند مجدداً به پایگاه‌داده متصل شود، کارساز خارج خواهد شد. مقدار 0 (پیش‌فرض) بازیابی خودکار را غیرفعال می‌کند و کارساز بلافاصله پس از تشخیص قطعی اتصال خارج می‌شود (فقط در MySQL و PostgreSQL).
تعداد میلی‌ثانیه‌هایی که کارساز بین دفعات تلاش برای اتصال مجدد به پایگاه‌داده اجاره‌ها پس از قطع اتصال منتظر می‌ماند نیز می‌تواند مشخص شود:
0.0
3.5
"Dhcp4": { "lease-database": { "reconnect-wait-time" : number-of-milliseconds, ... }, ... }
168u
168u
مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی خودکار را غیرفعال کرده و باعث می‌شود کارساز بلافاصله پس از تشخیص قطعی اتصال خارج شود.
0.0
3.5
"Dhcp4": { "lease-database": { "on-fail" : "stop-retry-exit", ... }, ... }
168u
168u
مقادیر ممکن عبارتند از:
0.0
• 2
stop-retry-exit - سرویس DHCP را در حین تلاش برای بازیابی خودکار اتصالات قطع‌شده غیرفعال می‌کند، و در صورت شکست پس از به پایان رسیدن max-reconnect-tries، کارساز را خاموش می‌نماید. این مقدار پیش‌فرض برای بک‌اند اجاره‌ها، بک‌اند میزبان‌ها و بک‌اند پیکربندی است.
• 2
serve-retry-exit - سرویس DHCP را در حین تلاش برای بازیابی خودکار اتصالات قطع‌شده ادامه می‌دهد، و در صورت شکست پس از به پایان رسیدن max-reconnect-tries، کارساز را خاموش می‌کند.
• 2
serve-retry-continue - سرویس DHCP را ادامه می‌دهد و حتی در صورت ناموفق بودن بازیابی، کارساز را خاموش نمی‌کند. این مقدار پیش‌فرض برای forensic logging است.
168u
نکته:
0.0
3.5
اتصال مجدد خودکار به بک‌اندهای پایگاه‌داده به‌طور مجزا برای هر بک‌اند پیکربندی می‌شود؛ این قابلیت به کاربران امکان می‌دهد تا پارامترهای بازیابی را متناسب با هر بک‌اندی که استفاده می‌کنند تنظیم نمایند. ما پیشنهاد می‌کنیم که کاربران آن را یا برای همه بک‌اندها فعال کنند یا برای هیچ‌کدام، تا رفتار سیستم یکپارچه و سازگار باشد.
از دست رفتن ارتباط با بک‌اندی که اتصال مجدد برای آن غیرفعال است (در صورت پیکربندی) منجر به خاموش شدن کارساز خواهد شد. این موضوع مواردی را نیز در بر می‌گیرد که بک‌اند پایگاه‌داده اجاره‌ها و بک‌اند پایگاه‌داده میزبان‌ها به یک نمونه (instance) پایگاه‌داده یکسان متصل هستند.
اکیداً توصیه می‌شود تنظیم پیش‌فرض stop-retry-exit را برای مدیر اجاره‌ها تغییر ندهید، چرا که فعال بودن اتصال در حین پردازش ترافیک DHCP بسیار حیاتی است. این مورد را تنها در صورتی تغییر دهید که کارساز منحصراً به‌عنوان یک ابزار پیکربندی استفاده شود.
168u
168u
0.0
3.5
"Dhcp4": { "lease-database": { "retry-on-startup" : true, ... }, ... }
168u
168u
در حین راه‌اندازی کارساز، ناتوانی در اتصال به هر یک از بک‌اندهای پیکربندی‌شده تنها در صورتی یک خطای مهلک تلقی می‌شود که retry-on-startup روی false (پیش‌فرض) تنظیم شده باشد. با این فرض که پیکربندی در زمان راه‌اندازی باید معتبر باشد، یک خطای مهلک ثبت شده و کارساز خارج می‌شود. خروج به سیستم‌عامل این امکان را به اسکریپت‌های ناظر (nanny scripts) می‌دهد تا مشکل را تشخیص دهند. اگر retry-on-startup روی true تنظیم شود، کارساز تلاش‌های اتصال مجدد را حتی در زمان راه‌اندازی کارساز یا در هنگام رویدادهای پیکربندی مجدد آغاز می‌کند و اقدام مشخص‌شده در پارامتر on-fail را رعایت می‌نماید.
پارامتر host توسط بک‌اندهای MySQL و PostgreSQL استفاده می‌شود.
در نهایت، باید اعتبارنامه‌های حسابی که کارساز تحت آن به پایگاه‌داده دسترسی خواهد داشت تعیین شود:
0.0
3.5
"Dhcp4": {
"lease-database": {
"user": "user-name",
"password": "1234",
...
},
...
}
168u
168u
اگر حساب کاربری رمز عبور ندارد، گذرواژه را روی یک رشته خالی "" تنظیم کنید. (این حالت پیش‌فرض است.).SS تنظیم مهلت‌های زمانی پایگاه داده (Tuning Database Timeouts)
در موارد نادر، ممکن است عملیات خواندن یا نوشتن در پایگاه داده معلق شود (hang کند). این امر می‌تواند ناشی از یک مشکل موقتی شبکه، یا پیکربندی نادرست سرور پراکسی باشد که اتصال را میان نمونه‌های مختلف پایگاه داده جابه‌جا می‌کند. این شرایط نادر هستند، اما کاربران گزارش داده‌اند که Kea گاهی هنگام انجام عملیات‌های ورودی/خروجی (IO) پایگاه داده متوقف می‌شود. تنظیم مقادیر مناسب برای مهلت زمانی (timeout) می‌تواند چنین مشکلاتی را کاهش دهد.
پایگاه داده MySQL دو گزینهٔ اتصال مجزا را برای پیکربندی مهلت‌های زمانی خواندن و نوشتن ارائه می‌دهد. پارامترهای پیکربندی متناظر read-timeout و write-timeout در Kea، مهلت‌های زمانی را بر حسب ثانیه مشخص می‌کنند. برای نمونه:
0.0
3.5
"Dhcp4": { "lease-database": { "read-timeout" : 10, "write-timeout": 20, ... }, ... }
168u
168u
تنظیم این پارامترها روی 0 معادل مشخص نکردن آن‌ها است و سبب می‌شود سرور Kea با مقادیر پیش‌فرض MySQL به پایگاه داده متصل شود. در این حالت، Kea برای تکمیل عملیات‌های خواندن و نوشتن به‌طور نامحدود منتظر می‌ماند.
نسخه‌های قدیمی‌تر از 5.6 در MySQL از تنظیم مهلت زمانی برای عملیات خواندن و نوشتن پشتیبانی نمی‌کنند. علاوه‌بر این، پارامترهای read-timeout و write-timeout تنها می‌توانند برای بک‌اند MySQL مشخص شوند؛ تنظیم آن‌ها برای هر نوع بک‌اند پایگاه دادهٔ دیگر موجب خطای پیکربندی خواهد شد.
برای تنظیم مهلت زمانی بر حسب ثانیه در PostgreSQL، از پارامتر tcp-user-timeout استفاده کنید. برای نمونه:
0.0
3.5
"Dhcp4": { "lease-database": { "tcp-user-timeout" : 10, ... }, ... }
168u
168u
مشخص کردن این پارامتر برای انواع دیگر بک‌اند موجب خطای پیکربندی خواهد شد.
نکته:
0.0
3.5
مهلت‌های زمانی شرح داده شده در اینجا تنها برای اتصالات TCP مؤثر هستند. لطفاً توجه داشته باشید که کتابخانه کلاینت MySQL مورداستفاده در سرورهای Kea، معمولاً هنگامی که پارامتر host روی localhost تنظیم شده باشد، از طریق یک سوکت دامنه یونیکس (UNIX domain socket) به پایگاه داده متصل می‌شود، اما برای 127.0.0.1 یک اتصال TCP برقرار می‌کند.
168u
168u
از Kea.2.7.4 به بعد، کتابخانهٔ قلاب libdhcp_mysql.so باید بارگذاری شود تا بتوان اجاره‌ها را در بک‌اند پایگاه دادهٔ اجارهٔ MySQL ذخیره کرد. مکان کتابخانهٔ قلاب بک‌اند اجاره را مشخص کنید:
0.0
3.5
"Dhcp4": { "hooks-libraries": [
{
// the MySQL lease backend hook library required for lease storage.
"library": "libdhcp_mysql.so"
}, ... ], ... }
168u
168u
از Kea.2.7.4 به بعد، کتابخانهٔ قلاب libdhcp_pgsql.so باید بارگذاری شود تا بتوان اجاره‌ها را در بک‌اند پایگاه دادهٔ اجارهٔ PostgreSQL ذخیره کرد. مکان کتابخانهٔ قلاب بک‌اند اجاره را مشخص کنید.
0.0
3.5
"Dhcp4": { "hooks-libraries": [
{
// the PostgreSQL lease backend hook library required for lease storage.
"library": "libdhcp_pgsql.so"
}, ... ], ... }
168u
168u
ذخیره‌سازی میزبان‌ها (Hosts Storage)
همچنین Kea قادر است اطلاعات مربوط به رزروهای میزبان (host reservations) را در پایگاه داده ذخیره کند. پیکربندی پایگاه دادهٔ میزبان‌ها از همان ساختار نحوی پایگاه دادهٔ اجاره‌ها استفاده می‌کند. در واقع، سرور Kea برای هر هدف، چه اطلاعات اجاره و چه میزبان‌ها، اتصال‌های مستقلی باز می‌کند که بیشترین انعطاف‌پذیری را فراهم می‌آورد. Kea می‌تواند اجاره‌ها و رزروهای میزبان را به‌طور جداگانه نگهداری کند، اما می‌تواند به یک پایگاه دادهٔ یکسان نیز اشاره داشته باشد. در حال حاضر، انواع پایگاه دادهٔ میزبان‌های پشتیبانی‌شده MySQL و PostgreSQL هستند.
از پیکربندی زیر می‌توان برای تنظیم اتصال به MySQL استفاده کرد:
0.0
3.5
"Dhcp4": {
"hosts-database": {
"type": "mysql",
"name": "kea",
"user": "kea",
"password": "1234",
"host": "localhost",
"port": 3306
}
}
168u
168u
بسته به پیکربندی پایگاه داده، بسیاری از پارامترها ممکن است اختیاری باشند.
لطفاً توجه داشته باشید که استفاده از ذخیره‌سازی میزبان‌ها اختیاری است. کاربر می‌تواند تمامی رزروهای میزبان را در فایل پیکربندی تعریف کند و چنانچه تعداد رزروها اندک باشد، این شیوه توصیه‌شده است. با این حال، هنگامی که تعداد رزروها افزایش می‌یابد، استفاده از فضای ذخیره‌سازی میزبان راحت‌تر خواهد بود. لطفاً در نظر داشته باشید که هر دو روش ذخیره‌سازی (فایل پیکربندی و یکی از پایگاه‌های دادهٔ پشتیبانی‌شده) می‌توانند هم‌زمان استفاده شوند. اگر میزبان‌ها در هر دو مکان تعریف شده باشند، ابتدا تعاریف فایل پیکربندی بررسی می‌شوند و سپس در صورت لزوم، فضای ذخیره‌سازی خارجی بررسی خواهد شد.
اطلاعات میزبان می‌تواند در چندین مخزن قرار داده شود. عملیات‌ها بر اساس ترتیبی که مخازن در فایل پیکربندی تعریف شده‌اند روی آن‌ها انجام می‌شود، هرچند این امر در صورت افزودن رزرو میزبان به محدودیتی در ترتیب منجر می‌شود؛ مخازن فقط‌خواندنی (read-only) باید پس از یک مخزن خواندنی-نوشتنی (read-write) الزامی پیکربندی شوند، وگرنه عملیات افزودن با شکست مواجه خواهد شد.
نکته:
0.0
3.5
در Kea الزامی است که منطقه زمانی (timezone) پایگاه داده با منطقه زمانی سیستم مطابقت داشته باشد. برای جزئیات بیشتر، First-Time Creation of the MySQL Database <#mysql-database-create> و First-Time Creation of the PostgreSQL Database <#pgsql-database-create> را ببینید.
168u
پیکربندی پایگاه‌داده میزبان‌ها از طریق پارامترهای
Dhcp4/hosts-database کنترل می‌شود. در صورت فعال بودن، نوع پایگاه‌داده باید
روی mysql یا postgresql تنظیم شود.
0.0
3.5
"Dhcp4": { "hosts-database": { "type": "mysql", ... }, ... }
168u
168u
سپس، نام پایگاه‌داده‌ای که رزروها را نگهداری می‌کند باید مشخص شود؛
این همان نامی است که هنگام ایجاد پایگاه‌داده اجاره‌ها (lease) استفاده شده است (برای دستورالعمل‌های
نحوه راه‌اندازی نوع پایگاه‌داده مورد نظر، بخش پس‌انه‌های پشتیبانی‌شده <#supported-databases> را ببینید):
0.0
3.5
"Dhcp4": { "hosts-database": { "name": "database-name" , ... }, ... }
168u
168u
اگر پایگاه‌داده روی سیستمی متفاوت از کارساز DHCPv4 قرار دارد،
نام میزبان پایگاه‌داده نیز باید مشخص شود:
0.0
3.5
"Dhcp4": { "hosts-database": { "host": remote-host-name, ... }, ... }
168u
168u
به طور معمول، پایگاه‌داده روی همان رایانه‌ای قرار دارد که کارساز DHCPv4 اجرا می‌شود.
در این حالت، مقدار را روی یک رشته خالی تنظیم کنید:
0.0
3.5
"Dhcp4": { "hosts-database": { "host" : "", ... }, ... }
168u
168u
اگر پایگاه‌داده از درگاهی غیر از پیش‌فرض استفاده کند، آن درگاه
نیز می‌تواند مشخص شود:
0.0
3.5
"Dhcp4": { "hosts-database": { "port" : 12345, ... }, ... }
168u
168u
حداکثر دفعاتی که کارساز پس از قطع ارتباط، به طور خودکار برای
اتصال دوباره به پایگاه‌داده میزبان تلاش می‌کند را می‌توان
مشخص کرد:
0.0
3.5
"Dhcp4": { "hosts-database": { "max-reconnect-tries" : number-of-tries, ... }, ... }
168u
168u
اگر کارساز پس از انجام حداکثر دفعات تلاش نتواند دوباره به پایگاه‌داده
متصل شود، کارساز خارج خواهد شد. مقدار 0 (پیش‌فرض) بازیابی
خودکار را غیرفعال می‌کند و کارساز بلافاصله پس از تشخیص قطعی اتصال
خارج می‌شود (تنها در MySQL و PostgreSQL).
تعداد میلی‌ثانیه‌هایی که کارساز میان دفعات تلاش برای اتصال دوباره
به پایگاه‌داده میزبان پس از قطعی اتصال منتظر می‌ماند نیز می‌تواند
تعیین شود:
0.0
3.5
"Dhcp4": { "hosts-database": { "reconnect-wait-time" : number-of-milliseconds, ... }, ... }
168u
168u
مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی
خودکار را غیرفعال کرده و باعث می‌شود کارساز بلافاصله پس از
تشخیص قطعی اتصال متوقف شود.
0.0
3.5
"Dhcp4": { "hosts-database": { "on-fail" : "stop-retry-exit", ... }, ... }
168u
168u
مقدارهای ممکن عبارتند از:
0.0
• 2
stop-retry-exit - هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده،
سرویس DHCP را غیرفعال می‌کند. در صورت شکست پس از پایان دفعات مجاز
max-reconnect-tries، کارساز را خاموش می‌کند. این مقدار پیش‌فرض برای MySQL و PostgreSQL است.
• 2
serve-retry-exit - هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده،
به سرویس‌دهی DHCP ادامه می‌دهد. در صورت شکست پس از پایان دفعات مجاز
max-reconnect-tries، کارساز را خاموش می‌کند.
• 2
serve-retry-continue - به سرویس‌دهی DHCP ادامه می‌دهد و حتی اگر
بازیابی شکست بخورد، کارساز را خاموش نمی‌کند.
168u
نکته:
0.0
3.5
اتصال دوباره خودکار به پس‌انه‌های پایگاه‌داده به صورت جداگانه برای هر
پس‌انه پیکربندی می‌شود. این به کاربران امکان می‌دهد پارامترهای بازیابی را متناسب با هر
پس‌انه‌ای که استفاده می‌کنند تنظیم کنند. پیشنهاد می‌کنیم کاربران آن را یا برای همه پس‌انه‌ها
فعال کنند یا برای هیچ‌کدام، تا رفتار سیستم یکپارچه باقی بماند.
از دست رفتن ارتباط با پس‌انه‌ای که اتصال مجدد برای آن غیرفعال است منجر
(در صورت پیکربندی) به خاموش شدن خودکار کارساز می‌شود. این مورد شامل شرایطی نیز
می‌شود که در آن، پس‌انه پایگاه‌داده اجاره‌ها و پس‌انه پایگاه‌داده میزبان‌ها به یک
نمونه یکسان از پایگاه‌داده متصل هستند.
168u
168u
0.0
3.5
"Dhcp4": { "hosts-database": { "retry-on-startup" : true, ... }, ... }
168u
168u
در طول راه‌اندازی کارساز، ناتوانی در اتصال به هر یک از پس‌انه‌های پیکربندی‌شده
تنها در صورتی مهلک تلقی می‌شود که retry-on-startup روی false
(پیش‌فرض) تنظیم شده باشد. یک خطای مهلک ثبت شده و کارساز خارج می‌شود، بر این مبنا
که پیکربندی در زمان راه‌اندازی باید معتبر باشد. خروج و بازگشت به سیستم‌عامل
به اسکریپت‌های ناظر (nanny scripts) امکان می‌دهد تا مشکل را شناسایی کنند.
اگر retry-on-startup روی true تنظیم شود، کارساز حتی در زمان راه‌اندازی
یا رویدادهای بازپیکربندی نیز تلاش‌ها برای اتصال دوباره را آغاز می‌کند و اقدام
مشخص‌شده در پارامتر on-fail را به کار می‌بندد.
در پایان، اعتبارنامه‌های حسابی که کارساز تحت آن به پایگاه‌داده
دسترسی خواهد داشت باید تنظیم شوند:
0.0
3.5
"Dhcp4": {
"hosts-database": {
"user": "user-name",
"password": "1234",
...
},
...
}
168u
168u
اگر حساب گذرواژه‌ای ندارد، گذرواژه را روی رشته خالی
"" تنظیم کنید. (این حالت پیش‌فرض است.)
افزونه multiple-storage از نحو مشابهی استفاده می‌کند؛ پیکربندی به جای یک
مدخل hosts-database در یک فهرست hosts-databases قرار
می‌گیرد، مانند:
0.0
3.5
"Dhcp4": { "hosts-databases": [ { "type": "mysql", ... }, ... ], ... }
168u
168u
اگر یک میزبان یکسان هم درون فایل (in-file) و هم درون پایگاه‌داده (in-database) پیکربندی شده باشد، Kea هشداری صادر نمی‌کند،
برخلاف زمانی که هر دو در یک منبع داده یکسان مشخص شده باشند.
در عوض، میزبان پیکربندی‌شده درون فایل نسبت به میزبان پیکربندی‌شده
درون پایگاه‌داده اولویت دارد..SS استفاده از پایگاه‌های داده فقط-خواندنی برای رزروهای میزبان با DHCPv4
در برخی استقرارها، کاربری که نامش در پیکربندی backend پایگاه داده مشخص شده است، ممکن است مجوز نوشتن روی پایگاه داده را نداشته باشد. این موضوع اغلب ناشی از سیاست‌های یک شبکه برای محافظت از داده‌ها در برابر تغییرات ناخواسته است. در بسیاری از موارد مدیران سیستم پایگاه‌های داده انبارگردانی (inventory) را مستقر کرده‌اند که حاوی اطلاعات به مراتب بیشتری درباره میزبان‌ها نسبت به صرفاً رزروهای ایستا اختصاص‌یافته به آن‌هاست. پایگاه داده انبارگردانی می‌تواند برای ایجاد یک نما (view) از پایگاه داده میزبان‌های Kea مورد استفاده قرار گیرد و چنین نمایی اغلب فقط-خواندنی (read-only) است.
بک‌اندهای پایگاه داده میزبان Kea با یک پیکربندی ضمنی برای خواندن و نوشتن هم‌زمان در پایگاه داده کار می‌کنند. اگر کاربر دسترسی نوشتن به پایگاه داده میزبان را نداشته باشد، راه‌اندازی بک‌اند با شکست مواجه شده و سرور از شروع به کار (یا بازپیکربندی) سر باز می‌زند. با این حال، اگر دسترسی به یک پایگاه داده میزبانِ فقط-خواندنی برای بازیابی رزروهای کلاینت‌ها و/یا انتساب نشانی‌ها و گزینه‌های خاص مورد نیاز باشد، می‌توان Kea را صریحاً برای اجرا در حالت "read-only" پیکربندی کرد. این حالت توسط پارامتر بولی readonly به صورت زیر کنترل می‌شود:
0.0
3.5
"Dhcp4": { "hosts-database": { "readonly": true, ... }, ... }
168u
168u
تنظیم این پارامتر روی false، بک‌اند پایگاه داده را برای فعالیت در حالت "read-write" پیکربندی می‌کند، که در صورت مشخص نشدن پارامتر، پیکربندی پیش‌فرض نیز همین است.
نکته:
0.0
3.5
پارامتر readonly تنها برای پایگاه‌های داده MySQL و PostgreSQL پشتیبانی می‌شود.
168u
168u
از نسخه Kea.2.7.4 به بعد، کتابخانه قلاب (hook library) libdhcp_mysql.so باید بارگیری شود تا رزروهای میزبان در MySQL Host Database Backend ذخیره شوند.
مکان کتابخانه قلاب بک‌اند اجاره (lease) را مشخص کنید:
0.0
3.5
"Dhcp4": { "hooks-libraries": [
{
// the MySQL host backend hook library required for host storage.
"library": "libdhcp_mysql.so"
}, ... ], ... }
168u
168u
از نسخه Kea.2.7.4 به بعد، کتابخانه قلاب libdhcp_pgsql.so باید بارگیری شود تا رزروهای میزبان در PostgreSQL Host Database Backend ذخیره شوند.
مکان کتابخانه قلاب بک‌اند اجاره را مشخص کنید.
0.0
3.5
"Dhcp4": { "hooks-libraries": [
{
// the PostgreSQL host backend hook library required for host storage.
"library": "libdhcp_pgsql.so"
}, ... ], ... }
168u
168u
تنظیم مهلت‌های زمانی پایگاه داده برای ذخیره‌سازی میزبان‌ها
بخش Tuning Database Timeouts را ببینید.
پیکربندی رابط‌های شبکه (Interface Configuration)
سرور DHCPv4 باید طوری پیکربندی شود که روی رابط‌های شبکه خاصی شنود کند. ساده‌ترین پیکربندی رابط شبکه به سرور می‌گوید روی تمام رابط‌های در دسترس گوش فرا دهد:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "*" ]
},
...
}
168u
168u
علامت ستاره نقش یک کاراکتر عام (wildcard) را ایفا می‌کند و به معنای "گوش دادن روی همه رابط‌ها" است. با این حال، معمولاً بهتر است نام رابط‌ها را به‌طور صریح مشخص کنید:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ]
},
...
}
168u
168u
امکان استفاده از کاراکتر عام رابط (*) هم‌زمان با نام‌های صریح رابط‌ها وجود دارد:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1", "eth3", "*" ]
},
...
}
168u
168u
این قالب تنها زمانی باید استفاده شود که بخواهید موقتاً فهرستی از نام‌های رابط را نادیده گرفته و روی تمام رابط‌ها گوش دهید.
برخی از استقرارهای سرورهای DHCP نیازمند آن هستند که سرورها روی رابط‌هایی با چندین نشانی IPv4 پیکربندی‌شده گوش دهند. در این وضعیت‌ها، نشانی مورد نظر را می‌توان با پیوست کردن یک نشانی IPv4 به نام رابط به روش زیر انتخاب کرد:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1/10.0.0.1", "eth3/192.0.2.3" ]
},
...
}
168u
168u
اگر نیاز باشد سرور روی چندین نشانی IPv4 اختصاص‌یافته به یک رابط مشترک گوش دهد، می‌توان مانند مثال زیر چندین نشانی را برای یک رابط تعیین کرد:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1/10.0.0.1", "eth1/10.0.0.2" ]
},
...
}
168u
168u
روش دیگر این است که اگر سرور باید روی تمام نشانی‌های یک رابط خاص گوش دهد، نام رابط بدون هیچ نشانی مشخص شود.
سرور Kea از پاسخ‌دهی به کلاینت‌های مستقیماً متصل که نشانی پیکربندی‌شده‌ای ندارند پشتیبانی می‌کند. این کار مستلزم آن است که سرور نشانی سخت‌افزاری مقصد را در لایه پیوند داده (data-link layer) بسته ارسالی به کلاینت تزریق کند. سرور DHCPv4 برای دستیابی به این هدف از سوکت‌های خام (raw sockets) استفاده کرده و کل پشته IP/UDP را برای بسته‌های خروجی ایجاد می‌کند. با این حال، نکته منفی استفاده از سوکت خام این است که بسته‌های ورودی و خروجی فایروال‌ها (مانند iptables) را دور می‌زنند.
مدیریت ترافیک روی چندین نشانی IPv4 اختصاص‌یافته به یک رابط مشترک می‌تواند یک چالش باشد، چرا که سوکت‌های خام به خود رابط متصل (bind) می‌شوند. هنگامی که سرور DHCP پیکربندی می‌شود تا از سوکت خام روی یک رابط برای دریافت ترافیک DHCP استفاده کند، باید روش‌های پیشرفته فیلتر کردن بسته (مانند BPF) به کار گرفته شوند تا ترافیک تک‌پخشی (unicast) روی نشانی‌های مد نظر اختصاص‌یافته به رابط دریافت شود. اینکه کلاینت‌ها از سوکت خام یا سوکت UDP استفاده کنند، به این بستگی دارد که مستقیماً متصل شده‌اند (سوکت خام) یا بازپخش‌شده (relayed) هستند (سوکت خام یا سوکت UDP).
بنابراین، در استقرارهایی که نیازی نیست سرور کلاینت‌های مستقیماً متصل را پیکربندی کند و تنها بسته‌های تک‌پخشی (unicast) را از عامل‌های بازپخش (relay agents) دریافت می‌کند، سرور Kea باید طوری پیکربندی شود که به جای سوکت‌های خام از سوکت‌های UDP استفاده کند. پیکربندی زیر نشان می‌دهد که این کار چگونه انجام‌پذیر است:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ],
"dhcp-socket-type": "udp"
},
...
}
168u
168u
پارامتر dhcp-socket-type مشخص می‌کند که سوکت‌های IP/UDP روی تمام رابط‌هایی که سرور روی آن‌ها گوش می‌دهد (یعنی در این مثال "eth1" و "eth3") باز خواهند شد. اگر dhcp-socket-type روی raw تنظیم شود، سرور را پیکربندی می‌کند تا در عوض از سوکت‌های خام استفاده کند. اگر مقدار dhcp-socket-type مشخص نشود، مقدار پیش‌فرض raw به کار می‌رود.
استفاده از سوکت‌های UDP به‌طور خودکار دریافت بسته‌های همگانی (broadcast) از کلاینت‌های متصل مستقیم را غیرفعال می‌کند. این عملاً بدین معناست که سوکت‌های UDP تنها برای ترافیک بازپخش‌شده (relayed) قابل استفاده هستند. هنگام استفاده از سوکت‌های خام، هم ترافیک کلاینت‌های متصل مستقیم و هم ترافیک بازپخش‌شده مدیریت می‌شوند.
هنگام پیکربندی سرور برای باز کردن چندین سوکت خام روی رابطی با چند نشانی IPv4 اختصاص‌یافته، باید احتیاط کرد. اگر کلاینت مستقیماً متصل پیامی را به نشانی همگانی (broadcast) ارسال کند، تمام سوکت‌های روی این پیوند این پیام را دریافت کرده و چندین پاسخ به کلاینت فرستاده خواهد شد. بنابراین، در صورتی که کلاینت‌های مستقیماً متصل روی آن پیوند فعالیت می‌کنند، نباید از پیکربندی با چندین نشانی IPv4 اختصاص‌یافته به رابط استفاده شود. برای استفاده از یک نشانی واحد در چنین رابطی، باید از ساختار "interface-name/address" استفاده شود.
نکته:
0.0
3.5
مشخص کردن مقدار raw به عنوان نوع سوکت تضمین نمی‌کند که حتماً از سوکت‌های خام استفاده خواهد شد! استفاده از سوکت‌های خام برای مدیریت ترافیک کلاینت‌های متصل مستقیم در حال حاضر تنها روی سیستم‌های Linux و BSD پشتیبانی می‌شود. اگر سوکت‌های خام در سیستم‌عامل مورد استفاده پشتیبانی نشوند، سرور یک هشدار صادر کرده و به استفاده از سوکت‌های IP/UDP بازمی‌گردد.
168u
168u
در یک محیط معمولی، انتظار می‌رود سرور DHCP پاسخ را روی همان رابط شبکه‌ای بازگرداند که پرس‌وجو از آن دریافت شده است. این رفتار پیش‌فرض است. با این حال، در برخی استقرارها مطلوب است که بسته‌های خروجی (پاسخ) به عنوان ترافیک عادی ارسال شوند و رابط خروجی توسط جدول‌های مسیریابی تعیین گردد. این نوع ترافیک نامتقارن، غیرمعمول اما معتبر است. سرور Kea از پارامتری به نام outbound-interface پشتیبانی می‌کند که این رفتار را کنترل می‌نماید. این پارامتر دو مقدار می‌پذیرد: مقدار نخست، same-as-inbound، به Kea می‌گوید پاسخ را روی همان رابطی بازگرداند که بسته پرس‌وجو دریافت شده بود. این رفتار پیش‌فرض است. پارامتر دوم، use-routing، به Kea می‌گوید بسته‌های عادی UDP را ارسال کند و اجازه دهد جدول مسیریابی هسته مناسب‌ترین رابط را تعیین کند. این گزینه تنها زمانی کار می‌کند که dhcp-socket-type روی udp تنظیم شده باشد. یک نمونه پیکربندی به صورت زیر است:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ],
"dhcp-socket-type": "udp",
"outbound-interface": "use-routing"
},
...
}
168u
168u
رابط‌ها در هر بازپیکربندی دوباره شناسایی می‌شوند. این رفتار را می‌توان با تنظیم مقدار re-detect روی false غیرفعال کرد، برای نمونه:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ],
"re-detect": false
},
...
}
168u
168u
سازوکار شناسایی مجدد (re-detect) معمولاً رابط‌های شناسایی‌شده پیشین را حذف کرده و سپس تمام رابط‌های شناسایی‌شده فعلی را اضافه می‌کند.
توجه داشته باشید که هنگام اجرای دستورات config-test <#std-isccmd-config-test> یا config-set <#std-isccmd-config-set> رابط‌ها مجدداً شناسایی نمی‌شوند.
با این حال، رابط‌های جدید شناسایی شده و برای استفاده توسط پیکربندی جدید ارسال‌شده به دستورات config-test <#std-isccmd-config-test> و config-set <#std-isccmd-config-set> در دسترس خواهند بود.
معمولاً رابط‌های بازگشتی (مانند رابط lo یا lo0) پیکربندی نمی‌شوند، اما اگر یک رابط بازگشتی به‌طور صریح پیکربندی شود و سوکت‌های IP/UDP مشخص گردند، رابط بازگشتی پذیرفته می‌شود.
برای مثال، این ساختار می‌تواند برای اجرای Kea در یک FreeBSD jail که تنها یک رابط بازگشتی دارد، جهت سرویس‌دهی به یک درخواست DHCP بازپخش‌شده (relayed) استفاده شود:
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "lo0" ],
"dhcp-socket-type": "udp"
},
...
}
168u
168u
سرور Kea هنگام راه‌اندازی، سوکت‌های سرویس را به هر رابط متصل می‌کند (bind). اگر فرایند دیگری در حال استفاده از یک درگاه (port) باشد، Kea پیام مربوطه را ثبت کرده و از اعلام خطا جلوگیری می‌کند. در این حالت سرویس DHCP اجرا می‌شود، اما روی برخی رابط‌ها در دسترس نخواهد بود.
گزینه "service-sockets-require-all" باعث می‌شود Kea نیاز داشته باشد که تمام سوکت‌ها با موفقیت متصل شوند. در صورت بروز هرگونه شکست در باز کردن سوکت‌ها، Kea فرایند مقداردهی اولیه را متوقف کرده و با یک وضعیت غیرصفر خارج می‌شود (پیش‌فرض false است).
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ],
"service-sockets-require-all": true
},
...
}
168u
168u
گاهی اوقات توقف فوری گزینه مناسبی نیست، چرا که درگاه ممکن است تنها به‌صورت موقت در دسترس نباشد. در این حالت، تلاش مجدد برای باز کردن ممکن است مشکل را رفع کند. سرور Kea دو گزینه برای تعیین تلاش مجدد فراهم می‌کند:
service-sockets-max-retries و service-sockets-retry-wait-time.
گزینه اول حداکثر تعداد دفعاتی را تعیین می‌کند که Kea برای باز کردن یک سوکت دوباره تلاش می‌نماید. مقدار صفر (پیش‌فرض) بدین معناست که Kea این فرایند را تکرار نمی‌کند.
گزینه دوم زمان انتظار (بر حسب میلی‌ثانیه) بین تلاش‌ها را مشخص می‌کند. مقدار پیش‌فرض 5000 (5 ثانیه) است.
0.0
3.5
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth1", "eth3" ],
"service-sockets-max-retries": 5,
"service-sockets-retry-wait-time": 5000
},
...
}
168u
168u
اگر "service-sockets-max-retries" غیرصفر باشد و "service-sockets-require-all" روی false تنظیم شده باشد، Kea در صورت نیاز تلاش مجدد را انجام می‌دهد، اما در صورتی که هر سوکت همچنان باز نشود متوقف نخواهد شد..SS مشکلات پاسخ‌های تک‌پخشی (Unicast) به DHCPINFORM
استفاده از سوکت‌های UDP در استقرارهایی که کارگزار فقط ترافیک رله‌شده را
دریافت می‌کند، مزایای خاصی دارد؛ این مزایا در Interface Configuration
ذکر شده‌اند. از دیدگاه مدیر سیستم، اغلب مطلوب است که دیوار آتش سامانه برای
فیلتر کردن ترافیک ناخواسته پیکربندی شود، و استفاده از سوکت‌های UDP
این کار را تسهیل می‌کند. با این حال، مدیر سیستم باید از پیامدهای مربوط به
فیلتر کردن انواع خاصی از ترافیک نیز آگاه باشد، زیرا ممکن است عملکرد
کارگزار DHCP را مختل کند.
در این بخش، ما روی حالتی تمرکز می‌کنیم که کارگزار پیام DHCPINFORM را
از طریق یک رله از کلاینت دریافت می‌کند. بر اساس RFC 2131
https://datatracker.ietf.org/doc/html/rfc2131، کارگزار
باید پاسخ DHCPACK را به‌صورت unicast به آدرس موجود در فیلد ciaddr ارسال
کند. هنگامی که سوکت UDP در حال استفاده است، کارگزار DHCP برای ساخت لایه‌های
پیوند داده (data link)، IP و UDP پیام خروجی، به توابع سطح پایین سیستم‌عامل
متکی است. معمولاً، اگر آدرس کلاینت از یک تراکنش قبلی کلاینت با کارگزار در حافظهٔ
موقت ذخیره نشده باشد، سیستم‌عامل ابتدا از ARP برای به‌دست آوردن آدرس لایهٔ پیوند
کلاینت جهت درج در سرآیند فریم استفاده می‌کند. هنگامی که تبادل ARP موفقیت‌آمیز
باشد، پیام DHCP می‌تواند با استفاده از آدرس به‌دست‌آمده، به‌صورت unicast به
کلاینت ارسال شود.
برخی از مدیران سیستم پیام‌های ARP را در شبکهٔ خود مسدود می‌کنند، که این امر
در هنگام پاسخ کارگزار به پیام‌های DHCPINFORM مشکلاتی ایجاد می‌کند؛ زیرا اگر
ارتباط ARP قبلی با شکست مواجه شود، کارگزار قادر به ارسال DHCPACK نخواهد بود.
از آنجا که سیستم‌عامل به‌طور کامل مسئول ارتباط ARP و سپس ارسال بستهٔ DHCP بر روی
بستر شبکه است، کارگزار DHCP راهی برای تشخیص شکست در تبادل ARP و دور انداخته
شدن (drop) پیام پاسخ DHCP ندارد. بنابراین، هنگامی که پاسخ DHCP خروجی دور انداخته
می‌شود، کارگزار هیچ پیام خطایی ثبت نمی‌کند. هم‌زمان، تمام قلاب‌های (hooks)
مربوط به عملیات ارسال بسته فراخوانی خواهند شد، حتی اگر پیام هرگز به مقصد خود نرسد.
توجه داشته باشید که مشکل توصیف‌شده در این بخش هنگام استفاده از سوکت‌های raw
مشاهده نمی‌شود، زیرا در این حالت، کارگزار DHCP تمام لایه‌های پیام خروجی را
خودش می‌سازد و از ARP استفاده نمی‌کند. در عوض، مقدار حمل‌شده در فیلد chaddr
از پیام DHCPINFORM را در لایهٔ پیوند درج می‌کند.
مدیران کارگزاری که مایل به پشتیبانی از پیام‌های DHCPINFORM از طریق رله‌ها هستند،
نباید ترافیک ARP را در شبکه‌های خود مسدود کنند، یا باید به‌جای سوکت‌های UDP
از سوکت‌های raw استفاده نمایند.
شناسه زیرشبکه IPv4
شناسهٔ زیرشبکه (subnet ID) یک شمارهٔ یکتا است که با یک زیرشبکهٔ خاص
پیوند دارد. در اصل، برای مرتبط کردن اجاره‌های (leases) کلاینت‌ها با
زیرشبکه‌های مربوطه‌شان استفاده می‌شود. پیکربندی کارگزار باید شامل شناسه‌های
یکتا و پایدار برای تمام زیرشبکه‌ها باشد.
نکته:
0.0
3.5
شناسه‌های زیرشبکه (Subnet ID) باید بزرگ‌تر از صفر و کوچک‌تر از 4294967295 باشند.
168u
168u
پیکربندی زیر شناسهٔ زیرشبکهٔ مشخص‌شده را به یک زیرشبکهٔ تازه‌پیکربندی‌شده
اختصاص می‌دهد:
0.0
3.5
"Dhcp4": {
"subnet4": [
{
"subnet": "192.0.2.0/24",
"id": 1024,
...
}
]
}
168u
168u
پیشوند زیرشبکه IPv4
پیشوند زیرشبکه راه دوم برای شناسایی یک زیرشبکه است. Kea می‌تواند
آدرس‌های زیرشبکهٔ غیرمعیار (non-canonical) را بپذیرد؛ برای نمونه،
این پیکربندی پذیرفته می‌شود:
0.0
3.5
"Dhcp4": {
"subnet4": [
{
"subnet": "192.0.2.1/24",
...
}
]
}
168u
168u
این قابلیت حتی در صورتی که زیرشبکهٔ دیگری با پیشوند "192.0.2.0/24"
وجود داشته باشد کار می‌کند؛ جهت جلوگیری از موارد تکراری، تنها شکل متنی
زیرشبکه‌ها با یکدیگر مقایسه می‌شوند.
نکته:
0.0
3.5
سوءاستفاده از این ویژگی می‌تواند منجر به انتخاب نادرست زیرشبکه شود
(بخش How the DHCPv4 Server Selects a Subnet for the Client را ببینید).
168u
168u
پیکربندی استخرهای آدرس IPv4
نقش اصلی یک کارگزار DHCPv4 تخصیص آدرس است. برای این منظور، کارگزار
باید با حداقل یک زیرشبکه و یک استخر (pool) از آدرس‌های پویا برای
مدیریت پیکربندی شود. برای مثال، فرض کنید کارگزار به یک بخش شبکه متصل است
که از پیشوند 192.0.2.0/24 استفاده می‌کند. مدیر آن شبکه تصمیم می‌گیرد
که آدرس‌های محدودهٔ 192.0.2.10 تا 192.0.2.20 توسط کارگزار DHCPv4 مدیریت
شوند. چنین پیکربندی‌ای می‌تواند به روش زیر انجام شود:
0.0
3.5
"Dhcp4": {
"subnet4": [
{
"subnet": "192.0.2.0/24",
"pools": [
{ "pool": "192.0.2.10 - 192.0.2.20" }
],
...
}
]
}
168u
168u
توجه داشته باشید که subnet به عنوان یک رشتهٔ ساده تعریف شده است،
اما پارامتر pools در واقع فهرستی از استخرها است؛ به همین دلیل،
تعریف استخر درون براکت قرار گرفته است، حتی اگر فقط یک محدوده از آدرس‌ها
مشخص شده باشد.
هر pool ساختاری است که حاوی پارامترهای توصیف‌کنندهٔ یک استخر منفرد
می‌باشد. در حال حاضر تنها یک پارامتر وجود دارد، pool، که محدودهٔ
آدرس‌های درون استخر را مشخص می‌کند.
تعریف بیش از یک استخر در یک زیرشبکه امکان‌پذیر است؛ در ادامهٔ مثال قبلی،
فرض کنید 192.0.2.64/26 نیز باید توسط کارگزار مدیریت شود. این مقدار را
می‌توان به صورت 192.0.2.64 تا 192.0.2.127 نوشت، یا ساده‌تر به شکل
192.0.2.64/26 بیان کرد. هر دو قالب توسط Dhcp4 پشتیبانی می‌شوند
و می‌توان آن‌ها را در فهرست استخر ترکیب کرد. برای نمونه، استخرهای زیر
را می‌توان تعریف کرد:
0.0
3.5
"Dhcp4": {
"subnet4": [
{
"subnet": "192.0.2.0/24",
"pools": [
{ "pool": "192.0.2.10-192.0.2.20" },
{ "pool": "192.0.2.64/26" }
],
...
}
],
...
}
168u
168u
فاصله‌های خالی (white space) در تعریف استخرها نادیده گرفته می‌شوند،
بنابراین فاصله‌های قبل و بعد از خط تیره اختیاری هستند. می‌توان از آن‌ها
برای بهبود خوانایی استفاده کرد.
تعداد استخرها محدودیتی ندارد، اما به دلایل کارایی توصیه می‌شود تا جای
ممکن از تعداد کمتری استفاده شود.
کارگزار ممکن است برای سرویس‌دهی به بیش از یک زیرشبکه پیکربندی شود.
برای افزودن زیرشبکهٔ دوم، از ساختاری مشابه زیر استفاده کنید:
0.0
3.5
"Dhcp4": {
"subnet4": [
{
"subnet": "192.0.2.0/24",
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
...
},
{
"subnet": "192.0.3.0/24",
"pools": [ { "pool": "192.0.3.100 - 192.0.3.200" } ],
...
},
{
"subnet": "192.0.4.0/24",
"pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ],
...
}
]
}
168u
168u
هنگام پیکربندی یک کارگزار DHCPv4 با استفاده از نمادگذاری پیشوند/طول
(prefix/length)، لطفاً به مقادیر مرزی توجه کنید. وقتی مشخص می‌کنید که
کارگزار می‌تواند از یک استخر مشخص استفاده کند، این کارگزار همچنین قادر است
اولین آدرس (معمولاً آدرس شبکه) و آخرین آدرس (معمولاً آدرس پخش همگانی یا
broadcast) آن استخر را نیز تخصیص دهد. در مثال پیشین استخر 192.0.3.0/24،
هر دو آدرس 192.0.3.0 و 192.0.3.255 نیز ممکن است تخصیص یابند. این امر در
برخی از پیکربندی‌های شبکه ممکن است نامعتبر باشد. برای جلوگیری از این موضوع،
از نمادگذاری min-max استفاده کنید.
در زیرشبکه‌ای که طول پیشوند آن کمتر از 24 است، ممکن است کاربران تمایل داشته باشند
همهٔ آدرس‌هایی را که به .0 و .255 ختم می‌شوند از تخصیص پویا مستثنی کنند.
به عنوان مثال، در زیرشبکهٔ 10.0.0.0/8، یک مدیر سیستم ممکن است بخواهد 10.x.y.0
و 10.x.y.255 را برای تمام مقادیر x و y مستثنی کند، با اینکه بر اساس
استانداردهای RFC تنها 10.0.0.0 و 10.255.255.255 باید مستثنی شوند.
پرچم سازگاری پیکربندی exclude-first-last-24 (بخش Kea DHCPv4 Compatibility Configuration Parameters)
این کار را به‌طور خودکار انجام می‌دهد، به‌جای اینکه نیاز به پیکربندی صریح
استخرهای متعدد یا رزرو برای میزبان‌های ساختگی باشد. هنگامی که مقدار آن
true باشد، تنها برای زیرشبکه‌هایی با طول پیشوند 24 یا کوچک‌تر (یعنی
فضای آدرس بزرگ‌تر) اعمال می‌شود؛ مقدار پیش‌فرض false است.
در این حالت، "exclude" (مستثنی کردن) به معنای نادیده گرفتن این آدرس‌ها
در روال انتخاب آدرس آزاد موتور تخصیص است؛ اگر یک کلاینت صریحاً آدرسی منتهی
به .0 یا .255 را درخواست کند یا رزرو میزبانی برای آن داشته باشد، آن را دریافت
خواهد کرد.
نکته:
0.0
3.5
در ادامه برخی از اختیارات و محدودیت‌های مقادیری که زیرشبکه‌ها و استخرها
می‌توانند در پیکربندی‌های غیرمعمول Kea داشته باشند، آورده شده است:
box center;
l|l|l.
حالت پیکربندی Kea مجاز توضیح
هم‌پوشانی زیرشبکه‌ها بله مدیر سیستم باید نحوهٔ تطبیق کلاینت‌ها با این زیرشبکه‌ها را در نظر بگیرد.
هم‌پوشانی استخرها در یک زیرشبکه خیر خطای راه‌اندازی: DHCP4_PARSER_FAIL
هم‌پوشانی استخرهای آدرس در زیرشبکه‌های متفاوت بله مشخص کردن یک استخر آدرس یکسان در زیرشبکه‌های مختلف می‌تواند به عنوان معادل یک استخر آدرس سراسری (global) استفاده شود. در این حالت، کارگزار می‌تواند صرف‌نظر از زیرشبکهٔ کلاینت، آدرس‌هایی را از همان محدوده تخصیص دهد. اگر آدرسی از چنین استخری به کلاینتی در یک زیرشبکه تخصیص یابد، در صورت جابه‌جایی کلاینت به زیرشبکه‌ای دیگر، همان آدرس برای این کلاینت تمدید خواهد شد. به کلاینت دیگری در یک زیرشبکهٔ متفاوت، آدرسی که قبلاً به این کلاینت در هر یک از زیرشبکه‌ها تخصیص داده شده است، تخصیص داده نخواهد شد.
استخرهایی که با پیشوند زیرشبکه مطابقت ندارند خیر خطای راه‌اندازی: DHCP4_PARSER_FAIL


مطابق با RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131، کارگزارها باید برای T1 و T2 به ترتیب مقادیری معادل ۵۰٪ و ۸۷.۵٪ از طول‌عمر اجاره را ارسال کنند. به‌طور پیش‌فرض، kea-dhcp4 <#std-iscman-kea-dhcp4> هیچ‌یک از این مقادیر را ارسال نمی‌کند؛ می‌توان آن را طوری پیکربندی کرد که مقادیر مشخص‌شده به‌صورت صریح یا مقادیر محاسبه‌شده بر اساس درصدی از زمان اجاره را ارسال کند. رفتار کارگزار توسط ترکیبی از پارامترهای پیکربندی کنترل می‌شود که دو مورد از آن‌ها پیش‌تر ذکر شده است. برای ارسال مقادیر مشخص و ثابت از دو پارامتر زیر استفاده کنید:

  • renew-timer - مقدار T1 را بر حسب ثانیه مشخص می‌کند.
  • rebind-timer - مقدار T2 را بر حسب ثانیه مشخص می‌کند.

کارگزار تنها زمانی T2 را ارسال می‌کند که کمتر از زمان اجاره معتبر باشد. T1 تنها در صورتی ارسال می‌شود که T2 در حال ارسال بوده و T1 کمتر از T2 باشد؛ یا اینکه T2 ارسال نشود و T1 کمتر از زمان اجاره معتبر باشد.

محاسبه مقادیر توسط سه پارامتر زیر کنترل می‌شود:

  • calculate-tee-times - زمانی که true باشد، T1 و T2 به‌صورت درصدی از زمان اجاره معتبر محاسبه می‌شوند. مقدار پیش‌فرض آن false است.
  • t1-percent - درصد زمان اجاره معتبر برای استفاده در T1. این مقدار به‌صورت یک عدد حقیقی بین 0.0 و 1.0 بیان شده و باید کمتر از t2-percent باشد. مقدار پیش‌فرض آن طبق RFC 2131 برابر با 0.50 است.
  • t2-percent - درصد زمان اجاره معتبر برای استفاده در T2. این مقدار به‌صورت یک عدد حقیقی بین 0.0 و 1.0 بیان شده و باید بزرگتر از t1-percent باشد. مقدار پیش‌فرض آن طبق RFC 2131 برابر با .875 است.

نکته:

در صورتی که هم مقادیر صریح مشخص شده باشند و هم calculate-tee-times روی true تنظیم شده باشد، کارگزار از مقادیر صریح استفاده خواهد کرد. مدیرانی با ساختاری که در آن برخی زیرشبکه‌ها یا shared-networkها از مقادیر صریح و برخی از مقادیر محاسبه‌شده استفاده می‌کنند، نباید مقادیر صریح را در سطحی بالاتر از جایی که استفاده خواهند شد تعریف کنند. به ارث بردن آن‌ها از یک محدوده بیش از حد بالا، مانند محدوده سراسری (global)، باعث می‌شود در تمامی سطوح زیرین (shared-networks و زیرشبکه‌ها) دارای مقدار صریح شوند که عملاً مقادیر محاسبه‌شده را غیرفعال می‌کند.

یکی از قابلیت‌های اصلی کارگزار DHCPv4، توانایی ارائه گزینه‌های پیکربندی به کلاینت‌ها است. بیشتر گزینه‌ها تنها در صورتی توسط کارگزار ارسال می‌شوند که کلاینت صراحتاً آن‌ها را با استفاده از گزینه Parameter Request List درخواست کرده باشد. مواردی که نیازی به گنجانده شدن در گزینه Parameter Request List ندارند گزینه‌های پرکاربرد هستند، مانند "Domain Server"، و همچنین گزینه‌هایی که نیازمند رفتار خاصی هستند، مانند "Client FQDN" که در صورت قرار گرفتن در پیام ارسالی کلاینت به کارگزار، به کلاینت بازگردانده می‌شود.

«فهرست گزینه‌های استاندارد DHCPv4 قابل پیکربندی توسط مدیر»، دربرگیرنده فهرستی از گزینه‌های استاندارد DHCPv4 است که مقادیر آن‌ها را می‌توان با استفاده از ساختارهای پیکربندی شرح داده‌شده در این بخش تنظیم کرد. این جدول گزینه‌هایی را که نیازمند پردازش خاص بوده و در نتیجه نمی‌توان آن‌ها را با مقادیر ثابت پیکربندی کرد، مستثنی می‌کند. ستون آخر جدول مشخص می‌کند کدام گزینه‌ها می‌توانند حتی در صورت عدم درخواست در گزینه Parameter Request List توسط کارگزار ارسال شوند، و کدام موارد تنها در صورت درخواست صریح ارسال می‌شوند.

مثال زیر نحوه پیکربندی نشانی‌های کارگزارهای DNS را نشان می‌دهد، که یکی از پرکاربردترین گزینه‌ها است. گزینه‌هایی که به این روش تعیین می‌شوند سراسری تلقی شده و به تمام زیرشبکه‌های پیکربندی‌شده اعمال می‌شوند.

"Dhcp4": {
    "option-data": [
        {
           "name": "domain-name-servers",
           "code": 6,
           "space": "dhcp4",
           "csv-format": true,
           "data": "192.0.2.1, 192.0.2.2"
        },
        ...
    ]
}

توجه داشته باشید که تعیین یکی از دو مورد name یا code الزامی است؛ نیازی به مشخص کردن هر دوی آن‌ها نیست. space مقدار پیش‌فرض dhcp4 دارد، بنابراین در صورت تعریف یک گزینه معمولی (غیر کپسوله‌شده) DHCPv4 می‌توان از آن نیز صرف‌نظر کرد. در نهایت، مقدار پیش‌فرض csv-format برابر با true است، بنابراین می‌توان از آن نیز صرف‌نظر کرد، مگر اینکه مقدار گزینه به صورت یک رشته هگزادسیمال مشخص شود. بنابراین، مثال بالا را می‌توان به این صورت ساده کرد:

"Dhcp4": {
    "option-data": [
        {
           "name": "domain-name-servers",
           "data": "192.0.2.1, 192.0.2.2"
        },
        ...
    ]
}

گزینه‌های تعریف‌شده هنگام درخواست کلاینت به پاسخ اضافه می‌شوند، به استثنای چند مورد خاص که همواره افزوده می‌گردند. برای اجبار به افزودن یک گزینه خاص، پرچم always-send را مانند زیر روی true تنظیم کنید:

"Dhcp4": {
    "option-data": [
        {
           "name": "domain-name-servers",
           "data": "192.0.2.1, 192.0.2.2",
           "always-send": true
        },
        ...
    ]
}

اثر این کار همانند آن است که کلاینت کد گزینه را در گزینه Parameter Request List (یا معادل آن برای گزینه‌های سازنده/vendor) قرار داده باشد:

"Dhcp4": {
    "option-data": [
        {
           "name": "domain-name-servers",
           "data": "192.0.2.1, 192.0.2.2",
           "always-send": true
        },
        ...
    ],
    "subnet4": [
        {
           "subnet": "192.0.3.0/24",
           "option-data": [
               {
                   "name": "domain-name-servers",
                   "data": "192.0.3.1, 192.0.3.2"
               },
               ...
           ],
           ...
        },
        ...
    ],
    ...
}

در مثال بالا، گزینه domain-name-servers از پرچم سراسری always-send پیروی کرده و همواره به پاسخ‌ها افزوده می‌شود، اما برای زیرشبکه 192.0.3.0/24، مقدار آن از مشخصات داده‌های گزینه در سطح زیرشبکه برداشته می‌شود.

برخلاف always-send، اگر پرچم never-send برای یک گزینه خاص روی true تنظیم شود، کارگزار آن را به پاسخ اضافه نمی‌کند. اثر این کار همانند آن است که کلاینت کد گزینه را از گزینه Parameter Request List (یا معادل آن برای گزینه‌های vendor) حذف کرده باشد:

"Dhcp4": {
    "option-data": [
        {
           "name": "domain-name-servers",
           "data": "192.0.2.1, 192.0.2.2"
        },
        ...
    ],
    "subnet4": [
        {
           "subnet": "192.0.3.0/24",
           "option-data": [
               {
                   "name": "domain-name-servers",
                   "never-send": true
               },
               ...
           ],
           ...
        },
        ...
    ],
    ...
}

در مثال بالا، گزینه domain-name-servers هرگز به پاسخ‌ها در زیرشبکه 192.0.3.0/24 افزوده نمی‌شود. never-send بر always-send تقدم دارد؛ بنابراین اگر هر دو true باشند، گزینه اضافه نمی‌شود.

نکته:

پرچم‌های always-send و never-send چسبنده (sticky) هستند؛ بدین معنا که از قوانین معمول توارث پیکربندی پیروی نمی‌کنند. در عوض، اگر در طول زنجیره توارث پیکربندی حداقل یک‌بار فعال شوند، اعمال می‌گردند - حتی اگر در بخش‌های دیگری که معمولاً اولویت بالاتری دارند، غیرفعال شده باشند. برای نمونه، اگر یکی از این پرچم‌ها در محدوده سراسری فعال باشد اما در سطح زیرشبکه غیرفعال شود، با نادیده گرفتن تنظیمات سطح زیرشبکه، فعال باقی خواهد ماند.

نکته:

پرچم never-send نسبت به libdhcp_flex_option.so <#std-ischooklib-libdhcp_flex_option.so> قدرت کمتری دارد؛ برای نمونه، هیچ اثری بر گزینه‌هایی که توسط خود کارگزار مدیریت می‌شوند ندارد. هر دو پرچم always-send و never-send بر گزینه‌هایی که قابل درخواست نیستند، مانند گزینه‌های یک فضای سفارشی (custom space)، بی‌اثر هستند.

نکته:

از نسخه Kea 2.7.4 به بعد، گنجاندن گزینه‌ها را می‌توان از طریق برچسب‌گذاری کلاس گزینه نیز کنترل کرد؛ به Option Class-Tagging <#option-class-tagging> مراجعه کنید.

پارامتر name نام گزینه را مشخص می‌کند. برای مشاهده فهرستی از نام‌های پشتیبانی‌شده در حال حاضر، بخش «فهرست گزینه‌های استاندارد DHCPv4 قابل پیکربندی توسط مدیر» در زیر را ببینید. پارامتر code کد گزینه را مشخص می‌کند که باید با یکی از مقادیر آن فهرست مطابقت داشته باشد. خط بعدی فضای گزینه (option space) را مشخص می‌کند که همواره باید روی dhcp4 تنظیم شود چرا که این‌ها گزینه‌های استاندارد DHCPv4 هستند. برای سایر فضاهای گزینه، از جمله فضاهای گزینه سفارشی، به Nested DHCPv4 Options (Custom Option Spaces) مراجعه کنید. خط بعدی قالبی را مشخص می‌کند که داده‌ها در آن وارد می‌شوند؛ استفاده از CSV (مقادیر جداشده با کاما) توصیه می‌شود. خط ششم مقدار واقعی ارسال‌شونده به کلاینت‌ها را تعیین می‌کند. پارامتر data به صورت متن معمولی مشخص می‌شود و در صورتی که بیش از یک مقدار مجاز باشد، مقادیر با کاما جدا می‌شوند.

گزینه‌ها را می‌توان به‌صورت مقادیر هگزادسیمال نیز پیکربندی کرد. اگر csv-format روی false تنظیم شود، داده‌های گزینه باید به‌صورت یک رشته هگزادسیمال مشخص شوند. دستورهای زیر گزینه domain-name-servers را برای تمامی زیرشبکه‌ها با نشانی‌های روبه‌رو پیکربندی می‌کنند: 192.0.3.1 و 192.0.3.2. توجه داشته باشید که csv-format روی false تنظیم شده است.

"Dhcp4": {
    "option-data": [
        {
            "name": "domain-name-servers",
            "code": 6,
            "space": "dhcp4",
            "csv-format": false,
            "data": "C0 00 03 01 C0 00 03 02"
        },
        ...
    ],
    ...
}

سامانه Kea هنگام تعیین داده‌های هگزادسیمال از قالب‌های زیر پشتیبانی می‌کند:

Delimited octets - یک یا چند اوکتت (بایت) که با دو‌نقطه یا فاصله (":" یا " ") از یکدیگر جدا شده‌اند. گرچه هر اوکتت می‌تواند شامل یک یا دو رقم باشد، اکیداً توصیه می‌کنیم همیشه از دو رقم استفاده کنید. نمونه‌های معتبر شامل "ab:cd:ef" و "ab cd ef" هستند.
•
String of digits - یک رشته پیوسته از ارقام هگزادسیمال با یا بدون پیشوند "0x". نمونه‌های معتبر شامل "0xabcdef" و "abcdef" هستند.

هنگام استفاده از قالب هگزادسیمال باید در به‌کارگیری کدگذاری مناسب دقت شود؛ توانایی Kea در اعتبارسنجی صحت داده‌ها در قالب هگزادسیمال محدود است.

همچنین می‌توان داده‌ها را برای گزینه‌های باینری، مطابق آنچه نشان داده شده است، به صورت یک رشته متنی درون نقل‌قول تکی داخل نقل‌قول دوتایی تعیین کرد (توجه داشته باشید که csv-format باید روی false تنظیم شود):

"Dhcp4": {
    "option-data": [
        {
            "name": "user-class",
            "code": 77,
            "space": "dhcp4",
            "csv-format": false,
            "data": "'convert this text to binary'"
        },
        ...
    ],
    ...
}

بیشتر پارامترها در ساختار option-data اختیاری هستند و در برخی شرایط می‌توان از آن‌ها صرف‌نظر کرد، همان‌طور که در Unspecified Parameters for DHCPv4 Option Configuration توضیح داده شده است.

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

دستورات زیر گزینه سراسری کارسازهای DNS را برای یک زیرشبکه خاص بازنویسی کرده و یک کارساز DNS منفرد با نشانی 192.0.2.3 تعیین می‌کنند:

"Dhcp4": {
    "subnet4": [
        {
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "code": 6,
                    "space": "dhcp4",
                    "csv-format": true,
                    "data": "192.0.2.3"
                },
                ...
            ],
            ...
        },
        ...
    ],
    ...
}

در برخی موارد، مرتبط ساختن برخی گزینه‌ها با یک استخر نشانی (address pool) که به کلاینت از آن اجاره داده می‌شود، مفید است. مقادیر گزینه‌های مختص استخر، مقادیر مختص زیرشبکه و سراسری را بازنویسی می‌کنند؛ اولویت‌بندی انتساب گزینه‌های مختص استخر از طریق ترتیب اعلان استخرها در پیکربندی سرور امکان‌پذیر نیست.

قطعه‌پیکربندی زیر نحوه تعیین گزینه سرورهای DNS را نشان می‌دهد که فقط در صورتی به کلاینت اختصاص می‌یابد که کلاینت نشانی خود را از استخر داده‌شده دریافت کند:

"Dhcp4": {
    "subnet4": [
        {
            "pools": [
                {
                    "pool": "192.0.2.1 - 192.0.2.200",
                    "option-data": [
                        {
                            "name": "domain-name-servers",
                            "data": "192.0.2.3"
                         },
                         ...
                    ],
                    ...
                },
                ...
            ],
            ...
        },
        ...
    ],
    ...
}

گزینه‌ها را همچنین می‌توان در حوزه class یا host-reservation مشخص کرد. ترتیب اولویت فعلی گزینه‌ها در Kea (از بیشترین به کمترین) عبارت است از: host reservation، سپس pool، سپس subnet، سپس shared network، سپس class و در نهایت global.

هنگامی که یک فیلد داده یک رشته باشد و آن رشته حاوی نویسه کاما (,؛ U+002C) باشد، کاما باید با دو بک‌اسلش (\\,؛ U+005C) گریز داده شود (escape شود). این گریز دوتایی به این دلیل لازم است که هم روال تفکیک داده‌های CSV به فیلدها و هم JSON از نویسه گریز یکسانی استفاده می‌کنند؛ یک گریز تکی (\,) ساختار JSON را نامعتبر می‌کند. برای نمونه، رشته "foo,bar" باید به صورت زیر نمایش داده شود:

"Dhcp4": {
    "subnet4": [
        {
            "pools": [
                {
                    "option-data": [
                        {
                            "name": "boot-file-name",
                            "data": "foo\\,bar"
                        }
                    ]
                },
                ...
            ],
            ...
        },
        ...
    ],
    ...
}

برخی گزینه‌ها به صورت آرایه تعیین شده‌اند، به این معنی که بیش از یک مقدار برای آن‌ها مجاز است. به عنوان مثال، گزینه time-servers امکان تعیین بیش از یک نشانی IPv4 را فراهم می‌آورد و کلاینت‌ها را قادر می‌سازد تا نشانی‌های چندین سرور NTP را به دست آورند.

بخش Custom DHCPv4 Options نحو پیکربندی را برای ایجاد تعاریف (قالب‌های) سفارشی گزینه شرح می‌دهد. ایجاد تعاریف سفارشی برای گزینه‌های استاندارد عموماً مجاز نیست، حتی اگر تعریف ایجادشده دقیقاً با قالب واقعی گزینه که در RFCها تعریف شده مطابقت داشته باشد. با این حال، یک استثنا برای این قاعده در مورد گزینه‌های استانداردی وجود دارد که Kea در حال حاضر تعریفی برای آن‌ها ارائه نمی‌دهد. برای استفاده از چنین گزینه‌هایی، مدیر سیستم باید تعریفی را همان‌طور که در Custom DHCPv4 Options شرح داده شده، در فضای گزینه dhcp4 ایجاد کند. این تعریف باید با قالب گزینه شرح داده شده در RFC مربوطه مطابقت داشته باشد، اما سازوکار پیکربندی هر قالب گزینه‌ای را مجاز می‌داند زیرا در حال حاضر راهی برای اعتبارسنجی آن وجود ندارد.

گزینه‌های استاندارد DHCPv4 که در حال حاضر پشتیبانی می‌شوند در جدول زیر فهرست شده‌اند. "Name" و "Code" مقادیری هستند که باید به عنوان name/code در ساختارهای option-data استفاده شوند. "Type" قالب داده‌ها را مشخص می‌کند؛ معانی انواع مختلف در List of standard DHCP option types ذکر شده است..SS فهرست گزینه‌های استاندارد DHCPv4 قابل پیکربندی توسط مدیر سیستم

نام کد نوع آرایه؟ بازگردانی در صورت عدم درخواست؟
time-offset 2 int32 false false
routers 3 ipv4-address true true
time-servers 4 ipv4-address true false
name-servers 5 ipv4-address true false
domain-name-servers 6 ipv4-address true true
log-servers 7 ipv4-address true false
cookie-servers 8 ipv4-address true false
lpr-servers 9 ipv4-address true false
impress-servers 10 ipv4-address true false
resource-location-servers 11 ipv4-address true false
boot-size 13 uint16 false false
merit-dump 14 string false false
domain-name 15 fqdn false true
swap-server 16 ipv4-address false false
root-path 17 string false false
extensions-path 18 string false false
ip-forwarding 19 boolean false false
non-local-source-routing 20 boolean false false
policy-filter 21 ipv4-address true false
max-dgram-reassembly 22 uint16 false false
default-ip-ttl 23 uint8 false false
path-mtu-aging-timeout 24 uint32 false false
path-mtu-plateau-table 25 uint16 true false
interface-mtu 26 uint16 false false
all-subnets-local 27 boolean false false
broadcast-address 28 ipv4-address false false
perform-mask-discovery 29 boolean false false
mask-supplier 30 boolean false false
router-discovery 31 boolean false false
router-solicitation-address 32 ipv4-address false false
static-routes 33 ipv4-address true false
trailer-encapsulation 34 boolean false false
arp-cache-timeout 35 uint32 false false
ieee802-3-encapsulation 36 boolean false false
default-tcp-ttl 37 uint8 false false
tcp-keepalive-interval 38 uint32 false false
tcp-keepalive-garbage 39 boolean false false
nis-domain 40 string false false
nis-servers 41 ipv4-address true false
ntp-servers 42 ipv4-address true false
vendor-encapsulated-options 43 empty false false
netbios-name-servers 44 ipv4-address true false
netbios-dd-server 45 ipv4-address true false
netbios-node-type 46 uint8 false false
netbios-scope 47 string false false
font-servers 48 ipv4-address true false
x-display-manager 49 ipv4-address true false
dhcp-option-overload 52 uint8 false false
dhcp-server-identifier 54 ipv4-address false true
dhcp-message 56 string false false
dhcp-max-message-size 57 uint16 false false
vendor-class-identifier 60 string false false
nwip-domain-name 62 string false false
nwip-suboptions 63 binary false false
nisplus-domain-name 64 string false false
nisplus-servers 65 ipv4-address true false
tftp-server-name 66 string false false
boot-file-name 67 string false false
mobile-ip-home-agent 68 ipv4-address true false
smtp-server 69 ipv4-address true false
pop-server 70 ipv4-address true false
nntp-server 71 ipv4-address true false
www-server 72 ipv4-address true false
finger-server 73 ipv4-address true false
irc-server 74 ipv4-address true false
streettalk-server 75 ipv4-address true false
streettalk-directory-assistance-server 76 ipv4-address true false
user-class 77 binary false false
slp-directory-agent 78 record (boolean, ipv4-address) true false
slp-service-scope 79 record (boolean, string) false false
nds-servers 85 ipv4-address true false
nds-tree-name 86 string false false
nds-context 87 string false false
bcms-controller-names 88 fqdn true false
bcms-controller-address 89 ipv4-address true false
client-system 93 uint16 true false
client-ndi 94 record (uint8, uint8, uint8) false false
uuid-guid 97 record (uint8, binary) false false
uap-servers 98 string false false
geoconf-civic 99 binary false false
pcode 100 string false false
tcode 101 string false false
v6-only-preferred 108 uint32 false false
netinfo-server-address 112 ipv4-address true false
netinfo-server-tag 113 string false false
v4-captive-portal 114 string false false
auto-config 116 uint8 false false
name-service-search 117 uint16 true false
domain-search 119 fqdn true false
classless-static-route 121 internal false false
cablelabs-client-conf 122 empty false false
vivco-suboptions 124 record (uint32, binary) false false
vivso-suboptions 125 uint32 false false
pana-agent 136 ipv4-address true false
v4-lost 137 fqdn false false
capwap-ac-v4 138 ipv4-address true false
sip-ua-cs-domains 141 fqdn true false
v4-sztp-redirect 143 tuple true false
rdnss-selection 146 record (uint8, ipv4-address, ipv4-address, fqdn) true false
v4-portparams 159 record (uint8, psid) false false
v4-dnr 162 record (uint16, uint16, uint8, fqdn, binary) false false
option-6rd 212 record (uint8, uint8, ipv6-address, ipv4-address) true false
v4-access-domain 213 fqdn false false

می‌توانید نمونه‌ای از نحوه پیکربندی این گزینه‌ها را در kea4/all-options.json <#config-example-kea4-all-options-json> مشاهده کنید.

نکته:

گزینه default-url در Kea 2.1.2 با v4-captive-portal جایگزین شد، همان‌طور که در RFC 8910 https://datatracker.ietf.org/doc/html/rfc8910 معرفی شده است. گزینه جدید دقیقاً همان ساختار گزینه پیشین را دارد. برداشت عمومی بر این است که default-url به‌ندرت استفاده می‌شد. کاربرانی که در حال مهاجرت هستند باید default-url را در پیکربندی‌های خود با v4-captive-portal جایگزین کنند.

Kea همچنین از گزینه‌های دیگری به‌جز موارد ذکرشده در بالا پشتیبانی می‌کند؛ گزینه‌های زیر توسط خود موتور Kea بازگردانده می‌شوند و به‌طور کلی نباید به‌صورت دستی پیکربندی شوند..SS فهرست گزینه‌های استاندارد DHCPv4 که به‌طور مستقل توسط Kea مدیریت می‌شوند و مستقیماً توسط مدیر سیستم قابل پیکربندی نیستند

نام کد نوع توضیحات
subnet-mask 1 ipv4-address به‌طور خودکار، بر اساس تعریف زیرشبکه محاسبه می‌شود.
host-name 12 string توسط کلاینت ارسال می‌شود، معمولاً توسط پیکربندی DNS تعیین می‌گردد.
dhcp-requested-address 50 ipv4-address ممکن است توسط کلاینت ارسال شود و سرور نباید آن را تنظیم کند.
dhcp-lease-time 51 uint32 به‌طور خودکار بر اساس پارامتر valid-lifetime تنظیم می‌شود.
dhcp-message-type 53 string توسط کلاینت‌ها و سرورها ارسال می‌شود. بسته به شرایط توسط موتور Kea تنظیم شده و هرگز نباید به‌طور صریح پیکربندی شود.
dhcp-parameter-request-list 55 uint8 array توسط کلاینت‌ها ارسال می‌شود و هرگز نباید توسط سرور ارسال گردد.
dhcp-renewal-time 58 uint32 توسط پارامتر renew-timer تعیین می‌شود.
dhcp-rebinding-time 59 uint32 توسط پارامتر rebind-timer تعیین می‌شود.
dhcp-client-identifier 61 binary توسط کلاینت ارسال می‌شود، با مقداری که کلاینت ارسال کرده بازتاب داده می‌شود.
fqdn 81 record (uint8, uint8, uint8, fqdn) بخشی از پیکربندی DDNS و D2.
dhcp-agent-options 82 empty توسط کارگزار رله (relay agent) ارسال می‌شود. این یک گزینهٔ دربرگیرندهٔ خالی است؛ به جزئیات گزینهٔ RAI در ادامهٔ این بخش مراجعه کنید.
authenticate 90 binary توسط کلاینت ارسال می‌شود، Kea هنوز آن را اعتبارسنجی نمی‌کند.
client-last-transaction-time 91 uint32 توسط کلاینت ارسال می‌شود، سرور آن را تنظیم نمی‌کند.
associated-ip 92 ipv4-address array توسط کلاینت ارسال می‌شود، سرور با فهرستی از نشانی‌ها پاسخ می‌دهد.
subnet-selection 118 ipv4-address اگر در پیام‌های کلاینت وجود داشته باشد، در فرآیند انتخاب زیرشبکه استفاده خواهد شد.
status-code 151 record (uint8, string) توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود.
base-time 152 uint32 توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود.
start-time-of-state 153 uint32 توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود.
query-start-time 154 uint32 توسط درخواست‌کننده در طول bulk leasequery تنظیم می‌شود.
query-end-time 155 uint32 توسط درخواست‌کننده در طول bulk leasequery تنظیم می‌شود.
dhcp-state 156 uint8 توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود.
data-source 157 uint8 توسط سرور در پاسخ‌های bulk leasequery تنظیم می‌شود.

جدول زیر تمام انواع گزینه‌های استفاده‌شده در دو جدول قبلی را همراه با توضیحی دربارهٔ مقادیر قابل‌قبول برای آن‌ها فهرست می‌کند..SS "فهرست انواع استاندارد گزینه‌های DHCP (List of standard DHCP option types)"

نام مفهوم
binary یک رشته دلخواه از بایت‌ها که به‌صورت مجموعه‌ای از ارقام هگزادسیمال مشخص می‌شود.
boolean یک مقدار بولی با مقادیر مجاز true یا false.
empty بدون مقدار؛ داده‌ها در زیرگزینه‌ها (sub-options) حمل می‌شوند.
fqdn نام دامنه کاملاً واجد شرایط (مانند www.example.com).
ipv4-address آدرس IPv4 در نماد نقطه‌ـ‌ده‌دهی معمول (مانند 192.0.2.1).
ipv6-address آدرس IPv6 در نماد دونقطه‌ای معمول (مانند 2001:db8::1).
ipv6-prefix پیشوند IPv6 و طول پیشوند مشخص‌شده با نمادگذاری CIDR، مانند 2001:db8:1::/64. این نوع داده برای نمایش یک فیلد ۸ بیتی حامل طول پیشوند و مقدار پیشوند با طول متغیر استفاده می‌شود.
psid ‏PSID و طول PSID که با ممیز از یکدیگر جدا شده‌اند، مثلاً 3/4 مشخص‌کننده PSID=3 و طول PSID برابر با ۴ است. در قالب انتقال روی شبکه (wire format)، با یک فیلد ۸ بیتی حامل طول PSID (در این حالت برابر با ۴) و فیلد ۱۶ بیتی مقدار PSID (در این حالت برابر با "0011000000000000b" در نماد دودویی) نمایش داده می‌شود. مقادیر مجاز برای طول PSID بین ۰ تا ۱۶ است. برای جزئیات مربوط به قالب نمایش PSID در شبکه به RFC 7597 https://datatracker.ietf.org/doc/html/rfc7597 مراجعه کنید.
record داده‌های ساختاریافته که می‌توانند از هر نوعی (به‌جز "record" و "empty") تشکیل شوند. نشانگر (flag) آرایه فقط بر روی فیلد آخر اعمال می‌شود.
string هر نوع متن. لطفاً توجه داشته باشید که Kea هنگام باز کردن بسته‌های دریافتی، کاراکترهای نال (null) پایانی را از انتهای گزینه‌های "string" بدون هشدار حذف می‌کند. این رفتار مطابق با بخش ۲ از RFC 2132 https://datatracker.ietf.org/doc/html/rfc2132#section-2 است.
tuple یک فیلد طول که به‌صورت عدد صحیح بدون علامت ۸ یا ۱۶ بیتی کدگذاری شده و پس از آن رشته‌ای با همین طول می‌آید. معمولاً برای DHCPv4 طول ۸ بیتی و برای DHCPv6 طول ۱۶ بیتی است. با این حال، استثناهایی برای این قاعده وجود دارد؛ برای نمونه در گزینه DHCPv4 SZTP Redirect Option، مقدار bootstrap-server-list به‌صورت فهرستی از تاپل‌ها (tuples) کدگذاری می‌شود که در آن URI-length در هر تاپل یک عدد صحیح بدون علامت ۱۶ بیتی است.
uint8 یک عدد صحیح بدون علامت ۸ بیتی با مقادیر مجاز ۰ تا ۲۵۵.
uint16 یک عدد صحیح بدون علامت ۱۶ بیتی با مقادیر مجاز ۰ تا ۶۵۵۳۵.
uint32 یک عدد صحیح بدون علامت ۳۲ بیتی با مقادیر مجاز ۰ تا ۴۲۹۴۹۶۷۲۹۵.
int8 یک عدد صحیح علامت‌دار ۸ بیتی با مقادیر مجاز -128 تا 127.
int16 یک عدد صحیح علامت‌دار ۱۶ بیتی با مقادیر مجاز -32768 تا 32767.
int32 یک عدد صحیح علامت‌دار ۳۲ بیتی با مقادیر مجاز -2147483648 تا 2147483647.

نکته:

گزینه classless-static-route دارای نوع داده اختصاصی خود یعنی "internal" است و رشته‌ای با الگوی زیر را به‌عنوان مقدار می‌پذیرد: subnet1/prefix_len1 - router1, subnetN/prefix_lenN - routerN.

برای مثال: 10.229.0.128/25 - 10.229.0.1, 10.198.122.47/32 - 10.198.122.1

همچنین Kea از گزینه Relay Agent Information (اطلاعات کارگزار رله یا RAI، تعریف‌شده در RFC 3046 https://datatracker.ietf.org/doc/html/rfc3046) که گاهی اوقات relay option،‏ agent option یا به‌سادگی option 82 نامیده می‌شود، پشتیبانی می‌کند. خود این گزینه تنها یک نگه‌دارنده (container) است و به‌تنهایی هیچ اطلاعاتی را منتقل نمی‌کند. جدول زیر شامل فهرستی از زیرگزینه‌های RAI است که Kea قادر به درک آن‌هاست. گزینه RAI و زیرگزینه‌های آن توسط کارگزار رله درج شده و توسط Kea دریافت می‌شوند؛ نیازی به پیکربندی Kea با این گزینه‌ها وجود ندارد. قابلیت‌های دسته‌بندی و شناسه منعطف (flexible ID) در بخش رزروهای میزبان Kea می‌توانند برای پردازش این گزینه‌ها و سایر گزینه‌هایی که در جدول زیر ذکر نشده‌اند، مورد استفاده قرار گیرند..SS فهرست زیرگزینه‌های RAI قابل درک برای Kea

نام کد توضیحات
circuit-id 1 هنگامی استفاده می‌شود که host-reservation-identifiers روی circuit-id تنظیم شده باشد.
remote-id 2 می‌تواند همراه با flex-id برای شناسایی میزبان‌ها استفاده شود.
link-selection 5 در صورت وجود، برای انتخاب زیرشبکه مناسب استفاده می‌شود.
subscriber-id 6 می‌تواند همراه با flex-id برای شناسایی میزبان‌ها استفاده شود.
server-id-override 11 در صورت ارسال توسط رله، Kea آن را به عنوان server-id می‌پذیرد.
relay-id 12 رله را شناسایی می‌کند
relay-port 19 در صورت ارسال توسط رله، Kea پاسخ‌های خود را به این درگاه ارسال می‌کند.

تمام زیرگزینه‌های دیگر RAI (از جمله مواردی که در اینجا ذکر نشده‌اند) را می‌توان در دسته‌بندی کلاینت‌ها برای اختصاص بسته‌های ورودی به کلاس‌های خاص، و/یا توسط libdhcp_flex_id.so <#std-ischooklib-libdhcp_flex_id.so> جهت ایجاد یک شناسه دستگاه یکتا به کار برد. برای اطلاعات بیشتر درباره عبارات مورد استفاده در دسته‌بندی کلاینت و شناسه‌های انعطاف‌پذیر، «دسته‌بندی کلاینت» (Client Classification) <#classify> را ببینید. با استفاده از relay4[option-code].hex می‌توان به زیرگزینه‌های RAI ارجاع داد؛ برای نمونه، جهت دسته‌بندی بسته‌ها بر اساس remote-id (کد زیرگزینه ۲)، از relay4[2].hex استفاده می‌شود. نمونه‌ای از یک کلاس کلاینت که تمام بسته‌های دارای مقدار مشخصی از remote-id را شامل می‌شود به شکل زیر خواهد بود:

"Dhcp4": {
    "client-classes": [
        {
            "name": "remote-id-1020304",
            "test": "relay4[2].hex == 0x01020304",
            ...
        }
    ],
    ...
}

از کلاس‌ها می‌توان برای تفکیک ترافیک به تعداد نسبتاً اندکی گروه استفاده کرد که سپس برای انتخاب زیرشبکه‌ها، استخرها (pools)، گزینه‌های اضافی و موارد دیگر به کار می‌روند. در صورتی که رفتار اختصاصی به ازای هر میزبان مورد نیاز باشد، استفاده از رزروهای میزبان (host reservations) همراه با شناسه‌های انعطاف‌پذیر اکیداً توصیه می‌شود.

گزینه پیکربندی کلاینت کیبل‌لبز ("cablelabs-client-conf" با کد ۱۲۲) حاوی زیرگزینه‌هایی در فضای "cablelabs-client-conf" است که در جدول زیر فهرست شده‌اند.

نام کد قالب
tsp-primary-server 1 آدرس IPv4
tsp-secondary-server 2 آدرس IPv4
tsp-as-parameters 4 رکوردی متشکل از ۳ مقدار uint32
tsp-ap-parameters 5 رکوردی متشکل از ۳ مقدار uint32
tsp-realm 6 نام دامنه کاملاً مشخص (FQDN)
tsp-use-tgt 7 بولی (boolean)
tsp-provisioning-timer 8 uint8
tsp-sct 9 uint16
kdc-server 10 آرایه‌ای از آدرس‌های IPv4

این زیرگزینه‌ها در RFC 3495 https://datatracker.ietf.org/doc/html/rfc3495 (شامل اصلاحیه آن که قالب realm را مشخص می‌کند)، RFC 3594 https://datatracker.ietf.org/doc/html/rfc3594 و RFC 3634 https://datatracker.ietf.org/doc/html/rfc3634 تعریف شده‌اند.

نکته:

زیرگزینه ۳ آدرس کارساز تامین TSP را یا به صورت آدرس IPv4 یا به صورت FQDN حمل می‌کند. این مورد را نمی‌توان در Kea تعریف کرد، بنابراین هیچ زیرگزینه استانداردی برای کد ۳ تعریف نشده است و این انتخاب باقی می‌ماند که محتوای آن به صورت یک مقدار باینری پیکربندی شود، یا اگر فقط به عنوان یک آدرس IPv4 یا FQDN استفاده می‌شود، به صورت رکوردی از یک uint8 (تنظیم‌شده روی 0) و ipv4-address، یا رکوردی از یک uint8 (تنظیم‌شده روی 1) و یک fqdn تعریف شود تا امکان استفاده از داده‌های با قالب CSV فراهم گردد.

Kea از گزینه‌های سفارشی (غیر استاندارد) DHCPv4 پشتیبانی می‌کند. فرض کنید می‌خواهیم یک گزینهٔ جدید DHCPv4 به نام foo تعریف کنیم که دارای کد 222 بوده و حامل یک مقدار عدد صحیح بی‌علامت 32 بیتی منفرد باشد. چنین گزینه‌ای را می‌توان با قرار دادن ورودی زیر در فایل پیکربندی تعریف کرد:

"Dhcp4": {
    "option-def": [
        {
            "name": "foo",
            "code": 222,
            "type": "uint32",
            "array": false,
            "record-types": "",
            "space": "dhcp4",
            "encapsulate": ""
        },
        ...
    ],
    ...
}

مقدار false برای پارامتر array مشخص می‌کند که این گزینه شامل آرایه‌ای از مقادیر uint32 نیست، بلکه در عوض یک مقدار منفرد است. دو پارامتر دیگر خالی گذاشته شده‌اند: record-types و encapsulate. پارامتر اول، در صورتی که گزینه شامل رکوردی از فیلدهای داده باشد، فهرستی جداشده با کاما از فیلدهای دادهٔ گزینه را مشخص می‌کند. مقدار record-types در صورتی که type بر روی "record" تنظیم شده باشد باید غیرخالی باشد؛ در غیر این صورت باید خالی بماند. پارامتر دوم، نام فضای گزینه‌ای را تعیین می‌کند که توسط این گزینهٔ خاص کپسوله‌سازی می‌شود. اگر این گزینهٔ خاص هیچ فضای گزینه‌ای را کپسوله‌سازی نمی‌کند، این پارامتر باید خالی رها شود. توجه داشته باشید که عبارت پیکربندی option-def تنها قالب یک گزینه را تعریف می‌کند و مقدار (یا مقادیر) آن را تنظیم نمی‌نماید.

پارامترهای name، code و type الزامی هستند؛ سایر پارامترها اختیاری می‌باشند. مقدار پیش‌فرض پارامتر array برابر با false است. مقادیر پیش‌فرض پارامترهای record-types و encapsulate خالی ("") می‌باشند. مقدار پیش‌فرض space برابر با dhcp4 است.

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

"Dhcp4": {
    "option-data": [
        {
            "name": "foo",
            "code": 222,
            "space": "dhcp4",
            "csv-format": true,
            "data": "12345"
        },
        ...
    ],
    ...
}

گزینه‌های جدید می‌توانند اَشکال پیچیده‌تری نسبت به استفادهٔ ساده از انواع اولیه (مانند uint8، string، ipv4-address و غیره) به خود بگیرند؛ امکان تعریف گزینه‌ای متشکل از چندین نوع اولیهٔ موجود وجود دارد.

برای مثال، فرض کنید می‌خواهیم گزینهٔ جدیدی تعریف کنیم که متشکل از یک نشانی IPv4، به دنبال آن یک عدد صحیح بی‌علامت 16 بیتی، سپس یک مقدار بولی (boolean) و در ادامه یک رشتهٔ متنی باشد. چنین گزینه‌ای را می‌توان به شیوهٔ زیر تعریف کرد:

"Dhcp4": {
    "option-def": [
        {
            "name": "bar",
            "code": 223,
            "space": "dhcp4",
            "type": "record",
            "array": false,
            "record-types": "ipv4-address, uint16, boolean, string",
            "encapsulate": ""
        },
        ...
    ],
    ...
}

پارامتر type بر روی "record" تنظیم شده است تا نشان دهد که این گزینه شامل چندین مقدار از انواع مختلف است. این نوع‌ها به‌صورت یک فهرست جداشده با کاما در فیلد record-types مشخص می‌شوند و باید از میان موارد فهرست‌شده در «فهرست انواع استاندارد گزینه‌های DHCP» (List of standard DHCP option types) باشند.

مقادیر گزینه در یک عبارت option-data به شرح زیر تنظیم می‌شوند:

"Dhcp4": {
    "option-data": [
        {
            "name": "bar",
            "space": "dhcp4",
            "code": 223,
            "csv-format": true,
            "data": "192.0.2.100, 123, true, Hello World"
        }
    ],
    ...
}

پارامتر csv-format بر روی true تنظیم می‌شود تا نشان دهد فیلد data شامل فهرستی از مقادیر جداشده با کاما است. مقادیر موجود در data باید با نوع‌های تعیین‌شده در فیلد record-types از تعریف گزینه مطابقت داشته باشند.

هنگامی که array بر روی true و type بر روی "record" تنظیم شود، فیلد پایانی یک آرایه خواهد بود؛ به این معنی که می‌تواند بیش از یک مقدار را شامل شود، مانند:

"Dhcp4": {
    "option-def": [
        {
            "name": "bar",
            "code": 223,
            "space": "dhcp4",
            "type": "record",
            "array": true,
            "record-types": "ipv4-address, uint16",
            "encapsulate": ""
        },
        ...
    ],
    ...
}

محتوای گزینهٔ جدید، یک نشانی IPv4 و در پی آن یک یا چند عدد صحیح بی‌علامت 16 بیتی خواهد بود.

نکته:

به‌طور کلی، مقادیر بولی به‌صورت true یا false، بدون نقل‌قول مشخص می‌شوند. برخی پارامترهای بولی خاص ممکن است "true"، "false"، 0، 1، "0" و "1" را نیز بپذیرند.

نکته:

اعداد را می‌توان در قالب ده‌دهی (decimal) یا هگزادسیمال (hexadecimal) مشخص کرد. قالب هگزادسیمال می‌تواند به‌صورت ساده (مانند abcd) یا با پیشوند 0x (مانند 0xabcd) باشد.

گزینه‌های دارای کدی بین 224 و 254 برای استفادهٔ خصوصی رزرو شده‌اند. می‌توان آن‌ها را در حوزهٔ سراسری (global scope) یا در حوزهٔ محلی client-class تعریف کرد؛ این امر امکان استفاده از تعاریف گزینه‌ها را بسته به زمینه (context) فراهم کرده و داده‌های گزینه نیز متناسب با آن تنظیم می‌شوند. برای نمونه، جهت پیکربندی یک سازندهٔ قدیمی PXEClient:

"Dhcp4": {
    "client-classes": [
        {
            "name": "pxeclient",
            "test": "option[vendor-class-identifier].text == 'PXEClient'",
            "option-def": [
                {
                    "name": "configfile",
                    "code": 209,
                    "type": "string"
                }
            ],
            ...
        },
        ...
    ],
    ...
}

از آنجا که گزینهٔ Vendor-Specific Information (VSI) (کد 43) قالبی مختص سازنده (vendor-specific) دارد، یعنی می‌تواند حامل یک مقدار باینری خام یا زیرگزینه‌ها (sub-options) باشد، این سازوکار برای این گزینه نیز در دسترس است.

در مثال زیر که از یک پیکربندی واقعی برداشته شده است، دو کلاس سازنده از گزینهٔ 43 برای اهدافی متفاوت و ناسازگار استفاده می‌کنند:

"Dhcp4": {
    "option-def": [
        {
            "name": "cookie",
            "code": 1,
            "type": "string",
            "space": "APC"
        },
        {
            "name": "mtftp-ip",
            "code": 1,
            "type": "ipv4-address",
            "space": "PXE"
        },
        ...
    ],
    "client-classes": [
        {
            "name": "APC",
            "test": "option[vendor-class-identifier].text == 'APC'",
            "option-def": [
                {
                    "name": "vendor-encapsulated-options",
                    "type": "empty",
                    "encapsulate": "APC"
                }
            ],
            "option-data": [
                {
                    "name": "cookie",
                    "space": "APC",
                    "data": "1APC"
                },
                {
                    "name": "vendor-encapsulated-options"
                },
                ...
            ],
            ...
        },
        {
            "name": "PXE",
            "test": "option[vendor-class-identifier].text == 'PXE'",
            "option-def": [
                {
                    "name": "vendor-encapsulated-options",
                    "type": "empty",
                    "encapsulate": "PXE"
                }
            ],
            "option-data": [
                {
                    "name": "mtftp-ip",
                    "space": "PXE",
                    "data": "0.0.0.0"
                },
                {
                    "name": "vendor-encapsulated-options"
                },
                ...
            ],
            ...
        },
        ...
    ],
    ...
}

تعریف مورداستفاده برای رمزگشایی (decode) یک گزینهٔ VSI به شرح زیر است:

1.
تعریف محلی کلاس کلاینتی که بستهٔ ورودی به آن تعلق دارد؛
2.
در صورت عدم وجود، تعریف سراسری (global)؛
3.
در صورت عدم وجود، تعریف آخرین راه‌حل (last-resort) توصیف‌شده در بخش بعدی، DHCPv4 Vendor-Specific Options (سازگار با نسخه‌های قبلی Kea).

نکته:

این تعریف آخرین راه‌حل برای گزینهٔ Vendor-Specific Information (کد 43) با مقادیر باینری خام سازگار نیست. در مواردی که مشخص است یک مقدار باینری خام استفاده خواهد شد، باید یک client class تعریف شود که هم شامل یک عبارت دسته‌بندی مطابق با این موارد و هم یک تعریف گزینه برای گزینهٔ VSI با نوع binary و بدون کپسوله‌سازی (encapsulation) باشد.

نکته:

به‌طور پیش‌فرض، در گزینهٔ Vendor-Specific Information (کد 43)، کدهای زیرگزینهٔ 0 و 255 بر اساس RFC 2132 https://datatracker.ietf.org/doc/html/rfc2132 به ترتیب به معنای PAD و END هستند. به بیان دیگر، مقادیر کد زیرگزینهٔ 0 و 255 رزرو شده‌اند. با این حال، Kea به کاربران اجازه می‌دهد کدهای زیرگزینه را از 0 تا 255 تعریف کنند. در صورتی که زیرگزینه‌هایی با کدهای 0 و/یا 255 تعریف شوند، بایت‌های دارای آن مقدار هنگام تجزیهٔ یک گزینهٔ VSI در یک پرس‌وجوی ورودی، دیگر به عنوان PAD یا END در نظر گرفته نشده، بلکه به عنوان کد زیرگزینه تلقی می‌شوند.

پردازش ورودی گزینهٔ 43 (که باز کردن بسته یا unpacking نیز نامیده می‌شود) به تعویق می‌افتد تا پس از مرحلهٔ دسته‌بندی (classification) انجام شود. این بدان معناست که کلاینت‌ها را نمی‌توان با استفاده از زیرگزینه‌های گزینهٔ 43 دسته‌بندی کرد. تعریفی که برای unpack کردن گزینهٔ 43 استفاده می‌شود به صورت زیر تعیین می‌گردد:

  • اگر در حوزهٔ سراسری تعریف شده باشد، از این تعریف استفاده می‌شود.
  • اگر در حوزهٔ client class تعریف شده باشد و بسته به این کلاس تعلق داشته باشد، از تعریف client class استفاده می‌شود.
  • اگر نه در حوزهٔ سراسری و نه در یک client class که بسته به آن تعلق دارد تعریف نشده باشد، از تعریف پیش‌ساختهٔ آخرین راه‌حل استفاده می‌شود. این تعریف صرفاً بیان می‌کند که فضای زیرگزینه برابر با "vendor-encapsulated-options-space" است.

انتخاب تعریف خروجی کمی ساده‌تر است:

  • اگر بسته به یک client class تعلق داشته باشد که گزینهٔ 43 را تعریف کرده است، از این تعریف استفاده شود.
  • اگر در حوزهٔ سراسری تعریف شده باشد، از این تعریف استفاده شود.
  • در غیر این صورت، از تعریف پیش‌ساختهٔ آخرین راه‌حل استفاده شود.

از آنجا که زیرگزینه‌ها از یک فضای گزینهٔ خاص/به‌ازای هر سازنده (per vendor) استفاده می‌کنند، در حوزهٔ سراسری تعریف می‌شوند.

نکته:

تعاریف گزینه در کلاس‌های کلاینت تنها برای این مجموعه گزینهٔ محدود (کدهای 43 و از 224 تا 254)، و فقط برای DHCPv4 مجاز است.

نکته:

همچنین بازتعریف برخی از گزینه‌های استاندارد در Kea، از طریق قلاب (hook) مربوط به libdhcp_flex_option.so: Flexible Option Actions for Option Value Settings <#hooks-flex-option> امکان‌پذیر است. نمونه‌هایی از این سازوکار در این مقالهٔ پایگاه دانش (Knowledgebase) موجود است: https://kb.isc.org/docs/redefining-standard-options.

در حال حاضر دو فضای گزینه (option space) برای kea-dhcp4 <#std-iscman-kea-dhcp4> تعریف شده است: dhcp4 (برای گزینه‌های سطح بالای DHCPv4) و "vendor-encapsulated-options-space"، که به‌طور پیش‌فرض خالی است اما می‌توان گزینه‌هایی را در آن تعریف کرد. این گزینه‌ها در گزینهٔ اطلاعات اختصاصی سازنده (Vendor-Specific Information - کد 43) حمل می‌شوند. مثال‌های زیر نحوهٔ تعریف گزینهٔ foo با کد 1 را نشان می‌دهند که شامل یک آدرس IPv4، یک عدد صحیح بی‌علامت ۱۶ بیتی، و یک رشته است. گزینهٔ foo در یک گزینهٔ Vendor-Specific Information منتقل می‌شود.

گام نخست، تعریف قالب گزینه است:

"Dhcp4": {
    "option-def": [
        {
            "name": "foo",
            "code": 1,
            "space": "vendor-encapsulated-options-space",
            "type": "record",
            "array": false,
            "record-types": "ipv4-address, uint16, string",
            "encapsulate": ""
        }
    ],
    ...
}

توجه داشته باشید که فضای گزینه روی "vendor-encapsulated-options-space" تنظیم شده است. پس از تعریف قالب گزینه، گام بعدی تعیین مقادیر واقعی برای آن گزینه است:

"Dhcp4": {
    "option-data": [
        {
            "name": "foo",
            "space": "vendor-encapsulated-options-space",
            "code": 1,
            "csv-format": true,
            "data": "192.0.2.3, 123, Hello World"
        }
    ],
    ...
}

در این مثال، ما گزینهٔ Vendor-Specific Information را نیز که حامل زیرگزینهٔ foo ما است می‌گنجانیم. این کار الزامی است؛ در غیر این صورت، گزینه در پیام‌های ارسال‌شده به کلاینت قرار نخواهد گرفت.

"Dhcp4": {
    "option-data": [
        {
            "name": "vendor-encapsulated-options"
        }
    ],
    ...
}

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

"Dhcp4": {
    "option-data": [
        {
            "code": 43
        }
    ],
    ...
}

گزینهٔ پرکاربرد دیگری که معمولاً تا حدی نادقیق "vendor option" نامیده می‌شود، گزینهٔ 125 است. نام درست آن "vendor-independent vendor-specific information option" یا "vivso" است. ایدهٔ پشت گزینه‌های vivso این است که هر سازنده مجموعهٔ منحصربه‌فردی از گزینه‌ها را با قالب‌های سفارشی خود دارد. سازنده با یک عدد صحیح بی‌علامت ۳۲ بیتی به نام enterprise-number یا vendor-id شناسایی می‌شود.

فضاهای استانداردی که در Kea تعریف شده‌اند و گزینه‌های آن‌ها عبارتند از:

•
vendor-4491: متعلق به Cable Television Laboratories, Inc. برای گزینه‌های DOCSIS3:
کد گزینه نام گزینه توضیحات گزینه
1 oro مخفف ORO (یا Option Request Option)، که توسط کلاینت‌ها برای درخواست فهرستی از گزینه‌های مورد نظرشان استفاده می‌شود.
2 tftp-servers فهرستی از آدرس‌های IPv4 سرورهای TFTP که باید توسط مودم کابلی استفاده شوند.

در Kea، هر سازنده با فضای سازنده (vendor space) خاص خود مشخص می‌شود. از آنجا که صدها سازنده وجود دارند و گاهی برای سخت‌افزارهای مختلف از تعاریف گزینه‌های متفاوتی استفاده می‌کنند، پشتیبانی توکار Kea از همهٔ آن‌ها غیرممکن است. خوشبختانه، تعریف پشتیبانی برای گزینه‌های سازندگان جدید آسان است. به عنوان مثال، دستگاه درگاه خانگی (home gateway) شرکت Genexis نیازمند آن است که گزینهٔ vivso 125 همراه با زیرگزینهٔ 2 که حاوی رشته‌ای شامل URL سرور TFTP است ارسال شود. برای پشتیبانی از چنین دستگاهی سه مرحله لازم است: نخست، ایجاد تعاریف گزینه که مشخص می‌کند ساختار گزینه چگونه باید باشد؛ دوم، تعیین مقادیر گزینه؛ و سوم، مشخص کردن زمان ارسال آن گزینه‌های خاص برای Kea از طریق دسته‌بندی کلاینت (client classification).

یک نمونه قطعه از پیکربندی می‌تواند شبیه به مورد زیر باشد:

"Dhcp4": {
    // First, we need to define that the sub-option 2 in vivso option for
    // vendor-id 25167 has a specific format (it's a plain string in this example).
    // After this definition, we can specify values for option tftp.
    "option-def": [
        {
            // We define a short name, so the option can be referenced by name.
            // The option has code 2 and resides within vendor space 25167.
            // Its data is a plain string.
            "name": "tftp",
            "code": 2,
            "space": "vendor-25167",
            "type": "string"
        }
    ],
    "client-classes": [
        {
            // We now need to tell Kea how to recognize when to use vendor space 25167.
            // Usually we can use a simple expression, such as checking if the device
            // sent a vivso option with specific vendor-id, e.g. "vendor[4491].exists".
            // Unfortunately, Genexis is a bit unusual in this aspect, because it
            // doesn't send vivso. In this case we need to look into the vendor class
            // (option code 60) and see if there's a specific string that identifies
            // the device. Alternatively, one can make use of the automated `VENDOR_CLASS_`
            // client class and replace "name" and "test" with `"name": "VENDOR_CLASS_HMC1000"`
            // and no test expression.
            "name": "cpe_genexis",
            "test": "substring(option[60].hex,0,7) == 'HMC1000'",
            // Once the device is recognized, we want to send two options:
            // the vivso option with vendor-id set to 25167, and a sub-option 2.
            "option-data": [
                {
                    "name": "vivso-suboptions",
                    "data": "25167"
                },
                // The sub-option 2 value is defined as any other option. However,
                // we want to send this sub-option 2, even when the client didn't
                // explicitly request it (often there is no way to do that for
                // vendor options). Therefore we use always-send to force Kea
                // to always send this option when 25167 vendor space is involved.
                {
                    "name": "tftp",
                    "space": "vendor-25167",
                    "data": "tftp://192.0.2.1/genexis/HMC1000.v1.3.0-R.img",
                    "always-send": true
                }
            ]
        }
    ]
}

به‌طور پیش‌فرض، Kea تنها گزینه‌هایی را بازمی‌گرداند که توسط کلاینت درخواست شده باشند، مگر اینکه قواعد پروتکل به سرور DHCP دستور دهند که همواره گزینه‌ای را ارسال کند. این رویکرد در بیشتر موارد به‌خوبی عمل می‌کند و مانع از بروز مشکلاتی می‌شود که کلاینت‌ها پاسخ‌های حاوی گزینه‌های ناشناخته را رد می‌کنند. با این حال، وضعیت گزینه‌های سازنده پیچیده‌تر است، زیرا این گزینه‌ها مشابه سایر گزینه‌ها درخواست نمی‌شوند، در RFCهای رسمی به‌خوبی مستند نشده‌اند، یا بسته به سازنده متفاوت هستند.

برخی سازندگان (مانند DOCSIS که با گزینهٔ سازندهٔ 4491 مشخص می‌شود) سازوکاری برای درخواست گزینه‌های خاص سازنده دارند و Kea قادر است آن‌ها را رعایت کند (زیرگزینهٔ 1). متأسفانه برای بسیاری از سازندگان دیگر، مانند Genexis (شمارهٔ 25167 که در بالا بررسی شد)، Kea چنین سازوکاری ندارد، بنابراین نمی‌تواند هیچ زیرگزینه‌ای را به‌خودی‌خود ارسال کند. برای حل این مشکل، مفهوم گزینه‌های پایدار (persistent options) ابداع شده است. می‌توان به Kea دستور داد که گزینه‌ها را همیشه ارسال کند، حتی اگر کلاینت آن‌ها را درخواست نکرده باشد. این کار با افزودن "always-send": true به ورودی داده‌های گزینه امکان‌پذیر است. توجه داشته باشید که در این مورد خاص، گزینه‌ای در فضای سازندهٔ 25167 تعریف شده است. با فعال بودن always-send، هر بار که نیازی به تعامل با فضای سازندهٔ 25167 باشد، این گزینه ارسال می‌شود.

همچنین به همین شیوه می‌توان kea-dhcp4 <#std-iscman-kea-dhcp4> را برای ارسال چندین گزینهٔ سازنده از سازندگان مختلف، به همراه شناسهٔ سازندهٔ ویژهٔ هر کدام پیکربندی کرد. اگر لازم است این گزینه‌ها بدون توجه به اینکه کلاینت شمارهٔ سازمانی (enterprise number) را مشخص کرده باشد یا خیر توسط سرور ارسال شوند، باید "always-send": true برای زیرگزینه‌هایی که درون گزینهٔ vivso-suboptions (کد 125) قرار می‌گیرند پیکربندی شود.

"Dhcp4": {
    "option-data": [
        # Typically DHCPv4 clients will send a Parameter Request List option (code 55) for
        # vivso-suboptions (code 125), and that is enough for Kea to understand that it needs to
        # send the option. These options still need to be defined in the configuration, one per
        # each vendor, but they don't need "always-send" enabled in that case. For misbehaving
        # clients that do not explicitly request it, one may alternatively set "always-send"
        # to true for them as well. This is referring to the following two entries in option-data.
        {
            "name": "vivso-suboptions",
            "space": "dhcp4",
            "data": "2234"
        },
        {
            "name": "vivso-suboptions",
            "space": "dhcp4",
            "data": "3561"
        },
        {
            "always-send": true,
            "data": "tagged",
            "name": "tag",
            "space": "vendor-2234"
        },
        {
            "always-send": true,
            "data": "https://example.com:1234/path",
            "name": "url",
            "space": "vendor-3561"
        }
    ],
    "option-def": [
        {
            "code": 22,
            "name": "tag",
            "space": "vendor-2234",
            "type": "string"
        },
        {
            "code": 11,
            "name": "url",
            "space": "vendor-3561",
            "type": "string"
        }
    ]
}

امکان دیگر بازتعریف گزینه است؛ بخش «DHCPv4 Private Options» را ببینید.

‏Kea به همراه چند فایل پیکربندی نمونه ارائه می‌شود. برخی از آن‌ها نحوهٔ پیکربندی گزینه‌های 60 و 43 را نشان می‌دهند. فایل‌های kea4/vendor-specific.json <#config-example-kea4-vendor-specific-json> و kea4/vivso.json <#config-example-kea4-vivso-json> را ببینید.

نکته:

kea-dhcp4 <#std-iscman-kea-dhcp4> قادر است چندین گزینهٔ Vendor Class Identifier (کد 60) با شناسه‌های سازندهٔ مختلف را در درخواست‌های کلاینت تشخیص داده و چندین گزینهٔ vivso (کد 125) را در پاسخ‌ها، یکی به ازای هر سازنده، ارسال کند.

kea-dhcp4 <#std-iscman-kea-dhcp4> زیرگزینهٔ 1 در DOCSIS (یعنی ORO) را رعایت می‌کند و تنها در صورتی که این زیرگزینه در درخواست کلاینت موجود باشد، گزینه‌های درخواست‌شده را اضافه می‌نماید.

در حال حاضر تنها از یک سازنده برای گزینهٔ vivco-suboptions (کد 124) پشتیبانی می‌شود. مشخص کردن چندین شمارهٔ سازمانی درون یک نمونه از گزینه یا چندین گزینه با شماره‌های سازمانی مختلف پشتیبانی نمی‌شود.

گاهی اوقات تعریف یک فضای گزینه کاملاً جدید سودمند است، مانند زمانی که کاربر گزینه جدیدی را در فضای استاندارد گزینه (dhcp4) ایجاد می‌کند و می‌خواهد این گزینه زیرگزینه‌ها (sub-options) را منتقل کند. از آنجا که زیرگزینه‌ها در یک فضای جداگانه قرار دارند، کدهای آن‌ها از یک طرح شماره‌گذاری مجزا پیروی می‌کنند و ممکن است با کدهای گزینه‌های استاندارد هم‌پوشانی داشته باشند.

توجه داشته باشید که هنگام تعریف زیرگزینه‌ها برای یک گزینه استاندارد، نیازی به ایجاد فضای گزینه جدید نیست؛ چرا که اگر گزینه استاندارد قرار باشد زیرگزینه‌هایی را منتقل کند، به طور پیش‌فرض یک فضا ایجاد می‌شود (بخش DHCPv4 Vendor-Specific Options را ببینید).

اگر یک گزینه DHCPv4 به نام container با کد 222 بخواهیم که دو زیرگزینه با کدهای 1 و 2 را منتقل کند، ابتدا باید زیرگزینه‌های جدید را تعریف کنیم:

"Dhcp4": {
    "option-def": [
        {
            "name": "subopt1",
            "code": 1,
            "space": "isc",
            "type": "ipv4-address",
            "record-types": "",
            "array": false,
            "encapsulate": ""
        },
        {
            "name": "subopt2",
            "code": 2,
            "space": "isc",
            "type": "string",
            "record-types": "",
            "array": false,
            "encapsulate": ""
        }
    ],
    ...
}

توجه داشته باشید که ما گزینه‌ها را طوری تعریف کرده‌ایم که متعلق به یک فضای گزینه جدید باشند (در این مورد، "isc").

مرحله بعد، تعریف یک گزینه معمولی DHCPv4 با کد مورد نظر و مشخص کردن این است که باید شامل گزینه‌هایی از فضای گزینه جدید باشد:

"Dhcp4": {
    "option-def": [
        {
            "name": "container",
            "code": 222,
            "space": "dhcp4",
            "type": "empty",
            "array": false,
            "record-types": "",
            "encapsulate": "isc"
        },
        ...
    ],
    ...
}

نام فضای گزینه‌ای که زیرگزینه‌ها در آن تعریف شده‌اند در فیلد encapsulate تنظیم می‌شود. فیلد type روی "empty" تنظیم می‌شود تا نشان دهد این گزینه هیچ داده‌ای به جز زیرگزینه‌ها را حمل نمی‌کند.

در نهایت، می‌توانیم مقادیر گزینه‌های جدید را مقداردهی کنیم:

{
  "Dhcp4": {
    "option-data": [
        {
            "name": "subopt1",
            "code": 1,
            "space": "isc",
            "data": "192.0.2.3"
        },
        {
            "name": "subopt2",
            "code": 2,
            "space": "isc",
            "data": "Hello world"
        },
        {
            "name": "container",
            "code": 222,
            "space": "dhcp4"
        }
    ]
  }
}

امکان ایجاد گزینه‌ای که علاوه بر زیرگزینه‌های تعریف‌شده در فضای گزینه کپسوله‌شده، داده‌هایی را نیز با خود حمل کند وجود دارد. برای مثال، اگر در نمونه قبلی نیاز بود که گزینه container علاوه بر زیرگزینه‌ها یک مقدار uint16 را نیز انتقال دهد، مقدار type در تعریف گزینه باید روی "uint16" تنظیم می‌شد. (چنین گزینه‌ای در این صورت ساختار داده‌ای به این شکل خواهد داشت: سربرگ DHCP، مقدار uint16، زیرگزینه‌ها.) سپس مقداری که با پارامتر data مشخص می‌شود — که باید یک عدد صحیح معتبر داخل نقل‌قول باشد، مانند "123" — به فیلد uint16 در گزینه container اختصاص می‌یابد..SS پارامترهای مشخص‌نشده برای پیکربندی گزینه DHCPv4

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

  • name - سرور برای شناسایی یک گزینه، به نام گزینه یا کد گزینه نیاز دارد. اگر این پارامتر مشخص نشده باشد، کد گزینه باید تعیین شود.
  • code - سرور برای شناسایی یک گزینه به نام یا کد گزینه نیاز دارد؛ در صورتی که پارامتر name مشخص شده باشد، این پارامتر می‌تواند تعیین‌نشده باقی بماند. با این حال، این امر همچنین مستلزم آن است که گزینه مورد نظر تعریفی داشته باشد (چه به عنوان یک گزینه استاندارد یا تعریفی که توسط مدیر سیستم برای گزینه و با استفاده از ساختار option-def ایجاد شده باشد)، زیرا تعریف گزینه، آن را به نامی مشخص مرتبط می‌سازد. امکان پیکربندی گزینه‌ای که برای آن تعریفی وجود ندارد (قالب گزینه نامشخص) وجود دارد. پیکربندی چنین گزینه‌هایی مستلزم استفاده از کد گزینه است.
  • space - اگر فضای گزینه مشخص نشده باشد، مقدار پیش‌فرض آن dhcp4 خواهد بود که فضای گزینه‌ای حاوی گزینه‌های استاندارد DHCPv4 است.
  • data - اگر داده‌های گزینه مشخص نشده باشد، مقدار پیش‌فرض آن تهی خواهد بود. مقدار تهی عمدتاً برای گزینه‌های فاقد بار داده (گزینه‌های بولی / boolean) استفاده می‌شود، اما تعیین مقادیر تهی برای برخی از گزینه‌های حامل داده با طول متغیر که استاندارد آن‌ها طول ۰ را مجاز می‌داند، قانونی و معتبر است. برای چنین گزینه‌هایی، پارامتر data می‌تواند در پیکربندی حذف شود.
  • csv-format - اگر این مقدار مشخص نشود، سرور فرض می‌کند که داده‌های گزینه به صورت فهرستی از مقادیر جداشده با کاما برای انتساب به فیلدهای منفرد گزینه DHCP مشخص شده‌اند.

سرور kea-dhcp4 <#std-iscman-kea-dhcp4> تا حدی از گزینه‌های طولانی (RFC 3396) پشتیبانی می‌کند. از نسخه Kea 2.1.6، سرور پیکربندی گزینه‌ها و زیرگزینه‌های طولانی (بیشتر از ۲۵۵ بایت) را می‌پذیرد. گزینه‌ها و زیرگزینه‌ها به صورت داخلی در قالب بسته‌بندی‌نشده (unwrapped) خود ذخیره می‌شوند و می‌توان آن‌ها را طبق معمول با استفاده از زبان تجزیه‌گر پردازش کرد. در هنگام ارسال، سرور گزینه‌ها و زیرگزینه‌های طولانی را با استفاده از کد گزینه مربوطه، به چندین گزینه و زیرگزینه تقسیم می‌کند.

{
"option-def": [
    {
        "array": false,
        "code": 240,
        "encapsulate": "",
        "name": "my-option",
        "space": "dhcp4",
        "type": "string"
    }
],
"subnet4": [
    {
        "id": 1,
        "subnet": "192.0.2.0/24",
        "reservations": [
            {
                "hw-address": "aa:bb:cc:dd:ee:ff",
                "option-data": [
                    {
                        "always-send": false,
                        "code": 240,
                        "name": "my-option",
                        "csv-format": true,
                        "data": "data \
                                 -00010203040506070809-00010203040506070809-00010203040506070809-00010203040506070809 \
                                 -00010203040506070809-00010203040506070809-00010203040506070809-00010203040506070809 \
                                 -00010203040506070809-00010203040506070809-00010203040506070809-00010203040506070809 \
                                 -data",
                        "space": "dhcp4"
                    }
                ]
            }
        ]
    }
],
...
}

نکته:

در مثال بالا، داده‌ها برای وضوح بیشتر در چند خط شکسته شده‌اند، اما Kea از شکستن خطوط در فایل پیکربندی پشتیبانی نمی‌کند.

این مثال پیکربندی یک گزینه طولانی سفارشی (بیش از ۲۵۵ بایت) را در یک رزرو نشان می‌دهد. هنگام ارسال پاسخ، سرور این گزینه را به دو گزینه تقسیم می‌کند که هر کدام دارای کد ۲۴۰ هستند.

نکته:

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

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

گزینه v6-only-preferred (کد ۱۰۸) در صورتی که در یک زیرشبکه یا یک شبکه اشتراکی پیکربندی شده باشد، توسط kea-dhcp4 <#std-iscman-kea-dhcp4> به شیوه خاصی که در RFC 8925 https://datatracker.ietf.org/doc/html/rfc8925 شرح داده شده است مدیریت می‌شود: هنگامی که کلاینت این گزینه را درخواست می‌کند (یعنی کد ۱۰۸ را در گزینه فهرست درخواست پارامترهای DHCP قرار می‌دهد) و زیرشبکه یا شبکه اشتراکی انتخاب می‌شود، آدرس 0.0.0.0 پیشنهاد شده و گزینه در پاسخ بازگردانده می‌شود..SS پیکربندی بی‌حالت کارخواه‌های DHCPv4

کارساز DHCPv4 از پیکربندی بی‌حالت (stateless) کارخواه پشتیبانی می‌کند، که در آن یک نشانی IP برای کارخواه پیکربندی شده است (برای نمونه با استفاده از پیکربندی دستی) و تنها برای دریافت دیگر پارامترهای پیکربندی مانند نشانی کارسازهای DNS با کارساز ارتباط برقرار می‌کند. جهت دریافت پارامترهای پیکربندی بی‌حالت، کارخواه پیام DHCPINFORM را با مقداردهی ciaddr به نشانی‌ای که کارخواه در حال حاضر استفاده می‌کند به کارساز می‌فرستد. کارساز پیام DHCPACK را به‌صورت تک‌پخشی (unicast) به کارخواه ارسال می‌کند که شامل پیکربندی بی‌حالت است ("yiaddr" تنظیم نشده است).

کارساز زمانی به DHCPINFORM پاسخ می‌دهد که کارخواه با زیرشبکه‌ای که در پیکربندی کارساز تعریف شده است مرتبط باشد. نمونه‌ای از پیکربندی زیرشبکه به این صورت است:

"Dhcp4": {
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "option-data": [
            {
                "name": "domain-name-servers",
                "code": 6,
                "data": "192.0.2.200,192.0.2.201",
                "csv-format": true,
                "space": "dhcp4"
            }
            ]
        }
    ]
}

این زیرشبکه گزینهٔ یکتایی را مشخص می‌کند که در پاسخ به DHCPINFORM، در پیام DHCPACK برای کارخواه گنجانده خواهد شد. اگر تعریف زیرشبکه صرفاً برای پیکربندی بی‌حالت به کار رود، نیازی به پیکربندی استخر نشانی (pool) ندارد.

کارساز در صورت برقراری یکی از شرایط زیر، زیرشبکه را با کارخواه مرتبط خواهد کرد:

  • پیام DHCPINFORM بازپخش (relay) شده باشد و giaddr با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد.
  • پیام DHCPINFORM به‌صورت تک‌پخشی از کارخواه ارسال شده باشد و ciaddr با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد.
  • پیام DHCPINFORM به‌صورت تک‌پخشی از کارخواه ارسال شده و ciaddr تنظیم نشده باشد، اما نشانی مبدأ بستهٔ IP با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد.
  • پیام DHCPINFORM بازپخش نشده باشد و نشانی IP روی رابطی که پیام در آن دریافت شده است با زیرشبکهٔ پیکربندی‌شده مطابقت داشته باشد.

کارساز DHCPv4 شامل پشتیبانی از دسته‌بندی کارخواه‌ها (client classification) است. برای بررسی دقیق‌تر فرایند دسته‌بندی، Client Classification <#classify> را ببینید.

در موارد خاص، پیکربندی کارساز برای تمایز قائل شدن میان انواع کارخواه‌های DHCP و رفتار متناسب با آن‌ها سودمند است. از دسته‌بندی کارخواه‌ها می‌توان برای تغییر رفتار تقریباً هر بخشی از پردازش پیام‌های DHCP استفاده کرد. Kea در حال حاضر دسته‌بندی کارخواه‌ها را از طریق گزینه‌های اختصاصی و باز کردن باتأخیر گزینهٔ ۴۳ (deferred unpacking)؛ انتخاب زیرشبکه؛ انتخاب استخر؛ تخصیص گزینه‌های گوناگون؛ و برای مودم‌های کابلی، گزینه‌های ویژه جهت استفاده با نشانی کارساز TFTP و فیلد فایل راه‌اندازی (boot file) فراهم می‌کند.

می‌توان به Kea دستور داد تا دسترسی به زیرشبکه‌های مشخص را بر پایهٔ اطلاعات دسته محدود سازد. این قابلیت به‌ویژه در مواردی سودمند است که دو نوع دستگاه پیوند (link) مشترکی دارند و انتظار می‌رود از دو زیرشبکهٔ متفاوت سرویس‌دهی شوند. کاربرد اصلی چنین سناریویی شبکه‌های کابلی است، جایی که دو دسته دستگاه وجود دارد: خود مودم کابلی، که باید یک اجاره (lease) از زیرشبکهٔ A به آن تخصیص یابد؛ و همهٔ دستگاه‌های دیگرِ پشت مودم، که باید اجاره‌هایی از زیرشبکهٔ B دریافت کنند. این جداسازی برای جلوگیری از کنجکاوی بیش‌ازحد کاربران نهایی و دستکاری مودم‌های کابلی‌شان ضروری است. برای جزئیات در مورد نحوهٔ برپایی محدودیت‌های دسته روی زیرشبکه‌ها، Configuring Subnets With Class Information <#classification-subnets> را ببینید.

زمانی که زیرشبکه‌ها متعلق به یک شبکهٔ اشتراکی (shared network) باشند، دسته‌بندی بر روی انتخاب زیرشبکه اعمال می‌شود و نه استخرها؛ بدین معنا که اگر استخری که انتظار می‌رود کارخواه‌ها از آن استفاده کنند تمام شود، استخری در یک زیرشبکه که به دستهٔ خاصی محدود شده است همچنان می‌تواند توسط کارخواه‌هایی که عضو آن دسته نیستند استفاده شود. محدودیت دسترسی بر پایهٔ اطلاعات دسته در سطح استخرِ درون یک زیرشبکه نیز در دسترس است: Configuring Pools With Class Information <#classification-pools> را ببینید. این ویژگی برای جداسازی کارخواه‌های متعلق به یک زیرشبکه در محدوده‌های نشانی متفاوت کارآمد است.

به روشی مشابه، می‌توان یک استخر را با استفاده از دسته‌های داخلی KNOWN یا UNKNOWN محدود کرد تا تنها به کارخواه‌های شناخته‌شده (کارخواه‌هایی که دارای رزرو هستند) سرویس‌دهی کند. نشانی‌ها می‌توانند بدون اختصاص یک نشانی متفاوت به ازای هر رزرو، به کارخواه‌های ثبت‌شده تخصیص یابند: برای نمونه، زمانی که نشانی‌های در دسترس کافی نباشد. تشخیص اینکه آیا رزروی برای یک کارخواه مشخص وجود دارد یا خیر پس از انتخاب زیرشبکه صورت می‌گیرد، بنابراین استفاده از دسته‌های KNOWN/UNKNOWN برای انتخاب یک شبکهٔ اشتراکی یا یک زیرشبکه امکان‌پذیر نیست.

فرایند دسته‌بندی در پنج گام انجام می‌شود. گام نخست، بررسی بستهٔ ورودی و تخصیص آن به صفر یا چند دسته است. گام دوم، گزینش زیرشبکه است که احتمالاً بر پایهٔ اطلاعات دسته انجام می‌پذیرد. هنگامی که بستهٔ ورودی در دستهٔ ویژهٔ DROP قرار گیرد، دور انداخته می‌شود (drop) و یک پیام اشکال‌زدایی (debug) ثبت می‌گردد. گام بعدی، ارزیابی عبارت‌های دسته وابسته به دسته‌های داخلی KNOWN/UNKNOWN پس از جستجوی رزرو میزبان (host reservation lookup)، استفاده از آن‌ها برای انتخاب استخر و تخصیص دسته‌ها از رزروهای میزبان است. سپس فهرست دسته‌های مورد نیاز ساخته شده و عبارت هر دسته از فهرست ارزیابی می‌شود؛ زمانی که نتیجه true باشد، بسته به‌عنوان عضوی از آن دسته افزوده می‌شود. گام پایانی، تخصیص گزینه‌هاست که این مورد نیز می‌تواند بر پایهٔ اطلاعات دسته باشد. اطلاعات کامل‌تر و دقیق‌تر در Client Classification <#classify> در دسترس است.

دو روش اصلی برای دسته‌بندی وجود دارد. روش نخست خودکار است و بر بررسی مقادیر موجود در گزینه‌های دستهٔ سازنده (vendor class options) یا وجود رزرو میزبان تکیه دارد. اطلاعات از این گزینه‌ها استخراج شده، نام دسته‌ای از آن ساخته می‌شود و به فهرست دسته‌های بسته افزوده می‌گردد. روش دوم، عبارتی را مشخص می‌کند که برای هر بسته ارزیابی می‌شود. چنانچه نتیجهٔ ارزیابی true باشد، بسته عضوی از آن دسته خواهد بود.

نکته:

پرچم پارامتر سراسری جدید early-global-reservations-lookup، امکان جستجو برای رزروهای سراسری را پیش از مرحلهٔ انتخاب زیرشبکه فعال می‌سازد. این جستجو شبیه به جستجوی عمومی شرح‌داده‌شده در بالا است، با دو تفاوت:
  • جستجو محدود به رزروهای سراسری میزبان است
  • دستهٔ UNKNOWN هرگز تنظیم نمی‌شود

نکته:

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

نکته:

نسخهٔ 3.1.7 برنامهٔ Kea یک دستهٔ ویژهٔ دیگر به نام REJECT اضافه کرد که عملکردی مشابه دستهٔ DROP دارد، اما به‌جای نادیده گرفتن و دور انداختن کامل پرس‌وجوی ورودی، بخش تخصیص اجاره را رد می‌کند؛ بنابراین هیچ پاسخ DHCPOFFER در پاسخ به پرس‌وجوی DHCPDISCOVER ارسال نمی‌شود، و پاسخ به پرس‌وجوی DHCPREQUEST باید یک DHCPNAK باشد.

این امکان وجود دارد که مشخص شود کلاینت‌های متعلق به یک رده‌ی خاص، بسته‌هایی با مقادیر مشخص در فیلدهای ثابتِ معینی دریافت کنند. به‌طور خاص، سه فیلد ثابت پشتیبانی می‌شوند: next-server (حاوی یک آدرس IPv4 است که در فیلد siaddr تنظیم می‌شود)، server-hostname (حاوی نام میزبان سرور است، می‌تواند تا ۶۴ بایت طول داشته باشد و در فیلد sname ارسال می‌شود) و boot-file-name (حاوی فایل پیکربندی است، می‌تواند تا ۱۲۸ بایت طول داشته باشد و با استفاده از فیلد file ارسال می‌شود).

بدیهی است که راه‌های زیادی برای تخصیص کلاینت‌ها به رده‌های خاص وجود دارد، اما برای کلاینت‌های PXE، گزینه نوع معماری کلاینت (کد ۹۳) به‌طور ویژه‌ای برای ایجاد این تمایز مناسب به نظر می‌رسد. مثال زیر بررسی می‌کند که آیا کلاینت خود را به عنوان یک دستگاه PXE با معماری EFI x86-64 معرفی می‌کند یا خیر، و در صورت تطابق، چندین فیلد را تنظیم می‌کند. برای مقادیر خاص، بخش 2.1 از RFC 4578 https://datatracker.ietf.org/doc/html/rfc4578#section-2.1 اصلاح‌شده توسط بخش خطاهای آن (errata) یا مستندات کلاینت را ببینید.

"Dhcp4": {
    "client-classes": [
        {
            "name": "ipxe_efi_x64",
            "test": "option[93].hex == 0x0007",
            "next-server": "192.0.2.254",
            "server-hostname": "hal9000",
            "boot-file-name": "/dev/null"
        },
        ...
    ],
    ...
}

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

نکته:

ترتیب رده‌ها همان‌گونه است که در پیکربندی مشخص شده است.

سرور بررسی می‌کند که آیا بسته ورودی شامل گزینه شناسه رده سازنده (۶۰) است یا خیر. در صورت وجود، پیشوند VENDOR_CLASS_ به محتوای آن گزینه اضافه شده و به عنوان یک رده تفسیر می‌شود. به عنوان مثال، مودم‌های کابلی مدرن این گزینه را با مقدار docsis3.0 ارسال می‌کنند، بنابراین بسته متعلق به رده VENDOR_CLASS_docsis3.0 خواهد بود.

نکته:

اقدامات خاصی برای کلاینت‌های موجود در VENDOR_CLASS_docsis3.0 را می‌توان با تعریف VENDOR_CLASS_docsis3.0 و تنظیم مناسب مقادیر next-server و boot-file-name آن انجام داد.

این مثال پیکربندی‌ای را با استفاده از یک رده VENDOR_CLASS_ که به‌صورت خودکار تولید شده نشان می‌دهد. مدیر شبکه تصمیم گرفته است که آدرس‌های محدوده 192.0.2.10 تا 192.0.2.20 توسط سرور Dhcp4 مدیریت شوند و تنها کلاینت‌های متعلق به رده کلاینت DOCSIS 3.0 مجاز به استفاده از این استخر (pool) باشند.

"Dhcp4": {
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "client-classes": [ "VENDOR_CLASS_docsis3.0" ]
        }
    ],
    ...
}

مثال زیر نشان می‌دهد که چگونه یک رده را با استفاده از یک عبارت و یک زیرشبکه (subnet) را با استفاده از آن رده پیکربندی کنید. این پیکربندی رده‌ای به نام Client_foo را تعریف می‌کند. این رده شامل همه کلاینت‌هایی است که شناسه کلاینت آن‌ها (گزینه ۶۱) با رشته foo شروع می‌شود. به اعضای این رده آدرس‌هایی از 192.0.2.10 تا 192.0.2.20 اختصاص داده می‌شود و آدرس سرورهای DNS آن‌ها روی 192.0.2.1 و 192.0.2.2 تنظیم می‌گردد.

"Dhcp4": {
    "client-classes": [
        {
            "name": "Client_foo",
            "test": "substring(option[61].hex,0,3) == 'foo'",
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "code": 6,
                    "space": "dhcp4",
                    "csv-format": true,
                    "data": "192.0.2.1, 192.0.2.2"
                }
            ]
        },
        ...
    ],
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "client-classes": [ "Client_foo" ]
        },
        ...
    ],
    ...
}

در برخی موارد، محدود کردن دامنه (scope) یک کلاس به یک pool، subnet یا shared network سودمند است. دو پارامتر وجود دارند که برای محدود کردن دامنه کلاس از طریق هدایت سرور به ارزیابی عبارت‌های آزمون (test expressions) در زمان نیاز، به کار می‌روند.

پارامتر evaluate-additional-classes که فهرستی از نام‌های کلاس را می‌پذیرد و در دامنه pool، subnet و shared network معتبر است. کلاس‌های موجود در این فهرست‌ها به عنوان تکمیلی (additional) علامت‌گذاری شده و پس از انتخاب آن pool/subnet/shared network خاص و پیش از پردازش گزینه‌های خروجی (output-option) ارزیابی می‌شوند.

مورد دوم پرچم مختص هر کلاس only-in-additional-list است که به‌طور پیش‌فرض false می‌باشد. هنگامی که روی true تنظیم شود، عبارت آزمون کلاس در زمان دریافت بسته ورودی ارزیابی نمی‌شود، بلکه دیرتر و تنها در صورتی که کلاس در یک فهرست evaluate-additional-classes موجود باشد ارزیابی خواهد شد.

در این مثال، هنگامی که subnet مشخص‌شده استفاده شود، یک کلاس به بسته ورودی اختصاص می‌یابد:

"Dhcp4": {
    "client-classes": [
       {
           "name": "Client_foo",
           "test": "member('ALL')",
           "only-in-additional-list": true
       },
       ...
    ],
    "subnet4": [
        {
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "evaluate-additional-classes": [ "Client_foo" ],
            ...
        },
        ...
    ],
    ...
}

ارزیابی تکمیلی می‌تواند برای بیان وابستگی‌های پیچیده مانند عضویت در subnet استفاده شود. همچنین می‌تواند برای معکوس کردن اولویت‌ها (precedence) به کار رود؛ اگر option-data در یک subnet تنظیم شود، نسبت به option-data در یک کلاس اولویت دارد. اگر option-data به یک کلاس الزامی منتقل شده و در subnet الزامی شود، کلاسی که زودتر ارزیابی شده است ممکن است اولویت یابد.

ارزیابی تکمیلی در سطوح shared network و pool نیز در دسترس است. ترتیبی که در آن کلاس‌های تکمیلی در نظر گرفته می‌شوند به این صورت است: pool، subnet و shared network؛ یعنی به همان ترتیبی که option-data پردازش می‌شود.

از نسخه 2.7.4 نرم‌افزار Kea، کلاس‌های تکمیلی پیکربندی‌شده بدون عبارت آزمون به‌طور بدون قید و شرط اضافه می‌شوند؛ یعنی در نظر گرفته می‌شود که همیشه به true ارزیابی می‌شوند.

نکته:

از آنجا که ارزیابی تکمیلی پس از تخصیص اجاره (lease assignment) رخ می‌دهد، پارامترهایی که در غیر این صورت بر طول عمر اجاره تأثیر می‌گذاشتند (مانند valid-lifetime و offer-lifetime)، هنگامی که در کلاسی مشخص شوند که only-in-additional-list آن نیز روی true تنظیم شده باشد، هیچ اثری نخواهند داشت.

نکته:

از نسخه 2.7.4 نرم‌افزار Kea، شناسه‌های only-if-required و require-client-classes به‌ترتیب به only-in-additional-list و evaluate-additional-classes تغییر نام یافته‌اند. نام‌های اولیه همچنان به‌عنوان ورودی پذیرفته می‌شوند تا به کاربران اجازه مهاجرت داده شود، اما در نهایت رد خواهند شد.

نکته:

گزینه‌های Vendor-Identifying Vendor Options یک حالت خاص هستند: برای سایر گزینه‌ها، یک گزینه بر اساس نقطه کد (code point) خود شناسایی می‌شود، اما vivco-suboptions (کد 124) و vivso-suboptions (کد 125) بر اساس جفت نقطه کد و شناسه فروشنده (vendor identifier) شناسایی می‌شوند. این موضوع تأثیر مشهودی بر vivso-suboptions ندارد، چرا که مقدار آن همان شناسه فروشنده است، اما برای vivco-suboptions متفاوت است؛ جایی که مقدار، یک رکورد شامل شناسه فروشنده و یک مقدار باینری است. برای نمونه، در:
"Dhcp4": {
    "option-data": [
       {
           "name": "vivco-suboptions",
           "always-send": true,
           "data": "1234, 03666f6f"
       },
       {
           "name": "vivco-suboptions",
           "always-send": true,
           "data": "5678, 03626172"
       },
       ...
     ],
     ...
 }

اولین مدخل option-data مدخل دوم را پنهان نمی‌کند، زیرا شناسه‌های فروشنده (1234 و 5678) متفاوت هستند: پاسخ‌ها حامل دو نمونه از گزینه vivco-suboptions خواهند بود که هر کدام مربوط به یک فروشنده متفاوت است..SS "DDNS برای DHCPv4"

همان‌طور که پیش‌تر ذکر شد، kea-dhcp4 <#std-iscman-kea-dhcp4> می‌تواند برای ایجاد درخواست‌ها به کارساز DHCP-DDNS، یعنی kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>، (که در اینجا از آن با عنوان "D2" یاد می‌شود) جهت به‌روزرسانی مدخل‌های DNS پیکربندی شود. این درخواست‌ها تحت عنوان NameChangeRequests یا NCRها شناخته می‌شوند. هر NCR شامل اطلاعات زیر است:

1.
آیا درخواستی برای افزودن (به‌روزرسانی) یا حذف مدخل‌های DNS است.
2.
آیا تغییر، درخواست به‌روزرسانی‌های مستقیم DNS (رکوردهای A)، به‌روزرسانی‌های معکوس DNS (رکوردهای PTR) یا هر دو را دارد.
3.
نام دامنه کاملاً مشخص (FQDN)، نشانی اجاره (lease) و DHCID (اطلاعات شناسایی کلاینت مرتبط با FQDN).

پارامترهای مرتبط با DDNS به دو گروه تقسیم می‌شوند:

1.
پارامترهای اتصال (Connectivity Parameters)
این‌ها پارامترهایی هستند که مشخص می‌کنند kea-dhcp4 <#std-iscman-kea-dhcp4> کجا و چگونه به D2 متصل شده و با آن ارتباط برقرار می‌کند. این پارامترها تنها می‌توانند در بخش سطح‌بالای dhcp-ddns در پیکربندی kea-dhcp4 <#std-iscman-kea-dhcp4> مشخص شوند. پارامترهای اتصال در زیر فهرست شده‌اند:
  • enable-updates
  • server-ip
  • server-port
  • sender-ip
  • sender-port
  • max-queue-size
  • ncr-protocol
  • ncr-format
2.
پارامترهای رفتاری (Behavioral Parameters)
این پارامترها بر رفتارهایی مانند نحوه مدیریت نام‌های میزبان کلاینت و گزینه‌های FQDN تأثیر می‌گذارند. آن‌ها از بخش dhcp-ddns خارج شده‌اند تا بتوان آن‌ها را در سطوح global، shared-network، subnet و/یا pool تعیین کرد. علاوه بر این، آن‌ها به صورت رو به پایین از global به shared-network به subnet و به pool به ارث می‌رسند. به عبارت دیگر، اگر پارامتری در یک سطح معین مشخص نشده باشد، مقدار آن سطح از سطح بالایی گرفته می‌شود. پارامترهای رفتاری به شرح زیر هستند:
  • ddns-send-updates
  • ddns-override-no-update
  • ddns-override-client-update
  • ddns-replace-client-name
  • ddns-generated-prefix
  • ddns-qualifying-suffix
  • ddns-update-on-renew
  • ddns-conflict-resolution-mode
  • ddns-ttl
  • ddns-ttl-percent
  • ddns-ttl-min
  • ddns-ttl-max
  • hostname-char-set
  • hostname-char-replacement

نکته:

Kea 2.7.6 پشتیبانی از این پارامترها را به سطح pool اضافه کرد.

نکته:

پارامترهای رفتاری که بر FQDN تأثیر می‌گذارند، حتی اگر هر دو پارامتر enable-updates و ddns-send-updates برابر false باشند نیز اعمال می‌شوند، تا از محیط‌هایی که در آن‌ها کلاینت‌ها خود مسئول به‌روزرسانی‌های DNS خود هستند پشتیبانی شود. این قاعده شامل ddns-replace-client-name، ddns-generated-prefix، ddns-qualifying-suffix، hostname-char-set و hostname-char-replacement می‌شود.

پیکربندی و مقادیر پیش‌فرض به شکل زیر خواهد بود:

"Dhcp4": {
     "dhcp-ddns": {
         // Connectivity parameters
         "enable-updates": false,
         "server-ip": "127.0.0.1",
         "server-port":53001,
         "sender-ip":"",
         "sender-port":0,
         "max-queue-size":1024,
         "ncr-protocol":"UDP",
         "ncr-format":"JSON"
     },
     // Behavioral parameters (global)
     "ddns-send-updates": true,
     "ddns-override-no-update": false,
     "ddns-override-client-update": false,
     "ddns-replace-client-name": "never",
     "ddns-generated-prefix": "myhost",
     "ddns-qualifying-suffix": "",
     "ddns-update-on-renew": false,
     "ddns-conflict-resolution-mode": "check-with-dhcid",
     "hostname-char-set": "[^A-Za-z0-9.-]",
     "hostname-char-replacement": "x",
     ...
}

دو پارامتر وجود دارند که تعیین می‌کنند آیا kea-dhcp4 <#std-iscman-kea-dhcp4> می‌تواند درخواست‌های DDNS را به D2 ارسال کند یا خیر: پارامتر موجود dhcp-ddns:enable-updates که اکنون تنها کنترل می‌کند آیا kea-dhcp4 <#std-iscman-kea-dhcp4> به D2 متصل شود یا خیر؛ و پارامتر رفتاری جدید، ddns-send-updates، که مشخص می‌کند آیا به‌روزرسانی‌های DDNS در یک سطح مشخص (مانند global، shared-network یا subnet) فعال هستند یا خیر. جدول زیر نحوه عملکرد هم‌زمان این دو پارامتر را نشان می‌دهد:.SS فعال‌سازی و غیرفعال‌سازی به‌روزرسانی‌های DDNS

dhcp-ddns: enable-updates سراسری ddns-send-updates نتیجه
false (پیش‌فرض) false عدم به‌روزرسانی در هیچ حوزه‌ای
false true (پیش‌فرض) عدم به‌روزرسانی در هیچ حوزه‌ای
true false به‌روزرسانی تنها در حوزه‌هایی با مقدار محلی true برای ddns-enable-updates
true true به‌روزرسانی در تمام حوزه‌ها به جز مواردی با مقدار محلی false برای ddns-enable-updates

در Kea 1.9.1 دو پارامتر جدید اضافه شد؛ نخستین مورد ddns-update-on-renew است. به‌طور معمول، هنگام تمدید اجاره‌ها، کارساز تنها در صورتی DNS را به‌روزرسانی می‌کند که اطلاعات DNS مربوط به اجاره (مانند FQDN یا پرچم‌های جهت به‌روزرسانی DNS) تغییر کرده باشد. تنظیم ddns-update-on-renew روی true به کارساز دستور می‌دهد هنگام تمدید اجاره همواره اطلاعات DNS را به‌روز کند، حتی اگر اطلاعات DNS آن تغییر نکرده باشد. این ویژگی به Kea امکان می‌دهد در صورتی که پیش‌تر نتوانسته ورودی‌های DNS را اضافه کند یا آن‌ها به نحوی توسط کارساز DNS از دست رفته باشند، «خودترمیمی» ("self-heal") کند.

نکته:

تنظیم ddns-update-on-renew روی true ممکن است بر کارایی تأثیر منفی بگذارد، به‌ویژه برای کارسازهایی با کلاینت‌های متعدد که مکرراً تمدید انجام می‌دهند.

دومین پارامتر اضافه‌شده در Kea 1.9.1 پارامتر ddns-use-conflict-resolution است. این پارامتر بولی به D2 فرستاده می‌شد و حل تداخل را طبق توصیفات RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703 فعال یا غیرفعال می‌کرد. از Kea 2.5.0 به بعد، این پارامتر منسوخ شده و با ddns-conflict-resolution-mode جایگزین شده است که چهار حالت رفتاری مرتبط با حل تداخل را ارائه می‌دهد:

  • check-with-dhcid - این حالت (پیش‌فرض)، به D2 دستور می‌دهد تا حل تداخل منطبق با RFC 4703 را انجام دهد. ورودی‌های موجود DNS تنها در صورتی ممکن است بازنویسی شوند که دارای رکورد DHCID باشند و با DHCID کلاینت مطابقت داشته باشد. این معادل ddns-use-conflict-resolution: true است؛
  • no-check-with-dhcid - ورودی‌های موجود DNS می‌توانند توسط هر کلاینتی بازنویسی شوند، فارغ از اینکه آن ورودی‌ها شامل رکورد DHCID باشند یا خیر. ورودی‌های جدید شامل رکورد DHCID برای کلاینتی خواهند بود که به آن تعلق دارند. این معادل ddns-use-conflict-resolution: false است؛
  • check-exists-with-dhcid - ورودی‌های موجود DNS تنها در صورتی بازنویسی می‌شوند که دارای رکورد DHCID باشند. لزومی ندارد رکورد DHCID با DHCID کلاینت مطابقت داشته باشد. این حالت راهکاری برای محافظت از ورودی‌های ایستا DNS (آن‌هایی که رکورد DHCID ندارند) فراهم می‌کند در حالی که اجازه می‌دهد ورودی‌های پویا (آن‌هایی که دارای رکورد DHCID هستند) توسط هر کلاینتی بازنویسی شوند. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد.
  • no-check-without-dhcid - ورودی‌های موجود DNS می‌توانند توسط هر کلاینتی بازنویسی شوند؛ ورودی‌های جدید شامل رکوردهای DHCID نخواهند بود. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد.

نکته:

برای سازگاری رو به عقب، ddns-use-conflict-resolution همچنان در پیکربندی JSON پذیرفته می‌شود. کارساز این مقدار را در درون خود با ddns-conflict-resolution-mode و مقدار مناسب جایگزین می‌کند: check-with-dhcid برای true و no-check-with-dhcid برای false.

نکته:

تنظیم ddns-conflict-resolution-mode روی هر مقداری غیر از check-with-dhcid، تدابیر حفاظتی بازنویسی را که قواعد حل تداخل (برگرفته از RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703) به‌منظور جلوگیری از آن‌ها تعبیه شده‌اند، غیرفعال می‌کند. این بدان معناست که ورودی‌های موجود برای یک FQDN یا یک نشانی IP که برای Client-A ایجاد شده‌اند، می‌توانند توسط ورودی‌های Client-B حذف یا جایگزین شوند. علاوه بر این، دو سناریو وجود دارد که طی آن‌ها ورودی‌های چند کلاینت برای یک کلید یکسان (مانند FQDN یا IP) ایجاد می‌شود:

۱. کلاینت Client-B از همان FQDN مربوط به Client-A ولی یک نشانی IP متفاوت استفاده کند. در این حالت، ورودی‌های رو به جلو DNS (رکوردهای منبع A و DHCID) برای Client-A حذف خواهند شد چون با FQDN مطابقت دارند، و ورودی‌های جدید برای Client-B اضافه خواهند شد. با این حال، ورودی‌های معکوس DNS (رکوردهای منبع PTR و DHCID) برای Client-A حذف نخواهند شد زیرا به نشانی IP متفاوتی تعلق دارند، در حالی که ورودی‌های جدید برای Client-B همچنان افزوده خواهند شد.

۲. کلاینت Client-B از همان نشانی IP مربوط به Client-A ولی یک FQDN متفاوت استفاده کند. در این حالت، ورودی‌های معکوس DNS (رکوردهای منبع PTR و DHCID) برای Client-A حذف خواهند شد چون با نشانی IP مطابقت دارند، و ورودی‌های جدید برای Client-B اضافه خواهند شد. اما ورودی‌های رو به جلو DNS (رکوردهای منبع A و DHCID) برای Client-A حذف نخواهند شد، زیرا به یک FQDN متفاوت تعلق دارند، در حالی که ورودی‌های جدید برای Client-B همچنان افزوده خواهند شد.

غیرفعال‌سازی حل تداخل تنها باید پس از بررسی دقیق موارد کاربرد خاص انجام گیرد. بهترین راه برای جلوگیری از ورودی‌های ناخواسته DNS این است که همیشه اطمینان حاصل شود پیش از تخصیص مجدد FQDNها یا نشانی‌های IP، تغییرات اجاره‌ها از طریق Kea پردازش شوند؛ چه آزاد شوند، چه منقضی گردند یا از طریق دستور lease4-del <#std-isccmd-lease4-del> حذف شوند. انجام این کار باعث می‌شود kea-dhcp4 <#std-iscman-kea-dhcp4> درخواست‌های حذف DNS را به D2 ارسال کند.

ورودی‌های DNS که Kea می‌سازد حاوی مقداری برای TTL (طول عمر) هستند. به‌طور پیش‌فرض، کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> این مقدار را بر اساس RFC 4702، بخش ۵ https://datatracker.ietf.org/doc/html/rfc4702#section-5 محاسبه می‌کند که پیشنهاد می‌دهد مقدار TTL برابر ۱/۳ طول عمر اجاره با حداقل مقدار ۱۰ دقیقه باشد. چهار پارامتر اختیاری وجود دارند که می‌توان از آن‌ها برای تأثیرگذاری بر محاسبه TTL استفاده کرد:

  • ddns-ttl - در صورت تعیین و بزرگ‌تر بودن از ۰، بدون قید و شرط به عنوان مقدار TTL استفاده می‌شود. این مقدار بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض نامشخص است.
  • ddns-ttl-percent - در صورت تعیین و بزرگ‌تر بودن از صفر، به عنوان درصد طول عمر اجاره استفاده می‌شود، در غیر این صورت از ۱/۳ (طبق RFC 4702) طول عمر اجاره استفاده خواهد شد. این پارامتر به عنوان یک درصد اعشاری (مانند 0.75، 0.50) مشخص می‌شود و به‌طور پیش‌فرض نامشخص است.
  • ddns-ttl-min - در صورت تعیین و بزرگ‌تر بودن از ۰، به عنوان حداقل مقدار استفاده می‌شود؛ در غیر این صورت حداقل ۶۰۰ ثانیه (طبق RFC 4702) به کار می‌رود. اگر TTL محاسبه‌شده کمتر از مقدار حداقل باشد، حداقل بازگردانده می‌شود. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض نامشخص است.
  • ddns-ttl-max - در صورت تعیین و بزرگ‌تر بودن از صفر، مقدار محاسبه‌شده TTL را به مقدار آن محدود می‌کند. این مقدار بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض نامشخص است.

نکته:

مقدار صفر برای هر یک از پارامترهای TTL می‌تواند برای باطل کردن (یعنی «نامشخص کردن» یا "unspecify") مقدار آن پارامتر که از یک حوزه بالاتر به ارث رسیده است، استفاده شود.

برای اینکه NCRها به سرور D2 برسند، kea-dhcp4 <#std-iscman-kea-dhcp4> باید قادر به برقراری ارتباط با آن باشد. kea-dhcp4 <#std-iscman-kea-dhcp4> از پارامترهای پیکربندی زیر برای کنترل این ارتباط استفاده می‌کند:

  • enable-updates - اتصال به kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> را فعال می‌کند تا به‌روزرسانی‌های DDNS ساخته و ارسال شوند. برای اینکه NCRها تولید و به D2 فرستاده شوند، این مقدار باید true باشد. مقدار پیش‌فرض آن false است.
  • server-ip - این آدرس IP است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض رابط محلی لوپ‌بک با آدرس 127.0.0.1 است. می‌توان هر یک از آدرس‌های IPv4 یا IPv6 را مشخص کرد.
  • server-port - این پورتی است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض 53001 است.
  • sender-ip - این آدرس IP است که kea-dhcp4 <#std-iscman-kea-dhcp4> برای ارسال درخواست‌ها به D2 از آن استفاده می‌کند. مقدار پیش‌فرض خالی است، که به kea-dhcp4 <#std-iscman-kea-dhcp4> دستور می‌دهد یک آدرس مناسب را انتخاب کند.
  • sender-port - این پورتی است که kea-dhcp4 <#std-iscman-kea-dhcp4> برای ارسال درخواست‌ها به D2 از آن استفاده می‌کند. مقدار پیش‌فرض 0 به kea-dhcp4 <#std-iscman-kea-dhcp4> دستور می‌دهد یک پورت مناسب را انتخاب نماید.
  • max-queue-size - این حداکثر تعداد درخواست‌های مجاز برای قرارگیری در صف هنگام انتظار برای ارسال به D2 است. این مقدار از انباشت مهارنشدنی درخواست‌ها در صورتی که سریع‌تر از توان تحویل تولید شوند، جلوگیری می‌کند. اگر تعداد درخواست‌های در صف برای مخابره به این مقدار برسد، به‌روزرسانی DDNS غیرفعال می‌شود تا زمانی که تراکم صف به اندازه کافی کاهش یابد. هدف این است که به سرور kea-dhcp4 <#std-iscman-kea-dhcp4> اجازه داده شود بدون پذیرش ریسک رشد نامحدود حافظه، به عملیات اجاره (lease) ادامه دهد. مقدار پیش‌فرض 1024 است.
  • ncr-protocol - پروتکل سوکت مورد استفاده هنگام ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر فقط UDP پشتیبانی می‌شود.
  • ncr-format - قالب بسته (packet format) برای ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر فقط قالب JSON پشتیبانی می‌شود.

به‌طور پیش‌فرض، فرض می‌شود که kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> روی همان ماشینی اجرا می‌شود که kea-dhcp4 <#std-iscman-kea-dhcp4> روی آن فعال است، و تمام مقادیر پیش‌فرض ذکرشده در بالا باید کافی باشند. با این حال، اگر D2 به گونه‌ای پیکربندی شده باشد که روی آدرس یا پورت دیگری گوش دهد، این مقادیر باید بر همین اساس تغییر یابند. برای مثال، اگر D2 برای گوش دادن روی آدرس 192.168.1.10 و پورت 900 پیکربندی شده باشد، پیکربندی زیر الزامی است:

"Dhcp4": {
    "dhcp-ddns": {
        "server-ip": "192.168.1.10",
        "server-port": 900,
        ...
    },
    ...
}

سرور kea-dhcp4 <#std-iscman-kea-dhcp4> از رفتار مقررشده برای سرورهای DHCP در RFC 4702 https://datatracker.ietf.org/doc/html/rfc4702 پیروی می‌کند. توجه به این نکته مهم است که kea-dhcp4 <#std-iscman-kea-dhcp4> تصمیم اولیه مبنی بر زمان و مواردی که باید به‌روزرسانی شوند را اتخاذ می‌کند و آن اطلاعات را در قالب NCRها به D2 می‌فرستد. انجام به‌روزرسانی‌های واقعی DNS و رسیدگی به مسائلی همچون حل تعارض (conflict resolution) در حیطه وظایف خود D2 است (بخش The DHCP-DDNS Server <#dhcp-ddns-server> را ببینید). این بخش توضیح می‌دهد که kea-dhcp4 <#std-iscman-kea-dhcp4> چه زمانی NCRها را ایجاد می‌کند و از چه پارامترهای پیکربندی می‌توان برای تأثیرگذاری بر این تصمیم استفاده نمود. فرض این بخش بر این است که هم پارامتر اتصال enable-updates و هم پارامتر رفتاری ddns-send-updates روی true تنظیم شده‌اند.

به‌طور کلی، kea-dhcp4 <#std-iscman-kea-dhcp4> درخواست‌های به‌روزرسانی DDNS را در مواقع زیر ایجاد می‌کند:

1.
یک اجاره جدید در پاسخ به یک DHCPREQUEST اعطا شود؛
2.
یک اجاره موجود تمدید شود اما FQDN مرتبط با آن تغییر کرده باشد؛ یا
3.
یک اجاره موجود در پاسخ به یک DHCPRELEASE آزاد شود.

در حالت دوم (تمدید اجاره)، دو درخواست DDNS صادر می‌شود: یک درخواست برای حذف ورودی‌های مربوط به FQDN قبلی، و درخواست دوم برای افزودن ورودی‌های FQDN جدید. در حالت سوم (آزادسازی اجاره)، یک درخواست DDNS تکی برای حذف ورودی‌های آن ارسال می‌شود.

اما در مورد حالت اول، تصمیمات مرتبط با اعطای اجاره جدید پیچیده‌تر است. هنگامی که یک اجاره جدید اعطا می‌شود، چنانچه DHCPREQUEST شامل گزینه FQDN (کد 81) یا گزینه Host Name (کد 12) باشد، kea-dhcp4 <#std-iscman-kea-dhcp4> یک درخواست به‌روزرسانی DDNS ایجاد می‌کند. اگر هر دو گزینه موجود باشند، سرور از گزینه FQDN استفاده می‌کند. به‌طور پیش‌فرض، kea-dhcp4 <#std-iscman-kea-dhcp4> به پرچم‌های N و S مشخص‌شده توسط کلاینت برای FQDN، مطابق با جدول زیر احترام می‌گذارد:

پرچم‌های کلاینت: N-S قصد کلاینت پاسخ سرور پرچم‌های سرور: N-S-O
0-0 کلاینت می‌خواهد به‌روزرسانی‌های مستقیم را انجام دهد، سرور باید به‌روزرسانی‌های معکوس را اعمال کند سرور فقط درخواست به‌روزرسانی معکوس تولید می‌کند 1-0-0
0-1 سرور باید هر دو به‌روزرسانی مستقیم و معکوس را انجام دهد سرور درخواستی برای به‌روزرسانی هر دو جهت تولید می‌کند 0-1-0
1-0 کلاینت می‌خواهد هیچ به‌روزرسانی‌ای انجام نشود سرور درخواستی تولید نمی‌کند 1-0-0

سطر اول در جدول بالا بیانگر "واگذاری به کلاینت (client delegation)" است. در اینجا کلاینت DHCP اعلام می‌کند که قصد دارد به‌روزرسانی‌های مستقیم DNS را خود انجام دهد و سرور باید به‌روزرسانی‌های معکوس را اعمال کند. به‌طور پیش‌فرض، kea-dhcp4 <#std-iscman-kea-dhcp4> به خواسته کلاینت احترام می‌گذارد و درخواستی برای DDNS به سرور D2 فقط جهت به‌روزرسانی داده‌های معکوس DNS ارسال می‌کند. از پارامتر ddns-override-client-update می‌توان برای واداشتن سرور به لغو و نادیده گرفتن درخواست‌های واگذاری به کلاینت استفاده کرد. هنگامی که این پارامتر true باشد، kea-dhcp4 <#std-iscman-kea-dhcp4> درخواست‌های واگذاری به کلاینت را نادیده گرفته و یک درخواست DDNS برای به‌روزرسانی داده‌های مستقیم و معکوس DNS تولید می‌کند. در این حالت، پرچم‌های N-S-O در پاسخ سرور به کلاینت به ترتیب 0-1-1 خواهند بود.

(توجه داشته باشید که بر اساس RFC 4702 https://datatracker.ietf.org/doc/html/rfc4702، ترکیب پرچم‌های N=1, S=1 ممنوع است. در صورت دریافت چنین ترکیبی از سوی کلاینت، بسته توسط kea-dhcp4 <#std-iscman-kea-dhcp4> دور انداخته می‌شود.)

برای لغو واگذاری به کلاینت، مقادیر زیر را در فایل پیکربندی تنظیم کنید:

"Dhcp4": {
    "ddns-override-client-update": true,
    ...
}

سطر سوم جدول بالا وضعیتی را توصیف می‌کند که در آن کلاینت درخواست می‌کند هیچ به‌روزرسانی در DNS انجام نشود. از پارامتر ddns-override-no-update می‌توان برای واداشتن سرور به نادیده گرفتن خواسته کلاینت استفاده کرد. هنگامی که این پارامتر true باشد، kea-dhcp4 <#std-iscman-kea-dhcp4> حتی اگر کلاینت درخواست عدم به‌روزرسانی داده باشد، درخواست‌های به‌روزرسانی DDNS را به kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> ارسال می‌کند. پرچم‌های N-S-O در پاسخ سرور به کلاینت 0-1-1 خواهند بود.

برای لغو واگذاری به کلاینت، دستورات زیر را اعمال کنید:

"Dhcp4": {
    "ddns-override-no-update": true,
    ...
}

سرور kea-dhcp4 <#std-iscman-kea-dhcp4> همواره در صورتی که درخواست کلاینت تنها شامل گزینه Host Name باشد، درخواست‌های به‌روزرسانی DDNS را تولید می‌کند. افزون بر این، یک گزینه FQDN را با پرچم‌های FQDN N-S-O که به ترتیب روی 0-1-0 تنظیم شده‌اند در پاسخ به کلاینت می‌گنجاند. بخش نام دامنه در گزینه FQDN، همان نامی است که در درخواست به‌روزرسانی DDNS به D2 ارسال می‌شود..SS kea-dhcp4 <#std-iscman-kea-dhcp4> - تولید نام برای درخواست‌های به‌روزرسانی DDNS

هر NameChangeRequest مسلماً باید شامل نام دامنه کاملاً واجد شرایط (FQDN) باشد که ورودی‌های DNS آن قرار است تحت تأثیر قرار گیرند. می‌توان kea-dhcp4 <#std-iscman-kea-dhcp4> را طوری پیکربندی کرد که بر اساس آنچه در DHCPREQUEST از کلاینت دریافت می‌کند، بخشی از آن نام یا تمام آن را فراهم نماید.

قوانین پیش‌فرض برای ساخت FQDN که برای ورودی‌های DNS استفاده خواهد شد، عبارتند از:

1.
اگر DHCPREQUEST حاوی گزینه FQDN کلاینت باشد، نام کاندید از آن گرفته می‌شود؛ در غیر این صورت، از گزینه Host Name اخذ خواهد شد.
2.
اگر نام کاندید یک نام جزئی (یعنی کامل‌نشده یا unqualified) باشد، یک پسوند قابل‌پیکربندی به نام اضافه شده و نتیجه به عنوان FQDN استفاده می‌شود.
3.
اگر نام کاندید ارائه‌شده خالی باشد، با استفاده از یک پیشوند و پسوند قابل‌پیکربندی، یک FQDN تولید می‌شود.
4.
اگر کلاینت هیچ‌یک از این دو گزینه را ارائه نکند، هیچ عملیاتی روی DNS انجام نمی‌شود.

این قوانین را می‌توان با تنظیم پارامتر ddns-replace-client-name اصلاح کرد، که حالت‌های رفتاری زیر را فراهم می‌کند:

  • never - استفاده از نامی که کلاینت ارسال کرده است. اگر کلاینت نامی ارسال نکرد، نامی تولید نشود. این حالت پیش‌فرض است.
  • always - جایگزین کردن نام ارسالی کلاینت. اگر کلاینت نامی ارسال نکرد، یکی برای کلاینت تولید شود.
  • when-present - جایگزین کردن نام ارسالی کلاینت. اگر کلاینت نامی ارسال نکرد، نامی تولید نشود.
  • when-not-present - استفاده از نامی که کلاینت ارسال کرده است. اگر کلاینت نامی ارسال نکرد، یکی برای کلاینت تولید شود.

نکته:

در نسخه‌های اولیه Kea، این پارامتر بولی (boolean) بود و تنها مقادیر true و false را می‌پذیرفت. مقادیر بولی منسوخ شده‌اند و دیگر پذیرفته نمی‌شوند. مدیرانی که در حال حاضر از مقادیر بولی استفاده می‌کنند، باید آن‌ها را با نام حالت مورد نظر جایگزین کنند. مقدار true به when-present و false به never نگاشت می‌شود.

برای مثال، جهت هدایت kea-dhcp4 <#std-iscman-kea-dhcp4> به تولید همیشگی FQDN برای یک کلاینت، پارامتر ddns-replace-client-name را مطابق زیر روی always تنظیم کنید:

"Dhcp4": {
    "ddns-replace-client-name": "always",
    ...
}

پیشوندی که در تولید FQDN استفاده می‌شود توسط پارامتر ddns-generated-prefix مشخص می‌گردد. مقدار پیش‌فرض "myhost" است. برای تغییر مقدار آن، کافی است آن را روی رشته مورد نظر تنظیم کنید:

"Dhcp4": {
    "ddns-generated-prefix": "another.host",
    ...
}

پسوندی که هنگام تولید یک FQDN یا هنگام کامل کردن (qualifying) یک نام جزئی استفاده می‌شود، توسط پارامتر ddns-qualifying-suffix مشخص می‌گردد. اکیداً توصیه می‌شود در صورت فعال بودن به‌روزرسانی‌های DDNS، کاربر مقداری برای این پسوند تعیین کند. به دلایل واضح، نمی‌توان مقدار پیش‌فرض معنی‌داری برای آن ارائه داد.

"Dhcp4": {
    "ddns-qualifying-suffix": "foo.example.org",
    ...
}

هنگام کامل کردن یک نام جزئی، kea-dhcp4 <#std-iscman-kea-dhcp4> نام را در این قالب می‌سازد:

[candidate-name].[ddns-qualifying-suffix].

که در آن candidate-name نام جزئی ارائه‌شده در DHCPREQUEST است. برای مثال، اگر مقدار نام دامنه FQDN برابر "some-computer" و مقدار ddns-qualifying-suffix برابر "example.com" باشد، FQDN تولیدشده عبارت است از:

some-computer.example.com.

هنگام تولید کل نام، kea-dhcp4 <#std-iscman-kea-dhcp4> نام را در این قالب می‌سازد:

[ddns-generated-prefix]-[address-text].[ddns-qualifying-suffix].

که در آن address-text صرفاً آدرس IP اجاره است که به یک رشته دارای خط پیوند (hyphenated) تبدیل شده است. برای مثال، اگر آدرس اجاره 172.16.1.10 باشد، پسوند تعیین‌شده "example.com" بوده، و مقدار پیش‌فرض برای ddns-generated-prefix استفاده شود، FQDN تولیدشده به صورت زیر خواهد بود:

myhost-172-16-1-10.example.com.

نکته:

هنگامی که کلاینت گزینه host name را ارسال می‌کند، kea-dhcp4 هرگز نقطه‌ای به نام میزبان در گزینه بازگردانده‌شده اضافه نمی‌کند. این نام تنها در صورتی با نقطه پایان می‌یابد که کلاینت آن را از قبل به صورت واجد شرایط و منتهی به نقطه ارسال کرده باشد. هنگامی که کلاینت گزینه FQDN را ارسال می‌کند، FQDN بازگردانده‌شده در پاسخ همیشه با یک نقطه خاتمه می‌یابد.

برخی کلاینت‌های DHCP ممکن است در گزینهٔ Host Name (کد گزینهٔ ۱۲) یا گزینهٔ FQDN (کد گزینهٔ ۸۱) مقادیری ارائه دهند که حاوی نویسه‌های نامطلوب باشد. امکان پیکربندی kea-dhcp4 <#std-iscman-kea-dhcp4> برای پاک‌سازی این مقادیر وجود دارد. رایج‌ترین مورد استفاده، اطمینان از این است که تنها نویسه‌های مجاز در RFC 1035 گنجانده شوند: A-Z، a-z، 0-9، و "-". این کار می‌تواند با استفاده از دو پارامتر زیر انجام شود:

  • hostname-char-set - یک عبارت باقاعده که مجموعه نویسه‌های نامعتبر را توصیف می‌کند. این می‌تواند هر عبارت باقاعدهٔ معتبری با استفاده از نحو عبارات باقاعدهٔ گسترش‌یافتهٔ POSIX باشد. نویسه‌های تهی توکار (0x00) همیشه به عنوان یک نویسهٔ نامعتبر برای جایگزینی (یا حذف) در نظر گرفته می‌شوند. پیش‌فرض "[^A-Za-z0-9.-]" است. این الگو با هر نویسه‌ای به جز یک حرف، رقم، نقطه یا خط تیره مطابقت دارد. اکیداً توصیه می‌شود که این پارامتر را روی یک رشتهٔ خالی ("") تنظیم نکنید، زیرا این کار اجازه می‌دهد نویسه‌های غیرقابل‌چاپ در بخش نام میزبان استفاده شوند.
  • hostname-char-replacement - رشته‌ای از صفر یا چند نویسه که هر نویسهٔ نامعتبر در نام میزبان با آن جایگزین می‌شود. یک رشتهٔ خالی باعث حذف شدن (OMITTED) نویسه‌های نامعتبر به جای جایگزینی آن‌ها می‌شود. پیش‌فرض "" است.

پیکربندی زیر هر چیزی به جز یک حرف، رقم، نقطه یا خط تیره را با حرف "x" جایگزین می‌کند:

"Dhcp4": {
    "hostname-char-set": "[^A-Za-z0-9.-]",
    "hostname-char-replacement": "x",
    ...
}

بنابراین، مقدار ارائه‌شده از سوی کلاینت مانند "myhost-$[123.org" تبدیل به "myhost-xx123.org" خواهد شد. پاک‌سازی تنها روی بخشی از نام انجام می‌شود که توسط کلاینت ارائه شده است، و پیش از اعمال یک پسوند توصیف‌کننده (qualifying suffix، در صورت تعریف و نیاز) انجام می‌پذیرد.

نکته:

هدف از پاک‌سازی نام، مهار موارد متداول‌تر نویسه‌های نامعتبر از طریق یک طرح نسبتاً سادهٔ جایگزینی نویسه است. طراحی طرحی که در تمامی موارد، هم برای گزینهٔ Host Name و هم برای گزینهٔ FQDN به خوبی کار کند دشوار است. مدیرانی که متوجه می‌شوند کلاینت‌هایی با حالات خاص و پیچیده از ترکیب نویسه‌ها دارند که به سادگی با این سازوکار قابل مدیریت نیست، باید نوشتن یک هوک (hook) را مد نظر قرار دهند که بتواند منطق به قدر کافی پیچیده‌ای را برای برآوردن نیازهای آن‌ها پیاده‌سازی کند.

اگر کلاینت‌ها نام‌های دامنه را در گزینهٔ Host Name بگنجانند و مدیر سیستم بخواهد این‌ها حفظ شوند، باید اطمینان حاصل کند که نقطه، "."، توسط عبارت hostname-char-set به عنوان یک نویسهٔ معتبر در نظر گرفته شده باشد، مانند این: "[^A-Za-z0-9.-]". این امر روی نقطه‌ها در مقادیر گزینهٔ FQDN تأثیری ندارد. هنگام پاک‌سازی FQDNها، نقطه‌ها به عنوان جداکننده در نظر گرفته شده و برای تفکیک مقدار گزینه به برچسب‌های دامنهٔ جداگانه استفاده می‌شوند که پاک‌سازی شده و سپس مجدداً سرهم می‌گردند.

اگر کلاینت‌ها مقادیری ارسال می‌کنند که تنها در نویسه‌هایی که توسط hostname-char-set نامعتبر شناخته شده‌اند تفاوت دارند، آگاه باشید که پاک‌سازی آن‌ها مقادیر یکسانی تولید خواهد کرد. در چنین مواردی، قواعد تداخل DDNS تنها به یکی از آن‌ها اجازهٔ ثبت نام را خواهد داد.

در نهایت، با توجه به دامنهٔ اختیاری که کلاینت‌ها در ارسال مقادیر دارند، عملاً غیرممکن است تضمین کرد که ترکیبی از این دو پارامتر همیشه نامی معتبر برای استفاده در DNS تولید کند. به عنوان مثال، استفاده از یک مقدار خالی برای hostname-char-replacement می‌تواند منجر به یک برچسب دامنهٔ خالی در یک نام شود، اگر آن برچسب تنها از نویسه‌های نامعتبر تشکیل شده باشد.

نکته:

امکان تعیین hostname-char-set و/یا hostname-char-replacement در حوزهٔ سراسری (global scope) وجود دارد.

کتابخانهٔ هوک کی libdhcp_ddns_tuning.so <#std-ischooklib-libdhcp_ddns_tuning.so> این امکان را هم برای kea-dhcp4 <#std-iscman-kea-dhcp4> و هم برای kea-dhcp6 <#std-iscman-kea-dhcp6> فراهم می‌کند تا نام‌های میزبان را به صورت رویه‌ای بر اساس یک عبارت تولید کنند، به‌روزرسانی‌های DDNS را به ازای هر کلاینت نادیده بگیرند، یا جنبه‌های مختلف به‌روزرسانی DNS را به‌دقت تنظیم نمایند. لطفاً برای گزینه‌های پیکربندی به مستندات libdhcp_ddns_tuning.so: DDNS Tuning <#hooks-ddns-tuning> مراجعه کنید.

نکته:

با شروع از Kea 3.1.3، هنگامی که پاک‌سازی منجر به یک رشتهٔ خالی شود، گزینه (hostname یا FQDN) به گونه‌ای نادیده گرفته خواهد شد که گویی کلاینت آن را ارسال نکرده است. این حالت زمانی رخ می‌دهد که مقدار ارسال‌شده توسط کلاینت تنها شامل نویسه‌هایی باشد که توسط عبارت در 'hostname-char-set' نامعتبر تشخیص داده شده‌اند و 'hostname-char-replacement' خالی باشد، "".

در برخی موارد، کلاینت‌ها تمایل دارند پیکربندی را از یک سرور TFTP دریافت کنند. اگرچه گزینهٔ اختصاصی برای این منظور وجود دارد، اما برخی دستگاه‌ها ممکن است از فیلد siaddr در بستهٔ DHCPv4 برای این هدف استفاده کنند. این فیلد خاص می‌تواند با استفاده از دستورالعمل next-server پیکربندی شود. امکان تعریف آن در حوزهٔ سراسری یا تنها برای یک زیرشبکهٔ مشخص وجود دارد. اگر هر دو تعریف شده باشند، مقدار زیرشبکه اولویت دارد. مقدار موجود در زیرشبکه می‌تواند روی "0.0.0.0" تنظیم شود، که به این معنی است که next-server نباید ارسال شود. همچنین می‌تواند روی یک رشتهٔ خالی تنظیم شود، که معادل با تعریف نشدن کامل آن است؛ یعنی از مقدار سراسری استفاده می‌کند.

دستورالعمل‌های server-hostname (که حامل یک نام میزبان سرور است، می‌تواند تا ۶۴ بایت طول داشته باشد، و در فیلد sname قرار دارد) و boot-file-name (که حامل فایل پیکربندی است، می‌تواند تا ۱۲۸ بایت طول داشته باشد، و با استفاده از فیلد file ارسال می‌شود) به همان شیوهٔ next-server مدیریت می‌شوند.

"Dhcp4": {
    "next-server": "192.0.2.123",
    "boot-file-name": "/dev/null",
    "subnet4": [
        {
            "next-server": "192.0.2.234",
            "server-hostname": "some-name.example.org",
            "boot-file-name": "bootfile.efi",
            ...
        }
    ],
    ...
}

مشخصات اصلی DHCPv4 (سند RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131) بیان می‌کند که سرور DHCPv4 نباید هنگام پاسخ‌گویی به کلاینت‌ها، گزینه‌های client-id را بازپس بفرستد. با این وجود، در برخی موارد این امر باعث سردرگمی کلاینت‌هایی می‌شود که فاقد نشانی MAC یا client-id هستند؛ برای جزئیات به RFC 6842 https://datatracker.ietf.org/doc/html/rfc6842 مراجعه کنید. این رفتار با انتشار RFC 6842 https://datatracker.ietf.org/doc/html/rfc6842 تغییر کرد، که RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131 را به‌روزرسانی نمود. آن به‌روزرسانی بیان می‌کند که اگر کلاینت گزینه client-id را فرستاده باشد سرور باید آن را بازپس بفرستد، و این رفتار پیش‌فرض Kea است. با این حال، در بعضی موارد ممکن است دستگاه‌های قدیمی‌تری که از RFC 6842 https://datatracker.ietf.org/doc/html/rfc6842 پشتیبانی نمی‌کنند، از پذیرش پاسخ‌های حاوی گزینه client-id خودداری کنند. برای فعال‌سازی سازگاری رو به عقب، یک پارامتر پیکربندی اختیاری معرفی شده است. برای پیکربندی آن، از عبارت پیکربندی زیر استفاده کنید:

"Dhcp4": {
    "echo-client-id": false,
    ...
}

سرور DHCP باید بتواند کلاینتی را که پیامی از آن دریافت می‌کند شناسایی کرده و آن را از سایر کلاینت‌ها تمایز دهد. دلایل متعددی برای الزام این شناسایی وجود دارد که مهم‌ترین آن‌ها عبارت‌اند از:

  • هنگامی که کلاینت برای تخصیص یک اجاره (lease) جدید با سرور ارتباط برقرار می‌کند، سرور باید اطلاعات شناسایی کلاینت را به عنوان کلید جستجو در پایگاه‌داده اجاره ذخیره کند.
  • هنگامی که کلاینت تلاش می‌کند اجاره موجود را تمدید کند یا آزاد سازد، سرور باید بتواند با استفاده از اطلاعات شناسایی کلاینت به عنوان یک کلید جستجو، مدخل اجاره موجود در پایگاه‌داده را برای این کلاینت پیدا کند.
  • برخی پیکربندی‌ها از رزروهای ایستا (static reservations) برای نشانی‌های IP و سایر اطلاعات پیکربندی استفاده می‌کنند. مدیر سرور از اطلاعات شناسایی کلاینت برای ایجاد این تخصیص‌های ایستا بهره می‌برد.
  • در شبکه‌های دوپشته‌ای (dual-stack) اغلب نیاز است که اطلاعات اجاره ذخیره‌شده در سرورهای DHCPv4 و DHCPv6 برای یک میزبان مشخص با یکدیگر تطبیق داده شوند. استفاده از اطلاعات شناسایی مشترک توسط کلاینت‌های DHCPv4 و DHCPv6 به مدیر شبکه اجازه می‌دهد تا این همبستگی را برقرار ساخته و شبکه را بهتر اداره نماید. از نگارش 2.1.2 به بعد، Kea از DUIDهای DHCPv6 تعبیه‌شده در گزینه‌های Client Identifier پروتکل DHCPv4، مطابق با آنچه در RFC 4361 https://datatracker.ietf.org/doc/html/rfc4361 تشریح شده، پشتیبانی می‌کند.

پروتکل DHCPv4 از دو شناسه متمایز استفاده می‌کند که توسط کلاینت در پرس‌وجوهای ارسالی به سرور قرار می‌گیرند و توسط سرور در پاسخ‌های ارسالی به کلاینت کپی می‌شوند: chaddr و client-identifier. مورد نخست به عنوان بخشی از مشخصات BOOTP معرفی شد و همچنین توسط DHCP برای حمل نشانی سخت‌افزاری رابطی که برای ارسال پرس‌وجو به سرور به کار رفته است (نشانی MAC برای اترنت) استفاده می‌شود. مورد دوم در گزینه client-identifier حمل می‌شود که در RFC 2132 https://datatracker.ietf.org/doc/html/rfc2132 معرفی شده است.

سند RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131 مشخص می‌کند که سرور می‌تواند از هر دوی این شناسه‌ها برای شناسایی کلاینت استفاده کند، اما در صورت حضور شناسه کلاینت، بر chaddr اولویت و ارجحیت دارد. یکی از دلایل این امر آن است که شناسه کلاینت مستقل از سخت‌افزاری است که کلاینت برای برقراری ارتباط با سرور به کار می‌برد. برای مثال، اگر کلاینت با استفاده از یک کارت شبکه اجاره را دریافت کند و سپس کارت شبکه به میزبان دیگری منتقل شود، سرور به اشتباه آن میزبان دیگر را همان دریافت‌کننده اجاره شناسایی خواهد کرد. افزون بر این، سند RFC 4361 https://datatracker.ietf.org/doc/html/rfc4361 توصیه می‌کند که هنگام استفاده از شبکه‌های دوپشته‌ای، از یک DUID (ببینید RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915، مشخصات DHCPv6) که به عنوان یک شناسه کلاینت حمل می‌شود استفاده گردد تا بدون توجه به نوع پروتکل مورد استفاده، اطلاعات شناسایی یکپارچه‌ای برای کلاینت ارائه شود. Kea به این مشخصات پایبند است، و شناسه کلاینت به طور پیش‌فرض هنگام جستجو، ایجاد، به‌روزرسانی یا حذف اجاره کلاینت توسط سرور، بر مقدار موجود در فیلد chaddr اولویت دارد.

هنگامی که سرور یک پیام DHCPDISCOVER یا DHCPREQUEST از کلاینت دریافت می‌کند، سعی می‌کند بررسی کند که آیا کلاینت از پیش اجاره‌ای در پایگاه‌داده دارد یا خیر؛ در صورتی که داشته باشد، سرور به جای تخصیص اجاره‌ای نو، همان اجاره را واگذار می‌کند. هر اجاره در پایگاه‌داده اجاره‌ها با شناسه کلاینت و/یا chaddr مرتبط است. سرور ابتدا از شناسه کلاینت (در صورت وجود) برای جستجوی اجاره استفاده می‌کند؛ اگر موردی یافت شود، سرور این اجاره را متعلق به کلاینت در نظر می‌گیرد، حتی اگر chaddr کنونی و chaddr مرتبط با اجاره مطابقت نداشته باشند. این ویژگی فرایند سناریویی را آسان می‌کند که در آن، کارت شبکه سامانه کلاینت تعویض شده و در نتیجه نشانی MAC جدیدی در پیام‌های ارسالی کلاینت DHCP ظاهر می‌شود. اگر سرور موفق به یافتن اجاره با استفاده از شناسه کلاینت نشود، جستجوی دیگری را با استفاده از chaddr انجام می‌دهد. اگر این جستجو نیز نتیجه‌ای در بر نداشته باشد، کلاینت فاقد اجاره در نظر گرفته شده و یک اجاره جدید ایجاد می‌شود.

یک مشکل متداول که توسط گردانندگان شبکه گزارش می‌شود این است که پیاده‌سازی‌های ضعیف کلاینت‌ها از شناسه‌های کلاینت پایدار استفاده نمی‌کنند و در عوض، با هر بار اتصال کلاینت به شبکه، یک شناسه کلاینت جدید تولید می‌کنند. مورد شناخته‌شده دیگر این است که کلاینت شناسه کلاینت خود را در طول فرایند بوت چندمرحله‌ای (PXE) تغییر می‌دهد. در چنین مواردی، نشانی MAC رابط کلاینت ثابت می‌ماند، و استفاده از فیلد chaddr برای شناسایی کلاینت تضمین می‌کند که آن سامانه خاص با وجود تغییر یافتن شناسه کلاینتش، به عنوان همان کلاینت واحد شناخته شود.

برای رفع این مشکل، Kea شامل یک گزینه پیکربندی است که شناسایی کلاینت را تنها با استفاده از chaddr امکان‌پذیر می‌سازد. این امر به سرور دستور می‌دهد که در طول جستجوها و تخصیص‌های اجاره برای یک زیرشبکه خاص، شناسه کلاینت را نادیده بگیرد. پیکربندی ساده‌شده زیر از سرور را در نظر بگیرید:

{
  "Dhcp4": {
    "match-client-id": true,
    "subnet4": [
    {
        "id": 1,
        "subnet": "192.0.10.0/24",
        "pools": [ { "pool": "192.0.2.23-192.0.2.87" } ],
        "match-client-id": false
    },
    {
        "id": 1,
        "subnet": "10.0.0.0/8",
        "pools": [ { "pool": "10.0.0.23-10.0.2.99" } ]
    }
    ]
  }
}

پارامتر match-client-id یک مقدار بولی است که این رفتار را کنترل می‌کند. مقدار پیش‌فرض true نشان می‌دهد که سرور از شناسه کلاینت برای جستجوهای اجاره استفاده می‌کند و اگر جستجوی نخست نتیجه‌ای در بر نداشته باشد به سراغ chaddr می‌رود. مقدار false بدین معناست که سرور تنها از chaddr برای جستجوی اجاره کلاینت استفاده خواهد کرد. اینکه DHCID برای به‌روزرسانی‌های DNS از شناسه کلاینت تولید شود یا از chaddr نیز از طریق همین پارامتر کنترل می‌شود.

پارامتر match-client-id می‌تواند هم در محدوده پیکربندی سراسری و هم ذیل هر اعلان زیرشبکه‌ای قرار گیرد. در مثال نشان‌داده‌شده در بالا، مقدار مؤثر match-client-id برای زیرشبکه 192.0.10.0/24 برابر با false خواهد بود، زیرا تنظیم مختص زیرشبکه این پارامتر بر مقدار سراسری آن اولویت داشته و آن را بازنویسی می‌کند. مقدار مؤثر match-client-id برای زیرشبکه 10.0.0.0/8 برابر با true تنظیم خواهد شد، زیرا اعلان زیرشبکه فاقد این پارامتر است و تنظیم سراسری به طور پیش‌فرض برای این زیرشبکه استفاده می‌شود. در واقع، در این حالت می‌شد از آوردن مدخل سراسری این پارامتر صرف‌نظر کرد، چرا که true مقدار پیش‌فرض است.

درک این موضوع حائز اهمیت است که در صورت دریافت اجاره توسط کلاینت تحت یک تنظیم از match-client-id و تمدید آن پس از تغییر یافتن این تنظیم، چه اتفاقی رخ می‌دهد. نخست، حالتی را در نظر بگیرید که کلاینت اجاره را دریافت می‌کند و match-client-id روی true تنظیم شده است. سرور اطلاعات اجاره را، شامل شناسه کلاینت (در صورت ارائه) و chaddr، در پایگاه‌داده اجاره ذخیره می‌کند. زمانی که این تنظیم تغییر کند و کلاینت اقدام به تمدید اجاره نماید، سرور تعیین می‌کند که باید از chaddr برای جستجوی اجاره موجود استفاده کند. اگر کلاینت نشانی MAC خود را تغییر نداده باشد، سرور باید با موفقیت اجاره موجود را بیابد. شناسه کلاینت مرتبط با اجاره بازگردانده‌شده نادیده گرفته خواهد شد و به کلاینت اجازه داده می‌شود تا از این اجاره استفاده کند. هنگام تمدید اجاره، مطابق با تنظیمات جدید سرور، تنها chaddr برای این اجاره ثبت خواهد شد.

در حالت دوم، کلاینت دارای اجاره‌ای است که تنها مقدار chaddr برای آن ثبت شده است. هنگامی که تنظیم match-client-id به true تغییر می‌یابد، سرور ابتدا سعی می‌کند از شناسه کلاینت برای پیدا کردن اجاره موجود کلاینت استفاده کند. این جستجو هیچ نتیجه‌ای در بر نخواهد داشت زیرا شناسه کلاینت برای این اجاره ثبت نشده بود. سپس سرور از chaddr استفاده خواهد کرد و اجاره یافت خواهد شد. اگر به نظر برسد که در اجاره هیچ شناسه کلاینتی ثبت نشده است، سرور فرض می‌کند که این اجاره متعلق به همین کلاینت است و با تنظیم پیشین match-client-id ایجاد شده است. با این حال، اگر اجاره حاوی شناسه کلاینتی باشد که با شناسه کلاینت استفاده‌شده توسط کلاینت متفاوت است، فرض می‌شود که اجاره به کلاینت دیگری تعلق دارد و یک اجاره جدید تخصیص داده خواهد شد.

برای نمای بصری‌تری از چگونگی بازشناسی کلاینت یکسان توسط Kea، لطفاً به بخش How Kea Recognizes the Same Client In Different DHCP Messages <#uml-recognizing-same-client> مراجعه فرمایید..SS رفتار کارگزار مقتدر DHCPv4

مشخصات اصلی DHCPv4 (RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131) بیان می‌کند که اگر یک کلاینت در وضعیت INIT-REBOOT آدرسی را درخواست کند که کارگزار شناختی از آن ندارد، کارگزار باید پاسخی ندهد (سکوت کند)، مگر اینکه کارگزار بداند کلاینت یک آدرس IP از شبکه اشتباه درخواست کرده است. به‌طور پیش‌فرض، Kea به جای این مشخصات، از رفتار دیمن ISC dhcpd پیروی می‌کند و در صورتی هم که کلاینت آدرس IP از شبکه اشتباه درخواست کند پاسخی نمی‌دهد، زیرا مشخص نیست که اطلاعات پیکربندی یک بخش شبکه (سگمنت) مشخص حتماً صحیح باشد. Kea تنها در صورتی درخواست DHCPREQUEST کلاینت را با یک پیام DHCPNAK رد می‌کند که از قبل اجاره‌ای (lease) برای آن کلاینت با یک آدرس IP متفاوت داشته باشد. مدیران سیستم می‌توانند با استفاده از تنظیم بولی authoritative (به‌طور پیش‌فرض false) این رفتار را تغییر دهند.

در حالت مقتدر، زمانی که authoritative روی true تنظیم شده باشد، Kea همواره درخواست‌های INIT-REBOOT کلاینت‌های ناشناس را با پیام‌های DHCPNAK رد می‌کند. تنظیم authoritative می‌تواند در حوزه پیکربندی سراسری (global)، شبکه اشتراکی (shared-network) و زیرشبکه (subnet) مشخص شود و در صورت عدم تعیین، به‌طور خودکار از حوزه والد به ارث برده می‌شود. تمام زیرشبکه‌ها در یک shared-network باید تنظیم authoritative یکسانی داشته باشند.

پشتیبانی از انتقال DHCPv4-over-DHCPv6 در RFC 7341 https://datatracker.ietf.org/doc/html/rfc7341 شرح داده شده است و با استفاده از همکاری کارگزارهای DHCPv4 و DHCPv6 پیاده‌سازی می‌شود. این بخش به پیکربندی سمت DHCPv4 می‌پردازد (سمت DHCPv6 در بخش DHCPv4-over-DHCPv6: سمت DHCPv6 <#dhcp6-dhcp4o6-config> شرح داده شده است).

نکته:

جزئیات ارتباط بین‌پردازشی در DHCPv4-over-DHCPv6 ممکن است تغییر کند؛ برای نمونه، پشتیبانی از رله پورت (RFC 8357) تغییری ناسازگار ایجاد کرد. هر دو سمت DHCPv4 و DHCPv6 باید از نسخه یکسانی از Kea استفاده کنند.

پارامتر سراسری dhcp4o6-port نخستین پورت از دو پورت متوالی سوکت‌های UDP مورد استفاده برای ارتباط میان کارگزارهای DHCPv6 و DHCPv4 را مشخص می‌کند. کارگزار DHCPv4 روی ::1 در port + 1 متصل (bound) شده و به ::1 در port متصل می‌شود.

در DHCPv4-over-DHCPv6، کارگزار DHCPv4 به چندین شناسه که به‌طور معمول برای انتخاب زیرشبکه استفاده می‌کرد دسترسی ندارد. برای رفع این مشکل، سه مدخل پیکربندی جدید فراهم شده است؛ وجود هر یک از این‌ها به زیرشبکه اجازه می‌دهد با DHCPv4-over-DHCPv6 استفاده شود. این مدخل‌ها عبارتند از:

  • 4o6-subnet: یک پیشوند (یعنی یک آدرس IPv6 به همراه اسلش و طول پیشوند) دریافت می‌کند که با آدرس مبدأ تطبیق داده می‌شود.
  • 4o6-interface-id: مقدار گزینه شناسه رابط رله را دریافت می‌کند.
  • 4o6-interface: نام یک رابط را دریافت می‌کند که با نام رابط ورودی تطبیق داده می‌شود.

شرکت ISC پیکربندی زیر را آزمایش کرده است:

{
# DHCPv4 conf
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [ "eno33554984" ]
    },
    "lease-database": {
        "type": "memfile",
        "name": "leases4"
    },
    "valid-lifetime": 4000,
    "subnet4": [
    {
        "id": 1,
        "subnet": "10.10.10.0/24",
        "4o6-interface": "eno33554984",
        "4o6-subnet": "2001:db8:1:1::/64",
        "pools": [ { "pool": "10.10.10.100 - 10.10.10.199" } ]
    }
    ],
    "dhcp4o6-port": 786,
    "loggers": [
    {
        "name": "kea-dhcp4",
        "output-options": [
        {
            "output": "kea-dhcp4.log"
        }
        ],
        "severity": "DEBUG",
        "debuglevel": 0
    }
    ]
}
}

یک جنبه مهم در اجرای صحیح سامانه DHCP، اطمینان از سازگاری داده‌ها است؛ با این حال، در برخی موارد ممکن است تحمل برخی از داده‌های ناسازگار مناسب باشد. برای نمونه، مدیر شبکه‌ای که موقتاً یک زیرشبکه را از پیکربندی حذف می‌کند، مایل نیست تمامی اجاره‌های مرتبط با آن از پایگاه‌داده اجاره‌ها ناپدید شوند. Kea سازوکاری برای اجرای بررسی‌های صحت (sanity checks) در چنین شرایطی دارد.

‏Kea از یک حوزه پیکربندی به نام sanity-checks پشتیبانی می‌کند. پارامتری به نام lease-checks، بر اعتبارسنجی انجام‌شده هنگام بارگیری یک اجاره جدید از فایل اجاره نظارت دارد. این سازوکار به Kea امکان می‌دهد تا برای اصلاح داده‌های ناسازگار تلاش کند.

هر زیرشبکه یک مقدار subnet-id دارد؛ این روشی است که Kea به‌صورت داخلی زیرشبکه‌ها را شناسایی می‌کند. هر اجاره نیز یک پارامتر subnet-id دارد که مشخص می‌کند متعلق به کدام زیرشبکه است. با این حال، در صورت تغییر پیکربندی، ممکن است اجاره‌ای با یک subnet-id وجود داشته باشد اما هیچ زیرشبکه منطبقی با آن یافت نشود. همچنین ممکن است پیکربندی زیرشبکه تغییر یافته باشد و اکنون subnet-id متعلق به زیرشبکه‌ای باشد که با اجاره همخوانی ندارد.

الگوریتم تصحیح Kea ابتدا بررسی می‌کند که آیا زیرشبکه‌ای با subnet-id مشخص‌شده توسط اجاره وجود دارد یا خیر. اگر وجود داشته باشد، بررسی می‌کند که آیا اجاره متعلق به آن زیرشبکه است یا خیر. در غیر این صورت، بسته به تنظیم lease-checks، اجاره نادیده گرفته می‌شود، هشداری نمایش داده می‌شود، یا زیرشبکه جدیدی برای اجاره انتخاب می‌شود که از لحاظ توپولوژیکی با آن مطابقت دارد.

پنج سطح پشتیبانی می‌شود:

  • none - هیچ بررسی خاصی انجام نده؛ اجاره را همان‌طور که هست بپذیر.
  • warn - در صورت تشخیص مشکل هشدار نمایش بده، اما در هر حال داده‌های اجاره را بپذیر. این مقدار پیش‌فرض است.
  • fix - در صورت مشاهده ناسازگاری در داده‌ها، سعی کن آن را تصحیح کنی. اگر تصحیح موفقیت‌آمیز نبود، داده‌های نادرست را در هر صورت درج کن.
  • fix-del - در صورت مشاهده ناسازگاری در داده‌ها، سعی کن آن را تصحیح کنی. اگر تصحیح موفقیت‌آمیز نبود، اجاره را رد کن. این تنظیم صحت داده‌ها را تضمین می‌کند، اما ممکن است برخی از داده‌های نادرست از دست بروند. با احتیاط استفاده شود.
  • del - در صورت تشخیص هرگونه ناسازگاری، اجاره را رد کن. این سخت‌گیرانه‌ترین حالت است؛ با احتیاط استفاده شود.

این قابلیت در حال حاضر برای بک‌اند memfile پیاده‌سازی شده است. بررسی صحت بر روی پایگاه‌داده اجاره در حافظه اعمال می‌شود، نه بر روی فایل اجاره؛ بدین معنا که اجاره‌های ناسازگار در فایل اجاره باقی می‌مانند.

یک نمونه پیکربندی که این پارامتر را تنظیم می‌کند به شرح زیر است:

"Dhcp4": {
    "sanity-checks": {
        "lease-checks": "fix-del"
    },
    ...
}

برای پشتیبانی از قابلیت‌هایی مانند DHCP Leasequery (RFC 4388 https://datatracker.ietf.org/doc/html/rfc4388) و گزینه‌های stash agent (Stash Agent Options)، باید اطلاعات اضافی به همراه هر اجاره (lease) ذخیره شود. از آنجا که حجم اطلاعات برای هر اجاره پیامدهایی از نظر کارایی و مصرف منابع سیستم به دنبال دارد، ذخیره‌سازی این اطلاعات اضافی از طریق پارامتر store-extended-info قابل پیکربندی است. مقدار پیش‌فرض آن false است و می‌تواند در سطوح global، shared-network و subnet تنظیم شود.

"Dhcp4": {
    "store-extended-info": true,
    ...
}

هنگامی که روی true تنظیم شود، اطلاعات مربوط به DHCPREQUEST درخواست‌کنندهٔ اجاره به عنوان یک عنصر نگاشت با برچسب "ISC" به زمینهٔ کاربر (user context) اجاره اضافه می‌شود. هنگامی که DHCPREQUEST دریافت‌شده حاوی گزینهٔ (DHCP Option 82) باشد، این نگاشت شامل نگاشت relay-agent-info با محتوای گزینهٔ (DHCP Option 82) در مدخل sub-options و در صورت وجود، گزینه‌های remote-id و relay-id خواهد بود. از آنجا که بعید است پیام‌های DHCPREQUEST ارسال‌شده به عنوان تمدید حاوی این اطلاعات باشند، مقادیر برگرفته از آخرین DHCPREQUEST که حاوی آن بوده است در اجاره حفظ می‌شوند. زمینهٔ کاربر اجاره شبیه به این خواهد بود:

{ "ISC": { "relay-agent-info": { "sub-options": "0x0104AABBCCDD" } } }

یا همراه با زیرگزینه‌های remote و relay:

{
    "ISC": {
        "relay-agent-info": {
            "sub-options": "0x02030102030C03AABBCC",
            "remote-id": "03010203",
            "relay-id": "AABBCC"
        }
    }
}

نکته:

ممکن است سایر کتابخانه‌های قلاب (hook libraries) از قبل در حال استفاده از user-context باشند. فعال کردن store-extended-info نباید با هیچ‌یک از محتویات دیگر user-context تداخلی ایجاد کند، تا زمانی که آن‌ها نیز از عنصری با برچسب "ISC" استفاده نکنند. به بیان دیگر، user-context به عنوان محفظه‌ای انعطاف‌پذیر برای مقاصد متعدد در نظر گرفته شده است. تا زمانی که هدف دیگری نیز عنصری با نام "ISC" را در user-context ننویسد، تعارضی رخ نخواهد داد.

اطلاعات گسترش‌یافتهٔ اجاره همچنین مشمول بررسی صحت (sanity checking) قابل پیکربندی است. پارامتر موجود در محدودهٔ sanity-checks با نام extended-info-checks شناخته می‌شود و از این سطوح پشتیبانی می‌کند:

  • none - هیچ بررسی یا ارتقایی انجام ندهد. این سطح تنها زمانی باید استفاده شود که اطلاعات گسترش‌یافته اصلاً استفاده نمی‌شود یا انتظار نمی‌رود اطلاعات گسترش‌یافته با قالب‌بندی نادرست (از جمله استفاده از قالب قدیمی) وجود داشته باشد.
  • fix - رفع برخی ناسازگاری‌های متداول و ارتقای اطلاعات گسترش‌یافته با قالب قدیمی به قالب جدید. این سطح پیش‌فرض است و زمانی که کتابخانهٔ قلاب Leasequery بارگذاری نشده باشد، مناسب است.
  • strict - رفع تمامی ناسازگاری‌هایی که روی کتابخانهٔ قلاب (Bulk) Leasequery تأثیر دارند.
  • pedantic - اعمال انطباق کامل با قالبی که توسط کد Kea تولید می‌شود؛ به عنوان مثال، هیچ مدخل اضافی به جز comment مجاز نیست.

نکته:

این قابلیت در حال حاضر تنها برای بک‌اند memfile پیاده‌سازی شده است. بررسی صحت بر روی پایگاه‌دادهٔ اجاره در حافظه اعمال می‌شود، نه روی فایل اجاره؛ بدین معنا که اجاره‌های ناسازگار در فایل اجاره باقی می‌مانند.

این پارامتر سراسری در نگارش 2.5.8 اضافه شد تا رفتاری مشابه قابلیتی را ارائه دهد که پیش‌تر در ISC DHCP در دسترس بود. هنگامی که پارامتر stash-agent-options روی true باشد، کارساز گزینه‌های اطلاعات کارگزار رله (relay agent information options) ارسال‌شده در پیام DHCPREQUEST اولیهٔ کلاینت (زمانی که کلاینت در وضعیت SELECTING بود) را ضبط می‌کند و به گونه‌ای عمل می‌کند که گویی آن گزینه‌ها در تمامی پیام‌های DHCPREQUEST بعدی که در وضعیت RENEWING ارسال می‌شوند گنجانده شده‌اند. این سازوکار مشکلی را دور می‌زند که در آن گزینه‌های اطلاعات کارگزار رله معمولاً در پیام‌های DHCPREQUEST ارسال‌شده توسط کلاینت در وضعیت RENEWING ظاهر نمی‌شوند؛ زیرا این پیام‌ها به صورت unicast مستقیماً به کارساز ارسال شده و از طریق یک کارگزار رله فرستاده نمی‌شوند.

مقدار پیش‌فرض false است.

کارساز Kea می‌تواند به گونه‌ای پیکربندی شود که بسته‌ها را به صورت موازی با استفاده از چندین ریسمان (thread) پردازش کند. این تنظیمات در ساختار multi-threading یافت می‌شوند و عبارتند از:

  • enable-multi-threading - استفاده از چندین ریسمان برای پردازش موازی بسته‌ها. مقدار پیش‌فرض true است.
  • thread-pool-size - تعیین تعداد ریسمان‌ها برای پردازش موازی بسته‌ها. می‌تواند روی 0 (تشخیص خودکار)، یا هر عدد مثبتی که تعداد ریسمان را به صراحت مشخص کند، تنظیم شود. مقدار پیش‌فرض 0 است.
  • packet-queue-size - تعیین اندازهٔ صف مورد استفاده توسط استخر ریسمان (thread pool) جهت پردازش بسته‌ها. می‌تواند روی 0 (نامحدود)، یا هر عدد مثبتی که اندازهٔ صف را به صراحت تعیین می‌کند، تنظیم شود. مقدار پیش‌فرض 64 است.

یک نمونه پیکربندی که این پارامترها را تنظیم می‌کند به صورت زیر است:

"Dhcp4": {
    "multi-threading": {
       "enable-multi-threading": true,
       "thread-pool-size": 4,
       "packet-queue-size": 16
    },
    ...
}

سرور Kea DHCPv4 توسط ISC محک‌زنی می‌شود تا مشخص شود کدام تنظیمات بهترین کارایی را ارائه می‌دهند. اگرچه این بخش نتایج ما را شرح می‌دهد، اما آنها صرفاً پیشنهاد هستند و به سخت‌افزار خاص مورد استفاده برای محک‌زنی بسیار وابسته‌اند. ما اکیداً توصیه می‌کنیم که مدیران سیستم محک‌زنی‌های کارایی خود را اجرا کنند.

گزارش کاملی از نتایج عملکرد برای آخرین نسخه پایدار Kea را می‌توان در اینجا https://reports.kea.isc.org مشاهده کرد. این گزارش شامل شرح سخت‌افزار و سناریوهای محک‌زنی، و همچنین نتایج کنونی است.

پس از فعال‌سازی چندریسمانی (multi-threading)، تعداد ریسمان‌ها با پارامتر thread-pool-size تنظیم می‌شود. نتایج حاصل از آزمایش‌های ما نشان می‌دهد که بهترین تنظیمات برای kea-dhcp4 <#std-iscman-kea-dhcp4> عبارتند از:

  • thread-pool-size: مقدار ۴ هنگام استفاده از memfile برای ذخیره اجاره‌ها.
  • thread-pool-size: مقدار ۱۲ یا بیشتر هنگام استفاده از mysql برای ذخیره اجاره‌ها.
  • thread-pool-size: مقدار ۸ هنگام استفاده از postgresql.

پارامتر بسیار مهم دیگر packet-queue-size است؛ در محک‌زنی‌هایمان، ما از آن به عنوان ضریبی از thread-pool-size استفاده کردیم. مقدار واقعی به شدت به thread-pool-size وابسته است.

ما در محک‌زنی‌های خود بهترین نتایج را با تنظیمات زیر مشاهده کردیم:

  • packet-queue-size: برابر با 7 * thread-pool-size هنگام استفاده از memfile برای ذخیره اجاره‌ها؛ در مورد ما 7 * 4 = 28 بود. این بدان معناست که در هر زمان، حداکثر تا ۲۸ بسته می‌توانست در صف قرار گیرد.
  • packet-queue-size: برابر با 66 * thread-pool-size هنگام استفاده از mysql برای ذخیره اجاره‌ها؛ در مورد ما 66 * 12 = 792 بود. این بدان معناست که حداکثر تا ۷۹۲ بسته می‌توانست در صف قرار گیرد.
  • packet-queue-size: برابر با 11 * thread-pool-size هنگام استفاده از postgresql برای ذخیره اجاره‌ها؛ در مورد ما 11 * 8 = 88 بود.

سند RFC 8925 https://datatracker.ietf.org/doc/html/rfc8925 که اخیراً توسط IETF منتشر شده است، یک گزینه DHCPv4 را تعیین می‌کند تا نشان دهد میزبان از حالت فقط IPv6 پشتیبانی می‌کند و در صورتی که شبکه اتصال IPv6 را فراهم کند، مایل است از دریافت آدرس IPv4 صرف‌نظر کند. ایده کلی این است که مدیر شبکه می‌تواند این گزینه را فعال کند تا به دستگاه‌های دوپشته‌ای (dual-stack) سازگار سیگنال دهد که اتصال IPv6 در دسترس است و می‌توانند پشته IPv4 خود را خاموش کنند. محتوای گزینه جدید v6-only-preferred یک عدد صحیح ۳۲ بیتی بدون علامت است و مشخص می‌کند که دستگاه چه مدت باید پشته خود را غیرفعال کند. این مقدار به ثانیه بیان می‌شود.

این RFC به تایمر V6ONLY_WAIT اشاره می‌کند. این قابلیت در Kea با تنظیم مقدار گزینه v6-only-preferred پیاده‌سازی شده است. این روند از شیوه معمول تنظیم گزینه‌ها پیروی می‌کند؛ مقدار گزینه را می‌توان در سطوح pool، subnet، shared network یا سطوح سراسری (global)، یا حتی از طریق رزروهای میزبان (host reservations) مشخص کرد.

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

{
"subnet4": [
    {
        "id": 1,
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
        "subnet": "192.0.2.0/24",
        "option-data": [
            {
                // This will make the v6-only capable devices to disable their
                // v4 stack for half an hour and then try again
                "name": "v6-only-preferred",
                "data": "1800"
            }
        ]
    }
],
...
}

کارخواه‌هایی که در مدت‌زمانی کوتاه اقدام به تمدید مکرر می‌کنند می‌توانند موجب شوند که سرور مرتباً پایگاه‌داده را به‌روزرسانی کرده و روی آن بنویسد، که نتیجه آن افت کارایی سرور خواهد بود. پارامترهای کش به سرور DHCP دستور می‌دهند که از به‌روزرسانی بیش از حد اجاره‌ها خودداری کند و بدین ترتیب از این رفتار جلوگیری شود. در عوض، سرور همان اجاره را بدون هیچ تغییری به جز CLTT (زمان آخرین ارسال کارخواه یا Client Last Transmission Time) که نیازی به عملیات دیسک ندارد، تخصیص می‌دهد (یعنی از آن مجدداً استفاده می‌کند).

این دو پارامتر عبارتند از عدد اعشاری cache-threshold و عدد صحیح cache-max-age. این پارامترها را می‌توان در سطوح global، shared-network و subnet پیکربندی کرد. سطح subnet بر سطح shared-network اولویت دارد، در حالی که از سطح global به عنوان آخرین راهکار استفاده می‌شود. برای مثال:

{
"subnet4": [
    {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
        "subnet": "192.0.2.0/24",
        "cache-threshold": .25,
        "cache-max-age": 600,
        "valid-lifetime": 2000,
        ...
    }
],
...
}

نکته:

از نسخه Kea 3.0.0، مقدار پیش‌فرض برای cache-threshold برابر 0.25 است در حالی که cache-max-age نامشخص رها شده است. این بدان معناست که کش کردن اجاره‌ها به صورت پیش‌فرض فعال است. می‌توان آن را در محدوده مورد نظر با تنظیم cache-threshold روی 0.0 یا تنظیم cache-max-age روی 0 غیرفعال کرد.

هنگامی که یک اجاره از پیش واگذار شده بتواند پاسخگوی پرس‌وجوی کارخواه باشد:

  • هرگونه تغییر مهم، مانند پارامتر DDNS، نام میزبان یا کاهش طول عمر معتبر، اجاره را غیرقابل استفاده مجدد می‌کند.
  • سن اجاره، یعنی اختلاف بین زمان ایجاد یا آخرین ویرایش و زمان فعلی محاسبه می‌شود (مدت‌زمان سپری‌شده).
  • اگر cache-max-age به طور صریح پیکربندی شده باشد، با سن اجاره مقایسه می‌شود؛ اجاره‌هایی که بیش از حد قدیمی باشند قابل استفاده مجدد نیستند. این بدان معناست که مقدار 0 برای cache-max-age قابلیت کش اجاره را غیرفعال می‌کند.
  • اگر cache-threshold به طور صریح پیکربندی شده و بین 0.0 و 1.0 باشد، درصدی از طول عمر معتبر اجاره را بیان می‌کند که برای سن اجاره مجاز شمرده می‌شود. مقادیر کمتر و مساوی 0.0 و مقادیر بزرگتر از 1.0 قابلیت کش اجاره را غیرفعال می‌کنند.

در مثال ما، اجاره‌ای با طول عمر معتبر ۲۰۰۰ ثانیه در صورتی می‌تواند مجدداً استفاده شود که کمتر از ۵۰۰ ثانیه پیش ثبت شده باشد. با طول عمر ۳۰۰۰ ثانیه، حداکثر سن ۶۰۰ ثانیه اعمال می‌شود.

در پاسخ‌های ارسالی به کارخواه (مانند پیام‌های DHCPACK)، گزینه dhcp-lease-time روی طول عمر معتبر قابل استفاده مجدد تنظیم می‌شود، یعنی تاریخ انقضا تغییر نمی‌کند. سایر گزینه‌های مبتنی بر طول عمر معتبر، مانند dhcp-renewal-time و dhcp-rebinding-time نیز به طول عمر قابل استفاده مجدد وابسته هستند..SS "تخصیص موقت در DHCPDISCOVER"

به‌طور پیش‌فرض، kea-dhcp4 <#std-iscman-kea-dhcp4> هنگام پیشنهاد دادن یک آدرس به کلاینت در پاسخ به یک DHCPDISCOVER، اجاره‌ای را تخصیص نداده یا ذخیره نمی‌کند. به‌طور کلی، kea-dhcp4 <#std-iscman-kea-dhcp4> می‌تواند با به تعویق انداختن تخصیص و ذخیره‌سازی اجاره تا زمان دریافت DHCPREQUESTها برای آن‌ها، درخواست‌های کلاینت را سریع‌تر برآورده کند. پارامتر offer-lifetime در kea-dhcp4 <#std-iscman-kea-dhcp4> (زمانی که صفر نباشد) به سرور دستور می‌دهد هنگام تولید یک DHCPOFFER، یک اجاره را تخصیص داده و پایدار (persist) کند. علاوه بر این:

  • طول عمر اجاره‌ی پایدارشده برابر با offer-lifetime (به ثانیه) است.
  • طول عمری که در DHCPOFFER از طریق گزینه ۵۱ (option 51) برای کلاینت ارسال می‌شود، همچنان بر اساس valid-lifetime است. این کار از بروز مشکل با کلاینت‌هایی که ممکن است پیشنهادهایی با طول عمر بیش از حد کوتاه را رد کنند، جلوگیری می‌کند.
  • به‌روزرسانی‌های DDNS انجام نمی‌شوند. همانند رفتار پیش‌فرض، این به‌روزرسانی‌ها در DHCPREQUEST رخ می‌دهند.
  • به‌روزرسانی‌ها به همتایان HA ارسال نمی‌شوند.
  • آمار اجاره‌های تخصیص‌یافته افزایش می‌یابد.
  • پردازش انقضا و بازپس‌گیری (reclamation) دقیقاً همانند اجاره‌های تخصیص‌یافته در طول پردازش DHCPREQUEST رفتار می‌کنند.
  • کش‌کردن اجاره (Lease caching)، در صورت فعال بودن، رعایت می‌شود.
  • در مراکزی که چندین نمونه از kea-dhcp4 <#std-iscman-kea-dhcp4> را در مقابل یک مخزن اجاره‌ی مشترک اجرا می‌کنند، رقابت‌ها (races) برای مقادیر مشخص آدرس در طول پردازش DHCPDISCOVER از دست می‌روند نه در طول پردازش DHCPREQUEST. سرورهایی که رقابت را برای آدرس ببازند، به‌سادگی به کلاینت پاسخ نمی‌دهند، به جای اینکه به آن‌ها NAK ارسال کنند. کلاینت نیز به نوبه خود به‌سادگی DHCPDISCOVER خود را مجدداً تلاش می‌کند. این امر باید میزان ترافیکی را که چنین تداخل‌هایی ایجاد می‌کنند، کاهش دهد.
  • به کلاینت‌هایی که DHCPDISCOVER را تکرار می‌کنند، هر بار همان آدرس پیشنهاد می‌شود.

یک نمونه پیکربندی زیرشبکه در زیر نشان داده شده است:

{
"subnet4": [
    {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
        "subnet": "192.0.2.0/24",
        "offer-lifetime": 60,
        "valid-lifetime": 2000,
        ...
    }
],
...
}

در اینجا offer-lifetime روی ۶۰ ثانیه با یک valid-lifetime معادل ۲۰۰۰ ثانیه پیکربندی شده است. این به kea-dhcp4 <#std-iscman-kea-dhcp4> دستور می‌دهد هنگام ارسال اجاره‌ها در DHCPOFFERها، آن‌ها را به مدت ۶۰ ثانیه پایدار کند و سپس هنگامی که کلاینت‌ها برای آن‌ها DHCPREQUEST ارسال می‌کنند، مدت آن‌ها را به ۲۰۰۰ ثانیه افزایش دهد.

این مقدار، که پیش‌فرض آن 0 است، در سطوح global، shared-network، subnet و class پشتیبانی می‌شود. انتخاب یک مقدار مناسب برای offer-lifetime به‌شدت به ساختار شبکه وابسته است، اما مقداری بین ۶۰ تا ۱۲۰ ثانیه نقطه‌ی شروع معقولی است.

گزینه‌ی Discovery of Network-designated Resolvers یا DNR، در RFC 9463 https://datatracker.ietf.org/doc/html/rfc9463 به عنوان روشی برای اعلام مکان تحلیل‌کننده‌های DNS (resolvers) که از طریق روش‌هایی به غیر از DNS کلاسیک روی UDP روی پورت ۵۳ در دسترس هستند، معرفی شد. تا بهار ۲۰۲۴، فناوری‌های پشتیبانی‌شده عبارت‌اند از DoT (DNS-over-TLS)، DoH (DNS-over-HTTPS) و DoQ (DNS-over-QUIC)، اما این گزینه به‌گونه‌ای طراحی شده است که قابل توسعه باشد تا پروتکل‌های دیگر را در آینده در بر بگیرد.

گزینه‌ی DHCPv4 و گزینه‌های متناظر آن در DHCPv6 تقریباً کاملاً یکسان هستند، با این استثنا که در تعداد تفاوت دارند (cardinality): تنها یک گزینه‌ی DHCPv4 مجاز است، در حالی که گزینه‌های متعددی برای DHCPv6 مجازند. برای امکان انتقال چندین مدخل (entry)، گزینه‌ی DNR در DHCPv4 یک آرایه است که چندین نمونه‌ی DNS را ممکن می‌سازد. هر نمونه از نظر منطقی معادل یک گزینه‌ی DHCPv6 است؛ تنها تفاوت این است که به جای آدرس‌های IPv6 از آدرس‌های IPv4 استفاده می‌کند. گزینه‌های DNR در DHCPv4 امکان پیکربندی بیش از یک نمونه‌ی DNR را فراهم می‌کنند، و نمونه‌های DNR با نویسه‌ی «pipe» (0x7C) از یکدیگر جدا می‌شوند.

برای مشاهده‌ی یک مثال دقیق از نحوه‌ی پیکربندی گزینه‌ی DNR، به DNR (Discovery of Network-designated Resolvers) Options for DHCPv6 <#dnr6-options> مراجعه کنید.

برای هر نمونه‌ی DNR، فیلدهای جداشده با کاما باید به ترتیب زیر ارائه شوند:

  • اولویت سرویس Service Priority (اجباری)،
  • نام دامنه کاملاً معین ADN FQDN (اجباری)،
  • آدرس(های) IP (اختیاری؛ در صورت وجود بیش از یکی، باید با فاصله از هم جدا شوند)
  • پارامترهای SvcParams به عنوان مجموعه‌ای از جفت‌های کلید=مقدار (key=value) (اختیاری؛ در صورت وجود بیش از یکی - باید با فاصله از هم جدا شوند). برای ارائه‌ی بیش از یک alpn-id، آن‌ها را با کاماهایی که با دو بک‌اسلش گریز (escape) داده شده‌اند جدا کنید (همانند مثال زیر).

مثال استفاده:

{
  "name": "v4-dnr",
  // 2 DNR Instances:
  // - Service priority 2, ADN, resolver IPv4 address and Service Parameters
  // - Service priority 3, ADN - this is ADN-only mode as per RFC 9463 3.1.6
  "data": "2, resolver.example., 10.0.5.6, alpn=dot\\,doq port=8530 | 3, fooexp.resolver.example."
}

نکته:

اگر نویسه‌های «comma» یا «pipe» به جای جداکننده‌ی فیلد به عنوان متن استفاده شوند، باید با دو بک‌اسلش گریز داده شوند (\\, یا \\|). کاماهای گریز داده شده باید هنگام پیکربندی بیش از یک پروتکل ALPN برای جداسازی آن‌ها استفاده شوند. نویسه‌ی «pipe» (0x7C) می‌تواند در پارامتر سرویس dohpath استفاده شود، زیرا در یک URI مجاز است.

مثال‌هایی برای گزینه‌های DNR در DHCPv4 که در سورس‌های Kea ارائه شده‌اند را می‌توان در kea4/all-options.json <#config-example-kea4-all-options-json> یافت..SS "رزروهای میزبان در DHCPv4 (Host Reservations in DHCPv4)"

موارد بسیاری وجود دارد که در آن‌ها ارائهٔ پیکربندی بر پایهٔ هر میزبان (per-host) مفید است. واضح‌ترین مورد، رزرو یک آدرس ثابت و مشخص برای استفادهٔ اختصاصی توسط یک کلاینت (میزبان) معین است؛ کلاینت هنگام بازگشت، هر بار همان آدرس را از سرور دریافت می‌کند و سایر کلاینت‌ها عموماً آن آدرس را دریافت نمی‌کنند. همچنین رزروهای میزبان زمانی که یک میزبان نیازمندی‌های خاصی دارد، مانند یک چاپگر که به گزینه‌های DHCP اضافی نیاز دارد، بسیار کارآمد هستند. یکی دیگر از کاربردهای ممکن، تعریف نام‌های یکتا برای میزبان‌ها است.

ممکن است مواردی پیش آید که رزرو جدیدی برای یک کلاینت روی آدرسی انجام شده باشد که در حال حاضر توسط کلاینت دیگری استفاده می‌شود. ما این وضعیت را "تداخل" (conflict) می‌نامیم. این تداخل‌ها با گذشت زمان به‌طور خودکار برطرف می‌شوند، همان‌طور که در بخش‌های بعدی شرح داده شده است. هنگامی که یک تداخل برطرف شد، کلاینت صحیح هنگام تمدید (renew)، پیکربندی رزروشده را دریافت خواهد کرد.

رزروهای میزبان به‌عنوان پارامترهایی برای هر زیرشبکه تعریف می‌شوند. هر میزبان باید شناسهٔ یکتای خود را داشته باشد، مانند آدرس سخت‌افزاری/MAC. یک آرایهٔ اختیاری reservations در ساختار subnet4 وجود دارد؛ هر عنصر در این آرایه ساختاری است که اطلاعات مربوط به رزروها را برای یک میزبان منفرد نگه می‌دارد. به‌ویژه، این ساختار دارای شناسه‌ای است که یک میزبان را به‌طور منحصربه‌فرد مشخص می‌کند. در زمینهٔ DHCPv4، این شناسه معمولاً یک آدرس سخت‌افزاری یا MAC است. در بیشتر موارد یک آدرس IP مشخص خواهد شد. همچنین می‌توان یک hostname، گزینه‌های مختص به میزبان، یا فیلدهای حمل‌شده در پیام DHCPv4 مانند siaddr، sname یا file را مشخص کرد.

نکته:

آدرس رزروشده باید درون زیرشبکه باشد.

مثال زیر نحوهٔ رزرو آدرس‌ها را برای میزبان‌های خاص در یک زیرشبکه نشان می‌دهد:

{
"subnet4": [
    {
        "id": 1,
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
        "subnet": "192.0.2.0/24",
        "interface": "eth0",
        "reservations": [
            {
                "hw-address": "1a:1b:1c:1d:1e:1f",
                "ip-address": "192.0.2.202"
            },
            {
                "duid": "0a:0b:0c:0d:0e:0f",
                "ip-address": "192.0.2.100",
                "hostname": "alice-laptop"
            },
            {
                "circuit-id": "'charter950'",
                "ip-address": "192.0.2.203"
            },
            {
                "client-id": "01:11:22:33:44:55:66",
                "ip-address": "192.0.2.204"
            }
        ]
    }
],
...
}

مدخل نخست آدرس 192.0.2.202 را برای کلاینتی رزرو می‌کند که از آدرس MAC مقدار 1a:1b:1c:1d:1e:1f استفاده می‌کند. مدخل دوم آدرس 192.0.2.100 و نام میزبان "alice-laptop" را برای کلاینتی که از DUID با مقدار 0a:0b:0c:0d:0e:0f استفاده می‌کند، رزرو می‌نماید. (اگر به‌روزرسانی‌های DNS برنامه‌ریزی شده باشند، اکیداً توصیه می‌شود که نام‌های میزبان یکتا باشند.) مثال سوم آدرس 192.0.3.203 را برای کلاینتی رزرو می‌کند که درخواست آن توسط یک کارگزار بازپخش (relay agent) رله می‌شود که گزینهٔ circuit-id را با مقدار "charter950" درج می‌کند. مدخل چهارم آدرس 192.0.2.204 را برای کلاینتی که از شناسهٔ کلاینت با مقدار 01:11:22:33:44:55:66 استفاده می‌کند، رزرو می‌نماید.

مثال بالا صرفاً برای اهداف نمایشی آورده شده است؛ در استقرارهای واقعی توصیه می‌شود تا حد امکان از انواع کمتری (ترجیحاً فقط یک نوع) استفاده شود. برای بحث دقیق دربارهٔ این نکته، به Fine-Tuning DHCPv4 Host Reservation مراجعه کنید.

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

افزودن رزروهای میزبان با افت کارایی همراه است. در اصل، زمانی که سروری که از رزرو میزبان پشتیبانی نمی‌کند به یک پرس‌وجو پاسخ می‌دهد، باید بررسی کند که آیا برای آدرس مورد نظر که برای تخصیص یا تمدید در نظر گرفته شده، اجاره‌ای (lease) وجود دارد یا خیر. سروری که از رزرو میزبان پشتیبانی می‌کند باید بررسی‌های بیشتری انجام دهد: نه تنها اینکه آیا آدرس در حال حاضر استفاده می‌شود (یعنی اجاره‌ای برای آن وجود دارد یا خیر)، بلکه اینکه آیا این آدرس ممکن است توسط شخص دیگری استفاده شود (یعنی رزروی برای آن وجود دارد یا خیر). این بررسی اضافی بار پردازشی بیشتری تحمیل می‌کند.

در یک سناریوی معمول Kea، یک زیرشبکهٔ IPv4 تعریف می‌شود (مانند 192.0.2.0/24) که بخش مشخصی از آن به تخصیص پویا توسط سرور DHCPv4 اختصاص می‌یابد. به این بخش پویا، یک استخر پویا (dynamic pool) یا به‌سادگی pool گفته می‌شود. در اصل، یک رزرو میزبان می‌تواند هر آدرسی را که متعلق به زیرشبکه است رزرو کند. رزروهایی که آدرس‌های متعلق به استخرهای پیکربندی‌شده را مشخص می‌کنند، "رزروهای درون‌استخری" (in-pool reservations) نامیده می‌شوند. در مقابل، آن‌هایی که متعلق به استخرهای پویا نیستند، "رزروهای برون‌استخری" (out-of-pool reservations) نام دارند. هیچ تفاوت رسمی در نحو (syntax) رزرو وجود ندارد و هر دو نوع رزرو به‌طور یکسان مدیریت می‌شوند.

ابزار Kea از رزروهای سراسری میزبان پشتیبانی می‌کند. این‌ها رزروهایی هستند که در سطح سراسری (global) در پیکربندی مشخص می‌شوند و متعلق به هیچ زیرشبکهٔ خاصی نیستند. Kea همچنان بسته‌های ورودی کلاینت را مانند قبل با یک زیرشبکه تطبیق می‌دهد، اما هنگامی که حالت رزرو زیرشبکه روی "global" تنظیم شده باشد، Kea رزروهای میزبان را فقط در میان رزروهای سراسریِ تعریف‌شده جستجو می‌کند. معمولاً چنین رزروهایی برای رزرو نام‌های میزبان برای کلاینت‌هایی استفاده می‌شوند که ممکن است از یک زیرشبکه به زیرشبکهٔ دیگری جابه‌جا شوند.

نکته:

رزروهای سراسری، اگرچه در شرایط خاصی مفید هستند، دارای جنبه‌هایی هستند که هنگام استفاده از آن‌ها باید به‌دقت مورد توجه قرار گیرند. لطفاً برای جزئیات بیشتر به Conflicts in DHCPv4 Reservations مراجعه کنید.

نکته:

از نسخهٔ Kea 1.9.1 به بعد، حالت رزرو با سه پرچم بولی (boolean flags)، یعنی reservations-global، reservations-in-subnet و reservations-out-of-pool جایگزین شده است که امکان پیکربندی رزروهای میزبان را هم به‌صورت سراسری و هم درون زیرشبکه فراهم می‌کنند. در چنین مواردی، هنگامی که هر دو برای یک کلاینت یکسان وجود داشته باشند، رزرو میزبانِ زیرشبکه نسبت به رزرو سراسری اولویت دارد.

از آنجا که اطلاعات مربوط به رزروها و اجاره‌ها به‌صورت جداگانه ذخیره می‌شوند، ممکن است تداخل‌هایی بروز کند. توالی رخدادهای زیر را در نظر بگیرید: کارساز استخر پویایی از نشانی‌ها را در محدودهٔ 192.0.2.10 تا 192.0.2.20 پیکربندی کرده است. میزبان Host A نشانی‌ای را درخواست می‌کند و 192.0.2.10 را دریافت می‌نماید. اکنون مدیر سیستم تصمیم می‌گیرد نشانی 192.0.2.10 را برای Host B رزرو کند. به‌طور کلی، رزرو نشانی‌ای که در حال حاضر به کس دیگری واگذار شده توصیه نمی‌شود، اما سناریوهای معتبری وجود دارد که چنین عملیاتی در آن‌ها توجیه‌پذیر است.

اکنون کارساز با تداخلی مواجه است که باید حل شود. اگر Host B بالا آمده و درخواستی برای یک نشانی ارسال کند، کارساز نمی‌تواند بلافاصله نشانی رزرو شدهٔ 192.0.2.10 را به آن اختصاص دهد. یک رویکرد ساده‌انگارانه این است که اجارهٔ فعلی Host A فوراً حذف شده و اجارهٔ جدیدی برای Host B ایجاد شود. با این حال این کار مشکل را برطرف نمی‌کند، زیرا به محض این‌که Host B نشانی را دریافت کند، متوجه می‌شود که این نشانی در حال حاضر (توسط Host A) در حال استفاده است و یک پیام DHCPDECLINE ارسال خواهد کرد. بنابراین، در چنین وضعیتی، کارساز باید موقتاً نشانی متفاوتی را از استخر پویا (که با آنچه رزرو شده مطابقت ندارد) به Host B اختصاص دهد.

هنگامی که Host A نشانی خود را تمدید می‌کند، کارساز متوجه خواهد شد نشانی‌ای که تمدید می‌شود اکنون برای میزبان دیگری - Host B - رزرو شده است. کارساز با ارسال یک پیام DHCPNAK به Host A اطلاع می‌دهد که دیگر مجاز به استفاده از آن نیست. با این حال کارساز اجاره را حذف نخواهد کرد، چرا که در شبکه‌های دارای اتلاف بسته (lossy)، احتمال اندکی وجود دارد که DHCPNAK تحویل داده نشود. اگر این اتفاق بیفتد، کلاینت هیچ پاسخی دریافت نمی‌کند و بنابراین بستهٔ DHCPREQUEST خود را دوباره ارسال خواهد کرد. به محض این‌که DHCPNAK توسط Host A دریافت شود، این میزبان به مرحلهٔ کشف کارساز (server discovery) بازگشته و در نهایت نشانی متفاوتی دریافت خواهد کرد. کارساز علاوه بر تخصیص اجارهٔ جدید، اجارهٔ قدیمی را نیز حذف خواهد کرد. در نتیجه، نشانی 192.0.2.10 آزاد خواهد شد.

هنگامی که Host B تلاش کند نشانی موقتاً تخصیص‌یافته‌اش را تمدید نماید، کارساز تشخیص می‌دهد که این میزبان دارای اجاره‌ای معتبر است، اما متوجه خواهد شد که یک رزرو برای نشانی دیگری وجود دارد. کارساز یک DHCPNAK ارسال می‌کند تا به Host B اطلاع دهد که نشانی آن دیگر قابل استفاده نیست، اما اجاره‌اش را نگه می‌دارد (مجدداً، ممکن است DHCPNAK گم شود، بنابراین کارساز آن را تا زمان بازگشت کلاینت برای دریافت نشانی جدید حفظ می‌کند). سپس Host B به فاز کشف کارساز بازگشته و سرانجام یک پیام DHCPREQUEST می‌فرستد. این بار کارساز درمی‌یابد که رزروی برای این میزبان ثبت شده و نشانی رزروشدهٔ 192.0.2.10 استفاده نمی‌شود، بنابراین آن را اعطا می‌کند. کارساز همچنین اجارهٔ مربوط به نشانی موقت قبلی Host B را حذف خواهد کرد.

این بازیابی حتی اگر سایر میزبان‌ها نیز تلاش کنند نشانی رزرو شده را دریافت نمایند، موفقیت‌آمیز خواهد بود. اگر Host C پس از ثبت رزرو، نشانی 192.0.2.10 را درخواست کند، کارساز یا نشانی دیگری را پیشنهاد می‌دهد (در پاسخ به DHCPDISCOVER) یا DHCPNAK ارسال می‌کند (در پاسخ به DHCPREQUEST).

این سازوکار به کارساز اجازه می‌دهد تا از شرایطی که رزروها با اجاره‌های موجود تداخل پیدا می‌کنند، به‌طور کامل بازیابی شود؛ با این حال، انجام این فرایند تقریباً به اندازهٔ مدت‌زمان تعیین‌شده در renew-timer زمان می‌برد. بهترین روش برای جلوگیری از چنین روندی، عدم تعریف رزروهای جدیدی است که با اجاره‌های موجود در تداخل هستند. توصیهٔ دیگر، استفاده از رزروهای خارج از استخر (out-of-pool) است؛ اگر نشانی رزروشده به هیچ استخری تعلق نداشته باشد، کلاینت‌های دیگر به هیچ وجه نمی‌توانند آن را دریافت کنند.

نکته:

سازوکار حل تداخل برای رزروهای سراسری (global reservations) کار نمی‌کند. هرچند ویژگی رزرو سراسری نشانی ممکن است در پیکربندی‌های خاصی مفید باشد، عموماً توصیه می‌شود که از رزروهای سراسری برای نشانی‌ها استفاده نشود. مدیرانی که تصمیم به استفاده از رزروهای سراسری می‌گیرند، باید به‌صورت دستی اطمینان حاصل کنند که نشانی‌های رزروشده درون استخرهای پویا قرار ندارند.

هنگامی که رزرو برای یک کلاینت شامل hostname باشد، کارساز این نام میزبان را در گزینهٔ Client FQDN یا Hostname به کلاینت بازمی‌گرداند. کارساز تنها در صورتی با گزینهٔ Client FQDN پاسخ می‌دهد که کلاینت گزینهٔ Client FQDN را در پیام ارسالی خود به کارساز گنجانده باشد. در صورتی که کلاینت گزینهٔ Hostname را در پیام خود گنجانده باشد یا گزینهٔ Hostname را از طریق گزینهٔ Parameter Request List درخواست کرده باشد، کارساز با گزینهٔ Hostname پاسخ می‌دهد. کارساز حتی اگر برای انجام به‌روزرسانی‌های DNS پیکربندی نشده باشد نیز گزینهٔ Hostname را بازمی‌گرداند. نام میزبان رزروشده همواره بر نام میزبان ارائه‌شده توسط کلاینت یا نام میزبان خودتولیدشده (از روی نشانی IPv4) اولویت دارد.

کارساز نام میزبان رزروشده را با مقدار پارامتر ddns-qualifying-suffix تکمیل (qualify) می‌کند. برای نمونه، پیکربندی زیرشبکهٔ زیر:

{
    "subnet4": [
    {
        "id": 1,
        "subnet": "10.0.0.0/24",
        "pools": [ { "pool": "10.0.0.10-10.0.0.100" } ],
        "ddns-qualifying-suffix": "example.isc.org.",
        "reservations": [
           {
             "hw-address": "aa:bb:cc:dd:ee:ff",
             "hostname": "alice-laptop"
           }
        ]
    }
    ],
    "dhcp-ddns": {
        "enable-updates": true
    }
}

باعث تخصیص نام میزبان "alice-laptop.example.isc.org." به کلاینت دارای نشانی MAC برابر با "aa:bb:cc:dd:ee:ff" خواهد شد. اگر ddns-qualifying-suffix مشخص نشده باشد، از مقدار پیش‌فرض (خالی) استفاده خواهد شد و در این حالت، مقدار ارائه‌شده در hostname به عنوان یک نام کاملاً واجد شرایط (FQDN) تلقی می‌شود. بدین ترتیب، با خالی گذاشتن ddns-qualifying-suffix، امکان تخصیص نام‌های دامنهٔ متفاوت به کلاینت‌های گوناگون وجود خواهد داشت:

{
    "subnet4": [
    {
        "id": 1,
        "subnet": "10.0.0.0/24",
        "pools": [ { "pool": "10.0.0.10-10.0.0.100" } ],
        "reservations": [
           {
             "hw-address": "aa:bb:cc:dd:ee:ff",
             "hostname": "alice-laptop.isc.org."
           },
           {
             "hw-address": "12:34:56:78:99:AA",
             "hostname": "mark-desktop.example.org."
           }
        ]
    }
    ],
    "dhcp-ddns": {
        "enable-updates": true
    }
}

مثال بالا منجر به اختصاص نام میزبان "alice-laptop.isc.org." به کلاینت با نشانی MAC برابر با "aa:bb:cc:dd:ee:ff"، و نام میزبان "mark-desktop.example.org." به کلاینت با نشانی MAC برابر با "12:34:56:78:99:AA" می‌گردد..SS گنجاندن گزینه‌های مشخص DHCPv4 در رزروها

Kea امکان تعیین گزینه‌ها را بر اساس هر میزبان فراهم می‌کند. این گزینه‌ها از همان قوانین حاکم بر سایر گزینه‌ها پیروی می‌کنند. این موارد می‌توانند گزینه‌های استاندارد (بخش Standard DHCPv4 Options را ببینید)، گزینه‌های سفارشی (بخش Custom DHCPv4 Options را ببینید)، یا گزینه‌های وابسته به سازنده (بخش DHCPv4 Vendor-Specific Options را ببینید) باشند. مثال زیر نحوهٔ تعریف گزینه‌های استاندارد را نشان می‌دهد:

{
    "subnet4": [
    {
        "reservations": [
        {
            "hw-address": "aa:bb:cc:dd:ee:ff",
            "ip-address": "192.0.2.1",
            "option-data": [
            {
                "name": "cookie-servers",
                "data": "10.1.1.202,10.1.1.203"
            },
            {
                "name": "log-servers",
                "data": "10.1.1.200,10.1.1.201"
            }
            ]
        }
        ],
        ...
    }
    ],
    ...
}

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

{
    "subnet4": [
    {
        "reservations": [
        {
            "hw-address": "aa:bb:cc:dd:ee:ff",
            "ip-address": "10.0.0.7",
            "option-data": [
            {
                "name": "vivso-suboptions",
                "data": "4491"
            },
            {
                "name": "tftp-servers",
                "space": "vendor-4491",
                "data": "10.1.1.202,10.1.1.203"
            }
            ]
        }
        ],
        ...
    }
    ],
    ...
}

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

پیام‌های BOOTP/DHCPv4 شامل فیلدهای "siaddr"، "sname" و "file" هستند. اگرچه DHCPv4 شامل گزینه‌های متناظر مانند گزینهٔ ۶۶ و گزینهٔ ۶۷ است، اما ممکن است برخی کلاینت‌ها از این گزینه‌ها پشتیبانی نکنند. به همین دلیل، مدیران سرور اغلب به جای آن از فیلدهای "siaddr"، "sname" و "file" استفاده می‌کنند.

با Kea، انجام رزروهای ایستا برای این فیلدهای پیام DHCPv4 امکان‌پذیر است:

{
    "subnet4": [
    {
        "reservations": [
        {
            "hw-address": "aa:bb:cc:dd:ee:ff",
            "next-server": "10.1.1.2",
            "server-hostname": "server-hostname.example.org",
            "boot-file-name": "/usr/local/share/kea/bootfile.efi"
        }
        ],
        ...
    }
    ],
    ...
}

توجه داشته باشید که این پارامترها را می‌توان در ترکیب با سایر پارامترها برای یک رزرو مشخص کرد، مانند یک نشانی IPv4 رزروشده. این پارامترها اختیاری هستند؛ می‌توان زیرمجموعه‌ای از آن‌ها را مشخص کرد یا تمام آن‌ها را نادیده گرفت.

بخش Using Expressions in Classification <#classification-using-expressions> نحوهٔ پیکربندی سرور را برای تخصیص کلاس‌ها به یک کلاینت، بر اساس محتوای گزینه‌هایی که آن کلاینت به سرور ارسال می‌کند، توضیح می‌دهد. سازوکارهای رزرو میزبان همچنین امکان تخصیص ایستای کلاس‌ها به کلاینت‌ها را فراهم می‌کنند. تعاریف این کلاس‌ها در فایل پیکربندی Kea یا یک پایگاه داده قرار می‌گیرد. قطعه‌پیکربندی زیر نحوهٔ تعیین تعلق یک کلاینت به کلاس‌های reserved-class1 و reserved-class2 را نشان می‌دهد. این کلاس‌ها با گزینه‌های خاصی که به کلاینت‌های متعلق به آن‌ها ارسال می‌شود، مرتبط هستند.

{
    "client-classes": [
    {
       "name": "reserved-class1",
       "option-data": [
       {
           "name": "routers",
           "data": "10.0.0.200"
       }
       ]
    },
    {
       "name": "reserved-class2",
       "option-data": [
       {
           "name": "domain-name-servers",
           "data": "10.0.0.201"
       }
       ]
    }
    ],
    "subnet4": [
    {
        "id": 1,
        "subnet": "10.0.0.0/24",
        "pools": [ { "pool": "10.0.0.10-10.0.0.100" } ],
        "reservations": [
        {
            "hw-address": "aa:bb:cc:dd:ee:ff",
            "client-classes": [ "reserved-class1", "reserved-class2" ]
        }
        ]
    }
    ]
 }

نکته:

کلاس‌های فهرست‌شده در فهرست client-classes یک رزرو، بدون قید و شرط به کلاینتِ آن رزرو اختصاص داده می‌شوند، چه آن کلاس‌ها حاوی یک عبارت آزمون باشند و چه نباشند. برای جلوگیری از سردرگمی، پیشنهاد می‌شود که کلاس‌های کلاینتی که صرفاً از طریق رزروهای میزبان تخصیص می‌یابند، فاقد عبارت‌های آزمون باشند.

در برخی موارد می‌توان رزروهای میزبان را در ارتباط با کلاس‌های کلاینت مشخص‌شده در پیکربندی Kea استفاده کرد. به‌ویژه، هنگامی که یک رزرو میزبان برای یک کلاینت در یک زیرشبکهٔ معین وجود دارد، کلاس توکار "KNOWN" به کلاینت اختصاص می‌یابد. در مقابل، هنگامی که هیچ تخصیص ایستایی برای کلاینت وجود ندارد، کلاس "UNKNOWN" به کلاینت اختصاص داده می‌شود. عبارت‌های کلاسی در فایل پیکربندی Kea می‌توانند با استفاده از عملگر "member" به کلاس‌های "KNOWN" یا "UNKNOWN" ارجاع دهند. برای مثال:

{
    "client-classes": [
        {
            "name": "dependent-class",
            "test": "member('KNOWN')",
            "only-in-additional-list": true
        }
    ]
}

پارامتر only-in-additional-list در اینجا برای اجبار به ارزیابی کلاس پس از تخصیص اجاره لازم است، تا کلاس رزروشده نیز تخصیص یافته باشد.

نکته:

کلاس‌های مشخص‌شده در رزروهای میزبان غیرسراسری، پس از ارزیابی تمام کلاس‌هایی که پارامتر only-in-additional-list آن‌ها روی false تنظیم شده است، به بستهٔ پردازش‌شده تخصیص می‌یابند. این بدان معناست که این کلاس‌ها نباید به کلاس‌های تخصیص‌یافتهٔ ایستا از طریق رزروهای میزبان وابسته باشند. اگر چنین وابستگی‌ای نیاز باشد، پارامتر only-in-additional-list برای کلاس‌های وابسته باید روی true تنظیم شود. این کلاس‌ها پس از اختصاص کلاس‌های ایستا به بسته، ارزیابی می‌شوند. با این حال، این امر بار پیکربندی اضافی تحمیل می‌کند، زیرا تمام کلاس‌هایی که با only-in-additional-list مشخص شده‌اند باید در فهرست evaluate-additional-classes برای هر زیرشبکه‌ای که در آن استفاده می‌شوند، ذکر شوند.

نکته:

کلاس‌های کلاینت مشخص‌شده در فایل پیکربندی Kea ممکن است به کلاس‌های مشخص‌شده در رزروهای سراسری میزبان وابسته باشند. در چنین حالتی به پارامتر only-in-additional-list نیازی نیست. برای موارد کاربرد خاص به بخش‌های Pool Selection with Client Class Reservations و Subnet Selection with Client Class Reservations مراجعه کنید.

کارساز Kea می‌تواند رزروهای میزبان را در MySQL یا PostgreSQL ذخیره کند. برای کسب اطلاعات در مورد نحوه پیکربندی Kea جهت استفاده از رزروهای ذخیره‌شده در MySQL یا PostgreSQL، بخش Hosts Storage را ببینید. کارساز Kea یک قلاب (hook) اختصاصی برای مدیریت رزروها در پایگاه داده ارائه می‌دهد؛ بخش libdhcp_host_cmds.so: Host Commands <#hooks-host-cmds> اطلاعات دقیقی را ارائه می‌کند. ویکی Kea در https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/commands#23-host-reservations-hr-management نمونه‌هایی از نحوه انجام عملیات‌های معمول رزرو میزبان ارائه می‌دهد.

نکته:

در Kea، حداکثر طول گزینه‌ای که به ازای هر رزرو میزبان (per-host-reservation) مشخص می‌شود، به‌طور قراردادی بر روی ۴۰۹۶ بایت تنظیم شده است.

قابلیت رزرو میزبان محدودیت‌های بیشتری را برای موتور تخصیص (بخشی از Kea که آدرسی را برای یک کلاینت انتخاب می‌کند) هنگام انتخاب و تمدید اجاره (lease) اعمال می‌کند. به‌ویژه، سه بررسی عمده ضروری است. نخست، هنگام انتخاب یک اجاره جدید، کافی نیست که اجاره کاندید صرفاً توسط کلاینت DHCP دیگری در حال استفاده نباشد؛ بلکه نباید برای کلاینت دیگری نیز رزرو شده باشد. به همین ترتیب، هنگام تمدید یک اجاره، باید بررسی دیگری انجام شود تا مشخص گردد آیا آدرسی که تمدید می‌شود برای کلاینت دیگری رزرو شده است یا خیر. در نهایت، هنگامی که یک میزبان آدرسی را تمدید می‌کند، کارساز باید بررسی کند که آیا رزروی برای این میزبان وجود دارد یا خیر؛ وجود رزرو به این معنا خواهد بود که آدرس فعلی (که به‌صورت پویا تخصیص یافته) باید لغو شده و آدرس رزروشده به جای آن استفاده شود.

برخی از این بررسی‌ها ممکن است در برخی استقرارها غیرضروری باشند و عدم انجام آن‌ها می‌تواند عملکرد را بهبود بخشد. کارساز Kea پارامترهای پیکربندی reservations-global، reservations-in-subnet و reservations-out-of-pool را برای انتخاب انواع رزروهای مجاز برای یک زیرشبکه خاص ارائه می‌دهد. هر نوع رزرو محدودیت‌های متفاوتی برای بررسی‌هایی دارد که باید توسط کارساز هنگام تخصیص یا تمدید اجاره برای کلاینت انجام شوند.

پرچم‌های پیکربندی عبارتند از:

  • reservations-in-subnet - هنگامی که روی true تنظیم شود، انواع رزرو میزبان درون استخر (in-pool) را فعال می‌کند. این تنظیم مقدار پیش‌فرض بوده و امن‌ترین و انعطاف‌پذیرترین حالت است. با این حال، از آنجا که تمام بررسی‌ها انجام می‌شوند، کندترین حالت نیز هست. این پرچم بررسی در برابر رزروهای سراسری را انجام نمی‌دهد. مقدار پیش‌فرض این پرچم true است.
  • reservations-out-of-pool - هنگامی که روی true تنظیم شود، فقط رزروهای میزبان خارج از استخر (out-of-pool) را مجاز می‌کند. در این حالت کارساز فرض می‌کند که تمام رزروهای میزبان برای آدرس‌هایی هستند که به استخر پویا تعلق ندارند. بنابراین، می‌تواند بررسی‌های رزرو را هنگام سروکار داشتن با آدرس‌های درون استخر نادیده بگیرد و بدین ترتیب عملکرد را بهبود بخشد. در صورتی که هر یک از رزروها از آدرس‌های درون استخر استفاده می‌کنند از این حالت استفاده نکنید. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ Kea صحت رزروها را در برابر reservations-out-of-pool بررسی نمی‌کند و پیکربندی نادرست ممکن است مشکلاتی ایجاد کند. مقدار پیش‌فرض این پرچم false است.
  • reservations-global - رزروهای سراسری میزبان را مجاز می‌کند. با این تنظیم، کارساز رزروهای مربوط به یک کلاینت را در میان رزروهای سراسری تعریف‌شده جستجو می‌کند. در صورت مشخص بودن یک آدرس، کارساز بررسی‌های رزرو انجام‌شده در حالت‌های دیگر را نادیده می‌گیرد و بنابراین کارایی را بهبود می‌بخشد. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ Kea در صورتی که reservations-global روی true تنظیم شده باشد، صحت رزروها را بررسی نمی‌کند و پیکربندی نادرست ممکن است مشکلاتی به وجود آورد. مقدار پیش‌فرض این پرچم false است.
نکته: تنظیم تمام پرچم‌ها روی false پشتیبانی از رزرو میزبان را غیرفعال می‌کند.
از آنجا که هیچ رزروی وجود ندارد، کارساز تمام بررسی‌ها را نادیده می‌گیرد. هر رزرو تعریف‌شده‌ای کاملاً نادیده گرفته می‌شود. از آنجا که بررسی‌ها نادیده گرفته می‌شوند، کارساز ممکن است در این حالت سریع‌تر کار کند.

از Kea 1.9.1 به بعد پرچم‌های reservations-global، reservations-in-subnet و reservations-out-of-pool پشتیبانی می‌شوند.

پارامترهای reservations-global، reservations-in-subnet و reservations-out-of-pool می‌توانند در سطوح زیر مشخص شوند:

  • سطح سراسری (global): .Dhcp4["reservations-global"] (پایین‌ترین اولویت: توسط سایر سطوح رونویسی می‌شود)
  • سطح زیرشبکه (subnet): .Dhcp4.subnet4[]["reservations-in-subnet"] (اولویت پایین)
  • سطح شبکه مشترک (shared-network): .Dhcp4["shared-networks"][]["reservations-out-of-pool"] (اولویت بالا)
  • سطح زیرشبکه در شبکه مشترک (shared-network subnet): .Dhcp4["shared-networks"][].subnet4[]["reservations-out-of-pool"] (بالاترین اولویت: سایر سطوح را رونویسی می‌کند)

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

                              O
                              |
                              v
+-----------------------------+------------------------------+
|         Is per-host configuration needed, such as          |
|                reserving specific addresses,               |
|               assigning specific options or                |
| assigning packets to specific classes on per-device basis? |
+-+-----------------+----------------------------------------+
  |                 |
no|              yes|
  |                 |   +--------------------------------------+
  |                 |   |         For all given hosts,         |
  +--> "disabled"   +-->+      can the reserved resources      |
                        |  be used in all configured subnets?  |
                        +--------+---------------------------+-+
                                 |                           |
+----------------------------+   |no                         |yes
|             Is             |   |                           |
|  at least one reservation  +<--+               "global" <--+
| used to reserve addresses? |
+-+------------------------+-+
  |                        |
no|                     yes|   +---------------------------+
  |                        |   | Is high leases-per-second |
  +--> "out-of-pool"       +-->+ performance or efficient  |
        ^                      |      resource usage       |
        |                      |  (CPU ticks, RAM usage,   |
        |                      |   database roundtrips)    |
        |                      | important to your setup?  |
        |                      +-+----------------+--------+
        |                        |                |
        |                     yes|              no|
        |                        |                |
        |          +-------------+                |
        |          |                              |
        |          |   +----------------------+   |
        |          |   | Can it be guaranteed |   |
        |          +-->+  that the reserved   |   |
        |              |      addresses       |   |
        |              |  aren't part of the  |   |
        |              |   pools configured   |   |
        |              |  in the respective   |   |
        |              |       subnet?        |   |
        |              +-+------------------+-+   |
        |                |                  |     |
        |             yes|                no|     |
        |                |                  |     V
        +----------------+                  +--> "in-subnet"

نمونه‌ای از پیکربندی که رزروها را غیرفعال می‌کند به صورت زیر است:

{
  "Dhcp4": {
    "subnet4": [
      {
        "id": 1,
        "pools": [
          {
            "pool": "192.0.2.10-192.0.2.100"
          }
        ],
        "reservations-global": false,
        "reservations-in-subnet": false,
        "subnet": "192.0.2.0/24"
      }
    ]
  }
}

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

{
  "Dhcp4": {
    "reservations-global": true,
    "reservations": [
      {
        "hostname": "host-one",
        "hw-address": "01:bb:cc:dd:ee:ff"
      },
      {
        "hostname": "host-two",
        "hw-address": "02:bb:cc:dd:ee:ff"
      }
    ],
    "subnet4": [
      {
        "id": 1,
        "pools": [
          {
            "pool": "192.0.2.10-192.0.2.100"
          }
        ],
        "subnet": "192.0.2.0/24"
      }
    ]
  }
}

معنای پرچم‌های رزرو عبارتند از:

reservations-global: واکشی رزروهای سراسری.
  • reservations-in-subnet: واکشی رزروهای زیرشبکه. برای یک شبکهٔ اشتراکی این شامل تمامی زیرشبکه‌های عضو آن شبکهٔ اشتراکی می‌شود.
  • reservations-out-of-pool: این گزینه تنها زمانی کاربرد دارد که پرچم reservations-in-subnet برابر با true باشد. هنگامی که reservations-out-of-pool برابر با true باشد، کارساز فرض می‌کند که تمامی رزروهای میزبان برای نشانی‌هایی هستند که به استخر پویا تعلق ندارند. بنابراین، می‌تواند هنگام سروکار داشتن با نشانی‌های درون استخر از بررسی‌های رزرو صرف‌نظر کرده و بدین‌صورت کارایی را بهبود بخشد. کارساز نشانی‌های رزروشده‌ای را که درون استخرهای پویا قرار دارند به کلاینت‌های مربوطه اختصاص نخواهد داد. این همچنین بدان معناست که نشانی‌های منطبق بر رزروهای مربوطه از درون استخرهای پویا (در صورت وجود) می‌توانند به‌طور پویا به هر کلاینتی اختصاص یابند.

پیکربندی disabled معادل است با:

{
  "Dhcp4": {
    "reservations-global": false,
    "reservations-in-subnet": false
  }
}

پیکربندی global با استفاده از reservations-global معادل است با:

{
  "Dhcp4": {
    "reservations-global": true,
    "reservations-in-subnet": false
  }
}

پیکربندی out-of-pool با استفاده از reservations-out-of-pool معادل است با:

{
  "Dhcp4": {
    "reservations-global": false,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": true
  }
}

و پیکربندی in-subnet با استفاده از reservations-in-subnet معادل است با:

{
  "Dhcp4": {
    "reservations-global": false,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": false
  }
}

برای فعال‌سازی هم‌زمان global و in-subnet، می‌توان از ترکیب زیر استفاده کرد:

{
  "Dhcp4": {
    "reservations-global": true,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": false
  }
}

برای فعال‌سازی هم‌زمان global و out-of-pool، می‌توان از ترکیب زیر استفاده کرد:

{
  "Dhcp4": {
    "reservations-global": true,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": true
  }
}

فعال کردن out-of-pool و غیرفعال کردن in-subnet به‌طور هم‌زمان پیشنهاد نمی‌شود؛ زیرا out-of-pool بر رزروهای میزبان در یک زیرشبکه اعمال می‌شود که تنها زمانی واکشی می‌شوند که پرچم in-subnet برابر با true باشد.

این پارامتر می‌تواند در سطوح سراسری (global)، زیرشبکه (subnet) و شبکهٔ اشتراکی (shared-network) مشخص شود.

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

{
  "Dhcp4": {
    "subnet4": [
      {
        "reservations-global": false,
        "reservations-in-subnet": false,
        "subnet": "192.0.2.0/24",
        "id": 1
      }
    ]
  }
}

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

{
  "Dhcp4": {
    "reservations": [
      {
        "hostname": "host-one",
        "hw-address": "01:bb:cc:dd:ee:ff"
      },
      {
        "hostname": "host-two",
        "hw-address": "02:bb:cc:dd:ee:ff"
      }
    ],
    "reservations-global": true,
    "reservations-in-subnet": false,
    "subnet4": [
      {
        "pools": [
          {
            "pool": "192.0.2.10-192.0.2.100"
          }
        ],
        "subnet": "192.0.2.0/24",
        "id": 1
      }
    ]
  }
}

برای جزئیات بیشتر در رابطه با رزروهای سراسری، به Global Reservations in DHCPv4 مراجعه کنید.

جنبهٔ دیگری از رزروهای میزبان، انواع مختلف شناسه‌ها است. Kea در حال حاضر از چهار نوع شناسه پشتیبانی می‌کند: hw-address، duid، client-id و circuit-id. این قابلیت از دیدگاه کاربردپذیری سودمند است؛ با این حال، یک ایراد به همراه دارد. به ازای هر بستهٔ دریافتی، Kea باید هر نوع شناسه را استخراج کرده و سپس پایگاه‌داده را پرس‌وجو کند تا مشخص شود آیا رزروی با این شناسهٔ مشخص وجود دارد یا خیر. اگر موردی یافت نشود، شناسهٔ بعدی استخراج شده و پرس‌وجوی بعدی ارسال می‌شود. این فرآیند تا زمانی که رزروی پیدا شود یا تمامی انواع شناسه‌ها بررسی شوند ادامه می‌یابد. به مرور زمان و با افزایش تعداد انواع شناسه‌های پشتیبانی‌شده، Kea کندتر و کندتر خواهد شد.

برای برطرف کردن این مشکل، پارامتری با عنوان host-reservation-identifiers ارائه شده است. این پارامتر فهرستی از انواع شناسه را دریافت می‌کند. Kea تنها آن دسته از انواع شناسه را بررسی می‌کند که در host-reservation-identifiers برشمرده شده‌اند. از دیدگاه عملکرد، تعداد انواع شناسه باید در کمترین حد ممکن، ترجیحاً یک مورد، نگه داشته شود. اگر محیط شما از چندین نوع رزرو استفاده می‌کند، لطفاً آن‌ها را از پرکاربردترین به کم‌کاربردترین فهرست کنید؛ زیرا این کار احتمال یافتن رزرو توسط Kea با کمترین تعداد پرس‌وجو را بالا می‌برد. یک نمونه از پیکربندی host-reservation-identifiers به صورت زیر است:

{
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
"subnet4": [
    {
        "subnet": "192.0.2.0/24",
        ...
    }
],
...
}

در صورت عدم تعیین، مقدار پیش‌فرض به شرح زیر است:

"host-reservation-identifiers": [ "hw-address", "duid", "circuit-id", "client-id" ]

نکته:

به محض یافتن یک رزرو میزبان، جستجو متوقف می‌شود؛ هنگامی که یک کلاینت دارای دو رزرو میزبان با استفاده از انواع مختلفی از شناسه‌های فعال باشد، همیشه نخستین مورد بازگردانده شده و مورد دوم نادیده گرفته می‌شود. به عبارت دیگر، این حالت معمولاً یک خطای پیکربندی محسوب می‌شود. در موارد نادری که داشتن دو رزرو برای یک میزبان منطقی باشد، رزروی که باید استفاده شود را می‌توان با مرتب‌سازی فهرست انواع شناسه‌ها در host-reservation-identifiers تعیین کرد.

در برخی پیاده‌سازی‌ها، مانند شبکه‌های تلفن همراه، کلاینت‌ها می‌توانند درون شبکه جابه‌جا شوند (roam کنند) و برخی پارامترها باید بدون در نظر گرفتن مکان فعلی کلاینت مشخص شوند. برای برآورده ساختن چنین نیازی، Kea سازوکار رزرو سراسری (global reservation) را ارائه می‌دهد. ایدهٔ نهفته در این سازوکار این است که رزروهای معمول میزبان با استفاده از یک subnet ID مشخص، به زیرشبکه‌های خاصی وابسته هستند. Kea می‌تواند رزروی سراسری تعیین کند که در تمام زیرشبکه‌های دارای رزرو سراسریِ فعال، قابل استفاده باشد.

از این ویژگی می‌توان برای تخصیص پارامترهای مشخصی مانند hostname یا دیگر گزینه‌های اختصاصی و ویژهٔ میزبان استفاده کرد. همچنین می‌توان از آن برای تخصیص آدرس‌ها نیز بهره برد.

آدرسی که از طریق رزرو سراسری میزبان تخصیص می‌یابد باید برای زیرشبکه‌ای که سرور برای کلاینت انتخاب می‌کند، امکان‌پذیر (feasible) باشد. به عبارت دیگر، آدرس باید در محدودهٔ زیرشبکه قرار داشته باشد؛ در غیر این صورت، نادیده گرفته می‌شود و سرور تلاش خواهد کرد تا آدرسی را به‌صورت پویا تخصیص دهد. اگر زیرشبکهٔ انتخاب‌شده به یک shared network تعلق داشته باشد، سرور امکان‌پذیر بودن را در مقایسه با زیرشبکه‌های هم‌ردیف (siblings) بررسی کرده و نخستین زیرشبکهٔ در محدوده را انتخاب می‌نماید. اگر چنین زیرشبکه‌ای وجود نداشته باشد، سرور به تخصیص پویای آدرس بازمی‌گردد.

نکته:

پیش از نسخهٔ 2.3.5، سرور بررسی‌های امکان‌پذیری را روی آدرس‌های رزروشده به‌صورت سراسری انجام نمی‌داد، که این امر اجازه می‌داد سرور به گونه‌ای پیکربندی شود که اجاره‌های (leases) بی‌معنی برای مقادیر دلخواه آدرس صادر کند. نسخه‌های بعدی Kea این بررسی‌ها را انجام می‌دهند.

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

"Dhcp4": {
    # This specifies global reservations.
    # They will apply to all subnets that
    # have global reservations enabled.
    "reservations": [
    {
       "hw-address": "aa:bb:cc:dd:ee:ff",
       "hostname": "hw-host-dynamic"
    },
    {
       "hw-address": "01:02:03:04:05:06",
       "hostname": "hw-host-fixed",
       # Use of IP addresses in global reservations is risky.
       # If used outside of a matching subnet, such as 192.0.1.0/24,
       # it will result in a broken configuration being handed
       # to the client.
       "ip-address": "192.0.1.77"
    },
    {
       "duid": "01:02:03:04:05",
       "hostname": "duid-host"
    },
    {
       "circuit-id": "'charter950'",
       "hostname": "circuit-id-host"
    },
    {
       "client-id": "01:11:22:33:44:55:66",
       "hostname": "client-id-host"
    }
    ],
    "valid-lifetime": 600,
    "subnet4": [
    {
        "id": 1,
        "subnet": "10.0.0.0/24",
        # Specify if the server should look up global reservations.
        "reservations-global": true,
        # Specify if the server should look up in-subnet reservations.
        "reservations-in-subnet": false,
        # Specify if the server can assume that all reserved addresses
        # are out-of-pool. It can be ignored because "reservations-in-subnet"
        # is false.
        # "reservations-out-of-pool": false,
        "pools": [ { "pool": "10.0.0.10-10.0.0.100" } ]
    }
    ]
}

هنگام استفاده از backendهای پایگاه‌داده، رزروهای سراسری میزبان با استفاده از مقدار 0 برای subnet-id از رزروهای عادی متمایز می‌شوند.

کلاس‌های کلاینت (Client classes) می‌توانند در فایل پیکربندی Kea و/یا از طریق رزروهای میزبان تعیین شوند. کلاس‌های مشخص‌شده در فایل پیکربندی Kea بلافاصله پس از دریافت بستهٔ DHCP ارزیابی می‌شوند و بنابراین می‌توان از آن‌ها برای اثرگذاری بر انتخاب زیرشبکه با استفاده از پارامتر client-classes مشخص‌شده در حوزهٔ (scope) زیرشبکه استفاده کرد. کلاس‌های مشخص‌شده درون رزروهای میزبان، پس از آن‌که سرور زیرشبکه‌ای را برای کلاینت انتخاب کرد، واکشی شده و به بسته اختصاص می‌یابند. این بدان معناست که کلاس کلاینت مشخص‌شده درون یک رزرو میزبان نمی‌تواند برای تأثیرگذاری بر تخصیص زیرشبکه به این کلاینت استفاده شود، مگر اینکه زیرشبکه متعلق به یک shared network باشد. اگر زیرشبکه متعلق به یک shared network باشد، ممکن است سرور هنگام تلاش برای تخصیص اجاره (lease)، تخصیص زیرشبکه را به‌صورت پویا تغییر دهد. اگر زیرشبکه به یک shared network تعلق نداشته باشد، زیرشبکه پس از یک‌بار انتخاب شدن، دیگر تغییر نخواهد کرد.

اگر زیرشبکه متعلق به یک shared network نباشد، می‌توان از دسته‌بندی کلاینت مبتنی بر رزرو میزبان برای انتخاب یک استخر (pool) در زیرشبکه، به شرح زیر استفاده کرد:

{
    "Dhcp4": {
        "client-classes": [
            {
                "name": "reserved_class"
            },
            {
                "name": "unreserved_class",
                "test": "not member('reserved_class')"
            }
        ],
        "subnet4": [
            {
                "id": 1,
                "subnet": "192.0.2.0/24",
                "reservations": [
                    {
                        "hw-address": "aa:bb:cc:dd:ee:fe",
                        "client-classes": [ "unreserved_class" ]
                    }
                ],
                "pools": [
                    {
                        "pool": "192.0.2.10 - 192.0.2.20",
                        "client-classes": [ "unreserved_class" ]
                    },
                    {
                        "pool": "192.0.2.30 - 192.0.2.40",
                        "client-classes": [ "reserved_class" ]
                    },
                    {
                        "pool": "192.0.2.50 - 192.0.2.60"
                    }
                ]
            }
        ]
    }
}

کلاس reserved_class بدون پارامتر test اعلان شده است زیرا تنها می‌تواند از طریق سازوکار رزرو میزبان به یک کلاینت اختصاص یابد. کلاس دوم، unreserved_class، به کلاینت‌هایی اختصاص داده می‌شود که به reserved_class تعلق ندارند.

نخستین استخر در زیرشبکه برای کلاینت‌هایی استفاده می‌شود که چنین رزروی ندارند. استخر دوم تنها برای کلاینت‌هایی استفاده می‌شود که دارای رزروی برای reserved_class هستند. استخر سوم یک استخر بدون محدودیت برای همهٔ کلاینت‌هاست که شامل کلاینت‌های هر دو دستهٔ reserved_class و unreserved_class می‌شود.

این قطعه‌پیکربندی شامل یک رزرو میزبان است که باعث می‌شود کلاینت با آدرس MAC معادل aa:bb:cc:dd:ee:fe به reserved_class اختصاص یابد. بدین ترتیب، به این کلاینت یک آدرس IP از دومین استخر آدرس اختصاص داده می‌شود.

رزروهای تعریف‌شده در زیرشبکه‌ای که متعلق به یک shared network است، برای کلاینتی که در غیر این صورت با آن منطبق می‌بود قابل مشاهده نیستند؛ بنابراین نمی‌توان از آن‌ها برای انتخاب استخرها و همچنین زیرشبکه‌ها استفاده کرد..SS انتخاب زیرشبکه با رزروهای کلاس کلاینت (Subnet Selection with Client Class Reservations)

یک مورد کاربرد خاص وجود دارد که در آن انتخاب زیرشبکه ممکن است تحت تأثیر کلاس‌های کلاینت مشخص‌شده درون رزروهای میزبان قرار گیرد: زمانی که کلاینت به یک شبکهٔ اشتراکی (shared network) تعلق دارد. در چنین حالتی امکان استفاده از رده‌بندی برای انتخاب یک زیرشبکه درون این شبکهٔ اشتراکی وجود دارد. مثال زیر را در نظر بگیرید:

{
    "Dhcp4": {
        "client-classes": [
            {
                "name": "reserved_class"
            },
            {
                "name": "unreserved_class",
                "test": "not member('reserved_class')"
            }
        ],
        "reservations": [
            {
                "hw-address": "aa:bb:cc:dd:ee:fe",
                "client-classes": [ "reserved_class" ]
            }
        ],
        "reservations-global": true,
        "reservations-in-subnet": false,
        "shared-networks": [
            {
                "name": "net",
                "subnet4": [
                    {
                        "id": 1,
                        "subnet": "192.0.2.0/24",
                        "pools": [
                            {
                                "pool": "192.0.2.10-192.0.2.20",
                                "client-classes": [ "unreserved_class" ]
                            },
                            {
                                "pool": "192.0.2.30-192.0.2.40",
                                "client-classes": [ "unreserved_class" ]
                            }
                        ]
                    },
                    {
                        "id": 2,
                        "subnet": "192.0.3.0/24",
                        "pools": [
                            {
                                "pool": "192.0.3.10-192.0.3.20",
                                "client-classes": [ "reserved_class" ]
                            },
                            {
                                "pool": "192.0.3.30-192.0.3.40",
                                "client-classes": [ "reserved_class" ]
                            }
                        ]
                    },
                    {
                        "id": 3,
                        "subnet": "192.0.4.0/24",
                        "pools": [
                            {
                                "pool": "192.0.4.10-192.0.4.20"
                            },
                            {
                                "pool": "192.0.4.30-192.0.4.40"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}

این شبیه به مثالی است که در Pool Selection with Client Class Reservations شرح داده شده است. با این حال، این بار سه زیرشبکه وجود دارد که استخرهای (pools) دو مورد اول هر کدام با یک کلاس متفاوت مرتبط هستند.

به کلاینت‌هایی که رزروی برای reserved_class ندارند، نشانی‌ای از زیرشبکهٔ اول تخصیص داده می‌شود و هنگامی که آن پر شد، از زیرشبکهٔ سوم. به کلاینت‌های دارای رزرو برای reserved_class، نشانی‌ای از زیرشبکهٔ دوم و هنگام پر شدن آن، از زیرشبکهٔ سوم تخصیص می‌یابد.

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

برای اینکه یک زیرشبکه به یک کلاس خاص محدود شود، یا از آن صرف‌نظر گردد، تمام استخرهای درون آن زیرشبکه باید به ترتیب توسط reserved_class یا unreserved_class محافظت شوند.

علاوه بر این، رزرو برای کلاس کلاینت باید در حوزهٔ سراسری (رزرو سراسری) مشخص شود و مقدار reservations-global باید روی true تنظیم شده باشد.

در مثال بالا، پارامتر پیکربندی client-classes می‌توانست به جای سطح استخر در سطح زیرشبکه نیز مشخص شود و همان اثر را داشته باشد.

اگر زیرشبکه‌ها خارج از شبکه‌های اشتراکی تعریف می‌شدند و client-classes در سطح زیرشبکه مشخص می‌شد، آنگاه برای کارکرد انتخاب زیرشبکه، فعال بودن early-global-reservations-lookup نیز الزامی می‌بود.

رزروهای میزبان برای جلوگیری از ایجاد چندین رزرو برای یک نشانی IP یکسان درون یک زیرشبکهٔ خاص طراحی شده‌اند تا از رقابت دو کلاینت مختلف بر سر یک نشانی جلوگیری شود. هنگام استفاده از تنظیمات پیش‌فرض، اگر سرور دو یا چند رزرو برای یک نشانی IP یکسان در یک زیرشبکه درون فایل پیکربندی Kea پیدا کند، خطای پیکربندی برمی‌گرداند. libdhcp_host_cmds.so <#std-ischooklib-libdhcp_host_cmds.so> در پاسخ به دستور reservation-add <#std-isccmd-reservation-add>، در صورتی که تشخیص دهد برای نشانی IP مورد نظری که رزرو جدید برای آن افزوده می‌شود رزروی در پایگاه داده وجود دارد، یک خطا برمی‌گرداند.

در برخی استقرارها، یک میزبان واحد می‌تواند یکی از چندین رابط شبکه را برای برقراری ارتباط با سرور DHCP انتخاب کند، و سرور باید بدون توجه به رابطِ استفاده‌شده، نشانی IP یکسانی را به میزبان تخصیص دهد. از آنجا که به هر رابط یک نشانی MAC متفاوت تخصیص می‌یابد، به این معنی است که باید چندین رزرو میزبان ایجاد شود تا تمام نشانی‌های MAC موجود در این میزبان را با نشانی‌های IP مرتبط کند. استفاده از نشانی‌های IP مختلف برای هر رابط غیرعملی است و اتلاف فضای نشانی IPv4 تلقی می‌شود، به‌ویژه از آنجا که میزبان معمولاً تنها از یک رابط برای ارتباط با سرور استفاده می‌کند و بنابراین تنها یک نشانی IP در حال استفاده است.

این امر نیاز به ایجاد چندین رزرو میزبان برای یک نشانی IP واحد درون یک زیرشبکه را ایجاد می‌کند؛ این امکان از نسخهٔ Kea 1.9.1 به عنوان یک حالت عملیاتی اختیاری پشتیبانی می‌شود که با پارامتر سراسری ip-reservations-unique فعال می‌گردد.

پارامتر ip-reservations-unique یک پارامتر بولی (boolean) است که مقدار پیش‌فرض آن true است و تعیین بیش از یک رزرو برای یک نشانی IP یکسان را در یک زیرشبکهٔ مشخص ممنوع می‌کند. تنظیم این پارامتر روی false اجازه می‌دهد تا چنین رزروهایی هم در فایل پیکربندی Kea و هم در بک‌اند پایگاه دادهٔ میزبان، از طریق libdhcp_host_cmds.so <#std-ischooklib-libdhcp_host_cmds.so> ایجاد شوند.

تنظیم ip-reservations-unique روی false هنگام استفاده از memfile، MySQL یا PostgreSQL پشتیبانی می‌شود. این تنظیم هنگام استفاده از Host Cache (نگاه کنید به libdhcp_host_cache.so: Host Cache Reservations for Improved Performance <#hooks-host-cache>) یا بک‌اند RADIUS (نگاه کنید به libdhcp_radius.so: RADIUS Server Support <#hooks-radius>) پشتیبانی نمی‌شود. این بک‌اندهای رزرو از چندین رزرو برای یک IP یکسان پشتیبانی نمی‌کنند؛ اگر هر یک از این قلاب‌ها (hooks) بارگذاری شده باشد و ip-reservations-unique روی false تنظیم شود، آنگاه خطای پیکربندی صادر شده و سرور راه‌اندازی نمی‌شود.

نکته:

هنگامی که ip-reservations-unique روی true (مقدار پیش‌فرض) تنظیم شده باشد، سرور تضمین می‌کند که رزروهای IP برای یک زیرشبکه درون یک بک‌اند میزبان منفرد و/یا فایل پیکربندی Kea یکتا هستند. این کار تضمین نمی‌کند که رزروها در چندین بک‌اند یکتا باشند. هنگام راه‌اندازی سرور، تنها رزروهای IP تعریف‌شده در فایل پیکربندی Kea از نظر یکتایی بررسی می‌شوند.

در ادامه یک پیکربندی نمونه با دو رزرو برای یک نشانی IP یکسان اما با نشانی‌های MAC متفاوت آورده شده است:

"Dhcp4": {
    "ip-reservations-unique": false,
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "reservations": [
                {
                    "hw-address": "1a:1b:1c:1d:1e:1f",
                    "ip-address": "192.0.2.11"
                },
                {
                    "hw-address": "2a:2b:2c:2d:2e:2f",
                    "ip-address": "192.0.2.11"
                }
            ]
        }
    ]
}

امکان کنترل پارامتر ip-reservations-unique از طریق Configuration Backend در DHCPv4 وجود دارد. اگر تنظیم جدید این پارامتر با بک‌اندهای فعلی مورد استفاده در تضاد باشد (یعنی بک‌اندها از تنظیم جدید پشتیبانی نکنند)، تنظیم جدید نادیده گرفته شده و یک پیام ثبت وقایع هشداری ایجاد می‌شود. بک‌اندها با این فرض که رزروهای IP در هر زیرشبکه یکتا هستند، به استفاده از تنظیم پیش‌فرض ادامه می‌دهند. برای مجاز کردن ایجاد رزروهای IP غیریکتا، مدیر سیستم باید بک‌اندهایی را که از آن‌ها پشتیبانی نمی‌کنند از فایل پیکربندی حذف کند.

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

نکته:

در حال حاضر، سرور Kea بررسی نمی‌کند که آیا با به‌روزرسانی ip-reservations-unique از false به true، چندین رزرو برای یک نشانی IP در پایگاه‌های دادهٔ میزبان MySQL و/یا PostgreSQL وجود دارد یا خیر. این امر ممکن است باعث ایجاد مشکلاتی در تخصیص اجاره‌ها شود. مدیر سیستم باید پیش از به‌روزرسانی پیکربندی اطمینان حاصل کند که برای هر نشانی IP در هر زیرشبکه حداکثر یک رزرو وجود دارد.

پارامتر reservations-lookup-first یک پارامتر بولی است که کنترل می‌کند آیا جستجوی رزروهای میزبان باید پیش از جستجوی اجاره (lease lookup) انجام شود یا خیر. این پارامتر تنها زمانی تأثیرگذار است که چندریسمانی (multi-threading) غیرفعال باشد. هنگامی که چندریسمانی فعال باشد، جستجوی رزروهای میزبان همواره ابتدا انجام می‌شود تا از قفل شدن منابع هنگام جستجوی اجاره جلوگیری شود. مقدار پیش‌فرض پارامتر reservations-lookup-first در زمان غیرفعال بودن چندریسمانی، false است..SS رزرو میزبان به‌عنوان کنترل دسترسی پایه‌ای

تعریف یک رزرو میزبان (host reservation) که تنها حاوی یک شناسه، بدون هیچ آدرس، گزینه یا مقداری باشد، امکان‌پذیر است. در برخی استقرارها این کار مفید است، چرا که میزبان‌های دارای رزرو به کلاس KNOWN تعلق دارند در حالی که سایر میزبان‌ها تعلق ندارند. از این قابلیت می‌توان به‌عنوان یک سازوکار پایه‌ای کنترل دسترسی استفاده کرد.

مثال زیر این مفهوم را نشان می‌دهد. این مثال یک زیرشبکه IPv4 واحد را مشخص می‌کند که تمام کارخواه‌ها آدرسی از آن دریافت خواهند کرد. با این حال، تنها کارخواه‌های شناخته‌شده (آن‌هایی که رزرو دارند) مسیریاب پیش‌فرضشان پیکربندی خواهد شد. رزروهای خالی، یعنی رزروهایی که تنها معیار شناسایی دارند، می‌توانند به‌عنوان روشی برای شناخته‌شدن کارخواه‌ها سودمند باشند.

"Dhcp4": {
    "client-classes": [
        {
            "name": "KNOWN",
            "option-data": [
                {
                    "name": "routers",
                    "data": "192.0.2.250"
                }
            ]
        }
    ],
    "reservations": [
        // کارخواه‌های این فهرست به کلاس KNOWN افزوده خواهند شد.
        { "hw-address": "aa:bb:cc:dd:ee:fe" },
        { "hw-address": "11:22:33:44:55:66" }
    ],
    "reservations-global": true,
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [
                {
                    "pool": "192.0.2.1-192.0.2.200"
                }
            ]
        }
    ]
}

این مفهوم را می‌توان با استفاده از رزروها در ترکیب با برچسب‌گذاری کلاسی گزینه‌ها (ببینید Option Class-Tagging <#option-class-tagging>) فراتر نیز گسترش داد. یک سناریوی واقعی مناسب می‌تواند وضعیتی باشد که در آن برخی از مشتریان یک ISP صورت‌حساب‌های خود را پرداخت نکرده‌اند. به این مشتریان باید یک مسیریاب جایگزین اختصاص داده شود که به‌جای هدایت و بازپخش ترافیک، آن‌ها را به یک پورتال ورود (captive portal) هدایت کرده و از آن‌ها بخواهد حساب‌های خود را تسویه کنند. می‌توان از رزروها برای تخصیص یک کارخواه به کلاس "blocked" استفاده کرد که متعاقباً برای تعیین مقدار گزینه مسیریاب همان‌طور که در زیر نشان داده شده است، به کار می‌رود:

"Dhcp4": {
    "client-classes": [
        {
            "name": "blocked"
        }
    ],
    "reservations": [
        // کارخواه‌های این فهرست به کلاس KNOWN افزوده خواهند شد. برخی
        // نیز به کلاس blocked افزوده می‌شوند.
        {
          "hw-address": "aa:bb:cc:dd:ee:fe",
          "client-classes": [ "blocked" ]
        },
        {
            "hw-address": "11:22:33:44:55:66"
        }
    ],
    "reservations-global": true,
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [
                {
                    "pool": "192.0.2.1-192.0.2.200"
                }
            ],
            "option-data": [
                {
                    // مسیریاب برای مشتریان مسدودشده.
                    "client-classes": [ "blocked" ],
                    "name": "routers",
                    "data": "192.0.2.251"
                },
                {
                    // مسیریاب برای مشتریان خوش‌حساب.
                    "name": "routers",
                    "data": "192.0.2.250"
                }
            ]
        }
    ]
}

کارسازهای DHCP اطلاعات زیرشبکه را به دو روش به کار می‌برند. این اطلاعات هم برای تعیین نقطه اتصال، یعنی جایی که کارخواه به شبکه متصل است، و هم برای گروه‌بندی اطلاعات مربوط به یک مکان خاص در شبکه استفاده می‌شود. گاهی اوقات استقرار بیش از یک زیرشبکه منطقی IP روی یک پیوند فیزیکی یکسان مفید است. درک این‌که دو یا چند زیرشبکه روی یک پیوند یکسان استفاده می‌شوند نیازمند منطق اضافی در کارساز DHCP است. این قابلیت در Kea با عنوان "شبکه‌های اشتراکی" (shared networks) و گاهی نیز "shared subnets" نامیده می‌شود؛ در نام‌گذاری Microsoft به آن "multinet" گفته می‌شود.

موارد متعددی وجود دارد که ویژگی شبکه‌های اشتراکی در آن‌ها سودمند است؛ در این‌جا تنها به چند مورد از رایج‌ترین آن‌ها اشاره می‌کنیم. نخستین و تا حد زیادی رایج‌ترین مورد استفاده، یک شبکه IPv4 موجود است که گسترش یافته و فضای آدرس در دسترس آن رو به پایان است. به‌جای مهاجرت دادن تمام دستگاه‌ها به یک زیرشبکه جدید و بزرگ‌تر، آسان‌تر است که زیرشبکه‌های اضافی روی زیرشبکه موجود پیکربندی شوند. گاهی اوقات به دلیل تکه‌تکه شدن فضای آدرس (برای نمونه هنگامی که تنها چندین /24 ناپیوسته در دسترس است)، این تنها انتخاب ممکن است. همچنین، پیکربندی زیرشبکه‌های اضافی این مزیت را دارد که در عملکرد دستگاه‌های موجود اختلالی ایجاد نمی‌کند.

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

به کارخواهی که به یک شبکه اشتراکی متصل است، ممکن است آدرسی از هر یک از استخرهای تعریف‌شده در زیرشبکه‌های متعلق به آن شبکه اشتراکی اختصاص داده شود. از نظر داخلی، کارساز یکی از زیرشبکه‌های متعلق به شبکه اشتراکی را انتخاب کرده و تلاش می‌کند آدرسی را از این زیرشبکه تخصیص دهد. اگر کارساز نتواند آدرسی از زیرشبکه انتخاب‌شده تخصیص دهد (به‌عنوان مثال به دلیل اتمام استخر آدرس)، از زیرشبکه دیگری از همان شبکه اشتراکی استفاده کرده و سعی می‌کند آدرسی از آن تخصیص دهد. کارساز معمولاً پیش از شروع تخصیص آدرس از سایر زیرشبکه‌های متعلق به همان شبکه اشتراکی، تمام آدرس‌های موجود در یک زیرشبکه مفروض را تخصیص می‌دهد. با این حال، در شرایط خاص ممکن است پیش از پایان یافتن استخرهای آدرس در زیرشبکه نخست، آدرسی از زیرشبکه دیگری به کارخواه اختصاص یابد؛ این حالت گاهی زمانی رخ می‌دهد که کارخواه یک نشانه (hint) متعلق به زیرشبکه دیگری ارائه دهد، یا کارخواه دارای رزروهایی در زیرشبکه‌ای غیر از پیش‌فرض باشد.

نکته:

استقرارها نباید فرض کنند که Kea پیش از تخصیص آدرس از سایر زیرشبکه‌ها، حتماً منتظر می‌ماند تا تمام آدرس‌های زیرشبکه نخست در یک شبکه اشتراکی را تخصیص دهد.

برای تعریف یک شبکه اشتراکی، یک حوزه (scope) پیکربندی اضافی معرفی شده است:

{
"Dhcp4": {
    "shared-networks": [
        {
            # نام شبکه اشتراکی. این می‌تواند یک رشته دلخواه باشد
            # و باید میان تمام شبکه‌های اشتراکی یکتا باشد.
            "name": "my-secret-lair-level-1",
            # انتخاب‌گر زیرشبکه می‌تواند در سطح shared-network مشخص شود.
            # زیرشبکه‌های این شبکه اشتراکی برای کارخواه‌های متصل مستقیم
            # که درخواست‌ها را به رابط "eth0" کارساز می‌فرستند انتخاب خواهند شد.
            "interface": "eth0",
            # این بخش فهرست زیرشبکه‌ها را در این شبکه اشتراکی آغاز می‌کند.
            # در این مثال دو زیرشبکه وجود دارد.
            "subnet4": [
                {
                    "id": 1,
                    "subnet": "10.0.0.0/8",
                    "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ]
                },
                {
                    "id": 2,
                    "subnet": "192.0.2.0/24",
                    "pools": [ { "pool":  "192.0.2.100 - 192.0.2.199" } ]
                }
            ]
        }
    ],
    # پایان shared-networks
    # احتمال دارد که در شبکه ترکیبی از زیرشبکه‌های عادی،
    # "ساده" و شبکه‌های اشتراکی وجود داشته باشد. ترکیب آن‌ها
    # در همان فایل پیکربندی کاملاً مجاز است.
    #
    # این یک زیرشبکه عادی است. بخشی از هیچ شبکه اشتراکی نیست.
    "subnet4": [
        {
            "id": 3,
            "subnet": "192.0.3.0/24",
            "pools": [ { "pool":  "192.0.3.1 - 192.0.3.200" } ],
            "interface": "eth1"
        }
    ]
}
}

همان‌طور که در مثال نشان داده شد، ترکیب زیرشبکه‌های اشتراکی و عادی ("ساده") امکان‌پذیر است. هر شبکه اشتراکی باید نامی یکتا داشته باشد. این نام مشابه شناسه (ID) برای زیرشبکه‌ها است، اما انعطاف‌پذیری بیشتری به مدیران سیستم می‌دهد. این نام برای ثبت وقایع (logging) و همچنین در سطوح داخلی برای شناسایی شبکه‌های اشتراکی به کار می‌رود.

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

شبکه‌های اشتراکی این امکان را فراهم می‌کنند که پارامترهای متعددی را در حوزه شبکه اشتراکی تعیین کنید که برای تمام زیرشبکه‌های درون آن اعمال می‌شوند. در صورت نیاز، این امکان وجود دارد که پارامتری در حوزه shared-network مشخص شده و سپس مقدار آن در حوزه زیرشبکه بازنویسی شود. برای نمونه:

{
"shared-networks": [
    {
        "name": "lab-network3",
        "interface": "eth0",
        # این مقدار برای تمام زیرشبکه‌های این شبکه اشتراکی اعمال می‌شود، مگر
        # این‌که مقادیر در حوزه زیرشبکه بازنویسی شوند.
        "valid-lifetime": 600,
        # این گزینه در دسترس تمام زیرشبکه‌های این شبکه اشتراکی
        # قرار می‌گیرد.
        "option-data": [
        {
            "name": "log-servers",
            "data": "1.2.3.4"
        }
        ],
        "subnet4": [
            {
                "id": 1,
                "subnet": "10.0.0.0/8",
                "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ],
                # این زیرشبکه خاص از مقادیر متفاوتی استفاده می‌کند.
                "valid-lifetime": 1200,
                "option-data": [
                {
                    "name": "log-servers",
                    "data": "10.0.0.254"
                },
                {
                    "name": "routers",
                    "data": "10.0.0.254"
                } ]
            },
            {
                 "id": 2,
                 "subnet": "192.0.2.0/24",
                 "pools": [ { "pool":  "192.0.2.100 - 192.0.2.199" } ],
                 # این زیرشبکه مقدار valid-lifetime اختصاصی خود را مشخص نکرده است،
                 # بنابراین از حوزه شبکه اشتراکی به ارث برده می‌شود.
                 "option-data": [
                 {
                     "name": "routers",
                     "data": "192.0.2.1"
                 } ]
            }
        ]
    }
    ],
    ...
}

در این مثال، گزینه log-servers تعریف شده است که برای کارخواه‌ها در هر دو زیرشبکه این شبکه اشتراکی در دسترس است. همچنین، طول عمر معتبر (valid lifetime) روی ۱۰ دقیقه (600s) تنظیم شده است. با این حال، زیرشبکه نخست برخی از مقادیر را بازنویسی می‌کند (طول عمر معتبر ۲۰ دقیقه است و یک آدرس IP متفاوت برای log-servers وجود دارد)، و همچنین گزینه اختصاصی خود را اضافه می‌کند (آدرس مسیریاب). با فرض این‌که به کارخواهی که گزینه‌های مسیریاب و log-servers را درخواست می‌کند، یک اجاره (lease) از این زیرشبکه اختصاص یابد، اجاره‌ای به مدت ۲۰ دقیقه و مقدار 10.0.0.254 برای log-servers و routers دریافت خواهد کرد. اگر همان کارخواه به زیرشبکه دوم اختصاص یابد، یک اجاره ۱۰ دقیقه‌ای، مقدار 1.2.3.4 برای log-servers و routers تنظیم‌شده روی 192.0.2.1 را دریافت خواهد کرد..SS "ترافیک محلی و رله‌شده در شبکه‌های اشتراکی"

این امکان وجود دارد که نام یک رابط را در سطح shared-network مشخص کنید تا به کارساز اعلام شود که این شبکه اشتراکیِ مشخص، مستقیماً (نه از طریق رله‌ها) و با استفاده از رابط شبکه محلی در دسترس است. از آنجا که انتظار می‌رود تمام زیرشبکه‌ها در یک شبکه اشتراکی روی پیوند فیزیکی یکسانی استفاده شوند، تلاش برای تعریف یک شبکه اشتراکی با زیرشبکه‌هایی که از طریق رابط‌های متفاوتی در دسترس هستند یک خطای پیکربندی محسوب می‌شود. به عبارت دیگر، تمام زیرشبکه‌های درون شبکه اشتراکی باید مقدار یکسانی برای پارامتر interface داشته باشند. پیکربندی زیر نمونه‌ای از کاری است که نباید انجام داد:

{
"shared-networks": [
    {
        "name": "office-floor-2",
        "subnet4": [
            {
                "id": 1,
                "subnet": "10.0.0.0/8",
                "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ],
                "interface": "eth0"
            },
            {
                 "id": 2,
                 "subnet": "192.0.2.0/24",
                 "pools": [ { "pool":  "192.0.2.100 - 192.0.2.199" } ],
                 # Specifying the different interface name is a configuration
                 # error. This value should rather be "eth0" or the interface
                 # name in the other subnet should be "eth1".
                 "interface": "eth1"
            }
        ]
    }
],
...
}

برای به حداقل رساندن احتمال خطاهای پیکربندی، اغلب راحت‌تر است که نام رابط را به سادگی یک بار در سطح shared-network مشخص کنید، همان‌طور که در مثال زیر نشان داده شده است.

{
"shared-networks": [
    {
        "name": "office-floor-2",
        # This tells Kea that the whole shared network is reachable over a
        # local interface. This applies to all subnets in this network.
        "interface": "eth0",
        "subnet4": [
            {
                "id": 1,
                "subnet": "10.0.0.0/8",
                "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ]
            },
            {
                 "id": 2,
                 "subnet": "192.0.2.0/24",
                 "pools": [ { "pool":  "192.0.2.100 - 192.0.2.199" } ]
            }
        ]
    }
],
...
}

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

{
"shared-networks": [
    {
        "name": "kakapo",
        "subnet4": [
            {
                "id": 1,
                "subnet": "192.0.2.0/26",
                "relay": {
                    "ip-addresses": [ "192.1.1.1" ]
                },
                "pools": [ { "pool": "192.0.2.63 - 192.0.2.63" } ]
            },
            {
                "id": 2,
                "subnet": "10.0.0.0/24",
                "relay": {
                    # Specifying a different relay address for this
                    # subnet is a configuration error. In this case
                    # it should be 192.1.1.1 or the relay address
                    # in the previous subnet should be 192.2.2.2.
                    "ip-addresses": [ "192.2.2.2" ]
                },
                "pools": [ { "pool": "10.0.0.16 - 10.0.0.16" } ]
            }
        ]
    }
],
...
}

مجدداً، بهتر است نشانی رله در سطح shared-network مشخص شود؛ این مقدار توسط تمام زیرشبکه‌های متعلق به شبکه اشتراکی به ارث برده خواهد شد.

{
"shared-networks": [
    {
        "name": "kakapo",
        "relay": {
            # This relay address is inherited by both subnets.
            "ip-addresses": [ "192.1.1.1" ]
        },
        "subnet4": [
            {
                "id": 1,
                "subnet": "192.0.2.0/26",
                "pools": [ { "pool": "192.0.2.63 - 192.0.2.63" } ]
            },
            {
                "id": 2,
                "subnet": "10.0.0.0/24",
                "pools": [ { "pool": "10.0.0.16 - 10.0.0.16" } ]
            }
        ]
    }
],
...
}

اگرچه از نظر فنی امکان پیکربندی دو (یا چند) زیرشبکه در یک شبکه اشتراکی برای استفاده از نشانی‌های رله متفاوت وجود دارد، اما این کار تقریباً همیشه به رفتاری متفاوت از آنچه کاربر انتظار دارد منجر خواهد شد. در این حالت، کارساز Kea ابتدا یکی از زیرشبکه‌ها را با تطبیق نشانی رله در بسته کلاینت با پیکربندی زیرشبکه انتخاب می‌کند. با این حال، در صورتی که کلاینت از قبل اجاره‌ای در این زیرشبکه داشته باشد یا یک رزرو میزبان (host reservation) در این زیرشبکه داشته باشد، یا صرفاً اگر زیرشبکه انتخاب‌شده اولیه نشانی دردسترس دیگری نداشته باشد، کارساز ممکن است در نهایت از زیرشبکه دیگر استفاده کند (حتی اگر با نشانی رله مطابقت نداشته باشد). بنابراین، در صورتی که زیرشبکه‌ها متعلق به یک شبکه اشتراکی هستند، اکیداً توصیه می‌شود انتخاب‌کننده‌های زیرشبکه (رابط یا نشانی رله) همیشه در سطح shared-network مشخص شوند، چرا که تعیین آن‌ها در سطح زیرشبکه به‌ندرت مفید است و ممکن است به خطاهای پیکربندی شرح داده شده در بالا منجر شود..SS کلاس‌بندی کلاینت در شبکه‌های اشتراکی

گاهی مطلوب است که کلاینت‌ها بر اساس ویژگی‌های معینی به زیرشبکه‌های مشخصی تفکیک شوند. این سازوکار «کلاس‌بندی کلاینت» نامیده می‌شود و در Client Classification <#classify> شرح داده شده است.

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

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

پارامتر client-classes را می‌توان در دامنه‌های شبکه اشتراکی (shared network)، زیرشبکه (subnet) و/یا استخر (pool) مشخص کرد. اگر برای یک شبکه اشتراکی مشخص شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های تعیین‌شده برای آن شبکه باشند تا برای زیرشبکه‌های درون آن شبکه در نظر گرفته شوند. اگر برای یک زیرشبکه مشخص شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های تعیین‌شده برای آن زیرشبکه باشند تا برای استخرها یا رزروهای میزبان (host reservations) آن زیرشبکه در نظر گرفته شوند. اگر برای یک pool مشخص شود، کلاینت‌ها باید حداقل به یکی از کلاس‌های مشخص‌شده برای آن pool تعلق داشته باشند تا یک اجاره (lease) از آن pool دریافت کنند.

مثال زیر را در نظر بگیرید:

{
    "client-classes": [
        {
            "name": "b-devices",
            "test": "option[93].hex == 0x0002"
        }
    ],
    "shared-networks": [
        {
            "name": "galah",
            "interface": "eth0",
            "subnet4": [
                {
                    "id": 1,
                    "subnet": "192.0.2.0/26",
                    "pools": [ { "pool": "192.0.2.1 - 192.0.2.63" } ]
                },
                {
                    "id": 2,
                    "subnet": "10.0.0.0/24",
                    "pools": [ { "pool": "10.0.0.2 - 10.0.0.250" } ],
                    "client-classes": [ "b-devices" ]
                }
            ]
        }
    ]
}

اگر کلاینت به کلاس "b-devices" تعلق داشته باشد (چون شامل option 93 با مقدار 0x0002 است)، این امر تضمین نمی‌کند که زیرشبکه 10.0.0.0/24 برای این کلاینت استفاده شود (یا ترجیح داده شود). سرور می‌تواند از هر یک از این دو زیرشبکه استفاده کند، چرا که زیرشبکه 192.0.2.0/26 نیز برای این کلاینت مجاز است. کلاس‌بندی کلاینت مورد استفاده در این مورد باید به عنوان راهکاری برای محدود کردن دسترسی به زیرشبکه‌های خاص در نظر گرفته شود، نه به عنوان روشی برای تعیین اولویت زیرشبکه. برای نمونه، اگر کلاینتی عضو کلاس "b-devices" نباشد، فقط می‌تواند از زیرشبکه 192.0.2.0/26 استفاده کند و هرگز از زیرشبکه 10.0.0.0/24 استفاده نخواهد کرد.

یک کاربرد متداول برای کلاس‌بندی کلاینت در شبکه‌های کابلی (cable networks) است؛ جایی که مودم‌های کابلی باید از یک زیرشبکه و سایر دستگاه‌ها باید از زیرشبکه دیگری در همان شبکه اشتراکی استفاده کنند. در این حالت لازم است کلاس‌بندی بر روی تمام زیرشبکه‌ها اعمال شود. مثال زیر دو کلاس از دستگاه‌ها را تعریف می‌کند و انتخاب زیرشبکه بر اساس مقادیر option 93 صورت می‌گیرد.

{
    "client-classes": [
        {
            "name": "a-devices",
            "test": "option[93].hex == 0x0001"
        },
        {
            "name": "b-devices",
            "test": "option[93].hex == 0x0002"
        }
    ],
    "shared-networks": [
        {
            "name": "galah",
            "interface": "eth0",
            "subnet4": [
                {
                    "id": 1,
                    "subnet": "192.0.2.0/26",
                    "pools": [ { "pool": "192.0.2.1 - 192.0.2.63" } ],
                    "client-classes": [ "a-devices" ]
                },
                {
                    "id": 2,
                    "subnet": "10.0.0.0/24",
                    "pools": [ { "pool": "10.0.0.2 - 10.0.0.250" } ],
                    "client-classes": [ "b-devices" ]
                }
            ]
        }
    ]
}

در این مثال هر کلاس محدودیت خاص خود را دارد. تنها کلاینت‌هایی که متعلق به کلاس "a-devices" هستند می‌توانند از زیرشبکه 192.0.2.0/26 استفاده کنند و تنها کلاینت‌های متعلق به "b-devices" مجاز به استفاده از زیرشبکه 10.0.0.0/24 هستند. باید مراقبت کرد که قوانین کلاس‌بندی بیش از حد محدودکننده تعریف نشوند، چرا که کلاینت‌هایی که نتوانند از هیچ زیرشبکه‌ای استفاده کنند، رد سرویس خواهند شد. با این حال، اگر هدف ارائه‌ی سرویس فقط به کلاینت‌هایی با ویژگی‌های مشخص باشد (برای مثال، تنها تلفن‌های VoIP مجاز به اتصال روی یک پیوند باشند)، این رفتار می‌تواند نتیجه‌ی مطلوب باشد.

دستیابی به اثری مشابه با آنچه در این بخش مطرح شد، بدون استفاده از شبکه‌های اشتراکی نیز ممکن است. اگر زیرشبکه‌ها به جای شبکه اشتراکی در دامنه سراسری زیرشبکه‌ها (global subnets scope) قرار گیرند، سرور همچنان از قوانین کلاس‌بندی برای انتخاب زیرشبکه مناسب برای کلاس مشخصی از دستگاه‌ها استفاده خواهد کرد. مزیت عمده قرار دادن زیرشبکه‌ها درون شبکه اشتراکی این است که پارامترهای مشترک برای زیرشبکه‌هایی که به صورت منطقی گروه‌بندی شده‌اند، می‌تواند یک‌بار در دامنه shared-network تعیین شود؛ مانند پارامتر interface یا relay. تمامی زیرشبکه‌های متعلق به این شبکه اشتراکی این پارامترها را به ارث خواهند برد..SS رزروهای میزبان در شبکه‌های اشتراکی (Host Reservations in Shared Networks)

زیرشبکه‌هایی که بخشی از یک شبکه اشتراکی (shared network) هستند، مانند زیرشبکه‌های معمولی امکان رزرو میزبان را فراهم می‌کنند:

{
    "shared-networks": [
    {
        "name": "frog",
        "interface": "eth0",
        "subnet4": [
            {
                "subnet": "192.0.2.0/26",
                "id": 100,
                "pools": [ { "pool": "192.0.2.1 - 192.0.2.63" } ],
                "reservations": [
                    {
                        "hw-address": "aa:bb:cc:dd:ee:ff",
                        "ip-address": "192.0.2.28"
                    }
                ]
            },
            {
                "subnet": "10.0.0.0/24",
                "id": 101,
                "pools": [ { "pool": "10.0.0.1 - 10.0.0.254" } ],
                "reservations": [
                    {
                        "hw-address": "11:22:33:44:55:66",
                        "ip-address": "10.0.0.29"
                    }
                ]
            }
        ]
    }
    ]
}

شایان ذکر است که در صورت تعریف شبکه‌های اشتراکی، Kea هنگام پردازش یک بسته، بررسی‌های بیشتری انجام می‌دهد. نخست، Kea به‌جای بررسی ساده این موضوع که آیا برای یک کلاینت معین در زیرشبکه نخستینِ انتخاب‌شده رزروی وجود دارد یا خیر، تمام زیرشبکه‌های موجود در یک شبکه اشتراکی را برای یافتن رزرو جستجو می‌کند. این یکی از دلایلی است که تعریف یک شبکه اشتراکی ممکن است بر کارایی تأثیر بگذارد. اگر در هر زیرشبکه‌ای رزروی برای یک کلاینت وجود داشته باشد، همان زیرشبکه خاص برای کلاینت انتخاب می‌شود. هرچند از نظر فنی این یک خطا محسوب نمی‌شود، اما تعریف رزرو برای یک میزبان یکسان در چندین زیرشبکه متعلق به یک شبکه اشتراکی، شیوه‌ای نادرست (bad practice) تلقی می‌شود.

اگرچه کاملاً اجباری نیست، اما در صورتی که قرار است از پایگاه داده برای ذخیره رزروهای میزبان استفاده شود، اکیداً توصیه می‌شود از مقادیر صریح "id" برای زیرشبکه‌ها استفاده کنید. اگر یک شناسه مشخص نشود، مقادیر آن به‌طور خودکار تولید می‌شوند؛ بدین معنا که Kea مقادیر صحیح افزایشی را با شروع از ۱ اختصاص می‌دهد. بنابراین، شناسه‌های تولیدشده به‌طور خودکار در صورت تغییر پیکربندی پایدار نخواهند ماند.

پروتکل DHCPv4 از یک "شناسه سرور" (server identifier) استفاده می‌کند تا به کلاینت‌ها امکان تمایز بین چندین سرور موجود روی یک پیوند (link) یکسان را بدهد؛ این مقدار، یک نشانی IPv4 متعلق به سرور است. سرور، نشانی IPv4 مربوط به رابطی را انتخاب می‌کند که پیام از کلاینت (یا عامل رله) روی آن دریافت شده است. یک نمونه منفرد سرور در صورتی که پرس‌وجوها را روی چندین رابط دریافت کند، از چندین شناسه سرور استفاده خواهد کرد.

امکان بازنویسی (override) مقادیر پیش‌فرض شناسه سرور با مشخص کردن گزینه dhcp-server-identifier وجود دارد. پیکربندی این گزینه تنها در سطوح زیرشبکه، شبکه اشتراکی، کلاس کلاینت و سراسری پشتیبانی می‌شود. این گزینه نباید در سطح رزرو میزبان (host-reservation) مشخص شود. هنگام پیکربندی گزینه dhcp-server-identifier در سطح کلاس کلاینت، کلاس نباید پرچم only-in-additional-list را تنظیم کند؛ زیرا این کلاس پیش از آنکه سرور تعیین کند آیا پیام DHCP دریافت‌شده باید برای پردازش پذیرفته شود یا خیر، ارزیابی نمی‌شود. چنین کلاس‌هایی پس از انتخاب زیرشبکه ارزیابی می‌شوند. برای جزئیات بیشتر به بخش دسته‌بندی اضافی (Additional Classification) مراجعه کنید.

مثال زیر نحوه بازنویسی شناسه سرور را برای یک زیرشبکه نشان می‌دهد:

{
"subnet4": [
    {
        "subnet": "192.0.2.0/24",
        "option-data": [
            {
                "name": "dhcp-server-identifier",
                "data": "10.2.5.76"
            }
        ],
        ...
    }
],
...
}

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

یک پارامتر اختیاری interface در تعریف زیرشبکه در دسترس است تا مشخص کند زیرشبکه موردنظر محلی است؛ یعنی مستقیماً از طریق رابط تعیین‌شده قابل دسترسی است. به عنوان مثال، سروری که در نظر دارد از طریق eth0 به یک زیرشبکه محلی خدمات دهد، می‌تواند به صورت زیر پیکربندی شود:

"Dhcp4": {
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [
                 {
                     "pool": "192.0.2.100 - 192.0.2.199"
                 }
             ],
            "interface": "eth0"
        }
    ],
    ...
}

با فرض اینکه رابط سرور با نشانی IPv4 برابر 192.0.2.3 پیکربندی شده باشد، سرور پیام‌های دریافت‌شده از طریق این رابط از یک کلاینت با اتصال مستقیم را تنها در صورتی پردازش می‌کند که زیرشبکه‌ای پیکربندی شده باشد که این نشانی IPv4 به آن تعلق دارد، مانند 192.0.2.0/24. سرور از این زیرشبکه برای اختصاص یک نشانی IPv4 به کلاینت استفاده می‌کند.

قاعده بالا زمانی که کلاینت پیام خود را به‌صورت تک‌پخشی (unicast) ارسال می‌کند، یعنی در حال تلاش برای تمدید اجاره خود است، اعمال نمی‌شود؛ چنین پیامی از طریق هر رابطی پذیرفته می‌شود. کلاینتِ در حال تمدید، ciaddr را روی نشانی IPv4 فعلی مورد استفاده قرار می‌دهد و سرور از این نشانی برای انتخاب زیرشبکه کلاینت استفاده می‌کند (به‌ویژه برای تمدید اجاره با استفاده از این نشانی).

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

همچنین امکان تعیین یک نشانی IPv4 برای عامل رله در یک زیرشبکه مشخص وجود دارد. این مورد می‌تواند برای تطبیق بسته‌های ورودی به یک زیرشبکه در پیکربندی‌های غیرمعمول، مانند شبکه‌های اشتراکی، استفاده شود. برای جزئیات به بخش استفاده از یک عامل رله خاص برای یک زیرشبکه (Using a Specific Relay Agent for a Subnet) مراجعه کنید.

نکته:

سازوکار انتخاب زیرشبکه که در این بخش شرح داده شده، مبتنی بر این فرض است که از دسته‌بندی کلاینت (client classification) استفاده نمی‌شود. سازوکار دسته‌بندی، بسته به کلاس‌هایی که کلاینت به آن‌ها تعلق دارد، روش انتخاب زیرشبکه برای کلاینت را تغییر می‌دهد.

نکته:

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

یک رله باید رابطی متصل به پیوندی داشته باشد که کلاینت‌ها روی آن پیکربندی می‌شوند. به‌طور معمول، رله دارای یک آدرس IPv4 پیکربندی‌شده روی آن رابط است که متعلق به زیرشبکه‌ای است که کارساز از آن آدرس تخصیص می‌دهد. در حالت عادی، کارساز قادر است از آدرس IPv4 درج‌شده توسط رله (در فیلد giaddr بستهٔ DHCPv4) برای انتخاب زیرشبکهٔ مناسب استفاده کند.

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

مثال زیر فرض می‌کند که زیرشبکه‌ای با نشانی 192.0.2.0/24 وجود دارد که از طریق رله‌ای با آدرس IPv4 برابر با 10.0.0.1 قابل دسترسی است. کارساز می‌تواند این زیرشبکه را برای تمام بسته‌های ورودی که از سوی رله‌ای با آدرسی در زیرشبکهٔ 192.0.2.0/24 می‌آیند انتخاب کند. همچنین این زیرشبکه را برای رله‌ای با آدرس 10.0.0.1 نیز انتخاب می‌کند.

{
  "Dhcp4": {
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "relay": {
                "ip-addresses": [ "10.0.0.1" ]
            }
        }
    ]
  }
}

اگر relay مشخص شده باشد، پارامتر ip-addresses درون آن اجباری است. پارامتر ip-addresses از تعیین فهرستی از آدرس‌ها پشتیبانی می‌کند.

در برخی موارد، ترکیب اطلاعات آدرس رله (معرفی‌شده در «استفاده از یک عامل رله مشخص برای یک زیرشبکه») با دسته‌بندی کلاینت (توضیح‌داده‌شده در Client Classification <#classify>) مفید است. یک نمونهٔ خاص در شبکهٔ کابلی است، جایی که مودم‌ها معمولاً آدرس‌هایی از زیرشبکه‌ای متفاوت نسبت به تمامی دستگاه‌های متصل پشت خود دریافت می‌کنند.

فرض کنید یک Cable Modem Termination System (CMTS) با یک CM MAC (یک پیوند فیزیکی که مودم‌ها به آن متصل هستند) وجود دارد. می‌خواهیم مودم‌ها آدرس‌هایی از زیرشبکهٔ 10.1.1.0/24 دریافت کنند، در حالی که همهٔ دستگاه‌های متصل پشت مودم‌ها باید آدرس‌هایی از زیرشبکهٔ 192.0.2.0/24 بگیرند. دستگاه CMTS که به عنوان رله عمل می‌کند از آدرس 10.1.1.1 استفاده می‌نماید. پیکربندی زیر می‌تواند پاسخگوی این وضعیت باشد:

"Dhcp4": {
    "subnet4": [
        {
            "id": 1,
            "subnet": "10.1.1.0/24",
            "pools": [ { "pool": "10.1.1.2 - 10.1.1.20" } ],
            "client-classes": [ "docsis3.0" ],
            "relay": {
                "ip-addresses": [ "10.1.1.1" ]
            }
        },
        {
            "id": 2,
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "relay": {
                "ip-addresses": [ "10.1.1.1" ]
            }
        }
    ],
    ...
}

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

چنین رویداد نامطلوبی را کلاینت‌های قانونی می‌توانند (با استفاده از سازوکارهای ARP یا ICMP Echo Request) شناسایی کرده و با استفاده از پیام DHCPDECLINE به کارساز DHCPv4 گزارش دهند. کارساز یک بررسی اعتبارسنجی اولیه (sanity check) انجام می‌دهد (تا ببیند آیا کلاینتی که آدرس را رد می‌کند واقعاً قرار بوده از آن استفاده کند یا خیر) و سپس یک عملیات پاک‌سازی را اجرا می‌کند. هرگونه مدخل DNS مرتبط با آن آدرس حذف شده، رویداد ثبت می‌شود و قلاب‌ها اجرا می‌گردند. پس از پایان این کار، آدرس به عنوان ردشده (declined) علامت‌گذاری می‌شود (که نشان می‌دهد توسط موجودیتی ناشناس در حال استفاده است و در نتیجه برای تخصیص در دسترس نیست) و یک زمان تعلیق (probation time) برای آن تعیین می‌شود. مگر اینکه خلاف آن پیکربندی شده باشد، دورهٔ تعلیق ۲۴ ساعت به طول می‌انجامد؛ پس از این زمان، کارساز اجاره (lease) را بازیابی می‌کند (یعنی آن را دوباره به وضعیت در دسترس بازمی‌گرداند) و آدرس مجدداً برای تخصیص در دسترس خواهد بود. باید توجه داشت که اگر مشکل بنیادین دستگاهی که پیکربندی نادرستی دارد حل نشود، سناریوی آدرس تکراری تکرار خواهد شد. در صورت پیکربندی صحیح، این سازوکار امکان بازیابی خودکار از چنین رویدادی را بدون نیاز به هیچ‌گونه مداخلهٔ مدیر سیستم فراهم می‌کند.

برای پیکربندی دورهٔ تعلیق رد شدن با مقداری غیر از پیش‌فرض، می‌توان از نحو دستوری زیر استفاده کرد:

"Dhcp4": {
    "decline-probation-period": 3600,
    "subnet4": [
        {
            ...
        },
        ...
    ],
    ...
}

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

چندین آمار و نقطهٔ قلاب (hook point) مرتبط با روال رسیدگی به رد شدن وجود دارد. نقطهٔ قلاب lease4_decline پس از اینکه پیام ورودی DHCPDECLINE اعتبارسنجی شد و کارساز در شرف رد کردن اجاره است فعال می‌شود. آمار declined-addresses پس از بازگشت قلاب افزایش می‌یابد (هم در نوع سراسری و هم در نوع ویژهٔ زیرشبکه). (برای جزئیات بیشتر دربارهٔ آمارهای DHCPv4 و نقاط قلاب Kea، بخش Statistics in the DHCPv4 Server و Hook Libraries <#hooks-libraries> را ببینید.)

به محض سپری شدن زمان تعلیق، اجارهٔ ردشده با استفاده از روال استاندارد آزادسازی اجاره‌های منقضی‌شده، همراه با چند مرحلهٔ اضافی بازیابی می‌شود. به‌ویژه، هر دو آمار declined-addresses (سراسری و ویژهٔ زیرشبکه) کاهش می‌یابند. در همان زمان، آمارهای reclaimed-declined-addresses (باز هم در دو گونهٔ سراسری و ویژهٔ زیرشبکه) افزایش می‌یابند.

یادداشتی دربارهٔ آمارها: کارساز Kea پس از دریافت و پردازش موفق یک DHCPDECLINE، آمار assigned-addresses را کاهش نمی‌دهد. اگرچه از نظر فنی یک آدرس ردشده دیگر تخصیص‌یافته محسوب نمی‌شود، اما کاربرد اصلی آمار assigned-addresses نظارت بر بهره‌برداری از استخر است. بیشتر افراد فراموش می‌کنند که declined-addresses را در محاسبه بگنجانند و صرفاً از نسبت assigned-addresses/total-addresses استفاده می‌کنند. این امر باعث ایجاد تورش و کمتر نشان دادن میزان بهره‌برداری از استخر خواهد شد. از آنجا که این موضوع پتانسیل ایجاد سردرگمی جدی دارد، ISC تصمیم گرفت که بلافاصله پس از دریافت DHCPDECLINE آمار assigned-addresses را کاهش ندهد، بلکه این کار را بعداً زمانی انجام دهد که Kea آدرس را دوباره به استخر در دسترس بازمی‌گرداند..SS "آمارها در کارساز DHCPv4"

کارساز DHCPv4 از آمارهای زیر پشتیبانی می‌کند:

آماره نوع داده توضیحات
pkt4-received integer تعداد بسته‌های DHCPv4 دریافت‌شده. شامل همه بسته‌ها می‌شود: معتبر، ساختگی، مخدوش، ردشده، و غیره. انتظار می‌رود این آماره به سرعت رشد کند.
pkt4-discover-received integer تعداد بسته‌های DHCPDISCOVER دریافت‌شده. انتظار می‌رود این آماره افزایش یابد؛ افزایش آن بدین معناست که کارخواه‌هایی که به‌تازگی راه‌اندازی شده‌اند فرایند پیکربندی خود را آغاز کرده و بسته‌های اولیه آن‌ها به کارساز Kea رسیده است.
pkt4-offer-received integer تعداد بسته‌های DHCPOFFER دریافت‌شده. انتظار می‌رود این آماره همواره صفر بماند، زیرا بسته‌های DHCPOFFER توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند. مقدار غیرصفر نشان‌دهنده یک خطاست. یکی از علل محتمل می‌تواند یک عامل رله با رفتار نادرست باشد که پیام‌های DHCPOFFER را به اشتباه به سمت کارساز بازمی‌فرستد، به جای آنکه به کارخواه‌ها ارسال کند.
pkt4-request-received integer تعداد بسته‌های DHCPREQUEST دریافت‌شده. انتظار می‌رود این آماره افزایش یابد. رشد آن بدین معناست که کارخواه‌هایی که به‌تازگی راه‌اندازی شده‌اند، پاسخ کارساز (DHCPOFFER) را دریافت و پذیرفته‌اند و اکنون در حال درخواست یک نشانی (DHCPREQUEST) هستند.
pkt4-ack-received integer تعداد بسته‌های DHCPACK دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، چرا که بسته‌های DHCPACK توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند. یک مقدار غیرصفر نشان‌دهنده خطا است. یکی از علل محتمل می‌تواند عامل رله‌ای باشد که رفتار نادرست داشته و پیام‌های DHCPACK را به جای کارخواه‌ها، به اشتباه به سمت کارساز بازمی‌گرداند.
pkt4-nak-received integer تعداد بسته‌های DHCPNAK دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، چرا که بسته‌های DHCPNAK توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند. یک مقدار غیرصفر نشان‌دهنده خطا است. یکی از علل محتمل می‌تواند عامل رله‌ای باشد که رفتار نادرست داشته و پیام‌های DHCPNAK را به جای کارخواه‌ها، به اشتباه به سمت کارساز بازمی‌گرداند.
pkt4-release-received integer تعداد بسته‌های DHCPRELEASE دریافت‌شده. انتظار می‌رود این آماره افزایش یابد. رشد آن نشان می‌دهد کارخواه‌هایی که دارای نشانی بوده‌اند در حال خاموش شدن هستند یا از استفاده از نشانی‌هایشان دست می‌کشند.
pkt4-decline-received integer تعداد بسته‌های DHCPDECLINE دریافت‌شده. انتظار می‌رود این آماره نزدیک به صفر باقی بماند. افزایش آن نشان می‌دهد که یک کارخواه نشانی‌ای را اجاره کرده، اما متوجه شده است که آن نشانی در حال حاضر توسط یک دستگاه ناشناس در جای دیگری از شبکه در حال استفاده است.
pkt4-inform-received integer تعداد بسته‌های DHCPINFORM دریافت‌شده. انتظار می‌رود این آماره افزایش یابد. رشد آن بدان معناست که کارخواه‌هایی وجود دارند که یا نیازی به نشانی ندارند یا از قبل نشانی دارند و تنها علاقه‌مند به دریافت پارامترهای پیکربندی اضافی هستند.
pkt4-lease-query-received integer تعداد بسته‌های DHCPLEASEQUERY دریافت‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد.
pkt4-unknown-received integer تعداد بسته‌های دریافتی با نوع ناشناخته. مقدار غیرصفر این آماره نشان می‌دهد که کارساز بسته‌ای را دریافت کرده که قادر به تشخیص آن نبوده است؛ یا با نوعی پشتیبانی‌نشده یا احتمالاً بدقواره (بدون گزینه message-type).
pkt4-sent integer تعداد بسته‌های DHCPv4 ارسال‌شده. انتظار می‌رود این آماره با هر بار ارسال یک بسته توسط کارساز، رشد کند. به‌طور کلی، این مقدار باید تقریباً با pkt4-received همخوانی داشته باشد، زیرا بیشتر بسته‌های ورودی باعث پاسخ دادن کارساز می‌شوند. استثناهایی وجود دارد (مانند DHCPRELEASE)، بنابراین اگر کمتر از pkt4-received بود جای نگرانی نیست.
pkt4-offer-sent integer تعداد بسته‌های DHCPOFFER ارسال‌شده. انتظار می‌رود این آماره در بیشتر موارد پس از پردازش یک DHCPDISCOVER افزایش یابد. مواردی نامتداول اما معتبر وجود دارد که بسته‌های ورودی DHCPDISCOVER دور انداخته می‌شوند، اما به‌طور کلی انتظار می‌رود این آماره به pkt4-discover-received نزدیک باشد.
pkt4-ack-sent integer تعداد بسته‌های DHCPACK ارسال‌شده. انتظار می‌رود این آماره در بیشتر موارد پس از پردازش یک DHCPREQUEST افزایش یابد؛ مواردی وجود دارد که به جای آن DHCPNAK ارسال می‌شود. به‌طور کلی، مجموع pkt4-ack-sent و pkt4-nak-sent باید نزدیک به pkt4-request-received باشد.
pkt4-nak-sent integer تعداد بسته‌های DHCPNAK ارسال‌شده. انتظار می‌رود این آماره زمانی که کارساز تصمیم می‌گیرد نشانی درخواست‌شده توسط کارخواه را واگذار نکند، افزایش یابد. به‌طور کلی، مجموع pkt4-ack-sent و pkt4-nak-sent باید نزدیک به pkt4-request-received باشد.
pkt4-lease-query-response-unassigned-sent integer تعداد بسته‌های DHCPLEASEUNASSIGNED ارسال‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد.
pkt4-lease-query-response-unknown-sent integer تعداد بسته‌های DHCPLEASEUNKNOWN ارسال‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد.
pkt4-lease-query-response-active-sent integer تعداد بسته‌های DHCPLEASEACTIVE ارسال‌شده توسط کتابخانه قلاب leasequery. انتظار می‌رود این آماره افزایش یابد.
pkt4-service-disabled integer تعداد بسته‌های ورودی که هنگام غیرفعال بودن سرویس DHCP دور انداخته شدند.
pkt4-parse-failed integer تعداد بسته‌های ورودی که تجزیه آن‌ها ناموفق بود. مقدار غیرصفر این آماره نشان می‌دهد که کارساز بسته‌ای بدقواره یا ناقص دریافت کرده است. این ممکن است نشان‌دهنده مشکلات در شبکه، کارخواه‌های معیوب، یا وجود باگ در کارساز باشد.
pkt4-queue-full integer تعداد بسته‌های ورودی که به دلیل پر بودن صفی که قرار بود در آن قرار گیرند، دور انداخته شدند.
pkt4-duplicate integer تعداد بسته‌های ورودی که به دلیل تکراری شناخته شدن دور انداخته شدند.
pkt4-rfc-violation integer تعداد بسته‌های ورودی که در راستای پیروی از مشخصات پروتکل دور انداخته شدند.
pkt4-admin-filtered integer تعداد بسته‌های ورودی که به دلیل پیکربندی کارساز برای این کار دور انداخته شدند، مثلاً با دسته‌بندی پرس‌وجو در کلاس DROP.
pkt4-not-for-us integer تعداد بسته‌های ورودی که دور انداخته شدند زیرا باید توسط کارساز دیگری رسیدگی می‌شدند.
pkt4-processing-failed integer تعداد بسته‌های ورودی که دور انداخته شدند به این دلیل که خطایی غیرمنتظره در حین پردازش رخ داد.
pkt4-limit-exceeded integer تعداد بسته‌های ورودی که توسط کتابخانه قلاب limits دور انداخته شدند.
pkt4-receive-drop integer تعداد بسته‌های ورودی که دور انداخته شدند. دلیل دقیق دور انداختن بسته‌ها در گزارش‌ها ثبت می‌شود، اما رایج‌ترین دلایل ممکن است دریافت نوع بسته غیرقابل‌قبول، ممنوع بودن پاسخ مستقیم، عدم تطابق شناسه کارساز ارسال‌شده توسط کارخواه با شناسه کارساز، یا بروز خطایی غیرمنتظره در حین پردازش باشد.
subnet[id].total-addresses integer تعداد کل نشانی‌های موجود برای مدیریت DHCPv4 برای یک زیرشبکه مشخص؛ به بیان دیگر، این تعداد کل نشانی‌ها در همه استخرهای پیکربندی‌شده است. این آماره تنها هنگام به‌روزرسانی پیکربندی تغییر می‌کند. نشانی‌هایی که ممکن است به دلیل رزرو میزبان رزرو شده باشند را در نظر نمی‌گیرد. شناسه id شناسه زیرشبکه مربوط به یک زیرشبکه داده‌شده است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود.
subnet[id].pool[pid].total-addresses integer تعداد کل نشانی‌های موجود برای مدیریت DHCPv4 برای یک استخر زیرشبکه مشخص؛ به بیان دیگر، این تعداد کل نشانی‌ها در استخر زیرشبکه پیکربندی‌شده است. این آماره تنها هنگام به‌روزرسانی پیکربندی تغییر می‌کند. نشانی‌هایی که ممکن است به دلیل رزرو میزبان رزرو شده باشند را در نظر نمی‌گیرد. شناسه id شناسه زیرشبکه مربوط به یک زیرشبکه مشخص است. مقدار pid شناسه استخر مربوط به یک استخر مشخص است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه شده و در زمان رویداد پیکربندی مجدد، بازنشانی می‌شود.
assigned-addresses integer تعداد نشانی‌های تخصیص‌یافته. با هر بار اختصاص یک اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش یافته و با هر بار آزادسازی یک اجاره (دریافت پیام DHCPRELEASE) یا انقضای آن کاهش می‌یابد، و در طول رویداد پیکربندی مجدد بازنشانی می‌شود.
cumulative-assigned-addresses integer تعداد تجمعی نشانی‌هایی که از زمان راه‌اندازی کارساز تخصیص داده شده‌اند. با هر بار تخصیص یک نشانی افزایش می‌یابد و در رویداد پیکربندی مجدد بازنشانی نمی‌شود.
subnet[id].cumulative-assigned-addresses integer تعداد تجمعی نشانی‌های تخصیص‌یافته در یک زیرشبکه مشخص. با هر بار اختصاص یک اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش می‌یابد و هرگز کاهش نمی‌یابد. شناسه id شناسه زیرشبکه است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود.
subnet[id].pool[pid].cumulative-assigned-addresses integer تعداد تجمعی نشانی‌های تخصیص‌یافته در یک استخر زیرشبکه مشخص. با هر بار اختصاص یک اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش می‌یابد و هرگز کاهش نمی‌یابد. شناسه id شناسه زیرشبکه است. مقدار pid شناسه استخر مربوط به استخر است. این آماره برای هر استخر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود.
subnet[id].assigned-addresses integer تعداد نشانی‌های تخصیص‌یافته در یک زیرشبکه مشخص. با هر بار اختصاص اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام DHCPRELEASE) یا انقضای آن کاهش می‌یابد. شناسه id شناسه زیرشبکه است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود و در طول رویداد پیکربندی مجدد، بازنشانی می‌شود.
subnet[id].pool[pid].assigned-addresses integer تعداد نشانی‌های تخصیص‌یافته در یک استخر زیرشبکه مشخص. با هر بار اختصاص اجاره جدید (در نتیجه دریافت پیام DHCPREQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام DHCPRELEASE) یا انقضای آن کاهش می‌یابد. شناسه id شناسه زیرشبکه است. شناسه pid شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه می‌شود و در رویداد پیکربندی مجدد، بازنشانی می‌گردد.
reclaimed-leases integer تعداد اجاره‌های منقضی‌شده‌ای که از زمان راه‌اندازی کارساز بازپس گرفته شده‌اند. با هر بار بازپس‌گیری یک اجاره منقضی‌شده افزایش یافته و هرگز کاهش نمی‌یابد. این آماره می‌تواند به عنوان یک شاخص بلندمدت از تعداد واقعی اجاره‌های بازپس‌گرفته‌شده استفاده شود. این یک آماره سراسری است که همه زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].reclaimed-leases integer تعداد اجاره‌های منقضی‌شده مرتبط با یک زیرشبکه مشخص که از زمان راه‌اندازی کارساز بازپس گرفته شده‌اند. با هر بار بازپس‌گیری یک اجاره منقضی‌شده افزایش می‌یابد. شناسه id شناسه زیرشبکه برای یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به طور جداگانه ارائه می‌شود.
subnet[id].pool[pid].reclaimed-leases integer تعداد اجاره‌های منقضی‌شده مرتبط با یک استخر زیرشبکه مشخص که از زمان راه‌اندازی کارساز بازپس گرفته شده‌اند. با هر بار بازپس‌گیری یک اجاره منقضی‌شده افزایش می‌یابد. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. شناسه pid شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه می‌شود.
declined-addresses integer تعداد نشانی‌های IPv4 که در حال حاضر رد شده‌اند (declined)؛ شمارشی از تعداد اجاره‌هایی که اکنون در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این آماره غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاهی با رفتار نادرست در شبکه وجود دارد یا خیر. این یک آماره سراسری است که همه زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].declined-addresses integer تعداد نشانی‌های IPv4 که در حال حاضر در یک زیرشبکه مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که در حال حاضر در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این آماره غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاهی با رفتار نادرست در شبکه وجود دارد یا خیر. شناسه id شناسه زیرشبکه مربوط به یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود.
subnet[id].pool[pid].declined-addresses integer تعداد نشانی‌های IPv4 که در حال حاضر در یک استخر زیرشبکه مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که در حال حاضر در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این آماره غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاهی با رفتار نادرست در شبکه وجود دارد یا خیر. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. شناسه pid شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به صورت جداگانه ارائه می‌شود.
reclaimed-declined-addresses integer تعداد نشانی‌های IPv4 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف declined-addresses، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت استفاده کرد که نشان می‌دهد چه تعداد رد معتبر واقعی پردازش شده و نشانی آن‌ها بازیابی شده است. این یک آماره سراسری است که همه زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].reclaimed-declined-addresses integer تعداد نشانی‌های IPv4 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف declined-addresses، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت استفاده کرد که نشان می‌دهد چه تعداد رد معتبر واقعی پردازش شده و نشانی آن‌ها بازیابی شده است. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود.
subnet[id].pool[pid].reclaimed-declined-addresses integer تعداد نشانی‌های IPv4 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف declined-addresses، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت استفاده کرد که نشان می‌دهد چه تعداد رد معتبر واقعی پردازش شده و نشانی آن‌ها بازیابی شده است. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. مقدار pid شناسه استخر مربوطه است. این آماره برای هر استخر زیرشبکه به صورت جداگانه ارائه می‌شود.
pkt4-lease-query-received integer تعداد بسته‌های DHCPLEASEQUERY برای IPv4 که دریافت شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.)
pkt4-lease-query-response-unknown-sent integer تعداد پاسخ‌های DHCPLEASEUNKNOWN برای IPv4 که ارسال شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.)
pkt4-lease-query-response-unassigned-sent integer تعداد پاسخ‌های DHCPLEASEUNASSIGNED برای IPv4 که ارسال شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.)
pkt4-lease-query-response-active-sent integer تعداد پاسخ‌های DHCPLEASEACTIVE برای IPv4 که ارسال شده‌اند. (تنها در صورتی وجود دارد که کتابخانه قلاب Leasequery بارگیری شده باشد.)
v4-allocation-fail integer تعداد کل شکست‌های تخصیص نشانی برای یک کارخواه خاص. این شامل تعداد تلاش‌های تخصیص اجاره است که کارساز پیش از انصراف انجام داده، در صورتی که نتوانسته باشد از هیچ‌یک از استخرهای نشانی استفاده کند. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v4-allocation-fail integer تعداد کل شکست‌های تخصیص نشانی برای یک کارخواه خاص. این شامل تعداد تلاش‌های تخصیص اجاره است که کارساز پیش از انصراف انجام داده، در صورتی که نتوانسته باشد از هیچ‌یک از استخرهای نشانی استفاده کند. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود.
v4-allocation-fail-shared-network integer تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به یک شبکه مشترک (shared network). این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v4-allocation-fail-shared-network integer تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به یک شبکه مشترک. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود.
v4-allocation-fail-subnet integer تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به زیرشبکه‌ای که به یک شبکه مشترک تعلق ندارد. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v4-allocation-fail-subnet integer تعداد شکست‌های تخصیص نشانی برای یک کارخواه خاص متصل به زیرشبکه‌ای که به یک شبکه مشترک تعلق ندارد. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود.
v4-allocation-fail-no-pools integer تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانست از هیچ‌یک از استخرهای پیکربندی‌شده برای یک کارخواه خاص استفاده کند. همچنین ممکن است تمام زیرشبکه‌هایی که کارساز تلاش کرده از آن‌ها نشانی اختصاص دهد، فاقد استخر نشانی باشند. در این حالت، اگر اپراتور انتظار دارد به برخی کارخواه‌ها نشانی پویا تخصیص یابد، این وضعیت باید یک پیکربندی نادرست تلقی شود. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v4-allocation-fail-no-pools integer تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانست از هیچ‌یک از استخرهای پیکربندی‌شده برای یک کارخواه خاص استفاده کند. همچنین ممکن است تمام زیرشبکه‌هایی که کارساز تلاش کرده از آن‌ها نشانی اختصاص دهد، فاقد استخر نشانی باشند. در این حالت، اگر اپراتور انتظار دارد به برخی کارخواه‌ها نشانی پویا تخصیص یابد، این وضعیت باید یک پیکربندی نادرست تلقی شود. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود.
v4-allocation-fail-classes integer تعداد شکست‌های تخصیص نشانی هنگامی که بسته کارخواه متعلق به یک یا چند کلاس است. دلایل متعددی ممکن است برای عدم اختصاص اجاره وجود داشته باشد: به عنوان مثال، اگر همه استخرها نیاز داشته باشند که بسته‌ها به کلاس‌های خاصی تعلق داشته باشند و بسته ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگری که این اطلاعات می‌تواند مفید باشد، نشان دادن این است که ظرفیت نشانی‌های استخر رزروشده برای یک کلاس خاص به پایان رسیده است. این یک آماره سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v4-allocation-fail-classes integer تعداد شکست‌های تخصیص نشانی هنگامی که بسته کارخواه متعلق به یک یا چند کلاس است. دلایل متعددی ممکن است برای عدم اختصاص اجاره وجود داشته باشد: به عنوان مثال، اگر همه استخرها نیاز داشته باشند که بسته‌ها به کلاس‌های خاصی تعلق داشته باشند و بسته ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگری که این اطلاعات می‌تواند مفید باشد، نشان دادن این است که ظرفیت نشانی‌های استخر رزروشده برای یک کلاس خاص به پایان رسیده است. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است. این آماره برای هر زیرشبکه به صورت جداگانه ارائه می‌شود.
v4-lease-reuses integer تعداد دفعاتی که به عنوان بخشی از قابلیت کَش کردن اجاره (lease caching)، مقدار CLTT یک اجاره IPv4 در حافظه افزایش یافته و زمان انقضای آن در حافظه پایدار دست‌نخورده باقی مانده است. به این عمل «استفاده مجدد از اجاره» (lease reuse) گفته می‌شود. این آماره سراسری است.
subnet[id].v4-lease-reuses integer تعداد دفعاتی که به عنوان بخشی از قابلیت کَش کردن اجاره (lease caching)، مقدار CLTT یک اجاره IPv4 در حافظه افزایش یافته و زمان انقضای آن در حافظه پایدار دست‌نخورده باقی مانده است. به این عمل «استفاده مجدد از اجاره» گفته می‌شود. این آماره بر پایه هر زیرشبکه است. شناسه id شناسه زیرشبکه یک زیرشبکه مشخص است.
v4-reservation-conflicts integer تعداد تداخل‌های تخصیص رزرو میزبان که در تمامی زیرشبکه‌ها رخ داده است. هنگامی که یک کارخواه DHCP Discover ارسال می‌کند و با یک رزرو میزبان تطبیق داده می‌شود که پیش‌تر به کارخواه دیگری اجاره داده شده است، این شمارنده ۱ واحد افزایش می‌یابد.
subnet[id].v4-reservation-conflicts integer تعداد تداخل‌های تخصیص رزرو میزبان که در یک زیرشبکه مشخص رخ داده است. هنگامی که یک کارخواه DHCP Discover ارسال می‌کند و با یک رزرو میزبان تطبیق داده می‌شود که پیش‌تر به کارخواه دیگری اجاره داده شده است، این شمارنده ۱ واحد افزایش می‌یابد.

بسته‌های ورودی دور انداخته‌شده می‌توانند در pkt4-receive-drop و یک شمارنده دوم با شرح علت دور انداختن شمرده شوند:

pkt4-service-disabled - سرویس DHCP غیرفعال است
  • pkt4-parse-failed - تجزیه بسته با یک خطای مهلک مواجه شد
  • pkt4-queue-full - بسته‌ای که قرار بود در صف قرار گیرد، اما صف پر بود
  • pkt4-duplicate - تکرار بسته‌ای که در حال پردازش است
  • pkt4-rfc-violation - نقض RFC (یعنی مشخصات پروتکل دستور به دور انداختن آنها می‌دهد)
  • pkt4-admin-filtered - توسط مدیر فیلتر شده است
  • pkt4-not-for-us - باید توسط سرور دیگری مدیریت شود
  • pkt4-processing-failed - دریافت یک خطای غیرمنتظره در حین پردازش
  • pkt4-limit-exceeded - توسط کتابخانه هوکِ محدودیت‌ها (libdhcp_limits.so: Limits to Manage Lease Allocation and Packet Processing <#hooks-limits>) دور انداخته شد

نکته:

شناسه استخر (pool ID) را می‌توان با تنظیم صریح پارامتر pool-id در نگاشت پارامترهای استخر، روی هر استخر پیکربندی کرد. در صورت عدم پیکربندی، مقدار پیش‌فرض pool-id برابر 0 خواهد بود. آمار مربوط به شناسه استخر 0 به تمام آمار همه استخرهایی اشاره دارد که pool-id آنها پیکربندی نشده است. شناسه استخر نیازی نیست در درون زیرشبکه یا در میان زیرشبکه‌ها یکتا باشد. آمار مربوط به یک شناسه استخر مشخص در یک زیرشبکه، با سایر آمار تمام استخرهای دیگری که همان شناسه استخر را در آن زیرشبکه دارند ترکیب می‌شود.

نکته:

این بخش آمار ویژه DHCPv4 را شرح می‌دهد. برای بررسی اجمالی و نحوه استفاده از آمار، به Statistics <#stats> مراجعه کنید.

سرور DHCPv4 دو پارامتر سراسری را برای کنترل محدودیت‌های پیش‌فرض نمونه‌های آماری ارائه می‌دهد:

  • statistic-default-sample-count - حداکثر تعداد پیش‌فرض نمونه‌هایی را که باید نگهداری شوند تعیین می‌کند. مقدار ویژه 0 نشان می‌دهد که باید از حداکثر طول عمر پیش‌فرض استفاده شود.
  • statistic-default-sample-age - حداکثر طول عمر پیش‌فرض (به ثانیه) نمونه‌هایی که باید نگهداری شوند را تعیین می‌کند.

به عنوان مثال، برای کاهش بار سربار نگهداری آمار، حداکثر تعداد نمونه پیش‌فرض را روی 1 تنظیم کنید تا فقط یک نمونه نگهداری شود:

"Dhcp4": {
    "statistic-default-sample-count": 1,
    "subnet4": [
        {
            ...
        },
        ...
    ],
    ...
}

آمارها را می‌توان به‌صورت دوره‌ای بازیابی کرد تا بینش بیشتری نسبت به عملکرد Kea به دست آید. یکی از ابزارهایی که از این قابلیت بهره می‌برد ISC Stork است. برای جزئیات بیشتر به Monitoring Kea With Stork <#stork> مراجعه کنید.

رابط مدیریتی (management API) امکان صدور دستورهای مدیریتی خاص، مانند بازیابی آمار، بازپیکربندی، یا خاموش کردن را فراهم می‌کند. برای جزئیات بیشتر، به Management API <#ctrl-channel> مراجعه کنید. به‌طور پیش‌فرض هیچ سوکتی باز نیست؛ برای هدایت Kea به باز کردن یک سوکت، می‌توان از ورودی زیر در فایل پیکربندی استفاده کرد:

"Dhcp4": {
    "control-sockets": [
        {
            "socket-type": "unix",
            "socket-name": "/path/to/the/unix/socket"
        }
    ],
    "subnet4": [
        {
            ...
        },
        ...
    ],
    ...
}

تا نسخه 2.7.2 سرور Kea، تنها نوع کانال ارتباطی پشتیبانی‌شده، سوکت جریانی UNIX با socket-type تنظیم‌شده روی unix و socket-name به مسیر فایل سوکت UNIX/LOCAL بود.

طول مسیر مشخص‌شده توسط پارامتر socket-name با حداکثر طول نام سوکت UNIX در سیستم‌عامل مدیر سیستم، یعنی اندازه فیلد sun_path در ساختار sockaddr_un منهای ۱ محدود شده است. این مقدار در سیستم‌های عامل مختلف، بین ۹۱ تا ۱۰۷ نویسه متغیر است. مقادیر معمول در Linux برابر ۱۰۷ و در FreeBSD برابر ۱۰۳ است.

برنامه Kea تنها از یک سوکت کنترلی unix در فهرست "control-sockets" پشتیبانی می‌کند.

نکته:

از Kea 2.7.9 به بعد، سوکت‌های کنترلی فقط ممکن است در دایرکتوری تعیین‌شده در حین کامپایل به عنوان "[kea-install-dir]/var/run/kea" قرار گیرند، که همچنین باید دارای مجوزهای دسترسی 0750 باشد. این مسیر ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی KEA_CONTROL_SOCKET_DIR روی مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در socket-name استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا اگر از قبل در حال اجرا باشد، یک خطای غیرقابل بازیابی را ثبت می‌کند. برای سهولت در استفاده، کافی است بخش مسیر را از socket-name حذف کنید.

ارتباط از طریق کانال کنترلی با استفاده از ساختارهای JSON انجام می‌شود. برای جزئیات بیشتر به بخش Control Channel در راهنمای توسعه‌دهندگان Kea Developer's Guide https://reports.kea.isc.org/dev_guide/d2/d96/ctrlSocket.html مراجعه کنید.

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

  • build-report <#std-isccmd-build-report>
  • config-get <#std-isccmd-config-get>
  • config-hash-get <#std-isccmd-config-hash-get>
  • config-reload <#std-isccmd-config-reload>
  • config-set <#std-isccmd-config-set>
  • config-test <#std-isccmd-config-test>
  • config-write <#std-isccmd-config-write>
  • dhcp-disable <#std-isccmd-dhcp-disable>
  • dhcp-enable <#std-isccmd-dhcp-enable>
  • interface-add <#std-isccmd-interface-add>
  • interface-list <#std-isccmd-interface-list>
  • interface-redetect <#std-isccmd-interface-redetect>
  • leases-reclaim <#std-isccmd-leases-reclaim>
  • list-commands <#std-isccmd-list-commands>
  • shutdown <#std-isccmd-shutdown>
  • status-get <#std-isccmd-status-get>
  • version-get <#std-isccmd-version-get>

همان‌طور که در Commands Supported by Both the DHCPv4 and DHCPv6 Servers <#commands-common> شرح داده شده است. علاوه بر این، از دستورهای زیر که مرتبط با آمار هستند نیز پشتیبانی می‌کند:

  • statistic-get <#std-isccmd-statistic-get>
  • statistic-reset <#std-isccmd-statistic-reset>
  • statistic-remove <#std-isccmd-statistic-remove>
  • statistic-get <#std-isccmd-statistic-get>-all
  • statistic-reset <#std-isccmd-statistic-reset>-all
  • statistic-remove <#std-isccmd-statistic-remove>-all
  • statistic-sample-age-set <#std-isccmd-statistic-sample-age-set>
  • statistic-sample-age-set <#std-isccmd-statistic-sample-age-set>-all
  • statistic-sample-count-set <#std-isccmd-statistic-sample-count-set>
  • statistic-sample-count-set <#std-isccmd-statistic-sample-count-set>-all

همان‌طور که در Commands for Manipulating Statistics <#command-stats> شرح داده شده است..SS سوکت کنترل HTTP/HTTPS (HTTP/HTTPS Control Socket)

مقدار socket-type باید http یا https باشد (هنگامی که نوع https باشد، TLS الزامی است). پارامترهای socket-address (پیش‌فرض 127.0.0.1) و socket-port (پیش‌فرض 8000) نشانی IP و درگاهی را مشخص می‌کنند که سرویس HTTP به آن مقید (bound) خواهد شد.

از Kea 2.7.5 به بعد، پارامتر http-headers فهرستی از سرآیندهای اضافی HTTP را برای افزودن به پاسخ‌های HTTP مشخص می‌کند.

پارامترهای trust-anchor، cert-file، key-file و cert-required راه‌اندازی TLS را برای HTTP، یعنی HTTPS، مشخص می‌کنند. اگر این پارامترها مشخص نشوند، HTTP استفاده می‌شود. پشتیبانی از TLS/HTTPS در Kea در TLS/HTTPS Support <#tls> شرح داده شده است.

احراز هویت پایه HTTP (Basic HTTP authentication) در برابر استفاده‌های غیرمجاز از سرور توسط کاربران محلی محافظت می‌کند. برای محافظت در برابر مهاجمان از راه دور، HTTPS و reverse proxy امنیت قوی‌تری را فراهم می‌سازند.

احراز هویت در بلوک authentication همراه با پارامتر اجباری type که نوع احراز هویت را انتخاب می‌کند، شرح داده شده است. در حال حاضر تنها احراز هویت پایه HTTP (نوع basic) پشتیبانی می‌شود.

پارامتر احراز هویت realm (پیش‌فرض kea-dhcpv4-server) برای پیام‌های خطا در شرایطی که احراز هویت پایه HTTP الزامی است اما کلاینت مجاز شناخته نشده، استفاده می‌شود.

هنگامی که فهرست احراز هویت clients پیکربندی شده و خالی نباشد، احراز هویت پایه HTTP الزامی است. هر عنصر از فهرست یک شناسه کاربر و یک گذرواژه را مشخص می‌کند. شناسه کاربر اجباری است، نباید خالی باشد، و نباید حاوی نویسه دونقطه (:) باشد. گذرواژه اختیاری است؛ هنگامی که مشخص نشود، یک گذرواژه خالی استفاده می‌شود.

نکته:

شناسه کاربر و گذرواژه احراز هویت پایه HTTP با کدگذاری UTF-8 کدگذاری می‌شوند، اما نحو JSON فعلی Kea تنها از زیرمجموعه یونیکد Latin-1 (یعنی 0x00..0xff) پشتیبانی می‌کند.

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

  • پارامتر احراز هویت directory، که بخش مشترک مسیرهای فایل را مدیریت می‌کند. مقدار پیش‌فرض یک رشته خالی است.
  • پارامتر کلاینت password-file، که در کنار پارامتر directory، مسیر فایلی را مشخص می‌کند که می‌تواند حاوی گذرواژه باشد، یا در صورتی که شناسه کاربر ارائه نشده باشد، کل عبارت محرمانه احراز هویت پایه HTTP را در بر گیرد.
  • پارامتر کلاینت user-file، که همراه با پارامتر directory، مسیر فایلی را مشخص می‌کند که شناسه کاربر می‌تواند از آن خوانده شود.

از نسخه Kea-2.7.6 به بعد، Kea از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هر دو نشانی IPv4 و IPv6 می‌توانند استفاده شوند. سرور در صورت تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از همان نشانی و درگاه، خطا صادر خواهد کرد. این عمل مجاز نیست زیرا ممکن است موجب بروز یک مشکل امنیتی ناشی از اشتباه تصادفی کاربر شود. هنگام استفاده از دستور "config-set" برای تغییر از HTTP به HTTPS یا از HTTPS به HTTP، باید یک نشانی یا درگاه متفاوت مشخص شود. همین موضوع هنگام تغییر فایل پیکربندی و سپس اجرای دستور "config-reload" نیز صدق می‌کند.

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

"Dhcp4": {
    "control-sockets": [
        {
            "socket-type": "https",
            "socket-address": "10.20.30.40",
            "socket-port": 8004,
            "http-headers": [
                {
                    "name": "Strict-Transport-Security",
                    "value": "max-age=31536000"
                 }
            ],
            "trust-anchor": "/path/to/the/ca-cert.pem",
            "cert-file": "/path/to/the/agent-cert.pem",
            "key-file": "/path/to/the/agent-key.pem",
            "cert-required": true,
            "authentication": {
                "type": "basic",
                "realm": "kea-dhcpv4-server",
                "clients": [
                {
                    "user": "admin",
                    "password": "1234"
                } ]
            }
        },
        {
            "socket-type": "http",
            "socket-address": "2010:30:40::50",
            "socket-port": 8004
        }
    ],
    "subnet4": [
        {
            ...
        },
        ...
    ],
    ...
}

‏Kea امکان بارگذاری کتابخانه‌های قلاب (hook libraries) را فراهم می‌کند که گاهی می‌توانند از پارامترهای اضافی بهره‌مند شوند. اگر چنین پارامتری مختص به کل کتابخانه باشد، معمولاً به عنوان پارامتری برای کتابخانه قلاب تعریف می‌شود. با این حال، گاهی اوقات لازم است پارامترهایی مشخص شوند که برای هر استخر (pool) متفاوت باشند.

برای پیش‌زمینه تکمیلی در مورد ایده user-context، بخش Comments and User Context <#user-context> را ببینید. برای بررسی از دیدگاه قلاب‌ها، بخش User Contexts in Hooks <#user-context-hooks> را مشاهده کنید.

زمینه‌های کاربر (User contexts) را می‌توان در محدوده سراسری (global scope)؛ در سطح shared-network، subnet، pool، client-class، option-data یا تعاریف (definition)؛ و از طریق رزرو میزبان (host reservation) مشخص کرد. یکی دیگر از ویژگی‌های مفید، قابلیت ذخیره نظرات یا توضیحات است.

بیایید حالت فرضی دستگاه‌هایی را در نظر بگیریم که چراغ‌های LED رنگی دارند. بسته به مکان قرارگیری، آن‌ها باید با نور قرمز، آبی یا سبز روشن شوند. نوشتن یک کتابخانه قلاب که مقادیر مشخصی را، احتمالاً به عنوان یک گزینه فروشنده (vendor option)، ارسال کند کار آسانی خواهد بود. با این حال، سرور باید راهی برای تعیین آن مقدار برای هر pool داشته باشد. این نیاز توسط زمینه‌های کاربر (user contexts) برطرف می‌شود. در اصل، هر داده کاربری می‌تواند در زمینه کاربر مشخص شود تا زمانی که یک نگاشت معتبر JSON باشد. برای مثال، مورد دستگاه‌های LED یادشده می‌تواند به روش زیر پیکربندی شود:

"Dhcp4": {
    "subnet4": [
        {
        "id": 1,
        "subnet": "192.0.2.0/24",
        "pools": [
        {
            "pool": "192.0.2.10 - 192.0.2.20",
            # This is pool specific user context
            "user-context": { "color": "red" }
        }
        ],
        # This is a subnet-specific user context. Any type
        # of information can be entered here as long as it is valid JSON.
        "user-context": {
            "comment": "network on the second floor",
            "last-modified": "2017-09-04 13:32",
            "description": "you can put anything you like here",
            "phones": [ "x1234", "x2345" ],
            "devices-registered": 42,
            "billing": false
        }
    }
    ]
}

‏Kea اطلاعات user-context را تفسیر یا استفاده نمی‌کند؛ صرفاً آن را ذخیره می‌کند و در دسترس کتابخانه‌های قلاب قرار می‌دهد. استخراج این اطلاعات و استفاده از آن به عهده هر کتابخانه قلاب است. تجزیه‌کننده یک مدخل comment را به یک زمینه کاربر همراه با آن مدخل ترجمه می‌کند که امکان ضمیمه کردن یک نظر را در داخل خود پیکربندی فراهم می‌سازد..SS استانداردهای پشتیبانی‌شده DHCP (Supported DHCP Standards)

استانداردهای زیر در حال حاضر در Kea پشتیبانی می‌شوند:

  • BOOTP Vendor Information Extensions، RFC 1497 https://datatracker.ietf.org/doc/html/rfc1497: این مورد نیازمند بارگذاری قلاب (hook) متن‌باز BOOTP است. برای جزئیات libdhcp_bootp.so: Support for BOOTP Clients <#hooks-bootp> را ببینید.
  • Dynamic Host Configuration Protocol، RFC 1531 https://datatracker.ietf.org/doc/html/rfc1531: این RFC منسوخ شده و با RFC 1541 جایگزین شده است که آن هم به نوبه خود با RFC 2131 جایگزین شد. Kea از هر سه RFC پشتیبانی می‌کند.
  • Clarifications and Extensions for the Bootstrap Protocol، RFC 1532 https://datatracker.ietf.org/doc/html/rfc1532: این RFC خطای نگارشی دارد و به‌سرعت توسط RFC 1542 جایگزین شد. Kea از هر دوی آن‌ها پشتیبانی می‌کند.
  • DHCP Options and BOOTP Vendor Extensions، RFC 1533 https://datatracker.ietf.org/doc/html/rfc1533: این RFC منسوخ شده و با RFC 2132 جایگزین شد. با این وجود، Kea از گزینه‌های تعریف‌شده در آن پشتیبانی می‌کند.
  • Dynamic Host Configuration Protocol، RFC 1541 https://datatracker.ietf.org/doc/html/rfc1541: این RFC منسوخ شده و با RFC 2131 جایگزین شد. Kea از هر دو پشتیبانی می‌کند.
  • Clarifications and Extensions for the Bootstrap Protocol، RFC 1542 https://datatracker.ietf.org/doc/html/rfc1542: این RFC پشتیبانی می‌شود.
  • Dynamic Host Configuration Protocol، RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131: پیام‌های پشتیبانی‌شده عبارتند از DHCPDISCOVER (1)، DHCPOFFER (2)، DHCPREQUEST (3)، DHCPRELEASE (7)، DHCPINFORM (8)، DHCPACK (5) و DHCPNAK (6).
  • DHCP Options and BOOTP Vendor Extensions، RFC 2132 https://datatracker.ietf.org/doc/html/rfc2132: گزینه‌های پشتیبانی‌شده عبارتند از PAD (0)، END (255)، Message Type (53)، DHCP Server Identifier (54)، Domain Name (15)، DNS Servers (6)، IP Address Lease Time (51)، Subnet Mask (1) و Routers (3).
  • DHCP Options for Novell Directory Services، RFC 2241 https://datatracker.ietf.org/doc/html/rfc2241: هر سه گزینه پشتیبانی می‌شوند.
  • Management of IP numbers by peg-dhcp، RFC 2322 https://datatracker.ietf.org/doc/html/rfc2322: این RFC پشتیبانی می‌شود، اگرچه برای استقرار کامل به سخت‌افزار اضافی نیاز است.
  • DHCP Option for The Open Group's User Authentication Protocol، RFC 2485 https://datatracker.ietf.org/doc/html/rfc2485: این گزینه پشتیبانی می‌شود.
  • DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients، RFC 2563 https://datatracker.ietf.org/doc/html/rfc2563: این گزینه پشتیبانی می‌شود.
  • DHCP Options for Service Location Protocol، RFC 2610 https://datatracker.ietf.org/doc/html/rfc2610: هر دو گزینه پشتیبانی می‌شوند.
  • The Name Service Search Option for DHCP، RFC 2937 https://datatracker.ietf.org/doc/html/rfc2937: این گزینه پشتیبانی می‌شود.
  • The User Class Option for DHCP، RFC 3004 https://datatracker.ietf.org/doc/html/rfc3004: کلاس کاربر پشتیبانی می‌شود و می‌تواند در هر عبارتی استفاده شود. ساختار گزینه تجزیه نمی‌شود و باید با استفاده از hex به آن ارجاع داده شود.
  • The IPv4 Subnet Selection Option for DHCP، RFC 3011 https://datatracker.ietf.org/doc/html/rfc3011: گزینه subnet-selection پشتیبانی می‌شود؛ در صورت دریافت در یک بسته، در فرایند انتخاب زیرشبکه استفاده می‌گردد.
  • DHCP Relay Agent Information Option، RFC 3046 https://datatracker.ietf.org/doc/html/rfc3046: گزینه‌های Relay Agent Information، Circuit ID و Remote ID پشتیبانی می‌شوند.
  • The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option، RFC 3256 https://datatracker.ietf.org/doc/html/rfc3256: زیرگزینه DOCSIS پشتیبانی می‌شود و می‌تواند در هر عبارتی استفاده شود.
  • Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)، RFC 3396 https://datatracker.ietf.org/doc/html/rfc3396: کارساز Kea می‌تواند هم گزینه‌های طولانی را دریافت و هم ارسال کند. گزینه‌های طولانی قابل پیکربندی هستند و اگر طول بار داده (payload) بیشتر از ۲۵۵ بایت باشد، Kea آن‌ها را به صورت نمونه‌های جداگانه ارسال می‌کند.
  • Dynamic Host Configuration Protocol (DHCP) Domain Search Option، RFC 3397 https://datatracker.ietf.org/doc/html/rfc3397: این گزینه پشتیبانی می‌شود.
  • The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4، RFC 3442 https://datatracker.ietf.org/doc/html/rfc3442: این گزینه پشتیبانی می‌شود.
  • Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration، RFC 3495 https://datatracker.ietf.org/doc/html/rfc3495: این گزینه و زیرگزینه‌های ۱، ۲، ۴، ۵، ۶، ۷ و ۸ آن پشتیبانی می‌شوند. برای جزئیات به بخش CableLabs Client Conf Suboptions مراجعه کنید.
  • Link Selection sub-option for the Relay Agent Option، RFC 3527 https://datatracker.ietf.org/doc/html/rfc3527: زیرگزینه link selection پشتیبانی می‌شود.
  • PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option، RFC 3594 https://datatracker.ietf.org/doc/html/rfc3594: زیرگزینه Security Ticket Control پشتیبانی می‌شود.
  • Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option، RFC 3634 https://datatracker.ietf.org/doc/html/rfc3634: زیرگزینه نشانی IP مربوط به Key Distribution Center پشتیبانی می‌شود.
  • Unused Dynamic Host Configuration Protocol (DHCP) Option Codes، RFC 3679 https://datatracker.ietf.org/doc/html/rfc3679: Kea از هیچ‌یک از گزینه‌های قدیمی که توسط این RFC منسوخ شده‌اند پشتیبانی نمی‌کند.
  • Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4، RFC 3925 https://datatracker.ietf.org/doc/html/rfc3925: گزینه‌های Vendor-Identifying Vendor Class و Vendor-Identifying Vendor-Specific Information پشتیبانی می‌شوند.
  • Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options، RFC 3942 https://datatracker.ietf.org/doc/html/rfc3942: Kea از گزینه‌هایی با کدهای بزرگتر از ۱۲۷ پشتیبانی می‌کند.
  • Subscriber-ID Suboption for the DHCP Relay Agent Option، RFC 3993 https://datatracker.ietf.org/doc/html/rfc3993: گزینه Subscriber-ID پشتیبانی می‌شود.
  • Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers، RFC 4280 https://datatracker.ietf.org/doc/html/rfc4280: گزینه‌های DHCPv4 پشتیبانی می‌شوند.
  • Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)، RFC 4361 https://datatracker.ietf.org/doc/html/rfc4361: شناسه DUID در DHCPv4 پشتیبانی می‌شود.
  • Dynamic Host Configuration Protocol (DHCP) Leasequery، RFC 4388 https://datatracker.ietf.org/doc/html/rfc4388: قابلیت‌های کارساز پشتیبانی می‌شود. این مورد نیازمند قلاب leasequery است. برای جزئیات libdhcp_lease_query.so: Leasequery Support <#hooks-lease-query> را ببینید.
  • Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)، RFC 4578 https://datatracker.ietf.org/doc/html/rfc4578: هر سه گزینه تعریف‌شده پشتیبانی می‌شوند.
  • A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)، RFC 4701 https://datatracker.ietf.org/doc/html/rfc4701: کارساز DHCPv4 از رکوردهای DHCID پشتیبانی می‌کند. کارساز DHCP-DDNS باید در حال اجرا باشد تا رکوردهای DHCID را اضافه، به‌روزرسانی و/یا حذف کند.
  • The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option، RFC 4702 https://datatracker.ietf.org/doc/html/rfc4702: کارساز Kea قادر به مدیریت گزینه Client FQDN است. همچنین می‌تواند از مؤلفه kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> برای آغاز عملیات مناسب به‌روزرسانی DNS استفاده کند.
  • Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients، RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703: کارساز DHCPv6 از یک کارساز DHCP-DDNS برای حل تعارض‌ها استفاده می‌کند.
  • Timezone Options for DHCP: RFC 4833 https://datatracker.ietf.org/doc/html/rfc4833: هر دو گزینه DHCPv4 پشتیبانی می‌شوند.
  • The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption: RFC 5010 https://datatracker.ietf.org/doc/html/rfc5010: زیرگزینه Relay Agent Flags برای Kea مفهوم است و می‌تواند در عبارات استفاده شود.
  • Server Identifier Override sub-option for the Relay Agent Option، RFC 5107 https://datatracker.ietf.org/doc/html/rfc5107: زیرگزینه server identifier override پشتیبانی می‌شود. پیاده‌سازی طبق RFC کامل نیست، زیرا کارساز RAI را ذخیره نمی‌کند، اما این کارکرد موارد کاربرد مورد انتظار را پوشش می‌دهد.
  • DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents: RFC 5192 https://datatracker.ietf.org/doc/html/rfc5192: گزینه PANA پشتیبانی می‌شود.
  • Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP): RFC 5223 https://datatracker.ietf.org/doc/html/rfc5223: گزینه LOST پشتیبانی می‌شود.
  • Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option: RFC 5417 https://datatracker.ietf.org/doc/html/rfc5417: گزینه CAPWAP برای IPv4 پشتیبانی می‌شود.
  • DHCPv4 Lease Query by Relay Agent Remote ID، RFC 6148 https://datatracker.ietf.org/doc/html/rfc6148: درخواست leasequery بر اساس remote-id پشتیبانی می‌شود. این مورد نیازمند قلاب leasequery است. برای جزئیات libdhcp_lease_query.so: Leasequery Support <#hooks-lease-query> را ببینید.
  • Client Identifier Option in DHCP Server Replies، RFC 6842 https://datatracker.ietf.org/doc/html/rfc6842: کارساز به صورت پیش‌فرض گزینه client-id را بازمی‌گرداند. این قابلیت می‌تواند غیرفعال شود. برای جزئیات Echoing Client-ID (RFC 6842) را ببینید.
  • The DHCPv4 Relay Agent Identifier Sub-Option، RFC 6925 https://datatracker.ietf.org/doc/html/rfc6925: گزینه relay-id پشتیبانی می‌شود و می‌تواند در تمام ویژگی‌هایی که از عبارات استفاده می‌کنند (دسته‌بندی کلاینت، رزروهای flex-id و غیره) به کار رود.
  • DHCPv4 Bulk Leasequery، RFC 6926 https://datatracker.ietf.org/doc/html/rfc6926: کارکرد کارساز (اتصال‌های TCP، انواع پرس‌وجو جدید، پاسخ‌های چندگانه و غیره) پشتیبانی می‌شود. این مورد نیازمند قلاب leasequery است. برای جزئیات libdhcp_lease_query.so: Leasequery Support <#hooks-lease-query> را ببینید.
  • Generalized UDP Source Port for the DHCP Relay Agent Option، RFC 8357 https://datatracker.ietf.org/doc/html/rfc8357: کارساز Kea زیرگزینه Relay Agent Information Source Port را در پیام دریافت‌شده پردازش می‌کند، درگاه UDP را به خاطر می‌سپارد، و پاسخی را با استفاده از این درگاه UDP برای همان عامل رله بازمی‌فرستد.
  • Captive-Portal Identification in DHCP and Router Advertisements (RAs)، RFC 8910 https://datatracker.ietf.org/doc/html/rfc8910: کارساز Kea می‌تواند هر دو نسخه v4 و v6 گزینه‌های پرتال محدودکننده (captive portal) را پیکربندی کند.
  • IPv6-Only Preferred Option for DHCPv4، RFC 8925 https://datatracker.ietf.org/doc/html/rfc8925: کارساز Kea قادر است استخرها و زیرشبکه‌های خود را به عنوان IPv6-Only Preferred تعیین کرده و گزینه v6-only-preferred را برای کلاینت‌هایی که آن را درخواست کرده‌اند بازپس فرستد.
  • DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)، RFC 9463 https://datatracker.ietf.org/doc/html/rfc9463. کارساز Kea از گزینه DNR پشتیبانی می‌کند.

    در اصل، Kea در پی آن است که یک پیاده‌سازی مرجع باشد و هدف آن پیاده‌سازی ۱۰۰٪ استانداردهای RFC است. با این حال، در برخی موارد جنبه‌های عملی وجود دارند که مانع از پایبندی کامل Kea به متن تمام اسناد RFC می‌شوند.

  • سند RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131، صفحهٔ ۳۰، بیان می‌کند که اگر بستهٔ ورودی DHCPREQUEST فاقد گزینهٔ "requested IP address" باشد و ciaddr نیز تنظیم نشده باشد، کارساز باید با NAK پاسخ دهد. با این حال، کلاینت‌های معیوبی وجود دارند که همواره یک DHCPREQUEST را بدون مشخص کردن این گزینه‌ها ارسال می‌کنند. در این حالت، Kea بستهٔ DHCPREQUEST را می‌پذیرد، نشانی‌ای را اختصاص می‌دهد، و با یک ACK پاسخ می‌دهد.
  • سند RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131، جدول ۵، بیان می‌کند که پیام‌های از نوع DHCPDECLINE یا DHCPRELEASE باید گزینهٔ شناسهٔ کارساز (server identifier) را تنظیم کرده باشند و در صورت نبود این گزینه باید رها (drop) شوند. با این حال، ISC DHCP این موضوع را اعمال نمی‌کند، که احتمالاً تلاشی در جهت سازگاری با کلاینت‌های معیوب است، و تیم Kea نیز تصمیم گرفت همین رویه را دنبال کند.

این موارد محدودیت‌های شناخته‌شدهٔ کنونی نرم‌افزار کارساز Kea DHCPv4 هستند. بیشتر آن‌ها بازتابی از مرحلهٔ فعلی توسعه هستند و باید به جای محدودیت‌های واقعی، به عنوان «هنوز پیاده‌سازی‌نشده» تلقی شوند. با این وجود، برخی از آن‌ها از پیامدهای تصمیمات اتخاذشده در طراحی هستند. این موارد به‌روشنی به همین صورت مشخص شده‌اند.

•
در خانوادهٔ سیستم‌های Linux و BSD، پیام‌های DHCP از طریق سوکت‌های خام (با استفاده از LPF و BPF) ارسال و دریافت می‌شوند و تمام سرآیندهای بسته (از جمله سرآیندهای لایهٔ پیوند داده، IP و UDP) به جای هستهٔ سیستم، توسط Kea ایجاد و تجزیه می‌شوند. در حال حاضر، Kea فقط می‌تواند سرآیندهای لایهٔ پیوند داده با قالبی مطابق با استاندارد IEEE 802.3 را تجزیه کند، و این قالب سرآیند لایهٔ پیوند داده را برای تمامی رابط‌ها فرض می‌گیرد. بنابراین، Kea روی رابط‌هایی که از قالب‌های سرآیند لایهٔ پیوند دادهٔ متفاوتی استفاده می‌کنند (مانند Infiniband) کار نمی‌کند.

مجموعه‌ای از مثال‌های ساده و کاربردی برای مؤلفهٔ DHCPv4 در Kea همراه با فایل‌های منبع، در دایرکتوری doc/examples/kea4 در دسترس است.

در بخش پسانهٔ پیکربندی Kea <#config-backend>، قابلیت پسانهٔ پیکربندی (CB)، کاربردپذیری و محدودیت‌های آن را شرح داده‌ایم. این بخش بر استفاده از CB به همراه کارساز Kea DHCPv4 متمرکز است. این قسمت پارامترهای پشتیبانی‌شده را فهرست می‌کند، محدودیت‌ها را توضیح می‌دهد و مثال‌هایی از پیکربندی کارساز DHCPv4 برای بهره‌برداری از CB ارائه می‌دهد. لطفاً برای استفادهٔ مخصوص DHCPv6 از CB، به بخش متناظر پسانهٔ پیکربندی در DHCPv6 <#dhcp6-cb> نیز مراجعه کنید.

هدف نهایی CB این است که به عنوان یک مخزن مرکزی پیکربندی برای یک یا چند کارساز Kea متصل به یک پایگاه‌داده عمل کند. در نسخه‌های کنونیِ پشتیبانی‌شدهٔ Kea، تنها زیرمجموعه‌ای از پارامترهای کارساز DHCPv4 را می‌توان در پایگاه‌داده پیکربندی کرد. سایر پارامترها در صورت نیاز باید در فایل پیکربندی JSON مشخص شوند.

تمامی پارامترهای پشتیبانی‌شده را می‌توان از طریق libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> پیکربندی کرد. قاعدهٔ کلی بر این است که پارامترهای سراسری نردبانی با استفاده از remote-global-parameter4-set <#std-isccmd-remote-global-parameter4-set> تنظیم می‌شوند؛ پارامترهای مختص شبکهٔ مشترک با استفاده از remote-network4-set <#std-isccmd-remote-network4-set> تعیین می‌گردند؛ و پارامترهای سطح زیرشبکه و سطح استخر با استفاده از remote-subnet4-set <#std-isccmd-remote-subnet4-set> تنظیم می‌شوند. هرگاه استثنایی بر این قاعدهٔ کلی وجود داشته باشد، در جدول برجسته شده است. پارامترهای سراسری غیرنردبانی دارای دستورات اختصاصی هستند؛ برای مثال، گزینه‌های سراسری DHCPv4 (option-data) با استفاده از remote-option4-global-set <#std-isccmd-remote-option4-global-set> تغییر می‌یابند. کلاس‌های کلاینت به همراه تعاریف گزینه‌ها و گزینه‌های DHCPv4 مختص به آن کلاس، با استفاده از دستور remote-class4-set <#std-isccmd-remote-class4-set> پیکربندی می‌شوند.

بخش اشتراک‌گذاری پیکربندی و برچسب‌های کارساز <#cb-sharing> مفهوم عناصر پیکربندی قابل‌اشتراک و غیرقابل‌اشتراک و محدودیت‌های به‌اشتراک‌گذاری آن‌ها میان چند کارساز را توضیح می‌دهد. در پیکربندی DHCP (چه DHCPv4 و چه DHCPv6)، عناصر پیکربندی قابل‌اشتراک شامل زیرشبکه‌ها و شبکه‌های مشترک هستند. بنابراین، می‌توان آن‌ها را به‌طور صریح با چند برچسب کارساز مرتبط کرد. پارامترهای سراسری، تعاریف گزینه‌ها و گزینه‌های سراسری غیرقابل‌اشتراک هستند و تنها می‌توانند با یک برچسب کارساز مرتبط باشند. این قاعده شامل عناصر پیکربندیِ مرتبط با کارسازهای all نمی‌شود. هر عنصر پیکربندی مرتبط با کارسازهای all (با استفاده از کلمهٔ کلیدی all به عنوان برچسب کارساز) توسط تمام کارسازهایی که به پایگاه‌دادهٔ پیکربندی متصل می‌شوند، استفاده می‌شود.

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

پارامتر سراسری کلاس کلاینت شبکهٔ مشترک زیرشبکه استخر
4o6-interface n/a n/a n/a بله n/a
4o6-interface-id n/a n/a n/a بله n/a
4o6-subnet n/a n/a n/a بله n/a
allocator بله n/a بله بله n/a
boot-file-name بله بله بله بله n/a
cache-max-age بله n/a خیر خیر n/a
cache-threshold بله n/a خیر خیر n/a
calculate-tee-times بله n/a بله بله n/a
client-class n/a n/a بله بله بله
ddns-send-update بله n/a بله بله n/a
ddns-override-no-update بله n/a بله بله n/a
ddns-override-client-update بله n/a بله بله n/a
ddns-replace-client-name بله n/a بله بله n/a
ddns-generated-prefix بله n/a بله بله n/a
ddns-qualifying-suffix بله n/a بله بله n/a
decline-probation-period بله n/a n/a n/a n/a
dhcp4o6-port بله n/a n/a n/a n/a
echo-client-id بله n/a n/a n/a n/a
hostname-char-set بله n/a بله بله n/a
hostname-char-replacement بله n/a بله بله n/a
interface n/a n/a بله بله n/a
match-client-id بله n/a بله بله n/a
min-valid-lifetime بله بله بله بله n/a
max-valid-lifetime بله بله بله بله n/a
next-server بله بله بله بله n/a
option-data بله (از طریق remote-option4-global-set) بله بله بله بله
option-def بله (از طریق remote-option-def4-set) بله n/a n/a n/a
rebind-timer بله n/a بله بله n/a
renew-timer بله n/a بله بله n/a
server-hostname بله بله بله بله n/a
valid-lifetime بله بله بله بله n/a
relay n/a n/a بله بله n/a
require-client-classes خیر n/a بله بله بله
evaluate-additional-classes خیر n/a بله بله بله
reservations-global بله n/a بله بله n/a
reservations-in-subnet بله n/a بله بله n/a
reservations-out-of-pool بله n/a بله بله n/a
t1-percent بله n/a بله بله n/a
t2-percent بله n/a بله بله n/a
yes - نشان می‌دهد که این پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود و از طریق بک‌اند پیکربندی قابل تنظیم است.
  • no - نشان می‌دهد که یک پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود، اما از طریق بک‌اند پیکربندی قابل تنظیم نیست.
  • n/a - نشان می‌دهد که پارامتر مربوطه در سطح مشخص‌شده از سلسله‌مراتب قابل اعمال نیست یا سرور از آن پارامتر در آن سطح پشتیبانی نمی‌کند.

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

نام پارامتر (قالب نام‌گذاری مسطح) نگاشت سراسری نام پارامتر
compatibility.ignore-dhcp-server-identifier compatibility ignore-dhcp-server-identifier
compatibility.ignore-rai-link-selection compatibility ignore-rai-link-selection
compatibility.lenient-option-parsing compatibility lenient-option-parsing
compatibility.exclude-first-last-24 compatibility exclude-first-last-24
dhcp-ddns.enable-updates dhcp-ddns enable-updates
dhcp-ddns.max-queue-size dhcp-ddns max-queue-size
dhcp-ddns.ncr-format dhcp-ddns ncr-format
dhcp-ddns.ncr-protocol dhcp-ddns ncr-protocol
dhcp-ddns.sender-ip dhcp-ddns sender-ip
dhcp-ddns.sender-port dhcp-ddns sender-port
dhcp-ddns.server-ip dhcp-ddns server-ip
dhcp-ddns.server-port dhcp-ddns server-port
expired-leases-processing.flush-reclaimed-timer-wait-time expired-leases-processing flush-reclaimed-timer-wait-time
expired-leases-processing.hold-reclaimed-time expired-leases-processing hold-reclaimed-time
expired-leases-processing.max-reclaim-leases expired-leases-processing max-reclaim-leases
expired-leases-processing.max-reclaim-time expired-leases-processing max-reclaim-time
expired-leases-processing.reclaim-timer-wait-time expired-leases-processing reclaim-timer-wait-time
expired-leases-processing.unwarned-reclaim-cycles expired-leases-processing unwarned-reclaim-cycles
multi-threading.enable-multi-threading multi-threading enable-multi-threading
multi-threading.thread-pool-size multi-threading thread-pool-size
multi-threading.packet-queue-size multi-threading packet-queue-size
sanity-checks.lease-checks sanity-checks lease-checks
sanity-checks.extended-info-checks sanity-checks extended-info-checks
dhcp-queue-control.enable-queue dhcp-queue-control enable-queue
dhcp-queue-control.queue-type dhcp-queue-control queue-type
dhcp-queue-control.capacity dhcp-queue-control capacity

برخی از پارامترهای فهرست سراسری که تنها حاوی انواع اسکالر هستند، توسط بک‌اند پیکربندی پشتیبانی می‌شوند..SS فهرست پارامترهای فهرستی DHCPv4 پشتیبانی‌شده توسط بک‌اند پیکربندی

نام پارامتر | نوع پارامتر نگه‌دارندهٔ فهرست
host-reservation-identifiers | string

قطعه‌پیکربندی زیر را در نظر بگیرید که از یک پایگاه‌دادهٔ پیکربندی MySQL استفاده می‌کند:

{
    "Dhcp4": {
        "server-tag": "my DHCPv4 server",
        "config-control": {
            "config-databases": [
                {
                    "type": "mysql",
                    "name": "kea",
                    "user": "kea",
                    "password": "1234",
                    "host": "192.0.2.1",
                    "port": 3302
                }
            ],
            "config-fetch-wait-time": 20
        },
        "hooks-libraries": [
            {
                "library": "libdhcp_mysql.so"
            },
            {
                "library": "libdhcp_cb_cmds.so"
            }
        ]
    }
}

قطعه‌کد زیر استفاده از یک پایگاه‌دادهٔ PostgreSQL را نشان می‌دهد:

{
    "Dhcp4": {
        "server-tag": "my DHCPv4 server",
        "config-control": {
            "config-databases": [
                {
                    "type": "postgresql",
                    "name": "kea",
                    "user": "kea",
                    "password": "1234",
                    "host": "192.0.2.1",
                    "port": 3302
                }
            ],
            "config-fetch-wait-time": 20
        },
        "hooks-libraries": [
            {
                "library": "libdhcp_pgsql.so"
            },
            {
                "library": "libdhcp_cb_cmds.so"
            }
        ]
    }
}

نگاشت config-control شامل دو پارامتر است. config-databases فهرستی حاوی یک عنصر است که نوع پایگاه‌داده، مکان آن و اطلاعات هویتی مورد استفاده برای اتصال به این پایگاه‌داده را شامل می‌شود. (توجه داشته باشید پارامترهایی که در اینجا مشخص شده‌اند، با مشخصات پایگاه‌داده برای بک‌اند پایگاه‌دادهٔ اجاره (lease) و بک‌اند پایگاه‌دادهٔ میزبان‌ها مطابقت دارند.) در حال حاضر تنها یک اتصال پایگاه‌داده را می‌توان در فهرست config-databases مشخص کرد. سرور در طول راه‌اندازی یا پیکربندی مجدد به این پایگاه‌داده متصل می‌شود و پیکربندی موجود برای این سرور را از پایگاه‌داده واکشی می‌کند. این پیکربندی در پیکربندی خوانده‌شده از فایل پیکربندی ادغام می‌شود.

نکته:

هر زمان که تعارضی بین پارامترهای مشخص‌شده در فایل پیکربندی و پایگاه‌داده وجود داشته باشد، پارامترهای پایگاه‌داده اولویت دارند. ما اکیداً توصیه می‌کنیم از تکرار پارامترها در فایل و پایگاه‌داده خودداری کنید، اما این توصیه توسط سرورهای Kea اجبار نمی‌شود. به‌ویژه، اگر پیکربندی زیرشبکه‌ها از پایگاه‌داده تأمین می‌شود، توصیه می‌کنیم تمام زیرشبکه‌ها در پایگاه‌داده مشخص شوند و هیچ زیرشبکه‌ای در فایل پیکربندی مشخص نشود. امکان تعیین زیرشبکه‌ها در هر دو مکان وجود دارد، اما زیرشبکه‌های موجود در فایل پیکربندی که دارای شناسه‌ها (IDs) و/یا پیشوندهای هم‌پوشان با زیرشبکه‌های پایگاه‌داده باشند، توسط موارد موجود در پایگاه‌داده جایگزین خواهند شد.

پس از پیکربندی سرور Kea، این سرور به‌صورت دوره‌ای پایگاه‌داده را برای بررسی تغییرات پیکربندی وارسی (poll) می‌کند. بسامد وارسی توسط پارامتر config-fetch-wait-time بر حسب ثانیه کنترل می‌شود؛ این مقدار فاصلهٔ زمانی بین لحظه‌ای است که سرور آخرین وارسی خود (و احتمالاً به‌روزرسانی پیکربندی محلی) را به پایان رسانده و زمانی است که وارسی مجدد را آغاز خواهد کرد. در مثال بالا، این دوره روی ۲۰ ثانیه تنظیم شده است. این بدان معناست که پس از افزودن یک پیکربندی جدید به پایگاه‌داده (مثلاً افزودن یک زیرشبکهٔ جدید)، تا ۲۰ ثانیه (به‌علاوهٔ زمان مورد نیاز برای واکشی و اعمال پیکربندی جدید) طول می‌کشد تا سرور شروع به استفاده از این زیرشبکه کند. هرچه مقدار config-fetch-wait-time کمتر باشد، زمان واکنش سرور به به‌روزرسانی‌های افزایشی پیکربندی در پایگاه‌داده کوتاه‌تر خواهد بود. از سوی دیگر، وارسی بیش از حد پایگاه‌داده ممکن است بر عملکرد سرور DHCP تأثیر بگذارد، زیرا سرور باید حداقل یک پرس‌وجو به پایگاه‌داده ارسال کند تا هرگونه به‌روزرسانی معلق پیکربندی را کشف کند. مقدار پیش‌فرض config-fetch-wait-time برابر با ۳۰ ثانیه است.

دستور config-backend-pull <#std-isccmd-config-backend-pull> می‌تواند برای وادار کردن سرور به وارسی فوری هرگونه تغییر پیکربندی از پایگاه‌داده و جلوگیری از انتظار برای چرخهٔ واکشی بعدی استفاده شود.

در مثال‌های پیکربندی بالا، دو کتابخانهٔ قلاب (hook library) بارگذاری شده‌اند. نخستین مورد کتابخانه‌ای است که بک‌اند پیکربندی را برای یک نوع پایگاه‌دادهٔ خاص پیاده‌سازی می‌کند: libdhcp_mysql.so <#std-ischooklib-libdhcp_mysql.so> پشتیبانی از MySQL را ارائه می‌دهد و libdhcp_pgsql.so <#std-ischooklib-libdhcp_pgsql.so> پشتیبانی از PostgreSQL را فراهم می‌کند. کتابخانهٔ بارگذاری‌شده باید با type پایگاه‌داده که در پارامتر config-control مشخص شده مطابقت داشته باشد؛ در غیر این صورت هنگامی که سرور تلاش می‌کند پیکربندی خود را بارگذاری کند، یک خطا ثبت شده و بارگذاری با شکست مواجه می‌شود.

کتابخانهٔ قلاب دوم، libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so>، اختیاری است. این کتابخانه زمانی باید بارگذاری شود که قرار است از نمونهٔ سرور Kea برای مدیریت پیکربندی در پایگاه‌داده استفاده شود. برای جزئیات بیشتر به بخش libdhcp_cb_cmds.so: Configuration Backend Commands <#hooks-cb-cmds> مراجعه کنید..SS پارامترهای پیکربندی سازگاری Kea DHCPv4

هدف ISC این است که Kea اسناد RFC را برای ارتقای سازگاری بهتر با استانداردها رعایت کند. با این حال، پیاده‌سازی‌های معیوب بسیاری از DHCP از قبل وجود دارند که نمی‌توان آن‌ها را به‌راحتی برطرف یا ارتقا داد. بنابراین، Kea یک حالت سازگاری با کاربرد آسان را برای کلاینت‌های خراب یا ناسازگار فراهم می‌کند. برای این منظور، گزینه سازگاری باید فعال شود تا رفتارهای غیرمعمول مجاز شمرده شوند:

{
  "Dhcp4": {
    "compatibility": {
    }
  }
}

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

با "lenient-option-parsing": true، اگر یک طول از باقی‌مانده بافر گزینه فراتر می‌رفت، نسخه‌های قبلی Kea پیام لاگ unable to parse the opaque data tuple, the buffer length is x, but the tuple length is y با شرط x < y را بازمی‌گرداندند؛ این اتفاق دیگر رخ نمی‌دهد. در عوض، مقدار برابر با باقی‌مانده بافر در نظر گرفته می‌شود، یا بر اساس پیام لاگ بالا، طول چندتایی y برابر با x می‌شود.

{
  "Dhcp4": {
    "compatibility": {
      "lenient-option-parsing": true
    }
  }
}

از نسخه 2.5.8 در Kea، این تجزیه گسترش یافته است تا گزینه‌های FQDN (81) دارای برخی نام‌های دامنه نامعتبر را بی‌صدا نادیده بگیرد، و از نسخه 3.1.9 در Kea برای تصحیح پرچم‌های نامعتبر توسعه یافته است، یعنی زمانی که هر دو پرچم 'S' و 'N' روی 1 تنظیم شده باشند، پرچم 'N' جهت سازگاری با رفتار ISC DHCP به 0 بازنشانی می‌شود.

با "ignore-dhcp-server-identifier": true، کارگزار نشانی موجود در گزینه DHCP Server Identifier را بررسی نمی‌کند، یعنی اینکه آیا پرس‌وجو به این کارگزار ارسال شده است یا کارگزاری دیگر (و در حالت دوم رها کردن پرس‌وجو).

{
  "Dhcp4": {
    "compatibility": {
      "ignore-dhcp-server-identifier": true
    }
  }
}

با "ignore-rai-link-selection": true، داده‌های زیرگزینه Relay Agent Information Link Selection برای انتخاب زیرشبکه (subnet) استفاده نمی‌شود. در این حالت، منطق عادی، انتخاب زیرشبکه را هدایت می‌کند، به جای تلاش برای استفاده از زیرشبکه مشخص‌شده توسط این زیرگزینه. این گزینه منطبق بر RFC نیست و به‌طور پیش‌فرض روی false تنظیم شده است. تنظیم این گزینه روی true می‌تواند به انتخاب زیرشبکه در سناریوهای خاصی کمک کند؛ برای مثال، هنگامی که رله‌های DHCP به مدیر سیستم اجازه نمی‌دهند مشخص کند کدام زیرگزینه‌ها در گزینه Relay Agent Information گنجانده شوند، و اطلاعات Link Selection نادرست را وارد می‌کنند.

{
  "Dhcp4": {
    "compatibility": {
      "ignore-rai-link-selection": true
    }
  }
}

پرچم سازگاری exclude-first-last-24 در بخش پیکربندی مخازن نشانی‌های IPv4 توضیح داده شده است (در صورت تنظیم روی true، نشانی‌های 0. و 255. از زیرشبکه‌هایی با طول پیشوند کوچکتر یا مساوی 24 مستثنی می‌شوند).

یک کارگزار DHCP الگوریتم پیچیده‌ای را برای انتخاب یک نشانی IPv4 برای یک کلاینت دنبال می‌کند. این کارگزار ترجیح می‌دهد نشانی‌های خاص درخواست‌شده توسط کلاینت و نشانی‌هایی را که کلاینت برای آن‌ها رزرو دارد، تخصیص دهد.

اگر کلاینت نشانی خاصی را درخواست نکند و هیچ رزروی نداشته باشد، یا کلاینت‌های دیگر از قبل در حال استفاده از هر یک از نشانی‌های درخواستی باشند، کارگزار باید نشانی دردسترس دیگری را در مخازن پیکربندی‌شده بیابد. تابعی از کارگزار با عنوان "allocator" (تخصیص‌دهنده) در Kea مسئول یافتن یک نشانی در دسترس در چنین مواردی است.

کارگزار Kea DHCPv4 پارامترهای پیکربندی را برای انتخاب تخصیص‌دهنده‌های مختلف در سطوح سراسری (global)، شبکه مشترک (shared-network) و زیرشبکه (subnet) ارائه می‌دهد. مثال زیر را در نظر بگیرید:

{
    "Dhcp4": {
        "allocator": "random",
        "subnet4": [
            {
                "id": 1,
                "subnet": "10.0.0.0/8",
                "allocator": "iterative"
            },
            {
                "id": 2,
                "subnet": "192.0.2.0/24"
            }
        ]
    }
}

این تخصیص‌دهنده، راهبرد تخصیص پیش‌فرض iterative (تکرارشونده) را در سطح سراسری لغو کرده و در عوض تخصیص random (تصادفی) را انتخاب می‌کند. تخصیص تصادفی برای زیرشبکه با شناسه 2 استفاده خواهد شد، در حالی که تخصیص تکرارشونده برای زیرشبکه با شناسه 1 به کار خواهد رفت.

بخش‌های زیر تخصیص‌دهنده‌های پشتیبانی‌شده و کاربردهای توصیه‌شده آن‌ها را شرح می‌دهند..SS مقایسه تخصیص‌دهنده‌ها (Allocators Comparison)

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

تخصیص‌دهنده عملکرد در بهره‌برداری پایین عملکرد در بهره‌برداری بالا تصادفی‌سازی اجاره راه‌اندازی/پیکربندی مصرف حافظه
Iterative بسیار بالا پایین خیر بسیار سریع پایین
Random بالا پایین بله بسیار سریع بالا (متغیر)
Free Lease Queue بالا بالا بله کند (بسته به اندازه poolها) بالا (متغیر)
Shared FLQ بالا بالا جزئی، poolهای درون زیرشبکه‌ها تصادفی هستند هنگام افزودن، کند؛ پس از افزودن، سریع پایین

این تخصیص‌دهنده پیش‌فرض مورد استفاده توسط کارساز Kea DHCPv4 است. این تخصیص‌دهنده آخرین آدرس پیشنهادشده را به خاطر می‌سپارد و آن آدرس را به اضافه یک، به کلاینت بعدی پیشنهاد می‌دهد. برای مثال، ممکن است آدرس‌ها را به این ترتیب پیشنهاد دهد: 192.0.2.10، 192.0.2.11، 192.0.2.12 و غیره. زمان لازم برای یافتن و پیشنهاد آدرس بعدی بسیار کوتاه است؛ بنابراین، زمانی که میزان بهره‌برداری از pool پایین بوده و احتمال در دسترس بودن آدرس بعدی بالا باشد، این تخصیص‌دهنده بیشترین کارایی را دارد.

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

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

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

قطعه‌پیکربندی زیر نحوه انتخاب تخصیص‌دهنده تصادفی را برای یک زیرشبکه نشان می‌دهد:

{
    "Dhcp4": {
        "allocator": "random",
        "subnet4": [
            {
                "id": 1,
                "subnet": "10.0.0.0/8",
                "allocator": "random"
            }
        ]
    }
}

این یک تخصیص‌دهنده (allocator) پیشرفته است که استفاده از آن باید در زیرشبکه‌هایی با استخرهای آدرس با بهره‌برداری بالا مورد توجه قرار گیرد. در چنین مواردی، ممکن است زمان قابل‌توجهی طول بکشد تا تخصیص‌دهنده تکرارشونده (iterative) یا تصادفی (random) یک آدرس در دسترس پیدا کند، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای آدرسی که قصد ارائه آن را دارند، اجاره معتبری وجود دارد یا خیر. هنگامی که استخرهای زیرشبکه به اتمام می‌رسند، تعداد این بررسی‌ها می‌تواند به اندازه تعداد کل آدرس‌های موجود در زیرشبکه باشد که این امر می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ‌دهی DHCP به هر درخواست بگذارد.

تخصیص‌دهنده Free Lease Queue (FLQ) تخصیص‌ها و آزادسازی‌های اجاره را دنبال کرده و فهرستی جاری از آدرس‌های در دسترس را برای هر استخر آدرس نگهداری می‌کند. این تخصیص‌دهنده اجازه می‌دهد که یک اجاره در دسترس در زمانی ثابت، صرف‌نظر از میزان بهره‌برداری استخرهای زیرشبکه، انتخاب شود. تخصیص‌دهنده به‌طور پیوسته فهرست اجاره‌های آزاد را با حذف هر اجاره تخصیص‌یافته و افزودن موارد رهاشده (released) یا بازیابی‌شده (reclaimed) به‌روزرسانی می‌کند.

قطعه‌پیکربندی زیر نحوه انتخاب تخصیص‌دهنده FLQ را برای یک زیرشبکه نشان می‌دهد:

{
    "Dhcp4": {
        "subnet4": [
            {
                "id": 1,
                "subnet": "192.0.2.0/24",
                "allocator": "flq"
            }
        ]
    }
}

چندین ملاحظه وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده مد نظر قرار دهد. تخصیص‌دهنده FLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی (startup) و بازپیکربندی (reconfiguration) سرور بگذارد، زیرا تخصیص‌دهنده باید فهرست اجاره‌های آزاد را برای هر زیرشبکه‌ای که در آن استفاده می‌شود، پر کند. این تأخیرها هم در زمان بارگذاری مجدد پیکربندی و هم هنگامی که زیرشبکه‌ها با استفاده از libdhcp_subnet_cmds.so <#std-ischooklib-libdhcp_subnet_cmds.so> ایجاد می‌شوند، قابل مشاهده است. این تخصیص‌دهنده مصرف حافظه را متناسب با اندازه کل استخرهای آدرسی که تخصیص‌دهنده FLQ برای آن‌ها به کار رفته است، برای نگهداری فهرست اجاره‌های آزاد افزایش می‌دهد. در نهایت، بازیابی اجاره (lease reclamation) باید با مقدار پایینی برای پارامتر reclaim-timer-wait-time فعال باشد تا اطمینان حاصل شود که سرور به‌طور مکرر اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق صف اجاره آزاد برای تخصیص در دسترس قرار می‌دهد؛ اجاره‌های منقضی‌شده تا زمانی که توسط سرور بازیابی نشوند، از نظر تخصیص‌دهنده آزاد تلقی نمی‌شوند. برای جزئیات بیشتر درباره فرایند بازیابی اجاره، به Lease Reclamation <#lease-reclamation> مراجعه کنید.

ما توصیه می‌کنیم که تخصیص‌دهنده FLQ تنها پس از بررسی دقیق انتخاب شود. برای نمونه، استفاده از آن برای یک زیرشبکه با استخر /8 ممکن است راه‌اندازی سرور را ۱۵ ثانیه یا بیشتر به تأخیر بیندازد. از سوی دیگر، تأخیر راه‌اندازی و افزایش مصرف حافظه برای زیرشبکه‌هایی با استخر /16 یا کوچک‌تر باید قابل قبول باشد. ما همچنین توصیه می‌کنیم نوع تخصیص‌دهنده دیگری را در تنظیمات پیکربندی سراسری (global) مشخص کرده و این انتخاب را در سطح زیرشبکه یا شبکه اشتراکی (shared-network) بازنویسی (override) کنید تا تخصیص‌دهنده FLQ فقط برای زیرشبکه‌های منتخب استفاده شود. بدین ترتیب، هنگامی که یک زیرشبکه جدید بدون تعیین تخصیص‌دهنده اضافه می‌شود، از تنظیم سراسری استفاده شده و در نتیجه از اثرات نامطلوب و غیرضروری بر زمان راه‌اندازی سرور جلوگیری می‌شود.

هشدار:

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

در Kea 3.1.1 یک پارامتر جدید با نام adaptive-lease-time-threshold اضافه شد. این پارامتر می‌تواند در سطوح سراسری (global)، شبکه اشتراکی (shared network) و زیرشبکه مشخص شود و مقداری ممیز شناور بین 0.0 (غیرشامل) و 1.0 می‌پذیرد. این پارامتر به‌طور پیش‌فرض یا هنگامی که روی 1.0 تنظیم شده باشد، غیرفعال است. این پارامتر فقط توسط تخصیص‌دهنده FLQ پشتیبانی می‌شود. هنگامی که نرخ اشغال استخرها در یک زیرشبکه بالاتر از مقدار مشخص‌شده باشد، سرور طول‌عمر معتبر اجاره را برای کلاینت‌های جدید به میزان مربوطه در min-valid-lifetime کاهش می‌دهد. کلاینت‌هایی که یک اجاره از پیش موجود را تمدید می‌کنند، حداقل طول‌عمر باقی‌مانده از اجاره فعلی را دریافت می‌کنند. از آنجا که اجاره‌ها سریع‌تر منقضی می‌شوند، سرور ممکن است سریع‌تر بازیابی شود یا به‌کلی از اتمام ظرفیت استخر جلوگیری کند.

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

هشدار:

تخصیص‌دهنده Shared Free Lease Queue Allocator که در Kea 3.1.9 اضافه شد، آزمایشی (experimental) تلقی شده و برای استفاده در محیط عملیاتی (production) پشتیبانی نمی‌شود.

تخصیص‌دهنده Shared Free Lease Queue (SFLQ) برای سایت‌هایی با بک‌اندهای اجاره مشترک (MySQL یا PostgreSQL) و زیرشبکه‌هایی با استخرهای آدرس با بهره‌برداری بالا در نظر گرفته شده است. در چنین مواردی، ممکن است زمان قابل‌توجهی طول بکشد تا تخصیص‌دهنده تکرارشونده یا تصادفی یک آدرس در دسترس پیدا کند، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای آدرسی که قصد ارائه آن را دارند، اجاره معتبری وجود دارد یا خیر. هنگامی که استخرهای زیرشبکه به اتمام می‌رسند، تعداد این بررسی‌ها می‌تواند به اندازه تعداد کل آدرس‌های زیرشبکه باشد. از آنجا که هر بررسی نیازمند یک پرس‌وجو در پایگاه‌داده است، این موضوع می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ‌دهی DHCP به هر درخواست بگذارد.

مشابه تخصیص‌دهنده Free Lease Queue، تخصیص‌دهنده SFLQ نیز تخصیص‌ها و آزادسازی‌های اجاره را دنبال کرده و فهرستی جاری از آدرس‌های در دسترس را برای هر استخر آدرس نگه می‌دارد. به این فهرست‌ها داده‌های SFLQ گفته می‌شود. این امر اجازه می‌دهد که صرف‌نظر از میزان بهره‌برداری استخرهای زیرشبکه، یک اجاره در دسترس در زمانی ثابت انتخاب شود. داده‌های SFLQ از طریق به‌روزرسانی‌های اختصاصی اجاره که توسط سرور Kea برای اجاره‌های متعلق به زیرشبکه‌های استفاده‌کننده از تخصیص SFLQ به کار گرفته می‌شوند، نگهداری می‌شوند.

تفاوت اساسی میان تخصیص‌دهنده‌های FLQ و SFLQ در این است که تخصیص SFLQ داده‌های SFLQ را به‌جای حافظه محلی سرور Kea، به‌صورت متمرکز در بک‌اند اجاره ذخیره می‌کند. این کار اجازه می‌دهد که این داده‌ها میان سرورها به اشتراک گذاشته شوند، به‌طوری که همگی درک یکسانی از وضعیت فعلی اجاره‌ها داشته باشند. این امر همچنین بدان معناست که داده‌های SFLQ پس از ایجاد، پایدار و ماندگار (persistent) هستند و بنابراین نیازی به ایجاد مجدد آن‌ها هنگام راه‌اندازی یا بازپیکربندی سرور Kea نیست. قطعه‌پیکربندی زیر نحوه انتخاب تخصیص‌دهنده SFLQ را برای یک زیرشبکه نشان می‌دهد:

{
    "Dhcp4": {
        "subnet4": [
            {
                "id": 1,
                "subnet": "192.0.2.0/24",
                "allocator": "shared-flq"
            }
        ]
    }
}

ملاحظاتی وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده در نظر بگیرد. همانند FLQ، تخصیص‌دهنده SFLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی و بازپیکربندی سرور بگذارد، زیرا تخصیص‌دهنده باید داده‌های SFLQ را برای هر استخر در هر زیرشبکه‌ای که در آن استفاده می‌شود ایجاد و پر کند. این تأخیرها هم در هنگام بارگذاری مجدد پیکربندی و هم زمانی که زیرشبکه‌ها با استفاده از libdhcp_subnet_cmds.so <#std-ischooklib-libdhcp_subnet_cmds.so> ایجاد می‌شوند، قابل مشاهده است. بر خلاف FLQ، این هزینه‌ها تنها در نخستین باری رخ می‌دهند که یک زیرشبکه برای استفاده از SFLQ پیکربندی می‌شود یا تغییراتی در محدوده‌های آدرس استخرهای آن اعمال می‌گردد. به بیانی دیگر، پس از راه‌اندازی مجدد یا بازپیکربندی، داده‌های SFLQ تنها باید برای استخرهایی ایجاد شوند که پیش‌تر داده‌ای برای آن‌ها ایجاد نشده است. بنابراین تأثیر آن بر راه‌اندازی‌های مجدد یا بازپیکربندی‌های بعدی زیرشبکه‌هایی که هم‌اکنون از SFLQ استفاده می‌کنند، حداقلی و ناچیز است.

از آنجا که داده‌های SFLQ در بک‌اند اجاره نگهداری می‌شوند، هزینه ذخیره‌سازی آن‌ها در فضای دیسک سرور پایگاه‌داده است نه در حافظه محلی سرور Kea. مصرف دیسک برای داده‌های SFLQ کسری از اطلاعاتی است که در حال حاضر به ازای هر اجاره ذخیره می‌شود و با افزایش بهره‌برداری از استخر، حجم داده‌های SFLQ کاهش می‌یابد.

ما توصیه می‌کنیم که تخصیص‌دهنده SFLQ تنها پس از بررسی دقیق انتخاب شود. همان‌طور که در بالا بحث شد، تأثیر بر راه‌اندازی هنگام شروع استفاده از SFLQ می‌تواند قابل‌توجه باشد. ایجاد داده‌های اولیه SFLQ برای استخرهای بزرگ (مانند ``/8``) ممکن است راه‌اندازی سرور را برای هر استخر چندین ثانیه یا بیشتر به تأخیر بیندازد. این کار برای استخرهای کوچک‌تر (مانند ``/16`` یا کمتر) سریع‌تر است، اما در صورت وجود تعداد زیادی از این استخرها، مجموع زمان صرف‌شده برای هر استخر می‌تواند قابل‌توجه شود. برای کاهش این هزینه راه‌اندازی، توصیه می‌کنیم نوع دیگری از تخصیص‌دهنده را در سطح سراسری مشخص کرده و تخصیص‌دهنده SFLQ را در سطح زیرشبکه یا شبکه اشتراکی فقط برای زیرشبکه‌های منتخب تعیین کنید.

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

نکته:

اکیداً توصیه می‌شود که پیکربندی زیرشبکه‌ها برای استفاده یا توقف استفاده از تخصیص SFLQ در بازه‌های تعمیر و نگهداری (maintenance windows) انجام شود، تا در زمان اعمال تغییرات، سرورها به‌طور فعال به کلاینت‌های آن زیرشبکه‌ها سرویس ندهند. این کار از ایجاد ناهماهنگی در داده‌های SFLQ جلوگیری می‌کند.

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

همان‌طور که پیش‌تر ذکر شد، هنگامی که یک سرور راه‌اندازی مجدد یا بازپیکربندی می‌شود، روی زیرشبکه‌های خود پیمایش کرده و تخصیص‌دهنده پیکربندی‌شده را برای استخرهای آن زیرشبکه راه‌اندازی اولیه (initialize) می‌کند. برای تخصیص‌دهنده SFLQ، این امر باعث می‌شود سرور از بک‌اند اجاره درخواست کند تا داده‌های SFLQ را برای هر استخر در زیرشبکه ایجاد کند. اگر داده‌های SFLQ از قبل برای یک استخر موجود باشد، درخواست بلافاصله بازمی‌گردد. در غیر این صورت، پس از ایجاد داده‌های SFLQ برای آن استخر بازخواهد گشت. ایجاد داده‌های SFLQ برای یک استخر خاص یک عملیات انحصاری (exclusive) است. پس از شروع این عملیات توسط یک سرور، هرگونه درخواست از سوی سرورهای دیگر برای ایجاد داده‌های SFLQ برای همان استخر مسدود (block) شده و تا زمانی که درخواست اول ایجاد داده‌های SFLQ استخر را کامل نکند، بازنخواهد گشت. بدین ترتیب تنها یک سرور داده‌های SFLQ استخر را ایجاد می‌کند و سایر سرورها تا زمانی که داده‌های SFLQ آن استخر وجود نداشته باشد، از استفاده از آن منع می‌شوند. این رفتار برای حفظ نظم در طول راه‌اندازی‌های مجدد و بازپیکربندی‌های هم‌زمان سرورها طراحی شده است.

موضوع استخرهای هم‌پوشان (overlapping pools) نیز مطرح است. Kea امکان پیکربندی استخرهایی را می‌دهد که محدوده آدرس آن‌ها با استخرهای دیگر هم‌پوشانی دارد. تخصیص‌دهنده SFLQ تا زمانی که تمام این استخرها برای استفاده از تخصیص‌دهنده SFLQ پیکربندی شده باشند، به‌طور یکپارچه از این مورد پشتیبانی می‌کند.

نکته:

بازیابی اجاره باید با مقدار پایینی برای پارامتر reclaim-timer-wait-time فعال باشد تا اطمینان حاصل شود که سرور به‌طور مکرر اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق داده‌های SFLQ برای تخصیص در دسترس قرار می‌دهد. اجاره‌های منقضی‌شده تا زمانی که توسط سرور بازیابی نشوند، از نظر تخصیص‌دهنده آزاد تلقی نمی‌شوند. برای جزئیات بیشتر درباره فرایند بازیابی اجاره، به Lease Reclamation <#lease-reclamation> مراجعه کنید.

نکته:

تخصیص‌دهنده SFLQ به استفاده در استخرهایی محدود شده است که بزرگ‌تر از /8 نباشند (به عنوان مثال ۱۶۷۷۷۲۱۶ آدرس). استخرهایی با ظرفیت بزرگ‌تر موجب خطای پیکربندی خواهند شد.

تخصیص‌دهنده SFLQ از adaptive-lease-time-threshold پشتیبانی نمی‌کند..SH "سرور DHCPV6 (THE DHCPV6 SERVER)"

توصیه می‌شود که سرور Kea DHCPv6 با استفاده از keactrl <#std-iscman-keactrl> (توضیح داده شده در مدیریت Kea با keactrl <#keactrl>) راه‌اندازی و متوقف شود؛ با این حال، اجرای مستقیم سرور از طریق دستور kea-dhcp6 <#std-iscman-kea-dhcp6> نیز امکان‌پذیر است، که گزینه‌های خط فرمان زیر را می‌پذیرد:

  • -c file - فایل پیکربندی را مشخص می‌کند. این تنها گزینه اجباری است.
  • -d - مشخص می‌کند که آیا ثبت وقایع سرور باید به حالت اشکال‌زدایی/پرگویی (debug/verbose) تغییر کند یا خیر. در حالت پرگویی، سطح شدت گزارش‌گیری و debuglevel مشخص‌شده در فایل پیکربندی نادیده گرفته می‌شوند؛ سطح شدت "debug" و حداکثر debuglevel (مقدار 99) فرض می‌شوند. این پرچم برای تغییر وضعیت موقت سرور به حداکثر پرگویی، به عنوان مثال هنگام اشکال‌زدایی، بسیار مناسب است.
  • -p server-port - پورت محلی UDP را که سرور روی آن گوش می‌دهد مشخص می‌کند. این گزینه فقط هنگام آزمایش مفید است، زیرا یک سرور DHCPv6 که روی پورت‌هایی غیر از پورت‌های استاندارد گوش می‌دهد، قادر به رسیدگی به پرس‌وجوهای عادی DHCPv6 نیست.
  • -P client-port - پورت دوردست UDP را که سرور تمام پاسخ‌ها را به آن ارسال می‌کند مشخص می‌کند. این گزینه فقط هنگام آزمایش مفید است، زیرا یک سرور DHCPv6 که پاسخ‌ها را به پورت‌هایی غیر از پورت‌های استاندارد ارسال می‌کند، قادر به رسیدگی به پرس‌وجوهای عادی DHCPv6 نیست.
  • -t file - یک فایل پیکربندی را جهت آزمایش مشخص می‌کند. kea-dhcp6 <#std-iscman-kea-dhcp6> آن را بارگذاری کرده، بررسی می‌کند و خارج می‌شود. در طول آزمایش، پیام‌های گزارش در خروجی استاندارد و پیام‌های خطا در خطای استاندارد چاپ می‌شوند. نتیجه آزمایش از طریق کد خروج گزارش می‌شود (۰ = پیکربندی درست به نظر می‌رسد، ۱ = خطا رخ داده است). این بررسی جامع نیست؛ برخی از بررسی‌ها فقط هنگام اجرای واقعی سرور امکان‌پذیر هستند.
  • -T file - یک فایل پیکربندی را جهت آزمایش مشخص می‌کند. kea-dhcp6 <#std-iscman-kea-dhcp6> آن را بارگذاری کرده، بررسی می‌کند و خارج می‌شود. این گزینه بررسی‌های اضافی فراتر از آنچه -t ارائه می‌دهد انجام می‌دهد، مانند برقراری اتصالات پایگاه داده (برای lease backend، host reservations backend، configuration backend و forensic logging backend)، بارگذاری کتابخانه‌های hook، تجزیه پیکربندی‌های hook-library و غیره. این گزینه سوکت‌های UNIX یا TCP/UDP، فایل‌های قفل و همچنین باز کردن یا چرخش (rotate) فایل‌ها را انجام نمی‌دهد، زیرا هر یک از این اقدامات می‌تواند با فرایند در حال اجرا روی همان ماشین تداخل داشته باشد.
  • -v - نسخه Kea را نمایش داده و خارج می‌شود.
  • -V - نسخه گسترش‌یافته Kea را همراه با پارامترهای اضافی نمایش داده و خارج می‌شود. این فهرست شامل نسخه کتابخانه‌هایی است که به صورت پویا به Kea پیوند (link) داده شده‌اند.
  • -W - گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش رونوشتی از فایل config.report تولید شده توسط meson setup است؛ این گزارش درون فایل اجرایی باینری گنجانده شده است.

    محتویات فایل config.report همچنین می‌تواند با بررسی برخی از کتابخانه‌ها در درخت نصب یا در درخت کد منبع در دسترس قرار گیرد.

# from installation using libkea-process.so
$ strings ${prefix}/lib/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.so
$ strings src/lib/process/.libs/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.a
$ strings src/lib/process/.libs/libkea-process.a | sed -n 's/;;;; //p'
# from sources using libcfgrpt.a
$ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed -n 's/;;;; //p'
•
-X - از نسخه Kea 3.0، محدودیت‌های امنیتی را غیرفعال می‌کند. سرور همچنان موارد نقض را بررسی می‌کند اما به جای توقف با خطا، هنگام مواجهه با آن‌ها گزارش‌های هشدار صادر می‌کند. لطفاً برای جزئیات به Kea Runtime Security Policy Checking <#sec-kea-runtime-security-policy-checking> مراجعه کنید.

هنگام راه‌اندازی، سرور رابط‌های شبکه موجود را شناسایی کرده و تلاش می‌کند سوکت‌های UDP را روی تمام رابط‌های فهرست‌شده در فایل پیکربندی باز کند. از آنجا که سرور DHCPv6 پورت‌های ممتاز (privileged) را باز می‌کند، به دسترسی root نیاز دارد؛ این دیمن باید به عنوان کاربر root اجرا شود.

در طول راه‌اندازی، سرور تلاش می‌کند یک فایل PID به فرم زیر ایجاد کند: [pidfile_dir]/[conf name].kea-dhcp6.pid، که در آن:

  • pidfile_dir - برابر است با [prefix]/[localstatedir]/run/kea که در آن prefix و localstatedir مقادیری هستند که به meson setup با استفاده از --prefix و --localstatedir منتقل شده‌اند و به طور پیش‌فرض به ترتیب /usr/local و var می‌باشند. بنابراین کل مسیر pidfile_dir به طور پیش‌فرض /usr/local/var است. توجه داشته باشید که این مقدار ممکن است در زمان اجرا با تنظیم متغیر محیطی KEA_PIDFILE_DIR که عمدتاً برای اهداف آزمایشی در نظر گرفته شده است، بازنویسی شود.
  • conf name: نام فایل پیکربندی مورد استفاده برای راه‌اندازی سرور، منهای تمام مسیرهای پیشین و پسوند فایل است. به عنوان مثال، در صورت داشتن مسیر /usr/local/etc/kea/myconf.txt، بخش استفاده‌شده myconf خواهد بود.

اگر فایل از قبل موجود باشد و شامل PID یک فرایند فعال باشد، سرور پیام گزارش DHCP6_ALREADY_RUNNING را صادر کرده و خارج می‌شود. این احتمال وجود دارد، اگرچه بعید است، که فایل بازمانده‌ای از یک فروپاشی سیستم (crash) باشد و فرایندی که PID متعلق به آن است ربطی به Kea نداشته باشد. در چنین حالتی، لازم است فایل PID را به صورت دستی حذف کنید.

سرور را می‌توان با استفاده از دستور kill متوقف کرد. هنگام اجرا در کنسول، سرور را می‌توان با فشردن Ctrl-c نیز متوقف نمود. Kea این ترکیب کلید را تشخیص داده و به آرامی و به درستی خاموش می‌شود.

پیکربندی مجدد هر سرور Kea با دریافت سیگنال SIGHUP آغاز می‌شود. هنگامی که یک سرور سیگنال SIGHUP را دریافت می‌کند، فایل پیکربندی خود را دوباره می‌خواند و در صورتی که پیکربندی جدید معتبر باشد، از آن استفاده می‌کند. اگر معلوم شود که پیکربندی جدید نامعتبر است، سرور پیکربندی فعلی خود را حفظ می‌کند؛ با این حال، در برخی موارد یک پیام خطای مهلک (fatal) ثبت می‌شود که نشان می‌دهد سرور دیگر هیچ سرویسی ارائه نمی‌دهد: در این شرایط باید در اسرع وقت یک پیکربندی سالم بارگذاری شود..SS پیکربندی کارگزار DHCPv6

این بخش نحوه پیکربندی کارگزار DHCPv6 مربوط به Kea را با استفاده از یک فایل پیکربندی توضیح می‌دهد.

پیش از آغاز به کار DHCPv6، فایل پیکربندی آن باید ایجاد شود. پیکربندی پایه‌ای به شرح زیر است:

{
# DHCPv6 configuration starts on the next line
"Dhcp6": {
# First we set up global values
    "valid-lifetime": 4000,
    "renew-timer": 1000,
    "rebind-timer": 2000,
    "preferred-lifetime": 3000,
# Next we set up the interfaces to be used by the server.
    "interfaces-config": {
        "interfaces": [ "eth0" ]
    },
# And we specify the type of lease database
    "lease-database": {
        "type": "memfile",
        "persist": true,
        "name": "/var/lib/kea/dhcp6.leases"
    },
# Finally, we list the subnets from which we will be leasing addresses.
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/64",
            "pools": [
                {
                    "pool": "2001:db8:1::1-2001:db8:1::ffff"
                }
             ]
        }
    ]
# DHCPv6 configuration ends with the next line
}
}

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

خطوطی که با علامت هش (#) آغاز می‌شوند، توضیح (comment) هستند و توسط کارگزار نادیده گرفته می‌شوند؛ این خطوط به هیچ وجه بر عملکرد آن تأثیری ندارند.

پیکربندی در خط نخست با براکت مجعد بازشونده (یا آکولاد باز) اولیه آغاز می‌شود. هر پیکربندی باید حاوی شیئی باشد که پیکربندی ماژول Kea مصرف‌کننده آن را مشخص می‌کند. در مثال بالا، این شیء Dhcp6 نام دارد.

پیکربندی Dhcp6 با خط "Dhcp6": { آغاز شده و با آکولاد بسته متناظر (در مثال بالا، آکولاد پس از آخرین توضیح) پایان می‌یابد. هر آنچه میان این خطوط تعریف می‌شود، به عنوان پیکربندی Dhcp6 در نظر گرفته می‌شود.

به طور کلی، ترتیبی که این پارامترها ظاهر می‌شوند اهمیتی ندارد، اما دو نکته حائز اهمیت وجود دارد. نخست آنکه فایل پیکربندی باید یک JSON با ساختار صحیح (well-formed) باشد؛ بدین معنا که پارامترها برای هر حوزه (scope) مشخص باید با یک کاما از هم جدا شوند، و نباید بعد از آخرین پارامتر کاما قرار گیرد. هنگام بازچینی فایل پیکربندی، جابه‌جا کردن یک پارامتر به موقعیت آخر یا از موقعیت آخر در یک حوزه، ممکن است نیازمند جابه‌جایی کاما نیز باشد. نکته دوم این است که تکرار چندباره یک پارامتر امری نامتداول است — هرچند از نظر قواعد JSON مجاز می‌باشد. اگر چنین اتفاقی بیفتد، آخرین رخداد یک پارامتر در یک حوزه معین استفاده می‌شود، در حالی که تمامی موارد پیشین نادیده گرفته می‌شوند. بعید است این موضوع سردرگمی ایجاد کند، چرا که در عمل دلیلی برای نگه‌داشتن چندین نسخه از یک پارامتر یکسان در فایل پیکربندی وجود ندارد.

چند مؤلفه نخست در پیکربندی DHCPv6 پارامترهایی سراسری (global) را تعریف می‌کنند. valid-lifetime مشخص می‌کند نشانی‌هایی (اجاره‌هایی یا leases) که توسط کارگزار واگذار می‌شوند تا چه مدت معتبر هستند؛ مقدار پیش‌فرض این است که کارخواه مجاز به استفاده از نشانی مشخص‌شده برای مدت ۴۰۰۰ ثانیه باشد. (توجه داشته باشید که اعداد صحیح به همان صورت و بدون هیچ‌گونه علامت نقل‌قول در اطرافشان مشخص می‌شوند.) این نشانی در ۳۰۰۰ ثانیه منسوخ (deprecated) خواهد شد؛ بدین معنا که کارخواه‌ها مجاز به حفظ اتصالات قدیمی هستند، اما نمی‌توانند از این نشانی برای ایجاد اتصالات جدید استفاده کنند. renew-timer و rebind-timer مقادیری (همچنین به ثانیه) هستند که زمان‌سنج‌های T1 و T2 را تعریف می‌کنند؛ این زمان‌سنج‌ها تعیین می‌کنند چه زمانی کارخواه رویه‌های تجدید (renewal) و اتصال مجدد (rebind) را آغاز کند.

نگاشت interfaces-config رابط‌های شبکه‌ای را مشخص می‌کند که کارگزار باید روی آن‌ها به پیام‌های DHCP گوش فرا دهد. پارامتر interfaces فهرستی از رابط‌های شبکه را تعیین می‌کند که کارگزار باید به آن‌ها گوش دهد. فهرست‌ها با براکت‌های مربعی باز و بسته می‌شوند و عناصر آن‌ها با کاما از یکدیگر جدا می‌گردند. برای گوش فرا دادن روی دو رابط، مؤلفه interfaces-config باید شبیه به این باشد:

{
"interfaces-config": {
    "interfaces": [ "eth0", "eth1" ]
},
...
}

خطوط بعدی پایگاه‌داده اجاره (lease database) را تعریف می‌کنند؛ مکانی که کارگزار اطلاعات اجاره خود را در آن ذخیره می‌نماید. این مثال خاص به کارگزار می‌گوید از memfile استفاده کند که ساده‌ترین و سریع‌ترین زیرساخت (backend) پایگاه‌داده است. این زیرساخت از یک پایگاه‌داده درون‌حافظه‌ای بهره می‌برد و اجاره‌ها را روی دیسک در یک فایل CSV (مقادیر جداشده با کاما) ذخیره می‌کند. این یک مثال پیکربندی بسیار ساده است؛ معمولاً پیکربندی پایگاه‌داده اجاره مفصل‌تر بوده و شامل پارامترهای تکمیلی است. توجه داشته باشید که lease-database یک شیء است و با استفاده از یک آکولاد باز، حوزه جدیدی باز می‌کند. پارامترهای آن (در این مثال تنها یک مورد: type) در ادامه می‌آیند. اگر بیش از یک پارامتر وجود داشت، با کاما جدا می‌شدند. این حوزه با یک آکولاد بسته، پایان می‌یابد. از آنجا که پارامترهای بیشتری برای تعریف Dhcp6 در ادامه می‌آیند، یک کاما در انتهای آن قرار گرفته است.

در نهایت، باید فهرستی از زیرشبکه‌های (subnets) مربوط به IPv6 را تعریف کنیم. این مهم‌ترین ساختار پیکربندی DHCPv6 است، چرا که کارگزار از این اطلاعات برای پردازش درخواست‌های کارخواه‌ها استفاده می‌کند. این بخش تمامی زیرشبکه‌هایی را مشخص می‌کند که انتظار می‌رود کارگزار درخواست‌های DHCP را از آن‌ها دریافت کند. زیرشبکه‌ها با پارامتر subnet6 مشخص می‌شوند. این پارامتر یک فهرست است، بنابراین با براکت‌های مربعی آغاز شده و پایان می‌یابد. هر تعریف زیرشبکه در این فهرست دارای چندین صفت وابسته به خود است؛ بنابراین یک ساختار به شمار می‌رود و با آکولاد باز و بسته می‌شود. در کمترین حالت، تعریف یک زیرشبکه باید حداقل شامل دو پارامتر باشد: subnet که کل زیرشبکه را تعریف می‌کند؛ و pools که فهرستی از استخرهای تخصیص‌یافته به صورت پویا است که توسط کارگزار DHCP اداره می‌شوند.

این مثال شامل یک زیرشبکه تکی است. در صورتی که بیش از یک مورد تعریف می‌شد، عناصر بیشتری در پارامتر subnet6 مشخص شده و با کاما از هم جدا می‌شدند. برای نمونه، جهت تعریف دو زیرشبکه، نحو (syntax) زیر به کار می‌رفت:

{
"subnet6": [
    {
        "id": 1,
        "pools": [ { "pool": "2001:db8:1::/112" } ],
        "subnet": "2001:db8:1::/64"
    },
    {
        "id": 2,
        "pools": [ { "pool": "2001:db8:2::1-2001:db8:2::ffff" } ],
        "subnet": "2001:db8:2::/64"
    }
],
...
}

توجه داشته باشید که تورفتگی (indentation) اختیاری است و صرفاً به دلایل زیبایی‌شناختی استفاده می‌شود. در برخی موارد ممکن است ترجیح داده شود از قالب نشانه‌گذاری فشرده‌تری استفاده شود.

پس از آنکه تمام پارامترها مشخص شدند، دو زمینه (context) باز وجود دارد: global و Dhcp6؛ از این رو، برای بستن آن‌ها باید از دو براکت مجعد بسته (آکولاد بسته) استفاده شود..SS ذخیره‌سازی اجاره‌ها (Lease Storage)

تمام اجاره‌های (leases) صادر شده توسط کارساز در پایگاه‌دادهٔ اجاره ذخیره می‌شوند. سه بک‌اند پایگاه‌داده در دسترس است: memfile (پیش‌فرض)، MySQL و PostgreSQL.

کارساز قادر است داده‌های اجاره را در مخازن مختلفی ذخیره کند. استقرارهای بزرگ‌تر ممکن است ذخیرهٔ اجاره‌ها در یک پایگاه‌داده را انتخاب کنند؛ بخش «پیکربندی پایگاه‌دادهٔ اجاره» (Lease Database Configuration) این گزینه را شرح می‌دهد. با این حال، در استقرارهای معمولی و کوچک‌تر، کارساز اطلاعات اجاره را به جای پایگاه‌داده در یک فایل CSV ذخیره می‌کند. علاوه بر نیاز به مدیریت کمتر، مزیت استفاده از فایل برای ذخیره‌سازی این است که وابستگی به نرم‌افزارهای پایگاه‌دادهٔ شخص ثالث را برطرف می‌سازد.

پیکربندی بک‌اند memfile از طریق پارامترهای Dhcp6/lease-database کنترل می‌شود. پارامتر type اجباری است و از طریق مقدار "memfile" مشخص می‌کند که کارساز باید از کدام محل ذخیره‌سازی برای اجاره‌ها استفاده کند. فهرست زیر پارامترهای اختیاری بیشتری را ارائه می‌دهد که می‌توان از آن‌ها برای پیکربندی بک‌اند memfile استفاده کرد.

  • persist: کنترل می‌کند که آیا اجاره‌های جدید و به‌روزرسانی‌های اجاره‌های موجود روی فایل نوشته شوند یا خیر. اکیداً توصیه می‌شود که در تمام طول کارکرد عادی کارساز، مقدار این پارامتر روی true تنظیم شده باشد. ننوشتن اجاره‌ها روی دیسک بدین معناست که اگر کارساز راه‌اندازی مجدد شود (مثلاً پس از قطع برق)، نخواهد دانست چه آدرس‌هایی واگذار شده‌اند. در نتیجه، ممکن است به کلاینت‌های جدید، آدرس‌هایی را تخصیص دهد که هم‌اکنون در حال استفاده هستند. مقدار false بیشتر برای اهداف آزمایش کارایی مفید است. مقدار پیش‌فرض پارامتر persist برابر با true است که نوشتن به‌روزرسانی‌های اجاره در فایل اجاره را فعال می‌کند.
  • name: فایل اجاره‌ای را که اجاره‌های جدید و به‌روزرسانی‌های اجاره در آن ثبت می‌شوند مشخص می‌کند. مقدار پیش‌فرض این پارامتر "[kea-install-dir]/var/lib/kea/kea-leases6.csv" است.

نکته:

از نسخهٔ Kea 2.7.9 به بعد، فایل‌های اجاره تنها می‌توانند از دایرکتوری داده‌ای که در زمان کامپایل تعیین شده است بارگیری شوند: "[kea-install-dir]/var/lib/kea". این مسیر را می‌توان در هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_DHCP_DATA_DIR روی مسیر مورد نظر بازنویسی (override) کرد. اگر در name مسیری غیر از این مقدار استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند، یا اگر از قبل در حال اجرا باشد، یک خطای جبران‌ناپذیر را ثبت می‌کند. برای سهولت در مشخص کردن نام فایل سفارشی، کافی است بخش مسیر را از name حذف کنید.
  • lfc-interval: بازهٔ زمانی (به ثانیه) را تعیین می‌کند که کارساز در آن یک پاک‌سازی فایل اجاره (LFC) انجام می‌دهد. این فرآیند اطلاعات مازاد (تاریخچه‌ای) را از فایل اجاره حذف کرده و به‌طور مؤثری حجم فایل اجاره را کاهش می‌دهد. فرآیند پاک‌سازی در ادامهٔ همین بخش با جزئیات بیشتری شرح داده شده است. مقدار پیش‌فرض lfc-interval برابر با 3600 است. مقدار 0 فرآیند LFC را غیرفعال می‌کند.
  • max-row-errors: تعداد خطاهای ردیف را پیش از این‌که کارساز تلاش برای بارگیری فایل اجاره را متوقف کند مشخص می‌کند. هنگامی که کارساز یک فایل اجاره را بارگیری می‌کند، آن را ردیف به ردیف پردازش می‌کند، که هر ردیف شامل یک اجارهٔ تکی است. اگر یک ردیف معیوب باشد و نتواند به درستی پردازش شود، کارساز آن را ثبت کرده، آن ردیف را نادیده می‌گیرد و به ردیف بعدی می‌رود. این پارامتر می‌تواند برای تعیین حد مجاز برای تعداد دفعات نادیده‌گرفته‌شدن ردیف‌ها استفاده شود، که پس از رسیدن به آن، کارساز تلاش را متوقف کرده و خارج می‌شود. مقدار پیش‌فرض 0 این محدودیت را غیرفعال کرده و به کارساز اجازه می‌دهد صرف‌نظر از این‌که چه تعداد ردیف نادیده گرفته می‌شوند، کل فایل را پردازش کند.

یک نمونه پیکربندی از بک‌اند memfile در زیر آورده شده است:

"Dhcp6": {
    "lease-database": {
        "type": "memfile",
        "persist": true,
        "name": "kea-leases6.csv",
        "lfc-interval": 1800,
        "max-row-errors": 100
    }
}

این پیکربندی kea-leases6.csv را به عنوان فایل ذخیره‌سازی اطلاعات اجاره انتخاب کرده و پایایی (نوشتن به‌روزرسانی‌های اجاره روی این فایل) را فعال می‌کند. همچنین بک‌اند را طوری پیکربندی می‌کند که هر ۱۸۰۰ ثانیه (۳۰ دقیقه) یک‌بار پاک‌سازی دوره‌ای فایل اجاره را انجام دهد و حداکثر تعداد خطاهای ردیف را روی ۱۰۰ تنظیم می‌کند.

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

پاک‌سازی فایل اجاره (LFC) تمام مدخل‌های پیشین مربوط به هر کلاینت را حذف کرده و تنها آخرین مدخل‌ها را نگه می‌دارد. بازهٔ زمانی اجرای پاک‌سازی قابل پیکربندی است و باید متناسب با بسامد تمدیدهای اجاره که از سوی کلاینت‌ها آغاز می‌شود انتخاب گردد. هرچه تمدیدها مکررتر باشند، مقدار lfc-interval باید کوچک‌تر باشد. با این حال، توجه داشته باشید که LFC زمان‌بر است و بنابراین این احتمال (هرچند بعید) وجود دارد که اگر lfc-interval بیش از حد کوتاه باشد، یک پاک‌سازی جدید در حالی آغاز شود که پاک‌سازی قبلی هنوز در حال اجراست. کارساز در صورت تشخیص این‌که پاک‌سازی پیشین هنوز در جریان است، با صرف‌نظر کردن از پاک‌سازی جدید این موضوع را مدیریت می‌کند، اما این بدان معناست که پاک‌سازی‌های واقعی با فواصلی طولانی‌تر از بازهٔ تنظیم‌شده اجرا خواهند شد. علاوه بر این، راه‌اندازی یک فرآیند پاک‌سازی جدید سرباری به کارساز اضافه می‌کند که باعث می‌شود در بازهٔ زمانی کوتاهی که فرآیند پاک‌سازی جدید ایجاد (spawn) می‌شود، قادر به پاسخگویی به درخواست‌های جدید نباشد. بنابراین، توصیه می‌شود که مقدار lfc-interval به گونه‌ای انتخاب شود که به LFC اجازه دهد پیش از شروع یک پاک‌سازی جدید، کار خود را به پایان برساند.

پاک‌سازی فایل اجاره توسط یک فرآیند مجزا (در پس‌زمینه) انجام می‌شود تا از تأثیر منفی بر کارایی فرآیند کارساز جلوگیری گردد. برای جلوگیری از تداخل میان دو فرآیند که از فایل‌های اجارهٔ یکسانی استفاده می‌کنند، فرآیند LFC با باز کردن یک فایل اجارهٔ جدید توسط Kea آغاز می‌شود؛ فرآیند واقعی LFC روی فایل اجاره‌ای کار می‌کند که دیگر توسط کارساز استفاده نمی‌شود. همچنین فایل‌های دیگری نیز به عنوان اثر جانبی پاک‌سازی فایل اجاره ایجاد می‌شوند. شرح تفصیلی فرآیند LFC در ادامهٔ این کتابچهٔ راهنمای مدیران Kea آورده شده است: فرآیند LFC <#kea-lfc>..SS پیکربندی پایگاه دادهٔ اجاره (Lease Database Configuration)

نکته:

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

نکته:

برنامهٔ Kea نیازمند آن است که منطقهٔ زمانی پایگاه داده با منطقهٔ زمانی سیستم همخوانی داشته باشد. برای جزئیات بیشتر، بخش «First-Time Creation of the MySQL Database» <#mysql-database-create> و «First-Time Creation of the PostgreSQL Database» <#pgsql-database-create> را ببینید.

پیکربندی پایگاه دادهٔ اجاره از طریق پارامترهای Dhcp6/lease-database کنترل می‌شود. نوع پایگاه داده باید روی memfile، mysql یا postgresql تنظیم شود؛ برای نمونه:

"Dhcp6": { "lease-database": { "type": "mysql", ... }, ... }

سپس، نام پایگاه داده‌ای که برای نگهداری اجاره‌ها استفاده می‌شود باید تعیین گردد؛ این همان نامی است که هنگام ایجاد پایگاه داده استفاده شده است (بخش «First-Time Creation of the MySQL Database» <#mysql-database-create> یا «First-Time Creation of the PostgreSQL Database» <#pgsql-database-create> را ببینید).

برای MySQL یا PostgreSQL:

"Dhcp6": { "lease-database": { "name": "database-name" , ... }, ... }

اگر پایگاه داده روی سیستمی متفاوت از کارگزار DHCPv6 قرار دارد، نام میزبان پایگاه داده نیز باید مشخص شود:

"Dhcp6": { "lease-database": { "host": "remote-host-name", ... }, ... }

به‌طور معمول، پایگاه داده روی همان ماشینی است که کارگزار DHCPv6 قرار دارد. در این حالت، مقدار را روی یک رشتهٔ خالی تنظیم کنید:

"Dhcp6": { "lease-database": { "host" : "", ... }, ... }

در صورتی که پایگاه داده از درگاهی غیر از درگاه پیش‌فرض استفاده کند، آن نیز می‌تواند مشخص شود:

"Dhcp6": { "lease-database": { "port" : 12345, ... }, ... }

در صورتی که پایگاه داده روی سیستم دیگری قرار داشته باشد، ممکن است مدیر سیستم نیاز به تعیین بازهٔ طولانی‌تری برای مهلت زمانی اتصال (timeout) داشته باشد:

"Dhcp6": { "lease-database": { "connect-timeout" : timeout-in-seconds, ... }, ... }

مقدار پیش‌فرضِ پنج ثانیه باید برای اتصالات محلی بیش از حد کافی باشد. هرچند اگر یک مهلت زمانی تعیین شود، باید یک عدد صحیح بزرگ‌تر از صفر باشد.

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

"Dhcp6": { "lease-database": { "max-reconnect-tries" : number-of-tries, ... }, ... }

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

تعداد میلی‌ثانیه‌هایی که کارگزار پس از قطع اتصال، بین تلاش‌ها برای اتصال مجدد به پایگاه دادهٔ اجاره منتظر می‌ماند نیز می‌تواند مشخص شود:

"Dhcp6": { "lease-database": { "reconnect-wait-time" : number-of-milliseconds, ... }, ... }

مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی خودکار را غیرفعال کرده و باعث می‌شود کارگزار بلافاصله پس از تشخیص قطع اتصال خارج شود.

"Dhcp6": { "lease-database": { "on-fail" : "stop-retry-exit", ... }, ... }

مقادیر ممکن عبارتند از:

  • stop-retry-exit - سرویس DHCP را هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده غیرفعال می‌کند، و پس از اتمام max-reconnect-tries در صورت عدم موفقیت، کارگزار را خاموش می‌کند. این مقدار پیش‌فرض برای بک‌اند اجاره، بک‌اند میزبان و بک‌اند پیکربندی است.
  • serve-retry-exit - هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده، به سرویس‌دهی DHCP ادامه می‌دهد و پس از اتمام max-reconnect-tries در صورت عدم موفقیت، کارگزار را خاموش می‌کند.
  • serve-retry-continue - به سرویس‌دهی DHCP ادامه می‌دهد و حتی اگر بازیابی با شکست مواجه شود، کارگزار را خاموش نمی‌کند. این مقدار پیش‌فرض برای ثبت وقایع قانونی (forensic logging) است.

نکته:

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

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

اکیداً توصیه می‌شود که تنظیم پیش‌فرض stop-retry-exit را برای مدیریت اجاره (lease manager) تغییر ندهید، چرا که فعال بودن اتصال در زمان پردازش ترافیک DHCP امری حیاتی است. این مورد را تنها در صورتی تغییر دهید که از کارگزار منحصراً به عنوان یک ابزار پیکربندی استفاده شود.

"Dhcp6": { "lease-database": { "retry-on-startup" : true, ... }, ... }

هنگام راه‌اندازی کارگزار، ناتوانی در اتصال به هر یک از بک‌اندهای پیکربندی‌شده تنها در صورتی مهلک (fatal) تلقی می‌شود که retry-on-startup روی false (پیش‌فرض) تنظیم شده باشد. یک خطای مهلک در گزارش ثبت می‌شود و کارگزار خارج می‌شود، بر این مبنا که پیکربندی باید در زمان راه‌اندازی معتبر باشد. خروج به سیستم‌عامل این امکان را به اسکریپت‌های نظارتی (nanny scripts) می‌دهد تا مشکل را تشخیص دهند. اگر retry-on-startup روی true تنظیم شود، کارگزار تلاش‌ها برای برقراری مجدد اتصال را حتی در زمان راه‌اندازی اولیه یا هنگام رویدادهای بازپیکربندی آغاز می‌کند و به عملیات مشخص‌شده در پارامتر on-fail عمل می‌نماید.

پارامتر host توسط بک‌اندهای MySQL و PostgreSQL استفاده می‌شود.

در نهایت، اطلاعات احراز هویت حسابی که کارگزار تحت آن به پایگاه داده دسترسی خواهد داشت باید تنظیم شود:

"Dhcp6": {
    "lease-database": {
        "user": "user-name",
        "password": "1234",
        ...
    },
    ...
}

اگر گذرواژه‌ای برای حساب وجود ندارد، گذرواژه را روی یک رشتهٔ خالی "" تنظیم کنید. (این مقدار پیش‌فرض است.).SS تنظیم مهلت‌های زمانی پایگاه داده (Tuning Database Timeouts)

در موارد نادری، خواندن از پایگاه داده یا نوشتن در آن ممکن است متوقف شود (hang کند). این وضعیت می‌تواند به دلیل یک مشکل موقت شبکه یا پیکربندی نادرست سرور پراکسی باشد که اتصال را بین نمونه‌های مختلف پایگاه داده جابه‌جا می‌کند. این شرایط نادر هستند، اما کاربران گزارش کرده‌اند که Kea گاهی اوقات هنگام انجام عملیات I/O پایگاه داده معلق می‌شود. تنظیم مقادیر مهلت زمانی (timeout) مناسب می‌تواند چنین مشکلاتی را کاهش دهد.

پایگاه‌داده MySQL دو گزینه اتصال متمایز را برای پیکربندی مهلت‌های زمانی خواندن و نوشتن ارائه می‌دهد. پارامترهای پیکربندی متناظر Kea یعنی read-timeout و write-timeout این مهلت‌های زمانی را بر حسب ثانیه مشخص می‌کنند. برای مثال:

"Dhcp6": { "lease-database": { "read-timeout" : 10, "write-timeout": 20, ... }, ... }

تنظیم این پارامترها روی 0 معادل مشخص نکردن آن‌ها است و باعث می‌شود سرور Kea با مقادیر پیش‌فرض MySQL اتصالی به پایگاه داده برقرار کند. در این حالت، Kea به مدت نامحدود منتظر تکمیل عملیات خواندن و نوشتن می‌ماند.

نسخه‌های MySQL قدیمی‌تر از 5.6 از تنظیم مهلت زمانی برای عملیات خواندن و نوشتن پشتیبانی نمی‌کنند. علاوه بر این، پارامترهای read-timeout و write-timeout تنها برای بک‌اند MySQL قابل تعریف هستند؛ تنظیم آن‌ها برای هر نوع پایگاه داده بک‌اند دیگری موجب خطای پیکربندی می‌شود.

برای تنظیم مهلت زمانی بر حسب ثانیه برای PostgreSQL، از پارامتر tcp-user-timeout استفاده کنید. برای مثال:

"Dhcp6": { "lease-database": { "tcp-user-timeout" : 10, ... }, ... }

مشخص کردن این پارامتر برای سایر انواع بک‌اند باعث خطای پیکربندی می‌شود.

نکته:

مهلت‌های زمانی شرح داده شده در اینجا فقط برای اتصالات TCP مؤثر هستند. لطفاً توجه داشته باشید که کتابخانه کلاینت MySQL مورد استفاده توسط سرورهای Kea معمولاً هنگامی که پارامتر host مقدار localhost باشد از طریق سوکت دامنه یونیکس (UNIX domain socket) به پایگاه داده متصل می‌شود، اما برای 127.0.0.1 یک اتصال TCP برقرار می‌کند.

از نسخه 2.7.4 نرم‌افزار Kea به بعد، کتابخانه قلاب (hook library) به نام libdhcp_mysql.so باید بارگذاری شود تا اجاره‌ها در بک‌اند پایگاه داده اجاره MySQL ذخیره شوند. مکان کتابخانه قلاب بک‌اند اجاره را مشخص کنید:

"Dhcp6": { "hooks-libraries": [
    {
        // the MySQL lease backend hook library required for lease storage.
        "library": "libdhcp_mysql.so"
    }, ... ], ... }

از نسخه 2.7.4 نرم‌افزار Kea به بعد، کتابخانه قلاب libdhcp_pgsql.so باید بارگذاری شود تا اجاره‌ها در بک‌اند پایگاه داده اجاره PostgreSQL ذخیره شوند. مکان کتابخانه قلاب بک‌اند اجاره را مشخص کنید.

"Dhcp6": { "hooks-libraries": [
    {
        // the PostgreSQL lease backend hook library required for lease storage.
        "library": "libdhcp_pgsql.so"
    }, ... ], ... }

همچنین Kea قادر است اطلاعات مربوط به رزروهای میزبان (host reservations) را در پایگاه داده ذخیره کند. پیکربندی پایگاه داده میزبان‌ها از همان ساختار نحوی پایگاه داده اجاره‌ها استفاده می‌کند. در حقیقت، سرور Kea برای هر منظور، خواه اطلاعات اجاره باشد یا اطلاعات میزبان‌ها، اتصالات مستقلی باز می‌کند که این امر بالاترین انعطاف‌پذیری را فراهم می‌سازد. Kea می‌تواند اجاره‌ها و رزروهای میزبان را به طور جداگانه نگهداری کند، اما می‌تواند به همان پایگاه داده مشترک نیز اشاره نماید. در حال حاضر انواع پایگاه‌های داده پشتیبانی‌شده برای میزبان‌ها MySQL و PostgreSQL هستند.

پیکربندی زیر می‌تواند برای تنظیم اتصال به MySQL استفاده شود:

"Dhcp6": {
    "hosts-database": {
        "type": "mysql",
        "name": "kea",
        "user": "kea",
        "password": "1234",
        "host": "localhost",
        "port": 3306
    }
}

بسته به پیکربندی پایگاه داده، بسیاری از این پارامترها ممکن است اختیاری باشند.

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

اطلاعات میزبان می‌تواند در چندین مخزن ذخیره‌سازی قرار گیرد. عملیات‌ها روی مخازن بر اساس همان ترتیبی که در فایل پیکربندی تعریف شده‌اند انجام می‌پذیرد، هرچند این موضوع در صورت افزودن یک رزرو میزبان به محدودیتی در اولویت‌بندی منجر می‌شود؛ مخازن فقط‌خواندنی (read-only) باید حتماً بعد از یک مخزن خواندنی-نوشتنی (read-write) پیکربندی شوند، در غیر این صورت عملیات افزودن با خطا مواجه خواهد شد.

نکته:

نرم‌افزار Kea مستلزم آن است که منطقه زمانی (timezone) پایگاه داده با منطقه زمانی سیستم یکسان باشد. برای جزئیات بیشتر، به بخش‌های First-Time Creation of the MySQL Database <#mysql-database-create> و First-Time Creation of the PostgreSQL Database <#pgsql-database-create> مراجعه کنید.

پیکربندی پایگاه‌داده میزبان‌ها از طریق پارامترهای Dhcp6/hosts-database کنترل می‌شود. در صورت فعال بودن، نوع پایگاه‌داده باید بر روی mysql یا postgresql تنظیم شود.

"Dhcp6": { "hosts-database": { "type": "mysql", ... }, ... }

سپس، نام پایگاه‌داده‌ای که رزروها را نگه‌داری می‌کند باید تنظیم شود؛ این همان نامی است که هنگام ایجاد پایگاه‌داده اجاره‌ها استفاده شده است (برای دستورالعمل‌های نحوه راه‌اندازی نوع پایگاه‌داده مورد نظر، به بخش پشتیبان‌های پشتیبانی‌شده <#supported-databases> مراجعه کنید):

"Dhcp6": { "hosts-database": { "name": "database-name" , ... }, ... }

اگر پایگاه‌داده بر روی سامانه‌ای غیر از کارگزار DHCPv6 قرار دارد، نام میزبان پایگاه‌داده نیز باید مشخص شود:

"Dhcp6": { "hosts-database": { "host": remote-host-name, ... }, ... }

به طور معمول، پایگاه‌داده روی همان ماشین کارگزار DHCPv6 قرار دارد. در این حالت، مقدار را روی یک رشته خالی تنظیم کنید:

"Dhcp6": { "hosts-database": { "host" : "", ... }, ... }

در صورتی که پایگاه‌داده از درگاهی به غیر از درگاه پیش‌فرض استفاده می‌کند، می‌توان آن را نیز مشخص کرد:

"Dhcp6": { "hosts-database": { "port" : 12345, ... }, ... }

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

"Dhcp6": { "hosts-database": { "max-reconnect-tries" : number-of-tries, ... }, ... }

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

مدت‌زمانی که کارگزار بین تلاش‌ها برای اتصال مجدد به پایگاه‌داده میزبان پس از قطع اتصال منتظر می‌ماند را نیز می‌توان بر حسب میلی‌ثانیه مشخص کرد:

"Dhcp6": { "hosts-database": { "reconnect-wait-time" : number-of-milliseconds, ... }, ... }

مقدار پیش‌فرض برای MySQL و PostgreSQL برابر با 0 است که بازیابی خودکار را غیرفعال کرده و باعث می‌شود کارگزار بلافاصله پس از تشخیص قطع اتصال خارج شود.

"Dhcp6": { "hosts-database": { "on-fail" : "stop-retry-exit", ... }, ... }

مقادیر مجاز عبارتند از:

  • stop-retry-exit - سرویس DHCP را در هنگام تلاش برای بازیابی خودکار اتصالات قطع‌شده غیرفعال می‌کند. در صورت عدم موفقیت پس از اتمام max-reconnect-tries، کارگزار را خاموش می‌کند. این مقدار پیش‌فرض برای MySQL و PostgreSQL است.
  • serve-retry-exit - سرویس‌دهی DHCP را در حین تلاش برای بازیابی خودکار اتصالات قطع‌شده ادامه می‌دهد. در صورت عدم موفقیت پس از اتمام max-reconnect-tries، کارگزار را خاموش می‌کند.
  • serve-retry-continue - سرویس‌دهی DHCP را ادامه می‌دهد و حتی در صورت شکست بازیابی نیز کارگزار را خاموش نمی‌کند.

نکته:

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

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

"Dhcp6": { "hosts-database": { "retry-on-startup" : true, ... }, ... }

در زمان راه‌اندازی کارگزار، ناتوانی در اتصال به هر یک از پشتیبان‌های پیکربندی‌شده تنها در صورتی یک خطای مهلک در نظر گرفته می‌شود که retry-on-startup بر روی false (پیش‌فرض) تنظیم شده باشد. یک خطای مهلک در گزارش‌ها ثبت شده و کارگزار خارج می‌شود، بر پایه این رویکرد که پیکربندی در زمان راه‌اندازی باید معتبر باشد. خروج به سیستم‌عامل به اسکریپت‌های ناظر اجازه می‌دهد تا مشکل را تشخیص دهند. اگر retry-on-startup بر روی true تنظیم شود، کارگزار حتی هنگام راه‌اندازی یا در زمان رخدادهای بازپیکربندی نیز تلاش‌های اتصال مجدد را آغاز کرده و رفتار مشخص‌شده در پارامتر on-fail را به کار می‌بندد.

در نهایت، اعتبارنامه‌های حسابی که کارگزار با استفاده از آن به پایگاه‌داده دسترسی خواهد داشت باید مشخص شوند:

"Dhcp6": {
    "hosts-database": {
        "user": "user-name",
        "password": "1234",
        ...
    },
    ...
}

اگر حساب کاربری گذرواژه‌ای ندارد، گذرواژه را روی رشته خالی "" تنظیم کنید. (این مقدار پیش‌فرض است.)

افزونه چندذخیره‌سازی از ساختار مشابهی استفاده می‌کند؛ با این تفاوت که پیکربندی به جای یک مدخل hosts-database، درون یک فهرست hosts-databases قرار می‌گیرد، مانند:

"Dhcp6": { "hosts-databases": [ { "type": "mysql", ... }, ... ], ... }

اگر میزبانی به صورت هم‌زمان هم درون فایل و هم درون پایگاه‌داده پیکربندی شده باشد، Kea هیچ هشداری صادر نمی‌کند؛ برخلاف وضعیتی که هر دو در یک منبع داده یکسان تعریف شده باشند. در عوض، میزبانی که درون فایل پیکربندی شده است، نسبت به میزبان پیکربندی‌شده در پایگاه‌داده اولویت دارد..SS استفاده از پایگاه‌های داده فقط-خواندنی برای رزروهای میزبان با DHCPv6

در برخی استقرارها، کاربری که نام آن در پیکربندی backend پایگاه داده مشخص شده است، ممکن است دسترسی نوشتن به پایگاه داده را نداشته باشد. این موضوع اغلب بر اساس سیاست‌های درون یک شبکه برای محافظت از داده‌ها در برابر تغییرات ناخواسته الزامی است. در بسیاری از موارد مدیران سیستم پایگاه‌های داده موجودی (inventory) را مستقر کرده‌اند که حاوی اطلاعات بسیار بیشتری درباره میزبان‌ها نسبت به صرفاً رزروهای ایستا اختصاص‌یافته به آن‌ها است. از پایگاه داده موجودی می‌توان برای ایجاد یک نما (view) از پایگاه داده میزبان‌های Kea استفاده کرد و چنین نمایی اغلب به‌صورت فقط-خواندنی است.

بخش‌های backend پایگاه داده میزبان Kea با یک پیکربندی ضمنی برای خواندن و نوشتن در پایگاه داده عمل می‌کنند. اگر کاربر دسترسی نوشتن به پایگاه داده میزبان را نداشته باشد، backend در راه‌اندازی شکست می‌خورد و سرور از شروع به‌کار (یا بازپیکربندی) خودداری می‌کند. با این حال، اگر دسترسی به یک پایگاه داده میزبانِ فقط-خواندنی جهت بازیابی رزروها برای کلاینت‌ها و/یا تخصیص آدرس‌ها و گزینه‌های خاص نیاز باشد، می‌توان Kea را صراحتاً برای شروع در حالت "read-only" پیکربندی کرد. این عمل توسط پارامتر بولی readonly به صورت زیر کنترل می‌شود:

"Dhcp6": { "hosts-database": { "readonly": true, ... }, ... }

تنظیم این پارامتر روی false، پایگاه داده backend را برای کار در حالت "read-write" پیکربندی می‌کند، که در صورت تعیین نشدن پارامتر، پیکربندی پیش‌فرض نیز همین است.

نکته:

پارامتر readonly تنها برای پایگاه‌های داده MySQL و PostgreSQL پشتیبانی می‌شود.

از نسخه Kea.2.7.4، کتابخانه قلاب libdhcp_mysql.so باید بارگیری شود تا رزروهای میزبان در backend پایگاه داده میزبان MySQL ذخیره شوند. مکان کتابخانه قلاب backend اجاره (lease) را مشخص کنید:

"Dhcp6": { "hooks-libraries": [
    {
        // the MySQL host backend hook library required for host storage.
        "library": "libdhcp_mysql.so"
    }, ... ], ... }

از نسخه Kea.2.7.4، کتابخانه قلاب libdhcp_pgsql.so باید بارگیری شود تا رزروهای میزبان در backend پایگاه داده میزبان PostgreSQL ذخیره شوند. مکان کتابخانه قلاب backend اجاره را مشخص کنید.

"Dhcp6": { "hooks-libraries": [
    {
        // the PostgreSQL host backend hook library required for host storage.
        "library": "libdhcp_pgsql.so"
    }, ... ], ... }

بخش Tuning Database Timeouts را ببینید.

سرور DHCPv6 باید برای شنود روی رابط‌های شبکه مشخصی پیکربندی شود. ساده‌ترین پیکربندی رابط شبکه به سرور می‌گوید روی تمام رابط‌های در دسترس شنود کند:

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "*" ]
    },
    ...
}

نکته:

‏Kea به‌طور پیش‌فرض روی آدرس‌های عمومی IPv6 شنود نمی‌کند. برای فعال‌سازی ترافیک تک‌پخشی (unicast) بخش Unicast Traffic Support را ببینید.

نویسه ستاره نقش نویسه عمومی (wildcard) را بازی می‌کند و به معنای "شنود روی تمام رابط‌ها" است. با این حال، معمولاً بهتر است نام‌های رابط‌ها صراحتاً مشخص شوند:

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eth1", "eth3" ]
    },
    ...
}

امکان استفاده از نویسه عمومی رابط (*) به‌طور هم‌زمان با نام‌های صریح رابط‌ها وجود دارد:

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eth1", "eth3", "*" ]
    },
    ...
}

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

همانند سرور DHCPv4، اتصال به آدرس‌های خاص و غیرفعال‌سازی تشخیص مجدد رابط‌ها پشتیبانی می‌شود. اما dhcp-socket-type پشتیبانی نمی‌شود، زیرا DHCPv6 تنها از سوکت‌های UDP/IPv6 استفاده می‌کند.

رابط‌ها در هر بار پیکربندی مجدد دوباره شناسایی می‌شوند. این رفتار را می‌توان با تنظیم مقدار re-detect روی false غیرفعال کرد، برای مثال:

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eth1", "eth3" ],
        "re-detect": false
    },
    ...
}

سازوکار شناسایی مجدد معمولاً رابط‌های شناسایی‌شده قبلی را حذف کرده و سپس تمام رابط‌های شناسایی‌شده فعلی را اضافه می‌کند. توجه داشته باشید که هنگام اجرای دستورهای config-test <#std-isccmd-config-test> یا config-set <#std-isccmd-config-set> رابط‌ها دوباره شناسایی نمی‌شوند. با این حال، رابط‌های جدید شناسایی می‌شوند و برای استفاده توسط پیکربندی جدیدِ ارسال‌شده به دستورهای config-test <#std-isccmd-config-test> و config-set <#std-isccmd-config-set> در دسترس خواهند بود.

رابط‌های لوپ‌بک (مانند رابط lo یا lo0) به‌طور پیش‌فرض پیکربندی نمی‌شوند، مگر اینکه صراحتاً در پیکربندی ذکر شوند. توجه داشته باشید که Kea به یک آدرس پیوند-محلی (link-local) (که در همه سیستم‌ها وجود ندارد) یا یک آدرس مشخص تک‌پخشی (unicast) نیاز دارد، مانند:

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "enp0s2/2001:db8::1234:abcd" ]
    },
    ...
}

‏Kea در هنگام راه‌اندازی، سوکت‌های سرویس را برای هر رابط مقیدسازی (bind) می‌کند. اگر فرایند دیگری قبلاً از یک درگاه (port) استفاده کرده باشد، Kea پیام را در لاگ ثبت کرده و از بروز خطا جلوگیری می‌کند. سرویس DHCP اجرا می‌شود، اما روی برخی رابط‌ها در دسترس نخواهد بود.

گزینه "service-sockets-require-all" باعث می‌شود Kea نیاز داشته باشد که تمام سوکت‌ها با موفقیت مقید شوند. اگر باز کردن هر سوکتی با شکست مواجه شود، Kea فرایند مقداردهی اولیه را قطع کرده و با یک وضعیت غیرصفر خارج می‌شود. (پیش‌فرض false است).

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eth1", "eth3" ],
        "service-sockets-require-all": true
    },
    ...
}

گاهی اوقات، قطع فوری فرایند انتخاب مناسبی نیست. درگاه ممکن است تنها موقتاً در دسترس نباشد. در این حالت، تلاش مجدد برای باز کردن ممکن است مشکل را حل کند. Kea دو گزینه را برای تعیین تلاش مجدد فراهم می‌کند: service-sockets-max-retries و service-sockets-retry-wait-time.

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

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

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eth1", "eth3" ],
        "service-sockets-max-retries": 5,
        "service-sockets-retry-wait-time": 5000
    },
    ...
}

اگر "service-sockets-max-retries" غیرصفر باشد و "service-sockets-require-all" برابر با false باشد، آن‌گاه Kea باز کردن را (در صورت نیاز) دوباره تلاش می‌کند اما در صورتی که هر سوکتی همچنان باز نشده باشد با شکست مواجه نمی‌شود..SS شناسه زیرشبکه IPv6 (IPv6 Subnet Identifier)

شناسه زیرشبکه (subnet ID) عددی یکتا است که به یک زیرشبکه خاص اختصاص می‌یابد. در اصل، این شناسه برای مرتبط ساختن اجاره‌های (leases) کارخواه‌ها با زیرشبکه‌های مربوطه‌شان به کار می‌رود. پیکربندی کارساز باید شامل شناسه‌های یکتا و پایداری برای تمام زیرشبکه‌ها باشد.

نکته:

شناسه‌های زیرشبکه باید بزرگ‌تر از صفر و کوچک‌تر از 4294967295 باشند.

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

"Dhcp6": {
    "subnet6": [
        {
            "subnet": "2001:db8:1::/64",
            "id": 1024,
            ...
        }
    ]
}

پیشوند زیرشبکه (subnet prefix) روش دوم برای شناسایی یک زیرشبکه است. Kea می‌تواند نشانی‌های غیرمتعارف (non-canonical) زیرشبکه را نیز بپذیرد؛ برای نمونه، این پیکربندی پذیرفته می‌شود:

"Dhcp6": {
   "subnet6": [
       {
            "subnet": "2001:db8:1::1/64",
            ...
       }
    ]
}

این حالت حتی در صورتی که زیرشبکه دیگری با پیشوند "2001:db8:1::/64" وجود داشته باشد کار می‌کند؛ جهت جلوگیری از موارد تکراری، تنها شکل متنی زیرشبکه‌ها مقایسه می‌شوند.

نکته:

استفاده نادرست از این قابلیت می‌تواند به انتخاب نادرست زیرشبکه منجر شود (به «انتخاب زیرشبکه IPv6» مراجعه کنید).

هنگامی که کارساز DHCPv6 راه‌اندازی می‌شود، به‌طور پیش‌فرض به ترافیک DHCP ارسال‌شده به نشانی چندپخشی (multicast) ff02::1:2 بر روی هر رابطی که برای شنود پیکربندی شده باشد گوش می‌دهد (به «پیکربندی رابط» مراجعه کنید). در برخی موارد مفید است که کارساز را طوری پیکربندی کرد که ترافیک ورودی ارسال‌شده به نشانی‌های تک‌پخشی سراسری (global unicast) را نیز مدیریت کند؛ رایج‌ترین دلیل برای این کار، ارسال مستقیم ترافیک توسط بازپخش‌کننده‌ها (relays) به کارساز است. برای پیکربندی کارساز جهت شنود روی یک نشانی تک‌پخشی مشخص، یک اسلش (/) پس از نام رابط اضافه کنید و سپس نشانی تک‌پخشی سراسری را که کارساز باید روی آن گوش دهد بیاورید. کارساز علاوه‌بر مقیدسازی (binding) عادی محلی پیوند (link-local) و شنود روی نشانی ff02::1:2، روی این نشانی نیز گوش خواهد داد. نمونه پیکربندی زیر نشان می‌دهد چگونه می‌توان روی نشانی 2001:db8::1 (یک نشانی سراسری) پیکربندی‌شده روی رابط eth1 شنود کرد.

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eth1/2001:db8::1" ]
    },
    "option-data": [
        {
            "name": "unicast",
            "data": "2001:db8::1"
        } ],
    ...
}

این پیکربندی باعث می‌شود که کارساز روی رابط eth1 بر روی نشانی link-local، گروه چندپخشی (ff02::1:2)، و 2001:db8::1 گوش دهد.

معمولاً پشتیبانی از تک‌پخشی با گزینه تک‌پخشی کارساز (server unicast option) همراه است که به کارخواه‌ها اجازه می‌دهد پیام‌های تک‌پخشی را به کارساز ارسال کنند.

نکته:

گزینه تک‌پخشی توسط RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 منسوخ شده است؛ تلاش برای افزودن آن به پاسخ‌ها هشداری را ایجاد می‌کند و کارساز دیگر پرس‌وجوهای مستقیم تک‌پخشی را (در مقایسه با پرس‌وجوهای بازپخش‌شده تک‌پخشی) نمی‌پذیرد.

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

امکان ترکیب نام‌های رابط، نویسه‌های عام (wildcards)، و جفت‌های «نام رابط/نشانی» در فهرست رابط‌ها وجود دارد. با این حال، مشخص کردن بیش از یک نشانی تک‌پخشی روی یک رابط معین امکان‌پذیر نیست.

باید در مشخص کردن نشانی‌های تک‌پخشی مناسب دقت شود، زیرا کارساز بدون هیچ‌گونه بررسی اضافی، برای مقیدسازی (bind) به نشانی‌های مشخص‌شده تلاش خواهد کرد. این رویکرد عمداً انتخاب شده است تا نرم‌افزار در صورت تمایل بتواند از طریق نشانی‌های نامتعارف نیز ارتباط برقرار کند..SS پیکربندی استخرهای نشانی IPv6

نقش اصلی یک کارگزار DHCPv6، تخصیص نشانی است. بدین منظور، کارگزار باید دست‌کم با یک زیرشبکه و یک استخر از نشانی‌های پویا برای مدیریت پیکربندی شود. برای نمونه، فرض کنید کارگزار به یک بخش از شبکه متصل است که از پیشوند 2001:db8:1::/64 استفاده می‌کند. مدیر آن شبکه تصمیم می‌گیرد که نشانی‌های بازهٔ 2001:db8:1::1 تا 2001:db8:1::ffff توسط کارگزار DHCPv6 مدیریت شوند. چنین پیکربندی‌ای را می‌توان به روش زیر انجام داد:

"Dhcp6": {
    "subnet6": [
       {
           "subnet": "2001:db8:1::/64",
           "pools": [
               {
                   "pool": "2001:db8:1::1-2001:db8:1::ffff"
               }
           ],
           ...
       }
    ]
}

توجه داشته باشید که subnet به صورت یک رشتهٔ ساده تعریف می‌شود، اما پارامتر pools در واقع فهرستی از استخرها است؛ به همین دلیل، تعریف استخر درون قلاب‌ها (کروشه‌ها) قرار می‌گیرد، حتی اگر فقط یک بازه از نشانی‌ها مشخص شده باشد.

هر pool ساختاری است که پارامترهای توصیف‌کنندهٔ یک استخر مجزا را در بر دارد. در حال حاضر فقط یک پارامتر وجود دارد، pool، که بازهٔ نشانی‌های موجود در استخر را تعیین می‌کند.

امکان تعریف بیش از یک استخر در یک زیرشبکه وجود دارد؛ در ادامهٔ مثال پیشین، همچنین فرض کنید 2001:db8:1:0:5::/80 نیز باید توسط کارگزار مدیریت شود. این را می‌توان به صورت 2001:db8:1:0:5:: تا 2001:db8:1::5:ffff:ffff:ffff نوشت، اما تایپ این همه نویسهٔ f دشوار و طاقت‌فرسا است. این استخر می‌تواند ساده‌تر به صورت 2001:db8:1:0:5::/80 بیان شود. هر دو قالب توسط Dhcp6 پشتیبانی می‌شوند و می‌توان آن‌ها را در فهرست استخرها با یکدیگر ترکیب کرد. برای نمونه، استخرهای زیر را می‌توان تعریف کرد:

"Dhcp6": {
    "subnet6": [
    {
        "subnet": "2001:db8:1::/64",
        "pools": [
            { "pool": "2001:db8:1::1-2001:db8:1::ffff" },
            { "pool": "2001:db8:1:05::/80" }
        ],
        ...
    }
    ]
}

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

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

کارگزار ممکن است طوری پیکربندی شود که به بیش از یک زیرشبکه سرویس‌دهی کند. برای افزودن زیرشبکهٔ دوم، از دستوری مشابه زیر استفاده کنید:

"Dhcp6": {
    "subnet6": [
    {
        "id": 1,
        "subnet": "2001:db8:1::/64",
        "pools": [
            { "pool": "2001:db8:1::1-2001:db8:1::ffff" }
        ]
    },
    {
        "id": 2,
        "subnet": "2001:db8:2::/64",
        "pools": [
            { "pool": "2001:db8:2::/64" }
        ]
    },
    ...
    ]
}

در این مثال، ما به کارگزار اجازه می‌دهیم تمام نشانی‌های موجود در کل زیرشبکه را به صورت پویا تخصیص دهد. گرچه تا حدی اسراف‌آمیز است، اما اختصاص دادن کل زیرشبکهٔ /64 برای این منظور مسلماً یک پیکربندی معتبر است. توجه داشته باشید که کارگزار Kea اجاره‌ها را از پیش تخصیص نمی‌دهد، بنابراین خطری در استفاده از استخرهای نشانی غول‌پیکر وجود ندارد.

هنگام پیکربندی یک کارگزار DHCPv6 با استفاده از نمادگذاری پیشوند/طول (prefix/length)، لطفاً به مقادیر مرزی دقت کنید. وقتی مشخص می‌کنید که کارگزار می‌تواند از یک استخر داده‌شده استفاده کند، این کارگزار قادر است اولین نشانی (که معمولاً یک نشانی شبکه است) را نیز از آن استخر تخصیص دهد. برای نمونه، برای استخر 2001:db8:2::/64، ممکن است نشانی 2001:db8:2:: نیز اختصاص یابد. برای جلوگیری از این امر، از نمادگذاری min-max استفاده کنید.

زیرشبکه‌ها همچنین می‌توانند برای تفویض پیشوندها پیکربندی شوند، همان‌گونه که در بخش 6.3 از RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 تعریف شده است. یک زیرشبکه می‌تواند یک یا چند استخر تفویض پیشوند داشته باشد. هر استخر دارای یک نشانی پیشوندی است که به عنوان یک پیشوند (prefix) و یک طول پیشوند (prefix-len)، به همراه طول پیشوند تفویض‌شده (delegated-len) مشخص می‌شود. طول تفویض‌شده نباید کوتاه‌تر از طول پیشوند باشد (یعنی باید از نظر عددی بزرگ‌تر یا مساوی با آن باشد). اگر هر دو طول تفویض‌شده و پیشوند برابر باشند، کارگزار تنها قادر به تفویض یک پیشوند خواهد بود. پیشوند تفویض‌شده الزامی ندارد که با پیشوند زیرشبکه یکسان باشد.

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

"Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:d8b:1::/64",
            "pd-pools": [
                {
                    "prefix": "3000:1::",
                    "prefix-len": 64,
                    "delegated-len": 96
                }
            ]
        }
    ],
    ...
}

برای هر پیشوند واگذارشده (delegated prefix)، روتر واگذارکننده می‌تواند طبق مشخصات RFC 6603 https://datatracker.ietf.org/doc/html/rfc6603 تصمیم بگیرد که یک پیشوند منفرد را از پیشوند واگذارشده استثنا کند. روتر درخواست‌کننده نباید پیشوند مستثناشده را به هیچ‌یک از رابط‌های دست‌پایین (downstream interfaces) خود اختصاص دهد. پیشوند مستثناشده با این هدف در نظر گرفته شده است که روی پیوندی استفاده شود که روتر واگذارکننده از طریق آن پیام‌های DHCPv6 را با روتر درخواست‌کننده تبادل می‌کند. نمونه پیکربندی زیر نحوه مشخص کردن یک پیشوند مستثناشده در تعاریف استخر پیشوند (prefix pool) را نشان می‌دهد. پیشوند مستثناشدهٔ 2001:db8:1:8000:cafe:80::/72 به روتر درخواست‌کننده‌ای ارسال خواهد شد که گزینه Prefix Exclude را در گزینه درخواست گزینه (ORO یا Option Request option) قرار داده باشد و پیشوندی از این استخر به آن واگذار شده باشد.

"Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/48",
            "pd-pools": [
                {
                    "prefix": "2001:db8:1:8000::",
                    "prefix-len": 56,
                    "delegated-len": 64,
                    "excluded-prefix": "2001:db8:1:8000:cafe:80::",
                    "excluded-prefix-len": 72
                }
            ]
        }
    ]
}

نکته:

در اینجا برخی آزادی‌عمل‌ها و محدودیت‌ها برای مقادیری که زیرشبکه‌ها و استخرها می‌توانند در پیکربندی‌های Kea فراتر از حالت معمول داشته باشند آورده شده است:
مورد پیکربندی Kea مجاز توضیح
زیرشبکه‌های هم‌پوشان بله مدیر سیستم باید به چگونگی تطبیق کلاینت‌ها با این زیرشبکه‌ها توجه داشته باشد.
استخرهای آدرس هم‌پوشان در یک زیرشبکه خیر خطای راه‌اندازی: DHCP6_PARSER_FAIL
استخرهای آدرس هم‌پوشان در زیرشبکه‌های مختلف بله مشخص کردن یک استخر آدرس یکسان در زیرشبکه‌های مختلف می‌تواند به عنوان معادل استخر آدرس سراسری (global address pool) استفاده شود. در این حالت، سرور می‌تواند فارغ از زیرشبکه کلاینت، آدرس‌ها را از همان محدوده تخصیص دهد. اگر آدرسی از چنین استخری به کلاینتی در یک زیرشبکه اختصاص یابد، در صورت انتقال کلاینت به زیرشبکه‌ای دیگر، همان آدرس برای این کلاینت تمدید خواهد شد. به کلاینت دیگری در یک زیرشبکه متفاوت، آدرسی که پیش‌تر به این کلاینت در هر یک از زیرشبکه‌ها اختصاص یافته است، داده نخواهد شد.
استخرهای آدرسی که خارج از زیرشبکه تعریف‌شده خود هستند خیر خطای راه‌اندازی: DHCP6_PARSER_FAIL
استخرهای واگذاری پیشوند هم‌پوشان در یک زیرشبکه خیر خطای راه‌اندازی: DHCP6_PARSER_FAIL
استخرهای واگذاری پیشوند هم‌پوشان در زیرشبکه‌های مختلف بله مشخص کردن یک استخر واگذاری پیشوند یکسان در زیرشبکه‌های مختلف می‌تواند به عنوان معادل استخر سراسری به کار رود. در این حالت، سرور می‌تواند صرف‌نظر از زیرشبکه کلاینت، همان پیشوندها را واگذار کند. اگر پیشوندی از چنین استخری به کلاینتی در یک زیرشبکه واگذار شود، در صورت جابجایی کلاینت به زیرشبکه‌ای دیگر، همان پیشوند برای این کلاینت تمدید خواهد شد. به کلاینت دیگری در یک زیرشبکه متفاوت، پیشوندی که پیش‌تر به این کلاینت در هر یک از زیرشبکه‌ها واگذار شده است، داده نخواهد شد.
استخرهای واگذاری پیشوندی که با پیشوند زیرشبکه مطابقت ندارند بله در بسیاری از پیاده‌سازی‌ها پیکربندی استخرهای واگذاری پیشوند به‌صورتی که با پیشوند زیرشبکه مطابقت نداشته باشند رایج است؛ مانند یک استخر پیشوند 3000::/96 درون زیرشبکه 2001:db8:1::/64. چنین مواردی توسط سرور Kea DHCPv6 پشتیبانی می‌شوند.

یکی از ویژگی‌های اصلی کارساز DHCPv6، توانایی ارائه گزینه‌های پیکربندی به کلاینت‌ها است. با اینکه گزینه‌های متعددی وجود دارند که نیازمند رفتار خاصی هستند، اکثر گزینه‌ها تنها در صورتی توسط کارساز ارسال می‌شوند که کلاینت صراحتاً آن‌ها را درخواست کرده باشد. مثال زیر نحوه پیکربندی نشانی‌های کارسازهای DNS را نشان می‌دهد که یکی از پرکاربردترین گزینه‌ها است. گزینه‌هایی که به این صورت مشخص می‌شوند سراسری (global) تلقی شده و برای تمام زیرشبکه‌های پیکربندی‌شده اعمال می‌گردند.

"Dhcp6": {
    "option-data": [
        {
           "name": "dns-servers",
           "code": 23,
           "space": "dhcp6",
           "csv-format": true,
           "data": "2001:db8::cafe, 2001:db8::babe"
        },
        ...
    ]
}

خط option-data یک مدخل جدید در جدول option-data ایجاد می‌کند. این جدول حاوی اطلاعات مربوط به تمام گزینه‌های سراسری است که کارساز باید در تمام زیرشبکه‌ها پیکربندی کند. خط name نام گزینه را مشخص می‌کند. (برای مشاهده فهرست کامل نام‌های پشتیبانی‌شده کنونی، بخش «List of standard DHCPv6 options configurable by an administrator» را ببینید.) خط بعدی کد گزینه را مشخص می‌کند که باید با یکی از مقادیر آن فهرست مطابقت داشته باشد. خطی که با space شروع می‌شود فضای گزینه را تعیین می‌کند که همواره باید روی dhcp6 تنظیم شود، چرا که این‌ها گزینه‌های استاندارد DHCPv6 هستند. برای سایر فضاهای نام، از جمله فضاهای گزینه سفارشی، بخش «Nested DHCPv6 Options (Custom Option Spaces)» را ببینید. خط بعدی قالبی را که داده‌ها در آن وارد می‌شوند مشخص می‌کند؛ استفاده از CSV (مقادیر جداشده با کاما) توصیه می‌شود. در نهایت، خط data مقدار واقعی ارسال‌شونده به کلاینت‌ها را مشخص می‌سازد. پارامتر data به صورت متن معمولی مشخص می‌شود و در صورتی که بیش از یک مقدار مجاز باشد، مقادیر با کاما از هم جدا می‌شوند.

گزینه‌ها را می‌توان به صورت مقادیر هگزادسیمال نیز پیکربندی کرد. اگر csv-format روی false تنظیم شده باشد، داده‌های گزینه باید به عنوان یک رشته هگزادسیمال مشخص شوند. دستورات زیر گزینه dns-servers را برای تمام زیرشبکه‌ها با نشانی‌های 2001:db8:1::cafe و 2001:db8:1::babe پیکربندی می‌کنند.

"Dhcp6": {
    "option-data": [
        {
           "name": "dns-servers",
           "code": 23,
           "space": "dhcp6",
           "csv-format": false,
           "data": "20 01 0D B8 00 01 00 00 00 00 00 00 00 00 CA FE \
                    20 01 0D B8 00 01 00 00 00 00 00 00 00 00 BA BE"
        },
        ...
    ]
}

نکته:

مقدار تنظیم‌شده برای عنصر data در این مثال برای وضوح بیشتر در دو خط شکسته شده است؛ هنگام وارد کردن دستور، کل رشته باید در یک خط وارد شود.

Kea هنگام مشخص کردن داده‌های هگزادسیمال از قالب‌های زیر پشتیبانی می‌کند:

  • اکتت‌های جداشده (Delimited octets) - یک یا چند اکتت که با دو‌نقطه یا فاصله (":" یا " ") از یکدیگر جدا شده‌اند. اگرچه هر اکتت می‌تواند شامل یک یا دو رقم باشد، اکیداً توصیه می‌کنیم همواره از دو رقم استفاده کنید. مثال‌های معتبر عبارتند از "ab:cd:ef" و "ab cd ef".
  • رشته‌ای از ارقام (String of digits) - یک رشته پیوسته از ارقام هگزادسیمال همراه با پیشوند "0x" یا بدون آن. مثال‌های معتبر عبارتند از "0xabcdef" و "abcdef".

هنگام استفاده از قالب هگزادسیمال باید دقت شود که کدگذاری مناسب به کار رود؛ توانایی Kea در اعتبارسنجی صحت داده‌ها در قالب هگزادسیمال محدود است.

همچنین می‌توان داده‌های گزینه‌های باینری را به صورت یک رشته متنی محصور در نقل‌قول تکی (single-quoted) درون نقل‌قول جفت (double quotes) مشخص کرد، همان‌طور که نشان داده شده است (توجه داشته باشید که csv-format باید روی false تنظیم شود):

"Dhcp6": {
    "option-data": [
        {
            "name": "subscriber-id",
            "code": 38,
            "space": "dhcp6",
            "csv-format": false,
            "data": "'convert this text to binary'"
        },
        ...
    ],
    ...
}

بسیاری از پارامترها در ساختار option-data اختیاری هستند و در برخی شرایط می‌توان آن‌ها را حذف کرد، همان‌طور که در «Unspecified Parameters for DHCPv6 Option Configuration» بحث شده است. تنها یکی از دو مورد name یا code الزامی است؛ نیازی به مشخص کردن هر دوی آن‌ها نیست. مقدار پیش‌فرض Space برابر با dhcp6 است، بنابراین اگر یک گزینه معمولی (غیر کپسوله‌شده) DHCPv6 تعریف شود، می‌توان از این مورد نیز صرف‌نظر کرد. در نهایت، مقدار پیش‌فرض csv-format برابر با true است، بنابراین از آن هم می‌توان صرف‌نظر کرد مگر اینکه مقدار گزینه به صورت رشته هگزادسیمال (hexstring) مشخص شده باشد. در نتیجه، مثال بالا را می‌توان به این صورت ساده‌سازی کرد:

"Dhcp6": {
    "option-data": [
        {
           "name": "dns-servers",
           "data": "2001:db8::cafe, 2001:db8::babe"
        },
        ...
    ]
}

گزینه‌های تعریف‌شده در صورتی که کلاینت آن‌ها را درخواست کند، به همراه تمام گزینه‌های الزامی در پروتکل، به پاسخ اضافه می‌شوند. مدیر سیستم همچنین می‌تواند مشخص کند که یک گزینه همواره ارسال شود، حتی اگر کلاینت به طور مشخص آن را درخواست نکرده باشد. برای اجبار به افزودن یک گزینه خاص، پرچم always-send را روی true تنظیم کنید، مانند:

"Dhcp6": {
    "option-data": [
        {
           "name": "dns-servers",
           "data": "2001:db8::cafe, 2001:db8::babe",
           "always-send": true
        },
        ...
    ]
}

اثر این کار همانند آن است که کلاینت کد گزینه را در Option Request Option (یا معادل آن برای گزینه‌های vendor) اضافه کرده باشد، مانند:

"Dhcp6": {
    "option-data": [
        {
           "name": "dns-servers",
           "data": "2001:db8::cafe, 2001:db8::babe",
           "always-send": true
        },
        ...
    ],
    "subnet6": [
        {
           "subnet": "2001:db8:1::/64",
           "option-data": [
               {
                   "name": "dns-servers",
                   "data": "2001:db8:1::cafe, 2001:db8:1::babe"
               },
               ...
           ],
           ...
        },
        ...
    ],
    ...
}

در مثال بالا، گزینه dns-servers از پرچم سراسری always-send تبعیت کرده و همواره به پاسخ‌ها اضافه می‌شود، اما برای زیرشبکه 2001:db8:1::/64، مقدار آن از مشخصات داده‌های گزینه در سطح زیرشبکه دریافت می‌شود.

برخلاف always-send، اگر پرچم never-send برای یک گزینه خاص روی true تنظیم شود، کارساز آن را به پاسخ اضافه نمی‌کند. اثر این کار مانند آن است که کلاینت کد گزینه را از Option Request Option (یا معادل آن برای گزینه‌های vendor) حذف کرده باشد:

"Dhcp6": {
    "option-data": [
        {
           "name": "dns-servers",
           "data": "2001:db8::cafe, 2001:db8::babe"
        },
        ...
    ],
    "subnet6": [
        {
           "subnet": "2001:db8:1::/64",
           "option-data": [
               {
                   "name": "dns-servers",
                   "never-send": true
               },
               ...
           ],
           ...
        },
        ...
    ],
    ...
}

در مثال بالا، گزینه dns-server هرگز به پاسخ‌ها در زیرشبکه 2001:db8:1::/64 اضافه نمی‌شود. never-send بر always-send اولویت دارد، بنابراین اگر هر دو روی true تنظیم شده باشند، گزینه اضافه نخواهد شد.

نکته:

پرچم‌های always-send و never-send چسبنده (sticky) هستند، بدین معنا که از قواعد معمول توارث پیکربندی پیروی نمی‌کنند. در عوض، اگر حداقل یک بار در طول زنجیره توارث پیکربندی فعال شوند، اعمال می‌گردند - حتی اگر در بخش‌های دیگری که معمولاً اولویت بالاتری دریافت می‌کنند غیرفعال شده باشند. برای نمونه، اگر یکی از این پرچم‌ها در دامنه سراسری فعال شده باشد اما در سطح زیرشبکه غیرفعال شود، صرف‌نظر از تنظیمات سطح زیرشبکه فعال در نظر گرفته می‌شود.

نکته:

پرچم never-send نسبت به libdhcp_flex_option.so <#std-ischooklib-libdhcp_flex_option.so> قدرت کمتری دارد؛ به عنوان مثال، بر گزینه‌هایی که توسط خود کارساز مدیریت می‌شوند هیچ تاثیری ندارد. هر دو پرچم always-send و never-send بر گزینه‌هایی که قابل درخواست نیستند، مانند گزینه‌های یک فضای سفارشی، بی‌تاثیر هستند.

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

دستورات زیر گزینه سراسری dns-servers را برای یک زیرشبکه خاص بازنویسی کرده و یک کارساز DNS منفرد با نشانی 2001:db8:1::3 تنظیم می‌کنند.

"Dhcp6": {
    "subnet6": [
        {
            "option-data": [
                {
                    "name": "dns-servers",
                    "code": 23,
                    "space": "dhcp6",
                    "csv-format": true,
                    "data": "2001:db8:1::3"
                },
                ...
            ],
            ...
        },
        ...
    ],
    ...
}

در برخی شرایط، اختصاص دادن برخی گزینه‌ها به یک استخر (pool) نشانی یا پیشوند که کلاینت اجاره (lease) خود را از آن دریافت می‌کند سودمند است. مقادیر گزینه‌های مختص استخر، مقادیر گزینه‌های مختص زیرشبکه و سراسری را بازنویسی می‌کنند. اگر کلاینت چندین اجاره از استخرهای مختلف دریافت کند، کارساز گزینه‌ها را از تمامی استخرهایی که اجاره‌ها از آن‌ها به دست آمده‌اند اختصاص می‌دهد. با این وجود، چنانچه گزینه خاصی در چندین استخر که کلاینت از آن‌ها اجاره می‌گیرد مشخص شده باشد، تنها یک نمونه از این گزینه به کلاینت تحویل داده می‌شود. مدیر کارساز نباید تلاش کند با تغییر ترتیب تعریف استخرها در پیکربندی کارساز، اقدام به اولویت‌بندی در تخصیص گزینه‌های مختص استخر نماید.

قطعه پیکربندی زیر نشان می‌دهد چگونه می‌توان گزینه dns-servers را مشخص کرد تا تنها در صورتی که کلاینت نشانی خود را از استخر داده‌شده به دست آورد، به آن اختصاص یابد:

"Dhcp6": {
    "subnet6": [
        {
            "pools": [
                {
                    "pool": "2001:db8:1::100-2001:db8:1::300",
                    "option-data": [
                        {
                            "name": "dns-servers",
                            "data": "2001:db8:1::10"
                        }
                    ]
                }
            ]
        },
        ...
    ],
    ...
}

گزینه‌ها را می‌توان در دامنه کلاس یا رزرو میزبان (host-reservation) نیز مشخص کرد. ترتیب اولویت گزینه‌ها در Kea در حال حاضر (از بیشترین اولویت به کمترین) به شرح زیر است: رزرو میزبان، استخر (pool)، زیرشبکه (subnet)، شبکه مشترک (shared network)، کلاس (class)، سراسری (global).

نکته:

از نسخه 2.7.4 نرم‌افزار Kea به بعد، گنجاندن گزینه‌ها را می‌توان از طریق برچسب‌گذاری کلاس گزینه (option class-tagging) نیز کنترل کرد؛ بخش «Option Class-Tagging» <#option-class-tagging> را ببینید.

زمانی که یک فیلد داده به صورت رشته باشد و آن رشته حاوی نویسه کاما (,؛ U+002C) باشد، کاما باید با دو بک‌اسلش گریز داده شود (\\,؛ U+005C). این گریز دوگانه از این رو الزامی است که هم روال جداسازی داده‌های CSV به فیلدها و هم ساختار JSON از نویسه گریز یکسانی استفاده می‌کنند؛ یک تک‌گریز (\,) ساختار JSON را نامعتبر خواهد کرد. برای مثال، رشته "EST5EDT4,M3.2.0/02:00,M11.1.0/02:00" باید به صورت زیر نمایش داده شود:

"Dhcp6": {
    "subnet6": [
        {
            "pools": [
                {
                    "option-data": [
                        {
                            "name": "new-posix-timezone",
                            "data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00"
                        }
                    ]
                },
                ...
            ],
            ...
        },
        ...
    ],
    ...
}

برخی گزینه‌ها به عنوان آرایه تعیین شده‌اند، به این معنی که بیش از یک مقدار برای آن‌ها مجاز است. به عنوان مثال، گزینه dns-servers امکان تعیین بیش از یک نشانی IPv6 را فراهم می‌سازد که به کلاینت‌ها اجازه می‌دهد نشانی‌های چندین کارساز DNS را به دست آورند.

بخش «Custom DHCPv6 Options» نحو (syntax) پیکربندی را جهت ایجاد تعاریف (قالب‌های) گزینه‌های سفارشی شرح می‌دهد. ایجاد تعاریف سفارشی برای گزینه‌های استاندارد عموماً مجاز نیست، حتی اگر تعریف در حال ایجاد دقیقاً با قالب گزینه تعریف‌شده در RFCها مطابقت داشته باشد. با این حال، یک استثنا برای این قاعده در مورد گزینه‌های استانداردی وجود دارد که Kea در حال حاضر تعریفی برای آن‌ها ارائه نمی‌دهد. برای استفاده از چنین گزینه‌هایی، مدیر کارساز باید همان‌طور که در «Custom DHCPv6 Options» شرح داده شده است، تعریفی در فضای گزینه dhcp6 ایجاد کند. این تعریف باید با قالب گزینه شرح داده شده در RFC مربوطه مطابقت داشته باشد، اما سازوکار پیکربندی هر قالب گزینه‌ای را مجاز می‌داند زیرا در حال حاضر روشی برای اعتبارسنجی آن وجود ندارد.

گزینه‌های استاندارد DHCPv6 که در حال حاضر پشتیبانی می‌شوند در جدول زیر فهرست شده‌اند. مقادیر "Name" و "Code" مقادیری هستند که باید به عنوان name/code در ساختارهای option-data استفاده شوند. "Type" قالب داده‌ها را مشخص می‌سازد؛ معانی انواع مختلف در «List of standard DHCP option types» <#dhcp-types> ارائه شده است..SS فهرست گزینه‌های استاندارد DHCPv6 قابل پیکربندی توسط مدیر سیستم

نام کد نوع آرایه؟
preference 7 uint8 false
unicast 12 ipv6-address false
sip-server-dns 21 fqdn true
sip-server-addr 22 ipv6-address true
dns-servers 23 ipv6-address true
domain-search 24 fqdn true
nis-servers 27 ipv6-address true
nisp-servers 28 ipv6-address true
nis-domain-name 29 fqdn true
nisp-domain-name 30 fqdn true
sntp-servers 31 ipv6-address true
information-refresh-time 32 uint32 false
bcmcs-server-dns 33 fqdn true
bcmcs-server-addr 34 ipv6-address true
geoconf-civic 36 record (uint8, uint16, binary) false
remote-id 37 record (uint32, binary) false
subscriber-id 38 binary false
client-fqdn 39 record (uint8, fqdn) false
pana-agent 40 ipv6-address true
new-posix-timezone 41 string false
new-tzdb-timezone 42 string false
ero 43 uint16 true
lq-query (1) 44 record (uint8, ipv6-address) false
client-data (1) 45 empty false
clt-time (1) 46 uint32 false
lq-relay-data (1) 47 record (ipv6-address, binary) false
lq-client-link (1) 48 ipv6-address true
v6-lost 51 fqdn false
capwap-ac-v6 52 ipv6-address true
relay-id 53 binary false
ntp-server 56 empty false
v6-access-domain 57 fqdn false
sip-ua-cs-list 58 fqdn true
bootfile-url 59 string false
bootfile-param 60 tuple true
client-arch-type 61 uint16 true
nii 62 record (uint8, uint8, uint8) false
aftr-name 64 fqdn false
erp-local-domain-name 65 fqdn false
rsoo 66 empty false
pd-exclude 67 binary false
rdnss-selection 74 record (ipv6-address, uint8, fqdn) true
client-linklayer-addr 79 binary false
link-address 80 ipv6-address false
solmax-rt 82 uint32 false
inf-max-rt 83 uint32 false
dhcp4o6-server-addr 88 ipv6-address true
s46-rule 89 record (uint8, uint8, uint8, ipv4-address, ipv6-prefix) false
s46-br 90 ipv6-address false
s46-dmr 91 ipv6-prefix false
s46-v4v6bind 92 record (ipv4-address, ipv6-prefix) false
s46-portparams 93 record(uint8, psid) false
s46-cont-mape 94 empty false
s46-cont-mapt 95 empty false
s46-cont-lw 96 empty false
v6-captive-portal 103 string false
v6-sztp-redirect 136 tuple true
ipv6-address-andsf 143 ipv6-address true
v6-dnr 144 record (uint16, uint16, fqdn, binary) false
addr-reg-enable 148 empty false

می‌توانید نمونه‌ای از چگونگی پیکربندی این گزینه‌ها را در kea6/all-options.json <#config-example-kea6-all-options-json> مشاهده کنید.

گزینهٔ unicast توسط RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 منسوخ شده است؛ این گزینه همچنان پشتیبانی می‌شود اما نباید استفاده شود و در نگارش‌های بعدی Kea حذف خواهد شد.

گزینه‌های مشخص‌شده با (1) دارای تعاریف گزینه هستند، اما منطق پردازشیِ پشت آن‌ها پیاده‌سازی نشده است. این بدان معناست که از نظر فنی، Kea می‌داند چگونه آن‌ها را در پیام‌های دریافتی تجزیه کند یا در صورت پیکربندی، چگونه ارسالشان نماید، اما نمی‌داند باید با آن‌ها چه کار کند. از آنجا که RFCهای مربوطه نیازمند پردازش‌های ویژه‌ای هستند، پشتیبانی از این گزینه‌ها غیرعملیاتی (non-functional) است. با این حال، ممکن است در برخی آزمون‌های محدود آزمایشگاهی مفید باشد؛ از این رو ساختار تعاریف آن‌ها در اینجا فهرست شده است.

پیکربندی برخی گزینه‌ها نسبت به گزینه‌های دیگر پیچیده‌تر است. به‌ویژه، خانوادهٔ گزینه‌های Softwire46 و Discovery of Network-designated Resolvers (DNR) در بخش‌های جداگانه‌ای در ادامه بررسی شده‌اند.

Kea از گزینه‌های بیشتری نسبت به موارد فهرست‌شده در بالا پشتیبانی می‌کند. فهرست زیر بیشتر برای خوانندگانی مفید است که می‌خواهند بدانند آیا Kea قادر به پشتیبانی از گزینه‌های خاصی هست یا خیر. گزینه‌های زیر توسط خود موتور Kea بازگردانده می‌شوند و به‌طور کلی نباید به‌صورت دستی پیکربندی شوند..SS فهرست گزینه‌های استاندارد DHCPv6 که به‌طور خودکار توسط Kea مدیریت شده و مستقیماً توسط مدیر سیستم قابل پیکربندی نیستند

نام کد توضیحات
client-id 1 توسط کلاینت ارسال می‌شود؛ Kea از آن برای تمایز میان کلاینت‌ها استفاده می‌کند.
server-id 2 توسط کلاینت‌ها برای درخواست عملیات از یک سرور مشخص، و توسط سرور برای معرفی و شناسایی خود ارسال می‌شود. برای جزئیات به Server Identifier in DHCPv6 مراجعه کنید.
ia-na 3 یک گزینه دربرگیرنده (container) که آدرس‌های IPv6 (گزینه‌های iaddr) را منتقل می‌کند. Kea این گزینه‌ها را با استفاده از موتور تخصیص خود دریافت و ارسال می‌کند.
ia-ta 4 آدرس‌های موقت را منتقل می‌کند. قابلیتی منسوخ‌شده است و پشتیبانی نمی‌شود.
iaaddr 5 آدرس‌ها را به همراه طول عمر در گزینه‌های ia-na و ia-ta منتقل می‌کند.
oro 6 گزینه ORO (یا Option Request Option) توسط کلاینت‌ها برای درخواست فهرستی از گزینه‌های مورد نظر استفاده می‌شود. Kea از آن پشتیبانی می‌کند و در صورت پیکربندی با گزینه‌های لازم، گزینه‌های درخواستی را بازمی‌گرداند.
elapsed-time 8 توسط کلاینت‌ها ارسال می‌شود تا مشخص کند چه مدت در تلاش برای دریافت پیکربندی بوده‌اند. Kea مقادیر بالای ارسال‌شده توسط کلاینت را به عنوان نشانه‌ای از وجود مشکل تلقی می‌کند؛ این یکی از جنبه‌های مورد استفاده در HA برای تعیین وضعیت سلامت شریک (partner) است.
relay-msg 9 توسط رله‌ها برای کپسوله‌سازی پیام اصلی کلاینت استفاده می‌شود. Kea هنگام بازگرداندن پاسخ‌های بازپخش‌شده به عامل رله (relay agent) از آن استفاده می‌کند.
auth 11 برای انتقال اطلاعات احراز هویت بین کلاینت‌ها و سرور استفاده می‌شود. پشتیبانی از این گزینه بسیار محدود است.
status-code 13 گزینه‌ای که سرور می‌تواند در صورت بروز شکست‌های مختلف، مانند تمام شدن آدرس‌ها یا پیکربندی نشدن برای تخصیص پیشوندها، آن را ضمیمه کند.
rapid-commit 14 برای نشان دادن تمایل کلاینت به پشتیبانی از rapid-commit و پذیرش این پیکربندی توسط سرور استفاده می‌شود. برای جزئیات به Rapid Commit مراجعه کنید.
user-class 15 توسط کلاینت برای شناسایی نوع دستگاه خود ارسال می‌شود. Kea می‌تواند از این مورد برای رده‌بندی کلاینت (client classification) استفاده کند.
vendor-class 16 مشابه user-class، اما وابسته به سازنده (vendor-specific).
vendor-opts 17 یک دربرگیرنده اختصاصی سازنده که توسط کلاینت و سرور برای تبادل گزینه‌های ویژه سازنده استفاده می‌شود. منطق پشت این گزینه‌ها بین سازندگان مختلف متفاوت است. گزینه‌های سازنده در DHCPv6 Vendor-Specific Options توضیح داده شده‌اند.
interface-id 18 ممکن است توسط عامل رله برای مشخص کردن رابطی که پیام اصلی کلاینت روی آن دریافت شده درج شود. می‌توان به Kea دستور داد تا از این اطلاعات برای انتخاب زیرشبکه‌های خاص استفاده کند. همچنین در صورت تعیین، Kea این گزینه را بازتاب (echo) می‌دهد تا رله بداند از کدام رابط برای دسترسی به کلاینت استفاده کند.
ia-pd 25 یک دربرگیرنده برای انتقال واگذاری پیشوند (Prefix Delegations یا PDs) که به کلاینت‌ها واگذار می‌شود. برای جزئیات به Subnet and Prefix Delegation Pools مراجعه کنید.
iaprefix 26 پیشوند IPv6 را در گزینه ia-pd منتقل می‌کند. برای جزئیات به Subnet and Prefix Delegation Pools مراجعه کنید.
گزینه‌های Softwire46 در تدارک و راه‌اندازی IPv4-over-IPv6 از طریق تونل‌زنی یا ترجمه، همان‌طور که در RFC
7598 https://datatracker.ietf.org/doc/html/rfc7598 مشخص شده است، به کار می‌روند. بخش‌های
زیر مثال‌هایی از پیکربندی این گزینه‌ها را ارائه می‌دهند.
گزینه‌های کانتینر Softwire46
گزینه‌های کانتینر Softwire46 (S46) قواعد و پارامترهای اختیاری درگاه (port) را برای یک
دامنه مشخص گروه‌بندی می‌کنند. سه گزینه کانتینر در فضای گزینه "dhcp6"
(سطح بالا) مشخص شده‌اند: گزینه کانتینر MAP-E، گزینه کانتینر MAP-T، و گزینه
کانتینر S46 Lightweight 4over6. این گزینه‌ها تنها شامل گزینه‌های کپسوله‌شده
مشخص‌شده در زیر هستند؛ آن‌ها شامل هیچ فیلد داده‌ای نمی‌باشند.
برای پیکربندی سرور جهت ارسال یک گزینه کانتینر خاص به همراه تمام گزینه‌های
کپسوله‌شده، گزینه کانتینر باید مطابق شکل زیر در پیکربندی سرور گنجانده شود:
0.0
3.5
"Dhcp6": {
"option-data": [
{
"name": "s46-cont-mape"
} ],
...
}
168u
168u
این پیکربندی باعث می‌شود سرور گزینه کانتینر MAP-E را برای کلاینت ارسال کند. به ترتیب
از s46-cont-mapt یا s46-cont-lw برای گزینه‌های کانتینر MAP-T و
کانتینر S46 Lightweight 4over6 استفاده کنید.
تمام گزینه‌های باقی‌مانده Softwire46 که در ادامه شرح داده شده‌اند، در یکی از گزینه‌های
کانتینر گنجانده می‌شوند. بنابراین، آن‌ها باید با انتخاب نام space که مشخص‌کننده
گزینه‌ای است که باید در آن قرار گیرند، در فضاهای گزینه مناسب گنجانده شوند.
گزینه S46 Rule
گزینه S46 Rule برای انتقال قاعده نگاشت پایه (BMR) و قاعده نگاشت بازارسال (FMR)
استفاده می‌شود.
0.0
3.5
{
"space": "s46-cont-mape-options",
"name": "s46-rule",
"data": "128, 0, 24, 192.0.2.0, 2001:db8:1::/64"
}
168u
168u
مقدار ممکن دیگر برای space، مقدار s46-cont-mapt-options است.
گزینه S46 Rule چندین پارامتر را منتقل می‌کند:
0.0
• 2
flags - یک عدد صحیح بی‌علامت ۸ بیتی، که در حال حاضر تنها باارزش‌ترین بیت
آن مشخص شده است. این مقدار مشخص می‌کند که آیا قاعده می‌تواند برای بازارسال (forwarding)
استفاده شود (128) یا خیر (0).
• 2
ea-len - طول آدرس تعبیه‌شده (Embedded Address) با طول ۸ بیت. مقادیر مجاز
در بازه 0 تا 48 قرار دارند.
• 2
IPv4 prefix length - بیانی ۸ بیتی از طول پیشوند برای پیشوند IPv4 قاعده که
در فیلد ipv4-prefix مشخص شده است. مقادیر مجاز در بازه 0 تا 32 قرار دارند.
• 2
IPv4 prefix - یک فیلد ۳۲ بیتی با طول ثابت که پیشوند IPv4 را برای قاعده S46
مشخص می‌کند. بیت‌های موجود در پیشوند پس از تعداد مشخصی بیت (تعریف‌شده در prefix4-len)
رزرو شده‌اند و فرستنده باید حتماً آن‌ها را با صفر مقداردهی اولیه کرده و گیرنده باید آن‌ها را
نادیده بگیرد.
• 2
IPv6 prefix - فیلدی با نمادگذاری پیشوند/طول که پیشوند دامنه IPv6 را برای قاعده
S46 مشخص می‌کند. هنگامی که prefix6-len بخش‌پذیر بر 8 نباشد، این فیلد از سمت راست
با بیت‌های صفر تا نزدیک‌ترین مرز بایت (اکتت) پر (pad) می‌شود.
168u
گزینه S46 BR
گزینه S46 BR برای انتقال آدرس IPv6 رله مرزی (Border Relay) استفاده می‌شود.
این گزینه در گزینه کانتینر MAP-E اجباری است و در گزینه‌های کانتینر MAP-T و
S46 Lightweight 4over6 مجاز نیست.
0.0
3.5
{
"space": "s46-cont-mape-options",
"name": "s46-br",
"data": "2001:db8:cafe::1"
}
168u
168u
مقدار ممکن دیگر برای space، مقدار s46-cont-lw-options است.
گزینه S46 DMR
گزینه S46 DMR برای انتقال مقادیر قاعده نگاشت پیش‌فرض (DMR) استفاده می‌شود.
این گزینه در گزینه کانتینر MAP-T اجباری است و در گزینه‌های کانتینر MAP-E و
S46 Lightweight 4over6 مجاز نیست.
0.0
3.5
{
"space": "s46-cont-mapt-options",
"name": "s46-dmr",
"data": "2001:db8:cafe::/64"
}
168u
168u
این گزینه نباید در کانتینرهای دیگر گنجانده شود..SS گزینه پیوند نشانی S46 IPv4/IPv6 (S46 IPv4/IPv6 Address Binding Option)
گزینه S46 IPv4/IPv6 Address Binding می‌تواند برای مشخص کردن نشانی کامل یا اشتراکی IPv4 سمت مشتری (Customer Edge یا CE) استفاده شود. فیلد پیشوند IPv6 توسط CE برای شناسایی پیشوند صحیح جهت استفاده به عنوان مبدأ تونل به کار می‌رود.
0.0
3.5
{
"space": "s46-cont-lw",
"name": "s46-v4v6bind",
"data": "192.0.2.3, 2001:db8:1:cafe::/64"
}
168u
168u
این گزینه نباید در کانتینرهای دیگر گنجانده شود.
پارامترهای پورت S46 (S46 Port Parameters)
گزینه S46 Port Parameters اطلاعات اختیاری مجموعه پورت‌ها (port-set) را مشخص می‌کند که ممکن است در اختیار CEها قرار گیرد.
0.0
3.5
{
"space": "s46-rule-options",
"name": "s46-portparams",
"data": "2, 3/4"
}
168u
168u
یک مقدار ممکن دیگر برای space مقدار s46-v4v6bind است تا این گزینه در گزینه S46 IPv4/IPv6 Address Binding قرار گیرد.
توجه داشته باشید که مقدار دوم در مثال بالا فیلدهای PSID و طول PSID (PSID-length) را در قالب PSID/PSID length مشخص می‌کند. این معادل مقادیر PSID-len=4 و PSID=12288 منتقل‌شده در گزینه S46 Port Parameters است.
گزینه‌های DNR (Discovery of Network-designated Resolvers) برای DHCPv6
گزینه کشف تحلیل‌کننده‌های تعیین‌شده توسط شبکه، یا گزینه DNR، در RFC 9463 https://datatracker.ietf.org/doc/html/rfc9463 به عنوان روشی برای اعلام مکان تحلیل‌کننده‌های DNS در دسترس از طریقی غیر از DNS کلاسیک بر روی UDP و پورت ۵۳ معرفی شد. تا بهار ۲۰۲۴، فناوری‌های پشتیبانی‌شده عبارتند از DoT (DNS-over-TLS)، DoH (DNS-over-HTTPS) و DoQ (DNS-over-QUIC)، اما این گزینه به گونه‌ای طراحی شده است که توسعه‌پذیر بوده و در آینده پروتکل‌های دیگر را نیز در بر گیرد.
گزینه DNR را می‌توان با استفاده از نشانه‌گذاری مناسبی پیکربندی کرد: فیلدهای جداشده با کاما باید به ترتیب زیر ارائه شوند:
0.0
• 2
اولویت سرویس (Service Priority) (اجباری)،
• 2
نام دامنه کاملاً مشخص ADN (اجباری)،
• 2
نشانی(های) IP (اختیاری؛ اگر بیش از یکی باشد، باید با فاصله جدا شوند)
• 2
پارامترهای SvcParams به صورت مجموعه‌ای از جفت‌های کلید=مقدار (اختیاری؛ اگر بیش از یکی باشد، باید با فاصله جدا شوند. برای ارائه بیش از یک alpn-id، آنها را با کاماهای گریز داده‌شده با دو بک‌اسلش مانند مثال زیر جدا کنید).
168u
فرض کنیم می‌خواهیم یک سرور DoT در حال کار در dot1.example.org (که به دو نشانی IPv6 تحلیل می‌شود: 2001:db8::1 و 2001:db8::2) روی یک پورت غیر استاندارد ۸۵۳۰ را اعلام کنیم. یک گزینه نمونه که این اطلاعات را منتقل می‌کند به شکل زیر است:
0.0
3.5
{
"name": "v6-dnr", // نام گزینه
// فیلدهای زیر باید مشخص شوند:
// - اولویت سرویس (عدد صحیح ۱۶ بیتی بدون علامت)
// - authentication-domain-name (نام FQDN مربوط به تحلیل‌کننده رمزگذاری‌شده)
// - فهرستی از یک یا چند نشانی IPv6
// - فهرستی از پارامترها در قالب key=value که با فاصله جدا شده‌اند؛ هرگونه
// نویسه کاما در این فیلد باید با دو بک‌اسلش گریز داده شود
"data": "100, dot1.example.org., 2001:db8::1 2001:db8::2, alpn=dot port=8530"
}
168u
168u
گزینه بالا در رسانه انتقال (on-wire) به صورت زیر کدگذاری خواهد شد:
0.0
3.5
00 64 - اولویت سرویس (۱۰۰ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت)
00 12 - طول FQDN نام دامنه احراز هویت (نام تحلیل‌کننده) (۱۸ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت)
04 64 6f 74 31 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 - ۱۸ اوکتت از ADN FQDN
00 20 - ۳۲ اوکتت، طول دو نشانی IPv6 پس از آن است
20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 - 2001:db8::1
20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 02 - 2001:db8::2
00 01 - شروع SvcParams - این alpn SvcParamKey است
00 04 - طول فیلد alpn SvcParamValue (۴ اوکتت)
03 - طول alpn-id بعدی کدگذاری‌شده در یک اوکتت
64 6f 74 - "dot" - مقدار alpn
00 03 - این port SvcParamKey است
00 02 - طول فیلد SvcParamValue برابر ۲ اوکتت است
21 52 - مقدار واقعی 0x2152 یا ۸۵۳۰ در مبنای ده‌دهی است
168u
168u
مثال زیر نحوه پیکربندی بیش از یک پروتکل ALPN را در پارامترهای سرویس (Service Parameters) نشان می‌دهد. این مثال تحلیل‌کننده‌ای شناخته‌شده به نام resolver.example را مشخص می‌کند که از موارد زیر پشتیبانی می‌کند:
0.0
• 2
پروتکل DoT روی پورت پیش‌فرض ۸۵۳
• 2
پروتکل DoQ روی پورت پیش‌فرض ۸۵۳
• 2
پروتکل DoH در https://resolver.example/q{?dns}
168u
0.0
3.5
{
"name": "v6-dnr", // نام گزینه
// به کاماهای گریز داده‌شده با دو بک‌اسلش در فهرست alpn-id توجه کنید.
"data": "150, resolver.example., 2001:db8::1 2001:db8::2, alpn=dot\\,doq\\,h2\\,h3 dohpath=/q{?dns}"
}
168u
168u
گزینه بالا در رسانه انتقال (on-wire) به صورت زیر کدگذاری خواهد شد:
0.0
3.5
00 96 - اولویت سرویس (۱۵۰ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت)
00 12 - طول FQDN نام دامنه احراز هویت (نام تحلیل‌کننده) (۱۸ در هگز به صورت عدد صحیح ۱۶ بیتی بدون علامت)
08 72 65 73 6f 6c 76 65 72 07 65 78 61 6d 70 6c 65 00 - ۱۸ اوکتت از ADN FQDN
00 20 - ۳۲ اوکتت، طول دو نشانی IPv6 پس از آن است
20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 - 2001:db8::1
20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 02 - 2001:db8::2
00 01 - شروع SvcParams - این alpn SvcParamKey است
00 0e - طول فیلد alpn SvcParamValue (۱۴ اوکتت)
03 - طول alpn-id بعدی کدگذاری‌شده در یک اوکتت
64 6f 74 - "dot" - مقدار alpn
03 - طول alpn-id بعدی کدگذاری‌شده در یک اوکتت
64 6f 71 - "doq" - مقدار alpn
02 - طول alpn-id بعدی کدگذاری‌شده در یک اوکتت
68 32 - "h2" - مقدار alpn "HTTP/2 over TLS"
02 - طول alpn-id بعدی کدگذاری‌شده در یک اوکتت
68 33 - "h3" - مقدار alpn "HTTP/3"
00 07 - این dohpath SvcParamKey است
00 08 - طول فیلد SvcParamValue برابر ۸ اوکتت است
2f 71 7b 3f 64 6e 73 7d - "/q{?dns}" dohpath
168u
168u
نکته:
0.0
3.5
اگر نویسه‌های «کاما» ("comma") یا «پایپ» ("pipe") به جای جداکننده فیلد به عنوان متن استفاده شوند، باید با دو بک‌اسلش گریز داده شوند (\\, یا \\|). هنگام پیکربندی بیش از یک پروتکل ALPN، باید از کاماهای گریزخورده برای جداسازی آنها استفاده شود. نویسه «پایپ» (0x7C) می‌تواند در پارامتر سرویس dohpath استفاده شود، زیرا در یک URI مجاز است.
168u
168u
بخش ۴.۱ از سند RFC 9463 https://datatracker.ietf.org/doc/html/rfc9463#name-option-format استفاده از SvcParam مربوط به ALPN (Application-Layer Protocol Negotiation) را تشویق می‌کند، زیرا در اکثر موارد مورد نیاز است. این پارامتر پروتکل دسترسی به تحلیل‌کننده رمزگذاری‌شده را تعریف می‌کند. رایج‌ترین مقادیر عبارتند از dot، doq و h2 (به معنای HTTP/2.0 بر روی TLS، که در DoH استفاده می‌شود).
طبق بخش ۵ از RFC 9461 https://datatracker.ietf.org/doc/html/rfc9461#name-new-svcparamkey-dohpath: اگر SvcParam مربوط به alpn نشان‌دهنده پشتیبانی از HTTP باشد، dohpath حتماً باید وجود داشته باشد. الگوی URI باید حاوی یک متغیر "dns" باشد. به عنوان مثال، هنگام معرفی یک تحلیل‌کننده DoH در دسترس در https://doh1.example.org/query{?dns}، مقدار dohpath باید روی URI نسبی /query{?dns} تنظیم شود.
به کاربرانی که علاقه‌مند به پیکربندی این گزینه هستند توصیه می‌شود مطالب زیر را مطالعه کنند:
0.0
• 2
مجموعه بسیار خوبی از مثال‌ها در بخش ۷ از RFC 9461 https://datatracker.ietf.org/doc/html/rfc9461#name-examples در دسترس است.
• 2
فهرستی از تمام پارامترهای سرویس تعریف‌شده کنونی در ثبت IANA https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml نگهداری می‌شود. این سند رکوردهایی را که می‌توان در فیلد svcParams گزینه DNR ذخیره کرد، مشخص می‌کند.
• 2
فهرستی از پروتکل‌های مجاز کنونی در پارامتر ALPN در یکی دیگر از ثبت‌های IANA https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids نگهداری می‌شود.
• 2
سند RFC 9463 https://datatracker.ietf.org/doc/html/rfc9463 تعاریف گزینه‌ها را ارائه می‌دهد. از نظر SvcParams، بیان می‌کند که alpn و port باید پشتیبانی شوند، و پشتیبانی از dohpath (استفاده‌شده برای DoH) توصیه می‌شود.
• 2
بخش ۲.۲ از RFC 9460 https://datatracker.ietf.org/doc/html/rfc9460 قالب on-wire را برای SvcParams تعریف می‌کند.
• 2
بخش‌های ۷.۱ و ۷.۲ از RFC 9460 https://datatracker.ietf.org/doc/html/rfc9460 قالب on-wire را برای alpn و port تعریف می‌کنند.
• 2
بخش ۵ از RFC 9461 https://datatracker.ietf.org/doc/html/rfc9461#name-new-svcparamkey-dohpath قالب on-wire را برای dohpath تعریف می‌کند.
168u
در حال حاضر Kea از پارامترهای سرویس زیر پشتیبانی می‌کند:
0.0
3.5
box center;
l|l|l.
نام کد توضیحات
alpn 1 انواع پروتکل‌های جداشده با کاما را مشخص می‌کند (DoT، DoH و غیره)
port 3 عدد صحیح ۱۶ بیتی بدون علامت. نشان‌دهنده یک پورت غیر استاندارد TCP یا UDP است.
dohpath 7 برای DoH اجباری است. شامل مسیر URL برای تحلیل‌کننده DoT است.

سایر پارامترهای سرویس تعریف‌شده کنونی شامل mandatory (0)، no-default-alpn (2)، ipv4hint (4)، ech (5)، ipv6hint (6) و ohttp (8) در گزینه DNR قابل استفاده نیستند.

مثال‌های بیشتر را می‌توان در kea6/all-options.json <#config-example-kea6-all-options-json> یافت. گزینه DHCPv4 تقریباً یکسان است و در DNR (Discovery of Network-designated Resolvers) Options for DHCPv4 <#dnr4-options> شرح داده شده است..SS زیرگزینه‌های سرور NTP (NTP Server Suboptions)

گزینهٔ سرور NTP حاوی مجموعه‌ای از زیرگزینه‌ها است: ntp-server-address (۱)، ntp-server-multicast (۲) که حامل یک آدرس IPv6 است، و ntp-server-fqdn (۳) که حامل یک FQDN در قالب سیمی (wire format) تعریف‌شده در فضای گزینهٔ "v6-ntp-server-suboptions" است. طبق الزامات RFC 5908 https://datatracker.ietf.org/doc/html/rfc5908، هر نمونه از گزینه تنها و فقط یک زیرگزینه را حمل می‌کند.

بنابراین با فرض اینکه گزینهٔ دربرگیرندهٔ ntp-server از پیش در یک بند option-data تنظیم شده باشد، برای ارسال آن همراه با زیرگزینهٔ ntp-server-address برای سرور عمومی 2.pool.ntp.org، پیکربندی باید شامل موارد زیر باشد:

"Dhcp6": {
    "option-data": [
        {
            "space": "v6-ntp-server-suboptions",
            "name": "ntp-server-address",
            "data": "2a02:8424:6fc4:3601:c13b:9426:51db:aa1"
        },
        ...
    ],
    ...
}

برای FQDN که امکان انتخاب یکی از ۴ آدرس آن را فراهم می‌کند:

"Dhcp6": {
    "option-data": [
        {
            "space": "v6-ntp-server-suboptions",
            "name": "ntp-server-fqdn",
            "data": "2.pool.ntp.org"
        },
        ...
    ],
    ...
}

یا برای یک سایت بسته با سرور NTP اختصاصی که از چندپخشی (multicast) استفاده می‌کند:

"Dhcp6": {
    "option-data": [
        {
            "space": "v6-ntp-server-suboptions",
            "name": "ntp-server-multicast",
            "data": "ff05::101"
        },
        ...
    ],
    ...
}

توجه داشته باشید که استاندارد ایجاب می‌کند تنها یک زیرگزینه در گزینهٔ ntp-server گنجانده شود.

نرم‌افزار Kea از گزینه‌های سفارشی (غیراستاندارد) DHCPv6 پشتیبانی می‌کند. فرض کنید می‌خواهیم یک گزینهٔ DHCPv6 جدید به نام foo تعریف کنیم که کد ۱۰۰ خواهد داشت و یک مقدار عدد صحیح ۳۲ بیتی بدون علامت منفرد را منتقل می‌کند. چنین گزینه‌ای را می‌توان با قرار دادن ورودی زیر در فایل پیکربندی تعریف کرد:

"Dhcp6": {
    "option-def": [
        {
            "name": "foo",
            "code": 100,
            "type": "uint32",
            "array": false,
            "record-types": "",
            "space": "dhcp6",
            "encapsulate": ""
        },
        ...
    ],
    ...
}

مقدار false در پارامتر array مشخص می‌کند که گزینه شامل آرایه‌ای از مقادیر uint32 نیست، بلکه در عوض یک مقدار منفرد است. دو پارامتر دیگر خالی گذاشته شده‌اند: record-types و encapsulate. اولی در صورتی که گزینه شامل رکوردی از فیلدهای داده باشد، فهرستی از فیلدهای دادهٔ گزینه را که با کاما جدا شده‌اند مشخص می‌کند. در صورتی که type روی record تنظیم شده باشد، مقدار record-types باید غیرخالی باشد؛ در غیر این صورت باید خالی گذاشته شود. پارامتر دومی نام فضای گزینه‌ای را مشخص می‌کند که توسط این گزینهٔ خاص کپسوله‌سازی می‌شود. اگر این گزینهٔ خاص هیچ فضای گزینه‌ای را کپسوله‌سازی نکند، پارامتر باید خالی گذاشته شود. توجه داشته باشید که عبارت پیکربندی option-def تنها قالب یک گزینه را تعریف می‌کند و مقدار (یا مقادیر) آن را تعیین نمی‌نماید.

پارامترهای name، code و type الزامی هستند؛ سایر پارامترها اختیاری‌اند. مقدار پیش‌فرض پارامتر array برابر با false است. مقادیر پیش‌فرض پارامترهای record-types و encapsulate خالی ("") هستند. مقدار پیش‌فرض space نیز dhcp6 است.

پس از تعریف قالب گزینهٔ جدید، مقدار آن به همان روش گزینه‌های استاندارد تنظیم می‌شود. به عنوان مثال، دستورات زیر یک مقدار سراسری تنظیم می‌کنند که بر تمام زیرشبکه‌ها اعمال می‌شود.

"Dhcp6": {
    "option-data": [
        {
            "name": "foo",
            "code": 100,
            "space": "dhcp6",
            "csv-format": true,
            "data": "12345"
        },
        ...
    ],
    ...
}

گزینه‌های جدید می‌توانند اشکال پیچیده‌تری نسبت به استفادهٔ ساده از انواع اولیه (uint8، string، ipv6-address و غیره) به خود بگیرند؛ امکان تعریف گزینه‌ای متشکل از چندین نوع اولیهٔ موجود وجود دارد.

برای مثال، فرض کنید می‌خواهیم گزینهٔ جدیدی تعریف کنیم که از یک آدرس IPv6، به دنبال آن یک عدد صحیح ۱۶ بیتی بدون علامت، به دنبال آن یک مقدار بولی (boolean)، و سپس یک رشتهٔ متنی تشکیل شده باشد. چنین گزینه‌ای را می‌توان به شیوهٔ زیر تعریف کرد:

"Dhcp6": {
    "option-def": [
        {
            "name": "bar",
            "code": 101,
            "space": "dhcp6",
            "type": "record",
            "array": false,
            "record-types": "ipv6-address, uint16, boolean, string",
            "encapsulate": ""
        },
        ...
    ],
    ...
}

پارامتر type روی "record" تنظیم می‌شود تا نشان دهد گزینه شامل مقادیر متعددی از انواع مختلف است. این نوع‌ها به صورت فهرستی جداشده با کاما در فیلد record-types مشخص می‌شوند و باید از میان موارد ذکرشده در فهرست انواع گزینه‌های استاندارد DHCP <#dhcp-types> باشند.

مقادیر گزینه‌ها در یک عبارت option-data به صورت زیر تنظیم می‌شوند:

"Dhcp6": {
    "option-data": [
        {
            "name": "bar",
            "space": "dhcp6",
            "code": 101,
            "csv-format": true,
            "data": "2001:db8:1::10, 123, false, Hello World"
        }
    ],
    ...
}

پارامتر csv-format روی true تنظیم شده است تا نشان دهد فیلد data شامل فهرستی از مقادیر جداشده با کاما است. مقادیر موجود در data باید با انواع تنظیم‌شده در فیلد record-types در تعریف گزینه مطابقت داشته باشند.

هنگامی که array روی true و type روی "record" تنظیم شود، آخرین فیلد یک آرایه خواهد بود، یعنی می‌تواند بیش از یک مقدار داشته باشد، مانند:

"Dhcp6": {
    "option-def": [
        {
            "name": "bar",
            "code": 101,
            "space": "dhcp6",
            "type": "record",
            "array": true,
            "record-types": "ipv6-address, uint16",
            "encapsulate": ""
        },
        ...
    ],
    ...
}

محتوای گزینهٔ جدید یک آدرس IPv6 است که در ادامهٔ آن یک یا چند عدد صحیح ۱۶ بیتی بدون علامت قرار دارد.

نکته:

به‌طور کلی، مقادیر بولی بدون نقل‌قول و به صورت true یا false مشخص می‌شوند. برخی پارامترهای بولی خاص ممکن است مقادیر "true"، "false"، 0، 1، "0" و "1" را نیز بپذیرند.

گزینه‌های سازنده در DHCPv6 از طریق گزینهٔ اطلاعات مختص سازنده (Vendor-Specific Information option با کد ۱۷) منتقل می‌شوند. ایدهٔ پشت گزینهٔ ۱۷ این است که هر سازنده مجموعهٔ یکتای خود از گزینه‌ها را با قالب‌های سفارشی ویژهٔ خود دارد. سازنده با یک عدد صحیح بدون علامت ۳۲ بیتی با نام enterprise-number یا vendor-id مشخص می‌شود.

فضاهای استانداردی که در Kea تعریف شده‌اند و گزینه‌های آن‌ها عبارت‌اند از:

•
vendor-2495: مربوط به Internet Systems Consortium, Inc. برای گزینه‌های 4o6:
کد گزینه نام گزینه شرح گزینه
60000 4o6-interface نام رابط سرور 4o6 که رو به سمت کلاینت است
60001 4o6-source-address آدرسی که سرور 4o6 برای ارسال بسته‌ها به کلاینت استفاده می‌کند
60002 4o6-source-port پورتی که سرور 4o6 برای ارسال بسته‌ها به کلاینت باز می‌کند
•
vendor-4491: مربوط به Cable Television Laboratories, Inc. برای گزینه‌های DOCSIS3:
کد گزینه نام گزینه شرح گزینه
1 oro گزینهٔ ORO (یا Option Request Option) توسط کلاینت‌ها برای درخواست فهرستی از گزینه‌های مورد نظر آن‌ها استفاده می‌شود.
2 tftp-servers فهرستی از آدرس‌های IPv4 سرورهای TFTP که توسط مودم کابلی استفاده می‌شوند

مثال‌های زیر نشان می‌دهند چگونه گزینهٔ "foo" با کد ۱ تعریف شود که شامل یک آدرس IPv6، یک عدد صحیح ۱۶ بیتی بدون علامت، و یک رشته است. گزینهٔ "foo" در یک گزینهٔ اطلاعات مختص سازنده (Vendor-Specific Information) منتقل می‌شود که شامل یک مقدار uint32 واحد است که روی 12345 تنظیم شده است. زیرگزینهٔ "foo" پس از فیلد داده‌ای که این مقدار را در خود نگه می‌دارد قرار می‌گیرد.

گام نخست، تعریف قالب گزینه است:

"Dhcp6": {
    "option-def": [
        {
            "name": "foo",
            "code": 1,
            "space": "vendor-12345",
            "type": "record",
            "array": false,
            "record-types": "ipv6-address, uint16, string",
            "encapsulate": ""
        }
    ],
    ...
}

توجه داشته باشید که فضای گزینه روی "vendor-12345" تنظیم شده است. پس از تعریف قالب گزینه، گام بعدی تعیین مقادیر واقعی برای آن گزینه است:

"Dhcp6": {
    "option-data": [
        {
            "name": "foo",
            "space": "vendor-12345",
            "data": "2001:db8:1::10, 123, Hello World"
        },
        ...
    ],
    ...
}

همچنین باید مقداری ("enterprise-number") برای گزینهٔ اطلاعات مختص سازنده تعریف کنیم تا گزینهٔ foo را منتقل کند.

"Dhcp6": {
    "option-data": [
        {
            "name": "vendor-opts",
            "data": "12345"
        },
        ...
    ],
    ...
}

از طرف دیگر، می‌توان گزینه را با استفاده از کد آن مشخص کرد.

"Dhcp6": {
    "option-data": [
        {
            "code": 17,
            "data": "12345"
        },
        ...
    ],
    ...
}

یک پیکربندی رایج این است که پرچم always-send روی true تنظیم شود، تا گزینهٔ سازنده حتی در صورتی که کلاینت آن را در پرس‌وجوی خود مشخص نکرده باشد نیز ارسال گردد.

همچنین به همین ترتیب می‌توان kea-dhcp6 <#std-iscman-kea-dhcp6> را برای ارسال چندین گزینهٔ سازنده از سازندگان مختلف، به همراه شماره سازمانی اختصاصی هر یک از آن‌ها، پیکربندی نمود. برای ارسال این گزینه‌ها صرف‌نظر از اینکه کلاینت یک شماره سازمانی مشخص کرده باشد یا خیر، سرور باید با "always-send": true پیکربندی شود، از جمله گزینهٔ اطلاعات مختص سازنده (کد ۱۷).

{
  "Dhcp6": {
    "option-data": [
      {
        "always-send": true,
        "data": "tagged",
        "name": "tag",
        "space": "vendor-2234"
      },
      {
        "always-send": true,
        "data": "https://example.com:1234/path",
        "name": "url",
        "space": "vendor-3561"
      }
    ],
    "option-def": [
      {
        "code": 22,
        "name": "tag",
        "space": "vendor-2234",
        "type": "string"
      },
      {
        "code": 11,
        "name": "url",
        "space": "vendor-3561",
        "type": "string"
      }
    ]
  }
}

نکته:

سرور kea-dhcp6 <#std-iscman-kea-dhcp6> قادر است چندین گزینهٔ Vendor Class (کد ۱۶) با شماره‌های سازمانی مختلف را در درخواست‌های کلاینت شناسایی کند و چندین گزینهٔ اطلاعات مختص سازنده (کد ۱۷) را در پاسخ‌ها، به ازای هر سازنده یکی، ارسال نماید.

گاهی اوقات تعریف یک فضای گزینهٔ (option space) کاملاً جدید سودمند است: برای نمونه، کاربر ممکن است گزینهٔ جدیدی برای انتقال زیرگزینه‌هایی ایجاد کند که از یک طرح شماره‌گذاری جداگانه استفاده می‌کنند، مانند زیرگزینه‌هایی با کدهای ۱ و ۲. این کدهای گزینه با گزینه‌های استاندارد DHCPv6 تداخل دارند، بنابراین باید یک فضای گزینهٔ جداگانه تعریف شود.

توجه داشته باشید که هنگام تعریف زیرگزینه‌ها برای یک گزینهٔ استاندارد، ایجاد یک فضای گزینهٔ جدید لازم نیست؛ زیرا اگر قرار باشد یک گزینهٔ استاندارد زیرگزینه‌هایی را منتقل کند، به‌طور پیش‌فرض یکی ایجاد می‌شود (به بخش DHCPv6 Vendor-Specific Options مراجعه کنید).

اگر بخواهیم یک گزینهٔ DHCPv6 به نام container با کد 102 داشته باشیم که دو زیرگزینه با کدهای 1 و 2 را منتقل می‌کند، ابتدا باید زیرگزینه‌های جدید را تعریف کنیم:

"Dhcp6": {
    "option-def": [
        {
            "name": "subopt1",
            "code": 1,
            "space": "isc",
            "type": "ipv6-address",
            "record-types": "",
            "array": false,
            "encapsulate": ""
        },
        {
            "name": "subopt2",
            "code": 2,
            "space": "isc",
            "type": "string",
            "record-types": "",
            "array": false,
            "encapsulate": ""
        }
    ],
    ...
}

توجه داشته باشید که ما گزینه‌ها را طوری تعریف کرده‌ایم که به یک فضای گزینهٔ جدید (در این حالت، "isc") تعلق داشته باشند.

گام بعدی تعریف یک گزینهٔ معمولی DHCPv6 با کد مورد نظر و مشخص کردن این است که باید گزینه‌های متعلق به فضای گزینهٔ جدید را شامل شود:

"Dhcp6": {
    "option-def": [
        {
            "name": "container",
            "code": 102,
            "space": "dhcp6",
            "type": "empty",
            "array": false,
            "record-types": "",
            "encapsulate": "isc"
        },
        ...
    ],
    ...
}

نام فضای گزینه‌ای که زیرگزینه‌ها در آن تعریف شده‌اند در فیلد encapsulate تنظیم می‌شود. فیلد type روی "empty" تنظیم شده است تا نشان دهد این گزینه داده‌ای غیر از زیرگزینه‌ها حمل نمی‌کند.

در نهایت، می‌توانیم مقادیر گزینه‌های جدید را مقداردهی کنیم:

{
  "Dhcp6": {
    "option-data": [
        {
            "name": "subopt1",
            "code": 1,
            "space": "isc",
            "data": "2001:db8::abcd"
        },
        {
            "name": "subopt2",
            "code": 2,
            "space": "isc",
            "data": "Hello world"
        },
        {
            "name": "container",
            "code": 102,
            "space": "dhcp6"
        }
    ]
  }
}

ایجاد گزینه‌ای که علاوه بر زیرگزینه‌های تعریف‌شده در فضای گزینهٔ کپسوله‌شده داده‌هایی را نیز حمل کند ممکن است. برای نمونه، اگر گزینهٔ container از مثال قبلی ملزم به حمل یک مقدار uint16 در کنار زیرگزینه‌ها باشد، مقدار type در تعریف گزینه باید روی "uint16" تنظیم شود. (چنین گزینه‌ای در این صورت دارای این ساختار داده خواهد بود: هدر DHCP، مقدار uint16، زیرگزینه‌ها.) سپس مقداری که با پارامتر data مشخص شده است — که باید یک عدد صحیح معتبر درون گیومه باشد، مانند "123" — به فیلد uint16 در گزینهٔ container اختصاص می‌یابد..SS پارامترهای مشخص‌نشده برای پیکربندی گزینه‌های DHCPv6

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

  • name - کارگزار برای شناسایی یک گزینه، یا به نام گزینه و یا به کد گزینه نیاز دارد. اگر این پارامتر مشخص نشده باشد، کد گزینه باید مشخص شود.
  • code - کارگزار برای شناسایی یک گزینه، یا به نام گزینه و یا به کد گزینه نیاز دارد؛ اگر پارامتر name مشخص شده باشد، این پارامتر می‌تواند مشخص‌نشده رها شود. با این حال، این امر همچنین مستلزم آن است که گزینه مورد نظر دارای تعریف باشد (خواه به عنوان یک گزینه استاندارد یا تعریفی ایجادشده توسط مدیر با استفاده از ساختار option-def)، چرا که تعریف گزینه، آن را با نامی خاص مرتبط می‌سازد. پیکربندی گزینه‌ای که تعریفی برای آن وجود ندارد (قالب گزینه نامشخص) امکان‌پذیر است. پیکربندی چنین گزینه‌هایی مستلزم استفاده از کد گزینه است.
  • space - اگر فضای گزینه مشخص نشده باشد، به طور پیش‌فرض dhcp6 خواهد بود که فضای گزینه‌ای شامل گزینه‌های استاندارد DHCPv6 است.
  • data - اگر داده‌های گزینه مشخص نشده باشد، به طور پیش‌فرض یک مقدار خالی خواهد بود. مقدار خالی بیشتر برای گزینه‌هایی استفاده می‌شود که بار داده (payload) ندارند (گزینه‌های بولی)، اما مشخص کردن مقادیر خالی برای برخی گزینه‌ها که حامل داده‌های با طول متغیر هستند و مشخصات پروتکل طول 0 را برای آن‌ها مجاز می‌داند نیز معتبر است. برای چنین گزینه‌هایی، می‌توان از پارامتر data در پیکربندی صرف‌نظر کرد.
  • csv-format - اگر این مقدار مشخص نشده باشد، کارگزار فرض می‌کند که داده‌های گزینه به صورت فهرستی از مقادیر جداشده با کاما مشخص شده‌اند تا به فیلدهای جداگانه گزینه DHCP اختصاص یابند.

مطابق با RFC 9915، بخش 21.4، مقادیر توصیه‌شده T1 و T2 به ترتیب ۵۰٪ و ۸۰٪ زمان اجاره ترجیحی (preferred lease time) هستند. Kea را می‌توان به گونه‌ای پیکربندی کرد که مقادیر مشخص‌شده به صورت صریح، یا مقادیر محاسبه‌شده به عنوان درصدی از زمان اجاره ترجیحی را ارسال کند. رفتار کارگزار با ترکیبی از پارامترهای پیکربندی تعیین می‌شود که T1 و T2 تنها دو مورد از آن‌ها هستند.

طول‌عمرهای ترجیحی و معتبر اجاره به صورت سه‌تایی‌هایی با مقادیر حداقل، پیش‌فرض و حداکثر با استفاده از ورودی‌های پیکربندی بیان می‌شوند:

  • min-preferred-lifetime - حداقل طول‌عمر ترجیحی را مشخص می‌کند (اختیاری).
  • preferred-lifetime - طول‌عمر ترجیحی پیش‌فرض را مشخص می‌کند.
  • max-preferred-lifetime - حداکثر طول‌عمر ترجیحی را مشخص می‌کند (اختیاری).
  • min-valid-lifetime - حداقل طول‌عمر معتبر را مشخص می‌کند (اختیاری).
  • valid-lifetime - طول‌عمر معتبر پیش‌فرض را مشخص می‌کند.
  • max-valid-lifetime - حداکثر طول‌عمر معتبر را مشخص می‌کند (اختیاری).

این مقادیر را می‌توان در کلاس‌های کلاینت (client classes) مشخص کرد.

هنگامی که کلاینت طول‌عمرها را مشخص نمی‌کند، از مقدار پیش‌فرض استفاده می‌شود. طول‌عمر مشخص‌شده - با استفاده از زیرگزینه IAADDR یا IAPREFIX با مقادیر غیرصفر - در صورتی از این مقادیر استفاده می‌کند که بین کران‌های حداقل و حداکثر پیکربندی‌شده قرار داشته باشند. مقادیر خارج از این کران‌ها بر حسب نیاز به سمت بالا یا پایین گرد می‌شوند.

نکته:

اگر preferred-lifetime به صورت صریح مشخص نشده باشد، یا اگر مقدار مشخص‌شده بزرگ‌تر از مقدار valid-lifetime باشد، کارگزار از مقدار valid-lifetime ضرب در 0.625 استفاده می‌کند.

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

  • renew-timer - مقدار T1 را به ثانیه مشخص می‌کند.
  • rebind-timer - مقدار T2 را به ثانیه مشخص می‌کند.

هر مقداری بزرگ‌تر یا مساوی صفر را می‌توان برای T2 مشخص کرد. T1، در صورت مشخص شدن، باید کمتر از T2 باشد. این انعطاف‌پذیری سناریویی را ممکن می‌سازد که مدیران بخواهند تمدیدها (renewals) و اتصال‌های مجدد (rebinds) کلاینت را با به تعویق انداختن آن‌ها فراتر از طول‌عمر اجاره، سرکوب کنند. این امر باعث منقضی شدن اجاره می‌شود، به جای آنکه توسط کلاینت‌ها تمدید گردد. اگر T1 بزرگ‌تر از T2 مشخص شود، T1 در IA خروجی بدون هشدار روی صفر تنظیم می‌شود.

در اکثریت قریب به اتفاق موارد، مقادیر باید از این قاعده پیروی کنند: T1 < T2 < طول‌عمر ترجیحی < طول‌عمر معتبر. از طرف دیگر، هر دو مقدار T1 و T2 را می‌توان روی 0 پیکربندی کرد، که علامتی به کلاینت‌های DHCPv6 است مبنی بر اینکه می‌توانند بر اساس صلاحدید خود اقدام به تمدید کنند. با این حال، پیاده‌سازی‌های معیوب شناخته‌شده‌ای از کلاینت‌ها در حال استفاده هستند که بلافاصله تمدید را آغاز می‌کنند. مدیرانی که قصد استفاده از مقادیر T1=T2=0 را دارند باید ابتدا آزمایش کرده و مطمئن شوند که کلاینت‌هایشان رفتار معقولی دارند.

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

محاسبه مقادیر توسط سه پارامتر زیر کنترل می‌شود:

  • calculate-tee-times - هنگامی که true باشد، T1 و T2 به صورت درصدهایی از زمان اجاره معتبر محاسبه می‌شوند. مقدار پیش‌فرض آن true است.
  • t1-percent - درصدی از زمان اجاره معتبر که برای T1 استفاده می‌شود. این مقدار به صورت یک عدد حقیقی بین 0.0 و 1.0 بیان می‌شود و باید کمتر از t2-percent باشد. مقدار پیش‌فرض طبق RFC 9915 برابر با 0.5 است.
  • t2-percent - درصدی از زمان اجاره معتبر که برای T2 استفاده می‌شود. این مقدار به صورت یک عدد حقیقی بین 0.0 و 1.0 بیان می‌شود و باید بزرگ‌تر از t1-percent باشد. مقدار پیش‌فرض طبق RFC 9915 برابر با 0.8 است.

نکته:

برخلاف DHCPv4، زمان‌های تی (T1، T2) همیشه در گزینه‌های نشانی و پیشوند DHCPv6 وجود دارند. بنابراین مقدار پیش‌فرض calculate-tee-times برای kea-dhcp6 <#std-iscman-kea-dhcp6> برابر با true است. این امر تضمین می‌کند که رفتار پیش‌فرض کارگزار منجر به ارسال زمان‌های تی غیرصفر به کلاینت‌ها شود. این کار به منظور جلوگیری از اشباع شدن کارگزار توسط کلاینت‌های بدرفتاری است که این زمان‌ها را برای خود محاسبه نمی‌کنند.

نکته:

اگر هم مقادیر صریح مشخص شده باشند و هم calculate-tee-times برابر با true باشد، کارگزار از مقادیر صریح استفاده خواهد کرد. مدیرانی با پیکربندی‌ای که در آن برخی زیرشبکه‌ها یا shared-networkها از مقادیر صریح و برخی از مقادیر محاسباتی استفاده می‌کنند، نباید مقادیر صریح را در سطحی بالاتر از جایی که به کار می‌روند تعریف کنند. به ارث بردن آن‌ها از حوزه‌ای بسیار بالا، مانند دامنه سراسری (global)، باعث می‌شود که آن‌ها در تمام سطوح زیرین (هم shared-networkها و هم زیرشبکه‌ها) دارای مقدار باشند و عملاً مقادیر محاسباتی را غیرفعال کنند.

کارساز DHCPv6 ممکن است درخواست‌هایی را از کلاینت‌های محلی (متصل به همان زیرشبکه کارساز) و دوردست (متصل از طریق رله‌ها یا relays) دریافت کند. از آنجا که ممکن است پیکربندی‌های متعددی برای زیرشبکه‌ها در کارساز تعریف شده باشد، باید زیرشبکه مناسب را برای درخواست داده‌شده انتخاب کند.

در IPv4، کارساز می‌تواند تشخیص دهد که کدام‌یک از زیرشبکه‌های پیکربندی‌شده محلی هستند، زیرا این انتظار منطقی وجود دارد که کارساز دارای یک نشانی IPv4 (سراسری یا global) پیکربندی‌شده روی رابط شبکه (interface) باشد. این فرض در IPv6 صادق نیست؛ کارساز DHCPv6 باید بتواند حتی در صورت استفاده صرف از نشانی‌های link-local نیز کار کند. بنابراین، پارامتر اختیاری interface درون تعریف زیرشبکه در دسترس است تا مشخص کند زیرشبکه مورد نظر محلی است، یعنی مستقیماً از طریق رابط مشخص‌شده در دسترس قرار دارد. برای نمونه، کارسازی که قرار است به یک زیرشبکه محلی روی eth0 سرویس دهد، می‌تواند به صورت زیر پیکربندی شود:

"Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:beef::/48",
            "pools": [
                 {
                     "pool": "2001:db8:beef::/48"
                 }
             ],
            "interface": "eth0"
        }
    ],
    ...
}

گزینه Rapid Commit، که در RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 شرح داده شده است، توسط کارساز Kea DHCPv6 پشتیبانی می‌شود. با این حال، این پشتیبانی به‌طور پیش‌فرض غیرفعال است. می‌توان آن را به ازای هر زیرشبکه با استفاده از پارامتر rapid-commit فعال کرد، همان‌طور که در زیر نشان داده شده است:

{
  "Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:beef::/48",
            "rapid-commit": true,
            "pools": [
                 {
                     "pool": "2001:db8:beef::1-2001:db8:beef::10"
                 }
             ]
        }
    ]
  }
}

این تنظیم تنها بر زیرشبکه‌ای تأثیر می‌گذارد که مقدار rapid-commit برای آن روی true تنظیم شده باشد. برای کلاینت‌های متصل به زیرشبکه‌های دیگر، کارساز گزینه Rapid Commit ارسال‌شده توسط کلاینت را نادیده می‌گیرد و فرایند مبادله ۴-مرحله‌ای (4-way exchange) را دنبال می‌کند؛ یعنی در پاسخ به یک پیام Solicit که حاوی گزینه Rapid Commit است، پیام Advertise ارسال می‌کند.

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

سازوکار نخست از فیلد linkaddr در پیام RELAY_FORW استفاده می‌کند. نام این فیلد تا حدی گمراه‌کننده است، چرا که حاوی یک نشانی لایه پیوند (link-layer) نیست؛ بلکه نشانی‌ای (معمولاً یک نشانی سراسری یا global) را نگهداری می‌کند که برای شناسایی یک پیوند به‌کار می‌رود. کارساز DHCPv6 بررسی می‌کند که آیا این نشانی به یک زیرشبکه تعریف‌شده تعلق دارد یا خیر، و در صورت تعلق داشتن، آن زیرشبکه برای درخواست کلاینت انتخاب می‌شود.

سازوکار دوم مبتنی بر گزینه‌های interface-id است. رله‌ها هنگام بازفرستادن (forwarding) پیام کلاینت، ممکن است گزینه interface-id را در پیام درج کنند که رابطی از رله را که پیام را دریافت کرده است مشخص می‌کند. (برخی رله‌ها امکان پیکربندی این پارامتر را فراهم می‌کنند، اما این مقدار گاهی به‌صورت ثابت کدنویسی شده است (hard-coded) و ممکن است از بسیار ساده [مانند "vlan100"] تا بسیار مبهم و پیچیده متغیر باشد؛ یک نمونه واقعی دیده شده روی سخت‌افزار "ISAM144|299|ipv6|nt:vp:1:110" بود.) کارساز می‌تواند از این اطلاعات برای انتخاب زیرشبکه مناسب استفاده کند. این اطلاعات همچنین به رله بازگردانده می‌شود، تا رله بداند از کدام رابط برای ارسال پاسخ به کلاینت استفاده کند. برای اینکه این فرایند با موفقیت کار کند، شناسه‌های رابط رله باید درون شبکه یکتا باشند و پیکربندی کارساز نیز با آن مقادیر مطابقت داشته باشد.

هنگام پیکربندی کارساز DHCPv6، دو پارامتر با نام‌های مشابه را می‌توان برای یک زیرشبکه پیکربندی کرد:

  • interface - تعیین می‌کند که کدام رابط شبکه محلی می‌تواند برای دسترسی به یک زیرشبکه داده‌شده استفاده شود.
  • interface-id - محتوای گزینه interface-id را تعیین می‌کند که توسط رله‌ها برای شناسایی رابطی روی رله که بسته پاسخ به آن ارسال می‌شود، استفاده می‌گردد.

این دو گزینه مانعة‌الجمع هستند؛ یک زیرشبکه نمی‌تواند هم به‌صورت محلی (ترافیک مستقیم) و هم از طریق رله‌ها (ترافیک راه‌دور) در دسترس باشد. تعیین هم‌زمان هر دو یک خطای پیکربندی محسوب می‌شود و کارساز DHCPv6 چنین پیکربندی‌ای را نخواهد پذیرفت.

پیکربندی نمونه زیر نشان می‌دهد که چگونه می‌توان یک interface-id با مقدار "vlan123" تعیین کرد:

"Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:beef::/48",
            "pools": [
                 {
                     "pool": "2001:db8:beef::/48"
                 }
             ],
            "interface-id": "vlan123"
        }
    ],
    ...
}

سند RFC 6422 https://datatracker.ietf.org/doc/html/rfc6422 سازوکاری به نام Relay-Supplied DHCP Options را تعریف می‌کند. در موارد خاصی، کارگزاران بازپخش (relay agents) تنها موجودیت‌هایی هستند که ممکن است اطلاعات مشخصی را در اختیار داشته باشند، و می‌توانند هنگام بازپخش پیام‌ها از کلاینت به کارساز، گزینه‌ها را درج کنند. سپس کارساز بررسی‌های خاصی را انجام داده و آن گزینه‌ها را در پاسخی که برای کلاینت فرستاده می‌شود رونوشت می‌کند.

برای گنجانده شدن گزینه، شرایط خاصی وجود دارد که باید برآورده شوند. نخست، کارساز نباید خودش آن گزینه را ارائه دهد؛ به بیان دیگر، اگر هم بازپخش و هم کارساز گزینه‌ای را ارائه دهند، کارساز همواره اولویت دارد. دوم، گزینه باید دارای قابلیت RSOO باشد. (مخفف "Relay Supplied Options option"). نهاد IANA فهرستی از گزینه‌های فعال‌شده برای RSOO را در اینجا نگهداری می‌کند: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied. با این حال، ممکن است مواردی وجود داشته باشد که مدیران سیستم بخواهند گزینه‌های دیگری را بازتاب (echo) دهند. می‌توان Kea را طوری تنظیم کرد که با گزینه‌های دیگر نیز به‌صورت RSOO-enabled رفتار کند؛ برای مثال، برای علامت‌گذاری گزینه‌های 110، 120 و 130 به‌عنوان RSOO-enabled، باید از ساختار زیر استفاده شود:

"Dhcp6": {
    "relay-supplied-options": [ "110", "120", "130" ],
    ...
}

در حال حاضر، تنها گزینه 65 توسط IANA به‌صورت RSOO-enabled درآمده است. این گزینه همیشه به‌صورت RSOO-enabled در نظر گرفته می‌شود، بنابراین نیازی به علامت‌گذاری صریح آن نیست. هنگام فعال‌سازی گزینه‌های استاندارد، می‌توان به جای کد گزینه از نام آن‌ها نیز استفاده کرد؛ برای نمونه، استفاده از dns-servers به جای 23. برای مشاهده نام‌ها به ref:dhcp6-std-options-list مراجعه کنید. در مواردی خاص، این کار ممکن است برای گزینه‌های سفارشی (custom options) نیز کار کند، اما به دلیل ماهیت کد تجزیه‌کننده (parser) ممکن است غیرقابل‌اتکا باشد و باید از آن اجتناب کرد.

کارساز DHCPv6 شامل پشتیبانی از طبقه‌بندی کلاینت (client classification) است. برای بررسی عمیق‌تر فرآیند طبقه‌بندی، Client Classification <#classify> را ببینید.

در مواردی خاص، پیکربندی کارساز برای تمایز قائل شدن بین انواع کلاینت‌های DHCP و رفتار متناسب با آن‌ها مفید است. طبقه‌بندی کلاینت را می‌توان برای تغییر رفتار تقریباً هر بخشی از پردازش پیام‌های DHCP به کار برد. Kea در حال حاضر سه سازوکار ارائه می‌دهد که در DHCPv6 از طبقه‌بندی کلاینت بهره می‌برند: انتخاب زیرشبکه (subnet selection)، انتخاب استخر آدرس (address pool selection)، و تخصیص گزینه‌های DHCP (DHCP options assignment).

می‌توان به Kea دستور داد تا دسترسی به زیرشبکه‌های مشخص‌شده را بر اساس اطلاعات کلاس محدود کند. این امر به‌ویژه برای مواردی مفید است که در آن دو نوع دستگاه پیوند یکسانی را به اشتراک می‌گذارند و انتظار می‌رود که از دو زیرشبکه مختلف به آن‌ها سرویس‌دهی شود. مورد کاربرد اصلی چنین سناریویی شبکه‌های کابلی است، که در آن دو کلاس از دستگاه‌ها وجود دارد: خود مودم کابلی، که باید اجاره‌ای (lease) از زیرشبکه A به آن تحویل داده شود؛ و تمامی دستگاه‌های دیگر پشت مودم، که باید اجاره‌هایی از زیرشبکه B دریافت کنند. این جداسازی برای جلوگیری از دستکاری مودم‌های کابلی توسط کاربران نهایی بیش از حد کنجکاو ضروری است. برای جزئیات در مورد نحوه راه‌اندازی محدودیت‌های کلاس روی زیرشبکه‌ها، Configuring Subnets With Class Information <#classification-subnets> را ببینید.

هنگامی که زیرشبکه‌ها به یک شبکه مشترک (shared network) تعلق دارند، طبقه‌بندی روی انتخاب زیرشبکه اعمال می‌شود اما روی استخرها اعمال نمی‌شود؛ یعنی یک استخر در زیرشبکه‌ای که به کلاس خاصی محدود شده است، در صورتی که استخر مورد انتظار کلاینت‌ها تمام شده باشد، همچنان می‌تواند توسط کلاینت‌هایی که به آن کلاس تعلق ندارند استفاده شود. محدودیت دسترسی بر اساس اطلاعات کلاس در سطح استخر آدرس/پیشوند درون یک زیرشبکه نیز در دسترس است: به Configuring Pools With Class Information <#classification-pools> مراجعه کنید. این قابلیت زمانی مفید است که کلاینت‌های متعلق به یک زیرشبکه را به محدوده‌های آدرس متفاوتی تفکیک می‌کنید.

به همین شیوه، با استفاده از کلاس‌های توکار KNOWN یا UNKNOWN، می‌توان یک استخر را محدود کرد تا تنها به کلاینت‌های شناخته‌شده، یعنی کلاینت‌هایی که دارای رزرو (reservation) هستند، سرویس دهد. می‌توان به کلاینت‌های ثبت‌شده آدرس اختصاص داد بدون اینکه برای هر رزرو یک آدرس متفاوت داده شود: برای نمونه، زمانی که آدرس‌های دردسترس کافی وجود ندارد. تعیین اینکه آیا رزروی برای یک کلاینت خاص وجود دارد یا خیر، پس از انتخاب زیرشبکه انجام می‌شود، بنابراین امکان استفاده از کلاس‌های KNOWN/UNKNOWN برای انتخاب یک شبکه مشترک یا یک زیرشبکه وجود ندارد.

فرآیند طبقه‌بندی در پنج مرحله انجام می‌شود. نخستین گام، ارزیابی بسته ورودی و انتساب آن به صفر یا چند کلاس است. دومین گام، انتخاب یک زیرشبکه است، که احتمالاً بر اساس اطلاعات کلاس صورت می‌گیرد. هنگامی که بسته ورودی در کلاس ویژه DROP قرار گیرد، دور انداخته می‌شود و یک پیام اشکال‌زدایی (debug) ثبت می‌گردد. گام بعدی، ارزیابی عبارت‌های کلاسیِ وابسته به کلاس‌های توکار KNOWN/UNKNOWN پس از جستجوی رزرو میزبان (host reservation lookup)، استفاده از آن‌ها برای انتخاب pool/pd-pool و انتساب کلاس‌ها از روی رزروهای میزبان است. سپس فهرست کلاس‌های مورد نیاز ساخته می‌شود و عبارت هر کلاس از این فهرست ارزیابی می‌گردد؛ زمانی که خروجی آن true باشد، بسته به‌عنوان عضوی از آن کلاس اضافه می‌شود. گام پایانی تخصیص گزینه‌ها است که باز هم احتمالاً بر اساس اطلاعات کلاس انجام می‌شود. اطلاعات کامل‌تر و دقیق‌تر در Client Classification <#classify> در دسترس است.

دو روش اصلی برای طبقه‌بندی وجود دارد. روش اول خودکار است و بر بررسی مقادیر موجود در گزینه‌های vendor class یا وجود رزرو میزبان تکیه دارد. اطلاعات از این گزینه‌ها استخراج شده، و نام کلاسی از آن ساخته می‌شود و به فهرست کلاس‌های بسته افزوده می‌گردد. روش دوم، عبارتی را مشخص می‌کند که برای هر بسته ارزیابی می‌شود. اگر نتیجه true باشد، بسته عضوی از آن کلاس خواهد بود.

نکته:

پرچم پارامتر سراسری جدید early-global-reservations-lookup امکان جستجو برای رزروهای سراسری را قبل از مرحله انتخاب زیرشبکه فعال می‌کند. این جستجو شبیه به جستجوی عمومی شرح داده‌شده در بالا با دو تفاوت است:
  • جستجو به رزروهای میزبان سراسری (global host reservations) محدود است
  • کلاس UNKNOWN هرگز تنظیم نمی‌شود

نکته:

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

نکته:

نگارش 3.1.7 از Kea کلاس ویژه دیگری به نام REJECT اضافه کرد که به شیوه‌ای مشابه با کلاس DROP کار می‌کند، اما به‌جای نادیده گرفتن و دور انداختن کامل پرس‌وجوی ورودی، از بخش تخصیص اجاره صرف‌نظر می‌کند تا IAها در پاسخ، کدهای وضعیت NoAddrsAvail یا NoPrefixAvail را دریافت کنند.

مثال زیر نحوه پیکربندی یک کلاس با استفاده از یک عبارت (expression) و یک زیرشبکه با استفاده از آن کلاس را نشان می‌دهد. این پیکربندی کلاسی به نام Client_enterprise را تعریف می‌کند. این کلاس شامل تمام کلاینت‌هایی است که شناسه کلاینت آن‌ها با رشته هگزادسیمال مشخص‌شده شروع می‌شود (که نشان‌دهنده یک DUID بر اساس شناسه سازمانی 0xAABBCCDD است). به اعضای این کلاس آدرسی از 2001:db8:1::0 تا 2001:db8:1::FFFF اختصاص می‌یابد و آدرس‌های کارسازهای DNS آن‌ها روی 2001:db8:0::1 و 2001:db8:2::1 تنظیم می‌شود.

"Dhcp6": {
    "client-classes": [
        {
            "name": "Client_enterprise",
            "test": "substring(option[1].hex,0,6) == 0x0002AABBCCDD",
            "option-data": [
                {
                    "name": "dns-servers",
                    "code": 23,
                    "space": "dhcp6",
                    "csv-format": true,
                    "data": "2001:db8:0::1, 2001:db8:2::1"
                }
            ]
        },
        ...
    ],
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/64",
            "pools": [ { "pool": "2001:db8:1::-2001:db8:1::ffff" } ],
            "client-classes": [ "Client_enterprise" ]
        }
    ],
    ...
}

این مثال پیکربندی‌ای را با استفاده از کلاس تولیدشده خودکار VENDOR_CLASS_ نشان می‌دهد. مدیر شبکه تصمیم گرفته است که آدرس‌ها در محدوده 2001:db8:1::1 تا 2001:db8:1::ffff توسط کارساز DHCPv6 مدیریت شوند و فقط کلاینت‌های متعلق به کلاس کلاینت eRouter1.0 مجاز به استفاده از آن استخر (pool) باشند.

"Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/64",
            "pools": [
                 {
                     "pool": "2001:db8:1::-2001:db8:1::ffff"
                 }
             ],
            "client-classes": [ "VENDOR_CLASS_eRouter1.0" ]
        }
    ],
    ...
}

در برخی موارد، محدود کردن دامنه (scope) یک کلاس به یک pool، subnet یا shared network مفید است. دو پارامتر وجود دارند که با دستور دادن به کارساز برای ارزیابی عبارت‌های آزمون در زمان نیاز، برای محدود کردن دامنه کلاس استفاده می‌شوند.

پارامتر نخست evaluate-additional-classes است که فهرستی از نام‌های کلاس را می‌گیرد و در دامنه pool، subnet و shared network معتبر است. کلاس‌های موجود در این فهرست‌ها به عنوان تکمیلی نشانه‌گذاری می‌شوند و پس از انتخاب آن pool/subnet/shared network خاص و پیش از پردازش گزینه‌های خروجی ارزیابی می‌گردند.

پارامتر دوم، پرچم خاص هر کلاس به نام only-in-additional-list است که به صورت پیش‌فرض false می‌باشد. هنگامی که روی true تنظیم شود، عبارت آزمون کلاس هنگام دریافت بسته ورودی ارزیابی نمی‌شود، بلکه بعداً و تنها در صورتی که کلاس در یک فهرست evaluate-additional-classes موجود باشد ارزیابی خواهد شد.

در این مثال، زمانی که زیرشبکه (subnet) مشخص‌شده استفاده شود، یک کلاس به بسته ورودی اختصاص داده می‌شود:

"Dhcp6": {
    "client-classes": [
       {
           "name": "Client_foo",
           "test": "member('ALL')",
           "only-in-additional-list": true
       },
       ...
    ],
    "subnet6": [
        {
            "subnet": "2001:db8:1::/64",
            "pools": [
                 {
                     "pool": "2001:db8:1::-2001:db8:1::ffff"
                 }
            ],
            "evaluate-additional-classes": [ "Client_foo" ],
            ...
        },
        ...
    ],
    ...
}

ارزیابی تکمیلی می‌تواند برای بیان وابستگی‌های پیچیده مانند عضویت در زیرشبکه استفاده شود. همچنین می‌توان از آن برای معکوس کردن تقدم (precedence) استفاده کرد؛ اگر option-data در یک subnet تنظیم شده باشد، بر option-data در یک کلاس اولویت دارد. اگر option-data به یک کلاس الزامی منتقل شود و در subnet فراخوانی شود، کلاسی که زودتر ارزیابی شده است ممکن است تقدم پیدا کند.

ارزیابی تکمیلی در سطوح shared network و pool/pd-pool نیز در دسترس است. ترتیبی که در آن کلاس‌های تکمیلی بررسی می‌شوند عبارت است از: (pd-)pool، سپس subnet، و در نهایت shared network؛ یعنی به همان ترتیبی که option-data پردازش می‌شود.

از نسخه 2.7.4 نرم‌افزار Kea، کلاس‌های تکمیلی که بدون عبارت آزمون پیکربندی شده‌اند بدون قید و شرط اضافه می‌شوند؛ یعنی همواره با مقدار true ارزیابی می‌شوند.

نکته:

از آنجا که ارزیابی تکمیلی پس از تخصیص اجاره (lease) رخ می‌دهد، پارامترهایی که در غیر این صورت بر طول عمر اجاره تأثیر می‌گذاشتند (مانند valid-lifetime و preferred-lifetime)، چنانچه در کلاسی تعیین شوند که پرچم only-in-additional-list آن روی true تنظیم شده است، هیچ تأثیری نخواهند داشت.

نکته:

از نسخه 2.7.4 نرم‌افزار Kea، شناسه‌های only-if-required و require-client-classes به ترتیب به only-in-additional-list و evaluate-additional-classes تغییر نام یافته‌اند. نام‌های قبلی همچنان به عنوان ورودی معتبر پذیرفته می‌شوند تا کاربران فرصت مهاجرت به ساختار جدید را داشته باشند، اما در نهایت منسوخ و رد خواهند شد.

همان‌طور که پیش‌تر اشاره شد، kea-dhcp6 <#std-iscman-kea-dhcp6> می‌تواند به‌گونه‌ای پیکربندی شود که برای به‌روزرسانی مدخل‌های DNS، درخواست‌هایی را برای کارساز DHCP-DDNS یعنی kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> (که در اینجا به آن "D2" گفته می‌شود) تولید کند. این درخواست‌ها با نام NameChangeRequests یا NCR شناخته می‌شوند. هر NCR شامل اطلاعات زیر است:

1.
اینکه آیا درخواستی برای افزودن (به‌روزرسانی) است یا حذف مدخل‌های DNS.
2.
اینکه آیا تغییر درخواستی برای به‌روزرسانی مستقیم DNS (رکورد‌های AAAA)، به‌روزرسانی معکوس DNS (رکورد‌های PTR)، یا هر دو است.
3.
نام دامنه کاملاً واجد شرایط (FQDN)، نشانی اجاره (lease address)، و DHCID (اطلاعات شناسایی کلاینت مرتبط با FQDN).

پارامترهای مرتبط با DDNS به دو گروه تقسیم می‌شوند:

1.
پارامترهای اتصال (Connectivity Parameters)
این‌ها پارامترهایی هستند که مشخص می‌کنند kea-dhcp6 <#std-iscman-kea-dhcp6> کجا و چگونه به D2 متصل شده و با آن ارتباط برقرار می‌کند. این پارامترها فقط می‌توانند درون بخش سطح بالای dhcp-ddns در پیکربندی kea-dhcp6 <#std-iscman-kea-dhcp6> مشخص شوند. پارامترهای اتصال در زیر فهرست شده‌اند:
  • enable-updates
  • server-ip
  • server-port
  • sender-ip
  • sender-port
  • max-queue-size
  • ncr-protocol
  • ncr-format
2.
پارامترهای رفتاری (Behavioral Parameters)
این پارامترها بر رفتارهایی مانند نحوه مدیریت نام میزبان کلاینت و گزینه‌های FQDN تأثیر می‌گذارند. آن‌ها از بخش dhcp-ddns خارج شده‌اند تا بتوان آن‌ها را در سطوح سراسری (global)، شبکه مشترک (shared-network)، زیرشبکه (subnet) و/یا استخر (pool) مشخص کرد. علاوه بر این، آن‌ها از سطوح بالاتر به پایین به ارث می‌رسند: از سراسری به شبکه مشترک، به زیرشبکه و به استخر. به عبارت دیگر، اگر پارامتری در یک سطح خاص تعیین نشده باشد، مقدار آن سطح از سطح بالاتر دریافت می‌شود. پارامترهای رفتاری به شرح زیر هستند:
  • ddns-send-updates
  • ddns-override-no-update
  • ddns-override-client-update
  • ddns-replace-client-name
  • ddns-generated-prefix
  • ddns-qualifying-suffix
  • ddns-update-on-renew
  • ddns-conflict-resolution-mode
  • ddns-ttl
  • ddns-ttl-percent
  • ddns-ttl-min
  • ddns-ttl-max
  • hostname-char-set
  • hostname-char-replacement

نکته:

در Kea 2.7.6 پشتیبانی از این پارامترها در سطح استخر (نشانی) افزوده شد. این پارامترها در pd-pools پشتیبانی نمی‌شوند.

نکته:

پارامترهای رفتاری که بر FQDN تأثیر می‌گذارند، حتی اگر هر دو گزینهٔ enable-updates و ddns-send-updates برابر با false باشند نیز اعمال می‌شوند؛ این امر برای پشتیبانی از محیط‌هایی است که در آن‌ها کلاینت‌ها مسئول به‌روزرسانی DNS خود هستند. این موضوع برای ddns-replace-client-name، ddns-generated-prefix، ddns-qualifying-suffix، hostname-char-set، و hostname-char-replacement صدق می‌کند.

پیکربندی پیش‌فرض و مقادیر آن به صورت زیر خواهد بود:

"Dhcp6": {
     "dhcp-ddns": {
         // Connectivity parameters
         "enable-updates": false,
         "server-ip": "127.0.0.1",
         "server-port":53001,
         "sender-ip":"",
         "sender-port":0,
         "max-queue-size":1024,
         "ncr-protocol":"UDP",
         "ncr-format":"JSON"
     },
     // Behavioral parameters (global)
     "ddns-send-updates": true,
     "ddns-override-no-update": false,
     "ddns-override-client-update": false,
     "ddns-replace-client-name": "never",
     "ddns-generated-prefix": "myhost",
     "ddns-qualifying-suffix": "",
     "ddns-update-on-renew": false,
     "ddns-conflict-resolution-mode": "check-with-dhcid",
     "hostname-char-set": "[^A-Za-z0-9.-]",
     "hostname-char-replacement": "x",
     ...
}

دو پارامتر وجود دارند که تعیین می‌کنند آیا kea-dhcp6 <#std-iscman-kea-dhcp6> می‌تواند درخواست‌های DDNS را برای D2 تولید کند یا خیر: پارامتر موجود dhcp-ddns:enable-updates که اکنون فقط کنترل می‌کند آیا kea-dhcp6 <#std-iscman-kea-dhcp6> به D2 متصل شود یا خیر؛ و پارامتر رفتاری جدید ddns-send-updates که مشخص می‌کند آیا به‌روزرسانی‌های DDNS در یک سطح مشخص (مانند سراسری، شبکه مشترک یا زیرشبکه) فعال هستند یا خیر. جدول زیر نحوه عملکرد هم‌زمان این دو پارامتر را نشان می‌دهد:.SS فعال و غیرفعال کردن به‌روزرسانی‌های DDNS

dhcp-ddns: enable-updates سراسری ddns-send-updates نتیجه
false (پیش‌فرض) false بدون به‌روزرسانی در هیچ حوزه‌ای
false true (پیش‌فرض) بدون به‌روزرسانی در هیچ حوزه‌ای
true false به‌روزرسانی تنها در حوزه‌هایی با مقدار محلی true برای ddns-enable-updates
true true به‌روزرسانی در تمام حوزه‌ها به‌جز آن‌هایی که مقدار محلی false برای ddns-enable-updates دارند

در Kea 1.9.1 دو پارامتر جدید اضافه شد؛ اولین پارامتر ddns-update-on-renew است. به‌طور معمول، هنگام تمدید اجاره‌ها (leases)، کارساز فقط در صورتی DNS را به‌روزرسانی می‌کند که اطلاعات DNS مربوط به اجاره (مانند FQDN، پرچم‌های جهت به‌روزرسانی DNS) تغییر کرده باشد. تنظیم ddns-update-on-renew روی true به کارساز دستور می‌دهد که هنگام تمدید اجاره همواره اطلاعات DNS را به‌روزرسانی کند، حتی اگر اطلاعات DNS آن تغییری نکرده باشد. این ویژگی به Kea امکان می‌دهد در صورتی که پیش‌تر قادر به افزودن ورودی‌های DNS نبوده یا آن‌ها به هر دلیلی توسط کارساز DNS از دست رفته باشند، «خودترمیم» ("self-heal") انجام دهد.

نکته:

تنظیم ddns-update-on-renew روی true ممکن است بر کارایی تأثیر بگذارد، به‌ویژه برای کارسازهایی با کارخواه‌های متعدد که مکرراً تمدید می‌شوند.

دومین پارامتر اضافه‌شده در Kea 1.9.1 پارامتر ddns-use-conflict-resolution است. این پارامتر بولی (boolean) به D2 منتقل می‌شد و حل تعارض را بر اساس شرح ارائه‌شده در RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703 فعال یا غیرفعال می‌کرد. از نسخه Kea 2.5.0 به بعد، این پارامتر منسوخ شده و با ddns-conflict-resolution-mode جایگزین شده است که چهار حالت رفتار مربوط به حل تعارض را ارائه می‌دهد:

  • check-with-dhcid - این حالت، که پیش‌فرض است، به D2 دستور می‌دهد تا حل تعارض منطبق بر RFC 4703 را انجام دهد. ورودی‌های موجود DNS فقط در صورتی بازنویسی می‌شوند که دارای یک رکورد DHCID باشند و این رکورد با DHCID کارخواه مطابقت داشته باشد. این حالت معادل ddns-use-conflict-resolution: true است؛
  • no-check-with-dhcid - ورودی‌های موجود DNS ممکن است توسط هر کارخواهی بازنویسی شوند، صرف‌نظر از اینکه آن ورودی‌ها شامل رکورد DHCID باشند یا خیر. ورودی‌های جدید شامل یک رکورد DHCID برای کارخواهی خواهند بود که به آن تعلق دارند. این حالت معادل ddns-use-conflict-resolution: false است؛
  • check-exists-with-dhcid - ورودی‌های موجود DNS تنها در صورتی بازنویسی می‌شوند که دارای رکورد DHCID باشند. نیازی نیست رکورد DHCID با DHCID کارخواه مطابقت داشته باشد. این حالت روشی برای محافظت از ورودی‌های ایستا DNS (آن‌هایی که رکورد DHCID ندارند) در حین اجازه دادن به بازنویسی ورودی‌های پویا (آن‌هایی که رکورد DHCID دارند) توسط هر کارخواهی فراهم می‌کند. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد.
  • no-check-without-dhcid - ورودی‌های موجود DNS ممکن است توسط هر کارخواهی بازنویسی شوند؛ ورودی‌های جدید شامل رکوردهای DHCID نخواهند بود. این رفتار پیش از Kea 2.4.0 پشتیبانی نمی‌شد.

نکته:

جهت سازگاری با نسخه‌های پیشین، ddns-use-conflict-resolution همچنان در پیکربندی JSON پذیرفته می‌شود. کارساز این مقدار را در داخل به‌صورت خودکار با ddns-conflict-resolution-mode و مقدار مناسب جایگزین می‌کند: ` check-with-dhcid برای true و no-check-with-dhcid برای false.

نکته:

تنظیم ddns-conflict-resolution-mode روی هر مقداری به‌جز check-with-dhcid، تمهیدات حفاظتی بازنویسی را که قواعد حل تعارض (از RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703) قصد پیشگیری از آن را دارند غیرفعال می‌کند. این بدان معناست که ورودی‌های موجود برای یک FQDN یا یک نشانی IP که برای Client-A ایجاد شده‌اند می‌توانند توسط ورودی‌های Client-B حذف یا جایگزین شوند. علاوه بر این، دو سناریو وجود دارد که از طریق آن‌ها ورودی‌های چند کارخواه برای یک کلید یکسان (مانند FQDN یا IP) ایجاد شود.

1. کارخواه Client-B از همان FQDN مربوط به Client-A اما با یک نشانی IP متفاوت استفاده می‌کند. در این حالت، ورودی‌های مستقیم DNS (رکوردهای AAAA و DHCID) مربوط به Client-A حذف خواهند شد چرا که با FQDN مطابقت دارند، و ورودی‌های جدید برای Client-B اضافه خواهند شد. با این حال، ورودی‌های معکوس DNS (رکوردهای PTR و DHCID) برای Client-A حذف نخواهند شد زیرا متعلق به نشانی IP متفاوتی هستند، در حالی که ورودی‌های جدید برای Client-B همچنان افزوده می‌شوند.

2. کارخواه Client-B از همان نشانی IP مربوط به Client-A اما با یک FQDN متفاوت استفاده می‌کند. در این حالت، ورودی‌های معکوس DNS (رکوردهای PTR و DHCID) مربوط به Client-A حذف خواهند شد چرا که با نشانی IP مطابقت دارند، و ورودی‌های جدید برای Client-B افزوده خواهند شد. با این حال، ورودی‌های مستقیم DNS (رکوردهای AAAA و DHCID) برای Client-A حذف نخواهند شد، زیرا به یک FQDN متفاوت تعلق دارند، در حالی که ورودی‌های جدید برای Client-B همچنان افزوده خواهند شد.

غیرفعال‌سازی حل تعارض تنها باید پس از بررسی دقیق موارد کاربرد خاص انجام شود. بهترین راه برای جلوگیری از ایجاد ورودی‌های ناخواسته DNS این است که همیشه اطمینان حاصل شود پیش از تخصیص مجدد FQDNها یا نشانی‌های IP، تغییرات اجاره از طریق Kea پردازش شوند—خواه آزاد شوند، منقضی شوند یا از طریق دستور lease6-del <#std-isccmd-lease6-del> حذف شوند. انجام این کار باعث می‌شود kea-dhcp6 <#std-iscman-kea-dhcp6> درخواست‌های حذف DNS را به D2 ارسال کند.

ورودی‌های DNS که توسط Kea ایجاد می‌شوند شامل مقداری برای TTL (طول عمر / time to live) هستند. به‌طور پیش‌فرض، کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> این مقدار را بر اساس RFC 4702، بخش ۵ https://datatracker.ietf.org/doc/html/rfc4702#section-5 محاسبه می‌کند، که پیشنهاد می‌کند مقدار TTL برابر با ۱/۳ طول عمر اجاره باشد، با حداقل مقدار ۱۰ دقیقه. چهار پارامتر اختیاری وجود دارند که می‌توان از آن‌ها برای تأثیرگذاری بر محاسبه TTL استفاده کرد:

  • ddns-ttl - در صورت تعیین شدن و بزرگ‌تر بودن از ۰، بدون قید و شرط به عنوان مقدار TTL استفاده می‌شود. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض تعیین‌نشده است.
  • ddns-ttl-percent - در صورت تعیین شدن و بزرگ‌تر بودن از صفر، به عنوان درصد طول عمر اجاره استفاده می‌شود، در غیر این صورت از ۱/۳ (بر اساس RFC 4702) طول عمر اجاره استفاده خواهد شد. این مقدار به‌صورت یک درصد اعشاری (مانند 0.75، 0.50) مشخص می‌شود و به‌طور پیش‌فرض تعیین‌نشده است.
  • ddns-ttl-min - در صورت تعیین شدن و بزرگ‌تر بودن از ۰، به عنوان حداقل مقدار استفاده می‌شود، در غیر این صورت حداقل ۶۰۰ ثانیه (بر اساس RFC 4702) در نظر گرفته خواهد شد. اگر TTL محاسبه‌شده کمتر از مقدار حداقل باشد، مقدار حداقل بازگردانده می‌شود. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض تعیین‌نشده است.
  • ddns-ttl-max - در صورت تعیین شدن و بزرگ‌تر بودن از صفر، TTL محاسبه‌شده را به این مقدار محدود می‌کند. این پارامتر بر حسب ثانیه مشخص می‌شود. به‌طور پیش‌فرض تعیین‌نشده است.

نکته:

مقدار صفر برای هر یک از پارامترهای TTL می‌تواند برای ابطال (یعنی "unspecify" یا لغو تعیین) مقدار به ارث رسیده آن پارامتر از یک حوزه بالاتر استفاده شود.

برای اینکه NCRها به کارگزار D2 برسند، kea-dhcp6 <#std-iscman-kea-dhcp6> باید بتواند با آن ارتباط برقرار کند. kea-dhcp6 <#std-iscman-kea-dhcp6> از پارامترهای پیکربندی زیر برای کنترل این ارتباط استفاده می‌کند:

  • enable-updates - این گزینه ارتباط با kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> را فعال می‌کند تا به‌روزرسانی‌های DDNS ایجاد و ارسال شوند. برای اینکه NCRها تولید و به D2 فرستاده شوند، مقدار آن باید true باشد. مقدار پیش‌فرض آن false است.
  • server-ip - نشانی IPای است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض، رابط محلی loopback روی نشانی 127.0.0.1 است. می‌توان هر یک از نشانی‌های IPv4 یا IPv6 را مشخص کرد.
  • server-port - درگاهی است که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض 53001 است.
  • sender-ip - نشانی IPای است که kea-dhcp6 <#std-iscman-kea-dhcp6> برای ارسال درخواست‌ها به D2 از آن استفاده می‌کند. مقدار پیش‌فرض خالی است که به kea-dhcp6 <#std-iscman-kea-dhcp6> دستور می‌دهد یک نشانی مناسب را انتخاب کند.
  • sender-port - درگاهی است که kea-dhcp6 <#std-iscman-kea-dhcp6> برای ارسال درخواست‌ها به D2 استفاده می‌کند. مقدار پیش‌فرض 0 به kea-dhcp6 <#std-iscman-kea-dhcp6> اعلام می‌کند یک درگاه مناسب انتخاب کند.
  • max-queue-size - حداکثر تعداد درخواست‌هایی است که مجازند در حین انتظار برای ارسال به D2 در صف قرار گیرند. این مقدار از تجمع مهارنشدنی درخواست‌ها در صورتی که سریع‌تر از تحویلشان تولید شوند، جلوگیری می‌کند. اگر تعداد درخواست‌های در صف برای انتقال به این مقدار برسد، به‌روزرسانی DDNS تا زمانی که انباشت صف به اندازه کافی کاهش یابد، متوقف می‌شود. هدف این است که به کارگزار kea-dhcp4 <#std-iscman-kea-dhcp4> اجازه داده شود بدون مواجه شدن با خطر رشد بی‌رویه مصرف حافظه، به عملیات‌های اجاره (lease) خود ادامه دهد. مقدار پیش‌فرض 1024 است.
  • ncr-protocol - پروتکل سوکت مورد استفاده هنگام ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر فقط از UDP پشتیبانی می‌شود.
  • ncr-format - قالب بسته مورد استفاده هنگام ارسال درخواست‌ها به D2 را مشخص می‌کند. در حال حاضر تنها قالب JSON پشتیبانی می‌شود.

به‌طور پیش‌فرض، فرض می‌شود که kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> روی همان دستگاهی اجرا می‌شود که kea-dhcp6 <#std-iscman-kea-dhcp6> در حال اجرا است، و تمام مقادیر پیش‌فرض ذکرشده در بالا باید کافی باشند. با این حال، اگر D2 برای گوش دادن روی نشانی یا درگاه دیگری پیکربندی شده باشد، این مقادیر باید متناسب با آن تغییر کنند. برای نمونه، اگر D2 برای گوش دادن روی 2001:db8::5 درگاه 900 پیکربندی شده باشد، پیکربندی زیر لازم است:

"Dhcp6": {
    "dhcp-ddns": {
        "server-ip": "2001:db8::5",
        "server-port": 900,
        ...
    },
    ...
}

کارگزار kea-dhcp6 <#std-iscman-kea-dhcp6> از رفتار تعیین‌شده برای کارگزارهای DHCP در RFC 4704 https://datatracker.ietf.org/doc/html/rfc4704 پیروی می‌کند. باید در نظر داشت که kea-dhcp6 <#std-iscman-kea-dhcp6> تصمیم اولیه درباره زمان و موارد به‌روزرسانی را اتخاذ کرده و این اطلاعات را در قالب NCRها به D2 هدایت می‌کند. انجام به‌روزرسانی‌های واقعی DNS و مدیریت مواردی چون حل تعارض، در حیطه وظایف خود D2 است (نگاه کنید به کارگزار DHCP-DDNS <#dhcp-ddns-server>). این بخش شرح می‌دهد که چه زمانی kea-dhcp6 <#std-iscman-kea-dhcp6> اقدام به تولید NCRها می‌کند و کدام پارامترهای پیکربندی می‌توانند بر این تصمیم اثر بگذارند. فرض بر این است که هم پارامتر ارتباطی enable-updates و هم پارامتر رفتاری ddns-send-updates برابر با true باشند.

نکته:

در حال حاضر رابط میان kea-dhcp6 <#std-iscman-kea-dhcp6> و D2 تنها از درخواست‌هایی پشتیبانی می‌کند که مدخل‌های DNS را برای یک نشانی IP منفرد به‌روزرسانی می‌کنند. اگر یک اجاره بیش از یک نشانی اعطا کند، kea-dhcp6 <#std-iscman-kea-dhcp6> درخواست به‌روزرسانی DDNS را فقط برای نخستین نشانی از این نشانی‌ها تولید می‌کند.

به‌طور کلی، kea-dhcp6 <#std-iscman-kea-dhcp6> درخواست‌های به‌روزرسانی DDNS را در شرایط زیر ایجاد می‌کند:

1.
یک اجاره جدید در پاسخ به یک DHCPREQUEST اعطا شود؛
2.
یک اجاره موجود تمدید شود اما FQDN مرتبط با آن تغییر کرده باشد؛ یا
3.
یک اجاره موجود در پاسخ به یک DHCPRELEASE آزاد شود.

در حالت دوم، یعنی تمدید اجاره، دو درخواست DDNS صادر می‌شود: یک درخواست برای حذف مدخل‌ها برای FQDN قبلی، و درخواست دوم برای افزودن مدخل‌ها برای FQDN جدید. در حالت سوم، آزادسازی اجاره - یک درخواست DDNS تکی - برای حذف مدخل‌های آن ارسال خواهد شد.

اما در مورد حالت اول، تصمیم‌گیری‌های مربوط به اعطای اجاره جدید پیچیده‌تر است. هنگامی که اجاره جدیدی اعطا می‌شود، kea-dhcp6 <#std-iscman-kea-dhcp6> تنها در صورتی درخواست به‌روزرسانی DDNS ایجاد می‌کند که DHCPREQUEST حاوی گزینه FQDN (کد 39) باشد. به‌طور پیش‌فرض، kea-dhcp6 <#std-iscman-kea-dhcp6> به پرچم‌های N و S مربوط به FQDN که توسط سرویس‌گیرنده مشخص شده‌اند همان‌گونه که در جدول زیر نشان داده شده، احترام می‌گذارد:

پرچم‌های سرویس‌گیرنده: N-S هدف سرویس‌گیرنده پاسخ کارگزار پرچم‌های کارگزار: N-S-O
0-0 سرویس‌گیرنده مایل به انجام به‌روزرسانی‌های مستقیم است، کارگزار باید به‌روزرسانی‌های معکوس را انجام دهد کارگزار درخواستی فقط برای معکوس تولید می‌کند 1-0-0
0-1 کارگزار باید هم به‌روزرسانی‌های مستقیم و هم معکوس را انجام دهد کارگزار درخواستی برای به‌روزرسانی هر دو جهت تولید می‌کند 0-1-0
1-0 سرویس‌گیرنده مایل به انجام هیچ به‌روزرسانی‌ای نیست کارگزار درخواستی تولید نمی‌کند 1-0-0

سطر نخست در جدول بالا نمایانگر "واگذاری سرویس‌گیرنده" (client delegation) است. در اینجا سرویس‌گیرنده DHCP اعلام می‌کند که قصد دارد به‌روزرسانی‌های مستقیم DNS را خود انجام دهد و کارگزار باید به‌روزرسانی‌های معکوس را انجام دهد. به‌طور پیش‌فرض، kea-dhcp6 <#std-iscman-kea-dhcp6> به خواسته سرویس‌گیرنده احترام گذاشته و یک درخواست DDNS به کارگزار D2 برای به‌روزرسانی داده‌های معکوس DNS تولید می‌کند. می‌توان از پارامتر ddns-override-client-update برای دستور به کارگزار جهت نادیده‌گرفتن درخواست‌های واگذاری سرویس‌گیرنده استفاده کرد. هنگامی که این پارامتر true باشد، kea-dhcp6 <#std-iscman-kea-dhcp6> درخواست‌های واگذاری سرویس‌گیرنده را نادیده گرفته و یک درخواست DDNS برای به‌روزرسانی داده‌های مستقیم و معکوس DNS تولید می‌کند. در این حالت، پرچم‌های N-S-O در پاسخ کارگزار به سرویس‌گیرنده به ترتیب 0-1-1 خواهد بود.

(توجه داشته باشید که بر اساس RFC 4702 https://datatracker.ietf.org/doc/html/rfc4702، ترکیب پرچم‌های N=1 و S=1 ممنوع است. در صورت دریافت چنین ترکیبی از سرویس‌گیرنده، بسته توسط kea-dhcp6 <#std-iscman-kea-dhcp6> دور انداخته خواهد شد.)

برای نادیده‌گرفتن واگذاری سرویس‌گیرنده، مقادیر زیر را در فایل پیکربندی تنظیم کنید:

"Dhcp6": {
    "ddns-override-client-update": true,
    ...
}

سطر سوم جدول بالا حالتی را شرح می‌دهد که در آن سرویس‌گیرنده درخواست می‌کند هیچ به‌روزرسانی DNS انجام نشود. می‌توان از پارامتر ddns-override-no-update برای دستور به کارگزار جهت نادیده گرفتن خواسته سرویس‌گیرنده استفاده کرد. هنگامی که این پارامتر true باشد، kea-dhcp6 <#std-iscman-kea-dhcp6> حتی اگر سرویس‌گیرنده درخواست کرده باشد که هیچ به‌روزرسانی‌ای صورت نگیرد، درخواست‌های به‌روزرسانی DDNS را به kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> ارسال می‌کند. پرچم‌های N-S-O در پاسخ کارگزار به سرویس‌گیرنده 0-1-1 خواهد بود.

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

"Dhcp6": {
    "ddns-override-no-update": true,
    ...
}

کارگزار kea-dhcp6 <#std-iscman-kea-dhcp6> در صورتی که درخواست سرویس‌گیرنده فقط شامل گزینه Host Name باشد، همیشه درخواست‌های به‌روزرسانی DDNS را تولید می‌کند. علاوه بر این، یک گزینه FQDN را با پرچم‌های FQDN N-S-O که به ترتیب روی 0-1-0 تنظیم شده‌اند، در پاسخ به سرویس‌گیرنده قرار می‌دهد. بخش نام دامنه از گزینه FQDN، همان نامی است که در درخواست به‌روزرسانی DDNS به D2 ارسال می‌شود..SS kea-dhcp6 <#std-iscman-kea-dhcp6> تولید نام برای درخواست‌های به‌روزرسانی DDNS

هر NameChangeRequest مسلماً باید شامل نام دامنه کاملاً واجد شرایط (FQDN) باشد که مدخل‌های DNS آن قرار است تحت تأثیر قرار گیرند. kea-dhcp6 <#std-iscman-kea-dhcp6> می‌تواند به‌گونه‌ای پیکربندی شود که بخشی از آن نام یا تمامی آن را بر اساس آنچه از کارخواه در DHCPREQUEST دریافت می‌کند، تأمین نماید.

قوانین پیش‌فرض برای ساخت FQDN که برای مدخل‌های DNS استفاده خواهد شد عبارتند از:

1.
اگر DHCPREQUEST شامل گزینه FQDN کارخواه باشد، نام کاندید از آن گرفته می‌شود.
2.
اگر نام کاندید یک نام جزئی (یعنی نامشخص یا فاقد صلاحیت) باشد، یک پسوند قابل‌پیکربندی به نام افزوده شده و از نتیجه به‌عنوان FQDN استفاده می‌شود.
3.
اگر نام کاندید ارائه‌شده خالی باشد، با استفاده از یک پیشوند و پسوند قابل‌پیکربندی، یک FQDN تولید می‌شود.
4.
اگر کارخواه هیچ‌یک از گزینه‌ها را ارائه نکند، هیچ اقدامی روی DNS صورت نمی‌گیرد.

این قوانین را می‌توان با تنظیم پارامتر ddns-replace-client-name اصلاح کرد، که حالت‌های رفتاری زیر را فراهم می‌کند:

  • never - استفاده از نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، نامی تولید نمی‌شود. این حالت پیش‌فرض است.
  • always - جایگزینی نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، یک نام برای کارخواه تولید می‌شود.
  • when-present - جایگزینی نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، نامی تولید نمی‌شود.
  • when-not-present - استفاده از نام ارسالی کارخواه. اگر کارخواه نامی ارسال نکرده باشد، یک نام برای کارخواه تولید می‌شود.

نکته:

در نسخه‌های اولیه Kea، این پارامتر بولی بود و فقط مقادیر true و false را مجاز می‌دانست. مقادیر بولی منسوخ شده‌اند و دیگر پذیرفته نمی‌شوند؛ مدیرانی که در حال حاضر از مقادیر بولی استفاده می‌کنند باید آن‌ها را با نام حالت مورد نظر جایگزین کنند. مقدار true به when-present و مقدار false به never نگاشت می‌شود.

برای نمونه، جهت دستور دادن به kea-dhcp6 <#std-iscman-kea-dhcp6> برای تولید همیشگی FQDN برای یک کارخواه، پارامتر ddns-replace-client-name را مانند زیر روی always تنظیم کنید:

"Dhcp6": {
    "ddns-replace-client-name": "always",
    ...
}

پیشوند مورداستفاده در تولید FQDN توسط پارامتر ddns-generated-prefix مشخص می‌شود. مقدار پیش‌فرض "myhost" است. برای تغییر مقدار آن، کافی است آن را روی رشته دلخواه تنظیم کنید:

"Dhcp6": {
    "ddns-generated-prefix": "another.host",
    ...
}

پسوند مورداستفاده هنگام تولید یک FQDN، یا هنگام کامل‌سازی یک نام جزئی، توسط پارامتر ddns-qualifying-suffix مشخص می‌شود. اکیداً توصیه می‌شود که در صورت فعال بودن به‌روزرسانی‌های DDNS، کاربر مقداری را برای پسوند صلاحیت‌بخش تعیین کند. به دلایل آشکار، ما نمی‌توانیم یک مقدار پیش‌فرض معنادار ارائه دهیم.

"Dhcp6": {
    "ddns-qualifying-suffix": "foo.example.org",
    ...
}

هنگام کامل‌سازی یک نام جزئی، kea-dhcp6 <#std-iscman-kea-dhcp6> نام را در قالب زیر می‌سازد:

[candidate-name].[ddns-qualifying-suffix].

که در آن candidate-name همان نام جزئی ارائه‌شده در DHCPREQUEST است. برای نمونه، اگر مقدار نام دامنه FQDN برابر با "some-computer" و مقدار ddns-qualifying-suffix برابر با "example.com" باشد، FQDN تولیدشده عبارت خواهد بود از:

some-computer.example.com.

هنگام تولید نام کامل، kea-dhcp6 <#std-iscman-kea-dhcp6> نام را در قالب زیر می‌سازد:

[ddns-generated-prefix]-[address-text].[ddns-qualifying-suffix].

که در آن address-text صرفاً همان آدرس IP اجاره (lease) است که به رشته‌ای جداشده با خط تیره تبدیل شده است. برای نمونه، اگر آدرس اجاره 3001:1::70E باشد، پسوند صلاحیت‌بخش "example.com" باشد و از مقدار پیش‌فرض برای ddns-generated-prefix استفاده شود، FQDN تولیدشده عبارت است از:

myhost-3001-1--70E.example.com.

از نسخه 2.7.8 برنامه Kea به بعد، پیشوندهای تولیدشده‌ای که به خط تیره ختم می‌شدند، یک صفر به انتهای آن‌ها اضافه خواهد شد. برای مثال، پیشوند تولیدشده برای آدرس "2001:db8:1::" به صورت "myhost-2001-db8-1--0" خواهد بود..SS پالایش نام‌های FQDN کلاینت

برخی از کلاینت‌های DHCP ممکن است مقادیری را در مؤلفهٔ نام از گزینهٔ FQDN (کد گزینهٔ ۳۹) ارائه دهند که حاوی نویسه‌های نامطلوب باشد. می‌توان kea-dhcp6 <#std-iscman-kea-dhcp6> را برای پالایش این مقادیر پیکربندی کرد. معمول‌ترین مورد کاربرد، اطمینان از این است که تنها نویسه‌های مجاز طبق RFC 1035 شامل شوند: A-Z،‏ a-z،‏ 0-9 و "-". این کار می‌تواند با دو پارامتر زیر انجام شود:

  • hostname-char-set - یک عبارت باقاعده که مجموعه نویسه‌های نامعتبر را توصیف می‌کند. این مقدار می‌تواند هر عبارت باقاعدهٔ معتبری با استفاده از نحو عبارات گسترش‌یافتهٔ POSIX باشد. نویسه‌های تهی نشانده‌شده (0x00) همواره به عنوان یک نویسهٔ نامعتبر در نظر گرفته می‌شوند تا جایگزین (یا حذف) شوند. پیش‌فرض "[^A-Za-z0-9.-]" است. این عبارت با هر نویسه‌ای که حرف، رقم، نقطه یا خط پیوند نباشد مطابقت دارد. اکیداً توصیه می‌شود که این مقدار بر روی یک رشتهٔ خالی ("") تنظیم نشود، زیرا این کار اجازه می‌دهد نویسه‌های غیرقابل‌چاپ در مؤلفهٔ hostname استفاده شوند.
  • hostname-char-replacement - رشته‌ای از صفر یا چند نویسه که هر نویسهٔ نامعتبر در نام میزبان با آن جایگزین می‌شود. یک رشتهٔ خالی باعث می‌شود نویسه‌های نامعتبر به‌جای جایگزین شدن، حذف (OMITTED) شوند. پیش‌فرض "" است.

پیکربندی زیر هر چیزی غیر از یک حرف، رقم، نقطه یا خط پیوند را با حرف "x" جایگزین می‌کند:

"Dhcp6": {
    "hostname-char-set": "[^A-Za-z0-9.-]",
    "hostname-char-replacement": "x",
    ...
}

بدین ترتیب، مقدار ارائه‌شده توسط کلاینت مانند "myhost-$[123.org" به "myhost-xx123.org" تبدیل خواهد شد. پالایش تنها روی بخشی از نام که توسط کلاینت ارائه شده انجام می‌گیرد، و قبل از اعمال پسوند صلاحیت‌بخش (در صورت تعریف و نیاز) اعمال می‌شود.

نکته:

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

اطمینان حاصل کنید که نقطه، یعنی "."، توسط عبارت hostname-char-set به عنوان یک نویسهٔ معتبر در نظر گرفته شود، مانند این: "[^A-Za-z0-9.-]". هنگام پالایش FQDNها، نقطه‌ها به عنوان جداکننده تلقی شده و برای تفکیک مقدار گزینه به برچسب‌های دامنهٔ جداگانه که پالایش شده و سپس مجدداً سرهم می‌شوند، به کار می‌روند.

اگر کلاینت‌ها مقادیری را ارسال می‌کنند که تفاوت آن‌ها فقط در نویسه‌هایی است که توسط hostname-char-set نامعتبر شمرده شده‌اند، آگاه باشید که پالایش آن‌ها به مقادیر یکسان منجر خواهد شد. در چنین مواردی، قواعد تداخل DDNS تنها به یکی از آن‌ها اجازهٔ ثبت نام را می‌دهد.

در نهایت، با توجه به اختیاری که کلاینت‌ها در ارسال مقادیر دارند، عملاً غیرممکن است تضمین شود که ترکیبی از این دو پارامتر همیشه نامی معتبر برای استفاده در DNS به دست دهد. برای نمونه، استفاده از یک مقدار خالی برای hostname-char-replacement در صورتی که برچسب دامنه تنها از نویسه‌های نامعتبر تشکیل شده باشد، می‌تواند منجر به یک برچسب خالی درون یک نام شود.

نکته:

امکان تعیین hostname-char-set و/یا hostname-char-replacement در حوزهٔ سراسری (global scope) وجود دارد.

کتابخانهٔ قلاب کئا با نام libdhcp_ddns_tuning.so <#std-ischooklib-libdhcp_ddns_tuning.so> این قابلیت را برای هر دوی kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> فراهم می‌کند تا نام‌های میزبان را به‌طور رویه‌ای بر پایه یک عبارت ایجاد کنند، از به‌روزرسانی‌های DDNS به‌ازای هر کلاینت صرف‌نظر نمایند، یا جنبه‌های مختلف به‌روزرسانی DNS را به‌دقت تنظیم کنند. لطفاً برای گزینه‌های پیکربندی به مستندات libdhcp_ddns_tuning.so: DDNS Tuning <#hooks-ddns-tuning> مراجعه نمایید.

نکته:

از نسخهٔ Kea 3.1.3 به بعد، هنگامی که پالایش منجر به یک رشتهٔ خالی شود، گزینهٔ FQDN به‌گونه‌ای نادیده گرفته خواهد شد که گویی کلاینت اصلاً آن را ارسال نکرده است. این موضوع می‌تواند در صورتی رخ دهد که مقدار ارسال‌شده توسط کلاینت تنها شامل نویسه‌هایی باشد که توسط عبارت در 'hostname-char-set' نامعتبر شمرده شده و 'hostname-char-replacement' نیز خالی، یعنی "" باشد.

پشتیبانی از انتقال DHCPv4-over-DHCPv6 در RFC 7341 https://datatracker.ietf.org/doc/html/rfc7341 شرح داده شده است و با استفاده از همکاری سرورهای DHCPv4 و DHCPv6 پیاده‌سازی می‌شود. این بخش دربارهٔ پیکربندی سمت DHCPv6 است (سمت DHCPv4 در DHCPv4-over-DHCPv6: DHCPv4 Side <#dhcp4-dhcp4o6-config> شرح داده شده است).

نکته:

جزئیات ارتباط بین‌فرآیندی در DHCPv4-over-DHCPv6 ممکن است تغییر کند؛ برای نمونه، پشتیبانی از رله پورت (RFC 8357) یک تغییر ناسازگار معرفی کرد. هر دو سمت DHCPv4 و DHCPv6 باید نسخهٔ یکسانی از Kea را اجرا کنند.

تنها یک پارامتر ویژه برای سمت DHCPv6 وجود دارد: dhcp4o6-port، که نخستین پورت از دو پورت متوالی سوکت‌های UDP مورد استفاده برای ارتباط میان سرورهای DHCPv6 و DHCPv4 را مشخص می‌کند. سرور DHCPv6 به ::1 روی port مقید (bind) شده و به ::1 روی port + 1 متصل می‌شود.

دو مدخل پیکربندی دیگر نیز معمولاً الزامی هستند: پشتیبانی از ترافیک Unicast (بخش Unicast Traffic Support را ببینید) و گزینهٔ آدرس سرور DHCP 4o6 (نام "dhcp4o6-server-addr"، کد 88).

شرکت ISC پیکربندی زیر را آزمایش کرده است:

{
# DHCPv6 conf
"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "eno33554984/2001:db8:1:1::1" ]
    },
    "lease-database": {
        "type": "memfile",
        "name": "leases6"
    },
    "preferred-lifetime": 3000,
    "valid-lifetime": 4000,
    "renew-timer": 1000,
    "rebind-timer": 2000,
    "subnet6": [ {
        "id": 1,
        "subnet": "2001:db8:1:1::/64",
        "interface": "eno33554984",
        "pools": [ { "pool": "2001:db8:1:1::1:0/112" } ]
    } ],
    "dhcp4o6-port": 786,
    "option-data": [ {
        "name": "dhcp4o6-server-addr",
        "code": 88,
        "space": "dhcp6",
        "csv-format": true,
        "data": "2001:db8:1:1::1"
    } ],
    "loggers": [ {
        "name": "kea-dhcp6",
        "output-options": [ {
            "output": "kea-dhcp6.log"
        } ],
        "severity": "DEBUG",
        "debuglevel": 0
    } ]
}
}

نکته:

پیام‌های بازپخش‌شدهٔ (Relayed) DHCPv6 از نوع DHCPv4-QUERY پشتیبانی نمی‌شوند.

یک جنبه مهم از یک سامانه DHCP با عملکرد مناسب، اطمینان از سازگار ماندن داده‌ها است؛ با این حال، در برخی موارد ممکن است تحمل برخی داده‌های ناسازگار مناسب باشد. برای مثال، یک مدیر شبکه که به طور موقت یک زیرشبکه را از پیکربندی حذف می‌کند، مایل نیست تمام اجاره‌های مرتبط با آن از پایگاه‌داده اجاره‌ها ناپدید شوند. Kea سازوکاری برای پیاده‌سازی بررسی‌های صحت برای شرایطی از این دست دارد.

Kea از یک حوزه پیکربندی به نام sanity-checks پشتیبانی می‌کند. پارامتری به نام lease-checks، اعتبارسنجی انجام‌شده هنگام بارگذاری یک اجاره جدید از یک فایل اجاره را کنترل می‌کند. این سازوکار به Kea اجازه می‌دهد تا برای اصلاح داده‌های ناسازگار تلاش کند.

هر زیرشبکه دارای یک مقدار subnet-id است؛ Kea به این صورت در داخل زیرشبکه‌ها را شناسایی می‌کند. هر اجاره نیز دارای پارامتر subnet-id است که زیرشبکه متعلق به آن را مشخص می‌کند. با این حال، اگر پیکربندی تغییر کرده باشد، ممکن است اجاره‌ای با یک subnet-id وجود داشته باشد بدون اینکه هیچ زیرشبکه منطبقی با آن یافت شود. همچنین، این احتمال وجود دارد که پیکربندی زیرشبکه تغییر کرده باشد و subnet-id اکنون متعلق به زیرشبکه‌ای باشد که با اجاره مطابقت ندارد.

الگوریتم اصلاحی Kea ابتدا بررسی می‌کند که آیا زیرشبکه‌ای با subnet-id مشخص‌شده توسط اجاره وجود دارد یا خیر. اگر وجود داشته باشد، بررسی می‌کند که آیا اجاره متعلق به آن زیرشبکه است یا خیر. در غیر این صورت، بسته به تنظیمات lease-checks، اجاره دور انداخته می‌شود، یک هشدار نمایش داده می‌شود، یا زیرشبکه جدیدی برای اجاره انتخاب می‌شود که از نظر مکان‌شناسی (topologically) با آن همخوانی دارد.

از آنجا که پیشوندهای تفویض‌شده (delegated prefixes) لزوماً نباید متعلق به زیرشبکه‌ای باشند که در آن ارائه می‌شوند، راهی برای پیاده‌سازی چنین سازوکاری برای پیشوندهای IPv6 وجود ندارد. به همین دلیل، این سازوکار تنها برای آدرس‌های IPv6 کار می‌کند.

پنج سطح پشتیبانی می‌شود:

  • none - هیچ بررسی خاصی انجام نده؛ اجاره را همان‌گونه که هست بپذیر.
  • warn - در صورت شناسایی مشکلات، یک هشدار نمایش بده، اما به هر حال داده‌های اجاره را بپذیر. این مقدار پیش‌فرض است.
  • fix - در صورت کشف ناسازگاری در داده‌ها، سعی در اصلاح آن کن. اگر اصلاح موفقیت‌آمیز نبود، به هر حال داده‌های نادرست را درج کن.
  • fix-del - در صورت کشف ناسازگاری در داده‌ها، سعی در اصلاح آن کن. اگر اصلاح موفقیت‌آمیز نبود، اجاره را رد کن. این تنظیم صحت داده‌ها را تضمین می‌کند، اما ممکن است برخی از داده‌های نادرست از دست بروند. با احتیاط استفاده شود.
  • del - در صورت شناسایی هرگونه ناسازگاری، اجاره را رد کن. این سخت‌گیرانه‌ترین حالت است؛ با احتیاط استفاده شود.

این ویژگی در حال حاضر برای backend memfile پیاده‌سازی شده است. بررسی صحت روی پایگاه‌داده اجاره در حافظه اعمال می‌شود، نه روی فایل اجاره؛ یعنی اجاره‌های ناسازگار در فایل اجاره باقی خواهند ماند.

یک نمونه پیکربندی که این پارامتر را تنظیم می‌کند به شرح زیر است:

"Dhcp6": {
    "sanity-checks": {
        "lease-checks": "fix-del"
    },
    ...
}

برای پشتیبانی از ویژگی‌هایی مانند DHCPv6 Reconfigure (RFC 3315 https://datatracker.ietf.org/doc/html/rfc3315) و Leasequery (RFC 5007 https://datatracker.ietf.org/doc/html/rfc5007)، اطلاعات تکمیلی باید همراه با هر اجاره ذخیره شود. از آنجا که حجم اطلاعات ذخیره‌شده برای هر اجاره پیامدهایی از نظر عملکرد و مصرف منابع سیستم دارد، ذخیره‌سازی این اطلاعات تکمیلی از طریق پارامتر store-extended-info قابل پیکربندی است. مقدار پیش‌فرض آن false است و ممکن است در سطوح سراسری (global)، shared-network، و زیرشبکه تنظیم شود.

"Dhcp6": {
    "store-extended-info": true,
    ...
}

هنگامی که روی true تنظیم شود، اطلاعات مربوط به پرس‌وجوی DHCPv6 (مانند REQUEST، RENEW، یا REBIND) که اجاره را درخواست می‌کند، به عنوان یک عنصر نگاشت با برچسب "ISC" به user-context اجاره اضافه می‌شود. در حال حاضر، اطلاعات موجود در این نگاشت فهرستی از رله‌ها است؛ یکی برای هر لایه پیام رله که پرس‌وجوی کلاینت را در بر می‌گیرد. user-context اجاره برای یک پرس‌وجوی با دو جهش (two-hop) ممکن است چیزی شبیه به این باشد (برای وضوح بیشتر به صورت ساختاریافته نمایش داده شده است):

{
    "ISC": {
        "relay-info": [
        {
            "hop": 3,
            "link": "2001:db8::1",
            "peer": "2001:db8::2"
        },
        {
            "hop": 2,
            "link": "2001:db8::3",
            "options": "0x00C800080102030405060708",
            "peer": "2001:db8::4"
        },
        {
            "hop": 1,
            "link": "2001:db8::5",
            "options": "0x00250006010203040506003500086464646464646464",
            "remote-id": "010203040506",
            "relay-id": "6464646464646464"
        }
        ]
    }
}

نکته:

پیش از نسخه 2.3.2 برنامه Kea، این ورودی relays نامیده می‌شد؛ گزینه‌های شناسه‌گر راه دور (remote) و رله رمزگشایی نمی‌شدند.

نکته:

این احتمال وجود دارد که سایر کتابخانه‌های قلاب (hook libraries) قبلاً از user-context استفاده کرده باشند. فعال کردن store-extended-info نباید با محتوای دیگر user-context تداخلی ایجاد کند، تا زمانی که آن‌ها نیز از عنصری با برچسب "ISC" استفاده نکنند. به عبارت دیگر، user-context به عنوان یک ظرف انعطاف‌پذیر برای برآورده کردن اهداف متعدد در نظر گرفته شده است. تا زمانی که هدف دیگری نیز یک عنصر "ISC" در user-context ننویسد، نباید هیچ تداخلی وجود داشته باشد.

اطلاعات توسعه‌یافته اجاره نیز مشمول بررسی صحت قابل پیکربندی است. پارامتر موجود در حوزه sanity-checks به نام extended-info-checks است و از این سطوح پشتیبانی می‌کند:

  • none - هیچ بررسی یا ارتقایی انجام نده. این سطح فقط باید زمانی استفاده شود که از اطلاعات توسعه‌یافته اصلاً استفاده نمی‌شود یا انتظار هیچ اطلاعات توسعه‌یافته با قالب‌بندی نادرست، از جمله استفاده از قالب قدیمی، وجود ندارد.
  • fix - برخی از ناسازگاری‌های رایج را برطرف کن و اطلاعات توسعه‌یافته با قالب قدیمی را به قالب جدید ارتقا بده. این سطح پیش‌فرض است و زمانی مناسب است که کتابخانه قلاب Leasequery بارگذاری نشده باشد.
  • strict - تمام ناسازگاری‌هایی را که بر کتابخانه قلاب (Bulk) Leasequery تأثیر دارند، برطرف کن.
  • pedantic - انطباق کامل با قالبی که توسط کد Kea تولید می‌شود را اعمال کن؛ برای مثال، به استثنای comment هیچ ورودی اضافه دیگری مجاز نیست.

نکته:

این ویژگی در حال حاضر تنها برای backend memfile پیاده‌سازی شده است. بررسی صحت روی پایگاه‌داده اجاره در حافظه اعمال می‌شود، نه روی فایل اجاره؛ یعنی اجاره‌های ناسازگار در فایل اجاره باقی می‌مانند.

سرور Kea را می‌توان برای پردازش موازی بسته‌ها با استفاده از چند ریسمان (thread) پیکربندی کرد. این تنظیمات در ساختار multi-threading یافت می‌شوند و با پارامترهای زیر مشخص می‌گردند:

  • enable-multi-threading - استفاده از چندین ریسمان برای پردازش موازی بسته‌ها. مقدار پیش‌فرض true است.
  • thread-pool-size - تعیین تعداد ریسمان‌ها برای پردازش موازی بسته‌ها. می‌تواند روی 0 (تشخیص خودکار) یا هر عدد مثبتی که تعداد ریسمان‌ها را به‌طور صریح مشخص کند تنظیم شود. مقدار پیش‌فرض 0 است.
  • packet-queue-size - تعیین اندازهٔ صف مورد استفاده توسط استخر ریسمان (thread pool) برای پردازش بسته‌ها. می‌تواند روی 0 (نامحدود) یا هر عدد مثبتی که اندازهٔ صف را به‌طور صریح مشخص کند تنظیم شود. مقدار پیش‌فرض 64 است.

یک نمونه پیکربندی که این پارامترها را تنظیم می‌کند به صورت زیر است:

"Dhcp6": {
    "multi-threading": {
       "enable-multi-threading": true,
       "thread-pool-size": 4,
       "packet-queue-size": 16
    },
    ...
}

سرور Kea DHCPv6 توسط ISC بنچمارک شده است تا مشخص شود چه تنظیماتی بهترین کارایی را ارائه می‌دهند. اگرچه این بخش نتایج ما را شرح می‌دهد، اما آنها صرفاً پیشنهاد هستند و به سخت‌افزار خاص مورد استفاده برای محک‌زنی بستگی زیادی دارند. قویاً توصیه می‌کنیم که مدیران سیستم بنچمارک‌های کارایی مختص به خود را اجرا کنند.

گزارش کاملی از نتایج کارایی برای آخرین نسخهٔ پایدار Kea را می‌توان در اینجا یافت: https://reports.kea.isc.org. این گزارش شامل توضیحات سخت‌افزار و سناریوی بنچمارک، و همچنین نتایج فعلی است.

پس از فعال‌سازی چندریسمانی، تعداد ریسمان‌ها با پارامتر thread-pool-size تعیین می‌شود. نتایج حاصل از آزمایش‌های ما نشان می‌دهد که بهترین تنظیمات برای kea-dhcp6 <#std-iscman-kea-dhcp6> عبارتند از:

  • thread-pool-size: برابر با 4 هنگام استفاده از memfile برای ذخیرهٔ اجاره‌ها (leases).
  • thread-pool-size: برابر با 12 یا بیشتر هنگام استفاده از mysql برای ذخیرهٔ اجاره‌ها.
  • thread-pool-size: برابر با 6 هنگام استفاده از postgresql.

پارامتر بسیار مهم دیگر packet-queue-size است؛ در بنچمارک‌هایمان ما آن را به عنوان ضریبی از thread-pool-size استفاده کردیم. مقدار واقعی به‌شدت به thread-pool-size وابسته است.

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

  • packet-queue-size: برابر با 150 * thread-pool-size هنگام استفاده از memfile برای ذخیرهٔ اجاره‌ها؛ در مورد ما، این مقدار 150 * 4 = 600 بود. این بدان معناست که در هر لحظه، حداکثر تا ۶۰۰ بسته می‌توانند در صف قرار گیرند.
  • packet-queue-size: برابر با 200 * thread-pool-size هنگام استفاده از mysql برای ذخیرهٔ اجاره‌ها؛ در مورد ما، این مقدار 200 * 12 = 2400 بود. این بدان معناست که حداکثر تا ۲۴۰۰ بسته می‌توانند در صف قرار گیرند.
  • packet-queue-size: برابر با 11 * thread-pool-size هنگام استفاده از postgresql برای ذخیرهٔ اجاره‌ها؛ در مورد ما، این مقدار 11 * 6 = 66 بود.

کلاینت‌هایی که در بازهٔ زمانی کوتاهی چندین بار تلاش برای تمدید اجاره می‌کنند، می‌توانند باعث شوند سرور به‌طور مکرر پایگاه‌داده را به‌روزرسانی کرده و در آن بنویسد، که نتیجهٔ آن افت کارایی سرور خواهد بود. پارامترهای حافظه‌نهان (cache) به سرور DHCP دستور می‌دهند که از به‌روزرسانی بیش‌ازحد مکرر اجاره‌ها خودداری کند و بدین ترتیب از این رفتار جلوگیری شود. در عوض، سرور همان اجاره را بدون هیچ تغییری تخصیص می‌دهد (یعنی از آن دوباره استفاده می‌کند)، به‌جز CLTT (Client Last Transmission Time)، که نیازی به عملیات دیسک ندارد.

این دو پارامتر عبارتند از عدد اعشاری cache-threshold و عدد صحیح cache-max-age. این پارامترها را می‌توان در سطوح سراسری (global)، شبکهٔ مشترک (shared-network) و زیرشبکه (subnet) پیکربندی کرد. سطح زیرشبکه نسبت به سطح شبکهٔ مشترک اولویت دارد، در حالی که سطح سراسری به عنوان آخرین چاره استفاده می‌شود. به عنوان مثال:

{
"subnet6": [
    {
        "subnet": "2001:db8:1:1::/64",
        "pools": [ { "pool": "2001:db8:1:1::1:0/112" } ],
        "cache-threshold": .25,
        "cache-max-age": 600,
        "valid-lifetime": 2000,
        ...
    }
],
...
}

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

  • هرگونه تغییر مهم، به عنوان مثال در پارامتر DDNS، نام میزبان (hostname)، یا کاهش طول عمر ترجیحی یا معتبر، مانع از استفادهٔ مجدد از اجاره می‌شود.
  • عمر اجاره (lease age)، یعنی تفاوت میان زمان ایجاد یا آخرین تغییر با زمان فعلی، محاسبه می‌شود (مدت‌زمان سپری‌شده).
  • اگر cache-max-age به‌طور صریح پیکربندی شده باشد، با عمر اجاره مقایسه می‌شود؛ اجاره‌هایی که بیش از حد قدیمی باشند قابل استفادهٔ مجدد نیستند. این بدان معناست که مقدار 0 برای cache-max-age، قابلیت حافظه‌نهان اجاره را غیرفعال می‌کند.
  • اگر cache-threshold به‌طور صریح پیکربندی شده باشد و بین 0.0 و 1.0 باشد، بیانگر درصدی از طول عمر معتبر (valid lifetime) اجاره است که برای عمر اجاره مجاز است. مقادیر کمتر و مساوی 0.0 و مقادیر بیشتر از 1.0، قابلیت حافظه‌نهان اجاره را غیرفعال می‌کنند.

در مثال ما، اجاره‌ای با طول عمر معتبر ۲۰۰۰ ثانیه در صورتی می‌تواند مجدداً استفاده شود که کمتر از ۵۰۰ ثانیه پیش ثبت شده باشد. با طول عمر ۳۰۰۰ ثانیه، حداکثر عمر ۶۰۰ ثانیه اعمال می‌شود.

در پاسخ‌های خروجی به کلاینت (مانند پیام‌های DHCPV6_REPLY)، طول عمرهای ترجیحی و معتبر استفاده‌شده همان مقادیر قابل استفادهٔ مجدد هستند، یعنی تاریخ‌های انقضا تغییر نمی‌کنند..SS رزروهای میزبان در DHCPv6

موارد متعددی وجود دارد که در آن‌ها ارائهٔ پیکربندی بر مبنای هر میزبان (per-host) مفید است. بارزترین مورد، رزرو یک نشانی IPv6 یا/و پیشوند مشخص و ایستا برای استفادهٔ انحصاری یک کلاینت (میزبان) خاص است؛ کلاینتِ بازگشتی، هر بار همان نشانی یا/و پیشوند را دریافت می‌کند و سایر کلاینت‌ها هرگز آن نشانی را دریافت نخواهند کرد. همچنین رزروهای میزبان در مواقعی که یک میزبان نیازمندی‌های خاصی دارد، سودمند هستند؛ به عنوان مثال چاپگری که به گزینه‌های DHCP اضافی نیاز دارد یا یک مودم کابلی که به پارامترهای مشخصی نیازمند است. یکی دیگر از موارد کاربرد ممکن، تعریف نام‌های یکتا برای میزبان‌ها است.

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

رزروهای میزبان به عنوان پارامترهایی برای هر زیرشبکه تعریف می‌شوند. هر میزبان باید یا با DUID یا با نشانی سخت‌افزاری/MAC خود شناسایی شود؛ برای جزئیات به MAC/Hardware Addresses in DHCPv6 مراجعه کنید. یک آرایهٔ اختیاری reservations در ساختار subnet6 وجود دارد؛ هر عنصر در آن آرایه ساختاری است که اطلاعات مربوط به رزروها را برای یک میزبان منفرد نگه می‌دارد. به طور خاص، این ساختار دارای یک شناسه است که یک میزبان را به طور یکتا مشخص می‌کند. در زمینهٔ DHCPv6، این شناسه معمولاً یک DUID است، اما می‌تواند یک نشانی سخت‌افزاری یا MAC نیز باشد. همچنین ممکن است یک یا چند نشانی یا پیشوند مشخص شود، و امکان تعیین hostname و گزینه‌های DHCPv6 برای یک میزبان معین وجود دارد.

نکته:

نشانی رزروشده باید در محدودهٔ زیرشبکه باشد. این موضوع در مورد پیشوندهای رزروشده صدق نمی‌کند.

مثال زیر نحوهٔ رزرو نشانی‌ها و پیشوندها را برای میزبان‌های مشخص نشان می‌دهد:

{
"subnet6": [
    {
        "id": 1,
        "subnet": "2001:db8:1::/48",
        "pools": [ { "pool": "2001:db8:1::/80" } ],
        "pd-pools": [
            {
                "prefix": "2001:db8:1:8000::",
                "prefix-len": 56,
                "delegated-len": 64
            }
        ],
        "reservations": [
            {
                "duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
                "ip-addresses": [ "2001:db8:1::100" ]
            },
            {
                "hw-address": "00:01:02:03:04:05",
                "ip-addresses": [ "2001:db8:1::101", "2001:db8:1::102" ]
            },
            {
                "duid": "01:02:03:04:05:06:07:08:09:0A",
                "ip-addresses": [ "2001:db8:1::103" ],
                "prefixes": [ "2001:db8:2:abcd::/64" ],
                "hostname": "foo.example.com"
            }
        ]
    }
],
...
}

این مثال شامل رزروهایی برای سه کلاینت مختلف است. رزرو نخست برای نشانی 2001:db8:1::100 و برای کلاینتی است که از DUID با مقدار 01:02:03:04:05:0A:0B:0C:0D:0E استفاده می‌کند. رزرو دوم برای دو نشانی 2001:db8:1::101 و 2001:db8:1::102 برای کلاینتی است که از نشانی MAC با مقدار 00:01:02:03:04:05 استفاده می‌کند. در نهایت، نشانی 2001:db8:1::103 و پیشوند 2001:db8:2:abcd::/64 برای کلاینتی با DUID مقدار 01:02:03:04:05:06:07:08:09:0A رزرو شده‌اند. آخرین رزرو همچنین یک hostname به این کلاینت اختصاص می‌دهد.

پروتکل DHCPv6 به یک کلاینت اجازه می‌دهد به طور هم‌زمان چندین نشانی و چندین پیشوند را اجاره کند. بنابراین ip-addresses و prefixes به صورت جمع هستند و در واقع آرایه می‌باشند. هنگامی که کلاینت چندین گزینهٔ IA (از نوع IA_NA یا IA_PD) ارسال می‌کند، هر نشانی یا پیشوند رزروشده به یک IA جداگانه از نوع مناسب اختصاص می‌یابد. اگر تعداد IAهای یک نوع خاص کمتر از تعداد رزروهای آن نوع باشد، تعداد نشانی‌ها یا پیشوندهای رزروشدهٔ اختصاص‌یافته به کلاینت برابر با تعداد IA_NAها یا IA_PDهای ارسال‌شده توسط کلاینت خواهد بود؛ بدین معنی که برخی از نشانی‌ها یا پیشوندهای رزروشده اختصاص نمی‌یابند. با این حال، آن‌ها همچنان برای این کلاینت رزرو باقی می‌مانند و سرور آن‌ها را به هیچ کلاینت دیگری اختصاص نخواهد داد. اگر تعداد IAهای یک نوع خاص که توسط کلاینت ارسال شده است بیشتر از تعداد نشانی‌ها یا پیشوندهای رزروشده باشد، سرور تلاش می‌کند تا تمام نشانی‌ها یا پیشوندهای رزروشده را به تک‌تک IAها اختصاص دهد و نشانی‌ها یا پیشوندها را به صورت پویا به IAهای باقی‌مانده تخصیص دهد. چنانچه سرور نتواند یک نشانی یا پیشوند رزروشده را به دلیل در حال استفاده بودن اختصاص دهد، نشانی یا پیشوند رزروشدهٔ بعدی را انتخاب کرده و تلاش می‌کند آن را به کلاینت اختصاص دهد. اگر سرور متعاقباً دریابد که دیگر هیچ رزروی وجود ندارد که بتوان در آن لحظه به کلاینت اختصاص داد، تلاش خواهد کرد اجاره‌ها را به صورت پویا اختصاص دهد.

ایجاد رزرو برای یک میزبان متحرک که ممکن است در چندین زیرشبکه رفت‌وآمد داشته باشد، نیازمند تعریف میزبان جداگانه در هر زیرشبکه‌ای است که انتظار می‌رود میزبان در آن حضور یابد. امکان تعریف چندین تعریف میزبان با یک نشانی سخت‌افزاری یکسان در یک زیرشبکهٔ منفرد وجود ندارد. چند تعریف میزبان با یک نشانی سخت‌افزاری یکسان در صورتی معتبر هستند که هر کدام در زیرشبکهٔ متفاوتی باشند. رزرو برای یک میزبان معین باید تنها شامل یک شناسه باشد، یا DUID یا نشانی سخت‌افزاری؛ تعریف هر دو برای یک میزبان، خطای پیکربندی در نظر گرفته می‌شود.

افزودن رزروهای میزبان باعث افت کارایی می‌شود. در اصل، هنگامی که سروری بدون پشتیبانی از رزرو میزبان به یک پرس‌وجو پاسخ می‌دهد، تنها باید بررسی کند که آیا برای نشانی مورد نظر جهت تخصیص یا تمدید، اجاره‌ای وجود دارد یا خیر. اما سروری که از رزرو میزبان پشتیبانی می‌کند باید بررسی‌های بیشتری انجام دهد: نه تنها این که آیا نشانی در حال حاضر استفاده می‌شود (یعنی آیا اجاره‌ای برای آن وجود دارد یا خیر)، بلکه آیا نشانی می‌تواند توسط شخص دیگری استفاده شود (یعنی آیا رزروی برای آن وجود دارد یا خیر). این بررسی اضافی بار پردازشی بیشتری تحمیل می‌کند..SS انواع رزرو آدرس/پیشوند

در یک سناریوی معمول Kea، یک زیرشبکه IPv6 تعریف شده است که بخش معینی از آن به تخصیص پویای آدرس توسط کارساز DHCPv6 اختصاص دارد. ممکن است فضای آدرس بیشتری نیز برای واگذاری پیشوند (prefix delegation) تعریف شده باشد. این بخش‌های پویا با عنوان استخرهای پویا، استخرهای آدرس و پیشوند، یا به طور ساده استخرها (pools) شناخته می‌شوند. در اصل، یک رزرو میزبان می‌تواند هر آدرس یا پیشوندی را که متعلق به زیرشبکه است، رزرو کند. به رزروهایی که آدرس‌های متعلق به استخرهای پیکربندی‌شده را مشخص می‌کنند، "رزروهای درون‌استخری" گفته می‌شود. در مقابل، به رزروهایی که متعلق به استخرهای پویا نیستند، "رزروهای بیرون‌استخری" می‌گویند. هیچ تفاوت رسمی‌ای در ساختار نحوی رزرو وجود ندارد و با هر دو نوع رزرو به‌صورت یکسان رفتار می‌شود.

نرم‌افزار Kea از رزروهای سراسری میزبان پشتیبانی می‌کند. این‌ها رزروهایی هستند که در سطح سراسری در پیکربندی مشخص می‌شوند و متعلق به هیچ زیرشبکهٔ خاصی نیستند. Kea همچنان بسته‌های ورودی کلاینت را مطابق گذشته به یک زیرشبکه تطبیق می‌دهد، اما هنگامی که حالت رزرو زیرشبکه روی "global" تنظیم شده باشد، Kea رزروهای میزبان را تنها در میان رزروهای سراسریِ تعریف‌شده جستجو می‌کند. معمولاً چنین رزروهایی برای رزرو نام میزبان کلاینت‌هایی به کار می‌روند که ممکن است از یک زیرشبکه به زیرشبکهٔ دیگر جابجا شوند.

نکته:

رزروهای سراسری، اگرچه در شرایط خاصی سودمند هستند، اما جنبه‌هایی دارند که هنگام استفاده از آن‌ها باید به‌دقت مد نظر قرار گیرند. لطفاً برای جزئیات بیشتر به بخش «تداخل‌ها در رزروهای DHCPv6» مراجعه کنید.

نکته:

از نسخه Kea 1.9.1، حالت رزرو با سه پرچم بولی reservations-global، reservations-in-subnet و reservations-out-of-pool جایگزین شده است که امکان پیکربندی رزروهای میزبان را هم به‌صورت سراسری و هم در یک زیرشبکه فراهم می‌سازند. در چنین مواردی، در صورتی که هر دو رزرو برای یک کلاینت یکسان وجود داشته باشند، رزرو میزبان زیرشبکه بر رزرو سراسری ارجحیت دارد.

نکته:

با شروع از Kea 2.7.3، ساختار نحوی رزرو میزبان از مدخل جدیدی با نام excluded-prefixes پشتیبانی می‌کند. از این مدخل می‌توان برای مشخص کردن پیشوندهایی که کلاینت باید از پیشوندهای واگذار شده استثنا کند استفاده کرد. در صورت وجود، این مدخل باید دقیقاً تعداد عناصری برابر با مدخل prefixes داشته باشد. هر دو مدخل حاوی رشته‌هایی هستند که پیشوندهای IPv6 را نشان می‌دهند. هر عنصر excluded-prefixes باید یک رشتهٔ خالی باشد یا با پیشوند موجود در همان جایگاه در prefixes مطابقت داشته باشد. یک فهرست excluded-prefixes خالی یا فهرستی که فقط حاوی رشته‌های خالی باشد را می‌توان حذف کرد. نمونه‌ای که 2001:db8:0:1::/64 را از 2001:db8::/48 مستثنی می‌کند در زیر نشان داده شده است:
{
"reservations": [
    {
        "duid": "01:02:03:04:05:06:07:08:09:0A",
        "ip-addresses": [ "2001:db8:1::103" ],
        "prefixes": [ "2001:db8::/48" ],
        "excluded-prefixes": [ "2001:db8:0:1::/64" ],
        "hostname": "foo.example.com"
    }
],
...
}

نکته:

از آنجا که رزروهای میزبان نسبت به استخرهای پیشوند اولویت دارند، یک پیشوند رزروشدهٔ فاقد پیشوند استثنا شده، گزینهٔ pd-exclude را به گزینهٔ پیشوند اضافه نخواهد کرد؛ حتی اگر پیشوند واگذار شده درون یک استخر پیشوند پیکربندی‌شده قرار داشته باشد که یک پیشوند استثنا شده را مشخص کرده است (برخلاف رفتار قبلی).

از آنجا که اطلاعات رزرو و اطلاعات اجاره به‌صورت جداگانه ذخیره می‌شوند، ممکن است تداخل رخ دهد. توالی رویدادهای زیر را در نظر بگیرید: کارساز یک استخر پویای آدرس را در بازهٔ 2001:db8::10 تا 2001:db8::20 پیکربندی کرده است. میزبان A درخواست آدرس می‌دهد و 2001:db8::10 را دریافت می‌کند. اکنون مدیر سیستم تصمیم می‌گیرد آدرس 2001:db8::10 را برای میزبان B رزرو کند. به‌طور کلی، رزرو آدرسی که در حال حاضر به شخص دیگری اختصاص داده شده است پیشنهاد نمی‌شود، اما سناریوهای معتبری وجود دارند که انجام چنین عملیاتی در آن‌ها موجه است.

اکنون کارساز تداخلی دارد که باید برطرف شود. اگر میزبان B راه‌اندازی شود و درخواست آدرس کند، کارساز نمی‌تواند بلافاصله آدرس رزروشدهٔ 2001:db8::10 را به آن تخصیص دهد. یک رویکرد ساده‌لوحانه این خواهد بود که فوراً اجارهٔ میزبان A حذف شده و یک اجارهٔ جدید برای میزبان B ایجاد شود. با این حال، این کار مشکل را حل نمی‌کند، زیرا به محض اینکه میزبان B آدرس را دریافت کند، متوجه می‌شود که این آدرس از قبل (توسط میزبان A) در حال استفاده است و یک پیام DHCPDECLINE ارسال می‌کند. بنابراین، در این وضعیت، کارساز باید موقتاً آدرس متفاوتی از استخر پویا (که با آنچه رزرو شده مطابقت ندارد) را به میزبان B تخصیص دهد.

هنگامی که میزبان A آدرس خود را تمدید می‌کند، کارساز متوجه می‌شود که آدرس در حال تمدید، اکنون برای فرد دیگری - میزبان B - رزرو شده است. کارساز اجارهٔ 2001:db8::10 را حذف کرده، آدرس جدیدی را انتخاب می‌کند و یک اجارهٔ جدید برای آن ایجاد می‌نماید. کارساز در پاسخ خود دو آدرس ارسال می‌کند: آدرس قدیمی با طول عمر (lifetime) تنظیم‌شده روی 0 تا صراحتاً نشان دهد که دیگر معتبر نیست؛ و آدرس جدید با یک طول عمر غیرصفر. هنگامی که میزبان B تلاش می‌کند آدرسِ موقتاً تخصیص‌یافتهٔ خود را تمدید کند، کارساز متوجه می‌شود که اجارهٔ موجود با رزرو مطابقت ندارد، بنابراین آدرس فعلیِ میزبان B را آزاد کرده و یک اجارهٔ جدید منطبق با رزرو می‌سازد. همانند قبل، کارساز دو آدرس ارسال می‌کند: آدرس موقتاً تخصیص‌یافته با طول عمر صفر، و آدرس جدیدِ مطابق با رزرو همراه با طول عمر مناسب.

این روند بازیابی حتی در صورتی که سایر میزبان‌ها برای دریافت آدرس رزروشده تلاش کنند نیز موفقیت‌آمیز خواهد بود. اگر میزبان C پس از ایجاد رزرو، آدرس 2001:db8::10 را درخواست کند، کارساز آدرس متفاوتی را پیشنهاد خواهد داد.

این سازوکار بازیابی به کارساز امکان می‌دهد تا از شرایطی که رزروها با اجاره‌های موجود تداخل دارند، به‌طور کامل بازیابی شود؛ هرچند اجرای این فرایند تقریباً به اندازه مقدار تنظیم‌شده برای renew-timer زمان می‌برد. بهترین روش برای جلوگیری از چنین روندی، تعریف نکردن رزروهای جدیدی است که با اجاره‌های موجود تداخل داشته باشند. توصیهٔ دیگر، استفاده از رزروهای بیرون‌استخری است؛ اگر آدرس رزروشده متعلق به یک استخر نباشد، کلاینت‌های دیگر به هیچ وجه نمی‌توانند آن را دریافت کنند.

نکته:

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

هنگامی که رزرو برای یک کلاینت شامل hostname باشد، سرور این نام میزبان را به کلاینت تخصیص داده و در صورتی که کلاینت گزینهٔ Client FQDN را در پیام ارسالی خود به سرور گنجانده باشد، آن را در گزینهٔ Client FQDN بازمی‌گرداند. نام میزبان رزروشده همواره نسبت به نام میزبان ارائه‌شده توسط کلاینت (از طریق گزینهٔ FQDN) یا نام میزبان تولیدشده به‌صورت خودکار (از روی نشانی IPv6) اولویت دارد.

سرور نام میزبان رزروشده را با مقدار پارامتر ddns-qualifying-suffix تکمیل می‌کند. برای نمونه، پیکربندی زیرشبکهٔ زیر:

{
"subnet6": [
    {
        "id": 1,
        "subnet": "2001:db8:1::/48",
        "pools": [ { "pool": "2001:db8:1::/80" } ],
        "ddns-qualifying-suffix": "example.isc.org.",
        "reservations": [
            {
                "duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
                "ip-addresses": [ "2001:db8:1::100" ],
                "hostname": "alice-laptop"
            }
        ]
    }
],
"dhcp-ddns": {
    "enable-updates": true
},
...
}

باعث می‌شود نام میزبان "alice-laptop.example.isc.org." به کلاینت دارای DUID با مقدار "01:02:03:04:05:0A:0B:0C:0D:0E" تخصیص یابد. اگر ddns-qualifying-suffix مشخص نشده باشد، مقدار پیش‌فرض (خالی) استفاده خواهد شد و در این حالت مقدار مشخص‌شده برای hostname به عنوان یک نام کامل دامنه (fully qualified name) در نظر گرفته می‌شود. بنابراین، با خالی گذاشتن ddns-qualifying-suffix می‌توان نام‌های میزبان را برای کلاینت‌های مختلف با نام‌های دامنهٔ متفاوت تکمیل کرد:

{
  "subnet6": [
    {
        "id": 1,
        "subnet": "2001:db8:1::/48",
        "pools": [ { "pool": "2001:db8:1::/80" } ],
        "reservations": [
            {
                "duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
                "ip-addresses": [ "2001:db8:1::100" ],
                "hostname": "mark-desktop.example.org."
            }
        ]
    }
  ],
  "dhcp-ddns": {
      "enable-updates": true
  }
}

مثال بالا منجر به تخصیص نام میزبان "mark-desktop.example.org." به کلاینت دارای DUID با مقدار "01:02:03:04:05:0A:0B:0C:0D:0E" می‌شود.

نرم‌افزار Kea امکان تعیین گزینه‌ها را بر پایهٔ هر میزبان فراهم می‌کند. این گزینه‌ها از همان قواعد سایر گزینه‌ها پیروی می‌کنند. این موارد می‌توانند گزینه‌های استاندارد (بخش Standard DHCPv6 Options را ببینید)، گزینه‌های سفارشی (بخش Custom DHCPv6 Options را ببینید)، یا گزینه‌های ویژهٔ سازنده (بخش DHCPv6 Vendor-Specific Options را ببینید) باشند. مثال زیر نحوهٔ تعریف گزینه‌های استاندارد را نشان می‌دهد.

{
"reservations": [
{
    "duid": "01:02:03:05:06:07:08",
    "ip-addresses": [ "2001:db8:1::2" ],
    "option-data": [
    {
        "name": "dns-servers",
        "data": "3000:1::234"
    },
    {
        "name": "nis-servers",
        "data": "3000:1::234"
    },
    ...
    ],
    ...
},
...
],
...
}

گزینه‌های ویژهٔ سازنده را می‌توان به شیوه‌ای مشابه رزرو کرد:

{
"reservations": [
{
    "duid": "aa:bb:cc:dd:ee:ff",
    "ip-addresses": [ "2001:db8::1" ],
    "option-data": [
    {
        "name": "vendor-opts",
        "data": 4491
    },
    {
        "name": "tftp-servers",
        "space": "vendor-4491",
        "data": "3000:1::234"
    },
    ...
    ],
    ...
},
...
],
...
}

گزینه‌های تعریف‌شده در سطح میزبان بالاترین اولویت را دارند. به بیان دیگر، اگر گزینه‌هایی با نوع یکسان در سطوح سراسری (global)، زیرشبکه (subnet)، کلاس (class) و میزبان (host) تعریف شده باشند، مقادیر اختصاصی میزبان استفاده می‌شوند..SS رزرو کلاس‌های کلاینت در DHCPv6

بخش «استفاده از عبارت‌ها در دسته‌بندی» <#classification-using-expressions> توضیح می‌دهد که چگونه سرور را پیکربندی کنید تا بر اساس محتوای گزینه‌هایی که کلاینت به سرور ارسال می‌کند، کلاس‌هایی را به آن اختصاص دهد. سازوکارهای رزرو میزبان (Host reservation) نیز امکان تخصیص ایستای کلاس‌ها به کلاینت‌ها را فراهم می‌کنند. تعاریف این کلاس‌ها در فایل پیکربندی Kea یا در یک پایگاه داده قرار می‌گیرند. قطعه‌پیکربندی زیر نشان می‌دهد چگونه مشخص کنید که یک کلاینت متعلق به کلاس‌های reserved-class1 و reserved-class2 است. این کلاس‌ها با گزینه‌های خاصی که به کلاینت‌های متعلق به آن‌ها ارسال می‌شوند، مرتبط هستند.

{
    "client-classes": [
    {
       "name": "reserved-class1",
       "option-data": [
       {
           "name": "dns-servers",
           "data": "2001:db8:1::50"
       }
       ]
    },
    {
       "name": "reserved-class2",
       "option-data": [
       {
           "name": "nis-servers",
           "data": "2001:db8:1::100"
       }
       ]
    }
    ],
    "subnet6": [
    {
        "id": 1,
        "pools": [ { "pool": "2001:db8:1::/64" } ],
        "subnet": "2001:db8:1::/48",
        "reservations": [
        {
            "duid": "01:02:03:04:05:06:07:08",
            "client-classes": [ "reserved-class1", "reserved-class2" ]
        }
        ]
    } ]
 }

نکته:

کلاس‌های فهرست‌شده در فهرست client-classes یک رزرو، بدون قید و شرط به کلاینتِ آن رزرو اختصاص داده می‌شوند، چه آن کلاس‌ها شامل یک عبارت آزمون (test expression) باشند و چه نباشند. برای جلوگیری از سردرگمی، پیشنهاد می‌شود در کلاس‌های کلاینتی که صرفاً از طریق رزروهای میزبان اختصاص می‌یابند، عبارت‌های آزمون حذف شوند.

در برخی موارد، رزروهای میزبان می‌توانند همراه با کلاس‌های کلاینتِ مشخص‌شده در پیکربندی Kea استفاده شوند. به‌ویژه، هنگامی که یک رزرو میزبان برای یک کلاینت در یک زیرشبکه معین وجود دارد، کلاس توکار "KNOWN" به کلاینت اختصاص می‌یابد. در مقابل، هنگامی که هیچ تخصیص ایستایی برای کلاینت وجود ندارد، کلاس "UNKNOWN" به کلاینت اختصاص داده می‌شود. عبارت‌های کلاس در فایل پیکربندی Kea می‌توانند با استفاده از عملگر "member" به کلاس‌های "KNOWN" یا "UNKNOWN" ارجاع دهند. برای مثال:

{
    "client-classes": [
        {
            "name": "dependent-class",
            "test": "member('KNOWN')",
            "only-in-additional-list": true
        }
    ]
}

پارامتر only-in-additional-list در اینجا برای واداشتنِ ارزیابی کلاس پس از تخصیص اجاره (lease) و در نتیجه پس از تخصیص کلاس رزرو شده لازم است.

نکته:

کلاس‌های مشخص‌شده در رزروهای میزبان غیرسراسری (non-global)، پس از اینکه تمام کلاس‌های دارای پارامتر only-in-additional-list با مقدار false ارزیابی شدند، به بستهٔ پردازش‌شده تخصیص می‌یابند. این بدان معناست که این کلاس‌ها نباید به کلاس‌های تخصیص‌یافتهٔ ایستا از رزروهای میزبان وابسته باشند. اگر چنین وابستگی‌ای لازم باشد، پارامتر only-in-additional-list برای کلاس‌های وابسته باید روی true تنظیم شود. چنین کلاس‌هایی پس از انتساب کلاس‌های ایستا به بسته ارزیابی می‌شوند. با این حال، این امر بار کاری اضافی در پیکربندی ایجاد می‌کند، زیرا تمام کلاس‌های علامت‌گذاری‌شده به عنوان only-in-additional-list باید در فهرست evaluate-additional-classes برای هر زیرشبکه‌ای که در آن استفاده می‌شوند قرار گیرند.

نکته:

کلاس‌های کلاینت مشخص‌شده در فایل پیکربندی Kea می‌توانند به کلاس‌های مشخص‌شده در رزروهای میزبان سراسری (global) وابسته باشند. در چنین حالتی به پارامتر only-in-additional-list نیازی نیست. برای سناریوهای کاربردی خاص، به بخش‌های «Pool Selection with Client Class Reservations» و «Subnet Selection with Client Class Reservations» مراجعه کنید.

کارساز Kea می‌تواند رزروهای میزبان را در MySQL یا PostgreSQL ذخیره کند. برای اطلاعات بیشتر در مورد نحوه پیکربندی Kea جهت استفاده از رزروهای ذخیره‌شده در MySQL یا PostgreSQL، بخش Hosts Storage را ببینید. کارساز Kea یک قلاب اختصاصی برای مدیریت رزروها در پایگاه‌داده ارائه می‌دهد؛ بخش libdhcp_host_cmds.so: Host Commands <#hooks-host-cmds> اطلاعات دقیقی را ارائه می‌کند. ویکی Kea https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/commands#23-host-reservations-hr-management چندین مثال از نحوه انجام عملیات رایج رزرو میزبان را ارائه می‌دهد.

نکته:

در Kea، حداکثر طول گزینه‌ای که به ازای هر میزبان مشخص می‌شود، به‌طور قراردادی روی 4096 بایت تنظیم شده است.

قابلیت رزرو میزبان، محدودیت‌های اضافی را برای موتور تخصیص (بخشی از Kea که آدرسی را برای کلاینت انتخاب می‌کند) در طول فرایند انتخاب و تمدید اجاره اعمال می‌کند. به طور خاص، سه بررسی عمده ضروری است. نخست، هنگام انتخاب یک اجاره جدید، تنها آزاد بودن اجاره و عدم استفاده از آن توسط کلاینت DHCP دیگر کافی نیست؛ بلکه نباید برای کلاینت دیگری نیز رزرو شده باشد. به طور مشابه، هنگام تمدید یک اجاره، باید بررسی دیگری انجام شود تا مشخص گردد آیا آدرسی که در حال تمدید است برای کلاینت دیگری رزرو شده است یا خیر. در نهایت، هنگامی که یک میزبان آدرس یا پیشوندی را تمدید می‌کند، کارساز باید بررسی کند که آیا رزروی برای این میزبان وجود دارد یا خیر، که در این صورت به این معنی است که آدرس موجود (تخصیص‌یافته به صورت پویا) باید باطل شده و به جای آن آدرس رزروشده استفاده شود.

برخی از این بررسی‌ها ممکن است در برخی استقرارها غیرضروری باشند، و انجام ندادن آن‌ها می‌تواند کارایی را بهبود بخشد. کارساز Kea پارامترهای پیکربندی reservations-global، reservations-in-subnet و reservations-out-of-pool را برای انتخاب انواع رزروهای مجاز برای یک زیرشبکه خاص ارائه می‌دهد. هر نوع رزرو، محدودیت‌های متفاوتی برای بررسی‌هایی دارد که کارساز هنگام تخصیص یا تمدید اجاره برای کلاینت باید انجام دهد.

پرچم‌های پیکربندی عبارتند از:

  • reservations-in-subnet - هنگامی که روی true تنظیم شود، انواع رزرو میزبان درون استخر (in-pool) را فعال می‌کند. این تنظیم مقدار پیش‌فرض بوده و امن‌ترین و انعطاف‌پذیرترین حالت است. با این حال، از آنجا که تمام بررسی‌ها انجام می‌شوند، کندترین حالت نیز هست. این گزینه رزروهای سراسری را بررسی نمی‌کند. مقدار پیش‌فرض این پرچم true است.
  • reservations-out-of-pool - هنگامی که روی true تنظیم شود، فقط به رزروهای میزبان خارج از استخر (out-of-pool) اجازه می‌دهد. در این حالت کارساز فرض می‌کند که تمام رزروهای میزبان برای آدرس‌هایی هستند که متعلق به استخر پویا نیستند. بنابراین، هنگام برخورد با آدرس‌های درون استخر می‌تواند از بررسی‌های رزرو صرف‌نظر کند، و در نتیجه کارایی را بهبود بخشد. اگر هر یک از رزروها از آدرس‌های درون استخر استفاده می‌کنند، از این حالت استفاده نکنید. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ Kea رزروها را در برابر reservations-out-of-pool اعتبارسنجی منطقی نمی‌کند و پیکربندی نادرست ممکن است باعث بروز مشکلاتی شود. مقدار پیش‌فرض این پرچم false است.
  • reservations-global - رزروهای میزبان سراسری را مجاز می‌کند. با اعمال این تنظیم، کارساز رزروهای مربوط به یک کلاینت را در میان رزروهای سراسری تعریف‌شده جستجو می‌کند. اگر آدرسی مشخص شده باشد، کارساز از بررسی‌های رزرو که در سایر حالت‌ها انجام می‌شوند صرف‌نظر کرده، و در نتیجه کارایی را بهبود می‌بخشد. هنگام استفاده از این تنظیم احتیاط توصیه می‌شود؛ زمانی که reservations-global روی true تنظیم شده باشد، Kea رزروها را اعتبارسنجی منطقی نمی‌کند و پیکربندی نادرست ممکن است باعث بروز مشکلاتی شود. مقدار پیش‌فرض این پرچم false است.
نکته: تنظیم تمام پرچم‌ها روی false پشتیبانی از رزرو میزبان را غیرفعال می‌کند.
از آنجا که هیچ رزروی وجود ندارد، کارساز از تمام بررسی‌ها صرف‌نظر می‌کند. هر رزرو تعریف‌شده کاملاً نادیده گرفته می‌شود. از آنجا که بررسی‌ها نادیده گرفته می‌شوند، کارساز ممکن است در این حالت سریع‌تر عمل کند.

از نسخه 1.9.1 Kea، پرچم‌های reservations-global، reservations-in-subnet و reservations-out-of-pool پشتیبانی می‌شوند.

پارامترهای reservations-global، reservations-in-subnet و reservations-out-of-pool را می‌توان در سطوح زیر مشخص کرد:

  • سطح سراسری: .Dhcp6["reservations-global"] (کمترین اولویت: توسط تمام سطوح دیگر بازنویسی می‌شود)
  • سطح زیرشبکه: .Dhcp6.subnet6[]["reservations-in-subnet"] (اولویت پایین)
  • سطح شبکه مشترک: .Dhcp6["shared-networks"][]["reservations-out-of-pool"] (اولویت بالا)
  • سطح زیرشبکه در شبکه مشترک: .Dhcp6["shared-networks"][].subnet6[]["reservations-out-of-pool"] (بالاترین اولویت: بر تمام سطوح دیگر تقدم دارد)

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

                              O
                              |
                              v
+-----------------------------+------------------------------+
|         Is per-host configuration needed, such as          |
|                reserving specific addresses,               |
|               assigning specific options or                |
| assigning packets to specific classes on per-device basis? |
+-+-----------------+----------------------------------------+
  |                 |
no|              yes|
  |                 |   +--------------------------------------+
  |                 |   |         For all given hosts,         |
  +--> "disabled"   +-->+      can the reserved resources      |
                        |  be used in all configured subnets?  |
                        +--------+---------------------------+-+
                                 |                           |
+----------------------------+   |no                         |yes
|             Is             |   |                           |
|  at least one reservation  +<--+               "global" <--+
| used to reserve addresses  |
|        or prefixes?        |
+-+------------------------+-+
  |                        |
no|                     yes|   +---------------------------+
  |                        |   | Is high leases-per-second |
  +--> "out-of-pool"       +-->+ performance or efficient  |
        ^                      |      resource usage       |
        |                      |  (CPU ticks, RAM usage,   |
        |                      |   database roundtrips)    |
        |                      | important to your setup?  |
        |                      +-+----------------+--------+
        |                        |                |
        |                     yes|              no|
        |                        |                |
        |          +-------------+                |
        |          |                              |
        |          |   +----------------------+   |
        |          |   | Can it be guaranteed |   |
        |          +-->+  that the reserved   |   |
        |              |  addresses/prefixes  |   |
        |              |  aren't part of the  |   |
        |              |   pools configured   |   |
        |              |  in the respective   |   |
        |              |       subnet?        |   |
        |              +-+------------------+-+   |
        |                |                  |     |
        |             yes|                no|     |
        |                |                  |     V
        +----------------+                  +--> "in-subnet"

یک نمونه پیکربندی که رزروها را غیرفعال می‌کند به صورت زیر است:

{
  "Dhcp6": {
    "subnet6": [
      {
        "id": 1,
        "pools": [
          {
            "pool": "2001:db8:1::-2001:db8:1::100"
          }
        ],
        "reservations-global": false,
        "reservations-in-subnet": false,
        "subnet": "2001:db8:1::/64"
      }
    ]
  }
}

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

{
  "Dhcp6": {
    "reservations-global": true,
    "reservations": [
      {
        "duid": "00:03:00:01:11:22:33:44:55:66",
        "hostname": "host-one"
      },
      {
        "duid": "00:03:00:01:99:88:77:66:55:44",
        "hostname": "host-two"
      }
    ],
    "subnet6": [
      {
        "id": 1,
        "pools": [
          {
            "pool": "2001:db8:1::-2001:db8:1::100"
          }
        ],
        "subnet": "2001:db8:1::/64"
      }
    ]
  }
}

معنی پرچم‌های رزرو عبارتند از:

reservations-global: واکشی رزروهای سراسری.
  • reservations-in-subnet: واکشی رزروهای زیرشبکه. برای یک shared network این شامل تمام زیرشبکه‌های عضو آن shared network می‌شود.
  • reservations-out-of-pool: این مورد تنها زمانی معنادار است که پرچم reservations-in-subnet برابر با true باشد. هنگامی که reservations-out-of-pool برابر با true باشد، کارگزار فرض می‌کند که تمام رزروهای میزبان برای نشانی‌هایی هستند که متعلق به استخر پویا (dynamic pool) نیستند. بنابراین، می‌تواند هنگام مواجهه با نشانی‌های درون استخر از بررسی‌های رزرو صرف‌نظر کرده و کارایی را بهبود بخشد. کارگزار نشانی‌های رزروشده‌ای را که درون استخرهای پویا قرار دارند به کلاینت‌های مربوطه اختصاص نخواهد داد. این همچنین بدان معناست که نشانی‌های مطابق با رزروهای مربوطه از درون استخرهای پویا (در صورت وجود) می‌توانند به‌صورت پویا به هر کلاینتی اختصاص داده شوند.

پیکربندی disabled معادل است با:

{
  "Dhcp6": {
    "reservations-global": false,
    "reservations-in-subnet": false
  }
}

پیکربندی global با استفاده از reservations-global معادل است با:

{
  "Dhcp6": {
    "reservations-global": true,
    "reservations-in-subnet": false
  }
}

پیکربندی out-of-pool با استفاده از reservations-out-of-pool معادل است با:

{
  "Dhcp6": {
    "reservations-global": false,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": true
  }
}

و پیکربندی in-subnet با استفاده از reservations-in-subnet معادل است با:

{
  "Dhcp6": {
    "reservations-global": false,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": false
  }
}

برای فعال‌سازی هم‌زمان global و in-subnet، ترکیب زیر می‌تواند استفاده شود:

{
  "Dhcp6": {
    "reservations-global": true,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": false
  }
}

برای فعال‌سازی هم‌زمان global و out-of-pool، ترکیب زیر می‌تواند استفاده شود:

{
  "Dhcp6": {
    "reservations-global": true,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": true
  }
}

فعال‌سازی out-of-pool و غیرفعال‌سازی هم‌زمان in-subnet توصیه نمی‌شود زیرا out-of-pool برای رزروهای میزبان در یک زیرشبکه اعمال می‌شود که فقط در صورت true بودن پرچم in-subnet واکشی می‌شوند.

این پارامتر می‌تواند در سطوح global، subnet و shared-network تعیین شود.

یک پیکربندی نمونه که رزروها را غیرفعال می‌کند به‌صورت زیر است:

{
  "Dhcp6": {
    "subnet6": [
      {
        "reservations-global": false,
        "reservations-in-subnet": false,
        "subnet": "2001:db8:1::/64",
        "id": 1
      }
    ]
  }
}

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

{
  "Dhcp6": {
    "reservations": [
      {
        "duid": "00:03:00:01:11:22:33:44:55:66",
        "hostname": "host-one"
      },
      {
        "duid": "00:03:00:01:99:88:77:66:55:44",
        "hostname": "host-two"
      }
    ],
    "reservations-global": true,
    "reservations-in-subnet": false,
    "subnet6": [
      {
        "pools": [
          {
            "pool": "2001:db8:1::-2001:db8:1::100"
          }
        ],
        "subnet": "2001:db8:1::/64",
        "id": 1
      }
    ]
  }
}

برای جزئیات بیشتر در رابطه با رزروهای سراسری، به بخش Global Reservations in DHCPv6 مراجعه کنید.

جنبهٔ دیگر رزروهای میزبان، انواع مختلف شناسه‌ها است. Kea در حال حاضر از دو نوع شناسه در DHCPv6 پشتیبانی می‌کند: نشانی سخت‌افزاری و DUID. این قابلیت از دیدگاه کاربری مفید است؛ با این حال، یک عیب دارد. برای هر بستهٔ ورودی، Kea باید هر نوع شناسه را استخراج کرده و سپس پایگاه‌داده را پرس‌وجو کند تا بررسی کند آیا رزروی با این شناسهٔ خاص وجود دارد یا خیر. اگر چیزی یافت نشد، شناسهٔ بعدی استخراج شده و پرس‌وجوی بعدی ارسال می‌شود. این فرایند تا زمانی که یک رزرو پیدا شود یا تمام انواع شناسه‌ها بررسی شوند ادامه می‌یابد. به مرور زمان، با افزایش تعداد انواع شناسه‌های پشتیبانی‌شده، Kea کندتر و کندتر خواهد شد.

برای حل این مشکل، پارامتری به نام host-reservation-identifiers در دسترس است. این پارامتر فهرستی از انواع شناسه را دریافت می‌کند. Kea تنها آن دسته از انواع شناسه‌ها را که در host-reservation-identifiers ذکر شده‌اند بررسی می‌کند. از نظر کارایی، تعداد انواع شناسه‌ها باید در حداقل ممکن، در حالت ایده‌آل یک مورد، نگه داشته شود. اگر در استقرار از چندین نوع رزرو استفاده می‌شود، لطفاً آن‌ها را از پرکاربردترین به کم‌کاربردترین مرتب کنید، زیرا این کار شانس یافتن رزرو توسط Kea را با کمترین تعداد پرس‌وجو افزایش می‌دهد. یک نمونه از پیکربندی host-reservation-identifiers به‌صورت زیر است:

{
"host-reservation-identifiers": [ "duid", "hw-address" ],
"subnet6": [
    {
        "subnet": "2001:db8:1::/64",
        ...
    }
],
...
}

در صورت عدم تعیین، مقدار پیش‌فرض برابر است با:

"host-reservation-identifiers": [ "hw-address", "duid" ]

نکته:

به‌محض یافتن یک رزرو میزبان، جستجو متوقف می‌شود؛ هنگامی که یک کلاینت دارای دو رزرو میزبان با استفاده از انواع شناسه‌های فعالِ متفاوت باشد، همیشه نخستین مورد بازگردانده شده و دومی نادیده گرفته می‌شود. این حالت معمولاً یک خطای پیکربندی است. در موارد نادری که داشتن دو رزرو برای یک میزبان منطقی است، موردی که باید استفاده شود را می‌توان با مرتب‌سازی فهرست انواع شناسه در host-reservation-identifiers تعیین کرد.

در برخی پیاده‌سازی‌ها، مانند شبکه‌های تلفن همراه، کلاینت‌ها می‌توانند در سراسر شبکه جابه‌جا شوند (roam کنند) و پارامترهای خاصی فارغ از مکان فعلی کلاینت باید مشخص گردند. برای برآورده ساختن چنین نیازی، Kea سازوکار رزرو سراسری (global reservation) را ارائه می‌دهد. ایدهٔ نهفته در پس آن این است که رزروهای میزبان معمولی، با استفاده از یک شناسهٔ زیرشبکه (subnet ID) مشخص، به زیرشبکه‌های خاصی وابسته هستند. Kea می‌تواند یک رزرو سراسری را مشخص کند که در تمامی زیرشبکه‌هایی که رزروهای سراسری در آن‌ها فعال است، قابل استفاده باشد.

این ویژگی می‌تواند برای تخصیص پارامترهای مشخصی مانند hostname یا سایر گزینه‌های اختصاصی و ویژهٔ میزبان (host-specific) به کار رود. همچنین می‌توان از آن برای تخصیص نشانی‌ها یا پیشوندها استفاده کرد.

نشانی اختصاص‌یافته از طریق رزرو سراسری میزبان باید برای زیرشبکه‌ای که سرور برای کلاینت انتخاب می‌کند، امکان‌پذیر و معتبر باشد. به عبارت دیگر، نشانی باید در محدودهٔ زیرشبکه قرار داشته باشد؛ در غیر این صورت نادیده گرفته شده و سرور تلاش خواهد کرد نشانی را به‌صورت پویا تخصیص دهد. اگر زیرشبکهٔ انتخاب‌شده متعلق به یک شبکهٔ مشترک (shared network) باشد، سرور امکان‌پذیری را با زیرشبکه‌های همتای آن بررسی کرده و نخستین زیرشبکه‌ای را که نشانی در محدودهٔ آن قرار دارد انتخاب می‌نماید. اگر چنین زیرشبکه‌ای وجود نداشته باشد، سرور به تخصیص پویای نشانی بازمی‌گردد. این موضوع در مورد پیشوندهای رزروشدهٔ سراسری صدق نمی‌کند.

نکته:

پیش از نسخهٔ 2.3.5، سرور بررسی‌های امکان‌پذیری را بر روی نشانی‌های رزروشدهٔ سراسری انجام نمی‌داد، که این موضوع به سرور اجازه می‌داد تا به‌گونه‌ای پیکربندی شود که اجاره‌های (leases) نامعقولی را برای مقادیر دلخواه نشانی صادر کند. نسخه‌های بعدی Kea این بررسی‌ها را انجام می‌دهند.

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

"Dhcp6": {
    # This specifies global reservations.
    # They will apply to all subnets that
    # have global reservations enabled.
    "reservations": [
    {
       "hw-address": "aa:bb:cc:dd:ee:ff",
       "hostname": "hw-host-dynamic"
    },
    {
       "hw-address": "01:02:03:04:05:06",
       "hostname": "hw-host-fixed",
       # Use of IP addresses in global reservations is risky.
       # If used outside of matching subnet, such as 3001::/64,
       # it will result in a broken configuration being handed
       # to the client.
       "ip-address": "2001:db8:ff::77"
    },
    {
       "duid": "01:02:03:04:05",
       "hostname": "duid-host"
    }
    ],
    "valid-lifetime": 600,
    "subnet4": [ {
        "subnet": "2001:db8:1::/64",
        # Specify if the server should look up global reservations.
        "reservations-global": true,
        # Specify if the server should look up in-subnet reservations.
        "reservations-in-subnet": false,
        # Specify if the server can assume that all reserved addresses
        # are out-of-pool. It can be ignored because "reservations-in-subnet"
        # is false.
        # "reservations-out-of-pool": false,
        "pools": [ { "pool": "2001:db8:1::-2001:db8:1::100" } ]
    } ]
}

هنگام استفاده از backendهای پایگاه داده، رزروهای سراسری میزبان با استفاده از مقدار 0 برای subnet-id از رزروهای معمولی متمایز می‌شوند.

کلاس‌های کلاینت می‌توانند هم در فایل پیکربندی Kea و هم از طریق رزروهای میزبان تعیین شوند. کلاس‌های مشخص‌شده در فایل پیکربندی Kea بلافاصله پس از دریافت بستهٔ DHCP ارزیابی می‌شوند و بنابراین می‌توان از آن‌ها برای تأثیرگذاری بر انتخاب زیرشبکه با استفاده از پارامتر client-classes مشخص‌شده در حوزهٔ زیرشبکه (subnet scope) استفاده کرد. کلاس‌های مشخص‌شده درون رزروهای میزبان، پس از آن‌که سرور از قبل زیرشبکه‌ای را برای کلاینت انتخاب کرد، واکشی شده و به بسته اختصاص داده می‌شوند. این بدان معناست که کلاس کلاینت مشخص‌شده درون یک رزرو میزبان نمی‌تواند بر تخصیص زیرشبکه برای این کلاینت تأثیر بگذارد، مگر اینکه زیرشبکه به یک شبکهٔ مشترک (shared network) تعلق داشته باشد. اگر زیرشبکه متعلق به یک شبکهٔ مشترک باشد، سرور ممکن است هنگام تلاش برای تخصیص اجاره (lease)، تخصیص زیرشبکه را به‌طور پویا تغییر دهد. اگر زیرشبکه متعلق به یک شبکهٔ مشترک نباشد، زیرشبکه پس از یک‌بار انتخاب شدن دیگر تغییر نخواهد کرد.

اگر زیرشبکه متعلق به یک شبکهٔ مشترک نباشد، می‌توان از دسته‌بندی کلاینت مبتنی بر رزرو میزبان برای انتخاب یک استخر (pool) در درون زیرشبکه به صورت زیر استفاده کرد:

{
    "Dhcp6": {
        "client-classes": [
            {
                "name": "reserved_class"
            },
            {
                "name": "unreserved_class",
                "test": "not member('reserved_class')"
            }
        ],
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8:1::/64",
                "reservations": [
                    {
                        "hw-address": "aa:bb:cc:dd:ee:fe",
                        "client-classes": [ "reserved_class" ]
                    }
                ],
                "pools": [
                    {
                        "pool": "2001:db8:1::10 - 2001:db8:1::20",
                        "client-classes": [ "unreserved_class" ]
                    },
                    {
                        "pool": "2001:db8:1::30 - 2001:db8:1::40",
                        "client-classes": [ "reserved_class" ]
                    },
                    {
                        "pool": "2001:db8:1::50 - 2001:db8:1::60"
                    }
                ]
            }
        ]
    }
}

کلاس reserved_class بدون پارامتر test اعلان شده است زیرا تنها می‌تواند از طریق سازوکار رزرو میزبان به یک کلاینت اختصاص یابد. کلاس دوم، یعنی unreserved_class، به کلاینت‌هایی اختصاص می‌یابد که به reserved_class تعلق ندارند.

استخر نخست در زیرشبکه برای کلاینت‌هایی استفاده می‌شود که چنین رزروی ندارند. استخر دوم تنها برای کلاینت‌هایی استفاده می‌شود که رزروی برای reserved_class دارند. استخر سوم یک استخر بدون محدودیت برای تمامی کلاینت‌ها است که هم شامل کلاینت‌های reserved_class و هم شامل unreserved_class می‌شود.

این قطعه‌پیکربندی شامل یک رزرو میزبان است که باعث می‌شود کلاینتی با نشانی MAC به مقدار aa:bb:cc:dd:ee:fe به reserved_class اختصاص یابد. بنابراین، به این کلاینت نشانی IP از دومین استخر نشانی داده خواهد شد.

رزروهای تعریف‌شده در زیرشبکه‌ای که متعلق به یک شبکهٔ مشترک است برای کلاینتی که در غیر این صورت تطابق دارد قابل مشاهده نیست، بنابراین نمی‌توان از آن‌ها برای انتخاب استخرها، و به همین ترتیب زیرشبکه‌ها، استفاده کرد..SS انتخاب زیرشبکه با رزروهای کلاس کلاینت (Subnet Selection with Client Class Reservations)

یک حالت کاربردی خاص وجود دارد که در آن انتخاب زیرشبکه می‌تواند تحت تأثیر کلاس‌های کلاینت مشخص‌شده درون رزروهای میزبان قرار گیرد: زمانی که کلاینت به یک شبکهٔ مشترک (shared network) تعلق دارد. در چنین حالتی، می‌توان از کلاس‌بندی برای انتخاب یک زیرشبکه درون این شبکهٔ مشترک استفاده کرد. مثال زیر را در نظر بگیرید:

{
    "Dhcp6": {
        "client-classes": [
            {
                "name": "reserved_class"
            },
            {
                "name": "unreserved_class",
                "test": "not member('reserved_class')"
            }
        ],
        "reservations": [
            {
                "hw-address": "aa:bb:cc:dd:ee:fe",
                "client-classes": [ "reserved_class" ]
            }
        ],
        "reservations-global": true,
        "reservations-in-subnet": false,
        "shared-networks": [
            {
                "name": "net",
                "subnet6": [
                    {
                        "id": 1,
                        "subnet": "2001:db8:1::/64",
                        "pools": [
                            {
                                "pool": "2001:db8:1::10 - 2001:db8:1::20",
                                "client-classes": [ "unreserved_class" ]
                            },
                            {
                                "pool": "2001:db8:1::30 - 2001:db8:1::40",
                                "client-classes": [ "unreserved_class" ]
                            }
                        ]
                    },
                    {
                        "id": 2,
                        "subnet": "2001:db8:2::/64",
                        "pools": [
                            {
                                "pool": "2001:db8:2::10 - 2001:db8:2::20",
                                "client-classes": [ "reserved_class" ]
                            },
                            {
                                "pool": "2001:db8:2::30 - 2001:db8:2::40",
                                "client-classes": [ "reserved_class" ]
                            }
                        ]
                    },
                    {
                        "id": 3,
                        "subnet": "2001:db8:3::/64",
                        "pools": [
                            {
                                "pool": "2001:db8:3::10 - 2001:db8:3::20"
                            },
                            {
                                "pool": "2001:db8:3::30 - 2001:db8:3::40"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}

این مشابه مثالی است که در «Pool Selection with Client Class Reservations» شرح داده شد. با این حال، این بار سه زیرشبکه وجود دارد که استخر هر یک از دو تای اول با یک کلاس متفاوت مرتبط شده است.

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

زیرشبکه‌ها باید متعلق به همان شبکهٔ مشترک باشند.

برای اینکه یک زیرشبکه به کلاسی خاص محدود شود یا نادیده گرفته شود، تمامی استخرهای درون آن زیرشبکه باید به ترتیب توسط reserved_class یا unreserved_class محافظت شوند.

علاوه بر این، رزرو برای کلاس کلاینت باید در حوزهٔ سراسری (رزرو سراسری) تعیین شده باشد و reservations-global نیز روی true تنظیم شده باشد.

در مثال بالا، پارامتر پیکربندی client-classes می‌توانست به جای سطح استخر، در سطح زیرشبکه نیز مشخص شود و همان نتیجه را در بر داشته باشد.

اگر زیرشبکه‌ها بیرون از شبکه‌های مشترک تعریف شده بودند و client-classes در سطح زیرشبکه مشخص شده بود، آن‌گاه early-global-reservations-lookup نیز باید فعال می‌شد تا انتخاب زیرشبکه به درستی کار کند.

رزروهای میزبان طوری طراحی شده بودند تا از ایجاد چندین رزرو برای یک نشانی IP یا پیشوند واگذارشده (delegated prefix) یکسان در یک زیرشبکهٔ خاص جلوگیری کنند، تا از رقابت دو کلاینت مختلف بر سر یک اجاره (lease) یکسان پرهیز شود. هنگام استفاده از تنظیمات پیش‌فرض، سرور هنگامی که دو یا چند رزرو را برای یک اجارهٔ یکسان درون یک زیرشبکه در فایل پیکربندی Kea بیابد، یک خطای پیکربندی برمی‌گرداند. libdhcp_host_cmds.so <#std-ischooklib-libdhcp_host_cmds.so> در پاسخ به دستور reservation-add <#std-isccmd-reservation-add> هنگامی که تشخیص دهد رزروی در پایگاه داده برای اجاره‌ای که رزرو جدید برای آن افزوده می‌شود وجود دارد، یک خطا برمی‌گرداند.

مشابه با DHCPv4 (ببینید Multiple Reservations for the Same IP <#multiple-reservations-same-ip4>)، سرور DHCPv6 نیز می‌تواند پیکربندی شود تا امکان ایجاد چندین رزرو برای یک نشانی IPv6 و/یا پیشوند واگذارشدهٔ یکسان در یک زیرشبکهٔ معین را فراهم کند. این قابلیت از انتشار 1.9.1 برنامهٔ Kea به عنوان یک حالت عملیاتی اختیاری پشتیبانی می‌شود که با پارامتر سراسری ip-reservations-unique فعال می‌گردد.

پارامتر ip-reservations-unique یک پارامتر بولی (boolean) است که مقدار پیش‌فرض آن true است و تعیین بیش از یک رزرو را برای همان اجاره در یک زیرشبکهٔ معین ممنوع می‌کند. تنظیم این پارامتر روی false اجازه می‌دهد چنین رزروهایی هم در فایل پیکربندی Kea و هم در بک‌اند پایگاه دادهٔ میزبان، از طریق libdhcp_host_cmds.so <#std-ischooklib-libdhcp_host_cmds.so> ایجاد شوند.

تنظیم ip-reservations-unique روی false هنگام استفاده از memfile، MySQL یا PostgreSQL پشتیبانی می‌شود. این تنظیم هنگام استفاده از Host Cache (ببینید libdhcp_host_cache.so: Host Cache Reservations for Improved Performance <#hooks-host-cache>) یا بک‌اند RADIUS (ببینید libdhcp_radius.so: RADIUS Server Support <#hooks-radius>) پشتیبانی نمی‌شود. این بک‌اندهای رزرو از چندین رزرو برای یک IP یکسان پشتیبانی نمی‌کنند؛ اگر هر یک از این هوک‌ها بارگیری شده باشد و ip-reservations-unique روی false تنظیم شود، خطای پیکربندی صادر شده و راه‌اندازی سرور ناموفق خواهد بود.

نکته:

هنگامی که ip-reservations-unique روی true (مقدار پیش‌فرض) تنظیم است، سرور اطمینان حاصل می‌کند که رزروهای IP برای یک زیرشبکه درون یک بک‌اند میزبان واحد و/یا فایل پیکربندی Kea یکتا هستند. این امر یکتا بودن رزروها را در میان چندین بک‌اند تضمین نمی‌کند. در زمان راه‌اندازی سرور، تنها یکتا بودن رزروهای IP تعریف‌شده در فایل پیکربندی Kea بررسی می‌شود.

در ادامه یک پیکربندی نمونه با دو رزرو برای نشانی IPv6 یکسان اما با نشانی‌های MAC متفاوت آمده است:

"Dhcp6": {
    "ip-reservations-unique": false,
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/64",
            "reservations": [
                {
                    "hw-address": "1a:1b:1c:1d:1e:1f",
                    "ip-address": "2001:db8:1::11"
                },
                {
                    "hw-address": "2a:2b:2c:2d:2e:2f",
                    "ip-address": "2001:db8:1::11"
                }
            ]
        }
    ]
}

کنترل پارامتر ip-reservations-unique از طریق Configuration Backend در DHCPv6 امکان‌پذیر است. اگر تنظیم جدید این پارامتر با بک‌اندهای مورد استفادهٔ فعلی تداخل داشته باشد (یعنی بک‌اندها از تنظیم جدید پشتیبانی نکنند)، تنظیم جدید نادیده گرفته شده و یک پیام ثبت وقایع هشداری تولید می‌شود. بک‌اندها با این انتظار که رزروهای IP در هر زیرشبکه یکتا هستند، به استفاده از تنظیم پیش‌فرض ادامه می‌دهند. برای فراهم کردن امکان ایجاد رزروهای IP غیریکتا، مدیر سیستم باید بک‌اندهایی را که از آن‌ها پشتیبانی نمی‌کنند از فایل پیکربندی حذف کند.

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

نکته:

در حال حاضر، سرور Kea بررسی نمی‌کند که آیا هنگام به‌روزرسانی ip-reservations-unique از false به true، چندین رزرو برای یک نشانی IP و/یا پیشوند واگذارشدهٔ یکسان در پایگاه‌های دادهٔ میزبان (MySQL و/یا PostgreSQL) وجود دارد یا خیر. این موضوع ممکن است باعث بروز مشکلاتی در تخصیص اجاره‌ها شود. مدیر سیستم باید پیش از به‌روزرسانی پیکربندی اطمینان حاصل کند که حداکثر یک رزرو برای هر نشانی IP و/یا پیشوند واگذارشده در هر زیرشبکه وجود دارد.

پارامتر reservations-lookup-first یک پارامتر بولی است که کنترل می‌کند آیا جستجوی رزروهای میزبان باید پیش از جستجوی اجاره انجام شود یا خیر. این پارامتر تنها زمانی مؤثر است که چندریسمانی (multi-threading) غیرفعال باشد. هنگامی که چندریسمانی فعال باشد، جستجوی رزروهای میزبان همواره ابتدا انجام می‌شود تا از قفل شدن منابع جستجوی اجاره جلوگیری گردد. پارامتر reservations-lookup-first در صورت غیرفعال بودن چندریسمانی، به طور پیش‌فرض روی false تنظیم است..SS رزرو میزبان به‌عنوان کنترل دسترسی پایه

تعریف یک رزرو میزبان (host reservation) که تنها شامل یک شناسه‌گر است، بدون هیچ نشانی، گزینه یا مقداری، امکان‌پذیر است. در برخی از پیاده‌سازی‌ها این کار مفید است، زیرا میزبان‌هایی که دارای رزرو هستند به کلاس KNOWN تعلق می‌گیرند در حالی که سایرین تعلق ندارند. این قابلیت می‌تواند به‌عنوان یک سازوکار ابتدایی برای کنترل دسترسی استفاده شود.

مثال زیر این مفهوم را نشان می‌دهد. این مثال یک زیرشبکه IPv6 منفرد را مشخص می‌کند که تمام کلاینت‌ها نشانی خود را از آن دریافت می‌کنند. با این حال، تنها کلاینت‌های شناخته‌شده (آن‌هایی که رزرو دارند) سرور DNS پیش‌فرض خود را پیکربندی‌شده دریافت خواهند کرد. رزروهای خالی، یعنی رزروهایی که فقط معیار شناسایی دارند، می‌توانند روشی مفید برای شناخته‌شده کردن کلاینت‌ها باشند.

"Dhcp6": {
    "client-classes": [
        {
            "name": "KNOWN",
            "option-data": [
                {
                    "name": "dns-servers",
                    "data": "2001:db8::1"
                }
            ]
        }
    ],
    "reservations": [
        // Clients on this list will be added to the KNOWN class.
        { "duid": "01:02:03:04:05:0A:0B:0C:0D:0E" },
        { "duid": "02:03:04:05:0A:0B:0C:0D:0E:0F" }
    ],
    "reservations-global": true,
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/48",
            "pools": [
                {
                    "pool": "2001:db8:1:1::/64"
                }
            ]
        }
    ]
}

این مفهوم می‌تواند با استفاده از رزروها همراه با برچسب‌گذاری کلاس گزینه‌ها (بخش Option Class-Tagging <#option-class-tagging> را ببینید) بیشتر گسترش یابد. یک سناریوی واقعی مناسب می‌تواند وضعیتی باشد که در آن برخی از مشترکان یک ISP صورت‌حساب‌های خود را پرداخت نکرده‌اند. به این مشتریان باید یک سرور DNS جایگزین تخصیص داده شود که به جای ارائه دسترسی به اینترنت، آن‌ها را به یک پورتال اسارتی (captive portal) هدایت کرده و از آن‌ها بخواهد حساب‌های خود را تسویه کنند. می‌توان از رزروها برای تخصیص یک کلاینت به کلاس "blocked" استفاده کرد که متعاقباً برای تعیین مقدار گزینه سرور DNS همان‌طور که در زیر نشان داده شده، به کار می‌رود:

"Dhcp6": {
    "client-classes": [
        {
            "name": "blocked"
        }
    ],
    "reservations": [
        // Clients on this list will be added to the KNOWN class. Some
        // will also be added to the blocked class.
        { "duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
          "client-classes": [ "blocked" ] },
        { "duid": "02:03:04:05:0A:0B:0C:0D:0E:0F" }
    ],
    "reservations-global": true,
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/48",
            "pools": [
                {
                    "pool": "2001:db8:1:1::/64"
                }
            ],
            "option-data": [
                {
                    // DNS server for blocked customers.
                    "client-classes": [ "blocked" ],
                    "name": "dns-servers",
                    "data": "2001:db8::2"
                },
                {
                    // DNS server for customers in good standing.
                    "name": "dns-servers",
                    "data": "2001:db8::1"
                }
            ]
        }
    ]
}

سرورهای DHCP از اطلاعات زیرشبکه به دو روش استفاده می‌کنند. این اطلاعات هم برای تعیین نقطه اتصال (یعنی جایی که کلاینت به شبکه متصل است) و هم برای گروه‌بندی اطلاعات مربوط به یک مکان خاص در شبکه به کار می‌رود. گاهی اوقات استقرار بیش از یک زیرشبکه منطقی IP روی یک پیوند فیزیکی (physical link) یکسان مفید است. درک این موضوع که دو یا چند زیرشبکه روی یک پیوند یکسان استفاده می‌شوند، نیازمند منطق اضافی در سرور DHCP است. این قابلیت در Kea با نام "shared networks" (شبکه‌های اشتراکی) و گاهی نیز "shared subnets" نامیده می‌شود؛ در نام‌گذاری مایکروسافت، به آن "multinet" گفته می‌شود.

موارد زیادی وجود دارد که ویژگی شبکه‌های اشتراکی در آن‌ها مفید است؛ در اینجا تنها به چند مورد از رایج‌ترین آن‌ها اشاره می‌کنیم. نخستین و تا حد زیادی متداول‌ترین مورد استفاده، یک شبکه IPv4 موجود است که گسترش یافته و فضای نشانی دردسترس آن رو به اتمام است. این موضوع در IPv6 کمتر رایج است، اما شبکه‌های اشتراکی همچنان مفید هستند: برای مثال، هنگام اتمام پیشوندهای واگذارشده (delegated prefixes) در IPv6 در یک زیرشبکه، یا تمایل به آزمایش یک طرح آدرس‌دهی جدید. با ظهور استقرار IPv6 و فضای نشانی گسترده، بسیاری از سازمان‌ها فضای نشانی را به زیرشبکه‌ها تقسیم کرده، آن را مستقر می‌کنند و سپس پس از مدتی متوجه می‌شوند که می‌خواهند آن را به شکل متفاوتی تقسیم‌بندی کنند. در دوره گذار، آن‌ها می‌خواهند هر دو آدرس‌دهی قدیمی و جدید در دسترس باشند؛ بنابراین به بیش از یک زیرشبکه روی یک پیوند فیزیکی یکسان نیاز خواهد بود.

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

به کلاینتی که به یک شبکه اشتراکی متصل است، ممکن است یک اجاره (نشانی یا پیشوند) از هر یک از استخرهای تعریف‌شده در زیرشبکه‌های متعلق به آن شبکه اشتراکی تخصیص داده شود. در داخل، سرور یکی از زیرشبکه‌های متعلق به یک شبکه اشتراکی را انتخاب کرده و تلاش می‌کند یک اجاره را از این زیرشبکه تخصیص دهد. اگر سرور نتواند اجاره‌ای را از زیرشبکه انتخابی تخصیص دهد (به‌عنوان مثال، به دلیل اتمام استخر)، از زیرشبکه دیگری در همان شبکه اشتراکی استفاده کرده و تلاش می‌کند اجاره را از آن تخصیص دهد. سرور معمولاً تمام اجاره‌های موجود در یک زیرشبکه مشخص را پیش از شروع تخصیص اجاره‌ها از سایر زیرشبکه‌های متعلق به همان شبکه اشتراکی واگذار می‌کند. با این حال، در شرایط خاصی ممکن است پیش از اتمام استخرهای زیرشبکه نخست، به کلاینت اجاره‌ای از زیرشبکه دیگری تخصیص یابد؛ این اتفاق گاهی زمانی رخ می‌دهد که کلاینت یک راهنمایی (hint) متعلق به زیرشبکه‌ای دیگر ارائه دهد، یا اینکه کلاینت دارای رزروهایی در زیرشبکه‌ای غیر از زیرشبکه پیش‌فرض باشد.

نکته:

در پیاده‌سازی‌ها نباید این فرض در نظر گرفته شود که Kea پیش از تخصیص نشانی‌ها از سایر زیرشبکه‌ها، حتماً منتظر می‌ماند تا تمام نشانی‌های زیرشبکه نخست در یک شبکه اشتراکی را تخصیص دهد.

برای تعریف یک شبکه اشتراکی، یک دامنه پیکربندی اضافی معرفی شده است:

{
"Dhcp6": {
    "shared-networks": [
        {
        # Name of the shared network. It may be an arbitrary string
        # and it must be unique among all shared networks.
        "name": "ipv6-lab-1",
        # The subnet selector can be specified on the shared network
        # level. Subnets from this shared network will be selected
        # for clients communicating via relay agent having
        # the specified IP address.
        "relay": {
            "ip-addresses": [ "2001:db8:2:34::1" ]
        },
        # This starts a list of subnets in this shared network.
        # There are two subnets in this example.
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8::/48",
                "pools": [ { "pool":  "2001:db8::1 - 2001:db8::ffff" } ]
            },
            {
                "id": 2,
                "subnet": "3ffe:ffe::/64",
                "pools": [ { "pool":  "3ffe:ffe::/64" } ]
            }
        ]
        }
    ],
    # end of shared-networks
    # It is likely that in the network there will be a mix of regular,
    # "plain" subnets and shared networks. It is perfectly valid
    # to mix them in the same configuration file.
    #
    # This is a regular subnet. It is not part of any shared-network.
    "subnet6": [
        {
            "id": 3,
            "subnet": "2001:db9::/48",
            "pools": [ { "pool":  "2001:db9::/64" } ],
            "relay": {
                "ip-addresses": [ "2001:db8:1:2::1" ]
            }
        }
    ]
}
}

همان‌طور که در مثال نشان داده شد، امکان ترکیب زیرشبکه‌های اشتراکی و زیرشبکه‌های عادی ("plain") وجود دارد. هر شبکه اشتراکی باید یک نام یکتا داشته باشد. این شبیه به شناسه (ID) برای زیرشبکه‌ها است، اما به مدیران سیستم انعطاف‌پذیری بیشتری می‌دهد. این نام برای ثبت وقایع و همچنین به طور داخلی برای شناسایی شبکه‌های اشتراکی استفاده می‌شود.

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

شبکه‌های اشتراکی این امکان را فراهم می‌کنند که پارامترهای متعددی در دامنه شبکه اشتراکی مشخص شوند که بر تمام زیرشبکه‌های درون آن اعمال گردند. در صورت لزوم، می‌توان پارامتری را در دامنه shared-network مشخص کرد و سپس مقدار آن را در دامنه زیرشبکه بازنویسی (override) نمود. برای مثال:

{
"shared-networks": [
    {
        "name": "lab-network3",
        "relay": {
             "ip-addresses": [ "2001:db8:2:34::1" ]
        },
        # This applies to all subnets in this shared network, unless
        # values are overridden on subnet scope.
        "valid-lifetime": 600,
        # This option is made available to all subnets in this shared
        # network.
        "option-data": [ {
            "name": "dns-servers",
            "data": "2001:db8::8888"
        } ],
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8:1::/48",
                "pools": [ { "pool":  "2001:db8:1::1 - 2001:db8:1::ffff" } ],
                # This particular subnet uses different values.
                "valid-lifetime": 1200,
                "option-data": [
                {
                    "name": "dns-servers",
                    "data": "2001:db8::1:2"
                },
                {
                    "name": "unicast",
                    "data": "2001:abcd::1"
                } ]
            },
            {
                 "id": 2,
                 "subnet": "2001:db8:2::/48",
                 "pools": [ { "pool":  "2001:db8:2::1 - 2001:db8:2::ffff" } ],
                 # This subnet does not specify its own valid-lifetime value,
                 # so it is inherited from shared network scope.
                 "option-data": [
                 {
                     "name": "dns-servers",
                     "data": "2001:db8:cafe::1"
                 } ]
            }
        ]
    }
    ],
    ...
}

در این مثال، گزینه dns-servers به‌گونه‌ای تعریف شده که برای کلاینت‌ها در هر دو زیرشبکه این شبکه اشتراکی در دسترس است. همچنین، طول عمر معتبر (valid lifetime) روی ۱۰ دقیقه (۶۰۰ ثانیه) تنظیم شده است. با این حال، زیرشبکه نخست برخی از مقادیر را بازنویسی می‌کند (طول عمر معتبر ۲۰ دقیقه است، نشانی IP متفاوتی برای dns-servers وجود دارد)، و همچنین گزینه اختصاصی خود را اضافه می‌کند (نشانی تک‌پخشی یا unicast). با فرض اینکه به کلاینتی که درخواست گزینه‌های server unicast و dns-servers را دارد، اجاره‌ای از این زیرشبکه تخصیص یابد، اجاره‌ای به مدت ۲۰ دقیقه و گزینه dns-servers را دریافت خواهد کرد و مجاز به استفاده از تک‌پخشی سرور در نشانی 2001:abcd::1 خواهد بود. اگر همان کلاینت به زیرشبکه دوم تخصیص داده شود، یک اجاره ۱۰ دقیقه‌ای، مقدار 2001:db8:cafe::1 برای dns-servers دریافت خواهد کرد و هیچ نشانی تک‌پخشی سروری نخواهد داشت.

برخی پارامترها باید در تمام زیرشبکه‌های واقع در یک شبکه اشتراکی یکسان باشند. این محدودیت برای تنظیمات interface و rapid-commit اعمال می‌شود. راحت‌ترین روش، تعریف آن‌ها در دامنه shared-network است، اما می‌توان آن‌ها را برای هر زیرشبکه نیز مشخص کرد. با این حال، هر زیرشبکه باید دارای مقدار یکسانی باشد.

نکته:

هنگام استفاده از کلاینت‌هایی که چندین گزینه IA را در یک درخواست منفرد ارسال می‌کنند، و شبکه‌های اشتراکی که زیرشبکه‌های آن‌ها مقادیر متفاوتی برای گزینه‌ها و پارامترهای پیکربندی دارند، یک ابهام ذاتی وجود دارد. سرور گزینه‌های IA را به ترتیب وقوع آن‌ها در پرس‌وجوی کلاینت به صورت متوالی پردازش می‌کند؛ اگر اجاره‌های درخواست‌شده در گزینه‌های IA در نهایت از زیرشبکه‌های متفاوتی برآورده شوند، کدام پارامترها و گزینه‌ها باید اعمال شوند؟ در حال حاضر، کد سرور از مقادیر آخرین زیرشبکه مربوط به آخرین گزینه IA برآورده‌شده استفاده می‌کند.

ما این مسئله را تا حد زیادی به‌عنوان یک مشکل در پیکربندی سایت در نظر می‌گیریم. یک شبکه اشتراکی معمولاً به معنای همان پیوند فیزیکی است، بنابراین سرویس‌های پیکربندی‌شده توسط گزینه‌های زیرشبکه A باید به همان آسانی از زیرشبکه B قابل دسترسی باشند و برعکس. راه‌های متعددی برای اجتناب از این وضعیت وجود دارد:

از مقادیر یکسان برای گزینه‌ها و پارامترها در زیرشبکه‌های درون شبکهٔ اشتراکی استفاده کنید.
  • از انتخاب‌گرهای زیرشبکه یا محافظ‌های کلاس کلاینت (client class guards) استفاده کنید که تضمین می‌کنند برای پرس‌وجوی یک کلاینت، برای تمام گزینه‌های IA در آن پرس‌وجو از همان زیرشبکه استفاده شود.
  • از به‌کارگیری شبکه‌های اشتراکی برای کلاینت‌هایی که در هر پرس‌وجو چندین گزینهٔ IA ارسال می‌کنند خودداری کنید.

تعیین نام رابط (interface) در سطح shared-network امکان‌پذیر است تا به سرور اعلام شود این شبکهٔ اشتراکی خاص، به‌طور مستقیم (نه از طریق رله‌ها) و با استفاده از رابط شبکهٔ محلی در دسترس است. از آنجا که انتظار می‌رود تمام زیرشبکه‌ها در یک شبکهٔ اشتراکی روی پیوند فیزیکی یکسانی استفاده شوند، تلاش برای تعریف یک شبکهٔ اشتراکی با زیرشبکه‌هایی که از طریق رابط‌های متفاوتی در دسترس هستند یک خطای پیکربندی است. به عبارت دیگر، تمام زیرشبکه‌های درون شبکهٔ اشتراکی باید مقدار یکسانی برای پارامتر interface داشته باشند. پیکربندی زیر نمونه‌ای از کارهایی است که نباید انجام داد:

{
"shared-networks": [
    {
        "name": "office-floor-2",
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8::/64",
                "pools": [ { "pool":  "2001:db8::1 - 2001:db8::ffff" } ],
                "interface": "eth0"
            },
            {
                 "id": 2,
                 "subnet": "3ffe:abcd::/64",
                 "pools": [ { "pool":  "3ffe:abcd::1 - 3ffe:abcd::ffff" } ],
                 ...
                 # Specifying a different interface name is a configuration
                 # error. This value should rather be "eth0" or the interface
                 # name in the other subnet should be "eth1".
                 # "interface": "eth1"
            }
        ]
    }
],
...
}

برای به حداقل رساندن احتمال خطاهای پیکربندی، اغلب راحت‌تر است که نام رابط به سادگی یک بار در سطح shared-network تعیین شود، همان‌طور که در مثال زیر نشان داده شده است.

{
"shared-networks": [
    {
        "name": "office-floor-2",
        # This tells Kea that the whole shared network is reachable over a
        # local interface. This applies to all subnets in this network.
        "interface": "eth0",
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8::/64",
                "pools": [ { "pool":  "2001:db8::1 - 2001:db8::ffff" } ]
            },
            {
                 "id": 2,
                 "subnet": "3ffe:abcd::/64",
                 "pools": [ { "pool":  "3ffe:abcd::1 - 3ffe:abcd::ffff" } ]
            }
        ]
    }
],
...
}

در ترافیک رله‌شده، زیرشبکه‌ها معمولاً با استفاده از نشانی‌های عامل‌های رله (relay agents) انتخاب می‌شوند. اگر زیرشبکه‌ها به‌طور مستقل (بدون گروه‌بندی در یک شبکهٔ اشتراکی) استفاده شوند، می‌توان برای هر یک از این زیرشبکه‌ها نشانی رلهٔ متفاوتی تعیین کرد. هنگامی که چندین زیرشبکه به یک شبکهٔ اشتراکی تعلق دارند، باید از طریق نشانی رلهٔ یکسانی انتخاب شوند و مانند مورد ترافیک محلی شرح داده شده در بالا، تعیین نشانی‌های رلهٔ متفاوت برای زیرشبکه‌های مربوطه در شبکهٔ اشتراکی یک خطای پیکربندی است. پیکربندی زیر نمونهٔ دیگری از کارهایی است که نباید انجام داد:

{
"shared-networks": [
    {
        "name": "kakapo",
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8::/64",
                "relay": {
                    "ip-addresses": [ "2001:db8::1234" ]
                },
                "pools": [ { "pool":  "2001:db8::1 - 2001:db8::ffff" } ]
            },
            {
                "id": 2,
                "subnet": "3ffe:abcd::/64",
                "pools": [ { "pool":  "3ffe:abcd::1 - 3ffe:abcd::ffff" } ],
                "relay": {
                    # Specifying a different relay address for this
                    # subnet is a configuration error. In this case
                    # it should be 2001:db8::1234 or the relay address
                    # in the previous subnet should be 3ffe:abcd::cafe.
                    "ip-addresses": [ "3ffe:abcd::cafe" ]
                }
            }
        ]
    }
],
...
}

مجدداً، بهتر است نشانی رله در سطح shared-network تعیین شود؛ این مقدار توسط تمام زیرشبکه‌های متعلق به شبکهٔ اشتراکی به ارث برده خواهد شد.

{
"shared-networks": [
    {
        "name": "kakapo",
        "relay": {
            # This relay address is inherited by both subnets.
            "ip-addresses": [ "2001:db8::1234" ]
        },
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8::/64",
                "pools": [ { "pool":  "2001:db8::1 - 2001:db8::ffff" } ]
            },
            {
                 "id": 2,
                 "subnet": "3ffe:abcd::/64",
                 "pools": [ { "pool":  "3ffe:abcd::1 - 3ffe:abcd::ffff" } ]
            }
        ]
    }
],
...
}

اگرچه از نظر فنی امکان پیکربندی دو (یا چند) زیرشبکه در شبکهٔ اشتراکی برای استفاده از نشانی‌های رلهٔ متفاوت وجود دارد، اما این کار تقریباً همیشه به رفتاری متفاوت از انتظار کاربر منجر خواهد شد. در این حالت، سرور Kea در ابتدا یکی از زیرشبکه‌ها را با تطبیق نشانی رله در بستهٔ کلاینت با پیکربندی زیرشبکه انتخاب می‌کند. با این حال، اگر کلاینت از قبل اجاره‌ای (lease) در زیرشبکهٔ دیگر داشته باشد یا یک رزرو میزبان (host reservation) در آن زیرشبکه داشته باشد، یا صرفاً اگر زیرشبکهٔ انتخاب‌شده در ابتدا نشانی در دسترس دیگری نداشته باشد، سرور ممکن است در نهایت از زیرشبکهٔ دیگر استفاده کند (حتی اگر با نشانی رله مطابقت نداشته باشد). بنابراین، اکیداً توصیه می‌شود در صورتی که زیرشبکه‌ها متعلق به یک شبکهٔ اشتراکی هستند، همیشه انتخاب‌گرهای زیرشبکه (interface یا نشانی relay) در سطح shared-network تعیین شوند، چرا که تعیین آن‌ها در سطح subnet به‌ندرت مفید است و می‌تواند منجر به خطاهای پیکربندی شرح داده شده در بالا شود..SS "طبقه‌بندی کلاینت‌ها در شبکه‌های مشترک (Client Classification in Shared Networks)"

گاهی مطلوب است که کلاینت‌ها بر اساس ویژگی‌های معینی در زیرشبکه‌های خاصی تفکیک شوند. این سازوکار طبقه‌بندی کلاینت (client classification) نامیده می‌شود و در Client Classification <#classify> شرح داده شده است. طبقه‌بندی کلاینت را می‌توان به همان شیوه‌ای که برای زیرشبکه‌های تعریف‌شده در خارج از شبکه‌های مشترک استفاده می‌شود، برای زیرشبکه‌های متعلق به شبکه‌های مشترک (shared networks) نیز اعمال کرد. درک نحوهٔ انتخاب زیرشبکه‌ها برای کلاینت‌ها توسط سرور هنگام استفاده از طبقه‌بندی کلاینت اهمیت دارد، تا اطمینان حاصل شود که زیرشبکهٔ مناسب برای یک نوع کلاینت مشخص انتخاب می‌شود.

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

پارامتر client-classes ممکن است در دامنه‌های shared network، subnet و/یا pool تعیین شود. اگر برای یک shared network تعیین شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های مشخص‌شده برای آن شبکه باشند تا برای زیرشبکه‌های درون آن شبکه در نظر گرفته شوند. اگر برای یک subnet مشخص گردد، کلاینت‌ها باید دست‌کم متعلق به یکی از کلاس‌های مشخص‌شده برای آن زیرشبکه باشند تا برای هر یک از استخرها (pools) یا رزروهای میزبان (host reservations) آن زیرشبکه مد نظر قرار گیرند. اگر برای یک pool مشخص شود، کلاینت‌ها باید حداقل عضو یکی از کلاس‌های مشخص‌شده برای آن استخر باشند تا یک اجاره (lease) از آن pool دریافت کنند.

مثال زیر را در نظر بگیرید:

{
    "client-classes": [
        {
            "name": "b-devices",
            "test": "option[1234].hex == 0x0002"
        }
    ],
    "shared-networks": [
        {
            "name": "galah",
            "relay": {
                "ip-address": [ "2001:db8:2:34::1" ]
            },
            "subnet6": [
                {
                    "id": 1,
                    "subnet": "2001:db8:1::/64",
                    "pools": [ { "pool": "2001:db8:1::20 - 2001:db8:1::ff" } ]
                },
                {
                    "id": 2,
                    "subnet": "2001:db8:3::/64",
                    "pools": [ { "pool": "2001:db8:3::20 - 2001:db8:3::ff" } ],
                    "client-classes": "b-devices"
                }
            ]
        }
    ]
}

اگر کلاینت متعلق به کلاس "b-devices" باشد (به این دلیل که شامل option 1234 با مقدار 0x0002 است)، این تضمین نمی‌کند که زیرشبکهٔ 2001:db8:3::/64 برای این کلاینت استفاده (یا ترجیح داده) شود. سرور می‌تواند از هر یک از این دو زیرشبکه استفاده کند، چرا که زیرشبکهٔ 2001:db8:1::/64 نیز برای این کلاینت مجاز است. طبقه‌بندی کلاینت به‌کاررفته در این مورد باید به عنوان راهی برای محدود کردن دسترسی به زیرشبکه‌های خاص تلقی شود، نه روشی برای اولویت‌بندی زیرشبکه‌ها. برای مثال، اگر کلاینت متعلق به کلاس "b-devices" نباشد، فقط می‌تواند از زیرشبکهٔ 2001:db8:1::/64 استفاده کند و هرگز از زیرشبکهٔ 2001:db8:3::/64 استفاده نخواهد کرد.

یک کاربرد معمول برای طبقه‌بندی کلاینت در شبکه‌های کابلی (cable network) است؛ جایی که مودم‌های کابلی باید از یک زیرشبکه و سایر دستگاه‌ها باید از زیرشبکهٔ دیگری درون همان شبکهٔ مشترک استفاده کنند. در این حالت، اعمال طبقه‌بندی بر روی تمام زیرشبکه‌ها ضروری است. مثال زیر دو کلاس از دستگاه‌ها را تعریف می‌کند و انتخاب زیرشبکه بر اساس مقادیر option 1234 انجام می‌گیرد.

{
    "client-classes": [
        {
            "name": "a-devices",
            "test": "option[1234].hex == 0x0001"
        },
        {
            "name": "b-devices",
            "test": "option[1234].hex == 0x0002"
        }
    ],
    "shared-networks": [
        {
            "name": "galah",
            "relay": {
                "ip-addresses": [ "2001:db8:2:34::1" ]
            },
            "subnet6": [
                {
                    "id": 1,
                    "subnet": "2001:db8:1::/64",
                    "pools": [ { "pool": "2001:db8:1::20 - 2001:db8:1::ff" } ],
                    "client-classes": [ "a-devices" ]
                },
                {
                    "id": 2,
                    "subnet": "2001:db8:3::/64",
                    "pools": [ { "pool": "2001:db8:3::20 - 2001:db8:3::ff" } ],
                    "client-classes": [ "b-devices" ]
                }
            ]
        }
    ]
}

در این مثال هر کلاس محدودیت خاص خود را دارد. تنها کلاینت‌هایی که متعلق به کلاس "a-devices" هستند می‌توانند از زیرشبکهٔ 2001:db8:1::/64 استفاده کنند و تنها کلاینت‌های متعلق به "b-devices" قادر به استفاده از زیرشبکهٔ 2001:db8:3::/64 خواهند بود. باید دقت شود که قواعد طبقه‌بندی بیش از حد محدودکننده تعریف نشوند، زیرا از ارائهٔ سرویس به کلاینت‌هایی که قادر به استفاده از هیچ زیرشبکه‌ای نیستند امتناع خواهد شد. با این حال، چنانچه هدف ارائهٔ سرویس صرفاً به کلاینت‌هایی با ویژگی‌های مشخص باشد (مثلاً فقط تلفن‌های VoIP مجاز به اتصال به یک پیوند خاص باشند)، این می‌تواند یک نتیجهٔ مطلوب باشد.

می‌توان بدون استفاده از shared networks نیز به نتیجه‌ای مشابه با آنچه در این بخش مطرح شد دست یافت. اگر زیرشبکه‌ها به جای قرار گرفتن در shared network، در دامنهٔ سراسری زیرشبکه‌ها (global subnets scope) قرار گیرند، سرور همچنان از قواعد طبقه‌بندی برای انتخاب زیرشبکهٔ مناسب برای یک کلاس خاص از دستگاه‌ها استفاده خواهد کرد. مزیت اصلی قرار دادن زیرشبکه‌ها در یک shared network این است که پارامترهای مشترک برای زیرشبکه‌هایی که از نظر منطقی گروه‌بندی شده‌اند را می‌توان یک‌بار در دامنهٔ shared network مشخص کرد؛ مانند پارامترهای interface یا relay. تمام زیرشبکه‌های متعلق به این شبکه مشترک، آن پارامترها را به ارث خواهند برد..SS رزروهای میزبان در شبکه‌های اشتراکی (Shared Networks)

زیرشبکه‌هایی که بخشی از یک شبکه اشتراکی هستند، همانند زیرشبکه‌های معمولی اجازه رزرو میزبان را می‌دهند:

{
    "shared-networks": [
    {
        "name": "frog",
        "relay": {
            "ip-addresses": [ "2001:db8:2:34::1" ]
        },
        "subnet6": [
            {
                "subnet": "2001:db8:1::/64",
                "id": 100,
                "pools": [ { "pool": "2001:db8:1::1 - 2001:db8:1::64" } ],
                "reservations": [
                {
                    "duid": "00:03:00:01:11:22:33:44:55:66",
                    "ip-addresses": [ "2001:db8:1::28" ]
                }
                ]
            },
            {
                "subnet": "2001:db8:3::/64",
                "id": 101,
                "pools": [ { "pool": "2001:db8:3::1 - 2001:db8:3::64" } ],
                "reservations": [
                    {
                        "duid": "00:03:00:01:aa:bb:cc:dd:ee:ff",
                        "ip-addresses": [ "2001:db8:2::28" ]
                    }
                ]
            }
        ]
    }
    ]
}

شایان ذکر است که در صورت تعریف شبکه‌های اشتراکی، Kea هنگام پردازش بسته، بررسی‌های بیشتری انجام می‌دهد. نخست، Kea به جای اینکه صرفاً بررسی کند آیا برای کلاینت مورد نظر در زیرشبکه اولیه انتخاب‌شده رزروی وجود دارد یا خیر، تمام زیرشبکه‌های موجود در یک شبکه اشتراکی را برای یافتن رزرو جستجو می‌کند. این یکی از دلایلی است که چرا تعریف یک شبکه اشتراکی ممکن است بر کارایی تأثیر بگذارد. اگر در هر یک از زیرشبکه‌ها رزروی برای کلاینت وجود داشته باشد، همان زیرشبکه خاص برای کلاینت انتخاب می‌شود. اگرچه از نظر فنی خطا محسوب نمی‌شود، اما تعریف رزرو برای یک میزبان یکسان در چندین زیرشبکه متعلق به یک شبکه اشتراکی، روشی نادرست تلقی می‌شود.

اگرچه استفاده از مقادیر صریح "id" برای زیرشبکه‌ها کاملاً اجباری نیست، اما در صورتی که قرار باشد از ذخیره‌سازی پایگاه‌داده برای رزروهای میزبان استفاده شود، به‌شدت توصیه می‌شود. اگر یک شناسه مشخص نشود، مقادیر آن به‌طور خودکار تولید می‌شوند؛ بدین معنا که Kea مقادیر صحیح افزایشی را از ۱ تخصیص می‌دهد. بنابراین، شناسه‌های تولیدشده به‌طور خودکار در طول تغییرات پیکربندی پایدار نخواهند بود.

پروتکل DHCPv6 از یک "شناسه سرور" (که با نام DUID نیز شناخته می‌شود) استفاده می‌کند تا به کلاینت‌ها امکان دهد بین چندین سرور موجود در یک پیوند (link) یکسان تمایز قائل شوند. استاندارد RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 در حال حاضر چهار نوع DUID را تعریف می‌کند: DUID-LLT، DUID-EN، DUID-LL و DUID-UUID.

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

نرم‌افزار Kea از توصیه مطرح‌شده در RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 مبنی بر استفاده از DUID-LLT به عنوان شناسه سرور پیش‌فرض پیروی می‌کند. با این حال، ISC گزارش‌هایی دریافت کرده است مبنی بر اینکه برخی استقرارها به انواع متفاوتی از DUID نیاز دارند، و لازم است نوع DUID و/یا محتوای آن به صورت مدیریتی تعیین شود.

شناسه سرور را می‌توان با استفاده از پارامترهای موجود در عنصر نگاشت server-id در حوزه سراسری فایل پیکربندی Kea پیکربندی کرد. مثال زیر نحوه انتخاب DUID-EN را به عنوان شناسه سرور نشان می‌دهد:

"Dhcp6": {
    "server-id": {
        "type": "EN"
    },
    ...
}

مقادیر پشتیبانی‌شده کنونی برای پارامتر type به ترتیب عبارتند از: "LLT"، "EN" و "LL"، به ترتیب برای DUID-LLT، DUID-EN و DUID-LL.

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

نکته:

اگر شناسه سرور جدید پس از دریافت اجاره‌ها (leases) توسط برخی کلاینت‌ها ایجاد شود، کلاینت‌هایی که از شناسه قدیمی استفاده می‌کنند قادر به تمدید اجاره‌های خود نخواهند بود؛ سرور پیام‌های حاوی شناسه سرور قدیمی را نادیده خواهد گرفت. کلاینت‌ها به ارسال پیام‌های RENEW ادامه می‌دهند تا زمانی که به وضعیت rebinding منتقل شوند. در این وضعیت، آنها شروع به ارسال پیام‌های REBIND به آدرس چندپخشی (multicast) بدون شناسه سرور می‌کنند. سرور با شناسه سرور جدید به پیام‌های REBIND پاسخ می‌دهد و کلاینت‌ها شناسه سرور جدید را با اجاره‌های خود مرتبط می‌سازند. اگرچه کلاینت‌ها قادر به حفظ اجاره‌های خود خواهند بود و در نهایت شناسه سرور جدید را یاد می‌گیرند، اما این امر به بهای افزایش تعداد درخواست‌های تمدید و ترافیک چندپخشی ناشی از نیاز به rebind تمام خواهد شد. بنابراین، توصیه می‌شود در صورتی که سرور از قبل اجاره‌هایی تخصیص داده و این اجاره‌ها همچنان معتبر هستند، از تغییر نوع و مقدار شناسه سرور خودداری شود.

مواردی وجود دارد که مدیر سیستم به جای اجازه دادن به سرور برای تولید مقدار DUID، نیاز به تعیین صریح آن دارد. مثال زیر نحوه تنظیم صریح تمامی مؤلفه‌های یک DUID-LLT را نشان می‌دهد.

"Dhcp6": {
    "server-id": {
        "type": "LLT",
        "htype": 8,
        "identifier": "A65DC7410F05",
        "time": 2518920166
    },
    ...
}

که در آن:

  • htype یک مقدار ۱۶ بیتی بدون علامت است که نوع سخت‌افزار را مشخص می‌کند،
  • identifier یک آدرس لایه پیوند (link-layer) است که به صورت رشته‌ای از ارقام هگزادسیمال مشخص می‌شود، و
  • time یک مقدار زمان ۳۲ بیتی بدون علامت است.

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

 00:01:00:08:96:23:AB:E6:A6:5D:C7:41:0F:05
|type |htype|   time    |   identifier    |

مقدار ویژه "0" برای htype و time مجاز است، که نشان می‌دهد سرور باید از هر مقداری برای این مؤلفه‌ها استفاده کند. اگر سرور از قبل از یک DUID-LLT استفاده کند، از مقادیر موجود در همین DUID استفاده خواهد کرد؛ اگر سرور از DUID با نوع متفاوتی استفاده کند یا هنوز از هیچ DUID استفاده نکرده باشد، این مقادیر را تولید خواهد کرد. به همین ترتیب، اگر به identifier یک رشته خالی اختصاص داده شود، مقدار identifier تولید خواهد شد. حذف هر یک از این پارامترها معادل تنظیم آنها بر روی این مقادیر ویژه است.

برای نمونه، پیکربندی زیر:

"Dhcp6": {
    "server-id": {
        "type": "LLT",
        "htype": 0,
        "identifier": "",
        "time": 2518920166
    },
    ...
}

نشان می‌دهد که سرور باید از هر آدرس لایه پیوند و نوع سخت‌افزاری استفاده کند. اگر سرور از قبل از DUID-LLT استفاده کند، از آدرس لایه پیوند و نوع سخت‌افزار موجود در DUID فعلی استفاده خواهد کرد. اگر سرور هنوز از هیچ DUID استفاده نمی‌کند، از آدرس لایه پیوند و نوع سخت‌افزار یکی از رابط‌های شبکه موجود استفاده خواهد کرد. سرور از مقدار زمانی صریح استفاده خواهد کرد؛ اگر این مقدار با مقدار زمان موجود در DUID کنونی متفاوت باشد، آن مقدار جایگزین خواهد شد که عملاً شناسه سرور فعلی را تغییر می‌دهد.

مثال زیر یک پیکربندی صریح از یک DUID-EN را نشان می‌دهد:

"Dhcp6": {
    "server-id": {
        "type": "EN",
        "enterprise-id": 2495,
        "identifier": "87ABEF7A5BB545"
    },
    ...
}

که در آن:

enterprise-id یک مقدار ۳۲-بیتی بدون علامت است که شماره سازمانی (enterprise number) را نگه می‌دارد، و
•
identifier یک شناسه با طول متغیر در DUID-EN است.

نمایش هگزادسیمال DUID-EN ایجادشده طبق پیکربندی بالا به صورت زیر است:

 00:02:00:00:09:BF:87:AB:EF:7A:5B:B5:45
|type |  ent-id   |     identifier     |

همانند حالت DUID-LLT، می‌توان از مقادیر ویژه‌ای برای پیکربندی DUID-EN استفاده کرد. اگر enterprise-id برابر "0" باشد، سرور از مقدار موجود در DUID-EN فعلی استفاده خواهد کرد. اگر سرور از هیچ DUID استفاده نکند یا DUID موجود از نوع متفاوتی باشد، شناسه سازمانی ISC استفاده خواهد شد. هنگامی که یک رشته خالی برای identifier وارد شود، از شناسه موجود در DUID-EN فعلی استفاده می‌شود. اگر سرور از هیچ DUID-EN استفاده نکند، یک identifier جدید با طول ۶ بایت ایجاد خواهد شد.

پیکربندی DUID-LL به همان روش DUID-LLT انجام می‌شود، با این تفاوت که پارامتر time هیچ تأثیری بر DUID-LL ندارد، زیرا این نوع DUID تنها شامل یک نوع سخت‌افزار و نشانی لایه پیوند است. مثال زیر نحوه پیکربندی DUID-LL را نشان می‌دهد:

"Dhcp6": {
    "server-id": {
        "type": "LL",
        "htype": 8,
        "identifier": "A65DC7410F05"
    },
    ...
}

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

 00:03:00:08:A6:5D:C7:41:0F:05
|type |htype|   identifier    |

سرور شناسه سرور ایجادشده را در مکان زیر ذخیره می‌کند: "[kea-install-dir]/var/lib/kea/kea-dhcp6-serverid".

از Kea نسخه 2.7.9 به بعد، این مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_DHCP_DATA_DIR به مسیر دلخواه بازنویسی شود.

در برخی استقرارهای نامتداول که هیچ فضای ذخیره‌سازی پایداری در دسترس نیست، سرور باید طوری پیکربندی شود که برای ذخیره شناسه سرور تلاش نکند. این انتخاب با مقدار پارامتر بولی persist کنترل می‌شود:

"Dhcp6": {
    "server-id": {
        "type": "EN",
        "enterprise-id": 2495,
        "identifier": "87ABEF7A5BB545",
        "persist": false
    },
    ...
}

مقدار پیش‌فرض پارامتر persist برابر با true است، که سرور را طوری پیکربندی می‌کند که شناسه سرور را روی یک دیسک ذخیره کند.

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

سرور Kea DHCPv6 فایل شناسه سرور و فایل پیش‌فرض اجاره‌های حافظه را در دایرکتوری داده‌های خود قرار می‌دهد. به طور پیش‌فرض این دایرکتوری "[kea-install-dir]/var/lib/kea" است، اما این مکان را می‌توان با استفاده از پارامتر سراسری data-directory تغییر داد، مانند:

"Dhcp6": {
    "data-directory": "/var/lib/kea/kea-server6",
    ...
}

نکته:

از Kea نسخه 2.7.9، پارامتر data-directory منسوخ شده است. فایل‌های duid و اجاره (lease) ممکن است فقط از دایرکتوری تعیین‌شده در زمان کامپایل بارگیری شوند: "[kea-install-dir]/var/lib/kea". این مسیر می‌تواند هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_DHCP_DATA_DIR به مسیر مورد نظر بازنویسی شود. اگر مسیری غیر از این مقدار در data-directory استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند.

به‌طور معمول DHCPv6 برای تخصیص هر دو مورد نشانی‌ها و گزینه‌ها به کار می‌رود. این تخصیص‌ها (اجاره‌ها) دارای وضعیتی هستند که در طول زمان تغییر می‌کند، از این رو به عنوان "با‌حالت" توصیف می‌شوند. پروتکل DHCPv6 همچنین از یک حالت "بدون‌حالت" پشتیبانی می‌کند که در آن کلاینت‌ها تنها گزینه‌های پیکربندی را درخواست می‌کنند. این حالت از دیدگاه سرور سبک به شمار می‌آید، زیرا به هیچ‌گونه رهگیری وضعیت نیاز ندارد.

سرور Kea از حالت بدون‌حالت پشتیبانی می‌کند. هنگامی که کلاینت‌ها پیام‌های INFORMATION-REQUEST ارسال می‌کنند، سرور در صورت موجود بودن گزینه‌ها در پیکربندی سرور، پاسخ‌ها را به همراه گزینه‌های درخواستی بازمی‌گرداند. سرور ابتدا تلاش می‌کند از گزینه‌های مختص به هر زیرشبکه استفاده کند؛ اگر این کار ناموفق باشد، سپس سعی می‌کند گزینه‌های تعریف‌شده در حوزه سراسری را ارائه دهد.

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

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

"Dhcp6": {
    "interfaces-config": {
        "interfaces": [ "ethX" ]
    },
    "option-data": [ {
        "name": "dns-servers",
        "data": "2001:db8::1, 2001:db8::2"
    } ],
    "lease-database": {
        "type": "memfile"
    }
 }

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

مستند RFC 7550 https://datatracker.ietf.org/doc/html/rfc7550 تغییراتی را در مشخصات قبلی DHCPv6، یعنی RFC 3315 https://datatracker.ietf.org/doc/html/rfc3315 و RFC 3633 https://datatracker.ietf.org/doc/html/rfc3633 ایجاد کرد تا مشکلات ناشی از همزیستی چند گزینه با‌حالت در پیام‌های مبادله‌شده میان کلاینت‌ها و سرورها برطرف شود. این تغییرات بعداً در جدیدترین مشخصات پروتکل DHCPv6، یعنی RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 گنجانده شدند که جایگزین RFC 7550 https://datatracker.ietf.org/doc/html/rfc7550 گردید. پروتکل Kea از RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 به همراه این تغییرات پروتکل پشتیبانی می‌کند که در ادامه به طور خلاصه شرح داده شده‌اند.

هنگامی که یک کلاینت، مانند یک مسیریاب درخواست‌کننده، در طول تبادل ۴ مرحله‌ای (SARR) با سرور درخواست تخصیص هم‌زمان نشانی‌ها و پیشوندها را ارسال کند و سرور برای تخصیص هیچ پیشوندی پیکربندی نشده باشد اما بتواند تعدادی نشانی تخصیص دهد، با IA_NA(ها) حاوی نشانی‌های تخصیص‌یافته و IA_PD(ها) حاوی کد وضعیت NoPrefixAvail پاسخ خواهد داد. مطابق با مشخصات به‌روزرسانی‌شده، اگر کلاینت بتواند بدون پیشوندها به کار خود ادامه دهد، باید نشانی‌های تخصیص‌یافته را بپذیرد و به وضعیت "bound" منتقل شود. هنگامی که کلاینت متعاقباً پیام‌های RENEW/REBIND را به منظور تمدید طول عمر نشانی‌های تخصیص‌یافته، بر اساس زمان‌های T1 و T2 به سرور ارسال می‌کند، در صورتی که کلاینت همچنان مایل به دریافت پیشوندها از سرور باشد، می‌تواند یک IA_PD را نیز در RENEW/REBIND برای درخواست تخصیص پیشوندها بگنجاند. اگر سرور همچنان قادر به تخصیص پیشوندها نباشد، با IA_PD(ها) حاوی کد وضعیت NoPrefixAvail پاسخ خواهد داد. با این حال، اگر سرور بتواند پیشوندها را تخصیص دهد، آن‌ها را تخصیص داده و در IA_PD(ها) به کلاینت ارسال می‌کند. وضعیت مشابهی زمانی رخ می‌دهد که سرور قادر به تخصیص نشانی برای کلاینت نباشد اما امکان تفویض پیشوندها را داشته باشد: کلاینت می‌تواند هنگام تمدید پیشوندهای تفویض‌شده، درخواست تخصیص نشانی‌ها را مطرح کند. تخصیص اجاره‌ها برای سایر انواع IA در حین تمدید اجاره‌های موجود، به‌طور پیش‌فرض توسط سرور Kea DHCPv6 پشتیبانی می‌شود و سرور هیچ سازوکار پیکربندی‌ای برای غیرفعال کردن این رفتار ارائه نمی‌دهد.

موارد زیر رفتارهای دیگری هستند که ابتدا در RFC 7550 https://datatracker.ietf.org/doc/html/rfc7550 (اکنون بخشی از RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915) معرفی شدند و توسط سرور Kea DHCPv6 پشتیبانی می‌شوند:

  • تنظیم تایمرهای T1/T2 روی مقدار یکسان برای تمام گزینه‌های با‌حالت (IA_NA و IA_PD) به منظور تسهیل تمدید هم‌زمان همه اجاره‌های یک کلاینت (در یک تبادل پیام واحد).
  • قرار دادن کدهای وضعیت NoAddrsAvail و NoPrefixAvail در گزینه‌های IA_NA و IA_PD در پیام ADVERTISE، به جای قرار دادن آن‌ها به عنوان گزینه‌های سطح بالا.

سرور DHCPv6 برای انتخاب یک زیرشبکه جهت کلاینت، از اصول مشابهی با سرور DHCPv4 پیروی می‌کند؛ البته با تفاوت‌های قابل‌توجهی که عمدتاً مربوط به رله‌ها است.

نکته:

هنگامی که زیرشبکه انتخاب‌شده عضوی از یک شبکه مشترک باشد، کل شبکه مشترک انتخاب می‌شود.

یک رله باید رابطی متصل به پیوندی داشته باشد که کلاینت‌ها روی آن پیکربندی می‌شوند. به‌طور معمول رله یک نشانی IPv6 سراسری پیکربندی‌شده روی آن رابط دارد که متعلق به زیرشبکه‌ای است که سرور نشانی‌ها را از آن تخصیص می‌دهد. در شرایط عادی، سرور قادر است از نشانی IPv6 درج‌شده توسط رله (در فیلد link-addr در پیام RELAY-FORW) برای انتخاب زیرشبکه مناسب استفاده کند.

با این حال، همیشه این‌طور نیست؛ نشانی رله ممکن است در برخی استقرارها با زیرشبکه مطابقت نداشته باشد. این موضوع معمولاً به این معنی است که بیش از یک زیرشبکه برای یک پیوند خاص تخصیص یافته است. دو نمونه رایج از این حالت، بازشماره‌گذاری طولانی‌مدت شبکه (جایی که هر دو فضای نشانی قدیم و جدید همچنان مورد استفاده قرار می‌گیرند) و شبکه کابلی هستند. در یک شبکه کابلی، هم مودم‌های کابلی و هم دستگاه‌های پشت آن‌ها به صورت فیزیکی به یک پیوند متصل هستند، اما از آدرس‌دهی متفاوتی استفاده می‌کنند. در چنین حالتی، سرور DHCPv6 به اطلاعات اضافی (مقدار گزینه interface-id یا نشانی IPv6 درج‌شده در فیلد link-addr در پیام RELAY-FORW) نیاز دارد تا بتواند زیرشبکه مناسب را به‌درستی انتخاب کند.

مثال زیر فرض می‌کند که زیرشبکه 2001:db8:1::/64 وجود دارد که از طریق رله‌ای با نشانی IPv6 معادل 3000::1 در دسترس است. سرور قادر است این زیرشبکه را برای هر بسته ورودی که از سوی رله‌ای با نشانی موجود در زیرشبکه 2001:db8:1::/64 می‌آید، انتخاب کند. همچنین آن زیرشبکه را برای رله‌ای با نشانی 3000::1 انتخاب می‌نماید.

"Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/64",
            "pools": [
                 {
                     "pool": "2001:db8:1::1-2001:db8:1::ffff"
                 }
            ],
            "relay": {
                "ip-addresses": [ "3000::1" ]
            }
        }
    ]
}

اگر relay مشخص شده باشد، پارامتر ip-addresses در داخل آن الزامی است. پارامتر ip-addresses از مشخص کردن فهرستی از نشانی‌ها پشتیبانی می‌کند..SS "جداسازی کلاینت‌های IPv6 در یک شبکه کابلی (Segregating IPv6 Clients in a Cable Network)"

در برخی موارد، ترکیب اطلاعات آدرس رله (معرفی‌شده در «Using a Specific Relay Agent for a Subnet») با طبقه‌بندی کلاینت (توضیح‌داده‌شده در «Client Classification» <#classify>) مفید است. یک نمونه خاص، شبکه‌های کابلی است که در آن‌ها مودم‌ها معمولاً آدرس‌هایی از یک زیرشبکه متفاوت نسبت به تمام دستگاه‌های متصل در پشت خود دریافت می‌کنند.

فرض کنیم یک Cable Modem Termination System (CMTS) با یک CM MAC (یک پیوند فیزیکی که مودم‌ها به آن متصل هستند) وجود دارد. ما می‌خواهیم مودم‌ها آدرس‌هایی از زیرشبکه 3000::/64 دریافت کنند، در حالی که تمام دستگاه‌های متصل در پشت مودم‌ها باید آدرس‌هایی از زیرشبکه 2001:db8:1::/64 دریافت کنند. CMTS که به عنوان رله عمل می‌کند از آدرس 3000::1 استفاده می‌کند. پیکربندی زیر می‌تواند پاسخگوی این وضعیت باشد:

"Dhcp6": {
    "subnet6": [
        {
            "id": 1,
            "subnet": "3000::/64",
            "pools": [
                { "pool": "3000::2 - 3000::ffff" }
            ],
            "client-classes": [ "VENDOR_CLASS_docsis3.0" ],
            "relay": {
                "ip-addresses": [ "3000::1" ]
            }
        },
        {
            "id": 2,
            "subnet": "2001:db8:1::/64",
            "pools": [
                 {
                     "pool": "2001:db8:1::1-2001:db8:1::ffff"
                 }
            ],
            "relay": {
                "ip-addresses": [ "3000::1" ]
            }
        }
    ]
}

آدرس‌های سخت‌افزاری/MAC در پیام‌های DHCPv4 ارسالی از سوی کلاینت‌ها در دسترس هستند و مدیران سیستم معمولاً از این اطلاعات برای انجام وظایف خاصی مانند پیکربندی به ازای هر میزبان (per-host configuration) و رزرو آدرس برای آدرس‌های MAC مشخص استفاده می‌کنند. متأسفانه، پروتکل DHCPv6 هیچ راهکار کاملاً قابل اعتمادی برای بازیابی این اطلاعات ارائه نمی‌دهد. برای کاهش این مشکل، سازوکارهای متعددی در Kea پیاده‌سازی شده است. هر یک از این سازوکارها در موارد خاصی کار می‌کنند، اما ممکن است در شرایط دیگر کارایی نداشته باشند. کارکردن این سازوکار در یک استقرار مشخص، تا حدودی به توپولوژی شبکه و فناوری‌های مورد استفاده بستگی دارد.

نرم‌افزار Kea امکان تعیین این موضوع را فراهم می‌کند که کدام‌یک از روش‌های پشتیبانی‌شده و با چه ترتیبی، از طریق پارامتر mac-sources استفاده شوند. این پیکربندی را می‌توان نوعی تنظیم دقیق (fine tuning) برای استقرار DHCP به شمار آورد.

در اینجا یک مثال آمده است:

"Dhcp6": {
    "mac-sources": [
        "method1",
        "method2",
        "method3",
        ...
    ],
    "subnet6": [
        {
            ...
        },
        ...
    ],
    ...
}

در صورت عدم تعیین، مقدار "any" استفاده می‌شود که به سرور دستور می‌دهد تمام روش‌ها را به ترتیب امتحان کرده و از مقدار بازگردانده‌شده توسط اولین روشی که موفق می‌شود استفاده کند. در یک استقرار معمولی، مقدار پیش‌فرض "any" کافی است و نیازی به انتخاب روش‌های خاص نیست. تغییر مقدار این پارامتر بیشتر در مواردی مفید است که مدیر سیستم بخواهد روش‌های خاصی را غیرفعال کند؛ به عنوان مثال، اگر مدیر سیستم به زیرساخت شبکه بیشتر از اطلاعات ارائه‌شده توسط خود کلاینت‌ها اعتماد داشته باشد، ممکن است اطلاعات ارائه‌شده توسط رله‌ها را به اطلاعات ارائه‌شده توسط کلاینت‌ها ترجیح دهد.

در صورت مشخص شدن، mac-sources باید حداقل دارای یک مقدار باشد.

روش‌های پشتیبانی‌شده عبارتند از:

  • any - این یک روش واقعی نیست، بلکه صرفاً کلمه‌ای کلیدی است که به Kea دستور می‌دهد تمام روش‌های دیگر را امتحان کرده و از نخستین روشی که موفق می‌شود استفاده کند. اگر هیچ mac-sources تعریف نشده باشد، این رفتار پیش‌فرض است.
  • raw - در اصل، یک سرور DHCPv6 می‌تواند از سوکت‌های خام (raw sockets) برای دریافت ترافیک ورودی و استخراج اطلاعات آدرس سخت‌افزاری/MAC استفاده کند. این قابلیت در حال حاضر برای DHCPv6 پیاده‌سازی نشده است و این مقدار هیچ اثری ندارد.
  • duid - پروتکل DHCPv6 به جای آدرس‌های MAC از شناساگرهای DUID استفاده می‌کند. در حال حاضر چهار نوع DUID تعریف شده است و دو مورد از آن‌ها (DUID-LLT که پیش‌فرض است، و DUID-LL) اطلاعات آدرس MAC را منتقل می‌کنند. گرچه RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 آن را منع کرده است، اما تجزیه این DUIDها و استخراج اطلاعات لازم از آن‌ها امکان‌پذیر است. این روش کاملاً قابل اعتماد نیست، زیرا کلاینت‌ها ممکن است از انواع دیگر DUID، یعنی DUID-EN یا DUID-UUID استفاده کنند.
  • ipv6-link-local - روش ممکن دیگر برای کسب اطلاعات از آدرس IPv6 مبدأ به دست می‌آید. در استفاده معمول، کلاینت‌ها بسته‌های خود را از آدرس‌های محلی پیوند (link-local) پروتکل IPv6 ارسال می‌کنند. احتمال زیادی وجود دارد که این آدرس‌ها بر پایه EUI-64 باشند که شامل آدرس MAC است. این روش کاملاً قابل اعتماد نیست، چرا که ممکن است کلاینت‌ها از انواع دیگر آدرس‌های link-local استفاده کنند. به‌ویژه، افزونه‌های حریم خصوصی (privacy extensions) تعریف‌شده در RFC 4941 https://datatracker.ietf.org/doc/html/rfc4941 از آدرس‌های MAC استفاده نمی‌کنند. همچنین توجه داشته باشید که استخراج موفقیت‌آمیز مستلزم آن است که بیت u آدرس روی "1" و بیت g آن روی "0" تنظیم شده باشد که نشان‌دهنده شناسه رابط (interface identifier) مطابق با بخش 2.5.1 از RFC 2373 https://datatracker.ietf.org/doc/html/rfc2373#section-2.5.1 است.
  • client-link-addr-option - یکی از افزونه‌های تعریف‌شده برای کاهش مشکلات نبود MAC، گزینه آدرس لایه پیوند کلاینت (client link-layer address option) است که در RFC 6939 https://datatracker.ietf.org/doc/html/rfc6939 تعریف شده است. این گزینه‌ای است که توسط یک رله درج می‌شود و حاوی اطلاعاتی پیرامون آدرس MAC کلاینت است. این روش نیازمند یک عامل رله است که از این گزینه پشتیبانی کند و برای درج آن پیکربندی شده باشد. این روش برای کلاینت‌هایی که اتصال مستقیم دارند بی‌فایده است. مقدار rfc6939 یک نام مستعار برای client-link-addr-option است.
  • remote-id - سند RFC 4649 https://datatracker.ietf.org/doc/html/rfc4649 گزینه remote-id را تعریف می‌کند که توسط یک عامل رله درج می‌شود. بسته به پیکربندی عامل رله، گزینه درج‌شده ممکن است حاوی اطلاعات آدرس MAC کلاینت باشد. مقدار rfc4649 یک نام مستعار برای remote-id است.
  • subscriber-id - تعریف‌شده در RFC 4580 https://datatracker.ietf.org/doc/html/rfc4580، گزینه subscriber-id تا حدی مشابه remote-id است؛ این گزینه نیز توسط یک عامل رله درج می‌شود. مقدار rfc4580 یک نام مستعار برای subscriber-id است. این روش در حال حاضر پیاده‌سازی نشده است.
  • docsis-cmts - یکی دیگر از منابع احتمالی اطلاعات آدرس MAC، گزینه‌های DOCSIS درج‌شده توسط یک CMTS است که به عنوان عامل رله DHCPv6 در شبکه‌های کابلی عمل می‌کند. این روش تلاش می‌کند اطلاعات آدرس MAC را از زیرگزینه 1026 (cm mac) از گزینه خاص سازنده با vendor-id=4491 استخراج کند. این گزینه سازنده از پیام Relay-forward استخراج می‌شود، نه از پیام اصلی کلاینت.
  • docsis-modem - آخرین منبع احتمالی اطلاعات آدرس MAC، گزینه‌های DOCSIS درج‌شده توسط خود مودم کابلی است. این روش تلاش می‌کند اطلاعات آدرس MAC را از زیرگزینه 36 (device-id) از گزینه خاص سازنده با vendor-id=4491 استخراج کند. این گزینه سازنده از پیام اصلی کلاینت استخراج می‌شود، نه از گزینه‌های رله.

یک پارامتر mac-sources خالی مجاز نیست. مدیرانی که تمایلی به تعیین آن ندارند، باید یا تعریف mac-sources را کاملاً حذف کنند یا آن را با مقدار "any" که حالت پیش‌فرض است مشخص نمایند..SS نشانی‌های تکراری (پشتیبانی از DHCPDECLINE)

کارساز DHCPv6 با استخر مشخصی از نشانی‌ها پیکربندی می‌شود که انتظار می‌رود آن‌ها را به کلاینت‌های DHCPv6 واگذار کند. فرض بر این است که کارساز معتبر (authoritative) بوده و اختیار تام بر روی آن نشانی‌ها دارد. با این حال، به دلایل مختلفی مانند پیکربندی نادرست یا پیاده‌سازی معیوب یک کلاینت که نشانی خود را فراتر از طول‌عمر معتبر (valid lifetime) حفظ می‌کند، ممکن است دستگاه‌های متصلی وجود داشته باشند که از آن نشانی‌ها بدون تایید یا آگاهی کارساز استفاده کنند.

چنین رویداد نامطلوبی می‌تواند توسط کلاینت‌های مجاز (با استفاده از Duplicate Address Detection) تشخیص داده شده و با استفاده از یک پیام DHCPDECLINE به کارساز DHCPv6 گزارش شود. کارساز یک بررسی صحت (sanity check) انجام می‌دهد (تا ببیند آیا کلاینتی که نشانی را رد می‌کند، واقعاً قرار بوده از آن استفاده کند یا خیر)، سپس یک عملیات پاک‌سازی انجام داده و با ارسال مجدد پیام REPLY، پیام DHCPDECLINE را تایید می‌کند. هرگونه مدخل DNS مربوط به آن نشانی حذف می‌شود، رویداد لاگ می‌شود و قلاب‌ها (hooks) فعال می‌گردند. پس از تکمیل این روند، نشانی به عنوان ردشده (declined) علامت‌گذاری می‌شود (که نشان می‌دهد توسط یک موجودیت ناشناس استفاده شده و در نتیجه برای تخصیص در دسترس نیست) و یک زمان تعلیق (probation time) روی آن تنظیم می‌شود. مگر اینکه به شکل دیگری پیکربندی شده باشد، دوره تعلیق ۲۴ ساعت طول می‌کشد؛ پس از آن زمان، کارساز اجاره (lease) را بازیابی می‌کند (یعنی آن را دوباره به وضعیت در دسترس بازمی‌گرداند) و نشانی دوباره برای تخصیص در دسترس خواهد بود. لازم به ذکر است که اگر مشکل اساسی دستگاه دارای پیکربندی نادرست برطرف نشود، سناریوی نشانی تکراری مجدداً تکرار خواهد شد. در صورت پیکربندی صحیح، این سازوکار فرصتی را برای بهبود و بازیابی خودکار از چنین رویدادی، بدون هیچ‌گونه دخالت مدیر سیستم، فراهم می‌کند.

برای پیکربندی دوره تعلیق رد نشانی با مقداری غیر از مقدار پیش‌فرض، می‌توان از نحو (syntax) زیر استفاده کرد:

"Dhcp6": {
    "decline-probation-period": 3600,
    "subnet6": [
        {
            ...
        },
        ...
    ],
    ...
}

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

چندین آمار و نقطه قلاب (hook point) مربوط به رویه رسیدگی به رد نشانی وجود دارد. نقطه قلاب lease6_decline پس از اینکه پیام ورودی DHCPDECLINE بررسی صحت شد و کارساز در شرف رد کردن اجاره است، فعال می‌شود. آمار declined-addresses پس از بازگشت قلاب افزایش می‌یابد (هم نسخه سراسری و هم نسخه ویژه زیرشبکه). (برای جزئیات بیشتر درباره آمارهای DHCPv6 و نقاط قلاب Kea، بخش Statistics in the DHCPv6 Server and Hook Libraries <#hooks-libraries> را ببینید.)

به‌محض پایان زمان تعلیق، اجاره ردشده با استفاده از رویه استاندارد بازپس‌گیری اجاره‌های منقضی‌شده، همراه با چند مرحله اضافی بازیابی می‌شود. به‌ویژه، هر دو آمار declined-addresses (سراسری و ویژه زیرشبکه) کاهش می‌یابند. در همان زمان، آمارهای reclaimed-declined-addresses (باز هم در دو گونه سراسری و ویژه زیرشبکه) افزایش می‌یابند.

نکته‌ای درباره آمارها: کارساز Kea هنگام دریافت و پردازش موفقیت‌آمیز پیام DHCPDECLINE، آمار assigned-nas را کاهش نمی‌دهد. اگرچه از نظر فنی یک نشانی ردشده دیگر تخصیص‌یافته نیست، کاربرد اصلی آمار assigned-nas پایش میزان بهره‌وری از استخر است. اکثر افراد فراموش می‌کنند که declined-addresses را در محاسبه بگنجانند و صرفاً از assigned-nas/total-nas استفاده می‌کنند. این امر باعث ایجاد سوگیری در جهت کمتر نشان دادن استفاده از استخر می‌شود. از آنجا که این موضوع پتانسیل ایجاد سردرگمی جدی دارد، ISC تصمیم گرفت که بلافاصله پس از دریافت DHCPDECLINE مقدار assigned-nas را کاهش ندهد، بلکه این کار را بعداً هنگامی که Kea نشانی را به استخر در دسترس بازمی‌گرداند انجام دهد.

نسخه 2.7.7 کارساز Kea پشتیبانی از ثبت نشانی خودتولید (self-generated) را همان‌طور که در RFC 9686 https://datatracker.ietf.org/doc/html/rfc9686 تعریف شده معرفی می‌کند؛ یعنی هنگامی که یک پیام معتبر ADDR-REG-INFORM (36) دریافت می‌شود، یک اجاره ثبت‌شده افزوده یا به‌روزرسانی شده و یک ADDR-REG-REPLY (37) به کلاینت بازگردانده می‌شود.

از نسخه 3.1.4 کارساز Kea، این ویژگی می‌تواند با تنظیم پارامتر allow-address-registration به ترتیب روی true یا false، به‌صورت سراسری فعال یا غیرفعال شود. این ویژگی به‌طور پیش‌فرض فعال است.

سند RFC 9686 https://datatracker.ietf.org/doc/html/rfc9686 از کارسازهایی که از ثبت نشانی پشتیبانی می‌کنند می‌خواهد که در صورت درخواست کلاینت‌ها از طریق گزینه ORO، گزینه 148 را به آن‌ها بازگردانند. مانند هر گزینه استاندارد دیگری، این گزینه نیز باید در پیکربندی کارساز مشخص شود تا به کلاینت‌ها ارسال گردد و این رفتار مستقل از allow-address-registration است.

نکته:

حتی اگر آن‌ها پایگاه‌داده اجاره مشترکی با اجاره‌ها در وضعیت‌های دیگر داشته باشند، اجاره‌های ثبت‌شده مستقل هستند: هنگامی که یک اجاره در وضعیتی دیگر از قبل برای یک نشانی وجود دارد، این نشانی در حال استفاده تلقی شده و نمی‌تواند ثبت شود. به‌طور مشابه، یک اجاره ثبت‌شده نمی‌تواند به وضعیت دیگری تغییر یابد؛ برای مثال، بازپس‌گیری اجاره‌های ثبت‌شده منقضی، آن‌ها را حذف می‌کند.

نکته:

کارساز Kea گزینه Option Request را در پیام ADDR-REG-INFORM می‌پذیرد و پردازش می‌کند (سند RFC مشخص کرده است که کلاینت نباید چنین گزینه‌ای را در آن قرار دهد).

نکته:

کارساز Kea در حال حاضر فقط نشانی‌هایی را می‌پذیرد که "مناسب پیوند" ("appropriate to the link") هستند، اما نشانی‌هایی را که "درون پیشوند واگذارشده به کلاینت" ("within a prefix delegated to the client") هستند هنوز نمی‌پذیرد، که این امر با شیوه توصیف توپولوژی در پیکربندی Kea سازگار نیست.

کارساز DHCPv6 از آمارهای زیر پشتیبانی می‌کند:

آماره نوع داده توضیحات
pkt6-received عدد صحیح تعداد بسته‌های DHCPv6 دریافت‌شده. این مقدار شامل همهٔ بسته‌ها می‌شود: معتبر، جعلی، خراب، رد شده و غیره. انتظار می‌رود این آماره به سرعت رشد کند.
pkt6-service-disabled عدد صحیح تعداد بسته‌های ورودی که هنگام غیرفعال بودن سرویس DHCP دور ریخته شده‌اند.
pkt6-parse-failed عدد صحیح تعداد بسته‌های ورودی که قابل تجزیه نبودند. مقدار غیرصفر برای این آماره نشان می‌دهد که کارساز یک بستهٔ بدشکل یا ناقص دریافت کرده است. این وضعیت ممکن است نشان‌دهندهٔ مشکلاتی در شبکه، کلاینت‌های معیوب، رله‌های معیوب، یا نقصی در کارساز باشد.
pkt6-queue-full عدد صحیح تعداد بسته‌های ورودی که به دلیل پر بودن صف نگه‌داری، دور ریخته شده‌اند.
pkt6-duplicate عدد صحیح تعداد بسته‌های ورودی که پس از تشخیص به عنوان تکراری، دور ریخته شده‌اند.
pkt6-rfc-violation عدد صحیح تعداد بسته‌های ورودی که به دلیل عدم تطابق با مشخصات پروتکل دور ریخته شده‌اند.
pkt6-admin-filtered عدد صحیح تعداد بسته‌های ورودی که بر اساس پیکربندی کارساز دور ریخته شده‌اند، برای نمونه با دسته‌بندی پرس‌وجو در کلاس DROP.
pkt6-not-for-us عدد صحیح تعداد بسته‌های ورودی که دور ریخته شدند زیرا باید توسط کارساز دیگری پردازش می‌شدند.
pkt6-processing-failed عدد صحیح تعداد بسته‌های ورودی که به دلیل رخ دادن خطایی غیرمنتظره در حین پردازش، دور ریخته شدند.
pkt6-limit-exceeded عدد صحیح تعداد بسته‌های ورودی که توسط کتابخانهٔ قلاب limits دور ریخته شده‌اند.
pkt6-receive-drop عدد صحیح تعداد بسته‌های ورودی که دور ریخته شده‌اند. علت دقیق دور ریختن بسته‌ها ثبت می‌شود، اما شایع‌ترین دلایل ممکن است دریافت نوع بستهٔ غیرقابل‌قبول یا پشتیبانی‌نشده، ممنوع بودن پاسخ‌های مستقیم، عدم تطابق شناسهٔ کارساز ارسال‌شده توسط کلاینت با شناسهٔ کارساز، بدشکل بودن بسته، یا رخ دادن خطایی غیرمنتظره در حین پردازش باشد.
pkt6-solicit-received عدد صحیح تعداد بسته‌های SOLICIT دریافت‌شده. انتظار می‌رود این آماره افزایش یابد؛ رشد آن یعنی کلاینت‌هایی که تازه راه‌اندازی شده‌اند فرآیند پیکربندی خود را آغاز کرده و بسته‌های اولیهٔ آن‌ها به کارساز Kea رسیده است.
pkt6-advertise-received عدد صحیح تعداد بسته‌های ADVERTISE دریافت‌شده. بسته‌های ADVERTISE توسط کارساز ارسال می‌شوند و هرگز انتظار نمی‌رود کارساز آن‌ها را دریافت کند؛ مقدار غیرصفر برای این آماره نشان‌دهندهٔ خطایی در شبکه است. یک دلیل محتمل می‌تواند یک عامل رلهٔ نادرست باشد که پیام‌های ADVERTISE را به جای بازگرداندن به کلاینت‌ها، به اشتباه به سمت کارساز بازپخش می‌کند.
pkt6-request-received عدد صحیح تعداد بسته‌های DHCPREQUEST دریافت‌شده. انتظار می‌رود این آماره رشد کند. افزایش آن بدین معنی است که کلاینت‌های تازه راه‌اندازی‌شده پاسخ کارساز (DHCPADVERTISE) را دریافت و قبول کرده‌اند، و اکنون در حال درخواست یک نشانی (DHCPREQUEST) هستند.
pkt6-reply-received عدد صحیح تعداد بسته‌های REPLY دریافت‌شده. انتظار می‌رود این آماره همواره صفر بماند، زیرا بسته‌های REPLY توسط کارساز ارسال می‌شوند و هرگز نباید دریافت شوند. مقدار غیرصفر نشان‌دهندهٔ خطا است. یک علت محتمل می‌تواند یک عامل رلهٔ نادرست باشد که پیام‌های REPLY را به جای کلاینت‌ها، به اشتباه به سمت کارساز بازپخش می‌کند.
pkt6-renew-received عدد صحیح تعداد بسته‌های RENEW دریافت‌شده. انتظار می‌رود این آماره افزایش یابد؛ رشد آن بدین معنا است که کلاینت‌ها نشانی‌ها و پیشوندهای خود را دریافت کرده و در تلاش برای تمدید آن‌ها هستند.
pkt6-rebind-received عدد صحیح تعداد بسته‌های REBIND دریافت‌شده. مقدار غیرصفر نشان می‌دهد کلاینت‌ها پاسخی برای پیام‌های RENEW خود (از طریق سازوکار عادی تمدید اجاره) دریافت نکرده‌اند و در تلاشند هر کارسازی را که بتواند اجاره‌های آن‌ها را به عهده بگیرد، بیابند. این وضعیت ممکن است به این معنی باشد که پیام‌های REPLY برخی کارسازها هرگز به کلاینت‌ها نرسیده است.
pkt6-release-received عدد صحیح تعداد بسته‌های RELEASE دریافت‌شده. انتظار می‌رود هنگام خاموش شدن یک دستگاه در شبکه، این آماره رشد کند؛ این آماره نشان می‌دهد که نشانی یا پیشوند واگذارشده دیگر مورد نیاز نیست. توجه داشته باشید که بسیاری از دستگاه‌ها، به‌ویژه دستگاه‌های بی‌سیم، چه به دلیل طراحی و چه به دلیل خارج شدن کلاینت از محدوده، بستهٔ RELEASE ارسال نمی‌کنند.
pkt6-decline-received عدد صحیح تعداد بسته‌های DECLINE دریافت‌شده. انتظار می‌رود این آماره نزدیک به صفر بماند. افزایش آن نشان می‌دهد کلاینتی یک نشانی را اجاره کرده، اما متوجه شده که نشانی هم‌اکنون توسط دستگاهی ناشناخته در شبکه در حال استفاده است. اگر این آماره در حال رشد باشد، ممکن است نشان‌دهندهٔ کارساز با پیکربندی نادرست یا وجود دستگاه‌هایی با نشانی‌های ایستای متداخل باشد.
pkt6-infrequest-received عدد صحیح تعداد بسته‌های INFORMATION-REQUEST دریافت‌شده. انتظار می‌رود در صورت وجود دستگاه‌هایی که از DHCPv6 بدون‌حالت استفاده می‌کنند، این آماره افزایش یابد. پیام‌های INFORMATION-REQUEST توسط کلاینت‌هایی استفاده می‌شود که پیکربندی بدون‌حالت، یعنی گزینه‌ها و پارامترهایی غیر از نشانی‌ها یا پیشوندها را درخواست می‌کنند.
pkt6-lease-query-received عدد صحیح تعداد بسته‌های LEASEQUERY دریافت‌شده توسط کتابخانهٔ قلاب leasequery. انتظار می‌رود این آماره افزایش یابد.
pkt6-dhcpv4-query-received عدد صحیح تعداد بسته‌های DHCPv4-QUERY دریافت‌شده. انتظار می‌رود در صورت وجود دستگاه‌هایی که از DHCPv4-over-DHCPv6 استفاده می‌کنند، این آماره رشد کند. پیام‌های DHCPv4-QUERY توسط کلاینت‌های DHCPv4 روی یک خط فقط-IPv6 استفاده می‌شود که درخواست‌ها را روی DHCPv6 کپسوله‌سازی می‌کند.
pkt6-dhcpv4-response-received عدد صحیح تعداد بسته‌های DHCPv4-RESPONSE دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، زیرا بسته‌های DHCPv4-RESPONSE توسط کارساز ارسال می‌شوند و انتظار نمی‌رود کارساز هرگز آن‌ها را دریافت کند. مقدار غیرصفر نشان‌دهندهٔ خطا است. یک دلیل محتمل می‌تواند یک عامل رلهٔ نادرست باشد که پیام DHCPv4-RESPONSE را به جای کلاینت‌ها، به اشتباه به سمت کارساز بازپخش می‌کند.
pkt6-addr-reg-inform-received عدد صحیح تعداد بسته‌های ADDR-REG-INFORM دریافت‌شده. انتظار می‌رود در صورت وجود دستگاه‌هایی که از ثبت نشانی استفاده می‌کنند، این آماره رشد کند.
pkt6-addr-reg-reply-received عدد صحیح تعداد بسته‌های ADDR-REG-REPLY دریافت‌شده. انتظار می‌رود این آماره همیشه صفر بماند، زیرا بسته‌های ADDR-REG-REPLY توسط کارساز ارسال می‌شوند و کارساز هرگز نباید آن‌ها را دریافت کند. مقدار غیرصفر نشان‌دهندهٔ خطا است. یک دلیل محتمل می‌تواند عامل رله‌ای باشد که به اشتباه پیام ADDR-REG-REPLY را به سمت کارساز بازپخش می‌کند.
pkt6-unknown-received عدد صحیح تعداد بسته‌های دریافت‌شده با نوع ناشناخته. مقدار غیرصفر برای این آماره نشان می‌دهد کارساز بسته‌ای را دریافت کرده که قادر به شناسایی آن نبوده است؛ یا نوع آن پشتیبانی‌نشده بوده یا احتمالاً مخدوش بوده است.
pkt6-sent عدد صحیح تعداد بسته‌های DHCPv6 ارسال‌شده. انتظار می‌رود با هر بار ارسال بسته توسط کارساز، این آماره رشد کند. به طور کلی، این مقدار باید تقریباً با pkt6-received همخوانی داشته باشد، زیرا بیشتر بسته‌های ورودی باعث پاسخ دادن کارساز می‌شوند. استثناهایی وجود دارد (مانند دریافت یک REQUEST با شناسهٔ کارساز متعلق به کارسازی دیگر)، بنابراین اگر از pkt6-received کمتر بود جای نگرانی نیست.
pkt6-advertise-sent عدد صحیح تعداد بسته‌های ADVERTISE ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش یک SOLICIT، این آماره افزایش یابد. موارد نامعمول اما معتبری وجود دارد که در آن‌ها بسته‌های SOLICIT ورودی دور ریخته می‌شوند، اما در کل انتظار می‌رود این آماره به pkt6-solicit-received نزدیک باشد.
pkt6-reply-sent عدد صحیح تعداد بسته‌های REPLY ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش SOLICIT (با rapid-commit)،‏ REQUEST،‏ RENEW،‏ REBIND،‏ RELEASE،‏ DECLINE، یا INFORMATION-REQUEST این آماره رشد کند. در موارد خاصی پاسخی ارسال نمی‌شود.
pkt6-lease-query-reply-sent عدد صحیح تعداد بسته‌های LEASEQUERY-REPLY ارسال‌شده توسط کتابخانهٔ قلاب leasequery. انتظار می‌رود این آماره افزایش یابد.
pkt6-dhcpv4-response-sent عدد صحیح تعداد بسته‌های DHCPv4-RESPONSE ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش یک DHCPv4-QUERY این آماره افزایش یابد. در موارد خاصی پاسخی ارسال نمی‌شود.
pkt6-addr-reg-reply-sent عدد صحیح تعداد بسته‌های ADDR-REG-REPLY ارسال‌شده. انتظار می‌رود در بیشتر موارد پس از پردازش یک ADDR-REG-INFORM این آماره رشد کند. در موارد خاصی پاسخی ارسال نمی‌شود.
subnet[id].total-nas عدد صحیح بزرگ تعداد کل نشانی‌های NA موجود برای مدیریت DHCPv6 در یک زیرشبکهٔ مشخص؛ به عبارت دیگر، این مقدار شمارش همهٔ نشانی‌ها در تمامی استخرهای پیکربندی‌شده است. این آماره فقط در طول تغییرات پیکربندی تغییر می‌کند. این مقدار نشانی‌هایی را که ممکن است به دلیل رزرو میزبان رزرو شده باشند شامل نمی‌شود. شناسهٔ id شناسهٔ زیرشبکهٔ مربوطه است. این آماره برای هر زیرشبکه به طور جداگانه ارائه می‌شود، و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].pool[pid].total-nas عدد صحیح بزرگ تعداد کل نشانی‌های NA موجود برای مدیریت DHCPv6 در یک استخر زیرشبکهٔ مشخص؛ به بیان دیگر، این تعداد همهٔ نشانی‌های موجود در استخر زیرشبکهٔ پیکربندی‌شده است. این آماره فقط در طول تغییرات پیکربندی تغییر می‌کند. نشانی‌هایی که به دلیل رزرو میزبان رزرو شده باشند به حساب نمی‌آیند. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر مربوطه است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌شود.
assigned-nas عدد صحیح تعداد نشانی‌های NA که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد، و در حین رویداد پیکربندی مجدد بازنشانی می‌شود.
cumulative-assigned-nas عدد صحیح تعداد تجمعی نشانی‌های NA که از زمان راه‌اندازی کارساز واگذار شده‌اند. این آماره با هر بار واگذاری نشانی NA افزایش می‌یابد و هنگام پیکربندی مجدد کارساز بازنشانی نمی‌شود.
subnet[id].cumulative-assigned-nas عدد صحیح تعداد تجمعی نشانی‌های NA در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و هرگز کاهش نمی‌یابد. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه به طور جداگانه ارائه می‌شود، و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].pool[pid].cumulative-assigned-nas عدد صحیح تعداد تجمعی نشانی‌های NA در یک استخر زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و هرگز کاهش پیدا نمی‌کند. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر مربوطه است. این آماره برای هر استخر زیرشبکه جداگانه ارائه می‌شود و در رویداد پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].assigned-nas عدد صحیح تعداد نشانی‌های NA در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].pool[pid].assigned-nas عدد صحیح تعداد نشانی‌های NA در یک استخر زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه جداگانه ارائه شده و در حین پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].total-pds عدد صحیح بزرگ تعداد کل پیشوندهای PD موجود برای مدیریت DHCPv6 در یک زیرشبکهٔ مشخص؛ به عبارت دیگر، این مقدار شمارش همهٔ پیشوندها در تمامی استخرهای پیکربندی‌شده است. این آماره فقط در طول تغییرات پیکربندی تغییر می‌کند. توجه داشته باشید که هیچ‌یک از پیشوندهایی که ممکن است به دلیل رزرو میزبان رزرو شده باشند به حساب نمی‌آیند. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].pd-pool[pid].total-pds عدد صحیح بزرگ تعداد کل پیشوندهای PD موجود برای مدیریت DHCPv6 در یک استخر زیرشبکهٔ مشخص؛ به عبارت دیگر، این تعداد کل پیشوندها در یک استخر PD زیرشبکهٔ پیکربندی‌شده است. این آماره فقط در حین تغییرات پیکربندی تغییر می‌کند. این مقدار پیشوندهای رزروشده به دلیل رزرو میزبان را شامل نمی‌شود. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر مشخص است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌شود.
assigned-pds عدد صحیح تعداد پیشوندهای PD که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد، و در حین رویداد پیکربندی مجدد بازنشانی می‌شود.
cumulative-assigned-pds عدد صحیح تعداد تجمعی پیشوندهای PD که از زمان راه‌اندازی کارساز واگذار شده‌اند. این مقدار با هر بار واگذاری پیشوند PD افزایش می‌یابد و هنگام پیکربندی مجدد کارساز بازنشانی نمی‌شود.
subnet[id].cumulative-assigned-pds عدد صحیح تعداد تجمعی پیشوندهای PD در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و هرگز کاهش نمی‌یابد. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].pd-pool[pid].cumulative-assigned-pds عدد صحیح تعداد تجمعی پیشوندهای PD در یک استخر PD زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش می‌یابد و هرگز کاهش نمی‌یابد. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر PD مربوطه است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].assigned-pds عدد صحیح تعداد پیشوندهای PD در یک زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه شده و در حین پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].pd-pool[pid].assigned-pds عدد صحیح تعداد پیشوندهای PD در یک pd-pool زیرشبکهٔ مشخص که واگذار شده‌اند. این مقدار با هر بار تخصیص اجارهٔ جدید (در نتیجهٔ دریافت پیام REQUEST) افزایش یافته و با هر بار آزادسازی اجاره (دریافت پیام RELEASE) یا انقضای آن کاهش می‌یابد. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر PD است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌شود.
reclaimed-leases عدد صحیح تعداد اجاره‌های منقضی‌شده‌ای که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری یک اجارهٔ منقضی‌شده افزایش می‌یابد (هر دو بازپس‌گیری NA و PD را شامل می‌شود). این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت برای تعداد کل اجاره‌های واقعی بازپس‌گرفته‌شده استفاده کرد. این یک آمارهٔ سراسری است که تمام زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].reclaimed-leases عدد صحیح تعداد اجاره‌های منقضی‌شدهٔ وابسته به یک زیرشبکهٔ مشخص که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری یک اجارهٔ منقضی‌شده افزایش می‌یابد (شامل هر دو بازپس‌گیری NA و PD). شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
subnet[id].pool[pid].reclaimed-leases عدد صحیح تعداد نشانی‌های NA منقضی‌شدهٔ وابسته به یک استخر زیرشبکهٔ مشخص که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری اجارهٔ منقضی‌شده افزایش می‌یابد. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].pd-pool[pid].reclaimed-leases عدد صحیح تعداد پیشوندهای PD منقضی‌شدهٔ وابسته به یک استخر PD زیرشبکهٔ مشخص که از زمان راه‌اندازی کارساز بازپس‌گیری شده‌اند. این آماره با هر بار بازپس‌گیری اجارهٔ منقضی‌شده افزایش می‌یابد. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر PD است. این آماره برای هر استخر PD زیرشبکه جداگانه ارائه شده و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.
declined-addresses عدد صحیح تعداد نشانی‌های IPv6 که هم‌اکنون رد شده‌اند (declined)؛ شمارشی از تعداد اجاره‌هایی که در حال حاضر در دسترس نیستند. به محض بازیابی یک اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این مقدار غیرصفر بوده یا رو به افزایش باشد، مدیر شبکه باید بررسی کند که آیا دستگاه ناهنجاری در شبکه وجود دارد یا خیر. این یک آمارهٔ سراسری است که تمامی زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].declined-addresses عدد صحیح تعداد نشانی‌های IPv6 که در حال حاضر در یک زیرشبکهٔ مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که فعلاً در دسترس نیستند. به محض بازیابی اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این مقدار غیرصفر باشد یا افزایش یابد، مدیر شبکه باید بررسی کند که آیا دستگاه ناهنجاری در شبکه وجود دارد یا خیر. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
subnet[id].pool[pid].declined-addresses عدد صحیح تعداد نشانی‌های IPv6 که هم‌اکنون در یک استخر زیرشبکهٔ مشخص رد شده‌اند؛ شمارشی از تعداد اجاره‌هایی که فعلاً در دسترس نیستند. به محض بازیابی اجاره، این آماره کاهش می‌یابد؛ در حالت ایده‌آل، این آماره باید صفر باشد. اگر این مقدار غیرصفر بوده یا در حال افزایش باشد، مدیر شبکه باید وجود دستگاه ناهنجار در شبکه را بررسی کند. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه به طور جداگانه ارائه می‌شود.
reclaimed-declined-addresses عدد صحیح تعداد نشانی‌های IPv6 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف declined-addresses، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان یک شاخص بلندمدت برای تعداد کل ردشدگی‌های معتبری که پردازش و بازیابی شده‌اند استفاده کرد. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].reclaimed-declined-addresses عدد صحیح تعداد نشانی‌های IPv6 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف declined-addresses، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان شاخصی بلندمدت برای تعداد کل ردشدگی‌های معتبری که پردازش و بازیابی شده‌اند استفاده کرد. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
subnet[id].pool[pid].reclaimed-declined-addresses عدد صحیح تعداد نشانی‌های IPv6 که رد شده بودند، اما اکنون بازیابی شده‌اند. بر خلاف declined-addresses، این آماره هرگز کاهش نمی‌یابد. می‌توان از آن به عنوان شاخصی بلندمدت برای تعداد ردشدگی‌های معتبری که پردازش و بازیابی شده‌اند استفاده کرد. شناسهٔ id شناسهٔ زیرشبکه و pid شناسهٔ استخر است. این آماره برای هر استخر زیرشبکه جداگانه ارائه می‌گردد.
v6-allocation-fail عدد صحیح تعداد کل شکست‌ها در تخصیص نشانی برای یک کلاینت خاص. این شامل تعداد تلاش‌هایی برای تخصیص اجاره است که کارساز پیش از انصراف انجام داده است، در صورتی که قادر به استفاده از هیچ‌یک از استخرهای نشانی نبوده باشد. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v6-allocation-fail عدد صحیح تعداد کل شکست‌ها در تخصیص نشانی برای یک کلاینت خاص. این شامل تعداد تلاش‌های تخصیص اجاره است که کارساز پیش از انصراف انجام داده است، در صورتی که نتوانسته باشد از هیچ‌یک از استخرهای نشانی استفاده کند. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
v6-allocation-fail-shared-network عدد صحیح تعداد شکست‌ها در تخصیص نشانی برای یک کلاینت خاص متصل به یک شبکهٔ اشتراکی (shared network). این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v6-allocation-fail-shared-network عدد صحیح تعداد شکست‌ها در تخصیص نشانی برای یک کلاینت خاص متصل به یک شبکهٔ اشتراکی. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
v6-allocation-fail-subnet عدد صحیح تعداد شکست‌های تخصیص نشانی برای یک کلاینت خاص متصل به زیرشبکه‌ای که به یک شبکهٔ اشتراکی تعلق ندارد. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v6-allocation-fail-subnet عدد صحیح تعداد شکست‌های تخصیص نشانی برای یک کلاینت خاص متصل به زیرشبکه‌ای که به یک شبکهٔ اشتراکی تعلق ندارد. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
v6-allocation-fail-no-pools عدد صحیح تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانسته است از هیچ استخر پیکربندی‌شده‌ای برای یک کلاینت خاص استفاده کند. همچنین این احتمال وجود دارد که تمام زیرشبکه‌هایی که کارساز تلاش کرده از آن‌ها نشانی تخصیص دهد فاقد استخر نشانی باشند. در این وضعیت، چنانچه مدیر سیستم انتظار داشته باشد که به برخی کلاینت‌ها نشانی‌های پویا تخصیص یابد، این مورد باید یک پیکربندی نادرست تلقی شود. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v6-allocation-fail-no-pools عدد صحیح تعداد شکست‌های تخصیص نشانی به این دلیل که کارساز نتوانسته است از هیچ استخر پیکربندی‌شده‌ای برای یک کلاینت خاص استفاده کند. همچنین ممکن است همهٔ زیرشبکه‌هایی که کارساز سعی در تخصیص نشانی از آن‌ها داشته فاقد استخر نشانی باشند. در این صورت، اگر مدیر انتظار تخصیص نشانی پویا به کلاینت‌ها را داشته باشد، این یک پیکربندی نادرست است. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
v6-allocation-fail-classes عدد صحیح تعداد شکست‌های تخصیص نشانی هنگامی که بستهٔ کلاینت به یک یا چند کلاس تعلق دارد. دلایل مختلفی برای عدم تخصیص اجاره وجود دارد: برای نمونه، اگر همهٔ استخرها نیازمند عضویت بسته‌ها در کلاس‌های خاصی باشند و بستهٔ ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگر مفید بودن این اطلاعات، نشان دادن پایان یافتن نشانی‌های استخر رزروشده برای یک کلاس خاص است. این یک آمارهٔ سراسری است که همهٔ زیرشبکه‌ها را پوشش می‌دهد.
subnet[id].v6-allocation-fail-classes عدد صحیح تعداد شکست‌های تخصیص نشانی هنگامی که بستهٔ کلاینت به یک یا چند کلاس تعلق دارد. دلایل مختلفی برای عدم تخصیص اجاره وجود دارد: برای نمونه، اگر همهٔ استخرها نیازمند عضویت بسته‌ها در کلاس‌های خاصی باشند و بستهٔ ورودی به هیچ‌کدام تعلق نداشته باشد. حالت دیگر مفید بودن این اطلاعات، نشان دادن اتمام نشانی‌های استخر رزروشده برای یک کلاس خاص است. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود.
v6-ia-na-lease-reuses عدد صحیح تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_NA در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار دست‌نخورده باقی مانده است. به این فرآیند «استفادهٔ مجدد از اجاره» (lease reuse) گفته می‌شود. این یک آمارهٔ سراسری است.
subnet[id].v6-ia-na-lease-reuses عدد صحیح تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_NA در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار دست‌نخورده باقی مانده است. به این فرآیند استفادهٔ مجدد از اجاره گفته می‌شود. این آماره به ازای هر زیرشبکه است. شناسهٔ id شناسهٔ زیرشبکهٔ مورد نظر است.
v6-ia-pd-lease-reuses عدد صحیح تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_PD در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار بدون تغییر رها شده است. به این فرآیند استفادهٔ مجدد از اجاره گفته می‌شود. این یک آمارهٔ سراسری است.
subnet[id].v6-ia-pd-lease-reuses عدد صحیح تعداد دفعاتی که به عنوان بخشی از قابلیت lease caching، مقدار CLTT یک اجارهٔ IA_PD در حافظه افزایش یافته و زمان انقضای آن در فضای ذخیره‌سازی پایدار بدون تغییر رها شده است. به این فرآیند استفادهٔ مجدد از اجاره گفته می‌شود. این آماره به ازای هر زیرشبکه است. شناسهٔ id شناسهٔ زیرشبکهٔ مورد نظر است.
cumulative-registered عدد صحیح تعداد تجمعی نشانی‌های NA که از زمان راه‌اندازی کارساز به ثبت رسیده‌اند. این آماره با هر بار ثبت یک نشانی NA افزایش یافته و هنگام پیکربندی مجدد کارساز بازنشانی نمی‌شود.
subnet[id].cumulative-registered عدد صحیح تعداد تجمعی نشانی‌های NA در یک زیرشبکهٔ مشخص که به ثبت رسیده‌اند. این مقدار با هر بار ثبت یک نشانی جدید (در نتیجهٔ دریافت پیام ADDR-REG-INFORM) افزایش می‌یابد و هرگز کاهش پیدا نمی‌کند. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.
subnet[id].registered عدد صحیح تعداد نشانی‌های NA در یک زیرشبکهٔ مشخص که به ثبت رسیده‌اند. این مقدار با هر بار ثبت یک نشانی جدید (در نتیجهٔ دریافت پیام ADDR-REG-INFORM) افزایش یافته و با هر بار انقضای یک ثبت کاهش می‌یابد. شناسهٔ id شناسهٔ زیرشبکه است. این آماره برای هر زیرشبکه جداگانه ارائه می‌شود و در حین رویداد پیکربندی مجدد بازنشانی می‌گردد.

بسته‌های ورودی دور ریخته‌شده را می‌توان در pkt6-receive-drop و شمارندهٔ دومی که جزئیات دلیل دور انداختن را شرح می‌دهد، شمارش کرد:

pkt6-service-disabled - سرویس DHCP غیرفعال است
  • pkt6-parse-failed - تجزیه بسته با یک خطای مهلک مواجه شد
  • pkt6-queue-full - بسته‌ای که قرار بود در صفی که پر بود نگهداری شود
  • pkt6-duplicate - نسخه تکراری از بسته‌ای که در حال پردازش است
  • pkt6-rfc-violation - نقض RFC (یعنی مشخصات پروتکل دستور به دور انداختن آنها می‌دهد)
  • pkt6-admin-filtered - توسط مدیر سیستم فیلتر شده است
  • pkt6-not-for-us - باید توسط سرور دیگری مدیریت شود
  • pkt6-processing-failed - هنگام پردازش با خطای غیرمنتظره‌ای مواجه شد
  • pkt6-limit-exceeded - توسط کتابخانه قلاب محدودیت‌ها (libdhcp_limits.so: Limits to Manage Lease Allocation and Packet Processing <#hooks-limits>) دور انداخته شد

نکته:

شناسه استخر (pool ID) را می‌توان با تنظیم صریح پارامتر pool-id در نگاشت پارامترهای استخر، روی هر استخر پیکربندی کرد. در صورت عدم پیکربندی، مقدار پیش‌فرض pool-id برابر 0 خواهد بود. آمارهای مربوط به شناسه استخر 0 به تمام آمارهای همه استخرهایی اشاره دارد که pool-id آنها پیکربندی نشده است. شناسه استخر نیازی نیست که در داخل یک زیرشبکه یا در میان زیرشبکه‌ها یکتا باشد. آمارهای مربوط به یک شناسه استخر مشخص در یک زیرشبکه با سایر آمارهای تمام استخرهای دیگری که همان شناسه استخر را در آن زیرشبکه دارند ادغام می‌شود.

نکته:

این بخش، آمارهای مختص DHCPv6 را شرح می‌دهد. برای بررسی اجمالی و نحوه استفاده از آمارها، Statistics <#stats> را ببینید.

سرور DHCPv6 دو پارامتر سراسری برای کنترل محدودیت‌های نمونه پیش‌فرض آمارها ارائه می‌دهد:

  • statistic-default-sample-count - حداکثر تعداد پیش‌فرض نمونه‌هایی را که باید نگهداری شوند تعیین می‌کند. مقدار ویژه 0 نشان می‌دهد که باید از یک حداکثر سن پیش‌فرض استفاده شود.
  • statistic-default-sample-age - حداکثر سن پیش‌فرض نمونه‌هایی را که باید نگهداری شوند، بر حسب ثانیه، تعیین می‌کند.

برای نمونه، جهت کاهش بار اضافی نگهداری آمار، حداکثر تعداد پیش‌فرض نمونه‌ها را روی 1 تنظیم کنید تا تنها یک نمونه نگهداری شود:

"Dhcp6": {
    "statistic-default-sample-count": 1,
    "subnet6": [
        {
            ...
        },
        ...
    ],
    ...
}

آمارها را می‌توان به‌صورت دوره‌ای بازیابی کرد تا بینش بیشتری درباره عملیات Kea به دست آورد. ابزاری که از این قابلیت بهره می‌برد ISC Stork است. برای جزئیات به Monitoring Kea With Stork <#stork> مراجعه کنید.

رابط مدیریتی (Management API) امکان صدور دستورهای مدیریتی مشخص، نظیر بازیابی آمار، پیکربندی مجدد یا خاموش‌سازی را فراهم می‌کند. برای جزئیات بیشتر، Management API <#ctrl-channel> را ببینید. به‌طور پیش‌فرض هیچ سوکتی باز نیست؛ برای صدور دستور به Kea جهت باز کردن یک سوکت، می‌توان از مدخل زیر در فایل پیکربندی استفاده کرد:

"Dhcp6": {
    "control-sockets": [
        {
            "socket-type": "unix",
            "socket-name": "/path/to/the/unix/socket"
        }
    ],
    "subnet6": [
        {
            ...
        },
        ...
    ],
    ...
}

تا سرور Kea نسخه 2.7.2، تنها نوع کانال ارتباطی پشتیبانی‌شده سوکت جریان UNIX با تنظیم socket-type روی unix و socket-name روی مسیر فایل سوکت UNIX/LOCAL بود.

طول مسیر مشخص‌شده توسط پارامتر socket-name به حداکثر طول مجاز برای نام سوکت UNIX در سیستم‌عامل مدیر سیستم، یعنی اندازه فیلد sun_path در ساختار sockaddr_un منهای 1، محدود است. این مقدار در سیستم‌عامل‌های گوناگون متغیر بوده و بین 91 تا 107 نویسه است. مقادیر معمول، 107 در Linux و 103 در FreeBSD هستند.

برنامه Kea تنها از یک سوکت کنترلی unix در فهرست "control-sockets" پشتیبانی می‌کند.

نکته:

از نسخه Kea 2.7.9 به بعد، سوکت‌های کنترل فقط می‌توانند در دایرکتوری تعیین‌شده در زمان کامپایل یعنی "[kea-install-dir]/var/run/kea" قرار گیرند، که این دایرکتوری نیز باید دارای مجوزهای دسترسی 0750 باشد. این مسیر ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی KEA_CONTROL_SOCKET_DIR به مسیر مورد نظر بازنویسی شود. اگر مسیری غیر از این مقدار در socket-name استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند یا در صورتی که از قبل در حال اجرا باشد، یک خطای غیرقابل‌بازیابی ثبت می‌کند. برای سهولت در استفاده، کافی است بخش مسیر را از socket-name حذف کنید.

ارتباط روی کانال کنترل با استفاده از ساختارهای JSON انجام می‌شود. برای جزئیات بیشتر، بخش Control Channel در Kea Developer's Guide https://reports.kea.isc.org/dev_guide/d2/d96/ctrlSocket.html را ببینید.

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

  • build-report <#std-isccmd-build-report>
  • config-get <#std-isccmd-config-get>
  • config-hash-get <#std-isccmd-config-hash-get>
  • config-reload <#std-isccmd-config-reload>
  • config-set <#std-isccmd-config-set>
  • config-test <#std-isccmd-config-test>
  • config-write <#std-isccmd-config-write>
  • dhcp-disable <#std-isccmd-dhcp-disable>
  • dhcp-enable <#std-isccmd-dhcp-enable>
  • interface-add <#std-isccmd-interface-add>
  • interface-list <#std-isccmd-interface-list>
  • interface-redetect <#std-isccmd-interface-redetect>
  • leases-reclaim <#std-isccmd-leases-reclaim>
  • list-commands <#std-isccmd-list-commands>
  • shutdown <#std-isccmd-shutdown>
  • status-get <#std-isccmd-status-get>
  • version-get <#std-isccmd-version-get>

همان‌طور که در Commands Supported by Both the DHCPv4 and DHCPv6 Servers <#commands-common> شرح داده شده است. علاوه بر این، از دستورهای مرتبط با آمار زیر پشتیبانی می‌کند:

  • statistic-get <#std-isccmd-statistic-get>
  • statistic-reset <#std-isccmd-statistic-reset>
  • statistic-remove <#std-isccmd-statistic-remove>
  • statistic-get <#std-isccmd-statistic-get>-all
  • statistic-reset <#std-isccmd-statistic-reset>-all
  • statistic-remove <#std-isccmd-statistic-remove>-all
  • statistic-sample-age-set <#std-isccmd-statistic-sample-age-set>
  • statistic-sample-age-set <#std-isccmd-statistic-sample-age-set>-all
  • statistic-sample-count-set <#std-isccmd-statistic-sample-count-set>
  • statistic-sample-count-set <#std-isccmd-statistic-sample-count-set>-all

همان‌طور که در Commands for Manipulating Statistics <#command-stats> شرح داده شده است..SS سوکت کنترلی HTTP/HTTPS

مقدار socket-type باید http یا https باشد (زمانی که نوع https باشد، TLS الزامی است). پارامترهای socket-address (پیش‌فرض ::1) و socket-port (پیش‌فرض 8000) آدرس IP و درگاهی را مشخص می‌کنند که سرویس HTTP به آن مقید (bind) خواهد شد.

از نسخه Kea 2.7.5، پارامتر http-headers فهرستی از سرفصل‌های HTTP اضافی را برای افزودن به پاسخ‌های HTTP مشخص می‌کند.

پارامترهای trust-anchor، cert-file، key-file و cert-required پیکربندی TLS را برای HTTP، یعنی HTTPS، مشخص می‌کنند. اگر این پارامترها مشخص نشوند، HTTP استفاده می‌شود. پشتیبانی از TLS/HTTPS در Kea در بخش TLS/HTTPS Support <#tls> شرح داده شده است.

احراز هویت پایه HTTP (Basic authentication) از سرور در برابر استفاده‌های غیرمجاز توسط کاربران محلی محافظت می‌کند. برای محافظت در برابر مهاجمان از راه دور، HTTPS و پراکسی معکوس (reverse proxy) امنیت قوی‌تری فراهم می‌کنند.

احراز هویت در بلوک authentication با پارامتر اجباری type که نوع احراز هویت را انتخاب می‌کند، شرح داده می‌شود. در حال حاضر تنها احراز هویت پایه HTTP (نوع basic) پشتیبانی می‌شود.

پارامتر احراز هویت realm (پیش‌فرض kea-dhcpv6-server) برای پیام‌های خطا در هنگامی استفاده می‌شود که احراز هویت پایه HTTP الزامی است اما کلاینت مجاز شناخته نشده است.

هنگامی که فهرست احراز هویت clients پیکربندی شده و خالی نباشد، احراز هویت پایه HTTP الزامی است. هر عنصر از فهرست، یک شناسه کاربری و یک گذرواژه را مشخص می‌کند. شناسه کاربری الزامی است، نباید خالی باشد و نباید شامل نویسه دونقطه (:) باشد. گذرواژه اختیاری است؛ در صورت عدم تعیین آن، از یک گذرواژه خالی استفاده می‌شود.

نکته:

شناسه کاربری و گذرواژه در احراز هویت پایه HTTP با کدگذاری UTF-8 ذخیره می‌شوند، اما نحو JSON فعلی Kea تنها از زیرمجموعه یونی‌کد Latin-1 (یعنی 0x00..0xff) پشتیبانی می‌کند.

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

  • پارامتر احراز هویت directory، که بخش مشترک مسیر فایل‌ها را مدیریت می‌کند. مقدار پیش‌فرض، رشته خالی است.
  • پارامتر کلاینت password-file، که همراه با پارامتر directory، مسیر فایلی را مشخص می‌کند که می‌تواند حاوی گذرواژه باشد، یا اگر هیچ شناسه کاربری ارائه نشده باشد، کل راز احراز هویت پایه HTTP را در بر گیرد.
  • پارامتر کلاینت user-file، که به همراه پارامتر directory، مسیر فایلی را مشخص می‌کند که شناسه کاربری را می‌توان از آن خواند.

از نسخه Kea-2.7.6، برنامه Kea از چندین اتصال HTTP/HTTPS پشتیبانی می‌کند. هم از آدرس‌های IPv4 و هم IPv6 می‌توان استفاده کرد. در صورت تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از همان آدرس و درگاه، سرور خطا صادر خواهد کرد. این عمل مجاز نیست، زیرا ممکن است به دلیل اشتباه سهوی کاربر، یک رخنه امنیتی ایجاد کند. هنگام استفاده از دستور "config-set" برای جابه‌جایی از HTTP به HTTPS یا از HTTPS به HTTP، باید آدرس یا درگاه متفاوتی مشخص شود. همین امر هنگام تغییر فایل پیکربندی و سپس اجرای دستور "config-reload" نیز صدق می‌کند.

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

"Dhcp6": {
    "control-sockets": [
        {
            "socket-type": "https",
            "socket-address": "2010:30:40::50",
            "socket-port": 8005,
            "http-headers": [
                {
                    "name": "Strict-Transport-Security",
                    "value": "max-age=31536000"
                 }
            ],
            "trust-anchor": "/path/to/the/ca-cert.pem",
            "cert-file": "/path/to/the/agent-cert.pem",
            "key-file": "/path/to/the/agent-key.pem",
            "cert-required": true,
            "authentication": {
               "type": "basic",
               "realm": "kea-dhcpv6-server",
               "clients": [
                   {
                       "user": "admin",
                       "password": "1234"
                   } ]
            }
        },
        {
            "socket-type": "http",
            "socket-address": "10.20.30.40",
            "socket-port": 8005
        }
    ],
    "subnet6": [
        {
            ...
        },
        ...
    ],
    ...
}

برنامه Kea امکان بارگذاری کتابخانه‌های قلاب (hook libraries) را فراهم می‌کند که گاهی می‌توانند از پارامترهای اضافی بهره‌مند شوند. اگر چنین پارامتری مختص کل کتابخانه باشد، معمولاً به عنوان پارامتری برای کتابخانه قلاب تعریف می‌شود. با این حال، گاهی اوقات نیاز است پارامترهایی مشخص شوند که برای هر استخر (pool) متفاوت باشند.

برای پیش‌زمینه بیشتر در رابطه با ایده user-context، به بخش Comments and User Context <#user-context> مراجعه کنید. برای بررسی موضوع از دیدگاه قلاب‌ها، به User Contexts in Hooks <#user-context-hooks> مراجعه کنید.

زمینه‌های کاربر (user contexts) را می‌توان در دامنه سراسری (global scope)؛ در سطح shared-network، subnet، pool، client-class، option-data یا definition؛ و از طریق رزرو میزبان (host reservation) مشخص کرد. یکی دیگر از ویژگی‌های کاربردی، امکان ذخیره یادداشت‌ها یا توضیحات است.

بیایید استقرار نمونه‌ای از lightweight 4over6 را در نظر بگیریم؛ فناوری گذار به IPv6 که امکان نگاشت پیشوندهای IPv6 به آدرس‌های IPv4 کامل یا جزئی را فراهم می‌کند. در زمینه DHCP، این‌ها پارامترهای خاصی هستند که قرار است در قالب گزینه‌های اضافی به کلاینت‌ها تحویل داده شوند. مقادیر این گزینه‌ها با پیشوندهای تفویض‌شده (delegated prefixes) همبستگی دارند، بنابراین منطقی است که این پارامترها به همراه استخر تفویض پیشوند (PD pool) نگهداری شوند. از سوی دیگر، lightweight 4over6 قابلیتی نیست که به طور متداول استفاده شود، بنابراین بخشی از کد پایه Kea محسوب نمی‌شود. راه‌حل این مسئله، تعیین یک زمینه کاربر است. برای هر استخر PD که انتظار می‌رود برای lightweight 4over6 استفاده شود، یک زمینه کاربر با پارامترهای اضافی تعریف می‌شود. آن پارامترهای اضافی توسط یک کتابخانه قلاب استفاده شده و تنها در صورتی بارگذاری می‌شوند که محاسبه پویای گزینه lightweight 4over6 واقعاً مورد نیاز باشد. نمونه‌ای از این پیکربندی به صورت زیر است:

"Dhcp6": {
    "subnet6": [ {
        "pd-pools": [
        {
            "prefix": "2001:db8::",
            "prefix-len": 56,
            "delegated-len": 64,
            # This is a pool-specific context.
            "user-context": {
                "threshold-percent": 85,
                "v4-network": "192.168.0.0/16",
                "v4-overflow": "10.0.0.0/16",
                "lw4over6-sharing-ratio": 64,
                "lw4over6-v4-pool": "192.0.2.0/24",
                "lw4over6-sysports-exclude": true,
                "lw4over6-bind-prefix-len": 56
            }
        } ],
        "id": 1,
        "subnet": "2001:db8::/32",
        # This is a subnet-specific context. Any type of
        # information can be entered here as long as it is valid JSON.
        "user-context": {
            "comment": "Those v4-v6 migration technologies are tricky.",
            "experimental": true,
            "billing-department": 42,
            "contacts": [ "Alice", "Bob" ]
        }
    } ]
}

برنامه Kea اطلاعات user-context را تفسیر یا استفاده نمی‌کند؛ این برنامه صرفاً آن را ذخیره کرده و در دسترس کتابخانه‌های قلاب قرار می‌دهد. استخراج و استفاده از این اطلاعات به عهده هر کتابخانه قلاب است. تجزیه‌کننده (parser)، ورودی comment را به یک زمینه کاربر به همراه آن ورودی تبدیل می‌کند، که این امر امکان پیوست کردن یادداشت درون خود پیکربندی را فراهم می‌سازد..SS "استانداردهای پشتیبانی‌شده DHCPv6"

استانداردهای زیر در حال حاضر در Kea پشتیبانی می‌شوند:

  • Dynamic Host Configuration Protocol for IPv6, RFC 3315 https://datatracker.ietf.org/doc/html/rfc3315: پیام‌های پشتیبانی‌شده عبارتند از SOLICIT، ADVERTISE، REQUEST، RELEASE، RENEW، REBIND، INFORMATION-REQUEST، CONFIRM، DECLINE و REPLY. تنها پیام پشتیبانی‌نشده RECONFIGURE است. تقریباً تمامی گزینه‌ها پشتیبانی می‌شوند، به جز AUTHENTICATION و RECONFIGURE-ACCEPT.
  • Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers, RFC 3319 https://datatracker.ietf.org/doc/html/rfc3319: تمامی گزینه‌های تعریف‌شده پشتیبانی می‌شوند.
  • IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6, RFC 3633 https://datatracker.ietf.org/doc/html/rfc3633: گزینه‌های پشتیبانی‌شده IA_PD و IA_PREFIX هستند. همچنین کد وضعیت NoPrefixAvail نیز پشتیبانی می‌شود.
  • DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 3646 https://datatracker.ietf.org/doc/html/rfc3646: تمامی گزینه‌های تعریف‌شده پشتیبانی می‌شوند.
  • Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6, RFC 3736 https://datatracker.ietf.org/doc/html/rfc3736: عملکرد سرور در حالت بدون حالت (stateless) پشتیبانی می‌شود. Kea در حال حاضر تنها در سمت سرور (server-only) است، بنابراین سمت کلاینت پیاده‌سازی نشده است.
  • Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6, RFC 4075 https://datatracker.ietf.org/doc/html/rfc4075: گزینه SNTP پشتیبانی می‌شود.
  • Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 4076 https://datatracker.ietf.org/doc/html/rfc4076: سرور از تمامی نیازمندی‌های شماره‌گذاری مجدد در حالت بدون حالت پشتیبانی می‌کند.
  • Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 4242 https://datatracker.ietf.org/doc/html/rfc4242: تنها گزینه تعریف‌شده (information-refresh-time) پشتیبانی می‌شود.
  • Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers, RFC 4280 https://datatracker.ietf.org/doc/html/rfc4280: گزینه‌های DHCPv6 پشتیبانی می‌شوند.
  • Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option, RFC 4580 https://datatracker.ietf.org/doc/html/rfc4580: گزینه subscribed-id پشتیبانی می‌شود و می‌تواند در هر عبارتی استفاده شود.
  • The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option, RFC 4649 https://datatracker.ietf.org/doc/html/rfc4649: گزینه Remote-ID پشتیبانی می‌شود.
  • A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR), RFC 4701 https://datatracker.ietf.org/doc/html/rfc4701: سرور DHCPv6 از رکوردهای DHCID پشتیبانی می‌کند. سرور DHCP-DDNS برای افزودن، به‌روزرسانی و/یا حذف رکوردهای DHCID باید در حال اجرا باشد.
  • Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients, RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703: سرور DHCPv6 برای حل تداخل‌ها از سرور DHCP-DDNS استفاده می‌کند.
  • The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option, RFC 4704 https://datatracker.ietf.org/doc/html/rfc4704: گزینه پشتیبانی‌شده CLIENT_FQDN است.
  • Timezone Options for DHCP: RFC 4833 https://datatracker.ietf.org/doc/html/rfc4833: هر دو گزینه DHCPv6 پشتیبانی می‌شوند.
  • DHCPv6 Leasequery: RFC 5007 https://datatracker.ietf.org/doc/html/rfc5007: قابلیت‌های سرور (انواع پیام‌ها، گزینه‌ها) پشتیبانی می‌شود. این ویژگی نیازمند قلاب leasequery است. برای جزئیات به libdhcp_lease_query.so: Leasequery Support <#hooks-lease-query> مراجعه کنید.
  • DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents: RFC 5192 https://datatracker.ietf.org/doc/html/rfc5192: گزینه PANA پشتیبانی می‌شود.
  • Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP): RFC 5223 https://datatracker.ietf.org/doc/html/rfc5223: گزینه LOST پشتیبانی می‌شود.
  • Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option: RFC 5417 https://datatracker.ietf.org/doc/html/rfc5417: گزینه CAPWAP for IPv6 پشتیبانی می‌شود.
  • DHCPv6 Bulk Leasequery: RFC 5460 https://datatracker.ietf.org/doc/html/rfc5460: قابلیت‌های سرور (اتصال TCP، انواع پیام‌ها و گزینه‌های جدید، انواع پرس‌وجوهای جدید) پشتیبانی می‌شود. این ویژگی نیازمند قلاب leasequery است. برای جزئیات به libdhcp_lease_query.so: Leasequery Support <#hooks-lease-query> مراجعه کنید.
  • Network Time Protocol (NTP) Server Option for DHCPv6: RFC 5908 https://datatracker.ietf.org/doc/html/rfc5908: گزینه سرور NTP و زیرگزینه‌های آن پشتیبانی می‌شوند. برای جزئیات به NTP Server Suboptions مراجعه کنید.
  • DHCPv6 Options for Network Boot: RFC 5970 https://datatracker.ietf.org/doc/html/rfc5970: گزینه‌های بوت شبکه پشتیبانی می‌شوند.
  • Lightweight DHCPv6 Relay Agent, RFC 6221 https://datatracker.ietf.org/doc/html/rfc6221: برنامه Kea می‌تواند پیام‌های رله سبک‌وزن را مدیریت کند و از روش‌هایی به غیر از آدرس پیوند برای انتخاب زیرشبکه استفاده نماید.
  • Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite, RFC 6334 https://datatracker.ietf.org/doc/html/rfc6334: گزینه DHCPv6 با عنوان AFTR-Name پشتیبانی می‌شود.
  • Relay-Supplied DHCP Options, RFC 6422 https://datatracker.ietf.org/doc/html/rfc6422: قابلیت کامل پشتیبانی می‌شود، از جمله OPTION_RSOO؛ توانایی سرور برای بازتاب دادن گزینه‌ها؛ بررسی فعال بودن RSOO برای یک گزینه؛ و امکان علامت‌گذاری گزینه‌های اضافی به عنوان فعال‌شده با RSOO.
  • The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option, RFC 6440 https://datatracker.ietf.org/doc/html/rfc6440: این گزینه پشتیبانی می‌شود.
  • Prefix Exclude Option for DHCPv6-based Prefix Delegation, RFC 6603 https://datatracker.ietf.org/doc/html/rfc6603: گزینه Prefix Exclude پشتیبانی می‌شود.
  • Client Link-Layer Address Option in DHCPv6, RFC 6939 https://datatracker.ietf.org/doc/html/rfc6939: گزینه پشتیبانی‌شده گزینه client link-layer address است.
  • Modification to Default values of SOL_MAX_RT and INF_MAX_RT, RFC 7083 https://datatracker.ietf.org/doc/html/rfc7083: گزینه‌های جدید پشتیبانی می‌شوند.
  • Issues and Recommendations with Multiple Stateful DHCPv6 Options, RFC 7550 https://datatracker.ietf.org/doc/html/rfc7550: تمامی توصیه‌های مربوط به عملکرد سرور DHCPv6 پشتیبانی می‌شوند.
  • DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients, RFC 7598 https://datatracker.ietf.org/doc/html/rfc7598: تمامی گزینه‌های مشخص‌شده در این سند، توسط سرور DHCPv6 پشتیبانی می‌شوند.
  • Generalized UDP Source Port for DHCP Relay, RFC 8357 https://datatracker.ietf.org/doc/html/rfc8357: سرور Kea قادر است گزینه Relay Source Port را در پیام دریافتی Relay-forward مدیریت کند، درگاه UDP را به خاطر بسپارد، و پاسخ Relay-reply را همراه با رونوشتی از این گزینه و با استفاده از همین درگاه UDP به عامل رله بازپس بفرستد.
  • Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915: این مشخصه جدید پروتکل DHCPv6، استانداردهای RFC 3315، RFC 3633، RFC 3736، RFC 4242، RFC 7083، RFC 7283، RFC 7550 و RFC 8415 را منسوخ می‌کند. تمامی ویژگی‌ها، به استثنای سازوکار RECONFIGURE و سازوکار اکنون منسوخ‌شده آدرس‌های موقت (IA_TA)، پشتیبانی می‌شوند.
  • Captive-Portal Identification in DHCP and Router Advertisements (RAs), RFC 8910 https://datatracker.ietf.org/doc/html/rfc8910: سرور Kea می‌تواند هر دو نگارش v4 و v6 گزینه‌های captive portal را پیکربندی کند.
  • DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR), RFC 9463 https://datatracker.ietf.org/doc/html/rfc9463. سرور Kea از گزینه DNR پشتیبانی می‌کند.
  • Registering Self-Generated IPv6 Addresses Using DHCPv6, RFC 9686 https://datatracker.ietf.org/doc/html/rfc9686. سرور Kea از ثبت آدرس‌های خودساخته پشتیبانی می‌کند. برای جزئیات به Address Registration (RFC 9686 Support) مراجعه کنید.

    این موارد محدودیت‌های شناخته‌شدهٔ کنونی نرم‌افزار سرور Kea DHCPv6 هستند. بیشتر آن‌ها بازتابی از مرحلهٔ کنونی توسعه هستند و به جای محدودیت‌های واقعی، باید به عنوان «هنوز پیاده‌سازی‌نشده» در نظر گرفته شوند.

  • سرور برای هر گزینهٔ IA خاص (IA_NA یا IA_PD) ارسال‌شده توسط کلاینت، حداکثر یک اجاره (lease) را تخصیص داده، تمدید کرده یا بازنشانی (rebind) می‌کند. سند RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 اجازه می‌دهد چندین نشانی یا پیشوند برای یک IA واحد تخصیص یابد.
  • نشانی‌های موقت پشتیبانی نمی‌شوند. هیچ برنامه‌ای برای پیاده‌سازی این ویژگی وجود ندارد، زیرا در RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 منسوخ شده است.
  • پیکربندی مجدد کلاینت (RECONFIGURE) هنوز پشتیبانی نمی‌شود.

مجموعه‌ای از مثال‌های ساده و کاربردی برای مؤلفهٔ DHCPv6 از Kea به همراه فایل‌های منبع، در دایرکتوری doc/examples/kea6 در دسترس است.

در بخش Kea Configuration Backend <#config-backend> ویژگی بک‌اند پیکربندی (CB)، کاربرد آن و محدودیت‌هایش را توضیح داده‌ایم. این بخش بر استفاده از CB با سرور DHCPv6 تمرکز دارد. این قسمت پارامترهای پشتیبانی‌شده را فهرست می‌کند، محدودیت‌ها را توضیح می‌دهد و برای بهره‌گیری از CB، مثال‌هایی از پیکربندی سرور DHCPv6 ارائه می‌دهد. لطفاً برای استفادهٔ مخصوص DHCPv4 از CB، به بخش متناظر Configuration Backend in DHCPv4 <#dhcp4-cb> نیز مراجعه کنید.

هدف نهایی CB این است که به عنوان یک مخزن مرکزی پیکربندی برای یک یا چند سرور Kea متصل به یک پایگاه‌داده عمل کند. در نسخه‌های کنونی پشتیبانی‌شدهٔ Kea، تنها زیرمجموعه‌ای از پارامترهای سرور DHCPv6 را می‌توان در پایگاه‌داده پیکربندی کرد. سایر پارامترها در صورت نیاز باید در فایل پیکربندی JSON مشخص شوند.

تمام پارامترهای پشتیبانی‌شده را می‌توان از طریق libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> پیکربندی کرد. قاعدهٔ کلی این است که پارامترهای سراسری اسکالر با استفاده از remote-global-parameter6-set <#std-isccmd-remote-global-parameter6-set> تنظیم می‌شوند؛ پارامترهای ویژهٔ شبکهٔ مشترک با استفاده از remote-network6-set <#std-isccmd-remote-network6-set> تنظیم می‌شوند؛ و پارامترهای سطح زیرشبکه و استخر با استفاده از remote-subnet6-set <#std-isccmd-remote-subnet6-set> تنظیم می‌گردند. هرگاه استثنایی برای این قاعدهٔ کلی وجود داشته باشد، در جدول مشخص شده است. پارامترهای سراسری غیراسکالر دستورهای اختصاصی خود را دارند؛ برای مثال، گزینه‌های سراسری DHCPv6 (option-data) با استفاده از remote-option6-global-set <#std-isccmd-remote-option6-global-set> تغییر داده می‌شوند. کلاس‌های کلاینت به همراه تعاریف گزینه‌ها و گزینه‌های DHCPv6 ویژهٔ کلاس، با استفاده از دستور remote-class6-set <#std-isccmd-remote-class6-set> پیکربندی می‌شوند.

بخش Configuration Sharing and Server Tags <#cb-sharing> مفهوم عناصر پیکربندی اشتراک‌پذیر و غیراشتراک‌پذیر و محدودیت‌های به‌اشتراک‌گذاری آن‌ها میان چندین سرور را توضیح می‌دهد. در پیکربندی DHCP (هم DHCPv4 و هم DHCPv6)، عناصر پیکربندی اشتراک‌پذیر زیرشبکه‌ها و شبکه‌های مشترک هستند. بنابراین، می‌توان آن‌ها را به‌طور صریح با چندین برچسب سرور مرتبط ساخت. پارامترهای سراسری، تعاریف گزینه‌ها و گزینه‌های سراسری غیراشتراک‌پذیر هستند و تنها می‌توانند با یک برچسب سرور مرتبط شوند. این قاعده برای عناصر پیکربندی مرتبط با سرورهای all صدق نمی‌کند. هر عنصر پیکربندی مرتبط با سرورهای all (با استفاده از کلمهٔ کلیدی all به عنوان برچسب سرور) توسط تمام سرورهای متصل به پایگاه‌دادهٔ پیکربندی مورد استفاده قرار می‌گیرد.

جدول زیر پارامترهای ویژهٔ DHCPv6 پشتیبانی‌شده توسط بک‌اند پیکربندی را به همراه سطحی از سلسله‌مراتب که در آن پشتیبانی می‌شود، فهرست می‌کند.

پارامتر سراسری کلاس کلاینت شبکهٔ مشترک زیرشبکه استخر استخر واگذاری پیشوند
allocator بله نامربوط بله بله نامربوط نامربوط
cache-max-age بله نامربوط خیر خیر نامربوط نامربوط
cache-threshold بله نامربوط خیر خیر نامربوط نامربوط
calculate-tee-times بله نامربوط بله بله نامربوط نامربوط
client-class نامربوط نامربوط بله بله بله بله
ddns-send-update بله نامربوط بله بله نامربوط نامربوط
ddns-override-no-update بله نامربوط بله بله نامربوط نامربوط
ddns-override-client-update بله نامربوط بله بله نامربوط نامربوط
ddns-replace-client-name بله نامربوط بله بله نامربوط نامربوط
ddns-generated-prefix بله نامربوط بله بله نامربوط نامربوط
ddns-qualifying-suffix بله نامربوط بله بله نامربوط نامربوط
decline-probation-period بله نامربوط نامربوط نامربوط نامربوط نامربوط
delegated-len نامربوط نامربوط نامربوط نامربوط نامربوط بله
dhcp4o6-port بله نامربوط نامربوط نامربوط نامربوط نامربوط
excluded-prefix نامربوط نامربوط نامربوط نامربوط نامربوط بله
excluded-prefix-len نامربوط نامربوط نامربوط نامربوط نامربوط بله
hostname-char-set بله نامربوط بله بله نامربوط نامربوط
hostname-char-replacement بله نامربوط بله بله نامربوط نامربوط
interface نامربوط نامربوط بله بله نامربوط نامربوط
interface-id نامربوط نامربوط بله بله نامربوط نامربوط
max-preferred-lifetime بله بله بله بله نامربوط نامربوط
max-valid-lifetime بله بله بله بله نامربوط نامربوط
min-preferred-lifetime بله بله بله بله نامربوط نامربوط
min-valid-lifetime بله بله بله بله نامربوط نامربوط
option-data بله (از طریق remote-option6-global-set) بله بله بله بله بله
option-def بله (از طریق remote-option-def6-set) بله نامربوط نامربوط نامربوط نامربوط
pd-allocator بله نامربوط بله بله نامربوط نامربوط
preferred-lifetime بله بله بله بله نامربوط نامربوط
prefix نامربوط نامربوط نامربوط نامربوط نامربوط بله
prefix-len نامربوط نامربوط نامربوط نامربوط نامربوط بله
rapid-commit بله نامربوط بله بله نامربوط نامربوط
rebind-timer بله نامربوط بله بله نامربوط نامربوط
relay نامربوط نامربوط بله بله نامربوط نامربوط
renew-timer بله نامربوط بله بله نامربوط نامربوط
require-client-classes خیر نامربوط بله بله بله بله
evaluate-additional-classes خیر نامربوط بله بله بله بله
reservations-global بله نامربوط بله بله نامربوط نامربوط
reservations-in-subnet بله نامربوط بله بله نامربوط نامربوط
reservations-out-of-pool بله نامربوط بله بله نامربوط نامربوط
t1-percent بله نامربوط بله بله نامربوط نامربوط
t2-percent بله نامربوط بله بله نامربوط نامربوط
valid-lifetime بله بله بله بله نامربوط نامربوط
yes - نشان می‌دهد که پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود و از طریق backend پیکربندی قابل تنظیم است.
  • no - نشان می‌دهد که پارامتر در سطح مشخص‌شده از سلسله‌مراتب پشتیبانی می‌شود اما از طریق backend پیکربندی قابل تنظیم نیست.
  • n/a - نشان می‌دهد که پارامتر داده‌شده در سطح خاصی از سلسله‌مراتب کاربرد ندارد یا سرور از پارامتر در آن سطح پشتیبانی نمی‌کند.

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

نام پارامتر (قالب نام‌گذاری مسطح) نگاشت سراسری نام پارامتر
compatibility.lenient-option-parsing compatibility lenient-option-parsing
dhcp-ddns.enable-updates dhcp-ddns enable-updates
dhcp-ddns.max-queue-size dhcp-ddns max-queue-size
dhcp-ddns.ncr-format dhcp-ddns ncr-format
dhcp-ddns.ncr-protocol dhcp-ddns ncr-protocol
dhcp-ddns.sender-ip dhcp-ddns sender-ip
dhcp-ddns.sender-port dhcp-ddns sender-port
dhcp-ddns.server-ip dhcp-ddns server-ip
dhcp-ddns.server-port dhcp-ddns server-port
expired-leases-processing.flush-reclaimed-timer-wait-time expired-leases-processing flush-reclaimed-timer-wait-time
expired-leases-processing.hold-reclaimed-time expired-leases-processing hold-reclaimed-time
expired-leases-processing.max-reclaim-leases expired-leases-processing max-reclaim-leases
expired-leases-processing.max-reclaim-time expired-leases-processing max-reclaim-time
expired-leases-processing.reclaim-timer-wait-time expired-leases-processing reclaim-timer-wait-time
expired-leases-processing.unwarned-reclaim-cycles expired-leases-processing unwarned-reclaim-cycles
multi-threading.enable-multi-threading multi-threading enable-multi-threading
multi-threading.thread-pool-size multi-threading thread-pool-size
multi-threading.packet-queue-size multi-threading packet-queue-size
sanity-checks.lease-checks sanity-checks lease-checks
sanity-checks.extended-info-checks sanity-checks extended-info-checks
server-id.type server-id type
server-id.enterprise-id server-id enterprise-id
server-id.identifier server-id identifier
server-id.persist server-id persist
dhcp-queue-control.enable-queue dhcp-queue-control enable-queue
dhcp-queue-control.queue-type dhcp-queue-control queue-type
dhcp-queue-control.capacity dhcp-queue-control capacity

برخی از پارامترهای فهرست سراسری که تنها حاوی انواع اسکالر هستند، توسط backend پیکربندی پشتیبانی می‌شوند..SS فهرست پارامترهای فهرستی DHCPv6 پشتیبانی‌شده توسط پس‌بند پیکربندی

نام پارامتر | نوع پارامتر نگه‌دارنده فهرست
host-reservation-identifiers | string

قطعه‌پیکربندی زیر را در نظر بگیرید که از یک پایگاه‌داده پیکربندی MySQL استفاده می‌کند:

{
    "Dhcp6": {
        "server-tag": "my DHCPv6 server",
        "config-control": {
            "config-databases": [
                {
                    "type": "mysql",
                    "name": "kea",
                    "user": "kea",
                    "password": "1234",
                    "host": "2001:db8:1::1",
                    "port": 3302
                }
            ],
            "config-fetch-wait-time": 20
        },
        "hooks-libraries": [
            {
                "library": "libdhcp_mysql.so"
            },
            {
                "library": "libdhcp_cb_cmds.so"
            }
        ]
    }
}

قطعه‌کد زیر استفاده از یک پایگاه‌داده PostgreSQL را نشان می‌دهد:

{
    "Dhcp6": {
        "server-tag": "my DHCPv6 server",
        "config-control": {
            "config-databases": [
                {
                    "type": "postgresql",
                    "name": "kea",
                    "user": "kea",
                    "password": "1234",
                    "host": "2001:db8:1::1",
                    "port": 3302
                }
            ],
            "config-fetch-wait-time": 20
        },
        "hooks-libraries": [
            {
                "library": "libdhcp_pgsql.so"
            },
            {
                "library": "libdhcp_cb_cmds.so"
            }
        ]
    }
}

ساختار پیکربندی تقریباً مشابه با کارساز DHCPv4 است (برای توضیحات دقیق، فعال‌سازی پس‌بند پیکربندی <#dhcp4-cb-json> را ببینید).

هدف ISC این است که Kea از اسناد RFC پیروی کند تا سازگاری بهتری با استانداردها ارتقا یابد. با این حال، پیاده‌سازی‌های معیوب بسیاری از DHCP وجود دارند که نمی‌توان به آسانی آن‌ها را اصلاح یا ارتقا داد. بنابراین، Kea یک حالت سازگاری با استفاده آسان برای کلاینت‌های معیوب یا ناسازگار فراهم می‌کند. به همین منظور، باید گزینه سازگاری فعال شود تا رفتارهای نامتعارف مجاز گردند:

{
  "Dhcp6": {
    "compatibility": {
    }
  }
}

به‌طور پیش‌فرض، فیلد vendor-class-data در گزینه ۱۶ DHCPv6 به‌صورت مجموعه‌ای از جفت‌های طول-مقدار تجزیه می‌شود؛ همین امر برای فیلدهای چندتایی (tuple) تعریف‌شده در گزینه‌های سفارشی نیز صادق است.

با "lenient-option-parsing": true، اگر یک طول از باقی‌مانده بافر گزینه فراتر رود، نسخه‌های پیشین Kea پیام گزارشی با مضمون unable to parse the opaque data tuple, the buffer length is x, but the tuple length is y با x < y بازمی‌گرداندند؛ این وضعیت دیگر رخ نمی‌دهد. در عوض، مقدار برابر با باقی‌مانده بافر در نظر گرفته می‌شود، یا به بیان پیام گزارش بالا، طول تاپل y به x تبدیل می‌شود.

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

{
  "Dhcp6": {
    "compatibility": {
      "lenient-option-parsing": true
    }
  }
}

از نسخه 2.5.8 به بعد Kea، این شیوه تجزیه گسترش یافته است تا گزینه‌های client-fqdn (39) با برخی نام‌های دامنه نامعتبر را بدون هشدار نادیده بگیرد؛ همچنین از نسخه 3.1.9 به بعد Kea، پرچم‌های نامعتبر را اصلاح می‌کند، بدین معنا که وقتی پرچم‌های 'S' و 'N' روی 1 تنظیم شده باشند، پرچم 'N' جهت سازگاری با رفتار ISC DHCP به 0 بازنشانی می‌شود..SS راهبردهای تخصیص در DHCPv6

یک سرور DHCP از الگوریتم پیچیده‌ای برای انتخاب اجارهٔ (lease) DHCPv6 برای کلاینت پیروی می‌کند. این سرور واگذاری آدرس‌های خاص یا پیشوندهای تفویض‌شدهٔ درخواست‌شده توسط کلاینت و مواردی را که کلاینت برای آن‌ها رزرو دارد، در اولویت قرار می‌دهد.

هنگامی که کلاینت یک پیشوند تفویض‌شدهٔ مشخص را درخواست می‌کند، kea-dhcp6 <#std-iscman-kea-dhcp6> مجموعه‌ای از مراحل را برای برآورده کردن درخواست، به این ترتیب دنبال می‌کند:

1.
به‌دنبال اجاره‌ای می‌گردد که با پیشوند و طول پیشوند درخواست‌شده مطابقت داشته باشد.
2.
به‌دنبال اجاره‌ای می‌گردد که با طول پیشوند مطابقت داشته باشد.
3.
به‌دنبال اجاره‌ای با فضای آدرس بزرگ‌تر (طول پیشوند کوچک‌تر) می‌گردد.
4.
به‌دنبال اجاره‌ای با فضای آدرس کوچک‌تر (طول پیشوند بزرگ‌تر) می‌گردد.

اگر کلاینت هیچ اجارهٔ خاصی را درخواست نکند و هیچ رزروی نداشته باشد، یا کلاینت‌های دیگر در حال حاضر از اجاره‌های درخواستی استفاده کنند، سرور باید اجارهٔ دردسترس دیگری را در استخرهای (pools) پیکربندی‌شده پیدا کند. تابعی در سرور موسوم به "allocator" (تخصیص‌دهنده) در Kea مسئول یافتن اجارهٔ دردسترس در چنین شرایطی است.

سرور Kea DHCPv6 پارامترهای پیکربندی مختلفی را برای انتخاب تخصیص‌دهنده‌های گوناگون در سطوح سراسری (global)، شبکهٔ مشترک (shared-network) و زیرشبکه (subnet) فراهم می‌کند. همچنین امکان انتخاب راهبردهای تخصیص متفاوت را برای واگذاری آدرس‌ها و تفویض پیشوند (prefix delegation) مهیا می‌سازد.

مثال زیر را در نظر بگیرید:

{
    "Dhcp6": {
        "allocator": "iterative",
        "pd-allocator": "random",
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8:1::/64",
                "allocator": "random"
            },
            {
                "id": 2,
                "subnet": "2001:db8:2::/64",
                "pd-allocator": "iterative"
            }
        ]
    }
}

تخصیص‌دهندهٔ iterative به‌صورت سراسری برای واگذاری آدرس‌ها انتخاب شده است، در حالی که تخصیص‌دهندهٔ random به‌صورت سراسری برای تفویض پیشوند تعیین شده است. این تنظیمات به‌صورت انتخابی در سطح زیرشبکه بازنویسی (override) می‌شوند.

بخش‌های زیر تخصیص‌دهنده‌های پشتیبانی‌شده و کاربردهای توصیه‌شدهٔ آن‌ها را شرح می‌دهند.

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

تخصیص‌دهنده کارایی در بهره‌برداری کم کارایی در بهره‌برداری زیاد تصادفی‌سازی اجاره راه‌اندازی/پیکربندی مصرف حافظه
Iterative بسیار بالا پایین خیر بسیار سریع کم
Random بالا پایین بله بسیار سریع زیاد (متغیر)
Free Lease Queue بالا بالا بله کند (بسته به اندازهٔ استخرها) زیاد (متغیر)
Shared FLQ بالا بالا جزئی، استخرهای درون زیرشبکه‌ها تصادفی هستند کند هنگام افزودن استفاده؛ سریع پس از افزودن کم
این تخصیص‌دهنده پیش‌فرضی است که توسط کارگزار Kea DHCPv6 استفاده می‌شود. این تخصیص‌دهنده آخرین اجارهٔ پیشنهادشده را به خاطر می‌سپارد و اجارهٔ ترتیبی بعدی را به کلاینت بعدی پیشنهاد می‌دهد. برای نمونه، ممکن است نشانی‌ها را به این ترتیب پیشنهاد دهد: 2001:db8:1::10، 2001:db8:1::11، 2001:db8:1::12 و غیره. به همین ترتیب، پیشوند واگذارشدهٔ ترتیبی بعدی را پس از مورد قبلی به کلاینت بعدی پیشنهاد می‌کند. زمان لازم برای یافتن و پیشنهاد دادن اجاره یا پیشوند واگذارشدهٔ بعدی بسیار کوتاه است؛ بنابراین، زمانی که بهره‌برداری از استخر پایین بوده و احتمال در دسترس بودن اجارهٔ انتخابی بعدی بالا باشد، این کارآمدترین تخصیص‌دهنده است.
تخصیص تکرارشونده زمانی که چندین کارگزار DHCP یک پایگاه‌دادهٔ اجاره را به اشتراک می‌گذارند یا به یک کلاستر متصل هستند، عملکرد ضعیفی ارائه می‌دهد. کارگزارها تمایل دارند همان بلوک‌های نشانی را به‌طور مستقل به کلاینت‌های مختلف پیشنهاد داده و تخصیص دهند، که باعث تداخل‌های تخصیص فراوان بین کارگزارها و ارسال‌های مجدد توسط کلاینت‌ها می‌شود. یک تخصیص تصادفی با پراکنده‌سازی ترتیب تخصیص، این مشکل را برطرف می‌کند.
تخصیص‌دهنده تصادفی (Random Allocator)
تخصیص‌دهنده تصادفی از یک تابع تصادفی‌سازی یکنواخت برای انتخاب نشانی‌ها و پیشوندهای واگذارشدهٔ پیشنهادی از استخرهای زیرشبکه استفاده می‌کند. این تخصیص‌دهنده در استقرارهایی مناسب است که چندین کارگزار به یک پایگاه‌دادهٔ مشترک یا یک کلاستر پایگاه‌داده متصل هستند. کارگزارها با پراکنده‌سازی اجاره‌های پیشنهادی، خطر تخصیص هم‌زمان یا تقریباً هم‌زمان یک اجارهٔ یکسان به دو کلاینت مختلف را به حداقل می‌رسانند. علاوه بر این، تاب‌آوری کارگزار را در برابر حملات مبتنی بر پیش‌بینی‌پذیری تخصیص بهبود می‌بخشد.
با این حال، تخصیص‌دهنده تصادفی اندکی از تخصیص‌دهنده تکرارشونده کندتر است. افزون بر این، مصرف حافظهٔ کارگزار را افزایش می‌دهد زیرا باید اجاره‌های تصادفی‌شده را به خاطر بسپارد تا از پیشنهاد دوبارهٔ آن‌ها جلوگیری کند. مصرف حافظه با تعداد اجاره‌های پیشنهادشده رشد می‌کند؛ به عبارت دیگر، استخرهای بزرگ‌تر و کلاینت‌های بیشتر، مصرف حافظه را در تخصیص تصادفی افزایش می‌دهند.
تخصیص‌دهنده صف اجاره‌های آزاد (فقط واگذاری پیشوند)
این یک تخصیص‌دهنده پیشرفته است که استفاده از آن باید در زیرشبکه‌هایی با استخرهای پیشوند واگذارشده با میزان مصرف بالا مد نظر قرار گیرد. در چنین مواردی، ممکن است یافتن یک پیشوند در دسترس برای تخصیص‌دهنده تکرارشونده یا تصادفی زمان قابل‌توجهی ببرد، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای پیشوندی که قصد پیشنهاد آن را دارند یک اجارهٔ معتبر وجود دارد یا خیر. زمانی که ظرفیت استخرهای زیرشبکه تکمیل شده باشد، تعداد بررسی‌ها می‌تواند به اندازهٔ تعداد کل پیشوندهای واگذارشده در زیرشبکه بالا برود که این امر می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ DHCP برای هر درخواست بگذارد.
تخصیص‌دهنده Free Lease Queue (FLQ) تخصیص‌ها و لغو تخصیص‌های اجاره را ردیابی کرده و فهرستی پویا از پیشوندهای واگذارشدهٔ در دسترس را برای هر استخر نگهداری می‌کند. این تخصیص‌دهنده اجازه می‌دهد که بدون در نظر گرفتن میزان استفاده از استخرهای زیرشبکه، یک اجارهٔ در دسترس در یک زمان ثابت انتخاب شود. تخصیص‌دهنده با حذف اجاره‌های تخصیص‌یافته و افزودن اجاره‌های آزادشده یا بازپس‌گرفته‌شده، فهرست اجاره‌های آزاد را به‌طور مداوم به‌روزرسانی می‌کند.
قطعه پیکربندی زیر نحوه انتخاب تخصیص‌دهنده FLQ را برای واگذاری پیشوند در یک زیرشبکه نشان می‌دهد:
0.0
3.5
{
"Dhcp6": {
"subnet6": [
{
"id": 1,
"subnet": "2001:db8:1::/64",
"pd-allocator": "flq"
}
]
}
}
168u
168u
نکته:
0.0
3.5
تخصیص‌دهنده Free Lease Queue تنها می‌تواند برای واگذاری پیشوند DHCPv6 استفاده شود. تلاش برای استفاده از این تخصیص‌دهنده جهت انتساب نشانی (با پارامتر allocator) منجر به خطای پیکربندی خواهد شد. استخرهای نشانی DHCPv6 معمولاً بسیار بزرگ هستند و میزان استفاده از آن‌ها پایین است؛ در این وضعیت، مزایای استفاده از تخصیص‌دهنده FLQ کم‌رنگ می‌شود. مدت‌زمان مورد نیاز تخصیص‌دهنده برای پر کردن صف اجاره‌های آزاد، باعث قفل شدن کارگزار در هنگام راه‌اندازی می‌شود.
168u
168u
چندین نکته وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده برای واگذاری پیشوند مد نظر قرار دهد. تخصیص‌دهنده FLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی و بازپیکربندی کارگزار بگذارد، زیرا تخصیص‌دهنده باید فهرست اجاره‌های آزاد را برای هر زیرشبکه‌ای که در آن استفاده می‌شود پر کند. این تأخیرها هم در طول بارگذاری مجدد پیکربندی و هم هنگامی که زیرشبکه‌ها با استفاده از libdhcp_subnet_cmds.so <#std-ischooklib-libdhcp_subnet_cmds.so> ایجاد می‌شوند، قابل مشاهده است. این تخصیص‌دهنده برای نگهداری فهرست اجاره‌های آزاد، مصرف حافظه را متناسب با اندازهٔ کل استخرهایی که برای آن‌ها به کار رفته است افزایش می‌دهد. در نهایت، بازپس‌گیری اجاره باید با مقدار پایینی برای پارامتر reclaim-timer-wait-time فعال شود، تا اطمینان حاصل گردد که کارگزار به‌طور مکرر اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق صف اجاره‌های آزاد برای تخصیص مجدد در دسترس قرار می‌دهد. اجاره‌های منقضی‌شده تا زمانی که توسط کارگزار بازپس‌گرفته نشوند، از نظر تخصیص‌دهنده آزاد به شمار نمی‌آیند. برای جزئیات بیشتر درباره فرایند بازپس‌گیری اجاره، بخش Lease Reclamation <#lease-reclamation> را ببینید.
پیشنهاد می‌کنیم تخصیص‌دهنده FLQ تنها پس از بررسی دقیق انتخاب شود. کارگزار هیچ محدودیتی بر اندازه استخرهای delegated-prefix مورد استفاده با تخصیص‌دهنده FLQ اعمال نمی‌کند، بنابراین به کاربران توصیه می‌کنیم قبل از استقرار پیکربندی دارای تخصیص‌دهنده FLQ در محیط عملیاتی، زمان لازم برای بارگذاری استخرها توسط کارگزار را آزمایش کنند. همچنین توصیه می‌کنیم نوع تخصیص‌دهنده دیگری را در تنظیمات پیکربندی سراسری مشخص کرده و این انتخاب را در سطح subnet یا shared-network بازنویسی کنید، تا از تخصیص‌دهنده FLQ فقط برای زیرشبکه‌های انتخابی استفاده شود. به این ترتیب، زمانی که یک زیرشبکه جدید بدون مشخص کردن تخصیص‌دهنده افزوده می‌شود، تنظیمات سراسری استفاده می‌شود و در نتیجه از تحمیل اثر غیرضروری بر زمان راه‌اندازی کارگزار جلوگیری می‌شود.
هشدار:
0.0
3.5
تخصیص‌دهنده FLQ برای استفاده با پایگاه‌دادهٔ اجاره مشترک مناسب نیست (یعنی زمانی که چندین کارگزار Kea اجاره‌ها را در یک پایگاه‌داده یکسان ذخیره می‌کنند). کارگزارها از اجاره‌های منقضی‌شده‌ای که توسط کارگزارهای همتا بازپس‌گرفته شده‌اند اطلاعی ندارند و هرگز آن‌ها را به صف‌های محلی اجاره‌های آزاد خود بازنمی‌گردانند. در نتیجه، کارگزارها قادر نخواهند بود برخی از اجاره‌های در دسترس را به کلاینت‌ها پیشنهاد دهند. تنها کارگزاری که یک اجارهٔ مشخص را بازپس می‌گیرد قادر به پیشنهاد دادن آن خواهد بود.
168u
168u
در Kea 3.1.1 یک پارامتر جدید با نام adaptive-lease-time-threshold اضافه شد. این پارامتر می‌تواند در سطوح global، shared network و subnet مشخص شود و یک مقدار اعشاری بین 0.0 (به‌جز خود آن) و 1.0 می‌پذیرد. این پارامتر به‌طور پیش‌فرض یا در صورت تنظیم بر روی 1.0 غیرفعال است. این پارامتر تنها توسط تخصیص‌دهنده FLQ پشتیبانی می‌شود. هنگامی که نرخ اشغال استخرها در یک زیرشبکه بالاتر از مقدار مشخص‌شده باشد، کارگزار طول‌عمر معتبر اجاره را برای کلاینت‌های جدید به مقدار مربوط در min-valid-lifetime کاهش می‌دهد. کلاینت‌هایی که یک اجارهٔ موجود را تمدید می‌کنند، حداقل طول‌عمر باقی‌مانده از اجارهٔ فعلی را دریافت خواهند کرد. از آنجا که اجاره‌ها سریع‌تر منقضی می‌شوند، کارگزار می‌تواند سریع‌تر بازیابی شود یا به‌طور کامل از اتمام ظرفیت استخر جلوگیری کند.
نرخ اشغال به‌صورت تعداد پیشوندهای واگذارشدهٔ پیش‌تر تخصیص‌یافته (شامل نشانی در حال تخصیص) تقسیم بر تعداد کل پیشوندها در استخرهایی که امکان تخصیص نشانی از آن‌ها وجود دارد، تعریف می‌شود (یعنی اگر پرس‌وجو عضو محافظ client-classes یک استخر نباشد، یا اگر طول پیشوند واگذارشده سازگار نباشد، آن استخر در نظر گرفته نمی‌شود)..SS تخصیص‌دهنده Shared Free Lease Queue
هشدار:
0.0
3.5
این ویژگی که در Kea 3.1.9 افزوده شده است، آزمایشی در نظر گرفته می‌شود و برای استفاده در محیط عملیاتی پشتیبانی نمی‌شود.
168u
168u
نکته:
0.0
3.5
تخصیص‌دهنده SFLQ می‌تواند برای استخرهای آدرس یا پیشوند (prefix) استفاده شود. برای شفافیت، این ویژگی در ادامه بر اساس استخرهای آدرس توضیح داده شده است، اما به‌طور یکسان در مورد استخرهای پیشوند نیز صدق می‌کند.
168u
168u
تخصیص‌دهنده Shared Free Lease Queue (SFLQ) برای سایت‌هایی در نظر گرفته شده است که دارای پشتیبان‌های اجاره اشتراکی (MySQL یا PostgreSQL) و زیرشبکه‌هایی با استخرهای آدرس دارای مصرف بالا هستند. در چنین مواردی، پیدا کردن یک آدرس آزاد برای تخصیص‌دهنده تکرارشونده (iterative) یا تصادفی (random) می‌تواند زمان قابل توجهی ببرد، زیرا آن‌ها باید مکرراً بررسی کنند که آیا برای آدرسی که پیشنهاد می‌دهند اجاره معتبری وجود دارد یا خیر. زمانی که استخرهای زیرشبکه رو به اتمام باشند، تعداد بررسی‌ها می‌تواند به اندازه تعداد آدرس‌های موجود در زیرشبکه بالا برود. از آنجا که هر بررسی نیازمند یک پرس‌وجو از پایگاه داده است، این مسئله می‌تواند تأثیر منفی مستقیمی بر زمان پاسخ DHCP برای هر درخواست بگذارد.
مشابه تخصیص‌دهنده Free Lease Queue، تخصیص‌دهنده SFLQ تخصیص‌ها و آزادسازی‌های اجاره را ردیابی کرده و فهرستی پویا از آدرس‌های در دسترس برای هر استخر آدرس نگهداری می‌کند. به این فهرست‌ها داده‌های SFLQ گفته می‌شود. این قابلیت امکان انتخاب یک اجاره در دسترس را در زمانی ثابت، صرف‌نظر از میزان مصرف استخرهای زیرشبکه، فراهم می‌کند. داده‌های SFLQ از طریق به‌روزرسانی‌های اختصاصی اجاره که توسط سرور Kea برای اجاره‌های متعلق به زیرشبکه‌های دارای تخصیص SFLQ به کار می‌رود، نگهداری می‌شوند.
تفاوت بنیادین میان تخصیص‌دهنده‌های FLQ و SFLQ در این است که تخصیص SFLQ داده‌های SFLQ را به‌جای حافظه محلی سرور Kea، به‌صورت متمرکز در پشتیبان اجاره ذخیره می‌کند. این امر اجازه می‌دهد داده‌ها بین سرورها به اشتراک گذاشته شوند تا همگی درک یکسانی از وضعیت فعلی اجاره‌ها داشته باشند. این ویژگی همچنین به این معناست که داده‌های SFLQ پس از ایجاد پایدار می‌مانند و بنابراین نیازی به ایجاد مجدد آن‌ها هنگام راه‌اندازی یا بازپیکربندی سرور Kea نیست.
از آنجا که استخرهای آدرس v6 می‌توانند بسیار بزرگ باشند و معمولاً نرخ مصرف پایینی دارند، تخصیص‌دهنده پیش‌فرض Iterative باید کارایی مناسبی ارائه دهد. تخصیص‌دهنده SFLQ می‌تواند برای استخرهای تفویض پیشوند (prefix delegation) که در آن‌ها تعداد پیشوندها در یک استخر مشخص محدودتر بوده و مصرف استخر می‌تواند بسیار بالا باشد، بسیار مفید واقع شود.
تخصیص‌دهنده‌ها برای v6 به‌طور مستقل برای آدرس‌ها و پیشوندهای تفویض‌شده تعیین می‌شوند. تخصیص‌دهنده SFLQ ممکن است برای هر دو نوع استخر استفاده شود. قطعه پیکربندی زیر نشان می‌دهد که چگونه تخصیص‌دهنده‌های SFLQ را برای تمام استخرهای هر دو نوع در یک زیرشبکه انتخاب کنید:
0.0
3.5
{
"Dhcp6": {
"subnet6": [
{
"id": 1,
"subnet": "2001:db8:1::/64",
"allocator": "shared-flq",
"pd-allocator": "shared-flq"
}
]
}
}
168u
168u
ملاحظاتی وجود دارد که مدیر سیستم باید پیش از استفاده از این تخصیص‌دهنده در نظر بگیرد. همانند FLQ، تخصیص‌دهنده SFLQ می‌تواند تأثیر شدیدی بر زمان راه‌اندازی و بازپیکربندی سرور بگذارد، زیرا تخصیص‌دهنده باید داده‌های SFLQ را برای هر استخر در هر زیرشبکه‌ای که در آن به کار رفته پر کند. این تأخیرها هم در طول بارگذاری مجدد پیکربندی و هم زمانی که زیرشبکه‌ها با استفاده از libdhcp_subnet_cmds.so <#std-ischooklib-libdhcp_subnet_cmds.so> ایجاد می‌شوند، قابل مشاهده است. برخلاف FLQ، این هزینه‌ها تنها اولین باری رخ می‌دهند که یک زیرشبکه برای استفاده از SFLQ پیکربندی می‌شود یا تغییراتی در بازه‌های آدرس استخرهای آن اعمال می‌گردد. به عبارت دیگر، پس از راه‌اندازی مجدد یا بازپیکربندی، داده‌های SFLQ فقط باید برای استخرهایی ایجاد شوند که از قبل داده‌ای برای آن‌ها وجود ندارد. بنابراین تأثیر آن بر راه‌اندازی‌های مجدد یا بازپیکربندی‌های بعدی زیرشبکه‌هایی که از قبل از SFLQ استفاده می‌کنند، حداقلی است.
از آنجا که داده‌های SFLQ در پشتیبان اجاره نگهداری می‌شوند، هزینه ذخیره‌سازی آن بر دوش فضای دیسک سرور پایگاه داده است تا حافظه محلی سرور Kea. مصرف دیسک برای داده‌های SFLQ کسری از مقداری است که از پیش به ازای هر اجاره ذخیره شده است، و با افزایش مصرف استخر، حجم داده‌های SFLQ کاهش می‌یابد.
ما توصیه می‌کنیم تخصیص‌دهنده SFLQ تنها پس از بررسی دقیق انتخاب شود. همان‌طور که در بالا اشاره شد، هنگام آغاز استفاده از SFLQ تأثیر بر زمان راه‌اندازی می‌تواند قابل توجه باشد. ایجاد داده‌های اولیه SFLQ برای استخرهای بزرگ (مثلاً بیش از ۵۰۰ هزار آدرس یا پیشوند) ممکن است راه‌اندازی سرور را چند ثانیه یا بیشتر به ازای هر استخر به تأخیر بیندازد. این فرآیند برای استخرهای کوچک‌تر (مثلاً ۶۵ هزار آدرس یا پیشوند) سریع‌تر است، اما در صورت وجود استخرهای زیاد، مجموع زمان آن‌ها انباشته می‌شود. برای کاهش این هزینه راه‌اندازی، توصیه می‌کنیم نوع تخصیص‌دهنده دیگری را در سطح سراسری (global) مشخص کرده و تخصیص‌دهنده SFLQ را در سطح زیرشبکه یا shared-network تنها برای زیرشبکه‌های گزینش‌شده تعیین نمایید.
جنبه مهم دیگری از تخصیص‌دهنده SFLQ وجود دارد که نیازمند توجه است. همان‌طور که پیش‌تر ذکر شد، هنگامی که یک سرور از تخصیص SFLQ برای استخری معین استفاده می‌کند، به‌روزرسانی‌های اختصاصی در پشتیبان را برای نگهداری داده‌های SFLQ به کار می‌گیرد. بنابراین حیاتی است که تمام سرورهایی که در یک پشتیبان اجاره سهیم هستند، در مورد اینکه کدام زیرشبکه‌ها از تخصیص SFLQ استفاده می‌کنند هماهنگ باشند. اگر آن‌ها هماهنگ نباشند، داده‌های SFLQ به‌سرعت نادقیق می‌شوند؛ آدرس‌ها ممکن است آزاد به نظر برسند در حالی که آزاد نیستند و برعکس. در حالت اول، موتور تخصیص یک اجاره موجود را شناسایی کرده و آدرس دیگری را امتحان می‌کند؛ در حالت دوم، اجاره پیشنهاد داده نخواهد شد.
نکته:
0.0
3.5
اکیداً توصیه می‌شود که پیکربندی زیرشبکه‌ها برای شروع یا توقف استفاده از تخصیص SFLQ در بازه‌های تعمیر و نگهداری (maintenance windows) انجام گیرد تا در حین اعمال تغییرات، سرورها به‌طور فعال به کلاینت‌های آن زیرشبکه‌ها سرویس ندهند. این کار از بروز ناسازگاری در داده‌های SFLQ جلوگیری می‌کند.
داده‌های SFLQ بر پایه استخرها ردیابی می‌شوند که در آن‌ها هر استخر دارای یک آدرس شروع و یک آدرس پایان است. تغییرات پیکربندی که بازه آدرس یک استخر را تغییر می‌دهند یا آن را به چندین استخر جدید تقسیم می‌کنند، هنگام اعمال پیکربندی جدید باعث ایجاد داده‌های SFLQ برای استخرهای جدید خواهند شد.
168u
168u
همان‌طور که قبلاً اشاره شد، زمانی که سرور راه‌اندازی مجدد یا بازپیکربندی می‌شود، روی زیرشبکه‌های خود پیمایش کرده و تخصیص‌دهنده پیکربندی‌شده را برای استخرهای آن زیرشبکه مقداردهی اولیه می‌کند. برای تخصیص‌دهنده SFLQ، این امر موجب می‌شود سرور از پشتیبان اجاره درخواست کند تا داده‌های SFLQ را برای هر استخر موجود در زیرشبکه بسازد. اگر داده‌های SFLQ از قبل برای یک استخر وجود داشته باشد، درخواست فوراً بازمی‌گردد. در غیر این صورت، پس از ایجاد داده‌های SFLQ برای آن استخر بازخواهد گشت. ایجاد داده‌های SFLQ برای یک استخر مشخص، یک عملیات انحصاری (exclusive) است. هنگامی که این عملیات توسط یک سرور آغاز شد، هر درخواستی از سوی دیگر سرورها برای ایجاد داده‌های SFLQ همان استخر مسدود (block) شده و تا زمانی که نخستین درخواست ساخت داده‌های SFLQ استخر را کامل نکند، بازنخواهد گشت. به این ترتیب، فقط یک سرور واقعاً داده‌های SFLQ استخر را ایجاد می‌کند و تمام سرورهای دیگر تا زمانی که داده‌های SFLQ استخر موجود نباشد، از استفاده از آن منع می‌شوند. این رفتار برای حفظ نظم در حین راه‌اندازی‌ها و بازپیکربندی‌های هم‌زمان سرورها در نظر گرفته شده است.
در نهایت، موضوع استخرهای هم‌پوشان مطرح است. Kea پیکربندی استخرهایی را که بازه‌های آدرس آن‌ها با استخرهای دیگر هم‌پوشانی دارند، مجاز می‌داند (به Overlapping Pools مراجعه کنید). تخصیص‌دهنده SFLQ به‌طور کلی از این سناریوها پشتیبانی می‌کند، تا زمانی که تمام چنین استخرهایی روی همه سرورها:
0.0
• 2
برای استفاده از تخصیص‌دهنده SFLQ پیکربندی شده باشند
• 2
از یک نوع اجاره یکسان باشند (همگی TYPE_NA یا همگی TYPE_PD)
• 2
برای استخرهای تفویض پیشوند، مقدار delegated_len یکسانی داشته باشند
168u
استفاده از استخرهای تفویض پیشوند هم‌پوشان در هر شرایطی غیر از تعریف یک استخر یکسان در چندین زیرشبکه، توصیه نمی‌شود.
نکته:
0.0
3.5
بازیابی اجاره (Lease reclamation) باید با مقداری کم برای پارامتر reclaim-timer-wait-time فعال باشد تا اطمینان حاصل شود که سرور به‌طور مرتب اجاره‌های منقضی‌شده را جمع‌آوری کرده و آن‌ها را از طریق داده‌های SFLQ برای تخصیص در دسترس قرار می‌دهد. اجاره‌های منقضی‌شده تا زمانی که توسط سرور بازیابی نشوند، از نظر تخصیص‌دهنده آزاد محسوب نمی‌شوند. برای جزئیات بیشتر درباره فرآیند بازیابی اجاره، به Lease Reclamation <#lease-reclamation> مراجعه کنید.
168u
168u
نکته:
0.0
3.5
تخصیص‌دهنده SFLQ محدود به استفاده در استخرهایی با ظرفیت حداکثر 16777216 آدرس یا پیشوند است. استخرهایی با ظرفیت بزرگ‌تر باعث ایجاد خطای پیکربندی خواهند شد.
168u
168u
تخصیص‌دهنده SFLQ از adaptive-lease-time-threshold پشتیبانی نمی‌کند..SH "اتصال به پایگاه داده (DATABASE CONNECTIVITY)"
سرورهای Kea (kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6>) می‌توانند برای استفاده از بک‌اندهای مختلف پایگاه داده جهت اجاره‌ها (leases)، میزبان‌ها (hosts) و پیکربندی تنظیم شوند. آن‌ها می‌توانند از طریق پارامترهای on-fail و retry-on-startup برای پشتیبانی از بازیابی خودکار در زمان قطع اتصال پیکربندی شوند.
(پارامترهای reconnect-wait-time و max-reconnect-tries در بخش «Lease Database Configuration» <#database-configuration4> و «Lease Database Configuration» <#database-configuration6> شرح داده شده‌اند.)
درک این موضوع که بازیابی خودکار چگونه و چه زمانی وارد عمل می‌شود بسیار حائز اهمیت است.
بازیابی خودکار، در صورت پیکربندی، تنها پس از یک راه‌اندازی یا بازپیکربندی موفقیت‌آمیز که در طول آن اتصال به تمام بک‌اندها با موفقیت برقرار شده باشد، کار می‌کند.
در زمان راه‌اندازی سرور، ناتوانی در برقراری اتصال به هر یک از بک‌اندهای پیکربندی‌شده تنها در صورتی یک خطای مهلک در نظر گرفته می‌شود که retry-on-startup روی false (مقدار پیش‌فرض) تنظیم شده باشد. یک خطای مهلک در گزارش ثبت شده و بر این اساس که پیکربندی در زمان راه‌اندازی باید معتبر باشد، سرور خارج می‌شود. خروج به سیستم‌عامل این امکان را به اسکریپت‌های ناظر (nanny scripts) می‌دهد تا مشکل را تشخیص دهند.
اگر retry-on-startup روی true تنظیم شده باشد، سرور حتی در هنگام راه‌اندازی سرور یا رویدادهای بازپیکربندی نیز تلاش برای اتصال مجدد را آغاز کرده و از اقدام مشخص‌شده در پارامتر on-fail پیروی خواهد کرد.
در طول بازپیکربندی پویا، اتصال تمام بک‌اندها قطع شده و سپس با استفاده از پیکربندی جدید مجدداً برقرار می‌شود. اگر اتصال به هر یک از بک‌اندها برقرار نشود، سرور یک خطای مهلک ثبت می‌کند اما فعال باقی می‌ماند. سرور قادر به پردازش دستورها خواهد بود، اما به کلاینت‌ها سرویس‌دهی نمی‌کند. این امر اجازه می‌دهد تا در صورت نیاز، پیکربندی از طریق دستورهای config-set <#std-isccmd-config-set> یا remote-* تصحیح شود.
در طول عملیات عادی، در صورتی که اتصال به هر یک از بک‌اندها قطع شود و بازیابی خودکار برای آن بک‌اند فعال باشد، سرور اتصال خود را از بک‌اند مربوطه قطع کرده و سپس تلاش می‌کند مجدداً متصل شود. در طول فرآیند بازیابی، سرور طبق گزینهٔ پیکربندی‌شدهٔ on-fail سرویس‌دهی به کلاینت‌ها را متوقف می‌کند، اما همچنان به دستورها پاسخ می‌دهد.
پارامتر on-fail اقداماتی را که سرور باید هنگام قطع اتصال انجام دهد، تعیین می‌کند. این پارامتر می‌تواند یکی از مقادیر زیر را داشته باشد:
0.0
• 2
stop-retry-exit - نشان می‌دهد که سرور باید هنگام تلاش برای بازیابی اتصال، سرویس‌دهی را متوقف کرده و در صورتی که بازیابی پس از max-reconnect-tries موفقیت‌آمیز نبود، خارج شود.
• 2
serve-retry-exit - نشان می‌دهد که سرور نباید هنگام تلاش برای بازیابی اتصال سرویس‌دهی را متوقف کند، اما در صورتی که بازیابی پس از max-reconnect-tries موفقیت‌آمیز نبود، باید خارج شود.
• 2
serve-retry-continue - نشان می‌دهد که سرور نباید هنگام تلاش برای بازیابی اتصال سرویس‌دهی را متوقف کند، و در صورتی که بازیابی پس از max-reconnect-tries موفقیت‌آمیز نبود نیز نباید خارج شود.
168u
اگر اتصال به تمام بک‌اندها بازیابی شود، سرور به عملیات عادی بازمی‌گردد. اگر اتصال نتواند بازیابی شود و سرور برای خروج پیکربندی شده باشد، قبل از خاموش شدن یک خطای مهلک صادر می‌کند.
نکته:
0.0
3.5
از نسخهٔ Kea 3.1.5، بک‌اند اجارهٔ memfile از پارامتر on-fail پشتیبانی می‌کند. اگر هنگام نوشتن در فایل اجاره، خطایی مانند "no space on device" رخ دهد و on-fail برابر با stop-retry-exit (پیش‌فرض) یا serve-retry-exit باشد، سرور بلافاصله خارج خواهد شد. اگر on-fail برابر با serve-retry-continue باشد، سرور فعال باقی می‌ماند، هرچند خطاهای نوشتن تا زمان انجام اقدام اصلاحی ادامه خواهند داشت. مقادیری غیر از صفر برای max-reconnect-tries و reconnect-wait-time توسط memfile پشتیبانی نمی‌شوند.
168u
168u
برای اینکه سرورهای Kea DHCP بتوانند با بک‌اندهای پایگاه داده کار کنند، طرح‌وارهٔ (schema) پایگاه داده باید ایجاد شده و با نسخهٔ سرور Kea مطابقت داشته باشد. اگر بررسی نسخه با شکست مواجه شود و بک‌اند پایگاه داده به‌صورت فقط‌خواندنی (read-only) پیکربندی نشده باشد، Kea تلاش می‌کند تا طرح‌واره را مقداردهی اولیه کند.
نکته:
0.0
3.5
سرور Kea به‌طور خودکار اقدام به ارتقای یک طرح‌وارهٔ موجود نمی‌کند؛ چرا که انجام این کار ممکن است کاربران را از فرصت اتخاذ اقدامات احتیاطی، مانند پشتیبان‌گیری از پایگاه داده یا خاموش کردن موقت سرورهای در حال اجرای Kea که در حال حاضر روی پایگاه داده کار می‌کنند، محروم سازد.
168u
168u
اتصال به سرور پایگاه داده می‌تواند به‌صورت اختیاری توسط TLS محافظت شود. پارامترهای پیکربندی متناظر پایگاه داده برای سرورهای Kea عبارتند از:
0.0
• 2
پارامتر trust-anchor نام فایل یا مسیر دایرکتوری مرجع صدور گواهی (CA) را مشخص می‌کند.
• 2
پارامتر cert-file نام فایل گواهی کلاینت را مشخص می‌کند.
• 2
پارامتر key-file نام فایل کلید خصوصی را مشخص می‌کند.
• 2
پارامتر ssl-mode حالت SSL را مشخص می‌کند: disable، prefer، require، verify-ca یا verify-full.
• 2
پارامتر cipher-list فهرست سایفرهای TLS را مشخص می‌کند (نحوهٔ نگارش محتوای این پارامتر در راهنمای سایفرهای OpenSSL شرح داده شده است).
168u
در حال حاضر، میزان پشتیبانی برای هر پایگاه داده به شرح زیر است:
0.0
• 2
پایگاه دادهٔ MySQL از تمام این مجموعه، به جز ssl-mode پشتیبانی می‌کند؛ پیکربندی‌های بیشتر باید در تنظیمات محلی MySQL انجام شوند، مانند فهرست ابطال گواهی (CRL)، انتخاب نسخهٔ خاصی از TLS، احراز هویت دوطرفه و غیره. هنگامی که یک اتصال TLS الزامی باشد اما اتصال واقعی به‌صورت متن آشکار (clear text) برقرار شود، یک گزارش خطا ثبت می‌گردد.
• 2
پایگاه دادهٔ PostgreSQL از تمام این مجموعه، به جز cipher-list پشتیبانی می‌کند؛ پیکربندی‌های اضافی باید در کتابخانهٔ کلاینت (libpq) انجام شود. سایر موارد باید در پیکربندی محلی PostgreSQL صورت گیرد.
168u
برای جزئیات بیشتر دربارهٔ ایمن‌سازی اتصال پایگاه داده، به بخش «Securing Database Connections» <#sec-database-connection> مراجعه کنید..SH "انقضای اجاره (LEASE EXPIRATION)"
نقش اصلی کارگزار DHCP تخصیص نشانی‌ها و/یا واگذاری پیشوندها به کلاینت‌های DHCP است. این نشانی‌ها و پیشوندها اغلب به عنوان «اجاره‌ها» ("leases") نامیده می‌شوند. اجاره‌ها معمولاً برای مدت زمان محدودی که به عنوان «طول عمر معتبر» ("valid lifetime") شناخته می‌شود به کلاینت‌ها تخصیص می‌یابند. کلاینت‌های DHCP که مایلند به استفاده از اجاره‌های تخصیص‌یافته خود ادامه دهند، آن‌ها را به صورت دوره‌ای با ارسال پیام مناسب به کارگزار DHCP تمدید می‌کنند. کارگزار DHCP زمان تمدید این اجاره‌ها را ثبت کرده و زمان انقضای جدیدی برای آن‌ها محاسبه می‌کند.
اگر کلاینت اجاره‌ای را پیش از به پایان رسیدن طول عمر معتبر آن تمدید نکند، اجاره منقضی‌شده تلقی می‌شود. شرایط متعددی وجود دارد که ممکن است کلاینت تمدید اجاره را متوقف کند؛ سناریوهای رایج شامل مواردی است که دستگاه اجراکننده کلاینت برای مدت طولانی خاموش می‌شود یا دستگاه همراه از محدوده شبکه خارج می‌گردد.
فرآیندی که کارگزار DHCP طی آن اجاره‌های منقضی‌شده را برای تخصیص مجدد در دسترس قرار می‌دهد، «بازپس‌گیری اجاره» ("lease reclamation") نامیده می‌شود، و اجاره‌های منقضی‌شده‌ای که از طریق این فرآیند مجدداً در دسترس قرار می‌گیرند «بازپس‌گرفته‌شده» ("reclaimed") نام دارند. کارگزار DHCP به محض تشخیص انقضای یک اجاره، برای بازپس‌گیری آن تلاش می‌کند. کارگزار چندین راه ممکن برای تشخیص انقضا دارد: ممکن است تلاش کند اجاره‌ای را به یک کلاینت اختصاص دهد اما متوجه شود این اجاره در پایگاه‌داده وجود دارد و منقضی شده است؛ یا می‌تواند به‌طور دوره‌ای پایگاه‌داده اجاره را برای یافتن اجاره‌های منقضی‌شده پرس‌وجو کند. صرف‌نظر از چگونگی تشخیص اجاره منقضی‌شده، این اجاره باید پیش از تخصیص مجدد به یک کلاینت بازپس‌گیری شود.
این فصل نحوه پیکربندی کارگزار را برای پرس‌وجوی دوره‌ای اجاره‌های منقضی‌شده و چگونگی به حداقل رساندن تأثیر فرآیند دوره‌ای بازپس‌گیری اجاره بر پاسخگویی کارگزار شرح می‌دهد. در نهایت، «وابستگی اجاره» ("lease affinity") را توضیح می‌دهد که سازوکاری برای تخصیص همان اجاره به یک کلاینت بازگشتی پس از انقضای اجاره‌اش فراهم می‌آورد.
اگرچه تمام مثال‌های پیکربندی در این بخش برای کارگزار DHCPv4 ارائه شده‌اند، اما همین پارامترها را می‌توان برای پیکربندی کارگزار DHCPv6 نیز به کار برد.
"بازپس‌گیری اجاره (Lease Reclamation)"
بازپس‌گیری اجاره فرآیندی است که طی آن یک اجاره منقضی‌شده برای تخصیص به همان کلاینت یا کلاینتی دیگر در دسترس قرار می‌گیرد. این فرآیند شامل مراحل زیر برای هر اجاره بازپس‌گرفته‌شده است:
0.0
• 2
فراخوانی calloutها برای نقاط قلاب lease4_expire یا lease6_expire، در صورتی که کتابخانه‌های قلاب پشتیبانی‌کننده از آن calloutها بارگذاری شده باشند.
• 2
به‌روزرسانی DNS؛ یعنی حذف هرگونه مدخل DNS مرتبط با اجاره منقضی‌شده.
• 2
به‌روزرسانی اطلاعات اجاره در پایگاه‌داده اجاره‌ها به منظور نشان دادن اینکه اجاره اکنون برای تخصیص مجدد در دسترس است.
• 2
به‌روزرسانی شمارنده‌ها در کارگزار؛ فرآیندی که شامل افزایش تعداد اجاره‌های بازپس‌گرفته‌شده و کاهش تعداد نشانی‌های تخصیص‌یافته یا پیشوندهای واگذارشده است.
168u
لطفاً برای مشاهده نحوه پیکربندی به‌روزرسانی‌های DNS در Kea به The DHCP-DDNS Server <#dhcp-ddns-server> و برای اطلاعات درباره استفاده از کتابخانه‌های قلاب به Hook Libraries <#hooks-libraries> مراجعه کنید.
"پارامترهای پیکربندی بازپس‌گیری اجاره (Lease Reclamation Configuration Parameters)"
فهرست زیر تمام پارامترهای پیکربندی مربوط به پردازش اجاره‌های منقضی‌شده را به همراه مقادیر پیش‌فرض آن‌ها ارائه می‌دهد:
0.0
• 2
reclaim-timer-wait-time - این پارامتر فاصله‌های زمانی بین اتمام چرخه بازپس‌گیری قبلی و شروع چرخه بعدی را تنظیم می‌کند. بر حسب ثانیه مشخص می‌شود؛ مقدار پیش‌فرض 10 است.
• 2
flush-reclaimed-timer-wait-time - این پارامتر مشخص می‌کند کارگزار با چه تواتری روند بازپس‌گیری اجاره را آغاز می‌کند. بر حسب ثانیه بیان می‌شود؛ مقدار پیش‌فرض 25 است. اگر هر دو پارامتر flush-reclaimed-timer-wait-time و hold-reclaimed-time غیر صفر باشند، هنگامی که کلاینت پیام release ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره‌ها، منقضی می‌شود.
• 2
hold-reclaimed-time - این پارامتر تعیین می‌کند که اجاره پس از بازپس‌گیری تا چه مدت باید نگهداری شود. مقدار غیر صفر این پارامتر، قابلیت وابستگی اجاره را فعال می‌کند. بر حسب ثانیه بیان می‌شود؛ مقدار پیش‌فرض 3600 است. اگر هر دو پارامتر flush-reclaimed-timer-wait-time و hold-reclaimed-time غیر صفر باشند، هنگامی که کلاینت پیام release ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره‌ها، منقضی می‌شود.
• 2
max-reclaim-leases - این پارامتر حداکثر تعداد اجاره‌های بازپس‌گرفته‌شده‌ای را که می‌توان در یک نوبت پردازش کرد مشخص می‌کند. مقدار صفر به معنی نامحدود است (یعنی پردازش تمام اجاره‌های بازپس‌گرفته‌شده). مقدار پیش‌فرض 100 است.
• 2
max-reclaim-time - این پارامتر حد بالایی برای مدت زمانی که یک فرآیند بازپس‌گیری اجاره می‌تواند طول بکشد تعیین می‌کند. مقدار صفر به معنای نبود محدودیت زمانی است. بر حسب میلی‌ثانیه بیان می‌شود؛ مقدار پیش‌فرض 250 است.
• 2
unwarned-reclaim-cycles - در صورت تعیین محدودیت‌های بازپس‌گیری اجاره (max-reclaim-leases و/یا max-reclaim-time)، تحت شرایط خاصی ممکن است کارگزار نتواند اجاره‌های آماده بازپس‌گیری را با سرعت کافی پردازش کند. این پارامتر مشخص می‌کند چند چرخه پاک‌سازی متوالی باید با باقی ماندن اجاره‌های در صف پردازش خاتمه یابند پیش از آنکه هشداری چاپ شود. مقدار پیش‌فرض 5 چرخه است.
168u
این پارامترها با جزئیات بیشتر در ادامه این فصل توضیح داده شده‌اند.
در صورتی که پارامتری صراحتاً در پیکربندی مشخص نشده باشد، مقدار پیش‌فرض آن به کار می‌رود. اگر نگاشت expired-leases-processing به‌طور کامل در پیکربندی حذف شده باشد، مقادیر پیش‌فرض برای تمام پارامترهای فهرست‌شده در بالا استفاده می‌شوند.
"پیکربندی بازپس‌گیری اجاره (Configuring Lease Reclamation)"
برنامه Kea را می‌توان به گونه‌ای پیکربندی کرد که اجاره‌های منقضی‌شده را به‌طور دوره‌ای شناسایی و بازپس‌گیری کند. در طول این فرآیند، مدخل‌های اجاره در پایگاه‌داده اصلاح یا حذف می‌شوند. در حین وقوع این امر، کارگزار پیام‌های ورودی DHCP را پردازش نمی‌کند تا از بروز تداخل دسترسی هم‌روند به اطلاعات پایگاه‌داده جلوگیری شود. در نتیجه، کارگزار در هنگام انجام بازپس‌گیری اجاره پاسخگو نخواهد بود و پرس‌وجوهای DHCP انباشته می‌شوند؛ پاسخ‌ها پس از اتمام چرخه بازپس‌گیری اجاره ارسال خواهند شد.
در پیاده‌سازی‌هایی که زمان پاسخ‌دهی در آن‌ها حیاتی است، مدیران سیستم ممکن است تمایل داشته باشند وقفه‌های سرویس‌دهی ناشی از بازپس‌گیری اجاره را به حداقل برسانند. به این منظور، Kea پارامترهای پیکربندی متعددی برای کنترل بسامد چرخه‌های بازپس‌گیری اجاره، حداکثر تعداد اجاره‌های پردازش‌شده در یک چرخه و حداکثر مدت زمانی که یک چرخه بازپس‌گیری اجازه دارد پیش از قطع شدن اجرا شود ارائه می‌دهد. مثال‌های زیر نحوه استفاده از این پارامترها را نشان می‌دهند:
0.0
3.5
{
"Dhcp4": {
"expired-leases-processing": {
"reclaim-timer-wait-time": 5,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
}
}
}
168u
168u
پارامتر اول بر حسب ثانیه بیان می‌شود و فاصله زمانی بین دو چرخه متوالی بازپس‌گیری اجاره را مشخص می‌کند. این موضوع با نمودار زیر توضیح داده شده است:
0.0
3.5
| c1 | | c2 | |c3| | c4 |
|<---->|<---------->|<-->|<---------->|<>|<---------->|<-->|<--
------------------------------------------------------------------>
| | 5s | | 5s | | 5s | | time
168u
168u
این نمودار چهار چرخه بازپس‌گیری اجاره (c1 تا c4) با مدت زمان متغیر را نشان می‌دهد. مدت زمان چرخه بازپس‌گیری به تعداد اجاره‌های منقضی‌شده شناسایی و پردازش‌شده در آن چرخه خاص بستگی دارد. این مدت زمان معمولاً به میزان قابل توجهی کوتاه‌تر از فاصله بین چرخه‌ها است.
با توجه به reclaim-timer-wait-time، کارگزار فاصله‌های زمانی ثابت پنج ثانیه‌ای بین پایان یک چرخه و شروع چرخه بعدی حفظ می‌کند. این امر وجود دوره‌های ۵ ثانیه‌ای را تضمین می‌کند که طی آن کارگزار به پرس‌وجوهای DHCP پاسخگو باقی می‌ماند و بازپس‌گیری اجاره را انجام نمی‌دهد. مقادیر max-reclaim-leases و max-reclaim-time روی 0 تنظیم شده‌اند که هیچ محدودیتی بر حداکثر تعداد اجاره‌های بازپس‌گرفته‌شده در چرخه مشخص یا حداکثر مدت زمان هر چرخه اعمال نمی‌کند.
در پیاده‌سازی‌هایی با بهره‌برداری بالای مخزن اجاره (lease pool)، طول عمرهای معتبر نسبتاً کوتاه، و کلاینت‌هایی با قطع ارتباط مکرر که باعث انقضای اجاره‌ها می‌شوند، ممکن است تعداد اجاره‌های منقضی‌شده نیازمند بازپس‌گیری در هر زمان معین به طور چشمگیری افزایش یابد. در این حالت، اغلب مطلوب است که محدودیت‌هایی بر حداکثر مدت زمان یک چرخه بازپس‌گیری یا حداکثر تعداد اجاره‌های بازپس‌گرفته‌شده در یک چرخه اعمال شود. پیکربندی زیر نشان می‌دهد چگونه می‌توان این کار را انجام داد:
0.0
3.5
{
"Dhcp4": {
"expired-leases-processing": {
"reclaim-timer-wait-time": 3,
"max-reclaim-leases": 100,
"max-reclaim-time": 50,
"unwarned-reclaim-cycles": 10
}
}
}
168u
168u
در این مثال، پارامتر max-reclaim-leases تعداد اجاره‌های بازپس‌گرفته‌شده در یک چرخه واحد را به 100 محدود می‌کند و max-reclaim-time حداکثر مدت زمان هر چرخه را به 50 میلی‌ثانیه محدود می‌سازد. در صورت رسیدن به هر یک از این محدودیت‌ها، چرخه بازپس‌گیری اجاره متوقف خواهد شد. بازپس‌گیری هرگونه اجاره بازپس‌گرفته‌نشده در چرخه‌های بعدی انجام خواهد گرفت.
نمودار زیر رفتار سامانه را در حضور تعداد زیادی اجاره منقضی‌شده، زمانی که محدودیت‌ها بر چرخه‌های بازپس‌گیری اعمال شده‌اند، نشان می‌دهد:
0.0
3.5
| c1 | | c2 | | c3 | | c4 |
|<-->|<-------------->|<-->|<-------------->|<-->|<-------------->|<-->|<--
------------------------------------------------------------------------------>
|50ms| 3s |50ms| 3s |50ms| 3s |50ms| time
168u
168u
در این حالت، اگر هر چرخه بازپس‌گیری بیش از 50 میلی‌ثانیه طول بکشد، بر اساس مقدار max-reclaim-time متوقف می‌شود. این موضوع باعث برابری مدت زمان تمام چرخه‌های بازپس‌گیری در طول زمان می‌گردد. در این مثال، به محدودیت حداکثر 100 اجاره دسترسی پیدا نمی‌شود. این سناریو ممکن است زمانی رخ دهد که تراکنش‌های پایگاه‌داده یا calloutها در کتابخانه‌های قلاب متصل به کارگزار کند باشند. با این حال، مقادیر انتخاب‌شده برای حداکثر تعداد اجاره‌ها یا حداکثر زمان چرخه به شدت به نوع پیاده‌سازی، backend پایگاه‌داده اجاره مورد استفاده، کتابخانه‌های قلاب و غیره وابسته است. مدیران سیستم ممکن است برای تنظیم سامانه متناسب با شرایط استقرار خود، نیاز به آزمون و ارزیابی داشته باشند.
درک این نکته حائز اهمیت است که با اعمال این محدودیت‌ها، این خطر وجود دارد که اجاره‌های منقضی‌شده سریع‌تر از توانایی کارگزار در بازپس‌گیری آن‌ها انباشته شوند. اگر کارگزار با موج موقتی از انقضاها مواجه باشد مشکلی ایجاد نخواهد شد، چرا که می‌تواند به مرور زمان آن‌ها را پردازش کند. با این حال، اگر اجاره‌ها برای مدت طولانی با نرخ بالایی منقضی شوند، اجاره‌های بازپس‌گرفته‌نشده در پایگاه‌داده انباشته خواهند شد. به منظور مطلع ساختن مدیر سیستم از این موضوع که پیکربندی فعلی پاسخگوی نیازهای بازپس‌گیری اجاره‌های منقضی‌شده نیست، کارگزار در صورتی که نتواند تمام اجاره‌ها را طی چندین چرخه بازپس‌گیری کند، یک پیام هشدار در وقایع‌نگاری (log) صادر می‌کند. تعداد چرخه‌هایی که پس از آن‌ها چنین هشداری صادر می‌شود با پارامتر پیکربندی unwarned-reclaim-cycles تعیین می‌گردد.
تنظیم reclaim-timer-wait-time روی 0، بازپس‌گیری دوره‌ای اجاره‌های منقضی‌شده را غیرفعال می‌کند..SS "پیکربندی تمایل اجاره (Configuring Lease Affinity)"
فرض کنید یک لپ‌تاپ پس از مدتی عدم فعالیت کاربر به حالت خواب (sleep mode) می‌رود. در حالی که لپ‌تاپ در حالت خواب است، کلاینت DHCP آن اجاره‌های دریافت‌شده از سرور را تمدید نمی‌کند و این اجاره‌ها در نهایت منقضی خواهند شد. هنگامی که لپ‌تاپ بیدار می‌شود، اغلب مطلوب است که همچنان به استفاده از آدرس‌های IP قبلیِ اختصاص‌یافته به خود ادامه دهد. برای تسهیل این امر، سرور باید کلاینت‌های بازگشتی را با اجاره‌های منقضی‌شدهٔ آن‌ها مرتبط سازد. هنگامی که کلاینت بازمی‌گردد، سرور ابتدا وجود آن اجاره‌ها را بررسی کرده و در صورتی که به کلاینت دیگری اختصاص نیافته باشند، آن‌ها را دوباره اختصاص می‌دهد. توانایی سرور در اختصاص مجدد همان اجاره به یک کلاینت بازگشتی، "تمایل اجاره" (lease affinity) نامیده می‌شود.
هنگامی که تمایل اجاره فعال باشد (یعنی زمانی که hold-reclaimed-time روی مقداری بزرگ‌تر از صفر پیکربندی شده باشد)، سرور همچنان اجاره‌ها را بر اساس پارامترهای شرح‌داده‌شده در بخش پیکربندی بازپس‌گیری اجاره (Configuring Lease Reclamation) بازپس می‌گیرد، اما اجاره‌های بازپس‌گرفته‌شده به جای حذف شدن، برای مدت‌زمان مشخصی در پایگاه داده نگهداری می‌شوند. اگر هر دو پارامتر flush-reclaimed-timer-wait-time و hold-reclaimed-time بزرگ‌تر از صفر باشند، زمانی که کلاینت یک پیام آزادسازی (release) ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره‌ها، بلافاصله منقضی می‌شود. هنگامی که کلاینت بازمی‌گردد، سرور ابتدا بررسی می‌کند که آیا اجارهٔ بازپس‌گرفته‌شده‌ای مرتبط با این کلاینت وجود دارد یا خیر و سپس در صورت امکان آن‌ها را دوباره اختصاص می‌دهد. با این حال، توجه به این نکته مهم است که هر اجارهٔ بازپس‌گرفته‌شده در صورتی که کلاینت دیگری مشخصاً آن را درخواست کند، ممکن است به آن کلاینت اختصاص یابد. بنابراین، تمایل اجاره تضمین نمی‌کند که اجارهٔ بازپس‌گرفته‌شده در دسترس کلاینتی که قبلاً از آن استفاده می‌کرده قرار گیرد؛ بلکه صرفاً احتمال اختصاص همان اجاره به کلاینت را افزایش می‌دهد. اگر استخر اجاره (lease pool) کوچک باشد - به‌ویژه در DHCPv4 که فضای آدرس محدود است - احتمال این‌که اجارهٔ منقضی‌شده به کلاینت دیگری اختصاص یابد افزایش می‌یابد.
پیکربندی زیر را در نظر بگیرید:
0.0
3.5
"Dhcp4": {
"expired-leases-processing": {
"reclaim-timer-wait-time": 3,
"hold-reclaimed-time": 1800,
"flush-reclaimed-timer-wait-time": 5
},
...
}
168u
168u
پارامتر hold-reclaimed-time مشخص می‌کند که یک اجارهٔ بازپس‌گرفته‌شده چند ثانیه پس از انقضا باید برای تخصیص مجدد به همان کلاینت در پایگاه داده نگهداری شود. در مثال فوق، اجاره‌های بازپس‌گرفته‌شده به مدت ۳۰ دقیقه (۱۸۰۰ ثانیه) پس از انقضایشان نگهداری می‌شوند. در طول این مدت، به احتمال زیاد سرور قادر خواهد بود همان اجاره را به کلاینت بازگشتی اختصاص دهد، مگر اینکه کلاینت دیگری صراحتاً این اجاره را درخواست کند و سرور آن را واگذار نماید.
سرور باید به‌صورت دوره‌ای اجاره‌های بازپس‌گرفته‌شده‌ای را که زمان مشخص‌شده توسط hold-reclaimed-time برای آن‌ها سپری شده است، حذف کند. پارامتر flush-reclaimed-timer-wait-time کنترل می‌کند که سرور هر چند وقت یک‌بار این‌گونه اجاره‌ها را حذف نماید. در مثال ارائه‌شده در بالا، سرور پنج ثانیه پس از تکمیل تلاش قبلی برای حذف، اقدام به حذف چنین اجاره‌هایی می‌کند. تنظیم این مقدار روی 0 تمایل اجاره را غیرفعال می‌کند، به این معنی که اجاره‌ها به محض بازپس‌گیری از پایگاه دادهٔ اجاره‌ها حذف می‌شوند. در صورت فعال بودن تمایل اجاره، توصیه می‌شود که hold-reclaimed-time روی مقداری به‌مراتب بالاتر از reclaim-timer-wait-time تنظیم شود، زیرا حذف به‌موقع اجاره‌های منقضی/بازپس‌گرفته‌شده اهمیت کمتری نسبت به خودِ فرایند حذف دارد که می‌تواند بر پاسخ‌دهی سرور تأثیر بگذارد.
هیچ تضمینی وجود ندارد که تمایل اجاره همیشه کار کند؛ اگر سرور با کمبود آدرس مواجه شود، آدرس‌های منقضی‌شده را به کلاینت‌های جدید اختصاص خواهد داد. همچنین، کلاینت‌ها می‌توانند آدرس‌های خاصی را درخواست کنند و سرور در صورت امکان سعی می‌کند چنین درخواست‌هایی را برآورده سازد. مدیرانی که می‌خواهند مطمئن شوند یک کلاینت آدرس خود را حتی پس از دوره‌های عدم فعالیت حفظ می‌کند، باید استفاده از رزروهای میزبان (host reservations) یا اجاره‌هایی با طول عمر بسیار طولانی را در نظر بگیرند.
"بازپس‌گیری اجاره‌های منقضی‌شده از طریق فرمان (Reclaiming Expired Leases via Command)"
دستور leases-reclaim <#std-isccmd-leases-reclaim> می‌تواند برای راه‌اندازی بازپس‌گیری اجاره در هر زمان استفاده شود. لطفاً برای جزئیات مربوط به نحوهٔ استفاده از این دستور، به بخش The leases-reclaim Command <#command-leases-reclaim> مراجعه کنید.
"مدیریت ازدحام (CONGESTION HANDLING)"
"ازدحام چیست؟ (What is Congestion?)"
ازدحام زمانی رخ می‌دهد که پرس‌وجوهای کلاینت‌ها با سرعتی فراتر از توان پردازش آن‌ها به سرورها سرازیر شوند. در نتیجه، سرورها شروع به انباشت صف معوقه‌ای از پرس‌وجوهای معلق می‌کنند. هرچه نرخ بالای ترافیک بیشتر ادامه یابد، سرورها عقب‌تر می‌مانند. بسته به پیاده‌سازی‌های کلاینت، کلاینت‌هایی که موفق به دریافت اجاره نمی‌شوند یا منصرف می‌شوند یا به‌سادگی برای همیشه به تلاش مجدد ادامه می‌دهند. در حالت اول، سرور ممکن است در نهایت بازیابی شود، اما حالت دوم یک چرخه معیوب است که سرور قادر به رهایی از آن نیست.
ازدحام معمولاً زمانی رخ می‌دهد که یک رخداد شبکه‌ای سبب شود تعداد بیش از حد زیادی از کلاینت‌ها به‌طور هم‌زمان به اجاره نیاز پیدا کنند؛ مانند بازیابی پس از قطعی شبکه. در یک استقرار خوب برنامه‌ریزی‌شده، تعداد و ظرفیت سرورها با حداکثر بار مورد انتظار کلاینت‌ها تطابق داده می‌شود. اگر بار به‌طور معمول بیش از حد سنگین باشد، باید در استقرار بازنگری شود.
هدف از مدیریت ازدحام، کمک به سرورها در کاهش اثر پیک ترافیک با پاسخ‌گویی به بیشترین تعداد ممکن از مرتبط‌ترین درخواست‌ها است تا زمانی که ازدحام فروکش کند.
"پیکربندی مدیریت ازدحام (Configuring Congestion Handling)"
مدیریت ازدحام این امکان را فراهم می‌کند که سرور به‌گونه‌ای پیکربندی شود تا از یک رشته (thread) جداگانه برای خواندن بسته‌ها از بافرهای سوکت رابط استفاده کند. با خواندن بسته‌ها از بافرها توسط این رشته، آن‌ها به یک صف بستهٔ داخلی اضافه می‌شوند و رشتهٔ برنامهٔ اصلی سرور، بسته‌ها را به جای بافرهای سوکت از این صف پردازش می‌کند. با ساختاربندی به این روش، لایه‌ای قابل‌پیکربندی معرفی شده است که می‌تواند در مورد اینکه کدام بسته‌ها پردازش شوند، چگونه ذخیره گردند، و ترتیبی که توسط سرور پردازش می‌شوند تصمیم‌گیری کند.
پیاده‌سازی پیش‌فرض صف بسته برای هر دو kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> یک بافر حلقوی (ring buffer) ساده است. هنگامی که ظرفیت آن تکمیل شود، بسته‌های جدید با دور انداختن بسته‌ها از ابتدای صف، به انتهای صف اضافه می‌شوند. به جای دور انداختن همیشگی جدیدترین بسته‌ها، Kea اکنون همواره قدیمی‌ترین بسته‌ها را دور می‌اندازد. ظرفیت بافر، یعنی حداکثر تعداد بسته‌هایی که بافر می‌تواند در بر گیرد، قابل‌پیکربندی است. یک نقطهٔ شروع منطقی این است که ظرفیت را با تعداد اجاره‌ها بر ثانیه که یک نصب خاص از Kea می‌تواند مدیریت کند، تطبیق داد. این رقم بسته به مشخصات هر استقرار بسیار متغیر است.
از آنجا که هیچ الگوریتم یگانه‌ای وجود ندارد که بتواند پویایی همهٔ سایت‌ها را به بهترین شکل مدیریت کند، و با گذشت زمان رویکردهای جدیدی توسعه خواهند یافت، صف بسته به صورت یک پلاگین پیاده‌سازی شده است که می‌تواند با یک پیاده‌سازی صف سفارشی از طریق یک کتابخانهٔ قلاب (hook library) جایگزین شود. این امر باید آزمایش راه‌حل‌های اختصاصی را برای افراد علاقه‌مند ساده سازد. (توسعه‌دهندگان می‌توانند به isc::dhcp::PacketQueue و isc::dhcp::PacketQueueMgr که در راهنمای توسعه‌دهندهٔ Kea (Kea Developer's Guide) https://reports.kea.isc.org/dev_guide/index.html شرح داده شده‌اند مراجعه کنند.)
رفتار صف بسته در هر دو سرور kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> از طریق یک عنصر پیکربندی اختیاری در بالاترین سطح، یعنی dhcp-queue-control پیکربندی می‌شود. حذف این عنصر صف‌بندی بسته‌ها را غیرفعال می‌کند:
0.0
3.5
"dhcp-queue-control": {
"enable-queue": true, // true|false
"queue-type": "queue type",
"capacity" : 256 // n packets
}
168u
168u
که در آن:
0.0
• 2
enable-queue - صف‌بندی بسته‌ها را فعال یا غیرفعال می‌کند. هنگامی که مقدار آن true باشد، سرور بسته‌ها را از صف بسته که توسط یک رشتهٔ جداگانه پر می‌شود پردازش می‌کند. هنگامی که false باشد، سرور بسته‌ها را مستقیماً از بافرهای سوکت در رشتهٔ اصلی پردازش می‌نماید. این گزینه به‌طور پیش‌فرض غیرفعال (false) است.
• 2
queue-type - نام پیاده‌سازی صف مورد استفاده. این مقدار به این منظور وجود دارد که بتوان پیاده‌سازی‌های سفارشی را (از طریق یک کتابخانهٔ قلاب) ثبت و سپس انتخاب کرد. یک پیاده‌سازی پیش‌فرض صف بسته وجود دارد که هنگام راه‌اندازی سرور از پیش ثبت شده است: "kea-ring4" برای kea-dhcp4 <#std-iscman-kea-dhcp4> و "kea-ring6" برای kea-dhcp6 <#std-iscman-kea-dhcp6>.
• 2
capacity - این پارامتر حداکثر تعداد بسته‌هایی است که صف می‌تواند پیش از دور انداختن بسته‌ها در خود نگه دارد. مقدار بهینه برای این گزینه به‌شدت به ساختار سایت وابسته است. مقدار پیش‌فرض برای هر دو "kea-ring4" و "kea-ring6" برابر با 64 است.
168u
مثال زیر صف بستهٔ پیش‌فرض را برای kea-dhcp4 <#std-iscman-kea-dhcp4> با ظرفیت صف 250 بسته فعال می‌کند:
0.0
3.5
"Dhcp4":
{
"dhcp-queue-control": {
"enable-queue": true,
"queue-type": "kea-ring4",
"capacity" : 250
},
...
}
168u
168u
مثال زیر صف بستهٔ پیش‌فرض را برای kea-dhcp6 <#std-iscman-kea-dhcp6> با ظرفیت صف 300 بسته فعال می‌کند:
0.0
3.5
"Dhcp6":
{
"dhcp-queue-control": {
"enable-queue": true,
"queue-type": "kea-ring6",
"capacity" : 300
},
...
}
168u
168u
نکته:
0.0
3.5
مدیریت ازدحام در حال حاضر با چندرشتگی (multi-threading) ناسازگار است؛ هنگامی که هر دو فعال باشند، مدیریت ازدحام در سکوت غیرفعال می‌شود.
168u
"نمای کلی (Overview)"
کارساز DHCP-DDNS (kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>، که به‌طور غیررسمی با نام D2 شناخته می‌شود) سمت کلاینت پروتکل DNS پویا (DDNS، تعریف‌شده در RFC 2136 https://datatracker.ietf.org/doc/html/rfc2136) را به نیابت از کارسازهای DHCPv4 و DHCPv6 (به‌ترتیب kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6>) مدیریت می‌کند. کارسازهای DHCP بر اساس رویدادهای تغییر اجاره در DHCP، درخواست‌های به‌روزرسانی DDNS را که با عنوان درخواست‌های تغییر نام (NameChangeRequests یا NCRs) شناخته می‌شوند ایجاد کرده و سپس به D2 ارسال می‌کنند. D2 تلاش می‌کند هر درخواست را با کارساز(های) DNS مناسب تطبیق دهد و تبادل لازم را با آن کارسازها برای به‌روزرسانی داده‌های DNS به انجام برساند.
کتابخانهٔ قلاب (hook) در Kea به نام libdhcp_ddns_tuning.so <#std-ischooklib-libdhcp_ddns_tuning.so> این امکان را برای هر دو کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> فراهم می‌کند تا نام‌های میزبان را به‌صورت رویه‌ای بر اساس یک عبارت تولید کنند، به‌روزرسانی‌های DDNS را به‌ازای هر کلاینت نادیده بگیرند، یا جنبه‌های مختلف به‌روزرسانی DNS را به‌دقت تنظیم نمایند. لطفاً برای گزینه‌های پیکربندی به مستندات libdhcp_ddns_tuning.so: DDNS Tuning <#hooks-ddns-tuning> مراجعه کنید.
"انتخاب کارساز DNS (DNS Server Selection)"
برای مطابقت دادن یک درخواست با کارسازهای DNS مناسب، D2 باید کاتالوگی از کارسازها داشته باشد تا از میان آن‌ها انتخاب کند. در واقع، D2 دو کاتالوگ از این دست دارد: یکی برای DNS مستقیم (forward) و دیگری برای DNS معکوس (reverse)؛ به این کاتالوگ‌ها «فهرست‌های دامنه‌های DDNS» ("DDNS domain lists") گفته می‌شود. هر فهرست از یک یا چند دامنهٔ نام‌گذاری‌شدهٔ DDNS تشکیل شده است. علاوه بر این، هر دامنهٔ DDNS فهرستی از یک یا چند کارساز DNS دارد که داده‌های DNS آن دامنه را منتشر می‌کنند.
هنگام انجام تطبیق دامنهٔ مستقیم، D2 نام دامنهٔ کاملاً مشخص (FQDN) موجود در درخواست را با نام هر یک از دامنه‌های DDNS مستقیم در کاتالوگ خود مقایسه می‌کند. دامنه‌ای که نام آن با طولانی‌ترین بخش از FQDN مطابقت داشته باشد، بهترین تطابق در نظر گرفته می‌شود. به عنوان مثال، اگر FQDN برابر با "myhost.sample.example.com." باشد و دو دامنهٔ مستقیم در کاتالوگ به نام‌های "sample.example.com." و "example.com." وجود داشته باشد، مورد اول بهترین تطابق محسوب می‌شود. در برخی موارد، ممکن است یافتن تطابق مناسب امکان‌پذیر نباشد. با فرض وجود همان دو دامنهٔ مستقیم، هیچ تطابقی برای FQDN با مقدار "bogus.net" وجود نخواهد داشت، بنابراین درخواست رد خواهد شد. در نهایت، اگر هیچ دامنهٔ DDNS مستقیمی تعریف نشده باشد، D2 به‌سادگی بخش به‌روزرسانی مستقیم درخواست‌ها را نادیده می‌گیرد.
هنگام انجام تطبیق دامنهٔ معکوس، D2 یک FQDN معکوس از آدرس اجاره در درخواست می‌سازد و آن را با نام هر دامنهٔ DDNS معکوس مقایسه می‌کند. مجدداً، دامنه‌ای که نام آن با طولانی‌ترین بخش از FQDN مطابقت داشته باشد، بهترین تطابق به شمار می‌آید. برای نمونه، اگر آدرس اجاره "172.16.1.40" باشد و دو دامنهٔ معکوس در کاتالوگ با نام‌های "1.16.172.in-addr.arpa." و "16.172.in-addr.arpa" وجود داشته باشند، مورد اول بهترین تطابق است. همانند تطبیق مستقیم، ممکن است D2 تطابق مناسبی پیدا نکند. با فرض وجود همان دو دامنه، هیچ تطابقی برای آدرس اجارهٔ "192.168.1.50" وجود نخواهد داشت و درخواست رد خواهد شد. همانند تطبیق دامنهٔ مستقیم، اگر هیچ دامنهٔ DDNS معکوسی تعریف نشده باشد، D2 به‌سادگی بخش به‌روزرسانی معکوس درخواست‌ها را نادیده می‌گیرد.
"رفع تعارض (Conflict Resolution)"
D2 راهبرد رفع تعارض تجویز‌شده توسط RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703 را پیاده‌سازی می‌کند. هدف از رفع تعارض، جلوگیری از نگاشت هم‌زمان کلاینت‌های مختلف به یک FQDN یکسان است. برای ممکن ساختن این امر، RFC الزامی می‌داند که مدخل‌های DNS مستقیم برای یک FQDN مشخص باید همراه با یک رکورد منبع (RR) از نوع DHCID باشند. این رکورد شامل یک شناسهٔ کلاینت است که کلاینت متعلق به آن نام را به‌صورت یکتا مشخص می‌کند. علاوه بر این، هر به‌روزرسان DNS که بخواهد مدخل‌های مستقیم موجود برای یک FQDN را به‌روزرسانی یا حذف کند، تنها در صورتی مجاز به انجام این کار است که کلاینت آن با رکورد DHCID RR همخوانی داشته باشد.
به عبارت دیگر، DHCID RR یک FQDN را به کلاینتی که به آن تعلق دارد نگاشت می‌کند و پس از آن، تغییرات در آن نگاشت تنها توسط آن کلاینت یا به درخواست آن امکان‌پذیر است.
رفع تعارض می‌تواند به‌طور غیرمستقیم از طریق پارامتر پیکربندی ddns-use-conflict-resolution که توسط هر دو کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> پشتیبانی می‌شود، فعال یا غیرفعال گردد. این کارسازها از این پارامتر برای تنظیم یک پرچم در هر NameChangeRequest ارسالی استفاده می‌کنند که به D2 اعلام می‌کند آیا باید رفع تعارض برای آن درخواست اعمال شود یا خیر. به‌طور پیش‌فرض، رفع تعارض فعال است. برای جزئیات بیشتر، لطفاً به مباحث مربوط به ddns-use-conflict-resolution در DDNS for DHCPv4 <#dhcp4-ddns-config> و DDNS for DHCPv6 <#dhcp6-ddns-config> مراجعه کنید.
هنگامی که رفع تعارض غیرفعال باشد، D2 همچنان رکوردهای DHCID RR را اضافه می‌کند اما از آن‌ها برای اعمال مالکیت کلاینت بر مدخل‌های DNS استفاده نمی‌کند. غیرفعال کردن آن تنها پس از بررسی دقیق باید انجام شود.
"محیط‌های دو پشته‌ای (Dual-Stack Environments)"
بخش ۵.۲ از RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703#section-5.2 مسائلی را توصیف می‌کند که ممکن است با کلاینت‌های دو پشته‌ای (dual-stack) رخ دهد. این‌ها کلاینت‌هایی هستند که تمایل دارند هر دو نگاشت IPv4 و IPv6 را برای یک FQDN یکسان داشته باشند. برای عملکرد صحیح، کلاینت‌ها باید DUID مربوط به IPv6 خود را در گزینهٔ شناسهٔ کلاینت IPv4 بگنجانند، همان‌طور که در RFC 4361 https://datatracker.ietf.org/doc/html/rfc4361 تشریح شده است. بدین ترتیب، به‌روزرسانی‌های DNS هم برای IPv4 و هم برای IPv6 می‌توانند تحت یک رکورد DHCID RR یکسان مدیریت شوند. این ویژگی از نگارش 2.1.2 به بعد در Kea پشتیبانی می‌شود.
"راه‌اندازی و متوقف‌کردن کارساز DHCP-DDNS (Starting and Stopping the DHCP-DDNS Server)"
برنامهٔ kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> کارساز DHCP-DDNS در Kea است و با توجه به ماهیت DDNS، در کنار مؤلفهٔ DHCPv4 یا DHCPv6 (یا هر دو) اجرا می‌شود. مانند سایر بخش‌های Kea، این برنامه یک باینری مجزا است که می‌تواند به صورت مستقل یا از طریق keactrl <#std-iscman-keactrl> اجرا شود (ببینید Managing Kea with keactrl <#keactrl>). در حالت عادی، کنترل کردن kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> با keactrl <#std-iscman-keactrl> توصیه می‌شود؛ با این حال، اجرای مستقیم کارساز DHCP-DDNS نیز امکان‌پذیر است. این برنامه سوئیچ‌های خط فرمان زیر را می‌پذیرد:
0.0
• 2
-c file - فایل پیکربندی را مشخص می‌کند. این تنها سوئیچ الزامی است.
• 2
-d - مشخص می‌کند که آیا ثبت وقایع (لاگین) کارساز باید به حالت اشکال‌زدایی/پُرگویی (debug/verbose) تغییر کند یا خیر. در حالت پُرگو، سطح اهمیت ثبت وقایع و debuglevel مشخص‌شده در فایل پیکربندی نادیده گرفته می‌شوند و سطح اهمیت "debug" و حداکثر debuglevel یعنی (99) در نظر گرفته می‌شود. این پرچم برای تغییر موقت کارساز به بیشترین حد پُرگویی، مثلاً هنگام اشکال‌زدایی، مناسب است.
• 2
-t file - فایل پیکربندی را برای آزمایش مشخص می‌کند. kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> تلاش می‌کند آن را بارگذاری کرده و بررسی‌های سلامت را انجام دهد. برخی بررسی‌ها تنها هنگام اجرای کارساز واقعی امکان‌پذیر است. وضعیت واقعی با یک کد خروج گزارش می‌شود (0 = پیکربندی مناسب به نظر می‌رسد، 1 = خطا رخ داده است). هنگام آزمایش پیکربندی، Kea پیام‌های لاگ را در خروجی استاندارد و خطاها را در خطای استاندارد چاپ می‌کند.
• 2
-v - نگارش Kea را نمایش داده و خارج می‌شود.
• 2
-V - نگارش تفصیلی Kea را نمایش داده و خارج می‌شود.
• 2
-W - گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش رونوشتی از فایل config.report تولیدشده توسط meson setup است؛ این گزارش درون باینری اجرایی جاسازی شده است.
محتویات فایل config.report همچنین از طریق بررسی کتابخانه‌های خاصی در درخت نصب یا در درخت سورس قابل دسترسی است.
2.0
3.5
# from installation using libkea-process.so
$ strings ${prefix}/lib/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.so
$ strings src/lib/process/.libs/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.a
$ strings src/lib/process/.libs/libkea-process.a | sed -n 's/;;;; //p'
# from sources using libcfgrpt.a
$ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed -n 's/;;;; //p'
168u
168u
• 2
-X - از نسخهٔ Kea 3.0، محدودیت‌های امنیتی را غیرفعال می‌کند. کارساز همچنان نقض‌ها را بررسی می‌کند اما به جای شکست همراه با خطا، هنگام یافتن آن‌ها پیام‌های هشدار ثبت خواهد کرد. لطفاً برای جزئیات به Kea Runtime Security Policy Checking <#sec-kea-runtime-security-policy-checking> مراجعه کنید.
168u
پس از راه‌اندازی، ماژول پیکربندی خود را بارگذاری کرده و بر اساس آن پیکربندی، گوش‌دادن به NCRها را آغاز می‌کند.
در حین راه‌اندازی، کارساز تلاش می‌کند یک فایل PID به این شکل ایجاد کند: [pidfile_dir]/[conf name].kea-dhcp-ddns.pid که در آن:
0.0
• 2
pidfile_dir - برابر است با [prefix]/[localstatedir]/run/kea که در آن prefix و localstatedir مقادیری هستند که با استفاده از --prefix و --localstatedir به meson setup ارسال شده‌اند و به‌ترتیب به‌طور پیش‌فرض /usr/local و var می‌باشند. بنابراین کل مسیر pidfile_dir به‌طور پیش‌فرض /usr/local/var است. توجه داشته باشید که این مقدار ممکن است در زمان اجرا با تنظیم متغیر محیطی KEA_PIDFILE_DIR که در درجهٔ اول برای اهداف آزمایشی در نظر گرفته شده است، بازنویسی شود.
• 2
conf name - نام فایل پیکربندی استفاده‌شده برای راه‌اندازی کارساز است، منهای تمام مسیرهای پیش از آن و پسوند فایل. برای مثال، با داشتن مسیر /usr/local/etc/kea/myconf.txt، بخش مورداستفاده myconf خواهد بود.
168u
اگر فایل از قبل موجود باشد و حاوی PID یک فرایند زنده باشد، کارساز پیام ثبت وقایع DHCP_DDNS_ALREADY_RUNNING را صادر کرده و خارج می‌شود. این احتمال وجود دارد (هرچند بعید) که این فایل بازماندهٔ یک فروپاشی سیستم باشد و فرایندی که PID متعلق به آن است به Kea نامربوط باشد. در چنین حالتی، حذف دستی فایل PID ضروری است..SS پیکربندی کارگزار DHCP-DDNS
پیش از راه‌اندازی ماژول kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> برای نخستین بار، باید یک فایل پیکربندی ایجاد شود. پیکربندی پیش‌فرض زیر قالبی است که می‌تواند بر اساس نیازهای اختصاصی سفارشی‌سازی شود.
0.0
3.5
"DhcpDdns": {
"ip-address": "127.0.0.1",
"port": 53001,
"dns-server-timeout": 500,
"ncr-protocol": "UDP",
"ncr-format": "JSON",
"tsig-keys": [ ],
"forward-ddns": {
"ddns-domains": [ ]
},
"reverse-ddns": {
"ddns-domains": [ ]
}
}
168u
168u
پیکربندی را می‌توان به بخش‌های زیر تقسیم کرد که هر یک در ادامه توضیح داده شده‌اند:
0.0
• 2
پارامترهای سراسری کارگزار (Global Server Parameters) - مقادیری را تعریف می‌کند که برقراری ارتباط و رفتار سراسری کارگزار را کنترل می‌کنند.
• 2
سوکت‌های کنترلی (Control Sockets) - فهرست سوکت‌های کنترلی را تعریف می‌کند.
• 2
اطلاعات کلید TSIG (TSIG Key Info) - کلیدهای TSIG مورد استفاده برای تبادل امن داده با کارگزارهای DNS را تعریف می‌کند.
• 2
DDNS مستقیم (Forward DDNS) - فهرست دامنه‌های DDNS مستقیم را تعریف می‌کند.
• 2
DDNS معکوس (Reverse DDNS) - فهرست دامنه‌های DDNS معکوس را تعریف می‌کند.
168u
پارامترهای سراسری کارگزار (Global Server Parameters)
0.0
• 2
ip-address - نشانی IP که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض، رابط محلی loopback روی نشانی 127.0.0.1 است. می‌توان یک نشانی IPv4 یا IPv6 تعیین کرد.
• 2
port - درگاهی (port) که D2 روی آن به درخواست‌ها گوش می‌دهد. مقدار پیش‌فرض 53001 است.
• 2
dns-server-timeout - حداکثر زمانی (بر حسب میلی‌ثانیه) که D2 برای دریافت پاسخ از کارگزار DNS برای یک پیام به‌روزرسانی منفرد DNS منتظر می‌ماند. مقدار پیش‌فرض 500 میلی‌ثانیه است.
• 2
ncr-protocol - پروتکل سوکت مورد استفاده هنگام ارسال درخواست‌ها به D2. در حال حاضر فقط UDP پشتیبانی می‌شود.
• 2
ncr-format - قالب بسته مورد استفاده هنگام ارسال درخواست‌ها به D2. در حال حاضر فقط قالب JSON پشتیبانی می‌شود.
168u
D2 باید روی یک نشانی و درگاه مشخص به درخواست‌های تغییر گوش دهد. به‌طور پیش‌فرض، روی 127.0.0.1 و درگاه 53001 گوش می‌دهد. مثال زیر نشان می‌دهد که چگونه می‌توان پارامترهای سراسری D2 را تغییر داد تا روی 192.168.1.10 و درگاه 900 گوش دهد:
0.0
3.5
"DhcpDdns": {
"ip-address": "192.168.1.10",
"port": 900,
...
}
168u
168u
هشدار:
0.0
3.5
این امکان وجود دارد که یک مهاجم مخرب درخواست‌های جعلی NameChangeRequests را به کارگزار DHCP-DDNS ارسال کند. نشانی‌هایی غیر از نشانی‌های loopback در IPv4 یا IPv6 (یعنی 127.0.0.1 یا ::1) باید صرفاً برای مقاصد آزمایشی استفاده شوند؛ توجه داشته باشید که کاربران محلی همچنان می‌توانند با کارگزار DHCP-DDNS ارتباط برقرار کنند.
168u
168u
نکته:
0.0
3.5
اگر ip-address و port تغییر کنند، مقادیر متناظر در بخش پیکربندی dhcp-ddns در کارگزارهای DHCP نیز باید تغییر یابند.
168u
168u
رابط برنامه‌نویسی مدیریت (Management API) برای کارگزار D2
رابط برنامه‌نویسی مدیریت امکان صدور دستورهای مدیریتی مشخص، مانند بازخوانی پیکربندی یا خاموش کردن را فراهم می‌کند. برای جزئیات بیشتر، Management API <#ctrl-channel> را ببینید. به‌طور پیش‌فرض هیچ سوکتی باز نیست؛ برای این‌که به Kea دستور دهید سوکتی را باز کند، می‌توان از مدخل زیر در فایل پیکربندی استفاده کرد:
0.0
3.5
"DhcpDdns": {
"control-sockets": [
{
"socket-type": "unix",
"socket-name": "/path/to/the/unix/socket"
}
],
...
}
168u
تا قبل از سرور Kea نسخهٔ 2.7.2، تنها نوع کانال ارتباطی پشتیبانی‌شده سوکت جریان UNIX با مقداردهی socket-type به unix و socket-name به مسیر فایل سوکت UNIX/LOCAL بود.
طول مسیر مشخص‌شده توسط پارامتر socket-name به حداکثر طول مجاز برای نام سوکت UNIX در سیستم‌عامل، یعنی اندازهٔ فیلد sun_path در ساختار sockaddr_un منهای ۱، محدود است. این مقدار در سیستم‌عامل‌های مختلف بین ۹۱ تا ۱۰۷ نویسه متغیر است. مقادیر معمول ۱۰۷ در Linux و ۱۰۳ در FreeBSD هستند.
نرم‌افزار Kea تنها از یک سوکت کنترلی unix در فهرست "control-sockets" پشتیبانی می‌کند.
نکته:
0.0
3.5
از نسخهٔ 2.7.9 در Kea، سوکت‌های کنترلی فقط می‌توانند در دایرکتوری تعیین‌شده در زمان کامپایل یعنی "[kea-install-dir]/var/run/kea" قرار گیرند که این مسیر نیز باید دارای مجوزهای دسترسی 0750 باشد. این مسیر را می‌توان هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_CONTROL_SOCKET_DIR به مسیر دلخواه بازنویسی (override) کرد. اگر مسیری غیر از این مقدار در socket-name استفاده شود، Kea خطایی صادر کرده و از شروع به کار امتناع می‌کند، یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. برای سهولت در استفاده، کافی است بخش مسیر را از socket-name حذف کنید.
168u
168u
ارتباط از طریق کانال کنترلی با استفاده از ساختارهای JSON انجام می‌شود. برای جزئیات بیشتر به بخش Control Channel در Kea Developer's Guide https://reports.kea.isc.org/dev_guide/d2/d96/ctrlSocket.html مراجعه کنید.
سرور D2 از دستورهای عملیاتی زیر پشتیبانی می‌کند:
0.0
• 2
build-report <#std-isccmd-build-report>
• 2
config-get <#std-isccmd-config-get>
• 2
config-hash-get <#std-isccmd-config-hash-get>
• 2
config-reload <#std-isccmd-config-reload>
• 2
config-set <#std-isccmd-config-set>
• 2
config-test <#std-isccmd-config-test>
• 2
config-write <#std-isccmd-config-write>
• 2
list-commands <#std-isccmd-list-commands>
• 2
shutdown <#std-isccmd-shutdown>
• 2
status-get <#std-isccmd-status-get>
• 2
version-get <#std-isccmd-version-get>
168u
از نسخهٔ 2.0.0 در Kea، سرور D2 از دستورهای عملیاتی زیر نیز برای آمار پشتیبانی می‌کند:
0.0
• 2
statistic-get <#std-isccmd-statistic-get>
• 2
statistic-get <#std-isccmd-statistic-get>-all
• 2
statistic-reset <#std-isccmd-statistic-reset>
• 2
statistic-reset <#std-isccmd-statistic-reset>-all
168u
دستور shutdown <#std-isccmd-shutdown> از آرگومان اضافی type پشتیبانی می‌کند که نحوهٔ پاک‌سازی سرور D2 هنگام خروج را کنترل می‌کند. انواع خاموش‌سازی پشتیبانی‌شده عبارتند از:
0.0
• 2
normal - مدیر صف را متوقف کرده و قبل از خروج، تمام تراکنش‌های جاری را به پایان می‌رساند. این مقدار پیش‌فرض است.
• 2
drain_first - مدیر صف را متوقف می‌کند، اما به پردازش درخواست‌ها از صف تا خالی شدن آن ادامه می‌دهد.
• 2
now - بلافاصله خارج می‌شود.
168u
یک دستور نمونه می‌تواند به این صورت باشد:
0.0
3.5
{
"command": "shutdown",
"arguments": {
"exit-value": 3,
"type": "drain_first"
}
}
168u
168u
سوکت کنترلی HTTP/HTTPS
مقدار socket-type باید http یا https باشد (هنگامی که نوع آن https باشد، TLS الزامی است). پارامترهای socket-address (پیش‌فرض 127.0.0.1) و socket-port (پیش‌فرض 8000) آدرس IP و درگاهی را مشخص می‌کنند که سرویس HTTP به آن متصل (bind) خواهد شد.
پارامترهای trust-anchor، cert-file، key-file و cert-required پیکربندی TLS را برای HTTP، یعنی HTTPS، مشخص می‌کنند. اگر این پارامترها مشخص نشوند، از HTTP استفاده می‌شود. پشتیبانی از TLS/HTTPS در Kea در بخش TLS/HTTPS Support <#tls> شرح داده شده است.
احراز هویت پایه HTTP (Basic HTTP authentication) از سرور در برابر استفاده‌های غیرمجاز توسط کاربران محلی محافظت می‌کند. برای محافظت در برابر مهاجمان از راه دور، HTTPS و پراکسی معکوس (reverse proxy) امنیت قوی‌تری فراهم می‌کنند.
احراز هویت در بلوک authentication همراه با پارامتر اجباری type شرح داده می‌شود که روش احراز هویت را تعیین می‌کند. در حال حاضر تنها احراز هویت پایه HTTP (نوع basic) پشتیبانی می‌شود.
پارامتر احراز هویت realm (پیش‌فرض kea-dhcp-ddns-server) برای پیام‌های خطا در شرایطی استفاده می‌شود که احراز هویت پایه HTTP الزامی است اما کلاینت مجاز شناخته نشده است.
هنگامی که فهرست احراز هویت clients پیکربندی شده و خالی نباشد، احراز هویت پایه HTTP الزامی است. هر عنصر از فهرست، یک شناسه کاربری و یک گذرواژه را مشخص می‌کند. شناسه کاربری الزامی است، نباید خالی باشد و نباید حاوی نویسهٔ دونقطه (:) باشد. گذرواژه اختیاری است؛ در صورت عدم تعیین، گذرواژهٔ خالی استفاده می‌شود.
نکته:
0.0
3.5
شناسه کاربری و گذرواژه در احراز هویت پایه HTTP با استاندارد UTF-8 کدگذاری می‌شوند، اما نحو JSON کنونی Kea تنها از زیرمجموعه یونیکد Latin-1 (یعنی 0x00..0xff) پشتیبانی می‌کند.
168u
168u
برای جلوگیری از افشای شناسه کاربری و/یا گذرواژه مرتبط، می‌توان این مقادیر را از فایل‌ها خواند. نحو دستورها با موارد زیر گسترش یافته است:
0.0
• 2
پارامتر احراز هویت directory، که بخش مشترک مسیرهای فایل را مدیریت می‌کند. مقدار پیش‌فرض آن یک رشتهٔ خالی است.
• 2
پارامتر کلاینت password-file، که همراه با پارامتر directory، مسیر فایلی را مشخص می‌کند که می‌تواند حاوی گذرواژه باشد، یا در صورتی که هیچ شناسه کاربری داده نشده باشد، کل راز احراز هویت پایه HTTP را در بر گیرد.
• 2
پارامتر کلاینت user-file، که همراه با پارامتر directory، مسیر فایلی را مشخص می‌کند که شناسه کاربری از آن خوانده می‌شود.
168u
از نسخهٔ 2.7.6 در Kea، از چندین اتصال HTTP/HTTPS پشتیبانی می‌شود. هر دو نوع آدرس IPv4 و IPv6 قابل استفاده هستند. سرور در صورت تغییر نوع سوکت از HTTP به HTTPS یا از HTTPS به HTTP با استفاده از همان آدرس و درگاه، خطایی صادر خواهد کرد. این عمل مجاز نیست زیرا ممکن است موجب بروز یک مشکل امنیتی تصادفی ناشی از اشتباه کاربر شود. هنگام استفاده از دستور "config-set" برای تغییر از HTTP به HTTPS یا از HTTPS به HTTP، باید آدرس یا درگاه متفاوتی مشخص شود. همین موضوع هنگام تغییر فایل پیکربندی و سپس اجرای دستور "config-reload" نیز صدق می‌کند.
هنگامی که از فایل‌ها استفاده می‌شود، آن‌ها در زمان بارگذاری پیکربندی خوانده می‌شوند تا خطاهای پیکربندی در سریع‌ترین زمان ممکن شناسایی شوند.
0.0
3.5
"DhcpDdns": {
"control-sockets": [
{
"socket-type": "https",
"socket-address": "10.20.30.40",
"socket-port": 8005,
"trust-anchor": "/path/to/the/ca-cert.pem",
"cert-file": "/path/to/the/agent-cert.pem",
"key-file": "/path/to/the/agent-key.pem",
"cert-required": true,
"authentication": {
"type": "basic",
"realm": "kea-dhcp-ddns-server",
"clients": [
{
"user": "admin",
"password": "1234"
} ]
}
},
{
"socket-type": "http",
"socket-address": "2010:30:40::50",
"socket-port": 8004
}
],
...
}
168u
یک تبادل در پروتکل DDNS می‌تواند با یا بدون امضای تراکنش یا TSIG (تعریف‌شده
در RFC 2845 https://datatracker.ietf.org/doc/html/rfc2845) انجام شود. این
بخش از پیکربندی به مدیر سیستم امکان می‌دهد مجموعه‌ای از کلیدهای TSIG را
که ممکن است در چنین تبادلاتی استفاده شوند، تعریف کند.
برای استفاده از TSIG هنگام به‌روزرسانی مدخل‌ها در یک دامنهٔ DNS، باید یک کلید
در فهرست کلیدهای TSIG تعریف شده و با نام در مدخل پیکربندی آن دامنه به آن
ارجاع داده شود. هنگامی که D2 یک درخواست تغییر را با یک دامنه مطابقت می‌دهد،
بررسی می‌کند که آیا آن دامنه کلید TSIG مرتبطی دارد یا خیر. در صورت وجود، D2
از آن کلید برای امضای پیام‌های به‌روزرسانی DNS ارسالی به سرور(های) DNS دامنه
و اعتبارسنجی پاسخ‌های دریافتی از آن‌ها استفاده می‌کند. به ازای هر کلید TSIG مورد نیاز
سرورهای DNS که D2 با آن‌ها کار می‌کند، باید یک کلید TSIG متناظر در فهرست
کلیدهای TSIG وجود داشته باشد.
همان‌طور که ممکن است از نام آن مشخص باشد، بخش tsig-key در پیکربندی D2
کلیدهای TSIG را فهرست می‌کند. هر مدخل، یک کلید TSIG را توصیف می‌کند که توسط
یک یا چند سرور DNS برای احراز هویت درخواست‌ها و امضای پاسخ‌ها استفاده می‌شود.
هر مدخل در این فهرست سه پارامتر دارد:
0.0
• 2
name - یک برچسب متنی یکتا است که برای شناسایی این کلید در فهرست استفاده
می‌شود. این مقدار مشخص می‌کند که هنگام به‌روزرسانی یک دامنهٔ خاص، باید از کدام
کلید (در صورت وجود) استفاده شود. تا زمانی که این نام یکتا باشد محتوای آن اختیاری
است، اگرچه برای وضوح و سهولت در نگهداری توصیه می‌شود که با نام استفاده‌شده در
سرور(های) DNS مطابقت داشته باشد. این فیلد نمی‌تواند خالی باشد.
• 2
algorithm - مشخص می‌کند که کدام الگوریتم درهم‌سازی (هش) باید با این کلید
استفاده شود. این مقدار باید همان الگوریتمی را مشخص کند که برای کلید در
سرور(های) DNS به کار رفته است. الگوریتم‌های پشتیبانی‌شده در زیر فهرست شده‌اند:
2.0
• 2
HMAC-MD5
• 2
HMAC-SHA1
• 2
HMAC-SHA224
• 2
HMAC-SHA256
• 2
HMAC-SHA384
• 2
HMAC-SHA512
168u
این مقدار به حروف بزرگ و کوچک حساس نیست.
• 2
digest-bits - برای تعیین حداقل طول خلاصه‌سازی‌شده بر حسب بیت استفاده می‌شود.
مقدار پیش‌فرض 0 به این معنی است که کوتاه‌سازی ممنوع است؛ مقادیر غیرصفر باید یک عدد
صحیح از هشت‌بیت‌ها (اکتت‌ها) بوده و هم از 80 و هم از نصف طول کامل بزرگ‌تر باشند.
(توجه داشته باشید که در BIND 9 این پارامتر بعد از یک خط تیره به انتهای نام الگوریتم اضافه می‌شود.)
• 2
secret - برای تعیین کد کلید مخفی مشترک (shared secret) برای این کلید
استفاده می‌شود. این مقدار به حروف بزرگ و کوچک حساس است و باید دقیقاً با مقدار
مشخص‌شده در سرور(های) DNS مطابقت داشته باشد. این مقدار یک متن کدگذاری‌شده با base64 است.
• 2
secret-file - از نسخهٔ Kea 2.5.8، این جایگزین امن‌تر پشتیبانی می‌شود.
این مقدار نام فایلی را مشخص می‌کند که کلید مخفی در آن قرار دارد، به این معنی که کلید
مخفیِ کدگذاری‌شده با base64 محتوای فایل است.
168u
به عنوان مثال، فرض کنید دامنه‌ای که D2 به‌روزرسانی خواهد کرد توسط یک سرور DNS از نوع BIND 9
نگهداری می‌شود که نیاز دارد به‌روزرسانی‌های پویا با TSIG امن شوند. همچنین فرض کنید مدخل مربوط
به کلید TSIG در فایل named.conf سرور BIND 9 به این شکل است:
0.0
3.5
:
key "key.four.example.com." {
algorithm hmac-sha224;
secret "bZEG7Ow8OgAUPfLWV3aAUQ==";
};
:
168u
168u
به‌طور پیش‌فرض، فهرست کلیدهای TSIG خالی است:
0.0
3.5
"DhcpDdns": {
"tsig-keys": [ ],
...
}
168u
168u
یک کلید جدید باید به فهرست اضافه شود:
0.0
3.5
"DhcpDdns": {
"tsig-keys": [
{
"name": "key.four.example.com.",
"algorithm": "HMAC-SHA224",
"secret": "bZEG7Ow8OgAUPfLWV3aAUQ=="
}
],
...
}
168u
168u
این مراحل باید برای هر کلید TSIG مورد نیاز تکرار شوند، هرچند یک کلید TSIG
یکسان می‌تواند برای بیش از یک دامنه استفاده شود.
DDNS مستقیم (Forward DDNS)
بخش forward DDNS برای پیکربندی رفتار به‌روزرسانی مستقیم (forward-update) در D2
استفاده می‌شود. در حال حاضر این بخش شامل یک پارامتر واحد است: کاتالوگ دامنه‌های
forward DDNS، که فهرستی از ساختارها است.
0.0
3.5
"DhcpDdns": {
"forward-ddns": {
"ddns-domains": [ ]
},
...
}
168u
168u
به‌طور پیش‌فرض، این فهرست خالی است که موجب می‌شود سرور بخش‌های مربوط
به به‌روزرسانی مستقیم در درخواست‌ها را نادیده بگیرد..SS افزودن دامنه‌های DDNS مستقیم
یک دامنهٔ DDNS مستقیم، یک ناحیهٔ (zone) مستقیم DNS را به مجموعه‌ای از سرورهای DNS نگاشت می‌کند که داده‌های مستقیم DNS (یعنی نگاشت نام به آدرس) را برای آن ناحیه نگهداری می‌کنند. هر ناحیهٔ ارائه‌شده به یک دامنهٔ DDNS مستقیم نیاز دارد. ممکن است برخی یا همهٔ ناحیه‌ها توسط سرورهای یکسانی نگهداری شوند، اما همچنان برای هر ناحیه به یک دامنهٔ DDNS نیاز است. به یاد داشته باشید که تطبیق یک درخواست با سرور(های) مناسب بر اساس ناحیه انجام می‌شود و یک دامنهٔ DDNS تنها یک ناحیه را تعریف می‌کند.
این بخش نحوهٔ افزودن دامنه‌های DDNS مستقیم را شرح می‌دهد؛ این مراحل را برای هر دامنهٔ DDNS مستقیمِ موردنظر تکرار کنید. هر دامنهٔ DDNS مستقیم دارای پارامترهای زیر است:
0.0
• 2
name - این نام دامنهٔ کاملاً مشخص (یا ناحیه) است که این دامنهٔ DDNS می‌تواند آن را به‌روزرسانی کند. این مقدار هنگام تطبیق مستقیم با FQDN درخواست مقایسه می‌شود. این مقدار باید در کاتالوگ (catalog) یکتا باشد.
• 2
key-name - اگر از TSIG همراه با سرورهای این دامنه استفاده می‌شود، این مقدار باید نام کلید از فهرست کلیدهای TSIG باشد. اگر مقدار خالی باشد (پیش‌فرض)، از TSIG در تبادلات DDNS با سرورهای این دامنه استفاده نخواهد شد.
• 2
dns-servers - فهرستی از یک یا چند سرور DNS است که می‌توانند سمتِ سرورِ پروتکل DDNS را برای این دامنه اداره کنند. سرورها به ترتیب اولویت از نخستین تا آخرین استفاده می‌شوند؛ به عبارت دیگر، هنگامی که D2 پردازش یک درخواست را برای این دامنه آغاز می‌کند، نخستین سرور در این فهرست را انتخاب کرده و تلاش می‌کند با آن ارتباط برقرار کند. اگر آن تلاش ناموفق باشد، D2 به سراغ سرور بعدی در فهرست می‌رود و به همین ترتیب، تا زمانی که یا عملیات موفقیت‌آمیز باشد یا فهرست به پایان برسد.
168u
برای ایجاد یک دامنهٔ DDNS مستقیم جدید، یک عنصر دامنهٔ جدید اضافه کرده و پارامترهای آن را تنظیم کنید:
0.0
3.5
"DhcpDdns": {
"forward-ddns": {
"ddns-domains": [
{
"name": "other.example.com.",
"key-name": "",
"dns-servers": [
]
}
]
}
}
168u
168u
امکان افزودن یک دامنه بدون هیچ سروری وجود دارد؛ با این حال، اگر آن دامنه با درخواستی تطبیق یابد، درخواست با شکست مواجه می‌شود. برای اینکه دامنه کاربردی باشد، باید دست‌کم یک سرور DNS به آن اضافه شود.
افزودن سرورهای مستقیم DNS
این بخش نحوهٔ افزودن سرورهای DNS به یک دامنهٔ DDNS مستقیم را شرح می‌دهد. این دستورالعمل‌ها را برحسب نیاز برای تمام سرورهای هر دامنه تکرار کنید.
مدخل‌های سرور مستقیم DNS نمایانگر سرورهای واقعی DNS هستند که از سمت سرور پروتکل DDNS پشتیبانی می‌کنند. هر سرور مستقیم DNS دارای پارامترهای زیر است:
0.0
• 2
hostname - نام میزبان قابل‌حلِ (resolvable) سرور DNS؛ این پارامتر هنوز پیاده‌سازی نشده است.
• 2
ip-address - آدرس IP که سرور روی آن به درخواست‌های DDNS گوش می‌دهد. این آدرس می‌تواند یک آدرس IPv4 یا IPv6 باشد.
• 2
port - پورتی که سرور روی آن به درخواست‌های DDNS گوش می‌دهد. مقدار پیش‌فرض آن پورت استاندارد سرویس DNS یعنی 53 است.
168u
برای ایجاد یک سرور مستقیم DNS جدید، باید یک عنصر سرور جدید به دامنه اضافه شده و پارامترهای آن تکمیل شود. به عنوان مثال، اگر سرویس روی "172.88.99.10" در حال اجرا باشد، سرور مستقیم DNS را به صورت زیر تنظیم کنید:
0.0
3.5
"DhcpDdns": {
"forward-ddns": {
"ddns-domains": [
{
"name": "other.example.com.",
"key-name": "",
"dns-servers": [
{
"ip-address": "172.88.99.10",
"port": 53
}
]
}
]
}
}
168u
168u
نکته:
0.0
3.5
از آنجا که hostname هنوز پشتیبانی نمی‌شود، پارامتر ip-address باید روی آدرس سرور DNS تنظیم شود.
168u
168u
DDNS معکوس
بخش DDNS معکوس برای پیکربندی رفتار به‌روزرسانی معکوس D2 به کار می‌رود و مفاهیم آن مشابه بخش DDNS مستقیم است. در حال حاضر این بخش شامل یک پارامتر منفرد، یعنی کاتالوگ (catalog) دامنه‌های DDNS معکوس است که فهرستی از ساختارها می‌باشد.
0.0
3.5
"DhcpDdns": {
"reverse-ddns": {
"ddns-domains": [ ]
},
...
}
168u
168u
به‌طور پیش‌فرض، این فهرست خالی است که باعث می‌شود سرور بخش‌های به‌روزرسانی معکوس در درخواست‌ها را نادیده بگیرد..SS افزودن دامنه‌های DDNS معکوس
یک دامنهٔ DDNS معکوس، یک زون معکوس DNS را به مجموعه‌ای از کارگزارهای DNS که داده‌های معکوس DNS (نگاشت نشانی به نام) را برای آن زون نگهداری می‌کنند، نگاشت می‌نماید. هر زون سرویس‌دهی‌شده به یک دامنهٔ DDNS معکوس نیاز دارد.
ممکن است برخی یا همهٔ زون‌ها توسط کارگزارهای یکسانی نگهداری شوند، اما برای هر زون به یک مدخل دامنهٔ DDNS نیاز است. به یاد داشته باشید که تطبیق یک درخواست با کارگزار(های) مناسب بر پایهٔ زون انجام می‌شود و هر دامنهٔ DDNS تنها یک زون منفرد را تعریف می‌کند.
این بخش نحوهٔ افزودن دامنه‌های DDNS معکوس را شرح می‌دهد؛ این مراحل را برای هر دامنهٔ DDNS معکوس دلخواه تکرار کنید. هر دامنهٔ DDNS معکوس دارای پارامترهای زیر است:
0.0
• 2
name - این زون معکوس کاملاً واجد شرایط (FQDN) است که این دامنهٔ DDNS می‌تواند آن را به‌روزرسانی کند. این همان مقداری است که در طول تطبیق معکوس استفاده می‌شود و با نسخهٔ معکوس‌شدهٔ نشانی واگذاری (lease address) درخواست مقایسه می‌گردد. نام زون باید از استانداردهای مربوطه پیروی کند؛ برای مثال، جهت پشتیبانی از زیرشبکهٔ IPv4 به‌صورت 172.16.1، نام باید
"1.16.172.in-addr.arpa." باشد. به همین ترتیب، برای پشتیبانی از یک زیرشبکهٔ IPv6 مانند
2001:db8:1، نام باید "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa." باشد.
این نام باید در سرتاسر کاتالوگ یکتا باشد.
• 2
key-name - اگر در ارتباط با کارگزارهای این دامنه از TSIG استفاده می‌شود،
این مقدار باید نام کلید از فهرست کلیدهای TSIG باشد. اگر
مقدار خالی باشد (پیش‌فرض)، در تبادلات DDNS با کارگزارهای این دامنه از TSIG استفاده نخواهد شد.
• 2
dns-servers - فهرستی از یک یا چند کارگزار DNS است که می‌توانند
سمت سرور پروتکل DDNS را برای این دامنه اجرا کنند. در حال حاضر،
کارگزارها با اولویت نخستین به آخرین استفاده می‌شوند؛ به عبارت دیگر، هنگامی که
D2 پردازش درخواستی را برای این دامنه آغاز می‌کند، نخستین
کارگزار این فهرست را برمی‌گزیند و برای برقراری ارتباط با آن تلاش می‌کند. اگر آن
تلاش ناموفق باشد، D2 به سراغ کارگزار بعدی در فهرست می‌رود و به همین ترتیب،
تا زمانی که عملیات با موفقیت انجام شود یا فهرست به پایان برسد.
168u
برای ایجاد یک دامنهٔ DDNS معکوس جدید، باید یک عنصر دامنهٔ جدید اضافه شده
و پارامترهای آن مقداردهی گردند. برای نمونه، برای پشتیبانی از زیرشبکهٔ 2001:db8:1::،
می‌توان از پیکربندی زیر استفاده کرد:
0.0
3.5
"DhcpDdns": {
"reverse-ddns": {
"ddns-domains": [
{
"name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.",
"key-name": "",
"dns-servers": [
]
}
]
}
}
168u
168u
افزودن یک دامنه بدون هیچ‌گونه کارگزاری امکان‌پذیر است؛ با این حال، اگر آن
دامنه با درخواستی تطبیق یابد، درخواست با شکست مواجه خواهد شد. برای کاربردی
ساختن دامنه، دست‌کم یک کارگزار DNS باید به آن افزوده شود.
افزودن کارگزارهای DNS معکوس
این بخش نحوهٔ افزودن کارگزارهای DNS به یک دامنهٔ DDNS معکوس را شرح می‌دهد.
این دستورالعمل‌ها را در صورت نیاز برای تمام کارگزارها در هر دامنه تکرار کنید.
مدخل‌های کارگزار DNS معکوس نمایانگر کارگزارهای واقعی DNS هستند که از
سمت سرور پروتکل DDNS پشتیبانی می‌کنند. هر کارگزار DNS معکوس دارای
پارامترهای زیر است:
0.0
• 2
hostname - نام میزبان قابل‌حلِ کارگزار DNS؛ این مقدار
در حال حاضر نادیده گرفته می‌شود.
• 2
ip-address - نشانی IP که کارگزار روی آن به درخواست‌های DDNS
گوش فرا می‌دهد.
• 2
port - پورتی که کارگزار روی آن به درخواست‌های DDNS گوش فرا می‌دهد.
مقدار پیش‌فرض آن پورت استاندارد سرویس DNS یعنی 53 است.
168u
جهت ایجاد یک کارگزار DNS معکوس جدید، باید یک عنصر کارگزار
جدید به دامنه افزوده شده و پارامترهای آن تعیین شوند. اگر به عنوان مثال،
سرویس روی "172.88.99.10" در حال اجراست، آن را به شکل زیر تنظیم کنید:
0.0
3.5
"DhcpDdns": {
"reverse-ddns": {
"ddns-domains": [
{
"name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.",
"key-name": "",
"dns-servers": [
{
"ip-address": "172.88.99.10",
"port": 53
}
]
}
]
}
}
168u
168u
نکته:
0.0
3.5
از آنجا که hostname هنوز پشتیبانی نمی‌شود، پارامتر ip-address
باید روی نشانی کارگزار DNS تنظیم شود.
168u
168u
کلیدهای TSIG به ازای هر کارگزار DNS
از نسخهٔ 2.0.0 در Kea، می‌توان یک کلید TSIG را در پیکربندی کارگزار DNS
مشخص کرد. قاعدهٔ اولویت بدین شرح است:
0.0
• 2
اگر یک نام کلید غیرخالی در مدخل کارگزار DNS مشخص شده باشد، این کلید TSIG
از به‌روزرسانی‌های DNS ارسال‌شده به این کارگزار محافظت می‌کند.
• 2
اگر مدخل کارگزار DNS خالی باشد، اما یک
نام کلید غیرخالی در مدخل دامنهٔ والد مشخص شده باشد، کلید TSIG دامنهٔ والد
از به‌روزرسانی‌های DNS ارسال‌شده به این کارگزار محافظت می‌کند.
• 2
اگر مدخل کارگزار DNS خالی باشد و هیچ نام کلیدی در مدخل دامنهٔ والد آن
مشخص نشده باشد، هیچ TSIGای از به‌روزرسانی‌های DNS ارسال‌شده به این کارگزار محافظت نمی‌کند.
168u
برای نمونه، در این پیکربندی:
0.0
3.5
"DhcpDdns": {
"forward-ddns": {
"ddns-domains": [
{
"name": "other.example.com.",
"key-name": "foo",
"dns-servers": [
{
"ip-address": "172.88.99.10",
"port": 53
},
{
"ip-address": "172.88.99.11",
"port": 53,
"key-name": "bar"
}
]
}
]
},
"reverse-ddns": {
"ddns-domains": [
{
"name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.",
"dns-servers": [
{
"ip-address": "172.88.99.12",
"port": 53
},
{
"ip-address": "172.88.99.13",
"port": 53,
"key-name": "bar"
}
]
}
]
},
"tsig-keys": [
{
"name": "foo",
"algorithm": "HMAC-MD5",
"secret": "LSWXnfkKZjdPJI5QxlpnfQ=="
},
{
"name": "bar",
"algorithm": "HMAC-SHA224",
"secret": "bZEG7Ow8OgAUPfLWV3aAUQ=="
}
]
}
168u
168u
کارگزار 172.88.99.10 از کلید TSIG با نام "foo" استفاده خواهد کرد، کارگزارهای 172.88.99.11 و
172.88.99.13 از کلید "bar" استفاده خواهند کرد و 172.88.99.12 از TSIG استفاده نخواهد کرد..SS زمینه‌های کاربری در DDNS
برای پیش‌زمینه بیشتر درباره ایده زمینه کاربر (user context)، بخش نظرات و زمینه کاربر <#user-context> را ببینید.
زمینه‌های کاربر را می‌توان در حوزه سراسری (global scope)، یک دامنه DDNS، یک کارساز DNS،
یک کلید TSIG و ثبت‌کننده‌ها (loggers) مشخص کرد. یکی دیگر از کاربردهای مفید، قابلیت ذخیره
نظرات یا توضیحات است؛ تجزیه‌گر یک مدخل "comment" را به یک زمینه کاربر به همراه
آن مدخل ترجمه می‌کند، که اجازه می‌دهد نظر در داخل خود پیکربندی ضمیمه شود.
نمونه پیکربندی کارساز DHCP-DDNS
این بخش یک نمونه پیکربندی کارساز DHCP-DDNS را بر اساس یک شبکه نمونه کوچک ارائه می‌دهد.
فرض کنیم شبکه نمونه ما دارای سه دامنه است که هر کدام زیرشبکه خود را دارند.
شبکه نمونه ما
box center;
l|l|l|l.
دامنه زیرشبکه کارسازهای DNS مستقیم کارسازهای DNS معکوس
four.example.com 192.0.2.0/24 172.16.1.5, 172.16.2.5 172.16.1.5, 172.16.2.5
six.example.com 2001:db8:1::/64 3001:1::50 3001:1::51
example.com 192.0.0.0/16 172.16.2.5 172.16.2.5

ما باید سه دامنه DDNS مستقیم بسازیم:

# نام دامنه DDNS کارسازهای DNS
0.0 1. 3 168u four.example.com. 172.16.1.5, 172.16.2.5
0.0 2. 3 168u six.example.com. 3001:1::50
0.0 3. 3 168u example.com. 172.16.2.5

همان‌طور که پیش‌تر توضیح داده شد، تطبیق FQDN به دامنه بر اساس طولانی‌ترین تطابق (longest match) است. عبارت FQDN "myhost.four.example.com." با دامنه اول ("four.example.com") تطابق دارد، در حالی که "admin.example.com." با دامنه سوم ("example.com") مطابقت پیدا می‌کند. عبارت FQDN "other.example.net." با هیچ دامنه‌ای تطبیق ندارد و رد می‌شود.

پیکربندی نمونه زیر دامنه‌های DDNS مستقیم را مشخص می‌کند.

"DhcpDdns": {
    "comment": "example configuration: forward part",
    "forward-ddns": {
        "ddns-domains": [
            {
                "name": "four.example.com.",
                "key-name": "",
                "dns-servers": [
                    { "ip-address": "172.16.1.5" },
                    { "ip-address": "172.16.2.5" }
                ]
            },
            {
                "name": "six.example.com.",
                "key-name": "",
                "dns-servers": [
                    { "ip-address": "2001:db8::1" }
                ]
            },
            {
                "name": "example.com.",
                "key-name": "",
                "dns-servers": [
                    { "ip-address": "172.16.2.5" }
                ],
                "user-context": { "backup": false }
            },
            ...
        ]
    }
}

به طور مشابه، ما باید سه دامنه DDNS معکوس را بسازیم:.SS دامنه‌های معکوس DDNS مورد نیاز

# نام دامنه DDNS کارسازهای DNS
0.0 1. 3 168u 2.0.192.in-addr.arpa. 172.16.1.5, 172.16.2.5
0.0 2. 3 168u 1.0.0.0.8.d.b.0.1.0.0.2.ip6.arpa. 3001:1::50
0.0 3. 3 168u 0.182.in-addr.arpa. 172.16.2.5

آدرس "192.0.2.150" با دامنه نخست، "2001:db8:1::10" با دامنه دوم، و "192.0.50.77" با دامنه سوم مطابقت دارد.

این دامنه‌های معکوس DDNS به صورت زیر مشخص می‌شوند:

"DhcpDdns": {
    "comment": "example configuration: reverse part",
    "reverse-ddns": {
        "ddns-domains": [
            {
                "name": "2.0.192.in-addr.arpa.",
                "key-name": "",
                "dns-servers": [
                    { "ip-address": "172.16.1.5" },
                    { "ip-address": "172.16.2.5" }
                ]
            },
            {
                "name": "1.0.0.0.8.B.D.0.1.0.0.2.ip6.arpa.",
                "key-name": "",
                "dns-servers": [
                    { "ip-address": "2001:db8::1" }
                ]
            },
            {
                "name": "0.192.in-addr.arpa.",
                "key-name": "",
                "dns-servers": [
                    { "ip-address": "172.16.2.5" }
                ]
            },
            ...
        ]
    }
}

نسخه 2.0.0 از Kea، پشتیبانی از آمارها را برای DHCP-DDNS ارائه کرد.

آمارها به سه گروه تقسیم می‌شوند: NameChangeRequests، به‌روزرسانی‌های DNS، و به‌روزرسانی‌های DNS بر پایه هر کلید TSIG (per-TSIG-key). در حالی که آمارهای دو گروه نخست تجمعی هستند، یعنی با تغییر پیکربندی یا بارگذاری مجدد تحت تأثیر قرار نمی‌گیرند، آمارهای بر پایه هر کلید با ایجاد (یا ایجاد مجدد) شیء مربوطه، به ۰ بازنشانی می‌شوند.

در حال حاضر مدیریت آمارهای Kea دارای محدودیت‌های زیر است:

  • تنها نمونه‌های عدد صحیح (یعنی یک شمارنده و یک برچسب زمانی) استفاده می‌شوند؛
  • بیشینه تعداد نمونه ۱ است؛
  • هیچ رابط برنامه‌نویسی‌ای (API) برای حذف یک یا تمام آمارها وجود ندارد؛
  • هیچ APIای برای تنظیم بیشینه تعداد نمونه یا طول عمر آن وجود ندارد.

نکته:

کتابخانه‌های قلاب (Hook libraries)، مانند کتابخانه GSS-TSIG، آمارهای جدیدی را در Kea در دسترس قرار می‌دهند.

اطلاعات بیشتر درباره آمارهای Kea را می‌توان در بخش Statistics <#stats> یافت.

آمارهای مربوط به NameChangeRequest عبارتند از:

  • ncr-received - تعداد NCRهای معتبر دریافتی
  • ncr-invalid - تعداد NCRهای نامعتبر دریافتی
  • ncr-error - تعداد خطاها در دریافت NCR به‌جز لغو ورودی/خروجی (I/O cancel) هنگام خاموش‌سازی
  • queue-mgr-queue-full - تعداد دفعاتی که صف دریافت NCR به حداکثر ظرفیت خود رسیده است

    آمارهای سراسری به‌روزرسانی DNS عبارتند از:

  • update-sent - تعداد به‌روزرسانی‌های DNS ارسال‌شده
  • update-signed - تعداد به‌روزرسانی‌های DNS ارسال‌شده و محافظت‌شده با TSIG
  • update-unsigned - تعداد به‌روزرسانی‌های DNS ارسال‌شده و محافظت‌نشده با TSIG
  • update-success - تعداد به‌روزرسانی‌های DNS که با موفقیت تکمیل شده‌اند
  • update-timeout - تعداد به‌روزرسانی‌های DNS که با اتمام مهلت زمانی (timeout) پایان یافته‌اند
  • update-error - تعداد به‌روزرسانی‌های DNS که با خطایی غیر از اتمام مهلت زمانی پایان یافته‌اند

آمارهای به‌روزرسانی DNS برای هر کلید TSIG عبارتند از:

  • update-sent - تعداد به‌روزرسانی‌های DNS ارسال‌شده
  • update-success - تعداد به‌روزرسانی‌های DNS که با موفقیت تکمیل شده‌اند
  • update-timeout - تعداد به‌روزرسانی‌های DNS که با اتمام مهلت زمانی (timeout) پایان یافته‌اند
  • update-error - تعداد به‌روزرسانی‌های DNS که با خطایی غیر از اتمام مهلت زمانی پایان یافته‌اند

قالب نام برای آمارهای بر پایه کلید، به صورت key[<key-DNS-name>].<stat-name> است؛ برای نمونه، نام آمار update-sent برای کلید TSIG با عنوان key.example.com. برابر با key[key.example.com.].update-sent است.

موارد زیر محدودیت‌های کنونی کارگزار DHCP-DDNS هستند.

•
درخواست‌های دریافتی از کارگزارهای DHCP تا زمان پردازش در صف قرار می‌گیرند. در حال حاضر، در صورت خاموش شدن کارگزار، تمام درخواست‌های موجود در صف از دست می‌روند.

RFCهای زیر توسط کارگزار DHCP-DDNS پشتیبانی می‌شوند:

  • Secret Key Transaction Authentication for DNS (TSIG)، RFC 2845 https://datatracker.ietf.org/doc/html/rfc2845: تمام بسته‌های به‌روزرسانی DNS ارسال‌شده و دریافت‌شده توسط کارگزار DHCP-DDNS می‌توانند با امضاهای TSIG محافظت شوند.
  • Dynamic Updates in the Domain Name System (DNS UPDATE)، RFC 2136 https://datatracker.ietf.org/doc/html/rfc2136: سازوکار کامل به‌روزرسانی DNS پشتیبانی می‌شود.
  • Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients، RFC 4703 https://datatracker.ietf.org/doc/html/rfc4703: DHCP-DDNS وظیفه حل تعارض را برای هر دو کارگزار DHCPv4 و DHCPv6 انجام می‌دهد.
  • A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)، RFC 4701 https://datatracker.ietf.org/doc/html/rfc4701: کارگزار DHCP-DDNS از رکوردهای DHCID استفاده می‌کند.

kea-lfc <#std-iscman-kea-lfc> یک فرآیند سرویس است که اطلاعات زائد را از فایل‌های مورد استفاده برای ذخیره‌سازی پایدار در بک‌اند پایگاه‌داده memfile پاک‌سازی می‌کند. این سرویس برای اجرا به عنوان یک فرآیند مستقل نوشته شده است.

اگرچه kea-lfc <#std-iscman-kea-lfc> را می‌توان به صورت خارجی آغاز کرد، معمولاً نیازی به انجام این کار نیست. kea-lfc <#std-iscman-kea-lfc> به صورت دوره‌ای توسط کارگزارهای Kea DHCP اجرا می‌شود و از نسخه Kea 3.1.2 می‌تواند با استفاده از دستور kea-lfc-start راه‌اندازی شود.

این فرآیند روی مجموعه‌ای از فایل‌ها کار می‌کند و از آن‌ها برای دریافت ورودی و ثبت خروجی ورودی‌های اجاره (lease entries) و نشان دادن مرحله‌ای که فرآیند در صورت بروز وقفه در آن قرار دارد، استفاده می‌کند. در حال حاضر فراخواننده باید نام همه این فایل‌ها را مشخص کند.

kea-lfc <#std-iscman-kea-lfc> به صورت زیر اجرا می‌شود:

kea-lfc [-4 | -6] -c config-file -p pid-file -x previous-file -i copy-file -o output-file -f finish-file

آرگومان -4 یا -6 نسخه پروتکل فایل‌های اجاره را انتخاب می‌کند.

آرگومان -c فایل پیکربندی را مشخص می‌کند. این آرگومان الزامی است، اما در حال حاضر توسط فرآیند استفاده نمی‌شود.

آرگومان -p فایل PID را مشخص می‌کند. هنگامی که فرآیند kea-lfc <#std-iscman-kea-lfc> آغاز می‌شود، با بررسی فایل PID تلاش می‌کند تشخیص دهد که آیا نمونه دیگری از فرآیند از قبل در حال اجرا است یا خیر. اگر نمونه‌ای در حال اجرا باشد، فرآیند جدید خاتمه می‌یابد؛ اگر در حال اجرا نباشد، Kea شناسه فرآیند (PID) خود را در فایل PID می‌نویسد.

سایر نام‌های فایل مشخص می‌کنند که فرآیند kea-lfc <#std-iscman-kea-lfc> کجا باید به دنبال ورودی بگردد، خروجی خود را بنویسد و وظایف ثبت وضعیت (bookkeeping) خود را انجام دهد:

  • previous — هنگامی که kea-lfc <#std-iscman-kea-lfc> آغاز می‌شود، این فایل نتیجه اجرای قبلی kea-lfc <#std-iscman-kea-lfc> است. هنگامی که kea-lfc <#std-iscman-kea-lfc> پایان می‌یابد، نتیجه این اجرا خواهد بود. اگر اجرای kea-lfc <#std-iscman-kea-lfc> پیش از تکمیل متوقف شود، ممکن است این فایل وجود نداشته باشد.
  • input — پیش از آنکه کارگزار DHCP فرآیند kea-lfc <#std-iscman-kea-lfc> را فراخوانی کند، فایل اجاره فعلی را به اینجا منتقل کرده و سپس kea-lfc <#std-iscman-kea-lfc> را با این فایل فراخوانی می‌کند.
  • output — این فایل موقتی است که kea-lfc <#std-iscman-kea-lfc> اجاره‌ها را در آن می‌نویسد. پس از پایان نوشتن در فایل، به فایل finish منتقل می‌شود (در ادامه ببینید).
  • finish — این یک فایل موقت دیگر است که kea-lfc <#std-iscman-kea-lfc> برای ثبت وضعیت استفاده می‌کند. هنگامی که kea-lfc <#std-iscman-kea-lfc> نوشتن در فایل output را تکمیل کرد، محتویات را به فایلی با این نام منتقل می‌کند. پس از اینکه kea-lfc <#std-iscman-kea-lfc> حذف فایل‌های دیگر (previous و input) را به پایان رساند، این فایل را به فایل اجاره previous منتقل می‌کند. با انتقال فایل‌ها به این روش، فرآیندهای kea-lfc <#std-iscman-kea-lfc> و کارگزار DHCP می‌توانند حتی در صورتی که یکی از فرآیندها پیش از پایان وظیفه خود دچار وقفه شود، فایل درست را برای استفاده تشخیص دهند.

چندین آرگومان دیگر نیز وجود دارند که بیشتر برای اهداف اشکال‌زدایی به کار می‌روند. -d سطح ثبت وقایع (logging) را روی حالت اشکال‌زدایی (debug) تنظیم می‌کند. -v و -V برچسب‌های نسخه را چاپ می‌کنند که -V قالب طولانی‌تری ارائه می‌دهد. -h متن راهنمای استفاده را نمایش می‌دهد..SH "دسته‌بندی کلاینت (CLIENT CLASSIFICATION)"

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

  • کلاینت‌ها بخش‌های متفاوتی از توپولوژی را نشان می‌دهند؛ به عنوان مثال، یک مودم کابلی (cable modem) با کلاینت‌های پشت آن مودم یکسان نیست.
  • کلاینت‌ها رفتار متفاوتی دارند؛ به عنوان مثال، رفتار یک گوشی هوشمند با یک لپ‌تاپ تفاوت دارد.
  • کلاینت‌ها برای برخی گزینه‌ها به مقادیر متفاوتی نیاز دارند؛ به عنوان مثال، یک مودم کابلی docsis3.0 به تنظیماتی متفاوت نسبت به یک مودم کابلی docsis2.0 نیاز دارد.

برای ساده‌تر شدن مدیریت، کلاینت‌های مختلف می‌توانند در یک کلاس کلاینت (client class) گروه‌بندی شوند تا گزینه‌های مشترکی را دریافت کنند.

یک بسته ورودی می‌تواند به چندین روش به یک کلاس کلاینت منتسب شود:

  • به‌طور ضمنی، با استفاده از یک گزینه vendor class یا شرط داخلی (built-in) دیگر.
  • با استفاده از عبارتی که مقدار آن به true ارزیابی شود.
  • با استفاده از رزروهای میزبان ایستا (static host reservations)، یک shared network، یک subnet و غیره.
  • با استفاده از یک hook.

دسته‌بندی کلاینت می‌تواند برای تغییر رفتار تقریباً هر بخشی از پردازش پیام‌های DHCP استفاده شود. در حال حاضر ۹ سازوکار وجود دارند که از دسته‌بندی کلاینت بهره می‌برند:

  • دور انداختن پرس‌وجوها (Dropping queries).
  • انتخاب زیرشبکه (Subnet selection).
  • انتخاب استخر (Pool selection).
  • محدود کردن اجاره (Lease limiting).
  • محدود کردن نرخ (Rate limiting).
  • تنظیم DDNS.
  • تعریف گزینه‌های اختصاصی DHCPv4 (کدهای ۲۲۴-۲۵۴) و گزینه‌های کد ۴۳.
  • اختصاص گزینه‌های متفاوت.
  • تنظیم گزینه‌های خاص برای استفاده با آدرس سرور TFTP و فیلد فایل بوت (boot file) برای مودم‌های کابلی DHCPv4.

فرایند دسته‌بندی در چندین مرحله انجام می‌شود:

1.
کلاس ALL به بسته ورودی منتسب می‌شود.
2.
گزینه‌های vendor class پردازش می‌شوند.
3.
کلاس‌های دارای عبارات منطبق‌سازی که برای ارزیابی بعدی نشانه‌گذاری نشده‌اند ("on request" یا وابسته به کلاس‌های داخلی KNOWN/UNKNOWN)، به ترتیبی که در پیکربندی تعریف شده‌اند پردازش می‌شوند؛ عبارت بولی ارزیابی شده و در صورتی که مقدار true (تطابق) را برگرداند، بسته ورودی به آن کلاس منتسب می‌شود.
4.
در صورت دریافت گزینه اختصاصی یا گزینه کد ۴۳ در DHCPv4، آن گزینه بر اساس تعریف client-class یا سراسری (یا برای گزینه ۴۳، آخرین راهکار/last-resort) رمزگشایی می‌شود.
5.
هنگامی که بسته ورودی متعلق به کلاس ویژه DROP باشد، دور انداخته می‌شود و یک پیام اطلاع‌رسانی به همراه اطلاعات بسته ثبت می‌شود.

نکته:

فراخوان‌های pkt4_receive و pkt6_receive در اینجا اجرا می‌شوند.
6.
هنگامی که پارامتر سراسری early-global-reservations-lookup بر روی true تنظیم شده باشد، این فرایند به جستجوی رزروهای سراسری پرداخته و مراحل ۸، ۹ و ۱۰ را به‌طور جزئی اجرا می‌کند. این جستجو محدود به رزروهای سراسری است؛ اگر موردی یافت شود، کلاس KNOWN تنظیم می‌شود، اما در صورت عدم یافتن، کلاس UNKNOWN تنظیم نمی‌شود.
7.
یک زیرشبکه انتخاب می‌شود، احتمالاً بر اساس اطلاعات کلاس، زمانی که برخی از زیرشبکه‌ها رزرو شده باشند. دقیق‌تر: هنگام انتخاب یک زیرشبکه، سرور در میان تمام زیرشبکه‌هایی که با توجه به اطلاعات موجود در بسته (آدرس کلاینت، آدرس رله و غیره) امکان‌پذیر هستند، پیمایش می‌کند. سرور از اولین زیرشبکه‌ای استفاده می‌کند که یا هیچ کلاسی به آن منتسب نشده باشد، یا دارای کلاسی باشد که با یکی از کلاس‌های بسته مطابقت دارد.

نکته:

فراخوان‌های subnet4_select و subnet6_select در اینجا اجرا می‌شوند.
8.
سرور به دنبال رزروهای میزبان (host reservations) می‌گردد. اگر شناسه‌ای از بسته ورودی با یک رزرو میزبان در زیرشبکه یا shared network مطابقت داشته باشد، بسته به کلاس KNOWN و تمام کلاس‌های آن رزرو میزبان منتسب می‌شود. اگر رزروی یافت نشود، بسته به کلاس UNKNOWN تخصیص می‌یابد.

نکته:

اگر یک رزرو منطبق از زیرشبکه انتخاب‌شده وجود داشته باشد و آن زیرشبکه متعلق به یک shared-network باشد، انتساب هر کلاسی که در رزرو مشخص شده است تا پس از تخصیص اجاره به تعویق می‌افتد. این کار به دلیل در نظر گرفتن این احتمال انجام می‌شود که ممکن است انتخاب زیرشبکه در طول تخصیص اجاره تغییر کند و این امر تطابق رزرو اولیه را باطل کرده و احتمالاً جایگزین نماید.
9.
کلاس‌های دارای عبارات تطابق - چه به صورت مستقیم یا غیرمستقیم با استفاده از کلاس‌های داخلی KNOWN/UNKNOWN و بدون نشانه‌گذاری برای ارزیابی بعدی ("on request") - به ترتیبی که در پیکربندی تعریف شده‌اند پردازش می‌شوند؛ عبارت بولی ارزیابی می‌شود و در صورت بازگرداندن true (تطابق)، بسته ورودی به آن کلاس منتسب می‌گردد. پس از انتخاب یک زیرشبکه، سرور مشخص می‌کند که آیا رزروی برای کلاینت مشخص وجود دارد یا خیر. بنابراین، استفاده از کلاس UNKNOWN برای انتخاب یک shared network یا یک subnet امکان‌پذیر نیست. برای کلاس KNOWN، تنها از رزروهای سراسری استفاده می‌شود و پارامتر early-global-reservations-lookup باید روی true تنظیم شده باشد.
10.
هنگامی که بسته ورودی متعلق به کلاس ویژه DROP باشد، دور انداخته می‌شود و یک پیام اطلاع‌رسانی به همراه اطلاعات بسته ثبت می‌شود. از نگارش ۱.۹.۸ برنامه Kea به بعد، وابسته کردن کلاس DROP به کلاس‌های KNOWN/UNKNOWN مجاز است.
11.
در صورت نیاز، آدرس‌ها و پیشوندها از استخرها (pools) تخصیص می‌یابند، که در صورت رزرو بودن برخی استخرها برای اعضای کلاس، ممکن است بر اساس اطلاعات کلاس انجام پذیرد.

نکته:

فراخوان‌های lease4_select، lease4_renew، lease6_select، lease6_renew و lease6_rebind در اینجا اجرا می‌شوند.

نکته:

اگر یک رزرو میزبان منطبق از زیرشبکه انتخاب‌شده وجود داشته باشد و آن زیرشبکه متعلق به یک shared-network باشد، هر کلاسی که در رزرو مشخص شده است تخصیص داده می‌شود.
12.
فهرست‌های evaluate-additional-classes (در صورت وجود) ابتدا برای pool، سپس subnet و در نهایت shared-network که منابع تخصیص‌یافته به آن تعلق دارند، ارزیابی می‌شوند. کلاس‌ها به همان ترتیبی که در هر فهرست آمده‌اند ارزیابی می‌شوند.
13.
گزینه‌ها مجدداً احتمالاً بر اساس اطلاعات کلاس و به ترتیبی که کلاس‌ها به بسته ورودی منتسب شده‌اند، اختصاص داده می‌شوند. اولین کلاسی که با بسته تطابق داشته و گزینه مشخص‌شده‌ای را معین کند، اولویت دارد. برای گزینه‌های اختصاصی و کد ۴۳ در DHCPv4، این شامل تعاریف گزینه مشخص‌شده درون کلاس‌ها نیز می‌شود. ترتیب اولویت گزینه‌ها به صورت زیر است:
1.
گزینه‌های میزبان (Host options)
2.
گزینه‌های استخر (Pool options)
3.
گزینه‌های زیرشبکه (Subnet options)
4.
گزینه‌های شبکه مشترک (Shared network options)
5.
گزینه‌های کلاس‌های اختصاص‌یافته در طول دسته‌بندی عادی:
کلاس ALL.IP b. 3 کلاس‌های سازنده (Vendor classes)
کلاس‌های میزبان (Host classes)
کلاس‌های ارزیابی‌شده‌ای که به کلاس KNOWN وابسته نیستند
کلاس‌های KNOWN و UNKNOWN
کلاس‌های ارزیابی‌شده‌ای که به کلاس KNOWN وابسته‌اند
6.
گزینه‌های مربوط به کلاس‌ها در evaluate-additional-classes از:
استخر (Pool)
زیرشبکه (Subnet)
شبکه مشترک (Shared network)
7.
گزینه‌های سراسری (Global options)

نکته:

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

برخی کلاس‌ها توکار هستند، بنابراین نیازی به تعریف صریح آن‌ها نیست. در صورت نیاز به پیوند دادن طول عمر اجاره (lease lifetime)، داده‌های گزینه و غیره با آن‌ها، می‌توان آن‌ها را تعریف کرد.

اطلاعات کلاس سازنده (vendor class) نمونه اصلی این مورد است: سرور بررسی می‌کند که آیا بسته ورودی DHCPv4 شامل گزینه شناسه کلاس سازنده (60) هست یا بسته ورودی DHCPv6 شامل گزینه کلاس سازنده (16) می‌باشد. اگر چنین باشد، محتوای آن گزینه با پیشوند VENDOR_CLASS_ همراه شده و نتیجه به عنوان کلاسی برای آن بسته تفسیر می‌شود. محتوایی که در نظر گرفته می‌شود کل شناسه کلاس برای DHCPv4، و اولین فیلد داده کلاس سازنده برای DHCPv6 است. شماره سازمانی (enterprise number) و فیلدهای داده کلاس سازنده پس از آن برای اهداف دسته‌بندی استفاده نمی‌شوند. برای مثال، مودم‌های کابلی امروزی چنین گزینه‌هایی را با مقدار docsis3.0 ارسال می‌کنند، بنابراین بسته متعلق به کلاس VENDOR_CLASS_docsis3.0 خواهد بود.

پیشوند HA_ توسط libdhcp_ha.so <#std-ischooklib-libdhcp_ha.so> برای تعیین سرورهای خاصی جهت پردازش بسته‌های DHCP در نتیجه توازن بار (load balancing) استفاده می‌شود. نام کلاس با اضافه کردن پیشوند HA_ به ابتدای نام سروری که باید بسته DHCP را پردازش کند ساخته می‌شود. این سرور بر اساس کلاس‌های کلاینت اختصاص‌یافته، از استخر یا زیرشبکه مناسبی برای تخصیص آدرس‌های IP (و/یا پیشوندها) استفاده می‌کند. جزئیات را می‌توان در libdhcp_ha.so: High Availability Outage Resilience for Kea Servers <#hooks-high-availability> یافت.

پیشوند SPAWN_ توسط کلاس‌های الگو (template classes) برای تولید نام‌های کلاس مشتق‌شده (spawned) در زمان اجرا استفاده می‌شود. نام کلاس مشتق‌شده با الحاق پیشوند SPAWN_ به ابتدای نام کلاس الگو و مقدار ارزیابی‌شده ساخته می‌شود: SPAWN_<template-class-name>_<evaluated-value>. جزئیات بیشتر را می‌توان در Configuring Classes یافت.

کلاس BOOTP توسط libdhcp_bootp.so <#std-ischooklib-libdhcp_bootp.so> برای دسته‌بندی و پاسخ‌گویی به پرس‌وجوهای ورودی BOOTP استفاده می‌شود.

کلاس SKIP_DDNS توسط کتابخانه قلابِ تنظیم DDNS (DDNS-tuning hook library) برای لغو به‌روزرسانی‌های DDNS بر اساس هر کلاینت استفاده می‌شود.

نمونه‌های دیگر شامل کلاس ALL است که تمامی بسته‌های ورودی به آن تعلق دارند، و کلاس KNOWN که هنگام وجود رزرو میزبان (host reservation) برای یک کلاینت خاص اختصاص می‌یابد. طبق قرارداد، نام کلاس‌های توکار همگی با حروف بزرگ آغاز می‌شود.

نام‌های کلاس‌های توکار که در حال حاضر شناسایی می‌شوند عبارتند از ALL، KNOWN و UNKNOWN، و پیشوندهای VENDOR_CLASS_، HA_، AFTER_، EXTERNAL_، SKIP_DDNS. اگرچه پیشوند AFTER_ تمهیدی برای یک قلاب (hook) هنوز نوشته‌نشده است، پیشوند EXTERNAL_ را می‌توان آزادانه استفاده کرد؛ کلاس‌های توکار به صورت ضمنی تعریف شده‌اند، بنابراین اگر در پیکربندی ظاهر نشوند، هرگز هشداری صادر نمی‌کنند.

بخش عبارت (expression) از یک تعریف دسته‌بندی شامل عملگرها و مقادیر است. در حال حاضر تمامی مقادیر رشته هستند؛ عملگرها یک یا چند رشته را به عنوان ورودی گرفته و رشته دیگری برمی‌گردانند. هنگامی که تمام عملیات پایان یافت، نتیجه باید مقداری از نوع true یا false باشد. در صورتی که نتیجه true باشد، بسته متعلق به آن کلاس است (و نام کلاس به فهرست کلاس‌ها اضافه می‌شود). عبارت‌ها در قالب استاندارد نوشته می‌شوند و می‌توانند تودرتو باشند.

عبارت‌ها هنگام تجزیه فایل پیکربندی پیش‌پردازش شده و به یک نمایش داخلی تبدیل می‌شوند. این امر امکان شناسایی و ثبت انواع خاصی از خطاها را در زمان تجزیه فراهم می‌کند. نمونه‌هایی از این خطاها شامل تعداد یا نوع نادرست آرگومان ورودی برای یک عملگر است. کد ارزیابی نیز این دسته از خطاها را بررسی کرده و معمولاً یک استثنا صادر می‌کند (throw exception)، اگرچه این حالت در یک سیستم با عملکرد عادی نباید رخ دهد.

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

وابستگی‌های بین کلاس‌ها نیز بررسی می‌شوند. برای نمونه، وابستگی‌های رو به جلو (forward dependencies) هنگام تجزیه پیکربندی رد می‌شوند؛ یک عبارت تنها می‌تواند به کلاس‌های از پیش تعریف‌شده (از جمله کلاس‌های توکار) وابسته باشد که در یک مرحله ارزیابی قبلی یا همان مرحله ارزیابی شده‌اند. این موضوع برای کلاس‌های KNOWN یا UNKNOWN اعمال نمی‌شود.

نام عبارت نمونه مقدار نمونه
رشته لفظی 'example' 'example'
رشته هگزادسیمال لفظی 0x5a7d 'Z}'
آدرس IP لفظی 10.0.0.1 0x0a000001
عدد صحیح لفظی 123 '123'
محتوای باینری گزینه option[123].hex '(content of the option)'
وجود گزینه option[123].exists 'true'
محتوای باینری زیرگزینه option[12].option[34].hex '(content of the sub-option)'
وجود زیرگزینه option[12].option[34].exists 'true'
عضویت در کلاس کلاینت member('foobar') 'true'
کلاینت شناخته‌شده known member('KNOWN')
کلاینت ناشناخته unknown not member('KNOWN')
زیرگزینه عامل رله DHCPv4 relay4[123].hex '(content of the RAI sub-option)'
گزینه‌های رله DHCPv6 relay6[nest].option[code].hex (value of the option)
آدرس همتای رله DHCPv6 relay6[nest].peeraddr 2001:DB8::1
آدرس پیوند رله DHCPv6 relay6[nest].linkaddr 2001:DB8::1
نام رابط بسته pkt.iface eth0
آدرس مبدأ بسته pkt.src 10.1.2.3
آدرس مقصد بسته pkt.dst 10.1.2.3
طول بسته pkt.len 513
آدرس سخت‌افزاری در بسته DHCPv4 pkt4.mac 0x010203040506
طول سخت‌افزار در بسته DHCPv4 pkt4.hlen 6
نوع سخت‌افزار در بسته DHCPv4 pkt4.htype 6
فیلد ciaddr در بسته DHCPv4 pkt4.ciaddr 192.0.2.1
فیلد giaddr در بسته DHCPv4 pkt4.giaddr 192.0.2.1
فیلد yiaddr در بسته DHCPv4 pkt4.yiaddr 192.0.2.1
فیلد siaddr در بسته DHCPv4 pkt4.siaddr 192.0.2.1
نوع پیام در بسته DHCPv4 pkt4.msgtype 1
شناسه تراکنش (xid) در بسته DHCPv4 pkt4.transid 12345
نوع پیام در بسته DHCPv6 pkt6.msgtype 1
شناسه تراکنش در بسته DHCPv6 pkt6.transid 12345
وجود گزینه سازنده (هر سازنده‌ای) vendor[*].exists 'true'
وجود گزینه سازنده (سازنده خاص) vendor[4491].exists 'true'
شناسه سازمانی (enterprise-id) از گزینه سازنده vendor.enterprise 4491
وجود زیرگزینه سازنده vendor[4491].option[1].exists 'true'
محتوای زیرگزینه سازنده vendor[4491].option[1].hex docsis3.0
وجود گزینه کلاس سازنده (هر سازنده‌ای) vendor-class[*].exists 'true'
وجود گزینه کلاس سازنده (سازنده خاص) vendor-class[4491].exists 'true'
شناسه سازمانی (enterprise-id) از گزینه کلاس سازنده vendor-class.enterprise 4491
نخستین بخش داده از گزینه کلاس سازنده vendor-class[4491].data docsis3.0
بخش داده خاص از گزینه کلاس سازنده vendor-class[4491].data[3] docsis3.0

نکات:

رشته‌های هگزادسیمال همان‌گونه که انتظار می‌رود به یک رشته تبدیل می‌شوند. 0X یا 0x ابتدایی حذف می‌شود، و اگر تعداد نویسه‌های رشته فرد باشد، یک "0" به ابتدای آن افزوده می‌شود.
  • آدرس‌های IP به رشته‌هایی به طول ۴ یا ۱۶ تبدیل می‌شوند. آدرس‌های IPv4،‏ IPv6 و IPv4 تعبیه‌شده در IPv6 (مانند IPv4-mapped IPv6) پشتیبانی می‌شوند.
  • اعداد صحیح در یک عبارت به اعداد صحیح ۳۲-بیتی بدون علامت تبدیل می‌شوند و به‌صورت رشته‌های چهار بایتی نشان داده می‌شوند؛ برای نمونه، 123 به‌صورت 0x0000007b نمایش داده می‌شود. تمام عبارت‌هایی که مقادیر عددی برمی‌گردانند، از اعداد صحیح ۳۲-بیتی بدون علامت استفاده می‌کنند، حتی اگر فیلد مربوطه در بسته کوچک‌تر باشد. به‌طور کلی، استفاده از نماد ده‌دهی برای نمایش اعداد صحیح آسان‌تر است، اما استفاده از نماد هگزادسیمال نیز امکان‌پذیر است. هنگام نوشتن یک عدد صحیح در مبنای شانزده، باید دقت شود که مقدار حتماً به‌صورت ۳۲ بیت نشان داده شود، مثلاً به‌جای 0x1 یا 0x01 از 0x00000001 استفاده کنید. همچنین، مطمئن شوید که مقدار در ترتیب بایت شبکه (network order) مشخص شده باشد، برای نمونه 1 به‌صورت 0x00000001 نمایش می‌یابد.
  • عبارت option[code].hex مقدار گزینه‌ای با کد code را از بستهٔ دریافتی استخراج می‌کند. اگر بسته فاقد این گزینه باشد، یک رشتهٔ خالی برمی‌گرداند. این رشته به‌صورت یک رشتهٔ بایتی از بار دادهٔ (payload) گزینه، بدون فیلدهای کد نوع یا طول ارائه می‌شود.
  • عبارت option[code].exists بررسی می‌کند که آیا گزینه‌ای با کد code در بستهٔ دریافتی وجود دارد یا خیر. این عبارت را می‌توان با گزینه‌های خالی نیز به‌کار برد.
  • عبارت member('foobar') بررسی می‌کند که آیا بسته متعلق به کلاس کلاینت foobar است یا خیر. برای جلوگیری از حلقه‌های وابستگی، تجزیه‌گر فایل پیکربندی بررسی می‌کند که آیا کلاس‌های کلاینت از قبل تعریف شده‌اند یا توکار هستند، یعنی با VENDOR_CLASS_، AFTER_ (برای قلابِ آیندهٔ "after") و EXTERNAL_ آغاز می‌شوند یا برابر با ALL، KNOWN، UNKNOWN و غیره هستند.

    کلمات known و unknown حالت‌های کوتاه‌شده برای member('KNOWN') و not member('KNOWN') هستند. توجه داشته باشید که ارزیابی هر عبارتی که از کلاس KNOWN (به‌صورت مستقیم یا غیرمستقیم) استفاده می‌کند، به پس از جستجوی رزرو میزبان موکول می‌شود (یعنی زمانی که افرازِ KNOWN یا UNKNOWN مشخص شده باشد).

  • عبارت relay4[code].hex تلاش می‌کند تا مقدار زیرگزینهٔ code را از گزینه‌ای که به‌عنوان گزینهٔ اطلاعات عامل رلهٔ DHCPv4 یا DHCPv4 Relay Agent Information (82) درج شده است، استخراج کند. اگر بسته فاقد گزینهٔ RAI باشد، یا گزینهٔ RAI شامل زیرگزینهٔ درخواستی نباشد، عبارت یک رشتهٔ خالی برمی‌گرداند. این رشته به‌صورت یک رشتهٔ بایتی از بار دادهٔ گزینه بدون فیلدهای کد نوع یا طول ارائه می‌شود. استفاده از این عبارت تنها در DHCPv4 مجاز است.
  • عبارت relay4 از همان انواع نمایش مشابه با option استفاده می‌کند؛ برای نمونه، relay4[code].exists پشتیبانی می‌شود.
  • عبارت relay6[nest] امکان دسترسی به کپسوله‌سازی‌های استفاده‌شده توسط هر رلهٔ DHCPv6 را که بسته را هدایت کرده است فراهم می‌کند. سطح nest رله‌ای را مشخص می‌کند که اطلاعات باید از آن استخراج شود، به‌طوری که مقدار 0 نشان‌دهندهٔ نزدیک‌ترین رله به کارساز DHCPv6 است. مقادیر منفی امکان شمارش رله‌ها را از سمت کلاینت DHCPv6 فراهم می‌کنند، به‌طوری که -1 نشان‌دهندهٔ نزدیک‌ترین رله به کلاینت است. اگر کپسوله‌سازی درخواستی وجود نداشته باشد، رشتهٔ خالی "" برگردانده می‌شود. این عبارت تنها در DHCPv6 مجاز است.
  • عبارت relay6[nest].option[code] از همان انواع نمایش مشابه با option استفاده می‌کند؛ برای نمونه، relay6[nest].option[code].exists پشتیبانی می‌شود.
  • عبارت‌هایی که با pkt4 آغاز می‌شوند تنها در DHCPv4 قابل استفاده هستند. آن‌ها امکان دسترسی به فیلدهای پیام DHCPv4 را فراهم می‌کنند.
  • عبارت pkt6 به اطلاعات درخواست کلاینت اشاره دارد. برای دسترسی به اطلاعات رله‌های میانی، از relay6 استفاده کنید. pkt6.msgtype و pkt6.transid یک رشتهٔ باینری ۴ بایتی را برای نوع پیام یا شناسهٔ تراکنش خروجی می‌دهند. برای نمونه، نوع پیام SOLICIT برابر با 0x00000001 یا به‌سادگی 1 است، مانند pkt6.msgtype == 1.
  • منظور از "گزینهٔ سازنده" (Vendor option)، گزینهٔ Vendor-Identifying Vendor-Specific Information در DHCPv4 (کد 125؛ بخش ۴ از RFC 3925 https://datatracker.ietf.org/doc/html/rfc3925#section-4 را ببینید) و گزینهٔ Vendor-Specific Information Option در DHCPv6 (کد 17، تعریف‌شده در بخش ۲۱.۱۷ از RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915#section-21.17) است. منظور از "گزینهٔ کلاس سازنده" (Vendor class option)، گزینهٔ Vendor-Identifying Vendor Class Option در DHCPv4 (کد 124؛ بخش ۳ از RFC 3925 https://datatracker.ietf.org/doc/html/rfc3925#section-3 را ببینید) در DHCPv4 و گزینهٔ Class Option در DHCPv6 (کد 16؛ بخش ۲۱.۱۶ از RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915#section-21.16) است. گزینه‌های سازنده ممکن است زیرگزینه‌هایی داشته باشند که با کد مربوطه‌شان ارجاع داده می‌شوند. گزینه‌های کلاس سازنده فاقد زیرگزینه هستند، بلکه تکه‌های داده (data chunks) دارند که با مقدار نمایه ارجاع داده می‌شوند. نمایهٔ 0 به معنای نخستین تکهٔ داده، نمایهٔ 1 برای دومین تکهٔ داده (در صورت وجود) و به همین ترتیب است.
  • در ساختارهای vendor و vendor-class می‌توان از یک ستاره (*) یا 0 برای مشخص کردن مقدار عام‌کارت (wildcard) برای enterprise-id استفاده کرد، به این معنی که با هر مقدار enterprise-id مطابقت خواهد داشت.
  • شناسهٔ کلاس سازنده یا Vendor Class Identifier (گزینهٔ 60 در DHCPv4) با استفاده از عبارت option[60] قابل دسترسی است.
  • استانداردهای RFC 3925 https://datatracker.ietf.org/doc/html/rfc3925 و RFC 9915 https://datatracker.ietf.org/doc/html/rfc9915 اجازه می‌دهند که چندین نمونه از گزینه‌های سازنده در یک پیام ظاهر شوند. کد طبقه‌بندی کلاینت در حال حاضر در صورتی که بیش از یک مورد ظاهر شود، نخستین نمونه را بررسی می‌کند. برای عبارت‌های vendor.enterprise و vendor-class.enterprise، مقدار اولین نمونه برگردانده می‌شود. لطفاً برای درخواست پشتیبانی از چندین نمونه، یک درخواست قابلیت (feature request) در وب‌گاه گیت‌لب Kea به آدرس https://gitlab.isc.org/isc-projects/kea ثبت کنید.

نام مثال توضیحات
Equal 'foo' == 'bar' مقایسهٔ دو مقدار و برگرداندن true یا false
Match match('foo.*', 'foobar') تطبیق یک عبارت باقاعده با یک مقدار.
Not not ('foo' == 'bar') نقیض منطقی
And ('foo' == 'bar') and ('bar' == 'foo') «و»ی منطقی
Or ('foo' == 'bar') or ('bar' == 'foo') «یا»ی منطقی
Substring substring('foobar',0,3) برگرداندن زیررشتهٔ درخواست‌شده
Concat concat('foo','bar') برگرداندن الحاق رشته‌ها
Concat (عملگر +) 'foo' + 'bar' برگرداندن الحاق رشته‌ها
Ifelse ifelse('foo' == 'bar','us','them') برگرداندن مقدار شاخه بر اساس شرط
Hexstring hexstring('foo', '-') تبدیل مقدار به یک رشتهٔ هگزادسیمال، مانند 66-6F-6F
Lcase lcase('LoWeR') تبدیل مقدار یک عبارت رشته‌ای به حروف کوچک، مانند 'lower'
Ucase ucase('uPpEr') تبدیل مقدار یک عبارت رشته‌ای به حروف بزرگ، مانند 'UPPER'
Split split('foo.bar', '.', 2) برگرداندن فیلد دوم، با تفکیک بر اساس نقطه.
box center;
l|l|l.
نام مثال توضیحات
AddressToText addrtotext (192.10.0.1) addrtotext (2003:db8::) نمایش ۴ بایت از یک آدرس IPv4 یا ۱۶ بایت از یک آدرس IPv6 در قالب خوانا برای انسان
Int8ToText int8totext (-1) نمایش عدد صحیح علامت‌دار ۸ بیتی در قالب متنی
Int16ToText int16totext (-1) نمایش عدد صحیح علامت‌دار ۱۶ بیتی در قالب متنی
Int32ToText int32totext (-1) نمایش عدد صحیح علامت‌دار ۳۲ بیتی در قالب متنی
UInt8ToText uint8totext (255) نمایش عدد صحیح بدون علامت ۸ بیتی در قالب متنی
UInt16ToText uint16totext (65535) نمایش عدد صحیح بدون علامت ۱۶ بیتی در قالب متنی
UInt32ToText uint32totext (4294967295) نمایش عدد صحیح بدون علامت ۳۲ بیتی در قالب متنی

نکات:

عملگرهای تبدیل می‌توانند برای تبدیل داده‌ها از بازنمود باینری به متنی استفاده شوند. تنها شرط این است که طول نوع دادهٔ ورودی با مقدار مورد انتظار همخوانی داشته باشد.

نشانهٔ AddressToText برای آدرس‌های IPv4 انتظار ۴ بایت و برای آدرس‌های IPv6 انتظار ۱۶ بایت را دارد. نشانه‌های Int8ToText و UInt8ToText انتظار ۱ بایت، نشانه‌های Int16ToText و UInt16ToText انتظار ۲ بایت، و نشانه‌های Int32ToText و UInt32ToText انتظار ۴ بایت دارند. برای تمام نشانه‌های تبدیل، اگر طول داده ۰ باشد، رشتهٔ حاصل خالی خواهد بود.

دو گزارهٔ موجود Equal و Match هستند. می‌توان از آن‌ها برای ساخت سایر گزاره‌های متداول استفاده کرد، به عنوان مثال:

not (substring('foobar', 3, 3) == 'bar')
match('foo.*', lcase('FooBar'))
match('.*foo.*', 'is it foo or bar')
match('^.*foo.*$', 'is it foo or bar')

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

نکته:

عبارت‌های باقاعدهٔ نامعتبرِ شناسایی‌شده به عنوان خطای نحوی تلقی می‌شوند، و استثناهای زمان اجرا در حین تطبیق، به عنوان عدم تطبیق در نظر گرفته می‌شوند.

هشدار:

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

عملگرهای منطقی Not، And و Or از عملگرهای رایج هستند. Not بالاترین اولویت و Or پایین‌ترین اولویت را دارد. And و Or شرکت‌پذیر (از چپ) هستند. پرانتزها در اطراف یک عبارت منطقی می‌توانند برای اعمال یک گروه‌بندی مشخص استفاده شوند؛ برای نمونه در "A and (B or C)". بدون پرانتز، "A and B or C" به معنای "(A and B) or C" است.

عملگر زیررشته substring(value, start, length) مقادیر مثبت و منفی را برای موقعیت آغازین و طول می‌پذیرد. برای start، مقدار 0 بایت نخست در رشته است در حالی که -1 آخرین بایت است. اگر نقطه آغاز بیرون از رشته اصلی باشد، یک رشته خالی بازگردانده می‌شود. length تعداد بایت‌های مورد نظر برای استخراج است. یک مقدار منفی به معنای شمارش به سمت ابتدای رشته است اما بایتی را که توسط start مشخص شده شامل نمی‌شود. مقدار ویژه all به معنای بازگرداندن تمامی بایت‌ها از نقطه آغاز تا انتهای رشته است. اگر طول بیشتر از بخش باقی‌مانده رشته باشد، کل بخش باقی‌مانده بازگردانده می‌شود. ذکر چند مثال می‌تواند مفید باشد:

substring('foobar', 0, 6) == 'foobar'
substring('foobar', 3, 3) == 'bar'
substring('foobar', 3, all) == 'bar'
substring('foobar', 1, 4) == 'ooba'
substring('foobar', -5, 4) == 'ooba'
substring('foobar', -1, -3) == 'oba'
substring('foobar', 4, -2) == 'ob'
substring('foobar', 10, 2) == ''

تابع concat(string1, string2) حاصل الحاق دو آرگومان خود را برمی‌گرداند. برای نمونه:

concat('foo', 'bar') == 'foobar'

برای راحتی کاربر، نگارش 1.9.8 از Kea یک نسخه عملگر شرکت‌پذیر از تابع concat اضافه کرده است. برای نمونه:

'abc' + 'def' + 'ghi' + 'jkl' + '...'

هم‌ارز است با:

concat(concat(concat(concat('abc', 'def'), 'ghi'), 'jkl'), '...')

یا:

concat('abc', concat('def', concat('ghi', concat('jkl', '...'))))

یا:

'abcdefghijkl...'

عملگر تفکیک split(value, delimiters, field-number) فهرستی از نویسه‌ها را به عنوان جداکننده (delimiters) و یک شماره فیلد مثبت از فیلد مورد نظر پس از تقسیم مقدار به فیلدهای جداشده توسط جداکننده‌ها می‌پذیرد. جداکننده‌های مجاور ادغام و فشرده نمی‌شوند، بلکه منجر به یک رشته خالی برای آن شماره فیلد خواهند شد. اگر value یک رشته خالی باشد، خروجی یک رشته خالی خواهد بود. اگر فهرست delimiters خالی باشد، خروجی همان مقدار اولیه خواهد بود. اگر field-number کمتر از یک یا بیشتر از تعداد فیلدها باشد، خروجی رشته‌ای خالی خواهد بود. در ادامه چند مثال آورده شده است:

split ('one.two..four', '.', 1) == 'one'
split ('one.two..four', '.', 2) == 'two'
split ('one.two..four', '.', 3) == ''
split ('one.two..four', '.', 4) == 'four'
split ('one.two..four', '.', 5) == ''

نکته:

برای استفاده از نویسه‌ای با گریز (escape) دشوار به عنوان جداکننده، از مقدار هگزادسیمال ASCII آن استفاده کنید. برای نمونه، جداسازی با single quote با استفاده از 0x27: split(option[39].text, 0x27, 1)

تابع ifelse(cond, iftrue, ifelse) مقدار شاخه iftrue یا ifelse را با توجه به شرط بولی cond برمی‌گرداند. برای نمونه:

ifelse(option[230].exists, option[230].hex, 'none')

تابع hexstring(binary, separator) مقدار دودویی (binary) را به صورت نمایه‌ی رشته هگزادسیمال آن بازمی‌گرداند: جفت‌هایی از ارقام هگزادسیمال که با جداکننده از هم جدا شده‌اند، مانند ':'، '-'، '' (جداکننده خالی).

hexstring(pkt4.mac, ':')

نکته:

عبارت مربوط به هر کلاس با دریافت هر بسته پردازش و اجرا می‌شود. در صورتی که عبارت‌ها بیش از اندازه پیچیده باشند، زمان لازم برای اجرای آن‌ها ممکن است عملکرد سرور را تحت تأثیر قرار دهد. مدیران سیستمی که به عبارت‌های پیچیده یا زمان‌بر نیاز دارند باید نوشتن یک قلاب <#hooks-libraries> را برای انجام کارهای لازم مد نظر قرار دهند.

تعریف یک کلاس کلاینت می‌تواند شامل مشخصه‌های زیر باشد:
  • پارامتر name اجباری است و باید میان تمامی کلاس‌ها یکتا باشد.
  • عبارت test اجباری نیست و نشان‌دهنده رشته‌ای حاوی عبارت منطقی مورد استفاده برای تعیین عضویت در کلاس است. کل عبارت در علامت نقل‌قول جفتی (") قرار می‌گیرد. نتیجه باید به یک مقدار بولی (true یا false) ارزیابی شود.
  • عبارت template-test اجباری نیست و نشان‌دهنده رشته‌ای حاوی عبارت منطقی مورد استفاده برای تولید یک کلاس انشعابی (spawning class) است. کل عبارت در علامت نقل‌قول جفتی (") قرار می‌گیرد. نتیجه باید به یک مقدار رشته‌ای ارزیابی شود که بخش متغیرِ نام کلاس انشعاب‌یافته (spawned class) را نشان می‌دهد. اگر رشته حاصل خالی باشد، هیچ کلاس انشعابی تولید نمی‌شود. کلاس انشعاب‌یافته حاصل دارای قالب نام تولیدشده به این صورت خواهد بود: SPAWN_<template-class-name>_<evaluated-value>. پس از ارزیابی کلاس‌ها و تولید کلاس انشعاب‌یافته، نام کلاس الگوی متناظر نیز با بسته پیوند می‌یابد. گزینه‌ای (Option) که در یک کلاس انشعاب‌یافته مشخص شده باشد بر همان گزینه در صورت تنظیم در کلاس الگوی آن، ارجحیت خواهد داشت.
  • فهرست option-data اجباری نیست و شامل گزینه‌هایی است که باید به اعضای این کلاس اختصاص داده شوند. در مورد یک کلاس الگو، این گزینه‌ها به کلاس انشعاب‌یافتهٔ تولیدشده اختصاص می‌یابند.
  • فهرست option-def اجباری نیست و برای تعریف گزینه‌های سفارشی به کار می‌رود.
  • مشخصه only-if-required با only-in-additional-list جایگزین شده و اکنون منسوخ است. این مقدار برای مدتی به عنوان ورودی پذیرفته می‌شود تا به کاربران اجازه مهاجرت داده شود، اما در نهایت پشتیبانی از آن متوقف خواهد شد.
  • پرچم only-in-additional-list اجباری نیست؛ هنگامی که مقدار آن روی false (پیش‌فرض) تنظیم شود، عضویت در طول دسته‌بندی تعیین شده و برای نمونه جهت انتخاب زیرشبکه در دسترس است. هنگامی که مقدار روی true تنظیم شود، عضویت تنها در صورتی ارزیابی می‌شود که کلاس در فهرست evaluate-additional-classes وجود داشته باشد و تنها برای پیکربندی گزینه‌ها قابل استفاده خواهد بود.
  • مشخصه user-context اجباری نیست و نشان‌دهنده یک نگاشت با داده‌های تعریف‌شده توسط کاربر و احتمالاً گزینه‌های پیکربندی برای کتابخانه‌های قلاب (hook libraries) است.
  • پارامتر next-server اجباری نیست و فیلد siaddr را در بسته‌های مرتبط با این کلاس پیکربندی می‌کند. این پارامتر تنها در DHCPv4 کاربرد دارد.
  • مشخصه server-hostname اجباری نیست و فیلد sname را در بسته‌های مرتبط با این کلاس پیکربندی می‌کند. این مشخصه تنها در DHCPv4 کاربرد دارد.
  • مشخصه boot-file-name اجباری نیست و فیلد file را در بسته‌های مرتبط با این کلاس پیکربندی می‌کند. این مشخصه تنها در DHCPv4 کاربرد دارد.
  • مشخصه‌های valid-lifetime، min-valid-lifetime و max-valid-lifetime اجباری نیستند و فیلدهای طول عمر معتبر را برای این کلاس کلاینت پیکربندی می‌کنند.
  • مشخصه‌های preferred-lifetime، min-preferred-lifetime و max-preferred-lifetime اجباری نیستند و فیلدهای طول عمر ترجیحی را برای این کلاس کلاینت پیکربندی می‌کنند. این مشخصه‌ها تنها در DHCPv6 کاربرد دارند.

نکته:

test و template-test در تعریف یک کلاس کلاینت مانعة‌الجمع هستند. از یکی از آن‌ها استفاده کنید، یا از هیچ‌کدام، اما نه هر دو. در صورت ارائه هر دو، پیکربندی رد می‌شود.

در مثال زیر، کلاسی به نام Client_foo تعریف شده است. این کلاس شامل تمام کلاینت‌هایی است که شناسه کلاینت (گزینه ۶۱) آن‌ها با رشته foo آغاز می‌شود. به اعضای این کلاس، 192.0.2.1 و 192.0.2.2 به عنوان کارگزارهای نام دامنه اختصاص خواهد یافت.

"Dhcp4": {
    "client-classes": [
        {
            "name": "Client_foo",
            "test": "substring(option[61].hex,0,3) == 'foo'",
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "code": 6,
                    "space": "dhcp4",
                    "csv-format": true,
                    "data": "192.0.2.1, 192.0.2.2"
                }
            ]
        },
        ...
    ],
    ...
}

مثال بعدی تعریف یک کلاس کلاینت با نام "Client_enterprise" را برای استفاده توسط سرور DHCPv6 نشان می‌دهد. این کلاس شامل تمام کلاینت‌هایی است که شناسه کلاینت آن‌ها با رشته هگزادسیمال مشخص‌شده آغاز می‌شود، که نشان‌دهنده یک DUID بر اساس شناسه سازمانی 0x0002AABBCCDD است. به اعضای این کلاس، 2001:db8:0::1 و 2001:db8:2::1 به عنوان کارگزارهای نام دامنه اختصاص داده خواهد شد.

"Dhcp6": {
    "client-classes": [
        {
            "name": "Client_enterprise",
            "test": "substring(option[1].hex,0,6) == 0x0002AABBCCDD",
            "option-data": [
                {
                    "name": "dns-servers",
                    "code": 23,
                    "space": "dhcp6",
                    "csv-format": true,
                    "data": "2001:db8:0::1, 2001:db8:2::1"
                }
            ]
        },
        ...
    ],
    ...
}

همچنین این امکان وجود دارد که هر دو عملوند چپ و راست عبارت ارزیابی‌شده در زمان اجرا پردازش شوند. عبارت‌های مربوط به بسته‌ها می‌توانند به هر تعداد مورد نیاز در عبارت ظاهر شوند؛ هیچ محدودیتی وجود ندارد. با این حال، هر نشانه (token) تأثیر اندکی بر عملکرد دارد و عبارت‌های بیش از اندازه پیچیده ممکن است باعث ایجاد گلوگاه شوند.

"Dhcp4": {
    "client-classes": [
        {
            "name": "Infrastructure",
            "test": "option[82].option[2].hex == pkt4.mac",
            ...
        },
        ...
    ],
    ...
}

پارامتر template-test مشخص می‌کند که کلاس مربوطه یک کلاس الگو است.

"Dhcp4": {
    "client-classes": [
        {
            "name": "Client-ID",
            "template-test": "substring(option[61].hex,0,3)",
            ...
        },
        ...
    ],
    ...
}

اگر بسته DHCPv4 دریافت‌شده حاوی option 61 باشد، سه بایت اول نشان‌دهنده مقدار foo در ASCII خواهد بود و کلاس ایجادشده (spawned) از نام SPAWN_Client-ID_foo استفاده می‌کند. هر دو کلاس SPAWN_Client-ID_foo و Client-ID به بسته منتسب می‌شوند.

نکته:

کلاس‌های الگو همچنین می‌توانند برای ایجاد کلاس‌هایی استفاده شوند که با کلاس‌های عادی (regular) مطابقت دارند و بدین‌ترتیب عملاً کلاس عادی را به بسته منتسب می‌کنند. برای دستیابی به این هدف، کلاس عادی نیز باید شامل بخش ثابتِ نام کلاس ایجادشده باشد:

SPAWN_<template-class-name-used-to-activate-this-regular-class>_<evaluated-value-filtering-this-regular-class>

"Dhcp6": {
    "client-classes": [
        {
            "name": "SPAWN_Client-ID_foobar",
            "test": "substring(option[1].hex,0,6) == 0x0002AABBCCDD",
            ...
        },
        {
            "name": "Client-ID",
            "template-test": "substring(option[1].hex,0,6)",
            ...
        },
        ...
    ],
    ...
}

اگر بسته DHCPv6 دریافت‌شده حاوی option 1 (شناسه کلاینت) با مقدار هگزادسیمال 0x0002AABBCCDD باشد، کلاس SPAWN_Client-ID_foobar به بسته منتسب می‌شود. علاوه بر این، اگر شش بایت اول نمایانگر مقدار foobar در ASCII باشد، کلاس ایجادشده از نام SPAWN_Client-ID_foobar استفاده کرده و عملاً کلاس عادی را به بسته منتسب می‌نماید. در این حالت دوم، هر دو کلاس SPAWN_Client-ID_foobar و Client-ID به بسته منتسب می‌شوند. عبارت test در کلاس عادی SPAWN_Client-ID_foobar اجباری نیست و می‌تواند حذف شود، اما در اینجا با یک عبارت تطبیق متفاوت صرفاً با هدف مثال به کار رفته است.

معمولاً عبارت‌های test و template-test پیش از انتخاب زیرشبکه (subnet) ارزیابی می‌شوند، اما در برخی موارد ارزیابی آن‌ها در مراحل بعد، زمانی که subnet، شبکه مشترک (shared network) یا poolها مشخص شده‌اند ولی پردازش گزینه‌های خروجی (output-option processing) هنوز انجام نشده است، مفید خواهد بود. برای این منظور، پرچم only-in-additional-list که به‌طور پیش‌فرض false است، اجازه می‌دهد عبارت test یا عبارت template-test تنها در صورتی ارزیابی شوند که به‌واسطه حضور کلاس در فهرست evaluate-additional-classes متعلق به pool، subnet یا shared network انتخاب‌شده درخواست شده باشند.

فهرست evaluate-additional-classes که برای دامنه‌های pool، subnet و shared-network معتبر است، کلاس‌هایی را مشخص می‌کند که در دور دوم ارزیابی و پیش از پردازش گزینه‌های خروجی بررسی می‌شوند. این فهرست با همان اولویت داده‌های گزینه (option data) ساخته می‌شود؛ یعنی یک داده گزینه در subnet نسبت به مورد مشابه در shared network اولویت دارد. یک کلاس اضافی در subnet، پیش از کلاسی در shared network اضافه می‌شود. این سازوکار با پرچم only-in-additional-list مرتبط است، اما اجباری نیست که این پرچم حتماً روی true تنظیم شده باشد.

نکته:

عبارت template-test همچنین می‌تواند برای فیلتر کردن کلاس‌های ایجادشده به کار رود، به‌طوری که با استفاده از دستور ifelse این کلاس‌ها فقط در صورت نیاز ساخته شوند.
"Dhcp4": {
    "client-classes": [
        {
            "name": "Client-ID",
            "template-test": "ifelse(substring(option[61].hex,4,3) == 'foo', substring(option[12].hex,0,12), '')",
            ...
        },
        ...
    ],
    ...
}

نکته:

کلاس‌های الگو را می‌توان برای پیکربندی محدودیت‌ها (limits) به کار برد که دقیقاً مانند گزینه‌ها، به کلاس ایجادشده منتسب می‌شوند. این امر امکان پیکربندی محدودیت‌هایی را فراهم می‌سازد که بر تمام بسته‌های منتسب به کلاسی که در زمان اجرا (runtime) بر اساس عبارت template-test در کلاس الگوی والد ایجاد شده است، اعمال شوند. برای توضیحات دقیق‌تر درباره نحوه پیکربندی محدودیت‌ها با استفاده از کتابخانه قلاب limits، به Configuration <#hooks-limits-configuration> مراجعه کنید. برای مثال، با استفاده از پیکربندی زیر، بسته‌های DHCPv6 ورودی (ingress) که دارای مقادیر شناسه کلاینت (در قالبی که توسط ارزیاب Kea بیان می‌شود) foobar و foofoo باشند، هر دو مشمول همان سقف ۶۰ بسته در روز می‌شوند، در حالی که بسته‌های دیگر که سه هگزاست (hextet) اول آن‌ها مقداری غیر از foo دارد، در سطل‌های مجزای محدودسازی نرخ (rate-limiting buckets) قرار می‌گیرند.
"Dhcp6": {
    "client-classes": [
        {
            "name": "Client-ID",
            "template-test": "substring(option[1].hex,0,3)",
            "user-context" : {
                "limits": {
                    "rate-limit": "60 packets per day"
                }
            },
            ...
        },
        ...
    ],
    ...
}

کلاس‌ها می‌توانند با استفاده از روش‌های شرح‌داده‌شده در «رزرو کلاس‌های کلاینت در DHCPv4» <#reservation4-client-classes> و «رزرو کلاس‌های کلاینت در DHCPv6» <#reservation6-client-classes> به صورت ایستا به کلاینت‌ها اختصاص یابند.

رزروهای میزبان در سطح زیرشبکه (subnet)، پس از انتخاب زیرشبکه جستجو می‌شوند. رزروهای سراسری میزبان (global) به طور پیش‌فرض در همان زمان جستجو می‌شوند، اما پارامتر early-global-reservations-lookup امکان تغییر این رفتار را برای جستجوی آن‌ها پیش از انتخاب زیرشبکه فراهم می‌کند.

انتخاب استخر (pool) پس از تمام جستجوهای رزرو میزبان انجام می‌شود.

در موارد خاص، محدود کردن دسترسی به برخی زیرشبکه‌ها تنها به کلاینت‌هایی که متعلق به یک کلاس مشخص هستند، با استفاده از پارامتر client-classes هنگام تعریف زیرشبکه سودمند است. این پارامتر می‌تواند برای تعیین فهرستی از یک یا چند کلاس به کار رود که کلاینت‌ها به منظور استفاده از زیرشبکه باید متعلق به آن‌ها باشند. این سازوکار را می‌توان به عنوان «محافظ کلاس» (class guard) برای زیرشبکه در نظر گرفت، یا به عبارت دیگر، زیرشبکه توسط یک کلاس کلاینت محافظت می‌شود.

فرض کنید سرور به بخشی از شبکه متصل است که از پیشوند 192.0.2.0/24 استفاده می‌کند. مدیر آن شبکه تصمیم گرفته است که نشانی‌های بازه 192.0.2.10 تا 192.0.2.20 توسط سرور DHCPv4 مدیریت شوند. تنها کلاینت‌های متعلق به کلاس کلاینت Client_foo مجاز به استفاده از این زیرشبکه هستند. چنین پیکربندی‌ای را می‌توان به روش زیر انجام داد:

"Dhcp4": {
    "client-classes": [
        {
            "name": "Client_foo",
            "test": "substring(option[61].hex,0,3) == 'foo'",
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "code": 6,
                    "space": "dhcp4",
                    "csv-format": true,
                    "data": "192.0.2.1, 192.0.2.2"
                }
            ]
        },
        ...
    ],
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "client-classes": [ "Client_foo" ]
        },
        ...
    ],
    ...
}

مثال زیر نحوه محدود کردن دسترسی به یک زیرشبکه DHCPv6 را نشان می‌دهد. این پیکربندی، استفاده از نشانی‌های بازه 2001:db8:1::1 تا 2001:db8:1::FFFF را به اعضای کلاس "Client_enterprise" محدود می‌کند.

"Dhcp6": {
    "client-classes": [
        {
            "name": "Client_enterprise",
            "test": "substring(option[1].hex,0,6) == 0x0002AABBCCDD",
            "option-data": [
                {
                    "name": "dns-servers",
                    "code": 23,
                    "space": "dhcp6",
                    "csv-format": true,
                    "data": "2001:db8:0::1, 2001:db8:2::1"
                }
            ]
        },
        ...
    ],
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/64",
            "pools": [ { "pool": "2001:db8:1::-2001:db8:1::ffff" } ],
            "client-classes": "Client_enterprise"
        }
    ],
    ...
}

مشابه زیرشبکه‌ها، در موارد خاص دسترسی به برخی استخرهای نشانی یا پیشوند باید تنها به کلاینت‌هایی محدود شود که دست‌کم به یکی از کلاس‌های مشخص‌شده در فهرست تعلق دارند؛ این کار با استفاده از پارامتر client-classes هنگام تعریف استخر انجام می‌گیرد. این موضوع را می‌توان به عنوان «محافظ کلاس» (class guard) برای استخر در نظر گرفت، یا به عبارت دیگر، استخر توسط یک کلاس کلاینت محافظت می‌شود.

فرض کنید سرور به بخشی از شبکه متصل است که از پیشوند 192.0.2.0/24 استفاده می‌کند. مدیر آن شبکه تصمیم گرفته است که نشانی‌های بازه 192.0.2.10 تا 192.0.2.20 توسط سرور DHCPv4 مدیریت شوند. تنها کلاینت‌های متعلق به کلاس کلاینت Client_foo مجاز به استفاده از این استخر هستند. چنین پیکربندی‌ای را می‌توان به روش زیر انجام داد:

"Dhcp4": {
    "client-classes": [
        {
            "name": "Client_foo",
            "test": "substring(option[61].hex,0,3) == 'foo'",
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "code": 6,
                    "space": "dhcp4",
                    "csv-format": true,
                    "data": "192.0.2.1, 192.0.2.2"
                }
            ]
        },
        ...
    ],
    "subnet4": [
        {
            "id": 1,
            "subnet": "192.0.2.0/24",
            "pools": [
                {
                    "pool": "192.0.2.10 - 192.0.2.20",
                    "client-classes": [ "Client_foo" ]
                }
            ]
        },
        ...
    ],
    ...
}

مثال زیر نحوه محدود کردن دسترسی به یک استخر نشانی را نشان می‌دهد. این پیکربندی، استفاده از نشانی‌های بازه 2001:db8:1::1 تا 2001:db8:1::FFFF را به اعضای کلاس "Client_enterprise" محدود می‌کند.

"Dhcp6": {
    "client-classes": [
        {
            "name": "Client_enterprise_",
            "test": "substring(option[1].hex,0,6) == 0x0002AABBCCDD",
            "option-data": [
                {
                    "name": "dns-servers",
                    "code": 23,
                    "space": "dhcp6",
                    "csv-format": true,
                    "data": "2001:db8:0::1, 2001:db8:2::1"
                }
            ]
        },
        ...
    ],
    "subnet6": [
        {
            "id": 1,
            "subnet": "2001:db8:1::/64",
            "pools": [
                {
                    "pool": "2001:db8:1::-2001:db8:1::ffff",
                    "client-classes": [ "Client_foo" ]
                }
            ]
        },
        ...
    ],
    ...
}

کلاس‌های کلاینت در Kea از ترتیبی که در پیکربندی مشخص شده‌اند پیروی می‌کنند (در مقایسه با ترتیب الفبایی). کلاس‌های اضافی به ترتیبِ pool، سپس subnet و سپس shared-network، و در هر محدوده (scope) بر اساس ترتیبی که در evaluate-additional-classes ظاهر می‌شوند، مرتب می‌گردند.

هنگام تعیین اینکه کدام اطلاعات client-class (شامل گزینه‌ها، طول‌عمر اجاره‌ها، یا مقادیر فیلد DHCPv4) بخشی از تعاریف کلاس هستند که باید در پاسخ گنجانده شوند، کارساز اجتماعِ گزینه‌های تمام کلاس‌های انتساب‌یافته را بررسی می‌کند. اگر دو یا چند کلاس شامل اطلاعات کلاس یکسانی باشند، مقدار اولین کلاسِ انتساب‌یافته استفاده می‌شود. ALL همیشه اولین کلاس است، یعنی کلاسی با بالاترین اولویت، و کلاس‌های منطبقِ الزامی (required) در انتها قرار دارند، بنابراین کمترین اولویت را دارند.

گزینه‌های تعریف‌شده در کلاس‌ها بر هر گزینه سراسری (global) اولویت داشته و جایگزین آن می‌شوند، و به نوبه خود توسط گزینه‌های تعریف‌شده برای یک subnet، shared network، pool یا reservation جداگانه لغو و بازنویسی (override) می‌شوند.

از سوی دیگر، طول‌عمر اجاره‌ها و مقادیر فیلدهای DHCPv4 تعریف‌شده در محدوده کلاس، بر هر مقدار تعریف‌شده به‌صورت سراسری، در محدوده subnet یا در محدوده shared-network اولویت دارند و جایگزین آن‌ها می‌شوند.

نکته:

از آنجا که ارزیابی اضافی پس از تخصیص اجاره رخ می‌دهد، پارامترهایی که در غیر این صورت بر طول‌عمر اجاره تأثیر می‌گذاشتند (مانند valid-lifetime و offer-lifetime) هنگامی که در کلاسی مشخص شوند که only-in-additional-list را نیز برابر با true قرار داده است، هیچ تأثیری نخواهند داشت.

به عنوان مثال، تصور کنید یک بسته ورودی با دو کلاس مطابقت دارد. کلاس foo مقادیری برای یک سرور NTP (گزینه 42 در DHCPv4) و یک سرور SMTP (گزینه 69 در DHCPv4) تعریف می‌کند، در حالی که کلاس bar مقادیری برای یک سرور NTP و یک سرور POP3 (گزینه 70 در DHCPv4) تعریف می‌کند. کارساز سه گزینه - یعنی NTP، SMTP و POP3 - را بررسی کرده و هر کدام را که کلاینت درخواست کرده باشد بازمی‌گرداند. از آنجا که سرور NTP دو بار تعریف شده است، کارساز فقط یکی از مقادیر را برای پاسخ انتخاب می‌کند؛ کلاسی که مقدار از آن گرفته می‌شود طبق توضیحات بندهای قبلی تعیین می‌گردد.

برچسب‌گذاری کلاسی گزینه‌ها (Option class-tagging) اجازه می‌دهد تا مقدار یک گزینه بر اساس عضویت کلاینت در کلاس، به‌صورت مشروط بر پاسخ اعمال شود. تأثیر آن مشابه استفاده از یک بلوک if در ISC DHCP برای گنجاندن شرطی گزینه‌ها در یک محدوده مشخص است. برچسب‌گذاری کلاسی با مشخص کردن فهرستی از یک یا چند نام کلاس در مدخل client-classes مربوط به گزینه انجام می‌شود.

حالتی را در نظر بگیرید که در آن اعضای یک کلاس معین به مقداری یکسان برای یک گزینه، اما مقداری مختص به زیرشبکه (subnet-specific) برای گزینه‌ای دیگر نیاز دارند. مثال زیر نشان می‌دهد که چگونه از برچسب‌گذاری کلاسی استفاده شده تا به کلاینت‌های متعلق به "GROUP1" یک مقدار مختص زیرشبکه برای گزینه "bar" اختصاص داده شود، در حالی که به تمام اعضای "GROUP1" همان مقدار یکسان برای گزینه "foo" داده می‌شود:

{
    "client-classes": [
    {
        "name": "GROUP1",
        "test":"substring(option[123].hex,0,4) == 'ONE'",
        "option-data": [{
            "name": "foo",
            "data": "somefile.txt"
        }]
    }],
    "subnet4": [
    {
        "id": 1,
        "subnet": "178.16.1.0/24",
        "option-data": [{
            "client-classes": ["GROUP1"],
            "name": "bar",
            "data": 123
        }]
    },
    {
        "id": 2,
        "subnet": "178.16.2.0/24",
        "option-data": [
        {
            "client-classes": ["GROUP1"],
            "name": "bar",
            "data": 789
        }]
    }]
}

فهرست client-classes در مشخصات گزینه در هر محدوده‌ای (scope) مجاز است. برچسب‌گذاری کلاسی گزینه در زمان اضافه شدن گزینه‌ها به پاسخ اعمال می‌شود؛ یعنی پس از تخصیص اجاره و درست قبل از ارسال پاسخ به کلاینت.

هنگامی که never-send برای یک گزینه در هر محدوده‌ای برابر با true باشد، تمام مدخل‌های client-classes برای آن گزینه نادیده گرفته می‌شوند. این گزینه گنجانده نخواهد شد.

هنگامی که always-send در هر محدوده‌ای برابر با true باشد، گزینه گنجانده خواهد شد؛ مگر اینکه گزینه تعیین‌شده بر اساس محدوده، فهرست client-classes را به‌گونه‌ای مشخص کرده باشد که شامل هیچ‌یک از کلاس‌های کلاینت نباشد.

در غیر این صورت، گزینه درخواست‌شده توسط کلاینت در صورتی در پاسخ گنجانده می‌شود که یا آن گزینه client-classes را مشخص نکرده باشد، یا کلاینت حداقل به یکی از کلاس‌های موجود در client-classes تعلق داشته باشد.

هنگامی که برچسب کلاسی یک گزینه مطابقت ندارد، درست مانند این است که گزینه در آن محدوده مشخص نشده باشد. در مثال زیر، گزینه "foo" هم برای subnet و هم برای pool مشخص شده است. مشخصات pool شامل یک برچسب کلاسی است که این گزینه را به اعضای کلاس "melon" محدود می‌کند:

{
    "id": 100,
    "subnet": "178.16.1.0/24",
    "option-data": [{
        "name": "foo",
        "data": 456
    }],
    "pools": [{
        "pool": "178.16.1.100 - 178.16.1.200",
        "option-data": [{
            "name": "foo",
            "data": 123,
            "client-classes" : [ "melon" ]
        }]
    }]
}

کلاینت‌هایی که با کلاس "melon" مطابقت دارند مقدار 123 را برای گزینه "foo" خواهند داشت، در حالی که کلاینت‌هایی که با "melon" مطابقت ندارند مقدار 456 را برای گزینه "foo" دریافت خواهند کرد.

می‌توان با مشخص کردن بیش از یک باره یک گزینه با برچسب‌های کلاسی و مقادیر مختلف، به رفتاری مشابه if-elseif-else دست یافت. پیکربندی زیر را برای یک زیرشبکه در نظر بگیرید که سه مقدار ممکن را برای گزینه "server-str" فراهم می‌کند:

{
    "id": 1,
    "subnet": "192.0.1.0/24",
    "pools": [{ "pool": "192.0.1.1 - 192.0.1.255" }],
    "option-data": [{
        "client-classes":  [ "class-one" ],
        "name": "server-str",
        "data": "string.one"
    },{
        "client-classes":  [ "class-two" ],
        "name": "server-str",
        "data": "string.two"
    },{
        "name": "server-str",
        "data": "string.other"
   }]
}

کلاینت‌های متعلق به "class-one" مقدار "string.one"، کلاینت‌های متعلق به "class-two" مقدار "string.two"، و کلاینت‌هایی که نه به "class-one" و نه به "class-two" تعلق دارند، مقدار "string.other" را دریافت خواهند کرد.

نکته:

ترتیب بررسی گزینه‌ها تضمین‌شده نیست، به جز اینکه گزینه‌ای با فهرست خالی "client-classes" در انتها بررسی می‌شود.

نکته:

اگرچه مثال‌های بالا برای DHCPv4 هستند، نحو و رفتار برچسب‌گذاری کلاسی برای DHCPv6 نیز یکسان است.

می‌توان از قلاب‌ها (hooks) برای دسته‌بندی بسته‌ها استفاده کرد. این کار ممکن است زمانی مفید باشد که نوشتن عبارت پیچیده یا زمان‌بر باشد، و بتوان آن را بهتر یا ساده‌تر به‌صورت کد نوشت. هنگامی که قلاب نام کلاس مناسب را به بسته اضافه کرد، بقیهٔ سیستم دسته‌بندی طبق انتظار در انتخاب یک زیرشبکه و گزینه‌ها عمل خواهد کرد. برای توضیحات دربارهٔ قلاب‌ها، به Hook Libraries <#hooks-libraries> مراجعه کنید؛ برای اطلاعات دربارهٔ پیکربندی کلاس‌ها، به Configuring Classes and Configuring Subnets With Class Information مراجعه نمایید.

هنگام ساخت عبارت‌های دسته‌بندی، مدیران سیستم ممکن است فعال‌سازی ثبت وقایع (logging) را مفید بیابند؛ برای توضیحات کامل‌تر دربارهٔ امکانات ثبت وقایع، به Logging <#logging> مراجعه کنید.

برای فعال‌سازی گزاره‌های اشکال‌زدایی در سیستم دسته‌بندی، سطح اهمیت باید روی DEBUG و سطح اشکال‌زدایی حداقل روی ۵۵ تنظیم شود. لاگرهای اختصاصی عبارتند از kea-dhcp4.eval و kea-dhcp6.eval.

برای درک گزاره‌های ثبت وقایع، ضروری است تا حدودی با نحوهٔ ارزیابی عبارت‌ها آشنا باشید؛ برای توضیحات کامل‌تر، به [سند طراحی](https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/client-classification-design) مراجعه کنید. به‌طور خلاصه، در طول ارزیابی یک عبارت از دو ساختار استفاده می‌شود: فهرستی از نشانه‌ها (tokens) که نمایانگر عبارت‌ها هستند، و یک پشتهٔ مقادیر (value stack) که نمایانگر مقادیر در حال دستکاری است.

فهرست نشانه‌ها هنگام پردازش فایل پیکربندی ایجاد می‌شود و بیشتر عبارت‌ها و مقادیر به یک نشانه تبدیل می‌شوند. این فهرست بر اساس نمادگذاری معکوس لهستانی (RPN) سازماندهی شده است. در طول اجرا، فهرست به ترتیب پیمایش می‌شود؛ با اجرای هر نشانه، امکان برداشتن (pop) مقادیر از بالای پشته و در نهایت قرار دادن (push) نتیجه روی بالای پشته فراهم می‌شود. عبارت زیر را در نظر بگیرید:

"test": "substring(option[61].hex,0,3) == 'foo'",

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

option, number (0), number (3), substring, text ('foo'), equals

در این مثال، سه نشانهٔ اول صرفاً مقادیر را روی پشته قرار می‌دهند. سپس نشانهٔ substring آن سه مقدار را برمی‌دارد و نتیجه‌ای را محاسبه می‌کند که روی پشته قرار می‌دهد. گزینهٔ text نیز مقداری را روی پشته می‌گذارد، و در نهایت نشانهٔ equals دو نشانهٔ روی پشته را برمی‌دارد و نتیجه‌اش را روی پشته می‌گذارد.

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

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

فرض کنیم آزمایش زیر در پیکربندی وارد شده است. این مثال از بخش عمدهٔ پیکربندی صرف‌نظر می‌کند تا روی آزمایش تمرکز کند.

"test": "substring(option[61].hex,0,3) == 'foo'",

ثبت وقایع ممکن است به این شکل باشد:

2016-05-19 13:35:04.163 DEBUG [kea.eval/44478] EVAL_DEBUG_OPTION Pushing option 61 with value 0x666F6F626172
2016-05-19 13:35:04.164 DEBUG [kea.eval/44478] EVAL_DEBUG_STRING Pushing text string '0'
2016-05-19 13:35:04.165 DEBUG [kea.eval/44478] EVAL_DEBUG_STRING Pushing text string '3'
2016-05-19 13:35:04.166 DEBUG [kea.eval/44478] EVAL_DEBUG_SUBSTRING Popping length 3, start 0, string 0x666F6F626172 pushing result 0x666F6F
2016-05-19 13:35:04.167 DEBUG [kea.eval/44478] EVAL_DEBUG_STRING Pushing text string 'foo'
2016-05-19 13:35:04.168 DEBUG [kea.eval/44478] EVAL_DEBUG_EQUAL Popping 0x666F6F and 0x666F6F pushing result 'true'

نکته:

در صورت وجود چندین عبارت برای ارزیابی، ثبت وقایع اشکال‌زدایی ممکن است بسیار پرحجم باشد؛ هدف از آن، کمک به ایجاد و اشکال‌زدایی عبارت‌ها است. مدیران سیستم باید پس از اطمینان از عملکرد صحیح عبارت‌ها، ثبت وقایع اشکال‌زدایی را غیرفعال کنند. همچنین کاربران ممکن است ترجیح دهند در زمان اشکال‌زدایی، تنها یک مجموعه از عبارت‌ها را در فایل پیکربندی قرار دهند تا گزاره‌های گزارش محدود شوند. به عنوان مثال، هنگام افزودن یک مجموعه عبارت جدید، ممکن است برای مدیر سیستم راحت‌تر باشد که فایلی از پیکربندی بسازد که تنها شامل عبارت‌های جدید باشد تا زمانی که به درستی کار کنند، و سپس مجموعهٔ جدید را به فایل پیکربندی اصلی اضافه کند.

‏Kea از طریق استفاده از «قلاب‌ها» ("hooks")، هم انعطاف‌پذیر و هم قابل سفارشی‌سازی است. این ویژگی به Kea اجازه می‌دهد یک یا چند کتابخانه با پیوند پویا (که به نام «کتابخانه‌های قلاب» یا "hook libraries" شناخته می‌شوند) را بارگذاری کرده و توابع درون آن‌ها را در نقاط مختلفی از پردازش خود («نقاط قلاب» یا "hook points") فراخوانی کند. این توابع هر پردازش سفارشی لازم را انجام می‌دهند.

مفهوم قلاب‌ها به کد اصلی Kea اجازه می‌دهد تا با انتقال قابلیت‌هایی که فقط برای برخی (نه همه) از کاربران مفید است به کتابخانه‌های خارجی، در حجمی مناسب باقی بماند. کاربرانی که به توابع خاصی نیاز ندارند می‌توانند به‌سادگی از بارگذاری آن کتابخانه‌ها صرف‌نظر کنند.

کتابخانه‌های قلاب توسط هر یک از فرآیندهای مجزای Kea بارگذاری می‌شوند، نه به صورت کلی توسط کل Kea. این یعنی در میان موارد دیگر، می‌توان یک مجموعه از کتابخانه‌ها را به کارگزار DHCPv4 و مجموعه‌ای دیگر را به کارگزار DHCPv6 اختصاص داد.

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

هنگامی که یک فرآیند Kea کتابخانه‌ای را تخلیه (unload) می‌کند، انتظار دارد تابع dlclose تمام نمادهای کتابخانه و همچنین کد آن را از فضای آدرس حذف کند. گرچه بیشتر سیستم‌عامل‌ها تابع dlclose را پیاده‌سازی کرده‌اند، اما این رفتار طبق استاندارد POSIX الزامی نیست و همهٔ سیستم‌ها از آن پشتیبانی نمی‌کنند؛ برای نمونه، کتابخانهٔ musl که به‌طور پیش‌فرض در Alpine Linux استفاده می‌شود، تابع dlclose را به‌صورت بی‌عملیات (no-op) پیاده‌سازی کرده است. در چنین سیستم‌هایی، کتابخانه در عمل در تمام طول عمر فرآیند بارگذاری‌شده باقی می‌ماند، به این معنی که برای به‌روزرسانی کتابخانه‌ها به نسخه‌های جدیدتر، فرآیند باید دوباره راه‌اندازی (restart) شود؛ صرفِ پیکربندی مجدد یا بارگذاری مجدد (reload) فرآیند Kea کافی نخواهد بود.

بخش‌های بعدی نحوهٔ نصب و پیکربندی کتابخانه‌های قلاب را شرح می‌دهند. کاربرانی که علاقه‌مند به نوشتن کتابخانهٔ قلاب خود هستند می‌توانند اطلاعات لازم را در بخش Hooks Developer's Guide از راهنمای Kea Developer's Guide https://reports.kea.isc.org/dev_guide/df/d46/hooksdgDevelopersGuide.html بیابند.

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

همچنین لطفاً توجه داشته باشید که برخی از کتابخانه‌ها ممکن است به وابستگی‌های اضافی و/یا فعال بودن کلیدهای کامپایل خاصی نیاز داشته باشند..SS "نصب بسته‌های قلاب (Hook Packages)"

نکته:

برای جزئیات بیشتر درباره نصب قلاب‌های مشترکین Kea، لطفاً این مقاله پایگاه دانش را بخوانید: https://kb.isc.org/docs/aa-01587.

بیشتر بسته‌های قلاب اکنون در سورس‌های اصلی Kea گنجانده شده‌اند. نیازی به انجام کار خاصی برای کامپایل یا نصب آن‌ها نیست، چرا که آن‌ها توسط روال‌های معمول ساخت و نصب پوشش داده می‌شوند. لطفاً برای یک نمای کلی از فرآیند نصب، به Installation <#installation> مراجعه کنید.

شرکت ISC چندین قلاب اضافی مخصوص مشترکین را در قالب بسته ارائه می‌دهد که روال نصب مشابهی دارند اما نیازمند چند مرحله بیشتر هستند. جهت راحتی کاربران، فرآیند نصب قلاب‌های مشترکین در این بخش شرح داده شده است.

1. بسته را دانلود کنید؛ دستورالعمل‌های دقیق در مقاله پایگاه دانش بالا ارائه شده است. بسته فایلی با نامی مشابه kea-subscriber-|release|.tar.xz خواهد بود.

2. مدیران سیستمی که از زمان نصب اولیه Kea، سورس‌های نسخه مربوط به بسته متن‌باز Kea را روی سیستم خود دارند، باید این مرحله را نادیده بگیرند. در غیر این صورت، سورس Kea را از tarball اصلی دانلود شده استخراج کنید. برای مثال، با دانلود Kea 3.2.0، باید یک tarball به نام kea-|release|.tar.xz روی سیستم موجود باشد. این tarball را استخراج کنید:

$ tar -Jxvf kea-3.2.0.tar.xz

این کار tarball را در زیردایرکتوری kea-|release| از دایرکتوری کاری فعلی استخراج می‌کند.

3. بسته tarball قلاب‌های مشترکین Kea را در همان دایرکتوری که سورس اصلی Kea در آن قرار دارد استخراج کنید. هنگامی که Kea 3.2.0 در زیردایرکتوری kea-|release| استخراج شد و tarball مشترکین Kea در دایرکتوری فعلی قرار گرفت، مراحل زیر tarball مشترکین را در مکان مناسب استخراج خواهند کرد:

$ cd kea-3.2.0
$ tar -Jxvf ../kea-subscriber-3.2.0.tar.xz

توجه داشته باشید که استخراج بسته مشترکین Kea، فایل‌ها را در دایرکتوری با نام premium قرار می‌دهد. صرف‌نظر از نام بسته، این دایرکتوری همیشه premium نامیده می‌شود.

4.
فرآیند ساخت (build) را آماده‌سازی کنید. مطمئن شوید که meson و ninja روی سیستم شما نصب شده‌اند. بخش اول خروجی باید چیزی شبیه به این باشد:
$ meson setup build
Package:
  Name:               kea
  Version:            3.2.0
  Extended version:   3.2.0 (tarball)
  Version type:       development
  OS Family:          Linux
  Prefix:             /opt/kea
  Hooks directory:    /opt/kea/lib/kea/hooks
  Premium hooks:      yes
6.
کامپایل Kea.
$ meson compile -C build
7.
نصب سورس‌های Kea همراه با قلاب‌ها:
$ sudo make install

مکان نصب کتابخانه‌های قلاب به این بستگی دارد که آیا پارامتر --prefix در مرحله meson setup مشخص شده بود یا خیر. در غیر این صورت، مکان پیش‌فرض /usr/local/lib/kea/hooks خواهد بود. نصب صحیح کتابخانه‌ها را می‌توان با این دستور بررسی کرد:

$ ls -l /usr/local/lib/kea/hooks/*.so
/usr/local/lib/kea/hooks/libddns_gss_tsig.so
/usr/local/lib/kea/hooks/libdhcp_bootp.so
/usr/local/lib/kea/hooks/libdhcp_class_cmds.so
/usr/local/lib/kea/hooks/libdhcp_ddns_tuning.so
/usr/local/lib/kea/hooks/libdhcp_flex_id.so
/usr/local/lib/kea/hooks/libdhcp_flex_option.so
/usr/local/lib/kea/hooks/libdhcp_ha.so
/usr/local/lib/kea/hooks/libdhcp_host_cache.so
/usr/local/lib/kea/hooks/libdhcp_host_cmds.so
/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so
/usr/local/lib/kea/hooks/libdhcp_lease_query.so
/usr/local/lib/kea/hooks/libdhcp_legal_log.so
/usr/local/lib/kea/hooks/libdhcp_limits.so
/usr/local/lib/kea/hooks/libdhcp_mysql.so
/usr/local/lib/kea/hooks/libdhcp_perfmon.so
/usr/local/lib/kea/hooks/libdhcp_pgsql.so
/usr/local/lib/kea/hooks/libdhcp_ping_check.so
/usr/local/lib/kea/hooks/libdhcp_radius.so
/usr/local/lib/kea/hooks/libdhcp_run_script.so
/usr/local/lib/kea/hooks/libdhcp_stat_cmds.so
/usr/local/lib/kea/hooks/libdhcp_subnet_cmds.so

همراه با کتابخانه‌های مشترکین زیر:

/usr/local/lib/kea/hooks/libdhcp_cb_cmds.so
/usr/local/lib/kea/hooks/libdhcp_rbac.so

فهرست دقیق بازگردانده شده به بسته‌های نصب‌شده بستگی دارد. اگر دایرکتوری از طریق --prefix مشخص شده باشد، کتابخانه‌های قلاب در {prefix directory}/lib/kea/hooks قرار خواهند گرفت..SS پیکربندی کتابخانه‌های هوک (Configuring Hook Libraries)

کتابخانه‌های هوک (hook libraries) برای یک فرآیند مشخص با استفاده از کلمهٔ کلیدی hooks-libraries در پیکربندی آن فرآیند پیکربندی می‌شوند. (توجه داشته باشید که واژهٔ "hooks" جمع است.) مقدار این کلمهٔ کلیدی آرایه‌ای از ساختارهای نگاشت (map structures) است، که هر ساختار متناظر با یک کتابخانهٔ هوک می‌باشد. برای نمونه، جهت راه‌اندازی دو کتابخانهٔ هوک برای سرور DHCPv4، پیکربندی به صورت زیر خواهد بود:

{
    "Dhcp6": {
        "hooks-libraries": [
            {
                "library": "first_custom_hooks_example.so"
            },
            {
                "library": "second_custom_hooks_example.so",
                "parameters": {
                    "mail": "spam@example.com",
                    "floor": 13,
                    "debug": false,
                    "users": [
                        "alice",
                        "bob",
                        "charlie"
                    ],
                    "languages": {
                        "french": "bonjour",
                        "klingon": "yl'el"
                    }
                }
            }
        ]
    }
}

نکته:

کتابخانه‌ها حتی اگر فهرست آن‌ها تغییری نکرده باشد مجدداً بارگذاری می‌شوند، زیرا ممکن است پارامترهای تعیین‌شده برای کتابخانه (یا فایل‌هایی که آن پارامترها به آن‌ها اشاره دارند) تغییر کرده باشند.

از نسخهٔ Kea 2.7.9، کتابخانه‌های هوک تنها می‌توانند از دایرکتوری پیش‌فرض نصب که در زمان کامپایل تعیین شده و در گزارش پیکربندی به عنوان "Hooks directory" نشان داده شده است، بارگذاری شوند. این مقدار ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی KEA_HOOKS_PATH بر روی مسیر دلخواه بازنویسی شود. اگر مسیری غیر از این مقدار در یک عنصر library استفاده شود، Kea خطایی صادر کرده و از بارگذاری کتابخانه خودداری خواهد کرد. برای سهولت در استفاده، عناصر library باید بخش‌های مسیر را حذف کنند و تنها نام فایل را همان‌طور که در زیر نشان داده شده مشخص نمایند:

{
    "Dhcp6": {
        "hooks-libraries": [
            {
                "library": "first_custom_hooks_example.so"
            },
            {
                "library": "second_custom_hooks_example.so"
            }
        ]
    }
}

نکته:

پشتیبانی از بخش‌های مسیر در عناصر library از نسخهٔ 2.7.8 منسوخ شده است و در نهایت حذف خواهد شد.

کتابخانه‌ها ممکن است پارامترهای اضافی داشته باشند که اجباری نیستند، به این معنا که ممکن است کتابخانه‌هایی وجود داشته باشند که نیازی به آن‌ها نداشته باشند. با این حال، برای هر کتابخانهٔ مشخص اغلب الزامی برای تعیین مجموعه‌ای خاص از پارامترها وجود دارد. لطفاً برای جزئیات به مستندات هر کتابخانهٔ مجزا مراجعه کنید. در مثال بالا، کتابخانهٔ نخست (/opt/first_custom_hooks_example.so) هیچ پارامتری ندارد. کتابخانهٔ دوم (/opt/local/second_custom_hooks_example.so) دارای پنج پارامتر است: تعیین mail (پارامتر رشته‌ای)، floor (پارامتر عددی صحیح)، debug (پارامتر بولی)، لیست‌ها (فهرستی از رشته‌ها)، و نگاشت‌ها (شامل رشته‌ها). در صورت پشتیبانی کتابخانه، می‌توان از پارامترهای تو در تو استفاده کرد. این موضوع به تفصیل در بخش Hooks Developer's Guide از راهنمای توسعه‌دهندهٔ Kea توضیح داده شده است https://reports.kea.isc.org/dev_guide/df/d46/hooksdgDevelopersGuide.html.

برخی هوک‌ها برای تنظیم پارامترها از بافتار کاربر (user context) استفاده می‌کنند. بخش User Contexts in Hooks را ببینید.

نکات:

  • مسیر کامل هر کتابخانه باید مشخص شود.
  • همان‌طور که در بالا اشاره شد، ترتیبی که هوک‌ها فراخوانی می‌شوند ممکن است حائز اهمیت باشد؛ برای جزئیات به مستندات مربوط به هر کتابخانه مراجعه کنید.
  • یک فهرست خالی همان اثری را دارد که گویی عنصر پیکربندی hooks-libraries به‌طور کلی حذف شده است.

    نکته:

یک حالت وجود دارد که این موضوع در آن صادق نیست: اگر Kea با پیکربندی‌ای در حال اجرا باشد که شامل یک مورد hooks-libraries است، و آن مورد حذف شده و پیکربندی مجدداً بارگذاری شود، این حذف نادیده گرفته شده و کتابخانه‌ها بارگذاری‌شده باقی می‌مانند. به عنوان یک راهکار موقت، به جای حذف مورد hooks-libraries، آن را به یک فهرست خالی تغییر دهید.

در حال حاضر، تنها فرآیندهای kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> از کتابخانه‌های هوک پشتیبانی می‌کنند..SS ترتیب پیکربندی (Order of Configuration):

بسیار مهم است توجه داشته باشید که ترتیب پیکربندی کتابخانه‌های قلاب (hook libraries)، تعیین‌کنندهٔ ترتیب اجرای فراخوانی‌های آن‌ها (callouts) در مواردی است که بیش از یک کتابخانهٔ قلاب، یک فراخوانی یکسان را پیاده‌سازی کرده باشند. برای مثال، جهت استفاده از کتابخانهٔ قلاب Flexible Identifier (که Flex ID نیز نامیده می‌شود) برای فرمول‌بندی شناسه‌های کلاینت در کنار کتابخانهٔ قلاب High Availability (HA) جهت توازن بار HA، ضروری است که کتابخانهٔ Flex ID ابتدا در بخش hooks-libraries سرور مشخص شود. این کار تضمین می‌کند که شناسهٔ کلاینت پیش از آن‌که کتابخانهٔ HA از آن برای توازن بار استفاده کند، توسط کتابخانهٔ Flex ID شکل گرفته باشد. به همین ترتیب، بهتر است کتابخانهٔ Forensic Logging در انتها مشخص شود تا اطمینان حاصل گردد پیش از بارگذاری آن، سایر قلاب‌های نصب‌شده سهم خود را در پردازش بسته اعمال کرده‌اند.

کتابخانه‌های قلاب می‌توانند پارامترهای پیکربندی مختص به خود را داشته باشند، که در صورت اعمال پارامتر بر کل کتابخانه، بسیار مناسب و کاربردی است. با این حال، گاهی اوقات سودمند است که موجودیت‌های پیکربندی خاصی را با داده‌های پیکربندی اضافی گسترش داد. اینجاست که مفهوم زمینه‌های کاربر (user contexts) مطرح می‌شود. مدیر سیستم می‌تواند مجموعه‌ای اختیاری از داده‌ها را تعریف کرده و تا زمانی که داده‌ها به صورت یک نگاشت (map) در قالب JSON مشخص شده باشند، آن‌ها را به ساختارهای Kea متصل کند. به‌ویژه، تعریف فیلدهایی از نوع اعداد صحیح (integers)، رشته‌ها (strings)، مقادیر بولی (boolean)، فهرست‌ها (lists) یا نگاشت‌ها (maps) امکان‌پذیر است. همچنین می‌توان ساختارهای تو‌در‌تو با هر میزان پیچیدگی را تعریف نمود. Kea به‌خودی‌خود از این داده‌ها استفاده نمی‌کند؛ بلکه صرفاً آن‌ها را ذخیره کرده و در دسترس کتابخانه‌های قلاب قرار می‌دهد.

کاربرد دیگر برای user contexts می‌تواند ذخیره‌سازی یادداشت‌ها و سایر اطلاعاتی باشد که توسط Kea نگهداری خواهند شد. کامنت‌های معمولی هنگام بارگذاری پیکربندی نادیده گرفته و دور ریخته می‌شوند، اما زمینه‌های کاربر حفظ می‌گردند. این ویژگی برای مواردی مفید است که مدیران سیستم بخواهند یادداشت‌هایشان برای مثال در طول عملیات‌های config-set <#std-isccmd-config-set> یا config-get <#std-isccmd-config-get> پابرجا بمانند.

اگر زمینهٔ کاربر در یک بافت خاص پشتیبانی شود، تجزیه‌کننده (parser) مدخل‌های "comment" را به زمینهٔ کاربر حاوی یک مدخل "comment" تبدیل می‌کند.

زمینهٔ کاربر می‌تواند پیکربندی مربوط به چندین قلاب و یادداشت‌ها را به‌طور هم‌زمان در خود ذخیره کند.

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

قلاب DDNS Tuning از user context برای پیکربندی رفتار به ازای هر زیرشبکه (per-subnet) استفاده می‌کند. نمونه‌ای از این پیکربندی در ادامه آمده است:

"subnet4": [{
    "id": 1,
    "subnet": "192.0.2.0/24",
    "pools": [{
        "pool": "192.0.2.10 - 192.0.2.20"
    } ],
    "user-context": {
        "ddns-tuning": {
            "hostname-expr": "'guest-'+int8totext(substring(pkt4.yiaddr, 0,1))+'-' \
                                      +int8totext(substring(pkt4.yiaddr, 1,2))+'-' \
                                      +int8totext(substring(pkt4.yiaddr, 2,3))+'-' \
                                      +int8totext(substring(pkt4.yiaddr, 3,4))"
        },
        "last-modified": "2017-09-04 13:32",
        "phones": [ "x1234", "x2345" ],
        "devices-registered": 42,
        "billing": false
    }
}]

قلاب Limits از user-context در کلاس‌ها و زیرشبکه‌ها برای تنظیم پارامترها استفاده می‌کند. برای نمونه:

{
  "Dhcp6": {
    "client-classes": [
      {
        "name": "gold",
        "user-context": {
          "limits": {
            "address-limit": 2,
            "prefix-limit": 1,
            "rate-limit": "1000 packets per second"
          }
        }
      }
    ],
    "hooks-libraries": [
      {
        "library": "libdhcp_limits.so"
      }
    ],
    "subnet6": [
      {
        "id": 1,
        "pools": [
          {
            "pool": "2001:db8::/64"
          }
        ],
        "subnet": "2001:db8::/64",
        "user-context": {
          "limits": {
            "address-limit": 4,
            "prefix-limit": 2,
            "rate-limit": "10 packets per minute"
          }
        }
      }
    ]
  }
}

سرورهای Kea شامل سازوکاری هستند که به موجب آن، پاسخ به یک بستهٔ کلاینت می‌تواند تا زمان اتمام کار کتابخانهٔ قلاب معلق نگه داشته شود. ما از این فرایند با عنوان "پارک کردن بسته" یاد می‌کنیم. هنگامی که ادامهٔ کار آماده شد، سرور پاسخ را از حالت پارک خارج کرده و پردازش را ادامه می‌دهد.

یک پارامتر سراسری به نام parked-packet-limit وجود دارد که می‌توان از آن برای محدود کردن تعداد پاسخ‌هایی که در هر لحظه می‌توانند پارک شوند، استفاده کرد. این پارامتر به عنوان روشی برای مدیریت ازدحام عمل کرده و زمانی که حجم پرس‌وجوهای کلاینت‌ها از توان پاسخ‌گویی سرور پیشی می‌گیرد، از غرق شدن سرور زیر بار ترافیک جلوگیری می‌کند. هنگامی که این حد نصاب تکمیل شود، سرور یک لاگ ثبت کرده و هر پاسخ جدیدی را تا زمان خالی شدن ظرفیت پارک دور می‌اندازد (drop می‌کند).

به‌طور کلی، مقادیر کوچک‌تر برای محدودیت ظرفیت پارک احتمالاً باعث ریزش (drop) بیشتر اما با زمان پاسخ‌گویی کوتاه‌تر می‌شوند؛ مقادیر بزرگ‌تر احتمالاً به ریزش کمتر اما با زمان پاسخ‌گویی طولانی‌تر می‌انجامند. در حال حاضر، مقدار پیش‌فرض برای parked-packet-limit برابر با 256 است.

هشدار:

استفاده از یک مقدار بسیار کوچک ممکن است منجر به نرخ ریزش (drop rate) غیرضروری و بالایی شود، در حالی که استفاده از مقداری بیش از حد بزرگ می‌تواند زمان پاسخ‌گویی را تا حدی طولانی کند که عملاً دیگر کارآمد نباشد. مقدار 0 با اینکه مجاز است، این محدودیت را به‌کلی غیرفعال می‌کند، اما این کار اکیداً نهی می‌شود؛ چرا که ممکن است منجر به عدم پاسخ‌گویی سرورهای Kea به کلاینت‌ها شود. انتخاب بهترین مقدار بسیار وابسته به شرایط هر سامانه است؛ توصیه می‌کنیم کاربران در ابتدا آن را روی مقدار پیش‌فرض 256 بگذارند و نحوهٔ رفتار سیستم را در طول زمان تحت شرایط مختلف بار ترافیکی مشاهده کنند.

در ادامه مثالی از پارامتر سراسری آورده شده است که به همراه libdhcp_ha.so استفاده شده است. این تنظیم، تعداد بسته‌های متوقف‌شدهٔ هم‌زمان را به 128 کاهش می‌دهد.

{
  "Dhcp6": {
    "parked-packet-limit": 128
    "hooks-libraries": [
      {
        "library": "libdhcp_lease_cmds.so"
      },
      {
        "library": "libdhcp_ha.so",
        "parameters": {
          "high-availability": [
            {
              "mode": "hot-standby",
              "peers": [
                {
                  "name": "server1",
                  "role": "primary",
                  "url": "http://127.0.0.1:8080/"
                },
                {
                  "name": "server2",
                  "role": "standby",
                  "url": "http://127.0.0.1:8088/"
                }
              ],
              "this-server-name": "server1"
            }
          ]
        }
      }
    ]
  }
}

همان‌طور که در بالا توضیح داده شد، سازوکار هوک روشی را برای سفارشی‌سازی یک کارساز Kea بدون تغییر در کد اصلی (core) فراهم می‌کند. ISC تصمیم گرفته است با بهره‌گیری از این ویژگی، قابلیت‌هایی را ارائه دهد که ممکن است تنها برای زیرمجموعه‌ای از کاربران Kea مفید باشند. بدین منظور، ISC چندین کتابخانهٔ هوک ایجاد کرده است که در بخش‌های بعدی به آن‌ها پرداخته می‌شود.

نکته:

از نسخهٔ Kea 3.0.0، بیشتر این کتابخانه‌ها بدون هزینه همراه با کد پایهٔ متن‌باز در دسترس هستند؛ تعداد اندکی تنها برای سازمان‌هایی در دسترس هستند که از طریق قراردادهای پشتیبانی غیررایگان ISC در توسعهٔ Kea مشارکت دارند. پشتیبانی غیررایگان شامل کمک‌های مهندسی حرفه‌ای، اعلان‌های امنیتی زودهنگام، مشارکت در برنامه‌ریزی نقشهٔ راه ISC و مزایای بسیار دیگر است، و هم‌زمان به پایداری Kea در بلندمدت کمک می‌کند. ISC شرکت‌ها و سازمان‌ها را تشویق می‌کند تا خرید قرارداد پشتیبانی را مد نظر قرار دهند؛ اطلاعات بیشتر را می‌توان با تکمیل فرم در https://www.isc.org/contact به دست آورد.

جدول زیر فهرستی از کتابخانه‌های هوک را که در حال حاضر از سوی ISC ارائه می‌شوند نشان می‌دهد. توجه به این که کدام کتابخانه‌ها می‌توانند توسط کدام فرایندهای Kea بارگذاری شوند دارای اهمیت است. اگر کتابخانه‌ای از سوی ISC مطابق انتظار کار نکرد، لطفاً مطمئن شوید که بر اساس جدول زیر توسط فرایند صحیح بارگذاری شده باشد.

نام دسترسی توضیحات
BOOTP متن‌باز Kea این کتابخانهٔ هوک، پشتیبانی از BOOTP را مطابق با تعریف RFC 1497 اضافه می‌کند. این کتابخانه درخواست‌های دریافت‌شدهٔ BOOTP را شناسایی می‌کند: این درخواست‌ها به بسته‌های DHCPREQUEST ترجمه می‌شوند، در کلاس کلاینت BOOTP قرار می‌گیرند و اجاره‌هایی با طول عمر نامحدود دریافت می‌کنند.
Class Commands متن‌باز Kea این کتابخانهٔ هوک امکان افزودن، به‌روزرسانی، حذف و واکشی کلاس‌های کلاینتِ پیکربندی‌شدهٔ DHCP را بدون نیاز به راه‌اندازی مجدد کارساز DHCP فراهم می‌کند.
Configuration Backend Commands مشتریان پشتیبانی ISC این کتابخانهٔ هوک مجموعه‌ای از دستورها را برای مدیریت اطلاعات پیکربندی Kea در یک پایگاه داده پیاده‌سازی می‌کند. این کتابخانه فقط در کنار یکی از پیاده‌سازی‌های پشتیبانی‌شدهٔ Configuration Backend قابل استفاده است.
DDNS Tuning متن‌باز Kea این کتابخانهٔ هوک رفتارهای سفارشی مربوط به به‌روزرسانی‌های Dynamic DNS را بر پایهٔ هر کلاینت اضافه می‌کند. ویژگی اصلی آن امکان محاسبهٔ نام میزبان مورداستفاده برای DNS با استفاده از یک عبارت است.
Flexible Identifier متن‌باز Kea نرم‌افزار Kea روشی را برای مدیریت رزروهای میزبان فراهم می‌کند که شامل آدرس‌ها، پیشوندها، گزینه‌ها، کلاس‌های کلاینت و سایر ویژگی‌ها است. رزرو می‌تواند بر اساس آدرس سخت‌افزاری، DUID، circuit-id یا client-id در DHCPv4 و بر اساس آدرس سخت‌افزاری یا DUID در DHCPv6 انجام شود. با این حال، گاهی سناریوهایی رخ می‌دهد که در آن‌ها رزرو پیچیده‌تر است، مانند استفاده از گزینه‌هایی غیر از موارد یادشده، استفاده از بخش‌هایی از گزینه‌هایی خاص، یا شاید استفاده از ترکیبی از چندین گزینه و فیلد برای شناسایی یکتای یک کلاینت. این سناریوها توسط برنامهٔ هوک Flexible Identifier پوشش داده می‌شوند. این برنامه امکان تعریف یک عبارت، مشابه عبارت مورد استفاده در کلاس‌بندی کلاینت، مانند substring(relay6[0].option[37],0,6) را می‌دهد. هر بستهٔ ورودی بر اساس آن عبارت ارزیابی شده و سپس مقدار آن در پایگاه دادهٔ رزروها جستجو می‌شود.
Flexible Option متن‌باز Kea این کتابخانه هوک‌هایی را ارائه می‌دهد که مقادیر گزینه را به‌جای مقادیر ایستای پیکربندی‌شده محاسبه می‌کنند. یک عبارت بر روی بستهٔ پرس‌وجو ارزیابی می‌شود. عملیات‌های تعریف‌شدهٔ add، supersede و remove با استفاده از نتیجهٔ ارزیابی، پیش از ارسال روی بستهٔ پاسخ اعمال می‌شوند.
Forensic Logging متن‌باز Kea این کتابخانه هوک‌هایی را فراهم می‌آورد که گزارشی تفصیلی از تخصیص‌ها و تمدیدهای اجاره را در مجموعه‌ای از فایل‌های لاگ ثبت می‌کنند. در بسیاری از حوزه‌های قضایی، شرکت‌ها – به‌ویژه ISPها – موظف‌اند اطلاعات مربوط به آدرس‌هایی را که به کلاینت‌های DHCP اجاره داده‌اند ثبت کنند. این کتابخانه برای کمک به این الزام طراحی شده است. اگر اطلاعاتی که ثبت می‌کند کافی باشد، می‌توان مستقیماً از آن استفاده کرد. اگر حوزه‌ای قضایی نیازمند ذخیرهٔ مجموعهٔ متفاوتی از اطلاعات باشد، می‌توان از آن به عنوان الگو یا مثالی برای ایجاد هوک‌های لاگ‌گیری سفارشی استفاده نمود. در Kea 1.9.8، پارامترهای بیشتری اضافه شد تا انعطاف‌پذیری بیشتری در رابطه با این که چه اطلاعاتی باید ثبت شوند به کاربران داده شود.
GSS-TSIG متن‌باز Kea این کتابخانهٔ هوک پشتیبانی از استفاده از GSS-TSIG برای امضای به‌روزرسانی‌های DNS را به کارساز Kea D2 (kea-dhcp-ddns) اضافه می‌کند.
High Availability متن‌باز Kea خطر از دسترس خارج شدن سرویس DHCP را می‌توان با برپایی یک جفت کارساز DHCP در یک شبکه به حداقل رساند. دو حالت عملیاتی پشتیبانی می‌شود. حالت اول موازنهٔ بار نام دارد و گاهی از آن با عنوان "active-active" یاد می‌شود. هر کارساز می‌تواند گروه‌های منتخبی از کلاینت‌ها را در این شبکه مدیریت کند، یا در صورتی که تشخیص دهد همتایش از دسترس خارج شده، تمام کلاینت‌ها را مدیریت نماید. همچنین می‌توان یک کارساز را برای پاسخگویی به همهٔ کلاینت‌های DHCP تعیین کرد و کارساز دیگر را در حالت آماده‌باش قرار داد. این حالت "hot standby" نامیده می‌شود و گاهی به آن "active-passive" می‌گویند. این کارساز تنها زمانی عملکرد DHCP خود را فعال می‌کند که تشخیص دهد همتایش در دسترس نیست. چنین همکاری‌ای میان کارسازهای DHCP مستلزم آن است که این کارسازها پیوسته با یکدیگر در ارتباط باشند تا به‌روزرسانی‌های مربوط به اجاره‌های اختصاص‌یافته را ارسال کنند و به صورت دوره‌ای عملیاتی بودن همتای خود را بیازمایند. این کتابخانهٔ هوک همچنین امکان ارسال به‌روزرسانی‌های اجاره را به کارسازهای پشتیبان خارجی فراهم می‌کند که داشتن یک جایگزین کاملاً به‌روز را بسیار ساده‌تر می‌سازد.
Host Cache متن‌باز Kea پاسخ‌دهی برخی از Backendهای پایگاه داده، مانند RADIUS، ممکن است زمان زیادی ببرد. از آنجا که Kea به‌طور کلی همگام است، کارایی Backend مستقیماً بر کارایی DHCP اثر می‌گذارد. برای به حداقل رساندن افت کارایی، این کتابخانه روشی را برای کَش کردن پاسخ‌های سایر میزبان‌ها فراهم می‌کند. این شامل کَش منفی نیز می‌شود، یعنی توانایی به‌خاطرسپاری اینکه هیچ اطلاعات کلاینتی در پایگاه داده وجود ندارد.
Host Commands متن‌باز Kea کارساز Kea روشی برای ذخیرهٔ رزروهای میزبان در یک پایگاه داده فراهم می‌کند. در بسیاری از استقرارهای بزرگ‌تر، مدیریت این اطلاعات در زمان اجرای کارساز سودمند است. این کتابخانه دستورهای مدیریتی را برای افزودن، پرس‌وجو و حذف رزروهای میزبان به شکلی امن و بدون راه‌اندازی دوبارهٔ کارساز ارائه می‌دهد. به‌ویژه، پارامترها را اعتبارسنجی می‌کند، بنابراین تلاشی برای درج داده‌های نادرست، مانند افزودن میزبانی با شناسهٔ متداخل در همان زیرشبکه، رد خواهد شد. این دستورها از طریق کانال فرمان (JSON از طریق سوکت‌های UNIX یا HTTP/HTTPS) ارائه می‌شوند،
Lease Commands متن‌باز Kea این کتابخانهٔ هوک مجموعه‌ای از دستورها را برای مدیریت اجاره‌ها ارائه می‌دهد. Kea می‌تواند اطلاعات اجاره را در Backendهای مختلفی ذخیره کند: memfile، MySQL و PostgreSQL. این کتابخانه رابطی یکپارچه برای دستکاری اجاره‌ها به روشی هماهنگ و امن فراهم می‌کند. به‌ویژه، دستکاری اجاره‌های memfile در زمان اجرای Kea، بررسی درستی تغییرات، بررسی وجود اجاره، و حذف تمام اجاره‌های متعلق به یک زیرشبکهٔ خاص را امکان‌پذیر می‌کند. همچنین می‌تواند خطاهای پنهان را شناسایی کند، مانند افزودن اجاره‌ای با subnet-id که در پیکربندی وجود ندارد، یا پیکربندی یک اجاره برای استفاده از آدرسی خارج از زیرشبکه‌ای که باید به آن تعلق داشته باشد. این کتابخانه مدیریت آسان بسترهای کاربری (user contexts) مرتبط با اجاره‌ها را ممکن می‌سازد.
Leasequery متن‌باز Kea این کتابخانه پشتیبانی از DHCPv4 Leasequery (RFC 4388)، DHCPv4 Bulk Leasequery (RFC6926)، DHCPv6 Leasequery (RFC 5007) و DHCPv6 Bulk Leasequery (RFC5460) را اضافه می‌کند.
Limits متن‌باز Kea با این کتابخانهٔ هوک، کارسازهای kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> می‌توانند نرخی را که بسته‌ها بر اساس آن پاسخ دریافت می‌کنند محدود نمایند. این محدودیت می‌تواند بر پایهٔ هر کلاس کلاینت یا هر زیرشبکه اعمال شود.
MySQL Support Library متن‌باز Kea این کتابخانهٔ هوک، پشتیبانی از استفاده از پایگاه(های) دادهٔ MySQL را برای Backendهای Lease، Host و Configuration در Kea ارائه می‌دهد.
PerfMon متن‌باز Kea با این کتابخانهٔ هوک، کارسازهای kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> می‌توانند داده‌های مربوط به کارایی را رصد و گزارش کنند.
Ping Check متن‌باز Kea با این کتابخانهٔ هوک، کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> می‌تواند پیش از پیشنهاد آدرس‌های نامزد اجاره به کلاینت‌ها، بررسی پینگ را روی آن‌ها انجام دهد.
PostgreSQL Support Library متن‌باز Kea این کتابخانهٔ هوک، پشتیبانی از استفاده از پایگاه(های) دادهٔ PostgreSQL را برای Backendهای Lease، Host و Configuration در Kea ارائه می‌دهد.
RADIUS متن‌باز Kea کتابخانهٔ هوک RADIUS به Kea اجازه می‌دهد با استفاده از سازوکارهای access و accounting با کارسازهای RADIUS در ارتباط باشد. سازوکار access می‌تواند برای کنترل دسترسی، تخصیص آدرس‌های IPv4 یا IPv6 خاصِ رزروشده توسط RADIUS، تخصیص پویای آدرس‌ها از مخزن‌های (pools) تعیین‌شده توسط RADIUS، یا رد کامل پیام‌های کلاینت استفاده شود. سازوکار accounting به کارساز RADIUS اجازه می‌دهد فعالیت دستگاه را در گذر زمان رهگیری کند.
RBAC مشتریان پشتیبانی ISC این کتابخانهٔ هوک پشتیبانی از پالایش دستورها بر اساس کنترل دسترسی نقش‌محور (Role-Based Access Control) را به کارسازهای Kea (شامل kea-dhcp4، kea-dhcp6 و kea-dhcp-ddns) اضافه می‌کند.
Run Script متن‌باز Kea این کتابخانهٔ هوک پشتیبانی از اجرای اسکریپت‌های خارجی را برای نقاط هوک خاص در پردازش بسته‌ها اضافه می‌کند. چندین متغیر محیطی صادرشده وجود دارند که در اختیار اسکریپت قرار می‌گیرند.
Statistics Commands متن‌باز Kea این کتابخانه دستورهای بیشتری را برای بازیابی آمارهای دقیق اجارهٔ DHCP، برای کارسازهای Kea DHCP که از یک پایگاه دادهٔ اجارهٔ مشترک بهره می‌برند، ارائه می‌دهد. این پیکربندی در استقرارهایی متداول است که به افزونگی سرویس DHCP نیاز دارند و از یک پایگاه دادهٔ اجارهٔ مشترک برای اجتناب از تکرار داده‌های اجاره بین کارسازهای DHCP استفاده می‌کنند. این کتابخانهٔ هوک آمارهای اجاره را برای هر زیرشبکه بازمی‌گرداند.
Subnet Commands متن‌باز Kea در استقرارهایی که پیکربندی زیرشبکه باید به طور مکرر به‌روزرسانی شود، این یک الزام حیاتی است که چنین به‌روزرسانی‌هایی بدون نیاز به پیکربندی مجددِ کامل یا راه‌اندازی دوبارهٔ کارساز DHCP انجام شوند. این کتابخانهٔ هوک امکان اعمال تغییرات تدریجی بر پیکربندی زیرشبکه، مانند افزودن یا حذف یک زیرشبکه را ممکن می‌سازد. همچنین امکان فهرست کردن تمام زیرشبکه‌های موجود و واکشی اطلاعات دقیق دربارهٔ یک زیرشبکهٔ انتخاب‌شده را فراهم می‌کند. دستورهای ارائه‌شده توسط این کتابخانه بر دیگر زیرشبکه‌ها یا پارامترهای پیکربندی که در حال حاضر توسط کارساز استفاده می‌شوند اثری نمی‌گذارند.
User Check متن‌باز Kea فهرست کاربران شناخته‌شده را از یک فایل می‌خواند. به کاربران ناشناخته، اجاره‌ای از آخرین زیرشبکهٔ تعریف‌شده در فایل پیکربندی اختصاص داده خواهد شد، برای مثال برای هدایت آن‌ها به یک پورتال محصور (captive portal). این عملکرد نشان می‌دهد که چگونه می‌توان از یک منبع خارجی اطلاعات برای اثرگذاری بر موتور تخصیص Kea استفاده کرد. این هوک بخشی از کد منبع Kea است و در دایرکتوری src/hooks/dhcp/user_chk در دسترس است.

سازمان ISC امیدوار است با گذشت زمان، شاهد در دسترس قرار گرفتن کتابخانه‌های هوک بیشتری باشد که چه به صورت داخلی و چه خارجی توسعه یافته باشند. از آنجا که این فهرست ممکن است به صورت پویا تغییر کند، در یک صفحهٔ ویکی نگهداری می‌شود که در https://gitlab.isc.org/isc-projects/kea/-/wikis/Hooks-Available در دسترس است. از توسعه‌دهندگان یا دیگر افرادی که از کتابخانه‌های هوک ذکرنشده در آنجا آگاهی دارند، تقاضا می‌شود یادداشتی به فهرست‌های پستی kea-users یا kea-dev جهت به‌روزرسانی ارسال نمایند. (اطلاعات مربوط به تمام فهرست‌های پستی عمومی ISC را می‌توان در https://www.isc.org/mailinglists یافت.)

کتابخانه‌های توسعه‌یافته توسط ISC در بخش‌های بعدی با جزئیات شرح داده شده‌اند..SS libdhcp_bootp.so: پشتیبانی از کلاینت‌های BOOTP

این کتابخانهٔ قلاب (hook library) پشتیبانی از BOOTP را به همراه افزونه‌های اطلاعات ارائه‌دهنده (vendor-information extensions) (RFC 1497 https://datatracker.ietf.org/doc/html/rfc1497) اضافه می‌کند. درخواست‌های دریافتی BOOTP تشخیص داده شده، با افزودن گزینهٔ dhcp-message-type به بسته‌های DHCPREQUEST تبدیل شده و در کلاس کلاینت "BOOTP" قرار می‌گیرند. اعضای این کلاس اجاره‌هایی با طول عمر نامحدود دریافت می‌کنند، اما از این کلاس می‌توان برای محافظت از یک استخر (pool) آدرس نیز استفاده کرد.

گزینه‌های ویژهٔ DHCP، مانند dhcp-message-type، از پاسخ‌های سرور حذف می‌شوند؛ پاسخ‌های کوتاه‌تر از حداقل اندازهٔ BOOTP یعنی ۳۰۰ بایت (octet)، تا این اندازه با داده‌های پرکننده تکمیل می‌شوند.

نکته:

libdhcp_bootp.so بخشی از کد متن‌باز است و در دسترس تمامی کاربران Kea قرار دارد.

نکته:

این کتابخانه تنها می‌تواند توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> بارگذاری شود، زیرا پروتکل BOOTP برای IPv6 وجود ندارد.

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

"Dhcp4": {
    "hooks-libraries": [
        {   "library": "libdhcp_bootp.so" },
        ...
    ]
}

نکته:

رزرو میزبان (host reservation) برای یک کلاینت BOOTP باید از آدرس سخت‌افزاری به عنوان شناسه استفاده کند (گزینهٔ client-id یک گزینهٔ ویژهٔ DHCP است).

بسته‌های ورودی BOOTP به کلاس BOOTP اضافه می‌شوند که به مدیران سیستم امکان می‌دهد کلاینت‌های BOOTP را در استخرهای جداگانه تفکیک کنند. برای مثال:

"Dhcp4": {
    "client-classes": [
        {
            // The DHCP class is the complement of the BOOTP class
            "name": "DHCP",
            "test": "not member('BOOTP')"
        }
    ],
    "subnet4": [
        {
            "subnet": "192.0.2.0/24",
            "pools": [
            {
                // BOOTP clients will be handled here
                "pool": "192.0.2.200 - 192.0.2.254",
                "client-classes": [ "BOOTP" ]
            },
            {
                // Regular DHCP clients will be handled here
                "pool": "192.0.2.1 - 192.0.2.199",
                "client-classes": [ "DHCP" ]
            }],
            ...
        },
        ...
    ],
    ...
}

در حال حاضر کتابخانهٔ BOOTP دارای محدودیت زیر است:

•
پروتکل BOOTP پایه، مطابق با تعریف RFC 951 https://datatracker.ietf.org/doc/html/rfc951، پشتیبانی نمی‌شود. Kea تنها از BOOTP همراه با افزونه‌های اطلاعات ارائه‌دهنده پشتیبانی می‌کند.

این کتابخانهٔ قلاب برای مدیریت پیکربندی‌های سرورهای Kea در یک پایگاه‌دادهٔ بک‌اند پیکربندی (configuration backend) به کار می‌رود. این کتابخانه باید همراه با کتابخانه‌های قلاب CB موجود که APIهای مشترک را برای ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) اطلاعات پیکربندی در پایگاه‌های دادهٔ مربوطه پیاده‌سازی می‌کنند، استفاده شود. برای مثال: libdhcp_mysql.so این API را برای MySQL پیاده‌سازی می‌کند در حالی که libdhcp_pgsql.so این API را برای PostgreSQL پیاده‌سازی می‌نماید. برای مدیریت اطلاعات پیکربندی در یک پایگاه‌دادهٔ MySQL، هر دو کتابخانهٔ libdhcp_mysql.so و libdhcp_cb_cmds.so باید توسط سروری که برای مدیریت پیکربندی استفاده می‌شود بارگذاری شوند. برای مدیریت اطلاعات پیکربندی در یک پایگاه‌دادهٔ PostgreSQL، هر دو کتابخانهٔ libdhcp_pgsql.so و libdhcp_cb_cmds.so باید توسط سروری که برای مدیریت پیکربندی استفاده می‌شود بارگذاری شوند.

اطلاعات بیشتر دربارهٔ چگونگی پیکربندی کتابخانهٔ قلاب بک‌اند پیکربندی برای استفاده با یک پایگاه‌دادهٔ MySQL یا PostgreSQL را می‌توان در بخش‌های Configuration Backend in DHCPv4 <#dhcp4-cb> و Configuration Backend in DHCPv6 <#dhcp6-cb> مشاهده کرد.

نکته:

libdhcp_cb_cmds.so تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس است. برای کسب اطلاعات بیشتر دربارهٔ گزینه‌های اشتراک، لطفاً فرم موجود در https://www.isc.org/contact را تکمیل کنید.

نکته:

این کتابخانه تنها می‌تواند توسط فرایندهای kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

نکته:

لطفاً پیش از به‌کارگیری دستورهای شرح داده شده در این بخش، بخش محدودیت‌ها و هشدارها (Limitations and Warnings) <#cb-limitations> را مطالعه کنید.

این کتابخانه از ۵ نوع دستور پشتیبانی می‌کند:

  • del - حذف شیء انتخاب‌شده از پایگاه داده، مانند remote-global-parameter4-del.
  • get - واکشی شیء انتخاب‌شده از پایگاه داده، مانند remote-subnet4-get-by-id.
  • get-all - واکشی تمام اشیاء یک نوع خاص از پایگاه داده، مانند remote-option-def4-get-all.
  • list - فهرست کردن تمام اشیاء یک نوع خاص در پایگاه داده، مانند remote-network4-list؛ این دسته از دستورات در مقایسه با خروجی get-all اطلاعات خلاصه‌تری درباره هر شیء برمی‌گردانند.
  • set - ایجاد یا جایگزینی شیئی از نوع داده‌شده در پایگاه داده، مانند remote-option4-global-set.

همه انواع دستورات یک نگاشت اختیاری remote را می‌پذیرند که نمونه پایگاه داده مورد اشاره دستور را مشخص می‌کند. برای مثال:

{
    "command": "remote-subnet4-list",
    "arguments": {
        "remote": {
            "type": "mysql",
            "host": "192.0.2.33",
            "port": 3302
        }
    }
}

پایگاه داده MySQL را که روی میزبان 192.0.2.33 و درگاه 3302 در حال اجراست برای واکشی فهرست زیرشبکه‌ها انتخاب می‌کند. تمام پارامترها در آرگومان remote اختیاری هستند. پارامتر port تنها همراه با host قابل تعیین است. اگر قرار نیست هیچ گزینه‌ای در پارامتر remote مشخص شود، این پارامتر باید حذف گردد. در این حالت، سرور از نخستین پشتیبان (backend) فهرست‌شده در نگاشت config-control در پیکربندی سرورِ دریافت‌کننده دستور استفاده خواهد کرد.

نکته:

در نگارش کنونی Kea، تنها می‌توان سرور Kea را برای استفاده از یک پشتیبان پیکربندی واحد تنظیم کرد. به بیان دقیق‌تر، با استفاده از پارامتر config-control تنها می‌توان سرور Kea را حداکثر به یک پایگاه داده (یا MySQL یا PostgreSQL) متصل کرد. بنابراین، پارامتر remote می‌تواند در دستورات نادیده گرفته شود و libdhcp_cb_cmds.so به‌طور پیش‌فرض از همان تنها پشتیبان موجود استفاده می‌کند. دستورات نمونه زیر اغلب مقدار "mysql" را برای پارامتر type نشان می‌دهند؛ در صورتی که از پایگاه داده PostgreSQL استفاده می‌کنید باید فرض شود که این مقدار "postgresql" است.

این بخش به شرح و ارائه مثال‌هایی از دستورات کنترلی پیاده‌سازی‌شده توسط libdhcp_cb_cmds.so برای مدیریت اطلاعات پیکربندی سرورهای DHCPv4 و DHCPv6 می‌پردازد. بسیاری از این دستورات بین DHCPv4 و DHCPv6 تقریباً یکسان هستند و تنها در نام دستور با یکدیگر تفاوت دارند. سایر دستورات تفاوت جزئی در ساختار داده‌های درج‌شده دارند؛ برای مثال، ساختار اطلاعات زیرشبکه IPv4 با زیرشبکه IPv6 متفاوت است. با این حال، ساختار آرگومان‌های دستورات آن‌ها یکسان است و از این رو توضیح دادن آن‌ها در کنار یکدیگر منطقی است.

علاوه بر این، در بخش‌های بعدی هر جا در متن به یک دستور DHCP یا پارامتر DHCP اشاره شود، به هر دو گونه DHCPv4 و DHCPv6 اشاره دارد. متن‌های مختص یک نوع سرور خاص، آن‌ها را با عنوان‌های: دستور DHCPv4، پارامتر DHCPv4، دستور DHCPv6، پارامتر DHCPv6 و غیره مشخص می‌کنند.

پاسخ معمول به دستور get یا list شامل فهرستی از اشیاء بازگردانده‌شده (مانند زیرشبکه‌ها) است و هر شیء حاوی نگاشت metadata با اطلاعاتی مختص پایگاه داده برای توصیف آن شیء می‌باشد. به عبارت دیگر، متاداده حاوی هرگونه اطلاعاتی درباره شیء واکشی‌شده است که ممکن است برای مدیر سیستم مفید باشد اما از دیدگاه سرور DHCP جزئی از مشخصات فنی شیء به شمار نمی‌رود. در نگارش کنونی Kea، متاداده به server-tag محدود شده است. این مقدار، ارتباط شیء با یک سرور خاص یا همه سرورها را مشخص می‌کند.

در زیر یک نمونه پاسخ برای دستور remote-network4-list آمده است که شامل متاداده می‌باشد:

{
    "result": 0,
    "text": "1 IPv4 shared network(s) found.",
    "arguments": {
        "shared-networks": [
            {
                "name": "level3",
                "metadata": {
                    "server-tags": [ "all" ]
                }
            }
        ],
        "count": 1
    }
}

پیاده‌سازی‌های کلاینت نباید فرض کنند که متاداده تنها شامل پارامتر server-tags است. در نگارش‌های آینده انتظار می‌رود این نگاشت با اطلاعات بیشتری گسترش یابد، از جمله زمان تغییر شیء، پیام ثبت‌شده در لاگ هنگام آخرین ویرایش و موارد مشابه..SS برچسب‌های کلاس گزینه به‌عنوان کلید (Option Class-tags as Keys)

قابلیت برچسب‌گذاری کلاس گزینه (Option Class-Tagging) <#option-class-tagging> فهرستی از کلاس‌های کلاینت، client-classes، را به مشخصات گزینه‌ها اضافه کرد. بنابراین در هر فهرستی از مشخصات گزینه‌ها (مانند option-data)، ممکن است بیش از یک مشخصه برای همان code و space وجود داشته باشد، اما با فهرست‌های client-classes متفاوت و محتوای داده‌ای گوناگون.

برای پشتیبانی از این ساختار، Kea افزون بر code و space، از فهرست client-classes گزینه نیز جهت شناسایی یکتای هر گزینه استفاده می‌کند. هنگام استفاده از Management API برای تغییر پیکربندی، به‌خاطر داشتن این موضوع مهم است. از نسخهٔ Kea 3.1.1، دستورهایی که یک گزینهٔ منفرد را دریافت، تنظیم یا حذف می‌کنند، علاوه بر پارامترهای code و space، یک پارامتر اختیاری client-classes را نیز می‌پذیرند.

اگر پارامتر client-classes قید نشود:

1.
Get - یکی از n موردی را که با code و space مطابقت دارد واکشی می‌کند. در صورتی که بیش از یک تطابق وجود داشته باشد، این‌که کدام گزینه بازگردانده می‌شود نامشخص است.
2.
Set - تنها گزینه‌ای را به‌روزرسانی می‌کند که با code و space مطابقت داشته و فهرست client-classes آن خالی باشد. اگر تطابقی یافت نشود، گزینه ایجاد می‌شود.
3.
Delete - تمام گزینه‌هایی را که با code و space تطابق دارند، در صورت وجود، حذف می‌کند.

اگر پارامتر client-classes مشخص شود:

1.
Get - در صورت وجود، گزینه‌ای را که با code، space و client-classes تطابق دارد واکشی می‌کند.
2.
Set - فقط گزینه‌ای را به‌روزرسانی می‌کند که با code، space و client-classes مطابقت داشته باشد. اگر تطابقی یافت نشود، گزینه ایجاد می‌شود.
3.
Delete - در صورت وجود، فقط گزینه‌ای را حذف می‌کند که با code، space و client-classes تطابق دارد.

یک فهرست خالی client-classes به‌صورت '[ ]' با یا بدون فاصله میان براکت‌ها مشخص می‌شود. هنگام مدیریت فهرست گزینه‌هایی که از برچسب‌گذاری کلاس کلاینت استفاده نمی‌کنند، می‌توان پارامتر client-classes را به‌سادگی نادیده گرفت.

این دستور برای حذف اطلاعات یک سرور DHCP انتخاب‌شده از پایگاه‌دادهٔ پیکربندی استفاده می‌شود. سرور با یک برچسب سرور (server tag) یکتا و غیرحساس به بزرگ و کوچکی حروف شناسایی می‌شود. برای مثال:

{
    "command": "remote-server4-del",
    "arguments": {
        "servers": [
            {
                "server-tag": "server1"
            }
        ],
        "remote": {
            "type": "postgresql"
        }
    }
}

در نتیجهٔ این دستور، تمام وابستگی‌های پیکربندی مربوط به سرور تعریف‌شده توسط کاربر با نام "server1" از پایگاه‌داده حذف می‌شوند، از جمله اطلاعات پیکربندی غیرقابل‌اشتراک، مانند پارامترهای سراسری، تعاریف گزینه‌ها و گزینه‌های سراسری. هرگونه اطلاعات پیکربندی قابل‌اشتراک، یعنی عناصر پیکربندی که ممکن است با بیش از یک سرور مرتبط باشند، حفظ می‌شوند. به‌ویژه، زیرشبکه‌ها و شبکه‌های مشترک مرتبط با سرورهای حذف‌شده حفظ می‌گردند. اگر هر یک از عناصر پیکربندی قابل‌اشتراک تنها با سرور حذف‌شده در ارتباط بوده باشد، آن شیء بدون انتساب (یتیم یا orphaned) می‌شود. برای مثال: اگر یک زیرشبکه با استفاده از دستور remote-subnet4-set ایجاد شده و به "server1" اختصاص یافته باشد و متعاقباً "server1" حذف شود، زیرشبکه در پایگاه‌داده باقی می‌ماند اما هیچ سروری نمی‌تواند از این زیرشبکه استفاده کند. این زیرشبکه می‌تواند با دستور remote-subnet4-set به‌روزرسانی شود و با استفاده از برچسب سرور ویژهٔ "all"، به سرور دیگری یا به همهٔ سرورها اختصاص یابد. چنین زیرشبکه‌ای را می‌توان در صورت عدم نیاز، با استفاده از دستور remote-subnet4-del-by-id یا remote-subnet4-del-by-prefix نیز از پایگاه‌داده حذف کرد.

پاسخ موفقیت‌آمیز به دستور remote-server4-del به صورت زیر است:

{
    "result": 0,
    "text": "1 DHCPv4 server(s) deleted.",
    "arguments": {
        "count": 1
    }
}

هشدار:

دستورهای remote-server4-del و remote-server6-del باید با احتیاط استفاده شوند، زیرا حذف تصادفی سرور می‌تواند باعث شود بخش‌هایی از پیکربندی‌های موجود برای همیشه از پایگاه‌داده از بین بروند. این عملیات برگشت‌پذیر نیست. ایجاد دوبارهٔ سروری که به‌طور تصادفی حذف شده، پیکربندی ازدست‌رفتهٔ آن سرور را بازنمی‌گرداند و این پیکربندی باید به‌صورت دستی توسط کاربر دوباره ایجاد شود.

این دستور برای واکشی اطلاعات یک سرور DHCP انتخاب‌شده از پایگاه‌دادهٔ پیکربندی استفاده می‌شود. برای مثال:

{
    "command": "remote-server6-get",
    "arguments": {
        "servers": [
            {
                "server-tag": "server1"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

این دستور اطلاعات سرور DHCPv6 را که با برچسب سرور "server1" مشخص شده است واکشی می‌کند. برچسب سرور به حروف بزرگ و کوچک حساس نیست. یک پاسخ موفقیت‌آمیز، اطلاعات پایه‌ای دربارهٔ سرور مانند برچسب سرور و توضیحات کاربر دربارهٔ سرور را بازمی‌گرداند:

{
    "result": 0,
    "text": "DHCP server server1 found.",
    "arguments": {
        "servers": [
            {
                "server-tag": "server1",
                "description": "A DHCPv6 server located on the first floor."
            }
        ],
        "count": 1
    }
}

این دستور برای واکشی تمام کارگزارهای DHCPv4 یا DHCPv6 تعریف‌شده توسط کاربر از پایگاه‌داده به کار می‌رود. ساختار دستور بسیار ساده است:

{
    "command": "remote-server4-get-all",
    "arguments": {
        "remote": {
            "type": "mysql"
        }
    }
}

پاسخ شامل اطلاعات پایه‌ای درباره هر کارگزار، مانند برچسب کارگزار و توضیحات آن است:

{
    "result": 0,
    "text": "DHCPv4 servers found.",
    "arguments": {
        "servers": [
            {
                "server-tag": "server1",
                "description": "A DHCP server located on the first floor."
            },
            {
                "server-tag": "server2",
                "description": "An old DHCP server to be soon replaced."
            }
        ],
       "count": 2
    }
}

این دستور برای ایجاد یا جایگزینی اطلاعات مربوط به یک کارگزار DHCP در پایگاه‌داده به کار می‌رود. اطلاعات کارگزار زمانی باید ایجاد شود که نیاز به تفکیک پیکربندی‌های استفاده‌شده توسط نمونه‌های گوناگون Kea متصل به یک پایگاه‌داده وجود داشته باشد. عناصر مختلف پیکربندی، مانند پارامترهای سراسری، زیرشبکه‌ها و غیره را می‌توان به‌طور صریح به کارگزارهای انتخاب‌شده پیوند داد (با استفاده از برچسب‌های کارگزار به‌عنوان شناسه)، که بدین ترتیب تنها این کارگزارها اجازه خواهند داشت از عناصر پیکربندی مربوطه استفاده کنند. استفاده از یک برچسب کارگزار مشخص برای برقراری چنین پیوندهایی تنها زمانی امکان‌پذیر است که اطلاعات کارگزار از طریق دستورهای remote-server4-set یا remote-server6-set در پایگاه‌داده ذخیره شده باشد. دستور زیر یک کارگزار DHCPv6 جدید را در پایگاه‌داده ایجاد می‌کند (یا اطلاعات موجود را به‌روزرسانی می‌کند):

{
    "command": "remote-server6-set",
    "arguments": {
        "servers": [
            {
                "server-tag": "server1",
                "description": "A DHCP server on the ground floor."
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

برچسب کارگزار باید در میان تمام کارگزارهای موجود در پایگاه‌داده یکتا باشد. هنگامی که اطلاعات کارگزار تحت برچسب داده‌شده از قبل موجود باشد، با اطلاعات جدید جایگزین می‌شود. برچسب کارگزار مشخص‌شده به حروف بزرگ و کوچک حساس نیست، و حداکثر طول آن ۲۵۶ نویسه است. کلیدواژه‌های زیر رزرو شده‌اند و نمی‌توان از آن‌ها به عنوان برچسب کارگزار استفاده کرد: "all" و "any".

در ادامه نمونه‌ای از پاسخ دستور بالا آمده است:

{
    "result": 0,
    "text": "DHCPv6 server successfully set.",
    "arguments": {
        "servers": [
            {
                "server-tag": "server1",
                "description": "A DHCP server on the ground floor."
            }
        ]
    }
}

این دستورها برای حذف یک پارامتر سراسری DHCP از پایگاه‌دادهٔ پیکربندی به کار می‌روند. هنگامی که پارامتر از پایگاه‌داده حذف می‌شود، کارگزار از مقدار مشخص‌شده در فایل پیکربندی برای این پارامتر استفاده می‌کند، یا اگر پارامتر در فایل پیکربندی مشخص نشده باشد، مقدار پیش‌فرض را به کار می‌برد.

دستور زیر تلاش می‌کند پارامتر DHCPv4 به نام renew-timer را که میان همهٔ کارگزارها مشترک است از پایگاه‌داده حذف کند:

{
    "command": "remote-global-parameter4-del",
    "arguments": {
        "parameters": [ "renew-timer" ],
        "remote": {
            "type": "mysql"
         },
        "server-tags": [ "all" ]
    }
}

اگر قرار است پارامتری مختص به یک کارگزار خاص حذف شود، فهرست server-tags باید شامل برچسب کارگزار مربوطه باشد. باید دقیقاً یک برچسب کارگزار در این فهرست مشخص شده باشد..SS دستورهای remote-global-parameter4-get و remote-global-parameter6-get

این دستورها برای دریافت یک پارامتر سراسری اسکالر (scalar) DHCP از پایگاه‌داده پیکربندی به کار می‌روند.

دستور زیر تلاش می‌کند پارامتر boot-file-name را برای "server1" واکشی کند:

{
    "command": "remote-global-parameter4-get",
    "arguments": {
        "parameters": [ "boot-file-name" ],
         "remote": {
             "type": "mysql"
         },
         "server-tags": [ "server1" ]
    }
}

مقدار بازگردانده‌شده دارای یکی از چهار نوع داده اسکالر است: رشته (string)، عدد صحیح (integer)، عدد حقیقی (real)، یا بولی (boolean). پارامترهای پیکربندی سراسری غیر اسکالر، مانند map یا list، توسط این دستور بازگردانده نمی‌شوند.

در مورد مثال بالا، مقدار رشته‌ای بازگردانده می‌شود، مانند:

{
    "result": 0,
    "text": "1 DHCPv4 global parameter found.",
    "arguments": {
        "parameters": {
            "boot-file-name": "/dev/null",
            "metadata": {
                "server-tags": [ "all" ]
            }
        },
        "count": 1
    }
}

توجه داشته باشید که پاسخ بالا نشان می‌دهد پارامتر بازگردانده‌شده به‌جای "server1" استفاده‌شده در دستور، با سرورهای "all" مرتبط است. این نشان می‌دهد که هیچ مقدار خاصی برای "server1" در پایگاه‌داده وجود ندارد و از این رو، مقدار مشترک بین همه سرورها بازگردانده شده است. اگر مقداری مختص "server1" در پایگاه‌داده وجود داشت، آن مقدار به‌جای این بازگردانده می‌شد.

پاسخ نمونه برای مقدار عدد صحیح عبارت است از:

{
    "result": 0,
    "text": "1 DHCPv4 global parameter found.",
    "arguments": {
        "parameters": {
            "renew-timer": 2000,
            "metadata": {
                "server-tags": [ "server1" ]
            }
        },
        "count": 1
    }
}

مقدار عدد حقیقی:

{
    "result": 0,
    "text": "1 DHCPv4 global parameter found.",
    "arguments": {
        "parameters": {
            "t1-percent": 0.85,
            "metadata": {
                "server-tags": [ "all" ]
            }
        },
        "count": 1
    }
}

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

{
    "result": 0,
    "text": "1 DHCPv4 global parameter found.",
    "arguments": {
        "parameters": {
            "match-client-id": true,
            "metadata": {
                "server-tags": [ "server2" ]
            }
        },
        "count": 1
    }
}

این دستورها برای واکشی تمام پارامترهای سراسری DHCP از پایگاه داده برای سرور مشخص‌شده به کار می‌روند. مثال زیر نحوهٔ واکشی تمام پارامترهای سراسری مورد استفاده توسط سرور "server1" را نشان می‌دهد:

{
    "command": "remote-global-parameter4-get-all",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

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

{
    "result": 0,
    "text": "DHCPv4 global parameters found.",
    "arguments": {
        "parameters": [
            {
                "boot-file-name": "/dev/null",
                "metadata": {
                    "server-tags": [ "server1" ]
                }
            },
            {
                "match-client-id": true,
                "metadata": {
                    "server-tags": [ "all" ]
                }
            }
        ],
        "count": 2
    }
}

پاسخ نمونه شامل دو پارامتر است: یک پارامتر رشته‌ای و یک پارامتر بولی (boolean). فرادادهٔ (metadata) بازگردانده‌شده برای هر پارامتر نشان می‌دهد که آیا این پارامتر مختص "server1" است یا برای همهٔ سرورها اعمال می‌شود. از آنجا که مقدار match-client-id با سرورهای "all" مرتبط است، نشان می‌دهد که تنظیم خاصی مختص "server1" برای این پارامتر وجود ندارد. هر پارامتر همیشه دقیقاً یک برچسب سرور مرتبط با خود دارد، چرا که پارامترهای سراسری عناصر پیکربندی غیرقابل‌اشتراک هستند.

نکته:

اگر برچسب سرور در دستور روی "all" تنظیم شده باشد، پاسخ تنها شامل پارامترهای سراسری مرتبط با سرور منطقی "all" خواهد بود. هنگامی که برچسب سرور به سرور خاصی اشاره کند (مانند مثال بالا)، فهرست بازگردانده‌شده پارامترهای مرتبط با این سرور و همهٔ سرورها را ترکیب می‌کند، اما اولویت با پارامترهای سرور خاص است.

این دستور برای ایجاد پارامترهای سراسری اسکالر DHCP در پایگاه داده به کار می‌رود. اگر هر یک از پارامترها از قبل وجود داشته باشد، مقدار آن در نتیجهٔ این دستور جایگزین می‌شود. امکان تنظیم چندین پارامتر در قالب یک دستور واحد وجود دارد که هر کدام می‌توانند یکی از چهار نوع رشته (string)، عدد صحیح (integer)، عدد حقیقی (real) یا بولی (boolean) را داشته باشند. برای مثال:

{
    "command": "remote-global-parameter4-set",
    "arguments": {
        "parameters": {
            "boot-file-name": "/dev/null",
            "renew-timer": 2000,
            "t1-percent": 0.85,
            "match-client-id": true
        },
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

اگر هر یک از پارامترها توسط سرور DHCP پشتیبانی نشود یا نوع آن مطابقت نداشته باشد، خطایی بازگردانده می‌شود. هنگام تعیین چندین پارامتر در یک دستور واحد باید دقت شود، زیرا ممکن است فقط برخی از پارامترها با موفقیت ذخیره شوند و برخی دیگر با خطا مواجه شوند. در صورت بروز خطا هنگام پردازش این دستور، توصیه می‌شود از remote-global-parameter4-get-all یا remote-global-parameter6-get-all برای بررسی اینکه کدام پارامترها با موفقیت ذخیره/به‌روزرسانی شده‌اند و کدام با شکست مواجه شده‌اند، استفاده کنید.

فهرست server-tags اجباری است و باید شامل یک برچسب سرور واحد یا کلیدواژهٔ "all" باشد. در مثال بالا، تمام پارامترهای مشخص‌شده با سرور "server1" مرتبط هستند.

این دستورها برای حذف یک شبکهٔ اشتراکی (shared network) از نوع IPv4 یا IPv6 از پایگاه داده به کار می‌روند. پارامتر اختیاری subnets-action تعیین می‌کند که آیا زیرشبکه‌های متعلق به شبکهٔ اشتراکی حذف‌شده نیز باید حذف شوند یا حفظ گردند. پارامتر subnets-action به‌طور پیش‌فرض روی keep تنظیم است که زیرشبکه‌ها را حفظ می‌کند. اگر روی delete تنظیم شود، زیرشبکه‌ها همراه با شبکهٔ اشتراکی حذف می‌شوند.

دستور زیر:

{
    "command": "remote-network6-del",
    "arguments": {
        "shared-networks": [
            {
                "name": "level3"
            }
        ],
        "subnets-action": "keep",
        "remote": {
            "type": "mysql"
        }
    }
}

شبکهٔ اشتراکی IPv6 با نام "level3" را حذف می‌کند. زیرشبکه‌ها حفظ می‌شوند، اما وابستگی آن‌ها از شبکهٔ اشتراکی حذف‌شده قطع شده و سراسری می‌شوند. این رفتار مطابق با رفتار دستورهای network4-del و network6-del با توجه به پارامتر subnets-action است.

توجه داشته باشید که پارامتر server-tags را نمی‌توان برای این دستور استفاده کرد..SS دستورهای remote-network4-get و remote-network6-get

این دستورها برای بازیابی اطلاعات مربوط به یک شبکه مشترک (shared network) از نوع IPv4 یا IPv6 به کار می‌روند. پارامتر اختیاری subnets-include مشخص می‌کند که آیا زیرشبکه‌های متعلق به شبکه مشترک نیز باید بازگردانده شوند یا خیر. مقدار پیش‌فرض این پارامتر no است که در این حالت زیرشبکه‌ها بازگردانده نمی‌شوند. اگر این پارامتر روی full تنظیم شود، زیرشبکه‌ها همراه با شبکه مشترک بازگردانده می‌شوند.

دستور زیر شبکه مشترک IPv6 با نام "level3" را به همراه اطلاعات کامل زیرشبکه‌های متعلق به آن واکشی می‌کند:

{
    "command": "remote-network6-get",
    "arguments": {
        "shared-networks": [
            {
                "name": "level3"
            }
        ],
        "subnets-include": "full",
        "remote": {
            "type": "mysql"
        }
    }
}

توجه داشته باشید که پارامتر server-tags را نمی‌توان برای این دستور استفاده کرد.

این دستورها برای فهرست کردن تمام شبکه‌های مشترک IPv4 یا IPv6 برای یک سرور به کار می‌روند.

دستور زیر تمام شبکه‌های مشترکی را که قرار است توسط "server1" و "server2" استفاده شوند بازیابی می‌کند:

{
    "command": "remote-network4-list",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1", "server2" ]
    }
}

پارامتر server-tags اجباری است و شامل یک یا چند برچسب سرور می‌باشد. این پارامتر می‌تواند حاوی کلیدواژه "all" باشد تا شبکه‌های مشترک مرتبط با همه سرورها را واکشی کند. هنگامی که فهرست server-tags حاوی مقدار null باشد، پاسخ بازگردانده شده شامل فهرستی از شبکه‌های مشترک تخصیص‌نیافته خواهد بود؛ یعنی شبکه‌هایی که با هیچ سروری مرتبط نیستند. برای مثال:

{
    "command": "remote-network4-list",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ null ]
    }
}

پاسخ نمونه به این دستور در حالتی که برچسب‌های سرور غیر null مشخص شده باشند، مشابه این خواهد بود:

{
    "result": 0,
    "text": "3 IPv4 shared network(s) found.",
    "arguments": {
        "shared-networks": [
            {
                "name": "ground floor",
                "metadata": {
                    "server-tags": [ "all" ]
                }
            },
            {
                "name": "floor2",
                "metadata": {
                    "server-tags": [ "server1" ]
                }
            },
            {
                "name": "floor3",
                "metadata": {
                    "server-tags": [ "server2" ]
                }
            }
        ],
        "count": 3
    }
}

اطلاعات بازگردانده شده درباره هر شبکه مشترک صرفاً شامل نام شبکه مشترک و متادیتا است. برای واکشی اطلاعات دقیق‌تر درباره شبکه مشترک انتخاب‌شده، از دستور remote-network4-get یا remote-network6-get استفاده کنید.

پاسخ نمونه بالا شامل سه شبکه مشترک است. یکی از شبکه‌های مشترک با تمام سرورها مرتبط است، بنابراین در فهرست شبکه‌های مشترکی که باید توسط "server1" و "server2" استفاده شوند گنجانده شده است. دو شبکه مشترک باقی‌مانده بازگردانده شده‌اند زیرا یکی از آن‌ها با "server1" و دیگری با "server2" مرتبط است.

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

{
    "result": 0,
    "text": "1 IPv4 shared network(s) found.",
    "arguments": {
        "shared-networks": [
            {
                "name": "fancy",
                "metadata": {
                    "server-tags": [ null ]
                }
            }
        ],
        "count": 1
    }
}

مقدار null در متادیتا نشان می‌دهد که شبکه مشترک بازگردانده‌شده تخصیص نیافته است..SS دستورهای remote-network4-set و remote-network6-set

این دستورها یک شبکهٔ اشتراکی IPv4 یا IPv6 جدید در پایگاه‌داده ایجاد کرده یا جایگزین نمونهٔ موجود می‌کنند. ساختار اطلاعات شبکهٔ اشتراکی همانند فایل پیکربندی Kea است (برای جزئیات به Shared Networks in DHCPv4 <#shared-network4> و Shared Networks in DHCPv6 <#shared-network6> مراجعه کنید)، با این تفاوت که مشخص کردن زیرشبکه‌ها همراه با اطلاعات شبکهٔ اشتراکی مجاز نیست. گنجاندن پارامتر subnet4 یا subnet6 درون اطلاعات شبکهٔ اشتراکی منجر به بروز خطا می‌شود.

این دستورها به منظور مدیریت اطلاعات مختص شبکهٔ اشتراکی و گزینه‌های DHCP طراحی شده‌اند. برای مرتبط‌سازی و لغو ارتباط زیرشبکه‌ها با شبکه‌های اشتراکی، باید از دستورهای remote-subnet4-set و remote-subnet6-set استفاده شود.

دستور زیر، شبکهٔ اشتراکی IPv6 با نام "level3" را به پایگاه‌داده اضافه می‌کند:

{
    "command": "remote-network6-set",
    "arguments": {
        "shared-networks": [
            {
                "name": "level3",
                "interface": "eth0",
                "option-data": [ {
                    "name": "sntp-servers",
                    "data": "2001:db8:1::1"
                } ]
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

این دستور شامل پارامتر interface است که نام رابط را در سطح شبکهٔ اشتراکی تعیین می‌کند. سایر پارامترهای سطح شبکهٔ اشتراکی که با این دستور مشخص نشده باشند، در پایگاه‌داده به عنوان "unspecified" علامت‌گذاری خواهند شد. کارگزار DHCP برای پارامترهای مشخص‌نشده از مقادیر سراسری استفاده می‌کند یا در صورتی که مقادیر سراسری تعیین نشده باشند، مقادیر پیش‌فرض به کار گرفته می‌شوند.

فهرست server-tags برای این دستور اجباری است و باید شامل یک یا چند برچسب کارگزار باشد. در نتیجه، شبکهٔ اشتراکی با تمامی کارگزارهای فهرست‌شده مرتبط می‌شود. هنگامی که کلیدواژهٔ "all" در آن قرار گیرد، شبکهٔ اشتراکی با تمامی کارگزارهایی که به پایگاه‌داده متصل می‌شوند مرتبط خواهد شد.

نکته:

مشابه سایر دستورهای "set"، در صورتی که شبکهٔ اشتراکی از قبل وجود داشته باشد، این دستور تمام اطلاعات مربوط به آن شبکهٔ اشتراکی مشخص‌شده را در پایگاه‌داده جایگزین می‌کند. بنابراین، هنگام ارسال این دستور، اطمینان حاصل کنید که همیشه تمام پارامترهایی را که باید برای نمونهٔ به‌روزشدهٔ شبکهٔ اشتراکی مشخص باشند، بگنجانید. هر پارامتر نامشخص، حتی اگر مقدار آن قبل از ارسال دستور در پایگاه‌داده موجود بوده باشد، به عنوان نامشخص (unspecified) علامت‌گذاری خواهد شد.

این دستورها برای حذف تعریف یک گزینهٔ DHCP از پایگاه‌داده استفاده می‌شوند. تعریف گزینه توسط یک کد گزینه و فضای گزینه مشخص می‌شود. برای مثال:

{
    "command": "remote-option-def6-del",
    "arguments": {
        "option-defs": [
            {
                "code": 1,
                "space": "isc"
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

تعریف گزینهٔ مرتبط با "server1" را که دارای کد 1 و متعلق به فضای گزینهٔ "isc" است حذف می‌کند. فضاهای گزینهٔ پیش‌فرض برای گزینه‌های سطح بالای DHCPv4 و DHCPv6 به ترتیب "dhcp4" و "dhcp6" هستند. اگر چنین تعریف گزینه‌ای به‌طور صریح با "server1" مرتبط نباشد، هیچ تعریفی حذف نمی‌شود. برای حذف تعریف گزینه‌ای که متعلق به کارگزارهای "all" است، باید از کلیدواژهٔ "all" به عنوان برچسب کارگزار استفاده شود. فهرست server-tags باید دقیقاً شامل یک برچسب باشد و نمی‌تواند مقدار null داشته باشد.

از نگارش Kea 3.1.2 به بعد، کارگزار قبل از حذف تعریف گزینه، ابتدا بررسی می‌کند که آیا گزینه‌ای وجود دارد که به آن تعریف وابسته باشد یا خیر. در این صورت، دستور حذف به همراه پیام خطایی که دلیل آن را شرح می‌دهد رد خواهد شد. این رفتار پیش‌فرض را می‌توان با تنظیم پارامتر اختیاری force روی مقدار true مطابق شکل زیر نادیده گرفت:

{
    "command": "remote-option-def6-del",
    "arguments": {
        "option-defs": [
            {
                "code": 1,
                "space": "isc",
                "force": true
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

نکته:

پارامتر force تنها پس از بررسی دقیق باید استفاده شود. حذف یک تعریف گزینه در حالی که مشخصات گزینه‌ای وابسته وجود دارد، باعث کنار گذاشته شدن آن گزینه از پیکربندی در حال اجرا خواهد شد. این پارامتر برای مواردی در نظر گرفته شده که ممکن است نیاز به اصلاح تعریف باشد در حالی که خود گزینه در جای خود باقی بماند.

این دستورها برای واکشی تعریف یک گزینه (option definition) مشخص DHCP از پایگاه‌داده به کار می‌روند. تعریف گزینه از طریق کد گزینه و فضای گزینه (option space) مشخص می‌شود. فضاهای پیش‌فرض گزینه برای گزینه‌های سطح بالای DHCPv4 و DHCPv6 به ترتیب "dhcp4" و "dhcp6" هستند.

دستور زیر یک تعریف گزینه DHCPv4 مرتبط با تمام سرورها را با کد ۱ و متعلق به فضای گزینه "isc" بازیابی می‌کند:

{
    "command": "remote-option-def4-get",
    "arguments": {
        "option-defs": [
            {
                "code": 1,
                "space": "isc"
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

فهرست server-tags باید دقیقاً شامل یک برچسب سرور یا کلیدواژه "all" باشد و نمی‌تواند شامل مقدار null باشد.

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

{
    "command": "remote-option-def6-get-all",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

این دستور تلاش می‌کند تمام تعاریف گزینه‌های DHCPv6 مرتبط با سرورهای "all" را واکشی کند. فهرست server-tags برای این دستور اجباری است و باید دقیقاً شامل یک برچسب سرور یا کلیدواژه "all" باشد. این مقدار نمی‌تواند null باشد.

نمونه پاسخ به این دستور به شرح زیر است:

{
    "result": 0,
    "text": "1 DHCPv6 option definition(s) found.",
    "arguments": {
        "option-defs": [
            {
                "name": "bar",
                "code": 1012,
                "space": "dhcp6",
                "type": "record",
                "array": true,
                "record-types": "ipv6-address, uint16",
                "encapsulate": "",
                "metadata": {
                    "server-tags": [ "all" ]
                }
            }
        ],
        "count": 1
    }
}

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

این دستورها یک تعریف گزینه DHCP جدید ایجاد می‌کنند یا تعریف گزینه موجود در پایگاه‌داده را جایگزین می‌نمایند. ساختار اطلاعات تعریف گزینه مشابه فایل پیکربندی Kea است (نگاه کنید به گزینه‌های سفارشی DHCPv4 <#dhcp4-custom-options> و گزینه‌های سفارشی DHCPv6 <#dhcp6-custom-options>). دستور زیر تعریف گزینه DHCPv4 را در فضای گزینه سطح بالای "dhcp4" ایجاد کرده و آن را به "server1" اختصاص می‌دهد:

{
    "command": "remote-option-def4-set",
    "arguments": {
        "option-defs": [
            {
                "name": "foo",
                "code": 222,
                "type": "uint32",
                "array": false,
                "record-types": "",
                "space": "dhcp4",
                "encapsulate": ""
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

فهرست server-tags باید دقیقاً شامل یک برچسب سرور یا کلیدواژه "all" باشد و نمی‌تواند شامل مقدار null باشد..SS دستورهای remote-option4-global-del و remote-option6-global-del

این دستورها برای حذف یک گزینه سراسری DHCP از پایگاه داده استفاده می‌شوند. گزینه بر اساس کد گزینه و فضای گزینه شناسایی می‌شود. از نسخه Kea 3.1.1 به بعد، یک پارامتر اختیاری client-classes نیز می‌تواند مشخص شود (به بخش Option Class-tags as Keys مراجعه کنید).

برای مثال:

{
    "command": "remote-option4-global-del",
    "arguments": {
        "options": [
            {
                "code": 5,
                "space": "dhcp4",
                "client-classes": [ "class-one" ]
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

مقدار "dhcp4" نشان‌دهنده فضای گزینه سطح بالایی است که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر server-tags اجباری است و باید شامل یک برچسب گزینه تکی یا کلیدواژه "all" باشد. اگر برچسب سرور صریح مشخص شده باشد، این دستور تلاش می‌کند گزینه سراسری مرتبط با این سرور را حذف کند. اگر چنین گزینه‌ای مرتبط با سرور مشخص‌شده وجود نداشته باشد، هیچ گزینه‌ای حذف نمی‌شود. برای حذف گزینه‌ای که با همه سرورها مرتبط است، باید کلیدواژه "all" مشخص شود.

این دستورها برای واکشی یک گزینه سراسری DHCP از پایگاه داده استفاده می‌شوند. گزینه بر اساس کد و فضای گزینه شناسایی می‌شود. بالاترین سطح فضاهای گزینه که گزینه‌های استاندارد DHCP به آن‌ها تعلق دارند، به ترتیب برای سرورهای DHCPv4 و DHCPv6 با نام‌های "dhcp4" و "dhcp6" شناخته می‌شوند. از نسخه Kea 3.1.1 به بعد، یک پارامتر اختیاری client-classes نیز می‌تواند مشخص شود (به بخش Option Class-tags as Keys مراجعه کنید).

دستور زیر گزینه "DNS Servers" در IPv6 (کد 23) که با همه سرورها مرتبط است را بازیابی می‌کند:

{
    "command": "remote-option6-global-get",
    "arguments": {
        "options": [
            {
                "code": 23,
                "space": "dhcp6",
                "client-classes": [ "class-one" ]
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

پارامتر server-tags اجباری است و باید دقیقا شامل یک برچسب سرور یا کلیدواژه "all" باشد. این پارامتر نمی‌تواند حاوی مقدار null باشد.

این دستورها برای واکشی تمام گزینه‌های سراسری DHCP از پایگاه داده پیکربندی برای سرور داده‌شده یا برای همه سرورها استفاده می‌شوند. دستور زیر همه گزینه‌های سراسری DHCPv4 را برای "server1" واکشی می‌کند:

{
    "command": "remote-option6-global-get-all",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

فهرست server-tags برای این دستور اجباری است و باید دقیقا شامل یک برچسب سرور یا کلیدواژه "all" باشد؛ این فهرست نمی‌تواند شامل مقدار null باشد.

در زیر یک پاسخ نمونه به این دستور آورده شده است که در آن یک گزینه تکی مرتبط با "server1" بازگردانده شده است:

{
    "result": 0,
    "text": "DHCPv4 options found.",
    "arguments": {
        "options": [
            {
                "name": "domain-name-servers",
                "code": 6,
                "space": "dhcp4",
                "csv-format": false,
                "data": "192.0.2.3",
                "metadata": {
                    "server-tags": [ "server1" ]
                }
            }
        ],
        "count": 1
    }
}

این دستورها یک گزینهٔ سراسری جدید DHCP ایجاد کرده یا یک گزینهٔ موجود در پایگاه‌داده را جایگزین می‌کنند. ساختار اطلاعات گزینه مشابه ساختار موجود در فایل پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 در <#dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 در <#dhcp6-std-options> را ببینید). برای مثال:

{
    "command": "remote-option6-global-set",
    "arguments": {
        "options": [
            {
                "name": "dns-servers",
                "data": "2001:db8:1::1"
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

فهرست server-tags برای این دستور اجباری است و باید دقیقاً شامل یک برچسب سرور یا کلیدواژهٔ "all" باشد؛ این مقدار نمی‌تواند حاوی مقدار null باشد. دستور بالا گزینه را به سرور "server1" مرتبط می‌سازد.

توجه داشته باشید که مشخص کردن نام گزینه به جای کد گزینه تنها برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان کار می‌کند. هنگام تعیین مقداری برای یک گزینهٔ سفارشی DHCP، باید به جای نام، کد گزینه مشخص شود. برای مثال:

{
    "command": "remote-option6-global-set",
    "arguments": {
        "options": [
            {
                "code": 1,
                "space": "isc",
                "data": "2001:db8:1::1"
            }
        ],
        "server-tags": [ "server1" ]
    }
}

این دستورها برای حذف یک گزینهٔ DHCP مختص شبکهٔ اشتراکی (shared network) از پایگاه‌داده به کار می‌روند. گزینه با یک کد گزینه و فضای گزینه شناسایی می‌شود، و از Kea 3.1.1 به بعد، یک پارامتر اختیاری client-classes نیز می‌تواند تعیین گردد (بخش Option Class-tags as Keys را ببینید). این پارامترها در داخل فهرست options ارسال می‌شوند. فهرست دیگر، shared-networks، شامل یک مَپ با نام شبکهٔ اشتراکی است که گزینه باید از آن حذف شود. اگر گزینه به‌طور صریح برای این شبکهٔ اشتراکی مشخص نشده باشد، هیچ گزینه‌ای حذف نمی‌شود. به‌ویژه، گزینهٔ مورد نظر ممکن است برای یک زیرشبکهٔ متعلق به آن شبکهٔ اشتراکی وجود داشته باشد. چنین موردی تحت تأثیر این دستور قرار نمی‌گیرد زیرا این دستور صرفاً گزینهٔ سطح شبکهٔ اشتراکی را حذف می‌کند. برای حذف یک گزینه در سطح زیرشبکه، باید به جای آن از دستورهای remote-option4-subnet-del و remote-option6-subnet-del استفاده شود.

دستور زیر تلاش می‌کند گزینه‌ای با کد گزینهٔ ۵ در بالاترین سطح فضای گزینه (top-level option space) و یک فهرست خالی client-classes را از شبکهٔ اشتراکی "fancy" حذف کند.

{
    "command": "remote-option4-network-del",
    "arguments": {
        "shared-networks": [
            {
                "name": "fancy"
            }
        ],
        "options": [
            {
                "code": 5,
                "space": "dhcp4",
                "client-classes" : [ ]
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

مقدار "dhcp4" نشان‌دهندهٔ بالاترین سطح فضای گزینه است که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر server-tags نمی‌تواند برای این دستور مشخص شود.

این دستورها یک گزینهٔ DHCP جدید مختص شبکهٔ اشتراکی ایجاد کرده یا یک گزینهٔ موجود در پایگاه‌داده را جایگزین می‌کنند. ساختار اطلاعات گزینه مشابه فایل پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 در <#dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 در <#dhcp6-std-options> را ببینید). اطلاعات گزینه در فهرست options منتقل می‌شود. فهرست دیگری به نام shared-networks شامل یک مَپ با نام شبکهٔ اشتراکی است که گزینه برای آن تنظیم می‌شود. اگر چنین گزینه‌ای از قبل برای شبکهٔ اشتراکی وجود داشته باشد، با نمونهٔ جدید جایگزین می‌شود.

{
    "command": "remote-option6-network-set",
    "arguments": {
        "shared-networks": [
            {
                "name": "fancy"
            }
        ],
        "options": [
            {
                "name": "dns-servers",
                "data": "2001:db8:1::1"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags نمی‌تواند برای این دستور مشخص شود.

مشخص کردن نام گزینه به جای کد گزینه فقط برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان عمل می‌کند. هنگام تعیین یک مقدار برای گزینهٔ سفارشی DHCP، باید به جای نام، از کد گزینه استفاده شود..SS دستور remote-option6-pd-pool-del

این دستور برای حذف یک گزینه DHCPv6 مختص استخر واگذاری پیشوند (prefix delegation pool) از پایگاه‌داده به کار می‌رود. گزینه با یک کد گزینه و فضای گزینه شناسایی می‌شود، و از نسخه Kea 3.1.1 به بعد، پارامتر اختیاری client-classes نیز می‌تواند مشخص شود (به Option Class-tags as Keys مراجعه کنید). این پارامترها درون فهرست options ارسال می‌شوند. فهرست دیگری به نام pd-pools شامل یک نگاشت با پیشوند و طول استخر واگذاری پیشوند است که استخر را مشخص می‌کند. اگر گزینه به‌طور صریح برای این استخر مشخص نشده باشد، هیچ گزینه‌ای حذف نمی‌شود. به‌ویژه، گزینه داده‌شده ممکن است برای زیرشبکه‌ای شامل استخر مشخص‌شده وجود داشته باشد. چنین نمونه‌ای از گزینه تحت تأثیر این دستور قرار نمی‌گیرد، زیرا این دستور صرفاً یک گزینه در سطح استخر واگذاری پیشوند را حذف می‌کند. برای حذف گزینه‌ای در سطح زیرشبکه، باید به جای آن از دستور remote-option6-subnet-del استفاده شود.

{
    "command": "remote-option6-pd-pool-del",
    "arguments": {
        "pd-pools": [
            {
                "prefix": "3000::",
                "prefix-len": 64
            }
        ],
        "options": [
            {
                "code": 23,
                "space": "dhcp6"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

مقدار "dhcp6" نشان‌دهنده فضای گزینه سطح بالا است که گزینه‌های استاندارد DHCPv6 به آن تعلق دارند. پارامتر server-tags را نمی‌توان برای این دستور مشخص کرد.

این دستور یک گزینه DHCPv6 جدید مختص استخر واگذاری پیشوند ایجاد کرده یا گزینه‌ای موجود در پایگاه‌داده را جایگزین می‌کند. ساختار اطلاعات گزینه مشابه پرونده پیکربندی Kea است (به Standard DHCPv4 Options <#dhcp4-std-options> و Standard DHCPv6 Options <#dhcp6-std-options> مراجعه کنید). اطلاعات گزینه در فهرست options حمل می‌شود. فهرست دیگری به نام pd-pools شامل نگاشتی با پیشوند استخر واگذاری پیشوند و طول پیشوند است که استخر را شناسایی می‌کند. اگر چنین گزینه‌ای از قبل برای استخر واگذاری پیشوند وجود داشته باشد، با نمونه جدید جایگزین می‌شود.

برای مثال:

{
    "command": "remote-option6-pd-pool-set",
    "arguments": {
        "pd-pools": [
            {
                "prefix": "3001:1::",
                "length": 64
            }
        ],
        "options": [
            {
                "name": "dns-servers",
                "data": "2001:db8:1::1"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags را نمی‌توان برای این دستور مشخص کرد.

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

این دستورها برای حذف یک گزینه DHCP مختص استخر نشانی از پایگاه‌داده به کار می‌روند. گزینه با یک کد گزینه و فضای گزینه شناسایی می‌شود، و از نسخه Kea 3.1.1 به بعد، پارامتر اختیاری client-classes نیز ممکن است مشخص شود (به Option Class-tags as Keys مراجعه کنید). این پارامترها در فهرست options ارسال می‌شوند. فهرست دیگری به نام pools شامل یک نگاشت با محدوده نشانی IP یا پیشوند مشخص‌کننده استخر است. اگر گزینه به‌طور صریح برای این استخر مشخص نشده باشد، هیچ گزینه‌ای حذف نخواهد شد. به‌ویژه، گزینه داده‌شده ممکن است برای زیرشبکه‌ای شامل استخر مشخص‌شده وجود داشته باشد. چنین نمونه‌ای از گزینه تحت تأثیر این دستور قرار نمی‌گیرد، چرا که این دستور صرفاً گزینه‌ای در سطح استخر را حذف می‌کند. برای حذف گزینه‌ای در سطح زیرشبکه، باید به جای آن از دستور remote-option4-subnet-del یا remote-option6-subnet-del استفاده شود.

دستور زیر تلاش می‌کند گزینه‌ای با کد گزینه 5 در فضای گزینه سطح بالا را از یک استخر نشانی IPv4 حذف کند:

{
    "command": "remote-option4-pool-del",
    "arguments": {
        "pools": [
            {
                "pool": "192.0.2.10 - 192.0.2.100"
            }
        ],
        "options": [
            {
                "code": 5,
                "space": "dhcp4"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

مقدار "dhcp4" نشان‌دهنده فضای گزینه سطح بالا است که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر server-tags را نمی‌توان برای این دستور مشخص کرد..SS دستورهای remote-option4-pool-set و remote-option6-pool-set

این دستورها یک گزینهٔ DHCP جدیدِ مختص استخر آدرس ایجاد کرده یا گزینه‌ای موجود را در پایگاه داده جایگزین می‌کنند. ساختار اطلاعات گزینه همانند پروندهٔ پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 <#dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 <#dhcp6-std-options> را ببینید). اطلاعات گزینه در فهرست options منتقل می‌شود. فهرست دیگری به نام pools شامل نگاشتی با بازهٔ نشانی IP یا پیشوندی است که استخر را مشخص می‌سازد. اگر چنین گزینه‌ای از قبل برای استخر وجود داشته باشد، با نمونهٔ جدید جایگزین می‌شود.

برای نمونه:

{
    "command": "remote-option4-pool-set",
    "arguments": {
        "pools": [
            {
                "pool": "192.0.2.10 - 192.0.2.100"
            }
        ],
        "options": [
            {
                "name": "domain-name-servers",
                "data": "10.0.0.1"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags را نمی‌توان برای این دستور مشخص کرد.

مشخص کردن نام گزینه به جای کد گزینه، فقط برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان کار می‌کند. هنگام تعیین مقدار برای یک گزینهٔ DHCP تعریف‌شده توسط کاربر (user-defined)، باید کد گزینه به جای نام آن درج شود.

این دستورها برای حذف یک گزینهٔ DHCP مختص زیرشبکه از پایگاه داده به کار می‌روند. گزینه با یک کد گزینه، فضای گزینه (option space) و از نسخهٔ Kea 3.1.1 به بعد، با یک پارامتر اختیاری client-classes شناسایی می‌شود (بخش Option Class-tags as Keys را ببینید). این پارامترها درون فهرست options ارسال می‌شوند. فهرست دیگر، subnets، شامل نگاشتی با شناسهٔ زیرشبکه‌ای است که گزینه باید از آن حذف شود. اگر گزینه به‌طور صریح برای این زیرشبکه مشخص نشده باشد، هیچ گزینه‌ای حذف نمی‌شود.

دستور زیر تلاش می‌کند گزینه‌ای با کد گزینهٔ 5 را در فضای گزینهٔ سطح‌بالا (top-level) از زیرشبکه‌ای با شناسهٔ 123 حذف کند.

{
    "command": "remote-option4-subnet-del",
    "arguments": {
        "subnets": [
            {
                "id": 123
            }
        ],
        "options": [
            {
                "code": 5,
                "space": "dhcp4"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

مقدار "dhcp4" نشان‌دهندهٔ فضای گزینهٔ سطح‌بالاست که گزینه‌های استاندارد DHCPv4 به آن تعلق دارند. پارامتر server-tags را نمی‌توان برای این دستور مشخص کرد.

این دستورها یک گزینهٔ DHCP جدیدِ مختص زیرشبکه ایجاد کرده یا گزینه‌ای موجود را در پایگاه داده جایگزین می‌کنند. ساختار اطلاعات گزینه مشابه پروندهٔ پیکربندی Kea است (بخش گزینه‌های استاندارد DHCPv4 <#dhcp4-std-options> و گزینه‌های استاندارد DHCPv6 <#dhcp6-std-options> را ببینید). اطلاعات گزینه در فهرست options منتقل می‌شود. فهرست دیگری به نام subnets شامل نگاشتی با شناسهٔ زیرشبکه‌ای است که گزینه باید برای آن تنظیم شود. اگر چنین گزینه‌ای از قبل برای زیرشبکه وجود داشته باشد، با نمونهٔ جدید جایگزین خواهد شد.

{
    "command": "remote-option6-subnet-set",
    "arguments": {
        "subnets": [
            {
                "id": 123
            }
        ],
        "options": [
            {
                "name": "dns-servers",
                "data": "2001:db8:1::1"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags را نمی‌توان برای این دستور مشخص کرد.

مشخص کردن نام گزینه به جای کد گزینه، فقط برای گزینه‌های استاندارد DHCP به‌طور قابل‌اطمینان کار می‌کند. هنگام تعیین مقدار برای گزینهٔ DHCP تعریف‌شده توسط کاربر، باید کد گزینه به جای نام آن مشخص شود..SS دستورهای remote-subnet4-del-by-id و remote-subnet6-del-by-id

این نخستین گونه از دستورهایی است که برای حذف یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از شناسهٔ زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه، جهت حذف زیرشبکهٔ IPv4 با شناسهٔ ۵:

{
    "command": "remote-subnet4-del-by-id",
    "arguments": {
        "subnets": [
            {
                "id": 5
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags نمی‌تواند همراه با این دستور استفاده شود.

این دومین گونه از دستورهایی است که برای حذف یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از پیشوند زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه:

{
    "command": "remote-subnet6-del-by-prefix",
    "arguments": {
        "subnets": [
            {
                "subnet": "2001:db8:1::/64"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags نمی‌تواند همراه با این دستور استفاده شود.

این نخستین گونه از دستورهایی است که برای واکشی یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از شناسهٔ زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه:

{
    "command": "remote-subnet4-get-by-id",
    "arguments": {
        "subnets": [
            {
                "id": 5
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags نمی‌تواند همراه با این دستور استفاده شود.

این دومین گونه از دستورهایی است که برای واکشی یک زیرشبکه IPv4 یا IPv6 از پایگاه‌داده به کار می‌روند. این دستور از پیشوند زیرشبکه برای شناسایی آن استفاده می‌کند. برای نمونه:

{
    "command": "remote-subnet6-get-by-prefix",
    "arguments": {
        "subnets": [
            {
                "subnet": "2001:db8:1::/64"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags نمی‌تواند همراه با این دستور استفاده شود.

این دستورها برای فهرست کردن تمام زیرشبکه‌های IPv4 یا IPv6 از پایگاه‌داده برای سرورهای برگزیده یا همهٔ سرورها به کار می‌روند. دستور زیر تمامی سرورهای مورد استفاده توسط "server1" و "server2" را بازیابی می‌کند:

{
    "command": "remote-subnet4-list",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1", "server2" ]
    }
}

پارامتر server-tags اجباری است و شامل یک یا چند برچسب سرور است. این پارامتر می‌تواند حاوی کلیدواژهٔ "all" باشد تا زیرشبکه‌های مرتبط با همهٔ سرورها را واکشی کند. هنگامی که فهرست server-tags حاوی مقدار null باشد، پاسخ بازگردانده‌شده شامل فهرستی از زیرشبکه‌های تخصیص‌نیافته خواهد بود، یعنی زیرشبکه‌هایی که با هیچ سروری مرتبط نیستند. برای نمونه:

{
    "command": "remote-subnet4-list",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ null ]
    }
}

پاسخ نمونه به این دستور هنگامی که برچسب‌های سرور غیر null مشخص شده باشند، شبیه به این خواهد بود:

{
    "result": 0,
    "text": "2 IPv4 subnet(s) found.",
    "arguments": {
        "subnets": [
            {
                "id": 1,
                "subnet": "192.0.2.0/24",
                "shared-network-name": null,
                "metadata": {
                    "server-tags": [ "server1", "server2" ]
                }
            },
            {
                "id": 2,
                "subnet": "192.0.3.0/24",
                "shared-network-name": null,
                "metadata": {
                    "server-tags": [ "all" ]
                }
            }
        ],
        "count": 2
    }
}

اطلاعات بازگردانده‌شده دربارهٔ هر زیرشبکه به شناسهٔ زیرشبکه، پیشوند و نام شبکهٔ مشترک مرتبط محدود می‌شود. برای بازیابی اطلاعات کامل دربارهٔ زیرشبکهٔ برگزیده، از دستور remote-subnet4-get-by-id / remote-subnet6-get-by-id یا دستور remote-subnet4-get-by-prefix / remote-subnet6-get-by-prefix استفاده کنید.

پاسخ نمونهٔ بالا شامل دو زیرشبکه است. یکی از زیرشبکه‌ها با هر دو سرور "server1" و "server2" مرتبط است. زیرشبکهٔ دوم با همهٔ سرورها مرتبط است، بنابراین در پیکربندی‌های "server1" و "server2" نیز حضور دارد.

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

{
    "result": 0,
    "text": "1 IPv4 subnet(s) found.",
    "arguments": {
        "subnets": [
            {
                "id": 3,
                "subnet": "192.0.4.0/24",
                "shared-network-name": null,
                "metadata": {
                    "server-tags": [ null ]
                }
            }
        ],
        "count": 1
    }
}

مقدار null در متادیتا نشان می‌دهد که زیرشبکهٔ بازگردانده‌شده تخصیص‌نیافته است..SS دستورهای remote-subnet4-set و remote-subnet6-set

این دستورها برای ایجاد یک زیرشبکه جدید IPv4 یا IPv6 و یا جایگزینی یک زیرشبکه موجود در پایگاه داده به کار می‌روند. تنظیم زیرشبکه همچنین آن را به یک شبکه مشترک (shared network) منتسب یا از آن منفصل می‌کند.

ساختار اطلاعات زیرشبکه مشابه ساختاری است که در فایل پیکربندی استفاده می‌شود (نگاه کنید به پیکربندی کارساز DHCPv4 <#dhcp4-configuration> و پیکربندی کارساز DHCPv6 <#dhcp6-configuration>). اطلاعات زیرشبکه منتقل‌شده در دستور remote-subnet4-set یا remote-subnet6-set باید شامل پارامتر اضافی shared-network-name باشد که مشخص می‌کند آیا زیرشبکه به یک شبکه مشترک تعلق دارد یا خیر.

مثال زیر را در نظر بگیرید:

{
    "command": "remote-subnet4-set",
    "arguments": {
        "subnets": [
            {
                "id": 5,
                "subnet": "192.0.2.0/24",
                "shared-network-name": "level3",
                "pools": [ { "pool": "192.0.2.100-192.0.2.200" } ],
                "option-data": [ {
                    "name": "routers",
                    "data": "192.0.2.1"
                } ]
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

این دستور زیرشبکه را ایجاد کرده و آن را به شبکه مشترک "level3" منتسب می‌کند. شبکه مشترک "level3" باید پیش از ایجاد زیرشبکه با دستور remote-network4-set ایجاد شده باشد.

اگر زیرشبکه ایجادشده باید سراسری (global) باشد - یعنی به هیچ شبکه مشترکی منتسب نباشد - پارامتر shared-network-name باید صریحاً روی null تنظیم شود:

{
    "command": "remote-subnet4-set",
    "arguments": {
        "subnets": [
            {
                "id": 5,
                "subnet": "192.0.2.0/24",
                "shared-network-name": null,
                "pools": [ { "pool": "192.0.2.100-192.0.2.200" } ],
                "option-data": [ {
                    "name": "routers",
                    "data": "192.0.2.1"
                } ]
           }
        ],
        "server-tags": [ "all" ]
    }
}

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

پارامتر shared-network-name برای دستور remote-subnet4-set اجباری است. فهرست server-tags اجباری است و باید شامل یک یا چند برچسب کارساز باشد. در نتیجه، زیرشبکه به تمام کارسازهای فهرست‌شده منتسب می‌شود. همچنین در صورتی که کلیدواژه "all" به عنوان برچسب کارساز استفاده شود، ممکن است به تمام کارسازهای متصل به پایگاه داده منتسب گردد.

نکته:

همانند سایر دستورهای "set"، این دستور در صورتی که اطلاعات زیرشبکه از قبل موجود باشد، تمام اطلاعات مربوط به آن زیرشبکه خاص را در پایگاه داده جایگزین می‌کند. بنابراین، هنگام ارسال این دستور، اطمینان حاصل کنید که همیشه تمام پارامترهایی را که باید برای نمونه به‌روزشدهٔ زیرشبکه مشخص شوند بگنجانید. هر پارامتر نامشخصی در پایگاه داده به عنوان نامشخص علامت‌گذاری خواهد شد، حتی اگر مقدار آن پیش از ارسال دستور وجود داشته باشد.

این دستورها یک کلاس کلاینت DHCPv4 یا DHCPv6 را بر اساس نام حذف می‌کنند. اگر هر یک از کلاس‌های کلاینت در پایگاه داده به کلاس حذف‌شده وابسته باشند، در پاسخ به این دستور یک خطا بازگردانده می‌شود. در این حالت، برای حذف موفقیت‌آمیز کلاس، کلاس‌های کلاینت وابسته باید ابتدا حذف شوند. از دستور remote-class4-get-all برای دریافت همه کلاس‌های کلاینت و پیدا کردن موارد وابسته استفاده کنید.

{
    "command": "remote-class4-del",
    "arguments": {
        "client-classes": [
            {
                "name": "foo"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags نمی‌تواند برای این دستور استفاده شود، زیرا کلاس‌های کلاینت به صورت یکتا با نام شناسایی می‌شوند..SS دستورهای remote-class4-get و remote-class6-get

این دستورها اطلاعات کلاس کلاینت DHCPv4 یا DHCPv6 را بر اساس نام کلاس کلاینت بازیابی می‌کنند.

{
    "command": "remote-class4-get",
    "arguments": {
        "client-classes": [
            {
                "name": "foo"
            }
        ],
        "remote": {
            "type": "mysql"
        }
    }
}

پارامتر server-tags نمی‌تواند برای این دستور استفاده شود، زیرا کلاس‌های کلاینت به صورت یکتا با نام شناسایی می‌شوند.

پاسخ این دستور شبیه به این است:

{
    "result": 0,
    "text": "DHCPv4 client class 'foo' found.",
    "arguments": {
        "client-classes": [
            {
                "name": "foo",
                "metadata": {
                    "server-tags": [ "all" ]
                }
            }
        ],
        "count": 1
    }
}

این دستورها تمام کلاس‌های کلاینت DHCPv4 یا DHCPv6 را برای یک سرور خاص، چندین سرور مشخص‌شده به طور صریح، و/یا همهٔ سرورها بازیابی می‌کنند. هر سرور معین، برچسب سرور اختصاصی خود را دارد و همچنین برچسب سرور "all" را داراست؛ این دستورها کلاس‌ها را هم برای یک سرور مستقل و هم برای سرورهای "all" بازیابی می‌کنند. برای مثال، دستور زیر تمام کلاس‌های کلاینت تعریف‌شده برای "server1" و همچنین کلاس‌های کلاینت تعریف‌شده برای سرورهای "all" را بازیابی می‌کند:

{
    "command": "remote-class4-get-all",
    "arguments": {
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "server1" ]
    }
}

پارامتر server-tags اجباری است و شامل یک یا چند برچسب سرور می‌باشد. اگر برچسب‌های سرور دیگری مشخص شوند، نیازی به قرار دادن "all" در server-tags نیست، زیرا هر سرور به طور خودکار برچسب سرور "all" را نیز دارد. اگر server-tags تنها شامل کلیدواژهٔ "all" باشد، فقط کلاس‌های کلاینت مرتبط با سرورهای "all" بازگردانده می‌شوند. هنگامی که فهرست server-tags شامل مقدار null باشد، پاسخ بازگردانده‌شده حاوی فهرستی از کلاس‌های کلاینت تخصیص‌نیافته خواهد بود، یعنی شبکه‌هایی که با هیچ سروری مرتبط نیستند.

پاسخ این دستور شبیه به این است:

{
    "result": 0,
    "text": "2 DHCPv4 client class(es) found.",
    "arguments": {
        "client-classes": [
            {
                "name": "foo",
                "metadata": {
                    "server-tags": [ "all" ]
                }
            },
            {
                "name": "bar",
                "test": "member('foo')",
                "metadata": {
                    "server-tags": [ "all" ]
                }
            }
        ],
        "count": 2
    }
}

این دستورها یک کلاس کلاینت جدید DHCPv4 یا DHCPv6 را در پایگاه داده درج کرده یا یک کلاس موجود را جایگزین می‌کنند. ساختار اطلاعات کلاس کلاینت همانند فایل پیکربندی Kea است (برای جزئیات به Client Classification in DHCPv4 <#dhcp4-client-classifier> و Client Classification in DHCPv6 <#dhcp6-client-classifier> مراجعه کنید).

{
    "command": "remote-class4-set",
    "arguments": {
        "client-classes": [
            {
                "name": "foo",
                "test": "member('KNOWN') or member('bar')",
                "option-def": [
                    {
                        "name": "configfile",
                        "code": 224,
                        "type": "string"
                    }
                ],
                "option-data": [
                    {
                        "name": "configfile",
                        "data": "1APC"
                    }
                ]
            }
        ],
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

قوانین ترتیب کلاس‌های کلاینت که در Using Expressions in Classification <#classification-using-expressions> شرح داده شده‌اند، برای کلاس‌های درج‌شده در پایگاه داده نیز اعمال می‌شوند. این قوانین ایجاب می‌کنند کلاسی مانند bar که در عبارت ارزیابی (test) به آن ارجاع داده شده است، هنگام اجرای دستور بالا باید در پایگاه داده موجود باشد.

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

با این حال، دستورهای کلاس امکان مشخص کردن موقعیت کلاس کلاینتِ درج‌شده یا به‌روزرسانی‌شده را فراهم می‌سازند. پارامتر اختیاری follow-class-name می‌تواند در دستور گنجانده شود تا نام کلاس موجودی را نشان دهد که کلاس مدیریت‌شده باید بعد از آن قرار گیرد. فرض کنید دو کلاس DHCPv6 در پایگاه داده وجود دارد: first-class و second-class. برای افزودن یک کلاس جدید، third-class، در بین این دو، از دستوری شبیه به این استفاده کنید:

{
    "command": "remote-class6-set",
    "arguments": {
        "client-classes": [
            {
                "name": "third-class",
                "test": "member('first-class')"
            }
        ],
        "follow-class-name": "first-class",
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

توجه داشته باشید که third-class می‌تواند به first-class وابسته باشد زیرا پس از first-class قرار گرفته است؛ اما third-class نمی‌تواند به second-class وابسته باشد زیرا قبل از آن قرار دارد. با این حال، می‌توان second-class را به‌روزرسانی کرد تا به third-class وابسته شود.

پارامتر follow-class-name می‌تواند به صراحت روی null تنظیم شود، مانند:

{
    "command": "remote-class6-set",
    "arguments": {
        "client-classes": [
            {
                "name": "third-class",
                "test": "member('first-class')"
            }
        ],
        "follow-class-name": null,
        "remote": {
            "type": "mysql"
        },
        "server-tags": [ "all" ]
    }
}

این رفتار مشابه زمانی است که پارامتر follow-class-name اصلاً گنجانده نشود؛ یعنی کلاس جدید به انتهای سلسله‌مراتب کلاس‌ها افزوده می‌شود و کلاس به‌روزرسانی‌شده در موقعیت فعلی خود باقی می‌ماند..SS libdhcp_class_cmds.so: دستورات کلاس (Class Commands)

این کتابخانهٔ قلاب (hook library) چندین دستور کنترلی را برای دستکاری کلاس‌های کلاینت (بخشی از پیکربندی سرورهای Kea DHCP) بدون نیاز به راه‌اندازی مجدد این سرورها فراهم می‌کند. با استفاده از این دستورات، افزودن، به‌روزرسانی، حذف و فهرست‌کردن کلاس‌های کلاینت پیکربندی‌شده برای یک سرور معین امکان‌پذیر است.

نکته:

libdhcp_class_cmds.so بخشی از کد متن‌باز است و برای همهٔ کاربران Kea در دسترس است. این کتابخانه پیش‌تر فقط برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود.

نکته:

این کتابخانه تنها توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> قابل بارگذاری است.

دستور class-add یک کلاس کلاینت جدید را به پیکربندی سرور DHCP اضافه می‌کند. این کلاس به انتهای فهرست کلاس‌های مورد استفادهٔ سرور پیوست می‌شود و می‌تواند به هر یک از کلاس‌های کلاینتی که قبلاً پیکربندی شده‌اند وابسته باشد.

مثال زیر نحوهٔ افزودن یک کلاس کلاینت جدید را به پیکربندی سرور DHCPv4 نشان می‌دهد:

{
    "command": "class-add",
    "arguments": {
        "client-classes": [
            {
                "name": "ipxe_efi_x64",
                "test": "option[93].hex == 0x0009",
                "next-server": "192.0.2.254",
                "server-hostname": "hal9000",
                "boot-file-name": "/dev/null"
            }
        ]
    }
}

توجه داشته باشید که پارامتر client-classes یک فهرست JSON است، اما تنها اجازه می‌دهد یک کلاس کلاینت در آن قرار گیرد.

در اینجا پاسخ به دستور class-add در مثال ما آمده است:

{
    "result": 0,
    "text": "Class 'ipxe_efi_x64' added."
}

دستور class-update یک کلاس کلاینت موجود را در پیکربندی سرور DHCP به‌روزرسانی می‌کند. اگر کلاس کلاینت با نام ارائه‌شده وجود نداشته باشد، سرور کد نتیجهٔ 3 را برمی‌گرداند؛ به این معنی که پیکربندی سرور تغییری نکرده و کلاس کلاینت وجود ندارد. در این صورت باید از دستور class-add برای ایجاد کلاس کلاینت جدید استفاده شود.

دستور class-update همان ساختار آرگومان دستور class-add را دارد:

{
    "command": "class-update",
    "arguments": {
        "client-classes": [
            {
                "name": "ipxe_efi_x64",
                "test": "option[93].hex == 0x0017",
                "next-server": "0.0.0.0",
                "server-hostname": "xfce",
                "boot-file-name": "/dev/null"
            }
        ]
    }
}

در اینجا پاسخ برای مثال ما آمده است:

{
    "result": 0,
    "text": "Class 'ipxe_efi_x64' updated."
}

هر پارامتری از کلاس کلاینت را می‌توان با این دستور تغییر داد، به جز name. در حال حاضر روشی برای تغییر نام کلاس وجود ندارد، زیرا نام کلاس به‌عنوان کلید جستجوی کلاسی که باید به‌روزرسانی شود استفاده می‌شود. برای دستیابی به اثری مشابه تغییر نام کلاس، می‌توان یک کلاس موجود را با دستور class-del حذف کرد و سپس با استفاده از class-add مجدداً آن را با نام متفاوتی اضافه نمود. با این حال توجه داشته باشید که کلاس با نام جدید به انتهای فهرست کلاس‌های پیکربندی‌شده اضافه خواهد شد.

همانند دیگر دستورات به‌روزرسانی، این دستور تمام محتویات یک مدخل را رونویسی (overwrite) می‌کند. اگر کلاس کلاینت قبلاً منبعی به آن اختصاص یافته بود و در دستور class-update آن منبع ذکر نشده باشد، از پیکربندی سرور حذف می‌شود. اگر به‌روزرسانی افزایشی کلاس مد نظر باشد، می‌توان با اجرای یک class-get برای دریافت وضعیت فعلی کلاس کلاینت، انتخاب کلاس کلاینت از پاسخ، اصلاح آن به نتیجهٔ دلخواه و سپس صدور دستور client-update همراه با کلاس کلاینت حاصل به این هدف دست یافت..SS دستور class-del

دستور class-del برای حذف یک کلاس خاص از پیکربندی کارگزار استفاده می‌شود. کلاسی که باید حذف شود بر اساس نام شناسایی می‌شود. اگر کلاس‌های دیگری به آن وابسته باشند، کلاس حذف نمی‌شود؛ برای حذف چنین کلاسی، باید ابتدا کلاس‌های وابسته حذف شوند.

نمونه دستور زیر برای حذف کلاس ipxe_efi_x64 آورده شده است:

{
    "command": "class-del",
    "arguments": {
        "name": "ipxe_efi_x64"
    }
}

در اینجا پاسخ به دستور class-del در مثال ما، هنگامی که کلاس کلاینت مشخص‌شده پیدا شده است، مشاهده می‌شود:

{
    "result": 0,
    "text": "Class 'ipxe_efi_x64' deleted."
}

اگر کلاس وجود نداشته باشد، نتیجه‌ی ۳ بازگردانده می‌شود.

دستور class-list برای دریافت فهرستی از تمام کلاس‌های کلاینت به کار می‌رود. این دستور هیچ آرگومانی ندارد:

{
    "command": "class-list"
}

در اینجا پاسخ کارگزار در این مثال، شامل فهرست کلاس‌های کلاینت، آورده شده است:

{
    "result": 0,
    "text": "2 classes found",
    "arguments": {
        "client-classes": [
            {
                "name": "ipxe_efi_x64"
            },
            {
                "name": "pxeclient"
            }
        ]
    }
}

توجه داشته باشید که فهرست بازگردانده‌شده شامل تعاریف کامل کلاس نیست، بلکه صرفاً نام کلاس‌ها را دربردارد. برای دریافت اطلاعات کامل کلاس، باید از دستور class-get استفاده شود.

دستور class-get برای بازیابی اطلاعات دقیق درباره یک کلاس مشخص استفاده می‌شود. ساختار این دستور بسیار ساده است:

{
    "command": "class-get",
    "arguments": {
        "name": "pxeclient"
    }
}

اگر کلاسی با نام مشخص‌شده وجود نداشته باشد، کد وضعیت ۳ بازگردانده می‌شود. اگر کلاس کلاینت مشخص‌شده وجود داشته باشد، جزئیات کلاس در قالب زیر بازگردانده می‌شود:

{
    "result": 0,
    "text": "Class 'pxeclient' definition returned",
    "arguments": {
        "client-classes": [
            {
                "name": "pxeclient",
                "only-in-additional-list": true,
                "test": "option[vendor-class-identifier].text == 'PXEClient'",
                "option-def": [
                    {
                        "name": "configfile",
                        "code": 209,
                        "type": "string"
                    }
                ],
                "option-data": [ ],
                "next-server": "0.0.0.0",
                "server-hostname": "xfce",
                "boot-file-name": "/dev/null"
            }
        ]
    }
}

توجه داشته باشید که مثال بالا مختص DHCPv4 است؛ سه پارامتر پایانی تنها توسط کارگزار DHCPv4 بازگردانده می‌شوند و هرگز توسط کارگزار DHCPv6 بازگردانده نخواهند شد. همچنین، ممکن است برخی از پارامترهای ارائه‌شده در این مثال در صورتی که برای کلاس تعیین نشده باشند، بازگردانده نشوند. به‌طور مشخص، در صورتی که only-in-additional-list، test و option-def برای کلاس مشخص نشده باشند، بازگردانده نمی‌شوند.

نکته:

از نگارش 2.7.4 نرم‌افزار Kea، پارامتر only-if-required با only-in-additional-list جایگزین شده و منسوخ گردیده است. برای اینکه به کاربران فرصت مهاجرت داده شود، دستورهای کلاس همچنان آن را به عنوان ورودی می‌پذیرند اما در خروجی به only-in-additional-list تبدیل می‌کنند. در نهایت، پشتیبانی از این نام قدیمی حذف خواهد شد.

این کتابخانه قلاب (hook library) پشتیبانی از تنظیم دقیق جنبه‌های گوناگون به‌روزرسانی‌های DNS را اضافه می‌کند. این کتابخانه در حال حاضر از تولید رویه‌ای نام میزبان و امکان چشم‌پوشی از انجام به‌روزرسانی‌های DDNS برای کلاینت‌های مشخص پشتیبانی می‌کند.

نکته:

کتابخانه libdhcp_ddns_tuning.so بخشی از کد متن‌باز است و برای تمام کاربران Kea در دسترس می‌باشد. این کتابخانه پیش‌تر تنها در اختیار مشتریان ISC با قرارداد پشتیبانی تجاری قرار داشت.

این کتابخانه، که در Kea 2.1.5 افزوده شد، می‌تواند توسط دیمن‌های kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> با اضافه کردن آن به عنصر hooks-libraries در پیکربندی سرور بارگذاری شود:

{
    "hooks-libraries": [
        {
            "library": "libdhcp_ddns_tuning.so",
            "parameters": {
                ...
            }
        },
        ...
    ],
    ...
}

این کتابخانه قلاب امکان تولید رویه‌ای نام‌های میزبان را بر اساس یک عبارت فراهم می‌سازد. این عبارت را می‌توان به‌صورت سراسری در پارامترهای قلاب با استفاده از hostname-expr تعریف کرد. در صورت تعریف سراسری، این عبارت برای تمامی میزبان‌ها در تمامی زیرشبکه‌ها اعمال می‌شود. عبارت‌ها می‌توانند از تمام نشانه‌های (tokens) تعریف‌شده در Client Classification <#classify> استفاده کنند. نمونه‌ای از یک عبارت سراسری در زیر نشان داده شده است:

{
    "hooks-libraries": [
        {
            "library": "libdhcp_ddns_tuning.so",
            "parameters": {
                "hostname-expr": "'host-'+hexstring(pkt4.mac,'-')",
                ...
            }
        },
        ...
    ],
    ...
}

رفتار پیش‌فرض kea-dhcp4 <#std-iscman-kea-dhcp4> این است که در صورت ارسال هر دو گزینه توسط یک کلاینت، گزینه FQDN (کد 81) را بر گزینه نام میزبان (کد 12) ترجیح دهد. مثال زیر hostname-expr مورد نیاز برای معکوس کردن این قاعده را نشان می‌دهد:

{
    "hooks-libraries": [
        {
            "library": "libdhcp_ddns_tuning.so",
            "parameters": {
                "hostname-expr" : "ifelse(option[12].exists, option[host-name].text, option[81].text)"
            }
        }
    ]
}

همچنین می‌توان این پارامتر را در یک زیرشبکه با استفاده از سازوکار user-context تعریف کرد. در صورت تعریف در سطح زیرشبکه، عبارت تنها برای آن زیرشبکه خاص اعمال خواهد شد. اگر عبارت زیرشبکه به‌صورت تهی، ""، تعریف شود، استفاده از عبارت سراسری را برای آن زیرشبکه لغو (یا غیرفعال) می‌کند. نمونه‌ای از یک عبارت در سطح زیرشبکه در زیر آورده شده است:

{
 "subnet4": [{
     "subnet": "192.0.2.0/24",
     "pools": [{
         "pool": "192.0.2.10 - 192.0.2.20"
     } ],
     "user-context": {
         "ddns-tuning": {
             "hostname-expr": "'guest-'+int8totext(substring(pkt4.yiaddr, 0,1))+'-' \
                                       +int8totext(substring(pkt4.yiaddr, 1,2))+'-' \
                                       +int8totext(substring(pkt4.yiaddr, 2,3))+'-' \
                                       +int8totext(substring(pkt4.yiaddr, 3,4))"
         }
     }
 }],
 ...
}

نکته:

مقدار عبارت بالا از یک بک‌اسلش، \، برای نمایش ادامه خط استفاده کرده است. این کار صرفاً برای خوانایی بهتر است و یک ساختار معتبر JSON که توسط تجزیه‌گر Kea پشتیبانی شود نیست. مقدار واقعی باید در یک خط ممتد نوشته شود.

نکته:

هنگام تولید نام میزبان باید به مسائل مربوط به حریم خصوصی توجه کرد. نام میزبان معمولاً در سامانه عمومی DNS درج می‌شود. افشای شناسه‌هایی که می‌توان از آن‌ها برای ردیابی دستگاه‌ها استفاده کرد، مانند آدرس MAC، معمولاً ایده بسیار نامناسبی است. در مثال عبارت سراسری فوق، صرفاً جهت سادگی از آدرس MAC استفاده شده است.

با نصب این کتابخانه، رفتار kea-dhcp4 <#std-iscman-kea-dhcp4> هنگام ساخت نام‌های میزبان در پاسخ به پرس‌وجوی کلاینت (مانند DISCOVER یا REQUEST) به شرح زیر است:

1. اگر نام میزبان از طریق یک رزرو میزبان (host reservation) ارائه شده باشد، از آن به همراه پارامترهای رفتاری DDNS برای ساخت نام میزبان نهایی استفاده کنید. به مرحله 4 بروید.

2. اگر کلاینت گزینهٔ FQDN (گزینهٔ 81) را ارائه داده باشد، از مقدار نام دامنهٔ مشخص‌شده در آن، به همراه پارامترهای رفتاری DDNS، برای ساخت نام میزبان نهایی استفاده کنید. به مرحله 4 بروید.

3. اگر کلاینت گزینهٔ host-name (گزینهٔ 12) را ارائه داده باشد، از نام میزبان مشخص‌شده در آن، به همراه پارامترهای رفتاری DDNS، برای ساخت نام میزبان نهایی استفاده کنید.

4. اگر یک عبارت host-name مربوط به ddns-tuning در حوزهٔ کاری معتبر (چه سراسری یا زیرشبکه) وجود داشته باشد، نام میزبان را با استفاده از آن عبارت محاسبه کنید. اگر مقدار محاسبه‌شده یک نام کاملاً واجد شرایط (FQDN) نباشد و یک ddns-qualifying-suffix در حوزهٔ کاری معتبر وجود داشته باشد، پسوند را به آن الحاق کنید.

5. اگر مقدار محاسبه‌شده توسط hook یک رشتهٔ خالی نباشد و با نام میزبان ساخته‌شده در مراحل 1 یا 2 تفاوت داشته باشد، مقدار محاسبه‌شده تبدیل به نام میزبان نهایی می‌شود.

با نصب این کتابخانه، رفتار kea-dhcp6 <#std-iscman-kea-dhcp6> هنگام ساخت نام‌های میزبان در پاسخ به پرس‌وجوی کلاینت (مانند SOLICIT، REQUEST، RENEW یا REBIND) به شرح زیر است:

1. اگر کلاینت گزینهٔ FQDN (گزینهٔ 39) را ارائه داده باشد، از مقدار نام دامنهٔ مشخص‌شده در آن، به همراه پارامترهای رفتاری DDNS، برای ساخت نام میزبان نهایی استفاده کنید. به مرحله 4 بروید.

2. اگر کلاینت FQDN ارائه نداده باشد اما ddns-replace-client-name برابر با always یا when-not-present باشد، شکل نهایی نام میزبان را محاسبه کرده و از آن برای ایجاد یک FQDN خروجی استفاده کنید. به مرحله 4 بروید.

3. اگر در این نقطه هیچ FQDN خروجی‌ای وجود نداشته باشد، پردازش client-name برای این بسته متوقف می‌شود. بدون یک FQDN خروجی، هیچ راهی برای انتقال نام میزبان به کلاینت وجود ندارد.

4. اگر نام میزبان از طریق یک host reservation ارائه شده باشد، از آن به همراه پارامترهای رفتاری DDNS برای ساخت نام میزبان نهایی استفاده کنید؛ این مقدار جایگزین مقدار FQDN محاسبه‌شده در مراحل 1 یا 2 می‌شود.

5. اگر یک عبارت host name مربوط به ddns-tuning در حوزهٔ کاری معتبر (چه سراسری یا زیرشبکه) وجود داشته باشد، نام میزبان را با استفاده از آن عبارت محاسبه کنید. اگر مقدار محاسبه‌شده یک نام کاملاً واجد شرایط (FQDN) نباشد و یک ddns-qualifying-suffix در حوزهٔ کاری معتبر وجود داشته باشد، پسوند را به آن الحاق کنید.

6. اگر مقدار محاسبه‌شده توسط hook یک رشتهٔ خالی نباشد و با نام میزبان ساخته‌شده در مراحل 1 یا 2 تفاوت داشته باشد، مقدار محاسبه‌شده تبدیل به نام میزبان نهایی می‌شود.

libdhcp_ddns_tuning.so همچنین امکان نادیده‌گرفتن به‌روزرسانی‌های DDNS را به‌ازای هر کلاینت فراهم می‌کند. این کتابخانه یک کلاس کلاینت ویژه به نام "SKIP_DDNS" را شناسایی می‌کند؛ هنگامی که یک کلاینت با این کلاس مطابقت داده شود، سرورهای Kea (kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6>) درخواست‌های به‌روزرسانی DDNS (یا NCRها) را به kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> ارسال نمی‌کنند. یک مورد کاربرد رایج، نادیده‌گرفتن به‌روزرسانی‌های DDNS برای رزروهای میزبان با آدرس ثابت است. این کار به سادگی و تنها با انتساب این کلاس به host reservation، همان‌طور که در زیر نشان داده شده است، انجام می‌شود:

{
    "reservations": [
    {
        "hw-address": "01:02:03:04:05:06",
        "ip-address": "192.0.2.1",
        "client-classes": [ "SKIP_DDNS", "foo", "bar" ]
    }]
}

کتابخانهٔ هوک libdhcp_ddns_tuning.so با هر بار درخواست، تمدید یا آزادسازی اجاره (lease) توسط کلاینت، وجود کلاس "SKIP_DDNS" را در فهرست کلاس‌های کلاینت بررسی کرده و به kea-dhcp4 <#std-iscman-kea-dhcp4> دستور می‌دهد از ارسال به‌روزرسانی‌های DDNS صرف‌نظر کند. روند کاری مشابهی برای kea-dhcp6 <#std-iscman-kea-dhcp6> نیز پشتیبانی می‌شود:

{
    "reservations": [
    {
        "duid": "01:02:03:04:05:06",
        "ip-address": "2001:db8::1",
        "client-classes": [ "SKIP_DDNS", "foo", "bar" ]
    }]
}

اگرچه "SKIP_DDNS" یک کلاس ویژه است، اما می‌توان آن را با یک عبارت آزمایشی (test expression) تعریف کرد. تعریف آن به صورت زیر، به‌روزرسانی‌های DDNS را برای تمام کلاینت‌های KNOWN نادیده می‌گیرد:

{
    "client-classes":[
    {
        "name": "SKIP_DDNS",
        "test": "member('KNOWN')"
    }]
}

نکته:

برای اینکه کلاس "SKIP_DDNS" اثرگذار باشد، کتابخانهٔ هوک libdhcp_ddns_tuning.so باید بارگذاری شده باشد.

نرم‌افزار Kea روشی برای مدیریت رزروهای میزبان فراهم می‌کند که شامل نشانی‌ها، پیشوندها، گزینه‌ها، کلاس‌های کلاینت و سایر قابلیت‌ها می‌شود. رزرو در DHCPv4 می‌تواند بر اساس نشانی سخت‌افزاری، DUID، circuit-id، یا client-id باشد، و در DHCPv6 بر اساس نشانی سخت‌افزاری یا DUID. با این حال، گاهی سناریوهایی وجود دارند که در آن‌ها رزرو پیچیده‌تر است؛ ممکن است از گزینه‌هایی غیر از موارد یادشده در بالا استفاده شود، بخش‌هایی از گزینه‌هایی خاص به کار رود، یا شاید حتی ترکیبی از چندین گزینه و فیلد برای شناسایی منحصربه‌فرد یک کلاینت استفاده شود. این سناریوها توسط برنامه قلاب (hook application) شناسه انعطاف‌پذیر (Flexible Identifiers) پوشش داده می‌شوند.

نکته:

libdhcp_flex_id.so بخشی از کد منبع‌باز است و در دسترس تمام کاربران Kea قرار دارد. این کتابخانه پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود.

نکته:

این کتابخانه تنها می‌تواند توسط فرآیند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

libdhcp_flex_id.so امکان تعریف یک عبارت (expression) را با استفاده از شیوه‌نگارشی که در ابتدا تنها برای دسته‌بندی کلاینت به کار می‌رفت فراهم می‌کند. (برای شرح مفصل ساختار نحوی موجود، Using Expressions in Classification <#classification-using-expressions> را ببینید.) یک تفاوت چشمگیر این است که برای دسته‌بندی کلاینت، عبارت در حال حاضر باید به true یا false ارزیابی شود، در حالی که انتظار می‌رود عبارت شناسه انعطاف‌پذیر به رشته‌ای ارزیابی گردد که به عنوان یک شناسه استفاده خواهد شد. این که عبارت به یک رشته خالی ارزیابی شود حالتی معتبر است (برای نمونه در مواردی که کلاینت گزینه‌های خاصی را ارسال نمی‌کند). سپس این عبارت برای هر بسته دریافتی ارزیابی شده و این ارزیابی شناسه‌ای تولید می‌کند که برای شناسایی کلاینت استفاده می‌شود. به‌ویژه، ممکن است رزروهای میزبانی وجود داشته باشند که به مقادیر خاصی از شناسه انعطاف‌پذیر گره خورده باشند.

این کتابخانه می‌تواند مشابه سایر کتابخانه‌های hook بارگذاری شود. این کتابخانه از پارامترهای زیر پشتیبانی می‌کند: identifier-expression، replace-client-id و ignore-iaid:

"Dhcp6": {
    "hooks-libraries": [
        {
            "library": "libdhcp_flex_id.so",
            "parameters": {
                "identifier-expression": "expression",
                "replace-client-id": false,
                "ignore-iaid": false
            }
        },
        ...
    ]
}

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

بیایید موردی از یک شبکه IPv6 را در نظر بگیریم که برای هر یک از مشتریان متصل خود دارای یک رابط مستقل است. مشتریان می‌توانند هر دستگاهی را که می‌خواهند متصل کنند، بنابراین هر نوع شناسه‌ای (مانند یک client-id) غیرقابل اتکا است. از این رو، مدیر شبکه ممکن است تصمیم بگیرد از گزینه‌ای که توسط یک relay agent درج شده برای تمایز بین کلاینت‌ها استفاده کند. در این استقرار خاص، مدیر شبکه تأیید کرده است که interface-id برای هر رابطِ سمت مشتری منحصربه‌فرد است، بنابراین برای استفاده به عنوان رزرو مناسب است. با این حال، تنها شش بایت نخست interface-id مد نظر است، زیرا بایت‌های باقی‌مانده یا به صورت تصادفی تغییر می‌کنند یا بین دستگاه‌ها یکتا نیستند. بنابراین، کاربر تصمیم می‌گیرد از شش بایت نخست گزینه interface-id درج‌شده توسط relay agent استفاده کند. پس از افزودن flex-id، هدف host-reservation-identifiers می‌تواند با استفاده از پیکربندی زیر حاصل شود:

"Dhcp6": {
    "subnet6": [{
    # subnet definition starts here
    "reservations": [{
        "flex-id": "'port1234'",
        # value of the first 8 bytes of the interface-id
        "ip-addresses": [ "2001:db8::1" ]
    },
    ...
    ],
    ...
    },
    ...
    ],
    # end of subnet definitions
    "host-reservation-identifiers": ["duid", "flex-id"],
    # add "flex-id" to reservation identifiers
    "hooks-libraries": [
        {
            "library": "libdhcp_flex_id.so",
            "parameters": {
                "identifier-expression": "substring(relay6[0].option[18].hex,0,8)"
            }
        },
        ...
    ],
    ...
}

نکته:

هنگام تنظیم عبارت باید دقت شود. اگر عبارت تغییر کند، ممکن است تمام مقادیر flex-id تغییر کنند و احتمالاً تمام رزروهای مبتنی بر flex-id تا زمانی که به صورت دستی به‌روزرسانی شوند غیرقابل استفاده گردند. اکیداً به مدیران سیستم توصیه می‌شود که کار را با عبارت و تعداد اندکی از رزروها شروع کرده و سپس در صورت نیاز عبارت را تنظیم کنند. به محض اینکه نتیجه مطلوب با عبارت حاصل شد، رزروهای میزبان می‌توانند در مقیاس وسیع‌تری مستقر شوند.

مقادیر flex-id در رزروهای میزبان را می‌توان به دو شیوه مشخص کرد. نخست، می‌توانند به عنوان یک رشته هگز (hex string) بیان شوند؛ برای نمونه رشته "bar" می‌تواند به صورت 626174 نمایش داده شود. در غیر این صورت، می‌تواند به عنوان یک مقدار درون نقل‌قول (با استفاده از نقل‌قول‌های دوتایی و تکی) بیان شود، مانند "'bar'". حالت نخست برای نویسه‌های قابل چاپ مناسب‌تر است، در حالی که مقادیر رشته هگز برای نویسه‌های غیرقابل چاپ راحت‌تر بوده و نیازی به استفاده از عملگر hexstring ندارند.

"Dhcp6": {
    "subnet6": [{
    # subnet definition starts here
    "reservations": [{
        "flex-id": "01:02:03:04:05:06",
        # value of the first 8 bytes of the interface-id
        "ip-addresses": [ "2001:db8::1" ]
    },
    ...
    ],
    ...
    },
    ...
    ],
    # end of subnet definitions
    "host-reservation-identifiers": ["duid", "flex-id"],
    # add "flex-id" to reservation identifiers
    "hooks-libraries": [
        {
            "library": "libdhcp_flex_id.so",
            "parameters": {
                "identifier-expression": "vendor[4491].option[1026].hex"
            }
        },
        ...
    ],
    ...
}

نکته:

یک سناریوی کمتر رایج که مثال‌های بالا ممکن است در آن سودمند واقع شوند، برای کلاینت‌های DHCPv6 است که DUID خود را بین تبادل‌ها تغییر می‌دهند. شناخته شده است که کلاینت‌های PXE خاصی بدین شیوه رفتار می‌کنند.

هنگامی که replace-client-id روی false تنظیم شده باشد (که تنظیم پیش‌فرض است)، libdhcp_flex_id.so از شناسهٔ منعطف ارزیابی‌شده صرفاً برای شناسایی رزروهای میزبان، یعنی جستجو برای رزروها در یک پایگاه داده، استفاده می‌کند. این معادل عملکردی سایر شناسه‌ها، مشابه با آدرس سخت‌افزاری یا circuit-id است. با این حال، این حالت عملکردی به این معنی است که اگر یک دستگاه کلاینت تعویض شود، ممکن است باعث ایجاد تداخل میان یک اجارهٔ موجود (تخصیص‌یافته به دستگاه قدیمی) و اجارهٔ جدید در حال تخصیص به دستگاه جدید شود. این تداخل به این دلیل رخ می‌دهد که شناسهٔ منعطف یکسانی برای دستگاه جایگزین‌شده محاسبه می‌شود، بنابراین کارساز تلاش خواهد کرد همان اجاره را تخصیص دهد. عدم تطابق میان شناسه‌های کلاینت ارسال‌شده توسط دستگاه جدید و دستگاه قدیمی باعث می‌شود که کارساز از این تخصیص جدید تا زمان منقضی شدن اجارهٔ قبلی امتناع ورزد. بروز این مشکل به عبارت خاصی که به عنوان شناسهٔ منعطف استفاده می‌شود وابسته است و در صورتی که فقط از گزینه‌ها و سایر پارامترهایی استفاده شود که محل اتصال دستگاه را مشخص می‌کنند (مانند circuit-id)، به جای شناسایی خود دستگاه (مانند آدرس MAC)، احتمال رخ دادن آن بیشتر است.

کتابخانهٔ libdhcp_flex_id.so روشی برای غلبه بر مشکل تداخل‌های اجاره از طریق جایگزینی پویای شناسهٔ کلاینت (یا DUID در DHCPv6) با مقداری مشتق‌شده از شناسهٔ منعطف ارائه می‌دهد. کارساز پرس‌وجوی کلاینت را به گونه‌ای پردازش می‌کند که گویی شناسهٔ منعطف در گزینهٔ شناسهٔ کلاینت (یا DUID) ارسال شده است. این امر تضمین می‌کند که به کلاینت بازگشتی (که همان شناسهٔ منعطف برای آن ارزیابی می‌شود)، علیرغم تغییر شناسهٔ کلاینت و/یا آدرس MAC، همان اجاره اختصاص داده شود.

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

"Dhcp4": {
    "hooks-libraries": [
        {
            "library": "libdhcp_flex_id.so",
            "parameters": {
                "identifier-expression": "expression",
                "replace-client-id": true
            }
        },
        ...
    ]
}

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

توجه داشته باشید که برای اعمال این سازوکار، کارساز DHCPv4 باید طوری پیکربندی شود که مقدار گزینهٔ شناسهٔ کلاینت را در طول تخصیص اجاره رعایت کند، یعنی match-client-id باید روی true تنظیم شده باشد. برای جزئیات به Using Client Identifier and Hardware Address <#dhcp4-match-client-id> مراجعه کنید. هیچ تنظیم اضافی برای DHCPv6 لازم نیست.

اگر گزینهٔ replace-client-id روی true تنظیم شود، مقدار پارامتر echo-client-id (که ارسال مجدد گزینهٔ client-id را کنترل می‌کند) نادیده گرفته می‌شود.

بخش libdhcp_lease_cmds.so: Lease Commands for Easier Lease Management دستورهایی را شرح می‌دهد که برای بازیابی، به‌روزرسانی و حذف اجاره‌ها با استفاده از شناسه‌های گوناگون، مانند hw-address و client-id استفاده می‌شوند. libdhcp_lease_cmds.so به طور بومی از پرس‌وجوی اجاره‌ها بر اساس شناسهٔ منعطف پشتیبانی نمی‌کند. با این حال، هنگامی که replace-client-id روی true تنظیم شده باشد، امکان پرس‌وجوی اجاره‌ها را با استفاده از مقداری مشتق‌شده از شناسهٔ منعطف فراهم می‌سازد. در DHCPv4، پرس‌وجو شبیه به این است:

{
    "command": "lease4-get",
    "arguments": {
        "identifier-type": "client-id",
        "identifier": "00:54:64:45:66",
        "subnet-id": 44
    }
}

که در آن مقدار هگزادسیمال "54:64:45:66" یک شناسهٔ منعطف محاسبه‌شده برای کلاینت است.

در DHCPv6، پرس‌وجوی متناظر چیزی شبیه به این است:

{
    "command": "lease6-get",
    "arguments": {
        "identifier-type": "duid",
        "identifier": "00:00:54:64:45:66",
        "subnet-id": 10
    }
}

هنگامی که ignore-iaid روی true تنظیم شود (مقدار پیش‌فرض false است)، libdhcp_flex_id.so باعث می‌شود کارساز Kea DHCPv6 مقدار IAID را از بسته‌های ورودی IPv6 نادیده بگیرد. این پارامتر توسط کارساز Kea DHCPv4 نادیده گرفته می‌شود.

اگر بسته تنها شامل یک IA_NA باشد، مقدار IAID به 0 تغییر کرده و به همین صورت در مخزن اجاره ذخیره خواهد شد. به طور مشابه، اگر بسته تنها شامل یک IA_PD باشد، مقدار IAID به 0 تغییر یافته و به همین صورت در مخزن اجاره ذخیره می‌شود. IAID در پاسخ بازگشتی به کلاینت به مقدار اولیهٔ خود بازگردانده می‌شود. این تغییر در عبارت شناسه (identifier expression) در صورتی که IAID بخشی از عبارت باشد، قابل مشاهده است.

نکته:

برای جلوگیری از تداخل اجاره‌ها، اگر بستهٔ ورودی شامل بیش از یک IA_NA باشد، مقدار IAID روی هیچ‌یک از IA_NAها تغییر نخواهد کرد. به طور مشابه، اگر بستهٔ ورودی شامل بیش از یک IA_PD باشد، مقدار IAID روی هیچ‌یک از IA_PDها تغییر نمی‌کند.

هشدار:

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

نکته:

پارامتر ignore-iaid مستقل از قابلیت شناسهٔ منعطف عمل می‌کند و می‌توان از آن بدون مشخص کردن مقداری برای identifier-expression استفاده کرد. هنگامی که identifier-expression حذف شود یا به عنوان یک رشتهٔ خالی، ""، مشخص گردد، قابلیت شناسهٔ منعطف غیرفعال می‌شود. نسخه‌های Kea پیش از 3.1.2 نیازمند مقداری برای identifier-expression هستند اما مقدار رشتهٔ خالی را می‌پذیرند. از نسخهٔ Kea 3.1.2 به بعد، این پارامتر اختیاری است.

این کتابخانه به مدیران سیستم اجازه می‌دهد تا بر اساس نتیجه یک عبارت، کنشی را برای یک گزینه مشخص تعریف کنند. این کنش‌ها در مراحل نهایی ساخت بسته پاسخ پرسش (query response)، درست پیش از ارسال آن به کلاینت، اجرا می‌شوند. سه کنشی که در حال حاضر پشتیبانی می‌شوند عبارتند از add، supersede و remove.

نکته:

libdhcp_flex_option.so بخشی از کد متن‌باز است و برای همه کاربران Kea در دسترس است.

سینتکس مورد استفاده برای عبارات کنش، همان سینتکسی است که برای طبقه‌بندی کلاینت (client classification) و کتابخانه قلاب (hook) شناسه منعطف (Flexible Identifier) استفاده می‌شود؛ برای شرح دقیق سینتکس، بخش Using Expressions in Classification <#classification-using-expressions> یا libdhcp_flex_id.so: Flexible Identifier for Host Reservations را ببینید.

کنش‌های add و supersede از عبارتی استفاده می‌کنند که یک رشته برمی‌گرداند، و در صورتی که رشته خالی باشد کاری انجام نمی‌دهند. کاربرد remove از عبارتی استفاده می‌کند که مقدار true یا false برمی‌گرداند، و در صورت false بودن کاری انجام نمی‌دهد. هنگامی که لازم باشد یک گزینه روی مقدار خالی تنظیم شود، این سازوکار کارایی ندارد، اما در عوض می‌توان از یک کلاس کلاینت (client class) استفاده کرد.

کنش add تنها زمانی یک گزینه را اضافه می‌کند که آن گزینه از قبل وجود نداشته باشد و عبارت به رشته خالی ارزیابی نشود. کنش supersede مشابه است، اما در صورتی که گزینه از قبل وجود داشته باشد، مقدار آن را بازنویسی می‌کند. کنش remove در صورتی که گزینه از قبل وجود داشته باشد و عبارت به true ارزیابی شود، آن گزینه را از بسته پاسخ حذف می‌کند.

گزینه‌ای که کنش بر آن اعمال می‌شود را می‌توان از طریق کد عددی یا نام آن مشخص کرد؛ مشخص کردن کد یا نام الزامی است. فضای گزینه (option space) بسته به سروری که کتابخانه هوک در آن بارگذاری شده است، DHCPv4 یا DHCPv6 خواهد بود.

libdhcp_flex_option.so می‌تواند توسط هر یک از فرایندهای kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود. این کتابخانه یک پارامتر اجباری options به همراه فهرستی از نگاشت‌های پارامتری به ازای هر گزینه دریافت می‌کند که شامل کنش‌های code، name، add، supersede و remove است. مدخل‌های کنش یک مقدار رشته‌ای می‌پذیرند که نشان‌دهنده یک عبارت است.

{
   "Dhcp4": {
       "hooks-libraries": [
           {
               "library": "libdhcp_flex_option.so",
               "parameters": {
                   "options": [
                       {
                           "code": 67,
                           "add": "ifelse(option[host-name].exists,concat(option[host-name].text,'.boot'),'')"
                       }
                   ]
               }
           }
       ]
   }
}

اگر (و تنها اگر) بسته query شامل گزینه host-name (کد ۱۲) باشد، گزینه boot-file-name (کد ۶۷) با محتوای نام میزبان به همراه پسوند .boot به پاسخ افزوده می‌شود.

یکی از کاربردهای متداول، تغییر دادن گزینه subnet mask در DHCPv4 (کد ۱) است. مثال زیر این قابلیت را نشان می‌دهد، که در آن به تمامی بسته‌های ورودی شناسایی‌شده با آدرس درگاه 192.168.0.1، با یک ماسک زیرشبکه ۳۲/ در پاسخ پاسخ داده می‌شود:

{
    "Dhcp4": {
        "hooks-libraries": [
            {
                "library": "libdhcp_flex_option.so",
                "parameters": {
                    "options": [
                        {
                            "code": 1,
                            "supersede": "ifelse(pkt4.giaddr==192.168.0.1, '255.255.255.255', '')"
                        }
                    ]
                }
            }
        ]
    }
}

کتابخانه Flexible Option هم از DHCPv4 و هم از DHCPv6 پشتیبانی می‌کند.

کنش‌های add و supersede یک پارامتر بولی اختیاری csv-format دریافت می‌کنند. اگر مشخص نشود یا روی false تنظیم شود، داده‌های گزینه با استفاده از مقدار خام عبارت ارزیابی‌شده تنظیم می‌شوند. هنگامی که روی true پیکربندی شده باشد، این مقدار با استفاده از تعریف گزینه برگرفته از داده‌های گزینه مشخص‌شده در فایل پیکربندی تجزیه می‌شود. این قابلیت تنظیم مقادیر را برای گزینه‌هایی که از ساختارهای رکوردی پیچیده یا نام‌های دامنه کاملاً واجد شرایط (FQDN) استفاده می‌کنند، آسان می‌سازد.

برای نمونه، اگر ارزیابی عبارت مقدار "example.com" را برگرداند و گزینه با نوع fqdn تعریف شده باشد، نام دامنه به قالب باینری DNS کدگذاری می‌شود.

از نسخه 2.1.4 نرم‌افزار Kea به بعد، پارامتر client-class یک محافظ کلاس (class guard) را مشخص می‌کند و نام یک client-class را می‌پذیرد. در صورتی که خالی نباشد، بسته کلاینت برای استفاده از این مدخل باید به کلاس مشخص‌شده تعلق داشته باشد.

همچنین امکان داشتن چندین مدخل برای یک گزینه یکسان وجود دارد، اما هر مدخل باید دقیقاً دارای یک کنش باشد. اگر گزینه در dhcp4 برای DHCPv4 یا در dhcp6 برای DHCPv6 تعریف نشده باشد، محل تعریف گزینه را می‌توان با استفاده از نام آن، از طریق پارامتر جدید space مشخص کرد.

از نسخه 2.1.4 نرم‌افزار Kea به بعد، زیرگزینه‌ها (sub-options) با مدخل جدید sub-options پشتیبانی می‌شوند که جایگزین کنش در پیکربندی گزینه دربرگیرنده (یعنی گزینه‌ای که زیرگزینه‌ها در آن قرار دارند) می‌شود.

پارامتر sub-options فهرستی از مدخل‌های زیرگزینه را دریافت می‌کند که هر یک شامل موارد زیر است:

  • code - کد زیرگزینه را مشخص می‌کند؛ مشخص کردن code یا name الزامی است. اگر هر دو ارائه شوند، باید با یکدیگر مطابقت داشته باشند وگرنه پیکربندی در زمان بارگذاری رد می‌شود.
  • name - نام زیرگزینه را مشخص می‌کند؛ مشخص کردن code یا name الزامی است. اگر هر دو ارائه شوند، باید با یکدیگر مطابقت داشته باشند وگرنه پیکربندی در زمان بارگذاری رد می‌شود.
  • space - فضایی را مشخص می‌کند که زیرگزینه می‌تواند در آن تعریف شود. این پارامتر اختیاری است، زیرا می‌تواند از تعریف گزینه دربرگیرنده استخراج شود. اگر هیچ نام فضای معتبری در زمان بارگذاری موجود نباشد، پیکربندی رد می‌شود. توجه داشته باشید که فضاهای سازنده (vendor spaces) هم برای vivso-suboptions در DHCPv4 و هم برای vendor-opts در DHCPv6، چه از پیش‌تعریف‌شده (مانند شناسه سازنده DoCSIS با کد 4491) و چه سفارشی، پشتیبانی می‌شوند.
  • add - (کنش) زیرگزینه را تنها در صورتی اضافه می‌کند که از قبل وجود نداشته باشد و عبارت به رشته خالی ارزیابی نشود.
  • supersede - (کنش) در صورتی که عبارت به رشته خالی ارزیابی نشود، زیرگزینه را اضافه یا بازنویسی می‌کند.
  • remove - (کنش) در صورتی که زیرگزینه از قبل وجود داشته باشد و عبارت به true ارزیابی شود، آن را حذف می‌کند.
  • container-add - یک مقدار بولی است که مشخص می‌کند آیا در صورت عدم وجود گزینه دربرگیرنده در کنش‌های add و supersede، این گزینه باید ایجاد شود یا خیر. در صورت عدم تعیین، مقدار پیش‌فرض آن true است.
  • container-remove - یک مقدار بولی است که مشخص می‌کند آیا پس از حذف یک زیرگزینه توسط کنش remove، در صورتی که گزینه دربرگیرنده خالی بماند، باید حذف شود یا خیر. در صورت عدم تعیین، مقدار پیش‌فرض آن true است.
  • csv-format - یک مقدار بولی است که مشخص می‌کند آیا مقدار خام عبارت ارزیابی‌شده استفاده شود (false، پیش‌فرض) یا با استفاده از تعریف زیرگزینه تجزیه شود (true).
  • client-class - مشخص می‌کند که آیا در صورت عدم تعلق query به کلاس کلاینت مشخص‌شده، باید از مدخل زیرگزینه صرف‌نظر شود یا خیر. توجه داشته باشید که پارامتر مشابه در مدخل گزینه دربرگیرنده، بر کل فهرست sub-options اعمال می‌شود.

برای نمونه، این پیکربندی یک زیرگزینه رشته‌ای را به گزینه vendor-encapsulated-options در DHCPv4 (کد ۴۳) اضافه می‌کند. این گزینه فضای vendor-encapsulated-options را کپسوله‌سازی می‌کند.

{
   "Dhcp4": {
       "hooks-libraries": [
           {
               "library": "libdhcp_flex_option.so",
               "parameters": {
                   "options": [
                       {
                           "code": 43,
                           "sub-options": [
                               {
                                  "code": 1,
                                  "add": "'foobar'"
                               }
                           ]
                       }
                   ]
               }
           }
       ]
   }
}

این کتابخانهٔ قلاب به سرور kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> اجازه می‌دهد تا از GSS-TSIG برای امضای به‌روزرسانی‌های DNS استفاده کند. برای بحث و بررسی کامل دربارهٔ GSS-TSIG در Kea، لطفاً به GSS-TSIG <#gss-tsig> مراجعه کنید.

نکته:

libddns_gss_tsig.so بخشی از کد متن‌باز است و برای تمامی کاربران Kea در دسترس است. این کتابخانه پیش‌تر تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس بود.

این کتابخانهٔ قلاب می‌تواند بر روی یک جفت سرور DHCPv4 یا DHCPv6 بارگذاری شود تا قابلیت اطمینان سرویس DHCP در صورت وقوع قطعی در یک سرور افزایش یابد.

نکته:

libdhcp_ha.so بخشی از کد متن‌باز است و برای تمامی کاربران Kea در دسترس است. این کتابخانه پیش‌تر تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس بود.

نکته:

این کتابخانه تنها می‌تواند توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

دسترسی‌پذیری بالا (HA) برای سرویس DHCP از طریق اجرای چندین نمونه سرور همکار فراهم می‌شود. اگر هر یک از این نمونه‌ها به هر دلیلی (از کار افتادن نرم‌افزار DHCP، قطعی برق، خرابی سخت‌افزار) از دسترس خارج شود، نمونه سرور بازمانده می‌تواند به ارائهٔ سرویس قابل‌اطمینان به کلاینت‌ها ادامه دهد. بسیاری از پیاده‌سازی‌های سرور DHCP شامل پروتکل "DHCP Failover" هستند که مهم‌ترین ویژگی‌های آن ارتباط میان سرورها، تشخیص خرابی همتا، و همگام‌سازی اجاره‌ها میان سرورها است. با این حال، فرایند استانداردسازی failover برای DHCPv4 هرگز توسط IETF تکمیل نشد. استاندارد failover برای DHCPv6 (RFC 8156) منتشر شد، اما پیچیده و استفاده از آن دشوار است، محدودیت‌های عملیاتی چشمگیری دارد، و با همتای v4 خود متفاوت است. اگرچه استفاده از یک پروتکل failover "استاندارد" ممکن است مفید باشد، بیشتر کاربران Kea صرفاً به دنبال یک راهکار کاربردی هستند که دسترسی‌پذیری بالای سرویس DHCP را تضمین کند. از این رو، کتابخانهٔ قلاب Kea HA مفاهیم اصلی را از پروتکل DHCP failover برگرفته، اما از راهکارهای اختصاصی خود برای ارتباطات و پیکربندی استفاده می‌کند. این کتابخانه ماشین وضعیت اختصاصی خود را ارائه می‌دهد که پیاده‌سازی آن را بسیار ساده‌تر کرده و به‌طور کلی سازگاری بهتری با Kea دارد، و قابلیت‌های یکسانی را در هر دو DHCPv4 و DHCPv6 فراهم می‌آورد. این سند عمداً از اصطلاح "high availability" به جای "failover" استفاده می‌کند تا تأکید کند که این پیاده‌سازیِ پروتکل failover نیست.

بخش‌های بعدی به شرح پیکربندی و نحوهٔ کارکرد کتابخانهٔ قلاب Kea HA می‌پردازند.

کتابخانهٔ قلاب Kea HA از سه پیکربندی، که با عنوان حالت‌های HA نیز شناخته می‌شوند، پشتیبانی می‌کند: load-balancing، hot-standby و passive-backup. در حالت load-balancing، دو سرور به درخواست‌های DHCP پاسخ می‌دهند. عملکرد load-balancing همان‌گونه که در RFC 3074 https://datatracker.ietf.org/doc/html/rfc3074 شرح داده شده پیاده‌سازی گردیده است، و هر سرور به نیمی از پرس‌وجوهای DHCP دریافتی پاسخ می‌دهد. هنگامی که یکی از سرورها اجاره‌ای را برای یک کلاینت تخصیص می‌دهد، از طریق کانال کنترل (از طریق RESTful API) به سرور همتا اطلاع می‌دهد تا همتا بتواند اطلاعات اجاره را در پایگاه دادهٔ خود ذخیره کند. اگر ارتباط با سرور همتا ناموفق باشد، پرس‌وجوی DHCP دور انداخته می‌شود و پاسخی به کلاینت DHCP بازگردانده نخواهد شد. اگر به‌روزرسانی اجاره موفقیت‌آمیز باشد، پاسخ توسط سروری که اجاره را تخصیص داده به کلاینت DHCP ارسال می‌شود. با تبادل به‌روزرسانی‌های اجاره، هر دو سرور رونوشتی از تمامی اجاره‌های تخصیص‌یافته توسط کل راه‌اندازی HA را دریافت می‌کنند، و در صورت از دسترس خارج شدن همتا، هر یک از سرورها می‌توانند برای مدیریت کل ترافیک DHCP تغییر وضعیت دهند.

در پیکربندی load-balancing، یکی از سرورها باید به عنوان primary و دیگری به عنوان secondary تعیین شود. از نظر عملکردی، تفاوتی میان این دو در طول کارکرد عادی وجود ندارد. با این حال، این تمایز هنگامی لازم است که دو سرور (تقریباً) در یک زمان راه‌اندازی شوند و ناچار باشند پایگاه‌های دادهٔ اجارهٔ خود را همگام‌سازی کنند. سرور primary ابتدا پایگاه داده را همگام می‌کند. سرور secondary قبل از شروع همگام‌سازی خود، منتظر می‌ماند تا سرور primary همگام‌سازی پایگاه دادهٔ اجاره را به پایان برساند.

در پیکربندی hot-standby، یکی از سرورها به عنوان primary و دیگری به عنوان standby تعیین می‌شود. در طول کارکرد عادی، سرور primary تنها سروری است که به درخواست‌های DHCP پاسخ می‌دهد. سرور standby به‌روزرسانی‌های اجاره را از سرور primary از طریق کانال کنترل دریافت می‌کند؛ با این حال، تا زمانی که primary در حال اجرا باشد، یا به بیان دقیق‌تر، تا زمانی که standby سرور primary را آفلاین نداند، به هیچ پرس‌وجوی DHCP پاسخ نمی‌دهد. اگر سرور standby خرابی سرور primary را تشخیص دهد، شروع به پاسخ‌گویی به تمام پرس‌وجوهای DHCP می‌کند.

نکته:

مدیران سیستم اغلب در این فکرند که آیا از حالت load-balancing استفاده کنند یا hot-standby. حالت load-balancing این مزیت را دارد که بار DHCP را بین دو نمونه تقسیم کرده و ترافیک پردازش‌شده توسط هر یک از آن‌ها را کاهش می‌دهد. با این حال، همیشه برای مدیران سیستم واضح نیست که استفاده از حالت load-balancing مستلزم تقسیم دستی استخرهای آدرس بین دو نمونهٔ Kea با استفاده از کلاس‌بندی کلاینت است، تا از تخصیص آدرس یکسان توسط هر دو سرور به کلاینت‌های مختلف ممانعت به عمل آید. چنین تفکیکی در حالت hot-standby مورد نیاز نیست. بنابراین، مزیت استفاده از hot-standby نسبت به load-balancing این است که پیکربندی ساده‌تری دارد. در مقابل، load-balancing پتانسیل کارایی بالاتری دارد اما به بهای پیکربندی پیچیده‌تر تمام می‌شود. برای جزئیات بیشتر در مورد چگونگی تقسیم استخرها با استفاده از کلاس‌بندی کلاینت، Load-Balancing Configuration را ببینید.

در پیکربندی‌های شرح‌داده‌شده در بالا، هم سرور primary و هم سرور secondary/standby به عنوان سرورهای active نامیده می‌شوند، چرا که آن‌ها به‌روزرسانی‌های اجاره را دریافت می‌کنند و می‌توانند با پاسخ دادن به پرس‌وجوهای DHCP که معمولاً توسط همتا رسیدگی می‌شد، به‌طور خودکار به خرابی‌های همتا واکنش نشان دهند. کتابخانهٔ قلاب HA از یک نوع/نقش سرور دیگر نیز پشتیبانی می‌کند: backup. استفاده از سرور backup اختیاری است، و علاوه‌بر سرورهای فعال، می‌تواند در هر دو ساختار load-balancing و hot-standby پیاده‌سازی شود. هیچ محدودیتی در تعداد سرورهای backup در راه‌اندازی HA وجود ندارد؛ با این وجود، حضور سرورهای backup ممکن است تأخیر پاسخ‌های DHCP را افزایش دهد، چرا که سرورهای فعال نه‌تنها به‌روزرسانی‌های اجاره را برای یکدیگر، بلکه برای سرورهای backup نیز ارسال می‌کنند. سرورهای فعال پیش از پاسخ دادن به کلاینت‌های DHCP منتظر تأییدیه از جانب سرورهای backup نمی‌مانند، بنابراین بار اضافی ناشی از ارسال به‌روزرسانی‌های اجاره به سرورهای backup به حداقل می‌رسد.

در آخرین پیکربندی پشتیبانی‌شده، یعنی passive-backup، تنها یک سرور فعال و معمولاً یک یا چند سرور backup وجود دارد. یک پیکربندی passive-backup بدون هیچ سرور backup نیز پذیرفته می‌شود، اما تفاوتی با اجرای یک سرور تک بدون هیچ قابلیت HA ندارد.

پیکربندی passive-backup در شرایطی به کار می‌رود که مدیر سیستم بخواهد بدون اجرای یک ساختار کامل failover، از سرور(های) backup به عنوان فضایی اضافی برای ذخیره‌سازی اجاره‌ها بهره ببرد. در این حالت، در صورت خرابی سرور primary، سرویس DHCP از دست می‌رود؛ و مستلزم آن است که مدیر سیستم سرور primary را به صورت دستی مجدداً راه‌اندازی کند تا سرویس DHCP بازیابی شود. مدیر سیستم همچنین می‌تواند یکی از سرورهای backup را برای ارائهٔ سرویس DHCP به کلاینت‌ها پیکربندی کند، زیرا این سرورها باید اطلاعات دقیق یا تقریباً دقیقی از اجاره‌های تخصیص‌یافته داشته باشند. مزیت اصلی حالت passive-backup این است که مقداری افزونگی در اطلاعات اجاره فراهم می‌کند، اما با عملکرد بهتر سرور primary در پاسخ‌گویی به پرس‌وجوهای DHCP همراه است. سرور primary مجبور نیست پیش از ارسال پاسخ به کلاینت DHCP، منتظر دریافت تأییدیه‌های به‌روزرسانی اجاره از سرورهای backup بماند. این کار زمان پاسخ‌گویی را در مقایسه با حالت‌های load-balancing و hot-standby کاهش می‌دهد؛ حالت‌هایی که در آن‌ها سرور پاسخ‌دهنده به پرس‌وجوی DHCP باید پیش از پاسخ‌دهی به کلاینت، منتظر تأییدیه از سوی دیگر سرور فعال بماند.

نکته:

یک مورد کاربرد جالب برای یک سرور فعال منفرد در حالت passive-backup، سرویس اعلان است که در آن نرم‌افزاری با معرفی خود به عنوان سرور backup، اعلان‌های هم‌زمان دربارهٔ اجاره‌های تخصیص‌یافته و حذف‌شده را از سرور primary دریافت می‌کند و می‌تواند آن‌ها را در یک صفحهٔ پایش نمایش دهد، هشدارها را به کار اندازد، و غیره.

همگام‌سازی ساعت‌ها برای کارکرد قابل‌اطمینان پیکربندی HA ضروری است. سرورها اطلاعات اجاره را - از طریق به‌روزرسانی‌های اجاره و در طول همگام‌سازی پایگاه‌های داده - از جمله زمان تخصیص اجاره و زمان انقضای آن، به اشتراک می‌گذارند. معمولاً مقداری انحراف ساعت (clock skew) بین سرورهای حاضر در راه‌اندازی HA وجود دارد؛ این موضوع تا زمانی که انحراف ساعت در مقایسه با طول عمر اجاره‌ها نسبتاً کم باشد، قابل قبول است. با این حال، اگر انحراف ساعت بیش از حد زیاد شود، زمان‌های انقضای متفاوت اجاره در سرورهای گوناگون ممکن است باعث اختلال در عملکرد سامانهٔ HA شود. برای نمونه، یک سرور ممکن است اجاره‌ای را منقضی‌شده تلقی کند در حالی که در واقعیت هنوز معتبر است. فرایند بازپس‌گیری اجاره ممکن است نام مرتبط با این اجاره را از DNS حذف کند و بعداً هنگامی که کلاینت سعی در تمدید اجاره دارد، مشکلاتی به وجود آورد.

هر سرور فعال با مقایسهٔ زمان فعلی خود با زمان بازگردانده‌شده توسط شریک خود در پاسخ به دستور ha-heartbeat، انحراف ساعت را پایش می‌کند. این کار تقریب مناسبی از انحراف ساعت ارائه می‌دهد، اگرچه بازهٔ زمانی بین ارسال پاسخ توسط شریک و دریافت آن توسط سروری که دستور ha-heartbeat را فرستاده است در نظر نمی‌گیرد. اگر انحراف ساعت از ۳۰ ثانیه بیشتر شود، یک پیام لاگ هشدار صادر می‌شود. مدیر سیستم می‌تواند با همگام‌سازی ساعت‌ها (برای مثال با استفاده از NTP) این مشکل را برطرف کند؛ سرورها باید اصلاح انحراف ساعت را تشخیص داده و صدور هشدار را متوقف کنند.

اگر انحراف ساعت اصلاح نشود و از ۶۰ ثانیه فراتر رود، سرویس HA در هر یک از سرورها خاتمه می‌یابد، به این معنی که ماشین حالت وارد وضعیت terminated می‌شود. سرورها به پاسخ‌گویی به کلاینت‌های DHCP (مانند حالت load-balancing یا hot-standby) ادامه خواهند داد، اما نه به‌روزرسانی‌های اجاره و نه ضربان‌های قلب (heartbeats) را رد و بدل نخواهند کرد و پایگاه‌های دادهٔ اجارهٔ آن‌ها از یکدیگر واگرا می‌شوند. در این حالت، مدیر سیستم باید ساعت‌ها را همگام کرده و سرورها را مجدداً راه‌اندازی کند.

نکته:

راه‌اندازی مجدد سرورها به صورت تک‌تک و بدون ترتیب خاصی امکان‌پذیر است. پیش از راه‌اندازی مجدد سرورها، ساعت‌ها حتماً باید همگام باشند. سرور ری‌استارت‌شده تا زمانی که شریک آن نیز ری‌استارت شود در وضعیت waiting باقی می‌ماند. اگر شریک ظرف مدت ۱۰ دقیقه راه‌اندازی مجدد نشود، سرورِ ری‌استارت‌شده برای ادامهٔ پاسخ‌گویی به کلاینت‌های DHCP دوباره به وضعیت terminated بازمی‌گردد. برای از سر گرفتن سرویس عادی HA، هر دو سرور را مجدداً راه‌اندازی کنید.

نکته:

انحراف ساعت تنها بین دو سرور فعال سنجیده می‌شود، و تنها سرورهای فعال در صورت بالا بودن بیش از حد انحراف وارد وضعیت terminated می‌شوند. انحراف ساعت بین سرورهای فعال و پشتیبان (backup) ارزیابی نمی‌شود، زیرا سرورهای فعال پیام‌های ضربان قلب را با سرورهای پشتیبان تبادل نمی‌کنند.

از نسخهٔ Kea 1.9.7، کتابخانهٔ هوک دسترس‌پذیری بالا (High Availability) از HTTPS بر بستر TLS پشتیبانی می‌کند، همان‌گونه که در پشتیبانی از TLS/HTTPS <#tls> شرح داده شده است.

پارامترهای پیکربندی HTTPS عبارتند از:

  • trust-anchor - نام فایل یا دایرکتوری‌ای را مشخص می‌کند که گواهی مرجع صدور گواهی (CA) مربوط به یک موجودیت Kea در آن یافت می‌شود.
  • cert-file - نام فایل حاوی گواهی نهاد پایانی (end-entity) مورد استفاده را مشخص می‌کند.
  • key-file - کلید خصوصی گواهی نهاد پایانی مورد استفاده را مشخص می‌کند.

این پارامترها را می‌توان در هر دو سطح سراسری (global) و نظیر (peer) پیکربندی کرد. در صورت پیکربندی در هر دو سطح، مقدار peer استفاده می‌شود که امکان اشتراک‌گذاری مقادیر عمومی را فراهم می‌سازد.

هر سه پارامتر یا باید همگی تعیین نشده باشند (HTTPS غیرفعال) یا همگی مشخص شده باشند (HTTPS فعال). تعیین رشتهٔ خالی به عنوان مشخص‌نشده در نظر گرفته می‌شود؛ این قابلیت می‌تواند به عنوان مثال برای غیرفعال کردن HTTPS برای یک peer خاص در زمانی که در سطح سراسری فعال است، به کار رود.

از آنجا که کتابخانهٔ هوک High Availability یک کلاینت HTTPS است، هیچ پارامتر cert-required در پیکربندی این هوک وجود ندارد. این پارامتر می‌تواند در سمت سرور تنظیم شود تا گواهی کلاینت در ارتباط کلاینت-سرور الزامی شده و اعتبارسنجی شود. این پارامتر ارتباط بین نظیرهای HA را در سمت کلاینت تحت تأثیر قرار نمی‌دهد؛ برای اطلاعات دربارهٔ سمت سرور، به بخش زیر مراجعه کنید.

از نسخهٔ Kea 2.1.7 به بعد، سمت سرور HTTPS نیز پشتیبانی می‌شود:

  • مدخل peer مربوط به نام سرور برای تنظیمات TLS استفاده می‌شود.
  • پارامتر جدید require-client-certs مشخص می‌کند که آیا گواهی‌های کلاینت الزامی و اعتبارسنجی می‌شوند یا خیر، یعنی رفتاری مشابه cert-required دارد. مقدار پیش‌فرض آن true است و یک پارامتر پیکربندی در سطح HA (در مقایسه با پیکربندی peer) به شمار می‌رود.

نسخهٔ Kea 2.1.7 یک ویژگی امنیتی جدید با پارامتر پیکربندی HA به نام restrict-commands اضافه کرد: در صورت تنظیم روی true، دستوراتی که توسط این هوک استفاده نمی‌شوند رد خواهند شد. مقدار پیش‌فرض از نسخهٔ Kea 3.0.0 برابر با true است.

در ادامه نمونه‌ای از یک جفت سرور HA برای حالت hot-standby به همراه TLS آورده شده است.

سرور ۱:

{
  "Dhcp4": {
    "hooks-libraries": [{
        "library": "libdhcp_lease_cmds.so",
        "parameters": { }
    }, {
        "library": "libdhcp_ha.so",
        "parameters": {
            "high-availability": [{
                "this-server-name": "server1",
                "trust-anchor": "/usr/lib/kea/CA.pem",
                "cert-file": "/usr/lib/kea/server1_cert.pem",
                "key-file": "/usr/lib/kea/server1_key.pem",
                "mode": "hot-standby",
                "heartbeat-delay": 10000,
                "max-response-delay": 60000,
                "max-ack-delay": 5000,
                "max-unacked-clients": 5,
                "peers": [{
                    "name": "server1",
                    "url": "http://192.168.56.33:8005/",
                    "role": "primary",
                    "auto-failover": true
                }, {
                    "name": "server2",
                    "url": "http://192.168.56.66:8005/",
                    "role": "standby",
                    "auto-failover": true
                }]
            }]
        }
    }],
    "subnet4": [{
        "id": 1,
        "subnet": "192.0.3.0/24",
        "pools": [{
            "pool": "192.0.3.100 - 192.0.3.250"
            }]
    }],
    "control-sockets": [{
        "socket-type": "https",
        "socket-address": "192.168.56.33",
        "socket-port": 8000,
        "trust-anchor": "/var/lib/kea/CA.pem",
        "cert-file": "/var/lib/kea/server1_cert.pem",
        "key-file": "/var/lib/kea/server1_key.pem",
        "cert-required": true
     }]
  }
}

سرور ۲:

{
  "Dhcp4": {
    "hooks-libraries": [{
        "library": "libdhcp_lease_cmds.so",
        "parameters": { }
    }, {
        "library": "libdhcp_ha.so",
        "parameters": {
            "high-availability": [{
                "this-server-name": "server2",
                "trust-anchor": "/usr/lib/kea/CA.pem",
                "cert-file": "/usr/lib/kea/server2_cert.pem",
                "key-file": "/usr/lib/kea/server2_key.pem",
                "mode": "hot-standby",
                "heartbeat-delay": 10000,
                "max-response-delay": 60000,
                "max-ack-delay": 5000,
                "max-unacked-clients": 5,
                "peers": [{
                    "name": "server1",
                    "url": "http://192.168.56.33:8005/",
                    "role": "primary",
                    "auto-failover": true
                }, {
                    "name": "server2",
                    "url": "http://192.168.56.66:8005/",
                    "role": "standby",
                    "auto-failover": true
                }]
            }]
        }
    }],
    "subnet4": [{
        "id": 1,
        "subnet": "192.0.3.0/24",
        "pools": [{
            "pool": "192.0.3.100 - 192.0.3.250"
            }]
    }],
    "control-sockets":[{
        "socket-type": "https",
        "socket-address": "192.168.56.66",
        "socket-port": 8000,
        "trust-anchor": "/var/lib/kea/CA.pem",
        "cert-file": "/var/lib/kea/server2_cert.pem",
        "key-file": "/var/lib/kea/server2_key.pem",
        "cert-required": true
    }]
  }
}

یک سرور DHCP که در یک ساختار HA (دسترس‌پذیری بالا) کار می‌کند، یک ماشین وضعیت (state machine) را اجرا می‌نماید و وضعیت سرور می‌تواند توسط همتایانش با استفاده از دستور ha-heartbeat که از طریق RESTful API ارسال می‌شود، دریافت گردد. اگر سرور شریک (partner) در مدت‌زمان مشخص‌شده به دستور ha-heartbeat پاسخ ندهد، ارتباط قطع‌شده تلقی می‌شود و سرور ممکن است، بسته به پیکربندی، از تدابیر اضافی (که در ادامه این سند شرح داده شده است) برای بررسی اینکه آیا شریک همچنان فعال است یا خیر، استفاده کند. اگر مشخص شود که شریک کار نمی‌کند، سرور به وضعیت partner-down تغییر وضعیت می‌دهد تا تمام ترافیک DHCP هدایت‌شده به سیستم را مدیریت کند.

در این حالت، سرور بازمانده به ارسال دستور ha-heartbeat ادامه می‌دهد تا زمان فعال شدن مجدد شریک را تشخیص دهد. در آن هنگام، سرور شریک پایگاه‌داده اجاره‌ها (leases) را همگام‌سازی می‌کند. هنگامی که مجدداً آماده کار شد، سرور بازمانده به عملکرد عادی بازمی‌گردد؛ یعنی به وضعیت load-balancing یا hot-standby.

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

  • backup - عملکرد عادی سرور پشتیبان. در این وضعیت، به‌روزرسانی‌های اجاره را از سرور(های) فعال دریافت می‌کند.
  • communication-recovery - یک سرور فعال که در حالت load-balancing اجرا می‌شود، هنگامی که در کانال کنترلی با سرور شریک دچار مشکلات ارتباطی شود، ممکن است به این وضعیت منتقل گردد. این یک وضعیت میانی بین وضعیت‌های load-balancing و partner-down است. در این وضعیت، سرور همچنان به پرس‌وجوهای DHCP پاسخ می‌دهد اما به‌روزرسانی‌های اجاره را برای شریک ارسال نمی‌کند؛ به‌روزرسانی‌های اجاره در صف قرار می‌گیرند و پس از برقراری مجدد ارتباط عادی ارسال می‌شوند. اگر ارتباط در مدت‌زمان مشخص‌شده از سر گرفته نشود، سرور اصلی (primary) به وضعیت partner-down تغییر وضعیت می‌دهد. وضعیت communication-recovery برای اطمینان از سرویس‌دهی مطمئن DHCP در شرایطی معرفی شد که هر دو سرور فعال همچنان مشغول به کار هستند اما ارتباط بین آنها برای مدتی طولانی قطع شده است. می‌توان هر یک از سرورها را طوری پیکربندی کرد که هرگز وارد این وضعیت نشوند، با تنظیم delayed-updates-limit روی 0 (برای جزئیات بیشتر درباره این پارامتر، به بخش Load-Balancing Configuration در ادامه این فصل مراجعه کنید). غیرفعال کردن ورود به وضعیت communication-recovery باعث می‌شود سرور به‌محض عدم توانایی در برقراری ارتباط با شریک خود، بررسی وضعیت partner-down را آغاز کند.

نکته:

در Kea 1.9.4، با معرفی delayed-updates-limit، رفتار پیش‌فرض سرور در حالت load-balancing تغییر کرد. اکنون هنگامی که یک سرور با شریک خود دچار مشکلات ارتباطی می‌شود، وارد وضعیت communication-recovery شده و تا زمان برقراری مجدد ارتباط، به‌روزرسانی‌های اجاره را صف‌بندی می‌کند. پیش از Kea 1.9.4، سروری که در حالت load-balancing قادر به برقراری ارتباط با شریک خود نبود، بلافاصله انتقال به وضعیت partner-down را آغاز می‌کرد.
  • hot-standby - عملکرد عادی سرور فعال در حال اجرا در حالت hot-standby؛ هم سرور اصلی و هم سرور standby در حین عملکرد عادی خود در این وضعیت قرار دارند. سرور اصلی به پرس‌وجوهای DHCP پاسخ می‌دهد و به‌روزرسانی‌های اجاره را به سرور standby و هر سرور backup موجود ارسال می‌کند.
  • load-balancing - عملکرد عادی سرور فعال در حال اجرا در حالت load-balancing؛ هم سرور اصلی و هم سرور ثانویه (secondary) در حین عملکرد عادی خود در این وضعیت قرار دارند. هر دو سرور به پرس‌وجوهای DHCP پاسخ می‌دهند و به‌روزرسانی‌های اجاره را برای یکدیگر و هر سرور backup موجود ارسال می‌کنند.
  • in-maintenance - یک سرور فعال در نتیجه دریافت اعلان از طرف شریک خود مبنی بر درخواست تعمیر و نگهداری ساختار HA توسط مدیر سیستم، به این وضعیت منتقل می‌شود. مدیر سیستم با ارسال دستور ha-maintenance-start به سروری که قرار است مسئولیت پاسخ‌گویی به کلاینت‌های DHCP را در حین آفلاین شدن سرور دیگر برای تعمیرات بر عهده بگیرد، درخواست تعمیر و نگهداری را ثبت می‌کند. اگر سرور در وضعیت in-maintenance باشد، می‌توان آن را با خیال راحت خاموش کرد. سرور شریک بلافاصله پس از پی بردن به خاموش شدن سرورِ در حال تعمیر، به وضعیت partner-down تغییر وضعیت می‌دهد.
  • partner-down - یک سرور فعال پس از تشخیص آفلاین بودن شریک خود (سرور فعال دیگر)، به این وضعیت منتقل می‌شود. اگر صرفاً یک سرور backup در دسترس نباشد، سرور به این وضعیت تغییر حالت نمی‌دهد. در وضعیت partner-down، سرور فعال به تمام پرس‌وجوهای DHCP پاسخ می‌دهد؛ از جمله پرس‌وجوهایی که در حالت عادی توسط سروری که اکنون در دسترس نیست مدیریت می‌شدند.
  • partner-in-maintenance - یک سرور فعال پس از دریافت دستور ha-maintenance-start از مدیر سیستم به این وضعیت منتقل می‌شود. سرور در این وضعیت مسئول پاسخ‌گویی به تمام درخواست‌های DHCP می‌شود. سرور دستور ha-maintenance-notify را به شریک ارسال می‌کند که آن شریک باید وارد وضعیت in-maintenance شود. سروری که در وضعیت partner-in-maintenance باقی می‌ماند، به ارسال به‌روزرسانی‌های اجاره به شریک ادامه می‌دهد تا زمانی که متوجه شود شریک پاسخ دادن به این به‌روزرسانی‌ها، ضربان‌های قلب (heartbeats) یا هر دستور دیگری را متوقف کرده است. در این صورت، سرورِ در وضعیت partner-in-maintenance به وضعیت partner-down تغییر حالت داده و به پاسخ‌گویی به پرس‌وجوها ادامه می‌دهد، اما دیگر به‌روزرسانی‌های اجاره را ارسال نمی‌کند.
  • passive-backup - یک سرور اصلی که در حالت HA به صورت passive-backup اجرا می‌شود، بلافاصله پس از راه‌اندازی (boot) به این وضعیت منتقل می‌شود. سرور اصلی در این وضعیت به تمام ترافیک DHCP پاسخ می‌دهد و به‌روزرسانی‌های اجاره را به سرورهای پشتیبان متصل به خود ارسال می‌کند. به‌طور پیش‌فرض، سرور اصلی منتظر تاییدیه از سرورهای پشتیبان نمی‌ماند و بلافاصله پس از ارسال به‌روزرسانی‌های اجاره به تمامی سرورهای پشتیبان، به پرس‌وجوی DHCP پاسخ می‌دهد. اگر هر یک از به‌روزرسانی‌های اجاره با شکست مواجه شود، سرور پشتیبان آن به‌روزرسانی را از دست می‌دهد اما کلاینت DHCP همچنان پیکربندی می‌شود. این پیکربندی پیش‌فرض را می‌توان با تنظیم پارامتر پیکربندی wait-backup-ack روی true تغییر داد؛ در این حالت، سرور اصلی همواره منتظر تاییدیه‌ها می‌ماند و اگر ارسال هر یک از به‌روزرسانی‌های مربوطه با شکست مواجه شود، پرس‌وجوی DHCP را نادیده می‌گیرد. این کار یکپارچگی پایگاه‌داده اجاره‌ها بین سرور اصلی و ثانویه را بهبود می‌بخشد. با این حال، در صورت بروز اختلال در ارتباط بین سرور فعال و هر یک از سرورهای پشتیبان، از دیدگاه کلاینت‌های DHCP در عمل منجر به از کار افتادن سرویس DHCP می‌شود.
  • ready - یک سرور فعال پس از همگام‌سازی پایگاه‌داده اجاره‌های خود با یک شریک فعال، به این وضعیت منتقل می‌شود. این وضعیت به شریک (که ممکن است در وضعیت partner-down باشد) نشان می‌دهد که باید به عملکرد عادی بازگردد. اگر و هنگامی که این کار را انجام دهد، سرور در وضعیت ready نیز عملکرد عادی خود را آغاز می‌کند.
  • syncing - یک سرور فعال برای واکشی اجاره‌ها از شریک فعال و به‌روزرسانی پایگاه‌داده محلی اجاره‌ها، به این وضعیت منتقل می‌شود. هنگام قرار داشتن در این وضعیت، سرور دستور dhcp-disable <#std-isccmd-dhcp-disable> را صادر می‌کند تا سرویس DHCP شریکی را که اجاره‌ها از آن واکشی می‌شوند، غیرفعال کند. سرویس DHCP حداکثر به مدت ۶۰ ثانیه غیرفعال می‌شود و در صورتی که شریک همگام‌کننده نتواند سرویس را مجدداً فعال کند، پس از این مدت به‌طور خودکار دوباره فعال می‌شود. اگر همگام‌سازی با موفقیت انجام شود، سرور همگام‌کننده دستور ha-sync-complete-notify را جهت اطلاع به شریک صادر می‌کند. در اکثر وضعیت‌ها، سرور شریک سرویس DHCP خود را مجدداً فعال می‌کند تا به پاسخ‌گویی به پرس‌وجوهای DHCP ادامه دهد. در وضعیت partner-down، شریک ابتدا پیش از فعال کردن سرویس DHCP اطمینان حاصل می‌کند که ارتباط بین سرورها دوباره برقرار شده است. عملیات همگام‌سازی به صورت همگام (synchronous) انجام می‌شود؛ سرور منتظر پاسخی از سوی شریک می‌ماند و در حین انجام همگام‌سازی اجاره‌ها کار دیگری انجام نمی‌دهد. سروری که پیکربندی شده تا پایگاه‌داده اجاره‌ها را با شریک خود همگام نکند، یعنی زمانی که پارامتر پیکربندی sync-leases روی false تنظیم شده باشد، هرگز به این وضعیت منتقل نمی‌شود. در عوض، مستقیماً از وضعیت waiting به وضعیت ready منتقل می‌گردد.
  • terminated - یک سرور فعال زمانی به این وضعیت منتقل می‌شود که کتابخانه قلاب (hook library) دسترس‌پذیری بالا دیگر قادر به ارائه سرویس مطمئن نباشد و برای حل مشکل نیاز به مداخله دستی مدیر سیستم باشد. مشکلات مختلف در پیکربندی HA ممکن است باعث انتقال سرور به این وضعیت شود. در زمان قرار داشتن در این وضعیت، سرور بر اساس حالت HA انتخاب‌شده (load-balancing یا hot-standby) به پاسخ‌گویی به کلاینت‌های DHCP ادامه می‌دهد، اما به‌روزرسانی‌های اجاره ردوبدل نشده و ضربان‌های قلب ارسال نمی‌شوند. هنگامی که سرور وارد وضعیت terminated شد، تا زمانی که مجدداً راه‌اندازی نشود در این وضعیت باقی می‌ماند. مدیر سیستم باید پیش از راه‌اندازی مجدد سرور، مشکلی که این وضعیت را ایجاد کرده است برطرف کند (مانند همگام‌سازی ساعت‌ها)؛ در غیر این صورت، سرور به محض اینکه دریابد مشکل همچنان پابرجاست، مجدداً به وضعیت terminated بازخواهد گشت.
  • waiting - هر نمونه سرورِ راه‌اندازی‌شده وارد این وضعیت می‌شود. یک سرور پشتیبان (backup) مستقیماً از این وضعیت به وضعیت backup می‌رود. یک سرور فعال برای بررسی وضعیت شریک خود، یک ضربان قلب به آن ارسال می‌کند؛ اگر به نظر برسد که شریک در دسترس نیست، سرور به وضعیت partner-down منتقل می‌شود. اگر شریک در دسترس باشد، بسته به تنظیم پارامتر پیکربندی sync-leases، سرور به وضعیت syncing یا ready منتقل می‌گردد. اگر به نظر برسد هر دو سرور در وضعیت waiting قرار دارند (راه‌اندازی هم‌زمان)، ابتدا سرور اصلی به وضعیت بعدی منتقل می‌شود. سرور ثانویه یا standby تا زمانی که سرور اصلی به وضعیت ready منتقل نشود، در وضعیت waiting باقی می‌ماند.

نکته:

در حال حاضر، راه‌اندازی مجدد سرویس HA از وضعیت terminated نیازمند راه‌اندازی مجدد سرور DHCP یا بارگذاری مجدد پیکربندی آن است.

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

عبارت DHCP Service Scopes مشخص می‌کند که سرور در یک وضعیت معین به کدام گروه از پرس‌وجوهای DHCP دریافت‌شده پاسخ می‌دهد. پیکربندی HA باید نامی یکتا را برای هر سرور درون ساختار HA تعیین کند. این سند در مثال‌های ارائه‌شده از این قرارداد استفاده می‌کند: "server1" برای سرور اصلی، "server2" برای سرور ثانویه یا standby، و "server3" برای سرور backup. در عمل تا زمانی که نام‌ها یکتا باقی بمانند، می‌توان از هر نامی استفاده کرد.

توضیحات دقیق این حوزه‌ها (scopes) در ادامه آمده است..SS رفتار پیش‌فرض سرور در وضعیت‌های گوناگون HA

وضعیت نوع سرور سرویس DHCP محدوده‌های سرویس DHCP
backup سرور backup غیرفعال هیچ‌کدام
communication-recovery primary یا secondary (تنها در حالت load-balancing) فعال "HA_server1" یا "HA_server2"
hot-standby primary یا standby (حالت hot-standby) فعال "HA_server1" در صورت primary بودن، در غیر این صورت هیچ‌کدام
load-balancing primary یا secondary (حالت load-balancing) فعال "HA_server1" یا "HA_server2"
in-maintenance سرور فعال غیرفعال هیچ‌کدام
partner-down سرور فعال فعال تمام محدوده‌ها
partner-in-maintenance سرور فعال فعال تمام محدوده‌ها
passive-backup سرور فعال فعال تمام محدوده‌ها
ready سرور فعال غیرفعال هیچ‌کدام
syncing سرور فعال غیرفعال هیچ‌کدام
terminated سرور فعال فعال مشابه با وضعیت load-balancing یا hot-standby
waiting هر سروری غیرفعال هیچ‌کدام

در حالت load-balancing دو محدوده برای سرورهای فعال مشخص شده است: "HA_server1" و "HA_server2". پرس‌وجوهای DHCP که به server1 موازنه‌بار می‌شوند متعلق به محدودهٔ "HA_server1" و پرس‌وجوهایی که به server2 موازنه‌بار می‌شوند متعلق به محدودهٔ "HA_server2" هستند. اگر هر یک از سرورها در وضعیت partner-down باشد، شریک فعال مسئول پاسخگویی به هر دو محدوده است.

در حالت hot-standby، تنها یک محدوده وجود دارد - "HA_server1" - زیرا تنها server1 به پرس‌وجوهای DHCP پاسخ می‌دهد. اگر آن سرور از دسترس خارج شود، server2 مسئول این محدوده خواهد بود.

سرورهای backup محدودهٔ اختصاصی خود را ندارند. در برخی موارد می‌توان از آن‌ها برای پاسخگویی به پرس‌وجوهای متعلق به محدوده‌های سرورهای فعال استفاده کرد. همچنین، سرور backup که نه در وضعیت partner-down و نه در عملکرد عادی باشد، به هیچ محدوده‌ای سرویس نمی‌دهد.

نام‌های محدوده می‌توانند برای مرتبط‌سازی استخرها (pools)، زیرشبکه‌ها و شبکه‌ها با سرورهای مشخص استفاده شوند، به طوری که فقط این سرورها بتوانند نشانی‌ها یا پیشوندها را از آن استخرها، زیرشبکه‌ها یا شبکه‌ها تخصیص دهند. این کار از طریق سازوکار طبقه‌بندی کلاینت (client classification) انجام می‌شود (برای جزئیات بیشتر به Load Balancing With Advanced Classification مراجعه کنید)..SS انتقال قلمرو در وضعیت Partner-Down

هنگامی که یکی از سرورها درمی‌یابد شریک آن در دسترس نیست، شروع به سرویس‌دهی به کلاینت‌ها هم از قلمرو (scope) خود و هم از قلمرو شریک خارج از دسترس می‌کند. این فرایند برای کلاینت‌های جدید، یعنی آن‌هایی که پیام‌های DHCPDISCOVER (در DHCPv4) یا Solicit (در DHCPv6) را ارسال می‌کنند، سرراست است، زیرا آن درخواست‌ها به سرور خاصی فرستاده نمی‌شوند. سرورِ در دسترس هنگامی که در وضعیت partner-down قرار دارد، به تمام این‌گونه پرس‌وجوها پاسخ می‌دهد.

هنگامی که یک کلاینت اجاره‌ای را تجدید می‌کند، پیام DHCPREQUEST (در DHCPv4) یا Renew (در DHCPv6) خود را مستقیماً به سروری می‌فرستد که اجاره در حال تجدید را تخصیص داده است. اگر این سرور دیگر در دسترس نباشد، کلاینت پاسخی دریافت نخواهد کرد. در این حالت، کلاینت به استفاده از اجاره خود ادامه داده و تا زمان سپری شدن زمان‌سنج اتصال مجدد (T2)، برای تجدید آن تلاش می‌کند. سپس کلاینت وارد مرحله اتصال مجدد (rebinding) می‌شود که در آن پیام DHCPREQUEST (در DHCPv4) یا Rebind (در DHCPv6) را به هر سرور در دسترسی ارسال می‌کند. سرور برجا مانده درخواست اتصال مجدد را دریافت کرده و معمولاً طول عمر اجاره را تمدید می‌کند. سپس کلاینت بر حسب نیاز، برای تجدید اجاره خود به تماس با آن سرور جدید ادامه می‌دهد.

اگر و هنگامی که سرور دیگر دوباره در دسترس قرار گیرد، هر دو سرور فعال در نهایت به وضعیت load-balancing یا hot-standby تغییر حالت می‌دهند، که در آن مجدداً مسئول قلمروهای خود خواهند بود. برخی کلاینت‌های متعلق به قلمرو سرور راه‌اندازی‌مجددشده تلاش خواهند کرد اجاره‌های خود را از طریق سرور برجا مانده تجدید کنند، اما این سرور دیگر به آن‌ها پاسخ نخواهد داد؛ کلاینت در نهایت از طریق سازوکار اتصال مجدد (rebinding) دوباره به سرور صحیح بازخواهد گشت.

در ادامه قطعه‌پیکربندی برای فعال‌سازی دسترسی‌پذیری بالا (HA) روی سرور primary در پیکربندی load-balancing آمده است. همین پیکربندی باید روی سرورهای secondary و backup نیز اعمال شود، با این تفاوت که this-server-name روی آن سرورها باید به ترتیب برابر "server2" و "server3" تنظیم شود.

نکته:

به یاد داشته باشید که حالت load-balancing نیازمند آن است که استخرهای آدرس (address pools) و استخرهای پیشوند واگذارشده (delegated prefix pools) بین سرورهای فعال تقسیم شوند. در طول عملکرد عادی، سرورها از استخرهای غیرهم‌پوشان استفاده می‌کنند تا از تخصیص یک اجاره یکسان به کلاینت‌های مختلف توسط هر دو نمونه جلوگیری شود. سرور تنها زمانی از بخش‌های استخر متعلق به شریک استفاده می‌کند که شریک در حال اجرا نباشد. یادداشت‌های موجود در بخش Supported Configurations را که تفاوت‌های میان حالت‌های load-balancing و hot-standby را مشخص می‌کنند، ببینید. معناشناسی افرازبندی استخر (pool partitioning) در ادامه این بخش توضیح داده شده است. بخش Load Balancing With Advanced Classification مثال‌های پیشرفته‌ای از افرازبندی استخر ارائه می‌دهد.
"Dhcp4": {
    "hooks-libraries": [{
        "library": "libdhcp_lease_cmds.so",
        "parameters": { }
    }, {
        "library": "libdhcp_ha.so",
        "parameters": {
            "high-availability": [{
                "this-server-name": "server1",
                "mode": "load-balancing",
                "heartbeat-delay": 10000,
                "max-response-delay": 60000,
                "max-ack-delay": 5000,
                "max-unacked-clients": 5,
                "max-rejected-lease-updates": 10,
                "delayed-updates-limit": 100,
                "peers": [{
                    "name": "server1",
                    "url": "http://192.168.56.33:8005/",
                    "role": "primary",
                    "auto-failover": true
                }, {
                    "name": "server2",
                    "url": "http://192.168.56.66:8005/",
                    "role": "secondary",
                    "auto-failover": true
                }, {
                    "name": "server3",
                    "url": "http://192.168.56.99:8005/",
                    "role": "backup",
                    "basic-auth-user": "foo",
                    "basic-auth-password": "1234",
                    "auto-failover": false
                }]
            }]
        }
    }],
    "subnet4": [{
        "id": 1,
        "subnet": "192.0.3.0/24",
        "pools": [{
            "pool": "192.0.3.100 - 192.0.3.150",
            "client-classes": [ "HA_server1" ]
         }, {
            "pool": "192.0.3.200 - 192.0.3.250",
            "client-classes": [ "HA_server2" ]
         }],
         "option-data": [{
            "name": "routers",
            "data": "192.0.3.1"
         }],
         "relay": { "ip-address": "10.1.2.3" }
    }]
}

برای فعال‌سازی HA دو کتابخانه هوک (hook) باید بارگیری شوند: libdhcp_lease_cmds.so و libdhcp_ha.so. دومی ویژگی HA را پیاده‌سازی می‌کند، در حالی که اولی دستورهای کنترلی مورد نیاز HA را برای دریافت و دستکاری اجاره‌ها در سرورهای دوردست فعال می‌سازد. در مثال ارائه‌شده در بالا، فرض شده است که کتابخانه‌های Kea در دایرکتوری /usr/lib نصب شده‌اند. اگر Kea در دایرکتوری /usr نصب نشده باشد، مکان کتابخانه‌های هوک باید متناسب با آن به‌روزرسانی شود.

پیکربندی HA در محدوده libdhcp_ha.so مشخص می‌شود. توجه داشته باشید در حالی که پارامتر سطح بالای high-availability یک فهرست است، در حال حاضر فقط یک ورودی پشتیبانی می‌شود.

پارامترهای سراسری زیر رفتار سرور را در رابطه با HA کنترل می‌کنند:

  • this-server-name - شناسه یکتای سرور در این راه‌اندازی HA است. این شناسه باید با یکی از سرورهای مشخص‌شده در فهرست peers مطابقت داشته باشد.
  • mode - حالت عملکرد HA را مشخص می‌کند. حالت‌هایی که در حال حاضر پشتیبانی می‌شوند load-balancing و hot-standby هستند.
  • heartbeat-delay - مدت زمان بر حسب میلی‌ثانیه میان ارسال آخرین ضربان قلب (heartbeat) (یا دستور دیگری که برای شریک ارسال شده) و ضربان قلب بعدی را مشخص می‌کند. ضربان‌های قلب به صورت دوره‌ای برای دریافت وضعیت شریک و بررسی در حال کار بودن آن ارسال می‌شوند. مقدار پیش‌فرض این پارامتر 10000 میلی‌ثانیه است.
  • max-response-delay - مدت زمان بر حسب میلی‌ثانیه از زمان آخرین ارتباط موفق با شریک را مشخص می‌کند که پس از آن سرور فرض می‌کند ارتباط با شریک قطع شده است. این مدت زمان باید بزرگتر از heartbeat-delay باشد؛ معمولاً باید مضربی از heartbeat-delay باشد. هنگامی که سرور تشخیص دهد ارتباط قطع شده است، ممکن است به وضعیت partner-down تغییر حالت دهد (زمانی که max-unacked-clients برابر 0 است) یا رویه تشخیص خرابی را با استفاده از مقادیر دو پارامتر زیر فعال کند. مقدار پیش‌فرض این پارامتر 60000 میلی‌ثانیه است.
  • max-ack-delay - یکی از پارامترهایی است که تشخیص خرابی شریک را کنترل می‌کند. هنگامی که ارتباط با شریک قطع می‌شود، سرور مقادیر فیلد "secs" (در DHCPv4) یا گزینه "elapsed time" (در DHCPv6) را که نشان‌دهنده مدت زمانی است که کلاینت DHCP سعی در برقراری ارتباط با سرور DHCP داشته است، بررسی می‌کند. این پارامتر حداکثر زمان بر حسب میلی‌ثانیه برای تلاش کلاینت جهت ارتباط با سرور DHCP را مشخص می‌کند که پس از آن، این سرور فرض می‌کند ارتباط کلاینت با سرور DHCP ناموفق بوده است (تأییدنشده یا "unacked" است). مقدار پیش‌فرض این پارامتر 10000 است.
  • max-unacked-clients - مشخص می‌کند چه تعداد کلاینت "unacked" مجاز هستند (به max-ack-delay مراجعه کنید) پیش از آنکه این سرور فرض کند شریک آفلاین است و به وضعیت partner-down تغییر حالت دهد. مقدار ویژه 0 برای این پارامتر مجاز است که سازوکار تشخیص خرابی را غیرفعال می‌کند. در این حالت، سروری که نتواند از طریق کانال کنترلی با شریک خود ارتباط برقرار کند، فرض می‌کند که سرور شریک از کار افتاده است و بلافاصله به وضعیت partner-down می‌رود. مقدار پیش‌فرض این پارامتر 10 است.
  • max-rejected-lease-updates - مشخص می‌کند چه تعداد به‌روزرسانی اجاره برای کلاینت‌های متمایز، به دلیل تعارض میان اجاره و پیکربندی یا وضعیت شریک، می‌تواند با شکست مواجه شود پیش از آنکه سرور به وضعیت terminated تغییر حالت دهد. تعارض می‌تواند نشانه‌ای از پیکربندی نادرست باشد؛ معمولاً تعداد کمی از اجاره‌های دارای تعارض قابل قبول هستند زیرا فقط بر تعداد کمی از دستگاه‌ها تأثیر می‌گذارند. با این حال، اگر تعارض‌ها برای دستگاه‌های زیادی رخ دهد (برای مثال، کل یک زیرشبکه)، سرویس HA غیرقابل‌اعتماد شده و باید خاتمه یابد، و مشکل باید به صورت دستی توسط یک مدیر سیستم برطرف شود. انتخاب بالاترین مقدار قابل قبول برای max-rejected-lease-updates بر عهده مدیر سیستم است. مقدار پیش‌فرض 10 است. مقدار ویژه 0 سرور را به گونه‌ای پیکربندی می‌کند که هرگز سرویس HA را به دلیل تعارض‌های اجاره خاتمه ندهد. اگر مقدار 1 باشد، سرور با رخ دادن اولین تعارض به وضعیت terminated تغییر حالت می‌دهد. این پارامتر به به‌روزرسانی‌های دارای تعارض اجاره که به سرورهای پشتیبان (backup) ارسال می‌شوند ارتباطی ندارد.
  • delayed-updates-limit - حداکثر تعداد به‌روزرسانی‌های اجاره را مشخص می‌کند که می‌توانند در زمانی که سرور در وضعیت communication-recovery قرار دارد در صف قرار گیرند. این پارامتر در Kea 1.9.4 معرفی شد. مقدار ویژه 0 سرور را به گونه‌ای پیکربندی می‌کند که هرگز به وضعیت communication-recovery تغییر حالت ندهد و رفتار سرور مشابه نسخه‌های قبلی Kea خواهد بود، یعنی اگر سرور نتواند به شریک خود دسترسی پیدا کند، مستقیماً به وضعیت partner-down می‌رود. مقدار پیش‌فرض این پارامتر 100 است.

نکته:

پارامتر max-rejected-lease-updates در Kea 2.3.1 معرفی شد. پیش از این، سرور بین شکست در به‌روزرسانی اجاره به دلیل کار نکردن شریک و شکست به دلیل تعارض (مانند مشکلات پیکربندی) تمایزی قائل نمی‌شد. در نتیجه، گاهی اوقات سرور حتی با وجود این که شریک به طور عادی کار می‌کرد اما فقط برخی اجاره‌ها مشکل داشتند، می‌توانست به وضعیت partner-down تغییر حالت دهد. تعارض‌ها دیگر نباید باعث چنین انتقالی شوند. با این حال، بسته به تنظیمات max-rejected-lease-updates، تعارض‌های بیش از حد می‌تواند به خاتمه سرویس High Availability منجر شود. در آن حالت، هر دو سرور به پاسخ دادن به پرس‌وجوهای DHCP ادامه می‌دهند اما دیگر به‌روزرسانی‌های اجاره را ارسال نمی‌کنند.

مقادیر max-ack-delay و max-unacked-clients باید با دقت و با در نظر گرفتن ویژگی‌های شبکه‌ای که سرورهای DHCP در آن فعالیت می‌کنند انتخاب شوند. سرور مورد نظر ممکن است بر اساس سیاست‌های مدیریتی به برخی از کلاینت‌های DHCP پاسخ ندهد، یا سرور ممکن است پرس‌وجوهای ناقص یا نامعتبر کلاینت‌ها را دور بیندازد (drop کند). بنابراین، انتخاب مقداری بسیار پایین برای پارامتر max-unacked-clients ممکن است باعث انتقال به وضعیت partner-down شود حتی اگر شریک همچنان در حال کار باشد. از سوی دیگر، انتخاب مقداری بیش از حد بالا ممکن است باعث شود در صورتی که ترافیک DHCP در شبکه بسیار کم باشد (مانند هنگام شب)، هرگز انتقالی به وضعیت partner-down صورت نگیرد، زیرا تعداد کلاینت‌های متمایزی که سعی در ارتباط با سرور دارند می‌تواند کمتر از مقدار تنظیم‌شده برای max-unacked-clients باشد.

در برخی موارد ممکن است غیرفعال کردن کامل سازوکار تشخیص خرابی سودمند باشد، به ویژه اگر سرورها بسیار نزدیک به یکدیگر مستقر باشند و تفکیک شبکه (network partitioning) نامحتمل باشد، به این معنی که عدم پاسخ به ضربان‌های قلب تنها زمانی امکان‌پذیر باشد که شریک آفلاین باشد. در چنین مواردی، max-unacked-clients را روی 0 تنظیم کنید.

پارامتر delayed-updates-limit برای فعال یا غیرفعال کردن رویه communication-recovery استفاده می‌شود و رفتار سرور را در وضعیت communication-recovery کنترل می‌کند. این پارامتر تنها می‌تواند در حالت load-balancing استفاده شود.

اگر سروری در وضعیت load-balancing دچار مشکلات ارتباطی با شریک خود شود (شکست در ضربان قلب یا به‌روزرسانی اجاره)، سرور به وضعیت communication-recovery تغییر حالت می‌دهد. در این وضعیت، سرور به پاسخ دادن به پرس‌وجوهای DHCP ادامه می‌دهد اما به‌روزرسانی‌های اجاره را برای شریک ارسال نمی‌کند. به‌روزرسانی‌های اجاره تا زمان برقراری مجدد ارتباط در صف قرار می‌گیرند تا اطمینان حاصل شود که سرویس DHCP حتی در صورت قطع ارتباط میان شرکا، در دسترس باقی می‌ماند. ممکن است قطع ارتباط در دو حالت رخ دهد: زمانی که یکی از سرورها متوقف شده باشد، یا زمانی که هر دو سرور در دسترس باقی بمانند اما نتوانند با یکدیگر ارتباط برقرار کنند. در حالت اول، سرور برجا مانده رویه عادی را دنبال کرده و در نهایت باید به وضعیت partner-down منتقل شود. در حالت دوم، هر دو سرور باید به وضعیت communication-recovery بروند و هرگز نباید به وضعیت partner-down تغییر حالت دهند (اگر max-unacked-clients روی یک مقدار غیرصفر تنظیم شده باشد)، زیرا به تمام پرس‌وجوهای DHCP پاسخ داده می‌شود و هیچ‌یک از سرورها هیچ پرس‌وجوی DHCP تأییدنشده‌ای (unacked) را مشاهده نخواهد کرد.

انگیزه معرفی رویه communication-recovery مشکلاتی بود که ممکن است هنگامی رخ دهد که دو سرور آنلاین بمانند اما ارتباط بین آن‌ها برای مدتی قطع شود. در نسخه‌های قبلی Kea، سرورهایی که با مشکلات ارتباطی مواجه می‌شدند پیش از تغییر حالت به وضعیت partner-down، بسته‌های DHCP را دور می‌انداختند (drop می‌کردند). در برخی موارد هر دوی آن‌ها به وضعیت partner-down منتقل می‌شدند که این امر به طور بالقوه می‌توانست منجر به تخصیص آدرس‌های IP یا پیشوندهای واگذارشده یکسان به کلاینت‌های مختلف توسط هر دو سرور شود. با ورود به وضعیت میانی communication-recovery، از این مشکلات جلوگیری می‌شود.

اگر سروری در وضعیت communication-recovery ارتباط با شریک خود را مجدداً برقرار کند، تلاش می‌کند تمام به‌روزرسانی‌های معوقه اجاره را که در صف قرار داده است برای شریک ارسال کند. این کار به صورت همگام (synchronous) انجام می‌شود و ممکن است زمان قابل توجهی طول بکشد تا سرور به وضعیت load-balancing تغییر حالت دهد و عملکرد عادی خود را از سر بگیرد. حداکثر تعداد به‌روزرسانی‌های اجاره که می‌توانند در وضعیت communication-recovery صف‌بندی شوند با delayed-updates-limit کنترل می‌شود. اگر از این حد فراتر رود، سرور صف‌بندی به‌روزرسانی‌های اجاره را متوقف کرده و پس از برقراری مجدد اتصال با شریک، به جای ارسال به‌روزرسانی‌های معوقه اجاره پیش از تغییر وضعیت به load-balancing، یک همگام‌سازی کامل پایگاه‌داده انجام می‌دهد. حتی در صورت فراتر رفتن از این حد، سرور در وضعیت communication-recovery همچنان پاسخگوی کلاینت‌های DHCP باقی می‌ماند.

شاید ترجیح داده شود در مواردی که خطر قطع طولانی‌مدت ارتباط بین سرورها وجود دارد و پایگاه‌داده اجاره بزرگ است، مقادیر بالاتری برای delayed-updates-limit تنظیم شود تا از همگام‌سازی پرهزینه پایگاه‌داده اجاره جلوگیری گردد. از سوی دیگر، اگر پایگاه‌داده اجاره کوچک باشد، زمان مورد نیاز برای ارسال به‌روزرسانی‌های معوقه اجاره ممکن است طولانی‌تر از همگام‌سازی پایگاه‌داده اجاره باشد. در چنین مواردی شاید بهتر باشد از مقدار کمتری، مثلاً 10 استفاده شود. مقدار پیش‌فرض 100 یک سازش معقول است و باید در اکثر استقرارها با ترافیک متوسط به خوبی کار کند.

نکته:

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

پارامتر peers شامل فهرستی از سرورهای درون این راه‌اندازی HA است. این پیکربندی باید حداقل شامل یک سرور primary (اولیه) و یک سرور secondary (ثانویه) باشد. همچنین می‌تواند شامل تعداد نامحدودی سرور backup (پشتیبان) باشد. در این مثال، یک سرور پشتیبان وجود دارد که به‌روزرسانی‌های اجاره را از سرورهای فعال دریافت می‌کند.

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

name - نام یکتایی را برای کارساز مشخص می‌کند.
  • url - نشانی URL مورد استفاده برای برقراری ارتباط با این کارساز از طریق کانال کنترلی را مشخص می‌کند. سایر کارسازها از این URL برای ارسال دستورهای کنترلی به این کارساز استفاده می‌کنند.
  • basic-auth-user - شناسه کاربر (user ID) را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. اگر مشخص نشود یا به صورت یک رشته خالی تعیین شود، هیچ سرآیند احراز هویتی به تراکنش‌های HTTP افزوده نمی‌شود. این مقدار نباید شامل نویسه دونقطه (:) باشد.
  • basic-auth-user-file - جایگزینی برای basic-auth-user است: به جای درج شناسه کاربر در فایل پیکربندی، این شناسه در سطر نخست فایل مشخص‌شده توسط این پارامتر تعیین می‌شود.
  • basic-auth-password - گذرواژه را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. هنگامی که شناسه کاربر مشخص نشده باشد یا خالی باشد، این پارامتر نادیده گرفته می‌شود. گذرواژه اختیاری است؛ اگر مشخص نشود، یک گذرواژه خالی استفاده می‌شود.
  • basic-auth-password-file - جایگزینی برای basic-auth-password است: به جای درج گذرواژه در فایل پیکربندی، این گذرواژه در سطر نخست فایل مشخص‌شده توسط این پارامتر تعیین می‌شود.
  • role - نقش کارساز را در ساختار HA مشخص می‌کند. نقش‌های زیر در پیکربندی load-balancing پشتیبانی می‌شوند: primary، secondary و backup. در ساختار load-balancing باید دقیقاً یک کارساز primary و یک کارساز secondary وجود داشته باشد.
  • auto-failover - مقداری بولی است که تعیین می‌کند آیا کارسازی که از کار افتادن همتای خود را تشخیص می‌دهد، باید به صورت خودکار شروع به پاسخ‌گویی به کلاینت‌های همتا کند یا خیر. مقدار پیش‌فرض این پارامتر true است.

در پیکربندی نمونه ما در بالا، هر دو کارساز فعال می‌توانند اجاره‌ها (leases) را از زیرشبکه "192.0.3.0/24" تخصیص دهند. این زیرشبکه شامل دو استخر آدرس است: "192.0.3.100 - 192.0.3.150" و "192.0.3.200 - 192.0.3.250" که با استفاده از رده‌بندی کلاینت به دامنه‌های کارساز HA مرتبط شده‌اند. هنگامی که server1 یک پرس‌وجوی DHCP را پردازش می‌کند، از استخر نخست برای تخصیص اجاره استفاده می‌نماید. در مقابل، هنگامی که server2 یک پرس‌وجوی DHCP را پردازش می‌کند، از استخر دوم استفاده می‌کند. اگر هر یک از کارسازها در وضعیت partner-down باشد، دیگری می‌تواند اجاره‌ها را از هر دو استخر ارائه دهد؛ و استخری را انتخاب می‌کند که برای پرس‌وجوی دریافت‌شده مناسب باشد. به بیان دیگر، اگر پرس‌وجو در حالت عادی توسط server2 پردازش می‌شد اما این کارساز در دسترس نباشد، server1 اجاره را از استخر "192.0.3.200 - 192.0.3.250" تخصیص می‌دهد. سوکت کنترلی HTTP مربوط به server3` نیازمند احراز هویت پایه‌ای HTTP است و شناسه کاربر "foo" را با گذرواژه "1234" مجاز می‌شناسد.

نکته:

طرح‌واره url می‌تواند http یا https باشد، اما از نسخه 1.9.6 نرم‌افزار Kea طرح‌واره https نیازمند راه‌اندازی TLS است. بخش نام میزبان باید یک آدرس IPv4 یا یک آدرس IPv6 داخل کروشه باشد، مانند http://[2001:db8::1]:8080. نام‌ها پذیرفته نمی‌شوند.

در بخش پیشین، مثالی از پیکربندی load-balancing با رده‌بندی کلاینت محدود به کلاس‌های "HA_server1" و "HA_server2" ارائه دادیم که به صورت پویا به پرس‌وجوهای DHCP دریافتی اختصاص می‌یابند. در بسیاری از موارد، HA در استقرارهایی مورد نیاز است که از پیش از رده‌بندی‌های کلاینت دیگری استفاده می‌کنند.

سیستمی را فرض کنید که دستگاه‌ها را بر اساس معیارهای رده‌بندی مشخص‌شده در فایل پیکربندی Kea به دو گروه دسته‌بندی می‌کند: "phones" و "laptops". به هر دو نوع دستگاه از استخرهای آدرس متفاوتی اجاره تخصیص داده می‌شود. اضافه کردن HA در حالت load-balancing منجر به تقسیم بیشتر هر یک از این استخرها می‌شود، چرا که هر کارساز اجاره‌ها را برای برخی گوشی‌ها و برخی لپ‌تاپ‌ها تخصیص می‌دهد. این موضوع نیازمند آن است که هر یک از استخرهای موجود بین "HA_server1" و "HA_server2" تقسیم شوند، بنابراین در نهایت کلاس‌های زیر را خواهیم داشت:

  • "phones_server1"
  • "laptops_server1"
  • "phones_server2"
  • "laptops_server2"

پیکربندی متناظر کارساز با استفاده از رده‌بندی پیشرفته (و عبارت member) در زیر آورده شده است. به منظور اختصار، پیکربندی کتابخانه قلاب HA از این مثال حذف شده است.

{
  "Dhcp4": {
    "client-classes": [{
        "name": "phones",
        "test": "substring(option[60].hex,0,6) == 'Aastra'"
    }, {
        "name": "laptops",
        "test": "not member('phones')"
    }, {
        "name": "phones_server1",
        "test": "member('phones') and member('HA_server1')"
    }, {
        "name": "phones_server2",
        "test": "member('phones') and member('HA_server2')"
    }, {
        "name": "laptops_server1",
        "test": "member('laptops') and member('HA_server1')"
    }, {
        "name": "laptops_server2",
        "test": "member('laptops') and member('HA_server2')"
    }],
    "hooks-libraries": [{
        "library": "libdhcp_lease_cmds.so",
        "parameters": { }
    }, {
        "library": "libdhcp_ha.so",
        "parameters": {
            "high-availability": [{
            }]
        }
    }],
    "subnet4": [{
        "id": 1,
        "subnet": "192.0.3.0/24",
        "pools": [{
            "pool": "192.0.3.100 - 192.0.3.125",
            "client-classes": [ "phones_server1" ]
        }, {
            "pool": "192.0.3.126 - 192.0.3.150",
            "client-classes": [ "laptops_server1" ]
        }, {
            "pool": "192.0.3.200 - 192.0.3.225",
            "client-classes": [ "phones_server2" ]
        }, {
            "pool": "192.0.3.226 - 192.0.3.250",
            "client-classes": [ "laptops_server2" ]
        }],
        "option-data": [{
            "name": "routers",
            "data": "192.0.3.1"
        }],
        "relay": { "ip-address": "10.1.2.3" }
    }]
  }
}

پیکربندی ارائه‌شده در بالا، محدوده نشانی را به چهار استخر تقسیم می‌کند: دو استخر اختصاص‌یافته به "HA_server1" و دو استخر به "HA_server2". هر کارساز می‌تواند اجاره‌ها را به هر دو گروه گوشی‌ها و لپ‌تاپ‌ها اختصاص دهد. به هر دو گروه دستگاه‌ها از استخرهای متفاوتی نشانی تخصیص داده می‌شود. کلاس‌های "HA_server1" و "HA_server2" توکار (built-in) هستند (بخش «کلاس‌های توکار کلاینت» (Built-in Client Classes) <#built-in-client-classes> را ببینید) و نیازی به تعریف آن‌ها نیست. آن‌ها به صورت پویا توسط کتابخانه قلاب HA بر اساس الگوریتم load-balancing تخصیص می‌یابند. هنگامی که پرس‌وجو متعلق به ترکیب معینی از سایر کلاس‌ها باشد، مانند "HA_server1" و "phones"، عبارت‌های "phones_*" و "laptop_*" به true ارزیابی می‌شوند. استخر نیز بر اساس نتیجه چنین ارزیابی‌ای انتخاب می‌گردد.

برای آگاهی از جزئیات چگونگی استفاده از عبارت member و وابستگی‌های کلاس، به «رده‌بندی کلاینت» (Client Classification) <#classify> مراجعه کنید..SS پیکربندی Hot-Standby

در ادامه نمونه‌ای از پیکربندی سرور اصلی (primary) در پیکربندی hot-standby آورده شده است:

"Dhcp4": {
    "hooks-libraries": [{
        "library": "libdhcp_lease_cmds.so",
        "parameters": { }
    }, {
        "library": "libdhcp_ha.so",
        "parameters": {
            "high-availability": [{
                "this-server-name": "server1",
                "mode": "hot-standby",
                "heartbeat-delay": 10000,
                "max-response-delay": 60000,
                "max-ack-delay": 5000,
                "max-unacked-clients": 5,
                "max-rejected-lease-updates": 10,
                "peers": [{
                    "name": "server1",
                    "url": "http://192.168.56.33:8005/",
                    "role": "primary",
                    "auto-failover": true
                }, {
                    "name": "server2",
                    "url": "http://192.168.56.66:8005/",
                    "role": "standby",
                    "auto-failover": true
                }, {
                    "name": "server3",
                    "url": "http://192.168.56.99:8005/",
                    "basic-auth-user": "foo",
                    "basic-auth-password": "1234",
                    "role": "backup",
                    "auto-failover": false
                }]
            }]
        }
    }],
    "subnet4": [{
        "id": 1,
        "subnet": "192.0.3.0/24",
        "pools": [{
            "pool": "192.0.3.100 - 192.0.3.250",
            "client-classes": [ "HA_server1" ]
        }],
        "option-data": [{
            "name": "routers",
            "data": "192.0.3.1"
        }],
        "relay": { "ip-address": "10.1.2.3" }
    }]
}

این پیکربندی شباهت بسیاری به پیکربندی load-balancing شرح داده شده در «پیکربندی Load-Balancing» دارد، با چند تفاوت قابل توجه.

پارامتر mode اکنون روی hot-standby تنظیم شده است که در آن تنها یک سرور به کلاینت‌های DHCP پاسخ می‌دهد. اگر سرور اصلی (primary) برخط باشد، به تمام درخواست‌های DHCP پاسخ می‌دهد. سرور standby تنها در صورتی تمام ترافیک DHCP را بر عهده می‌گیرد که متوجه در دسترس نبودن سرور اصلی شود.

در این حالت، سرور فعال غیر اصلی (non-primary) standby نامیده می‌شود و نقش آن نیز همین است.

در نهایت، از آنجا که همواره تنها یک سرور به پرس‌وجوهای DHCP پاسخ می‌دهد، تنها یک محدوده - "HA_server1" - درون تعاریف pool استفاده می‌شود. در واقع، پارامتر client-class را می‌توان بدون مشکل از این پیکربندی حذف کرد، زیرا با توجه به اینکه سرورها به صورت هم‌زمان اجاره‌ها را تخصیص نمی‌دهند، هیچ تداخلی در تخصیص اجاره‌ها توسط سرورهای مختلف رخ نخواهد داد. پارامتر client-class در این مثال بیشتر به منظور نمایش و برجسته کردن تفاوت‌های بین حالت‌های عملیاتی hot-standby و load-balancing باقی مانده است.

در ادامه نمونه‌ای از فایل پیکربندی برای سرور اصلی در پیکربندی passive-backup آمده است:

{
  "Dhcp4": {
    "hooks-libraries": [{
        "library": "libdhcp_lease_cmds.so",
        "parameters": { }
    }, {
        "library": "libdhcp_ha.so",
        "parameters": {
            "high-availability": [{
                "this-server-name": "server1",
                "mode": "passive-backup",
                "wait-backup-ack": false,
                "peers": [{
                    "name": "server1",
                    "url": "http://192.168.56.33:8005/",
                    "role": "primary"
                }, {
                    "name": "server2",
                    "url": "http://192.168.56.66:8005/",
                    "role": "backup"
                }, {
                    "name": "server3",
                    "url": "http://192.168.56.99:8005/",
                    "basic-auth-user": "foo",
                    "basic-auth-password": "1234",
                    "role": "backup"
                }]
            }]
        }
    }],
    "subnet4": [{
        "id": 1,
        "subnet": "192.0.3.0/24",
        "pools": [{
            "pool": "192.0.3.100 - 192.0.3.250"
        }],
        "option-data": [{
            "name": "routers",
            "data": "192.0.3.1"
        }],
        "relay": { "ip-address": "10.1.2.3" }
    }]
  }
}

پیکربندی‌های سه همتا (peer) گنجانده شده است: یکی برای سرور اصلی (primary) و دو تا برای سرورهای پشتیبان (backup).

بسیاری از پارامترهای موجود در مثال‌های پیکربندی load-balancing و hot-standby در حالت passive-backup کاربردی ندارند، بنابراین در اینجا مشخص نشده‌اند. به عنوان مثال: heartbeat-delay، max-unacked-clients، max-rejected-lease-updates و موارد دیگری که به سازوکار failover مربوط می‌شوند، نباید در حالت passive-backup مشخص شوند.

پارامتر wait-backup-ack یک پارامتر بولی (boolean) است که در مثال‌های قبلی وجود نداشت. مقدار پیش‌فرض آن false است و نباید در حالت‌های load-balancing و hot-standby تغییر داده شود. در حالت passive-backup این پارامتر می‌تواند روی true تنظیم شود، که باعث می‌شود سرور اصلی قبل از پاسخ دادن به کلاینت DHCP، منتظر دریافت تأییدیه‌ها (acknowledgments) برای به‌روزرسانی‌های اجاره از سرورهای پشتیبان باشد. این کار تضمین می‌کند که اجاره قبل از اعطا به کلاینت در تمام سرورها منتشر شده است، اما در صورت بروز مشکل ارتباطی با یکی از سرورهای پشتیبان، خطر از دست رفتن سرویس DHCP را به همراه دارد. این تنظیم همچنین به دلیل زمانی که سرور اصلی صرف انتظار برای تأییدیه‌ها می‌کند، تأخیر (latency) پاسخ DHCP را افزایش می‌دهد. توصیه می‌کنیم در صورتی که قابلیت اطمینان سرویس DHCP از یکپارچگی اطلاعات اجاره بین سرور اصلی و سرورهای پشتیبان مهم‌تر است، و در تمام مواردی که تأخیر سرویس DHCP باید حداقل باشد، تنظیم wait-backup-ack روی مقدار پیش‌فرض خود (false) باقی بماند.

نکته:

در حال حاضر، سرورهای فعال به‌روزرسانی‌های اجاره را برای ارسال به همتاها در صف‌های داخلی قرار می‌دهند (یک صف برای هر همتا/URL). در حالت passive-backup، سرورهای فعال منتظر تأیید به‌روزرسانی‌های اجاره نمی‌مانند؛ بنابراین در زمان‌های ترافیک سنگین کلاینت‌ها، این احتمال وجود دارد که تعداد به‌روزرسانی‌های اجاره در صف ارسال سریع‌تر از توان تحویل آنها انباشته شود. با کاهش ترافیک کلاینت، صف‌ها شروع به خالی شدن می‌کنند. از نسخه Kea 2.0.0 به بعد، سرورهای فعال اندازه این صف‌ها را پایش می‌کنند و اگر تشخیص دهند که صفی بیش از حد سریع رشد می‌کند، هشدارهای دوره‌ای صادر می‌کنند (به HTTP_CLIENT_QUEUE_SIZE_GROWING در Kea Messages Manual <#kea-messages> مراجعه کنید). این هشدارها به محض شروع کوچک شدن صف متوقف می‌شوند. این پیام‌ها به عنوان یک شاخص پیش‌آگاهی در نظر گرفته شده‌اند و مشاهده گاه‌به‌گاه آن‌ها در زمان بار ترافیکی سنگین لزوماً نشان‌دهنده مشکل نیست. با این حال، اگر این هشدارها به طور مداوم در شرایط بار ترافیکی معمول رخ دهند، به احتمال زیاد نشان‌دهنده عدم تطابق در توانایی‌های سرور و/یا پیکربندی آن هستند؛ این موضوع باید بررسی شود، زیرا اندازه صف‌ها در نهایت ممکن است توانایی سرور فعال را در پاسخ‌گویی به موقع به کلاینت‌ها مختل کند.

یک سرور مجهز به HA با ارسال دستورات کنترلی مناسب، شریک فعال خود را از اجاره‌های تخصیص‌یافته یا تمدیدشده مطلع می‌سازد، و شریک نیز اطلاعات اجاره را در پایگاه داده خود به‌روزرسانی می‌کند. هنگامی که سرور برای نخستین بار راه‌اندازی می‌شود یا پس از یک خرابی بازیابی می‌گردد، پایگاه داده اجاره‌های خود را با شریکش همگام‌سازی می‌کند. این دو سازوکار، سازگاری اطلاعات اجاره میان سرورها را تضمین کرده و اجازه می‌دهند در صورت از دسترس خارج شدن یکی از سرورها، سرور دیگر کل بار ترافیک DHCP را مدیریت کند.

با این حال در برخی موارد، چنانچه تبادل اطلاعات درباره اجاره‌های تخصیص‌یافته با استفاده از سازوکار دیگری انجام گیرد، غیرفعال کردن به‌روزرسانی‌های اجاره و/یا همگام‌سازی پایگاه داده میان سرورهای فعال مطلوب خواهد بود. Kea از انواع مختلف پایگاه‌های داده که می‌توانند برای ذخیره اجاره‌ها استفاده شوند، از جمله MySQL و PostgreSQL پشتیبانی می‌کند. این پایگاه‌های داده شامل راهکارهای توکار برای تکثیر داده‌ها (data replication) هستند که اغلب توسط مدیران Kea جهت فراهم آوردن افزونگی (redundancy) به کار گرفته می‌شوند.

کتابخانه قلاب HA از چنین سناریوهایی با غیرفعال کردن به‌روزرسانی‌های اجاره از طریق کانال کنترلی و/یا همگام‌سازی پایگاه داده اجاره پشتیبانی می‌کند و سرور را بر سازوکار تکثیر پایگاه داده متکی می‌سازد. این رفتار توسط دو پارامتر بولی send-lease-updates و sync-leases کنترل می‌شود که مقادیر پیش‌فرض آن‌ها true است:

"Dhcp4": {
    "hooks-libraries": [
        {
            "library": "libdhcp_lease_cmds.so",
            "parameters": { }
        },
        {
            "library": "libdhcp_ha.so",
            "parameters": {
                "high-availability": [ {
                    "this-server-name": "server1",
                    "mode": "load-balancing",
                    "send-lease-updates": false,
                    "sync-leases": false,
                    "peers": [
                        {
                            "name": "server1",
                            "url": "http://192.168.56.33:8005/",
                            "role": "primary"
                        },
                        {
                            "name": "server2",
                            "url": "http://192.168.56.66:8005/",
                            "role": "secondary"
                        }
                    ]
                } ]
            }
        }
    ],
    ...
}

در متداول‌ترین حالت استفاده، هر دو پارامتر روی یک مقدار یکسان تنظیم می‌شوند؛ یعنی در صورت استفاده از تکثیر پایگاه داده هر دو روی false و در غیر این صورت هر دو روی true قرار می‌گیرند. معرفی دو پارامتر مجزا برای کنترل به‌روزرسانی‌های اجاره و همگام‌سازی پایگاه داده اجاره، با هدف پشتیبانی از موارد استفاده خاص صورت گرفته است؛ به عنوان مثال، زمانی که همگام‌سازی با کپی کردن یک فایل اجاره انجام می‌شود (بنابراین sync-leases روی false تنظیم می‌گردد)، اما به‌روزرسانی‌های اجاره باید طبق روال عادی ارسال شوند (send-lease-updates روی true تنظیم می‌شود). لازم به ذکر است که Kea به‌صورت توکار از چنین مواردی پشتیبانی نمی‌کند، اما کاربران می‌توانند اسکریپت‌ها و ابزارهای اختصاصی خود را پیرامون Kea توسعه دهند تا چنین سازوکارهایی فراهم شود. پیکربندی کتابخانه قلاب HA طوری طراحی شده است که انعطاف‌پذیری مدیریت را به حداکثر برساند.

یک سرور مجهز به HA، پس از توقف فعالیت یا پس از دریافت دستور ha-sync، همگام‌سازی پایگاه داده اجاره را آغاز می‌کند. سرور از دستورات lease4-get-page و lease6-get-page برای واکشی اجاره‌ها از سرور شریک خود استفاده می‌کند (پرس‌وجوهای اجاره). اندازه صفحه نتایج (حداکثر تعداد اجاره‌هایی که در یک پاسخ واحد به یکی از این دستورات بازگردانده می‌شوند) از طریق پیکربندی کتابخانه قلاب HA قابل کنترل است. افزایش اندازه صفحه، تعداد پرس‌وجوهای اجاره ارسالی به سرور شریک را کاهش می‌دهد، اما باعث می‌شود سرور شریک پاسخ‌های حجیم‌تری تولید کند که موجب افزایش زمان انتقال و همچنین افزایش مصرف حافظه و CPU در هر دو سرور می‌گردد. کاهش اندازه صفحه به کاهش مصرف منابع کمک می‌کند، اما نیازمند ارسال پرس‌وجوهای اجاره بیشتری جهت واکشی کل پایگاه داده اجاره است.

مقدار پیش‌فرض دستور sync-page-limit که اندازه صفحه را کنترل می‌کند 10000 است. این بدان معناست که اگر اندازه پایگاه داده برابر یا کمتر از 10000 خط باشد، کل پایگاه داده اجاره می‌تواند با یک دستور واحد واکشی شود.

در استقرارهایی با تعداد زیادی کلاینت متصل به شبکه، همگام‌سازی پایگاه داده اجاره پس از خرابی یک سرور ممکن است عملیاتی زمان‌بر باشد. سرور همگام‌ساز باید تمام اجاره‌ها را از شریک خود جمع‌آوری کند که پاسخی بزرگ را از طریق رابط RESTful به همراه دارد. سرور، اجاره‌ها را با استفاده از سازوکار صفحه‌بندی توضیح داده شده در «کنترل حد اندازه صفحه اجاره» دریافت می‌کند. پیش از واکشی صفحه اجاره‌ها، سرور همگام‌ساز دستور dhcp-disable <#std-isccmd-dhcp-disable> را برای غیرفعال کردن سرویس DHCP در سرور شریک ارسال می‌کند. اگر این سرویس از قبل غیرفعال باشد، این دستور مهلت زمانی غیرفعال بودن سرویس DHCP را بازنشانی می‌کند که به‌طور پیش‌فرض روی 60 ثانیه تنظیم شده است. اگر واکشی یک صفحه واحد از اجاره‌ها بیش از زمان تعیین‌شده طول بکشد، سرور شریک فرض می‌کند که سرور همگام‌ساز از کار افتاده است و سرویس DHCP خود را از سر می‌گیرد. اتصال سرور همگام‌ساز با شریک خود نیز توسط مهلت زمانی محافظت می‌شود. اگر همگام‌سازی یک صفحه از اجاره‌ها بیشتر از زمان مشخص‌شده به طول بینجامد، سرور همگام‌ساز اتصال را قطع کرده و همگام‌سازی با شکست مواجه می‌شود. هر دو مقدار مهلت زمانی توسط یک پارامتر پیکربندی واحد به نام sync-timeout کنترل می‌شوند. قطعه‌پیکربندی زیر نحوه اصلاح مهلت زمانی برای فعال‌سازی مجدد خودکار سرویس DHCP در سرور شریک و نحوه افزایش مهلت زمانی برای واکشی یک صفحه از اجاره‌ها از 60 ثانیه به 90 ثانیه را نشان می‌دهد:

"Dhcp4": {
    "hooks-libraries": [
        {
            "library": "libdhcp_lease_cmds.so",
            "parameters": { }
        },
        {
            "library": "libdhcp_ha.so",
            "parameters": {
                "high-availability": [ {
                    "this-server-name": "server1",
                    "mode": "load-balancing",
                    "sync-timeout": 90000,
                    "peers": [
                        {
                            "name": "server1",
                            "url": "http://192.168.56.33:8005/",
                            "role": "primary"
                        },
                        {
                            "name": "server2",
                            "url": "http://192.168.56.66:8005/",
                            "role": "secondary"
                        }
                    ]
                } ]
            }
        }
    ],
    ...
}

توجه به این نکته مهم است که افزایش این مقدار sync-timeout ممکن است گاهی اوقات برای جلوگیری از بروز مشکلات مهلت زمانی در حین همگام‌سازی پایگاه داده اجاره کافی نباشد. سرور DHCP همچنین اتصال از سمت همتا را برای بررسی مهلت‌های زمانی زیر نظر می‌گیرد. این مهلت‌های زمانی در حال حاضر از طریق پیکربندی قابل تغییر نیستند؛ افزایش این مهلت‌های زمانی تنها با اصلاح آن‌ها در کد Kea و کامپایل مجدد سرور امکان‌پذیر است. ثابت‌های مربوطه در سورس Kea در مسیر src/lib/config/timeouts.h قرار دارند..SS توقف موقت ماشین وضعیت HA

ماشین وضعیت high-availability شامل وضعیت‌های مختلف بسیاری است که با جزئیات در Server States شرح داده شده‌اند. کارساز هنگامی وارد هر وضعیت می‌شود که شرایط خاصی برآورده شوند، که اغلب اوقات وضعیت کارساز همکار را نیز در نظر می‌گیرد. در برخی وضعیت‌ها کارساز اقدامات خاصی انجام می‌دهد؛ برای مثال، همگام‌سازی پایگاه‌داده واگذاری‌ها در وضعیت syncing، یا پاسخ‌گویی به پرس‌وجوهای DHCP مطابق با حالت عملیاتی پیکربندی‌شده در وضعیت‌های load-balancing و hot-standby.

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

خرابی کارسازی را در نظر بگیرید که منجر به از دست رفتن کل پایگاه‌داده واگذاری‌ها می‌شود. به‌طور معمول، کارساز با استعلام واگذاری‌ها از کارساز همکار به هنگام ورود به وضعیت syncing، پایگاه‌داده واگذاری‌های خود را بازسازی می‌کند، اما این احتمال وجود دارد که همکار نیز دچار خرابی شده و فاقد اطلاعات واگذاری باشد. در این حالت، ممکن است نیاز باشد پایگاه‌داده واگذاری‌ها در هر دو کارساز از یک منبع خارجی، مانند یک کارساز پشتیبان، بازسازی شود. اگر قرار است پایگاه‌داده واگذاری‌ها از طریق RESTful API بازسازی شود، کارسازها باید در وضعیت اولیه، یعنی waiting، راه‌اندازی شوند و در حین افزودن واگذاری‌ها در همین وضعیت باقی بمانند. به‌ویژه، کارسازها نباید برای همگام‌سازی پایگاه‌داده واگذاری‌های خود تلاشی کنند و نباید سرویس‌دهی به کلاینت‌های DHCP را آغاز نمایند.

کتابخانه قلاب HA پارامترهای پیکربندی و دستوری را برای کنترل توقف موقت و ازسرگیری ماشین وضعیت HA فراهم می‌کند. پیکربندی زیر باعث می‌شود که ماشین وضعیت HA پس از راه‌اندازی کارساز در وضعیت waiting متوقف شود.

"Dhcp4": {
    "hooks-libraries": [
        {
            "library": "libdhcp_lease_cmds.so",
            "parameters": { }
        },
        {
            "library": "libdhcp_ha.so",
            "parameters": {
                "high-availability": [ {
                    "this-server-name": "server1",
                    "mode": "load-balancing",
                    "peers": [
                        {
                            "name": "server1",
                            "url": "http://192.168.56.33:8005/",
                            "role": "primary"
                        },
                        {
                            "name": "server2",
                            "url": "http://192.168.56.66:8005/",
                            "role": "secondary"
                        }
                    ],
                    "state-machine": {
                        "states": [
                            {
                                "state": "waiting",
                                "pause": "once"
                            }
                        ]
                    }
                } ]
            }
        }
    ],
    ...
}

مقدار once برای پارامتر pause نشان می‌دهد که ماشین وضعیت باید در نخستین گذار به وضعیت waiting متوقف شود؛ گذارهای بعدی به این وضعیت موجب توقف ماشین وضعیت نخواهند شد. دو مقدار پشتیبانی‌شده دیگر برای پارامتر pause مقادیر always و never هستند. مقدار اخیر مقدار پیش‌فرض برای هر وضعیت است که به کارساز دستور می‌دهد هرگز ماشین وضعیت را متوقف نکند.

به منظور خروج ماشین وضعیت از حالت توقف، باید دستور ha-continue به کارساز متوقف‌شده ارسال شود. این دستور هیچ آرگومانی نمی‌پذیرد. برای جزئیات درباره دستورهای ویژه libdhcp_ha.so به Control Commands for High Availability مراجعه کنید.

پیکربندی ماشین وضعیت برای توقف در بیش از یک وضعیت امکان‌پذیر است. پیکربندی زیر را در نظر بگیرید:

"Dhcp4": {
    "hooks-libraries": [
        {
            "library": "libdhcp_lease_cmds.so",
            "parameters": { }
        },
        {
            "library": "libdhcp_ha.so",
            "parameters": {
                "high-availability": [ {
                    "this-server-name": "server1",
                    "mode": "load-balancing",
                    "peers": [
                        {
                            "name": "server1",
                            "url": "http://192.168.56.33:8005/",
                            "role": "primary"
                        },
                        {
                            "name": "server2",
                            "url": "http://192.168.56.66:8005/",
                            "role": "secondary"
                        }
                    ],
                    "state-machine": {
                        "states": [
                            {
                                "state": "ready",
                                "pause": "always"
                            },
                            {
                                "state": "partner-down",
                                "pause": "once"
                            }
                        ]
                    }
                } ]
            }
        }
    ],
    ...
}

این پیکربندی به کارساز دستور می‌دهد که هر بار پس از گذار به وضعیت ready و همچنین در نخستین گذار به وضعیت partner-down، ماشین وضعیت را متوقف کند.

برای مشاهده فهرست کامل وضعیت‌های کارساز به Server States مراجعه کنید. ماشین وضعیت را می‌توان در هر یک از وضعیت‌های پشتیبانی‌شده متوقف کرد؛ با این حال، متوقف کردن در وضعیت‌های backup یا terminated کاربردی ندارد، زیرا کارساز در هر صورت هرگز از این وضعیت‌ها خارج نمی‌شود.

نکته:

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

نکته:

وضعیت ماشین وضعیت HA به وضعیت کارساز همکار وابسته است. بنابراین، متوقف کردن ماشین وضعیت یک کارساز ممکن است بر عملکرد کارساز همکار تأثیر بگذارد. برای مثال: اگر کارساز اصلی در وضعیت waiting متوقف شود، کارساز همکار نیز تا زمانی که ماشین وضعیت کارساز اصلی از سر گرفته نشده و آن کارساز به وضعیت ready گذار نکند، در وضعیت waiting باقی خواهد ماند.

امکان پیکربندی HA برای استفاده از ارتباط مستقیم چندنخی بین همتایان (peers) وجود دارد. ما این حالت را HA+MT می‌نامیم. با فعال بودن HA+MT، هر همتا شنونده (کارساز) HTTP اختصاصی و داخلی خود را اجرا می‌کند که مستقیماً دستورها را دریافت کرده و به آن‌ها پاسخ می‌دهد؛ بنابراین ترتیبی بودن پردازش دستورها از جمله برای پروتکل HA میان همتایان حذف می‌شود. افزون بر این، هر دو جزء شنونده و کلاینت از چندنخی برای پشتیبانی از چندین اتصال هم‌روند میان همتایان استفاده می‌کنند. با حذف بار اضافی از کانال کنترلی و اجرای موازی مبادلات چندگانه دستورها، توان عملیاتی HA بین همتایان در بیشتر شرایط در مقایسه با نسخه‌های پیشین Kea به طور چشمگیری بهبود می‌یابد.

پارامترهای زیر برای پشتیبانی از عملکرد HA+MT به پیکربندی HA افزوده شده‌اند:

  • enable-multi-threading - ارتباط چندنخی همتایان HA‏ (HA+MT) را فعال یا غیرفعال می‌کند. برای عملکرد HA+MT، قابلیت چندنخی در هسته Kea باید فعال باشد. هنگامی که روی false باشد، کارساز برای ارتباط با همتای خود به یک سوکت کنترلی HTTP متکی خواهد بود و از پردازش کلاینت HTTP تک‌نخی استفاده می‌کند. مقدار پیش‌فرض true است.
  • http-dedicated-listener - ایجاد یک شنونده HTTP داخلی و اختصاصی را که کارساز از طریق آن پیام‌های HA را از همتایان خود دریافت می‌کند، فعال یا غیرفعال می‌کند. شنونده داخلی جایگزین ترافیک سوکت کنترلی می‌شود و به همتایان اجازه می‌دهد دستورهای HA خود را مستقیماً برای یکدیگر ارسال کنند. شنونده روی url متعلق به همتا به شنود می‌پردازد. در صورت تنظیم روی false، کارساز به سوکت کنترلی HTTP متکی می‌شود. این پارامتر عمدتاً برای انعطاف‌پذیری و آزمون ارائه شده است؛ اجرای HA+MT بدون فعال بودن شنونده‌های اختصاصی، توان عملیاتی HA را به شدت محدود خواهد کرد. مقدار پیش‌فرض true است.
  • http-listener-threads - حداکثر تعداد نخ‌هایی را که شنونده اختصاصی باید استفاده کند مشخص می‌کند. مقدار 0 به کارساز دستور می‌دهد از همان تعداد نخ‌هایی استفاده کند که هسته Kea برای چندنخی DHCP به کار می‌برد. مقدار پیش‌فرض 0 است.
  • http-client-threads - حداکثر تعداد نخ‌هایی را که باید برای ارسال پیام‌های HA به همتایان استفاده شود، مشخص می‌کند. مقدار 0 به کارساز دستور می‌دهد از همان تعداد نخ‌هایی استفاده کند که هسته Kea برای چندنخی DHCP به کار می‌برد. مقدار پیش‌فرض 0 است.

این پارامترها همان‌طور که در زیر نشان داده شده است، در قالب یک عنصر نگاشت با نام multi-threading با یکدیگر گروه‌بندی می‌شوند:

"Dhcp4": {
    "hooks-libraries": [
        {
            "library": "libdhcp_lease_cmds.so",
            "parameters": { }
        },
        {
            "library": "libdhcp_ha.so",
            "parameters": {
                "high-availability": [ {
                    "this-server-name": "server1",
                    "multi-threading": {
                        "enable-multi-threading": true,
                        "http-dedicated-listener": true,
                        "http-listener-threads": 4,
                        "http-client-threads": 4
                    },
                    "peers": [
                      // This is the configuration of this server instance.
                      {
                          "name": "server1",
                          // This specifies the URL of our server instance.
                          // Since the HA+MT uses a direct connection, the
                          // DHCPv4 server open its own socket. Note that it
                          // must be different than the one used by the control
                          // socket (typically 8000). In this example, 8005 is used.
                          "url": "http://192.0.2.1:8005/",
                          // This server is primary. The other one must be
                          // secondary.
                          "role": "primary"
                      },
                      // This is the configuration of our HA peer.
                      {
                          "name": "server2",
                          // This specifies the URL of our server instance.
                          // Since the HA+MT uses a direct connection, the
                          // DHCPv4 server open its own socket. Note that it
                          // must be different than the one used by the control
                          // socket (typically 8000). In this example, 8005 is used.
                          "url": "http://192.0.2.2:8005/",
                          // The partner is a secondary. This server is a
                          // primary as specified in the previous "peers"
                          // entry and in "this-server-name" before that.
                          "role": "secondary"
                      },
                      ...
                    ],
                    ...
                },
                ...
                ]
            }
        },
        ...
    ],
    ...
}

در مثال بالا، HA+MT با چهار نخ برای شنونده و چهار نخ برای کلاینت فعال شده است.

نکته:

پیکربندی درست پورت‌ها امری حیاتی است. یک اشتباه رایج، پیکربندی سوکت کنترلی برای شنود روی پورت 8000 و همچنین تنظیم شنونده‌های اختصاصی روی پورت 8000 است. در چنین پیکربندی، ارتباط همچنان از طریق سوکت کنترلی (در حالت تک‌نخی) کار خواهد کرد، اما کُند خواهد بود و کارساز DHCP در مقیدسازی سوکت‌ها (در حالت چندنخی) با شکست مواجه خواهد شد. مدیران سیستم باید اطمینان حاصل کنند که شنونده‌های اختصاصی از پورت دیگری استفاده می‌کنند (8001 یک جایگزین پیشنهادی است)؛ در صورتی که پورت‌ها نادرست پیکربندی شوند یا از پورت‌های اختصاص‌یافته به سوکت کنترلی استفاده شود، گلوگاه‌های کارایی ناشی از حالت تک‌نخی کارساز DHCP یا ماهیت ترتیبی سوکت کنترلی کارسازهای DHCP، هرگونه بهبود کارایی حاصل از HA+MT را بی‌اثر خواهند کرد.

برای آشنایی مقدماتی با پارک کردن بسته‌ها، به «محدودیت بسته‌های پارک‌شده» مراجعه کنید.

کتابخانه قلاب HA از این سازوکار استفاده می‌کند. هنگامی که یک سرور HA نیاز دارد یک به‌روزرسانی اجاره را برای همتایان خود ارسال کند تا آن‌ها را از تغییرات اجاره مطلع سازد، پاسخ به کلاینت را تا زمانی که همتایان به‌روزرسانی اجاره را تایید کنند، پارک می‌کند. در آن هنگام، سرور پاسخ را از حالت پارک خارج کرده و آن را به کلاینت ارسال می‌کند. این موضوع برای پرس‌وجوهای کلاینت که منجر به تغییرات اجاره می‌شوند اعمال می‌گردد، مانند DHCPREQUEST برای DHCPv4 و Request، Renew و Rebind برای DHCPv6. این سازوکار شامل DHCPDISCOVER (در نسخه ۴) یا Solicit (در نسخه ۶) نمی‌شود.

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

مشکل متداولی که در نسخه‌های اولیه کتابخانه قلاب High Availability گزارش شده بود این بود که مدیر سیستم کنترل مستقیمی بر وضعیت سرور DHCP نداشت. خاموش کردن یکی از سرورها برای نگهداری لزوماً باعث نمی‌شد که سرور دیگر شروع به پاسخ دادن به تمام پرس‌وجوهای DHCP کند؛ زیرا الگوریتم تشخیص خرابی توضیح‌داده‌شده در «انتقال حوزه در حالت از کار افتادن شریک» نیازمند این است که شریک برای یک بازه زمانی پیکربندی‌شده پاسخ ندهد و بسته به پیکربندی، ممکن است همچنین نیاز داشته باشد که به تعدادی از درخواست‌های DHCP برای بازه زمانی مشخصی پاسخ داده نشود. با این حال، روند نگهداری ایجاب می‌کند که مدیر سیستم بتواند به یکی از سرورها دستور دهد که بلافاصله سرویس‌دهی به تمام کلاینت‌های DHCP را آغاز کند و سرور دیگر بلافاصله سرویس‌دهی به کلاینت‌های DHCP را متوقف کند تا بتوان آن را با ایمنی خاموش کرد.

قابلیت نگهداری در کتابخانه قلاب High Availability به این وضعیت رسیدگی می‌کند. دستور ha-maintenance-start به مدیر سیستم امکان می‌دهد جفت سرورهای فعال را در وضعیتی قرار دهد که در آن یکی از آن‌ها به تمام پرس‌وجوهای DHCP پاسخ می‌دهد و دیگری منتظر خاموش شدن است.

فرض کنید راه‌اندازی HA شامل دو سرور فعال server1 و server2 است و سرور دوم باید برای نگهداری خاموش شود. مدیر سیستم می‌تواند دستور ha-maintenance-start را به server1 ارسال کند، زیرا این سروری است که قرار است ترافیک DHCP را در زمان آفلاین بودن دیگری مدیریت کند. اگر وضعیت server1 یا وضعیت شریک آن اجازه خاموش‌سازی برای نگهداری را ندهد، server1 با یک خطا پاسخ می‌دهد؛ برای مثال، اگر نگهداری برای سرور پشتیبان پشتیبانی نشود یا سرور در وضعیت terminated باشد. همچنین، اگر درخواست ha-maintenance-start پیش‌تر به سرور دیگر ارسال شده باشد، خطایی بازگردانده می‌شود.

با دریافت دستور ha-maintenance-start، server1 دستور ha-maintenance-notify را به server2 ارسال می‌کند تا آن را در وضعیت in-maintenance قرار دهد. اگر server2 تایید کند، server1 به وضعیت partner-in-maintenance تغییر وضعیت می‌دهد. این شبیه به وضعیت partner-down است، با این تفاوت که در وضعیت partner-in-maintenance سرور server1 تا زمانی که مدیر سیستم server2 را خاموش کند، به ارسال به‌روزرسانی‌های اجاره به server2 ادامه می‌دهد. اکنون server1 به تمام پرس‌وجوهای DHCP پاسخ می‌دهد.

اکنون مدیر سیستم می‌تواند با ایمنی server2 را در وضعیت in-maintenance خاموش کرده و اقدامات لازم برای نگهداری را انجام دهد. در حالی که server2 آفلاین است، بدیهی است که server1 قادر به برقراری ارتباط با شریک خود نخواهد بود، بنابراین بلافاصله به وضعیت partner-down منتقل می‌شود؛ این سرور همچنان به تمام پرس‌وجوهای DHCP پاسخ خواهد داد، اما دیگر به‌روزرسانی‌های اجاره را به server2 ارسال نمی‌کند. راه‌اندازی مجدد server2 پس از نگهداری، مذاکره عادی وضعیت، همگام‌سازی پایگاه‌داده اجاره‌ها و در نهایت گذار به وضعیت عادی load-balancing یا hot-standby را آغاز می‌کند. سپس می‌توان نگهداری را پس از ارسال دستور ha-maintenance-start به server2، روی server1 انجام داد.

اگر دستور ha-maintenance-start به سرور ارسال شده باشد و سرور به وضعیت partner-in-maintenance رفته باشد، بازگرداندن هر دوی آن و شریکش به وضعیت‌های قبلی‌شان به منظور از سرگیری عملکرد عادی جفت HA امکان‌پذیر است. این کار با ارسال دستور ha-maintenance-cancel به سروری که در وضعیت partner-in-maintenance قرار دارد انجام می‌شود. با این حال، اگر سرور در نتیجه تشخیص آفلاین بودن شریک، قبلاً به وضعیت partner-down تغییر وضعیت داده باشد، لغو نگهداری دیگر امکان‌پذیر نیست. در این حالت، لازم است سرور دیگر را دوباره راه‌اندازی کرده و اجازه داد فرایند عادی مذاکره وضعیت خود را تکمیل کند.

اگر سرور رابطه‌های متعددی با شرکای مختلف داشته باشد، دستور ha-maintenance-start تلاش می‌کند تا تمام این رابطه‌ها را با ارسال ha-maintenance-notify به همه سرورهای شریک، به وضعیت partner-in-maintenance انتقال دهد. اگر این مرحله برای هر یک از سرورها با شکست مواجه شود، خطایی بازگردانده می‌شود. در صورت وقوع این رویداد، می‌توان از دستور ha-maintenance-cancel برای از سرگیری عملکردهای عادی و رفع مشکل استفاده کرد.

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

در صورتی که هر دو سرور فعال از کار بیفتند، گاهی اوقات می‌توان از سرور پشتیبان برای رسیدگی به ترافیک DHCP استفاده کرد. سرور پشتیبان عمل جایگزینی خودکار (failover) را انجام نمی‌دهد؛ بنابراین، برای استفاده از سرور پشتیبان جهت پاسخ‌گویی به پرس‌وجوهای DHCP، مدیر سرور باید این تابع را به صورت دستی فعال کند.

بخش‌های زیر دستورهای پشتیبانی‌شده توسط کتابخانه قلاب HA را که در دسترس مدیر سیستم هستند، شرح می‌دهند.

دستور ha-sync به سرور فرمان می‌دهد که پایگاه‌داده محلی اجاره‌های خود را با همتای انتخابی همگام کند. سرور تمام اجاره‌ها را از همتا واکشی کرده و هرگونه اجاره محلی ذخیره‌شده را که قدیمی‌تر از موارد واکشی‌شده باشد، به‌روزرسانی می‌کند. همچنین در صورتی که هر یک از موارد واکشی‌شده در پایگاه‌داده محلی وجود نداشته باشد، اجاره‌های جدید ایجاد می‌کند. تمام اجاره‌هایی که توسط همتا بازگردانده نشده‌اند اما در پایگاه‌داده محلی موجود هستند، حفظ می‌شوند. همگام‌سازی پایگاه‌داده یک‌طرفه است؛ تنها پایگاه‌داده روی سروری که دستور به آن ارسال شده است به‌روزرسانی می‌شود. برای همگام‌سازی پایگاه‌داده همتا، باید یک دستور ha-sync جداگانه به آن همتا فرستاده شود.

همگام‌سازی پایگاه‌داده ممکن است برای هر دو نوع سرور فعال و پشتیبان اجرا شود. دستور ha-sync دارای ساختار زیر است (در یک مثال برای DHCPv4):

{
    "command": "ha-sync",
    "service": [ "dhcp4 "],
    "arguments": {
        "server-name": "server2",
        "max-period": 60
    }
}

هنگامی که سرور این دستور را دریافت می‌کند، ابتدا سرویس DHCP سروری را که قرار است اجاره‌ها از آن واکشی شوند، با ارسال دستور dhcp-disable <#std-isccmd-dhcp-disable> به آن سرور، غیرفعال می‌سازد. پارامتر max-period حداکثر مدت زمانی را (به ثانیه) مشخص می‌کند که سرویس DHCP باید غیرفعال باشد. اگر سرویس DHCP با موفقیت غیرفعال شود، سرور همگام‌کننده با صدور یک یا چند دستور lease4-get-page اجاره‌ها را از سرور دوردست واکشی می‌کند. هنگامی که همگام‌سازی پایگاه‌داده اجاره‌ها کامل شد، سرور همگام‌کننده دستور dhcp-enable <#std-isccmd-dhcp-enable> را به همتا ارسال می‌کند تا سرویس DHCP آن را دوباره فعال کند.

مقدار max-period باید به اندازه کافی طولانی باشد تا تضمین شود که پیش از تکمیل همگام‌سازی به پایان نمی‌رسد. در غیر این صورت، سرور DHCP در حالی که همگام‌سازی هنوز در جریان است، عملکرد DHCP خود را به طور خودکار فعال خواهد کرد. اگر سرور DHCP متعاقباً در طول همگام‌سازی هرگونه اجاره‌ای را تخصیص دهد، آن اجاره‌های جدید (یا به‌روزرسانی‌شده) توسط سرور همگام‌کننده واکشی نخواهند شد که این امر منجر به ناسازگاری پایگاه‌داده می‌شود..SS دستور ha-scopes

این دستور به مدیر سیستم اجازه می‌دهد حوزه‌های (scopes) HA در حال سرویس‌دهی را تغییر دهد. این دستور هنگام بازیابی از خرابی یا هنگام انجام عملیات نگهداری می‌تواند مفید باشد. برای آگاهی از این که کدام حوزه‌ها برای حالت‌های عملیاتی مختلف HA در دسترس هستند، به Load-Balancing Configuration و Hot-Standby Configuration مراجعه کنید.

هشدار:

دستور ha-scopes می‌تواند سرورهای Kea را در وضعیت‌های متناقضی قرار دهد که ممکن است منجر به رفتارهای غیرمنتظره شود. تغییر حوزه‌ها وضعیت سرور یا رابطه آن با شریک (partner) را به طور خودکار تغییر نمی‌دهد.

به عنوان مثال، هنگامی که حوزه‌های اصلی (primary) را به سرور آماده‌به‌خدمت (standby) اضافه می‌کنیم، شروع به پاسخ‌گویی به ترافیک DHCP برای آن حوزه‌ها خواهد کرد. این موضوع می‌تواند به وضعیتی بیانجامد که در آن هر دو سرور به ترافیک یکسانی پاسخ می‌دهند که ممکن است باعث تداخل آدرس‌های IP شود.

دستور ha-scopes ساختار زیر را دارد؛ با استفاده از یک مثال در DHCPv4:

{
    "command": "ha-scopes",
    "service": [ "dhcp4" ],
    "arguments": {
        "scopes": [ "HA_server1", "HA_server2" ],
        "server-name": "server2"
    }
}

این دستور سرور را برای رسیدگی به ترافیک حاصل از هر دو حوزه "HA_server1" و "HA_server2" پیکربندی می‌کند. برای غیرفعال کردن تمامی حوزه‌ها، یک فهرست خالی مشخص کنید:

{
    "command": "ha-scopes",
    "service": [ "dhcp4 "],
    "arguments": {
        "scopes": [ ],
        "server-name": "server2"
    }
}

پارامتر اختیاری server-name نام یکی از شرکا را در رابطه HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد.

این دستور برای ازسرگیری عملکرد ماشین وضعیت متوقف‌شده HA استفاده می‌شود، همان‌طور که در Pausing the HA State Machine شرح داده شده است. این دستور هیچ آرگومانی نمی‌پذیرد، بنابراین ساختار دستور به سادگی به شکل زیر است:

{
    "command": "ha-continue",
    "service": [ "dhcp4" ],
    "arguments": {
        "scopes": [ ],
        "server-name": "server2"
    }
}

پارامتر اختیاری server-name نام یکی از شرکا را در رابطه HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد.

بخش Server States توصیف می‌کند که چگونه دستور ha-heartbeat توسط یک جفت سرور فعال HA برای تشخیص خرابی یکی از شرکا استفاده می‌شود. با این حال، این دستور می‌تواند توسط مدیر سیستم نیز به یک یا هر دو سرور فرستاده شود تا وضعیت HA آن‌ها بررسی شود. این قابلیت امکان استقرار یک سامانه مانیتورینگ را بر روی سرورهای دارای قابلیت HA فراهم می‌سازد تا به صورت دوره‌ای بررسی کند که آیا آن‌ها فعال هستند یا نیاز به دخالت دستی وجود دارد. دستور ha-heartbeat هیچ آرگومانی نمی‌پذیرد:

{
    "command": "ha-heartbeat",
    "service": [ "dhcp4" ],
    "arguments": {
        "scopes": [ ],
        "server-name": "server2"
    }
}

پارامتر اختیاری server-name نام یکی از شرکا را در رابطه HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد.

پس از برقراری ارتباط موفق با سرور، پاسخی مشابه زیر باید بازگردانده شود:

{
   "result": 0,
   "text": "HA peer status returned.",
   "arguments":
       {
           "state": "partner-down",
           "date-time": "Thu, 07 Nov 2019 08:49:37 GMT",
           "scopes": [ "server1" ],
           "unsent-update-count": 123
       }
}

مقدار بازگردانده شده state باید یکی از مقادیر فهرست‌شده در Server States باشد. در مثال بالا، وضعیت partner-down بازگردانده شده است که نشان می‌دهد سروری که به دستور پاسخ داده معتقد است شریک آن آفلاین است؛ بنابراین، به تمامی درخواست‌های DHCP فرستاده شده به سرورها پاسخ می‌دهد. برای اطمینان از اینکه شریک واقعاً آفلاین است، مدیر سیستم باید دستور ha-heartbeat را به سرور دوم بفرستد. اگر ارسال دستور ناموفق باشد، به عنوان مثال به دلیل ناتوانی در برقراری اتصال TCP به سرور DHCP، به احتمال بسیار زیاد سرور در حال اجرا نیست.

پارامتر date-time درک سرور از زمان را منتقل می‌کند.

مقدار unsent-update-count تعداد تجمعی تمام به‌روزرسانی‌های ارسال‌نشده اجاره (lease) از زمان بوت شدن سرور است؛ مقدار آن هنگام راه‌اندازی سرور روی 0 تنظیم می‌شود. این مقدار در طول کارکرد سرور هرگز به 0 بازنشانی نمی‌شود، حتی پس از آنکه شریک پایگاه داده را همگام‌سازی کند. این مقدار توسط شریکی که پاسخ ضربان قلب (heartbeat) را ارسال می‌کند، در صورتی که نتواند به‌روزرسانی اجاره را ارسال کند، افزایش می‌یابد. به عنوان مثال، فرض کنید خرابی در نتیجه یک قطعی موقت در ارتباط باشد. در آن صورت، شریکی که پاسخ ضربان قلب partner-down را دریافت می‌کند تغییرات مقدار را ردیابی کرده و می‌تواند پس از برقراری مجدد ارتباط تعیین کند که آیا به‌روزرسانی‌های اجاره جدیدی وجود دارد که دریافت نکرده باشد یا خیر. اگر مقادیر در هر دو سرور مطابقت نداشته باشند، نشانه‌ای است از این که شریک باید پایگاه داده اجاره‌های خود را همگام‌سازی کند. مقدار غیر صفر به خودی خود نشان‌دهنده مشکلی در حال حاضر با به‌روزرسانی‌های اجاره نیست، اما مقداری که مدام در حال افزایش باشد چنین است.

پاسخ معمول بازگردانده شده توسط یک سرور زمانی که هر دو سرور عملیاتی هستند، به این صورت است:

{
   "result": 0,
   "text": "HA peer status returned.",
   "arguments":
       {
           "state": "load-balancing",
           "date-time": "Thu, 07 Nov 2019 08:49:37 GMT",
           "scopes": [ "server1" ],
           "unsent-update-count": 0
       }
}

در بیشتر موارد، دستور ha-heartbeat باید به هر دو سرور دارای قابلیت HA ارسال شود تا وضعیت کل پیکربندی HA بررسی شود. به ویژه، اگر یکی از سرورها نشان دهد که در وضعیت load-balancing قرار دارد، به این معنی است که این سرور طوری عمل می‌کند که گویی شریک آن سالم است و کار می‌کند. وقتی یک شریک از کار می‌افتد، مدتی طول می‌کشد تا سرور بازمانده متوجه آن شود. بخش Scope Transition in a Partner-Down Case الگوریتمی را که سرور بازمانده قبل از انتقال به وضعیت partner-down دنبال می‌کند، شرح می‌دهد. اگر دستور ha-heartbeat در بازه زمانی بین از کار افتادن یکی از سرورها و انتقال سرور بازمانده به وضعیت partner-down ارسال شود، پاسخ دریافتی از سرور بازمانده این خرابی را بازتاب نمی‌دهد. ارسال مجدد دستور پس از اینکه سرور بازمانده وارد وضعیت partner-down شد، خرابی را تشخیص خواهد داد..SS دستور status-get

دستور status-get <#std-isccmd-status-get> یک دستور عمومی است که علاوه بر کارسازهای DHCP، توسط چندین دیمن Kea نیز پشتیبانی می‌شود. با این حال، هنگام ارسال به یک کارساز DHCP با HA فعال، می‌توان از آن برای آگاهی از جزئیات وضعیت کارساز مختص HA استفاده کرد. پاسخ نه تنها حاوی اطلاعات وضعیت کارساز دریافت‌کنندهٔ این دستور است، بلکه در صورت در دسترس بودن، شامل اطلاعات مربوط به شریک (partner) آن نیز می‌شود.

در ادامه یک نمونه پاسخ به دستور status-get <#std-isccmd-status-get>، شامل وضعیت HA دو کارساز load-balancing آورده شده است:

{
    "result": 0,
    "text": "",
    "arguments": {
        "pid": 1234,
        "uptime": 3024,
        "reload": 1111,
        "high-availability": [
            {
                "ha-mode": "load-balancing",
                "ha-servers": {
                    "local": {
                        "role": "primary",
                        "scopes": [ "server1" ],
                        "server-name": "server1",
                        "state": "load-balancing",
                        "system-time": "2024-01-01 12:00:00"
                    },
                    "remote": {
                        "age": 10,
                        "analyzed-packets": 8,
                        "clock-skew": 0,
                        "communication-interrupted": true,
                        "connecting-clients": 2,
                        "in-touch": true,
                        "last-scopes": [ "server2" ],
                        "last-state": "load-balancing",
                        "role": "secondary",
                        "server-name": "server2",
                        "system-time": "2024-01-01 12:00:00",
                        "unacked-clients": 1,
                        "unacked-clients-left": 2
                    }
                }
            }
        ],
        "multi-threading-enabled": true,
        "thread-pool-size": 4,
        "packet-queue-size": 64,
        "packet-queue-statistics": [ 0.2, 0.1, 0.1 ],
        "sockets": {
            "status": "ready"
        }
    }
}

آرگومان high-availability فهرستی است که در حال حاضر تنها از یک عنصر تشکیل شده است.

نگاشت ha-servers شامل دو ساختار است: local و remote. اولی حاوی اطلاعات وضعیت کارسازی است که دستور را دریافت کرده است، در حالی که دومی دربردارندهٔ اطلاعات وضعیتی است که کارساز محلی از شریک خود دارد. مقدار role برای کارساز شریک از فایل پیکربندی محلی جمع‌آوری می‌شود، بنابراین همواره باید در دسترس باشد. سایر اطلاعات وضعیت، مانند last-scopes و last-state، تا زمانی که کارساز محلی با ارسال موفقیت‌آمیز دستور ha-heartbeat با کارساز دوردست ارتباط برقرار نکند در دسترس نخواهند بود. اگر حداقل یک ارتباط از این دست انجام شده باشد، مقدار بازگشتی پارامتر in-touch برابر با true قرار می‌گیرد. با بررسی این مقدار، فرستندهٔ دستور می‌تواند مشخص کند که آیا اطلاعات مربوط به کارساز دوردست قابل اعتماد است یا خیر.

پارامترهای last-scopes و last-state حاوی اطلاعاتی دربارهٔ حوزه‌های HA ارائه‌شده توسط شریک و وضعیت آن هستند. این اطلاعات هنگام تبادل دستور ha-heartbeat جمع‌آوری می‌شوند، بنابراین اگر مشکلی در ارتباط میان شرکا رخ دهد و این اطلاعات وضعیت تازه‌سازی نشوند، ممکن است دقیق نباشند. در چنین حالتی، ممکن است ارسال مستقیم دستور status-get <#std-isccmd-status-get> به کارساز شریک برای بررسی وضعیت فعلی آن سودمند باشد. پارامتر age، سن اطلاعات دریافتی از شریک را بر حسب ثانیه مشخص می‌کند.

مقدار بولی communication-interrupted مشخص می‌کند که آیا کارساز دریافت‌کنندهٔ دستور status-get <#std-isccmd-status-get> (کارساز محلی) برای مدتی طولانی‌تر از زمان مشخص‌شده در max-response-delay از برقراری ارتباط با شریک ناتوان بوده است یا خیر. در چنین شرایطی، کارسازهای فعال در وضعیت communication-interrupted در نظر گرفته می‌شوند. در این نقطه، کارساز محلی ممکن است پایش ترافیک DHCP هدایت‌شده به سمت شریک را آغاز کند تا ببیند آیا شریک به این ترافیک پاسخ می‌دهد یا خیر. اطلاعات بیشتر دربارهٔ روال failover را می‌توان در پیکربندی Load-Balancing یافت.

پارامتر system-time زمان UTC را در لحظه‌ای که انحراف زمان میان گره محلی و شریک آخرین بار محاسبه شده است، نگه می‌دارد. این مقدار در قالب %Y-%m-%d %H:%M:%S به ترتیب برای هر گره فعال، یعنی محلی و دوردست، نمایش داده می‌شود. پارامتر clock-skew در نگاشت remote در دسترس است و اختلاف این دو زمان را بر حسب ثانیه نگه می‌دارد. زمان محلی از زمان شریک کسر می‌شود. یک مقدار مثبت به این معنی است که ساعت شریک جلوتر است، در حالی که مقدار منفی نشان می‌دهد که شریک عقب‌تر است. اگر انحراف ساعت هنوز محاسبه نشده باشد، هر دو پارامتر system-time و clock-skew می‌توانند null باشند.

پارامترهای connecting-clients، unacked-clients، unacked-clients-left و analyzed-packets همراه با پارامتر communication-interrupted معرفی شده‌اند و اطلاعات مفیدی دربارهٔ وضعیت پایش ترافیک DHCP در حالت communication-interrupted ارائه می‌دهند. به محض خروج کارساز از حالت communication-interrupted، تمامی این پارامترها به 0 بازنشانی می‌شوند.

این پارامترها در حالت communication-interrupted دارای معانی زیر هستند:

  • connecting-clients - این تعداد کلاینت‌های متفاوتی است که برای دریافت اجاره (lease) از کارساز دوردست تلاش کرده‌اند. این کلاینت‌ها با نشانی MAC و شناسهٔ کلاینت (در DHCPv4) یا DUID (در DHCPv6) متمایز می‌شوند. این تعداد شامل کلاینت‌های "unacked" (که مقدار فیلد "secs" یا زمان سپری‌شده "elapsed time" برای آن‌ها از max-response-delay فراتر رفته است) نیز می‌شود.
  • unacked-clients - این تعداد کلاینت‌های متفاوتی است که "unacked" در نظر گرفته شده‌اند؛ یعنی کلاینت‌هایی که تلاششان برای دریافت اجاره بیشتر از مقدار فیلد "secs" طول کشیده است، یا زمان سپری‌شده "elapsed time" برای آن‌ها از مقدار max-response-delay فراتر رفته است.
  • unacked-clients-left - این مشخص‌کنندهٔ تعداد کلاینت‌های دیگری است که قبل از ورود کارساز به وضعیت partner-down باید "unacked" تلقی شوند. با افزایش مقدار unacked-clients، این مقدار کاهش می‌یابد. زمانی که این مقدار به 0 برسد، کارساز محلی وارد وضعیت partner-down می‌شود.
  • analyzed-packets - این تعداد کل بسته‌های هدایت‌شده به کارساز شریک است که از زمان ورود به وضعیت قطع ارتباط، توسط کارساز محلی تحلیل شده‌اند. این عدد شامل ارسال‌های مجدد از سوی همان کلاینت‌ها نیز می‌باشد.

پایش این مقادیر به پیش‌بینی زمان ورود کارساز محلی به حالت partner-down یا درک چرایی عدم ورود کارساز به این حالت کمک می‌کند.

پارامتر ha-mode حالت عملیاتی HA را که با استفاده از پارامتر mode در فایل پیکربندی انتخاب شده است، برمی‌گرداند. این پارامتر می‌تواند یکی از مقادیر زیر را داشته باشد: load-balancing، hot-standby، یا passive-backup.

پاسخ status-get <#std-isccmd-status-get> تنها در حالت‌های load-balancing و hot-standby قالبی به صورت شرح‌داده‌شده در بالا دارد. در حالت passive-backup، نگاشت remote در پاسخ گنجانده نمی‌شود، زیرا در این حالت تنها یک کارساز فعال (محلی) وجود دارد. پاسخ شامل هیچ اطلاعاتی دربارهٔ وضعیت کارسازهای پشتیبان نیست..SS دستور ha-maintenance-start

این دستور انتقال شرکای سرور به وضعیت in-maintenance و انتقال سرورِ دریافت‌کنندهٔ دستور به وضعیت partner-in-maintenance را در هر رابطهٔ HA آغاز می‌کند. برای جزئیات بیشتر به بخش «خاموشی کنترل‌شده و نگهداری سرورهای DHCP» (Controlled Shutdown and Maintenance of DHCP Servers) مراجعه کنید.

{
    "command": "ha-maintenance-start",
    "service": [ "dhcp4" ]
}

این دستور برای لغو فرآیند نگهداری‌ای که پیش‌تر با استفاده از دستور ha-maintenance-start آغاز شده بود، استفاده می‌شود. سرور دریافت‌کنندهٔ این دستور ابتدا دستور ha-maintenance-notify را در حالی که پرچم cancel روی true تنظیم شده است، به شرکای خود ارسال می‌کند. سپس سرور از وضعیت partner-in-maintenance به وضعیت پیشین خود بازمی‌گردد. برای جزئیات به بخش «خاموشی کنترل‌شده و نگهداری سرورهای DHCP» (Controlled Shutdown and Maintenance of DHCP Servers) مراجعه کنید.

{
    "command": "ha-maintenance-cancel",
    "service": [ "dhcp4" ]
}

این دستور توسط سروری که دستور ha-maintenance-start یا ha-maintenance-cancel را دریافت کرده است به شریک خود فرستاده می‌شود، تا موجب انتقال شریک به وضعیت in-maintenance یا بازگشت آن از این وضعیت به وضعیت پیشین شود. برای جزئیات به بخش «خاموشی کنترل‌شده و نگهداری سرورهای DHCP» (Controlled Shutdown and Maintenance of DHCP Servers) مراجعه کنید.

{
    "command": "ha-maintenance-notify",
    "service": [ "dhcp4" ],
    "arguments": {
        "cancel": false,
        "state": "ready",
        "server-name": "server2"
    }
}

آرگومان state گیرنده را از وضعیت سرور فرستنده مطلع می‌سازد. گیرنده می‌تواند فوراً عملکرد ماشین وضعیت را بدون نیاز به ارسال یک ضربان قلب (heartbeat) جهت بررسی وضعیت شریک، از سر بگیرد.

پارامتر اختیاری server-name نام یکی از شرکا را در رابطهٔ HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کنندهٔ این دستور فقط یک رابطهٔ HA در پیکربندی خود داشته باشد، می‌توان از این پارامتر صرف‌نظر کرد.

هشدار:

دستور ha-maintenance-notify برای استفاده توسط مدیران سیستم در نظر گرفته نشده است. این دستور برای ارتباطات داخلی بین یک جفت سرور DHCP فعال‌شده با قابلیت HA استفاده می‌شود. استفادهٔ مستقیم از این دستور پشتیبانی نمی‌شود و ممکن است عواقب ناخواسته‌ای ایجاد کند.

این دستور موجب می‌شود سرور ماشین وضعیت دسترس‌پذیری بالا (High Availability) خود را با انتقال به وضعیت waiting بازنشانی کند. یک شریک در وضعیت communication-recovery ممکن است این دستور را ارسال کند تا سرور پایگاه دادهٔ اجاره‌های (lease database) خود را همگام‌سازی کند. همگام‌سازی پایگاه داده زمانی لازم است که شریک، پس از برقراری مجدد ارتباط متعاقب یک قطعی موقت، نتواند تمام به‌روزرسانی‌های پایگاه دادهٔ اجاره را ارسال نماید. همچنین زمانی که سرور در وضعیت communication-recovery قرار دارد و مقدار delayed-updates-limit فراتر رود، انجام این کار الزامی است.

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

{
    "command": "ha-reset",
    "service": [ "dhcp4" ],
    "arguments": {
        "server-name": "server2"
    }
}

پارامتر اختیاری server-name نام یکی از شرکا را در رابطهٔ HA که این دستور مربوط به آن است، مشخص می‌کند. اگر سرور دریافت‌کنندهٔ این دستور تنها یک رابطهٔ HA در پیکربندی خود داشته باشد، می‌توان این پارامتر را نادیده گرفت.

این دستور پاسخ زیر را ایجاد می‌کند:

{
    "result": 0,
    "text": "HA state machine reset."
}

اگر سرور دریافت‌کنندهٔ این دستور از قبل در وضعیت waiting باشد، دستور هیچ اثری نخواهد داشت..SS دستور ha-sync-complete-notify

یک کارگزار این دستور را برای همتای خود ارسال می‌کند تا اعلام کند که همگام‌سازی پایگاه‌داده اجاره‌ها (lease-database) را به پایان رسانده است. همتا در صورتی که بتواند در وضعیت فعلی خود اجاره‌های جدیدی تخصیص دهد، ممکن است سرویس DHCP خود را فعال کند. همتا در وضعیت partner-down تا زمانی که یک آزمون موفقیت‌آمیز ha-heartbeat به کارگزار همتای خود ارسال نکند، سرویس DHCP را فعال نمی‌کند. اگر اتصال همچنان در دسترس نباشد، کارگزار در وضعیت partner-down سرویس DHCP خود را فعال می‌کند تا به پاسخ‌دهی به کلاینت‌ها ادامه دهد.

{
    "command": "ha-sync-complete-notify",
    "service": [ "dhcp4" ],
    "arguments": {
        "origin-id": 2000,
        "server-name": "server2"
    }
}

پارامتر اختیاری server-name نام یکی از همتاها را در رابطه HA که این دستور به آن مربوط می‌شود مشخص می‌کند. اگر کارگزار دریافت‌کننده این دستور تنها یک رابطه HA در پیکربندی خود داشته باشد، می‌توان این پارامتر را نادیده گرفت.

پارامتر origin-id برای انتخاب سرویس HA استفاده می‌شود که کارگزار دریافت‌کننده هنگام دریافت این اعلان، باید سرویس DHCP را برای آن فعال کند. این همان مبدأیی است که کارگزار فرستنده پیش‌تر برای غیرفعال کردن سرویس DHCP پیش از همگام‌سازی استفاده کرده بود. پارامتر origin-id جایگزین پارامتر منسوخ‌شده origin است که در برخی از نسخه‌های پیشین Kea استفاده می‌شد.

این دستور پاسخ زیر را به همراه دارد:

{
    "result": 0,
    "text": "Server successfully notified about the synchronization completion."
}

هشدار:

دستور ha-sync-complete-notify برای استفاده توسط مدیران سیستم در نظر گرفته نشده است. این دستور برای ارتباط داخلی میان یک جفت کارگزار DHCP با قابلیت HA استفاده می‌شود. استفاده مستقیم از این دستور پشتیبانی نمی‌شود و ممکن است پیامدهای ناخواسته‌ای به همراه داشته باشد.

یک چیدمان هاب و اسپوک (hub-and-spoke)، با یک کارگزار مرکزی و چندین کارگزار شعبه، روشی متداول برای اطمینان از تاب‌آوری کارگزارهای DHCP است. کارگزارهای شعبه، کارگزارهای اصلی در حالت hot-standby هستند و به ترافیک محلی DHCP در مکان‌های مربوط به خود پاسخ می‌دهند. کارگزار مرکزی به عنوان یک کارگزار آماده‌به‌خدمت (standby) برای هر کارگزار شعبه عمل می‌کند. این کارگزار ماشین‌های وضعیت مستقلی را با کارگزارهای شعبه نگه می‌دارد که روابط (relationships) نامیده می‌شوند. اگر یکی از کارگزارهای شعبه دچار خرابی شود، کارگزار مرکزی می‌تواند ترافیک DHCP آن را به عهده بگیرد. در این حالت، یکی از روابط کارگزار مرکزی در وضعیت partner-down قرار می‌گیرد. سایر روابط ممکن است همچنان در وضعیت hot-standby باقی بمانند و به طور فعال به ترافیک DHCP پاسخ ندهند. هنگامی که کارگزار شعبه دوباره فعال می‌شود، پایگاه‌داده اجاره را با کارگزار مرکزی همگام‌سازی می‌کند و کارگزار مرکزی دوباره کاملاً غیرفعال (passive) می‌شود. در موارد نادر، اگر چندین کارگزار شعبه متوقف شوند، کارگزار مرکزی مسئولیت تمام ترافیک آن‌ها را به عهده می‌گیرد و در صورتی که همه کارگزارهای شعبه از کار بیفتند، بالقوه کل ترافیک DHCP در کل شبکه را مدیریت خواهد کرد. یک ساختار ساده هاب و اسپوک متشکل از دو کارگزار شعبه و یک کارگزار مرکزی در زیر نشان داده شده است.

                            +----- Central Server ------+
                            |                           |
+----------+ relationship 1 |  +----------+----------+  | relationship 2 +----------+
| Server 1 |===================| Server 2 | Server 4 |===================| Server 3 |
+----------+                |  +----------+----------+  |                +----------+
                            |                           |
                            +---------------------------+

پیکربندی هر کارگزار شعبه شامل مجموعه‌ای از زیرشبکه‌های مناسب برای آن کارگزار شعبه است؛ کارگزارهای شعبه مختلف به زیرشبکه‌های متفاوتی سرویس می‌دهند. پیکربندی کارگزار مرکزی شامل تمام زیرشبکه‌های کارگزارهای شعبه است، به طوری که بتواند به ترافیک DHCP هدایت‌شده به هر کارگزار شعبه‌ای که دچار خرابی شده است پاسخ دهد. زیرشبکه‌ها در کارگزار مرکزی باید مانند قطعه‌کد زیر در قالب روابط گروه‌بندی شوند:

{
    "Dhcp6": {
        "interfaces-config": {
            "interfaces": [ "enp0s8", "enp0s9" ]
        },
        "hooks-libraries": [
            {
                "library": "libdhcp_lease_cmds.so",
                "parameters": {}
            },
            {
                "library": "libdhcp_ha.so",
                "parameters": {
                    "high-availability": [
                        {
                            "this-server-name": "server2",
                            "mode": "hot-standby",
                            "multi-threading": {
                                "enable-multi-threading": true,
                                "http-dedicated-listener": true,
                                "http-listener-threads": 4,
                                "http-client-threads": 4
                            },
                            "peers": [
                                {
                                    "name": "server1",
                                    "url": "http://192.168.56.66:8007/",
                                    "role": "primary",
                                    "auto-failover": true
                                },
                                {
                                    "name": "server2",
                                    "url": "http://192.168.56.33:8007/",
                                    "role": "standby",
                                    "auto-failover": true
                                }
                            ]
                        },
                        {
                            "this-server-name": "server4",
                            "mode": "hot-standby",
                            "multi-threading": {
                                "enable-multi-threading": true,
                                "http-dedicated-listener": true,
                                "http-listener-threads": 4,
                                "http-client-threads": 4
                            },
                            "peers": [
                                {
                                    "name": "server3",
                                    "url": "http://192.168.57.99:8007/",
                                    "role": "primary",
                                    "auto-failover": true
                                },
                                {
                                    "name": "server4",
                                    "url": "http://192.168.57.33:8007/",
                                    "role": "standby",
                                    "auto-failover": true
                                }
                            ]
                        }
                    ]
                }
            }
        ],
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8:1::/64",
                "pools": [ { "pool": "2001:db8:1::/80" } ],
                "interface": "enp0s8",
                "user-context": {
                    "ha-server-name": "server2"
                }
            },
            {
                "id": 2,
                "subnet": "2001:db8:2::/64",
                "pools": [ { "pool": "2001:db8:2::/80" } ],
                "interface": "enp0s9",
                "user-context": {
                    "ha-server-name": "server4"
                }
            }
        ]
    }
}

نام‌های همتا در روابط باید یکتا باشند. بافت کاربر (user context) برای هر زیرشبکه شامل پارامتر ha-server-name است که یک زیرشبکه را با یک رابطه مرتبط می‌کند. مقدار ha-server-name می‌تواند هر یک از نام‌های همتا در رابطه باشد. به عنوان مثال، اگر یک رابطه شامل نام‌های همتای server1 و server2 باشد، فرقی نمی‌کند که ha-server-name برابر با server1 باشد یا server2. در هر دو حالت، زیرشبکه را با آن رابطه مرتبط می‌سازد.

نکته:

توجه به این نکته مهم است که هر همتا در یک کارگزار Kea مشخص باید از ترکیب نشانی/پورت شنود یکتا استفاده کند. اگر نشانی و پورت یکسانی برای چندین همتا تعریف شود، سرویس Kea با خطایی مشابه زیر در راه‌اندازی شکست می‌خورد:
DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using
file 'kea-dhcp4.conf': Error initializing hooks: CmdHttpListener::run failed:
unable to setup TCP acceptor for listening to the incoming HTTP requests:
bind: Address already in use

مشخص کردن ha-server-name در کارگزارهای شعبه الزامی نیست، با این فرض که کارگزارهای شعبه فقط شامل زیرشبکه‌هایی باشند که به آن‌ها سرویس می‌دهند. پیکربندی زیر را برای شعبه server3 در نظر بگیرید:

{
    "Dhcp6": {
        "interfaces-config": {
            "interfaces": [ "enp0s8" ]
        },
        "hooks-libraries": [
            {
                "library": "libdhcp_lease_cmds.so",
                "parameters": {}
            },
            {
                "library": "libdhcp_ha.so",
                "parameters": {
                    "high-availability": [
                        {
                            "this-server-name": "server3",
                            "mode": "hot-standby",
                            "multi-threading": {
                                "enable-multi-threading": true,
                                "http-dedicated-listener": true,
                                "http-listener-threads": 4,
                                "http-client-threads": 4
                            },
                            "peers": [
                                {
                                    "name": "server3",
                                    "url": "http://192.168.57.99:8007/",
                                    "role": "primary",
                                    "auto-failover": true
                                },
                                {
                                    "name": "server4",
                                    "url": "http://192.168.57.33:8007/",
                                    "role": "standby",
                                    "auto-failover": true
                                }
                            ]
                        }
                    ]
                }
            }
        ],
        "subnet6": [
            {
                "id": 2,
                "subnet": "2001:db8:2::/64",
                "pools": [
                    {
                        "pool": "2001:db8:2::/80"
                    }
                ],
                "interface": "enp0s8",
                "user-context": {
                    "ha-server-name": "server3"
                }
            }
        ]
    }
}

نکته:

اگرچه می‌توان پارامترهای بافت کاربر ha-server-name را در کارگزارهای شعبه نادیده گرفت، توصیه می‌کنیم آن‌ها را درج کنید. کارگزارها هنگام همگام‌سازی پایگاه‌داده، تمام اجاره‌ها را از همتاها دریافت می‌کنند؛ اگر زیرشبکه‌ها به صراحت با رابطه مرتبط نشده باشند، کارگزار شعبه تمام اجاره‌های دریافت شده از کارگزار مرکزی (شامل اجاره‌های مربوط به سایر روابط) را در پایگاه‌داده خود وارد می‌کند. مشخص کردن پارامتر ha-server-name برای هر زیرشبکه پیکربندی‌شده در کارگزار شعبه، تضمین می‌کند که فقط اجاره‌های متعلق به رابطه خود در پایگاه‌داده کارگزار شعبه وارد شوند.

نکته:

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

نکته:

پیکربندی هاب و اسپوک در حال حاضر با پارامترهای reselect-subnet-address و reselect-subnet-pool از کتابخانه libdhcp_radius.so ناسازگار است. کتابخانه قلاب دسترس‌پذیری بالا (High Availability hook library) از زیرشبکه انتخاب‌شده اولیه برای برگزیدن یک رابطه HA جهت پردازش بسته استفاده می‌کند. انتخاب مجدد زیرشبکه ممکن است با این فرایند تداخل ایجاد کند. برای جزئیات بیشتر، به بخش پیکربندی کتابخانه قلاب RADIUS در <#radius-config> مراجعه کنید.

برخی از پس‌اندهای پایگاه‌داده، مانند RADIUS، کند هستند و ممکن است پاسخ‌دهی آن‌ها زمان زیادی ببرد. از آن‌جا که Kea به‌طور کلی همگام (synchronous) است، کارایی پس‌اند مستقیماً بر کارایی DHCP تأثیر می‌گذارد. به منظور به حداقل رساندن این اثر و بهبود کارایی، کتابخانهٔ Host Cache روشی برای ذخیره‌سازی محلی اطلاعات پایگاه‌داده در حافظه موقت (cache) فراهم می‌کند. این قابلیت شامل حافظه موقت منفی (negative caching)، یعنی توانایی به‌خاطر سپردن این که هیچ اطلاعاتی از کلاینت در پایگاه‌داده وجود ندارد، نیز می‌شود.

نکته:

libdhcp_host_cache.so بخشی از کد منبع‌باز است و برای همهٔ کاربران Kea در دسترس است. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود.

نکته:

این کتابخانه تنها می‌تواند توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

در اصل، این کتابخانهٔ قلاب (hook library) می‌تواند با هر پس‌اندی که ممکن است موجب افت کارایی شود (MySQL، PostgreSQL یا RADIUS) استفاده شود. برای کارکرد سازوکار حسابرسی (accounting) در RADIUS، بارگذاری Host Cache الزامی است.

کتابخانهٔ قلاب Host Cache بسیار ساده است. این کتابخانه تنها یک پارامتر اختیاری (maximum) می‌گیرد که حداکثر تعداد میزبان‌های ذخیره‌شده در حافظه موقت را مشخص می‌کند. در صورت عدم تعیین، مقدار پیش‌فرض 0 استفاده می‌شود که به معنای نبود محدودیت است. این کتابخانهٔ قلاب را می‌توان همانند هر کتابخانهٔ قلاب دیگری بارگذاری کرد؛ برای نمونه، این پیکربندی می‌تواند استفاده شود:

"Dhcp4": {
# Your regular DHCPv4 configuration parameters here.
"hooks-libraries": [
{
    "library": "libdhcp_host_cache.so",
    "parameters": {
        # Tells Kea to never cache more than 1000 hosts.
        "maximum": 1000
    }
} ],
...
}

پس از بارگذاری، کتابخانهٔ قلاب Host Cache تعدادی دستور جدید ارائه می‌دهد که می‌توانند از طریق کانال کنترل (بخش Using the Control Channel <#ctrl-channel-client> را ببینید) استفاده شوند. یک نمونه کلاینت RESTful API در Overview of the Kea Shell <#shell-overview> شرح داده شده است. بخش‌های زیر دستورهای موجود را شرح می‌دهند.

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

{
    "command": "cache-flush",
    "arguments": 1000
}

این دستور 1000 میزبان را حذف می‌کند؛ برای حذف تمام میزبان‌های ذخیره‌شده، در عوض از cache-clear استفاده کنید. میزبان‌ها با ترتیب FIFO (نخستین ورودی، نخستین خروجی) ذخیره می‌شوند، بنابراین همیشه قدیمی‌ترین مدخل‌ها حذف می‌گردند.

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

{
    "command": "cache-clear"
}

این دستور تمام میزبان‌ها را حذف می‌کند. برای حذف تنها تعداد مشخصی از میزبان‌های ذخیره‌شده، لطفاً در عوض از cache-flush استفاده کنید.

این دستور تعداد مدخل‌های میزبان را بازمی‌گرداند. یک نمونه کاربرد به صورت زیر است:

{
    "command": "cache-size"
}

به‌طور کلی، محتوای حافظه موقت یک وضعیت زمان اجرا در نظر گرفته می‌شود و کارساز می‌تواند طبق معمول خاموش یا بازراه‌اندازی شود؛ سپس حافظه موقت پس از بازراه‌اندازی مجدداً پر می‌شود. با این حال، در برخی موارد ذخیره کردن محتویات حافظه موقت سودمند است. یک نمونه از این موارد RADIUS است، که در آن میزبان‌های ذخیره‌شده همچنین صفت‌های اضافیِ ذخیره‌شدهٔ RADIUS را حفظ می‌کنند؛ روش آسانی برای به‌دست آوردن دوبارهٔ این اطلاعات وجود ندارد، زیرا کلاینت‌های در حال تمدید بسته‌های خود را مستقیماً به کارساز DHCP ارسال می‌کنند. مورد کاربرد دیگر زمانی است که مدیر سیستم می‌خواهد کارساز را بازراه‌اندازی کند و به دلایل کارایی، مایل است کارساز با یک حافظه موقت گرم و از پیش پرشده (hot/populated) شروع به کار کند.

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

{
    "command": "cache-write",
    "arguments": "/var/lib/kea/kea-host-cache.json"
}

این کار موجب ذخیره شدن محتویات در فایل /var/lib/kea/kea-host-cache.json می‌شود. سپس می‌توان آن فایل را با دستور cache-load بارگذاری کرد یا توسط هر ابزار دیگری که قادر به تجزیه و فهم قالب JSON باشد پردازش نمود.

نکته:

از نسخهٔ 2.7.9 در Kea، فایل حافظه موقت تنها می‌تواند در دایرکتوری داده‌ای که در زمان کامپایل مشخص شده است نوشته شود: "[kea-install-dir]/var/lib/kea". این مسیر می‌تواند در هنگام راه‌اندازی با مقداردهی متغیر محیطی KEA_DHCP_DATA_DIR به مسیر دلخواه بازنویسی شود. برای راحتی کار هنگام تعیین نام فایل سفارشی، کافی است بخش مسیر را از filename حذف کنید.

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

این دستور اجازه می‌دهد محتویات یک فایل روی دیسک در یک حافظهٔ نهان درون حافظه (in-memory cache) بارگذاری شود. این دستور یک پارامتر می‌گیرد که نام فایل را مشخص می‌کند. نمونه‌ای از کاربرد آن به صورت زیر است:

{
    "command": "cache-load",
    "arguments": "/usr/local/share/kea/kea-host-cache.json"
}

این دستور محتویات را در فایل /usr/local/share/kea/kea-host-cache.json ذخیره می‌کند. سپس می‌توان آن فایل را با دستور cache-load بارگذاری کرد یا توسط هر ابزار دیگری که قادر به درک قالب JSON باشد پردازش نمود.

این دستور مشابه cache-write است، اما به جای نوشتن محتویات حافظهٔ نهان روی دیسک، محتویات را به ارسال‌کنندهٔ دستور بازمی‌گرداند.

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

{
    "command": "cache-get"
}

این دستور تمام میزبان‌های ذخیره‌شده در حافظهٔ نهان را برمی‌گرداند؛ پاسخ ممکن است حجیم باشد.

این دستور مشابه cache-get است، اما به جای بازگرداندن کل محتوا، تنها ورودی‌های منطبق با شناسهٔ ارائه‌شده را بازمی‌گرداند.

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

{
    "command": "cache-get-by-id",
    "arguments": {
        "hw-address": "01:02:03:04:05:06"
    }
}

این دستور تمام میزبان‌های ذخیره‌شده در حافظهٔ نهان را با آدرس سخت‌افزاری ارائه‌شده بازمی‌گرداند.

از این دستور می‌توان برای درج دستی یک میزبان در حافظهٔ نهان استفاده کرد؛ سناریوهای کاربردی بسیار اندکی وجود دارند که در آن‌ها این دستور ممکن است مفید باشد. این دستور انتظار دارد آرگومان‌های آن از نحو معمول برای تعیین رزروهای میزبان پیروی کنند (بخش رزروهای میزبان در DHCPv4 <#host-reservation-v4> یا رزروهای میزبان در DHCPv6 <#host-reservation-v6> را ببینید)، با یک تفاوت: مقدار subnet-id باید صراحتاً مشخص شود.

نمونه‌ای از دستور برای درج یک میزبان IPv4 در حافظهٔ نهان میزبان به صورت زیر است:

{
    "command": "cache-insert",
    "arguments": {
        "hw-address": "01:02:03:04:05:06",
        "subnet-id4": 4,
        "subnet-id6": 0,
        "ip-address": "192.0.2.100",
        "hostname": "somehost.example.org",
        "client-classes4": [ ],
        "client-classes6": [ ],
        "option-data4": [ ],
        "option-data6": [ ],
        "next-server": "192.0.0.2",
        "server-hostname": "server-hostname.example.org",
        "boot-file-name": "bootfile.efi",
        "host-id": 0
    }
}

نمونه‌ای از دستور برای درج یک میزبان IPv6 در حافظهٔ نهان میزبان به صورت زیر است:

{
    "command": "cache-insert",
    "arguments": {
        "hw-address": "01:02:03:04:05:06",
        "subnet-id4": 0,
        "subnet-id6": 6,
        "ip-addresses": [ "2001:db8::cafe:babe" ],
        "prefixes": [ "2001:db8:dead:beef::/64" ],
        "hostname": "",
        "client-classes4": [ ],
        "client-classes6": [ ],
        "option-data4": [ ],
        "option-data6": [ ],
        "next-server": "0.0.0.0",
        "server-hostname": "",
        "boot-file-name": "",
        "host-id": 0
    }
}

گاهی اوقات حذف یک مدخل مشخص از کَش میزبان مفید است: برای مثال وضعیتی را در نظر بگیرید که دستگاه فعال است، Kea از پیش پیکربندی را ارائه داده، و مدخل میزبان در کَش قرار دارد. در پی یک اقدام مدیریتی (مثلاً مشتری قبوض خود را پرداخت نکرده یا به یک سرویس بهتر ارتقا یافته است)، اطلاعات در پایگاه‌دادهٔ پسین (مانند MySQL یا RADIUS) به‌روزرسانی می‌شود. با این حال، از آنجا که کَش در حال استفاده است، Kea متوجه تغییرات نمی‌شود زیرا مقادیر کَش‌شده به کار گرفته می‌شوند. دستور cache-remove می‌تواند با حذف مدخل کَش‌شده پس از اعمال تغییرات مدیریتی، این مشکل را برطرف کند.

دستور cache-remove به شیوه‌ای مشابه با دستور reservation-get عمل می‌کند. این دستور امکان پرس‌وجو با استفاده از دو پارامتر را فراهم می‌کند: یا subnet-id4 یا subnet-id6؛ یا ip-address (می‌تواند یک آدرس IPv4 یا IPv6 باشد)، hw-address (مشخص‌کنندهٔ آدرس سخت‌افزاری/MAC)، duid، circuit-id، client-id، یا flex-id.

یک دستور نمونه برای حذف یک میزبان IPv4 با آدرس رزروشدهٔ 192.0.2.1 از زیرشبکه‌ای با subnet-id برابر با 123 به صورت زیر است:

{
    "command": "cache-remove",
    "arguments": {
        "ip-address": "192.0.2.1",
        "subnet-id": 123
    }
}

نمونه‌ای دیگر که یک شناسهٔ میزبان IPv6 را بر اساس DUID و یک subnet-id مشخص حذف می‌کند:

{
    "command": "cache-remove",
    "arguments": {
        "duid": "00:01:ab:cd:f0:a1:c2:d3:e4",
        "subnet-id": 123
    }
}

Kea می‌تواند رزروهای میزبان را در یک پایگاه‌داده ذخیره کند؛ در بسیاری از استقرارهای بزرگ‌تر، اینکه بتوان این اطلاعات را در حین اجرای کارساز مدیریت کرد بسیار سودمند است. کتابخانهٔ دستورهای میزبان (Host Commands)، دستورهای مدیریتی را برای افزودن، پرس‌وجو، و حذف رزروهای میزبان به شکلی امن و بدون راه‌اندازی مجدد کارساز ارائه می‌دهد. به‌ویژه، این کتابخانه پارامترها را اعتبارسنجی می‌کند، بنابراین تلاش برای درج داده‌های نادرست - مانند افزودن میزبانی با شناسهٔ متداخل در همان زیرشبکه - رد می‌شود. این دستورها از طریق کانال فرمان (JSON بر بستر سوکت‌های UNIX یا HTTP/HTTPS) ارائه می‌شوند.

نکته:

libdhcp_host_cmds.so بخشی از کد منبع‌باز است و در دسترس تمامی کاربران Kea قرار دارد. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود.

نکته:

این کتابخانه تنها می‌تواند توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

در حال حاضر دستورهای زیر پشتیبانی می‌شوند:

  • reservation-add، که یک رزرو میزبان جدید اضافه می‌کند.
  • reservation-get، که در صورت تطابق با معیارهای مشخص‌شده، یک رزرو موجود را بازمی‌گرداند.
  • reservation-get-all، که تمام رزروهای موجود در یک زیرشبکهٔ مشخص را بازمی‌گرداند.
  • reservation-get-page، نوعی از reservation-get-all که رزروها را به صورت صفحه‌بندی‌شده بازمی‌گرداند؛ خواه تمام آن‌ها و خواه در یک زیرشبکهٔ مشخص.
  • reservation-get-by-address، که تمام رزروهای دارای یک آدرس IP مشخص یا یک پیشوند واگذارشده (بدون طول پیشوند)، و به‌طور اختیاری یک شناسهٔ زیرشبکه را بازمی‌گرداند.
  • reservation-get-by-hostname، که تمام رزروهای دارای یک نام میزبان مشخص و به‌طور اختیاری درون یک زیرشبکه را بازمی‌گرداند.
  • reservation-get-by-id، که تمام رزروهای دارای شناسهٔ مشخص را بازمی‌گرداند (از نسخهٔ 1.9.0 در Kea).
  • reservation-del، که برای حذف رزرو منطبق با معیارهای مشخص‌شده تلاش می‌کند.
  • reservation-update، که یک رزرو موجود منطبق با شناسه‌های ارائه‌شده در یک زیرشبکه را به‌روزرسانی (جایگزین) می‌کند.

برای استفاده از دستورهایی که اطلاعات رزرو را تغییر می‌دهند (یعنی reservation-add، reservation-del، و reservation-update) جهت تغییر داده‌های ذخیره‌شده در پایگاه‌دادهٔ میزبان، پایگاه‌دادهٔ میزبان‌ها باید مشخص شده باشد و نباید در حالت فقط‌خواندنی (read-only) اجرا شود (برای جزئیات، به توضیحات hosts-databases در بخش پیکربندی پایگاه‌دادهٔ میزبان‌های DHCPv4 <#hosts-databases-configuration4> و پیکربندی پایگاه‌دادهٔ میزبان‌های DHCPv6 <#hosts-databases-configuration6> مراجعه کنید). چنانچه hosts-databases مشخص نشده باشد یا در حالت فقط‌خواندنی کار کند، libdhcp_host_cmds.so بارگذاری خواهد شد، اما هرگونه تلاش برای استفاده از reservation-add، reservation-del، و reservation-update جهت اصلاح داده‌ها در آن پایگاه‌داده با شکست مواجه خواهد شد.

این دستورها همچنین می‌توانند میزبان‌ها را از پیکربندی JSON، مستقل از پایگاه‌دادهٔ میزبان‌ها اصلاح کنند. تغییرات اعمال‌شده در پیکربندی JSON به صورت فرار (volatile) هستند و می‌توان با ارسال دستور config-write <#std-isccmd-config-write> آن‌ها را دائمی کرد.

برای مشاهدهٔ شرح دستورهای پیشنهادی در آینده، به سند الزامات رابط کنترلی (Control API Requirements) در نشانی https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/commands مراجعه کنید.

تمامی دستورهای میزبان از نحو JSON استفاده می‌کنند. این دستورها را می‌توان با استفاده از کانال کنترل صادر کرد (به رابط مدیریتی یا Management API <#ctrl-channel> مراجعه کنید).

این کتابخانه می‌تواند مشابه سایر کتابخانه‌های قلاب (hook libraries) بارگذاری شود. این کتابخانه هیچ پارامتری دریافت نمی‌کند و از هر دو کارساز DHCPv4 و DHCPv6 پشتیبانی می‌کند.

"Dhcp6": {
    "hooks-libraries": [
        {
            "library": "libdhcp_host_cmds.so"
        },
        ...
    ]
}

پیش از بررسی هر دستور به طور مجزا، شایسته است در مورد پارامتر subnet-id بحث شود. در حال حاضر، این پارامتر برای تمام دستورات ارائه‌شده توسط این کتابخانه اجباری است، به استثنای reservation-get-by-hostname و reservation-get-by-address که در آن‌ها اختیاری است. subnet-id همچنین در reservation-get-page اختیاری بوده و در reservation-get-by-id غیرمجاز است.

رزروها می‌توانند به صورت سراسری (global) مشخص شوند و لزوماً محدود به زیرشبکه خاصی نیستند. هنگامی که رزروها از طریق فایل پیکربندی ارائه می‌شوند، شناسه (ID) زیرشبکه دربرگیرنده (یا عدم وجود آن) در ساختار پیکربندی به صورت ضمنی مشخص است. با این حال، هنگام مدیریت رزروها با استفاده از دستورات host، لازم است حوزه‌ای (scope) که رزرو به آن تعلق دارد، به طور صریح مشخص شود. این کار از طریق پارامتر subnet-id انجام می‌شود. برای رزروهای سراسری، از مقدار صفر (0) استفاده کنید. برای رزروهای محدود به یک زیرشبکه خاص، از شناسه (ID) آن زیرشبکه استفاده نمایید. همچنین به یادداشت موجود در بخش دستور reservation-add درباره دستور reservation-add برای رزرو خالی (یعنی بدون آدرس یا پیشوند رزرو شده) مراجعه کنید.

از سوی دیگر، اگر subnet-id در پارامترهای دستور مشخص نشده باشد، به هر میزبان (host) در پاسخ‌ها اضافه می‌شود. اگر subnet-id دارای مقدار ویژه استفاده‌نشده باشد، بدان معناست که مدخل میزبان تنها به نسخه دیگر IP تعلق دارد (یعنی IPv6 در سرور DHCPv4 یا IPv4 در سرور DHCPv6) و این مدخل نادیده گرفته می‌شود.

اکثر دستورات host پارامتر operation-target را می‌پذیرند که منبع داده میزبان را انتخاب می‌کند. دستورات ممکن است داده‌ها را از پیکربندی سرور (یعنی مقصد عملیاتی حافظه - memory)، یک پایگاه داده (مقصد database) یا هر دو (تمام منابع) پردازش کنند. پارامتر operation-target اختیاری است. به طور پیش‌فرض، دستوراتی که فقط داده‌ها را می‌خوانند از تمام منابع داده (حافظه و پایگاه داده) استفاده می‌کنند؛ دستوراتی که وضعیت را تغییر می‌دهند (یعنی reservation-add، reservation-del و reservation-update) تنها از مقصد پایگاه داده (database) استفاده می‌کنند.

پارامتر operation-target مقادیر زیر را می‌پذیرد:

  • memory - پرس‌وجو یا به‌روزرسانی پیکربندی زمان اجرای سرور
  • database - پرس‌وجو یا به‌روزرسانی پایگاه(های) داده میزبان
  • all - پرس‌وجو یا به‌روزرسانی هم پیکربندی زمان اجرا و هم پایگاه(های) داده میزبان
  • default - پرس‌وجو یا به‌روزرسانی منبع داده پیش‌فرض میزبان - بسته به دستور متفاوت است

دستور reservation-add امکان درج یک میزبان جدید را فراهم می‌کند. این دستور مجموعه‌ای از آرگومان‌ها را دریافت می‌کند که بسته به ماهیت رزرو میزبان متفاوت است. هر پارامتر مجاز در فایل پیکربندی که مربوط به رزرو میزبان باشد، در اینجا نیز مجاز است. برای جزئیات مربوط به رزروهای IPv4، بخش Host Reservations in DHCPv4 <#host-reservation-v4> را ببینید؛ برای رزروهای IPv6، بخش Host Reservations in DHCPv6 <#host-reservation-v6> را ببینید. پارامتر subnet-id اجباری است. از مقدار صفر (0) برای افزودن یک رزرو سراسری، یا شناسه (ID) زیرشبکه‌ای که رزرو باید به آن اضافه شود، استفاده کنید. این دستور می‌تواند به سادگیِ داشتن تنها دو مدخل اجباری باشد:

{
    "command": "reservation-add",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "hw-address": "1a:1b:1c:1d:1e:1f"
        }
    }
}

با این حال، در این حالت هیچ منبعی به میزبان اختصاص داده نمی‌شود. یک آدرس IPv4 را می‌توان مانند این مثال اختصاص داد:

{
    "command": "reservation-add",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "hw-address": "1a:1b:1c:1d:1e:1f",
            "ip-address": "192.0.2.202"
        }
    }
}

همچنین می‌تواند پارامترهای بسیار بیشتری را بپذیرد، مانند:

{
    "command": "reservation-add",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "client-id": "01:0a:0b:0c:0d:0e:0f",
            "ip-address": "192.0.2.205",
            "next-server": "192.0.2.1",
            "server-hostname": "hal9000",
            "boot-file-name": "/dev/null",
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "data": "10.1.1.202,10.1.1.203"
                }
            ],
            "client-classes": [ "special_snowflake", "office" ]
        }
    }
}

در اینجا یک مثال از رزرو پیچیده IPv6 آورده شده است:

{
    "command": "reservation-add",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "duid": "01:02:03:04:05:06:07:08:09:0A",
            "ip-addresses": [ "2001:db8:1:cafe::1" ],
            "prefixes": [ "2001:db8:2:abcd::/64" ],
            "hostname": "foo.example.com",
            "option-data": [
                {
                    "name": "vendor-opts",
                    "data": "4491"
                },
                {
                    "name": "tftp-servers",
                    "space": "vendor-4491",
                    "data": "3000:1::234"
                }
            ]
        }
    }
}

این دستور آرگومان operation-target را می‌پذیرد. به طور پیش‌فرض، رزرو را فقط به پایگاه داده میزبان‌ها اضافه می‌کند.

{
    "command": "reservation-add",
    "arguments": {
        "reservation": {},
        "operation-target": "all"
    }
}

این دستور وضعیتی را بازمی‌گرداند که نشان‌دهنده موفقیت (result 0) یا شکست (result 1) است. یک دستور ناموفق همیشه شامل یک پارامتر text است که علت شکست را توضیح می‌دهد. در اینجا یک نمونه از افزودن موفقیت‌آمیز آورده شده است:

{
    "result": 0,
    "text": "Host added."
}

و در اینجا یک مثال از شکست آورده شده است:

{
    "result": 1,
    "text": "Mandatory 'subnet-id' parameter missing."
}

از آنجا که انتظار می‌رود reservation-add میزبان را ذخیره کند، پارامتر hosts-databases باید در پیکربندی مشخص شده باشد و پایگاه‌های داده نباید در حالت فقط‌خواندنی (read-only) اجرا شوند.

نکته:

از نسخه 2.7.0 kea به بعد، یک رزرو خالی به صورت ضمنی سراسری است؛ یعنی اگر هیچ مدخل subnet-id وجود نداشته باشد و برای DHCPv4 پارامتر ip-address یا برای DHCPv6 پارامترهای ip-addresses و prefixes آدرس یا پیشوند رزروشده‌ای را مشخص نکنند، دستور معتبر است و یک رزرو میزبان سراسری (subnet-id 0) اضافه می‌کند.

از reservation-get می‌توان برای پرس‌وجوی پایگاه‌داده میزبان و بازیابی رزروهای موجود استفاده کرد. این دستور از دو نوع پارامتر پشتیبانی می‌کند: (subnet-id, address) یا (subnet-id, identifier-type, identifier). نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (چه IPv4 یا IPv6) مشخص است، اما جزئیات رزرو مشخص نیست. یک کاربرد رایج برای این نوع پرس‌وجو، بررسی رزرو بودن یک آدرس مشخص است. پرس‌وجوی دوم از شناسه‌ها استفاده می‌کند. برای بیشترین انعطاف‌پذیری، Kea اطلاعات شناسایی میزبان را به صورت یک جفت مقدار ذخیره می‌کند: نوع و شناسه واقعی. شناسه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از "hw-address"، "duid"، "circuit-id"، "client-id" و "flex-id". مقدار subnet-id اجباری است. برای دریافت یک رزرو سراسری، از مقدار صفر (0) استفاده کنید، یا شناسه زیرشبکه‌ای که رزرو متعلق به آن است را وارد نمایید.

یک نمونه دستور برای دریافت رزرو میزبان با یک جفت (subnet-id, address) به صورت زیر است:

{
    "command": "reservation-get",
    "arguments": {
        "subnet-id": 1,
        "ip-address": "192.0.2.202"
    }
}

یک نمونه پرس‌وجو بر اساس (subnet-id, identifier-type, identifier) به صورت زیر است:

{
    "command": "reservation-get",
    "arguments": {
        "subnet-id": 4,
        "identifier-type": "hw-address",
        "identifier": "01:02:03:04:05:06"
    }
}

این دستور آرگومان operation-target را می‌پذیرد. به طور پیش‌فرض، رزرو را هم از حافظه موقت و هم از پایگاه‌داده میزبان‌ها دریافت می‌کند.

{
    "command": "reservation-get",
    "arguments": {
        "subnet-id": 1,
        "ip-address": "192.0.2.202",
        "operation-target": "database"
    }
}

دستور reservation-get معمولاً هنگامی که یک پرس‌وجو به درستی انجام شده باشد نتیجه 0 را برمی‌گرداند. به ویژه، زمانی که میزبان پیدا نشود، مقدار 0 بازگردانده می‌شود. اگر پرس‌وجو موفقیت‌آمیز باشد، پارامترهای میزبان بازگردانده می‌شوند. نمونه‌ای از پرس‌وجویی که میزبان را پیدا نکرده است به صورت زیر است:

{ "result": 0, "text": "Host not found." }

در اینجا نمونه‌ای از نتیجه بازگردانده شده در صورت یافتن موفقیت‌آمیز میزبان آمده است:

{
  "arguments": {
    "boot-file-name": "bootfile.efi",
    "client-classes": [
    ],
    "hostname": "somehost.example.org",
    "hw-address": "01:02:03:04:05:06",
    "ip-address": "192.0.2.100",
    "next-server": "192.0.0.2",
    "option-data": [
    ],
    "server-hostname": "server-hostname.example.org",
    "subnet-id": 4
  },
  "result": 0,
  "text": "Host found."
}

نمونه نتیجه بازگردانده شده در زمانی که پرس‌وجو ساختار نادرستی داشته باشد ممکن است به این شکل باشد:

{ "result": 1, "text": "No 'ip-address' provided and 'identifier-type' is either missing or not a string." }

reservation-get-all می‌تواند برای پرس‌وجو از پایگاه‌دادهٔ میزبان و دریافت تمام رزروها در یک زیرشبکهٔ مشخص به کار رود. این دستور از پارامترهایی استفاده می‌کند که subnet-id اجباری را فراهم می‌کنند. رزروهای سراسری میزبان می‌توانند با استفاده از مقدار صفر (0) برای subnet-id دریافت شوند.

برای نمونه، دریافت رزروهای میزبان برای زیرشبکهٔ 1:

{
    "command": "reservation-get-all",
    "arguments": {
        "subnet-id": 1
     }
}

برخی میزبان‌های IPv4 را برمی‌گرداند:

{
    "arguments": {
        "hosts": [
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "somehost.example.org",
                "hw-address": "01:02:03:04:05:06",
                "ip-address": "192.0.2.100",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org",
                "subnet-id": 1
            },
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "otherhost.example.org",
                "hw-address": "01:02:03:04:05:ff",
                "ip-address": "192.0.2.200",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org",
                "subnet-id": 1
            },
            ...
        ]
    },
    "result": 0,
    "text": "72 IPv4 host(s) found."
}

پاسخ بازگردانده‌شده توسط reservation-get-all می‌تواند بسیار طولانی باشد. سرور DHCP هنگام آماده‌سازی پاسخ برای reservation-get-all ترافیک DHCP را پردازش نمی‌کند، بنابراین اگر رزروهای زیادی در یک زیرشبکه وجود داشته باشد، این کار ممکن است مختل‌کننده باشد؛ با احتیاط استفاده کنید. برای استقرارهای بزرگ‌تر، لطفاً استفاده از reservation-get-page را به عنوان جایگزین در نظر بگیرید.

این دستور آرگومان operation-target را می‌پذیرد. به‌طور پیش‌فرض، رزروها را از هر دو حافظهٔ مقیم و پایگاه‌دادهٔ میزبان‌ها دریافت می‌کند.

{
    "command": "reservation-get-all",
    "arguments": {
        "subnet-id": 1,
        "operation-target": "database"
    }
}

برای اطلاعات بیشتر، «دستور reservation-get-all» را ببینید.

reservation-get-page می‌تواند برای پرس‌وجو از پایگاه‌دادهٔ میزبان و دریافت تمام رزروها در یک زیرشبکهٔ مشخص، به‌صورت صفحه‌بندی‌شده به کار رود. این دستور از پارامترهایی استفاده می‌کند که subnet-id اجباری را فراهم می‌کنند. برای دریافت رزروهای سراسری از مقدار صفر (0) استفاده کنید. دومین پارامتر اجباری، حد اندازهٔ صفحه است. پارامترهای اختیاری source-index و from-host-id که هر دو به‌طور پیش‌فرض 0 هستند، برای زنجیره‌سازی پرسمان‌های صفحه‌ای استفاده می‌شوند. از نسخهٔ 1.9.0 نرم‌افزار Kea، پارامتر subnet-id اختیاری است.

استفاده از پارامترهای from و source-index نیازمند توضیحات بیشتری است. برای فراخوانی اول، نباید این پارامترها مشخص شوند (یا باید صفر تعیین شوند). برای هرگونه فراخوانی بعدی، آنها باید روی مقادیر بازگردانده‌شده در فراخوانی‌های قبلی در نگاشت next شامل مقادیر from و source-index تنظیم گردند. فراخوانی‌های بعدی باید تا زمانی که همهٔ رزروها برگردانده شوند، ارسال گردند. پایان زمانی حاصل می‌شود که فهرست بازگردانده‌شده خالی باشد، تعداد 0 باشد، هیچ نگاشت next وجود نداشته باشد، و وضعیت نتیجهٔ 3 (empty) بازگردانده شود.

نکته:

پارامترهای from و source-index بازتاب‌دهندهٔ وضعیت درونی جست‌وجو هستند. نیازی به درک معنای آن‌ها نیست؛ تنها مقداری هستند که باید از یک پاسخ به پرسمان بعدی کپی شوند. با این حال، برای علاقه‌مندان، فیلد from یک نمایش ۶۴ بیتی از شناسهٔ میزبان است که توسط یک بک‌اند میزبان استفاده می‌شود. فیلد source-index یک نمایش درونی از چندین بک‌اند میزبان است: 0 برای نشان دادن میزبان‌های تعریف‌شده در یک فایل پیکربندی به کار می‌رود، و 1 نشان‌دهندهٔ نخستین بک‌اند پایگاه‌داده است. در برخی موارد نادر ممکن است بیش از یک بک‌اند پایگاه‌داده پیکربندی شده باشد، بنابراین احتمالاً مقدار 2 نیز وجود دارد. در هر صورت، Kea روی تمام بک‌اندهای پیکربندی‌شده پیمایش می‌کند.

برای نمونه، دریافت رزروهای میزبان برای زیرشبکهٔ 1 و درخواست صفحهٔ نخست می‌تواند به این صورت انجام شود:

{
    "command": "reservation-get-page",
    "arguments": {
        "subnet-id": 1,
        "limit": 10
     }
}

از آنجا که این اولین فراخوانی است، source-index و from نباید مشخص شوند. آن‌ها روی مقادیر پیش‌فرض صفر خود تنظیم شده‌اند.

تعدادی میزبان همراه با اطلاعات برای دریافت صفحهٔ بعدی بازگردانده می‌شوند:

{
    "arguments": {
        "count": 72,
        "hosts": [
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "somehost.example.org",
                "hw-address": "01:02:03:04:05:06",
                "ip-address": "192.0.2.100",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org"
            },
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "otherhost.example.org",
                "hw-address": "01:02:03:04:05:ff",
                "ip-address": "192.0.2.200",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org"
            },
            ...
        ],
        "next": {
            "from": 1234567,
            "source-index": 1
        }
    },
    "result": 0,
    "text": "72 IPv4 host(s) found."
}

توجه داشته باشید که فیلدهای from و source-index در پاسخ، داخل نگاشت next مشخص شده‌اند. این دو باید در دستور بعدی کپی شوند تا Kea کار را از همان جایی که دستور قبلی به پایان رسید ادامه دهد. برای دریافت صفحهٔ بعدی دستور زیر می‌تواند ارسال شود:

{
    "command": "reservation-get-page",
    "arguments": {
        "subnet-id": 1,
        "source-index": 1,
        "from": 1234567,
        "limit": 10
     }
}

پاسخ شامل فهرستی از میزبان‌ها با فیلدهای به‌روزشدهٔ source-index و from خواهد بود. فراخوانی دستور را ادامه دهید تا آخرین صفحه دریافت شود. پاسخ آن به این شکل خواهد بود:

{
    "arguments": {
        "count": 0,
        "hosts": [ ]
    },
    "result": 3,
    "text": "0 IPv4 host(s) found."
}

این دستور آرگومان operation-target را نمی‌پذیرد.

این دستور پیچیده‌تر از reservation-get-all است، اما به کاربران اجازه می‌دهد فهرست‌های بزرگ‌تر رزرو میزبان را در بخش‌های کوچک‌تر دریافت کنند. برای استقرارهای کوچک با رزروهای اندک، استفاده از reservation-get-all ساده‌تر است..SS دستور reservation-get-by-address

دستور reservation-get-by-address می‌تواند برای پرس‌وجو از پایگاه داده میزبان و دریافت تمام رزروها برای یک نشانی IP مشخص یا یک پیشوند واگذارشده (بدون طول پیشوند)، در یک زیرشبکه تعیین‌شده یا در تمامی زیرشبکه‌ها استفاده شود. این دستور از پارامترهایی استفاده می‌کند که پارامتر اجباری ip-address و پارامترهای اختیاری subnet-id و operation-target را فراهم می‌آورند.

به عنوان مثال، دریافت رزروهای میزبان برای نشانی IPv4 با مقدار "192.0.200.181" در زیرشبکه ۱:

{
    "command": "reservation-get-by-address",
    "arguments": {
        "ip-address": "192.0.200.181",
        "subnet-id": 1
    },
    "service": [
        "dhcp4"
    ]
}

می‌تواند دو میزبان IPv4 را بازگرداند:

{
    "arguments": {
        "hosts": [
            {
                "boot-file-name": "",
                "client-classes": [],
                "hostname": "",
                "hw-address": "99:99:99:99:99:01",
                "ip-address": "192.0.200.181",
                "next-server": "0.0.0.0",
                "option-data": [],
                "server-hostname": "",
                "subnet-id": 1
            },
            {
                "boot-file-name": "",
                "circuit-id": "1234",
                "client-classes": [],
                "hostname": "",
                "ip-address": "192.0.200.181",
                "next-server": "0.0.0.0",
                "option-data": [],
                "server-hostname": "",
                "subnet-id": 1
            }
        ]
    },
    "result": 0,
    "text": "2 IPv4 host(s) found."
}

برای جستجوی تمامی رزروها در همه زیرشبکه‌ها، کافی است از پارامتر subnet-id صرف‌نظر کنید:

{
    "command": "reservation-get-by-address",
    "arguments": {
        "ip-address": "192.0.200.181"
    },
    "service": [
        "dhcp4"
    ]
}

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

{
    "arguments": {
        "hosts": [
            {
                "boot-file-name": "",
                "client-classes": [],
                "hostname": "",
                "hw-address": "99:99:99:99:99:02",
                "ip-address": "192.0.200.181",
                "next-server": "0.0.0.0",
                "option-data": [],
                "server-hostname": "",
                "subnet-id": 1
            },
            {
                "boot-file-name": "",
                "circuit-id": "1234",
                "client-classes": [],
                "hostname": "",
                "ip-address": "192.0.200.181",
                "next-server": "0.0.0.0",
                "option-data": [],
                "server-hostname": "",
                "subnet-id": 1
            },
            {
                "boot-file-name": "",
                "client-classes": [],
                "hostname": "",
                "hw-address": "99:99:99:99:99:02",
                "ip-address": "192.0.200.181",
                "next-server": "0.0.0.0",
                "option-data": [],
                "server-hostname": "",
                "subnet-id": 0
            },
            {
                "boot-file-name": "",
                "client-classes": [],
                "hostname": "",
                "hw-address": "99:99:99:99:99:03",
                "ip-address": "192.0.200.181",
                "next-server": "0.0.0.0",
                "option-data": [],
                "server-hostname": "",
                "subnet-id": 2
            }
        ]
    },
    "result": 0,
    "text": "4 IPv4 host(s) found."
}

هنگام استفاده از این دستور برای دریافت رزروهای میزبان DHCP6، می‌توان یک نشانی IPv6 یا یک پیشوند واگذارشده (delegated prefix) را به عنوان پارامتر ip-address ارائه داد. لطفاً توجه داشته باشید که این دستور در پیاده‌سازی فعلی طول پیشوند را به عنوان پارامتر نمی‌پذیرد. بنابراین، جستجو بر اساس نشانی IP مانند 2001:db8:2:cafe:: می‌تواند رزروهای میزبانی با پیشوندهای واگذارشده با طول‌های متفاوتی که با این جستجو مطابقت دارند را برگرداند. برای مثال: 2001:db8:2:cafe::/63، 2001:db8:2:cafe::/64 و غیره. لطفاً مثال زیر را در نظر بگیرید:

{
    "command": "reservation-get-by-address",
    "arguments": {
        "ip-address": "2001:db8:2:cafa::"
    },
    "service": [
        "dhcp6"
    ]
}

پاسخ:

{
    "arguments": {
        "hosts": [
            {
                "client-classes": [],
                "duid": "01:02:03:04:05:06:07:88:98:fa",
                "hostname": "foo.example.com",
                "ip-addresses": [
                    "2001:db8:1:cafe::2"
                ],
                "option-data": [],
                "prefixes": [
                    "2001:db8:2:abcd::/64",
                    "2001:db8:2:cafa::/63"
                ],
                "subnet-id": 8
            },
            {
                "client-classes": [],
                "duid": "01:02:03:04:05:06:07:88:98:fb",
                "hostname": "foo.example.com",
                "ip-addresses": [
                    "2001:db8:1:cafe::2"
                ],
                "option-data": [],
                "prefixes": [
                    "2001:db8:2:abcd::/64",
                    "2001:db8:2:cafa::/64"
                ],
                "subnet-id": 8
            }
        ]
    },
    "result": 0,
    "text": "2 IPv6 host(s) found."
}

این دستور آرگومان operation-target را می‌پذیرد. به طور پیش‌فرض، این دستور رزرو را هم از فضای ذخیره‌سازی در حافظه (in-memory) و هم از پایگاه داده میزبان‌ها دریافت می‌کند.

{
    "command": "reservation-get-by-address",
    "arguments": {
        "ip-address": "192.0.200.181",
        "subnet-id": 1,
        "operation-target": "database"
    },
    "service": [
        "dhcp4"
    ]
}

نکته:

این دستور در موارد خاصی کاربرد دارد. به طور پیش‌فرض، داشتن بیش از یک رزرو میزبان برای یک نشانی IP یکسان در یک زیرشبکه معین مجاز نیست؛ همان‌طور که در Multiple Reservations for the Same IPv4 <#multiple-reservations-same-ip4> یا Multiple Reservations for the Same IPv6 <#multiple-reservations-same-ip6> توضیح داده شده است. به همین دلیل این دستور زمانی به کار می‌آید که پارامتر بولی ip-reservations-unique روی false تنظیم شده باشد. کاربرد دیگر این دستور در زمان وجود زیرشبکه‌های دارای هم‌پوشانی با رزروهای نشانی IP یکسان (اما با شناسه‌های متفاوت) در زیرشبکه‌های مختلف است.

از reservation-get-by-hostname می‌توان برای پرس‌وجو در پایگاه دادهٔ میزبان و واکشی تمام رزروها با یک نام میزبان مشخص یا در یک زیرشبکهٔ تعیین‌شده استفاده کرد. این دستور از پارامترهایی استفاده می‌کند که hostname اجباری و subnet-id اختیاری را فراهم می‌کنند. رزروهای سراسری میزبان را می‌توان با استفاده از مقدار صفر (0) برای subnet-id واکشی کرد. تطابق نام میزبان به بزرگی و کوچکی حروف حساس نیست.

برای نمونه، واکشی رزروهای میزبان برای "foobar" در زیرشبکهٔ 1:

{
    "command": "reservation-get-by-hostname",
    "arguments": {
        "hostname": "foobar.example.org",
        "subnet-id": 1
     }
}

برخی از میزبان‌های IPv4 را بازمی‌گرداند:

{
    "arguments": {
        "hosts": [
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "foobar.example.org",
                "hw-address": "01:02:03:04:05:06",
                "ip-address": "192.0.2.100",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org"
            },
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "foobar.example.org",
                "hw-address": "01:02:03:04:05:ff",
                "ip-address": "192.0.2.200",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org"
            },
            ...
        ]
    },
    "result": 0,
    "text": "5 IPv4 host(s) found."
}

پاسخ بازگردانده شده توسط reservation-get-by-hostname می‌تواند طولانی باشد، به‌ویژه زمانی که پاسخ‌ها به یک زیرشبکه محدود نشده باشند.

این دستور آرگومان operation-target را می‌پذیرد. به‌طور پیش‌فرض، رزرو را هم از حافظهٔ موقت و هم از پایگاه دادهٔ میزبان‌ها دریافت می‌کند.

{
    "command": "reservation-get-by-hostname",
    "arguments": {
        "hostname": "foobar.example.org",
        "subnet-id": 1,
        "operation-target": "database"
    }
}

برای اطلاعات بیشتر، بخش دستور reservation-get-by-hostname را ببینید.

نکته:

هنگام استفاده از MySQL به‌عنوان بک‌اند میزبان، این دستور به این موضوع متکی است که ستون hostname در جدول hosts از یک چینش (collation) غیرحساس به حروف بزرگ و کوچک استفاده می‌کند، همان‌طور که در بخش MySQL <#mysql-database> از مستندات Kea Database Administration <#admin> توضیح داده شده است.

از reservation-get-by-id می‌توان برای پرس‌وجو در پایگاه دادهٔ میزبان و واکشی تمام رزروها با یک شناسه‌گر مشخص (پارامترهای identifier-type و identifier)، مستقل از زیرشبکه‌ها استفاده کرد. ساختار نحوی پارامترها همانند دستور reservation-get است. برای جلوگیری از سردرگمی، امکان استفاده از پارامتر subnet-id وجود ندارد. این دستور از نسخهٔ 1.9.0 در Kea در دسترس است.

برای نمونه، واکشی رزروهای میزبان برای نشانی مک 01:02:03:04:05:06:

{
    "command": "reservation-get-by-id",
    "arguments": {
        "identifier-type": "hw-address",
        "identifier": "01:02:03:04:05:06"
     }
 }

برخی از میزبان‌های IPv4 را بازمی‌گرداند:

{
    "arguments": {
        "hosts": [
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "foo.example.org",
                "hw-address": "01:02:03:04:05:06",
                "ip-address": "192.0.2.100",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org",
                "subnet-id": 123
            },
            {
                "boot-file-name": "bootfile.efi",
                "client-classes": [ ],
                "hostname": "bar.example.org",
                "hw-address": "01:02:03:04:05:06",
                "ip-address": "192.0.2.200",
                "next-server": "192.0.0.2",
                "option-data": [ ],
                "server-hostname": "server-hostname.example.org",
                "subnet-id": 345
            },
            ...
        ]
    },
    "result": 0,
    "text": "5 IPv4 host(s) found."
}

پاسخ بازگردانده شده توسط reservation-get-by-id می‌تواند طولانی باشد، به‌ویژه زمانی که پاسخ‌ها به یک زیرشبکه محدود نشده باشند.

این دستور آرگومان operation-target را می‌پذیرد. به‌طور پیش‌فرض، رزرو را هم از حافظهٔ موقت و هم از پایگاه دادهٔ میزبان‌ها واکشی می‌کند.

{
    "command": "reservation-get-by-id",
    "arguments": {
        "identifier-type": "hw-address",
        "identifier": "01:02:03:04:05:06",
        "operation-target": "database"
    }
}

برای اطلاعات بیشتر، بخش دستور reservation-get-by-id را ببینید..SS دستور reservation-del

دستور reservation-del می‌تواند برای حذف یک رزرو از پایگاه‌داده میزبان‌ها و/یا پیکربندی JSON استفاده شود. این دستور از دو نوع پارامتر پشتیبانی می‌کند: (subnet-id, address) یا (subnet-id, identifier-type, identifier). نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (خواه IPv4 یا IPv6) مشخص است، اما جزئیات رزرو مشخص نیست. یکی از کاربردهای رایج این نوع پرس‌وجو، حذف یک رزرو است (به عنوان مثال، یک آدرس مشخص دیگر نباید رزرو بماند). پرس‌وجوی دوم از شناسه‌ها استفاده می‌کند. برای حداکثر انعطاف‌پذیری، Kea اطلاعات شناسایی میزبان را به صورت یک جفت مقدار ذخیره می‌کند: نوع و شناسه واقعی. شناسه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از "hw-address"، "duid"، "circuit-id"، "client-id" و "flex-id". مقدار subnet-id الزامی است. از مقدار صفر (0) برای حذف یک رزرو سراسری (global)، یا شناسه زیرشبکه‌ای که رزرو باید از آن حذف شود، استفاده کنید.

یک نمونه دستور برای حذف یک رزرو میزبان با جفت (subnet-id, address) به صورت زیر است:

{
    "command": "reservation-del",
    "arguments": {
        "subnet-id": 1,
        "ip-address": "192.0.2.202"
    }
}

یک نمونه حذف بر اساس (subnet-id, identifier-type, identifier) به صورت زیر است:

{
    "command": "reservation-del",
    "arguments": {
        "subnet-id": 4,
        "identifier-type": "hw-address",
        "identifier": "01:02:03:04:05:06"
    }
}

دستور reservation-del در صورت موفقیت‌آمیز بودن حذف میزبان مقدار 0، و در صورت شکست مقدار 1 را برمی‌گرداند. در صورت بروز خطا، متن توضیحی ارائه می‌شود. در اینجا چند نمونه از نتایج احتمالی آورده شده است:

{
    "result": 1,
    "text": "Host not deleted (not found)."
}

یا

{
    "result": 0,
    "text": "Host deleted."
}

یا

{
    "result": 1,
    "text": "Unable to delete a host because there is no hosts-database configured."
}

این دستور آرگومان operation-target را می‌پذیرد. به طور پیش‌فرض، رزرو را فقط از پایگاه‌داده میزبان‌ها حذف می‌کند.

{
    "command": "reservation-del",
    "arguments": {
        "subnet-id": 4,
        "identifier-type": "hw-address",
        "identifier": "01:02:03:04:05:06",
        "operation-target": "memory"
    }
}

دستور reservation-update امکان به‌روزرسانی یک میزبان موجود را فراهم می‌کند. این دستور همان مجموعه آرگومان‌های reservation-add را دریافت می‌کند و همچنین برای شناسایی میزبانی که به‌روزرسانی می‌شود، به یک شناسه میزبان و یک شناسه زیرشبکه (subnet ID) نیاز دارد. این دستور می‌تواند به سادگیِ داشتن تنها دو مدخل الزامی باشد:

{
    "command": "reservation-update",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "hw-address": "1a:1b:1c:1d:1e:1f"
        }
    }
}

با این حال، در این حالت هیچ منبعی به میزبان اختصاص داده نمی‌شود. یک آدرس IPv4 را می‌توان مانند این مثال اختصاص داد:

{
    "command": "reservation-update",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "hw-address": "1a:1b:1c:1d:1e:1f",
            "ip-address": "192.0.2.202"
        }
    }
}

همچنین می‌تواند پارامترهای بسیار بیشتری را بپذیرد، مانند:

{
    "command": "reservation-update",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "client-id": "01:0a:0b:0c:0d:0e:0f",
            "ip-address": "192.0.2.205",
            "next-server": "192.0.2.1",
            "server-hostname": "hal9000",
            "boot-file-name": "/dev/null",
            "option-data": [
                {
                    "name": "domain-name-servers",
                    "data": "10.1.1.202,10.1.1.203"
                }
            ],
            "client-classes": [
                "office",
                "special_snowflake"
            ]
        }
    }
}

در اینجا نمونه‌ای از یک به‌روزرسانی رزرو پیچیده IPv6 آورده شده است:

{
    "command": "reservation-update",
    "arguments": {
        "reservation": {
            "subnet-id": 1,
            "duid": "01:02:03:04:05:06:07:08:09:0A",
            "ip-addresses": [
                "2001:db8:1:cafe::1"
            ],
            "prefixes": [
                "2001:db8:2:abcd::/64"
            ],
            "hostname": "foo.example.com",
            "option-data": [
                {
                    "name": "vendor-opts",
                    "data": "4491"
                },
                {
                    "name": "tftp-servers",
                    "space": "vendor-4491",
                    "data": "3000:1::234"
                }
            ]
        }
    }
}

دستور وضعیتی را بازمی‌گرداند که نشان‌دهنده موفقیت (نتیجه 0) یا شکست (نتیجه 1) است، و یک پارامتر متنی که موفقیت را تأیید کرده یا علت شکست را توضیح می‌دهد. در اینجا نمونه‌ای از یک به‌روزرسانی موفق آورده شده است:

{
    "result": 0,
    "text": "Host updated."
}

و در اینجا نمونه‌ای از یک شکست آمده است:

{
    "result": 1,
    "text": "Mandatory 'subnet-id' parameter missing."
}

این دستور آرگومان operation-target را می‌پذیرد. به طور پیش‌فرض، رزرو را تنها به پایگاه‌داده میزبان‌ها اضافه می‌کند. از آنجا که انتظار می‌رود reservation-update میزبان را ذخیره کند، پارامتر hosts-databases باید در پیکربندی مشخص شده باشد، و اگر هدف عملیات پیکربندی JSON نباشد، پایگاه‌های داده نباید در حالت فقط‌خواندنی (read-only) اجرا شوند.

همانند سایر دستورهای به‌روزرسانی و تنظیم، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر میزبان قبلاً منبعی به آن اختصاص داده شده بود و دستور reservation-update فاقد آن منبع باشد، آن منبع از پایگاه‌داده حذف می‌شود. اگر به‌روزرسانی افزایشی میزبان مد نظر باشد، این امر می‌تواند با اجرای دستور reservation-get-by-id برای دریافت وضعیت فعلی میزبان، انتخاب میزبان از پاسخ، اصلاح آن به نتیجه مورد نظر و سپس اجرای دستور reservation-update به همراه میزبان حاصل انجام گیرد..SS نکات کلی (General Mentions)

نکته:

بک‌اندهای میزبان برای کتابخانه‌های قلابِ حافظهٔ پنهان میزبان (host cache) و RADIUS به دستورهایی که مجموعه‌ای از رزروهای میزبان را برمی‌گردانند، مانند reservation-get-all، پاسخ نمی‌دهند. در عوض باید از دستورهایی که یک مدخل میزبان را برمی‌گردانند یا دستورهای اختصاصی حافظهٔ پنهان میزبان استفاده شود.

Kea به کاربران امکان می‌دهد اطلاعات اجاره (lease) را در چندین بک‌اند (memfile، MySQL و PostgreSQL) ذخیره کنند، و کتابخانهٔ Lease Commands رابطی فراهم می‌سازد که می‌تواند اجاره‌ها را به شیوه‌ای یکپارچه و ایمن دستکاری کند. به‌ویژه، انجام کارهایی را ممکن می‌سازد که پیش‌تر غیرممکن بودند: دستکاری اجاره در memfile در زمان اجرای Kea، بررسی صحت تغییرات (sanity check)، بررسی وجود اجاره، و حذف تمامی اجاره‌های متعلق به یک زیرشبکهٔ (subnet) خاص. این کتابخانهٔ قلاب همچنین می‌تواند خطاهای مبهم‌تر را شناسایی کند، مانند تلاش برای افزودن یک اجاره با یک subnet-id که در پیکربندی وجود ندارد، یا پیکربندی یک اجاره برای استفاده از نشانی‌ای که خارج از زیرشبکهٔ تعیین‌شده قرار دارد. این کتابخانه همچنین روشی غیربرنامه‌نویسی برای مدیریت بافتارهای کاربری (user contexts) مرتبط با اجاره‌ها ارائه می‌دهد.

از Kea 2.7.7، این کتابخانه همچنین از binding-variables پشتیبانی می‌کند. متغیرهای مقیدسازی (Binding variables) به کاربر امکان می‌دهند مقادیر سفارشی را برای هر اجاره ذخیره کند. این متغیرها در این بخش بررسی شده‌اند: Binding Variables.

نکته:

libdhcp_lease_cmds.so بخشی از کد متن‌باز است و در دسترس تمام کاربران Kea قرار دارد.

نکته:

این کتابخانه تنها می‌تواند توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

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

این کتابخانه دستورهای زیر را ارائه می‌دهد:

  • lease4-add - یک اجارهٔ IPv4 جدید اضافه می‌کند.
  • lease6-add - یک اجارهٔ IPv6 جدید اضافه می‌کند.
  • lease6-bulk-apply - چندین اجارهٔ IPv6 را در یک تراکنش منفرد ایجاد، به‌روزرسانی، و/یا حذف می‌کند.
  • lease4-get - بررسی می‌کند که آیا یک اجارهٔ IPv4 با پارامترهای مشخص‌شده وجود دارد یا خیر و در صورت وجود آن را برمی‌گرداند.
  • lease6-get - بررسی می‌کند که آیا یک اجارهٔ IPv6 با پارامترهای مشخص‌شده وجود دارد یا خیر و در صورت وجود آن را برمی‌گرداند.
  • lease4-get-all - تمام اجاره‌های IPv4 یا تمام اجاره‌های IPv4 زیرشبکه‌های مشخص‌شده را برمی‌گرداند.
  • lease6-get-all - تمام اجاره‌های IPv6 یا تمام اجاره‌های IPv6 زیرشبکه‌های مشخص‌شده را برمی‌گرداند.
  • lease4-get-page - مجموعه‌ای ("صفحه") از اجاره‌ها را از فهرست تمامی اجاره‌های IPv4 در پایگاه‌داده برمی‌گرداند. با پیمایش صفحات می‌توان تمامی اجاره‌ها را بازیابی کرد.
  • lease6-get-page - مجموعه‌ای ("صفحه") از اجاره‌ها را از فهرست تمامی اجاره‌های IPv6 در پایگاه‌داده برمی‌گرداند. با پیمایش صفحات می‌توان تمامی اجاره‌ها را بازیابی کرد.
  • lease4-get-by-hw-address - تمام اجاره‌های IPv4 با نشانی سخت‌افزاری مشخص‌شده را برمی‌گرداند.
  • lease6-get-by-hw-address - تمام اجاره‌های IPv6 با نشانی سخت‌افزاری مشخص‌شده را برمی‌گرداند.
  • lease4-get-by-client-id - تمام اجاره‌های IPv4 با client-id مشخص‌شده را برمی‌گرداند.
  • lease6-get-by-duid - تمام اجاره‌های IPv6 با DUID مشخص‌شده را برمی‌گرداند.
  • lease4-get-by-state - تمام اجاره‌های IPv4 با وضعیت مشخص‌شده را برمی‌گرداند.
  • lease6-get-by-state - تمام اجاره‌های IPv6 با وضعیت مشخص‌شده را برمی‌گرداند.
  • lease4-get-by-hostname - تمام اجاره‌های IPv4 با نام میزبان مشخص‌شده را برمی‌گرداند.
  • lease6-get-by-hostname - تمام اجاره‌های IPv6 با نام میزبان مشخص‌شده را برمی‌گرداند.
  • lease4-del - یک اجارهٔ IPv4 با پارامترهای مشخص‌شده را حذف می‌کند.
  • lease6-del - یک اجارهٔ IPv6 با پارامترهای مشخص‌شده را حذف می‌کند.
  • lease4-update - یک اجارهٔ IPv4 موجود را به‌روزرسانی (جایگزین) می‌کند.
  • lease6-update - یک اجارهٔ IPv6 موجود را به‌روزرسانی (جایگزین) می‌کند.
  • lease4-wipe - تمام اجاره‌ها را از یک زیرشبکهٔ IPv4 خاص یا از تمام زیرشبکه‌ها حذف می‌کند.
  • lease6-wipe - تمام اجاره‌ها را از یک زیرشبکهٔ IPv6 خاص یا از تمام زیرشبکه‌ها حذف می‌کند.
  • lease4-resend-ddns - درخواست به‌روزرسانی مدخل‌های DNS را برای یک اجارهٔ موجود دوباره ارسال می‌کند.
  • lease6-resend-ddns - درخواست به‌روزرسانی مدخل‌های DNS را برای یک اجارهٔ موجود دوباره ارسال می‌کند.
  • lease4-write - پایگاه‌دادهٔ اجاره‌های memfile مربوط به IPv4 را درون یک فایل می‌نویسد.
  • lease6-write - پایگاه‌دادهٔ اجاره‌های memfile مربوط به IPv6 را درون یک فایل می‌نویسد.
  • sflq-pool4-rebuild - یک استخر SFLQ مربوط به IPv4 را در بک‌اند اجاره بازسازی می‌کند.
  • sflq-pool6-rebuild - یک استخر SFLQ مربوط به IPv6 را در بک‌اند اجاره بازسازی می‌کند.
  • sflq-pool4-get-all - تمام استخرهای SFLQ مربوط به IPv4 را از بک‌اند اجاره واکشی می‌کند.
  • sflq-pool6-get-all - تمام استخرهای SFLQ مربوط به IPv6 را از بک‌اند اجاره واکشی می‌کند.
  • sflq-pool4-get-by-subnet - تمام استخرهای SFLQ مربوط به IPv4 متعلق به یک زیرشبکه را از بک‌اند اجاره واکشی می‌کند.
  • sflq-pool6-get-by-subnet - تمام استخرهای SFLQ مربوط به IPv6 متعلق به یک زیرشبکه را از بک‌اند اجاره واکشی می‌کند.
  • sflq-pool4-get-by-range - تمام استخرهای SFLQ مربوط به IPv4 که با یک محدودهٔ نشانی هم‌پوشانی دارند را از بک‌اند اجاره واکشی می‌کند.
  • sflq-pool6-get-by-range - تمام استخرهای SFLQ مربوط به IPv6 که با یک محدودهٔ نشانی هم‌پوشانی دارند را از بک‌اند اجاره واکشی می‌کند.
  • sflq-pool4-del - یک استخر SFLQ مربوط به IPv4 مطابق با یک محدودهٔ نشانی را از بک‌اند اجاره حذف می‌کند.
  • sflq-pool6-del - یک استخر SFLQ مربوط به IPv6 مطابق با یک محدودهٔ نشانی را از بک‌اند اجاره حذف می‌کند.

تمامی دستورها از نحو JSON استفاده می‌کنند و می‌توان آن‌ها را از طریق کانال کنترل (ببینید Management API <#ctrl-channel>) صادر کرد.

این کتابخانه را می‌توان به همان شیوهٔ سایر کتابخانه‌های قلاب بارگذاری کرد و هیچ پارامتری دریافت نمی‌کند. این کتابخانه از هر دو سرور DHCPv4 و DHCPv6 پشتیبانی می‌کند.

"Dhcp6": {
    "hooks-libraries": [
        {
            "library": "libdhcp_lease_cmds.so"
        },
        ...
    ]
}

دستورهای lease4-add و lease6-add امکان ایجاد یک اجاره (lease) جدید را فراهم می‌کنند. به طور معمول Kea هنگامی که دستگاه جدیدی را برای نخستین بار مشاهده می‌کند یک اجاره ایجاد می‌نماید؛ با این حال، گاهی ممکن است ایجاد دستی اجاره سودمند باشد. دستور lease4-add حداقل به دو پارامتر نیاز دارد: یک نشانی IPv4 و یک شناسه، یعنی نشانی سخت‌افزاری (MAC). پارامتر سوم، subnet-id، اختیاری است. اگر subnet-id مشخص نشده باشد یا مقدار مشخص‌شده 0 باشد، Kea تلاش می‌کند با اجرای یک فرایند انتخاب زیرشبکه، مقدار آن را تعیین کند. با این حال، در صورت تعیین، مقدار آن باید با زیرشبکه موجود همخوانی داشته باشد. ساده‌ترین فراخوانی موفق ممکن است به شکل زیر باشد:

{
    "command": "lease4-add",
    "arguments": {
        "ip-address": "192.0.2.202",
        "hw-address": "1a:1b:1c:1d:1e:1f"
    }
}

دستور lease6-add به سه پارامتر نیاز دارد: یک نشانی IPv6، یک مقدار IAID (شناسه ارتباط هویتی، مقداری که توسط کلاینت‌ها ارسال می‌شود)، و یک DUID. همانند lease4-add، پارامتر subnet-id اختیاری است. اگر subnet-id مشخص نشده باشد یا مقدار ارائه‌شده 0 باشد، Kea تلاش می‌کند با اجرای یک فرایند انتخاب زیرشبکه مقدار آن را تعیین کند. با این حال، در صورت مشخص شدن، مقدار آن باید با زیرشبکه موجود مطابقت داشته باشد. برای مثال:

{
    "command": "lease6-add",
    "arguments": {
        "subnet-id": 66,
        "ip-address": "2001:db8::3",
        "duid": "1a:1b:1c:1d:1e:1f:20:21:22:23:24",
        "iaid": 1234
    }
}

دستور lease6-add همچنین می‌تواند برای افزودن اجاره‌ها برای پیشوندهای IPv6 استفاده شود. در این حالت سه پارامتر دیگر وجود دارد که باید مشخص شوند: subnet-id، type (تنظیم‌شده بر روی "IA_PD")، و طول پیشوند. پیشوند اصلی با استفاده از فیلد ip-address تنظیم می‌شود. توجه داشته باشید که Kea نمی‌تواند مقادیر subnet-id را برای پیشوندها حدس بزند؛ این مقادیر باید صریحاً مشخص شوند. برای نمونه، برای پیکربندی یک اجاره برای پیشوند 2001:db8:abcd::/48، می‌توان از دستور زیر استفاده کرد:

{
    "command": "lease6-add",
    "arguments": {
        "subnet-id": 66,
        "type": "IA_PD",
        "ip-address": "2001:db8:abcd::",
        "prefix-len": 48,
        "duid": "1a:1b:1c:1d:1e:1f:20:21:22:23:24",
        "iaid": 1234
    }
}

این دستورها می‌توانند چندین پارامتر اختیاری اضافی دریافت کنند:

  • valid-lft - طول عمر اجاره را بر حسب ثانیه مشخص می‌کند. در صورت عدم تعیین، از مقدار پیکربندی‌شده در زیرشبکه مربوط به subnet-id مشخص‌شده استفاده می‌شود.
  • expire - یک مهر زمانی از زمان انقضای اجاره بر حسب قالب یونیکس (ثانیه‌ها از ۱ ژانویه ۱۹۷۰) ایجاد می‌کند. در صورت عدم تعیین، مقدار پیش‌فرض زمان فعلی به علاوه طول عمر اجاره (مقدار valid-lft) خواهد بود.
  • fqdn-fwd - مشخص می‌کند که آیا اجاره باید طوری علامت‌گذاری شود که گویی یک به‌روزرسانی مستقیم DNS انجام شده است یا خیر. این مورد فقط بر داده‌های ذخیره‌شده در پایگاه‌داده اجاره اثر می‌گذارد و هیچ به‌روزرسانی DNS انجام نخواهد شد. در صورت پیکربندی، هنگام حذف اجاره به دلیل انقضا یا آزادسازی توسط یک کلاینت، یک به‌روزرسانی DNS برای حذف رکوردهای A یا AAAA انجام خواهد شد. در صورت عدم تعیین، مقدار پیش‌فرض false است. در صورتی که fqdn-fwd بر روی true تنظیم شده باشد، پارامتر hostname باید مشخص گردد.
  • fqdn-rev - مشخص می‌کند که آیا اجاره باید طوری علامت‌گذاری شود که گویی یک به‌روزرسانی معکوس DNS انجام شده است یا خیر. این مورد فقط بر داده‌های ذخیره‌شده در پایگاه‌داده اجاره اثر می‌گذارد و هیچ به‌روزرسانی DNS انجام نخواهد شد. در صورت پیکربندی، هنگام حذف اجاره به دلیل انقضا یا آزادسازی توسط یک کلاینت، یک به‌روزرسانی DNS برای حذف رکورد PTR انجام خواهد شد. در صورت عدم تعیین، مقدار پیش‌فرض false است. در صورتی که fqdn-fwd بر روی true تنظیم شده باشد، پارامتر hostname باید مشخص گردد.
  • hostname - نام میزبان (hostname) مرتبط با این اجاره را مشخص می‌کند. در صورتی که هر یک از fqdn-fwd یا fqdn-rev بر روی true تنظیم شده باشند، مقدار آن نباید خالی باشد. در صورت عدم تعیین، مقدار پیش‌فرض یک رشته خالی است.
  • hw-address - به صورت اختیاری نشانی سخت‌افزاری (MAC) را برای یک اجاره IPv6 مشخص می‌کند. این پارامتر برای اجاره IPv4 اجباری است.
  • client-id - به صورت اختیاری یک شناسه کلاینت را برای یک اجاره IPv4 مشخص می‌کند.
  • preferred-lft - به صورت اختیاری طول عمر ترجیحی را برای اجاره‌های IPv6 مشخص می‌کند. در صورت عدم تعیین، از مقدار پیکربندی‌شده برای زیرشبکه متناظر با subnet-id مشخص‌شده استفاده می‌شود. این پارامتر هنگام افزودن اجاره IPv4 استفاده نمی‌شود.
  • state - وضعیت یک اجاره افزوده‌شده را مشخص می‌کند که می‌تواند 0 برای default، 1 برای declined، 2 برای expired-reclaimed و 3 برای وضعیت released باشد. هر مقدار دیگری باعث خطا می‌شود. استفاده از 1 برای نوع اجاره "IA_PD" غیرمجاز است و رد خواهد شد.
  • user-context - بافت کاربری (user context) مرتبط با این اجاره را مشخص می‌کند. این مقدار باید یک نگاشت JSON باشد.

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

{
    "command": "lease6-add",
    "arguments": {
        "subnet-id": 66,
        "ip-address": "2001:db8::3",
        "duid": "01:02:03:04:05:06:07:08",
        "iaid": 1234,
        "hw-address": "1a:1b:1c:1d:1e:1f",
        "preferred-lft": 500,
        "valid-lft": 1000,
        "expire": 12345678,
        "fqdn-fwd": true,
        "fqdn-rev": true,
        "state": 0,
        "hostname": "urania.example.org",
        "user-context": { "version": 1 }
    }
}

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

{ "result": 0, "text": "Lease added." }

نمونه شکست:

{ "result": 1, "text": "missing parameter 'ip-address' (<string>:3:19)" }

دستور lease6-bulk-apply برای رفع افت کارایی در حالت دسترس‌پذیری بالا (High-Availability) پیاده‌سازی شده است؛ در این حالت زمانی که چندین اجارهٔ آدرس و/یا پیشوند تخصیص داده می‌شود، یک تراکنش منفرد DHCPv6 منجر به ارسال چندین به‌روزرسانی اجاره به کارگزار همتا (partner) می‌گردد. حالتی را در نظر بگیرید که یک کلاینت DHCPv6 درخواست تخصیص دو آدرس IPv6 و دو پیشوند IPv6 را می‌دهد: این امر ممکن است منجر به تخصیص چهار اجاره شود. علاوه‌بر این، DHCPv6 ممکن است در مرحلهٔ تمدید (renew) یا اتصال مجدد (rebind)، آدرسی متفاوت از آدرس درخواستی کلاینت اختصاص دهد و اجاره‌هایی را که پیش‌تر توسط این کلاینت استفاده می‌شدند، حذف کند. در این حالت شش تغییر اجاره میان همتاهای HA ارسال می‌شود. ارسال این به‌روزرسانی‌ها در قالب دستورهای مجزا، مثلاً از طریق lease6-update، بسیار ناکارآمد است و تأخیرهای غیرضروری در ارتباطات، هم میان همتاهای HA و هم در ارسال پاسخ به کلاینت DHCPv6، ایجاد می‌کند.

دستور lease6-bulk-apply با تجمیع تمام تغییرات اجاره - چه اجاره‌های حذف‌شده و چه اجاره‌های جدید یا به‌روزرسانی‌شده - در قالب یک دستور واحد با این مشکل مقابله می‌کند. کارگزار دریافت‌کننده روی اجاره‌های حذف‌شده پیمایش کرده و آن‌ها را از پایگاه دادهٔ اجاره‌های خود حذف می‌کند. سپس، روی اجاره‌های جدید/به‌روزرسانی‌شده پیمایش کرده و آن‌ها را به پایگاه داده اضافه نموده یا در صورت وجود، به‌روزرسانی می‌کند.

اگرچه دسترس‌پذیری بالا (High Availability) کاربرد اصلی این دستور است، اما در تمامی مواردی که ارسال چندین تغییر اجاره در قالب یک دستور واحد مد نظر باشد، می‌توان آزادانه از آن استفاده کرد.

در مثال زیر، دو اجاره را حذف کرده و دو اجارهٔ دیگر را در پایگاه داده اضافه یا به‌روزرسانی می‌کنیم:

 {
   "command": "lease6-bulk-apply",
   "arguments": {
       "deleted-leases": [
           {
               "ip-address": "2001:db8:abcd::",
               "type": "IA_PD",
               ...
           },
           {
               "ip-address": "2001:db8:abcd::234",
               "type": "IA_NA",
               ...
           }
       ],
       "leases": [
           {
               "subnet-id": 66,
               "ip-address": "2001:db8:cafe::",
               "type": "IA_PD",
                ...
           },
           {
               "subnet-id": 66,
               "ip-address": "2001:db8:abcd::333",
               "type": "IA_NA",
               ...
           }
       ]
    }
}

اگر هر یک از اجاره‌ها ساختار ناصحیحی داشته باشند (malformed)، هیچ تغییری در پایگاه دادهٔ اجاره‌ها اعمال نمی‌شود. اگر اجاره‌ها ساختار معتبری داشته باشند اما در اعمال هر یک از تغییرات اجاره در پایگاه داده خطایی رخ دهد، پردازش دستور برای سایر اجاره‌ها ادامه می‌یابد. تمام اجاره‌هایی که دستور نتوانسته تغییرات آن‌ها را در پایگاه داده اعمال کند، در پاسخ فهرست می‌شوند. برای نمونه:

{
    "result": 0,
    "text": "Bulk apply of 2 IPv6 leases completed",
    "arguments": {
        "failed-deleted-leases": [
            {
                "ip-address": "2001:db8:abcd::",
                "type": "IA_PD",
                "result": 3,
                "error-message": "no lease found"
            }
        ],
        "failed-leases": [
            {
                "ip-address": "2001:db8:cafe::",
                "type": "IA_PD",
                "result": 1,
                "error-message": "unable to communicate with the lease database"
            }
        ]
    }
}

پاسخ بالا نشان می‌دهد که کتابخانهٔ قلاب (hook library) نتوانسته است اجارهٔ مربوط به پیشوند "2001:db8:abcd::" را حذف کرده و اجارهٔ مربوط به پیشوند "2001:db8:cafe::" را اضافه یا به‌روزرسانی کند. با این حال، همان‌طور که در پیام متنی مشخص است، دو تغییر اجارهٔ دیگر اعمال شده‌اند. مقدار result ثابتی از وضعیت است که نوع خطای رخ‌داده برای اجارهٔ مشخص را نشان می‌دهد. معانی کدهای بازگردانده‌شده همانند نتایج بازگردانده‌شده برای دستورها است. به‌ویژه، نتیجهٔ 1 نشان‌دهندهٔ خطا در حین پردازش اجاره است، مانند خطای ارتباط با پایگاه داده. نتیجهٔ 3 نشان می‌دهد که تلاش برای حذف اجاره ناموفق بوده است زیرا چنین اجاره‌ای وجود ندارد (یک نتیجهٔ خالی).

از دستورهای lease4-get و lease6-get می‌توان برای پرس‌وجوی پایگاه دادهٔ اجاره و بازیابی اجاره‌های موجود استفاده کرد. دستور lease4-get از دو نوع پارامتر پشتیبانی می‌کند: (address) یا (subnet-id، identifier-type، identifier). همچنین برای lease6-get دو نوع وجود دارد: (address، type) یا (subnet-id، identifier-type، identifier، IAID، type). نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (چه IPv4 و چه IPv6) مشخص است، اما جزئیات اجاره مشخص نیست؛ یکی از موارد کاربرد رایج این نوع پرس‌وجو پی بردن به این است که آیا آدرس مورد نظر در حال استفاده است یا خیر. پرس‌وجوی دوم از شناسه‌ها استفاده می‌کند؛ شناسه‌هایی که در حال حاضر برای اجاره‌ها پشتیبانی می‌شوند عبارتند از: "hw-address" (فقط IPv4)، "client-id" (فقط IPv4) و "duid" (فقط IPv6).

یک نمونه دستور lease4-get برای دریافت اجاره با استفاده از آدرس IPv4:

{
    "command": "lease4-get",
    "arguments": {
        "ip-address": "192.0.2.1"
    }
}

یک نمونه از پرس‌وجوی lease6-get:

{
  "command": "lease6-get",
  "arguments": {
    "ip-address": "2001:db8:1234:ab::",
    "type": "IA_PD"
  }
}

یک نمونه پرس‌وجو بر اساس "hw-address" برای یک اجارهٔ IPv4 به صورت زیر است:

{
    "command": "lease4-get",
    "arguments": {
        "identifier-type": "hw-address",
        "identifier": "08:08:08:08:08:08",
        "subnet-id": 44
    }
}

یک نمونه پرس‌وجو بر اساس "client-id" برای یک اجارهٔ IPv4 به صورت زیر است:

{
    "command": "lease4-get",
    "arguments": {
        "identifier-type": "client-id",
        "identifier": "01:01:02:03:04:05:06",
        "subnet-id": 44
    }
}

یک نمونه پرس‌وجو بر اساس (subnet-id، identifier-type، identifier، iaid، type) برای یک اجارهٔ IPv6:

{
    "command": "lease6-get",
    "arguments": {
        "identifier-type": "duid",
        "identifier": "08:08:08:08:08:08",
        "iaid": 1234567,
        "type": "IA_NA",
        "subnet-id": 44
    }
}

پارامتر type اختیاری است. مقادیر پشتیبانی‌شده عبارتند از: IA_NA (آدرس غیرموقت) و IA_PD (پیشوند IPv6). در صورت عدم تعیین، IA_NA در نظر گرفته می‌شود.

دستورهای lease4-get و lease6-get در صورت یافتن، نشانگری از نتیجهٔ عملیات و جزئیات اجاره را بازمی‌گردانند. نتیجه دارای یکی از مقادیر زیر است: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی). نتیجهٔ خالی بدین معناست که پرس‌وجو به‌درستی انجام شده، اما شیء مورد نظر (در اینجا یک اجاره) یافت نشده است. در صورت یافت شدن، پارامترهای اجاره در قالب آرگومان‌ها بازگردانده می‌شوند. مقدار client-id در صورت خالی بودن بازگردانده نمی‌شود.

یک نمونه نتیجهٔ بازگردانده‌شده در زمانی که میزبان پیدا شده است:

{
  "arguments": {
    "client-id": "42:42:42:42:42:42:42:42",
    "cltt": 12345678,
    "fqdn-fwd": false,
    "fqdn-rev": true,
    "hostname": "myhost.example.com.",
    "hw-address": "08:08:08:08:08:08",
    "ip-address": "192.0.2.1",
    "state": 0,
    "subnet-id": 44,
    "valid-lft": 3600
  },
  "result": 0,
  "text": "IPv4 lease found."
}

نکته:

زمان آخرین تراکنش کلاینت (فیلد cltt) با معادلهٔ زیر به مدت‌زمان اعتبار (valid-lft) و تاریخ انقضا (که در اینجا گزارش نمی‌شود اما در پایگاه‌های داده ذخیره می‌گردد) پیوند خورده است: cltt + valid\_lft = expire

به استثنای مدت‌زمان اعتبار نامحدود که با مقدار ویژهٔ 0xfffffff (4294967295) کدگذاری شده است و باعث سرریز (overflow) مقدار expire در backendهای MySQL و نگارش‌های قدیمی PostgreSQL می‌شود که در آن‌ها مهر زمانی ۳۲ بیتی است. بنابراین در این پایگاه‌های دادهٔ اجاره، تاریخ انقضا همان cltt است؛ یعنی: cltt = expire زمانی که valid\_lft = 4294967295 باشد و backend اجاره MySQL یا PostgreSQL باشد.

دستورهای lease4-get-all و lease6-get-all برای دریافت تمام اجاره‌های (leases) IPv4 یا IPv6، یا تمام اجاره‌های مربوط به مجموعه‌ای مشخص از زیرشبکه‌ها به کار می‌روند. اگر هیچ آرگومانی همراه با دستور مشخص نشده باشد، تمام اجاره‌ها بازگردانده می‌شوند، همان‌طور که در مثال زیر آمده است:

{
    "command": "lease4-get-all"
}

در صورت ارائه آرگومان‌ها، انتظار می‌رود که شامل پارامتر "subnets" باشند؛ این پارامتر فهرستی از شناسه‌های زیرشبکه‌ای است که اجاره‌های آن‌ها باید بازگردانده شوند. به عنوان مثال، برای دریافت تمام اجاره‌های IPv6 متعلق به زیرشبکه‌هایی با شناسه‌های 1، 2، 3 و 4:

{
    "command": "lease6-get-all",
    "arguments": {
        "subnets": [ 1, 2, 3, 4 ]
    }
}

پاسخ بازگردانده‌شده شامل فهرست دقیقی از اجاره‌ها با قالب زیر است:

{
    "arguments": {
        "leases": [
            {
                "cltt": 12345678,
                "duid": "42:42:42:42:42:42:42:42",
                "fqdn-fwd": false,
                "fqdn-rev": true,
                "hostname": "myhost.example.com.",
                "hw-address": "08:08:08:08:08:08",
                "iaid": 1,
                "ip-address": "2001:db8:2::1",
                "preferred-lft": 500,
                "state": 0,
                "subnet-id": 44,
                "type": "IA_NA",
                "valid-lft": 3600
            },
            {
                "cltt": 12345678,
                "duid": "21:21:21:21:21:21:21:21",
                "fqdn-fwd": false,
                "fqdn-rev": true,
                "hostname": "",
                "iaid": 1,
                "ip-address": "2001:db8:0:0:2::",
                "preferred-lft": 500,
                "prefix-len": 80,
                "state": 0,
                "subnet-id": 44,
                "type": "IA_PD",
                "valid-lft": 3600
            }
        ]
    },
    "result": 0,
    "text": "2 IPv6 lease(s) found."
}

هشدار:

دستورهای lease4-get-all و lease6-get-all ممکن است به پاسخ‌های بسیار بزرگی منجر شوند. از آنجا که کارگزار محدودیتی بر روی تعداد اجاره‌های بازگردانده‌شده در نتیجه این دستور اعمال نمی‌کند، این امر ممکن است در حین تولید پاسخ و ارسال آن از طریق کانال کنترل، بر پاسخ‌گویی کارگزار DHCP اثر منفی بگذارد.

دستورهای lease4-get-all و lease6-get-all ممکن است منجر به پاسخ‌های بسیار بزرگی شوند؛ تولید چنین پاسخی ممکن است توان پردازشی CPU و همچنین حافظه را مصرف کند. حتی ممکن است باعث عدم پاسخ‌گویی کارگزار شود. در پایگاه‌داده‌های بزرگ اجاره، معمولاً بهتر است اجاره‌ها به‌صورت تکه‌تکه و با استفاده از سازوکار صفحه‌بندی دریافت شوند. lease4-get-page و lease6-get-page به ترتیب یک سازوکار صفحه‌بندی برای کارگزارهای DHCPv4 و DHCPv6 پیاده‌سازی می‌کنند. دستور زیر 1024 اجاره اول IPv4 را دریافت می‌کند:

{
    "command": "lease4-get-page",
    "arguments": {
        "from": "start",
        "limit": 1024
    }
}

کلمه کلیدی start نشان می‌دهد که صفحه اول اجاره‌ها باید دریافت شود. به عنوان جایگزین، می‌توان یک آدرس صفر IPv4 را برای دریافت صفحه اول مشخص کرد:

{
    "command": "lease4-get-page",
    "arguments": {
        "from": "0.0.0.0",
        "limit": 1024
    }
}

به طور مشابه، می‌توان آدرس صفر IPv6 را در دستور lease6-get-page مشخص نمود:

{
    "command": "lease6-get-page",
    "arguments": {
        "from": "::",
        "limit": 6
    }
}

پاسخ دارای ساختار زیر است:

{
    "arguments": {
        "leases": [
            {
                "ip-address": "2001:db8:2::1",
                ...
            },
            {
                "ip-address": "2001:db8:2::9",
                ...
            },
            {
                "ip-address": "2001:db8:3::1",
                ...
            },
            {
                "ip-address": "2001:db8:5::3",
                ...
            },
            {
                "ip-address": "2001:db8:4::1",
                ...
            },
            {
                "ip-address": "2001:db8:2::7",
                ...
            },
            ...
        ],
        "count": 6
    },
    "result": 0,
    "text": "6 IPv6 lease(s) found."
}

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

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

پارامتر count حاوی تعداد اجاره‌های بازگردانده‌شده در این صفحه است.

برای واکشی صفحه بعدی، کلاینت باید آخرین آدرس صفحه فعلی را به عنوان ورودی برای فراخوانی دستور بعدی lease4-get-page یا lease6-get-page استفاده کند. در این مثال، این آدرس به صورت زیر است:

{
    "command": "lease6-get-page",
    "arguments": {
        "from": "2001:db8:2::7",
        "count": 6
    }
}

زیرا 2001:db8:2::7 آخرین آدرس در صفحه فعلی است.

کلاینت می‌تواند هنگامی که مقدار count کمتر از مقدار مشخص‌شده در دستور باشد، فرض کند که به آخرین صفحه رسیده است؛ این شامل حالتی نیز می‌شود که count برابر با 0 باشد، به این معنی که هیچ اجاره‌ای پیدا نشده است..SS دستورهای lease4-get-by-* و lease6-get-by-*

دستورهای lease4-get-by-* و lease6-get-by-* می‌توانند برای پرس‌وجو از پایگاه داده اجاره‌ها و دریافت تمام اجاره‌های موجودِ منطبق با یک ویژگی مشخص (که با * نشان داده شده است) استفاده شوند. این موارد می‌توانند شامل یک آدرس سخت‌افزاری مشخص (فقط IPv4)، شناسه‌های client-id (فقط IPv4)، duid (فقط IPv6)، یا hostname باشند.

یک مثال از دستور lease4-get-by-hw-address برای دریافت اجاره‌های IPv4 با یک آدرس سخت‌افزاری مشخص:

{
    "command": "lease4-get-by-hw-address",
    "arguments": {
        "hw-address": "08:08:08:08:08:08"
    }
}

یک مثال از lease6-get-by-hostname:

{
    "command": "lease6-get-by-hostname",
    "arguments": {
        "hostname": "myhost.example.org"
    }
}

کلید by تنها پارامتر است. پاسخ بازگردانده شده شامل فهرستی با جزئیات از اجاره‌ها با همان قالب lease4-get-all یا lease6-get-all است. این فهرست می‌تواند خالی باشد و معمولاً بزرگ نیست.

از نسخه 3.1.5 Kea، دستورهای by-state اضافه شده‌اند به طوری که:

  • پارامتر state همچنین یک رشته (در مقابل یک عدد) را برای نام‌های معمول وضعیت می‌پذیرد (default (یا assigned) (0)، declined (1)، expired-reclaimed (2)، released (3)، و registered (4)).
  • یک پارامتر اختیاری subnet-id که اجاره‌ها را به زیرشبکه مشخص‌شده محدود می‌کند. هنگامی که حذف شود یا روی 0 تنظیم گردد، تمام اجاره‌ها با وضعیت داده‌شده بازگردانده می‌شوند.

lease4-del و lease6-del می‌توانند برای حذف یک اجاره از پایگاه داده اجاره‌ها استفاده شوند. این دستورها مانند دستورهای lease4-get و lease6-get از دو نوع پارامتر پشتیبانی می‌کنند: (address) برای هر دو نسخه v4 و v6، همچنین (subnet-id، identifier-type، identifier) برای v4، و (subnet-id، identifier-type، identifier، type، IAID) برای v6. نوع اول پرس‌وجو زمانی استفاده می‌شود که آدرس (چه IPv4 یا IPv6) مشخص است، اما جزئیات اجاره مشخص نیست. یک مورد استفاده معمول زمانی است که مدیر سیستم می‌خواهد یک آدرس مشخص دیگر استفاده نشود. شکل دوم دستور از شناسه‌ها استفاده می‌کند. برای حداکثر انعطاف‌پذیری، این رابط کاربری از شناسه‌ها به صورت یک جفت مقدار استفاده می‌کند: نوع و شناسه واقعی. شناسه‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از "hw-address" (فقط IPv4)، "client-id" (فقط IPv4)، و "duid" (فقط IPv6).

یک مثال از دستور برای حذف یک اجاره IPv4 بر اساس آدرس:

{
    "command": "lease4-del",
    "arguments": {
        "ip-address": "192.0.2.202"
    }
}

یک مثال از حذف اجاره IPv4 بر اساس "hw-address":

{
  "command": "lease4-del",
  "arguments": {
    "identifier": "08:08:08:08:08:08",
    "identifier-type": "hw-address",
    "subnet-id": 44
  }
}

اجاره‌های آدرس IPv6 نیز به همین روش حذف می‌شوند، اما با استفاده از lease6-del. اجاره‌های پیشوند IPv6 نیز با استفاده از lease6-del حذف می‌شوند، اما با چند مرحله اضافی. به پیشوند باید از طریق آدرس آن ارجاع داده شود و از طول پیشوند صرف‌نظر شود. برای مثال، جهت حذف 2001:db8:1::/48 می‌توان از دستور زیر استفاده کرد. پارامتر subnet-id اختیاری است.

{
    "command": "lease6-del",
    "arguments": {
        "ip-address": "2001:db8:1::",
        "type": "IA_PD",
        "subnet-id": 1
    }
}

پارامتر دیگری با نام update-ddns، در صورت true بودن، به سرور دستور می‌دهد که در صورت برقراری شرایط زیر، پس از حذف موفقیت‌آمیز اجاره، درخواستی را به kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> جهت حذف مدخل‌های DNS در صف قرار دهد:

  • به‌روزرسانی DDNS فعال باشد (یعنی "dhcp-ddns":{ "enable-updates": true }).
  • نام میزبان (hostname) اجاره خالی نباشد.
  • حداقل یکی از پرچم‌های جهت DNS اجاره (fqdn_fwd یا fqdn_rev) برابر با true باشد.

مقدار پیش‌فرض این پارامتر false است. مثالی از کاربرد آن در زیر نشان داده شده است:

{
    "command": "lease4-del",
    "arguments": {
        "ip-address": "192.0.2.202",
        "update-ddns": true
    }
}

دستورهای lease4-del و lease6-del نتیجه‌ای را برمی‌گردانند که بیانگر پیامد عملیات است. این نتیجه یکی از مقادیر زیر را دارد: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی). نتیجه خالی به این معنی است که پرس‌وجو به درستی انجام شده، اما شیء مورد نظر (در اینجا، یک اجاره) یافت نشده است..SS دستورهای lease4-update و lease6-update

دستورهای lease4-update و lease6-update می‌توانند برای به‌روزرسانی اجاره‌های موجود به کار روند. از آنجا که تمام پایگاه‌های داده پس‌زمینه اجاره‌ها بر اساس نشانی‌های IP نمایه شده‌اند، امکان به‌روزرسانی خود نشانی وجود ندارد، اما تمام فیلدهای دیگر قابل تغییر هستند. اگر نیاز به تغییر نشانی باشد، لطفاً از lease4-del / lease6-del و به دنبال آن از lease4-add / lease6-add استفاده کنید.

پارامتر subnet-id اختیاری است. اگر مشخص نشود، یا مقدار تعیین‌شده 0 باشد، Kea تلاش می‌کند مقدار آن را با اجرای یک رویه انتخاب زیرشبکه تعیین کند. با این حال اگر مشخص شده باشد، مقدار آن باید با زیرشبکه موجود مطابقت داشته باشد.

پارامتر بولی اختیاری "force-create" مشخص می‌کند که آیا در صورت عدم وجود اجاره در پایگاه داده، باید ایجاد شود یا خیر. مقدار پیش‌فرض آن false است که نشان می‌دهد در صورت عدم وجود اجاره، ایجاد نخواهد شد. در چنین حالتی، هنگام تلاش برای به‌روزرسانی یک اجاره ناموجود، خطا بازگردانده می‌شود. اگر پارامتر "force-create" روی true تنظیم شده باشد و اجاره مورد نظر وجود نداشته باشد، با دریافت دستور lease4-update / lease6-update، اجاره جدید ایجاد می‌شود.

نمونه‌ای از دستور برای به‌روزرسانی یک اجاره IPv4:

{
  "command": "lease4-update",
  "arguments": {
    "ip-address": "192.0.2.1",
    "hostname": "newhostname.example.org",
    "hw-address": "1a:1b:1c:1d:1e:1f",
    "subnet-id": 44,
    "force-create": true
  }
}

نمونه‌ای از دستور برای به‌روزرسانی یک اجاره IPv6:

{
  "command": "lease6-update",
  "arguments": {
    "ip-address": "2001:db8::1",
    "duid": "88:88:88:88:88:88:88:88",
    "iaid": 7654321,
    "hostname": "newhostname.example.org",
    "subnet-id": 66,
    "force-create": false
  }
}

همانند سایر دستورهای به‌روزرسانی، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر اجاره قبلاً منبعی تخصیص داده شده داشت، و در دستور lease4-update / lease6-update آن منبع وجود نداشته باشد، از پایگاه داده اجاره‌ها حذف خواهد شد. اگر به‌روزرسانی تدریجی اجاره مد نظر باشد، این کار با ارسال دستور lease4-get / lease6-get برای دریافت وضعیت فعلی اجاره، انتخاب اجاره از پاسخ، تغییر آن به وضعیت مطلوب، و سپس ارسال دستور lease4-update / lease6-update همراه با اجاره حاصل، قابل انجام است.

دستورهای lease4-wipe و lease6-wipe برای حذف تمام اجاره‌های مرتبط با یک زیرشبکه مشخص طراحی شده‌اند. انتظار می‌رود این وظیفه مدیریتی زمانی استفاده شود که یک زیرشبکه موجود در حال بازنشستگی و خروج از سرویس است. این اجاره‌ها به درستی منقضی نمی‌شوند؛ هیچ به‌روزرسانی DNS انجام نمی‌گیرد، هیچ پیام لاگی ایجاد نمی‌شود، و برای اجاره‌های در حال حذف هیچ قلابی (hook) فراخوانی نمی‌گردد.

نمونه‌ای از lease4-wipe:

{
  "command": "lease4-wipe",
  "arguments": {
    "subnet-id": 44
  }
}

نمونه‌ای از lease6-wipe:

{
  "command": "lease6-wipe",
  "arguments": {
    "subnet-id": 66
  }
}

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

شناسه subnet-id 0 دارای معنای خاصی است؛ این مقدار به Kea اعلام می‌کند که اجاره‌ها را از تمام زیرشبکه‌های پیکربندی‌شده حذف کند. همچنین، پارامتر subnet-id می‌تواند حذف شود. اگر مشخص نشود، اجاره‌های تمام زیرشبکه‌ها پاک‌سازی خواهند شد.

نکته: در حال حاضر تنها فضای ذخیره‌سازی اجاره memfile از این دستور پشتیبانی می‌کند.

دستورهای lease4-resend-ddns و lease6-resend-ddns می‌توانند برای ایجاد یک درخواست به kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> جهت به‌روزرسانی مدخل‌های DNS برای یک اجاره موجود استفاده شوند. اجاره مورد نظر با یک پارامتر واحد به نام "ip-address" انتخاب می‌شود. برای ایجاد درخواست به‌روزرسانی، باید به‌روزرسانی DDNS فعال باشد و پیش‌تر مدخل‌های DNS برای این اجاره ثبت شده (یا اقدام به ثبت شده) باشند. به عبارت دیگر، تمام موارد زیر باید برقرار باشند:

  • به‌روزرسانی DDNS باید فعال باشد (یعنی "dhcp-ddns":{ "enable-updates": true"}).
  • نام میزبان (hostname) اجاره نباید خالی باشد.
  • حداقل یکی از پرچم‌های جهت DNS اجاره (fqdn_fwd یا fqdn_rev) باید true باشد.

نمونه‌ای از دستور lease4-resend-ddns برای دریافت اجاره با استفاده از نشانی IPv4:

{
    "command": "lease4-resend-ddns",
    "arguments": {
        "ip-address": "192.0.2.1"
    }
}

نمونه‌ای از پرس‌وجوی lease6-resend-ddns:

{
  "command": "lease6-resend-ddns",
  "arguments": {
    "ip-address": "2001:db8:1::1"
  }
}

دستورهای lease4-resend-ddns و lease6-resend-ddns وضعیت نتیجه عملیات را بازمی‌گردانند. این وضعیت یکی از مقادیر زیر است: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی). نتیجه خالی بدین معناست که پرس‌وجو به درستی تکمیل شده، اما شیء (در این مورد یک اجاره) پیدا نشده است.

نتیجه موفقیت‌آمیز به این معنا نیست که DNS با موفقیت به‌روزرسانی شده است؛ بلکه نشان می‌دهد درخواستی برای به‌روزرسانی DNS با موفقیت ایجاد شده و برای ارسال به kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> در صف قرار گرفته است.

در اینجا نمونه‌ای از نتیجه بازگردانده‌شده در صورت یافتن اجاره آمده است:

{
  "result": 0,
  "text": "NCR generated for: 2001:db8:1::1, hostname: example.com."
}

دستورهای lease4-write و lease6-write می‌توانند برای بازیابی در شرایط اضطراری که فایل اجاره memfile آسیب دیده است (برای نمونه به اشتباه حذف شده یا به دلیل پر شدن سیستم‌فایل ناقص شده است)، اما پایگاه‌داده درون‌حافظه‌ای (in-memory) همچنان معتبر است، استفاده شوند. این دستورها تنها توسط بک‌اند پایگاه‌داده memfile پشتیبانی می‌شوند و پایگاه‌داده اجاره را در یک فایل CSV می‌نویسند. آن‌ها مسیر فایل را به عنوان آرگومان filename دریافت می‌کنند. اگر فایل خروجی مشخص‌شده با فایل پیکربندی‌شده memfile یکسان باشد، بک‌اند در تلاشی برای همگام‌سازی هر دو فایل و تصویرهای درون‌حافظه‌ای پایگاه‌داده اجاره، فایل را بسته و دوباره باز می‌کند. پسوند .bak و شماره PID سرور به نام فایل قبلی افزوده می‌شوند؛ برای نمونه: .bak14326.

نکته:

از Kea 2.7.9 به این سو، فایل اجاره تنها ممکن است در دایرکتوری داده تعیین‌شده هنگام کامپایل نوشته شود: "[kea-install-dir]/var/lib/kea". این مسیر ممکن است در زمان راه‌اندازی با تنظیم متغیر محیطی KEA_DHCP_DATA_DIR به مسیر دلخواه بازنویسی شود. اگر مسیری به غیر از این مقدار در filename استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی امتناع می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌بازیابی را ثبت می‌کند. برای سهولت در مشخص کردن نام فایل سفارشی، کافی است بخش مسیر را از filename حذف کنید.

نکته:

این دستورها جایگزین سازوکار LFC نمی‌شوند؛ آن‌ها باید تنها در شرایط استثنایی استفاده شوند، مانند بازیابی پس از اتمام فضای دیسک.

دستورهای زیر می‌توانند برای مدیریت داده‌های SFLQ (مانند استخرها و اجاره‌های آزاد) موجود در بک‌اند اجاره برای زیرشبکه‌هایی که از Shared FLQ Allocator استفاده می‌کنند، به کار روند. در شرایط عادی، این اطلاعات به طور خودکار توسط سازوکارهای SFLQ Allocator ایجاد و نگهداری می‌شوند. با این دستورهای API، امکان مشاهده، ساخت (مجدد) و حذف استخرهای SFLQ فراهم می‌شود.

نخست، درک این نکته مهم است که استخرهای SFLQ به طور یکتا بر اساس آدرس‌های آغازین و پایانی خود شناسایی می‌شوند. برای هر محدوده معتبر IPv4 یا IPv6، تنها می‌تواند یک استخر وجود داشته باشد. با این حال، استخرها می‌توانند محدوده‌های همپوشان داشته باشند.

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

  • start-address - آدرس آغازین استخر
  • end-address - آدرس پایانی استخر
  • subnet-id - شناسه زیرشبکه‌ای که استخر برای آن ایجاد شده است
  • lease-type - برای IPv4 همیشه "V4" است، برای IPv6 یا "IA_NA" است یا "IA_PD"
  • delegated-len - برای استخرهای "V4" و "IA_NA" همیشه ۱۲۸ است. برای استخرهای "IA_PD" طول پیشوند واگذارشده است.
  • created-ts - زمان ایجاد استخر.
  • modified-ts - زمان آخرین به‌روزرسانی استخر. این مقدار در ابتدا پس از تکمیل ایجاد استخر تنظیم می‌شود. پس از آن، هر بار که تخصیص SFLQ یک اجاره آزاد را از استخر برمی‌دارد، به‌روزرسانی می‌شود.
  • free-leases تعداد آدرس‌های در حال حاضر آزاد در استخر.

حداقل سه حالت وجود دارد که این دستورها در آن‌ها به احتمال زیاد بیشترین کاربرد را خواهند داشت. نخست، به عنوان راهکاری برای جست‌وجو و حذف استخرهای منسوخ‌شده. از آنجا که استخرها می‌توانند بین تعداد دلخواهی از سرورها به اشتراک گذاشته شوند، و هیچ‌یک از آن‌ها نمی‌توانند با قطعیت بدانند چه زمانی یک استخر دیگر مورد نیاز نیست، داده‌های SFLQ یک استخر را نمی‌توان هنگامی که طرح تخصیص آن به چیزی غیر از SFLQ Allocator تغییر می‌کند، به طور خودکار حذف کرد. اگرچه استخرهای غیرفعال نباید باعث اختلال در عملکرد سرورها شوند، اما فضا و نمایه‌ها را در بک‌اند اجاره مصرف می‌کنند.

حالت دوم، طرح‌های تخصیص ترکیبی است. برای اینکه تخصیص SFLQ به درستی کار کند، همه سرورهایی که از یک استخر معین (یعنی محدوده آدرس یا پیشوند) تخصیص می‌دهند، باید از SFLQ استفاده کنند. اگر برخی از سرورها استفاده کنند در حالی که برخی دیگر استفاده نکنند، داده‌های SFLQ می‌توانند به سرعت نادرست شوند. این مشکل را می‌توان با متوقف کردن سرورهایی که از SFLQ برای استخر(های) مربوطه استفاده نمی‌کنند، بازسازی استخر(ها) با استفاده از دستورهای sflq-pool*-rebuild، تغییر آن سرورها برای استفاده از SFLQ برای استخر(ها) و سپس راه‌اندازی مجدد آن‌ها رفع کرد.

حالت سوم، استخرهای همپوشان است (یعنی استخرهایی که محدوده‌های آدرس/پیشوند آن‌ها با یکدیگر تداخل دارند). Kea این موضوع را به عنوان یک پیکربندی عامدانه پشتیبانی می‌کند، اما همچنین ممکن است به صورت ناخواسته در صورتی رخ دهد که تغییرات پیکربندی به صورت یکپارچه در چندین سرور اعمال نشوند. واکشی استخرهای SFLQ بر اساس محدوده آدرس، تمام استخرهای SFLQ که با محدوده ورودی همپوشانی دارند را برمی‌گرداند.

نکته:

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

دستورهای sflq-pool4-rebuild و sflq-pool6-rebuild می‌توانند برای بازسازی داده‌های اجاره آزاد برای استخرهای SFLQ موجود استفاده شوند. این امر در مواردی مفید است که یک یا چند سرور از سایر طرح‌های تخصیص برای محدوده‌های آدرسی که شامل استخرهای SFLQ هستند استفاده کرده باشند. اجرای این دستور باعث می‌شود که بک‌اند اجاره، داده‌های اجاره آزاد برای استخر مشخص‌شده را دور ریخته و سپس مجدداً بازسازی کند. تنها استخری بازسازی خواهد شد که دقیقاً با آدرس آغازین و پایانی ارائه‌شده مطابقت داشته باشد.

یک نمونه از دستور sflq-pool4-rebuild برای بازسازی استخر SFLQ مربوط به IPv4 در زیر نشان داده شده است:

{
    "command": "sflq-pool4-rebuild",
    "arguments": {
        "start-address": "192.0.2.0",
        "end-address": "192.0.2.255"
    }
}

یک نمونه از دستور sflq-pool6-rebuild برای بازسازی استخر SFLQ مربوط به IPv6 برای یک استخر آدرس در زیر نشان داده شده است:

{
    "command": "sflq-pool6-rebuild",
    "arguments": {
        "start-address": "2001:db8:1::",
        "end-address": "2001:db8:1::FFFF"
    }
}

نکته:

برای استخرهای بزرگ (برای مثال >= ۱ میلیون آدرس/پیشوند)، این دستور می‌تواند بیست ثانیه یا بیشتر زمان ببرد. در طول این مدت سرور درخواست‌های کلاینت‌ها را پردازش نخواهد کرد. اطمینان حاصل کنید ابزاری که با آن دستورها را ارسال می‌کنید برای مهلت‌های زمانی (time outs) طولانی پیکربندی شده باشد. هنگامی که درخواست به بک‌اند اجاره ارسال شود، پرس‌وجو به اجرای خود ادامه خواهد داد، حتی اگر اتصال کلاینت API قطع شود.

این دستور وضعیتی را بازمی‌گرداند که نشان‌دهنده موفقیت (result 0) یا شکست (result 1) است. دستور شکست‌خورده همواره حاوی پارامتر متنی است که علت شکست را شرح می‌دهد. برای نمونه:

{ "result": 0, "text": "SFLQ pool rebuilt." }

از sflq-pool4-get-all و sflq-pool6-get-all می‌توان برای واکشی فهرستی از تمامی استخرهای IPv4 یا IPv6 در SFLQ استفاده کرد. آن‌ها هیچ آرگومانی نمی‌پذیرند.

یک نمونه دستور sflq-pool4-get-all برای واکشی استخرهای IPv4 در SFLQ:

{
    "command": "sflq-pool4-get-all"
}

پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از تمام استخرهای IPv4 در SLFQ به قالب زیر است:

{
    "arguments": {
        "pools": [
            {
                "created-ts": "2026-05-05 11:16:36.000000",
                "delegated-len": 128,
                "end-address": "178.0.255.255",
                "free-leases": 65535,
                "lease-type": "V4",
                "modified-ts": "2026-05-05 11:16:36.000000",
                "start-address": "178.0.0.1",
                "subnet-id": 1
            },
        {
            "created-ts": "2026-05-05 11:18:02.000000",
            "delegated-len": 128,
            "end-address": "192.0.2.255",
            "free-leases": 256,
            "lease-type": "V4",
            "modified-ts": "2026-05-05 11:18:02.000000",
            "start-address": "192.0.2.0",
            "subnet-id": 2
        }
        ]
    },
    "result": 0,
    "text": "1 pool(s) found."
}

یک نمونه دستور sflq-pool6-get-all برای واکشی استخرهای IPv6 در SFLQ:

{
    "command": "sflq-pool6-get-all"
}

پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از تمام استخرهای IPv6 در SLFQ به قالب زیر است:

{
    "arguments": {
        "pools": [
            {
                "created-ts": "2026-05-05 13:21:10.000000",
                "delegated-len": 120,
                "end-address": "2001:db8:1::ffff",
                "free-leases": 256,
                "lease-type": "IA_PD",
                "modified-ts": "2026-05-05 13:21:10.000000",
                "start-address": "2001:db8:1::",
                "subnet-id": 1
            },
            {
                "created-ts": "2026-05-05 08:40:40.000000",
                "delegated-len": 128,
                "end-address": "3001::ffff",
                "free-leases": 65520,
                "lease-type": "IA_NA",
                "modified-ts": "2026-05-05 08:40:41.000000",
                "start-address": "3001::10",
                "subnet-id": 2
            }
        ]
    },
    "result": 0,
    "text": "2 pool(s) found."
}

از sflq-pool4-get-by-subnet و sflq-pool6-get-by-subnet می‌توان برای واکشی فهرستی از تمامی استخرهای IPv4 یا IPv6 در SFLQ که برای یک زیرشبکه ایجاد شده‌اند، استفاده کرد.

یک نمونه دستور sflq-pool4-get-by-subnet برای واکشی استخرهای IPv4 در SFLQ در زیر نشان داده شده است:

{
    "command": "sflq-pool4-get-by-subnet",
    "arguments": {
        "subnet-id" : 1
    }
}

پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از استخرهای IPv4 در SLFQ به قالب زیر است:

{
    "arguments": {
        "pools": [
            {
                "created-ts": "2026-05-05 11:18:02.000000",
                "delegated-len": 128,
                "end-address": "192.0.2.255",
                "free-leases": 256,
                "lease-type": "V4",
                "modified-ts": "2026-05-05 11:18:02.000000",
                "start-address": "192.0.2.0",
                "subnet-id": 1
            }
        ]
    },
    "result": 0,
    "text": "1 pool(s) found."
}

یک نمونه دستور sflq-pool6-get-by-subnet برای واکشی استخرهای IPv6 در SFLQ در زیر نشان داده شده است:

{
    "command": "sflq-pool6-get-by-subnet",
    "arguments": {
        "subnet-id" : 100
    }
}

پاسخ بازگردانده‌شده شامل یک فهرست تفصیلی از استخرهای IPv6 در SLFQ به قالب زیر است:

{
    "arguments": {
        "pools": [
            {
                "created-ts": "2026-05-05 13:21:10.000000",
                "delegated-len": 120,
                "end-address": "2001:db8:1::ffff",
                "free-leases": 256,
                "lease-type": "IA_PD",
                "modified-ts": "2026-05-05 13:21:10.000000",
                "start-address": "2001:db8:1::",
                "subnet-id": 100
            }
        ]
    },
    "result": 0,
    "text": "1 pool(s) found."
}

sflq-pool4-get-by-range و sflq-pool6-get-by-range می‌توانند برای دریافت فهرستی از تمام استخرهای SFLQ مربوط به IPv4 یا IPv6 که برای یک زیرشبکه ساخته شده‌اند، استفاده شوند.

یک نمونه دستور sflq-pool4-get-by-range برای دریافت استخرهای SFLQ مربوط به IPv4 در زیر نشان داده شده است:

{
    "command": "sflq-pool4-get-by-range",
    "arguments": {
        "start-address": "178.0.0.0",
        "end-address": "178.255.255.255"
    }
}

پاسخ بازگردانده‌شده شامل یک فهرست دقیق از استخرهای SFLQ مربوط به IPv4 به قالب زیر است:

{
    "arguments": {
        "pools": [
            {
                "created-ts": "2026-05-05 11:16:36.000000",
                "delegated-len": 128,
                "end-address": "178.0.255.255",
                "free-leases": 65535,
                "lease-type": "V4",
                "modified-ts": "2026-05-05 11:16:36.000000",
                "start-address": "178.0.0.1",
                "subnet-id": 1
            }
        ]
    },
    "result": 0,
    "text": "1 pool(s) found."
}

یک نمونه دستور sflq-pool6-get-by-range برای دریافت استخرهای SFLQ مربوط به IPv6 در زیر نشان داده شده است:

{
    "command": "sflq-pool6-get-by-range",
    "arguments": {
        "start-address": "3001::",
        "end-address": "3002::"
    }
}

پاسخ بازگردانده‌شده شامل یک فهرست دقیق از استخرهای SFLQ مربوط به IPv6 به قالب زیر است:

{
    "arguments": {
        "pools": [
            {
                "created-ts": "2026-05-05 08:40:40.000000",
                "delegated-len": 128,
                "end-address": "3001::ffff",
                "free-leases": 65520,
                "lease-type": "IA_NA",
                "modified-ts": "2026-05-05 08:40:41.000000",
                "start-address": "3001::10",
                "subnet-id": 3001
            },
            {
                "created-ts": "2026-05-05 08:40:41.000000",
                "delegated-len": 64,
                "end-address": "3001:20:0:ff:ffff:ffff:ffff:ffff",
                "free-leases": 256,
                "lease-type": "IA_PD",
                "modified-ts": "2026-05-05 08:40:41.000000",
                "start-address": "3001:20::",
                "subnet-id": 3001
            }
        ]
    },
    "result": 0,
    "text": "2 pool(s) found."
}

از sflq-pool4-del و sflq-pool6-del می‌توان برای حذف یک استخر SFLQ مربوط به IPv4 یا IPv6 استفاده کرد. آن‌ها به دو آرگومان start-address و end-address نیاز دارند. تنها استخری حذف خواهد شد که بازه آن با این مقادیر مطابقت داشته باشد و آن هم تنها در صورتی که هیچ استخر SFLQ دیگری با بازه توصیف‌شده توسط این مقادیر هم‌پوشانی نداشته باشد. اگر هرگونه استخر هم‌پوشانی شناسایی شود، عملیات حذف با پیام خطایی مبنی بر این وضعیت شکست خواهد خورد. یک پارامتر اختیاری force وجود دارد که می‌تواند برای نادیده گرفتن این محافظت استفاده شود. هنگامی که روی true تنظیم شود، استخر منطبق بدون بررسی استخرهای هم‌پوشان حذف خواهد شد.

حذف یک استخر در زمانی که استخرهای هم‌پوشان وجود دارند، می‌تواند باعث ایجاد حفره‌هایی در داده‌های اجاره‌های آزاد (free lease) در محل‌های هم‌پوشانی شود. اگر قرار است استخرهای هم‌پوشان همچنان مورد استفاده قرار گیرند، باید از دستورات sflq-poolX-rebuild برای بازسازی داده‌های اجاره‌های آزاد برای استخرهای باقی‌مانده استفاده شود.

به عنوان راهکار دیگر، می‌توان تمام استخرهای هم‌پوشان را حذف کرد و راه‌اندازی (مجدد) یا پیکربندی (مجدد) بعدی کارساز Kea، تمام استخرهای مورد نیاز را به صورت خودکار بازآفرینی خواهد کرد.

یک نمونه دستور sflq-pool4-del برای حذف یک استخر SFLQ مربوط به IPv4 در زیر نشان داده شده است:

{
    "command": "sflq-pool4-del",
    "arguments": {
        "start-address": "192.0.2.10",
        "end-address": "192.0.2.20",
        "force": false
    }
}

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

{
    "result": 1,
    "text": "Delete would affect 2 overlapping pools"
}

و اگر هیچ استخر هم‌پوشانی وجود نداشته باشد یا force روی true تنظیم شده باشد و استخر منطبق موجود باشد، نتیجه مشابه مورد نشان‌داده‌شده در زیر خواهد بود:

{
    "result": 0,
    "text": "SFLQ pool deleted"
}

یک نمونه دستور sflq-pool6-del برای حذف یک استخر SFLQ مربوط به IPv6 در زیر نشان داده شده است:

{
    "command": "sflq-pool6-del",
    "arguments": {
        "start-address": "3001::",
        "end-address": "3001::10:FFFF",
        "force": false
    }
}

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

{
    "result": 1,
    "text": "Delete would affect 3 overlapping pools"
}

و اگر هیچ استخر هم‌پوشانی وجود نداشته باشد یا force روی true تنظیم شده باشد و استخر منطبق موجود باشد، نتیجه مشابه مورد نشان‌داده‌شده در زیر خواهد بود:

{
    "result": 0,
    "text": "SFLQ pool deleted"
}

متغیرهای انتساب به کاربران اجازه می‌دهند مقادیر سفارشی را همراه با هر اجاره (lease) ذخیره کنند. این مقادیر با استفاده از عبارت‌ها محاسبه شده و در user-context مربوط به اجاره ذخیره می‌شوند. این قابلیت شبیه به دستور set در ISC DHCP است.

آن‌ها به عنوان پارامترهایی برای کتابخانه قلاب lease-cmds پیکربندی می‌شوند. هر متغیر دارای پارامترهای زیر است:

•
نام متغیری که در user-context نمایش داده خواهد شد. این نام باید در فهرست متغیرهای انتساب یکتا باشد.
•
عبارتی که برای محاسبه مقدار متغیر استفاده می‌شود (نگاه کنید به: :ref: classification-using-expressions).
•
بسته‌ای که به عنوان ورودی عبارت استفاده می‌شود. این مقدار می‌تواند query (بسته ارسال‌شده توسط کلاینت) یا response (بسته‌ای که سرور در پاسخ ارسال می‌کند) باشد.

مثال زیر یک گزینه تعریف‌شده توسط کاربر ارسال‌شده از طرف کلاینت را به همراه domain-name ارسال‌شده توسط سرور برای هر اجاره DHCPv4 ذخیره می‌کند:

{
    "hooks-libraries": [{
        "library": "libdhcp_lease_cmds.so",
        "parameters": {
            "binding-variables": [{
                "name": "opt-222",
                "expression": "hexstring(option[222].hex, ':')",
                "source": "query"
            },{
                "name": "domain-name",
                "expression": "option[15].text",
                "source": "response"
            }]
        }
    }]
}

مقادیر به صورت جفت‌های نام-مقدار در نگاشت ISC در user-context اجاره ذخیره می‌شوند و محتویات آن شبیه به موارد زیر خواهد بود:

{
    "ISC": {
        "binding-variables": [{
            "domain-name": "example.org",
            "opt-222": "01:02:03:04"
        }
    ]}
}

هنگام ذخیره‌سازی در بک‌اندهای پایگاه‌داده، user-context فاقد شکست‌های خط نشان داده شده در بالا خواهد بود و به صورت زیر نمایش می‌یابد:

{ "ISC": { "binding-variables": { "domain-name": "example.org", "opt-222": "01:02:03:04" } } }

هنگام استفاده از فضای ذخیره‌سازی اجاره memfile، مقدار user-context با جایگزینی کاماها با توالی گریز "&#x2c" در خروجی قرار می‌گیرد. این امر برای جلوگیری از تداخل در تجزیه فایل اجاره ضروری است. خروجی مثال بالا در یک فایل اجاره memfile به صورت زیر خواهد بود:

{ "ISC": { "binding-variables": { "domain-name": "example.org"&#x2c "opt-222": "01:02:03:04" } } }

مقادیر متغیر انتساب هر زمان که اجاره‌ای تخصیص داده شده یا تمدید گردد ارزیابی می‌شوند. برای kea-dhcp4 <#std-iscman-kea-dhcp4>، در صورتی که offer-lifetime بزرگتر از صفر باشد نیز اضافه می‌شوند. اجاره در بک‌اند تنها زمانی به‌روزرسانی می‌شود که مقادیر تغییر کرده باشند.

نکته:

هنگام استفاده هم‌زمان با کتابخانه قلاب Ping Check، کتابخانه قلاب lease-cmds باید پس از Ping Check در بخش hooks-libraries در پیکربندی سرور فهرست شود.

هنگام استفاده هم‌زمان با کتابخانه قلاب HA، کتابخانه قلاب lease-cmds باید قبل از HA در بخش hooks-libraries در پیکربندی سرور فهرست شود. این امر تضمین می‌کند که متغیرهای انتساب پیش از ارسال به‌روزرسانی‌های اجاره توسط HA به همتایانش (peer(s)) ارزیابی شوند.

این کتابخانه پشتیبانی از DHCPv4 Leasequery مطابق با RFC 4388 https://datatracker.ietf.org/doc/html/rfc4388؛ و برای DHCPv6 Leasequery مطابق با (RFC 5007 https://datatracker.ietf.org/doc/html/rfc5007) را فراهم می‌کند.

نکته:

libdhcp_lease_query.so بخشی از کد متن‌باز بوده و در دسترس تمام کاربران Kea است. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود.

نکته:

این کتابخانه تنها می‌تواند توسط فرایندهای kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

نسخه 2.3.4 از Kea پشتیبانی از DHCPv6 Bulk Leasequery (RFC 5460 https://datatracker.ietf.org/doc/html/rfc5460) را اضافه کرد؛ نسخه 2.3.5 از Kea پشتیبانی از DHCPv4 Bulk Leasequery (RFC 6926 https://datatracker.ietf.org/doc/html/rfc6926) را با استفاده از بک‌اند اجاره memfile اضافه نمود..SS پرسمان اجاره DHCPv4 (DHCPv4 Leasequery)

قابلیت پرسمان اجاره ساده DHCPv4 (DHCPv4 simple Leasequery) به درخواست‌کننده امکان استعلام اطلاعات اجاره‌های فعال را برای یک آدرس IP مشخص یا یک کلاینت مشخص فراهم می‌کند. استاندارد RFC 4388 سه نوع از این پرسمان‌ها را معین کرده است:

•
پرسمان بر اساس آدرس IP
آدرس IP مورد نظر در فیلد ciaddr پرسمان قرار می‌گیرد.
•
پرسمان بر اساس آدرس سخت‌افزاری
آدرس سخت‌افزاری مورد نظر در فیلد chaddr پرسمان قرار می‌گیرد.
•
پرسمان بر اساس شناسه کلاینت
شناسه کلاینت مورد نظر در گزینه dhcp-client-identifier (کد 61) پرسمان ارسال می‌شود.

بسته ورودی DHCPLEASEQUERY باید تنها یکی از سه مقدار بالا را ارائه دهد. پرسمان‌هایی که بیش از یکی از این مقادیر را ارائه دهند دور ریخته می‌شوند.

علاوه بر این، پرسمان باید حاوی آدرس IP درخواست‌کننده در فیلد giaddr باشد. این مقدار نه تنها به عنوان مقصد پاسخ پرسمان استفاده می‌شود، بلکه برای اعتبارسنجی درخواست‌کننده در برابر فهرستی شناخته‌شده از آدرس‌های IP مجاز به پرسمان نیز به کار می‌رود. این فهرست از آدرس‌های درخواست‌کننده معتبر به عنوان بخشی از پیکربندی کتابخانه قلاب (hook library) مربوط به Leasequery مشخص می‌شود (بخش پیکربندی در زیر را ببینید).

سرور در پاسخ به یک پرسمان معتبر، یکی از سه نوع پیام زیر را برمی‌گرداند:

•
DHCPLEASEUNKNOWN
زمانی بازگردانده می‌شود که آدرس IP مورد نظر برای سرور ناشناخته باشد (پرسمان بر اساس آدرس IP)؛ یا هیچ اجاره فعالی برای کلاینت مورد نظر وجود نداشته باشد (پرسمان بر اساس آدرس سخت‌افزاری یا شناسه کلاینت).
•
DHCPLEASEUNASSIGNED
زمانی بازگردانده می‌شود که آدرس IP برای سرور شناخته‌شده باشد اما هیچ اجاره فعالی برای آن وجود نداشته باشد (تنها برای پرسمان بر اساس آدرس IP اعمال می‌شود).
•
DHCPLEASEACTIVE
زمانی بازگردانده می‌شود که حداقل یک اجاره فعال منطبق با معیارها یافت شود.

برای هر دو پاسخ DHCPLEASEUNKNOWN و DHCPLEASEUNASSIGNED، تنها اطلاعاتی که در پاسخ به درخواست‌کننده بازگردانده می‌شود، همان پارامتر پرسمان است (یعنی یکی از موارد: آدرس IP، آدرس سخت‌افزاری یا شناسه کلاینت).

برای DHCPLEASEACTIVE، سرور اطلاعات زیر را برای جدیدترین اجاره فعال منطبق با معیارها در پاسخ ارائه می‌دهد:

  • ciaddr - روی آدرس IP اجاره تنظیم می‌شود
  • chaddr - روی آدرس سخت‌افزاری اجاره تنظیم می‌شود

علاوه بر این، یک یا چند مورد از گزینه‌های زیر نیز گنجانده می‌شوند:

گزینه کد محتوا
dhcp-client-identifier 61 از روی اجاره کپی می‌شود (در صورت وجود)
client-last-transaction-time 91 مدت زمانی که از client-last-transaction-time (CLTT) اجاره سپری شده است. این مقدار همچنین توسط سرور برای تنظیم مقادیر طول عمر و زمان‌سنج‌ها استفاده می‌شود.
dhcp-lease-time 51 طول عمر اجاره که مقدار CLTT از آن کسر شده است
dhcp-renewal-time 58 همان‌طور که توسط پیکربندی kea-dhcp4 کنترل شده و سپس مقدار CLTT از آن کسر شده است
dhcp-rebind-time 59 همان‌طور که توسط پیکربندی kea-dhcp4 تعیین شده و سپس مقدار CLTT از آن کسر شده است
dhcp-agent-options 82 در صورتی که روی اجاره ذخیره شده باشد. (ببینید: ذخیره‌سازی اطلاعات توسعه‌یافته اجاره <#dhcp4-store-extended-info>)
associated-ip 92 فهرستی از تمام آدرس‌های IP دیگری که کلاینت برای آن‌ها اجاره فعال دارد. (برای پرسمان بر اساس آدرس IP اعمال نمی‌شود)

گزینه dhcp-server-identifier (کد 54) در تمام پاسخ‌ها در راستای مطابقت با RFC 2131، بخش 4.3.1 بازگردانده می‌شود.

استاندارد RFC 4388 به درخواست‌کنندگان اجازه می‌دهد تا گزینه‌های خاصی را از طریق dhcp-parameter-request-list (PRL، گزینه 55) درخواست کنند. این مورد در حال حاضر در Kea پشتیبانی نمی‌شود..SS پیکربندی Leasequery در DHCPv4

پیکربندی کتابخانه قلاب (hook library) Leasequery برای استفاده سرراست است. این کتابخانه از یک پارامتر منفرد، requesters، پشتیبانی می‌کند که فهرستی از نشانی‌های IP است که بسته‌های DHCPLEASEQUERY از آن‌ها پذیرفته می‌شوند. به عبارت دیگر، این فهرستی از درخواست‌دهندگان شناخته‌شده است. کد زیر یک نمونه پیکربندی را با دو نشانی درخواست‌دهنده نشان می‌دهد:

{
 "hooks-libraries": [
     {
         "library": "libdhcp_lease_query.so",
         "parameters": {
             "requesters": [ "192.0.1.1", "10.0.0.2" ]
         }
     }
 ],
 ...
}

نکته:

از Kea 3.1.4 به بعد، امکان گنجاندن محدوده‌های نشانی درخواست‌دهنده در قالب CIDR مانند "192.0.1.0/24" نیز وجود دارد. لطفاً توجه داشته باشید که مشخص کردن محدوده‌ها ممکن است امنیت کمتری نسبت به استفاده صرف از نشانی‌های IP صریح داشته باشد.

قابلیت Leasequery ساده در DHCPv6 به درخواست‌دهنده این امکان را می‌دهد که اطلاعات اجاره (lease) فعال را برای یک نشانی IP منفرد یا یک DUID کلاینت منفرد پرس‌وجو کند. نوع پرس‌وجو و پارامترها در یک گزینه lq-query (44) متصل به پیام DHCPV6_LEASEQUERY منتقل می‌شوند:

•
query-type
این مقدار یا query-by-address (1) است یا query-by-clientid (2).
•
link-address
نشانی پیوند سراسری (global link address)، هنگامی که خالی نباشد، پرس‌وجو را ملزم می‌کند که به اجاره‌های درون آن "پیوند" محدود شود. Kea از این مقدار برای انتخاب تنها آن دسته از اجاره‌هایی استفاده می‌کند که به زیرشبکه‌هایی با پیشوند منطبق بر این مقدار تعلق دارند. اجاره‌های فعال برای تفویض‌های پیشوند (prefix delegations) مربوط به یک زیرشبکه منطبق، در پاسخ پرس‌وجو گنجانده می‌شوند، حتی اگر خود پیشوند تفویض‌شده خارج از پیشوند زیرشبکه قرار گیرد.
•
query-options
هنگام پرس‌وجو بر اساس نشانی، باید یک گزینه منفرد iaaddr (12) ارائه شود. هنگام پرس‌وجو بر اساس شناسه کلاینت (client ID)، باید یک گزینه منفرد clientid (1) ارائه شود. استاندارد RFC 5007 همچنین یک گزینه اختیاری oro (6) را برای درخواست بازگرداندن گزینه‌های خاص برای اجاره‌های منطبق مشخص کرده است. این قابلیت در حال حاضر پیاده‌سازی نشده است.

نکته:

بخش 3.3 استاندارد RFC 5007 https://datatracker.ietf.org/doc/html/rfc5007#section-3.3 بیان می‌کند که پرس‌وجو بر اساس نشانی IP باید یا یک اجاره (مثلاً انتساب) برای خود نشانی، یا یک اجاره برای پیشوند تفویض‌شده‌ای که شامل آن نشانی است بازگرداند.

پرس‌وجوهای DHCPV6_LEASEQUERY تنها در صورتی پذیرفته می‌شوند که نشانی مبدأ پرس‌وجو با مدخلی در فهرست نشانی‌های IP شناخته‌شده و مجاز برای پرس‌وجو مطابقت داشته باشد. این فهرست از نشانی‌های معتبر درخواست‌دهنده به عنوان بخشی از پیکربندی کتابخانه قلاب Leasequery مشخص می‌شود (به بخش پیکربندی در زیر مراجعه کنید). پرس‌وجوهای دریافتی از درخواست‌دهندگان ناشناس ثبت (log) و دور انداخته می‌شوند.

سرور در پاسخ به یک پرس‌وجوی معتبر، فعالیت‌های لازم را انجام داده و یک DHCPV6_LEASEQUERY_REPLY برمی‌گرداند. همه پاسخ‌ها حداقل شامل یک گزینه status-code (13) هستند که نتیجه پرس‌وجو را مطابق با جدول زیر نشان می‌دهد:

نتیجه پرس‌وجو برچسب وضعیت کد وضعیت متن وضعیت
فیلد نوع پرس‌وجوی نامعتبر STATUS_UnknownQueryType 7 "unknown query-type"
پرس‌وجو بر اساس نشانی IP فاقد گزینه نشانی STATUS_Malformed 10 "missing D6O_IAADDR"
پرس‌وجو بر اساس نشانی IP برای نشانی‌ای که در هیچ استخر پیکربندی‌شده‌ای قرار ندارد STATUS_NotConfigured 9 "address not in a configured pool"
پرس‌وجو بر اساس نشانی IP که تنها یک اجاره غیرفعال یافت (مانند منقضی‌شده، ردشده، بازپس‌گرفته‌شده-منقضی‌شده) STATUS_Success 0 "inactive lease exists"
پرس‌وجو بر اساس نشانی IP که هیچ اجاره‌ای (فعال یا غیرفعال) نیافت STATUS_Success 0 "no active lease"
پرس‌وجو بر اساس نشانی IP که یک اجاره فعال برای نشانی یافت STATUS_Success 0 "active lease found"
پرس‌وجو بر اساس شناسه کلاینت فاقد گزینه شناسه کلاینت STATUS_Malformed 10 "missing D6O_CLIENTID"
پرس‌وجو بر اساس شناسه کلاینت با نشانی پیوندی که با هیچ زیرشبکه پیکربندی‌شده‌ای مطابقت ندارد STATUS_NotConfigured 9 "not a configured link"
پرس‌وجو بر اساس شناسه کلاینت که هیچ اجاره منطبقی نیافت STATUS_Success 0 "no active leases"
پرس‌وجو بر اساس شناسه کلاینت که یک یا چند اجاره فعال یافت STATUS_Success 0 "active lease(s) found"

برای سناریوهایی که در آن‌ها پرس‌وجو یا نامعتبر بوده یا هیچ اجاره فعال منطبقی برای آن یافت نشده است، DHCPV6_LEASEQUERY_REPLY طبق جدول فوق تنها شامل گزینه status-code (12) خواهد بود.

هنگامی که یک پرس‌وجو اجاره‌های فعال را در بیش از یک زیرشبکه بیابد و link-address پرس‌وجو خالی باشد، آنگاه علاوه بر status-code، پیام DHCPV6_LEASEQUERY_REPLY شامل یک گزینه lq-client-link (48) خواهد بود. گزینه lq-client-link شامل فهرستی از نشانی‌های IPv6 است، یک نشانی برای هر زیرشبکه‌ای که در آن اجاره‌ای یافت شده است (به RFC 5007، بخش 4.1.2.5 https://datatracker.ietf.org/doc/html/rfc5007#section-4.1.2.5 مراجعه کنید). با این حال، اگر link-address پرس‌وجو خالی نباشد، فهرست پرس‌وجوها هرس می‌شود تا فقط شامل اجاره‌هایی باشد که متعلق به آن زیرشبکه هستند.

هنگامی که پرس‌وجو منجر به یک یا چند اجاره فعال شود که همگی به یک زیرشبکه منفرد تعلق دارند، علاوه بر status-code، پیام DHCPV6_LEASEQUERY_REPLY شامل یک گزینه client-data (45) خواهد بود (به RFC 5007، بخش 4.1.2.2 https://datatracker.ietf.org/doc/html/rfc5007#section-4.1.2.2 مراجعه کنید). گزینه client-data گزینه‌های زیر را کپسوله‌سازی می‌کند:.SS OPTION_CLIENT_DATA بازگردانده‌شده هنگام یافتن اجاره(های) فعال

گزینه کد محتوا
clientid 1 رونویسی‌شده از روی اجاره (در صورت وجود)
clt-time 46 مدت زمانی که از زمان آخرین تراکنش کلاینت (CLTT) اجاره سپری شده است. این مقدار توسط کارگزار نیز برای تنظیم طول‌عمر و مقادیر تایمر استفاده خواهد شد.
iaaddr 5 یک گزینه به ازای هر نشانی منطبق‌شده. فیلدها در هر گزینه: - نشانی اجاره - طول‌عمر معتبر کاهش‌یافته با CLTT - طول‌عمر ترجیحی کاهش‌یافته با CLTT
iaprefix 26 یک گزینه به ازای هر پیشوند منطبق‌شده. فیلدها در هر گزینه: - پیشوند - طول پیشوند - طول‌عمر معتبر کاهش‌یافته با CLTT - طول‌عمر ترجیحی کاهش‌یافته با CLTT

اگر اجاره با تازه‌ترین مقدار client-last-transaction-time (CLTT) دارای اطلاعات رله (relay) در بافت کاربری (user context) خود باشد (ببینید ذخیره‌سازی اطلاعات گسترش‌یافته اجاره <#store-extended-info-v6>)، آنگاه یک گزینه OPTION_LQ_RELAY_DATA به پاسخ افزوده می‌شود (ببینید RFC 5007, Section 4.1.2.4 https://datatracker.ietf.org/doc/html/rfc5007#section-4.1.2.4).

اطلاعات رله در اجاره، فهرستی با یک مدخل برای هر لایه رله است که بسته کلاینت (برای نمونه DHCPV6_REQUEST) از آن عبور کرده است؛ به‌طوری‌که نخستین مدخل در فهرست، بیرونی‌ترین لایه (نزدیک‌ترین به کارگزار) است. فیلد peer-address از lq-rely-option بر روی نشانی همتای این رله تنظیم می‌شود. سپس از فهرست رله‌ها برای ساخت یک پیام DHCPV6_RELAY_FORW معادل پیامی که حاوی بسته کلاینت بود (منهای بسته کلاینت) استفاده می‌شود. این پیام در فیلد DHCP-relay-message از گزینه lq-relay-data ذخیره می‌شود.

پیکربندی کتابخانه قلاب (hook library) Leasequery برای استفاده سرراست است. این کتابخانه از یک پارامتر منفرد، یعنی requesters پشتیبانی می‌کند که فهرستی از نشانی‌های IP است که بسته‌های DHCPV6_LEASEQUERY از آن‌ها پذیرفته می‌شوند. به عبارت دیگر، این فهرستی از درخواست‌کنندگان شناخته‌شده است. کد زیر یک پیکربندی نمونه را با دو نشانی درخواست‌کننده نشان می‌دهد:

{
 "hooks-libraries": [
     {
         "library": "libdhcp_lease_query.so",
         "parameters": {
             "requesters": [ "2001:db8:1::1", "2001:db8:2::1" ],
             "prefix-lengths": [ 72 ]
         }
     }
 ],
 ...
}

نکته:

از Kea 3.1.4 به بعد، گنجاندن محدوده‌هایی از نشانی‌های درخواست‌کننده در قالب CIDR مانند "2001:db8:1::/64" نیز امکان‌پذیر است. لطفاً توجه داشته باشید که تعیین محدوده‌ها ممکن است امنیت کمتری نسبت به استفاده انحصاری از نشانی‌های صریح IP داشته باشد.

هنگامی که یک پرس‌وجو بر پایه نشانی IP با هیچ اجاره نشانی موجودی منطبق نشود، جستجویی برای یافتن یک پیشوند واگذارشده (delegated prefix) منطبق انجام می‌پذیرد. این کار با پیمایش روی فهرستی از طول‌های پیشوند به ترتیب نزولی، استخراج پیشوندی با آن طول از نشانی مورد پرس‌وجو، و جستجو برای واگذاری منطبق با پیشوند حاصل انجام می‌شود. این فرآیند برای هر طول در فهرست تا زمانی که تطابقی یافت شود یا فهرست به پایان برسد ادامه می‌یابد.

به‌طور پیش‌فرض، فهرست طول‌های پیشوند مورد استفاده در جستجو، پس از رویدادهای پیکربندی (یا پیکربندی مجدد) به‌صورت پویا تعیین می‌شود. فهرست حاصل شامل مقادیر یکتای delegated-len است که از مجموعه استخرهای PD پیکربندی‌شده فعلی گردآوری شده است.

یک پارامتر اختیاری به نام prefix-lengths وجود دارد که امکان پیکربندی صریح فهرست را به‌جای تعیین پویای آن فراهم می‌آورد. این امر کنترل دقیق‌تری را بر روی اینکه کدام طول‌های پیشوند جستجو شوند ممکن می‌سازد. در مثال بالا، جستجوی طول پیشوند صرف‌نظر از اینکه استخرهایی با مقادیر دیگر برای delegated-len وجود داشته باشند یا خیر، به یک دور با استفاده از طول 72 محدود شده است. مشخص کردن یک فهرست خالی، همان‌گونه که در زیر نشان داده شده است:

:
               "prefix-lengths": [ ]
:

جستجو برای پیشوندهای واگذارشده را برای پرس‌وجو بر پایه نشانی IP غیرفعال می‌کند..SS پرسش دسته‌ای اجاره در DHCPv4 (DHCPv4 Bulk Leasequery)

قابلیت DHCPv4 Bulk Leasequery به یک درخواست‌کننده امکان می‌دهد تا اطلاعات اجاره‌های فعال را روی یک اتصال TCP پرس‌وجو کند. این ویژگی به سرور اجازه می‌دهد تا تمام اجاره‌های منطبق با یک پرس‌وجوی داده‌شده را برگرداند.

دو مورد از انواع پرس‌وجوهای مشخص‌شده در RFC 4388 - پرسش بر اساس نشانی MAC و پرسش بر اساس Client-identifier - انواع پرسش‌های دسته‌ای اجاره (Bulk Leasequery) تعیین‌شده در RFC 6926 هستند. آن RFC همچنین این انواع جدید Bulk Leasequery را تعریف می‌کند:

•
پرسش بر اساس شناسه رله (Query by Relay Identifier)
این پرس‌وجو حامل یک گزینه RAI (dhcp-agent-options (82)) به همراه زیرگزینه relay-id (12) است.
•
پرسش بر اساس شناسه دوردست (Query by Remote ID)
این پرس‌وجو حامل یک گزینه RAI (گزینه dhcp-agent-options (82)) به همراه زیرگزینه remote-id (2) است.
•
پرسش برای تمام نشانی‌های IP پیکربندی‌شده (Query for All Configured IP Addresses)
این نوع پرس‌وجو زمانی انتخاب می‌شود که هیچ نوع پرس‌وجوی دیگری مشخص نشده باشد.

استاندارد RFC 6926 همچنین گزینه‌های جدیدی را برای Bulk Leasequery تعریف می‌کند:

•
status-code (151)
این گزینه پاسخ، یک کد وضعیت نظیر MalformedQuery یا NotAllowed را به همراه یک پیام متنی اختیاری حمل می‌کند.
•
base-time (152)
این گزینه پاسخ، زمان مطلق فعلی را که پاسخ در آن ایجاد شده است حمل می‌کند. تمام گزینه‌های پاسخ دیگرِ مبتنی بر زمان، وابسته به این مقدار هستند.
•
start-time-of-state (153)
این گزینه پاسخ، زمان انتقال اجاره به وضعیت فعلی‌اش را حمل می‌کند.
•
query-start-time (154)
این گزینه پرس‌وجو یک زمان شروع پرس‌وجو را تعیین می‌کند؛ پاسخ‌ها فقط شامل اجاره‌هایی خواهند بود که قدیمی‌تر از این مقدار باشند.
•
query-end-time (155)
این گزینه پرس‌وجو یک زمان پایان پرس‌وجو را تعیین می‌کند؛ پاسخ‌ها فقط شامل اجاره‌هایی خواهند بود که جدیدتر از این مقدار باشند.
•
dhcp-state (156)
این گزینه پاسخ، وضعیت اجاره را حمل می‌کند.
•
data-source (157)
این گزینه پاسخ، منبع داده را به عنوان یک پرچم دوردست (remote flag) حمل می‌کند.

استاندارد RFC 6926 از گزینه Virtual Subnet Selection (221) تعریف‌شده در RFC 6607 مجدداً استفاده کرده و آن را گسترش می‌دهد.

نکته:

برنامه Kea هنوز از پرس‌وجوی تمام نشانی‌های IP پیکربندی‌شده پشتیبانی نمی‌کند، بنابراین گزینه dhcp-state قابل استفاده نیست، زیرا تنها اجاره‌های فعال می‌توانند در پاسخ‌ها بازگردانده شوند. Kea زمان شروع وضعیت اجاره و همچنین اطلاعات محلی/دوردست را نگهداری نمی‌کند، از این رو نمی‌تواند گزینه‌های متناظر start-time-of-state و data-source را منتشر کند. Kea از VPNها پشتیبانی نمی‌کند، بنابراین وجود گزینه 221 در پرس‌وجو به عنوان خطای (NotAllowed) در نظر گرفته می‌شود.

قابلیت DHCPv6 Bulk Leasequery به یک درخواست‌کننده توانایی پرس‌وجوی اطلاعات اجاره‌های فعال را روی یک اتصال TCP می‌دهد. این امر به سرور امکان می‌دهد تا تمام اجاره‌های فعال منطبق با پرس‌وجو را بازگرداند.

انواع جدیدی از پرس‌وجو در دسترس هستند: query-by-relay-id (3)، query-by-link-address (4) و query-by-remote-id (5).

یک کد وضعیت جدید، STATUS_QueryTerminated (11)، تعریف شده است اما هنوز توسط کتابخانه قلاب (hook library) استفاده نمی‌شود.

نکته:

برنامه Kea تلاش می‌کند تا پارامترهای نشانی پیوند (link address) را به پیشوندهای زیرشبکه‌های پیکربندی‌شده نگاشت کند. اگر نشانی داده‌شده خارج از تمام پیشوندهای زیرشبکه پیکربندی‌شده قرار گیرد، پرس‌وجو با کد وضعیت STATUS_NotConfigured با شکست مواجه می‌شود. چنانچه پارامتر link address برای query-by-relay-id یا query-by-remote-id برابر با :: نباشد (یعنی خالی نباشد)، تنها پیشوندهای واگذارشده‌ای که درون پیشوندهای زیرشبکه منطبق قرار دارند بازگردانده می‌شوند. در حال حاضر، query-by-address از یافتن پیشوندهای واگذارشده با مشخص کردن نشانی‌ای که درون پیشوند قرار دارد، پشتیبانی نمی‌کند.

پیکربندی Bulk Leasequery از طریق یک پارامتر نگاشت (map) جدید به نام advanced با این ورودی‌های ممکن مشخص می‌شود:

•
bulk-query-enabled
هنگامی که true باشد، Kea اتصال‌ها را از نشانی‌های IP موجود در فهرست requesters می‌پذیرد و bulk leasequeryهای دریافتی را پردازش می‌کند. مقدار پیش‌فرض false است.
•
active-query-enabled
این یک پارامتر پیش‌بینی‌شده است: در صورت تنظیم، باید false باشد.
•
extended-info-tables-enabled
هنگامی که true باشد، پسانه اجاره (lease backend) اطلاعات تکمیلی اجاره DHCPv6 (اطلاعات رله) را در جدول‌ها مدیریت می‌کند تا از انواع جدید DHCPv6 Bulk Leasequery شامل by-relay-id و by-remote-id پشتیبانی کند. مقدار پیش‌فرض، استفاده از همان مقدار bulk-query-enabled است.
•
lease-query-ip
این نشانی IP است که باید برای اتصال‌ها روی آن شنود انجام شود. این نشانی باید از همان خانواده سرور باشد، برای مثال IPv6 برای سرور DHCPv6.
•
lease-query-port
این درگاهی (پورت) است که باید روی آن شنود شود. مقدار پیش‌فرض 67 برای IPv4 و 547 برای IPv6 است؛ یعنی همان مقدار سرویس UDP DHCP، اما برای TCP.
•
max-bulk-query-threads
این مقدار حداکثر تعداد ریسه‌هایی (threads) را نشان می‌دهد که پردازش bulk leasequery باید استفاده کند. مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسه‌هایی استفاده کند که هسته Kea برای چندریسمانی (multi-threading) پروتکل DHCP به کار می‌برد. مقدار پیش‌فرض 0 است.
•
max-requester-connections
این حداکثر تعداد اتصال‌های هم‌زمان درخواست‌کننده است. مقدار پیش‌فرض 10 است؛ مقدار باید بزرگ‌تر از 0 باشد.
•
max-concurrent-queries
این حداکثر تعداد پرس‌وجوهای هم‌زمان به ازای هر اتصال است. مقدار 0 به Kea امکان می‌دهد که تعداد را تعیین کند، و مقدار پیش‌فرض است.
•
max-requester-idle-time
این مدت‌زمانی است که پس از دریافت داده از یک درخواست‌کننده، پیش از اینکه اتصال آن به دلیل بیکار بودن (idle) بسته شود، می‌تواند سپری شود (به ثانیه). مقدار پیش‌فرض 300 است.
•
max-leases-per-fetch
این حداکثر تعداد اجاره‌ها برای بازگرداندن در یک واکشی (fetch) منفرد است. مقدار پیش‌فرض 100 است.

پس از پشتیبانی از TLS، انتظار داریم پارامترهای مشترک TLS پیاده‌سازی شوند.

برای نمونه، برای DHCPv4:

{
  "hooks-libraries": [
      {
          "library": "libdhcp_lease_query.so",
          "parameters": {
              "requesters": [ "192.0.2.1", "192.0.2.2" ],
              "advanced" : {
                   "bulk-query-enabled": true,
                   "active-query-enabled": false,
                   "lease-query-ip": "127.0.0.1",
                   "lease-query-tcp-port": 67,
                   "max-bulk-query-threads": 0,
                   "max-requester-connections": 10,
                   "max-concurrent-queries": 4,
                   "max-requester-idle-time": 300,
                   "max-leases-per-fetch": 100
              }
          }
      }
  ],
  ...
}

یا برای DHCPv6:

{
  "hooks-libraries": [
      {
          "library": "libdhcp_lease_query.so",
          "parameters": {
              "requesters": [ "2001:db8:1::1", "2001:db8:2::1" ],
              "advanced" : {
                   "bulk-query-enabled": true,
                   "active-query-enabled": false,
                   "extended-info-tables-enabled": true,
                   "lease-query-ip": "::1",
                   "lease-query-tcp-port": 547,
                   "max-bulk-query-threads": 0,
                   "max-requester-connections": 10,
                   "max-concurrent-queries": 4,
                   "max-requester-idle-time": 300,
                   "max-leases-per-fetch": 100
              }
          }
      }
  ],
  ...
}

ویژگی Bulk Leasequery نیازمند داده‌های اضافه‌تری برای اطلاعات اجارهٔ ذخیره‌شده است. در بک‌اندهای اجارهٔ SQL، اجاره‌هایی که پیش از پیکربندی کارساز برای Bulk Leasequery ایجاد شده‌اند، فاقد این داده‌های جدید مورد نیاز هستند. برای پر کردن این داده‌ها، اجرای این دستورهای API ضروری است:

نکته:

اجاره‌های موجود باید توسط Kea با فعال بودن store-extended-info ایجاد شده باشند تا داده‌های جدید از اطلاعات تکمیلی (extended info) قابل استخراج و ذخیره‌سازی باشند.

برای داده‌های اجارهٔ DHCPv4، دستور به این صورت است:

{
    "command": "extended-info4-upgrade"
}

برای داده‌های اجارهٔ DHCPv6، دستور به این صورت است:

برای اطلاعات تکمیلی مورد استفاده توسط relay ID و توسط remote ID، دستور به این صورت است:

{
    "command": "extended-info6-upgrade"
}

در تمام موارد، پاسخ نشان می‌دهد که عملیات با موفقیت انجام شده یا شکست خورده است و شامل تعداد اجاره‌های به‌روزشده یا ماهیت خطا خواهد بود:

{
    "result": 0,
    "text": "Upgraded 1000 leases"
}

این دستور extended-info6-upgrade باید در شرایط زیر اجرا شود:

  • طرحوارهٔ (schema) پایگاه داده از نگارش 2.4.1 یا نگارش‌های قدیمی‌تر ارتقا یافته باشد. هنگام ارتقا از نگارش 2.3.8 یا قدیمی‌تر می‌توان از extended-info4-upgrade استفاده کرد.
  • قابلیت Bulk Leasequery فعال نبوده باشد؛ جدول‌ها تنها زمانی نگهداری می‌شوند که v6 BLQ فعال باشد.
  • داده‌های موجود در جدول‌ها سازگار به نظر نرسند؛ جدول‌ها به صورت اتمیک نگهداری نمی‌شوند، بنابراین سازگاری تضمین نمی‌شود. برای نمونه، هنگامی که یک پایگاه داده میان چند کارساز به اشتراک گذاشته شده است، ممکن است بین به‌روزرسانی‌ها شرایط رقابتی رخ دهد.

عملکرد دستور extended info توسط پارامتر extended-info-checks زیر عنصر sanity-checks کنترل می‌شود. لطفاً «بررسی‌های سلامت در DHCPv4» <#sanity-checks4> یا «بررسی‌های سلامت در DHCPv6» <#sanity-checks6> را ببینید.

برای تعداد زیادی از اجاره‌ها، ممکن است تکمیل این دستور مدتی زمان ببرد.

نکته:

هر دو دستور extended-info4-upgrade و extended-info6-upgrade برای استفادهٔ یک‌باره پس از ارتقا به نگارشی از Kea در نظر گرفته شده‌اند که به طور کامل از Bulk Leasequery در بک‌اندهای پایگاه داده پشتیبانی می‌کند. این دستورها برای استفادهٔ مکرر نیستند و در نگارش‌های آیندهٔ Kea حذف خواهند شد.

کتابخانهٔ قلاب Forensic Logging، قلاب‌هایی را فراهم می‌کند که گزارش تفصیلی تخصیص‌ها، تمدیدها، آزادسازی‌ها و سایر رویدادهای مربوط به اجاره را در مجموعه‌ای از فایل‌های لاگ ثبت می‌نمایند.

نکته:

کتابخانهٔ libdhcp_legal_log.so بخشی از کد منبع‌باز است و در دسترس همهٔ کاربران Kea قرار دارد. این کتابخانه پیش‌تر تنها در دسترس مشتریان ISC دارای قرارداد پشتیبانی تجاری بود.

نکته:

این کتابخانه فقط می‌تواند توسط فرایندهای kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

در بسیاری از حوزه‌های قضایی، شرکت‌ها - به ویژه ISPها - باید اطلاعات مربوط به نشانی‌هایی را که به کلاینت‌های DHCP اجاره داده‌اند ثبت کنند. این کتابخانه برای کمک به برآورده کردن این الزام طراحی شده است. اگر اطلاعاتی که ثبت می‌کند کافی باشد، می‌توان مستقیماً از آن استفاده کرد.

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

همچنین می‌توان از این کتابخانه به عنوان الگو یا نمونه‌ای برای قلاب ثبت گزارش سفارشی خود کاربر استفاده کرد. ثبت گزارش به عنوان مجموعه‌ای از قلاب‌ها انجام می‌شود تا امکان سفارشی‌سازی آن برای هر نیاز خاصی وجود داشته باشد؛ تغییر دادن یک کتابخانهٔ قلاب بسیار ساده‌تر و امن‌تر از دستکاری کد هسته است. علاوه بر این، با استفاده از ویژگی‌های قلاب، کاربرانی که نیازی به ثبت این اطلاعات ندارند می‌توانند آن را کنار بگذارند و از افت کارایی جلوگیری کنند..SS نام‌گذاری فایل لاگ (Log File Naming)

نام‌های فایل‌های لاگ از یک الگوی مشخص پیروی می‌کنند.

در صورت استفاده از day، month یا year به‌عنوان واحد زمانی، نام فایل از قالب زیر پیروی می‌کند:

path/base-name.CCYYMMDD.txt

که در آن CC بیانگر قرن، YY نشان‌دهندهٔ سال، MM نشان‌دهندهٔ ماه، و DD نشان‌دهندهٔ روز است.

در صورت استفاده از second به‌عنوان واحد زمانی، نام فایل از قالب زیر پیروی می‌کند:

path/base-name.TXXXXXXXXXXXXXXXXXXXX.txt

که در آن XXXXXXXXXXXXXXXXXXXX بیانگر زمان بر حسب ثانیه از ابتدای مبدأ یونیکس (UNIX epoch) است.

هنگام استفاده از second به‌عنوان واحد زمانی، فایل پس از سپری شدن تعداد ثانیه‌های مشخص‌شده در count چرخانده می‌شود. در مقابل، هنگام استفاده از day، month یا year به‌عنوان واحد زمانی، فایل هر زمان که بر اساس مورد، شمارش (count) روز، ماه یا سال آغاز شود، چرخانده می‌شود.

مقدارهای "path" و "base-name" همان‌طور که در زیر شرح داده شده در پیکربندی مشخص می‌شوند؛ بخش «پیکربندی قلاب‌های ثبت لاگ قضایی (Configuring the Forensic Logging Hooks)» را ببینید.

نکته:

هنگام اجرای کارسازهای Kea برای هر دو پروتکل DHCPv4 و DHCPv6، نام‌های لاگ باید متمایز باشند. مثال‌های موجود در «پیکربندی قلاب‌های ثبت لاگ قضایی (Configuring the Forensic Logging Hooks)» را ببینید.

برای استفاده از این قابلیت، کتابخانهٔ قلاب (hook library) باید در پیکربندی پودمان‌های کارساز DHCP مورد نظر گنجانده شود. libdhcp_legal_log.so می‌تواند لاگ‌ها را در یک فایل متنی یا در یک پایگاه‌داده ذخیره کند (ایجاد شده با استفاده از kea-admin <#std-iscman-kea-admin>؛ بخش‌های «ساخت اولیهٔ پایگاه‌دادهٔ MySQL» <#mysql-database-create> و «ساخت اولیهٔ پایگاه‌دادهٔ PostgreSQL» <#pgsql-database-create> را ببینید). این کتابخانه در کنار کتابخانه‌های Kea در "[kea-install-dir]/var/log/kea" نصب می‌شود، که در آن kea-install-dir توسط گزینهٔ --prefix در meson setup تعیین می‌شود و به‌طور پیش‌فرض /usr/local است. با فرض مقدار پیش‌فرض، kea-dhcp4 <#std-iscman-kea-dhcp4> را می‌توان به‌صورت زیر برای بارگذاری libdhcp_legal_log.so پیکربندی کرد:

{
    "Dhcp4": {
        "hooks-libraries": [
            {
                "library": "libdhcp_legal_log.so",
                "parameters": {
                    "path": "/var/log/kea",
                    "base-name": "kea-forensic4"
                }
            }
        ]
    }
}

برای kea-dhcp6 <#std-iscman-kea-dhcp6>، پیکربندی به این صورت است:

{
    "Dhcp6": {
        "hooks-libraries": [
            {
                "library": "libdhcp_legal_log.so",
                "parameters": {
                    "path": "/var/log/kea",
                    "base-name": "kea-forensic6"
                }
            }
        ]
    }
}

پارامترهای کتابخانهٔ قلاب برای پیکربندی فایل متنی عبارتند از:

•
path - دایرکتوری‌ای که فایل(های) لاگ قضایی در آن نوشته خواهند شد. مقدار پیش‌فرض "[kea-install-dir]/var/log/kea" است. این دایرکتوری باید وجود داشته باشد.

نکته:

از نسخهٔ Kea 2.7.9 به بعد، فایل‌های لاگ قانونی فقط می‌توانند در دایرکتوری خروجی تعیین‌شده در حین کامپایل نوشته شوند: "[kea-install-dir]/var/log/kea". این مسیر را می‌توان در زمان راه‌اندازی با تنظیم متغیر محیطی KEA_LEGAL_LOG_DIR روی مسیر دلخواه بازنویسی کرد. اگر مسیری غیر از این مقدار در path استفاده شود، Kea خطایی صادر کرده و از شروع به کار خودداری می‌کند، یا در صورت در حال اجرا بودن، یک خطای جبران‌ناپذیر ثبت می‌کند. برای سهولت در استفاده، کافی است پارامتر path را حذف کنید.
  • base-name - یک مقدار دلخواه که همراه با تاریخ فعلی سیستم برای تشکیل نام فایل لاگ قضایی جاری استفاده می‌شود. مقدار پیش‌فرض آن kea-legal است.
  • time-unit - واحد زمانی مورد استفاده برای چرخش فایل لاگ را پیکربندی می‌کند. مقدارهای معتبر عبارتند از second، day، month یا year. مقدار پیش‌فرض آن day است.
  • count - تعداد واحدهای زمانی که باید تا زمان چرخش فایل لاگ سپری شوند را پیکربندی می‌کند. این مقدار می‌تواند هر عدد مثبتی باشد، یا 0 که چرخش لاگ را غیرفعال می‌کند. مقدار پیش‌فرض آن 1 است.

اگر چرخش لاگ غیرفعال باشد، هنگام بارگذاری کتابخانه یک فایل جدید ایجاد می‌شود؛ نام فایل جدید با هر نام فایل قبلی متفاوت خواهد بود.

اقدامات اضافی را می‌توان درست قبل از بستن فایل قدیمی و پس از باز کردن فایل جدید انجام داد. این اقدامات باید به یک فایل اجرایی یا اسکریپت خارجی اشاره داشته باشند و با تنظیمات زیر پیکربندی می‌شوند:

  • prerotate - یک فایل اجرایی یا اسکریپت خارجی که با نام فایلی که قرار است بسته شود فراخوانی می‌شود. Kea منتظر پایان فرایند نمی‌ماند.
  • postrotate - یک فایل اجرایی یا اسکریپت خارجی که با نام فایلی که باز شده است فراخوانی می‌شود. Kea منتظر پایان فرایند نمی‌ماند.

این فایل‌های اجرایی باید در دایرکتوری "[kea-install-dir]/share/kea/scripts/" ذخیره شوند که می‌توان آن را هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_HOOK_SCRIPTS_PATH روی یک مسیر متفاوت بازنویسی کرد.

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

  • request-parser-format - یک عبارت ارزیابی‌شده و تجزیه‌شده که برای استخراج و ثبت داده‌ها از بستهٔ ورودی استفاده می‌شود.
  • response-parser-format - یک عبارت ارزیابی‌شده و تجزیه‌شده که برای استخراج و ثبت داده‌ها از بستهٔ پاسخ کارساز استفاده می‌شود.

برای مشاهدهٔ فهرستی از عبارت‌ها، به بخش «استفاده از عبارت‌ها در دسته‌بندی» <#classification-using-expressions> مراجعه کنید. در صورت پیکربندی هر یک از request-parser-format یا response-parser-format، قالب لاگ پیش‌فرض استفاده نخواهد شد. اگر هر دوی آن‌ها پیکربندی شوند، پیام لاگ حاصل با الحاق داده‌های استخراج‌شده از درخواست و داده‌های استخراج‌شده از پاسخ ساخته می‌شود.

قالب‌بندی سفارشی ثبت لاگ در چندین خط را با استفاده از رشتهٔ هگز 0x0a (کد ASCII برای خط جدید) امکان‌پذیر می‌کند. در فایل لاگ، در ابتدای هر خط برچسب زمانی لاگ اضافه می‌شود. برای بک‌اند پایگاه‌داده، داده‌ها (شامل نویسهٔ خط جدید) در همان مدخل ذخیره می‌شوند.

مثال‌ها:

{
    "Dhcp6": {
        "hooks-libraries": [
            {
                "library": "libdhcp_legal_log.so",
                "parameters": {
                    "path": "/var/log/kea",
                    "base-name": "kea-forensic6",
                    "request-parser-format": "'first line' + 0x0a + 'second line'",
                    "response-parser-format": "'also second line' + 0x0a + 'third line'"
                }
            }
        ]
    }
}

برخی داده‌ها ممکن است در درخواست یا فقط در پاسخ در دسترس باشند؛ داده‌های موجود در بستهٔ درخواست ممکن است با داده‌های موجود در بستهٔ پاسخ تفاوت داشته باشند.

زمینهٔ lease-client فقط با استفاده از قالب پیش‌فرض قابل چاپ است، زیرا این اطلاعات مستقیماً در بستهٔ درخواست یا بستهٔ پاسخ ذخیره نمی‌شود.

پارامتر timestamp-format می‌تواند برای تغییر برچسب زمانی ثبت‌شده در ابتدای هر خط استفاده شود. قالب‌بندی‌های مجاز مواردی هستند که توسط strftime پشتیبانی می‌شوند به‌علاوهٔ قالب اضافی '%Q' که زیرواحدهای میکروثانیه را اضافه می‌کند. مقدار پیش‌فرض عبارت است از: "%Y-%m-%d %H:%M:%S %Z". این پارامتر برای بک‌اندهای پایگاه‌داده که در آن‌ها برچسب زمانی در سطح طرحواره (schema) تعریف شده است، اثری ندارد.

مثال‌ها:

{
    "Dhcp6": {
        "hooks-libraries": [
            {
                "library": "libdhcp_legal_log.so",
                "parameters": {
                    "path": "/var/log/kea",
                    "base-name": "kea-forensic6",
                    "timestamp-format": "%H%t%w %F%%"
                }
            }
        ]
    }
}

پارامترهای اضافی برای اتصال پایگاه‌داده را می‌توان مشخص کرد، برای مثال:

{
  "Dhcp6": {
    "hooks-libraries": [
      {
        "library": "libdhcp_legal_log.so",
        "parameters": {
          "name": "database-name",
          "password": "1234",
          "type": "mysql",
          "user": "user-name"
        }
      }
    ]
  }
}

برای اطلاعات مشخص‌تر دربارهٔ پارامترهای مرتبط با پایگاه‌داده، لطفاً به «پیکربندی پایگاه‌دادهٔ اجاره‌ها» <#database-configuration4> و «پیکربندی پایگاه‌دادهٔ اجاره‌ها» <#database-configuration6> مراجعه کنید.

اگر تمایل دارید ثبت لاگ قضایی را به زیرشبکه‌های خاصی محدود کنید، پارامتر بولی "legal-logging" می‌تواند در یک زمینهٔ کاربری (user context) از این زیرشبکه‌ها مشخص شود. برای مثال:

{
    "Dhcp4": {
        "subnet4": [
            {
                "id": 1,
                "subnet": "192.0.2.0/24",
                "pools": [
                    {
                        "pool": "192.0.2.1 - 192.0.2.200"
                    }
                ],
                "user-context": {
                    "legal-logging": false
                }
            }
        ]
    }
}

این پیکربندی ثبت لاگ قضایی را برای زیرشبکهٔ "192.0.2.0/24" غیرفعال می‌کند. اگر پارامتر "legal-logging" مشخص نشده باشد، مقدار پیش‌فرض آن true خواهد بود که ثبت لاگ قضایی را برای زیرشبکه فعال می‌کند.

مثال زیر نحوهٔ غیرفعال کردن انتخابی ثبت لاگ قضایی را برای یک زیرشبکهٔ IPv6 نشان می‌دهد:

{
    "Dhcp6": {
        "subnet6": [
            {
                "id": 1,
                "subnet": "2001:db8:1::/64",
                "pools": [
                    {
                        "pool": "2001:db8:1::1-2001:db8:1::ffff"
                    }
                ],
                "user-context": {
                    "legal-logging": false
                }
            }
        ]
    }
}

برای کسب اطلاعات بیشتر دربارهٔ زمینه‌های کاربری در پیکربندی Kea، به «زمینه‌های کاربری در IPv4» <#dhcp4-user-contexts> و «زمینه‌های کاربری در IPv6» <#dhcp6-user-contexts> مراجعه کنید..SS "ورودی‌های گزارش DHCPv4 (DHCPv4 Log Entries)"

برای DHCPv4، این کتابخانه بر اساس پیام‌های DHCPREQUEST،‏ DHCPDECLINE،‏ DHCPRELEASE و غیره، و پاسخ‌های آن‌ها ورودی ایجاد می‌کند. بسته‌ها و اجاره‌های حاصل با رهگیری از طریق نقاط قلاب (hook points) زیر در نظر گرفته می‌شوند:

  • pkt4_receive
  • leases4_committed
  • pkt4_send
  • lease4_release
  • lease4_decline

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

timestamp address duration device-id {client-info} {relay-info} {user-context}

به طوری که:

  • timestamp - تاریخ و زمانی که ورودی گزارش نوشته شده است، در قالب strftime با فرمت "%Y-%m-%d %H:%M:%S %Z" ("%Z" نام منطقه زمانی است).
  • address - نشانی IPv4 اجاره‌داده‌شده‌ی اعطا شده، و اینکه آیا واگذار (assigned)، تمدید (renewed)، یا آزاد (released) شده است.
  • duration - طول عمر اجاره که بر حسب روز (در صورت وجود)، ساعت، دقیقه و ثانیه بیان می‌شود. طول عمر اجاره‌ی 0xFFFFFFFF با متن "infinite duration" مشخص می‌شود. این اطلاعات هنگام آزادسازی اجاره ارائه نمی‌شود.
  • device-id - نشانی سخت‌افزاری کلاینت که به صورت یک نوع عددی و رشته‌ای از ارقام هگزادسیمال نشان داده می‌شود.
  • client-info - گزینه‌ی شناسه کلاینت DHCP (گزینه 61) در صورت وجود، که به صورت یک رشته هگز نمایش داده می‌شود. هنگامی که محتوای آن قابل چاپ باشد، نمایش داده می‌شود.
  • relay-info - برای بسته‌های رله‌شده، مقادیر giaddr و گزینه‌های RAI شامل circuit-id، remote-id، و subscriber-id (زیرگزینه‌های ۱، ۲ و ۶ از گزینه ۸۲)، در صورت وجود. مقادیر circuit-id و remote-id به صورت رشته‌های هگز ارائه می‌شوند. هنگامی که محتوای آن‌ها قابل چاپ باشد، نمایش داده می‌شود.
  • user-context - بافت کاربری اختیاری مرتبط با اجاره.

برای مثال (شکست‌های خط در اینجا صرفاً برای خوانایی اضافه شده‌اند؛ آن‌ها در فایل گزارش وجود ندارند):

2018-01-06 01:02:03 CET Address: 192.2.1.100 has been renewed for 1 hrs 52 min 15 secs to a device with hardware address:
hwtype=1 08:00:2b:02:3f:4e, client-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33,
identified by circuit-id: 68:6f:77:64:79 (howdy) and remote-id: 87:f6:79:77:ef

یا برای آزادسازی:

2018-01-06 01:02:03 CET Address: 192.2.1.100 has been released from a device with hardware address:
hwtype=1 08:00:2b:02:3f:4e, client-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33,
identified by circuit-id: 68:6f:77:64:79 (howdy) and remote-id: 87:f6:79:77:ef

علاوه بر ثبت فعالیت‌های اجاره بر اساس ترافیک کلاینت DHCPv4، این کتابخانه‌ی قلاب همچنین ورودی‌هایی را برای دستورهای کانال کنترلی مدیریت اجاره زیر ثبت می‌کند: lease4-add،‏ lease4-update، و lease4-del. این موارد نمی‌توانند قالب‌بندی سفارشی داشته باشند. هر ورودی یک رشته‌ی واحد بدون نشانگرهای انتهای خط درون‌متنی است، و به طور معمول ساختاری به شکل زیر دارد:

lease4-add:

*timestamp* Administrator added a lease of address: *address* to a device with hardware address: *device-id*

بسته به آرگومان‌های دستور add، ممکن است شامل client-id و duration نیز باشد.

مثال:

2018-01-06 01:02:03 CET Administrator added a lease of address: 192.0.2.202 to a device with hardware address:
1a:1b:1c:1d:1e:1f for 1 days 0 hrs 0 mins 0 secs

lease4-update:

*timestamp* Administrator updated information on the lease of address: *address* to a device with hardware address: *device-id*

بسته به آرگومان‌های دستور update، ممکن است شامل client-id و مدت‌زمان اجاره (lease duration) نیز باشد.

مثال:

2018-01-06 01:02:03 CET Administrator updated information on the lease of address: 192.0.2.202 to a device
with hardware address: 1a:1b:1c:1d:1e:1f, client-id: 1234567890

lease4-del: عملیات حذف دارای دو شکل است، یکی بر اساس نشانی و دیگری بر اساس شناسه و نوع شناسه:

*timestamp* Administrator deleted the lease for address: *address*

یا

*timestamp* Administrator deleted a lease for a device identified by: *identifier-type* of *identifier*

در حال حاضر تنها نوع @b hw-address (نشانی سخت‌افزاری) پشتیبانی می‌شود.

مثال‌ها:

2018-01-06 01:02:03 CET Administrator deleted the lease for address: 192.0.2.202
2018-01-06 01:02:12 CET Administrator deleted a lease for a device identified by: hw-address of 1a:1b:1c:1d:1e:1f

اگر کتابخانه‌ی قلاب دسترسی‌پذیری بالا (High Availability) فعال باشد، شریک (partner) به طور دوره‌ای دستورهای اجاره را با قالبی مشابه ارسال می‌کند؛ تنها تفاوت این است که صادرکننده‌ی دستور به جای "Administrator" برابر "HA partner" خواهد بود.

*timestamp* HA partner added ...

یا

*timestamp* HA partner updated ...

یا

*timestamp* HA partner deleted ...

گزینه‌های request-parser-format و response-parser-format می‌توانند به ترتیب برای استخراج و ثبت داده‌ها از بسته‌ی ورودی و بسته‌ی پاسخ کارساز استفاده شوند. مقدار پیکربندی‌شده، یک عبارت تجزیه‌شده‌ی ارزیابی‌شونده است که یک رشته را بازمی‌گرداند. فهرستی از توکن‌ها در فرآیند رده‌بندی کارساز توصیف شده است. با احتیاط استفاده شود زیرا ممکن است بر کارایی کارساز تأثیر بگذارد. اگر هر یک از آن‌ها پیکربندی شود، قالب پیش‌فرض ثبت گزارش استفاده نمی‌شود. اگر هر دوی آن‌ها پیکربندی شوند، پیام گزارش حاصل با الحاق داده‌های ثبت‌شده‌ی استخراج‌شده از درخواست و داده‌های ثبت‌شده‌ی استخراج‌شده از پاسخ ساخته می‌شود.

قالب‌بندی سفارشی امکان ثبت گزارش در چند خط را با استفاده از رشته هگز 0x0a (کد ASCII برای خط جدید) فراهم می‌کند. در مورد فایل گزارش، در ابتدای هر خط برچسب زمان گزارش قرار می‌گیرد. برای بک‌اند پایگاه داده، داده‌ها (شامل نویسه خط جدید) در همان ورودی ذخیره می‌شوند.

مثال‌ها:

{
  "Dhcp4": {
    "hooks-libraries": [
      {
        "library": "libdhcp_legal_log.so",
        "parameters": {
          "name": "database-name",
          "password": "1234",
          "type": "mysql",
          "user": "user-name",
          "request-parser-format": "'log entry' + 0x0a + 'same log entry'",
          "response-parser-format": "'also same log entry' + 0x0a + 'again same log entry'"
        }
      }
    ]
  }
}

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

مثال‌ها:

{
    "request-parser-format": "ifelse(pkt4.msgtype == 4 or pkt4.msgtype == 7, 'Address: ' + ifelse(option[50].exists, addrtotext(option[50].hex), addrtotext(pkt4.ciaddr)) + ' has been released from a device with hardware address: hwtype=' + substring(hexstring(pkt4.htype, ''), 7, 1) + ' ' + hexstring(pkt4.mac, ':') + ifelse(option[61].exists, ', client-id: ' + hexstring(option[61].hex, ':'), '') + ifelse(pkt4.giaddr == 0.0.0.0, '', ' connected via relay at address: ' + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, ', circuit-id: ' + hexstring(option[82].option[1].hex, ':'), '') + ifelse(option[82].option[2].exists, ', remote-id: ' + hexstring(option[82].option[2].hex, ':'), '') + ifelse(option[82].option[6].exists, ', subscriber-id: ' + hexstring(option[82].option[6].hex, ':'), '')), '')",
    "response-parser-format": "ifelse(pkt4.msgtype == 5, 'Address: ' + addrtotext(pkt4.yiaddr) + ' has been assigned for ' + uint32totext(option[51].hex) + ' seconds to a device with hardware address: hwtype=' + substring(hexstring(pkt4.htype, ''), 7, 1) + ' ' + hexstring(pkt4.mac, ':') + ifelse(option[61].exists, ', client-id: ' + hexstring(option[61].hex, ':'), '') + ifelse(pkt4.giaddr == 0.0.0.0, '', ' connected via relay at address: ' + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, ', circuit-id: ' + hexstring(option[82].option[1].hex, ':'), '') + ifelse(option[82].option[2].exists, ', remote-id: ' + hexstring(option[82].option[2].hex, ':'), '') + ifelse(option[82].option[6].exists, ', subscriber-id: ' + hexstring(option[82].option[6].hex, ':'), '')), '')"
}

جزئیات:

این پیکربندی داده‌های زیر را در هنگام درخواست (request) و تمدید (renew) ثبت خواهد کرد:

Address: 192.2.1.100 has been assigned for 6735 seconds to a device with hardware address: hwtype=1 08:00:2b:02:3f:4e, client-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33, circuit-id: 68:6f:77:64:79, remote-id: 87:f6:79:77:ef, subscriber-id: 1a:2b:3c:4d:5e:6f

این پیکربندی داده‌های زیر را در هنگام آزادسازی (release) و رد کردن (decline) ثبت خواهد کرد:

Address: 192.2.1.100 has been released from a device with hardware address: hwtype=1 08:00:2b:02:3f:4e, client-id: 17:34:e2:ff:09:92:54 connected via relay at address: 192.2.16.33, circuit-id: 68:6f:77:64:79, remote-id: 87:f6:79:77:ef, subscriber-id: 1a:2b:3c:4d:5e:6f

نتیجه‌ی مشابهی را می‌توان تنها با پیکربندی request-parser-format به دست آورد.

مثال‌ها:

{
    "request-parser-format": "ifelse(pkt4.msgtype == 3, 'Address: ' + ifelse(option[50].exists, addrtotext(option[50].hex), addrtotext(pkt4.ciaddr)) + ' has been assigned' + ifelse(option[51].exists, ' for ' + uint32totext(option[51].hex) + ' seconds', '') + ' to a device with hardware address: hwtype=' + substring(hexstring(pkt4.htype, ''), 7, 1) + ' ' + hexstring(pkt4.mac, ':') + ifelse(option[61].exists, ', client-id: ' + hexstring(option[61].hex, ':'), '') + ifelse(pkt4.giaddr == 0.0.0.0, '', ' connected via relay at address: ' + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, ', circuit-id: ' + hexstring(option[82].option[1].hex, ':'), '') + ifelse(option[82].option[2].exists, ', remote-id: ' + hexstring(option[82].option[2].hex, ':'), '') + ifelse(option[82].option[6].exists, ', subscriber-id: ' + hexstring(option[82].option[6].hex, ':'), '')), ifelse(pkt4.msgtype == 4 or pkt4.msgtype == 7, 'Address: ' + ifelse(option[50].exists, addrtotext(option[50].hex), addrtotext(pkt4.ciaddr)) + ' has been released from a device with hardware address: hwtype=' + substring(hexstring(pkt4.htype, ''), 7, 1) + ' ' + hexstring(pkt4.mac, ':') + ifelse(option[61].exists, ', client-id: ' + hexstring(option[61].hex, ':'), '') + ifelse(pkt4.giaddr == 0.0.0.0, '', ' connected via relay at address: ' + addrtotext(pkt4.giaddr) + ifelse(option[82].option[1].exists, ', circuit-id: ' + hexstring(option[82].option[1].hex, ':'), '') + ifelse(option[82].option[2].exists, ', remote-id: ' + hexstring(option[82].option[2].hex, ':'), '') + ifelse(option[82].option[6].exists, ', subscriber-id: ' + hexstring(option[82].option[6].hex, ':'), '')), ''))"
}

جزئیات:.SS "ورودی‌های گزارش DHCPv6 (DHCPv6 Log Entries)"

برای DHCPv6، کتابخانه بر اساس پیام‌های REQUEST،‏ RENEW،‏ RELEASE و DECLINE و غیره و پاسخ‌های آن‌ها ورودی ایجاد می‌کند. بسته‌ها و اجاره‌های حاصل در نظر گرفته شده و از طریق نقاط قلاب (hook points) زیر رهگیری می‌شوند:

  • pkt6_receive
  • leases6_committed
  • pkt6_send
  • lease6_release
  • lease6_decline

هر ورودی یک رشته منفرد بدون نشانگرهای انتهای خط درون‌متنی و با یک برچسب زمانی (timestamp) در ابتدا است که بخش‌های زیر را شامل می‌شود:

timestamp address duration device-id {relay-info}* {user-context}

که در آن:

  • timestamp - تاریخ و زمان ثبت ورودی گزارش، در قالب strftime به صورت "%Y-%m-%d %H:%M:%S %Z" (که "%Z" نام منطقه زمانی است).
  • address - آدرس یا پیشوند IPv6 اجاره داده‌شده، و وضعیت آن از نظر تخصیص‌یافته، تمدیدشده یا آزادشده بودن.
  • duration - طول عمر اجاره بیان‌شده به روز (در صورت وجود)، ساعت، دقیقه و ثانیه. طول عمر اجاره با مقدار 0xFFFFFFFF با متن "infinite duration." مشخص خواهد شد. این اطلاعات هنگام آزادسازی اجاره ارائه نمی‌شود.
  • device-id - شناسه DUID و آدرس سخت‌افزاری کلاینت (در صورت وجود).
  • relay-info - برای بسته‌های رله‌شده، محتوای پیام‌های کارگزار رله، و گزینه‌های remote-id (کد ۳۷)، subscriber-id (کد ۳۸) و interface-id (کد ۱۸) در صورت وجود. توجه داشته باشید که گزینه interface-id، در صورت وجود، کل رابطی را که کارگزار رله پیام را روی آن دریافت کرده مشخص می‌کند. این معمولاً به یک پیوند واحد در شبکه ترجمه می‌شود، اما به توپولوژی خاص شبکه بستگی دارد. با این وجود، این اطلاعات مفیدی برای تعیین دقیق‌تر مکان دستگاه است، بنابراین در صورت وجود ثبت می‌شود.
  • user-context - بافت کاربر (user context) اختیاری مرتبط با اجاره.

به عنوان مثال (شکست‌های خط در اینجا برای خوانایی اضافه شده‌اند؛ آن‌ها در فایل گزارش وجود ندارند):

2018-01-06 01:02:03 PST Address:2001:db8:1:: has been assigned for 0 hrs 11 mins 53 secs
to a device with DUID: 17:34:e2:ff:09:92:54 and hardware address: hwtype=1 08:00:2b:02:3f:4e
(from Raw Socket) connected via relay at address: fe80::abcd for client on link address: 3001::1,
hop count: 1, identified by remote-id: 01:02:03:04:0a:0b:0c:0d:0e:0f and subscriber-id: 1a:2b:3c:4d:5e:6f

یا برای آزادسازی:

2018-01-06 01:02:03 PST Address:2001:db8:1:: has been released
from a device with DUID: 17:34:e2:ff:09:92:54 and hardware address: hwtype=1 08:00:2b:02:3f:4e
(from Raw Socket) connected via relay at address: fe80::abcd for client on link address: 3001::1,
hop count: 1, identified by remote-id: 01:02:03:04:0a:0b:0c:0d:0e:0f and subscriber-id: 1a:2b:3c:4d:5e:6f

علاوه بر ثبت فعالیت‌های اجاره ناشی از ترافیک کلاینت DHCPv6، کتابخانه قلاب ورودی‌هایی را نیز برای دستورهای کانال کنترلی مدیریت اجاره زیر ثبت می‌کند: lease6-add، lease6-update و lease6-del. هر ورودی یک رشته منفرد بدون نشانگرهای انتهای خط درون‌متنی است، و معمولاً شکل زیر را خواهد داشت:

lease6-add:

*timestamp* Administrator added a lease of address: *address* to a device with DUID: *DUID*

بسته به آرگومان‌های دستور add، ممکن است شامل آدرس سخت‌افزاری و مدت‌زمان نیز باشد.

مثال:

2018-01-06 01:02:03 PST Administrator added a lease of address: 2001:db8::3 to a device with DUID:
1a:1b:1c:1d:1e:1f:20:21:22:23:24 for 1 days 0 hrs 0 mins 0 secs

lease6-update:

*timestamp* Administrator updated information on the lease of address: *address* to a device with DUID: *DUID*

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

مثال:

2018-01-06 01:02:03 PST Administrator updated information on the lease of address: 2001:db8::3 to a device with
DUID: 1a:1b:1c:1d:1e:1f:20:21:22:23:24, hardware address: 1a:1b:1c:1d:1e:1f

lease6-del: عملیات حذف دارای دو شکل است، یکی بر اساس آدرس و دیگری بر اساس شناسه و نوع شناسه:

*timestamp* Administrator deleted the lease for address: *address*

یا

*timestamp* Administrator deleted a lease for a device identified by: *identifier-type* of *identifier*

در حال حاضر تنها نوع DUID پشتیبانی می‌شود.

مثال‌ها:

2018-01-06 01:02:03 PST Administrator deleted the lease for address: 2001:db8::3
2018-01-06 01:02:11 PST Administrator deleted a lease for a device identified by: duid of 1a:1b:1c:1d:1e:1f:20:21:22:23:24

اگر کتابخانه قلاب High Availability فعال باشد، شریک (partner) به صورت دوره‌ای دستورهای اجاره را با قالبی مشابه ارسال می‌کند؛ تنها تفاوت این است که صادرکننده دستور به جای "Administrator" عبارت "HA partner" است.

*timestamp* HA partner added ...

یا

*timestamp* HA partner updated ...

یا

*timestamp* HA partner deleted ...

گزینه‌های request-parser-format و response-parser-format می‌توانند به ترتیب برای استخراج و ثبت داده‌ها از بسته ورودی و بسته پاسخ سرور استفاده شوند. مقدار پیکربندی‌شده یک عبارت ارزیابی‌شده و تجزیه‌شده است که یک رشته برمی‌گرداند. فهرستی از نشانه‌ها (tokens) در فرآیند دسته‌بندی سرور شرح داده شده است. با احتیاط استفاده کنید زیرا ممکن است بر عملکرد سرور تأثیر بگذارد. اگر هر یک از آن‌ها پیکربندی شود، قالب پیش‌فرض ثبت وقایع استفاده نمی‌شود. اگر هر دوی آن‌ها پیکربندی شوند، پیام گزارش حاصل با الحاق داده‌های ثبت‌شده استخراج‌شده از درخواست و داده‌های ثبت‌شده استخراج‌شده از پاسخ ساخته می‌شود.

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

مثال‌ها:

{
  "Dhcp6": {
    "hooks-libraries": [
      {
        "library": "libdhcp_legal_log.so",
        "parameters": {
          "name": "database-name",
          "password": "1234",
          "type": "mysql",
          "user": "user-name",
          "request-parser-format": "'log entry' + 0x0a + 'same log entry'",
          "response-parser-format": "'also same log entry' + 0x0a + 'again same log entry'"
        }
      }
    ]
  }
}

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

نکات:

در مورد IPv6، بسته‌ها می‌توانند حاوی چندین گزینه IA_NA (۳) یا IA_PD (۲۵) باشند که هر کدام شامل چندین گزینه از جمله زیرگزینه‌های OPTION_IAADDR (۵) یا OPTION_IAPREFIX (۲۵) هستند. برای اینکه بتوان اجاره فعلی مرتبط با ورودی گزارش را چاپ کرد، کتابخانه قلاب forensic log به طور داخلی گزینه IA_NA یا IA_PD متناظر و زیرگزینه مربوطه که با اجاره فعلی مطابقت دارد را تفکیک می‌کند. کتابخانه قلاب روی تمام آدرس‌های تازه تخصیص‌یافته و همه آدرس‌های حذف‌شده پیمایش خواهد کرد و هر آدرس را برای ثبت به عنوان اجاره فعلی برای ورودی گزارش مربوطه در دسترس قرار می‌دهد.

آن‌ها با استفاده از عبارت‌های تجزیه‌کننده زیر در دسترس هستند:

اجاره فعلی مرتبط با OPTION_IAADDR:

addrtotext(substring(option[3].option[5].hex, 0, 16))

اجاره فعلی مرتبط با OPTION_IAPREFIX:

addrtotext(substring(option[25].option[26].hex, 9, 16))

سایر پارامترهای گزینه‌ها در آفست‌های مربوط به خود در گزینه در دسترس هستند. لطفاً برای جزئیات بیشتر RFC9915 را مطالعه کنید.

مثال‌ها:

{
    "request-parser-format": "ifelse(pkt6.msgtype == 8 or pkt6.msgtype == 9, ifelse(option[3].option[5].exists, 'Address: ' + addrtotext(substring(option[3].option[5].hex, 0, 16)) + ' has been released from a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), '') + ifelse(option[25].option[26].exists, 'Prefix: ' + addrtotext(substring(option[25].option[26].hex, 9, 16)) + '/' + uint8totext(substring(option[25].option[26].hex, 8, 1)) + ' has been released from a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), ''), '')",
    "response-parser-format": "ifelse(pkt6.msgtype == 7, ifelse(option[3].option[5].exists and not (substring(option[3].option[5].hex, 20, 4) == 0), 'Address: ' + addrtotext(substring(option[3].option[5].hex, 0, 16)) + ' has been assigned for ' + uint32totext(substring(option[3].option[5].hex, 20, 4)) + ' seconds to a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), '') + ifelse(option[25].option[26].exists and not (substring(option[25].option[26].hex, 4, 4) == 0), 'Prefix: ' + addrtotext(substring(option[25].option[26].hex, 9, 16)) + '/' + uint8totext(substring(option[25].option[26].hex, 8, 1)) + ' has been assigned for ' + uint32totext(substring(option[25].option[26].hex, 4, 4)) + ' seconds to a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), ''), '')"
}

جزئیات:

این پیکربندی داده‌های زیر را هنگام request،‏ renew و rebind برای NA ثبت می‌کند:

Address: 2001:db8:1:: has been assigned for 713 seconds to a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber-id: 1a:2b:3c:4d:5e:6f, connected at location interface-id: 72:65:6c:61:79:31:3a:65:74:68:30

این پیکربندی داده‌های زیر را هنگام request،‏ renew و rebind برای PD ثبت می‌کند:

Prefix: 2001:db8:1::/64 has been assigned for 713 seconds to a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber-id: 1a:2b:3c:4d:5e:6f, connected at location interface-id: 72:65:6c:61:79:31:3a:65:74:68:30

این پیکربندی داده‌های زیر را هنگام release و decline برای NA ثبت می‌کند:

Address: 2001:db8:1:: has been released from a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber-id: 1a:2b:3c:4d:5e:6f, connected at location interface-id: 72:65:6c:61:79:31:3a:65:74:68:30

این پیکربندی داده‌های زیر را هنگام release و decline برای PD ثبت می‌کند:

Prefix: 2001:db8:1::/64 has been released from a device with DUID: 17:34:e2:ff:09:92:54 connected via relay at address: fe80::abcd for client on link address: 3001::1, remote-id: 01:02:03:04:0a:0b:0c:0d:0e:0f, subscriber-id: 1a:2b:3c:4d:5e:6f, connected at location interface-id: 72:65:6c:61:79:31:3a:65:74:68:30

نتیجه مشابهی را می‌توان تنها با پیکربندی request-parser-format به دست آورد.

مثال‌ها:

{
    "request-parser-format": "ifelse(pkt6.msgtype == 3 or pkt6.msgtype == 5 or pkt6.msgtype == 6, ifelse(option[3].option[5].exists, 'Address: ' + addrtotext(substring(option[3].option[5].hex, 0, 16)) + ' has been assigned for ' + uint32totext(substring(option[3].option[5].hex, 20, 4)) + ' seconds to a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), '') + ifelse(option[25].option[26].exists, 'Prefix: ' + addrtotext(substring(option[25].option[26].hex, 9, 16)) + '/' + uint8totext(substring(option[25].option[26].hex, 8, 1)) + ' has been assigned for ' + uint32totext(substring(option[25].option[26].hex, 4, 4)) + ' seconds to a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), ''), ifelse(pkt6.msgtype == 8 or pkt6.msgtype == 9, ifelse(option[3].option[5].exists, 'Address: ' + addrtotext(substring(option[3].option[5].hex, 0, 16)) + ' has been released from a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), '') + ifelse(option[25].option[26].exists, 'Prefix: ' + addrtotext(substring(option[25].option[26].hex, 9, 16)) + '/' + uint8totext(substring(option[25].option[26].hex, 8, 1)) + ' has been released from a device with DUID: ' + hexstring(option[1].hex, ':') + ifelse(relay6[0].peeraddr == '', '', ' connected via relay at address: ' + addrtotext(relay6[0].peeraddr) + ' for client on link address: ' + addrtotext(relay6[0].linkaddr) + ifelse(relay6[0].option[37].exists, ', remote-id: ' + hexstring(relay6[0].option[37].hex, ':'), '') + ifelse(relay6[0].option[38].exists, ', subscriber-id: ' + hexstring(relay6[0].option[38].hex, ':'), '') + ifelse(relay6[0].option[18].exists, ', connected at location interface-id: ' + hexstring(relay6[0].option[18].hex, ':'), '')), ''), ''))"
}

جزئیات:.SS پس‌بند پایگاه داده (Database Backend)

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

لطفاً برای اطلاعات در مورد استفاده از پایگاه داده MySQL به MySQL <#mysql-database>، یا برای اطلاعات پایگاه داده PostgreSQL به PostgreSQL <#pgsql-database> مراجعه کنید. جدول logs بخشی از طرح‌واره‌های پایگاه داده Kea است.

پارامترهای پیکربندی بر اساس پارامترهای استاندارد پایگاه داده اجاره (lease)، همان‌طور که در Lease Database Configuration <#database-configuration4> تعریف شده است، گسترش می‌یابند. پارامتر type باید mysql، postgresql، logfile یا syslog باشد؛ هنگامی که وجود نداشته باشد یا روی logfile تنظیم شده باشد، از فایل‌ها استفاده می‌شود.

هیچ ابزار خاصی برای کار با پایگاه داده ارائه نشده است، اما می‌توان از ابزارهای استاندارد استفاده کرد؛ به عنوان مثال، برای استخراج جدول logs از یک پایگاه داده MySQL:

$ mysql --user keatest --password 1234 -e "select * from logs;"
+---------------------+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+----+
| timestamp           | address      | log                                                                                                                                                             | id |
+---------------------+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+----+
| 2022-03-30 17:38:41 | 192.168.50.1 | Address: 192.168.50.1 has been assigned for 0 hrs 10 mins 0 secs to a device with hardware address: hwtype=1 ff:01:02:03:ff:04, client-id: 00:01:02:03:04:05:06 | 31 |
| 2022-03-30 17:38:43 | 192.168.50.1 | Address: 192.168.50.1 has been assigned for 0 hrs 10 mins 0 secs to a device with hardware address: hwtype=1 ff:01:02:03:ff:04, client-id: 00:01:02:03:04:05:06 | 32 |
| 2022-03-30 17:38:45 | 192.168.50.1 | Address: 192.168.50.1 has been assigned for 0 hrs 10 mins 0 secs to a device with hardware address: hwtype=1 ff:01:02:03:ff:04, client-id: 00:01:02:03:04:05:06 | 33 |
+---------------------+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------+----+

همانند سایر ویژگی‌های مبتنی بر پایگاه داده، ثبت لاگ قانونی (forensic logging) از بازیابی اتصال پایگاه داده پشتیبانی می‌کند که می‌تواند با تنظیم پارامتر on-fail فعال شود. در صورت عدم تعیین، مقدار پارامتر on-fail در ثبت لاگ قانونی به‌طور پیش‌فرض برابر با serve-retry-continue است. این بر خلاف کتابخانه‌های libdhcp_lease_cmds.so، libdhcp_host_cmds.so و libdhcp_cb_cmds.so است که در آن‌ها on-fail به‌طور پیش‌فرض برابر با stop-retry-exit می‌باشد. در این حالت، کارساز به خدمت‌رسانی به کلاینت‌ها ادامه می‌دهد و حتی در صورت شکست سازوکار بازیابی نیز خاموش نمی‌شود. اگر on-fail بر روی serve-retry-exit تنظیم شود، در صورتی که اتصال به پس‌بند پایگاه داده طبق پارامترهای max-reconnect-tries و reconnect-wait-time بازیابی نشود، کارساز خاموش خواهد شد، اما تا زمانی که این سازوکار فعال است به سرویس‌دهی به کلاینت‌ها ادامه می‌دهد.

در هنگام راه‌اندازی کارساز، ناتوانی در اتصال به هر یک از پس‌بندهای پیکربندی‌شده تنها در صورتی مهلک تلقی می‌شود که retry-on-startup بر روی false (پیش‌فرض) تنظیم شده باشد. یک خطای مهلک ثبت شده و کارساز خارج می‌شود، بر این فرض که پیکربندی باید در زمان راه‌اندازی معتبر باشد. خروج به سیستم‌عامل به اسکریپت‌های ناظر (nanny scripts) اجازه می‌دهد تا مشکل را تشخیص دهند. اگر retry-on-startup بر روی true تنظیم شود، کارساز تلاش‌ها برای اتصال مجدد را حتی در زمان راه‌اندازی کارساز یا در هنگام رخدادهای پیکربندی مجدد آغاز می‌کند و اقدام مشخص‌شده در پارامتر on-fail را اعمال می‌نماید.

مدخل‌های لاگ را می‌توان با تنظیم type بر روی syslog در syslog درج کرد. هنگامی که نوع syslog پیکربندی شده باشد، پارامتر pattern جزئیاتی را که برای ثبت لاگ استفاده می‌شوند مشخص می‌کند. برای جزئیات بیشتر به Logging <#logging> مراجعه کنید. در صورت عدم پیکربندی، پیش‌فرض آن به شرح زیر است:

"%-5p [%c.%t] %m\n"

پارامتر facility بخش (facility) مورد نظر در syslog را مشخص می‌کند و مقدار پیش‌فرض آن local0 است.

این کتابخانه قلاب (hook library) دو نوع محدودیت را فعال می‌کند:

1.
محدودسازی اجاره: حداکثر اجازه تخصیص n اجاره را در هر لحظه می‌دهد.
2.
محدودسازی نرخ: اجازه می‌دهد در هر time_unit حداکثر به n بسته پاسخ داده شود.

نکته:

libdhcp_limits.so بخشی از کد متن‌باز است و در دسترس تمام کاربران Kea قرار دارد. این کتابخانه پیش‌تر تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس بود.

مثال‌های زیر مربوط به kea-dhcp6 <#std-iscman-kea-dhcp6> هستند، اما به همان ترتیب برای kea-dhcp4 <#std-iscman-kea-dhcp4> نیز صدق می‌کنند. نویسه‌های عام "<limit-type>" و "<limit-value>" باید با کلیدها و مقادیر مربوطه برای هر نوع محدودیت شرح داده شده در بخش‌های بعد جایگزین شوند.

این کتابخانه می‌تواند توسط هر دو کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> با افزودن مسیر آن در عنصر "hooks-libraries" از پیکربندی کارساز بارگذاری شود.

{
  "Dhcp6": {
    "hooks-libraries": [
      {
        "library": "libdhcp_limits.so"
      }
    ]
  }
}

این اقدام به تنهایی هیچ چیزی را محدود نمی‌کند. محدودیت‌های مورد نظر به بافت کاربر (user context) در بخش پیکربندی عنصری که کلاینت‌های مشمول محدودیت را مشخص می‌کند اضافه می‌شوند: یک کلاس کلاینت یا یک زیرشبکه. پس از پیکربندی مجدد، در صورتی که Kea محدودیت‌های پیکربندی‌شده را تشخیص دهد، یک خط برای هر محدودیت پیکربندی‌شده لاگ می‌اندازد. پیام لاگ حاوی شناسه LIMITS_CONFIGURED خواهد بود.

نحوه تعریف محدودیت اجاره برای یک کلاس کلاینت به این صورت است:

{
  "Dhcp6": {
    "client-classes": [
      {
        "name": "cable-modem-1",
        "test": "option[123].hex == 0x000C4B1E",
        "user-context": {
          "limits": {
            "<limit>": "<limit-value>"
          }
        }
      }
    ]
  }
}

نحوه تعریف محدودیت اجاره برای یک زیرشبکه سراسری (global subnet) به این صورت است:

{
  "Dhcp6": {
    "subnet6": [
      {
        "id": 1,
        "subnet": "2001:db8::/64",
        "user-context": {
          "limits": {
            "<limit>": "<limit-value>"
          }
        }
      }
    ]
  }
}

نحوه تعریف محدودیت اجاره برای یک زیرشبکه درون یک شبکه اشتراکی (shared network) به این صورت است:

{
  "Dhcp6": {
    "shared-networks": [
      {
        "subnet6": [
          {
            "id": 1,
            "subnet": "2001:db8::/64",
            "user-context": {
              "limits": {
                "<limit>": "<limit-value>"
              }
            }
          }
        ]
      }
    ]
  }
}

نکته:

کتابخانه قلاب Limits از نام کلاس برای شناسایی کلاس کلاینت و از شناسه زیرشبکه (subnet ID) برای شناسایی یک زیرشبکه استفاده می‌کند. تغییر عبارت آزمون (test expression) در یک کلاس کلاینت یا محدوده شبکه یک زیرشبکه در حالی که نام یا شناسه بدون تغییر باقی بماند، شمارنده اجاره را برای کلاس کلاینت یا زیرشبکه مربوطه بازنشانی نمی‌کند. برای بازنشانی شمارنده اجاره، نام کلاس کلاینت یا شناسه زیرشبکه را تغییر دهید.

این امکان وجود دارد که تعداد اجاره‌هایی که یک گروه از کلاینت‌ها می‌توانند از یک سرور Kea DHCP یا از مجموعه‌ای از سرورهای همکار Kea DHCP دریافت کنند، محدود شود.

مقدار محدودیت اجاره می‌تواند به صورت یک عدد صحیح ۳۲ بیتی بدون علامت، یعنی بین 0 و 4,294,967,295 مشخص شود. هر نوع اجاره را می‌توان به صورت جداگانه محدود کرد. اجاره‌های IPv4 و اجاره‌های IA_NA در IPv6 از طریق مدخل پیکربندی "address-limit" محدود می‌شوند. اجاره‌های IA_PD در IPv6 از طریق مدخل پیکربندی "prefix-limit" محدود می‌شوند. در اینجا چند مثال آورده شده است:

  • "address-limit": 4
  • "prefix-limit": 2

برای محدودسازی اجاره، کلاس‌های کلاینت و تعداد اجاره‌های مرتبط با آن‌ها - که در برابر محدودیت‌های پیکربندی‌شده سنجیده می‌شوند - برای هر اجاره در فراخوان‌های قلاب (hook callouts) زیر به‌روزرسانی می‌شوند:

  • lease4_select
  • lease4_renew
  • lease6_select
  • lease6_renew
  • lease6_rebind

در نتیجه، کلاس‌هایی که مقدار "only-in-additional-list" برای آن‌ها "true" است، نمی‌توانند تحت محدودیت اجاره قرار گیرند. لطفاً برای اطلاعات بیشتر درباره اینکه کدام کلاس‌های کلاینت می‌توانند برای محدود کردن تعداد اجاره‌ها استفاده شوند، به مراحل دسته‌بندی <#classify-classification-steps> مراجعه کنید.

نکته:

تحت بار کاری بالا، ممکن است یک سرور Kea DHCP اجاره‌های بیشتری نسبت به آنچه محدودیت دقیقاً اجازه می‌دهد تخصیص دهد. این موضوع فقط در زمان جهش‌های ترافیکی شدید رخ می‌دهد که از کلاینت‌های متعلق به همان کلاس یا همان زیرشبکه (بسته به آنچه محدود شده است) ناشی می‌شوند. کاربران ممکن است علاقه‌مند به دنبال کردن روند توسعه محدودیت‌های اجاره اتمیک https://gitlab.isc.org/isc-projects/kea/-/issues/2449 در گیت‌لب ISC باشند.

امکان محدود کردن بسامد یا نرخی که بسته‌های ورودی بر اساس آن پاسخ دریافت می‌کنند وجود دارد.

مقدار محدودیت نرخ می‌تواند با قالب "<p> packets per <time-unit>" مشخص شود. <p> هر عددی است که بتوان آن را به صورت یک عدد صحیح ۳۲ بیتی بدون علامت نمایش داد، یعنی بین 0 و 4,294,967,295. <time-unit> می‌تواند هر یک از مقادیر second، minute، hour، day، week، month، یا year باشد. برای سادگی، یک month معادل ۳۰ روز در نظر گرفته می‌شود؛ به طور مشابه، یک year برای اهداف محدودسازی ۳۶۵ روز در نظر گرفته می‌شود. این ساختار نحوی طیف گسترده‌ای از نرخ‌ها را از یک اجاره در سال تا چهار میلیارد اجاره در ثانیه پوشش می‌دهد. این مقدار به مدخل پیکربندی "rate-limit" اختصاص داده می‌شود. در اینجا چند مثال آورده شده است:

  • "rate-limit": 1 packet per second
  • "rate-limit": 4 packets per minute
  • "rate-limit": 16 packets per hour

مقدار پیکربندی‌شده 0 بسته، روشی مناسب برای غیرفعال‌سازی کامل پردازش بسته برای برخی از کلاینت‌های خاص است. به این ترتیب، این مقدار بیانگر معنای تحت‌اللفظی خود است و برخلاف آنچه ممکن است تصور شود، یک مقدار ویژه برای غیرفعال کردن کلی محدودسازی نیست. غیرفعال کردن کامل محدودسازی با حذف مدخل پیکربندی برگ (leaf) "rate-limit"، نگاشت یا زمینه کاربری (user context) "limits" پیرامون آن، یا پیکربندی کتابخانه قلاب حاصل می‌شود. همین امر برای مقدار 0 در محدودسازی اجاره نیز صدق می‌کند. با این حال، دستیابی به آن مورد کاربرد با محدودسازی نرخ بهتر انجام می‌شود؛ زیرا بار محاسباتی کمتری به Kea وارد می‌کند، چرا که تصمیم برای نادیده‌گرفتن (drop) درخواست یا ارسال NAK در مراحل اولیه گرفته می‌شود.

از نظر محدودسازی نرخ، کلاس‌های کلاینت به ترتیب در فراخوان‌های pkt4_receive و pkt6_receive ارزیابی می‌شوند تا محدودیت‌های نرخ در زودترین زمان ممکن در چرخه پردازش بسته بررسی شوند. بدین ترتیب، تنها کلاس‌هایی که صرفاً از طریق یک عبارت آزمون مستقل به بسته اختصاص یافته‌اند، قابل استفاده هستند. کلاس‌هایی که به رزروهای میزبان (host reservations) یا کلاس‌های ویژه BOOTP یا KNOWN وابسته‌اند، و همچنین کلاس‌هایی که با "only-in-additional-list": true مشخص شده‌اند، نمی‌توانند مشمول محدودسازی نرخ شوند. برای جزئیات بیشتر درباره اینکه کدام کلاس‌های کلاینت می‌توانند برای محدود کردن نرخ بسته به کار روند، به مراحل دسته‌بندی <#classify-classification-steps> مراجعه کنید.

محدودیت‌های نرخ مبتنی بر زیرشبکه فقط بر روی زیرشبکه اولیه‌ای که برای یک بسته مشخص انتخاب شده اعمال می‌شوند. اگر زیرشبکه انتخاب‌شده متعاقباً تغییر کند (همان‌طور که ممکن است برای زیرشبکه‌های یک شبکه اشتراکی یا هنگام فعال بودن انتخاب مجدد در کتابخانه‌هایی مانند قلاب RADIUS رخ دهد)، محدودیت‌های نرخ در زیرشبکه جدیدِ انتخاب‌شده نادیده گرفته می‌شوند. به بیان دیگر، بسته‌ها فقط با محدودیت نرخ زیرشبکه اصلی کنترل می‌شوند.

نکته:

شاید منطقی به نظر برسد که تعیین محدودیت نرخ n بسته در هر واحد زمانی منجر به n تبادل DORA یا n تبادل SARR می‌شود. با این حال، به طور پیش‌فرض، تمام بسته‌های ورودی شمرده می‌شوند - یعنی یک تبادل پیام کامل معادل دو بسته به حساب می‌آید. برای رسیدن به این نتیجه که یک تبادل پیام فقط یک بار شمرده شود، از محدودسازی نرخ کلاس کلاینت همراه با یک عبارت آزمون استفاده کنید که pkt4.msgtype را به پیام‌های DHCPDISCOVER یا pkt6.msgtype را به پیام‌های SOLICIT مقید کند.

این کتابخانه قلاب، ذخیره‌سازی در پایگاه داده MySQL را برای موارد زیر پیاده‌سازی می‌کند:
  • پس‌زمینه اجاره (Lease Backend)
  • پس‌زمینه میزبان (Host Backend)
  • پس‌زمینه پیکربندی (Configuration Backend)

این کتابخانه قلاب همراه با libdhcp_cb_cmds.so کار می‌کند تا API لازم برای ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) پیکربندی در یک پایگاه داده MySQL را پیاده‌سازی کند. لطفاً برای جزئیات بیشتر به libdhcp_cb_cmds.so: Configuration Backend Commands مراجعه کنید.

نکته:

libdhcp_mysql.so بخشی از کد منبع‌باز است و برای همه کاربران Kea در دسترس است. با این حال، این کتابخانه قلاب فقط با libdhcp_cb_cmds.so کار می‌کند که مدیریت آسان پیکربندی را با استفاده از دستورات API فراهم می‌سازد. libdhcp_cb_cmds.so تنها در دسترس مشتریان ISC با قرارداد پشتیبانی پولی است؛ برای اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در https://www.isc.org/contact را تکمیل کنید.

کتابخانه قلاب پایش کارایی (perfmon) به کارسازهای Kea DHCPv4 و DHCPv6 قابلیت رهگیری و گزارش داده‌های مرتبط با کارایی را می‌دهد.

نکته:

libdhcp_perfmon.so بخشی از کد متن‌باز است و برای هر کاربر Kea در دسترس می‌باشد.

کتابخانه perfmon که در Kea 2.5.6 افزوده شده است، می‌تواند توسط دیمن‌های kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> با افزودن آن به عنصر hooks-libraries در پیکربندی کارساز بارگذاری شود:

{
    "hooks-libraries": [
        {
            "library": "libdhcp_perfmon.so",
            "parameters": {
                ...
            }
        },
        ...
    ],
    ...
}

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

1.
socket_received - هسته پرس‌وجوی کلاینت را در بافر سوکت قرار داد
2.
buffer_read - کارساز پرس‌وجوی کلاینت را از بافر سوکت خواند
3.
mt_queued - کارساز پرس‌وجوی کلاینت را در صف کار استخر ریسه خود قرار داد (فقط در حالت چندریسمانی)
4.
process_started - کارساز پردازش پرس‌وجو را آغاز کرده است
5.
process_completed - کارساز پاسخ را ساخته و آماده ارسال آن است

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

هنگامی که کتابخانه قلاب perfmon بارگذاری می‌شود، محتویات پشته رویداد بسته را برای هر پرس‌وجوی کلاینت که یک بسته پاسخ تولید می‌کند در گزارش ثبت می‌کند. مدخل گزارش شامل شناسه‌های پرس‌وجوی کلاینت است و به دنبال آن فهرستی از جفت‌های رویداد/برچسب زمانی به همان ترتیبی که رخ داده‌اند می‌آید.

برای kea-dhcp4 <#std-iscman-kea-dhcp4>، گزارش با برچسب PERFMON_DHCP4_PKT_EVENTS مشخص شده و در سطح اشکال‌زدایی (debug) ۵۰ یا بالاتر لاگر منتشر می‌شود. برای یک DHCPDISCOVER، این گزارش پس از آماده شدن DHCPOFFER برای ارسال منتشر می‌شود و مشابه تصویر زیر خواهد بود (به مدخل دوم نگاه کنید):

2024-03-20 10:52:20.069 INFO  [kea-dhcp4.leases/50033.140261252249344] DHCP4_LEASE_OFFER [hwtype=1 08:00:27:25:d3:f4], cid=[no info], tid=0xc288f9: lease 178.16.2.0 will be offered
2024-03-20 10:52:20.070 DEBUG [kea-dhcp4.perfmon-hooks/50033.140261252249344] PERFMON_DHCP4_PKT_EVENTS query: [hwtype=1 08:00:27:25:d3:f4], cid=[no info], tid=0xc288f9 events=[2024-Mar-20 14:52:20.067563 : socket_received, 2024-Mar-20 14:52:20.067810 : buffer_read, 2024-Mar-20 14:52:20.067897 : mt_queued, 2024-Mar-20 14:52:20.067952 : process_started, 2024-Mar-20 14:52:20.069614 : process_completed]

برای kea-dhcp6 <#std-iscman-kea-dhcp6>، گزارش با برچسب PERFMON_DHCP6_PKT_EVENTS مشخص شده و در سطح اشکال‌زدایی (debug) ۵۰ یا بالاتر لاگر منتشر می‌شود. برای یک DHCPV6_SOLICIT، این گزارش پس از آماده شدن DHCPV6_ADVERTISE برای ارسال منتشر می‌شود و مشابه تصویر زیر خواهد بود (به مدخل دوم نگاه کنید):

2024-03-20 10:22:14.030 INFO  [kea-dhcp6.leases/47195.139913679886272] DHCP6_LEASE_ADVERT duid=[00:03:00:01:08:00:27:25:d3:f4], [no hwaddr info], tid=0xb54806: lease for address 3002:: and iaid=11189196 will be advertised
2024-03-20 10:22:14.031 DEBUG [kea-dhcp6.perfmon-hooks/47195.139913679886272] PERFMON_DHCP6_PKT_EVENTS query: duid=[00:03:00:01:08:00:27:25:d3:f4], [no hwaddr info], tid=0xb54806 events=[2024-Mar-20 14:22:14.028729 : socket_received, 2024-Mar-20 14:22:14.028924 : buffer_read, 2024-Mar-20 14:22:14.029005 : process_started, 2024-Mar-20 14:22:14.030566 : process_completed]

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

  • query message type - نوع پیام پرس‌وجوی کلاینت (مانند DHCPDISCOVER، DHCPV6_REQUEST)
  • response message type - نوع پیام پاسخ کارساز (مانند DHCPOFFER، DHCPV6_REPLY)
  • start event label - رویدادی که آغاز فعالیت را مشخص می‌کند (مانند socket_received، process_started)
  • stop event label - رویدادی که پایان فعالیت را مشخص می‌کند (مانند buffer_read، process_completed)
  • subnet id - زیرشبکه انتخاب‌شده در حین پردازش پیام (یا 0 برای مدت‌زمان‌های سراسری)

به محض اینکه کارساز ساخت پاسخ برای یک پرس‌وجو را تمام کند، پشته رویداد آن پرس‌وجو به مجموعه‌ای از به‌روزرسانی‌ها برای مدت‌زمان‌های پایش‌شده پردازش می‌شود. اگر پس از به‌روزرسانی مشخص شود که بازه نمونه‌برداری یک مدت‌زمان کامل شده است، برای گزارش‌دهی ارسال می‌شود و یک بازه نمونه‌برداری جدید آغاز می‌گردد. طول بازه توسط پارامتر پیکربندی interval-width-secs تعیین می‌شود.

پشته رویداد برای چرخه DHCPDISCOVER/DHCPOFFER در حالت چندریسمانی که در بالا نمایش داده شد شامل رویدادهای زیر است:

برچسب زمانی رویداد برچسب رویداد
2024-Mar-20 14:52:20.067563 socket_received
2024-Mar-20 14:52:20.067810 buffer_read
2024-Mar-20 14:52:20.067897 mt_queued
2024-Mar-20 14:52:20.067952 process_started
2024-Mar-20 14:52:20.069614 process_completed

با فرض اینکه شناسه زیرشبکه (subnet ID) انتخاب‌شده 100 بوده باشد، به‌روزرسانی‌های مدت‌زمان ایجادشده توسط perfmon بر اساس این رویدادها در زیر نمایش داده شده است:

کلیدهای مدت‌زمان برای شناسه زیرشبکه 100 به‌روزرسانی به میکروثانیه
DHCPDISCOVER.DHCPOFFER.socket_received-buffer_read.100 247
DHCPDISCOVER.DHCPOFFER.buffer_read-mt_queue.100 87
DHCPDISCOVER.DHCPOFFER.mt_queued-process_started.100 55
DHCPDISCOVER.DHCPOFFER.process_started-process_completed.100 1662
DHCPDISCOVER.DHCPOFFER.composite-total_response.100 2051

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

کلیدهای مدت‌زمان سراسری به‌روزرسانی به میکروثانیه
DHCPDISCOVER.DHCPOFFER.socket_received-buffer_read.0 247
DHCPDISCOVER.DHCPOFFER.buffer_read-mt_queue.0 87
DHCPDISCOVER.DHCPOFFER.mt_queued-process_started.0 55
DHCPDISCOVER.DHCPOFFER.process_started-process_completed.0 1662
DHCPDISCOVER.DHCPOFFER.composite-total_response.0 2051

هنگامی که فعال باشد، perfmon در هر بار تکمیل یک بازه نمونه‌برداری توسط یک مدت‌زمان (duration)، داده‌های آن را گزارش می‌دهد (به stats-mgr-reporting در بخش پیکربندی مراجعه کنید). هر آمار از قرارداد نام‌گذاری زیر پیروی می‌کند:

{subnet-id[x]}.perfmon.<query type>-<response type>.<start event>-<end event>.<value-name>

برای هر مورد، هم یک مقدار سراسری و هم یک مقدار ویژهٔ زیرشبکه وجود دارد. در حال حاضر، تنها مقداری که برای یک کلید مدت‌زمان مشخص گزارش می‌شود mean-usecs است؛ این آمار میانگین زمان بین جفت‌رویدادِ آن مدت‌زمان در طول آخرین بازهٔ تکمیل‌شده است. به عبارت دیگر، اگر در طول یک بازهٔ مشخص هفت رخداد (یعنی به‌روزرسانی) با مجموع 3500us رخ داده باشد، مقدار mean-usecs گزارش‌شده 500us خواهد بود. با ادامهٔ مثال بالا، آمارهای گزارش‌شده برای مقادیر در سطح زیرشبکه به صورت زیر نام‌گذاری می‌شوند:

subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.socket_received-buffer_read.mean-usecs
subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.buffer_read-mt_queue.mean-usecs
subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.mt_queued-process_started.mean-usecs
subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.process_started-process_completed.mean-usecs
subnet[100].perfmon.DHCPDISCOVER.DHCPOFFER.composite-total_response.mean-usecs

و برای مقادیر سراسری به این صورت نمایش داده می‌شوند:

perfmon.DHCPDISCOVER.DHCPOFFER.socket_received-buffer_read.mean-usecs
perfmon.DHCPDISCOVER.DHCPOFFER.buffer_read-mt_queue.mean-usecs
perfmon.DHCPDISCOVER.DHCPOFFER.mt_queued-process_started.mean-usecs
perfmon.DHCPDISCOVER.DHCPOFFER.process_started-process_completed.mean-usecs
perfmon.DHCPDISCOVER.DHCPOFFER.composite-total_response.mean-usecs

نتایج به StatsMgr گزارش می‌شوند؛ مؤلفه‌ای داخلی در Kea که داده‌ها را به عنوان آمارهایی گزارش می‌کند که می‌توان با دستورهای آماری آن‌ها را دریافت کرد. این داده‌ها با استفاده از دستورهای statistic-get-all <#std-isccmd-statistic-get-all>، statistic-global-get-all <#std-isccmd-statistic-global-get-all>، یا statistic-get <#std-isccmd-statistic-get> قابل واکشی هستند.

می‌توان هشدارها را برای نظارت بر مدت‌زمان‌های خاصی تعریف کرد. هر هشدار یک حد بالا، high-water-ms، و یک حد پایین، low-water-ms تعریف می‌کند. اگر میانگین مقدار گزارش‌شده برای مدت‌زمان از حد بالا فراتر رود، یک لاگ هشدار در سطح WARN صادر می‌شود، که در این مرحله هشدار «فعال‌شده» ("triggered") در نظر گرفته می‌شود. پس از فعال شدن، تا زمانی که میانگین گزارش‌شده برای مدت‌زمان بالاتر از حد پایین باقی بماند، لاگ سطح WARN در بازه گزارش هشدار که توسط alarm-report-secs مشخص شده تکرار می‌شود. هنگامی که میانگین به زیر حد پایین افت کند، هشدار پاک شده و یک لاگ در سطح INFO صادر می‌شود.

لاگ سطح WARN ناشی از فعال شدن هشدار شبیه به نمونه زیر است:

2024-03-20 10:22:14.030 WARN [kea-dhcp6.leases/47195.139913679886272] PERFMON_ALARM_TRIGGERED Alarm for DHCPDISCOVER.DHCPOFFER.composite-total_response.0 has been triggered since 2024-03-20 10:18:20.070000, reported mean duration 00:00:00.700000 exceeds high-water-ms: 500

لاگ سطح INFO ناشی از پاک شدن هشدار به این صورت است:

2024-03-20 10:30:14.030 INFO [kea-dhcp6.leases/47195.139913679886272] PERFMON_ALARM_CLEARED Alarm for DHCPDISCOVER.DHCPOFFER.composite-total_response.0 has been cleared, reported mean duration 00:00:00.010000 is now below low-water-ms: 25

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

{
     "command": "perfmon-control",
     "arguments": {
         "enable-monitoring": true,
         "stats-mgr-reporting": false
     }
}

صرف‌نظر از آرگومان‌های ارائه‌شده (در صورت وجود)، مقادیر حاصل از هر دو پرچم همواره بازگردانده می‌شوند:

{
    "result": 0,
    "text": "perfmon-control success",
    "arguments": {
         "enable-monitoring": true,
         "stats-mgr-reporting": false
    }
}

این دستور تمام داده‌های مدت‌زمان پایش‌شده را که در حال حاضر توسط کتابخانه قلاب (hook library) Perfmon در حافظه نگه‌داری می‌شوند، واکشی می‌کند.

{
    "command": "perfmon-get-all-durations",
    "arguments": {
        "result-set-format": true
    }
}

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

قالب داده‌های مدت‌زمان پایش‌شده بازگردانده‌شده، توسط آرگومان اختیاری result-set-format تعیین می‌شود. هنگامی که false باشد (پیش‌فرض)، فهرست مدت‌زمان‌ها به صورت فهرستی از عناصر تکی مطابق شکل زیر بازگردانده خواهد شد:

{
    "arguments": {
       "durations": [{
           "duration-key": {
               "query-type": "DHCPDISCOVER",
               "response-type": "DHCPOFFER",
               "start-event": "buffer_read",
               "stop-event": "mt_queued",
               "subnet-id": 0
           },
           "max-duration-usecs": 118,
           "min-duration-usecs": 31,
           "occurrences": 501,
           "start-time": "2024-06-12 17:52:06.814884",
           "total-duration-usecs": 23951,
           "mean-duration-usecs": 47
        },
        ...
       ],
       "result-set-format": false,
       "interval-width-secs": 5,
       "timestamp": "2024-06-12 17:52:22.397233"
   },
"result": 0,
"text": "perfmon-get-all-durations: n found"
}

هنگامی که result-set-format برابر با true باشد، فهرست مدت‌زمان‌ها در قالبی مشابه با مجموعه نتایج (result set) پایگاه‌داده SQL به صورت زیر بازگردانده می‌شود:

{
    "arguments": {
        "durations-result-set": {
            "columns": [
                "query-type",
                "response-type",
                "start-event",
                "end-event",
                "subnet-id",
                "interval-start",
                "occurrence",
                "min-duration-usecs",
                "max-duration-usecs",
                "total-duration-usecs",
                "mean-duration-usecs"
            ],
            "rows": [ [
                "DHCPDISCOVER",
                "DHCPOFFER",
                "buffer_read",
                "mt_queued",
                0,
                "2024-06-12 17:52:06.814884",
                501,
                31,
                118,
                23951,
                47
                ],
                ...
            ]
        },
        "result-set-format": true,
        "interval-width-secs": 5,
        "timestamp": "2024-06-12 17:52:22.397233"
    },
    "result": 0,
    "text": "perfmon-get-all-durations: n found"
}

مقادیر داده برای هر مدت‌زمان از آخرین بازه داده‌های تکمیل‌شده آن مدت‌زمان خواهد بود. اگر یک مدت‌زمان فاقد چنین بازه‌ای باشد، مقدار interval-start برابر با "<none>" گزارش شده و مقادیر باقی‌مانده صفر خواهند بود..SS "پیکربندی (Configuration)"

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

•
این پارامتر تجمیع داده‌های رویداد را برای گزارش‌گیری، آمار و هشدارها فعال می‌کند. مقدار پیش‌فرض آن false است.
•
مدت‌زمانی را بر حسب ثانیه مشخص می‌کند که طی آن، مدت‌زمان انجام وظایف مجزا پیش از گزارش شدن در یک مجموعه تجمیع می‌شوند. مقدار پیش‌فرض ۶۰ ثانیه است.
•
گزارش‌دهی مقادیر تجمیع‌شده به StatsMgr را فعال می‌کند. مقدار پیش‌فرض آن true است.
•
مدت‌زمانی را بر حسب ثانیه میان دفعات ثبت لاگ برای یک هشدار پس از برانگیخته شدن آن مشخص می‌کند. مقدار پیش‌فرض ۳۰۰ ثانیه است.
•
فهرستی اختیاری از هشدارهایی است که مقادیر تجمیعی مدت‌زمان‌های خاصی را پایش می‌کنند. هر هشدار با این چهار پارامتر تعریف می‌شود:
•
مدت‌زمان پایش‌شده را برای موارد زیر مشخص می‌کند:
  • query-type - نوع پیام پرس‌وجوی کلاینت (مانند DHCPDISCOVER، DHCPV6_REQUEST)
  • response-type - نوع پیام پاسخ سرور (مانند DHCPOFFER، DHCPV6_REPLY)
  • start-event - رویدادی که آغاز وظیفه را مشخص می‌کند (مانند socket_received، process_started)
  • stop-event - رویدادی که پایان وظیفه را مشخص می‌کند
  • subnet-id - زیرشبکه انتخاب‌شده هنگام پردازش پیام (یا 0 برای مدت‌زمان‌های سراسری)
•
این هشدار را فعال یا غیرفعال می‌کند؛ مقدار پیش‌فرض true است.
•
مقداری را بر حسب میلی‌ثانیه مشخص می‌کند که مدت‌زمان باید بیش از آن باشد تا این هشدار برانگیخته شود؛ باید بزرگ‌تر از صفر باشد.
•
مقداری را بر حسب میلی‌ثانیه مشخص می‌کند که مدت‌زمان باید به کمتر از آن افت کند تا این هشدار پاک شود؛ باید بزرگ‌تر از صفر اما کمتر از high-water-ms باشد.

نکته:

ثبت غیرفعال وقایع رویدادها همواره فعال است، حتی بدون مشخص کردن بخش "parameters".

نمونه‌ای از پیکربندی در زیر نشان داده شده است:

{
    "hooks-libraries": [
    {
        "library": "libdhcp_perfmon.so",
        "parameters": {
            "enable-monitoring": true,
            "interval-width-secs": 5,
            "stats-mgr-reporting": true,
            "alarm-report-secs": 600,
            "alarms": [
            {
                "duration-key": {
                    "query-type": "DHCPDISCOVER",
                    "response-type": "DHCPOFFER",
                    "start-event": "process-started",
                    "stop-event": "process-completed",
                    "subnet-id": 0
                },
                "enable-alarm": true,
                "high-water-ms": 500,
                "low-water-ms": 25
            }]
        }
    }]
}

این کتابخانه قلاب قابلیت انجام «بررسی پینگ» ("ping check") روی یک آدرس IPv4 نامزد را پیش از پیشنهاد آن به یک کلاینت DHCP می‌افزاید. این ویژگی مشابه رفتاری است که در ISC DHCP وجود دارد و در RFC 2131 https://datatracker.ietf.org/doc/html/rfc2131، بخش ۳.۱، بند ۲ پیشنهاد شده است.

نکته:

کتابخانه libdhcp_ping_check.so بخشی از کد متن‌باز است و برای همه کاربران Kea در دسترس است. این قابلیت پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود.

کتابخانهٔ Ping Check، که در Kea 2.5.4 اضافه شده است، می‌تواند با افزوده شدن به عنصر hooks-libraries در پیکربندی کارگزار، توسط دیمن kea-dhcp4 <#std-iscman-kea-dhcp4> بارگذاری شود:

{
    "hooks-libraries": [
        {
            "library": "libdhcp_ping_check.so",
            "parameters": {
                ...
            }
        },
        ...
    ],
    ...
}

هنگامی که این کتابخانه بارگذاری شود، در صورتی که همهٔ شرایط زیر برقرار باشند، kea-dhcp4 <#std-iscman-kea-dhcp4> پیش از پیشنهاد یک اجاره به کلاینت، یک بررسی پینگ (ping check) انجام می‌دهد:

1.
کتابخانهٔ قلاب ping check بارگذاری شده باشد.
2.
بررسی پینگ فعال باشد.
3.
کارگزار در حال پاسخ‌گویی به یک DHCPDISCOVER باشد.
4.
اجارهٔ کاندید نه فعال باشد و نه رزرو شده.
5.
هر یک از موارد زیر درست باشد:
a. این نخستین پیشنهاد این اجاره به این کلاینت باشد. این بررسی تنها در صورتی قابل انجام است که offer-lifetime بزرگ‌تر از صفر باشد (یعنی تخصیص موقت در DHCPDISCOVER فعال باشد). اگر offer-lifetime صفر باشد، بررسی‌های پینگ برای هر DHCPOFFER انجام می‌شوند، زیرا کارگزار راهی برای دانستن اینکه آیا پیش‌تر پیشنهادی ارائه شده است یا خیر ندارد.
اجاره به کلاینتی غیر از مالک پیشین آن در حال پیشنهاد داده شدن باشد.

c. اجاره به مالک پیشین آن پیشنهاد داده شود و بیش از تعداد ثانیه‌های مشخص‌شده توسط ping-cltt-secs از CLTT اجارهٔ اولیه سپری شده باشد.

هنگامی که کتابخانهٔ ping check بارگذاری شده باشد، کارگزار kea-dhcp4 <#std-iscman-kea-dhcp4> با انجام مراحل زیر به یک DHCPDISCOVER پاسخ می‌دهد:

1. انتخاب یک آدرس IPv4 کاندید از طریق روندهای معمول و استفاده از آن برای ساخت یک DHCPOFFER.

2. پارک کردن DHCPOFFER و درخواست یک بررسی پینگ از کتابخانهٔ قلاب ping check از طریق فراخوان lease4_offer آن. برای آشنایی مقدماتی با پارک بسته‌ها، به Parked-Packet Limit مراجعه کنید.

3. آزمودن شرایط فراخوان که در بالا شرح داده شد: اگر برقرار نباشند، بدون انجام بررسی بازمی‌گردد و کارگزار DHCPOFFER را به کلاینت ارسال می‌کند. در غیر این صورت، فراخوان یک بررسی پینگ برای آدرس اجاره آغاز می‌کند.

4. پس از پایان بررسی پینگ، در صورتی که نتیجهٔ بررسی حاکی از در دسترس بودن آدرس باشد، کارگزار DHCPOFFER را به کلاینت ارسال می‌کند؛ در غیر این صورت، DHCPFOFFER را دور انداخته و یک اجارهٔ DECLINED برای آن آدرس ایجاد می‌کند.

هر بررسی پینگ شامل مراحل زیر است:

1. اگر تعداد ECHO REPLYهای ارسال‌شده کمتر از حداقل تعداد پیکربندی‌شده برای ارسال باشد، یک ICMP ECHO REQUEST به آدرس اجاره ارسال می‌شود. در غیر این صورت، نتیجه گرفته می‌شود که آدرس در دسترس است.

2. اگر هیچ ECHO REPLYای در بازهٔ زمانی قابل‌پیکربندی دریافت نشود، بازگشت به مرحلهٔ 1.

3.
به محض دریافت یک ICMP ECHO REPLY، نتیجه گرفته می‌شود که اجاره در دسترس نیست (NOT available).
4.
اگر هر یک از موارد زیر رخ دهد:
دریافت پیام ICMP DESTINATION UNREACHABLE
شکست در ارسال ICMP ECHO REQUEST به دلیل خطای شبکه (مانند غیرقابل‌دسترس بودن شبکه)
شکست در ارسال ICMP ECHO REQUEST به دلیل خطای دسترسی و مجوزها (مانند اینکه آدرس اجاره یک آدرس برودکست باشد)
شکست در ارسال ICMP ECHO REQUEST با خطای پر بودن بافر سوکت (socket buffer full)

از بررسی آدرس صرف‌نظر کرده و آن را در دسترس تلقی می‌کند.

نکته:

خطاهای "Socket buffer full" نشان می‌دهند که محدودیت‌های نرخ (rate limits) سیستم‌عامل روی ICMP رد شده است. کارگزار آن‌ها را دوباره تلاش نمی‌کند، زیرا احتمالاً تنها وضعیت را وخیم‌تر خواهد کرد. اگر این اتفاق به طور مداوم رخ دهد، ممکن است بار کلاینت‌ها روی کارگزار برای انجام بررسی پینگ بیش از حد زیاد باشد. بررسی پینگ برای سیستم‌هایی با توان عملیاتی (throughput) بالا توصیه نمی‌شود.

کتابخانهٔ قلاب ping check در حال حاضر از پارامترهای پیکربندی زیر پشتیبانی می‌کند که می‌توانند در سطوح سراسری (global) و زیرشبکه (subnet) تنظیم شوند؛ مقادیر سطح زیرشبکه بر مقادیر سراسری تقدم دارند:

  • enable-ping-check - این پارامتر بررسی پینگ را در یک حوزهٔ مشخص فعال یا غیرفعال می‌کند.
  • min-ping-requests - حداقل تعداد ECHO REQUESTهای ارسال‌شده بدون دریافت پاسخ، پیش از اعلام در دسترس بودن یک آدرس. مقدار پیش‌فرض 1 است؛ این مقدار باید بزرگ‌تر از صفر باشد.
  • reply-timeout - حداکثر مدت زمانی که برای دریافت پاسخ به یک ECHO REQUEST منفرد منتظر می‌ماند. این مقدار بر حسب میلی‌ثانیه مشخص شده و باید بزرگ‌تر از صفر باشد؛ مقدار پیش‌فرض 100 است.
  • ping-cltt-secs - تعداد ثانیه‌هایی را مشخص می‌کند که در صورت تعلق کلاینت به عنوان مالک قبلی اجاره، باید پس از CLTT اجاره سپری شود تا بررسی پینگ انجام شود. مقدار پیش‌فرض 60 ثانیه است.

پارامتر زیر تنها در سطح سراسری پشتیبانی می‌شود:

•
ping-channel-threads - در حالت چندنخی (multi-threaded)، این تعداد نخ‌ها در استخر نخ (thread pool) کانال است. مقدار پیش‌فرض 0 است که به کتابخانه دستور می‌دهد از همان تعداد نخ‌های هستهٔ Kea استفاده کند. اگر این مقدار در حالت تک‌نخی بودن Kea مشخص شود، نادیده گرفته خواهد شد.

گزیدهٔ پیکربندی زیر یک پیکربندی در سطح سراسری را نمایش می‌دهد:

{
    "hooks-libraries": [{
        "library": "libdhcp_ping_check.so",
        "parameters": {
            "enable-ping-check" : true,
            "min-ping-requests" : 1,
            "reply-timeout" : 100,
            "ping-cltt-secs" : 60,
            "ping-channel-threads" : 0
        }
    }]
}

گزیدهٔ زیر یک پیکربندی در سطح زیرشبکه را نشان می‌دهد:

 {
 "subnet4": [{
     "subnet": "192.0.2.0/24",
     "pools": [{
         "pool": "192.0.2.10 - 192.0.2.20"
     }],
     "user-context": {
         "ping-check": {
             "enable-ping-check" : true,
             "min-ping-requests" : 2,
             "reply-timeout" : 250,
             "ping-cltt-secs" : 120
         }
     }
 }]
}
این کتابخانه هوک ذخیره‌سازی پایگاه‌داده PostgreSQL را برای موارد زیر پیاده‌سازی می‌کند:
  • بک‌اند اجاره (Lease Backend)
  • بک‌اند میزبان (Host Backend)
  • بک‌اند پیکربندی (Configuration Backend)

این کتابخانه هوک در ارتباط با libdhcp_cb_cmds.so کار می‌کند تا API لازم جهت ایجاد، خواندن، به‌روزرسانی و حذف (CRUD) پیکربندی را در یک پایگاه‌داده PostgreSQL پیاده‌سازی کند. لطفاً برای جزئیات بیشتر به libdhcp_cb_cmds.so: Configuration Backend Commands مراجعه کنید.

نکته:

libdhcp_pgsql.so بخشی از کد متن‌باز است و برای تمام کاربران Kea در دسترس می‌باشد. با این حال، این کتابخانه هوک تنها با libdhcp_cb_cmds.so کار می‌کند که مدیریت آسان پیکربندی را با استفاده از دستورات API ممکن می‌سازد. libdhcp_cb_cmds.so تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس است؛ برای اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در https://www.isc.org/contact را تکمیل نمایید.

این کتابخانه هوک به سرورهای DHCP در Kea امکان می‌دهد تا از پروتکل RADIUS برای احراز صلاحیت کلاینت‌های DHCP از طریق سرویس دسترسی (access service)، یا برای ژورنال‌سازی اجاره‌های DHCP از طریق سرویس حسابرسی (accounting service) استفاده کنند. برای جزئیات مربوط به RADIUS در Kea، لطفاً RADIUS <#radius> را ببینید.

نکته:

libdhcp_radius.so بخشی از کد متن‌باز است و برای تمامی کاربران Kea در دسترس می‌باشد. این مورد پیش‌تر تنها برای مشتریان ISC با قرارداد پشتیبانی تجاری در دسترس بود.

پیش از پردازش دستورات در درخواست‌های HTTP دریافتی، libdhcp_rbac.so پارامترهای مشخصی را دریافت می‌کند، مانند بخش common-name در نام موضوع (subject name) گواهی کلاینت، تا نقشی را به درخواست اختصاص دهد. پیکربندی مرتبط با این نقش برای پذیرش یا رد دستور استفاده می‌شود. پس از پردازش، پاسخ می‌تواند بازنویسی شود؛ مثلاً بخش‌هایی از آن حذف گردند.

خلاصه‌ای از مراحل پردازش یک درخواست:
  • کتابخانه HTTP برخی از اطلاعات را برای استفاده‌های بعدی ثبت می‌کند، مانند آدرس دوردست (remote address).
  • هنگامی که TLS الزامی باشد اما درخواست توسط TLS محافظت نشده باشد، درخواست با ارسال پاسخ "unauthorized" رد می‌شود.
  • دستور از درخواست استخراج می‌شود.
  • با استفاده از اطلاعات ثبت‌شده در درخواست، یک نقش اختصاص داده می‌شود.
  • نقش برای پذیرش (عبور دادن) یا رد کردن (ارسال یک پاسخ forbidden به) دستور استفاده می‌شود.
خلاصه‌ای از مراحل پردازش یک پاسخ:
  • اطلاعات پیوست‌شده به درخواست، در طول پردازش درخواست (هنگامی که درخواست پذیرفته شد) بازیابی می‌شوند.
  • فیلترهای درخواست بر روی پاسخ اعمال می‌شوند.

نکته:

libdhcp_rbac.so تنها برای مشتریان ISC دارای قرارداد پشتیبانی تجاری در دسترس است. برای اطلاعات بیشتر درباره گزینه‌های اشتراک، لطفاً فرم موجود در https://www.isc.org/contact را تکمیل نمایید.

نکته:

از نسخه 2.7.2 در Kea، کنترل دسترسی مبتنی بر نقش (RBAC) دیگر محدود به Control Agent نیست: می‌تواند توسط هر سرور دیگری که از سوکت‌های کنترلی HTTP/HTTPS پشتیبانی می‌کند مانند سرورهای DHCPv4، DHCPv6 و DDNS استفاده شود. از نسخه 3.1.8 در Kea، مؤلفه منسوخ‌شده Control Agent حذف گردیده است.

تخصیص نقش توسط روش role-assignment پیکربندی‌شده مدیریت می‌شود.

نام توضیحات
remote-address آدرس IP دوردست/کلاینت
cert-subject بخش common-name از نام موضوع (subject name) گواهی کلاینت
cert-issuer بخش common-name از نام صادرکننده (issuer name) گواهی کلاینت
basic-authentication شناسه کاربری در احراز هویت اولیه HTTP
custom-value یک نقش دیگر می‌تواند در هوک‌های خارجی طراحی شود
"پارامترهای پیکربندی نقش (Role Configuration Parameters)"
box center;
l|l.
نام توضیحات
name نام نقش (به‌استثنای نقش‌های پیش‌فرض و ناشناخته)
accept-commands فهرست دسترسی مجاز (accept)
reject-commands فهرست دسترسی ردشده (reject)
other-commands مشخص می‌کند برای دستوراتی که با فهرست‌های مجاز و ردشده مطابقت ندارند چه عملی انجام شود (پیش‌فرض: reject)
list-match-first با تعیین فهرستی که باید ابتدا بررسی و اعمال شود، مشخص می‌کند برای دستوراتی که با هر دو فهرست مجاز و ردشده تطابق دارند چه اقدامی صورت گیرد (پیش‌فرض: accept)
response-filters فیلترهایی که باید روی پاسخ‌ها اعمال شوند

نکته:

تخصیص نقش ممکن است با cert-subject شکست بخورد، هنگامی که گواهی کلاینت الزامی نبوده باشد، یا ممکن است فاقد نام عمومی موضوع (subject common name) بوده و در عوض دارای یک نام جایگزین موضوع DNS باشد. در این حالت، تخصیص نقش یک نقش خالی بازمی‌گرداند و از مدخل default-role استفاده می‌شود.

تخصیص نقش می‌تواند مقداری غیرمنتظره بازگرداند، مثلاً در صورت وجود یک نام نقش ثبت‌نشده یا یک اشتباه تایپی. در این حالت، مدخل unknown-role به کار گرفته می‌شود.

رفتار پیش‌فرض برای هر دوی default-role و unknown-role رد کردن (reject) تمام دستورات است.

تمام دستورات REST API در فایل‌هایی درون دایرکتوری سورس src/share/api، یا در نسخهٔ نصب‌شدهٔ Kea در .../share/kea/api شرح داده شده‌اند. libdhcp_rbac.so این فایل‌ها را می‌خواند تا نام، حق دسترسی (یعنی read یا write)، و نام قلاب (hook) را دریافت کند. حق دسترسی را می‌توان در فایل تغییر داد اما تغییرات تنها پس از راه‌اندازی مجدد سرور یا کارگزار اعمال می‌شوند. حذف تعاریف دستور از .../share/kea/api پیامدهایی به همراه دارد: اگر فهرست کنترل دسترسی مبتنی بر read یا write باشد و فایل تعریف موجود نباشد، سرور یا کارگزار همواره چنین دستوری را رد می‌کند. اگر فهرست کنترل دسترسی از commands برای تعیین نام یک دستور استفاده کند و فایل تعریف آن دستور خاص در .../share/kea/api مفقود باشد، سرور Kea هنگام راه‌اندازی و خروج یک خطا لاگ می‌کند.

نام توضیحات
name (اجباری) نام دستور
access (اجباری) حق دسترسی، یعنی read یا write
hook (اختیاری) نام قلاب (برای دستورات سرورها یا کارگزارها خالی است یا وجود ندارد)

نکته:

این فایل‌های شرح دستور از نظر امنیتی حساس هستند؛ به عنوان مثال با مجوزهای دسترسی بیش از حد آزادانه، یک مهاجم محلی ممکن است آن‌ها را تغییر داده و هدف RBAC را بی‌اثر سازد.

فهرست‌های کنترل دسترسی را می‌توان با استفاده از یک نام (رشته) یا یک نگاشت تک‌مدخلی مشخص کرد..SS فهرست دسترسی نام‌گذاری‌شده از پیش تعریف‌شده

نام توضیحات
ALL با همه‌چیز مطابقت دارد
NONE با هیچ‌چیز مطابقت ندارد
READ با دستورهای دارای حق دسترسی خواندن (read-access) مطابقت دارد
WRITE با دستورهای دارای حق دسترسی نوشتن (write-access) مطابقت دارد

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

نام توضیحات پارامتر
not نقیض منطقی فهرست دسترسی
and عطف منطقی فهرستی از فهرست‌های دسترسی
or فصل منطقی فهرستی از فهرست‌های دسترسی
command فهرست صریح فهرستی از نام‌های دستور
access بر اساس حق دسترسی حق دسترسی (read یا write)
hook بر اساس قلاب نام قلاب (می‌تواند خالی باشد)

نام توضیحات
list-commands دستورهای غیرمجاز را از پاسخ list-commands حذف می‌کند

پارامترهای سراسری عبارتند از:

  • assign-role-method: نام روشی که برای تخصیص نقش استفاده می‌شود. این پارامتر اجباری است.
  • api-files: مسیر دایرکتوری‌ای که فایل‌های API توصیف‌کننده دستورها در آن یافت می‌شوند. این پارامتر اجباری است.
  • require-tls: تعیین اینکه آیا درخواست‌های دریافت‌شده از طریق HTTP (در مقایسه با HTTPS) رد شوند یا خیر. مقدار پیش‌فرض آن زمانی که روش تخصیص نقش مبتنی بر گواهی‌ها نباشد، false است.
  • commands: فهرست پیکربندی‌های دستورهای اضافی.
  • access-control-lists: تعاریف فهرست‌های کنترل دسترسی نام‌گذاری‌شده (هر تعریف یک نگاشت تک‌مدخلی است؛ نام مدخل، نام فهرست دسترسی و مقدار آن، مشخصات مربوطه است). این نام در بخش‌های دیگر پیکربندی، مانند "accept-commands" استفاده می‌شود.
  • roles: پیکربندی‌های نقش.
  • default-role: پیکربندی نقش پیش‌فرض (زمانی استفاده می‌شود که "" تخصیص یافته باشد).
  • unknown-role: پیکربندی نقش ناشناخته (زمانی استفاده می‌شود که نقش تخصیص‌یافتهٔ غیرخالی هیچ پیکربندی‌ای نداشته باشد).

    پیکربندی‌های نمونه در kea4/hooks-rbac.json <#config-example-kea4-hooks-rbac-json> و kea6/hooks-rbac.json <#config-example-kea6-hooks-rbac-json> موجود هستند.

این شبه‌کدِ الگوریتم تصمیم‌گیری پذیرش/رد است که مقدار true (پذیرش) یا false (رد) را برمی‌گرداند.

bool match(command) {
    if (list-match-first == accept) {
        if (accept_list && accept_list->match(command)) {
            return (true);
        }
        if (reject_list && reject_list->match(command)) {
            return (false);
        }
    } else {
        if (reject_list && reject_list->match(command)) {
            return (false);
        }
        if (accept_list && accept_list->match(command)) {
            return (true);
        }
    }
    if (others == reject) {
       return (false);
    } else {
       return (true);
    }
}

امکان داشتن یک هوک سفارشی همراه با دستورات جدید وجود دارد. در این حالت، می‌توان از کنترل دسترسی بر پایه نقش (Role Based Access Control) به دو روش برای مدیریت دستور جدید استفاده کرد.

پارامتر سراسری command می‌تواند برای تعریف نام، نوع دسترسی و نام هوک آن به کار رود:

{
"commands": [
        {
            "name": "my-new-command",
            "access": "write",
            "hook": "my-custom-hook"
        }
    ],
...
}

سپس دستور جدید می‌تواند در roles مشخص شود:

{
"roles": [
    {
        "name": "user1",
        "accept-commands": {
            "commands": [ "my-new-command" ] },
        "reject-commands": "WRITE",
        "list-match-first": "accept"
    },
    {
        "name": "user2",
        "accept-commands": { "hook": "my-custom-hook" },
        "reject-commands": "ALL",
        "list-match-first": "accept"
    }
],
...
}

روش دوم، ایجاد یک فایل سفارشی در .../share/kea/api و تعریف نوع دسترسی دستور(های) سفارشی است.

همچنین امکان بازتعریف یک دستور موجود با حذف فایل تعریف آن از .../share/kea/api و تعریف آن در پارامتر سراسری commands وجود دارد:

{
"commands": [
        {
            "name": "dhcp-disable",
            "access": "read",
            "hook": "my-custom-hook-3"
        }
    ]
}

با این رویکرد، مدیر سیستم می‌تواند پیکربندی‌های تمام دستورهای موجود را در فایل پیکربندی سرور قرار دهد.

در اینجا مثالی جامع برای نقشی آورده شده است که همهٔ دستورهای خواندن را، به استثنای config-get <#std-isccmd-config-get> می‌پذیرد (برای نمونه، جهت پنهان‌سازی گذرواژه‌ها). برای هر کاربر راه‌دور که به عنوان "user1" شناخته نشده باشد، تمام دستورها باید رد شوند.

گزینهٔ نخست، قرار دادن دستورهای مجاز در فهرست "accept-commands" و رد کردن هر چیز دیگری است:

{
"roles": [
{
    "name": "user1",
    "accept-commands":
    {
        "and": [
            "READ",
            { "not":
                { "commands": [ "config-get" ] }
            }
        ]
    },
    "reject-commands": "ALL",
    // This is the default but as the config relies on it
    // it is explicitly set.
    "list-match-first": "accept"
},
...
],
...
}

یک جایگزین رایج، تنظیم نکردن فهرست "reject-commands" است، یعنی خالی گذاشتن آن و تکیه بر "other-commands" برای رد کردن هر چیز دیگر.

{
"roles": [
{
    "name": "user2",
    "accept-commands":
    {
        "and": [
            "READ",
            { "not":
                { "commands": [ "config-get" ] }
            }
        ]
    },
    // This is the default but as the config relies on it
    // it is explicitly set.
    "other-commands": "reject"
},
...
],
...
}

همچنین می‌توان عکس آن را انجام داد، یعنی تنها فهرست "reject-commands" تنظیم شود:

{
"roles": [
{
    "name": "user3",
    "reject-commands":
    {
        "or": [
            "WRITE",
            { "commands": [ "config-get" ] }
        ]
    },
    "other-commands": "accept"
},
...
],
...
}

یا از هر دو فهرست استفاده شود به گونه‌ای که استثنا در فهرست "reject-commands" قرار گیرد؛ این فهرست باید ابتدا بررسی شود زیرا "config-get" دارای حق دسترسی خواندن (read-access) است.

{
"roles": [
{
    "name": "user4",
    "accept-commands": "READ",
    "reject-commands": { "commands": [ "config-get" ] },
    "list-match-first": "reject"
},
...
],
...
}

برای بررسی هر پیکربندی، ایدهٔ خوبی است که از فیلتر پاسخ "list-commands" استفاده شود که خطاهایی مانند دستورهای مفقود (رد شده) و دستورهای اضافی (پذیرفته شده) را نشان می‌دهد.

می‌توان از access-control-lists برای تعریف فهرست‌های کنترل دسترسی و سپس استفادهٔ مجدد در roles بهره برد:

{
"access-control-lists":[
    {
        "my-list-one":{
            "or":[
            {
                "hook": "subnet_cmds"
            },
            {
                "commands":[ "list-commands" ]
            }
            ]
        }
    },
    {
        "my-list-two":{
            "and":[
            "READ",
            {
                "not":{
                    "commands":[ "config-get" ]
                }
            }
            ]
        }
    },
    {
        "my-list-three":{
            "or":[
            { "hook":"subnet_cmds" },
            { "hook":"class_cmds" },
            { "hook":"lease_cmds" }
            ]
        }
    }
],
"roles":[
    {
        "name":"admin",
        "accept-commands":"my-list-one",
        "reject-commands":"ALL",
        "list-match-first":"accept"
    },
    {
        "name":"admin2",
        "accept-commands":"my-list-two",
        "reject-commands":"ALL",
        "list-match-first":"accept"
    }
],
"unknown-role":{
    "accept-commands":"my-list-three",
    "reject-commands":"ALL"
},
...
}

کتابخانه قلاب Run Script، پشتیبانی از فراخوانی یک اسکریپت خارجی را برای نقاط قلاب (hook points) خاص در پردازش بسته‌ها اضافه می‌کند.

نکته:

libdhcp_run_script.so بخشی از کد منبع‌باز است و برای هر کاربر Kea در دسترس است.

نکته:

این کتابخانه تنها می‌تواند توسط فرآیند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.
{
    "hooks-libraries": [
        {
            "library": "libdhcp_run_script.so",
            "parameters": {
                "name": "/full_path_to/script_name.sh",
                "sync": false
            }
        }
    ]
}

پارامترها شامل name هستند که مسیر کامل اسکریپت خارجی را برای فراخوانی در هر نقطه قلاب مشخص می‌کند، و همچنین گزینه sync، تا بتوان به‌طور همگام (synchronous) برای اتمام اجرای اسکریپت منتظر ماند. اگر پارامتر sync برابر با false باشد، اسکریپت راه‌اندازی شده و Kea منتظر پایان اجرای آن نخواهد ماند، که باعث می‌شود تمام پارامترهای خروجی (OUT) اسکریپت (از جمله گام بعدی) نادیده گرفته شوند.

اسکریپت خارجی باید در دایرکتوری "[kea-install-dir]/share/kea/scripts/" ذخیره شود که می‌توان آن را هنگام راه‌اندازی با تنظیم متغیر محیطی KEA_HOOK_SCRIPTS_PATH به یک مسیر دیگر بازنویسی کرد.

نکته:

اسکریپت تمام امتیازات و دسترسی‌ها را از سروری که آن را فراخوانی می‌کند به ارث می‌برد.

نکته:

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

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

نقاط قلاب dhcpv4:

lease4_renew
lease4_expire
lease4_recover
leases4_committed
lease4_release
lease4_decline

نقاط قلاب dhcpv6:

lease6_renew
lease6_rebind
lease6_expire
lease6_recover
leases6_committed
lease6_release
lease6_decline
addr6_register

هر نقطه قلاب داده‌های داخلی Kea را استخراج کرده و آن‌ها را به‌صورت متغیرهای محیطی رشته‌ای صادر (export) می‌کند. این پارامترها با استفاده از محیط فرآیند فرزند با اسکریپت مقصد به اشتراک گذاشته می‌شوند. تنها پارامتری که به فراخوانی اسکریپت مقصد ارسال می‌شود، نام نقطه قلاب است.

نمونه‌ای از یک اسکریپت که تمامی نقاط قلاب را پیاده‌سازی می‌کند در زیر ارائه شده است:

#!/bin/sh
unknown_handle() {
    echo "Unhandled function call ${*}"
    exit 123
}
lease4_renew () {
    ...
}
lease4_expire () {
    ...
}
lease4_recover () {
    ...
}
leases4_committed () {
    ...
}
lease4_release () {
    ...
}
lease4_decline () {
    ...
}
lease6_renew () {
    ...
}
lease6_rebind () {
    ...
}
lease6_expire () {
    ...
}
lease6_recover () {
    ...
}
leases6_committed () {
    ...
}
lease6_release () {
    ...
}
lease6_decline () {
    ...
}
addr6_register () {
    ...
}
case "$1" in
    "lease4_renew")
        lease4_renew
        ;;
    "lease4_expire")
        lease4_expire
        ;;
    "lease4_recover")
        lease4_recover
        ;;
    "leases4_committed")
        leases4_committed
        ;;
    "lease4_release")
        lease4_release
        ;;
    "lease4_decline")
        lease4_decline
        ;;
    "lease6_renew")
        lease6_renew
        ;;
    "lease6_rebind")
        lease6_rebind
        ;;
    "lease6_expire")
        lease6_expire
        ;;
    "lease6_recover")
        lease6_recover
        ;;
    "leases6_committed")
        leases6_committed
        ;;
    "lease6_release")
        lease6_release
        ;;
    "lease6_decline")
        lease6_decline
        ;;
    "addr6_register")
        addr6_register
        ;;
    *)
        unknown_handle "${@}"
        ;;
esac

پارامترهای موجود برای هر نقطه قلاب در زیر ارائه شده است.

DHCPv4:

lease4_renew

QUERY4_TYPE
QUERY4_TXID
QUERY4_LOCAL_ADDR
QUERY4_LOCAL_PORT
QUERY4_REMOTE_ADDR
QUERY4_REMOTE_PORT
QUERY4_IFACE_INDEX
QUERY4_IFACE_NAME
QUERY4_HOPS
QUERY4_SECS
QUERY4_FLAGS
QUERY4_CIADDR
QUERY4_SIADDR
QUERY4_YIADDR
QUERY4_GIADDR
QUERY4_RELAYED
QUERY4_HWADDR
QUERY4_HWADDR_TYPE
QUERY4_LOCAL_HWADDR
QUERY4_LOCAL_HWADDR_TYPE
QUERY4_REMOTE_HWADDR
QUERY4_REMOTE_HWADDR_TYPE
QUERY4_OPTION_82
QUERY4_OPTION_82_SUB_OPTION_1
QUERY4_OPTION_82_SUB_OPTION_2
SUBNET4_ID
SUBNET4_NAME
SUBNET4_PREFIX
SUBNET4_PREFIX_LEN
PKT4_CLIENT_ID
PKT4_HWADDR
PKT4_HWADDR_TYPE
LEASE4_ADDRESS
LEASE4_CLTT
LEASE4_HOSTNAME
LEASE4_HWADDR
LEASE4_HWADDR_TYPE
LEASE4_STATE
LEASE4_SUBNET_ID
LEASE4_VALID_LIFETIME
LEASE4_CLIENT_ID

lease4_expire

LEASE4_ADDRESS
LEASE4_CLTT
LEASE4_HOSTNAME
LEASE4_HWADDR
LEASE4_HWADDR_TYPE
LEASE4_STATE
LEASE4_SUBNET_ID
LEASE4_VALID_LIFETIME
LEASE4_CLIENT_ID
REMOVE_LEASE

lease4_recover

LEASE4_ADDRESS
LEASE4_CLTT
LEASE4_HOSTNAME
LEASE4_HWADDR
LEASE4_HWADDR_TYPE
LEASE4_STATE
LEASE4_SUBNET_ID
LEASE4_VALID_LIFETIME
LEASE4_CLIENT_ID

leases4_committed

QUERY4_TYPE
QUERY4_TXID
QUERY4_LOCAL_ADDR
QUERY4_LOCAL_PORT
QUERY4_REMOTE_ADDR
QUERY4_REMOTE_PORT
QUERY4_IFACE_INDEX
QUERY4_IFACE_NAME
QUERY4_HOPS
QUERY4_SECS
QUERY4_FLAGS
QUERY4_CIADDR
QUERY4_SIADDR
QUERY4_YIADDR
QUERY4_GIADDR
QUERY4_RELAYED
QUERY4_HWADDR
QUERY4_HWADDR_TYPE
QUERY4_LOCAL_HWADDR
QUERY4_LOCAL_HWADDR_TYPE
QUERY4_REMOTE_HWADDR
QUERY4_REMOTE_HWADDR_TYPE
QUERY4_OPTION_82
QUERY4_OPTION_82_SUB_OPTION_1
QUERY4_OPTION_82_SUB_OPTION_2
LEASES4_SIZE
DELETED_LEASES4_SIZE

اگر LEASES4_SIZE یا DELETED_LEASES4_SIZE غیر صفر باشد، آنگاه هر اجاره (lease) دارای شناسه یکتای خود خواهد بود، همان‌طور که در زیر نشان داده شده است. اولین نمایه از ۰ آغاز می‌شود.

LEASES4_AT0_ADDRESS
LEASES4_AT0_CLTT
LEASES4_AT0_HOSTNAME
LEASES4_AT0_HWADDR
LEASES4_AT0_HWADDR_TYPE
LEASES4_AT0_STATE
LEASES4_AT0_SUBNET_ID
LEASES4_AT0_VALID_LIFETIME
LEASES4_AT0_CLIENT_ID
DELETED_LEASES4_AT0_ADDRESS
DELETED_LEASES4_AT0_CLTT
DELETED_LEASES4_AT0_HOSTNAME
DELETED_LEASES4_AT0_HWADDR
DELETED_LEASES4_AT0_HWADDR_TYPE
DELETED_LEASES4_AT0_STATE
DELETED_LEASES4_AT0_SUBNET_ID
DELETED_LEASES4_AT0_VALID_LIFETIME
DELETED_LEASES4_AT0_CLIENT_ID

lease4_release

QUERY4_TYPE
QUERY4_TXID
QUERY4_LOCAL_ADDR
QUERY4_LOCAL_PORT
QUERY4_REMOTE_ADDR
QUERY4_REMOTE_PORT
QUERY4_IFACE_INDEX
QUERY4_IFACE_NAME
QUERY4_HOPS
QUERY4_SECS
QUERY4_FLAGS
QUERY4_CIADDR
QUERY4_SIADDR
QUERY4_YIADDR
QUERY4_GIADDR
QUERY4_RELAYED
QUERY4_HWADDR
QUERY4_HWADDR_TYPE
QUERY4_LOCAL_HWADDR
QUERY4_LOCAL_HWADDR_TYPE
QUERY4_REMOTE_HWADDR
QUERY4_REMOTE_HWADDR_TYPE
QUERY4_OPTION_82
QUERY4_OPTION_82_SUB_OPTION_1
QUERY4_OPTION_82_SUB_OPTION_2
LEASE4_ADDRESS
LEASE4_CLTT
LEASE4_HOSTNAME
LEASE4_HWADDR
LEASE4_HWADDR_TYPE
LEASE4_STATE
LEASE4_SUBNET_ID
LEASE4_VALID_LIFETIME
LEASE4_CLIENT_ID

lease4_decline

QUERY4_TYPE
QUERY4_TXID
QUERY4_LOCAL_ADDR
QUERY4_LOCAL_PORT
QUERY4_REMOTE_ADDR
QUERY4_REMOTE_PORT
QUERY4_IFACE_INDEX
QUERY4_IFACE_NAME
QUERY4_HOPS
QUERY4_SECS
QUERY4_FLAGS
QUERY4_CIADDR
QUERY4_SIADDR
QUERY4_YIADDR
QUERY4_GIADDR
QUERY4_RELAYED
QUERY4_HWADDR
QUERY4_HWADDR_TYPE
QUERY4_LOCAL_HWADDR
QUERY4_LOCAL_HWADDR_TYPE
QUERY4_REMOTE_HWADDR
QUERY4_REMOTE_HWADDR_TYPE
QUERY4_OPTION_82
QUERY4_OPTION_82_SUB_OPTION_1
QUERY4_OPTION_82_SUB_OPTION_2
LEASE4_ADDRESS
LEASE4_CLTT
LEASE4_HOSTNAME
LEASE4_HWADDR
LEASE4_HWADDR_TYPE
LEASE4_STATE
LEASE4_SUBNET_ID
LEASE4_VALID_LIFETIME
LEASE4_CLIENT_ID

DHCPv6:

lease6_renew

QUERY6_TYPE
QUERY6_TXID
QUERY6_LOCAL_ADDR
QUERY6_LOCAL_PORT
QUERY6_REMOTE_ADDR
QUERY6_REMOTE_PORT
QUERY6_IFACE_INDEX
QUERY6_IFACE_NAME
QUERY6_REMOTE_HWADDR
QUERY6_REMOTE_HWADDR_TYPE
QUERY6_PROTO
QUERY6_CLIENT_ID
LEASE6_ADDRESS
LEASE6_CLTT
LEASE6_HOSTNAME
LEASE6_HWADDR
LEASE6_HWADDR_TYPE
LEASE6_STATE
LEASE6_SUBNET_ID
LEASE6_VALID_LIFETIME
LEASE6_DUID
LEASE6_IAID
LEASE6_PREFERRED_LIFETIME
LEASE6_PREFIX_LEN
LEASE6_TYPE
PKT6_IA_IAID
PKT6_IA_IA_TYPE
PKT6_IA_IA_T1
PKT6_IA_IA_T2

lease6_rebind

QUERY6_TYPE
QUERY6_TXID
QUERY6_LOCAL_ADDR
QUERY6_LOCAL_PORT
QUERY6_REMOTE_ADDR
QUERY6_REMOTE_PORT
QUERY6_IFACE_INDEX
QUERY6_IFACE_NAME
QUERY6_REMOTE_HWADDR
QUERY6_REMOTE_HWADDR_TYPE
QUERY6_PROTO
QUERY6_CLIENT_ID
LEASE6_ADDRESS
LEASE6_CLTT
LEASE6_HOSTNAME
LEASE6_HWADDR
LEASE6_HWADDR_TYPE
LEASE6_STATE
LEASE6_SUBNET_ID
LEASE6_VALID_LIFETIME
LEASE6_DUID
LEASE6_IAID
LEASE6_PREFERRED_LIFETIME
LEASE6_PREFIX_LEN
LEASE6_TYPE
PKT6_IA_IAID
PKT6_IA_IA_TYPE
PKT6_IA_IA_T1
PKT6_IA_IA_T2

lease6_expire

LEASE6_ADDRESS
LEASE6_CLTT
LEASE6_HOSTNAME
LEASE6_HWADDR
LEASE6_HWADDR_TYPE
LEASE6_STATE
LEASE6_SUBNET_ID
LEASE6_VALID_LIFETIME
LEASE6_DUID
LEASE6_IAID
LEASE6_PREFERRED_LIFETIME
LEASE6_PREFIX_LEN
LEASE6_TYPE
REMOVE_LEASE

lease6_recover

LEASE6_ADDRESS
LEASE6_CLTT
LEASE6_HOSTNAME
LEASE6_HWADDR
LEASE6_HWADDR_TYPE
LEASE6_STATE
LEASE6_SUBNET_ID
LEASE6_VALID_LIFETIME
LEASE6_DUID
LEASE6_IAID
LEASE6_PREFERRED_LIFETIME
LEASE6_PREFIX_LEN
LEASE6_TYPE

leases6_committed

QUERY6_TYPE
QUERY6_TXID
QUERY6_LOCAL_ADDR
QUERY6_LOCAL_PORT
QUERY6_REMOTE_ADDR
QUERY6_REMOTE_PORT
QUERY6_IFACE_INDEX
QUERY6_IFACE_NAME
QUERY6_REMOTE_HWADDR
QUERY6_REMOTE_HWADDR_TYPE
QUERY6_PROTO
QUERY6_CLIENT_ID
LEASES6_SIZE
DELETED_LEASES6_SIZE

اگر LEASES6_SIZE یا DELETED_LEASES6_SIZE غیر صفر باشد، آنگاه هر اجاره دارای شناسه یکتای خود خواهد بود، همان‌طور که در زیر نشان داده شده است. اولین نمایه از ۰ آغاز می‌شود.

LEASES6_AT0_ADDRESS
LEASES6_AT0_CLTT
LEASES6_AT0_HOSTNAME
LEASES6_AT0_HWADDR
LEASES6_AT0_HWADDR_TYPE
LEASES6_AT0_STATE
LEASES6_AT0_SUBNET_ID
LEASES6_AT0_VALID_LIFETIME
LEASES6_AT0_DUID
LEASES6_AT0_IAID
LEASES6_AT0_PREFERRED_LIFETIME
LEASES6_AT0_PREFIX_LEN
LEASES6_AT0_TYPE
DELETED_LEASES6_AT0_ADDRESS
DELETED_LEASES6_AT0_CLTT
DELETED_LEASES6_AT0_HOSTNAME
DELETED_LEASES6_AT0_HWADDR
DELETED_LEASES6_AT0_HWADDR_TYPE
DELETED_LEASES6_AT0_STATE
DELETED_LEASES6_AT0_SUBNET_ID
DELETED_LEASES6_AT0_VALID_LIFETIME
DELETED_LEASES6_AT0_DUID
DELETED_LEASES6_AT0_IAID
DELETED_LEASES6_AT0_PREFERRED_LIFETIME
DELETED_LEASES6_AT0_PREFIX_LEN
DELETED_LEASES6_AT0_TYPE

lease6_release

QUERY6_TYPE
QUERY6_TXID
QUERY6_LOCAL_ADDR
QUERY6_LOCAL_PORT
QUERY6_REMOTE_ADDR
QUERY6_REMOTE_PORT
QUERY6_IFACE_INDEX
QUERY6_IFACE_NAME
QUERY6_REMOTE_HWADDR
QUERY6_REMOTE_HWADDR_TYPE
QUERY6_PROTO
QUERY6_CLIENT_ID
LEASE6_ADDRESS
LEASE6_CLTT
LEASE6_HOSTNAME
LEASE6_HWADDR
LEASE6_HWADDR_TYPE
LEASE6_STATE
LEASE6_SUBNET_ID
LEASE6_VALID_LIFETIME
LEASE6_DUID
LEASE6_IAID
LEASE6_PREFERRED_LIFETIME
LEASE6_PREFIX_LEN
LEASE6_TYPE

lease6_decline

QUERY6_TYPE
QUERY6_TXID
QUERY6_LOCAL_ADDR
QUERY6_LOCAL_PORT
QUERY6_REMOTE_ADDR
QUERY6_REMOTE_PORT
QUERY6_IFACE_INDEX
QUERY6_IFACE_NAME
QUERY6_REMOTE_HWADDR
QUERY6_REMOTE_HWADDR_TYPE
QUERY6_PROTO
QUERY6_CLIENT_ID
LEASE6_ADDRESS
LEASE6_CLTT
LEASE6_HOSTNAME
LEASE6_HWADDR
LEASE6_HWADDR_TYPE
LEASE6_STATE
LEASE6_SUBNET_ID
LEASE6_VALID_LIFETIME
LEASE6_DUID
LEASE6_IAID
LEASE6_PREFERRED_LIFETIME
LEASE6_PREFIX_LEN
LEASE6_TYPE

addr6_register

QUERY6_TYPE
QUERY6_TXID
QUERY6_LOCAL_ADDR
QUERY6_LOCAL_PORT
QUERY6_REMOTE_ADDR
QUERY6_REMOTE_PORT
QUERY6_IFACE_INDEX
QUERY6_IFACE_NAME
QUERY6_REMOTE_HWADDR
QUERY6_REMOTE_HWADDR_TYPE
QUERY6_PROTO
QUERY6_CLIENT_ID
ADDRESS6
OLD_LEASE6_ADDRESS
OLD_LEASE6_CLTT
OLD_LEASE6_HOSTNAME
OLD_LEASE6_HWADDR
OLD_LEASE6_HWADDR_TYPE
OLD_LEASE6_STATE
OLD_LEASE6_SUBNET_ID
OLD_LEASE6_VALID_LIFETIME
OLD_LEASE6_DUID
OLD_LEASE6_IAID
OLD_LEASE6_PREFERRED_LIFETIME
OLD_LEASE6_PREFIX_LEN
OLD_LEASE6_TYPE
NEW_LEASE6_ADDRESS
NEW_LEASE6_CLTT
NEW_LEASE6_HOSTNAME
NEW_LEASE6_HWADDR
NEW_LEASE6_HWADDR_TYPE
NEW_LEASE6_STATE
NEW_LEASE6_SUBNET_ID
NEW_LEASE6_VALID_LIFETIME
NEW_LEASE6_DUID
NEW_LEASE6_IAID
NEW_LEASE6_PREFERRED_LIFETIME
NEW_LEASE6_PREFIX_LEN
NEW_LEASE6_TYPE

متغیر OLD_LEASE6 همیشه وجود ندارد.

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

leases4_committed() {
    for i in $(seq 0 $((LEASES4_SIZE-1))); do
        LEASE4_ADDRESS=$(eval "echo \$LEASES4_AT${i}_ADDRESS")
        ...
    done
    for i in $(seq 0 $((DELETED_LEASES4_SIZE-1))); do
        DELETED_LEASE4_ADDRESS=$(eval "echo \$DELETED_LEASES4_AT${i}_ADDRESS")
        ...
    done
    exit 0
}

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

leases6_committed() {
    for i in $(seq 0 $((LEASES6_SIZE-1))); do
        LEASE6_ADDRESS=$(eval "echo \$LEASES6_AT${i}_ADDRESS")
        ...
    done
    for i in $(seq 0 $((DELETED_LEASES6_SIZE-1))); do
        DELETED_LEASE6_ADDRESS=$(eval "echo \$DELETED_LEASES6_AT${i}_ADDRESS")
        ...
    done
    exit 0
}

این کتابخانه دستورات بیشتری را برای واکشی آمار اجاره‌ها (leases) از کارسازهای Kea DHCP فراهم می‌کند. این دستورات برای برطرف کردن مشکلی در به‌دست آوردن آمار دقیق اجاره‌ها در استقرارهایی با چندین کارساز Kea که از یک پس‌بند (backend) اجاره مشترک استفاده می‌کنند، اضافه شده‌اند. آمار درون حافظه‌ای (in-memory) نگهداری‌شده توسط هر یک از کارسازها تنها تغییرات اجاره انجام‌شده توسط همان کارساز را ردیابی می‌کند؛ بنابراین، در استقراری با چندین کارساز (برای مثال دو کارساز kea-dhcp6 <#std-iscman-kea-dhcp6> که از یک پایگاه‌داده PostgreSQL یکسان برای ذخیره‌سازی اجاره‌ها استفاده می‌کنند)، این آمار ناقص هستند. پس‌بندهای MySQL و PostgreSQL در Kea تغییرات تخصیص اجاره را به محض وقوع از طریق تریگرهای پایگاه‌داده ردیابی می‌کنند. علاوه بر این، تمام پس‌بندهای اجاره برای پشتیبانی از واکشی آمار اجاره‌ها برای یک زیرشبکه، بازه‌ای از زیرشبکه‌ها یا تمام زیرشبکه‌ها توسعه یافته‌اند. در نهایت، این کتابخانه دستوراتی را برای واکشی این آمار ارائه می‌دهد.

نکته:

کتابخانه libdhcp_stat_cmds.so بخشی از کد منبع‌باز است و برای تمام کاربران Kea در دسترس است.

نکته:

این کتابخانه تنها می‌تواند توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

دستورات ارائه‌شده توسط این کتابخانه عبارتند از:

  • stat-lease4-get - آمار اجاره‌های DHCPv4 را واکشی می‌کند.
  • stat-lease6-get - آمار اجاره‌های DHCPv6 را واکشی می‌کند.

کتابخانه دستورات آماری (Statistics Commands) بخشی از کد منبع‌باز است و برای تمام کاربران Kea در دسترس است.

تمام دستورات از ساختار JSON استفاده می‌کنند و می‌توانند مستقیماً از طریق کانال کنترل (بخش Management API <#ctrl-channel> را ببینید) به کارسازها ارسال شوند.

این کتابخانه همانند سایر کتابخانه‌ها بارگذاری می‌شود و در حال حاضر هیچ پارامتری ندارد:

"Dhcp6": {
    "hooks-libraries": [
        {
            "library": "libdhcp_stat_cmds.so"
        },
        ...
    ]
}

در استقراری با چندین کارساز Kea DHCP که یک فضای ذخیره‌سازی مشترک اجاره را به اشتراک می‌گذارند، این کتابخانه قلاب (hook library) می‌تواند توسط یک یا تمام کارسازها بارگذاری شود. با این حال، پاسخ یک کارساز به دستور stat-lease4-get / stat-lease6-get تنها شامل داده‌های مربوط به زیرشبکه‌های شناخته‌شده برای آن کارساز خواهد بود. به عبارت دیگر، اگر زیرشبکه‌ای در پیکربندی کارساز وجود نداشته باشد، Kea آماری برای آن واکشی نخواهد کرد.

دستورات stat-lease4-get و stat-lease6-get آمار اجاره را برای بازه‌ای از زیرشبکه‌های شناخته‌شده واکشی می‌کنند. بازه زیرشبکه‌ها از طریق استفاده از پارامترهای اختیاری ورودی دستور مشخص می‌شود:

  • subnet-id - شناسه زیرشبکه‌ای که آمار اجاره برای آن باید واکشی شود؛ برای دریافت آمار یک زیرشبکه تکی به کار می‌رود. اگر زیرشبکه وجود نداشته باشد، کد نتیجه دستور ۳ خواهد بود (یعنی CONTROL_RESULT_EMPTY).
  • subnet-range - جفتی از شناسه‌های زیرشبکه که بازه فراگیری (شامل هر دو سر بازه) از زیرشبکه‌ها را که آمار برای آن‌ها باید واکشی شود توصیف می‌کند. این بازه ممکن است شامل یک یا چند شناسه باشد که با هیچ زیرشبکه‌ای مطابقت ندارند؛ در این حالت، دستور تنها آمار اجاره را برای آن‌هایی که وجود دارند در خروجی می‌آورد. با این حال، اگر بازه شامل هیچ زیرشبکه شناخته‌شده‌ای نباشد، کد نتیجه دستور ۳ خواهد بود (یعنی CONTROL_RESULT_EMPTY).
  • first-subnet-id - شناسه نخستین زیرشبکه در بازه.
  • last-subnet-id - شناسه آخرین زیرشبکه در بازه.

استفاده از subnet-id و subnet-range مانعة‌الجمع است (نمی‌توان هم‌زمان از هر دو استفاده کرد). اگر هیچ پارامتری داده نشود، نتیجه حاوی داده‌های تمام زیرشبکه‌های شناخته‌شده خواهد بود. توجه داشته باشید که در پیکربندی‌هایی با زیرشبکه‌های متعدد، این امر می‌تواند منجر به پاسخی حجیم شود.

دستور زیر آمار اجاره را برای تمام زیرشبکه‌های شناخته‌شده از یک کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> واکشی می‌کند:

{
  "command": "stat-lease4-get"
}

دستور زیر آمار اجاره را برای زیرشبکه با شناسه ۱۰ از یک کارساز kea-dhcp6 <#std-iscman-kea-dhcp6> واکشی می‌کند:

{
  "command": "stat-lease6-get",
  "arguments": {
    "subnet-id" : 10
  }
}

دستور زیر آمار اجاره را برای تمام زیرشبکه‌های با شناسه‌ای در بازه ۱۰ تا ۵۰ از یک کارساز kea-dhcp4 <#std-iscman-kea-dhcp4> واکشی می‌کند:

{
  "command": "stat-lease4-get",
  "arguments": {
    "subnet-range": {
      "first-subnet-id": 10,
      "last-subnet-id": 50
    }
  }
}

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

•
result - یک مقدار عددی که نتیجه دستور را مشخص می‌کند به طوری که:
  • 0 - دستور موفقیت‌آمیز بود؛
  • 1 - خطایی رخ داد، و توضیح آن در عنصر "text" است؛ یا
  • 2 - واکشی هیچ داده منطبقی نیافت.
  • text - توضیحی درباره نتیجه دستور. هنگامی که دستور با موفقیت انجام شود، شامل نام دستور به همراه تعداد سطرهای بازگردانده‌شده است.
  • arguments - یک نگاشت حاوی داده‌های بازگردانده‌شده توسط دستور به عنوان عنصر "result-set"، که از الگوی پاسخ‌های دستورات SQL پیروی می‌کند:
•
columns - فهرستی از برچسب‌های متنی ستون‌ها.

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

  • subnet-id - شناسه زیرشبکه.
  • total-addresses - تعداد کل نشانی‌های موجود برای مدیریت DHCPv4 در زیرشبکه. به عبارت دیگر، این شمارش تمام نشانی‌ها در همه استخرهای (pools) پیکربندی‌شده در زیرشبکه است.
  • cumulative-assigned-addresses - تعداد تجمعی نشانی‌هایی در زیرشبکه که از زمان شروع به کار کارساز توسط آن به یک کلاینت تخصیص داده شده‌اند.
  • assigned-addresses - تعداد نشانی‌هایی در زیرشبکه که در حال حاضر به یک کلاینت تخصیص داده شده‌اند.
  • declined-addresses - تعداد نشانی‌هایی در زیرشبکه که در حال حاضر رد شده‌اند (declined) و بنابراین برای تخصیص در دسترس نیستند.

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

  • subnet-id - شناسه زیرشبکه..IP • 2 total-nas - تعداد آدرس‌های NA موجود برای مدیریت DHCPv6 در زیرشبکه. به عبارت دیگر، این تعداد کل آدرس‌های NA در تمام استخرهای NA پیکربندی‌شده در زیرشبکه است.
  • cumulative-assigned-nas - تعداد تجمعی آدرس‌های NA در زیرشبکه که از زمان راه‌اندازی سرور به یک کلاینت اختصاص داده شده‌اند.
  • assigned-nas - تعداد آدرس‌های NA در زیرشبکه که در حال حاضر به یک کلاینت اختصاص داده شده‌اند.
  • declined-addresses - تعداد آدرس‌های NA که در حال حاضر رد شده‌اند (declined) و در نتیجه برای تخصیص در دسترس نیستند.
  • total-pds - تعداد کل پیشوندهای PD موجود برای مدیریت DHCPv6 در زیرشبکه. به عبارت دیگر، این تعداد کل پیشوندها در تمام استخرهای پیشوند پیکربندی‌شده در زیرشبکه است.
  • cumulative-assigned-pds - تعداد تجمعی پیشوندهای PD در زیرشبکه که از زمان راه‌اندازی سرور به یک کلاینت اختصاص یافته‌اند.
  • assigned-pds - تعداد پیشوندهای PD در زیرشبکه که در حال حاضر به یک کلاینت اختصاص داده شده‌اند.
  • rows - فهرستی از سطرها، یک سطر به ازای هر شناسه زیرشبکه (subnet ID). هر سطر شامل مقادیر داده‌ای متناظر با ستون‌های فهرست‌شده در "columns" و به همان ترتیب برای یک زیرشبکه مشخص است.
  • timestamp - تاریخ و زمان متنیِ واکشی داده‌ها، بیان‌شده بر اساس GMT.

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

{
  "result": 0,
  "text": "stat-lease4-get: 2 rows found",
  "arguments": {
    "result-set": {
      "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ],
      "rows": [
        [ 10, 256, 300, 111, 0 ],
        [ 20, 4098, 2034, 2034, 4 ]
      ],
      "timestamp": "2018-05-04 15:03:37.000000"
    }
  }
}

پاسخ به یک دستور DHCPv6 با این فرض که زیرشبکه 10 هیچ استخر پیشوندی ندارد، زیرشبکه 20 هیچ استخر NA ندارد، و زیرشبکه 30 دارای هر دو استخر NA و PD است، ممکن است به شکل زیر باشد:

{
  "result": 0,
  "text": "stat-lease6-get: 2 rows found",
  "arguments": {
    "result-set": {
      "columns": [ "subnet-id", "total-nas", "cumulative-assigned-nas", "assigned-nas", "declined-addresses", "total-pds", "cumulative-assigned-pds", "assigned-pds" ],
      "rows": [
        [ 10, 4096, 5000, 2400, 3, 0, 0, 0],
        [ 20, 0, 0, 0, 0, 1048, 300, 233 ],
        [ 30, 256, 60, 60, 0, 1048, 15, 15 ]
      ],
      "timestamp": "2018-05-04 15:03:37.000000"
    }
  }
}

این کتابخانه دستورهایی را برای پرس‌وجو و دستکاری پیکربندی‌های زیرشبکه و شبکه اشتراکی (shared network) در Kea ارائه می‌دهد. این دستورها می‌توانند در استقرارهایی با تعداد زیادی زیرشبکه که توسط سرورهای DHCP مدیریت می‌شوند، هنگامی که آن زیرشبکه‌ها مکرراً به‌روزرسانی می‌شوند، بسیار مفید باشند. این دستورها رویکردی سبک را برای دستکاری زیرشبکه‌ها بدون نیاز به پیکربندی مجددِ کامل سرور، و بدون تأثیر بر پیکربندی‌های موجود سرور فراهم می‌کنند. همچنین قابلیت مدیریت شبکه‌های اشتراکی (فهرست‌کردن، بازیابی جزئیات، افزودن موارد جدید، حذف موارد موجود، و افزودن زیرشبکه‌ها به شبکه‌های اشتراکی و حذف آن‌ها از شبکه اشتراکی) نیز ارائه شده است.

نکته:

libdhcp_subnet_cmds.so بخشی از کد متن‌باز است و برای همه کاربران Kea در دسترس است. این کتابخانه پیش‌تر فقط برای مشتریان ISC با قرارداد پشتیبانی پولی در دسترس بود.

نکته:

این کتابخانه فقط می‌تواند توسط فرایند kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

در حال حاضر دستورهای زیر پشتیبانی می‌شوند:

  • subnet4-list / subnet6-list - تمام زیرشبکه‌های پیکربندی‌شده را فهرست می‌کند.
  • subnet4-get / subnet6-get - اطلاعات تفصیلی مربوط به یک زیرشبکه مشخص را بازیابی می‌کند.
  • subnet4-add / subnet6-add - یک زیرشبکه جدید به پیکربندی سرور اضافه می‌کند.
  • subnet4-update / subnet6-update - یک زیرشبکه مشخص را در پیکربندی سرور به‌روزرسانی (جایگزین) می‌کند.
  • subnet4-del / subnet6-del - یک زیرشبکه را از پیکربندی سرور حذف می‌کند.
  • subnet4-delta-add / subnet6-delta-add - بخش‌هایی از یک زیرشبکه مشخص را در پیکربندی سرور به‌روزرسانی (جایگزین) می‌کند.
  • subnet4-delta-del / subnet6-delta-del - بخش‌هایی از یک زیرشبکه مشخص را در پیکربندی سرور حذف می‌کند.
  • network4-list / network6-list - تمام شبکه‌های اشتراکی پیکربندی‌شده را فهرست می‌کند.
  • network4-get / network6-get - اطلاعات تفصیلی مربوط به یک شبکه اشتراکی مشخص را بازیابی می‌کند.
  • network4-add / network6-add - یک شبکه اشتراکی جدید به پیکربندی سرور اضافه می‌کند.
  • network4-del / network6-del - یک شبکه اشتراکی را از پیکربندی سرور حذف می‌کند.
  • network4-subnet-add / network6-subnet-add - یک زیرشبکه موجود را به یک شبکه اشتراکی موجود اضافه می‌کند.
  • network4-subnet-del / network6-subnet-del - یک زیرشبکه را از یک شبکه اشتراکی موجود حذف کرده و آن را به یک زیرشبکه عادی تنزل می‌دهد.

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

    این دستور ساختار ساده‌ای دارد:

{
    "command": "subnet4-list"
}

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

{
    "result": 0,
    "text": "2 IPv4 subnets found",
    "arguments": {
    "subnets": [
        {
            "id": 10,
            "shared-network-name": "net1",
            "subnet": "10.0.0.0/8"
        },
        {
            "id": 100,
            "shared-network-name": null,
            "subnet": "192.0.2.0/24"
        }
    ]
    }
}

اگر هیچ زیرشبکه IPv4ای پیدا نشود، یک کد خطا به همراه شرح خطا بازگردانده می‌شود.

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

این دستور ساختار ساده‌ای دارد:

{
    "command": "subnet6-list"
}

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

{
    "result": 0,
    "text": "2 IPv6 subnets found",
    "arguments": {
    "subnets": [
        {
            "id": 11,
            "shared-network-name": null,
            "subnet": "2001:db8:1::/64"
        },
        {
            "id": 233,
            "shared-network-name": "some-net",
            "subnet": "3000::/16"
        }
    ]
    }
}

اگر هیچ زیرشبکه IPv6ای پیدا نشود، یک کد خطا به همراه شرح خطا بازگردانده می‌شود.

این دستور برای بازیابی اطلاعات دقیق درباره زیرشبکه مشخص‌شده به کار می‌رود. این دستور معمولاً پس از subnet4-list استفاده می‌شود، که برای کشف زیرشبکه‌های موجود به همراه شناسه‌ها و پیشوندهای زیرشبکه مربوطه‌شان به کار می‌رود. سپس از هر کدام از این پارامترها می‌توان در subnet4-get برای دریافت اطلاعات زیرشبکه استفاده کرد:

{
    "command": "subnet4-get",
    "arguments": {
        "id": 10
    }
}

یا

{
    "command": "subnet4-get",
    "arguments": {
        "subnet": "10.0.0.0/8"
    }
}

اگر زیرشبکه وجود داشته باشد، پاسخ مشابه زیر خواهد بود:

{
    "result": 0,
    "text": "Info about IPv4 subnet 10.0.0.0/8 (id 10) returned",
    "arguments": {
        "subnets": [
            {
                "subnet": "10.0.0.0/8",
                "id": 1,
                "option-data": [
                    {
                        ...
                    },
                    ...
                ],
                ...
            }
        ]
    }
}

این دستور برای بازیابی اطلاعات تفصیلی درباره زیرشبکه مشخص‌شده به کار می‌رود. این دستور معمولاً پس از subnet6-list اجرا می‌شود که برای یافتن زیرشبکه‌های موجود به همراه شناسه‌ها و پیشوندهای زیرشبکه مربوطه‌شان استفاده می‌گردد. سپس می‌توان از هر یک از این پارامترها در subnet6-get برای دریافت اطلاعات زیرشبکه استفاده کرد:

{
    "command": "subnet6-get",
    "arguments": {
        "id": 11
    }
}

یا

{
    "command": "subnet6-get",
    "arguments": {
        "subnet": "2001:db8:1::/64"
    }
}

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

{
    "result": 0,
    "text": "Info about IPv6 subnet 2001:db8:1::/64 (id 11) returned",
    "arguments": {
        "subnets": [
            {
                "subnet": "2001:db8:1::/64",
                "id": 1,
                "option-data": [
                    {
                        ...
                    },
                    ...
                ],
                ...
            }
        ]
    }
}

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

اطلاعات زیرشبکه درون این دستور دارای همان ساختار اطلاعات زیرشبکه در فایل پیکربندی سرور است، با این استثنا که رزروهای ایستای میزبان را نمی‌توان درون subnet4-add مشخص کرد. برای افزودن، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

{
    "command": "subnet4-add",
    "arguments": {
        "subnet4": [ {
            "id": 123,
            "subnet": "10.20.30.0/24",
            ...
        } ]
    }
}

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

{
    "result": 0,
    "text": "IPv4 subnet added",
    "arguments": {
        "subnet4": [
            {
                "id": 123,
                "subnet": "10.20.30.0/24"
            }
        ]
    }
}

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

اطلاعات زیرشبکه درون این دستور دارای همان ساختار اطلاعات زیرشبکه در فایل پیکربندی سرور است، با این استثنا که رزروهای ایستای میزبان را نمی‌توان درون subnet6-add مشخص کرد. برای افزودن، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

{
    "command": "subnet6-add",
    "arguments": {
        "subnet6": [ {
            "id": 234,
            "subnet": "2001:db8:1::/64",
            ...
        } ]
    }
}

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

{
    "result": 0,
    "text": "IPv6 subnet added",
    "arguments": {
        "subnet6": [
            {
                "id": 234,
                "subnet": "2001:db8:1::/64"
            }
        ]
    }
}

از Kea 2.6.0 به بعد، Kea دیگر شناسه‌های زیرشبکه را به‌طور خودکار تولید نمی‌کند؛ آن‌ها باید برای subnet4-add و subnet6-add مشخص شوند. در صورت عدم تعیین، Kea تلاش می‌کند مقدار بعدی subnet-id را اختصاص دهد. این تولیدکننده خودکار مقادیر شناسه ساده است؛ مقدار اختصاص‌یافته خودکار قبلی را به علاوه ۱ برمی‌گرداند. این سازوکار به خوبی کار می‌کند، مگر اینکه یک زیرشبکه به‌صورت دستی با مقداری بزرگ‌تر از مقادیر قبلاً استفاده‌شده ایجاد شود. برای مثال، اگر subnet4-add پنج بار فراخوانی شود، هر بار بدون شناسه، Kea شناسه‌های ۱، ۲، ۳، ۴ و ۵ را اختصاص خواهد داد و همه‌چیز به درستی کار خواهد کرد. با این حال، اگر subnet4-add پنج بار فراخوانی شود، در حالی که اولین زیرشبکه دارای subnet-id با مقدار ۳ باشد و باقی آن‌ها فاقد subnet-id باشند، عملیات با شکست مواجه خواهد شد. اولین دستور (با مقدار صریح) از subnet-id مقدار ۳ استفاده خواهد کرد؛ دومین دستور زیرشبکه‌ای با شناسه ۱ ایجاد می‌کند؛ سومی از مقدار ۲ استفاده خواهد کرد؛ و سرانجام مقدار subnet-id چهارمی به‌طور خودکار برابر با ۳ تولید خواهد شد. اما از آن‌جا که هم‌اکنون زیرشبکه‌ای با آن شناسه وجود دارد، فرآیند با شکست مواجه خواهد شد.

توصیه عمومی این است که یا هرگز از مقادیر صریح استفاده نکنید تا مقادیر تولید‌شده به‌طور خودکار همیشه کار کنند؛ یا همیشه از مقادیر صریح استفاده کنید تا از تولید خودکار هرگز استفاده نشود. این دو رویکرد تنها در صورتی می‌توانند با هم ترکیب شوند که مدیر سیستم از نحوه کارکرد تولید خودکار داخلی subnet-id در Kea آگاه باشد.

نکته:

شناسه‌های زیرشبکه باید بزرگ‌تر از صفر و کوچک‌تر از 4294967295 باشند.

این دستور برای به‌روزرسانی (بازنویسی) یک زیرشبکهٔ منفرد در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد. شناسهٔ زیرشبکه برای شناسایی زیرشبکه‌ای که باید جایگزین شود به‌کار می‌رود؛ این شناسه باید مشخص شده و در میان تمام زیرشبکه‌ها یکتا باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود.

اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای میزبان ایستا را نمی‌توان در subnet4-update مشخص کرد. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

{
    "command": "subnet4-update",
    "arguments": {
        "subnet4": [ {
            "id": 123,
            "subnet": "10.20.30.0/24",
            ...
        } ]
    }
}

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

{
    "result": 0,
    "text": "IPv4 subnet updated",
    "arguments": {
        "subnet4": [
            {
                "id": 123,
                "subnet": "10.20.30.0/24"
            }
        ]
    }
}

همانند سایر دستورهای به‌روزرسانی، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر زیرشبکهٔ IPv4 پیش‌تر منبعی به آن تخصیص یافته بود و دستور subnet4-update فاقد آن منبع باشد، آن منبع از پیکربندی سرور حذف خواهد شد. چنانچه به‌روزرسانی افزایشی زیرشبکه مد نظر باشد، از subnet4-delta-add استفاده کنید.

این دستور برای به‌روزرسانی (بازنویسی) یک زیرشبکهٔ منفرد در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد. شناسهٔ زیرشبکه برای شناسایی زیرشبکه‌ای که باید جایگزین شود به‌کار می‌رود؛ این شناسه باید مشخص شده و در میان تمام زیرشبکه‌ها یکتا باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود.

اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای میزبان ایستا را نمی‌توان در subnet6-update مشخص کرد. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

{
    "command": "subnet6-update",
    "arguments": {
        "subnet6": [ {
            "id": 234,
            "subnet": "2001:db8:1::/64",
            ...
        } ]
    }
}

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

{
    "result": 0,
    "text": "IPv6 subnet updated",
    "arguments": {
        "subnet6": [
            {
                "id": 234,
                "subnet": "2001:db8:1::/64"
            }
        ]
    }
}

همانند سایر دستورهای به‌روزرسانی، این دستور تمام محتویات مدخل را بازنویسی می‌کند. اگر زیرشبکهٔ IPv6 پیش‌تر منبعی به آن تخصیص یافته بود و دستور subnet6-update فاقد آن منبع باشد، آن منبع از پیکربندی سرور حذف خواهد شد. چنانچه به‌روزرسانی افزایشی زیرشبکه مد نظر باشد، از subnet6-delta-add استفاده کنید.

این دستور برای حذف یک زیرشبکه از پیکربندی سرور به‌کار می‌رود. این دستور اثری بر سایر زیرشبکه‌های پیکربندی‌شده ندارد، اما حذف یک زیرشبکه پیامدهای خاصی به همراه دارد.

در بیشتر موارد، سرور اجاره‌هایی (leases) را به کلاینت‌های متعلق به آن زیرشبکه تخصیص داده است. همچنین ممکن است سرور با رزروهای میزبان ایستایی پیکربندی شده باشد که به این زیرشبکه مرتبط هستند. پیاده‌سازی کنونی دستور subnet4-del نه اجاره‌ها و نه رزروهای میزبان مرتبط با زیرشبکه را حذف نمی‌کند. این امن‌ترین رویکرد است زیرا سرور ردیابی اجاره‌های تخصیص‌یافته به کلاینت‌های این زیرشبکه را از دست نمی‌دهد. با این حال، حذف زیرشبکه ممکن است همچنان باعث بروز خطاها و تداخل‌های پیکربندی شود. برای مثال: پس از حذف زیرشبکه، ممکن است مدیر سرور زیرشبکهٔ جدیدی را با همان شناسه‌ای که پیش‌تر برای زیرشبکهٔ حذف‌شده استفاده شده بود، به‌روزرسانی کند. این بدان معناست که اجاره‌های موجود و رزروهای ایستا با این زیرشبکهٔ جدید تداخل خواهند داشت؛ بنابراین، توصیه می‌کنیم که این دستور با احتیاط بسیار بالا استفاده شود.

این دستور همچنین می‌تواند برای حذف کامل یک زیرشبکهٔ IPv4 که بخشی از یک شبکهٔ مشترک (shared network) است استفاده شود. برای حذف صرف زیرشبکه از یک شبکهٔ مشترک و نگه‌داشتن پیکربندی آن زیرشبکه، در عوض از دستور network4-subnet-del استفاده کنید.

این دستور ساختار زیر را دارد:

{
    "command": "subnet4-del",
    "arguments": {
        "id": 123
    }
}

یک پاسخ موفقیت‌آمیز ممکن است به این شکل باشد:

{
    "result": 0,
    "text": "IPv4 subnet 192.0.2.0/24 (id 123) deleted",
    "arguments": {
        "subnets": [
            {
                "id": 123,
                "subnet": "192.0.2.0/24"
            }
        ]
    }
}

این دستور برای حذف یک زیرشبکه از پیکربندی سرور استفاده می‌شود. این دستور هیچ تأثیری بر سایر زیرشبکه‌های پیکربندی‌شده ندارد، اما حذف یک زیرشبکه پیامدهای خاصی به همراه دارد.

در بیشتر موارد، سرور اجاره‌هایی را به کلاینت‌های متعلق به این زیرشبکه اختصاص داده است. سرور همچنین ممکن است با رزروهای ایستای میزبان که با این زیرشبکه مرتبط هستند، پیکربندی شده باشد. پیاده‌سازی فعلی دستور subnet6-del نه اجاره‌ها و نه رزروهای میزبان مرتبط با یک زیرشبکه را حذف نمی‌کند. این امن‌ترین رویکرد است چرا که سرور ردیابی اجاره‌های اختصاص‌یافته به کلاینت‌های این زیرشبکه را از دست نمی‌دهد. با این حال، حذف زیرشبکه ممکن است همچنان باعث بروز خطاها و تداخل‌های پیکربندی شود. برای مثال: پس از حذف زیرشبکه، مدیر سرور ممکن است یک زیرشبکه جدید با شناسه‌ای که پیش‌تر برای زیرشبکه حذف‌شده استفاده می‌شد، اضافه کند. این بدان معناست که اجاره‌های موجود و رزروهای ایستا با این زیرشبکه جدید در تداخل خواهند بود. بنابراین، توصیه می‌کنیم که این دستور با احتیاط بسیار زیاد استفاده شود.

این دستور همچنین می‌تواند برای حذف کامل یک زیرشبکه IPv6 که بخشی از یک شبکه مشترک است استفاده شود. برای صرفاً حذف زیرشبکه از یک شبکه مشترک و حفظ پیکربندی زیرشبکه، به جای آن از دستور network6-subnet-del استفاده کنید.

این دستور ساختار زیر را دارد:

{
    "command": "subnet6-del",
    "arguments": {
        "id": 234
    }
}

یک پاسخ موفق ممکن است به این شکل باشد:

{
    "result": 0,
    "text": "IPv6 subnet 2001:db8:1::/64 (id 234) deleted",
    "subnets": [
        {
            "id": 234,
            "subnet": "2001:db8:1::/64"
        }
    ]
}

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

اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای ایستای میزبان را نمی‌توان در subnet4-delta-add مشخص کرد. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

این دستور از کلیدها برای شناسایی شیء مربوطه استفاده می‌کند. کلیدها قابل به‌روزرسانی نیستند. برای افزودن اشیای دیگر با کلیدهای متداخل، ابتدا باید اشیاء حذف شوند. استخرهای آدرس با پارامتر pool شناسایی می‌شوند؛ گزینه‌ها با پارامترهای name یا code و space شناسایی می‌شوند.

{
    "command": "subnet4-delta-add",
    "arguments": {
        "subnet4": [ {
            "valid-lifetime": 120,
            "id": 123,
            "subnet": "10.20.30.0/24",
            "option-data": [
                {
                    "always-send": false,
                    "code": 3,
                    "csv-format": true,
                    "data": "192.0.3.1",
                    "name": "routers",
                    "space": "dhcp4"
                }
            ],
            "pools": [
                {
                    "pool": "10.20.30.1-10.20.30.10",
                    "option-data": [
                        {
                            "always-send": false,
                            "code": 4,
                            "csv-format": true,
                            "data": "192.0.4.1",
                            "name": "time-servers",
                            "space": "dhcp4"
                        }
                    ]
                }
            ]
        } ]
    }
}

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

{
    "result": 0,
    "text": "IPv4 subnet updated",
    "arguments": {
        "subnet4": [
            {
                "id": 123,
                "subnet": "10.20.30.0/24"
            }
        ]
    }
}

این دستور زیرشبکه "10.20.30.0/24" با شناسه 123 را با تغییر طول‌عمر معتبر، با افزودن یا تغییر گزینه سطح زیرشبکه 3 ("routers")، با افزودن یا تغییر پارامترهای استخر "10.20.30.1-10.20.30.10"، و با افزودن یا تغییر گزینه سطح استخر 4 ("time-servers") به‌روزرسانی می‌کند..SS دستور subnet6-delta-add

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

اطلاعات زیرشبکه در این دستور ساختاری یکسان با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای ایستای میزبان نمی‌توانند درون subnet6-delta-add مشخص شوند. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

این دستور از کلیدها برای شناسایی شیء مربوطه استفاده می‌کند. کلیدها قابل به‌روزرسانی نیستند. اشیاء ابتدا باید حذف شوند تا بتوان اشیاء دیگری را با کلیدهای متداخل اضافه کرد. استخرهای آدرس با پارامتر pool شناسایی می‌شوند؛ استخرهای پیشوند با پارامترهای prefix، prefix-len و delegated-len شناسایی می‌شوند؛ و گزینه‌ها با پارامترهای name یا code و space شناسایی می‌گردند.

{
    "command": "subnet6-delta-add",
    "arguments": {
        "subnet6": [ {
            "valid-lifetime": 120,
            "id": 243,
            "subnet": "2001:db8:1::/64",
            "option-data": [
                {
                    "always-send": false,
                    "code": 23,
                    "csv-format": true,
                    "data": "3000::3:1",
                    "name": "dns-servers",
                    "space": "dhcp6"
                }
            ],
            "pd-pools": [
                {
                    "prefix": "2001:db8:2::",
                    "prefix-len": 48,
                    "delegated-len": 64,
                    "option-data": [
                        {
                            "always-send": false,
                            "code": 22,
                            "csv-format": true,
                            "data": "3000::4:1",
                            "name": "sip-server-addr",
                            "space": "dhcp6"
                        }
                    ]
                }
            ],
            "pools": [
                {
                    "pool": "2001:db8:1::1-2001:db8:1::10",
                    "option-data": [
                        {
                            "always-send": false,
                            "code": 31,
                            "csv-format": true,
                            "data": "3000::5:1",
                            "name": "sntp-servers",
                            "space": "dhcp6"
                        }
                    ]
                }
            ]
        } ]
    }
}

پاسخ این دستور ساختار زیر را دارد:

{
    "result": 0,
    "text": "IPv6 subnet updated",
    "arguments": {
        "subnet6": [
            {
                "id": 234,
                "subnet": "2001:db8:1::/64"
            }
        ]
    }
}

این دستور زیرشبکهٔ "2001:db8:1::/64" با شناسهٔ 243 را با تغییر طول عمر معتبر (valid lifetime)، افزودن یا تغییر گزینهٔ سطح زیرشبکهٔ 23 ("dns-servers")، افزودن یا تغییر پارامترهای استخر "2001:db8:1::1-2001:db8:1::10"، افزودن یا تغییر گزینهٔ سطح استخر 31 ("sntp-servers")، افزودن یا تغییر پارامترهای pd-pool با عنوان "2001:db8:2::" با prefix-len برابر با 48، و افزودن یا تغییر گزینهٔ سطح pd-pool شمارهٔ 22 ("sip-server-addr") به‌روزرسانی می‌کند.

این دستور برای به‌روزرسانی یک زیرشبکه با حذف بخش‌هایی از آن در پیکربندی موجود سرور استفاده می‌شود. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد. شناسهٔ زیرشبکه برای شناسایی زیرشبکه‌ای که باید به‌روزرسانی شود استفاده می‌شود؛ این مقدار باید مشخص گردد و در میان تمام زیرشبکه‌ها منحصربه‌فرد باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود.

اطلاعات زیرشبکه در این دستور ساختاری یکسان با اطلاعات زیرشبکه در فایل پیکربندی سرور دارد، با این استثنا که رزروهای ایستای میزبان نمی‌توانند درون subnet4-delta-del مشخص شوند. برای به‌روزرسانی، حذف و ویرایش رزروهای ایستا باید از دستورهای شرح‌داده‌شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

این دستور انعطاف‌پذیر است و می‌تواند بخشی از زیرشبکه را با مشخص کردن کل شیئی که باید حذف شود، یا صرفاً با مشخص کردن کلیدهای شناسایی‌کنندهٔ شیء مربوطه حذف کند. استخرهای آدرس با پارامتر pool شناسایی می‌شوند؛ و گزینه‌ها با پارامترهای name یا code، و space شناسایی می‌گردند. اگر گزینه متعلق به فضای پیش‌فرض dhcp4 باشد، پارامتر space می‌تواند نادیده گرفته شود.

{
    "command": "subnet4-delta-del",
    "arguments": {
        "subnet4": [ {
            "valid-lifetime": 0,
            "id": 123,
            "subnet": "10.20.30.0/24",
            "option-data": [
                { "name": "routers" }
            ],
            "pools": [
                {
                    "option-data": [
                        { "code": 4 }
                    ],
                    "pool": "10.20.30.11-10.20.30.20"
                },
                {
                    "pool": "10.20.30.21-10.20.30.30"
                }
            ]
        } ]
    }
}

پاسخ این دستور ساختار زیر را دارد:

{
    "result": 0,
    "text": "IPv4 subnet updated",
    "arguments": {
        "subnet4": [
            {
                "id": 123,
                "subnet": "10.20.30.0/24"
            }
        ]
    }
}

این دستور زیرشبکهٔ "10.20.30.0/24" با شناسهٔ 123 را با حذف طول عمر معتبر (valid lifetime)، حذف گزینهٔ سطح زیرشبکهٔ 3 ("routers")، حذف استخر "10.20.30.21-10.20.30.30" و حذف گزینهٔ سطح استخر 4 ("time-servers") در استخر "10.20.30.11-10.20.30.20" به‌روزرسانی می‌کند. نیازی نیست مقادیر اسکالر با آنچه پیکربندی شده مطابقت داشته باشند، اما همچنان باید حضور داشته باشند تا ساختار معتبر JSON حفظ شود و مقدار معتبری برای تجزیه شدن (parse) باشند..SS دستور subnet6-delta-del

این دستور برای به‌روزرسانی یک زیرشبکه از طریق حذف بخش‌هایی از آن در پیکربندی موجود کارساز به کار می‌رود. این عملیات هیچ تأثیری بر سایر زیرشبکه‌ها ندارد. از شناسهٔ زیرشبکه برای تعیین زیرشبکه جهت به‌روزرسانی استفاده می‌شود؛ این شناسه باید مشخص شده و در میان تمام زیرشبکه‌ها یکتا باشد. پیشوند زیرشبکه نباید به‌روزرسانی شود.

اطلاعات زیرشبکه در این دستور ساختاری مشابه با اطلاعات زیرشبکه در فایل پیکربندی کارساز دارد، با این استثنا که رزروهای ایستا برای میزبان را نمی‌توان درون subnet6-delta-del مشخص کرد. برای به‌روزرسانی، حذف و اصلاح رزروهای ایستا باید از دستورهای شرح داده شده در libdhcp_host_cmds.so: Host Commands استفاده شود.

این دستور انعطاف‌پذیر است و می‌تواند با مشخص کردن کل شیئی که باید حذف شود، یا تنها با مشخص کردن کلیدهای شناسایی‌کنندهٔ آن شیء، بخش مربوطه از زیرشبکه را حذف کند. استخرهای آدرس با پارامتر pool مشخص می‌شوند؛ استخرهای پیشوند با پارامترهای prefix، prefix-len و delegated-len شناسایی می‌شوند؛ و گزینه‌ها با پارامترهای name یا code و space مشخص می‌گردند. در صورتی که گزینه متعلق به فضای پیش‌فرض dhcp6 باشد، می‌توان پارامتر space را نادیده گرفت.

{
    "command": "subnet6-delta-del",
    "arguments": {
        "subnet6": [ {
            "valid-lifetime": 0,
            "id": 234,
            "subnet": "2001:db8:1::/64",
            "option-data": [
                { "name": "dns-servers" }
            ],
            "pd-pools": [
                {
                    "prefix": "2001:db8:3::",
                    "prefix-len": 48,
                    "delegated-len": 64,
                    "option-data": [
                        { "code": 22 }
                    ]
                },
                {
                    "prefix": "2001:db8:4::",
                    "prefix-len": 48,
                    "delegated-len": 64
                }
            ],
            "pools": [
                {
                    "option-data": [
                        { "code": 31 }
                    ],
                    "pool": "2001:db8:1::11-2001:db8:1::20"
                },
                {
                    "pool": "2001:db8:1::21-2001:db8:1::30"
                }
            ]
        } ]
    }
}

پاسخ این دستور ساختار زیر را دارد:

{
    "result": 0,
    "text": "IPv6 subnet updated",
    "arguments": {
        "subnet6": [
            {
                "id": 234,
                "subnet": "2001:db8:1::/64"
            }
        ]
    }
}

این دستور زیرشبکهٔ "2001:db8:1::/64" با شناسهٔ 243 را با حذف valid lifetime، حذف گزینهٔ 23 در سطح زیرشبکه ("dns-servers")، حذف استخر "2001:db8:1::21-2001:db8:1::30"، حذف گزینهٔ 31 در سطح استخر ("sntp-servers") در استخر "2001:db8:1::11-2001:db8:1::20"، حذف pd-pool با عنوان "2001:db8:4::" با prefix-len برابر با 48، و حذف گزینهٔ 22 در سطح pd-pool ("sip-server-addr") در pd-pool با عنوان "2001:db8:3::" با prefix-len برابر با 48 به‌روزرسانی می‌کند. نیازی نیست مقادیر اسکالر با آنچه پیکربندی شده مطابقت داشته باشند، اما برای حفظ ساختار معتبر json و داشتن یک مقدار معتبر جهت امکان تجزیه شدن، همچنان باید مشخص شوند.

این دستورها برای دریافت فهرست کامل شبکه‌های اشتراکی پیکربندی‌شده در حال حاضر به کار می‌روند. این فهرست تنها شامل اطلاعات بسیار پایه‌ای دربارهٔ هر شبکهٔ اشتراکی است. اگر به جزئیات بیشتری نیاز است، لطفاً از network4-get یا network6-get برای بازیابی تمامی اطلاعات موجود استفاده کنید. این دستور به هیچ پارامتری نیاز ندارد و فراخوانی آن بسیار ساده است:

{
    "command": "network4-list"
}

یک نمونه پاسخ برای network4-list به صورت زیر است:

{
    "arguments": {
        "shared-networks": [
            { "name": "floor1" },
            { "name": "office" }
        ]
    },
    "result": 0,
    "text": "2 IPv4 network(s) found"
}

دستور network6-list برای هر دو بخش دستور و پاسخ، دقیقاً از ساختار نحوی یکسانی استفاده می‌کند..SS دستورهای network4-get و network6-get

این دستورها برای دریافت اطلاعات دقیق درباره شبکه‌های اشتراکی (shared networks)، شامل زیرشبکه‌هایی که در حال حاضر بخشی از یک شبکه مشخص هستند، استفاده می‌شوند. هر دو دستور یک پارامتر اجباری به نام name می‌گیرند که نام شبکه اشتراکی را مشخص می‌کند. یک دستور نمونه برای دریافت جزئیات یک شبکه اشتراکی IPv4 با نام "floor13" به صورت زیر است:

{
    "command": "network4-get",
    "arguments": {
        "name": "floor13"
    }
}

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

{
    "result": 0,
    "text": "Info about IPv4 shared network 'floor13' returned",
    "arguments": {
        "shared-networks": [
        {
            "match-client-id": true,
            "name": "floor13",
            "option-data": [ ],
            "rebind-timer": 90,
            "relay": {
                "ip-address": "0.0.0.0"
            },
            "renew-timer": 60,
            # Specify if the server should look up global reservations.
            "reservations-global": false,
            # Specify if the server should look up in-subnet reservations.
            "reservations-in-subnet": true,
            # Specify if the server can assume that all reserved addresses
            # are out-of-pool.
            "reservations-out-of-pool": false,
            "subnet4": [
                {
                    "subnet": "192.0.2.0/24",
                    "id": 5,
                    ...
                    # many other subnet-specific details here
                },
                {
                    "id": 6,
                    "subnet": "192.0.3.0/31",
                    ...
                    # many other subnet-specific details here
                }
            ],
            "valid-lifetime": 120
        }
        ]
    }
}

پاسخ واقعی شامل فیلدهای اضافی بسیاری است که در اینجا برای وضوح بیشتر حذف شده‌اند. قالب پاسخ دقیقاً همان قالبی است که در config-get <#std-isccmd-config-get> استفاده می‌شود، با این تفاوت که تنها به بازگرداندن اطلاعات شبکه اشتراکی محدود شده است.

این دستورها برای افزودن یک شبکه اشتراکی جدید استفاده می‌شوند که باید نامی یکتا داشته باشد. این دستور به یک پارامتر به نام shared-networks نیاز دارد که یک لیست است و باید دقیقاً شامل یک مدخل (entry) باشد که شبکه را تعریف می‌کند. تنها عنصر اجباری برای یک شبکه، نام آن است. اگرچه از نظر عملیاتی منطقی به نظر نمی‌رسد، اما امکان افزودن یک شبکه اشتراکی خالی که هیچ زیرشبکه‌ای در آن وجود ندارد، ممکن است. این کار برای اهداف آزمایشی مجاز است، اما داشتن شبکه‌های خالی (یا شبکه‌هایی با تنها یک زیرشبکه) در محیط‌های عملیاتی (production) توصیه نمی‌شود. برای جزئیات مربوط به نحو (syntax)، به Shared Networks in DHCPv4 <#shared-network4> و Shared Networks in DHCPv6 <#shared-network6> مراجعه کنید.

نکته:

برخلاف توارث پارامترها در حین پردازش یک پیکربندی کامل جدید، این دستور توارث پارامتر را به طور کامل مدیریت نمی‌کند. هر پارامتر مفقود به جای این که از محدوده سراسری (global scope) به ارث برده شود، با مقادیر پیش‌فرض پر خواهد شد.

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

{
    "command": "network4-add",
    "arguments": {
        "shared-networks": [ {
            "name": "floor13",
            "subnet4": [
            {
                "id": 100,
                "pools": [ { "pool": "192.0.2.2-192.0.2.99" } ],
                "subnet": "192.0.2.0/24",
                "option-data": [
                    {
                        "name": "routers",
                        "data": "192.0.2.1"
                    }
                ]
            },
            {
                "id": 101,
                "pools": [ { "pool": "192.0.3.2-192.0.3.99" } ],
                "subnet": "192.0.3.0/24",
                "option-data": [
                    {
                        "name": "routers",
                        "data": "192.0.3.1"
                    }
                ]
            } ]
        } ]
    }
}

با فرض اینکه قبلاً هیچ شبکه اشتراکی با نام "floor13" و هیچ زیرشبکه‌ای با شناسه‌های 100 و 101 پیکربندی نشده باشد، دستور با موفقیت اجرا خواهد شد و پاسخ زیر را برمی‌گرداند:

{
    "arguments": {
        "shared-networks": [ { "name": "floor13" } ]
    },
    "result": 0,
    "text": "A new IPv4 shared network 'floor13' added"
}

دستور network6-add هم برای پرس‌وجو و هم برای پاسخ از همین نحو استفاده می‌کند. با این حال، برخی پارامترها فقط مخصوص IPv4 هستند (مانند match-client-id) و برخی دیگر فقط مخصوص IPv6 هستند (مانند interface-id). همین موضوع برای زیرشبکه‌های درون شبکه نیز صدق می‌کند..SS دستورهای network4-del و network6-del

این دستورها برای حذف شبکه‌های اشتراکی موجود به کار می‌روند. هر دو دستور دقیقاً یک پارامتر می‌گیرند، name، که نام شبکه مورد نظر برای حذف را مشخص می‌کند. نمونه‌ای از فراخوانی دستور network4-del به صورت زیر است:

{
    "command": "network4-del",
    "arguments": {
        "name": "floor13"
    }
}

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

{
    "arguments": {
        "shared-networks": [
            {
                "name": "floor13"
            }
        ]
    },
    "result": 0,
    "text": "IPv4 shared network 'floor13' deleted"
}

دستور network6-del دقیقاً از همان نحو برای هر دوی دستور و پاسخ استفاده می‌کند.

اگر زیرشبکه‌هایی متعلق به شبکه اشتراکیِ در حال حذف وجود داشته باشند، آن‌ها به یک زیرشبکه ساده تنزل داده می‌شوند. یک پارامتر اختیاری به نام subnets-action وجود دارد که در صورت تعیین شدن، یکی از دو مقدار ممکن را می‌پذیرد: keep (که پیش‌فرض است) و delete. این گزینه مشخص می‌کند که آیا زیرشبکه‌ها به زیرشبکه‌های ساده تنزل یابند یا حذف شوند. یک نمونه استفاده در دستور network6-del که شبکه اشتراکی و تمام زیرشبکه‌های درون آن را حذف می‌کند می‌تواند به صورت زیر باشد:

{
    "command": "network4-del",
    "arguments": {
        "name": "floor13",
        "subnets-action": "delete"
    }
}

همچنین برای حذف کامل زیرشبکه‌ها، استفاده از دستورهای subnet4-del یا subnet6-del امکان‌پذیر است.

این دستورها برای افزودن زیرشبکه‌های موجود به شبکه‌های اشتراکی موجود به کار می‌روند. چندین روش برای افزودن یک شبکه اشتراکی جدید وجود دارد. مدیر سیستم می‌تواند کل شبکه اشتراکی را یک‌جا اضافه کند، چه از طریق ویرایش فایل پیکربندی یا با فراخوانی دستور network4-add یا network6-add به همراه زیرشبکه‌های مورد نظر در آن. این رویکرد برای زیرشبکه‌های اشتراکی کاملاً جدید به خوبی عمل می‌کند. با این حال، ممکن است مواردی پیش بیاید که آدرس‌های یک زیرشبکه موجود رو به اتمام باشد و لازم باشد با فضای آدرس‌دهی بیشتر گسترش یابد؛ به عبارت دیگر، باید زیرشبکه دیگری بر روی آن افزوده شود. برای این سناریو، مدیر سیستم می‌تواند از network4-add یا network6-add استفاده کرده و سپس با استفاده از network4-subnet-add یا network6-subnet-add، یک زیرشبکه موجود را به این شبکه اشتراکی تازه ایجاد شده اضافه کند.

دستورهای network4-subnet-add و network6-subnet-add دو پارامتر دریافت می‌کنند: id، که یک عدد صحیح است و شناسه (ID) یک زیرشبکه موجود را برای افزوده شدن به یک شبکه اشتراکی مشخص می‌کند؛ و name، که نام شبکه اشتراکی‌ای را که زیرشبکه به آن اضافه خواهد شد مشخص می‌سازد. زیرشبکه نباید به هیچ شبکه موجودی تعلق داشته باشد؛ برای انتساب مجدد یک زیرشبکه از یک شبکه اشتراکی به شبکه دیگر، ابتدا از دستورهای network4-subnet-del یا network6-subnet-del استفاده کنید.

نمونه‌ای از فراخوانی دستور network4-subnet-add به صورت زیر است:

{
    "command": "network4-subnet-add",
    "arguments": {
        "name": "floor13",
        "id": 5
    }
}

با فرض وجود شبکه‌ای به نام "floor13"، و وجود زیرشبکه‌ای با subnet-id برابر با 5 که بخشی از شبکه موجود نیست، این دستور پاسخی مشابه زیر را بازمی‌گرداند:

{
    "result": 0,
    "text": "IPv4 subnet 10.0.0.0/8 (id 5) is now part of shared network 'floor13'"
}

دستور network6-subnet-add دقیقاً از همان نحو برای هر دوی دستور و پاسخ استفاده می‌کند.

نکته:

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

این دستورها برای حذف یک زیرشبکه که بخشی از یک شبکهٔ اشتراکی (shared network) موجود است و تنزل آن به یک زیرشبکهٔ مستقل و عادی به کار می‌روند. برای حذف کامل یک زیرشبکه، در عوض از دستورهای subnet4-del یا subnet6-del استفاده کنید. دستورهای network4-subnet-del و network6-subnet-del دو پارامتر می‌گیرند: id که یک عدد صحیح است و شناسهٔ زیرشبکهٔ موجودی را مشخص می‌کند که باید از یک شبکهٔ اشتراکی حذف شود؛ و name که نام شبکهٔ اشتراکی را که زیرشبکه از آن حذف خواهد شد مشخص می‌کند.

یک نمونه از فراخوانی دستور network4-subnet-del به صورت زیر است:

{
   "command": "network4-subnet-del",
   "arguments": {
       "name": "floor13",
       "id": 5
   }
}

با فرض اینکه زیرشبکه‌ای با subnet-id برابر با ۵ وجود داشته که بخشی از یک شبکهٔ اشتراکی با نام "floor13" بوده است، پاسخ مشابه زیر خواهد بود:

{
    "result": 0,
    "text": "IPv4 subnet 10.0.0.0/8 (id 5) is now removed from shared network 'floor13'"
}

دستور network6-subnet-del برای هر دوی دستور و پاسخ از همان ساختار نحوی استفاده می‌کند.

این کتابخانه چندین هدف را دنبال می‌کند:

  • تخصیص کاربران «جدید» یا «ثبت‌نشده» به یک زیرشبکهٔ محدود، در حالی که کاربران «شناخته‌شده» یا «ثبت‌شده» به زیرشبکه‌های بدون محدودیت تخصیص می‌یابند.
  • امکان سفارشی‌سازی گزینه‌های پاسخ DHCP یا مقادیر گزینه‌های سازنده بر اساس هویت کاربر.
  • فراهم آوردن یک گزارش بی‌درنگ از فعالیت ثبت کاربران، که می‌تواند توسط یک مصرف‌کنندهٔ خارجی نمونه‌برداری شود.
  • ارائه به عنوان نمونه‌ای نمایشی از قابلیت‌های گوناگونی که می‌توان با استفاده از رابط قلاب‌ها (hooks interface) پیاده‌سازی کرد.

نکته:

libdhcp_user_chk.so بخشی از کد متن‌باز است و در دسترس تمام کاربران Kea قرار دارد.

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

به عنوان نمونه‌ای از یک مورد کاربرد، این رفتار می‌تواند برای قرار دادن کاربران ناشناخته در یک زیرشبکهٔ مجزا پیاده‌سازی شود که به یک «باغ محصور» (walled garden) منتهی می‌شود؛ جایی که آن‌ها تنها به یک درگاه ثبت‌نام دسترسی دارند. پس از اینکه داده‌های لازم را پر کردند، مشخصات آن‌ها به فایل کلاینت‌های شناخته‌شده افزوده می‌شود و پس از راه‌اندازی مجدد دستگاه، یک آدرس مناسب دریافت می‌کنند.

نکته:

این کتابخانه چندین سال قبل از در دسترس قرار گرفتن سازوکار رزرو میزبان (host reservation) توسعه یافته بود. رزرو میزبان بسیار قدرتمندتر و انعطاف‌پذیرتر است، اما توانایی user_chk در مراجعه به یک منبع اطلاعات خارجی دربارهٔ کلاینت‌ها و تغییر رفتار Kea همچنان مفید و دارای ارزش آموزشی است.

این کتابخانه در زمان بارگذاری و هر بار که یک بستهٔ دریافتی پردازش می‌شود، فایل /usr/local/share/kea/user_chk_registry.txt را می‌خواند. انتظار می‌رود هر خط از فایل شامل یک قطعه کد JSON مستقل باشد که باید دارای دو مدخل زیر باشد:

  • type - که مقدار آن برای کاربران IPv4 برابر با "HW_ADDR" یا برای کاربران IPv6 برابر با "DUID" است.
  • id - که مقدار آن یا آدرس سخت‌افزاری یا DUID از درخواست است، که در قالب رشته‌ای از ارقام هگزادسیمال، با یا بدون جداکننده‌های ":" قالب‌بندی شده است.

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

  • bootfile - که مقدار آن مسیر فایل مورد نظر است.
  • tftp_server - که مقدار آن نام میزبان یا آدرس IP کارساز مورد نظر است.

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

{ "type" : "HW_ADDR", "id" : "0c:0e:0a:01:ff:04", "bootfile" : "/usr/local/share/kea/v4bootfile" }
{ "type" : "HW_ADDR", "id" : "0c:0e:0a:01:ff:06", "tftp_server" : "tftp.v4.example.com" }
{ "type" : "DUID", "id" : "00:01:00:01:19:ef:e6:3b:00:0c:01:02:03:04", "bootfile" : "/usr/local/share/kea/v6bootfile" }
{ "type" : "DUID", "id" : "00:01:00:01:19:ef:e6:3b:00:0c:01:02:03:06", "tftp_server" : "tftp.v6.example.com" }

همانند هر کتابخانهٔ قلاب دیگری که توسط ISC ارائه می‌شود، سازوکار درونی کد user_chk به خوبی مستند شده است. کاربران برای کسب اطلاعات دربارهٔ چگونگی عملکرد درونی کد، می‌توانند به بخش کتابخانهٔ user_chk در راهنمای توسعه‌دهندگان Kea https://reports.kea.isc.org/dev_guide/d8/db2/libdhcp_user_chk.html مراجعه کنند. این بخش به همراه بخش چارچوب قلاب‌ها در راهنمای توسعه‌دهندگان Kea https://reports.kea.isc.org/dev_guide/index.html#hooksFramework باید راهنمایی‌های لازم را در اختیار کاربران قرار دهد تا این کتابخانه را توسعه دهند و شاید حتی کتابخانه‌ای را از ابتدا بنویسند..SH "آمارها (STATISTICS)"

هر دو کارگزار Kea DHCP از جمع‌آوری آمارها پشتیبانی می‌کنند. یک کارگزار DHCP فعال با رویدادهای گوناگونی مواجه می‌شود که می‌توانند باعث جمع‌آوری آمارهای مشخصی گردند. برای نمونه، یک کارگزار DHCPv4 ممکن است بسته‌ای دریافت کند (آمار pkt4-received یک واحد افزایش می‌یابد) که پس از تجزیه، به‌عنوان DHCPDISCOVER شناسایی می‌شود (pkt4-discover-received). کارگزار آن را پردازش کرده و تصمیم می‌گیرد یک DHCPOFFER را به‌عنوان پاسخ خود ارسال کند (آمارهای pkt4-offer-sent و pkt4-sent یک واحد افزایش می‌یابند). چنین رویدادهایی مکرراً رخ می‌دهند، بنابراین داشتن مقادیری در مرتبه چند ده هزار برای آمارها غیرمعمول نیست. آن‌ها می‌توانند ابزاری آسان و قدرتمند برای نظارت بر سلامت یک کارگزار و یک شبکه باشند. برای مثال، اگر رشد آمار pkt4-received متوقف شود، به این معنی است که بسته‌های کلاینت‌ها به کارگزار نمی‌رسند.

چهار نوع آمار وجود دارد:

  • integer - این رایج‌ترین نوع است. به‌صورت یک عدد صحیح ۶۴ بیتی (int64_t در C++) پیاده‌سازی شده است، بنابراین می‌تواند هر مقداری بین -2^63 تا 2^63-1 را در خود نگه دارد.
  • big integer - این نوع برای نگهداری اعداد بزرگ در نظر گرفته شده است. به‌صورت یک عدد صحیح ۱۲۸ بیتی (boost::multiprecision::int128_t در C++) پیاده‌سازی شده است، بنابراین می‌تواند هر مقداری بین -2^127 تا 2^127-1 را نگهداری کند.
  • floating point - این نوع برای ذخیره دقت ممیز شناور طراحی شده است. به‌صورت نوع double در C++ پیاده‌سازی شده است.
  • duration - این نوع برای ثبت بازه‌های زمانی در نظر گرفته شده است. این نوع از `boost::posix_time::time_duration استفاده می‌کند که ساعت‌ها، دقیقه‌ها، ثانیه‌ها و میکروثانیه‌ها را ذخیره می‌نماید.
  • string - این نوع برای ثبت آمارها به شکل متنی در نظر گرفته شده است. این نوع از std::string در C++ استفاده می‌کند.

در طول عملکرد عادی، کارگزارهای DHCPv4 و DHCPv6 آمارها را جمع‌آوری می‌کنند. برای فهرستی از آمارهای DHCPv4 و DHCPv6، به‌ترتیب به Statistics in the DHCPv4 Server <#dhcp4-stats> و Statistics in the DHCPv6 Server <#dhcp6-stats> مراجعه کنید.

برای استخراج داده‌ها از ماژول آمار، می‌توان از کانال کنترل استفاده کرد. برای جزئیات به Management API <#ctrl-channel> مراجعه کنید. بازیابی یک آمار منفرد یا همه آمارها، بازنشانی آمارها (یعنی تنظیم آن‌ها روی یک مقدار خنثی، معمولاً صفر)، یا حتی حذف کامل یک آمار مشخص یا تمام آمارها امکان‌پذیر است. برای فهرستی از دستورات مربوط به آمار به بخش Commands for Manipulating Statistics مراجعه کنید.

ابزارهای خارجی می‌توانند از آمارها برای نظارت بر Kea استفاده کنند. یک نمونه از چنین ابزارهایی Stork است. برای جزئیات درباره نحوه استفاده از آن و سایر منابع داده جهت بازیابی دوره‌ای آمارها برای کسب دید بهتر از سلامت و وضعیت عملیاتی Kea، به Monitoring Kea With Stork <#stork> مراجعه نمایید.

تمام آمارهای پشتیبانی‌شده توسط کارگزارهای Kea هنگام راه‌اندازی کارگزار مقداردهی اولیه می‌شوند و در پاسخ به دستوراتی مانند statistic-get-all بازگردانده می‌شوند. آمارهای زمان اجرا مربوط به بسته‌های DHCP پردازش‌شده، در ابتدا روی ۰ تنظیم شده و هنگام راه‌اندازی مجدد کارگزار بازنشانی می‌گردند.

آمارهای مربوط به هر زیرشبکه (Per-subnet) هنگام انجام پیکربندی مجدد، دوباره محاسبه می‌شوند.

به‌طور کلی، زمانی که یک آمار مقداردهی اولیه شد، تا زمانی که صراحتاً از طریق statistic-remove یا statistic-remove-all حذف نشود، یا زمانی که کارگزار خاموش گردد، در مدیر (manager) نگهداری می‌شود.

حذف آماری که مکرراً به‌روزرسانی می‌شود منطقی نیست، زیرا با ثبت بعدی آن توسط کد کارگزار، دوباره اضافه خواهد شد. دستورات statistic-remove و statistic-remove-all برای حذف آمارهایی در نظر گرفته شده‌اند که انتظار نمی‌رود در آینده نزدیک مشاهده شوند. برای نمونه، یک دستگاه با پیکربندی نادرست در شبکه ممکن است باعث شود کلاینت‌ها نشانی‌های تکراری را گزارش کنند، بنابراین کارگزار مقادیر رو به رشدی از pkt4-decline-received را گزارش خواهد داد. پس از یافتن مشکل و حذف دستگاه، مدیر سیستم ممکن است بخواهد آمار pkt4-decline-received را حذف کند تا دیگر گزارش نشود، مگر اینکه و تا زمانی که دوباره یک نشانی تکراری شناسایی گردد.

چندین دستور تعریف شده است که می‌توان از آن‌ها برای دسترسی (-get)، بازنشانی به صفر یا یک مقدار خنثی (-reset)، یا حذف کامل یک آمار (-remove) استفاده کرد. حد زمانی آمار (-sample-age-set) و حد اندازه بر اساس تعداد (-sample-count-set)، که کنترل می‌کنند نمونه‌های یک آمار معین چه مدت یا به چه تعداد نگهداری شوند، نیز قابل تغییر هستند.

تفاوت بین -reset و -remove تا حدی ظریف است. دستور -reset مقدار آمار را روی صفر یا یک مقدار خنثی تنظیم می‌کند، به‌طوری که پس از این عملیات، آمار مقداری برابر با 0 (integer)، 0.0 (float)، 0h0m0s0us (duration)، یا "" (string) خواهد داشت. هنگام درخواست، آماری با مقادیر ذکرشده بازگردانده می‌شود. -remove یک آمار را به‌طور کامل حذف می‌کند، به‌طوری که آمار دیگر گزارش نمی‌شود. با این حال، کد کارگزار در صورت وجود دلیلی برای ثبت، ممکن است مجدداً آن را اضافه کند.

نکته:

بخش‌های زیر دستوراتی را شرح می‌دهند که می‌توانند به کارگزار ارسال شوند؛ این مثال‌ها تکه‌هایی از یک فایل پیکربندی نیستند. برای اطلاعات بیشتر درباره ارسال دستورات به Kea، به Management API <#ctrl-channel> مراجعه کنید.

دستور statistic-get یک آمار منفرد را بازیابی می‌کند. این دستور یک پارامتر تک‌رشته‌ای به نام name می‌گیرد که نام آمار را مشخص می‌سازد. یک نمونه دستور می‌تواند مانند این باشد:

{
    "command": "statistic-get",
    "arguments": {
        "name": "pkt4-received"
    }
}

کارگزار جزئیات آمار درخواست‌شده را بازمی‌گرداند؛ نتیجه 0 نشان‌دهنده موفقیت و مقدار پارامتر arguments همان آمار مشخص‌شده است. اگر آمار درخواست‌شده یافت نشود، پاسخ حاوی یک نگاشت خالی خواهد بود، یعنی فقط { } به‌عنوان آرگومان، اما کد وضعیت همچنان نشان‌دهنده موفقیت (0) است.

در اینجا یک نمونه پاسخ آمده است:

{
    "command": "statistic-get",
    "arguments": {
        "pkt4-received": [ [ 125, "2019-07-30 10:11:19.498739" ], [ 100, "2019-07-30 10:11:19.498662" ] ]
    },
    "result": 0
}

دستور statistic-reset آمار مشخص‌شده را به مقدار خنثی آن تنظیم می‌کند: 0 برای عدد صحیح، 0.0 برای ممیز شناور، 0h0m0s0us برای بازه زمانی، و "" برای نوع رشته‌ای. این دستور یک پارامتر تک‌رشته‌ای به نام name می‌گیرد که نام آمار را مشخص می‌کند. یک نمونه دستور ممکن است بدین صورت باشد:

{
    "command": "statistic-reset",
    "arguments": {
        "name": "pkt4-received"
    }
}

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

دستور statistic-remove یک آمار را حذف می‌کند. این دستور یک پارامتر تک‌رشته‌ای به نام name می‌گیرد که نام آمار را مشخص می‌کند. یک نمونه دستور ممکن است بدین صورت باشد:

{
    "command": "statistic-remove",
    "arguments": {
        "name": "pkt4-received"
    }
}

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

دستور statistic-get-all تمامی آمارهای ثبت‌شده را بازیابی می‌کند. یک نمونه دستور ممکن است بدین صورت باشد:

{
    "command": "statistic-get-all",
    "arguments": { }
}

در اینجا یک نمونه پاسخ که تمامی آمارهای جمع‌آوری‌شده را بازمی‌گرداند آورده شده است:

{
    "command": "statistic-get-all",
    "arguments": {
        "assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836096"
            ]
        ],
        "cumulative-assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836166"
            ]
        ],
        "declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836156"
            ]
        ],
        "pkt4-ack-received": [
            [
                0,
                "2023-06-13 20:42:46.616247"
            ]
        ],
        "pkt4-ack-sent": [
            [
                0,
                "2023-06-13 20:42:46.616290"
            ]
        ],
        "pkt4-admin-filtered": [
            [
                0,
                "2023-06-13 20:42:46.616352"
            ]
        ],
        "pkt4-decline-received": [
            [
                0,
                "2023-06-13 20:42:46.616296"
            ]
        ],
        "pkt4-duplicate": [
            [
                0,
                "2023-06-13 20:42:46.616352"
            ]
        ],
        "pkt4-discover-received": [
            [
                0,
                "2023-06-13 20:42:46.616303"
            ]
        ],
        "pkt4-inform-received": [
            [
                0,
                "2023-06-13 20:42:46.616308"
            ]
        ],
        "pkt4-limit-exceeded": [
            [
                0,
                "2023-06-13 20:42:46.616310"
            ]
        ],
        "pkt4-nak-received": [
            [
                0,
                "2023-06-13 20:42:46.616312"
            ]
        ],
        "pkt4-nak-sent": [
            [
                0,
                "2023-06-13 20:42:46.616314"
            ]
        ],
        "pkt4-not-for-us": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-offer-received": [
            [
                0,
                "2023-06-13 20:42:46.616318"
            ]
        ],
        "pkt4-offer-sent": [
            [
                0,
                "2023-06-13 20:42:46.616323"
            ]
        ],
        "pkt4-parse-failed": [
            [
                0,
                "2023-06-13 20:42:46.616326"
            ]
        ],
        "pkt4-processing-failed": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-queue-full": [
            [
                0,
                "2023-06-13 20:42:46.616352"
            ]
        ],
        "pkt4-receive-drop": [
            [
                0,
                "2023-06-13 20:42:46.616330"
            ]
        ],
        "pkt4-received": [
            [
                0,
                "2023-06-13 20:42:46.616335"
            ]
        ],
        "pkt4-release-received": [
            [
                0,
                "2023-06-13 20:42:46.616339"
            ]
        ],
        "pkt4-request-received": [
            [
                0,
                "2023-06-13 20:42:46.616343"
            ]
        ],
        "pkt4-rfc-violation": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-sent": [
            [
                0,
                "2023-06-13 20:42:46.616348"
            ]
        ],
        "pkt4-service-disabled": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-unknown-received": [
            [
                0,
                "2023-06-13 20:42:46.616354"
            ]
        ],
        "reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836159"
            ]
        ],
        "reclaimed-leases": [
            [
                0,
                "2023-06-13 20:42:46.836163"
            ]
        ],
        "subnet[1].assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836173"
            ]
        ],
        "subnet[1].cumulative-assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836098"
            ]
        ],
        "subnet[1].declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836178"
            ]
        ],
        "subnet[1].pool[0].assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836205"
            ]
        ],
        "subnet[1].pool[0].cumulative-assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836137"
            ]
        ],
        "subnet[1].pool[0].declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836213"
            ]
        ],
        "subnet[1].pool[0].reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836225"
            ]
        ],
        "subnet[1].pool[0].reclaimed-leases": [
            [
                0,
                "2023-06-13 20:42:46.836236"
            ]
        ],
        "subnet[1].pool[0].total-addresses": [
            [
                11010049,
                "2023-06-13 20:42:46.836128"
            ]
        ],
        "subnet[1].reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836186"
            ]
        ],
        "subnet[1].reclaimed-leases": [
            [
                0,
                "2023-06-13 20:42:46.836194"
            ]
        ],
        "subnet[1].total-addresses": [
            [
                11010049,
                "2023-06-13 20:42:46.836083"
            ]
        ],
        "subnet[1].v4-lease-reuses": [
            [
                0,
                "2023-06-13 20:42:46.836105"
            ]
        ],
        "subnet[1].v4-reservation-conflicts": [
            [
                0,
                "2023-06-13 20:42:46.836111"
            ]
        ],
        "v4-allocation-fail": [
            [
                0,
                "2023-06-13 20:42:46.616358"
            ]
        ],
        "v4-allocation-fail-classes": [
            [
                0,
                "2023-06-13 20:42:46.616363"
            ]
        ],
        "v4-allocation-fail-no-pools": [
            [
                0,
                "2023-06-13 20:42:46.616368"
            ]
        ],
        "v4-allocation-fail-shared-network": [
            [
                0,
                "2023-06-13 20:42:46.616372"
            ]
        ],
        "v4-allocation-fail-subnet": [
            [
                0,
                "2023-06-13 20:42:46.616376"
            ]
        ],
        "v4-lease-reuses": [
            [
                0,
                "2023-06-13 20:42:46.616410"
            ]
        ],
        "v4-reservation-conflicts": [
            [
                0,
                "2023-06-13 20:42:46.616412"
            ]
        ]
    },
    "result": 0
}

یا

{
    "command": "statistic-get-all",
    "arguments": {
        "assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196757"
            ]
        ],
        "assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196757"
            ]
        ],
        "cumulative-assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196757"
            ]
        ],
        "cumulative-assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196758"
            ]
        ],
        "cumulative-registered": [
            [
                0,
                "2023-06-13 21:28:57.196758"
            ]
        ],
        "declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196754"
            ]
        ],
        "pkt6-addr-reg-inform-received": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-addr-reg-reply-received": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-addr-reg-reply-sent": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-admin-filtered": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-advertise-received": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-advertise-sent": [
            [
                0,
                "2023-06-13 21:28:57.177739"
            ]
        ],
        "pkt6-decline-received": [
            [
                0,
                "2023-06-13 21:28:57.177739"
            ]
        ],
        "pkt6-dhcpv4-query-received": [
            [
                0,
                "2023-06-13 21:28:57.177740"
            ]
        ],
        "pkt6-dhcpv4-response-received": [
            [
                0,
                "2023-06-13 21:28:57.177740"
            ]
        ],
        "pkt6-dhcpv4-response-sent": [
            [
                0,
                "2023-06-13 21:28:57.177741"
            ]
        ],
        "pkt6-duplicate": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-infrequest-received": [
            [
                0,
                "2023-06-13 21:28:57.177742"
            ]
        ],
        "pkt6-limit-exceeded": [
            [
                0,
                "2023-06-13 21:28:57.177742"
            ]
        ],
        "pkt6-not-for-us": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-parse-failed": [
            [
                0,
                "2023-06-13 21:28:57.177742"
            ]
        ],
        "pkt6-processing-failed": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-queue-full": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-rebind-received": [
            [
                0,
                "2023-06-13 21:28:57.177743"
            ]
        ],
        "pkt6-receive-drop": [
            [
                0,
                "2023-06-13 21:28:57.177743"
            ]
        ],
        "pkt6-received": [
            [
                0,
                "2023-06-13 21:28:57.177744"
            ]
        ],
        "pkt6-release-received": [
            [
                0,
                "2023-06-13 21:28:57.177744"
            ]
        ],
        "pkt6-renew-received": [
            [
                0,
                "2023-06-13 21:28:57.177745"
            ]
        ],
        "pkt6-reply-received": [
            [
                0,
                "2023-06-13 21:28:57.177745"
            ]
        ],
        "pkt6-reply-sent": [
            [
                0,
                "2023-06-13 21:28:57.177746"
            ]
        ],
        "pkt6-request-received": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-rfc-violation": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-sent": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-service-disabled": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-solicit-received": [
            [
                0,
                "2023-06-13 21:28:57.177748"
            ]
        ],
        "pkt6-unknown-received": [
            [
                0,
                "2023-06-13 21:28:57.177748"
            ]
        ],
        "reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196755"
            ]
        ],
        "reclaimed-leases": [
            [
                0,
                "2023-06-13 21:28:57.196756"
            ]
        ],
        "subnet[1].assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196760"
            ]
        ],
        "subnet[1].assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196761"
            ]
        ],
        "subnet[1].cumulative-assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196727"
            ]
        ],
        "subnet[1].cumulative-assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196729"
            ]
        ],
        "subnet[1].cumulative-registered": [
            [
                0,
                "2023-06-13 21:28:57.196727"
            ]
        ],
        "subnet[1].declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196763"
            ]
        ],
        "subnet[1].pd-pool[0].assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196785"
            ]
        ],
        "subnet[1].pd-pool[0].cumulative-assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196744"
            ]
        ],
        "subnet[1].pd-pool[0].reclaimed-leases": [
            [
                0,
                "2023-06-13 21:28:57.196789"
            ]
        ],
        "subnet[1].pd-pool[0].total-pds": [
            [
                256,
                "2023-06-13 21:28:57.196741"
            ]
        ],
        "subnet[1].pool[0].assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196773"
            ]
        ],
        "subnet[1].pool[0].cumulative-assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196739"
            ]
        ],
        "subnet[1].pool[0].declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196775"
            ]
        ],
        "subnet[1].pool[0].reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196779"
            ]
        ],
        "subnet[1].pool[0].reclaimed-leases": [
            [
                0,
                "2023-06-13 21:28:57.196783"
            ]
        ],
        "subnet[1].pool[0].total-nas": [
            [
                281474976710656,
                "2023-06-13 21:28:57.196736"
            ]
        ],
        "subnet[1].reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196766"
            ]
        ],
        "subnet[1].reclaimed-leases": [
            [
                0,
                "2023-06-13 21:28:57.196770"
            ]
        ],
        "subnet[1].registered": [
            [
                0,
                "2023-06-13 21:28:57.196727"
            ]
        ],
        "subnet[1].total-nas": [
            [
                281474976710656,
                "2023-06-13 21:28:57.196720"
            ]
        ],
        "subnet[1].total-pds": [
            [
                256,
                "2023-06-13 21:28:57.196724"
            ]
        ],
        "subnet[1].v6-ia-na-lease-reuses": [
            [
                0,
                "2023-06-13 21:28:57.196731"
            ]
        ],
        "subnet[1].v6-ia-pd-lease-reuses": [
            [
                0,
                "2023-06-13 21:28:57.196733"
            ]
        ],
        "v6-allocation-fail": [
            [
                0,
                "2023-06-13 21:28:57.177749"
            ]
        ],
        "v6-allocation-fail-classes": [
            [
                0,
                "2023-06-13 21:28:57.177755"
            ]
        ],
        "v6-allocation-fail-no-pools": [
            [
                0,
                "2023-06-13 21:28:57.177756"
            ]
        ],
        "v6-allocation-fail-shared-network": [
            [
                0,
                "2023-06-13 21:28:57.177756"
            ]
        ],
        "v6-allocation-fail-subnet": [
            [
                0,
                "2023-06-13 21:28:57.177757"
            ]
        ],
        "v6-ia-na-lease-reuses": [
            [
                0,
                "2023-06-13 21:28:57.177757"
            ]
        ],
        "v6-ia-pd-lease-reuses": [
            [
                0,
                "2023-06-13 21:28:57.177758"
            ]
        ]
    },
    "result": 0
}

یا

{
    "command": "statistic-get-all",
    "arguments": {
        "ncr-error": [
            [
                0,
                "2023-06-13 21:42:54.627751"
            ]
        ],
        "ncr-invalid": [
            [
                0,
                "2023-06-13 21:42:54.627749"
            ]
        ],
        "ncr-received": [
            [
                0,
                "2023-06-13 21:42:54.627737"
            ]
        ],
        "queue-mgr-queue-full": [
            [
                0,
                "2023-06-13 21:42:54.627737"
            ]
        ],
        "update-error": [
            [
                0,
                "2023-06-13 21:42:54.627759"
            ]
        ],
        "update-sent": [
            [
                0,
                "2023-06-13 21:42:54.627752"
            ]
        ],
        "update-signed": [
            [
                0,
                "2023-06-13 21:42:54.627753"
            ]
        ],
        "update-success": [
            [
                0,
                "2023-06-13 21:42:54.627755"
            ]
        ],
        "update-timeout": [
            [
                0,
                "2023-06-13 21:42:54.627757"
            ]
        ],
        "update-unsigned": [
            [
                0,
                "2023-06-13 21:42:54.627754"
            ]
        ]
    },
    "result": 0
}

دستور statistic-global-get-all تمام آمارهای سراسری ثبت‌شده را بازیابی می‌کند (مشابه statistic-get-all، اما بدون آمارهای زیرشبکه). یک دستور نمونه می‌تواند به این صورت باشد:

{
    "command": "statistic-global-get-all",
    "arguments": { }
}

در ادامه یک نمونه پاسخ که تمام آمارهای جمع‌آوری‌شده را بازمی‌گرداند آمده است:

{
    "command": "statistic-global-get-all",
    "arguments": {
        "assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836096"
            ]
        ],
        "cumulative-assigned-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836166"
            ]
        ],
        "declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836156"
            ]
        ],
        "pkt4-ack-received": [
            [
                0,
                "2023-06-13 20:42:46.616247"
            ]
        ],
        "pkt4-ack-sent": [
            [
                0,
                "2023-06-13 20:42:46.616290"
            ]
        ],
        "pkt4-admin-filtered": [
            [
                0,
                "2023-06-13 20:42:46.616352"
            ]
        ],
        "pkt4-decline-received": [
            [
                0,
                "2023-06-13 20:42:46.616296"
            ]
        ],
        "pkt4-discover-received": [
            [
                0,
                "2023-06-13 20:42:46.616303"
            ]
        ],
        "pkt4-duplicate": [
            [
                0,
                "2023-06-13 20:42:46.616352"
            ]
        ],
        "pkt4-inform-received": [
            [
                0,
                "2023-06-13 20:42:46.616308"
            ]
        ],
        "pkt4-limit-exceeded": [
            [
                0,
                "2023-06-13 20:42:46.616310"
            ]
        ],
        "pkt4-nak-received": [
            [
                0,
                "2023-06-13 20:42:46.616312"
            ]
        ],
        "pkt4-nak-sent": [
            [
                0,
                "2023-06-13 20:42:46.616314"
            ]
        ],
        "pkt4-not-for-us": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-offer-received": [
            [
                0,
                "2023-06-13 20:42:46.616318"
            ]
        ],
        "pkt4-offer-sent": [
            [
                0,
                "2023-06-13 20:42:46.616323"
            ]
        ],
        "pkt4-parse-failed": [
            [
                0,
                "2023-06-13 20:42:46.616326"
            ]
        ],
        "pkt4-processing-failed": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-queue-full": [
            [
                0,
                "2023-06-13 20:42:46.616352"
            ]
        ],
        "pkt4-receive-drop": [
            [
                0,
                "2023-06-13 20:42:46.616330"
            ]
        ],
        "pkt4-received": [
            [
                0,
                "2023-06-13 20:42:46.616335"
            ]
        ],
        "pkt4-release-received": [
            [
                0,
                "2023-06-13 20:42:46.616339"
            ]
        ],
        "pkt4-request-received": [
            [
                0,
                "2023-06-13 20:42:46.616343"
            ]
        ],
        "pkt4-rfc-violation": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-sent": [
            [
                0,
                "2023-06-13 20:42:46.616348"
            ]
        ],
        "pkt4-service-disabled": [
            [
                0,
                "2023-06-13 20:42:46.616351"
            ]
        ],
        "pkt4-unknown-received": [
            [
                0,
                "2023-06-13 20:42:46.616354"
            ]
        ],
        "reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 20:42:46.836159"
            ]
        ],
        "reclaimed-leases": [
            [
                0,
                "2023-06-13 20:42:46.836163"
            ]
        ],
        "v4-allocation-fail": [
            [
                0,
                "2023-06-13 20:42:46.616358"
            ]
        ],
        "v4-allocation-fail-classes": [
            [
                0,
                "2023-06-13 20:42:46.616363"
            ]
        ],
        "v4-allocation-fail-no-pools": [
            [
                0,
                "2023-06-13 20:42:46.616368"
            ]
        ],
        "v4-allocation-fail-shared-network": [
            [
                0,
                "2023-06-13 20:42:46.616372"
            ]
        ],
        "v4-allocation-fail-subnet": [
            [
                0,
                "2023-06-13 20:42:46.616376"
            ]
        ],
        "v4-lease-reuses": [
            [
                0,
                "2023-06-13 20:42:46.616410"
            ]
        ],
        "v4-reservation-conflicts": [
            [
                0,
                "2023-06-13 20:42:46.616412"
            ]
        ]
    },
    "result": 0
}

یا

{
    "command": "statistic-global-get-all",
    "arguments": {
        "assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196757"
            ]
        ],
        "assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196757"
            ]
        ],
        "cumulative-assigned-nas": [
            [
                0,
                "2023-06-13 21:28:57.196757"
            ]
        ],
        "cumulative-assigned-pds": [
            [
                0,
                "2023-06-13 21:28:57.196758"
            ]
        ],
        "cumulative-registered": [
            [
                0,
                "2023-06-13 21:28:57.196758"
            ]
        ],
        "declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196754"
            ]
        ],
        "pkt6-addr-reg-inform-received": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-addr-reg-reply-received": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-addr-reg-reply-sent": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-admin-filtered": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-advertise-received": [
            [
                0,
                "2023-06-13 21:28:57.177731"
            ]
        ],
        "pkt6-advertise-sent": [
            [
                0,
                "2023-06-13 21:28:57.177739"
            ]
        ],
        "pkt6-decline-received": [
            [
                0,
                "2023-06-13 21:28:57.177739"
            ]
        ],
        "pkt6-dhcpv4-query-received": [
            [
                0,
                "2023-06-13 21:28:57.177740"
            ]
        ],
        "pkt6-dhcpv4-response-received": [
            [
                0,
                "2023-06-13 21:28:57.177740"
            ]
        ],
        "pkt6-dhcpv4-response-sent": [
            [
                0,
                "2023-06-13 21:28:57.177741"
            ]
        ],
        "pkt6-duplicate": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-infrequest-received": [
            [
                0,
                "2023-06-13 21:28:57.177742"
            ]
        ],
        "pkt6-limit-exceeded": [
            [
                0,
                "2023-06-13 21:28:57.177742"
            ]
        ],
        "pkt6-not-for-us": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-parse-failed": [
            [
                0,
                "2023-06-13 21:28:57.177742"
            ]
        ],
        "pkt6-processing-failed": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-queue-full": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-rebind-received": [
            [
                0,
                "2023-06-13 21:28:57.177743"
            ]
        ],
        "pkt6-receive-drop": [
            [
                0,
                "2023-06-13 21:28:57.177743"
            ]
        ],
        "pkt6-received": [
            [
                0,
                "2023-06-13 21:28:57.177744"
            ]
        ],
        "pkt6-release-received": [
            [
                0,
                "2023-06-13 21:28:57.177744"
            ]
        ],
        "pkt6-renew-received": [
            [
                0,
                "2023-06-13 21:28:57.177745"
            ]
        ],
        "pkt6-reply-received": [
            [
                0,
                "2023-06-13 21:28:57.177745"
            ]
        ],
        "pkt6-reply-sent": [
            [
                0,
                "2023-06-13 21:28:57.177746"
            ]
        ],
        "pkt6-request-received": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-rfc-violation": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-sent": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-service-disabled": [
            [
                0,
                "2023-06-13 21:28:57.177747"
            ]
        ],
        "pkt6-solicit-received": [
            [
                0,
                "2023-06-13 21:28:57.177748"
            ]
        ],
        "pkt6-unknown-received": [
            [
                0,
                "2023-06-13 21:28:57.177748"
            ]
        ],
        "reclaimed-declined-addresses": [
            [
                0,
                "2023-06-13 21:28:57.196755"
            ]
        ],
        "reclaimed-leases": [
            [
                0,
                "2023-06-13 21:28:57.196756"
            ]
        ],
        "v6-allocation-fail": [
            [
                0,
                "2023-06-13 21:28:57.177749"
            ]
        ],
        "v6-allocation-fail-classes": [
            [
                0,
                "2023-06-13 21:28:57.177755"
            ]
        ],
        "v6-allocation-fail-no-pools": [
            [
                0,
                "2023-06-13 21:28:57.177756"
            ]
        ],
        "v6-allocation-fail-shared-network": [
            [
                0,
                "2023-06-13 21:28:57.177756"
            ]
        ],
        "v6-allocation-fail-subnet": [
            [
                0,
                "2023-06-13 21:28:57.177757"
            ]
        ],
        "v6-ia-na-lease-reuses": [
            [
                0,
                "2023-06-13 21:28:57.177757"
            ]
        ],
        "v6-ia-pd-lease-reuses": [
            [
                0,
                "2023-06-13 21:28:57.177758"
            ]
        ]
    },
    "result": 0
}

دستور statistic-reset تمام آمارها را به مقادیر خنثای آن‌ها بازنشانی می‌کند: 0 برای عدد صحیح (integer)، 0.0 برای ممیز شناور (float)، 0h0m0s0us برای بازه زمانی، و "" برای نوع رشته (string). یک نمونه دستور می‌تواند به این صورت باشد:

{
    "command": "statistic-reset-all",
    "arguments": { }
}

اگر عملیات موفقیت‌آمیز باشد، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا، سرور یک کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.

دستور statistic-remove-all برای حذف تمامی آمارها تلاش می‌کند. یک نمونه دستور می‌تواند به این صورت باشد:

{
    "command": "statistic-remove-all",
    "arguments": { }
}

اگر حذف تمامی آمارها موفقیت‌آمیز باشد، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا، سرور یک کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.

دستور statistic-sample-age-set یک محدودیت زمانی بر روی نمونه‌های یک آماره مشخص تنظیم می‌کند. این دستور دو پارامتر دریافت می‌کند: یک رشته به نام name که نام آماره را مشخص می‌کند، و یک مقدار عدد صحیح به نام duration که محدودیت زمانی آماره مشخص‌شده را بر حسب ثانیه تعیین می‌کند. یک نمونه دستور می‌تواند به این صورت باشد:

{
    "command": "statistic-sample-age-set",
    "arguments": {
        "name": "pkt4-received",
        "duration": 1245
    }
}

اگر دستور موفقیت‌آمیز باشد، سرور با وضعیت 0 به نشانه موفقیت و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا (مانند پیدا نشدن آماره درخواستی)، سرور کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.

دستور statistic-sample-age-set-all محدودیت‌های مبتنی بر زمان را بر روی نمونه‌های تمامی آمارها تنظیم می‌کند. این دستور یک پارامتر عدد صحیح به نام duration دریافت می‌کند که محدودیت زمانی آماره را بر حسب ثانیه تعیین می‌کند. یک نمونه دستور می‌تواند به این صورت باشد:

{
    "command": "statistic-sample-age-set-all",
    "arguments": {
        "duration": 1245
    }
}

اگر دستور موفقیت‌آمیز باشد، سرور با وضعیت 0 به نشانه موفقیت و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا، سرور یک کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.

دستور statistic-sample-count-set یک محدودیت مبتنی بر اندازه (تعداد) بر روی نمونه‌های یک آماره مشخص تنظیم می‌کند. یک نمونه دستور می‌تواند به این صورت باشد:

{
    "command": "statistic-sample-count-set",
    "arguments": {
        "name": "pkt4-received",
        "max-samples": 100
    }
}

اگر دستور موفقیت‌آمیز باشد، سرور با وضعیت 0 به نشانه موفقیت و یک فیلد parameters خالی پاسخ می‌دهد. در صورت بروز خطا (مانند پیدا نشدن آماره درخواستی)، سرور کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود..SS دستور statistic-sample-count-set-all

دستور statistic-sample-count-set-all محدودیت‌های مبتنی بر اندازه را بر روی نمونه‌های تمامی آمارها تنظیم می‌کند. یک نمونه از این دستور می‌تواند به شکل زیر باشد:

{
    "command": "statistic-sample-count-set-all",
    "arguments": {
        "max-samples": 100
    }
}

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

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

هر یک از آمارهای Kea تا ۲۰ نقطه داده را در خود نگه می‌دارند؛ تعیین چنین محدودیتی از رشد نامحدود حافظه جلوگیری می‌کند. دو روش برای تعیین محدودیت‌ها وجود دارد: بر پایه زمان (برای مثال، نگهداری نمونه‌های ۵ دقیقه گذشته) و بر پایه اندازه. محدودیت بر پایه اندازه را می‌توان با استفاده از یکی از دو دستور تغییر داد: statistic-sample-count-set، برای تعیین محدودیت اندازه برای یک آمار منفرد، و statistic-sample-count-set-all، برای تنظیم محدودیت‌های مبتنی بر اندازه برای تمامی آمارها. برای تنظیم محدودیت‌های بر پایه زمان برای یک آمار مشخص، از statistic-sample-age-set استفاده کنید؛ از statistic-sample-age-set-all نیز برای تعیین محدودیت‌های بر پایه زمان برای تمامی آمارها استفاده نمایید. برای هر آمار معین تنها یک نوع محدودیت می‌تواند فعال باشد؛ فضای ذخیره‌سازی یا بر پایه زمان محدود می‌شود یا اندازه، نه هر دو.

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

برای جلوگیری از چنین مشکلاتی، سرورهای DHCPv4، DHCPv6 و D2 در Kea از سازوکاری پشتیبانی می‌کنند که امکان پیکربندی مجدد به‌صورت برخط را بدون نیاز به خاموش کردن سرور فراهم می‌سازد. به سرورها می‌توان دستور داد تا سوکت‌های کنترلی را که یک کانال ارتباطی است باز کنند. سرور قادر است دستورها را روی این کانال دریافت کرده، آن‌ها را اجرا کند و وضعیت را گزارش دهد.

سرورهای DHCPv4، DHCPv6 و D2 دستورها را از طریق سوکت‌های دامنه یونیکس (UNIX domain sockets) دریافت می‌کنند. برای جزئیات بیشتر در مورد نحوه پیکربندی این سوکت‌ها، بخش‌های UNIX Control Socket <#dhcp4-unix-ctrl-channel>، UNIX Control Socket <#dhcp6-unix-ctrl-channel> و UNIX Control Socket <#d2-unix-ctrl-channel> را ببینید. در حالی که امکان کنترل مستقیم سرورها با استفاده از سوکت‌های دامنه یونیکس وجود دارد، اما این کار مستلزم آن است که کلاینت کنترل‌کننده روی همان ماشین سرور در حال اجرا باشد. معمولاً از SSH برای اتصال از راه دور به ماشین تحت کنترل استفاده می‌شود.

مدیران شبکه معمولاً ترجیح می‌دهند به جای استفاده مستقیم از سوکت‌های دامنه یونیکس، از نوعی RESTful API برای کنترل سرورها بهره ببرند. Kea نسخه ۳ سرورها را با سوکت‌های HTTP/HTTPS گسترش می‌دهد. برای جزئیات درباره نحوه پیکربندی این سوکت‌ها، بخش‌های HTTP/HTTPS Control Socket <#dhcp4-http-ctrl-channel>، HTTP/HTTPS Control Socket <#dhcp6-http-ctrl-channel> و HTTP/HTTPS Control Socket <#d2-http-ctrl-channel> را ببینید.

اتصال‌های کنترلی بر روی هر دو سوکت‌ HTTP و دامنه یونیکس با زمان‌های انتظار (timeout) محافظت می‌شوند. مقدار زمان انتظار روی ۱۰ ثانیه تنظیم شده و غیرقابل پیکربندی است.

این API می‌تواند توسط ابزارهای خارجی برای مدیریت و پایش عملکرد Kea مورد استفاده قرار گیرد. نمونه‌ای از این ابزارهای نظارتی، ISC Stork است. برای جزئیات، بخش Monitoring Kea With Stork <#stork> را ببینید.

ارتباط از طریق کانال کنترلی با استفاده از ساختارهای JSON انجام می‌شود. در صورت پیکربندی، Kea یک سوکت باز کرده و به اتصال‌های ورودی گوش می‌دهد. فرآیندی که به این سوکت متصل می‌شود باید دستورهای JSON را با ساختاری مانند زیر ارسال کند:

{
    "command": "foo",
    "arguments": {
        "param1": "value1",
        "param2": "value2",
        ...
    }
}

همان دستور هنگامی که از طریق رابط RESTful به سرور ارسال می‌شود دارای ساختار زیر است:

POST / HTTP/1.1\r\n
Content-Type: application/json\r\n
Content-Length: 147\r\n\r\n
{
    "command": "foo",
    "arguments": {
        "param1": "value1",
        "param2": "value2",
        ...
    }
}

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

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

{
    "result": 0, // 0|1|2|3|4
    "text": "textual description",
    "arguments": {
        "argument1": "value1",
        "argument2": "value2",
        ...
    }
}

مقدار result یک کد وضعیت است که نتیجه دستور را نشان می‌دهد. کدهای وضعیت عمومی زیر در حال حاضر پشتیبانی می‌شوند:

  • 0 - دستور با موفقیت پردازش شده است.
  • 1 - در حین پردازش دستور، یک خطا یا شکست عمومی رخ داده است.
  • 2 - دستور مشخص‌شده توسط سرور دریافت‌کننده پشتیبانی نمی‌شود.
  • 3 - عملیات درخواستی انجام شده است اما منبع درخواستی پیدا نشد. این کد وضعیت زمانی بازگردانده می‌شود که یک دستور هیچ منبعی را بازنگرداند یا بر هیچ منبعی تأثیر نگذارد.
  • 4 - دستور خوش‌ساخت پردازش شده است اما تغییرات درخواستی اعمال نشد، زیرا با وضعیت سرور یا درک آن از پیکربندی در تضاد بود.
  • 5 - دستور پردازش‌شده با شکست مواجه شد و پیکربندی به طور جزئی تغییر یافته است. سازوکار بازگردانی (rollback) قادر به بازگرداندن پیکربندی قبلی نبود.

برای نمونه، یک دستور با ساختار صحیح که زیرشبکه‌ای موجود در پیکربندی سرور را درخواست می‌کند، نتیجه 0 را بازمی‌گرداند. اگر سرور با وضعیت خطا مواجه شود، 1 را بازمی‌گرداند. اگر دستور یک زیرشبکه IPv6 را درخواست کند، اما به سرور DHCPv4 ارسال شده باشد، نتیجه 2 خواهد بود. اگر پرس‌وجو به دنبال زیرشبکه‌ای با subnet-id باشد که تطابقی دارد، نتیجه 3 است. اگر دستور تلاش کند یک اجاره (lease) را به‌روزرسانی کند اما subnet-id مشخص‌شده با شناسه موجود در پیکربندی سرور مطابقت نداشته باشد، نتیجه 4 خواهد بود.

کتابخانه‌های هوک (Hook libraries) گاهی اوقات می‌توانند کدهای وضعیت بیشتری متناسب با شرایط استفاده خود بازگردانند.

فیلد text معمولاً هنگامی ظاهر می‌شود که نتیجه غیرصفر باشد و حاوی شرح خطای رخ‌داده است، اما اغلب برای نتایج موفقیت‌آمیز نیز نمایش می‌یابد. متن دقیق مختص هر دستور است، اما به‌طور کلی از متن واضح انگلیسی برای توصیف نتیجه دستور استفاده می‌کند. نگاشت arguments شامل مقادیر داده‌های اضافی بازگردانده‌شده توسط سرور است که مختص دستور صادرشده می‌باشد. ممکن است این نگاشت وجود داشته باشد، اما این به دستور مربوطه بستگی دارد.

نکته:

از نسخه 1.9.7 Kea، همانند فایل پیکربندی، امکان قرار دادن کامنت در دستورها نیز وجود دارد. برای نمونه:
{
    "command": "foo",
    # command arguments are here.
    "arguments": {
        "param1": "value1",
        ...
        /*
        "param2": "value2",
        ...
        */
    }
}

نکته:

از نسخه 2.7.5 Kea، امکان تعیین سرآیندهای (headers) اضافی HTTP که به پاسخ‌های HTTP افزوده می‌شوند، وجود دارد. هر سرآیند با نام و مقدار خود و به‌صورت اختیاری یک زمینه کاربری (user context) مشخص می‌شود. برای نمونه:
{
    "http-headers": [
        {
            "name": "Strict-Transport-Security",
            "value": "max-age=31536000"
        }
     ],
 ...
 }

یک سرآیند HSTS اضافه می‌کند که اعلام می‌دارد HTTPS (در مقایسه با HTTP) باید به مدت یک سال استفاده شود..SS قالب پاسخ دستور HTTP

برای سازگاری با نسخه‌های پیشین با Control Agent منسوخ‌شده (حذف‌شده)، پاسخ‌های دریافتی از طریق HTTP همواره درون یک آرایه (فهرست JSON) تک‌عضوی قرار می‌گیرند.

برای نمونه، پاسخ برای یک دستور ارسال‌شده ساختاری به شرح زیر خواهد داشت:

[
    {
        "result": 0, // 0|1|2|3|4
        "text": "textual description",
        "arguments": {
            "argument1": "value1",
            "argument2": "value2",
            ...
        }
    }
]

یک استثنا برای این مورد، خطاهای احراز هویت یا تعیین سطح دسترسی هستند که باعث می‌شوند سرور دستور را به طور کامل رد کند. پاسخ به چنین خطایی در قالب یک مدخل تکی (نگاشت JSON) به شرح زیر ساختاردهی می‌شود:

{
    "result": 403,
    "text": "Forbidden"
}

این نوع خطاها روی سیستم‌هایی که برای احراز هویت اولیه (basic authentication) پیکربندی شده‌اند یا سرورهایی که libdhcp_rbac.so <#std-ischooklib-libdhcp_rbac.so> را بارگذاری می‌کنند، امکان‌پذیر است.

ساده‌ترین راه برای شروع تعامل با API کنترل، استفاده از ابزارهای متداول UNIX/Linux مانند socat و curl است.

به منظور کنترل سرویس مورد نظر Kea از طریق یک UNIX domain socket، از socat در حالت تعاملی به شرح زیر استفاده کنید:

$ socat UNIX:/path/to/the/kea/socket -

یا در حالت دسته‌ای (batch mode)، گزینه "ignoreeof" را همانند زیر درج کنید تا اطمینان حاصل شود socat به اندازه کافی منتظر پاسخ سرور می‌ماند:

$ echo "{ some command...}" | socat UNIX:/path/to/the/kea/socket -,ignoreeof

که در آن /path/to/the/kea/socket مسیری است که در پارامتر Dhcp4/control-socket/socket-name در فایل پیکربندی Kea مشخص شده است. متن ارسال‌شده به socat به Kea فرستاده می‌شود و پاسخ‌های دریافتی از Kea در خروجی استاندارد چاپ می‌شوند. این روش به طور مستقیم با سرور مورد نظر ارتباط برقرار می‌کند.

همچنین باز کردن برنامه‌نویسی‌شده‌ی یک سوکت UNIX آسان است. نمونه‌ای از یک کلاینت ساده که به زبان C نوشته شده است در Kea Developer's Guide، در فصل Control Channel Overview و در بخش Using Control Channel https://reports.kea.isc.org/dev_guide/d2/d96/ctrlSocket.html#ctrlSocketClient در دسترس است.

برای استفاده از RESTful API نرم‌افزار Kea با curl، دستور زیر را به کار ببرید:

$ curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get" }' http://kea.example.org:8000

این دستور فرض می‌کند که سرور روی میزبان kea.example.org در حال اجرا بوده و سرویس RESTful را روی درگاه 8000 اجرا می‌کند.

دستور build-report همان چیزی را که آرگومان خط فرمان -W نمایش می‌دهد روی کانال کنترل بازمی‌گرداند؛ یعنی محتوای تعبیه‌شده در فایل config.report. این دستور هیچ پارامتری دریافت نمی‌کند.

{
    "command": "build-report"
}

دستور config-get پیکربندی فعلی مورد استفاده توسط سرور را بازیابی می‌کند. این دستور هیچ پارامتری دریافت نمی‌کند. پیکربندی بازگردانده‌شده تقریباً معادل پیکربندی است که با استفاده از گزینه خط فرمان -c در زمان راه‌اندازی سرور بارگذاری شده بود، یا بعداً با استفاده از دستور config-set تنظیم شده است. با این حال، ممکن است تفاوت‌های خاصی وجود داشته باشد، زیرا کامنت‌ها نگهداری نمی‌شوند. اگر در پیکربندی اصلی از گنجاندن فایل (file inclusion) استفاده شده باشد، پیکربندی بازگردانده‌شده شامل تمام پارامترها از همه فایل‌های گنجانده‌شده خواهد بود. در Kea 2.4.0 و نسخه‌های بعدی، پاسخ موفقیت‌آمیز همچنین حاوی یک خلاصه (digest) از نوع SHA-256 است که می‌توان از آن برای تشخیص آسان تغییر پیکربندی استفاده کرد.

هشدار:

پیکربندی بازگردانده‌شده پنهان‌سازی (redact) نمی‌شود؛ یعنی اگر گذرواژه‌های پایگاه داده در پیکربندی اصلی مشخص شده باشند، به صورت متن خام (plain text) خواهند بود. باید دقت شود که کانال دستور در دسترس کاربران بدون امتیاز قرار نگیرد.

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

{
    "command": "config-get"
}

دستور config-hash-get هش SHA-256 پیکربندی فعلی مورد استفاده توسط کارگزار را بازیابی می‌کند. این دستور هیچ پارامتری دریافت نمی‌کند. هش بازگردانده‌شده می‌تواند برای تشخیص تغییرات پیکربندی استفاده شود.

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

{
    "command": "config-hash-get"
}

و پاسخ کارگزار:

{
    "result": 0,
    "arguments": {
        "hash": "5C3C90EF7035249E2FF74D003C19F34EE0B83A3D329E741B52B2EF95A2C9CC5C"
     }
 }

در Kea نسخه 2.4.0 و بالاتر، دستورهای config-set و config-get نیز هش SHA-256 پیکربندی جدید یا فعلی را برمی‌گردانند. این ویژگی می‌تواند برای تشخیص اینکه آیا پیکربندی تغییر کرده است یا خیر استفاده شود.

دستور config-reload به Kea فرمان می‌دهد که فایل پیکربندی قبلی را دوباره بارگذاری کند. این عملیات در صورتی مفید است که فایل پیکربندی توسط یک منبع خارجی تغییر کرده باشد؛ برای مثال، یک مدیر سیستم می‌تواند فایل پیکربندی را دستکاری کند و از این دستور برای واداشتن Kea به اعمال تغییرات استفاده نماید.

هنگام استفاده از این دستور همراه با دستور config-set باید احتیاط کرد. Kea مکان فایل پیکربندی را که با آن راه‌اندازی شده بود به خاطر می‌سپارد، و این پیکربندی می‌تواند از طریق دستور config-set دچار تغییرات چشمگیری شده باشد. هنگامی که config-reload پس از config-set صادر شود، Kea تلاش می‌کند پیکربندی اولیه خود را دوباره از فایل بارگذاری کند، که در نتیجه آن ممکن است تمام تغییرات اعمال‌شده از طریق config-set یا سایر دستورها از دست برود.

دستور config-reload هیچ پارامتری دریافت نمی‌کند. نمونه‌ای از فراخوانی دستور به این صورت است:

{
    "command": "config-reload"
}

اگر فایل پیکربندی نادرست باشد، بارگذاری مجدد آن می‌تواند منجر به بروز خطایی شود که کارگزار را در وضعیتی غیرقابل استفاده رها می‌کند. برای یادگیری نحوه بازیابی از وضعیت کارگزار از کار افتاده، به بخش دستور config-set مراجعه کنید.

دستور config-test به کارگزار فرمان می‌دهد بررسی کند که آیا پیکربندی جدید ارائه‌شده در آرگومان‌های دستور قابل بارگذاری است یا خیر. انتظار می‌رود پیکربندی ارائه‌شده، پیکربندی کامل کارگزار مورد نظر به همراه پیکربندی اختیاری ثبات وقایع (logger) باشد. پیکربندی تا حد امکان بدون تلاش واقعی کارگزار برای بارگذاری آن اعتبارسنجی (sanity-check) می‌شود؛ با این حال ممکن است پیکربندی‌ای که این دستور را با موفقیت پشت سر می‌گذارد، همچنان در دستور config-set یا هنگام راه‌اندازی با خطا مواجه شود. ساختار دستور به صورت زیر است:

{
    "command": "config-test",
    "arguments":  {
        "<server>": {
        }
    }
}

که در آن <server> نام مؤلفه پیکربندی برای یک کارگزار معین، مانند "Dhcp4" یا "Dhcp6" است. برای مثال:

{
    "command": "config-test",
    "arguments":  {
        "Dhcp6": {
            ...
        }
    }
}

پاسخ کارگزار شامل یک کد عددی به نام result (صفر برای موفقیت، غیر صفر در صورت شکست)، و یک رشته به نام text است که نتیجه را شرح می‌دهد:

{ "result": 0, "text": "Configuration seems sane..." }
یا
{ "result": 1, "text": "unsupported parameter: BOGUS (<string>:16:26)" }

دستور config-write به کارساز Kea اعلام می‌کند که پیکربندی فعلی خود را درون فایلی روی دیسک بنویسد. این دستور یک آرگومان اختیاری به نام "filename" می‌پذیرد که نام فایل مقصد برای نوشتن پیکربندی را مشخص می‌کند. در صورت عدم تعیین، از نام استفاده‌شده در هنگام راه‌اندازی Kea (که به عنوان آرگومان -c داده شده است) استفاده می‌شود. اگر یک مسیر نسبی تعیین شود، Kea فایل‌های خود را فقط در دایرکتوری محل اجرای خود می‌نویسد.

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

{
    "command": "config-write",
    "arguments": {
        "filename": "config-modified-2017-03-15.json"
    }
}

نکته:

از نسخه 2.7.9 Kea به بعد، فایل پیکربندی تنها می‌تواند در همان دایرکتوری فایل پیکربندی اولیه استفاده‌شده هنگام راه‌اندازی Kea (که به عنوان آرگومان -c داده شده است) نوشته شود.

دستور leases-reclaim به کارساز دستور می‌دهد که تمام اجاره‌های منقضی‌شده را فوراً بازپس‌گیری کند. این دستور ساختار نحوی JSON زیر را دارد:

{
    "command": "leases-reclaim",
    "arguments": {
        "remove": true
    }
}

پارامتر بولی remove اجباری است و مشخص می‌کند که آیا اجاره‌های بازپس‌گرفته‌شده باید از پایگاه‌داده اجاره‌ها حذف شوند (در صورت true)، یا در وضعیت expired-reclaimed باقی بمانند (در صورت false). حالت دوم قابلیت وابستگی اجاره (lease affinity) را تسهیل می‌کند؛ یعنی امکان تخصیص مجدد یک اجاره منقضی‌شده به یک کلاینت بازگشتی که پیش‌تر از آن اجاره استفاده می‌کرده است. برای جزئیات به Configuring Lease Affinity <#lease-affinity> مراجعه کنید. همچنین، برای اطلاعات عمومی درباره پردازش اجاره‌های منقضی‌شده (بازپس‌گیری اجاره)، به Lease Reclamation <#lease-reclamation> مراجعه نمایید.

دستور interface-add فهرست رابط‌های استفاده‌شده برای پردازش ترافیک DHCP را به‌روزرسانی می‌کند. این دستور فهرستی از رابط‌ها را به همراه آدرس‌های مربوطه (در صورت تعیین) که کارساز باید شنود ترافیک DHCP را روی آن‌ها آغاز کند، به عنوان پارامتر دریافت می‌کند. اگر مدخل‌های تکراری در فهرست دستور وجود داشته باشند یا مدخل‌های موجود در پیکربندی در حال اجرا را تکرار کنند، این مدخل‌ها هیچ تأثیری بر پیکربندی جدید نخواهند داشت.

نکته:

این دستور تنها می‌تواند به فهرست موجود رابط‌ها اضافه کند. هیچ راهی برای حذف یک رابط پس از اضافه شدن آن و شروع شنود ترافیک DHCP توسط کارساز وجود ندارد.

لطفاً توجه داشته باشید که پیکربندی جدید تنها در حافظه نگهداری می‌شود؛ اگر کارساز بازراه‌اندازی شود یا بارگذاری مجدد پیکربندی از طریق یک سیگنال صورت گیرد، کارساز از پیکربندی ذخیره‌شده در فایل پیکربندی خود استفاده خواهد کرد. پاسخ کارساز شامل یک کد عددی، result (۰ برای موفقیت و غیر صفر برای شکست)، و یک رشته، text، است که نتیجه را توصیف می‌کند:

{ "result": 0, "text": "Interface configuration successfully updated." }

پیکربندی به‌روزرسانی‌شده همچنین می‌تواند با استفاده از دستور config-get (درون مپ پیکربندی "interfaces-config") بازیابی شود.

دستور interface-list فهرست رابط‌های شناسایی‌شده را بازیابی می‌کند. این دستور هیچ پارامتری نمی‌پذیرد.

دستور interface-redetect پس از اجرای یک روند شناسایی مجدد که تنها رابط‌ها و آدرس‌های جدیداً کشف‌شده را اضافه می‌کند، بدون آنکه رابط‌ها یا آدرس‌های شناسایی‌شده قبلی را حذف کند، فهرست رابط‌های شناسایی‌شده را بازیابی می‌نماید. این دستور هیچ پارامتری دریافت نمی‌کند."

دستور list-commands فهرستی از تمام دستورهای پشتیبانی‌شده توسط کارساز را بازیابی می‌کند. این دستور هیچ آرگومانی نمی‌پذیرد. یک نمونه فراخوانی ممکن است به شکل زیر باشد:

{
    "command": "list-commands",
    "arguments": { }
}

کارساز با فهرستی از تمامی دستورهای پشتیبانی‌شده پاسخ می‌دهد. عنصر arguments فهرستی از رشته‌ها است که هر کدام نشان‌دهنده یک دستور پشتیبانی‌شده است..SS دستور config-set

دستور config-set به سرور اعلام می‌کند که پیکربندی فعلی خود را با پیکربندی جدید ارائه‌شده در آرگومان‌های دستور جایگزین کند. انتظار می‌رود پیکربندی ارائه‌شده، پیکربندی کامل سرور مورد نظر به همراه پیکربندی اختیاری ثبات وقایع (logger) باشد. اگرچه پیکربندی logger اختیاری است، اکیداً توصیه می‌شود؛ چرا که بدون آن سرور به پیکربندی پیش‌فرض ثبت وقایع خود بازمی‌گردد. ساختار دستور به شرح زیر است:

{
    "command": "config-set",
    "arguments":  {
        "<server>": {
        }
    }
}

که در آن <server> نام مؤلفه پیکربندی برای یک سرور مشخص است، مانند "Dhcp4" یا "Dhcp6". برای مثال:

{
    "command": "config-set",
    "arguments":  {
        "Dhcp6": {
            ...
        }
    }
}

چنانچه نامعتبر بودن پیکربندی جدید محرز شود، سرور پیکربندی فعلی خود را حفظ می‌کند؛ با این حال، در برخی موارد یک پیام خطای مهلک ثبت می‌شود که نشان می‌دهد سرور دیگر هیچ سرویسی ارائه نمی‌دهد: در این شرایط باید در اسرع وقت یک پیکربندی کارآمد بارگذاری شود. در صورتی که کانال کنترل (control channel) از کار افتاده باشد، همچنان می‌توان با استفاده از سیگنال SIGHUP فایل پیکربندی را مجدداً بارگذاری کرد. اگر این روش نیز ناموفق بود، سرور را مجدداً راه‌اندازی کنید.

لطفاً توجه داشته باشید که پیکربندی جدید تنها در حافظه نگه‌داری می‌شود؛ اگر سرور مجدداً راه‌اندازی شود یا بارگذاری مجدد پیکربندی از طریق یک سیگنال فعال گردد، سرور از پیکربندی ذخیره‌شده در فایل پیکربندی خود استفاده خواهد کرد. پاسخ سرور شامل یک کد عددی به نام result (صفر برای موفقیت، و مقداری غیر صفر در صورت شکست) و یک رشته متنی به نام text است که نتیجه را شرح می‌دهد:

{ "result": 0, "text": "Configuration successful." }
یا
{ "result": 1, "text": "unsupported parameter: BOGUS (<string>:16:26)" }

در Kea 2.4.0 و نسخه‌های بعدی، پاسخ موفقیت‌آمیز دریافتی از دیمن‌های DHCPv4، DHCPv6، یا DHCP-DDNS همچنین حاوی یک خلاصه درهم‌ساز (digest) از نوع SHA-256 از پیکربندی جدید اعمال‌شده است. از این خلاصه می‌توان به‌سادگی برای تشخیص اینکه آیا پیکربندی تغییر کرده است یا خیر استفاده کرد.

دستور shutdown به سرور دستور می‌دهد تا روال خاموش شدن خود را آغاز کند؛ این دستور معادل ارسال سیگنال SIGTERM به فرایند است. این دستور هیچ آرگومانی نمی‌پذیرد. یک نمونه دستور ممکن است به شکل زیر باشد:

{
    "command": "shutdown",
    "arguments": {
        "exit-value": 3
    }
}

سرور با تأییدیه‌ای مبنی بر آغاز شدن فرایند خاموش‌سازی پاسخ می‌دهد. پارامتر اختیاری exit-value مقدار عددی خروج فرایند سرور به سیستم را مشخص می‌کند. مقدار پیش‌فرض صفر است.

دیمن DDNS از یک پارامتر اضافی به نام type پشتیبانی می‌کند که نحوه پاک‌سازی فرایند هنگام خروج را کنترل می‌نماید. حالت‌های خاموش‌سازی پشتیبانی‌شده عبارتند از:

  • "normal" - مدیر صف را متوقف کرده و قبل از خروج، تمامی تراکنش‌های جاری را به پایان می‌رساند. این حالت پیش‌فرض است.
  • "drain_first" - مدیر صف را متوقف می‌کند، اما به پردازش درخواست‌های درون صف تا خالی شدن کامل آن ادامه می‌دهد.
  • "now" - فوراً خارج می‌شود.

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

{
    "command": "shutdown",
    "arguments": {
        "exit-value": 3,
        "type": "drain_first"
    }
}

دستور dhcp-disable سرویس DHCP را به‌طور سراسری غیرفعال می‌کند. کارکرد کارساز ادامه می‌یابد، اما تمام پیام‌های دریافتی DHCP را دور می‌اندازد (drop می‌کند). این دستور زمانی مفید است که نگهداری کارساز مستلزم آن باشد که کارساز موقتاً تخصیص اجاره‌های جدید و تمدید اجاره‌های موجود را متوقف کند. همچنین در پیکربندی‌های مشابه failover در طول همگام‌سازی پایگاه‌های داده اجاره هنگام راه‌اندازی، یا بازیابی پس از خرابی مفید است. پارامتر اختیاری max-period مدت زمان بر حسب ثانیه را مشخص می‌کند که پس از آن سرویس DHCP باید به‌طور خودکار دوباره فعال شود، چنانچه دستور dhcp-enable پیش از سپری شدن این زمان ارسال نشده باشد.

از Kea 1.9.4، یک پارامتر اضافی به نام origin وجود دارد که منبع دستور را مشخص می‌کند. مدیر کارساز معمولاً باید این پارامتر را نادیده بگیرد، زیرا مقدار پیش‌فرض "user" نشان‌دهنده آن است که مدیر دستور را ارسال کرده است. در Kea نسخه ۲.۵.۵ تا ۲.۵.۷، این پارامتر همچنین در ارتباط میان شرکای HA برای مشخص کردن شناسه سرویس HA ارسال‌کننده دستور در قالب عددی به کار می‌رفت. با این حال، به دلیل مسائل سازگاری با نسخه‌های قدیمی‌تر Kea که مقادیر عددی را به‌درستی تجزیه نمی‌کردند، معرفی پارامتر جدید origin-id در Kea 2.5.8 ضروری شد.

این پارامتر حاوی یک مقدار عددی است که منشأ دستور را نشان می‌دهد. همان مقدار را همچنان می‌توان با استفاده از پارامتر origin ارسال کرد، اما ممکن است باعث مسائل سازگاری یادشده میان شرکای HA با نسخه‌های متفاوت Kea شود؛ اگر از هر دو استفاده شود، origin-id اولویت دارد. نسخه‌های جدید Kea استفاده از origin-id را در ارتباط میان شرکای HA ترجیح می‌دهند، اما در کل توصیه می‌شود هر دو پارامتر نادیده گرفته شوند و از مقدار پیش‌فرض استفاده شود.

کدهای زیر منشأهای پشتیبانی‌شده را در قالب عددی نشان می‌دهند:

  • 1 - یک دستور کاربری؛ معادل با تعیین "origin": "user".
  • 2000، 2001، 2002 و غیره - منشأهای تعیین‌شده توسط شرکای HA که در آن مقادیر افزایشی بالای 2000، شناسه‌های متمایز سرویس HA هستند که در صورت وجود روابط متعدد میان شرکا استفاده می‌شوند.

در مثال زیر:

{
    "command": "dhcp-disable",
    "arguments": {
        "max-period": 20,
        "origin-id": 2002,
        "origin": "user"
    }
}

منشأ مؤثر 2002 است، که نشان می‌دهد یکی از شرکای HA در حال ارسال دستور برای سرویسی با شناسه 2 است. در این حالت، پارامتر origin نادیده گرفته خواهد شد.

دستور dhcp-enable سرویس DHCP را به‌طور سراسری فعال می‌کند.

از Kea 1.9.4، یک پارامتر اضافی به نام origin وجود دارد که منبع دستور را مشخص می‌کند. مدیر کارساز معمولاً باید این پارامتر را نادیده بگیرد، زیرا مقدار پیش‌فرض "user" نشان می‌دهد که مدیر دستور را ارسال کرده است. در Kea نسخه ۲.۵.۵ تا ۲.۵.۷، این پارامتر همچنین در ارتباط میان شرکای HA برای مشخص کردن شناسه سرویس HA ارسال‌کننده دستور در قالب عددی استفاده می‌شد. با این حال، به دلیل مسائل سازگاری با نسخه‌های قدیمی‌تر Kea که مقادیر عددی را به‌درستی تجزیه نمی‌کردند، معرفی پارامتر جدید origin-id در Kea 2.5.8 ضروری شد.

این پارامتر حاوی یک مقدار عددی است که منشأ دستور را نشان می‌دهد. همان مقدار را همچنان می‌توان با استفاده از پارامتر origin ارسال کرد، اما می‌تواند باعث ایجاد مسائل سازگاری یادشده میان شرکای HA با نسخه‌های متفاوت Kea شود؛ اگر از هر دو استفاده شود، origin-id اولویت دارد. نسخه‌های جدید Kea استفاده از origin-id را در ارتباط میان شرکای HA ترجیح می‌دهند، اما در کل توصیه می‌شود هر دو پارامتر نادیده گرفته شوند و از مقدار پیش‌فرض استفاده شود.

کدهای زیر منشأهای پشتیبانی‌شده را در قالب عددی نشان می‌دهند:

  • 1 - یک دستور کاربری؛ معادل با تعیین "origin": "user".
  • 2000، 2001، 2002 و غیره - منشأهای تعیین‌شده توسط شرکای HA که در آن مقادیر افزایشی بالای 2000، شناسه‌های متمایز سرویس HA هستند که در صورت وجود روابط متعدد میان شرکا استفاده می‌شوند.

در مثال زیر:

{
    "command": "dhcp-enable",
    "arguments": {
        "origin-id": 2002,
        "origin": "user"
    }
}

منشأ مؤثر 2002 است، که نشان می‌دهد یکی از شرکای HA در حال ارسال دستور برای سرویسی با شناسه 2 است. در این حالت، پارامتر origin نادیده گرفته خواهد شد.

دستور status-get اطلاعات زمان اجرای کارساز را برمی‌گرداند:

  • pid: شناسه فرایند (PID).
  • uptime: تعداد ثانیه‌های سپری‌شده از زمان شروع به کار کارساز.
  • reload: تعداد ثانیه‌های سپری‌شده از آخرین بارگذاری (مجدد) پیکربندی.
  • high-availability: اطلاعات وضعیت مختص HA درباره کارسازهای DHCP پیکربندی‌شده برای استفاده از کتابخانه قلاب (hook) مربوط به HA:
  • local: وضعیت، نقش (primary، secondary و...)، و دامنه‌های (یعنی آنچه کارساز عملاً در حال پردازش آن است) کارساز محلی.
  • remote: آخرین وضعیت شناخته‌شده کارساز دوردست، دامنه‌های HA ارائه‌شده توسط آن، و نقش کارساز دوردست در رابطه HA.
  • multi-threading-enabled: پرچمی که نشان می‌دهد آیا چندنخی فعال است یا خیر.
  • thread-pool-size: تعداد نخ‌های سرویس DHCP.
  • packet-queue-size: حداکثر اندازه صف بسته‌ها. صرف‌نظر از تعداد نخ‌های در حال اجرا، تنها یک صف وجود دارد.
  • packet-queue-statistics: میانگین اندازه صف برای ۱۰، ۱۰۰ و ۱۰۰۰ بسته آخر، با استفاده از رویکردی مشابه با دستور top در UNIX. میانگین اندازه صف برای ۱۰ بسته آخر را می‌توان یک مقدار لحظه‌ای در نظر گرفت، در حالی که میانگین برای ۱۰۰۰ بسته آخر روندی بلندمدت‌تر را نشان می‌دهد.

اطلاعات high-availability تنها زمانی بازگردانده می‌شود که دستور به کارسازهای DHCP در یک راه‌اندازی HA ارسال شود. این پارامتر هنگامی که دستور status-get به دیمن DDNS ارسال شود، هرگز بازگردانده نمی‌شود.

پارامترهای thread-pool-size، packet-queue-size و packet-queue-statistics تنها زمانی بازگردانده می‌شوند که دستور به کارسازهای DHCP با چندنخی فعال ارسال شود. این سه پارامتر و multi-threading-enabled هرگز هنگامی که دستور status-get به دیمن DDNS ارسال شود، بازگردانده نمی‌شوند.

برای کسب اطلاعات بیشتر درباره وضعیت HA بازگردانده‌شده توسط دستور status-get، لطفاً به بخش دستور status-get <#command-ha-status-get> مراجعه کنید..SS دستور server-tag-get:

دستور server-tag-get برچسب کارگزار (server tag) پیکربندی‌شده برای کارگزار DHCPv4 یا DHCPv6 را بازمی‌گرداند (بخش Configuration Sharing and Server Tags <#cb-sharing> مفهوم server tag را شرح می‌دهد).

دستور config-backend-pull بررسی دوره‌ای (polling) بک‌اندهای پیکربندی را آغاز می‌کند (که برای اثربخشی این دستور باید پیکربندی شده باشند)، همان‌طور که در Enabling the Configuration Backend <#dhcp4-cb-json> توضیح داده شده است.

دستور version-get اطلاعات گسترش‌یافته‌ای را دربارهٔ نسخهٔ Kea بازمی‌گرداند؛ این همان اطلاعاتی است که از طریق آرگومان خط فرمان -V در دسترس است. این دستور هیچ پارامتری دریافت نمی‌کند.

{
    "command": "version-get"
}

دستور kea-lfc-start فرایند kea-lfc را آغاز می‌کند که فایل اجاره‌ها را پاک‌سازی می‌نماید (بخش The LFC Process <#kea-lfc> را ببینید). این دستور هیچ آرگومانی نمی‌پذیرد و در مواردی که بک‌اند اجاره memfile نباشد، پارامتر persist در lease-database روی false پیکربندی شده باشد (اما نه زمانی که lfc-interval برابر با 0 است)، تشخیص دهد که یک فرایند LFC در حال حاضر در حال اجرا است، یا خطایی مانع از آغاز یک فرایند LFC جدید شود، وضعیت موفقیت‌آمیز را برنمی‌گرداند.

دستور subnet4-select-test روشی را برای آزمایش انتخاب زیرشبکهٔ DHCPv4 بر اساس مجموعه‌ای از پارامترهای ورودی فراهم می‌کند که معمولاً در بستهٔ کارخواه ارائه می‌شوند. پارامترهای شناخته‌شده رشته دریافت می‌کنند و عبارتند از:

  • interface - نام رابط ورودی
  • address - نشانی کارخواه
  • relay - نشانی رله/دروازه
  • local - نشانی محلی/مقصد
  • remote - نشانی دوردست/مبدأ
  • link - نشانی link-selection مربوط به RAI
  • subnet - نشانی subnet-selection
  • classes - (فهرستی از رشته‌ها) کلاس‌های کارخواه (جهت امکان انتخاب یک زیرشبکهٔ حفاظت‌شده)

هنگامی که پرچم سازگاری ignore-rai-link-selection برابر با true باشد، RAI link-selection نادیده گرفته می‌شود. هنگامی که نادیده گرفته نشود، نسبت به subnet-selection اولویت دارد.

صرف‌نظر از خطاها، نتایج احتمالی عبارتند از:

  • (خالی) "no selected subnet"
  • "selected shared network '<name>' starting with subnet '<subnet>' id <id>"
  • "selected subnet '<subnet>' id <id>"

دستور subnet4o6-select-test روشی را برای آزمایش انتخاب زیرشبکهٔ DHCPv4-over-DHCPv6 بر اساس مجموعه‌ای از پارامترهای ورودی فراهم می‌کند که معمولاً در بستهٔ کارخواه ارائه می‌شوند. پارامترهای شناخته‌شده رشته دریافت می‌کنند و عبارتند از:

  • interface - نام رابط ورودی کارگزار DHCPv6
  • interface-id - محتوای دودویی گزینهٔ رلهٔ interface-id
  • address - نشانی کارخواه
  • relay - نشانی رله/دروازه
  • local - نشانی محلی/مقصد
  • remote - نشانی IPv6 دوردست/مبدأ کارگزار DHCPv6
  • link - نشانی IPv6 اولین پیوند رله
  • subnet - نشانی subnet-selection
  • classes - (فهرستی از رشته‌ها) کلاس‌های کارخواه (جهت امکان انتخاب یک زیرشبکهٔ حفاظت‌شده)

طبق کد، تنها گزینش‌گرهای remote، interface-id و interface استفاده می‌شوند. در پیاده‌سازی DHCPv4-over-DHCPv6 مقادیر interface و remote از کارگزار DHCPv6 منتقل می‌شوند، interface-id و link در بخش اطلاعات رلهٔ بستهٔ DHCPv6 حمل می‌شوند و در نتیجه مانند کارگزار DHCPv6 هستند.

صرف‌نظر از خطاها، نتایج احتمالی عبارتند از:

  • (خالی) "no selected subnet"
  • "selected shared network '<name>' starting with subnet '<subnet>' id <id>"
  • "selected subnet '<subnet>' id <id>"

دستور subnet6-select-test روشی را برای آزمایش انتخاب زیرشبکه DHCPv6 بر اساس مجموعه‌ای از پارامترهای ورودی که معمولاً در بسته کارخواه (client) ارائه می‌شوند، فراهم می‌کند. پارامترهای شناخته‌شده رشته می‌پذیرند و عبارتند از:

  • interface - نام رابط ورودی
  • interface-id - محتوای دودویی گزینه بازپخش (relay) مربوط به interface-id
  • remote - نشانی دوردست/مبدأ
  • link - نخستین نشانی پیوند رله
  • classes - (فهرستی از رشته‌ها) کلاس‌های کارخواه (جهت امکان انتخاب یک زیرشبکه محافظت‌شده)

جدا از خطاها، نتایج احتمالی عبارتند از:

  • (خالی) "no selected subnet"
  • "selected shared network '<name>' starting with subnet '<subnet>' id <id>"
  • "selected subnet '<subnet>' id <id>"

کارساز D2 تنها از زیرمجموعه‌ای از دستورات کارسازهای DHCPv4/DHCPv6 پشتیبانی می‌کند:

  • build-report
  • config-get
  • config-hash-get
  • config-reload
  • config-set
  • config-test
  • config-write
  • list-commands
  • shutdown
  • status-get
  • version-get

از نسخه 2.7.2 Kea، کارسازهای DHCP از کانال‌های کنترلی HTTP/HTTPS پشتیبانی می‌کنند؛ بنابراین به Control Agent (CA) دیگر نیازی نیست، و از نسخه 3.1.8 Kea، این مؤلفه (CA) به‌طور کامل حذف شده است.

کارسازهای DHCPv4، DHCPv6 و D2 مدخل control-socket را به فهرست control-sockets گسترش داده‌اند. برای مهاجرت پیکربندی CA، عنصری را با مشخصات زیر به این فهرست اضافه کنید:

  • socket-type تنظیم‌شده روی http یا https
  • socket-address با محتوای http-host مربوط به CA
  • socket-port با محتوای http-port مربوط به CA
  • trust-anchor (بدون تغییر)
  • cert-file (بدون تغییر)
  • key-file (بدون تغییر)
  • cert-required (بدون تغییر)
  • authentication (بدون تغییر)

بافتار کاربر (User context) نیز پشتیبانی می‌شود. لطفاً برای مقادیر پیش‌فرض و سایر جزئیات، بخش‌های مربوط به سوکت کنترلی HTTP را ببینید: سوکت کنترلی HTTP/HTTPS برای DHCP4 <#dhcp4-http-ctrl-channel>، سوکت کنترلی HTTP/HTTPS برای DHCP6 <#dhcp6-http-ctrl-channel> و سوکت کنترلی HTTP/HTTPS برای DHCP-DDNS <#d2-http-ctrl-channel>.

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

به‌منظور حفظ سازگاری، نتیجه JSON این سوکت‌های کنترلی HTTP/HTTPS همچنان درون یک فهرست کپسوله‌سازی می‌شود.

در طول اجرای برنامه، Kea ممکن است پیام‌های ثبتی (log) متعددی ایجاد کند. این پیام‌ها از نظر سطح اهمیت (برخی مهم‌تر از بقیه هستند) و منبع تولید (مؤلفه‌های مختلف، مانند قلاب‌ها، پیام‌های متفاوتی صادر می‌کنند) فرق دارند. آگاهی از اینکه کدام پیام‌ها حیاتی و کدام غیرحیاتی هستند و پیکربندی متناسب سازوکار ثبت وقایع بسیار مفید است. برای نمونه، پیام‌های سطح اشکال‌زدایی (debug-level) را می‌توان با اطمینان در یک استقرار عادی نادیده گرفت. هرچند، این پیام‌ها هنگام عیب‌یابی یک مشکل بسیار کارآمد هستند.

سامانه ثبت وقایع در Kea از طریق مدخل loggers در بخش server فایل پیکربندی تنظیم می‌شود.

در Kea، پیام‌ها از طریق موجودیتی موسوم به "logger" (ثبت‌کننده) ثبت می‌شوند. مؤلفه‌های گوناگون پیام‌ها را از طریق ثبت‌کننده‌های مختلفی به ثبت می‌رسانند و هر ثبت‌کننده می‌تواند مستقل از سایرین پیکربندی شود. برخی از مؤلفه‌ها، به‌ویژه فرایندهای کارساز DHCP، ممکن است از چندین ثبت‌کننده جهت ثبت پیام‌های مربوط به بخش‌های منطقی مختلفِ آن مؤلفه استفاده کنند. برای مثال، کارساز DHCPv4 از یک ثبت‌کننده برای پیام‌های دریافت و ارسال بسته‌ها، و از ثبت‌کننده‌ای دیگر برای پیام‌های مرتبط با تخصیص اجاره (lease) و مواردی از این دست استفاده می‌کند. برخی از کتابخانه‌های مورداستفاده در کارساز Kea مانند libdhcpsrv از ثبت‌کننده‌های مختص به خود بهره می‌برند.

کاربرانی که کتابخانه‌های قلاب (hook libraries ‏- کدی که در زمان اجرا به کارساز پیوست می‌شود) را توسعه می‌دهند، وظیفه ایجاد ثبت‌کننده‌های مورد استفاده در آن کتابخانه‌ها را بر عهده دارند. این ثبت‌کننده‌ها باید نام‌های منحصربه‌فردی داشته باشند که با نام‌های استفاده‌شده توسط Kea تداخل نداشته باشد. بدین ترتیب، پیام‌های صادرشده توسط کتابخانه قلاب از پیام‌های بخش مرکزی کد Kea قابل تفکیک خواهند بود. همچنین نام‌های متمایز این امکان را می‌دهند که ثبت‌کننده‌های قلاب به‌طور مستقل از ثبت‌کننده‌های Kea پیکربندی شوند. در صورت لزوم، یک کتابخانه قلاب می‌تواند از چندین ثبت‌کننده جهت ثبت پیام‌های مربوط به بخش‌های منطقی متفاوت کتابخانه بهره ببرد.

در بخش server فایل پیکربندی، می‌توان تنظیمات مربوط به صفر یا چند ثبت‌کننده (از جمله ثبت‌کننده‌های مورداستفاده در کتابخانه‌های قلاب اختصاصی) را تعیین کرد. در صورت عدم تعیین ثبت‌کننده‌ها، کد از مقادیر پیش‌فرض استفاده می‌کند؛ در این حالت Kea پیام‌های با سطح اهمیت INFO یا بیشتر را در خروجی استاندارد ثبت می‌کند. یک بازه زمانی کوتاه میان شروع به کار Kea تا زمان خواندن پیکربندی وجود دارد؛ ثبت وقایع در این بازه کوتاه را می‌توان از طریق متغیرهای محیطی کنترل نمود. برای کسب اطلاعات بیشتر، بخش Logging During Kea Startup را ببینید.

سه مؤلفه اصلی در پیکربندی یک ثبت‌کننده عبارتند از: name (مؤلفه‌ای که پیام‌ها را ایجاد می‌کند)، severity (چه چیزی ثبت شود)، و output_commands (محل ذخیره یا ارسال لاگ). علاوه بر این، گزینه debuglevel نیز وجود دارد که تنها در صورت انتخاب سطح ثبت وقایع debug کاربرد دارد..SS ثبت‌کنندهٔ name (رشته)

هر ثبت‌کننده (logger) در سامانه یک نام دارد: نام فایل باینری مؤلفه‌ای که از آن برای ثبت پیام‌ها استفاده می‌کند. برای نمونه، جهت پیکربندی ثبت رخدادها برای سرور DHCPv4، مدخلی برای ثبت‌کننده‌ای با نام «kea-dhcp4» اضافه کنید. این پیکربندی سپس توسط ثبت‌کننده‌های موجود در سرور DHCPv4 و تمامی کتابخانه‌های مورد استفادهٔ آن به کار گرفته خواهد شد، مگر آن‌که کتابخانه‌ای ثبت‌کنندهٔ ویژهٔ خود را تعریف کرده باشد و پیکربندی ثبت‌کنندهٔ مشخصی وجود داشته باشد که بر آن ثبت‌کننده اعمال شود.

هنگام ردیابی یک مشکل در عملکرد سرور، استفاده از ثبت در سطح DEBUG برای به‌دست آوردن خروجی با جزئیات کامل جهت عیب‌یابی مورد نیاز است. با این حال، احتمال دارد این حجم زیاد از جزئیات در مواردی که سرور ترافیک بالایی را پردازش می‌کند، سامانهٔ ثبت رخداد را تحت فشار شدید قرار دهد. برای کاهش این مشکل، Kea می‌تواند از چندین ثبت‌کننده برای بخش‌های عملکردی مختلف سرور استفاده کند که هر کدام را می‌توان به طور مستقل پیکربندی کرد. اگر کاربر تا حد قابل قبولی مطمئن باشد که مشکل از بخش خاصی از سرور سرچشمه می‌گیرد، یا مشکل به نوع خاصی از عملیات مربوط است، می‌تواند سطح جزئیات بالا را تنها برای ثبت‌کنندهٔ مربوطه فعال کند و از این طریق پیام‌های DEBUG را به حداقلِ لازم محدود سازد.

ثبت‌کننده‌ها به یک کتابخانه یا فایل باینریِ مشخص از Kea وابسته هستند. با این وجود، هر کتابخانه یا فایل باینری می‌تواند (و معمولاً چنین است) شامل چندین ثبت‌کننده باشد. برای نمونه، فایل باینری سرور DHCPv4 شامل ثبت‌کننده‌های مجزایی برای تجزیهٔ بسته‌ها (packet parsing)، بسته‌های دور انداخته‌شده (dropped packets)، فراخوانی‌ها (callouts) و غیره است.

ثبت‌کننده‌ها یک سلسله‌مراتب را تشکیل می‌دهند. برای هر برنامه در Kea، یک ثبت‌کنندهٔ «ریشه» ("root") وجود دارد که هم‌نام با آن برنامه است (برای نمونه، ثبت‌کنندهٔ ریشه برای kea-dhcp4 <#std-iscman-kea-dhcp4>، یعنی سرور DHCPv4، نامش kea-dhcp4 <#std-iscman-kea-dhcp4> است). سایر ثبت‌کننده‌ها فرزندان این ثبت‌کننده به شمار می‌روند و متناسب با آن نام‌گذاری می‌شوند؛ مثلاً موتور تخصیص در سرور DHCPv4، پیام‌ها را با استفاده از ثبت‌کننده‌ای به نام kea-dhcp4.alloc-engine ثبت می‌کند.

این رابطه اهمیت دارد، زیرا هر ثبت‌کنندهٔ فرزند، پیکربندی پیش‌فرض خود را از ثبت‌کنندهٔ ریشهٔ والد خود دریافت می‌کند. در حالت معمول، پیکربندی ثبت‌کنندهٔ ریشه تنها پیکربندیِ ثبتی است که در فایل پیکربندی مشخص می‌شود و بنابراین برای همهٔ ثبت‌کننده‌ها اعمال می‌گردد. اگر مدخلی برای یک ثبت‌کنندهٔ معین ایجاد شود، هر ویژگیِ مشخص‌شده بر ویژگی‌های ثبت‌کنندهٔ ریشه ارجحیت خواهد داشت، در حالی که ویژگی‌های مشخص‌نشده از آن به ارث برده می‌شوند.

برای روشن‌تر شدن موضوع، فرض کنید در حال استفاده از سرور DHCPv4 با ثبت‌کنندهٔ ریشهٔ kea-dhcp4 <#std-iscman-kea-dhcp4> هستیم که در سطح INFO ثبت می‌کند. به منظور فعال‌سازی سطح جزئیات DEBUG برای بسته‌های دور انداخته‌شدهٔ DHCPv4، باید مدخل پیکربندی‌ای برای این ثبت‌کننده با "name": "kea-dhcp4.bad-packets”، "severity": "DEBUG" و یک سطح اشکال‌زدایی صریح بسازیم. تمام پارامترهای پیکربندی دیگر می‌توانند برای این ثبت‌کننده حذف شوند در صورتی که قرار باشد از مقادیر پیش‌فرض تعیین‌شده در پیکربندی ثبت‌کنندهٔ ریشه استفاده کند.

ویژگی debuglevel تنها در صورتی به ارث می‌رسد که severity نیز وجود نداشته باشد. برای به‌دست آمدن نتایج قابل پیش‌بینی، اگر severity برابر "DEBUG" باشد، این دو ویژگی همیشه باید یا با هم به صراحت مشخص شوند یا هر دو حذف شوند. مدخلی با شدت صریح "DEBUG"، مقدار debuglevel را از ثبت‌کنندهٔ ریشه به ارث نمی‌برد و در صورت عدم تعیین، به طور پیش‌فرض 0 در نظر گرفته می‌شود که در نتیجه هیچ پیام اشکال‌زدایی‌ای ثبت نخواهد شد. این پیامدِ تکیه بر سازوکار توارث log4cplus است.

اگر چندین مشخصهٔ ثبت‌کننده در پیکربندی وجود داشته باشد که ممکن است با یک ثبت‌کنندهٔ خاص تطابق داشته باشند، مشخصه‌ای که نام ثبت‌کنندهٔ دقیق‌تری دارد اولویت خواهد داشت. برای نمونه، اگر مدخل‌هایی هم برای kea-dhcp4 <#std-iscman-kea-dhcp4> و هم برای kea-dhcp4.dhcpsrv وجود داشته باشد، برنامهٔ اصلی سرور DHCPv4 — و تمام کتابخانه‌های مورد استفادهٔ آن به جز کتابخانهٔ dhcpsrv (کتابخانهٔ libdhcpsrv) — پیام‌ها را بر اساس پیکربندی موجود در مدخل اول (kea-dhcp4 <#std-iscman-kea-dhcp4>) ثبت می‌کنند. پیام‌های تولیدشده توسط کتابخانهٔ dhcpsrv بر اساس پیکربندی تعیین‌شده در مدخل دوم ثبت می‌شوند.

ثبت‌کننده‌هایی که در حال حاضر تعریف شده‌اند در جدول زیر فهرست شده‌اند. ستون «بستهٔ نرم‌افزاری» ("Software Package") در این جدول مشخص می‌کند که آیا ثبت‌کننده‌های خاص متعلق به کد اصلی Kea (فایل‌های باینری و کتابخانه‌های متن‌باز Kea) هستند، یا کتابخانه‌های قلاب (hook) (متن‌باز یا اشتراکی).

نام ثبت‌کننده بستهٔ نرم‌افزاری توضیحات
kea-dhcp4 core ثبت‌کنندهٔ ریشه برای سرور DHCPv4. تمام مؤلفه‌های مورد استفادهٔ سرور DHCPv4 تنظیمات را از این ثبت‌کننده به ارث می‌برند.
kea-dhcp6 core ثبت‌کنندهٔ ریشه برای سرور DHCPv6. تمام مؤلفه‌های مورد استفادهٔ سرور DHCPv6 تنظیمات را از این ثبت‌کننده به ارث می‌برند.
kea-dhcp4.alloc-engine, kea-dhcp6.alloc-engine core مورد استفاده توسط موتور تخصیص اجاره، که مسئول مدیریت اجاره‌ها در پایگاه دادهٔ اجاره است؛ یعنی ایجاد، تغییر، و حذف اجاره‌های DHCP در نتیجهٔ پردازش پیام‌های دریافتی از کلاینت‌ها.
kea-dhcp4.auth, kea-dhcp6.auth core برای ثبت بسته‌های ناهنجار HTTP در هنگام استفاده از احراز هویت پایه (basic authentication).
kea-dhcp4.bad-packets, kea-dhcp6.bad-packets core مورد استفاده توسط سرورهای DHCP برای ثبت بسته‌های ورودی کلاینت که دور انداخته شده‌اند یا سرور با یک DHCPNAK به آن‌ها پاسخ داده است. این قابلیت به مدیران سیستم امکان می‌دهد تا یک خروجی ثبت مجزا پیکربندی کنند که تنها حاوی موارد دور انداختن و رد بسته باشد.
kea-dhcp4.bootp-hooks کتابخانهٔ قلاب متن‌باز libdhcp_bootp.so <#std-ischooklib-libdhcp_bootp.so> این ثبت‌کننده برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب BOOTP به کار می‌رود.
kea-dhcp4.callouts, kea-dhcp6.callouts, kea-dhcp-ddns.callouts core برای ثبت پیام‌های مربوط به ثبت و اجرای فراخوانی‌ها (callouts) برای یک نقطهٔ قلاب خاص.
kea-dhcp4.cb-cmds-hooks, kea-dhcp6.cb-cmds-hooks کتابخانهٔ قلاب اشتراکی libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Config Backend Commands.
kea-dhcp4.class-cmds-hooks, kea-dhcp6.class-cmds-hooks کتابخانهٔ قلاب متن‌باز libdhcp_class_cmds.so <#std-ischooklib-libdhcp_class_cmds.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Class Commands.
kea-dhcp4.commands, kea-dhcp6.commands core برای ثبت پیام‌های مرتبط با رسیدگی به دستورهای دریافت شده توسط سرور DHCP از طریق کانال دستور (command channel).
kea-dhcp4.database, kea-dhcp6.database core برای ثبت پیام‌های مرتبط با عملیات عمومی پایگاه‌های دادهٔ رابطه‌ای.
kea-dhcp4.ddns-tuning-hooks, kea-dhcp6.ddns-tuning-hooks کتابخانهٔ قلاب متن‌باز libdhcp_ddns_tuning.so <#std-ischooklib-libdhcp_ddns_tuning.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب DDNS Tuning.
kea-dhcp4.ddns, kea-dhcp6.ddns core مورد استفاده توسط سرور DHCP برای ثبت پیام‌های مرتبط با پردازش گزینه‌های Client FQDN و Hostname. همچنین شامل پیام‌های ثبت مربوط به به‌روزرسانی‌های مرتبط با DNS است.
kea-dhcp4.dhcp4, kea-dhcp6.dhcp6 core برای ثبت عملیات پایه به کار می‌رود.
kea-dhcp4.dhcpsrv, kea-dhcp6.dhcpsrv core ثبت‌کننده‌های پایه برای کتابخانهٔ libkea-dhcpsrv.so.
kea-dhcp4.eval, kea-dhcp6.eval core برای ثبت پیام‌های مرتبط با کد ارزیابی عبارت دسته‌بندی کلاینت.
kea-dhcp4.flex-id-hooks, kea-dhcp6.flex-id-hooks کتابخانهٔ قلاب متن‌باز libdhcp_flex_id.so <#std-ischooklib-libdhcp_flex_id.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Flexible Identifier.
kea-dhcp4.flex-option-hooks, kea-dhcp6.flex-option-hooks کتابخانهٔ قلاب متن‌باز libdhcp_flex_option.so <#std-ischooklib-libdhcp_flex_option.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Flexible Option.
kea-dhcp4.ha-hooks, kea-dhcp6.ha-hooks کتابخانهٔ قلاب متن‌باز libdhcp_ha.so <#std-ischooklib-libdhcp_ha.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب دسترسی‌پذیری بالا (High Availability).
kea-dhcp4.hooks, kea-dhcp6.hooks, kea-dhcp-ddns.hooks core برای ثبت پیام‌های مرتبط با مدیریت کتابخانه‌های قلاب، مانند ثبت و لغو ثبت کتابخانه‌ها، و مقداردهی اولیهٔ اجرای فراخوانی‌ها برای نقاط قلاب مختلف در سرور DHCP به کار می‌رود.
kea-dhcp4.host-cache-hooks, kea-dhcp6.host-cache-hooks کتابخانهٔ قلاب متن‌باز libdhcp_host_cache.so <#std-ischooklib-libdhcp_host_cache.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Host Cache.
kea-dhcp4.host-cmds-hooks, kea-dhcp6.host-cmds-hooks کتابخانهٔ قلاب متن‌باز libdhcp_host_cmds.so <#std-ischooklib-libdhcp_host_cmds.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Host Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند.
kea-dhcp4.hosts, kea-dhcp6.hosts core درون libkea-dhcpsrv.so برای ثبت پیام‌های مربوط به مدیریت رزروهای میزبان در DHCP (یعنی بازیابی رزروها و افزودن رزروهای جدید) استفاده می‌شود.
kea-dhcp4.lease-cmds-hooks, kea-dhcp6.lease-cmds-hooks کتابخانهٔ قلاب متن‌باز libdhcp_lease_cmds.so <#std-ischooklib-libdhcp_lease_cmds.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Lease Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند.
kea-dhcp4.limits-hooks, kea-dhcp6.limits-hooks کتابخانهٔ قلاب متن‌باز libdhcp_limits.so <#std-ischooklib-libdhcp_limits.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Limits.
kea-dhcp4.lease-query-hooks, kea-dhcp6.lease-query-hooks کتابخانهٔ قلاب متن‌باز libdhcp_lease_query.so <#std-ischooklib-libdhcp_lease_query.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Leasequery.
kea-dhcp4.leases, kea-dhcp6.leases core توسط سرور DHCP برای ثبت پیام‌های مرتبط با تخصیص اجاره به کار می‌رود. این پیام‌ها شامل اطلاعات دقیق دربارهٔ اجاره‌های تخصیص‌یافته یا ارائه‌شده، خطاها در طول تخصیص اجاره و غیره می‌باشند.
kea-dhcp4.legal-log-hooks, kea-dhcp6.legal-log-hooks کتابخانهٔ قلاب متن‌باز libdhcp_legal_log.so <#std-ischooklib-libdhcp_legal_log.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Forensic Logging.
kea-dhcp4.mysql-cb-hooks, kea-dhcp6.mysql-cb-hooks کتابخانهٔ قلاب متن‌باز libdhcp_mysql.so <#std-ischooklib-libdhcp_mysql.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب MySQL Configuration Backend.
kea-dhcp4.mysql-hb-hooks, kea-dhcp6.mysql-hb-hooks کتابخانهٔ قلاب متن‌باز libdhcp_mysql.so <#std-ischooklib-libdhcp_mysql.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب MySQL Host Backend.
kea-dhcp4.mysql-lb-hooks, kea-dhcp6.mysql-lb-hooks کتابخانهٔ قلاب متن‌باز libdhcp_mysql.so <#std-ischooklib-libdhcp_mysql.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب MySQL Lease Backend.
kea-dhcp4.options, kea-dhcp6.options core توسط سرور DHCP برای ثبت پیام‌های مربوط به پردازش گزینه‌ها در پیام‌های DHCP به کار می‌رود؛ مانند تجزیهٔ گزینه‌ها، کدگذاری گزینه‌ها به قالب on-wire، و دسته‌بندی بسته‌ها با استفاده از گزینه‌های موجود در بسته‌های دریافتی.
kea-dhcp4.packets, kea-dhcp6.packets core بیشتر برای ثبت پیام‌های مرتبط با انتقال بسته‌های DHCP استفاده می‌شود؛ یعنی دریافت بسته و ارسال پاسخ. چنین پیام‌هایی شامل اطلاعاتی دربارهٔ نشانی‌های IP مبدأ و مقصد و رابط‌های مورد استفاده برای انتقال بسته‌ها هستند. این ثبت‌کننده همچنین برای ثبت پیام‌های مرتبط با انتخاب زیرشبکه به کار می‌رود، چرا که این انتخاب معمولاً بر اساس نشانی‌های IP، نشانی‌های رله، و/یا نام رابط‌ها صورت می‌گیرد که می‌توان آن‌ها را حتی پیش از تجزیه شدن پیام DHCP درون بسته، از بستهٔ دریافتی استخراج کرد.
kea-dhcp4.perfmon-hooks, kea-dhcp6.perfmon-hooks کتابخانهٔ قلاب متن‌باز libdhcp_perfmon.so <#std-ischooklib-libdhcp_perfmon.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Performance Monitoring.
kea-dhcp4.ping-check-hooks کتابخانهٔ قلاب متن‌باز libdhcp_ping_check.so <#std-ischooklib-libdhcp_ping_check.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Ping Check.
kea-dhcp4.pgsql-cb-hooks, kea-dhcp6.pgsql-cb-hooks کتابخانهٔ قلاب متن‌باز libdhcp_pgsql.so <#std-ischooklib-libdhcp_pgsql.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب PostgreSQL Configuration Backend.
kea-dhcp4.pgsql-hb-hooks, kea-dhcp6.pgsql-hb-hooks کتابخانهٔ قلاب متن‌باز libdhcp_pgsql.so <#std-ischooklib-libdhcp_pgsql.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب PostgreSQL Host Backend.
kea-dhcp4.pgsql-lb-hooks, kea-dhcp6.pgsql-lb-hooks کتابخانهٔ قلاب متن‌باز libdhcp_pgsql.so <#std-ischooklib-libdhcp_pgsql.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب PostgreSQL Lease Backend.
kea-dhcp4.run-script-hooks, kea-dhcp6.run-script-hooks کتابخانهٔ قلاب متن‌باز libdhcp_run_script.so <#std-ischooklib-libdhcp_run_script.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Run Script.
kea-dhcp4.radius-hooks, kea-dhcp6.radius-hooks کتابخانهٔ قلاب متن‌باز libdhcp_radius.so <#std-ischooklib-libdhcp_radius.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب RADIUS.
kea-dhcp4.stat-cmds-hooks, kea-dhcp6.stat-cmds-hooks کتابخانهٔ قلاب متن‌باز libdhcp_stat_cmds.so <#std-ischooklib-libdhcp_stat_cmds.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Statistics Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند.
kea-dhcp4.subnet-cmds-hooks, kea-dhcp6.subnet-cmds-hooks کتابخانهٔ قلاب متن‌باز libdhcp_subnet_cmds.so <#std-ischooklib-libdhcp_subnet_cmds.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب Subnet Commands. به طور کلی، این پیام‌ها مربوط به بارگذاری و تخلیهٔ کتابخانه و اجرای دستورها توسط کتابخانه هستند.
kea-dhcp4.tcp, kea-dhcp6.tcp core برای ثبت پیام‌های مرتبط با ترافیک TCP.
kea-dhcp4.user_chk, kea-dhcp6.user_chk کتابخانهٔ قلاب متن‌باز libdhcp_user_chk.so <#std-ischooklib-libdhcp_user_chk.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب User Check.
kea-dhcp-ddns core ثبت‌کنندهٔ ریشه برای دیمن kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>. تمام مؤلفه‌های مورد استفاده توسط این دیمن تنظیمات را از این ثبت‌کننده به ارث می‌برند، مگر اینکه پیکربندی‌هایی برای ثبت‌کننده‌های تخصصی‌تر وجود داشته باشد.
kea-dhcp-ddns.dctl core برای ثبت اطلاعات اولیه دربارهٔ فرآیند، سیگنال‌های دریافتی، و پیکربندی‌های مجدد فراخوانی‌شده.
kea-dhcp-ddns.asiodns core برای ثبت پیام‌ها دربارهٔ رخدادهای شبکه در عملیات DDNS.
kea-dhcp-ddns.dhcpddns core توسط دیمن kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> برای ثبت رخدادهای مرتبط با عملیات DDNS استفاده می‌شود.
kea-dhcp-ddns.dhcp-to-d2 core توسط دیمن kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> برای ثبت اطلاعات دربارهٔ رخدادهای مربوط به دریافت پیام‌ها از سرورهای DHCP و افزودن آن‌ها به صف پردازش استفاده می‌شود.
kea-dhcp-ddns.d2-to-dns core توسط دیمن kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> برای ثبت اطلاعات دربارهٔ رخدادهای مربوط به ارسال و دریافت پیام‌ها به و از سرورهای DNS استفاده می‌شود.
kea-dhcp-ddns.gss-tsig-hooks کتابخانهٔ قلاب متن‌باز libddns_gss_tsig.so <#std-ischooklib-libddns_gss_tsig.so> برای ثبت پیام‌های مرتبط با عملکرد کتابخانهٔ قلاب GSS-TSIG.
kea-dhcp-ddns.libdhcp-ddns core برای ثبت رخدادهای مرتبط با عملیات DDNS استفاده می‌شود.
kea-netconf core ثبت‌کنندهٔ ریشه برای عامل NETCONF. تمام مؤلفه‌های مورد استفادهٔ NETCONF تنظیمات را از این ثبت‌کننده به ارث می‌برند در صورتی که ثبت‌کنندهٔ تخصصی‌تری ارائه نشده باشد.

توجه داشته باشید که کتابخانه‌های قلابِ تعریف‌شده توسط کاربر نباید از هیچ‌یک از ثبت‌کننده‌های ذکرشده در بالا استفاده کنند، بلکه باید ثبت‌کننده‌های جدیدی با نام‌هایی متناسب با کتابخانه‌های استفاده‌کننده از آن‌ها تعریف نمایند. فرض کنید کاربری کتابخانه‌ای به نام «libdhcp-packet-capture» ایجاد کرده است تا بسته‌های دریافتی و ارسالی توسط سرور را در یک فایل ذخیره کند. نام مناسب برای این ثبت‌کننده می‌تواند kea-dhcp4.packet-capture-hooks باشد. (توجه داشته باشید که پیاده‌ساز کتابخانهٔ قلاب تنها بخش دوم این نام، یعنی «packet-capture» را مشخص می‌کند؛ بخش اول نام ثبت‌کنندهٔ ریشه است و توسط سامانهٔ ثبت رخداد Kea به ابتدای آن افزوده می‌شود). همچنین ذکر این نکته حائز اهمیت است که چون این ثبت‌کنندهٔ جدید فرزندی از یک ثبت‌کنندهٔ ریشه است، پیکربندی را از ثبت‌کنندهٔ ریشه به ارث می‌برد؛ امری که می‌توان با ایجاد مدخلی در فایل پیکربندی آن را بازنویسی کرد.

ساده‌ترین راه برای یافتن نام یک ثبت‌کننده این است که تمام عملیات ثبت رخداد را طوری پیکربندی کنید که به یک مقصد واحد ارسال شود و در آن‌جا به دنبال نام‌های ثبت‌کنندهٔ خاص بگردید. برای جزئیات بیشتر به بخش «قالب پیام‌های ثبت» (Logging Message Format) مراجعه کنید..SS ثبت‌کننده severity (رشته)

این مورد ردهٔ پیام‌های ثبت‌شده را مشخص می‌کند. هر پیام به همراه یک سطح اهمیت مرتبط ثبت می‌شود که ممکن است یکی از موارد زیر باشد (به ترتیب نزولی سطح اهمیت):

  • FATAL - مرتبط با پیام‌های تولیدشده در شرایطی که آن‌چنان وخیم است که کارساز نمی‌تواند به اجرای خود ادامه دهد.
  • ERROR - مرتبط با پیام‌های تولیدشده در وضعیت خطا. کارساز به اجرای خود ادامه می‌دهد، اما نتایج ممکن است مطابق انتظار نباشد.
  • WARN - بیانگر یک وضعیت غیرعادی است. با این حال، کارساز به طور عادی به اجرای خود ادامه می‌دهد.
  • INFO - یک پیام اطلاع‌رسانی که نشان‌دهندهٔ وقوع یک رویداد است.
  • DEBUG - پیام‌های تولیدشده برای اهداف اشکال‌زدایی.

هنگامی که سطح اهمیت یک ثبت‌کننده روی یکی از این مقادیر تنظیم شود، تنها پیام‌های مربوط به همان سطح و سطوح بالاتر ثبت می‌شوند (برای مثال، تنظیم سطح اهمیت گزارش‌گیری روی INFO باعث ثبت پیام‌های INFO، WARN، ERROR و FATAL می‌شود). همچنین می‌توان سطح اهمیت را روی NONE تنظیم کرد که در این صورت از ثبت تمامی پیام‌های آن ثبت‌کننده جلوگیری می‌شود.

نکته:

ابزار keactrl <#std-iscman-keactrl>، که در «مدیریت Kea با keactrl» <#keactrl> شرح داده شده است، می‌تواند طوری پیکربندی شود که کارسازها را در حالت پرحرف (verbose) راه‌اندازی کند. در این صورت، تنظیمات سطح اهمیت گزارش‌گیری در فایل پیکربندی هیچ اثری نخواهد داشت؛ کارسازها بدون توجه به تنظیمات گزارش‌گیری مشخص‌شده در فایل پیکربندی، از سطح اهمیت DEBUG استفاده می‌کنند. برای کنترل سطح اهمیت از طریق فایل پیکربندی، لطفاً مطمئن شوید که مقدار kea_verbose درون پیکربندی keactrl <#std-iscman-keactrl> روی "no" تنظیم شده باشد.

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

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

نکته:

نام مستعار output-options در Kea 2.5.1 اضافه شد تا بتوان آن را به‌جای کلید پیکربندی قبلی یعنی output_options به کار برد. این کار برای حفظ یکپارچگی تمامی کلیدهای پیکربندی انجام شد، یعنی استفاده از خط تیره (-) به جای زیرخط (_) در نام کلید.

از نسخهٔ Kea 2.5.2، کلید output-options به کلید پیکربندی پیش‌فرض تبدیل شده و از output_options می‌توان به عنوان یک نام مستعار استفاده کرد.

از نسخهٔ Kea 2.7.4، کلید پیکربندی output_options منسوخ شده است و در نسخه‌های آینده حذف خواهد شد. لطفاً با جایگزین کردن آن با output-options، پیکربندی خود را به‌روزرسانی کنید.

این مقدار نوع خروجی را تعیین می‌کند. چندین مقدار خاص در اینجا مجاز هستند: stdout (پیام‌ها روی خروجی استاندارد چاپ می‌شوند)، stderr (پیام‌ها روی خطای استاندارد چاپ می‌شوند)، syslog (پیام‌ها با استفاده از نام پیش‌فرض در syslog ثبت می‌شوند)، syslog:name (پیام‌ها با استفاده از نام مشخص‌شده در syslog ثبت می‌شوند). هر مقدار دیگری به عنوان نام فایلی که پیام‌ها باید در آن نوشته شوند تفسیر می‌شود.

نکته:

از نسخهٔ Kea 2.7.9، فایل‌های گزارش تنها می‌توانند در پوشهٔ خروجی تعیین‌شده در حین کامپایل نوشته شوند: "[kea-install-dir]/var/log/kea". این مسیر را می‌توان در زمان راه‌اندازی با تنظیم متغیر محیطی KEA_LOG_FILE_DIR روی مسیر دلخواه بازنویسی کرد. اگر مسیری غیر از این مقدار در output استفاده شود، Kea خطایی صادر کرده و از راه‌اندازی خودداری می‌کند یا در صورت در حال اجرا بودن، یک خطای غیرقابل‌جبران ثبت خواهد کرد. برای سهولت در استفاده، کافی است بخش مسیر را از output حذف کرده و فقط نام فایل را مشخص کنید.

این گزینه بافرها را پس از هر پیام گزارش تخلیه می‌کند. انجام این کار کارایی را کاهش می‌دهد اما تضمین می‌کند که در صورت خاتمهٔ غیرعادی برنامه، تمامی پیام‌ها تا لحظهٔ خاتمه ثبت شوند. مقدار پیش‌فرض true است.

این گزینه تنها زمانی که مقصد یک فایل باشد کاربرد دارد؛ این مقدار حداکثر اندازه‌ای به بایت است که یک فایل گزارش می‌تواند داشته باشد. هنگامی که اندازه به حداکثر رسید، نام فایل تغییر یافته و یک فایل جدید ایجاد می‌شود. در ابتدا یک ".1" به انتهای نام افزوده می‌شود؛ اگر فایلی با پسوند ".1" وجود داشته باشد، نام آن به ".2" تغییر می‌یابد و به همین ترتیب ادامه پیدا می‌کند. به این فرآیند چرخش گفته می‌شود.

مقدار پیش‌فرض 10240000 (۱۰ مگابایت) است. کوچک‌ترین مقداری که می‌توان بدون غیرفعال کردن چرخش تعیین کرد، 204800 است. هر مقداری کمتر از این مقدار، از جمله 0، چرخش را غیرفعال می‌کند. بزرگ‌ترین مقدار ممکن INT_MAX مگابایت است که تقریباً برابر با ۲ پتابایت می‌باشد.

نکته:

به دلیل محدودیتی در کتابخانهٔ گزارش‌گیری زیربنایی (log4cplus)، چرخش فایل‌های گزارش (از ".1" به ".2" و غیره) ممکن است نتایج عجیبی نشان دهد؛ ممکن است در زمان چرخش، چندین فایل کوچک وجود داشته باشند. این امر زمانی رخ می‌دهد که چندین فرآیند تلاش کنند فایل‌ها را به طور هم‌زمان بچرخانند. نسخهٔ 1.1.0 کتابخانهٔ log4cplus این مشکل را برطرف کرد، بنابراین اگر برای ساخت Kea از این نسخه یا نسخه‌های جدیدتر log4cplus استفاده شود، این مشکل نباید رخ دهد. حتی با نسخه‌های قدیمی‌تر نیز انتظار می‌رود که این مسئله به ندرت رخ دهد، مگر اینکه پیام‌های گزارش با بسامد بسیار بالا توسط چندین فرآیند مختلف تولید شوند.

این گزینه تنها زمانی کاربرد دارد که مقصد یک فایل بوده و چرخش فعال باشد (یعنی maxsize به اندازهٔ کافی بزرگ باشد). این پارامتر، حداکثر تعداد نسخه‌های چرخیده‌ای است که نگهداری می‌شوند. هنگامی که تعداد فایل‌ها به این حد نصاب برسد، در هر بار چرخش لاگ، قدیمی‌ترین فایل، یعنی "log-name.maxver"، دور ریخته می‌شود. به عبارت دیگر، حداکثر فایل لاگ فعال به همراه maxver فایل چرخیده وجود خواهد داشت. کمترین مقدار و مقدار پیش‌فرض ۱ است.

از این گزینه می‌توان برای مشخص کردن الگوی چیدمان پیام‌ها برای یک ثبت‌کننده (logger) استفاده کرد. سیستم ثبت گزارش Kea با استفاده از کتابخانهٔ log4cplus پیاده‌سازی شده و قالب‌بندی خروجی آن، از نظر مفهومی بر پایهٔ قالب‌بندی printf در زبان C است؛ این موضوع با جزئیات در بخش بعدی، قالب پیام‌های ثبت وقایع، بررسی شده است.

هر نوع خروجی (stdout، فایل یا syslog) یک pattern پیش‌فرض دارد که محتوای پیام‌های لاگ آن را شرح می‌دهد. از این پارامتر می‌توان برای مشخص کردن الگوی دلخواه استفاده کرد. الگوی هر ثبت‌کننده به صورت جداگانه تعیین می‌شود، بنابراین هر ثبت‌کنندهٔ پیکربندی‌شده می‌تواند الگوی مخصوص به خود را داشته باشد. حذف کردن پارامتر pattern یا مقداردهی آن با یک رشتهٔ خالی، ""، باعث می‌شود Kea از الگوی پیش‌فرض برای نوع خروجی آن ثبت‌کننده استفاده کند.

علاوه بر خود متن لاگ، الگوهای پیش‌فرض استفاده‌شده برای stdout و فایل‌ها حاوی اطلاعاتی نظیر تاریخ و زمان، سطح ثبت‌کننده و اطلاعات فرایند هستند. الگوی پیش‌فرض برای syslog عمدتاً به سطح لاگ، منبع و متن لاگ محدود می‌شود. این امر از تکرار اطلاعاتی که معمولاً توسط syslog ارائه می‌شوند جلوگیری می‌کند.

هشدار:

اکیداً به کاربران توصیه می‌شود که الگو(های) خود را بر روی یک نمونهٔ محلی و غیرعملیاتی از Kea که در پیش‌زمینه اجرا شده و لاگ‌ها را در stdout می‌نویسد، آزمایش کنند.

همان‌طور که در بالا اشاره شد، محتوای پیام لاگ Kea از طریق ساختاری شبیه به قالب‌بندی printf در زبان C کنترل می‌شود. «الگو» ("pattern") استفاده‌شده برای هر پیام، با رشته‌ای توصیف می‌شود که حاوی یک یا چند جزء قالب‌بندی به عنوان بخشی از یک رشتهٔ متنی است. این رشته علاوه بر اجزا می‌تواند شامل هر متن مفید دیگری برای مدیر سیستم نیز باشد.

رفتار رشته‌های قالب‌بندی Kea توسط log4cplus تعیین می‌شود. گزینه‌های قالب‌بندی زمان زیر درون %D{} یا %d{} امکان‌پذیر هستند:

جزء مقدار
%a نام اختصاری روز هفته
%A نام کامل روز هفته
%b نام اختصاری ماه
%B نام کامل ماه
%c رشتهٔ استاندارد تاریخ و زمان
%d روزِ ماه به صورت ده‌دهی (1-31)
%H ساعت (0-23)
%I ساعت (1-12)
%j روزِ سال به صورت ده‌دهی (1-366)
%m ماه به صورت ده‌دهی (1-12)
%M دقیقه به صورت ده‌دهی (0-59)
%p معادل محلی (locale) برای AM یا PM
%q میلی‌ثانیه به صورت ده‌دهی (0-999)
%Q میکروثانیه به صورت ده‌دهی (0-999.999)
%S ثانیه به صورت ده‌دهی (0-59)
%U هفتهٔ سال، با یکشنبه به عنوان روز نخست (0-53)
%w روز هفته به صورت ده‌دهی (0-6، یکشنبه برابر 0 است)
%W هفتهٔ سال، با دوشنبه به عنوان روز نخست (0-53)
%x رشتهٔ استاندارد تاریخ
%X رشتهٔ استاندارد زمان
%y سال به صورت ده‌دهی بدون قرن (0-99)
%Y سال به صورت ده‌دهی شامل قرن
%Z نام منطقهٔ زمانی
%% علامت درصد

برای اطلاعات بیشتر، به مستندات تابع strftime() موجود در هدر <ctime> یا صفحهٔ راهنمای یونیکس strftime(3) مراجعه کنید.

احتمالاً ساده‌ترین راه برای درک این موضوع، بررسی الگوی پیش‌فرض برای stdout و فایل‌ها است؛ در حال حاضر هر دوی آن‌ها یکسان هستند. این الگو در زیر نشان داده شده است:

"%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i.%t] %m\n"

و یک لاگ معمول تولیدشده توسط این الگو چیزی شبیه به این خواهد بود:

2019-08-05 14:27:45.871 DEBUG [kea-dhcp4.dhcpsrv/8475.12345] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases

که به صورت زیر تفکیک می‌شود:

%D{%Y-%m-%d %H:%M:%S.%q} عبارت "%D" تاریخ و زمان محلی هنگام تولید پیام گزارش است، در حالی که همه چیز میان آکولادها، "{}"، مؤلفه‌های تاریخ و زمان هستند. بر اساس گزارش نمونه بالا، این عبارت مقدار زیر را تولید می‌کند: 2019-08-05 14:27:45.871
  • %-5p میزان شدت پیام، که در حداقل پنج نویسه با استفاده از فاصله‌گذاری از راست (right-padding) با فاصله‌ها در خروجی درج می‌شود. در گزارش نمونه ما: DEBUG
  • %c منبع گزارش. این مورد شامل دو بخش است: فرایند Kea تولیدکننده پیام، در این مورد، kea-dhcp4 <#std-iscman-kea-dhcp4>؛ و مؤلفه درون برنامه‌ای که پیام از آن صادر شده است، dhcpsrv (برای مثال نام کتابخانه استفاده‌شده توسط پیاده‌سازی‌های کارگزار DHCP).
  • %i شناسه فرایند (PID). از گزارش نمونه: 8475.
  • %t شناسه ریسه (thread ID). از گزارش نمونه: 12345. قالب شناسه ریسه به سیستم‌عامل وابسته است: برای مثال در برخی سیستم‌ها یک آدرس است، بنابراین در مبنای شانزده (هگزادسیمال) نمایش داده می‌شود.
  • %m خود متن پیام گزارش. تمام پیام‌های گزارش Kea با یک شناسه پیام شروع شده و به دنبال آن متن دلخواه گزارش می‌آید. هر پیام در Kea دارای یک شناسه یکتا است که می‌تواند به عنوان نمایه‌ای برای راهنمای پیام‌های Kea <#kea-messages> استفاده شود، جایی که می‌توان اطلاعات بیشتری کسب کرد. در گزارش نمونه بالا، شناسه عبارت است از DHCPSRV_TIMERMGR_START_TIMER. متن گزارش معمولاً شرح مختصری با جزئیات شرایطی است که باعث ثبت گزارش شده است. در نمونه ما، اطلاعات ثبت‌شده، starting timer: reclaim-expired-leases، توضیح می‌دهد که زمان‌سنج مربوط به چرخه بازپس‌گیری اجاره‌های منقضی‌شده شروع شده است.

هشدار:

حذف %m متن پیام گزارش را از خروجی حذف کرده و آن را تا حدودی بی‌فایده می‌سازد. %m باید اجباری در نظر گرفته شود.

در نهایت، توجه داشته باشید که فاصله‌گذاری بین مؤلفه‌ها، کروشه‌های دور منبع گزارش و PID، و نویسه بازگشت به خط بعد پایانی \n همگی متن‌های عینی هستند که به عنوان بخشی از الگو مشخص شده‌اند.

هشدار:

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

الگوی پیش‌فرض برای خروجی syslog عبارت است از:

"%-5p [%c.%t] %m\n"

این الگو تاریخ و زمان و همچنین شناسه فرایند را حذف می‌کند، زیرا این اطلاعات معمولاً توسط syslog در خروجی قرار داده می‌شوند. توجه داشته باشید که Kea از این الگو برای ساختن متنی که به syslog (یا هر مقصد دیگری) می‌فرستد، استفاده می‌کند. این مورد هیچ تأثیری بر محتوایی که ممکن است syslog اضافه کند یا قالب‌بندی که ممکن است انجام دهد، ندارد.

برای بررسی رفتار syslog به مستندات سیستم‌عامل مراجعه کنید، زیرا پیاده‌سازی‌های متعددی از آن وجود دارد.

فهرست کاملی از پارامترهای گزارش‌گیری پشتیبانی‌شده توسط Kea در جدول زیر نشان داده شده است:

مؤلفه مقدار
%b فایلی که گزارش را فراخوانی کرده در خروجی می‌آورد، مثلاً logger_impl.cc
%c ثبت‌کننده (logger) رویداد را در خروجی می‌آورد، مثلاً kea-dhcp4.hosts
%d الگوی %d{} خروجی زمان UTC را قالب‌بندی می‌کند، مثلاً %d{%Y-%m-%d %H:%M:%S.%q}
%D الگوی %D{} خروجی زمان محلی (LOCAL) را قالب‌بندی می‌کند، مثلاً %D{%Y-%m-%d %H:%M:%S.%q}
%E متغیرهای محیط را در خروجی می‌آورد، مثلاً %E{PATH}
%F نام فایلی که درخواست گزارش از آنجا صادر شده را در خروجی می‌آورد، مثلاً logger_impl.cc
%h نام میزبان سیستم را در خروجی می‌آورد، مثلاً host-1
%H نام دامنه کاملاً مشخص (FQDN) را در خروجی می‌آورد، مثلاً host-1.example.com
%l معادل %F:%L است، مثلاً logger_impl.cc:179
%L شماره خطی که گزارش در آن فراخوانی شده را در خروجی می‌آورد، مثلاً 179
%m پیام واقعی گزارش را در خروجی می‌آورد
%M فراخواننده (نام تابع) پیام گزارش را در خروجی می‌آورد
%n جداکننده خط پشتیبانی‌شده توسط سیستم‌عامل را در خروجی می‌آورد، مثلاً \n در Linux
%p میزان شدت گزارش را در خروجی می‌آورد، مثلاً INFO
%r میلی‌ثانیه‌های سپری‌شده از شروع برنامه را در خروجی می‌آورد، مثلاً 1235
%t شناسه ریسه‌ای (thread ID) را که پیام گزارش را تولید کرده در خروجی می‌آورد، مثلاً 281472855306256
%T نام ریسه‌ای را که پیام گزارش را تولید کرده در خروجی می‌آورد، مثلاً 168005
%i شناسه فرایندی (PID) را که پیام گزارش را تولید کرده در خروجی می‌آورد، مثلاً 168030
%% یک علامت درصد واقعی را در خروجی درج می‌کند

فاصله‌گذاری (Padding) و کوتاه‌سازی (truncation) نیز با استفاده از اصلاح‌کننده‌های قبل از مؤلفه امکان‌پذیر هستند؛ این کار با قرار دادن یک عدد و سایر نویسه‌های اصلاح‌کننده بین مؤلفه و علامت % انجام می‌شود. پنج روش برای اصلاح خروجی وجود دارد:

%20p در صورتی که سطح اهمیت (severity) کوتاه‌تر از ۲۰ نویسه باشد، از سمت چپ با فاصله پر می‌شود (راست‌چین).
  • %-15r در صورتی که میلی‌ثانیه‌های سپری‌شده از زمان شروع برنامه کوتاه‌تر از ۱۵ نویسه باشد، از سمت راست با فاصله پر می‌شود (چپ‌چین).
  • %.30m در صورتی که پیام طولانی‌تر از ۳۰ نویسه باشد، از ابتدای پیام برش می‌خورد.
  • %10.35E{PATH} در صورتی که متغیر محیطی "PATH" کوتاه‌تر از ۱۰ نویسه باشد، از سمت چپ با فاصله پر می‌شود (راست‌چین). اگر طول محتوا بیشتر از ۳۵ نویسه باشد، از ابتدای رشته برش می‌خورد.
  • %-15.40m در صورتی که پیام لاگ کوتاه‌تر از ۱۵ نویسه باشد، از سمت راست با فاصله پر می‌شود (چپ‌چین). اگر طول پیام بیشتر از ۴۰ نویسه باشد، از ابتدا برش می‌خورد.

پارامترهای پشتیبانی‌شده به نسخه liblog4cplus استفاده‌شده برای کامپایل Kea بستگی دارد، که می‌توان آن را با اجرای دستور kea-dhcp4 -W | grep -i log4cplus بررسی کرد. این کار خروجی‌ای مانند LOG4CPLUS_VERSION: 2.0.5 تولید می‌کند. برای دریافت اطلاعات بیشتر درباره نسخه نصب‌شده، مستندات موجود در ویکی log4cplus را در https://github.com/log4cplus/log4cplus/wiki بررسی کنید.

در این مثال، می‌خواهیم ثبت گزارش (logging) کارساز را طوری تنظیم کنیم که با استفاده از خروجی استاندارد روی کنسول بنویسد.

"Server": {
    "loggers": [
        {
            "name": "kea-dhcp4",
            "output-options": [
                {
                    "output": "stdout"
                }
            ],
            "severity": "WARN"
        }
    ]
}

به عنوان مثال دوم، می‌خواهیم پیام‌های لاگ سطح DEBUG را در فایلی حداکثر با حجم ۲ مگابایت ذخیره کنیم و تا هشت نسخه از فایل‌های لاگ قدیمی را نگه داریم. به محض اینکه اندازه فایل لاگ به ۲ مگابایت برسد، باید تغییر نام داده شده و یک فایل جدید ایجاد شود.

"Server": {
    "loggers": [
        {
            "name": "kea-dhcp6",
            "output-options": [
                {
                    "output": "/var/log/kea/kea-debug.log",
                    "maxver": 8,
                    "maxsize": 204800,
                    "flush": true,
                    "pattern": "%d{%j %H:%M:%S.%q} %c %m\n"
                }
            ],
            "severity": "DEBUG",
            "debuglevel": 99
        }
   ]
}

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

220 13:50:31.783 kea-dhcp4.dhcp4 DHCP4_STARTED Kea DHCPv4 server version 1.6.0-beta2-git started

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

متغیرهای محیطی زیر می‌توانند برای کنترل رفتار لاگ‌گیری در هنگام راه‌اندازی استفاده شوند:

KEA_LOCKFILE_DIR

دایرکتوری‌ای را مشخص می‌کند که سیستم ثبت لاگ باید فایل قفل (lock file) خود را در آن ایجاد کند. در صورت عدم تعیین، مقدار آن prefix/var/run/kea است که در آن "prefix" به طور پیش‌فرض /usr/local می‌باشد. این متغیر نباید با یک اسلش خاتمه یابد. یک مقدار ویژه وجود دارد: "none"، که به Kea اعلام می‌کند اصلاً فایل قفل ایجاد نکند. این موضوع در صورتی که چند فرایند در یک فایل مشترک لاگ بنویسند ممکن است باعث بروز مشکل شود.

KEA_LOGGER_DESTINATION

مقصد خروجی لاگ را مشخص می‌کند. چندین مقدار ویژه وجود دارد:

stdout ثبت لاگ در خروجی استاندارد.

stderr ثبت لاگ در خطای استاندارد.

syslog[:fac] ثبت لاگ از طریق syslog. بخش اختیاری "fac" (که با دونقطه از کلمه "syslog" جدا می‌شود) تسهیلات (facility) مورد استفاده برای پیام‌های لاگ را مشخص می‌کند. در صورت عدم تعیین، پیام‌ها با استفاده از تسهیلات "local0" ثبت می‌شوند.

هر مقدار دیگری به عنوان نام فایل خروجی در نظر گرفته می‌شود. اگر وضعیت دیگری تعیین نشده باشد، Kea در خروجی استاندارد لاگ می‌اندازد.

تمام کارسازهای Kea از این رویکرد کلی پیروی می‌کنند که بدون تحمیل بار اضافی و اطلاعات بیش از حد به سیستم ثبت وقایع (logging)، کاربر را از رویدادهای جاری آگاه سازند؛ چرا که بارگذاری بیش از حد می‌تواند به سادگی به عنوان حمله‌ای از نوع محروم‌سازی از سرویس (denial-of-service) مورد سوءاستفاده قرار گیرد.

برخلاف سطوح FATAL، ERROR، WARN و INFO، سطح DEBUG پارامترهای بیشتری دارد. فهرست زیر اطلاعات پایه‌ای را که در هر سطح ثبت می‌شود به تفصیل شرح می‌دهد. گاهی شرایط مشخص می‌کند که یک مورد از اطلاعات در سطحی بالاتر ثبت شود یا پایین‌تر. به عنوان مثال، اگر یک بسته به دلیل دسته‌بندیِ پیکربندی‌شده دور انداخته (drop) شود، این امر ناشی از اجرای سیاست پیکربندی‌شده است و در debuglevel 15 ثبت می‌گردد. با این حال، اگر بسته به دلیل بروز یک استثنا (exception) دور انداخته شود، اهمیت بسیار بیشتری دارد؛ چرا که ممکن است نشان‌دهنده یک باگ نرم‌افزاری، مشکلات جدی در حافظه، یا ایرادات اتصال به پایگاه داده باشد. از این رو ممکن است در سطوح بسیار بالاتری مانند WARN یا حتی ERROR ثبت شود.

  • 0 - پیام‌های منفردی که هنگام راه‌اندازی یا خاموش شدن کارساز چاپ می‌شوند.
  • 10 - ثبت اطلاعات مربوط به دستورات دریافتی API.
  • 15 - اطلاعات درباره دلایل دور انداخته شدن بسته.
  • 40 - اطلاعات ردگیری (tracing)، از جمله تصمیمات پردازشی، نتایج ارزیابی عبارت‌ها و موارد بیشتر.
  • 45 - مشابه سطح 40، اما با جزئیات بیشتر؛ برای مثال، زیرشبکه‌ای که برای یک بسته ورودی انتخاب می‌شود.
  • 50 - ارزیابی عبارت‌ها، وضعیت دریافتی از نقاط هوک (hook points)، پردازش اجاره (lease)، جزئیات پردازش بسته شامل باز کردن بسته (unpacking)، بسته‌بندی، ارسال و غیره.
  • 55 - شامل تمام جزئیات در دسترس، از جمله محتوای کامل بسته به همراه چاپ تمام گزینه‌ها.

سطوح دیباگ فقط برای پیام‌های ثبت‌شده در DEBUG اعمال می‌شوند و با استفاده از گزینه debuglevel پیکربندی می‌گردند. برای جزئیات بیشتر به بخش The debuglevel (integer) Logger مراجعه کنید.

کارسازهای Kea یک رابط کنترلی RESTful بر روی HTTP فراهم می‌کنند. معمولاً انتظار می‌رود که این API توسط IPAMهای گوناگون و سیستم‌های مدیریتی مشابه استفاده شود. با این وجود، ممکن است مواردی پیش بیاید که مدیر سیستم بخواهد فرمانی را مستقیماً به کارساز بفرستد، و پوسته Kea راهکاری برای انجام این کار فراهم می‌کند. این ابزار یک کلاینت متنی خط فرمانیِ ساده و سازگار با اسکریپت‌نویسی است که می‌تواند به کارساز متصل شود، دستورها را همراه با پارامترها به آن ارسال کند، پاسخ‌ها را بازیابی کرده و نمایش دهد.

از آنجا که هدف اصلی پوسته Kea به کارگیری به عنوان ابزاری در محیط اسکریپت‌نویسی است، تعاملی (interactive) نیست. با این حال، با دنبال کردن دستورالعمل‌های ساده می‌توان آن را به صورت دستی نیز اجرا کرد.

نسخه 1.9.0 از Kea پشتیبانی از احراز هویت پایه‌ای HTTP (basic HTTP authentication) را معرفی کرد.

نکته:

نسخه 2.7.2 از Kea پشتیبانی مستقیم از کانال کنترلی HTTP/HTTPS را توسط کارسازهای Kea (kea-dhcp4 <#std-iscman-kea-dhcp4>، kea-dhcp6 <#std-iscman-kea-dhcp6> و kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>) معرفی کرده است. ابزار kea-shell <#std-iscman-kea-shell> می‌تواند با این کارسازها استفاده شود؛ تنها تفاوت این است که آرگومان --service بی‌فایده شده و توسط کارسازهای Kea نادیده گرفته می‌شود. توجه داشته باشید که نتیجه جهت سازگاری با نسخه‌های پیشین (backward compatibility) در قالب یک لیست کپسوله‌بندی می‌شود.

kea-shell <#std-iscman-kea-shell> به شکل زیر اجرا می‌شود:

$ kea-shell [--host hostname] [--port number] [--path path] [--auth-user] [--auth-password] [--auth-password-file] [--timeout seconds] [command]

که در آن:

  • --host hostname نام میزبان (hostname) کارساز را مشخص می‌کند. در صورت عدم تعیین، "localhost" استفاده می‌شود.
  • --port number درگاه (port) TCP را که کارساز روی آن گوش می‌دهد مشخص می‌کند. در صورت عدم تعیین، 8000 استفاده می‌شود.
  • --path path مسیر موجود در URL را برای اتصال مشخص می‌کند. اگر تعیین نشود، یک مسیر خالی استفاده خواهد شد. از آنجا که کارساز روی مسیر خالی گوش می‌دهد، این پارامتر تنها هنگام استفاده از یک پراکسی معکوس (reverse proxy) کاربرد دارد.
  • --auth-user شناسه کاربری را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. اگر تعیین نشود یا به صورت یک رشته خالی مشخص شود، احراز هویت استفاده نخواهد شد.
  • --auth-password گذرواژه را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. در صورتی که مشخص نشده باشد اما شناسه کاربری تعیین شده باشد، یک گذرواژه خالی استفاده می‌شود. اگر همراه با --auth-password-file به کار رود، نادیده گرفته می‌شود.
  • --auth-password-file یک فایل متنی را مشخص می‌کند که خط اول آن حاوی گذرواژه مورد استفاده برای احراز هویت پایه‌ای HTTP است. این پرچم بر پرچم --auth-password اولویت دارد. توصیه می‌شود هنگام تنظیم مجوزهای دسترسی برای فایل حاوی گذرواژه احتیاط شود. دسترسی به فایل باید تا حد امکان محدود بوده و تنها به مدیران Kea محدود شود.
  • --timeout seconds مهلت زمانی (timeout بر حسب ثانیه) را برای اتصال مشخص می‌کند. اگر داده نشود، 10 ثانیه استفاده می‌شود.
  • --service service-name اکنون منسوخ شده است اما برای سازگاری با گذشته همچنان شناسایی می‌شود.
  • command دستوری را که باید ارسال شود مشخص می‌کند. در صورت عدم تعیین، دستور list-commands <#std-isccmd-list-commands> استفاده می‌شود.

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

  • -h - یک پیام راهنما چاپ می‌کند.
  • -v - نسخه Kea را نمایش می‌دهد.
  • -V - نسخه گسترده Kea را نمایش می‌دهد.

برای آرگومان‌های خط فرمان جدید مربوط به پشتیبانی از TLS/HTTPS، به بخش TLS Support مراجعه کنید.

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

برای فهرستی از دستورات در دسترس، به Management API <#ctrl-channel> مراجعه کنید؛ ممکن است دستورات اضافی توسط کتابخانه‌های هوک (hook) ارائه شوند. برای دریافت فهرستی از تمام دستورات پشتیبانی‌شده توسط کارساز، از دستور list-commands <#std-isccmd-list-commands> استفاده کنید.

نمونه ساده‌ای از نحوه استفاده در زیر نشان داده شده است:

$ kea-shell --host 192.0.2.1 --port 8001 --auth-user foo --auth-password-file secret_file list-commands
^D

پس از وارد کردن خط فرمان، برنامه منتظر ورود پارامترهای دستور می‌ماند. از آنجا که list-commands <#std-isccmd-list-commands> هیچ آرگومانی نمی‌پذیرد، Ctrl-D (که در مثال بالا با "^D" نشان داده شده است) بیانگر پایان فایل (end-of-file) بوده و ورودی پارامترها را خاتمه می‌دهد. سپس پوسته با کارساز ارتباط برقرار کرده و فهرست دستورات در دسترس بازگردانده‌شده برای کارساز را چاپ می‌کند.

پوسته Kea احتمالاً بیشتر در اسکریپت‌ها مورد استفاده قرار خواهد گرفت؛ مثال بعدی یک اجرای اسکریپت‌شده ساده را نشان می‌دهد. این مثال دستور config-write <#std-isccmd-config-write> را به همراه پارامترهای مشخص‌شده در param.json به کارساز ارسال می‌کند. نتیجه در result.json ذخیره خواهد شد.

$ cat param.json
"filename": "my-config-file.json"
$ cat param.json | kea-shell --host 192.0.2.1 config-write > result.json

هنگامی که از یک پراکسی معکوس برای تفکیک (de-multiplex) درخواست‌ها به کارسازهای مختلف استفاده می‌شود، مسیر خالیِ پیش‌فرض در URL کافی نیست؛ بنابراین باید از پارامتر --path استفاده شود. برای نمونه، اگر درخواست‌های ارسال‌شده به مسیر "/kea" به کارساز هدایت شوند، می‌توان این مورد را به کار برد:

$ kea-shell --host 192.0.2.1 --port 8001 --path kea ...

پوسته Kea نیازمند نصب بودن Python روی سیستم است. این ابزار با نسخه‌های مختلف Python 3 آزمایش شده است.

نکته:

از نسخه 2.4.0 کی‌آ به بعد، kea-shell <#std-iscman-kea-shell> دیگر از Python 2.7 پشتیبانی نمی‌کند.

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

نکته:

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

ابزار kea-shell <#std-iscman-kea-shell> از اتصالات HTTPS پشتیبانی می‌کند؛ پشتیبانی از TLS/HTTPS نیازمند Python 3 است. آرگومان‌های اضافی خط فرمان عبارتند از:

  • --ca نام فایل یا دایرکتوری مرجع صدور گواهی (CA) را مشخص می‌کند. در صورت عدم تعیین، از HTTPS استفاده نمی‌شود.
  • --cert نام فایل گواهی کلید عمومی نهاد نهایی (end-entity) کاربر را مشخص می‌کند. در صورت تعیین، نام فایل کلید کاربر نیز باید مشخص شود.
  • --key نام فایل کلید کاربر را مشخص می‌کند. در صورت تعیین، نام فایل گواهی کاربر نیز باید مشخص شود. فایل‌های کلید رمزنگاری‌شده پشتیبانی نمی‌شوند.

برای مثال، یک درخواست پایه HTTPS برای دریافت فهرست دستورات می‌تواند به این صورت باشد:

$ kea-shell --host 127.0.0.1 --port 8000 --ca ./kea-ca.crt list-commands

سامانه Kea پشتیبانی اختیاری از انواع سیستم‌های خارجی مانند RADIUS، NETCONF، YANG و GSS-TSIG را فراهم می‌آورد. بخش‌های زیر نحوه کامپایل Kea به همراه این قابلیت‌های اضافی و چگونگی پیکربندی آن‌ها را شرح می‌دهند.

پروتکل پیکربندی شبکه یا NETCONF، یک پروتکل مدیریت شبکه است که در RFC 6241 https://datatracker.ietf.org/doc/html/rfc6241 تعریف شده است. این پروتکل از زبان مدل‌سازی YANG، تعریف‌شده در RFC 6020 https://datatracker.ietf.org/doc/html/rfc6020، برای ایجاد روشی یکپارچه جهت مدیریت ساختار نحوی پیکربندی دستگاه‌های مختلف شبکه بهره می‌برد. Kea پشتیبانی اختیاری از یک رابط YANG/NETCONF را از طریق عامل kea-netconf <#std-iscman-kea-netconf> فراهم می‌کند.

برای دستیابی به قابلیت‌های NETCONF، نرم‌افزار Kea به نسخه‌های v3 از libyang و Sysrepo نیاز دارد. نسخه‌های خاصی که به طور کامل با Kea آزمایش شده‌اند عبارتند از:

  • libyang v3.13.5 (کامیت efe43e3790822a3dc64d7d28db935d03fff8b81f)
  • sysrepo v3.7.11 (کامیت 1b720b196f630f348d9e0c131d326b3fb8c6aca7)
  • libyang-cpp v3 (کامیت f3cd4e05462a16e81d6bfd0c4a5b385cf88a8549)
  • sysrepo-cpp v3 (کامیت fe4edfa3998fdf312099ee1fb08a06983b6907f6)

نکته:

kea-netconf <#std-iscman-kea-netconf> ممکن است با نسخه‌های جدیدتر libyang و Sysrepo سازگار باشد، اما تنها نسخه‌های ذکرشده در بالا به طور کامل توسط ISC آزمایش شده‌اند.

در صورتی که بسته‌ها توسط سیستم ارائه شده باشند، نصب از طریق بسته‌ها پیشنهاد می‌شود. در غیر این صورت، کاربران می‌توانند طبق راهنمای زیر برنامه را از روی کد منبع بسازند که باید بر روی تمام سیستم‌عامل‌های رایج کار کند.

$ git clone https://github.com/CESNET/libyang.git
$ cd libyang
$ git checkout v3.13.5
$ mkdir build
$ cd build
$ cmake ..
$ make
$ make install

$ git clone https://github.com/sysrepo/sysrepo.git
$ cd sysrepo
$ git checkout v3.7.11
$ mkdir build
$ cd build
$ cmake -DREPO_PATH=/etc/sysrepo ..
$ make
$ make install  # without sudo if you're doing development and want to run unit tests

$ git clone https://github.com/CESNET/libyang-cpp.git
$ cd libyang-cpp
$ git checkout v3
$ mkdir build
$ cd build
$ cmake -DBUILD_TESTING=OFF ..
$ make
$ make install

$ git clone https://github.com/sysrepo/sysrepo-cpp.git
$ cd sysrepo-cpp
$ git checkout v3
$ mkdir build
$ cd build
$ cmake -DBUILD_TESTING=OFF ..
$ make
$ make install
1.
دریافت سورس‌کدهای Kea.
$ git clone gitlab.isc.org/isc-projects/kea.git
$ cd kea
2.
آماده‌سازی ساخت.
$ meson setup build -D netconf=enabled -D cpp_std=c++20

نکته:

اگر هر یک از کتابخانه‌ها در یک مکان سفارشی نصب شده باشند، متغیر PKG_CONFIG_PATH می‌تواند به فایل‌های .pc اشاره کند.
PKG_CONFIG_PATH=:/opt/libyang/lib/pkgconfig:/opt/libyang-cpp/lib/pkgconfig:/opt/sysrepo/lib/pkgconfig:/opt/sysrepo-cpp/lib/pkgconfig
3.
برای بررسی پشتیبانی از NETCONF، فایل build/config.report را بررسی کنید.
NETCONF:
  YANG:               2.1.4
  YANG_PREFIX:        /opt/libyang
  YANGCPP:            1.1.0
  YANGCPP_PREFIX:     /opt/libyang-cpp
  SYSREPO:            2.2.12
  SYSREPO_PREFIX:     /opt/sysrepo
  SYSREPOCPP:         1.1.0
  SYSREPOCPP_PREFIX:  /opt/sysrepo-cpp
4.
طبق معمول کامپایل کنید.
$ meson compile -C build

این بخش مرور کوتاهی بر زیرمجموعه‌ای از قابلیت‌های موجود در Sysrepo ارائه می‌دهد. برای اطلاعات کامل‌تر، به صفحه اصلی Sysrepo در https://www.sysrepo.org مراجعه کنید.

در YANG، پیکربندی‌ها و داده‌های وضعیت با نحو YANG در فایل‌های ماژولی به نام <module-name>[@<revision>].yang توصیف می‌شوند.

بخش بازبینی (revision) اختیاری است و از قالب YYYY-MM-DD پیروی می‌کند. یک نحو XML جایگزین به نام YIN نیز تعریف شده است اما کاربرپسندی کمتری دارد. ماژول‌های سطح بالا در مدل‌های Kea (نسخه کوتاه‌شده مدل‌های طرح‌واره) نام‌گذاری می‌شوند.

دو ماژول اصلی وجود دارند که Kea قادر به پشتیبانی از آن‌هاست: kea-dhcp4-server و kea-dhcp6-server. اگرچه تلاشی فعال در کارگروه DHC در IETF برای توسعه مدل YANG برای DHCPv6 در جریان است، ابتکار مشابهی در گذشته برای DHCPv4 با شکست مواجه شد. بنابراین، Kea از مدل‌های اختصاصی خود برای DHCPv4 و DHCPv6 استفاده می‌کند اما به صورت جزئی از مدل IETF برای DHCPv6 نیز پشتیبانی می‌کند.

همه این مدل‌ها دارای ماژول‌های اضافی به عنوان پیش‌نیاز هستند که آن‌ها نیز ارائه شده‌اند. تمام این ماژول‌ها را می‌توان در src/share/yang/modules در سورس‌کدها و در share/kea/yang/modules در دایرکتوری محل نصب یافت. در دستورهای زیر، از این دایرکتوری با عنوان ${share_directory} یاد می‌شود.

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

$ ${share_directory}/yang/modules/utils/reinstall.sh

با این حال، اگر در طول فرآیند ارتقا مشکلی پیش بیاید و بتوان داده‌ها را از طریق یک کلاینت NETCONF یا روش‌های دیگر دوباره ایجاد کرد، ماژول‌های Kea را می‌توان قبل از نصب مجدد، به راحتی با این دستور حذف نصب کرد:

$ ${share_directory}/yang/modules/utils/reinstall.sh -u

این اسکریپت باید بتواند Sysrepo را مجدداً نصب کند. با این حال، از پرچم -s نیز می‌توان برای مشخص کردن یک مسیر استفاده کرد:

$ ./build/src/share/yang/modules/utils/reinstall.sh -s /path/to/sysrepo

برای نصب تک‌تک تمام ماژول‌ها:

$ cd ./src/share/yang/modules
$ sysrepoctl -i ./ietf-dhcpv6-server*.yang
$ sysrepoctl -i ./kea-dhcp4-server*.yang
$ sysrepoctl -i ./kea-dhcp6-server*.yang
...

فرآیند نصب باید مشابه موارد زیر باشد:

$ ./build/src/share/yang/modules/utils/reinstall.sh
[INF] Connection 2 created.
[INF] Module "keatest-module" was installed.
[INF] File "keatest-module@2022-11-30.yang" was installed.
[INF] No datastore changes to apply.
[INF] Connection 4 created.
[ERR] Module "ietf-interfaces@2018-02-20" already installed.
[INF] No datastore changes to apply.
[INF] Connection 7 created.
[ERR] Module "ietf-dhcpv6-client" is already in sysrepo.
[INF] No datastore changes to apply.
[INF] Connection 9 created.
[ERR] Module "ietf-dhcpv6-relay" is already in sysrepo.
[INF] No datastore changes to apply.
[INF] Connection 11 created.
[ERR] Module "ietf-dhcpv6-server" is already in sysrepo.
[INF] No datastore changes to apply.
[INF] Connection 13 created.
[ERR] Write permission "ietf-yang-types" check failed.
[INF] No datastore changes to apply.
[INF] Connection 15 created.
[ERR] Module "ietf-dhcpv6-options" is already in sysrepo.
[INF] No datastore changes to apply.
[INF] Connection 17 created.
[ERR] Module "ietf-dhcpv6-types" is already in sysrepo.
[INF] No datastore changes to apply.
[INF] Connection 21 created.
[INF] Module "kea-types" was installed.
[INF] File "kea-types@2019-08-12.yang" was installed.
[INF] No datastore changes to apply.
[INF] Connection 23 created.
[INF] Module "kea-dhcp-types" was installed.
[INF] File "kea-dhcp-types@2022-11-30.yang" was installed.
[INF] No datastore changes to apply.
[INF] Connection 25 created.
[INF] Module "kea-dhcp-ddns" was installed.
[INF] File "kea-dhcp-ddns@2022-07-27.yang" was installed.
[INF] No datastore changes to apply.
[INF] Connection 27 created.
[INF] Connection 28 created.
[INF] Module "kea-dhcp4-server" was installed.
[INF] File "kea-dhcp4-server@2022-11-30.yang" was installed.
[INF] No datastore changes to apply.
[INF] Connection 30 created.
[INF] Module "kea-dhcp6-server" was installed.
[INF] File "kea-dhcp6-server@2022-11-30.yang" was installed.
[INF] No datastore changes to apply.

برای اطمینان از اینکه ماژول‌ها به درستی وارد (import) شده‌اند، فهرست ماژول‌های YANG نصب‌شده فعلی را بررسی کنید. باید مشابه این باشد:

$ sysrepoctl -l
Sysrepo repository: /etc/sysrepo
Module Name                | Revision   | Flags | Owner     | Startup Perms | Submodules | Features
---------------------------------------------------------------------------------------------------
ietf-datastores            | 2018-02-14 | I     | user:user | 444           |            |
ietf-dhcpv6-client         | 2018-09-04 | I     | user:user | 600           |            |
ietf-dhcpv6-options        | 2018-09-04 | I     | user:user | 600           |            |
ietf-dhcpv6-relay          | 2018-09-04 | I     | user:user | 600           |            |
ietf-dhcpv6-server         | 2018-09-04 | I     | user:user | 600           |            |
ietf-dhcpv6-types          | 2018-09-04 | I     | user:user | 600           |            |
ietf-inet-types            | 2013-07-15 | I     | user:user | 444           |            |
ietf-interfaces            | 2018-02-20 | I     | user:user | 600           |            |
ietf-netconf               | 2013-09-29 | I     | user:user | 644           |            |
ietf-netconf-acm           | 2018-02-14 | I     | user:user | 600           |            |
ietf-netconf-notifications | 2012-02-06 | I     | user:user | 644           |            |
ietf-netconf-with-defaults | 2011-06-01 | I     | user:user | 444           |            |
ietf-origin                | 2018-02-14 | I     | user:user | 444           |            |
ietf-yang-library          | 2019-01-04 | I     | user:user | 644           |            |
ietf-yang-metadata         | 2016-08-05 | i     |           |               |            |
ietf-yang-schema-mount     | 2019-01-14 | I     | user:user | 644           |            |
ietf-yang-types            | 2013-07-15 | I     | user:user | 444           |            |
kea-dhcp-ddns              | 2022-07-27 | I     | user:user | 600           |            |
kea-dhcp-types             | 2022-11-30 | I     | user:user | 600           |            |
kea-dhcp4-server           | 2022-11-30 | I     | user:user | 600           |            |
kea-dhcp6-server           | 2022-11-30 | I     | user:user | 600           |            |
kea-types                  | 2019-08-12 | I     | user:user | 600           |            |
keatest-module             | 2022-11-30 | I     | user:user | 600           |            |
sysrepo-monitoring         | 2022-04-08 | I     | user:user | 600           |            |
sysrepo-plugind            | 2022-03-10 | I     | user:user | 644           |            |
yang                       | 2022-06-16 | I     | user:user | 444           |            |
Flags meaning: I - Installed/i - Imported; R - Replay support

برای نصب مجدد یک ماژول، اگر مدخل بازبینی (revision) در YANG افزایش یافته باشد، نصب ساده آن را به طور خودکار به‌روزرسانی خواهد کرد. در غیر این صورت، ابتدا باید حذف نصب شود:

$ sysrepoctl -u kea-dhcp4-server

اگر ماژول توسط ماژول‌های دیگر استفاده (یعنی وارد/import) شده باشد، تنها پس از آنکه ماژول‌های وابسته ابتدا حذف نصب شدند، می‌توان آن را حذف نصب کرد. نصب و حذف نصب باید به ترتیب وابستگی و ترتیب معکوس وابستگی، بسته به مورد، انجام گیرد..SS مدل‌های پشتیبانی‌شدهٔ YANG (Supported YANG Models)

مدل‌های پشتیبانی‌شده در حال حاضر kea-dhcp4-server و kea-dhcp6-server هستند. پشتیبانی جزئی از ietf-dhcpv6-server وجود دارد، اما تمرکز اصلی آزمایش‌ها روی سرورهای Kea DHCP بوده است. سایر مدل‌ها (مانند kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns>) در حال حاضر پشتیبانی نمی‌شوند.

کارگزار NETCONF از این الگوریتم پیروی می‌کند:

  • برای هر سرور مدیریت‌شده، پیکربندی اولیه را از طریق سوکت کنترل از سرور دریافت می‌کند.
  • یک اتصال با محیط Sysrepo باز کرده و دو نشست با مخازن دادهٔ startup و running برقرار می‌سازد.
  • بررسی می‌کند که ماژول‌های استفاده‌شده (غیرضروری / not-essential) و مورد نیاز (ضروری / essential) با نسخهٔ بازبینی (revision) صحیح در مخزن Sysrepo نصب شده باشند. اگر یک ماژول ضروری - یعنی ماژولی که طرح‌وارهٔ (schema) پیکربندی برای یک سرور مدیریت‌شده در آن تعریف شده است - نصب نشده باشد، یک خطای مهلک (fatal error) صادر می‌کند.
  • برای هر سرور مدیریت‌شده، پیکربندی YANG را از مخزن دادهٔ startup دریافت کرده، آن را به JSON ترجمه می‌کند و روی سروری که در حال پیکربندی است بارگذاری می‌نماید.
  • برای هر سرور مدیریت‌شده، یک فراخوانی برگشتی (callback) تغییر ماژول را با استفاده از نام مدل آن ثبت (subscribe) می‌کند.
  • هنگامی که یک پیکربندی running تغییر می‌کند، تلاش می‌کند تا پیکربندی به‌روزرسانی‌شده را از طریق فراخوانی برگشتی به سرور مدیریت‌شده اعتبارسنجی یا بارگذاری کند.

رفتار شرح‌داده‌شده در «استفاده از کارگزار NETCONF» توسط چندین پرچم پیکربندی کنترل می‌شود، که می‌توانند در دامنهٔ سراسری (global scope) یا در دامنهٔ یک سرور مدیریت‌شدهٔ خاص تنظیم شوند. در صورت مورد دوم، مقدار تعریف‌شده در دامنهٔ سرور مدیریت‌شده اولویت دارد. این پرچم‌ها عبارتند از:

  • boot-update - فاز پیکربندی اولیه را کنترل می‌کند؛ هنگامی که true باشد (پیش‌فرض)، ابتدا پیکربندی اولیهٔ دریافت‌شده از فایل پیکربندی کلاسیک JSON سرور Kea بارگذاری شده و سپس مدل YANG در زمان راه‌اندازی (startup) بارگذاری می‌شود. این تنظیم به مدیران سیستم امکان می‌دهد یک سوکت کنترل را در فایل JSON محلی تعریف کرده و سپس پیکربندی را از YANG بارگیری کنند. در صورت تنظیم روی false، از این فاز صرف‌نظر می‌شود.
  • subscribe-changes - اشتراک تغییرات ماژول را کنترل می‌کند؛ هنگامی که true باشد (پیش‌فرض)، یک فراخوانی برگشتی تغییر ماژول ثبت می‌شود، اما هنگامی که false باشد از این فاز صرف‌نظر شده و به‌روزرسانی‌های پیکربندی running غیرفعال می‌شوند. هنگامی که روی true تنظیم شود، از مخزن دادهٔ running برای اشتراک تغییرات استفاده می‌شود.
  • validate-changes - نحوهٔ نظارت Kea بر تغییرات پیکربندی Sysrepo را کنترل می‌کند. Sysrepo دو مرحله را ارائه می‌دهد که Kea می‌تواند در آن‌ها تعامل داشته باشد: اعتبارسنجی (validation) و اِعمال (application). در مرحلهٔ اعتبارسنجی (یا رویداد SR_EV_CHANGE طبق نام‌گذاری در Sysrepo)، Kea پیکربندی تازه نهایی‌شده (committed) را دریافت کرده و آن را راستی‌آزمایی می‌کند. اگر پیکربندی به هر دلیلی نادرست باشد، سرورهای Kea آن را رد می‌کنند و خطا به Sysrepo پس فرستاده می‌شود، که متعاقباً یک خطا بازمی‌گرداند. این مرحله تنها در صورتی انجام می‌شود که validate-changes روی true تنظیم شده باشد. در مرحلهٔ اِعمال (یا رویداد SR_EV_UPDATE طبق نام‌گذاری در Sysrepo)، پیکربندی واقعی اِعمال می‌شود. در این مرحله Kea می‌تواند پیکربندی را دریافت کند، اما برای گزارش هرگونه خطا به عقب بسیار دیر است چرا که پیکربندی قبلاً نهایی شده است.

ایدهٔ نهفته در فاز پیکربندی اولیه این است که سرورهای Kea با حداقل پیکربندی که تنها شامل یک سوکت کنترل است راه‌اندازی شوند تا مدیریت‌پذیر گردند. برای نمونه، برای سرور DHCPv4:

{
    "Dhcp4": {
        "control-socket": {
           "socket-name": "kea-dhcp4-ctrl.sock",
           "socket-type": "unix"
        }
    }
}

با فعال بودن اشتراک‌های تغییرات ماژول، دیمن kea-netconf <#std-iscman-kea-netconf> هرگونه تغییر پیکربندی را به محض پدیدار شدن در Sysrepo نظارت می‌کند. چنین تغییراتی را می‌توان با استفاده از ابزار sysrepocfg یا از راه دور با استفاده از هر کلاینت NETCONF انجام داد. برای جزئیات، لطفاً به مستندات Sysrepo یا A Step-by-Step NETCONF Agent Operation Example مراجعه کنید. از این ابزارها می‌توان برای اصلاح پیکربندی‌های YANG در مخزن دادهٔ running استفاده کرد. توجه داشته باشید که پیکربندی‌های ثبت‌شده (committed) تنها در مخزن دادهٔ running به‌روزرسانی می‌شوند؛ برای حفظ آن‌ها در بین راه‌اندازی‌های مجدد سرور، باید در مخزن دادهٔ startup کپی شوند.

هنگامی که تغییرات ماژول ردیابی می‌شوند (با استفاده از subscribe-changes تنظیم‌شده روی true) و پیکربندی running تغییر کرده است (مثلاً با استفاده از sysrepocfg یا هر کلاینت NETCONF)، فراخوانی برگشتی پیکربندی اصلاح‌شده را اعتبارسنجی کرده (اگر validate-changes روی false تنظیم نشده باشد) و برای دومین بار جهت اِعمال پیکربندی جدید اجرا می‌شود. اگر اعتبارسنجی ناموفق باشد، فراخوانی برگشتی همچنان دوباره فراخوانی می‌شود اما با یک رویداد SR_EV_ABORT (در مقابل SR_EV_DONE) به همراه تغییرات بازگردانی (rollback).

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

چهار حالت وجود دارد که در آن‌ها ممکن است یک پیکربندی اصلاح‌شدهٔ YANG نادرست باشد:

1.
ممکن است با طرح‌واره (schema) ناسازگار باشد؛ برای نمونه یک مدخل ناشناخته، نبودِ یک مدخل اجباری، مقداری با نوع نادرست، یا عدم تطابق با یک قید (constraint).
2.
ممکن است در ترجمه از YANG به JSON شکست بخورد؛ مانند یک بافت کاربری (user context) نامعتبر.
3.
ممکن است در بررسی‌های سلامت (sanity checks) سرور Kea رد شود؛ مانند یک محدودهٔ خارج از استخر زیرشبکه (out-of-subnet-pool) یا یک نوع پایگاه‌دادهٔ پشتیبانی‌نشده.
4.
نحو ممکن است درست باشد و بررسی‌های سلامت سرور را با موفقیت بگذراند، اما پیکربندی در زمان اجرا با شکست مواجه شود؛ برای نمونه، پیکربندی حاوی اطلاعات احراز هویت پایگاه‌داده باشد اما پایگاه‌داده اتصال را رد کند.

حالت نخست توسط Sysrepo مدیریت می‌شود. حالت‌های دوم و سوم توسط kea-netconf <#std-iscman-kea-netconf> در فاز اعتبارسنجی رسیدگی می‌شوند (در صورتی که با تنظیم validate-changes روی true غیرفعال نشده باشد). مورد آخر باعث می‌شود فاز اِعمال بدون گزارشی معقول به Sysrepo با شکست مواجه شود.

سرورها و کارگزارهای مدیریت‌شدهٔ Kea در بخش managed-servers شرح داده شده‌اند. هر زیربخش با نام سرویس آغاز می‌شود: dhcp4، dhcp6 و d2.

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

  • پرچم‌های کنترلی - boot-update، subscribe-changes و/یا validate-changes.
  • model - نام مدل/ماژول YANG را مشخص می‌کند. برای هر سرویس، پیش‌فرض مدل متناظر Kea YANG است؛ به عنوان نمونه برای "dhcp4" برابر با "kea-dhcp4-server" است.
  • control-socket - سوکت کنترل را برای مدیریت پیکربندی سرویس مشخص می‌کند.

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

  • socket-type - نوع سوکت یکی از موارد stdout، unix یا http است. stdout مقدار پیش‌فرض است؛ این گزینه در واقع یک سوکت نیست، اما به kea-netconf <#std-iscman-kea-netconf> اجازه می‌دهد در حالت اشکال‌زدایی اجرا شود که در آن همه‌چیز در stdout چاپ می‌شود، و همچنین می‌تواند برای هدایت مجدد آسان دستورات استفاده شود. unix کانال کنترل مستقیم و استاندارد سرور است که از سوکت‌های UNIX استفاده می‌کند؛ http از یک کانال کنترل استفاده می‌کند که اتصالات HTTP را می‌پذیرد.
  • socket-name - نام سوکت محلی برای نوع سوکت unix (پیش‌فرض یک رشتهٔ خالی است).
  • socket-url - آدرس URL مبتنی بر HTTP برای نوع سوکت http (پیش‌فرض http://127.0.0.1:8000).

بافت‌های کاربری (User contexts) می‌توانند داده‌های دلخواه را تا زمانی که دارای نحو معتبر JSON باشند و عنصر سطح بالای آن‌ها یک نگاشت (map) باشد (یعنی داده‌ها باید در آکولاد محصور شده باشند) ذخیره کنند. آن‌ها در مدخل NETCONF، یعنی در دامنه‌های زیرِ سطح بالا، مدخل managed-service و مدخل control-socket پذیرفته می‌شوند.

کتابخانه‌های قلاب (Hook libraries) می‌توانند درست مانند سایر سرورها یا کارگزارها توسط کارگزار NETCONF بارگذاری شوند؛ با این حال، در حال حاضر هیچ نقطهٔ قلابی (hook point) تعریف نشده است. فهرست hooks-libraries حاوی فهرستی از کتابخانه‌های قلاب است که باید توسط kea-netconf <#std-iscman-kea-netconf> بارگذاری شوند، به همراه اطلاعات پیکربندی آن‌ها که با parameters مشخص می‌شود.

لطفاً برای جزئیات مربوط به نحوهٔ پیکربندی ثبت رویدادها، Logging <#logging> را بررسی کنید. نام ثبت‌کنندهٔ اصلی کارگزار NETCONF برابر با kea-netconf <#std-iscman-kea-netconf> است، همان‌طور که در مثال بالا نشان داده شده است..SS نمونه‌ای از پیکربندی kea-netconf <#std-iscman-kea-netconf>

مثال زیر پیکربندی پایه NETCONF را نشان می‌دهد. مثال‌های بیشتری در دایرکتوری doc/examples/netconf در کدهای منبع Kea در دسترس است.

// این یک مثال ساده از پیکربندی برای عامل NETCONF است.
// این سرور یک رابط YANG برای تمامی سرورهای Kea و عامل فراهم می‌کند.
{
    "Netconf":
    {
        // پرچم‌های کنترلی را می‌توان در حوزه سراسری یا
        // در حوزه یک سرور مدیریت‌شده تعریف کرد. ترتیب اولویت‌ها عبارتند از:
        // - استفاده از مقدار پیش‌فرض (true)
        // - استفاده از مقدار سراسری
        // - استفاده از مقدار محلی.
        // بنابراین این گزینه، مقدار پیش‌فرض را بازنویسی می‌کند:
        "boot-update": false,
        // این نگاشت مشخص می‌کند هر سرور چگونه مدیریت می‌شود. برای هر سرور
        // یک نام از مدل YANG برای استفاده و کانال کنترل وجود دارد.
        // در حال حاضر سه نوع کانال کنترل پشتیبانی می‌شوند:
        // "stdout" که پیکربندی را در خروجی استاندارد چاپ می‌کند،
        // "unix" که از کانال کنترل محلی پشتیبانی‌شده توسط سرورهای
        // "dhcp4" و "dhcp6" استفاده می‌کند (پشتیبانی از "d2" هنوز در دسترس نیست)،
        // و "http" که از کانال‌های کنترل HTTP/HTTPS استفاده می‌کند.
        "managed-servers":
        {
            // به این روش kea-netconf می‌تواند با سرور DHCPv4 ارتباط برقرار کند.
            "dhcp4":
            {
                "comment": "DHCPv4 server",
                "model": "kea-dhcp4-server",
                "control-socket":
                {
                    "socket-type": "unix",
                    "socket-name": "kea4-ctrl-socket"
                }
            },
            // پارامترهای DHCPv6.
            "dhcp6":
            {
                "model": "kea-dhcp6-server",
                "control-socket":
                {
                    "socket-type": "unix",
                    "socket-name": "kea6-ctrl-socket"
                }
            },
            "d2":
            {
                "model": "kea-dhcp-ddns",
                "control-socket":
                {
                    "socket-type": "unix",
                    "socket-name": "kea-ddns-ctrl-socket",
                    "user-context": { "in-use": true }
                }
            },
            "dhcp4-http":
            {
                "comment": "DHCPv4 server using HTTP",
                "model": "kea-dhcp4-server",
                "control-socket":
                {
                    "socket-type": "http",
                    "socket-url": "http://127.0.0.1:8000/"
                }
            }
        },
        // ابزار kea-netconf قادر است کتابخانه‌های hook را برای ارتقای عملکرد خود بارگذاری کند.
        // در حال حاضر هیچ نقطه hookای در پردازش kea-netconf
        // تعریف نشده است.
        "hooks-libraries": [
            // فهرست کتابخانه‌های hook می‌تواند شامل بیش از یک کتابخانه باشد.
            {
                // تنها پارامتر ضروری، نام فایل کتابخانه است.
                "library": "custom_hooks_example.so",
                // برخی کتابخانه‌ها ممکن است از پارامترها پشتیبانی کنند. دقت کنید
                // که این بخش را با دقت وارد کنید، زیرا kea-netconf آن را
                // اعتبارسنجی نمی‌کند (چرا که قالب آن مختص همان کتابخانه است).
                "parameters": {
                    "param1": "foo"
                }
            }
        ],
        // همانند سایر مؤلفه‌های Kea، بخش NETCONF نیز از ثبت گزارش استفاده می‌کند.
        "loggers": [
            {
                "name": "kea-netconf",
                "output-options": [
                    {
                        "output": "/var/log/kea/kea-netconf.log",
                        // علاوه بر خروجی معمول، چندین پارامتر
                        // اضافی نیز ممکن است.
                        // پارامتر Flush تعیین می‌کند آیا ثبت‌کننده خروجی را
                        //  در فایل تخلیه می‌کند یا خیر.
                        // پارامتر Maxsize حداکثر اندازه فایل را پیش از چرخش
                        // آن تعیین می‌کند.
                        // پارامتر Maxver حداکثر تعداد فایل‌های چرخیده‌شده
                        //  برای نگهداری را مشخص می‌کند.
                        "flush": true,
                        "maxsize": 204800,
                        "maxver": 4
                    }
                ],
                "severity": "INFO",
                "debuglevel": 0
            }
        ]
    }
}

kea-netconf <#std-iscman-kea-netconf> گزینه‌های خط فرمان زیر را می‌پذیرد:

  • -c file - فایل پیکربندی را مشخص می‌کند.
  • -d - مشخص می‌کند که آیا ثبت گزارش‌های عامل باید به حالت اشکال‌زدایی/پرجزئیات تغییر کند یا خیر. در حالت پرجزئیات، شدت ثبت گزارش و debuglevel مشخص‌شده در فایل پیکربندی نادیده گرفته شده و شدت "debug" و بیشترین سطح اشکال‌زدایی (99) فرض می‌شود. این پرچم برای تغییر موقت سرور به حداکثر جزئیات، مثلاً هنگام اشکال‌زدایی، مناسب است.
  • -t file - فایل پیکربندی را برای آزمودن مشخص می‌کند. kea-netconf <#std-iscman-kea-netconf> تلاش می‌کند آن را بارگذاری کرده و بررسی‌های سلامت را انجام دهد؛ برخی بررسی‌ها تنها هنگام اجرای سرور واقعی امکان‌پذیر هستند. وضعیت واقعی با کد خروج گزارش می‌شود (0 = پیکربندی معتبر به نظر می‌رسد، 1 = با خطا مواجه شد). هنگام آزمودن پیکربندی، Kea پیام‌های گزارش را به خروجی استاندارد و خطاها را به خطای استاندارد ارسال می‌کند.
  • -v - نسخه kea-netconf <#std-iscman-kea-netconf> را نمایش داده و خارج می‌شود.
  • -V - اطلاعات تفصیلی نسخه kea-netconf <#std-iscman-kea-netconf> را نمایش داده و خارج می‌شود. این فهرست شامل نسخه‌های کتابخانه‌هایی است که به صورت پویا به Kea پیوند خورده‌اند.
  • -W - گزارش پیکربندی Kea را نمایش داده و خارج می‌شود. این گزارش رونوشتی از فایل config.report تولیدشده توسط meson setup است؛ این گزارش در باینری اجرایی تعبیه شده است.

    محتوای فایل config.report همچنین می‌تواند با بررسی برخی کتابخانه‌ها در درخت نصب یا درخت کد مبدا در دسترس قرار گیرد.

# from installation using libkea-process.so
$ strings ${prefix}/lib/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.so
$ strings src/lib/process/.libs/libkea-process.so | sed -n 's/;;;; //p'
# from sources using libkea-process.a
$ strings src/lib/process/.libs/libkea-process.a | sed -n 's/;;;; //p'
# from sources using libcfgrpt.a
$ strings src/lib/process/cfgrpt/.libs/libcfgrpt.a | sed -n 's/;;;; //p'

نکته:

نسخه‌هایی از پیکربندی‌های نمونه ارائه‌شده در این بخش را می‌توان در کد مبدا Kea، تحت مسیر doc/examples/netconf/kea-dhcp6-operations یافت.

سیستم آزمایشی دارای یک رابط اترنت به نام eth1 است. در برخی سیستم‌ها امکان تغییر نام رابط‌ها وجود دارد؛ برای نمونه، در لینوکس با یک رابط ens38:

# ip link set down dev ens38
# ip link set name eth1 dev ens38
# ip link set up dev eth1

این رابط باید آدرسی در پیشوند آزمایشی داشته باشد:

# ip -6 addr add 2001:db8::1/64 dev eth1

سرور Kea DHCPv6 باید با پیکربندی مشخص‌کننده یک سوکت کنترلی برای دریافت دستورات کنترلی اجرا شود. فرایند kea-netconf <#std-iscman-kea-netconf> از این سوکت برای برقراری ارتباط با سرور DHCPv6 استفاده می‌کند، یعنی پیکربندی‌های ترجمه‌شده را با استفاده از دستورات کنترلی به آن سرور ارسال می‌نماید. در ادامه نمونه‌ای از پیکربندی سوکت کنترلی برای سرور Kea DHCPv6 آورده شده است:

{
    "Dhcp6": {
        "control-socket": {
           "socket-name": "kea-dhcp6-ctrl.sock",
           "socket-type": "unix"
        }
    }
}

به منظور اجرای سرور Kea DHCPv6 با استفاده از پیکربندی موجود در فایل netconf/kea-dhcp6-operations/boot.json <#config-example-netconf-kea-dhcp6-operations-boot-json>، دستور زیر را اجرا کنید:

# kea-dhcp6 -d -c boot.json

پیکربندی فعلی سرور را می‌توان از طریق یک سوکت کنترلی با اجرای دستور زیر دریافت کرد:

# echo '{ "command": "config-get" }' | socat UNIX:/opt/kea/var/run/kea/kea-dhcp6-ctrl.sock '-,ignoreeof'

پیکربندی نمونه netconf/kea-dhcp6-operations/netconf.json <#config-example-netconf-kea-dhcp6-operations-netconf-json> برای kea-netconf <#std-iscman-kea-netconf>، جهت مدیریت سرور Kea DHCPv6 به شرح زیر است:

{
  "Netconf": {
    "loggers": [
      {
        "debuglevel": 99,
        "name": "kea-netconf",
        "output-options": [
          {
            "output": "stderr"
          }
        ],
        "severity": "DEBUG"
      }
    ],
    "managed-servers": {
      "dhcp6": {
        "control-socket": {
          "socket-name": "kea-dhcp6-ctrl.sock",
          "socket-type": "unix"
        }
      }
    }
  }
}

توجه داشته باشید که در محیط‌های عملیاتی نباید نیازی به ثبت گزارش در سطح DEBUG وجود داشته باشد.

عامل Kea NETCONF با دستور زیر راه‌اندازی می‌شود:

# kea-netconf -d -c netconf.json

اکنون که هر دو kea-netconf <#std-iscman-kea-netconf> و kea-dhcp6 <#std-iscman-kea-dhcp6> در حال اجرا هستند، می‌توان به‌روزرسانی‌های پیکربندی را به سرور DHCPv6 اعمال کرد. در ادامه پیکربندی استخراج‌شده از startup.xml آمده است:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <subnet6>
    <id>1</id>
    <pool>
      <start-address>2001:db8::1:0</start-address>
      <end-address>2001:db8::1:ffff</end-address>
      <prefix>2001:db8::1:0/112</prefix>
    </pool>
    <subnet>2001:db8::/64</subnet>
  </subnet6>
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <control-socket>
    <socket-name>kea-dhcp6-ctrl.sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
</config>

برای اعمال این پیکربندی جدید:

$ sysrepocfg -d startup -f xml -m kea-dhcp6-server --import=startup.xml

kea-netconf <#std-iscman-kea-netconf> در فاز مقداردهی اولیه خود، پس از مشترک شدن در تغییرات ماژول در مخزن داده running نرم‌افزار Sysrepo، پیکربندی موجود در مخزن داده startup را به تمام سرورهای Kea ارسال می‌کند. این اقدام، پیکربندی را از مخزن داده startup به مخزن داده running کپی کرده و مخزن داده running را فعال و دردسترس می‌سازد.

تغییرات اعمال‌شده بر مخزن داده running، پس از اعتبارسنجی روی سرورهای Kea اعمال می‌شوند. توجه داشته باشید که این تغییرات به‌طور پیش‌فرض به مخزن داده startup کپی نمی‌شوند؛ بدین معنا که تغییرات دائمی نیستند.

نکته:

kea-netconf <#std-iscman-kea-netconf> تمام پیکربندی را از هر مخزن داده Sysrepo در یک عملیات واحد get-config در NETCONF دریافت می‌کند. پیش از Kea 2.3.2، عملیات get-config برای هر گره برگ (leaf) و لیست برگ (leaf-list) به‌طور جداگانه انجام می‌شد.

چهار دسته مشکل در پیکربندی‌های اعمال‌شده از طریق NETCONF وجود دارد:

1.
پیکربندی با شِمای (schema) YANG مطابقت ندارد.
2.
پیکربندی نمی‌تواند از YANG به JSON مربوط به Kea ترجمه شود.
3.
پیکربندی توسط سرور Kea رد می‌شود.
4.
پیکربندی توسط سرور Kea اعتبارسنجی شده اما قابل اعمال نیست.

در حالت نخست، فایل پیکربندی BAD-schema.xml زیر را در نظر بگیرید:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <subnet4>
    <id>1</id>
    <pool>
      <start-address>2001:db8::1:0</start-address>
      <end-address>2001:db8::1:ffff</end-address>
      <prefix>2001:db8::1:0/112</prefix>
    </pool>
    <subnet>2001:db8::/64</subnet>
  </subnet4>
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <control-socket>
    <socket-name>kea-dhcp6-ctrl.sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
</config>

این فایل مستقیماً توسط sysrepocfg رد می‌شود:

$ sysrepocfg -d running -f xml -m kea-dhcp6-server --import=BAD-schema.xml

در حالت دوم، پیکربندی توسط kea-netconf <#std-iscman-kea-netconf> رد می‌شود. برای نمونه، این فایل BAD-translator.xml را در نظر بگیرید:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <subnet6>
    <id>1</id>
    <pool>
      <start-address>2001:db8::1:0</start-address>
      <end-address>2001:db8::1:ffff</end-address>
      <prefix>2001:db8::1:0/112</prefix>
    </pool>
    <subnet>2001:db8::/64</subnet>
  </subnet6>
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <control-socket>
    <socket-name>kea-dhcp6-ctrl.sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
  <user-context>bad</user-context>
</config>

در حالت سوم، پیکربندی به سرور Kea DHCPv6 ارائه شده و اعتبارسنجی آن با شکست مواجه می‌شود، مانند این فایل BAD-config.xml:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <subnet6>
    <id>1</id>
    <pool>
      <start-address>2001:db8:1::0</start-address>
      <end-address>2001:db8:1::ffff</end-address>
      <prefix>2001:db8:1::0/112</prefix>
    </pool>
    <subnet>2001:db8::/64</subnet>
  </subnet6>
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <control-socket>
    <socket-name>kea-dhcp6-ctrl.sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
</config>

در حالت آخر، پیکربندی نادرست خیلی دیر تشخیص داده می‌شود و تغییرات باید در Sysrepo بازگردانی (revert) شوند، مثلاً با استفاده از پایگاه داده (datastore) آغازین (startup) به عنوان پشتیبان.

این نمونه یک استخر دوم را به پیکربندی اولیه (یعنی startup) در فایل twopools.xml اضافه می‌کند:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <subnet6>
    <id>1</id>
    <pool>
      <start-address>2001:db8::1:0</start-address>
      <end-address>2001:db8::1:ffff</end-address>
      <prefix>2001:db8::1:0/112</prefix>
    </pool>
    <pool>
      <start-address>2001:db8::2:0</start-address>
      <end-address>2001:db8::2:ffff</end-address>
      <prefix>2001:db8::2:0/112</prefix>
    </pool>
    <subnet>2001:db8::/64</subnet>
  </subnet6>
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <control-socket>
    <socket-name>kea-dhcp6-ctrl.sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
</config>

این پیکربندی با دستور زیر نصب می‌شود:

$ sysrepocfg -d running -f xml -m kea-dhcp6-server --import=twopools.xml

این مثال دو زیرشبکه را در فایل twosubnets.xml مشخص می‌کند:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <subnet6>
    <id>1</id>
    <pool>
      <start-address>2001:db8:1::</start-address>
      <end-address>2001:db8:1::ffff</end-address>
      <prefix>2001:db8:1::/112</prefix>
    </pool>
    <subnet>2001:db8:1::/64</subnet>
  </subnet6>
  <subnet6>
    <id>2</id>
    <pool>
      <start-address>2001:db8:2::</start-address>
      <end-address>2001:db8:2::ffff</end-address>
      <prefix>2001:db8:2::/112</prefix>
    </pool>
    <subnet>2001:db8:2::/64</subnet>
  </subnet6>
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <control-socket>
    <socket-name>kea-dhcp6-ctrl.sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
</config>

این پیکربندی با دستور زیر نصب می‌شود:

$ sysrepocfg -d running -f xml -m kea-dhcp6-server --import=twosubnets.xml

این مثال یک مدخل ثبت وقایع (logger) را به پیکربندی اولیه (یعنی هنگام راه‌اندازی) در فایل logging.xml اضافه می‌کند:

<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp6-server">
  <interfaces-config>
    <interfaces>eth1</interfaces>
  </interfaces-config>
  <subnet6>
    <id>1</id>
    <pool>
      <start-address>2001:db8::1:0</start-address>
      <end-address>2001:db8::1:ffff</end-address>
      <prefix>2001:db8::1:0/112</prefix>
    </pool>
    <subnet>2001:db8::/64</subnet>
  </subnet6>
  <control-socket>
    <socket-name>kea-dhcp6-ctrl.sock</socket-name>
    <socket-type>unix</socket-type>
  </control-socket>
  <logger>
    <name>kea-dhcp6</name>
    <output-option>
      <output>stderr</output>
    </output-option>
    <debuglevel>99</debuglevel>
    <severity>DEBUG</severity>
  </logger>
</config>

پیکربندی متناظر Kea در قالب JSON عبارت است از:

{
  "Dhcp6": {
    "control-socket": {
      "socket-name": "kea-dhcp6-ctrl.sock",
      "socket-type": "unix"
    },
    "interfaces-config": {
      "interfaces": [ "eth1" ]
    },
    "subnet6": [
      {
        "id": 1,
        "pools": [
          {
            "pool": "2001:db8::1:0/112"
          }
        ],
        "subnet": "2001:db8::/64"
      }
    ],
    "loggers": [
      {
        "name": "kea-dhcp6",
        "output-options": [
          {
            "output": "stderr"
          }
        ],
        "severity": "DEBUG",
        "debuglevel": 99
      }
    ]
  }
}

در نهایت، هر یک از مثال‌های پیشین را می‌توان با استفاده از sysrepocfg در حالت ویرایش به صورت زیر مجدداً اجرا کرد:

$ sysrepocfg -d running -f xml -m kea-dhcp6-server --edit

یا با استفاده از یک کلاینت NETCONF مانند netopeer2-cli از مجموعه ابزار NETCONF پروژه Netopeer2 https://github.com/CESNET/Netopeer2..SS مهاجرت داده‌های YANG از نسخه پیشین Sysrepo

1. برنامه kea-netconf <#std-iscman-kea-netconf> را متوقف کنید. این کار تضمین می‌کند که پشتیبان‌گیری از هر دو datastore در یک وضعیت پیکربندی یکسان انجام شود و هیچ تغییری میان برون‌بری (export) آن‌ها رخ ندهد.

2.
از تمام ماژول‌های YANG نسخه پشتیبان تهیه کنید، به‌طوری که برای هر datastore یک فایل XML ایجاد شود.
$ sysrepocfg --datastore running --export=save.xml --format=xml
$ sysrepocfg --datastore startup --export=save.xml --format=xml

نکته:

نسخه Sysrepo v0 از درون‌ریزی/برون‌بری تمام ماژول‌های YANG پشتیبانی نمی‌کند؛ این قابلیت در Sysrepo v1 افزوده شده است. کاربرانی که از Sysrepo v0 مهاجرت می‌کنند باید پشتیبان‌گیری را به ازای هر ماژول به‌طور جداگانه انجام دهند. این کار مزیت مضاعفی در جداسازی خرابی‌های احتمالی و جلوگیری از اثرگذاری آن‌ها بر روی تمام ماژول‌ها دارد. دستور مورد استفاده یکسان است، با این تفاوت که نام ماژول در پایان به آن افزوده می‌شود.
$ sysrepocfg --datastore running --export=save.xml --format=xml kea-dhcp6-server
$ sysrepocfg --datastore startup --export=save.xml --format=xml kea-dhcp6-server
3.
نرم‌افزار Sysrepo را به نسخه جدیدتر ارتقا دهید و سپس دستورات زیر را اجرا کنید:
$ sysrepocfg --datastore running --import=save.xml
$ sysrepocfg --datastore startup --import=save.xml

نرم‌افزار Kea از به‌روزرسانی‌های DNS پشتیبانی می‌کند که می‌توان آن‌ها را با استفاده از امضاهای تراکنش (Transaction Signatures یا TSIG) محافظت کرد. این سطح از محافظت اغلب کافی است. با این حال، برخی سیستم‌ها، به‌ویژه Active Directory (AD) در سرورهای Microsoft Windows، رویکرد پیچیده‌تر GSS-TSIG را برگزیده‌اند که قابلیت‌های بیشتری همچون استفاده از کلیدهای پویای مذاکره‌شده را ارائه می‌دهد.

نرم‌افزار Kea از GSS-TSIG برای محافظت از به‌روزرسانی‌های DNS ارسال‌شده توسط سرور Kea DHCP-DDNS (D2) از طریق یک هوک (hook) به نام libddns_gss_tsig.so <#std-ischooklib-libddns_gss_tsig.so> پشتیبانی می‌کند.

استاندارد GSS-TSIG در RFC 3645 https://datatracker.ietf.org/doc/html/rfc3645 تعریف شده است. خود پروتکل GSS-TSIG پیاده‌سازی سرویس‌های عمومی GSS-API v2 است که در RFC 2743 https://datatracker.ietf.org/doc/html/rfc2743 تعریف شده است.

پروتکل‌های متعددی در این سازوکار دخیل هستند:

به‌طور خلاصه، GSS-API برای Kerberos 5 به همراه SPNEGO و TKEY برای مذاکره بر سر یک بافتار امنیتی (security context) میان سرور Kea D2 و یک سرور DNS استفاده می‌شوند:

[تصویر]

سپس این بافتار امنیتی توسط GSS-TSIG برای محافظت از به‌روزرسانی‌ها به کار گرفته می‌شود:

[تصویر]

پیاده‌سازی Kea از GSS-TSIG از یک کتابخانه GSS-API برای Kerberos 5 به همراه SPNEGO استفاده می‌کند. دو پیاده‌سازی این معیارها را برآورده می‌کنند: MIT Kerberos 5 و Heimdal..SS کامپایل GSS-TSIG

روال زیر روی دبیان ۱۲ (Debian 12) آزمایش شده است. رویکرد مشابهی را می‌توان برای سایر سیستم‌ها نیز به کار برد.

1.
یکی از کتابخانه‌های MIT (libkrb5-dev) یا Heimdal (heimdal-dev) را نصب کنید، برای نمونه:
sudo apt install libkrb5-dev
2.
سورس‌کدهای Kea را دریافت کرده و آن‌ها را استخراج کنید.
3.
مراحل ساخت را برپا کنید:
meson setup build -D krb5=enabled
4.
مطمئن شوید که build/config.report مدخل Kerberos5 GSS-API را نمایش می‌دهد.
Kerberos5 GSS-API:
  VERSION:         1.20.1
  VENDOR:          MIT

حضور فایل krb5.pc یا ابزار krb5-config الزامی است. این موارد توسط هر دو پیاده‌سازی MIT Kerberos 5 و Heimdal ارائه می‌شوند؛ با این حال، در برخی سیستم‌ها که هر دو مورد Kerberos 5 و Heimdal نصب شده‌اند، این ابزار یک پیوند نمادین (symbolic link) به یکی از آن‌ها است. اگر ابزار در مکان استاندارد قرار ندارد، می‌توان آن را با تنظیم PKG_CONFIG_PATH=/path/to/krb5.pc:${PKG_CONFIG_PATH} یا PATH=/path/to/krb5-config:${PATH} پیش از meson setup مشخص کرد.

6.
با دستور meson compile -C build کامپایل کنید.
7.
پس از کامپایل، libddns_gss_tsig.so <#std-ischooklib-libddns_gss_tsig.so> در
دایرکتوری build/src/hooks/d2/gss_tsig در دسترس خواهد بود. این پرونده می‌تواند توسط kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> بارگذاری شود.

پرونده libddns_gss_tsig.so <#std-ischooklib-libddns_gss_tsig.so> از هر دو پیاده‌سازی MIT Kerberos 5 و Heimdal پشتیبانی می‌کند. پیاده‌سازی Heimdal درباره دسترسی‌های فایل‌های حساس امنیتی بسیار سخت‌گیر است و معروف است که پیام خطای نامفهومی صادر می‌کند. ایده خوبی است که این فایل‌ها ساده، با یک پیوند و بدون دسترسی برای گروه یا سایر کاربران نگه‌داشته شوند.

اسکریپت krb5-config باید یک گزینه --vendor فراهم کند که پیاده‌سازی را مشخص می‌سازد.

پیش از استفاده از GSS-TSIG، یک سرور DNS با قابلیت پشتیبانی از GSS-TSIG، مانند BIND 9 یا Microsoft Active Directory (AD) باید مستقر شده باشد. سایر پیاده‌سازی‌های دارای قابلیت GSS-TSIG ممکن است کار کنند، اما آزمایش نشده‌اند.

دو نوع جدول کلید (فایل‌های keytab) وجود دارد: جدول سیستمی که توسط سرورها استفاده می‌شود، و جدول‌های کلاینت که توسط کلاینت‌ها به کار می‌روند. برای Kerberos 5، نرم‌افزار Kea یک client (کلاینت) محسوب می‌شود.

کتابخانه کلاینت Kerberos 5 و ابزار kadmin را نصب کنید:

sudo apt install krb5-kdc krb5-admin-server

مثال‌های زیر از قلمرو (realm) فرضی EXAMPLE.ORG برای نمایش مراحل پیکربندی و تنظیمات مورد نیاز استفاده می‌کنند.

کتابخانه کلاینت Kerberos 5 باید از طریق به‌روزرسانی فایل krb5.conf (برای نمونه در لینوکس: /etc/krb5.conf) برای پذیرش درخواست‌های ورودی مربوط به قلمرو EXAMPLE.ORG پیکربندی شود:

[libdefaults]
    default_realm = EXAMPLE.ORG
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
[realms]
    EXAMPLE.ORG = {
            kdc = kdc.example.org
            admin_server = kdc.example.org
    }

علاوه بر فایل krb5.conf، فایل kdc.conf نیز می‌تواند استفاده شود (برای نمونه در لینوکس: /etc/krb5kdc/kdc.conf):

[kdcdefaults]
    kdc_ports = 750,88
[realms]
    EXAMPLE.ORG = {
        database_name = /var/lib/krb5kdc/principal
        admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
        acl_file = /etc/krb5kdc/kadm5.acl
        key_stash_file = /etc/krb5kdc/stash
        kdc_ports = 750,88
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des3-hmac-sha1
        #supported_enctypes = aes256-cts:normal aes128-cts:normal
        default_principal_flags = +preauth
    }

لیست کنترل دسترسی (ACL) دیمن kadmind باید طوری پیکربندی شود که به پرینسیپال (principal) کلاینت DNS برای دسترسی به پایگاه‌داده Kerberos 5 مجوز دهد (برای نمونه در لینوکس: /etc/krb5kdc/kadm5.acl):

DHCP/admin.example.org@EXAMPLE.ORG       *

گذرواژه مدیر سیستم برای قلمرو پیش‌فرض باید تنظیم شود:

krb5_newrealm

پس از نمایش پیام زیر، گذرواژه قلمرو پیش‌فرض را وارد کنید:

This script should be run on the master KDC/admin server to initialize
a Kerberos realm.  It will ask you to type in a master key password.
This password will be used to generate a key that is stored in
/etc/krb5kdc/stash.  You should try to remember this password, but it
is much more important that it be a strong password than that it be
remembered.  However, if you lose the password and /etc/krb5kdc/stash,
you cannot decrypt your Kerberos database.
Loading random data
Initializing database '/var/lib/krb5kdc/principal' for realm 'EXAMPLE.ORG',
master key name 'K/M@EXAMPLE.ORG'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:

سپس گذرواژه را دوباره وارد کنید:

Re-enter KDC database master key to verify:

در صورت اعمال موفقیت‌آمیز، پیام زیر نمایش داده می‌شود:

Now that your realm is set up you may wish to create an administrative
principal using the addprinc subcommand of the kadmin.local program.
Then, this principal can be added to /etc/krb5kdc/kadm5.acl so that
you can use the kadmin program on other computers.  Kerberos admin
principals usually belong to a single user and end in /admin.  For
example, if jruser is a Kerberos administrator, then in addition to
the normal jruser principal, a jruser/admin principal should be
created.
Don't forget to set up DNS information so your clients can find your
KDC and admin servers.  Doing so is documented in the administration
guide.

گام بعدی، ایجاد پرینسیپال‌ها برای سرور BIND 9 DNS (سرویسی که توسط GSS-TSIG TKEY محافظت می‌شود) و برای کلاینت DNS (سرور Kea DHCP-DDNS) است.

پرینسیپال سرور BIND 9 DNS (مورد استفاده برای احراز هویت) به شیوه زیر ایجاد می‌شود:

kadmin.local -q "addprinc -randkey DNS/server.example.org"

در صورت ایجاد موفقیت‌آمیز، پیام زیر نمایش داده می‌شود:

No policy specified for DNS/server.example.org@EXAMPLE.ORG; defaulting to no policy
Authenticating as principal root/admin@EXAMPLE.ORG with password.
Principal "DNS/server.example.org@EXAMPLE.ORG" created.

پرینسیپال سرور DNS باید برون‌بری شود تا بتواند توسط سرور BIND 9 DNS استفاده شود. تنها به این پرینسیپال نیاز است، و در فایل keytab با نام dns.keytab برون‌بری می‌شود.

kadmin.local -q "ktadd -k /usr/local/share/kea/dns.keytab DNS/server.example.org"

در صورت برون‌بری موفق، پیام زیر نمایش داده می‌شود:

Authenticating as principal root/admin@EXAMPLE.ORG with password.
Entry for principal DNS/server.example.org with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/usr/local/share/kea/dns.keytab.
Entry for principal DNS/server.example.org with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/usr/local/share/kea/dns.keytab.

پرینسیپال کلاینت DHCP (مورد استفاده توسط سرور Kea DHCP-DDNS) به این ترتیب ایجاد می‌شود:

kadmin.local -q "addprinc -randkey DHCP/admin.example.org"

در صورت ایجاد موفقیت‌آمیز، پیام زیر نمایش داده می‌شود:

No policy specified for DHCP/admin.example.org@EXAMPLE.ORG; defaulting to no policy
Authenticating as principal root/admin@EXAMPLE.ORG with password.
Principal "DHCP/admin.example.org@EXAMPLE.ORG" created.

پرینسیپال کلاینت DHCP باید برون‌بری شود تا بتواند توسط سرور Kea DHCP-DDNS و کتابخانه قلاب (hook) مربوط به GSS-TSIG استفاده شود. این پرینسیپال به فایل keytab کلاینت با نام dhcp.keytab صادر می‌شود.

kadmin.local -q "ktadd -k /usr/local/share/kea/dhcp.keytab DHCP/admin.example.org"

در نهایت، سرویس krb5-admin-server باید بازراه‌اندازی شود:

systemctl restart krb5-admin-server.service

کارساز DNS برنامه‌ی BIND 9 باید برای استفاده از GSS-TSIG و به‌کارگیری principal کارساز DNS که پیش‌تر از فایل keytab با نام dns.keytab صادر شده است، پیکربندی شود. به‌روزرسانی فایل named.conf الزامی است:

options {
    ...
    directory "/var/cache/bind";
    dnssec-validation auto;
    listen-on-v6 { any; };
    tkey-gssapi-keytab "/etc/bind/dns.keytab";
};
zone "example.org" {
    type master;
    file "/var/lib/bind/db.example.org";
    update-policy {
        grant "DHCP/admin.example.org@EXAMPLE.ORG" zonesub any;
    };
};
zone "84.102.10.in-addr.arpa" {
    type master;
    file "/etc/bind/db.10";
};

فایل‌های zone باید شامل مدخلی برای FQDN پرینسیپال کارساز یعنی server.example.org باشند.

فایل /etc/bind/db.10 باید ایجاد یا به‌روزرسانی شود:

;
; BIND reverse data file for local loopback interface
;
$TTL    604800                      ; 1 week
@       IN      SOA      server.example.org. root.example.org. (
                         2          ; Serial
                         604800     ; Refresh
                         86400      ; Retry
                         2419200    ; Expire
                         604800     ; Negative Cache TTL
                         )
;
@       IN      NS      ns.
40      IN      PTR     ns.example.org.

فایل /var/lib/bind/db.example.org باید ایجاد یا به‌روزرسانی شود:

$ORIGIN .
$TTL                604800             ; 1 week
example.org         IN SOA  server.example.org. root.example.org. (
                            8          ; serial
                            604800     ; refresh (1 week)
                            86400      ; retry (1 day)
                            2419200    ; expire (4 weeks)
                            604800     ; minimum (1 week)
                            )
                    NS      example.org.
                    A       ${BIND9_IP_ADDR}
                    AAAA    ::1
$ORIGIN example.org.
kdc                 A       ${KDC_IP_ADDR}
server              A       ${BIND9_IP_ADDR}

پس از هرگونه تغییر در پیکربندی، کارساز باید دوباره بارگذاری یا راه‌اندازی مجدد شود:

systemctl restart named.service

امکان دریافت وضعیت یا بررسی لاگ‌ها وجود دارد:

systemctl status named.service
journalctl -u named | tail -n 30

این زیربخش بر پایه‌ی Microsoft Windows Server 2016 ارائه‌شده توسط Amazon AWS با Active Directory از پیش نصب‌شده است، بنابراین تنها مراحلی را که برای استقرار GSS-TSIG به کار رفته‌اند شرح می‌دهد. (برای فرایند کامل پیکربندی، لطفاً به مستندات Microsoft یا سایر منابع خارجی مراجعه کنید. ما این راهنمای آموزشی را در https://www.tenforums.com/tutorials/51456-windows-server-2016-setup-local-domain-controller.html هنگام پیکربندی سیستم‌های آزمایش تضمین کیفیت (QA) داخلی خود بسیار مفید یافتیم.)

به دو حساب کاربری Active Directory (AD) نیاز است:
  • حساب نخست برای دریافت اطلاعات AD، مانند جدول کلید (key table) کلاینت Kea استفاده می‌شود
  • حساب دوم به principal کلاینت Kea DHCP نگاشت می‌شود
برنامه‌ی Kea باید از موارد زیر مطلع باشد:
  • نشانی IP کارساز
  • نام دامنه/realm: نام دامنه با حروف کوچک و realm با حروف بزرگ، هر دو بدون نقطه در انتها
  • نام کارساز

حساب دوم (که در زیر kea نامیده شده است) برای ایجاد یک Service Principal Name (SPN) به کار می‌رود:

setspn -S DHCP/kea.<domain> kea

سپس یک کلید مخفی مشترک تولید شده و در یک فایل جدول کلید (key table) قرار می‌گیرد:

ktpass -princ DHCP/kea.<domain>@<REALM> -mapuser kea +rndpass -mapop set -ptype KRB5_NT_PRINCIPAL -out dhcp.keytab

فایل dhcp.keytab کاربردی مشابه با UNIX Kerberos دارد..SS عیب‌یابی GSS-TSIG

هنگام آزمایش یکپارچه‌سازی GSS-TSIG با Active Directory به یک خطای بسیار مبهم برخوردیم:

INFO  [kea-dhcp-ddns.gss-tsig-hooks/4678.139690935890624] GSS_TSIG_VERIFY_FAILED GSS-TSIG verify failed: gss_verify_mic failed with GSSAPI error:
Major = 'A token had an invalid Message Integrity Check (MIC)' (393216), Minor = 'Packet was replayed in wrong direction' (100002).

در مورد ما، مشکل این بود که کارساز Kea D2 تلاش می‌کرد یک ناحیهٔ معکوس DNS را در حالی به‌روزرسانی کند که پیکربندی نشده بود. یک راه‌حل ساده، افزودن یک ناحیهٔ معکوس DNS مشابه آنچه در Kea پیکربندی شده است می‌باشد. برای این کار، "DNS Manager" را باز کرده و "DNS" را از فهرست انتخاب کنید؛ سپس از فهرست کشویی، "Reverse Lookup Zones" را برگزینید؛ بعد روی "Action" و "New Zone" کلیک کنید؛ در نهایت، New Zone Wizard را برای افزودن یک ناحیهٔ جدید دنبال کنید.

استاندارد به هر دو سرویس ضد بازپخش (anti-replay) و توالی (sequence) نیاز دارد. تجربیات به‌دست‌آمده با nsupdate در BIND 9 نشان داد که سرویس توالی منجر به بروز مشکلاتی می‌شود، بنابراین به‌طور پیش‌فرض در hook غیرفعال شده است. به نظر می‌رسد سرویس ضد بازپخش نیز می‌تواند باعث ایجاد مشکل در کارسازهای DNS مایکروسافت شود، بنابراین اکنون قابل پیکربندی است. توجه داشته باشید که این سرویس‌های امنیتی برای به‌روزرسانی پویای DNS، که برای اجرا روی UDP و در نتیجه همراه با پیام‌های نامرتب و تکراری طراحی شده، کاربردی ندارند.

برای فعال‌سازی سازوکار GSS-TSIG، چند مرحله لازم است:

1.
libddns_gss_tsig.so <#std-ischooklib-libddns_gss_tsig.so> باید توسط kea-dhcp-ddns <#std-iscman-kea-dhcp-ddns> بارگذاری شود.
2.
کارسازهای DNS با قابلیت پشتیبانی از GSS-TSIG باید به همراه پارامترهایشان مشخص شوند.

گزیده‌ای از پیکربندی کارساز D2 در زیر ارائه شده است؛ مثال‌های بیشتر در دایرکتوری doc/examples/ddns در سورس‌های Kea موجود است.

{
"DhcpDdns": {
    // The following parameters are used to receive NCRs (NameChangeRequests)
    // from the local Kea DHCP server. Make sure your kea-dhcp4 and kea-dhcp6
    // matches this.
    "ip-address": "127.0.0.1",
    "port": 53001,
    "dns-server-timeout" : 1000,
    // Forward zone: secure.example.org. It uses GSS-TSIG. It is served
    // by two DNS servers, which listen for DDNS requests at 192.0.2.1
    // and 192.0.2.2.
    "forward-ddns":
    {
        "ddns-domains":
        [
            // DdnsDomain for zone "secure.example.org."
            {
                "name": "secure.example.org.",
                "comment": "DdnsDomain example",
                "dns-servers":
                [
                    { // This server has an entry in gss/servers and
                      // thus will use GSS-TSIG.
                        "ip-address": "192.0.2.1"
                    },
                    { // This server also has an entry there, so will
                      // use GSS-TSIG, too.
                        "ip-address": "192.0.2.2",
                        "port": 5300
                    }
                ]
            }
        ]
    },
    // Reverse zone: we want to update the reverse zone "2.0.192.in-addr.arpa".
    "reverse-ddns":
    {
        "ddns-domains":
        [
            {
                "name": "2.0.192.in-addr.arpa.",
                "dns-servers":
                [
                    {
                        // There is a GSS-TSIG definition for this server (see
                        // DhcpDdns/gss-tsig/servers), so it will use
                        // Krb/GSS-TSIG.
                        "ip-address": "192.0.2.1"
                    }
                ]
            }
        ]
    },
    // The GSS-TSIG hook is loaded and its configuration is specified here.
    "hooks-libraries": [
    {
        "library": "libddns_gss_tsig.so",
        "parameters": {
            // This section governs the GSS-TSIG integration. Each server
            // mentioned in forward-ddns and/or reverse-ddns needs to have
            // an entry here to be able to use GSS-TSIG defaults (optional,
            // if specified they apply to all the GSS-TSIG servers, unless
            // overwritten on specific server level).
            "server-principal": "DNS/server.example.org@EXAMPLE.ORG",
            "client-principal": "DHCP/admin.example.org@EXAMPLE.ORG",
            // client-keytab and credentials-cache can both be used to
            // store client keys. As credentials cache is more flexible,
            // it is recommended to use it. Typically, using both at the
            // same time may cause problems.
            // "client-keytab": "FILE:/etc/dhcp.keytab", // toplevel only
            "credentials-cache": "FILE:/etc/ccache", // toplevel only
            "gss-replay-flag": true, // GSS anti replay service
            "gss-sequence-flag": false, // no GSS sequence service
            "tkey-lifetime": 3600, // 1 hour
            "rekey-interval": 2700, // 45 minutes
            "retry-interval": 120, // 2 minutes
            "tkey-protocol": "TCP",
            "fallback": false,
            // The list of GSS-TSIG capable servers
            "servers": [
                {
                    // First server (identification is required)
                    "id": "server1",
                    "domain-names": [ ], // if not specified or empty, will
                                         // match all domains that want to
                                         // use this IP+port pair
                    "ip-address": "192.0.2.1",
                    "port": 53,
                    "server-principal": "DNS/server1.example.org@EXAMPLE.ORG",
                    "client-principal": "DHCP/admin1.example.org@EXAMPLE.ORG",
                    "gss-replay-flag": false, // no GSS anti replay service
                    "gss-sequence-flag": false, // no GSS sequence service
                    "tkey-lifetime": 7200, // 2 hours
                    "rekey-interval": 5400, // 90 minutes
                    "retry-interval": 240, // 4 minutes
                    "tkey-protocol": "TCP",
                    "fallback": true // if no key is available fallback to the
                                     // standard behavior (vs skip this server)
                },
                {
                    // The second server (it has most of the parameters missing
                    // as those are using the defaults specified above)
                    "id": "server2",
                    "ip-address": "192.0.2.2",
                    "port": 5300
                }
            ]
        }
    }
    ]
    // Additional parameters, such as logging, control socket and
    // others omitted for clarity.
}
}

این فایل پیکربندی شامل تعدادی عنصر اضافی است.

نخست، فهرستی از دامنه‌های مستقیم و/یا معکوس همراه با کارسازهای DNS مربوطه که با جفت‌های IP+port مشخص شده‌اند، تعریف می‌شود. اگر پورت مشخص نشده باشد، مقدار پیش‌فرض 53 در نظر گرفته می‌شود. این مشابه حالت پایه است که در آن هیچ احراز هویتی با استفاده از کلیدهای TSIG انجام نمی‌شود، با این تفاوت که به کلیدهای استاتیک TSIG با نام ارجاع داده نمی‌شود.

دوم، libddns_gss_tsig.so <#std-ischooklib-libddns_gss_tsig.so> باید در فهرست hooks-libraries مشخص شود. این hook پارامترهای متعددی می‌گیرد. مهم‌ترین آن‌ها servers است که فهرستی از کارسازهای با قابلیت GSS-TSIG می‌باشد. اگر چندین کارساز وجود داشته باشد و ویژگی‌های مشترکی داشته باشند، مقادیر می‌توانند در حوزهٔ parameters به عنوان مقادیر پیش‌فرض تعیین شوند. در مثال بالا، مقادیر پیش‌فرضی که برای همهٔ کارسازها اعمال می‌شوند (مگر اینکه در سطح هر کارساز به‌طور خاص بازنویسی شده باشند)، در خطوط 63 تا 68 تعریف شده‌اند. اگر تنها یک کارساز تعریف شده باشد، یا اگر همهٔ کارسازها مقادیر متفاوتی داشته باشند، می‌توان از این مقادیر پیش‌فرض صرف‌نظر کرد..SS فهرست پارامترهای موجود

نام محدوده نوع مقدار پیش‌فرض توضیحات
client-keytab سراسری / سرور رشته خالی جدول کلید کلاینت در Kerberos
credentials-cache سراسری / سرور رشته خالی کَش گواهی‌های Kerberos
server-principal سراسری / سرور رشته خالی نام Kerberos principal کارگزار DNS که به‌روزرسانی‌ها را دریافت خواهد کرد
client-principal سراسری / سرور رشته خالی نام Kerberos principal سرویس Kea D2
gss-replay-flag سراسری / سرور true / false true الزام سرویس ضددوباره‌رسانی GSS (GSS_C_REPLAY_FLAG)
gss-sequence-flag سراسری / سرور true / false false الزام سرویس توالی GSS (GSS_C_SEQUENCE_FLAG)
tkey-protocol سراسری / سرور رشته "TCP" / "UDP" "TCP" پروتکل مورد استفاده برای برقراری زمینهٔ امنیتی (security context) با کارگزارهای DNS
tkey-lifetime سراسری / سرور uint32 3600 ثانیه ( 1 ساعت ) مدت‌زمان اعتبار کلیدهای GSS-TSIG

rekey-interval سراسری / سرور uint32 2700 ثانیه ( 45 دقیقه ) بازهٔ زمانی بررسی کلیدها جهت کلیدگذاری مجدد (rekeying)

retry-interval سراسری / سرور uint32 120 ثانیه ( 2 دقیقه ) بازهٔ زمانی تلاش مجدد برای ایجاد کلید در صورت وقوع هرگونه خطا در دفعات پیشین

fallback سراسری / سرور true / false false رفتار بازگشت به حالت غیر GSS-TSIG در شرایطی که GSS-TSIG باید استفاده شود اما هیچ کلید GSS-TSIGای موجود نیست.
exchange-timeout سراسری / سرور uint32 3000 میلی‌ثانیه ( 3 ثانیه ) مدت‌زمان انتظار برای اتمام تبادل GSS-TSIG TKEY پیش از آنکه مهلت زمانی آن به پایان برسد (timeout)

ignore-bad-direction سراسری true / false false نادیده گرفتن خطاهای اعتبارسنجی MIC نامعتبر / جهت نادرست (bad direction).
user-context سراسری / سرور رشته خالی داده‌های ارائه‌شده توسط کاربر در قالب JSON (توسط قلاب GSS-TSIG استفاده نمی‌شود)
comment سراسری / سرور رشته خالی نادیده گرفته می‌شود
id سرور رشته خالی شناسهٔ یک کارگزار DNS (الزامی)
domain-names سرور فهرستی از رشته‌ها خالی رابطهٔ چندبه‌یک بین کارگزارهای DNS در D2 و کارگزارهای DNS در GSS-TSIG
ip-address سرور آدرس IPv4 / IPv6 خالی آدرس IP که کارگزار DNS در GSS-TSIG برای درخواست‌های DDNS و TKEY روی آن گوش می‌دهد (الزامی)
port سرور uint16 53 درگاه انتقال DNS که کارگزار DNS در GSS-TSIG برای درخواست‌های DDNS و TKEY روی آن گوش می‌دهد

پارامترهای سراسری در ادامه شرح داده شده‌اند:

client-keytab جدول کلید (key table) client مربوط به Kerberos را مشخص می‌کند. برای نمونه، FILE:<filename> می‌تواند برای اشاره به یک فایل مشخص استفاده شود. این پارامتر تنها یک بار در حوزه (scope) پارامترها قابل تعیین است و معادل تنظیم متغیر محیطی KRB5_CLIENT_KTNAME می‌باشد. یک مقدار خالی بدون ایجاد پیام نادیده گرفته می‌شود.
  • credentials-cache حافظه موقت مدارک هویتی (credentials cache) مربوط به Kerberos را تعیین می‌کند. به عنوان مثال، FILE:<filename> می‌تواند برای اشاره به یک فایل به کار رود یا در صورت استفاده از دایرکتوری‌ای که از بیش از یک principal پشتیبانی می‌کند، DIR:<directory-path>. این پارامتر تنها یک بار در حوزه پارامترها قابل تعیین است و معادل مقداردهی به متغیر محیطی KRB5CCNAME می‌باشد. یک مقدار خالی بدون پیام نادیده گرفته می‌شود.
  • server-principal نام principal مربوط به Kerberos برای کارساز DNS است که به‌روزرسانی‌ها را دریافت می‌کند. به عبارت دیگر، این نام کارساز DNS در سامانه Kerberos است. این پارامتر اجباری است و از نشانه‌گذاری معمول Kerberos استفاده می‌کند: <SERVICE-NAME>/<server-domain-name>@<REALM>.
  • client-principal نام principal در Kerberos برای سرویس Kea D2 است. این پارامتر اختیاری است و از نشانه‌گذاری معمول Kerberos استفاده می‌کند: <SERVICE-NAME>/<server-domain-name>@<REALM>.
  • gss-replay-flag مشخص می‌کند که آیا سرویس ضد تکرار (anti replay) در GSS مورد نیاز است یا خیر. به طور پیش‌فرض فعال است اما می‌توان آن را غیرفعال کرد.
  • gss-sequence-flag مشخص می‌کند که آیا سرویس توالی (sequence) در GSS مورد نیاز است یا خیر. به طور پیش‌فرض فعال نیست، اما توسط استاندارد ملزم شده است بنابراین می‌تواند فعال شود.
  • tkey-protocol تعیین می‌کند که کدام پروتکل برای برقراری بافت امنیتی (security context) با کارسازهای DNS به کار رود. در حال حاضر، تنها مقادیر پشتیبانی‌شده TCP (پیش‌فرض) و UDP هستند.
  • tkey-lifetime طول عمر کلیدهای GSS-TSIG را در پروتکل TKEY مشخص می‌کند. این مقدار باید بیشتر از مقدار rekey-interval باشد. این پارامتر بر حسب ثانیه بیان شده و پیش‌فرض آن 3600 (یک ساعت) است.
  • rekey-interval فاصله زمانی بررسی کلیدها برای کلیدزنی مجدد (rekeying) به ازای هر کارساز پیکربندی‌شده را مدیریت می‌کند؛ به این معنی که اگر سن کلید قابل استفاده فعلی بیش از مقدار rekey-interval باشد، کلید جدیدی جایگزین آن می‌شود. این مقدار باید کمتر از مقدار tkey-lifetime باشد (توصیه می‌شود بین ۵۰٪ تا ۸۰٪ مقدار tkey-lifetime تنظیم شود). این پارامتر بر حسب ثانیه بیان شده و مقدار پیش‌فرض آن 2700 (۴۵ دقیقه، یا ۷۵٪ از یک ساعت) است.
  • retry-interval فاصله زمانی برای تلاش مجدد جهت ساخت کلید را، در صورت وقوع هرگونه خطای قبلی برای هر کارساز پیکربندی‌شده، مدیریت می‌کند. این مقدار باید کمتر از مقدار rekey-interval باشد، و حداکثر باید ۱/۳ اختلاف بین tkey-lifetime و rekey-interval باشد. این پارامتر بر حسب ثانیه بیان شده و پیش‌فرض آن 120 (۲ دقیقه) است.
  • fallback رفتار سامانه را در زمانی که GSS-TSIG باید استفاده شود (یک کارساز DNS منطبق پیکربندی شده است) اما هیچ کلید GSS-TSIG در دسترسی نیست، کنترل می‌کند. اگر روی false (پیش‌فرض) تنظیم شود، از این کارساز صرف‌نظر می‌شود؛ اگر روی true تنظیم شود، کارساز DNS نادیده گرفته شده و به‌روزرسانی DNS با محافظت DHCP-DDNS پیکربندی‌شده (مانند کلید TSIG)، یا بدون هیچ حفاظتی (در صورت عدم پیکربندی) ارسال می‌شود.
  • exchange-timeout مدت زمانی را تعیین می‌کند که فرآیند پیش از اتمام مهلت (timeout) برای پایان تبادل TKEY در GSS-TSIG منتظر می‌ماند. این مقدار بر حسب میلی‌ثانیه بیان شده و پیش‌فرض آن 3000 (۳ ثانیه) است.
  • user-context یک پارامتر اختیاری است (برای توضیحات عمومی درباره زمینه‌های کاربری در Kea، بخش Comments and User Context <#user-context> را ببینید).
  • comment مجاز است اما در حال حاضر نادیده گرفته می‌شود.
  • servers فهرست کارسازهای DNS که GSS-TSIG در آن‌ها فعال است را مشخص می‌کند.

پارامترهای نقشه کارساز (server map) در زیر شرح داده شده‌اند:

  • id یک شناسه به کارساز DNS اختصاص می‌دهد. از آن برای آمار و دستورها استفاده می‌شود. این پارامتر الزامی است و نباید خالی باشد و باید یکتا باشد.
  • domain-names رابطه چندبه‌یک میان کارسازهای DNS مربوط به D2 و کارسازهای DNS مربوط به GSS-TSIG را مدیریت می‌کند: برای هر نام دامنه در این فهرست، Kea به دنبال کارساز DNS در D2 برای این دامنه با آدرس IP و درگاه (port) مشخص‌شده می‌گردد. یک فهرست خالی (پیش‌فرض) به این معناست که تمام دامنه‌ها منطبق هستند.
  • ip-address آدرس IP که کارساز DNS مربوط به GSS-TSIG روی آن به درخواست‌های DDNS و TKEY گوش می‌دهد را مشخص می‌کند. این یک پارامتر الزامی است.
  • port درگاه انتقال DNS که کارساز DNS مربوط به GSS-TSIG روی آن به درخواست‌های DDNS و TKEY گوش می‌دهد را مشخص می‌کند. مقدار پیش‌فرض آن 53 است.
  • server-principal نام principal در Kerberos برای کارساز DNS است که به‌روزرسانی‌ها را دریافت می‌کند. پارامتر server-principal تنظیم‌شده در سطح هر کارساز بر مقداری که در سطح سراسری تنظیم شده، اولویت دارد. این پارامتر الزامی است و باید در سطح سراسری یا در سطح کارساز مشخص شود.
  • client-principal نام principal در Kerberos برای سرویس Kea D2 جهت این کارساز DNS است. پارامتر client-principal تنظیم‌شده در سطح هر کارساز بر مقداری که در سطح سراسری تعیین شده اولویت دارد. این یک پارامتر اختیاری است.
  • gss-replay-flag مشخص می‌کند که آیا سرویس ضد تکرار GSS مورد نیاز است یا خیر. پارامتر gss-replay-flag تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. این یک پارامتر اختیاری است که پیش‌فرض آن true می‌باشد.
  • gss-sequence-flag مشخص می‌کند که آیا سرویس توالی GSS مورد نیاز است یا خیر. پارامتر gss-sequence-flag تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. این یک پارامتر اختیاری است که مقدار پیش‌فرض آن false می‌باشد.
  • tkey-protocol مشخص می‌کند که چه پروتکلی برای برقراری بافت امنیتی با کارساز DNS به کار رود. پارامتر tkey-protocol تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر سطح هر کارساز همانند مقادیر پارامتر سطح سراسری است.
  • tkey-lifetime طول عمر کلیدهای GSS-TSIG را در پروتکل TKEY برای کارساز DNS مشخص می‌کند. پارامتر tkey-lifetime تنظیم‌شده در سطح هر کارساز بر مقدار تعیین‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز با مقادیر پارامتر در سطح سراسری یکسان است.
  • rekey-interval بازه زمانی را تعیین می‌کند که در آن کلیدهای این کارساز خاص برای کلیدزنی مجدد بررسی می‌شوند؛ بدین معنا که اگر سن کلید قابل استفاده فعلی از مقدار rekey-interval بیشتر باشد، کلید جدیدی جایگزین آن خواهد شد. این مقدار باید از مقدار tkey-lifetime کوچکتر باشد (توصیه می‌شود بین ۵۰٪ تا ۸۰٪ مقدار tkey-lifetime تنظیم گردد). پارامتر rekey-interval تنظیم‌شده در سطح هر کارساز بر مقداری که در سطح سراسری تنظیم شده اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز مانند پارامتر در سطح سراسری است.
  • retry-interval بازه زمانی تلاش مجدد برای ساخت کلید را در صورت وقوع هرگونه خطای قبلی برای این کارساز خاص مدیریت می‌کند. این مقدار باید از مقدار rekey-interval کوچکتر باشد و حداکثر ۱/۳ اختلاف بین tkey-lifetime و rekey-interval باشد. پارامتر retry-interval تنظیم‌شده در سطح هر کارساز بر مقدار تنظیم‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز همانند پارامتر در سطح سراسری است.
  • fallback رفتار سامانه را هنگامی که GSS-TSIG باید استفاده شود (یک کارساز DNS متناظر پیکربندی شده است) اما کلید GSS-TSIG در دسترس نیست کنترل می‌کند. پارامتر fallback تنظیم‌شده در سطح هر کارساز بر مقدار تعیین‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر سطح کارساز همانند مقادیر پارامتر در سطح سراسری است.
  • exchange-timeout مدت زمانی که پیش از اتمام مهلت فرآیند باید منتظر تبادل GSS-TSIG TKEY ماند را مدیریت می‌کند. پارامتر exchange-timeout تنظیم‌شده در سطح هر کارساز بر مقدار تعیین‌شده در سطح سراسری اولویت دارد. مقادیر پیش‌فرض و پشتیبانی‌شده برای پارامتر در سطح هر کارساز مانند پارامتر در سطح سراسری است.
  • ignore-bad-direction یک راه‌حل موقت (workaround) برای باگ کارساز Microsoft را مدیریت می‌کند. هنگامی که به طور صریح روی true تنظیم شود، پاسخ‌های به‌روزرسانی DNS ارسالی حتی اگر پیش‌نیازها با امضای درخواست شکست بخورند، به عنوان تأییدشده پذیرفته می‌شوند.
  • user-context یک پارامتر اختیاری است (برای توضیحات عمومی درباره زمینه‌های کاربری در Kea، بخش Comments and User Context <#user-context> را ببینید).
  • comment مجاز است اما در حال حاضر نادیده گرفته می‌شود.

نکته:

به طور کلی تعیین همزمان جدول کلید کلاینت (client-keytab) و حافظه موقت مدارک هویتی (credentials-cache) توصیه نمی‌شود، هرچند ممکن است این مورد در پیاده‌سازی‌های مختلف Kerberos متفاوت باشد. جدول کلید کلاینت تنها برای کلید کلاینت است و به طور معمول برای تعیین صریح کلید به روشی ایستا‌تر به کار می‌رود، در حالی که حافظه موقت مدارک هویتی می‌تواند چندین مدرک را ذخیره کند و می‌تواند توسط کتابخانه Kerberos به صورت پویا به‌روزرسانی شود. به همین دلیل، credentials-cache انعطاف‌پذیرتر بوده و در نتیجه گزینه توصیه‌شده است.

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

سرور به‌صورت دوره‌ای کلیدها را پس از این‌که مدت زمان انقضای آن‌ها بیش از سه برابر حداکثر عمر کلید (پارامتر tkey-lifetime) گذشته باشد، حذف می‌کند. کاربر این گزینه را دارد که با استفاده از دستور gss-tsig-purge-all یا دستور gss-tsig-purge کلیدها را بر حسب نیاز پاکسازی کند.

هنگام استفاده از Kerberos 5 و BIND 9 همان‌طور که در GSS-TSIG Deployment شرح داده شده است، تحلیل‌گر محلی (local resolver) باید به نشانی سرور named در BIND 9 اشاره کند. همچنین Kerberos محلی باید با قرار دادن متن زیر در فایل krb5.conf پیکربندی شود:

[libdefaults]
    default_realm = EXAMPLE.ORG
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
[realms]
    EXAMPLE.ORG = {
            kdc = kdc.example.org
            admin_server = kdc.example.org
    }

در Windows AD، سرویس DNS توسط AD ارائه می‌شود که سرویس Kerberos را نیز فراهم می‌کند. متن مورد نیاز در فایل krb5.conf به صورت زیر خواهد بود:

[libdefaults]
    default_realm = <REALM>
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
[realms]
    ${REALM} = {
            kdc = <AD_IP_ADDR>
            admin_server = <AD_IP_ADDR>
    }

حتی زمانی که کتابخانه GSS-API می‌تواند از کلید محرمانه موجود در جدول کلید (key table) کلاینت استفاده کند، از نظر کارایی، دریافت و کش کردن اعتبارنامه‌ها (credentials) به مراتب بهتر است.

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

kinit -k -t /usr/local/share/kea/dhcp.keytab DHCP/admin.example.org

یا هنگام استفاده از AD:

kinit -k -t /usr/local/share/kea/dhcp.keytab DHCP/kea.<domain>

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

در محیط عملیاتی، بهتر است به یک مدیریت‌کننده اعتبارنامه Kerberos مانند System Security Services Daemon (sssd) تکیه شود.

هنگام استفاده از BIND 9، پرینسیپال سرور (server principal) به شکل "<DNS/server.example.org@EXAMPLE>.ORG¨ است؛ با AD، قالب به صورت "DNS/<server>.<domain>@<REALM>" می‌باشد.

کتابخانه قلاب GSS-TSIG آمارهای جدیدی را در سطوح سراسری و به ازای هر سرور DNS معرفی می‌کند:

  • gss-tsig-key-created - تعداد کلیدهای GSS-TSIG ایجادشده
  • tkey-sent - تعداد درخواست‌های اولیه ارسالی برای تبادل TKEY
  • tkey-success - تعداد تبادلات TKEY که با موفقیت انجام شده‌اند
  • tkey-timeout - تعداد تبادلات TKEY که با اتمام مهلت زمانی (timeout) پایان یافته‌اند
  • tkey-error - تعداد تبادلات TKEY که با خطایی غیر از اتمام مهلت زمانی به پایان رسیده‌اند

رابطه بین کلیدها و سرورهای DNS بین کد D2 و کلیدهای ایستای TSIG، در مقایسه با کلیدهای GSS-TSIG و سرورهای DNS بسیار متفاوت است:

  • یک کلید ایستای TSIG می‌تواند بین چندین سرور DNS به اشتراک گذاشته شود؛
  • یک کلید GSS-TSIG تنها توسط یک سرور DNS درون یک مجموعه اختصاصی از کلیدها استفاده می‌شود.

کتابخانه قلاب GSS-TSIG از چند دستور پشتیبانی می‌کند که در زیر توضیح داده شده‌اند.

این دستور تمامی سرورها و کلیدهای GSS-TSIG را فهرست می‌کند.

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

{
    "command": "gss-tsig-get-all"
}

اینجا نمونه‌ای از پاسخی که یک سرور GSS-TSIG و یک کلید را بازمی‌گرداند آورده شده است:

{
    "result": 0,
    "text": "1 GSS-TSIG servers and 1 keys",
    "arguments": {
        "gss-tsig-servers": [
            {
                "id": "foo",
                "ip-address": "192.1.2.3",
                "port": 53,
                "server-principal": "DNS/foo.com@FOO.COM",
                "key-name-suffix": "foo.com.",
                "tkey-lifetime": 3600,
                "tkey-protocol": "TCP",
                "keys": [
                    {
                        "name": "1234.sig-foo.com.",
                        "inception-date": "2021-09-05 12:23:36.281176",
                        "server-id": "foo",
                        "expire-date": "2021-09-05 13:23:36.281176",
                        "status": "not yet ready",
                        "tkey-exchange": true
                    }
                ]
            },
            {
                "id": "bar",
                "ip-address": "192.1.2.4",
                "port": 53,
                "server-principal": "DNS/bar.com@FOO.COM",
                "key-name-suffix": "bar.com.",
                "tkey-lifetime": 7200,
                "tkey-protocol": "UDP",
                "keys": [ ]
            }
        ]
    }
}

این دستور اطلاعات مربوط به سرور GSS-TSIG مشخص‌شده را بازیابی می‌کند.

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

{
    "command": "gss-tsig-get",
    "arguments": {
        "server-id": "foo"
    }
}

در اینجا نمونه‌ای از یک پاسخ که اطلاعات مربوط به سرور "foo" را بازمی‌گرداند آورده شده است:

{
    "result": 0,
    "text": "GSS-TSIG server[foo] found",
    "arguments": {
        "id": "foo",
        "ip-address": "192.1.2.3",
        "port": 53,
        "server-principal": "DNS/foo.com@FOO.COM",
        "key-name-suffix": "foo.com.",
        "tkey-lifetime": 3600,
        "tkey-protocol": "TCP",
        "keys": [
            {
                "name": "1234.sig-foo.com.",
                "server-id": "foo",
                "inception-date": "2021-09-05 12:23:36.281176",
                "expire-date": "2021-09-05 13:23:36.281176",
                "status": "not yet ready",
                "tkey-exchange": true
            }
        ]
    }
}

این دستور فهرستی از شناسه سرورهای GSS-TSIG و نام کلیدها را ایجاد می‌کند.

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

{
    "command": "gss-tsig-list"
}

در اینجا نمونه‌ای از یک پاسخ که دو سرور GSS-TSIG و سه کلید را بازمی‌گرداند آورده شده است:

{
    "result": 0,
    "text": "2 GSS-TSIG servers and 3 keys",
    "arguments": {
        "gss-tsig-servers": [
            "foo",
            "bar"
        ],
        "gss-tsig-keys": [
            "1234.example.com.",
            "5678.example.com.",
            "43888.example.org."
        ]
    }
}

این دستور اطلاعات مربوط به کلید GSS-TSIG مشخص‌شده را بازیابی می‌کند.

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

{
    "command": "gss-tsig-key-get",
    "arguments": {
        "key-name": "1234.sig-foo.com."
    }
}

در اینجا نمونه‌ای از یک پاسخ که اطلاعات مربوط به کلید GSS-TSIG با عنوان "1234.sig-foo.com." را بازمی‌گرداند آورده شده است:

{
    "result": 0,
    "text": "GSS-TSIG key '1234.sig-foo.com.' found",
    "arguments": {
        "name": "1234.sig-foo.com.",
        "server-id": "foo",
        "inception-date": "2021-09-05 12:23:36.281176",
        "expire-date": "2021-09-05 13:23:36.281176",
        "status": "not yet ready",
        "tkey-exchange": true
    }
}

این دستور کلید GSS-TSIG مشخص‌شده را منقضی می‌کند.

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

{
    "command": "gss-tsig-key-expire",
    "arguments": {
        "key-name": "1234.sig-foo.com."
    }
}

در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد کلید GSS-TSIG با نام "1234.sig-foo.com." منقضی شده است:

{
    "result": 0,
    "text": "GSS-TSIG key '1234.sig-foo.com.' expired"
}

این دستور کلید GSS-TSIG مشخص‌شده را حذف می‌کند.

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

{
    "command": "gss-tsig-key-del",
    "arguments": {
        "key-name": "1234.sig-foo.com."
    }
}

در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد کلید GSS-TSIG با نام "1234.sig-foo.com." حذف شده است:

{
    "result": 0,
    "text": "GSS-TSIG key '1234.sig-foo.com.' deleted"
}

این دستور تمام کلیدهای غیرقابل‌استفاده‌ی GSS-TSIG را پاک‌سازی می‌کند.

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

{
    "command": "gss-tsig-purge-all"
}

در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد دو کلید GSS-TSIG پاک‌سازی شده‌اند:

{
    "result": 0,
    "text": "2 purged GSS-TSIG keys"
}

این دستور کلیدهای غیرقابل‌استفاده‌ی GSS-TSIG را برای سرور مشخص‌شده پاک‌سازی می‌کند.

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

{
    "command": "gss-tsig-purge",
    "arguments": {
        "server-id": "foo"
    }
}

در اینجا نمونه‌ای از یک پاسخ آورده شده است که نشان می‌دهد دو کلید GSS-TSIG برای سرور "foo" پاک‌سازی شده‌اند:

{
    "result": 0,
    "text": "2 purged keys for GSS-TSIG server[foo]"
}

این دستور بدون قید و شرط کلیدهای جدید GSS-TSIG را برای تمام کارگزارهای DNS مجدداً ایجاد می‌کند (عملیات تجدید کلید یا rekey).

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

{
    "command": "gss-tsig-rekey-all"
}

در ادامه نمونه‌ای از پاسخی که نشان می‌دهد تجدید کلید انجام شده است آورده شده است:

{
    "result": 0,
    "text": "rekeyed"
}

این دستور به عنوان مثال هنگامی که کارگزار DHCP-DDNS مجدداً به شبکه متصل می‌شود مفید است.

این دستور بدون قید و شرط کلیدهای جدید GSS-TSIG را برای یک کارگزار DNS مشخص بازتولید می‌کند (عملیات rekey).

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

{
    "command": "gss-tsig-rekey",
    "arguments": {
        "server-id": "foo"
    }
}

در ادامه نمونه‌ای از پاسخی که نشان می‌دهد تجدید کلید انجام شده است آورده شده است:

{
    "result": 0,
    "text": "GSS-TSIG server[foo] rekeyed"
}

این دستور معمولاً زمانی استفاده می‌شود که یک کارگزار DNS بازراه‌اندازی (reboot) شده باشد، به طوری که کلیدهای GSS-TSIG مشترک فعلی با این کارگزار دیگر قابل استفاده نباشند.

امنیت RADIUS/UDP (و RADIUS/TCP) مبتنی بر استفاده مستقیم از MD5 به همراه کلید مخفی مشترک (shared secret) و گذرواژه دسترسی کاربر است. این سازوکارهای امنیتی به ضعیف بودن شناخته می‌شدند، اما این موضوع با انتشار آسیب‌پذیری Blast-RADIUS در https://www.blastradius.fail (شناسه CVE-2024-3596 در https://www.cve.org/CVERecord?id=CVE-2024-3596) دگرگون شد.

به طور خلاصه، زمانی که زیرساخت ارتباطی میان کلاینت RADIUS (در اینجا کارگزار Kea DHCP) و کارگزار RADIUS محافظت‌نشده باشد، یک مهاجم مرد میانی (man-in-the-middle) می‌تواند در پاسخ به یک درخواست دسترسی / احراز هویت ناموفق، یک پیام پذیرش (accept) معتبر جعل کند.

برخی از کارگزارهای RADIUS از جمله کارگزار پرکاربرد FreeRADIUS از هم‌اکنون به صورت پیش‌فرض از پاسخ‌گویی به درخواست‌هایی که به دلیل عدم محافظت توسط مشخصه Message-Authenticator ناامن تلقی می‌شوند خودداری می‌کنند (این مشخصه مبتنی بر HMAC-MD5 است و بنابراین آسیب‌پذیر نبوده و از Kea 3.1.5 به بعد پشتیبانی می‌شود)؛ بنابراین حتی زمانی که زیرساخت محافظت‌شده باشد، استقرار RADIUS تحت تأثیر Blast-RADIUS قرار می‌گیرد.

راهکارهای ارائه‌شده توسط نسخه 3.1.6 از Kea عبارتند از:

۱. پشتیبانی از RADIUS/TLS که حفاظت رمزنگاری‌شده توکار را برای ارتباط میان کلاینت‌ها و کارگزارهای RADIUS فراهم می‌کند. این روش به عنوان راهکار بلندمدت شناخته می‌شود.

۲. پشتیبانی از راهکار کوتاه‌مدت با افزودن مشخصه Message-Authenticator به تمام پیام‌های ارسالی و الزام به وجود آن در تمام پیام‌های دریافتی (توجه داشته باشید که مورد دوم تنها توسط کارگزارهای جدید RADIUS اعمال می‌شود).

این راهکارها آزمایشی (experimental) هستند.

این کتابخانه قلاب (hook library) به Kea امکان می‌دهد با دو نوع از خدمات RADIUS تعامل داشته باشد: دسترسی (access) و حسابرسی (accounting). متداول‌ترین شیوه یکپارچه‌سازی DHCP و RADIUS در سطح عامل رله DHCP (relay-agent) انجام می‌شود: کلاینت‌های DHCP بسته‌های DHCP را به رله‌های DHCP می‌فرستند؛ این رله‌ها با کارگزار RADIUS ارتباط برقرار کرده و بسته به پاسخ، بسته را به کارگزار DHCP ارسال می‌کنند یا آن را نادیده می‌گیرند (drop می‌کنند). با این حال، این کار مستلزم پشتیبانی سخت‌افزار رله DHCP از ارتباطات RADIUS است، و حتی اگر رله پشتیبانی لازم را داشته باشد، اغلب به اندازه کافی انعطاف‌پذیر نیست تا مشخصه‌های اضافی RADIUS را ارسال و دریافت کند. یک جایگزین جذاب‌تر وجود دارد: توسعه دادن کارگزار DHCP برای برقراری ارتباط مستقیم با RADIUS. این موضوع، هدف اصلی این کتابخانه است.

نکته:

این کتابخانه تنها می‌تواند توسط فرایندهای kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود.

ویژگی عمده این کتابخانه قلاب، امکان استفاده از مجوزدهی (authorization) توسط RADIUS است. هنگامی که یک بسته DHCP دریافت می‌شود، کارگزار Kea یک Access-Request به کارگزار RADIUS ارسال کرده و منتظر پاسخ می‌ماند. سپس کارگزار پاسخی به صورت Access-Accept با مشخصه‌های خاص کلاینت یا Access-Reject برمی‌گرداند. در اینجا دو حالت پشتیبانی می‌شود: نخست، Access-Accept شامل مشخصه Framed-IP-Address (برای DHCPv4) یا مشخصه Framed-IPv6-Address/Delegated-IPv6-Prefix (برای DHCPv6) است که توسط Kea به عنوان دستورالعملی برای اختصاص آدرس IPv4 یا IPv6 یا پیشوند IPv6 مشخص‌شده تفسیر می‌شود. این سازوکار در عمل بدان معناست که RADIUS می‌تواند به عنوان یک پایگاه داده رزرو آدرس عمل کند.

دومین حالت پشتیبانی‌شده، قابلیت تخصیص کلاینت‌ها به استخرهای (pools) خاص بر اساس پاسخ RADIUS است. در این حالت، کارگزار RADIUS یک Access-Accept همراه با مشخصه Framed-Pool ارسال می‌کند. برای هر دو پروتکل DHCPv4 و DHCPv6، کارگزار Kea این مشخصه را به عنوان یک کلاس کلاینت (client class) در نظر می‌گیرد. با افزودن قابلیت محدودسازی دسترسی به استخرها برای کلاس‌های خاص (به بخش پیکربندی استخرها با اطلاعات کلاس <#classification-pools> مراجعه کنید)، می‌توان از RADIUS برای واداشتن کلاینت به تخصیص یک نشانی پویا یا پیشوند از استخری خاص استفاده کرد. علاوه بر این، در صورتی که گزینه‌های DHCP برای یک کلاس مشخص تعریف شده باشند، می‌توان از همین سازوکار برای کنترل اینکه کلاینت چه نوع گزینه‌هایی را دریافت می‌کند نیز بهره گرفت..SS پیکربندی کتابخانه هوک RADIUS

هوک RADIUS کتابخانه‌ای است که باید توسط کارسازهای kea-dhcp4 <#std-iscman-kea-dhcp4> یا kea-dhcp6 <#std-iscman-kea-dhcp6> بارگذاری شود. برخلاف برخی دیگر از کتابخانه‌های هوک موجود، این کتابخانه پارامترهای متعددی می‌گیرد. برای نمونه، می‌توان از این پیکربندی استفاده کرد:

{
  "Dhcp4": {
    // پارامترهای پیکربندی معمول DHCPv4 شما در اینجا قرار می‌گیرند.
    "hooks-libraries": [
      {
        // توجه داشته باشید که سرویس دسترسی RADIUS برای عملکرد صحیح به host-cache نیاز دارد،
        // بنابراین این کتابخانه نیز بارگذاری می‌شود.
        "library": "libdhcp_host_cache.so"
      },
      {
        "library": "libdhcp_radius.so",
        "parameters": {
          // مشخص کنید لغت‌نامه در کجا قرار دارد.
          "dictionary": "/etc/kea/radius/dictionary",
          // مشخص کنید از کدام آدرس برای برقراری ارتباط با کارسازهای RADIUS استفاده شود
          "bindaddr": "*"
          // پارامترهای بیشتر RADIUS در اینجا قرار می‌گیرند.
        }
      }
    ]
  }
}

محیط RADIUS پیچیده است. از این رو، ارائه یک پیکربندی پیش‌فرض که برای همگان کارآمد باشد امکان‌پذیر نیست. با این حال، ما نمونه‌ای داریم که برخی از ویژگی‌های رایج‌تر را نشان می‌دهد؛ لطفاً kea4/hooks-radius.json <#config-example-kea4-hooks-radius-json> را ببینید.

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

  • bindaddr (پیش‌فرض "*") - آدرسی را که باید توسط کتابخانه هوک در ارتباط با کارسازهای RADIUS استفاده شود مشخص می‌کند. مقدار ویژه "*" به هسته می‌گوید که آدرس را در زمان بارگذاری کتابخانه هوک انتخاب کند.
  • canonical-mac-address (پیش‌فرض false) - مشخص می‌کند که آیا نشانی‌های MAC در صفت‌ها از قالب رسمی RADIUS (جفت‌رقم‌های هگزادسیمال کوچک جداشده با -) پیروی کنند یا خیر.
  • client-id-pop0 (پیش‌فرض false) - همراه با libdhcp_flex_id.so <#std-ischooklib-libdhcp_flex_id.so> استفاده می‌شود؛ صفر ابتدایی (یا جفت صفر در DHCPv6) نوع شناسه کلاینت (DUID در DHCPv6) را حذف می‌کند. برای هرگونه پیامدهای مقداری در صورت استفاده هم‌زمان با آن، به client-id-printable مراجعه کنید.
  • client-id-printable (پیش‌فرض false) - بررسی می‌کند که آیا محتوای client-id/duid قابل‌چاپ است یا خیر و به جای هگزادسیمال، آن را همان‌طور که هست استفاده می‌کند. این گزینه مستلزم اعمال خودکار client-id-pop0 و extract-duid است، زیرا 0 و 255 قابل‌چاپ نیستند.
  • deadtime (پیش‌فرض 0) - سازوکاری است که به مرتب‌سازی کارسازها کمک می‌کند تا ابتدا با کارسازهایی که تا کنون پاسخگو بوده‌اند ارتباط برقرار شود، و کارسازهایی که پاسخگو نبوده‌اند برای تلاش‌های بعدی گذاشته شوند. مقدار deadtime تعداد ثانیه‌هایی را مشخص می‌کند که پس از آن یک کارساز غیرپاسخگو در نظر گرفته می‌شود. مقدار 0 این سازوکار را غیرفعال می‌کند.
  • dictionary (پیش‌فرض "/etc/kea/radius/dictionary") - لغت‌نامه صفت‌ها و مقادیر است؛ توجه داشته باشید که این یک پارامتر حیاتی است. یک لغت‌نامه توسط Kea ارائه شده و به صورت پیش‌فرض تنظیم گردیده است.
  • extract-duid (پیش‌فرض true) - مقدار DUID تعبیه‌شده را از یک شناسه کلاینت DHCPv4 منطبق با RFC 4361 استخراج می‌کند. برای هرگونه پیامدهای مقداری در صورت استفاده هم‌زمان با آن، به client-id-printable مراجعه کنید.
  • identifier-type4 (پیش‌فرض "client-id") - نوع شناسه را برای ساخت صفت User-Name برای DHCPv4 مشخص می‌کند؛ این مقدار باید با شناسه میزبان یکسان باشد. هنگامی که از libdhcp_flex_id.so <#std-ischooklib-libdhcp_flex_id.so> استفاده می‌شود، replace-client-id باید روی true تنظیم شده و client-id همراه با فعال بودن client-id-pop0 به کار رود.
  • identifier-type6 (پیش‌فرض "duid") - نوع شناسه را برای ساخت صفت User-Name برای DHCPv6 مشخص می‌کند؛ این مقدار باید با شناسه میزبان یکسان باشد. هنگامی که از libdhcp_flex_id.so <#std-ischooklib-libdhcp_flex_id.so> استفاده می‌شود، replace-client-id باید روی true تنظیم شده و duid همراه با فعال بودن client-id-pop0 به کار رود.
  • nas-ports (پیش‌فرض []) - پورت NAS را برای استفاده به جای شناسه زیرشبکه (رفتار پیش‌فرض) مشخص می‌کند. این یک آرایه از نگاشت‌ها است که هر نگاشت حداکثر دو عنصر دارد: مقدار الزامی پورت NAS، و به صورت اختیاری، یک انتخاب‌گر متشکل از شناسه زیرشبکه، پیشوند زیرشبکه یا نام شبکه اشتراکی (shared-network). اگر انتخاب‌گر بر روی بسته اعمال شود، پورت NAS به جای شناسه زیرشبکه استفاده خواهد شد. زمانی که شناسه زیرشبکه 0 باشد یا وجود نداشته باشد، پورت NAS مشخص‌شده به عنوان پیش‌فرض عمل می‌کند. این جایگزینی برای تمامی بسته‌هایی که با هیچ انتخاب‌گری مطابقت نداشته‌اند رخ می‌دهد.
  • protocol (پیش‌فرض UDP) - از نسخه Kea 3.1.6، پروتکل لایه انتقال را مشخص می‌کند. مقادیر پذیرفته‌شده عبارتند از UDP و TLS.
  • reselect-subnet-address (پیش‌فرض false) - انتخاب مجدد زیرشبکه را با توجه به مقدار صفت Framed-IP-Address یا به ترتیب Framed-IPv6-Address دریافتی از پاسخ دسترسی RADIUS فعال می‌کند. با فعال بودن این پرچم، اگر نشانی IP در محدوده زیرشبکه فعلیِ انتخاب‌شده نباشد، اما در محدوده زیرشبکه دیگری باشد که با توجه به معیارهای دیگر قابل انتخاب است، زیرشبکه دوم انتخاب شده و در مراحل بعدی تخصیص اجاره به کار می‌رود.
  • reselect-subnet-pool (پیش‌فرض false) - انتخاب مجدد زیرشبکه را با توجه به مقدار صفت Framed-Pool دریافتی از پاسخ دسترسی RADIUS فعال می‌کند. با فعال بودن این پرچم، اگر زیرشبکه انتخاب‌شده فعلی توسط کلاس کلاینت نشان‌داده‌شده با مقدار صفت محافظت نشده باشد، اما زیرشبکه قابل‌انتخاب دیگری وجود داشته باشد که توسط آن محافظت شده است، زیرشبکه دوم انتخاب شده و در ادامه فرایند تخصیص اجاره استفاده می‌شود. این انتخاب مجدد ابتدا امتحان می‌شود و در صورت موفقیت، از به کار افتادن عملکرد reselect-subnet-address جلوگیری می‌کند.
  • retries (پیش‌فرض 3) - تعداد تلاش‌های مجدد پیش از امتحان کردن کارساز بعدی است.
  • session-history (پیش‌فرض "") - نام فایلی است که حافظه پایدار را برای تاریخچه نشست‌های حسابرسی فراهم می‌کند.
•
thread-pool-size (پیش‌فرض 0) نشان‌دهنده تعداد ریسه‌هایی است که برای ارسال درخواست‌های RADIUS و پردازش پاسخ‌های RADIUS برای هر دو سرویس دسترسی و حسابرسی قبل از انتقال آن‌ها به استخر ریسه هسته استفاده می‌شوند. مقدار 0 به کتابخانه هوک RADIUS دستور می‌دهد تا از همان تعداد ریسه‌های استفاده‌شده برای پردازش هسته DHCP استفاده کند. این مقدار تنها در صورتی اهمیت دارد که هسته Kea به صورت چندریسه‌ای پیکربندی شده باشد؛ یک هسته تک‌ریسه‌ای Kea منجر به پردازش تک‌ریسه‌ای RADIUS خواهد شد.
  • timeout (پیش‌فرض 10) - تعداد ثانیه‌هایی است که طی آن برای یک پاسخ انتظار کشیده می‌شود.
  • use-message-authenticator (پیش‌فرض true هنگامی که پروتکل TLS نیست) - یک صفت Message-Authenticator به تمامی پیام‌های ارسالی اضافه می‌کند و وجود آن را در تمامی پیام‌های دریافتی الزامی می‌سازد. این می‌تواند به عنوان یک راهکار کاهش موقت در برابر آسیب‌پذیری BLAST استفاده شود، اما تنها با نسخه‌های اخیر کارسازهای RADIUS کار می‌کند که می‌توان آن‌ها را طوری پیکربندی کرد که این صفت را در تمام پاسخ‌ها قرار دهند.

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

  • access - سرویس مجوزدهی.
  • accounting - سرویس حسابرسی.

در سطح سرویس، سه بخش قابل پیکربندی است:

•
کارسازهایی که سرویس‌های RADIUS را که انتظار می‌رود کتابخانه با آن‌ها ارتباط برقرار کند تعریف می‌کنند. برای هر کارساز می‌توان موارد زیر را مشخص کرد:
  • name - نشانی IP کارساز را مشخص می‌کند. می‌توان از یک نام دامنه استفاده کرد که در زمان بارگذاری کتابخانه هوک تحلیل خواهد شد.
  • port - پورت UDP کارساز را مشخص می‌کند. به صورت پیش‌فرض، 1812 برای دسترسی و 1813 برای حسابرسی است.
  • secret - پیام‌ها را اصالت‌سنجی می‌کند.
  • trust-anchor - از نسخه Kea 3.1.6، نام فایل یا دایرکتوری‌ای را مشخص می‌کند که گواهی مرجع صدور گواهی (CA) در آن یافت می‌شود. همراه با پروتکل TLS الزامی است و در غیر این صورت نادیده گرفته می‌شود.
  • cert-file - از نسخه Kea 3.1.6، نام فایل حاوی گواهی نهاد نهایی (end-entity) مورد استفاده را مشخص می‌کند. همراه با پروتکل TLS الزامی است و در غیر این صورت نادیده گرفته می‌شود.
  • key-file - از نسخه Kea 3.1.6، کلید خصوصی گواهی نهاد نهایی مورد استفاده را مشخص می‌کند. همراه با پروتکل TLS الزامی است و در غیر این صورت نادیده گرفته می‌شود.

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

•
صفت‌هایی که اطلاعات اضافی ارسالی توسط کارساز Kea به یک کارساز RADIUS را تعریف می‌کنند. این پارامتر باید با یک نام یا نوع شناسایی شود. مقدار آن می‌تواند به یکی از سه روش ممکن مشخص گردد: data (که یک مقدار متن ساده را تعریف می‌کند)، raw (که مقدار را به صورت هگزادسیمال تعریف می‌کند)، یا expr (که عبارتی را تعریف می‌کند که برای هر بسته ورودی به طور مستقل ارزیابی می‌شود).
name - نام صفت است.
  • type - نوع صفت است. باید نوع یا نام مشخص شود، و صفت باید در لغت‌نامه (dictionary) تعریف شده باشد.
  • data - نخستین روش از سه روش برای مشخص کردن محتوای صفت است. این گزینه نمایش متنی محتوای صفت را مشخص می‌کند.
  • raw - دومین روش از سه روش برای مشخص کردن محتوای صفت است. این گزینه محتوا را در قالب شانزده‌شانزدهی (hexadecimal) مشخص می‌کند.
  • expr - آخرین روش از سه روش برای مشخص کردن محتوای صفت است. این گزینه یک عبارت ارزیابی را روی بسته پرسمان DHCP مشخص می‌کند.
  • vendor - از Kea 3.1.2 به بعد، شناسه سازنده (vendor id) صفت است. این مقدار همواره حاوی یک رشته با نام سازنده یا یک لیترال عدد صحیح است.
صفت‌ها فقط برای سرویس access پشتیبانی می‌شوند.

نکته:

صفت Vendor-Specific را می‌توان به دو روش مشخص کرد: استفاده از یک مقدار raw که باید شامل سازنده و داده‌های vsa باشد؛ توجه داشته باشید که مقدار data از نسخه Kea 3.1.2 دیگر پشتیبانی نمی‌شود، و مقدار expr به محتوای صفت ارزیابی می‌شود. روش دوم در نسخه 3.1.2 افزوده شد و امکان مشخص کردن یک صفت سازنده را می‌دهد که به‌طور خودکار درون یک صفت Vendor-Specific تعبیه می‌شود.
  • پرچم بولی peer-updates (پیش‌فرض true) مشخص می‌کند که آیا به‌روزرسانی‌های اجاره (lease) که از یک همتای فعال دسترسی‌پذیری بالا (HA) می‌آیند باید منجر به یک درخواست accounting شوند یا خیر. این امر ممکن است برای حذف موارد تکراری در صورتی که همتاهای HA برای ارسال درخواست به همان کارساز RADIUS پیکربندی شده باشند، مطلوب باشد. این پرچم تنها توسط سرویس accounting پشتیبانی می‌شود. فرایند همگام‌سازی اجاره در هنگام راه‌اندازی یک گره HA، صرف‌نظر از مقدار این پرچم، درخواست RADIUS accounting ایجاد نمی‌کند.
  • عدد صحیح مثبت max-pending-requests (پیش‌فرض 0) تعداد درخواست‌های معلق RADIUS را محدود می‌کند. این مقدار فقط توسط سرویس access پشتیبانی می‌شود. مقدار 0 به معنای عدم وجود محدودیت است؛ مقدار 64 یک تنظیم توصیه‌شده است.
  • عدد صحیح مثبت idle-timer-interval (پیش‌فرض 0) فاصله زمانی بین آخرین پاسخ معتبر از کارسازها و ارسال یک پیام Status-Server را مشخص می‌کند. مقدار 0 به معنای غیرفعال کردن این سازوکار است که در نسخه Kea 3.1.5 افزوده شد.
  • از نسخه Kea 3.1.6 با پروتکل TLS، پرچم بولی enabled (پیش‌فرض true) امکان فعال یا غیرفعال کردن سرویس‌های access و accounting را فراهم می‌کند.

برای نمونه، جهت مشخص کردن یک تک‌کارساز access موجود روی localhost که از "1234" به عنوان رمز (secret) استفاده می‌کند، و دستور به Kea برای ارسال سه صفت اضافی (User-Password، Connect-Info و Configuration-Token)، قطعه‌کد زیر می‌تواند استفاده شود:

{
  "parameters": {
    // Other RADIUS parameters here
    "access": {
      // This starts the list of access servers.
      "servers": [
        {
          // These are parameters for the first (and only) access server
          "name": "127.0.0.1",
          "port": 1812,
          "secret": "1234"
        }
      // Additional access servers could be specified here.
      ],
      // This defines a list of additional attributes Kea will send to each
      // access server in Access-Request.
      "attributes": [
        {
          // This attribute is identified by name (must be present in the
          // dictionary) and has static value (i.e. the same value will be
          // sent to every server for every packet).
          "name": "User-Password",
          "data": "mysecretpassword"
        },
        {
          // It is also possible to specify an attribute using its type,
          // rather than a name. 77 is Connect-Info. The value is specified
          // using hex. Again, this is a static value. It will be sent the
          // same for every packet and to every server.
          "type": 77,
          "raw": "65666a6a71"
        },
        {
           // This example shows how an expression can be used to send dynamic value.
           // The expression (see Using Expressions in Classification <#classification-using-expressions>) may take any
           // value from the incoming packet or even its metadata e.g. the
           // interface it was received over from.
           "name": "Configuration-Token",
           "expr": "hexstring(pkt4.mac,':')"
        }
      ] // End of attributes
    }, // End of access
    // Accounting parameters.
    "accounting": {
      // This starts the list of accounting servers.
      "servers": [
        {
          // These are parameters for the first (and only) accounting server
          "name": "127.0.0.1",
          "port": 1813,
          "secret": "1234"
        }
        // Additional accounting servers could be specified here.
      ]
    }
  }
}

گاهی اوقات سفارشی‌سازی برای برخی از صفت‌ها توسط دستگاه‌های متعلق به سازندگان مختلف مورد نیاز است. این یک روش عالی برای بهره‌گیری از سازوکار ارزیابی عبارت است. برای نمونه، نشانی‌های MAC که ممکن است به عنوان یک مقدار برای صفت User-Password استفاده شوند، به احتمال زیاد در قالب نمایش دونقطه-شانزده‌شانزدهی (de:ad:be:ef:ca:fe) ظاهر می‌شوند، اما ممکن است لازم باشد در قالب خط‌تیره-شانزده‌شانزدهی (de-ad-be-ef-ca-fe) بیان شوند. روش مشخص کردن آن در اینجا آمده است:

{
   "parameters": {
      "access": {
         "attributes": [
            {
               "name": "User-Password",
               "expr": "hexstring(pkt4.mac, '-')"
            }
         ]
      }
   }
}

و در اینجا نحوه مشخص کردن نماد شانزده‌شانزدهی جداشده با نقطه (dead.beef.cafe) که توسط دستگاه‌های Cisco ترجیح داده می‌شود، آورده شده است:

{
   "parameters": {
      "access": {
         "attributes": [
            {
               "name": "User-Password",
               "expr": "substring(hexstring(pkt4.mac, ''), 0, 4) + '.' + substring(hexstring(pkt4.mac, ''), 4, 4) + '.' + substring(hexstring(pkt4.mac, ''), 8, 4)"
            }
         ]
      }
   }
}

برای اینکه سرویس access در libdhcp_radius.so <#std-ischooklib-libdhcp_radius.so> به درستی کار کند، libdhcp_host_cache.so <#std-ischooklib-libdhcp_host_cache.so> نیز باید بارگذاری شود. دلیل این امر تا حدی پیچیده است. در یک استقرار معمولی، کلاینت‌های DHCP بسته‌های خود را از طریق DHCP relay ارسال می‌کنند، که گزینه‌های مشخصی از Relay Agent Information را درج می‌کند، مانند circuit-id یا remote-id. سپس مقادیر آن گزینه‌ها توسط کارساز Kea DHCP برای فرمول‌بندی صفت‌های لازم در پیام Access-Request ارسال‌شده به کارساز RADIUS استفاده می‌شوند. با این حال، هنگامی که کلاینت DHCP نشانی خود را دریافت کرد، با ارسال مستقیم بسته‌ها به کارساز DHCP آن را تمدید می‌کند. رله‌ها در آن مرحله نمی‌توانند گزینه‌های RAI خود را درج کنند، و کارساز DHCP نمی‌تواند تنها با استفاده از اطلاعات بسته‌های دریافتی، پرسمان‌های Access-Request را به کارساز RADIUS ارسال کند. Kea باید اطلاعات دریافت شده در تبادلات اولیه Discover/Offer را نگه دارد و بعداً هنگام ارسال پیام‌های accounting دوباره از آن‌ها استفاده کند.

این سازوکار بر اساس بافت کاربر (user context) در رزروهای میزبان پیاده‌سازی شده است. (برای جزئیات بیشتر به Comments and User Context <#user-context> و User Contexts in Hooks <#user-context-hooks> مراجعه کنید.) سازوکار host-cache امکان ذخیره و استفاده مجدد از اطلاعات دریافت‌شده توسط RADIUS را فراهم می‌کند، به جای اینکه یک رفت‌وبرگشت احراز هویت دیگر به کارساز RADIUS انجام شود. به عبارت دیگر، سازوکار host-cache برای سرویس access الزامی است. اگر libdhcp_host_cache.so <#std-ischooklib-libdhcp_host_cache.so> در کنار libdhcp_radius.so <#std-ischooklib-libdhcp_radius.so> بارگذاری نشود، پیکربندی Kea رد می‌شود.

نکته:

در حال حاضر کتابخانه قلاب RADIUS با پارامتر سراسری early-global-reservations-lookup ناسازگار است؛ به این معنی که تنظیم این پارامتر روی true هنگام بارگذاری کتابخانه قلاب، خطایی ایجاد می‌کند.

نکته:

در حال حاضر کتابخانه قلاب RADIUS با شبکه‌های اشتراکی چندزیرشبکه‌ای که دارای رزرو میزبان غیرسراسری هستند ناسازگار است. بارگذاری کتابخانه قلاب RADIUS در یک کارساز Kea DHCP که دارای چنین پیکربندی‌ای باشد، خطایی ایجاد می‌کند.

نکته:

در حال حاضر پارامترهای reselect-subnet-address و reselect-subnet-pool با پیکربندی hub-and-spoke در libdhcp_ha.so <#std-ischooklib-libdhcp_ha.so> ناسازگار هستند. این کتابخانه قلاب از یک زیرشبکه انتخاب‌شده اولیه برای تعیین رابطه HA جهت پردازش بسته استفاده می‌کند. انتخاب مجدد زیرشبکه ممکن است با این انتخاب تداخل پیدا کند. برای جزئیات به Hub and Spoke Configuration <#ha-hub-and-spoke> مراجعه کنید.

در Kea 3.1.6 پشتیبانی از RADIUS/TLS با اعمال تغییراتی در پیکربندی ارائه شده است، عمدتاً به این دلیل که در TLS از یک اتصال اشتراکی استفاده می‌شود (در برابر درگاه‌های مختلف UDP).

  • پارامتر جدید protocol باید روی TLS تنظیم شود.
  • یک مدخل سرویس جدید به نام tls باید برای تعریف پارامترهای servers و idle-timer-interval استفاده شود.
  • این پارامترها دیگر در مدخل‌های سرویس access` و ``accounting مجاز نیستند.
  • از آنجا که مدخل servers وجود ندارد، سرویس‌های access و accounting می‌توانند با تنظیم پرچم enabled روی false غیرفعال شوند.
  • مدخل‌های سرور برای تنظیم پارامترهای TLS شامل trust-anchor، cert-file و key-file الزامی هستند.
  • درگاه سرور پیش‌فرض (و یکتا) 2083 است.
  • مدخل secret دیگر الزامی نیست و مقدار پیش‌فرض آن radsec است.

برای نمونه، پیکربندی یک تک‌سرور access با RADIUS/TLS به این صورت درمی‌آید:

{
  "parameters": {
    // Set the protocol to TLS (default is UDP).
    "protocol": "TLS",
    // Other RADIUS parameters here
    // Access parameters.
    "access": {
      // This defines a list of additional attributes Kea will send to each
      // access server in Access-Request.
      "attributes": [
        {
          // This attribute is identified by name (must be present in the
          // dictionary) and has static value (i.e. the same value will be
          // sent to every server for every packet).
          "name": "User-Password",
          "data": "mysecretpassword"
        }
      ] // End of attributes
    }, // End of access
    // Accounting parameters.
    "accounting": {
      // Disabling this service.
      "enabled": false
    }, // End of accounting
    // TLS parameters.
    "tls": {
      // This starts the list of servers.
      "servers": [
        {
          "name": "127.0.0.1",
          "port": 2083,
          "secret": "radsec",
          "trust-anchor": "/usr/lib/kea/CA.pem",
          "cert-file": "/usr/lib/kea/server_cert.pem",
          "key-file": "/usr/lib/kea/server_key.pem"
        }
      ]
    }
  }
}

نکته:

در حال حاضر تنها نخستین سرور پیکربندی‌شده استفاده می‌شود. پارامترهای retries و deadtime بدون هیچ هشداری نادیده گرفته می‌شوند. به‌دلیل برخی محدودیت‌ها در پیاده‌سازی کلاینت TCP، نشانی محلی را نمی‌توان تنظیم کرد (یعنی تنظیم پارامتر bindaddr نادیده گرفته می‌شود)، و درخواست‌ها پایپ‌لاین (pipelined) نمی‌شوند؛ بدین معنی که پیش از ارسال درخواستی دیگر بر روی همان اتصال، باید منتظر پاسخ ماند. زمانی که چندریسمانی (multi-threading) فعال باشد، چندین اتصال (تا سقف تعداد ریسمان‌ها) را می‌توان به‌طور موازی باز کرد.

کتابخانه قلاب (hook) RADIUS برای کارکرد به حداقل یک سرور RADIUS نیاز دارد. یکی از پیاده‌سازی‌های متن‌باز و محبوب FreeRADIUS است؛ در اینجا نحوه راه‌اندازی آن برای فعال‌سازی قابلیت‌های پایه‌ای در Kea آمده است.

1.
نرم‌افزار FreeRADIUS را از طریق مدیر بسته یا از پرونده‌های tarball موجود در [صفحه بارگیری freeradius.org](https://freeradius.org/releases) نصب کنید.
2.
شاخه پیکربندی FreeRADIUS را مشخص کنید. این شاخه معمولاً /etc/freeradius است، اما ممکن است /etc/raddb نیز باشد.
3.
گواهی‌ها را ایجاد کنید. به مسیر /etc/freeradius/certs بروید. دستور ./bootstrap یا make را اجرا کنید. تا پایان کار منتظر بمانید. این فرآیند باید چند ثانیه طول بکشد.
4.
بررسی کنید که سرور قادر به اجرا شدن باشد. اجرا با پرچم -X روشی مناسب برای نمایش خطاهای احتمالی است. بسته به این که کدام دستور موجود است، radiusd -X یا freeradius -X را اجرا کنید. در سطر پایانی باید عبارت Ready to process requests نمایش داده شود.
5.
اگر سرور DHCP در Kea و سرور RADIUS بر روی ماشین‌های جداگانه‌ای قرار دارند، فایل /etc/freeradius/clients.conf را با نشانی مناسب ذیل ipadddr ویرایش کنید. این فایل همچنین مکانی است که رمز (secret) در آن تنظیم می‌شود؛ این مقدار باید با آنچه در پیکربندی کتابخانه قلاب تنظیم شده مطابقت داشته باشد.
6.
اگر از RADIUS برای احراز مجوز کلاینت‌های DHCP استفاده می‌شود، هر کلاینت DHCP باید یک مدخل در فایل authorize داشته باشد که معمولاً در مسیرهای زیر یافت می‌شود:
  • /etc/raddb/mods-config/files/authorize
  • /etc/freeradius/3.0/mods-config/files/authorize
  • /etc/freeradius/users (برای سری RADIUS 2.x)

گذرواژه‌های این مدخل‌ها باید با گذرواژه‌های موجود در پیکربندی کتابخانه قلاب RADIUS تحت مشخصه User-Password مطابقت داشته باشد. هر مدخل می‌تواند دارای صفر یا چند مشخصه باشد.

در مثال زیر، شش مدخل وجود دارد که گذرواژه آن‌ها بر روی شناسه کلاینت تنظیم شده است؛ این مقدار باید به‌صورت پویا در پیکربندی کتابخانه قلاب تنظیم شود. شکل مدخل‌ها ممکن است به این صورت باشد:

01:00:0c:01:02:03:04    Cleartext-password := "00:0c:01:02:03:04"
01:00:0c:01:02:03:05    Cleartext-password := "00:0c:01:02:03:05"
    Framed-IP-Address = "192.0.2.5"
01:00:0c:01:02:03:06    Cleartext-password := "00:0c:01:02:03:06"
    Framed-IP-Address = "192.0.2.6",
    Framed-Pool = "classical"
00:03:00:01:00:0c:01:02:03:07    Cleartext-password := "00:0c:01:02:03:07"
00:03:00:01:00:0c:01:02:03:08    Cleartext-password := "00:0c:01:02:03:08"
    Framed-IPv6-Address = "2001:db8::8"
00:03:00:01:00:0c:01:02:03:09    Cleartext-password := "00:0c:01:02:03:09"
    Framed-IPv6-Address = "2001:db8::9",
    Framed-Pool = "classroom"
7.
نیازی به تغییر accounting برای کار با Kea نیست، اما امکان اعمال سفارشی‌سازی‌ها در فایل accounting وجود دارد، فایلی که معمولاً در مسیرهای زیر یافت می‌شود:
  • /etc/radius-config/mods-config/files/accounting
  • /etc/freeradius/3.0/mods-config/files/accounting
8.
هنگامی که RADIUS/TLS استفاده می‌شود، بهتر است اعتبارنامه‌های TLS را به هویت کلاینت مقید (bind) کنید. این کار با استفاده از عبارت زیر امکان‌پذیر است:
check_cert_cn = %{User-Name}

که Common Name مربوط به موضوع (subject) گواهی کلاینت TLS (یعنی Kea) را با User-Name در RADIUS مطابقت می‌دهد.

نمودارهای زیر نمای کلی سطح بالایی از نحوه کمک RADIUS به فرایند تخصیص اجاره در kea-dhcp4 <#std-iscman-kea-dhcp4> و kea-dhcp6 <#std-iscman-kea-dhcp6> را نشان می‌دهند.

[تصویر]

مورد فراخوانی (callout) command_processed که تا حدودی خارج از مبحث تخصیص اجاره است و در نمودارهای بالا نشان داده نشده است، هنگام دریافت یک فرمان اجاره (lease command)، پیام‌های Accounting-Request را ارسال می‌کند.

برای آشنایی اولیه با نگه‌داری بسته (packet parking)، به Parked-Packet Limit <#parked-packet-limit> مراجعه کنید.

کتابخانه هوک (hook) RADIUS از این سازوکار استفاده می‌کند. برای فراهم کردن امکان ارتباط ناهمگام (asynchronous) میان Kea و سرور RADIUS و پردازش هم‌روند بسته‌های DHCP توسط سرور Kea، پیش از ارسال درخواست دسترسی (access request) در فراخوانیِ subnet select، درخواست DHCP متوقف (park) می‌شود. زمانی که پاسخ دسترسی در دسترس سرور DHCP Kea قرار گرفت، درخواست از حالت توقف خارج شده (unparked) و سرور به پردازش آن ادامه می‌دهد.

کتابخانه هوک RADIUS در نسخه 2.4.0 و نسخه‌های پیشین برای کارکرد خود به کتابخانه کلاینت FreeRADIUS متکی بود. از نسخه 2.6.0 به بعد، کتابخانه هوک RADIUS مستقل است و پیاده‌سازی کلاینت RADIUS و دیکشنری RADIUS اختصاصی خود را دارد. تفاوت‌ها عبارتند از:

ویژگی قدیمی جدید
پشتیبانی از انواع داده مشخصه (Attribute) string, ipaddr, ipv4prefix, integer, integer64, date, ifid, ipv6addr, ipv6prefix, tlv, abinary, byte, ether, short, signed, octets string (می‌تواند هر نوع داده پشتیبانی‌نشده دیگر را نیز شبیه‌سازی کند)، ipaddr، integer، date (به عنوان integer تفسیر می‌شود)، ipv6addr، ipv6prefix
نام‌های مشخصه‌های استاندارد گرفته‌شده از دیکشنری FreeRADIUS. گرفته‌شده از دیکشنری RADIUS در Kea و رجیستری IANA. یک سازوکار نام مستعار (aliasing) در کتابخانه تعبیه شده است که سازگاری رو به عقب را تضمین می‌کند؛ برای نمونه Password به نام استاندارد مشخصه User-Password ترجمه می‌شود.
تفکیک نام دامنه سرورهای RADIUS در زمان اجرا (run time). در زمان بارگذاری کتابخانه هوک.
استنتاج خودکار آدرس مبدأ برای دسترسی به سرورهای RADIUS (پیکربندی‌شده با bindaddr: "*") در زمان اجرا (run time). در زمان بارگذاری کتابخانه هوک.
محدودیت سرور RADIUS به ازای هر سرویس 8 نامحدود
پشتیبانی از گنجاندن دیکشنری‌ها درون دیکشنری‌ها بله از Kea 3.1.2 به بعد
پشتیبانی از مشخصه‌های فروشنده (Vendor Attributes) بله از Kea 3.1.2 به بعد
نام‌ها و مقادیر مشخصه‌ها غیرحساس به حروف کوچک و بزرگ حساس به حروف کوچک و بزرگ
مقادیر عدد صحیح (Integer) نیازی به تعریف مشخصه ندارند. باید تعریف مشخصه مرتبط در دیکشنری داشته باشند.
فضاهای نام مشخصه و مقدار عددی فضاهای نام مسطح (flat) که مقادیر تکراری را مجاز می‌دانند. از Kea 3.1.2 به بعد فضاهای نام مجزا به ازای هر فروشنده (vendor).
حضور Reply-Message در لاگ‌های Kea فقط به عنوان بخشی از فهرست تجمیعی مشخصه‌ها در پیام‌های لاگ RADIUS_AUTHENTICATION_ACCEPTED، RADIUS_ACCESS_CACHE_INSERT و RADIUS_ACCESS_CACHE_GET. همچنین دارای یک پیام اختصاصی RADIUS_REPLY_MESSAGE_ATTRIBUTE به ازای هر مشخصه Reply-Message است که پس از دریافت پاسخ معتبر RADIUS ثبت می‌شود.
رفتار در مواجهه با چندین مشخصه از یک نوع (به جز Reply-Message) به صورت تجربی، تنها نخستین مشخصه روی سیم (on the wire) از یک پیام Access-Accept در نظر گرفته می‌شود. به صورت تجربی، تنها آخرین مشخصه روی سیم (on the wire) از یک پیام Access-Accept در نظر گرفته می‌شود.
پروتکل Remote Authentication Dial In User Service (RADIUS) در RFC 2865 https://datatracker.ietf.org/doc/html/rfc2865 مشخص شده است.
بخش RADIUS Accounting در RFC 2866 https://datatracker.ietf.org/doc/html/rfc2866 مشخص شده است.
صفت Message-Authenticator در افزونه EAP در RFC 3579 https://datatracker.ietf.org/doc/html/rfc3579 مشخص شده است.
پیام Status-Server در RFC 5997 https://datatracker.ietf.org/doc/html/rfc5997 مشخص شده است.
انتقال TCP (پشتیبانی‌نشده، اما برای TLS ارجاع فراوانی به آن داده شده است) در RFC 6613 https://datatracker.ietf.org/doc/html/rfc6613 مشخص شده است.
انتقال TLS (شناخته‌شده با عنوان RADIUS/TLS یا radsec) در RFC 6614 https://datatracker.ietf.org/doc/html/rfc6614 مشخص شده است.
"پایش KEA با STORK (MONITORING KEA WITH STORK)"
بیشتر مدیران سیستم تمایل دارند بتوانند سرویس‌های Kea در حال اجرا را پایش کنند. Kea اطلاعات بسیار متنوعی ارائه می‌دهد - فایل‌های پیکربندی، API، آمارها، گزارش‌ها (logs)، محتوای پایگاه داده باز و موارد دیگر - به‌گونه‌ای که دنبال کردن همه‌ی آن‌ها گاهی ممکن است دشوار باشد. پروژه Stork متعلق به ISC با هدف رفع این مشکل برای هر دو نرم‌افزار Kea و BIND 9 طراحی شده است. Stork از جنبه‌های گوناگونی سودمند است:
0.0
• 2
ابزار Stork می‌تواند به‌عنوان داشبورد استفاده شود. این ابزار دید عمیقی از آنچه دقیقاً در سرورها رخ می‌دهد فراهم می‌آورد. به‌ویژه، به کاربران امکان می‌دهد: جزئیات به‌روز مربوط به بهره‌برداری از pool در زیرشبکه‌ها و شبکه‌های اشتراکی (shared networks) را مشاهده کنند؛ وضعیت جفت HA را پایش نمایند (و در صورت بروز رخدادهای تغییر وضعیت خرابی (failover) و بازیابی، اطلاعات بیشتری فراهم کند)؛ رزروهای میزبان (host reservations) خاص را فهرست، پالایش و جستجو کنند؛ و موارد بیشتر. فقط کافی است یک سرور واحد Stork و بر روی هر ماشینی که باید پایش شود یک Stork agent مستقر گردد.
• 2
عامل Stork می‌تواند Kea را با Prometheus و Grafana یکپارچه‌سازی کند. به‌محض فعال شدن Stork agent در سرور، به‌عنوان یک صادرکننده Prometheus (Prometheus exporter) عمل می‌کند. کاربرانی که Prometheus را در شبکه‌های خود مستقر کرده‌اند می‌توانند آمارها را به‌صورت سری زمانی با استفاده از Grafana بصری‌سازی کنند.
• 2
ابزار Stork می‌تواند هم به‌عنوان داشبورد و هم به‌عنوان یکپارچه‌ساز برای Prometheus/Grafana عمل کند. پس از اتصال Stork به محل استقرار Grafana در شبکه، کاربران می‌توانند وضعیت فعلی را بررسی کرده و با باز کردن پیوند سفارشی در Grafana، رفتار یک مشخصه خاص را در گذر زمان مشاهده نمایند.
168u
ابزار Stork هم به‌صورت کد منبع و هم در قالب بسته‌های بومی deb و RPM در دسترس است که نصب آن را روی اکثر سیستم‌های متداول آسان می‌سازد. برای جزئیات بیشتر، لطفاً به راهنمای مرجع Stork ARM https://stork.readthedocs.io یا صفحه پروژه Stork https://gitlab.isc.org/isc-projects/stork مراجعه کنید. سند ARM مجموعه‌ای مناسب از نماگرفت‌ها دارد که مکرراً به‌روزرسانی می‌شود تا تصویری از آنچه اکنون در دسترس است به کاربران ارائه دهد. Stork در میانه فرایند توسعه همه‌جانبه با انتشارهای ماهانه است، بنابراین پیشنهاد می‌شود مرتباً آن را بررسی کنید.
نکته:
0.0
3.5
ابزار Stork از فراخوانی‌های Kea API از قلاب‌های libdhcp_host_cmds.so <#std-ischooklib-libdhcp_host_cmds.so> و libdhcp_subnet_cmds.so <#std-ischooklib-libdhcp_subnet_cmds.so> برای اعمال تغییرات در پیکربندی Kea استفاده می‌کند. چنین استفاده‌ای با Kea Configuration Backend <#config-backend> (CB) ناسازگار است. در حال حاضر Stork پشتیبانی از libdhcp_cb_cmds.so <#std-ischooklib-libdhcp_cb_cmds.so> را که برای اعمال تغییرات در پیکربندی CB مورد نیاز است، پیاده‌سازی نکرده است. در صورت استفاده از Kea CB، ابزار Stork را تنها می‌توان با اطمینان در حالت "read-only" (فقط‌خواندنی) به کار برد. پشتیبانی از CB برای نسخه‌های آتی Stork برنامه‌ریزی شده است.
168u
168u
آمارهای Kea در Grafana
پروژه ISC Stork عاملی را ارائه می‌دهد که می‌تواند در کنار Kea مستقر شود. این عامل آمارهای Kea را در قالبی که توسط Prometheus پذیرفته می‌شود ارائه می‌دهد. یکی از مزایای عمده Prometheus این است که مشاهدات تکرارشونده یک‌باره را به سری‌های زمانی تبدیل می‌کند؛ امری که به کاربران امکان می‌دهد تغییرات رفتارهای مشخص را در گذر زمان پایش کنند. استفاده از سایر ابزارها برای بصری‌سازی داده‌های موجود در Prometheus آسان است؛ متداول‌ترین رویکرد، استفاده از Grafana جهت ارائه داشبوردهای بصری است. پروژه Stork تعاریف داشبوردی را برای Kea ارائه می‌کند که به‌سادگی در Grafana قابل درون‌ریزی است.
درباره Prometheus و Grafana در وب‌سایت‌های آن‌ها بیشتر بیاموزید: Prometheus https://prometheus.io و Grafana https://grafana.com.
"مرجع API (API REFERENCE)"
در حال حاضر Kea از ۲۱۹ دستور در دیمن‌های kea-dhcp-ddns، kea-dhcp4 و kea-dhcp6 و کتابخانه‌های قلاب cb_cmds، class_cmds، gss_tsig، high_availability، host_cache، host_cmds، lease_cmds، lease_query، perfmon، stat_cmds و subnet_cmds پشتیبانی می‌کند.
دستورهای پشتیبانی‌شده توسط دیمن kea-dhcp-ddns: build-report, config-get, config-hash-get, config-reload, config-set, config-test, config-write, gss-tsig-get, gss-tsig-get-all, gss-tsig-key-del, gss-tsig-key-expire, gss-tsig-key-get, gss-tsig-list, gss-tsig-purge, gss-tsig-purge-all, gss-tsig-rekey, gss-tsig-rekey-all, list-commands, shutdown, statistic-get, statistic-get-all, statistic-reset, statistic-reset-all, status-get, version-get.
دستورهای پشتیبانی‌شده توسط دیمن kea-dhcp4: build-report, cache-clear, cache-flush, cache-get, cache-get-by-id, cache-insert, cache-load, cache-remove, cache-size, cache-write, class-add, class-del, class-get, class-list, class-update, config-backend-pull, config-get, config-hash-get, config-reload, config-set, config-test, config-write, dhcp-disable, dhcp-enable, extended-info4-upgrade, ha-continue, ha-heartbeat, ha-maintenance-cancel, ha-maintenance-notify, ha-maintenance-start, ha-reset, ha-scopes, ha-sync, ha-sync-complete-notify, interface-add, interface-list, interface-redetect, kea-lfc-start, lease4-add, lease4-del, lease4-get, lease4-get-all, lease4-get-by-client-id, lease4-get-by-hostname, lease4-get-by-hw-address, lease4-get-by-state, lease4-get-page, lease4-resend-ddns, lease4-update, lease4-wipe, lease4-write, leases-reclaim, list-commands, network4-add, network4-del, network4-get, network4-list, network4-subnet-add, network4-subnet-del, perfmon-control, perfmon-get-all-durations, remote-class4-del, remote-class4-get, remote-class4-get-all, remote-class4-set, remote-global-parameter4-del, remote-global-parameter4-get, remote-global-parameter4-get-all, remote-global-parameter4-set, remote-network4-del, remote-network4-get, remote-network4-list, remote-network4-set, remote-option-def4-del, remote-option-def4-get, remote-option-def4-get-all, remote-option-def4-set, remote-option4-global-del, remote-option4-global-get, remote-option4-global-get-all, remote-option4-global-set, remote-option4-network-del, remote-option4-network-set, remote-option4-pool-del, remote-option4-pool-set, remote-option4-subnet-del, remote-option4-subnet-set, remote-server4-del, remote-server4-get, remote-server4-get-all, remote-server4-set, remote-subnet4-del-by-id, remote-subnet4-del-by-prefix, remote-subnet4-get-by-id, remote-subnet4-get-by-prefix, remote-subnet4-list, remote-subnet4-set, reservation-add, reservation-del, reservation-get, reservation-get-all, reservation-get-by-address, reservation-get-by-hostname, reservation-get-by-id, reservation-get-page, reservation-update, server-tag-get, sflq-pool4-del, sflq-pool4-get-all, sflq-pool4-get-by-range, sflq-pool4-get-by-subnet, sflq-pool4-rebuild, sflq-pool6-del, sflq-pool6-get-all, sflq-pool6-get-by-range, sflq-pool6-get-by-subnet, sflq-pool6-rebuild, shutdown, stat-lease4-get, statistic-get, statistic-get-all, statistic-global-get-all, statistic-remove, statistic-remove-all, statistic-reset, statistic-reset-all, statistic-sample-age-set, statistic-sample-age-set-all, statistic-sample-count-set, statistic-sample-count-set-all, status-get, subnet4-add, subnet4-del, subnet4-delta-add, subnet4-delta-del, subnet4-get, subnet4-list, subnet4-select-test, subnet4-update, subnet4o6-select-test, version-get.
دستورهای پشتیبانی‌شده توسط دیمن kea-dhcp6: build-report, cache-clear, cache-flush, cache-get, cache-get-by-id, cache-insert, cache-load, cache-remove, cache-size, cache-write, class-add, class-del, class-get, class-list, class-update, config-backend-pull, config-get, config-hash-get, config-reload, config-set, config-test, config-write, dhcp-disable, dhcp-enable, extended-info6-upgrade, ha-continue, ha-heartbeat, ha-maintenance-cancel, ha-maintenance-notify, ha-maintenance-start, ha-reset, ha-scopes, ha-sync, ha-sync-complete-notify, interface-add, interface-list, interface-redetect, kea-lfc-start, lease6-add, lease6-bulk-apply, lease6-del, lease6-get, lease6-get-all, lease6-get-by-duid, lease6-get-by-hostname, lease6-get-by-hw-address, lease6-get-by-state, lease6-get-page, lease6-resend-ddns, lease6-update, lease6-wipe, lease6-write, leases-reclaim, list-commands, network6-add, network6-del, network6-get, network6-list, network6-subnet-add, network6-subnet-del, perfmon-control, perfmon-get-all-durations, remote-class6-del, remote-class6-get, remote-class6-get-all, remote-class6-set, remote-global-parameter6-del, remote-global-parameter6-get, remote-global-parameter6-get-all, remote-global-parameter6-set, remote-network6-del, remote-network6-get, remote-network6-list, remote-network6-set, remote-option-def6-del, remote-option-def6-get, remote-option-def6-get-all, remote-option-def6-set, remote-option6-global-del, remote-option6-global-get, remote-option6-global-get-all, remote-option6-global-set, remote-option6-network-del, remote-option6-network-set, remote-option6-pd-pool-del, remote-option6-pd-pool-set, remote-option6-pool-del, remote-option6-pool-set, remote-option6-subnet-del, remote-option6-subnet-set, remote-server6-del, remote-server6-get, remote-server6-get-all, remote-server6-set, remote-subnet6-del-by-id, remote-subnet6-del-by-prefix, remote-subnet6-get-by-id, remote-subnet6-get-by-prefix, remote-subnet6-list, remote-subnet6-set, reservation-add, reservation-del, reservation-get, reservation-get-all, reservation-get-by-address, reservation-get-by-hostname, reservation-get-by-id, reservation-get-page, reservation-update, server-tag-get, sflq-pool4-del, sflq-pool4-get-all, sflq-pool4-get-by-range, sflq-pool4-get-by-subnet, sflq-pool4-rebuild, sflq-pool6-del, sflq-pool6-get-all, sflq-pool6-get-by-range, sflq-pool6-get-by-subnet, sflq-pool6-rebuild, shutdown, stat-lease6-get, statistic-get, statistic-get-all, statistic-global-get-all, statistic-remove, statistic-remove-all, statistic-reset, statistic-reset-all, statistic-sample-age-set, statistic-sample-age-set-all, statistic-sample-count-set, statistic-sample-count-set-all, status-get, subnet6-add, subnet6-del, subnet6-delta-add, subnet6-delta-del, subnet6-get, subnet6-list, subnet6-select-test, subnet6-update, version-get.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب cb_cmds: remote-class4-del, remote-class4-get, remote-class4-get-all, remote-class4-set, remote-class6-del, remote-class6-get, remote-class6-get-all, remote-class6-set, remote-global-parameter4-del, remote-global-parameter4-get, remote-global-parameter4-get-all, remote-global-parameter4-set, remote-global-parameter6-del, remote-global-parameter6-get, remote-global-parameter6-get-all, remote-global-parameter6-set, remote-network4-del, remote-network4-get, remote-network4-list, remote-network4-set, remote-network6-del, remote-network6-get, remote-network6-list, remote-network6-set, remote-option-def4-del, remote-option-def4-get, remote-option-def4-get-all, remote-option-def4-set, remote-option-def6-del, remote-option-def6-get, remote-option-def6-get-all, remote-option-def6-set, remote-option4-global-del, remote-option4-global-get, remote-option4-global-get-all, remote-option4-global-set, remote-option4-network-del, remote-option4-network-set, remote-option4-pool-del, remote-option4-pool-set, remote-option4-subnet-del, remote-option4-subnet-set, remote-option6-global-del, remote-option6-global-get, remote-option6-global-get-all, remote-option6-global-set, remote-option6-network-del, remote-option6-network-set, remote-option6-pd-pool-del, remote-option6-pd-pool-set, remote-option6-pool-del, remote-option6-pool-set, remote-option6-subnet-del, remote-option6-subnet-set, remote-server4-del, remote-server4-get, remote-server4-get-all, remote-server4-set, remote-server6-del, remote-server6-get, remote-server6-get-all, remote-server6-set, remote-subnet4-del-by-id, remote-subnet4-del-by-prefix, remote-subnet4-get-by-id, remote-subnet4-get-by-prefix, remote-subnet4-list, remote-subnet4-set, remote-subnet6-del-by-id, remote-subnet6-del-by-prefix, remote-subnet6-get-by-id, remote-subnet6-get-by-prefix, remote-subnet6-list, remote-subnet6-set.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب class_cmds: class-add, class-del, class-get, class-list, class-update.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب gss_tsig: gss-tsig-get, gss-tsig-get-all, gss-tsig-key-del, gss-tsig-key-expire, gss-tsig-key-get, gss-tsig-list, gss-tsig-purge, gss-tsig-purge-all, gss-tsig-rekey, gss-tsig-rekey-all.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب high_availability: ha-continue, ha-heartbeat, ha-maintenance-cancel, ha-maintenance-notify, ha-maintenance-start, ha-reset, ha-scopes, ha-sync, ha-sync-complete-notify.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب host_cache: cache-clear, cache-flush, cache-get, cache-get-by-id, cache-insert, cache-load, cache-remove, cache-size, cache-write.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب host_cmds: reservation-add, reservation-del, reservation-get, reservation-get-all, reservation-get-by-address, reservation-get-by-hostname, reservation-get-by-id, reservation-get-page, reservation-update.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب lease_cmds: lease4-add, lease4-del, lease4-get, lease4-get-all, lease4-get-by-client-id, lease4-get-by-hostname, lease4-get-by-hw-address, lease4-get-by-state, lease4-get-page, lease4-resend-ddns, lease4-update, lease4-wipe, lease4-write, lease6-add, lease6-bulk-apply, lease6-del, lease6-get, lease6-get-all, lease6-get-by-duid, lease6-get-by-hostname, lease6-get-by-hw-address, lease6-get-by-state, lease6-get-page, lease6-resend-ddns, lease6-update, lease6-wipe, lease6-write, sflq-pool4-del, sflq-pool4-get-all, sflq-pool4-get-by-range, sflq-pool4-get-by-subnet, sflq-pool4-rebuild, sflq-pool6-del, sflq-pool6-get-all, sflq-pool6-get-by-range, sflq-pool6-get-by-subnet, sflq-pool6-rebuild.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب lease_query: extended-info4-upgrade, extended-info6-upgrade.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب perfmon: perfmon-control, perfmon-get-all-durations.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب stat_cmds: stat-lease4-get, stat-lease6-get.
دستورهای پشتیبانی‌شده توسط کتابخانه قلاب subnet_cmds: network4-add, network4-del, network4-get, network4-list, network4-subnet-add, network4-subnet-del, network6-add, network6-del, network6-get, network6-list, network6-subnet-add, network6-subnet-del, subnet4-add, subnet4-del, subnet4-delta-add, subnet4-delta-del, subnet4-get, subnet4-list, subnet4-update, subnet6-add, subnet6-del, subnet6-delta-add, subnet6-delta-del, subnet6-get, subnet6-list, subnet6-update.
build-report
این دستور فهرستی از گزینه‌های کامپایلی را که این فایل باینری خاص با آن‌ها ساخته شده است برمی‌گرداند.
پشتیبانی‌شده توسط: kea-dhcp-ddns, kea-dhcp4, kea-dhcp6
در دسترس بودن: 1.2.0 (توکار)
سطح دسترسی: read (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور build-report را ببینید <#command-build-report>
ساختار دستور:
0.0
3.5
{
"command": "build-report"
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": <string with build details>
}
168u
این دستور تمام رزروهای میزبان ذخیره‌شده در کَش را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-clear را ببینید <#command-cache-clear>
ساختار دستور:
0.0
3.5
{
"command": "cache-clear"
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
cache-flush
این دستور تا تعداد مشخص‌شده یا تمامی رزروهای میزبان ذخیره‌شده در کَش را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-flush را ببینید <#command-cache-flush>
ساختار دستور:
0.0
3.5
{
"command": "cache-flush",
"arguments": 5
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
cache-get
این دستور محتوای کامل کَش میزبان را بازمی‌گرداند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-get را ببینید <#command-cache-get>
ساختار دستور:
0.0
3.5
{
"command": "cache-get"
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "123 entries returned.",
"arguments": <list of host reservations>
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
این دستور مدخل‌های منطبق با شناسهٔ ارائه‌شده را از حافظهٔ پنهان میزبان (host cache) بازمی‌گرداند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
دسترس‌پذیری: 1.6.0 (کتابخانهٔ قلاب host_cache)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-get-by-id را ببینید <#command-cache-get-by-id>
ساختار دستور:
0.0
3.5
{
"command": "cache-get-by-id",
"arguments": {
"hw-address": "01:02:03:04:05:06"
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 entries returned.",
"arguments": <list of host reservations>
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
cache-insert
این دستور یک میزبان را در حافظهٔ پنهان درج می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
دسترس‌پذیری: 1.4.0 (کتابخانهٔ قلاب host_cache)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-insert را ببینید <#command-cache-insert>
ساختار دستور:
0.0
3.5
{
"command": "cache-insert",
"arguments": {
"hw-address": "01:02:03:04:05:06",
"subnet-id4": 4,
"subnet-id6": 0,
"ip-address": "192.0.2.100",
"hostname": "somehost.example.org",
"client-classes4": [ ],
"client-classes6": [ ],
"option-data4": [ ],
"option-data6": [ ],
"next-server": "192.0.0.2",
"server-hostname": "server-hostname.example.org",
"boot-file-name": "bootfile.efi",
"host-id": 0
}
}
مثال دیگری که رزرو میزبان IPv6 را به حافظهٔ پنهان اضافه می‌کند عبارت است از:
{
"command": "cache-insert",
"arguments": {
"hw-address": "01:02:03:04:05:06",
"subnet-id4": 0,
"subnet-id6": 6,
"ip-addresses": [ "2001:db8::cafe:babe" ],
"prefixes": [ "2001:db8:dead:beef::/64" ],
"hostname": "",
"client-classes4": [ ],
"client-classes6": [ ],
"option-data4": [ ],
"option-data6": [ ],
"next-server": "0.0.0.0",
"server-hostname": "",
"boot-file-name": "",
"host-id": 0
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بود)
این دستور امکان بارگذاری محتوای یک فایل روی دیسک را در یک حافظهٔ نهان درون‌حافظه‌ای فراهم می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 1.4.0 (کتابخانهٔ قلاب host_cache)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-load را ببینید <#command-cache-load>
نحو دستور:
0.0
3.5
{
"command": "cache-load",
"arguments": "/usr/local/share/kea/kea-host-cache.json"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار Result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
cache-remove
این دستور مدخل‌ها را از حافظهٔ نهان میزبان حذف می‌کند. این دستور پارامترهایی مشابه با دستور reservation-get می‌پذیرد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 1.4.0 (کتابخانهٔ قلاب host_cache)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-remove را ببینید <#command-cache-remove>
نحو دستور:
0.0
3.5
{
"command": "cache-remove",
"arguments": {
"ip-address": "192.0.2.1",
"subnet-id": 123
}
}
مثال دیگری که شناسهٔ میزبان IPv6 را بر اساس DUID و subnet-id مشخص حذف می‌کند عبارت است از:
{
"command": "cache-remove",
"arguments": {
"duid": "00:01:ab:cd:f0:a1:c2:d3:e4",
"subnet-id": 123
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار Result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
cache-size
این دستور تعداد مدخل‌های موجود در حافظهٔ نهان میزبان را برمی‌گرداند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 1.6.0 (کتابخانهٔ قلاب host_cache)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-size را ببینید <#command-cache-size>
نحو دستور:
0.0
3.5
{
"command": "cache-size"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "123 entries.",
"arguments": { "size": 123 }
}
168u
168u
مقدار Result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور به Kea فرمان می‌دهد تا محتوای حافظهٔ موقت میزبان (host cache) خود را روی دیسک بنویسد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
دسترس‌پذیری: 1.4.0 (کتابخانهٔ هوک host_cache)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور cache-write را ببینید <#command-cache-write>
نحو دستور:
0.0
3.5
{
"command": "cache-write",
"arguments": "/path/to/the/file.json"
}
168u
168u
این دستور یک آرگومان اجباری می‌پذیرد که مسیر نام فایلی را که باید نوشته شود مشخص می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty - دستور با موفقیت به پایان رسید، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict - دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
class-add
این دستور یک کلاس جدید به پیکربندی موجود سرور اضافه می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
دسترس‌پذیری: 1.5.0 (کتابخانهٔ هوک class_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور class-add را ببینید <#command-class-add>
نحو دستور:
0.0
3.5
{
"command": "class-add",
"arguments": {
"client-classes": [ {
"name": <name of the class>,
"test": <test expression to be evaluated on incoming packets>,
"option-data": [ <option values here> ],
"option-def": [ <option definitions here> ],
"next-server": <ipv4 address>,
"server-hostname": <string>,
"boot-file-name": <name of the boot file>
} ]
}
}
168u
168u
گزینه‌های next-server، server-hostname و boot-file-name مختص DHCPv4 هستند. تنها یک کلاس کلاینت را می‌توان با یک دستور اضافه کرد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "Class '<class-name>' added."
}
168u
168u
این دستور موفقیت‌آمیز است (نتیجه 0)، مگر اینکه نام کلاس تکراری باشد یا خطای دیگری رخ دهد (نتیجه 1).
class-del
این دستور یک کلاس کلاینت را از پیکربندی سرور حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
دسترس‌پذیری: 1.5.0 (کتابخانهٔ هوک class_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور class-del را ببینید <#command-class-del>
نحو دستور:
0.0
3.5
{
"command": "class-del",
"arguments": {
"name": <name of the class>
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "Class '<class-name>' deleted."
}
168u
168u
اگر کلاس کلاینت وجود نداشته باشد، دستور نتیجهٔ 3 (empty) را بازمی‌گرداند. اگر کلاس کلاینت وجود داشته باشد، در صورت موفقیت‌آمیز بودن حذف، نتیجهٔ بازگردانده‌شده 0 است؛ در صورتی که حذف ناموفق باشد، نتیجه 1 خواهد بود..SS class-get
این دستور اطلاعات تفصیلی را درباره یک کلاس کلاینت موجود بازمی‌گرداند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.5.0 (کتابخانه هوک class_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور class-get در <#command-class-get> مراجعه کنید
نحو دستور:
0.0
3.5
{
"command": "class-get",
"arguments": {
"name": <name of the class>
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "Class '<class-name>' definition returned",
"arguments": {
"client-classes": [
{
"name": <name of the class>,
"only-in-additional-list": <only in additional list boolean value>,
"test": <test expression to be evaluated on incoming packets>,
"option-data": [ <option values here> ],
"option-def": [ <option definitions here> ],
"next-server": <ipv4 address>,
"server-hostname": <string>,
"boot-file-name": <name of the boot file>
}
]
}
}
168u
168u
اطلاعات بازگردانده‌شده به نوع سرور DHCP بستگی دارد؛ به این معنی که برخی پارامترها مختص سرور DHCPv4 هستند. همچنین، اگر برخی پارامترها برای کلاس کلاینت تنظیم نشده باشند، ممکن است در پاسخ بازگردانده نشوند. اگر کلاسی با نام مشخص‌شده وجود نداشته باشد، نتیجه ۳ (empty) بازگردانده می‌شود. اگر کلاس کلاینت پیدا شود، نتیجه ۰ بازگردانده خواهد شد. در صورت بروز خطا در حین پردازش دستور، نتیجه ۱ بازگردانده می‌شود.
class-list
این دستور فهرستی از تمامی کلاس‌های کلاینت را از پیکربندی سرور دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.5.0 (کتابخانه هوک class_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور class-list در <#command-class-list> مراجعه کنید
نحو دستور:
0.0
3.5
{
"command": "class-list"
}
168u
168u
این دستور هیچ آرگومانی ندارد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "'<number of>' classes found",
"arguments": {
"client-classes": [
{
"name": <first class name>
},
{
"name": <second class name>
}
]
}
}
168u
168u
فهرست کلاس‌های بازگردانده‌شده صرفاً حاوی نام آن‌هاست. جهت دریافت اطلاعات کامل در مورد یکی از این کلاس‌ها، از دستور class-get در <#command-class-get> استفاده کنید. اگر هیچ کلاسی پیدا نشود، نتیجه بازگردانده‌شده ۳ (empty) است. اگر دستور با موفقیت پردازش شود و فهرست کلاس‌های کلاینت خالی نباشد، نتیجه ۰ بازگردانده می‌شود. در صورت بروز خطا حین پردازش دستور، نتیجه ۱ بازگردانده خواهد شد.
class-update
این دستور یک کلاس کلاینت موجود را در پیکربندی سرور به‌روزرسانی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.5.0 (کتابخانه هوک class_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور class-update در <#command-class-update> مراجعه کنید
config-backend-pull
این دستور سرور را وادار می‌کند تا فوراً با استفاده از Config Backends به‌روزرسانی شود.
این دستور هیچ پارامتری نمی‌پذیرد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.7.1 (توکار)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور config-backend-pull را در <#command-config-backend-pull> ببینید
نحو دستور:
0.0
3.5
{
"command": "config-backend-pull"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "On demand configuration update successful."
}
168u
168u
هنگامی که هیچ Config Backend‌ای پیکربندی نشده باشد، این دستور empty (3) را بازمی‌گرداند؛
اگر خطایی رخ دهد، error (1) همراه با جزئیات خطا بازگردانده می‌شود؛
در غیر این صورت، success (0) بازگردانده خواهد شد.
config-get
این دستور پیکربندی فعلی مورد استفاده سرور را واکشی می‌کند. این پیکربندی اساساً همان محتوای فایل پیکربندی است، اما تغییرات اعمال‌شده توسط سایر دستورها و موارد ناشی از وراثت پارامترها را نیز شامل می‌شود.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.2.0 (توکار)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور config-get را در <#command-config-get> ببینید
نحو دستور:
0.0
3.5
{
"command": "config-get"
}
168u
168u
این دستور هیچ پارامتری نمی‌پذیرد.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"arguments": {
<Dhcp4, Dhcp6, or DhcpDdns object>: <JSON configuration here>
}
}
168u
168u
از نسخه 2.4.0 سامانه Kea به بعد، پاسخ موفقیت‌آمیز حاوی یک خلاصه (digest) بر مبنای SHA256 از پیکربندیِ تازه دریافت‌شده است. ممکن است از این مقدار، احتمالاً با به‌کارگیری config-hash-get، برای تعیین اینکه آیا پیکربندی تغییر کرده است یا خیر استفاده شود.
config-hash-get
این دستور هش (hash) پیکربندی فعلی مورد استفاده سرور را واکشی می‌کند. این
پیکربندی اساساً همان محتوای فایل پیکربندی است، اما شامل تغییرات اعمال‌شده
توسط دستورهای دیگر و موارد ناشی از وراثت پارامترها نیز می‌شود.
در حال حاضر این الگوریتم SHA256 است، اما ممکن است در آینده تغییر کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 2.4.0 (توکار)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور config-hash-get را در <#command-config-hash-get> ببینید
نحو دستور:
0.0
3.5
{
"command": "config-hash-get"
}
168u
168u
این دستور هیچ پارامتری نمی‌پذیرد.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"arguments": {
"hash": <SHA256 hash of the config in hexa>
}
}
168u
168u
نتیجه (Result) نمایشی از وضعیت به‌صورت یک عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور به Kea فرمان می‌دهد تا فایل پیکربندی را که پیش‌تر استفاده شده بود، دوباره بارگذاری کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
دردسترس بودن: 1.2.0 (توکار)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور config-reload را ببینید <#command-config-reload>
نحو دستور:
0.0
3.5
{
"command": "config-reload"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
config-set
این دستور به سرور فرمان می‌دهد که پیکربندی فعلی خود را با پیکربندی جدید ارائه‌شده در آرگومان‌های دستور جایگزین کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
دردسترس بودن: 1.2.0 (توکار)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور config-set را ببینید <#command-config-set>
نحو دستور:
0.0
3.5
{
"command": "config-set",
"arguments": {
"'<server>'": {
}
}
}
168u
168u
در مثال زیر، '<server>' نام عنصر پیکربندی برای یک سرور معین مانند "Dhcp4" یا "Dhcp6" است.
نحو پاسخ:
0.0
3.5
{
"arguments": {
"hash": "8B5F5822E93178B65CE658304C37EA511BDE7D29F792AA5E88012FC741F2BE32"
},
"result": 0,
"text": "Configuration successful."
}
or
{ "result": 1, "text": "unsupported parameter: BOGUS (<string>:16:26)" }
168u
168u
از نسخه 2.4.0 Kea به بعد، پاسخ موفقیت‌آمیز از سوی دیمن‌های DHCPv4، DHCPv6 یا DHCP-DDNS
همچنین شامل یک خلاصه (digest) SHA-256 از پیکربندی جدیداً تنظیم‌شده است. از این خلاصه می‌توان
به‌سادگی برای تشخیص اینکه آیا پیکربندی تغییر کرده است یا خیر، احتمالاً با استفاده از config-hash-get، بهره برد.
config-test
این دستور به سرور فرمان می‌دهد بررسی کند که آیا پیکربندی جدید ارائه‌شده در آرگومان‌های دستور قابل بارگذاری است یا خیر.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
دردسترس بودن: 1.2.0 (توکار)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور config-test را ببینید <#command-config-test>
نحو دستور:
0.0
3.5
{
"command": "config-test",
"arguments": {
"'<server>'": {
}
}
}
168u
168u
در مثال زیر، '<server>' نام عنصر پیکربندی برای یک سرور معین مانند "Dhcp4" یا "Dhcp6" است.
نحو پاسخ:
0.0
3.5
{ "result": 0, "text": "Configuration seems sane." }
or
{ "result": 1, "text": "unsupported parameter: BOGUS (<string>:16:26)" }
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور به کارساز Kea دستور می‌دهد تا پیکربندی
فعلی خود را درون فایلی روی دیسک بنویسد.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.2.0 (توکار)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور config-write را ببینید <#command-config-write>
نحو دستور:
0.0
3.5
{
"command": "config-write",
"arguments": {
"filename": "config-modified-2017-03-15.json"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
168u
dhcp-disable
این دستور سرویس DHCP را غیرفعال می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.4.0 (توکار)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور dhcp-disable را ببینید <#command-dhcp-disable>
نحو دستور:
0.0
3.5
{
"command": "dhcp-disable",
"arguments": {
"max-period": 20,
"origin": "ha-partner",
"origin-id": 2002
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
168u
dhcp-enable
این دستور سرویس DHCP را فعال می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.4.0 (توکار)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور dhcp-enable را ببینید <#command-dhcp-enable>
نحو دستور:
0.0
3.5
{
"command": "dhcp-enable",
"arguments": {
"origin": "ha-partner",
"origin-id": 2002
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
این دستور اطلاعات تکمیلی (extended info) تمام اجاره‌های IPv4 را پالایش کرده و ستون‌های relay و remote ID را در پایگاه‌داده اجاره‌های SQL پر می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 2.3.8 (کتابخانه قلاب lease_query)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور extended-info4-upgrade را ببینید <#command-extended-info4-upgrade>
نحو دستور:
0.0
3.5
{
"command": "extended-info4-upgrade"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
},
"result": 0,
"text": "Upgraded 1000 leases"
}
168u
168u
این دستور زمانی باید استفاده شود که تعدادی اجاره قدیمی IPv4 در پایگاه‌داده اجاره با بک‌اند SQL وجود داشته باشند.
extended-info6-upgrade
این دستور اطلاعات تکمیلی (extended info) تمام اجاره‌های IPv6 را پالایش کرده و در صورت فعال بودن، جدول‌های relay و remote ID را در پایگاه‌داده اجاره‌های SQL بازسازی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 2.5.0 (کتابخانه قلاب lease_query)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور extended-info6-upgrade را ببینید <#command-extended-info6-upgrade>
نحو دستور:
0.0
3.5
{
"command": "extended-info6-upgrade"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
},
"result": 0,
"text": "Upgraded 1000 leases"
}
168u
168u
این دستور زمانی باید استفاده شود که برخی اجاره‌های قدیمی IPv6 در پایگاه‌داده اجاره با بک‌اند SQL وجود داشته باشند تا آن‌ها را برای . قابل مشاهده سازد.
gss-tsig-get
این دستور اطلاعات مربوط به کارساز GSS-TSIG مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
در دسترس بودن: 2.0.0 (کتابخانه قلاب gss_tsig)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-get را ببینید <#command-gss-tsig-get>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-get",
"arguments": {
"server-id": "foo"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "GSS-TSIG server[foo] found",
"arguments": {
"id": "foo",
"ip-address": "192.1.2.3",
"port": 53,
"server-principal": "DNS/foo.com@FOO.COM",
"key-name-suffix": "foo.com.",
"tkey-lifetime": 3600,
"tkey-protocol": "TCP",
"keys": [
{
"name": "1234.sig-foo.com.",
"server-id": "foo",
"inception-date": "2021-09-05 12:23:36.281176",
"expire-date": "2021-09-05 13:23:36.281176",
"status": "not yet ready",
"tkey-exchange": true
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
این دستور کارسازها و کلیدهای GSS-TSIG را فهرست می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
در دسترس در: 2.0.0 (کتابخانه هوک gss_tsig)
سطح دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور gss-tsig-get-all در <#command-gss-tsig-get-all> مراجعه کنید
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-get-all"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 GSS-TSIG servers and 1 keys",
"arguments": {
"gss-tsig-servers": [
{
"id": "foo",
"ip-address": "192.1.2.3",
"port": 53,
"server-principal": "DNS/foo.com@FOO.COM",
"key-name-suffix": "foo.com.",
"tkey-lifetime": 3600,
"tkey-protocol": "TCP",
"keys": [
{
"name": "1234.sig-foo.com.",
"inception-date": "2021-09-05 12:23:36.281176",
"server-id": "foo",
"expire-date": "2021-09-05 13:23:36.281176",
"status": "not yet ready",
"tkey-exchange": true
}
]
},
{
"id": "bar",
"ip-address": "192.1.2.4",
"port": 53,
"server-principal": "DNS/bar.com@FOO.COM",
"key-name-suffix": "bar.com.",
"tkey-lifetime": 7200,
"tkey-protocol": "UDP",
"keys": [ ]
}
]
}
}
168u
168u
نتیجه (Result) نمایشی عددی از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت‌آمیز
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
168u
gss-tsig-key-del
این دستور کلید GSS-TSIG مشخص‌شده را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
در دسترس در: 2.0.0 (کتابخانه هوک gss_tsig)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور gss-tsig-key-del در <#command-gss-tsig-key-del> مراجعه کنید
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-key-del",
"arguments": {
"key-name": "1234.sig-foo.com."
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "GSS-TSIG key '1234.sig-foo.com.' deleted"
}
168u
168u
نتیجه (Result) نمایشی عددی از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت‌آمیز
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
این دستور کلید GSS-TSIG مشخص‌شده را منقضی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
دسترس‌پذیری: 2.0.0 (کتابخانه هوک gss_tsig)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-key-expire را ببینید <#command-gss-tsig-key-expire>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-key-expire",
"arguments": {
"key-name": "1234.sig-foo.com."
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "GSS-TSIG key '1234.sig-foo.com.' expired"
}
168u
168u
نتیجه، نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
gss-tsig-key-get
این دستور اطلاعات مربوط به کلید GSS-TSIG مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
دسترس‌پذیری: 2.0.0 (کتابخانه هوک gss_tsig)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-key-get را ببینید <#command-gss-tsig-key-get>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-key-get",
"arguments": {
"key-name": "1234.sig-foo.com."
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "GSS-TSIG key '1234.sig-foo.com.' found",
"arguments": {
"name": "1234.sig-foo.com.",
"server-id": "foo",
"inception-date": "2021-09-05 12:23:36.281176",
"expire-date": "2021-09-05 13:23:36.281176",
"status": "not yet ready",
"tkey-exchange": true
}
}
168u
168u
نتیجه، نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
gss-tsig-list
این دستور شناسه‌های سرور GSS-TSIG و نام‌های کلید را فهرست می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
دسترس‌پذیری: 2.0.0 (کتابخانه هوک gss_tsig)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-list را ببینید <#command-gss-tsig-list>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-list"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 GSS-TSIG servers and 3 keys",
"arguments": {
"gss-tsig-servers": [
"foo",
"bar"
],
"gss-tsig-keys": [
"1234.example.com.",
"5678.example.com.",
"43888.example.org."
]
}
}
168u
168u
نتیجه، نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور کلیدهای غیرقابل استفادهٔ GSS-TSIG را برای سرور مشخص‌شده حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
دسترس‌پذیری: 2.0.0 (کتابخانهٔ قلاب gss_tsig)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-purge را ببینید <#command-gss-tsig-purge>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-purge",
"arguments": {
"server-id": "foo"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 purged keys for GSS-TSIG server[foo]"
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - success (موفقیت)
• 2
1 - error (خطا)
• 2
2 - unsupported (پشتیبانی‌نشده)
• 2
3 - empty (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - conflict (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
gss-tsig-purge-all
این دستور کلیدهای غیرقابل استفادهٔ GSS-TSIG را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns
دسترس‌پذیری: 2.0.0 (کتابخانهٔ قلاب gss_tsig)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-purge-all را ببینید <#command-gss-tsig-purge-all>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-purge-all"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 purged GSS-TSIG keys"
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - success (موفقیت)
• 2
1 - error (خطا)
• 2
2 - unsupported (پشتیبانی‌نشده)
• 2
3 - empty (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - conflict (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
gss-tsig-rekey
این دستور بدون قید و شرط کلیدهای جدید GSS-TSIG را برای سرور DNS مشخص‌شده ایجاد می‌کند (عملیات rekey را انجام می‌دهد).
پشتیبانی‌شده توسط: kea-dhcp-ddns
دسترس‌پذیری: 2.0.0 (کتابخانهٔ قلاب gss_tsig)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-rekey را ببینید <#command-gss-tsig-rekey>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-rekey",
"arguments": {
"server-id": "foo"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "GSS-TSIG server[foo] rekeyed"
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - success (موفقیت)
• 2
1 - error (خطا)
• 2
2 - unsupported (پشتیبانی‌نشده)
• 2
3 - empty (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - conflict (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور بدون قید و شرط کلیدهای جدید GSS-TSIG را برای تمام کارگزارهای DNS ایجاد می‌کند (کلیدزنی مجدد یا rekey).
پشتیبانی‌شده توسط: kea-dhcp-ddns
در دسترس بودن: 2.0.0 (کتابخانه قلاب gss_tsig)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور gss-tsig-rekey-all را ببینید <#command-gss-tsig-rekey-all>
نحو دستور:
0.0
3.5
{
"command": "gss-tsig-rekey-all"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "rekeyed"
}
168u
168u
نتیجه (result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - تهی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تعارض بود)
168u
ha-continue
این دستور عملکرد یک ماشین وضعیت HA متوقف‌شده (paused) را از سر می‌گیرد.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
در دسترس بودن: 1.4.0 (کتابخانه قلاب high_availability)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور ha-continue را ببینید <#command-ha-continue>
نحو دستور:
0.0
3.5
{
"command": "ha-continue",
"arguments": {
"server-name": "server1"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه (result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - تهی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تعارض بود)
168u
ha-heartbeat
این دستور به‌طور داخلی توسط یک همتای Kea هنگام کار در حالت دسترسی‌پذیری بالا (HA) یا توسط مدیر سیستم برای بررسی وضعیت کارگزاران از نظر دسترسی‌پذیری بالا ارسال می‌شود. این دستور وضعیت HA و مقدار ساعت کارگزار را دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
در دسترس بودن: 1.4.0 (کتابخانه قلاب high_availability)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور ha-heartbeat را ببینید <#command-ha-heartbeat>
نحو دستور:
0.0
3.5
{
"command": "ha-heartbeat",
"arguments": {
"server-name": "server1"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "HA peer status returned.",
"arguments": {
"state": <server state>,
"date-time": <server notion of time>,
"scopes": [ <first scope>, <second scope>, ... ],
"unsent-update-count": <total number of lease allocations in partner-down state>
}
}
168u
168u
پاسخ شامل وضعیت کارگزار (وضعیت‌های کارگزار را ببینید <#ha-server-states>)، مقدار ساعت فعلی، محدوده‌های (scopes) سرویس‌دهی‌شده و شمارنده‌ای است که مشخص می‌کند کارگزار چه تعداد اجاره را بدون ارسال به‌روزرسانی‌های اجاره به همتای خود تخصیص داده است. همتا از این شمارنده برای تشخیص اینکه آیا باید پایگاه داده اجاره‌های خود را همگام‌سازی کند یا خیر استفاده می‌کند..SS ha-maintenance-cancel
این دستور برای هدایت کارگزاری که در وضعیت partner-in-maintenance قرار دارد
به بازگشت به وضعیت پیشین ارسال می‌شود و در عمل، عملیات نگهداری را لغو می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.7.4 (کتابخانه هوک high_availability)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور ha-maintenance-cancel مراجعه کنید <#command-ha-maintenance-cancel>
نحو دستور:
0.0
3.5
{
"command": "ha-maintenance-cancel"
}
168u
168u
این دستور هیچ آرگومانی نمی‌پذیرد.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک مقدار عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت کارگزار در تداخل بودند)
168u
ha-maintenance-notify
این دستور توسط کارگزاری که ha-maintenance-start را دریافت کرده است
به همتای خود ارسال می‌شود تا باعث انتقال همتا به وضعیت in-maintenance گردد
یا در نتیجه دریافت دستور ha-maintenance-cancel، آن را از وضعیت in-maintenance بازگرداند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.7.4 (کتابخانه هوک high_availability)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور ha-maintenance-notify مراجعه کنید <#command-ha-maintenance-notify>
نحو دستور:
0.0
3.5
{
"command": "ha-maintenance-notify",
"arguments": {
"cancel": true,
"state": "ready"
}
}
168u
168u
این دستور شامل یک آرگومان بولی است که اگر false باشد، نشان می‌دهد
که کارگزار باید به وضعیت in-maintenance منتقل شود.
اگر آرگومان cancel بر روی true تنظیم شده باشد، به کارگزار دستور می‌دهد که از
وضعیت in-maintenance به وضعیت پیشین خود بازگردد. آرگومان state گیرنده را
از وضعیت کارگزار فرستنده مطلع می‌سازد.
این دستور برای استفاده توسط مدیر سیستم در نظر گرفته نشده است؛ بلکه
صرفاً برای ارتباطات داخلی میان همتاهای HA استفاده می‌شود.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
پاسخ ممکن است شامل یک کد خطای ویژه 1001 باشد
که نشان می‌دهد همتا از ورود به وضعیت نگهداری امتناع کرده است.
ha-maintenance-start
این دستور برای دستور دادن به یکی از کارگزارها جهت انتقال
به وضعیت partner-in-maintenance ارسال می‌شود که در آن وضعیت، به
تمامی پرس‌وجوهای DHCP پاسخ خواهد داد. کارگزاری که این دستور را دریافت می‌کند، دستور
ha-maintenance-notify را به همتای خود ارسال می‌کند تا باعث انتقال همتا
به وضعیت in-maintenance شود.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.7.4 (کتابخانه هوک high_availability)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور ha-maintenance-start مراجعه کنید <#command-ha-maintenance-start>
نحو دستور:
0.0
3.5
{
"command": "ha-maintenance-start"
}
168u
168u
این دستور هیچ آرگومانی نمی‌پذیرد.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک مقدار عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت کارگزار در تداخل بودند)
این فرمان ماشین حالت HA کارگزار را با انتقال آن به وضعیت waiting بازنشانی می‌کند.
پشتیبانی توسط: kea-dhcp4، kea-dhcp6
در دسترس در: 1.9.4 (کتابخانه قلاب high_availability)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: فرمان ha-reset را ببینید <#command-ha-reset>
نحو فرمان:
0.0
3.5
{
"command": "ha-reset",
"arguments": {
"server-name": "server1"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (فرمان با موفقیت تکمیل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (فرمان نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بودند)
168u
ha-scopes
این فرمان دامنه‌ای (scope) را که کارگزار هنگام کار در حالت دسترس‌پذیری بالا (HA) مسئول سرویس‌دهی به آن است، تغییر می‌دهد.
پشتیبانی توسط: kea-dhcp4، kea-dhcp6
در دسترس در: 1.4.0 (کتابخانه قلاب high_availability)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: فرمان ha-scopes را ببینید <#command-ha-scopes>
نحو فرمان:
0.0
3.5
{
"command": "ha-scopes",
"arguments": {
"scopes": [ "HA_server1", "HA_server2" ],
"server-name": "server1"
}
}
168u
168u
در مثال زیر، آرگومان‌ها کارگزار را برای مدیریت ترافیک هر دو دامنهٔ HA_server1 و HA_server2 پیکربندی می‌کنند.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (فرمان با موفقیت تکمیل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (فرمان نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بودند)
168u
ha-sync
این فرمان به کارگزاری که در حالت HA اجرا می‌شود دستور می‌دهد تا پایگاه‌داده اجاره‌های (lease database) محلی خود را با همتای (peer) انتخاب‌شده همگام‌سازی کند.
پشتیبانی توسط: kea-dhcp4، kea-dhcp6
در دسترس در: 1.4.0 (کتابخانه قلاب high_availability)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: فرمان ha-sync را ببینید <#command-ha-sync>
نحو فرمان:
0.0
3.5
{
"command": "ha-sync",
"arguments": {
"server-name": "server1",
"max-period": 60
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (فرمان با موفقیت تکمیل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (فرمان نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بودند)
یک سرور با استفاده از این دستور به شریک (partner) خود اطلاع می‌دهد که همگام‌سازی پایگاه‌داده اجاره‌ها (lease database) را به پایان رسانده است. اگر شریک در وضعیت partner-down باشد، موقتاً تخصیص اجاره‌های جدید را تا زمان انتقال به وضعیت عملیاتی عادی (مانند load-balancing) متوقف می‌کند. در صورتی که شریک متوجه عدم پاسخگویی ضربان قلب (heartbeat) شود، می‌تواند تخصیص اجاره‌های جدید را در وضعیت partner-down از سر بگیرد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 1.9.11 (کتابخانه قلاب high_availability)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور ha-sync-complete-notify را ببینید <#command-ha-sync-complete-notify>
نحو دستور:
0.0
3.5
{
"command": "ha-sync-complete-notify",
"arguments": {
"server-name": "server1",
"origin": 2001,
"max-period": 60
}
}
168u
168u
این دستور هیچ آرگومانی نمی‌پذیرد.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک مقدار عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
interface-add
این دستور فهرست رابط‌های مورد استفاده برای پردازش ترافیک DHCP را به‌روزرسانی می‌کند. این دستور فهرستی از رابط‌ها را به همراه نشانی‌های مربوطه (در صورت تعیین) که سرور باید گوش دادن به ترافیک DHCP را روی آن‌ها آغاز کند، به عنوان پارامتر می‌پذیرد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 3.1.9 (توکار - built-in)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور interface-add را ببینید <#command-interface-add>
نحو دستور:
0.0
3.5
{
"command": "interface-add",
"arguments": {
"interfaces": [ "eth0/10.10.1.1", "eth0/192.168.1.1", "eth1"]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "Operation succeeded."
}
168u
168u
نتیجه یک مقدار عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
interface-list
این دستور فهرست رابط‌های شناسایی‌شده را بازیابی می‌کند. این دستور هیچ پارامتری نمی‌پذیرد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 3.1.9 (توکار - built-in)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور interface-list را ببینید <#command-interface-list>
نحو دستور:
0.0
3.5
{
"command": "interface-list"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 interfaces detected.",
"arguments": {
"interfaces": [ {
"name": "eth0",
"index": 4,
"mac": "00:11:22:33:44:55",
"type": 6,
"addresses": [ "192.168.1.1", "10.10.1.1",
"2003:db8:1::1", "3001:db8:1::1",
"fe80::3a60:77ff:fed5:abcd" ],
"flag-loopback": false,
"flag-up": true,
"flag-running": true,
"flag-multicast": false,
"flag-broadcast": false,
"in-use": true
}, {
"name": "eth1",
"index": 7,
"mac": "11:22:33:44:55:66",
"type": 6,
"addresses": [ "10.10.1.2",
"2003:db8:1::2",
"fe80::3a60:77ff:fed5:1234" ],
"flag-loopback": false,
"flag-up": true,
"flag-running": true,
"flag-multicast": false,
"flag-broadcast": false,
"in-use": false
}]
}
}
168u
168u
نتیجه یک مقدار عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
این دستور، پس از انجام یک فرآیند شناسایی مجدد که تنها رابط‌های تازه کشف‌شده را اضافه کرده
و هیچ‌یک از رابط‌های شناسایی‌شده پیشین را حذف نمی‌کند، فهرست رابط‌های شناسایی‌شده را بازیابی می‌کند.
این دستور هیچ پارامتری نمی‌پذیرد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 3.1.9 (توکار)
دسترسی: write (در این نسخه Kea این پارامتر نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور interface-redetect را ببینید <#command-interface-redetect>
نحو دستور:
0.0
3.5
{
"command": "interface-redetect"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "3 interfaces detected.",
"arguments": {
"interfaces": [ {
"name": "eth0",
"index": 4,
"mac": "00:11:22:33:44:55",
"type": 6,
"addresses": [ "192.168.1.1", "10.10.1.1", "130.50.1.1",
"2003:db8:1::1", "3001:db8:1::1",
"fe80::3a60:77ff:fed5:abcd" ],
"flag-loopback": false,
"flag-up": true,
"flag-running": true,
"flag-multicast": false,
"flag-broadcast": false,
"in-use": true
}, {
"name": "eth1",
"index": 7,
"mac": "11:22:33:44:55:66",
"type": 6,
"addresses": [ "10.10.1.2",
"2003:db8:1::2",
"fe80::3a60:77ff:fed5:1234" ],
"flag-loopback": false,
"flag-up": true,
"flag-running": true,
"flag-multicast": false,
"flag-broadcast": false,
"in-use": false
}, {
"name": "eth2",
"index": 8,
"mac": "22:33:44:55:66:77",
"type": 6,
"addresses": [ "192.168.1.2",
"3001:db8:1::2",
"fe80::3a60:77ff:fed5:5678" ],
"flag-loopback": false,
"flag-up": true,
"flag-running": false,
"flag-multicast": false,
"flag-broadcast": false,
"in-use": false
}]
}
}
168u
168u
نتیجه (Result)، نمایشی عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
kea-lfc-start
این دستور فرآیند kea-lfc را آغاز می‌کند که وظیفه پاک‌سازی فایل اجاره‌ها را بر عهده دارد.
این دستور هیچ پارامتری دریافت نمی‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 3.1.2 (توکار)
دسترسی: write (در این نسخه Kea این پارامتر نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور kea-lfc-start را ببینید <#command-kea-lfc-start>
نحو دستور:
0.0
3.5
{
"command": "kea-lfc-start"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه (Result)، نمایشی عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور به‌طور مدیریتی یک اجارهٔ IPv4 جدید اضافه می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس از: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-add را ببینید <#command-lease4-add>
نحو دستور:
0.0
3.5
{
"command": "lease4-add",
"arguments": {
"ip-address": "192.0.2.202",
"hw-address": "1a:1b:1c:1d:1e:1f"
}
}
168u
168u
توجه داشته باشید که Kea 1.4 به یک آرگومان اضافی به نام subnet-ID نیاز دارد که از Kea 1.5 به بعد اختیاری است. همچنین تعدادی آرگومان اختیاری دیگر و با جزئیات بیشتر پشتیبانی می‌شوند.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
اگر نتیجهٔ بازگردانده‌شده برابر با 4 باشد، نشان‌دهندهٔ این است که امکان ایجاد اجاره وجود نداشته است زیرا با وضعیت سرور یا برداشت آن از پیکربندی در تضاد بوده است. کتابخانهٔ قلاب High Availability می‌تواند با چنین نتیجه‌ای متفاوت از یک خطای عمومی رفتار کند. خطای عمومی 1 می‌تواند نشان‌دهندهٔ مشکلاتی در پردازش دستور، در دسترس بودن پایگاه داده و غیره باشد.
lease4-del
این دستور یک اجاره را از پایگاه دادهٔ اجاره‌ها حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس از: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-del را ببینید <#command-lease4-del>
نحو دستور:
0.0
3.5
{
"command": "lease4-del",
"arguments": {
"ip-address": "192.0.2.202"
}
}
168u
168u
اجاره‌ای که باید حذف شود می‌تواند بر اساس نشانی IP یا نوع شناسه و مقدار شناسه مشخص گردد. شناسه‌هایی که در حال حاضر پشتیبانی می‌شوند "hw-address" و "client-id" هستند.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تضاد بودند)
168u
lease4-get
این دستور پایگاه دادهٔ اجاره‌ها را پرس‌وجو کرده و اجاره‌های موجود را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس از: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-get را ببینید <#command-lease4-get>
نحو دستور:
0.0
3.5
{
"command": "lease4-get",
"arguments": {
"ip-address": "192.0.2.1"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"client-id": "42:42:42:42:42:42:42:42",
"cltt": 12345678,
"fqdn-fwd": false,
"fqdn-rev": true,
"hostname": "myhost.example.com.",
"hw-address": "08:08:08:08:08:08",
"ip-address": "192.0.2.1",
"state": 0,
"subnet-id": 44,
"valid-lft": 3600
},
"result": 0,
"text": "IPv4 lease found."
}
168u
168u
دستور lease4-get نتیجه‌ای را بازمی‌گرداند که وضعیت عملیات و در صورت یافت شدن، جزئیات اجاره را مشخص می‌کند. این خروجی یکی از مقادیر زیر را دارد: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی). نتیجهٔ 3 زمانی بازگردانده می‌شود که هیچ اجاره‌ای با نشانی IP مشخص‌شده پیدا نشود..SS lease4-get-all
این دستور تمام اجاره‌های IPv4 یا تمام اجاره‌های مربوط به مجموعه زیرشبکه‌های مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دردسترس از: 1.4.0 (کتابخانه قلاب lease_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور lease4-get-all مراجعه کنید <#command-lease4-get-all>
نحو دستور:
0.0
3.5
{
"command": "lease4-get-all",
"arguments": {
"subnets": [ 1, 2, 3, ... ]
}
}
168u
168u
دستور lease4-get-all ممکن است به پاسخ‌های بسیار بزرگی منجر شود. لطفاً استفاده از lease4-get-page را برای دریافت آن‌ها به صورت بخش‌بخش در نظر داشته باشید. پارامتر subnets اختیاری است. اگر مشخص نشود، اجاره‌های همه زیرشبکه‌ها بازگردانده می‌شوند.
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"client-id": "01:00:0c:01:02:03:04",
"cltt": 1600432232,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "00:0c:01:02:03:04",
"ip-address": "192.168.1.150",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
},
{
"client-id": "01:00:0c:01:02:03:05",
"cltt": 1600432234,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "00:0c:01:02:03:05",
"ip-address": "192.168.1.151",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "2 IPv4 lease(s) found."
}
168u
168u
نتیجه 0 زمانی بازگردانده می‌شود که حداقل یک اجاره پیدا شود، 1 زمانی که پارامترها ناقص باشند یا وجود نداشته باشند، و 3 در صورتی بازگردانده می‌شود که هیچ اجاره‌ای با پارامتر مشخص‌شده پیدا نشود.
lease4-get-by-client-id
این دستور تمام اجاره‌های IPv4 دارای client id مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دردسترس از: 1.7.1 (کتابخانه قلاب lease_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور lease4-get-by-client-id مراجعه کنید <#command-lease4-get-by-client-id>
نحو دستور:
0.0
3.5
{
"command": "lease4-get-by-client-id",
"arguments": {
"client-id": "01:00:0c:01:02:03:04"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"client-id": "01:00:0c:01:02:03:04",
"cltt": 1600432232,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "00:0c:01:02:03:04",
"ip-address": "192.168.1.150",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
168u
168u
نتیجه 0 زمانی بازگردانده می‌شود که حداقل یک اجاره پیدا شود، 1 زمانی که پارامترها ناقص باشند یا وجود نداشته باشند، و 3 در صورتی بازگردانده می‌شود که هیچ اجاره‌ای یافت نشود..SS lease4-get-by-hostname
این دستور تمام اجاره‌های IPv4 با نام میزبان مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.7.1 (کتابخانه هوک lease_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-get-by-hostname را ببینید <#command-lease4-get-by-hostname>
ساختار دستور:
0.0
3.5
{
"command": "lease4-get-by-hostname",
"arguments": {
"hostname": "myhost.example.com."
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"client-id": "01:00:0c:01:02:03:04",
"cltt": 1600432232,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "myhost.example.com.",
"hw-address": "00:0c:01:02:03:04",
"ip-address": "192.168.1.150",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
168u
168u
در صورتی که حداقل یک اجاره یافت شود نتیجه 0، اگر پارامترها نامعتبر بوده یا وجود نداشته باشند 1،
و اگر هیچ اجاره‌ای پیدا نشود نتیجه 3 برگردانده می‌شود.
lease4-get-by-hw-address
این دستور تمام اجاره‌های IPv4 با آدرس سخت‌افزاری مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.7.1 (کتابخانه هوک lease_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-get-by-hw-address را ببینید <#command-lease4-get-by-hw-address>
ساختار دستور:
0.0
3.5
{
"command": "lease4-get-by-hw-address",
"arguments": {
"hw-address": "00:0c:01:02:03:04"
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"client-id": "01:00:0c:01:02:03:04",
"cltt": 1600432232,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "myhost.example.com.",
"hw-address": "00:0c:01:02:03:04",
"ip-address": "192.168.1.150",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
168u
168u
در صورتی که حداقل یک اجاره یافت شود نتیجه 0، اگر پارامترها نامعتبر بوده یا وجود نداشته باشند 1،
و اگر هیچ اجاره‌ای پیدا نشود نتیجه 3 برگردانده می‌شود.
lease4-get-by-state
0.0
این دستور تمام اجاره‌های IPv4 با وضعیت مشخص‌شده را
و به‌صورت اختیاری در یک زیرشبکه بازیابی می‌کند.
168u
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 3.1.5 (کتابخانه هوک lease_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-get-by-state را ببینید <#command-lease4-get-by-state>
ساختار دستور:
0.0
3.5
{
"command": "lease4-get-by-state",
"arguments": {
"state": 1,
"subnet-id": 1
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"client-id": "01:00:0c:01:02:03:04",
"cltt": 1600432232,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "00:0c:01:02:03:04",
"ip-address": "192.168.1.150",
"state": 1,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
168u
168u
در صورتی که حداقل یک اجاره یافت شود نتیجه 0، اگر پارامترها نامعتبر بوده یا وجود نداشته باشند 1،
و اگر هیچ اجاره‌ای پیدا نشود نتیجه 3 برگردانده می‌شود..SS lease4-get-page
این دستور تمامی اجاره‌های (leases) IPv4 را به صورت صفحه‌بندی‌شده دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.5.0 (کتابخانه قلاب lease_cmds)
دسترسی: خواندن (read) (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-get-page را در <#command-lease4-get-page> ببینید
نحو دستور:
0.0
3.5
{
"command": "lease4-get-page",
"arguments": {
"limit": <integer>,
"from": <IPv4 address or 'start'>
}
}
168u
168u
آدرس from و محدودیت اندازه صفحه (limit) اجباری هستند.
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"client-id": "01:00:0c:01:02:03:04",
"cltt": 1600432232,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "00:0c:01:02:03:04",
"ip-address": "192.168.1.150",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
},
{
"client-id": "01:00:0c:01:02:03:05",
"cltt": 1600432234,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "00:0c:01:02:03:05",
"ip-address": "192.168.1.151",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "2 IPv4 lease(s) found."
}
168u
168u
نتیجه 0 زمانی برگردانده می‌شود که حداقل یک اجاره پیدا شود، 1 زمانی که پارامترها نامعتبر یا ناموجود باشند، و 3 در صورتی برگردانده می‌شود که هیچ اجاره‌ای با پارامترهای مشخص‌شده یافت نشود.
lease4-resend-ddns
این دستور یک درخواست مجدد به kea-dhcp-ddns برای به‌روزرسانی DNS جهت یک اجاره موجود ارسال می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.7.6 (کتابخانه قلاب lease_cmds)
دسترسی: نوشتن (write) (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-resend-ddns را در <#command-lease4-resend-ddns> ببینید
نحو دستور:
0.0
3.5
{
"command": "lease4-resend-ddns",
"arguments": {
"ip-address": "192.0.2.1"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
},
"result": 0,
"text": "NCR generated for: 192.0.2.1, hostname: example.com."
}
168u
168u
دستور lease4-resend-ddns نتیجه‌ای را بازمی‌گرداند که وضعیت اجرای عملیات و در صورت یافت شدن، جزئیات اجاره را نشان می‌دهد. این نتیجه یکی از مقادیر زیر خواهد بود: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی).
lease4-update
این دستور اجاره‌های موجود را به‌روزرسانی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: نوشتن (write) (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-update را در <#command-lease4-update> ببینید
نحو دستور:
0.0
3.5
{
"command": "lease4-update",
"arguments": {
"ip-address": "192.0.2.1",
"hostname": "newhostname.example.org",
"hw-address": "1a:1b:1c:1d:1e:1f",
"subnet-id": 44,
"force-create": true
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
اگر نتیجه بازگردانده‌شده برابر با 4 باشد، نشان می‌دهد که اجاره به دلیل تداخل با وضعیت سرور یا درک آن از پیکربندی نتوانسته است به‌روزرسانی شود. کتابخانه قلاب High Availability می‌تواند چنین نتیجه‌ای را به شکلی متفاوت از یک خطای عمومی مدیریت کند. خطای عمومی 1 می‌تواند نشان‌دهنده مشکلاتی در پردازش دستور، در دسترس بودن پایگاه داده و غیره باشد..SS lease4-wipe
این دستور تمام اجاره‌های مرتبط با یک زیرشبکه مشخص را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دردسترس‌بودن: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-wipe را ببینید <#command-lease4-wipe>
نحو دستور:
0.0
3.5
{
"command": "lease4-wipe",
"arguments": {
"subnet-id": 44
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه نمایشی عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
lease4-write
این دستور پایگاه‌داده اجاره memfile مربوط به IPv4 را درون یک فایل CSV می‌نویسد.
پشتیبانی‌شده توسط: kea-dhcp4
دردسترس‌بودن: 2.3.1 (کتابخانه قلاب lease_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease4-write را ببینید <#command-lease4-write>
نحو دستور:
0.0
3.5
{
"command": "lease4-write",
"arguments": {
"filename": "a_file.csv"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه نمایشی عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
lease6-add
این دستور به‌صورت مدیریتی یک اجاره جدید ایجاد می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دردسترس‌بودن: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-add را ببینید <#command-lease6-add>
نحو دستور:
0.0
3.5
{
"command": "lease6-add",
"arguments": {
"subnet-id": 66,
"ip-address": "2001:db8::3",
"duid": "1a:1b:1c:1d:1e:1f:20:21:22:23:24",
"iaid": 1234
}
}
168u
168u
همچنین می‌توان از lease6-add برای افزودن اجاره‌ها جهت پیشوندهای IPv6 استفاده کرد.
نحو پاسخ:
0.0
3.5
{ "result": 0, "text": "Lease added." }
or
{ "result": 1, "text": "missing parameter 'ip-address' (<string>:3:19)" }
168u
168u
اگر نتیجه بازگردانده‌شده برابر با 4 باشد، نشان‌دهنده این است که اجاره نتوانسته ایجاد شود زیرا با وضعیت سرور یا برداشت آن از پیکربندی در تداخل بوده است. کتابخانه قلاب High Availability می‌تواند چنین نتیجه‌ای را به شکلی متفاوت از یک خطای عمومی مدیریت کند. خطای عمومی 1 می‌تواند نشان‌دهنده مشکلاتی در پردازش دستور، دردسترس‌بودن پایگاه‌داده و غیره باشد..SS lease6-bulk-apply
این دستور چندین اجاره‌ی IPv6 را در یک تراکنش واحد ایجاد، به‌روزرسانی یا حذف می‌کند. این دستور تغییرات اجاره را میان همتایان HA تبادل می‌کند، اما در تمامی مواردی که اعمال چندین به‌روزرسانی اجاره در یک تراکنش واحد مطلوب باشد نیز قابل استفاده است.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه هوک lease_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-bulk-apply را ببینید <#command-lease6-bulk-apply>
نحو دستور:
0.0
3.5
{
"command": "lease6-bulk-apply",
"arguments": {
"deleted-leases": [
{
"ip-address": "2001:db8:abcd::",
"type": "IA_PD",
...
},
{
"ip-address": "2001:db8:abcd::234",
"type": "IA_NA",
...
}
],
"leases": [
{
"subnet-id": 66,
"ip-address": "2001:db8:cafe::",
"type": "IA_PD",
...
},
{
"subnet-id": 66,
"ip-address": "2001:db8:abcd::333",
"type": "IA_NA",
...
}
]
}
}
168u
168u
اگر هر یک از اجاره‌ها ساختار نامعتبری داشته باشد، تمام تغییرات به عقب بازگردانده می‌شوند (rolled back). اگر اجاره‌ها ساختار معتبری داشته باشند اما عملیات برای یک یا چند مورد از آن‌ها با شکست مواجه شود، این اجاره‌ها در پاسخ فهرست می‌شوند؛ با این حال، تغییرات برای تمامی اجاره‌هایی که عملیات برای آن‌ها با موفقیت انجام شده است حفظ می‌گردد. پارامترهای "deleted-leases" و "leases" اختیاری هستند، اما تعیین حداقل یکی از آن‌ها الزامی است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 leases bulk apply completed.",
"arguments": {
"failed-deleted-leases": [
{
"ip-address": "2001:db8:abcd::",
"type": "IA_PD",
"result": <control result>,
"error-message": <error message>
}
],
"failed-leases": [
{
"ip-address": "2001:db8:cafe::",
"type": "IA_PD",
"result": <control result>,
"error-message": <error message>
}
]
}
}
168u
168u
فیلد "failed-deleted-leases" فهرستی از اجاره‌هایی را نگهداری می‌کند که حذف آن‌ها با شکست مواجه شده است؛ این بخش شامل اجاره‌هایی که در پایگاه داده پیدا نشده‌اند نیز می‌شود. فیلد "failed-leases" شامل فهرستی از اجاره‌هایی است که ایجاد یا به‌روزرسانی آن‌ها ناموفق بوده است. به ازای هر اجاره‌ای که در حین پردازش، درج در پایگاه داده و غیره دچار خطا شده باشد، مقدار result روی 1 تنظیم می‌شود. در صورتی که خطا به دلیل تعارض میان اجاره و پیکربندی یا وضعیت سرور رخ دهد، مقدار 4 به جای 1 بازگردانده می‌شود. به ازای هر اجاره‌ای که به دلیل نیافتن آن توسط سرور در پایگاه داده حذف نشده است، مقدار 3 بازگردانده می‌شود.
lease6-del
این دستور یک اجاره را از پایگاه داده اجاره‌ها حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه هوک lease_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-del را ببینید <#command-lease6-del>
نحو دستور:
0.0
3.5
{
"command": "lease6-del",
"arguments": {
"ip-address": "2001:db8::3"
}
}
168u
168u
دستور lease6-del نتیجه‌ای را بازمی‌گرداند که وضعیت حاصل از عملیات را نشان می‌دهد. این مقدار یکی از موارد زیر است: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی).
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار Result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور پایگاه‌دادهٔ اجاره‌ها را پرس‌وجو کرده و اجاره‌های موجود را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانهٔ قلاب lease_cmds)
دسترسی: read (پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-get را ببینید <#command-lease6-get>
نحو دستور:
0.0
3.5
{
"command": "lease6-get",
"arguments": {
"ip-address": "2001:db8:1234:ab::",
"type": "IA_PD"
}
}
168u
168u
دستور lease6-get نتیجه‌ای را بازمی‌گرداند که وضعیت عملیات و در صورت یافت شدن، جزئیات اجاره را مشخص می‌کند.
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"cltt": 1600439560,
"duid": "00:01:00:01:26:f7:81:88:00:0c:01:02:03:04",
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "foobar.example.org",
"hw-address": "00:0c:01:02:03:04",
"iaid": 1,
"ip-address": "2001:db8:1::",
"preferred-lft": 3000,
"state": 0,
"subnet-id": 1,
"type": "IA_NA",
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv6 lease(s) found."
}
168u
168u
نتیجهٔ 0 زمانی بازگردانده می‌شود که حداقل یک اجاره یافت شود، 1 زمانی که پارامترها نامعتبر یا مفقود باشند،
و 3 در صورتی بازگردانده می‌شود که هیچ اجاره‌ای با پارامتر مشخص‌شده یافت نشود.
lease6-get-all
این دستور تمام اجاره‌های IPv6 یا تمام اجاره‌های مربوط به مجموعه زیرشبکه‌های مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانهٔ قلاب lease_cmds)
دسترسی: read (پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-get-all را ببینید <#command-lease6-get-all>
نحو دستور:
0.0
3.5
{
"command": "lease6-get-all",
"arguments": {
"subnets": [ 1, 2, 3, 4 ]
}
}
168u
168u
دستور lease6-get-all ممکن است منجر به پاسخ‌های بسیار حجیم شود. لطفاً استفاده از
lease6-get-page را برای دریافت آن‌ها به صورت بخش‌بخش در نظر بگیرید. پارامتر subnets اختیاری است. اگر
مشخص نشود، اجاره‌های تمام زیرشبکه‌ها بازگردانده می‌شوند.
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"cltt": 12345678,
"duid": "42:42:42:42:42:42:42:42",
"fqdn-fwd": false,
"fqdn-rev": true,
"hostname": "myhost.example.com.",
"hw-address": "08:08:08:08:08:08",
"iaid": 1,
"ip-address": "2001:db8:2::1",
"preferred-lft": 500,
"state": 0,
"subnet-id": 44,
"type": "IA_NA",
"valid-lft": 3600
},
{
"cltt": 12345678,
"duid": "21:21:21:21:21:21:21:21",
"fqdn-fwd": false,
"fqdn-rev": true,
"hostname": "",
"iaid": 1,
"ip-address": "2001:db8:0:0:2::",
"preferred-lft": 500,
"prefix-len": 80,
"state": 0,
"subnet-id": 44,
"type": "IA_PD",
"valid-lft": 3600
}
]
},
"result": 0,
"text": "2 IPv6 lease(s) found."
}
168u
168u
نتیجهٔ 0 زمانی بازگردانده می‌شود که حداقل یک اجاره یافت شود، 1 زمانی که پارامترها نامعتبر یا مفقود باشند،
و 3 در صورتی بازگردانده می‌شود که هیچ اجاره‌ای با پارامتر مشخص‌شده یافت نشود..SS lease6-get-by-duid
این دستور تمام اجاره‌های IPv6 با DUID مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دسترس‌پذیری: 1.7.1 (کتابخانه هوک lease_cmds)
دسترسی: read (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-get-by-duid را ببینید <#command-lease6-get-by-duid>
ساختار دستور:
0.0
3.5
{
"command": "lease6-get-by-duid",
"arguments": {
"duid": "1a:1b:1c:1d:1e:1f:20:21:22:23:24"
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"cltt": 1600439560,
"duid": "00:01:00:01:26:f7:81:88:00:0c:01:02:03:04",
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "foobar.example.org",
"hw-address": "00:0c:01:02:03:04",
"iaid": 1,
"ip-address": "2001:db8:1::",
"preferred-lft": 3000,
"state": 0,
"subnet-id": 1,
"type": "IA_NA",
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv6 lease(s) found."
}
168u
168u
نتیجه 0 هنگامی بازگردانده می‌شود که دست‌کم یک اجاره پیدا شود، 1 هنگامی که پارامترها ناقص یا نادرست باشند،
و در صورتی که هیچ اجاره‌ای با پارامتر مشخص‌شده یافت نشود، 3 بازگردانده می‌شود.
lease6-get-by-hostname
این دستور تمام اجاره‌های IPv6 با hostname مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دسترس‌پذیری: 1.7.1 (کتابخانه هوک lease_cmds)
دسترسی: read (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-get-by-hostname را ببینید <#command-lease6-get-by-hostname>
ساختار دستور:
0.0
3.5
{
"command": "lease6-get-by-hostname",
"arguments": {
"hostname": "myhost.example.com."
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"cltt": 1600439560,
"duid": "00:01:00:01:26:f7:81:88:00:0c:01:02:03:04",
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "foobar.example.org",
"hw-address": "00:0c:01:02:03:04",
"iaid": 1,
"ip-address": "2001:db8:1::",
"preferred-lft": 3000,
"state": 0,
"subnet-id": 1,
"type": "IA_NA",
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv6 lease(s) found."
}
168u
168u
نتیجه 0 هنگامی بازگردانده می‌شود که دست‌کم یک اجاره پیدا شود، 1 هنگامی که پارامترها ناقص یا نادرست باشند،
و در صورتی که هیچ اجاره‌ای با پارامتر مشخص‌شده یافت نشود، 3 بازگردانده می‌شود..SS lease6-get-by-hw-address
این دستور تمامی اجاره‌های IPv6 با آدرس سخت‌افزاری مشخص‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 3.1.1 (کتابخانه قلاب lease_cmds)
سطح دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-get-by-hw-address را ببینید <#command-lease6-get-by-hw-address>
نحو دستور:
0.0
3.5
{
"command": "lease6-get-by-hw-address",
"arguments": {
"hw-address": "00:0c:01:02:03:04"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"cltt": 1600439560,
"duid": "00:01:00:01:26:f7:81:88:00:0c:01:02:03:04",
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "foobar.example.org",
"hw-address": "00:0c:01:02:03:04",
"iaid": 1,
"ip-address": "2001:db8:1::",
"preferred-lft": 3000,
"state": 0,
"subnet-id": 1,
"type": "IA_NA",
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv6 lease(s) found."
}
168u
168u
در صورت یافتن حداقل یک اجاره نتیجه 0، در صورت معیوب بودن یا مفقود بودن پارامترها 1،
و در صورت پیدا نشدن هیچ اجاره‌ای 3 بازگردانده می‌شود.
lease6-get-by-state
0.0
این دستور تمامی اجاره‌های IPv6 با وضعیت مشخص‌شده را بازیابی می‌کند
و به صورت اختیاری درون یک زیرشبکه.
168u
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 3.1.5 (کتابخانه قلاب lease_cmds)
سطح دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-get-by-state را ببینید <#command-lease6-get-by-state>
نحو دستور:
0.0
3.5
{
"command": "lease6-get-by-state",
"arguments": {
"state": "registered",
"subnet-id": 1
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"cltt": 1600439560,
"duid": "00:01:00:01:26:f7:81:88:00:0c:01:02:03:04",
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "00:0c:01:02:03:04",
"iaid": 1,
"ip-address": "2001:db8:1::",
"preferred-lft": 3000,
"state": 6,
"subnet-id": 1,
"type": "IA_NA",
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv6 lease(s) found."
}
168u
168u
در صورت یافتن حداقل یک اجاره نتیجه 0، در صورت معیوب بودن یا مفقود بودن پارامترها 1،
و در صورت پیدا نشدن هیچ اجاره‌ای با پارامتر مشخص‌شده 3 بازگردانده می‌شود..SS lease6-get-page
این فرمان تمام اجاره‌های IPv6 را به صورت صفحه‌بندی‌شده بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.5.0 (کتابخانه قلاب lease_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: فرمان lease6-get-page را ببینید <#command-lease6-get-page>
نحو فرمان:
0.0
3.5
{
"command": "lease6-get-page",
"arguments": {
"limit": <integer>,
"from": <IPv6 address or 'start'>
}
}
168u
168u
آدرس from و محدودیت اندازه صفحه (limit) الزامی هستند.
نحو پاسخ:
0.0
3.5
{
"arguments": {
"leases": [
{
"cltt": 1600439560,
"duid": "00:01:00:01:26:f7:81:88:00:0c:01:02:03:04",
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "foo.example.org",
"hw-address": "00:0c:01:02:03:04",
"iaid": 1,
"ip-address": "2001:db8:1::1",
"preferred-lft": 3000,
"state": 0,
"subnet-id": 1,
"type": "IA_NA",
"valid-lft": 4000
},
{
"cltt": 1600439570,
"duid": "00:01:00:01:26:f7:81:88:00:0c:01:02:03:05",
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "bar.example.org",
"hw-address": "00:0c:01:02:03:05",
"iaid": 1,
"ip-address": "2001:db8:1::2",
"preferred-lft": 3000,
"state": 0,
"subnet-id": 1,
"type": "IA_NA",
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv6 lease(s) found."
}
168u
168u
نتیجه 0 زمانی بازگردانده می‌شود که حداقل یک اجاره پیدا شود، 1 زمانی که پارامترها نامعتبر بوده یا وجود نداشته باشند، و 3 در صورتی که هیچ اجاره‌ای پیدا نشود بازگردانده می‌شود.
lease6-resend-ddns
این فرمان درخواستی را جهت به‌روزرسانی DNS برای یک اجاره موجود، مجدداً به kea-dhcp-ddns ارسال می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.7.6 (کتابخانه قلاب lease_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: فرمان lease6-resend-ddns را ببینید <#command-lease6-resend-ddns>
نحو فرمان:
0.0
3.5
{
"command": "lease6-resend-ddns",
"arguments": {
"ip-address": "2001:db8::1"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
},
"result": 0,
"text": "NCR generated for: 2001:db8::1, hostname: example.com."
}
168u
168u
فرمان lease6-resend-ddns نتیجه‌ای را بازمی‌گرداند که بیانگر وضعیت عملیات و در صورت یافت شدن، جزئیات اجاره است. این نتیجه یکی از مقادیر زیر را دارد: 0 (موفقیت)، 1 (خطا)، یا 3 (خالی)..SS lease6-update
این دستور اجاره‌های موجود را به‌روزرسانی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-update را ببینید <#command-lease6-update>
نحو دستور:
0.0
3.5
{
"command": "lease6-update",
"arguments": {
"ip-address": "2001:db8::1",
"duid": "88:88:88:88:88:88:88:88",
"iaid": 7654321,
"hostname": "newhostname.example.org",
"subnet-id": 66,
"force-create": false
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
اگر نتیجه بازگردانده‌شده برابر با 4 باشد، نشان می‌دهد که اجاره به دلیل تعارض با وضعیت سرور یا درک آن از پیکربندی، نتوانسته است به‌روزرسانی شود. کتابخانه قلاب High Availability می‌تواند با چنین نتیجه‌ای متفاوت از یک خطای عمومی رفتار کند. یک خطای عمومی 1 می‌تواند نشان‌دهنده مشکلاتی در پردازش دستور، در دسترس بودن پایگاه داده و غیره باشد.
lease6-wipe
این دستور تمام اجاره‌های مرتبط با یک زیرشبکه مشخص را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب lease_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-wipe را ببینید <#command-lease6-wipe>
نحو دستور:
0.0
3.5
{
"command": "lease6-wipe",
"arguments": {
"subnet-id": 66
}
}
168u
168u
نکته: همه backendها از این دستور پشتیبانی نمی‌کنند.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه، نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
lease6-write
این دستور پایگاه داده اجاره memfile مربوط به IPv6 را درون یک فایل CSV می‌نویسد.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 2.3.1 (کتابخانه قلاب lease_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور lease6-write را ببینید <#command-lease6-write>
نحو دستور:
0.0
3.5
{
"command": "lease6-write",
"arguments": {
"filename": "a_file.csv"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه، نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور به سرور اعلام می‌کند که تمامی اجاره‌های منقضی‌شده را فوراً بازپس گیرد.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
در دسترس بودن: 1.0.0 (توکار)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور leases-reclaim را ببینید <#command-leases-reclaim>
نحو دستور:
0.0
3.5
{
"command": "leases-reclaim",
"arguments": {
"remove": true
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
list-commands
این دستور فهرستی از تمام دستورات پشتیبانی‌شده توسط سرور را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns, kea-dhcp4, kea-dhcp6
در دسترس بودن: 1.0.0 (توکار)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور list-commands را ببینید <#command-list-commands>
نحو دستور:
0.0
3.5
{
"command": "list-commands",
"arguments": { }
}
168u
168u
سرور با فهرستی از تمام دستورات پشتیبانی‌شده پاسخ می‌دهد.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
network4-add
این دستور یک شبکه اشتراکی (shared network) جدید اضافه می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.3.0 (کتابخانه هوک subnet_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network4-add را ببینید <#command-network4-add>
نحو دستور:
0.0
3.5
{
"command": "network4-add",
"arguments": {
"shared-networks": [ {
"name": "floor13",
"subnet4": [
{
"id": 100,
"pools": [ { "pool": "192.0.2.2-192.0.2.99" } ],
"subnet": "192.0.2.0/24",
"option-data": [
{
"name": "routers",
"data": "192.0.2.1"
}
]
},
{
"id": 101,
"pools": [ { "pool": "192.0.3.2-192.0.3.99" } ],
"subnet": "192.0.3.0/24",
"option-data": [
{
"name": "routers",
"data": "192.0.3.1"
}
]
} ]
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"shared-networks": [ { "name": "floor13" } ]
},
"result": 0,
"text": "A new IPv4 shared network 'floor13' added"
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
این دستور شبکه‌های اشتراکی موجود را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network4-del را ببینید <#command-network4-del>
نحو دستور:
0.0
3.5
{
"command": "network4-del",
"arguments": {
"name": "floor13"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"command": "network4-del",
"arguments": {
"shared-networks": [
{
"name": "floor13"
}
]
},
"result": 0,
"text": "IPv4 shared network 'floor13' deleted"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده کنونی عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
network4-get
این دستور اطلاعات تفصیلی درباره شبکه‌های اشتراکی، از جمله زیرشبکه‌هایی که در حال حاضر بخشی از یک شبکه معین هستند را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: read (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network4-get را ببینید <#command-network4-get>
نحو دستور:
0.0
3.5
{
"command": "network4-get",
"arguments": {
"name": "floor13"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "Info about IPv4 shared network 'floor13' returned",
"arguments": {
"shared-networks": [
{
"match-client-id": true,
"name": "floor13",
"option-data": [ ],
"rebind-timer": 90,
"relay": {
"ip-address": "0.0.0.0"
},
"renew-timer": 60,
"subnet4": [
{
"subnet": "192.0.2.0/24",
"id": 5,
<many other subnet specific details here>
},
{
"subnet": "192.0.3.0/31",
"id": 6,
<many other subnet specific details here>
}
],
"valid-lifetime": 120
}
]
}
}
168u
168u
توجه داشته باشید که پاسخ واقعی شامل فیلدهای اضافی متعددی است که جهت شفافیت در اینجا حذف شده‌اند..SS network4-list
این دستور فهرست کامل شبکه‌های مشترک (shared networks) پیکربندی‌شده کنونی را دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس در: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network4-list را ببینید <#command-network4-list>
نحو دستور:
0.0
3.5
{
"command": "network4-list"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"shared-networks": [
{ "name": "floor1" },
{ "name": "office" }
]
},
"result": 0,
"text": "2 IPv4 network(s) found"
}
168u
168u
نتیجه یک مقدار عددی صحیح نشان‌دهنده وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا برگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
network4-subnet-add
این دستور زیرشبکه‌های موجود را به شبکه‌های مشترک موجود اضافه می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس در: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: نوشتن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network4-subnet-add را ببینید <#command-network4-subnet-add>
نحو دستور:
0.0
3.5
{
"command": "network4-subnet-add",
"arguments": {
"name": "floor13",
"id": 5
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet 10.0.0.0/8 (id 5) is now part of shared network 'floor1'"
}
168u
168u
نتیجه یک مقدار عددی صحیح نشان‌دهنده وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا برگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
network4-subnet-del
این دستور زیرشبکه‌ای را که بخشی از یک شبکه مشترک موجود است حذف کرده و آن را به یک زیرشبکه ساده و مستقل تنزل می‌دهد.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس در: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: نوشتن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network4-subnet-del را ببینید <#command-network4-subnet-del>
نحو دستور:
0.0
3.5
{
"command": "network4-subnet-del",
"arguments": {
"name": "floor13",
"id": 5
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet 10.0.0.0/8 (id 5) is now removed from shared network 'floor13'"
}
168u
168u
نتیجه یک مقدار عددی صحیح نشان‌دهنده وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا برگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
این دستور یک شبکه اشتراکی جدید اضافه می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دردسترس از: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network6-add را ببینید <#command-network6-add>
ساختار دستور:
0.0
3.5
{
"command": "network6-add",
"arguments": {
"shared-networks": [ {
"name": "floor13",
"subnet6": [
{
"id": 100,
"pools": [ { "pool": "2003:db8:1::1-2003:db8:1::ff" } ],
"subnet": "2003:db8:1::/64",
"option-data": [
{
"name": "dns-servers",
"data": "2005:db8:1::1"
}
]
},
{
"id": 101,
"pools": [ { "pool": "2003:db8:2::1-2003:db8:2::ff" } ],
"subnet": "2003:db8:2::/64",
"option-data": [
{
"name": "dns-servers",
"data": "2006:db8:1::1"
}
]
} ]
} ]
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"arguments": {
"shared-networks": [ { "name": "floor13" } ]
},
"result": 0,
"text": "A new IPv6 shared network 'floor13' added"
}
168u
168u
نتیجه (Result) نمایشی عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
network6-del
این دستور شبکه‌های اشتراکی موجود را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دردسترس از: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network6-del را ببینید <#command-network6-del>
ساختار دستور:
0.0
3.5
{
"command": "network6-del",
"arguments": {
"name": "floor13"
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"command": "network6-del",
"arguments": {
"shared-networks": [
{
"name": "floor13"
}
]
},
"result": 0,
"text": "IPv6 shared network 'floor13' deleted"
}
168u
168u
نتیجه (Result) نمایشی عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور اطلاعات دقیقی را درباره شبکه‌های اشتراکی (shared networks)، از جمله زیرشبکه‌هایی که در حال حاضر بخشی از یک شبکه مشخص هستند، بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network6-get را ببینید <#command-network6-get>
ساختار دستور:
0.0
3.5
{
"command": "network4-get",
"arguments": {
"name": "floor13"
}
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "Info about IPv6 shared network 'floor13' returned",
"arguments": {
"shared-networks": [
{
"match-client-id": true,
"name": "floor13",
"option-data": [ ],
"rebind-timer": 90,
"relay": {
"ip-address": "::"
},
"renew-timer": 60,
"subnet6": [
{
"subnet": "2003:db8:1::/64",
"id": 5,
<many other subnet specific details here>
},
{
"subnet": "2003:db8:2::/71",
"id": 6,
<many other subnet specific details here>
}
],
"valid-lifetime": 120
}
]
}
}
168u
168u
توجه داشته باشید که پاسخ واقعی شامل فیلدهای اضافی متعددی است که در اینجا برای وضوح بیشتر حذف شده‌اند.
network6-list
این دستور فهرست کامل شبکه‌های اشتراکی پیکربندی‌شده فعلی را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network6-list را ببینید <#command-network6-list>
ساختار دستور:
0.0
3.5
{
"command": "network6-list"
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"arguments": {
"shared-networks": [
{ "name": "floor1" },
{ "name": "office" }
]
},
"result": 0,
"text": "2 IPv6 network(s) found"
}
168u
168u
نتیجه (Result) نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده فعلی عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات درخواستی در پیکربندی را اعمال کند زیرا با وضعیت سرور تداخل داشت)
این دستور زیرشبکه‌های موجود را به شبکه‌های اشتراکی موجود اضافه می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network6-subnet-add را ببینید <#command-network6-subnet-add>
نحو دستور:
0.0
3.5
{
"command": "network6-subnet-add",
"arguments": {
"name": "floor13",
"id": 5
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet 2003:db8::/64 (id 5) is now part of shared network 'floor1'"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
network6-subnet-del
این دستور یک زیرشبکه را که بخشی از یک شبکهٔ اشتراکی موجود است حذف کرده و آن را به یک زیرشبکهٔ ساده و مستقل تنزل می‌دهد.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور network6-subnet-del را ببینید <#command-network6-subnet-del>
نحو دستور:
0.0
3.5
{
"command": "network6-subnet-del",
"arguments": {
"name": "floor13",
"id": 5
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet 2003:db8::/64 (id 5) is now removed from shared network 'floor13'"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
perfmon-control
این دستور پایش فعال و گزارش‌دهی آمار را فعال/غیرفعال می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 2.7.0 (کتابخانه قلاب perfmon)
دسترسی: write (پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور perfmon-control را ببینید <#command-perfmon-control>
نحو دستور:
0.0
3.5
{
"command": "perfmon-control",
"arguments": {
"enable-monitoring": true,
"stats-mgr-reporting": false
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"enable-monitoring": true,
"stats-mgr-reporting": false
},
"result": 0,
"text": "perfmon-control success."
}
168u
168u
در صورت موفقیت دستور، نتیجهٔ 0 همراه با مقادیر حاصل از هر دو پرچم بازگردانده می‌شود.
هنگامی که پارامترها ساختار نادرستی داشته یا مفقود باشند، نتیجه 1 است..SS perfmon-get-all-durations
این دستور تمام داده‌های مدت‌زمان پایش‌شده را که در حال حاضر توسط Perfmon نگهداری می‌شوند، واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 2.7.0 (کتابخانه هوک perfmon)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور perfmon-get-all-durations را ببینید <#command-perfmon-get-all-durations>
نحو دستور:
0.0
3.5
{
"command": "perfmon-get-all-durations",
"arguments": {
"result-set-format": true
}
}
168u
168u
نحو پاسخ:
0.0
3.5
اگر result-set-format برابر با false باشد، خروجی به صورت زیر خواهد بود:
{
"arguments": {
"durations": [{
"duration-key": {
"query-type": "DHCPDISCOVER",
"response-type": "DHCPOFFER",
"start-event": "buffer_read",
"stop-event": "mt_queued",
"subnet-id": 0
},
"max-duration-usecs": 118,
"mean-duration-usecs": 47,
"min-duration-usecs": 31,
"occurrences": 501,
"start-time": "2024-06-12 17:52:06.814884",
"total-duration-usecs": 23951
},
...
],
"result-set-format": false,
"interval-width-secs": 5,
"timestamp": "2024-06-12 17:52:22.397233"
},
"result": 0,
"text": "perfmon-get-all-durations: n found"
}
اگر result-set-format برابر با true باشد، خروجی به صورت زیر خواهد بود:
{
"arguments": {
"durations-result-set": {
"columns": [
"query-type",
"response-type",
"start-event",
"end-event",
"subnet-id",
"interval-start",
"occurrences",
"min-duration-usecs",
"max-duration-usecs",
"total-duration-usecs",
"mean-duration-usecs"
],
"rows": [
[
"DHCPDISCOVER",
"DHCPOFFER",
"buffer_read",
"mt_queued",
0,
"2024-06-12 17:52:06.814884",
501,
31,
118,
23951,
47
],
...
]
},
"result-set-format": true,
"interval-width-secs": 5,
"timestamp": "2024-06-12 17:52:22.397233"
},
"result": 0,
"text": "perfmon-get-all-durations: n found"
}
168u
168u
در صورت موفقیت‌آمیز بودن دستور، نتیجه 0 همراه با داده‌های مدت‌زمان پایش‌شده بازگردانده می‌شود.
اگر دستور نامعتبر باشد یا پردازش دستور با خطا مواجه شود، نتیجه 1 خواهد بود.
remote-class4-del
این دستور یک کلاس کلاینت DHCPv4 را از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.9.10 (کتابخانه هوک cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-class4-del را ببینید <#command-remote-class4-del>
نحو دستور:
0.0
3.5
{
"command": "remote-class4-del",
"arguments": {
"client-classes": [
{
"name": <client class name>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک نام از کلاس کلاینت مورد نظر برای حذف است. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv4 client class(es) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک کلاس کلاینت DHCPv4 انتخاب‌شده را بر اساس نام از پایگاه‌داده مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس از: 1.9.10 (کتابخانه هوک cb_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-class4-get را ببینید <#command-remote-class4-get>
نحو دستور:
0.0
3.5
{
"command": "remote-class4-get",
"arguments": {
"client-classes": [
{
"name": <client class name>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک نام از کلاس کلاینت برای بازگردانی است. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 client class found.",
"arguments": {
"client-classes": [
{
"name": <client class name>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the client class information>
}
],
"count": 1
}
}
168u
168u
ابرداده (metadata) در تعریف شبکه مشترک بازگردانده‌شده گنجانده شده است و اطلاعات مختص پایگاه‌داده مرتبط با شیء بازگردانده‌شده را ارائه می‌دهد.
remote-class4-get-all
این دستور تمام کلاس‌های کلاینت DHCPv4 را برای سرورهای مشخص‌شده از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس از: 1.9.10 (کتابخانه هوک cb_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-class4-get-all را ببینید <#command-remote-class4-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-class4-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست server-tags برای این دستور الزامی است و نباید خالی باشد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 DHCPv4 client class(es) found.",
"arguments": {
"client-classes": [
{
<first client class specification>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
},
{
<second client class specification>,
"metadata": {
"server-tags": [ <first server tag>, ... ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها (maps) است. هر نگاشت شامل یک نام کلاس کلاینت و ابرداده (metadata) است که اطلاعات مختص پایگاه‌داده مرتبط با کلاس کلاینت را ارائه می‌دهد..SS remote-class4-set
این دستور یک کلاس کلاینت DHCPv4 را در پایگاه‌داده پیکربندی ایجاد کرده یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.9.10 (کتابخانه هوک cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-class4-set را ببینید <#command-remote-class4-set>
نحو دستور:
0.0
3.5
{
"command": "remote-class4-set",
"arguments": {
"client-class": [
{
<client class specification>,
"follow-class-name": <existing class name>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل مشخصات یک کلاس کلاینت باشد. این فهرست می‌تواند حاوی پارامتر اختیاری "follow-class-name" باشد که می‌تواند نام یک کلاس موجود را مشخص کند تا نشان دهد کلاسی که از دستور آمده است، در سلسله‌مراتب دقیقاً پس از این کلاس موجود قرار می‌گیرد. این پارامتر می‌تواند حذف شود یا روی "null" تنظیم گردد تا مشخص کند کلاس کلاینت جدید باید به انتهای سلسله‌مراتب افزوده شود یا کلاس به‌روزشده در موقعیت فعلی خود باقی بماند. فهرست server-tags الزامی است و باید شامل یک یا چند برچسب سرور به‌صورت رشته باشد تا کلاس کلاینت را صراحتاً به یک یا چند سرور تعریف‌شده توسط کاربر مرتبط کند. این فهرست می‌تواند شامل برچسب سرور ویژه "all" باشد تا کلاس را با تمام سرورها مرتبط سازد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 shared network successfully set.",
"arguments": {
"client-classes": [
{
"name": <set client class name>
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت تکمیل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند، زیرا با وضعیت سرور در تعارض بودند)
168u
remote-class6-del
این دستور یک کلاس کلاینت DHCPv6 را از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.9.10 (کتابخانه هوک cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-class6-del را ببینید <#command-remote-class6-del>
نحو دستور:
0.0
3.5
{
"command": "remote-class6-del",
"arguments": {
"client-classes": [
{
"name": <client class name>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک نام از کلاس کلاینتی است که باید حذف شود. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 client class(es) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت تکمیل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند، زیرا با وضعیت سرور در تعارض بودند)
این فرمان یک کلاس کلاینت DHCPv6 انتخاب‌شده را بر اساس نام از پایگاه‌داده مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.9.10 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به فرمان remote-class6-get رجوع کنید <#command-remote-class6-get>
نحو فرمان:
0.0
3.5
{
"command": "remote-class6-get",
"arguments": {
"client-classes": [
{
"name": <client class name>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این فرمان شامل فهرستی است که دقیقاً یک نام از کلاس کلاینت مورد نظر برای بازگردانی را در بر دارد. پارامتر server-tags نباید برای این فرمان مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 client class found.",
"arguments": {
"client-classes": [
{
"name": <client class name>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the client class information>
}
],
"count": 1
}
}
168u
168u
متاداده در تعریف شبکه اشتراکی بازگردانده‌شده گنجانده می‌شود و اطلاعات مختص پایگاه‌داده مرتبط با شیء بازگردانده‌شده را ارائه می‌دهد.
remote-class6-get-all
این فرمان تمام کلاس‌های کلاینت DHCPv6 را برای کارگزارهای مشخص‌شده از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.9.10 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به فرمان remote-class6-get-all رجوع کنید <#command-remote-class6-get-all>
نحو فرمان:
0.0
3.5
{
"command": "remote-class6-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست server-tags برای این فرمان الزامی است و نباید خالی باشد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 DHCPv6 client class(es) found.",
"arguments": {
"client-classes": [
{
<first client class specification>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
},
{
<second client class specification>,
"metadata": {
"server-tags": [ <first server tag>, ... ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده حاوی فهرستی از نگاشت‌ها است. هر نگاشت شامل نام یک کلاس کلاینت و متاداده است، که اطلاعات مختص پایگاه‌داده مربوط به کلاس کلاینت را ارائه می‌دهد..SS remote-class6-set
این دستور یک کلاس کلاینت DHCPv6 را در پایگاه‌داده پیکربندی ایجاد کرده یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.9.10 (کتابخانه قلاب cb_cmds)
سطح دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-class6-set را ببینید <#command-remote-class6-set>
نحو دستور:
0.0
3.5
{
"command": "remote-class6-set",
"arguments": {
"client-class": [
{
<client class specification>,
"follow-class-name": <existing class name>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل یک مشخصه کلاس کلاینت باشد. این فهرست می‌تواند شامل پارامتر اختیاری "follow-class-name" باشد که می‌تواند نام یک کلاس موجود را مشخص کند تا نشان دهد کلاس ارائه‌شده در این دستور، دقیقاً پس از این کلاسِ موجود در سلسله‌مراتب قرار می‌گیرد. این پارامتر می‌تواند حذف شود یا روی "null" تنظیم گردد تا نشان دهد کلاس کلاینت جدید باید به انتهای سلسله‌مراتب اضافه شود یا کلاس به‌روزرسانی‌شده در موقعیت فعلی خود باقی بماند. فهرست server-tags اجباری است و باید شامل یک یا چند برچسب کارساز به‌صورت رشته باشد تا کلاس کلاینت را به‌طور صریح به یک یا چند کارساز تعریف‌شده توسط کاربر مرتبط کند. این فهرست می‌تواند شامل برچسب کارساز ویژه "all" باشد تا کلاس را به تمام کارسازها مرتبط سازد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 shared network successfully set.",
"arguments": {
"client-classes": [
{
"name": <set client class name>
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
168u
remote-global-parameter4-del
این دستور یک پارامتر سراسری DHCPv4 را از پایگاه‌داده پیکربندی حذف می‌کند. کارساز پس از حذف پارامتر از پایگاه‌داده، از مقدار مشخص‌شده در فایل پیکربندی یا در صورت مشخص نبودن پارامتر، از یک مقدار پیش‌فرض استفاده می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس از: 1.6.0 (کتابخانه قلاب cb_cmds)
سطح دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-global-parameter4-del را ببینید <#command-remote-global-parameter4-del>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter4-del",
"arguments": {
"parameters": [ <parameter name as string> ],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور فهرستی شامل دقیقاً یک نام از پارامتری که باید حذف شود را در بر دارد. در صورت حذف یک پارامتر نگاشت (map)، باید از قالب map-name.parameter-name استفاده شود. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب کارساز باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب کارساز منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 global parameter(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
این دستور پارامتر سراسری (global parameter) انتخاب‌شده برای سرور را از پایگاه داده مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور remote-global-parameter4-get مراجعه کنید <#command-remote-global-parameter4-get>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter4-get",
"arguments": {
"parameters": [ <parameter name as string> ],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور شامل فهرستی است که دقیقاً نام یک پارامتر را جهت واکشی دربردارد. در صورت بازیابی یک پارامتر نگاشت (map)، باید از قالب map-name.parameter-name استفاده شود. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور (server tag) باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چند برچسب سرور منجر به خطا خواهد شد. برچسب سرور "all" مجاز است؛ این برچسب مقدار پارامتر سراسری مشترک بین همه سرورها را واکشی می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 global parameter found.",
"arguments": {
"parameters": {
<parameter name>: <parameter value>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
"count": 1
}
}
168u
168u
پاسخ بازگردانده‌شده شامل یک نگاشت با یک جفت نام:مقدار پارامتر سراسری است. مقدار ممکن است یک رشته JSON، عدد صحیح (integer)، عدد حقیقی (real)، بولی (boolean)، فهرستی از این نوع‌های اسکالر یا نگاشتی باشد که تنها شامل یکی از این نوع‌های اسکالر است. متادیتا (metadata) گنجانده شده و اطلاعات خاص پایگاه داده مرتبط با شیء بازگردانده‌شده را ارائه می‌دهد. اگر برچسب سرور "all" مشخص شود، دستور تلاش می‌کند مقدار پارامتر سراسری مرتبط با همه سرورها را واکشی کند. اگر برچسب سرور صریح مشخص شود، دستور مقدار مرتبط با سرور ارائه‌شده را واکشی می‌کند. اگر مقدار مختص سرور وجود نداشته باشد، دستور remote-global-parameter4-get مقدار مرتبط با همه سرورها را واکشی خواهد کرد.
remote-global-parameter4-get-all
این دستور تمام پارامترهای سراسری برای سرور را از پایگاه داده مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور remote-global-parameter4-get-all مراجعه کنید <#command-remote-global-parameter4-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter4-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چند برچسب سرور منجر به خطا خواهد شد. برچسب سرور ویژه "all" مجاز است؛ این برچسب پارامترهای سراسری مشترک بین همه سرورها را واکشی می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 global parameters found.",
"arguments": {
"parameters": [
{
<first parameter name>: <first parameter value>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
{
<second parameter name>: <second parameter value>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها است. هر نگاشت شامل یک جفت نام:مقدار پارامتر سراسری است. مقدار ممکن است یک رشته JSON، عدد صحیح، عدد حقیقی، بولی، فهرستی از این نوع‌های اسکالر یا نگاشتی باشد که تنها شامل یکی از این نوع‌های اسکالر است. متادیتا به هر پارامتر پیوست شده و اطلاعات خاص پایگاه داده مرتبط با اشیاء بازگردانده‌شده را فراهم می‌کند. اگر برچسب سرور "all" در دستور گنجانده شده باشد، پاسخ حاوی پارامترهای سراسری به اشتراک گذاشته‌شده میان همه سرورها خواهد بود و پارامترهای سراسری مختص سرور را مستثنی می‌کند. اگر یک برچسب سرور صریح در دستور گنجانده شده باشد، پاسخ شامل همه پارامترهای سراسری است که مستقیماً با سرور داده‌شده مرتبط هستند و در صورت عدم وجود مقادیر مختص سرور، شامل پارامترهای سراسری مرتبط با همه سرورها خواهد بود.
remote-global-parameter4-set
این دستور یک یا چند پارامتر سراسری را در پایگاه داده پیکربندی ایجاد یا به‌روزرسانی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: نوشتن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور remote-global-parameter4-set مراجعه کنید <#command-remote-global-parameter4-set>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter4-set",
"arguments": {
"parameters": {
<first parameter name>: <first parameter value>,
<second parameter name>: <second parameter value>
},
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور حامل چندین پارامتر سراسری به همراه مقادیر آن‌ها (شامل فهرست‌ها یا نگاشت‌ها با پارامترهای اسکالر) است. هنگام تعیین بیش از یک پارامتر باید احتیاط کرد؛ در برخی موارد، ممکن است تنها زیرمجموعه‌ای از پارامترها با موفقیت در پایگاه داده ذخیره شوند و ذخیره سایر پارامترها با شکست مواجه شود. در چنین مواردی، ممکن است دستور remote-global-parameter4-get-all برای تأیید محتویات پایگاه داده پس از به‌روزرسانی مفید باشد. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چند برچسب سرور منجر به خطا خواهد شد. برچسب سرور "all" مجاز است؛ این برچسب پارامترهای مشخص‌شده را به همه سرورها مرتبط می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 global parameter(s) successfully set.",
"arguments": {
"parameters": {
<first parameter name>: <first parameter value>,
<second parameter name>: <second parameter value>
},
"count": 2
}
}
168u
168u
نتیجه (result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت تکمیل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد) (empty)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور تداخل داشت) (conflict)
این دستور یک پارامتر سراسری DHCPv6 را از پایگاه‌داده پیکربندی حذف می‌کند. کارساز پس از حذف پارامتر از پایگاه‌داده، از مقدار مشخص‌شده در فایل پیکربندی یا در صورت مشخص نبودن پارامتر در فایل پیکربندی، از یک مقدار پیش‌فرض استفاده می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-global-parameter6-del را ببینید <#command-remote-global-parameter6-del>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter6-del",
"arguments": {
"parameters": [ <parameter name as string> ],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور حامل فهرستی است که دقیقاً نام یک پارامتر را برای حذف شدن در بر دارد. در صورت حذف یک پارامتر نگاشت، باید از قالب map-name.parameter-name استفاده شود. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب کارساز باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب کارساز منجر به بروز خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 global parameter(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده کنونی عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تداخل بود)
168u
remote-global-parameter6-get
این دستور پارامتر سراسری انتخاب‌شده را برای کارساز از پایگاه‌داده مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-global-parameter6-get را ببینید <#command-remote-global-parameter6-get>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter6-get",
"arguments": {
"parameters": [ <parameter name as string> ],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور حامل فهرستی است که دقیقاً نام یک پارامتر را جهت واکشی در بر دارد. در صورت بازیابی یک پارامتر نگاشت، باید از قالب map-name.parameter-name استفاده شود. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب کارساز باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب کارساز منجر به بروز خطا خواهد شد. برچسب کارساز "all" مجاز است؛ این برچسب مقدار پارامتر سراسری مشترک بین همه کارسازها را واکشی می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 global parameter found.",
"arguments": {
"parameters": {
<parameter name>: <parameter value>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
"count": 1
}
}
168u
168u
پاسخ بازگردانده‌شده شامل یک نگاشت با یک جفت نام:مقدار پارامتر سراسری است. این مقدار می‌تواند یک رشته JSON، عدد صحیح، عدد حقیقی، بولی، فهرستی از این نوع‌های اسکالر یا نگاشتی باشد که تنها شامل یکی از این نوع‌های اسکالر است. فراداده گنجانده شده و اطلاعات مخصوص پایگاه‌داده مرتبط با شیء بازگردانده‌شده را فراهم می‌کند. اگر برچسب کارساز "all" مشخص شده باشد، دستور تلاش می‌کند مقدار پارامتر سراسری مرتبط با همه کارسازها را واکشی کند. اگر برچسب کارساز مشخصی تعیین شده باشد، دستور مقدار مرتبط با همان کارساز را واکشی می‌کند. اگر مقدار ویژه‌ی کارساز وجود نداشته باشد، remote-global-parameter6-get مقدار مرتبط با همه کارسازها را واکشی می‌نماید.
remote-global-parameter6-get-all
این دستور تمام پارامترهای سراسری را برای کارساز از پایگاه‌داده مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-global-parameter6-get-all را ببینید <#command-remote-global-parameter6-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter6-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب کارساز باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب کارساز منجر به بروز خطا خواهد شد. برچسب کارساز ویژه "all" مجاز است؛ این برچسب پارامترهای سراسری مشترک بین همه کارسازها را واکشی می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 global parameters found.",
"arguments": {
"parameters": [
{
<first parameter name>: <first parameter value>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
{
<second parameter name>: <second parameter value>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها است. هر نگاشت حاوی یک جفت نام:مقدار از پارامتر سراسری است. این مقدار می‌تواند یک رشته JSON، عدد صحیح، عدد حقیقی، بولی، فهرستی از این نوع‌های اسکالر یا نگاشتی باشد که تنها شامل یکی از این نوع‌های اسکالر است. فراداده به هر پارامتر پیوست شده و اطلاعات مخصوص پایگاه‌داده مرتبط با اشیاء بازگردانده‌شده را فراهم می‌کند. اگر برچسب کارساز "all" در دستور گنجانده شده باشد، پاسخ حاوی پارامترهای سراسری مشترک میان همه کارسازها خواهد بود و پارامترهای سراسری مختص کارساز را مستثنی می‌کند. اگر یک برچسب کارساز مشخص در دستور گنجانده شده باشد، پاسخ شامل تمامی پارامترهای سراسری است که مستقیماً با کارساز داده‌شده مرتبط هستند، و در صورتی که مقادیر مختص به کارساز وجود نداشته باشند، پارامترهای سراسری مرتبط با همه کارسازها را نیز شامل می‌شود..SS remote-global-parameter6-set
این دستور یک یا چند پارامتر سراسری را در پایگاه‌داده پیکربندی ایجاد یا به‌روزرسانی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس در: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-global-parameter6-set را ببینید <#command-remote-global-parameter6-set>
نحو دستور:
0.0
3.5
{
"command": "remote-global-parameter6-set",
"arguments": {
"parameters": {
<first parameter name>: <first parameter value>,
<second parameter name>: <second parameter value>
},
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور حامل چندین پارامتر سراسری به همراه مقادیر آن‌ها است (از جمله فهرست‌ها یا نگاشت‌هایی با پارامترهای اسکالر). در هنگام مشخص کردن بیش از یک پارامتر باید دقت شود؛ در برخی موارد، ممکن است تنها زیرمجموعه‌ای از پارامترها با موفقیت در پایگاه‌داده ذخیره شوند و ذخیره سایر پارامترها با شکست مواجه گردد. در چنین مواردی دستور remote-global-parameter6-get-all ممکن است برای تأیید محتوای پایگاه‌داده پس از به‌روزرسانی مفید باشد. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چندین برچسب سرور منجر به خطا خواهد شد. برچسب سرور "all" مجاز است؛ این برچسب پارامترهای مشخص‌شده را به تمام سرورها مرتبط می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 global parameter(s) successfully set.",
"arguments": {
"parameters": {
<first parameter name>: <first parameter value>,
<second parameter name>: <second parameter value>
},
"count": 2
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
remote-network4-del
این دستور یک شبکه مشترک IPv4 را از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس در: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-network4-del را ببینید <#command-remote-network4-del>
نحو دستور:
0.0
3.5
{
"command": "remote-network4-del",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"subnets-action": <'keep' | 'delete'>,
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک نام از شبکه مشترک برای حذف است. پارامتر subnets-action مشخص می‌کند که آیا زیرشبکه‌ها در این شبکه مشترک باید حذف شوند یا خیر. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 IPv4 shared network(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
این دستور شبکهٔ اشتراکی IPv4 انتخاب‌شده برای سرور را از پایگاه‌دادهٔ مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
سطح دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-network4-get را ببینید <#command-remote-network4-get>
نحو دستور:
0.0
3.5
{
"command": "remote-network4-get",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"subnets-include": <'full' | 'no'>,
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک نام از شبکهٔ اشتراکی برای بازگردانده شدن است. پارامتر اختیاری subnets-include امکان تعیین این را فراهم می‌کند که آیا زیرشبکه‌های متعلق به شبکهٔ اشتراکی نیز باید بازگردانده شوند یا خیر. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 shared network found.",
"arguments": {
"shared-networks": [
{
"name": <shared network name>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the shared network information, potentially including subnets>
}
],
"count": 1
}
}
168u
168u
اگر زیرشبکه‌ها به همراه شبکهٔ اشتراکی بازگردانده شوند، در فهرست subnet4 درون تعریف شبکهٔ اشتراکی قرار می‌گیرند. فراداده در تعریف بازگردانده‌شدهٔ شبکهٔ اشتراکی گنجانده شده و اطلاعات خاص پایگاه‌دادهٔ مرتبط با شیءِ بازگردانده‌شده را فراهم می‌کند.
remote-network4-list
این دستور فهرستی از تمام شبکه‌های اشتراکی IPv4 را از پایگاه‌دادهٔ پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
سطح دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-network4-list را ببینید <#command-remote-network4-list>
نحو دستور:
0.0
3.5
{
"command": "remote-network4-list",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست server-tags برای این دستور الزامی است و نباید خالی باشد. این فهرست می‌تواند شامل یک یا چند برچسب سرور به‌صورت رشته، یا یک مقدار تکی null باشد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 IPv4 shared network(s) found.",
"arguments": {
"shared-networks": [
{
"name": <first shared network name>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
},
{
"name": <second shared network name>,
"metadata": {
"server-tags": [ <first server tag>, ... ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها (maps) است. هر نگاشت شامل نام شبکهٔ اشتراکی و فراداده است که اطلاعات خاص پایگاه‌دادهٔ مرتبط با شبکهٔ اشتراکی را فراهم می‌کند. فهرست بازگردانده‌شده شامل تعاریف کامل شبکه‌های اشتراکی نیست؛ برای واکشی اطلاعات کامل دربارهٔ شبکه‌های اشتراکی انتخاب‌شده از remote-network4-get استفاده کنید. اگر دستور شامل برچسب‌های صریح سرور به‌صورت رشته باشد (از جمله برچسب سرور ویژهٔ "all")، فهرست شامل تمام شبکه‌های اشتراکی خواهد بود که با هر یک از برچسب‌های مشخص‌شده مرتبط هستند. یک شبکه حتی در صورتی که با چندین سرور مرتبط باشد و تنها یکی از برچسب‌های مشخص‌شده مطابقت داشته باشد نیز بازگردانده می‌شود. اگر دستور شامل مقدار null در فهرست server-tags باشد، پاسخ شامل تمام شبکه‌های اشتراکی خواهد بود که به هیچ سروری تخصیص داده نشده‌اند (تخصیص‌نیافته)..SS remote-network4-set
این دستور یک شبکه اشتراکی IPv4 را در پایگاه‌داده پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور remote-network4-set مراجعه کنید <#command-remote-network4-set>
نحو دستور:
0.0
3.5
{
"command": "remote-network4-set",
"arguments": {
"shared-networks": [
{
<shared network specification excluding subnets list>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل مشخصات یک شبکه اشتراکی باشد و نباید شامل زیرشبکه‌ها (پارامتر "subnet4") باشد. زیرشبکه‌ها با استفاده از دستور remote-subnet4-set به شبکه اشتراکی اضافه می‌شوند. فهرست server-tags اجباری است و باید شامل یک یا چند برچسب سرور به‌صورت رشته باشد تا شبکه اشتراکی را به‌طور صریح با یک یا چند سرور تعریف‌شده توسط کاربر مرتبط سازد. این فهرست می‌تواند شامل برچسب سرور ویژه "all" باشد تا شبکه را با تمام سرورها مرتبط کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 shared network successfully set."
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-network6-del
این دستور یک شبکه اشتراکی IPv6 را از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور remote-network6-del مراجعه کنید <#command-remote-network6-del>
نحو دستور:
0.0
3.5
{
"command": "remote-network6-del",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"subnets-action": <'keep' | 'delete'>,
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک نام از شبکه اشتراکی مورد نظر برای حذف است. پارامتر subnets-action مشخص می‌کند که آیا زیرشبکه‌های موجود در این شبکه اشتراکی باید حذف شوند یا خیر. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 IPv6 shared network(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور شبکهٔ اشتراکی IPv6 انتخاب‌شده را برای سرور از پایگاه‌دادهٔ مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: read (پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-network6-get را ببینید <#command-remote-network6-get>
نحو دستور:
0.0
3.5
{
"command": "remote-network6-get",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"subnets-include": <'full' | 'no'>,
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک نام از شبکهٔ اشتراکی برای بازگردانی است. پارامتر اختیاری subnets-include امکان مشخص کردن این موضوع را فراهم می‌کند که آیا زیرشبکه‌های متعلق به شبکهٔ اشتراکی نیز باید بازگردانده شوند یا خیر. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 shared network found.",
"arguments": {
"shared-networks": [
{
"name": <shared network name>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the shared network information, potentially including subnets>
}
],
"count": 1
}
}
168u
168u
اگر زیرشبکه‌ها به همراه شبکهٔ اشتراکی بازگردانده شوند، درون فهرست subnet6 در تعریف شبکهٔ اشتراکی منتقل می‌شوند. فراداده (metadata) در تعریف شبکهٔ اشتراکی بازگردانده‌شده گنجانده شده و اطلاعات خاص پایگاه‌دادهٔ مرتبط با شیء بازگردانده‌شده را فراهم می‌کند.
remote-network6-list
این دستور فهرستی از تمام شبکه‌های اشتراکی IPv6 را از پایگاه‌دادهٔ پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: read (پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-network6-list را ببینید <#command-remote-network6-list>
نحو دستور:
0.0
3.5
{
"command": "remote-network6-list",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست server-tags برای این دستور الزامی است و نباید خالی باشد. این فهرست می‌تواند شامل یک یا چند برچسب سرور به‌صورت رشته، یا یک مقدار تکی null باشد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 IPv6 shared network(s) found.",
"arguments": {
"shared-networks": [
{
"name": <first shared network name>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
},
{
"name": <second shared network name>,
"metadata": {
"server-tags": [ <first server tag>, ... ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده حاوی فهرستی از نگاشت‌ها است. هر نگاشت شامل نام شبکهٔ اشتراکی و فراداده (metadata) است که اطلاعات خاص پایگاه‌دادهٔ مرتبط با شبکهٔ اشتراکی را فراهم می‌کند. فهرست بازگردانده‌شده شامل تعاریف کامل شبکه‌های اشتراکی نیست؛ از remote-network6-get برای واکشی اطلاعات کامل دربارهٔ شبکه‌های اشتراکی انتخاب‌شده استفاده کنید. اگر دستور شامل برچسب‌های صریح سرور به‌صورت رشته باشد (از جمله برچسب ویژهٔ سرور "all")، فهرست حاوی تمام شبکه‌های اشتراکی خواهد بود که با هر یک از برچسب‌های مشخص‌شده مرتبط هستند. یک شبکه حتی در صورتی که با چندین سرور مرتبط باشد و تنها یکی از برچسب‌های مشخص‌شده با آن مطابقت داشته باشد بازگردانده می‌شود. اگر دستور حاوی مقدار null در فهرست server-tags باشد، پاسخ شامل تمام شبکه‌های اشتراکی خواهد بود که به هیچ سروری تخصیص نیافته‌اند (تخصیص‌نیافته)..SS remote-network6-set
این دستور یک شبکهٔ اشتراکی IPv6 را در پایگاه‌دادهٔ پیکربندی ایجاد کرده یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس در: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-network6-set را ببینید <#command-remote-network6-set>
ساختار دستور:
0.0
3.5
{
"command": "remote-network6-set",
"arguments": {
"shared-networks": [
{
<shared network specification excluding subnets list>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل مشخصات یک شبکهٔ اشتراکی باشد و نباید شامل زیرشبکه‌ها (پارامتر "subnet6") باشد. زیرشبکه‌ها با استفاده از دستور remote-subnet6-set به شبکهٔ اشتراکی اضافه می‌شوند. فهرست server-tags اجباری است و باید شامل یک یا چند برچسب سرور به‌صورت رشته باشد تا شبکهٔ اشتراکی را به‌طور صریح با یک یا چند سرور تعریف‌شده توسط کاربر مرتبط سازد. این فهرست می‌تواند شامل برچسب سرور ویژهٔ "all" برای مرتبط کردن شبکه با همهٔ سرورها باشد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 shared network successfully set."
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-option-def4-del
این دستور یک تعریف گزینهٔ DHCPv4 را از پایگاه‌دادهٔ پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس در: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option-def4-del را ببینید <#command-remote-option-def4-del>
ساختار دستور:
0.0
3.5
{
"command": "remote-option-def4-del",
"arguments": {
"option-defs": [ {
"code": <option code>,
"space": <option space>,
"force": false
} ],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور شامل فهرستی با مشخصات دقیقاً یک تعریف گزینه است که شامل نام و کد گزینه می‌شود. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. تعیین یک فهرست خالی، مقدار null، یا چندین برچسب سرور منجر به خطا خواهد شد. از نسخهٔ 3.1.2 نرم‌افزار Kea، سرور پیش از حذف یک تعریف گزینه، ابتدا بررسی می‌کند که آیا گزینه‌ای تعریف شده که به آن تعریف وابسته باشد یا خیر. در این صورت، دستور حذف با پیامی خطا که علت را توضیح می‌دهد رد خواهد شد. این رفتار پیش‌فرض را می‌توان با تنظیم پارامتر اختیاری force بر روی true لغو کرد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv4 option definition(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک تعریف گزینه DHCPv4 را از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور remote-option-def4-get مراجعه کنید <#command-remote-option-def4-get>
نحو دستور:
0.0
3.5
{
"command": "remote-option-def4-get",
"arguments": {
"option-defs": [
{
"code": <option code>,
"space": <option space>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
تعریف گزینه مورد نظر با جفت مقادیر code/space گزینه مشخص می‌شود. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب سرور منجر به بروز خطا می‌شود. برچسب سرور "all" برای واکشی نمونه تعریف گزینه به‌اشتراک‌گذاشته‌شده میان همه سرورها مجاز است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 option definition found.",
"arguments": {
"option-defs": [
{
<option definition>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 1
}
}
168u
168u
فراداده (metadata) گنجانده شده است و اطلاعات ویژه پایگاه‌داده مرتبط با شیء بازگردانده‌شده را ارائه می‌دهد. اگر برچسب سرور "all" مشخص شود، دستور تلاش می‌کند تعریف گزینه مرتبط با همه سرورها را واکشی کند. اگر برچسب صریح سرور مشخص شود، دستور تعریف گزینه مرتبط با سرور داده‌شده را واکشی می‌کند. اگر تعریف گزینه مختص سرور وجود نداشته باشد، دستور remote-option-def4-get تعریف گزینه مرتبط با همه سرورها را واکشی می‌کند.
remote-option-def4-get-all
این دستور همه تعاریف گزینه‌های DHCPv4 را از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور remote-option-def4-get-all مراجعه کنید <#command-remote-option-def4-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-option-def4-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب سرور منجر به بروز خطا خواهد شد. برچسب سرور ویژه "all" برای واکشی تعاریف گزینه‌های به‌اشتراک‌گذاشته‌شده توسط همه سرورها مجاز است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 DHCPv4 option definition(s) found.",
"arguments": {
"option-defs": [
{
<first option definition>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
{
<second option definition>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها است. هر نگاشت شامل مشخصات تعریف گزینه و فراداده (metadata)، از جمله اطلاعات ویژه پایگاه‌داده مرتبط با اشیاء بازگردانده‌شده است. اگر برچسب سرور "all" در دستور گنجانده شود، پاسخ حاوی تعاریف گزینه‌های به‌اشتراک‌گذاشته‌شده میان همه سرورها خواهد بود و تعاریف گزینه مختص سرور را مستثنی می‌کند. اگر یک برچسب سرور صریح در دستور گنجانده شود، پاسخ حاوی تمامی تعاریف گزینه‌های مستقیماً مرتبط با سرور داده‌شده و همچنین در صورت عدم وجود تعاریف گزینه مختص سرور، تعاریف گزینه مرتبط با همه سرورها خواهد بود..SS remote-option-def4-set
این دستور یک تعریف گزینهٔ DHCPv4 را در پایگاه‌دادهٔ پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option-def4-set را ببینید <#command-remote-option-def4-set>
ساختار دستوری:
0.0
3.5
{
"command": "remote-option-def4-set",
"arguments": {
"option-defs": [
{
<option definition specification>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل یک مشخصهٔ تعریف گزینه باشد. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب سرور منجر به خطا خواهد شد. برچسب سرور "all" مجاز است؛ این برچسب، تعریف گزینهٔ مشخص‌شده را به تمام سرورها مرتبط می‌کند.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 option definition set."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شدهٔ فعلی عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
remote-option-def6-del
این دستور یک تعریف گزینهٔ DHCPv6 را از پایگاه‌دادهٔ پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option-def6-del را ببینید <#command-remote-option-def6-del>
ساختار دستوری:
0.0
3.5
{
"command": "remote-option-def6-del",
"arguments": {
"option-defs": [ {
"code": <option code>,
"space": <option space>,
"force": false
} ],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک مشخصهٔ تعریف گزینه، متشکل از یک نام و کد گزینه است. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب سرور منجر به خطا خواهد شد. از نسخهٔ Kea 3.1.2، سرور پیش از حذف یک تعریف گزینه، ابتدا بررسی می‌کند که آیا گزینه‌ای مشخص شده است که به آن تعریف وابسته باشد یا خیر. در این صورت، دستور حذف با یک پیام خطا که علت را توضیح می‌دهد رد خواهد شد. این رفتار پیش‌فرض می‌تواند با تنظیم پارامتر اختیاری force روی true لغو شود.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 option definition(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شدهٔ فعلی عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور یک تعریف گزینهٔ DHCPv6 را از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option-def6-get را ببینید <#command-remote-option-def6-get>
نحو دستور:
0.0
3.5
{
"command": "remote-option-def6-get",
"arguments": {
"option-defs": [
{
"code": <option code>,
"space": <option space>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
تعریف گزینهٔ مورد نظر توسط جفت مقادیر code/space گزینه شناسایی می‌شود. فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چندین برچسب سرور منجر به خطا خواهد شد. برچسب سرور "all" برای واکشی نمونه تعریف گزینهٔ به‌اشتراک‌گذاشته‌شده توسط تمام سرورها مجاز است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option definition found.",
"arguments": {
"option-defs": [
{
<option definition>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 1
}
}
168u
168u
متادیتا (metadata) گنجانده شده و اطلاعات مخصوص پایگاه‌داده مرتبط با شیء بازگردانده‌شده را ارائه می‌دهد. اگر برچسب سرور "all" مشخص شود، دستور تعریف گزینهٔ مرتبط با تمام سرورها را واکشی می‌کند. اگر یک برچسب سرور صریح مشخص شود، دستور تعریف گزینهٔ مرتبط با سرور مشخص‌شده را واکشی می‌کند. چنانچه تعریف گزینهٔ مخصوص سرور وجود نداشته باشد، دستور remote-option-def6-get تعریف گزینهٔ مرتبط با تمام سرورها را واکشی خواهد کرد.
remote-option-def6-get-all
این دستور تمام تعاریف گزینه‌های DHCPv6 را از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option-def6-get-all را ببینید <#command-remote-option-def6-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-option-def6-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چندین برچسب سرور منجر به خطا خواهد شد. برچسب سرور ویژهٔ "all" برای واکشی تعاریف گزینه‌های به‌اشتراک‌گذاشته‌شده توسط تمام سرورها مجاز است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 DHCPv6 option definition(s) found.",
"arguments": {
"option-defs": [
{
<first option definition>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
{
<second option definition>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها (maps) است. هر نگاشت حاوی مشخصات تعریف گزینه و متادیتا، شامل اطلاعات مخصوص پایگاه‌داده مرتبط با اشیاء بازگردانده‌شده است. اگر برچسب سرور "all" در دستور گنجانده شده باشد، پاسخ حاوی تعاریف گزینه‌های به‌اشتراک‌گذاشته‌شده میان تمام سرورها خواهد بود و تعاریف گزینه‌های اختصاصی سرورها را حذف می‌کند. اگر یک برچسب سرور صریح در دستور گنجانده شده باشد، پاسخ شامل تمام تعاریف گزینه‌های مستقیماً مرتبط با سرور مشخص‌شده و در صورت عدم وجود تعاریف گزینه‌های خاص سرور، شامل تعاریف گزینه‌های مرتبط با تمام سرورها خواهد بود..SS remote-option-def6-set
این دستور یک تعریف گزینهٔ DHCPv6 را در پایگاه‌دادهٔ پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دسترس‌پذیری: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option-def6-set را ببینید <#command-remote-option-def6-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option-def6-set",
"arguments": {
"option-defs": [
{
<option definition specification>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل یک مشخصهٔ تعریف گزینه باشد. فهرست server-tags الزامی است و باید دقیقاً شامل یک برچسب سرور باشد. تعیین یک فهرست خالی، مقدار null، یا چندین برچسب سرور منجر به خطا خواهد شد. برچسب سرور "all" مجاز است؛ این برچسب تعریف گزینهٔ مشخص‌شده را به تمام سرورها مرتبط می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option definition set."
}
168u
168u
نتیجه (result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty - دستور با موفقیت به پایان رسید، اما هیچ داده‌ای متأثر یا بازگردانده نشد)
• 2
4 - تعارض (conflict - دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-option4-global-del
این دستور یک گزینهٔ سراسری DHCPv4 را از پایگاه‌دادهٔ پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-global-del را ببینید <#command-remote-option4-global-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-global-del",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک مشخصهٔ گزینه است، متشکل از نام گزینه، کد و از نسخهٔ Kea 3.1، یک پارامتر اختیاری client-classes (به Option Class-tags as Keys مراجعه کنید <#cb-cmds-option-class-tags-as-keys>). تعیین یک فهرست خالی، مقدار null، یا چندین برچسب سرور منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv4 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه (result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty - دستور با موفقیت به پایان رسید، اما هیچ داده‌ای متأثر یا بازگردانده نشد)
• 2
4 - تعارض (conflict - دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک گزینهٔ سراسری DHCPv4 را برای کارساز از پایگاه‌دادهٔ مشخص‌شده واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-global-get را ببینید <#command-remote-option4-global-get>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-global-get",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
گزینه با جفت‌مقدارهای کد/فضای گزینه (option code/space) و از نسخهٔ ۳.۱ Kea، با پارامتر اختیاری client-classes شناسایی می‌شود (Option Class-tags as Keys <#cb-cmds-option-class-tags-as-keys> را ببینید). فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب کارساز باشد. تعیین یک فهرست خالی، مقدار null یا چندین برچسب کارساز منجر به خطا خواهد شد. برچسب کارساز "all" برای واکشی نمونهٔ گزینهٔ سراسریِ مشترک میان همهٔ کارسازها مجاز است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 option is found.",
"arguments": {
"options": [
{
<option information>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
]
}
}
168u
168u
فراداده گنجانده شده و اطلاعات خاص پایگاه‌دادهٔ مرتبط با شیء بازگردانده‌شده را فراهم می‌کند. اگر برچسب کارساز "all" مشخص شده باشد، دستور گزینهٔ سراسری مرتبط با همهٔ کارسازها را واکشی می‌کند. اگر برچسب کارسازِ صریحی مشخص شده باشد، دستور گزینهٔ سراسری مرتبط با کارساز مشخص‌شده را واکشی می‌کند. اگر گزینهٔ خاص کارساز وجود نداشته باشد، گزینهٔ مرتبط با همهٔ کارسازها را واکشی خواهد کرد.
remote-option4-global-get-all
این دستور همهٔ گزینه‌های سراسری DHCPv4 را برای کارساز از پایگاه‌دادهٔ پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-global-get-all را ببینید <#command-remote-option4-global-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-global-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب کارساز باشد. تعیین یک فهرست خالی، مقدار null یا چندین برچسب کارساز منجر به خطا خواهد شد. برچسب کارساز ویژهٔ "all" برای واکشی گزینه‌های سراسریِ مشترک میان همهٔ کارسازها مجاز است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 DHCPv4 option(s) found.",
"arguments": {
"options": [
{
<first option specification>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
{
<second option specification>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها (maps) است. هر نگاشت شامل مشخصات گزینهٔ سراسری و فراداده، از جمله اطلاعات مختص پایگاه‌دادهٔ مرتبط با شیء بازگردانده‌شده است. اگر برچسب کارساز "all" در دستور گنجانده شده باشد، پاسخ حاوی گزینه‌های سراسری مشترک میان همهٔ کارسازها است و گزینه‌های سراسری مختص کارساز را مستثنی می‌کند. اگر یک برچسب کارسازِ صریح در دستور گنجانده شده باشد، پاسخ شامل تمام گزینه‌های سراسری است که مستقیماً با کارساز داده‌شده مرتبط هستند، و در صورتی که گزینه‌های مختص کارساز وجود نداشته باشند، گزینه‌های مرتبط با همهٔ کارسازها را در بر خواهد داشت..SS remote-option4-global-set
این دستور یک گزینهٔ سراسری DHCPv4 را در پایگاه‌دادهٔ پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-global-set را ببینید <#command-remote-option4-global-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-global-set",
"arguments": {
"options": [
{
<global option specification>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل یک مشخصهٔ گزینه باشد. فهرست server-tags الزامی است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چندین برچسب سرور منجر به بروز خطا خواهد شد. برچسب سرور "all" مجاز است؛ این برچسب گزینهٔ مشخص‌شده را به تمام سرورها مرتبط می‌سازد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 option set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-option4-network-del
این دستور یک گزینهٔ DHCPv4 مربوط به یک شبکهٔ اشتراکی را از پایگاه‌دادهٔ پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-network-del را ببینید <#command-remote-option4-network-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-network-del",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً یک نام شبکهٔ اشتراکی و دقیقاً یک مشخصهٔ گزینه است که شامل نام گزینه، کد، و از نسخهٔ Kea 3.1 به بعد، پارامتر اختیاری client-classes می‌شود (به Option Class-tags as Keys مراجعه کنید <#cb-cmds-option-class-tags-as-keys>). مشخص کردن یک فهرست خالی، مقدار null، یا برچسب سرور منجر به بروز خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv4 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک گزینه DHCPv4 را در یک شبکه مشترک (shared network) در پایگاه‌داده پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-network-set را ببینید <#command-remote-option4-network-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-network-set",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"options": [
{
<shared network option specification>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
فهرست‌های ارائه‌شده باید دقیقاً شامل یک نام شبکه مشترک (shared network) و یک مشخصه گزینه باشند. تعیین یک فهرست خالی، یک مقدار null یا یک server tag منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 option successfully set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه (Result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده کنونی عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
remote-option4-pool-del
این دستور یک گزینه DHCPv4 را از یک استخر آدرس (address pool) از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-pool-del را ببینید <#command-remote-option4-pool-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-pool-del",
"arguments": {
"pools": [
{
"pool": <pool range or prefix>
}
],
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً یک مشخصه address pool و دقیقاً یک مشخصه گزینه شامل یک نام option space، کد و از نسخه 3.1 Kea، یک پارامتر اختیاری client-classes است (بخش Option Class-tags as Keys را ببینید <#cb-cmds-option-class-tags-as-keys>). تعیین یک فهرست خالی، یک مقدار null یا یک server tag منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv4 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه (Result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده کنونی عبارت‌اند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
این دستور یک گزینه DHCPv4 را در یک استخر نشانی در پایگاه داده پیکربندی ایجاد کرده یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-pool-set را ببینید <#command-remote-option4-pool-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-pool-set",
"arguments": {
"pools": [
{
"pool": <pool range or prefix>
}
],
"options": [
{
<address pool option specification>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً مشخصات استخر نشانی و دقیقاً یک مشخصات گزینه است. مشخص کردن یک فهرست خالی، یک مقدار null یا یک server tag منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 option successfully set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-option4-subnet-del
این دستور یک گزینه DHCPv4 را برای یک زیرشبکه از پایگاه داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-subnet-del را ببینید <#command-remote-option4-subnet-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-subnet-del",
"arguments": {
"subnets": [
{
"id": <subnet identifier>
}
],
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً یک شناسه (ID) زیرشبکه و دقیقاً یک مشخصات گزینه، شامل نام گزینه، کد، و از نسخه Kea 3.1، یک پارامتر اختیاری client-classes است (بخش Option Class-tags as Keys را ببینید <#cb-cmds-option-class-tags-as-keys>). مشخص کردن یک فهرست خالی، یک مقدار null یا یک server tag منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv4 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک گزینه DHCPv4 را در یک زیرشبکه در پایگاه‌داده پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option4-subnet-set را ببینید <#command-remote-option4-subnet-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option4-subnet-set",
"arguments": {
"subnets": [
{
"id": <subnet identifier>
}
],
"options": [
{
<subnet option specification>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
فهرست‌های ارائه‌شده باید دقیقاً شامل یک شناسه زیرشبکه و یک مشخصه گزینه باشند. مشخص کردن یک فهرست خالی، مقدار null یا یک برچسب سرور (server tag) منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 option successfully set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-option6-global-del
این دستور یک گزینه سراسری DHCPv6 را از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-global-del را ببینید <#command-remote-option6-global-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option6-global-del",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک مشخصه گزینه است، متشکل از نام گزینه، کد، و از نسخه Kea 3.1.1 به بعد، پارامتر اختیاری client-classes (به بخش Option Class-tags as Keys مراجعه کنید <#cb-cmds-option-class-tags-as-keys>). مشخص کردن یک فهرست خالی، مقدار null یا چندین برچسب سرور منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک گزینهٔ سراسری DHCPv6 را برای سرور از پایگاه‌دادهٔ مشخص‌شده دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-global-get را ببینید <#command-remote-option6-global-get>
ساختار دستور:
0.0
3.5
{
"command": "remote-option6-global-get",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
این گزینه با جفت مقادیر کد/فضای گزینه (option code/space) و از نسخهٔ 3.1.1 Kea به بعد، با یک پارامتر اختیاری client-classes شناسایی می‌شود (بخش Option Class-tags as Keys را ببینید <#cb-cmds-option-class-tags-as-keys>). فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چند برچسب سرور منجر به خطا خواهد شد. برچسب سرور "all" مجاز است تا نمونهٔ گزینهٔ سراسری به‌اشتراک‌گذاشته‌شده توسط همهٔ سرورها دریافت شود.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option is found.",
"arguments": {
"options": [
{
<option information>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
]
}
}
168u
168u
فراداده (metadata) گنجانده شده و اطلاعات خاص پایگاه‌دادهٔ مرتبط با شیء بازگردانده‌شده را فراهم می‌کند. اگر برچسب سرور "all" مشخص شده باشد، دستور تلاش می‌کند گزینهٔ سراسری مرتبط با همهٔ سرورها را دریافت کند. اگر یک برچسب سرور صریح مشخص شده باشد، دستور گزینهٔ سراسری مرتبط با سرور داده‌شده را واکشی خواهد کرد. اگر گزینهٔ مختص سرور وجود نداشته باشد، گزینهٔ مرتبط با همهٔ سرورها را دریافت می‌کند.
remote-option6-global-get-all
این دستور تمام گزینه‌های سراسری DHCPv6 را برای سرور از پایگاه‌دادهٔ پیکربندی دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-global-get-all را ببینید <#command-remote-option6-global-get-all>
ساختار دستور:
0.0
3.5
{
"command": "remote-option6-global-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست server-tags اجباری است و باید دقیقاً شامل یک برچسب سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چند برچسب سرور منجر به خطا خواهد شد. برچسب ویژهٔ سرور "all" مجاز است تا گزینه‌های سراسری به‌اشتراک‌گذاشته‌شده توسط همهٔ سرورها دریافت شوند.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 DHCPv6 option(s) found.",
"arguments": {
"options": [
{
<first option specification>,
"metadata": {
"server-tags": [ <server tag> ]
}
},
{
<second option specification>,
"metadata": {
"server-tags": [ <server tag> ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشتها است. هر نگاشت حاوی مشخصات یک گزینهٔ سراسری و فراداده (شامل اطلاعات خاص پایگاه‌دادهٔ مرتبط با شیء بازگردانده‌شده) است. اگر برچسب سرور "all" در دستور گنجانده شود، پاسخ شامل گزینه‌های سراسری مشترک بین همهٔ سرورها خواهد بود و گزینه‌های سراسری مختص سرور را شامل نمی‌شود. اگر یک برچسب سرور صریح در دستور گنجانده شود، پاسخ شامل تمام گزینه‌های سراسری مرتبط مستقیم با سرور داده‌شده، و همچنین گزینه‌های مرتبط با همهٔ سرورها در صورت عدم وجود گزینه‌های مختص سرور، خواهد بود..SS remote-option6-global-set
این دستور یک گزینهٔ سراسری DHCPv6 را در پایگاه‌دادهٔ پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
شرح و مثال‌ها: دستور remote-option6-global-set را ببینید <#command-remote-option6-global-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option6-global-set",
"arguments": {
"options": [
{
<global option specification>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <single server tag as string> ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل یک مشخصات گزینه باشد. فهرست server-tags الزامی است و باید دقیقاً شامل یک تگ سرور باشد. مشخص کردن یک فهرست خالی، مقدار null، یا چندین تگ سرور منجر به خطا خواهد شد. تگ سرور "all" مجاز است؛ این تگ گزینهٔ مشخص‌شده را به تمام سرورها مرتبط می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-option6-network-del
این دستور یک گزینهٔ DHCPv6 را از یک شبکهٔ مشترک (shared network) در پایگاه‌دادهٔ پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
شرح و مثال‌ها: دستور remote-option6-network-del را ببینید <#command-remote-option6-network-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option6-network-del",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً یک نام از شبکهٔ مشترک و دقیقاً یک مشخصات گزینه است، شامل نام گزینه، کد، و از نسخهٔ Kea 3.1.1، پارامتر اختیاری client-classes (بخش Option Class-tags as Keys را ببینید <#cb-cmds-option-class-tags-as-keys>). مشخص کردن یک فهرست خالی، مقدار null، یا یک تگ سرور منجر به بروز خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک گزینهٔ DHCPv6 را در یک شبکهٔ مشترک (shared network) در پایگاه‌دادهٔ پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
سطح دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-network-set را ببینید <#command-remote-option6-network-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option6-network-set",
"arguments": {
"shared-networks": [
{
"name": <shared network name>
}
],
"options": [
{
<shared network option specification>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
فهرست‌های ارائه‌شده باید دقیقاً شامل یک نام شبکهٔ مشترک و یک مشخصهٔ گزینه باشند. تعیین یک فهرست خالی، مقدار null یا یک برچسب سرور منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option successfully set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه (Result) یک نمایش عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد) (empty)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بودند) (conflict)
168u
remote-option6-pd-pool-del
این دستور یک گزینهٔ DHCPv6 را از یک استخر تفویض پیشوند (prefix delegation pool) در پایگاه‌دادهٔ پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
سطح دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-pd-pool-del را ببینید <#command-remote-option6-pd-pool-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option6-pd-pool-del",
"arguments": {
"pd-pools": [
{
"prefix": <pool prefix (address part)>,
"prefix-len": <pool prefix (length part)>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"options": [
{
"code": <option code>,
"space": <option space>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست است که دقیقاً شامل یک مشخصهٔ استخر تفویض پیشوند و دقیقاً یک مشخصهٔ گزینه شامل نام گزینه، کد و از نسخهٔ Kea 3.1.1، پارامتر اختیاری client-classes می‌شوند (بخش Option Class-tags as Keys را ببینید <#cb-cmds-option-class-tags-as-keys>). تعیین یک فهرست خالی، مقدار null یا یک برچسب سرور منجر به خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه (Result) یک نمایش عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد) (empty)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بودند) (conflict)
این دستور یک گزینهٔ DHCPv6 را در یک استخر واگذاری پیشوند (prefix delegation pool) در پایگاه‌دادهٔ پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: write (پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-pd-pool-set را ببینید <#command-remote-option6-pd-pool-set>
نحو دستور:
0.0
3.5
{
"command": "remote-option6-pd-pool-set",
"arguments": {
"pd-pools": [
{
"prefix": <pool prefix (address part)>,
"prefix-len": <pool prefix (length part)>
}
],
"options": [
{
<prefix delegation pool option specification>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً یک مشخصهٔ استخر واگذاری پیشوند و دقیقاً یک مشخصهٔ گزینه است. مشخص کردن یک فهرست خالی، یک مقدار null یا یک برچسب کارساز منجر به بروز خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option successfully set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه (result) نمایش عدد صحیح وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت پایان یافت، اما هیچ داده‌ای متأثر نشد یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند، زیرا با وضعیت کارساز در تعارض بودند)
168u
remote-option6-pool-del
این دستور یک گزینهٔ DHCPv6 را از یک استخر نشانی در پایگاه‌دادهٔ پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانهٔ قلاب cb_cmds)
دسترسی: write (پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-pool-del را ببینید <#command-remote-option6-pool-del>
نحو دستور:
0.0
3.5
{
"command": "remote-option6-pool-del",
"arguments": {
"pools": [
{
"pool": <pool range or prefix>
}
],
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً یک مشخصهٔ استخر نشانی و دقیقاً یک مشخصهٔ گزینه است، شامل نام گزینه، کد و از Kea 3.1.1 به بعد، پارامتر اختیاری client-classes (بخش Option Class-tags as Keys را ببینید <#cb-cmds-option-class-tags-as-keys>). مشخص کردن یک فهرست خالی، یک مقدار null یا یک برچسب کارساز منجر به بروز خطا خواهد شد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه (result) نمایش عدد صحیح وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت پایان یافت، اما هیچ داده‌ای متأثر نشد یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند، زیرا با وضعیت کارساز در تعارض بودند)
این دستور یک گزینه DHCPv6 را در یک استخر نشانی در پایگاه‌داده پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-pool-set را ببینید <#command-remote-option6-pool-set>
ساختار دستور:
0.0
3.5
{
"command": "remote-option6-pool-set",
"arguments": {
"pools": [
{
"pool": <pool range or prefix>
}
],
"options": [
{
<address pool option specification>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با مشخصات دقیق استخر نشانی و مشخصات دقیق یک گزینه است. مشخص کردن یک فهرست خالی، مقدار null، یا یک برچسب سرور منجر به خطا خواهد شد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option successfully set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <one or more comma-separated strings> ]
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
remote-option6-subnet-del
این دستور یک گزینه DHCPv6 را از یک زیرشبکه در پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-subnet-del را ببینید <#command-remote-option6-subnet-del>
ساختار دستور:
0.0
3.5
{
"command": "remote-option6-subnet-del",
"arguments": {
"subnets": [
{
"id": <subnet identifier>
}
],
"options": [
{
"code": <option code>,
"space": <option space>,
"client-classes": [ <zero or more comma-separated strings> ]
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل دو فهرست با دقیقاً یک شناسه زیرشبکه و مشخصات دقیق یک گزینه است که شامل نام گزینه، کد، و از نسخه Kea 3.1.1 به بعد، پارامتر اختیاری client-classes می‌شود (بخش Option Class-tags as Keys را ببینید <#cb-cmds-option-class-tags-as-keys>). مشخص کردن یک فهرست خالی، مقدار null، یا یک برچسب سرور منجر به خطا خواهد شد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 option(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور یک گزینهٔ DHCPv6 را در یک زیرشبکه در پایگاه‌دادهٔ پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دردسترس‌بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-option6-subnet-set را ببینید <#command-remote-option6-subnet-set>
ساختار دستور:
0.0
3.5
{
"command": "remote-option6-subnet-set",
"arguments": {
"subnets": [
{
"id": <subnet identifier>
}
],
"options": [
{
<subnet option specification>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
فهرست‌های ارائه‌شده باید دقیقاً شامل یک شناسهٔ زیرشبکه و یک مشخصات گزینه باشند. تعیین یک فهرست خالی، یک مقدار null، یا یک برچسب سرور منجر به خطا خواهد شد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 option successfully set.",
"arguments": {
"options": [
{
"code": <option code>,
"space": <option space>
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت پایان یافت، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
remote-server4-del
این دستور اطلاعات مربوط به یک سرور DHCPv4 را از پایگاه‌دادهٔ پیکربندی حذف می‌کند. هر پیکربندی که به‌طور صریح با سرور حذف‌شده مرتبط باشد، به‌طور خودکار جداسازی می‌شود. علاوه بر این، مؤلفه‌های پیکربندی که با سرورهای دیگر قابل اشتراک‌گذاری نیستند (مانند پارامترهای سراسری DHCP) حذف می‌شوند. مؤلفه‌های پیکربندی قابل اشتراک‌گذاری (مانند زیرشبکه‌ها، شبکه‌های اشتراکی) حذف نمی‌شوند چرا که ممکن است توسط سرورهای دیگر استفاده شوند.
پشتیبانی‌شده توسط: kea-dhcp4
دردسترس‌بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server4-del را ببینید <#command-remote-server4-del>
ساختار دستور:
0.0
3.5
{
"command": "remote-server4-del",
"arguments": {
"servers": [
{
"server-tag": <server name>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور حاوی فهرستی است که دقیقاً شامل یک نگاشت با برچسب سرورِ مورد نظر برای حذف می‌باشد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv4 server(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت پایان یافت، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور اطلاعاتی درباره کارساز DHCPv4، مانند برچسب کارساز و توضیحات آن را واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server4-get را ببینید <#command-remote-server4-get>
نحو دستور:
0.0
3.5
{
"command": "remote-server4-get",
"arguments": {
"servers": [
{
"server-tag": <server tag>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور فهرستی را حمل می‌کند که دقیقاً شامل یک نگاشت با برچسب کارساز موردنظر برای واکشی است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCP server 'server tag' found.",
"arguments": {
"servers": [
{
"server-tag": <server tag>,
"description": <server description>
}
],
"count": 1
}
}
168u
168u
برچسب کارساز (server tag) شناسه یکتای کارساز است که برای مرتبط کردن عناصر پیکربندی در پایگاه‌داده با نمونه کارساز خاص استفاده می‌شود. توضیحات کارساز بازگردانده‌شده توسط کاربر هنگام تنظیم اطلاعات کارساز مشخص می‌شود.
remote-server4-get-all
این دستور اطلاعات مربوط به تمام کارسازهای DHCPv4 مشخص‌شده توسط کاربر را واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server4-get-all را ببینید <#command-remote-server4-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-server4-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور به جز remote اختیاری هیچ آرگومانی ندارد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 servers found.",
"arguments": {
"servers": [
{
"server-tag": <first server tag>,
"description": <first server description>
},
{
"server-tag": <second server tag>,
"description": <second server description>
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها است. هر نگاشت حاوی یک برچسب کارساز است که کارساز را به‌طور یکتا شناسایی می‌کند، و همچنین توضیحات تعریف‌شده توسط کاربر برای کارساز. بخش پشتیبان پیکربندی Kea از کلیدواژه all برای مرتبط ساختن بخش‌هایی از پیکربندی با همه کارسازها استفاده می‌کند. این بخش به صورت داخلی کارساز منطقی all را برای این منظور ایجاد می‌کند. با این حال، این کارساز منطقی به عنوان نتیجه دستور remote-server4-get-all بازگردانده نمی‌شود؛ تنها کارسازهای تعریف‌شده توسط کاربر بازگردانده می‌شوند.
remote-server4-set
این دستور اطلاعات مربوط به کارساز DHCPv4 را در پایگاه‌داده ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server4-set را ببینید <#command-remote-server4-set>
نحو دستور:
0.0
3.5
{
"command": "remote-server4-set",
"arguments": {
"servers": [
{
"server-tag": <server tag>,
"description": <server description>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل مشخصات یک کارساز باشد. server-tag باید در میان تمام کارسازهای درون پایگاه‌داده پیکربندی یکتا باشد. description متن دلخواهی است که کارساز، موقعیت آن در شبکه و غیره را توصیف می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv4 server successfully set.",
"arguments": {
"servers": [
{
"server-tag": <server tag>,
"description": <server description>
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت کارساز در تعارض بودند)
این دستور اطلاعات مربوط به یک سرور DHCPv6 را از پایگاه‌داده پیکربندی حذف می‌کند. هر پیکربندی که به‌طور صریح با سرور حذف‌شده مرتبط شده باشد، به‌طور خودکار ارتباطش قطع می‌شود. علاوه بر این، عناصر پیکربندی که با سایر سرورها قابل اشتراک‌گذاری نیستند (مانند پارامترهای سراسری DHCP) حذف می‌شوند. عناصر پیکربندی قابل اشتراک‌گذاری (مانند زیرشبکه‌ها و شبکه‌های مشترک) حذف نمی‌شوند چرا که ممکن است توسط سایر سرورها استفاده شوند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server6-del را ببینید <#command-remote-server6-del>
نحو دستور:
0.0
3.5
{
"command": "remote-server6-del",
"arguments": {
"servers": [
{
"server-tag": <server name>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور فهرستی شامل دقیقاً یک نگاشت با برچسب سروری که باید حذف شود را حمل می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 DHCPv6 server(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-server6-get
این دستور اطلاعات مربوط به سرور DHCPv6، مانند برچسب و توضیحات سرور را واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server6-get را ببینید <#command-remote-server6-get>
نحو دستور:
0.0
3.5
{
"command": "remote-server6-get",
"arguments": {
"servers": [
{
"server-tag": <server tag>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور فهرستی شامل دقیقاً یک نگاشت با برچسب سروری که باید واکشی شود را حمل می‌کند.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCP server 'server tag' found.",
"arguments": {
"servers": [
{
"server-tag": <server tag>,
"description": <server description>
}
],
"count": 1
}
}
168u
168u
برچسب سرور (server tag) شناسه یکتای سرور است که برای مرتبط کردن عناصر پیکربندی در پایگاه‌داده با نمونه سرور مشخص استفاده می‌شود. توضیحات بازگردانده‌شده سرور توسط کاربر هنگام تعیین اطلاعات سرور مشخص می‌شود..SS remote-server6-get-all
این دستور اطلاعات مربوط به تمام سرورهای DHCPv6 مشخص‌شده توسط کاربر را واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دردسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server6-get-all را ببینید <#command-remote-server6-get-all>
نحو دستور:
0.0
3.5
{
"command": "remote-server6-get-all",
"arguments": {
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور به جز گزینه اختیاری remote هیچ آرگومان دیگری ندارد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 servers found.",
"arguments": {
"servers": [
{
"server-tag": <first server tag>,
"description": <first server description>
},
{
"server-tag": <second server tag>,
"description": <second server description>
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها است. هر نگاشت حاوی یک برچسب سرور است که سرور را به‌طور یکتا مشخص می‌کند، و توصیفی که توسط کاربر برای سرور تعیین شده است. بخش پشتیبان پیکربندی کی (Kea Configuration Backend) از کلیدواژه all برای مرتبط ساختن بخش‌هایی از پیکربندی با همه سرورها استفاده می‌کند. این بخش در درون خود، سرور منطقی all را برای این منظور ایجاد می‌کند. با این حال، این سرور منطقی در خروجی دستور remote-server6-get-all بازگردانده نمی‌شود؛ تنها سرورهای تعریف‌شده توسط کاربر بازگردانده می‌شوند.
remote-server6-set
این دستور اطلاعات مربوط به سرور DHCPv6 را در پایگاه‌داده ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دردسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: نوشتن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-server6-set را ببینید <#command-remote-server6-set>
نحو دستور:
0.0
3.5
{
"command": "remote-server6-set",
"arguments": {
"servers": [
{
"server-tag": <server tag>,
"description": <server description>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً حاوی مشخصات یک سرور باشد. مقدار server-tag باید در میان تمام سرورهای موجود در پایگاه‌داده پیکربندی یکتا باشد. مقدار description متنی دلخواه برای توصیف سرور، موقعیت آن در شبکه و غیره است.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "DHCPv6 server successfully set.",
"arguments": {
"servers": [
{
"server-tag": <server tag>,
"description": <server description>
}
]
}
}
168u
168u
نتیجه یک نمایش عددی صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور یک زیرشبکه IPv4 را با استفاده از شناسه (ID) از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 1.6.0 (کتابخانه قلاب cb_cmds)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet4-del-by-id را ببینید <#command-remote-subnet4-del-by-id>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet4-del-by-id",
"arguments": {
"subnets": [
{
"id": <subnet identifier>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک شناسه از زیرشبکه برای حذف است. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 IPv4 subnet(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده فعلی عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-subnet4-del-by-prefix
این دستور یک زیرشبکه IPv4 را با استفاده از پیشوند از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 1.6.0 (کتابخانه قلاب cb_cmds)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet4-del-by-prefix را ببینید <#command-remote-subnet4-del-by-prefix>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet4-del-by-prefix",
"arguments": {
"subnets": [
{
"subnet": <subnet prefix>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک پیشوند از زیرشبکه برای حذف است. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 IPv4 subnet(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده فعلی عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور زیرشبکه IPv4 انتخاب‌شده را بر اساس شناسه (ID) از پایگاه داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet4-get-by-id را ببینید <#command-remote-subnet4-get-by-id>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet4-get-by-id",
"arguments": {
"subnets": [ {
"id": <subnet identifier>
} ],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک شناسه از زیرشبکه‌ای است که باید بازگردانده شود. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet found.",
"arguments": {
"subnets": [ {
"id": <subnet identifier>,
"subnet": <subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the subnet specification here>
} ],
"count": 1
}
}
168u
168u
اگر نام شبکه مشترک (shared network) برابر با null باشد، به این معنی است که زیرشبکه بازگردانده‌شده متعلق به هیچ شبکه مشترکی نیست (یک زیرشبکه سراسری یا global subnet). متادیتا در تعریف زیرشبکه بازگردانده‌شده گنجانده شده و اطلاعات خاص پایگاه داده مرتبط با شیء بازگردانده‌شده را ارائه می‌دهد.
remote-subnet4-get-by-prefix
این دستور زیرشبکه IPv4 انتخاب‌شده را بر اساس پیشوند (prefix) از پایگاه داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet4-get-by-prefix را ببینید <#command-remote-subnet4-get-by-prefix>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet4-get-by-prefix",
"arguments": {
"subnets": [ {
"subnet": <subnet prefix>
} ],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک پیشوند از زیرشبکه‌ای است که باید بازگردانده شود. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet found.",
"arguments": {
"subnets": [
{
"id": <subnet identifier>,
"subnet": <subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the subnet specification here>
}
],
"count": 1
}
}
168u
168u
اگر نام شبکه مشترک (shared network) برابر با null باشد، به این معنی است که زیرشبکه بازگردانده‌شده متعلق به هیچ شبکه مشترکی نیست (زیرشبکه سراسری یا global subnet). متادیتا در تعریف زیرشبکه بازگردانده‌شده گنجانده شده و اطلاعات خاص پایگاه داده مرتبط با شیء بازگردانده‌شده را ارائه می‌دهد..SS remote-subnet4-list
این دستور فهرستی از تمام زیرشبکه‌های IPv4 را از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet4-list را ببینید <#command-remote-subnet4-list>
ساختار دستور:
0.0
3.5
{
"command": "remote-subnet4-list",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست server-tags برای این دستور الزامی است و نباید خالی باشد. این فهرست می‌تواند شامل یک یا چند برچسب سرور به‌صورت رشته، یا یک مقدار منفرد null باشد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 IPv4 subnets found.",
"arguments": {
"subnets": [
{
"id": <first subnet identifier>,
"subnet": <first subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
},
{
"id": <second subnet identifier>,
"subnet": <second subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, ... ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها است. هر نگاشت حاوی یک شناسه زیرشبکه، پیشوند و نام شبکه اشتراکی است که زیرشبکه به آن تعلق دارد. اگر زیرشبکه به هیچ شبکه اشتراکی تعلق نداشته باشد، این نام null است. متادیتا شامل اطلاعات مختص پایگاه‌داده است که با زیرشبکه‌ها مرتبط است. فهرست بازگردانده‌شده شامل تعاریف کامل زیرشبکه نیست؛ برای واکشی اطلاعات کامل درباره زیرشبکه‌های انتخاب‌شده از remote-subnet4-get استفاده کنید. اگر دستور شامل برچسب‌های سرور صریح به‌صورت رشته باشد (از جمله برچسب ویژه سرور "all")، فهرست شامل تمام زیرشبکه‌هایی خواهد بود که با هر یک از برچسب‌های مشخص‌شده مرتبط هستند. حتی اگر یک زیرشبکه با چندین سرور مرتبط باشد و تنها یکی از برچسب‌های مشخص‌شده مطابقت داشته باشد، آن زیرشبکه بازگردانده می‌شود. اگر دستور حاوی مقدار null در فهرست server-tags باشد، پاسخ شامل تمام زیرشبکه‌هایی است که به هیچ سروری تخصیص داده نشده‌اند (تخصیص‌نیافته).
remote-subnet4-set
این دستور یک زیرشبکه IPv4 را در پایگاه‌داده پیکربندی ایجاد کرده یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: نوشتن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet4-set را ببینید <#command-remote-subnet4-set>
ساختار دستور:
0.0
3.5
{
"command": "remote-subnet4-set",
"arguments": {
"subnets": [
{
"id": <subnet identifier>,
"subnet": <subnet prefix>,
"shared-network-name": <shared network name or null>,
<the rest of the subnet specification here>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل یک مشخصه زیرشبکه باشد. پارامتر shared-network-name برای این دستورها الزامی است؛ این پارامتر زیرشبکه را بر اساس نام شبکه اشتراکی، به آن مرتبط می‌سازد. اگر زیرشبکه نباید به هیچ شبکه اشتراکی تعلق داشته باشد (یک زیرشبکه سراسری)، باید مقدار null برای نام شبکه اشتراکی مشخص شود. فهرست server-tags اجباری است و باید شامل یک یا چند برچسب سرور به‌صورت رشته باشد تا زیرشبکه را به‌طور صریح با یک یا چند سرور تعریف‌شده توسط کاربر مرتبط کند. دستور remote-subnet4-set ممکن است شامل برچسب ویژه سرور "all" برای مرتبط کردن زیرشبکه با تمام سرورها باشد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet successfully set.",
"arguments": {
"id": <subnet identifier>,
"subnet": <subnet prefix>
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty - دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict - دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک زیرشبکه IPv6 را بر اساس شناسه از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet6-del-by-id را ببینید <#command-remote-subnet6-del-by-id>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet6-del-by-id",
"arguments": {
"subnets": [
{
"id": <subnet identifier>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک شناسه از زیرشبکه‌ای است که باید حذف شود. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 IPv6 subnet(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
remote-subnet6-del-by-prefix
این دستور یک زیرشبکه IPv6 را بر اساس پیشوند از پایگاه‌داده پیکربندی حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه هوک cb_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet6-del-by-prefix را ببینید <#command-remote-subnet6-del-by-prefix>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet6-del-by-prefix",
"arguments": {
"subnets": [
{
"subnet": <subnet prefix>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک پیشوند از زیرشبکه‌ای است که باید حذف شود. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 IPv6 subnet(s) deleted.",
"arguments": {
"count": 1
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور زیرشبکه IPv6 انتخاب‌شده را بر اساس شناسه از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده در: kea-dhcp6
دردسترس‌بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet6-get-by-id را ببینید <#command-remote-subnet6-get-by-id>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet6-get-by-id",
"arguments": {
"subnets": [
{
"id": <subnet identifier>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک شناسه از زیرشبکه‌ای است که باید بازگردانده شود. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet found.",
"arguments": {
"subnets": [
{
"id": <subnet identifier>,
"subnet": <subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the subnet specification here>
}
],
"count": 1
}
}
168u
168u
اگر نام شبکه مشترک (shared network name) برابر با null باشد، به این معنی است که زیرشبکه بازگردانده‌شده به هیچ شبکه مشترکی تعلق ندارد (یک زیرشبکه سراسری). فراداده (metadata) در تعریف زیرشبکه بازگردانده‌شده گنجانده شده و اطلاعات مربوط به پایگاه‌داده را که با شیء بازگردانده‌شده مرتبط است ارائه می‌دهد.
remote-subnet6-get-by-prefix
این دستور زیرشبکه IPv6 انتخاب‌شده را بر اساس پیشوند از پایگاه‌داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده در: kea-dhcp6
دردسترس‌بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet6-get-by-prefix را ببینید <#command-remote-subnet6-get-by-prefix>
نحو دستور:
0.0
3.5
{
"command": "remote-subnet6-get-by-prefix",
"arguments": {
"subnets": [
{
"subnet": <subnet prefix>
}
],
"remote": {
<specification of the database to connect to>
}
}
}
168u
168u
این دستور شامل فهرستی با دقیقاً یک پیشوند از زیرشبکه‌ای است که باید بازگردانده شود. پارامتر server-tags نباید برای این دستور مشخص شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet found.",
"arguments": {
"subnets": [ {
"id": <subnet identifier>,
"subnet": <subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
},
<the rest of the subnet specification here>
} ],
"count": 1
}
}
168u
168u
اگر نام شبکه مشترک برابر با null باشد، به این معنی است که زیرشبکه بازگردانده‌شده به هیچ شبکه مشترکی تعلق ندارد (زیرشبکه سراسری). فراداده (metadata) در تعریف زیرشبکه بازگردانده‌شده گنجانده شده و اطلاعات مربوط به پایگاه‌داده را که با شیء بازگردانده‌شده مرتبط است ارائه می‌دهد..SS remote-subnet6-list
این دستور فهرستی از تمام زیرشبکه‌های IPv6 را از پایگاه داده پیکربندی واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: خواندن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet6-list را ببینید <#command-remote-subnet6-list>
ساختار دستور:
0.0
3.5
{
"command": "remote-subnet6-list",
"arguments": {
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست server-tags برای این دستور الزامی است و نباید خالی باشد. این فهرست می‌تواند شامل یک یا چند برچسب سرور به صورت رشته، یا یک مقدار منفرد null باشد.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 IPv6 subnets found.",
"arguments": {
"subnets": [
{
"id": <first subnet identifier>,
"subnet": <first subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
},
{
"id": <second subnet identifier>,
"subnet": <second subnet prefix>,
"shared-network-name": <shared network name or null>,
"metadata": {
"server-tags": [ <first server tag>, ... ]
}
}
],
"count": 2
}
}
168u
168u
پاسخ بازگردانده‌شده شامل فهرستی از نگاشت‌ها (maps) است. هر نگاشت حاوی یک شناسه زیرشبکه، پیشوند، و نام شبکه اشتراکی است که زیرشبکه به آن تعلق دارد. اگر زیرشبکه متعلق به هیچ شبکه اشتراکی نباشد، این نام null است. متادیتا شامل اطلاعات مختص پایگاه داده است که با زیرشبکه‌ها مرتبط هستند. فهرست بازگردانده‌شده شامل تعاریف کامل زیرشبکه نیست؛ برای واکشی اطلاعات کامل درباره زیرشبکه‌های انتخاب‌شده، از remote-subnet6-get استفاده کنید. اگر دستور شامل برچسب‌های سرور صریح به صورت رشته باشد (شامل برچسب سرور ویژه "all")، فهرست شامل تمامی زیرشبکه‌هایی خواهد بود که با هر یک از برچسب‌های مشخص‌شده مرتبط هستند. یک زیرشبکه حتی در صورتی که با چندین سرور مرتبط باشد و تنها یکی از برچسب‌های مشخص‌شده مطابقت داشته باشد نیز بازگردانده می‌شود. اگر دستور شامل مقدار null در فهرست server-tags باشد، پاسخ شامل تمامی زیرشبکه‌هایی خواهد بود که به هیچ سروری تخصیص نیافته‌اند (تخصیص‌نیافته).
remote-subnet6-set
این دستور یک زیرشبکه IPv6 را در پایگاه داده پیکربندی ایجاد یا جایگزین می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه قلاب cb_cmds)
دسترسی: نوشتن (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور remote-subnet6-set را ببینید <#command-remote-subnet6-set>
ساختار دستور:
0.0
3.5
{
"command": "remote-subnet6-set",
"arguments": {
"subnets": [
{
"id": <subnet identifier>,
"subnet": <subnet prefix>,
"shared-network-name": <shared network name or null>,
<the rest of the subnet specification here>
}
],
"remote": {
<specification of the database to connect to>
},
"server-tags": [ <first server tag>, <second server tag>, ... ]
}
}
168u
168u
فهرست ارائه‌شده باید دقیقاً شامل مشخصات یک زیرشبکه باشد. پارامتر shared-network-name برای این دستورها الزامی است؛ این پارامتر زیرشبکه را از طریق نام آن به شبکه اشتراکی مرتبط می‌کند. اگر زیرشبکه نباید متعلق به هیچ شبکه اشتراکی باشد (یک زیرشبکه سراسری یا global)، باید مقدار null برای نام شبکه اشتراکی مشخص شود. فهرست server-tags اجباری است و باید شامل یک یا چند برچسب سرور به صورت رشته باشد تا زیرشبکه را صراحتاً به یک یا چند سرور تعریف‌شده توسط کاربر مرتبط سازد. دستور remote-subnet6-set می‌تواند شامل برچسب سرور ویژه "all" باشد تا زیرشبکه را به تمامی سرورها مرتبط کند.
ساختار پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet successfully set.",
"arguments": {
"id": <subnet identifier>,
"subnet": <subnet prefix>
}
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک رزرو میزبان (host reservation) جدید اضافه می‌کند. این رزرو می‌تواند شامل نشانی‌های IPv4، نشانی‌های IPv6، پیشوندهای IPv6، شناسه‌های گوناگون، کلاسی که کلاینت به آن تخصیص داده می‌شود، گزینه‌های DHCPv4 و DHCPv6، و موارد دیگر باشد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.2.0 (کتابخانه هوک host_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-add را ببینید <#command-reservation-add>
نحو دستور:
0.0
3.5
{
"command": "reservation-add",
"arguments": {
"reservation": {
"boot-file-name": <string>,
"client-id": <string>,
"circuit-id": <string>,
"duid": <string>,
"flex-id": <string>,
"ip-address": <string (IPv4 address)>,
"ip-addresses": [ <comma-separated strings> ],
"hw-address": <string>,
"hostname": <string>,
"next-server": <string (IPv4 address)>,
"option-data": [ <comma-separated structures defining options> ],
"prefixes": [ <comma-separated IPv6 prefixes> ],
"client-classes": [ <comma-separated strings> ],
"server-hostname": <string>,
"subnet-id": <integer>,
"user-context": <any valid JSON>
},
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
توجه داشته باشید که boot-file-name، circuit-id، client-id، ip-address، next-server و server-hostname مختص IPv4 هستند. ip-addresses و prefixes مختص IPv6 هستند. operation-target اختیاری است؛ پیش‌فرض 'alternate' است.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": <string>
}
168u
168u
نتیجه یک نمایش عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
reservation-del
این دستور یک رزرو میزبان موجود را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.2.0 (کتابخانه هوک host_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-del را ببینید <#command-reservation-del>
نحو دستور:
0.0
3.5
{
"command": "reservation-del",
"arguments": {
"subnet-id": <integer>,
"ip-address": <string>,
"identifier-type": <one of 'hw-address', 'duid', 'circuit-id', 'client-id' and 'flex-id'>,
"identifier": <string>,
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
رزرو میزبان می‌تواند با جفت (subnet-id, ip-address) یا سه‌تاییِ (subnet-id, identifier-type, identifier) شناسایی شود. operation-target اختیاری است؛ پیش‌فرض 'alternate' است.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک رزرو میزبان موجود را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.2.0 (کتابخانه هوک host_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-get را ببینید <#command-reservation-get>
نحو دستور:
0.0
3.5
{
"command": "reservation-get",
"arguments": {
"subnet-id": <integer>,
"identifier-type": <one of 'hw-address', 'duid', 'circuit-id', 'client-id' and 'flex-id'>,
"identifier": <string>,
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
رزرو میزبان می‌تواند با جفت (subnet-id, ip-address) یا سه‌گانه (subnet-id, identifier-type, identifier) شناسایی شود. پارامتر operation-target اختیاری است؛ پیش‌فرض 'all' است.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": <string>,
"arguments": {
"boot-file-name": <string>,
"comment": <string>,
"client-id": <string>,
"circuit-id": <string>,
"duid": <string>,
"flex-id": <string>,
"ip-address": <string (IPv4 address)>,
"ip-addresses": [ <comma-separated strings> ],
"hw-address": <string>,
"hostname": <string>,
"next-server": <string (IPv4 address)>,
"option-data": [ <comma-separated structures defining options> ],
"prefixes": [ <comma-separated IPv6 prefixes> ],
"client-classes": [ <comma-separated strings> ],
"server-hostname": <string>,
"subnet-id": <integer>,
"user-context": <any valid JSON>
}
}
168u
168u
شیء arguments تنها در صورتی ظاهر می‌شود که میزبانی یافت شود. بسیاری از فیلدها در شیء arguments تنها در صورتی ظاهر می‌شوند که فیلد مشخصی تنظیم شده باشد.
reservation-get-all
این دستور تمامی رزروهای میزبان را برای یک زیرشبکه مشخص بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه هوک host_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-get-all را ببینید <#command-reservation-get-all>
نحو دستور:
0.0
3.5
{
"command": "reservation-get-all",
"arguments": {
"subnet-id": <integer>,
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
پارامتر operation-target اختیاری است؛ پیش‌فرض 'all' است.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
دستور reservation-get-all ممکن است منجر به پاسخ‌های بسیار حجیم شود.
reservation-get-by-address
این دستور تمامی رزروهای میزبان را برای یک ip-address مشخص و به صورت اختیاری برای یک زیرشبکه معین بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 2.4.0 (کتابخانه هوک host_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-get-by-address را ببینید <#command-reservation-get-by-address>
نحو دستور:
0.0
3.5
{
"command": "reservation-get-by-address",
"arguments": {
"ip-address": <string>,
"subnet-id": <integer>,
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
رزروهای میزبان می‌توانند با جفتی از 'ip-address' و 'subnet-id' شناسایی شوند. 'subnet-id' اختیاری است. 'operation-target' اختیاری است؛ پیش‌فرض 'all' است.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
دستور reservation-get-by-address ممکن است چندین رزرو را برای یک ip-address یکسان برگرداند. این دستور در صورتی که پرچم پیکربندی ip-reservations-unique روی false تنظیم شده باشد، می‌تواند مفید باشد..SS reservation-get-by-hostname
این دستور تمامی رزروهای میزبان را برای یک hostname مشخص و به‌طور اختیاری یک subnet مشخص بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 1.7.1 (کتابخانه قلاب host_cmds)
سطح دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-get-by-hostname را ببینید <#command-reservation-get-by-hostname>
ساختار دستور:
0.0
3.5
{
"command": "reservation-get-by-hostname",
"arguments": {
"hostname": <hostname>,
"subnet-id": <integer>,
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
پارامتر operation-target اختیاری است؛ مقدار پیش‌فرض 'all' است.
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
دستور reservation-get-by-hostname ممکن است به پاسخ‌های حجیمی منجر شود.
reservation-get-by-id
این دستور تمامی رزروهای میزبان را برای یک شناسهٔ مشخص (نوع و مقدار) بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 1.9.0 (کتابخانه قلاب host_cmds)
سطح دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-get-by-id را ببینید <#command-reservation-get-by-id>
ساختار دستور:
0.0
3.5
{
"command": "reservation-get-by-id",
"arguments": {
"identifier-type": <one of 'hw-address', 'duid', 'circuit-id', 'client-id' and 'flex-id'>,
"identifier": <string>,
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
پارامتر operation-target اختیاری است؛ مقدار پیش‌فرض 'all' است.
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
دستور reservation-get-by-id ممکن است به پاسخ‌های حجیمی منجر شود.
reservation-get-page
این دستور تمامی رزروهای میزبان یا رزروهای میزبان مربوط به یک subnet مشخص را به‌صورت صفحه‌بندی‌شده بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 1.6.0 (کتابخانه قلاب host_cmds)
سطح دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور reservation-get-page را ببینید <#command-reservation-get-page>
ساختار دستور:
0.0
3.5
{
"command": "reservation-get-page",
"arguments": {
"subnet-id": <integer>,
"limit": <integer>,
"source-index": <integer>,
"from": <integer>
}
}
168u
168u
پارامتر limit برای اندازهٔ صفحه اجباری است. پارامتر subnet-id از نسخهٔ 1.9.0 به بعد اختیاری است. پارامترهای source-index و from host-id اختیاری هستند و مقدار پیش‌فرض آن‌ها 0 است. مقادیر مورد نیاز برای بارگیری صفحهٔ بعد، در پاسخ‌ها در قالب یک نگاشت next بازگردانده می‌شوند.
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
مقدار result نمایشی عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور یک رزرو میزبان (host reservation) موجود را به‌روزرسانی می‌کند. این رزرو باید شامل شناسه‌های میزبان و یک شناسه زیرشبکه باشد و می‌تواند شامل نشانی‌های IPv4، نشانی‌های IPv6، پیشوندهای IPv6، شناسه‌های گوناگون، کلاسی که کلاینت به آن تخصیص خواهد یافت، گزینه‌های DHCPv4 و DHCPv6، و موارد دیگر باشد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 2.3.7 (کتابخانه قلاب host_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور reservation-update در <#command-reservation-update> مراجعه کنید
نحو دستور:
0.0
3.5
{
"command": "reservation-update",
"arguments": {
"reservation": {
"boot-file-name": <string>,
"client-id": <string>,
"circuit-id": <string>,
"duid": <string>,
"flex-id": <string>,
"ip-address": <string (IPv4 address)>,
"ip-addresses": [ <comma-separated strings> ],
"hw-address": <string>,
"hostname": <string>,
"next-server": <string (IPv4 address)>,
"option-data": [ <comma-separated structures defining options> ],
"prefixes": [ <comma-separated IPv6 prefixes> ],
"client-classes": [ <comma-separated strings> ],
"server-hostname": <string>,
"subnet-id": <integer>,
"user-context": <any valid JSON>
},
"operation-target": <string (memory, database, all, default)>
}
}
168u
168u
توجه داشته باشید که boot-file-name، circuit-id، client-id، ip-address، next-server و server-hostname مختص IPv4 هستند. ip-addresses و prefixes مختص IPv6 می‌باشند. آرگومان operation-target اختیاری است؛ مقدار پیش‌فرض 'alternate' است.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": <string>
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند، زیرا با وضعیت سرور در تعارض بودند)
168u
server-tag-get
این دستور برچسب سرور (server tag) مورد استفاده توسط سرور را بازمی‌گرداند.
برچسب سرور یک پارامتر پیکربندی ضروری در پیکربندی Config Backend است.
این پارامتر در فایل پیکربندی محلی تنظیم می‌شود.
این دستور هیچ پارامتری دریافت نمی‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.6.0 (توکار)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور server-tag-get در <#command-server-tag-get> مراجعه کنید
نحو دستور:
0.0
3.5
{
"command": "server-tag-get"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"arguments": {
"server-tag": "office1"
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند، زیرا با وضعیت سرور در تعارض بودند)
این دستور استخری را که دقیقاً با یک محدوده نشانی مطابقت دارد از پسانه اجاره (lease back end) حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از نسخه: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool4-del را ببینید <#command-sflq-pool4-del>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool4-del",
"arguments": {
"start-address": "192.0.2.0",
"end-address": "192.0.2.255",
"force": true
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 pool(s) deleted."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
sflq-pool4-get-all
این دستور فهرستی از تمامی استخرهای v4 SFLQ را از پسانه اجاره واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از نسخه: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool4-get-all را ببینید <#command-sflq-pool4-get-all>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool4-get-all"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"pools": [
{
"created-ts": "2026-05-02 10:54:55.000000",
"delegated-len": 128,
"end-address": "192.0.2.255",
"free-leases": 256,
"lease-type": "V4",
"modified-ts": "2026-05-02 10:54:55.000000",
"start-address": "192.0.2.0",
"subnet-id": 6
}
]
},
"result": 0,
"text": "1 pool(s) found."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
sflq-pool4-get-by-range
این دستور فهرستی از تمامی استخرهای v4 SFLQ را که با یک محدوده نشانی هم‌پوشانی دارند، از پسانه اجاره واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از نسخه: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool4-get-by-range را ببینید <#command-sflq-pool4-get-by-range>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool4-get-by-range",
"arguments": {
"start-address": "192.0.2.0",
"end-address": "192.0.2.255"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"pools": [
{
"created-ts": "2026-05-02 10:54:55.000000",
"delegated-len": 128,
"end-address": "192.0.2.255",
"free-leases": 256,
"lease-type": "V4",
"modified-ts": "2026-05-02 10:54:55.000000",
"start-address": "192.0.2.0",
"subnet-id": 123
}
]
},
"result": 0,
"text": "1 pool(s) found."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بود)
این دستور فهرستی از تمام poolهای v4 SFLQ متعلق به یک subnet را از lease back end واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس در: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool4-get-by-subnet را ببینید <#command-sflq-pool4-get-by-subnet>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool4-get-by-subnet",
"arguments": {
"subnet-id": 123
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"pools": [
{
"created-ts": "2026-05-02 10:54:55.000000",
"delegated-len": 128,
"end-address": "192.0.2.255",
"free-leases": 256,
"lease-type": "V4",
"modified-ts": "2026-05-02 10:54:55.000000",
"start-address": "192.0.2.0",
"subnet-id": 123
}
]
},
"result": 0,
"text": "1 pool(s) found."
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
sflq-pool4-rebuild
این دستور به lease back end فرمان می‌دهد داده‌های اجاره‌های آزاد (free lease data) را برای یک pool از نوع v4 SFLQ بازسازی کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس در: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool4-rebuild را ببینید <#command-sflq-pool4-rebuild>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool4-rebuild",
"arguments": {
"start-address": "1.2.3.4",
"end-address": "1.2.3.4"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "SFLQ pool rebuilt."
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور استخری را که دقیقاً با یک محدوده نشانی مطابقت دارد، از بک‌اند اجاره حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
در دسترس بودن: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool6-del را ببینید <#command-sflq-pool6-del>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool6-del",
"arguments": {
"start-address": "3001::ffff",
"end-address": "3001::10",
"force": true
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "1 pool(s) deleted."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت تکمیل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
168u
sflq-pool6-get-all
این دستور فهرستی از تمام استخرهای v6 SFLQ را از بک‌اند اجاره واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
در دسترس بودن: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool6-get-all را ببینید <#command-sflq-pool6-get-all>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool6-get-all"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"pools": [
{
"created-ts": "2026-05-05 08:40:40.000000",
"delegated-len": 128,
"end-address": "3001::ffff",
"free-leases": 65520,
"lease-type": "IA_NA",
"modified-ts": "2026-05-05 08:40:41.000000",
"start-address": "3001::10",
"subnet-id": 100
},
{
"created-ts": "2026-05-05 08:40:41.000000",
"delegated-len": 64,
"end-address": "3001:20:0:ff:ffff:ffff:ffff:ffff",
"free-leases": 256,
"lease-type": "IA_PD",
"modified-ts": "2026-05-05 08:40:41.000000",
"start-address": "3001:20::",
"subnet-id": 100
}
]
},
"result": 0,
"text": "2 pool(s) found."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت تکمیل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تعارض (conflict) (دستور نتوانست تغییرات پیکربندی درخواست‌شده را اعمال کند زیرا با وضعیت سرور در تعارض بودند)
این دستور فهرستی از تمام استخرهای v6 SFLQ را که با یک محدوده نشانی همپوشانی دارند، از بک‌اند اجاره (lease back end) واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
دسترس‌پذیری: 3.1.9 (کتابخانه قلاب lease_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool6-get-by-range را ببینید <#command-sflq-pool6-get-by-range>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool6-get-by-range",
"arguments": {
"start-address": "3001::10",
"end-address": "3001::ffff"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"pools": [
{
"created-ts": "2026-05-05 08:40:40.000000",
"delegated-len": 128,
"end-address": "3001::ffff",
"free-leases": 65520,
"lease-type": "IA_NA",
"modified-ts": "2026-05-05 08:40:41.000000",
"start-address": "3001::10",
"subnet-id": 100
}
]
},
"result": 0,
"text": "1 pool(s) found."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
sflq-pool6-get-by-subnet
این دستور فهرستی از تمام استخرهای v6 SFLQ را که به یک زیرشبکه تعلق دارند، از بک‌اند اجاره (lease back end) واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4, kea-dhcp6
دسترس‌پذیری: 3.1.9 (کتابخانه قلاب lease_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool6-get-by-subnet را ببینید <#command-sflq-pool6-get-by-subnet>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool6-get-by-subnet",
"arguments": {
"subnet-id": 100
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"arguments": {
"pools": [
{
"created-ts": "2026-05-05 08:40:40.000000",
"delegated-len": 128,
"end-address": "3001::ffff",
"free-leases": 65520,
"lease-type": "IA_NA",
"modified-ts": "2026-05-05 08:40:41.000000",
"start-address": "3001::10",
"subnet-id": 100
},
{
"created-ts": "2026-05-05 08:40:41.000000",
"delegated-len": 64,
"end-address": "3001:20:0:ff:ffff:ffff:ffff:ffff",
"free-leases": 256,
"lease-type": "IA_PD",
"modified-ts": "2026-05-05 08:40:41.000000",
"start-address": "3001:20::",
"subnet-id": 100
}
]
},
"result": 0,
"text": "2 pool(s) found."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
این دستور به backend اجاره دستور می‌دهد تا داده‌های اجاره‌های آزاد را برای یک pool v6 SFLQ بازسازی کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس از: 3.1.9 (کتابخانه هوک lease_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور sflq-pool6-rebuild را ببینید <#command-sflq-pool6-rebuild>
نحو دستور:
0.0
3.5
{
"command": "sflq-pool6-rebuild",
"arguments": {
"start-address": "2001:db8:1::",
"end-address": "2001:db8:1::ffff"
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "SFLQ pool rebuilt."
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
shutdown
این دستور به سرور اعلام می‌کند که فرآیند خاموش شدن (shutdown) خود را آغاز کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس از: 1.0.0 (توکار)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور shutdown را ببینید <#command-shutdown>
نحو دستور:
0.0
3.5
{
"command": "shutdown",
"arguments": {
"exit-value": 123
}
}
168u
168u
سرور با تأیید این‌که فرآیند خاموش شدن آغاز شده است پاسخ می‌دهد.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
stat-lease4-get
این دستور آمار اجاره‌ها را برای محدوده‌ای از زیرشبکه‌های شناخته‌شده IPv4 واکشی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس از: 1.4.0 (کتابخانه هوک stat_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور stat-lease4-get را ببینید <#command-stat-lease4-get>
نحو دستور:
0.0
3.5
{
"command": "stat-lease4-get"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "stat-lease4-get: 2 rows found",
"arguments": {
"result-set": {
"columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ],
"rows": [
[ 10, 256, 200, 111, 0 ],
[ 20, 4098, 5000, 2034, 4 ]
],
"timestamp": "2018-05-04 15:03:37.000000"
}
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
این دستور آمار اجاره‌ها را برای محدوده‌ای از زیرشبکه‌های شناخته‌شدهٔ IPv6 دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس از: 1.4.0 (کتابخانهٔ قلاب stat_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور stat-lease6-get را ببینید <#command-stat-lease6-get>
نحو دستور:
0.0
3.5
{
"command": "stat-lease6-get",
"arguments": {
"subnet-id" : 10
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "stat-lease6-get: 2 rows found",
"arguments": {
"result-set": {
"columns": [ "subnet-id", "total-nas", "cumulative-assigned-nas", "assigned-nas", "declined-addresses", "total-pds", "cumulative-assigned-pds", "assigned-pds" ],
"rows": [
[ 10, 4096, 3000, 2400, 3, 0, 0],
[ 20, 0, 0, 0, 1048, 500, 233 ],
[ 30, 256, 300, 60, 0, 1048, 15, 15 ]
],
"timestamp": "2018-05-04 15:03:37.000000"
}
}
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شدهٔ کنونی عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
statistic-get
این دستور یک آمار منفرد را دریافت می‌کند. این دستور یک پارامتر رشته‌ای منفرد به نام name می‌گیرد که نام آمار را مشخص می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس از: 1.0.0 (توکار)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-get را ببینید <#command-statistic-get>
نحو دستور:
0.0
3.5
{
"command": "statistic-get",
"arguments": {
"name": "pkt4-received"
}
}
168u
168u
سرور با جزئیات آمار درخواستی پاسخ می‌دهد، که در آن result برابر 0 نشان‌دهندهٔ موفقیت است و آمار مشخص‌شده به عنوان مقدار پارامتر "arguments" ارائه می‌شود.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"arguments": {
"pkt4-received": [ [ "first_value", "2019-07-30 10:11:19.498739" ], [ "second_value", "2019-07-30 10:11:19.498662" ] ]
}
}
168u
168u
مقدار result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شدهٔ کنونی عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور تمام آمارهای ثبت‌شده را بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.0.0 (توکار)
سطح دسترسی: read (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-get-all را ببینید <#command-statistic-get-all>
نحو دستور:
0.0
3.5
{
"command": "statistic-get-all",
"arguments": { }
}
168u
168u
سرور با جزئیات تمام آمارهای ثبت‌شده پاسخ می‌دهد.
نحو پاسخ:
0.0
3.5
{
"result": 0,
"arguments": {
"assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836096"
]
],
"cumulative-assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836166"
]
],
"declined-addresses": [
[
0,
"2023-06-13 20:42:46.836156"
]
],
"pkt4-ack-received": [
[
0,
"2023-06-13 20:42:46.616247"
]
],
"pkt4-ack-sent": [
[
0,
"2023-06-13 20:42:46.616290"
]
],
"pkt4-decline-received": [
[
0,
"2023-06-13 20:42:46.616296"
]
],
"pkt4-discover-received": [
[
0,
"2023-06-13 20:42:46.616303"
]
],
"pkt4-inform-received": [
[
0,
"2023-06-13 20:42:46.616308"
]
],
"pkt4-nak-received": [
[
0,
"2023-06-13 20:42:46.616312"
]
],
"pkt4-nak-sent": [
[
0,
"2023-06-13 20:42:46.616314"
]
],
"pkt4-offer-received": [
[
0,
"2023-06-13 20:42:46.616318"
]
],
"pkt4-offer-sent": [
[
0,
"2023-06-13 20:42:46.616323"
]
],
"pkt4-parse-failed": [
[
0,
"2023-06-13 20:42:46.616326"
]
],
"pkt4-receive-drop": [
[
0,
"2023-06-13 20:42:46.616330"
]
],
"pkt4-received": [
[
0,
"2023-06-13 20:42:46.616335"
]
],
"pkt4-release-received": [
[
0,
"2023-06-13 20:42:46.616339"
]
],
"pkt4-request-received": [
[
0,
"2023-06-13 20:42:46.616343"
]
],
"pkt4-sent": [
[
0,
"2023-06-13 20:42:46.616348"
]
],
"pkt4-unknown-received": [
[
0,
"2023-06-13 20:42:46.616354"
]
],
"reclaimed-declined-addresses": [
[
0,
"2023-06-13 20:42:46.836159"
]
],
"reclaimed-leases": [
[
0,
"2023-06-13 20:42:46.836163"
]
],
"subnet[1].assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836173"
]
],
"subnet[1].cumulative-assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836098"
]
],
"subnet[1].declined-addresses": [
[
0,
"2023-06-13 20:42:46.836178"
]
],
"subnet[1].pool[0].assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836205"
]
],
"subnet[1].pool[0].cumulative-assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836137"
]
],
"subnet[1].pool[0].declined-addresses": [
[
0,
"2023-06-13 20:42:46.836213"
]
],
"subnet[1].pool[0].reclaimed-declined-addresses": [
[
0,
"2023-06-13 20:42:46.836225"
]
],
"subnet[1].pool[0].reclaimed-leases": [
[
0,
"2023-06-13 20:42:46.836236"
]
],
"subnet[1].pool[0].total-addresses": [
[
11010049,
"2023-06-13 20:42:46.836128"
]
],
"subnet[1].reclaimed-declined-addresses": [
[
0,
"2023-06-13 20:42:46.836186"
]
],
"subnet[1].reclaimed-leases": [
[
0,
"2023-06-13 20:42:46.836194"
]
],
"subnet[1].total-addresses": [
[
11010049,
"2023-06-13 20:42:46.836083"
]
],
"subnet[1].v4-lease-reuses": [
[
0,
"2023-06-13 20:42:46.836105"
]
],
"subnet[1].v4-reservation-conflicts": [
[
0,
"2023-06-13 20:42:46.836111"
]
],
"v4-allocation-fail": [
[
0,
"2023-06-13 20:42:46.616358"
]
],
"v4-allocation-fail-classes": [
[
0,
"2023-06-13 20:42:46.616363"
]
],
"v4-allocation-fail-no-pools": [
[
0,
"2023-06-13 20:42:46.616368"
]
],
"v4-allocation-fail-shared-network": [
[
0,
"2023-06-13 20:42:46.616372"
]
],
"v4-allocation-fail-subnet": [
[
0,
"2023-06-13 20:42:46.616376"
]
],
"v4-lease-reuses": [
[
0,
"2023-06-13 20:42:46.616410"
]
],
"v4-reservation-conflicts": [
[
0,
"2023-06-13 20:42:46.616412"
]
]
}
}
or
{
"result": 0,
"arguments": {
"assigned-nas": [
[
0,
"2023-06-13 21:28:57.196757"
]
],
"assigned-pds": [
[
0,
"2023-06-13 21:28:57.196757"
]
],
"cumulative-assigned-nas": [
[
0,
"2023-06-13 21:28:57.196757"
]
],
"cumulative-assigned-pds": [
[
0,
"2023-06-13 21:28:57.196758"
]
],
"declined-addresses": [
[
0,
"2023-06-13 21:28:57.196754"
]
],
"pkt6-advertise-received": [
[
0,
"2023-06-13 21:28:57.177731"
]
],
"pkt6-advertise-sent": [
[
0,
"2023-06-13 21:28:57.177739"
]
],
"pkt6-decline-received": [
[
0,
"2023-06-13 21:28:57.177739"
]
],
"pkt6-dhcpv4-query-received": [
[
0,
"2023-06-13 21:28:57.177740"
]
],
"pkt6-dhcpv4-response-received": [
[
0,
"2023-06-13 21:28:57.177740"
]
],
"pkt6-dhcpv4-response-sent": [
[
0,
"2023-06-13 21:28:57.177741"
]
],
"pkt6-infrequest-received": [
[
0,
"2023-06-13 21:28:57.177742"
]
],
"pkt6-parse-failed": [
[
0,
"2023-06-13 21:28:57.177742"
]
],
"pkt6-rebind-received": [
[
0,
"2023-06-13 21:28:57.177743"
]
],
"pkt6-receive-drop": [
[
0,
"2023-06-13 21:28:57.177743"
]
],
"pkt6-received": [
[
0,
"2023-06-13 21:28:57.177744"
]
],
"pkt6-release-received": [
[
0,
"2023-06-13 21:28:57.177744"
]
],
"pkt6-renew-received": [
[
0,
"2023-06-13 21:28:57.177745"
]
],
"pkt6-reply-received": [
[
0,
"2023-06-13 21:28:57.177745"
]
],
"pkt6-reply-sent": [
[
0,
"2023-06-13 21:28:57.177746"
]
],
"pkt6-request-received": [
[
0,
"2023-06-13 21:28:57.177747"
]
],
"pkt6-sent": [
[
0,
"2023-06-13 21:28:57.177747"
]
],
"pkt6-solicit-received": [
[
0,
"2023-06-13 21:28:57.177748"
]
],
"pkt6-unknown-received": [
[
0,
"2023-06-13 21:28:57.177748"
]
],
"reclaimed-declined-addresses": [
[
0,
"2023-06-13 21:28:57.196755"
]
],
"reclaimed-leases": [
[
0,
"2023-06-13 21:28:57.196756"
]
],
"subnet[1].assigned-nas": [
[
0,
"2023-06-13 21:28:57.196760"
]
],
"subnet[1].assigned-pds": [
[
0,
"2023-06-13 21:28:57.196761"
]
],
"subnet[1].cumulative-assigned-nas": [
[
0,
"2023-06-13 21:28:57.196727"
]
],
"subnet[1].cumulative-assigned-pds": [
[
0,
"2023-06-13 21:28:57.196729"
]
],
"subnet[1].declined-addresses": [
[
0,
"2023-06-13 21:28:57.196763"
]
],
"subnet[1].pd-pool[0].assigned-pds": [
[
0,
"2023-06-13 21:28:57.196785"
]
],
"subnet[1].pd-pool[0].cumulative-assigned-pds": [
[
0,
"2023-06-13 21:28:57.196744"
]
],
"subnet[1].pd-pool[0].reclaimed-leases": [
[
0,
"2023-06-13 21:28:57.196789"
]
],
"subnet[1].pd-pool[0].total-pds": [
[
256,
"2023-06-13 21:28:57.196741"
]
],
"subnet[1].pool[0].assigned-nas": [
[
0,
"2023-06-13 21:28:57.196773"
]
],
"subnet[1].pool[0].cumulative-assigned-nas": [
[
0,
"2023-06-13 21:28:57.196739"
]
],
"subnet[1].pool[0].declined-addresses": [
[
0,
"2023-06-13 21:28:57.196775"
]
],
"subnet[1].pool[0].reclaimed-declined-addresses": [
[
0,
"2023-06-13 21:28:57.196779"
]
],
"subnet[1].pool[0].reclaimed-leases": [
[
0,
"2023-06-13 21:28:57.196783"
]
],
"subnet[1].pool[0].total-nas": [
[
281474976710656,
"2023-06-13 21:28:57.196736"
]
],
"subnet[1].reclaimed-declined-addresses": [
[
0,
"2023-06-13 21:28:57.196766"
]
],
"subnet[1].reclaimed-leases": [
[
0,
"2023-06-13 21:28:57.196770"
]
],
"subnet[1].total-nas": [
[
281474976710656,
"2023-06-13 21:28:57.196720"
]
],
"subnet[1].total-pds": [
[
256,
"2023-06-13 21:28:57.196724"
]
],
"subnet[1].v6-ia-na-lease-reuses": [
[
0,
"2023-06-13 21:28:57.196731"
]
],
"subnet[1].v6-ia-pd-lease-reuses": [
[
0,
"2023-06-13 21:28:57.196733"
]
],
"v6-allocation-fail": [
[
0,
"2023-06-13 21:28:57.177749"
]
],
"v6-allocation-fail-classes": [
[
0,
"2023-06-13 21:28:57.177755"
]
],
"v6-allocation-fail-no-pools": [
[
0,
"2023-06-13 21:28:57.177756"
]
],
"v6-allocation-fail-shared-network": [
[
0,
"2023-06-13 21:28:57.177756"
]
],
"v6-allocation-fail-subnet": [
[
0,
"2023-06-13 21:28:57.177757"
]
],
"v6-ia-na-lease-reuses": [
[
0,
"2023-06-13 21:28:57.177757"
]
],
"v6-ia-pd-lease-reuses": [
[
0,
"2023-06-13 21:28:57.177758"
]
]
}
}
or
{
"result": 0,
"arguments": {
"ncr-error": [
[
0,
"2023-06-13 21:42:54.627751"
]
],
"ncr-invalid": [
[
0,
"2023-06-13 21:42:54.627749"
]
],
"ncr-received": [
[
0,
"2023-06-13 21:42:54.627737"
]
],
"queue-mgr-queue-full": [
[
0,
"2023-06-13 21:42:54.627737"
]
],
"update-error": [
[
0,
"2023-06-13 21:42:54.627759"
]
],
"update-sent": [
[
0,
"2023-06-13 21:42:54.627752"
]
],
"update-signed": [
[
0,
"2023-06-13 21:42:54.627753"
]
],
"update-success": [
[
0,
"2023-06-13 21:42:54.627755"
]
],
"update-timeout": [
[
0,
"2023-06-13 21:42:54.627757"
]
],
"update-unsigned": [
[
0,
"2023-06-13 21:42:54.627754"
]
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0.IP
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
statistic-global-get-all
این دستور تمام آمارهای سراسری ثبت‌شده را (بدون در نظر گرفتن آمارهای زیرشبکه) بازیابی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 3.1.2 (توکار)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-global-get-all را ببینید <#command-statistic-global-get-all>
نحو دستور:
0.0
3.5
{
"command": "statistic-global-get-all",
"arguments": { }
}
168u
168u
سرور با جزئیات تمام آمارهای سراسری ثبت‌شده پاسخ می‌دهد (بدون در نظر گرفتن آمارهای زیرشبکه).
نحو پاسخ:
0.0
3.5
{
"result": 0,
"arguments": {
"assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836096"
]
],
"cumulative-assigned-addresses": [
[
0,
"2023-06-13 20:42:46.836166"
]
],
"declined-addresses": [
[
0,
"2023-06-13 20:42:46.836156"
]
],
"pkt4-ack-received": [
[
0,
"2023-06-13 20:42:46.616247"
]
],
"pkt4-ack-sent": [
[
0,
"2023-06-13 20:42:46.616290"
]
],
"pkt4-decline-received": [
[
0,
"2023-06-13 20:42:46.616296"
]
],
"pkt4-discover-received": [
[
0,
"2023-06-13 20:42:46.616303"
]
],
"pkt4-inform-received": [
[
0,
"2023-06-13 20:42:46.616308"
]
],
"pkt4-nak-received": [
[
0,
"2023-06-13 20:42:46.616312"
]
],
"pkt4-nak-sent": [
[
0,
"2023-06-13 20:42:46.616314"
]
],
"pkt4-offer-received": [
[
0,
"2023-06-13 20:42:46.616318"
]
],
"pkt4-offer-sent": [
[
0,
"2023-06-13 20:42:46.616323"
]
],
"pkt4-parse-failed": [
[
0,
"2023-06-13 20:42:46.616326"
]
],
"pkt4-receive-drop": [
[
0,
"2023-06-13 20:42:46.616330"
]
],
"pkt4-received": [
[
0,
"2023-06-13 20:42:46.616335"
]
],
"pkt4-release-received": [
[
0,
"2023-06-13 20:42:46.616339"
]
],
"pkt4-request-received": [
[
0,
"2023-06-13 20:42:46.616343"
]
],
"pkt4-sent": [
[
0,
"2023-06-13 20:42:46.616348"
]
],
"pkt4-unknown-received": [
[
0,
"2023-06-13 20:42:46.616354"
]
],
"reclaimed-declined-addresses": [
[
0,
"2023-06-13 20:42:46.836159"
]
],
"reclaimed-leases": [
[
0,
"2023-06-13 20:42:46.836163"
]
],
"v4-allocation-fail": [
[
0,
"2023-06-13 20:42:46.616358"
]
],
"v4-allocation-fail-classes": [
[
0,
"2023-06-13 20:42:46.616363"
]
],
"v4-allocation-fail-no-pools": [
[
0,
"2023-06-13 20:42:46.616368"
]
],
"v4-allocation-fail-shared-network": [
[
0,
"2023-06-13 20:42:46.616372"
]
],
"v4-allocation-fail-subnet": [
[
0,
"2023-06-13 20:42:46.616376"
]
],
"v4-lease-reuses": [
[
0,
"2023-06-13 20:42:46.616410"
]
],
"v4-reservation-conflicts": [
[
0,
"2023-06-13 20:42:46.616412"
]
]
}
}
or
{
"result": 0,
"arguments": {
"assigned-nas": [
[
0,
"2023-06-13 21:28:57.196757"
]
],
"assigned-pds": [
[
0,
"2023-06-13 21:28:57.196757"
]
],
"cumulative-assigned-nas": [
[
0,
"2023-06-13 21:28:57.196757"
]
],
"cumulative-assigned-pds": [
[
0,
"2023-06-13 21:28:57.196758"
]
],
"declined-addresses": [
[
0,
"2023-06-13 21:28:57.196754"
]
],
"pkt6-advertise-received": [
[
0,
"2023-06-13 21:28:57.177731"
]
],
"pkt6-advertise-sent": [
[
0,
"2023-06-13 21:28:57.177739"
]
],
"pkt6-decline-received": [
[
0,
"2023-06-13 21:28:57.177739"
]
],
"pkt6-dhcpv4-query-received": [
[
0,
"2023-06-13 21:28:57.177740"
]
],
"pkt6-dhcpv4-response-received": [
[
0,
"2023-06-13 21:28:57.177740"
]
],
"pkt6-dhcpv4-response-sent": [
[
0,
"2023-06-13 21:28:57.177741"
]
],
"pkt6-infrequest-received": [
[
0,
"2023-06-13 21:28:57.177742"
]
],
"pkt6-parse-failed": [
[
0,
"2023-06-13 21:28:57.177742"
]
],
"pkt6-rebind-received": [
[
0,
"2023-06-13 21:28:57.177743"
]
],
"pkt6-receive-drop": [
[
0,
"2023-06-13 21:28:57.177743"
]
],
"pkt6-received": [
[
0,
"2023-06-13 21:28:57.177744"
]
],
"pkt6-release-received": [
[
0,
"2023-06-13 21:28:57.177744"
]
],
"pkt6-renew-received": [
[
0,
"2023-06-13 21:28:57.177745"
]
],
"pkt6-reply-received": [
[
0,
"2023-06-13 21:28:57.177745"
]
],
"pkt6-reply-sent": [
[
0,
"2023-06-13 21:28:57.177746"
]
],
"pkt6-request-received": [
[
0,
"2023-06-13 21:28:57.177747"
]
],
"pkt6-sent": [
[
0,
"2023-06-13 21:28:57.177747"
]
],
"pkt6-solicit-received": [
[
0,
"2023-06-13 21:28:57.177748"
]
],
"pkt6-unknown-received": [
[
0,
"2023-06-13 21:28:57.177748"
]
],
"reclaimed-declined-addresses": [
[
0,
"2023-06-13 21:28:57.196755"
]
],
"reclaimed-leases": [
[
0,
"2023-06-13 21:28:57.196756"
]
],
"v6-allocation-fail": [
[
0,
"2023-06-13 21:28:57.177749"
]
],
"v6-allocation-fail-classes": [
[
0,
"2023-06-13 21:28:57.177755"
]
],
"v6-allocation-fail-no-pools": [
[
0,
"2023-06-13 21:28:57.177756"
]
],
"v6-allocation-fail-shared-network": [
[
0,
"2023-06-13 21:28:57.177756"
]
],
"v6-allocation-fail-subnet": [
[
0,
"2023-06-13 21:28:57.177757"
]
],
"v6-ia-na-lease-reuses": [
[
0,
"2023-06-13 21:28:57.177757"
]
],
"v6-ia-pd-lease-reuses": [
[
0,
"2023-06-13 21:28:57.177758"
]
]
}
}
168u
168u
نتیجه (Result) نمایشی از وضعیت به‌صورت عدد صحیح است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0.IP
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
statistic-remove
این دستور یک داده آماری منفرد را حذف می‌کند. این دستور یک پارامتر رشته‌ای تکی به نام name دریافت می‌کند که نام داده آماری را مشخص می‌سازد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.0.0 (توکار)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-remove را ببینید <#command-statistic-remove>
ساختار دستور:
0.0
3.5
{
"command": "statistic-remove",
"arguments": {
"name": "pkt4-received"
}
}
168u
168u
اگر داده آماری مشخص‌شده پیدا شود و حذف آن موفقیت‌آمیز باشد، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد parameters خالی پاسخ می‌دهد. اگر خطایی رخ دهد (برای مثال، داده آماری درخواستی پیدا نشود)، سرور کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
فیلد result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
statistic-remove-all
(منسوخ‌شده) این دستور تمام داده‌های آماری را حذف می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.0.0 (توکار)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-remove-all را ببینید <#command-statistic-remove-all>
ساختار دستور:
0.0
3.5
{
"command": "statistic-remove-all",
"arguments": { }
}
168u
168u
اگر حذف تمام داده‌های آماری موفقیت‌آمیز باشد، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد parameters خالی پاسخ می‌دهد. اگر خطایی رخ دهد، سرور کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
فیلد result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
statistic-reset
این دستور داده آماری مشخص‌شده را روی مقدار خنثی آن تنظیم می‌کند: 0 برای عدد صحیح (integer)، 0.0 برای ممیز شناور (float)، 0h0m0s0us برای مدت‌زمان (time duration)، و "" برای نوع رشته‌ای (string). این دستور یک پارامتر رشته‌ای تکی به نام name دریافت می‌کند که نام داده آماری را مشخص می‌سازد.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.0.0 (توکار)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-reset را ببینید <#command-statistic-reset>
ساختار دستور:
0.0
3.5
{
"command": "statistic-reset",
"arguments": {
"name": "pkt4-received"
}
}
168u
168u
اگر داده آماری مشخص‌شده پیدا شود و بازنشانی آن موفقیت‌آمیز باشد، سرور با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد parameters خالی پاسخ می‌دهد. اگر خطایی رخ دهد (برای مثال، داده آماری درخواستی پیدا نشود)، سرور کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
فیلد result یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور تمام آمارها را به مقادیر خنثی خود تنظیم می‌کند: 0 برای عدد صحیح (integer)، 0.0 برای ممیز شناور (float)، 0h0m0s0us برای بازه زمانی (time duration) و "" برای نوع رشته (string).
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.0.0 (داخلی)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
شرح و مثال‌ها: دستور statistic-reset-all را در <#command-statistic-reset-all> ببینید.
نحو دستور:
0.0
3.5
{
"command": "statistic-reset-all",
"arguments": { }
}
168u
168u
اگر عملیات موفقیت‌آمیز باشد، کارگزار با وضعیت 0 که نشان‌دهنده موفقیت است و یک فیلد پارامترهای خالی پاسخ می‌دهد. در صورت بروز خطا، کارگزار کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه (Result) نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بود)
168u
statistic-sample-age-set
این دستور یک محدودیت زمانی را برای یک آماره منفرد تنظیم می‌کند. این دستور دو پارامتر دریافت می‌کند: یک رشته به نام name و یک مقدار عدد صحیح به نام duration.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.6.0 (داخلی)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
شرح و مثال‌ها: دستور statistic-sample-age-set را در <#command-statistic-sample-age-set> ببینید.
نحو دستور:
0.0
3.5
{
"command": "statistic-sample-age-set",
"arguments": {
"name": "pkt4-received",
"duration": 1245
}
}
168u
168u
کارگزار پیامی مبنی بر تنظیم موفقیت‌آمیز محدودیت برای آماره مشخص‌شده، با نتیجه 0 نشان‌دهنده موفقیت و یک فیلد پارامترهای خالی برمی‌گرداند. در صورت بروز خطا (برای مثال اگر آماره درخواستی پیدا نشود)، کارگزار کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه (Result) نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بود)
168u
statistic-sample-age-set-all
این دستور یک محدودیت زمانی را برای تمامی آمارها تنظیم می‌کند. این دستور یک پارامتر منفرد از نوع عدد صحیح به نام duration دریافت می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.6.0 (داخلی)
دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
شرح و مثال‌ها: دستور statistic-sample-age-set-all را در <#command-statistic-sample-age-set-all> ببینید.
نحو دستور:
0.0
3.5
{
"command": "statistic-sample-age-set-all",
"arguments": {
"duration": 1245
}
}
168u
168u
کارگزار پیامی مبنی بر تنظیم موفقیت‌آمیز محدودیت‌ها برای تمامی آمارها، با نتیجه 0 نشان‌دهنده موفقیت و یک فیلد پارامترهای خالی برمی‌گرداند. در صورت بروز خطا، کارگزار کد وضعیت 1 (خطا) را بازمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه (Result) نمایشی از وضعیت در قالب عدد صحیح است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بود)
این دستور یک محدودیت مبتنی بر اندازه را برای یک شاخص آماری منفرد تنظیم می‌کند. این دستور دو پارامتر دریافت می‌کند: یک رشته به نام name و یک مقدار عدد صحیح به نام max-samples.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.6.0 (داخلی)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-sample-count-set را ببینید <#command-statistic-sample-count-set>
نحو دستور:
0.0
3.5
{
"command": "statistic-sample-count-set",
"arguments": {
"name": "pkt4-received",
"max-samples": 100
}
}
168u
168u
سرور پیامی مبنی بر تنظیم موفقیت‌آمیز محدودیت برای شاخص آماری داده‌شده ارسال می‌کند، با مقدار 0 برای result که نشان‌دهنده موفقیت است، و یک فیلد خالی parameters. اگر خطایی رخ دهد (برای مثال شاخص آماری درخواستی یافت نشود)، سرور کد وضعیت 1 (خطا) را برمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
فیلد result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
statistic-sample-count-set-all
این دستور یک محدودیت مبتنی بر اندازه را برای تمام شاخص‌های آماری تنظیم می‌کند. این دستور یک پارامتر منفرد از نوع عدد صحیح به نام max-samples می‌گیرد.
پشتیبانی‌شده توسط: kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.6.0 (داخلی)
سطح دسترسی: write (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور statistic-sample-count-set-all را ببینید <#command-statistic-sample-count-set-all>
نحو دستور:
0.0
3.5
{
"command": "statistic-sample-count-set-all",
"arguments": {
"max-samples": 100
}
}
168u
168u
سرور پیامی مبنی بر تنظیم موفقیت‌آمیز محدودیت‌ها برای تمام شاخص‌های آماری ارسال می‌کند، با مقدار 0 برای result که نشان‌دهنده موفقیت است، و یک فیلد خالی parameters. در صورت بروز خطا، سرور کد وضعیت 1 (خطا) را برمی‌گرداند و فیلد text حاوی شرح خطا خواهد بود.
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
فیلد result یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
168u
status-get
این دستور اطلاعات زمان اجرای سرور را برمی‌گرداند.
این دستور هیچ آرگومانی نمی‌پذیرد.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.7.3 (داخلی)
سطح دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور status-get را ببینید <#command-status-get>
نحو دستور:
0.0
3.5
{
"command": "status-get"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": <integer>,
"arguments": {
"dhcp-state": {
"disabled-by-db-connection": [],
"disabled-by-local-command": [],
"disabled-by-remote-command": [],
"disabled-by-user": false,
"globally-disabled": false
},
"extended-info-tables": <whether relay information is held in lease tables>,
"high-availability": [
{
"ha-mode": <HA mode configured for this relationship>,
"ha-servers": {
"local": {
"role": <role of this server as in the configuration file>,
"scopes": <list of scope names served by this server>,
"server-name": <name of the local server>,
"state": <HA state name of the server receiving the command>,
"system-time": <system time in format '%Y-%m-%d %H:%M:%S' on UTC timezone>
},
"remote": {
"age": <the age of the remote status in seconds>,
"analyzed-packets": <number of packets sent to the partner server since communication was interrupted>,
"clock-skew": <difference in seconds between local and partner server times>,
"communication-interrupted": <whether communication did not happen for more than max-response-delay milliseconds>,
"connecting-clients": <number of different clients getting a lease from partner>,
"in-touch": <indicates if this server communicated with partner>,
"last-scopes": <list of scopes served by partner>,
"last-state": <HA state name of the partner>,
"role": <partner role>,
"server-name": <name of the partner server>,
"system-time": <system time in format '%Y-%m-%d %H:%M:%S' on UTC timezone>,
"unacked-clients": <number of unacked clients>,
"unacked-clients-left": <how many more clients have to be unacked before partner-down state>
}
}
}
],
"multi-threading-enabled": true,
"packet-queue-size": 64,
"packet-queue-statistics": [ 1.2, 2.3, 3.4 ],
"pid": <integer>,
"reload": <time since reload in seconds>,
"sockets": {
"errors": <list of errors received during the last attempt to open all sockets; only appears when status is failed or retrying>,
"status": <ready, retrying, or failed>
},
"thread-pool-size": 4,
"uptime": <uptime in seconds>
}
}
168u
168u
اگر کتابخانه قلاب‌های libdhcp_ha (دسترس‌پذیری بالا یا High Availability) توسط سرور DHCP دریافت‌کننده این دستور بارگذاری شده باشد، پاسخ همچنین شامل اطلاعات وضعیت مختص HA سرور دریافت‌کننده دستور و وضعیت سرور همتای آن (partner) خواهد بود..SS subnet4-add
این دستور یک زیرشبکه جدید ایجاد کرده و به پیکربندی موجود سرور اضافه می‌کند. این عملیات هیچ تأثیری بر سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس در: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-add را ببینید <#command-subnet4-add>
نحو دستور:
0.0
3.5
{
"command": "subnet4-add",
"arguments": {
"subnet4": [ {
"id": 123,
"subnet": "10.20.30.0/24",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet added",
"arguments": {
"subnets": [
{
"id": 123,
"subnet": "10.20.30.0/24"
}
]
}
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
168u
subnet4-del
این دستور یک زیرشبکه را از پیکربندی سرور حذف می‌کند. این دستور هیچ اثری بر سایر زیرشبکه‌های پیکربندی‌شده ندارد، اما حذف یک زیرشبکه پیامدهای خاصی به همراه دارد که مدیر سرور باید از آن‌ها آگاه باشد.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس در: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-del را ببینید <#command-subnet4-del>
نحو دستور:
0.0
3.5
{
"command": "subnet4-del",
"arguments": {
"id": 123
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet 192.0.2.0/24 (id 123) deleted",
"arguments": {
"subnets": [
{
"id": 123,
"subnet": "192.0.2.0/24"
}
]
}
}
168u
168u
نتیجه، یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارت‌اند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تعارض (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تعارض بود)
این دستور بخش‌هایی از یک زیرشبکه منفرد را در پیکربندی موجود سرور به‌روزرسانی (اضافه یا رونویسی) می‌کند. این عملیات تأثیری بر سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 2.1.7 (کتابخانه هوک subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-delta-add را ببینید <#command-subnet4-delta-add>
نحو دستور:
0.0
3.5
{
"command": "subnet4-delta-add",
"arguments": {
"subnet4": [ {
"id": 123,
"subnet": "10.20.30.0/24",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet updated",
"arguments": {
"subnets": [
{
"id": 123,
"subnet": "10.20.30.0/24"
}
]
}
}
168u
168u
نتیجه، نمایشی از وضعیت به‌صورت یک عدد صحیح است. وضعیت‌های پشتیبانی‌شده کنونی عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور تداخل داشتند)
168u
subnet4-delta-del
این دستور بخش‌هایی از یک زیرشبکه منفرد را در پیکربندی موجود سرور به‌روزرسانی (حذف) می‌کند. این عملیات تأثیری بر سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp4
دسترس‌پذیری: 2.1.7 (کتابخانه هوک subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-delta-del را ببینید <#command-subnet4-delta-del>
نحو دستور:
0.0
3.5
{
"command": "subnet4-delta-del",
"arguments": {
"subnet4": [ {
"id": 123,
"subnet": "10.20.30.0/24",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet updated",
"arguments": {
"subnets": [
{
"id": 123,
"subnet": "10.20.30.0/24"
}
]
}
}
168u
168u
نتیجه، نمایشی از وضعیت به‌صورت یک عدد صحیح است. وضعیت‌های پشتیبانی‌شده کنونی عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای تغییر نکرد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور تداخل داشتند)
این دستور اطلاعات دقیق درباره زیرشبکه (subnet) مشخص‌شده را بازیابی می‌کند. این دستور معمولاً پس از subnet4-list اجرا می‌شود که زیرشبکه‌های موجود را به همراه شناسه‌ها و پیشوندهای زیرشبکه مربوط به هرکدام شناسایی می‌کند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: خواندن (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-get را ببینید <#command-subnet4-get>
نحو دستور:
0.0
3.5
{
"command": "subnet4-get",
"arguments": {
"id": 10
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "Info about IPv4 subnet 10.0.0.0/8 (id 10) returned",
"arguments": {
"subnets": [
{
"subnet": "10.0.0.0/8",
"id": 1,
"option-data": [{
...
}],
...
}
]
}
}
168u
168u
نتیجه (result) یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت‌آمیز (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty): دستور با موفقیت انجام شد، اما هیچ داده‌ای تغییر نیافت یا بازگردانده نشد
• 2
4 - تداخل (conflict): دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود
168u
subnet4-list
این دستور تمام زیرشبکه‌هایی را که در حال حاضر پیکربندی شده‌اند فهرست می‌کند. زیرشبکه‌ها در قالبی خلاصه بازگردانده می‌شوند؛ یعنی برای هر زیرشبکه، شناسه زیرشبکه، پیشوند زیرشبکه، و نام شبکه مشترک (در صورت وجود) گنجانده شده است.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: خواندن (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-list را ببینید <#command-subnet4-list>
نحو دستور:
0.0
3.5
{
"command": "subnet4-list"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 IPv4 subnets found",
"arguments": {
"subnets": [
{
"id": 10,
"subnet": "10.0.0.0/8"
},
{
"id": 100,
"subnet": "192.0.2.0/24",
"shared-network-name": "example-shared-network"
}
]
}
}
168u
168u
اگر هیچ زیرشبکه IPv4 یافت نشود، یک کد خطا به همراه توضیحات خطا بازگردانده می‌شود.
subnet4-select-test
این دستور نتیجه انتخاب زیرشبکه DHCPv4 را بازمی‌گرداند.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 2.7.0 (توکار - built-in)
دسترسی: خواندن (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-select-test را ببینید <#command-subnet4-select-test>
نحو دستور:
0.0
3.5
{
"command": "subnet4-select-test",
"arguments": {
"interface": <string>,
"address": <string>,
"relay": <string>,
"local": <string>,
"remote": <string>,
"link": <string>,
"subnet": <string>,
"classes": [ <strings> ]
}
}
168u
168u
پارامترهای ممکن عبارتند از نام رابط ورودی، نشانی کلاینت، نشانی رله (relay)، کلاس‌های کلاینت، و غیره.
نحو پاسخ:
0.0
3.5
{ "result": 1, "text": <localization result> }
168u
168u
۳ حالت برای شبکه مشترک انتخاب‌شده، زیرشبکه، یا هیچ‌چیز..SS subnet4-update
این دستور یک زیرشبکه تکی را در پیکربندی موجود سرور به‌روزرسانی (بازنویسی) می‌کند. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 1.6.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4-update را ببینید <#command-subnet4-update>
نحو دستور:
0.0
3.5
{
"command": "subnet4-update",
"arguments": {
"subnet4": [ {
"id": 123,
"subnet": "10.20.30.0/24",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv4 subnet updated",
"arguments": {
"subnets": [
{
"id": 123,
"subnet": "10.20.30.0/24"
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
168u
subnet4o6-select-test
این دستور نتیجه انتخاب زیرشبکه DHCPv4o6 را برمی‌گرداند
پشتیبانی‌شده توسط: kea-dhcp4
در دسترس بودن: 2.7.0 (توکار built-in)
دسترسی: read (پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet4o6-select-test را ببینید <#command-subnet4o6-select-test>
نحو دستور:
0.0
3.5
{
"command": "subnet4o6-select-test",
"arguments": {
"interface": <string>,
"interface-id": <string>,
"address": <string>,
"relay": <string>,
"local": <string>,
"remote": <string>,
"link": <string>,
"subnet": <string>,
"classes": [ <strings> ]
}
}
168u
168u
پارامترهای ممکن عبارتند از: آدرس دوردست (remote address)، گزینه شناسه واسط (interface id option)، نام واسط (هر سه از سرور DHCPv6)، و غیره.
نحو پاسخ:
0.0
3.5
{ "result": 1, "text": <localization result> }
168u
168u
۳ حالت برای شبکه مشترک انتخاب‌شده، زیرشبکه یا هیچ‌چیز..
subnet6-add
این دستور یک زیرشبکه جدید را ایجاد کرده و به پیکربندی موجود سرور اضافه می‌کند. این عملیات هیچ اثری بر سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-add را ببینید <#command-subnet6-add>
نحو دستور:
0.0
3.5
{
"command": "subnet6-add",
"arguments": {
"subnet6": [ {
"id": 234,
"subnet": "2001:db8:1::/64",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet added",
"arguments": {
"subnets": [
{
"id": 234,
"subnet": "2001:db8:1::/64"
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت کامل شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بود)
این دستور یک زیرشبکه را از پیکربندی کارگزار حذف می‌کند. این دستور تأثیری بر سایر زیرشبکه‌های پیکربندی‌شده ندارد، اما حذف یک زیرشبکه پیامدهای خاصی به همراه دارد که مدیر سیستم کارگزار باید از آن‌ها آگاه باشد.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه قلاب subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-del را ببینید <#command-subnet6-del>
نحو دستور:
0.0
3.5
{
"command": "subnet6-del",
"arguments": {
"id": 234
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet 2001:db8:1::/64 (id 234) deleted",
"subnets": [
{
"id": 234,
"subnet": "2001:db8:1::/64"
}
]
}
168u
168u
نتیجه، نمایشی عددی (عدد صحیح) از وضعیت است. وضعیت‌های پشتیبانی‌شده فعلی عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بود)
168u
subnet6-delta-add
این دستور بخش‌هایی از یک زیرشبکه منفرد را در پیکربندی موجود کارگزار به‌روزرسانی (اضافه یا رونویسی) می‌کند. این عملیات هیچ تأثیری بر سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 2.1.7 (کتابخانه قلاب subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-delta-add را ببینید <#command-subnet6-delta-add>
نحو دستور:
0.0
3.5
{
"command": "subnet6-delta-add",
"arguments": {
"subnet6": [ {
"id": 234,
"subnet": "2001:db8:1::/64",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet updated",
"arguments": {
"subnets": [
{
"id": 234,
"subnet": "2001:db8:1::/64"
}
]
}
}
168u
168u
نتیجه، نمایشی عددی (عدد صحیح) از وضعیت است. وضعیت‌های پشتیبانی‌شده فعلی عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما هیچ داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارگزار در تداخل بود)
این دستور بخش‌هایی از یک زیرشبکهٔ منفرد را در پیکربندی موجود کارساز به‌روزرسانی (حذف) می‌کند. این عملیات هیچ اثری بر روی سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp6
دسترس‌پذیری: 2.1.7 (کتابخانهٔ قلاب subnet_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-delta-del را ببینید <#command-subnet6-delta-del>
نحو دستور:
0.0
3.5
{
"command": "subnet6-delta-del",
"arguments": {
"subnet6": [ {
"id": 234,
"subnet": "2001:db8:1::/64",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet updated",
"arguments": {
"subnets": [
{
"id": 234,
"subnet": "2001:db8:1::/64"
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای متأثر نشد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تداخل بود)
168u
subnet6-get
این دستور اطلاعات تفصیلی را دربارهٔ زیرشبکهٔ مشخص‌شده بازیابی می‌کند. این دستور معمولاً پس از subnet6-list می‌آید که زیرشبکه‌های موجود را به همراه شناسه‌ها و پیشوندهای مربوط به آن‌ها پیدا می‌کند.
پشتیبانی‌شده توسط: kea-dhcp6
دسترس‌پذیری: 1.3.0 (کتابخانهٔ قلاب subnet_cmds)
دسترسی: read (این پارامتر در این نسخه از Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-get را ببینید <#command-subnet6-get>
نحو دستور:
0.0
3.5
{
"command": "subnet6-get",
"arguments": {
"id": 11
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "Info about IPv6 subnet 2001:db8:1::/64 (id 11) returned",
"arguments": {
"subnets": [
{
"subnet": "2001:db8:1::/64",
"id": 1,
"option-data": [{
...
}],
...
}
]
}
}
168u
168u
نتیجه یک نمایش عدد صحیح از وضعیت است. وضعیت‌های پشتیبانی‌شده در حال حاضر عبارتند از:
0.0
• 2
0 - موفقیت
• 2
1 - خطا
• 2
2 - پشتیبانی‌نشده
• 2
3 - خالی (دستور با موفقیت کامل شد، اما هیچ داده‌ای متأثر نشد یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت کارساز در تداخل بود)
این دستور تمام زیرشبکه‌های پیکربندی‌شده فعلی را فهرست می‌کند. زیرشبکه‌ها در قالبی مختصر برگردانده می‌شوند، یعنی برای هر زیرشبکه یک شناسه زیرشبکه، پیشوند زیرشبکه، و نام شبکه اشتراکی گنجانده شده است.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.3.0 (کتابخانه هوک subnet_cmds)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-list را ببینید <#command-subnet6-list>
نحو دستور:
0.0
3.5
{
"command": "subnet6-list"
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "2 IPv6 subnets found",
"arguments": {
"subnets": [
{
"id": 11,
"subnet": "2001:db8:1::/64"
},
{
"id": 233,
"subnet": "3000::/16",
"shared-network-name": "example-shared-network"
}
]
}
}
168u
168u
اگر هیچ زیرشبکه IPv6ای یافت نشود، یک کد خطا همراه با توضیحات خطا برگردانده می‌شود.
subnet6-select-test
این دستور نتیجه انتخاب زیرشبکه DHCPv6 را برمی‌گرداند
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 2.7.0 (توکار)
دسترسی: read (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-select-test را ببینید <#command-subnet6-select-test>
نحو دستور:
0.0
3.5
{
"command": "subnet6-select-test",
"arguments": {
"interface": <string>,
"interface-id": <string>,
"remote": <string>,
"link": <string>,
"classes": [ <strings> ]
}
}
168u
168u
پارامترهای ممکن عبارتند از نام رابط ورودی، نشانی دوردست (remote address)، نشانی پیوند رله (relay link address)، کلاس‌های کلاینت، و غیره.
نحو پاسخ:
0.0
3.5
{ "result": 1, "text": <localization result> }
168u
168u
۳ حالت برای شبکه اشتراکی انتخاب‌شده، زیرشبکه، یا هیچ‌چیز..
subnet6-update
این دستور یک زیرشبکه تکی را در پیکربندی موجود سرور به‌روزرسانی (بازنویسی) می‌کند. این عملیات تاثیری بر سایر زیرشبکه‌ها ندارد.
پشتیبانی‌شده توسط: kea-dhcp6
در دسترس بودن: 1.6.0 (کتابخانه هوک subnet_cmds)
دسترسی: write (این پارامتر در این نسخه Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: دستور subnet6-update را ببینید <#command-subnet6-update>
نحو دستور:
0.0
3.5
{
"command": "subnet6-update",
"arguments": {
"subnet6": [ {
"id": 234,
"subnet": "2001:db8:1::/64",
...
} ]
}
}
168u
168u
نحو پاسخ:
0.0
3.5
{
"result": 0,
"text": "IPv6 subnet updated",
"arguments": {
"subnets": [
{
"id": 234,
"subnet": "2001:db8:1::/64"
}
]
}
}
168u
168u
نتیجه، نمایشی عددی از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (دستور با موفقیت انجام شد، اما داده‌ای تحت تأثیر قرار نگرفت یا بازگردانده نشد)
• 2
4 - تداخل (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور در تداخل بودند)
این دستور اطلاعات تفصیلی و تکمیلی را دربارهٔ نسخهٔ Kea در حال اجرا بازمی‌گرداند. رشتهٔ بازگردانده‌شده همانند حالتی است که Kea با گزینهٔ خط فرمان -V اجرا شده باشد.
پشتیبانی‌شده توسط: kea-dhcp-ddns، kea-dhcp4، kea-dhcp6
در دسترس بودن: 1.2.0 (داخلی)
دسترسی: read (این پارامتر در این نسخهٔ Kea نادیده گرفته می‌شود)
توضیحات و مثال‌ها: به دستور version-get در <#command-version-get> مراجعه کنید
ساختار دستور:
0.0
3.5
{
"command": "version-get"
}
168u
168u
ساختار پاسخ:
0.0
3.5
{
"result": <integer>,
"text": "<string>"
}
168u
168u
نتیجه (Result) یک نمایش عددی صحیح از وضعیت است. وضعیت‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:
0.0
• 2
0 - موفقیت (success)
• 2
1 - خطا (error)
• 2
2 - پشتیبانی‌نشده (unsupported)
• 2
3 - خالی (empty) (دستور با موفقیت به پایان رسید، اما هیچ داده‌ای تغییر نیافت یا برگردانده نشد)
• 2
4 - تداخل (conflict) (دستور نتوانست تغییرات پیکربندی درخواستی را اعمال کند زیرا با وضعیت سرور تداخل داشت)
168u
"صفحات راهنما (MANUAL PAGES)"
kea-dhcp4 - سرور DHCPv4 در Kea
"خلاصه دستور (SYNOPSIS)"
kea-dhcp4 [-v] [-V] [-W] [-d] [-c config-file] [-t config-file] [-p server-port-number] [-P client-port-number]
"توضیحات (DESCRIPTION)"
دیمن kea-dhcp4 پیاده‌سازی سرور DHCPv4 را فراهم می‌کند.
"آرگومان‌ها (ARGUMENTS)"
آرگومان‌ها به شرح زیر هستند:
0.0
-v
نسخهٔ Kea را نمایش می‌دهد.
-V
نسخهٔ تفصیلی Kea را نمایش می‌دهد.
-W
گزارش پیکربندی را نمایش می‌دهد.
-d
حالت اشکال‌زدایی (debug) را با پرگویی بیش‌تر فعال می‌کند.
-c config-file
فایل پیکربندی حاوی تنظیمات سرور DHCPv4 را مشخص می‌کند. این فایل همچنین ممکن است دربردارندهٔ ورودی‌های پیکربندی برای سایر سرویس‌های Kea نیز باشد.
-t config-file
فایل پیکربندی را بررسی کرده و نخستین خطا را (در صورت وجود) گزارش می‌کند. توجه داشته باشید که همهٔ پارامترها به‌طور کامل بررسی نمی‌شوند؛ به‌ویژه سوکت‌های سرویس و کانال کنترل باز نمی‌شوند و کتابخانه‌های hook بارگذاری نمی‌گردند.
-T config-file
فایل پیکربندی را بررسی کرده و نخستین خطا را (در صورت وجود) گزارش می‌کند. این گزینه بررسی‌های اضافی فراتر از آنچه -t ارائه می‌دهد انجام می‌دهد، از جمله برقراری اتصال‌های پایگاه‌داده (برای بک‌اند اجاره‌ها، بک‌اند رزروهای میزبان، بک‌اند پیکربندی، و بک‌اند ثبت وقایع قانونی [forensic logging])، بارگذاری کتابخانه‌های hook، تجزیهٔ پیکربندی‌های کتابخانهٔ hook و غیره. این گزینه سوکت‌های UNIX یا TCP/UDP را باز نمی‌کند و فایل‌ها را نیز باز نکرده یا بازچرخانی (rotate) نمی‌کند، زیرا هر یک از این اقدامات ممکن است با یک فرایند در حال اجرا روی همان ماشین تداخل پیدا کند.
-p server-port-number
شماره درگاه سرور (1-65535) را که سرور روی آن گوش می‌دهد مشخص می‌کند. این گزینه صرفاً برای اهداف آزمایشی کاربرد دارد.
-P client-port-number
شماره درگاه کلاینت (1-65535) را که سرور به آن پاسخ می‌دهد مشخص می‌کند. این گزینه صرفاً برای اهداف آزمایشی کاربرد دارد.
168u
"مستندات (DOCUMENTATION)"
نرم‌افزار Kea به همراه یک «کتابچهٔ راهنمای مرجع مدیر سیستم Kea» (Kea Administrator Reference Manual) جامع ارائه می‌شود که تمام جنبه‌های اجرای نرم‌افزار Kea - شامل کامپایل، نصب، پیکربندی، مثال‌های پیکربندی و موارد دیگر - را پوشش می‌دهد. همچنین Kea دارای یک «راهنمای پیام‌های Kea» (Kea Messages Manual) است که تمامی پیام‌های احتمالی را که Kea می‌تواند چاپ کند به همراه توضیحی کوتاه برای هر یک فهرست می‌نماید. هر دو سند در قالب‌های مختلف (.txt، .html، .pdf) به همراه توزیع Kea در دسترس هستند. مستندات Kea در https://kea.readthedocs.io در دسترس است.
کد منبع Kea در «راهنمای توسعه‌دهندهٔ Kea» (Kea Developer's Guide) مستندسازی شده و در https://reports.kea.isc.org/dev_guide در دسترس است.
وب‌سایت پروژهٔ Kea در https://kea.isc.org در دسترس است.
"فهرست‌های پستی و پشتیبانی (MAILING LISTS AND SUPPORT)"
دو فهرست پستی عمومی برای پروژهٔ Kea در دسترس است. فهرست kea-users (kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev (kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان آینده و دیگر کاربران پیشرفته اختصاص دارد. هر دو فهرست در https://lists.isc.org در دسترس هستند. جامعهٔ کاربری در هر دو فهرست پستی بر مبنای بهترین تلاش (best-effort) پشتیبانی ارائه می‌دهد.
شرکت ISC پشتیبانی حرفه‌ای برای سرویس‌های Kea ارائه می‌کند. برای جزئیات بیشتر به https://www.isc.org/kea مراجعه کنید..SS تاریخچه (HISTORY)
دیمن b10-dhcp4 نخستین‌بار در نوامبر ۲۰۱۱ توسط Tomek
Mrugalski کدنویسی شد.
در اواسط ۲۰۱۴، Kea از چارچوب BIND 10 جدا شد و به یک
سرور DHCP مستقل تبدیل گردید. باینری سرور DHCPv4 به
kea-dhcp4 تغییر نام یافت. نسخه Kea 1.0.0 در دسامبر ۲۰۱۵ منتشر شد.
همچنین ببینید (SEE ALSO)
kea-dhcp6(8), kea-dhcp-ddns(8),
kea-admin(8), keactrl(8),
perfdhcp(8), kea-netconf(8), kea-lfc(8),
Kea Administrator Reference Manual.
kea-dhcp6 - سرور DHCPv6 در Kea
خلاصه دستور (SYNOPSIS)
kea-dhcp6 [-v] [-V] [-W] [-d] [-c config-file] [-t config-file] [-p server-port-number] [-P client-port-number]
توضیحات (DESCRIPTION)
دیمن kea-dhcp6 پیاده‌سازی سرور DHCPv6 را ارائه می‌دهد.
آرگومان‌ها (ARGUMENTS)
آرگومان‌ها به شرح زیر هستند:
0.0
-v
نسخه Kea را نمایش می‌دهد.
-V
نسخه تفصیلی و گسترش‌یافته Kea را نمایش می‌دهد.
-W
گزارش پیکربندی را نمایش می‌دهد.
-d
حالت اشکال‌زدایی (debug) را با پرگویی بیشتر فعال می‌کند.
-c config-file
فایل پیکربندی حاوی تنظیمات سرور DHCPv6 را مشخص می‌کند. این فایل
همچنین ممکن است شامل مدخل‌های پیکربندی سایر سرویس‌های Kea نیز باشد.
-t config-file
فایل پیکربندی را بررسی کرده و در صورت وجود، نخستین خطا را گزارش می‌دهد. توجه
داشته باشید که تمامی پارامترها به‌طور کامل بررسی نمی‌شوند؛ به‌ویژه،
سوکت‌های سرویس و کانال کنترل باز نمی‌شوند و کتابخانه‌های هوک (hook)
بارگذاری نمی‌گردند.
-T config-file
فایل پیکربندی را بررسی کرده و در صورت وجود، نخستین خطا را گزارش می‌دهد.
این گزینه بررسی‌های بیشتری فراتر از آن‌چه -t ارائه می‌دهد انجام می‌دهد، مانند برقراری
اتصالات پایگاه داده (برای بک‌اند اجاره‌ها، بک‌اند رزرو میزبان‌ها،
بک‌اند پیکربندی و بک‌اند لاگ قانونی)، بارگذاری کتابخانه‌های هوک،
تجزیه پیکربندی کتابخانه‌های هوک و غیره. این گزینه سوکت‌های UNIX یا TCP/UDP را باز نمی‌کند و
فایل‌ها را نیز باز یا بازچرخانی (rotate) نمی‌کند، چرا که هر یک از این اقدامات می‌تواند با
یک فرایند در حال اجرا روی همان ماشین تداخل ایجاد کند.
-p server-port-number
شماره پورت سرور (۱-۶۵۵۳۵) را که سرور روی آن شنود می‌کند مشخص می‌سازد. این گزینه
صرفاً برای اهداف آزمایشی کاربرد دارد.
-P client-port-number
شماره پورت کلاینت (۱-۶۵۵۳۵) را که سرور به آن پاسخ می‌دهد مشخص می‌سازد. این گزینه
صرفاً برای اهداف آزمایشی کاربرد دارد.
168u
مستندات (DOCUMENTATION)
پروژه Kea همراه با یک راهنمای مرجع جامع مدیر سیستم (Kea Administrator Reference Manual) ارائه می‌شود که
تمامی جنبه‌های اجرای نرم‌افزار Kea - شامل کامپایل، نصب،
پیکربندی، نمونه‌های پیکربندی و موارد دیگر - را پوشش می‌دهد. همچنین Kea دارای یک
Kea Messages Manual است که تمام پیام‌های قابل چاپ توسط Kea را
به همراه توضیح مختصری برای هر یک فهرست می‌کند. هر دو سند
در قالب‌های گوناگون (.txt، .html، .pdf) همراه با توزیع Kea
در دسترس هستند. مستندات Kea در نشانی زیر در دسترس است:
https://kea.readthedocs.io.
کد منبع Kea در Kea Developer's Guide مستند شده است
که در نشانی زیر در دسترس قرار دارد:
https://reports.kea.isc.org/dev_guide.
وبگاه پروژه Kea در نشانی زیر در دسترس است:
https://kea.isc.org.
فهرست‌های پستی و پشتیبانی (MAILING LISTS AND SUPPORT)
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. kea-users
(kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev
(kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان
بالقوه و دیگر کاربران پیشرفته است. هر دو فهرست در
https://lists.isc.org در دسترس هستند. جامعه کاربری
پشتیبانی بر مبنای تمام تلاش (best-effort) را روی هر دوی این فهرست‌ها ارائه می‌دهد.
شرکت ISC پشتیبانی حرفه‌ای برای سرویس‌های Kea ارائه می‌کند. برای جزئیات به
https://www.isc.org/kea مراجعه کنید.
تاریخچه (HISTORY)
دیمن b10-dhcp6 نخستین‌بار در ژوئن ۲۰۱۱ توسط Tomek
Mrugalski کدنویسی شد.
در اواسط ۲۰۱۴، Kea از چارچوب BIND 10 جدا شد و به یک
سرور DHCP مستقل تبدیل گردید. باینری سرور DHCPv6 به
kea-dhcp6 تغییر نام یافت. نسخه Kea 1.0.0 در دسامبر ۲۰۱۵ منتشر شد.
همچنین ببینید (SEE ALSO)
kea-dhcp4(8), kea-dhcp-ddns(8),
kea-admin(8), keactrl(8),
perfdhcp(8), kea-netconf(8), kea-lfc(8),
Kea Administrator Reference Manual.
keactrl - اسکریپت شل برای مدیریت Kea
خلاصه دستور (SYNOPSIS)
keactrl [command] [-c keactrl-config-file] [-s server[,server,...]] [-v]
توضیحات (DESCRIPTION)
ابزار keactrl یک اسکریپت شل است که راه‌اندازی، متوقف‌سازی و
پیکربندی مجدد سرورهای Kea (kea-dhcp4، kea-dhcp6،
kea-dhcp-ddns و kea-netconf) را کنترل می‌کند. این ابزار
همچنین روشی را برای بررسی وضعیت کنونی سرورها و
تعیین فایل‌های پیکربندیِ در حال استفاده فراهم می‌آورد.
فایل پیکربندی (CONFIGURATION FILE)
بسته به نیازمندی‌های کاربر، نیازی به اجرای تمامی سرورهای موجود نیست.
فایل پیکربندی keactrl مشخص می‌کند کدام سرورها فعال و کدام
غیرفعال هستند. به‌طور پیش‌فرض، فایل پیکربندی عبارت است از:
"[kea-install-dir]/etc/kea/keactrl.conf".
برای مستندات مربوط به پارامترهای موجود در فایل پیکربندی keactrl،
به Kea Administrator Reference Manual مراجعه کنید..SS "گزینه‌ها (OPTIONS)"
0.0
command
دستوری که باید برای کارسازها ارسال شود را مشخص می‌کند. می‌تواند یکی از موارد زیر باشد:
7.0
start
کارسازها را راه‌اندازی می‌کند.
stop
کارسازها را متوقف می‌کند.
reload
به کارسازها دستور می‌دهد که فایل پیکربندی Kea را دوباره بخوانند. این
دستور توسط عامل NETCONF پشتیبانی نمی‌شود.
status
وضعیت کارسازها را چاپ می‌کند.
168u
-c|--ctrl-config keactrl-config-file
فایل پیکربندی keactrl را مشخص می‌کند. بدون این سوئیچ،
keactrl از فایل
"[kea-install-dir]/etc/kea/keactrl.conf" استفاده می‌کند.
-s|--server server[,server,...]
زیرمجموعه‌ای از کارسازهای فعال را که دستور باید برای آن‌ها صادر
شود مشخص می‌کند. فهرست کارسازها باید با کاما و بدون فاصله
جدا شود. مقادیر قابل قبول عبارتند از:
7.0
dhcp4
کارساز DHCPv4 (kea-dhcp4).
dhcp6
کارساز DHCPv6 (kea-dhcp6).
dhcp_ddns
کارساز DHCP DDNS (kea-dhcp-ddns).
netconf
عامل NETCONF (kea-netconf).
all
تمام کارسازها، از جمله NETCONF در صورتی که برای ساخت پیکربندی
شده باشد. این مقدار پیش‌فرض است.
168u
-v|--version
نسخه Kea را نمایش می‌دهد.
-V
نسخه تفصیلی Kea را نمایش می‌دهد.
168u
"مستندات (DOCUMENTATION)"
نرم‌افزار Kea همراه با یک راهنمای جامع مرجع مدیر سیستم Kea (Kea Administrator Reference Manual) ارائه می‌شود که
تمام جنبه‌های اجرای نرم‌افزار Kea - کامپایل، نصب،
پیکربندی، مثال‌های پیکربندی و موارد بسیار دیگر - را پوشش می‌دهد. همچنین Kea دارای یک
راهنمای پیام‌های Kea (Kea Messages Manual) است که تمامی پیام‌های احتمالی که Kea می‌تواند چاپ کند
را با شرح کوتاهی برای هر یک فهرست می‌کند. هر دو سند
در قالب‌های گوناگون (.txt ،.html ،.pdf) همراه با توزیع Kea
در دسترس هستند. مستندات Kea در
https://kea.readthedocs.io در دسترس است.
کد منبع Kea در راهنمای توسعه‌دهندگان Kea (Kea Developer's Guide) مستندسازی شده است،
که در https://reports.kea.isc.org/dev_guide در دسترس است.
وبگاه پروژه Kea در https://kea.isc.org در دسترس است.
"فهرست‌های پستی و پشتیبانی (MAILING LISTS AND SUPPORT)"
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. kea-users
(kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev
(kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان بالقوه
و دیگر کاربران پیشرفته در نظر گرفته شده است. هر دو فهرست در
https://lists.isc.org در دسترس هستند. جامعه کاربری بیشترین
تلاش خود را برای پشتیبانی روی هر دوی این فهرست‌ها ارائه می‌دهد.
سازمان ISC پشتیبانی حرفه‌ای برای خدمات Kea ارائه می‌دهد. برای جزئیات به
https://www.isc.org/kea مراجعه کنید.
"همچنین ببینید (SEE ALSO)"
kea-dhcp4(8), kea-dhcp6(8), kea-dhcp-ddns(8),
kea-admin(8), kea-netconf(8),
perfdhcp(8), kea-lfc(8), Kea Administrator Reference Manual.
"kea-admin - اسکریپت شل برای مدیریت پایگاه‌های داده Kea"
"خلاصه دستور (SYNOPSIS)"
kea-admin [command] [backend] [-h database_host]
[-P database_port] [-u database_username]
[-p [database_password]] [-n database_name] [-d script_directory]
[-v] [-x extra_argument [-x extra_argument ...]]
[-4 | -6] [-i input_file] [-o output_file] [-y]
"توضیحات (DESCRIPTION)"
دستور kea-admin یک اسکریپت شل است که امکانات نگهداری پایگاه داده را ارائه می‌دهد.
به طور ویژه، قابلیت‌های مقداردهی اولیه پایگاه داده، بررسی نسخه پایگاه داده،
و ارتقای طرحواره پایگاه داده را فراهم می‌کند.
"آرگومان‌ها (ARGUMENTS)"
0.0
command
دستوری که باید برای کارسازها ارسال شود را مشخص می‌کند. می‌تواند یکی از
موارد زیر باشد:
7.0
db-init
یک طرحواره جدید برای پایگاه داده مقداردهی اولیه می‌کند. این ویژگی هنگام نصب
جدید Kea مفید است. پایگاه داده به جدیدترین نسخه‌ای که توسط نسخه نرم‌افزار
در حال نصب پشتیبانی می‌شود، مقداردهی اولیه می‌گردد.
db-version
شماره نسخه بک‌اند پایگاه داده را گزارش می‌دهد. این شماره لزوماً با
شماره نسخه Kea برابر نیست، زیرا هر بک‌اند طرح نسخه‌گذاری
مخصوص به خود را دارد.
db-upgrade
ارتقای طرحواره پایگاه داده را انجام می‌دهد. این ویژگی هنگام ارتقای Kea مفید است.
lease-dump
محتوای پایگاه داده اجاره‌ها (برای بک‌اندهای MySQL یا
PostgreSQL) را در یک فایل متنی CSV (مقادیر جداشده با کاما) تخلیه (dump) می‌کند. (پشتیبانی
از بک‌اند Cassandra منسوخ شده است.)
خط نخست فایل شامل نام ستون‌ها است. این کار می‌تواند به عنوان روشی برای
تغییر بک‌اند پایگاه داده به بک‌اند memfile به کار رود.
همچنین می‌تواند به عنوان یک ابزار عیب‌یابی استفاده شود، زیرا قالبی قابل حمل
از داده‌های اجاره را ارائه می‌دهد. آرگومان‌های اجباری دیگری نیز وجود دارند که باید
همراه با این دستور استفاده شوند: یا -4 یا -6 باید
مشخص شود، و یا -o یا --output باید ارائه گردد.
lease-upload
اجاره‌ها را از یک فایل متنی CSV (مقادیر جداشده با کاما) درون پایگاه داده اجاره
MySQL یا PostgreSQL بارگذاری می‌کند. فایل CSV باید در قالب memfile باشد.
آرگومان‌های اجباری دیگری نیز وجود دارند که باید همراه با این
دستور استفاده شوند: یا -4 یا -6 باید مشخص شود،
و یا -i یا --input باید ارائه گردد.
stats-recount
آمار اجاره‌ها را برای یک پایگاه داده MySQL یا PostgreSQL بازشماری می‌کند.
168u
backend
نوع بک‌اند را مشخص می‌کند. بک‌اندهای مجاز در حال حاضر عبارتند از: memfile،
mysql و pgsql؛ گزینه cql منسوخ شده است.
-h|--host hostname
نام میزبان را هنگام اتصال به پایگاه داده مشخص می‌کند.
مقدار پیش‌فرض localhost است.
-i|--input input_file
فایل متنی CSV (مقادیر جداشده با کاما) حاوی اجاره‌های مورد نظر برای بارگذاری را مشخص می‌کند؛
برای lease-upload الزامی است.
-P|--port port
درگاه را هنگام اتصال به پایگاه داده مشخص می‌کند. در صورت عدم تعیین،
مقدار پیش‌فرضی که توسط کلاینت پایگاه داده انتخاب می‌شود استفاده خواهد شد.
-u|--user username
نام کاربری را هنگام اتصال به پایگاه داده مشخص می‌کند.
مقدار پیش‌فرض keatest است.
-p|--password password
گذرواژه را هنگام اتصال به پایگاه داده مشخص می‌کند.
اگر تنها -p یا --password داده شود، گذرواژه از کاربر پرسیده می‌شود.
اگر اصلاً مشخص نشود، متغیر محیطی KEA_ADMIN_DB_PASSWORD
بررسی شده و در صورت وجود استفاده می‌شود.
در غیر این صورت از مقدار پیش‌فرض 1234 استفاده می‌گردد.
-n|--name database-name
نام پایگاه داده جهت اتصال را مشخص می‌کند.
مقدار پیش‌فرض keatest است.
-d|--directory script-directory
دایرکتوری اسکریپت‌های جایگزین را مشخص می‌کند. این اسکریپت در طول
ارتقاها، مقداردهی اولیه پایگاه داده و احتمالاً سایر عملیات استفاده می‌شود.
مقدار پیش‌فرض (prefix)/share/kea/scripts/ است.
-o|--output output_file
فایلی را که داده‌های اجاره در آن تخلیه خواهد شد، مشخص می‌کند. برای
lease-dump الزامی است.
-v|--version
نسخه Kea را نمایش می‌دهد.
-V
نسخه تفصیلی Kea را نمایش می‌دهد.
-4
به kea-admin دستور می‌دهد تا اجاره‌های DHCPv4 را تخلیه کند (lease-dump). با
گزینه -6 ناسازگار است.
-6
به kea-admin دستور می‌دهد تا اجاره‌های DHCPv6 را تخلیه کند (lease-dump). با
گزینه -4 ناسازگار است.
-x|--extra
یک آرگومان اضافی را برای ارسال به ابزار دستور پایگاه داده مشخص می‌کند؛ به عنوان مثال
برای فراخوانی mysql با آرگومان --ssl. این گزینه می‌تواند تکرار شود
تا بیش از یک آرگومان ارسال گردد. نقل‌قول‌ها حفظ نمی‌شوند. از دستورات
حاوی فاصله خودداری کنید..TP
-y|--yes
هنگام بازنویسی فایل‌های موقت، پاسخ مثبت (yes) را فرض می‌کند.
168u
"مستندات (DOCUMENTATION)"
نرم‌افزار Kea همراه با یک «راهنمای مرجع مدیر سیستم Kea» (Kea Administrator Reference Manual) جامع ارائه می‌شود که تمام جنبه‌های اجرای نرم‌افزار Kea از جمله کامپایل، نصب، پیکربندی، مثال‌های پیکربندی و بسیاری موارد دیگر را پوشش می‌دهد. همچنین Kea شامل یک «راهنمای پیام‌های Kea» (Kea Messages Manual) است که تمام پیام‌های احتمالی قابل چاپ توسط Kea را به همراه شرحی مختصر از هر یک فهرست می‌کند. هر دو سند در قالب‌های مختلف (.txt، .html، .pdf) به همراه توزیع Kea در دسترس هستند. مستندات Kea در نشانی زیر در دسترس است:
https://kea.readthedocs.io.
کد منبع Kea در «راهنمای توسعه‌دهنده Kea» (Kea Developer's Guide) مستندسازی شده است که در نشانی زیر قابل مشاهده است:
https://reports.kea.isc.org/dev_guide.
وب‌سایت پروژه Kea در نشانی زیر در دسترس است:
https://kea.isc.org.
"فهرست‌های پستی و پشتیبانی (Mailing Lists and Support)"
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. فهرست پستی kea-users (kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev (kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان بالقوه و دیگر کاربران پیشرفته در نظر گرفته شده است. هر دو فهرست در https://lists.isc.org در دسترس هستند. جامعه کاربری بیشترین تلاش خود را برای ارائه پشتیبانی در هر دو فهرست به کار می‌گیرد.
مجموعه ISC پشتیبانی تجاری و حرفه‌ای برای سرویس‌های Kea ارائه می‌کند. برای جزئیات به https://www.isc.org/kea مراجعه کنید.
"همچنین ببینید (SEE ALSO)"
kea-dhcp4(8), kea-dhcp6(8),
kea-dhcp-ddns(8),
keactrl(8), perfdhcp(8), kea-netconf(8),
Kea Administrator Reference Manual.
"kea-dhcp-ddns - فرآیند DHCP-DDNS در Kea"
"خلاصه دستور (SYNOPSIS)"
kea-dhcp-ddns [-v] [-V] [-W] [-d] [-c config-file] [-t config-file]
"توضیحات (DESCRIPTION)"
فرآیند سرویس kea-dhcp-ddns بر اساس رویدادهای تغییر اجاره (lease) در DHCP، درخواست به‌روزرسانی نگاشت DNS را ارسال می‌کند. این فرآیند به عنوان یک پردازهٔ مجزا اجرا می‌شود که انتظار دارد درخواست‌های تغییر نام (Name Change Requests) را از سرورهای Kea DHCP دریافت کند.
"آرگومان‌ها (ARGUMENTS)"
آرگومان‌ها به شرح زیر هستند:
0.0
-v
نسخه Kea را نمایش می‌دهد.
-V
نسخه گسترده Kea را نمایش می‌دهد.
-W
گزارش پیکربندی را نمایش می‌دهد.
-d
سطح ثبت گزارش (logging) را روی اشکال‌زدایی (debug) با جزئیات بیشتر تنظیم می‌کند. این گزینه اساساً برای مقاصد توسعه در حالت مستقل (stand-alone) کاربرد دارد.
-c config-file
فایل پیکربندی حاوی تنظیمات سرور DHCP-DDNS را مشخص می‌کند. این فایل ممکن است شامل ورودی‌های پیکربندی برای دیگر سرویس‌های Kea نیز باشد.
-t config-file
نحو (syntax) فایل پیکربندی را بررسی کرده و در صورت وجود، نخستین خطا را گزارش می‌دهد. توجه داشته باشید که همه پارامترها به‌طور کامل بررسی نمی‌شوند؛ به‌ویژه هیچ سوکت سرویسی باز نمی‌شود.
168u
"مستندات (DOCUMENTATION)"
نرم‌افزار Kea همراه با یک «راهنمای مرجع مدیر سیستم Kea» (Kea Administrator Reference Manual) جامع ارائه می‌شود که تمام جنبه‌های اجرای نرم‌افزار Kea از جمله کامپایل، نصب، پیکربندی، مثال‌های پیکربندی و بسیاری موارد دیگر را پوشش می‌دهد. همچنین Kea شامل یک «راهنمای پیام‌های Kea» (Kea Messages Manual) است که تمام پیام‌های احتمالی قابل چاپ توسط Kea را به همراه شرحی مختصر از هر یک فهرست می‌کند. هر دو سند در قالب‌های مختلف (.txt، .html، .pdf) به همراه توزیع Kea در دسترس هستند. مستندات Kea در نشانی زیر در دسترس است:
https://kea.readthedocs.io.
کد منبع Kea در «راهنمای توسعه‌دهنده Kea» (Kea Developer's Guide) مستندسازی شده است که در نشانی زیر قابل مشاهده است:
https://reports.kea.isc.org/dev_guide.
وب‌سایت پروژه Kea در نشانی زیر در دسترس است:
https://kea.isc.org.
"فهرست‌های پستی و پشتیبانی (Mailing Lists and Support)"
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. فهرست پستی kea-users (kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev (kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان بالقوه و دیگر کاربران پیشرفته در نظر گرفته شده است. هر دو فهرست در https://lists.isc.org در دسترس هستند. جامعه کاربری بیشترین تلاش خود را برای ارائه پشتیبانی در هر دو فهرست به کار می‌گیرد.
مجموعه ISC پشتیبانی تجاری و حرفه‌ای برای سرویس‌های Kea ارائه می‌کند. برای جزئیات به https://www.isc.org/kea مراجعه کنید.
"تاریخچه (HISTORY)"
فرآیند b10-dhcp-ddns نخستین بار در مه ۲۰۱۳ توسط Thomas Markwalder برنامه‌نویسی شد.
پروژه Kea به یک سرور مستقل تبدیل شد و چارچوب BIND 10 حذف گردید. باینری سرور DHCP-DDNS در ژوئیه ۲۰۱۴ به kea-dhcp-ddns تغییر نام یافت. نسخه Kea 1.0.0 در دسامبر ۲۰۱۵ منتشر شد.
"همچنین ببینید (SEE ALSO)"
kea-dhcp4(8), kea-dhcp6(8),
kea-admin(8), keactrl(8),
perfdhcp(8), kea-netconf(8), kea-lfc(8),
Kea Administrator Reference Manual.
"kea-lfc - فرآیند پاک‌سازی فایل اجاره در Kea"
"خلاصه دستور (SYNOPSIS)"
kea-lfc [-4**|-6**] [-c config-file] [-p pid-file] [-x previous-file] [-i copy-file] [-o output-file] [-f finish-file] [-v] [-V] [-W] [-d] [-h]
"توضیحات (DESCRIPTION)"
فرآیند سرویس kea-lfc اطلاعات زائد و تکراری را از فایل‌هایی که برای ذخیره‌سازی پایدار در بخش پشتی (backend) پایگاه‌داده memfile استفاده می‌شوند، حذف می‌کند. این سرویس به گونه‌ای نوشته شده است که به عنوان یک پردازه مستقل اجرا شود. اگرچه می‌توان آن را به صورت دستی و از خارج اجرا کرد، اما معمولاً نیازی به این کار نیست؛ این پردازه به صورت دوره‌ای توسط سرورهای Kea DHCP اجرا می‌شود..SS آرگومان‌ها
آرگومان‌ها به شرح زیر هستند:
0.0
-4 | -6
نسخه پروتکل فایل‌های اجاره (lease) را مشخص می‌کند؛ باید ۴ یا ۶ باشد.
-c config-file
فایل حاوی پیکربندی فرایند kea-lfc را مشخص می‌کند. این فایل همچنین ممکن است حاوی مدخل‌های پیکربندی برای دیگر سرویس‌های Kea باشد. در حال حاضر kea-lfc تمام آرگومان‌های خود را از خط فرمان دریافت می‌کند.
-p pid-file
فایل PID را مشخص می‌کند. هنگامی که فرایند kea-lfc آغاز می‌شود، با بررسی فایل PID تلاش می‌کند مشخص کند که آیا نمونه دیگری از این فرایند در حال اجرا است یا خیر. اگر نمونه‌ای در حال اجرا باشد، فرایند جدید متوقف می‌شود. اگر نمونه‌ای در حال اجرا نباشد، Kea شناسه PID خود را درون فایل PID می‌نویسد.
-x previous-file
فایل اجاره قبلی یا پیشین را مشخص می‌کند. هنگامی که kea-lfc آغاز می‌شود، این فایل نتیجه هر اجرای قبلی kea-lfc است؛ هنگامی که kea-lfc به پایان می‌رسد، نتیجه اجرای فعلی خواهد بود. اگر اجرای kea-lfc پیش از تکمیل قطع شود، این فایل ممکن است وجود نداشته باشد.
-i copy-file
فایل ورودی یا رونوشت فایل اجاره را مشخص می‌کند. پیش از آنکه سرور DHCP فرایند kea-lfc را فراخوانی کند، فایل اجاره فعلی را به اینجا منتقل کرده و سپس kea-lfc را با این فایل فراخوانی می‌کند.
-o output-file
فایل خروجی اجاره را مشخص می‌کند که فایل موقتی است که kea-lfc باید برای نوشتن اجاره‌ها استفاده کند. پس از پایان نوشتن این فایل، به فایل پایان منتقل می‌شود (پایین را ببینید).
-f finish-file
فایل پایان یا تکمیل را مشخص می‌کند، فایل موقت دیگری که kea-lfc برای ثبت سوابق استفاده می‌کند. هنگامی که kea-lfc نوشتن فایل خروجی را به پایان رساند، آن را به این نام فایل منتقل می‌کند. پس از اینکه kea-lfc حذف فایل‌های دیگر (قبلی و ورودی) را به پایان برد، این فایل را به فایل اجاره قبلی منتقل می‌کند. با انتقال فایل‌ها به این روش، فرایندهای kea-lfc و سرور DHCP می‌توانند فایل صحیح را برای استفاده تعیین کنند، حتی اگر یکی از فرایندها پیش از تکمیل وظیفه خود متوقف شده باشد.
-v
نسخه Kea را نمایش می‌دهد.
-V
نسخه توسعه‌یافته Kea را نمایش می‌دهد.
-W
گزارش پیکربندی را نمایش می‌دهد.
-d
سطح ثبت گزارش (logging) را روی اشکال‌زدایی (debug) با پرگویی بیشتر تنظیم می‌کند. این گزینه اساساً برای مقاصد توسعه در حالت مستقل (stand-alone) است.
-h
باعث چاپ رشته راهنمای نحوه استفاده می‌شود.
168u
مستندات
نرم‌افزار Kea همراه با یک راهنمای مرجع جامع مدیر سیستم Kea (با عنوان Kea Administrator Reference Manual) ارائه می‌شود که تمام جنبه‌های اجرای نرم‌افزار Kea شامل کامپایل، نصب، پیکربندی، مثال‌های پیکربندی و موارد دیگر را پوشش می‌دهد. همچنین Kea دارای راهنمای پیام‌های Kea (با عنوان Kea Messages Manual) است که تمام پیام‌های ممکنی را که Kea می‌تواند چاپ کند، با شرح مختصری برای هر یک فهرست می‌کند. هر دو سند در قالب‌های مختلف (.txt، .html، .pdf) همراه با توزیع Kea در دسترس هستند. مستندات Kea در
https://kea.readthedocs.io
در دسترس است.
کد منبع Kea در راهنمای توسعه‌دهنده Kea (با عنوان Kea Developer's Guide) مستندسازی شده است که در
https://reports.kea.isc.org/dev_guide
در دسترس است.
وب‌سایت پروژه Kea در https://kea.isc.org در دسترس است.
فهرست‌های پستی و پشتیبانی
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. kea-users
(kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev
(kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان احتمالی و سایر کاربران پیشرفته در نظر گرفته شده است. هر دو فهرست در
https://lists.isc.org در دسترس هستند. جامعه کاربری در هر دو فهرست پستی مذکور، پشتیبانی را به بهترین نحو ممکن (best-effort) ارائه می‌دهد.
مجموعه ISC پشتیبانی حرفه‌ای برای سرویس‌های Kea ارائه می‌دهد. برای جزئیات به
https://www.isc.org/kea مراجعه کنید.
تاریخچه
فرایند kea-lfc نخستین بار در ژانویه ۲۰۱۵ توسط تیم Kea/DHCP در ISC کدنویسی شد.
"همچنین ببینید (SEE ALSO)"
kea-dhcp4(8)، kea-dhcp6(8)، kea-dhcp-ddns(8)،
kea-admin(8)، keactrl(8)،
perfdhcp(8)، kea-netconf(8)، راهنمای مرجع مدیر سیستم Kea.
kea-shell - کلاینت متنی برای سرورهای kea-dhcp4، kea-dhcp6 و kea-dhcp-ddns
"خلاصه دستور (SYNOPSIS)"
kea-shell [-h] [-v] [--host] [--port] [--path] [--ca] [--cert] [--key] [--auth-user] [--auth-password] [--auth-password-file] [--timeout] [--service] [command]
"توضیحات (DESCRIPTION)"
ابزار kea-shell یک کلاینت REST برای سرورهای kea-dhcp4،
kea-dhcp6 و kea-dhcp-ddns در Kea فراهم می‌کند. پیش‌تر این ابزار
برای دیمن Control Agent (CA) در نظر گرفته شده بود که اکنون منسوخ (حذف) شده است.
این ابزار دستورها را به عنوان یک پارامتر خط فرمان دریافت کرده و با کپسوله‌سازی مناسب JSON
به سرور Kea ارسال می‌کند. آرگومان‌های اختیاری ممکن است در ورودی استاندارد مشخص شوند.
درخواست از طریق HTTP ارسال شده و پاسخ دریافت و در خروجی استاندارد نمایش داده می‌شود.
احراز هویت پایه‌ای HTTP و HTTPS (یعنی انتقال با امنیت TLS) پشتیبانی می‌شوند.
آرگومان‌ها
آرگومان‌ها به شرح زیر هستند:
0.0
-h
راهنمای مربوط به پارامترهای خط فرمان را نمایش می‌دهد.
-v
نسخه Kea را نمایش می‌دهد.
--host
میزبانی را که باید به آن متصل شد مشخص می‌کند. سرور Kea باید روی میزبان مشخص‌شده در حال اجرا باشد. در صورت مشخص نشدن، از 127.0.0.1 استفاده می‌شود.
--port
درگاه (پورت) TCP را برای اتصال مشخص می‌کند. سرور باید روی درگاه مشخص‌شده در حال شنود باشد. در صورت مشخص نشدن، از 8000 استفاده می‌شود.
--path
مسیر موجود در URL را برای اتصال مشخص می‌کند. در صورت عدم تعیین، از مسیر خالی استفاده می‌شود. از آنجا که سرورهای Kea روی مسیر خالی شنود می‌کنند، این پارامتر تنها همراه با یک پراکسی معکوس (reverse proxy) مفید است.
--ca
نام فایل یا دایرکتوری مرجع صدور گواهی (Certification Authority) را مشخص می‌کند. اگر مشخص نشود، از HTTPS استفاده نمی‌شود.
--cert
نام فایل گواهی کلید عمومی موجودیت نهایی (end-entity) کاربر را مشخص می‌کند. در صورت مشخص شدن، نام فایل کلید کاربر نیز باید مشخص شود.
--key
نام فایل کلید کاربر را مشخص می‌کند. در صورت مشخص شدن، نام فایل گواهی کاربر نیز باید مشخص شود. فایل‌های کلید رمزگذاری‌شده پشتیبانی نمی‌شوند.
--auth-user
شناسه کاربری را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. در صورت عدم تعیین، یا تعیین به صورت یک رشته خالی، از احراز هویت استفاده نمی‌شود.
--auth-password
گذرواژه را برای احراز هویت پایه‌ای HTTP مشخص می‌کند. اگر مشخص نشود اما شناسه کاربری مشخص شده باشد، از گذرواژه خالی استفاده می‌شود. اگر همراه با --auth-password-file استفاده شود، نادیده گرفته می‌شود.
--auth-password-file
یک فایل متنی را مشخص می‌کند که سطر اول آن حاوی گذرواژه مورد استفاده برای احراز هویت پایه‌ای HTTP است. این پرچم بر پرچم --auth-password اولویت دارد.
--timeout
مهلت زمانی اتصال (timeout) را بر حسب ثانیه مشخص می‌کند. مقدار پیش‌فرض 10 است.
--service
(منسوخ) سرورهای Kea شامل kea-dhcp4، kea-dhcp6 و kea-dhcp-ddns این آرگومان را نادیده می‌گیرند. این گزینه برای ارتباط با دیمن منسوخ‌شده (حذف‌شده) Control Agent در نظر گرفته شده بود.
اگر با نسخه Kea قبل از 2.7.2 استفاده شود: سرویسی را که هدف یک دستور است مشخص می‌کند. اگر مشخص نشود، خود Control Agent هدف قرار می‌گیرد. ممکن است بیش از یک بار برای مشخص کردن چندین هدف استفاده شود.
command
دستوری را که باید به سرور ارسال شود مشخص می‌کند. در صورت مشخص نشدن، از list-commands استفاده می‌شود.
نرم‌افزار Kea همراه با «راهنمای مرجع مدیر سیستم Kea» (Kea Administrator Reference Manual) جامعی ارائه می‌شود که تمام جنبه‌های اجرای نرم‌افزار Kea - کامپایل، نصب، پیکربندی، مثال‌های پیکربندی و بسیاری موارد دیگر - را پوشش می‌دهد. Kea همچنین دارای یک «راهنمای پیام‌های Kea» (Kea Messages Manual) است که تمام پیام‌های ممکنی را که Kea می‌تواند چاپ کند با شرح مختصری برای هر یک فهرست می‌نماید. هر دو سند در قالب‌های مختلف (.txt، .html، .pdf) به همراه توزیع Kea در دسترس هستند. مستندات Kea در
https://kea.readthedocs.io در دسترس است.
کد منبع Kea در «راهنمای توسعه‌دهنده Kea» (Kea Developer's Guide) مستند شده است، که در https://reports.kea.isc.org/dev_guide در دسترس می‌باشد.
وبگاه پروژه Kea در https://kea.isc.org در دسترس است.
"فهرست‌های پستی و پشتیبانی (MAILING LISTS AND SUPPORT)"
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. kea-users
(kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev
(kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان بالقوه و سایر کاربران پیشرفته در نظر گرفته شده است. هر دو فهرست در
https://lists.isc.org در دسترس هستند. جامعه کاربری در هر دوی این فهرست‌ها پشتیبانی در حد توان (best-effort) ارائه می‌دهد.
سازمان ISC پشتیبانی حرفه‌ای برای خدمات Kea ارائه می‌دهد. برای جزئیات به
https://www.isc.org/kea مراجعه کنید.
"تاریخچه (HISTORY)"
ابزار kea-shell نخستین بار در مارس ۲۰۱۷ توسط Tomek Mrugalski نوشته شد.
"همچنین ببینید (SEE ALSO)"
kea-dhcp4(8)، kea-dhcp6(8)، kea-dhcp-ddns(8)،
kea-admin(8)، keactrl(8)،
perfdhcp(8)، kea-lfc(8)، راهنمای مرجع مدیر سیستم Kea (Kea Administrator Reference Manual).
"kea-netconf - عامل NETCONF برای پیکربندی Kea"
"خلاصه دستور (SYNOPSIS)"
kea-netconf [-v] [-V] [-W] [-d] [-c config-file] [-t config-file]
"توضیحات (DESCRIPTION)"
عامل kea-netconf یک رابط YANG/NETCONF برای محیط Kea فراهم می‌کند.
"آرگومان‌ها (ARGUMENTS)"
آرگومان‌ها به شرح زیر هستند:
0.0
-v
نسخه Kea را نمایش می‌دهد.
-V
نسخه گسترده Kea را نمایش می‌دهد.
-W
گزارش پیکربندی را نمایش می‌دهد.
-d
حالت اشکال‌زدایی (debug) را با پرگویی (verbosity) بیشتر فعال می‌کند.
-c config-file
فایل حاوی پیکربندی برای عامل NETCONF را مشخص می‌کند.
-t config-file
نحو (syntax) فایل پیکربندی را بررسی کرده و در صورت وجود، نخستین خطا را گزارش می‌کند. توجه داشته باشید که تمام پارامترها به‌طور کامل بررسی نمی‌شوند؛ به‌ویژه، سوکت‌های سرویس و کلاینت باز نمی‌شوند و کتابخانه‌های هوک (hook) بارگیری نمی‌گردند.
168u
"مستندات (DOCUMENTATION)"
نرم‌افزار Kea همراه با «راهنمای مرجع مدیر سیستم Kea» (Kea Administrator Reference Manual) جامعی ارائه می‌شود که تمام جنبه‌های اجرای نرم‌افزار Kea - کامپایل، نصب، پیکربندی، مثال‌های پیکربندی و بسیاری موارد دیگر - را پوشش می‌دهد. Kea همچنین دارای یک «راهنمای پیام‌های Kea» (Kea Messages Manual) است که تمام پیام‌های ممکنی را که Kea می‌تواند چاپ کند با شرح مختصری برای هر یک فهرست می‌نماید. هر دو سند در قالب‌های مختلف (.txt، .html، .pdf) به همراه توزیع Kea در دسترس هستند. مستندات Kea در
https://kea.readthedocs.io در دسترس است.
کد منبع Kea در «راهنمای توسعه‌دهنده Kea» (Kea Developer's Guide) مستند شده است، که در https://reports.kea.isc.org/dev_guide در دسترس می‌باشد.
وبگاه پروژه Kea در https://kea.isc.org در دسترس است.
"فهرست‌های پستی و پشتیبانی (MAILING LISTS AND SUPPORT)"
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. kea-users
(kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev
(kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان بالقوه و سایر کاربران پیشرفته در نظر گرفته شده است. هر دو فهرست در
https://lists.isc.org در دسترس هستند. جامعه کاربری در هر دوی این فهرست‌ها پشتیبانی در حد توان (best-effort) ارائه می‌دهد.
سازمان ISC پشتیبانی حرفه‌ای برای خدمات Kea ارائه می‌دهد. برای جزئیات به
https://www.isc.org/kea مراجعه کنید.
"تاریخچه (HISTORY)"
نمونه‌های اولیه پیاده‌سازی kea-netconf در طول هکاتون‌های IETF در برلین، لندن و مونترال نوشته شدند. پیاده‌سازی واقعی آماده برای محیط عملیاتی (production-ready) در اوت ۲۰۱۸ توسط Tomek Mrugalski و Francis Dupont آغاز شد.
"همچنین ببینید (SEE ALSO)"
kea-dhcp4(8)، kea-dhcp6(8)، kea-dhcp-ddns(8)،
kea-admin(8)، keactrl(8)،
perfdhcp(8)، kea-lfc(8)، راهنمای مرجع مدیر سیستم Kea (Kea Administrator Reference Manual).
"perfdhcp - ابزار سنجش کارایی و بنچمارک DHCP"
"خلاصه دستور (SYNOPSIS)"
perfdhcp [-1] [-4 | -6] [-A encapsulation-level] [-b base] [-B] [-c] [-C separator] [-d drop-time] [-D max-drop] [-e lease-type] [-E time-offset] [-f renew-rate] [-F release-rate] [-g thread-mode] [-h] [-i] [-I ip-offset] [-J remote-address-list-file] [-l local-address|interface] [-L local-port] [-M mac-list-file] [-n num-request] [-N remote-port] [-O random-offset] [-o code,hexstring] [--or encapsulation-level:code,hexstring] [-p test-period] [-P preload] [-r rate] [-R num-clients] [-s seed] [-S srvid-offset] [--scenario name] [-t report] [-T template-file] [-u] [-v] [-W exit-wait-time] [-w script_name] [-x diagnostic-selector] [-X xid-offset] [server]
"توضیحات (DESCRIPTION)"
ابزار perfdhcp یک ابزار محک‌زنی و ارزیابی کارایی (benchmarking) برای DHCP است. این ابزار با ایجاد حجم بالایی از ترافیک از چندین کلاینت شبیه‌سازی‌شده، روشی برای اندازه‌گیری کارایی سرورهای DHCP فراهم می‌کند. این ابزار قادر است هر دو سرور IPv4 و IPv6 را آزمایش کند و آمارهایی در رابطه با زمان‌های پاسخ‌دهی و تعداد درخواست‌های رهاشده (dropped) ارائه دهد.
این ابزار از دو سناریوی مختلف پشتیبانی می‌کند که امکان آزمایش رفتارهای خاصی را فراهم می‌سازند. به‌طور پیش‌فرض (سناریوی پایه یا basic)، آزمون‌ها با استفاده از توالی کامل تبادل چهار بسته‌ای (DORA برای DHCPv4 و SARR برای DHCPv6) اجرا می‌شوند. گزینه‌ای نیز برای اجرای آزمون‌ها با استفاده از تبادل دو بسته‌ای اولیه (DO و SA) به‌جای آن ارائه شده است. همچنین امکان پیکربندی perfdhcp برای ارسال پیام‌های RENEW و RELEASE مربوط به DHCPv6 با نرخ مشخص، به موازات تبادلات چهارطرفه DHCPv6 وجود دارد. به‌طور پیش‌فرض، اگر در مدت یک ثانیه پاسخی دریافت نشود، پاسخ به عنوان گم‌شده تلقی شده و perfdhcp با سایر تراکنش‌ها ادامه می‌دهد.
سناریوی دوم به نام avalanche (بهمن)، از طریق --scenario avalanche انتخاب می‌شود. این سناریو ابتدا تعداد پیام‌های Discovery یا Solicit مشخص‌شده توسط گزینه -R را ارسال می‌کند؛ سپس برای هر کلاینت شبیه‌سازی‌شده تا زمانی که به همه درخواست‌ها پاسخ داده شود، ارسال مجدد (با سازوکار عقب‌نشینی نمایی یا exponential back-off) انجام می‌شود. هنگامی که همه کلاینت‌ها نشانی‌های خود را دریافت کنند، یا زمانی که آزمون به‌صورت دستی متوقف شود، گزارشی تولید می‌کند. این سناریو تلاش می‌کند حالتی را بازسازی کند که در آن سرور قادر نیست ترافیک را به‌اندازه کافی سریع مدیریت کند. کلاینت‌های واقعی فرض خواهند کرد بسته یا پاسخ گم شده است و مجدداً ارسال می‌کنند، که این امر ترافیک DHCP را باز هم افزایش می‌دهد. این پدیده گاهی اثر بهمنی (avalanche effect) نامیده می‌شود، از این رو نام سناریو از آن گرفته شده است. گزینه -p در سناریوی avalanche نادیده گرفته می‌شود.
هنگام اجرای یک آزمون کارایی، perfdhcp بسته‌ها را با بیشترین سرعت ممکن با سرور تحت آزمون مبادله می‌کند، مگر اینکه از پارامتر -r برای محدود کردن نرخ درخواست‌ها استفاده شود. مدت‌زمان آزمون را می‌توان با تعیین آستانه‌ای بر روی هر یک یا همه مواردی چون تعداد درخواست‌های ارسال‌شده توسط perfdhcp، زمان سپری‌شده، یا تعداد درخواست‌های رهاشده توسط سرور محدود کرد..SS "الگوها (Templates)"
برای فراهم کردن امکان سفارشی‌سازی محتوای بسته‌های ارسالی به سرور،
perfdhcp امکان تعیین فایل‌های الگو را می‌دهد که محتوای بسته‌ها
را مشخص می‌کنند. برای نمونه، بسته سفارشی‌شده ممکن است شامل یک
DHCPv6 ORO برای درخواست مجموعه‌ای از گزینه‌ها جهت بازگردانی توسط
سرور باشد، یا ممکن است شامل گزینه Client FQDN باشد تا از سرور درخواست
انجام به‌روزرسانی‌های DNS را نماید. از این قابلیت می‌توان برای یافتن
گلوگاه‌های کارایی در پیکربندی‌های گوناگون سرور بهره برد (مانند DDNS فعال یا
غیرفعال).
حداکثر دو فایل الگو را می‌توان در خط فرمان مشخص کرد که هر فایل
نشان‌دهنده محتوای نوع خاصی از بسته است، و این نوع بر اساس آزمونی که
در حال اجراست تعیین می‌شود. به عنوان مثال، هنگام آزمایش DHCPv6:
0.0
• 2
اگر هیچ فایل الگویی در خط فرمان مشخص نشود، perfdhcp
هر دو بسته Solicit و Request را تولید می‌کند.
• 2
اگر یک فایل الگو مشخص شود، آن فایل به عنوان الگوی بسته‌های
Solicit استفاده می‌شود: perfdhcp بسته‌های Request را
تولید می‌کند.
• 2
اگر دو فایل الگو در خط فرمان داده شود، فایل نخست به عنوان الگو
برای بسته‌های Solicit و فایل دوم به عنوان الگو برای بسته‌های
Request استفاده می‌شود.
168u
(تصمیم‌گیری مشابهی برای بسته‌های DHCPDISCOVER و DHCPREQUEST در DHCPv4
اعمال می‌شود.)
فایل الگو بسته DHCP را نگه می‌دارد که به عنوان جریانی از ارقام هگزادسیمال
ASCII نمایش داده شده است؛ این فایل شامل هیچ‌یک از هدرهای پشته IP/UDP
نمی‌شود. فایل الگو نباید هیچ نویسه‌ای جز ارقام هگزادسیمال و فاصله‌ها
داشته باشد. فاصله‌ها هنگام تجزیه فایل الگو نادیده گرفته می‌شوند؛
درون فایل، 12B4 همانند 12 B4 و آن نیز همانند
1 2 B 4 است.
فایل‌های الگو باید همراه با پارامترهای خط فرمان استفاده شوند که
آفست‌های فیلدهای داده‌ای را مشخص می‌کنند که در بسته‌های خروجی دستخوش
تغییر می‌شوند. به عنوان مثال، سوییچ -E time-offset آفست
گزینه DHCPv6 Elapsed Time را در الگوی بسته مشخص می‌کند.
اگر آفست مشخص شود، perfdhcp پیش از ارسال بسته به سرور، مقدار
کنونی elapsed-time را در این فیلد تزریق می‌کند.
در بسیاری از سناریوها، perfdhcp نیاز دارد چندین کلاینت را شبیه‌سازی
کند که هر کدام شناسه کلاینت یکتایی دارند. از آنجا که بسته‌ها برای هر
کلاینت از همان فایل الگوی یکسان تولید می‌شوند، لازم است شناسه کلاینت
(یا آدرس سخت‌افزاری HW در DHCPv4) در بسته‌ای که از آن ایجاد می‌شود به صورت
تصادفی تغییر یابد. گزینه -O random-offset امکان تعیین آفست در
الگو را که تصادفی‌سازی باید در آنجا انجام گیرد فراهم می‌کند. مهم است که
توجه شود این آفست به انتهای (نه ابتدای) شناسه کلاینت (یا فیلد آدرس HW)
اشاره دارد. تعداد بایت‌هایی که تصادفی می‌شوند به تعداد کلاینت‌های
شبیه‌سازی‌شده بستگی دارد. اگر تعداد کلاینت‌های شبیه‌سازی‌شده بین ۱ تا ۲۵۵
باشد، تنها یک بایت (که آفست تصادفی‌سازی به آن اشاره دارد) تصادفی
می‌شود. اگر تعداد کلاینت‌های شبیه‌سازی‌شده بین ۲۵۶ تا ۶۵۵۳۵ باشد، دو
بایت تصادفی می‌شوند. توجه داشته باشید که در این حالت دو بایت پایانی
شناسه کلاینت تصادفی می‌شوند: بایتی که پارامتر آفست تصادفی‌سازی به آن
اشاره می‌کند و بایتی که پیش از آن قرار دارد (random-offset - 1). اگر
تعداد کلاینت‌های شبیه‌سازی‌شده از ۶۵۵۳۵ فراتر رود، سه بایت تصادفی
می‌شوند، و به همین ترتیب.
perfdhcp می‌تواند با فعال‌سازی گزینه -J و ارسال مسیر فایلی
حاوی آدرس‌های v4 یا v6 برای استفاده به عنوان رله (relay) در پیام‌های
تولیدشده، ترافیک را از چندین زیرشبکه (subnet) شبیه‌سازی کند. این کار
امکان آزمایش تعداد بسیار زیادی از شبکه‌های اشتراکی (shared networks)
در Kea را فراهم می‌سازد. هنگام آزمایش DHCPv4، برنامه Kea باید با متغیر
محیطی KEA_TEST_SEND_RESPONSES_TO_SOURCE راه‌اندازی شود تا Kea
مجبور شود پیام‌های تولیدشده را به آدرس مبدا بسته ورودی ارسال کند.
الگوها در حال حاضر می‌توانند برای تولید بسته‌هایی استفاده شوند که در
تبادلات چهارمرحله‌ای به سرور فرستاده می‌شوند، یعنی Solicit و Request
(در DHCPv6) و DHCPDISCOVER و DHCPREQUEST (در DHCPv4). از آن‌ها
نمی‌توان هنگام ارسال بسته‌های Renew یا DHCPRELEASE استفاده کرد.
"گزینه‌ها (Options)"
0.0
-1
گزینه server-id را از نخستین پیام دریافتی برمی‌دارد.
-4
عملکرد DHCPv4 را برقرار می‌سازد؛ این حالت پیش‌فرض است. با گزینه
-6 ناسازگار است.
-6
عملکرد DHCPv6 را برقرار می‌سازد. با گزینه -4 ناسازگار است.
-b basetype=value
آدرس MAC پایه یا DUID استفاده‌شده برای شبیه‌سازی کلاینت‌های گوناگون را
مشخص می‌کند. مقدار basetype می‌تواند "mac" یا "duid" باشد.
(همچنین می‌توان از کلیدواژه "ether" به عنوان جایگزین MAC استفاده
کرد.) گزینه -b می‌تواند چندین بار مشخص شود. آدرس MAC باید شامل
شش بایت (اکتت) باشد که با دونقطه تکی (:) یا دوتایی (::) جدا شده‌اند؛
به عنوان مثال: mac=00:0c:01:02:03:04. مقدار DUID یک رشته هگزادسیمال
است؛ طول آن باید حداقل شش بایت و نه بیشتر از ۶۴ بایت باشد، و طول آن باید
کمتر از ۱۲۸ رقم هگزادسیمال باشد. برای نمونه: duid=0101010101010101010110111F14.
-d drop-time
مدت زمانی را مشخص می‌کند که پس از آن یک درخواست به عنوان ازدست‌رفته
تلقی می‌شود. این مقدار بر حسب ثانیه داده می‌شود و می‌تواند شامل بخش
اعشاری باشد. مقدار پیش‌فرض 1 است.
-e lease-type
نوع اجاره (lease) درخواستی از سرور را مشخص می‌کند. می‌تواند یکی از
موارد زیر باشد:
7.0
address-only
تنها آدرس‌های معمولی (v4 یا v6) درخواست می‌شوند.
prefix-only
تنها پیشوندهای IPv6 درخواست می‌شوند.
address-and-prefix
هم آدرس‌ها و هم پیشوندهای IPv6 درخواست می‌شوند.
168u
حالت‌های -e prefix-only و -e address-and-prefix را
نمی‌توان با گزینه -4 استفاده کرد.
-F release-rate
نرخی را مشخص می‌کند که با آن، درخواست‌های DHCPv4 DHCPRELEASE یا
DHCPv6 Release به سرور فرستاده می‌شوند. این مقدار تنها زمانی معتبر است
که همراه با نرخ تبادل (ارائه‌شده با -r rate) به کار رود. علاوه
بر این، مجموع این مقدار و renew-rate (ارائه‌شده با -f rate)
باید برابر یا کمتر از مقدار نرخ تبادل باشد.
-f renew-rate
نرخی را مشخص می‌کند که با آن، درخواست‌های DHCPv4 DHCPREQUEST یا
DHCPv6 Renew به سرور فرستاده می‌شوند. این مقدار تنها زمانی معتبر است
که همراه با نرخ تبادل (ارائه‌شده با -r rate) به کار رود. علاوه
بر این، مجموع این مقدار و release-rate (ارائه‌شده با -F rate)
باید برابر یا کمتر از نرخ تبادل باشد.
-g thread-mode
امکان انتخاب thread-mode را می‌دهد که می‌تواند single یا multi
باشد. در حالت چندنخی (multi-thread)، بسته‌ها در یک رشته جداگانه دریافت
می‌شوند که بهره‌وری بهتری از پردازنده‌ها را ممکن می‌سازد. در یک سامانه با یک
پردازنده (single-CPU)، اجرای تک‌نخی بهتر است تا از مسدود کردن نخ‌ها توسط
یکدیگر جلوگیری شود. اگر بیش از یک پردازنده در سامانه موجود باشد، حالت
چندنخی پیش‌فرض است؛ در غیر این صورت، تک‌نخی پیش‌فرض خواهد بود.
-h
راهنما را چاپ کرده و خارج می‌شود.
-i
تنها بخش ابتدایی تبادل را انجام می‌دهد: DISCOVER-OFFER اگر -4
انتخاب شده باشد، و Solicit-Advertise اگر -6 برگزیده شده باشد.
گزینه -i با گزینه‌های زیر ناسازگار است: -1، -d،
-D، -E، -S، -I و -F. علاوه بر این،
نمی‌توان آن را با چندین نمونه از -O، -T و -X
به کار برد.
-J remote-address-list-file
یک فایل متنی شامل چندین آدرس را مشخص می‌کند که برای آزمایش شبکه‌های
اشتراکی طراحی شده است. در صورت ارائه، perfdhcp برای هر تبادل به
صورت تصادفی یکی از آدرس‌ها را انتخاب می‌کند تا ترافیک را از چندین زیرشبکه
تولید نماید. هنگام آزمایش DHCPv4، باید با متغیر محیطی
KEA_TEST_SEND_RESPONSES_TO_SOURCE=ENABLE راه‌اندازی شود؛ در
غیر این صورت، perfdhcp قادر به دریافت پاسخ‌ها نخواهد بود.
-l local-addr|interface
برای عملیات DHCPv4، نام میزبان/آدرس محلی را برای برقراری ارتباط با سرور
مشخص می‌کند. به طور پیش‌فرض، آدرس رابطی استفاده می‌شود که ترافیک به
طور عادی از طریق آن به سمت سرور مسیریابی می‌شود. برای عملیات DHCPv6،
نام رابط شبکه‌ای را مشخص می‌کند که تبادلات از طریق آن آغاز می‌گردند.
-L local-port
درگاه محلی برای استفاده را مشخص می‌کند. این مقدار باید صفر یا یک عدد
صحیح مثبت تا ۶۵۵۳۵ باشد. مقدار 0 (پیش‌فرض) به perfdhcp اجازه
می‌دهد تا درگاه خود را انتخاب کند.
-M mac-list-file
یک فایل متنی شامل فهرستی از آدرس‌های MAC را مشخص می‌کند که در هر خط
یک آدرس قرار دارد. در صورت ارائه، برای هر تبادل جدید یک آدرس MAC به
طور تصادفی از این فهرست برگزیده می‌شود. در DHCPv6، آدرس‌های MAC برای
تولید DUID-LL استفاده می‌شوند. این پارامتر نباید در کنار پارامتر
-b استفاده شود.
-N remote-port
درگاه راه دور برای استفاده را مشخص می‌کند. این مقدار باید صفر یا یک عدد
صحیح مثبت تا ۶۵۵۳۵ باشد. مقدار 0 (پیش‌فرض) به perfdhcp اجازه
می‌دهد تا درگاه استاندارد سرویس را انتخاب کند.
-o code,hexstring
برنامه perfdhcp را وادار می‌کند تا گزینه اضافی مشخص‌شده (یا در صورت
استفاده چندباره، گزینه‌ها) را در بسته‌های ارسالی بگنجاند. مقدار code شماره
گزینه را تعیین می‌کند و hexstring یک رشته هگزادسیمال است که محتوای
گزینه را تعریف می‌نماید. باید احتیاط شود، زیرا perfdhcp هیچ‌گونه
منطقی در پس گزینه‌ها ارائه نمی‌دهد؛ آن‌ها صرفاً درون بسته‌ها قرار گرفته
و همان‌طور که هستند ارسال می‌شوند. دقت کنید گزینه‌هایی را که پیش‌تر درج
شده‌اند دو بار اضافه نکنید. برای نمونه، جهت درج شناسه client-class
(کد گزینه 60) با رشته "docsis"، از -o 60,646f63736973
استفاده کنید. گزینه -o ممکن است چندین بار به کار رود. خانواده
پروتکل (-4 یا -6) باید پیش از استفاده از -o مشخص
شود.
-P preload
تبادلات پیش‌بارگذاری (preload) را در زمان راه‌اندازی به صورت پشت سر هم
(back-to-back) آغاز می‌کند. مقدار آن باید 0 (پیش‌فرض) یا یک عدد صحیح
مثبت باشد..TP
-r rate
نرخ تبادلات DORA/SARR (یا اگر -i داده شده باشد، DO/SA) در هر ثانیه را آغاز می‌کند. یک گزارش دوره‌ای تولید می‌شود که تعداد تبادلات تکمیل‌نشده و همچنین میانگین تأخیر پاسخ را نشان می‌دهد. برنامه تا زمان متوقف شدن ادامه می‌یابد، که در آن نقطه یک گزارش نهایی تولید می‌شود.
-R num-clients
مشخص می‌کند چند کلاینت مختلف مورد استفاده قرار می‌گیرند. با مقدار 1 (پیش‌فرض)، به نظر می‌رسد که تمام درخواست‌ها از یک کلاینت یکسان ارسال می‌شوند. باید یک عدد مثبت باشد.
-s seed
سید (seed) تصادفی‌سازی را مشخص می‌کند که باعث تکرارپذیر شدن اجراهای perfdhcp می‌شود. این مقدار باید 0 یا یک عدد صحیح مثبت باشد. مقدار 0 به این معنی است که از seed استفاده نمی‌شود؛ این مقدار پیش‌فرض است.
--scenario name
نوع سناریو را تعیین می‌کند و می‌تواند basic (پیش‌فرض) یا avalanche باشد.
-T template-file
فایلی حاوی الگوی مورد استفاده به‌صورت جریانی از ارقام هگزادسیمال را مشخص می‌کند. این گزینه می‌تواند تا دو بار مشخص شود و محتوای بسته‌های ارسالی را کنترل می‌کند (بخش "Templates" در بالا را ببینید).
-u
بررسی یکتایی آدرس را فعال می‌کند. مدت اعتبار اجاره (valid-lifetime) نباید کوتاه‌تر از مدت زمان آزمون باشد، و کلاینت‌ها نباید یک آدرس را بیش از یک بار بدون آزادسازی (release) آن درخواست کنند.
-v
نسخه Kea را نمایش می‌دهد.
-V
نسخه تفصیلی Kea را نمایش می‌دهد.
-W exit-wait-time
پارامتر exit-wait-time را تعیین می‌کند که باعث می‌شود perfdhcp پس از برآورده شدن شرایط خروج، مدت زمان معینی منتظر بماند تا تمام بسته‌ها بدون ارسال هیچ بسته جدیدی دریافت شوند. بر حسب میکروثانیه بیان می‌شود. در صورت عدم تعیین، از 0 استفاده می‌شود (یعنی بلافاصله پس از برآورده شدن شرایط خروج خارج شود).
-w script_name
نام اسکریپتی را که باید قبل/بعد از perfdhcp اجرا شود مشخص می‌کند. هنگام فراخوانی، یک پارامتر منفرد، یا "start" یا "stop"، به اسکریپت ارسال می‌شود که نشان می‌دهد قبل از perfdhcp فراخوانی شده است یا بعد از آن.
-x diagnostic-selector
اطلاعات عیب‌یابی تکمیلی را در خروجی می‌گنجاند. این یک رشته از کلیدواژه‌های تکی است که عملیات‌های مورد نظر برای دریافت خروجی پرجزئیات (verbose) را مشخص می‌کند. حروف کلیدی انتخابگر عبارتند از:
7.0
a
آرگومان‌های خط فرمان رمزگشایی‌شده را چاپ می‌کند.
e
دلیل خروج را چاپ می‌کند.
i
جزئیات پردازش نرخ را چاپ می‌کند.
l
اجاره‌های (lease) دریافتی را چاپ می‌کند.
s
شناسه اولین سرور (server ID) را چاپ می‌کند.
t
در پایان، زمان‌سنج‌های تمام تبادلات موفق را چاپ می‌کند.
T
در پایان، الگوها را چاپ می‌کند.
168u
-Y seconds
زمانی بر حسب ثانیه که پس از آن perfdhcp شروع به شبیه‌سازی انتظار طولانی‌تر کلاینت برای پاسخ‌های سرور می‌کند. این کار فیلد secs را در DHCPv4 افزایش می‌دهد و مقادیر افزایش‌یافته را در گزینه Elapsed Time در DHCPv6 ارسال می‌کند. باید همراه با -y استفاده شود.
-y seconds
مدت زمان بر حسب ثانیه که در طول آن perfdhcp شبیه‌سازی انتظار طولانی‌تر کلاینت برای پاسخ‌های سرور را انجام می‌دهد. این کار فیلد secs را در DHCPv4 افزایش می‌دهد و مقادیر افزایش‌یافته را در گزینه Elapsed Time در DHCPv6 ارسال می‌کند. باید همراه با -Y استفاده شود.
168u
گزینه‌های فقط DHCPv4 (DHCPv4-Only Options)
گزینه‌های زیر فقط برای DHCPv4 اعمال می‌شوند (یعنی زمانی که -4 داده شده باشد).
0.0
-B
مدیریت همه‌پخشی (broadcast) را اجبار می‌کند.
168u
گزینه‌های فقط DHCPv6 (DHCPv6-Only Options)
گزینه‌های زیر فقط برای DHCPv6 اعمال می‌شوند (یعنی زمانی که -6 داده شده باشد).
0.0
-c
یک گزینه rapid-commit اضافه می‌کند (تبادلات به‌صورت Solicit-Advertise خواهند بود).
-A encapsulation-level
مشخص می‌کند که ترافیک رله‌شده (relayed) باید تولید شود. این آرگومان سطح کپسوله‌سازی (encapsulation) را مشخص می‌کند، یعنی چه تعداد عامل رله (relay agent) شبیه‌سازی می‌شوند. در حال حاضر تنها مقدار پشتیبانی‌شده برای encapsulation-level عدد 1 است، به این معنی که ترافیک تولیدشده معادل میزان ترافیک عبوری از یک relay agent واحد است.
--or encapsulation-level:code,hexstring
برنامه perfdhcp را ملزم می‌کند تا گزینه اضافی مشخص‌شده (یا در صورت استفاده مکرر، گزینه‌ها) را در پیام رله‌شده DHCPv6 در سطح کپسوله‌سازی داده‌شده درج کند؛ در حال حاضر، تنها مقدار پشتیبانی‌شده برای encapsulation-level عدد 1 است.
این گزینه بسیار شبیه به -o است: آرگومان code کد گزینه را مشخص می‌کند و hexstring یک رشته هگزادسیمال است که محتوای گزینه را تعیین می‌کند. باید دقت شود، زیرا perfdhcp هیچ‌گونه منطقی برای گزینه‌ها ارائه نمی‌دهد؛ آن‌ها صرفاً درون بسته‌ها درج شده و به همان شکل ارسال می‌شوند. عبارت encapsulation-level: اختیاری است؛ اگر حذف شود، مقدار پیش‌فرض سطح کپسوله‌سازی یعنی 1 استفاده می‌شود.
برای نمونه، جهت درج Subscriber identifier (کد گزینه 38) با مقدار 1234 در اولین سطح کپسوله‌سازی، از --or 38,31323334 یا --or 1:38,31323334 استفاده کنید. گزینه --or ممکن است چندین بار استفاده شود و باید همراه با -A به کار رود.
گزینه‌های زیر تنها می‌توانند در همراهی با -T استفاده شوند و
چگونگی تغییر الگو توسط perfdhcp را مهار می‌کنند. این گزینه‌ها
می‌توانند چندین بار در خط فرمان مشخص شوند؛ هر بار تکرار بر فایل الگوی متناظر
تأثیر می‌گذارد (بخش "الگوها" در بالا را ببینید).
0.0
-E time-offset
انحراف فیلد secs (در DHCPv4) یا گزینهٔ Elapsed Time (در DHCPv6) را در
الگوی دوم (یعنی Request) تعیین می‌کند؛ باید ۰ یا یک عدد صحیح مثبت باشد.
مقدار ۰ این ویژگی را غیرفعال می‌کند.
-I ip-offset
انحراف آدرس IP (در DHCPv4) در گزینهٔ requested-ip
یا گزینهٔ IA_NA (در DHCPv6) را در الگوی دوم (Request) تعیین می‌کند.
-O random-offset
انحراف آخرین اوکتتی را که باید در الگو تصادفی‌سازی شود تعیین می‌کند. این
مقدار باید عددی صحیح و بزرگ‌تر از ۳ باشد. برای استفاده از این گزینه،
سوئیچ -T حتماً باید داده شود.
-S srvid-offset
انحراف گزینهٔ server-id در الگوی دوم (Request) را مشخص می‌کند.
این مقدار باید عددی صحیح و مثبت باشد، و این سوئیچ تنها زمانی می‌تواند استفاده شود
که گزینهٔ الگو (-T) نیز مشخص شده باشد.
-X xid-offset
انحراف شناسهٔ تراکنش (xid) را در الگو تعیین می‌کند. این مقدار باید یک
عدد صحیح مثبت باشد، و این سوئیچ تنها در صورتی می‌تواند استفاده شود که گزینهٔ
الگو (-T) نیز داده شده باشد.
168u
"گزینه‌های مهار آزمون (Options Controlling a Test)"
0.0
-D max-drop
اگر به تعداد "max-drop" درخواست دور انداخته شود، آزمون را فوراً متوقف می‌کند.
برای توقف در صورت دور انداخته شدن حتی یک درخواست، از -D 1 استفاده کنید.
"max-drop" باید یک عدد صحیح مثبت باشد. اگر "max-drop"
شامل پسوند % باشد، بیشینهٔ درصد درخواست‌هایی را مشخص می‌کند که پیش از متوقف شدن
می‌توانند دور انداخته شوند. در این حالت، بررسی آستانه پس از این آغاز می‌شود که انتظار می‌رود
۱۰ درخواست دریافت شده باشد.
-n num-requests
تعداد "num-request" تراکنش را آغاز می‌کند. تا زمانی که همهٔ
تراکنش‌ها آغاز نشده یا در انتظار پاسخ نمانده باشند، هیچ گزارشی تولید نمی‌شود؛
پس از آن گزارشی تولید شده و برنامه پایان می‌یابد.
-p test-period
درخواست‌ها را برای مدت‌زمان "test-period" ارسال می‌کند، که به همان روش
-d تعیین می‌شود. این گزینه می‌تواند به عنوان جایگزینی برای -n استفاده شود،
یا هر دو گزینه داده شوند که در این حالت، آزمون با رسیدن به هر یک از این دو محدودیت به پایان می‌رسد.
-t interval
میزان تأخیر (به ثانیه) را بین دو گزارش پیاپی تنظیم می‌کند.
-C separator
از خروجی اولیه جلوگیری می‌کند و باعث می‌شود داده‌های میان‌دوره‌ای تنها شامل
مقدارهایی باشند که با separator از هم جدا شده‌اند. در همراهی با -t
برای تولید گزارش‌هایی با قابلیت تجزیهٔ آسان در بازه‌های زمانی -t به کار می‌رود.
168u
"آرگومان‌ها (Arguments)"
0.0
server
سرور مورد نظر برای آزمون را نشان می‌دهد که به صورت یک آدرس IP مشخص می‌شود. در مورد DHCPv6،
می‌توان از نام ویژهٔ all برای اشاره به
All_DHCP_Relay_Agents_and_Servers (آدرس چندپخشی FF02::1:2)،
یا از نام ویژهٔ servers برای اشاره به All_DHCP_Servers (آدرس
چندپخشی FF05::1:3) استفاده کرد. مشخص کردن سرور الزامی است، مگر در حالتی
که گزینهٔ -l برای تعیین یک رابط (interface) داده شده باشد، که در این حالت
پیش‌فرض آن all خواهد بود.
168u
"خطاها (Errors)"
perfdhcp می‌تواند خطاهای زیر را در تبادل بسته‌ها گزارش کند:
0.0
tooshort
پیامی دریافت شده است که بیش از حد کوتاه بوده است.
orphans
پیامی دریافت شده است که با هیچ‌یک از پیام‌های ارسال‌شده به سرور همخوانی ندارد (یعنی
یک پیام تکراری است، پیامی است که پس از تأخیری بیش از حد رسیده است، یا به سادگی
شناخته نشده است).
locallimit
هنگام ارسال پیام، به محدودیت‌های سیستم محلی برخورد شده است.
168u
"وضعیت خروج (Exit Status)"
perfdhcp با یکی از کدهای وضعیت زیر خارج می‌شود:
0.0
0
موفقیت‌آمیز.
1
خطای عمومی.
2
خطا در آرگومان‌های خط فرمان.
3
هیچ شکست عمومی در عملکرد رخ نداده، اما یک یا چند تبادل ناموفق بوده‌اند.
168u
"مثال‌های کاربرد (Usage Examples)"
در اینجا مثالی آمده است که ترافیک عادی DHCPv4 را از ۱۰۰ دستگاه DHCPv4 شبیه‌سازی می‌کند (-R 100)،
با نرخ ۱۰ بسته در ثانیه (-r 10)، جزئیات نرخ پرسش/پاسخ را نمایش می‌دهد (-xi)،
هر ۲ ثانیه یک بار گزارش می‌دهد (-t 2)، و بسته‌ها را به IP با مقدار 192.0.2.1 می‌فرستد:
0.0
3.5
sudo perfdhcp -xi -t 2 -r 10 -R 100 192.0.2.1
168u
168u
این نمونه‌ای مشابه است، اما برای DHCPv6. توجه داشته باشید که پروتکل DHCPv6 از آدرس‌های
link-local استفاده می‌کند، بنابراین رابط شبکه‌ای (در این مثال eth0) که ترافیک باید روی آن
ارسال شود، باید مشخص گردد. all یک نام مستعار مناسب برای All_DHCP_Relay_Agents_and_Servers
(آدرس چندپخشی FF02::1:2) است. همچنین می‌توان از نام مستعار servers برای اشاره به
All_DHCP_Servers (آدرس چندپخشی FF05::1:3) استفاده کرد. مقدار پیش‌فرض all است.
0.0
3.5
sudo perfdhcp -6 -xi -t 1 -r 1 -R 10 -l eth0 all
168u
168u
مثال‌های زیر ترافیک عادی DHCPv4 و DHCPv6 را شبیه‌سازی می‌کنند که پس از ۳ ثانیه،
برای مدت ۱۰ ثانیه وانمود می‌کند هیچ پاسخی از سرور دریافت نمی‌کند. پروتکل
DHCPv4 این وضعیت را با فیلد افزایش‌یافتهٔ secs نشان می‌دهد، در حالی که DHCPv6 از گزینهٔ
Elapsed Time استفاده می‌کند. در شبکه‌های واقعی، این امر نشان می‌دهد که کلاینت‌ها پاسخ‌ها را
به‌موقع دریافت نمی‌کنند. این می‌تواند برای شبیه‌سازی برخی سناریوهای HA استفاده شود، زیرا Kea
از فیلد secs و مقدار گزینهٔ Elapsed Time به عنوان یکی از شاخص‌های
عدم پاسخ‌گویی شریک HA استفاده می‌کند. در صورت فعال شدن با -y و -Y، مقادیر secs
و Elapsed Time به طور پیوسته افزایش می‌یابند.
0.0
3.5
sudo perfdhcp -xi -t 1 -r 1 -y 10 -Y 3 192.0.2.1
sudo perfdhcp -6 -xi -t 1 -r 1 -y 10 -Y 3 2001:db8::1
168u
نرم‌افزار Kea همراه با یک «راهنمای مرجع جامع مدیر سیستم Kea» ارائه می‌شود که تمام جنبه‌های اجرای نرم‌افزار Kea - از جمله کامپایل، نصب، پیکربندی، نمونه‌های پیکربندی و موارد دیگر - را پوشش می‌دهد. همچنین Kea دارای «راهنمای پیام‌های Kea» است که تمام پیام‌های احتمالی قابل چاپ توسط Kea را همراه با شرح مختصری برای هر یک فهرست می‌کند. هر دو سند در قالب‌های مختلف (.txt، .html، .pdf) به همراه توزیع Kea در دسترس هستند. مستندات Kea در نشانی زیر در دسترس است:
https://kea.readthedocs.io.
کد منبع Kea در «راهنمای توسعه‌دهنده Kea» مستندسازی شده است که در نشانی زیر قابل دسترسی است:
https://reports.kea.isc.org/dev_guide.
وب‌سایت پروژه Kea در نشانی زیر در دسترس است:
https://kea.isc.org.
"فهرست‌های پستی و پشتیبانی (MAILING LISTS AND SUPPORT)"
دو فهرست پستی عمومی برای پروژه Kea در دسترس است. kea-users
(نشانی kea-users در lists.isc.org) برای کاربران Kea در نظر گرفته شده است، در حالی که kea-dev
(نشانی kea-dev در lists.isc.org) برای توسعه‌دهندگان Kea، مشارکت‌کنندگان آینده و دیگر کاربران پیشرفته در نظر گرفته شده است. هر دو فهرست در نشانی زیر در دسترس هستند:
https://lists.isc.org. جامعه کاربری در هر دوی این فهرست‌ها در حد توان (best-effort) پشتیبانی ارائه می‌دهد.
سازمان ISC پشتیبانی حرفه‌ای برای خدمات Kea ارائه می‌دهد. برای جزئیات به نشانی زیر مراجعه کنید:
https://www.isc.org/kea.
"تاریخچه (HISTORY)"
ابزار perfdhcp در ابتدا در اکتبر ۲۰۱۱ توسط John DuBois، Francis Dupont و Marcin Siodelski از ISC کدنویسی شد. Kea 1.0.0 که شامل perfdhcp بود، در دسامبر ۲۰۱۵ منتشر شد.
"همچنین ببینید (SEE ALSO)"
kea-dhcp4(8)، kea-dhcp6(8)، kea-dhcp-ddns(8)،
kea-admin(8)، kea-netconf(8)،
keactrl(8)، kea-lfc(8)، Kea Administrator Reference Manual.
"راهنمای پیام‌های KEA (KEA MESSAGES MANUAL)"
نرم‌افزار Kea پیاده‌سازی متن‌بازی از کارسازهای پروتکل پیکربندی پویای میزبان (DHCP) است که توسط Internet Systems Consortium (ISC) توسعه یافته و نگهداری می‌شود.
این سند، راهنمای مرجع برای Kea نسخه 3.2.0 است.
پیوندهای مربوط به به‌روزترین نسخه این سند (در قالب‌های PDF، HTML و متن ساده)، به همراه سایر اطلاعات مفید درباره Kea را می‌توان در پایگاه دانش ISC به نشانی https://kea.readthedocs.io یافت.
لطفاً توجه داشته باشید که در پیام‌های زیر، علامت درصد (%) که به دنبال آن یک عدد می‌آید، برای نشان دادن یک جای‌نگه‌دار (placeholder) برای داده‌هایی استفاده می‌شود که توسط کد Kea در حین اجرای آن ارائه می‌گردند.
ALLOC
ALLOC_ENGINE_IGNORING_UNSUITABLE_GLOBAL_ADDRESS
0.0
3.5
%1: ignoring globally reserved address %2, it falls outside %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص تشخیص دهد نشانی رزروشده به صورت سراسری خارج از زیرشبکه (subnet) یا شبکه مشترک (shared-network) انتخاب‌شده قرار می‌گیرد. کارساز باید نشانی رزروشده را نادیده گرفته و برای تخصیص پویا تلاش کند.
ALLOC_ENGINE_IGNORING_UNSUITABLE_GLOBAL_ADDRESS6
0.0
3.5
%1: ignoring globally reserved address %2, it falls outside %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص تشخیص دهد نشانی رزروشده به صورت سراسری خارج از زیرشبکه یا شبکه مشترک انتخاب‌شده قرار می‌گیرد. کارساز باید نشانی رزروشده را نادیده گرفته و برای تخصیص پویا تلاش کند.
ALLOC_ENGINE_LEASE_RECLAIMED
0.0
3.5
successfully reclaimed lease %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که موتور تخصیص یک اجاره (lease) را با موفقیت بازپس‌گیری کند. این اجاره اکنون برای واگذاری در دسترس است.
ALLOC_ENGINE_V4_ALLOC_ERROR
0.0
3.5
%1: error during attempt to allocate an IPv4 address: %2
168u
168u
هنگام تلاش برای تخصیص یک نشانی IPv4 خطایی رخ داده است که دلیل این شکست در پیام گنجانده شده است. کارساز پیامی مبنی بر رد اجاره به کلاینت بازمی‌گرداند. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V4_ALLOC_FAIL
0.0
3.5
%1: failed to allocate an IPv4 address after %2 attempt(s)
168u
168u
این یک پیام هشدار قدیمی است که هنگام شکست موتور تخصیص در تخصیص یک اجاره به یک کلاینت صادر می‌شود. این پیام شامل تعداد دفعاتی است که موتور پیش از انصراف، برای تخصیص اجاره تلاش کرده است. اگر تعداد تلاش‌ها ۰ باشد زیرا موتور نتوانسته است از هیچ‌یک از استخرهای نشانی برای آن کلاینت خاص استفاده کند، این پیام ثبت نمی‌شود. با وجود اینکه چندین لاگ با جزئیات بیشتر پیش از این پیام ثبت می‌شوند، این پیام برای حفظ سازگاری با گذشته باقی مانده است.
این پیام ممکن است نشان‌دهنده این باشد که استخر نشانی شما برای تعداد کلاینت‌هایی که سعی در سرویس‌دهی به آن‌ها دارید بسیار کوچک است و باید گسترش یابد. همچنین، اگر می‌دانید تعداد کلاینت‌های فعالِ هم‌زمان کمتر از نشانی‌های در دسترس شما است، می‌توانید کاهش مدت زمان اعتبار اجاره (lease lifetime) را مد نظر قرار دهید. با این روش، نشانی‌های تخصیص‌یافته به کلاینت‌هایی که دیگر در شبکه فعال نیستند، زودتر آزاد شده و در دسترس قرار می‌گیرند..SS ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES
0.0
3.5
%1: Failed to allocate an IPv4 address for client with classes: %2
168u
168u
این پیام هشدار زمانی چاپ می‌شود که Kea در تخصیص یک آدرس ناموفق بوده و بستهٔ کلاینت متعلق به یک یا چند کلاس باشد. دلایل متعددی ممکن است برای عدم انتساب اجاره (lease) وجود داشته باشد. یکی از آن‌ها این است که تمام استخرها نیازمند تعلق بسته به کلاس‌های خاصی هستند و بستهٔ دریافتی به هیچ‌یک از آن‌ها تعلق ندارد. مورد دیگر که این اطلاعات می‌تواند در آن مفید باشد، اشاره به این نکته است که آدرس‌های استخر رزروشده برای یک کلاس معین به پایان رسیده است. در صورت نمایش این پیام، بررسی اندازهٔ استخر و تعاریف رده‌بندی را مد نظر قرار دهید.
ALLOC_ENGINE_V4_ALLOC_FAIL_NO_POOLS
0.0
3.5
%1: no pools were available for the address allocation
168u
168u
این پیام هشدار زمانی صادر می‌شود که موتور تخصیص نتواند اجاره‌ای را اختصاص دهد، چرا که امکان استفاده از هیچ‌یک از استخرهای پیکربندی‌شده برای آن کلاینت خاص وجود نداشته است. همچنین این احتمال وجود دارد که تمام زیرشبکه‌هایی که موتور تخصیص تلاش کرده از آن‌ها آدرسی اختصاص دهد، فاقد استخر آدرس باشند. در این صورت، چنانچه مدیر سیستم انتظار داشته باشد به برخی از کلاینت‌ها آدرس‌های پویا اختصاص یابد، این مسئله باید یک پیکربندی نادرست تلقی شود. یک زیرشبکه تنها در صورتی می‌تواند فاقد هرگونه استخر باشد که قرار باشد به همهٔ کلاینت‌ها آدرس‌های IP رزروشده اختصاص داده شود.
اگر زیرشبکه‌های متصل به یک شبکهٔ اشتراکی یا یک زیرشبکهٔ منفرد که کلاینت متعلق به آن است دارای استخرهای پیکربندی‌شده باشند، در این حالت، این پیام نشان‌دهندهٔ آن است که هیچ‌یک از استخرها به دلیل عدم تعلق کلاینت به کلاس‌های مناسب، برای آن قابل استفاده نبوده‌اند.
ALLOC_ENGINE_V4_ALLOC_FAIL_SHARED_NETWORK
0.0
3.5
%1: failed to allocate an IPv4 address in the shared network %2: %3 subnets have no available addresses, %4 subnets have no matching pools
168u
168u
این پیام هشدار زمانی صادر می‌شود که موتور تخصیص در اختصاص یک اجاره برای کلاینت متصل به یک شبکهٔ اشتراکی (shared network) با شکست مواجه شود. شبکهٔ اشتراکی باید حداقل شامل یک زیرشبکه باشد، اما معمولاً چندین زیرشبکه را تجمیع می‌کند. این پیام لاگ نشان می‌دهد که موتور تخصیص نتوانسته هیچ اجارهٔ مناسبی را در هیچ‌یک از زیرشبکه‌های موجود در شبکهٔ اشتراکی پیدا و تخصیص دهد.
آرگومان اول حاوی اطلاعات شناسایی کلاینت است. آرگومان دوم نام شبکهٔ اشتراکی را مشخص می‌کند. دو آرگومان باقی‌مانده اطلاعات بیشتری ارائه می‌دهند که برای اشکال‌زدایی دلیل عدم توانایی موتور تخصیص در واگذاری اجاره مفید هستند. موتور تخصیص تلاش می‌کند تا آدرس‌ها را از زیرشبکه‌های مختلف در شبکهٔ اشتراکی تخصیص دهد، و ممکن است در برخی زیرشبکه‌ها به دلیل عدم وجود اجاره‌های آزاد یا رزرو بودن اجاره‌های آزاد برای کلاینت‌های دیگر با شکست مواجه شود. تعداد چنین زیرشبکه‌هایی در آرگومان سوم مشخص می‌شود. برای سایر زیرشبکه‌ها، تخصیص ممکن است به دلیل در دسترس نبودن استخرهای آن‌ها برای کلاینت مربوطه ناموفق باشد. این استخرها با کلاس‌های کلاینتی محافظت می‌شوند که کلاینت به آن‌ها تعلق ندارد. آرگومان چهارم تعداد چنین زیرشبکه‌هایی را مشخص می‌کند. مدیر سیستم با بررسی مقادیر آرگومان‌های سوم و چهارم می‌تواند مواردی را که در آن‌ها آدرسی در برخی از استخرها باقی نمانده شناسایی کند. او همچنین می‌تواند پیکربندی‌های نادرست رده‌بندی کلاینت را که موجب رد ارائهٔ سرویس به برخی کلاینت‌ها می‌شود، تشخیص دهد.
ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET
0.0
3.5
%1: failed to allocate an IPv4 lease in the subnet %2, subnet-id %3, shared network %4
168u
168u
این پیام هشدار زمانی صادر می‌شود که موتور تخصیص نتواند اجاره‌ای را برای کلاینت متصل به یک زیرشبکه تخصیص دهد. آرگومان اول شامل اطلاعات شناسایی کلاینت است. آرگومان‌های دوم و سوم زیرشبکه را مشخص می‌کنند. آرگومان چهارم نیز در صورتی که زیرشبکه متعلق به یک شبکهٔ اشتراکی باشد، نام شبکهٔ اشتراکی را تعیین می‌کند.
دلایل متعددی برای شکست در تخصیص اجاره وجود دارد. یکی از آن‌ها می‌تواند اتمام ظرفیت استخرها یا رزروهای موجود برای اجاره‌های آزاد باشد. با این حال، در برخی موارد، ممکن است موتور تخصیص در یافتن استخر مناسب برای کلاینت ناموفق باشد؛ یعنی در شرایطی که استخرها تنها برای کلاس‌های کلاینت خاصی در دسترس هستند، اما کلاینت درخواست‌کننده به آن‌ها تعلق ندارد. پیام‌های لاگ بعدی اطلاعات بیشتری را به منظور تمایز بین این حالات مختلف ارائه می‌دهند.
ALLOC_ENGINE_V4_DECLINED_RECOVERED
0.0
3.5
IPv4 address %1 was recovered after %2 seconds of probation-period
168u
168u
این پیام اطلاعاتی نشان می‌دهد که آدرس مشخص‌شده به عنوان تکراری گزارش شده بود (کلاینت پیام DECLINE ارسال کرده بود) و سرور این آدرس را برای مدت‌زمانی غیرقابل‌دسترس علامت‌گذاری کرده بود. اکنون این زمان سپری شده و آدرس به استخر آدرس‌های در دسترس بازگردانده شده است. این مرحله، فرایند بازیابی رد (decline recovery) را به پایان می‌رساند.
ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT
0.0
3.5
%1: conflicting reservation for address %2 with existing lease %3
168u
168u
این پیام هشدار زمانی صادر می‌شود که سرور DHCP متوجه شود آدرس رزروشده برای کلاینت قابل ارائه نیست، زیرا این آدرس در حال حاضر به کلاینت دیگری تخصیص داده شده است. سرور تلاش خواهد کرد آدرس متفاوتی را به کلاینت اختصاص دهد تا زمانی که تداخل برطرف شود از آن استفاده نماید. آرگومان اول شامل اطلاعات شناسایی کلاینت است..SS ALLOC_ENGINE_V4_DISCOVER_HR
0.0
3.5
client %1 sending DHCPDISCOVER has reservation for the address %2
168u
168u
در سطح ثبت گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام زمانی صادر می‌شود که موتور تخصیص تشخیص دهد کلاینت فرستندهٔ DHCPDISCOVER دارای رزرو برای آدرس مشخص‌شده است. موتور تخصیص تلاش خواهد کرد این آدرس را به کلاینت پیشنهاد (offer) دهد.
ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE
0.0
3.5
reclaimed %1 leases in %2
168u
168u
در سطح ثبت گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که موتور تخصیص، بازپس‌گیری مجموعه‌ای از اجاره‌های منقضی‌شده را به پایان برساند. حداکثر تعداد اجاره‌هایی که در یک دور از روال بازپس‌گیری اجاره بازیابی می‌شوند، با استفاده از پارامتر 'max-reclaim-leases' قابل پیکربندی است. با این حال، تعداد اجاره‌های بازپس‌گرفته‌شده ممکن است توسط مقدار مهلت زمانی (timeout) که با 'max-reclaim-time' پیکربندی شده نیز محدود شود. این پیام شامل تعداد اجاره‌های بازپس‌گرفته‌شده و کل زمان صرف‌شده است.
ALLOC_ENGINE_V4_LEASES_RECLAMATION_FAILED
0.0
3.5
reclamation of expired leases failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که بازپس‌گیری اجاره‌های منقضی‌شده با شکست مواجه شود.
پیام خطا نمایش داده می‌شود.
ALLOC_ENGINE_V4_LEASES_RECLAMATION_SLOW
0.0
3.5
expired leases still exist after %1 reclamations
168u
168u
این پیام هشدار زمانی صادر می‌شود که سرور نتواند تمام اجاره‌های منقضی‌شده را در تعداد معینی تلاش متوالی بازپس گیرد. این امر نشان می‌دهد که مقدار "reclaim-timer-wait-time" ممکن است بیش از حد بالا باشد. با این وجود، اگر این رویداد تنها ناشی از یک موج ناگهانی و کوتاه‌مدت از انقضای اجاره‌ها باشد، نیازی به تغییر مقدار نیست و سرور باید در تلاش‌های بعدیِ بازپس‌گیری با آن مواجه شود. اگر این وضعیت نتیجهٔ افزایش دائمی بار سرور باشد، مقدار "reclaim-timer-wait-time" باید کاهش یابد، یا مقادیر "max-reclaim-leases" و "max-reclaim-time" افزایش یابند تا پردازش اجاره‌های بیشتری در یک چرخه مجاز باشد.
همچنین می‌توان این مقادیر را روی 0 تنظیم کرد تا محدودیت‌های تعداد اجاره‌ها و مدت‌زمان برداشته شود. با این حال، این عمل ممکن است باعث دوره‌های طولانی‌تر پاسخ‌گو نبودن سرور به بسته‌های DHCP در حین پردازش اجاره‌های منقضی‌شده گردد.
ALLOC_ENGINE_V4_LEASES_RECLAMATION_START
0.0
3.5
starting reclamation of expired leases (limit = %1 leases or %2 milliseconds)
168u
168u
در سطح ثبت گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص بازپس‌گیری اجاره‌های منقضی‌شده را آغاز کند. حداکثر تعداد اجاره‌های قابل بازپس‌گیری و مهلت زمانی (timeout) در پیام آورده شده است. اگر هر یک از این مقادیر 0 باشد، به معنای «نامحدود» ("unlimited") است.
ALLOC_ENGINE_V4_LEASES_RECLAMATION_TIMEOUT
0.0
3.5
timeout of %1 ms reached while reclaiming IPv4 leases
168u
168u
در سطح ثبت گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص هنگام اجرای بازپس‌گیری اجاره‌های منقضی‌شده به مهلت زمانی برسد. بازپس‌گیری اکنون متوقف خواهد شد و تمام اجاره‌هایی که به دلیل پایان مهلت زمانی بازپس‌گرفته نشده‌اند، با شروع بازپس‌گیری زمان‌بندی‌شدهٔ بعدی بازپس گرفته خواهند شد. آرگومان، مقدار مهلت زمانی بیان‌شده به میلی‌ثانیه است.
ALLOC_ENGINE_V4_LEASE_RECLAIM
0.0
3.5
%1: reclaiming expired lease for address %2
168u
168u
در سطح ثبت گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور بازپس‌گیری اجارهٔ منقضی‌شدهٔ DHCPv4 را آغاز می‌کند. آرگومان نخست، اطلاعات شناسایی کلاینت را مشخص می‌کند. آرگومان دوم حاوی آدرس IPv4 اجاره‌داده‌شده است.
ALLOC_ENGINE_V4_LEASE_RECLAMATION_FAILED
0.0
3.5
failed to reclaim the lease %1: %2
168u
168u
این پیام خطا زمانی ثبت می‌شود که موتور تخصیص در بازپس‌گیری یک اجارهٔ منقضی‌شده با شکست مواجه شود. دلیل این شکست در پیام گنجانده شده است. این خطا ممکن است در قلاب (hook) انقضای اجاره یا هنگام انجام عملیات روی پایگاه دادهٔ اجاره‌ها رخ داده باشد..SS ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES
0.0
3.5
all expired leases have been reclaimed
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تمامی اجاره‌های منقضی‌شدهٔ
DHCPv4 در پایگاه داده را بازپس می‌گیرد.
ALLOC_ENGINE_V4_OFFER_EXISTING_LEASE
0.0
3.5
allocation engine will try to offer existing lease to the client %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام هنگامی صادر می‌شود که موتور تخصیص تعیین می‌کند
کلاینت یک اجاره در پایگاه دادهٔ اجاره‌ها دارد، هیچ رزروی برای
اجارهٔ دیگری ندارد، و نشانی اجاره‌داده‌شده برای هیچ کلاینت
دیگری رزرو نشده است. موتور تخصیص تلاش خواهد کرد همان اجاره
را به کلاینت پیشنهاد دهد.
ALLOC_ENGINE_V4_OFFER_NEW_LEASE
0.0
3.5
allocation engine will try to offer new lease to the client %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی صادر می‌شود که موتور تخصیص تلاش می‌کند
یک اجارهٔ جدید به کلاینت پیشنهاد دهد. این حالت زمانی رخ می‌دهد که
کلاینت هیچ اجارهٔ فعلی نداشته باشد، فاقد هرگونه رزرو باشد،
یا نشانیِ موجود یا رزروشده به کلاینت دیگری اجاره داده شده باشد.
همچنین زمانی که کلاینت یک hint مشخص نکرده باشد، یا نشانی
ارائه‌شده در hint در حال استفاده باشد.
ALLOC_ENGINE_V4_OFFER_REQUESTED_LEASE
0.0
3.5
allocation engine will try to offer requested lease %1 to the client %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی صادر می‌شود که موتور تخصیص تلاش می‌کند
اجارهٔ مشخص‌شده در hint را پیشنهاد دهد. این وضعیت ممکن است
زمانی رخ دهد که: (a) کلاینت هیچ رزروی نداشته باشد، (b) کلاینت دارای
رزرو باشد اما نشانیِ رزروشده به کلاینت دیگری اجاره داده شده باشد.
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE
0.0
3.5
begin deletion of reclaimed leases expired more than %1 seconds ago
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که موتور تخصیص آغاز به
حذف اجاره‌های بازپس‌گرفته‌شده‌ای می‌کند که بیش از تعداد ثانیه‌های
مشخصی پیش منقضی شده‌اند. این عملیات به‌صورت دوره‌ای بر اساس
پارامتر "flush-reclaimed-timer-wait-time" اجرا می‌شود.
پارامتر "hold-reclaimed-time" تعداد ثانیه‌هایی را مشخص می‌کند
که اجاره‌ها پیش از حذف شدن، ذخیره و نگهداری می‌شوند.
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE
0.0
3.5
successfully deleted %1 expired-reclaimed leases
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز اجاره‌های
"expired-reclaimed" را با موفقیت از پایگاه دادهٔ اجاره‌ها حذف کند.
تعداد اجاره‌های حذف‌شده در پیام لاگ گنجانده شده است.
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_FAILED
0.0
3.5
deletion of expired-reclaimed leases failed: %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که حذف اجاره‌های "expired-reclaimed"
از پایگاه داده با شکست مواجه شود. پیام خطا به پیام لاگ پیوست
می‌شود.
ALLOC_ENGINE_V4_REQUEST_ADDRESS_RESERVED
0.0
3.5
%1: requested address %2 is reserved
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام هنگامی صادر می‌شود که موتور تخصیص از تخصیص نشانی
درخواستی کلاینت خودداری کرده است، زیرا این نشانی برای
کلاینت دیگری رزرو شده است. آرگومان اول شامل اطلاعات
شناسایی کلاینت است..SS ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED
0.0
3.5
%1: trying to allocate requested address %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام هنگامی صادر می‌شود که موتور تخصیص در حال تلاش برای تخصیص (یا استفادهٔ مجدد از یک نشانی منقضی‌شده) نشانی درخواست‌شده توسط کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE
0.0
3.5
%1: extending lifetime of the lease for address %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام هنگامی صادر می‌شود که موتور تخصیص تشخیص می‌دهد کلاینت از پیش دارای یک اجاره (lease) است که طول عمر آن قابل تمدید بوده و می‌تواند به کلاینت بازگردانده شود.
آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V4_REQUEST_INVALID
0.0
3.5
client %1 having a reservation for address %2 is requesting invalid address %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که کلاینت، با داشتن رزرو برای یک نشانی، نشانی متفاوتی را درخواست می‌کند. کلاینت تنها زمانی مجاز به انجام این کار است که نشانی رزروشده توسط کلاینت دیگری در حال استفاده باشد. با این حال، موتور تخصیص تشخیص داده است که نشانی رزروشده در دسترس است و کلاینت باید همان نشانی رزروشده را درخواست کند.
ALLOC_ENGINE_V4_REQUEST_IN_USE
0.0
3.5
%1: requested address %2 is in use
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام هنگامی صادر می‌شود که کلاینت درخواستی برای یک نشانی دارد یا رزروی برای نشانی‌ای دارد که در حال استفاده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL
0.0
3.5
client %1, which doesn't have a reservation, requested address %2 out of the dynamic pool
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام هنگامی صادر می‌شود که کلاینت درخواست تخصیص نشانی‌ای را داده است که متعلق به هیچ استخر نشانی‌ای که نشانی‌ها به‌طور پویا از آن تخصیص می‌یابند نیست. کلاینت همچنین هیچ رزروی برای این نشانی ندارد. این نشانی تنها در صورتی می‌توانست تخصیص داده شود که کلاینت برای آن رزرو می‌داشت.
ALLOC_ENGINE_V4_REQUEST_PICK_ADDRESS
0.0
3.5
client %1 hasn't specified an address - picking available address from the pool
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که کلاینت هیچ نشانی ترجیحی را مشخص نکرده است (کلاینت همیشه باید این کار را انجام دهد، اما Kea سعی می‌کند انعطاف‌پذیر باشد). موتور تخصیص تلاش خواهد کرد تا نشانی در دسترسی را از استخر پویا انتخاب کرده و آن را به کلاینت تخصیص دهد.
ALLOC_ENGINE_V4_REQUEST_REMOVE_LEASE
0.0
3.5
%1: removing previous client's lease %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص، اجارهٔ پیشین کلاینت را حذف می‌کند زیرا اجارهٔ جدیدی به کلاینت تخصیص یافته است.
ALLOC_ENGINE_V4_REQUEST_USE_HR
0.0
3.5
client %1 hasn't requested specific address, using reserved address %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام هنگامی صادر می‌شود که کلاینت هیچ نشانی مشخصی را درخواست نکرده است اما موتور تخصیص تشخیص داده که یک رزرو برای این کلاینت وجود دارد. موتور تخصیص تلاش خواهد کرد تا نشانی رزروشده را تخصیص دهد..SS ALLOC_ENGINE_V4_REUSE_EXPIRED_LEASE_DATA
0.0
3.5
%1: reusing expired lease, updated lease information: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص در حال استفادهٔ مجدد از یک
اجارهٔ موجود است. جزئیات اجارهٔ به‌روزشده چاپ می‌شوند.
آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_ALLOC_ERROR
0.0
3.5
%1: error during attempt to allocate an IPv6 address: %2
168u
168u
هنگام تلاش برای تخصیص یک نشانی IPv6 خطایی رخ داد و دلیل شکست
در پیام درج شده است. سرور پیامی مبنی بر رد اجاره به کلاینت
بازمی‌گرداند. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_ALLOC_FAIL
0.0
3.5
%1: failed to allocate an IPv6 lease after %2 attempt(s)
168u
168u
این یک پیام هشدار قدیمی است که هنگام شکست موتور تخصیص در تخصیص
اجاره برای یک کلاینت صادر می‌شود. این پیام شامل تعداد تلاش‌های تخصیص
اجاره است که موتور قبل از انصراف انجام داده است. اگر تعداد تلاش‌ها 0 باشد،
به این دلیل که موتور نتوانسته است از هیچ‌یک از استخرها برای آن کلاینت خاص
استفاده کند، این پیام ثبت نمی‌شود. با وجود اینکه چندین گزارش با جزئیات بیشتر
پیش از این پیام می‌آیند، این پیام برای سازگاری با گذشته باقی مانده است.
این پیام ممکن است نشان‌دهندهٔ این باشد که استخر شما برای تعداد کلاینت‌هایی
که می‌خواهید به آن‌ها سرویس دهید بسیار کوچک است و باید گسترش یابد.
متناوباً، اگر می‌دانید که تعداد کلاینت‌های فعال به‌طور هم‌زمان کمتر از اجاره‌های
دردسترس شما است، ممکن است بخواهید طول عمر اجاره را کاهش دهید.
به این ترتیب، اجاره‌های تخصیص‌یافته به کلاینت‌هایی که دیگر در شبکه فعال
نیستند، زودتر دردسترس قرار می‌گیرند.
ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES
0.0
3.5
%1: Failed to allocate an IPv6 address for client with classes: %2
168u
168u
این پیام هشدار زمانی چاپ می‌شود که Kea در تخصیص نشانی ناموفق بوده
و بستهٔ کلاینت متعلق به یک یا چند کلاس است. عدم انتساب اجاره ممکن است
دلایل متعددی داشته باشد. یکی از آن‌ها می‌تواند وضعیتی باشد که در آن همهٔ
استخرها نیازمند تعلق بسته به کلاس‌های خاصی هستند و بستهٔ دریافتی به
هیچ‌یک از آن‌ها تعلق نداشته است. حالت دیگری که این اطلاعات می‌تواند در آن
مفید باشد، اشاره به این است که نشانی‌های استخر رزروشده برای یک کلاس معین
به پایان رسیده است. در صورت نمایش این پیام، می‌توانید اندازهٔ استخر و
تعاریف کلاس‌بندی را بررسی کنید.
ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS
0.0
3.5
%1: no pools were available for the lease allocation
168u
168u
این پیام هشدار زمانی صادر می‌شود که موتور تخصیص در تخصیص اجاره
ناموفق است، زیرا نتوانسته از هیچ‌یک از استخرهای پیکربندی‌شده برای آن
کلاینت خاص استفاده کند. همچنین این احتمال وجود دارد که تمام زیرشبکه‌هایی
که موتور تخصیص سعی کرده از آن‌ها نشانی اختصاص دهد، فاقد استخر نشانی
باشند. در این حالت، اگر مدیر سیستم انتظار دارد که به برخی کلاینت‌ها نشانی‌های
پویا اختصاص داده شود، این مسئله باید یک پیکربندی نادرست تلقی شود.
یک زیرشبکه تنها زمانی ممکن است فاقد هرگونه استخر باشد که قرار باشد به همهٔ
کلاینت‌ها اجاره‌های رزروشده اختصاص یابد.
فرض کنید زیرشبکه‌های متصل به یک شبکهٔ اشتراکی (shared network) یا یک
زیرشبکهٔ منفرد که کلاینت به آن تعلق دارد، دارای استخرهای پیکربندی‌شده هستند.
در این حالت، این پیام نشان‌دهندهٔ آن است که هیچ‌کدام از استخرها نتوانسته‌اند برای
کلاینت استفاده شوند زیرا کلاینت به کلاس‌های کلاینت مناسب تعلق ندارد.
ALLOC_ENGINE_V6_ALLOC_FAIL_SHARED_NETWORK
0.0
3.5
%1: failed to allocate a lease in the shared network %2: %3 subnets have no available leases, %4 subnets have no matching pools
168u
168u
این پیام هشدار زمانی صادر می‌شود که موتور تخصیص در تخصیص اجاره برای
یک کلاینت متصل به یک شبکهٔ اشتراکی (shared network) ناموفق باشد.
شبکهٔ اشتراکی باید حداقل شامل یک زیرشبکه باشد، اما معمولاً چندین زیرشبکه را
تجمیع می‌کند. این پیام گزارش نشان می‌دهد که موتور تخصیص نتوانسته است
هیچ اجارهٔ مناسبی را در هیچ‌یک از زیرشبکه‌های درون شبکهٔ اشتراکی بیابد
و تخصیص دهد.
آرگومان نخست شامل اطلاعات شناسایی کلاینت است. آرگومان دوم نام شبکهٔ
اشتراکی را مشخص می‌کند. دو آرگومان باقی‌مانده اطلاعات بیشتری ارائه می‌دهند
که برای اشکال‌زدایی دلیل عدم توانایی موتور تخصیص در انتساب اجاره مفید است.
موتور تخصیص تلاش می‌کند تا اجاره‌ها را از زیرشبکه‌های مختلف در شبکهٔ
اشتراکی تخصیص دهد، و ممکن است برای برخی از زیرشبکه‌ها با شکست مواجه
شود زیرا هیچ اجارهٔ دردسترسی در آن زیرشبکه‌ها وجود ندارد یا اجاره‌های آزاد
برای کلاینت‌های دیگر رزرو شده‌اند. تعداد چنین زیرشبکه‌هایی در آرگومان سوم
مشخص می‌شود. برای زیرشبکه‌های دیگر ممکن است تخصیص به این دلیل ناموفق
باشد که استخرهای آن‌ها برای آن کلاینت خاص دردسترس نیستند. این استخرها با
کلاس‌های کلاینتی محافظت می‌شوند که کلاینت عضو آن‌ها نیست. آرگومان چهارم
تعداد چنین زیرشبکه‌هایی را مشخص می‌کند. با بررسی مقادیر آرگومان‌های سوم و
چهارم، مدیر سیستم می‌تواند شرایطی را که در آن هیچ اجاره‌ای در برخی از استخرها
باقی نمانده است شناسایی کند. او همچنین می‌تواند پیکربندی‌های نادرست
کلاس‌بندی کلاینت را که باعث رد ارائهٔ سرویس به برخی کلاینت‌ها می‌شود،
تشخیص دهد..SS ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET
0.0
3.5
%1: failed to allocate an IPv6 lease in the subnet %2, subnet-id %3, shared network %4
168u
168u
این پیام هشدار زمانی صادر می‌شود که موتور تخصیص در تخصیص یک اجاره (lease) برای کلاینت متصل به یک زیرشبکه با شکست مواجه شود. آرگومان نخست شامل اطلاعات شناسایی کلاینت است. آرگومان‌های دوم و سوم زیرشبکه را مشخص می‌کنند. آرگومان چهارم شبکهٔ اشتراکی (shared network) را مشخص می‌کند، در صورتی که زیرشبکه متعلق به یک شبکهٔ اشتراکی باشد.
دلایل متعددی برای شکست در تخصیص اجاره وجود دارد. یکی از آن‌ها ممکن است اتمام ظرفیت استخرها یا وجود رزروها برای اجاره‌های آزاد باشد. با این حال، در برخی موارد، ممکن است موتور تخصیص در یافتن یک استخر مناسب برای کلاینت ناموفق باشد؛ برای نمونه زمانی که استخرها تنها برای کلاس‌های کلاینت خاصی در دسترس هستند، اما کلاینت درخواست‌کننده متعلق به آن‌ها نیست. پیام‌های لاگ بعدی اطلاعات بیشتری را برای تفکیک بین این حالت‌های مختلف ارائه می‌دهند.
ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS
0.0
3.5
%1: lease type %2 for reserved address/prefix %3 already exists
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص تشخیص دهد اجاره مربوط به نشانی یا پیشوند IPv6 از پیش برای کلاینت تخصیص داده شده است و کلاینت می‌تواند به استفاده از آن ادامه دهد. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_ALLOC_LEASES_HR
0.0
3.5
leases and static reservations found for client %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص در حین فرایند تخصیص اجاره‌ها برای کلاینت، اجاره‌های موجود و رزروهای ایستا (static reservations) را برای کلاینت پیدا کند. موتور تخصیص بررسی خواهد کرد که آیا اجاره‌های موجود با رزروها مطابقت دارند یا خیر. اجاره‌هایی که برای سایر کلاینت‌ها رزرو شده‌اند و اجاره‌هایی که برای این کلاینت رزرو نشده‌اند حذف خواهند شد. تمامی اجاره‌های منطبق با رزروها تمدید شده و بازگردانده می‌شوند.
ALLOC_ENGINE_V6_ALLOC_LEASES_NO_HR
0.0
3.5
no reservations found but leases exist for client %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص در حین فرایند تخصیص اجاره‌ها برای کلاینت باشد و هیچ رزرو ایستایی وجود نداشته باشد، اما اجاره(هایی) برای کلاینت موجود باشد. موتور تخصیص اجاره‌هایی را که برای سایر کلاینت‌ها رزرو شده‌اند حذف کرده و تمامی اجاره‌های باقی‌مانده را به کلاینت بازمی‌گرداند.
ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR
0.0
3.5
no leases found but reservations exist for client %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص در حین فرایند تخصیص اجاره‌ها برای کلاینت باشد. این موتور هیچ اجارهٔ موجودی برای این کلاینت نیافته است، اما به نظر می‌رسد کلاینت دارای رزروهای ایستا است. موتور تخصیص تلاش خواهد کرد منابع رزروشده را برای کلاینت تخصیص دهد.
ALLOC_ENGINE_V6_ALLOC_NO_V6_HR
0.0
3.5
%1: unable to allocate reserved leases - no IPv6 reservations
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص تشخیص دهد کلاینت هیچ رزرو IPv6 ندارد و بنابراین موتور تخصیص باید برای تخصیص اجاره‌ها از استخر پویا تلاش کند، یا در صورتی که هیچ اجاره‌ای قابل تخصیص نباشد، فرایند تخصیص را متوقف سازد. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_ALLOC_UNRESERVED
0.0
3.5
no static reservations available - trying to dynamically allocate leases for client %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص برای تخصیص اجاره‌ها از استخرهای پویا تلاش کند. این امر ممکن است ناشی از یکی از موارد زیر باشد:
(الف) هیچ رزروی برای این کلاینت وجود ندارد، (ب) رزروهایی برای کلاینت وجود دارد اما قابل استفاده نیستند زیرا نشانی‌ها توسط کلاینت دیگری در حال استفاده هستند، یا (ج) اجاره‌ای رزروشده وجود داشته اما اکنون به کلاینت دیگری تخصیص داده شده است.
ALLOC_ENGINE_V6_CALCULATED_PREFERRED_LIFETIME
0.0
3.5
%1: using a calculated preferred-lifetime of %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که مقدار preferred-lifetime بازگردانده‌شده به کلاینت، به‌طور پیش‌فرض روی ۶۲٫۵٪ از valid-lifetime تنظیم می‌شود. این وضعیت ممکن است زمانی رخ دهد که preferred-lifetime به‌طور صریح پیکربندی نشده باشد، یا مقدار پیکربندی‌شده بزرگ‌تر از valid-lifetime باشد. آرگومان‌ها جزئیات کلاینت و preferred-lifetime مورد استفاده را مشخص می‌کنند..SS ALLOC_ENGINE_V6_DECLINED_RECOVERED
0.0
3.5
IPv6 address %1 was recovered after %2 seconds of probation-period
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که نشانی مشخص‌شده به عنوان تکراری گزارش شده است (کلاینت پیام DECLINE ارسال کرده) و کارساز این نشانی را برای مدت معینی به عنوان غیرقابل دسترس علامت‌گذاری کرده بود. این مدت‌زمان اکنون سپری شده و نشانی به مخزن نشانی‌های در دسترس بازگردانده شده است. این مرحله، فرآیند بازیابی رد (decline recovery) را به پایان می‌رساند.
ALLOC_ENGINE_V6_EXPIRED_HINT_RESERVED
0.0
3.5
%1: expired lease for the client's hint %2 is reserved for another client
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص (allocation engine) متوجه می‌شود اجارهٔ منقضی‌شده برای پیشنهاد (hint) کلاینت قابل استفادهٔ مجدد نیست، زیرا برای کلاینت دیگری رزرو شده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_EXTEND_ALLOC_UNRESERVED
0.0
3.5
allocate new (unreserved) leases for the renewing client %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص در تلاش است تا اجاره‌های جدیدی را برای کلاینت در حال تمدید تخصیص دهد، زیرا نتوانسته هیچ‌یک از اجاره‌های موجود کلاینت را تمدید کند؛ برای مثال به دلیل اینکه اجاره‌ها برای کلاینت دیگری رزرو شده‌اند یا به هر دلیل دیگری.
ALLOC_ENGINE_V6_EXTEND_ERROR
0.0
3.5
%1: allocation engine experienced error with attempting to extend lease lifetime: %2
168u
168u
این پیام خطا نشان می‌دهد که در حین پردازش Renew یا Rebind خطایی رخ داده است. توضیحات تکمیلی به همراه این پیام ارائه می‌شود. بسته به ماهیت خطا، ممکن است برای ادامهٔ پردازش پیام‌های این کلاینت خاص، به مداخلهٔ دستی نیاز باشد؛ سایر کلاینت‌ها تحت تأثیر قرار نخواهند گرفت. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_EXTEND_LEASE
0.0
3.5
%1: extending lifetime of the lease type %2, address %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص در حال تلاش برای افزایش طول عمر اجاره است. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_EXTEND_LEASE_DATA
0.0
3.5
%1: detailed information about the lease being extended: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاعات تفصیلی را دربارهٔ اجاره‌ای که طول عمر آن در حال افزایش است (renew یا rebind) چاپ می‌کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_EXTEND_NEW_LEASE_DATA
0.0
3.5
%1: new lease information for the lease being extended: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاعات به‌روزشده را دربارهٔ اجاره‌ای که قرار است تمدید شود چاپ می‌کند. در صورتی که به‌روزرسانی اجاره موفقیت‌آمیز باشد، اطلاعات چاپ‌شده توسط این پیام در پایگاه داده ذخیره خواهد شد. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_HINT_RESERVED
0.0
3.5
%1: lease for the client's hint %2 is reserved for another client
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص نمی‌تواند اجاره را با استفاده از پیشنهاد (hint) کلاینت تخصیص دهد، زیرا اجاره برای این پیشنهاد برای کلاینت دیگری رزرو شده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_HR_ADDR_GRANTED
0.0
3.5
reserved address %1 was assigned to client %2
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد نشانی که برای کلاینت مشخص‌شده رزرو شده بود، به آن اختصاص یافته است..SS ALLOC_ENGINE_V6_HR_PREFIX_GRANTED
0.0
3.5
reserved prefix %1/%2 was assigned to client %3
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که پیشوند رزرو شده برای کارخواه مشخص‌شده، به آن اختصاص یافته است.
ALLOC_ENGINE_V6_LEASES_RECLAMATION_COMPLETE
0.0
3.5
reclaimed %1 leases in %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که موتور تخصیص بازپس‌گیری مجموعه‌ای از اجاره‌های منقضی‌شده را به پایان برساند. بیشینه تعداد اجاره‌هایی که باید در یک دور از روال بازپس‌گیری اجاره‌ها بازپس گرفته شوند، با استفاده از پارامتر 'max-reclaim-leases' قابل پیکربندی است. با این حال، تعداد اجاره‌های بازپس‌گرفته‌شده ممکن است توسط مقدار مهلت زمانی (timeout) که با 'max-reclaim-time' پیکربندی شده نیز محدود شود. این پیام شامل تعداد اجاره‌های بازپس‌گرفته‌شده و کل زمان صرف‌شده است.
ALLOC_ENGINE_V6_LEASES_RECLAMATION_FAILED
0.0
3.5
reclamation of expired leases failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که بازپس‌گیری اجاره‌های منقضی‌شده ناموفق باشد.
پیام خطا نمایش داده می‌شود.
ALLOC_ENGINE_V6_LEASES_RECLAMATION_SLOW
0.0
3.5
expired leases still exist after %1 reclamations
168u
168u
این پیام هشدار زمانی صادر می‌شود که سرور نتواند تمام اجاره‌های منقضی‌شده را در تعداد مشخصی از تلاش‌های متوالی بازپس گیرد. این امر نشان می‌دهد که ممکن است مقدار "reclaim-timer-wait-time" بیش از حد بالا باشد. با این حال، اگر این موضوع تنها یک افزایش ناگهانی و کوتاه‌مدت در انقضای اجاره‌ها باشد نیازی به تغییر این مقدار نیست و سرور باید در تلاش‌های بعدی بازپس‌گیری با آن رسیدگی کند. اگر این وضعیت نتیجه افزایش دائمی بار سرور است، مقدار "reclaim-timer-wait-time" باید کاهش یابد، یا مقادیر "max-reclaim-leases" و "max-reclaim-time" باید افزایش یابند تا پردازش اجاره‌های بیشتری در یک چرخه امکان‌پذیر شود. روش دیگر این است که این مقادیر روی 0 تنظیم شوند تا محدودیت‌های مربوط به تعداد اجاره‌ها و مدت زمان حذف گردند. با این حال، این کار ممکن است منجر به دوره‌های طولانی‌تری از عدم پاسخگویی سرور به بسته‌های DHCP در زمان پردازش اجاره‌های منقضی‌شده شود.
ALLOC_ENGINE_V6_LEASES_RECLAMATION_START
0.0
3.5
starting reclamation of expired leases (limit = %1 leases or %2 milliseconds)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص بازپس‌گیری اجاره‌های منقضی‌شده را آغاز کند. بیشینه تعداد اجاره‌های قابل بازپس‌گیری و مهلت زمانی در پیام گنجانده شده‌اند. اگر هر یک از این مقادیر 0 باشد، به معنای "نامحدود" است.
ALLOC_ENGINE_V6_LEASES_RECLAMATION_TIMEOUT
0.0
3.5
timeout of %1 ms reached while reclaiming IPv6 leases
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص به مهلت زمانی تعیین‌شده برای انجام بازپس‌گیری اجاره‌های منقضی‌شده برسد. اکنون فرایند بازپس‌گیری متوقف خواهد شد و تمامی اجاره‌هایی که به دلیل پایان مهلت زمانی بازپس گرفته نشده‌اند، هنگام آغاز بازپس‌گیری زمان‌بندی‌شده بعدی بازپس گرفته خواهند شد. آرگومان، مقدار مهلت زمانی بیان‌شده بر حسب میلی‌ثانیه است.
ALLOC_ENGINE_V6_LEASE_RECLAIM
0.0
3.5
%1: reclaiming expired lease for prefix %2/%3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور بازپس‌گیری اجاره منقضی‌شده DHCPv6 را آغاز کند. اجاره بازپس‌گرفته‌شده ممکن است اجاره یک نشانی یا یک پیشوند واگذار شده (delegated prefix) باشد. آرگومان نخست، اطلاعات شناسایی کارخواه را ارائه می‌دهد. سایر آرگومان‌ها پیشوند و طول پیشوند را برای اجاره مشخص می‌کنند. طول پیشوند برای اجاره نشانی برابر با 128 است.
ALLOC_ENGINE_V6_LEASE_RECLAMATION_FAILED
0.0
3.5
failed to reclaim the lease %1: %2
168u
168u
این پیام خطا زمانی ثبت می‌شود که موتور تخصیص در بازپس‌گیری یک اجاره منقضی‌شده با شکست مواجه شود. علت شکست در پیام گنجانده شده است. این خطا ممکن است در قلاب انقضای اجاره (lease expiration hook) یا هنگام انجام عملیات روی پایگاه‌داده اجاره‌ها رخ داده باشد..SS ALLOC_ENGINE_V6_NO_MORE_EXPIRED_LEASES
0.0
3.5
all expired leases have been reclaimed
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور همهٔ اجاره‌های منقضی‌شدهٔ
DHCPv6 موجود در پایگاه‌داده را بازپس‌گیری (reclaim) کند.
ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE
0.0
3.5
begin deletion of reclaimed leases expired more than %1 seconds ago
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص (allocation engine)
حذف اجاره‌های بازپس‌گرفته‌شده‌ای را که بیش از تعداد ثانیه‌های مشخصی پیش
منقضی شده‌اند، آغاز کند. این عملیات به‌صورت دوره‌ای بر اساس پارامتر
"flush-reclaimed-timer-wait-time" راه‌اندازی می‌شود. پارامتر
"hold-reclaimed-time" مدت زمانی (بر حسب ثانیه) را تعیین می‌کند
که اجاره‌ها پیش از حذف شدن نهایی، نگهداری می‌شوند.
ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_COMPLETE
0.0
3.5
successfully deleted %1 expired-reclaimed leases
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور اجاره‌های "expired-reclaimed"
را با موفقیت از پایگاه‌دادهٔ اجاره‌ها حذف کند. تعداد اجاره‌های حذف‌شده در پیام لاگ
گنجانده می‌شود.
ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_FAILED
0.0
3.5
deletion of expired-reclaimed leases failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که حذف اجاره‌های "expired-reclaimed" از
پایگاه‌داده با شکست مواجه شود. پیام خطا به انتهای پیام لاگ اضافه می‌شود.
ALLOC_ENGINE_V6_RENEW_HR
0.0
3.5
allocating leases reserved for the client %1 as a result of Renew
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که موتور تخصیص در پاسخ به پیام Renew
تلاش می‌کند اجاره‌های رزروشده را به کلاینت اختصاص دهد. سرور همچنین هر
اجاره‌ای را که کلاینت سعی در تمدید آن دارد اما برای آن رزرو نشده است،
حذف خواهد کرد.
ALLOC_ENGINE_V6_RENEW_REMOVE_RESERVED
0.0
3.5
%1: checking if existing client's leases are reserved for another client
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص اجاره‌هایی برای کلاینت می‌یابد
و بررسی می‌کند که آیا این اجاره‌ها برای کلاینت دیگری رزرو شده‌اند یا خیر.
در صورت رزرو بودن، برای کلاینت درخواست‌کننده تمدید نخواهند شد. آرگومان اول
شامل اطلاعات شناسایی کلاینت است.
ALLOC_ENGINE_V6_REUSE_EXPIRED_LEASE_DATA
0.0
3.5
%1: reusing expired lease, updated lease information: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که موتور تخصیص در حال استفادهٔ مجدد از یک اجارهٔ
موجود است. جزئیات اجارهٔ به‌روزشده چاپ می‌شود. آرگومان اول شامل اطلاعات
شناسایی کلاینت است.
ALLOC_ENGINE_V6_REVOKED_ADDR_LEASE
0.0
3.5
%1: address %2 was revoked from client %3 as it is reserved for client %4
168u
168u
این پیام اطلاع‌رسانی نشان‌دهندهٔ آن است که نشانی IPv6 مشخص‌شده توسط client A
استفاده می‌شده، اما اکنون برای client B رزرو شده است. به client A اعلام شده است
که استفاده از آن را متوقف کند تا بتوان آن را به client B اجاره داد. این یک رویداد
عادی هنگام رفع تعارض است که می‌تواند در مواردی مانند افزودن یک رزرو جدید توسط
مدیر سیستم برای نشانی‌ای که هم‌اکنون توسط کلاینت دیگری استفاده می‌شود، رخ دهد.
سرور وضعیت را به‌طور کامل مدیریت و بازیابی خواهد کرد، اما کلاینت‌ها نشانی‌های خود
را تغییر خواهند داد..SS ALLOC_ENGINE_V6_REVOKED_PREFIX_LEASE
0.0
3.5
%1: prefix %2/%3 was revoked from client %4 as it is reserved for client %5
168u
168u
این پیام اطلاعاتی نشان‌دهنده آن است که پیشوند IPv6 مشخص‌شده توسط کلاینت A در حال استفاده بود، اما اکنون برای کلاینت B رزرو شده است. به کلاینت A اعلام شده که استفاده از آن را متوقف کند تا بتوان آن را به کلاینت B اجاره داد. این یک رخداد عادی در حین رفع تداخل است که می‌تواند در مواردی مانند افزودن رزرو توسط مدیر سیستم برای نشانی‌ای که در حال حاضر توسط کلاینت دیگری استفاده می‌شود، رخ دهد. کارساز به‌طور کامل از این وضعیت بازیابی خواهد شد، اما کلاینت‌ها پیشوندهای خود را تغییر خواهند داد.
ALLOC_ENGINE_V6_REVOKED_SHARED_ADDR_LEASE
0.0
3.5
%1: address %2 was revoked from client %3 as it is reserved for %4 other clients
168u
168u
این پیام اطلاعاتی نشان‌دهنده آن است که نشانی IPv6 مشخص‌شده توسط کلاینت A در حال استفاده بود، اما اکنون برای چندین کلاینت دیگر رزرو شده است. به کلاینت A اعلام شده که استفاده از آن را متوقف کند تا بتوان آن را به یکی از کلاینت‌هایی که برای آن رزرو دارند اجاره داد. این یک رخداد عادی در حین رفع تداخل است که می‌تواند در مواردی مانند افزودن رزروها توسط مدیر سیستم برای نشانی‌ای که در حال حاضر توسط کلاینت دیگری استفاده می‌شود، رخ دهد. کارساز به‌طور کامل از این وضعیت بازیابی خواهد شد، اما کلاینت‌ها نشانی‌های خود را تغییر خواهند داد.
ALLOC_ENGINE_V6_REVOKED_SHARED_PREFIX_LEASE
0.0
3.5
%1: prefix %2/%3 was revoked from client %4 as it is reserved for %5 other clients
168u
168u
این پیام اطلاعاتی نشان‌دهنده آن است که پیشوند IPv6 مشخص‌شده توسط کلاینت A در حال استفاده بود، اما اکنون برای چندین کلاینت دیگر رزرو شده است. به کلاینت A اعلام شده که استفاده از آن را متوقف کند تا بتوان آن را به یکی از کلاینت‌هایی که برای آن رزرو دارند اجاره داد. این یک رخداد عادی در حین رفع تداخل است که می‌تواند در مواردی مانند افزودن رزروها توسط مدیر سیستم برای نشانی‌ای که در حال حاضر توسط کلاینت دیگری استفاده می‌شود، رخ دهد. کارساز به‌طور کامل از این وضعیت بازیابی خواهد شد، اما کلاینت‌ها پیشوندهای خود را تغییر خواهند داد.
ASIODNS
ASIODNS_FETCH_COMPLETED
0.0
3.5
upstream fetch to %1(%2) has now completed
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۷۰ ثبت می‌شود.
یک پیام اشکال‌زدایی؛ این پیام ثبت می‌کند که واکشی بالادستی (پرس‌وجویی که توسط resolver از جانب کلاینت آن انجام می‌شود) به نشانی مشخص‌شده پایان یافته است.
ASIODNS_FETCH_STOPPED
0.0
3.5
upstream fetch to %1(%2) has been stopped
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
یک مؤلفه خارجی درخواست توقف یک واکشی بالادستی را داده است. این یک عملیات مجاز است و پیام تنها در صورتی باید ظاهر شود که اشکال‌زدایی فعال باشد.
ASIODNS_OPEN_SOCKET
0.0
3.5
error %1 opening %2 socket to %3(%4)
168u
168u
کد ورودی/خروجی ناهمگام (asynchronous I/O) هنگام تلاش برای باز کردن یک سوکت با پروتکل مشخص‌شده به منظور ارسال یک پیام به نشانی هدف، با خطا مواجه شد. شماره خطای سیستمی که باعث این مشکل شده در پیام ذکر شده است.
ASIODNS_READ_DATA
0.0
3.5
error %1 reading %2 data from %3(%4)
168u
168u
کد ورودی/خروجی ناهمگام (asynchronous I/O) هنگام تلاش برای خواندن داده‌ها از نشانی مشخص‌شده روی پروتکل داده‌شده، با خطا مواجه شد. شماره خطای سیستمی که باعث این مشکل شده در پیام ذکر شده است.
ASIODNS_READ_TIMEOUT
0.0
3.5
receive timeout while waiting for data from %1(%2)
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
مهلت زمانی یک واکشی بالادستی از نشانی مشخص‌شده به پایان رسید (timed out). این رویداد ممکن است به دلایل مختلفی رخ دهد و به احتمال زیاد مشکلی در کارساز دوردست یا مشکلی در شبکه است. این پیام تنها در صورتی ظاهر می‌شود که اشکال‌زدایی فعال باشد..SS ASIODNS_SEND_DATA
0.0
3.5
error %1 sending data using %2 to %3(%4)
168u
168u
کد I/O ناهمگام هنگام تلاش برای ارسال داده به نشانی مشخص‌شده روی پروتکل داده‌شده، با خطا مواجه شد. شماره خطای سیستمی که باعث بروز مشکل شده است در پیام ذکر می‌شود.
ASIODNS_UNKNOWN_ORIGIN
0.0
3.5
unknown origin for ASIO error code %1 (protocol: %2, address %3)
168u
168u
یک بررسی سازگاری داخلی در مورد مبدأ پیامی از ماژول I/O ناهمگام با شکست مواجه شد. این موضوع ممکن است نشان‌دهنده یک خطای داخلی باشد؛ لطفاً یک گزارش باگ ارسال کنید.
ASIODNS_UNKNOWN_RESULT
0.0
3.5
unknown result (%1) when IOFetch::stop() was executed for I/O to %2(%3)
168u
168u
یک خطای داخلی که نشان می‌دهد متد خاتمه کلاس بازیابی بالادست (upstream fetch) مربوط به کارساز تحلیل‌گر (resolver) با یک کد نتیجه ناشناخته (که در پیام ذکر شده است) فراخوانی شده است. لطفاً یک گزارش باگ ارسال کنید.
BAD
BAD_CLIENT_CREDENTIALS
0.0
3.5
bad client credentials: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که پردازش اعتبارنامه کلاینت با شکست مواجه شده باشد، از جمله زمانی که طول عمر باقی‌مانده اعتبارنامه از طول عمر TKEY کوتاه‌تر باشد. آرگومان، جزئیات خطا را شرح می‌دهد.
BOOTP
BOOTP_BOOTP_QUERY
0.0
3.5
recognized a BOOTP query: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که پرس‌وجوی BOOTP شناسایی شده باشد. کلاس کلاینت BOOTP اضافه شده و نوع پیام روی DHCPREQUEST تنظیم می‌شود. مشخصات کلاینتِ پرس‌وجو و شناسه تراکنش نمایش داده می‌شوند.
BOOTP_LOAD
0.0
3.5
Bootp hooks library has been loaded
168u
168u
این پیام اطلاع‌رسانی (info) نشان می‌دهد که کتابخانه قلاب‌های Bootp بارگیری شده است.
BOOTP_PACKET_OPTIONS_SKIPPED
0.0
3.5
an error unpacking an option, caused subsequent options to be skipped: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازگشایی (unpack) یک گزینه با شکست مواجه شده و بازگشایی گزینه‌های باقی‌مانده در پرس‌وجوی DHCPv4 را غیرممکن سازد. کارساز همچنان برای پاسخ‌گویی به بسته تلاش خواهد کرد. تنها آرگومان، دلیل خطای بازگشایی را مشخص می‌کند.
BOOTP_PACKET_PACK
0.0
3.5
%1: preparing on-wire format of the packet to be sent
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز آماده‌سازی قالب انتقال روی سیم (on-wire) بسته‌ای را که باید به کلاینت پس فرستاده شود، آغاز می‌کند. آرگومان، اطلاعات کلاینت و شناسه تراکنش را مشخص می‌کند.
BOOTP_PACKET_PACK_FAIL
0.0
3.5
%1: preparing on-wire-format of the packet to be sent failed %2
168u
168u
این پیام خطا زمانی صادر می‌شود که آماده‌سازی قالب انتقال روی سیم (on-wire) بسته ناموفق بوده باشد. آرگومان نخست، کلاینت و تراکنش BOOTP را مشخص می‌کند. آرگومان دوم شامل رشته خطا است..SS BOOTP_PACKET_UNPACK_FAILED
0.0
3.5
failed to parse query from %1 to %2, received over interface %3, reason: %4
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv4 دریافتی بدقواره (malformed) بوده و نتواند توسط فراخوان buffer4_receive تجزیه شود. پرس‌وجو توسط سرور دور انداخته خواهد شد. سه آرگومان نخست نشانی IP مبدأ، نشانی IP مقصد و رابط شبکه را مشخص می‌کنند. آرگومان پایانی دلیل شکست را بیان می‌کند.
BOOTP_UNLOAD
0.0
3.5
Bootp hooks library has been unloaded
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های Bootp از حافظه تخلیه شده است.
BULK
BULK_LEASE_QUERY4_UNSUPPORTED_MSG_TYPE
0.0
3.5
Dropping packet with an unsupported DHCPv4 message type %1 received from: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که نوع بسته‌ای از DHCPv4 دریافت شود که قلاب پرس‌وجوی اجاره (lease query hook) از آن پشتیبانی نمی‌کند. آرگومان نخست نوع پیام پشتیبانی‌نشده و آرگومان دوم نشانی دوردست (remote address) اتصالی است که بسته خواهد شد.
BULK_LEASE_QUERY6_UNSUPPORTED_MSG_TYPE
0.0
3.5
Dropping packet with an unsupported DHCPv6 message type %1 received from: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که نوع بسته‌ای از DHCPv6 دریافت شود که قلاب پرس‌وجوی اجاره (lease query hook) از آن پشتیبانی نمی‌کند. آرگومان نخست نوع پیام پشتیبانی‌نشده و آرگومان دوم نشانی دوردست (remote address) اتصالی است که بسته خواهد شد.
BULK_LEASE_QUERY_AT_MAX_CONCURRENT_QUERIES
0.0
3.5
Queuing query from: %1, details: %2, connection already has %3 queries in progress
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک درخواست‌کننده، یک پرس‌وجوی اجاره دسته‌ای (bulk lease query) را روی اتصالی ارسال کند که در حال حاضر حداکثر تعداد مجاز پرس‌وجوهای در حال انجام را دارد. آرگومان نخست نشانی درخواست‌کننده، دومی جزئیات پرس‌وجوی صف‌بندی‌شده و سومی مقدار max-concurrent-queries است.
BULK_LEASE_QUERY_DEQUEUED
0.0
3.5
A query from %1, details: %2, dequeued.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک پرس‌وجو از صف خارج شده و پردازش خواهد شد. آرگومان نخست نشانی درخواست‌کننده و آرگومان دوم جزئیات پرس‌وجویی است که از صف خارج شده است.
BULK_LEASE_QUERY_DUPLICATE_XID
0.0
3.5
Dropping query from: %1, transaction id %2 is a duplicate
168u
168u
این پیام هشدار زمانی صادر می‌شود که یک درخواست‌کننده، پرس‌وجوی اجاره دسته‌ای با همان شناسه تراکنش (transaction id) ارسال کند، در حالی که آن درخواست‌کننده هم‌اکنون پرس‌وجویی با همان شناسه تراکنش در حال انجام دارد. آرگومان نخست نشانی درخواست‌کننده و دومی شناسه تراکنش تکراری است.
BULK_LEASE_QUERY_EMPTY_REQUEST
0.0
3.5
A bulk lease query packet received from %1 is empty.
168u
168u
این پیام خطا زمانی صادر می‌شود که بسته پرس‌وجوی اجاره دسته‌ای فاقد بار داده (payload) دریافت شود. این آرگومان حاوی نشانی دوردست اتصالی است که بسته خواهد شد.
BULK_LEASE_QUERY_INVALID_REQUEST
0.0
3.5
A bulk lease query packet received from %1 is invalid, query: %2, error: %3
168u
168u
این پیام خطا هنگام دریافت بسته نامعتبر پرس‌وجوی اجاره دسته‌ای صادر می‌شود. آرگومان نخست نشانی دوردست اتصالی است که بسته خواهد شد، دومی پرس‌وجو، و آرگومان پایانی پیام خطا است..SS BULK_LEASE_QUERY_LISTENER_START_FAILED
0.0
3.5
Bulk lease query listener thread pool could not be started, error %1
168u
168u
این پیام خطا زمانی صادر می‌شود که استخر ریسه‌های شنونده‌ی bulk lease query نتواند پس از یک رخداد پیکربندی مجدد، (مجدداً) راه‌اندازی شود. محتمل‌ترین علت می‌تواند یک خطای پیکربندی در زمان اجرا باشد؛ مانند یک آدرس IP که نامعتبر است یا هم‌اکنون به عنوان آدرس سرویس در حال استفاده است. این آرگومان جزئیات خطا را شرح می‌دهد.
BULK_LEASE_QUERY_PAUSE_CHECK_PERMISSIONS_FAILED
0.0
3.5
An unexpected error occurred while checking pause permissions, error %1
168u
168u
این پیام خطا هنگام تلاش برای متوقف کردن موقت (pause) شنونده‌ی Bulk Lease Query صادر می‌شود. رخ دادن این خطا بسیار دور از انتظار است و نشان‌دهنده‌ی یک اشکال برنامه‌نویسی است که باید به عنوان یک نقص گزارش شود.
BULK_LEASE_QUERY_PAUSE_LISTENER_FAILED
0.0
3.5
Listener could not be paused, error %1
168u
168u
این پیام خطا هنگام تلاش برای متوقف کردن موقت (pause) شنونده‌ی Bulk Lease Query صادر می‌شود. رخ دادن این خطا بسیار دور از انتظار است و نشان‌دهنده‌ی یک اشکال برنامه‌نویسی است که باید به عنوان یک نقص گزارش شود.
BULK_LEASE_QUERY_PAUSE_LISTENER_ILLEGAL
0.0
3.5
Pausing multi-threaded processing failed: %1
168u
168u
این پیام خطا هنگام تلاش برای متوقف کردن موقت استخر ریسه‌های (thread pool) شنونده‌ی bulk lease query از طریق یک ریسه‌ی کارگر (worker thread) صادر می‌شود. این خطا نشان می‌دهد عملیاتی که روی ریسه‌ی شنونده آغاز شده، تلاش می‌کند از یک بخش بحرانی (critical section) استفاده کند که منجر به بن‌بست (dead-lock) خواهد شد. رخ دادن این خطا بسیار دور از انتظار است و نشان‌دهنده‌ی یک اشکال برنامه‌نویسی است که باید به عنوان یک نقص گزارش شود.
BULK_LEASE_QUERY_PROCESSING_UNEXPECTED_FAILURE
0.0
3.5
A bulk lease query packet processing throws unexpected exception: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که پردازش بسته‌ی bulk lease query دچار استثنا (exception) شود. این استثنا نمایش داده می‌شود.
BULK_LEASE_QUERY_QUERY_RECEIVED
0.0
3.5
A bulk lease query packet received from %1, details: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک استعلام bulk lease query دریافت شده باشد. آرگومان نخست، آدرسی است که بسته را ارسال کرده و دومی جزئیات بسته را شرح می‌دهد.
BULK_LEASE_QUERY_REJECTED_CONNECTION
0.0
3.5
A new bulk lease query connection from %1 was rejected: %2
168u
168u
این پیام اشکال‌زدایی هنگامی صادر می‌شود که یک اتصال جدید bulk lease query رد شده باشد. آدرس کلاینت و پیام خطا نمایش داده می‌شوند.
BULK_LEASE_QUERY_RESPONSE_SEND_ERROR
0.0
3.5
A bulk lease query response could not be sent to: %1, response: %2, error: %3
168u
168u
این پیام اشکال‌زدایی زمانی صادر می‌شود که تلاش سرور برای ارسال پاسخ استعلام با شکست مواجه شده باشد. آرگومان نخست، آدرسی است که پاسخ برای آن ارسال می‌شد، دومی حاوی جزئیات پاسخ است و سومی توضیح خطا می‌باشد.
BULK_LEASE_QUERY_RESPONSE_SENT
0.0
3.5
A bulk lease query response sent to %1, details: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که یک پاسخ bulk lease query ارسال شده باشد. آرگومان نخست، آدرسی است که بسته به آن ارسال شده و دومی جزئیات بسته را شرح می‌دهد..SS BULK_LEASE_QUERY_RESUME_LISTENER_FAILED
0.0
3.5
Listener could not be resumed, error %1
168u
168u
این پیام خطا هنگام تلاش برای ازسرگیری شنوندهٔ (listener) مربوط به Bulk Lease Query صادر می‌شود. وقوع این خطا بسیار بعید است و نشان‌دهندهٔ یک مشکل نرم‌افزاری است که باید به عنوان یک نقص (باگ) گزارش شود.
BULK_LEASE_QUERY_UNPACK_ERROR
0.0
3.5
A bulk lease query packet received from %1, could not be unpacked, error: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که بستهٔ پرس‌وجوی اجارهٔ انبوه (bulk lease query) دریافت‌شده ناقص یا معیوب (malformed) باشد و نتوان آن را بازگشایی کرد. آرگومان اول نشانی راه دور اتصالی است که بسته خواهد شد و آرگومان دوم شرح خطا را نشان می‌دهد.
CB
CB_CMDS_CLASS4_DEL_HANDLER_FAILED
0.0
3.5
remote-class4-del command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ (handler) دستور remote-class4-del هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
CB_CMDS_CLASS4_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-class4-get-all command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-class4-get-all هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
CB_CMDS_CLASS4_GET_HANDLER_FAILED
0.0
3.5
remote-class4-get command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-class4-get هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
CB_CMDS_CLASS4_SET_HANDLER_FAILED
0.0
3.5
remote-class4-set command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-class4-set هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
CB_CMDS_CLASS6_DEL_HANDLER_FAILED
0.0
3.5
remote-class6-del command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-class6-del هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
CB_CMDS_CLASS6_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-class6-get-all command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-class6-get-all هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
CB_CMDS_CLASS6_GET_HANDLER_FAILED
0.0
3.5
remote-class6-get command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-class6-get هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
CB_CMDS_CLASS6_SET_HANDLER_FAILED
0.0
3.5
remote-class6-set command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-class6-set هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند..SS CB_CMDS_DEINIT_OK
0.0
3.5
unloading cb_cmds hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های Config Commands با موفقیت از حافظه تخلیه شده است.
CB_CMDS_GLOBAL_PARAMETER4_DEL_HANDLER_FAILED
0.0
3.5
remote-global-parameter4-del command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter4-del هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_GLOBAL_PARAMETER4_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-global-parameter4-get-all command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter4-get-all هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_GLOBAL_PARAMETER4_GET_HANDLER_FAILED
0.0
3.5
remote-global-parameter4-get command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter4-get هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_GLOBAL_PARAMETER4_SET_HANDLER_FAILED
0.0
3.5
remote-global-parameter4-set command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter4-set هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_GLOBAL_PARAMETER6_DEL_HANDLER_FAILED
0.0
3.5
remote-global-parameter6-del command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter6-del هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_GLOBAL_PARAMETER6_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-global-parameter6-get-all command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter6-get-all هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_GLOBAL_PARAMETER6_GET_HANDLER_FAILED
0.0
3.5
remote-global-parameter6-get command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter6-get هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_GLOBAL_PARAMETER6_SET_HANDLER_FAILED
0.0
3.5
remote-global-parameter6-set command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-parameter6-set هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
CB_CMDS_INIT_OK
0.0
3.5
loading cb_cmds hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های Config Commands با موفقیت بارگذاری شده است. لذت ببرید!.SS CB_CMDS_NETWORK4_DEL_HANDLER_FAILED
0.0
3.5
remote-network4-del command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network4-del هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_NETWORK4_GET_HANDLER_FAILED
0.0
3.5
remote-network4-get command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network4-get هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_NETWORK4_LIST_HANDLER_FAILED
0.0
3.5
remote-network4-list command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network4-list هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_NETWORK4_SET_HANDLER_FAILED
0.0
3.5
remote-network4-set command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network4-set هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_NETWORK6_DEL_HANDLER_FAILED
0.0
3.5
remote-network6-del command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network6-del هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_NETWORK6_GET_HANDLER_FAILED
0.0
3.5
remote-network6-get command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network6-get هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_NETWORK6_LIST_HANDLER_FAILED
0.0
3.5
remote-network6-list command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network6-list هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_NETWORK6_SET_HANDLER_FAILED
0.0
3.5
remote-network6-set command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-network6-set هنگام
پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION4_GLOBAL_DEL_HANDLER_FAILED
0.0
3.5
remote-global-option4-del command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-global-option4-del
هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را
مشخص می‌کند.
CB_CMDS_OPTION4_GLOBAL_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-global-option4-get-all command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور remote-global-option4-get-all
هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را
مشخص می‌کند..SS CB_CMDS_OPTION4_GLOBAL_GET_HANDLER_FAILED
0.0
3.5
remote-global-option4-get command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-global-option4-get
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION4_GLOBAL_SET_HANDLER_FAILED
0.0
3.5
remote-global-option4-set command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-global-option4-set
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION4_NETWORK_DEL_HANDLER_FAILED
0.0
3.5
remote-network-option4-del command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-network-option4-del
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION4_NETWORK_SET_HANDLER_FAILED
0.0
3.5
remote-network-option4-set command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-network-option4-set
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION4_POOL_DEL_HANDLER_FAILED
0.0
3.5
remote-pool-option4-del command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-pool-option4-del
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION4_POOL_SET_HANDLER_FAILED
0.0
3.5
remote-pool-option4-set command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-pool-option4-set
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION4_SUBNET_DEL_HANDLER_FAILED
0.0
3.5
remote-subnet-option4-del command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-subnet-option4-del
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION4_SUBNET_SET_HANDLER_FAILED
0.0
3.5
remote-subnet-option4-set command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-subnet-option4-set
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION6_GLOBAL_DEL_HANDLER_FAILED
0.0
3.5
remote-global-option6-del command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-global-option6-del
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند.
CB_CMDS_OPTION6_GLOBAL_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-global-option6-get-all command failed: %1
168u
168u
این پیام خطا بیانگر آن است که گردانندهٔ دستور remote-global-option6-get-all
در حین پردازش دستور با شکست مواجه شده است. آرگومان، علت شکست
را مشخص می‌کند..SS CB_CMDS_OPTION6_GLOBAL_GET_HANDLER_FAILED
0.0
3.5
remote-global-option6-get command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-option6-get هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_GLOBAL_SET_HANDLER_FAILED
0.0
3.5
remote-global-option6-set command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-global-option6-set هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_NETWORK_DEL_HANDLER_FAILED
0.0
3.5
remote-network-option6-del command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-network-option6-del هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_NETWORK_SET_HANDLER_FAILED
0.0
3.5
remote-network-option6-set command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-network-option6-set هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_PD_POOL_DEL_HANDLER_FAILED
0.0
3.5
remote-pd-pool-option6-del command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-pd-pool-option6-del هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_PD_POOL_SET_HANDLER_FAILED
0.0
3.5
remote-pd-pool-option6-set command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-pd-pool-option6-set هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_POOL_DEL_HANDLER_FAILED
0.0
3.5
remote-pool-option6-del command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-pool-option6-del هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_POOL_SET_HANDLER_FAILED
0.0
3.5
remote-pool-option6-set command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-pool-option6-set هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_SUBNET_DEL_HANDLER_FAILED
0.0
3.5
remote-subnet-option6-del command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-subnet-option6-del هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد.
CB_CMDS_OPTION6_SUBNET_SET_HANDLER_FAILED
0.0
3.5
remote-subnet-option6-set command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور remote-subnet-option6-set هنگام پردازش دستور ناموفق بوده است. آرگومان، دلیل شکست را ارائه می‌دهد..SS CB_CMDS_OPTION_DEF4_DEL_HANDLER_FAILED
0.0
3.5
remote-option-def4-del command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def4-del هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION_DEF4_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-option-def4-get-all command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def4-get-all هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION_DEF4_GET_HANDLER_FAILED
0.0
3.5
remote-option-def4-get command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def4-get هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION_DEF4_SET_HANDLER_FAILED
0.0
3.5
remote-option-def4-set command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def4-set هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION_DEF6_DEL_HANDLER_FAILED
0.0
3.5
remote-option-def6-del command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def6-del هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION_DEF6_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-option-def6-get-all command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def6-get-all هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION_DEF6_GET_HANDLER_FAILED
0.0
3.5
remote-option-def6-get command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def6-get هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_OPTION_DEF6_SET_HANDLER_FAILED
0.0
3.5
remote-option-def6-set command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-option-def6-set هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_SERVER4_DEL_HANDLER_FAILED
0.0
3.5
remote-server4-del command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-server4-del هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند.
CB_CMDS_SERVER4_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-server4-get-all command failed: %1
168u
168u
این پیام خطا برای نشان دادن این صادر می‌شود که گرداننده دستور remote-server4-get-all هنگام پردازش دستور با شکست مواجه شده است. آرگومان ارائه‌شده دلیل شکست را مشخص می‌کند..SS CB_CMDS_SERVER4_GET_HANDLER_FAILED
0.0
3.5
remote-server4-get command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-server4-get
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SERVER4_SET_HANDLER_FAILED
0.0
3.5
remote-server4-set command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-server4-set
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SERVER6_DEL_HANDLER_FAILED
0.0
3.5
remote-server6-del command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-server6-del
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SERVER6_GET_ALL_HANDLER_FAILED
0.0
3.5
remote-server6-get-all command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-server6-get-all
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SERVER6_GET_HANDLER_FAILED
0.0
3.5
remote-server6-get command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-server6-get
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SERVER6_SET_HANDLER_FAILED
0.0
3.5
remote-server6-set command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-server6-set
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SUBNET4_DEL_BY_ID_HANDLER_FAILED
0.0
3.5
remote-subnet4-del-by-id command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-subnet4-del-by-id
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SUBNET4_DEL_BY_PREFIX_HANDLER_FAILED
0.0
3.5
remote-subnet4-del-by-prefix command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-subnet4-del-by-prefix
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SUBNET4_GET_BY_ID_HANDLER_FAILED
0.0
3.5
remote-subnet4-get-by-id command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-subnet4-get-by-id
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد.
CB_CMDS_SUBNET4_GET_BY_PREFIX_HANDLER_FAILED
0.0
3.5
remote-subnet4-get-by-prefix command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور remote-subnet4-get-by-prefix
هنگام پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را
ارائه می‌دهد..SS CB_CMDS_SUBNET4_LIST_HANDLER_FAILED
0.0
3.5
remote-subnet4-list command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet4-list
هنگام پردازش دستور با شکست مواجه شده است. آرگومان،
دلیل این شکست را مشخص می‌کند.
CB_CMDS_SUBNET4_SET_HANDLER_FAILED
0.0
3.5
remote-subnet4-set command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet4-set
هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل این
شکست را مشخص می‌کند.
CB_CMDS_SUBNET6_DEL_BY_ID_HANDLER_FAILED
0.0
3.5
remote-subnet6-del-by-id command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet6-del-by-id
هنگام پردازش دستور با شکست مواجه شده است. آرگومان،
دلیل این شکست را مشخص می‌کند.
CB_CMDS_SUBNET6_DEL_BY_PREFIX_HANDLER_FAILED
0.0
3.5
remote-subnet6-del-by-prefix command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet6-del-by-prefix
هنگام پردازش دستور با شکست مواجه شده است. آرگومان،
دلیل این شکست را مشخص می‌کند.
CB_CMDS_SUBNET6_GET_BY_ID_HANDLER_FAILED
0.0
3.5
remote-subnet6-get-by-id command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet6-get-by-id
هنگام پردازش دستور با شکست مواجه شده است. آرگومان،
دلیل این شکست را مشخص می‌کند.
CB_CMDS_SUBNET6_GET_BY_PREFIX_HANDLER_FAILED
0.0
3.5
remote-subnet6-get-by-prefix command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet6-get-by-prefix
هنگام پردازش دستور با شکست مواجه شده است. آرگومان،
دلیل این شکست را مشخص می‌کند.
CB_CMDS_SUBNET6_LIST_HANDLER_FAILED
0.0
3.5
remote-subnet6-list command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet6-list
هنگام پردازش دستور با شکست مواجه شده است. آرگومان،
دلیل این شکست را مشخص می‌کند.
CB_CMDS_SUBNET6_SET_HANDLER_FAILED
0.0
3.5
remote-subnet6-set command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور remote-subnet6-set
هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل این
شکست را مشخص می‌کند.
CLASS
CLASS_CMDS_CLASS_ADD
0.0
3.5
class added: %1
168u
168u
دستور class-add با موفقیت اجرا شد. تعریف کلاس
اضافه‌شده در لاگ ثبت می‌شود.
CLASS_CMDS_CLASS_ADD_FAILED
0.0
3.5
failed to add a new class: %1
168u
168u
دستور class-add با شکست مواجه شد. علت شکست
درون پیام خطا ارائه شده است..SS CLASS_CMDS_CLASS_ADD_HANDLER_FAILED
0.0
3.5
failed to run handler for 'class-add' command
168u
168u
این پیام خطا زمانی در گزارش ثبت می‌شود که کتابخانه قلاب‌های class_cmds با یک خطای غیرمنتظره مواجه شود و اجرای گردانندهٔ دستور 'class-add' با شکست مواجه گردد.
CLASS_CMDS_CLASS_DEL
0.0
3.5
class deleted: %1
168u
168u
دستور class-del موفقیت‌آمیز بوده است. نام کلاس حذف‌شده در گزارش ثبت می‌شود.
CLASS_CMDS_CLASS_DEL_EMPTY
0.0
3.5
class not deleted (not found): %1
168u
168u
دستور class-del هیچ کلاس منطبقی پیدا نکرد. نام کلاسی که قرار بود حذف شود در گزارش ثبت می‌شود.
CLASS_CMDS_CLASS_DEL_FAILED
0.0
3.5
failed to delete a class: %1
168u
168u
دستور class-del با شکست مواجه شد. علت شکست در پیام خطا ذکر شده است.
CLASS_CMDS_CLASS_DEL_HANDLER_FAILED
0.0
3.5
failed to run handler for 'class-del' command
168u
168u
این پیام خطا زمانی در گزارش ثبت می‌شود که کتابخانه قلاب‌های class_cmds با یک خطای غیرمنتظره مواجه شود و اجرای گردانندهٔ دستور 'class-del' با شکست مواجه گردد.
CLASS_CMDS_CLASS_GET
0.0
3.5
successfully retrieved a class: %1
168u
168u
دستور class-get موفقیت‌آمیز بوده است. نام کلاس دریافت‌شده در گزارش ثبت می‌شود.
CLASS_CMDS_CLASS_GET_EMPTY
0.0
3.5
specified class was not found: %1
168u
168u
دستور class-get هیچ کلاس منطبقی پیدا نکرد. نام کلاس جست‌وجوشده در گزارش ثبت می‌شود.
CLASS_CMDS_CLASS_GET_FAILED
0.0
3.5
failed to retrieve a class: %1
168u
168u
دستور class-get با شکست مواجه شد. علت شکست در پیام خطا ذکر شده است.
CLASS_CMDS_CLASS_GET_HANDLER_FAILED
0.0
3.5
failed to run handler for 'class-get' command
168u
168u
این پیام خطا زمانی در گزارش ثبت می‌شود که کتابخانه قلاب‌های class_cmds با یک خطای غیرمنتظره مواجه شود و اجرای گردانندهٔ دستور 'class-get' با شکست مواجه گردد.
CLASS_CMDS_CLASS_LIST
0.0
3.5
successfully retrieved classes names
168u
168u
دستور class-list موفقیت‌آمیز بوده است.
CLASS_CMDS_CLASS_LIST_EMPTY
0.0
3.5
no class was found
168u
168u
دستور class-list هیچ کلاسی پیدا نکرد..SS CLASS_CMDS_CLASS_LIST_FAILED
0.0
3.5
failed to retrieve classes names: %1
168u
168u
دستور class-list با شکست مواجه شد. علت شکست در متن پیام خطا ارائه شده است.
CLASS_CMDS_CLASS_LIST_HANDLER_FAILED
0.0
3.5
failed to run handler for 'class-list' command
168u
168u
این پیام خطا زمانی ثبت می‌شود که کتابخانه قلاب‌های class_cmds با خطایی غیرمنتظره در هنگام شکست اجرای گرداننده (handler) دستور 'class-list' مواجه شود.
CLASS_CMDS_CLASS_UPDATE
0.0
3.5
class updated: %1
168u
168u
دستور class-update با موفقیت انجام شد. پارامترهای کلاس به‌روزشده ثبت می‌شوند.
CLASS_CMDS_CLASS_UPDATE_EMPTY
0.0
3.5
class not updated (not found): %1
168u
168u
دستور class-update هیچ کلاس منطبقی پیدا نکرد. نام کلاسی که قرار بود به‌روزرسانی شود ثبت می‌شود.
CLASS_CMDS_CLASS_UPDATE_FAILED
0.0
3.5
failed to update a class: %1
168u
168u
دستور class-update با شکست مواجه شد. علت شکست در متن پیام خطا ارائه شده است.
CLASS_CMDS_CLASS_UPDATE_HANDLER_FAILED
0.0
3.5
failed to run handler for 'class-update' command
168u
168u
این پیام خطا زمانی ثبت می‌شود که کتابخانه قلاب‌های class_cmds با خطایی غیرمنتظره در هنگام شکست اجرای گرداننده دستور 'class-update' مواجه شود.
CLASS_CMDS_DEINIT_OK
0.0
3.5
unloading Class Commands hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های Class Commands با موفقیت حذف شده است.
CLASS_CMDS_INIT_FAILED
0.0
3.5
loading Class Commands hooks library failed: %1
168u
168u
این پیام خطا نشان‌دهنده بروز خطا در بارگذاری کتابخانه قلاب‌های Class Commands است. جزئیات خطا به عنوان آرگومان پیام ثبت گزارش ارائه شده است.
CLASS_CMDS_INIT_OK
0.0
3.5
loading Class Commands hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های Class Commands با موفقیت بارگذاری شده است. لذت ببرید!
COMMAND
COMMAND_ACCEPTOR_START
0.0
3.5
Starting to accept connections via unix domain socket bound to %1
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کارگزار Kea یک پذیرنده (acceptor) را راه‌اندازی می‌کند که از طریق آن اتصالات کنترلی جدید را خواهد پذیرفت. این پذیرنده به نقطه پایانی مرتبط با نام فایل ارائه‌شده به عنوان آرگومان، متصل (bound) می‌شود. در صورتی که شروع به کار پذیرنده با شکست مواجه شود، پیام‌های خطای بعدی علت شکست را ارائه خواهند داد..SS COMMAND_DEREGISTERED
0.0
3.5
Command %1 deregistered
168u
168u
در سطح لاگ debug ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دیمن (daemon) پشتیبانی از دستور مشخص‌شده را
متوقف کرده است. این دستور دیگر قابل اجرا نیست. اگر سوکت دستورات باز باشد و این
دستور صادر شود، دیمن قادر به پردازش آن نخواهد بود.
COMMAND_EXTENDED_REGISTERED
0.0
3.5
Command %1 registered
168u
168u
در سطح لاگ debug ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دیمن پشتیبانی از دستور مشخص‌شده را آغاز کرده
است. گردانندهٔ (handler) دستور ثبت‌شده شامل پارامتری است که کل دستورِ آماده برای
پردازش را در خود نگه می‌دارد.
COMMAND_HTTP_LISTENER_COMMAND_REJECTED
0.0
3.5
Command HTTP listener rejected command '%1' from '%2'
168u
168u
در سطح لاگ debug ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که دستوری رد شده باشد. آرگومان‌ها جزئیات
دستور و نشانی‌ای که درخواست از آن دریافت شده است را مشخص می‌کنند.
COMMAND_HTTP_LISTENER_STARTED
0.0
3.5
Command HTTP listener started with %1 threads, listening on address: %2 port: %3, use TLS: %4
168u
168u
در سطح لاگ debug ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک شنوندهٔ HTTP برای پذیرش اتصالات
از کلاینت‌های Command API آغاز به کار کرده باشد که از طریق آن دستورات دریافت
و پاسخ‌ها ارسال می‌شوند. آرگومان‌ها تعداد ریسه‌هایی (threads) که شنونده استفاده
می‌کند، نشانی و درگاهی (port) که روی آن گوش می‌دهد، و استفاده یا عدم استفاده
از HTTPS/TLS را شرح می‌دهند.
COMMAND_HTTP_LISTENER_STOPPED
0.0
3.5
Command HTTP listener for address: %1 port: %2 stopped.
168u
168u
در سطح لاگ debug ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که شنوندهٔ HTTP دستورات که روی نشانی
و درگاه داده‌شده گوش می‌داد، فرایند خاموش‌سازی را تکمیل کرده باشد.
COMMAND_HTTP_LISTENER_STOPPING
0.0
3.5
Stopping Command HTTP listener for address: %1 port: %2
168u
168u
در سطح لاگ debug ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که شنوندهٔ HTTP دستورات که روی نشانی
و درگاه داده‌شده گوش می‌دهد، فرایند خاموش‌سازی را آغاز کرده باشد.
COMMAND_HTTP_SOCKET_SECURITY_WARNING
0.0
3.5
command socket configuration is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال تدابیر امنیتی غیرفعال باشد و
پیکربندی سوکت دستورات از HTTPS/TLS یا احراز هویت اولیهٔ HTTP استفاده نکند.
سرور همچنان طبق پیکربندی از سوکت استفاده خواهد کرد، اما هشدار می‌دهد که
انجام این کار ممکن است خطرات امنیتی به همراه داشته باشد.
COMMAND_PROCESS_ERROR1
0.0
3.5
Error while processing command: %1
168u
168u
این پیام هشدار نشان می‌دهد که سرور هنگام پردازش دستور دریافت‌شده با خطایی مواجه
شده است. در صورت در دسترس بودن، اطلاعات تکمیلی ارائه خواهد شد. پیام‌های لاگ
بیشتر ممکن است جزئیات بیشتری فراهم کنند.
COMMAND_PROCESS_ERROR2
0.0
3.5
Error while processing command: %1
168u
168u
این پیام هشدار نشان می‌دهد که سرور هنگام پردازش دستور دریافت‌شده با خطایی مواجه
شده است. تفاوت این پیام در مقایسه با COMMAND_PROCESS_ERROR1 این است که دستور اولیه
ساختار صحیحی داشته و خطا در حین پردازش منطقی رخ داده است، نه در زمان تجزیهٔ
(parsing) دستور. در صورت وجود، اطلاعات تکمیلی ارائه خواهد شد. پیام‌های لاگ بیشتر
ممکن است جزئیات بیشتری ارائه دهند..SS COMMAND_RECEIVED
0.0
3.5
Received command '%1'
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که فرمانی از طریق سوکت فرمان (command socket) دریافت شده است. ماهیت این فرمان و نتایج احتمالی آن در پیام‌های جداگانه‌ای ثبت خواهند شد.
COMMAND_REGISTERED
0.0
3.5
Command %1 registered
168u
168u
در سطح لاگ اشکال‌زدایی ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دیمن پشتیبانی از فرمان مشخص‌شده را آغاز کرده است. اگر سوکت فرمان باز باشد، اکنون می‌توان این فرمان را صادر کرد.
COMMAND_RESPONSE_ERROR
0.0
3.5
Server failed to generate response for command: %1
168u
168u
این پیام خطا نشان می‌دهد که سرور نتوانسته است برای فرمان مشخص‌شده پاسخی تولید کند. این امر احتمالاً نشان‌دهنده یک خطای منطقی در سرور است، زیرا انتظار می‌رود سرور برای همه فرمان‌ها، حتی موارد دارای ساختار نادرست (malformed)، پاسخ‌های معتبری تولید کند.
COMMAND_SOCKET_ACCEPT_FAIL
0.0
3.5
Failed to accept incoming connection on command socket %1: %2
168u
168u
این خطا نشان می‌دهد که سرور یک اتصال ورودی را شناسایی کرده و فراخوان سیستمی accept را روی سوکت مذکور اجرا کرده، اما این فراخوان با خطا مواجه شده است. اطلاعات تکمیلی ممکن است توسط سیستم به عنوان پارامتر دوم ارائه شود.
COMMAND_SOCKET_CLOSED_BY_FOREIGN_HOST
0.0
3.5
Closed command socket %1 by foreign host, %2
168u
168u
این یک پیام اطلاع‌رسانی است که نشان می‌دهد اتصال فرمان توسط کلاینت کنترل فرمان بسته شده است، و مشخص می‌کند که آیا داده‌های ناقص خوانده‌شده دور ریخته شده‌اند یا خیر.
COMMAND_SOCKET_CONNECTION_CANCEL_FAIL
0.0
3.5
Failed to cancel read operation on socket %1: %2
168u
168u
این پیام خطا نشان‌دهنده بروز خطا در لغو خواندن ناهمگام فرمان کنترلی از طریق سوکت کنترل است. عملیات لغو هنگامی انجام می‌شود که حین ارتباط با یک کلاینت، وقفه زمانی (timeout) رخ دهد. پیام خطا شامل جزئیاتی درباره علت شکست است.
COMMAND_SOCKET_CONNECTION_CLOSED
0.0
3.5
Closed socket %1 for existing command connection
168u
168u
در سطح لاگ اشکال‌زدایی ۱۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان می‌دهد سوکت ایجادشده برای مدیریت اتصال کلاینت بسته شده است. این معمولاً به معنای قطع ارتباط کلاینت است، اما ممکن است به معنای وقفه زمانی (timeout) نیز باشد.
COMMAND_SOCKET_CONNECTION_CLOSE_FAIL
0.0
3.5
Failed to close command connection: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام بستن یک اتصال فرمان و/یا حذف آن از استخر اتصالات (connections pool)، خطایی رخ داده باشد. خطای تفصیلی به عنوان یک آرگومان ارائه می‌شود.
COMMAND_SOCKET_CONNECTION_OPENED
0.0
3.5
Opened socket %1 for incoming command connection
168u
168u
در سطح لاگ اشکال‌زدایی ۱۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان می‌دهد یک اتصال ورودی جدید برای فرمان شناسایی شده و یک سوکت اختصاصی برای آن اتصال باز شده است..SS COMMAND_SOCKET_CONNECTION_SHUTDOWN_FAIL
0.0
3.5
Encountered error %1 while trying to gracefully shutdown socket
168u
168u
این پیام نشان‌دهنده بروز خطا هنگام تلاش برای بستن اصولی (graceful shutdown) اتصال فرمان است. نوع خطا در پیام گنجانده شده است.
COMMAND_SOCKET_CONNECTION_TIMEOUT
0.0
3.5
Timeout occurred for connection over socket %1
168u
168u
این یک پیام اطلاع‌رسانی است که نشان می‌دهد مهلت زمانی (timeout) برای یکی از اتصالات کانال فرمان به پایان رسیده است. پاسخ ارسال‌شده توسط کارساز اتمام مهلت زمانی را اعلام می‌کند و سپس اتصال بسته می‌شود.
COMMAND_SOCKET_READ
0.0
3.5
Received %1 bytes over command socket %2
168u
168u
در سطح ۱۰ گزارش اشکال‌زدایی (debug) ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تعداد بایت‌های مشخص‌شده از طریق سوکت فرمانِ شناسایی‌شده با توصیف‌گر فایل (file descriptor) معین، دریافت شده است.
COMMAND_SOCKET_READ_FAIL
0.0
3.5
Encountered error %1 while reading from command socket %2
168u
168u
این پیام خطا نشان می‌دهد که هنگام خواندن از سوکت فرمان خطایی رخ داده است.
COMMAND_SOCKET_WRITE
0.0
3.5
Sent response of %1 bytes (%2 bytes left to send) over command socket %3
168u
168u
در سطح ۱۰ گزارش اشکال‌زدایی (debug) ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تعداد بایت‌های مشخص‌شده از طریق سوکت فرمانِ شناسایی‌شده با توصیف‌گر فایل (file descriptor) معین، ارسال شده است.
COMMAND_SOCKET_WRITE_FAIL
0.0
3.5
Error while writing to command socket %1 : %2
168u
168u
این پیام خطا نشان می‌دهد که هنگام تلاش برای ارسال یک پاسخ به سوکت فرمان خطایی رخ داده است.
COMMAND_UNIX_SOCKET_PATH_SECURITY_WARNING
0.0
3.5
unix socket path is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال تدابیر امنیتی غیرفعال باشد و مسیر مشخص‌شده برای unix socket-name کانال کنترل با مسیر پشتیبانی‌شده مطابقت نداشته باشد. کارساز همچنان از مسیر مشخص‌شده استفاده خواهد کرد، اما هشدار می‌دهد که انجام این کار ممکن است خطرات امنیتی در پی داشته باشد.
COMMAND_UNIX_SOCKET_PERMISSIONS_SECURITY_WARNING
0.0
3.5
unix socket permissions are NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال تدابیر امنیتی غیرفعال باشد و مسیر مشخص‌شده برای unix socket-name کانال کنترل، مجوزهای لازم برای سوکت را نداشته باشد. کارساز همچنان از مسیر مشخص‌شده استفاده خواهد کرد، اما هشدار می‌دهد که انجام این کار ممکن است خطرات امنیتی در پی داشته باشد.
COMMAND_WATCH_SOCKET_CLEAR_ERROR
0.0
3.5
watch socket failed to clear: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که مدیر فرمان (command manager) نتوانسته باشد پس از اتمام یک ارسال، وضعیت آماده (ready status) را بازنشانی کند. این یک خطای برنامه‌نویسی است که باید گزارش شود. مدیر فرمان ممکن است به کارکرد صحیح خود ادامه دهد یا ندهد.
COMMAND_WATCH_SOCKET_CLOSE_ERROR
0.0
3.5
watch socket failed to close: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که مدیر فرمان تلاش کرده است سوکت مورد استفاده برای نشان دادن وضعیت آماده برای عملیات ارسال را ببندد. از آنجا که این رخداد هنگام پایان یافتن اتصال رخ می‌دهد، نباید هیچ تأثیر منفی بر عملکرد مدیر فرمان بگذارد..SS COMMAND_WATCH_SOCKET_MARK_READY_ERROR
0.0
3.5
watch socket failed to mark ready: %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که command manager پس از زمان‌بندی ارسال ناهمگام، نتوانسته وضعیت آماده (ready) را تنظیم کند. این یک خطای برنامه‌نویسی است که باید گزارش شود. ممکن است command manager به کارکرد صحیح خود ادامه دهد یا ندهد.
CONFIG
CONFIG_BACKENDS_REGISTERED
0.0
3.5
the following config backend types are available: %1
168u
168u
این پیام اطلاع‌رسانی، تمام پس‌اندهای پیکربندی (config backends) ممکن را که می‌توان در config-database[s] استفاده کرد، فهرست می‌کند.
DATABASE
DATABASE_INVALID_ACCESS
0.0
3.5
invalid database access string: %1
168u
168u
این پیام زمانی ثبت می‌شود که تلاشی برای تجزیهٔ یک رشتهٔ دسترسی به پایگاه داده انجام شده و با خطا پایان یافته باشد. رشتهٔ دسترسی مورد نظر - که باید به فرم 'keyword=value keyword=value...' باشد - در پیام گنجانده شده است.
DATABASE_MYSQL_COMMIT
0.0
3.5
committing to MySQL database
168u
168u
کد یک فراخوانی commit صادر کرده است. تمام تراکنش‌های معلق در پایگاه داده اعمال خواهند شد. توجه داشته باشید که بسته به تنظیمات MySQL، این اعمال ممکن است شامل نوشتن روی دیسک نباشد.
DATABASE_MYSQL_FATAL_ERROR
0.0
3.5
Unrecoverable MySQL error occurred: %1 for <%2>, reason: %3 (error code: %4).
168u
168u
پیام خطایی که نشان می‌دهد ارتباط با سرور پایگاه دادهٔ MySQL قطع شده است. اگر بازیابی خودکار فعال شده باشد، سرور تلاش خواهد کرد ارتباط را بازیابی کند. در غیر این صورت، سرور با یک کد خروج غیرصفر خارج خواهد شد. علت چنین خطایی به احتمال زیاد مشکل شبکه یا از کار افتادن سرور MySQL است.
DATABASE_MYSQL_INITIALIZE_SCHEMA
0.0
3.5
Initializing the MySQL schema with command: %1.
168u
168u
این پیام پس از شکست در دریافت اولیهٔ نسخهٔ طرح‌واره (schema)، پیش از اجرای دستور kea-admin جهت مقداردهی اولیهٔ خودکار طرح‌واره از سوی Kea ثبت می‌شود. دستور کامل kea-admin نمایش داده شده است.
DATABASE_MYSQL_INITIAL_CONNECTION_FAIL
0.0
3.5
The connection to the MySQL server is not yet established. Reason: %1
168u
168u
پیام هشداری که هنگام ناموفق بودن تلاش اولیه برای اتصال به MySQL ثبت می‌شود. اگر دلیل ناموفق بودن تلاش، عدم وجود طرح‌واره (schema) باشد، ممکن است پس از اجرای kea-admin db-init توسط سرور Kea DHCP، همچنان فرصتی برای برقراری موفقیت‌آمیز اتصال وجود داشته باشد.
DATABASE_MYSQL_NO_INIT_NO_ADMIN
0.0
3.5
Not attempting to initialize the MySQL schema. kea-admin seems to be missing.
168u
168u
پیام هشداری که نشان می‌دهد kea-admin در دسترس نیست، که این امر اجرای db-init را غیرممکن می‌سازد.
DATABASE_MYSQL_NO_INIT_READONLY
0.0
3.5
Not attempting to initialize the MySQL schema. Kea has the database configured as readonly.
168u
168u
پیام هشداری که نشان می‌دهد پایگاه داده در Kea به‌صورت فقط‌خواندنی (readonly) پیکربندی شده است، بنابراین برای db-init تلاشی صورت نخواهد گرفت.
DATABASE_MYSQL_ROLLBACK
0.0
3.5
rolling back MySQL database
168u
168u
کد یک فراخوانی rollback صادر کرده است. تمام تراکنش‌های معلق بازگردانی (roll back) خواهند شد و در پایگاه داده اعمال نمی‌شوند..SS DATABASE_MYSQL_START_TRANSACTION
0.0
3.5
starting new MySQL transaction
168u
168u
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تراکنش جدید MySQL در حال آغاز باشد.
این پیام معمولاً هنگام درج داده در یک جدول منفرد صادر نمی‌شود، زیرا سرور در این
حالت تراکنش‌ها را به طور صریح آغاز نمی‌کند. این پیام زمانی صادر می‌شود که داده‌ها
با چندین دستور INSERT در چندین جدول درج می‌شوند و ممکن است در صورت شکست هر یک
از این دستورات INSERT، نیاز به بازگردانی (rollback) کل تراکنش باشد.
DATABASE_PGSQL_COMMIT
0.0
3.5
committing to PostgreSQL database
168u
168u
کد یک فراخوانی commit صادر کرده است. تمام تراکنش‌های معلق در پایگاه‌داده
اعمال (commit) خواهند شد. توجه داشته باشید که بسته به تنظیمات PostgreSQL،
اعمال تراکنش ممکن است شامل نوشتن روی دیسک نباشد.
DATABASE_PGSQL_CREATE_SAVEPOINT
0.0
3.5
creating a new PostgreSQL savepoint: %1
168u
168u
کد در حال صدور فراخوانی برای ایجاد یک نقطهٔ ذخیره (savepoint) درون تراکنش
جاری است. در صورتی که پیش از اعمال (commit) تراکنش، فراخوانی بعدی برای
بازگردانی (rollback) به این نقطهٔ ذخیره رخ دهد، تغییرات پایگاه‌داده که
تا این نقطه انجام شده‌اند حفظ خواهند شد.
DATABASE_PGSQL_DEALLOC_ERROR
0.0
3.5
An error occurred deallocating SQL statements while closing the PostgreSQL lease database: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که یک سرور DHCP (خواه V4 یا V6)
در هنگام آزادسازی منابع SQL پایگاه‌داده به عنوان بخشی از بستن اتصال خود به
پایگاه‌دادهٔ PostgreSQL دچار خطا شود. اتصال به عنوان بخشی از فرایند خاموش شدن
عادی سرور بسته می‌شود. این خطا به احتمال زیاد یک مسئلهٔ برنامه‌نویسی است که
احتمال وقوع آن یا تأثیر منفی آن بر عملکرد سرور بسیار اندک است.
DATABASE_PGSQL_FATAL_ERROR
0.0
3.5
Unrecoverable PostgreSQL error occurred: Statement: <%1>, reason: %2 (error code: %3).
168u
168u
پیام خطایی که نشان می‌دهد ارتباط با سرور پایگاه‌دادهٔ PostgreSQL قطع شده است.
اگر بازیابی خودکار فعال شده باشد، سرور برای بازیابی اتصال تلاش خواهد کرد.
در غیر این صورت، سرور با یک کد خروج غیرصفر خارج خواهد شد. علت چنین خطایی
به احتمال زیاد یک مشکل شبکه‌ای است یا اینکه سرور PostgreSQL از کار افتاده است.
DATABASE_PGSQL_INITIALIZE_SCHEMA
0.0
3.5
Initializing the PostgreSQL schema with command: %1.
168u
168u
این پیام پس از آنکه دریافت اولیهٔ نسخهٔ طرحواره (schema) با شکست مواجه شد،
پیش از اجرای دستور kea-admin برای مقداردهی اولیهٔ خودکار طرحواره از Kea ثبت می‌شود.
دستور کامل kea-admin نمایش داده می‌شود.
DATABASE_PGSQL_INITIAL_CONNECTION_FAIL
0.0
3.5
The connection to the PostgreSQL server is not yet established. Reason: %1
168u
168u
پیام هشداری که هنگام ناموفق بودن تلاش اولیه برای اتصال به PostgreSQL ثبت می‌شود.
اگر دلیل تلاش ناموفق عدم وجود طرحواره باشد، ممکن است همچنان پس از اجرای
kea-admin db-init توسط سرور Kea DHCP، شانسی برای برقراری موفق اتصال وجود داشته باشد.
DATABASE_PGSQL_NO_INIT_NO_ADMIN
0.0
3.5
Not attempting to initialize the PostgreSQL schema. kea-admin seems to be missing.
168u
168u
پیام هشداری که نشان می‌دهد kea-admin در دسترس نیست و این امر اجرای db-init را غیرممکن می‌سازد.
DATABASE_PGSQL_NO_INIT_READONLY
0.0
3.5
Not attempting to initialize the PostgreSQL schema. Kea has the database configured as readonly.
168u
168u
پیام هشداری که نشان می‌دهد پایگاه‌داده در Kea به صورت فقط‌خواندنی (readonly) پیکربندی شده است، بنابراین تلاشی برای db-init صورت نخواهد گرفت..SS DATABASE_PGSQL_ROLLBACK
0.0
3.5
rolling back PostgreSQL database
168u
168u
کد دستور واگردانی (rollback) را صادر کرده است. تمام تراکنش‌های معلق واگردانی خواهند شد و در پایگاه‌داده اعمال (commit) نمی‌شوند.
DATABASE_PGSQL_ROLLBACK_SAVEPOINT
0.0
3.5
rolling back PostgreSQL database to savepoint: $1
168u
168u
کد در حال صدور فراخوانی برای واگردانی به نقطه ذخیره (savepoint) مشخص‌شده است. هرگونه تغییری در پایگاه‌داده که پس از ایجاد این نقطه ذخیره انجام شده باشد، واگردانی شده و در پایگاه‌داده اعمال نخواهد شد.
DATABASE_PGSQL_START_TRANSACTION
0.0
3.5
starting a new PostgreSQL transaction
168u
168u
این پیام اشکال‌زدایی هنگامی صادر می‌شود که یک تراکنش جدید PostgreSQL در حال شروع باشد. این پیام معمولاً هنگام درج داده در یک جدول منفرد صادر نمی‌شود، زیرا سرور در این حالت تراکنش‌ها را به‌طور صریح آغاز نمی‌کند. این پیام هنگامی صادر می‌شود که داده‌ها با چندین دستور INSERT در چند جدول درج می‌شوند و ممکن است در صورت شکست هر یک از این دستورات INSERT، نیاز به واگردانی کل تراکنش باشد.
DATABASE_PGSQL_TCP_USER_TIMEOUT_UNSUPPORTED
0.0
3.5
tcp_user_timeout is not supported in this PostgreSQL version
168u
168u
این پیام هشدار هنگامی صادر می‌شود که کاربر پارامتر tcp_user_timeout را در اتصال به پایگاه‌داده PostgreSQL پیکربندی کرده باشد، اما پایگاه‌داده نصب‌شده از این پارامتر پشتیبانی نکند. این پارامتر در نسخه 12 یا بالاتر PostgreSQL پشتیبانی می‌شود. مقدار تنظیم‌شده برای این پارامتر نادیده گرفته خواهد شد.
DATABASE_TO_JSON_BOOLEAN_ERROR
0.0
3.5
Internal logic error: invalid boolean value found in database connection parameters: %1=%2
168u
168u
این پیام خطا هنگامی چاپ می‌شود که تبدیل وضعیت داخلی به JSON درخواست شده باشد، اما رشته اتصال حاوی یک پارامتر بولی (boolean) با مقداری نامعتبر باشد. این یک خطای برنامه‌نویسی است. نرم‌افزار به کار خود ادامه خواهد داد، اما داده‌های JSON بازگردانده‌شده با وجود معتبر بودن از نظر نحوی، ناقص خواهند بود. پارامتر معیوب تبدیل نخواهد شد.
DATABASE_TO_JSON_INTEGER_ERROR
0.0
3.5
Internal logic error: invalid integer value found in database connection parameters: %1=%2
168u
168u
این پیام خطا هنگامی چاپ می‌شود که تبدیل وضعیت داخلی به JSON درخواست شده باشد، اما رشته اتصال حاوی یک پارامتر عدد صحیح (integer) با مقداری نادرست باشد. این یک خطای برنامه‌نویسی است. نرم‌افزار به کار خود ادامه خواهد داد، اما داده‌های JSON بازگردانده‌شده با وجود معتبر بودن از نظر نحوی، ناقص خواهند بود. پارامتر معیوب تبدیل نخواهد شد.
DATABASE_TO_JSON_UNKNOWN_TYPE_ERROR
0.0
3.5
Internal logic error: unknown element found in database connection parameters: %1=%2
168u
168u
این پیام خطا زمانی چاپ می‌شود که تبدیل وضعیت داخلی به JSON درخواست شده باشد، اما رشته اتصال حاوی یک پارامتر ناشناخته باشد. این یک خطای برنامه‌نویسی است. نرم‌افزار به کار خود ادامه خواهد داد، اما داده‌های JSON بازگردانده‌شده با وجود معتبر بودن از نظر نحوی، ناقص خواهند بود. پارامتر ناشناخته تبدیل نخواهد شد.
DCTL
DCTL_ALREADY_RUNNING
0.0
3.5
%1 already running? %2
168u
168u
این یک پیام خطا است و زمانی رخ می‌دهد که یک ماژول با یک فایل PID از پیش موجود مواجه شود که حاوی PID یک فرایند در حال اجرا است. این موضوع به احتمال زیاد نشان‌دهنده تلاش برای راه‌اندازی نمونه دوم از یک ماژول با استفاده از همان فایل پیکربندی است. این احتمال نیز وجود دارد، هرچند بعید، که فایل PID بازمانده‌ای از فروپاشی (crash) سرور یا قطع برق باشد و PID موجود در آن به فرایندی غیر از فرایند Kea اشاره کند. در چنین حالتی، لازم است فایل PID به‌صورت دستی حذف شود. آرگومان نخست نام فرایند و آرگومان دوم حاوی PID و فایل PID است.
DCTL_CFG_FILE_RELOAD_ERROR
0.0
3.5
configuration reload failed: %1, reverting to current configuration.
168u
168u
این یک پیام خطا است که نشان می‌دهد برنامه تلاش کرده است پیکربندی خود را مجدداً از فایل بارگذاری کند و با یک خطا مواجه شده است. این امر احتمالاً به دلیل وجود محتوای نامعتبر در فایل پیکربندی رخ داده است. برنامه باید با همان پیکربندی فعلی خود به کار ادامه دهد..SS DCTL_CFG_FILE_RELOAD_SIGNAL_RECVD
0.0
3.5
OS signal %1 received, reloading configuration from file: %2
168u
168u
این یک پیام اطلاعاتی است که نشان می‌دهد برنامه سیگنالی دریافت کرده که به آن دستور می‌دهد پیکربندی خود را مجدداً از فایل بارگذاری کند.
DCTL_CONFIG_CHECK_COMPLETE
0.0
3.5
server has completed configuration check: %1, result: %2
168u
168u
این یک پیام اطلاعاتی است که اتمام موفقیت‌آمیز پردازش بررسی یک پیکربندی جدید را اعلان می‌کند. نتیجهٔ این بررسی چاپ می‌شود. این پیام اطلاعاتی هنگامی که بررسی پیکربندی درخواست شده باشد، چاپ می‌شود.
DCTL_CONFIG_COMPLETE
0.0
3.5
server has completed configuration: %1
168u
168u
این یک پیام اطلاعاتی است که پردازش موفقیت‌آمیز یک پیکربندی جدید را اعلان می‌کند. این پیام هنگام راه‌اندازی سرور، و زمانی که یک پیکربندی به‌روزشده توسط مدیر سیستم اعمال (commit) می‌شود، نمایش داده خواهد شد. ممکن است اطلاعات بیشتری نیز ارائه شود.
DCTL_CONFIG_DEPRECATED
0.0
3.5
server configuration includes a deprecated object: %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که پیکربندی شامل یک شیء منسوخ‌شده (یعنی یک عنصر سطح بالا) باشد که نادیده گرفته خواهد شد.
DCTL_CONFIG_FETCH
0.0
3.5
Fetching configuration data from config backends.
168u
168u
این یک پیام اطلاعاتی است و زمانی صادر می‌شود که سرور Kea در آستانهٔ شروع واکشی داده‌های پیکربندی از یک یا چند بک‌اند پیکربندی باشد.
DCTL_CONFIG_FILE_LOAD_FAIL
0.0
3.5
%1 reason: %2
168u
168u
این پیام خطای مهلک نشان می‌دهد که برنامه تلاش کرده پیکربندی اولیهٔ خود را از فایل بارگذاری کند اما شکست خورده است. سرویس بسته خواهد شد.
DCTL_CONFIG_START
0.0
3.5
parsing new configuration: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۱۰ (debug log level 10) ثبت می‌شود.
پیام اشکال‌زدایی که نشان می‌دهد فرآیند برنامه پیکربندی به‌روزشده‌ای را دریافت کرده و آن را برای تجزیه به مدیر پیکربندی خود تحویل داده است.
DCTL_DB_OPEN_CONNECTION_WITH_RETRY_FAILED
0.0
3.5
Failed to connect to database: %1 with error: %2
168u
168u
این یک پیام اطلاعاتی است و زمانی صادر می‌شود که اتصال سرور به پایگاه‌دادهٔ پیکربندی ناموفق باشد. این عملیات رویهٔ تلاش مجدد برای اتصال را آغاز کرده است. رشتهٔ دسترسی به پایگاه‌داده (با رمز عبور پنهان‌شده) به همراه خطا و جزئیات مربوط به رویهٔ اتصال مجدد ثبت می‌شود.
DCTL_DEPRECATED_OUTPUT_OPTIONS
0.0
3.5
The output_options parameter is deprecated. Use output-options parameter instead.
168u
168u
این پیام هشدار زمانی نمایش داده می‌شود که پارامتر منسوخ‌شدهٔ output_options به جای output-options استفاده شود.
DCTL_DEVELOPMENT_VERSION
0.0
3.5
This software is a development branch of Kea. It is not recommended for production use.
168u
168u
این پیام هشدار زمانی نمایش داده می‌شود که نسخه از نوع توسعه‌ای (در مقابل نسخهٔ پایدار) باشد: عدد دوم شمارهٔ نسخه فرد است..SS DCTL_INIT_PROCESS
0.0
3.5
%1 initializing the application
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۰ ثبت می‌شود.
این پیام اشکال‌زدایی درست پیش از آنکه کنترلر برای ایجاد و مقداردهی اولیهٔ
نمونه برنامهٔ خود تلاش کند صادر می‌شود.
DCTL_INIT_PROCESS_FAIL
0.0
3.5
%1 application initialization failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که کنترلر نتواند برنامه را مقداردهی
اولیه کند و خارج خواهد شد.
DCTL_LOG_PATH_SECURITY_WARNING
0.0
3.5
Log output path specified is NOT SECURE: %1
168u
168u
این پیام هشدار هنگامی صادر می‌شود که اعمال امنیت غیرفعال باشد
و مسیر خروجی مشخص‌شده برای یک ثبت‌کنندهٔ وقایع (logger) با مسیر
پشتیبانی‌شده مطابقت نداشته باشد. سرور همچنان از مسیر تعیین‌شده استفاده خواهد
کرد، اما هشدار می‌دهد که انجام این کار ممکن است خطرات امنیتی
به همراه داشته باشد.
DCTL_NOT_RUNNING
0.0
3.5
%1 application instance is not running
168u
168u
این پیام هشدار زمانی صادر می‌شود که تلاشی برای متوقف کردن برنامه در
حالی که در حال اجرا نیست، صورت گیرد.
DCTL_OPEN_CONFIG_DB
0.0
3.5
Opening configuration database: %1
168u
168u
این پیام هنگامی چاپ می‌شود که سرور Kea در حال تلاش برای باز کردن یک
پایگاه دادهٔ پیکربندی است. رشتهٔ دسترسی به پایگاه داده با گذرواژهٔ
سانسورشده ثبت می‌شود.
DCTL_PARSER_FAIL
0.0
3.5
Parser error: %1
168u
168u
هنگام دریافت یک پیکربندی جدید، سرور در ایجاد یک تجزیه‌کننده (parser) برای
رمزگشایی محتوای عنصر پیکربندیِ نام‌برده ناموفق بوده، یا ساخت آن موفقیت‌آمیز
بوده اما عملیات تجزیه و اعمال تغییرات با شکست مواجه شده است.
دلیل این شکست در پیام ذکر شده است.
DCTL_PID_FILE_ERROR
0.0
3.5
%1 could not create a PID file: %2
168u
168u
این یک پیام خطا است و زمانی رخ می‌دهد که سرور قادر به ایجاد فایل PID خود
نباشد. پیام گزارش باید شامل جزئیات کافی برای تعیین علت اصلی باشد.
محتمل‌ترین دلایل، عدم وجود بخشی از مسیر فایل یا وجود مشکل در مجوزهای دسترسی
است. مسیر پیش‌فرض توسط گزینه‌های --localstatedir و --prefix در meson setup
تعیین می‌شود، اما می‌توان با تنظیم متغیر محیطی KEA_PIDFILE_DIR آن را بازنویسی کرد.
آرگومان نخست، نام فرآیند است.
DCTL_PROCESS_FAILED
0.0
3.5
%1 application execution failed: %2
168u
168u
کنترلر هنگام اجرای برنامه با یک خطای مهلک مواجه شده و در حال
خاتمه است. دلیل این شکست در پیام گنجانده شده است.
DCTL_ROOT_USER_SECURITY_WARNING
0.0
3.5
%1 running as root user!
168u
168u
این هشدار زمانی صادر می‌شود که سرور با کاربر ریشه (root) در حال اجرا باشد.
با اینکه سرور به طور کامل کار خواهد کرد، این حالت عملکرد ممکن است
محیط شما را در معرض آسیب‌پذیری‌های امنیتی قرار دهد و تنها پس از بررسی
دقیق باید استفاده شود..SS DCTL_RUN_PROCESS
0.0
3.5
%1 starting application event loop
168u
168u
در سطح گزارش اشکال‌زدایی ۰ ثبت می‌شود.
این پیام اشکال‌زدایی درست پیش از اینکه کنترل‌کننده متد اجرای (run)
برنامه را فراخوانی کند، صادر می‌شود.
DCTL_SHUTDOWN
0.0
3.5
%1 has shut down, pid: %2, version: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۰ ثبت می‌شود.
این یک پیام اطلاع‌رسانی است که نشان می‌دهد سرویس متوقف شده
است. آرگومان نام سرویس را مشخص می‌کند.
DCTL_SHUTDOWN_SIGNAL_RECVD
0.0
3.5
OS signal %1 received, starting shutdown
168u
168u
در سطح گزارش اشکال‌زدایی ۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان می‌دهد برنامه سیگنالی
مبنی بر خاموش شدن دریافت کرده است.
DCTL_STANDALONE
0.0
3.5
%1 skipping message queue, running standalone
168u
168u
در سطح گزارش اشکال‌زدایی ۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان می‌دهد کنترل‌کننده در برنامه
در حالت مستقل (standalone) اجرا می‌شود. این بدان معناست که به صف
پیام Kea متصل نخواهد شد. حالت مستقل فقط در طول توسعهٔ برنامه مفید
است و نباید در یک محیط عملیاتی (production) استفاده شود.
DCTL_STARTING
0.0
3.5
%1 starting, pid: %2, version: %3 (%4)
168u
168u
این یک پیام اطلاع‌رسانی است که هنگام نخستین راه‌اندازی کنترل‌کننده
برای سرویس صادر می‌شود. نسخه نیز گزارش داده می‌شود.
DCTL_UNLOAD_LIBRARIES_ERROR
0.0
3.5
error unloading hooks libraries during shutdown: %1
168u
168u
این پیام خطا نشان می‌دهد که هنگام خاموش شدن، تخلیهٔ کتابخانه‌های
hooks در بستن آن‌ها با شکست مواجه شده است. اگر فهرست کتابخانه‌ها
خالی باشد، این یک خطای برنامه‌نویسی در کد سرور است. اگر خالی نباشد،
می‌تواند یک خطای برنامه‌نویسی در یکی از کتابخانه‌های hooks باشد که ممکن
است منجر به فروپاشی (crash) در طول مرحلهٔ نهایی‌سازی شود.
DCTL_UNSUPPORTED_SIGNAL
0.0
3.5
ignoring reception of unsupported signal: %1
168u
168u
این یک پیام اشکال‌زدایی است که نشان می‌دهد برنامه یک سیگنال
پشتیبانی‌نشده دریافت کرده است. این یک خطای برنامه‌نویسی است که نشان
می‌دهد برنامه برای دریافت سیگنال ثبت‌نام کرده، اما هیچ منطق پردازشی
مرتبطی افزوده نشده است.
DDNS
DDNS_TUNING4_CALCULATED_HOSTNAME
0.0
3.5
Replacing host name: %1, with calculated host name: %2, for query: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کتابخانهٔ hooks مربوط
به DDNS Tuning یک نام میزبان جدید برای پرس‌وجوی کلاینت مربوطه
محاسبه کرده باشد. نام میزبان اصلی و نام میزبان محاسبه‌شده ارائه
می‌شوند.
DDNS_TUNING4_PROCESS_ERROR
0.0
3.5
An error occurred processing query %1: %2
168u
168u
این پیام خطا نشان‌دهندهٔ بروز خطا در حین پردازش یک پرس‌وجو
توسط کتابخانهٔ hooks مربوط به DDNS Tuning است. اطلاعات شناسایی
کلاینت از پرس‌وجو و جزئیات خطا به عنوان آرگومان‌های پیام گزارش
ارائه می‌شوند..SS DDNS_TUNING4_SKIPPING_DDNS
0.0
3.5
Client is a member matches SKIP_DDNS class, skipping DDNS updates, query: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که در طول فراخوانی (callout) ddns4-update، پرس‌وجوی کلاینت با کلاس SKIP_DDNS مطابقت داشته باشد. سرور kea-dhcp4 درخواست‌های به‌روزرسانی DDNS را برای این پرس‌وجو به kea-dhcp-ddns ارسال نخواهد کرد. پرس‌وجو در پیام لاگ نشان داده شده است.
DDNS_TUNING6_CALCULATED_HOSTNAME
0.0
3.5
Replacing host name: %1, with calculated host name: %2, for query: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کتابخانه قلاب‌های (hooks library) DDNS Tuning یک نام میزبان (hostname) جدید برای پرس‌وجوی کلاینت داده‌شده محاسبه کرده باشد. نام میزبان اصلی و نام میزبان محاسبه‌شده ارائه می‌شوند.
DDNS_TUNING6_PROCESS_ERROR
0.0
3.5
An error occurred processing query %1: %2
168u
168u
این پیام خطا نشان‌دهنده بروز خطا در حین پردازش یک پرس‌وجو توسط کتابخانه قلاب‌های DDNS Tuning است. اطلاعات شناسایی کلاینت از پرس‌وجو و جزئیات خطا به عنوان آرگومان‌های پیام لاگ ارائه می‌شوند.
DDNS_TUNING6_SKIPPING_DDNS
0.0
3.5
Client is a member matches SKIP_DDNS class, skipping DDNS updates, query: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که در طول فراخوانی ddns6-update، پرس‌وجوی کلاینت با کلاس SKIP_DDNS مطابقت داشته باشد. سرور kea-dhcp6 درخواست‌های به‌روزرسانی DDNS را برای این پرس‌وجو به kea-dhcp-ddns ارسال نخواهد کرد. پرس‌وجو در پیام لاگ نشان داده شده است.
DDNS_TUNING_GLOBAL_EXPR_SET
0.0
3.5
Global hostname expression set to: %1
168u
168u
این پیام نشان می‌دهد که عبارت نام میزبان سراسری (global hostname expression) تنظیم شده است و در همه‌جا استفاده خواهد شد، مگر اینکه توسط پارامترهای سطح زیرشبکه (subnet) بازنویسی شود.
DDNS_TUNING_LOAD_ERROR
0.0
3.5
loading DDNS Tuning hooks library failed: %1
168u
168u
این پیام خطا نشان‌دهنده بروز خطا هنگام بارگیری کتابخانه قلاب‌های DDNS Tuning است. جزئیات خطا به عنوان آرگومان پیام لاگ ارائه می‌شوند.
DDNS_TUNING_LOAD_OK
0.0
3.5
DDNS Tuning hooks library loaded successfully.
168u
168u
این پیام اطلاعاتی (info) نشان می‌دهد که کتابخانه قلاب‌های DDNS Tuning با موفقیت بارگیری شده است.
DDNS_TUNING_SUBNET_EXPRESSION_PARSE
0.0
3.5
Parsing subnet expression (%1) for for subnet %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کتابخانه قلاب‌های DDNS Tuning در حال تلاش برای تجزیه عبارت نام میزبان برای یک زیرشبکه است. تجزیه پس از رویدادهای پیکربندی (مانند دستور reconfigure، به‌روزرسانی‌های backend پیکربندی، به‌روزرسانی‌های دستور subnet) رخ می‌دهد.
DDNS_TUNING_SUBNET_EXPRESSION_PARSE_ERROR
0.0
3.5
An error occurred while parsing the hostname expression for subnet %1, %2
168u
168u
این خطا نشان می‌دهد که عبارت نام میزبان تخصیص‌یافته به یک زیرشبکه، عبارتی معتبر نیست. سرویس DHCP طوری به کار خود ادامه می‌دهد که گویی زیرشبکه هیچ عبارتی مشخص نکرده است. زیرشبکه و خطای تجزیه در پیام لاگ گنجانده شده‌اند..SS DDNS_TUNING_SUBNET_EXPR_CACHED
0.0
3.5
Using subnet expression stored in a cache for subnet %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
عبارت این زیرشبکه پیش‌تر استفاده و در حافظه موقت (cache) ذخیره شده است. از نسخه کش‌شده استفاده می‌شود.
DDNS_TUNING_UNLOAD
0.0
3.5
DDNS Tuning hooks library has been unloaded
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه هوک‌های DDNS Tuning از حافظه تخلیه شده است (unloaded).
DHCP4
DHCP4_ADDITIONAL_CLASS_EVAL_ERROR
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
این پیام خطا نشان می‌دهد که هنگام ارزیابی عبارت مربوط به یک کلاس کلاینت اضافی، مشکلی رخ داده است.
توضیحی درباره مشکل چاپ می‌شود.
DHCP4_ADDITIONAL_CLASS_EVAL_RESULT
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت مربوط به یک کلاس کلاینت اضافی با موفقیت ارزیابی شده است. نام کلاس کلاینت و مقدار حاصل از ارزیابی چاپ می‌شوند.
DHCP4_ADDITIONAL_CLASS_NO_TEST
0.0
3.5
additional class %1 has no test expression, adding it to client's classes unconditionally
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که کلاسی برای ارزیابی اضافی فهرست شده است، اما تعریف آن شامل عبارت آزمایشی برای ارزیابی نیست. این کلاس بدون قید و شرط به پرس‌وجو (query) اضافه می‌شود.
DHCP4_ADDITIONAL_CLASS_UNDEFINED
0.0
3.5
additional class %1 has no definition
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که کلاسی برای ارزیابی اضافی فهرست شده است اما تعریفی ندارد. از این کلاس صرف‌نظر می‌شود.
DHCP4_ALREADY_RUNNING
0.0
3.5
%1 already running? %2
168u
168u
این پیام خطا زمانی رخ می‌دهد که سرور DHCPv4 با یک فایل PID از پیش موجود مواجه می‌شود که حاوی PID یک فرایند در حال اجرا است.
این امر به احتمال زیاد نشان‌دهنده تلاشی برای راه‌اندازی نمونهٔ دوم از سرور با استفاده از همان فایل پیکربندی است. ممکن است، اگرچه نامحتمل، که فایل PID بازمانده‌ای از کرش (خرابی ناگهانی) سرور یا قطع برق باشد و PID موجود در آن به فرایندی غیر از سرور اشاره کند. در چنین حالتی، لازم است فایل PID به صورت دستی حذف شود. آرگومان اول، نام فرایند DHCPv4 است و دومی حاوی PID و فایل PID است.
DHCP4_BUFFER_RECEIVED
0.0
3.5
received buffer from %1:%2 to %3:%4 over interface %5
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که سرور بسته‌ای را از طریق سوکت دریافت کرده باشد. هنگام ثبت این پیام، محتوای بستهٔ دریافتی هنوز تجزیه (parse) نشده است. تنها اطلاعات موجود، رابط شبکه (interface) و نشانی‌ها و پورت‌های IPv4 مبدا و مقصد هستند.
DHCP4_BUFFER_RECEIVE_FAIL
0.0
3.5
error on attempt to receive packet: %1
168u
168u
سرور DHCPv4 تلاش کرد بسته‌ای را دریافت کند اما هنگام این تلاش خطایی رخ داد. علت خطا در متن پیام گنجانده شده است..SS DHCP4_BUFFER_UNPACK
0.0
3.5
parsing buffer received from %1 to %2 over interface %3
168u
168u
در سطح ثبت اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز شروع به تجزیه بافر دریافتی
حاوی پیام DHCPv4 می‌کند. آرگومان‌ها آدرس‌های IPv4 مبدأ و
مقصد و همچنین واسطی که بافر از طریق آن دریافت شده است را
مشخص می‌کنند.
DHCP4_BUFFER_WAIT_SIGNAL
0.0
3.5
signal received while waiting for next packet
168u
168u
در سطح ثبت اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در انتظار
بسته بوده، اما این انتظار توسط سیگنال دریافت شده توسط فرایند
متوقف شده است. سیگنال پیش از آنکه کارساز شروع به انتظار
برای بسته‌های بعدی کند، رسیدگی خواهد شد.
DHCP4_CB_ON_DEMAND_FETCH_UPDATES_FAIL
0.0
3.5
error on demand attempt to fetch configuration updates from the configuration backend(s): %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کارساز تلاش کرده به‌روزرسانی‌های
پیکربندی را از پایگاه‌داده واکشی کند و این تلاش درخواستی (on demand) با شکست مواجه شده است.
تنها آرگومان این پیام که به فراخواننده دستور config-backend-pull
نیز بازگردانده می‌شود، شامل دلیل شکست است.
DHCP4_CB_PERIODIC_FETCH_UPDATES_FAIL
0.0
3.5
error on periodic attempt to fetch configuration updates from the configuration backend(s): %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کارساز تلاش کرده به‌روزرسانی‌های
پیکربندی را از پایگاه‌داده واکشی کند و این تلاش دوره‌ای با شکست مواجه شده است.
کارساز مطابق با مقدار پیکربندی‌شده پارامتر config-fetch-wait-time
دوباره تلاش خواهد کرد. تنها آرگومان شامل دلیل شکست است.
DHCP4_CB_PERIODIC_FETCH_UPDATES_RETRIES_EXHAUSTED
0.0
3.5
maximum number of configuration fetch attempts: 10, has been exhausted without success
168u
168u
این خطا نشان می‌دهد که کارساز تعدادی تلاش دوره‌ای ناموفق برای
واکشی به‌روزرسانی‌های پیکربندی از یک بک‌اند پیکربندی انجام داده است.
کارساز به کار خود ادامه خواهد داد اما هیچ تلاش دیگری برای واکشی
به‌روزرسانی‌های پیکربندی انجام نخواهد داد. مدیر سیستم باید پیکربندی را
در پایگاه‌داده اصلاح کرده و کارساز را مجدداً بارگذاری (یا راه‌اندازی مجدد) کند.
DHCP4_CLASSES_ASSIGNED
0.0
3.5
%1: client packet has been assigned on %2 message to the following classes: %3
168u
168u
در سطح ثبت اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بسته دریافتی به کلاس‌های مشخص‌شده
تخصیص یافته است. این یک رفتار عادی است و نشان‌دهنده عملکرد موفقیت‌آمیز است.
آرگومان اول اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم
نوع پیام DHCPv4 را تعیین می‌کند. آرگومان سوم شامل تمام کلاس‌هایی است که
بسته به آن‌ها تخصیص یافته است.
DHCP4_CLASSES_ASSIGNED_AFTER_SUBNET_SELECTION
0.0
3.5
%1: client packet has been assigned to the following classes: %2
168u
168u
در سطح ثبت اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بسته دریافتی به کلاس‌های مشخص‌شده
تخصیص یافته است. این یک رفتار عادی است و نشان‌دهنده عملکرد موفقیت‌آمیز است.
آرگومان اول اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم
شامل تمام کلاس‌هایی است که بسته به آن‌ها تخصیص یافته است.
DHCP4_CLASS_ASSIGNED
0.0
3.5
%1: client packet has been assigned to the following class: %2
168u
168u
در سطح ثبت اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بسته دریافتی به کلاس مشخص‌شده
تخصیص یافته است. این یک رفتار عادی است و نشان‌دهنده عملکرد موفقیت‌آمیز است.
آرگومان اول اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم
شامل کلاس جدیدی است که بسته به آن تخصیص یافته است..SS DHCP4_CLASS_UNCONFIGURED
0.0
3.5
%1: client packet belongs to an unconfigured class: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بستهٔ دریافتی متعلق به کلاسی است
که در پیکربندی یافت نمی‌شود. یا از یک هوک (hook) که پیش از اضافه شدن
قابلیت دسته‌بندی به Kea نوشته شده استفاده شده است، یا نام‌گذاری کلاس‌ها
ناسازگار و ناهماهنگ است.
DHCP4_CLIENTID_IGNORED_FOR_LEASES
0.0
3.5
%1: not using client identifier for lease allocation for subnet %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار در حال پردازش پیام DHCPv4 است
که برای آن هنگام تخصیص اجارهٔ جدید (lease) یا تمدید اجارهٔ موجود، از شناسهٔ کلاینت
(client identifier) استفاده نخواهد شد. کارگزار صراحتاً پیکربندی شده است تا از
شناسهٔ کلاینت برای جستجوی اجاره‌های موجود کلاینت استفاده نکند و شناسهٔ کلاینت
را در پایگاه دادهٔ اجاره‌ها ثبت نخواهد کرد. این حالت عملکرد زمانی مفید است
که کلاینت‌ها از شناسه‌های پایدار استفاده نمی‌کنند، مانند راه‌اندازی چندمرحله‌ای
(multi-stage booting). آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است.
آرگومان دوم شناسهٔ زیرشبکه‌ای (subnet) را مشخص می‌کند که کلاینت به آن متصل
است و این حالت عملکرد روی کارگزار برای آن پیکربندی شده است.
DHCP4_CLIENT_FQDN_DATA
0.0
3.5
%1: Client sent FQDN option: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل اطلاعات تفصیلی استخراج‌شده از گزینهٔ Client FQDN
ارسال‌شده در پرس‌وجو (query) است. آرگومان نخست شامل اطلاعات شناسایی کلاینت
و تراکنش است. آرگومان دوم اطلاعات دقیق دربارهٔ گزینهٔ FQDN دریافت‌شده توسط
کارگزار را مشخص می‌کند.
DHCP4_CLIENT_FQDN_PROCESS
0.0
3.5
%1: processing Client FQDN option
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار پردازش گزینهٔ Client FQDN
ارسال‌شده در پرس‌وجوی کلاینت را آغاز می‌کند. آرگومان شامل اطلاعات شناسایی
کلاینت و تراکنش است.
DHCP4_CLIENT_FQDN_SCRUBBED_EMPTY
0.0
3.5
%1: sanitizing client's FQDN option '%2' yielded an empty string
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که نتیجهٔ پالایش و پاک‌سازی گزینهٔ
FQDN option(81) ارسال‌شده توسط کلاینت، یک رشتهٔ خالی باشد. در صورت وقوع
این حالت، کارگزار گزینهٔ FQDN را نادیده خواهد گرفت. آرگومان‌ها شامل کلاینت
و گزینهٔ FQDN ارسال‌شده توسط آن هستند.
DHCP4_CLIENT_HOSTNAME_DATA
0.0
3.5
%1: client sent Hostname option: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل اطلاعات تفصیلی استخراج‌شده از گزینهٔ Hostname
ارسال‌شده در پرس‌وجو است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و
تراکنش است. آرگومان دوم نام میزبان (hostname) حمل‌شده در گزینهٔ Hostname
ارسال‌شده توسط کلاینت را مشخص می‌کند.
DHCP4_CLIENT_HOSTNAME_MALFORMED
0.0
3.5
%1: client hostname option malformed: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار DHCP به دلیل ناهنجار یا
ناقص بودن محتوا (malformed)، قادر به پردازش گزینهٔ hostname ارسال‌شده توسط
کلاینت نبوده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است.
آرگومان دوم حاوی شرح خطای داده است.
DHCP4_CLIENT_HOSTNAME_PROCESS
0.0
3.5
%1: processing client's Hostname option
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار پردازش گزینهٔ Hostname
ارسال‌شده در پرس‌وجوی کلاینت را آغاز می‌کند. آرگومان شامل اطلاعات شناسایی
کلاینت و تراکنش است..SS DHCP4_CLIENT_HOSTNAME_SCRUBBED_EMPTY
0.0
3.5
%1: sanitizing client's Hostname option '%2' yielded an empty string
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که نتیجهٔ پاک‌سازی گزینهٔ hostname (کد ۱۲) ارسال‌شده توسط کلاینت، یک رشتهٔ خالی باشد. در چنین حالتی، سرور گزینهٔ hostname را نادیده خواهد گرفت. آرگومان‌ها شامل کلاینت و گزینهٔ hostname ارسال‌شده توسط آن هستند.
DHCP4_CLIENT_NAME_PROC_FAIL
0.0
3.5
%1: failed to process the fqdn or hostname sent by a client: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور DHCP قادر به پردازش گزینهٔ FQDN یا Hostname ارسال‌شده توسط کلاینت نبوده است. این مسئله احتمالاً به دلیل نامعتبر بودن ساختار (malformed) نام کلاینت یا به دلیل خطای داخلی سرور رخ داده است. آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی توضیحات دقیق خطا می‌باشد.
DHCP4_CONFIG_COMPLETE
0.0
3.5
DHCPv4 server has completed configuration: %1
168u
168u
این یک پیام اطلاع‌رسانی است که پردازش موفقیت‌آمیز یک پیکربندی جدید را اعلام می‌کند. این پیام هنگام راه‌اندازی سرور و همچنین زمانی که یک پیکربندی به‌روزرسانی‌شده توسط مدیر سیستم اعمال می‌شود، نمایش داده خواهد شد. ممکن است اطلاعات بیشتری نیز ارائه شود.
DHCP4_CONFIG_LOAD_FAIL
0.0
3.5
configuration error using file: %1, reason: %2
168u
168u
این پیام خطا نشان می‌دهد که پیکربندی DHCPv4 با شکست مواجه شده است. اگر این یک پیکربندی اولیه باشد (هنگام راه‌اندازی سرور)، سرور شروع به کار نخواهد کرد. اگر این تلاش برای پیکربندی مجدد پویا باشد، سرور به استفاده از پیکربندی پیشین ادامه خواهد داد.
DHCP4_CONFIG_PACKET_QUEUE
0.0
3.5
DHCPv4 packet queue info after configuration: %1
168u
168u
این پیام اطلاع‌رسانی هنگام پیکربندی سرور DHCPv4 و بلافاصله پس از پیکربندی صف بسته‌های DHCPv4 صادر می‌شود. اطلاعات نمایش‌داده‌شده به نوع صف بستهٔ انتخاب‌شده بستگی دارد.
DHCP4_CONFIG_RECEIVED
0.0
3.5
received configuration %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۱۰ ثبت می‌شود.
این پیام اشکال‌زدایی پیکربندی دریافت‌شده توسط سرور DHCPv4 را فهرست می‌کند. منبع آن پیکربندی به بستر زیرین (backend) پیکربندیِ استفاده‌شده بستگی دارد.
DHCP4_CONFIG_START
0.0
3.5
DHCPv4 server is processing the following configuration: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۱۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و هر بار که سرور پیکربندی دریافت می‌کند صادر می‌شود. این فرایند در زمان راه‌اندازی و همچنین زمانی که تغییری در پیکربندی سرور توسط مدیر سیستم اعمال می‌شود، رخ می‌دهد.
DHCP4_CONFIG_SYNTAX_WARNING
0.0
3.5
configuration syntax warning: %1
168u
168u
این پیام هشدار نشان می‌دهد که پیکربندی DHCPv4 دارای یک خطای جزئی در ساختار نحو (syntax) بوده است. خطا نمایش داده شد و تجزیهٔ پیکربندی ادامه یافت.
DHCP4_CONFIG_UNRECOVERABLE_ERROR
0.0
3.5
DHCPv4 server new configuration failed with an error which cannot be recovered
168u
168u
این پیام خطای مهلک زمانی صادر می‌شود که در پیکربندی جدید خطایی غیرقابل‌بازیابی رخ دهد. از آنجا که سرور دیگر کار نمی‌کند، باید در اسرع وقت یک پیکربندی صحیح اعمال شود.
پیکربندی را می‌توان به چندین روش اصلاح کرد. اگر کانال کنترل باز باشد، می‌توان از دستور config-set به همراه یک پیکربندی معتبر استفاده کرد. به عنوان روش دیگر، می‌توان فایل پیکربندی اصلی را روی دیسک ویرایش کرد و سیگنال SIGHUP را فرستاد (یا دستور config-reload را اجرا کرد). در نهایت، می‌توان سرور را به طور کامل مجدداً راه‌اندازی نمود..SS DHCP4_CONFIG_UNSUPPORTED_OBJECT
0.0
3.5
DHCPv4 server configuration includes an unsupported object: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که پیکربندی شامل یک شیء پشتیبانی‌نشده (یعنی یک عنصر در بالاترین سطح) باشد.
DHCP4_DB_RECONNECT_DISABLED
0.0
3.5
database reconnect is disabled: retries left: %1, reconnect wait time: %2, manager ID: %3, timer: %4
168u
168u
این یک پیام اطلاع‌رسانی است که نشان می‌دهد ارتباط با پایگاه‌دادهٔ اجاره‌ها یا میزبان‌ها و یا هر دو قطع شده و اتصال مجدد خودکار فعال نیست.
DHCP4_DB_RECONNECT_FAILED
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success, manager ID: %2, timer: %3
168u
168u
این خطا نشان می‌دهد که کارساز پس از انجام حداکثر تعداد تلاش‌های پیکربندی‌شده برای اتصال مجدد، نتوانسته است دوباره به پایگاه‌داده(های) اجاره و/یا میزبان متصل شود. این امر ممکن است باعث خاموش شدن کارساز طبق آنچه در پیکربندی مشخص شده است بشود. قطع ارتباط معمولاً ناشی از مشکلی در شبکه یا کارساز پایگاه‌داده است.
DHCP4_DB_RECONNECT_LOST_CONNECTION
0.0
3.5
database connection lost: manager ID: %1, timer: %2.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که ارتباط قطع شده است و ممکن است سرویس dhcp طبق تنظیمات پیکربندی، به‌منظور تلاش برای بازیابی اتصال غیرفعال شده باشد.
DHCP4_DB_RECONNECT_NO_DB_CTL
0.0
3.5
unexpected error in database reconnect
168u
168u
این یک پیام خطا است که وجود یک خطای برنامه‌نویسی را نشان می‌دهد که نباید رخ دهد. این خطا در صورت قطع ارتباط مانع از تلاش کارساز برای اتصال مجدد به پایگاه‌های داده‌اش شده و کارساز خارج می‌شود. این خطا باید گزارش شود.
DHCP4_DB_RECONNECT_SUCCEEDED
0.0
3.5
database connection recovered: manager ID: %1, timer: %2.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که اتصال بازیابی شده و سرویس dhcp به وضعیت عادی بازگشته است.
DHCP4_DDNS_REQUEST_SEND_FAILED
0.0
3.5
failed sending a request to kea-dhcp-ddns, error: %1, ncr: %2
168u
168u
این پیام خطا نشان می‌دهد که کارساز DHCP4 برای ارسال یک درخواست به‌روزرسانی DDNS به کارساز DHCP-DDNS تلاش کرده است. این خطا به احتمال زیاد ناشی از مشکلی در پیکربندی یا شبکه است.
DHCP4_DECLINE_FAIL
0.0
3.5
%1: error on decline lease for address %2: %3
168u
168u
این پیام خطا نشان می‌دهد که نرم‌افزار به دلیل بروز خطا در حین یک عملیات پایگاه‌داده، در رد کردن (decline) یک اجاره از پایگاه‌دادهٔ اجاره‌ها ناموفق بوده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4 است که تلاش برای رد آن انجام شده بود. آخرین آرگومان نیز شامل دلیل شکست است.
DHCP4_DECLINE_LEASE
0.0
3.5
Received DHCPDECLINE for addr %1 from client %2. The lease will be unavailable for %3 seconds.
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که کلاینت آدرسی را دریافت کرده، اما متوجه شده است که دستگاه دیگری در حال استفاده از آن است و با ارسال یک پیام DHCPDECLINE کارساز را مطلع کرده است. کارساز بررسی کرده است که این آدرس واقعاً به کلاینت اجاره داده شده بوده و سپس آن آدرس را برای مدت‌زمان مشخصی به عنوان غیرقابل استفاده علامت‌گذاری کرده است. این پیام ممکن است بیانگر پیکربندی نادرست در شبکه باشد، چرا که یا یک کلاینت دارای اشکال وجود دارد یا به‌احتمال قوی‌تر دستگاهی در حال استفاده از آدرسی است که مجاز به استفاده از آن نیست. کارساز به‌طور کامل از این وضعیت بازیابی خواهد شد، اما اگر ریشهٔ مشکل یعنی دستگاه ناسازگار یا سرکش (rogue) برطرف نشود، ممکن است این آدرس در آینده دوباره رد شود..SS DHCP4_DECLINE_LEASE_MISMATCH
0.0
3.5
Received DHCPDECLINE for addr %1 from client %2, but the data doesn't match: received hwaddr: %3, lease hwaddr: %4, received client-id: %5, lease client-id: %6
168u
168u
این پیام اطلاعاتی به این معنی است که یک کلاینت تلاش کرده است آدرس خود را به عنوان رد شده (declined - یعنی استفاده‌شده توسط موجودیتی ناشناس) گزارش کند. کارساز اطلاعاتی دربارهٔ یک اجاره (lease) برای آن آدرس دارد، اما نشانی سخت‌افزاری یا شناسهٔ کلاینت با اطلاعات ذخیره‌شده در کارساز مطابقت ندارد. درخواست کلاینت نادیده گرفته خواهد شد.
DHCP4_DECLINE_LEASE_NOT_FOUND
0.0
3.5
Received DHCPDECLINE for addr %1 from client %2, but no such lease found.
168u
168u
این پیام هشدار نشان می‌دهد که یک کلاینت گزارش کرده است که آدرس آن به عنوان تکراری شناسایی شده است (یعنی دستگاه دیگری در شبکه از این آدرس استفاده می‌کند). با این حال، کارساز رکوردی برای این آدرس ندارد. این ممکن است نشان‌دهندهٔ خطای کلاینت یا پاک‌سازی پایگاه‌دادهٔ کارساز باشد.
DHCP4_DEFERRED_OPTION_MISSING
0.0
3.5
%1: cannot find deferred option code %2 in the query
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک گزینهٔ به تعویق افتاده (deferred option) در پرس‌وجو (query) یافت نشود.
DHCP4_DEFERRED_OPTION_UNPACK_FAIL
0.0
3.5
%1: An error unpacking the deferred option %2: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که باز کردن معوق (deferred unpacking) یک گزینه با شکست مواجه شده و باعث شود در بسته بازنشده باقی بماند. آرگومان نخست کد گزینه و آرگومان دوم خطا است.
DHCP4_DEVELOPMENT_VERSION
0.0
3.5
This software is a development branch of Kea. It is not recommended for production use.
168u
168u
این پیام هشدار زمانی نمایش داده می‌شود که نسخه از نوع در حال توسعه (در مقایسه با پایدار) باشد: عدد دوم شمارهٔ نسخه فرد است.
DHCP4_DHCP4O6_BAD_PACKET
0.0
3.5
%1: received malformed DHCPv4o6 packet: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
یک بستهٔ ناهنجار و بدشکل (malformed) DHCPv4o6 دریافت شد.
DHCP4_DHCP4O6_HOOK_SUBNET4_SELECT_DROP
0.0
3.5
%1: packet was dropped, because a callout set the next step to 'drop'
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطهٔ قلاب (hook point) subnet4_select، گام بعدی را روی مقدار 'drop' تنظیم کند. برای این نقطهٔ قلاب خاص، تنظیم روی این مقدار به کارساز دستور می‌دهد بستهٔ دریافت‌شده را دور بیندازد (drop کند). آرگومان مشخص‌کنندهٔ اطلاعات شناسایی کلاینت و تراکنش است.
DHCP4_DHCP4O6_HOOK_SUBNET4_SELECT_SKIP
0.0
3.5
%1: no subnet was selected, because a callout set the next skip flag
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطهٔ قلاب subnet4_select، گام بعدی را روی مقدار SKIP تنظیم کند. برای این نقطهٔ قلاب به‌خصوص، تنظیم این پرچم به کارساز دستور می‌دهد که هیچ زیرشبکه‌ای (subnet) را انتخاب نکند؛ اقدامی که ادامهٔ پردازش را به شدت محدود می‌کند؛ کارساز تنها قادر خواهد بود گزینه‌های سراسری (global options) را ارائه دهد - هیچ آدرسی تخصیص نخواهد یافت. این آرگومان اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند.
DHCP4_DHCP4O6_PACKET_RECEIVED
0.0
3.5
received DHCPv4o6 packet from DHCPv4 server (type %1) for %2 on interface %3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که کارساز در حال دریافت یک بستهٔ DHCPv4o6 از کارساز DHCPv4 از طریق ارتباط بین‌فرایندی (inter-process communication) باشد..SS DHCP4_DHCP4O6_PACKET_SEND
0.0
3.5
%1: trying to send packet %2 (type %3) to %4 port %5 on interface %6 encapsulating %7: %8 (type %9)
168u
168u
در سطح ثبت گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
آرگومان‌ها اطلاعات شناسایی کلاینت (آدرس سخت‌افزاری و شناسهٔ کلاینت)، نام و نوع پیام DHCPv6، آدرس IPv6 و پورت مبدأ، نام رابط شبکه، اطلاعات شناسایی کلاینت DHCPv4، و نام و نوع پیام را مشخص می‌کنند.
DHCP4_DHCP4O6_PACKET_SEND_FAIL
0.0
3.5
%1: failed to send DHCPv4o6 packet: %2
168u
168u
این خطا زمانی در خروجی ظاهر می‌شود که کارساز DHCP IPv4 نتواند یک پیام DHCPv4o6 را به کارساز DHCP IPv6 ارسال کند. دلیل بروز خطا در متن پیام گنجانده شده است.
DHCP4_DHCP4O6_RECEIVE_FAIL
0.0
3.5
failed to receive DHCPv4o6: %1
168u
168u
در سطح ثبت گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که ارتباط بین‌فرآیندی با کارساز DHCPv6 با شکست مواجه شده است. دلیل بروز خطا در متن پیام گنجانده شده است.
DHCP4_DHCP4O6_RECEIVING
0.0
3.5
receiving DHCPv4o6 packet from DHCPv6 server
168u
168u
در سطح ثبت گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که کارساز در حال دریافت یک بستهٔ DHCPv4o6 از کارساز DHCPv6 از طریق سوکت ارتباط بین‌فرآیندی باشد.
DHCP4_DHCP4O6_RESPONSE_DATA
0.0
3.5
%1: responding with packet %2 (type %3), packet details: %4
168u
168u
در سطح ثبت گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
پیامی برای اشکال‌زدایی شامل اطلاعات تفصیلی دربارهٔ بسته‌ای که به کارساز DHCPv6 فرستاده می‌شود تا به کلاینت بازفرستاده شود. آرگومان نخست دربردارندهٔ اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های دوم و سوم به ترتیب حاوی نام و نوع بسته هستند. آرگومان چهارم شامل جزئیات بسته است.
DHCP4_DHCP4O6_SUBNET_DATA
0.0
3.5
%1: the selected subnet details: %2
168u
168u
در سطح ثبت گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات زیرشبکهٔ انتخاب‌شده برای کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم جزئیات زیرشبکه را در بر دارد.
DHCP4_DHCP4O6_SUBNET_SELECTED
0.0
3.5
%1: the subnet with ID %2 was selected for client assignments
168u
168u
در سطح ثبت گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی به انتخاب زیرشبکه‌ای اشاره دارد که قرار است برای تخصیص نشانی و گزینه‌ها به‌کار رود. انتخاب زیرشبکه یکی از گام‌های اولیه در پردازش پیام دریافتی از کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی شناسهٔ زیرشبکهٔ انتخاب‌شده است.
DHCP4_DHCP4O6_SUBNET_SELECTION_FAILED
0.0
3.5
%1: failed to select subnet for the client
168u
168u
در سطح ثبت گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که کارساز نتوانسته است زیرشبکه‌ای را برای کلاینتی که پیامی به کارساز ارسال کرده، انتخاب کند. کارساز قادر به ارائهٔ هیچ اجاره‌ای به کلاینت نخواهد بود؛ چنانچه پیام دریافتی DHCPDISCOVER باشد پیام دور انداخته می‌شود، و اگر پیام دریافتی DHCPREQUEST باشد یک پیام DHCPNAK ارسال خواهد شد. این آرگومان شامل اطلاعات شناسایی کلاینت و تراکنش است..SS DHCP4_DISCOVER
0.0
3.5
%1: server is processing DHCPDISCOVER with hint=%2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان‌دهنده پردازش پیام DHCPDISCOVER دریافت‌شده است. آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم ممکن است حاوی سرنخی برای سرور درباره آدرسی باشد که کلاینت مایل به تخصیص آن است. اگر سرنخی وجود نداشته باشد، این آرگومان متنی را ارائه می‌دهد که نشان می‌دهد سرنخی ارسال نشده است.
DHCP4_DYNAMIC_RECONFIGURATION
0.0
3.5
initiate server reconfiguration using file: %1, after receiving SIGHUP signal or config-reload command
168u
168u
این پیام اطلاعاتی هنگامی ثبت می‌شود که سرور DHCPv4 در پی دریافت سیگنال SIGHUP یا دستور config-reload، پیکربندی مجدد را آغاز می‌کند.
DHCP4_DYNAMIC_RECONFIGURATION_FAIL
0.0
3.5
dynamic server reconfiguration failed with file: %1
168u
168u
این یک پیام خطای مهلک است که در صورت شکست پیکربندی پویای مجدد سرور DHCP ثبت می‌شود.
DHCP4_DYNAMIC_RECONFIGURATION_SUCCESS
0.0
3.5
dynamic server reconfiguration succeeded with file: %1
168u
168u
این پیام اطلاعاتی هنگامی ثبت می‌شود که پیکربندی پویای مجدد سرور DHCP با موفقیت انجام شده باشد.
DHCP4_EMPTY_HOSTNAME
0.0
3.5
%1: received empty hostname from the client, skipping processing of this option
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که سرور یک گزینهٔ Hostname خالی از کلاینت دریافت کرده باشد. سرور گزینه‌های خالی Hostname را پردازش نمی‌کند و بنابراین از این گزینه صرف‌نظر می‌شود. این آرگومان حاوی اطلاعات شناسایی کلاینت و تراکنش است.
DHCP4_FATAL_OPEN_SOCKETS_FAILED
0.0
3.5
maximum number of open service sockets attempts: %1, has been exhausted without success
168u
168u
این خطا نشان می‌دهد که سرور پس از انجام حداکثر تعداد تلاش‌های پیکربندی‌شده برای باز کردن سوکت، در متصل کردن (bind) سوکت‌های سرویس ناموفق بوده است. این امر باعث خاموش شدن سرور مطابق با آنچه در پیکربندی مشخص شده است می‌شود.
DHCP4_FLEX_ID
0.0
3.5
%1: flexible identifier generated for incoming packet: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که نوع رزرو میزبان روی flexible identifier تنظیم شده باشد و عبارت مشخص‌شده در پیکربندی آن، شناسه‌ای را برای بستهٔ ورودی تولید کرده باشد (به یک شناسه ارزیابی شده باشد). این پیام اشکال‌زدایی عمدتاً به عنوان کمکی برای اشکال‌زدایی flexible identifier در نظر گرفته شده است.
DHCP4_GENERATE_FQDN
0.0
3.5
%1: client did not send a FQDN or hostname; FQDN will be generated for the client
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور گزینهٔ Hostname را از کلاینت دریافت نکرده باشد و تولید نام میزبان (hostname generation) فعال باشد. این قابلیت امکان ایجاد مدخل‌های DNS را برای کلاینت‌های ساده فراهم می‌کند.
DHCP4_HOOK_BUFFER_RCVD_DROP
0.0
3.5
received buffer from %1 to %2 over interface %3 was dropped because a callout set the drop flag
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک کال‌اوت (callout) نصب‌شده روی نقطهٔ قلاب buffer4_receive، پرچم drop را تنظیم کرده باشد. برای این نقطهٔ قلاب به‌خصوص، تنظیم این پرچم توسط کال‌اوت به سرور دستور می‌دهد تا بسته را دور بیندازد. آرگومان‌ها آدرس‌های مبدأ و مقصد IPv4 و همچنین نام رابطی را که بافر روی آن دریافت شده است مشخص می‌کنند..SS DHCP4_HOOK_BUFFER_RCVD_SKIP
0.0
3.5
بافر دریافت‌شده از %1 به %2 روی رابط %3 تجزیه نمی‌شود زیرا یک callout گام بعدی را روی SKIP تنظیم کرده است.
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب buffer4_receive، گام بعدی را روی SKIP تنظیم کرده باشد. برای این نقطه قلاب خاص، این مقدارِ تنظیم‌شده توسط یک callout به سرور دستور می‌دهد که بافر را تجزیه نکند زیرا پیش‌تر توسط قلاب تجزیه شده است. آرگومان‌ها نشانی IPv4 مبدأ و مقصد و همچنین نام رابطی را که بافر از طریق آن دریافت شده است مشخص می‌کنند.
DHCP4_HOOK_BUFFER_SEND_SKIP
0.0
3.5
%1: پاسخ آماده‌شده دور انداخته شد زیرا یک callout گام بعدی را روی SKIP تنظیم کرده است.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب buffer4_send، گام بعدی را روی SKIP تنظیم کرده باشد. برای این نقطه قلاب خاص، مقدار SKIP تنظیم‌شده توسط یک callout به سرور دستور می‌دهد که بسته را دور بیندازد. سرور تمامی پردازش‌ها را تکمیل کرده است (برای مثال ممکن است اجاره‌ها را تخصیص داده، به‌روزرسانی کرده یا آزاد کرده باشد)، اما پاسخ برای کلاینت ارسال نخواهد شد.
DHCP4_HOOK_DDNS_UPDATE
0.0
3.5
یک قلاب پارامترهای DDNS را به‌روزرسانی کرده است: hostname %1=>%2, forward update %3=>%4, reverse update %5=>%6
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام نشان می‌دهد که یک قلاب در نقطه قلاب ddns4_update فراخوانی شده و آن قلاب پارامترهای به‌روزرسانی DDNS را به‌روزرسانی کرده است: hostname، یا اینکه به‌روزرسانی مستقیم DDNS (رکورد A) یا معکوس (رکورد PTR) انجام شود یا خیر.
DHCP4_HOOK_DECLINE_SKIP
0.0
3.5
calloutهای قلاب Decline4 وضعیت را روی DROP تنظیم کردند، نادیده‌گرفتن بسته.
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام نشان می‌دهد که سرور یک پیام DHCPDECLINE دریافت کرده و صحت آن و تطابقش با اطلاعات اجارهٔ سرور تأیید شده است. سرور قلاب‌های نقطه قلاب decline4 را فراخوانی کرده و یکی از calloutها وضعیت گام بعدی را روی DROP تنظیم کرده است. سرور اکنون پردازش بسته را به گونه‌ای متوقف می‌کند که گویی هرگز دریافت نشده است. اجاره همچنان به این کلاینت اختصاص خواهد داشت.
DHCP4_HOOK_LEASE4_OFFER_ARGUMENT_MISSING
0.0
3.5
calloutهای قلاب، آرگومان مورد انتظار %1 را برای %2 تنظیم نکردند
168u
168u
این پیام خطا زمانی چاپ می‌شود که هیچ‌یک از calloutهای نصب‌شده روی نقطه قلاب lease4_offer، آرگومان مورد انتظار را در وضعیت callout تنظیم نکرده باشند. این یک خطای برنامه‌نویسی در کتابخانه‌های قلابِ نصب‌شده است. جزئیات آرگومان و پرس‌وجویی که در آن زمان در حال پردازش بوده، در آرگومان‌های لاگ ارائه شده است.
DHCP4_HOOK_LEASE4_OFFER_DROP
0.0
3.5
%1: بسته دور انداخته شد، زیرا یک callout گام بعدی را روی DROP تنظیم کرده است
168u
168u
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب lease4_offer گام بعدی را روی DROP تنظیم کند.
DHCP4_HOOK_LEASE4_OFFER_PARK
0.0
3.5
%1: بسته پارک شد، زیرا یک callout گام بعدی را روی PARK تنظیم کرده است
168u
168u
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب lease4_offer گام بعدی را روی PARK تنظیم کند.
DHCP4_HOOK_LEASE4_OFFER_PARKING_LOT_FULL
0.0
3.5
محدودیت parked-packet-limit به میزان %1 رسیده است، در حال دور انداختن پرس‌وجو: %2
168u
168u
این پیام اشکال‌زدایی زمانی رخ می‌دهد که پارکینگ (محل نگهداری بسته‌ها) مورد استفاده برای نگه‌داشتن پرس‌وجوهای کلاینت در حین اتمام کار کتابخانهٔ قلاب برای آن‌ها، به حد تعیین‌شده توسط پارامتر سراسری parked-packet-limit رسیده یا از آن فراتر رفته باشد. این حالت می‌تواند زمانی رخ دهد که kea-dhcp4 در حال استفاده از کتابخانه‌های قلاب (مانند ping-check) باشد که callout مربوط به "lease4_offer" را پیاده‌سازی کرده‌اند، و پرس‌وجوهای کلاینت سریع‌تر از توان پاسخ‌گویی آن calloutها دریافت شوند.
DHCP4_HOOK_LEASE4_RELEASE_SKIP
0.0
3.5
%1: اجاره آزاد نشد زیرا یک callout گام بعدی را روی SKIP تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب lease4_release، وضعیت گام بعدی را روی SKIP تنظیم کرده باشد. برای این نقطه قلاب خاص، مقدار تنظیم‌شده توسط یک callout به سرور دستور می‌دهد که اجاره را آزاد نکند..SS DHCP4_HOOK_LEASES4_COMMITTED_DROP
0.0
3.5
%1: packet is dropped, because a callout set the next step to DROP
168u
168u
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب leases4_committed، گام بعدی را بر روی DROP تنظیم کند.
DHCP4_HOOK_LEASES4_COMMITTED_PARK
0.0
3.5
%1: packet is parked, because a callout set the next step to PARK
168u
168u
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب leases4_committed، گام بعدی را بر روی PARK تنظیم کند.
DHCP4_HOOK_LEASES4_COMMITTED_PARKING_LOT_FULL
0.0
3.5
The parked-packet-limit %1, has been reached, dropping query: %2
168u
168u
این پیام اشکال‌زدایی زمانی رخ می‌دهد که توقف‌گاه (parking lot) مورد استفاده برای نگه‌داشتن پرس‌وجوهای کلاینت در حین تکمیل کار کتابخانه قلاب (hook library) برای آن‌ها، به محدودیت تعیین‌شده توسط پارامتر سراسری parked-packet-limit رسیده یا از آن فراتر رفته باشد. این موضوع می‌تواند زمانی رخ دهد که kea-dhcp4 از کتابخانه‌های قلاب (مانند HA) که callout مربوط به "leases4-committed" را پیاده‌سازی کرده‌اند استفاده کند و پرس‌وجوهای کلاینت سریع‌تر از توانایی آن calloutها برای انجام و پاسخ‌گویی به آن‌ها برسند.
DHCP4_HOOK_PACKET_RCVD_SKIP
0.0
3.5
%1: packet is dropped, because a callout set the next step to SKIP
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده بر روی نقطه قلاب pkt4_receive، گام بعدی را روی SKIP تنظیم کند. برای این نقطه قلاب به‌خصوص، مقدار تنظیم‌شده برای پرچم به سرور دستور می‌دهد که بسته را دور بیندازد.
DHCP4_HOOK_PACKET_SEND_DROP
0.0
3.5
%1: prepared DHCPv4 response was not sent because a callout set the next step to DROP
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده بر روی نقطه قلاب pkt4_send، گام بعدی را روی DROP تنظیم کند. برای این نقطه قلاب به‌خصوص، تنظیم این مقدار توسط یک callout به سرور دستور می‌دهد که بسته را دور بیندازد. این در عمل به این معناست که کلاینت هیچ پاسخی دریافت نخواهد کرد، حتی با اینکه سرور درخواست کلاینت را پردازش کرده و بر اساس آن عمل کرده باشد (برای نمونه، احتمالاً یک اجاره تخصیص داده باشد). این آرگومان اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند.
DHCP4_HOOK_PACKET_SEND_SKIP
0.0
3.5
%1: prepared response is not sent, because a callout set the next step to SKIP
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده بر روی نقطه قلاب pkt4_send، گام بعدی را بر روی SKIP تنظیم کند. برای این نقطه قلاب خاص، این تنظیم به سرور دستور می‌دهد که بسته را دور بیندازد. این بدان معناست که کلاینت هیچ پاسخی دریافت نخواهد کرد، حتی با وجود اینکه سرور درخواست کلاینت را پردازش کرده و بر روی آن اقدام کرده باشد (مثلاً احتمالاً یک اجاره تخصیص داده باشد).
DHCP4_HOOK_SUBNET4_SELECT_4O6_PARKING_LOT_FULL
0.0
3.5
The parked-packet-limit %1, has been reached, dropping query: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی رخ می‌دهد که توقف‌گاه (parking lot) مورد استفاده برای نگه‌داشتن پرس‌وجوهای کلاینت در حین اتمام کار کتابخانه قلاب برای آن‌ها، به حد تعیین‌شده توسط پارامتر سراسری parked-packet-limit رسیده یا از آن فراتر رفته باشد. این امر می‌تواند زمانی رخ دهد که kea-dhcp4 از کتابخانه‌های قلاب (مانند radius) که callout مربوط به "subnet4_select" را پیاده‌سازی کرده‌اند استفاده کند و پرس‌وجوهای کلاینت DHCP4O6 سریع‌تر از توانایی آن calloutها برای پاسخ‌گویی به آن‌ها دریافت شوند.
DHCP4_HOOK_SUBNET4_SELECT_DROP
0.0
3.5
%1: packet was dropped, because a callout set the next step to 'drop'
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده بر روی نقطه قلاب subnet4_select، گام بعدی را بر روی مقدار 'drop' تنظیم کند. برای این نقطه قلاب خاص، تنظیم شدن روی این مقدار به سرور دستور می‌دهد که بسته دریافتی را دور بیندازد. این آرگومان اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند..SS DHCP4_HOOK_SUBNET4_SELECT_PARK
0.0
3.5
%1: packet was parked
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک فراخوان (callout) نصب‌شده روی
نقطه قلاب (hook point) subnet4_select، پرچم park را تنظیم کند. آرگومان حاوی
اطلاعات شناسایی کلاینت و تراکنش است.
DHCP4_HOOK_SUBNET4_SELECT_PARKING_LOT_FULL
0.0
3.5
The parked-packet-limit %1, has been reached, dropping query: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی رخ می‌دهد که توقفگاه موقت (parking lot) مورد استفاده
برای نگه‌داری پرس‌وجوهای کلاینت تا زمان تکمیل کار کتابخانه قلاب برای آن‌ها،
به حد تعیین‌شده توسط پارامتر سراسری parked-packet-limit رسیده یا از آن فراتر
رفته باشد. این حالت می‌تواند زمانی رخ دهد که kea-dhcp4 از کتابخانه‌های قلاب
(مانند radius) که فراخوان "subnet4_select" را پیاده‌سازی می‌کنند استفاده کند
و پرس‌وجوهای کلاینت با سرعتی بیشتر از توان پاسخ‌گویی آن فراخوان‌ها برسند.
DHCP4_HOOK_SUBNET4_SELECT_SKIP
0.0
3.5
%1: no subnet was selected, because a callout set the next skip flag
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک فراخوان نصب‌شده روی نقطه قلاب
subnet4_select، گام بعدی را روی مقدار SKIP تنظیم کند. برای این نقطه قلاب خاص،
تنظیم این پرچم به سرور دستور می‌دهد که زیرشبکه‌ای انتخاب نکند؛ اقدامی که
پردازش‌های بعدی را به شدت محدود می‌کند؛ سرور تنها قادر خواهد بود گزینه‌های
سراسری را ارائه دهد - هیچ آدرسی تخصیص داده نخواهد شد. آرگومان، اطلاعات
شناسایی کلاینت و تراکنش را مشخص می‌کند.
DHCP4_HOOK_SUBNET6_SELECT_PARKING_LOT_FULL
0.0
3.5
The parked-packet-limit %1, has been reached, dropping query: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی رخ می‌دهد که توقفگاه موقت (parking lot) مورد استفاده
برای نگه‌داری پرس‌وجوهای کلاینت تا زمان تکمیل کار کتابخانه قلاب برای آن‌ها،
به حد تعیین‌شده توسط پارامتر سراسری parked-packet-limit رسیده یا از آن فراتر
رفته باشد. این حالت می‌تواند زمانی رخ دهد که kea-dhcp4 از کتابخانه‌های قلاب
(مانند radius) که فراخوان "subnet6_select" را پیاده‌سازی می‌کنند استفاده کند
و پرس‌وجوهای کلاینت با سرعتی بیشتر از توان پاسخ‌گویی آن فراخوان‌ها برسند.
DHCP4_INFORM_DIRECT_REPLY
0.0
3.5
%1: DHCPACK in reply to the DHCPINFORM will be sent directly to %2 over %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که DHCPACK به‌جای ارسال از طریق رله (relay)،
به‌طور مستقیم برای کلاینت ارسال گردد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و
تراکنش است. آرگومان دوم حاوی آدرس IPv4 کلاینت است که پاسخ به آن ارسال خواهد شد.
آرگومان سوم شامل نام واسط محلی است.
DHCP4_INIT_FAIL
0.0
3.5
failed to initialize Kea server: %1
168u
168u
راه‌اندازی اولیه سرور Kea با شکست مواجه شد. این مسئله ممکن است به دلیل ناموفق
بودن پیکربندی باشد، یا اینکه سرور هنگام راه‌اندازی با خطای بحرانی دیگری روبه‌رو
شده است. پیام خطای پیوست‌شده جزئیات بیشتری درباره این مشکل ارائه می‌دهد.
DHCP4_INIT_REBOOT
0.0
3.5
%1: client is in INIT-REBOOT state and requests address %2
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کلاینت در وضعیت INIT-REBOOT قرار دارد
و درخواست تخصیص آدرس IPv4 را دارد که هم‌اکنون در حال استفاده از آن است. آرگومان
نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم آدرس IPv4 درخواستی را
مشخص می‌کند.
DHCP4_LEASE_ALLOC
0.0
3.5
%1: lease %2 has been allocated for %3 seconds
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که سرور در پاسخ به پیام DHCPREQUEST کلاینت،
با موفقیت یک اجاره (lease) را اعطا کرده است. اطلاعات اجاره در پیام DHCPACK
برای کلاینت ارسال خواهد شد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و
تراکنش است. آرگومان دوم حاوی آدرس IPv4 تخصیص‌یافته است. آرگومان سوم مدت‌زمان
اعتبار است..SS DHCP4_LEASE_OFFER
0.0
3.5
%1: lease %2 will be offered
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کارگزار اجاره‌ای را برای پیشنهاد به کلاینت پیدا کرده است. این بر عهدهٔ کلاینت است که از میان کارگزارهایی که اجاره پیشنهاد داده‌اند یکی را انتخاب کرده و تخصیص را با آن کارگزار ادامه دهد. آرگومان اول اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم آدرس IPv4 پیشنهادی را تعیین می‌کند.
DHCP4_LEASE_QUERY_PACKET_PACK_FAILED
0.0
3.5
preparing on-wire-format of the packet to be sent: %1, failed %2
168u
168u
این پیام خطا زمانی صادر می‌شود که آماده‌سازی قالب روی خط (on-wire format) بسته ارسالی با شکست مواجه شده باشد. آرگومان اول جزئیات بسته را ارائه می‌دهد. آرگومان دوم ماهیت خطا را توضیح می‌دهد.
DHCP4_LEASE_QUERY_PACKET_UNPACK_FAILED
0.0
3.5
failed to parse query from %1 to %2, received over interface %3, reason: %4
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که DHCPLEASEQUERY دریافتی معیوب باشد و توسط فراخوان buffer4_receive قابل تجزیه نباشد. این پرس‌وجو توسط کارگزار دور انداخته خواهد شد. سه آرگومان نخست آدرس IP مبدأ، آدرس IP مقصد و رابط شبکه را مشخص می‌کنند. آرگومان آخر دلیل شکست را ارائه می‌دهد.
DHCP4_LEASE_QUERY_PROCESS_FAILED
0.0
3.5
processing failed for lease query: %1, reason: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام خطا زمانی صادر می‌شود که کارگزار در پردازش یک DHCPLEASEQUERY با خطا مواجه شده باشد. آرگومان اول جزئیات پرس‌وجو و آرگومان دوم توضیحی دربارهٔ خطا را ارائه می‌دهد.
DHCP4_LEASE_QUERY_RECEIVED
0.0
3.5
received query: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک پرس‌وجوی DHCPLEASEQUERY دریافت شده باشد. این آرگومان جزئیات پرس‌وجو را ارائه می‌دهد.
DHCP4_LEASE_QUERY_RESPONSE_SENT
0.0
3.5
response: %1, sent to %2:%3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که پاسخی به یک DHCPLEASEQUERY برای درخواست‌کننده ارسال شده باشد. آرگومان اول جزئیات پاسخ را ارائه می‌دهد و آرگومان‌های دوم و سوم آدرس IP و پورتی هستند که پاسخ به آن ارسال شده است.
DHCP4_LEASE_QUERY_SEND_FAILED
0.0
3.5
unable to send response: %1, iface: %2, address %3:%4 error: %5
168u
168u
این پیام خطا زمانی صادر می‌شود که کارگزار قادر به ارسال پاسخ پرس‌وجوی اجاره (DHCPLEASEQUERY) به درخواست‌کننده نبوده است. آرگومان اول جزئیات پرس‌وجو را ارائه می‌دهد و به دنبال آن رابط خروجی، آدرس IP و پورت، و در نهایت خود خطا می‌آید.
DHCP4_LEASE_REUSE
0.0
3.5
%1: lease %2 has been reused for %3 seconds
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کارگزار با موفقیت یک اجاره را در پاسخ به پیام کلاینت مجدداً استفاده کرده است. اطلاعات اجاره در پیام DHCPACK به کلاینت ارسال خواهد شد. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4 تخصیص‌یافته است. آرگومان سوم مدت‌زمان اعتبار (validity lifetime) است.
DHCP4_MULTI_THREADING_INFO
0.0
3.5
enabled: %1, number of threads: %2, queue size: %3
168u
168u
این پیامی است که برخی اطلاعات را دربارهٔ پارامترهای چندنخی (multi-threading) که کارگزار با آن‌ها اجرا می‌شود فهرست می‌کند..SS DHCP4_NCR_CREATION_FAILED
0.0
3.5
%1: failed to generate name change requests for DNS: %2
168u
168u
این پیام نشان می‌دهد که کارساز قادر به تولید NameChangeRequests نبوده است؛ درخواست‌هایی که باید برای ایجاد رکوردهای جدید DNS جهت اجارهٔ در حال دریافت یا به‌روزرسانی رکوردهای موجود برای اجارهٔ تمدیدشده، به پیمانهٔ kea-dhcp_ddns ارسال شوند. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم دلیل این شکست را شامل می‌شود.
DHCP4_NOT_RUNNING
0.0
3.5
DHCPv4 server is not running
168u
168u
یک پیام هشدار است که هنگام تلاش برای متوقف کردن کارساز DHCPv4 در حالی که در حال اجرا نیست صادر می‌شود.
DHCP4_NO_LEASE_INIT_REBOOT
0.0
3.5
%1: no lease for address %2 requested by INIT-REBOOT client
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کلاینت در وضعیت INIT-REBOOT درخواست یک نشانی IPv4 کرده است اما این کلاینت ناشناخته است. کارساز پاسخ نخواهد داد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و شناسهٔ تراکنش است. آرگومان دوم شامل نشانی IPv4 درخواست‌شده توسط کلاینت است.
DHCP4_OPEN_SOCKET
0.0
3.5
opening service sockets on port %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۰ ثبت می‌شود.
این پیام اشکال‌زدایی در زمان راه‌اندازی صادر می‌شود و نشان‌دهندهٔ این است که کارساز DHCPv4 در آستانهٔ باز کردن سوکت‌ها روی درگاه مشخص‌شده است.
DHCP4_OPEN_SOCKETS_FAILED
0.0
3.5
maximum number of open service sockets attempts: %1, has been exhausted without success
168u
168u
این خطا نشان می‌دهد که کارساز پس از انجام حداکثر دفعات تلاشِ پیکربندی‌شده، در متصل ساختن (bind) سوکت‌های سرویس ناموفق بوده است.
DHCP4_OPEN_SOCKETS_NO_RECONNECT_CTL
0.0
3.5
unexpected error in bind service sockets.
168u
168u
این یک پیام خطا است که بیانگر خطایی در سطح کد برنامه بوده و نباید رخ دهد. این خطا کارساز را از تلاش برای متصل ساختن (bind) سوکت‌های سرویس خود در صورت در دسترس نبودن منع می‌کند و کارساز خارج می‌شود. این خطا باید گزارش شود.
DHCP4_PACKET_DROP_0001
0.0
3.5
%1: failed to parse packet from %2 to %3, received over interface %4, reason: %5, %6
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
کارساز DHCPv4 بسته‌ای دریافت کرده که قادر به تجزیه و تحلیل آن نیست. دلیل نامعتبر بودن بسته در پیام گنجانده شده است.
DHCP4_PACKET_DROP_0002
0.0
3.5
%1, from interface %2: no suitable subnet configured for a direct client
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اطلاع‌رسانی هنگامی ثبت می‌شود که پیامی از یک کلاینت با اتصال مستقیم دریافت شده باشد، اما هیچ زیرشبکهٔ مناسبی برای واسطی که این پیام از طریق آن دریافت شده پیکربندی نشده است. نشانی IPv4 تخصیص‌یافته به این واسط باید متعلق به یکی از زیرشبکه‌های پیکربندی‌شده باشد؛ در غیر این صورت پیام دریافتی دور انداخته می‌شود (drop).
DHCP4_PACKET_DROP_0003
0.0
3.5
%1, from interface %2: it contains a foreign server identifier
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که پیام DHCPv4 دریافتی به این دلیل که خطاب به کارساز دیگری ارسال شده است دور انداخته می‌شود؛ به این معنی که شناسهٔ کارساز موجود در پیام با شناسهٔ مورد استفادهٔ کارساز ما مطابقت ندارد. آرگومان‌های این پیام حاوی شناسهٔ تراکنش و واسطی هستند که پیام از طریق آن دریافت شده است..SS DHCP4_PACKET_DROP_0004
0.0
3.5
%1, from interface %2: missing msg-type option
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که اطلاع می‌دهد بستهٔ دریافتی DHCPv4 فاقد گزینهٔ اجباری نوع پیام DHCP بوده و بنابراین دور ریخته شده است. آرگومان‌ها اطلاعات شناسایی کلاینت و تراکنش و همچنین رابطی را که پیام از طریق آن دریافت شده است مشخص می‌کنند.
DHCP4_PACKET_DROP_0005
0.0
3.5
%1: unrecognized type %2 in option 53
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که نوع پیام حمل‌شده در گزینهٔ ۵۳ DHCPv4 توسط سرور ناشناخته است. انواع پیام معتبر در وب‌سایت IANA فهرست شده‌اند: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#message-type-53.
این پیام توسط سرور پردازش نخواهد شد. آرگومان‌ها اطلاعات شناسایی کلاینت و تراکنش و همچنین نوع پیام دریافت شده را مشخص می‌کنند.
DHCP4_PACKET_DROP_0006
0.0
3.5
%1: unsupported DHCPv4 message type %2
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که نوع پیام حمل‌شده در گزینهٔ ۵۳ DHCPv4 معتبر است اما پیام توسط سرور پردازش نخواهد شد. این شامل پیام‌هایی می‌شود که معمولاً توسط سرور به کلاینت ارسال می‌شوند، مانند DHCPOFFER، DHCPACK، DHCPNAK و غیره. آرگومان اول اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم نوع پیام را مشخص می‌نماید.
DHCP4_PACKET_DROP_0007
0.0
3.5
%1: failed to process packet: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این یک پیام کلی و جامع است که نشان می‌دهد پردازش یک بستهٔ دریافتی ناموفق بوده است. دلیل آن در پیام ذکر شده است. سرور پاسخی ارسال نخواهد کرد بلکه در عوض بسته را نادیده می‌گیرد. آرگومان اول حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم شامل جزئیات خطا است.
DHCP4_PACKET_DROP_0008
0.0
3.5
%1: DHCP service is globally disabled
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بسته‌ای به دلیل غیرفعال بودن موقت سرویس DHCP دور ریخته شود. این موضوع بر تمام بسته‌های DHCP دریافتی تأثیر می‌گذارد. سرویس ممکن است توسط دستور کنترلی "dhcp-enable" یا به‌طور خودکار پس از گذشت مدت زمان مشخصی از دریافت دستور "dhcp-disable" مجدداً فعال شود.
DHCP4_PACKET_DROP_0009
0.0
3.5
%1: Option 53 missing (no DHCP message type), is this a BOOTP packet?
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بسته‌ای به دلیل نداشتن گزینهٔ ۵۳ و در نتیجه عدم وجود نوع پیام DHCP دور ریخته شود. محتمل‌ترین توضیح این است که بسته از نوع BOOTP بوده است.
DHCP4_PACKET_DROP_0010
0.0
3.5
dropped as member of the special class 'DROP': %1, %2
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که یک بستهٔ ورودی در کلاس ویژهٔ 'DROP' طبقه‌بندی شده و دور ریخته شود. جزئیات بسته نمایش داده می‌شوند.
DHCP4_PACKET_DROP_0011
0.0
3.5
dropped as sent by the same client than a packet being processed by another thread: dropped %1, %2 by thread %3 as duplicate of %4, %5 processed by thread %6
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
در حال حاضر پردازش چندریسمانی (multi-threading) با دور انداختن بسته‌های جدید تا زمان پایان پردازش، از تداخل و رقابت بین بسته‌های ارسال‌شده توسط کلاینتی با گزینهٔ شناسه کلاینت (client id) یکسان جلوگیری می‌کند.
جزئیات بسته و شناسه‌های ریسمان (thread) برای هر دو بسته در این پیام گنجانده شده است..SS DHCP4_PACKET_DROP_0012
0.0
3.5
dropped as sent by the same client than a packet being processed by another thread: dropped %1, %2 by thread %3 as duplicate of %4, %5 processed by thread %6
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
در حال حاضر پردازش چندرشته‌ای (multi-threading) با دور انداختن بسته‌های جدید تا زمان پایان پردازش، از ایجاد شرایط رقابتی (race conditions) میان بسته‌های ارسال‌شده توسط کلاینتی با آدرس سخت‌افزاری یکسان جلوگیری می‌کند.
جزئیات بسته و شناسه‌های رشته برای هر دو بسته در این پیام هشدار گنجانده شده‌اند.
DHCP4_PACKET_DROP_0013
0.0
3.5
dropped as member of the special class 'DROP' after host reservation lookup: %1, %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بسته ورودی پس از جستجوی رزرو میزبان (host reservation lookup)، در کلاس ویژه 'DROP' دسته‌بندی شده و دور انداخته شود.
جزئیات بسته نمایش داده می‌شوند.
DHCP4_PACKET_DROP_0014
0.0
3.5
dropped as member of the special class 'DROP' after early global host reservations lookup: %1, %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بسته ورودی پس از جستجوی زودهنگام رزروهای سراسری میزبان (early global host reservations lookup)، در کلاس ویژه 'DROP' دسته‌بندی شده و دور انداخته شود. جزئیات بسته نمایش داده می‌شوند.
DHCP4_PACKET_NAK_0001
0.0
3.5
%1: failed to select a subnet for incoming packet, src %2, type %3
168u
168u
این پیام خطا زمانی صادر می‌شود که بسته‌ای از زیرشبکه‌ای (subnet) دریافت شده باشد که سرور DHCPv4 برای آن پیکربندی نشده است. محتمل‌ترین علت، پیکربندی نادرست سرور است. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4 مبدأ بسته است. آرگومان سوم شامل نام بسته دریافتی است.
DHCP4_PACKET_NAK_0002
0.0
3.5
%1: invalid address %2 requested by INIT-REBOOT
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کلاینت در وضعیت INIT-REBOOT، آدرس IPv4 را درخواست کرده باشد که به آن تخصیص داده نشده است. سرور به این کلاینت با DHCPNAK پاسخ خواهد داد. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4 درخواستی توسط کلاینت است.
DHCP4_PACKET_NAK_0003
0.0
3.5
%1: failed to advertise a lease, client sent ciaddr %2, requested-ip-address %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که سرور پس از دریافت پیام DISCOVER از کلاینت مشخص‌شده، نتوانسته اجاره‌ای (lease) را به آن پیشنهاد دهد. دلایل احتمالی متعددی برای این شکست وجود دارد. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4 در فیلد ciaddr است. آرگومان سوم حاوی آدرس IPv4 در گزینه requested-ip-address (در صورت وجود) است.
DHCP4_PACKET_NAK_0004
0.0
3.5
%1: failed to grant a lease, client sent ciaddr %2, requested-ip-address %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که سرور پس از دریافت پیام REQUEST از کلاینت مشخص‌شده، نتوانسته اجاره‌ای را به آن اعطا کند. دلایل احتمالی متعددی برای این شکست وجود دارد. پیام‌های اضافی علت را نشان خواهند داد. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4 در فیلد ciaddr است. آرگومان سوم حاوی آدرس IPv4 در گزینه requested-ip-address (در صورت وجود) است.
DHCP4_PACKET_NAK_0005
0.0
3.5
nacked as member of the special class 'REJECT': %1, %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام نشان می‌دهد که سرور یک DHCPNAK برگردانده است زیرا پرس‌وجوی (query) ورودی در کلاس ویژه 'REJECT' دسته‌بندی شده است. جزئیات بسته نمایش داده می‌شوند..SS DHCP4_PACKET_OPTIONS_SKIPPED
0.0
3.5
%1: An error unpacking an option, caused subsequent options to be skipped: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که استخراج (unpack) یک گزینه با شکست مواجه شده و در نتیجه استخراج گزینه‌های باقی‌مانده در بسته غیرممکن گردد. با این وجود، سرور همچنان تلاش خواهد کرد تا بسته را پردازش کرده و به آن پاسخ دهد.
DHCP4_PACKET_PACK
0.0
3.5
%1: preparing on-wire format of the packet to be sent
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که سرور آماده‌سازی قالب روی شبکه (on-wire format) بسته را برای ارسال به کلاینت آغاز می‌کند. این آرگومان اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند.
DHCP4_PACKET_PACK_FAIL
0.0
3.5
%1: preparing on-wire-format of the packet to be sent failed %2
168u
168u
این پیام خطا زمانی صادر می‌شود که آماده‌سازی قالب روی شبکه (on-wire format) بسته با شکست مواجه شده باشد. آرگومان نخست، کلاینت و تراکنش DHCP را مشخص می‌کند. آرگومان دوم حاوی رشته پیام خطا است.
DHCP4_PACKET_PROCESS_EXCEPTION
0.0
3.5
%1: exception occurred during packet processing
168u
168u
این پیام خطا نشان می‌دهد که هنگام پردازش بسته، یک استثنای (exception) غیر استاندارد رخ داده که توسط سایر گرداننده‌های اختصاصی‌تر استثنا دریافت نشده است. این بسته دور ریخته می‌شود (drop) و سرور به کار خود ادامه خواهد داد.
DHCP4_PACKET_PROCESS_EXCEPTION_MAIN
0.0
3.5
exception occurred during packet processing
168u
168u
این پیام خطا نشان می‌دهد که در حین پردازش بسته، یک استثنای غیر استاندارد رخ داده که توسط سایر گرداننده‌های اختصاصی‌تر استثنا دریافت نشده است. این بسته دور ریخته شده و سرور به کار خود ادامه خواهد داد. این پیام خطا ممکن است در حلقه اصلی پردازش سرور ظاهر شود.
DHCP4_PACKET_PROCESS_STD_EXCEPTION
0.0
3.5
%1: exception occurred during packet processing: %2
168u
168u
این پیام خطا نشان می‌دهد که هنگام پردازش بسته، یک استثنای استاندارد رخ داده که توسط سایر گرداننده‌های اختصاصی‌تر استثنا دریافت نشده است. این بسته دور ریخته می‌شود (drop) و سرور به فعالیت خود ادامه خواهد داد.
DHCP4_PACKET_PROCESS_STD_EXCEPTION_MAIN
0.0
3.5
exception occurred during packet processing: %1
168u
168u
این پیام خطا بیانگر آن است که هنگام پردازش بسته، یک استثنای استاندارد رخ داده که توسط سایر گرداننده‌های اختصاصی‌تر استثنا دریافت نشده است. این بسته دور انداخته می‌شود و سرور به کار خود ادامه خواهد داد. این پیام خطا ممکن است در حلقه اصلی پردازش سرور ظاهر گردد.
DHCP4_PACKET_QUEUE_FULL
0.0
3.5
multi-threading packet queue is full
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیامی برای اشکال‌زدایی که نشان می‌دهد صف چندنخی (multi-threading) بسته‌ها پر است؛ بنابراین قدیمی‌ترین بسته موجود در صف حذف شد تا جا برای بسته دریافت‌شده جدید باز شود.
DHCP4_PACKET_RECEIVED
0.0
3.5
%1: %2 (type %3) received from %4 to %5 on interface %6
168u
168u
یک پیام INFO که نشان می‌دهد سرور بسته مشخص‌شده را روی رابط شبکه (interface) معین دریافت کرده است. آرگومان نخست اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان‌های دوم و سوم به ترتیب نام پیام DHCPv4 و نوع عددی آن را مشخص می‌کنند. باقی آرگومان‌ها نشانی IPv4 مبدأ، نشانی IPv4 مقصد و نام رابطی که پیام روی آن دریافت شده است را مشخص می‌کنند..SS DHCP4_PACKET_SEND
0.0
3.5
%1: trying to send packet %2 (type %3) from %4:%5 to %6:%7 on interface %8
168u
168u
یک پیام INFO که نشان می‌دهد کارساز در تلاش است نوع مشخص‌شده‌ای از بسته را ارسال کند. آرگومان‌ها اطلاعات شناسایی کلاینت (آدرس سخت‌افزاری و شناسه کلاینت)، نام و نوع پیام DHCP، آدرس و درگاه IPv4 مبدأ، آدرس و درگاه IPv4 مقصد و نام رابط شبکه را مشخص می‌کنند. این پیام اشکال‌زدایی (debug) زمانی صادر می‌شود که کارساز در حال تلاش برای ارسال پاسخ به کلاینت است. هنگامی که کارساز از یک سوکت UDP برای ارسال بسته استفاده می‌کند، مواردی وجود دارد که ممکن است این عملیات ناموفق باشد و هیچ پیام خطایی نمایش داده نشود. یکی از این شرایط زمانی رخ می‌دهد که کارساز در حال ارسال تک‌پخشی (unicast) پاسخ به 'ciaddr' مربوط به یک پیام DHCPINFORM است. این کار اغلب نیازمند انتشار همگانی (broadcasting) یک پیام ARP برای به دست آوردن آدرس لایه پیوند مقصد تک‌پخشی است. اگر پیام‌های همگانی ARP بر اساس سیاست‌های دیوار آتش (firewall) در شبکه مسدود شده باشند، پیام ARP پاسخی در پی نخواهد داشت. در نتیجه، پاسخ به DHCPINFORM ارسال نخواهد شد. از آنجا که ارتباطات ARP تحت کنترل سیستم‌عامل است، Kea از حذف شدن (drop) بسته‌ای که در تلاش برای ارسال آن است مطلع نمی‌شود و راهی برای نمایش پیام خطا ندارد.
DHCP4_PACKET_SEND_FAIL
0.0
3.5
%1: failed to send DHCPv4 packet: %2
168u
168u
این خطا زمانی در خروجی ثبت می‌شود که کارساز DHCPv4 نتواند پیام DHCP سرهم‌شده را به کلاینت ارسال کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم دلیل شکست را در بر دارد.
DHCP4_PARSER_COMMIT_EXCEPTION
0.0
3.5
parser failed to commit changes
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی کارساز DHCPv4، مجموعه‌ای از تجزیه‌کننده‌ها با موفقیت ایجاد شدند، اما یکی از آن‌ها به دلیل رخ دادن یک استثنای سیستمی سطح پایین (low-level system exception) در اعمال نهایی (commit) تغییرات خود شکست خورد. ممکن است پیام‌های دیگری برای نشان دادن دلیل این خطا در خروجی ثبت شوند.
DHCP4_PARSER_COMMIT_FAIL
0.0
3.5
parser failed to commit changes: %1
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی کارساز DHCPv4، مجموعه‌ای از تجزیه‌کننده‌ها با موفقیت ایجاد شدند، اما یکی از آن‌ها در اعمال نهایی (commit) تغییرات خود ناموفق بود. دلیل شکست در پیام ذکر شده است.
DHCP4_PARSER_EXCEPTION
0.0
3.5
failed to create or run parser for configuration element %1
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی، کارساز DHCPv4 در ایجاد یک تجزیه‌کننده برای رمزگشایی محتوای عنصر پیکربندی نام‌برده‌شده ناموفق بود، یا ایجاد آن موفقیت‌آمیز بوده اما عملیات تجزیه و اعمال تغییرات با شکست مواجه شده است. این پیام در پاسخ به رخ دادن یک استثنای خارج از چارچوب Kea در خروجی ثبت شده است. پیام‌های تکمیلی ممکن است اطلاعات بیشتری ارائه دهند.
DHCP4_PARSER_FAIL
0.0
3.5
failed to create or run parser for configuration element %1: %2
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی، کارساز DHCPv4 در ایجاد یک تجزیه‌کننده برای رمزگشایی محتوای عنصر پیکربندی نام‌برده‌شده ناموفق بود، یا ایجاد آن با موفقیت انجام شد اما عملیات تجزیه و اعمال تغییرات با شکست مواجه گردید. دلیل شکست در پیام ذکر شده است.
DHCP4_POST_ALLOCATION_NAME_UPDATE_FAIL
0.0
3.5
%1: failed to update hostname %2 in a lease after address allocation: %3
168u
168u
این پیام نشان‌دهنده شکست در تلاش برای به‌روزرسانی اجاره (lease) و/یا گزینه‌ها در پاسخ کارساز با hostname تولیدشده توسط کارساز، یا رزروشده برای کلاینت متعلق به یک شبکه مشترک (shared network) است. مورد دوم زمانی رخ می‌دهد که کارساز به‌طور پویا از همان شبکه مشترک به زیرشبکه دیگری (به غیر از موردی که ابتدا برای تخصیص انتخاب شده بود) جابه‌جا شود.
DHCP4_QUERY_DATA
0.0
3.5
%1, packet details: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
پیامی اشکال‌زدایی که جزئیات بسته دریافتی را چاپ می‌کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. فیلدهای بسته شامل ciaddr، yiaddr، siaddr، giaddr، sname و file در صورت خالی نبودن گنجانده خواهند شد..SS DHCP4_QUERY_LABEL
0.0
3.5
received query: %1
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک پرس‌وجو دریافت شده است. این پیام اطلاعات شناسایی کلاینت و تراکنش را نمایش می‌دهد.
DHCP4_RECLAIM_EXPIRED_LEASES_FAIL
0.0
3.5
failed to reclaim expired leases: %1
168u
168u
این پیام خطا نشان می‌دهد که عملیات بازپس‌گیری اجاره‌های منقضی‌شده با شکست مواجه شده است و علت خطا را مشخص می‌کند.
DHCP4_RECLAIM_EXPIRED_LEASES_SKIPPED
0.0
3.5
dhcp6 service is currently disabled. Try again in %1 seconds.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که زمان‌بندی بازپس‌گیری اجاره‌ها فرارسیده باشد، اما به دلیل غیرفعال بودن سرویس DHCPv6 نادیده گرفته شده باشد. زمان‌بندی بازپس‌گیری طبق مقدار پیکربندی‌شده در reclaim-timer-wait-time ادامه خواهد یافت.
DHCP4_RECOVERED_STASHED_RELAY_AGENT_INFO
0.0
3.5
recovered for query %1 relay agent option from lease %2: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که گزینه‌های agent در اجاره برای نشانی کلاینتِ درخواست‌کننده ذخیره شده بودند و اکنون بازیابی شده‌اند. آرگومان اول شامل اطلاعات درخواست، آرگومان دوم نشانی کلاینت و آرگومان آخر محتوای گزینه dhcp-agent-options است.
DHCP4_RELEASE
0.0
3.5
%1: address %2 was released properly.
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اطلاع‌رسانی نشان می‌دهد که یک نشانی به‌درستی آزاد شده است. این یک فرایند عادی هنگام خاموش شدن کلاینت است. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش، و آرگومان دوم شامل نشانی IPv4 آزادشده است.
DHCP4_RELEASE_DELETED
0.0
3.5
%1: address %2 was deleted on release.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک نشانی هنگام آزادسازی حذف شده است. این یک فرایند عادی در زمان خاموش شدن کلاینت است. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش، و آرگومان دوم شامل نشانی IPv4 آزادشده است.
DHCP4_RELEASE_EXCEPTION
0.0
3.5
%1: while trying to release address %2 an exception occurred: %3
168u
168u
این پیام زمانی صادر می‌شود که هنگام تلاش برای پردازش پیام DHCPRELEASE خطایی رخ داده باشد. این خطا تأثیری بر کلاینت نخواهد داشت، چرا که کلاینت برای پیام‌های DHCPRELEASE منتظر دریافت هیچ پاسخی از سوی سرور نمی‌ماند. بسته به ماهیت مشکل، ممکن است بر عملکرد آینده سرور اثر بگذارد. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم شامل نشانی IPv4 است که آزادسازی آن با شکست روبه‌رو شد و آخرین آرگومان حاوی توضیحات تفصیلی خطا است.
DHCP4_RELEASE_EXPIRED
0.0
3.5
%1: address %2 expired on release.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک نشانی هنگام آزادسازی منقضی شده است. این یک فرایند عادی در زمان خاموش شدن کلاینت است. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش، و آرگومان دوم شامل نشانی IPv4 آزادشده است.
DHCP4_RELEASE_FAIL
0.0
3.5
%1: failed to remove lease for address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام خطا بیانگر آن است که نرم‌افزار نتوانسته است یک اجاره را از پایگاه‌داده اجاره‌ها حذف کند. این مشکل احتمالاً به دلیل بروز خطا در حین انجام عملیات روی پایگاه‌داده است؛ رفع آن به احتمال زیاد نیاز به مداخله مدیر سیستم دارد (برای مثال، بررسی اینکه آیا فرایند DHCP مجوزهای کافی برای به‌روزرسانی پایگاه‌داده را داراست یا خیر). این پیام همچنین ممکن است در صورتی رخ دهد که در حین پردازش پیام RELEASE، اجاره به‌صورت دستی از پایگاه‌داده حذف شده باشد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم نیز نشانی IPv4 مورد نظر برای آزادسازی را در بر دارد..SS DHCP4_RELEASE_FAIL_NO_LEASE
0.0
3.5
%1: client is trying to release non-existing lease %2
168u
168u
در سطح لاگ‌گیری اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که کلاینت تلاش می‌کند یک اجاره (lease) را آزاد کند،
اما چنین اجاره‌ای برای سرور شناخته‌شده نیست. آرگومان نخست حاوی اطلاعات
شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4 است که کلاینت
سعی در آزادسازی آن دارد.
DHCP4_RELEASE_FAIL_WRONG_CLIENT
0.0
3.5
%1: client is trying to release the lease %2 which belongs to a different client
168u
168u
در سطح لاگ‌گیری اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کلاینت در تلاش برای آزادسازی اجاره
آدرسی است که در حال حاضر توسط کلاینت دیگری استفاده می‌شود؛ یعنی مقادیر
'client identifier' یا 'chaddr' بین کلاینت و اجاره همخوانی ندارند.
آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم
آدرس اجاره‌شده را مشخص می‌کند.
DHCP4_REQUEST
0.0
3.5
%1: server is processing DHCPREQUEST with hint=%2
168u
168u
در سطح لاگ‌گیری اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان‌دهنده پردازش یک پیام دریافتی DHCPREQUEST است.
آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم ممکن است
حاوی سرنخی (hint) برای سرور درباره آدرسی باشد که کلاینت تمایل به تخصیص آن دارد.
اگر سرنخی وجود نداشته باشد، این آرگومان متنی را ارائه می‌دهد که نشان می‌دهد
سرنخی ارسال نشده است.
DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED
0.0
3.5
Multi-threading is enabled and host reservations lookup is always performed first.
168u
168u
این پیامی است که اطلاع می‌دهد با فعال بودن چندرشتگی (multi-threading)، جستجوی
رزروهای میزبان (host reservations) همیشه پیش از جستجوی اجاره انجام می‌شود و مقدار
پیکربندی‌شده را بازنویسی می‌کند.
DHCP4_RESERVED_HOSTNAME_ASSIGNED
0.0
3.5
%1: server assigned reserved hostname %2
168u
168u
در سطح لاگ‌گیری اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که سرور یک رزرو نام میزبان (hostname) برای
کلاینت پیدا کرده و از این رزرو در گزینه نام میزبانی که به این کلاینت بازمی‌گرداند
استفاده می‌کند. در صورت تعیین پارامتر 'ddns-qualifying-suffix'، نام میزبان
رزروشده با مقدار این پارامتر تکمیل می‌شود.
DHCP4_RESPONSE_DATA
0.0
3.5
%1: responding with packet %2 (type %3), packet details: %4
168u
168u
در سطح لاگ‌گیری اشکال‌زدایی ۵۵ ثبت می‌شود.
پیام اشکال‌زدایی شامل داده‌های تفصیلی بسته‌ای است که برای کلاینت ارسال می‌شود.
آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های دوم و سوم
به ترتیب حاوی نام و نوع بسته هستند. آرگومان چهارم شامل جزئیات اطلاعات بسته است.
فیلدهای بسته شامل ciaddr، yiaddr، siaddr، giaddr، sname و file در صورت خالی نبودن
درج خواهند شد.
DHCP4_RESPONSE_FQDN_DATA
0.0
3.5
%1: including FQDN option in the server's response: %2
168u
168u
در سطح لاگ‌گیری اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که سرور در حال افزودن گزینه Client FQDN
در پاسخ خود به کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش
است. آرگومان دوم شامل جزئیات گزینه FQDN درج‌شده است. توجه داشته باشید که نام
ارائه‌شده در گزینه FQDN ممکن است در زمان دریافت اجاره برای کلاینت، توسط سرور
تغییر یابد.
DHCP4_RESPONSE_HOSTNAME_DATA
0.0
3.5
%1: including Hostname option in the server's response: %2
168u
168u
در سطح لاگ‌گیری اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که سرور در حال افزودن گزینه Hostname
در پاسخ خود به کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش
است. آرگومان دوم شامل جزئیات گزینه FQDN گنجانده‌شده است. توجه داشته باشید که
نام ارائه‌شده در گزینه Hostname ممکن است هنگام دریافت اجاره برای کلاینت، توسط
سرور تغییر یابد..SS DHCP4_RESPONSE_HOSTNAME_GENERATE
0.0
3.5
%1: server has generated hostname %2 for the client
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی شامل نام میزبان (hostname) خودکار تولید‌شده‌ای است که برای
کلاینتی که پیام آن در حال پردازش است استفاده خواهد شد. نام‌های میزبان ممکن است در مواردی
نیاز به تولید داشته باشند که در پیکربندی کارساز الزامی شده باشد، یا زمانی که کلاینت
نام میزبان خود را ارائه نکرده باشد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و
تراکنش است. آرگومان دوم نام میزبان تولید‌شده را در بر دارد.
DHCP4_ROOT_USER_SECURITY_WARNING
0.0
3.5
kea-dhcp4 running as root user!
168u
168u
این هشدار زمانی صادر می‌شود که kea-dhcp4 به عنوان کاربر ریشه (root) در حال اجرا باشد.
اگرچه کارساز به‌طور کامل به کار خود ادامه می‌دهد، اما این شیوهٔ اجرا ممکن است
محیط شما را در معرض آسیب‌پذیری‌های امنیتی قرار دهد و تنها پس از بررسی دقیق
باید استفاده شود.
DHCP4_SECURITY_CHECKS_DISABLED
0.0
3.5
Invoked with command line option -X, Security checks are disabled!!
168u
168u
این هشدار زمانی صادر می‌شود که بررسی‌های امنیتی داخلی که معمولاً توسط
kea-dhcp4 انجام می‌شوند، از طریق گزینهٔ خط فرمان '-X' غیرفعال شده باشند.
این بدان معناست که کارساز محدودیت‌های مربوط به مسیرهای منابع یا مجوزهای
دسترسی را اعمال نمی‌کند. این شیوهٔ اجرا ممکن است محیط شما را در معرض
آسیب‌پذیری‌های امنیتی قرار دهد و تنها پس از بررسی دقیق باید استفاده شود.
DHCP4_SERVER_FAILED
0.0
3.5
server failed: %1
168u
168u
کارساز DHCPv4 با یک خطای مهلک مواجه شده و در حال خاتمه است.
علت این شکست در پیام گنجانده شده است.
DHCP4_SERVER_INITIATED_DECLINE
0.0
3.5
%1: Lease for addr %2 has been found to be already in use. The lease will be unavailable for %3 seconds.
168u
168u
این پیام اطلاعاتی هنگامی چاپ می‌شود که کارساز از طریق ICMP ECHO (به‌عنوان مثال بررسی ping)
یا راه‌های دیگر تشخیص دهد اجاره‌ای (lease) که باید برای ارائه آزاد باشد، در عمل در حال
استفاده است. این پیام ممکن است نشان‌دهندهٔ پیکربندی نادرست در شبکه یا به احتمال بیشتر دستگاهی
باشد که از نشانی‌ای استفاده می‌کند که مجاز به استفاده از آن نیست. کارساز به‌طور کامل از این
وضعیت بازیابی خواهد شد، اما اگر مشکل اصلی یعنی پیکربندی نادرست یا وجود دستگاه سرکش (rogue)
حل نشود، ممکن است این نشانی در آینده دوباره رد (decline) شود.
DHCP4_SERVER_INITIATED_DECLINE_ADD_FAILED
0.0
3.5
%1: error adding a lease for address %2
168u
168u
این پیام خطا نشان می‌دهد که کارساز نتوانسته است یک اجارهٔ ردشده (DECLINED) را به
مخزن اجاره‌ها اضافه کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است.
آرگومان دوم نشانی IPv4 مربوطه را که رد کردن برای آن انجام شده است، نگهداری می‌کند.
DHCP4_SERVER_INITIATED_DECLINE_RESOURCE_BUSY
0.0
3.5
%1: error declining a lease for address %2
168u
168u
این پیام خطا نشان می‌دهد در حالی که یک ریسهٔ (thread) کارساز در تلاش برای نشانه‌گذاری
یک اجاره به‌عنوان DECLINED بود، این اجاره قبلاً توسط ریسهٔ دیگری قفل شده است. آرگومان
نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم نشانی IPv4 مربوطه را
که رد کردن برای آن انجام شده است، نگهداری می‌کند.
DHCP4_SERVER_INITIATED_DECLINE_UPDATE_FAILED
0.0
3.5
%1: error updating lease for address %2
168u
168u
این پیام خطا نشان می‌دهد که کارساز نتوانسته است وضعیت یک اجاره را در مخزن
اجاره‌ها به DECLINED به‌روزرسانی کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت
و تراکنش است. آرگومان دوم نشانی IPv4 مربوطه را که رد کردن برای آن انجام شده است،
نگهداری می‌کند.
DHCP4_SHUTDOWN
0.0
3.5
server shutdown
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کارساز DHCPv4 به‌طور عادی خاتمه یافته است..SS DHCP4_SHUTDOWN_REQUEST
0.0
3.5
shutdown of server requested
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که خاموش‌شدن کارساز DHCPv4 از طریق فراخوانی متد 'shutdown' در شیء اصلی Dhcpv4Srv درخواست شده است.
DHCP4_SRV_CONSTRUCT_ERROR
0.0
3.5
error creating Dhcpv4Srv object, reason: %1
168u
168u
این پیام خطا نشان می‌دهد که در حین راه‌اندازی، ساخت یکی از مؤلفه‌های اصلی درون کارساز DHCPv4 (شیء کارساز Dhcpv4) با شکست مواجه شده است. در نتیجه، کارساز خارج خواهد شد. علت شکست در متن پیام ذکر شده است.
DHCP4_SRV_D2STOP_ERROR
0.0
3.5
error stopping IO with DHCP_DDNS during shutdown: %1
168u
168u
این پیام خطا نشان می‌دهد که در حین خاموش‌شدن، هنگام توقف ورودی/خروجی (IO) بین کارساز DHCPv4 و کارساز DHCP_DDNS خطایی رخ داده است. این مشکل احتمالاً به دلیل یک خطای برنامه‌نویسی است و بعید است پس از راه‌اندازی مجدد، بر هیچ‌یک از کارسازها تأثیر بگذارد. علت شکست در متن پیام ذکر شده است.
DHCP4_SRV_DHCP4O6_ERROR
0.0
3.5
error stopping IO with DHCPv4o6 during shutdown: %1
168u
168u
این پیام خطا نشان می‌دهد که در حین خاموش‌شدن، هنگام توقف ورودی/خروجی (IO) بین کارساز DHCPv4 و کارساز DHCPv4o6 خطایی رخ داده است. این مشکل احتمالاً به دلیل یک خطای برنامه‌نویسی است و بعید است پس از راه‌اندازی مجدد، بر هیچ‌یک از کارسازها تأثیر بگذارد. علت شکست در متن پیام ذکر شده است.
DHCP4_SRV_UNLOAD_LIBRARIES_ERROR
0.0
3.5
error unloading hooks libraries during shutdown: %1
168u
168u
این پیام خطا نشان می‌دهد که در حین خاموش‌شدن، تخلیهٔ (unload) کتابخانه‌های قلاب‌ها (hooks libraries) در بستن آن‌ها با شکست مواجه شده است. اگر فهرست کتابخانه‌ها خالی باشد، این یک خطای برنامه‌نویسی در کد کارساز است. اگر خالی نباشد، می‌تواند ناشی از یک خطای برنامه‌نویسی در یکی از کتابخانه‌های قلاب باشد که ممکن است به فروپاشی (crash) در طول نهایی‌سازی بینجامد.
DHCP4_STARTED
0.0
3.5
Kea DHCPv4 server version %1 started
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کارساز DHCPv4 تمامی اطلاعات پیکربندی را پردازش کرده و آمادهٔ پردازش بسته‌های DHCPv4 است. نگارش کارساز نیز چاپ می‌شود.
DHCP4_STARTING
0.0
3.5
Kea DHCPv4 server version %1 (%2) starting
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کارساز DHCPv4 گزینه‌های خط فرمان را پردازش کرده و در حال راه‌اندازی است. نگارش کارساز نیز چاپ می‌شود.
DHCP4_START_INFO
0.0
3.5
pid: %1, server port: %2, client port: %3, verbose: %4
168u
168u
در سطح گزارش اشکال‌زدایی 0 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که در حین راه‌اندازی کارساز DHCPv4 صادر می‌شود. این پیام اطلاعاتی را دربارهٔ پارامترهایی که کارساز با آن‌ها در حال اجرا است فهرست می‌کند.
DHCP4_SUBNET_DATA
0.0
3.5
%1: the selected subnet details: %2
168u
168u
در سطح گزارش اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات زیرشبکهٔ انتخاب‌شده برای کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم شامل جزئیات زیرشبکه است..SS DHCP4_SUBNET_DYNAMICALLY_CHANGED
0.0
3.5
%1: changed selected subnet %2 to subnet %3 from shared network %4 for client assignments
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که کارگزار برای تخصیص‌های کلاینت از زیرشبکه
دیگری به غیر از زیرشبکه اولیه استفاده می‌کند. این زیرشبکه تازه انتخاب‌شده
متعلق به همان شبکه مشترک (shared network) زیرشبکه اصلی است.
برخی از دلایل انتخاب زیرشبکه جدید عبارتند از: اتمام استخر آدرس
در زیرشبکه اصلی یا وجود رزروهای ایستا برای این کلاینت در زیرشبکه جدید.
DHCP4_SUBNET_SELECTED
0.0
3.5
%1: the subnet with ID %2 was selected for client assignments
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که به انتخاب یک زیرشبکه جهت استفاده برای
تخصیص آدرس و گزینه‌ها اشاره می‌کند. انتخاب زیرشبکه یکی از گام‌های
اولیه در پردازش پیام دریافتی کلاینت است. آرگومان اول شامل اطلاعات
شناسایی کلاینت و تراکنش است. آرگومان دوم شناسه زیرشبکه انتخاب‌شده را نگه می‌دارد.
DHCP4_SUBNET_SELECTION_FAILED
0.0
3.5
%1: failed to select subnet for the client
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که کارگزار در انتخاب زیرشبکه برای کلاینتی
که پیامی به کارگزار فرستاده، ناموفق بوده است. کارگزار قادر به ارائه هیچ
اجاره‌ای به کلاینت نخواهد بود؛ در صورتی که پیام دریافتی DHCPDISCOVER باشد
آن را دور می‌اندازد (drop می‌کند)، و اگر پیام دریافتی DHCPREQUEST باشد
یک پیام DHCPNAK ارسال خواهد کرد. آرگومان شامل اطلاعات شناسایی
کلاینت و تراکنش است.
DHCP4_TESTING_MODE_SEND_TO_SOURCE_ENABLED
0.0
3.5
All packets will be sent to the source address of an incoming packet - use only for testing
168u
168u
این پیام زمانی چاپ می‌شود که متغیر محیطی KEA_TEST_SEND_RESPONSES_TO_SOURCE
تنظیم شده باشد. این متغیر باعث می‌شود Kea بسته‌ها را به آدرس مبدا بسته
دریافتی ارسال کند. این ویژگی تنها در یک محیط آزمایشی برای شبیه‌سازی ترافیک
چندین زیرشبکه از یک مبدا واحد قابل استفاده است.
DHCP4_UNKNOWN_ADDRESS_REQUESTED
0.0
3.5
%1: client requested an unknown address, client sent ciaddr %2, requested-ip-address %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که کلاینت آدرسی را درخواست کرده است که به هیچ‌کدام
از استخرهای پویای مدیریت‌شده توسط این کارگزار تعلق ندارد. آرگومان اول
حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرس IPv4
در فیلد ciaddr است. آرگومان سوم حاوی آدرس IPv4 در گزینه
requested-ip-address است (در صورت وجود).
DHCP4_V6_ONLY_PREFERRED_MISSING_IN_ACK
0.0
3.5
v6-only-preferred option missing in 0.0.0.0 reply to query: %1
168u
168u
یک پیام DHCPACK برای آدرس 0.0.0.0 برای کلاینتی که گزینه v6-only-preferred (108)
را درخواست کرده بود تولید شد، اما این گزینه بر خلاف انتظار در پاسخ وجود ندارد:
پاسخ نادرست دور ریخته شده و پرس‌وجوی درخواست (request) نمایش داده می‌شود.
DHCP4_V6_ONLY_PREFERRED_MISSING_IN_OFFER
0.0
3.5
v6-only-preferred option missing in 0.0.0.0 offer to query: %1
168u
168u
یک پیام DHCPOFFER برای آدرس 0.0.0.0 برای کلاینتی که گزینه v6-only-preferred (108)
را درخواست کرده بود تولید شد، اما این گزینه بر خلاف انتظار در پاسخ وجود ندارد:
پاسخ نادرست دور ریخته شده و پرس‌وجوی کشف (discover) نمایش داده می‌شود.
DHCP6
DHCP6_ADDITIONAL_CLASS_EVAL_ERROR
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
این پیام خطا نشان می‌دهد که هنگام ارزیابی عبارت مربوط به یک کلاس
کلاینت اضافی مشکلی رخ داده است.
شرحی از مشکل چاپ می‌شود..SS DHCP6_ADDITIONAL_CLASS_EVAL_RESULT
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت یک کلاس کلاینت اضافی با موفقیت ارزیابی شده است. نام کلاس کلاینت و مقدار نتیجهٔ ارزیابی چاپ می‌شوند.
DHCP6_ADDITIONAL_CLASS_NO_TEST
0.0
3.5
additional class %1 has no test expression, adding it to client's classes unconditionally
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که یک کلاس برای ارزیابی بیشتر فهرست شده است اما تعریف آن شامل هیچ عبارت آزمایشی برای ارزیابی نیست. این کلاس بدون قید و شرط به پرسمان اضافه می‌شود.
DHCP6_ADDITIONAL_CLASS_UNDEFINED
0.0
3.5
additional class %1 has no definition
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که یک کلاس برای ارزیابی بیشتر فهرست شده اما تعریفی ندارد. از این کلاس صرف‌نظر می‌شود.
DHCP6_ADDR6_REGISTER_DISABLED_DROP
0.0
3.5
ADDR-REG-INFORM from %1 was dropped because address registration is disabled.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که کارگزار یک بستهٔ ADDR-REG-INFORM را نادیده گرفته و دور می‌اندازد، زیرا 'allow-address-registration' روی false تنظیم شده است.
DHCP6_ADDR_REG_INFORM_CLIENT_CHANGE
0.0
3.5
received an ADDR-REG-INFORM for %1 from client '%2' but the address was registered by another client '%3'
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که از قبل یک اجاره (lease) متعلق به کلاینتی دیگر برای نشانیِ در حال ثبت وجود داشته باشد. نشانی، شناسهٔ کلاینت جدید و کلاینت پیشین چاپ می‌شوند.
DHCP6_ADDR_REG_INFORM_FAIL
0.0
3.5
error on ADDR-REG-INFORM from client %1, %2
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که پردازش پیام ADDR-REG-INFORM با شکست مواجه شده باشد. نشانی کلاینت (که معمولاً همان نشانی برای ثبت است) و شرح مشکل چاپ می‌شوند.
DHCP6_ADD_DEPRECATED_UNICAST
0.0
3.5
%1: adding deprecated unicast option
168u
168u
این هشدار زمانی ثبت می‌شود که گزینهٔ منسوخ‌شدهٔ unicast به پاسخ افزوده شود. به جز برای مقاصد آزمایشی، پیکربندی کارگزار باید اصلاح شود زیرا پرسمان‌های مستقیم unicast دیگر پذیرفته نمی‌شوند.
DHCP6_ADD_GLOBAL_STATUS_CODE
0.0
3.5
%1: adding Status Code to DHCPv6 packet: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که کارگزار در حال افزودن گزینهٔ سطح بالای Status Code است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم جزئیات کد وضعیت را در بر دارد.
DHCP6_ADD_STATUS_CODE_FOR_IA
0.0
3.5
%1: adding Status Code to IA with iaid=%2: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که کارگزار در حال افزودن گزینهٔ Status Code به یک IA است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم IAID را مشخص می‌کند. آرگومان سوم شامل جزئیات کد وضعیت است..SS DHCP6_ALREADY_RUNNING
0.0
3.5
%1 already running? %2
168u
168u
این یک پیام خطا است و زمانی رخ می‌دهد که کارساز DHCPv6 با یک فایل PID از پیش موجود که حاوی PID یک فرایند در حال اجراست مواجه می‌شود.
این امر به احتمال زیاد نشان‌دهندهٔ تلاش برای اجرای نمونهٔ دومی از کارساز با استفاده از همان فایل پیکربندی است. همچنین این احتمال، هرچند اندک، وجود دارد که فایل PID باقی‌مانده‌ای از فروپاشی (crash) کارساز یا قطعی برق باشد و شناسهٔ PID درون آن به فرایندی غیر از کارساز اشاره کند. در چنین شرایطی، لازم است فایل PID به‌صورت دستی حذف شود. آرگومان نخست نام فرایند DHCPv6 است و آرگومان دوم حاوی PID و فایل PID است.
DHCP6_BUFFER_RECEIVED
0.0
3.5
received buffer from %1:%2 to %3:%4 over interface %5
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که کارساز بسته‌ای را روی سوکت دریافت کرده باشد. هنگام ثبت این پیام، محتوای بستهٔ دریافتی هنوز تجزیه نشده است. تنها اطلاعات موجود، رابط شبکه و نشانی‌ها/درگاه‌های مبدأ و مقصد هستند.
DHCP6_BUFFER_UNPACK
0.0
3.5
parsing buffer received from %1 to %2 over interface %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز شروع به تجزیهٔ بافر دریافتی حاوی پیام DHCPv6 می‌کند. آرگومان‌ها نشانی‌های مبدأ و مقصد و همچنین رابط شبکه‌ای را که بافر از طریق آن دریافت شده است مشخص می‌کنند.
DHCP6_BUFFER_WAIT_SIGNAL
0.0
3.5
signal received while waiting for next packet
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در انتظار بسته بوده است، اما این انتظار به دلیل سیگنال دریافت شده توسط فرایند دچار وقفه شده است. پیش از آن‌که کارساز انتظار برای بسته‌های بعدی را آغاز کند، به این سیگنال رسیدگی خواهد شد.
DHCP6_CB_ON_DEMAND_FETCH_UPDATES_FAIL
0.0
3.5
error on demand attempt to fetch configuration updates from the configuration backend(s): %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کارساز برای واکشی به‌روزرسانی‌های پیکربندی از پایگاه‌داده تلاش کرده و این تلاش درخواستی (on demand) با شکست مواجه شده است. تنها آرگومان موجود، که به فراخوانندهٔ دستور config-backend-pull نیز برگردانده می‌شود، شامل علت شکست است.
DHCP6_CB_PERIODIC_FETCH_UPDATES_FAIL
0.0
3.5
error on periodic attempt to fetch configuration updates from the configuration backend(s): %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کارساز برای واکشی به‌روزرسانی‌های پیکربندی از پایگاه‌داده تلاش کرده و این تلاش دوره‌ای با شکست مواجه شده است. کارساز با توجه به مقدار پیکربندی‌شده در پارامتر config-fetch-wait-time مجدداً تلاش خواهد کرد. تنها آرگومان موجود حاوی علت شکست است.
DHCP6_CB_PERIODIC_FETCH_UPDATES_RETRIES_EXHAUSTED
0.0
3.5
maximum number of configuration fetch attempts: 10, has been exhausted without success
168u
168u
این خطا نشان‌دهندهٔ آن است که کارساز چندین تلاش ناموفق دوره‌ای برای واکشی به‌روزرسانی‌های پیکربندی از پسانهٔ (backend) پیکربندی انجام داده است. کارساز به فعالیت خود ادامه خواهد داد، اما تلاش دیگری برای واکشی به‌روزرسانی‌های پیکربندی انجام نخواهد داد. مدیر سیستم باید پیکربندی را در پایگاه‌داده اصلاح کرده و کارساز را مجدداً بارگذاری (reload) یا بازراه‌اندازی (restart) کند.
DHCP6_CLASSES_ASSIGNED
0.0
3.5
%1: client packet has been assigned on %2 message to the following classes: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بستهٔ ورودی به کلاس‌های مشخص‌شده تخصیص داده شده است. این یک رفتار عادی بوده و نشان‌دهندهٔ عملکرد موفقیت‌آمیز است. آرگومان اول، اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم نوع پیام DHCPv6 را مشخص می‌کند. آرگومان سوم شامل تمام کلاس‌هایی است که بسته به آن‌ها تخصیص یافته است..SS DHCP6_CLASSES_ASSIGNED_AFTER_SUBNET_SELECTION
0.0
3.5
%1: client packet has been assigned to the following classes: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بستهٔ دریافتی به کلاس‌های مشخص‌شده تخصیص یافته است. این یک رفتار عادی است و نشان‌دهندهٔ عملکرد موفقیت‌آمیز می‌باشد.
آرگومان اول اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم شامل تمام کلاس‌هایی است که بسته به آن‌ها تخصیص داده شده است.
DHCP6_CLASS_ASSIGNED
0.0
3.5
%1: client packet has been assigned to the following class: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بستهٔ دریافتی به کلاس مشخص‌شده تخصیص یافته است. این یک رفتار عادی است و نشان‌دهندهٔ عملکرد موفقیت‌آمیز می‌باشد.
آرگومان اول اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان دوم شامل کلاس جدیدی است که بسته به آن تخصیص داده شده است.
DHCP6_CLASS_UNCONFIGURED
0.0
3.5
%1: client packet belongs to an unconfigured class: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی اطلاع می‌دهد که بستهٔ دریافتی متعلق به کلاسی است
که در پیکربندی یافت نمی‌شود. یا از یک hook استفاده شده است که
قبل از افزوده شدن دسته‌بندی به Kea نوشته شده بود، یا نام‌گذاری کلاس‌ها
ناسازگار است.
DHCP6_CLIENT_FQDN_SCRUBBED_EMPTY
0.0
3.5
%1: sanitizing client's FQDN option '%2' yielded an empty string
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که نتیجهٔ پاک‌سازی (sanitizing)
گزینهٔ FQDN (39) ارسال‌شده توسط کلاینت، یک رشتهٔ خالی باشد. در صورت بروز این حالت،
سرور از گزینهٔ FQDN صرف‌نظر خواهد کرد. آرگومان‌ها شامل کلاینت
و گزینهٔ FQDN ارسال‌شده توسط آن هستند.
DHCP6_CONFIG_COMPLETE
0.0
3.5
DHCPv6 server has completed configuration: %1
168u
168u
این یک پیام اطلاع‌رسانی است که پردازش موفقیت‌آمیز یک پیکربندی جدید را
اعلان می‌کند. این پیام در زمان راه‌اندازی سرور و هنگامی که یک پیکربندی
به‌روزشده توسط مدیر سیستم اعمال می‌شود، در خروجی ثبت می‌گردد. ممکن است
اطلاعات تکمیلی نیز ارائه شود.
DHCP6_CONFIG_LOAD_FAIL
0.0
3.5
configuration error using file: %1, reason: %2
168u
168u
این پیام خطا نشان می‌دهد که پیکربندی DHCPv6 با شکست مواجه شده است.
اگر این یک پیکربندی اولیه باشد (در حین راه‌اندازی سرور)، سرور در شروع به‌کار
ناموفق خواهد بود. اگر این تلاشی برای پیکربندی مجدد پویا باشد، سرور
به استفاده از پیکربندی قدیمی ادامه خواهد داد.
DHCP6_CONFIG_PACKET_QUEUE
0.0
3.5
DHCPv6 packet queue info after configuration: %1
168u
168u
این پیام اطلاع‌رسانی در حین پیکربندی سرور DHCPv6، بلافاصله پس از
پیکربندی صف بسته‌های DHCPv6 صادر می‌شود. اطلاعات نمایش‌داده‌شده به
نوع صف بستهٔ انتخاب‌شده بستگی دارد.
DHCP6_CONFIG_RECEIVED
0.0
3.5
received configuration: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۰ ثبت می‌شود.
پیامی اشکال‌زدایی که پیکربندی دریافت‌شده توسط سرور DHCPv6 را فهرست می‌کند.
منبع آن پیکربندی به backend پیکربندیِ مورداستفاده بستگی دارد.
DHCP6_CONFIG_START
0.0
3.5
DHCPv6 server is processing the following configuration: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هر بار با دریافت یک پیکربندی توسط سرور
صادر می‌شود. این حالت هنگام راه‌اندازی و همچنین زمانی که تغییر پیکربندی
سرور توسط مدیر سیستم اعمال می‌شود، رخ می‌دهد..SS DHCP6_CONFIG_SYNTAX_WARNING
0.0
3.5
configuration syntax warning: %1
168u
168u
این پیام هشدار نشان می‌دهد که پیکربندی DHCPv6 دارای یک خطای نحوی جزئی بوده است. خطا نمایش داده شد و تجزیهٔ پیکربندی ادامه یافت.
DHCP6_CONFIG_UNRECOVERABLE_ERROR
0.0
3.5
DHCPv6 server new configuration failed with an error which cannot be recovered
168u
168u
این پیام خطای مهلک زمانی صادر می‌شود که پیکربندی جدید با خطایی مواجه شده که قابل بازیابی نیست. از آن‌جا که کارساز دیگر کار نمی‌کند، باید در سریع‌ترین زمان ممکن یک پیکربندی صحیح اعمال شود.
پیکربندی را می‌توان به چندین روش اصلاح کرد. اگر کانال کنترل باز باشد، می‌توان از config-set با یک پیکربندی معتبر استفاده کرد. به عنوان روش دیگر، فایل پیکربندی اصلی روی دیسک می‌تواند اصلاح شده و سیگنال SIGHUP ارسال شود (یا دستور config-reload صادر گردد). در نهایت، کارساز می‌تواند به طور کامل بازراه‌اندازی شود.
DHCP6_CONFIG_UNSUPPORTED_OBJECT
0.0
3.5
DHCPv6 server configuration includes an unsupported object: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که پیکربندی شامل یک شیء پشتیبانی‌نشده (یعنی یک عنصر سطح بالا) باشد.
DHCP6_DATA_DIRECTORY_DEPRECATED
0.0
3.5
'data-directory' has been deprecated and should no longer be used.
168u
168u
این پیام هشدار زمانی صادر می‌شود که تجزیهٔ پیکربندی تشخیص دهد پارامتر data-directory مشخص شده است. این پارامتر دیگر پشتیبانی نمی‌شود. این مسیر پشتیبانی‌شده که در زمان کامپایل تعیین می‌شود، می‌تواند در زمان اجرا با تنظیم متغیر محیطی 'KEA_DHCP_DATA_DIR' بازنویسی شود.
DHCP6_DB_RECONNECT_DISABLED
0.0
3.5
database reconnect is disabled: retries left: %1, reconnect wait time: %2, manager ID: %3, timer: %4
168u
168u
این یک پیام اطلاعاتی است که نشان می‌دهد ارتباط با پایگاه‌دادهٔ اجاره (lease) یا میزبان یا هر دو قطع شده و اتصال مجدد خودکار فعال نیست.
DHCP6_DB_RECONNECT_FAILED
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success, manager ID: %2, timer: %3
168u
168u
این خطا نشان می‌دهد که کارساز پس از انجام حداکثر دفعات تلاش پیکربندی‌شده، در اتصال مجدد به پایگاه(های) دادهٔ اجاره و/یا میزبان ناموفق بوده است. این امر ممکن است طبق آنچه در پیکربندی مشخص شده، باعث متوقف شدن کارساز شود. قطع ارتباط معمولاً یک مشکل شبکه یا کارساز پایگاه‌داده است.
DHCP6_DB_RECONNECT_LOST_CONNECTION
0.0
3.5
database connection lost: manager ID: %1, timer: %2.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که اتصال قطع شده است و سرویس dhcp ممکن است، همان‌طور که در پیکربندی مشخص شده، برای تلاش جهت بازیابی اتصال غیرفعال شده باشد.
DHCP6_DB_RECONNECT_NO_DB_CTL
0.0
3.5
unexpected error in database reconnect
168u
168u
این یک پیام خطا است که بیانگر یک خطای برنامه‌نویسی بوده که نباید رخ دهد. این خطا مانع از تلاش کارساز برای اتصال مجدد به پایگاه‌های داده‌اش در صورت قطع اتصال می‌شود و کارساز خارج می‌گردد. این خطا باید گزارش شود.
DHCP6_DB_RECONNECT_SUCCEEDED
0.0
3.5
database connection recovered: manager ID: %1, timer: %2.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که اتصال بازیابی شده و سرویس dhcp به حالت عادی بازگردانده شده است..SS DHCP6_DDNS_CREATE_ADD_NAME_CHANGE_REQUEST
0.0
3.5
%1: created name change request: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که NameChangeRequest جدیدی برای انجام
به‌روزرسانی DNS (جهت افزودن RRهای جدید) ایجاد شده باشد.
DHCP6_DDNS_FQDN_GENERATED
0.0
3.5
%1: generated FQDN for the client: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی ثبت می‌شود که کارساز یک FQDN (نام) را برای
کارخواهی که پیامش در حال پردازش است، تولید کرده باشد. این نام‌ها ممکن
است بنا به خط‌مشی کارساز یا در صورتی که کارخواه هیچ FQDN مشخصی در پیام
ارسالی خود ارائه نداده باشد، توسط کارساز تولید شوند. آرگومان نخست شامل
اطلاعات شناسایی کارخواه و تراکنش است. آرگومان دوم شامل FQDN تولیدشده
می‌باشد.
DHCP6_DDNS_GENERATED_FQDN_UPDATE_FAIL
0.0
3.5
%1: failed to update the lease using address %2, after generating FQDN for a client, reason: %3
168u
168u
این پیام بیانگر شکست در هنگام تلاش برای به‌روزرسانی اجاره‌نامه یا گزینه‌ها
در پاسخ کارساز با استفاده از نام میزبانی است که کارساز از روی نشانی اختصاص‌یافته
تولید کرده است. آرگومان نخست شامل اطلاعات شناسایی کارخواه و تراکنش است.
آرگومان دوم نشانی اجاره‌داده‌شده است. آرگومان سوم دلیل این شکست را نشان می‌دهد.
DHCP6_DDNS_GENERATE_FQDN
0.0
3.5
%1: client did not send a FQDN option; FQDN will be
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
برای کارخواه تولید خواهد شد.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز گزینهٔ FQDN را از کارخواه
دریافت نکرده باشد و جایگزینی نام کارخواه فعال باشد. این سازوکار امکانی را
برای ایجاد مدخل‌های DNS برای کارخواه‌های ساده فراهم می‌آورد.
DHCP6_DDNS_RECEIVE_FQDN
0.0
3.5
%1: received DHCPv6 Client FQDN option: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که کارساز گزینهٔ DHCPv6 Client FQDN
ارسال‌شده توسط کارخواه را پیدا کرده و پردازش آن را آغاز نموده باشد. آرگومان
نخست شامل اطلاعات شناسایی کارخواه و تراکنش است. آرگومان دوم شامل FQDN
دریافت‌شده می‌باشد.
DHCP6_DDNS_REMOVE_OLD_LEASE_FQDN
0.0
3.5
%1: FQDN for a lease: %2 has changed. New values: hostname = %3, reverse mapping = %4, forward mapping = %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی در طول تمدید اجاره‌نامه زمانی ثبت می‌شود که اجاره‌نامهٔ
قدیمی که دیگر ارائه نمی‌شود، FQDN متفاوتی نسبت به اجاره‌نامهٔ در حال تمدید
داشته باشد؛ بنابراین باید مدخل‌های قدیمی DNS حذف شوند. آرگومان نخست شامل
اطلاعات شناسایی کارخواه و تراکنش است. آرگومان دوم جزئیات اجاره‌نامه‌ای را
در بر دارد که اطلاعات FQDN یا نگاشت‌های آن تغییر یافته است. آرگومان‌های
باقی‌مانده اطلاعات جدید FQDN و پرچم‌های مربوط به نگاشت‌ها را نگه‌داری می‌کنند.
DHCP6_DDNS_REQUEST_SEND_FAILED
0.0
3.5
failed sending a request to kea-dhcp-ddns, error: %1, ncr: %2
168u
168u
این پیام خطا نشان می‌دهد که کارساز DHCP نگارش ۶ در ارسال درخواست به‌روزرسانی
DDNS به کارساز DHCP-DDNS با شکست مواجه شده است. این مورد به‌احتمال قوی
ناشی از خطای پیکربندی یا مشکلی در شبکه است.
DHCP6_DDNS_RESPONSE_FQDN_DATA
0.0
3.5
%1: including FQDN option in the server's response: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال گنجاندن گزینهٔ
Client FQDN در پاسخ خود به کارخواه است. آرگومان نخست شامل اطلاعات شناسایی
کارخواه و تراکنش است. آرگومان دوم شامل جزئیات گزینهٔ FQDN گنجانده‌شده
می‌باشد. توجه داشته باشید نامی که در گزینهٔ FQDN حمل می‌شود، ممکن است در
زمان اختصاص اجاره‌نامه به کارخواه، توسط کارساز تغییر یابد..SS DHCP6_DECLINE_FAIL
0.0
3.5
%1: error on decline lease for address %2: %3
168u
168u
این پیام خطا نشان می‌دهد که نرم‌افزار به دلیل بروز خطا در حین یک عملیات پایگاه‌داده، موفق به رد کردن (decline) یک اجاره از پایگاه‌داده اجاره‌ها نشده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم آدرس IPv6 که رد کردن آن انجام شده را نگه می‌دارد. آخرین آرگومان نیز حاوی علت شکست است.
DHCP6_DECLINE_FAIL_DUID_MISMATCH
0.0
3.5
Client %1 sent DECLINE for address %2, but it belongs to client with DUID %3
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که یک کلاینت تلاش می‌کند اجاره‌ای را رد کند، اما آن اجاره متعلق به کلاینت دیگری است. درخواست decline رد خواهد شد.
DHCP6_DECLINE_FAIL_IAID_MISMATCH
0.0
3.5
Client %1 sent DECLINE for address %2, but used a wrong IAID (%3), instead of expected %4
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که یک کلاینت تلاش می‌کند یک اجاره را رد کند. سرور اجاره‌ای برای این آدرس دارد و این اجاره به همین کلاینت تعلق دارد، اما IAID ثبت‌شده با آنچه کلاینت ارسال کرده مطابقت ندارد. این بدان معناست که سرور این Decline را رد خواهد کرد.
DHCP6_DECLINE_FAIL_LEASE_WITHOUT_DUID
0.0
3.5
Client %1 sent DECLINE for address %2, but the associated lease has no DUID
168u
168u
این وضعیت خطا احتمالاً نشان‌دهنده خرابی پایگاه‌داده است، زیرا انتظار می‌رود هر اجاره IPv6 دارای یک DUID باشد، حتی اگر خالی باشد.
DHCP6_DECLINE_FAIL_NO_LEASE
0.0
3.5
Client %1 sent DECLINE for address %2, but there's no lease for it
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که کلاینتی تلاش کرده آدرسی را رد کند، اما سرور هیچ اجاره‌ای برای آدرس مذکور ندارد. این بدان معناست که برداشت سرور و کلاینت از اجاره‌ها متفاوت است. علل محتمل این وضعیت می‌تواند این موارد باشد: یک کلاینت سردرگم (مانند ناهماهنگی یا انحراف ساعت) یا یک کلاینت معیوب (مانند جابه‌جا شدن کلاینت به مکانی دیگر بدون این‌که متوجه شود) یا احتمالاً یک حمله (یک کلاینت سرکش تلاش می‌کند آدرس‌های تصادفی را رد کند). سرور به کلاینت اطلاع خواهد داد که درخواست decline او رد شده است و کلاینت باید بتواند از این وضعیت بازیابی شود.
DHCP6_DECLINE_LEASE
0.0
3.5
Client %1 sent DECLINE for address %2 and the server marked it as declined. The lease will be recovered in %3 seconds.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کلاینت آدرسی را اجاره کرده، اما متوجه شده که توسط دستگاه دیگری در حال استفاده است و با ارسال یک پیام Decline این موضوع را به سرور گزارش داده است. سرور اجاره را به‌عنوان ردشده (declined) علامت‌گذاری کرده است. این وضعیت احتمالاً حاکی از یک پیکربندی نادرست در شبکه است؛ یا سرور با یک pool نادرست پیکربندی شده است، یا دستگاه‌هایی با آدرس‌های ایستا (statically assigned) در شبکه حضور دارند که قرار بوده توسط سرور DHCP تخصیص داده شوند. هر دوی کلاینت (یک آدرس متفاوت درخواست خواهد کرد) و سرور (پس از سپری شدن decline-probation-time اجاره را بازیابی خواهد کرد) به‌صورت خودکار بازیابی خواهند شد. با این حال، اگر ریشه اصلی مشکل برطرف نشود، شرایطی که منجر به ثبت این پیام شده ممکن است دوباره تکرار شود.
DHCP6_DECLINE_PROCESS_IA
0.0
3.5
Processing of IA (IAID: %1) from client %2 started.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که سرور شروع به پردازش یک گزینه IA_NA دریافت‌شده در پیام Decline می‌کند. انتظار می‌رود این گزینه شامل آدرسی باشد که در حال رد شدن است. اطلاعات دقیق‌تر در پیامی جداگانه چاپ خواهد شد.
DHCP6_DEVELOPMENT_VERSION
0.0
3.5
This software is a development branch of Kea. It is not recommended for production use.
168u
168u
این پیام هشدار زمانی نمایش داده می‌شود که نسخه، یک نسخه در حال توسعه (در مقایسه با پایدار) باشد: عدد دوم نسخه فرد است..SS DHCP6_DHCP4O6_PACKET_RECEIVED
0.0
3.5
received DHCPv4o6 packet from DHCPv4 server (type %1) for %2 port %3 on interface %4
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که سرور در حال دریافت یک بسته DHCPv4o6
از سرور DHCPv4 از طریق ارتباط بین‌فرایندی (inter-process communication) است.
DHCP6_DHCP4O6_RECEIVE_FAIL
0.0
3.5
failed to receive DHCPv4o6: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که ارتباط بین‌فرایندی با سرور
DHCPv4 با شکست مواجه شده است. دلیل خطا در پیام گنجانده شده است.
DHCP6_DHCP4O6_RECEIVING
0.0
3.5
receiving DHCPv4o6 packet from DHCPv4 server
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که سرور در حال دریافت یک بسته DHCPv4o6
از سرور DHCPv4 از طریق سوکت ارتباط بین‌فرایندی است.
DHCP6_DHCP4O6_RESPONSE_DATA
0.0
3.5
%1: responding with packet %2 (type %3), packet details: %4
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
یک پیام اشکال‌زدایی شامل داده‌های تفصیلی درباره بسته‌ای که به
کلاینت ارسال می‌شود. آرگومان اول شامل اطلاعات شناسایی کلاینت و
تراکنش است. آرگومان‌های دوم و سوم به ترتیب نام و نوع بسته را نشان می‌دهند.
آرگومان چهارم شامل جزئیات دقیق بسته است.
DHCP6_DHCP4O6_SEND_FAIL
0.0
3.5
%1: failed to send DHCPv4o6 packet: %2
168u
168u
این خطا در صورتی در خروجی ثبت می‌شود که سرور IPv6 DHCP در ارسال یک پیام
سرهم‌بندی‌شده‌ی DHCPv4o6 به کلاینت شکست بخورد. دلیل خطا در متن پیام
گنجانده شده است.
DHCP6_DYNAMIC_RECONFIGURATION
0.0
3.5
initiate server reconfiguration using file: %1, after receiving SIGHUP signal or config-reload command
168u
168u
این پیام اطلاع‌رسانی (info) زمانی ثبت می‌شود که سرور DHCPv6
در نتیجه دریافت سیگنال SIGHUP یا دستور config-reload، پیکربندی مجدد را آغاز کند.
DHCP6_DYNAMIC_RECONFIGURATION_FAIL
0.0
3.5
dynamic server reconfiguration failed with file: %1
168u
168u
این پیام خطای مهلک (fatal) زمانی ثبت می‌شود که پیکربندی مجدد پویای
سرور DHCP با شکست مواجه شده باشد.
DHCP6_DYNAMIC_RECONFIGURATION_SUCCESS
0.0
3.5
dynamic server reconfiguration succeeded with file: %1
168u
168u
این پیام اطلاع‌رسانی (info) زمانی ثبت می‌شود که پیکربندی مجدد پویای سرور DHCP
با موفقیت انجام شده باشد.
DHCP6_FATAL_OPEN_SOCKETS_FAILED
0.0
3.5
maximum number of open service sockets attempts: %1, has been exhausted without success
168u
168u
این خطا نشان می‌دهد که سرور پس از انجام حداکثر تعداد تلاش‌های پیکربندی‌شده،
در متصل ساختن (bind) سوکت‌های سرویس ناموفق بوده است. این امر باعث خاموش شدن سرور،
طبق آنچه در پیکربندی مشخص شده است، می‌گردد.
DHCP6_FLEX_ID
0.0
3.5
%1: flexible identifier generated for incoming packet: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که نوع رزرو میزبان (host reservation) روی
شناسه انعطاف‌پذیر (flexible identifier) تنظیم شده باشد و عبارت مشخص‌شده در
پیکربندی آن، شناسه‌ای برای بسته ورودی تولید کرده باشد (عبارت ارزیابی شده باشد).
هدف اصلی این پیام اشکال‌زدایی، کمک به خطایابی flexible identifier است..SS DHCP6_HOOK_ADDR6_REGISTER_DROP
0.0
3.5
%1: ADDR-REG-INFORM for %2 is dropped, because a callout set the next step to DROP
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که یک فراخوان (callout) نصب‌شده روی
نقطه قلاب (hook point) addr6_register، گام بعدی را روی DROP تنظیم کند. برای این
نقطه قلاب به‌خصوص، مقدار تنظیم‌شده به کارساز دستور می‌دهد تا ثبت نشانی را لغو کرده و
بسته را دور بیندازد (drop کند).
DHCP6_HOOK_ADDR6_REGISTER_SKIP
0.0
3.5
%1: lease %2 operation for %3 is skipped, because a callout set the next step to SKIP
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که یک فراخوان نصب‌شده روی
نقطه قلاب addr6_register، گام بعدی را روی SKIP تنظیم کند. برای این نقطه قلاب
به‌خصوص، مقدار تنظیم‌شده به کارساز دستور می‌دهد تا از عملیات افزودن یا به‌روزرسانی اجاره (lease)
برای نشانی ثبت‌شده صرف‌نظر کند، بنابراین وضعیت ثبت نگهداری نخواهد شد.
DHCP6_HOOK_BUFFER_RCVD_DROP
0.0
3.5
received buffer from %1 to %2 over interface %3 was dropped because a callout set the drop flag
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که یک فراخوان نصب‌شده روی نقطه قلاب
buffer6_receive پرچم drop را تنظیم کند. برای این نقطه قلاب به‌خصوص،
تنظیم این پرچم توسط یک فراخوان به کارساز دستور می‌دهد تا بسته را دور بیندازد.
آرگومان‌ها نشانی مبدأ و مقصد و همچنین نام رابطی (interface) را که بافر
از طریق آن دریافت شده است مشخص می‌کنند.
DHCP6_HOOK_BUFFER_RCVD_SKIP
0.0
3.5
received buffer from %1 to %2 over interface %3 is not parsed because a callout set the next step to SKIP
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که یک فراخوان نصب‌شده روی
نقطه قلاب buffer6_receive وضعیت گام بعدی را روی skip تنظیم کند. برای این نقطه
قلاب به‌خصوص، این مقدار تنظیم‌شده توسط فراخوان به کارساز دستور می‌دهد تا
بافر را تجزیه (parse) نکند، زیرا پیش‌تر توسط قلاب تجزیه شده است.
آرگومان‌ها نشانی مبدأ و مقصد و همچنین نام رابطی را که بافر از طریق آن
دریافت شده است مشخص می‌کنند.
DHCP6_HOOK_BUFFER_SEND_SKIP
0.0
3.5
%1: prepared DHCPv6 response was dropped because a callout set the next step to SKIP
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که یک فراخوان نصب‌شده روی نقطه قلاب
buffer6_send مقدار گام بعدی را روی SKIP تنظیم کند. برای این نقطه قلاب به‌خصوص،
تنظیم SKIP توسط فراخوان به کارساز دستور می‌دهد که بسته را دور بیندازد.
کارساز تمامی پردازش‌ها را تکمیل کرده است (برای نمونه ممکن است اجاره‌ها را تخصیص داده،
به‌روزرسانی یا آزاد کرده باشد)، اما پاسخ به کلاینت ارسال نخواهد شد.
آرگومان شامل اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_HOOK_DDNS_UPDATE
0.0
3.5
A hook has updated the DDNS parameters: hostname %1=>%2, forward update %3=>%4, reverse update %5=>%6
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام نشان می‌دهد که یک قلاب روی نقطه قلاب ddns6_update فراخوانی شده
و آن قلاب پارامترهای به‌روزرسانی DDNS را تغییر داده است: نام میزبان (hostname)، یا اینکه آیا
به‌روزرسانی مستقیم (رکورد A) یا معکوس (رکورد PTR) برای DDNS انجام گیرد یا خیر.
DHCP6_HOOK_DECLINE_DROP
0.0
3.5
During Decline processing (client=%1, interface=%2, addr=%3) hook callout set next step to DROP, dropping packet.
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام نشان می‌دهد که کارساز پیام DECLINE را دریافت کرده، درستی آن تأیید
شده و با اطلاعات اجاره در کارساز مطابقت داشته است. کارساز قلاب‌ها را
برای نقطه قلاب lease6_decline فراخوانی کرده و یکی از فراخوان‌ها وضعیت گام بعدی را روی DROP تنظیم کرده است.
اکنون کارساز پردازش بسته را متوقف می‌کند، به گونه‌ای که انگار هرگز دریافت
نشده است. اجاره همچنان در وضعیت تخصیص‌یافته به این کلاینت باقی می‌ماند.
DHCP6_HOOK_DECLINE_SKIP
0.0
3.5
During Decline processing (client=%1, interface=%2, addr=%3) hook callout set status to SKIP, skipping decline.
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که کارساز پیام DECLINE را دریافت کرده، درستی آن تأیید
شده و با اطلاعات اجاره در کارساز مطابقت داشته است. کارساز قلاب‌ها را
برای نقطه قلاب lease6_decline فراخوانی کرده و یکی از فراخوان‌ها وضعیت گام بعدی را روی SKIP تنظیم کرده است.
کارساز از عملیات انتقال اجاره به وضعیت ردشده (declined) صرف‌نظر کرده و
به پردازش بسته ادامه می‌دهد. به‌ویژه، پیامی از نوع REPLY ارسال خواهد کرد
به گونه‌ای که گویی رد اجاره (decline) واقعاً اتفاق افتاده است..SS DHCP6_HOOK_LEASE6_RELEASE_NA_SKIP
0.0
3.5
%1: اجاره نشانی DHCPv6 آزاد نشد زیرا یک callout گام بعدی را روی SKIP تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب lease6_release گام بعدی را روی SKIP تنظیم کرده باشد. برای این نقطه قلاب به‌خصوص، این تنظیم توسط callout به سرور دستور می‌دهد که اجاره را آزاد نکند. اگر یک کلاینت درخواست آزادسازی چندین اجاره را داده باشد (با ارسال چندین گزینه IA)، سرور این اجاره خاص را نگه داشته و طبق روال معمول آزادسازی موارد دیگر را ادامه می‌دهد. این آرگومان حاوی اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_HOOK_LEASE6_RELEASE_PD_SKIP
0.0
3.5
%1: اجاره پیشوند آزاد نشد زیرا یک callout گام بعدی را روی SKIP تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب lease6_release گام بعدی را روی مقدار SKIP تنظیم کند. برای این نقطه قلاب به‌خصوص، این تنظیم توسط callout به سرور دستور می‌دهد که اجاره را آزاد نکند. اگر کلاینت درخواست آزادسازی چندین اجاره را داشته باشد (با ارسال چندین گزینه IA)، سرور این اجاره به‌خصوص را نگه داشته و طبق روال معمول تمدیدهای دیگر را ادامه خواهد داد. این آرگومان حاوی اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_HOOK_LEASES6_COMMITTED_DROP
0.0
3.5
%1: بسته دور انداخته شد، زیرا یک callout گام بعدی را روی DROP تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب leases6_committed گام بعدی را روی DROP تنظیم کند.
DHCP6_HOOK_LEASES6_COMMITTED_PARK
0.0
3.5
%1: بسته پارک شد، زیرا یک callout گام بعدی را روی PARK تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب leases6_committed گام بعدی را روی PARK تنظیم کند.
DHCP6_HOOK_LEASES6_PARKING_LOT_FULL
0.0
3.5
محدودیت parked-packet-limit به میزان %1 رسیده است، در حال دور انداختن پرس‌وجو: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی رخ می‌دهد که محوطه پارک (parking lot) مورد استفاده برای نگه‌داشتن پرس‌وجوهای کلاینت تا زمان تکمیل کار کتابخانه قلاب برای آن‌ها، به حد تعیین‌شده توسط پارامتر سراسری parked-packet-limit رسیده یا از آن فراتر رفته باشد. این وضعیت می‌تواند زمانی رخ دهد که kea-dhcp6 در حال استفاده از کتابخانه‌های قلاب (مانند HA) است که callout مربوط به "leases6-committed" را پیاده‌سازی می‌کنند و پرس‌وجوهای کلاینت سریع‌تر از توانایی آن calloutها برای پاسخ‌گویی به آن‌ها، دریافت می‌شوند.
DHCP6_HOOK_PACKET_RCVD_SKIP
0.0
3.5
%1: بسته دور انداخته شد، زیرا یک callout گام بعدی را روی SKIP تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب pkt6_receive گام بعدی را روی SKIP تنظیم کند. برای این نقطه قلاب به‌خصوص، تنظیم این مقدار به سرور دستور می‌دهد که بسته را دور بیندازد.
DHCP6_HOOK_PACKET_SEND_DROP
0.0
3.5
%1: پاسخ آماده‌شده‌ی DHCPv6 ارسال نشد زیرا یک callout گام بعدی را روی DROP تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب pkt6_send گام بعدی را روی DROP تنظیم کند. برای این نقطه قلاب به‌خصوص، تنظیم این مقدار توسط یک callout به سرور دستور می‌دهد که بسته را دور بیندازد. این عملاً بدین معناست که کلاینت هیچ پاسخی دریافت نخواهد کرد، حتی اگر سرور درخواست کلاینت را پردازش کرده و بر اساس آن اقدام کرده باشد (مثلاً احتمالاً یک اجاره تخصیص داده باشد). این آرگومان اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند.
DHCP6_HOOK_PACKET_SEND_SKIP
0.0
3.5
%1: پاسخ آماده‌شده‌ی DHCPv6 ساخته نشد زیرا یک callout گام بعدی را روی SKIP تنظیم کرده است
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب pkt6_send گام بعدی را روی SKIP تنظیم کند. برای این نقطه قلاب به‌خصوص، تنظیم این مقدار توسط یک callout به سرور دستور می‌دهد که داده‌های ارسالی روی شبکه (pack) را نسازد، زیرا این کار قبلاً توسط قلاب انجام شده است. این آرگومان اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند..SS DHCP6_HOOK_SUBNET6_SELECT_DROP
0.0
3.5
%1: packet was dropped because a callout set the drop flag
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب subnet6_select پرچم drop را تنظیم کرده باشد. برای این نقطه قلاب به‌خصوص، تنظیم این پرچم به سرور دستور می‌دهد که بسته دریافتی را دور بیندازد (drop کند). آرگومان حاوی اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_HOOK_SUBNET6_SELECT_PARK
0.0
3.5
%1: packet was parked
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب subnet6_select پرچم park را تنظیم کرده باشد. آرگومان حاوی اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_HOOK_SUBNET6_SELECT_SKIP
0.0
3.5
%1: no subnet was selected because a callout set the next step to SKIP
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب subnet6_select گام بعدی را روی مقدار SKIP تنظیم کرده باشد. برای این نقطه قلاب به‌خصوص، تنظیم این مقدار به سرور دستور می‌دهد که هیچ زیرشبکه‌ای را انتخاب نکند؛ اقدامی که پردازش‌های بعدی را به‌شدت محدود می‌سازد؛ سرور تنها قادر به ارائه گزینه‌های سراسری (global options) خواهد بود - هیچ آدرس یا پیشوندی تخصیص داده نخواهد شد. آرگومان حاوی اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_INIT_FAIL
0.0
3.5
failed to initialize Kea server: %1
168u
168u
سرور در برقراری ارتباط با سایر بخش‌های Kea ناموفق بوده است، در خواندن فایل پیکربندی JSON شکست خورده، یا با هر مشکل بحرانی دیگری مواجه شده است که مانع از راه‌اندازی درست آن می‌شود. پیام خطای پیوست‌شده جزئیات بیشتری درباره این مشکل ارائه می‌دهد.
DHCP6_LEASE_ADVERT
0.0
3.5
%1: lease for address %2 and iaid=%3 will be advertised
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اطلاع‌رسانی نشان می‌دهد که سرور یک آدرس را در پیام ADVERTISE به کلاینت اعلان (advertise) خواهد کرد. کلاینت در تبادل پیام بعدی، با ارسال پیام REQUEST درخواست تخصیص این آدرس را ثبت خواهد کرد. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های باقی‌مانده آدرس تخصیص‌یافته و IAID را نگه‌داری می‌کنند.
DHCP6_LEASE_ADVERT_FAIL
0.0
3.5
%1: failed to advertise an address lease for iaid=%2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که سرور در پاسخ به یک پیام دریافتی SOLICIT، نتوانسته است یک اجاره آدرس غیرموقت (non-temporary) را برای کلاینت مربوطه اعلان کند. ممکن است دلایل متعددی برای این شکست وجود داشته باشد. هر شکست در یک مدخل لاگ جداگانه ثبت می‌شود. آرگومان اول حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم IAID را نگه‌داری می‌کند.
DHCP6_LEASE_ALLOC
0.0
3.5
%1: lease for address %2 and iaid=%3 has been allocated for %4 seconds
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اطلاع‌رسانی نشان می‌دهد که در پاسخ به پیام REQUEST کلاینت، سرور با موفقیت یک اجاره آدرس غیرموقت (non-temporary) را اعطا کرده است. این یک رفتار عادی بوده و نشان‌دهنده عملکرد موفقیت‌آمیز است. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های باقی‌مانده حاوی آدرس تخصیص‌یافته، IAID و طول‌عمر اعتبار (validity lifetime) هستند.
DHCP6_LEASE_ALLOC_FAIL
0.0
3.5
%1: failed to grant an address lease for iaid=%2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که سرور در پاسخ به یک REQUEST دریافتی، در اعطای اجاره آدرس غیرموقت (non-temporary) به کلاینت ناموفق بوده است. دلایل متعددی می‌تواند برای چنین شکستی وجود داشته باشد. هر شکست در یک مدخل لاگ جداگانه ثبت می‌شود. آرگومان اول حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم IAID را نگه‌داری می‌کند..SS DHCP6_LEASE_DATA
0.0
3.5
%1: detailed lease information for iaid=%2: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی برای چاپ اطلاعات دقیق دربارهٔ اجارهٔ تخصیص‌یافته یا اجاره‌ای که به کلاینت اعلان خواهد شد به کار می‌رود.
آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است.
آرگومان دوم حاوی IAID است.
آرگومان سوم حاوی اطلاعات دقیق اجاره است.
DHCP6_LEASE_NA_WITHOUT_DUID
0.0
3.5
%1: address lease for address %2 does not have a DUID
168u
168u
این پیام خطا بیانگر مشکلی در سازگاری پایگاه داده است. پایگاه دادهٔ اجاره‌ها دارای مدخلی است که نشان می‌دهد آدرس داده‌شده در حال استفاده است، اما اجاره شامل هیچ شناسهٔ کلاینتی نیست. این مسئله به احتمال زیاد به دلیل یک خطای نرم‌افزاری است: لطفاً یک گزارش باگ ارسال کنید. به عنوان راهکاری موقت، مدخل اجاره را به صورت دستی از پایگاه داده حذف کنید. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی آدرسی است که باید آزاد شود.
DHCP6_LEASE_PD_WITHOUT_DUID
0.0
3.5
%1: lease for prefix %2/%3 does not have a DUID
168u
168u
این پیام خطا بیانگر نقصی در سازگاری پایگاه داده است. پایگاه دادهٔ اجاره‌ها مدخلی دارد که مشخص می‌کند پیشوند داده‌شده در حال استفاده است، اما این اجاره شامل هیچ شناسهٔ کلاینتی نیست. این موضوع به احتمال فراوان ناشی از یک خطای نرم‌افزاری است: لطفاً یک گزارش باگ ارسال کنید. به عنوان راهکاری موقت، مدخل اجاره را به صورت دستی از پایگاه داده حذف کنید. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های دوم و سوم حاوی پیشوند و طول پیشوند هستند.
DHCP6_LEASE_QUERY_ERROR_GETTING_RELAY_INFO
0.0
3.5
failed to get relay information for lease: %1, reason: %2
168u
168u
این یک پیام هشدار است که نشان می‌دهد سرور نتوانسته از اطلاعات رلهٔ ذخیره‌شده در user-context اجاره برای ساخت گزینهٔ lq-relay-data جهت DHCPV6_LEASEQUERY_REPLY استفاده کند. سرور همچنان پاسخ را به درخواست‌کننده ارسال می‌کند اما بدون گزینهٔ lq-relay-data. محتمل‌ترین دلیل برای این موضوع یا یک فایل اجارهٔ خراب است یا یک خطای برنامه‌نویسی و باید گزارش شود. آرگومان نخست جزئیات اجاره و آرگومان دوم خطای مشخص‌شده است.
DHCP6_LEASE_QUERY_PACKET_PACK
0.0
3.5
%1: preparing on-wire format of the packet to be sent
168u
168u
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور شروع به آماده‌سازی قالب on-wire بسته برای ارسال به کلاینت می‌کند. آرگومان مشخص‌کنندهٔ اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_LEASE_QUERY_PACKET_PACK_FAILED
0.0
3.5
%1: preparing on-wire-format of the packet to be sent failed %2
168u
168u
این پیام خطا هنگامی صادر می‌شود که آماده‌سازی قالب on-wire بسته با شکست مواجه شده باشد. آرگومان نخست کلاینت و
DHCP6_LEASE_QUERY_PACKET_UNPACK_FAILED
0.0
3.5
failed to parse query from %1 to %2, received over interface %3, reason: %4
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که DHCPV6_LEASEQUERY دریافت‌شده بدریخت باشد و نتواند توسط فراخوانی buffer6_receive تجزیه شود. پرس‌وجو توسط سرور دور انداخته خواهد شد. سه آرگومان نخست، آدرس IP مبدأ، آدرس IP مقصد و رابط را مشخص می‌کنند. آخرین آرگومان دلیلی برای شکست ارائه می‌دهد.
DHCP6_LEASE_QUERY_PREFIX_LENGTH_LIST
0.0
3.5
the list of prefix lengths to use when searching will be: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی پس از یک رویداد پیکربندی (مجدد) صادر می‌شود تا فهرستی از طول پیشوندهای واگذارشده را نمایش دهد که هنگام جستجو برای پیشوند واگذارشده‌ای که آدرس پرس‌وجو به آن تعلق دارد، استفاده خواهند شد. این آرگومان فهرستی از طول پیشوندها به ترتیبی است که هنگام جستجوها استفاده می‌شوند..SS DHCP6_LEASE_QUERY_PROCESS_FAILED
0.0
3.5
processing failed for lease query: %1, reason: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام خطا زمانی صادر می‌شود که کارگزار هنگام پردازش یک DHCPV6_LEASEQUERY با خطا مواجه شود. آرگومان نخست جزئیات پرس‌وجو و آرگومان دوم شرح خطا را ارائه می‌دهد.
DHCP6_LEASE_QUERY_RECEIVED
0.0
3.5
received query: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که پرس‌وجوی DHCPV6_LEASEQUERY دریافت شده باشد.
DHCP6_LEASE_QUERY_REPLY_SEND_FAILED
0.0
3.5
unable to send response: %1, iface: %2, address %3:%4 error: %5
168u
168u
این پیام خطا زمانی صادر می‌شود که کارگزار نتواند پاسخ پرس‌وجوی اجاره (lease query) را برای درخواست‌کننده ارسال کند. آرگومان نخست جزئیات پرس‌وجو را نشان می‌دهد و به‌دنبال آن رابط خروجی، آدرس IP و درگاه، و در نهایت خود خطا می‌آید.
DHCP6_LEASE_QUERY_REPLY_SENT
0.0
3.5
response: %1, sent to %2:%3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که پاسخی به یک DHCPV6_LEASEQUERY برای درخواست‌کننده ارسال شده باشد. آرگومان نخست جزئیات پاسخ را ارائه می‌دهد و آرگومان‌های دوم و سوم آدرس IP و درگاهی هستند که پاسخ به آن‌ها فرستاده شده است.
DHCP6_LEASE_RENEW
0.0
3.5
%1: lease for address %2 and iaid=%3 has been allocated
168u
168u
این پیام اطلاع‌رسانی بیانگر این است که کارگزار در پاسخ به پیام REQUEST کلاینت، اجارهٔ یک آدرس غیرموقت (non-temporary) را با موفقیت تمدید کرده است. این یک رفتار عادی بوده و نشان‌دهندهٔ عملکرد موفق است. آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. باقی آرگومان‌ها آدرس تخصیص‌یافته و IAID را نگه‌داری می‌کنند.
DHCP6_LEASE_REUSE
0.0
3.5
%1: lease for address %2 and iaid=%3 has been reused for %4 seconds
168u
168u
این پیام اطلاع‌رسانی بیانگر این است که کارگزار در پاسخ به پیام کلاینت، اجارهٔ یک آدرس غیرموقت را با موفقیت مجدداً استفاده کرده است (reuse). این یک رفتار عادی بوده و نشان‌دهندهٔ عملکرد موفق است. آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. باقی آرگومان‌ها آدرس تخصیص‌یافته، IAID و طول عمر اعتبار (validity lifetime) را دربرمی‌گیرند.
DHCP6_MULTI_THREADING_INFO
0.0
3.5
enabled: %1, number of threads: %2, queue size: %3
168u
168u
این پیامی است که برخی اطلاعات مربوط به پارامترهای چندنخی (multi-threading) را که کارگزار با آن‌ها در حال اجرا است فهرست می‌کند.
DHCP6_NOT_RUNNING
0.0
3.5
IPv6 DHCP server is not running
168u
168u
هنگامی که تلاشی برای خاموش کردن کارگزار IPv6 DHCP صورت گیرد اما کارگزار در حال اجرا نباشد، یک پیام هشدار صادر می‌شود.
DHCP6_NO_INTERFACES
0.0
3.5
failed to detect any network interfaces
168u
168u
کارگزار IPv6 DHCP در حین راه‌اندازی موفق به شناسایی هیچ رابط شبکه‌ای نشد و به همین دلیل در حال متوقف شدن است..SS DHCP6_OPEN_SOCKET
0.0
3.5
opening service sockets on port %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۰ ثبت می‌شود.
این پیام اشکال‌زدایی در حین راه‌اندازی صادر می‌شود و نشان می‌دهد که سرور IPv6 DHCP در شرف باز کردن سوکت‌ها روی درگاه (port) مشخص‌شده است.
DHCP6_OPEN_SOCKETS_FAILED
0.0
3.5
maximum number of open service sockets attempts: %1, has been exhausted without success
168u
168u
این خطا نشان می‌دهد که سرور پس از انجام حداکثر تعداد تلاش‌های پیکربندی‌شده، در متصل کردن (bind) سوکت‌های سرویس ناموفق بوده است.
DHCP6_OPEN_SOCKETS_NO_RECONNECT_CTL
0.0
3.5
unexpected error in bind service sockets.
168u
168u
این یک پیام خطا است که نشان‌دهنده خطایی در برنامه‌نویسی است که نباید رخ دهد. این خطا مانع از تلاش سرور برای متصل شدن به سوکت‌های سرویس در صورت در دسترس نبودن آن‌ها می‌شود و سرور خارج می‌شود. این خطا باید گزارش شود.
DHCP6_PACKET_DROP_DHCP_DISABLED
0.0
3.5
%1: DHCP service is globally disabled
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بسته به دلیل غیرفعال بودن موقت سرویس DHCP دور انداخته (drop) می‌شود. این مسئله بر تمام بسته‌های دریافتی DHCP اثر می‌گذارد. سرویس ممکن است توسط دستور کنترلی "dhcp-enable" یا به‌طور خودکار پس از گذشت مدت‌زمان مشخصی از دریافت دستور "dhcp-disable" دوباره فعال شود.
DHCP6_PACKET_DROP_DROP_CLASS
0.0
3.5
dropped as member of the special class 'DROP': %1 %2
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بسته دریافتی در کلاس ویژه 'DROP' دسته‌بندی شده و دور انداخته شود. جزئیات بسته نمایش داده می‌شود.
DHCP6_PACKET_DROP_DROP_CLASS2
0.0
3.5
dropped as member of the special class 'DROP' after host reservation lookup: %1 %2
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بسته دریافتی پس از جستجوی رزرو میزبان (host reservation lookup) در کلاس ویژه 'DROP' دسته‌بندی شده و دور انداخته شود. جزئیات بسته نمایش داده می‌شود.
DHCP6_PACKET_DROP_DROP_CLASS_EARLY
0.0
3.5
dropped as member of the special class 'DROP' after early global host reservations lookup: %1 %2
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بسته دریافتی پس از جستجوی زودهنگام و سراسری رزروهای میزبان در کلاس ویژه 'DROP' دسته‌بندی شده و دور انداخته شود. جزئیات بسته نمایش داده می‌شود.
DHCP6_PACKET_DROP_DUPLICATE
0.0
3.5
dropped as sent by the same client than a packet being processed by another thread: dropped %1 %2 by thread %3 as duplicate of %4 %5 processed by thread %6
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
در حال حاضر پردازش چندنخی (multi-threading) با دور انداختن بسته‌های جدید تا زمان پایان پردازش، از تداخل و شرایط رقابتی (race condition) بین بسته‌های ارسال‌شده توسط یک کلاینت یکسان جلوگیری می‌کند. جزئیات بسته‌ها و شناسه‌های نخ‌ها برای هر دو بسته در این پیام هشدار گنجانده شده است.
DHCP6_PACKET_DROP_PARSE_FAIL
0.0
3.5
%1: failed to parse packet from %2 to %3, received over interface %4, reason: %5, %6
168u
168u
در سطح گزارش اشکال‌زدایی ۱۵ ثبت می‌شود.
سرور DHCPv6 بسته‌ای دریافت کرده است که قادر به تفسیر و تجزیه آن نیست. دلیل نامعتبر بودن بسته در پیام ذکر شده است..SS DHCP6_PACKET_DROP_SERVERID_MISMATCH
0.0
3.5
%1: dropping packet with server identifier: %2, server is using: %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
پیامی اشکال‌زدایی که نشان می‌دهد سرور پیامی حاوی گزینهٔ شناسهٔ سرور (server identifier) دریافت کرده است که با شناسهٔ سروری که خود سرور استفاده می‌کند، همخوانی ندارد.
DHCP6_PACKET_DROP_UNICAST
0.0
3.5
%1: dropping unicast %2 packet as this packet should be sent to multicast
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور بستهٔ تک‌پخشی (unicast) را دور می‌اندازد، زیرا بسته‌هایی از این نوع باید به‌صورت چندپخشی (multicast) ارسال شوند. آرگومان نخست اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند و آرگومان دوم نوع بسته را تعیین می‌نماید.
DHCP6_PACKET_OPTIONS_SKIPPED
0.0
3.5
%1: An error unpacking an option, caused subsequent options to be skipped: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که باز کردن (unpack) یک گزینه با خطا مواجه شده و در نتیجه باز کردن گزینه‌های باقی‌مانده در بسته غیرممکن شده است. سرور همچنان تلاش خواهد کرد تا به این بسته رسیدگی کند.
DHCP6_PACKET_PROCESS_EXCEPTION
0.0
3.5
%1: exception occurred during packet processing
168u
168u
این پیام خطا نشان می‌دهد که در حین پردازش بسته، یک استثنای (exception) غیر استاندارد رخ داده است که توسط سایر مدیریت‌کننده‌های اختصاصی‌ترِ استثنا گرفته نشده است. این بسته دور انداخته می‌شود و سرور به کار خود ادامه خواهد داد.
DHCP6_PACKET_PROCESS_EXCEPTION_MAIN
0.0
3.5
exception occurred during packet processing
168u
168u
این پیام خطا نشان می‌دهد که در حین پردازش بسته، یک استثنای غیر استاندارد رخ داده است که توسط سایر مدیریت‌کننده‌های اختصاصی‌ترِ استثنا گرفته نشده است. این بسته دور انداخته می‌شود و سرور به کار خود ادامه خواهد داد. این پیام خطا ممکن است در حلقهٔ اصلی پردازش سرور رخ دهد.
DHCP6_PACKET_PROCESS_FAIL
0.0
3.5
%1: processing of %2 message received from %3 failed: %4
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام کلی و فراگیر است که نشان می‌دهد پردازش نوع پیام مشخص‌شده از آدرس اعلام‌شده با شکست مواجه شده است. دلیل آن در متن پیام ذکر شده است. سرور پاسخی ارسال نخواهد کرد، بلکه بسته را نادیده می‌گیرد.
DHCP6_PACKET_PROCESS_STD_EXCEPTION
0.0
3.5
%1: exception occurred during packet processing: %2
168u
168u
این پیام خطا نشان می‌دهد که در حین پردازش بسته، یک استثنای استاندارد رخ داده است که توسط سایر مدیریت‌کننده‌های اختصاصی‌ترِ استثنا گرفته نشده است. این بسته دور انداخته می‌شود و سرور به کار خود ادامه خواهد داد.
DHCP6_PACKET_PROCESS_STD_EXCEPTION_MAIN
0.0
3.5
exception occurred during packet processing: %1
168u
168u
این پیام خطا نشان می‌دهد که در حین پردازش بسته، یک استثنای استاندارد رخ داده است که توسط سایر مدیریت‌کننده‌های اختصاصی‌ترِ استثنا گرفته نشده است. این بسته دور انداخته می‌شود و سرور به کار خود ادامه خواهد داد. این پیام خطا ممکن است در حلقهٔ اصلی پردازش سرور رخ دهد.
DHCP6_PACKET_QUEUE_FULL
0.0
3.5
multi-threading packet queue is full
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیامی اشکال‌زدایی حاکی از آنکه صف بسته‌های چندرشته‌ای (multi-threading) پر شده است؛ بنابراین قدیمی‌ترین بستهٔ صف دور انداخته شد تا فضایی برای بستهٔ دریافت‌شده باز شود..SS DHCP6_PACKET_RECEIVED
0.0
3.5
%1: %2 (type %3) received from %4 to %5 on interface %6
168u
168u
یک پیام INFO که نشان می‌دهد سرور نوع مشخص‌شده‌ای از بسته را روی رابط مشخص‌شده دریافت کرده است. آرگومان نخست، اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند. آرگومان‌های دوم و سوم به ترتیب نام پیام DHCPv6 و نوع عددی آن را مشخص می‌کنند. باقی آرگومان‌ها نشانی مبدأ، نشانی IP مقصد و نام رابطی را که پیام روی آن دریافت شده است مشخص می‌کنند.
DHCP6_PACKET_RECEIVE_FAIL
0.0
3.5
error on attempt to receive packet: %1
168u
168u
سرور IPv6 DHCP برای دریافت یک بسته تلاش کرد اما در حین این تلاش خطایی رخ داد. علت خطا در پیام گنجانده شده است.
DHCP6_PACKET_REJECT_CLASS
0.0
3.5
assignment rejected as member of the special class 'REJECT': %1 %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۱۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بستهٔ دریافتی در کلاس ویژهٔ 'REJECT' طبقه‌بندی شده و هیچ منبعی به آن تخصیص نیافته است.
جزئیات بسته نمایش داده می‌شوند.
DHCP6_PACKET_SEND
0.0
3.5
%1: trying to send packet %2 (type %3) from [%4]:%5 to [%6]:%7 on interface %8
168u
168u
یک پیام INFO که نشان می‌دهد سرور در حال تلاش برای ارسال نوع مشخص‌شده‌ای از بسته است. آرگومان‌ها اطلاعات شناسایی کلاینت (نشانی HW و شناسه کلاینت)، نام و نوع پیام DHCP، نشانی و درگاه IPv6 مبدأ، نشانی و درگاه IPv6 مقصد و نام رابط را مشخص می‌کنند.
DHCP6_PACKET_SEND_FAIL
0.0
3.5
%1: failed to send DHCPv6 packet: %2
168u
168u
این خطا در صورتی در خروجی ثبت می‌شود که سرور IPv6 DHCP نتواند پیام سرهم‌شدهٔ DHCP را به یک کلاینت ارسال کند. علت خطا در پیام گنجانده شده است.
DHCP6_PACK_FAIL
0.0
3.5
%1: failed to assemble response correctly: %2
168u
168u
این خطا زمانی در خروجی ثبت می‌شود که سرور نتواند داده‌های بازگشتی به کلاینت را در قالب یک بستهٔ معتبر سرهم‌بندی کند. به احتمال زیاد علت این امر یک خطای برنامه‌نویسی است: لطفاً یک گزارش باگ ارسال کنید.
DHCP6_PARSER_COMMIT_EXCEPTION
0.0
3.5
parser failed to commit changes
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی سرور IPv6 DHCP، مجموعه‌ای از تجزیه‌کننده‌ها با موفقیت ایجاد شدند، اما یکی از آن‌ها به دلیل رخ دادن یک استثنای سطح‌پایین سیستمی، در اعمال (commit) تغییرات خود شکست خورد. ممکن است پیام‌های دیگری نیز برای نشان دادن علت در خروجی ظاهر شوند.
DHCP6_PARSER_COMMIT_FAIL
0.0
3.5
parser failed to commit changes: %1
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی سرور IPv6 DHCP، مجموعه‌ای از تجزیه‌کننده‌ها با موفقیت ایجاد شدند، اما یکی از آن‌ها در اعمال تغییرات خود شکست خورد. دلیل این شکست در پیام آورده شده است.
DHCP6_PARSER_EXCEPTION
0.0
3.5
failed to create or run parser for configuration element %1
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی، سرور IPv6 DHCP نتوانست تجزیه‌کننده‌ای برای رمزگشایی محتوای عنصر پیکربندیِ نام‌برده ایجاد کند، یا اینکه ساخت آن موفقیت‌آمیز بود اما عملیات تجزیه و اعمال تغییرات با شکست مواجه شد. این پیام در پاسخ به رخ دادن یک استثنای غیر Kea صادر شده است. پیام‌های دیگر ممکن است اطلاعات تکمیلی ارائه دهند.
محتمل‌ترین علت این اتفاق این است که فایل مشخصات سرور (که جزئیات محتویات مجاز پیکربندی را شرح می‌دهد) برای این نسخه از Kea صحیح نیست. این امر ممکن است ناشی از قطع شدن فرایند نصب یک به‌روزرسانی برای Kea باشد..SS DHCP6_PARSER_FAIL
0.0
3.5
failed to create or run parser for configuration element %1: %2
168u
168u
هنگام دریافت پیامی حاوی جزئیات تغییر در پیکربندی، کارساز DHCP برای IPv6 نتوانست یک تجزیه‌کننده برای رمزگشایی محتویات عنصر پیکربندی نام‌برده ایجاد کند، یا اینکه ساخت آن موفقیت‌آمیز بوده اما عملیات تجزیه و اعمال تغییرات با شکست مواجه شده است. علت شکست در پیام مشخص شده است.
DHCP6_PD_LEASE_ADVERT
0.0
3.5
%1: lease for prefix %2/%3 and iaid=%4 will be advertised
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اطلاعاتی نشان می‌دهد که کارساز در پیام ADVERTISE یک پیشوند را برای کلاینت اعلان خواهد کرد. کلاینت در تبادل پیام بعدی با ارسال پیام REQUEST، تخصیص این پیشوند را درخواست خواهد کرد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های باقی‌مانده شامل پیشوند تخصیص‌یافته، طول پیشوند و IAID هستند.
DHCP6_PD_LEASE_ADVERT_FAIL
0.0
3.5
%1: failed to advertise a prefix lease for iaid=%2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که کارساز در پاسخ به پیام SOLICIT دریافتی، نتوانسته است اجاره یک پیشوند را برای کلاینت مشخص اعلان کند. ممکن است دلایل متعددی برای این شکست وجود داشته باشد. هر شکست در یک ورودی گزارش جداگانه ثبت می‌شود. آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی IAID است.
DHCP6_PD_LEASE_ALLOC
0.0
3.5
%1: lease for prefix %2/%3 and iaid=%4 has been allocated for %5 seconds
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اطلاعاتی نشان می‌دهد که کارساز در پاسخ به پیام REQUEST کلاینت، اجاره یک پیشوند را با موفقیت اعطا کرده است. این رفتاری عادی است و عملیات موفقیت‌آمیز را نشان می‌دهد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های باقی‌مانده شامل پیشوند تخصیص‌یافته، طول پیشوند، IAID و طول عمر اعتبار هستند.
DHCP6_PD_LEASE_ALLOC_FAIL
0.0
3.5
%1: failed to grant a prefix lease for iaid=%2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام نشان می‌دهد که کارساز در پاسخ به پیام REQUEST دریافتی، نتوانسته است اجاره یک پیشوند را به کلاینت اعطا کند. دلایل متعددی برای این شکست می‌تواند وجود داشته باشد. هر شکست در یک ورودی گزارش جداگانه ثبت می‌شود. آرگومان نخست حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم شامل IAID است.
DHCP6_PD_LEASE_RENEW
0.0
3.5
%1: lease for prefix %2/%3 and iaid=%4 has been allocated
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کارساز در پاسخ به پیام REQUEST یک کلاینت، اجاره یک پیشوند را با موفقیت تمدید کرده است. این رفتاری عادی است و عملیات موفقیت‌آمیز را نشان می‌دهد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های باقی‌مانده شامل پیشوند تخصیص‌یافته، طول پیشوند و IAID هستند.
DHCP6_PD_LEASE_REUSE
0.0
3.5
%1: lease for prefix %2/%3 and iaid=%4 has been reused for %5 seconds
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کارساز در پاسخ به پیام کلاینت، اجاره یک پیشوند را با موفقیت مجدداً استفاده کرده است. این رفتاری عادی است و عملیات موفقیت‌آمیز را نشان می‌دهد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های باقی‌مانده شامل پیشوند تخصیص‌یافته، طول پیشوند، IAID و طول عمر اعتبار هستند.
DHCP6_PROCESS_IA_NA_EXTEND
0.0
3.5
%1: extending lease lifetime for IA_NA option with iaid=%2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام هنگامی ثبت می‌شود که کارساز تمدید طول عمر اجاره نشانی مرتبط با IAID مشخص را آغاز می‌کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم شامل IAID است..SS DHCP6_PROCESS_IA_NA_RELEASE
0.0
3.5
%1: releasing lease for IA_NA option with iaid=%2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که کارساز در نتیجه دریافت پیام RELEASE، در تلاش برای آزادسازی اجاره کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی IAID می‌باشد.
DHCP6_PROCESS_IA_NA_REQUEST
0.0
3.5
%1: server is processing IA_NA option with iaid=%2 and hint=%3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان‌دهنده پردازش یک گزینهٔ IA_NA دریافت‌شده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی IAID مربوط به گزینهٔ IA_NA است. آرگومان سوم ممکن است حاوی راهنمایی (hint) برای کارساز درباره نشانی مد نظر کلاینت جهت تخصیص باشد. اگر راهنمایی وجود نداشته باشد، این آرگومان متنی را ارائه می‌دهد که نشان می‌دهد راهنمایی ارسال نشده است.
DHCP6_PROCESS_IA_NA_SOLICIT
0.0
3.5
%1: server is processing IA_NA option with iaid=%2 and hint=%3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان‌دهنده پردازش یک گزینهٔ IA_NA دریافت‌شده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی IAID مربوط به گزینهٔ IA_NA است. آرگومان سوم ممکن است حاوی راهنمایی (hint) برای کارساز درباره نشانی مد نظر کلاینت جهت تخصیص باشد. اگر راهنمایی وجود نداشته باشد، این آرگومان متنی را ارائه می‌دهد که نشان می‌دهد راهنمایی ارسال نشده است.
DHCP6_PROCESS_IA_PD_EXTEND
0.0
3.5
%1: extending lease lifetime for IA_PD option with iaid=%2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام زمانی ثبت می‌شود که کارساز شروع به تمدید طول عمر اجاره پیشوند (prefix lease) مرتبط با IAID مشخص می‌کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی IAID است.
DHCP6_PROCESS_IA_PD_REQUEST
0.0
3.5
%1: server is processing IA_PD option with iaid=%2 and hint=%3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان‌دهنده پردازش یک گزینهٔ IA_PD دریافت‌شده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی IAID مربوط به گزینهٔ IA_PD است. آرگومان سوم ممکن است شامل راهنمایی (hint) برای کارساز درباره پیشوندی باشد که کلاینت مایل به تخصیص آن است. اگر راهنمایی وجود نداشته باشد، این آرگومان متنی را ارائه می‌دهد که نشان می‌دهد راهنمایی ارسال نشده است.
DHCP6_PROCESS_IA_PD_SOLICIT
0.0
3.5
%1: server is processing IA_PD option with iaid=%2 and hint=%3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان‌دهنده پردازش یک گزینهٔ IA_PD دریافت‌شده است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی IAID مربوط به گزینهٔ IA_PD است. آرگومان سوم ممکن است شامل راهنمایی (hint) برای کارساز درباره پیشوندی باشد که کلاینت مایل به تخصیص آن است. اگر راهنمایی وجود نداشته باشد، این آرگومان متنی را ارائه می‌دهد که نشان می‌دهد راهنمایی ارسال نشده است.
DHCP6_QUERY_DATA
0.0
3.5
%1, packet details: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
یک پیام اشکال‌زدایی که جزئیات بسته دریافت شده را چاپ می‌کند. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است.
DHCP6_QUERY_LABEL
0.0
3.5
received query: %1
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک پرس‌وجو (query) دریافت شده است. این پیام اطلاعات شناسایی کلاینت و تراکنش را نمایش می‌دهد..SS DHCP6_RAPID_COMMIT
0.0
3.5
%1: Rapid Commit option received, following 2-way exchange
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار (سرور) گزینهٔ Rapid Commit را در پیام کلاینت پیدا کند و تبادلات دوطرفه (2-way) توسط سرور برای زیرشبکه‌ای که کلاینت به آن متصل است پشتیبانی شود. آرگومان، اطلاعات شناسایی کلاینت و تراکنش را مشخص می‌کند.
DHCP6_RECLAIM_EXPIRED_LEASES_FAIL
0.0
3.5
failed to reclaim expired leases: %1
168u
168u
این پیام خطا نشان می‌دهد که عملیات بازپس‌گیری اجاره‌های (leases) منقضی‌شده با شکست مواجه شده است و علت خطا را مشخص می‌کند.
DHCP6_RECLAIM_EXPIRED_LEASES_SKIPPED
0.0
3.5
dhcp6 service is currently disabled. Try again in %1 seconds.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازپس‌گیری اجاره‌ها برای آغاز زمان‌بندی شده بود اما به دلیل غیرفعال بودن سرویس DHCPv6 نادیده گرفته شد. زمان‌بندی بازپس‌گیری همچنان مطابق با مقدار پیکربندی‌شدهٔ reclaim-timer-wait-time ادامه خواهد داشت.
DHCP6_REGISTERED_LEASE_ADD_FAIL
0.0
3.5
error in registered lease add for %1
168u
168u
این پیام خطا نشان می‌دهد که افزودن اجارهٔ ثبت‌شده ناموفق بوده است و آدرسی را که در حال ثبت بود نشان می‌دهد.
DHCP6_REGISTERED_LEASE_UPDATE_FAIL
0.0
3.5
error in registered lease update for %1: %2
168u
168u
این پیام خطا نشان می‌دهد که به‌روزرسانی اجارهٔ ثبت‌شده ناموفق بوده است و آدرس ثبت‌شده و علت خطا را نشان می‌دهد.
DHCP6_RELEASE_NA
0.0
3.5
%1: binding for address %2 and iaid=%3 was released properly
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک آدرس به‌درستی آزاد (released) شده است. این یک فرایند عادی در طول خاموش شدن کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم و سوم به ترتیب شامل آدرس IPv6 آزادشده و IAID هستند.
DHCP6_RELEASE_NA_DELETED
0.0
3.5
%1: binding for address %2 and iaid=%3 was deleted on release
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک آدرس در هنگام آزادسازی حذف شده است. این یک فرایند عادی در طول خاموش شدن کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم و سوم به ترتیب شامل آدرس IPv6 آزادشده و IAID هستند.
DHCP6_RELEASE_NA_EXPIRED
0.0
3.5
%1: binding for address %2 and iaid=%3 expired on release
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک آدرس در هنگام آزادسازی منقضی شده است. این یک فرایند عادی در طول خاموش شدن کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم و سوم به ترتیب شامل آدرس IPv6 آزادشده و IAID هستند.
DHCP6_RELEASE_NA_FAIL
0.0
3.5
%1: failed to remove address lease for address %2 and iaid=%3
168u
168u
این پیام خطا نشان می‌دهد که نرم‌افزار نتوانسته است اجارهٔ یک آدرس را از پایگاه‌دادهٔ اجاره‌ها حذف کند. این امر احتمالاً به دلیل بروز خطا در طول عملیات پایگاه‌داده رخ داده است: حل این مشکل به احتمال زیاد نیازمند مداخلهٔ مدیر سیستم خواهد بود (برای مثال، بررسی اینکه آیا فرایند DHCP دسترسی‌های لازم برای به‌روزرسانی پایگاه‌داده را دارد یا خیر). همچنین این خطا ممکن است زمانی رخ دهد که یک اجاره در طول پردازش پیام RELEASE به‌صورت دستی از پایگاه‌داده حذف شده باشد. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم و سوم به ترتیب شامل آدرس آزادشده و IAID هستند..SS DHCP6_RELEASE_NA_FAIL_WRONG_DUID
0.0
3.5
%1: client tried to release address %2, but it belongs to another client using duid=%3
168u
168u
این پیام هشدار نشان می‌دهد که یک کلاینت تلاش کرده است نشانی‌ای را که متعلق به کلاینت دیگری است آزاد کند. این اتفاق در شرایط عادی نباید رخ دهد و ممکن است نشان‌دهندهٔ پیکربندی نادرست کلاینت باشد. با این حال، از آنجا که کلاینت رهاکنندهٔ نشانی به هر حال استفاده از آن را متوقف خواهد کرد، احتمال زیادی وجود دارد که این وضعیت به خودی خود برطرف شود.
DHCP6_RELEASE_NA_FAIL_WRONG_IAID
0.0
3.5
%1: client tried to release address %2, but it used wrong IAID (expected %3, but got %4)
168u
168u
این پیام هشدار نشان می‌دهد که کلاینت برای آزادسازی نشانی‌ای تلاش کرده است که متعلق به خود اوست، اما انتظار می‌رفت که این نشانی در یک ظرف IA (انجمن هویت) متفاوتی قرار داشته باشد. این امر احتمالاً به این معنی است که پشتیبانی کلاینت از چندین نشانی دچار ایراد است.
DHCP6_RELEASE_PD
0.0
3.5
%1: prefix %2/%3 for iaid=%4 was released properly
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک پیشوند (prefix) به‌درستی آزاد شده است. این عملیات در طول خاموش شدن کلاینت روالی عادی است. آرگومان اول حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم و سوم پیشوند و طول آن را مشخص می‌کنند. آرگومان چهارم شامل IAID است.
DHCP6_RELEASE_PD_DELETED
0.0
3.5
%1: prefix %2/%3 for iaid=%4 was deleted on release
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک پیشوند در زمان آزادسازی حذف شده است. این عملیات در طول خاموش شدن کلاینت روالی عادی است. آرگومان اول حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم و سوم پیشوند و طول آن را مشخص می‌کنند. آرگومان چهارم شامل IAID است.
DHCP6_RELEASE_PD_EXPIRED
0.0
3.5
%1: prefix %2/%3 for iaid=%4 expired on release
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که یک پیشوند در زمان آزادسازی منقضی شده است. این عملیات در طول خاموش شدن کلاینت روالی عادی است. آرگومان اول حاوی اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم و سوم پیشوند و طول آن را مشخص می‌کنند. آرگومان چهارم شامل IAID است.
DHCP6_RELEASE_PD_FAIL
0.0
3.5
%1: failed to release prefix %2/%3 for iaid=%4
168u
168u
این پیام خطا نشان می‌دهد که نرم‌افزار در حذف اجارهٔ یک پیشوند از پایگاه‌دادهٔ اجاره‌ها با شکست مواجه شده است. این امر احتمالاً ناشی از بروز خطا در حین یک عملیات پایگاه‌داده است؛ رفع آن به احتمال زیاد نیازمند دخالت مدیر سیستم خواهد بود (برای نمونه بررسی اینکه آیا فرایند DHCP اختیارات کافی برای به‌روزرسانی پایگاه‌داده دارد یا خیر). همچنین این خطا ممکن است در صورتی رخ دهد که یک اجاره در طول پردازش پیام RELEASE به‌صورت دستی از پایگاه‌داده حذف شده باشد. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های دوم و سوم پیشوند و طول آن را مشخص می‌کنند. آرگومان چهارم حاوی IAID است.
DHCP6_RELEASE_PD_FAIL_WRONG_DUID
0.0
3.5
%1: client tried to release prefix %2/%3, but it belongs to another client (duid=%4)
168u
168u
این پیام هشدار نشان می‌دهد که کلاینت تلاش کرده است پیشوندی را که متعلق به کلاینت دیگری است آزاد کند. این اتفاق در شرایط عادی نباید رخ دهد و ممکن است نشان‌دهندهٔ پیکربندی نادرست کلاینت باشد. با این حال، از آنجا که کلاینت رهاکنندهٔ پیشوند به هر حال استفاده از آن را متوقف خواهد کرد، احتمال زیادی وجود دارد که این وضعیت به خودی خود اصلاح شود. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های دوم و سوم پیشوند و طول آن را مشخص می‌کنند. آرگومان آخر حاوی DUID کلاینتی است که اجاره را در اختیار دارد.
DHCP6_RELEASE_PD_FAIL_WRONG_IAID
0.0
3.5
%1: client tried to release prefix %2/%3, but it used wrong IAID (expected %4, but got %5)
168u
168u
این پیام هشدار نشان می‌دهد که کلاینت برای آزادسازی پیشوندی تلاش کرده است که متعلق به خود اوست، اما انتظار می‌رفت نشانی در یک ظرف IA (انجمن هویت) متفاوتی قرار داشته باشد. این امر احتمالاً به این معنی است که پشتیبانی کلاینت از چندین پیشوند دارای ایراد است. آرگومان اول شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان‌های دوم و سوم پیشوند را مشخص می‌کنند. آرگومان‌های چهارم و پنجم به ترتیب حاوی IAID مورد انتظار و IAID دریافت‌شده هستند..SS DHCP6_REQUIRED_OPTIONS_CHECK_FAIL
0.0
3.5
%1: %2 message received from %3 failed the following check: %4
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام نشان می‌دهد که بستهٔ DHCPv6 دریافت‌شده نامعتبر است. این امر ممکن است به دلایل
متعددی رخ داده باشد؛ برای نمونه، گزینهٔ اجباری client-id وجود ندارد،
گزینهٔ server-id که در آن نوع خاص از پیام ممنوع است درج شده،
بیش از یک نمونه از client-id یا server-id وجود دارد
و غیره. علت دقیق رد شدن بسته در پیام گنجانده شده است.
DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED
0.0
3.5
Multi-threading is enabled and host reservations lookup is always performed first.
168u
168u
این پیامی است که اطلاع می‌دهد با فعال بودن چندنخی (multi-threading)، جستجوی رزروهای
میزبان همواره پیش از جستجوی اجاره (lease) انجام می‌شود و مقدار پیکربندی‌شده را بازنویسی می‌کند.
DHCP6_RESPONSE_DATA
0.0
3.5
%1: responding with packet %2 (type %3), packet details: %4
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
پیام اشکال‌زدایی شامل داده‌های تفصیلی بسته‌ای که به کلاینت فرستاده می‌شود.
آرگومان اول حاوی اطلاعات شناسایی کلاینت و تراکنش است.
آرگومان دوم و سوم به‌ترتیب حاوی نام و نوع بسته هستند.
آرگومان چهارم شامل اطلاعات تفصیلی بسته است.
DHCP6_ROOT_USER_SECURITY_WARNING
0.0
3.5
kea-dhcp6 running as root user!
168u
168u
این هشدار زمانی صادر می‌شود که kea-dhcp6 با کاربر root در حال اجرا باشد.
اگرچه سرور عملکرد کاملی خواهد داشت، این حالت کاربری ممکن است محیط شما را
در معرض آسیب‌پذیری‌های امنیتی قرار دهد و تنها باید پس از بررسی دقیق
استفاده شود.
DHCP6_SECURITY_CHECKS_DISABLED
0.0
3.5
Invoked with command line option -X, Security checks are disabled!!
168u
168u
این هشدار زمانی صادر می‌شود که بررسی‌های امنیتی داخلی که معمولاً توسط
kea-dhcp6 انجام می‌شوند، از طریق گزینهٔ خط فرمان '-X' غیرفعال شده باشند.
این بدان معناست که سرور هیچ‌گونه محدودیتی را بر روی مسیرهای منابع یا
مجوزها اعمال نمی‌کند. این حالت کاربری ممکن است محیط شما را در معرض
آسیب‌پذیری‌های امنیتی قرار دهد و تنها باید پس از بررسی دقیق استفاده شود.
DHCP6_SERVER_FAILED
0.0
3.5
server failed: %1
168u
168u
سرور DHCP در IPv6 با یک خطای مهلک مواجه شده و در حال خاتمه است.
علت این شکست در متن پیام ذکر شده است.
DHCP6_SHUTDOWN
0.0
3.5
server shutdown
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
سرور DHCP در IPv6 به‌طور عادی خاتمه یافته است.
DHCP6_SHUTDOWN_REQUEST
0.0
3.5
shutdown of server requested
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که خاموش‌سازی سرور IPv6 از طریق
فراخوانی متد 'shutdown' از شیء اصلی Dhcpv6Srv درخواست شده است.
DHCP6_SRV_CONSTRUCT_ERROR
0.0
3.5
error creating Dhcpv6Srv object, reason: %1
168u
168u
این پیام خطا نشان می‌دهد که در هنگام راه‌اندازی، ساخت یک مؤلفهٔ اصلی در
سرور DHCP در IPv6 (شیء سرور Dhcpv6) با شکست مواجه شده است.
در نتیجه، سرور خارج خواهد شد. علت این شکست در متن پیام ذکر شده است..SS DHCP6_SRV_D2STOP_ERROR
0.0
3.5
error stopping IO with DHCP_DDNS during shutdown: %1
168u
168u
این پیام خطا نشان می‌دهد که هنگام خاموش شدن، در زمان متوقف کردن IO میان کارگزار DHCPv6 و کارگزار DHCP_DDNS خطایی رخ داده است. این امر احتمالاً به دلیل یک خطای برنامه‌نویسی است و بعید است پس از راه‌اندازی مجدد، بر هیچ‌یک از کارگزارها تأثیر بگذارد. علت شکست در متن پیام ذکر شده است.
DHCP6_SRV_UNLOAD_LIBRARIES_ERROR
0.0
3.5
error unloading hooks libraries during shutdown: %1
168u
168u
این پیام خطا نشان می‌دهد که هنگام خاموش شدن، تخلیه کتابخانه‌های hooks در بستن آن‌ها با شکست مواجه شده است. اگر فهرست کتابخانه‌ها خالی باشد، این یک خطای برنامه‌نویسی در کد کارگزار است. اگر خالی نباشد، می‌تواند یک خطای برنامه‌نویسی در یکی از کتابخانه‌های hooks باشد که ممکن است به فروپاشی (crash) در حین نهایی‌سازی بیانجامد.
DHCP6_STARTED
0.0
3.5
Kea DHCPv6 server version %1 started
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کارگزار DHCPv6 تمام اطلاعات پیکربندی را پردازش کرده و آمادهٔ پردازش بسته‌های DHCPv6 است. نسخهٔ برنامه نیز چاپ می‌شود.
DHCP6_STARTING
0.0
3.5
Kea DHCPv6 server version %1 (%2) starting
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کارگزار DHCPv6 تمام گزینه‌های خط فرمان را پردازش کرده و در حال راه‌اندازی است. نسخهٔ برنامه نیز چاپ می‌شود.
DHCP6_START_INFO
0.0
3.5
pid: %1, server port: %2, client port: %3, verbose: %4
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 0 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هنگام راه‌اندازی کارگزار DHCPv6 صادر می‌شود. این پیام اطلاعاتی را دربارهٔ پارامترهایی که کارگزار با آن‌ها در حال اجرا است، فهرست می‌کند.
DHCP6_SUBNET_DATA
0.0
3.5
%1: the selected subnet details: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 55 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات زیرشبکهٔ (subnet) انتخاب‌شده برای کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم شامل جزئیات زیرشبکه است.
DHCP6_SUBNET_DYNAMICALLY_CHANGED
0.0
3.5
%1: changed selected subnet %2 to subnet %3 from shared network %4 for client assignments
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 45 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که کارگزار برای تخصیص‌های کلاینت از زیرشبکهٔ دیگری به غیر از آنچه در ابتدا انتخاب شده بود، استفاده می‌کند. این زیرشبکهٔ تازه انتخاب‌شده به همان شبکهٔ مشترک (shared network) زیرشبکهٔ اولیه تعلق دارد. برخی از دلایل انتخاب زیرشبکهٔ جدید عبارت‌اند از: اتمام استخر آدرس (address pool) در زیرشبکهٔ اولیه یا این واقعیت که زیرشبکهٔ جدید شامل رزروهای ایستا (static reservations) برای این کلاینت است.
DHCP6_SUBNET_SELECTED
0.0
3.5
%1: the subnet with ID %2 was selected for client assignments
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 45 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که انتخاب یک زیرشبکه را برای استفاده در تخصیص آدرس و گزینه‌ها مشخص می‌کند. انتخاب زیرشبکه یکی از نخستین مراحل در پردازش پیام‌های دریافتی از کلاینت است. آرگومان نخست شامل اطلاعات شناسایی کلاینت و تراکنش است. آرگومان دوم حاوی شناسهٔ (ID) زیرشبکهٔ انتخاب‌شده است.
DHCP6_SUBNET_SELECTION_FAILED
0.0
3.5
%1: failed to select subnet for the client
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 50 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که کارگزار در انتخاب زیرشبکه برای کلاینتی که پیامی به کارگزار فرستاده، با شکست مواجه شده است. علت احتمالاً به دلیل پیکربندی نادرست کارگزار است. پردازش بسته ادامه خواهد یافت، اما پاسخ تنها حاوی پیکربندی عمومی خواهد بود و هیچ آدرس یا پیشوندی را شامل نمی‌شود. آرگومان شامل اطلاعات شناسایی کلاینت و تراکنش است..SS DHCP6_UNKNOWN_MSG_RECEIVED
0.0
3.5
%1: received unknown message (type %2) on interface %3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که سرور پیامی از نوع ناشناخته دریافت کند.
این موضوع می‌تواند بیانگر نبود یک قابلیت یا یک کلاینت یا رلهٔ نامعتبر یا معیوب باشد.
فهرست انواع پیام‌های تعریف‌شده به‌صورت رسمی در اینجا در دسترس است:
http://www.iana.org/assignments/dhcpv6-parameters.
DHCP6_USING_SERVERID
0.0
3.5
server is using server-id %1 and stores in the file %2
168u
168u
این پیام اطلاعاتی زمانی ثبت می‌شود که سرور server-id خود را از یک فایل بخواند یا
آن را تولید کند. این پیام اعلانی به مدیر سیستم است که چه server-id استفاده
خواهد شد و در کجا ذخیره و نگهداری می‌شود. معمولاً نیازی به تغییر server id نیست.
با این وجود، انجام این کار در فایل پیکربندی Kea امکان‌پذیر است. درک پیامدهای
چنین تغییری بسیار مهم است. کلاینت‌ها server-id پیشین را به خاطر خواهند سپرد و
از آن برای تمدید اجاره‌هایشان (leases) استفاده خواهند کرد. در نتیجه، آن‌ها برای
دریافت مجدد اجاره‌های خود و انتساب آن‌ها به یک server id جدید، ناچار خواهند بود
مرحلهٔ پیوند دوباره (rebinding) را طی کنند.
DHCPSRV
DHCPSRV_CFGMGR_ADD_IFACE
0.0
3.5
listening on interface %1
168u
168u
پیامی اطلاعاتی که هنگام افزوده شدن یک رابط جدید به مجموعه رابط‌هایی که سرور
روی آن‌ها به پیام‌های DHCP گوش می‌دهد، صادر می‌شود.
DHCPSRV_CFGMGR_ADD_SUBNET4
0.0
3.5
adding subnet %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که زمانی گزارش می‌شود که مدیر پیکربندی DHCP در حال افزودن
ساب‌نت IPv4 مشخص‌شده به پایگاه دادهٔ خود است.
DHCPSRV_CFGMGR_ADD_SUBNET6
0.0
3.5
adding subnet %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که زمانی گزارش می‌شود که مدیر پیکربندی DHCP در حال افزودن
ساب‌نت IPv6 مشخص‌شده به پایگاه دادهٔ خود است.
DHCPSRV_CFGMGR_ALL_IFACES_ACTIVE
0.0
3.5
enabling listening on all interfaces
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور پیکربندی شده باشد تا روی همهٔ
رابط‌ها گوش فرا دهد.
DHCPSRV_CFGMGR_CFG_DHCP_DDNS
0.0
3.5
Setting DHCP-DDNS configuration to: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تنظیمات DHCP-DDNS سرور تغییر می‌کند.
DHCPSRV_CFGMGR_CONFIG4_MERGED
0.0
3.5
Configuration backend data has been merged.
168u
168u
این یک پیام اطلاعاتی است و زمانی صادر می‌شود که سرور DHCPv4 داده‌های پیکربندی
دریافت‌شده از بک‌اندهای پیکربندی خود را با موفقیت در پیکربندی فعلی ادغام
کرده باشد.
DHCPSRV_CFGMGR_CONFIG6_MERGED
0.0
3.5
Configuration backend data has been merged.
168u
168u
این یک پیام اطلاعاتی است و زمانی صادر می‌شود که سرور DHCPv6 داده‌های پیکربندی
دریافت‌شده از بک‌اندهای پیکربندی خود را با موفقیت در پیکربندی فعلی ادغام
کرده باشد..SS DHCPSRV_CFGMGR_CONFIGURE_SERVERID
0.0
3.5
server configuration includes specification of a server identifier
168u
168u
این پیام هشدار زمانی صادر می‌شود که پیکربندی سرور شامل مشخص‌سازی یک شناسه سرور (server identifier) باشد. اگر این پیکربندی جدید یک server identifier موجود را بازنویسی کند، بر پیوندهای (bindings) فعلی کلاینت‌ها تأثیر خواهد گذاشت. کلاینت‌ها هنگام تمدید پیوندهای خود از server identifier قدیمی استفاده خواهند کرد. سرور به این تمدیدها پاسخ نخواهد داد و کلاینت‌ها در نهایت به وضعیت rebinding منتقل خواهند شد. سرور باید پیوندهای موجود را مجدداً تخصیص دهد و کلاینت‌ها پس از آن از server identifier جدید استفاده خواهند کرد. توصیه می‌شود server identifier را تغییر ندهید، مگر اینکه دلیل موجهی برای آن وجود داشته باشد، تا از افزایش تعداد تمدیدها و نیاز به rebinding (افزایش ترافیک چندپخشی یا multicast، که ممکن است توسط چندین سرور دریافت شود) جلوگیری گردد.
DHCPSRV_CFGMGR_DEL_SUBNET4
0.0
3.5
IPv4 subnet %1 removed
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک زیرشبکه (subnet) با موفقیت از پیکربندی سرور حذف شود. آرگومان، زیرشبکه حذف‌شده را مشخص می‌کند.
DHCPSRV_CFGMGR_DEL_SUBNET6
0.0
3.5
IPv6 subnet %1 removed
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک زیرشبکه (subnet) با موفقیت از پیکربندی سرور حذف شود. آرگومان، زیرشبکه حذف‌شده را مشخص می‌کند.
DHCPSRV_CFGMGR_FLQ_POPULATE_FREE_ADDRESS_LEASES
0.0
3.5
populating free address leases for the FLQ allocator in subnet %1; it can take a while!
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که سرور شروع به ساخت یک صف از اجاره‌های آدرس (address leases) آزاد برای زیرشبکه مشخص‌شده می‌کند. این کار بسته به اندازه استخرهای آدرس (address pools)، می‌تواند زمان قابل توجهی ببرد.
DHCPSRV_CFGMGR_FLQ_POPULATE_FREE_ADDRESS_LEASES_DONE
0.0
3.5
populated %1 free address leases for the FLQ allocator in subnet %2 in %3
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که سرور ساخت صف اجاره‌های آدرس آزاد را برای یک زیرشبکه مشخص به پایان می‌رساند. آرگومان نخست تعداد اجاره‌های آزاد، آرگومان دوم زیرشبکه، و آرگومان سوم مدت‌زمان را ثبت می‌کند.
DHCPSRV_CFGMGR_FLQ_POPULATE_FREE_PREFIX_LEASES
0.0
3.5
populating free prefix leases for the FLQ allocator in subnet %1; it can take a while!
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که سرور شروع به ساخت یک صف از اجاره‌های آزاد برای زیرشبکه مشخص‌شده می‌کند. این کار بسته به اندازه استخرهای پیشوند واگذارشده (delegated prefix pools)، می‌تواند زمان قابل توجهی ببرد.
DHCPSRV_CFGMGR_FLQ_POPULATE_FREE_PREFIX_LEASES_DONE
0.0
3.5
populated %1 free prefix leases for the FLQ allocator in subnet %2 completed in %3
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که سرور ساخت صف اجاره‌های پیشوند آزاد را برای یک زیرشبکه مشخص به پایان می‌رساند. آرگومان نخست تعداد اجاره‌های آزاد، آرگومان دوم زیرشبکه، و آرگومان سوم مدت‌زمان را ثبت می‌کند.
DHCPSRV_CFGMGR_IPV4_RESERVATIONS_NON_UNIQUE_IGNORED
0.0
3.5
ignoring "ip-reservations-unique" setting because at least one of the host database backends does not support non-unique IP reservations in a subnet
168u
168u
این پیام هشدار زمانی صادر می‌شود که سرور در استفاده از تنظیم جدید پارامتر سراسری ip-reservations-unique که از طریق بک‌اند پیکربندی (configuration backend) پیکربندی شده است، ناموفق باشد. ظاهراً برخی از بک‌اندهای پایگاه‌داده میزبان (host database backends) مورد استفاده از تعیین چندین رزرو برای یک آدرس IP یکسان در یک زیرشبکه پشتیبانی نمی‌کنند. مدیر سیستم برای رفع این مشکل پیکربندی باید یا استفاده از بک‌اندی را که از این تنظیم پشتیبانی نمی‌کند متوقف سازد یا مقدار ip-reservations-unique را برابر با true قرار دهد.
DHCPSRV_CFGMGR_IPV6_RESERVATIONS_NON_UNIQUE_IGNORED
0.0
3.5
ignoring "ip-reservations-unique" setting because at least one of the host database backends does not support non unique IP reservations in a subnet
168u
168u
این پیام هشدار زمانی صادر می‌شود که سرور در استفاده از تنظیم جدید پارامتر سراسری ip-reservations-unique که از طریق بک‌اند پیکربندی (configuration backend) پیکربندی شده است، ناموفق باشد. ظاهراً برخی از بک‌اندهای پایگاه‌داده میزبانِ مورد استفاده از تعیین چندین رزرو برای یک آدرس IP یکسان یا پیشوند واگذارشده (delegated prefix) در یک زیرشبکه پشتیبانی نمی‌کنند. مدیر سیستم برای رفع این مشکل پیکربندی باید یا استفاده از بک‌اندی را که از این تنظیم پشتیبانی نمی‌کند متوقف سازد یا مقدار ip-reservations-unique را برابر با true قرار دهد..SS DHCPSRV_CFGMGR_IP_RESERVATIONS_UNIQUE_DUPLICATES_DETECTED
0.0
3.5
the "ip-reservations-unique" flag is set to true and multiple reservations for the IP address %1 in subnet %2 are not allowed causing error: %3
168u
168u
این پیام هشدار زمانی صادر می‌شود که کارگزار DHCP طوری پیکربندی شده باشد که رزروهای چندگانه را برای یک نشانی IP یکسان مجاز نداند. با این حال، بک‌اند پایگاه‌داده میزبان شامل چندین رزرو برای نشانی IP ثبت‌شده به عنوان آرگومان نخست، در زیرشبکه ثبت‌شده به عنوان آرگومان دوم است که باعث ایجاد مشکلاتی در تخصیص اجاره ثبت‌شده به عنوان آرگومان سوم می‌شود.
DHCPSRV_CFGMGR_IP_RESERVATIONS_UNIQUE_DUPLICATES_POSSIBLE
0.0
3.5
setting "ip-reservations-unique" from false to true poses a risk that some host backends may still contain multiple reservations for the same IP address
168u
168u
این پیام هشدار زمانی صادر می‌شود که کارگزار DHCP طوری پیکربندی شده باشد که رزروهای چندگانه را برای یک نشانی IP یکسان مجاز نداند. با این حال، بک‌اندهای پایگاه‌داده میزبان ممکن است همچنان شامل چندین رزرو برای نشانی‌های IP یکسان باشند که سبب ایجاد مشکلاتی در تخصیص اجاره برای برخی نشانی‌ها می‌شود. لطفاً اطمینان حاصل کنید که تمام این موارد تکراری حذف شوند.
DHCPSRV_CFGMGR_NEW_SUBNET4
0.0
3.5
a new subnet has been added to configuration: %1
168u
168u
این یک پیام اطلاع‌رسانی است که گزارش می‌دهد پیکربندی برای در بر گرفتن زیرشبکه IPv4 مشخص‌شده گسترش یافته است.
DHCPSRV_CFGMGR_NEW_SUBNET6
0.0
3.5
a new subnet has been added to configuration: %1
168u
168u
این یک پیام اطلاع‌رسانی است که گزارش می‌دهد پیکربندی برای در بر گرفتن زیرشبکه مشخص‌شده گسترش یافته است.
DHCPSRV_CFGMGR_OPTION_DEFINITION_MISMATCH
0.0
3.5
failed to create option: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که گزینه‌ای مشخص شده باشد که تعریف گزینه مناسبی برای آن وجود ندارد. یا اصلاً تعریفی وجود ندارد یا محتوای گزینه با تعریف گزینه همخوانی ندارد. این آرگومان دلیل تفصیلی شکست را ارائه می‌دهد. کارگزار به کار خود ادامه خواهد داد اما تا زمان اصلاح وضعیت، این گزینه را از پردازش بسته‌ها کنار می‌گذارد. این مورد یک خطای پیکربندی محسوب می‌شود.
DHCPSRV_CFGMGR_OPTION_DUPLICATE
0.0
3.5
multiple options with the code: %1 added to the subnet: %2
168u
168u
این پیام هشدار هنگام تلاش برای پیکربندی چند گزینه با یک کد گزینه یکسان برای یک زیرشبکه خاص صادر می‌شود. افزودن گزینه‌های چندگانه برای DHCPv6 غیرمعمول است، اما ممنوع نیست.
DHCPSRV_CFGMGR_RENEW_GTR_REBIND
0.0
3.5
in %1, the value of renew-timer %2 is greater than the value of rebind-timer %3, ignoring renew-timer
168u
168u
یک پیام هشدار که نشان می‌دهد مقدار renew-timer پیکربندی‌شده از مقدار rebind-timer پیکربندی‌شده بزرگ‌تر است. کارگزار مقدار renew timer را نادیده می‌گیرد و فقط مقدار rebind timer را ارسال خواهد کرد. این مورد یک خطای پیکربندی غیرمهلک در نظر گرفته می‌شود.
DHCPSRV_CFGMGR_SOCKET_RAW_UNSUPPORTED
0.0
3.5
use of raw sockets is unsupported on this OS, UDP sockets will be used
168u
168u
این پیام هشدار زمانی ثبت می‌شود که کاربر مشخص کرده باشد کارگزار DHCPv4 باید از سوکت‌های خام (raw sockets) برای دریافت پیام‌های DHCP و پاسخ به کلاینت‌ها استفاده کند، اما استفاده از سوکت‌های خام در آن محیط خاص پشتیبانی نمی‌شود. سوکت‌های خام زمانی مفید هستند که کارگزار باید به کلاینت‌های مستقیماً متصل‌شده‌ای که هنوز نشانی ندارند پاسخ دهد. اگر سوکت‌های خام توسط Kea در آن پلتفرم خاص پشتیبانی نشود، Kea به استفاده از سوکت‌های IP/UDP بازمی‌گردد. پاسخ‌ها به کلاینت‌های مستقیماً متصل، همه‌پخشی (broadcast) خواهد بود. پاسخ‌ها به کلاینت‌های بازپخش‌شده (relayed) مانند معمول تک‌پخشی (unicast) خواهد بود.
DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT
0.0
3.5
"dhcp-socket-type" not specified , using default socket type %1
168u
168u
این پیام اطلاع‌رسانی زمانی ثبت می‌شود که مدیر سیستم پارامتر "dhcp-socket-type" را در پیکربندی رابط‌ها مشخص نکرده باشد. در چنین حالتی، نوع سوکت پیش‌فرض استفاده خواهد شد..SS DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT
0.0
3.5
using socket type %1
168u
168u
این پیام اطلاعاتی زمانی ثبت می‌شود که کارگزار DHCPv4 نوع سوکت (socket type) مورد استفاده برای تمامی سوکت‌هایی که روی رابط‌ها باز خواهند شد را انتخاب کند. به‌طور معمول، نوع سوکت توسط مدیر کارگزار تعیین می‌شود. اگر نوع سوکت مشخص نشده باشد، raw socket انتخاب خواهد شد. چنانچه raw socket انتخاب شده باشد اما Kea از استفاده از raw socketها روی آن سیستم‌عامل به‌خصوص پشتیبانی نکند، به‌جای آن از یک UDP socket استفاده خواهد کرد.
DHCPSRV_CFGMGR_SUBNET4
0.0
3.5
retrieved subnet %1 for address hint %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP با توجه به نشانی پیشنهادی (address hint) مشخص‌شده، زیرشبکهٔ IPv4 مربوطه را بازگردانده است، چرا که نشانی در محدودهٔ این زیرشبکه قرار دارد.
DHCPSRV_CFGMGR_SUBNET4_ADDR
0.0
3.5
selected subnet %1 for packet received by matching address %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP زیرشبکهٔ IPv4 مشخص‌شده را برای یک بستهٔ دریافتی بازگردانده است. این زیرشبکهٔ به‌خصوص از آن جهت انتخاب شد که نشانی IPv4 تطبیق‌یافته متعلق به این زیرشبکه بود.
DHCPSRV_CFGMGR_SUBNET4_IFACE
0.0
3.5
selected subnet %1 for packet received over interface %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP زیرشبکهٔ IPv4 مشخص‌شده را برای بسته‌ای که از رابط داده‌شده دریافت شده، بازگردانده است. این زیرشبکهٔ به‌خصوص به این دلیل انتخاب شده که مشخص شده بود مستقیماً از طریق رابط داده‌شده قابل دسترسی است (پارامتر 'interface' در تعریف subnet4 را ببینید).
DHCPSRV_CFGMGR_SUBNET4_RELAY
0.0
3.5
selected subnet %1, because of matching relay addr %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP زیرشبکهٔ IPv4 مشخص‌شده را بازگردانده است، زیرا نشانیِ عامل رله (relay agent) شناسایی‌شده با مقدار مشخص‌شده برای این زیرشبکه مطابقت دارد.
DHCPSRV_CFGMGR_SUBNET6
0.0
3.5
retrieved subnet %1 for address hint %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP با توجه به نشانی پیشنهادی (address hint) مشخص‌شده، زیرشبکهٔ IPv6 مربوطه را بازگردانده است، چرا که نشانی در محدودهٔ این زیرشبکه قرار دارد.
DHCPSRV_CFGMGR_SUBNET6_IFACE
0.0
3.5
selected subnet %1 for packet received over interface %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP زیرشبکهٔ IPv6 مشخص‌شده را برای بسته‌ای که از رابط داده‌شده دریافت شده، بازگردانده است. این زیرشبکهٔ به‌خصوص به این دلیل انتخاب شد که مشخص شده بود مستقیماً از طریق رابط داده‌شده قابل دسترسی است (پارامتر 'interface' در تعریف subnet6 را ببینید).
DHCPSRV_CFGMGR_SUBNET6_IFACE_ID
0.0
3.5
selected subnet %1 (interface-id match) for incoming packet
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP زیرشبکهٔ IPv6 مشخص‌شده را برای یک بستهٔ دریافتی بازگردانده است. این زیرشبکهٔ به‌خصوص به این دلیل انتخاب شد که مقدار گزینهٔ interface-id با مقدار پیکربندی‌شده در گزینهٔ interface-id کارگزار برای آن subnet6 انتخاب‌شده مطابقت داشت (پارامتر 'interface-id' در تعریف subnet6 را ببینید)..SS DHCPSRV_CFGMGR_SUBNET6_RELAY
0.0
3.5
selected subnet %1, because of matching relay addr %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که گزارش می‌دهد مدیر پیکربندی DHCP، زیرشبکهٔ IPv6 مشخص‌شده را بازگردانده است، زیرا نشانی عامل رله (relay agent) شناسایی‌شده با مقدار مشخص‌شده برای این زیرشبکه مطابقت دارد.
DHCPSRV_CFGMGR_UNICAST_LINK_LOCAL
0.0
3.5
specified link local address %1 for unicast traffic on interface %2
168u
168u
این پیام هشدار زمانی ثبت می‌شود که کاربر یک نشانی پیوند-محلی (link-local) را برای دریافت ترافیک تک‌پخشی (unicast) مشخص کرده باشد. این پیام هشدار به دلیل غیرمعمول بودن چنین کاربردی صادر می‌شود.
DHCPSRV_CFGMGR_UPDATE_SUBNET4
0.0
3.5
updating subnet %1 (result %2)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
یک پیام اشکال‌زدایی که هنگام به‌روزرسانی زیرشبکهٔ IPv4 مشخص‌شده در پیکربندی فعلی توسط مدیر پیکربندی DHCP گزارش می‌شود. شناسهٔ زیرشبکه (Subnet ID) و نتیجه (که انتظار می‌رود true باشد) نمایش داده می‌شوند.
DHCPSRV_CFGMGR_UPDATE_SUBNET6
0.0
3.5
updating subnet %1 (result %2)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
یک پیام اشکال‌زدایی که هنگام جایگزینی زیرشبکهٔ IPv6 مشخص‌شده در پیکربندی فعلی توسط مدیر پیکربندی DHCP گزارش می‌شود. شناسهٔ زیرشبکه و نتیجه (که انتظار می‌رود true باشد) نمایش داده می‌شوند.
DHCPSRV_CFGMGR_USE_ADDRESS
0.0
3.5
listening on address %1, on interface %2
168u
168u
پیامی که وقتی سرور برای شنود روی نشانی IP صریحاً مشخص‌شده در واسط (interface) داده‌شده پیکربندی شده باشد، صادر می‌شود.
DHCPSRV_CFGMGR_USE_ALLOCATOR
0.0
3.5
using the %1 allocator for %2 leases in subnet %3
168u
168u
پیامی که هنگام آغاز استفادهٔ مدیر پیکربندی از یک تخصیص‌دهندهٔ (allocator) مشخص برای یک زیرشبکه صادر می‌شود.
DHCPSRV_CFGMGR_USE_UNICAST
0.0
3.5
listening on unicast address %1, on interface %2
168u
168u
یک پیام اطلاع‌رسانی (info) که هنگام پیکربندی سرور DHCP برای شنود روی نشانی تک‌پخشی (unicast) در واسط مشخص صادر می‌شود.
DHCPSRV_CLASS_WITH_ADDITIONAL_AND_LIFETIMES
0.0
3.5
class: %1 has 'only-in-additional-list' true while specifying one or more lease life time values. Life time values will be ignored.
168u
168u
این هشدار زمانی صادر می‌شود که کلاسی با 'only-in-addition-list' برابر با true پیکربندی شده باشد و هم‌زمان یک یا چند پارامتر طول عمر اجاره (مانند 'valid-lifetime'، 'preferred-lifetime' یا 'offer-lifetime') را تعیین کند. کلاس‌های فهرست الحاقی (additional list) پس از تخصیص اجاره ارزیابی می‌شوند؛ بنابراین پارامترهایی که در غیر این صورت بر طول عمر اجاره تأثیر می‌گذاشتند، هیچ اثری نخواهند داشت.
DHCPSRV_CLIENT_CLASS_DEPRECATED
0.0
3.5
The parameter 'client-class' is deprecated. Use 'client-classes' list parameter instead
168u
168u
این پیام هشدار زمانی صادر می‌شود که تجزیهٔ پیکربندی، استفاده از پارامتر منسوخ‌شدهٔ 'client-class' را تشخیص دهد. این پارامتر با 'client-classes' جایگزین شده است. کاربران باید به پارامتر فهرستی جدید مهاجرت کنند..SS DHCPSRV_CLOSE_DB
0.0
3.5
closing currently open %1 database
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که سرور DHCP پایگاه‌دادهٔ اجاره‌های در حال حاضر باز را می‌بندد. این پیام هنگام خاموش شدن برنامه و هر زمان که پارامترهای دسترسی به پایگاه‌داده تغییر کنند، صادر می‌شود: در حالت دوم، سرور پایگاه‌دادهٔ باز فعلی را بسته و پایگاه‌داده‌ای را با استفاده از پارامترهای جدید باز می‌کند.
DHCPSRV_DDNS_TTL_TOO_LARGE
0.0
3.5
%1 of lease life time %2 is %3, using maximum of %4 instead.
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که مقدار DDNS TTL محاسبه‌شده با استفاده از ddns-ttl-percent (در صورت تعیین) یا (0.33 در صورت عدم تعیین)، از مقدار مشخص‌شدهٔ ddns-ttl-max بزرگ‌تر باشد. Kea این مقدار را نادیده گرفته و در عوض از حداکثر مشخص‌شده استفاده می‌کند. جزئیات پیام شامل درصد، طول عمر اجاره، TTL محاسبه‌شده و مقدار استفاده‌شدهٔ واقعی است.
DHCPSRV_DDNS_TTL_TOO_SMALL
0.0
3.5
%1 of lease life time %2 is %3, using minimum of %4 instead.
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که مقدار DDNS TTL محاسبه‌شده با استفاده از ddns-ttl-percent (در صورت تعیین) یا (0.33 در صورت عدم تعیین)، بیش از حد کوچک باشد. Kea این مقدار را نادیده گرفته و از حداقل (ddns-ttl-min در صورت تعیین، یا 600 ثانیه در صورت عدم تعیین) استفاده می‌کند. جزئیات پیام شامل درصد، طول عمر اجاره، TTL محاسبه‌شده و مقدار استفاده‌شدهٔ واقعی است.
DHCPSRV_DHCP4O6_RECEIVED_BAD_PACKET
0.0
3.5
received bad DHCPv4o6 packet: %1
168u
168u
یک بستهٔ نامعتبر DHCPv4o6 دریافت شد.
DHCPSRV_DHCP_DDNS_ERROR_EXCEPTION
0.0
3.5
error handler for DHCP_DDNS IO generated an expected exception: %1
168u
168u
این یک پیام خطا است و زمانی رخ می‌دهد که تلاش برای ارسال درخواست به kea-dhcp-ddns ناموفق باشد و گردانندهٔ خطای ثبت‌شده، یک استثنای مدیریت‌نشده ایجاد کند. این یک خطای برنامه‌نویسی است که نباید رخ دهد. طبق قرارداد، گردانندهٔ خطا نباید استثناها را انتشار دهد. لطفاً این خطا را گزارش دهید.
DHCPSRV_DHCP_DDNS_HANDLER_NULL
0.0
3.5
error handler for DHCP_DDNS IO is not set.
168u
168u
این یک پیام خطا است و زمانی رخ می‌دهد که تلاش برای ارسال درخواست به kea-dhcp-ddns ناموفق باشد و هیچ گردانندهٔ خطایی ثبت نشده باشد. این یک خطای برنامه‌نویسی است که هرگز نباید رخ دهد و باید گزارش شود.
DHCPSRV_DHCP_DDNS_NCR_REJECTED
0.0
3.5
NameChangeRequest rejected by the sender: %1, ncr: %2
168u
168u
این یک پیام خطا است و نشان می‌دهد NameChangeSender که برای تحویل درخواست‌های به‌روزرسانی DDNS به kea-dhcp-ddns استفاده می‌شود، درخواست را رد کرده است. محتمل‌ترین علت این است که صف فرستنده به حداکثر ظرفیت خود رسیده باشد. این بدان معناست که درخواست‌ها سریع‌تر از توانایی تحویل آن‌ها تولید می‌شوند.
DHCPSRV_DHCP_DDNS_NCR_SENT
0.0
3.5
NameChangeRequest sent to kea-dhcp-ddns: %1
168u
168u
در سطح لاگ اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک NameChangeRequest با موفقیت به kea-dhcp-ddns ارسال شده باشد.
DHCPSRV_DHCP_DDNS_SENDER_STARTED
0.0
3.5
NameChangeRequest sender has been started: %1
168u
168u
یک پیام اطلاع‌رسانی که هنگام آغاز موفقیت‌آمیز ارتباط با kea-dhcp-ddns صادر می‌شود..SS DHCPSRV_DHCP_DDNS_SENDER_STOPPED
0.0
3.5
NameChangeRequest sender has been stopped.
168u
168u
پیامی اطلاعاتی که هنگام متوقف شدن ارتباط با kea-dhcp-ddns صادر می‌شود. این وضعیت معمولاً در طول پیکربندی مجدد و به عنوان بخشی از فرایند عادی خاموش شدن رخ می‌دهد. همچنین اگر ارتباطات با kea-dhcp-ddns قطع شود، ممکن است رخ دهد.
DHCPSRV_DHCP_DDNS_SUSPEND_UPDATES
0.0
3.5
DHCP_DDNS updates are being suspended.
168u
168u
این یک پیام هشدار است و نشان می‌دهد که به‌روزرسانی‌های DHCP_DDNS غیرفعال شده‌اند. این حالت تنها در صورتی باید رخ دهد که خطاهای ورودی/خروجی (IO) در ارتباط با kea-dhcp-ddns رخ داده باشد. هرگونه خطایی از این دست باید پیش‌تر همراه با جزئیات در لاگ ثبت شده باشد. بدون مداخله، تلاش دیگری برای برقراری ارتباط با kea-dhcp-ddns انجام نخواهد شد.
DHCPSRV_EVAL_ERROR
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
این پیام خطا نشان می‌دهد که هنگام ارزیابی یک عبارت (expression) از یک client class مشکلی رخ داده است.
توضیحی دربارهٔ مشکل چاپ می‌شود.
DHCPSRV_EVAL_RESULT
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug log level) 50 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت یک client class با موفقیت ارزیابی شده است. نام client class و مقدار حاصل از ارزیابی چاپ می‌شوند.
DHCPSRV_FORENSIC_BACKENDS_REGISTERED
0.0
3.5
the following forensic backend types are available: %1
168u
168u
این پیام اطلاعاتی تمام انواع backendهای فارنزیک (forensic) ممکن را که می‌توان در ثبت وقایع فارنزیک (forensic logging) استفاده کرد، فهرست می‌کند.
DHCPSRV_FORENSIC_BACKEND_DEREGISTER
0.0
3.5
deregistered forensic backend type: %1
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک backend factory از ثبت لغو شده باشد.
دیگر استفاده از backend فارنزیک از این نوع امکان‌پذیر نیست.
DHCPSRV_FORENSIC_BACKEND_REGISTER
0.0
3.5
registered forensic backend type: %1
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک backend factory با موفقیت ثبت شده باشد.
اکنون استفاده از backend فارنزیک از این نوع امکان‌پذیر است.
DHCPSRV_HOOK_LEASE4_RECOVER_SKIP
0.0
3.5
DHCPv4 lease %1 was not recovered from the declined state because a callout set the skip status.
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده روی نقطهٔ قلاب lease4_recover وضعیت مرحلهٔ بعدی را روی SKIP تنظیم کرده باشد. برای این نقطهٔ قلاب خاص، این امر نشان می‌دهد که سرور نباید اجاره (lease) را از وضعیت رد شده (declined) بازیابی کند. سرور اجاره را به همان صورتی که هست در وضعیت رد شده باقی می‌گذارد. سرور در نوبت بعدی اجرای فرایند بازیابی رد (decline recovery)، برای بازیابی آن تلاش خواهد کرد.
DHCPSRV_HOOK_LEASE4_RENEW_SKIP
0.0
3.5
DHCPv4 lease was not renewed because a callout set the skip flag.
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که یک callout نصب‌شده روی نقطهٔ قلاب lease4_renew پرچم skip را تنظیم کرده باشد. برای این نقطهٔ قلاب خاص، تنظیم این پرچم توسط callout به سرور دستور می‌دهد که اجاره را تمدید نکند. سرور از اجارهٔ موجود به همان شکلی که هست، بدون تمدید طول عمر آن استفاده خواهد کرد..SS DHCPSRV_HOOK_LEASE4_SELECT_SKIP
0.0
3.5
Lease4 creation was skipped, because of callout skip flag.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی
نقطه قلاب (hook point) lease4_select پرچم skip را تنظیم کند. این بدان معناست که به
سرور اعلام شده است هیچ lease4 نباید تخصیص داده شود. سرور این اجاره را در
پایگاه‌داده خود قرار نخواهد داد و کلاینت یک بسته NAK دریافت خواهد کرد.
DHCPSRV_HOOK_LEASE6_EXTEND_SKIP
0.0
3.5
DHCPv6 lease lifetime was not extended because a callout set the skip flag for message %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب
lease6_renew یا lease6_rebind پرچم skip را تنظیم کند. برای این نقطه قلاب
به‌خصوص، تنظیم این پرچم توسط callout به سرور دستور می‌دهد که طول عمر اجاره را
تمدید نکند. اگر کلاینت تمدید چندین اجاره را (با ارسال چندین گزینه IA) درخواست
کرده باشد، سرور از تمدید اجاره مورد نظر صرف‌نظر کرده و سایر تمدیدها را طبق روال معمول انجام خواهد داد.
DHCPSRV_HOOK_LEASE6_RECOVER_SKIP
0.0
3.5
DHCPv6 lease %1 was not recovered from declined state because a callout set the skip status.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب
lease6_recover وضعیت مرحله بعد را روی SKIP تنظیم کند. برای این نقطه قلاب به‌خصوص،
این موضوع نشان می‌دهد که سرور نباید اجاره را از وضعیت ردشده (declined) بازیابی کند.
سرور اجاره را همان‌طور که هست، در وضعیت declined رها خواهد کرد. سرور
دفعه بعد که فرایند بازیابی رد انجام شود، دوباره برای بازیابی آن تلاش خواهد کرد.
DHCPSRV_HOOK_LEASE6_SELECT_SKIP
0.0
3.5
Lease6 (non-temporary) creation was skipped, because of callout skip flag.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک callout نصب‌شده روی نقطه قلاب
lease6_select پرچم skip را تنظیم کند. این بدان معناست که به سرور اعلام شده است
هیچ lease6 نباید تخصیص یابد. سرور این اجاره را در پایگاه‌داده خود قرار
نخواهد داد و کلاینت برای آن گزینه IA_NA یک پاسخ NoAddrsAvail دریافت خواهد کرد.
DHCPSRV_HOST_MGR_DB_OPEN_CONNECTION_WITH_RETRY_FAILED
0.0
3.5
Failed to connect to database: %1 with error: %2
168u
168u
این یک پیام اطلاع‌رسانی است و زمانی صادر می‌شود که سرور نتواند به
پایگاه‌داده میزبان متصل شود. این عملیات فرایند تلاش مجدد برای اتصال را آغاز کرده است.
رشته دسترسی به پایگاه‌داده همراه با سانسور گذرواژه، به همراه خطا و
جزئیات مربوط به فرایند اتصال مجدد ثبت می‌شود.
DHCPSRV_LEASE4_EXTENDED_INFO_SANITY_FAIL
0.0
3.5
extended info for lease %1 failed checks (%2)
168u
168u
این پیام خطا زمانی چاپ می‌شود که اطلاعات تکمیلی (extended info) یک اجاره در
بررسی‌های صحت‌سنجی رد شود. جزئیات مشکلِ پیدا شده نمایش داده شده و
اطلاعات تکمیلی از بافت کاربری اجاره (lease user context) حذف می‌شود.
DHCPSRV_LEASE4_EXTENDED_INFO_UPGRADED
0.0
3.5
extended info for lease %1 was upgraded
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که اطلاعات تکمیلی یک اجاره ارتقا یافته باشد.
DHCPSRV_LEASE6_EXTENDED_INFO_SANITY_FAIL
0.0
3.5
extended info for lease %1 failed checks (%2)
168u
168u
این پیام خطا زمانی چاپ می‌شود که اطلاعات تکمیلی (extended info) یک اجاره در
بررسی‌های صحت‌سنجی رد شود. جزئیات مشکلِ پیدا شده نمایش داده شده و
اطلاعات تکمیلی از بافت کاربری اجاره (lease user context) حذف می‌شود.
DHCPSRV_LEASE6_EXTENDED_INFO_UPGRADED
0.0
3.5
extended info for lease %1 was upgraded
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که اطلاعات تکمیلی یک اجاره ارتقا یافته باشد..SS DHCPSRV_LEASE_MGR_BACKENDS_REGISTERED
0.0
3.5
the following lease backend types are available: %1
168u
168u
این پیام اطلاعاتی، تمام پس‌اندهای ممکن برای اجاره را که می‌توان در lease-database استفاده کرد، فهرست می‌کند.
DHCPSRV_LEASE_MGR_BACKEND_DEREGISTER
0.0
3.5
deregistered lease backend type: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک backend factory از حالت ثبت خارج شده باشد.
دیگر امکان استفاده از پس‌اند اجاره از این نوع وجود ندارد.
DHCPSRV_LEASE_MGR_BACKEND_REGISTER
0.0
3.5
registered lease backend type: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک backend factory با موفقیت ثبت شده باشد.
اکنون امکان استفاده از پس‌اند اجاره از این نوع وجود دارد.
DHCPSRV_LEASE_MGR_CALLBACK_EXCEPTION
0.0
3.5
exception occurred in a lease manager callback for callback type %1, subnet id %2, and lease %3: %4
168u
168u
این پیام هشدار زمانی چاپ می‌شود که یکی از توابع بازخوانی (callback) ثبت‌شده در مدیر اجاره (lease manager) باعث بروز خطا شود. توابع بازخوانی می‌توانند اهداف متفاوتی داشته باشند و احتمالاً پیام‌های خطای دقیق‌تری ثبت می‌کنند. این پیام خطا احتمالاً نشان‌دهندهٔ یک خطای رسیدگی‌نشده (unhandled error) است. آرگومان نخست نوع callback را مشخص می‌کند. آرگومان دوم شناسهٔ زیرشبکه (subnet id) را چاپ می‌کند. آرگومان سوم اجاره‌ای را که خطا برای آن رخ داده است چاپ می‌کند. آرگومان آخر متن خطا را نمایش می‌دهد.
DHCPSRV_LEASE_MGR_CALLBACK_UNKNOWN_EXCEPTION
0.0
3.5
unknown exception occurred in a lease manager callback for callback type %1, subnet id %2, and lease %3
168u
168u
این پیام هشدار زمانی چاپ می‌شود که یکی از توابع بازخوانی (callback) ثبت‌شده در مدیر اجاره (lease manager) باعث بروز یک خطای ناشناخته شود. توابع بازخوانی می‌توانند اهداف متفاوتی داشته باشند و احتمالاً پیام‌های خطای دقیق‌تری ثبت می‌کنند. این پیام خطا احتمالاً نشان‌دهندهٔ یک خطای رسیدگی‌نشده است. آرگومان نخست نوع callback را مشخص می‌کند. آرگومان دوم شناسهٔ زیرشبکه (subnet id) را چاپ می‌کند. آرگومان سوم اجاره‌ای را که خطا برای آن رخ داده است چاپ می‌کند. این نگارش از پیام لاگ حاوی متن خطا نیست، زیرا توسط یک استثنای ناشناخته (unknown exception) برانگیخته شده است.
DHCPSRV_LEASE_MGR_DB_OPEN_CONNECTION_WITH_RETRY_FAILED
0.0
3.5
Failed to connect to database: %1 with error: %2
168u
168u
این یک پیام اطلاعاتی است که در صورت عدم موفقیت سرور در اتصال به پایگاه‌دادهٔ اجاره‌ها صادر می‌شود. این عملیات رویهٔ تلاش مجدد برای برقراری اتصال را آغاز کرده است. رشتهٔ دسترسی به پایگاه‌داده همراه با گذرواژهٔ سانسورشده (redacted)، به همراه خطا و جزئیات رویهٔ اتصال مجدد ثبت می‌شود.
DHCPSRV_LEASE_SANITY_FAIL
0.0
3.5
The lease %1 with subnet-id %2 failed subnet-id checks (%3).
168u
168u
این پیام هشدار زمانی چاپ می‌شود که اجارهٔ در حال بارگذاری با پیکربندی مطابقت ندارد. با توجه به مقدار lease-checks، اجاره بارگذاری خواهد شد، اما به احتمال زیاد توسط Kea استفاده نخواهد شد؛ زیرا هیچ زیرشبکه‌ای که با نشانی IP مرتبط با این اجاره همخوانی داشته باشد وجود ندارد.
DHCPSRV_LEASE_SANITY_FAIL_DISCARD
0.0
3.5
The lease %1 with subnet-id %2 failed subnet-id checks (%3) and was dropped.
168u
168u
این پیام هشدار زمانی چاپ می‌شود که یک اجاره بارگذاری شده، اما به Kea دستور داده شده است (با تنظیم پارامتر lease-checks) که اجاره‌های دارای داده‌های ناسازگار را دور بیندازد. اجاره دور انداخته شد، زیرا یا هیچ زیرشبکه‌ای با subnet-id منطبق پیکربندی نشده است، یا نشانیِ اجاره متعلق به آن زیرشبکه نیست.
DHCPSRV_LEASE_SANITY_FIXED
0.0
3.5
The lease %1 with subnet-id %2 failed subnet-id checks, but was corrected to subnet-id %3.
168u
168u
این پیام اطلاعاتی زمانی چاپ می‌شود که یک اجاره بارگذاری شده، اما مقدار subnet-id آن نادرست بوده است. پارامتر lease-checks روی مقداری تنظیم شده بود که به Kea دستور می‌داد برای رفع مشکل تلاش کند. از آنجا که یک زیرشبکهٔ منطبق وجود دارد، Kea مقدار subnet-id را به‌روزرسانی کرده و اجاره را با موفقیت بارگذاری نمود..SS DHCPSRV_MEMFILE_ADD_ADDR4
0.0
3.5
adding IPv4 lease with address %1
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که کارگزار در شرف افزودن یک اجارهٔ IPv4 با نشانی مشخص‌شده به پایگاه‌دادهٔ پشتیبان memory file است.
DHCPSRV_MEMFILE_ADD_ADDR6
0.0
3.5
adding IPv6 lease with address %1
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که کارگزار در شرف افزودن یک اجارهٔ IPv6 با نشانی مشخص‌شده به پایگاه‌دادهٔ پشتیبان memory file است.
DHCPSRV_MEMFILE_BEGIN_BUILD_EXTENDED_INFO_TABLES6
0.0
3.5
building extended info tables with %1 sanity check level, tables %2
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که کارگزار در حال ساخت جدول‌های اطلاعات تکمیلی (extended info) است.
سطح بررسی صحت (sanity check) اطلاعات تکمیلی و فعال یا غیرفعال بودن جدول‌ها نمایش داده می‌شوند.
DHCPSRV_MEMFILE_BEGIN_EXTRACT_EXTENDED_INFO4
0.0
3.5
extract extended info with %1 sanity check level%2
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که کارگزار در حال استخراج اطلاعات تکمیلی است.
سطح بررسی صحت اطلاعات تکمیلی و به‌روزرسانی در فایل در صورت درخواست نمایش داده می‌شوند.
DHCPSRV_MEMFILE_BUILD_EXTENDED_INFO_TABLES6
0.0
3.5
building extended info tables saw %1 leases, extended info sanity checks modified %2 leases and %3 leases were entered into tables
168u
168u
ساخت جدول‌های اطلاعات تکمیلی به پایان رسید. برخی آمارها نمایش داده می‌شوند و وضعیت به‌روزشده در پایگاه‌داده به رابط فرمانی بازگردانده می‌شود.
DHCPSRV_MEMFILE_BUILD_EXTENDED_INFO_TABLES6_ERROR
0.0
3.5
building extended info tables got an exception on the lease for %1: %2
168u
168u
پیام خطایی که زمانی صادر می‌شود که کارگزار در حال ساخت جدول‌های اطلاعات تکمیلی است و در هنگام پردازش یک اجاره با یک استثنا (exception) مواجه می‌شود.
DHCPSRV_MEMFILE_COMMIT
0.0
3.5
committing to memory file database
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
کد یک فراخوانی commit صادر کرده است. برای پایگاه‌دادهٔ memory file، این یک عملیات بی‌اثر (no-op) است.
DHCPSRV_MEMFILE_CONVERTING_LEASE_FILES
0.0
3.5
running LFC now to convert lease files to the current schema: %1.%2
168u
168u
پیام هشداری که زمانی صادر می‌شود که کارگزار فایل‌های اجاره‌ای را شناسایی کرده که برای مطابقت با طرح‌وارهٔ (schema) کارگزار باید ارتقا یا تنزیل یابند، و کارگزار به‌طور خودکار فرایند LFC را برای انجام این تبدیل اجرا می‌کند.
این اتفاق فقط باید در نخستین باری که کارگزار پس از ارتقای نصب Kea (یا تنزیل آن) راه‌اندازی می‌شود رخ دهد.
DHCPSRV_MEMFILE_DB
0.0
3.5
opening memory file lease database: %1
168u
168u
این پیام اطلاع‌رسانی زمانی ثبت می‌شود که یک کارگزار DHCP (چه V4 یا V6) در شرف باز کردن یک پایگاه‌دادهٔ اجارهٔ memory file است. پارامترهای اتصال شامل نام پایگاه‌داده و نام کاربری لازم برای دسترسی به آن (اما نه گذرواژه، در صورت وجود) در لاگ ثبت می‌شوند..SS DHCPSRV_MEMFILE_DELETE_ADDR4
0.0
3.5
deleting lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش برای حذف اجارهٔ آدرس
مشخص‌شده از پایگاه‌دادهٔ فایل حافظه (memfile) است.
DHCPSRV_MEMFILE_DELETE_ADDR6
0.0
3.5
deleting lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش برای حذف اجارهٔ آدرس
مشخص‌شده از پایگاه‌دادهٔ فایل حافظه (memfile) است.
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4
0.0
3.5
deleting reclaimed IPv4 leases that expired more than %1 seconds ago
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال حذف اجاره‌های بازپس‌گرفته‌شدهٔ (reclaimed)
DHCPv4 است که بیش از بازهٔ زمانی مشخصی منقضی شده‌اند.
آرگومان، مدت زمانی است که Kea پس از انقضای یک اجارهٔ بازپس‌گرفته‌شده
پیش از اقدام به حذف آن، منتظر می‌ماند.
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED6
0.0
3.5
deleting reclaimed IPv6 leases that expired more than %1 seconds ago
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال حذف اجاره‌های بازپس‌گرفته‌شدهٔ (reclaimed)
DHCPv6 است که بیش از بازهٔ زمانی مشخصی منقضی شده‌اند.
آرگومان، مدت زمانی است که Kea پس از انقضای یک اجارهٔ بازپس‌گرفته‌شده
پیش از اقدام به حذف آن، منتظر می‌ماند.
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED_START
0.0
3.5
starting deletion of %1 expired-reclaimed leases
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور اجاره‌های منقضی‌شده-بازپس‌گرفته‌شده‌ای را
برای حذف پیدا کرده است. تعداد اجاره‌های قابل حذف در پیام
ثبت می‌شود.
DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4
0.0
3.5
extracting extended info saw %1 leases, extended info sanity checks modified %2 / updated %3 leases and %4 leases have relay or remote id
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
استخراج اطلاعات گسترده (extended info) به پایان رسید. آمارهایی نمایش داده می‌شوند، و
موارد به‌روزشده در پایگاه‌داده به رابط فرمان بازگردانده می‌شوند.
DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4_ERROR
0.0
3.5
extracting extended info got an exception on the lease for %1: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال استخراج اطلاعات گسترده است و
در حین پردازش یک اجاره با یک استثنا (exception) مواجه می‌شود.
DHCPSRV_MEMFILE_FAILED_TO_OPEN
0.0
3.5
Could not open lease file: %1
168u
168u
این خطا زمانی صادر می‌شود که باز کردن فایل اجاره امکان‌پذیر نباشد. آرگومان
شامل جزئیات است. محتمل‌ترین دلیل این است که پارامتر name
برای بک‌اند memfile حاوی مسیری به غیر از مسیر پشتیبانی‌شده باشد.
آرگومان حاوی جزئیات خواهد بود. مؤلفهٔ مسیر را می‌توان به‌سادگی
نادیده گرفت و حذف کرد. برای بازنویسی مسیر پیش‌فرض پشتیبانی‌شده، متغیر
محیطی KEA_DHCP_DATA_DIR را پیش از اجرای سرور تنظیم کنید.
DHCPSRV_MEMFILE_GET4
0.0
3.5
obtaining all IPv4 leases
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش برای دریافت تمام
اجاره‌های IPv4 از پایگاه‌دادهٔ فایل حافظه (memfile) است..SS DHCPSRV_MEMFILE_GET6
0.0
3.5
obtaining all IPv6 leases
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت تمام اجاره‌های IPv6 از پایگاه دادهٔ memory file است.
DHCPSRV_MEMFILE_GET6_DUID
0.0
3.5
obtaining IPv6 leases for DUID %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت اجاره‌های IPv6 برای DUID مربوطه از پایگاه دادهٔ memory file است.
DHCPSRV_MEMFILE_GET_ADDR4
0.0
3.5
obtaining IPv4 lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک اجارهٔ IPv4 از پایگاه دادهٔ memory file برای آدرس مشخص‌شده است.
DHCPSRV_MEMFILE_GET_ADDR6
0.0
3.5
obtaining IPv6 lease for address %1 and lease type %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک اجارهٔ IPv6 از پایگاه دادهٔ memory file برای آدرس مشخص‌شده است.
DHCPSRV_MEMFILE_GET_CLIENTID
0.0
3.5
obtaining IPv4 leases for client ID %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای از اجاره‌های IPv4 از پایگاه دادهٔ memory file برای کلاینتی با شناسهٔ کلاینت مشخص‌شده است.
DHCPSRV_MEMFILE_GET_EXPIRED4
0.0
3.5
obtaining maximum %1 of expired IPv4 leases
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت اجاره‌های منقضی‌شدهٔ IPv4 جهت بازپس‌گیری آن‌ها است. حداکثر تعداد اجاره‌هایی که باید بازیابی شوند در پیام ثبت می‌شود.
DHCPSRV_MEMFILE_GET_EXPIRED6
0.0
3.5
obtaining maximum %1 of expired IPv6 leases
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت اجاره‌های منقضی‌شدهٔ IPv6 جهت بازپس‌گیری آن‌ها است. حداکثر تعداد اجاره‌هایی که باید بازیابی شوند در پیام ثبت می‌شود.
DHCPSRV_MEMFILE_GET_HOSTNAME4
0.0
3.5
obtaining IPv4 leases for hostname %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای از اجاره‌های IPv4 از پایگاه دادهٔ memory file برای کلاینتی با نام میزبان مشخص‌شده است.
DHCPSRV_MEMFILE_GET_HOSTNAME6
0.0
3.5
obtaining IPv6 leases for hostname %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای از اجاره‌های IPv6 از پایگاه دادهٔ memory file برای کلاینتی با نام میزبان مشخص‌شده است..SS DHCPSRV_MEMFILE_GET_HWADDR4
0.0
3.5
obtaining IPv4 leases for hardware address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای از
اجاره‌های IPv4 از پایگاه‌داده فایل حافظه (memory file database) برای کلاینتی با
آدرس سخت‌افزاری مشخص‌شده است.
DHCPSRV_MEMFILE_GET_HWADDR6
0.0
3.5
obtaining IPv6 leases for hardware address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای از
اجاره‌های IPv6 از پایگاه‌داده فایل حافظه (memory file database) برای کلاینتی با
آدرس سخت‌افزاری مشخص‌شده است.
DHCPSRV_MEMFILE_GET_IAID_DUID
0.0
3.5
obtaining IPv6 leases for IAID %1 and DUID %2 and lease type %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای از اجاره‌های IPv6
از پایگاه‌داده فایل حافظه برای کلاینتی با IAID
(شناسه Identity Association) و DUID (شناسه یکتای DHCP) مشخص‌شده است.
DHCPSRV_MEMFILE_GET_IAID_SUBID_DUID
0.0
3.5
obtaining IPv6 leases for IAID %1, Subnet ID %2, DUID %3 and lease type %4
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک
اجاره IPv6 از پایگاه‌داده فایل حافظه برای کلاینتی با IAID
(شناسه Identity Association)، Subnet ID و DUID (شناسه یکتای DHCP) مشخص‌شده است.
DHCPSRV_MEMFILE_GET_PAGE4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک صفحه
از اجاره‌ها با شروع از آدرس مشخص‌شده است.
DHCPSRV_MEMFILE_GET_PAGE6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک صفحه
از اجاره‌ها با شروع از آدرس مشخص‌شده است.
DHCPSRV_MEMFILE_GET_RELAYID4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2 with relay id %3 and cltt between %4 and %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک صفحه از
اجاره‌های IPv4 با شروع از آدرس مشخص‌شده با یک relay id و زمان
تراکنش کلاینت (cltt) بین تاریخ‌های شروع و پایان است.
DHCPSRV_MEMFILE_GET_RELAYID6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 with relay id %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک صفحه از
اجاره‌های IPv6 با شروع از آدرس مشخص‌شده با یک relay id است.
DHCPSRV_MEMFILE_GET_REMOTEID4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2 with remote id %3 and cltt between %4 and %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک صفحه از
اجاره‌های IPv4 با شروع از آدرس مشخص‌شده با یک remote id و
زمان تراکنش کلاینت (cltt) بین تاریخ‌های شروع و پایان است..SS DHCPSRV_MEMFILE_GET_REMOTEID6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 with remote id %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است صفحه‌ای از اجاره‌های IPv6 را که با نشانی و remote id مشخص‌شده شروع می‌شوند، به دست آورد.
DHCPSRV_MEMFILE_GET_SUBID4
0.0
3.5
obtaining IPv4 leases for subnet ID %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تمام اجاره‌های IPv4 را برای یک شناسه زیرشبکه (subnet ID) مشخص از پایگاه داده فایل حافظه دریافت کند.
DHCPSRV_MEMFILE_GET_SUBID6
0.0
3.5
obtaining IPv6 leases for subnet ID %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تمام اجاره‌های IPv6 را برای یک شناسه زیرشبکه (subnet ID) مشخص از پایگاه داده فایل حافظه دریافت کند.
DHCPSRV_MEMFILE_GET_SUBID_CLIENTID
0.0
3.5
obtaining IPv4 lease for subnet ID %1 and client ID %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است یک اجاره IPv4 را برای کلاینتی با شناسه زیرشبکه (subnet ID) و شناسه کلاینت (client ID) مشخص‌شده، از پایگاه داده فایل حافظه دریافت کند.
DHCPSRV_MEMFILE_GET_SUBID_HWADDR
0.0
3.5
obtaining IPv4 lease for subnet ID %1 and hardware address %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است یک اجاره IPv4 را برای کلاینتی با شناسه زیرشبکه (subnet ID) و نشانی سخت‌افزاری (hardware address) مشخص‌شده، از پایگاه داده فایل حافظه دریافت کند.
DHCPSRV_MEMFILE_GET_SUBID_PAGE6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 for subnet ID %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است صفحه‌ای از اجاره‌های IPv6 را با شروع از نشانی مشخص‌شده برای یک شناسه زیرشبکه معین از پایگاه داده فایل حافظه دریافت کند.
DHCPSRV_MEMFILE_LEASE_FILE_LOAD
0.0
3.5
loading leases from file %1
168u
168u
پیامی اطلاعاتی (info) که هنگامی صادر می‌شود که سرور در آستانه آغاز خواندن اجاره‌های DHCP از فایل اجاره است. تمام اجاره‌هایی که در حال حاضر در حافظه نگهداری می‌شوند، با اجاره‌های خوانده‌شده از فایل جایگزین خواهند شد.
DHCPSRV_MEMFILE_LEASE_LOAD
0.0
3.5
loading lease %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که اجاره DHCP در حال بارگذاری از فایل به حافظه است.
DHCPSRV_MEMFILE_LEASE_LOAD_ROW_ERROR
0.0
3.5
discarding row %1, error: %2
168u
168u
پیام خطایی که در صورت ناموفق بودن بارگذاری اجاره DHCP از سطر مشخص‌شده در فایل اجاره صادر می‌شود. پیام لاگ باید شامل دلیل مشخص رد شدن سطر باشد. سرور به بارگذاری داده‌های باقی‌مانده ادامه می‌دهد. این ممکن است نشان‌دهنده یک فایل اجاره خراب باشد..SS DHCPSRV_MEMFILE_LFC_EXECUTE
0.0
3.5
executing Lease File Cleanup using: %1
168u
168u
پیامی اطلاعاتی که هنگام آغاز یک فرآیند جدید توسط بک‌اند پایگاه‌داده اجاره memfile برای انجام پاک‌سازی فایل اجاره (Lease File Cleanup) صادر می‌شود.
DHCPSRV_MEMFILE_LFC_FAIL_PID_CREATE
0.0
3.5
Lease File Cleanup pid file create: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کد اجرای LFC در هنگام تلاش برای ایجاد فایل PID با شکست مواجه شود. این پیام شامل یک رشته خطای مشخص‌تر است.
DHCPSRV_MEMFILE_LFC_LEASE_FILE_RENAME_FAIL
0.0
3.5
failed to rename the current lease file %1 to %2, reason: %3
168u
168u
پیام خطایی که هنگام عدم موفقیت بک‌اند پایگاه‌داده اجاره memfile در انتقال فایل اجاره فعلی به یک فایل جدید (که پاک‌سازی باید روی آن انجام شود) ثبت می‌شود. این امر در عمل به این معناست که پاک‌سازی فایل اجاره انجام نمی‌شود.
DHCPSRV_MEMFILE_LFC_LEASE_FILE_REOPEN_FAIL
0.0
3.5
failed to reopen lease file %1 after preparing input file for lease file cleanup, reason: %2, new leases will not persist!
168u
168u
پیام خطایی که زمانی ثبت می‌شود که بک‌اند پایگاه‌داده اجاره memfile پس از تغییر نام فایل اجاره برای پاک‌سازی، در بازگشایی مجدد یا ایجاد مجدد فایل اجاره شکست می‌خورد. کارساز به فعالیت خود ادامه می‌دهد، اما اجاره‌های جدید روی دیسک ذخیره نخواهند شد.
DHCPSRV_MEMFILE_LFC_RESCHEDULED
0.0
3.5
rescheduled Lease File Cleanup
168u
168u
پیامی اطلاعاتی که زمانی صادر می‌شود که بک‌اند پایگاه‌داده اجاره memfile با دریافت دستور "kea-lfc-start"، زمان‌بندی پاک‌سازی دوره‌ای فایل اجاره را مجدداً تنظیم می‌کند.
DHCPSRV_MEMFILE_LFC_RUNNING
0.0
3.5
Lease File Cleanup instance already running
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کد اجرای LFC از طریق بررسی PID متوجه شود که نمونه‌ای قبلی از فرآیند LFC همچنان در حال اجراست.
DHCPSRV_MEMFILE_LFC_SETUP
0.0
3.5
setting up the Lease File Cleanup interval to %1 sec
168u
168u
پیامی اطلاعاتی که هنگام پیکربندی LFC توسط بک‌اند پایگاه‌داده اجاره memfile برای اجرای دوره‌ای ثبت می‌شود. آرگومان ارائه‌شده حاوی بازه زمانی بر حسب ثانیه است که LFC در فواصل آن اجرا خواهد شد.
DHCPSRV_MEMFILE_LFC_SPAWN_FAIL
0.0
3.5
lease file cleanup failed to run because kea-lfc process couldn't be spawned
168u
168u
این پیام خطا زمانی ثبت می‌شود که کارساز Kea نتواند kea-lfc (برنامه‌ای که فایل اجاره را پاک‌سازی می‌کند) را اجرا کند. کارساز در زمان‌بندی بعدیِ پاک‌سازی فایل اجاره دوباره تلاش خواهد کرد. اگرچه این پیام نباید رخ دهد و دلیل بروز آن باید بررسی شود، اما عدم اجرای گاه‌به‌گاهِ پاک‌سازی فایل اجاره تأثیری بر عملیات جاری نخواهد گذاشت. با این حال، در صورت تداوم این شکست، حجم فایل اجاره بدون محدودیت افزایش خواهد یافت.
DHCPSRV_MEMFILE_LFC_START
0.0
3.5
starting Lease File Cleanup
168u
168u
پیامی اطلاعاتی که زمانی صادر می‌شود که بک‌اند پایگاه‌داده اجاره Memfile پاک‌سازی دوره‌ای فایل اجاره را آغاز می‌کند.
DHCPSRV_MEMFILE_LFC_UNREGISTER_TIMER_FAILED
0.0
3.5
failed to unregister timer 'memfile-lfc': %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی ثبت می‌شود که بک‌اند Memfile نتواند تایمر مورد استفاده برای زمان‌بندی پاک‌سازی فایل اجاره را لغو ثبت کند. دلایل متعددی برای بروز این اتفاق وجود دارد، هرچند محتمل‌ترین علت آن خاموش شدن سیستم و لغو ثبت تایمر توسط مؤلفه‌ای دیگر است. این پیام شامل دلیل این خطا می‌باشد..SS DHCPSRV_MEMFILE_NEEDS_DOWNGRADING
0.0
3.5
version of lease file: %1 schema is later than version %2
168u
168u
پیام هشداری که هنگامی صادر می‌شود که طرحواره‌ی (schema) فایل اجاره بارگذاری‌شده توسط سرور،
جدیدتر از طرحواره‌ی memfile سرور باشد. سرور داده‌های اجاره را هنگام خواندن از طرحواره‌های
جدیدتر به طرحواره‌ی خود تبدیل می‌کند، بنابراین اطلاعات اجاره‌ی مورد استفاده توسط سرور
صحیح خواهد بود. با این حال توجه داشته باشید که هرگونه داده‌ی ذخیره‌شده در فیلدهای طرحواره‌ی
جدیدتر نادیده گرفته شده و حذف خواهد شد. آنچه باقی می‌ماند این است که خود فایل با استفاده
از طرحواره‌ی فعلی بازنویسی شود.
DHCPSRV_MEMFILE_NEEDS_UPGRADING
0.0
3.5
version of lease file: %1 schema is earlier than version %2
168u
168u
پیام هشداری که هنگامی صادر می‌شود که طرحواره‌ی فایل اجاره بارگذاری‌شده توسط سرور،
قدیمی‌تر از طرحواره‌ی memfile سرور باشد. توجه داشته باشید که سرور داده‌های اجاره را
هنگام خواندن از طرحواره‌های قدیمی‌تر به طرحواره‌ی فعلی تبدیل می‌کند، بنابراین اطلاعات
اجاره‌ی مورد استفاده توسط سرور صحیح خواهد بود. آنچه باقی می‌ماند این است که خود
فایل با استفاده از طرحواره‌ی فعلی بازنویسی شود.
DHCPSRV_MEMFILE_NO_STORAGE
0.0
3.5
running in non-persistent mode, leases will be lost after restart
168u
168u
پیام هشداری که هنگامی صادر می‌شود که نوشتن اجاره‌ها روی دیسک در پیکربندی غیرفعال
شده باشد. این حالت برای برخی از انواع آزمایش‌های کارایی مفید است، اما در شرایط
عادی نباید فعال شود. حالت غیرپایا (non-persistence) زمانی فعال می‌شود که پارامترهای
'persist4=no persist6=no' در رشته‌ی دسترسی پایگاه‌داده مشخص شده باشند.
DHCPSRV_MEMFILE_PATH_SECURITY_WARNING
0.0
3.5
Lease file path specified is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال تدابیر امنیتی غیرفعال شده باشد و
مسیر مشخص‌شده برای فایل اجاره با مسیر پشتیبانی‌شده مطابقت نداشته باشد. سرور
همچنان از مسیر مشخص‌شده استفاده خواهد کرد، اما هشدار می‌دهد که انجام این کار
ممکن است خطرات امنیتی به همراه داشته باشد.
DHCPSRV_MEMFILE_READ_HWADDR_FAIL
0.0
3.5
failed to read hardware address from lease file: %1
168u
168u
پیام هشداری که هنگام ناموفق بودن تلاش برای خواندن آدرس سخت‌افزاری ذخیره‌شده
در یک فایل دیسک صادر می‌شود. این پارامتر باید ماهیت دقیق خطا را ارائه دهد.
خواندن پایگاه‌داده ادامه خواهد یافت، اما آن اجاره‌ی خاص دیگر آدرس سخت‌افزاری
مرتبط با خود را نخواهد داشت.
DHCPSRV_MEMFILE_ROLLBACK
0.0
3.5
rolling back memory file database
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
کد یک فراخوانی rollback صادر کرده است. برای پایگاه‌داده‌ی فایل حافظه (memfile)،
این یک عملیات بدون اثر (no-op) است.
DHCPSRV_MEMFILE_UPDATE_ADDR4
0.0
3.5
updating IPv4 lease for address %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که سرور در تلاش برای به‌روزرسانی اجاره‌ی IPv4
از پایگاه‌داده‌ی فایل حافظه برای آدرس مشخص‌شده است.
DHCPSRV_MEMFILE_UPDATE_ADDR6
0.0
3.5
updating IPv6 lease for address %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که سرور در تلاش برای به‌روزرسانی اجاره‌ی IPv6
از پایگاه‌داده‌ی فایل حافظه برای آدرس مشخص‌شده است.
DHCPSRV_MEMFILE_WIPE_LEASES4
0.0
3.5
removing all IPv4 leases from subnet %1
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که حذف تمام اجاره‌ها از زیرشبکه‌ی (subnet)
مشخص‌شده‌ی IPv4 آغاز شده باشد. این عمل در نتیجه‌ی دریافت یک دستور مدیریتی رخ می‌دهد..SS DHCPSRV_MEMFILE_WIPE_LEASES4_FINISHED
0.0
3.5
removing all IPv4 leases from subnet %1 finished, removed %2 leases
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که حذف تمام اجاره‌ها از یک زیرشبکهٔ مشخص IPv4 به پایان رسیده باشد. تعداد اجاره‌های حذف‌شده نیز نمایش داده می‌شود.
DHCPSRV_MEMFILE_WIPE_LEASES6
0.0
3.5
removing all IPv6 leases from subnet %1
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که فرایند حذف تمام اجاره‌ها از زیرشبکهٔ مشخص‌شدهٔ IPv6 در حال آغاز است. این پیام در نتیجهٔ دریافت یک دستور مدیریتی صادر می‌شود.
DHCPSRV_MEMFILE_WIPE_LEASES6_FINISHED
0.0
3.5
removing all IPv6 leases from subnet %1 finished, removed %2 leases
168u
168u
این پیام اطلاع‌رسانی زمانی چاپ می‌شود که حذف تمام اجاره‌ها از یک زیرشبکهٔ مشخص IPv6 به پایان رسیده باشد. تعداد اجاره‌های حذف‌شده نیز نمایش داده می‌شود.
DHCPSRV_MT_DISABLED_QUEUE_CONTROL
0.0
3.5
disabling dhcp queue control when multi-threading is enabled.
168u
168u
این پیام هشدار زمانی صادر می‌شود که در صورت فعال بودن multi-threading، کنترل صف DHCP به‌طور خودکار غیرفعال گردد. این دو گزینه با یکدیگر ناسازگارند و نمی‌توان هر دو را به‌طور هم‌زمان فعال کرد.
DHCPSRV_MULTIPLE_RAW_SOCKETS_PER_IFACE
0.0
3.5
current configuration will result in opening multiple broadcast capable sockets on some interfaces and some DHCP messages may be duplicated
168u
168u
پیام هشداری که نشان می‌دهد پیکربندی فعلی منجر به باز شدن چندین سوکت با قابلیت دریافت ترافیک همگانی (broadcast) روی برخی از رابط‌ها خواهد شد. باید توجه داشت که این وضعیت ممکن است به دریافت و پردازش چندبارهٔ یک پیام DHCP یکسان بیانجامد، زیرا پیام توسط هر یک از سوکت‌ها به‌طور جداگانه دریافت خواهد شد.
DHCPSRV_NOTYPE_DB
0.0
3.5
no 'type' keyword to determine database backend: %1
168u
168u
این یک پیام خطا است و زمانی ثبت می‌شود که تلاشی برای دسترسی به یک backend پایگاه‌داده انجام شده باشد، اما کلیدواژهٔ 'type' در رشتهٔ دسترسی قید نشده باشد. رشتهٔ دسترسی (بدون گذرواژه‌ها) در این پیام گنجانده شده است.
DHCPSRV_NO_SOCKETS_OPEN
0.0
3.5
no interface configured to listen to DHCP traffic
168u
168u
این پیام هشدار زمانی صادر می‌شود که پیکربندی فعلی سرور هیچ رابطی را برای گوش دادن سرور به آن مشخص نکرده باشد، یا رابط‌های مشخص‌شده برای دریافت ترافیک پیکربندی نشده باشند.
DHCPSRV_ONLY_IF_REQUIRED_DEPRECATED
0.0
3.5
The parameter 'only-if-required' is deprecated. Use 'only-in-additional-list' instead
168u
168u
این پیام هشدار زمانی صادر می‌شود که پردازش و بررسی پیکربندی، استفاده از پارامتر منسوخ‌شدهٔ 'only-if-required' را تشخیص دهد. این پارامتر با 'only-in-additional-list' جایگزین شده است. کاربران باید به استفاده از پارامتر جدید مهاجرت کنند.
DHCPSRV_OPEN_SOCKET_FAIL
0.0
3.5
failed to open socket: %1
168u
168u
پیام هشداری که هنگام شکست IfaceMgr در باز کردن و bind کردن یک سوکت صادر می‌شود. دلیل این شکست به عنوان یک آرگومان در پیام ثبت گزارش ضمیمه شده است..SS DHCPSRV_QUEUE_NCR
0.0
3.5
%1: Name change request to %2 DNS entry queued: %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
پیام اشکال‌زدایی‌ای که هنگام در صف قرار گرفتن NameChangeRequest برای افزودن یا حذف مدخل‌های DNS برای یک اجارهٔ (lease) مشخص ثبت می‌شود. آرگومان نخست شامل اطلاعات شناسایی کلاینت است. آرگومان دوم مشخص می‌کند که آیا مدخل DNS باید افزوده شود یا حذف. آرگومان سوم حامل جزئیات NameChangeRequest است.
DHCPSRV_QUEUE_NCR_FAILED
0.0
3.5
%1: queuing %2 name change request failed for lease %3: %4
168u
168u
این پیام خطا زمانی ثبت می‌شود که ارسال NameChangeRequest به DHCP DDNS با شکست مواجه شود. آرگومان نخست شامل اطلاعات شناسایی کلاینت است. آرگومان دوم مشخص می‌کند که آیا مدخل DNS باید افزوده شود یا حذف. آرگومان سوم نشانی اجاره‌داده‌شده را مشخص می‌کند. آرگومان پایانی دلیل شکست را ارائه می‌دهد.
DHCPSRV_QUEUE_NCR_SKIP
0.0
3.5
%1: skip queuing name change request for lease: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار تصمیم می‌گیرد درخواست تغییر نام را در صف قرار ندهد، زیرا اجاره (lease) شامل FQDN نیست، به‌روزرسانی مستقیم (forward) و معکوس (reverse) برای این اجاره غیرفعال است یا به‌روزرسانی‌های DNS در پیکربندی غیرفعال شده‌اند. آرگومان نخست شامل اطلاعات شناسایی کلاینت است. آرگومان دوم شامل نشانی اجاره‌داده‌شده است.
DHCPSRV_REQUIRE_CLIENT_CLASSES_DEPRECATED
0.0
3.5
The parameter 'require-client-classes' is deprecated. Use 'evaluate-additional-classes' instead
168u
168u
این پیام هشدار زمانی صادر می‌شود که تجزیهٔ پیکربندی، استفاده از پارامتر منسوخ‌شدهٔ 'require-client-classes' را تشخیص دهد. این پارامتر با 'evaluate-additional-classes' جایگزین شده است. کاربران باید به پارامتر جدید مهاجرت کنند.
DHCPSRV_SUBNET4O6_SELECT_FAILED
0.0
3.5
Failed to select any subnet for the DHCPv4o6 packet
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند هیچ زیرشبکه‌ای (subnet) را برای بستهٔ DHCPv4o6 انتخاب کند.
DHCPSRV_SUBNET4_SELECT_BY_ADDRESS_NO_MATCH
0.0
3.5
No subnet matches address: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند با استفاده از نشانی مشخص‌شده، زیرشبکه‌ای را انتخاب کند.
DHCPSRV_SUBNET4_SELECT_BY_INTERFACE_NO_MATCH
0.0
3.5
No subnet matches interface: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند با استفاده از نام رابط (interface) مشخص‌شده، زیرشبکه‌ای را انتخاب کند.
DHCPSRV_SUBNET4_SELECT_BY_RELAY_ADDRESS_NO_MATCH
0.0
3.5
No subnet matches relay address: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند با استفاده از نشانی بازپخش (relay address) مشخص‌شده، زیرشبکه‌ای را انتخاب کند.
DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS
0.0
3.5
No RAI options found to use for subnet selection.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی توسط کارگزار صادر می‌شود که پرس‌وجوی کلاینت شامل گزینه‌های RAI مناسب برای استفاده در انتخاب زیرشبکه نباشد..SS DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS
0.0
3.5
Relay address (giaddr) in client packet is empty.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ نشانی رله‌ای (relay address) برای استفاده در انتخاب زیرشبکه مشخص نشده باشد.
DHCPSRV_SUBNET4_SELECT_NO_USABLE_ADDRESS
0.0
3.5
No subnet selected because no suitable address to use for subnet selection was found.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند نشانی مناسبی را برای استفاده در انتخاب زیرشبکه بیابد.
DHCPSRV_SUBNET6_SELECT_BY_ADDRESS_NO_MATCH
0.0
3.5
No subnet matches address: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند با استفاده از نشانی مشخص‌شده، زیرشبکه‌ای را انتخاب کند.
DHCPSRV_SUBNET6_SELECT_BY_INTERFACE_ID_NO_MATCH
0.0
3.5
No subnet matches interface id: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند با استفاده از شناسهٔ رابط مشخص‌شده (interface id)، زیرشبکه‌ای را انتخاب کند.
DHCPSRV_SUBNET6_SELECT_BY_INTERFACE_NO_MATCH
0.0
3.5
No subnet matches interface: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار نتواند با استفاده از نام رابط مشخص‌شده، زیرشبکه‌ای را انتخاب کند.
DHCPSRV_TEMPLATE_EVAL_ERROR
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
این پیام خطا نشان می‌دهد که هنگام ارزیابی یک عبارت در یک کلاس کلاینت الگویی (template client class) مشکلی رخ داده است.
توضیحی دربارهٔ مشکل چاپ می‌شود.
DHCPSRV_TEMPLATE_EVAL_RESULT
0.0
3.5
%1: Expression '%2' evaluated to %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت یک کلاس کلاینت الگویی با موفقیت ارزیابی شده است. نام کلاس کلاینت و مقدار حاصل از این ارزیابی چاپ می‌شوند.
DHCPSRV_TIMERMGR_CALLBACK_FAILED
0.0
3.5
running handler for timer %1 caused exception: %2
168u
168u
این پیام خطا هنگامی صادر می‌شود که مهلت تایمر به سر رسیده و عملیات مرتبط با این تایمر موجب پرتاب یک استثنا (exception) شده باشد.
نام تایمر و علت بروز استثنا ثبت می‌شود.
DHCPSRV_TIMERMGR_REGISTER_TIMER
0.0
3.5
registering timer: %1, using interval: %2 ms
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تایمر بازه‌ای (interval timer) جدیدی در Timer Manager ثبت شود. این تایمر یک تابع بازخوانی (callback function) مرتبط خواهد داشت و این تابع بر اساس بازهٔ زمانی مشخص‌شده اجرا می‌شود. نام یکتای تایمر و بازهٔ زمانی اجرای تابع بازخوانی در پیام گنجانده شده است..SS DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION
0.0
3.5
running operation for timer: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که Timer Manager در آستانه
اجرای یک عملیات دوره‌ای مرتبط با تایمر مشخص‌شده باشد.
نمونه‌ای از چنین عملیاتی، پاک‌سازی دوره‌ای اجاره‌های (leases)
منقضی‌شده است. نام تایمر در پیام گنجانده شده است.
DHCPSRV_TIMERMGR_START_TIMER
0.0
3.5
starting timer: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تایمر فاصله‌ای (interval timer)
ثبت‌شده در حال راه‌اندازی باشد. در صورت موفقیت‌آمیز بودن این عملیات،
تایمر به صورت دوره‌ای عملیات مرتبط با خود را اجرا خواهد کرد. نام تایمر
راه‌اندازی‌شده در پیام گنجانده شده است.
DHCPSRV_TIMERMGR_STOP_TIMER
0.0
3.5
stopping timer: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تایمر فاصله‌ای ثبت‌شده
در حال متوقف شدن باشد. تایمر همچنان ثبت‌شده باقی می‌ماند و در صورت
لزوم می‌تواند دوباره راه‌اندازی شود. نام تایمر در پیام گنجانده شده است.
DHCPSRV_TIMERMGR_UNREGISTER_ALL_TIMERS
0.0
3.5
unregistering all timers
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تمام تایمرهای فاصله‌ای ثبت‌شده
از Timer Manager لغو ثبت (unregister) شوند.
DHCPSRV_TIMERMGR_UNREGISTER_TIMER
0.0
3.5
unregistering timer: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یکی از تایمرهای فاصله‌ای ثبت‌شده
از Timer Manager لغو ثبت شود. نام تایمر در پیام گنجانده شده است.
DHCPSRV_UNKNOWN_DB
0.0
3.5
unknown database type: %1
168u
168u
رشته دسترسی به پایگاه‌داده، نوعی از پایگاه‌داده را مشخص کرده است (که در
پیام آمده است) که برای نرم‌افزار ناشناخته است. این یک خطای پیکربندی است.
DHCP
DHCP_ADD_EXTERNAL_SOCKET_ALREADY_EXISTS
0.0
3.5
Adding an already existing external socket %1
168u
168u
این پیام هشدار نشان می‌دهد که یک سوکت خارجی اضافه شده است، اما از قبل
وجود دارد؛ یعنی افزودن‌ها و حذف‌ها به طور صحیح متعادل نیستند.
DHCP_ADD_EXTERNAL_SOCKET_BAD_THREAD
0.0
3.5
Attempted to register external socket %1 from different thread %2 than main thread %3
168u
168u
این پیام خطا نشان می‌دهد که نخی (thread) به غیر از نخ اصلی، یک سوکت خارجی را
ثبت کرده است. این یک خطای برنامه‌نویسی است و باید اصلاح شود.
تنها نخ اصلی مجاز به انجام عملیات روی سوکت‌های خارجی است.
توصیف‌کننده فایل (file descriptor) و شناسه نخ‌های مربوطه در پیام گنجانده شده‌اند.
DHCP_DDNS_ADD_FAILED
0.0
3.5
DHCP_DDNS Request ID %1: Transaction outcome %2
168u
168u
این یک پیام خطا است که پس از شکست تلاش‌های DHCP_DDNS برای ثبت ورودی‌های
نگاشت DNS صادر می‌شود. دلیل دقیق این شکست باید در مدخل‌های گزارش
(log) پیشین مستند شده باشد..SS DHCP_DDNS_ADD_SUCCEEDED
0.0
3.5
DHCP_DDNS Request ID %1: successfully added the DNS mapping addition for this request: %2
168u
168u
این یک پیام اطلاعاتی است و زمانی صادر می‌شود که DHCP_DDNS عملیات افزودن نگاشت‌های DNS را ارسال کرده و توسط یک کارساز DNS مناسب دریافت و پذیرفته شده باشد.
DHCP_DDNS_AT_MAX_TRANSACTIONS
0.0
3.5
application has %1 queued requests but has reached maximum number of %2 concurrent transactions
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و نشان می‌دهد برنامه دارای درخواست‌های DHCP_DDNS در صف است، اما در حال حاضر به اندازهٔ حداکثر مجازِ تراکنش‌های هم‌روند فعالیت می‌کند.
DHCP_DDNS_CLEARED_FOR_SHUTDOWN
0.0
3.5
application has met shutdown criteria for shutdown type: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که به برنامه دستور خاموش شدن داده شده و معیارهای لازم برای خروج را احراز کرده باشد.
DHCP_DDNS_CONFIGURE
0.0
3.5
configuration %1 received: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که متد پیکربندی (configure) برنامهٔ DHCP-DDNS فراخوانی شده باشد.
DHCP_DDNS_CONFIGURED_CALLOUT_DROP
0.0
3.5
configuration was rejected because a callout set the next step to 'drop': %1
168u
168u
این پیام خطا نشان می‌دهد تلاش پیکربندی DHCP-DDNS ناموفق بوده است؛ زیرا گام بعدیِ فراخوانی (callout) پیکربندی‌شده توسط یک کتابخانهٔ قلاب (hook library) روی 'drop' تنظیم شده بود. پیام خطای ارائه‌شده توسط کتابخانهٔ قلاب نمایش داده می‌شود.
DHCP_DDNS_CONFIG_CHECK_FAIL
0.0
3.5
DHCP-DDNS server configuration check failed: %1
168u
168u
این پیام خطا نشان می‌دهد که بررسی پیکربندی DHCP-DDNS با شکست مواجه شده است. جزئیات ارائه شده است. ممکن است جزئیات بیشتر در ورودی‌های قبلی گزارش، احتمالاً در سطوح پایین‌تر، در دسترس باشد.
DHCP_DDNS_CONFIG_FAIL
0.0
3.5
DHCP-DDNS server configuration failed: %1
168u
168u
این پیام خطا نشان می‌دهد که تلاش پیکربندی DHCP-DDNS با شکست مواجه شده است. جزئیات ارائه شده است. ممکن است جزئیات بیشتر در ورودی‌های قبلی گزارش، احتمالاً در سطوح پایین‌تر، در دسترس باشد.
DHCP_DDNS_CONFIG_SYNTAX_WARNING
0.0
3.5
DHCP-DDNS server configuration syntax warning: %1
168u
168u
این پیام هشدار نشان می‌دهد که پیکربندی DHCP-DDNS دارای یک خطای نحوی جزئی بوده است. خطا نمایش داده شده و تجزیهٔ پیکربندی از سر گرفته شد.
DHCP_DDNS_FAILED
0.0
3.5
application experienced a fatal error: %1
168u
168u
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که برنامهٔ DHCP-DDNS در درون حلقهٔ رویداد (event loop) با یک خطای غیرقابل‌بازیابی مواجه شود.
DHCP_DDNS_FORWARD_ADD_BAD_DNSCLIENT_STATUS
0.0
3.5
DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while adding a forward address mapping for FQDN %3 to DNS server %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که DNSClient در حین افزودن نگاشت آدرس مستقیم (forward address mapping) توسط DHCP_DDNS، وضعیتی ناشناخته را برمی‌گرداند. این درخواست لغو خواهد شد. این موضوع به احتمال زیاد یک مشکل برنامه‌نویسی است و باید گزارش شود..SS DHCP_DDNS_FORWARD_ADD_BUILD_FAILURE
0.0
3.5
DNS Request ID %1: update message to add a forward DNS entry could not be constructed for this request: %2, reason: %3
168u
168u
این پیام خطایی است که هنگام بروز خطا در تلاش برای ساخت بستهٔ ارسالی به کارساز به منظور درخواست افزودن نشانی مستقیم صادر می‌شود. دلیل این امر داده‌های نامعتبر موجود در NameChangeRequest است. درخواست لغو خواهد شد. این مشکل به احتمال زیاد ناشی از پیکربندی است.
DHCP_DDNS_FORWARD_ADD_IO_ERROR
0.0
3.5
DHCP_DDNS Request ID %1: encountered an IO error sending a forward mapping add for FQDN %2 to DNS server %3
168u
168u
این پیام خطایی است که هنگام بروز خطای ارتباطی در حین انجام عملیات افزودن نشانی مستقیم توسط DHCP_DDNS صادر می‌شود. برنامه بسته به شرایط، تلاش مجدد را روی همان کارساز یا کارسازهای دیگر انجام خواهد داد.
DHCP_DDNS_FORWARD_ADD_REJECTED
0.0
3.5
DNS Request ID %1: Server, %2, rejected a DNS update request to add the address mapping for FQDN, %3, with an RCODE: %4
168u
168u
این پیام خطایی است و زمانی صادر می‌شود که درخواست به‌روزرسانی توسط کارساز DNS مقصد، به دلیلی که در RCODE مشخص شده است رد شود. مقادیر rcode در RFC 2136 تعریف شده‌اند.
DHCP_DDNS_FORWARD_ADD_RESP_CORRUPT
0.0
3.5
DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while adding forward address mapping for FQDN, %3
168u
168u
این پیام خطایی است و زمانی صادر می‌شود که پاسخ دریافتی توسط DHCP_DDNS در ازای درخواست به‌روزرسانی افزودن نگاشت نشانی مستقیم، مخدوش یا بدریخت (malformed) باشد. برنامه بسته به شرایط، تلاش مجدد را روی همان کارساز یا کارسازهای دیگر انجام خواهد داد.
DHCP_DDNS_FORWARD_ADD_TIMEOUT
0.0
3.5
DHCP_DDNS Request ID %1: timed out waiting for a response to forward mapping add for FQDN %2 to DNS server %3
168u
168u
این پیام خطایی است و زمانی صادر می‌شود که در حین انجام عملیات افزودن نشانی مستقیم توسط DHCP_DDNS، پیش از سرآمدن مدت‌زمان dns-server-timeout هیچ پاسخی از کارساز DNS دریافت نشود. برنامه بسته به شرایط، تلاش مجدد را روی همان کارساز یا کارسازهای دیگر انجام خواهد داد.
DHCP_DDNS_FORWARD_REMOVE_ADDRS_BAD_DNSCLIENT_STATUS
0.0
3.5
DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while removing a forward address mapping for FQDN %3 to DNS server %4
168u
168u
این پیام خطایی است و زمانی صادر می‌شود که هنگام حذف نگاشت نشانی مستقیم توسط DHCP_DDNS، مؤلفهٔ DNSClient وضعیتی ناشناخته را بازگرداند. درخواست لغو خواهد شد. این موضوع به احتمال زیاد یک ایراد برنامه‌نویسی است و باید گزارش شود.
DHCP_DDNS_FORWARD_REMOVE_ADDRS_BUILD_FAILURE
0.0
3.5
DNS Request ID %1: update message to remove a forward DNS Address entry could not be constructed for this request: %2, reason: %3
168u
168u
این پیام خطایی است که هنگام بروز خطا در تلاش برای ساخت بستهٔ ارسالی به کارساز به منظور درخواست حذف نشانی مستقیم (A یا AAAA) صادر می‌شود. دلیل این امر داده‌های نامعتبر موجود در NameChangeRequest است. درخواست لغو خواهد شد. این مشکل به احتمال زیاد ناشی از پیکربندی است.
/sar/
DHCP_DDNS_FORWARD_REMOVE_ADDRS_IO_ERROR
0.0
3.5
DHCP_DDNS Request ID %1: encountered an IO error sending a forward mapping address removal for FQDN %2 to DNS server %3
168u
168u
این پیام خطایی است که هنگام بروز خطای ارتباطی در حین انجام عملیات حذف نشانی مستقیم توسط DHCP_DDNS صادر می‌شود. برنامه بسته به شرایط، تلاش مجدد را روی همان کارساز یا کارسازهای دیگر انجام خواهد داد.
DHCP_DDNS_FORWARD_REMOVE_ADDRS_REJECTED
0.0
3.5
DNS Request ID %1: Server, %2, rejected a DNS update request to remove the forward address mapping for FQDN, %3, with an RCODE: %4
168u
168u
این پیام خطایی است و زمانی صادر می‌شود که درخواست به‌روزرسانی توسط کارساز DNS مقصد، به دلیلی که در RCODE مشخص شده است رد شود. مقادیر rcode در RFC 2136 تعریف شده‌اند..SS DHCP_DDNS_FORWARD_REMOVE_ADDRS_RESP_CORRUPT
0.0
3.5
DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while removing forward address mapping for FQDN, %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که پاسخ دریافت‌شده توسط DHCP_DDNS برای یک درخواست به‌روزرسانی جهت حذف نگاشت نشانی مستقیم (forward address mapping)، مخدوش یا ناقص (malformed) باشد. برنامه بسته به شرایط، درخواست را مجدداً روی همان سرور یا سایر سرورها امتحان خواهد کرد.
DHCP_DDNS_FORWARD_REMOVE_ADDRS_TIMEOUT
0.0
3.5
DHCP_DDNS Request ID %1: timed out waiting for a response to forward mapping address removal for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام حذف نگاشت نشانی مستقیم توسط DHCP_DDNS، پیش از سرآمدن مهلت زمانی dns-server-timeout هیچ پاسخی از سرور DNS دریافت نشود. برنامه بسته به شرایط، درخواست را مجدداً روی همان سرور یا سایر سرورها امتحان خواهد کرد.
DHCP_DDNS_FORWARD_REMOVE_RRS_BAD_DNSCLIENT_STATUS
0.0
3.5
DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while removing forward RRs for FQDN %3 to DNS server %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که DNSClient هنگام حذف رکوردهای منبع مستقیم (forward RRs) توسط DHCP_DDNS، وضعیتی ناشناخته را بازمی‌گرداند. این درخواست لغو خواهد شد. این مورد به احتمال زیاد یک مشکل برنامه‌نویسی است و باید گزارش شود.
DHCP_DDNS_FORWARD_REMOVE_RRS_BUILD_FAILURE
0.0
3.5
DNS Request ID %1: update message to remove forward DNS RR entries could not be constructed for this request: %2, reason: %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام تلاش برای ساخت بسته ارسالی به سرور جهت درخواست حذف رکوردهای منبع مستقیم (DHCID RR)، خطایی رخ دهد. این خطا ناشی از داده‌های نامعتبر موجود در NameChangeRequest است. درخواست لغو خواهد شد. این مورد به احتمال زیاد یک مشکل در پیکربندی است.
DHCP_DDNS_FORWARD_REMOVE_RRS_IO_ERROR
0.0
3.5
DHCP_DDNS Request ID %1: encountered an IO error sending a forward RR removal for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام حذف رکوردهای منبع مستقیم توسط DHCP_DDNS، یک خطای ارتباطی (I/O) رخ دهد. برنامه درخواست را مجدداً روی همان سرور تکرار خواهد کرد.
DHCP_DDNS_FORWARD_REMOVE_RRS_REJECTED
0.0
3.5
DNS Request ID %1: Server, %2, rejected a DNS update request to remove forward RR entries for FQDN, %3, with an RCODE: %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که یک درخواست به‌روزرسانی توسط سرور DNS مقصد، به دلیلی که با RCODE مشخص شده رد شود. مقادیر rcode در RFC 2136 تعریف شده‌اند.
DHCP_DDNS_FORWARD_REMOVE_RRS_RESP_CORRUPT
0.0
3.5
DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while removing forward RRs for FQDN, %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که پاسخ دریافت‌شده توسط DHCP_DDNS برای یک درخواست به‌روزرسانی جهت حذف نگاشت رکوردهای منبع مستقیم (forward RRs)، مخدوش یا ناقص (malformed) باشد. برنامه بسته به شرایط، درخواست را مجدداً روی همان سرور یا سایر سرورها امتحان خواهد کرد.
/sar/
DHCP_DDNS_FORWARD_REMOVE_RRS_TIMEOUT
0.0
3.5
DHCP_DDNS Request ID %1: timed out waiting for response to forward RR removal for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام حذف رکوردهای منبع مستقیم توسط DHCP_DDNS، پیش از سرآمدن مهلت زمانی dns-server-timeout هیچ پاسخی از سرور DNS دریافت نشود. برنامه بسته به شرایط، درخواست را مجدداً روی همان سرور یا سایر سرورها امتحان خواهد کرد.
DHCP_DDNS_FORWARD_REPLACE_BAD_DNSCLIENT_STATUS
0.0
3.5
DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while replacing forward address mapping for FQDN %3 to DNS server %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که DNSClient هنگام جایگزینی نگاشت نشانی مستقیم توسط DHCP_DDNS، وضعیتی ناشناخته را بازمی‌گرداند. این درخواست لغو خواهد شد. این مورد به احتمال زیاد یک مشکل برنامه‌نویسی است و باید گزارش شود..SS DHCP_DDNS_FORWARD_REPLACE_BUILD_FAILURE
0.0
3.5
DNS Request ID %1: update message to replace a forward DNS entry could not be constructed from this request: %2, reason: %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام تلاش برای ساخت بسته ارسالی به کارساز جهت درخواست جایگزینی نگاشت مستقیم، خطایی رخ دهد. این مشکل ناشی از داده‌های نامعتبر موجود در NameChangeRequest است. این درخواست متوقف خواهد شد. این خطا به احتمال زیاد یک مشکل در پیکربندی است.
DHCP_DDNS_FORWARD_REPLACE_IO_ERROR
0.0
3.5
DHCP_DDNS Request ID %1: encountered an IO error sending a forward mapping replace for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که حین انجام عملیات جایگزینی نگاشت مستقیم توسط DHCP_DDNS، یک خطای ارتباطی (I/O) رخ دهد. برنامه با توجه به شرایط، عملیات را مجدداً با همان کارساز یا کارسازهای دیگر امتحان خواهد کرد.
DHCP_DDNS_FORWARD_REPLACE_REJECTED
0.0
3.5
DNS Request ID %1: Server, %2, rejected a DNS update request to replace the address mapping for FQDN, %3, with an RCODE: %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که یک به‌روزرسانی توسط کارساز DNS دریافت‌کننده، به دلیلی که در RCODE مشخص شده است، رد شود. مقادیر rcode در RFC 2136 تعریف شده‌اند.
DHCP_DDNS_FORWARD_REPLACE_RESP_CORRUPT
0.0
3.5
DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while replacing forward address mapping for FQDN, %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که پاسخ دریافت‌شده توسط DHCP_DDNS در قبال درخواست به‌روزرسانی جایگزینی نگاشت آدرس مستقیم، مخدوش یا ناصحیح (malformed) باشد. برنامه با توجه به شرایط، مجدداً با همان کارساز یا کارسازهای دیگر تلاش خواهد کرد.
DHCP_DDNS_FORWARD_REPLACE_TIMEOUT
0.0
3.5
DHCP_DDNS Request ID %1: timed out waiting for a response to forward mapping replace for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که حین اجرای عملیات جایگزینی نگاشت مستقیم توسط DHCP_DDNS، تا پیش از پایان مهلت زمانی dns-server-timeout هیچ پاسخی از کارساز DNS دریافت نشود. برنامه با توجه به شرایط، مجدداً با همان کارساز یا کارسازهای دیگر تلاش خواهد کرد.
DHCP_DDNS_FWD_REQUEST_IGNORED
0.0
3.5
Request ID %1: Forward updates are disabled, the forward portion of request will be ignored: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که به‌روزرسانی‌های مستقیم DNS غیرفعال باشند و DHCP_DDNS درخواستی شامل به‌روزرسانی مستقیم DNS دریافت کند. بخش به‌روزرسانی مستقیم انجام نخواهد شد.
DHCP_DDNS_INVALID_NCR
0.0
3.5
application received an invalid DNS update request: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد برنامه درخواستی نامعتبر برای به‌روزرسانی یک مدخل DNS دریافت کرده است. قالب یا محتوای درخواست نادرست است. درخواست نادیده گرفته خواهد شد.
DHCP_DDNS_INVALID_RESPONSE
0.0
3.5
received response to DNS Update message is malformed: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که برنامه DHCP-DDNS هنگام رمزگشایی پاسخ یک پیام DNS Update با خطا مواجه شود. به‌طور معمول، این خطا زمانی رخ می‌دهد که پیام پاسخ بدشکل و ناصحیح (malformed) باشد.
DHCP_DDNS_LISTENING_ON_ALL_INTERFACES
0.0
3.5
the DHCP-DDNS server has been configured to listen on %1. This is an insecure configuration supported for testing purposes only
168u
168u
این یک پیام هشدار است و زمانی صادر می‌شود که کارساز DHCP-DDNS برای گوش دادن به یکی از آدرس‌های 0.0.0.0 یا :: پیکربندی شده باشد. در این حالت ممکن است یک مهاجم با اهداف مخرب بتواند پیام‌های ساختگی NameChangeRequests ارسال کرده و مدخل‌های DNS را تغییر دهد. به همین دلیل، گوش دادن روی تمام رابط‌ها باید تنها هنگام استقرار در کانتینرها یا برای اهداف آزمایشی استفاده شود. نگارش‌های آینده Kea این قابلیت را به‌طور پیش‌فرض غیرفعال خواهند کرد..SS DHCP_DDNS_NCR_FLUSH_IO_ERROR
0.0
3.5
DHCP-DDNS Last send before stopping did not complete successfully: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد کلاینت DHCP-DDNS قادر به تکمیل آخرین ارسال پیش از خروج از حالت ارسال نبوده است. این یک خطای برنامه‌نویسی است، وقوع آن بسیار نامحتمل است و نباید به توانایی برنامه در پردازش درخواست‌ها آسیبی برساند.
DHCP_DDNS_NCR_LISTEN_CLOSE_ERROR
0.0
3.5
application encountered an error while closing the listener used to receive NameChangeRequests : %1
168u
168u
این یک پیام خطا است که نشان می‌دهد برنامه نتوانسته است اتصال شنونده (listener) مورد استفاده برای دریافت NameChangeRequestها را ببندد. بسته شدن اتصال ممکن است در حین بازیابی از خطا یا در طول روند عادی خاموش شدن رخ دهد. در هر دو حالت، بعید است این خطا به توانایی برنامه در پردازش درخواست‌ها آسیبی برساند، اما باید برای بررسی و تحلیل گزارش شود.
DHCP_DDNS_NCR_RECV_NEXT_ERROR
0.0
3.5
application could not initiate the next read following a request receive.
168u
168u
این یک پیام خطا است که نشان می‌دهد شنوندهٔ NameChangeRequest پس از دریافت یک درخواست، نتوانسته است خواندن بعدی را آغاز کند. با اینکه ممکن است رخ دهد، اما بسیار نامحتمل است و احتمالاً یک خطای برنامه‌نویسی است. برنامه باید بتواند خودبه‌خود بازیابی شود.
DHCP_DDNS_NCR_SEND_CLOSE_ERROR
0.0
3.5
DHCP-DDNS client encountered an error while closing the sender connection used to send NameChangeRequests: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد کلاینت DHCP-DDNS نتوانسته است اتصال مورد استفاده برای ارسال NameChangeRequestها را ببندد. بسته شدن ممکن است در حین بازیابی از خطا یا در طول روند عادی خاموش شدن رخ دهد. در هر دو حالت، بعید است این خطا توانایی کلاینت را در ارسال درخواست‌ها مختل کند، اما باید برای بررسی و تحلیل گزارش شود.
DHCP_DDNS_NCR_SEND_NEXT_ERROR
0.0
3.5
DHCP-DDNS client could not initiate the next request send following send completion: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد فرستندهٔ NameChangeRequest پس از تکمیل ارسال درخواست پیشین، نتوانسته است ارسال بعدی را آغاز کند. هرچند رخ دادن آن ممکن است، اما بسیار نامحتمل بوده و احتمالاً یک خطای برنامه‌نویسی است. برنامه باید بتواند خودبه‌خود بازیابی شود.
DHCP_DDNS_NCR_UDP_CLEAR_READY_ERROR
0.0
3.5
NCR UDP watch socket failed to clear: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد برنامه پس از تکمیل یک ارسال، نتوانسته است وضعیت آماده (ready status) فرستندهٔ UDP NCR را بازنشانی کند. این یک خطای برنامه‌نویسی است که باید گزارش شود. برنامه ممکن است به عملکرد درست خود ادامه دهد یا ندهد.
DHCP_DDNS_NCR_UDP_RECV_CANCELED
0.0
3.5
UDP socket receive was canceled while listening for DNS Update requests
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان می‌دهد گوش دادن روی یک سوکت UDP برای دریافت درخواست‌های DNS Update لغو شده است. این یک بخش طبیعی از تعلیق عملیات گوش دادن است.
DHCP_DDNS_NCR_UDP_RECV_ERROR
0.0
3.5
UDP socket receive error while listening for DNS Update requests: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد در حین گوش دادن روی یک سوکت UDP برای دریافت درخواست‌های DNS Update، یک خطای ورودی/خروجی (I/O) رخ داده است. این امر می‌تواند نشان‌دهندهٔ مشکل در اتصال شبکه یا کمبود منابع سیستم باشد.
DHCP_DDNS_NCR_UDP_SEND_CANCELED
0.0
3.5
UDP socket send was canceled while sending a DNS Update request to DHCP_DDNS: %1
168u
168u
این یک پیام اطلاع‌رسانی است که نشان می‌دهد ارسال درخواست‌ها از طریق سوکت UDP به DHCP_DDNS متوقف شده است. این یک بخش طبیعی از روند تعلیق عملیات ارسال است..SS DHCP_DDNS_NCR_UDP_SEND_ERROR
0.0
3.5
UDP socket send error while sending a DNS Update request: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد هنگام ارسال یک درخواست به‌روزرسانی DNS به DHCP_DDNS از طریق سوکت UDP، یک خطای IO رخ داده است. این موضوع می‌تواند بیانگر وجود مشکلی در اتصال شبکه یا منابع سیستم باشد.
DHCP_DDNS_NOT_ON_LOOPBACK
0.0
3.5
the DHCP-DDNS server has been configured to listen on %1 which is not the local loopback. This is an insecure configuration supported for testing purposes only
168u
168u
این یک پیام هشدار است که هنگام پیکربندی کارساز DHCP-DDNS برای شنود روی آدرسی به غیر از آدرس loopback (یعنی 127.0.0.1 یا ::1) صادر می‌شود. این احتمال وجود دارد که یک مهاجم مخرب، NameChangeRequestهای جعلی به آن ارسال کرده و مدخل‌های DNS را تغییر دهد. به همین دلیل، آدرس‌هایی غیر از آدرس‌های loopback در IPv4 یا IPv6 فقط باید برای اهداف آزمایشی استفاده شوند. نسخه‌های آیندهٔ Kea برای محافظت در برابر چنین حملاتی، احراز هویت را پیاده‌سازی خواهند کرد.
DHCP_DDNS_NO_ELIGIBLE_JOBS
0.0
3.5
although there are queued requests, there are pending transactions for each, Queue count: %1 Transaction count: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 55 ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که تمام درخواست‌های موجود در صف نشان‌دهندهٔ کلاینت‌هایی باشند که در حال حاضر یک به‌روزرسانی برای آن‌ها در جریان است. این وضعیت ممکن است در طول عملیات عادی رخ دهد، اما باید یک شرایط موقتی باشد.
DHCP_DDNS_NO_FWD_MATCH_ERROR
0.0
3.5
Request ID %1: the configured list of forward DDNS domains does not contain a match for: %2 The request has been discarded.
168u
168u
این یک پیام خطا است که نشان می‌دهد DHCP_DDNS درخواستی برای به‌روزرسانی اطلاعات مستقیم (forward) در DNS برای FQDN مشخص‌شده دریافت کرده است، اما هیچ دامنهٔ DDNS پیکربندی‌شده‌ای برای آن در پیکربندی DHCP_DDNS وجود ندارد. در این حالت یا باید پیکربندی DHCP_DDNS به‌روزرسانی شود یا منبع خودِ FQDN بررسی گردد.
DHCP_DDNS_NO_MATCH
0.0
3.5
No DNS servers match FQDN %1
168u
168u
این یک پیام هشدار است و زمانی صادر می‌شود که هیچ دامنه‌ای در پیکربندی با نام دامنهٔ کاملاً مشخص (FQDN) ذکرشده مطابقت نداشته باشد. درخواست به‌روزرسانی DNS برای این FQDN قابل پردازش نیست.
DHCP_DDNS_NO_REV_MATCH_ERROR
0.0
3.5
Request ID %1: the configured list of reverse DDNS domains does not contain a match for: %2 The request has been discarded.
168u
168u
این یک پیام خطا است که نشان می‌دهد DHCP_DDNS درخواستی برای به‌روزرسانی اطلاعات معکوس (reverse) در DNS برای FQDN مشخص‌شده دریافت کرده است، اما هیچ دامنهٔ DDNS پیکربندی‌شده‌ای برای آن در پیکربندی DHCP_DDNS وجود ندارد. در این حالت یا باید پیکربندی DHCP_DDNS به‌روزرسانی شود یا منبع خودِ FQDN بررسی گردد.
DHCP_DDNS_QUEUE_MGR_QUEUE_FULL
0.0
3.5
application request queue has reached maximum number of entries %1
168u
168u
این یک پیام خطا است که نشان می‌دهد DHCP-DDNS درخواست‌های به‌روزرسانی DNS را با سرعتی بیشتر از توان پردازش خود دریافت می‌کند. این موضوع ممکن است به این معنا باشد که حداکثر اندازهٔ صف باید افزایش یابد، کلاینت‌های DHCP-DDNS بیش از حد و با سرعتی بالا درخواست تولید می‌کنند، یا شاید کارسازهای بالادستی DNS با مشکل بار پردازشی مواجه شده‌اند.
DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE
0.0
3.5
Request ID %1: received and queued a request.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 55 ثبت می‌شود.
این یک پیام اطلاعاتی است که نشان می‌دهد شنوندهٔ NameChangeRequest که توسط DHCP-DDNS برای دریافت درخواست‌ها استفاده می‌شود، درخواستی دریافت کرده و آن را برای پردازش‌های بعدی در صف قرار داده است.
DHCP_DDNS_QUEUE_MGR_RECONFIGURING
0.0
3.5
application is reconfiguring the queue manager
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 40 ثبت می‌شود.
این یک پیام اطلاعاتی است که نشان می‌دهد DHCP_DDNS در حال پیکربندی مجدد مدیر صف به عنوان بخشی از راه‌اندازی عادی یا در پاسخ به یک پیکربندی جدید است..SS DHCP_DDNS_QUEUE_MGR_RECOVERING
0.0
3.5
application is attempting to recover from a queue manager IO error
168u
168u
این یک پیام اطلاع‌رسانی است که نشان می‌دهد DHCP_DDNS در تلاش است تا پس از مواجهه با یک خطای IO حین دریافت درخواست‌ها، مدیر صف (queue manager) را مجدداً راه‌اندازی کند.
DHCP_DDNS_QUEUE_MGR_RECV_ERROR
0.0
3.5
application's queue manager was notified of a request receive error by its listener.
168u
168u
این یک پیام خطا است که نشان می‌دهد شنونده‌ی (listener) NameChangeRequest که توسط DHCP-DDNS برای دریافت درخواست‌ها استفاده می‌شود، با یک خطای IO مواجه شده است. باید پیام‌های گزارش متناظری از لایه‌ی شنونده حاوی جزئیات بیشتر وجود داشته باشد. این امر ممکن است نشان‌دهنده‌ی مشکلی در اتصال شبکه یا منابع سیستم باشد.
DHCP_DDNS_QUEUE_MGR_RESUME_ERROR
0.0
3.5
application could not restart the queue manager, reason: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد Queue Manager مربوط به DHCP_DDNS نتوانسته پس از توقف ناشی از پر شدن صف دریافت، مجدداً راه‌اندازی شود. این بدان معناست که برنامه قادر به دریافت درخواست‌ها نیست. این مسئله به احتمال زیاد به دلیل پارامترهای پیکربندی DHCP_DDNS است که به منابعی مانند یک آدرس IP یا پورت اشاره دارند که دیگر در دسترس نیستند. در صورت ارائه‌ی یک پیکربندی جدید، DHCP_DDNS تلاش خواهد کرد مدیر صف را مجدداً راه‌اندازی کند.
DHCP_DDNS_QUEUE_MGR_RESUMING
0.0
3.5
application is resuming listening for requests now that the request queue size has reached %1 of a maximum %2 allowed
168u
168u
این یک پیام اطلاع‌رسانی است که نشان می‌دهد DHCP_DDNS، که پذیرش درخواست‌های جدید را متوقف کرده بود، اکنون ورودی‌های کافی از صف دریافت را پردازش کرده است تا پذیرش درخواست‌ها را از سر بگیرد.
DHCP_DDNS_QUEUE_MGR_STARTED
0.0
3.5
application's queue manager has begun listening for requests.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 0 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان می‌دهد Queue Manager مربوط به DHCP_DDNS با موفقیت راه‌اندازی شده و اکنون در حال گوش دادن به NameChangeRequests است.
DHCP_DDNS_QUEUE_MGR_START_ERROR
0.0
3.5
application could not start the queue manager, reason: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد Queue Manager مربوط به DHCP_DDNS نتوانسته راه‌اندازی شود. این بدان معناست که برنامه قادر به دریافت درخواست‌ها نیست. این مسئله به احتمال زیاد به دلیل پارامترهای پیکربندی DHCP_DDNS است که به منابعی مانند یک آدرس IP یا پورت که در دسترس نیستند اشاره دارند. در صورت ارائه‌ی یک پیکربندی جدید، DHCP_DDNS تلاش خواهد کرد مدیر صف را مجدداً راه‌اندازی کند.
DHCP_DDNS_QUEUE_MGR_STOPPED
0.0
3.5
application's queue manager has stopped listening for requests.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 40 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که نشان می‌دهد Queue Manager مربوط به DHCP_DDNS گوش دادن به NameChangeRequests را متوقف کرده است. این امر ممکن است به دلیل یک رویداد عادی مانند پیکربندی مجدد یا در نتیجه‌ی یک خطا رخ داده باشد. باید پیش از این پیام، پیام‌های گزارشی وجود داشته باشند که دلیل توقف آن را مشخص کنند.
DHCP_DDNS_QUEUE_MGR_STOPPING
0.0
3.5
application is stopping the queue manager for %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 0 ثبت می‌شود.
این یک پیام اطلاع‌رسانی است که نشان می‌دهد DHCP_DDNS در حال متوقف کردن مدیر صف است؛ چه به منظور پیکربندی مجدد آن و چه به عنوان بخشی از روند خاموش‌سازی برنامه.
DHCP_DDNS_QUEUE_MGR_STOP_ERROR
0.0
3.5
application encountered an error stopping the queue manager: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد DHCP_DDNS هنگام تلاش برای متوقف کردن مدیر صف با خطایی مواجه شده است. رخ دادن این خطا یا مختل شدن کارایی برنامه توسط آن بعید است، اما باید جهت بررسی و تحلیل گزارش شود..SS DHCP_DDNS_QUEUE_MGR_UNEXPECTED_HANDLER_ERROR
0.0
3.5
گرداننده دریافت درخواست مدیر صف برنامه با یک استثنای غیرمنتظره %1 مواجه شد:
168u
168u
این یک پیام خطا است که نشان می‌دهد یک خطای غیرمنتظره در گرداننده تکمیل دریافت درخواست Queue Manager در DHCP_DDNS رخ داده است. این موضوع به احتمال زیاد یک اشکال برنامه‌نویسی است که باید گزارش شود. برنامه ممکن است خودبه‌خود بازیابی شود.
DHCP_DDNS_QUEUE_MGR_UNEXPECTED_STOP
0.0
3.5
دریافت مدیر صف برنامه
168u
168u
به‌طور غیرمنتظره‌ای لغو شد در حالی که وضعیت مدیر صف عبارت است از: %1
این یک پیام خطا است که نشان می‌دهد دریافت درخواست Queue Manager در DHCP_DDNS به‌طور غیرمنتظره‌ای قطع شده است. در حالت عادی، خواندن/دریافت فقط به عنوان بخش معمولی از فرایند متوقف‌سازی مدیر صف قطع می‌شود. این موضوع به احتمال زیاد یک اشکال برنامه‌نویسی است که باید گزارش شود.
DHCP_DDNS_REMOVE_FAILED
0.0
3.5
شناسه درخواست DHCP_DDNS %1: نتیجه تراکنش: %2
168u
168u
این یک پیام خطا است که پس از شکست تلاش‌های DHCP_DDNS برای ارسال درخواست‌های حذف مدخل نگاشت DNS صادر می‌شود. دلیل دقیق شکست باید در مدخل‌های قبلی گزارش وقایع مستند شده باشد.
DHCP_DDNS_REMOVE_SUCCEEDED
0.0
3.5
شناسه درخواست DHCP_DDNS %1: نگاشت افزوده‌شده DNS برای این درخواست با موفقیت حذف شد: %2
168u
168u
این یک پیام اطلاع‌رسانی است که پس از ارسال درخواست‌های حذف نگاشت DNS توسط DHCP_DDNS صادر می‌شود؛ درخواست‌هایی که توسط یک کارساز DNS مناسب دریافت و پذیرفته شده‌اند.
DHCP_DDNS_REQUEST_DROPPED
0.0
3.5
شناسه درخواست %1: درخواست شامل هیچ درخواست به‌روزرسانی فعال‌شده‌ای نیست و نادیده گرفته خواهد شد: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که DHCP_DDNS درخواستی دریافت کند که شامل به‌روزرسانی در جهتی که فعال شده است نباشد. به عبارت دیگر، اگر تنها به‌روزرسانی‌های مستقیم (forward) فعال باشند و درخواستی دریافت شود که فقط به‌روزرسانی‌های معکوس (reverse) را می‌خواهد، درخواست نادیده گرفته (drop) می‌شود.
DHCP_DDNS_REVERSE_REMOVE_BAD_DNSCLIENT_STATUS
0.0
3.5
شناسه درخواست DHCP_DDNS %1: وضعیت ناشناخته DNSClient دریافت شد: %2، هنگام حذف نگاشت آدرس معکوس برای FQDN %3 به کارساز DNS %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که DNSClient در حین حذف یک نگاشت آدرس معکوس توسط DHCP_DDNS، وضعیتی ناشناخته را بازگرداند. درخواست لغو خواهد شد. این موضوع به احتمال زیاد یک اشکال برنامه‌نویسی است و باید گزارش شود.
DHCP_DDNS_REVERSE_REMOVE_BUILD_FAILURE
0.0
3.5
شناسه درخواست DNS %1: پیام به‌روزرسانی برای حذف یک مدخل معکوس DNS از این درخواست ساخته نشد: %2، دلیل: %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام تلاش برای ساخت بسته ارسالی به کارساز جهت درخواست حذف PTR معکوس، خطایی رخ دهد. این امر به دلیل داده‌های نامعتبر موجود در NameChangeRequest است. درخواست لغو خواهد شد. این مشکل به احتمال زیاد یک مسئله پیکربندی است.
DHCP_DDNS_REVERSE_REMOVE_IO_ERROR
0.0
3.5
شناسه درخواست DHCP_DDNS %1: هنگام ارسال درخواست حذف نگاشت معکوس برای FQDN %2 به کارساز DNS %3 با یک خطای IO مواجه شد
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که در حین انجام عملیات حذف نگاشت معکوس توسط DHCP_DDNS، یک خطای ارتباطی رخ دهد. برنامه تلاش مجدد را در برابر همان کارساز یا کارسازهای دیگر بر حسب مورد انجام خواهد داد.
DHCP_DDNS_REVERSE_REMOVE_REJECTED
0.0
3.5
شناسه درخواست DNS %1: کارساز، %2، یک درخواست به‌روزرسانی DNS برای حذف نگاشت معکوس برای FQDN، %3 را با RCODE رد کرد: %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که یک به‌روزرسانی توسط کارساز DNS که به آن ارسال شده بود، به دلیلی که توسط RCODE مشخص شده است، رد شود. مقادیر rcode در RFC 2136 تعریف شده‌اند..SS DHCP_DDNS_REVERSE_REMOVE_RESP_CORRUPT
0.0
3.5
DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while removing reverse address mapping for FQDN, %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که پاسخ دریافت‌شده توسط DHCP_DDNS برای یک درخواست به‌روزرسانی جهت حذف یک آدرس معکوس، مخدوش یا دارای ساختار نادرست (malformed) باشد.
برنامه با توجه به شرایط، تلاش مجدد را روی همان سرور یا سایر سرورها انجام خواهد داد.
DHCP_DDNS_REVERSE_REMOVE_TIMEOUT
0.0
3.5
DHCP_DDNS Request ID %1: timed out waiting for a response to reverse mapping remove for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام انجام عملیات حذف نگاشت معکوس توسط DHCP_DDNS، پیش از اتمام مهلت زمانی dns-server-timeout هیچ پاسخی از سرور DNS دریافت نشود.
برنامه با توجه به شرایط، تلاش مجدد را روی همان سرور یا سایر سرورها انجام خواهد داد.
DHCP_DDNS_REVERSE_REPLACE_BAD_DNSCLIENT_STATUS
0.0
3.5
DHCP_DDNS Request ID %1: received an unknown DNSClient status: %2, while replacing reverse address mapping for FQDN %3 to DNS server %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام جایگزینی یک نگاشت آدرس معکوس توسط DHCP_DDNS، مؤلفه DNSClient وضعیتی ناشناخته را بازگرداند.
درخواست لغو خواهد شد.
این مسئله به احتمال زیاد یک اشکال برنامه‌نویسی است و باید گزارش شود.
DHCP_DDNS_REVERSE_REPLACE_BUILD_FAILURE
0.0
3.5
DNS Request ID %1: update message to replace a reverse DNS entry could not be constructed from this request: %2, reason: %3
168u
168u
این یک پیام خطا است و هنگامی رخ می‌دهد که در تلاش برای ساخت بسته ارسالی به سرور جهت درخواست جایگزینی PTR معکوس، خطایی پیش بیاید.
دلیل این امر، داده‌های نامعتبر موجود در NameChangeRequest است.
درخواست لغو خواهد شد.
این موضوع به احتمال زیاد یک مشکل در پیکربندی است.
DHCP_DDNS_REVERSE_REPLACE_IO_ERROR
0.0
3.5
DHCP_DDNS Request ID %1: encountered an IO error sending a reverse mapping replacement for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام جایگزینی یک نگاشت معکوس توسط DHCP_DDNS، خطای ارتباطی (I/O) رخ دهد.
برنامه با توجه به شرایط، تلاش مجدد را روی همان سرور یا سایر سرورها انجام خواهد داد.
DHCP_DDNS_REVERSE_REPLACE_REJECTED
0.0
3.5
DNS Request ID %1: Server, %2, rejected a DNS update request to replace the reverse mapping for FQDN, %3, with an RCODE: %4
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که یک به‌روزرسانی توسط سرور DNS مقصد، به دلیلی که در RCODE مشخص شده است رد شود.
مقادیر rcode در RFC 2136 تعریف شده‌اند.
DHCP_DDNS_REVERSE_REPLACE_RESP_CORRUPT
0.0
3.5
DHCP_DDNS Request ID %1: received a corrupt response from the DNS server, %2, while replacing reverse address mapping for FQDN, %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که پاسخ دریافت‌شده توسط DHCP_DDNS برای یک درخواست به‌روزرسانی جهت جایگزینی آدرس معکوس، مخدوش یا دارای ساختار نادرست (malformed) باشد.
برنامه با توجه به شرایط، تلاش مجدد را روی همان سرور یا سایر سرورها انجام خواهد داد.
DHCP_DDNS_REVERSE_REPLACE_TIMEOUT
0.0
3.5
DHCP_DDNS Request ID %1: timed out waiting for a response to reverse mapping replacement for FQDN %2 to DNS server %3
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام انجام عملیات جایگزینی نگاشت معکوس توسط DHCP_DDNS، پیش از سررسید مهلت زمانی dns-server-timeout هیچ پاسخی از سرور DNS دریافت نشود.
برنامه با توجه به شرایط، تلاش مجدد را روی همان سرور یا سایر سرورها انجام خواهد داد.
DHCP_DDNS_REV_REQUEST_IGNORED
0.0
3.5
Request ID %1: Reverse updates are disabled, the reverse portion of request will be ignored: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که به‌روزرسانی‌های معکوس DNS غیرفعال باشند و DHCP_DDNS یک درخواست به‌روزرسانی حاوی به‌روزرسانی معکوس DNS دریافت کند.
به‌روزرسانی معکوس انجام نخواهد شد..SS DHCP_DDNS_RUN_EXIT
0.0
3.5
application is exiting the event loop
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 0 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هنگام خروج کارساز DHCP-DDNS از حلقه
رویداد (event loop) خود صادر می‌شود.
DHCP_DDNS_SECURITY_CHECKS_DISABLED
0.0
3.5
Invoked with command line option -X, Security checks are disabled!!
168u
168u
این هشدار زمانی صادر می‌شود که بررسی‌های امنیتی داخلی که معمولاً
توسط kea-dhcp-ddns انجام می‌شوند، از طریق گزینه خط فرمان '-X' غیرفعال شده باشند.
این بدان معناست که کارساز محدودیت‌ها روی مسیرهای منابع یا مجوزها را
اعمال نمی‌کند. این حالت عملکرد ممکن است محیط شما را در معرض
آسیب‌پذیری‌های امنیتی قرار دهد و تنها باید پس از بررسی و ملاحظه دقیق
استفاده شود.
DHCP_DDNS_SHUTDOWN_COMMAND
0.0
3.5
application received shutdown command with args: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 0 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که پس از صدور دستور خاموش شدن برنامه توسط
کنترل‌کننده (controller) صادر می‌شود.
DHCP_DDNS_STARTED
0.0
3.5
Kea DHCP-DDNS server version %1 started
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کارساز DHCP-DDNS تمام اطلاعات
پیکربندی را پردازش کرده و آماده آغاز پردازش است.
نسخه برنامه نیز چاپ می‌شود.
DHCP_DDNS_STARTING_TRANSACTION
0.0
3.5
Request ID %1:
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 50 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هنگام آغاز یک تراکنش توسط DHCP-DDNS برای
یک درخواست مشخص صادر می‌شود.
DHCP_DDNS_STATE_MODEL_UNEXPECTED_ERROR
0.0
3.5
Request ID %1: application encountered an unexpected error while carrying out a NameChangeRequest: %2
168u
168u
این یک پیام خطا است که هنگام عدم موفقیت برنامه در پردازش صحیح یک
NameChangeRequest صادر می‌شود. بخشی از یا تمام به‌روزرسانی‌های DNS درخواست‌شده به عنوان بخشی
از این به‌روزرسانی با موفقیت انجام نشدند. این یک خطای برنامه‌نویسی است و باید
گزارش شود.
DHCP_DDNS_TRANS_SEND_ERROR
0.0
3.5
Request ID %1: application encountered an unexpected error while attempting to send a DNS update: %2
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که برنامه قادر به ساخت یک پیام
به‌روزرسانی بوده است، اما تلاش برای ارسال آن با خطایی غیرمنتظره مواجه شده است. این مورد
به احتمال زیاد یک خطای برنامه‌نویسی است تا یک مشکل ارتباطی. بخشی از یا تمام
به‌روزرسانی‌های DNS درخواست‌شده به عنوان بخشی از این درخواست موفقیت‌آمیز نبودند.
DHCP_DDNS_TSIG_SECRET_SECURITY_WARNING
0.0
3.5
use of clear text TSIG 'secret' is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال امنیت غیرفعال باشد
و در پیکربندی کلید TSIG به جای 'secret-file' از متن صریح 'secret'
استفاده شده باشد. کارساز همچنان از کلید پیکربندی‌شده استفاده خواهد کرد
اما هشدار می‌دهد که این کار ممکن است خطرات امنیتی در پی داشته باشد.
DHCP_DDNS_UDP_SENDER_WATCH_SOCKET_CLOSE_ERROR
0.0
3.5
watch socket failed to close: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد برنامه نتوانسته است
سمت ورودی یا خروجی سوکت نظارتی (watch socket) فرستنده NCR را ببندد. گرچه از نظر فنی
امکان‌پذیر است، اما وقوع این خطا بسیار بعید است و نباید توانایی
برنامه را در پردازش درخواست‌ها مختل کند..SS DHCP_DDNS_UNCAUGHT_NCR_RECV_HANDLER_ERROR
0.0
3.5
unexpected exception thrown from the application receive completion handler: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد یک استثنا (exception) رخ داده اما در گردانندهٔ اتمام دریافتِ درخواست برنامه گرفته نشده است. این یک خطای برنامه‌نویسی است که باید گزارش شود. بسته به ماهیت خطا، برنامه ممکن است به عملکرد عادی خود ادامه دهد یا ندهد.
DHCP_DDNS_UNCAUGHT_NCR_SEND_HANDLER_ERROR
0.0
3.5
unexpected exception thrown from the DHCP-DDNS client send completion handler: %1
168u
168u
این یک پیام خطا است که نشان می‌دهد یک استثنا رخ داده اما در گردانندهٔ اتمام ارسال کلاینت DHCP-DDNS گرفته نشده است. این یک خطای برنامه‌نویسی است که باید گزارش شود. بسته به ماهیت خطا، کلاینت ممکن است به عملکرد عادی خود ادامه دهد یا خیر.
DHCP_DDNS_UPDATE_REQUEST_SENT
0.0
3.5
Request ID %1: %2 to server: %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که DHCP_DDNS یک درخواست DNS را به یک سرور DNS ارسال می‌کند.
DHCP_DDNS_UPDATE_RESPONSE_RECEIVED
0.0
3.5
Request ID %1: to server: %2 status: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که DHCP_DDNS یک پاسخ به‌روزرسانی DNS را از یک سرور DNS دریافت می‌کند.
DHCP_DELETE_ALL_EXTERNAL_SOCKETS_BAD_THREAD
0.0
3.5
Attempted to unregister external sockets from different thread %1 than main thread %2
168u
168u
این پیام خطا نشان می‌دهد که ریسه‌ای (thread) غیر از ریسهٔ اصلی تمام سوکت‌های خارجی را حذف کرده است. این یک خطای برنامه‌نویسی است و باید اصلاح شود. تنها ریسهٔ اصلی مجاز به انجام عملیات روی سوکت‌های خارجی است. شناسه‌های ریسه مربوطه در پیام گنجانده شده‌اند.
DHCP_DELETE_EXTERNAL_SOCKET_BAD_THREAD
0.0
3.5
Attempted to unregister external socket %1 from different thread %2 than main thread %3
168u
168u
این پیام خطا نشان می‌دهد که ریسه‌ای غیر از ریسهٔ اصلی یک سوکت خارجی را لغو ثبت کرده است. این یک خطای برنامه‌نویسی است و باید اصلاح شود. تنها ریسهٔ اصلی مجاز به انجام عملیات روی سوکت‌های خارجی است. توصیف‌کنندهٔ فایل (file descriptor) و شناسه‌های ریسه مربوطه در پیام گنجانده شده‌اند.
DHCP_DELETE_EXTERNAL_SOCKET_NOT_FOUND
0.0
3.5
Deleting a not found external socket %1
168u
168u
این پیام هشدار نشان می‌دهد که یک سوکت خارجی حذف شده اما یافت نمی‌شود؛ یعنی افزودن‌ها و حذف‌ها به درستی متوازن نیستند.
DHCP_IFACE_OPEN_SOCKET
0.0
3.5
Opened socket on the interface %1 with address %2 and port %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک سوکت برای یک رابط (interface) مشخص باز شده است. نام رابط، آدرس و درگاه (port) ثبت می‌شوند.
DHCP_IFACE_SOCKET_ERROR
0.0
3.5
Got an error on the interface socket %1 of interface %2: %3
168u
168u
این پیام خطا نشان می‌دهد که خطایی روی سوکت رابط رخ داده است. توصیف‌کنندهٔ فایل، نام رابط و پیام خطا نمایش داده می‌شوند.
DHCP_RECEIVE4_UNKNOWN
0.0
3.5
Received data over unknown socket
168u
168u
این پیام هشدار نشان می‌دهد که گردانندهٔ رویدادِ توصیف‌کنندهٔ فایل با داده‌های دریافت‌شده بازگشته است، اما امکان تشخیص اینکه مربوط به کدام‌یک بوده وجود نداشته است..SS DHCP_RECEIVE6_UNKNOWN
0.0
3.5
Received data over unknown socket
168u
168u
این پیام هشدار نشان می‌دهد که گرداننده رویداد توصیف‌کننده فایل (file descriptor event handler) با داده‌های دریافت‌شده بازمی‌گردد، اما امکان یافتن این‌که کدام‌یک بوده وجود نداشته است.
EVAL
EVAL_DEBUG_AND
0.0
3.5
%1: Popping %2 and %3 pushing %4
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دو مقدار از پشته مقادیر پاپ (pop) می‌شوند. سپس از طریق "and" منطقی با یکدیگر ترکیب شده و نتیجه روی پشته مقادیر پوش (push) می‌شود.
EVAL_DEBUG_BRANCH
0.0
3.5
Branching to %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک انشعاب بدون شرط به مقصد نمایش‌داده‌شده انجام می‌شود.
EVAL_DEBUG_CONCAT
0.0
3.5
%1: Popping %2 and %3 pushing %4
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دو رشته از پشته پاپ می‌شوند. سپس به یکدیگر متصل شده و رشته حاصل روی پشته پوش می‌شود. رشته‌ها در قالب هگزادسیمال نمایش داده می‌شوند.
EVAL_DEBUG_EQUAL
0.0
3.5
%1: Popping %2 and %3 pushing result %4
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دو رشته از پشته مقادیر پاپ می‌شوند و نتیجه مقایسه آن‌ها روی پشته مقادیر پوش می‌شود. رشته‌ها در قالب هگزادسیمال نمایش داده می‌شوند.
EVAL_DEBUG_HEXSTRING
0.0
3.5
%1: Pushing hex string %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشته دودویی (binary) داده‌شده روی پشته مقادیر پوش می‌شود. رشته در قالب هگزادسیمال نمایش داده می‌شود.
EVAL_DEBUG_IFELSE_FALSE
0.0
3.5
%1: Popping %2 (false) and %3, leaving %4
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که شرط نادرست (false) است، بنابراین مقدار شاخه iftrue حذف شده و مقدار شاخه ifelse روی پشته مقادیر باقی می‌ماند.
EVAL_DEBUG_IFELSE_TRUE
0.0
3.5
%1: Popping %2 (true) and %3, leaving %4
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که شرط درست (true) است، بنابراین مقدار شاخه ifelse حذف شده و مقدار شاخه iftrue روی پشته مقادیر باقی می‌ماند.
EVAL_DEBUG_INT16TOTEXT
0.0
3.5
%1: Pushing Int16 %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای آدرس داده‌شده روی پشته مقادیر پوش می‌شود. این مقدار نشان‌دهنده یک عدد صحیح ۱۶ بیتی است..SS EVAL_DEBUG_INT32TOTEXT
0.0
3.5
%1: Pushing Int32 %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای نشانی داده‌شده روی
پشتهٔ مقادیر (value stack) قرار داده می‌شود (push). این مقدار بیانگر یک عدد صحیح ۳۲ بیتی است.
EVAL_DEBUG_INT8TOTEXT
0.0
3.5
%1: Pushing Int8 %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای نشانی داده‌شده روی
پشتهٔ مقادیر (value stack) قرار داده می‌شود (push). این مقدار بیانگر یک عدد صحیح ۸ بیتی است.
EVAL_DEBUG_IPADDRESS
0.0
3.5
%1: Pushing IPAddress %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشتهٔ باینری داده‌شده روی پشتهٔ مقادیر
قرار داده می‌شود (push). این مقدار بیانگر یک نشانی IPv4 یا IPv6 است.
رشته به صورت هگزادسیمال (hex) نمایش داده می‌شود.
EVAL_DEBUG_IPADDRESSTOTEXT
0.0
3.5
%1: Pushing IPAddress %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای نشانی داده‌شده روی
پشتهٔ مقادیر (value stack) قرار داده می‌شود (push). این مقدار بیانگر یک نشانی IPv4 یا IPv6 است.
EVAL_DEBUG_LCASE
0.0
3.5
%1: Popping string %2 and pushing converted value to lower case %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای داده‌شده به حروف کوچک
تبدیل شده و روی پشتهٔ مقادیر (value stack) قرار می‌گیرد (push).
EVAL_DEBUG_MATCH
0.0
3.5
Matching '%1' on %2, result %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت باقاعده (regular expression) داده‌شده
با مقدار برداشته‌شده از پشته (popped) مطابقت داده شد. نتیجه روی پشتهٔ مقادیر قرار گرفت (push).
EVAL_DEBUG_MATCH_ERROR
0.0
3.5
Matching '%1' on %2 raised an error: %3
168u
168u
این پیام خطا نشان می‌دهد که هنگام ارزیابی عبارت باقاعده (regular expression) داده‌شده
در برابر مقدار برداشته‌شده از پشته، خطایی رخ داده است.
EVAL_DEBUG_MEMBER
0.0
3.5
%1: Checking membership of '%2', pushing result %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عضویت بسته برای کلاس کلاینت
(client class) بررسی شده است.
EVAL_DEBUG_NOT
0.0
3.5
%1: Popping %2 pushing %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که نخستین مقدار از پشتهٔ مقادیر برداشته می‌شود (pop)،
نقیض شده و سپس روی پشتهٔ مقادیر قرار می‌گیرد (push).
رشته به صورت متنی نمایش داده می‌شود.
EVAL_DEBUG_OPTION
0.0
3.5
%1: Pushing option %2 with value %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشتهٔ داده‌شده که مقدار گزینهٔ درخواستی
را مشخص می‌کند، روی پشتهٔ مقادیر قرار می‌گیرد (push).
بسته به نوع بازنمایی درخواستی (.text یا .hex)، رشته ممکن است متنی یا باینری باشد،
یا چنانچه نوع درخواستی .exists باشد، مقدار "true" یا "false" خواهد بود.
کد گزینه می‌تواند برای یک گزینه (option) یا یک زیرگزینه (sub-option) باشد،
همان‌گونه که در عبارت دسته‌بندی درخواست شده است..SS EVAL_DEBUG_OR
0.0
3.5
%1: Popping %2 and %3 pushing %4
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دو مقدار از پشتهٔ مقادیر برداشته می‌شوند (pop). سپس از طریق "or" منطقی با هم ترکیب شده و نتیجه بر روی پشتهٔ مقادیر قرار می‌گیرد (push). رشته به صورت متنی نمایش داده می‌شود.
EVAL_DEBUG_PKT
0.0
3.5
%1: Pushing PKT meta data %2 with value %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشته باینری داده‌شده که بیانگر مقدار فرا‌دادهٔ (meta data) درخواستی است، بر روی پشتهٔ مقادیر قرار می‌گیرد. رشته، به استثنای نام رابط (interface)، در مبنای شانزده (hex) نمایش داده می‌شود.
EVAL_DEBUG_PKT4
0.0
3.5
%1: Pushing PKT4 field %2 with value %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشته باینری داده‌شده که بیانگر مقدار فیلد درخواستی است، بر روی پشتهٔ مقادیر قرار می‌گیرد. رشته در مبنای شانزده (hex) نمایش داده می‌شود.
EVAL_DEBUG_PKT6
0.0
3.5
%1: Pushing PKT6 field %2 with value %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشته باینری داده‌شده که بیانگر مقدار فیلد درخواستی است، بر روی پشتهٔ مقادیر قرار می‌گیرد. رشته در مبنای شانزده (hex) نمایش داده می‌شود.
EVAL_DEBUG_POP_AND_BRANCH_FALSE
0.0
3.5
Value is false: branching to %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک انشعاب بر اساس شرط نادرست (false) به مقصد نمایش‌داده‌شده انجام می‌شود.
EVAL_DEBUG_POP_OR_BRANCH_FALSE
0.0
3.5
Value is false: keeping it and branching to %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک انشعاب بر اساس شرط نادرست (false) به مقصد نمایش‌داده‌شده انجام می‌شود.
EVAL_DEBUG_POP_OR_BRANCH_TRUE
0.0
3.5
Value is true: keeping it and branching to %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک انشعاب بر اساس شرط درست (true) به مقصد نمایش‌داده‌شده انجام می‌شود.
EVAL_DEBUG_RELAY6
0.0
3.5
%1: Pushing PKT6 relay field %2 nest %3 with value %4
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشته باینری داده‌شده که بیانگر مقدار فیلد درخواستی است، بر روی پشتهٔ مقادیر قرار می‌گیرد. رشته در مبنای شانزده (hex) نمایش داده می‌شود.
EVAL_DEBUG_RELAY6_RANGE
0.0
3.5
%1: Pushing PKT6 relay field %2 nest %3 with value %4
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی در صورتی تولید می‌شود که فیلد nest خارج از محدوده باشد. مقداری که بر روی پشته قرار می‌گیرد همواره رشتهٔ خالی خواهد بود..SS EVAL_DEBUG_SPLIT
0.0
3.5
%1: Popping field %2, delimiters %3, string %4, pushing result %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که سه مقدار از پشته برداشته شده
و یک نتیجه روی پشته قرار می‌گیرد. مقادیر برداشته‌شده عبارت‌اند از
فیلد، جداکننده و رشته. نتیجه، فیلد استخراج‌شده است که روی
پشته قرار می‌گیرد. رشته‌ها به‌صورت hex نمایش داده می‌شوند.
EVAL_DEBUG_SPLIT_DELIM_EMPTY
0.0
3.5
%1: Popping field %2, delimiters %3, string %4, pushing result %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که جداکنندهٔ برداشته‌شده از پشته خالی بوده
و بنابراین نتیجه، کل رشته خواهد بود. فیلد، جداکننده و رشته
همچنان از پشته برداشته شده و نتیجه همچنان روی پشته قرار می‌گیرد.
EVAL_DEBUG_SPLIT_EMPTY
0.0
3.5
%1: Popping field %2, delimiters %3, string %4, pushing result %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشتهٔ برداشته‌شده از پشته خالی بوده
و بنابراین نتیجه نیز خالی خواهد بود. فیلد، جداکننده و رشته همچنان
از پشته برداشته شده و نتیجه همچنان روی پشته قرار می‌گیرد.
EVAL_DEBUG_SPLIT_FIELD_OUT_OF_RANGE
0.0
3.5
%1: Popping field %2, delimiters %3, string %4, pushing result %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که فیلد یا کمتر از یک است یا بزرگ‌تر
از تعداد فیلدهای موجود در رشتهٔ برداشته‌شده از پشته. نتیجه
خالی خواهد بود. فیلد، جداکننده و رشته همچنان از پشته برداشته شده و
نتیجه همچنان روی پشته قرار می‌گیرد.
EVAL_DEBUG_STRING
0.0
3.5
%1: Pushing text string %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشتهٔ متنی ارائه‌شده روی
پشتهٔ مقادیر قرار می‌گیرد. رشته به‌صورت متن نمایش داده می‌شود.
EVAL_DEBUG_SUBSTRING
0.0
3.5
%1: Popping length %2, start %3, string %4 pushing result %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که سه مقدار از
پشتهٔ مقادیر برداشته شده و یک نتیجه روی پشتهٔ مقادیر قرار می‌گیرد. مقادیر
برداشته‌شده، نقطهٔ شروع و طول زیررشته‌ای هستند که باید
از رشتهٔ ارائه‌شده استخراج شود. رشتهٔ حاصل روی
پشته قرار می‌گیرد. رشته‌ها به‌صورت hex نمایش داده می‌شوند.
EVAL_DEBUG_SUBSTRING_EMPTY
0.0
3.5
%1: Popping length %2, start %3, string %4 pushing result %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که رشتهٔ برداشته‌شده از پشته خالی بوده
و بنابراین نتیجه نیز خالی خواهد بود. نقطهٔ شروع، طول و رشته
همچنان از پشته برداشته شده و نتیجه همچنان روی پشته قرار می‌گیرد.
EVAL_DEBUG_SUBSTRING_RANGE
0.0
3.5
%1: Popping length %2, start %3, string %4 pushing result %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که مقدار start خارج از محدودهٔ
رشته بوده و یک نتیجهٔ خالی روی پشته قرار خواهد گرفت. نقطهٔ شروع،
طول و رشته همچنان از پشته برداشته شده و نتیجه
همچنان روی پشته قرار می‌گیرد. رشته‌ها به‌صورت hex نمایش داده می‌شوند.
EVAL_DEBUG_SUB_OPTION
0.0
3.5
%1: Pushing option %2 sub-option %3 with value %4
168u
168u
این پیام اشکال‌زدایی نشان می‌دهد رشتهٔ ارائه‌شده که نشان‌دهندهٔ
مقدار زیرگزینهٔ (sub-option) درخواستی از گزینهٔ والد مورد نظر است،
روی پشتهٔ مقادیر قرار می‌گیرد. رشته می‌تواند بر اساس نوع بازنمایی
درخواست‌شده (.text یا .hex) مقدار متنی یا باینری رشته باشد،
یا اگر نوع درخواستی .exists باشد، مقدار "true" یا "false" خواهد بود.
کدها کدهای گزینهٔ والد و زیرگزینه هستند، همان‌گونه که در
عبارت رده‌بندی درخواست شده‌اند..SS EVAL_DEBUG_SUB_OPTION_NO_OPTION
0.0
3.5
%1: Requested option %2 sub-option %3, but the parent option is not present, pushing result %4
168u
168u
این پیام اشکال‌زدایی نشان می‌دهد که گزینهٔ والد یافت نشد.
کدها همان کدهای گزینهٔ والد و زیرگزینه (sub-option) هستند که در عبارت
دسته‌بندی (classification statement) درخواست شده بودند.
EVAL_DEBUG_TOHEXSTRING
0.0
3.5
%1: Popping binary value %2 and separator %3, pushing result %4
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که دو مقدار از پشتهٔ مقادیر برداشته
شده (pop) و نتیجه‌ای در پشتهٔ مقادیر قرار می‌گیرد (push). مقادیر
برداشته‌شده شامل مقدار باینری برای تبدیل و جداکننده هستند.
مقدار باینری به بازنمایی رشته‌ای هگزادسیمال خود تبدیل شده
و در پشته قرار می‌گیرد. مقدار باینری به صورت هگز (hex) نمایش داده می‌شود.
EVAL_DEBUG_UCASE
0.0
3.5
%1: Popping string %2 and pushing converted value to upper case %3
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای داده‌شده به
حروف بزرگ تبدیل شده و در پشتهٔ مقادیر قرار می‌گیرد.
EVAL_DEBUG_UINT16TOTEXT
0.0
3.5
%1: Pushing UInt16 %2
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای آدرسِ داده‌شده در
پشتهٔ مقادیر قرار می‌گیرد. این مقدار نشان‌دهندهٔ یک عدد صحیح ۱۶ بیتی بدون علامت است.
EVAL_DEBUG_UINT32TOTEXT
0.0
3.5
%1: Pushing UInt32 %2
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای آدرسِ داده‌شده در
پشتهٔ مقادیر قرار می‌گیرد. این مقدار نشان‌دهندهٔ یک عدد صحیح ۳۲ بیتی بدون علامت است.
EVAL_DEBUG_UINT8TOTEXT
0.0
3.5
%1: Pushing UInt8 %2
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که بازنمایی رشته‌ای آدرسِ داده‌شده در
پشتهٔ مقادیر قرار می‌گیرد. این مقدار نشان‌دهندهٔ یک عدد صحیح ۸ بیتی بدون علامت است.
EVAL_DEBUG_VENDOR_CLASS_DATA
0.0
3.5
%1: Data %2 (out of %3 received) in vendor class found, pushing result '%4'
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که گزینهٔ vendor class پیدا شده، بررسی‌های
enterprise-id را با موفقیت گذرانده و تعداد تکه‌های داده (data chunks) آن کافی است.
تعداد کل تکه‌ها و مقدار ارائه‌شده، جهت کمک به اشکال‌زدایی گزارش می‌شوند.
EVAL_DEBUG_VENDOR_CLASS_DATA_NOT_FOUND
0.0
3.5
%1: Requested data index %2, but option with enterprise-id %3 has only %4 data tuple(s), pushing result '%5'
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که گزینهٔ vendor class پیدا شده و بررسی‌های
enterprise-id را با موفقیت گذرانده است، اما تعداد تکه‌های دادهٔ آن کافی نیست.
توجه داشته باشید که ایندکس از 0 شروع می‌شود، بنابراین باید حداقل
(index + 1) تکه داده وجود داشته باشد.
EVAL_DEBUG_VENDOR_CLASS_ENTERPRISE_ID
0.0
3.5
%1: Pushing enterprise-id %2 as result 0x%3
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده، گزینهٔ vendor
class یافت شده و enterprise-id آن در حال گزارش است..SS EVAL_DEBUG_VENDOR_CLASS_ENTERPRISE_ID_MISMATCH
0.0
3.5
%1: Was looking for %2, option had %3, pushing result '%4'
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده و گزینه vendor class پیدا شده است، اما enterprise-id آن با مقدار مشخص‌شده در عبارت متفاوت است.
EVAL_DEBUG_VENDOR_CLASS_EXISTS
0.0
3.5
%1: Option with enterprise-id %2 found, pushing result '%3'
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده و گزینه vendor class پیدا شده است.
EVAL_DEBUG_VENDOR_CLASS_NO_OPTION
0.0
3.5
%1: Option with code %2 missing, pushing result '%3'
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده اما گزینه vendor class یافت نشده است.
EVAL_DEBUG_VENDOR_ENTERPRISE_ID
0.0
3.5
%1: Pushing enterprise-id %2 as result 0x%3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده، گزینه vendor پیدا شده و enterprise-id آن گزارش می‌شود.
EVAL_DEBUG_VENDOR_ENTERPRISE_ID_MISMATCH
0.0
3.5
%1: Was looking for %2, option had %3, pushing result '%4'
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده و گزینه vendor پیدا شده است، اما enterprise-id آن با مقدار مشخص‌شده در عبارت متفاوت است.
EVAL_DEBUG_VENDOR_EXISTS
0.0
3.5
%1: Option with enterprise-id %2 found, pushing result '%3'
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده و گزینه vendor پیدا شده است.
EVAL_DEBUG_VENDOR_NO_OPTION
0.0
3.5
%1: Option with code %2 missing, pushing result '%3'
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که عبارت ارزیابی شده اما گزینه vendor یافت نشده است.
FLEX
FLEX_ID_EXPRESSION_EVALUATED
0.0
3.5
Expression evaluated for packet to "%1" (size: %2)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هر بار که ارزیابی یک بسته موفقیت‌آمیز باشد چاپ می‌شود.
این بدان معناست که عبارت شناسه تولید شده است. توجه داشته باشید که
بسته به عبارت و محتوای بسته دریافتی، عبارت ممکن است به یک رشته خالی ارزیابی شود.
FLEX_ID_EXPRESSION_EVALUATED_NP
0.0
3.5
Expression evaluated for packet to 0x%1 (size: %2)
168u
168u
این پیام اشکال‌زدایی هر بار که ارزیابی یک بسته موفقیت‌آمیز باشد چاپ می‌شود.
این بدان معناست که عبارت شناسه تولید شده است. از آنجا که مقدار آن
قابل چاپ نیست، به مبنای شانزده (هگزادسیمال) تبدیل می‌شود..SS FLEX_ID_EXPRESSION_HEX
0.0
3.5
عبارت ارزیابی‌شده در قالب هگزادسیمال "%1"
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی، نمایشی هگزادسیمال از عبارت ارزیابی‌شده ارائه می‌دهد.
این مورد برای اهداف اشکال‌زدایی مفید است، چرا که لاگ‌های بعدی از قالب
هگزادسیمال برای ثبت وقایع استفاده می‌کنند.
FLEX_ID_EXPRESSION_INVALID_JSON_TYPE
0.0
3.5
عبارت identifier-expression برابر با %1 است، اما رشته JSON مورد انتظار بود
168u
168u
این پیام خطا هنگامی چاپ می‌شود که کتابخانه flex-id در حال بارگذاری است،
اما عبارت استفاده‌شده برای تولید شناسه ناصحیح (بدشکل) است. این عبارت
نوع JSON متفاوتی (برای نمونه یک map) به‌جای رشته مورد انتظار دارد.
FLEX_ID_EXPRESSION_PARSE_FAILED
0.0
3.5
عبارت identifier-expression برابر با [%1] است، اما تجزیه آن با خطای %2 شکست می‌خورد
168u
168u
این پیام خطا هنگامی چاپ می‌شود که کتابخانه flex-id در حال بارگذاری است،
اما عبارت استفاده‌شده برای تولید شناسه بدشکل است و تجزیه آن با
شکست مواجه شده است.
FLEX_ID_IGNORE_IAID_APPLIED_ON_NA
0.0
3.5
گزینه ignore-iaid مقدار IAID (%1) را برای گزینه IA_NA به 0 تغییر داده است.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام DEBUG هنگامی چاپ می‌شود که کتابخانه flex-id پرچم ignore-iaid را
اعمال کرده و مقدار IAID را به 0 تغییر داده است، زیرا بسته دریافتی دقیقاً
شامل یک IA_NA است.
FLEX_ID_IGNORE_IAID_APPLIED_ON_PD
0.0
3.5
گزینه ignore-iaid مقدار IAID (%1) را برای گزینه IA_PD به 0 تغییر داده است.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام DEBUG هنگامی چاپ می‌شود که کتابخانه flex-id پرچم ignore-iaid را
اعمال کرده و مقدار IAID را به 0 تغییر داده است، زیرا بسته دریافتی دقیقاً
شامل یک IA_PD است.
FLEX_ID_IGNORE_IAID_ENABLED
0.0
3.5
گزینه ignore-iaid تنظیم شده است. این گزینه فقط بر روی کلاینت‌هایی با حداکثر یک IA_NA و یک IA_PD تأثیر دارد.
168u
168u
این پیام هشدار (WARNING) هنگامی چاپ می‌شود که کتابخانه flex-id در حال بارگذاری
بوده و پارامتر ignore-iaid تنظیم شده است. این پرچم به سرور امکان می‌دهد
بسته‌هایی را که حاوی بیش از یک IA_NA و یک IA_PD هستند دور بیندازد.
FLEX_ID_IGNORE_IAID_JSON_TYPE
0.0
3.5
مقدار ignore-iaid برابر با %1 است اما مقدار boolean مورد انتظار بود
168u
168u
این پیام خطا هنگامی چاپ می‌شود که کتابخانه flex-id در حال بارگذاری است،
اما پارامتر ignore-iaid بدشکل است، یعنی نوعی متفاوت از نوع مورد انتظار دارد.
انتظار می‌رود مقدار آن یک مقدار boolean باشد.
FLEX_ID_IGNORE_IAID_NOT_APPLIED_ON_NA
0.0
3.5
گزینه ignore-iaid روی بسته اعمال نشد زیرا حاوی بیش از یک IA_NA است.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام هشدار (WARNING) هنگامی چاپ می‌شود که کتابخانه flex-id پرچم
ignore-iaid را اعمال نکرده است، زیرا بسته دریافتی حاوی بیش از یک IA_NA است.
FLEX_ID_IGNORE_IAID_NOT_APPLIED_ON_PD
0.0
3.5
گزینه ignore-iaid روی بسته اعمال نشد زیرا حاوی بیش از یک IA_PD است.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام هشدار (WARNING) هنگامی چاپ می‌شود که کتابخانه flex-id پرچم
ignore-iaid را اعمال نکرده است، زیرا بسته دریافتی حاوی بیش از یک IA_PD است..SS FLEX_ID_LOAD_ERROR
0.0
3.5
خطایی هنگام بارگذاری کتابخانه %1 رخ داد
168u
168u
این پیام خطا زمانی چاپ می‌شود که در حین بارگذاری کتابخانه خطایی رخ دهد.
جزئیات مشکل به عنوان پارامتر این پیام چاپ می‌شوند.
FLEX_ID_NO_IDENTIFIER_EXPRESSION
0.0
3.5
identifier-expression یا مشخص نشده یا خالی است
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی چاپ می‌شود که کتابخانه flex-id در حال بارگذاری است،
اما عبارت مورد استفاده برای تولید شناسه، تعیین‌نشده یا خالی است. کتابخانه
بارگذاری خواهد شد، اما شناسه‌های کلاینت را نه تولید می‌کند و نه جایگزین.
معمولاً این حالت زمانی رخ می‌دهد که کاربران تنها مایل به استفاده از ignore-iaid هستند
که مستقل از این عبارت عمل می‌کند.
FLEX_ID_REPLACE_CLIENT_ID_JSON_TYPE
0.0
3.5
مقدار replace-client-id برابر %1 است اما مقدار بولی مورد انتظار بود
168u
168u
این پیام خطا زمانی چاپ می‌شود که کتابخانه flex-id در حال بارگذاری است،
اما پارامتر replace-client-id ساختار نادرستی دارد، یعنی نوع متفاوتی نسبت به آنچه
انتظار می‌رفت دارد. انتظار می‌رود که این پارامتر یک مقدار بولی (boolean) باشد.
FLEX_ID_RESTORE_CLIENT_ID
0.0
3.5
بازیابی شناسه کلاینت اصلی '%1' در پاسخ
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که شناسه کلاینت اصلی (ارائه‌شده توسط کلاینت)
در پاسخ سرور بازیابی می‌شود.
FLEX_ID_RESTORE_DUID
0.0
3.5
بازیابی DUID اصلی "%1" در پاسخ
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که شناسه کلاینت اصلی (ارائه‌شده توسط کلاینت)
در پاسخ سرور بازیابی می‌شود.
FLEX_ID_UNLOAD
0.0
3.5
کتابخانه Flex-id تخلیه شد.
168u
168u
این پیام اطلاع‌رسانی بیانگر آن است که کتابخانه flexible-identifier تخلیه شده است.
FLEX_ID_USED_AS_CLIENT_ID
0.0
3.5
استفاده از شناسه منعطف "%1" به عنوان شناسه کلاینت
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی برای نشان دادن این موضوع صادر می‌شود که کتابخانه در حال حذف شناسه کلاینت
ارائه‌شده توسط کلاینت از پیام دریافتی، و درج شناسه کلاینت مبتنی بر شناسه منعطف به جای آن است.
سرور از این شناسه کلاینت جدید برای پردازش بسته استفاده خواهد کرد. شناسه کلاینت اصلی
در فراخوانی pkt4_send بازیابی شده و برای کلاینت پس فرستاده خواهد شد.
FLEX_ID_USED_AS_DUID
0.0
3.5
استفاده از شناسه منعطف "%1" به عنوان DUID
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی برای نشان دادن این موضوع صادر می‌شود که کتابخانه در حال حذف DUID
ارائه‌شده توسط کلاینت از پیام دریافتی، و درج DUID مبتنی بر شناسه منعطف به جای آن است.
سرور از این DUID جدید برای پردازش بسته استفاده خواهد کرد. DUID اصلی در فراخوانی
pkt6_send بازیابی شده و برای کلاینت پس فرستاده خواهد شد.
FLEX_OPTION_LOAD_ERROR
0.0
3.5
بارگذاری کتابخانه قلاب‌های Flex Option ناموفق بود: %1
168u
168u
این پیام خطا نشان‌دهنده بروز خطا در حین بارگذاری کتابخانه قلاب‌های Flex Option است.
جزئیات خطا به عنوان آرگومان پیام گزارش ارائه می‌شود..SS FLEX_OPTION_PROCESS_ADD
0.0
3.5
Added the option code %1 with value %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک گزینه به بستهٔ پاسخ افزوده شده باشد. کد گزینه و مقدار آن (در صورت قابل چاپ بودن درون گیومه، و در غیر این صورت به صورت هگزادسیمال) ارائه می‌شوند.
FLEX_OPTION_PROCESS_CLIENT_CLASS
0.0
3.5
Skip processing of the option code %1 for class '%2'
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که از پردازش یک گزینه صرف‌نظر شده است، چرا که پرس‌وجو به کلاس کلاینت تعلق ندارد. کد گزینه و نام کلاس کلاینت ارائه می‌شوند.
FLEX_OPTION_PROCESS_ERROR
0.0
3.5
An error occurred processing query %1: %2
168u
168u
این پیام خطا نشان‌دهندهٔ بروز خطا در حین پردازش یک پرس‌وجو توسط کتابخانهٔ قلاب‌های Flex Option است. اطلاعات شناسایی کلاینت از پرس‌وجو و جزئیات خطا به عنوان آرگومان‌های پیام لاگ ارائه می‌شوند.
FLEX_OPTION_PROCESS_REMOVE
0.0
3.5
Removed option code %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک گزینه از بستهٔ پاسخ حذف شده باشد. کد گزینه ارائه می‌شود.
FLEX_OPTION_PROCESS_SUB_ADD
0.0
3.5
Added the sub-option code %1 in option code %2 with value %3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک زیرگزینه به بستهٔ پاسخ افزوده شده باشد. کدهای زیرگزینه و گزینهٔ دربرگیرنده، و مقدار آن (در صورت قابل چاپ بودن درون گیومه، و در غیر این صورت به صورت هگزادسیمال) ارائه می‌شوند.
FLEX_OPTION_PROCESS_SUB_CLIENT_CLASS
0.0
3.5
Skip processing of the sub-option code %1 in option code %2 for class '%3'
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که از پردازش یک زیرگزینه صرف‌نظر شده است، چرا که پرس‌وجو به کلاس کلاینت تعلق ندارد. کدهای زیرگزینه و گزینهٔ دربرگیرنده، و نام کلاس کلاینت ارائه می‌شوند.
FLEX_OPTION_PROCESS_SUB_REMOVE
0.0
3.5
Removed sub-option code %1 in option code %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک زیرگزینه از بستهٔ پاسخ حذف شده باشد. کدهای زیرگزینه و گزینهٔ دربرگیرنده ارائه می‌شوند.
FLEX_OPTION_PROCESS_SUB_SUPERSEDE
0.0
3.5
Supersedes the sub-option code %1 in option code %2 with value %3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک زیرگزینه در بستهٔ پاسخ جایگزین شده باشد. کدهای زیرگزینه و گزینهٔ دربرگیرنده، و مقدار آن (در صورت قابل چاپ بودن درون گیومه، و در غیر این صورت به صورت هگزادسیمال) ارائه می‌شوند.
FLEX_OPTION_PROCESS_SUPERSEDE
0.0
3.5
Supersedes the option code %1 with value %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک گزینه در بستهٔ پاسخ جایگزین شده باشد. کد گزینه و مقدار آن (در صورت قابل چاپ بودن درون گیومه، و در غیر این صورت به صورت هگزادسیمال) ارائه می‌شوند..SS FLEX_OPTION_PROCESS_VENDOR_ID_MISMATCH
0.0
3.5
Skip processing of vendor option code %1 with vendor id %2 not matching wanted %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی چاپ می‌شود که یک زیر-گزینه از vendor option پردازش می‌شود، اما vendor idها مطابقت ندارند. کد vendor option و هر دو vendor id ارائه شده‌اند.
FLEX_OPTION_UNLOAD
0.0
3.5
Flex Option hooks library has been unloaded
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانهٔ قلاب‌های (hooks library) Flex Option از حافظه خارج (unload) شده است.
FUZZ
FUZZ_DATA_READ
0.0
3.5
read %1 byte(s) from AFL via stdin
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
پیام اشکال‌زدایی خروجی که مشخص می‌کند چه مقدار داده از طریق stdin از fuzzer دریافت شده است.
FUZZ_INIT_COMPLETE
0.0
3.5
fuzz initialization complete: interface %1, address %2, port %3, max loops %4
168u
168u
یک پیام اطلاعاتی خروجی که پس از تکمیل موفقیت‌آمیز تابع مقداردهی اولیهٔ fuzzing صادر می‌شود. پارامترهای فهرست‌شده مواردی هستند که باید/می‌توانند از طریق متغیرهای محیطی تنظیم شوند.
FUZZ_INIT_FAIL
0.0
3.5
fuzz initialization failure, reason: %1
168u
168u
یک پیام خطا که در صورت شکست مقداردهی اولیهٔ fuzzing گزارش می‌شود. دلیل شکست در پیام آورده شده است.
FUZZ_READ_FAIL
0.0
3.5
error reading input from fuzzer: %1
168u
168u
این خطا در صورتی گزارش می‌شود که خواندن داده از fuzzer (که از طریق stdin دریافت می‌شود) شکست بخورد، یا خواندن مقدار صفر بایت را بازگرداند. در صورت وقوع این حالت، ریسه (thread) قبل از تلاش مجدد برای خواندن، مدت کوتاهی به خواب می‌رود. این پیام شامل دلیل شکست است.
FUZZ_SEND
0.0
3.5
sent %1 byte(s) to the socket connected to the Kea interface
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
یک پیام اشکال‌زدایی حاکی از آنکه فراخوانی sendto() در تابع اصلی fuzzing با موفقیت به پایان رسیده و تعداد بایت‌های ارسال‌شده را گزارش می‌دهد. این فراخوانی داده‌های دریافتی از AFL را به پورتی که Kea روی آن گوش می‌دهد ارسال می‌کند.
FUZZ_SEND_ERROR
0.0
3.5
failed to send data to Kea input socket: %1
168u
168u
این خطا زمانی گزارش می‌شود که فراخوانی sendto() در ریسهٔ fuzzing (که داده‌های دریافت‌شده از AFL را به سوکتی که Kea روی آن گوش می‌دهد ارسال می‌کند) با شکست مواجه شود. دلیل این شکست در پیام آورده شده است. کد fuzzing تلاش می‌کند از این حالت عبور کرده و ادامه دهد، اما ممکن است باعث شکست کل فرایند fuzzing شود.
FUZZ_SHORT_SEND
0.0
3.5
expected to send %1 bytes to Kea input socket but only sent %2
168u
168u
پیام هشداری که اگر فراخوانی sendto() (مورد استفاده برای ارسال داده از ریسهٔ fuzzing به پردازش اصلی Kea) به اندازهٔ داده‌های خوانده‌شده از AFL داده ارسال نکرده باشد، صادر می‌شود. این وضعیت ممکن است نشان‌دهندهٔ مشکلی در ارتباطات زیرین بین ریسهٔ fuzzing و پردازش اصلی Kea باشد..SS FUZZ_SOCKET_CREATE_FAIL
0.0
3.5
failed to crease socket for use by fuzzing thread: %1
168u
168u
پیام خطایی که هنگام ناتوانی کد fuzzing در ایجاد یک سوکت صادر می‌شود؛ سوکتی که از طریق آن، داده‌های دریافتی روی stdin از فازر AFL به درگاهی که Kea روی آن گوش می‌دهد، کپی می‌شود. در صورت وقوع این خطا، برنامه به احتمال زیاد متوقف (hang) خواهد شد.
GSS
GSS_TSIG_COMMAND_PROCESSED_FAILED
0.0
3.5
command_processed callout failed: %1.
168u
168u
این پیام خطا زمانی صادر می‌شود که callout مربوط به نقطه فراخوانی command_processed شکست خورده باشد. آرگومان حاوی دلیل بروز خطا است.
GSS_TSIG_IGNORED_BAD_DIRECTION
0.0
3.5
ignored bad direction verify failure.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که اعتبارسنجی به دلیل جهت نادرست پیام با شکست مواجه شده، اما از این شکست صرف‌نظر شده است.
GSS_TSIG_LOAD_FAILED
0.0
3.5
GSS-TSIG hooks library failed to load: %1.
168u
168u
این پیام خطا نشان می‌دهد که هنگام تلاش برای بارگذاری کتابخانه قلاب‌های (hooks library) مربوط به GSS-TSIG خطایی رخ داده است. آرگومان جزئیات خطا را شرح می‌دهد.
GSS_TSIG_LOAD_OK
0.0
3.5
GSS-TSIG hooks library loaded successfully.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های GSS-TSIG با موفقیت بارگذاری شده است.
GSS_TSIG_MANAGER_STARTED
0.0
3.5
hooks library GSS-TSIG key periodic manager started.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که مدیر دوره‌ای کلید GSS-TSIG آغاز به کار کرده باشد.
GSS_TSIG_MANAGER_STOPPED
0.0
3.5
hooks library GSS-TSIG key periodic manager stopped.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که مدیر دوره‌ای کلید GSS-TSIG متوقف شده باشد.
GSS_TSIG_MANAGER_STOP_ERROR
0.0
3.5
manager stop error: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که مدیر دوره‌ای کلید GSS-TSIG متوقف شده اما خطایی شناسایی شده است. پیام خطای موجود در آرگومان، جزئیات مربوط به مشکل را ارائه می‌دهد.
GSS_TSIG_MANAGER_STOP_GENERAL_ERROR
0.0
3.5
manager stop general error
168u
168u
این پیام خطا زمانی صادر می‌شود که مدیر دوره‌ای کلید GSS-TSIG متوقف شده اما یک خطای عمومی شناسایی شده است.
GSS_TSIG_NEW_KEY
0.0
3.5
new GSS-TSIG key '%1' was created.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های GSS-TSIG یک کلید GSS-TSIG جدید ایجاد کرده است. نام کلید جدید نمایش داده می‌شود..SS GSS_TSIG_NEW_KEY_SETUP_FAILED
0.0
3.5
new GSS-TSIG key '%1' setup failed: %2.
168u
168u
این پیام هشدار زمانی صادر می‌شود که برپاسازی کلید GSS-TSIG جدید ناموفق بوده است.
نام کلید جدید و خطا نمایش داده می‌شوند.
GSS_TSIG_NEW_KEY_SETUP_SUCCEED
0.0
3.5
new GSS-TSIG key '%1' setup succeeded.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که برپاسازی کلید جدید GSS-TSIG
با موفقیت به پایان برسد. نام کلید جدید نمایش داده می‌شود.
GSS_TSIG_OLD_KEY_REMOVED
0.0
3.5
%1 old GSS-TSIG keys were removed
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که برخی از کلیدهای قدیمی (قدیمی‌تر از ۲ برابر حداکثر
طول عمر TKEY) حذف شده باشند. تعداد کلیدهای حذف‌شده نمایش داده می‌شود.
GSS_TSIG_UNLOAD_OK
0.0
3.5
GSS-TSIG hooks library unloaded successfully.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های GSS-TSIG
با موفقیت از حافظه خارج شده است.
GSS_TSIG_VERIFIED
0.0
3.5
GSS-TSIG verify succeeded.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که اعتبارسنجی GSS-TSIG با موفقیت انجام شود.
GSS_TSIG_VERIFY_FAILED
0.0
3.5
GSS-TSIG verify failed: %1.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که اعتبارسنجی GSS-TSIG با شکست مواجه شده است.
آرگومان جزئیات خطا را شرح می‌دهد.
HA
HA_BUFFER4_RECEIVE_FAILED
0.0
3.5
buffer4_receive callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوانی کال‌اوت برای نقطه قلاب buffer4_receive
شکست خورده باشد. این امر ممکن است در پی یک خطای داخلی کارساز رخ دهد.
آرگومان حاوی دلیل بروز خطا است.
HA_BUFFER4_RECEIVE_NOT_FOR_US
0.0
3.5
%1: dropping query to be processed by another server
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv4 دریافتی
توسط این کارساز نادیده گرفته (drop) می‌شود؛ زیرا باید توسط کارساز دیگری پردازش شود.
این حالت زمانی رخ می‌دهد که کارساز دوردست در نتیجه توازن بار یا به دلیل ایفای نقش
به‌عنوان کارساز اصلی در پیکربندی آماده‌به‌کار فعال (hot standby)، برای پردازش بسته تعیین
شده باشد. این آرگومان اطلاعات شناسایی کلاینت را که از پرس‌وجو استخراج شده ارائه می‌دهد.
HA_BUFFER4_RECEIVE_PACKET_OPTIONS_SKIPPED
0.0
3.5
an error unpacking an option, caused subsequent options to be skipped: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که باز کردن بسته‌بندی (unpack) یک گزینه با خطا مواجه شده
و در نتیجه باز کردن بسته‌بندی گزینه‌های بعدی در پرس‌وجوی DHCPv4 غیرممکن گردد. کارساز
همچنان برای پاسخگویی به بسته تلاش خواهد کرد. تنها آرگومان موجود دلیل خطای
باز کردن بسته‌بندی را مشخص می‌کند..SS HA_BUFFER4_RECEIVE_UNPACK_FAILED
0.0
3.5
failed to parse query from %1 to %2, received over interface %3, reason: %4
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv4 دریافت‌شده معیوب (malformed) باشد و نتواند توسط کال‌اوت buffer4_receive تجزیه شود. پرس‌وجو توسط سرور نادیده گرفته شده و دور انداخته (drop) خواهد شد. سه آرگومان نخست، آدرس IP مبدأ، آدرس IP مقصد و رابط شبکه را مشخص می‌کنند. آرگومان آخر دلیل شکست را ارائه می‌دهد.
HA_BUFFER6_RECEIVE_FAILED
0.0
3.5
buffer6_receive callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کال‌اوت برای نقطه قلاب (hook point) مربوط به buffer6_receive با شکست مواجه شده باشد. این اتفاق ممکن است در نتیجه یک خطای داخلی سرور رخ دهد. آرگومان ارائه‌شده شامل دلیل خطا است.
HA_BUFFER6_RECEIVE_NOT_FOR_US
0.0
3.5
%1: dropping query to be processed by another server
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv6 دریافت‌شده توسط این سرور دور انداخته می‌شود (drop)، زیرا باید توسط سرور دیگری پاسخ داده شود. این حالت زمانی پیش می‌آید که سرور دوردست در نتیجه توازن بار (load balancing) یا به دلیل اینکه سرور اولیه در پیکربندی hot standby است، برای پردازش بسته تعیین شده باشد. این آرگومان اطلاعات شناسایی کلاینت را که از پرس‌وجو استخراج شده است، ارائه می‌دهد.
HA_BUFFER6_RECEIVE_PACKET_OPTIONS_SKIPPED
0.0
3.5
an error unpacking an option, caused subsequent options to be skipped: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازگشایی (unpack) یک گزینه (option) با شکست مواجه شده و در نتیجه بازگشایی گزینه‌های باقی‌مانده در پرس‌وجوی DHCPv6 غیرممکن می‌شود. سرور همچنان تلاش خواهد کرد به این بسته سرویس‌دهی کند. تنها آرگومان ارائه‌شده، دلیل خطای بازگشایی را مشخص می‌کند.
HA_BUFFER6_RECEIVE_UNPACK_FAILED
0.0
3.5
failed to parse query from %1 to %2, received over interface %3, reason: %4
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv6 دریافت‌شده معیوب (malformed) باشد و نتواند توسط کال‌اوت buffer6_receive تجزیه شود. این پرس‌وجو توسط سرور دور انداخته خواهد شد. سه آرگومان نخست، آدرس IP مبدأ، آدرس IP مقصد و رابط شبکه را مشخص می‌کنند. آرگومان آخر دلیل شکست را بیان می‌کند.
HA_COMMAND_PROCESSED_FAILED
0.0
3.5
command_processed callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کال‌اوت برای نقطه قلاب (hook point) مربوط به command_processed با شکست مواجه شود. آرگومان ارائه‌شده شامل دلیل خطا است.
HA_COMMUNICATION_INTERRUPTED
0.0
3.5
%1: communication with %2 is interrupted
168u
168u
این پیام هشدار توسط سروری صادر می‌شود که متوجه شده است ارتباط با شریک فعال (active partner) برای مدت‌زمانی طولانی‌تر از مقدار پیکربندی‌شده‌ی heartbeat-delay قطع شده است. در این مرحله، سرور با پایش ترافیک DHCP ارسال‌شده برای شریک و بررسی اینکه آیا سرور شریک به این ترافیک پاسخ می‌دهد یا خیر، روند failover را آغاز می‌کند. اگر مقدار max-unacked-clients برابر با 0 تنظیم شده باشد، این تأیید اعتبار غیرفعال است که در این حالت سرور مستقیماً به وضعیت partner-down منتقل خواهد شد.
HA_COMMUNICATION_INTERRUPTED_CLIENT4
0.0
3.5
%1: new client %2 attempting to get a lease from the partner
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که سرور بازمانده (surviving server) متوجه یک بسته DHCP شود که برای شریکی که ارتباط با آن قطع شده است ارسال گردیده است. کلاینتی که بسته‌اش مشاهده شده است، هنوز به عنوان "unacked" (پاسخ‌داده‌نشده) در نظر گرفته نمی‌شود، زیرا مقدار فیلد secs هنوز از آستانه پیکربندی‌شده مشخص‌شده در max-ack-delay فراتر نرفته است..SS HA_COMMUNICATION_INTERRUPTED_CLIENT4_UNACKED
0.0
3.5
%1: partner server failed to respond to %2, %3 clients unacked so far, %4 clients left before transitioning to the partner-down state
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کارگزار بازمانده تشخیص دهد
همتای آن در پاسخ به پرس‌وجوی DHCP ناموفق بوده است و این سرویس‌گیرنده
در نظر گرفته می‌شود که توسط همتا سرویس‌دهی نشده است. کارگزار بازمانده
چنین سرویس‌گیرندگانی را شمارش می‌کند و اگر تعداد این سرویس‌گیرندگان از آستانه
max-unacked-clients فراتر رود، کارگزار به وضعیت partner-down منتقل خواهد شد. آرگومان
اول نام رابطه را مشخص می‌کند. آرگومان دوم حاوی اطلاعات شناسایی سرویس‌گیرنده
است. آرگومان سوم تعداد سرویس‌گیرندگانی را مشخص می‌کند که کارگزار در پاسخ به آن‌ها
ناموفق بوده است. آرگومان چهارم تعداد سرویس‌گیرندگان مضاعفی را مشخص می‌کند
که اگر سرویس‌دهی نشوند، باعث انتقال کارگزار به وضعیت partner-down خواهند شد.
HA_COMMUNICATION_INTERRUPTED_CLIENT6
0.0
3.5
%1: new client %2 attempting to get a lease from the partner
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کارگزار بازمانده بسته DHCP
ارسال‌شده به همتایی را که ارتباط با آن قطع شده است مشاهده می‌کند.
سرویس‌گیرنده‌ای که بسته آن مشاهده شده است هنوز "unacked" (تأییدنپذیرفته) در نظر
گرفته نمی‌شود زیرا مقدار گزینه elapsed time از آستانه پیکربندی‌شده مشخص‌شده
با max-ack-delay فراتر نرفته است. تنها آرگومان، اطلاعات شناسایی سرویس‌گیرنده
را مشخص می‌کند.
HA_COMMUNICATION_INTERRUPTED_CLIENT6_UNACKED
0.0
3.5
%1: partner server failed to respond to %2, %3 clients unacked so far, %4 clients left before transitioning to the partner-down state
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کارگزار بازمانده تشخیص دهد
همتای آن در پاسخ به پرس‌وجوی DHCP ناموفق بوده است و این سرویس‌گیرنده
در نظر گرفته می‌شود که توسط همتا سرویس‌دهی نشده است. کارگزار بازمانده
چنین سرویس‌گیرندگانی را شمارش می‌کند و اگر تعداد این سرویس‌گیرندگان از آستانه
max-unacked-clients فراتر رود، کارگزار به وضعیت partner-down منتقل خواهد شد. آرگومان
اول نام رابطه را مشخص می‌کند. آرگومان دوم حاوی اطلاعات شناسایی سرویس‌گیرنده
است. آرگومان سوم تعداد سرویس‌گیرندگانی را مشخص می‌کند که کارگزار در پاسخ به آن‌ها
ناموفق بوده است. آرگومان چهارم تعداد سرویس‌گیرندگان مضاعفی را مشخص می‌کند
که در صورت عدم سرویس‌دهی، باعث انتقال کارگزار به وضعیت partner-down خواهند شد.
HA_CONFIGURATION_FAILED
0.0
3.5
failed to configure High Availability hooks library: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در پیکربندی کتابخانه قلاب‌های HA خطایی رخ دهد.
آرگومان، پیام خطای دقیق را ارائه می‌دهد.
HA_CONFIGURATION_SUCCESSFUL
0.0
3.5
HA hook library has been successfully configured
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که تجزیه‌کننده پیکربندی کتابخانه قلاب‌های HA
پیکربندی جدید را با موفقیت تجزیه و اعتبارسنجی کند.
HA_CONFIG_AUTO_FAILOVER_DISABLED
0.0
3.5
%1: auto-failover disabled
168u
168u
این پیام هشدار برای نشان دادن این موضوع صادر می‌شود که پارامتر 'auto-failover'
توسط مدیر سیستم برای کارگزار مشخص‌شده غیرفعال شده است. با تشخیص خرابی همتا،
کارگزار به‌طور خودکار شروع به سرویس‌دهی به دامنه (scope) همتا نخواهد کرد.
مدیر سیستم باید با ارسال دستور مناسب ha-scopes این دامنه را به‌صورت دستی فعال کند.
HA_CONFIG_DHCP_MT_DISABLED
0.0
3.5
%1: HA multi-threading has been disabled, it cannot be enabled when Kea global multi-threading is disabled
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که پیکربندی HA قابلیت چندریسمانی (multi-threading)
را فعال کرده باشد در حالی که در پیکربندی سراسری Kea چندریسمانی غیرفعال است.
HA_CONFIG_DHCP_MT_DISABLED_AND_KEA_MT_ENABLED
0.0
3.5
%1: HA multi-threading is disabled while Kea global multi-threading is enabled which most likely cause performance degradation.
168u
168u
این پیام هشدار زمانی صادر می‌شود که پیکربندی HA قابلیت چندریسمانی را غیرفعال
کرده باشد در حالی که در پیکربندی سراسری Kea چندریسمانی فعال است.
این وضعیت به احتمال زیاد باعث افت عملکرد خواهد شد..SS HA_CONFIG_LEASE_SYNCING_DISABLED
0.0
3.5
%1: lease database synchronization between HA servers is disabled
168u
168u
این پیام هشدار زمانی صادر می‌شود که همگام‌سازی پایگاه‌داده اجاره‌ها به‌صورت مدیریتی غیرفعال شده باشد. اگر اجاره‌ها از طریق سازوکار دیگری، برای مثال همانندسازی پایگاه‌داده SQL، بین پایگاه‌های داده اجاره همانندسازی شوند، این یک پیکربندی معتبر است.
HA_CONFIG_LEASE_SYNCING_DISABLED_REMINDER
0.0
3.5
%1: bypassing SYNCING state because lease database synchronization is administratively disabled
168u
168u
این پیام اطلاعاتی به عنوان یادآوری صادر می‌شود که همگام‌سازی پایگاه‌داده اجاره‌ها به‌صورت مدیریتی غیرفعال شده است و بنابراین کارگزار مستقیماً از وضعیت "waiting" به وضعیت "ready" تغییر حالت می‌دهد.
HA_CONFIG_LEASE_UPDATES_AND_SYNCING_DIFFER
0.0
3.5
%1: unusual configuration where "send-lease-updates": %2 and "sync-leases": %3
168u
168u
این پیام هشدار زمانی صادر می‌شود که مقادیر پیکربندی پارامترهای send-lease-updates و sync-leases متفاوت باشند. این ممکن است یک پیکربندی معتبر باشد، اما نامعمول است. در حالت عادی، اگر پایگاه‌داده اجاره به همراه همانندسازی استفاده شود، هر دو مقدار روی false تنظیم می‌شوند. اگر پایگاه‌داده اجاره بدون همانندسازی استفاده شود (مانند memfile)، هر دو مقدار روی true تنظیم می‌شوند. تعیین مقادیر متفاوت برای این پارامترها به این معنی است که مدیر سیستم یا می‌خواهد کارگزار هنگام راه‌اندازی، اجاره‌ها را همگام‌سازی نکند اما بعداً به‌روزرسانی‌های اجاره را به کارگزار شریک ارسال نماید، یا اینکه پایگاه‌داده اجاره باید هنگام راه‌اندازی همگام‌سازی شود، اما پس از آن هیچ به‌روزرسانی اجاره‌ای حاصل از تخصیص اجاره‌ها ارسال نشود.
HA_CONFIG_LEASE_UPDATES_DISABLED
0.0
3.5
%1: lease updates will not be generated
168u
168u
این پیام هشدار زمانی صادر می‌شود که به‌روزرسانی‌های اجاره به‌صورت مدیریتی غیرفعال شده باشند. اگر اجاره‌ها از طریق سازوکار دیگری، برای مثال همانندسازی پایگاه‌داده SQL، به پایگاه‌داده کارگزار شریک همانندسازی شوند، این یک پیکربندی معتبر است.
HA_CONFIG_LEASE_UPDATES_DISABLED_REMINDER
0.0
3.5
%1: lease updates are administratively disabled and will not be generated while in %2 state
168u
168u
این پیام اطلاعاتی به عنوان یادآوری صادر می‌شود که به‌روزرسانی‌های اجاره به‌صورت مدیریتی غیرفعال شده‌اند و در وضعیت HA که کارگزار به آن تغییر حالت داده است، ایجاد نخواهند شد. تنها آرگومان مشخص‌کننده وضعیتی است که کارگزار به آن منتقل شده است.
HA_CONFIG_SYSTEM_MT_UNSUPPORTED
0.0
3.5
%1: HA multi-threading has been disabled, auto-detection of thread support reports 0
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که پیکربندی چندریسمانی (multi-threading) HA روی تشخیص خودکار برای تعداد ریسمان‌ها تنظیم شده باشد و سیستم تعداد ریسمان‌های هم‌روند را 0 گزارش کند. اگر مطمئن هستید سیستم شما می‌تواند از چند ریسمان پشتیبانی کند، می‌توانید با تعیین مقادیر صریح برای http-listener-threads و http-client-threads این وضعیت را لغو و بازنویسی (override) کنید.
HA_CONTINUE_HANDLER_FAILED
0.0
3.5
ha-continue command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور ha-continue هنگام پردازش دستور با شکست مواجه شده است. آرگومان دلیل شکست را مشخص می‌کند.
HA_DEINIT_OK
0.0
3.5
unloading High Availability hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های (hooks library) دسترس‌پذیری بالا (High Availability) با موفقیت تخلیه شده است.
HA_DHCP4_START_SERVICE_FAILED
0.0
3.5
failed to start DHCPv4 HA services in dhcp4_srv_configured callout: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که تلاش برای شروع سرویس‌های High Availability برای کارگزار DHCPv4 در فراخوانی dhcp4_srv_configured ناموفق باشد. این یک خطای داخلی کارگزار است و باید یک گزارش باگ ایجاد شود..SS HA_DHCP6_START_SERVICE_FAILED
0.0
3.5
failed to start DHCPv6 HA services in dhcp6_srv_configured callout: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که تلاش برای راه‌اندازی سرویس‌های دسترسی‌پذیری بالا (HA) برای کارگزار DHCPv6 در فراخوانِ dhcp6_srv_configured با شکست مواجه شود. این یک خطای داخلی کارگزار است و باید یک گزارش باگ برای آن ثبت شود.
HA_DHCP_DISABLE_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send request to disable DHCP service of %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که هنگام ارسال دستور dhcp-disable، مشکلی در ارتباط با همتای HA رخ داده است. آرگومان نخست نام کارگزار محلی را مشخص می‌کند. آرگومان دوم نام کارگزار دوردست را ارائه می‌دهد. آرگومان سوم دلیل شکست را بیان می‌کند.
HA_DHCP_DISABLE_FAILED
0.0
3.5
%1: failed to disable DHCP service of %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به دستور dhcp-disable یک کد وضعیت خطا بازگردانده است. آرگومان نخست نام کارگزار محلی را مشخص می‌کند. آرگومان دوم نام کارگزار دوردست را ارائه می‌دهد. آرگومان سوم دلیل شکست را بیان می‌کند.
HA_DHCP_ENABLE_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send request to enable DHCP service of %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که هنگام ارسال دستور dhcp-enable، مشکلی در ارتباط با یک همتای HA رخ داده است. آرگومان نخست نام کارگزار محلی را مشخص می‌کند. آرگومان دوم نام کارگزار دوردست را ارائه می‌دهد. آرگومان سوم دلیل شکست را بیان می‌کند.
HA_DHCP_ENABLE_FAILED
0.0
3.5
%1: failed to enable DHCP service of %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به دستور dhcp-enable یک کد وضعیت خطا بازگردانده است. آرگومان نخست نام کارگزار محلی را مشخص می‌کند. آرگومان دوم نام کارگزار دوردست را ارائه می‌دهد. آرگومان سوم دلیل شکست را بیان می‌کند.
HA_HEARTBEAT_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send heartbeat to %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که هنگام ارسال ضربان قلب (heartbeat) مشکلی در ارتباط با یک همتای HA رخ داده است. این نخستین نشانه از احتمال از کار افتادن همتا است. کارگزار به تلاش برای ارسال ضربان قلب ادامه خواهد داد تا زمانی که ارتباط را قطع‌شده در نظر بگیرد.
HA_HEARTBEAT_FAILED
0.0
3.5
%1: heartbeat to %2 failed: %3
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به یک ضربان قلب (heartbeat) کد وضعیت خطا بازگردانده است. این نشانه‌ای از آن است که همتا ممکن است به درستی کار نکند. کارگزار به تلاش برای ارسال ضربان قلب ادامه خواهد داد تا زمانی که ارتباط را قطع‌شده در نظر بگیرد.
HA_HEARTBEAT_HANDLER_FAILED
0.0
3.5
heartbeat command failed: %1
168u
168u
این پیام خطا به این منظور صادر می‌شود که نشان دهد گردانندهٔ دستور heartbeat در حین پردازش دستور با شکست مواجه شده است. آرگومان ارائه شده دلیل شکست را مشخص می‌کند.
HA_HIGH_CLOCK_SKEW
0.0
3.5
%1: %2, please synchronize clocks!
168u
168u
این پیام هشدار زمانی صادر می‌شود که انحراف ساعت (clock skew) میان کارگزارهای فعال از ۳۰ ثانیه فراتر رود. سرویس HA به فعالیت خود ادامه می‌دهد اما ممکن است به درستی کار نکند، به‌ویژه برای طول‌عمرهای کوتاه اجاره (lease lifetimes). مدیر سیستم باید ساعت‌ها را همگام‌سازی کند، برای نمونه با استفاده از NTP. اگر انحراف ساعت از ۶۰ ثانیه فراتر رود، سرویس HA خاتمه خواهد یافت..SS HA_HIGH_CLOCK_SKEW_CAUSED_TERMINATION
0.0
3.5
%1: %2, causing HA service to terminate
168u
168u
این پیام هشدار زمانی صادر می‌شود که انحراف زمانی (clock skew) میان کارگزارهای فعال
از ۶۰ ثانیه فراتر رود. سرویس HA متوقف می‌شود. کارگزارها به پاسخ‌گویی به پرس‌وجوهای
DHCP ادامه خواهند داد، اما به‌روزرسانی‌های اجاره (lease) را تبادل نکرده و ضربان قلب
(heartbeat) ارسال نمی‌کنند. مدیر سیستم ملزم است ساعت‌ها را همگام‌سازی کرده و سپس
کارگزارها را مجدداً راه‌اندازی کند تا سرویس HA از سر گرفته شود.
HA_INIT_OK
0.0
3.5
loading High Availability hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های (hooks) دسترسی‌پذیری بالا
(High Availability) با موفقیت بارگذاری شده است. لذت ببرید!
HA_INVALID_PARTNER_STATE_COMMUNICATION_RECOVERY
0.0
3.5
%1: partner is in the communication-recovery state unexpectedly
168u
168u
این پیام هشدار زمانی صادر می‌شود که شریک (partner) در وضعیت communication-recovery
قرار دارد، اما این کارگزار در حالت load balancing اجرا نمی‌شود. کارگزار تنها زمانی
می‌تواند به وضعیت communication-recovery تغییر وضعیت دهد که در حالت load balancing
اجرا شود. حالت HA هر دو کارگزار باید یکسان باشد.
HA_INVALID_PARTNER_STATE_HOT_STANDBY
0.0
3.5
%1: partner is in the hot-standby state unexpectedly
168u
168u
این پیام هشدار زمانی صادر می‌شود که شریک (partner) در وضعیت hot-standby قرار دارد،
اما این کارگزار در حالت hot standby اجرا نمی‌شود. کارگزار تنها زمانی می‌تواند
به وضعیت hot-standby تغییر وضعیت دهد که در حالت hot standby اجرا شود.
حالت HA هر دو کارگزار باید یکسان باشد.
HA_INVALID_PARTNER_STATE_LOAD_BALANCING
0.0
3.5
%1: partner is in the load-balancing state unexpectedly
168u
168u
این پیام هشدار زمانی صادر می‌شود که شریک (partner) در وضعیت load-balancing قرار دارد،
اما این کارگزار در حالت load balancing اجرا نمی‌شود. کارگزار تنها زمانی می‌تواند
به وضعیت load-balancing تغییر وضعیت دهد که در حالت load balancing اجرا شود.
حالت HA هر دو کارگزار باید یکسان باشد.
HA_LEASE4_EXPIRE_FAILED
0.0
3.5
lease4_expire callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوان تابع (callout) برای نقطه قلاب
lease4_expire با شکست مواجه شود. این شامل خطاهای غیرمنتظره‌ای مانند ارسال آرگومان‌های
نادرست به تابع فراخوان توسط کارگزار DHCP است (خطای داخلی نامحتمل کارگزار).
آرگومان حاوی دلیل بروز خطا است.
HA_LEASE4_EXPIRE_INVALID_HA_SERVER_NAME
0.0
3.5
%1: invalid ha-server-name value for subnet %2
168u
168u
این پیام خطا زمانی صادر می‌شود که اجاره DHCPv4 بازپس‌گرفته‌شده متعلق به
زیرشبکه‌ای (subnet) باشد که مقدار ha-server-name را در user-context دارد، اما
این مقدار یک رشته متنی نیست یا خالی است. این یک پیکربندی نادرست در کارگزار است.
آرگومان اول حاوی اطلاعات اجاره است. آرگومان دوم پیشوند زیرشبکه (subnet prefix) است.
HA_LEASE4_EXPIRE_RECLAMATION_SKIP
0.0
3.5
%1: skipping reclamation of the lease that belongs to a partner
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار در وضعیت خاتمه‌یافته (terminated) قرار دارد
و از بازپس‌گیری اجاره‌ای که احتمالاً توسط کارگزار دیگری تخصیص داده شده، یا در زمان قرار داشتن
کارگزارها در وضعیت خاتمه‌یافته HA توسط کارگزار دیگر نگهداری می‌شود، صرف‌نظر می‌کند.
آرگومان، نشانی اجاره است.
HA_LEASE4_SERVER_DECLINE_FAILED
0.0
3.5
lease4_server_decline callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوان تابع (callout) برای نقطه قلاب
lease4_server_decline با شکست مواجه شود. این شامل خطاهای غیرمنتظره‌ای مانند ارسال آرگومان‌های
نادرست به تابع فراخوان توسط کارگزار DHCP است (خطای داخلی نامحتمل کارگزار).
آرگومان حاوی دلیل بروز خطا است..SS HA_LEASE6_EXPIRE_FAILED
0.0
3.5
lease4_expire callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوانی (callout) برای قلاب lease4_expire ناموفق باشد. این شامل خطاهای غیرمنتظره‌ای مانند ارسال آرگومان‌های نادرست توسط کارگزار DHCP به فراخوان (خطای داخلی نامحتمل کارگزار) است.
آرگومان شامل دلیل بروز خطا است.
HA_LEASE6_EXPIRE_INVALID_HA_SERVER_NAME
0.0
3.5
%1: invalid ha-server-name value for subnet %2
168u
168u
این پیام خطا زمانی صادر می‌شود که اجاره‌ی بازپس‌گرفته‌شده‌ی DHCPv6 به زیرشبکه‌ای تعلق داشته باشد که شامل مقدار ha-server-name در user-context است، اما این مقدار یک رشته نبوده یا خالی است. این مورد ناشی از پیکربندی نادرست کارگزار است.
آرگومان نخست حاوی اطلاعات اجاره است. آرگومان دوم پیشوند زیرشبکه است.
HA_LEASE6_EXPIRE_RECLAMATION_SKIP
0.0
3.5
%1: skipping reclamation of the lease that belongs to a partner
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار در وضعیت terminated (پایان‌یافته) قرار دارد و از بازپس‌گیری اجاره‌ای که احتمالاً توسط کارگزار دیگری تخصیص داده شده یا در زمان قرار داشتن کارگزارها در وضعیت HA terminated توسط کارگزار دیگر نگهداری می‌شود، صرف‌نظر می‌کند. آرگومان، نشانی اجاره است.
HA_LEASES4_COMMITTED_FAILED
0.0
3.5
leases4_committed callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوانی (callout) برای قلاب leases4_committed ناموفق باشد. این شامل خطاهای غیرمنتظره‌ای مانند ارسال آرگومان‌های نادرست توسط کارگزار DHCP به فراخوان (خطای داخلی نامحتمل کارگزار) است.
آرگومان شامل دلیل بروز خطا است.
HA_LEASES4_COMMITTED_NOTHING_TO_UPDATE
0.0
3.5
%1: leases4_committed callout was invoked without any leases
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که فراخوانی "leases4_committed" بازمی‌گردد زیرا نه اجاره‌ی جدیدی وجود دارد و نه اجاره‌ی حذف‌شده‌ای که لازم باشد به‌روزرسانی‌هایی برای آن‌ها ارسال شود. تنها آرگومان، جزئیات کلاینت ارسال‌کننده‌ی بسته را مشخص می‌کند.
HA_LEASES4_COMMITTED_NO_RELATIONSHIP
0.0
3.5
%1: HA relationship not found: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که رابطه‌ی مربوط به نام کارگزار ارائه‌شده توسط فراخوان‌های قبلی، در پیکربندی HA یافت نشود. این خطا بسیار نامحتمل است و بیشتر نشان‌دهنده‌ی یک خطای برنامه‌نویسی است. آرگومان نخست، اطلاعات شناسایی کلاینت است. آرگومان دوم حاوی پیام خطای دقیق‌تری است.
HA_LEASES6_COMMITTED_FAILED
0.0
3.5
leases6_committed callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوانی (callout) برای قلاب leases6_committed ناموفق باشد. این شامل خطاهای غیرمنتظره‌ای مانند ارسال آرگومان‌های نادرست توسط کارگزار DHCP به فراخوان (خطای داخلی نامحتمل کارگزار) است.
آرگومان شامل دلیل بروز خطا است.
HA_LEASES6_COMMITTED_NOTHING_TO_UPDATE
0.0
3.5
%1: leases6_committed callout was invoked without any leases
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که فراخوانی "leases6_committed" بازمی‌گردد زیرا نه اجاره‌ی جدیدی وجود دارد و نه اجاره‌ی حذف‌شده‌ای که لازم باشد به‌روزرسانی‌هایی برای آن‌ها ارسال شود. تنها آرگومان، جزئیات کلاینت ارسال‌کننده‌ی بسته را مشخص می‌کند.
HA_LEASES6_COMMITTED_NO_RELATIONSHIP
0.0
3.5
%1: HA relationship not found: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که رابطه‌ی مربوط به نام کارگزار ارائه‌شده توسط فراخوان‌های قبلی، در پیکربندی HA یافت نشود. این خطا بسیار نامحتمل است و بیشتر نشان‌دهنده‌ی یک خطای برنامه‌نویسی است. آرگومان نخست، اطلاعات شناسایی کلاینت است. آرگومان دوم حاوی پیام خطای دقیق‌تری است..SS HA_LEASES_BACKLOG_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to communicate with %2 while sending lease updates backlog: %3
168u
168u
این پیام خطا نشان‌دهنده آن است که هنگام ارسال به‌روزرسانی‌های معوق اجاره‌ها پس از برقراری مجدد ارتباط با سرور همتا، خطای ارتباطی رخ داده است. آرگومان سوم شامل دلیل خطا است.
HA_LEASES_BACKLOG_FAILED
0.0
3.5
%1: failed to send lease updates backlog to %2: %3
168u
168u
این پیام خطا نشان‌دهنده آن است که ارسال انباشت به‌روزرسانی‌های اجاره به سرور همتا با شکست مواجه شد. انباشت به‌روزرسانی‌های اجاره پس از برقراری مجدد ارتباطِ موقتاً قطع‌شده با همتا برای آن ارسال می‌شود. در صورت شکست این عملیات، سرور به وضعیت waiting تغییر حالت می‌دهد تا همگام‌سازی کامل پایگاه‌داده اجاره‌ها را آغاز کند.
HA_LEASES_BACKLOG_NOTHING_TO_SEND
0.0
3.5
%1: no leases in backlog after communication recovery
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که پس از بازیابی ارتباط با همتا، هیچ اجاره معوقی برای ارسال وجود نداشته باشد. این بدان معناست که قطعی ارتباط آن‌قدر کوتاه بوده که هیچ کلاینت DHCP در زمانی که سرور در وضعیت communication-recovery قرار داشته، اجاره‌ای دریافت نکرده است. اکنون سرور می‌تواند به وضعیت load-balancing تغییر حالت دهد.
HA_LEASES_BACKLOG_START
0.0
3.5
%1: starting to send %2 outstanding lease updates to %3
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که سرور پس از برقراری مجدد ارتباط، شروع به ارسال به‌روزرسانی‌های معوق اجاره‌ها به همتا می‌کند. آرگومان نخست نام سرور محلی را مشخص می‌کند. آرگومان دوم تعداد به‌روزرسانی‌های اجاره برای ارسال را تعیین می‌کند. نام همتا در آرگومان سوم مشخص می‌شود.
HA_LEASES_BACKLOG_SUCCESS
0.0
3.5
%1: sending lease updates backlog to %2 successful in %3
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که سرور با موفقیت ارسال انباشت به‌روزرسانی‌های اجاره به همتا را به پایان می‌رساند. آرگومان نخست نام سرور محلی را مشخص می‌کند. آرگومان دوم نام سرور دوردست را تعیین می‌کند. آرگومان سوم مدت‌زمان این عملیات را مشخص می‌سازد.
HA_LEASES_SYNC_APPLIED_LEASES
0.0
3.5
%1: applied %2 leases received from the partner in the local lease database
168u
168u
این پیام اطلاعاتی، تعداد اجاره‌های دریافت‌شده از سرور همتا طی همگام‌سازی پایگاه‌داده را که در پایگاه‌داده محلی اعمال شده‌اند، نمایش می‌دهد. یک حالت معمول برای شرایطی که تنها برخی از اجاره‌ها اعمال می‌شوند، زمانی است که سرور چندین رابطه (relationship) دارد و بخشی از اجاره‌های دریافت‌شده متعلق به رابطه دیگری هستند. آرگومان نخست نام این سرور را مشخص می‌کند. آرگومان دوم تعداد اجاره‌های اعمال‌شده را تعیین می‌کند.
HA_LEASES_SYNC_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to communicate with %2 while syncing leases: %3
168u
168u
این پیام خطا نشان‌دهنده آن است که هنگام تلاش برای واکشی اجاره‌ها از پایگاه‌داده سرور همتا، خطای ارتباطی با آن سرور رخ داده است. این آرگومان حاوی دلیل بروز خطا است.
HA_LEASES_SYNC_FAILED
0.0
3.5
%1: failed to synchronize leases with %2: %3
168u
168u
این پیام خطا نشان‌دهنده آن است که هنگام تجزیه پاسخ دریافتی از سروری که اجاره‌ها برای همگام‌سازی پایگاه‌داده محلی از آن واکشی شده‌اند، مشکلی رخ داده است. آرگومان سوم شامل دلیل خطا است.
HA_LEASES_SYNC_LEASE_PAGE_RECEIVED
0.0
3.5
%1: received %2 leases from %3
168u
168u
این پیام اطلاعاتی در حین همگام‌سازی پایگاه‌داده اجاره‌ها صادر می‌شود تا نشان دهد دسته‌ای از اجاره‌ها دریافت شده است. آرگومان نخست نام سرور محلی را مشخص می‌کند. آرگومان دوم حاوی تعداد اجاره‌های دریافت‌شده است. آرگومان سوم نام سرور همتا را مشخص می‌کند..SS HA_LEASE_SYNC_FAILED
0.0
3.5
%1: synchronization failed for lease: %2, reason: %3
168u
168u
این پیام هشدار زمانی صادر می‌شود که ایجاد یا به‌روزرسانی یک اجاره (lease) در
پایگاه‌داده محلی اجاره‌ها با شکست مواجه شود. اطلاعات اجاره در قالب JSON
به‌عنوان آرگومان اول ارائه می‌شود. آرگومان سوم دلیل این شکست را مشخص می‌کند.
HA_LEASE_SYNC_STALE_LEASE4_SKIP
0.0
3.5
%1: skipping stale lease %2 in subnet %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی در طول همگام‌سازی پایگاه‌داده اجاره صادر می‌شود، زمانی که
نمونه اجاره IPv4 واکشی‌شده قدیمی‌تر از نمونه موجود در پایگاه‌داده محلی به نظر
برسد. نمونه جدیدتر در پایگاه‌داده باقی می‌ماند و اجاره واکشی‌شده دور انداخته
می‌شود. سرور راه دور همچنان نمونه اجاره قدیمی‌تر را حفظ خواهد کرد تا زمانی که
پایگاه‌داده خود را با این سرور همگام‌سازی کند. آرگومان اول نام سرور محلی را مشخص
می‌کند. آرگومان دوم آدرس اجاره‌داده‌شده را مشخص می‌کند. آرگومان سوم زیرشبکه‌ای
(subnet) را مشخص می‌کند که اجاره به آن تعلق دارد.
HA_LEASE_SYNC_STALE_LEASE6_SKIP
0.0
3.5
%1: skipping stale lease %2 in subnet %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی در طول همگام‌سازی پایگاه‌داده اجاره صادر می‌شود، زمانی که
نمونه اجاره IPv6 واکشی‌شده قدیمی‌تر از نمونه موجود در پایگاه‌داده محلی به نظر
برسد. نمونه جدیدتر در پایگاه‌داده باقی می‌ماند و اجاره واکشی‌شده دور انداخته
می‌شود. سرور راه دور همچنان نمونه اجاره قدیمی‌تر را حفظ خواهد کرد تا زمانی که
پایگاه‌داده خود را با این سرور همگام‌سازی کند. آرگومان اول نام سرور محلی را مشخص
می‌کند. آرگومان دوم آدرس اجاره‌داده‌شده را مشخص می‌کند. آرگومان دوم [سوم] زیرشبکه‌ای
را مشخص می‌کند که اجاره به آن تعلق دارد.
HA_LEASE_UPDATES_DISABLED
0.0
3.5
%1: lease updates will not be sent to the partner while in %2 state
168u
168u
این پیام اطلاع‌رسانی برای اعلام این موضوع صادر می‌شود که به‌روزرسانی‌های اجاره
در زمانی که سرور در وضعیت فعلی قرار دارد به شریک (partner) ارسال نخواهد شد.
آرگومان دوم نام وضعیت فعلی سرور را مشخص می‌کند. در صورت پیکربندی سرورهای پشتیبان،
به‌روزرسانی‌های اجاره همچنان برای آن‌ها ارسال می‌شود اما از هرگونه خطای احتمالی
در ارتباط با سرورهای پشتیبان صرف‌نظر می‌گردد.
HA_LEASE_UPDATES_ENABLED
0.0
3.5
%1: lease updates will be sent to the partner while in %2 state
168u
168u
این پیام اطلاع‌رسانی برای اعلام این موضوع صادر می‌شود که به‌روزرسانی‌های اجاره
در زمانی که سرور در وضعیت فعلی قرار دارد به شریک (partner) ارسال خواهد شد.
مورد دوم نام وضعیت فعلی سرور را مشخص می‌کند.
HA_LEASE_UPDATE_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send lease update %2 to %3: %4
168u
168u
این پیام هشدار نشان می‌دهد که در هنگام پردازش درخواست کلاینت DHCP و ارسال
به‌روزرسانی اجاره، مشکلی در برقراری ارتباط با همتای (peer) مربوط به HA رخ داده
است. پیام DHCP کلاینت دور انداخته خواهد شد.
HA_LEASE_UPDATE_CONFLICT
0.0
3.5
%1: lease update %2 sent to %3 returned conflict status code: %4
168u
168u
این پیام هشدار نشان می‌دهد که شریک در پاسخ به یک به‌روزرسانی اجاره، کد وضعیت
تعارض بازگردانده است. پیام DHCP کلاینت دور انداخته خواهد شد. اگر سرور برای
ردیابی به‌روزرسانی‌های دارای تعارضِ اجاره پیکربندی شده باشد، در صورت فراتر رفتن
از آستانه تعیین‌شده، ممکن است در نهایت به وضعیت خاتمه‌یافته (terminated) منتقل شود.
HA_LEASE_UPDATE_CREATE_UPDATE_FAILED_ON_PEER
0.0
3.5
%1: failed to create or update the lease having type %2 for address %3, reason: %4
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که ایجاد یا به‌روزرسانی یکی از اجاره‌ها روی
همتای HA در حین پردازش به‌روزرسانی‌های اجارهٔ ارسال‌شده از این سرور با شکست مواجه
شود. این امر ممکن است نشان‌دهنده مشکلی در ارتباط بین همتا و پایگاه‌داده اجاره آن باشد..SS HA_LEASE_UPDATE_DELETE_FAILED_ON_PEER
0.0
3.5
%1: failed to delete the lease having type %2 for address %3, reason: %4
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که هنگام پردازش به‌روزرسانی‌های اجارهٔ ارسال‌شده از این سرور، حذف یکی از اجاره‌ها روی همتای HA با شکست مواجه شود. معمولاً حذف اجاره زمانی با شکست مواجه می‌شود که در پایگاه دادهٔ همتا وجود نداشته باشد.
HA_LEASE_UPDATE_FAILED
0.0
3.5
%1: lease update %2 sent to %3 failed: %4
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به به‌روزرسانی اجاره، کد وضعیت خطا بازگردانده است. پیام DHCP کلاینت نادیده گرفته خواهد شد.
HA_LEASE_UPDATE_REJECTS_CAUSED_TERMINATION
0.0
3.5
%1: too many rejected lease updates cause the HA service to terminate
168u
168u
این پیام خطا زمانی صادر می‌شود که سرویس HA خاتمه یابد، زیرا تعداد به‌روزرسانی‌های اجاره‌ای که کد وضعیت تداخل (conflict) برای آن‌ها از سوی شریک بازگردانده شده است، از حد تعیین‌شده با پارامتر پیکربندی max-rejected-lease-updates فراتر رفته است.
HA_LOAD_BALANCING_DUID_MISSING
0.0
3.5
%1: load balancing failed for the DHCPv6 message (transaction id: %2) because DUID is missing
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کتابخانه هوک (hook library) HA نتواند بار یک پرس‌وجوی ورودی DHCPv6 را متعادل‌سازی کند، زیرا نه شناسه کلاینت و نه نشانی سخت‌افزاری (HW address) در پرس‌وجو گنجانده نشده است. پرس‌وجو نادیده گرفته خواهد شد. تنها آرگومان شامل شناسه تراکنش (transaction id) است.
HA_LOAD_BALANCING_IDENTIFIER_MISSING
0.0
3.5
%1: load balancing failed for the DHCPv4 message (transaction id: %2) because HW address and client identifier are missing
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کتابخانه هوک HA نتواند بار یک پرس‌وجوی ورودی DHCPv4 را متعادل‌سازی کند، زیرا نه شناسه کلاینت و نه نشانی سخت‌افزاری در پرس‌وجو گنجانده نشده است. پرس‌وجو نادیده گرفته خواهد شد. تنها آرگومان شامل شناسه تراکنش است.
HA_LOAD_BALANCING_LEASE_DUID_MISSING
0.0
3.5
%1: load balancing failed for the DHCPv6 lease %2 because DUID is missing
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کتابخانه هوک HA نتواند بار یک اجارهٔ بازپس‌گرفته‌شدهٔ DHCPv6 را متعادل‌سازی کند، زیرا شناسه کلاینت در اجاره یافت نشده است.
HA_LOAD_BALANCING_LEASE_IDENTIFIER_MISSING
0.0
3.5
%1: load balancing failed for the DHCPv4 lease %2 because HW address and client identifier are missing
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کتابخانه هوک HA نتواند بار یک اجارهٔ بازپس‌گرفته‌شدهٔ DHCPv4 را متعادل‌سازی کند، زیرا نه شناسه کلاینت و نه نشانی سخت‌افزاری در پرس‌وجو گنجانده نشده است.
HA_LOCAL_DHCP_DISABLE
0.0
3.5
local DHCP service is disabled while the %1 is in the %2 state
168u
168u
این پیام اطلاع‌رسانی صادر می‌شود تا نشان دهد سرویس محلی DHCP غیرفعال است، زیرا سرور در وضعیتی قرار دارد که نباید به کلاینت‌های DHCP پاسخ دهد؛ برای نمونه، سرور هنوز پایگاه دادهٔ اجاره‌های خود را همگام‌سازی نکرده است. آرگومان نخست نام سرور و آرگومان دوم وضعیت سرور را مشخص می‌کند.
HA_LOCAL_DHCP_ENABLE
0.0
3.5
local DHCP service is enabled while the %1 is in the %2 state
168u
168u
این پیام اطلاع‌رسانی صادر می‌شود تا نشان دهد سرویس محلی DHCP فعال است، زیرا سرور در وضعیتی قرار دارد که باید به کلاینت‌های DHCP پاسخ دهد. آرگومان نخست نام سرور و آرگومان دوم وضعیت سرور را مشخص می‌کند..SS HA_MAINTENANCE_CANCEL_HANDLER_FAILED
0.0
3.5
ha-maintenance-cancel command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده (handler) دستور ha-maintenance-cancel هنگام پردازش دستور با شکست مواجه شده است. این آرگومان، دلیل شکست را ارائه می‌دهد.
HA_MAINTENANCE_NOTIFY_CANCEL_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send ha-maintenance-notify to %2 in attempt to cancel its maintenance: %3
168u
168u
این پیام هشدار نشان می‌دهد که هنگام ارسال دستور ha-maintenance-notify با پرچم cancel تنظیم‌شده روی true، مشکلی در برقراری ارتباط با همتای HA وجود داشته است. آرگومان نخست، نام کارگزار محلی را مشخص می‌کند. آرگومان دوم، نام کارگزار دوردست را مشخص می‌سازد. آرگومان سوم، دلیلی برای شکست رخ‌داده ارائه می‌دهد.
HA_MAINTENANCE_NOTIFY_CANCEL_FAILED
0.0
3.5
%1: error returned while processing ha-maintenance-notify by %2 in attempt to cancel its maintenance: %3
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به دستور ha-maintenance-notify با پرچم cancel تنظیم‌شده روی true، کد وضعیت خطا برگردانده است. آرگومان نخست، نام کارگزار محلی را مشخص می‌کند. آرگومان دوم، نام کارگزار دوردست را ارائه می‌دهد. آرگومان سوم، دلیلی برای این شکست ارائه می‌کند.
HA_MAINTENANCE_NOTIFY_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send ha-maintenance-notify to %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که هنگام ارسال دستور ha-maintenance-notify، مشکلی در برقراری ارتباط با یک همتای HA رخ داده است. آرگومان نخست، نام کارگزار محلی را ارائه می‌دهد. آرگومان دوم، نام کارگزار دوردست را مشخص می‌کند. آرگومان سوم، دلیل شکست را ارائه می‌دهد.
HA_MAINTENANCE_NOTIFY_FAILED
0.0
3.5
%1: error returned while processing ha-maintenance-notify by %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به دستور ha-maintenance-notify، یک کد وضعیت خطا برگردانده است. آرگومان نخست، نام کارگزار دوردست را ارائه می‌دهد. آرگومان دوم، دلیلی برای این شکست ارائه می‌کند.
HA_MAINTENANCE_NOTIFY_HANDLER_FAILED
0.0
3.5
ha-maintenance-notify command failed: %1
168u
168u
این پیام خطا نشان‌دهنده آن است که گرداننده دستور ha-maintenance-notify هنگام پردازش دستور با شکست مواجه شده است. این آرگومان، دلیل شکست را ارائه می‌دهد.
HA_MAINTENANCE_SHUTDOWN_SAFE
0.0
3.5
%1: the server can now be shutdown for maintenance as the partner has taken over the DHCP traffic
168u
168u
این پیام اطلاعاتی پس از انتقال کارگزار به وضعیت in-maintenance نمایش داده می‌شود. این کارگزار دیگر به هیچ‌یک از پرس‌وجوهای DHCP پاسخ نمی‌دهد و شریک آن - در وضعیت partner-in-maintenance - ترافیک DHCP را بر عهده گرفته است. هنگامی که کارگزارِ در وضعیت in-maintenance خاموش شود، شریک بلافاصله به وضعیت partner-down منتقل می‌شود.
HA_MAINTENANCE_STARTED
0.0
3.5
%1: the server is now in the partner-in-maintenance state and the partner is in-maintenance state
168u
168u
این پیام اطلاعاتی زمانی نمایش داده می‌شود که کارگزار دریافت‌کننده دستور ha-maintenance-start به وضعیت partner-in-maintenance منتقل شود. کارگزار این کار را پس از ارسال ha-maintenance-notify به شریک خود برای قرار دادن آن در وضعیت in-maintenance انجام می‌دهد. از این لحظه به بعد، کارگزار موجود در وضعیت partner-in-maintenance به تمام پرس‌وجوها پاسخ خواهد داد و شریک به هیچ پرس‌وجویی پاسخ نمی‌دهد. شریک می‌تواند با اطمینان برای عملیات نگهداری خاموش شود که در این صورت، این کارگزار به‌طور خودکار از وضعیت partner-in-maintenance به وضعیت partner-down منتقل خواهد شد.
HA_MAINTENANCE_STARTED_IN_PARTNER_DOWN
0.0
3.5
%1: the server is now in the partner-down mode as a result of requested maintenance
168u
168u
این پیام اطلاعاتی هنگامی نمایش داده می‌شود که کارگزار دریافت‌کننده دستور ha-maintenance-start، به دلیل ناتوانی در برقراری ارتباط با شریک در زمان دریافت دستور، به وضعیت partner-down منتقل شود. فرض بر این است که در چنین شرایطی شریک از پیش برای نگهداری آفلاین شده است. توجه داشته باشید که در این حالت، روال عادی جایگزینی در خرابی (failover) انجام نمی‌شود. کارگزار منتظر چندین بار عدم پاسخ بررسی زنده بودن (heartbeat) نمی‌ماند و ترافیک DHCP را برای پرس‌وجوهای بدون پاسخ پایش نمی‌کند. در حالت نگهداری، کارگزار به محض رویارویی با نخستین مشکل ارتباطی با شریک، به وضعیت partner-down منتقل می‌شود..SS HA_MAINTENANCE_START_HANDLER_FAILED
0.0
3.5
ha-maintenance-start command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور ha-maintenance-start هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
HA_MISSING_CONFIGURATION
0.0
3.5
high-availability parameter not specified for High Availability hooks library
168u
168u
این پیام خطا نشان می‌دهد که پیکربندی کتابخانه قلاب‌های High Availability مشخص نشده است. پارامتر 'high-availability' باید مشخص شود تا کتابخانه قلاب‌ها به درستی بارگذاری گردد.
HA_PAUSE_CLIENT_LISTENER_FAILED
0.0
3.5
%1: pausing multi-threaded HTTP processing failed: %2
168u
168u
این پیام خطا هنگام تلاش برای متوقف کردن موقت ریسمان‌های کلاینت و شنونده‌ی HTTP مربوط به HA صادر می‌شود. رخ دادن این خطا بسیار بعید است و نشان‌دهنده یک مشکل برنامه‌نویسی است که باید به عنوان نقص گزارش شود. نام سرور و علت خطا چاپ می‌شوند.
HA_PAUSE_CLIENT_LISTENER_ILLEGAL
0.0
3.5
%1: pausing multi-threaded HTTP processing failed: %2
168u
168u
این پیام خطا هنگام تلاش برای متوقف کردن موقت استخرهای ریسمان کلاینت یا شنونده‌ی HTTP مربوط به HA از طریق یک ریسمان کارگر صادر می‌شود. این خطا نشان می‌دهد دستوری که روی ریسمان‌های شنونده اجرا می‌شود، در حال تلاش برای استفاده از یک بخش بحرانی است که منجر به بن‌بست (dead-lock) خواهد شد.
HA_RESET_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send ha-reset command to %2: %3
168u
168u
این پیام هشدار نشان‌دهنده مشکلی در برقراری ارتباط با یک همتای HA هنگام ارسال دستور ha-reset است. آرگومان نخست، نام سرور محلی را مشخص می‌کند. آرگومان دوم، نام سرور راه دور را مشخص می‌کند. آرگومان سوم، دلیل شکست را مشخص می‌کند.
HA_RESET_FAILED
0.0
3.5
%1: failed to reset HA state machine of %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به دستور ha-reset یک کد وضعیت خطا بازگردانده است. آرگومان نخست، نام سرور محلی را مشخص می‌کند. آرگومان دوم، نام سرور راه دور را مشخص می‌کند. آرگومان سوم، دلیل شکست را مشخص می‌کند.
HA_RESET_HANDLER_FAILED
0.0
3.5
ha-reset command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور ha-reset هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند.
HA_RESUME_CLIENT_LISTENER_FAILED
0.0
3.5
%1: resuming multi-threaded HTTP processing failed: %2
168u
168u
این پیام خطا هنگام تلاش برای ازسرگیری ریسمان‌های کلاینت و شنونده‌ی HTTP مربوط به HA صادر می‌شود. رخ دادن این خطا بسیار بعید است و نشان‌دهنده یک مشکل برنامه‌نویسی است که باید به عنوان نقص گزارش شود.
HA_SCOPES_HANDLER_FAILED
0.0
3.5
ha-scopes command failed: %1
168u
168u
این پیام خطا نشان می‌دهد که گرداننده دستور ha-scopes هنگام پردازش دستور با شکست مواجه شده است. آرگومان، دلیل شکست را مشخص می‌کند..SS HA_SERVICE_STARTED
0.0
3.5
%1: started high availability service in %2 mode as %3 server
168u
168u
این پیام اطلاعاتی هنگامی صادر می‌شود که سرویس HA در نتیجهٔ راه‌اندازی کارساز یا پیکربندی مجدد آغاز به کار کند. آرگومان نخست، نام کارساز محلی را مشخص می‌کند. آرگومان دوم، حالت HA را ارائه می‌دهد. آرگومان سوم، نقش این نمونه از کارساز را در این پیکربندی مشخص می‌کند.
HA_STATE_MACHINE_CONTINUED
0.0
3.5
%1: state machine is un-paused
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که ماشین حالت HA از مکث خارج شود. این کار کارساز را از وضعیت فعلی آزاد می‌کند. در صورت نیاز، کارساز می‌تواند به هر حالت دیگری گذار کند؛ برای نمونه، اگر به نظر برسد شریک آن آفلاین است به 'partner-down' برود. همچنین در صورتی که وضعیت راه‌اندازی HA چنین رفتاری را ایجاب کند، کارساز ممکن است در وضعیت فعلی باقی بماند.
HA_STATE_MACHINE_PAUSED
0.0
3.5
%1: state machine paused in state %2
168u
168u
این پیام اطلاعاتی هنگامی صادر می‌شود که ماشین حالت HA متوقف (مکث) شود. ماشین حالت HA ممکن است در وضعیت‌های مشخصی که در پیکربندی کتابخانه قلاب‌های HA تعیین شده است به حالت مکث درآید. هنگامی که ماشین حالت متوقف است، کارساز در وضعیت تعیین‌شده باقی می‌ماند تا زمانی که به‌طور صریح از مکث خارج شود (از طریق دستور ha-continue). در صورت متوقف بودن ماشین حالت، کارساز به‌طور عادی کار می‌کند اما نمی‌تواند به هیچ حالت دیگری گذار کند.
HA_STATE_TRANSITION
0.0
3.5
%1: server transitions from %2 to %3 state, partner state is %4
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کارساز در نتیجهٔ تعاملی (یا عدم تعامل) با شریک خود به یک وضعیت جدید گذار کند. آرگومان‌ها به‌ترتیب نام کارساز محلی، وضعیت اولیه کارساز، وضعیت جدید کارساز و وضعیت شریک را مشخص می‌کنند.
HA_STATE_TRANSITION_PASSIVE_BACKUP
0.0
3.5
%1: server transitions from %2 to %3 state
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کارساز در حالت passive-backup به یک وضعیت جدید گذار کند. آرگومان‌ها نام کارساز محلی، وضعیت اولیه کارساز و وضعیت جدید کارساز را مشخص می‌کنند.
HA_SUBNET4_SELECT_FAILED
0.0
3.5
subnet4_select callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوانی (callout) برای نقطه قلاب subnet4_select با شکست مواجه شود. این امر ممکن است در نتیجه یک خطای داخلی کارساز رخ دهد. آرگومان ارائه‌شده حاوی دلیل بروز خطا است.
HA_SUBNET4_SELECT_INVALID_HA_SERVER_NAME
0.0
3.5
%1: invalid ha-server-name value for subnet %2
168u
168u
این پیام خطا زمانی صادر می‌شود که پرس‌وجوی DHCPv4 دریافت شده توسط این کارساز نادیده گرفته (drop) شود، زیرا مقدار ha-server-name مشخص‌شده در user-context زیرشبکه از نوع غیررشته‌ای بوده یا خالی است. این موضوع ناشی از پیکربندی نادرست کارساز است. آرگومان نخست اطلاعات شناسایی کلاینت است. آرگومان دوم پیشوند زیرشبکه است.
HA_SUBNET4_SELECT_NOT_FOR_US
0.0
3.5
%1: dropping query in relationship %2 to be processed by another server
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv4 دریافت شده توسط این کارساز نادیده گرفته شود زیرا باید توسط کارساز دیگری رسیدگی شود. این حالت زمانی رخ می‌دهد که کارساز اصلی راه دور فعال و در حال کار باشد. آرگومان نخست اطلاعات شناسایی کلاینت و آرگومان دوم نام رابطه (relationship) است.
HA_SUBNET4_SELECT_NO_RELATIONSHIP_FOR_SUBNET
0.0
3.5
%1: HA relationship not found for %2
168u
168u
این پیام خطا هنگامی صادر می‌شود که پرس‌وجوی DHCPv4 دریافت شده توسط این کارساز نادیده گرفته شود، زیرا کارساز نتوانسته رابطه‌ای منطبق با ha-server-name مشخص‌شده برای یک زیرشبکه پیدا کند. نام کارساز با هیچ رابطه‌ای که در پیکربندی HA مشخص شده مطابقت ندارد. دلیل معمول آن وجود یک اشتباه تایپی است. آرگومان نخست اطلاعات شناسایی کلاینت است. آرگومان دوم نام رابطه است..SS HA_SUBNET4_SELECT_NO_RELATIONSHIP_SELECTOR_FOR_SUBNET
0.0
3.5
%1: unable to determine HA relationship because selected subnet %2 lacks the ha-server-name
168u
168u
این پیام خطا زمانی صادر می‌شود که پرس‌وجوی DHCPv4 دریافت‌شده توسط این کارساز نادیده گرفته می‌شود؛ زیرا کارساز قادر به تعیین رابطه HA که پرس‌وجوی دریافت‌شده به آن تعلق دارد نبوده است. در صورت وجود چندین رابطه، لازم است مقدار ha-server-name در user-context در سطح زیرشبکه یا شبکه مشترک برای هر زیرشبکه و/یا شبکه مشترک تعیین شود. کارساز از آن‌ها به عنوان گزینش‌گر رابطه استفاده می‌کند. در صورتی که این گزینش‌گرها برای هر یک از زیرشبکه‌ها تعیین نشده باشند، یک خطای پیکربندی به‌شمار می‌رود. آرگومان نخست، اطلاعات شناسایی کلاینت است. آرگومان دوم، پیشوند زیرشبکه است.
HA_SUBNET4_SELECT_NO_SUBNET_SELECTED
0.0
3.5
%1: unable to determine HA relationship because no subnet has been selected for the client
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv4 دریافت‌شده توسط این کارساز نادیده گرفته می‌شود؛ چرا که نتوانسته زیرشبکه‌ای برای این کلاینت انتخاب کند. انتخاب زیرشبکه برای یافتن رابطه HA مناسب ضروری است. این پیام هنگامی که کارساز تنها یک رابطه دارد صادر نمی‌شود. آرگومان این پیام، اطلاعات شناسایی کلاینت است.
HA_SUBNET6_SELECT_FAILED
0.0
3.5
subnet6_select callout failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که فراخوانی نقطه‌قلاب (hook point) subnet6_select با شکست مواجه شده باشد. این وضعیت ممکن است در پی یک خطای داخلی در کارساز رخ دهد. آرگومان ارائه‌شده شامل دلیل بروز خطا است.
HA_SUBNET6_SELECT_INVALID_HA_SERVER_NAME
0.0
3.5
%1: invalid ha-server-name value for subnet %2
168u
168u
این پیام خطا زمانی صادر می‌شود که پرس‌وجوی DHCPv6 دریافت‌شده توسط این کارساز نادیده گرفته می‌شود؛ زیرا مقدار ha-server-name مشخص‌شده در user-context زیرشبکه، از نوع رشته‌ای نیست یا خالی است. این حالت نشان‌دهنده پیکربندی نادرست در کارساز است. آرگومان نخست، اطلاعات شناسایی کلاینت و آرگومان دوم، پیشوند زیرشبکه است.
HA_SUBNET6_SELECT_NOT_FOR_US
0.0
3.5
%1: dropping query in relationship %2 to be processed by another server
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv6 دریافت‌شده توسط این کارساز نادیده گرفته می‌شود؛ به این دلیل که پرس‌وجو باید توسط کارساز دیگری پاسخ داده شود. این وضعیت زمانی اتفاق می‌افتد که یک کارساز اولیه (primary) از راه دور فعال و آماده خدمت‌رسانی است. آرگومان نخست، اطلاعات شناسایی کلاینت و آرگومان دوم، نام رابطه است.
HA_SUBNET6_SELECT_NO_RELATIONSHIP_FOR_SUBNET
0.0
3.5
%1: HA relationship not found for %2
168u
168u
این پیام خطا زمانی صادر می‌شود که پرس‌وجوی DHCPv6 دریافت‌شده توسط این کارساز نادیده گرفته می‌شود؛ چرا که کارساز نتوانسته رابطه‌ای منطبق بر ha-server-name مشخص‌شده برای زیرشبکه پیدا کند. نام کارساز با هیچ‌یک از روابط مشخص‌شده در پیکربندی HA تطابق ندارد. دلیل متداول این مشکل، وجود اشتباه تایپی است. آرگومان نخست، اطلاعات شناسایی کلاینت و آرگومان دوم، نام رابطه است.
HA_SUBNET6_SELECT_NO_RELATIONSHIP_SELECTOR_FOR_SUBNET
0.0
3.5
%1: unable to determine HA relationship because selected subnet %2 lacks the ha-server-name
168u
168u
این پیام خطا زمانی صادر می‌شود که پرس‌وجوی DHCPv6 دریافت‌شده توسط این کارساز نادیده گرفته می‌شود؛ زیرا قادر به تعیین رابطه HA که پرس‌وجوی دریافت‌شده به آن تعلق دارد نبوده است. در صورت وجود چندین رابطه، مشخص کردن مقدار ha-server-name در user-context در سطح زیرشبکه یا شبکه مشترک برای هر زیرشبکه و/یا شبکه مشترک الزامی است. کارساز از آن‌ها به عنوان گزینش‌گر رابطه استفاده می‌کند. چنانچه این گزینش‌گرها برای هر یک از زیرشبکه‌ها تعیین نشده باشند، خطای پیکربندی رخ داده است. آرگومان نخست، اطلاعات شناسایی کلاینت و آرگومان دوم، پیشوند زیرشبکه است.
HA_SUBNET6_SELECT_NO_SUBNET_SELECTED
0.0
3.5
%1: unable to determine HA relationship because no subnet has been selected for the client
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پرس‌وجوی DHCPv6 دریافت‌شده توسط این کارساز نادیده گرفته می‌شود؛ چرا که نتوانسته زیرشبکه‌ای برای این کلاینت برگزیند. انتخاب زیرشبکه به منظور یافتن یک رابطه HA مناسب الزامی است. این پیام در صورتی که کارساز فقط دارای یک رابطه باشد تولید نخواهد شد. آرگومان موجود، اطلاعات شناسایی کلاینت است..SS HA_SYNC_COMPLETE_NOTIFY_COMMUNICATIONS_FAILED
0.0
3.5
%1: failed to send ha-sync-complete-notify to %2: %3
168u
168u
این پیام هشدار نشان‌دهندهٔ وجود مشکلی در برقراری ارتباط با یک همتای HA هنگام ارسال دستور ha-sync-complete-notify است. آرگومان نخست، نام سرور محلی را مشخص می‌کند. آرگومان دوم، نام سرور دوردست را مشخص می‌کند. آرگومان سوم دلیل این شکست را ارائه می‌دهد.
HA_SYNC_COMPLETE_NOTIFY_FAILED
0.0
3.5
%1: error processing ha-sync-complete-notify command on %2: %3
168u
168u
این پیام هشدار نشان می‌دهد که یک همتا در پاسخ به دستور ha-sync-complete-notify یک کد وضعیت خطا برگردانده است. آرگومان نخست، نام سرور محلی را مشخص می‌کند. آرگومان دوم، نام سرور دوردست را مشخص می‌کند. آرگومان سوم دلیل این شکست را ارائه می‌دهد.
HA_SYNC_COMPLETE_NOTIFY_HANDLER_FAILED
0.0
3.5
ha-sync-complete-notify command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور ha-sync-complete-notify در حین پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
HA_SYNC_FAILED
0.0
3.5
%1: lease database synchronization with %2 failed: %3
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که همگام‌سازی پایگاه‌دادهٔ اجاره‌ها (lease database) با شکست مواجه شده است. آرگومان نخست نام سرور محلی را مشخص می‌کند. آرگومان دوم نام سرور شریک را مشخص می‌کند. آرگومان سوم دلیل این شکست را بیان می‌کند.
HA_SYNC_HANDLER_FAILED
0.0
3.5
ha-sync command failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ آن است که گردانندهٔ دستور ha-sync در حین پردازش دستور با شکست مواجه شده است. این آرگومان دلیل شکست را مشخص می‌کند.
HA_SYNC_START
0.0
3.5
%1: starting lease database synchronization with %2
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که سرور همگام‌سازی پایگاه‌دادهٔ اجاره‌ها را با یک سرور شریک آغاز می‌کند. آرگومان‌ها نام سرورهای محلی و دوردست را مشخص می‌کنند.
HA_SYNC_SUCCESSFUL
0.0
3.5
%1: lease database synchronization with %2 completed successfully in %3
168u
168u
این پیام اطلاع‌رسانی هنگامی صادر می‌شود که سرور همگام‌سازی پایگاه‌دادهٔ اجاره‌ها را با سرور شریک با موفقیت به پایان رسانده است. آرگومان نخست نام سرور محلی را مشخص می‌کند. آرگومان دوم نام سرور شریک را تعیین می‌کند. آرگومان سوم مدت‌زمان فرایند همگام‌سازی را نشان می‌دهد.
HA_TERMINATED
0.0
3.5
HA %1: service terminated due to an unrecoverable condition. Check previous error message(s), address the problem and restart!
168u
168u
این پیام خطا بیانگر آن است که سرویس HA به‌دلیل یک وضعیت غیرقابل‌قبول (مانند انحراف زمانی بیش از حد ساعت یا clock skew) متوقف شده است. علت دقیق این رخداد باید در پیام(های) خطای پیشین مشخص شده باشد. وضعیت گزارش‌شده را برطرف کرده و سپس سرورها را بازراه‌اندازی کنید تا ارائهٔ سرویس ادامه یابد.
HA_TERMINATED_PARTNER_DID_NOT_RESTART
0.0
3.5
%1: service is terminating because the terminated partner was not restarted within %2 minutes
168u
168u
این پیام هشدار نشان می‌دهد که سرویس HA در حال خاتمه یافتن است، زیرا سرور شریک در وضعیت خاتمه‌یافته (terminated) قرار دارد و در بازهٔ زمانی مورد انتظار بازراه‌اندازی نشده است. سرورهای متوقف‌شده باید پس از رفع مشکلی که موجب توقف آن‌ها شده است، مجدداً راه‌اندازی شوند. امکان راه‌اندازی متوالی آن‌ها وجود دارد اما فاصلهٔ زمانی بین این راه‌اندازی‌ها نباید طولانی باشد. در صورت طولانی شدن، ممکن است به این معنا باشد که راه‌اندازی یکی از سرورها غیرعمدی بوده است (برای نمونه قطع برق). اگر سرورِ بازراه‌اندازی‌شده در حالت انتظار (waiting) باقی بماند، نمی‌تواند به کلاینت‌های DHCP سرویس‌دهی کند. رفتن به وضعیت خاتمه‌یافته دست‌کم امکان پاسخ‌گویی به ترافیک DHCP را فراهم می‌کند..SS HA_TERMINATED_RESTART_PARTNER
0.0
3.5
%1: waiting for the partner in the TERMINATED state to be restarted
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کارگزار پس از اصلاح انحراف ساعت (clock skew) مجدداً راه‌اندازی شده باشد. کارگزار همکار (partner server) همچنان در وضعیت خاتمه‌یافته (TERMINATED) قرار دارد. پیش از آنکه کارگزار بتواند پایگاه داده را همگام‌سازی کرده و عملکرد عادی را آغاز کند، همکار باید مجدداً راه‌اندازی شود.
HOOKS
HOOKS_ALL_CALLOUTS_DEREGISTERED
0.0
3.5
hook library at index %1 removed all callouts on hook %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تمام calloutهای روی hook مشخص‌شده که توسط کتابخانه با شاخص داده‌شده ثبت شده بودند، حذف شوند. این پیام مشابه پیام HOOKS_CALLOUTS_REMOVED است (و احتمالاً هر دو با هم دیده می‌شوند)، اما در سطح پایین‌تری از چارچوب hook صادر می‌شود.
HOOKS_CALLOUTS_BEGIN
0.0
3.5
begin all callouts for hook %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که مدیر callout فراخوانی calloutها را برای hook آغاز می‌کند. آرگومان نام hook را مشخص می‌کند.
HOOKS_CALLOUTS_COMPLETE
0.0
3.5
completed callouts for hook %1 (total callouts duration: %2)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که مدیر callout اجرای تمام calloutها را برای hook مورد نظر به پایان رسانده باشد. آرگومان‌ها نام hook و مدت زمان کل اجرای تمام calloutها را بر حسب میلی‌ثانیه مشخص می‌کنند.
HOOKS_CALLOUTS_REMOVED
0.0
3.5
callouts removed from hook %1 for library %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هنگام تخلیه بارگذاری کتابخانه صادر می‌شود. این پیام مشخص می‌کند که یک یا چند callout ثبت‌شده توسط آن کتابخانه از hook مشخص‌شده حذف شده‌اند. این پیام شبیه پیام HOOKS_DEREGISTER_ALL_CALLOUTS است (و احتمال دارد هر دو با هم مشاهده شوند)، اما در سطح بالاتری از چارچوب hook صادر می‌شود.
HOOKS_CALLOUT_CALLED
0.0
3.5
hooks library with index %1 has called a callout on hook %2 that has address %3 (callout duration: %4)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این پیام که تنها در سطوح بالای اشکال‌زدایی نشان داده می‌شود، بیانگر این است که یک callout روی hook نام‌برده، ثبت‌شده توسط کتابخانه با شاخص داده‌شده (در فهرست کتابخانه‌های بارگذاری‌شده)، فراخوانی شده و وضعیت موفقیت‌آمیز بازگردانده است. نشانی callout در پیام آمده است. همچنین پیام شامل مدت زمان اجرای callout بر حسب میلی‌ثانیه می‌باشد.
HOOKS_CALLOUT_DEREGISTERED
0.0
3.5
hook library at index %1 deregistered a callout on hook %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تمام نمونه‌های یک callout خاص روی hook مشخص‌شده در پیام، که توسط کتابخانه با شاخص داده‌شده ثبت شده بودند، حذف شده باشند.
HOOKS_CALLOUT_ERROR
0.0
3.5
error returned by callout on hook %1 registered by library with index %2 (callout address %3) (callout duration %4)
168u
168u
اگر یک callout هنگام فراخوانی وضعیت خطا بازگرداند، این پیام خطا صادر می‌شود. این پیام، hookای را که callout به آن متصل است، شاخص کتابخانه (در فهرست کتابخانه‌های بارگذاری‌شده) که آن را ثبت کرده است، و نشانی callout را مشخص می‌کند. در غیر این صورت، خطا نادیده گرفته می‌شود. پیام خطا شامل مدت زمان اجرای callout بر حسب میلی‌ثانیه نیز هست.
HOOKS_CALLOUT_EXCEPTION
0.0
3.5
exception thrown by callout on hook %1 registered by library with index %2 (callout address %3): %4 (callout duration: %5)
168u
168u
اگر یک callout هنگام فراخوانی یک استثنا (exception) ایجاد کند، این پیام خطا صادر می‌شود. این پیام، hookای را که callout به آن متصل است، شاخص کتابخانه (در فهرست کتابخانه‌های بارگذاری‌شده) که آن را ثبت کرده است، و نشانی callout را مشخص می‌کند. در غیر این صورت، خطا نادیده گرفته می‌شود. پیام خطا شامل مدت زمان اجرای callout بر حسب میلی‌ثانیه نیز هست..SS HOOKS_CALLOUT_REGISTRATION
0.0
3.5
hooks library with index %1 registering callout for hook '%2'
168u
168u
در سطح ثبت اشکال‌زدایی ۴۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هنگام ثبت یک فراخوانی (callout) توسط یک کتابخانه (که اندیس آن در فهرست کتابخانه‌های در حال بارگذاری مشخص شده) نشان داده می‌شود.
HOOKS_CLOSE_ERROR
0.0
3.5
failed to close hook library %1: %2
168u
168u
سامانه Kea به دلیل ذکرشده نتوانست کتابخانه قلاب (hook) نام‌برده را ببندد.
اگرچه این یک خطاست، اما به جز اتلاف منابع نباید تأثیری بر سامانهٔ در حال اجرا بگذارد. اگر این خطا ادامه داشت، باید Kea را بازراه‌اندازی کنید.
HOOKS_HOOK_LIST_RESET
0.0
3.5
the list of hooks has been reset
168u
168u
این پیامی است که نشان می‌دهد فهرست قلاب‌ها بازنشانی شده است.
در حالی که این اتفاق هنگام اجرای مجموعه آزمون‌های Kea معمول است، نباید هنگام اجرای Kea در یک محیط عملیاتی دیده شود. اگر این پیام ظاهر شد، لطفاً از طریق مجاری معمول یک گزارش باگ ارسال کنید.
HOOKS_INCORRECT_VERSION
0.0
3.5
hook library %1 is at version %2, require version %3
168u
168u
سامانه Kea تشخیص داده است که کتابخانه قلاب نام‌برده با نسخه‌ای از Kea ساخته شده است که با نسخهٔ Kea در حال اجرا روی سامانهٔ شما ناسازگار است؛ از این رو کتابخانه را بارگذاری نکرده است.
این وضعیت به احتمال زیاد ناشی از نصب نسخهٔ جدیدی از Kea بدون کامپایل مجدد کتابخانه قلاب است. ساخت و نصب مجدد کتابخانه در بیشتر موارد مشکل را برطرف می‌کند.
HOOKS_LIBPATH_SECURITY_WARNING
0.0
3.5
Library path specified is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که الزام امنیتی غیرفعال شده باشد و مسیر تعیین‌شده برای یک کتابخانه قلاب مشخص، با مسیرهای پشتیبانی‌شده مطابقت نداشته باشد. سرور همچنان کتابخانه قلاب را بارگذاری می‌کند، اما هشدار می‌دهد که انجام این کار ممکن است خطرات امنیتی به همراه داشته باشد.
HOOKS_LIBRARY_CLOSED
0.0
3.5
hooks library %1 successfully closed
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که یک کتابخانه قلاب‌های ارائه‌شده توسط کاربر با موفقیت بسته شده باشد.
HOOKS_LIBRARY_LOADED
0.0
3.5
hooks library %1 successfully loaded
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که یک کتابخانه قلاب‌های ارائه‌شده توسط کاربر با موفقیت بارگذاری شده باشد.
HOOKS_LIBRARY_LOADING
0.0
3.5
loading hooks library %1
168u
168u
در سطح ثبت اشکال‌زدایی ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که درست پیش از بارگذاری کتابخانهٔ مشخص‌شده نمایش داده می‌شود.
در صورت موفقیت‌آمیز بودن عملیات، این پیام با پیام اطلاع‌رسانی HOOKS_LIBRARY_LOADED دنبال خواهد شد.
HOOKS_LIBRARY_MULTI_THREADING_COMPATIBLE
0.0
3.5
hooks library %1 reports its multi-threading compatibility as %2
168u
168u
در سطح ثبت اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تابع "multi_threading_compatible" فراخوانی شده باشد. مقدار بازگردانده‌شده (۰ به معنای ناسازگار و سایر مقادیر به معنای سازگار) نمایش داده می‌شود..SS HOOKS_LIBRARY_MULTI_THREADING_NOT_COMPATIBLE
0.0
3.5
hooks library %1 is not compatible with multi-threading
168u
168u
هنگامی که چندنخی (multi-threading) فعال باشد و کتابخانه سازگار نباشد (خواه به این دلیل که تابع "multi_threading_compatible" مقدار 0 را برگردانده یا اینکه پیاده‌سازی نشده باشد)، این پیام خطا صادر می‌شود. کتابخانه باید از پیکربندی حذف شود یا اینکه چندنخی غیرفعال گردد.
HOOKS_LIBRARY_UNLOADED
0.0
3.5
hooks library %1 successfully unloaded
168u
168u
این پیام اطلاع‌رسانی هنگامی صادر می‌شود که یک کتابخانهٔ قلاب‌ها (hooks library) ارائه‌شده از سوی کاربر با موفقیت تخلیه (unload) شده باشد.
HOOKS_LIBRARY_UNLOADING
0.0
3.5
unloading library %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) 40 ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که کتابخانهٔ مشخص‌شده در حال تخلیه شدن باشد. اگر همه‌چیز با موفقیت انجام شود، پیام اطلاع‌رسانی HOOKS_LIBRARY_UNLOADED به دنبال آن خواهد آمد.
HOOKS_LIBRARY_VERSION
0.0
3.5
hooks library %1 reports its version as %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) 45 ثبت می‌شود.
پیامی اشکال‌زدایی که هنگام موفقیت‌آمیز بودن بررسی نسخهٔ کتابخانهٔ قلاب‌ها صادر می‌شود.
HOOKS_LOAD_ERROR
0.0
3.5
'load' function in hook library %1 returned error %2
168u
168u
تابع "load" در کتابخانهٔ نام‌برده در پیام پیدا و فراخوانی شد. این تابع یک وضعیت غیرصفر (که آن هم در پیام آمده است) برگرداند که به عنوان خطا تفسیر شد. کتابخانه تخلیه شده است و هیچ فراخوانی‌ای (callout) از آن نصب نخواهد شد.
HOOKS_LOAD_EXCEPTION
0.0
3.5
'load' function in hook library %1 threw an exception
168u
168u
تابع "load" در کتابخانهٔ نام‌برده در پیام پیدا و فراخوانی شد. این تابع در حین اجرا یک استثنا (نشانه‌ای از بروز خطا) پرتاب کرد که یک وضعیت خطاست. کتابخانه تخلیه شده است و هیچ فراخوانی‌ای (callout) از آن نصب نخواهد شد.
HOOKS_LOAD_FRAMEWORK_EXCEPTION
0.0
3.5
'load' function in hook library %1 threw an exception: reason %2
168u
168u
تابع "load" در کتابخانهٔ نام‌برده در پیام پیدا و فراخوانی شد. چارچوب قلاب‌ها یا خود تابع در حین اجرا یک استثنا (نشانه‌ای از بروز خطا) ایجاد کردند که وضعیتی خطاست؛ علت استثنا در پیام ثبت شده است. کتابخانه تخلیه شده است و هیچ فراخوانی‌ای (callout) از آن نصب نخواهد شد.
HOOKS_LOAD_SUCCESS
0.0
3.5
'load' function in hook library %1 returned success
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) 40 ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که تابع "load" در یک کتابخانهٔ قلاب پیدا شده و با موفقیت فراخوانی شده باشد.
HOOKS_MULTI_THREADING_COMPATIBLE_EXCEPTION
0.0
3.5
'multi_threading_compatible' function in hook library %1 threw an exception
168u
168u
این پیام خطا زمانی صادر می‌شود که تابع multi_threading_compatible() در کتابخانهٔ قلابِ مشخص‌شده فراخوانی شده و یک استثنا ایجاد کرده باشد. این کتابخانه غیرقابل‌استفاده تلقی شده و بارگذاری نخواهد شد..SS HOOKS_NO_LOAD
0.0
3.5
no 'load' function found in hook library %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و نشان می‌دهد که کتابخانه مشخص‌شده بارگذاری شد،
اما هیچ تابعی با نام "load" در آن یافت نشد. به شرطی که کتابخانه
حاوی چند تابع «استاندارد» باشد (یعنی توابعی با نام‌های hookهای سرور
مربوطه)، این مورد مشکلی ایجاد نمی‌کند.
HOOKS_NO_UNLOAD
0.0
3.5
no 'unload' function found in hook library %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هنگام تخلیه (unload) کتابخانه از حافظه صادر می‌شود.
این پیام صرفاً بیان می‌کند که کتابخانه شامل تابع "unload" نبوده است.
HOOKS_NO_VERSION
0.0
3.5
no 'version' function found in hook library %1
168u
168u
کتابخانه اشتراکی ذکرشده در پیام پیدا شده و با موفقیت بارگذاری شد،
اما Kea هیچ تابعی با نام "version" در آن نیافت. این تابع الزامی
است و باید نسخه Kea را که کتابخانه بر اساس آن ساخته شده است بازگرداند.
این مقدار برای بررسی سازگار بودن نسخه Kea با نسخه ساخته‌شده کتابخانه
استفاده می‌شود. کتابخانه بارگذاری نشده است.
HOOKS_OPEN_ERROR
0.0
3.5
failed to open hook library %1: %2
168u
168u
‏Kea به دلیل ذکرشده نتوانست کتابخانه hook مشخص‌شده را باز کند.
کتابخانه بارگذاری نشده است. Kea به عملکرد خود ادامه خواهد داد،
اما بدون سرویس‌هایی که توسط این کتابخانه ارائه می‌شوند.
HOOKS_STD_CALLOUT_REGISTERED
0.0
3.5
hooks library %1 registered standard callout for hook %2 at address %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۵ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی در خروجی ثبت می‌شود که تابع بارگذاری کتابخانه،
یک callout استاندارد (یک callout با نامی یکسان با نقطه hook) را پیدا کرده
و آن را ثبت کرده باشد. نشانی callout نیز مشخص شده است.
HOOKS_UNLOAD_ERROR
0.0
3.5
'unload' function in hook library %1 returned error %2
168u
168u
هنگام تخلیه کتابخانه از حافظه، یک تابع "unload" پیدا شد.
این تابع فراخوانی گردید، اما وضعیت خطا (غیر-صفر) برگرداند که باعث
صدور این پیام شد. فرایند تخلیه پس از این پیام ادامه یافت و کتابخانه
از حافظه تخلیه شد.
HOOKS_UNLOAD_EXCEPTION
0.0
3.5
'unload' function in hook library %1 threw an exception
168u
168u
هنگام تخلیه کتابخانه از حافظه، یک تابع "unload" پیدا شد. این تابع
فراخوانی شد، اما در حین اجرا یک استثنا (نشانگر خطا) ایجاد کرد.
فرایند تخلیه پس از این پیام ادامه یافت و کتابخانه از حافظه
تخلیه شد.
HOOKS_UNLOAD_FRAMEWORK_EXCEPTION
0.0
3.5
'unload' function in hook library %1 threw an exception, reason %2
168u
168u
هنگام تخلیه کتابخانه از حافظه، یک تابع "unload" پیدا شد.
این تابع فراخوانی شد، اما در حین اجرا خود تابع یا چارچوب hooks
یک استثنا (نشانگر خطا) ایجاد کرد؛ دلیل خطا در پیام ثبت شده است.
فرایند تخلیه پس از این پیام ادامه یافت و کتابخانه از حافظه
تخلیه شد.
HOOKS_UNLOAD_SUCCESS
0.0
3.5
'unload' function in hook library %1 returned success
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این یک پیام اشکال‌زدایی است و زمانی صادر می‌شود که یک تابع "unload" در طول
فرایند تخلیه در یک کتابخانه hook پیدا شده، فراخوانی شده و با موفقیت پایان یافته باشد..SS HOOKS_VERSION_EXCEPTION
0.0
3.5
تابع 'version' در کتابخانه هوک %1 یک استثنا ایجاد کرد
168u
168u
این پیام خطا زمانی صادر می‌شود که تابع version() در کتابخانه هوک مشخص‌شده
فراخوانی شده و یک استثنا ایجاد کرده باشد. این کتابخانه غیرقابل‌استفاده در نظر
گرفته شده و بارگذاری نخواهد شد.
HOSTS
HOSTS_BACKENDS_REGISTERED
0.0
3.5
انواع بک‌اند میزبان زیر در دسترس هستند: %1
168u
168u
این پیام اطلاع‌رسانی، تمام بک‌اندهای میزبان ممکن را که می‌توان در
hosts-database[s] استفاده کرد فهرست می‌کند.
HOSTS_BACKEND_DEREGISTER
0.0
3.5
نوع بک‌اند میزبان لغو ثبت شد: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که ثبت یک backend factory لغو شده باشد.
دیگر استفاده از بک‌اند میزبان از این نوع امکان‌پذیر نیست.
HOSTS_BACKEND_REGISTER
0.0
3.5
نوع بک‌اند میزبان ثبت شد: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک backend factory با موفقیت
ثبت شده باشد. اکنون امکان استفاده از بک‌اند میزبان از این نوع وجود دارد.
HOSTS_CFG_ADD_HOST
0.0
3.5
افزودن میزبان برای رزروها: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که میزبان جدیدی (به همراه رزروها) به
پیکربندی کارساز اضافه شود. این آرگومان، میزبان و رزروهای آن را با جزئیات
شرح می‌دهد.
HOSTS_CFG_CACHE_HOST_DATA_SOURCE
0.0
3.5
دریافت منبع داده حافظه پنهان میزبان: %1
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که یک منبع داده حافظه پنهان میزبان
توسط مدیر میزبان (host manager) شناسایی شود.
HOSTS_CFG_CLOSE_HOST_DATA_SOURCE
0.0
3.5
در حال بستن منبع داده میزبان: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این یک پیام عادی است که هنگام بستن اتصال منبع داده میزبان توسط کارساز
چاپ می‌شود.
HOSTS_CFG_DEL
0.0
3.5
تعداد %1 میزبان دارای %2 رزرو IPv6 برای شناسه زیرشبکه %3 و نشانی %4 حذف شد(ند)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که رزروها برای زیرشبکه و نشانی مشخص‌شده
حذف شوند. آرگومان نخست مشخص می‌کند چه تعداد میزبان حذف شده‌اند. آرگومان دوم
مشخص می‌کند چه تعداد رزرو حذف شده‌اند. آرگومان سوم شناسه زیرشبکه است. آرگومان
چهارم نشانی IP است.
HOSTS_CFG_DEL4
0.0
3.5
تعداد %1 میزبان برای شناسه زیرشبکه %2 و شناسه %3 حذف شد(ند)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که رزروهای IPv4 برای زیرشبکه و شناسه
مشخص‌شده حذف شوند. آرگومان نخست مشخص می‌کند چه تعداد میزبان حذف شده‌اند.
آرگومان دوم شناسه زیرشبکه است. آرگومان سوم شناسه موردنظر است..SS HOSTS_CFG_DEL6
0.0
3.5
deleted %1 host(s) having %2 IPv6 reservation(s) for subnet id %3 and identifier %4
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که رزروهای IPv6 برای زیرشبکه و شناسه مشخص‌شده حذف شوند. آرگومان نخست تعیین می‌کند چه تعداد میزبان حذف شده‌اند. آرگومان دوم مشخص می‌کند چه تعداد رزرو حذف شده‌اند. آرگومان سوم شناسه زیرشبکه است. آرگومان چهارم شناسه است.
HOSTS_CFG_DEL_ALL_SUBNET4
0.0
3.5
deleted all %1 host(s) for subnet id %2
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تمامی رزروهای IPv4 برای زیرشبکه مشخص‌شده حذف شوند. آرگومان نخست مشخص می‌کند چه تعداد رزرو حذف شده‌اند. آرگومان دوم شناسه زیرشبکه است.
HOSTS_CFG_DEL_ALL_SUBNET6
0.0
3.5
deleted all %1 host(s) having %2 IPv6 reservation(s) for subnet id %3
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تمامی رزروهای IPv6 برای زیرشبکه مشخص‌شده حذف شوند. آرگومان نخست مشخص می‌کند چه تعداد میزبان حذف شده‌اند. آرگومان دوم تعیین می‌کند چه تعداد رزرو IPv6 (نشانی‌ها و پیشوندها) حذف شده‌اند. آرگومان سوم شناسه زیرشبکه است.
HOSTS_CFG_GET_ALL
0.0
3.5
get all hosts with reservations
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی هنگام آغاز بازیابی تمام میزبان‌ها صادر می‌شود.
HOSTS_CFG_GET_ALL_ADDRESS4
0.0
3.5
get all hosts with reservations for IPv4 address %1
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی هنگام آغاز بازیابی تمامی میزبان‌های دارای رزرو برای نشانی IPv4 مشخص‌شده از پیکربندی صادر می‌شود. این آرگومان نشانی IPv4 به‌کاررفته برای جستجوی میزبان‌ها را مشخص می‌کند.
HOSTS_CFG_GET_ALL_ADDRESS4_COUNT
0.0
3.5
using address %1, found %2 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی 45 ثبت می‌شود.
این پیام اشکال‌زدایی تعداد میزبان‌های یافت‌شده با استفاده از نشانی IPv4 مشخص‌شده را ثبت می‌کند. آرگومان‌ها به‌ترتیب نشانی IPv4 استفاده‌شده و تعداد میزبان‌های یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_ADDRESS4_HOST
0.0
3.5
using address %1 found host: %2
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که میزبانی با رزرو برای نشانی IPv4 مشخص‌شده پیدا شود. آرگومان‌ها نشانی IPv4 و توضیحات تفصیلی میزبان یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_ADDRESS6
0.0
3.5
get all hosts with reservations for IPv6 address %1
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی هنگام آغاز بازیابی تمامی میزبان‌های دارای رزرو برای نشانی IPv6 مشخص‌شده از پیکربندی صادر می‌شود. این آرگومان نشانی IPv6 به‌کاررفته برای جستجوی میزبان‌ها را مشخص می‌کند.
HOSTS_CFG_GET_ALL_ADDRESS6_COUNT
0.0
3.5
using address %1, found %2 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی 45 ثبت می‌شود.
این پیام اشکال‌زدایی تعداد میزبان‌های یافت‌شده با استفاده از نشانی IPv6 مشخص‌شده را ثبت می‌کند. آرگومان‌ها به‌ترتیب نشانی IPv6 استفاده‌شده و تعداد میزبان‌های یافت‌شده را مشخص می‌کنند..SS HOSTS_CFG_GET_ALL_ADDRESS6_HOST
0.0
3.5
using address %1 found host: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 55 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که میزبانی با رزرو برای نشانی IPv6 مشخص‌شده یافت شود. آرگومان‌ها نشانی IPv6 و توضیحات تفصیلی میزبان یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_COUNT
0.0
3.5
found %1 host(s)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 45 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان‌های یافت‌شده است. آرگومان تعداد میزبان‌های یافت‌شده را مشخص می‌کند.
HOSTS_CFG_GET_ALL_HOST
0.0
3.5
found host: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 55 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده است. آرگومان جزئیات میزبان یافت‌شده را مشخص می‌کند.
HOSTS_CFG_GET_ALL_HOSTNAME
0.0
3.5
get all hosts with reservations for hostname %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازیابی تمام میزبان‌های دارای hostname مشخص آغاز گردد. آرگومان hostname را مشخص می‌کند.
HOSTS_CFG_GET_ALL_HOSTNAME_COUNT
0.0
3.5
using hostname %1, found %2 host(s)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 45 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان‌های یافت‌شده با استفاده از hostname است. آرگومان‌ها به‌ترتیب hostname و تعداد میزبان‌های یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_HOSTNAME_HOST
0.0
3.5
using hostname %1, found host: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 55 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از hostname است. آرگومان‌ها به‌ترتیب hostname و جزئیات میزبان یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID4
0.0
3.5
get all hosts with reservations for hostname %1 and IPv4 subnet %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازیابی تمام میزبان‌های دارای hostname مشخص و متصل به زیرشبکه (subnet) خاص DHCPv4 آغاز گردد. آرگومان‌ها hostname و subnet id را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID4_COUNT
0.0
3.5
using hostname %1 and IPv4 subnet %2, found %3 host(s)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 45 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان‌های یافت‌شده با استفاده از hostname و DHCPv4 subnet id است. آرگومان‌ها به‌ترتیب hostname، شناسه زیرشبکه (subnet id) و تعداد میزبان‌های یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID4_HOST
0.0
3.5
using hostname %1 and IPv4 subnet %2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 55 ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از hostname و DHCPv4 subnet id است. آرگومان‌ها به‌ترتیب hostname، شناسه زیرشبکه (subnet id) و جزئیات میزبان یافت‌شده را مشخص می‌کنند..SS HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID6
0.0
3.5
get all hosts with reservations for hostname %1 and IPv6 subnet %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع بازیابی تمام میزبان‌های دارای نام میزبان خاص متصل به زیرشبکه DHCPv6 مشخص صادر می‌شود. این آرگومان hostname و subnet id را مشخص می‌کند.
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID6_COUNT
0.0
3.5
using hostname %1 and IPv6 subnet %2, found %3 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان‌های یافت‌شده با استفاده از hostname و DHCPv6 subnet id است. آرگومان‌ها به ترتیب hostname، subnet id و تعداد میزبان‌های یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID6_HOST
0.0
3.5
using hostname %1 and IPv6 subnet %2, found host: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از hostname و DHCPv6 subnet id است. آرگومان‌ها به ترتیب hostname، subnet id و جزئیات میزبان یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_IDENTIFIER
0.0
3.5
get all hosts with reservations using identifier: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع بازیابی رزروها برای تمام میزبان‌های شناسایی‌شده با HW address یا DUID صادر می‌شود. این آرگومان هم نوع شناسه و هم مقدار آن را مشخص می‌کند.
HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT
0.0
3.5
using identifier %1, found %2 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی تعداد میزبان‌های یافت‌شده با استفاده از شناسه مشخص‌شده را ثبت می‌کند. آرگومان‌ها به ترتیب شناسه استفاده‌شده و تعداد میزبان‌های یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_IDENTIFIER_HOST
0.0
3.5
using identifier: %1, found host: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام یافتن میزبان شناسایی‌شده با شناسه خاص صادر می‌شود. آرگومان‌ها شناسه و شرح تفصیلی میزبان یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_SUBNET_ID4
0.0
3.5
get all hosts with reservations for IPv4 subnet %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع بازیابی تمام میزبان‌های متصل به زیرشبکه DHCPv4 خاص صادر می‌شود. این آرگومان subnet id را مشخص می‌کند.
HOSTS_CFG_GET_ALL_SUBNET_ID4_COUNT
0.0
3.5
using IPv4 subnet %1, found %2 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان‌های یافت‌شده با استفاده از DHCPv4 subnet id است. آرگومان‌ها به ترتیب subnet id و تعداد میزبان‌های یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_SUBNET_ID4_HOST
0.0
3.5
using IPv4 subnet %1, found host: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از DHCPv4 subnet id است. آرگومان‌ها به ترتیب subnet id و جزئیات میزبان یافت‌شده را مشخص می‌کنند..SS HOSTS_CFG_GET_ALL_SUBNET_ID6
0.0
3.5
get all hosts with reservations for IPv6 subnet %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع بازیابی تمام میزبان‌های متصل به
زیرشبکهٔ DHCPv6 مشخص صادر می‌شود. این آرگومان شناسهٔ زیرشبکه را مشخص می‌کند.
HOSTS_CFG_GET_ALL_SUBNET_ID6_COUNT
0.0
3.5
using IPv6 subnet %1, found %2 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از شناسهٔ زیرشبکهٔ DHCPv6
است. آرگومان‌ها به‌ترتیب شناسهٔ زیرشبکه و تعداد میزبان‌های یافت‌شده را مشخص
می‌کنند.
HOSTS_CFG_GET_ALL_SUBNET_ID6_HOST
0.0
3.5
using IPv6 subnet %1, found host: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از شناسهٔ زیرشبکهٔ DHCPv6
است. آرگومان‌ها به‌ترتیب شناسهٔ زیرشبکه و جزئیات میزبان یافت‌شده را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS4
0.0
3.5
get all hosts with reservations for subnet id %1 and IPv4 address %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع بازیابی تمام میزبان‌هایی که دارای رزرو برای
نشانی IPv4 داده‌شده در زیرشبکهٔ داده‌شده هستند، صادر می‌شود. آرگومان نخست
شناسهٔ زیرشبکه را مشخص می‌کند. آرگومان دوم نشانی IPv4 را که باید رزرو
برای آن بازگردانده شود، مشخص می‌کند.
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS4_COUNT
0.0
3.5
using IPv4 subnet %1 and IPv4 address %2, found %3 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی تعداد میزبان‌های یافت‌شده‌ای را که دارای رزرو برای نشانی IPv4
مشخص‌شده در زیرشبکهٔ مشخص‌شده هستند، ثبت می‌کند. آرگومان نخست شناسهٔ زیرشبکه را
مشخص می‌کند. آرگومان دوم نشانی IPv4 رزروشده را مشخص می‌کند. آرگومان سوم تعداد
میزبان‌های یافت‌شده را مشخص می‌کند.
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS4_HOST
0.0
3.5
using IPv4 subnet %1 and IPv4 address %2, found host: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که میزبانی دارای رزرو برای نشانی IPv4
مشخص‌شده در زیرشبکهٔ مشخص‌شده پیدا شود. آرگومان نخست شناسهٔ زیرشبکه را مشخص
می‌کند. آرگومان دوم نشانی IPv4 رزروشده را مشخص می‌کند. آرگومان سوم جزئیات میزبان
را مشخص می‌کند.
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6
0.0
3.5
get all hosts with reservations for subnet id %1 and IPv6 address %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع بازیابی تمام میزبان‌های متصل به زیرشبکهٔ مشخص
صادر می‌شود که دارای نشانی IPv6 رزروشدهٔ مشخصی هستند. آرگومان‌ها به‌ترتیب
شناسهٔ زیرشبکه و نشانی IPv6 را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_COUNT
0.0
3.5
using subnet id %1 and address %2, found %3 host(s)
168u
168u
در سطح لاگ اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از شناسهٔ زیرشبکه و
نشانی است. آرگومان‌ها به‌ترتیب شناسهٔ زیرشبکه، نشانی و تعداد میزبان‌های یافت‌شده
را مشخص می‌کنند.
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_HOST
0.0
3.5
using subnet id %1 and address %2, found host: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از شناسهٔ زیرشبکه و
نشانی است. آرگومان‌ها به‌ترتیب شناسهٔ زیرشبکه، نشانی و جزئیات میزبان یافت‌شده
را مشخص می‌کنند..SS HOSTS_CFG_GET_ONE_PREFIX
0.0
3.5
get one host with reservation for prefix %1/%2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازیابی میزبانی با رزرو برای یک
پیشوند مشخص آغاز شود. آرگومان‌ها یک پیشوند و طول پیشوند را مشخص می‌کنند.
HOSTS_CFG_GET_ONE_PREFIX_HOST
0.0
3.5
using prefix %1/%2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبان یافت‌شده با استفاده از پیشوند/طول
پیشوند مشخص است. آرگومان‌ها به ترتیب پیشوند، طول پیشوند و جزئیات میزبان را
مشخص می‌کنند.
HOSTS_CFG_GET_ONE_PREFIX_NULL
0.0
3.5
host not found using prefix %1/%2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ میزبانی برای پیشوند و طول
پیشوند مشخص‌شده یافت نشود.
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4
0.0
3.5
get one host with reservation for subnet id %1 and IPv4 address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که بازیابی میزبان متصل به زیرشبکه
مشخص و دارای آدرس IPv4 رزروشده خاص آغاز شود. آرگومان‌ها به ترتیب شناسه
زیرشبکه و آدرس IPv4 را مشخص می‌کنند.
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_HOST
0.0
3.5
using subnet id %1 and address %2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی جزئیات میزبان یافت‌شده با استفاده از شناسه زیرشبکه
و آدرس IPv4 را ثبت می‌کند.
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL
0.0
3.5
host not found using subnet id %1 and address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ میزبانی برای شناسه زیرشبکه
و آدرس IPv4 مشخص‌شده یافت نشود.
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6
0.0
3.5
get one host with reservation for subnet id %1 and having IPv6 address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که بازیابی میزبان متصل به زیرشبکه
مشخص و دارای آدرس IPv6 رزروشده خاص آغاز شود. آرگومان‌ها به ترتیب شناسه
زیرشبکه و آدرس IPv6 را مشخص می‌کنند.
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_HOST
0.0
3.5
using subnet id %1 and address %2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی جزئیات میزبان یافت‌شده با استفاده از شناسه زیرشبکه
و آدرس IPv6 را ثبت می‌کند.
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_NULL
0.0
3.5
host not found using subnet id %1 and address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ میزبانی با استفاده از شناسه
زیرشبکه و آدرس IPv6 مشخص‌شده یافت نشود..SS HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER
0.0
3.5
get one host with %1 reservation for subnet id %2, identified by %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازیابی میزبانی که دارای
رزروهای IPv4 یا IPv6 است، به زیرشبکه خاصی متصل بوده و با یک
شناسه یکتای مشخص شناسایی می‌شود، آغاز گردد. آرگومان نخست مشخص
می‌کند که آیا رزرو IPv4 مد نظر است یا IPv6.
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST
0.0
3.5
using subnet id %1 and identifier %2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبانی است که با استفاده از شناسه
زیرشبکه و شناسه میزبان مشخص یافت شده است.
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL
0.0
3.5
host not found using subnet id %1 and identifier %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که با استفاده از شناسه زیرشبکه
و شناسه میزبان مشخص‌شده هیچ میزبانی یافت نشود.
HOSTS_CFG_UPDATE_ADD
0.0
3.5
add the host for reservations: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک میزبان جدید (همراه با رزروها)
در طول یک به‌روزرسانی به پیکربندی سرور افزوده شود. این آرگومان میزبان
و رزروهای آن را با جزئیات شرح می‌دهد.
HOSTS_CFG_UPDATE_DEL4
0.0
3.5
deleted %1 host(s) for subnet id %2 and identifier %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که رزروهای IPv4 برای زیرشبکه
و شناسه مشخص‌شده در طول یک به‌روزرسانی حذف شوند. آرگومان نخست
مشخص می‌کند چه تعداد میزبان حذف شده‌اند. آرگومان دوم شناسه زیرشبکه
است. آرگومان سوم شناسه است.
HOSTS_CFG_UPDATE_DEL6
0.0
3.5
deleted %1 host(s) having %2 IPv6 reservation(s) for subnet id %3 and identifier %4
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که رزروهای IPv6 برای زیرشبکه
و شناسه مشخص‌شده در طول یک به‌روزرسانی حذف شوند. آرگومان نخست
مشخص می‌کند چه تعداد میزبان حذف شده‌اند. آرگومان دوم مشخص می‌کند
چه تعداد رزرو حذف شده‌اند. آرگومان سوم شناسه زیرشبکه است. آرگومان
چهارم شناسه است.
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4
0.0
3.5
trying alternate sources for host using subnet id %1 and address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که Host Manager میزبان متصل
به زیرشبکه مشخص را که دارای رزرو برای نشانی IPv4 مشخص است پیدا
نمی‌کند، و جستجو برای این میزبان را در منابع داده میزبان جایگزین آغاز
می‌کند.
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_IDENTIFIER
0.0
3.5
get one host with IPv4 reservation for subnet id %1, identified by %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بازیابی میزبانی که دارای
رزرو IPv4 است، به زیرشبکه خاصی متصل بوده و با یک شناسه یکتای
مشخص شناسایی می‌شود، آغاز گردد.
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_IDENTIFIER_HOST
0.0
3.5
using subnet id %1 and identifier %2, found in %3 host: %4
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبانی است که توسط یک منبع داده
میزبان‌های جایگزین با استفاده از یک شناسه زیرشبکه و شناسه میزبان
مشخص بازگردانده شده است..SS HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_IDENTIFIER_NULL
0.0
3.5
host not found using subnet id %1 and identifier %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که با استفاده از شناسه زیرشبکه و شناسه میزبان مشخص‌شده، هیچ میزبانی یافت نشود.
HOSTS_MGR_ALTERNATE_GET6_PREFIX
0.0
3.5
trying alternate sources for host using prefix %1/%2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که Host Manager میزبانی متصل به زیرشبکه مشخص را که دارای رزرو برای پیشوند تعیین‌شده باشد پیدا نکند، و جستجو برای این میزبان را در منابع داده جایگزین میزبان آغاز نماید.
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_ADDRESS6
0.0
3.5
trying alternate sources for host using subnet id %1 and IPv6 address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که Host Manager میزبانی متصل به زیرشبکه مشخص را که دارای رزرو برای نشانی IPv6 تعیین‌شده باشد پیدا نکند، و جستجو برای این میزبان را در منابع داده جایگزین میزبان آغاز نماید.
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_IDENTIFIER
0.0
3.5
get one host with IPv6 reservation for subnet id %1, identified by %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع بازیابی میزبانی صادر می‌شود که دارای رزرو IPv4 بوده، به زیرشبکه‌ای مشخص متصل است و با یک شناسه یکتای معین شناسایی می‌شود.
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_IDENTIFIER_HOST
0.0
3.5
using subnet id %1 and identifier %2, found in %3 host: %4
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات میزبانی است که توسط یک منبع داده جایگزین میزبان با استفاده از شناسه زیرشبکه و شناسه میزبان مشخص بازگردانده شده است.
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_IDENTIFIER_NULL
0.0
3.5
host not found using subnet id %1 and identifier %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که با استفاده از شناسه زیرشبکه و شناسه میزبان مشخص‌شده، هیچ میزبانی یافت نشود.
HOSTS_MGR_ALTERNATE_GET_ALL_SUBNET_ID_ADDRESS4
0.0
3.5
trying alternate sources for hosts using subnet id %1 and address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که Host Manager جستجو برای میزبان‌ها را در منابع داده جایگزین میزبان بر اساس شناسه زیرشبکه و نشانی IPv4 آغاز می‌کند.
HOSTS_MGR_ALTERNATE_GET_ALL_SUBNET_ID_ADDRESS6
0.0
3.5
trying alternate sources for hosts using subnet id %1 and address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که Host Manager جستجو برای میزبان‌ها را در منابع داده جایگزین میزبان بر اساس شناسه زیرشبکه و نشانی IPv6 آغاز می‌کند.
HOSTS_MGR_NON_UNIQUE_IP_UNSUPPORTED
0.0
3.5
host data source %1 does not support the mode in which IP reservations are non-unique
168u
168u
این پیام هشدار زمانی صادر می‌شود که مدیر سیستم تلاش کرده باشد کارساز را به گونه‌ای پیکربندی کند که چندین رزرو میزبان برای یک نشانی IP یا پیشوند یکسان مجاز باشد.
برخی از backendهای پایگاه‌داده میزبان ممکن است از این حالت عملکرد پشتیبانی نکنند. در این صورت مدیر سیستم باید استفاده از این backendها را متوقف کند یا به حالت پیش‌فرض که نیازمند یکتا بودن نشانی‌های IP درون یک زیرشبکه است بازگردد.
کارکرد این تنظیم برای backendهای میزبان MySQL و Postgres تضمین شده است..SS HOST
HOST_CACHE_ADD
0.0
3.5
add host: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 45 ثبت می‌شود.
این پیام اشکال‌زدایی جزئیات مدخل اضافه‌شده به حافظهٔ نهان (cache) میزبان را ثبت می‌کند.
HOST_CACHE_ADD_DUPLICATE
0.0
3.5
duplicate host: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 45 ثبت می‌شود.
عملیات افزودن ناموفق بود زیرا این مدخل با مدخل موجود دیگری تداخل دارد. جزئیات آرگومان عملیات افزودن ثبت می‌شود.
HOST_CACHE_COMMAND_CLEAR
0.0
3.5
cache-clear command successful
168u
168u
دستور cache-clear موفقیت‌آمیز بوده است.
HOST_CACHE_COMMAND_CLEAR_FAILED
0.0
3.5
cache-clear command failed (reason: %1)
168u
168u
دستور cache-clear با شکست مواجه شد. علت آن ثبت می‌شود.
HOST_CACHE_COMMAND_FLUSH
0.0
3.5
cache-flush command successful
168u
168u
دستور cache-flush موفقیت‌آمیز بوده است.
HOST_CACHE_COMMAND_FLUSH_FAILED
0.0
3.5
cache-flush command failed (parameters: %1, reason: %2)
168u
168u
دستور cache-flush با شکست مواجه شد. هم علت و هم پارامترهای ارسالی ثبت می‌شوند.
HOST_CACHE_COMMAND_GET
0.0
3.5
cache-get command successful (returned: %1)
168u
168u
دستور cache-get موفقیت‌آمیز بوده است. تعداد مدخل‌های بازگردانده‌شده ثبت می‌شود.
HOST_CACHE_COMMAND_GET_BY_ID
0.0
3.5
cache-get-by-id command successful (returned: %1)
168u
168u
دستور cache-get-by-id موفقیت‌آمیز بوده است. تعداد مدخل‌های بازگردانده‌شده ثبت می‌شود.
HOST_CACHE_COMMAND_GET_BY_ID_FAILED
0.0
3.5
cache-get-by-id command failed (reason: %1)
168u
168u
دستور cache-get-by-id با شکست مواجه شد. علت آن ثبت می‌شود.
HOST_CACHE_COMMAND_GET_FAILED
0.0
3.5
cache-get command failed (reason: %1)
168u
168u
دستور cache-get با شکست مواجه شد. علت آن ثبت می‌شود.
HOST_CACHE_COMMAND_INSERT
0.0
3.5
cache-insert command successful (inserted: %1, overwritten: %2)
168u
168u
دستور cache-insert موفقیت‌آمیز بوده است. تعداد مدخل‌های درج‌شده و تعداد مدخل‌هایی که با موارد جدیدتر بازنویسی شده‌اند ثبت می‌شود..SS HOST_CACHE_COMMAND_INSERT_FAILED
0.0
3.5
cache-insert command failed (parameters: %1, reason: %2)
168u
168u
دستور cache-insert ناموفق بود. هم علت و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
HOST_CACHE_COMMAND_LOAD
0.0
3.5
cache-load command successful (loaded: %1, overwritten: %2)
168u
168u
دستور cache-load با موفقیت انجام شد. تعداد مدخل‌های بارگذاری‌شده و تعداد مدخل‌هایی که با داده‌های جدیدتر رونویسی شده‌اند در گزارش ثبت می‌شوند.
HOST_CACHE_COMMAND_LOAD_FAILED
0.0
3.5
cache-load command failed (parameters: %1, reason: %2)
168u
168u
دستور cache-load ناموفق بود. هم علت و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
HOST_CACHE_COMMAND_REMOVE
0.0
3.5
cache-remove command successful (parameters: %1)
168u
168u
دستور cache-remove با موفقیت انجام شد. پارامترهای میزبانِ حذف‌شده در گزارش ثبت می‌شوند.
HOST_CACHE_COMMAND_REMOVE_FAILED
0.0
3.5
cache-remove command failed (parameters: %1, reason: %2)
168u
168u
دستور cache-remove ناموفق بود. هم علت و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
HOST_CACHE_COMMAND_SIZE
0.0
3.5
cache-clear command successful: %1
168u
168u
دستور cache-size با موفقیت انجام شد و تعداد مدخل‌های موجود در حافظهٔ نهان میزبان (host cache) را بازگرداند.
HOST_CACHE_COMMAND_SIZE_FAILED
0.0
3.5
cache-size command failed (reason: %1)
168u
168u
دستور cache-size ناموفق بود. دلیل آن در گزارش ثبت می‌شود.
HOST_CACHE_COMMAND_WRITE
0.0
3.5
cache-write command successful (dumped: %1)
168u
168u
دستور cache-write با موفقیت انجام شد. تعداد مدخل‌های ذخیره‌شده (تخلیه‌شده) در گزارش ثبت می‌شود.
HOST_CACHE_COMMAND_WRITE_FAILED
0.0
3.5
cache-write command failed (parameters: %1, reason: %2)
168u
168u
دستور cache-write ناموفق بود. هم علت و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
HOST_CACHE_CONFIGURATION_FAILED
0.0
3.5
failed to configure Host Cache hooks library: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در پیکربندی کتابخانهٔ قلاب‌های Host Cache خطایی رخ دهد. آرگومان، پیام خطای دقیق را ارائه می‌دهد.
HOST_CACHE_DEINIT_OK
0.0
3.5
unloading Host Cache hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانهٔ قلاب‌های Host Cache با موفقیت از حافظه تخلیه شده است..SS HOST_CACHE_DEL_SUBNET_ID_ADDRESS4
0.0
3.5
using subnet id %1 and address %2, delete host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی، جزئیات مدخل کَش میزبانی را که با استفاده از شناسهٔ زیرشبکه (subnet id) و نشانی IPv4 حذف شده است، ثبت می‌کند.
HOST_CACHE_DEL_SUBNET_ID_ADDRESS6
0.0
3.5
using subnet id %1 and address %2, delete host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی، جزئیات مدخل کَش میزبانی را که با استفاده از شناسهٔ زیرشبکه (subnet id) و نشانی IPv6 حذف شده است، ثبت می‌کند.
HOST_CACHE_DEL_SUBNET_ID_IDENTIFIER4
0.0
3.5
using subnet id %1 and identifier %2, delete host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی، جزئیات مدخل کَش میزبانی را که با استفاده از شناسهٔ زیرشبکه و شناسهٔ میزبان مشخص حذف شده است، ثبت می‌کند.
HOST_CACHE_DEL_SUBNET_ID_IDENTIFIER6
0.0
3.5
using subnet id %1 and identifier %2, delete host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی، جزئیات مدخل کَش میزبانی را که با استفاده از شناسهٔ زیرشبکه و شناسهٔ میزبان مشخص حذف شده است، ثبت می‌کند.
HOST_CACHE_GET_ONE_PREFIX
0.0
3.5
get one host with reservation for prefix %1/%2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که بازیابی یک مدخل کَش میزبان دارای رزرو برای یک پیشوند مشخص آغاز گردد. آرگومان‌ها یک پیشوند و طول پیشوند را مشخص می‌کنند.
HOST_CACHE_GET_ONE_PREFIX_HOST
0.0
3.5
using prefix %1/%2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات مدخل کَش میزبان یافت‌شده با استفاده از پیشوند/طول پیشوند مشخص است. آرگومان‌ها به ترتیب پیشوند، طول پیشوند و جزئیات میزبان را مشخص می‌کنند.
HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS4
0.0
3.5
get one host with reservation for subnet id %1 and IPv4 address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که بازیابی یک مدخل کَش میزبان متصل به زیرشبکهٔ مشخص و دارای نشانی IPv4 رزروشدهٔ مشخص آغاز گردد. آرگومان‌ها به ترتیب شناسهٔ زیرشبکه و نشانی IPv4 را مشخص می‌کنند.
HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS4_HOST
0.0
3.5
using subnet id %1 and address %2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی، جزئیات مدخل کَش میزبانی را که با استفاده از شناسهٔ زیرشبکه و نشانی IPv4 یافت شده است، ثبت می‌کند.
HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS6
0.0
3.5
get one host with reservation for subnet id %1 and including IPv6 address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که بازیابی یک مدخل کَش میزبان متصل به زیرشبکهٔ مشخص و دارای نشانی IPv6 رزروشدهٔ مشخص آغاز گردد. آرگومان‌ها به ترتیب شناسهٔ زیرشبکه و نشانی IPv6 را مشخص می‌کنند..SS HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS6_HOST
0.0
3.5
using subnet id %1 and address %2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی، جزئیات مدخل حافظه موقت میزبان (host cache) را که با استفاده از subnet id و نشانی IPv6 پیدا شده است، در گزارش ثبت می‌کند.
HOST_CACHE_GET_ONE_SUBNET_ID_IDENTIFIER
0.0
3.5
get one host with %1 reservation for subnet id %2, identified by %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام آغاز بازیابی یک مدخل حافظه موقت میزبانِ دارای رزروهای IPv4 یا IPv6 صادر می‌شود که به یک زیرشبکه خاص متصل بوده و با یک شناسه یکتای مشخص شناسایی می‌شود. آرگومان نخست تعیین می‌کند که آیا رزرو IPv4 مد نظر است یا IPv6.
HOST_CACHE_GET_ONE_SUBNET_ID_IDENTIFIER_HOST
0.0
3.5
using subnet id %1 and identifier %2, found host: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی شامل جزئیات مدخل حافظه موقت میزبانی است که با استفاده از یک subnet id و شناسه خاص میزبان پیدا شده است.
HOST_CACHE_INIT_OK
0.0
3.5
loading Host Cache hooks library successful
168u
168u
این پیام اطلاعاتی (info) نشان می‌دهد که کتابخانه قلاب‌های (hooks) بخش Host Cache با موفقیت بارگذاری شده است. لذت ببرید!
HOST_CACHE_PATH_SECURITY_WARNING
0.0
3.5
Cache file path specified is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال تدابیر امنیتی غیرفعال بوده و مسیر مشخص‌شده برای فایل حافظه موقت میزبان با مسیر پشتیبانی‌شده مطابقت ندارد. کارگزار همچنان از مسیر مشخص‌شده استفاده خواهد کرد، اما هشدار می‌دهد که این کار ممکن است خطرات امنیتی ایجاد کند.
HOST_CMDS_DEINIT_OK
0.0
3.5
unloading Host Commands hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های Host Commands با موفقیت تخلیه (حذف) شده است.
HOST_CMDS_INIT_FAILED
0.0
3.5
loading Host Commands hooks library failed: %1
168u
168u
این پیام خطا بیانگر بروز خطا هنگام بارگذاری کتابخانه قلاب‌های Host Commands است. جزئیات خطا به عنوان آرگومان در پیام گزارش ارائه شده است.
HOST_CMDS_INIT_OK
0.0
3.5
loading Host Commands hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های Host Commands با موفقیت بارگذاری شده است. لذت ببرید!
HOST_CMDS_RESERV_ADD
0.0
3.5
reservation-add command called (parameters: %1)
168u
168u
دستور reservation-add فراخوانی شده است. پارامترهای ارسالی در گزارش ثبت می‌شوند.
HOST_CMDS_RESERV_ADD_FAILED
0.0
3.5
reservation-add command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-add با شکست مواجه شد. هم دلیل و هم پارامترهای ارسالی در گزارش ثبت می‌شوند..SS HOST_CMDS_RESERV_ADD_SUCCESS
0.0
3.5
reservation-add command success (parameters: %1)
168u
168u
دستور reservation-add با موفقیت انجام شد. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_DEL
0.0
3.5
reservation-del command called (parameters: %1)
168u
168u
دستور reservation-del فراخوانی شد. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_DEL_FAILED
0.0
3.5
reservation-del command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-del با شکست مواجه شد. هم دلیل و هم پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_DEL_SUCCESS
0.0
3.5
reservation-del command success (parameters: %1)
168u
168u
دستور reservation-del با موفقیت انجام شد. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET
0.0
3.5
reservation-get command called (parameters: %1)
168u
168u
دستور reservation-get فراخوانی شد. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_ALL
0.0
3.5
reservation-get-all command called (parameters: %1)
168u
168u
دستور reservation-get-all فراخوانی شد. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_ALL_FAILED
0.0
3.5
reservation-get-all command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-get-all با شکست مواجه شد. هم دلیل و هم پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_ALL_SUCCESS
0.0
3.5
reservation-get-all command success (parameters: %1)
168u
168u
دستور reservation-get-all با موفقیت انجام شد. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_ADDRESS
0.0
3.5
reservation-get-by-address command called (parameters: %1)
168u
168u
دستور reservation-get-by-address فراخوانی شد. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_ADDRESS_FAILED
0.0
3.5
reservation-get-by-address command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-get-by-address با شکست مواجه شد. هم دلیل و هم پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_ADDRESS_SUCCESS
0.0
3.5
reservation-get-by-address command success (parameters: %1)
168u
168u
دستور reservation-get-by-address با موفقیت انجام شد. پارامترهای ارسال‌شده ثبت می‌شوند..SS HOST_CMDS_RESERV_GET_BY_HOSTNAME
0.0
3.5
reservation-get-by-hostname command called (parameters: %1)
168u
168u
دستور reservation-get-by-hostname فراخوانی شده است. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_HOSTNAME_FAILED
0.0
3.5
reservation-get-by-hostname command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-get-by-hostname شکست خورده است. هم دلیل و هم
پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_HOSTNAME_SUCCESS
0.0
3.5
reservation-get-by-hostname command success (parameters: %1)
168u
168u
دستور reservation-get-by-hostname موفقیت‌آمیز بوده است. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_ID
0.0
3.5
reservation-get-by-id command called (parameters: %1)
168u
168u
دستور reservation-get-by-id فراخوانی شده است. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_ID_FAILED
0.0
3.5
reservation-get-by-id command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-get-by-id شکست خورده است. هم دلیل و هم
پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_BY_ID_SUCCESS
0.0
3.5
reservation-get-by-id command success (parameters: %1)
168u
168u
دستور reservation-get-by-id موفقیت‌آمیز بوده است. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_FAILED
0.0
3.5
reservation-get command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-add شکست خورده است. هم دلیل و هم
پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_PAGE
0.0
3.5
reservation-get-page command called (parameters: %1)
168u
168u
دستور reservation-get-page فراخوانی شده است. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_PAGE_FAILED
0.0
3.5
reservation-get-page command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-get-page شکست خورده است. هم دلیل و هم
پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_PAGE_SUCCESS
0.0
3.5
reservation-get-page command success (parameters: %1)
168u
168u
دستور reservation-get-page موفقیت‌آمیز بوده است. پارامترهای ارسال‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_GET_SUCCESS
0.0
3.5
reservation-get command success (parameters: %1)
168u
168u
دستور reservation-get موفقیت‌آمیز بوده است. پارامترهای ارسال‌شده ثبت می‌شوند..SS HOST_CMDS_RESERV_UPDATE
0.0
3.5
reservation-update command called (parameters: %1)
168u
168u
دستور reservation-update فراخوانی شده است. پارامترهای ارائه‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_UPDATE_FAILED
0.0
3.5
reservation-update command failed (parameters: %1, reason: %2)
168u
168u
دستور reservation-update با شکست مواجه شده است. هم دلیل و هم پارامترهای ارائه‌شده ثبت می‌شوند.
HOST_CMDS_RESERV_UPDATE_SUCCESS
0.0
3.5
reservation-update command success (parameters: %1)
168u
168u
دستور reservation-update موفقیت‌آمیز بوده است. پارامترهای ارائه‌شده ثبت می‌شوند.
HTTPS
HTTPS_REQUEST_RECEIVE_START
0.0
3.5
start receiving request from %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور شروع به دریافت درخواست جدیدی از طریق اتصال برقرارشده می‌کند. این آرگومان آدرس نقطه پایانی دوردست (remote endpoint) را مشخص می‌کند.
HTTP
HTTP_BAD_CLIENT_REQUEST_RECEIVED
0.0
3.5
bad request received from %1: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک کلاینت HTTP درخواستی بدریخت (malformed) به سرور ارسال کند. این شامل درخواست‌های HTTP با نوع محتوای (content type) غیرمنتظره، از جمله JSON بدریخت و غیره است. آرگومان نخست آدرس نقطه پایانی دوردست ارسال‌کننده درخواست را مشخص می‌کند. آرگومان دوم پیام خطای تفصیلی را ارائه می‌دهد.
HTTP_BAD_CLIENT_REQUEST_RECEIVED_DETAILS
0.0
3.5
detailed information about bad request received from %1:\n%2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک کلاینت HTTP درخواستی بدریخت به سرور ارسال کند. این پیام شامل اطلاعات تفصیلی درباره درخواست دریافتی ردشده توسط سرور است. آرگومان نخست آدرس نقطه پایانی دوردست ارسال‌کننده درخواست را مشخص می‌کند. آرگومان دوم درخواست را در قالب متنی ارائه می‌دهد. اگر درخواست برای چاپ شدن بیش از حد بزرگ باشد، توسط ثبت‌کننده وقایع (logger) کوتاه‌سازی می‌شود.
HTTP_BAD_SERVER_RESPONSE_RECEIVED
0.0
3.5
bad response received when communicating with %1: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک کلاینت HTTP در دریافت پاسخ از سرور ناکام بماند یا هنگامی که این پاسخ بدریخت باشد. آرگومان نخست URL سرور را مشخص می‌کند. آرگومان دوم پیام خطای تفصیلی را ارائه می‌دهد.
HTTP_BAD_SERVER_RESPONSE_RECEIVED_DETAILS
0.0
3.5
detailed information about bad response received from %1:\n%2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک کلاینت HTTP پاسخی بدریخت از سرور دریافت کند. آرگومان نخست URL سرور را مشخص می‌کند. آرگومان دوم پاسخ را در قالب متنی ارائه می‌دهد. اگر درخواست برای چاپ شدن بیش از حد بزرگ باشد، توسط ثبت‌کننده وقایع (logger) کوتاه‌سازی می‌شود.
HTTP_CLIENT_MT_STARTED
0.0
3.5
HttpClient has been started in multi-threaded mode running %1 threads
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک نمونه چندنخی (multi-threaded) از کلاینت HTTP ایجاد شده باشد. آرگومان حداکثر تعداد نخ‌ها را مشخص می‌کند..SS HTTP_CLIENT_PASSWORD_SECURITY_WARNING
0.0
3.5
use of clear text 'password' is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال امنیت غیرفعال باشد و پیکربندی سوکت فرمان به‌جای 'password-file' از متن آشکار 'password' استفاده کند. کارگزار همچنان از سوکت به همان صورت پیکربندی‌شده استفاده خواهد کرد، اما هشدار می‌دهد که این کار ممکن است خطرات امنیتی در پی داشته باشد.
HTTP_CLIENT_QUEUE_SIZE_GROWING
0.0
3.5
queue for URL: %1, now has %2 entries and may be growing too quickly
168u
168u
این پیام هشدار زمانی صادر می‌شود که به نظر می‌رسد صف درخواست‌های در انتظار برای URL داده‌شده سریع‌تر از توان پردازش درخواست‌ها رشد می‌کند. تا زمانی که اندازهٔ صف به رشد خود ادامه دهد، این پیام به‌صورت دوره‌ای صادر خواهد شد. این وضعیت ممکن است با هجوم ناگهانی ترافیک کلاینت‌ها رخ دهد که یک انباشتگی موقت ایجاد می‌کند و پس از فرونشستن ترافیک فروکش می‌کند. اگر این اتفاق به‌طور مداوم رخ دهد، به احتمال زیاد نشان‌دهندهٔ پیکربندی استقراری است که نمی‌تواند بار کاری کلاینت‌ها را تاب بیاورد.
HTTP_CLIENT_REQUEST_AUTHORIZED
0.0
3.5
received HTTP request authorized for '%1'
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کارگزار درخواستی با سرآیند احراز هویت منطبق دریافت کند. آرگومان، شناسهٔ کاربر (user id) را ارائه می‌دهد.
HTTP_CLIENT_REQUEST_BAD_AUTH_HEADER
0.0
3.5
received HTTP request with malformed authentication header: %1
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کارگزار درخواستی با یک سرآیند احراز هویت بدریخت (malformed) دریافت کند. آرگومان مشکل را توضیح می‌دهد.
HTTP_CLIENT_REQUEST_NOT_AUTHORIZED
0.0
3.5
received HTTP request with not matching authentication header
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کارگزار درخواستی با سرآیند احراز هویت حاوی گواهی‌نامهٔ ناشناخته دریافت کند: کاربر شناسهٔ کاربری و/یا گذرواژهٔ نادرستی ارائه کرده است.
HTTP_CLIENT_REQUEST_NO_AUTH_HEADER
0.0
3.5
received HTTP request without required authentication header
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کارگزار درخواستی فاقد سرآیند احراز هویت الزامی دریافت کند.
HTTP_CLIENT_REQUEST_RECEIVED
0.0
3.5
received HTTP request from %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که دریافت درخواست HTTP از نقطهٔ پایانی راه دور (remote endpoint) توسط کارگزار به پایان رسیده باشد. نشانی نقطهٔ پایانی راه دور به عنوان یک آرگومان مشخص شده است.
HTTP_CLIENT_REQUEST_RECEIVED_DETAILS
0.0
3.5
detailed information about well-formed request received from %1:\n%2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 45 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار HTTP درخواستی خوش‌قالب (well-formed) دریافت کند. این پیام شامل اطلاعات تفصیلی دربارهٔ درخواست دریافتی است. آرگومان اول، نشانی نقطهٔ پایانی راه دور را که درخواست را ارسال کرده است مشخص می‌کند. آرگومان دوم، درخواست را در قالب متنی ارائه می‌دهد. اگر درخواست برای چاپ‌شدن بیش از حد بزرگ باشد، توسط ثبت‌کنندهٔ لاگ بریده (truncated) می‌شود.
HTTP_CLIENT_REQUEST_SEND
0.0
3.5
sending HTTP request %1 to %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کلاینت شروع به ارسال یک درخواست HTTP به کارگزار می‌کند. آرگومان اول، اطلاعات پایه دربارهٔ درخواست (شماره نسخهٔ HTTP و کد وضعیت) را نگه می‌دارد. آرگومان دوم URL کارگزار را مشخص می‌کند..SS HTTP_CLIENT_REQUEST_SEND_DETAILS
0.0
3.5
detailed information about request sent to %1:\n%2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی درست پیش از ارسال یک درخواست HTTP توسط کلاینت به
سرور صادر می‌شود. این پیام شامل اطلاعات دقیقی دربارهٔ درخواست است. آرگومان
نخست، URL سروری را که درخواست به آن ارسال می‌شود مشخص می‌کند. آرگومان دوم
درخواست را به شکل متنی ارائه می‌دهد. اگر اندازهٔ درخواست برای چاپ شدن بیش از
حد بزرگ باشد، توسط ثبت‌کنندهٔ گزارش کوتاه (truncate) می‌شود.
HTTP_CLIENT_REQUEST_TIMEOUT_OCCURRED
0.0
3.5
HTTP request timeout occurred when communicating with %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که مهلت زمانی درخواست HTTP به پایان
رسیده باشد و سرور قصد داشته باشد پاسخی حاوی کد وضعیت اتمام مهلت زمانی
درخواست (Http Request timeout) ارسال کند.
HTTP_CLIENT_USER_SECURITY_WARNING
0.0
3.5
use of clear text 'user' is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که الزامات امنیتی غیرفعال شده باشند
و در پیکربندی سوکت فرمان به‌جای 'user-file' از متن آشکار 'user'
استفاده شده باشد. سرور همچنان طبق پیکربندی از سوکت استفاده خواهد کرد،
اما هشدار می‌دهد که انجام این کار ممکن است خطرات امنیتی در پی داشته باشد.
HTTP_COMMAND_MGR_HTTPS_SERVICE_REUSE_FAILED
0.0
3.5
failed to reused HTTPS service bound to address: %1 port: %2
168u
168u
این پیام خطا بیانگر آن است که سرور نتوانسته از سرویس HTTPS موجود روی آدرس
و درگاه (port) مشخص‌شده دوباره استفاده کند. سرور نمی‌تواند با استفاده از همان
آدرس و درگاه، از سوکت‌های HTTPS به HTTP تغییر وضعیت دهد.
HTTP_COMMAND_MGR_HTTPS_SERVICE_UPDATED
0.0
3.5
reused HTTPS service bound to address: %1 port: %2 and updated TLS settings
168u
168u
این پیام اطلاعاتی نشان می‌دهد که سرور از سرویس HTTPS موجود روی آدرس
و درگاه مشخص‌شده مجدداً استفاده کرده است. توجه داشته باشید که هرگونه تغییر در
پیکربندی TLS اعمال شده است.
HTTP_COMMAND_MGR_HTTP_SERVICE_REUSE_FAILED
0.0
3.5
failed to reused HTTP service bound to address: %1 port: %2
168u
168u
این پیام خطا بیانگر آن است که سرور نتوانسته از سرویس HTTP موجود روی آدرس
و درگاه مشخص‌شده دوباره استفاده کند. سرور نمی‌تواند با استفاده از همان آدرس و
درگاه، از سوکت‌های HTTP به HTTPS تغییر وضعیت دهد.
HTTP_COMMAND_MGR_HTTP_SERVICE_UPDATED
0.0
3.5
reused HTTP service bound to address: %1 port: %2
168u
168u
این پیام اطلاعاتی نشان می‌دهد که سرور از سرویس HTTP موجود روی آدرس
و درگاه مشخص‌شده مجدداً استفاده کرده است.
HTTP_COMMAND_MGR_SERVICE_STARTED
0.0
3.5
started %1 service bound to address: %2 port: %3
168u
168u
این پیام اطلاعاتی نشان می‌دهد که سرور سرویس HTTP/HTTPS را روی آدرس
و درگاه مشخص‌شده برای دریافت دستورات کنترلی راه‌اندازی کرده است.
HTTP_COMMAND_MGR_SERVICE_STOPPING
0.0
3.5
Server is stopping %1 service %2
168u
168u
این پیام اطلاعاتی بیانگر آن است که سرور سرویس HTTP/HTTPS را متوقف کرده است.
در صورت مشخص بودن، آدرس و درگاه نمایش داده می‌شوند..SS HTTP_CONNECTION_CLOSE_CALLBACK_FAILED
0.0
3.5
Connection close callback threw an exception
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که فراخوان بازگشتی (callback) بستن اتصال که روی اتصال ثبت شده است، به‌طور غیرمنتظره‌ای با شکست مواجه شود. این یک خطای برنامه‌نویسی است و باید به عنوان یک باگ گزارش شود.
HTTP_CONNECTION_HANDSHAKE_FAILED
0.0
3.5
TLS handshake with %1 failed with %2
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که دست‌تکانی TLS در سمت سرور با شکست مواجه شود. آدرس کلاینت و پیام خطا نمایش داده می‌شوند.
HTTP_CONNECTION_HANDSHAKE_START
0.0
3.5
start TLS handshake with %1 with timeout %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور دست‌تکانی TLS را با نقطه پایانی دوردست (remote endpoint) آغاز می‌کند. آرگومان نخست، آدرس نقطه پایانی دوردست را مشخص می‌کند. آرگومان دوم، مهلت زمانی (timeout) درخواست را بر حسب ثانیه تعیین می‌کند.
HTTP_CONNECTION_SHUTDOWN
0.0
3.5
shutting down HTTP connection from %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یکی از اتصالات HTTP خاموش (shut down) شود. اتصال ممکن است در نتیجه یک خطا یا پس از تبادل موفقیت‌آمیز پیام با یک کلاینت متوقف شود.
HTTP_CONNECTION_SHUTDOWN_FAILED
0.0
3.5
shutting down HTTP connection failed
168u
168u
این پیام خطا زمانی صادر می‌شود که در حین خاموش‌سازی (shutting down) یک اتصال HTTP با یک کلاینت، خطایی رخ داده باشد.
HTTP_CONNECTION_STOP
0.0
3.5
stopping HTTP connection from %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یکی از اتصالات HTTP متوقف شود. اتصال ممکن است در نتیجه یک خطا یا پس از تبادل موفقیت‌آمیز پیام با یک کلاینت متوقف شود.
HTTP_CONNECTION_STOP_FAILED
0.0
3.5
stopping HTTP connection failed
168u
168u
این پیام خطا زمانی صادر می‌شود که در حین بستن یک اتصال HTTP با یک کلاینت، خطایی رخ داده باشد.
HTTP_CONNECTION_WATCH_SOCKET_CLEAR_ERROR
0.0
3.5
clearing connection watch socket failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در حین پاک‌سازی سوکت پایش (watch socket) مرتبط با یک اتصال HTTP با یک کلاینت، خطایی رخ دهد. خطا نمایش داده می‌شود.
HTTP_CONNECTION_WATCH_SOCKET_CLOSE_ERROR
0.0
3.5
closing connection watch socket failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در حین بستن سوکت پایش (watch socket) مرتبط با یک اتصال HTTP با یک کلاینت، خطایی رخ دهد. خطا نمایش داده می‌شود.
HTTP_CONNECTION_WATCH_SOCKET_MARK_READY_ERROR
0.0
3.5
marking ready connection watch socket failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در حین علامت‌گذاری سوکت پایش (watch socket) مرتبط با یک اتصال HTTP با یک کلاینت به عنوان آماده (ready)، خطایی رخ دهد. خطا نمایش داده می‌شود..SS HTTP_DATA_RECEIVED
0.0
3.5
received %1 bytes from %2
168u
168u
در سطح گزارش اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار تکه‌ای از داده را از
نقطه پایانی راه دور (remote endpoint) دریافت کند. این داده ممکن است شامل کل درخواست یا تنها بخشی
از آن باشد. آرگومان نخست، میزان داده دریافتی را مشخص می‌کند.
آرگومان دوم، آدرس نقطه پایانی راه دور تولیدکننده داده را تعیین می‌کند.
HTTP_IDLE_CONNECTION_TIMEOUT_OCCURRED
0.0
3.5
closing persistent connection with %1 as a result of a timeout
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که اتصال پایدار (persistent) در HTTP به علت
بیکار ماندن بسته شود.
HTTP_PREMATURE_CONNECTION_TIMEOUT_OCCURRED
0.0
3.5
premature connection timeout occurred: in transaction ? %1, transid: %2, current_transid: %3
168u
168u
این پیام هشدار زمانی صادر می‌شود که وقفه زمانی (timeout) غیرمنتظره‌ای در حین
تراکنش رخ دهد. اثبات شده است که این مورد هنگام تغییر دستی ساعت سیستم
یا در نتیجه همگام‌سازی با یک کارگزار زمان (time server) رخ می‌دهد. هرگونه تراکنش
در حال اجرا متوقف خواهد شد. تراکنش‌های جدید باید به شکل عادی انجام شوند.
HTTP_REQUEST_RECEIVE_START
0.0
3.5
start receiving request from %1 with timeout %2
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار دریافت درخواست جدیدی را
روی اتصال برقرارشده آغاز کند. آرگومان نخست، آدرس
نقطه پایانی راه دور را مشخص می‌کند. آرگومان دوم، مهلت زمانی درخواست را
بر حسب ثانیه تعیین می‌کند.
HTTP_SERVER_RESPONSE_RECEIVED
0.0
3.5
received HTTP response from %1
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کلاینت دریافت پاسخ HTTP
از کارگزار را به پایان رسانده باشد. URL کارگزار به عنوان آرگومان مشخص شده است.
HTTP_SERVER_RESPONSE_RECEIVED_DETAILS
0.0
3.5
detailed information about well-formed response received from %1:\n%2
168u
168u
در سطح گزارش اشکال‌زدایی 45 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کلاینت HTTP یک پاسخ با ساختار صحیح (well-formed)
از کارگزار دریافت کند. این پیام شامل اطلاعات تفصیلی درباره پاسخ
دریافت‌شده است. آرگومان نخست، URL کارگزاری که پاسخ را ارسال کرده مشخص می‌کند.
آرگومان دوم، پاسخ را در قالب متنی فراهم می‌آورد.
در صورتی که پاسخ برای چاپ بیش از حد بزرگ باشد، توسط سیستم ثبت گزارش (logger) کوتاه می‌شود.
HTTP_SERVER_RESPONSE_SEND
0.0
3.5
sending HTTP response %1 to %2
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار شروع به ارسال پاسخ HTTP
به یک نقطه پایانی راه دور کند. آرگومان نخست شامل اطلاعات پایه
درباره پاسخ است (شماره نسخه HTTP و کد وضعیت). آرگومان
دوم، آدرس نقطه پایانی راه دور را مشخص می‌کند.
HTTP_SERVER_RESPONSE_SEND_DETAILS
0.0
3.5
detailed information about response sent to %1:\n%2
168u
168u
در سطح گزارش اشکال‌زدایی 45 ثبت می‌شود.
این پیام اشکال‌زدایی درست پیش از آنکه کارگزار پاسخ HTTP را به کلاینت
ارسال کند صادر می‌شود. این پیام شامل اطلاعات تفصیلی درباره پاسخ است.
آرگومان نخست، آدرس نقطه پایانی راه دور را که پاسخ به آن
ارسال می‌شود مشخص می‌کند. آرگومان دوم، پاسخ را در قالب متنی فراهم می‌آورد.
اگر پاسخ برای چاپ بیش از حد بزرگ باشد، توسط ثبت‌کننده وقایع کوتاه می‌شود..SS KEY
KEY_LOOKUP_DISABLED
0.0
3.5
hooks library lookup for a key: GSS-TSIG is not enabled for the current DNS server.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که جستجو برای یک کلید GSS-TSIG برای
یک سرور DNS که GSS-TSIG روی آن فعال نیست، انجام شده باشد.
KEY_LOOKUP_FOUND
0.0
3.5
hooks library lookup for a key: return GSS-TSIG key '%1'.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که جستجو برای کلید GSS-TSIG،
کلید قابل استفاده‌ای را برای محافظت از به‌روزرسانی DNS بازگردانده باشد. نام کلید نمایش داده می‌شود.
KEY_LOOKUP_NONE
0.0
3.5
hooks library lookup for a key: found no usable key.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که جستجو برای کلید GSS-TSIG در یافتن
یک کلید قابل استفاده ناموفق باشد.
KEY_PROCESSING_FAILED
0.0
3.5
The GSS-TKEY processing for server %1 failed because of an error: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که پردازش کلید برای یک سرور خاص با شکست
مواجه شده باشد. آرگومان نخست شناسه سرور را مشخص کرده و آرگومان دوم
اطلاعات بیشتری درباره خطا ارائه می‌دهد.
KEY_PROCESSING_FAILED_UNSPECIFIED_ERROR
0.0
3.5
The GSS-TKEY processing for server %1 failed because of an unspecified error
168u
168u
این پیام خطا زمانی صادر می‌شود که پردازش کلید برای یک سرور خاص با شکست
مواجه شده باشد. آرگومان نخست شناسه سرور را مشخص می‌کند.
LEASE
LEASE_CMDS_ADD4
0.0
3.5
lease4-add command successful (address: %1)
168u
168u
در سطح گزارش اشکال‌زدایی ۲۰ ثبت می‌شود.
دستور lease4-add موفقیت‌آمیز بوده است. نشانی IPv4 اجاره
ثبت می‌شود.
LEASE_CMDS_ADD4_CONFLICT
0.0
3.5
lease4-add command failed due to conflict (parameters: %1, reason: %2)
168u
168u
دستور دریافتی lease4-add خوش‌ساخت بوده و حاوی پارامترهای معتبری است، اما
اجاره ایجاد نشد زیرا با وضعیت سرور یا پیکربندی در تداخل است.
علت تداخل در پیام ثبت می‌شود.
LEASE_CMDS_ADD4_FAILED
0.0
3.5
lease4-add command failed (parameters: %1, reason: %2)
168u
168u
دستور lease4-add با شکست مواجه شده است. هم دلیل و هم
پارامترهای ارائه‌شده ثبت می‌شوند.
LEASE_CMDS_ADD6
0.0
3.5
lease6-add command successful (address: %1)
168u
168u
در سطح گزارش اشکال‌زدایی ۲۰ ثبت می‌شود.
دستور lease6-add موفقیت‌آمیز بوده است. نشانی IPv6 اجاره
ثبت می‌شود.
LEASE_CMDS_ADD6_CONFLICT
0.0
3.5
lease6-add command failed due to conflict (parameters: %1, reason: %2)
168u
168u
دستور دریافتی lease6-add خوش‌ساخت بوده و حاوی پارامترهای معتبری است، اما
اجاره ایجاد نشد زیرا با وضعیت سرور یا پیکربندی در تداخل است.
علت تداخل در پیام ثبت می‌شود..SS LEASE_CMDS_ADD6_FAILED
0.0
3.5
lease6-add command failed (parameters: %1, reason: %2)
168u
168u
دستور lease6-add با شکست مواجه شده است. هم علت و هم
پارامترهای ارسالی در گزارش ثبت می‌شوند.
LEASE_CMDS_BULK_APPLY6
0.0
3.5
lease6-bulk-apply command successful (applied addresses count: %1)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور lease6-bulk-apply موفقیت‌آمیز بوده است. تعداد نشانی‌های
اعمال‌شده در گزارش ثبت می‌شود.
LEASE_CMDS_BULK_APPLY6_FAILED
0.0
3.5
lease6-bulk-apply command failed (parameters: %1, reason: %2)
168u
168u
دستور lease6-bulk-apply با شکست مواجه شده است. هم علت
و هم پارامترهای ارسالی در گزارش ثبت می‌شوند.
LEASE_CMDS_DEINIT_OK
0.0
3.5
unloading Lease Commands hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های (hooks library)
مربوط به Lease Commands با موفقیت خارج (تخلیه) شده است.
LEASE_CMDS_DEL4
0.0
3.5
lease4-del command successful (address: %1)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
تلاش برای حذف یک اجاره IPv4 (دستور lease4-del) موفقیت‌آمیز بوده است.
نشانی IPv4 اجاره در گزارش ثبت می‌شود.
LEASE_CMDS_DEL4_FAILED
0.0
3.5
lease4-del command failed (parameters: %1, reason: %2)
168u
168u
تلاش برای حذف یک اجاره IPv4 (دستور lease4-del) با شکست مواجه شده است. هم علت
و هم پارامترهای ارسالی در گزارش ثبت می‌شوند.
LEASE_CMDS_DEL6
0.0
3.5
lease4-del command successful (address: %1)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
تلاش برای حذف یک اجاره IPv4 (دستور lease4-del) موفقیت‌آمیز بوده است.
نشانی IPv6 اجاره در گزارش ثبت می‌شود.
LEASE_CMDS_DEL6_FAILED
0.0
3.5
lease6-del command failed (parameters: %1, reason: %2)
168u
168u
تلاش برای حذف یک اجاره IPv6 (دستور lease4-del) با شکست مواجه شده است. هم علت
و هم پارامترهای ارسالی در گزارش ثبت می‌شوند.
LEASE_CMDS_GET4_FAILED
0.0
3.5
lease4-get command failed (parameters: %1, reason: %2)
168u
168u
دستور lease4-get با شکست مواجه شده است. هم علت و هم
پارامترهای ارسالی در گزارش ثبت می‌شوند.
LEASE_CMDS_GET6_FAILED
0.0
3.5
lease6-get command failed (parameters: %1, reason: %2)
168u
168u
دستور lease4-get با شکست مواجه شده است. هم علت و هم
پارامترهای ارسالی در گزارش ثبت می‌شوند..SS LEASE_CMDS_INIT_OK
0.0
3.5
loading Lease Commands hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های (hooks library) مربوط به Lease Commands با موفقیت بارگذاری شده است. لذت ببرید!
LEASE_CMDS_LEASE4_OFFER_FAILED
0.0
3.5
processing error occurred evaluating binding variables: %1
168u
168u
این گزارش خطا زمانی صادر می‌شود که هنگام فراخوانی گرداننده lease4_offer خطایی رخ دهد. آرگومان توضیحی درباره علت خطا ارائه می‌دهد.
LEASE_CMDS_LEASES4_COMMITTED_FAILED
0.0
3.5
processing error occurred evaluating binding variables: %1
168u
168u
این گزارش خطا زمانی صادر می‌شود که هنگام فراخوانی گرداننده leases4_committed خطایی رخ دهد. آرگومان توضیحی درباره علت خطا ارائه می‌دهد.
LEASE_CMDS_LEASES6_COMMITTED_CONFLICT
0.0
3.5
could not updating lease: %1 for: %2
168u
168u
این گزارش خطا توسط فراخوان (callback) leases6_committed زمانی صادر می‌شود که تلاشی برای به‌روزرسانی یک اجاره با مقادیر جدید binding-variable صورت می‌گیرد، اما تغییری متناقض رخ داده که این به‌روزرسانی را نامعتبر می‌سازد. آرگومان‌ها نشانی اجاره و جزئیات پرسمان را ارائه می‌دهند.
LEASE_CMDS_LEASES6_COMMITTED_FAILED
0.0
3.5
reason: %1
168u
168u
این گزارش خطا زمانی صادر می‌شود که به‌روزرسانی یک یا چند اجارهٔ مرتبط با پرسمان کلاینت با مقادیر binding-variable با شکست مواجه شده باشد. آرگومان جزئیات را ارائه می‌دهد. خطاهای منفرد مربوط به هر اجاره باید پیش از این گزارش ثبت شده باشند.
LEASE_CMDS_LEASES6_COMMITTED_LEASE_ERROR
0.0
3.5
evaluating binding-variables for lease: %1 for: %2, reason: %3
168u
168u
این گزارش خطا توسط فراخوان leases6_committed زمانی صادر می‌شود که خطایی غیرمنتظره در ارزیابی binding-variableها برای یک اجاره مشخص رخ دهد. آرگومان‌ها نشانی اجاره، جزئیات پرسمان و توضیحی درباره خطا را ارائه می‌دهند.
LEASE_CMDS_LOAD_ERROR
0.0
3.5
loading Lease Commands hooks library failed: %1
168u
168u
این پیام خطا نشان‌دهنده بروز خطا در بارگذاری کتابخانه قلاب‌های Lease Commands است. جزئیات خطا به عنوان آرگومان پیام گزارش ارائه شده است.
LEASE_CMDS_PATH_SECURITY_WARNING
0.0
3.5
lease file path specified is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال تدابیر امنیتی غیرفعال باشد و بخش مسیر در پارامتر filename از دستور lease4-write یا lease6-write با مسیرهای پشتیبانی‌شده مطابقت نداشته باشد. کارساز همچنان از مسیر تعیین‌شده استفاده خواهد کرد، اما هشدار می‌دهد که این کار ممکن است خطرات امنیتی به همراه داشته باشد.
LEASE_CMDS_RESEND_DDNS4
0.0
3.5
lease4-resend-ddns command successful: %1
168u
168u
درخواست به‌روزرسانی DNS برای اجاره IPv4 مورد نظر با موفقیت در صف ارسال به kea-dhcp-ddns قرار گرفت.
LEASE_CMDS_RESEND_DDNS4_FAILED
0.0
3.5
lease4-resend-ddns command failed: %1
168u
168u
درخواست به‌روزرسانی DNS برای اجاره IPv4 مورد نظر با شکست مواجه شد. علت این شکست در گزارش ثبت می‌شود..SS LEASE_CMDS_RESEND_DDNS6
0.0
3.5
lease6-resend-ddns command successful: %1
168u
168u
درخواستی برای به‌روزرسانی DNS جهت اجاره درخواستی IPv6 با موفقیت برای ارسال به kea-dhcp-ddns در صف قرار گرفت.
LEASE_CMDS_RESEND_DDNS6_FAILED
0.0
3.5
lease6-resend-ddns command failed: %1
168u
168u
درخواستی برای به‌روزرسانی DNS جهت اجاره درخواستی IPv6 با شکست مواجه شد. دلیل شکست ثبت شده است.
LEASE_CMDS_UPDATE4
0.0
3.5
lease4-update command successful (address: %1)
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور lease4-update موفقیت‌آمیز بوده است. آدرس IPv4 اجاره ثبت می‌شود.
LEASE_CMDS_UPDATE4_CONFLICT
0.0
3.5
lease4-update command failed due to conflict (parameters: %1, reason: %2)
168u
168u
دستور دریافتی lease4-update ساختار درستی دارد و حاوی پارامترهای معتبری است، اما اجاره نتوانست ایجاد شود زیرا با وضعیت یا پیکربندی کارساز در تعارض است. علت تعارض در پیام ثبت می‌شود.
LEASE_CMDS_UPDATE4_FAILED
0.0
3.5
lease4-update command failed (parameters: %1, reason: %2)
168u
168u
دستور lease4-update با شکست مواجه شد. هم دلیل شکست و هم پارامترهای ارسال‌شده ثبت می‌شوند.
LEASE_CMDS_UPDATE6
0.0
3.5
lease6-update command successful (address: %1)
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور lease6-update موفقیت‌آمیز بوده است. آدرس IPv6 اجاره ثبت می‌شود.
LEASE_CMDS_UPDATE6_CONFLICT
0.0
3.5
lease6-update command failed due to conflict (parameters: %1, reason: %2)
168u
168u
دستور دریافتی lease6-update ساختار درستی دارد و حاوی پارامترهای معتبری است، اما اجاره نتوانست ایجاد شود زیرا با وضعیت یا پیکربندی کارساز در تعارض است. علت تعارض در پیام ثبت می‌شود.
LEASE_CMDS_UPDATE6_FAILED
0.0
3.5
lease6-add command failed (parameters: %1, reason: %2)
168u
168u
دستور lease6-update با شکست مواجه شد. هم دلیل شکست و هم پارامترهای ارسال‌شده ثبت می‌شوند.
LEASE_CMDS_WIPE4
0.0
3.5
lease4-wipe command successful (parameters: %1)
168u
168u
دستور lease4-wipe موفقیت‌آمیز بوده است. پارامترهای این دستور ثبت می‌شوند.
LEASE_CMDS_WIPE4_FAILED
0.0
3.5
lease4-wipe command failed (parameters: %1, reason: %2)
168u
168u
دستور lease4-wipe با شکست مواجه شد. هم دلیل شکست و هم پارامترهای ارسال‌شده ثبت می‌شوند..SS LEASE_CMDS_WIPE6
0.0
3.5
lease6-wipe command successful (parameters: %1)
168u
168u
دستور lease6-wipe با موفقیت انجام شد. پارامترهای این دستور ثبت شده‌اند.
LEASE_CMDS_WIPE6_FAILED
0.0
3.5
lease6-wipe command failed (parameters: %1, reason: %2)
168u
168u
دستور lease6-wipe با شکست مواجه شد. هم دلیل شکست و هم پارامترهای ارسال‌شده ثبت شده‌اند.
LEASE_QUERY_LOAD_FAILED
0.0
3.5
Lease Query hooks library failed to load: %1
168u
168u
این پیام خطا نشان می‌دهد که هنگام بارگذاری کتابخانه قلاب‌های Lease Query خطایی رخ داده است. آرگومان، جزئیات خطا را شرح می‌دهد.
LEASE_QUERY_LOAD_OK
0.0
3.5
Lease Query hooks library loaded successfully.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های Lease Query با موفقیت بارگذاری شده است.
LEASE_QUERY_UNLOAD_OK
0.0
3.5
Lease Query hooks library unloaded successfully.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های Lease Query با موفقیت تخلیه شده است.
LEGAL
LEGAL_LOG_COMMAND_NO_LEGAL_STORE
0.0
3.5
LegalStore instance is null
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانه Legal Log برای نوشتن یک مدخل دستور کنترلی در مخزن قانونی (legal store) تلاش کرده و نمونهٔ مخزن ایجاد نشده است. این یک خطای برنامه‌نویسی است و نباید رخ دهد.
LEGAL_LOG_COMMAND_WRITE_ERROR
0.0
3.5
Could not write command entry to the legal store: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانه Legal Log برای نوشتن یک مدخل دستور کنترلی در مخزن قانونی (legal store) تلاش کرده و نوشتن با شکست مواجه شده است. محتوای پیام باید توضیحی دقیق دربارهٔ خطا ارائه دهد.
LEGAL_LOG_DB_OPEN_CONNECTION_WITH_RETRY_FAILED
0.0
3.5
Failed to connect to database: %1 with error: %2
168u
168u
این یک پیام اطلاع‌رسانی است و زمانی صادر می‌شود که کارساز در برقراری اتصال به پایگاه‌دادهٔ مخزن ناموفق بوده است. عملیات، رویهٔ تلاش مجدد برای اتصال را آغاز کرده است. رشتهٔ دسترسی به پایگاه‌داده با گذرواژهٔ پوشانده‌شده، همراه با خطا و جزئیات رویهٔ اتصال مجدد ثبت می‌شود.
LEGAL_LOG_LEASE4_NO_LEGAL_STORE
0.0
3.5
LegalStore instance is null
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانه Legal Log برای نوشتن یک مدخل اجارهٔ IPv4 در مخزن قانونی (legal store) تلاش کرده و نمونهٔ مخزن ایجاد نشده است. این یک خطای برنامه‌نویسی است و نباید رخ دهد.
LEGAL_LOG_LEASE4_WRITE_ERROR
0.0
3.5
Could not write to the legal store: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانه Legal Log برای نوشتن یک مدخل اجارهٔ IPv4 در مخزن قانونی (legal store) تلاش کرده و عملیات نوشتن ناموفق بوده است. محتوای پیام باید شامل نام مخزن فیزیکی و ماهیت خطا باشد..SS LEGAL_LOG_LEASE6_NO_LEGAL_STORE
0.0
3.5
LegalStore instance is null
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانهٔ Legal Log تلاش کرده یک مدخل واگذاری IPv6 را در مخزن قانونی بنویسد، اما نمونهٔ مخزن ایجاد نشده است. این یک خطای برنامه‌نویسی است و نباید رخ دهد.
LEGAL_LOG_LEASE6_WRITE_ERROR
0.0
3.5
Could not write to the legal store: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانهٔ Legal Log برای نوشتن یک مدخل واگذاری IPv6 در مخزن قانونی تلاش کرده اما عملیات نوشتن با شکست مواجه شده است. محتوای پیام باید شامل نام فیزیکی مخزن و ماهیت خطا باشد.
LEGAL_LOG_LOAD_ERROR
0.0
3.5
LEGAL LOGGING DISABLED! An error occurred loading the library: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانهٔ DHCP Legal Log بارگذاری نشود. علت دقیق باید در پیام گزارش توضیح داده شود. هیچ‌یک از مخازن موجود تغییر نخواهند کرد و هیچ مدخل ثبت گزارش قانونی صادر نخواهد شد.
LEGAL_LOG_MYSQL_COMMIT
0.0
3.5
committing to MySQL database
168u
168u
کد یک فراخوانی commit صادر کرده است. تمام تراکنش‌های معلق در پایگاه داده ثبت (commit) خواهند شد. توجه داشته باشید که بسته به تنظیمات MySQL، این تثبیت ممکن است شامل نوشتن مستقیم روی دیسک نباشد.
LEGAL_LOG_MYSQL_DB_RECONNECT_ATTEMPT_FAILED
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
LEGAL_LOG_MYSQL_DB_RECONNECT_ATTEMPT_SCHEDULE
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
یک پیام اطلاعاتی که هنگام زمان‌بندی تلاش بعدی سرور برای اتصال مجدد به پایگاه داده صادر می‌شود. این حالت زمانی رخ می‌دهد که سرور اتصال خود را به پایگاه داده از دست داده و در حال تلاش برای برقراری مجدد اتصال به‌صورت خودکار است.
LEGAL_LOG_MYSQL_DB_RECONNECT_FAILED
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطایی که هنگام شکست سرور در برقراری مجدد اتصال صادر می‌شود. قطع ارتباط معمولاً به دلیل مشکلی در شبکه یا سرور پایگاه داده است.
LEGAL_LOG_MYSQL_FATAL_ERROR
0.0
3.5
Unrecoverable MySQL error occurred: %1 for <%2>, reason: %3 (error code: %4).
168u
168u
پیام خطایی که نشان می‌دهد ارتباط با سرور پایگاه داده MySQL قطع شده است. هنگامی که این اتفاق رخ می‌دهد، سرور فوراً با یک کد خروج غیرصفر (non-zero) خارج می‌شود. این مشکل به احتمال زیاد ناشی از مشکلی در شبکه است.
LEGAL_LOG_MYSQL_GET_VERSION
0.0
3.5
obtaining schema version information
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در شرف دریافت اطلاعات نسخهٔ شمای پایگاه داده MySQL است.
LEGAL_LOG_MYSQL_INSERT_LOG
0.0
3.5
Adding a log entry to the database: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
یک پیام اطلاع‌رسانی که هنگام درج یک مدخل گزارش ثبت می‌گردد..SS LEGAL_LOG_MYSQL_INVALID_ACCESS
0.0
3.5
invalid database access string: %1
168u
168u
این پیام زمانی ثبت می‌شود که تلاشی برای تجزیه یک رشته دسترسی به پایگاه داده انجام شده و با خطا مواجه شده باشد. رشته دسترسی مورد نظر - که باید به صورت 'keyword=value keyword=value...' باشد - در پیام گنجانده شده است.
LEGAL_LOG_MYSQL_NO_TLS
0.0
3.5
TLS was required but is not used
168u
168u
این پیام خطا هنگامی صادر می‌شود که TLS برای اتصال الزامی بوده اما TLS استفاده نشده است.
LEGAL_LOG_MYSQL_ROLLBACK
0.0
3.5
rolling back MySQL database
168u
168u
کد یک فراخوانی rollback صادر کرده است. تمام تراکنش‌های معلق بازگردانی خواهند شد و در پایگاه داده اعمال (commit) نمی‌شوند.
LEGAL_LOG_MYSQL_START_TRANSACTION
0.0
3.5
starting new MySQL transaction
168u
168u
این پیام اشکال‌زدایی (debug) زمانی صادر می‌شود که یک تراکنش MySQL جدید در حال شروع باشد. این پیام معمولاً هنگام درج داده در یک جدول منفرد صادر نمی‌شود، زیرا سرور در این حالت تراکنش‌ها را به صورت صریح آغاز نمی‌کند. این پیام زمانی صادر می‌شود که داده‌ها با چندین دستور INSERT در چندین جدول درج شوند و در صورت بروز خطا در هر یک از این دستورهای INSERT، نیاز به بازگردانی (rollback) کل تراکنش وجود داشته باشد.
LEGAL_LOG_MYSQL_TLS_CIPHER
0.0
3.5
TLS cipher: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک اتصال MySQL جدید به همراه TLS ایجاد گردد. نام سایفر (cipher) پروتکل TLS ثبت می‌شود.
LEGAL_LOG_PATH_SECURITY_WARNING
0.0
3.5
Forensic log path specified is NOT SECURE: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که اعمال تدابیر امنیتی غیرفعال شده باشد و مسیر مشخص‌شده برای خروجی لاگ‌های قانونی (forensic logging) با مسیر پشتیبانی‌شده مطابقت نداشته باشد. سرور همچنان از مسیر تعیین‌شده استفاده خواهد کرد، اما هشدار می‌دهد که انجام این کار ممکن است خطرات امنیتی به همراه داشته باشد.
LEGAL_LOG_PGSQL_COMMIT
0.0
3.5
committing to PostgreSQL database
168u
168u
کد یک فراخوانی commit صادر کرده است. تمام تراکنش‌های معلق در پایگاه داده اعمال (commit) خواهند شد. توجه داشته باشید که بسته به تنظیمات PostgreSQL، عمل ثبت ممکن است شامل نوشتن هم‌زمان روی دیسک نباشد.
LEGAL_LOG_PGSQL_DB_RECONNECT_ATTEMPT_FAILED
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
LEGAL_LOG_PGSQL_DB_RECONNECT_ATTEMPT_SCHEDULE
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاعاتی (info) که هنگام زمان‌بندی تلاش بعدی سرور برای اتصال مجدد به پایگاه داده صادر می‌شود. این وضعیت زمانی رخ می‌دهد که اتصال سرور به پایگاه داده قطع شده باشد و در حال تلاش برای اتصال مجدد خودکار باشد..SS LEGAL_LOG_PGSQL_DB_RECONNECT_FAILED
0.0
3.5
حداکثر تعداد تلاش‌ها برای اتصال مجدد به پایگاه داده: %1، بدون موفقیت به پایان رسید
168u
168u
پیام خطایی که هنگام شکست سرور در اتصال مجدد صادر می‌شود. قطع ارتباط معمولاً ناشی از یک مشکل شبکه یا سرور پایگاه داده است.
LEGAL_LOG_PGSQL_DEALLOC_ERROR
0.0
3.5
هنگام آزادسازی عبارت‌های SQL در زمان بستن پایگاه داده گزارش PostgreSQL خطایی رخ داد: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کتابخانه قلاب legal log در فرایند بستن اتصال خود به پایگاه داده PostgreSQL، هنگام آزادسازی منابع SQL پایگاه داده با خطا مواجه شود. این اتصال به عنوان بخشی از روال عادی خاموش‌سازی سرور بسته می‌شود. این خطا به احتمال زیاد یک مشکل نرم‌افزاری است که وقوع آن یا تأثیر منفی آن بر عملکرد سرور بسیار بعید است.
LEGAL_LOG_PGSQL_FATAL_ERROR
0.0
3.5
خطای غیرقابل‌بازیابی PostgreSQL رخ داد: عبارت: <%1>، دلیل: %2 (کد خطا: %3).
168u
168u
پیام خطایی که نشان می‌دهد ارتباط با سرور پایگاه داده PostgreSQL قطع شده است. هنگام رخ دادن این وضعیت، سرور بلافاصله با یک کد خروج غیر-صفر خارج می‌شود. این مشکل به احتمال زیاد به دلیل وجود اختلال در شبکه رخ می‌دهد.
LEGAL_LOG_PGSQL_GET_VERSION
0.0
3.5
دریافت اطلاعات نسخه طرح‌واره
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در آستانه دریافت اطلاعات نسخه طرح‌واره (schema) از پایگاه داده PostgreSQL باشد.
LEGAL_LOG_PGSQL_INSERT_LOG
0.0
3.5
افزودن یک مدخل گزارش به پایگاه داده: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
پیامی اطلاع‌رسانی که هنگام درج یک مدخل گزارش ثبت می‌شود.
LEGAL_LOG_PGSQL_INVALID_ACCESS
0.0
3.5
رشته نامعتبر دسترسی به پایگاه داده: %1
168u
168u
این مورد زمانی ثبت می‌شود که تلاشی برای تجزیه رشته دسترسی به پایگاه داده انجام گرفته و به خطا منجر شده باشد. رشته دسترسی مورد نظر - که باید به صورت 'keyword=value keyword=value...' باشد - در متن پیام گنجانده شده است.
LEGAL_LOG_PGSQL_ROLLBACK
0.0
3.5
بازگردانی پایگاه داده PostgreSQL
168u
168u
کد برنامه‌نویسی یک فراخوانی بازگردانی (rollback) صادر کرده است. تمام تراکنش‌های معلق بازگردانی خواهند شد و در پایگاه داده اعمال (commit) نمی‌شوند.
LEGAL_LOG_PGSQL_START_TRANSACTION
0.0
3.5
شروع یک تراکنش جدید PostgreSQL
168u
168u
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تراکنش جدید PostgreSQL در حال آغاز باشد.
این پیام معمولاً هنگام درج داده‌ها در یک جدول منفرد صادر نمی‌شود، زیرا سرور در این حالت
به‌طور صریح تراکنش‌ها را آغاز نمی‌کند. این پیام زمانی صادر می‌شود که داده‌ها
با چندین عبارت INSERT در چندین جدول درج شوند و ممکن است در صورت شکست هر یک
از این دستورات INSERT، نیاز به بازگردانی (rollback) کل تراکنش باشد.
LEGAL_LOG_STORE_CLOSED
0.0
3.5
مخزن لاگ قانونی بسته شد: %1
168u
168u
این یک پیام اطلاع‌رسانی است و زمانی صادر می‌شود که کتابخانه Legal Log مخزن گزارش‌های قانونی را با موفقیت بسته باشد..SS LEGAL_LOG_STORE_CLOSE_ERROR
0.0
3.5
An error occurred closing the store: %1, error: %2
168u
168u
این یک پیام خطا است که هنگام بروز مشکل در کتابخانهٔ legal log برای بستن یک legal store صادر می‌شود. رخ دادن این حالت بسیار بعید است و نباید تأثیری بر محتوای مخزن یا عملیات بعدی legal store بگذارد.
LEGAL_LOG_STORE_OPEN
0.0
3.5
opening Legal Log file: %1
168u
168u
این پیام اطلاعاتی هنگامی ثبت می‌شود که یک کارگزار DHCP (چه V4 یا V6) در شرف باز کردن یک فایل legal log باشد. پارامترهای backend در لاگ ثبت می‌شوند.
LEGAL_LOG_STORE_OPENED
0.0
3.5
Legal store opened: %1
168u
168u
این یک پیام اطلاعاتی است که پس از باز شدن موفقیت‌آمیز legal store توسط کتابخانهٔ Legal Log صادر می‌شود.
LEGAL_LOG_SYSLOG
0.0
3.5
%1
168u
168u
این پیام اطلاعاتی شامل پیامی است که در syslog ثبت می‌شود.
LEGAL_LOG_SYSLOG_STORE_OPEN
0.0
3.5
opening Legal Syslog: %1
168u
168u
این پیام اطلاعاتی هنگامی ثبت می‌شود که یک کارگزار DHCP (چه V4 یا V6) در شرف باز کردن یک مخزن legal syslog باشد. پارامترهای backend در لاگ ثبت می‌شوند.
LEGAL_LOG_UNLOAD_ERROR
0.0
3.5
An error occurred unloading the library: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هنگام تخلیهٔ (unload) کتابخانهٔ Legal Log خطایی رخ دهد. وقوع این خطا بعید است و احتمالاً با بارگذاری مجدد کتابخانه در دفعات بعدی، عملکرد عادی آن از سر گرفته خواهد شد.
LFC
LFC_FAIL_PID_CREATE
0.0
3.5
: %1
168u
168u
این پیام زمانی صادر می‌شود که LFC هنگام تلاش برای ایجاد فایل PID با خطا مواجه شود. این پیام شامل یک رشته خطای دقیق‌تر است.
LFC_FAIL_PID_DEL
0.0
3.5
: %1
168u
168u
این پیام زمانی صادر می‌شود که LFC هنگام تلاش برای حذف فایل PID با خطا مواجه شود. این پیام شامل یک رشته خطای دقیق‌تر است.
LFC_FAIL_PROCESS
0.0
3.5
: %1
168u
168u
این پیام زمانی صادر می‌شود که LFC هنگام تلاش برای پردازش فایل‌ها با خطا مواجه شود. این پیام شامل یک رشته خطای دقیق‌تر است.
LFC_FAIL_ROTATE
0.0
3.5
: %1
168u
168u
این پیام زمانی صادر می‌شود که LFC هنگام تلاش برای چرخش فایل‌ها (rotate) با خطا مواجه شود. این پیام شامل یک رشته خطای دقیق‌تر است..SS LFC_PROCESSING
0.0
3.5
Previous file: %1, copy file: %2
168u
168u
این پیام درست پیش از اینکه LFC پردازش فایل‌های اجاره را آغاز کند، صادر می‌شود.
LFC_READ_STATS
0.0
3.5
Leases: %1, attempts: %2, errors: %3.
168u
168u
این پیام تعداد اجاره‌های خوانده‌شده، تعداد تلاش‌ها برای خواندن اجاره‌ها و تعداد خطاهای رخ‌داده هنگام خواندن را چاپ می‌کند.
LFC_ROTATING
0.0
3.5
LFC rotating files
168u
168u
این پیام درست پیش از شروع چرخش (rotate) فایل‌های اجاره توسط LFC صادر می‌شود - حذف فایل‌های قدیمی و جایگزینی آن‌ها با موارد جدید.
LFC_RUNNING
0.0
3.5
LFC instance already running
168u
168u
این پیام در صورتی صادر می‌شود که LFC از طریق بررسی PID تشخیص دهد نمونه قبلی LFC ممکن است همچنان در حال اجرا باشد.
LFC_START
0.0
3.5
Starting lease file cleanup
168u
168u
این پیام با شروع فرایند LFC صادر می‌شود.
LFC_TERMINATE
0.0
3.5
LFC finished processing
168u
168u
این پیام هنگام اتمام فرایند LFC صادر می‌شود. این پیام نشان‌دهنده موفقیت‌آمیز بودن فرایند نیست، بلکه تنها پایان یافتن آن را مشخص می‌کند.
LFC_WRITE_STATS
0.0
3.5
Leases: %1, attempts: %2, errors: %3.
168u
168u
این پیام تعداد اجاره‌های نوشته‌شده، تعداد تلاش‌ها برای نوشتن اجاره‌ها و تعداد خطاهای رخ‌داده هنگام نوشتن را چاپ می‌کند.
LIMITS
LIMITS_CONFIGURATION_LEASE_BACKEND_NOT_AVAILABLE
0.0
3.5
Lease backend not available. Could not check JSON support in the database. Continuing without checking...
168u
168u
پیام هشداری که ثبت می‌شود تا اطلاع دهد اگر پایگاه‌داده در حال بازیابی از JSON پشتیبانی نکند، ممکن است محدودیت‌ها کار نکنند.
LIMITS_CONFIGURATION_LEASE_BACKEND_SHOULD_HAVE_BEEN_AVAILABLE
0.0
3.5
Lease backend not available when configuration shows it should have been. This is likely a programmatic error. Continuing...
168u
168u
پیام خطایی که برای اطلاع‌رسانی درباره یک وضعیت غیرمنتظره ثبت می‌شود؛ وضعیتی که در آن انتظار می‌رفت backend اجاره در دسترس باشد اما در دسترس نبود. ممکن است خطاهای زمان اجرا (runtime) رخ دهند.
LIMITS_CONFIGURED_ADDRESS_LIMIT_BY_CLIENT_CLASS
0.0
3.5
New lease limit of %1 addresses for client class %2 has been configured.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که برای اطلاع‌رسانی از پیکربندی موفقیت‌آمیز محدودیت نشانی به ازای هر client class ثبت می‌شود..SS LIMITS_CONFIGURED_ADDRESS_LIMIT_BY_SUBNET
0.0
3.5
حد اجاره جدید %1 نشانی برای زیرشبکه با شناسه %2 پیکربندی شده است.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای اطلاع‌رسانی درباره پیکربندی موفقیت‌آمیز یک حد نشانی به ازای هر زیرشبکه
LIMITS_CONFIGURED_PREFIX_LIMIT_BY_CLIENT_CLASS
0.0
3.5
حد اجاره جدید %1 پیشوند برای کلاس کلاینت %2 پیکربندی شده است.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای اطلاع‌رسانی درباره پیکربندی موفقیت‌آمیز یک حد پیشوند به ازای هر کلاس کلاینت
LIMITS_CONFIGURED_PREFIX_LIMIT_BY_SUBNET
0.0
3.5
حد اجاره جدید %1 پیشوند برای زیرشبکه با شناسه %2 پیکربندی شده است.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای اطلاع‌رسانی درباره پیکربندی موفقیت‌آمیز یک حد پیشوند به ازای هر زیرشبکه
LIMITS_CONFIGURED_RATE_LIMIT_BY_CLIENT_CLASS
0.0
3.5
حد نرخ جدید %1 برای کلاس کلاینت %2 پیکربندی شده است.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای اطلاع‌رسانی درباره پیکربندی موفقیت‌آمیز یک حد نرخ به ازای هر کلاس کلاینت
LIMITS_CONFIGURED_RATE_LIMIT_BY_SUBNET
0.0
3.5
حد نرخ جدید %1 برای زیرشبکه با شناسه %2 پیکربندی شده است.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای اطلاع‌رسانی درباره پیکربندی موفقیت‌آمیز یک حد نرخ به ازای هر زیرشبکه
LIMITS_LEASE_LIMIT_EXCEEDED
0.0
3.5
اجاره به دلیل فراتر رفتن از %1 تخصیص داده نشد.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای نشان دادن اینکه تعداد فعلی نشانی‌ها یا
پیشوندهای اجاره‌داده‌شده برای یک کلاس کلاینت یا یک زیرشبکه از حد مجاز فراتر رفته است.
LIMITS_LEASE_WITHIN_LIMITS
0.0
3.5
اجاره با نشانی %1 در محدوده مجاز است.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای نشان دادن اینکه تعداد فعلی نشانی‌ها یا
پیشوندهای اجاره‌داده‌شده برای یک کلاس کلاینت یا یک زیرشبکه از حد مجاز فراتر نرفته است.
LIMITS_PACKET_WIIH_SUBNET_ID_RATE_NO_SUBNET
0.0
3.5
به دلیل مشخص نشدن زیرشبکه، محدودیت نرخ بر روی بسته اعمال نمی‌شود.
168u
168u
در سطح گزارش اشکال‌زدایی 55 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای نشان دادن اینکه حد نرخ زیرشبکه برای بسته فعلی (در صورت وجود)، به دلیل
تنظیم نشدن زیرشبکه در callout handle بررسی نمی‌شود. این وضعیت می‌تواند به عنوان مثال در صورتی رخ دهد که
زیرشبکه پس از انتخاب شدن برای بسته در حال پردازش فعلی، حذف شده باشد.
LIMITS_PACKET_WITH_CLIENT_CLASSES_RATE_LIMIT_DROPPED
0.0
3.5
بسته تخصیص‌یافته به کلاس‌های کلاینت %1 به دلیل فراتر رفتن از حد نرخ %2 برای کلاس کلاینت %3 دور انداخته می‌شود.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای نشان دادن اینکه بسته فعلی از یکی از محدودیت‌های نرخ
پیکربندی‌شده ذیل حداقل یک کلاس کلاینت فراتر رفته است
LIMITS_PACKET_WITH_CLIENT_CLASSES_RATE_LIMIT_HONORED
0.0
3.5
بسته تخصیص‌یافته به کلاس‌های کلاینت %1 پذیرفته می‌شود.
168u
168u
در سطح گزارش اشکال‌زدایی 55 ثبت می‌شود.
پیام اشکال‌زدایی ثبت‌شده برای نشان دادن اینکه بسته فعلی از هیچ‌یک از محدودیت‌های نرخ
پیکربندی‌شده ذیل هیچ کلاس کلاینتی فراتر نرفته است.SS LIMITS_PACKET_WITH_SUBNET_ID_RATE_LIMIT_DROPPED
0.0
3.5
Packet assigned to subnet with ID %1 is being dropped for exceeding the rate limit of %2.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی برای اعلام این‌که بستهٔ جاری به‌دلیل فراتر رفتن از محدودیت نرخ (rate limit) پیکربندی‌شده ذیل شناسهٔ زیرشبکهٔ (subnet ID) اختصاص‌یافته، در صورت وجود، دور ریخته می‌شود (drop).
LIMITS_PACKET_WITH_SUBNET_ID_RATE_LIMIT_HONORED
0.0
3.5
Packet under subnet with ID %1 and limit %2 is being honored.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
پیام اشکال‌زدایی برای اعلام این‌که بستهٔ جاری از محدودیت پیکربندی‌شده ذیل شناسهٔ زیرشبکهٔ اختصاص‌یافته فراتر نرفته است. این پیام همچنین زمانی که هیچ محدودیت نرخی برای این شناسهٔ زیرشبکه پیکربندی نشده باشد، ثبت می‌شود.
LOGIMPL
LOGIMPL_ABOVE_MAX_DEBUG
0.0
3.5
debug level of %1 is too high and will be set to the maximum of %2
168u
168u
پیامی از رابط به پیاده‌سازی لاگر (logger) زیرین مبنی بر این‌که سطح اشکال‌زدایی (که توسط یک رشتهٔ داخلی مانند DEBUGn تنظیم شده است، که در آن n یک عدد صحیح است، مانند DEBUG22) بالاتر از حداکثر مقدار مجاز بوده و به آن مقدار کاهش یافته است. نمایش این پیام ممکن است نشان‌دهندهٔ خطای برنامه‌نویسی باشد - لطفاً یک گزارش باگ ارسال کنید.
LOGIMPL_BAD_DEBUG_STRING
0.0
3.5
debug string '%1' has invalid format
168u
168u
پیامی از رابط به پیاده‌سازی لاگر زیرین مبنی بر این‌که رشتهٔ ایجادشده به‌صورت داخلی برای تنظیم سطح اشکال‌زدایی، قالب معتبری ندارد (باید به‌صورت DEBUGn باشد که در آن n یک عدد صحیح است، مانند DEBUG22). نمایش این پیام نشان‌دهندهٔ خطای برنامه‌نویسی است - لطفاً یک گزارش باگ ارسال کنید.
LOGIMPL_BELOW_MIN_DEBUG
0.0
3.5
debug level of %1 is too low and will be set to the minimum of %2
168u
168u
پیامی از رابط به پیاده‌سازی لاگر زیرین مبنی بر این‌که سطح اشکال‌زدایی (که توسط یک رشتهٔ داخلی مانند DEBUGn تنظیم شده است، که در آن n یک عدد صحیح است، مانند DEBUG22) کمتر از حداقل مقدار مجاز بوده و به آن مقدار افزایش یافته است. نمایش این پیام ممکن است نشان‌دهندهٔ خطای برنامه‌نویسی باشد - لطفاً یک گزارش باگ ارسال کنید.
LOG
LOG_BAD_DESTINATION
0.0
3.5
unrecognized log destination: %1
168u
168u
این پیام خطا زمانی چاپ می‌شود که مقدار مقصد لاگر (logger destination) مشخص‌شده ناشناخته باشد. مقصد باید یکی از مقادیر "console"، "file" یا "syslog" باشد.
LOG_BAD_SEVERITY
0.0
3.5
unrecognized log severity: %1
168u
168u
این پیام خطا زمانی چاپ می‌شود که مقدار سطح اهمیت لاگر (logger severity) مشخص‌شده ناشناخته باشد. سطح اهمیت باید یکی از مقادیر "DEBUG"، "INFO"، "WARN"، "ERROR"، "FATAL" یا "NONE" باشد.
LOG_BAD_STREAM
0.0
3.5
bad log console output stream: %1
168u
168u
ثبت لاگ به‌گونه‌ای پیکربندی شده است که خروجی در ترمینال (console) نوشته شود، اما جریانی (stream) که قرار است در آن نوشته شود شناخته‌شده نیست. مقادیر مجاز "stdout" و "stderr" هستند.
LOG_DUPLICATE_MESSAGE_ID
0.0
3.5
duplicate message ID (%1) in compiled code
168u
168u
در حین راه‌اندازی (start-up)، نرم‌افزار Kea تشخیص داد که شناسهٔ پیام داده‌شده چندین بار در کد Kea تعریف شده است. این امر نشان‌دهندهٔ خطای برنامه‌نویسی است؛ لطفاً یک گزارش باگ ارسال کنید..SS LOG_DUPLICATE_NAMESPACE
0.0
3.5
line %1: duplicate $NAMESPACE directive found
168u
168u
هنگام خواندن یک فایل پیام، بیش از یک دستورالعمل $NAMESPACE یافت شد.
(این دستورالعمل برای تعیین یک فضای نام C++ هنگام تولید فایل‌های سرآیند
در طول توسعه نرم‌افزار استفاده می‌شود.) چنین وضعیتی به عنوان یک خطا در
نظر گرفته شده و فرآیند خواندن متوقف خواهد شد.
LOG_INPUT_OPEN_FAIL
0.0
3.5
unable to open message file %1 for input: %2
168u
168u
برنامه به دلیل ذکرشده قادر به باز کردن فایل پیام ورودی مشخص‌شده نبود.
LOG_INVALID_MESSAGE_ID
0.0
3.5
line %1: invalid message identification '%2'
168u
168u
یک شناسه (ID) نامعتبر برای پیام در حین خواندن فایل پیام پیدا شده است.
شناسه‌های پیام باید تنها شامل نویسه‌های الفبایی-عددی و خط زیرین (underscore)
باشند و نباید با یک رقم شروع شوند.
LOG_LOCK_TEST_MESSAGE
0.0
3.5
this is a test message.
168u
168u
این یک پیام گزارش وقایع (log) است که در آزمون‌ها استفاده می‌شود.
LOG_NAMESPACE_EXTRA_ARGS
0.0
3.5
line %1: $NAMESPACE directive has too many arguments
168u
168u
دستورالعمل $NAMESPACE در یک فایل پیام تنها یک آرگومان می‌پذیرد؛
فضای نامی که تمام نام‌های نمادِ تولیدشده در آن قرار می‌گیرند. این خطا
زمانی رخ می‌دهد که کامپایلر یک دستورالعمل $NAMESPACE را با بیش از یک
آرگومان پیدا کند.
LOG_NAMESPACE_INVALID_ARG
0.0
3.5
line %1: $NAMESPACE directive has an invalid argument ('%2')
168u
168u
آرگومان $NAMESPACE در یک فایل پیام باید یک فضای نام معتبر در C++ باشد.
این پیام در صورتی نمایش داده می‌شود که بررسی اولیه نحو (syntax) رشته
توسط خواننده فایل با شکست مواجه شود.
LOG_NAMESPACE_NO_ARGS
0.0
3.5
line %1: no arguments were given to the $NAMESPACE directive
168u
168u
دستورالعمل $NAMESPACE در یک فایل پیام تنها یک آرگومان می‌پذیرد؛
یک فضای نام C++ که تمام نام‌های نمادِ ایجادشده در آن قرار می‌گیرند.
این خطا زمانی تولید می‌شود که کامپایلر یک دستورالعمل $NAMESPACE بدون
هیچ آرگومانی را پیدا کند.
LOG_NO_MESSAGE_ID
0.0
3.5
line %1: message definition line found without a message ID
168u
168u
در یک فایل پیام، پیام‌ها با خطوطی مشخص می‌شوند که با "%" آغاز می‌گردند.
باقی خط باید شامل شناسه پیام و متنی باشد که پیام را شرح می‌دهد. این خطا
نشان می‌دهد که کامپایلر پیام خطی را در فایل پیدا کرده است که فقط شامل
"%" بوده و هیچ محتوای دیگری ندارد.
LOG_NO_MESSAGE_TEXT
0.0
3.5
line %1: line found containing a message ID ('%2') and no text
168u
168u
در یک فایل پیام، پیام‌ها با خطوطی مشخص می‌شوند که با "%" آغاز می‌گردند.
باقی خط باید شامل شناسه پیام و متن توصیف‌کننده پیام باشد. این خطا نشان می‌دهد
که کامپایلر پیام خطی را در فایل پیدا کرده است که فقط حاوی "%" و شناسه پیام
است، اما هیچ متنی ندارد..SS LOG_NO_SUCH_MESSAGE
0.0
3.5
could not replace message text for '%1': no such message
168u
168u
در حین راه‌اندازی، یک فایل پیام محلی خوانده شد. خطی با شناسه پیامِ مشخص‌شده در فایل یافت شد، اما این شناسه در فرهنگ پیام‌های کامپایل‌شده (compiled-in message dictionary) وجود ندارد. این پیام ممکن است چندین بار در فایل ظاهر شود، یک بار به ازای هر شناسه پیام ناشناخته.
دلایل متعددی برای ظاهر شدن این پیام وجود دارد:
- شناسه پیام در فایل پیام محلی دارای غلط املایی است.
- برنامه‌ای که پیام را در خروجی می‌نویسد ممکن است از آن پیام خاص استفاده نکند (برای نمونه، پیام از ماژولی منشأ می‌گیرد که توسط برنامه استفاده نمی‌شود).
- فایل محلی برای نسخه‌ای قدیمی‌تر از نرم‌افزار Kea نوشته شده و نسخه جدیدتر دیگر آن پیام را تولید نمی‌کند.
علت هرچه که باشد، هیچ تأثیری بر عملکرد Kea ندارد.
LOG_OPEN_OUTPUT_FAIL
0.0
3.5
unable to open %1 for output: %2
168u
168u
این خطا که از درون کد ثبت وقایع ناشی می‌شود، نشان‌دهنده آن است که برنامه به دلیل ذکرشده نتوانسته فایل خروجی مشخص‌شده را باز کند.
LOG_PREFIX_EXTRA_ARGS
0.0
3.5
line %1: $PREFIX directive has too many arguments
168u
168u
درون یک فایل پیام، دستورالعمل $PREFIX تنها یک آرگومان می‌پذیرد؛ پیشوندی که هنگام ایجاد یک فایل C++ به نام نمادها اضافه می‌شود. این خطا زمانی ایجاد می‌شود که کامپایلر یک دستورالعمل $PREFIX با بیش از یک آرگومان را بیابد.
نکته: دستورالعمل $PREFIX منسوخ شده است و در نسخه‌های آینده Kea حذف خواهد شد.
LOG_PREFIX_INVALID_ARG
0.0
3.5
line %1: $PREFIX directive has an invalid argument ('%2')
168u
168u
درون یک فایل پیام، دستورالعمل $PREFIX تنها یک آرگومان می‌پذیرد؛ پیشوندی که هنگام ایجاد یک فایل C++ به نام نمادها اضافه می‌شود. بدین ترتیب، این پیشوند باید از محدودیت‌های نام‌گذاری نمادها در C++ پیروی کند (برای مثال، فقط می‌تواند شامل نویسه‌های الفبایی-عددی یا زیرخط باشد و نباید با رقم شروع شود). یک دستورالعمل $PREFIX با آرگومانی یافت شد (در پیام آمده است) که این محدودیت‌ها را نقض می‌کند.
نکته: دستورالعمل $PREFIX منسوخ شده است و در نسخه‌های آینده Kea حذف خواهد شد.
LOG_READING_LOCAL_FILE
0.0
3.5
reading local message file %1
168u
168u
این یک پیام اطلاع‌رسانی است که توسط Kea هنگام شروع به خواندن یک فایل پیام محلی صادر می‌شود. (یک فایل پیام محلی ممکن است متن یک یا چند پیام را جایگزین کند؛ با این حال، شناسه پیام تغییر نخواهد کرد.)
LOG_READ_ERROR
0.0
3.5
error reading from message file %1: %2
168u
168u
هنگام خواندن از فایل پیام نام‌برده، خطای مشخص‌شده رخ داده است.
LOG_UNRECOGNIZED_DIRECTIVE
0.0
3.5
line %1: unrecognized directive '%2'
168u
168u
درون یک فایل پیام، خطی یافت شد که با نماد دلار ($) شروع شده است (که نشان‌دهنده وجود یک دستورالعمل است)، اما واژه نخست در آن خط (که در پیام نشان داده شده) شناسایی نشد.
LOG_WRITE_ERROR
0.0
3.5
error writing to %1: %2
168u
168u
کامپایلر پیام هنگام نوشتن در فایل خروجی نام‌برده با خطای مشخص‌شده مواجه شد.
MT
MT_TCP_LISTENER_MGR_STARTED
0.0
3.5
MtTcpListenerMgr started with %1 threads, listening on %2:%3, use TLS: %4
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک MtTcpListenerMgr برای پذیرش اتصالات راه‌اندازی شده باشد. آرگومان‌ها جزئیات تعداد رشته‌هایی (threads) که شنونده استفاده می‌کند، آدرس و درگاهی (port) که در آن به گوش فرامی‌دهد، و اینکه آیا از TLS استفاده می‌شود یا خیر را مشخص می‌کنند..SS MT_TCP_LISTENER_MGR_STOPPED
0.0
3.5
MtTcpListenerMgr for %1:%2 stopped.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که MtTcpListenerMgr در حال گوش‌دادن
روی نشانی و پورت مشخص‌شده، فرایند خاموش شدن را به پایان رسانده باشد.
MT_TCP_LISTENER_MGR_STOPPING
0.0
3.5
Stopping MtTcpListenerMgr for %1:%2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که MtTcpListenerMgr در حال گوش‌دادن
روی نشانی و پورت مشخص‌شده، فرایند خاموش شدن را آغاز کرده باشد.
MYSQL
MYSQL_CB_CREATE_UPDATE_BY_POOL_OPTION4
0.0
3.5
create or update option pool start: %1 pool end: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی گزینه بر اساس استخر (pool) صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_BY_POOL_OPTION6
0.0
3.5
create or update option pool start: %1 pool end: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی گزینه بر اساس استخر (pool) صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_BY_PREFIX_OPTION6
0.0
3.5
create or update option prefix: %1 prefix len: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی گزینه بر اساس پیشوند (prefix) صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION4
0.0
3.5
create or update option by subnet id: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی گزینه بر اساس شناسه زیرشبکه (subnet id) صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION6
0.0
3.5
create or update option by subnet id: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی گزینه بر اساس شناسه زیرشبکه (subnet id) صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_CLIENT_CLASS4
0.0
3.5
create or update client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی کلاس کلاینت (client class) صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_CLIENT_CLASS6
0.0
3.5
create or update client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی کلاس کلاینت (client class) صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER4
0.0
3.5
create or update global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات ایجاد یا به‌روزرسانی پارامتر سراسری (global parameter) صادر می‌شود..SS MYSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER6
0.0
3.5
create or update global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی پارامتر سراسری فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_OPTION4
0.0
3.5
create or update option
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینه (option) فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_OPTION6
0.0
3.5
create or update option
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینه (option) فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_OPTION_DEF4
0.0
3.5
create or update option definition: %1 code: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی تعریف گزینه فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_OPTION_DEF6
0.0
3.5
create or update option definition: %1 code: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی تعریف گزینه فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_SERVER4
0.0
3.5
create or update server: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی اطلاعات
سرور DHCPv4 فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_SERVER6
0.0
3.5
create or update server: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی اطلاعات
سرور DHCPv6 فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK4
0.0
3.5
create or update shared network: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی شبکه مشترک فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK6
0.0
3.5
create or update shared network: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی شبکه مشترک فعال شده باشد.
MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION4
0.0
3.5
create or update shared network: %1 option
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینهٔ شبکه مشترک فعال شده باشد..SS MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION6
0.0
3.5
create or update shared network: %1 option
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات ایجاد یا به‌روزرسانی گزینهٔ شبکهٔ اشتراکی صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_SUBNET4
0.0
3.5
create or update subnet: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات ایجاد یا به‌روزرسانی زیرشبکه صادر می‌شود.
MYSQL_CB_CREATE_UPDATE_SUBNET6
0.0
3.5
create or update subnet: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات ایجاد یا به‌روزرسانی زیرشبکه صادر می‌شود.
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES4
0.0
3.5
delete all client classes
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام کلاس‌های کلاینت صادر می‌شود.
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف تمام کلاس‌های کلاینت است.
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES6
0.0
3.5
delete all client classes
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام کلاس‌های کلاینت صادر می‌شود.
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف تمام کلاس‌های کلاینت است.
MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4
0.0
3.5
delete all global parameters
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام پارامترهای سراسری صادر می‌شود.
MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف تمام پارامترهای سراسری است.
MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6
0.0
3.5
delete all global parameters
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام پارامترهای سراسری صادر می‌شود..SS MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام پارامترهای سراسری را نشان می‌دهد.
MYSQL_CB_DELETE_ALL_OPTION_DEFS4
0.0
3.5
delete all option definitions
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات حذف تمام تعاریف گزینه‌ها.
MYSQL_CB_DELETE_ALL_OPTION_DEFS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام تعاریف گزینه‌ها را نشان می‌دهد.
MYSQL_CB_DELETE_ALL_OPTION_DEFS6
0.0
3.5
delete all option definitions
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات حذف تمام تعاریف گزینه‌ها.
MYSQL_CB_DELETE_ALL_OPTION_DEFS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام تعاریف گزینه‌ها را نشان می‌دهد.
MYSQL_CB_DELETE_ALL_SERVERS4
0.0
3.5
delete all DHCPv4 servers
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات حذف تمام سرورها.
MYSQL_CB_DELETE_ALL_SERVERS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام سرورها را نشان می‌دهد.
MYSQL_CB_DELETE_ALL_SERVERS6
0.0
3.5
delete all DHCPv6 servers
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات حذف تمام سرورها.
MYSQL_CB_DELETE_ALL_SERVERS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام سرورها را نشان می‌دهد.
MYSQL_CB_DELETE_ALL_SHARED_NETWORKS4
0.0
3.5
delete all shared networks
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات حذف تمام شبکه‌های اشتراکی..SS MYSQL_CB_DELETE_ALL_SHARED_NETWORKS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه یک اقدام برای حذف همه شبکه‌های مشترک است.
MYSQL_CB_DELETE_ALL_SHARED_NETWORKS6
0.0
3.5
delete all shared networks
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی اقدامی برای حذف همه شبکه‌های مشترک صادر می‌شود.
MYSQL_CB_DELETE_ALL_SHARED_NETWORKS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه یک اقدام برای حذف همه شبکه‌های مشترک است.
MYSQL_CB_DELETE_ALL_SUBNETS4
0.0
3.5
delete all subnets
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی اقدامی برای حذف همه زیرشبکه‌ها صادر می‌شود.
MYSQL_CB_DELETE_ALL_SUBNETS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه یک اقدام برای حذف همه زیرشبکه‌ها است.
MYSQL_CB_DELETE_ALL_SUBNETS6
0.0
3.5
delete all subnets
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی اقدامی برای حذف همه زیرشبکه‌ها صادر می‌شود.
MYSQL_CB_DELETE_ALL_SUBNETS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه یک اقدام برای حذف همه زیرشبکه‌ها است.
MYSQL_CB_DELETE_BY_POOL_OPTION4
0.0
3.5
delete pool start: %1 pool end: %2 option code: %3 space: %4
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی اقدامی برای حذف گزینه بر اساس استخر صادر می‌شود.
MYSQL_CB_DELETE_BY_POOL_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه یک اقدام برای حذف گزینه بر اساس استخر است.
MYSQL_CB_DELETE_BY_POOL_OPTION6
0.0
3.5
delete pool start: %1 pool end: %2 option code: %3 space: %4
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی اقدامی برای حذف گزینه بر اساس استخر صادر می‌شود..SS MYSQL_CB_DELETE_BY_POOL_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس استخر (pool) است.
MYSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6
0.0
3.5
delete prefix: %1 prefix len: %2 option code: %3 space: %4
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف گزینه بر اساس پیشوند (prefix).
MYSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس پیشوند است.
MYSQL_CB_DELETE_BY_PREFIX_SUBNET4
0.0
3.5
delete subnet by prefix: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف زیرشبکه (subnet) بر اساس پیشوند.
MYSQL_CB_DELETE_BY_PREFIX_SUBNET4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه بر اساس پیشوند است.
MYSQL_CB_DELETE_BY_PREFIX_SUBNET6
0.0
3.5
delete subnet by prefix: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف زیرشبکه بر اساس پیشوند.
MYSQL_CB_DELETE_BY_PREFIX_SUBNET6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه بر اساس پیشوند است.
MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION4
0.0
3.5
delete by subnet id: %1 option code: %2 space: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه (subnet id).
MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه است.
MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION6
0.0
3.5
delete by subnet id: %1 option code: %2 space: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه..SS MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه (subnet id) است.
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4
0.0
3.5
delete subnet by subnet id: %1
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه صادر می‌شود.
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه است.
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6
0.0
3.5
delete subnet by subnet id: %1
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه صادر می‌شود.
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه است.
MYSQL_CB_DELETE_CLIENT_CLASS4
0.0
3.5
delete client class: %1
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف کلاس کلاینت (client class) صادر می‌شود.
MYSQL_CB_DELETE_CLIENT_CLASS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف کلاس کلاینت است.
MYSQL_CB_DELETE_CLIENT_CLASS6
0.0
3.5
delete client class: %1
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف کلاس کلاینت صادر می‌شود.
MYSQL_CB_DELETE_CLIENT_CLASS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف کلاس کلاینت است.
MYSQL_CB_DELETE_GLOBAL_PARAMETER4
0.0
3.5
delete global parameter: %1
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف پارامتر سراسری (global parameter) صادر می‌شود..SS MYSQL_CB_DELETE_GLOBAL_PARAMETER4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف پارامتر سراسری است.
MYSQL_CB_DELETE_GLOBAL_PARAMETER6
0.0
3.5
delete global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف پارامتر سراسری صادر می‌شود.
MYSQL_CB_DELETE_GLOBAL_PARAMETER6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف پارامتر سراسری است.
MYSQL_CB_DELETE_OPTION4
0.0
3.5
delete option code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف گزینه صادر می‌شود.
MYSQL_CB_DELETE_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه است.
MYSQL_CB_DELETE_OPTION6
0.0
3.5
delete option code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف گزینه صادر می‌شود.
MYSQL_CB_DELETE_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه است.
MYSQL_CB_DELETE_OPTION_DEF4
0.0
3.5
delete option definition code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف تعریف گزینه صادر می‌شود.
MYSQL_CB_DELETE_OPTION_DEF4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف تعریف گزینه است.
MYSQL_CB_DELETE_OPTION_DEF6
0.0
3.5
delete option definition code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف تعریف گزینه صادر می‌شود..SS MYSQL_CB_DELETE_OPTION_DEF6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات حذف تعریف گزینه (option definition) است.
MYSQL_CB_DELETE_SERVER4
0.0
3.5
delete DHCPv4 server: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف یک سرور.
MYSQL_CB_DELETE_SERVER4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات حذف یک سرور است.
MYSQL_CB_DELETE_SERVER6
0.0
3.5
delete DHCPv6 server: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف یک سرور.
MYSQL_CB_DELETE_SERVER6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات حذف یک سرور است.
MYSQL_CB_DELETE_SHARED_NETWORK4
0.0
3.5
delete shared network: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف شبکه مشترک (shared network).
MYSQL_CB_DELETE_SHARED_NETWORK4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات حذف شبکه مشترک (shared network) است.
MYSQL_CB_DELETE_SHARED_NETWORK6
0.0
3.5
delete shared network: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف شبکه مشترک (shared network).
MYSQL_CB_DELETE_SHARED_NETWORK6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات حذف شبکه مشترک (shared network) است.
MYSQL_CB_DELETE_SHARED_NETWORK_OPTION4
0.0
3.5
delete shared network: %1 option code: %2 space: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف گزینه شبکه مشترک (shared network option)..SS MYSQL_CB_DELETE_SHARED_NETWORK_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینهٔ شبکه مشترک.
MYSQL_CB_DELETE_SHARED_NETWORK_OPTION6
0.0
3.5
delete shared network: %1 option code: %2 space: %3
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف گزینهٔ شبکه مشترک صادر می‌شود.
MYSQL_CB_DELETE_SHARED_NETWORK_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینهٔ شبکه مشترک.
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4
0.0
3.5
delete shared network: %1 subnets
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف زیرشبکه‌های شبکه مشترک صادر می‌شود.
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه‌های شبکه مشترک.
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6
0.0
3.5
delete shared network: %1 subnets
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف زیرشبکه‌های شبکه مشترک صادر می‌شود.
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه‌های شبکه مشترک.
MYSQL_CB_GET_ALL_CLIENT_CLASSES4
0.0
3.5
retrieving all client classes
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات بازیابی تمام کلاس‌های کلاینت صادر می‌شود.
MYSQL_CB_GET_ALL_CLIENT_CLASSES4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیات بازیابی تمام کلاس‌های کلاینت.
MYSQL_CB_GET_ALL_CLIENT_CLASSES6
0.0
3.5
retrieving all client classes
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات بازیابی تمام کلاس‌های کلاینت صادر می‌شود..SS MYSQL_CB_GET_ALL_CLIENT_CLASSES6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی تمام کلاس‌های کلاینت است.
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS4
0.0
3.5
retrieving all global parameters
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات بازیابی تمام پارامترهای سراسری صادر می‌شود.
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی تمام پارامترهای سراسری است.
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS6
0.0
3.5
retrieving all global parameters
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات بازیابی تمام پارامترهای سراسری صادر می‌شود.
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی تمام پارامترهای سراسری است.
MYSQL_CB_GET_ALL_OPTIONS4
0.0
3.5
retrieving all options
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات بازیابی تمام گزینه‌ها صادر می‌شود.
MYSQL_CB_GET_ALL_OPTIONS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی تمام گزینه‌ها است.
MYSQL_CB_GET_ALL_OPTIONS6
0.0
3.5
retrieving all options
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات بازیابی تمام گزینه‌ها صادر می‌شود.
MYSQL_CB_GET_ALL_OPTIONS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی تمام گزینه‌ها است.
MYSQL_CB_GET_ALL_OPTION_DEFS4
0.0
3.5
retrieving all option definitions
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات بازیابی تمام تعاریف گزینه‌ها صادر می‌شود..SS MYSQL_CB_GET_ALL_OPTION_DEFS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ یک عملیات برای دریافت تمام تعاریف گزینه است.
MYSQL_CB_GET_ALL_OPTION_DEFS6
0.0
3.5
retrieving all option definitions
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی جهت دریافت تمام تعاریف گزینه صادر می‌شود.
MYSQL_CB_GET_ALL_OPTION_DEFS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ یک عملیات برای دریافت تمام تعاریف گزینه است.
MYSQL_CB_GET_ALL_SERVERS4
0.0
3.5
retrieving all servers
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی جهت دریافت تمام سرورهای DHCPv4
صادر می‌شود.
MYSQL_CB_GET_ALL_SERVERS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ یک عملیات برای دریافت تمام سرورهای DHCPv4
است.
MYSQL_CB_GET_ALL_SERVERS6
0.0
3.5
retrieving all DHCPv6 servers
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی جهت دریافت تمام سرورهای DHCPv6
صادر می‌شود.
MYSQL_CB_GET_ALL_SERVERS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ یک عملیات برای دریافت تمام سرورهای DHCPv6
است.
MYSQL_CB_GET_ALL_SHARED_NETWORKS4
0.0
3.5
retrieving all shared networks
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی جهت دریافت تمام شبکه‌های مشترک صادر می‌شود.
MYSQL_CB_GET_ALL_SHARED_NETWORKS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ یک عملیات برای دریافت تمام شبکه‌های مشترک است.
MYSQL_CB_GET_ALL_SHARED_NETWORKS6
0.0
3.5
retrieving all shared networks
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی جهت دریافت تمام شبکه‌های مشترک صادر می‌شود..SS MYSQL_CB_GET_ALL_SHARED_NETWORKS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات بازیابی تمام شبکه‌های مشترک است.
MYSQL_CB_GET_ALL_SUBNETS4
0.0
3.5
retrieving all subnets
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات بازیابی تمام زیرشبکه‌ها.
MYSQL_CB_GET_ALL_SUBNETS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات بازیابی تمام زیرشبکه‌ها است.
MYSQL_CB_GET_ALL_SUBNETS6
0.0
3.5
retrieving all subnets
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات بازیابی تمام زیرشبکه‌ها.
MYSQL_CB_GET_ALL_SUBNETS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات بازیابی تمام زیرشبکه‌ها است.
MYSQL_CB_GET_CLIENT_CLASS4
0.0
3.5
retrieving client class: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات بازیابی یک کلاس کلاینت.
MYSQL_CB_GET_CLIENT_CLASS6
0.0
3.5
retrieving client class: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات بازیابی یک کلاس کلاینت.
MYSQL_CB_GET_GLOBAL_PARAMETER4
0.0
3.5
retrieving global parameter: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات بازیابی پارامتر سراسری.
MYSQL_CB_GET_GLOBAL_PARAMETER6
0.0
3.5
retrieving global parameter: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات بازیابی پارامتر سراسری.
MYSQL_CB_GET_HOST4
0.0
3.5
get host
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات بازیابی میزبان..SS MYSQL_CB_GET_HOST6
0.0
3.5
get host
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی برای بازیابی میزبان (host).
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES4
0.0
3.5
retrieving modified client classes from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی برای بازیابی کلاس‌های کلاینت تغییریافته از زمان مشخص‌شده.
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات بازیابی کلاس‌های کلاینت تغییریافته از زمان مشخص‌شده است.
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES6
0.0
3.5
retrieving modified client classes from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی برای بازیابی کلاس‌های کلاینت تغییریافته از زمان مشخص‌شده.
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات بازیابی کلاس‌های کلاینت تغییریافته از زمان مشخص‌شده است.
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4
0.0
3.5
retrieving modified global parameters from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی برای بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده.
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده است.
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6
0.0
3.5
retrieving modified global parameters from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی برای بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده.
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجه عملیات بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده است.
MYSQL_CB_GET_MODIFIED_OPTIONS4
0.0
3.5
retrieving modified options from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی برای بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده..SS MYSQL_CB_GET_MODIFIED_OPTIONS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ یک عملیات برای بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده را نشان می‌دهد.
MYSQL_CB_GET_MODIFIED_OPTIONS6
0.0
3.5
retrieving modified options from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود.
MYSQL_CB_GET_MODIFIED_OPTIONS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ یک عملیات برای بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده را نشان می‌دهد.
MYSQL_CB_GET_MODIFIED_OPTION_DEFS4
0.0
3.5
retrieving modified option definitions from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود.
MYSQL_CB_GET_MODIFIED_OPTION_DEFS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ یک عملیات برای بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده را نشان می‌دهد.
MYSQL_CB_GET_MODIFIED_OPTION_DEFS6
0.0
3.5
retrieving modified option definitions from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود.
MYSQL_CB_GET_MODIFIED_OPTION_DEFS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ یک عملیات برای بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده را نشان می‌دهد.
MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS4
0.0
3.5
retrieving modified shared networks from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی شبکه‌های مشترک تغییریافته از زمان مشخص‌شده صادر می‌شود.
MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ یک عملیات برای بازیابی شبکه‌های مشترک تغییریافته از زمان مشخص‌شده را نشان می‌دهد.
MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS6
0.0
3.5
retrieving modified shared networks from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی شبکه‌های مشترک تغییریافته از زمان مشخص‌شده صادر می‌شود..SS MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجه یک عملیات برای دریافت شبکه‌های اشتراکی تغییریافته از زمانی مشخص را نشان می‌دهد.
MYSQL_CB_GET_MODIFIED_SUBNETS4
0.0
3.5
retrieving modified subnets from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات دریافت زیرشبکه‌های تغییریافته از زمانی مشخص صادر می‌شود.
MYSQL_CB_GET_MODIFIED_SUBNETS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجه یک عملیات برای دریافت زیرشبکه‌های تغییریافته از زمانی مشخص را نشان می‌دهد.
MYSQL_CB_GET_MODIFIED_SUBNETS6
0.0
3.5
retrieving modified subnets from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات دریافت زیرشبکه‌های تغییریافته از زمانی مشخص صادر می‌شود.
MYSQL_CB_GET_MODIFIED_SUBNETS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجه یک عملیات برای دریافت زیرشبکه‌های تغییریافته از زمانی مشخص را نشان می‌دهد.
MYSQL_CB_GET_OPTION4
0.0
3.5
retrieving option code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات دریافت گزینه صادر می‌شود.
MYSQL_CB_GET_OPTION6
0.0
3.5
retrieving option code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات دریافت گزینه صادر می‌شود.
MYSQL_CB_GET_OPTION_DEF4
0.0
3.5
retrieving option definition code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات دریافت تعریف گزینه صادر می‌شود.
MYSQL_CB_GET_OPTION_DEF6
0.0
3.5
retrieving option definition code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات دریافت تعریف گزینه صادر می‌شود.
MYSQL_CB_GET_PORT4
0.0
3.5
get port
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات دریافت پورت صادر می‌شود..SS MYSQL_CB_GET_PORT6
0.0
3.5
get port
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی درگاه صادر می‌شود.
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES4
0.0
3.5
retrieving audit entries from: %1 %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی ورودی‌های بازرسی از زمان و شناسهٔ مشخص‌شده صادر می‌شود.
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات بازیابی ورودی‌های بازرسی از زمان مشخص‌شده را نشان می‌دهد.
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES6
0.0
3.5
retrieving audit entries from: %1 %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی ورودی‌های بازرسی از زمان و شناسهٔ مشخص‌شده صادر می‌شود.
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات بازیابی ورودی‌های بازرسی از زمان مشخص‌شده را نشان می‌دهد.
MYSQL_CB_GET_SERVER4
0.0
3.5
retrieving DHCPv4 server: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی اطلاعات سرور DHCPv4 صادر می‌شود.
MYSQL_CB_GET_SERVER6
0.0
3.5
retrieving DHCPv6 server: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی اطلاعات سرور DHCPv6 صادر می‌شود.
MYSQL_CB_GET_SHARED_NETWORK4
0.0
3.5
retrieving shared network: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی شبکهٔ مشترک صادر می‌شود.
MYSQL_CB_GET_SHARED_NETWORK6
0.0
3.5
retrieving shared network: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی شبکهٔ مشترک صادر می‌شود.
MYSQL_CB_GET_SHARED_NETWORK_SUBNETS4
0.0
3.5
retrieving shared network: %1 subnets
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی زیرشبکه‌های شبکهٔ مشترک صادر می‌شود..SS MYSQL_CB_GET_SHARED_NETWORK_SUBNETS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی زیرشبکه‌های شبکهٔ اشتراکی (shared network) است.
MYSQL_CB_GET_SHARED_NETWORK_SUBNETS6
0.0
3.5
retrieving shared network: %1 subnets
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات برای بازیابی زیرشبکه‌های شبکهٔ اشتراکی (shared network) صادر می‌شود.
MYSQL_CB_GET_SHARED_NETWORK_SUBNETS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی زیرشبکه‌های شبکهٔ اشتراکی (shared network) است.
MYSQL_CB_GET_SUBNET4_BY_PREFIX
0.0
3.5
retrieving subnet by prefix: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات برای بازیابی زیرشبکه بر اساس پیشوند (prefix) صادر می‌شود.
MYSQL_CB_GET_SUBNET4_BY_SUBNET_ID
0.0
3.5
retrieving subnet by subnet id: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات برای بازیابی زیرشبکه بر اساس شناسهٔ زیرشبکه (subnet id) صادر می‌شود.
MYSQL_CB_GET_SUBNET6_BY_PREFIX
0.0
3.5
retrieving subnet by prefix: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات برای بازیابی زیرشبکه بر اساس پیشوند (prefix) صادر می‌شود.
MYSQL_CB_GET_SUBNET6_BY_SUBNET_ID
0.0
3.5
retrieving subnet by subnet id: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات برای بازیابی زیرشبکه بر اساس شناسهٔ زیرشبکه (subnet id) صادر می‌شود.
MYSQL_CB_GET_TYPE4
0.0
3.5
get type
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات برای بازیابی نوع (type) صادر می‌شود.
MYSQL_CB_GET_TYPE6
0.0
3.5
get type
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات برای بازیابی نوع (type) صادر می‌شود.
MYSQL_CB_NO_TLS
0.0
3.5
TLS was required but is not used
168u
168u
این پیام خطا زمانی صادر می‌شود که TLS برای اتصال الزامی بوده اما TLS استفاده نشده است..SS MYSQL_CB_RECONNECT_ATTEMPT_FAILED4
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطای صادرشده هنگامی که تلاش برای برقراری مجدد اتصال با شکست مواجه شده است.
MYSQL_CB_RECONNECT_ATTEMPT_FAILED6
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطای صادرشده هنگامی که تلاش برای برقراری مجدد اتصال با شکست مواجه شده است.
MYSQL_CB_RECONNECT_ATTEMPT_SCHEDULE4
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاعاتی صادرشده هنگامی که سرور در حال زمان‌بندی تلاش بعدی برای اتصال مجدد
به پایگاه داده است. این رویداد هنگامی رخ می‌دهد که ارتباط سرور با پایگاه داده قطع شده باشد
و سرور تلاش کند به‌طور خودکار دوباره متصل شود.
MYSQL_CB_RECONNECT_ATTEMPT_SCHEDULE6
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاعاتی صادرشده هنگامی که سرور در حال زمان‌بندی تلاش بعدی برای اتصال مجدد
به پایگاه داده است. این رویداد هنگامی رخ می‌دهد که ارتباط سرور با پایگاه داده قطع شده باشد
و سرور تلاش کند به‌طور خودکار دوباره متصل شود.
MYSQL_CB_RECONNECT_FAILED4
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطای صادرشده هنگامی که سرور در برقراری مجدد اتصال ناموفق بوده است. قطع ارتباط
معمولاً یک مشکل در شبکه یا سرور پایگاه داده است.
MYSQL_CB_RECONNECT_FAILED6
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطای صادرشده هنگامی که سرور در برقراری مجدد اتصال ناموفق بوده است. قطع ارتباط
معمولاً یک مشکل در شبکه یا سرور پایگاه داده است.
MYSQL_CB_REGISTER_BACKEND_TYPE4
0.0
3.5
register backend
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگامی که عملیاتی برای ثبت backend فعال شده باشد.
MYSQL_CB_REGISTER_BACKEND_TYPE6
0.0
3.5
register backend
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگامی که عملیاتی برای ثبت backend فعال شده باشد.
MYSQL_CB_TLS_CIPHER
0.0
3.5
TLS cipher: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک اتصال جدید به MySQL با TLS ایجاد شود.
نام سایفر (cipher) مورد استفاده در TLS در لاگ ثبت می‌شود.
MYSQL_CB_UNREGISTER_BACKEND_TYPE4
0.0
3.5
unregister backend
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگامی که عملیاتی برای لغو ثبت backend فعال شده باشد..SS MYSQL_CB_UNREGISTER_BACKEND_TYPE6
0.0
3.5
unregister backend
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام فعال شدن عملیاتی برای لغو ثبت backend.
MYSQL_DEINIT_OK
0.0
3.5
unloading MySQL hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانهٔ قلاب‌های (hooks) مربوط به MySQL Backend با موفقیت تخلیه (unload) شده است.
MYSQL_FB_DB
0.0
3.5
opening MySQL log database: %1
168u
168u
این پیام اطلاع‌رسانی زمانی ثبت می‌شود که کتابخانهٔ قلاب ثبت وقایع قانونی (legal log hook library) در شرف باز کردن یک پایگاه‌دادهٔ لاگ MySQL است. پارامترهای اتصال شامل نام پایگاه‌داده و نام کاربری لازم برای دسترسی به آن (به‌جز گذرواژه در صورت وجود) ثبت می‌شوند.
MYSQL_HB_DB
0.0
3.5
opening MySQL hosts database: %1
168u
168u
این پیام اطلاع‌رسانی زمانی ثبت می‌شود که یک کارگزار DHCP (چه V4 و چه V6) در شرف باز کردن پایگاه‌دادهٔ میزبان‌های MySQL است. پارامترهای اتصال شامل نام پایگاه‌داده و نام کاربری لازم برای دسترسی به آن (به‌جز گذرواژه در صورت وجود) ثبت می‌شوند.
MYSQL_HB_DB_GET_VERSION
0.0
3.5
obtaining schema version information for the MySQL hosts database
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار در شرف دریافت اطلاعات نگارش طرح‌واره (schema version) از پایگاه‌دادهٔ میزبان‌های MySQL است.
MYSQL_HB_DB_READONLY
0.0
3.5
MySQL host database opened for read access only
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کاربر پایگاه‌دادهٔ MySQL را در حالت فقط‌خواندنی (read-only) پیکربندی کرده باشد. Kea قادر به درج یا ویرایش رزروهای میزبان (host reservations) نخواهد بود، اما می‌تواند موارد موجود را بازیابی کرده و آن‌ها را به کلاینت‌هایی که با کارگزار ارتباط برقرار می‌کنند اختصاص دهد.
MYSQL_HB_DB_RECONNECT_ATTEMPT_FAILED
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
MYSQL_HB_DB_RECONNECT_ATTEMPT_SCHEDULE
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاع‌رسانی که زمانی صادر می‌شود که کارگزار در حال زمان‌بندی تلاش بعدی برای اتصال مجدد به پایگاه‌داده است. این حالت زمانی رخ می‌دهد که اتصال کارگزار با پایگاه‌داده قطع شده باشد و در تلاش است به‌طور خودکار دوباره متصل شود.
MYSQL_HB_DB_RECONNECT_FAILED
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطایی که هنگام ناموفق بودن نهایی کارگزار در برقراری مجدد اتصال صادر می‌شود. قطعی اتصال معمولاً ناشی از مشکلات شبکه یا کارگزار پایگاه‌داده است.
MYSQL_HB_NO_TLS
0.0
3.5
TLS was required but is not used
168u
168u
این پیام خطا زمانی صادر می‌شود که TLS برای اتصال الزامی بوده اما استفاده نشده است..SS MYSQL_HB_TLS_CIPHER
0.0
3.5
TLS cipher: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که یک اتصال جدید به MySQL با TLS برقرار گردد.
نام TLS cipher ثبت می‌شود.
MYSQL_INIT_OK
0.0
3.5
loading MySQL hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانهٔ قلاب‌های (hooks) پشتیبان
MySQL با موفقیت بارگذاری شده است. لذت ببرید!
MYSQL_LB_ADD_ADDR4
0.0
3.5
adding IPv4 lease with address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام دیباگ هنگامی صادر می‌شود که سرور در آستانهٔ افزودن یک اجارهٔ IPv4
با نشانی مشخص‌شده به پایگاه‌دادهٔ پشتیبان MySQL باشد.
MYSQL_LB_ADD_ADDR6
0.0
3.5
adding IPv6 lease with address %1, lease type %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام دیباگ هنگامی صادر می‌شود که سرور در آستانهٔ افزودن یک اجارهٔ IPv6
با نشانی مشخص‌شده به پایگاه‌دادهٔ پشتیبان MySQL باشد.
MYSQL_LB_COMMIT
0.0
3.5
committing to MySQL database
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
کد یک فراخوانی commit صادر کرده است. تمام تراکنش‌های معلق در پایگاه‌داده
تثبیت (commit) خواهند شد. توجه داشته باشید که بسته به تنظیمات MySQL،
این تثبیت ممکن است لزوماً شامل نوشتن روی دیسک نباشد.
MYSQL_LB_DB
0.0
3.5
opening MySQL lease database: %1
168u
168u
این پیام اطلاع‌رسانی زمانی ثبت می‌شود که یک سرور DHCP (خواه نسخهٔ ۴ یا
نسخهٔ ۶) در آستانهٔ باز کردن پایگاه‌دادهٔ اجاره‌های MySQL باشد. پارامترهای
اتصال شامل نام پایگاه‌داده و نام کاربری لازم برای دسترسی به آن (اما نه
گذرواژه در صورت وجود) در گزارش ثبت می‌شوند.
MYSQL_LB_DB_RECONNECT_ATTEMPT_FAILED
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
MYSQL_LB_DB_RECONNECT_ATTEMPT_SCHEDULE
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاع‌رسانی صادرشده در هنگامی که سرور در حال زمان‌بندی تلاش بعدی برای
اتصال مجدد به پایگاه‌داده است. این وضعیت زمانی رخ می‌دهد که اتصال سرور به
پایگاه‌داده قطع شده باشد و در حال تلاش برای اتصال مجدد خودکار باشد.
MYSQL_LB_DB_RECONNECT_FAILED
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطایی که هنگام ناموفق بودن سرور در برقراری مجدد اتصال صادر می‌شود. قطع
ارتباط معمولاً به دلیل مشکلی در شبکه یا سرور پایگاه‌داده رخ می‌دهد.
MYSQL_LB_DELETED_EXPIRED_RECLAIMED
0.0
3.5
deleted %1 reclaimed leases from the database
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور تعدادی از اجاره‌های بازپس‌گرفته‌شده
را از پایگاه‌داده حذف کرده باشد. تعداد اجاره‌های حذف‌شده در متن پیام گنجانده
می‌شود..SS MYSQL_LB_DELETED_SUBNET4_ID
0.0
3.5
deleted %1 leases that match subnet ID %2.
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال حذف اجاره‌هایی است که با
شناسه زیرشبکه مربوطه مطابقت دارند.
MYSQL_LB_DELETED_SUBNET6_ID
0.0
3.5
deleted %1 leases that match subnet ID %2.
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال حذف اجاره‌هایی است که با
شناسه زیرشبکه مربوطه مطابقت دارند.
MYSQL_LB_DELETE_ADDR4
0.0
3.5
deleting lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال تلاش برای حذف اجاره مربوط به
نشانی مشخص‌شده از پایگاه‌داده MySQL است.
MYSQL_LB_DELETE_ADDR6
0.0
3.5
deleting lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال تلاش برای حذف اجاره مربوط به
نشانی مشخص‌شده از پایگاه‌داده MySQL است.
MYSQL_LB_DELETE_EXPIRED_RECLAIMED4
0.0
3.5
deleting reclaimed IPv4 leases that expired more than %1 seconds ago
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال حذف اجاره‌های بازپس‌گرفته‌شده DHCPv4
است که بیش از یک بازه زمانی مشخص منقضی شده‌اند.
آرگومان، مدت‌زمانی است که Kea پس از انقضای یک اجاره بازپس‌گرفته‌شده، پیش از اقدام به حذف آن منتظر می‌ماند.
MYSQL_LB_DELETE_EXPIRED_RECLAIMED6
0.0
3.5
deleting reclaimed IPv6 leases that expired more than %1 seconds ago
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال حذف اجاره‌های بازپس‌گرفته‌شده DHCPv6
است که بیش از یک بازه زمانی مشخص منقضی شده‌اند.
آرگومان، مدت‌زمانی است که Kea پس از انقضای یک اجاره بازپس‌گرفته‌شده، پیش از اقدام به حذف آن منتظر می‌ماند.
MYSQL_LB_GET4
0.0
3.5
obtaining all IPv4 leases
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال تلاش برای دریافت تمامی
اجاره‌های IPv4 از پایگاه‌داده MySQL است.
MYSQL_LB_GET6
0.0
3.5
obtaining all IPv6 leases
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال تلاش برای دریافت تمامی
اجاره‌های IPv6 از پایگاه‌داده MySQL است.
MYSQL_LB_GET_ADDR4
0.0
3.5
obtaining IPv4 lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال تلاش برای دریافت یک
اجاره IPv4 برای نشانی مشخص‌شده از پایگاه‌داده MySQL است..SS MYSQL_LB_GET_ADDR6
0.0
3.5
obtaining IPv6 lease for address %1, lease type %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا یک اجارهٔ IPv6 را از پایگاه دادهٔ MySQL برای نشانی مشخص‌شده دریافت کند.
MYSQL_LB_GET_CLIENTID
0.0
3.5
obtaining IPv4 leases for client ID %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv4 را از پایگاه دادهٔ MySQL برای کلاینتی با شناسهٔ کلاینت (client ID) مشخص‌شده دریافت کند.
MYSQL_LB_GET_DUID
0.0
3.5
obtaining IPv6 lease for duid %1,
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا یک اجارهٔ IPv6 را از پایگاه دادهٔ MySQL برای duid مشخص‌شده دریافت کند.
MYSQL_LB_GET_EXPIRED4
0.0
3.5
obtaining maximum %1 of expired IPv4 leases
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا اجاره‌های منقضی‌شدهٔ IPv4 را به منظور بازپس‌گیری آن‌ها دریافت کند. حداکثر تعداد اجاره‌های قابل بازیابی در این پیام ثبت می‌شود.
MYSQL_LB_GET_EXPIRED6
0.0
3.5
obtaining maximum %1 of expired IPv6 leases
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا اجاره‌های منقضی‌شدهٔ IPv6 را به منظور بازپس‌گیری آن‌ها دریافت کند. حداکثر تعداد اجاره‌های قابل بازیابی در این پیام ثبت می‌شود.
MYSQL_LB_GET_HOSTNAME4
0.0
3.5
obtaining IPv4 leases for hostname %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv4 را از پایگاه دادهٔ MySQL برای کلاینتی با hostname مشخص‌شده دریافت کند.
MYSQL_LB_GET_HOSTNAME6
0.0
3.5
obtaining IPv6 leases for hostname %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv6 را از پایگاه دادهٔ MySQL برای کلاینتی با hostname مشخص‌شده دریافت کند.
MYSQL_LB_GET_HWADDR4
0.0
3.5
obtaining IPv4 leases for hardware address %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv4 را از پایگاه دادهٔ MySQL برای کلاینتی با نشانی سخت‌افزاری (hardware address) مشخص‌شده دریافت کند.
MYSQL_LB_GET_HWADDR6
0.0
3.5
obtaining IPv6 leases for hardware address %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv6 را از پایگاه دادهٔ MySQL برای کلاینتی با نشانی سخت‌افزاری (hardware address) مشخص‌شده دریافت کند..SS MYSQL_LB_GET_IAID_DUID
0.0
3.5
obtaining IPv6 leases for IAID %1, DUID %2, lease type %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند مجموعه‌ای از
اجاره‌های IPv6 را برای یک کلاینت با IAID (شناسهٔ انجمن هویت) و DUID (شناسهٔ
یکتای DHCP) مشخص‌شده از پایگاه‌دادهٔ MySQL دریافت کند.
MYSQL_LB_GET_IAID_SUBID_DUID
0.0
3.5
obtaining IPv6 leases for IAID %1, subnet ID %2, DUID %3, lease type %4
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند یک اجارهٔ IPv6
را برای یک کلاینت با IAID (شناسهٔ انجمن هویت)، subnet ID و DUID (شناسهٔ
یکتای DHCP) مشخص‌شده از پایگاه‌دادهٔ MySQL دریافت کند.
MYSQL_LB_GET_PAGE4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند صفحه‌ای از
اجاره‌ها را با شروع از نشانی مشخص‌شده دریافت کند.
MYSQL_LB_GET_PAGE6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند صفحه‌ای از
اجاره‌ها را با شروع از نشانی مشخص‌شده دریافت کند.
MYSQL_LB_GET_RELAYID4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2 with relay id %3 and cltt between %4 and %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند صفحه‌ای از
اجاره‌های IPv4 را با شروع از نشانی مشخص‌شده، با یک relay id و زمان تراکنش
کلاینت (cltt) بین تاریخ‌های آغاز و پایان دریافت کند.
MYSQL_LB_GET_RELAYID6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 with relay id %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند صفحه‌ای از
اجاره‌های IPv6 را با شروع از نشانی مشخص‌شده و دارای یک relay id دریافت کند.
MYSQL_LB_GET_REMOTEID4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2 with remote id %3 and cltt between %4 and %5
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند صفحه‌ای از
اجاره‌های IPv4 را با شروع از نشانی مشخص‌شده، با یک remote id و زمان تراکنش
کلاینت (cltt) بین تاریخ‌های آغاز و پایان دریافت کند.
MYSQL_LB_GET_REMOTEID6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 with remote id %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند صفحه‌ای از
اجاره‌های IPv6 را با شروع از نشانی مشخص‌شده و دارای یک remote id دریافت کند.
MYSQL_LB_GET_STATE4
0.0
3.5
obtaining IPv4 leases with state %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز تلاش می‌کند مجموعه‌ای از
اجاره‌های IPv4 را با وضعیت مشخص‌شده از پایگاه‌دادهٔ MySQL دریافت کند..SS MYSQL_LB_GET_STATE6
0.0
3.5
obtaining IPv6 leases with state %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای
از اجاره‌های IPv6 با وضعیت مشخص‌شده از پایگاه داده MySQL است.
MYSQL_LB_GET_STATE_SUBID4
0.0
3.5
obtaining IPv4 leases with state %1 in subnet %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای
از اجاره‌های IPv4 با وضعیت مشخص‌شده در زیرشبکه مشخص‌شده از پایگاه داده MySQL است.
MYSQL_LB_GET_STATE_SUBID6
0.0
3.5
obtaining IPv6 leases with state %1 in subnet %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت مجموعه‌ای
از اجاره‌های IPv6 با وضعیت مشخص‌شده در زیرشبکه مشخص‌شده از پایگاه داده MySQL است.
MYSQL_LB_GET_SUBID4
0.0
3.5
obtaining IPv4 leases for subnet ID %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت تمام
اجاره‌های IPv4 برای یک شناسه زیرشبکه داده‌شده از پایگاه داده MySQL است.
MYSQL_LB_GET_SUBID6
0.0
3.5
obtaining IPv6 leases for subnet ID %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت تمام
اجاره‌های IPv6 برای یک شناسه زیرشبکه داده‌شده از پایگاه داده MySQL است.
MYSQL_LB_GET_SUBID_CLIENTID
0.0
3.5
obtaining IPv4 lease for subnet ID %1 and client ID %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک
اجاره IPv4 از پایگاه داده MySQL برای کلاینتی با شناسه زیرشبکه (subnet ID)
و شناسه کلاینت (client ID) مشخص‌شده است.
MYSQL_LB_GET_SUBID_HWADDR
0.0
3.5
obtaining IPv4 lease for subnet ID %1 and hardware address %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک
اجاره IPv4 از پایگاه داده MySQL برای کلاینتی با شناسه زیرشبکه (subnet ID)
و نشانی سخت‌افزاری مشخص‌شده است.
MYSQL_LB_GET_SUBID_PAGE6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 for subnet ID %3
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای دریافت یک صفحه از
اجاره‌های IPv6 از پایگاه داده MySQL است که با نشانی مشخص‌شده برای شناسه زیرشبکه داده‌شده آغاز می‌شود.
MYSQL_LB_GET_VERSION
0.0
3.5
obtaining schema version information
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در آستانه دریافت اطلاعات
نسخه طرح‌واره (schema) از پایگاه داده MySQL است..SS MYSQL_LB_NEGATIVE_LEASES_STAT
0.0
3.5
شمارش مجدد اجاره‌ها مقدار منفی بازگرداند
168u
168u
این پیام هشدار زمانی صادر می‌شود که شمارش مجدد اجاره‌ها با استفاده از شمارنده‌ها
در پایگاه‌داده MySQL مقدار منفی بازگرداند. این امر نشان‌دهنده مشکلی است
که تنها با یک شمارش مجدد مستقیم و آفلاین روی پایگاه‌داده قابل رفع است.
این پیام فقط یک بار صادر می‌شود.
MYSQL_LB_NO_TLS
0.0
3.5
TLS الزامی بود اما استفاده نشده است
168u
168u
این پیام خطا زمانی صادر می‌شود که TLS برای اتصال الزامی بوده اما
از TLS استفاده نشده است.
MYSQL_LB_ROLLBACK
0.0
3.5
در حال بازگردانی پایگاه‌داده MySQL
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
کد یک فراخوانی rollback صادر کرده است. تمام تراکنش‌های معلق
بازگردانی خواهند شد و در پایگاه‌داده commit نمی‌شوند.
MYSQL_LB_SFLQ_CREATE_POOL4
0.0
3.5
ایجاد استخر shared-flq برای محدوده آدرس %1 - %2، شناسه زیرشبکه %3، ایجاد مجدد %4، ظرفیت %5
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور از بک‌اند اجاره درخواست کند داده‌های
اجاره آزاد مشترک را برای استخر توصیف‌شده در آرگومان‌ها ایجاد (مجدد) کند.
MYSQL_LB_SFLQ_CREATE_POOL6
0.0
3.5
ایجاد استخر shared-flq برای محدوده آدرس %1 - %2، نوع %3، طول واگذارشده: %4، شناسه زیرشبکه %5، ایجاد مجدد %6، ظرفیت %7
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور از بک‌اند اجاره درخواست کند داده‌های
اجاره آزاد مشترک را برای استخر توصیف‌شده در آرگومان‌ها ایجاد (مجدد) کند.
MYSQL_LB_SFLQ_PICK_LEASE4
0.0
3.5
انتخاب یک اجاره آزاد از محدوده آدرس %1 - %2
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور از بک‌اند اجاره یک
آدرس آزاد از استخر توصیف‌شده در آرگومان‌ها درخواست می‌کند.
MYSQL_LB_SFLQ_PICK_LEASE6
0.0
3.5
انتخاب یک اجاره آزاد از محدوده آدرس %1 - %2
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور از بک‌اند اجاره یک
اجاره آزاد از استخر توصیف‌شده در آرگومان‌ها درخواست می‌کند.
MYSQL_LB_SFLQ_POOL4_DELETE
0.0
3.5
حذف استخر V4 SFLQ با آدرس شروع %1 و آدرس پایان %2، force = %3
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور از بک‌اند اجاره درخواست کند
استخر v4 SFLQ (و داده‌های اجاره آزاد آن) را که با آدرس‌های شروع و پایان
داده‌شده مطابقت دارد حذف کند.
MYSQL_LB_SFLQ_POOL4_GET_ALL
0.0
3.5
واکشی تمام استخرهای V4 SFLQ
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور از بک‌اند اجاره فهرستی از تمام استخرهای v4 SFLQ را درخواست می‌کند.
MYSQL_LB_SFLQ_POOL4_GET_BY_RANGE
0.0
3.5
واکشی تمام استخرهای V4 SFLQ که با محدوده %1 و %2 هم‌پوشانی دارند
168u
168u
در سطح لاگ دیباگ ۵۰ ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور از بک‌اند اجاره
استخرهای v4 SFLQ را که با محدوده آدرس داده‌شده هم‌پوشانی دارند درخواست می‌کند..SS MYSQL_LB_SFLQ_POOL4_GET_BY_SUBNET
0.0
3.5
fetch all V4 SFLQ pools for subnet-id %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره،
فهرستی از تمام استخرهای v4 SFLQ متعلق به یک زیرشبکه را درخواست کند.
MYSQL_LB_SFLQ_POOL6_DELETE
0.0
3.5
delete the V6 SFLQ pool with start address %1 and end address %2, force = %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره بخواهد
استخر v6 SFLQ (و داده‌های اجاره‌های آزاد آن) را که با آدرس‌های شروع و پایان
داده‌شده مطابقت دارد، حذف کند.
MYSQL_LB_SFLQ_POOL6_GET_ALL
0.0
3.5
fetch all V6 SFLQ pools
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره،
فهرستی از تمام استخرهای v6 SFLQ را درخواست کند.
MYSQL_LB_SFLQ_POOL6_GET_BY_RANGE
0.0
3.5
fetch all V6 SFLQ pools that overlap the range %1 and %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره،
استخرهای v6 SFLQ را که با بازهٔ آدرس داده‌شده همپوشانی دارند درخواست کند.
MYSQL_LB_SFLQ_POOL6_GET_BY_SUBNET
0.0
3.5
fetch all V6 SFLQ pools for subnet-id %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره،
فهرستی از تمام استخرهای v6 SFLQ متعلق به یک زیرشبکه را درخواست کند.
MYSQL_LB_TLS_CIPHER
0.0
3.5
TLS cipher: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک اتصال جدید MySQL با TLS ایجاد شود.
نام رمز (cipher) TLS ثبت می‌شود.
MYSQL_LB_UPDATE_ADDR4
0.0
3.5
updating IPv4 lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای به‌روزرسانی
اجاره IPv4 از پایگاه داده MySQL برای آدرس مشخص‌شده باشد.
MYSQL_LB_UPDATE_ADDR6
0.0
3.5
updating IPv6 lease for address %1, lease type %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال تلاش برای به‌روزرسانی
اجاره IPv6 از پایگاه داده MySQL برای آدرس مشخص‌شده باشد.
MYSQL_LB_UPGRADE_EXTENDED_INFO4
0.0
3.5
upgrading IPv4 leases done in %1 pages with %2 updated leases
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
سرور اطلاعات گسترش‌یافته (extended info) را ارتقا داد. تعداد صفحات و شمارش نهایی
اجاره‌های به‌روزشده نمایش داده می‌شود.
MYSQL_LB_UPGRADE_EXTENDED_INFO4_ERROR
0.0
3.5
upgrading extending info for IPv4 lease at %1 failed with %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در ارتقای اطلاعات گسترش‌یافته (extended info) با شکست مواجه شود.
آدرس اجاره و پیام خطا نمایش داده می‌شوند..SS MYSQL_LB_UPGRADE_EXTENDED_INFO4_PAGE
0.0
3.5
upgrading IPv4 lease extended info at page %1 starting at %2 (updated %3)
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار اطلاعات تکمیلی (extended info) اجاره‌های IPv4 را ارتقا می‌دهد.
شمارهٔ صفحه، نشانی شروع، و تعداد اجاره‌هایی که تاکنون به‌روزرسانی شده‌اند
نمایش داده می‌شوند.
MYSQL_LB_UPGRADE_EXTENDED_INFO6
0.0
3.5
upgrading IPv6 leases done in %1 pages with %2 updated leases
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
کارگزار اطلاعات تکمیلی را ارتقا داد. تعداد صفحات و شمارش نهایی
اجاره‌های به‌روزرسانی‌شده نمایش داده می‌شوند.
MYSQL_LB_UPGRADE_EXTENDED_INFO6_ERROR
0.0
3.5
upgrading extending info for IPv6 lease at %1 failed with %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارگزار در ارتقای اطلاعات تکمیلی
یک اجاره با شکست مواجه شده باشد. نشانی اجاره و پیام خطا نمایش داده می‌شوند.
MYSQL_LB_UPGRADE_EXTENDED_INFO6_PAGE
0.0
3.5
upgrading IPv6 lease extended info at page %1 starting at %2 (updated %3)
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار اطلاعات تکمیلی اجاره‌های IPv6 را ارتقا می‌دهد.
شمارهٔ صفحه، نشانی شروع، و تعداد اجاره‌هایی که تاکنون به‌روزرسانی شده‌اند
نمایش داده می‌شوند.
NETCONF
NETCONF_BOOT_UPDATE_COMPLETED
0.0
3.5
Boot-update configuration completed for server %1
168u
168u
این پیام اطلاعاتی هنگامی صادر می‌شود که پیکربندی اولیه با استفاده از NETCONF
دریافت شده و با موفقیت روی کارگزار Kea اعمال شده باشد.
NETCONF_CONFIG_CHANGED_DETAIL
0.0
3.5
YANG configuration changed: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان‌دهندهٔ تغییر پیکربندی YANG است. قالب پیام
عبارت است از عملیات تغییر (created، modified، deleted یا moved) که به‌دنبال آن
xpathها و مقادیر گره‌های قدیمی و جدید می‌آیند.
NETCONF_CONFIG_CHANGE_EVENT
0.0
3.5
Received YANG configuration change %1 event
168u
168u
این پیام اطلاعاتی هنگامی صادر می‌شود که kea-netconf یک رویداد تغییر
پیکربندی YANG را دریافت کند. نوع رویداد چاپ می‌شود.
NETCONF_CONFIG_CHECK_FAIL
0.0
3.5
NETCONF configuration check failed: %1
168u
168u
این پیام خطا نشان می‌دهد که بررسی پیکربندی kea-netconf با شکست مواجه شده است.
جزئیات ارائه شده‌اند. ممکن است جزئیات بیش‌تر در مدخل‌های لاگ پیشین،
احتمالاً در سطوح پایین‌تر موجود باشد.
NETCONF_CONFIG_FAIL
0.0
3.5
NETCONF configuration failed: %1
168u
168u
این پیام خطا نشان می‌دهد که تلاش پیکربندی kea-netconf با شکست مواجه شده است.
جزئیات ارائه شده‌اند. ممکن است جزئیات بیش‌تر در مدخل‌های لاگ پیشین،
احتمالاً در سطوح پایین‌تر موجود باشد.
NETCONF_CONFIG_SYNTAX_WARNING
0.0
3.5
NETCONF configuration syntax warning: %1
168u
168u
این پیام هشدار نشان می‌دهد که پیکربندی NETCONF یک خطای نحوی جزئی داشته است.
خطا نمایش داده شد و تجزیهٔ پیکربندی ادامه یافت..SS NETCONF_CONTROL_SOCKET_INFO
0.0
3.5
the service: %1 started using control socket type: %2 %3
168u
168u
این پیام اطلاعاتی، جزئیات سوکت کنترلی استفاده‌شده برای سرویس مربوطه را ارائه می‌دهد. نام سرویس، نوع سوکت و جزئیات آن ثبت می‌شوند.
NETCONF_FAILED
0.0
3.5
application experienced a fatal error: %1
168u
168u
این یک پیام خطای مهلک است و زمانی صادر می‌شود که kea-netconf با خطایی غیرقابل‌بازیابی از درون حلقه رویداد (event loop) مواجه شود.
NETCONF_GET_CONFIG
0.0
3.5
got configuration from %1 server: %2
168u
168u
در سطح ثبت اشکال‌زدایی (debug) ۵۵ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که kea-netconf پیکربندی را از یک سرور Kea دریافت کرده است. نام سرور و پیکربندی دریافت‌شده چاپ می‌شوند.
NETCONF_GET_CONFIG_FAILED
0.0
3.5
getting configuration from %1 server failed: %2
168u
168u
این پیام خطا نشان می‌دهد که kea-netconf هنگام دریافت پیکربندی از یک سرور Kea دچار خطا شده است. اطمینان حاصل کنید که سرور فعال و در حال اجرا است، سوکت کنترلی مناسب برای آن تعریف شده است و پیکربندی سوکت کنترلی روی سرور با پیکربندی kea-netconf مطابقت دارد. نام سرور و خطا چاپ می‌شوند.
NETCONF_GET_CONFIG_STARTED
0.0
3.5
getting configuration from %1 server
168u
168u
این پیام اطلاعاتی نشان می‌دهد که kea-netconf در تلاش برای دریافت پیکربندی از یک سرور Kea است.
NETCONF_MODULE_CHANGE_INTERNAL_ERROR
0.0
3.5
an internal error occurred while processing changes for module %1: %2
168u
168u
این پیام خطا نشان می‌دهد که kea-netconf هنگام پردازش تغییرات ماژول‌ها توسط sysrepo با خطایی مواجه شده است. این وضعیت معمولاً پس از شکست در اعتبارسنجی پیکربندی رخ می‌دهد و قابل بازیابی است. نام ماژول و پیام خطای داخلی چاپ می‌شوند.
NETCONF_MODULE_MISSING_ERR
0.0
3.5
Missing essential module %1 in sysrepo
168u
168u
این پیام خطای مهلک نشان می‌دهد که ماژول ضروریِ مورد نیاز برای پیکربندی Netconf در مخزن sysrepo موجود نیست. نام ماژول چاپ می‌شود.
NETCONF_MODULE_MISSING_WARN
0.0
3.5
Missing module %1 in sysrepo
168u
168u
این پیام هشدار نشان می‌دهد که یک ماژول استفاده‌شده توسط Kea در مخزن sysrepo موجود نیست. نام ماژول چاپ می‌شود.
NETCONF_MODULE_REVISION_ERR
0.0
3.5
Essential module %1 does NOT have the right revision: expected %2, got %3
168u
168u
این پیام خطای مهلک نشان می‌دهد که ماژول ضروریِ مورد نیاز برای پیکربندی Netconf، نسخه بازنگری (revision) صحیحی در مخزن sysrepo ندارد. نام ماژول و نسخه‌های بازنگری مورد انتظار و موجود چاپ می‌شوند.
NETCONF_MODULE_REVISION_WARN
0.0
3.5
Module %1 does NOT have the right revision: expected %2, got %3
168u
168u
این پیام هشدار نشان می‌دهد که ماژول استفاده‌شده توسط Kea نسخه بازنگری (revision) صحیحی در مخزن sysrepo ندارد. نام ماژول و نسخه‌های بازنگری مورد انتظار و موجود چاپ می‌شوند..SS NETCONF_NOTIFICATION_INTERNAL_ERROR
0.0
3.5
an internal error occurred while sending an event notification for module %1: %2
168u
168u
این پیام خطا نشان می‌دهد که kea-netconf هنگام ارسال یک اعلان رخداد توسط sysrepo با خطا مواجه شده است.
این خطا مهلک نیست و امکان بازیابی از آن وجود دارد.
نام ماژول و پیام خطای داخلی چاپ می‌شوند.
NETCONF_NOTIFICATION_RECEIVED
0.0
3.5
Received notification of type %1 for module %2: '%3'
168u
168u
این پیام اطلاع‌رسانی، هرگونه اعلان YANG را که توسط سرور ارسال شده، به kea-netconf تحویل گردیده و سپس به کلاینت‌های مشترک‌شده بازفرستاده شده است، ثبت می‌کند. برای انجام این کار، kea-netconf خود را به‌عنوان یک کلاینت در تمامی اعلان‌های ماژول پیکربندی‌شده مشترک می‌کند.
NETCONF_NOT_SUBSCRIBED_TO_NOTIFICATIONS
0.0
3.5
subscribing to notifications for %1 server with %2 module failed: %3
168u
168u
این پیام هشدار نشان می‌دهد که kea-netconf هنگام اشتراک در اعلان‌های یک سرور Kea با خطا مواجه شده است. محتمل‌ترین علت این است که مدل مشترک‌شده توسط kea-netconf فاقد هرگونه گره اعلان است، اما ممکن است دلایل غیرمنتظره دیگری نیز وجود داشته باشد.
نام سرور، نام ماژول و متن خطا چاپ می‌شوند.
NETCONF_RUN_EXIT
0.0
3.5
application is exiting the event loop
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 0 ثبت می‌شود.
این یک پیام اشکال‌زدایی است که هنگام خروج kea-netconf از حلقه رخداد (event loop) خود صادر می‌شود. این یک مرحله عادی در طول فرآیند خاموش شدن kea-netconf است.
NETCONF_SET_CONFIG
0.0
3.5
set configuration to %1 server: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که kea-netconf پیکربندی را روی یک سرور Kea اعمال کرده است. نام سرور و پیکربندی اعمال‌شده چاپ می‌شوند.
NETCONF_SET_CONFIG_FAILED
0.0
3.5
setting configuration to %1 server failed: %2
168u
168u
این پیام خطا نشان می‌دهد که kea-netconf هنگام اعمال پیکربندی روی یک سرور Kea با خطا مواجه شده است. اطمینان حاصل کنید که سرور فعال و در حال اجرا است، سوکت کنترلی مناسب برای آن تعریف شده و پیکربندی سوکت کنترلی روی سرور با kea-netconf مطابقت دارد. نام سرور و متن خطا چاپ می‌شوند.
NETCONF_SET_CONFIG_STARTED
0.0
3.5
setting configuration to %1 server
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که kea-netconf در تلاش برای اعمال پیکربندی روی یک سرور Kea است.
NETCONF_STARTED
0.0
3.5
kea-netconf (version %1) started
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که kea-netconf تمامی اطلاعات پیکربندی را پردازش کرده و آماده آغاز به کار است.
نسخه برنامه نیز چاپ می‌شود.
NETCONF_SUBSCRIBE_CONFIG
0.0
3.5
subscribing configuration changes for %1 server with %2 module
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که kea-netconf در تلاش است تا برای تغییرات پیکربندی یک سرور Kea با ماژول مشخص‌شده مشترک شود. نام سرور و ماژول چاپ می‌شوند..SS NETCONF_SUBSCRIBE_CONFIG_FAILED
0.0
3.5
subscribe configuration changes for %1 server with %2 module failed: %3
168u
168u
این پیام خطا نشان می‌دهد که kea-netconf هنگام اشتراک در تغییرات پیکربندی برای یک سرور Kea با خطا مواجه شده است. نام‌های سرور و ماژول و همچنین خطا چاپ می‌شوند.
NETCONF_SUBSCRIBE_NOTIFICATIONS
0.0
3.5
subscribing to notifications for %1 server with %2 module
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که kea-netconf در حال تلاش برای اشتراک در اعلان‌های یک سرور Kea است. نام سرور و نام ماژول چاپ می‌شوند.
NETCONF_UPDATE_CONFIG
0.0
3.5
updating configuration with %1 server: %2
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که kea-netconf پیکربندی یک سرور Kea را به‌روزرسانی می‌کند. نام سرور و پیکربندی به‌روزرسانی‌شده چاپ می‌شوند.
NETCONF_UPDATE_CONFIG_COMPLETED
0.0
3.5
completed updating configuration for %1 server
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که kea-netconf با موفقیت پیکربندی یک سرور Kea را به‌روزرسانی کرده است.
NETCONF_UPDATE_CONFIG_FAILED
0.0
3.5
updating configuration with %1 server: %2
168u
168u
این پیام خطا نشان می‌دهد که kea-netconf هنگام به‌روزرسانی پیکربندی یک سرور Kea با خطا مواجه شده است. این شامل رد شدن پیکربندی توسط یک سرور Kea در زمان تلاش برای اعمال آن نیز می‌شود. نام سرور و خطا چاپ می‌شوند.
NETCONF_UPDATE_CONFIG_STARTED
0.0
3.5
started updating configuration for %1 server
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که kea-netconf در حال تلاش برای به‌روزرسانی پیکربندی یک سرور Kea است.
NETCONF_VALIDATE_CONFIG
0.0
3.5
validating configuration with %1 server: %2
168u
168u
در سطح لاگ اشکال‌زدایی 55 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که kea-netconf در حال اعتبارسنجی پیکربندی با یک سرور Kea است. نام سرور و پیکربندی اعتبارسنجی‌شده چاپ می‌شوند.
NETCONF_VALIDATE_CONFIG_COMPLETED
0.0
3.5
completed validating configuration for %1 server
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که kea-netconf با موفقیت پیکربندی را با یک سرور Kea اعتبارسنجی کرده است.
NETCONF_VALIDATE_CONFIG_FAILED
0.0
3.5
validating configuration with %1 server got an error: %2
168u
168u
این پیام خطا نشان می‌دهد که kea-netconf هنگام اعتبارسنجی پیکربندی با یک سرور Kea با خطا مواجه شده است. این پیام زمانی تولید می‌شود که در حین تلاش برای اعتبارسنجی پیکربندی دریافتی، یک استثنا (exception) رخ دهد. ممکن است توضیحات تکمیلی به عنوان پارامتر ارائه شود. همچنین می‌توانید به پیام‌های لاگ پیشین نگاهی بیندازید. نام سرور و خطا چاپ می‌شوند.
NETCONF_VALIDATE_CONFIG_REJECTED
0.0
3.5
validating configuration with %1 server was rejected: %2
168u
168u
این پیام هشدار نشان می‌دهد که kea-netconf هنگام اعتبارسنجی پیکربندی با یک سرور Kea با خطا مواجه شده است. این پیام زمانی چاپ می‌شود که پیکربندی در حین پردازش عادی رد شده باشد. ممکن است توضیحات تکمیلی به عنوان پارامتر ارائه شود. همچنین می‌توانید به پیام‌های لاگ پیشین نگاهی بیندازید. نام سرور و خطا چاپ می‌شوند..SS NETCONF_VALIDATE_CONFIG_STARTED
0.0
3.5
started validating configuration for %1 server
168u
168u
این پیام اطلاعاتی نشان می‌دهد که kea-netconf در حال تلاش برای اعتبارسنجی
پیکربندی با یک کارساز Kea است.
PERFMON
PERFMON_ALARM_CLEARED
0.0
3.5
Alarm for %1 has been cleared, reported mean duration %2 is now below low-water-ms: %3
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که میانگین مدت‌زمان گزارش‌شده برای
هشداری که فعال شده بود، به زیر مقدار پارامتر low-water-ms آن کاهش یابد.
آرگومان‌ها کلید هشدار و آخرین میانگین گزارش‌شده را با جزئیات شرح می‌دهند.
PERFMON_ALARM_TRIGGERED
0.0
3.5
Alarm for %1 has been triggered since %2, reported mean duration %3 exceeds high-water-ms: %4
168u
168u
این پیام هشدار زمانی صادر می‌شود که میانگین مدت‌زمان گزارش‌شده برای یک هشدار
از مقدار high-water-ms آن فراتر رود. تا زمانی که میانگین‌های گزارش‌شده بالاتر از
مقدار low-water-ms باقی بمانند، هشدار در وضعیت فعال باقی می‌ماند و این پیام هر
alarm-report-secs یک‌بار تکرار خواهد شد. آرگومان‌ها کلید هشدار، زمانی که هشدار
نخستین بار فعال شد، آخرین میانگین گزارش‌شده و مقدار high-water-ms را مشخص می‌کنند.
PERFMON_CMDS_CONTROL_ERROR
0.0
3.5
perfmon-control command processing failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب PerfMon در پردازش یک دستور
perfmon-control با خطا مواجه شود. آرگومان، خطای دستور را توضیح می‌دهد.
PERFMON_CMDS_CONTROL_OK
0.0
3.5
perfmon-control command success: active monitoring: %1, stats-mgr-reporting: %2
168u
168u
این گزارش اطلاعاتی زمانی صادر می‌شود که دستور perfmon-control با موفقیت
پایش فعال (active monitoring) و/یا گزارش‌دهی statistics mgr را فعال/غیرفعال کرده باشد.
آرگومان‌ها وضعیت فعلی هر دو را نشان می‌دهند.
PERFMON_CMDS_GET_ALL_DURATIONS_ERROR
0.0
3.5
perfmon-get-all-durations command processing failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب PerfMon در پردازش یک دستور
perfmon-get-all-durations با خطا مواجه شود. آرگومان، خطای دستور را توضیح می‌دهد.
PERFMON_CMDS_GET_ALL_DURATIONS_OK
0.0
3.5
perfmon-get-all-durations returning %1 durations
168u
168u
این گزارش اطلاعاتی زمانی صادر می‌شود که دستور perfmon-get-all-durations با موفقیت
به پایان رسیده باشد. آرگومان شامل تعداد مدت‌زمان‌های بازگردانده‌شده است.
PERFMON_DEINIT_OK
0.0
3.5
unloading PerfMon hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های PerfMon با موفقیت
تخلیه (حذف) شده است.
PERFMON_DHCP4_PKT_EVENTS
0.0
3.5
query: %1 events=[%2]
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی پس از پردازش یک پرس‌وجوی ورودی DHCPv4 صادر می‌شود؛
آرگومان‌ها عبارتند از برچسب پرس‌وجو و رونوشت پشته رویداد بسته
(packet event stack) مربوط به پرس‌وجو..SS PERFMON_DHCP4_PKT_PROCESS_ERROR
0.0
3.5
Packet event stack was not processed for query %1, reason %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پشته رویداد پرس‌وجو پردازش نشود.
این مورد به احتمال زیاد یک خطای برنامه‌نویسی است و باید گزارش شود.
آرگومان‌ها پرس‌وجو و دلیل پردازش نشدن آن را مشخص می‌کنند.
این خطاها نباید بر عملیات عادی سرور تأثیر بگذارند.
PERFMON_DHCP4_SOCKET_RECEIVED_TIME_SUPPORT
0.0
3.5
Kernel supports socket received time? %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی پس از (باز)پیکربندی صادر می‌شود و نشان می‌دهد آیا
فیلتر بسته‌ای که توسط kea-dhcp4 استفاده می‌شود می‌تواند برچسب زمانی
دریافت بسته توسط هسته را برای ثبت رویدادهای SOCKET_RECEIVED ارائه دهد
یا خیر. اگر نتواند، perfmon همچنان کار خواهد کرد اما داده‌ای برای تعیین
مدت‌زمان انتظار در بافر هسته در دسترس نخواهد داشت.
PERFMON_DHCP6_PKT_EVENTS
0.0
3.5
query: %1 events=[%2]
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی پس از پردازش یک پرس‌وجوی ورودی DHCPv6 صادر می‌شود؛
آرگومان‌ها برچسب پرس‌وجو و تخلیه پشته رویداد بسته مربوط به پرس‌وجو هستند.
PERFMON_DHCP6_PKT_PROCESS_ERROR
0.0
3.5
Packet event stack was not processed for query %1, reason %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پشته رویداد پرس‌وجو پردازش نشود.
این مورد به احتمال زیاد یک خطای برنامه‌نویسی است و باید گزارش شود.
آرگومان‌ها پرس‌وجو و دلیل پردازش نشدن آن را مشخص می‌کنند.
این خطاها نباید بر عملیات عادی سرور تأثیر بگذارند.
PERFMON_DHCP6_SOCKET_RECEIVED_TIME_SUPPORT
0.0
3.5
Kernel supports socket received time? %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی پس از (باز)پیکربندی صادر می‌شود و نشان می‌دهد آیا
فیلتر بسته‌ای که توسط kea-dhcp6 استفاده می‌شود می‌تواند برچسب زمانی
دریافت بسته توسط هسته را برای ثبت رویدادهای SOCKET_RECEIVED ارائه دهد
یا خیر. اگر نتواند، perfmon همچنان کار خواهد کرد اما داده‌ای برای تعیین
مدت‌زمان انتظار در بافر هسته در دسترس نخواهد داشت.
PERFMON_INIT_FAILED
0.0
3.5
loading PerfMon hooks library failed: %1
168u
168u
این پیام خطا بیانگر وجود خطایی هنگام بارگذاری کتابخانه قلاب‌های PerfMon
است. جزئیات خطا به عنوان آرگومان پیام گزارش ارائه شده است.
PERFMON_INIT_OK
0.0
3.5
loading PerfMon hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های PerfMon با موفقیت
بارگذاری شده است. لذت ببرید!
PGSQL
PGSQL_CB_CREATE_UPDATE_BY_POOL_OPTION4
0.0
3.5
create or update option pool start: %1 pool end: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیاتی برای ایجاد یا به‌روزرسانی گزینه بر اساس استخر صادر می‌شود.
PGSQL_CB_CREATE_UPDATE_BY_POOL_OPTION6
0.0
3.5
create or update option pool start: %1 pool end: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیاتی برای ایجاد یا به‌روزرسانی گزینه بر اساس استخر صادر می‌شود..SS PGSQL_CB_CREATE_UPDATE_BY_PREFIX_OPTION6
0.0
3.5
create or update option prefix: %1 prefix len: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینه بر اساس پیشوند (prefix) فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION4
0.0
3.5
create or update option by subnet id: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینه بر اساس subnet id فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION6
0.0
3.5
create or update option by subnet id: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینه بر اساس subnet id فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_CLIENT_CLASS4
0.0
3.5
create or update client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی کلاس کلاینت (client class) فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_CLIENT_CLASS6
0.0
3.5
create or update client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی کلاس کلاینت (client class) فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER4
0.0
3.5
create or update global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی پارامتر سراسری فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER6
0.0
3.5
create or update global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی پارامتر سراسری فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_OPTION4
0.0
3.5
create or update option
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینه فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_OPTION6
0.0
3.5
create or update option
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی گزینه فعال شده باشد.
PGSQL_CB_CREATE_UPDATE_OPTION_DEF4
0.0
3.5
create or update option definition: %1 code: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که عملیاتی برای ایجاد یا به‌روزرسانی تعریف گزینه فعال شده باشد..SS PGSQL_CB_CREATE_UPDATE_OPTION_DEF6
0.0
3.5
create or update option definition: %1 code: %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی تعریف گزینه (option definition) آغاز شود.
PGSQL_CB_CREATE_UPDATE_SERVER4
0.0
3.5
create or update server: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی اطلاعات
سرور DHCPv4 آغاز شود.
PGSQL_CB_CREATE_UPDATE_SERVER6
0.0
3.5
create or update server: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی اطلاعات
سرور DHCPv6 آغاز شود.
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK4
0.0
3.5
create or update shared network: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی شبکه مشترک (shared network) آغاز شود.
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK6
0.0
3.5
create or update shared network: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی شبکه مشترک (shared network) آغاز شود.
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION4
0.0
3.5
create or update shared network: %1 option
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی گزینه شبکه مشترک آغاز شود.
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION6
0.0
3.5
create or update shared network: %1 option
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی گزینه شبکه مشترک آغاز شود.
PGSQL_CB_CREATE_UPDATE_SUBNET4
0.0
3.5
create or update subnet: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی زیرشبکه (subnet) آغاز شود.
PGSQL_CB_CREATE_UPDATE_SUBNET6
0.0
3.5
create or update subnet: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای ایجاد یا به‌روزرسانی زیرشبکه (subnet) آغاز شود.
PGSQL_CB_DELETE_ALL_CLIENT_CLASSES4
0.0
3.5
delete all client classes
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی زمانی صادر می‌شود که اقدامی برای حذف تمام کلاس‌های کلاینت (client classes) آغاز شود..SS PGSQL_CB_DELETE_ALL_CLIENT_CLASSES4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجهٔ عملیات حذف تمام کلاس‌های کلاینت است.
PGSQL_CB_DELETE_ALL_CLIENT_CLASSES6
0.0
3.5
delete all client classes
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام کلاس‌های کلاینت صادر می‌شود.
PGSQL_CB_DELETE_ALL_CLIENT_CLASSES6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجهٔ عملیات حذف تمام کلاس‌های کلاینت است.
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4
0.0
3.5
delete all global parameters
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام پارامترهای سراسری صادر می‌شود.
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجهٔ عملیات حذف تمام پارامترهای سراسری است.
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6
0.0
3.5
delete all global parameters
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام پارامترهای سراسری صادر می‌شود.
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجهٔ عملیات حذف تمام پارامترهای سراسری است.
PGSQL_CB_DELETE_ALL_OPTION_DEFS4
0.0
3.5
delete all option definitions
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام تعاریف گزینه‌ها صادر می‌شود.
PGSQL_CB_DELETE_ALL_OPTION_DEFS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهنده نتیجهٔ عملیات حذف تمام تعاریف گزینه‌ها است.
PGSQL_CB_DELETE_ALL_OPTION_DEFS6
0.0
3.5
delete all option definitions
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف تمام تعاریف گزینه‌ها صادر می‌شود..SS PGSQL_CB_DELETE_ALL_OPTION_DEFS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام تعاریف گزینه‌ها را نشان می‌دهد.
PGSQL_CB_DELETE_ALL_SERVERS4
0.0
3.5
delete all DHCPv4 servers
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف تمام سرورها صادر می‌شود.
PGSQL_CB_DELETE_ALL_SERVERS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام سرورها را نشان می‌دهد.
PGSQL_CB_DELETE_ALL_SERVERS6
0.0
3.5
delete all DHCPv6 servers
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف تمام سرورها صادر می‌شود.
PGSQL_CB_DELETE_ALL_SERVERS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام سرورها را نشان می‌دهد.
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS4
0.0
3.5
delete all shared networks
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف تمام شبکه‌های مشترک صادر می‌شود.
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام شبکه‌های مشترک را نشان می‌دهد.
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS6
0.0
3.5
delete all shared networks
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف تمام شبکه‌های مشترک صادر می‌شود.
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تمام شبکه‌های مشترک را نشان می‌دهد.
PGSQL_CB_DELETE_ALL_SUBNETS4
0.0
3.5
delete all subnets
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف تمام زیرشبکه‌ها صادر می‌شود..SS PGSQL_CB_DELETE_ALL_SUBNETS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف تمام زیرشبکه‌ها است.
PGSQL_CB_DELETE_ALL_SUBNETS6
0.0
3.5
delete all subnets
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف تمام زیرشبکه‌ها صادر می‌شود.
PGSQL_CB_DELETE_ALL_SUBNETS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف تمام زیرشبکه‌ها است.
PGSQL_CB_DELETE_BY_POOL_OPTION4
0.0
3.5
delete pool start: %1 pool end: %2 option code: %3 space: %4
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف گزینه بر اساس استخر صادر می‌شود.
PGSQL_CB_DELETE_BY_POOL_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس استخر است.
PGSQL_CB_DELETE_BY_POOL_OPTION6
0.0
3.5
delete pool start: %1 pool end: %2 option code: %3 space: %4
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف گزینه بر اساس استخر صادر می‌شود.
PGSQL_CB_DELETE_BY_POOL_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس استخر است.
PGSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6
0.0
3.5
delete prefix: %1 prefix len: %2 option code: %3 space: %4
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف گزینه بر اساس پیشوند صادر می‌شود.
PGSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس پیشوند است.
PGSQL_CB_DELETE_BY_PREFIX_SUBNET4
0.0
3.5
delete subnet by prefix: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فراخوانی عملیات حذف زیرشبکه بر اساس پیشوند صادر می‌شود..SS PGSQL_CB_DELETE_BY_PREFIX_SUBNET4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه بر اساس پیشوند است.
PGSQL_CB_DELETE_BY_PREFIX_SUBNET6
0.0
3.5
delete subnet by prefix: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف زیرشبکه بر اساس پیشوند صادر می‌شود.
PGSQL_CB_DELETE_BY_PREFIX_SUBNET6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه بر اساس پیشوند است.
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION4
0.0
3.5
delete by subnet id: %1 option code: %2 space: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه صادر می‌شود.
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه است.
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION6
0.0
3.5
delete by subnet id: %1 option code: %2 space: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه صادر می‌شود.
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف گزینه بر اساس شناسهٔ زیرشبکه است.
PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4
0.0
3.5
delete subnet by subnet id: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه صادر می‌شود.
PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه است.
PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6
0.0
3.5
delete subnet by subnet id: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه صادر می‌شود..SS PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات حذف زیرشبکه بر اساس شناسهٔ زیرشبکه (subnet id) است.
PGSQL_CB_DELETE_CLIENT_CLASS4
0.0
3.5
delete client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف کلاس کلاینت (client class) صادر می‌شود.
PGSQL_CB_DELETE_CLIENT_CLASS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات حذف کلاس کلاینت (client class) است.
PGSQL_CB_DELETE_CLIENT_CLASS6
0.0
3.5
delete client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف کلاس کلاینت (client class) صادر می‌شود.
PGSQL_CB_DELETE_CLIENT_CLASS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات حذف کلاس کلاینت (client class) است.
PGSQL_CB_DELETE_GLOBAL_PARAMETER4
0.0
3.5
delete global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف پارامتر سراسری (global parameter) صادر می‌شود.
PGSQL_CB_DELETE_GLOBAL_PARAMETER4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات حذف پارامتر سراسری (global parameter) است.
PGSQL_CB_DELETE_GLOBAL_PARAMETER6
0.0
3.5
delete global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف پارامتر سراسری (global parameter) صادر می‌شود.
PGSQL_CB_DELETE_GLOBAL_PARAMETER6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات حذف پارامتر سراسری (global parameter) است.
PGSQL_CB_DELETE_OPTION4
0.0
3.5
delete option code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات حذف گزینه (option) صادر می‌شود..SS PGSQL_CB_DELETE_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف گزینه را نشان می‌دهد.
PGSQL_CB_DELETE_OPTION6
0.0
3.5
delete option code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده در هنگام آغاز عملیات حذف گزینه.
PGSQL_CB_DELETE_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف گزینه را نشان می‌دهد.
PGSQL_CB_DELETE_OPTION_DEF4
0.0
3.5
delete option definition code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده در هنگام آغاز عملیات حذف تعریف گزینه.
PGSQL_CB_DELETE_OPTION_DEF4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تعریف گزینه را نشان می‌دهد.
PGSQL_CB_DELETE_OPTION_DEF6
0.0
3.5
delete option definition code: %1 space: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده در هنگام آغاز عملیات حذف تعریف گزینه.
PGSQL_CB_DELETE_OPTION_DEF6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف تعریف گزینه را نشان می‌دهد.
PGSQL_CB_DELETE_SERVER4
0.0
3.5
delete DHCPv4 server: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده در هنگام آغاز عملیات حذف یک کارساز.
PGSQL_CB_DELETE_SERVER4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف یک کارساز را نشان می‌دهد.
PGSQL_CB_DELETE_SERVER6
0.0
3.5
delete DHCPv6 server: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده در هنگام آغاز عملیات حذف یک کارساز..SS PGSQL_CB_DELETE_SERVER6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف یک سرور را نشان می‌دهد.
PGSQL_CB_DELETE_SHARED_NETWORK4
0.0
3.5
delete shared network: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف شبکهٔ مشترک (shared network).
PGSQL_CB_DELETE_SHARED_NETWORK4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف شبکهٔ مشترک را نشان می‌دهد.
PGSQL_CB_DELETE_SHARED_NETWORK6
0.0
3.5
delete shared network: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف شبکهٔ مشترک (shared network).
PGSQL_CB_DELETE_SHARED_NETWORK6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف شبکهٔ مشترک را نشان می‌دهد.
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION4
0.0
3.5
delete shared network: %1 option code: %2 space: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف گزینهٔ شبکهٔ مشترک.
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف گزینهٔ شبکهٔ مشترک را نشان می‌دهد.
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION6
0.0
3.5
delete shared network: %1 option code: %2 space: %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف گزینهٔ شبکهٔ مشترک.
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف گزینهٔ شبکهٔ مشترک را نشان می‌دهد.
PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4
0.0
3.5
delete shared network: %1 subnets
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیات حذف زیرشبکه‌های شبکهٔ مشترک..SS PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف زیرشبکه‌های شبکهٔ مشترک (shared network) را نشان می‌دهد.
PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6
0.0
3.5
delete shared network: %1 subnets
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات حذف زیرشبکه‌های شبکهٔ مشترک (shared network).
PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6_RESULT
0.0
3.5
deleted: %1 entries
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات حذف زیرشبکه‌های شبکهٔ مشترک (shared network) را نشان می‌دهد.
PGSQL_CB_GET_ALL_CLIENT_CLASSES4
0.0
3.5
retrieving all client classes
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات بازیابی تمام کلاس‌های کلاینت.
PGSQL_CB_GET_ALL_CLIENT_CLASSES4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات بازیابی تمام کلاس‌های کلاینت را نشان می‌دهد.
PGSQL_CB_GET_ALL_CLIENT_CLASSES6
0.0
3.5
retrieving all client classes
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات بازیابی تمام کلاس‌های کلاینت.
PGSQL_CB_GET_ALL_CLIENT_CLASSES6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات بازیابی تمام کلاس‌های کلاینت را نشان می‌دهد.
PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS4
0.0
3.5
retrieving all global parameters
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات بازیابی تمام پارامترهای سراسری.
PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نتیجهٔ عملیات بازیابی تمام پارامترهای سراسری را نشان می‌دهد.
PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS6
0.0
3.5
retrieving all global parameters
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیات بازیابی تمام پارامترهای سراسری..SS PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نمایانگر نتیجه عملیاتی برای بازیابی تمامی پارامترهای سراسری است.
PGSQL_CB_GET_ALL_OPTIONS4
0.0
3.5
retrieving all options
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی تمامی گزینه‌ها صادر می‌شود.
PGSQL_CB_GET_ALL_OPTIONS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نمایانگر نتیجه عملیاتی برای بازیابی تمامی گزینه‌ها است.
PGSQL_CB_GET_ALL_OPTIONS6
0.0
3.5
retrieving all options
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی تمامی گزینه‌ها صادر می‌شود.
PGSQL_CB_GET_ALL_OPTIONS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نمایانگر نتیجه عملیاتی برای بازیابی تمامی گزینه‌ها است.
PGSQL_CB_GET_ALL_OPTION_DEFS4
0.0
3.5
retrieving all option definitions
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی تمامی تعاریف گزینه‌ها صادر می‌شود.
PGSQL_CB_GET_ALL_OPTION_DEFS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نمایانگر نتیجه عملیاتی برای بازیابی تمامی تعاریف گزینه‌ها است.
PGSQL_CB_GET_ALL_OPTION_DEFS6
0.0
3.5
retrieving all option definitions
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی تمامی تعاریف گزینه‌ها صادر می‌شود.
PGSQL_CB_GET_ALL_OPTION_DEFS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نمایانگر نتیجه عملیاتی برای بازیابی تمامی تعاریف گزینه‌ها است.
PGSQL_CB_GET_ALL_SERVERS4
0.0
3.5
retrieving all servers
168u
168u
در سطح وقایع‌نگاری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی تمامی سرورهای DHCPv4 صادر می‌شود..SS PGSQL_CB_GET_ALL_SERVERS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی همهٔ کارگزارهای DHCPv4
است.
PGSQL_CB_GET_ALL_SERVERS6
0.0
3.5
retrieving all DHCPv6 servers
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی همهٔ کارگزارهای DHCPv6
صادر می‌شود.
PGSQL_CB_GET_ALL_SERVERS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی همهٔ کارگزارهای DHCPv6
است.
PGSQL_CB_GET_ALL_SHARED_NETWORKS4
0.0
3.5
retrieving all shared networks
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی همهٔ شبکه‌های اشتراکی صادر می‌شود.
PGSQL_CB_GET_ALL_SHARED_NETWORKS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی همهٔ شبکه‌های اشتراکی است.
PGSQL_CB_GET_ALL_SHARED_NETWORKS6
0.0
3.5
retrieving all shared networks
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی همهٔ شبکه‌های اشتراکی صادر می‌شود.
PGSQL_CB_GET_ALL_SHARED_NETWORKS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی همهٔ شبکه‌های اشتراکی است.
PGSQL_CB_GET_ALL_SUBNETS4
0.0
3.5
retrieving all subnets
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی همهٔ زیرشبکه‌ها صادر می‌شود.
PGSQL_CB_GET_ALL_SUBNETS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی همهٔ زیرشبکه‌ها است.
PGSQL_CB_GET_ALL_SUBNETS6
0.0
3.5
retrieving all subnets
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام آغاز عملیاتی برای بازیابی همهٔ زیرشبکه‌ها صادر می‌شود..SS PGSQL_CB_GET_ALL_SUBNETS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهنده نتیجه عملیات بازیابی تمام زیرشبکه‌ها.
PGSQL_CB_GET_CLIENT_CLASS4
0.0
3.5
retrieving client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی یک کلاس کلاینت صادر می‌شود.
PGSQL_CB_GET_CLIENT_CLASS6
0.0
3.5
retrieving client class: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی یک کلاس کلاینت صادر می‌شود.
PGSQL_CB_GET_GLOBAL_PARAMETER4
0.0
3.5
retrieving global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی پارامتر سراسری صادر می‌شود.
PGSQL_CB_GET_GLOBAL_PARAMETER6
0.0
3.5
retrieving global parameter: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی پارامتر سراسری صادر می‌شود.
PGSQL_CB_GET_HOST4
0.0
3.5
get host
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی میزبان صادر می‌شود.
PGSQL_CB_GET_HOST6
0.0
3.5
get host
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی میزبان صادر می‌شود.
PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES4
0.0
3.5
retrieving modified client classes from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی کلاس‌های کلاینت تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهنده نتیجه عملیاتی برای بازیابی کلاس‌های کلاینت تغییریافته از زمان مشخص‌شده.
PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES6
0.0
3.5
retrieving modified client classes from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیاتی برای بازیابی کلاس‌های کلاینت تغییریافته از زمان مشخص‌شده صادر می‌شود..SS PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی کلاس‌های کلاینتِ تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4
0.0
3.5
retrieving modified global parameters from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6
0.0
3.5
retrieving modified global parameters from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی پارامترهای سراسری تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_OPTIONS4
0.0
3.5
retrieving modified options from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_OPTIONS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_OPTIONS6
0.0
3.5
retrieving modified options from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_OPTIONS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که نشان‌دهندهٔ نتیجهٔ عملیات بازیابی گزینه‌های تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_OPTION_DEFS4
0.0
3.5
retrieving modified option definitions from: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام راه‌اندازی عملیات بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود..SS PGSQL_CB_GET_MODIFIED_OPTION_DEFS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_OPTION_DEFS6
0.0
3.5
retrieving modified option definitions from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_OPTION_DEFS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات بازیابی تعاریف گزینه‌های تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS4
0.0
3.5
retrieving modified shared networks from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات بازیابی شبکه‌های اشتراکی تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات بازیابی شبکه‌های اشتراکی تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS6
0.0
3.5
retrieving modified shared networks from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات بازیابی شبکه‌های اشتراکی تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات بازیابی شبکه‌های اشتراکی تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_SUBNETS4
0.0
3.5
retrieving modified subnets from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات بازیابی زیرشبکه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود.
PGSQL_CB_GET_MODIFIED_SUBNETS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که بیانگر نتیجهٔ عملیات بازیابی زیرشبکه‌های تغییریافته از زمان مشخص‌شده است.
PGSQL_CB_GET_MODIFIED_SUBNETS6
0.0
3.5
retrieving modified subnets from: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که هنگام فعال شدن عملیات بازیابی زیرشبکه‌های تغییریافته از زمان مشخص‌شده صادر می‌شود..SS PGSQL_CB_GET_MODIFIED_SUBNETS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیاتی برای بازیابی زیرشبکه‌های تغییریافته از زمانی مشخص.
PGSQL_CB_GET_OPTION4
0.0
3.5
retrieving option code: %1 space: %2
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی گزینه.
PGSQL_CB_GET_OPTION6
0.0
3.5
retrieving option code: %1 space: %2
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی گزینه.
PGSQL_CB_GET_OPTION_DEF4
0.0
3.5
retrieving option definition code: %1 space: %2
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی تعریف گزینه.
PGSQL_CB_GET_OPTION_DEF6
0.0
3.5
retrieving option definition code: %1 space: %2
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی تعریف گزینه.
PGSQL_CB_GET_PORT4
0.0
3.5
get port
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی پورت.
PGSQL_CB_GET_PORT6
0.0
3.5
get port
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی پورت.
PGSQL_CB_GET_RECENT_AUDIT_ENTRIES4
0.0
3.5
retrieving audit entries from: %1 %2
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی مدخل‌های بازرسی از یک زمان و شناسه مشخص.
PGSQL_CB_GET_RECENT_AUDIT_ENTRIES4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیاتی برای بازیابی مدخل‌های بازرسی از زمانی مشخص.
PGSQL_CB_GET_RECENT_AUDIT_ENTRIES6
0.0
3.5
retrieving audit entries from: %1 %2
168u
168u
در سطح گزارش‌گیری اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام راه‌اندازی عملیاتی برای بازیابی مدخل‌های بازرسی از یک زمان و شناسه مشخص..SS PGSQL_CB_GET_RECENT_AUDIT_ENTRIES6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیاتی جهت بازیابی مدخل‌های بازرسی (audit entries) از یک زمان مشخص.
PGSQL_CB_GET_SERVER4
0.0
3.5
retrieving DHCPv4 server: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی جهت بازیابی اطلاعات یک سرور DHCPv4.
PGSQL_CB_GET_SERVER6
0.0
3.5
retrieving DHCPv6 server: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی جهت بازیابی اطلاعات یک سرور DHCPv6.
PGSQL_CB_GET_SHARED_NETWORK4
0.0
3.5
retrieving shared network: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی جهت بازیابی شبکهٔ اشتراکی (shared network).
PGSQL_CB_GET_SHARED_NETWORK6
0.0
3.5
retrieving shared network: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی جهت بازیابی شبکهٔ اشتراکی (shared network).
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS4
0.0
3.5
retrieving shared network: %1 subnets
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی جهت بازیابی زیرشبکه‌های شبکهٔ اشتراکی.
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS4_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیاتی جهت بازیابی زیرشبکه‌های شبکهٔ اشتراکی.
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS6
0.0
3.5
retrieving shared network: %1 subnets
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی جهت بازیابی زیرشبکه‌های شبکهٔ اشتراکی.
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS6_RESULT
0.0
3.5
retrieving: %1 elements
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی نشان‌دهندهٔ نتیجهٔ عملیاتی جهت بازیابی زیرشبکه‌های شبکهٔ اشتراکی.
PGSQL_CB_GET_SUBNET4_BY_PREFIX
0.0
3.5
retrieving subnet by prefix: %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادرشده هنگام آغاز عملیاتی جهت بازیابی زیرشبکه بر اساس پیشوند (prefix)..SS PGSQL_CB_GET_SUBNET4_BY_SUBNET_ID
0.0
3.5
retrieving subnet by subnet id: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که با آغاز عملیاتی برای بازیابی زیرشبکه بر اساس شناسهٔ زیرشبکه صادر می‌شود.
PGSQL_CB_GET_SUBNET6_BY_PREFIX
0.0
3.5
retrieving subnet by prefix: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که با آغاز عملیاتی برای بازیابی زیرشبکه بر اساس پیشوند صادر می‌شود.
PGSQL_CB_GET_SUBNET6_BY_SUBNET_ID
0.0
3.5
retrieving subnet by subnet id: %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که با آغاز عملیاتی برای بازیابی زیرشبکه بر اساس شناسهٔ زیرشبکه صادر می‌شود.
PGSQL_CB_GET_TYPE4
0.0
3.5
get type
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که با آغاز عملیاتی برای بازیابی نوع صادر می‌شود.
PGSQL_CB_GET_TYPE6
0.0
3.5
get type
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی که با آغاز عملیاتی برای بازیابی نوع صادر می‌شود.
PGSQL_CB_RECONNECT_ATTEMPT_FAILED4
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
PGSQL_CB_RECONNECT_ATTEMPT_FAILED6
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
PGSQL_CB_RECONNECT_ATTEMPT_SCHEDULE4
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاعاتی که هنگامی صادر می‌شود که کارساز در حال زمان‌بندی تلاش بعدی برای اتصال مجدد به پایگاه داده است. این وضعیت زمانی رخ می‌دهد که کارساز ارتباط خود را با پایگاه داده از دست داده و در حال تلاش برای اتصال مجددِ خودکار است.
PGSQL_CB_RECONNECT_ATTEMPT_SCHEDULE6
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاعاتی که هنگامی صادر می‌شود که کارساز در حال زمان‌بندی تلاش بعدی برای اتصال مجدد به پایگاه داده است. این وضعیت زمانی رخ می‌دهد که کارساز ارتباط خود را با پایگاه داده از دست داده و در حال تلاش برای اتصال مجددِ خودکار است.
PGSQL_CB_RECONNECT_FAILED4
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطایی که هنگامی صادر می‌شود که کارساز در اتصال مجدد ناموفق بوده است. قطع اتصال معمولاً ناشی از مشکلات شبکه یا کارساز پایگاه داده است..SS PGSQL_CB_RECONNECT_FAILED6
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطایی که هنگام عدم موفقیت کارساز در اتصال مجدد صادر می‌شود. قطع ارتباط معمولاً ناشی از مشکلات شبکه یا کارساز پایگاه داده است.
PGSQL_CB_REGISTER_BACKEND_TYPE4
0.0
3.5
register backend
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادر شده هنگام راه‌اندازی عملیاتی برای ثبت backend.
PGSQL_CB_REGISTER_BACKEND_TYPE6
0.0
3.5
register backend
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادر شده هنگام راه‌اندازی عملیاتی برای ثبت backend.
PGSQL_CB_UNREGISTER_BACKEND_TYPE4
0.0
3.5
unregister backend
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادر شده هنگام راه‌اندازی عملیاتی برای لغو ثبت backend.
PGSQL_CB_UNREGISTER_BACKEND_TYPE6
0.0
3.5
unregister backend
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
پیام اشکال‌زدایی صادر شده هنگام راه‌اندازی عملیاتی برای لغو ثبت backend.
PGSQL_DEINIT_OK
0.0
3.5
unloading PostgreSQL hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه قلاب‌های (hooks) بک‌اند PostgreSQL با موفقیت تخلیه (unload) شده است.
PGSQL_FB_DB
0.0
3.5
opening PostgreSQL log database: %1
168u
168u
این پیام اطلاع‌رسانی زمانی ثبت می‌شود که کتابخانه قلاب legal log در شرف باز کردن یک پایگاه داده لاگ PostgreSQL باشد. پارامترهای اتصال، از جمله نام پایگاه داده و نام کاربری مورد نیاز برای دسترسی به آن (به‌جز گذرواژه، در صورت وجود)، در لاگ ثبت می‌شوند.
PGSQL_HB_DB
0.0
3.5
opening PostgreSQL hosts database: %1
168u
168u
این پیام اطلاع‌رسانی زمانی ثبت می‌شود که یک کارساز DHCP (نسخه V4 یا V6) در شرف باز کردن پایگاه داده میزبان‌های PostgreSQL باشد. پارامترهای اتصال، از جمله نام پایگاه داده و نام کاربری مورد نیاز برای دسترسی به آن (به‌جز گذرواژه، در صورت وجود)، در لاگ ثبت می‌شوند.
PGSQL_HB_DB_GET_VERSION
0.0
3.5
obtaining schema version information for the PostgreSQL hosts database
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در شرف دریافت اطلاعات نگارش شمای پایگاه داده میزبان‌های PostgreSQL است.
PGSQL_HB_DB_READONLY
0.0
3.5
PostgreSQL host database opened for read access only
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کاربر پایگاه داده PostgreSQL را در حالت فقط‌خواندنی (read-only) پیکربندی کرده باشد. Kea قادر به درج یا تغییر رزروهای میزبان نخواهد بود، اما می‌تواند موارد موجود را بازیابی کرده و به کلاینت‌هایی که با کارساز ارتباط برقرار می‌کنند اختصاص دهد..SS PGSQL_HB_DB_RECONNECT_ATTEMPT_FAILED
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
PGSQL_HB_DB_RECONNECT_ATTEMPT_SCHEDULE
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاعاتی که هنگام زمان‌بندی تلاش بعدی کارساز برای اتصال مجدد به پایگاه داده صادر می‌شود. این حالت زمانی رخ می‌دهد که ارتباط کارساز با پایگاه داده قطع شده و تلاش برای اتصال مجدد خودکار در جریان باشد.
PGSQL_HB_DB_RECONNECT_FAILED
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
پیام خطایی که هنگام شکست کارساز در برقراری مجدد اتصال صادر می‌شود. قطع ارتباط معمولاً به دلیل مشکلات شبکه یا کارساز پایگاه داده رخ می‌دهد.
PGSQL_INIT_OK
0.0
3.5
loading PostgreSQL hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های (hooks) پس‌زمینه PostgreSQL با موفقیت بارگذاری شده است. لذت ببرید!
PGSQL_LB_ADD_ADDR4
0.0
3.5
adding IPv4 lease with address %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در شرف افزودن یک اجاره (lease) IPv4 با نشانی مشخص‌شده به پایگاه داده پس‌زمینه PostgreSQL است.
PGSQL_LB_ADD_ADDR6
0.0
3.5
adding IPv6 lease with address %1, lease type %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در شرف افزودن یک اجاره (lease) IPv6 با نشانی مشخص‌شده به پایگاه داده پس‌زمینه PostgreSQL است.
PGSQL_LB_COMMIT
0.0
3.5
committing to PostgreSQL database
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
کد یک فراخوانی commit صادر کرده است. تمام تراکنش‌های معلق در پایگاه داده اعمال (commit) خواهند شد. توجه داشته باشید که بسته به تنظیمات PostgreSQL، ممکن است commit شامل نوشتن مستقیم روی دیسک نباشد.
PGSQL_LB_DB
0.0
3.5
opening PostgreSQL lease database: %1
168u
168u
این پیام اطلاعاتی زمانی ثبت می‌شود که یک کارساز DHCP (نسخه V4 یا V6) در آستانه باز کردن پایگاه داده اجاره‌های PostgreSQL باشد. پارامترهای اتصال، از جمله نام پایگاه داده و نام کاربری مورد نیاز برای دسترسی به آن (به‌جز گذرواژه، در صورت وجود) ثبت می‌شوند.
PGSQL_LB_DB_RECONNECT_ATTEMPT_FAILED
0.0
3.5
database reconnect failed: %1
168u
168u
پیام خطایی که هنگام ناموفق بودن تلاش برای اتصال مجدد صادر می‌شود.
PGSQL_LB_DB_RECONNECT_ATTEMPT_SCHEDULE
0.0
3.5
scheduling attempt %1 of %2 in %3 milliseconds
168u
168u
پیام اطلاعاتی که هنگام زمان‌بندی تلاش بعدی کارساز برای اتصال مجدد به پایگاه داده صادر می‌شود. این حالت زمانی رخ می‌دهد که ارتباط کارساز با پایگاه داده قطع شده و تلاش برای اتصال مجدد خودکار در جریان باشد..SS PGSQL_LB_DB_RECONNECT_FAILED
0.0
3.5
maximum number of database reconnect attempts: %1, has been exhausted without success
168u
168u
یک پیام خطا که هنگام ناموفق بودن تلاش سرور برای برقراری مجدد اتصال صادر می‌شود. از دست رفتن اتصال معمولاً ناشی از یک مشکل در شبکه یا سرور پایگاه داده است.
PGSQL_LB_DELETED_SUBNET4_ID
0.0
3.5
deleted %1 leases that match subnet ID %2.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال حذف اجاره‌هایی است که با شناسه زیرشبکه (subnet ID) مربوطه مطابقت دارند.
PGSQL_LB_DELETED_SUBNET6_ID
0.0
3.5
deleted %1 leases that match subnet ID %2.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال حذف اجاره‌هایی است که با شناسه زیرشبکه (subnet ID) مربوطه مطابقت دارند.
PGSQL_LB_DELETE_ADDR4
0.0
3.5
deleting lease for address %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا اجاره آدرس مشخص‌شده را از پایگاه داده PostgreSQL حذف کند.
PGSQL_LB_DELETE_ADDR6
0.0
3.5
deleting lease for address %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا اجاره آدرس مشخص‌شده را از پایگاه داده PostgreSQL حذف کند.
PGSQL_LB_DELETE_EXPIRED_RECLAIMED4
0.0
3.5
deleting reclaimed IPv4 leases that expired more than %1 seconds ago
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال حذف اجاره‌های بازپس‌گرفته‌شده DHCPv4 است که از انقضای آن‌ها بیش از یک بازه زمانی مشخص گذشته است.
آرگومان، مدت زمانی است که Kea پس از منقضی شدن یک اجاره بازپس‌گرفته‌شده، پیش از در نظر گرفتن حذف آن، منتظر می‌ماند.
PGSQL_LB_DELETE_EXPIRED_RECLAIMED6
0.0
3.5
deleting reclaimed IPv6 leases that expired more than %1 seconds ago
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در حال حذف اجاره‌های بازپس‌گرفته‌شده DHCPv6 است که از انقضای آن‌ها بیش از یک بازه زمانی مشخص گذشته است.
آرگومان، مدت زمانی است که Kea پس از منقضی شدن یک اجاره بازپس‌گرفته‌شده، پیش از در نظر گرفتن حذف آن، منتظر می‌ماند.
PGSQL_LB_GET4
0.0
3.5
obtaining all IPv4 leases
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا تمام اجاره‌های IPv4 را از پایگاه داده PostgreSQL دریافت کند.
PGSQL_LB_GET6
0.0
3.5
obtaining all IPv6 leases
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا تمام اجاره‌های IPv6 را از پایگاه داده PostgreSQL دریافت کند..SS PGSQL_LB_GET_ADDR4
0.0
3.5
obtaining IPv4 lease for address %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا یک اجارهٔ IPv4 را برای آدرس مشخص‌شده از پایگاه‌دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_ADDR6
0.0
3.5
obtaining IPv6 lease for address %1 (lease type %2)
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا یک اجارهٔ IPv6 را برای آدرس مشخص‌شده از پایگاه‌دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_CLIENTID
0.0
3.5
obtaining IPv4 leases for client ID %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv4 را برای کلاینتی با شناسهٔ مشخص‌شدهٔ کلاینت، از پایگاه‌دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_DUID
0.0
3.5
obtaining IPv6 leases for DUID %1,
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv6 را برای کلاینتی با DUID (شناسهٔ یکتای DHCP) مشخص‌شده، از پایگاه‌دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_EXPIRED4
0.0
3.5
obtaining maximum %1 of expired IPv4 leases
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا اجاره‌های منقضی‌شدهٔ IPv4 را برای بازپس‌گیری آن‌ها دریافت کند. حداکثر تعداد اجاره‌های قابل‌بازیابی در پیام ثبت می‌شود.
PGSQL_LB_GET_EXPIRED6
0.0
3.5
obtaining maximum %1 of expired IPv6 leases
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا اجاره‌های منقضی‌شدهٔ IPv6 را برای بازپس‌گیری آن‌ها دریافت کند. حداکثر تعداد اجاره‌های قابل‌بازیابی در پیام ثبت می‌شود.
PGSQL_LB_GET_HOSTNAME4
0.0
3.5
obtaining IPv4 leases for hostname %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv4 را برای کلاینتی با نام میزبان مشخص‌شده، از پایگاه‌دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_HOSTNAME6
0.0
3.5
obtaining IPv6 leases for hostname %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv6 را برای کلاینتی با نام میزبان مشخص‌شده، از پایگاه‌دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_HWADDR4
0.0
3.5
obtaining IPv4 leases for hardware address %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در تلاش است تا مجموعه‌ای از اجاره‌های IPv4 را برای کلاینتی با آدرس سخت‌افزاری مشخص‌شده، از پایگاه‌دادهٔ PostgreSQL دریافت کند..SS PGSQL_LB_GET_HWADDR6
0.0
3.5
obtaining IPv6 leases for hardware address %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا مجموعه‌ای
از اجاره‌های IPv6 را از پایگاه داده PostgreSQL برای کلاینتی با آدرس
سخت‌افزاری مشخص‌شده دریافت کند.
PGSQL_LB_GET_IAID_DUID
0.0
3.5
obtaining IPv4 leases for IAID %1 and DUID %2, lease type %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا مجموعه‌ای از اجاره‌های IPv6
را از پایگاه داده PostgreSQL برای کلاینتی با IAID (شناسه Identity Association ID)
و DUID (شناسه DHCP Unique Identifier) مشخص‌شده دریافت کند.
PGSQL_LB_GET_IAID_SUBID_DUID
0.0
3.5
obtaining IPv4 leases for IAID %1, subnet ID %2, DUID %3, and lease type %4
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا یک اجاره
IPv6 را از پایگاه داده PostgreSQL برای کلاینتی با IAID (شناسه Identity Association ID)،
subnet ID و DUID (شناسه DHCP Unique Identifier) مشخص‌شده دریافت کند.
PGSQL_LB_GET_PAGE4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا صفحه‌ای
از اجاره‌ها را که با آدرس مشخص‌شده شروع می‌شوند، دریافت کند.
PGSQL_LB_GET_PAGE6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا صفحه‌ای
از اجاره‌ها را که با آدرس مشخص‌شده شروع می‌شوند، دریافت کند.
PGSQL_LB_GET_RELAYID4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2 with relay id %3 and cltt between %4 and %5
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا صفحه‌ای از
اجاره‌های IPv4 را که با آدرس مشخص‌شده آغاز می‌شوند، با یک relay id و زمان
تراکنش کلاینت بین تاریخ‌های شروع و پایان دریافت کند.
PGSQL_LB_GET_RELAYID6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 with relay id %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا صفحه‌ای از
اجاره‌های IPv6 را که با آدرس مشخص‌شده آغاز می‌شوند، با یک relay id دریافت کند.
PGSQL_LB_GET_REMOTEID4
0.0
3.5
obtaining at most %1 IPv4 leases starting from address %2 with remote id %3 and cltt between %4 and %5
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا صفحه‌ای از
اجاره‌های IPv4 را که با آدرس مشخص‌شده آغاز می‌شوند، با یک remote id و زمان
تراکنش کلاینت بین تاریخ‌های شروع و پایان دریافت کند.
PGSQL_LB_GET_REMOTEID6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 with remote id %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تا صفحه‌ای از
اجاره‌های IPv6 را که با آدرس مشخص‌شده آغاز می‌شوند، با یک remote id دریافت کند..SS PGSQL_LB_GET_STATE4
0.0
3.5
obtaining IPv4 leases with state %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است مجموعه‌ای از
اجاره‌های IPv4 با وضعیت مشخص‌شده را از پایگاه دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_STATE6
0.0
3.5
obtaining IPv6 leases with state %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است مجموعه‌ای از
اجاره‌های IPv6 با وضعیت مشخص‌شده را از پایگاه دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_STATE_SUBID4
0.0
3.5
obtaining IPv4 leases with state %1 in subnet %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است مجموعه‌ای از
اجاره‌های IPv4 با وضعیت مشخص‌شده در زیرشبکهٔ تعیین‌شده را از پایگاه دادهٔ PostgreSQL
دریافت کند.
PGSQL_LB_GET_STATE_SUBID6
0.0
3.5
obtaining IPv6 leases with state %1 in subnet %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است مجموعه‌ای از
اجاره‌های IPv6 با وضعیت مشخص‌شده در زیرشبکهٔ تعیین‌شده را از پایگاه دادهٔ PostgreSQL
دریافت کند.
PGSQL_LB_GET_SUBID4
0.0
3.5
obtaining IPv4 leases for subnet ID %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تمام اجاره‌های IPv4
مربوط به یک شناسهٔ زیرشبکهٔ داده‌شده را از پایگاه دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_SUBID6
0.0
3.5
obtaining IPv6 leases for subnet ID %1
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است تمام اجاره‌های IPv6
مربوط به یک شناسهٔ زیرشبکهٔ داده‌شده را از پایگاه دادهٔ PostgreSQL دریافت کند.
PGSQL_LB_GET_SUBID_CLIENTID
0.0
3.5
obtaining IPv4 lease for subnet ID %1 and client ID %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است یک اجارهٔ IPv4
را برای کلاینتی با شناسهٔ زیرشبکه و شناسهٔ کلاینت مشخص‌شده از پایگاه دادهٔ PostgreSQL
دریافت کند.
PGSQL_LB_GET_SUBID_HWADDR
0.0
3.5
obtaining IPv4 lease for subnet ID %1 and hardware address %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است یک اجارهٔ IPv4
را برای کلاینتی با شناسهٔ زیرشبکه و آدرس سخت‌افزاری مشخص‌شده از پایگاه دادهٔ PostgreSQL
دریافت کند.
PGSQL_LB_GET_SUBID_PAGE6
0.0
3.5
obtaining at most %1 IPv6 leases starting from address %2 for subnet ID %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش است صفحه‌ای از
اجاره‌های IPv6 را با شروع از آدرس مشخص‌شده برای شناسهٔ زیرشبکهٔ تعیین‌شده از
پایگاه دادهٔ PostgreSQL دریافت کند..SS PGSQL_LB_GET_VERSION
0.0
3.5
obtaining schema version information
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در آستانهٔ دریافت اطلاعات
نسخهٔ طرح‌واره (schema) از پایگاه‌دادهٔ PostgreSQL است.
PGSQL_LB_NEGATIVE_LEASES_STAT
0.0
3.5
recount of leases returned a negative value
168u
168u
این پیام هشدار زمانی صادر می‌شود که شمارش مجدد اجاره‌ها با استفاده از
شمارنده‌ها در پایگاه‌دادهٔ PostgreSQL یک مقدار منفی برگردانده باشد. این امر
نشان‌دهندهٔ مشکلی است که تنها با یک شمارش مجدد مستقیم و برون‌خط (offline) بر روی
پایگاه‌داده قابل رفع است. این پیام فقط یک بار صادر می‌شود.
PGSQL_LB_ROLLBACK
0.0
3.5
rolling back PostgreSQL database
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
کد یک فراخوانی عقب‌گرد (rollback) صادر کرده است. تمام تراکنش‌های در انتظار،
به عقب بازگردانده شده و در پایگاه‌داده ثبت نهایی (commit) نخواهند شد.
PGSQL_LB_SFLQ_CREATE_POOL4
0.0
3.5
creating shared-flq pool for address range %1 - %2, subnet id %3, recreate %4, capacity %5
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره می‌خواهد
داده‌های اجارهٔ آزاد اشتراکی را برای استخر (pool) شرح‌داده‌شده در آرگومان‌ها
(مجدداً) ایجاد کند.
PGSQL_LB_SFLQ_CREATE_POOL6
0.0
3.5
creating shared-flq pool for address range %1 - %2, type %3, delegated length: %4, subnet id %5, recreate %6, capacity %7
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره می‌خواهد
داده‌های اجارهٔ آزاد اشتراکی را برای استخر شرح‌داده‌شده در آرگومان‌ها
(مجدداً) ایجاد کند.
PGSQL_LB_SFLQ_PICK_LEASE4
0.0
3.5
picking a free lease from address range %1 - %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره، یک نشانی آزاد
از استخر شرح‌داده‌شده در آرگومان‌ها را درخواست می‌کند.
PGSQL_LB_SFLQ_PICK_LEASE6
0.0
3.5
picking a free lease from address range %1 - %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره، یک اجارهٔ آزاد
از استخر شرح‌داده‌شده در آرگومان‌ها را درخواست می‌کند.
PGSQL_LB_SFLQ_POOL4_DELETE
0.0
3.5
delete the V4 SFLQ pool with start address %1 and end address %2, force = %3
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره درخواست می‌کند
استخر SFLQ مربوط به v4 (و داده‌های اجارهٔ آزاد آن) را که با نشانی‌های آغاز و پایان
داده‌شده همخوانی دارد، حذف کند.
PGSQL_LB_SFLQ_POOL4_GET_ALL
0.0
3.5
fetch all V4 SFLQ pools
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور فهرستی از تمام استخرهای SFLQ
مربوط به v4 را از بک‌اند اجاره درخواست می‌کند.
PGSQL_LB_SFLQ_POOL4_GET_BY_RANGE
0.0
3.5
fetch all V4 SFLQ pools that overlap the range %1 and %2
168u
168u
در سطح لاگ اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور استخرهای SFLQ مربوط به v4 را که با
محدودهٔ نشانی داده‌شده هم‌پوشانی دارند، از بک‌اند اجاره درخواست می‌کند..SS PGSQL_LB_SFLQ_POOL4_GET_BY_SUBNET
0.0
3.5
fetch all V4 SFLQ pools for subnet-id %1
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره، فهرستی از تمام استخرهای v4 SFLQ متعلق به یک زیرشبکه را درخواست کند.
PGSQL_LB_SFLQ_POOL6_DELETE
0.0
3.5
delete the V6 SFLQ pool with start address %1 and end address %2, force = %3
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره درخواست کند استخر v6 SFLQ (و داده‌های اجارهٔ آزاد آن) را که با آدرس‌های آغاز و پایان داده‌شده مطابقت دارند، حذف نماید.
PGSQL_LB_SFLQ_POOL6_GET_ALL
0.0
3.5
fetch all V6 SFLQ pools
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره، فهرستی از تمام استخرهای v6 SFLQ را درخواست کند.
PGSQL_LB_SFLQ_POOL6_GET_BY_RANGE
0.0
3.5
fetch all V6 SFLQ pools that overlap the range %1 and %2
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره، استخرهای v6 SFLQ را که با محدودهٔ آدرس مشخص‌شده هم‌پوشانی دارند درخواست کند.
PGSQL_LB_SFLQ_POOL6_GET_BY_SUBNET
0.0
3.5
fetch all V6 SFLQ pools for subnet-id %1
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور از بک‌اند اجاره، فهرستی از تمام استخرهای v6 SFLQ متعلق به یک زیرشبکه را درخواست کند.
PGSQL_LB_UPDATE_ADDR4
0.0
3.5
updating IPv4 lease for address %1
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش برای به‌روزرسانی اجارهٔ IPv4 از پایگاه‌دادهٔ PostgreSQL برای آدرس مشخص‌شده است.
PGSQL_LB_UPDATE_ADDR6
0.0
3.5
updating IPv6 lease for address %1, lease type %2
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در تلاش برای به‌روزرسانی اجارهٔ IPv6 از پایگاه‌دادهٔ PostgreSQL برای آدرس مشخص‌شده است.
PGSQL_LB_UPGRADE_EXTENDED_INFO4
0.0
3.5
upgrading IPv4 leases done in %1 pages with %2 updated leases
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
سرور اطلاعات گسترش‌یافته (extended info) را ارتقا داد. تعداد صفحه‌ها و شمار نهایی اجاره‌های به‌روزرسانی‌شده نمایش داده می‌شوند.
PGSQL_LB_UPGRADE_EXTENDED_INFO4_ERROR
0.0
3.5
upgrading extending info for IPv4 lease at %1 failed with %2
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور در ارتقای اطلاعات گسترش‌یافته با شکست مواجه شود. آدرس اجاره و پیام خطا نمایش داده می‌شوند.
PGSQL_LB_UPGRADE_EXTENDED_INFO4_PAGE
0.0
3.5
upgrading IPv4 lease extended info at page %1 starting at %2 (updated %3)
168u
168u
در سطح گزارش اشکال‌زدایی 50 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور اطلاعات گسترش‌یافتهٔ اجارهٔ IPv4 را ارتقا می‌دهد. شمارهٔ صفحه، آدرس آغازین و تعداد اجاره‌های از قبل به‌روزرسانی‌شده نمایش داده می‌شوند..SS PGSQL_LB_UPGRADE_EXTENDED_INFO6
0.0
3.5
upgrading IPv6 leases done in %1 pages with %2 updated leases
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
کارساز اطلاعات توسعه‌یافته را ارتقا داد. تعداد صفحه‌ها و شمار نهایی اجاره‌های به‌روزرسانی‌شده نمایش داده می‌شوند.
PGSQL_LB_UPGRADE_EXTENDED_INFO6_ERROR
0.0
3.5
upgrading extending info for IPv6 lease at %1 failed with %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز نتواند اطلاعات توسعه‌یافته را برای یک اجاره ارتقا دهد. نشانی اجاره و پیام خطا نمایش داده می‌شوند.
PGSQL_LB_UPGRADE_EXTENDED_INFO6_PAGE
0.0
3.5
upgrading IPv6 lease extended info at page %1 starting at %2 (updated %3)
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که کارساز اطلاعات توسعه‌یافته اجاره IPv6 را ارتقا می‌دهد. شماره صفحه، نشانی آغازین و تعداد اجاره‌هایی که تاکنون به‌روزرسانی شده‌اند نمایش داده می‌شوند.
PING
PING_CHECK_CB4_UPDATE_FAILED
0.0
3.5
A subnet ping-check parameters failed to parse after being updated %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که پس از به‌روزرسانی زیرشبکه از طریق backend پیکربندی، خطایی در تجزیه پارامترهای ping-check زیرشبکه رخ دهد. این نشان می‌دهد که یک یا چند پارامتر نامعتبر هستند و باید اصلاح شوند.
PING_CHECK_CHANNEL_ECHO_REPLY_RECEIVED
0.0
3.5
from address %1, id %2, sequence %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک ECHO REPLY روی سوکت ICMP کانال ping دریافت شده باشد.
PING_CHECK_CHANNEL_ECHO_REQUEST_SENT
0.0
3.5
to address %1, id %2, sequence %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک ECHO REQUEST روی سوکت ICMP کانال ping نوشته (ارسال) شده باشد.
PING_CHECK_CHANNEL_MALFORMED_PACKET_RECEIVED
0.0
3.5
error occurred unpacking message %1, discarding it
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که بسته ICMP دریافت شده باشد که بازگشایی (unpack) آن امکان‌پذیر نیست.
PING_CHECK_CHANNEL_NETWORK_WRITE_ERROR
0.0
3.5
occurred trying to ping %1, error %2
168u
168u
این پیام خطا زمانی رخ می‌دهد که یک نوشتن ناهمگام روی سوکت ICMP هنگام تلاش برای ارسال به شبکه هدف ping با شکست مواجه شود. این ممکن است به این معنی باشد که یک رابط شبکه غیرفعال (down) است یا خطای پیکربندی وجود دارد. نشانی اجاره برای ping و نوع خطا در آرگومان‌ها ارائه شده‌اند.
PING_CHECK_CHANNEL_SOCKET_CLOSED
0.0
3.5
ICMP socket has been closed.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سوکت ICMP برای انجام بررسی‌های ping بسته شده باشد..SS PING_CHECK_CHANNEL_SOCKET_CLOSE_ERROR
0.0
3.5
an attempt to close the ICMP socket failed %1
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام بستن سوکت ICMP مربوط به بررسی پینگ (ping check)، خطای غیرمنتظره‌ای رخ دهد. جزئیات خطا به عنوان آرگومان در پیام لاگ ارائه شده است.
PING_CHECK_CHANNEL_SOCKET_OPENED
0.0
3.5
ICMP socket been opened successfully.
168u
168u
در سطح لاگ اشکال‌زدایی (debug log level) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سوکت ICMP برای انجام بررسی‌های پینگ با موفقیت باز شده باشد.
PING_CHECK_CHANNEL_SOCKET_READ_FAILED
0.0
3.5
socket read completed with an error %1
168u
168u
این پیام خطا زمانی رخ می‌دهد که خواندن ناهمگام (asynchronous read) روی سوکت ICMP با شکست مواجه شود. جزئیات خطا به عنوان آرگومان در پیام لاگ ارائه شده است.
PING_CHECK_CHANNEL_SOCKET_WRITE_FAILED
0.0
3.5
socket write completed with an error %1
168u
168u
این پیام خطا زمانی رخ می‌دهد که نوشتن ناهمگام (asynchronous write) روی سوکت ICMP با شکست مواجه شود. جزئیات خطا به عنوان آرگومان در پیام لاگ ارائه شده است.
PING_CHECK_CHANNEL_STOP
0.0
3.5
channel is stopping operations.
168u
168u
در سطح لاگ اشکال‌زدایی (debug log level) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که کانال در حال توقف عملیات و بستن سوکت ICMP است. دلیل توقف باید در پیام‌های لاگ قبلی مشخص باشد.
PING_CHECK_CHANNEL_WATCH_SOCKET_CLEAR_ERROR
0.0
3.5
an attempt to clear the WatchSocket associated with
168u
168u
the single-threaded ping-channel failed %1
این پیام خطا زمانی صادر می‌شود که هنگام پاک کردن نشانگر آمادگی (ready marker) سوکت WatchSocket مرتبط با کانال بررسی پینگ، خطای غیرمنتظره‌ای رخ دهد. این وضعیت تنها هنگام اجرا در حالت تک‌نخی (single-threaded) می‌تواند رخ دهد. جزئیات خطا به عنوان آرگومان در پیام لاگ ارائه شده است.
PING_CHECK_CHANNEL_WATCH_SOCKET_CLOSE_ERROR
0.0
3.5
an attempt to close the WatchSocket associated with
168u
168u
the single-threaded ping-channel failed %1
این پیام خطا زمانی صادر می‌شود که هنگام بستن WatchSocket مرتبط با کانال بررسی پینگ، خطای غیرمنتظره‌ای رخ دهد. این وضعیت تنها هنگام اجرا در حالت تک‌نخی (single-threaded) می‌تواند رخ دهد. جزئیات خطا به عنوان آرگومان در پیام لاگ ارائه شده است.
PING_CHECK_DHCP4_SRV_CONFIGURED_FAILED
0.0
3.5
dhcp4_srv_configured callout failed %1
168u
168u
این پیام خطا نشان‌دهندهٔ بروز خطا در حین فراخوانی (callout) تابع dhcp4_srv_configured از کتابخانه هوک (hook library) مربوط به Ping Check است. جزئیات خطا به عنوان آرگومان در پیام لاگ ارائه شده است.
PING_CHECK_DUPLICATE_CHECK
0.0
3.5
Ping check already in progress for %1, initiated by %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug log level) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک درخواست تکراری برای بررسی یک نشانی دریافت گردد. در صورت وقوع، از بررسی تکراری صرف‌نظر می‌شود و DHCPOFFER مرتبط نادیده گرفته و رها (drop) خواهد شد..SS PING_CHECK_LEASE4_OFFER_FAILED
0.0
3.5
lease4_offer callout failed for query %1, lease address %2, reason %3
168u
168u
این پیام خطا نشان‌دهنده بروز خطا در حین فراخوانی (callout) مربوط به lease4_offer در کتابخانه قلاب‌های Ping Check است. جزئیات خطا به عنوان آرگومان پیام گزارش ارائه شده‌اند.
PING_CHECK_LOAD_ERROR
0.0
3.5
loading Ping Check hooks library failed %1
168u
168u
این پیام خطا نشان‌دهنده بروز خطا در حین بارگذاری کتابخانه قلاب‌های Ping Check است. جزئیات خطا به عنوان آرگومان پیام گزارش ارائه شده‌اند.
PING_CHECK_LOAD_OK
0.0
3.5
Ping Check hooks library loaded successfully.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های Ping Check با موفقیت بارگذاری شده است.
PING_CHECK_MGR_CHANNEL_DOWN
0.0
3.5
Ping Channel has shutdown, ping checking will be skipped
168u
168u
این پیام خطا زمانی صادر می‌شود که کانال زیرین ICMP به دلیل یک خطای غیرقابل جبران متوقف شده باشد. سرویس DHCP ممکن است به کار خود ادامه دهد اما بدون انجام بررسی‌های ping. پیام‌های گزارش قبلی باید جزئیات را ارائه دهند.
PING_CHECK_MGR_LEASE_FREE_TO_USE
0.0
3.5
address %1 is free to use for %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که ping check تشخیص دهد نشانی برای استفاده آزاد است. آرگومان‌های گزارش، نشانی اجاره (lease) بررسی‌شده و درخواستی را که این بررسی را آغاز کرده است مشخص می‌کنند.
PING_CHECK_MGR_NEXT_ECHO_SCHEDULED
0.0
3.5
for %1, scheduling ECHO_REQUEST %2 of %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که حداقل تعداد ECHO REQUESTها بیشتر از ۱ باشد و ECHO REQUEST بعدی برای نشانی اجاره داده‌شده زمان‌بندی شده باشد.
PING_CHECK_MGR_RECEIVED_ECHO_REPLY
0.0
3.5
from %1, id %2, sequence %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک پیام ECHO REPLY دریافت شده باشد. آرگومان گزارش، نشانی IP مبدأ، شناسه (id) و شماره توالی (sequence) پیام ECHO REPLY را مشخص می‌کند.
PING_CHECK_MGR_RECEIVED_UNEXPECTED_ECHO_REPLY
0.0
3.5
from %1, id %2, sequence %3 received after reply-timeout expired
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک ECHO REPLY پس از منقضی شدن reply-timeout دریافت شده باشد و دیگر مورد نیاز نباشد. این ممکن است یک ECHO REPLY سرگردان باشد یا نشان‌دهنده این باشد که مقدار reply-timeout بیش از حد کوتاه است. آرگومان گزارش، نشانی IP مبدأ، شناسه (id) و شماره توالی پاسخ را مشخص می‌کند.
PING_CHECK_MGR_RECEIVED_UNEXPECTED_UNREACHABLE_MSG
0.0
3.5
for %1, id %2, sequence %3 received after reply-timeout expired
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک پیام UNREACHABLE پس از منقضی شدن reply-timeout دریافت شده باشد و دیگر مورد نیاز نباشد. این ممکن است یک پیام سرگردان باشد یا نشان‌دهنده این باشد که مقدار reply-timeout بیش از حد کوتاه است..SS PING_CHECK_MGR_RECEIVED_UNREACHABLE_MSG
0.0
3.5
for %1, id %2, sequence %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک پیام UNREACHABLE دریافت شده باشد.
آرگومان گزارش، جزئیات نشانی IP مقصد، شناسه (id) و شماره توالی برگرفته از
ECHO REQUEST تعبیه‌شده را مشخص می‌کند.
PING_CHECK_MGR_REPLY_RECEIVED_ERROR
0.0
3.5
an error occurred processing an ICMP reply message %1
168u
168u
این پیام اشکال‌زدایی زمانی صادر می‌شود که هنگام پردازش یک پیام ورودی
ICMP خطایی رخ داده باشد. آرگومان گزارش، خطای رخ‌داده را شرح می‌دهد.
PING_CHECK_MGR_REPLY_TIMEOUT_EXPIRED
0.0
3.5
for %1, ECHO REQUEST %2 of %3, reply-timeout %4
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پیش از به پایان رسیدن مقدار مهلت زمانی پیکربندی‌شده،
یعنی reply-timeout، هیچ پاسخی برای یک ECHO REQUEST دریافت نشود.
آرگومان‌های گزارش جزئیات را ارائه می‌دهند.
PING_CHECK_MGR_SEND_COMPLETED_ERROR
0.0
3.5
an error occurred in the send completion callback %1
168u
168u
این پیام خطا زمانی صادر می‌شود که پس از تکمیل یک نوشتن موفق در
سوکت PingChannel، خطای غیرمنتظره‌ای رخ داده باشد. آرگومان گزارش، خطای
مشخص را شرح می‌دهد.
PING_CHECK_MGR_STARTED
0.0
3.5
ping channel operations are running, number of threads %1
168u
168u
این پیام زمانی صادر می‌شود که کانال بررسی پینگ باز شده باشد
و آمادهٔ پردازش درخواست‌ها باشد. آرگومان گزارش شامل تعداد ریسه‌ها
در استخر ریسه‌های (thread pool) کانال است.
PING_CHECK_MGR_STARTED_SINGLE_THREADED
0.0
3.5
single-threaded ping channel operations are running
168u
168u
این پیام زمانی صادر می‌شود که کانال بررسی پینگ باز شده باشد
و آمادهٔ پردازش درخواست‌ها در حالت تک‌ریسه‌ای (single-threaded) باشد.
PING_CHECK_MGR_START_PING_CHECK
0.0
3.5
for %1, initiated by %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک بررسی پینگ برای یک نشانی
آغاز شده باشد. آرگومان‌های گزارش، جزئیات نشانی اجاره (lease address) برای
پینگ و پرس‌وجویی که بررسی را آغاز کرده است مشخص می‌کنند.
PING_CHECK_MGR_STOPPED
0.0
3.5
channel operations have stopped
168u
168u
این پیام زمانی صادر می‌شود که عملیات کانال بررسی پینگ
متوقف شده باشد.
PING_CHECK_MGR_STOPPING
0.0
3.5
ping channel operations are stopping
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کانال بررسی پینگ در حال توقف عملیات باشد،
که معمولاً به دلیل یک رویداد پیکربندی یا خاموش شدن سرور رخ می‌دهد.
PING_CHECK_MGR_SUBNET_CONFIG_FAILED
0.0
3.5
user-context for subnet id %1, contains invalid ping-check %2
168u
168u
این پیام خطا نشان می‌دهد که یک زیرشبکه (subnet) از طریق دستورات subnet به‌روزرسانی شده
و بخش 'user-context' آن شامل پیکربندی نامعتبر 'ping-check' است.
سرور این خطا را یک بار ثبت کرده و سپس تا زمان اصلاح پیکربندی،
از پارامترهای سراسری ping-check برای آن زیرشبکه استفاده خواهد کرد..SS PING_CHECK_NO_LEASE_OR_LEASE_REUSED
0.0
3.5
Ping check skipped: no lease
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که درخواست ping check ارسال‌شده توسط کارگزار، فاقد یک lease باشد. این حالت معمولاً زمانی رخ می‌دهد که یک lease مجدداً استفاده می‌شود. بررسی ping نادیده گرفته خواهد شد و پردازش offer طبق روال عادی ادامه می‌یابد.
PING_CHECK_PAUSE_FAILED
0.0
3.5
Pausing ping channel operations failed %1
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام تلاش برای متوقف کردن موقت (pause) مخزن نخ‌های (thread pool) کانال ping، خطای غیرمنتظره‌ای رخ دهد. وقوع این خطا بسیار نامحتمل است و نشان‌دهنده یک مشکل برنامه‌نویسی است که باید به عنوان نقص (defect) گزارش شود.
PING_CHECK_PAUSE_ILLEGAL
0.0
3.5
Pausing ping channel operations not allowed %1
168u
168u
این پیام خطا هنگام تلاش برای متوقف کردن موقت (pause) مخزن نخ‌های (thread pool) کانال ping صادر می‌شود. این موضوع نشان می‌دهد که یک نخ کانال تلاش کرده است از یک بخش بحرانی (critical section) استفاده کند که منجر به بن‌بست (dead-lock) می‌شد. وقوع این خطا بسیار نامحتمل است و نشان‌دهنده یک مشکل برنامه‌نویسی است که باید به عنوان یک نقص گزارش شود.
PING_CHECK_PAUSE_PERMISSIONS_FAILED
0.0
3.5
Permissions check for ping-channel pause failed %1
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام اعتبارسنجی تلاش برای متوقف کردن موقت (pause) مخزن نخ‌های (thread pool) کانال ping، خطای غیرمنتظره‌ای رخ دهد. وقوع این خطا بسیار نامحتمل است و نشان‌دهنده یک مشکل برنامه‌نویسی است که باید به عنوان یک نقص گزارش شود.
PING_CHECK_RESUME_FAILED
0.0
3.5
Resuming ping channel operations failed %1
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام تلاش برای ازسرگیری عملیات مخزن نخ‌های (thread pool) کانال ping، خطای غیرمنتظره‌ای رخ دهد. وقوع این خطا بسیار نامحتمل است و نشان‌دهنده یک مشکل برنامه‌نویسی است که باید به عنوان یک نقص گزارش شود.
PING_CHECK_UNEXPECTED_READ_ERROR
0.0
3.5
could not start next socket read %1
168u
168u
این پیام خطا زمانی رخ می‌دهد که آغاز یک خواندن ناهمگام (asynchronous read) روی سوکت ICMP به شکلی غیرمنتظره با شکست مواجه شود. جزئیات خطا به عنوان یک آرگومان در پیام لاگ ارائه می‌شود.
PING_CHECK_UNEXPECTED_WRITE_ERROR
0.0
3.5
could not start next socket write %1
168u
168u
این پیام خطا زمانی رخ می‌دهد که آغاز یک نوشتن ناهمگام (asynchronous write) روی سوکت ICMP به شکلی غیرمنتظره با شکست مواجه شود. جزئیات خطا به عنوان یک آرگومان در پیام لاگ ارائه می‌شود.
PING_CHECK_UNLOAD
0.0
3.5
Ping Check hooks library has been unloaded
168u
168u
این پیام اطلاع‌رسانی (info) نشان می‌دهد که کتابخانه قلاب‌های (hooks library) قابلیت Ping Check از حافظه تخلیه (unload) شده است.
RADIUS
RADIUS_ACCESS_BUILD_FAILED
0.0
3.5
building Access-Request failed: %1 for incoming message %2
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام ساخت یک Access-Request خطایی رخ داده باشد..SS RADIUS_ACCESS_CACHE_GET
0.0
3.5
host %1 with attributes %2 was retrieved from the cache
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک میزبان از حافظهٔ نهان میزبان (host cache) بازیابی شود.
RADIUS_ACCESS_CACHE_INSERT
0.0
3.5
host %1 with attributes %2 was inserted into the cache
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که میزبان جدیدی در حافظهٔ نهان میزبان درج گردد.
RADIUS_ACCESS_CONFLICT
0.0
3.5
query %1 triggers a conflict for %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک پرس‌وجو (query) باعث ایجاد تداخل با یک درخواست دسترسی معلق برای همان شناسه شود.
RADIUS_ACCESS_DROP_PARKED_QUERY
0.0
3.5
access request terminate callback decided to drop the parked query %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک درخواست دسترسی با تصمیم مبنی بر دور انداختن (drop) پرس‌وجوی متوقف‌شده (parked query) خاتمه یابد.
RADIUS_ACCESS_ERROR
0.0
3.5
Access-Request failed with %1 (%2)
168u
168u
این پیام خطا زمانی صادر می‌شود که هیچ پیام معتبر Access-Accept یا Access-Reject دریافت نشده باشد. کد بازگشتی و نام آن ثبت می‌شوند.
RADIUS_ACCESS_GET_IDENTIFIER
0.0
3.5
identifier %1 of type %2 and User-Name %3 were set from incoming message %4
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که شناسهٔ میزبان و مشخصهٔ User-Name از یک پیام دریافتی مقداردهی شوند.
RADIUS_ACCESS_GET_IDENTIFIER_FAILED
0.0
3.5
no identifier of type %1 can be set from incoming message %2, reason: %3
168u
168u
این پیام خطا زمانی صادر می‌شود که ساخت شناسهٔ میزبان بر اساس پیام دریافتی امکان‌پذیر نبوده است.
RADIUS_ACCESS_HOST_BACKEND_ERROR
0.0
3.5
Configuring access failed during host backend '%1' setup, reason: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که دسترسی/احراز هویت در پیکربندی فعال شده باشد، اما در راه‌اندازی backend میزبان مشکلی رخ دهد. نام backend میزبان و دلیل خطا ثبت می‌شوند.
RADIUS_ACCESS_MAX_PENDING_REQUESTS
0.0
3.5
query '%1' with identifier '%2' was dropped for too many pending access requests
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که تعداد درخواست‌های دسترسی معلق فراتر از حد مجاز پیکربندی‌شده باشد. پرس‌وجو و شناسهٔ آن نمایش داده می‌شوند.
RADIUS_ACCESS_NO_HOST_CACHE
0.0
3.5
Configuring access failed: host cache library not loaded.
168u
168u
این پیام خطا زمانی صادر می‌شود که دسترسی/احراز هویت در پیکربندی فعال باشد اما هیچ حافظهٔ نهان میزبانی (host cache) یافت نشود. قلاب Radius برای ذخیره (نهان‌سازی) پارامترهای دریافت‌شده از تبادل داده با سرور RADIUS، نیازمند بارگذاری قلاب Host Cache است..SS RADIUS_ACCESS_ORPHAN
0.0
3.5
orphan pending access request for %1
168u
168u
این پیام خطا زمانی صادر می‌شود که یک درخواست دسترسی (access request) بدون درخواست معلق متناظر برای شناسه پایان یابد.
RADIUS_ACCESS_RESUME_PARKED_QUERY
0.0
3.5
access request terminate callback resumes processing of parked query %1 in %2
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که فراخوان بازگشتی پایان درخواست دسترسی (access request terminate callback)، پردازش یک پرس‌وجوی متوقف‌شده (parked query) را پس از نقطه فراخوانی انتخاب زیرشبکه (subnet select callout point) از سر می‌گیرد.
RADIUS_ACCESS_SUBNET_RESELECT
0.0
3.5
subnet was reselected from 'ID %1' to 'ID %2'
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که دسترسی/احراز هویت باعث انتخاب مجدد زیرشبکه شود. شناسه‌های اصلی و جدید زیرشبکه ثبت می‌شوند.
RADIUS_ACCESS_TERMINATE_ERROR
0.0
3.5
access request terminate callback got an error: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که یک درخواست دسترسی با یک خطای داخلی غیرمنتظره پایان یابد.
RADIUS_ACCOUNTING_ASYNC
0.0
3.5
Asynchronous send Accounting-Request for NAS port %1 with %2
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی هنگام آغاز ارسال یک پیام Accounting-Request به سرورهای حسابرسی صادر می‌شود. پورت NAS و مشخصه‌های پیام ثبت می‌شوند.
RADIUS_ACCOUNTING_ASYNC_FAILED
0.0
3.5
Asynchronous Accounting-Request failed: return code %1 (%2)
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ پیام معتبر Accounting-Response دریافت نشده باشد.
RADIUS_ACCOUNTING_ASYNC_SUCCEED
0.0
3.5
received valid Accounting-Response (asynchronously)
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک Accounting-Response معتبر دریافت شده است.
RADIUS_ACCOUNTING_ERROR
0.0
3.5
Accounting-Request failed for %1 on event %2 (%3) failed with %4 (%5)
168u
168u
این پیام خطا زمانی صادر می‌شود که ارتباط حسابرسی ناموفق باشد.
شناسه نشست (session Id)، کد و نام رویداد، و همچنین کد بازگشتی و نام آن ثبت می‌شوند.
RADIUS_ACCOUNTING_HISTORY_UPDATE_FAILED
0.0
3.5
failed to insert a record for %1 in the history container
168u
168u
این پیام خطا زمانی صادر می‌شود که درج یک رکورد در برچسب زمان ایجاد یا همان مخزن تاریخچه (history container) ممکن نباشد. این امر باید نشست را مختل کند، به این معنی که برای نمونه تطبیق پیام‌های وضعیت start و stop ممکن نخواهد بود.
RADIUS_ACCOUNTING_NO_HISTORY
0.0
3.5
failed to find the date the lease for %1 was created
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که آدرسی در برچسب زمان ایجاد یا همان مخزن تاریخچه (history container) یافت نشود. این امر منجر به ایجاد یک نشست حسابرسی بدون پیام وضعیت start می‌شود..SS RADIUS_ACCOUNTING_STATUS
0.0
3.5
send Status-Server with %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که ارسال یک پیام Status-Server به سرورهای accounting آغاز شود. ویژگی‌های پیام در گزارش ثبت می‌شوند.
RADIUS_ACCOUNTING_STATUS_ERROR
0.0
3.5
received error response to Status-Server: %1 (%2) with %3
168u
168u
این پیام خطا نشان می‌دهد که پاسخ معتبری برای پیام Status-Server از سرورهای accounting دریافت شده، اما حاوی یک کد غیرمنتظره یا ویژگی Error-Cause بوده است. جزئیات پاسخ در گزارش ثبت می‌شوند.
RADIUS_ACCOUNTING_STATUS_FAILED
0.0
3.5
Status-Server failed: return code %1 (%2)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که هیچ پاسخ معتبری برای پیام Status-Server از سرورهای accounting دریافت نشده باشد.
RADIUS_ACCOUNTING_STATUS_SUCCEED
0.0
3.5
received valid response to Status-Server
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که پاسخ معتبری برای پیام Status-Server از سرورهای accounting دریافت شده است.
RADIUS_ACCOUNTING_SYNC
0.0
3.5
Synchronous send Accounting-Request for NAS port %1 with %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که ارسال یک پیام Accounting-Request به سرورهای accounting آغاز گردد. پورت NAS و ویژگی‌های پیام در گزارش ثبت می‌شوند.
RADIUS_ACCOUNTING_SYNC_FAILED
0.0
3.5
Synchronous Accounting-Request failed: return code %1 (%2)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که هیچ پیام Accounting-Response معتبری دریافت نشده باشد.
RADIUS_ACCOUNTING_SYNC_SUCCEED
0.0
3.5
received valid Accounting-Response (synchronously)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک Accounting-Response معتبر دریافت شده است.
RADIUS_AUTHENTICATION_ASYNC
0.0
3.5
send Access-Request for NAS port %1 with %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که ارسال یک پیام Access-Request به سرورهای دسترسی (access servers) آغاز شود. پورت NAS و ویژگی‌های پیام در گزارش ثبت می‌شوند.
RADIUS_AUTHENTICATION_ASYNC_ACCEPTED
0.0
3.5
received valid Access-Accept with %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک پیام Access-Accept معتبر دریافت شده است. ویژگی‌های پیام در گزارش ثبت می‌شوند.
RADIUS_AUTHENTICATION_ASYNC_FAILED
0.0
3.5
Access-Request failed: return code %1 (%2)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگامی صادر می‌شود که هیچ پیام صحیح Access-Accept یا Access-Reject دریافت نشده باشد..SS RADIUS_AUTHENTICATION_ASYNC_REJECTED
0.0
3.5
received valid Access-Reject with %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک پیام معتبر Access-Reject دریافت شده است.
مشخصه‌های (attributes) پیام ثبت می‌شوند.
RADIUS_AUTHENTICATION_STATUS
0.0
3.5
send Status-Server with %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع ارسال پیام Status-Server به سرورهای دسترسی
صادر می‌شود. مشخصه‌های پیام ثبت می‌شوند.
RADIUS_AUTHENTICATION_STATUS_ERROR
0.0
3.5
received error response to Status-Server: %1 (%2) with %3
168u
168u
این پیام خطا نشان می‌دهد که یک پاسخ معتبر برای پیام Status-Server از سرورهای دسترسی
دریافت شده است، اما حاوی یک کد غیرمنتظره یا مشخصهٔ Error-Cause بوده است.
جزئیات پاسخ ثبت می‌شوند.
RADIUS_AUTHENTICATION_STATUS_FAILED
0.0
3.5
Status-Server failed: return code %1 (%2)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ پاسخ معتبری برای پیام Status-Server
از سرورهای دسترسی دریافت نشده باشد.
RADIUS_AUTHENTICATION_STATUS_SUCCEED
0.0
3.5
received valid response to Status-Server
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک پاسخ معتبر برای پیام Status-Server
از سرورهای دسترسی دریافت شده است.
RADIUS_AUTHENTICATION_SYNC
0.0
3.5
send Access-Request for NAS port %1 with %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام شروع ارسال پیام Access-Request به سرورهای دسترسی
صادر می‌شود. درگاه NAS و مشخصه‌های پیام ثبت می‌شوند.
RADIUS_AUTHENTICATION_SYNC_ACCEPTED
0.0
3.5
received valid Access-Accept with %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک پیام معتبر Access-Accept دریافت شده است.
مشخصه‌های پیام ثبت می‌شوند.
RADIUS_AUTHENTICATION_SYNC_FAILED
0.0
3.5
Access-Request failed: return code %1 (%2)
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ پیام معتبر Access-Accept یا
Access-Reject دریافت نشده باشد.
RADIUS_AUTHENTICATION_SYNC_REJECTED
0.0
3.5
received valid Access-Reject with %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک پیام معتبر Access-Reject دریافت شده است.
مشخصه‌های پیام ثبت می‌شوند.
RADIUS_BACKEND_GET4
0.0
3.5
spurious lookup for IPv4 subnet %1 and id %2 of type %3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پس‌دانه (backend) میزبان radius به‌طور
غیرمنتظره برای جستجوی یک مدخل IPv4 فراخوانی شود. جزئیات این جستجو ثبت می‌شوند..SS RADIUS_BACKEND_GET6
0.0
3.5
spurious lookup for IPv6 subnet %1 and id %2 of type %3
168u
168u
در سطح ثبت اشکال‌زدایی (debug) ۴۰ گزارش می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که backend میزبان radius به‌طور غیرمنتظره برای جستجوی یک مدخل IPv6 فراخوانی شود. جزئیات این جستجو ثبت می‌شود.
RADIUS_CLEANUP_EXCEPTION
0.0
3.5
Exception on RADIUS cleanup: %1
168u
168u
این پیام هشدار زمانی صادر می‌شود که هنگام تخریب یک شیء در کتابخانهٔ قلاب (hook) RADIUS، یک استثنا (exception) رخ دهد. برای جلوگیری از پنهان ماندن استثنایی دیگر، اجازه داده نمی‌شود که انتشار این استثنا ادامه یابد، بنابراین ثبت می‌شود. این پیام عموماً به معنای یک خطای برنامه‌نویسی است و باید به ISC گزارش شود، اما ممکن است بی‌خطر نیز باشد. آرگومان، پیام خطای دقیق را ارائه می‌دهد.
RADIUS_CONFIGURATION_FAILED
0.0
3.5
failed to configure Radius hooks library: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در پیکربندی کتابخانهٔ قلاب‌های Radius خطایی رخ دهد. آرگومان، پیام خطای دقیق را ارائه می‌دهد.
RADIUS_DECODE_MESSAGE
0.0
3.5
Decoded message '%1' (%2) id %3 length %4 with %5 attributes.
168u
168u
در سطح ثبت اشکال‌زدایی (debug) ۴۰ گزارش می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که پیامی رمزگشایی شود. نام نوع پیام و مقدار آن، شناسه، طول و تعداد مشخصه‌ها (attributes) نمایش داده می‌شوند.
RADIUS_DEINIT_OK
0.0
3.5
unloading Radius hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانهٔ قلاب‌های Radius با موفقیت تخلیه (unload) شده است.
RADIUS_ENCODE_MESSAGE
0.0
3.5
Encoded message '%1' (%2) id %3 length %4 with %5 attributes.
168u
168u
در سطح ثبت اشکال‌زدایی (debug) ۴۰ گزارش می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک پیام کدگذاری (encode) شود. نام نوع پیام و مقدار آن، شناسه، طول و تعداد مشخصه‌ها (attributes) نمایش داده می‌شوند.
RADIUS_EXCHANGE_RECEIVED_ACCESS_ACCEPT
0.0
3.5
Exchange %1 received an Access-Accept.
168u
168u
در سطح ثبت اشکال‌زدایی (debug) ۴۰ گزارش می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل (exchange) یک پاسخ Access-Accept دریافت کند. شناسهٔ تبادل نمایش داده می‌شود.
RADIUS_EXCHANGE_RECEIVED_ACCESS_REJECT
0.0
3.5
Exchange %1 received an Access-Reject.
168u
168u
در سطح ثبت اشکال‌زدایی (debug) ۴۰ گزارش می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل یک پاسخ Access-Reject دریافت کند. شناسهٔ تبادل نمایش داده می‌شود.
RADIUS_EXCHANGE_RECEIVED_ACCOUNTING_RESPONSE
0.0
3.5
Exchange %1 received an Accounting-Response.
168u
168u
در سطح ثبت اشکال‌زدایی (debug) ۴۰ گزارش می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل یک پاسخ Accounting-Response دریافت کند. شناسهٔ تبادل نمایش داده می‌شود.
RADIUS_EXCHANGE_RECEIVED_BAD_RESPONSE
0.0
3.5
Exchange %1 received a bad response: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل پاسخی نادرست دریافت کند. شناسهٔ تبادل و پیام خطا نمایش داده می‌شوند..SS RADIUS_EXCHANGE_RECEIVED_MISMATCH
0.0
3.5
Exchange %1: received response with identifier %2 when %3 was expected.
168u
168u
این پیام خطا زمانی صادر می‌شود که درخواست ارسال‌شده و پاسخ دریافت‌شده
دارای شناسه‌های متفاوتی باشند. شناسه مبادله و شناسه‌های هر دو پیام RADIUS
نمایش داده می‌شوند.
RADIUS_EXCHANGE_RECEIVED_RESPONSE
0.0
3.5
Exchange %1 received response: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) 40 ثبت می‌شود.
این پیام اشکال‌زدایی در پایان روال دریافت صادر می‌شود.
شناسه مبادله و کد خطا نمایش داده می‌شوند.
RADIUS_EXCHANGE_RECEIVED_UNEXPECTED
0.0
3.5
Exchange %1: sent %2, received unexpected %3
168u
168u
این پیام خطا زمانی صادر می‌شود که درخواست ارسال‌شده و پاسخ دریافت‌شده
مطابقت نداشته باشند. شناسه مبادله و کدهای هر دو پیام RADIUS نمایش
داده می‌شوند.
RADIUS_HOOK_FAILED
0.0
3.5
processing for hook %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که پردازش در یک نقطه قلاب (hook point) استاندارد با شکست مواجه شود.
علت شکست نمایش داده می‌شود.
RADIUS_INIT_OK
0.0
3.5
loading Radius hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های Radius با
موفقیت بارگذاری شده است. لذت ببرید!
RADIUS_INTEGER_ATTRIBUTE_FROM_BYTES_FAILED
0.0
3.5
Creating an integer attribute %1 '%2' failed: %3
168u
168u
این پیام خطا زمانی صادر می‌شود که یک صفت عدد صحیح نتواند
ایجاد شود. نوع صفت، نام و پیام خطا نمایش داده می‌شوند.
RADIUS_INTEGER_ATTRIBUTE_FROM_TEXT_FAILED
0.0
3.5
Creating an integer attribute %1 '%2' from %3 failed.
168u
168u
این پیام خطا زمانی صادر می‌شود که یک صفت عدد صحیح نتواند
ایجاد شود. نوع صفت، نام و مقدار نامعتبر ارائه‌شده نمایش داده می‌شوند.
RADIUS_IPADDR_ATTRIBUTE_FROM_BYTES_FAILED
0.0
3.5
Creating an IP address attribute %1 '%2' failed: %3
168u
168u
این پیام خطا زمانی صادر می‌شود که یک صفت نشانی IP نتواند
ایجاد شود. نوع صفت، نام و پیام خطا نمایش داده می‌شوند.
RADIUS_IPADDR_ATTRIBUTE_FROM_TEXT_FAILED
0.0
3.5
Creating an IP address attribute %1 '%2' from %3 failed.
168u
168u
این پیام خطا زمانی صادر می‌شود که یک صفت نشانی IP نتواند
ایجاد شود. نوع صفت، نام و مقدار نامعتبر ارائه‌شده نمایش داده می‌شوند.
RADIUS_IPV6ADDR_ATTRIBUTE_FROM_BYTES_FAILED
0.0
3.5
Creating an IPv6 address attribute %1 '%2' failed: %3
168u
168u
این پیام خطا زمانی صادر می‌شود که یک صفت نشانی IPv6 نتواند
ایجاد شود. نوع صفت، نام و پیام خطا نمایش داده می‌شوند..SS RADIUS_IPV6ADDR_ATTRIBUTE_FROM_TEXT_FAILED
0.0
3.5
Creating an IPv6 address attribute %1 '%2' from %3 failed.
168u
168u
این پیام خطا زمانی صادر می‌شود که صفت آدرس IPv6 نتواند ایجاد شود.
نوع صفت، نام و مقدار نامعتبر ارسال‌شده نمایش داده می‌شوند.
RADIUS_IPV6PREFIX_ATTRIBUTE_FROM_BYTES_FAILED
0.0
3.5
Creating an IPv6 prefix attribute %1 '%2' failed: %3
168u
168u
این پیام خطا زمانی صادر می‌شود که صفت پیشوند IPv6 نتواند ایجاد شود.
نوع صفت، نام و پیام خطا نمایش داده می‌شوند.
RADIUS_IPV6PREFIX_ATTRIBUTE_FROM_TEXT_FAILED
0.0
3.5
Creating an IPv6 prefix attribute %1 '%2' from %3 failed.
168u
168u
این پیام خطا زمانی صادر می‌شود که صفت پیشوند IPv6 نتواند ایجاد شود.
نوع صفت، نام و مقدار نامعتبر ارسال‌شده نمایش داده می‌شوند.
RADIUS_PAUSE_FAILED
0.0
3.5
Pausing the RADIUS thread pool failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در حین اعتبارسنجی تلاش برای متوقف کردن موقت
thread pool خطایی غیرمنتظره رخ دهد. وقوع این خطا بسیار نامحتمل است و نشان‌دهنده
یک مشکل برنامه‌نویسی است که باید به عنوان نقص گزارش شود.
RADIUS_PAUSE_ILLEGAL
0.0
3.5
Pausing the RADIUS thread pool not allowed: %1
168u
168u
این پیام خطا هنگام تلاش برای متوقف کردن موقت thread pool صادر می‌شود.
این موضوع نشان می‌دهد که یک ریسه تلاش کرده است از یک بخش بحرانی (critical section)
استفاده کند که منجر به بن‌بست (deadlock) می‌شد. وقوع این خطا بسیار نامحتمل است
و نشان‌دهنده یک مشکل برنامه‌نویسی است که باید به عنوان نقص گزارش شود.
RADIUS_PAUSE_PERMISSIONS_FAILED
0.0
3.5
Checking for permissions to pause the RADIUS thread pool failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که در حین اعتبارسنجی تلاش برای متوقف کردن موقت
thread pool خطایی غیرمنتظره رخ دهد. وقوع این خطا بسیار نامحتمل است و نشان‌دهنده
یک مشکل برنامه‌نویسی است که باید به عنوان نقص گزارش شود.
RADIUS_REPLY_MESSAGE_ATTRIBUTE
0.0
3.5
Message %1 on exchange %2 has a Reply-Message attribute with value '%3'.
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که یک صفت Reply-Message در پیامی دریافت شده
از سرور RADIUS یافت شود. به ازای هر صفت یک پیام لاگ چاپ می‌شود. یک پیام لاگ
می‌تواند شامل چندین صفت باشد، بنابراین ممکن است به ازای هر پیام RADIUS چندین پیام
لاگ ثبت شود. این پیام شناسه پیام، شناسه تبادل (exchange) و مقدار صفت Reply-Message
را نمایش می‌دهد.
RADIUS_RESUME_FAILED
0.0
3.5
Resuming the RADIUS thread pool failed: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام تلاش برای ازسرگیری فعالیت thread pool
خطایی غیرمنتظره رخ دهد. وقوع این خطا بسیار نامحتمل است و نشان‌دهنده یک مشکل
برنامه‌نویسی است که باید به عنوان نقص گزارش شود.
RADIUS_SERVER_CONFIGURED
0.0
3.5
configured an %1 server: %2
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که یک سرور RADIUS پیکربندی شود.
نوع سرور (access یا accounting) و جزئیات پیکربندی، در حالی که عبارت محرمانه
(secret) با ستاره جایگزین شده است، ثبت می‌شوند.
RADIUS_SESSION_HISTORY_APPEND_FAILED
0.0
3.5
appending of a new record for %1 to the session history file failed: %2
168u
168u
این پیام هشدار زمانی صادر می‌شود که الحاق یک رکورد جدید به فایل تاریخچه نشست
(session history file) با شکست مواجه شود. آدرس رکورد جدید و علت شکست
نمایش داده می‌شوند..SS RADIUS_SESSION_HISTORY_LOADED
0.0
3.5
loading of the session history file succeeded: read %1 records including %2 active records
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که بارگذاری فایل تاریخچه نشست با موفقیت به پایان برسد. تعداد رکوردهای بارگذاری‌شده و فعال نمایش داده می‌شود.
RADIUS_SESSION_HISTORY_LOAD_FAILED
0.0
3.5
loading of the session history file
168u
168u
با شکست مواجه شد: %1 رکورد بارگذاری‌شده، %2 نادیده‌گرفته‌شده و %3 رکورد فعال.
این پیام خطا زمانی صادر می‌شود که بارگذاری فایل تاریخچه نشست با موفقیت به پایان نرسد. تعداد رکوردهای بارگذاری‌شده، نادیده‌گرفته‌شده و فعال نمایش داده می‌شوند.
RADIUS_SESSION_HISTORY_OPENED
0.0
3.5
opening of the session history file %1 succeeded
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که باز کردن فایل CSV تأمین‌کننده پایداری تاریخچه نشست با موفقیت انجام شود. نام فایل نمایش داده می‌شود.
RADIUS_SESSION_HISTORY_OPEN_FAILED
0.0
3.5
opening of the session history file %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که باز کردن فایل CSV تأمین‌کننده پایداری تاریخچه نشست با شکست مواجه شود. نام فایل و دلیل شکست نمایش داده می‌شوند.
RADIUS_SESSION_HISTORY_STORED
0.0
3.5
Storing to the session history file succeeded: stored %1 records
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که نوشتن در یک فایل جدید تاریخچه نشست با موفقیت تکمیل شده باشد. تعداد رکوردهای ذخیره‌شده نمایش داده می‌شود.
RADIUS_SESSION_HISTORY_STORE_FAILED
0.0
3.5
Writing to the session history file %1 failed: %2 (stored %3 over %4 records)
168u
168u
این پیام خطا زمانی صادر می‌شود که نوشتن در یک فایل جدید تاریخچه نشست با شکست مواجه شود. نام فایل، دلیل شکست، تعداد رکوردهای ذخیره‌شده پیش از وقوع شکست و تعداد رکوردهای مورد انتظار نمایش داده می‌شوند.
RADIUS_TCP_EXCHANGE_FAILURE
0.0
3.5
TCP exchange %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل TCP با خطا پایان یابد. شناسه تبادل و کد خطای بازگشتی نمایش داده می‌شوند.
RADIUS_TCP_EXCHANGE_RECEIVED
0.0
3.5
TCP exchange %1 received %2 bytes.
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل TCP پاسخی دریافت کرده باشد. شناسه تبادل و اندازه پاسخ نمایش داده می‌شوند.
RADIUS_TCP_EXCHANGE_RECEIVE_FAILED
0.0
3.5
Receive for TCP exchange %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل TCP در دریافت پیام با شکست مواجه شود. شناسه تبادل و پیام خطا نمایش داده می‌شوند.
RADIUS_TCP_EXCHANGE_SEND
0.0
3.5
TCP exchange %1 sends %2 bytes to server %3 on port %4%5
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل TCP پیامی را به یک سرور ارسال کند. شناسه تبادل، اندازه پیام، آدرس و پورت سرور و استفاده از TLS نمایش داده می‌شوند..SS RADIUS_TCP_EXCHANGE_START
0.0
3.5
Start TCP exchange %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل TCP آغاز شود. شناسه
تبادل نمایش داده می‌شود.
RADIUS_TCP_EXCHANGE_START_ERROR
0.0
3.5
TCP exchange %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که آغاز یک تبادل TCP ناموفق باشد.
شناسه تبادل و پیام خطا نمایش داده می‌شوند.
RADIUS_TCP_EXCHANGE_SUCCESS
0.0
3.5
TCP exchange %1 succeeded: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل TCP با موفقیت پایان یابد.
شناسه تبادل و کد بازگشتی نمایش داده می‌شوند.
RADIUS_THREAD_POOL_STARTED
0.0
3.5
RADIUS thread pool started with %1 threads.
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که استخر ریسه‌ها (thread pool) راه‌اندازی شود.
تعداد ریسه‌ها نمایش داده می‌شود.
RADIUS_TLS_STATUS
0.0
3.5
send Status-Server with %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام آغاز ارسال یک پیام Status-Server به سرورهای TLS صادر می‌شود.
مشخصه‌های (attributes) پیام ثبت می‌شوند.
RADIUS_TLS_STATUS_ERROR
0.0
3.5
received error response to Status-Server: %1 (%2) with %3
168u
168u
این پیام خطا بیانگر آن است که یک پاسخ معتبر برای پیام Status-Server از سرورهای TLS
دریافت شده، اما دارای یک کد غیرمنتظره یا مشخصه Error-Cause بوده است.
جزئیات پاسخ ثبت می‌شوند.
RADIUS_TLS_STATUS_FAILED
0.0
3.5
Status-Server failed: return code %1 (%2)
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که هیچ پاسخ معتبری برای پیام Status-Server
از سرورهای TLS دریافت نشده باشد.
RADIUS_TLS_STATUS_SUCCEED
0.0
3.5
received valid response to Status-Server
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که یک پاسخ معتبر برای پیام Status-Server
از سرورهای TLS دریافت شده است.
RADIUS_UDP_EXCHANGE_FAILED
0.0
3.5
UDP exchange %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل UDP با خطا پایان یابد.
شناسه تبادل و کد بازگشتی خطا نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_OPEN_FAILED
0.0
3.5
Open socket for UDP exchange %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل UDP در باز کردن سوکت جدید با شکست مواجه شود.
شناسه تبادل و پیام خطا نمایش داده می‌شوند..SS RADIUS_UDP_EXCHANGE_RECEIVED
0.0
3.5
UDP exchange %1 received %2 bytes.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل UDP پاسخی دریافت کرده باشد.
شناسه تبادل و اندازه پاسخ نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_RECEIVE_FAILED
0.0
3.5
Receive for UDP exchange %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل UDP در دریافت پیام با شکست مواجه شود.
شناسه تبادل و پیام خطا نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_SEND_FAILED
0.0
3.5
Send for UDP exchange %1 failed: %2
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل UDP در ارسال پیام با شکست مواجه شود.
شناسه تبادل و پیام خطا نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_SEND_NEW
0.0
3.5
UDP exchange %1 sends %2 bytes to new server[%3] %4 on port %5
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل UDP پیامی را به یک
سرور جدید ارسال می‌کند. شناسه تبادل، اندازه پیام، شاخص سرور،
نشانی و پورت نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_SEND_RETRY
0.0
3.5
UDP exchange %1 sends %2 bytes for the %3 try.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل UDP پیامی را به یک
سرور جدید ارسال می‌کند. شناسه تبادل، اندازه پیام و شمارنده تلاش مجدد
نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_SENT
0.0
3.5
UDP exchange %1 sent %2 bytes.
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل UDP درخواستی را ارسال کرده و آماده
دریافت پاسخ باشد. شناسه تبادل و اندازه درخواست
نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_START
0.0
3.5
Start UDP exchange %1
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل UDP آغاز گردد. شناسه
تبادل نمایش داده می‌شود.
RADIUS_UDP_EXCHANGE_SYNC_RETURN
0.0
3.5
Synchronous UDP exchange %1 returns with %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل UDP همگام (synchronous) بازگردد.
شناسه تبادل و کد خطا/بازگشت نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_TERMINATE
0.0
3.5
UDP exchange %1 terminates with %2
168u
168u
در سطح لاگ اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک تبادل UDP با موفقیت خاتمه یابد.
شناسه تبادل و کد بازگشت نمایش داده می‌شوند.
RADIUS_UDP_EXCHANGE_TIMEOUT
0.0
3.5
UDP exchange %1 timeout
168u
168u
این پیام خطا زمانی صادر می‌شود که یک تبادل UDP به دلیل اتمام مهلت زمانی (timeout) با شکست مواجه شود.
شناسه تبادل نمایش داده می‌شود..SS RBAC
RBAC_CONFIGURED_ACLS
0.0
3.5
RBAC hooks library has configured %1 named ACLs.
168u
168u
در سطح ۴۰ گزارش اشکال‌زدایی (debug) ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تعدادی فهرست کنترل دسترسی (ACL) نام‌گذاری‌شده
پیکربندی شده‌اند. تعداد آن‌ها نمایش داده می‌شود.
RBAC_CONFIGURED_COMMANDS
0.0
3.5
RBAC hooks library has configured %1 extra commands.
168u
168u
در سطح ۴۰ گزارش اشکال‌زدایی (debug) ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تعدادی دستور اضافی پیکربندی شده‌اند.
تعداد آن‌ها نمایش داده می‌شود.
RBAC_CONFIGURED_ROLES
0.0
3.5
hooks library has configured %1 roles.
168u
168u
در سطح ۴۰ گزارش اشکال‌زدایی (debug) ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تعدادی نقش (role) پیکربندی شده‌اند.
تعداد آن‌ها نمایش داده می‌شود.
RBAC_HTTP_AUTH_ERROR
0.0
3.5
Error in http_auth callout: %1.
168u
168u
این پیام خطا نشان می‌دهد که در نقطه فراخوانی (callout) http_auth توسط
کتابخانه هوک‌های RBAC خطایی رخ داده است. آرگومان جزئیات خطا را مشخص می‌کند.
RBAC_HTTP_AUTH_FAILED
0.0
3.5
RBAC processing in http_auth callout failed for unexpected condition: %1.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه هوک‌های RBAC در نقطه callout مربوط به
http_auth با یک وضعیت غیرمنتظره مواجه شده است. علت شکست به طور خلاصه
بیان شده و جزئیات آن در گزارش اشکال‌زدایی در دسترس است.
RBAC_HTTP_AUTH_REJECT
0.0
3.5
Role configuration '%1' for role '%2' has rejected command '%3'.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که دستور در callout مربوط به http_auth
رد شده است. نام پیکربندی نقش، نام نقش و دستور نمایش داده می‌شوند.
RBAC_HTTP_AUTH_RESPONSE
0.0
3.5
RBAC hooks library has returned response: %1.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه هوک‌های RBAC پاسخی در callout مربوط
به http_auth بازگردانده است. پاسخ به صورت خلاصه بیان می‌شود.
RBAC_HTTP_RESPONSE_FAILED
0.0
3.5
RBAC processing in http_response callout failed for unexpected condition: %1.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه هوک‌های RBAC در نقطه callout مربوط به
http_response با یک وضعیت غیرمنتظره مواجه شده است. علت شکست به طور خلاصه
بیان شده و جزئیات آن در گزارش اشکال‌زدایی در دسترس است.
RBAC_LOAD_FAILED
0.0
3.5
RBAC hooks library failed to load: %1.
168u
168u
این پیام خطا نشان می‌دهد که هنگام بارگذاری کتابخانه هوک‌های RBAC خطایی
رخ داده است. آرگومان جزئیات خطا را شرح می‌دهد.
RBAC_LOAD_OK
0.0
3.5
RBAC hooks library loaded successfully.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه هوک‌های RBAC با موفقیت
بارگذاری شده است..SS RBAC_READ_API_FILES
0.0
3.5
RBAC hooks library read API files from '%1' getting %2 commands, %3 access types and %4 hooks.
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانه RBAC hooks فایل‌های API را از دایرکتوری پیکربندی‌شده خوانده است. نام دایرکتوری و برخی آمارها نمایش داده می‌شوند.
RBAC_TRACE_HTTP_AUTH_ACCEPT
0.0
3.5
Role configuration '%1' for role '%2' has accepted command '%3'.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
دستور در کال‌اوت http_auth پذیرفته شده است. نام پیکربندی نقش، نام نقش و دستور نمایش داده می‌شوند.
RBAC_TRACE_HTTP_AUTH_BAD_BODY_TYPE
0.0
3.5
Bad body type in JSON request in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth با نوع بدنه (body type) نادرست در درخواست JSON فراخوانی شده است. کتابخانه RBAC hooks بلافاصله بازمی‌گردد. این وضعیت یک خطا است.
RBAC_TRACE_HTTP_AUTH_BAD_COMMAND_TYPE
0.0
3.5
Bad command type in JSON request in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth با نوع دستور (command type) نادرست در درخواست JSON فراخوانی شده است. کتابخانه RBAC hooks بلافاصله بازمی‌گردد. این وضعیت یک خطا است.
RBAC_TRACE_HTTP_AUTH_COMMAND
0.0
3.5
Command '%1' in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth با دستور نمایش‌داده‌شده فراخوانی شده است.
RBAC_TRACE_HTTP_AUTH_DISABLED
0.0
3.5
RBAC hooks library is disabled in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth در شرایطی فراخوانی شده است که کتابخانه RBAC hooks غیرفعال است؛ یعنی هیچ نقشی اختصاص نیافته است.
RBAC_TRACE_HTTP_AUTH_EMPTY_BODY
0.0
3.5
Empty body in JSON request in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth با بدنه خالی در درخواست JSON فراخوانی شده است. کتابخانه RBAC hooks بلافاصله بازمی‌گردد. این وضعیت یک خطا است.
RBAC_TRACE_HTTP_AUTH_NO_COMMAND
0.0
3.5
No command entry in JSON request in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth بدون مدخل دستور در درخواست JSON فراخوانی شده است. کتابخانه RBAC hooks بلافاصله بازمی‌گردد. این وضعیت یک خطا است.
RBAC_TRACE_HTTP_AUTH_NO_JSON
0.0
3.5
No JSON request in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth با درخواستی غیر از JSON فراخوانی شده است. کتابخانه RBAC hooks بلافاصله بازمی‌گردد. این وضعیت یک خطا است.
RBAC_TRACE_HTTP_AUTH_NO_REQUEST
0.0
3.5
No request in http_auth callout.
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
کال‌اوت http_auth بدون هیچ درخواستی فراخوانی شده است. کتابخانه RBAC hooks بلافاصله بازمی‌گردد. این وضعیت یک خطا است..SS RBAC_TRACE_HTTP_AUTH_NO_TLS_REJECT
0.0
3.5
درخواست غیر TLS رد شده است.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
درخواست غیر TLS در فراخوانی http_auth رد شده است.
RBAC_TRACE_HTTP_AUTH_RESPONSE
0.0
3.5
پاسخ در فراخوانی http_auth: %1.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
فراخوانی http_auth همراه با یک پاسخ فراخوانی شده است. کتابخانه قلاب‌های RBAC
بلافاصله بازمی‌گردد. پاسخ خلاصه شده است.
RBAC_TRACE_HTTP_AUTH_ROLE
0.0
3.5
نقش '%1' در فراخوانی http_auth تخصیص داده شد.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
نقش نمایش‌داده‌شده در فراخوانی http_auth تخصیص داده شده است.
RBAC_TRACE_HTTP_RESPONSE_BAD_BODY_TYPE
0.0
3.5
نوع بدنه نادرست در پاسخ JSON در فراخوانی http_response.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
فراخوانی http_response با یک نوع بدنه نادرست در پاسخ JSON فراخوانی شده است
که احتمالاً یک پاسخ خطا است. کتابخانه قلاب‌های RBAC
بلافاصله بازمی‌گردد.
RBAC_TRACE_HTTP_RESPONSE_CONTEXT
0.0
3.5
دستور '%1' و پیکربندی نقش '%2' در فراخوانی http_response بازیابی شد.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
دستور و پیکربندی نقش از زمینه درخواست بازیابی شده‌اند.
آن‌ها نمایش داده می‌شوند.
RBAC_TRACE_HTTP_RESPONSE_DISABLED
0.0
3.5
کتابخانه قلاب‌های RBAC در فراخوانی http_response غیرفعال است.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
فراخوانی http_response با غیرفعال بودن کتابخانه قلاب‌های RBAC،
یعنی بدون تخصیص هیچ نقشی، فراخوانی شده است.
RBAC_TRACE_HTTP_RESPONSE_EMPTY_BODY
0.0
3.5
بدنه خالی در پاسخ JSON در فراخوانی http_response.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
فراخوانی http_response با یک بدنه خالی در پاسخ JSON فراخوانی شده است.
کتابخانه قلاب‌های RBAC بلافاصله بازمی‌گردد. این یک
وضعیت خطا است.
RBAC_TRACE_HTTP_RESPONSE_EMPTY_BODY_LIST
0.0
3.5
فهرست خالی در پاسخ JSON در فراخوانی http_response.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
فراخوانی http_response با یک فهرست بدنه خالی در پاسخ JSON فراخوانی
شده است. کتابخانه قلاب‌های RBAC بلافاصله بازمی‌گردد. این یک وضعیت
خطا است.
RBAC_TRACE_HTTP_RESPONSE_MODIFIED
0.0
3.5
پاسخ توسط یک فیلتر پاسخ در فراخوانی http_response تغییر یافته است.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
یک فیلتر پاسخ، پاسخ HTTP را در فراخوانی http_response تغییر داده است.
RBAC_TRACE_HTTP_RESPONSE_NO_ARGUMENTS
0.0
3.5
هیچ درخواست یا پاسخی در فراخوانی http_response وجود ندارد.
168u
168u
در سطح لاگ دیباگ ۴۰ ثبت می‌شود.
فراخوانی http_response بدون درخواست یا پاسخ فراخوانی شده است. کتابخانه
قلاب‌های RBAC بلافاصله بازمی‌گردد. این یک وضعیت خطا است..SS RBAC_UNLOAD_OK
0.0
3.5
RBAC hooks library unloaded successfully.
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های (hooks) RBAC با موفقیت تخلیه (unload) شده است.
RUN
RUN_SCRIPT_LOAD
0.0
3.5
Run Script hooks library has been loaded
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های Run Script بارگذاری شده است.
RUN_SCRIPT_LOAD_ERROR
0.0
3.5
Run Script hooks library failed: %1
168u
168u
این پیام خطا نشان‌دهنده بروز خطا هنگام بارگذاری کتابخانه قلاب‌های Run Script است. جزئیات خطا به عنوان آرگومان پیام گزارش ارائه شده است.
RUN_SCRIPT_UNLOAD
0.0
3.5
Run Script hooks library has been unloaded
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانه قلاب‌های RunScript تخلیه شده است.
SFLQ
SFLQ_POOL4_DEL
0.0
3.5
sflq-pool4-del command succeeded, (parameters: %1) pools deleted: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۲۰ ثبت می‌شود.
دستور sflq-pool4-del با موفقیت اجرا شد. این دستور، آرگومان‌های فراخوانی را به همراه تعداد استخرهای (pools) حذف‌شده نمایش می‌دهد.
SFLQ_POOL4_DEL_FAILED
0.0
3.5
sflq-pool4-del command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool4-del با شکست مواجه شد. هم علت خطا و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
SFLQ_POOL4_GET_ALL
0.0
3.5
sflq-pool4-get-all command succeeded, pools found: %1
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۲۰ ثبت می‌شود.
دستور sflq-pool4-get-all با موفقیت اجرا شد.
SFLQ_POOL4_GET_ALL_FAILED
0.0
3.5
sflq-pool4-get-all command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool4-get-all با شکست مواجه شد. هم علت خطا و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
SFLQ_POOL4_GET_BY_RANGE
0.0
3.5
sflq-pool4-get-by-range command succeeded, (parameters: %1) pools found: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug log level) ۲۰ ثبت می‌شود.
دستور sflq-pool4-get-by-range با موفقیت اجرا شد.
SFLQ_POOL4_GET_BY_RANGE_FAILED
0.0
3.5
sflq-pool4-get-by-range command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool4-get-range با شکست مواجه شد. هم علت خطا و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند..SS SFLQ_POOL4_GET_BY_SUBNET
0.0
3.5
sflq-pool4-get-by-subnet command succeeded, (parameters: %1) pools found: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور sflq-pool4-get-by-subnet موفقیت‌آمیز بود.
SFLQ_POOL4_GET_BY_SUBNET_FAILED
0.0
3.5
sflq-pool4-get-by-subnet command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool4-get-subnet با شکست مواجه شد. هم دلیل شکست و هم پارامترهای
ارسال‌شده در لاگ ثبت می‌شوند.
SFLQ_POOL4_REBUILD
0.0
3.5
sflq-pool4-rebuild command succeeded, (parameters: %1) pools rebuilt: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور sflq-pool4-rebuild موفقیت‌آمیز بود. این پیام آرگومان‌های دستور
را به همراه تعداد استخرهای بازسازی‌شده چاپ می‌کند.
SFLQ_POOL4_REBUILD_FAILED
0.0
3.5
sflq-pool4-rebuild command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool4-rebuild با شکست مواجه شد. هم دلیل شکست و هم پارامترهای
ارسال‌شده در لاگ ثبت می‌شوند.
SFLQ_POOL6_DEL
0.0
3.5
sflq-pool4-del command succeeded, (parameters: %1) pools deleted: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور sflq-pool6-del موفقیت‌آمیز بود. این پیام آرگومان‌های دستور
را به همراه تعداد استخرهای حذف‌شده چاپ می‌کند.
SFLQ_POOL6_DEL_FAILED
0.0
3.5
sflq-pool4-del command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool6-del با شکست مواجه شد. هم دلیل شکست و هم پارامترهای
ارسال‌شده در لاگ ثبت می‌شوند.
SFLQ_POOL6_GET_ALL
0.0
3.5
sflq-pool6-get-all command succeeded, pools found: %1
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور sflq-pool6-rebuild موفقیت‌آمیز بود.
SFLQ_POOL6_GET_ALL_FAILED
0.0
3.5
sflq-pool6-get-all command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool6-get-all با شکست مواجه شد. هم دلیل شکست و هم پارامترهای
ارسال‌شده در لاگ ثبت می‌شوند.
SFLQ_POOL6_GET_BY_RANGE
0.0
3.5
sflq-pool6-get-by-range command succeeded, (parameters: %1) pools found: %2
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور sflq-pool6-get-by-range موفقیت‌آمیز بود.
SFLQ_POOL6_GET_BY_RANGE_FAILED
0.0
3.5
sflq-pool6-get-by-range command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool6-get-range با شکست مواجه شد. هم دلیل شکست و هم پارامترهای
ارسال‌شده در لاگ ثبت می‌شوند..SS SFLQ_POOL6_GET_BY_SUBNET
0.0
3.5
sflq-pool6-get-by-subnet command succeeded, (parameters: %1) pools found: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور sflq-pool6-get-by-subnet موفقیت‌آمیز بود.
SFLQ_POOL6_GET_BY_SUBNET_FAILED
0.0
3.5
sflq-pool6-get-by-subnet command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool6-get-subnet با شکست مواجه شده است. هم دلیل و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
SFLQ_POOL6_REBUILD
0.0
3.5
sflq-pool6-rebuild command succeeded, (parameters: %1) pools rebuilt: %2
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۲۰ ثبت می‌شود.
دستور sflq-pool6-rebuild موفقیت‌آمیز بود. این پیام آرگومان‌های دستور را به همراه تعداد استخرهای (pools) بازسازی‌شده چاپ می‌کند.
SFLQ_POOL6_REBUILD_FAILED
0.0
3.5
sflq-pool6-rebuild command failed, (parameters: %1, reason: %2)
168u
168u
دستور sflq-pool6-rebuild با شکست مواجه شده است. هم دلیل و هم پارامترهای ارسال‌شده در گزارش ثبت می‌شوند.
START
START_REKEY_TIMER
0.0
3.5
started timer handling rekey for server %1 in %2 seconds.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام راه‌اندازی تایمر تولید مجدد کلید (rekey timer) برای مدیریت کلیدهای جدید این سرور صادر می‌شود، زمانی که در حال حاضر دست‌کم یک کلید موجود است. آرگومان نخست شناسهٔ سرور و آرگومان دوم بازهٔ زمانی را مشخص می‌کند که تلاش بعدی برای پردازش کلید در آن صورت خواهد گرفت.
START_RETRY_TIMER
0.0
3.5
started timer handling retry for server %1 in %2 seconds.
168u
168u
در سطح گزارش اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی هنگام راه‌اندازی تایمر تلاش مجدد (retry timer) برای مدیریت کلیدهای جدید این سرور صادر می‌شود، زمانی که در حال حاضر هیچ کلیدی موجود نیست. آرگومان نخست شناسهٔ سرور و آرگومان دوم بازهٔ زمانی را مشخص می‌کند که تلاش بعدی برای پردازش کلید در آن صورت خواهد گرفت.
STAT
STAT_CMDS_DEINIT_OK
0.0
3.5
unloading Stat Commands hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانهٔ قلاب‌های (hooks library) Stat Commands با موفقیت حذف شده است.
STAT_CMDS_INIT_OK
0.0
3.5
loading Stat Commands hooks library successful
168u
168u
این پیام اطلاعاتی نشان می‌دهد که کتابخانهٔ قلاب‌های Stat Commands با موفقیت بارگذاری شده است. لذت ببرید!
STAT_CMDS_LEASE4_FAILED
0.0
3.5
stat-lease4-get command failed: reason: %1
168u
168u
دستور stat-lease4-get با شکست مواجه شده است. علت شکست در گزارش ثبت می‌شود.
STAT_CMDS_LEASE4_GET
0.0
3.5
stat-lease4-get command successful, parameters: %1 rows found: %2
168u
168u
دستور stat-lease4-get با موفقیت انجام شده است. گزارش شامل پارامترهای ارائه‌شده و تعداد سطرهای یافت‌شده خواهد بود..SS STAT_CMDS_LEASE4_GET_FAILED
0.0
3.5
stat-lease4-get command failed: parameters: %1, reason: %2
168u
168u
دستور stat-lease4-get با شکست مواجه شده است. پارامترهای ارائه‌شده و دلیل شکست هر دو ثبت می‌شوند.
STAT_CMDS_LEASE4_GET_INVALID
0.0
3.5
stat-lease4-get command is malformed or invalid, reason: %1
168u
168u
دستور stat-lease4-get ساختار نادرستی داشته یا حاوی پارامترهای نامعتبر بوده است. توضیحات دقیق‌تر باید ثبت شود.
STAT_CMDS_LEASE4_GET_NO_SUBNETS
0.0
3.5
stat-lease4-get, parameters: %1, %2"
168u
168u
پارامترهای ارسال‌شده به همراه stat-lease4-get معتبر بودند اما همه زیرشبکه‌های شناخته‌شده را مستثنی کردند. پارامترهای ارائه‌شده به همراه توضیحات باید ثبت شوند.
STAT_CMDS_LEASE4_ORPHANED_STATS
0.0
3.5
stat-lease4-get command omitted statistics for one or more non-existent subnets
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
در حین پردازش، دستور stat-lease4-get آمارهایی را برای شناسه‌های زیرشبکه مربوط به زیرشبکه‌های ناموجود پیدا کرد. این مقادیر از پاسخ بازگردانده‌شده دستور به کاربر حذف شدند. این مسئله ممکن است زمانی رخ دهد که زیرشبکه‌ها به‌گونه‌ای از پیکربندی حذف شده باشند که آمار آن‌ها حذف نشده باشد. اگرچه وجود چنین آمارهایی زیان‌آور نیست، اما باید اقداماتی برای حذف آن‌ها در نظر گرفته شود. برای فضای ذخیره‌سازی اجاره memfile، این مشکل پس از بارگذاری مجدد پیکربندی یا راه‌اندازی دوباره سرور باید برطرف شود. برای ذخیره‌سازی اجاره در پایگاه‌داده (database) این مسئله پیچیده‌تر است و تا نسخه Kea 2.0.0 هنوز راه‌حل تر و تمیزی برای آن وجود ندارد.
STAT_CMDS_LEASE6_FAILED
0.0
3.5
stat-lease6-get command failed: reason: %1
168u
168u
دستور stat-lease6-get با شکست مواجه شده است. دلیل شکست ثبت می‌شود.
STAT_CMDS_LEASE6_GET
0.0
3.5
stat-lease6-get command successful, parameters: %1 rows found: %2
168u
168u
دستور stat-lease6-get با موفقیت انجام شد. گزارش حاوی پارامترهای ارائه‌شده و تعداد ردیف‌های یافت‌شده خواهد بود.
STAT_CMDS_LEASE6_GET_FAILED
0.0
3.5
stat-lease6-get command failed: parameters: %1, reason: %2
168u
168u
دستور stat-lease6-get با شکست مواجه شده است. پارامترهای ارائه‌شده و دلیل شکست هر دو ثبت می‌شوند.
STAT_CMDS_LEASE6_GET_INVALID
0.0
3.5
stat-lease6-get command is malformed or invalid, reason: %1
168u
168u
دستور stat-lease6-get ساختار نادرستی داشته یا حاوی پارامترهای نامعتبر بوده است. توضیحات دقیق‌تر باید ثبت شود.
STAT_CMDS_LEASE6_GET_NO_SUBNETS
0.0
3.5
stat-lease6-get, parameters: %1, %2"
168u
168u
پارامترهای ارسال‌شده به همراه stat-lease6-get معتبر بودند اما همه زیرشبکه‌های شناخته‌شده را مستثنی کردند. پارامترهای ارائه‌شده به همراه توضیحات باید ثبت شوند.
STAT_CMDS_LEASE6_ORPHANED_STATS
0.0
3.5
stat-lease6-get command omitted statistics for one or more non-existent subnets
168u
168u
در سطح لاگ اشکال‌زدایی (debug) ۴۰ ثبت می‌شود.
در حین پردازش، دستور stat-lease4-get آمارهایی را برای شناسه‌های زیرشبکه مربوط به زیرشبکه‌های ناموجود پیدا کرد. این مقادیر از پاسخ بازگردانده‌شده دستور به کاربر حذف شدند. این مسئله ممکن است زمانی رخ دهد که زیرشبکه‌ها به‌گونه‌ای از پیکربندی حذف شده باشند که آمار آن‌ها حذف نشده باشد. اگرچه وجود چنین آمارهایی زیان‌آور نیست، اما باید اقداماتی برای حذف آن‌ها در نظر گرفته شود. برای فضای ذخیره‌سازی اجاره memfile، این مشکل پس از بارگذاری مجدد پیکربندی یا راه‌اندازی دوباره سرور باید برطرف شود. برای ذخیره‌سازی اجاره در پایگاه‌داده (database) این مسئله پیچیده‌تر است و تا نسخه Kea 2.0.0 هنوز راه‌حل تر و تمیزی برای آن وجود ندارد..SS SUBNET
SUBNET_CMDS_DEINIT_OK
0.0
3.5
unloading Subnet Commands hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانهٔ قلاب‌های Host Commands با موفقیت تخلیه شده است.
SUBNET_CMDS_INIT_FAILED
0.0
3.5
loading Subnet Commands hooks library failed: %1
168u
168u
این پیام خطا نشان‌دهندهٔ بروز خطا در حین بارگذاری کتابخانهٔ قلاب‌های Subnet Commands است. جزئیات خطا به عنوان آرگومان پیام گزارش ارائه شده است.
SUBNET_CMDS_INIT_OK
0.0
3.5
loading Subnet Commands hooks library successful
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که کتابخانهٔ قلاب‌های Host Commands با موفقیت بارگذاری شده است. لذت ببرید!
SUBNET_CMDS_NETWORK4_ADD_FAILED
0.0
3.5
failed to add new IPv4 network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانهٔ قلاب‌های Subnet Commands در افزودن یک شبکهٔ IPv4 جدید به پیکربندی کارگزار با شکست مواجه شود. دلیل شکست در پیام خطا ارائه شده است. این پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK4_DEL_FAILED
0.0
3.5
failed to delete IPv4 network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانهٔ قلاب‌های Subnet Commands در حذف یک شبکهٔ IPv4 با شکست مواجه شود. دلیل شکست در پیام خطا ارائه شده است. این پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK4_GET_FAILED
0.0
3.5
failed to return an IPv4 network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کارگزار در بازگرداندن یک شبکهٔ IPv4 در پاسخ به دستور 'network4-get' با شکست مواجه شود. آرگومان مربوطه جزئیات دلیل شکست را مشخص می‌کند. این پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد. این خطا ممکن است زمانی رخ دهد که دستور دریافتی ساختاری نامعتبر داشته باشد، دارای پارامترهای غیرمجاز باشد یا فاقد پارامترهای الزامی باشد. این خطا همچنین زمانی بازگردانده می‌شود که نحو دستور درست باشد اما هیچ شبکه‌ای یافت نشود.
SUBNET_CMDS_NETWORK4_LIST_FAILED
0.0
3.5
failed to return a list of IPv4 networks: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانهٔ قلاب‌های Subnet Commands در بازگرداندن فهرست شبکه‌های IPv4 درخواست‌شده با دستور 'network4-list' با شکست مواجه شود. دلیل شکست در پیام خطا ارائه شده است. این پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK4_SUBNET_ADD_FAILED
0.0
3.5
failed to add existing IPv4 subnet to a shared network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانهٔ قلاب‌های Subnet Commands در افزودن یک زیرشبکهٔ IPv4 موجود به یک شبکهٔ اشتراکی موجود با شکست مواجه شود. دلیل شکست در پیام خطا ارائه شده است. این پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK4_SUBNET_DEL_FAILED
0.0
3.5
failed to remove a IPv4 subnet from a shared network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانهٔ قلاب‌های Subnet Commands در حذف یک زیرشبکهٔ IPv4 موجود از یک شبکهٔ اشتراکی موجود با شکست مواجه شود. دلیل شکست در پیام خطا ارائه شده است. این پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد..SS SUBNET_CMDS_NETWORK6_ADD_FAILED
0.0
3.5
failed to add new IPv6 network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در افزودن یک شبکه IPv6 جدید به پیکربندی سرور با شکست مواجه شود. دلیل شکست در متن پیام خطا ارائه شده است. پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK6_DEL_FAILED
0.0
3.5
failed to delete IPv6 network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در حذف یک شبکه IPv6 با شکست مواجه شود. دلیل شکست در متن پیام خطا ارائه شده است. پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK6_GET_FAILED
0.0
3.5
failed to return an IPv6 network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که سرور در بازگرداندن یک شبکه IPv6 در پاسخ به دستور 'network4-get' با شکست مواجه شود. این آرگومان جزئیات دلیل شکست را شرح می‌دهد. پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد. این خطا ممکن است زمانی رخ دهد که دستور دریافتی دارای ساختار نامعتبر باشد، شامل پارامترهای غیرمجاز باشد یا فاقد پارامترهای الزامی باشد. همچنین در صورتی که نحو دستوری صحیح باشد اما شبکه‌ای یافت نشود نیز این پیام بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK6_LIST_FAILED
0.0
3.5
failed to return a list of IPv6 networks: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در بازگرداندن فهرست شبکه‌های IPv4 درخواست‌شده با دستور 'network6-list' با شکست مواجه شود. دلیل شکست در متن پیام خطا ارائه شده است. پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK6_SUBNET_ADD_FAILED
0.0
3.5
failed to add existing IPv6 subnet to a shared network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در افزودن زیرشبکه IPv6 موجود به شبکه اشتراکی موجود با شکست مواجه شود. دلیل شکست در متن پیام خطا ارائه شده است. پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK6_SUBNET_DEL_FAILED
0.0
3.5
failed to remove a IPv6 subnet from a shared network: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در حذف زیرشبکه IPv6 موجود از شبکه اشتراکی موجود با شکست مواجه شود. دلیل شکست در متن پیام خطا ارائه شده است. پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_NETWORK_ADD
0.0
3.5
successfully added shared network %1
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در پی دریافت دستور 'network4-add' یا 'network6-add' یک شبکه اشتراکی را با موفقیت اضافه کند. این آرگومان نشان‌دهنده نام شبکه اشتراکی اضافه‌شده است.
SUBNET_CMDS_NETWORK_DEL
0.0
3.5
successfully deleted shared network %1
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در پی دریافت دستور 'network4-del' یا 'network6-del' یک شبکه اشتراکی را با موفقیت حذف کند. این آرگومان نشان‌دهنده نام شبکه اشتراکی حذف‌شده است.
SUBNET_CMDS_NETWORK_GET
0.0
3.5
successfully retrieved shared network %1
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در پی دریافت دستور 'network4-get' یا 'network6-get' یک شبکه اشتراکی را با موفقیت بازیابی کند. این آرگومان نشان‌دهنده نام شبکه اشتراکی بازیابی‌شده است..SS SUBNET_CMDS_NETWORK_GET_EMPTY
0.0
3.5
specified shared network is not found: %1
168u
168u
این پیام اطلاع‌رسانی هنگامی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در پی دریافت دستور 'network4-get' یا 'network6-get'، هیچ شبکه اشتراکی منطبقی را پیدا نکند.
SUBNET_CMDS_NETWORK_LIST
0.0
3.5
successfully retrieved list of %1 %2 shared networks
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در نتیجه دریافت دستور 'network4-list' یا 'network6-list'، فهرستی از شبکه‌های اشتراکی را با موفقیت بازیابی کند. آرگومان نخست، تعداد شبکه‌های بازیابی‌شده را مشخص می‌کند. پارامتر دوم نوع پروتکل را تعیین می‌کند: 'IPv4' یا 'IPv6'.
SUBNET_CMDS_NETWORK_LIST_EMPTY
0.0
3.5
no %1 shared networks listed
168u
168u
این پیام اطلاع‌رسانی هنگامی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands دستور 'network4-list' یا 'network6-list' را با موفقیت پردازش کند، اما هیچ شبکه اشتراکی پیدا نشود. این وضعیت نشان می‌دهد که پیکربندی سرور شامل هیچ شبکه اشتراکی از نوع مشخص‌شده نیست. آرگومان، نوع پروتکل را مشخص می‌کند: 'IPv4' یا 'IPv6'.
SUBNET_CMDS_NETWORK_SUBNET_ADD
0.0
3.5
%1 subnet %2 (id %3) added to shared network %4
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که زیرشبکه مشخص‌شده (خانواده آدرس در پارامتر ۱، و جزئیات در پارامترهای ۲ و ۳ مشخص شده است) اکنون بخشی از یک شبکه اشتراکی است. این رخداد، نتیجه موفقیت‌آمیز هر یک از دستورهای network4-subnet-add یا network6-subnet-add است.
SUBNET_CMDS_NETWORK_SUBNET_DEL
0.0
3.5
%1 subnet %2 (id %3) removed from shared network %4
168u
168u
این پیام اطلاع‌رسانی نشان می‌دهد که زیرشبکه مشخص‌شده (خانواده آدرس در پارامتر ۱، و جزئیات در پارامترهای ۲ و ۳ مشخص شده است) دیگر بخشی از یک شبکه اشتراکی نیست. زیرشبکه در پیکربندی باقی می‌ماند، اما به یک زیرشبکه مستقل تبدیل می‌شود. این رخداد، نتیجه موفقیت‌آمیز هر یک از دستورهای network4-subnet-del یا network6-subnet-del است.
SUBNET_CMDS_SUBNET4_ADD_FAILED
0.0
3.5
failed to add new IPv4 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands نتواند یک زیرشبکه IPv4 جدید به پیکربندی سرور اضافه کند. دلیل این شکست در متن پیام خطا ارائه می‌شود. پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET4_DELTA_ADD_FAILED
0.0
3.5
failed to update IPv4 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در به‌روزرسانی پیکربندی سرور از طریق افزودن دلتا به یک زیرشبکه IPv4 با شکست مواجه شود. دلیل این شکست در متن پیام خطا ارائه می‌شود. پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET4_DELTA_DEL_FAILED
0.0
3.5
failed to update IPv4 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در به‌روزرسانی پیکربندی سرور از طریق حذف دلتا در یک زیرشبکه IPv4 با شکست مواجه شود. دلیل این شکست در متن پیام خطا ارائه می‌شود. پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET4_DEL_FAILED
0.0
3.5
failed to delete IPv4 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه قلاب‌های Subnet Commands در حذف یک زیرشبکه IPv4 با شکست مواجه شود. دلیل این شکست در متن پیام خطا ارائه می‌شود. پیام خطا همراه با کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد..SS SUBNET_CMDS_SUBNET4_GET_FAILED
0.0
3.5
failed to return an IPv4 subnet: %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که سرور نتواند یک زیرشبکهٔ IPv4 را در پاسخ به دستور 'subnet4-get' بازگرداند. آرگومان مربوطه جزئیات دلیل شکست را شرح می‌دهد. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد. این خطا ممکن است زمانی رخ دهد که دستور دریافت شده ساختار نامعتبر داشته باشد، شامل پارامترهای غیرمجاز باشد یا پارامترهای ضروری را نداشته باشد. همچنین در صورتی که نحو دستور صحیح باشد اما هیچ زیرشبکه‌ای یافت نشود نیز این پیام بازگردانده می‌شود.
SUBNET_CMDS_SUBNET4_LIST_FAILED
0.0
3.5
failed to return a list of IPv4 subnets: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands نتواند فهرستی از زیرشبکه‌های IPv4 درخواست‌شده با دستور 'subnet4-list' را بازگرداند. علت شکست درون پیام خطا ارائه می‌شود. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET4_UPDATE_FAILED
0.0
3.5
failed to update IPv4 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands در به‌روزرسانی یک زیرشبکهٔ IPv4 در پیکربندی سرور با شکست مواجه شود. علت شکست درون پیام خطا ارائه می‌شود. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET6_ADD_FAILED
0.0
3.5
failed to add new IPv6 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands در افزودن یک زیرشبکهٔ جدید IPv6 به پیکربندی سرور با شکست مواجه شود. علت شکست درون پیام خطا ارائه می‌شود. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET6_DELTA_ADD_FAILED
0.0
3.5
failed to update IPv6 subnet: %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که کتابخانه هوک‌های Subnet Commands در به‌روزرسانی از طریق افزودن یک دلتا در زیرشبکهٔ IPv6 به پیکربندی سرور با شکست مواجه شود. علت شکست درون پیام خطا ارائه می‌شود. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET6_DELTA_DEL_FAILED
0.0
3.5
failed to update IPv6 subnet: %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که کتابخانه هوک‌های Subnet Commands در به‌روزرسانی از طریق حذف یک دلتا در زیرشبکهٔ IPv6 از پیکربندی سرور با شکست مواجه شود. علت شکست درون پیام خطا ارائه می‌شود. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET6_DEL_FAILED
0.0
3.5
failed to delete IPv6 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands در حذف یک زیرشبکهٔ IPv6 با شکست مواجه شود. علت شکست درون پیام خطا ارائه می‌شود. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET6_GET_FAILED
0.0
3.5
failed to return an IPv6 subnet: %1
168u
168u
این پیام خطا هنگامی صادر می‌شود که سرور نتواند یک زیرشبکهٔ IPv6 را در پاسخ به دستور 'subnet4-get' بازگرداند. آرگومان مربوطه جزئیات دلیل شکست را شرح می‌دهد. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد. این خطا ممکن است زمانی رخ دهد که دستور دریافت شده ساختار نامعتبر داشته باشد، شامل پارامترهای غیرمجاز باشد یا پارامترهای ضروری را نداشته باشد. همچنین در صورتی که نحو دستور درست باشد اما هیچ زیرشبکه‌ای پیدا نشود نیز بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET6_LIST_FAILED
0.0
3.5
failed to return a list of IPv6 subnets: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands نتواند فهرستی از زیرشبکه‌های IPv6 درخواست‌شده با دستور 'subnet6-list' را بازگرداند. علت شکست درون پیام خطا ارائه می‌شود. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد..SS SUBNET_CMDS_SUBNET6_UPDATE_FAILED
0.0
3.5
failed to update IPv6 subnet: %1
168u
168u
این پیام خطا زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands نتواند یک زیرشبکه IPv6 را در پیکربندی سرور به‌روزرسانی کند. دلیل این شکست درون پیام خطا مشخص شده است. این پیام خطا به همراه کد وضعیت خطا به کلاینت کنترل‌کننده بازگردانده خواهد شد.
SUBNET_CMDS_SUBNET_ADD
0.0
3.5
successfully added subnet %1 having id %2
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands یک زیرشبکه را در نتیجه دریافت دستور 'subnet4-add' یا 'subnet6-add' با موفقیت اضافه کند. پارامتر نخست، پیشوند زیرشبکه اضافه‌شده را مشخص می‌کند. پارامتر دوم، شناسه زیرشبکه را مشخص می‌سازد.
SUBNET_CMDS_SUBNET_DEL
0.0
3.5
successfully deleted subnet %1 having id %2
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands یک زیرشبکه را در نتیجه دریافت دستور 'subnet4-del' یا 'subnet6-del' با موفقیت حذف کند. پارامتر نخست، پیشوند زیرشبکه حذف‌شده را مشخص می‌کند. پارامتر دوم، شناسه زیرشبکه را مشخص می‌سازد.
SUBNET_CMDS_SUBNET_GET
0.0
3.5
successfully retrieved subnet %1 having id %2
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands یک زیرشبکه را در نتیجه دریافت دستور 'subnet4-get' یا 'subnet6-get' با موفقیت بازیابی کند. پارامتر نخست، پیشوند زیرشبکه بازیابی‌شده را مشخص می‌کند. پارامتر دوم، شناسه زیرشبکه را مشخص می‌سازد.
SUBNET_CMDS_SUBNET_GET_EMPTY
0.0
3.5
specified subnet is not found: %1
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands در نتیجه دریافت دستور 'subnet4-get' یا 'subnet6-get' هیچ زیرشبکه منطبقی نیابد.
SUBNET_CMDS_SUBNET_LIST
0.0
3.5
successfully retrieved list of %1 %2 subnets
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands فهرستی از زیرشبکه‌ها را در نتیجه دریافت دستور 'subnet4-list' یا 'subnet6-list' با موفقیت بازیابی کند. آرگومان نخست، تعداد زیرشبکه‌های بازیابی‌شده را مشخص می‌کند. پارامتر دوم، نوع پروتکل را تعیین می‌کند: 'IPv4' یا 'IPv6'.
SUBNET_CMDS_SUBNET_LIST_EMPTY
0.0
3.5
no %1 subnets listed
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands دستور 'subnet4-list' یا 'subnet6-list' را با موفقیت پردازش کند، اما هیچ زیرشبکه‌ای یافت نشود. این امر نشان می‌دهد که پیکربندی سرور شامل هیچ زیرشبکه‌ای از این نوع خاص نیست. این وضعیت یک حالت خطا محسوب نمی‌شود، اما برای سرویس DHCP موردی غیرمعمول است. این آرگومان نوع زیرشبکه‌های فهرست‌شده را مشخص می‌کند، یعنی 'IPv4' یا 'IPv6'.
SUBNET_CMDS_SUBNET_UPDATE
0.0
3.5
successfully updated subnet %1 having id %2
168u
168u
این پیام اطلاعاتی زمانی صادر می‌شود که کتابخانه هوک‌های Subnet Commands یک زیرشبکه را در نتیجه دریافت دستور 'subnet4-update' یا 'subnet6-update' با موفقیت به‌روزرسانی کند. پارامتر نخست، پیشوند زیرشبکه به‌روزرسانی‌شده را مشخص می‌کند. پارامتر دوم، شناسه زیرشبکه را مشخص می‌سازد.
TCP
TCP_CLIENT_BAD_SERVER_RESPONSE_RECEIVED
0.0
3.5
bad response received when communicating with %1 port %2: %3
168u
168u
در سطح ۴۰ ثبت گزارش اشکال‌زدایی (debug) ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک کلاینت TCP موفق به دریافت پاسخ از سرور نشود یا پاسخ دریافتی ناهنجار و معیوب باشد. آرگومان‌های نخست، آدرس و پورت سرور را مشخص می‌کنند. آرگومان آخر پیام خطای تفصیلی را ارائه می‌دهد..SS TCP_CLIENT_BAD_SERVER_RESPONSE_RECEIVED_DETAILS
0.0
3.5
detailed information about bad response received from %1 port %2:\n%3
168u
168u
در سطح گزارش اشکال‌زدایی ۴۵ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک کلاینت TCP پاسخی بدشکل (malformed) از کارساز دریافت کند. آرگومان‌های نخست نشانی و درگاه کارساز را مشخص می‌کنند؛ آرگومان آخر رونوشتی (dump) از پاسخ را ارائه می‌دهد.
TCP_CLIENT_CONNECTION_CLOSE_CALLBACK_FAILED
0.0
3.5
Connection close callback threw an exception
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که کالبک (callback) بستن اتصال که روی اتصال ثبت شده بود، به‌طور غیرمنتظره‌ای شکست بخورد. این یک خطای برنامه‌نویسی است که باید به‌عنوان یک باگ گزارش شود.
TCP_CLIENT_MT_STARTED
0.0
3.5
TcpClient has been started in multi-threaded mode running %1 threads
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یک نمونه کلاینت چندنخی (multi-threaded) TCP ایجاد شده باشد. این آرگومان حداکثر تعداد نخ‌ها را مشخص می‌کند.
TCP_CLIENT_PREMATURE_CONNECTION_TIMEOUT_OCCURRED
0.0
3.5
premature connection timeout occurred: in transaction ? %1, transid: %2, current_transid: %3
168u
168u
این پیام هشدار زمانی صادر می‌شود که در طول تراکنش، اتمام مهلت (timeout) پیش‌رس و غیرمنتظره‌ای رخ دهد. ثابت شده است که این اتفاق زمانی رخ می‌دهد که ساعت سیستم به‌صورت دستی یا در نتیجه همگام‌سازی با یک کارساز زمان (time server) تغییر داده شود. هر تراکنش در حال انجامی قطع خواهد شد. تراکنش‌های جدید باید به‌طور عادی انجام شوند.
TCP_CLIENT_QUEUE_SIZE_GROWING
0.0
3.5
queue for address: %1, port %2, now has %3 entries and may be growing too quickly
168u
168u
این پیام هشدار زمانی صادر می‌شود که به نظر برسد صف درخواست‌های معلق برای نشانی و درگاه داده‌شده، سریع‌تر از توان پردازش درخواست‌ها در حال رشد است. تا زمانی که اندازه صف به رشد خود ادامه دهد، این پیام به‌صورت دوره‌ای صادر خواهد شد. این وضعیت ممکن است به دلیل هجوم ناگهانی ترافیک کلاینت‌ها رخ دهد که انباشتگی موقتی ایجاد می‌کند و سپس با فروکش کردن ترافیک برطرف می‌شود. اگر این اتفاق به‌طور مداوم رخ دهد، به احتمال زیاد نشان‌دهنده پیکربندی استقراری است که توان تحمل بار کلاینت‌ها را ندارد.
TCP_CLIENT_REQUEST_SEND
0.0
3.5
sending TCP request %1 to %2 port %3
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کلاینت شروع به ارسال یک درخواست TCP به یک کارساز می‌کند. آرگومان نخست رونوشتی از درخواست را نشان می‌دهد و آرگومان‌های بعدی نشانی و درگاه کارساز را مشخص می‌کنند.
TCP_CLIENT_SERVER_RESPONSE_RECEIVED
0.0
3.5
received TCP response from %1 port %2
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کلاینت دریافت پاسخ TCP از کارساز را به پایان برساند. نشانی و درگاه کارساز به‌عنوان آرگومان مشخص می‌شوند.
TCP_CONNECTION_REJECTED_BY_FILTER
0.0
3.5
connection from %1 has been denied by the connection filter.
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که فیلتر اتصال کارساز، اتصال جدیدی را بر اساس نشانی IP کلاینت رد کند.
TCP_CONNECTION_SHUTDOWN
0.0
3.5
shutting down TCP connection from %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که یکی از اتصالات TCP متوقف (بسته) شود. این اتصال می‌تواند در نتیجه یک خطا یا پس از تبادل موفق پیام با یک کلاینت متوقف شود..SS TCP_CONNECTION_SHUTDOWN_FAILED
0.0
3.5
shutting down TCP connection failed
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام قطع یک اتصال TCP با کلاینت، خطایی رخ داده باشد.
TCP_CONNECTION_STOP
0.0
3.5
stopping TCP connection from %1
168u
168u
در سطح لاگ دیباگ 40 ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که یکی از اتصال‌های TCP متوقف شود.
اتصال ممکن است در نتیجه یک خطا یا پس از تبادل موفقیت‌آمیز پیام با کلاینت متوقف گردد.
TCP_CONNECTION_STOP_FAILED
0.0
3.5
stopping TCP connection failed
168u
168u
این پیام خطا زمانی صادر می‌شود که هنگام بستن یک اتصال TCP با کلاینت، خطایی رخ داده باشد.
TCP_DATA_RECEIVED
0.0
3.5
received %1 bytes from %2
168u
168u
در سطح لاگ دیباگ 55 ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور بخشی از داده‌ها را از نقطه پایانی راه دور (remote endpoint) دریافت کند. این داده‌ها ممکن است شامل کل درخواست یا تنها بخشی از آن باشند. آرگومان نخست، مقدار داده‌های دریافت‌شده را مشخص می‌کند. آرگومان دوم، آدرس نقطه پایانی راه دور را که داده‌ها را تولید کرده است، مشخص می‌سازد.
TCP_DATA_SENT
0.0
3.5
send %1 bytes to %2
168u
168u
در سطح لاگ دیباگ 55 ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور بخشی از داده‌ها را به نقطه پایانی راه دور ارسال کند. این داده‌ها ممکن است شامل کل پاسخ یا تنها بخشی از آن باشند. آرگومان نخست، مقدار داده‌های ارسالی را مشخص می‌کند. آرگومان دوم، آدرس نقطه پایانی راه دور را مشخص می‌سازد.
TCP_IDLE_CONNECTION_TIMEOUT_OCCURRED
0.0
3.5
closing connection with %1 as a result of a timeout
168u
168u
در سطح لاگ دیباگ 50 ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که اتصال TCP به دلیل بیکار بودن (idle) بسته شود.
TCP_REQUEST_RECEIVED_FAILED
0.0
3.5
An unexpected error occurred processing a request from %1, error: %2
168u
168u
این پیام خطا هنگامی صادر می‌شود که در حین تلاش سرور برای پردازش یک درخواست دریافت‌شده، خطایی غیرمنتظره رخ دهد. آرگومان نخست، آدرس نقطه پایانی راه دور را مشخص می‌کند. آرگومان دوم، ماهیت خطا را شرح می‌دهد.
TCP_REQUEST_RECEIVE_START
0.0
3.5
start receiving request from %1 with timeout %2
168u
168u
در سطح لاگ دیباگ 50 ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که سرور شروع به دریافت درخواستی جدید از طریق اتصال برقرارشده کند. آرگومان نخست، آدرس نقطه پایانی راه دور را مشخص می‌کند. آرگومان دوم، مهلت زمانی (timeout) درخواست را بر حسب ثانیه مشخص می‌سازد.
TCP_SERVER_CLIENT_REQUEST_RECEIVED
0.0
3.5
received TCP request from %1
168u
168u
در سطح لاگ دیباگ 40 ثبت می‌شود.
این پیام دیباگ زمانی صادر می‌شود که دریافت درخواست TCP از نقطه پایانی راه دور توسط سرور به پایان رسیده باشد. آدرس نقطه پایانی راه دور به عنوان آرگومان مشخص شده است..SS TCP_SERVER_RESPONSE_SEND
0.0
3.5
sending TCP response to %1
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارساز در حال آغاز ارسال یک پاسخ TCP
به یک نقطهٔ پایانی دوردست است. آرگومان، نشانی نقطهٔ
پایانی دوردست را مشخص می‌کند.
TKEY
TKEY_EXCHANGE_ANSWER_CLASS
0.0
3.5
GSS-TKEY exchange received a response with answer class: %1.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY پاسخی با
کلاس پاسخ مشخص‌شده دریافت کرده است.
TKEY_EXCHANGE_FAILED_TO_VERIFY
0.0
3.5
GSS-TKEY exchange failed because the response failed to verify.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY با شکست مواجه شده است زیرا اعتبارسنجی
پاسخ ناموفق بود.
TKEY_EXCHANGE_FAIL_EMPTY_IN_TOKEN
0.0
3.5
GSS-TKEY exchange failed because input token is empty.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY با شکست مواجه شده است زیرا توکن ورودی
خالی است.
TKEY_EXCHANGE_FAIL_EMPTY_OUT_TOKEN
0.0
3.5
GSS-TKEY exchange failed because output token is empty.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY با شکست مواجه شده است زیرا توکن خروجی
خالی است.
TKEY_EXCHANGE_FAIL_EMPTY_RESPONSE
0.0
3.5
GSS-TKEY exchange failed because the response is empty.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY با شکست مواجه شده است زیرا پاسخ
خالی است.
TKEY_EXCHANGE_FAIL_IO_ERROR
0.0
3.5
GSS-TKEY exchange failed because of the IO error: %1.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY به دلیل خطای IO با شکست مواجه شده است.
آرگومان، جزئیات خطای IO را مشخص می‌کند.
TKEY_EXCHANGE_FAIL_IO_STOPPED
0.0
3.5
GSS-TKEY exchange failed because the IO service was stopped.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY با شکست مواجه شده است زیرا سرویس
IO متوقف شده بود.
TKEY_EXCHANGE_FAIL_IO_TIMEOUT
0.0
3.5
GSS-TKEY exchange failed because of IO timeout.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY به دلیل اتمام مهلت زمانی (timeout)
در IO با شکست مواجه شده است.
TKEY_EXCHANGE_FAIL_NOT_SIGNED
0.0
3.5
GSS-TKEY exchange failed because the response is not signed.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY با شکست مواجه شده است زیرا پاسخ
امضا نشده است..SS TKEY_EXCHANGE_FAIL_NO_RDATA
0.0
3.5
GSS-TKEY exchange failed because the response contains no rdata.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ حاوی هیچ rdataای نیست.
TKEY_EXCHANGE_FAIL_NO_RESPONSE_ANSWER
0.0
3.5
GSS-TKEY exchange failed because the response contains no answer.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ فاقد answer است.
TKEY_EXCHANGE_FAIL_NULL_RESPONSE
0.0
3.5
GSS-TKEY exchange failed because the response is null.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ null است.
TKEY_EXCHANGE_FAIL_RESPONSE_ERROR
0.0
3.5
GSS-TKEY exchange failed because the response contains an error: %1.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ حاوی یک خطا است. آرگومان، جزئیات خطای پاسخ را مشخص می‌کند.
TKEY_EXCHANGE_FAIL_TKEY_ERROR
0.0
3.5
GSS-TKEY exchange failed because the response contains TKEY error: %1.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ حاوی خطای TKEY است. آرگومان، جزئیات خطای TKEY را مشخص می‌کند.
TKEY_EXCHANGE_FAIL_TO_INIT
0.0
3.5
GSS-TKEY exchange failed to initialize because of the error: %1.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY در مرحلهٔ مقداردهی اولیه شکست خورده است، برای نمونه به این دلیل که principal سرور وجود ندارد. آرگومان، جزئیات خطا را مشخص می‌کند.
TKEY_EXCHANGE_FAIL_WRONG_RESPONSE_ANSWER_COUNT
0.0
3.5
GSS-TKEY exchange failed because the response contains invalid number of RRs: %1.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ حاوی تعداد نامعتبری از RRها است. آرگومان، حاوی تعداد نادرست RRها است.
TKEY_EXCHANGE_FAIL_WRONG_RESPONSE_ANSWER_TYPE
0.0
3.5
GSS-TKEY exchange failed because the response contains wrong answer type: %1.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ حاوی نوع answer نادرستی است. آرگومان، حاوی نوع نادرست answer است.
TKEY_EXCHANGE_FAIL_WRONG_RESPONSE_OPCODE
0.0
3.5
GSS-TKEY exchange failed because the response contains invalid opcode: %1.
168u
168u
این پیام خطا نشان می‌دهد که تبادل GSS-TKEY شکست خورده است زیرا پاسخ حاوی opcode نامعتبری است. آرگومان، حاوی opcode نادرست است.
TKEY_EXCHANGE_NOT_A_RESPONSE
0.0
3.5
GSS-TKEY exchange received a non response type.
168u
168u
در سطح گزارش اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY نوعی غیر از پاسخ (non-response) دریافت کرده است..SS TKEY_EXCHANGE_OUT_TOKEN_NOT_EMPTY
0.0
3.5
GSS-TKEY exchange output token is not empty.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که توکن خروجی تبادل GSS-TKEY خالی نیست.
TKEY_EXCHANGE_RDATA_COUNT
0.0
3.5
GSS-TKEY exchange received a response with rdata count: %1.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY پاسخی با تعداد rdata مشخص‌شده دریافت کرده است.
TKEY_EXCHANGE_RECEIVE_MESSAGE
0.0
3.5
GSS-TKEY exchange receives a message of size: %1.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY پیامی با اندازهٔ مشخص‌شده دریافت می‌کند.
TKEY_EXCHANGE_RESPONSE_TTL
0.0
3.5
GSS-TKEY exchange received a response with TTL of: %1 seconds.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY پاسخی با TTL مشخص‌شده دریافت کرده است.
TKEY_EXCHANGE_SEND_MESSAGE
0.0
3.5
GSS-TKEY exchange sends a message of size: %1.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY پیامی با اندازهٔ مشخص‌شده ارسال می‌کند.
TKEY_EXCHANGE_VALID
0.0
3.5
GSS-TKEY exchange retrieved a TKEY valid for: %1 seconds.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY یک TKEY معتبر برای بازهٔ زمانی مشخص‌شده بر حسب ثانیه را بازیابی کرده است.
TKEY_EXCHANGE_VERIFIED
0.0
3.5
GSS-TKEY exchange verified.
168u
168u
در سطح گزارش اشکال‌زدایی ۴۰ ثبت می‌شود.
این پیام اشکال‌زدایی نشان می‌دهد که تبادل GSS-TKEY تأیید شده است.
TLS
TLS_CONNECTION_HANDSHAKE_FAILED
0.0
3.5
TLS handshake with %1 failed with %2
168u
168u
این پیام اطلاع‌رسانی زمانی صادر می‌شود که دست‌تکانی TLS در سمت سرور با شکست مواجه شود. نشانی کلاینت و پیام خطا نمایش داده می‌شوند.
TLS_CONNECTION_HANDSHAKE_START
0.0
3.5
start TLS handshake with %1 with timeout %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور دست‌تکانی TLS را با نقطهٔ پایانی راه دور آغاز می‌کند. آرگومان اول نشانی نقطهٔ پایانی راه دور را مشخص می‌کند. آرگومان دوم مهلت زمانی درخواست را بر حسب ثانیه مشخص می‌کند.
TLS_REQUEST_RECEIVE_START
0.0
3.5
start receiving request from %1 with timeout %2
168u
168u
در سطح گزارش اشکال‌زدایی ۵۰ ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که سرور دریافت درخواست جدید را بر روی اتصال برقرار شده آغاز می‌کند. آرگومان اول نشانی نقطهٔ پایانی راه دور را مشخص می‌کند. آرگومان دوم مهلت زمانی درخواست را بر حسب ثانیه مشخص می‌کند..SS TLS_SERVER_RESPONSE_SEND
0.0
3.5
sending TLS response to %1
168u
168u
در سطح لاگ اشکال‌زدایی 40 ثبت می‌شود.
این پیام اشکال‌زدایی زمانی صادر می‌شود که کارگزار در حال آغاز ارسال یک پاسخ TLS به یک نقطه پایانی دوردست است. این آرگومان، نشانی نقطه پایانی دوردست را مشخص می‌کند.
USER
USER_CHK_HOOK_LOAD_ERROR
0.0
3.5
DHCP UserCheckHook could not be loaded: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که DHCP UserCheckHook نتواند بارگذاری شود. علت دقیق باید در پیام لاگ توضیح داده شده باشد. انتخاب زیرشبکه کاربر به پردازش پیش‌فرض بازخواهد گشت.
USER_CHK_HOOK_UNLOAD_ERROR
0.0
3.5
DHCP UserCheckHook an error occurred unloading the library: %1
168u
168u
این یک پیام خطا است و هنگامی که خطایی در حین تخلیه کتابخانه UserCheckHook رخ دهد صادر می‌شود. وقوع این خطا بعید است و احتمالاً با بارگذاری بعدی کتابخانه، عملکرد عادی آن از سر گرفته خواهد شد.
USER_CHK_SUBNET4_SELECT_ERROR
0.0
3.5
DHCP UserCheckHook an unexpected error occurred in subnet4_select callout: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هوک subnet4_select در DHCP UserCheckHook با یک خطای غیرمنتظره مواجه شود. این پیام باید حاوی توضیح دقیق‌تری باشد.
USER_CHK_SUBNET4_SELECT_REGISTRY_NULL
0.0
3.5
DHCP UserCheckHook UserRegistry has not been created.
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هوک subnet4_select در DHCP UserCheckHook فراخوانی شده باشد، اما UserRegistry ایجاد نشده باشد. این یک خطای برنامه‌نویسی است و نباید رخ دهد.
USER_CHK_SUBNET6_SELECT_ERROR
0.0
3.5
DHCP UserCheckHook an unexpected error occurred in subnet6_select callout: %1
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هوک subnet6_select در DHCP UserCheckHook با یک خطای غیرمنتظره مواجه شود. این پیام باید حاوی توضیح دقیق‌تری باشد.
USER_CHK_SUBNET6_SELECT_REGISTRY_NULL
0.0
3.5
DHCP UserCheckHook UserRegistry has not been created.
168u
168u
این یک پیام خطا است و زمانی صادر می‌شود که هوک subnet6_select در DHCP UserCheckHook فراخوانی شده باشد، اما UserRegistry ایجاد نشده باشد. این یک خطای برنامه‌نویسی است و نباید رخ دهد.
پیام‌های اشکال‌زدایی Kea بر اساس سطح لاگ
پیام‌های چاپ‌شده در debuglevel 0
0.0
• 2
DCTL_INIT_PROCESS
• 2
DCTL_RUN_PROCESS
• 2
DCTL_SHUTDOWN
• 2
DCTL_SHUTDOWN_SIGNAL_RECVD
• 2
DCTL_STANDALONE
• 2
DHCP4_OPEN_SOCKET
• 2
DHCP4_START_INFO
• 2
DHCP6_OPEN_SOCKET
• 2
DHCP6_START_INFO
• 2
DHCP_DDNS_CLEARED_FOR_SHUTDOWN
• 2
DHCP_DDNS_QUEUE_MGR_STARTED
• 2
DHCP_DDNS_QUEUE_MGR_STOPPING
• 2
DHCP_DDNS_RUN_EXIT
• 2
DHCP_DDNS_SHUTDOWN_COMMAND
• 2
NETCONF_RUN_EXIT
0.0
• 2
COMMAND_DEREGISTERED
• 2
COMMAND_EXTENDED_REGISTERED
• 2
COMMAND_HTTP_LISTENER_COMMAND_REJECTED
• 2
COMMAND_HTTP_LISTENER_STARTED
• 2
COMMAND_HTTP_LISTENER_STOPPED
• 2
COMMAND_HTTP_LISTENER_STOPPING
• 2
COMMAND_REGISTERED
• 2
COMMAND_SOCKET_CONNECTION_CLOSED
• 2
COMMAND_SOCKET_CONNECTION_OPENED
• 2
COMMAND_SOCKET_READ
• 2
COMMAND_SOCKET_WRITE
• 2
DCTL_CONFIG_START
• 2
DHCP4_CONFIG_RECEIVED
• 2
DHCP4_CONFIG_START
• 2
DHCP6_CONFIG_RECEIVED
• 2
DHCP6_CONFIG_START
168u
"پیام‌های چاپ‌شده در debuglevel 15"
0.0
• 2
DHCP4_HOOK_BUFFER_RCVD_DROP
• 2
DHCP4_HOOK_DDNS_UPDATE
• 2
DHCP4_HOOK_DECLINE_SKIP
• 2
DHCP4_HOOK_LEASE4_RELEASE_SKIP
• 2
DHCP4_HOOK_PACKET_SEND_DROP
• 2
DHCP4_HOOK_SUBNET4_SELECT_4O6_PARKING_LOT_FULL
• 2
DHCP4_HOOK_SUBNET4_SELECT_PARKING_LOT_FULL
• 2
DHCP4_HOOK_SUBNET6_SELECT_PARKING_LOT_FULL
• 2
DHCP4_PACKET_DROP_0001
• 2
DHCP4_PACKET_DROP_0002
• 2
DHCP4_PACKET_DROP_0003
• 2
DHCP4_PACKET_DROP_0004
• 2
DHCP4_PACKET_DROP_0005
• 2
DHCP4_PACKET_DROP_0006
• 2
DHCP4_PACKET_DROP_0007
• 2
DHCP4_PACKET_DROP_0008
• 2
DHCP4_PACKET_DROP_0009
• 2
DHCP4_PACKET_DROP_0010
• 2
DHCP4_PACKET_DROP_0011
• 2
DHCP4_PACKET_DROP_0012
• 2
DHCP4_PACKET_DROP_0013
• 2
DHCP4_PACKET_DROP_0014
• 2
DHCP4_PACKET_NAK_0005
• 2
DHCP6_HOOK_BUFFER_RCVD_DROP
• 2
DHCP6_HOOK_DDNS_UPDATE
• 2
DHCP6_HOOK_DECLINE_DROP
• 2
DHCP6_HOOK_LEASES6_COMMITTED_DROP
• 2
DHCP6_HOOK_LEASES6_PARKING_LOT_FULL
• 2
DHCP6_HOOK_PACKET_SEND_DROP
• 2
DHCP6_PACKET_DROP_DHCP_DISABLED
• 2
DHCP6_PACKET_DROP_DROP_CLASS
• 2
DHCP6_PACKET_DROP_DROP_CLASS2
• 2
DHCP6_PACKET_DROP_DROP_CLASS_EARLY
• 2
DHCP6_PACKET_DROP_DUPLICATE
• 2
DHCP6_PACKET_DROP_PARSE_FAIL
• 2
DHCP6_PACKET_DROP_SERVERID_MISMATCH
• 2
DHCP6_PACKET_DROP_UNICAST
• 2
DHCP6_PACKET_REJECT_CLASS
168u
"پیام‌های چاپ‌شده در debuglevel 20"
0.0
• 2
LEASE_CMDS_ADD4
• 2
LEASE_CMDS_ADD6
• 2
LEASE_CMDS_BULK_APPLY6
• 2
LEASE_CMDS_DEL4
• 2
LEASE_CMDS_DEL6
• 2
LEASE_CMDS_UPDATE4
• 2
LEASE_CMDS_UPDATE6
• 2
SFLQ_POOL4_DEL
• 2
SFLQ_POOL4_GET_ALL
• 2
SFLQ_POOL4_GET_BY_RANGE
• 2
SFLQ_POOL4_GET_BY_SUBNET
• 2
SFLQ_POOL4_REBUILD
• 2
SFLQ_POOL6_DEL
• 2
SFLQ_POOL6_GET_ALL
• 2
SFLQ_POOL6_GET_BY_RANGE
• 2
SFLQ_POOL6_GET_BY_SUBNET
• 2
SFLQ_POOL6_REBUILD
0.0
• 2
ALLOC_ENGINE_IGNORING_UNSUITABLE_GLOBAL_ADDRESS
• 2
ALLOC_ENGINE_IGNORING_UNSUITABLE_GLOBAL_ADDRESS6
• 2
ALLOC_ENGINE_LEASE_RECLAIMED
• 2
ALLOC_ENGINE_V4_DISCOVER_HR
• 2
ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE
• 2
ALLOC_ENGINE_V4_LEASES_RECLAMATION_START
• 2
ALLOC_ENGINE_V4_LEASES_RECLAMATION_TIMEOUT
• 2
ALLOC_ENGINE_V4_LEASE_RECLAIM
• 2
ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES
• 2
ALLOC_ENGINE_V4_OFFER_EXISTING_LEASE
• 2
ALLOC_ENGINE_V4_OFFER_NEW_LEASE
• 2
ALLOC_ENGINE_V4_OFFER_REQUESTED_LEASE
• 2
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE
• 2
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE
• 2
ALLOC_ENGINE_V4_REQUEST_ADDRESS_RESERVED
• 2
ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED
• 2
ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE
• 2
ALLOC_ENGINE_V4_REQUEST_INVALID
• 2
ALLOC_ENGINE_V4_REQUEST_IN_USE
• 2
ALLOC_ENGINE_V4_REQUEST_OUT_OF_POOL
• 2
ALLOC_ENGINE_V4_REQUEST_PICK_ADDRESS
• 2
ALLOC_ENGINE_V4_REQUEST_REMOVE_LEASE
• 2
ALLOC_ENGINE_V4_REQUEST_USE_HR
• 2
ALLOC_ENGINE_V6_ALLOC_HR_LEASE_EXISTS
• 2
ALLOC_ENGINE_V6_ALLOC_LEASES_HR
• 2
ALLOC_ENGINE_V6_ALLOC_LEASES_NO_HR
• 2
ALLOC_ENGINE_V6_ALLOC_NO_LEASES_HR
• 2
ALLOC_ENGINE_V6_ALLOC_NO_V6_HR
• 2
ALLOC_ENGINE_V6_ALLOC_UNRESERVED
• 2
ALLOC_ENGINE_V6_CALCULATED_PREFERRED_LIFETIME
• 2
ALLOC_ENGINE_V6_EXPIRED_HINT_RESERVED
• 2
ALLOC_ENGINE_V6_EXTEND_ALLOC_UNRESERVED
• 2
ALLOC_ENGINE_V6_HINT_RESERVED
• 2
ALLOC_ENGINE_V6_LEASES_RECLAMATION_COMPLETE
• 2
ALLOC_ENGINE_V6_LEASES_RECLAMATION_START
• 2
ALLOC_ENGINE_V6_LEASES_RECLAMATION_TIMEOUT
• 2
ALLOC_ENGINE_V6_LEASE_RECLAIM
• 2
ALLOC_ENGINE_V6_NO_MORE_EXPIRED_LEASES
• 2
ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE
• 2
ALLOC_ENGINE_V6_RECLAIMED_LEASES_DELETE_COMPLETE
• 2
ALLOC_ENGINE_V6_RENEW_HR
• 2
ALLOC_ENGINE_V6_RENEW_REMOVE_RESERVED
• 2
ASIODNS_FETCH_STOPPED
• 2
BOOTP_BOOTP_QUERY
• 2
BOOTP_PACKET_OPTIONS_SKIPPED
• 2
BOOTP_PACKET_PACK
• 2
BOOTP_PACKET_UNPACK_FAILED
• 2
BULK_LEASE_QUERY_AT_MAX_CONCURRENT_QUERIES
• 2
BULK_LEASE_QUERY_DEQUEUED
• 2
BULK_LEASE_QUERY_QUERY_RECEIVED
• 2
BULK_LEASE_QUERY_RESPONSE_SENT
• 2
DDNS_TUNING4_CALCULATED_HOSTNAME
• 2
DDNS_TUNING4_SKIPPING_DDNS
• 2
DDNS_TUNING6_CALCULATED_HOSTNAME
• 2
DDNS_TUNING6_SKIPPING_DDNS
• 2
DDNS_TUNING_SUBNET_EXPRESSION_PARSE
• 2
DDNS_TUNING_SUBNET_EXPR_CACHED
• 2
DHCP4_ADDITIONAL_CLASS_NO_TEST
• 2
DHCP4_ADDITIONAL_CLASS_UNDEFINED
• 2
DHCP4_BUFFER_RECEIVED
• 2
DHCP4_CLASSES_ASSIGNED
• 2
DHCP4_CLASSES_ASSIGNED_AFTER_SUBNET_SELECTION
• 2
DHCP4_CLASS_ASSIGNED
• 2
DHCP4_CLASS_UNCONFIGURED
• 2
DHCP4_DHCP4O6_HOOK_SUBNET4_SELECT_DROP
• 2
DHCP4_DHCP4O6_HOOK_SUBNET4_SELECT_SKIP
• 2
DHCP4_DHCP4O6_PACKET_RECEIVED
• 2
DHCP4_DHCP4O6_PACKET_SEND
• 2
DHCP4_FLEX_ID
• 2
DHCP4_HOOK_BUFFER_SEND_SKIP
• 2
DHCP4_HOOK_PACKET_RCVD_SKIP
• 2
DHCP4_HOOK_PACKET_SEND_SKIP
• 2
DHCP4_HOOK_SUBNET4_SELECT_DROP
• 2
DHCP4_HOOK_SUBNET4_SELECT_PARK
• 2
DHCP4_HOOK_SUBNET4_SELECT_SKIP
• 2
DHCP4_LEASE_QUERY_PACKET_UNPACK_FAILED
• 2
DHCP4_LEASE_QUERY_PROCESS_FAILED
• 2
DHCP4_LEASE_QUERY_RECEIVED
• 2
DHCP4_LEASE_QUERY_RESPONSE_SENT
• 2
DHCP4_PACKET_QUEUE_FULL
• 2
DHCP4_RECLAIM_EXPIRED_LEASES_SKIPPED
• 2
DHCP4_SHUTDOWN
• 2
DHCP4_SHUTDOWN_REQUEST
• 2
DHCP6_ADDITIONAL_CLASS_NO_TEST
• 2
DHCP6_ADDITIONAL_CLASS_UNDEFINED
• 2
DHCP6_ADDR6_REGISTER_DISABLED_DROP
• 2
DHCP6_BUFFER_RECEIVED
• 2
DHCP6_CLASSES_ASSIGNED
• 2
DHCP6_CLASSES_ASSIGNED_AFTER_SUBNET_SELECTION
• 2
DHCP6_CLASS_ASSIGNED
• 2
DHCP6_CLASS_UNCONFIGURED
• 2
DHCP6_DHCP4O6_PACKET_RECEIVED
• 2
DHCP6_FLEX_ID
• 2
DHCP6_HOOK_ADDR6_REGISTER_DROP
• 2
DHCP6_HOOK_ADDR6_REGISTER_SKIP
• 2
DHCP6_HOOK_BUFFER_SEND_SKIP
• 2
DHCP6_HOOK_LEASE6_RELEASE_NA_SKIP
• 2
DHCP6_HOOK_LEASE6_RELEASE_PD_SKIP
• 2
DHCP6_HOOK_LEASES6_COMMITTED_PARK.IP • 2
DHCP6_HOOK_PACKET_RCVD_SKIP
• 2
DHCP6_HOOK_PACKET_SEND_SKIP
• 2
DHCP6_HOOK_SUBNET6_SELECT_DROP
• 2
DHCP6_HOOK_SUBNET6_SELECT_PARK
• 2
DHCP6_HOOK_SUBNET6_SELECT_SKIP
• 2
DHCP6_LEASE_QUERY_PACKET_UNPACK_FAILED
• 2
DHCP6_LEASE_QUERY_PREFIX_LENGTH_LIST
• 2
DHCP6_LEASE_QUERY_PROCESS_FAILED
• 2
DHCP6_LEASE_QUERY_RECEIVED
• 2
DHCP6_LEASE_QUERY_REPLY_SENT
• 2
DHCP6_PACKET_PROCESS_FAIL
• 2
DHCP6_PACKET_QUEUE_FULL
• 2
DHCP6_RECLAIM_EXPIRED_LEASES_SKIPPED
• 2
DHCP6_REQUIRED_OPTIONS_CHECK_FAIL
• 2
DHCP6_SHUTDOWN
• 2
DHCP6_SHUTDOWN_REQUEST
• 2
DHCP6_UNKNOWN_MSG_RECEIVED
• 2
DHCPSRV_CFGMGR_ADD_SUBNET4
• 2
DHCPSRV_CFGMGR_ADD_SUBNET6
• 2
DHCPSRV_CFGMGR_ALL_IFACES_ACTIVE
• 2
DHCPSRV_CFGMGR_CFG_DHCP_DDNS
• 2
DHCPSRV_CFGMGR_DEL_SUBNET4
• 2
DHCPSRV_CFGMGR_DEL_SUBNET6
• 2
DHCPSRV_CFGMGR_SUBNET4
• 2
DHCPSRV_CFGMGR_SUBNET4_ADDR
• 2
DHCPSRV_CFGMGR_SUBNET4_IFACE
• 2
DHCPSRV_CFGMGR_SUBNET4_RELAY
• 2
DHCPSRV_CFGMGR_SUBNET6
• 2
DHCPSRV_CFGMGR_SUBNET6_IFACE
• 2
DHCPSRV_CFGMGR_SUBNET6_IFACE_ID
• 2
DHCPSRV_CFGMGR_SUBNET6_RELAY
• 2
DHCPSRV_CFGMGR_UPDATE_SUBNET4
• 2
DHCPSRV_CFGMGR_UPDATE_SUBNET6
• 2
DHCPSRV_CLOSE_DB
• 2
DHCPSRV_FORENSIC_BACKEND_DEREGISTER
• 2
DHCPSRV_FORENSIC_BACKEND_REGISTER
• 2
DHCPSRV_HOOK_LEASE4_RECOVER_SKIP
• 2
DHCPSRV_HOOK_LEASE4_RENEW_SKIP
• 2
DHCPSRV_HOOK_LEASE4_SELECT_SKIP
• 2
DHCPSRV_HOOK_LEASE6_EXTEND_SKIP
• 2
DHCPSRV_HOOK_LEASE6_RECOVER_SKIP
• 2
DHCPSRV_HOOK_LEASE6_SELECT_SKIP
• 2
DHCPSRV_LEASE4_EXTENDED_INFO_UPGRADED
• 2
DHCPSRV_LEASE6_EXTENDED_INFO_UPGRADED
• 2
DHCPSRV_LEASE_MGR_BACKEND_DEREGISTER
• 2
DHCPSRV_LEASE_MGR_BACKEND_REGISTER
• 2
DHCPSRV_MEMFILE_BEGIN_BUILD_EXTENDED_INFO_TABLES6
• 2
DHCPSRV_MEMFILE_BEGIN_EXTRACT_EXTENDED_INFO4
• 2
DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4
• 2
DHCPSRV_MEMFILE_EXTRACT_EXTENDED_INFO4_ERROR
• 2
DHCPSRV_MEMFILE_LFC_UNREGISTER_TIMER_FAILED
• 2
DHCPSRV_SUBNET4O6_SELECT_FAILED
• 2
DHCPSRV_SUBNET4_SELECT_BY_ADDRESS_NO_MATCH
• 2
DHCPSRV_SUBNET4_SELECT_BY_INTERFACE_NO_MATCH
• 2
DHCPSRV_SUBNET4_SELECT_BY_RELAY_ADDRESS_NO_MATCH
• 2
DHCPSRV_SUBNET4_SELECT_NO_RAI_OPTIONS
• 2
DHCPSRV_SUBNET4_SELECT_NO_RELAY_ADDRESS
• 2
DHCPSRV_SUBNET4_SELECT_NO_USABLE_ADDRESS
• 2
DHCPSRV_SUBNET6_SELECT_BY_ADDRESS_NO_MATCH
• 2
DHCPSRV_SUBNET6_SELECT_BY_INTERFACE_ID_NO_MATCH
• 2
DHCPSRV_SUBNET6_SELECT_BY_INTERFACE_NO_MATCH
• 2
DHCPSRV_TIMERMGR_REGISTER_TIMER
• 2
DHCPSRV_TIMERMGR_START_TIMER
• 2
DHCPSRV_TIMERMGR_STOP_TIMER
• 2
DHCPSRV_TIMERMGR_UNREGISTER_ALL_TIMERS
• 2
DHCPSRV_TIMERMGR_UNREGISTER_TIMER
• 2
DHCP_DDNS_CONFIGURE
• 2
DHCP_DDNS_NCR_UDP_RECV_CANCELED
• 2
DHCP_DDNS_QUEUE_MGR_RECONFIGURING
• 2
DHCP_DDNS_QUEUE_MGR_STOPPED
• 2
DHCP_IFACE_OPEN_SOCKET
• 2
FLEX_ID_EXPRESSION_EVALUATED
• 2
FLEX_ID_EXPRESSION_HEX
• 2
FLEX_ID_IGNORE_IAID_APPLIED_ON_NA
• 2
FLEX_ID_IGNORE_IAID_APPLIED_ON_PD
• 2
FLEX_ID_IGNORE_IAID_NOT_APPLIED_ON_NA
• 2
FLEX_ID_IGNORE_IAID_NOT_APPLIED_ON_PD
• 2
FLEX_ID_NO_IDENTIFIER_EXPRESSION
• 2
FLEX_ID_RESTORE_CLIENT_ID
• 2
FLEX_ID_RESTORE_DUID
• 2
FLEX_ID_USED_AS_CLIENT_ID
• 2
FLEX_ID_USED_AS_DUID
• 2
FLEX_OPTION_PROCESS_ADD
• 2
FLEX_OPTION_PROCESS_CLIENT_CLASS
• 2
FLEX_OPTION_PROCESS_REMOVE
• 2
FLEX_OPTION_PROCESS_SUB_ADD
• 2
FLEX_OPTION_PROCESS_SUB_CLIENT_CLASS
• 2
FLEX_OPTION_PROCESS_SUB_REMOVE
• 2
FLEX_OPTION_PROCESS_SUB_SUPERSEDE
• 2
FLEX_OPTION_PROCESS_SUPERSEDE
• 2
FLEX_OPTION_PROCESS_VENDOR_ID_MISMATCH
• 2
GSS_TSIG_MANAGER_STARTED
• 2
GSS_TSIG_MANAGER_STOPPED
• 2
GSS_TSIG_NEW_KEY
• 2
GSS_TSIG_NEW_KEY_SETUP_SUCCEED
• 2
GSS_TSIG_OLD_KEY_REMOVED
• 2
GSS_TSIG_VERIFIED
• 2
HA_BUFFER4_RECEIVE_NOT_FOR_US
• 2
HA_BUFFER4_RECEIVE_PACKET_OPTIONS_SKIPPED
• 2
HA_BUFFER4_RECEIVE_UNPACK_FAILED.IP • 2
HA_BUFFER6_RECEIVE_NOT_FOR_US
• 2
HA_BUFFER6_RECEIVE_PACKET_OPTIONS_SKIPPED
• 2
HA_BUFFER6_RECEIVE_UNPACK_FAILED
• 2
HA_LEASE4_EXPIRE_RECLAMATION_SKIP
• 2
HA_LEASE6_EXPIRE_RECLAMATION_SKIP
• 2
HA_LEASES4_COMMITTED_NOTHING_TO_UPDATE
• 2
HA_LEASES6_COMMITTED_NOTHING_TO_UPDATE
• 2
HA_LEASE_SYNC_STALE_LEASE4_SKIP
• 2
HA_LEASE_SYNC_STALE_LEASE6_SKIP
• 2
HA_LOAD_BALANCING_DUID_MISSING
• 2
HA_LOAD_BALANCING_IDENTIFIER_MISSING
• 2
HA_LOAD_BALANCING_LEASE_DUID_MISSING
• 2
HA_LOAD_BALANCING_LEASE_IDENTIFIER_MISSING
• 2
HA_SUBNET4_SELECT_NOT_FOR_US
• 2
HA_SUBNET4_SELECT_NO_SUBNET_SELECTED
• 2
HA_SUBNET6_SELECT_NOT_FOR_US
• 2
HA_SUBNET6_SELECT_NO_SUBNET_SELECTED
• 2
HOOKS_LIBRARY_LOADING
• 2
HOOKS_LIBRARY_UNLOADING
• 2
HOOKS_LOAD_SUCCESS
• 2
HOOKS_NO_LOAD
• 2
HOOKS_NO_UNLOAD
• 2
HOOKS_UNLOAD_SUCCESS
• 2
HOSTS_BACKEND_DEREGISTER
• 2
HOSTS_BACKEND_REGISTER
• 2
HOSTS_CFG_ADD_HOST
• 2
HOSTS_CFG_CLOSE_HOST_DATA_SOURCE
• 2
HOSTS_CFG_DEL
• 2
HOSTS_CFG_DEL4
• 2
HOSTS_CFG_DEL6
• 2
HOSTS_CFG_DEL_ALL_SUBNET4
• 2
HOSTS_CFG_DEL_ALL_SUBNET6
• 2
HOSTS_CFG_GET_ALL
• 2
HOSTS_CFG_GET_ALL_ADDRESS4
• 2
HOSTS_CFG_GET_ALL_ADDRESS6
• 2
HOSTS_CFG_GET_ALL_HOSTNAME
• 2
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID4
• 2
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID6
• 2
HOSTS_CFG_GET_ALL_IDENTIFIER
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID4
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID6
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS4
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6
• 2
HOSTS_CFG_GET_ONE_PREFIX
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER
• 2
HOSTS_CFG_UPDATE_ADD
• 2
HOSTS_CFG_UPDATE_DEL4
• 2
HOSTS_CFG_UPDATE_DEL6
• 2
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4
• 2
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_IDENTIFIER
• 2
HOSTS_MGR_ALTERNATE_GET6_PREFIX
• 2
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_ADDRESS6
• 2
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_IDENTIFIER
• 2
HOSTS_MGR_ALTERNATE_GET_ALL_SUBNET_ID_ADDRESS4
• 2
HOSTS_MGR_ALTERNATE_GET_ALL_SUBNET_ID_ADDRESS6
• 2
HOST_CACHE_GET_ONE_PREFIX
• 2
HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS4
• 2
HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS6
• 2
HOST_CACHE_GET_ONE_SUBNET_ID_IDENTIFIER
• 2
HTTP_BAD_CLIENT_REQUEST_RECEIVED
• 2
HTTP_BAD_SERVER_RESPONSE_RECEIVED
• 2
HTTP_CLIENT_MT_STARTED
• 2
HTTP_CLIENT_REQUEST_RECEIVED
• 2
HTTP_CONNECTION_SHUTDOWN
• 2
HTTP_CONNECTION_STOP
• 2
HTTP_SERVER_RESPONSE_RECEIVED
• 2
HTTP_SERVER_RESPONSE_SEND
• 2
KEY_LOOKUP_DISABLED
• 2
KEY_LOOKUP_FOUND
• 2
KEY_LOOKUP_NONE
• 2
LIMITS_CONFIGURED_ADDRESS_LIMIT_BY_CLIENT_CLASS
• 2
LIMITS_CONFIGURED_ADDRESS_LIMIT_BY_SUBNET
• 2
LIMITS_CONFIGURED_PREFIX_LIMIT_BY_CLIENT_CLASS
• 2
LIMITS_CONFIGURED_PREFIX_LIMIT_BY_SUBNET
• 2
LIMITS_CONFIGURED_RATE_LIMIT_BY_CLIENT_CLASS
• 2
LIMITS_CONFIGURED_RATE_LIMIT_BY_SUBNET
• 2
LIMITS_LEASE_LIMIT_EXCEEDED
• 2
LIMITS_LEASE_WITHIN_LIMITS
• 2
LIMITS_PACKET_WITH_CLIENT_CLASSES_RATE_LIMIT_DROPPED
• 2
LIMITS_PACKET_WITH_SUBNET_ID_RATE_LIMIT_DROPPED
• 2
MT_TCP_LISTENER_MGR_STARTED
• 2
MT_TCP_LISTENER_MGR_STOPPED
• 2
MT_TCP_LISTENER_MGR_STOPPING
• 2
MYSQL_CB_CREATE_UPDATE_BY_POOL_OPTION4
• 2
MYSQL_CB_CREATE_UPDATE_BY_POOL_OPTION6
• 2
MYSQL_CB_CREATE_UPDATE_BY_PREFIX_OPTION6
• 2
MYSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION4
• 2
MYSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION6
• 2
MYSQL_CB_CREATE_UPDATE_CLIENT_CLASS4
• 2
MYSQL_CB_CREATE_UPDATE_CLIENT_CLASS6
• 2
MYSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER4
• 2
MYSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER6
• 2
MYSQL_CB_CREATE_UPDATE_OPTION4
• 2
MYSQL_CB_CREATE_UPDATE_OPTION6
• 2
MYSQL_CB_CREATE_UPDATE_OPTION_DEF4
• 2
MYSQL_CB_CREATE_UPDATE_OPTION_DEF6
• 2
MYSQL_CB_CREATE_UPDATE_SERVER4
• 2
MYSQL_CB_CREATE_UPDATE_SERVER6.IP • 2
MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK4
• 2
MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK6
• 2
MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION4
• 2
MYSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION6
• 2
MYSQL_CB_CREATE_UPDATE_SUBNET4
• 2
MYSQL_CB_CREATE_UPDATE_SUBNET6
• 2
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES4
• 2
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES4_RESULT
• 2
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES6
• 2
MYSQL_CB_DELETE_ALL_CLIENT_CLASSES6_RESULT
• 2
MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4
• 2
MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4_RESULT
• 2
MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6
• 2
MYSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6_RESULT
• 2
MYSQL_CB_DELETE_ALL_OPTION_DEFS4
• 2
MYSQL_CB_DELETE_ALL_OPTION_DEFS4_RESULT
• 2
MYSQL_CB_DELETE_ALL_OPTION_DEFS6
• 2
MYSQL_CB_DELETE_ALL_OPTION_DEFS6_RESULT
• 2
MYSQL_CB_DELETE_ALL_SERVERS4
• 2
MYSQL_CB_DELETE_ALL_SERVERS4_RESULT
• 2
MYSQL_CB_DELETE_ALL_SERVERS6
• 2
MYSQL_CB_DELETE_ALL_SERVERS6_RESULT
• 2
MYSQL_CB_DELETE_ALL_SHARED_NETWORKS4
• 2
MYSQL_CB_DELETE_ALL_SHARED_NETWORKS4_RESULT
• 2
MYSQL_CB_DELETE_ALL_SHARED_NETWORKS6
• 2
MYSQL_CB_DELETE_ALL_SHARED_NETWORKS6_RESULT
• 2
MYSQL_CB_DELETE_ALL_SUBNETS4
• 2
MYSQL_CB_DELETE_ALL_SUBNETS4_RESULT
• 2
MYSQL_CB_DELETE_ALL_SUBNETS6
• 2
MYSQL_CB_DELETE_ALL_SUBNETS6_RESULT
• 2
MYSQL_CB_DELETE_BY_POOL_OPTION4
• 2
MYSQL_CB_DELETE_BY_POOL_OPTION4_RESULT
• 2
MYSQL_CB_DELETE_BY_POOL_OPTION6
• 2
MYSQL_CB_DELETE_BY_POOL_OPTION6_RESULT
• 2
MYSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6
• 2
MYSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6_RESULT
• 2
MYSQL_CB_DELETE_BY_PREFIX_SUBNET4
• 2
MYSQL_CB_DELETE_BY_PREFIX_SUBNET4_RESULT
• 2
MYSQL_CB_DELETE_BY_PREFIX_SUBNET6
• 2
MYSQL_CB_DELETE_BY_PREFIX_SUBNET6_RESULT
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION4
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION4_RESULT
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION6
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_OPTION6_RESULT
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4_RESULT
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6
• 2
MYSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6_RESULT
• 2
MYSQL_CB_DELETE_CLIENT_CLASS4
• 2
MYSQL_CB_DELETE_CLIENT_CLASS4_RESULT
• 2
MYSQL_CB_DELETE_CLIENT_CLASS6
• 2
MYSQL_CB_DELETE_CLIENT_CLASS6_RESULT
• 2
MYSQL_CB_DELETE_GLOBAL_PARAMETER4
• 2
MYSQL_CB_DELETE_GLOBAL_PARAMETER4_RESULT
• 2
MYSQL_CB_DELETE_GLOBAL_PARAMETER6
• 2
MYSQL_CB_DELETE_GLOBAL_PARAMETER6_RESULT
• 2
MYSQL_CB_DELETE_OPTION4
• 2
MYSQL_CB_DELETE_OPTION4_RESULT
• 2
MYSQL_CB_DELETE_OPTION6
• 2
MYSQL_CB_DELETE_OPTION6_RESULT
• 2
MYSQL_CB_DELETE_OPTION_DEF4
• 2
MYSQL_CB_DELETE_OPTION_DEF4_RESULT
• 2
MYSQL_CB_DELETE_OPTION_DEF6
• 2
MYSQL_CB_DELETE_OPTION_DEF6_RESULT
• 2
MYSQL_CB_DELETE_SERVER4
• 2
MYSQL_CB_DELETE_SERVER4_RESULT
• 2
MYSQL_CB_DELETE_SERVER6
• 2
MYSQL_CB_DELETE_SERVER6_RESULT
• 2
MYSQL_CB_DELETE_SHARED_NETWORK4
• 2
MYSQL_CB_DELETE_SHARED_NETWORK4_RESULT
• 2
MYSQL_CB_DELETE_SHARED_NETWORK6
• 2
MYSQL_CB_DELETE_SHARED_NETWORK6_RESULT
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_OPTION4
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_OPTION4_RESULT
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_OPTION6
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_OPTION6_RESULT
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4_RESULT
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6
• 2
MYSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6_RESULT
• 2
MYSQL_CB_GET_ALL_CLIENT_CLASSES4
• 2
MYSQL_CB_GET_ALL_CLIENT_CLASSES4_RESULT
• 2
MYSQL_CB_GET_ALL_CLIENT_CLASSES6
• 2
MYSQL_CB_GET_ALL_CLIENT_CLASSES6_RESULT
• 2
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS4
• 2
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS4_RESULT
• 2
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS6
• 2
MYSQL_CB_GET_ALL_GLOBAL_PARAMETERS6_RESULT
• 2
MYSQL_CB_GET_ALL_OPTIONS4
• 2
MYSQL_CB_GET_ALL_OPTIONS4_RESULT
• 2
MYSQL_CB_GET_ALL_OPTIONS6
• 2
MYSQL_CB_GET_ALL_OPTIONS6_RESULT
• 2
MYSQL_CB_GET_ALL_OPTION_DEFS4
• 2
MYSQL_CB_GET_ALL_OPTION_DEFS4_RESULT
• 2
MYSQL_CB_GET_ALL_OPTION_DEFS6
• 2
MYSQL_CB_GET_ALL_OPTION_DEFS6_RESULT
• 2
MYSQL_CB_GET_ALL_SERVERS4
• 2
MYSQL_CB_GET_ALL_SERVERS4_RESULT
• 2
MYSQL_CB_GET_ALL_SERVERS6
• 2
MYSQL_CB_GET_ALL_SERVERS6_RESULT.IP • 2
MYSQL_CB_GET_ALL_SHARED_NETWORKS4
• 2
MYSQL_CB_GET_ALL_SHARED_NETWORKS4_RESULT
• 2
MYSQL_CB_GET_ALL_SHARED_NETWORKS6
• 2
MYSQL_CB_GET_ALL_SHARED_NETWORKS6_RESULT
• 2
MYSQL_CB_GET_ALL_SUBNETS4
• 2
MYSQL_CB_GET_ALL_SUBNETS4_RESULT
• 2
MYSQL_CB_GET_ALL_SUBNETS6
• 2
MYSQL_CB_GET_ALL_SUBNETS6_RESULT
• 2
MYSQL_CB_GET_CLIENT_CLASS4
• 2
MYSQL_CB_GET_CLIENT_CLASS6
• 2
MYSQL_CB_GET_GLOBAL_PARAMETER4
• 2
MYSQL_CB_GET_GLOBAL_PARAMETER6
• 2
MYSQL_CB_GET_HOST4
• 2
MYSQL_CB_GET_HOST6
• 2
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES4
• 2
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES4_RESULT
• 2
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES6
• 2
MYSQL_CB_GET_MODIFIED_CLIENT_CLASSES6_RESULT
• 2
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4
• 2
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4_RESULT
• 2
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6
• 2
MYSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6_RESULT
• 2
MYSQL_CB_GET_MODIFIED_OPTIONS4
• 2
MYSQL_CB_GET_MODIFIED_OPTIONS4_RESULT
• 2
MYSQL_CB_GET_MODIFIED_OPTIONS6
• 2
MYSQL_CB_GET_MODIFIED_OPTIONS6_RESULT
• 2
MYSQL_CB_GET_MODIFIED_OPTION_DEFS4
• 2
MYSQL_CB_GET_MODIFIED_OPTION_DEFS4_RESULT
• 2
MYSQL_CB_GET_MODIFIED_OPTION_DEFS6
• 2
MYSQL_CB_GET_MODIFIED_OPTION_DEFS6_RESULT
• 2
MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS4
• 2
MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS4_RESULT
• 2
MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS6
• 2
MYSQL_CB_GET_MODIFIED_SHARED_NETWORKS6_RESULT
• 2
MYSQL_CB_GET_MODIFIED_SUBNETS4
• 2
MYSQL_CB_GET_MODIFIED_SUBNETS4_RESULT
• 2
MYSQL_CB_GET_MODIFIED_SUBNETS6
• 2
MYSQL_CB_GET_MODIFIED_SUBNETS6_RESULT
• 2
MYSQL_CB_GET_OPTION4
• 2
MYSQL_CB_GET_OPTION6
• 2
MYSQL_CB_GET_OPTION_DEF4
• 2
MYSQL_CB_GET_OPTION_DEF6
• 2
MYSQL_CB_GET_PORT4
• 2
MYSQL_CB_GET_PORT6
• 2
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES4
• 2
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES4_RESULT
• 2
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES6
• 2
MYSQL_CB_GET_RECENT_AUDIT_ENTRIES6_RESULT
• 2
MYSQL_CB_GET_SERVER4
• 2
MYSQL_CB_GET_SERVER6
• 2
MYSQL_CB_GET_SHARED_NETWORK4
• 2
MYSQL_CB_GET_SHARED_NETWORK6
• 2
MYSQL_CB_GET_SHARED_NETWORK_SUBNETS4
• 2
MYSQL_CB_GET_SHARED_NETWORK_SUBNETS4_RESULT
• 2
MYSQL_CB_GET_SHARED_NETWORK_SUBNETS6
• 2
MYSQL_CB_GET_SHARED_NETWORK_SUBNETS6_RESULT
• 2
MYSQL_CB_GET_SUBNET4_BY_PREFIX
• 2
MYSQL_CB_GET_SUBNET4_BY_SUBNET_ID
• 2
MYSQL_CB_GET_SUBNET6_BY_PREFIX
• 2
MYSQL_CB_GET_SUBNET6_BY_SUBNET_ID
• 2
MYSQL_CB_GET_TYPE4
• 2
MYSQL_CB_GET_TYPE6
• 2
MYSQL_CB_REGISTER_BACKEND_TYPE4
• 2
MYSQL_CB_REGISTER_BACKEND_TYPE6
• 2
MYSQL_CB_TLS_CIPHER
• 2
MYSQL_CB_UNREGISTER_BACKEND_TYPE4
• 2
MYSQL_CB_UNREGISTER_BACKEND_TYPE6
• 2
MYSQL_HB_TLS_CIPHER
• 2
MYSQL_LB_TLS_CIPHER
• 2
MYSQL_LB_UPGRADE_EXTENDED_INFO4
• 2
MYSQL_LB_UPGRADE_EXTENDED_INFO4_ERROR
• 2
MYSQL_LB_UPGRADE_EXTENDED_INFO6
• 2
MYSQL_LB_UPGRADE_EXTENDED_INFO6_ERROR
• 2
PERFMON_DHCP4_SOCKET_RECEIVED_TIME_SUPPORT
• 2
PERFMON_DHCP6_SOCKET_RECEIVED_TIME_SUPPORT
• 2
PGSQL_CB_CREATE_UPDATE_BY_POOL_OPTION4
• 2
PGSQL_CB_CREATE_UPDATE_BY_POOL_OPTION6
• 2
PGSQL_CB_CREATE_UPDATE_BY_PREFIX_OPTION6
• 2
PGSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION4
• 2
PGSQL_CB_CREATE_UPDATE_BY_SUBNET_ID_OPTION6
• 2
PGSQL_CB_CREATE_UPDATE_CLIENT_CLASS4
• 2
PGSQL_CB_CREATE_UPDATE_CLIENT_CLASS6
• 2
PGSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER4
• 2
PGSQL_CB_CREATE_UPDATE_GLOBAL_PARAMETER6
• 2
PGSQL_CB_CREATE_UPDATE_OPTION4
• 2
PGSQL_CB_CREATE_UPDATE_OPTION6
• 2
PGSQL_CB_CREATE_UPDATE_OPTION_DEF4
• 2
PGSQL_CB_CREATE_UPDATE_OPTION_DEF6
• 2
PGSQL_CB_CREATE_UPDATE_SERVER4
• 2
PGSQL_CB_CREATE_UPDATE_SERVER6
• 2
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK4
• 2
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK6
• 2
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION4
• 2
PGSQL_CB_CREATE_UPDATE_SHARED_NETWORK_OPTION6
• 2
PGSQL_CB_CREATE_UPDATE_SUBNET4
• 2
PGSQL_CB_CREATE_UPDATE_SUBNET6
• 2
PGSQL_CB_DELETE_ALL_CLIENT_CLASSES4
• 2
PGSQL_CB_DELETE_ALL_CLIENT_CLASSES4_RESULT
• 2
PGSQL_CB_DELETE_ALL_CLIENT_CLASSES6
• 2
PGSQL_CB_DELETE_ALL_CLIENT_CLASSES6_RESULT.IP • 2
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4
• 2
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS4_RESULT
• 2
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6
• 2
PGSQL_CB_DELETE_ALL_GLOBAL_PARAMETERS6_RESULT
• 2
PGSQL_CB_DELETE_ALL_OPTION_DEFS4
• 2
PGSQL_CB_DELETE_ALL_OPTION_DEFS4_RESULT
• 2
PGSQL_CB_DELETE_ALL_OPTION_DEFS6
• 2
PGSQL_CB_DELETE_ALL_OPTION_DEFS6_RESULT
• 2
PGSQL_CB_DELETE_ALL_SERVERS4
• 2
PGSQL_CB_DELETE_ALL_SERVERS4_RESULT
• 2
PGSQL_CB_DELETE_ALL_SERVERS6
• 2
PGSQL_CB_DELETE_ALL_SERVERS6_RESULT
• 2
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS4
• 2
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS4_RESULT
• 2
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS6
• 2
PGSQL_CB_DELETE_ALL_SHARED_NETWORKS6_RESULT
• 2
PGSQL_CB_DELETE_ALL_SUBNETS4
• 2
PGSQL_CB_DELETE_ALL_SUBNETS4_RESULT
• 2
PGSQL_CB_DELETE_ALL_SUBNETS6
• 2
PGSQL_CB_DELETE_ALL_SUBNETS6_RESULT
• 2
PGSQL_CB_DELETE_BY_POOL_OPTION4
• 2
PGSQL_CB_DELETE_BY_POOL_OPTION4_RESULT
• 2
PGSQL_CB_DELETE_BY_POOL_OPTION6
• 2
PGSQL_CB_DELETE_BY_POOL_OPTION6_RESULT
• 2
PGSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6
• 2
PGSQL_CB_DELETE_BY_POOL_PREFIX_OPTION6_RESULT
• 2
PGSQL_CB_DELETE_BY_PREFIX_SUBNET4
• 2
PGSQL_CB_DELETE_BY_PREFIX_SUBNET4_RESULT
• 2
PGSQL_CB_DELETE_BY_PREFIX_SUBNET6
• 2
PGSQL_CB_DELETE_BY_PREFIX_SUBNET6_RESULT
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION4
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION4_RESULT
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION6
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_OPTION6_RESULT
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET4_RESULT
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6
• 2
PGSQL_CB_DELETE_BY_SUBNET_ID_SUBNET6_RESULT
• 2
PGSQL_CB_DELETE_CLIENT_CLASS4
• 2
PGSQL_CB_DELETE_CLIENT_CLASS4_RESULT
• 2
PGSQL_CB_DELETE_CLIENT_CLASS6
• 2
PGSQL_CB_DELETE_CLIENT_CLASS6_RESULT
• 2
PGSQL_CB_DELETE_GLOBAL_PARAMETER4
• 2
PGSQL_CB_DELETE_GLOBAL_PARAMETER4_RESULT
• 2
PGSQL_CB_DELETE_GLOBAL_PARAMETER6
• 2
PGSQL_CB_DELETE_GLOBAL_PARAMETER6_RESULT
• 2
PGSQL_CB_DELETE_OPTION4
• 2
PGSQL_CB_DELETE_OPTION4_RESULT
• 2
PGSQL_CB_DELETE_OPTION6
• 2
PGSQL_CB_DELETE_OPTION6_RESULT
• 2
PGSQL_CB_DELETE_OPTION_DEF4
• 2
PGSQL_CB_DELETE_OPTION_DEF4_RESULT
• 2
PGSQL_CB_DELETE_OPTION_DEF6
• 2
PGSQL_CB_DELETE_OPTION_DEF6_RESULT
• 2
PGSQL_CB_DELETE_SERVER4
• 2
PGSQL_CB_DELETE_SERVER4_RESULT
• 2
PGSQL_CB_DELETE_SERVER6
• 2
PGSQL_CB_DELETE_SERVER6_RESULT
• 2
PGSQL_CB_DELETE_SHARED_NETWORK4
• 2
PGSQL_CB_DELETE_SHARED_NETWORK4_RESULT
• 2
PGSQL_CB_DELETE_SHARED_NETWORK6
• 2
PGSQL_CB_DELETE_SHARED_NETWORK6_RESULT
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION4
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION4_RESULT
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION6
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_OPTION6_RESULT
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS4_RESULT
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6
• 2
PGSQL_CB_DELETE_SHARED_NETWORK_SUBNETS6_RESULT
• 2
PGSQL_CB_GET_ALL_CLIENT_CLASSES4
• 2
PGSQL_CB_GET_ALL_CLIENT_CLASSES4_RESULT
• 2
PGSQL_CB_GET_ALL_CLIENT_CLASSES6
• 2
PGSQL_CB_GET_ALL_CLIENT_CLASSES6_RESULT
• 2
PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS4
• 2
PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS4_RESULT
• 2
PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS6
• 2
PGSQL_CB_GET_ALL_GLOBAL_PARAMETERS6_RESULT
• 2
PGSQL_CB_GET_ALL_OPTIONS4
• 2
PGSQL_CB_GET_ALL_OPTIONS4_RESULT
• 2
PGSQL_CB_GET_ALL_OPTIONS6
• 2
PGSQL_CB_GET_ALL_OPTIONS6_RESULT
• 2
PGSQL_CB_GET_ALL_OPTION_DEFS4
• 2
PGSQL_CB_GET_ALL_OPTION_DEFS4_RESULT
• 2
PGSQL_CB_GET_ALL_OPTION_DEFS6
• 2
PGSQL_CB_GET_ALL_OPTION_DEFS6_RESULT
• 2
PGSQL_CB_GET_ALL_SERVERS4
• 2
PGSQL_CB_GET_ALL_SERVERS4_RESULT
• 2
PGSQL_CB_GET_ALL_SERVERS6
• 2
PGSQL_CB_GET_ALL_SERVERS6_RESULT
• 2
PGSQL_CB_GET_ALL_SHARED_NETWORKS4
• 2
PGSQL_CB_GET_ALL_SHARED_NETWORKS4_RESULT
• 2
PGSQL_CB_GET_ALL_SHARED_NETWORKS6
• 2
PGSQL_CB_GET_ALL_SHARED_NETWORKS6_RESULT
• 2
PGSQL_CB_GET_ALL_SUBNETS4
• 2
PGSQL_CB_GET_ALL_SUBNETS4_RESULT
• 2
PGSQL_CB_GET_ALL_SUBNETS6
• 2
PGSQL_CB_GET_ALL_SUBNETS6_RESULT
• 2
PGSQL_CB_GET_CLIENT_CLASS4
• 2
PGSQL_CB_GET_CLIENT_CLASS6.IP • 2
PGSQL_CB_GET_GLOBAL_PARAMETER4
• 2
PGSQL_CB_GET_GLOBAL_PARAMETER6
• 2
PGSQL_CB_GET_HOST4
• 2
PGSQL_CB_GET_HOST6
• 2
PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES4
• 2
PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES4_RESULT
• 2
PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES6
• 2
PGSQL_CB_GET_MODIFIED_CLIENT_CLASSES6_RESULT
• 2
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4
• 2
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS4_RESULT
• 2
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6
• 2
PGSQL_CB_GET_MODIFIED_GLOBAL_PARAMETERS6_RESULT
• 2
PGSQL_CB_GET_MODIFIED_OPTIONS4
• 2
PGSQL_CB_GET_MODIFIED_OPTIONS4_RESULT
• 2
PGSQL_CB_GET_MODIFIED_OPTIONS6
• 2
PGSQL_CB_GET_MODIFIED_OPTIONS6_RESULT
• 2
PGSQL_CB_GET_MODIFIED_OPTION_DEFS4
• 2
PGSQL_CB_GET_MODIFIED_OPTION_DEFS4_RESULT
• 2
PGSQL_CB_GET_MODIFIED_OPTION_DEFS6
• 2
PGSQL_CB_GET_MODIFIED_OPTION_DEFS6_RESULT
• 2
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS4
• 2
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS4_RESULT
• 2
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS6
• 2
PGSQL_CB_GET_MODIFIED_SHARED_NETWORKS6_RESULT
• 2
PGSQL_CB_GET_MODIFIED_SUBNETS4
• 2
PGSQL_CB_GET_MODIFIED_SUBNETS4_RESULT
• 2
PGSQL_CB_GET_MODIFIED_SUBNETS6
• 2
PGSQL_CB_GET_MODIFIED_SUBNETS6_RESULT
• 2
PGSQL_CB_GET_OPTION4
• 2
PGSQL_CB_GET_OPTION6
• 2
PGSQL_CB_GET_OPTION_DEF4
• 2
PGSQL_CB_GET_OPTION_DEF6
• 2
PGSQL_CB_GET_PORT4
• 2
PGSQL_CB_GET_PORT6
• 2
PGSQL_CB_GET_RECENT_AUDIT_ENTRIES4
• 2
PGSQL_CB_GET_RECENT_AUDIT_ENTRIES4_RESULT
• 2
PGSQL_CB_GET_RECENT_AUDIT_ENTRIES6
• 2
PGSQL_CB_GET_RECENT_AUDIT_ENTRIES6_RESULT
• 2
PGSQL_CB_GET_SERVER4
• 2
PGSQL_CB_GET_SERVER6
• 2
PGSQL_CB_GET_SHARED_NETWORK4
• 2
PGSQL_CB_GET_SHARED_NETWORK6
• 2
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS4
• 2
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS4_RESULT
• 2
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS6
• 2
PGSQL_CB_GET_SHARED_NETWORK_SUBNETS6_RESULT
• 2
PGSQL_CB_GET_SUBNET4_BY_PREFIX
• 2
PGSQL_CB_GET_SUBNET4_BY_SUBNET_ID
• 2
PGSQL_CB_GET_SUBNET6_BY_PREFIX
• 2
PGSQL_CB_GET_SUBNET6_BY_SUBNET_ID
• 2
PGSQL_CB_GET_TYPE4
• 2
PGSQL_CB_GET_TYPE6
• 2
PGSQL_CB_REGISTER_BACKEND_TYPE4
• 2
PGSQL_CB_REGISTER_BACKEND_TYPE6
• 2
PGSQL_CB_UNREGISTER_BACKEND_TYPE4
• 2
PGSQL_CB_UNREGISTER_BACKEND_TYPE6
• 2
PGSQL_LB_UPGRADE_EXTENDED_INFO4
• 2
PGSQL_LB_UPGRADE_EXTENDED_INFO4_ERROR
• 2
PGSQL_LB_UPGRADE_EXTENDED_INFO6
• 2
PGSQL_LB_UPGRADE_EXTENDED_INFO6_ERROR
• 2
PING_CHECK_CHANNEL_MALFORMED_PACKET_RECEIVED
• 2
PING_CHECK_CHANNEL_SOCKET_CLOSED
• 2
PING_CHECK_CHANNEL_SOCKET_OPENED
• 2
PING_CHECK_CHANNEL_STOP
• 2
PING_CHECK_DUPLICATE_CHECK
• 2
PING_CHECK_MGR_LEASE_FREE_TO_USE
• 2
PING_CHECK_MGR_RECEIVED_ECHO_REPLY
• 2
PING_CHECK_MGR_START_PING_CHECK
• 2
PING_CHECK_MGR_STOPPING
• 2
RADIUS_ACCESS_CACHE_GET
• 2
RADIUS_ACCESS_CACHE_INSERT
• 2
RADIUS_ACCESS_CONFLICT
• 2
RADIUS_ACCESS_DROP_PARKED_QUERY
• 2
RADIUS_ACCESS_GET_IDENTIFIER
• 2
RADIUS_ACCESS_MAX_PENDING_REQUESTS
• 2
RADIUS_ACCESS_RESUME_PARKED_QUERY
• 2
RADIUS_ACCESS_SUBNET_RESELECT
• 2
RADIUS_ACCOUNTING_ASYNC
• 2
RADIUS_ACCOUNTING_ASYNC_FAILED
• 2
RADIUS_ACCOUNTING_ASYNC_SUCCEED
• 2
RADIUS_ACCOUNTING_NO_HISTORY
• 2
RADIUS_ACCOUNTING_STATUS
• 2
RADIUS_ACCOUNTING_STATUS_FAILED
• 2
RADIUS_ACCOUNTING_STATUS_SUCCEED
• 2
RADIUS_ACCOUNTING_SYNC
• 2
RADIUS_ACCOUNTING_SYNC_FAILED
• 2
RADIUS_ACCOUNTING_SYNC_SUCCEED
• 2
RADIUS_AUTHENTICATION_ASYNC
• 2
RADIUS_AUTHENTICATION_ASYNC_ACCEPTED
• 2
RADIUS_AUTHENTICATION_ASYNC_FAILED
• 2
RADIUS_AUTHENTICATION_ASYNC_REJECTED
• 2
RADIUS_AUTHENTICATION_STATUS
• 2
RADIUS_AUTHENTICATION_STATUS_FAILED
• 2
RADIUS_AUTHENTICATION_STATUS_SUCCEED
• 2
RADIUS_AUTHENTICATION_SYNC
• 2
RADIUS_AUTHENTICATION_SYNC_ACCEPTED
• 2
RADIUS_AUTHENTICATION_SYNC_FAILED
• 2
RADIUS_AUTHENTICATION_SYNC_REJECTED
• 2
RADIUS_BACKEND_GET4
• 2
RADIUS_BACKEND_GET6.IP • 2
RADIUS_DECODE_MESSAGE
• 2
RADIUS_ENCODE_MESSAGE
• 2
RADIUS_EXCHANGE_RECEIVED_ACCESS_ACCEPT
• 2
RADIUS_EXCHANGE_RECEIVED_ACCESS_REJECT
• 2
RADIUS_EXCHANGE_RECEIVED_ACCOUNTING_RESPONSE
• 2
RADIUS_EXCHANGE_RECEIVED_RESPONSE
• 2
RADIUS_TCP_EXCHANGE_RECEIVED
• 2
RADIUS_TCP_EXCHANGE_SEND
• 2
RADIUS_TCP_EXCHANGE_START
• 2
RADIUS_TCP_EXCHANGE_SUCCESS
• 2
RADIUS_TLS_STATUS
• 2
RADIUS_TLS_STATUS_FAILED
• 2
RADIUS_TLS_STATUS_SUCCEED
• 2
RADIUS_UDP_EXCHANGE_RECEIVED
• 2
RADIUS_UDP_EXCHANGE_SEND_NEW
• 2
RADIUS_UDP_EXCHANGE_SEND_RETRY
• 2
RADIUS_UDP_EXCHANGE_SENT
• 2
RADIUS_UDP_EXCHANGE_START
• 2
RADIUS_UDP_EXCHANGE_SYNC_RETURN
• 2
RADIUS_UDP_EXCHANGE_TERMINATE
• 2
RBAC_CONFIGURED_ACLS
• 2
RBAC_CONFIGURED_COMMANDS
• 2
RBAC_CONFIGURED_ROLES
• 2
RBAC_TRACE_HTTP_AUTH_ACCEPT
• 2
RBAC_TRACE_HTTP_AUTH_BAD_BODY_TYPE
• 2
RBAC_TRACE_HTTP_AUTH_BAD_COMMAND_TYPE
• 2
RBAC_TRACE_HTTP_AUTH_COMMAND
• 2
RBAC_TRACE_HTTP_AUTH_DISABLED
• 2
RBAC_TRACE_HTTP_AUTH_EMPTY_BODY
• 2
RBAC_TRACE_HTTP_AUTH_NO_COMMAND
• 2
RBAC_TRACE_HTTP_AUTH_NO_JSON
• 2
RBAC_TRACE_HTTP_AUTH_NO_REQUEST
• 2
RBAC_TRACE_HTTP_AUTH_NO_TLS_REJECT
• 2
RBAC_TRACE_HTTP_AUTH_RESPONSE
• 2
RBAC_TRACE_HTTP_AUTH_ROLE
• 2
RBAC_TRACE_HTTP_RESPONSE_BAD_BODY_TYPE
• 2
RBAC_TRACE_HTTP_RESPONSE_CONTEXT
• 2
RBAC_TRACE_HTTP_RESPONSE_DISABLED
• 2
RBAC_TRACE_HTTP_RESPONSE_EMPTY_BODY
• 2
RBAC_TRACE_HTTP_RESPONSE_EMPTY_BODY_LIST
• 2
RBAC_TRACE_HTTP_RESPONSE_MODIFIED
• 2
RBAC_TRACE_HTTP_RESPONSE_NO_ARGUMENTS
• 2
START_REKEY_TIMER
• 2
START_RETRY_TIMER
• 2
STAT_CMDS_LEASE4_ORPHANED_STATS
• 2
STAT_CMDS_LEASE6_ORPHANED_STATS
• 2
TCP_CLIENT_BAD_SERVER_RESPONSE_RECEIVED
• 2
TCP_CLIENT_MT_STARTED
• 2
TCP_CLIENT_SERVER_RESPONSE_RECEIVED
• 2
TCP_CONNECTION_SHUTDOWN
• 2
TCP_CONNECTION_STOP
• 2
TCP_SERVER_CLIENT_REQUEST_RECEIVED
• 2
TCP_SERVER_RESPONSE_SEND
• 2
TKEY_EXCHANGE_ANSWER_CLASS
• 2
TKEY_EXCHANGE_NOT_A_RESPONSE
• 2
TKEY_EXCHANGE_OUT_TOKEN_NOT_EMPTY
• 2
TKEY_EXCHANGE_RDATA_COUNT
• 2
TKEY_EXCHANGE_RECEIVE_MESSAGE
• 2
TKEY_EXCHANGE_RESPONSE_TTL
• 2
TKEY_EXCHANGE_SEND_MESSAGE
• 2
TKEY_EXCHANGE_VALID
• 2
TKEY_EXCHANGE_VERIFIED
• 2
TLS_SERVER_RESPONSE_SEND
0.0
• 2
DHCP4_DHCP4O6_SUBNET_SELECTED
• 2
DHCP4_SUBNET_DYNAMICALLY_CHANGED
• 2
DHCP4_SUBNET_SELECTED
• 2
DHCP6_SUBNET_DYNAMICALLY_CHANGED
• 2
DHCP6_SUBNET_SELECTED
• 2
HOOKS_CALLOUTS_BEGIN
• 2
HOOKS_CALLOUTS_COMPLETE
• 2
HOOKS_CALLOUTS_REMOVED
• 2
HOOKS_CALLOUT_REGISTRATION
• 2
HOOKS_LIBRARY_MULTI_THREADING_COMPATIBLE
• 2
HOOKS_LIBRARY_VERSION
• 2
HOOKS_STD_CALLOUT_REGISTERED
• 2
HOSTS_CFG_GET_ALL_ADDRESS4_COUNT
• 2
HOSTS_CFG_GET_ALL_ADDRESS6_COUNT
• 2
HOSTS_CFG_GET_ALL_COUNT
• 2
HOSTS_CFG_GET_ALL_HOSTNAME_COUNT
• 2
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID4_COUNT
• 2
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID6_COUNT
• 2
HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID4_COUNT
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID6_COUNT
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS4_COUNT
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_COUNT
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_HOST
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_HOST
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS6_NULL
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST
• 2
HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL
• 2
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_IDENTIFIER_HOST
• 2
HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_IDENTIFIER_NULL
• 2
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_IDENTIFIER_HOST
• 2
HOSTS_MGR_ALTERNATE_GET6_SUBNET_ID_IDENTIFIER_NULL
• 2
HOST_CACHE_ADD
• 2
HOST_CACHE_ADD_DUPLICATE
• 2
HOST_CACHE_DEL_SUBNET_ID_ADDRESS4
• 2
HOST_CACHE_DEL_SUBNET_ID_ADDRESS6
• 2
HOST_CACHE_DEL_SUBNET_ID_IDENTIFIER4
• 2
HOST_CACHE_DEL_SUBNET_ID_IDENTIFIER6
• 2
HOST_CACHE_GET_ONE_PREFIX_HOST
• 2
HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS4_HOST
• 2
HOST_CACHE_GET_ONE_SUBNET_ID_ADDRESS6_HOST
• 2
HOST_CACHE_GET_ONE_SUBNET_ID_IDENTIFIER_HOST
• 2
HTTP_BAD_CLIENT_REQUEST_RECEIVED_DETAILS
• 2
HTTP_BAD_SERVER_RESPONSE_RECEIVED_DETAILS
• 2
HTTP_CLIENT_REQUEST_RECEIVED_DETAILS
• 2
HTTP_SERVER_RESPONSE_RECEIVED_DETAILS
• 2
HTTP_SERVER_RESPONSE_SEND_DETAILS
• 2
TCP_CLIENT_BAD_SERVER_RESPONSE_RECEIVED_DETAILS
168u
"پیام‌های چاپ‌شده در debuglevel 50"
0.0
• 2
ALLOC_ENGINE_V6_EXTEND_LEASE
• 2
ASIODNS_READ_TIMEOUT
• 2
DHCP4_ADDITIONAL_CLASS_EVAL_RESULT
• 2
DHCP4_BUFFER_UNPACK
• 2
DHCP4_BUFFER_WAIT_SIGNAL
• 2
DHCP4_CLIENTID_IGNORED_FOR_LEASES
• 2
DHCP4_CLIENT_FQDN_PROCESS
• 2
DHCP4_CLIENT_FQDN_SCRUBBED_EMPTY
• 2
DHCP4_CLIENT_HOSTNAME_MALFORMED
• 2
DHCP4_CLIENT_HOSTNAME_PROCESS
• 2
DHCP4_CLIENT_HOSTNAME_SCRUBBED_EMPTY
• 2
DHCP4_DEFERRED_OPTION_MISSING
• 2
DHCP4_DEFERRED_OPTION_UNPACK_FAIL
• 2
DHCP4_DHCP4O6_BAD_PACKET
• 2
DHCP4_DHCP4O6_RECEIVE_FAIL
• 2
DHCP4_DHCP4O6_RECEIVING
• 2
DHCP4_DHCP4O6_SUBNET_SELECTION_FAILED
• 2
DHCP4_DISCOVER
• 2
DHCP4_EMPTY_HOSTNAME
• 2
DHCP4_HOOK_BUFFER_RCVD_SKIP
• 2
DHCP4_INFORM_DIRECT_REPLY
• 2
DHCP4_NO_LEASE_INIT_REBOOT
• 2
DHCP4_PACKET_NAK_0002
• 2
DHCP4_PACKET_NAK_0003
• 2
DHCP4_PACKET_NAK_0004
• 2
DHCP4_PACKET_OPTIONS_SKIPPED
• 2
DHCP4_PACKET_PACK
• 2
DHCP4_RELEASE
• 2
DHCP4_RELEASE_FAIL
• 2
DHCP4_RELEASE_FAIL_NO_LEASE
• 2
DHCP4_RELEASE_FAIL_WRONG_CLIENT
• 2
DHCP4_REQUEST
• 2
DHCP4_RESPONSE_HOSTNAME_GENERATE
• 2
DHCP4_SUBNET_SELECTION_FAILED
• 2
DHCP4_UNKNOWN_ADDRESS_REQUESTED
• 2
DHCP6_ADDITIONAL_CLASS_EVAL_RESULT
• 2
DHCP6_ADD_GLOBAL_STATUS_CODE
• 2
DHCP6_ADD_STATUS_CODE_FOR_IA
• 2
DHCP6_BUFFER_UNPACK
• 2
DHCP6_BUFFER_WAIT_SIGNAL
• 2
DHCP6_CLIENT_FQDN_SCRUBBED_EMPTY
• 2
DHCP6_DDNS_CREATE_ADD_NAME_CHANGE_REQUEST
• 2
DHCP6_DDNS_GENERATE_FQDN
• 2
DHCP6_DDNS_RECEIVE_FQDN
• 2
DHCP6_DDNS_REMOVE_OLD_LEASE_FQDN
• 2
DHCP6_DDNS_RESPONSE_FQDN_DATA
• 2
DHCP6_DECLINE_PROCESS_IA
• 2
DHCP6_DHCP4O6_RECEIVE_FAIL
• 2
DHCP6_DHCP4O6_RECEIVING
• 2
DHCP6_HOOK_BUFFER_RCVD_SKIP
• 2
DHCP6_HOOK_DECLINE_SKIP
• 2
DHCP6_LEASE_ADVERT
• 2
DHCP6_LEASE_ADVERT_FAIL
• 2
DHCP6_LEASE_ALLOC
• 2
DHCP6_LEASE_ALLOC_FAIL
• 2
DHCP6_PACKET_OPTIONS_SKIPPED
• 2
DHCP6_PD_LEASE_ADVERT
• 2
DHCP6_PD_LEASE_ADVERT_FAIL
• 2
DHCP6_PD_LEASE_ALLOC
• 2
DHCP6_PD_LEASE_ALLOC_FAIL
• 2
DHCP6_PROCESS_IA_NA_EXTEND
• 2
DHCP6_PROCESS_IA_NA_RELEASE
• 2
DHCP6_PROCESS_IA_NA_REQUEST
• 2
DHCP6_PROCESS_IA_NA_SOLICIT
• 2
DHCP6_PROCESS_IA_PD_EXTEND
• 2
DHCP6_PROCESS_IA_PD_REQUEST
• 2
DHCP6_PROCESS_IA_PD_SOLICIT
• 2
DHCP6_RAPID_COMMIT
• 2
DHCP6_SUBNET_SELECTION_FAILED
• 2
DHCPSRV_DHCP_DDNS_NCR_SENT
• 2
DHCPSRV_EVAL_RESULT
• 2
DHCPSRV_MEMFILE_ADD_ADDR4
• 2
DHCPSRV_MEMFILE_ADD_ADDR6
• 2
DHCPSRV_MEMFILE_COMMIT
• 2
DHCPSRV_MEMFILE_DELETE_ADDR4
• 2
DHCPSRV_MEMFILE_DELETE_ADDR6
• 2
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4
• 2
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED6
• 2
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED_START
• 2
DHCPSRV_MEMFILE_GET4
• 2
DHCPSRV_MEMFILE_GET6
• 2
DHCPSRV_MEMFILE_GET6_DUID
• 2
DHCPSRV_MEMFILE_GET_ADDR4
• 2
DHCPSRV_MEMFILE_GET_ADDR6
• 2
DHCPSRV_MEMFILE_GET_CLIENTID
• 2
DHCPSRV_MEMFILE_GET_EXPIRED4
• 2
DHCPSRV_MEMFILE_GET_EXPIRED6
• 2
DHCPSRV_MEMFILE_GET_HOSTNAME4
• 2
DHCPSRV_MEMFILE_GET_HOSTNAME6
• 2
DHCPSRV_MEMFILE_GET_HWADDR4
• 2
DHCPSRV_MEMFILE_GET_HWADDR6
• 2
DHCPSRV_MEMFILE_GET_IAID_DUID
• 2
DHCPSRV_MEMFILE_GET_IAID_SUBID_DUID
• 2
DHCPSRV_MEMFILE_GET_PAGE4
• 2
DHCPSRV_MEMFILE_GET_PAGE6
• 2
DHCPSRV_MEMFILE_GET_RELAYID4
• 2
DHCPSRV_MEMFILE_GET_RELAYID6
• 2
DHCPSRV_MEMFILE_GET_REMOTEID4
• 2
DHCPSRV_MEMFILE_GET_REMOTEID6
• 2
DHCPSRV_MEMFILE_GET_SUBID4
• 2
DHCPSRV_MEMFILE_GET_SUBID6
• 2
DHCPSRV_MEMFILE_GET_SUBID_CLIENTID
• 2
DHCPSRV_MEMFILE_GET_SUBID_HWADDR
• 2
DHCPSRV_MEMFILE_GET_SUBID_PAGE6
• 2
DHCPSRV_MEMFILE_ROLLBACK
• 2
DHCPSRV_MEMFILE_UPDATE_ADDR4
• 2
DHCPSRV_MEMFILE_UPDATE_ADDR6
• 2
DHCPSRV_QUEUE_NCR_SKIP
• 2
DHCPSRV_TEMPLATE_EVAL_RESULT
• 2
DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION
• 2
DHCP_DDNS_INVALID_RESPONSE
• 2
DHCP_DDNS_STARTING_TRANSACTION
• 2
DHCP_DDNS_UPDATE_REQUEST_SENT
• 2
DHCP_DDNS_UPDATE_RESPONSE_RECEIVED
• 2
FUZZ_DATA_READ
• 2
FUZZ_SEND
• 2
HTTPS_REQUEST_RECEIVE_START
• 2
HTTP_CLIENT_REQUEST_SEND
• 2
HTTP_CLIENT_REQUEST_TIMEOUT_OCCURRED
• 2
HTTP_CONNECTION_HANDSHAKE_START
• 2
HTTP_IDLE_CONNECTION_TIMEOUT_OCCURRED
• 2
HTTP_REQUEST_RECEIVE_START
• 2
LEGAL_LOG_MYSQL_GET_VERSION
• 2
LEGAL_LOG_MYSQL_INSERT_LOG
• 2
LEGAL_LOG_MYSQL_TLS_CIPHER
• 2
LEGAL_LOG_PGSQL_GET_VERSION
• 2
LEGAL_LOG_PGSQL_INSERT_LOG
• 2
MYSQL_HB_DB_GET_VERSION
• 2
MYSQL_LB_ADD_ADDR4
• 2
MYSQL_LB_ADD_ADDR6
• 2
MYSQL_LB_COMMIT
• 2
MYSQL_LB_DELETED_EXPIRED_RECLAIMED
• 2
MYSQL_LB_DELETED_SUBNET4_ID
• 2
MYSQL_LB_DELETED_SUBNET6_ID
• 2
MYSQL_LB_DELETE_ADDR4
• 2
MYSQL_LB_DELETE_ADDR6
• 2
MYSQL_LB_DELETE_EXPIRED_RECLAIMED4
• 2
MYSQL_LB_DELETE_EXPIRED_RECLAIMED6
• 2
MYSQL_LB_GET4
• 2
MYSQL_LB_GET6
• 2
MYSQL_LB_GET_ADDR4
• 2
MYSQL_LB_GET_ADDR6
• 2
MYSQL_LB_GET_CLIENTID
• 2
MYSQL_LB_GET_DUID
• 2
MYSQL_LB_GET_EXPIRED4
• 2
MYSQL_LB_GET_EXPIRED6
• 2
MYSQL_LB_GET_HOSTNAME4
• 2
MYSQL_LB_GET_HOSTNAME6
• 2
MYSQL_LB_GET_HWADDR4.IP • 2
MYSQL_LB_GET_HWADDR6
• 2
MYSQL_LB_GET_IAID_DUID
• 2
MYSQL_LB_GET_IAID_SUBID_DUID
• 2
MYSQL_LB_GET_PAGE4
• 2
MYSQL_LB_GET_PAGE6
• 2
MYSQL_LB_GET_RELAYID4
• 2
MYSQL_LB_GET_RELAYID6
• 2
MYSQL_LB_GET_REMOTEID4
• 2
MYSQL_LB_GET_REMOTEID6
• 2
MYSQL_LB_GET_STATE4
• 2
MYSQL_LB_GET_STATE6
• 2
MYSQL_LB_GET_STATE_SUBID4
• 2
MYSQL_LB_GET_STATE_SUBID6
• 2
MYSQL_LB_GET_SUBID4
• 2
MYSQL_LB_GET_SUBID6
• 2
MYSQL_LB_GET_SUBID_CLIENTID
• 2
MYSQL_LB_GET_SUBID_HWADDR
• 2
MYSQL_LB_GET_SUBID_PAGE6
• 2
MYSQL_LB_GET_VERSION
• 2
MYSQL_LB_ROLLBACK
• 2
MYSQL_LB_SFLQ_CREATE_POOL4
• 2
MYSQL_LB_SFLQ_CREATE_POOL6
• 2
MYSQL_LB_SFLQ_PICK_LEASE4
• 2
MYSQL_LB_SFLQ_PICK_LEASE6
• 2
MYSQL_LB_SFLQ_POOL4_DELETE
• 2
MYSQL_LB_SFLQ_POOL4_GET_ALL
• 2
MYSQL_LB_SFLQ_POOL4_GET_BY_RANGE
• 2
MYSQL_LB_SFLQ_POOL4_GET_BY_SUBNET
• 2
MYSQL_LB_SFLQ_POOL6_DELETE
• 2
MYSQL_LB_SFLQ_POOL6_GET_ALL
• 2
MYSQL_LB_SFLQ_POOL6_GET_BY_RANGE
• 2
MYSQL_LB_SFLQ_POOL6_GET_BY_SUBNET
• 2
MYSQL_LB_UPDATE_ADDR4
• 2
MYSQL_LB_UPDATE_ADDR6
• 2
MYSQL_LB_UPGRADE_EXTENDED_INFO4_PAGE
• 2
MYSQL_LB_UPGRADE_EXTENDED_INFO6_PAGE
• 2
PERFMON_DHCP4_PKT_EVENTS
• 2
PERFMON_DHCP4_PKT_PROCESS_ERROR
• 2
PERFMON_DHCP6_PKT_EVENTS
• 2
PERFMON_DHCP6_PKT_PROCESS_ERROR
• 2
PGSQL_HB_DB_GET_VERSION
• 2
PGSQL_LB_ADD_ADDR4
• 2
PGSQL_LB_ADD_ADDR6
• 2
PGSQL_LB_COMMIT
• 2
PGSQL_LB_DELETED_SUBNET4_ID
• 2
PGSQL_LB_DELETED_SUBNET6_ID
• 2
PGSQL_LB_DELETE_ADDR4
• 2
PGSQL_LB_DELETE_ADDR6
• 2
PGSQL_LB_DELETE_EXPIRED_RECLAIMED4
• 2
PGSQL_LB_DELETE_EXPIRED_RECLAIMED6
• 2
PGSQL_LB_GET4
• 2
PGSQL_LB_GET6
• 2
PGSQL_LB_GET_ADDR4
• 2
PGSQL_LB_GET_ADDR6
• 2
PGSQL_LB_GET_CLIENTID
• 2
PGSQL_LB_GET_DUID
• 2
PGSQL_LB_GET_EXPIRED4
• 2
PGSQL_LB_GET_EXPIRED6
• 2
PGSQL_LB_GET_HOSTNAME4
• 2
PGSQL_LB_GET_HOSTNAME6
• 2
PGSQL_LB_GET_HWADDR4
• 2
PGSQL_LB_GET_HWADDR6
• 2
PGSQL_LB_GET_IAID_DUID
• 2
PGSQL_LB_GET_IAID_SUBID_DUID
• 2
PGSQL_LB_GET_PAGE4
• 2
PGSQL_LB_GET_PAGE6
• 2
PGSQL_LB_GET_RELAYID4
• 2
PGSQL_LB_GET_RELAYID6
• 2
PGSQL_LB_GET_REMOTEID4
• 2
PGSQL_LB_GET_REMOTEID6
• 2
PGSQL_LB_GET_STATE4
• 2
PGSQL_LB_GET_STATE6
• 2
PGSQL_LB_GET_STATE_SUBID4
• 2
PGSQL_LB_GET_STATE_SUBID6
• 2
PGSQL_LB_GET_SUBID4
• 2
PGSQL_LB_GET_SUBID6
• 2
PGSQL_LB_GET_SUBID_CLIENTID
• 2
PGSQL_LB_GET_SUBID_HWADDR
• 2
PGSQL_LB_GET_SUBID_PAGE6
• 2
PGSQL_LB_GET_VERSION
• 2
PGSQL_LB_ROLLBACK
• 2
PGSQL_LB_SFLQ_CREATE_POOL4
• 2
PGSQL_LB_SFLQ_CREATE_POOL6
• 2
PGSQL_LB_SFLQ_PICK_LEASE4
• 2
PGSQL_LB_SFLQ_PICK_LEASE6
• 2
PGSQL_LB_SFLQ_POOL4_DELETE
• 2
PGSQL_LB_SFLQ_POOL4_GET_ALL
• 2
PGSQL_LB_SFLQ_POOL4_GET_BY_RANGE
• 2
PGSQL_LB_SFLQ_POOL4_GET_BY_SUBNET
• 2
PGSQL_LB_SFLQ_POOL6_DELETE
• 2
PGSQL_LB_SFLQ_POOL6_GET_ALL
• 2
PGSQL_LB_SFLQ_POOL6_GET_BY_RANGE
• 2
PGSQL_LB_SFLQ_POOL6_GET_BY_SUBNET
• 2
PGSQL_LB_UPDATE_ADDR4
• 2
PGSQL_LB_UPDATE_ADDR6
• 2
PGSQL_LB_UPGRADE_EXTENDED_INFO4_PAGE
• 2
PGSQL_LB_UPGRADE_EXTENDED_INFO6_PAGE
• 2
PING_CHECK_CHANNEL_ECHO_REPLY_RECEIVED
• 2
PING_CHECK_CHANNEL_ECHO_REQUEST_SENT
• 2
PING_CHECK_MGR_NEXT_ECHO_SCHEDULED.IP • 2
PING_CHECK_MGR_RECEIVED_UNEXPECTED_ECHO_REPLY
• 2
PING_CHECK_MGR_RECEIVED_UNEXPECTED_UNREACHABLE_MSG
• 2
PING_CHECK_MGR_RECEIVED_UNREACHABLE_MSG
• 2
PING_CHECK_MGR_REPLY_TIMEOUT_EXPIRED
• 2
PING_CHECK_NO_LEASE_OR_LEASE_REUSED
• 2
TCP_CLIENT_REQUEST_SEND
• 2
TCP_CONNECTION_REJECTED_BY_FILTER
• 2
TCP_IDLE_CONNECTION_TIMEOUT_OCCURRED
• 2
TCP_REQUEST_RECEIVE_START
• 2
TLS_CONNECTION_HANDSHAKE_START
• 2
TLS_REQUEST_RECEIVE_START
168u
پیام‌های چاپ‌شده در debuglevel 55
0.0
• 2
ALLOC_ENGINE_V4_REUSE_EXPIRED_LEASE_DATA
• 2
ALLOC_ENGINE_V6_EXTEND_LEASE_DATA
• 2
ALLOC_ENGINE_V6_EXTEND_NEW_LEASE_DATA
• 2
ALLOC_ENGINE_V6_REUSE_EXPIRED_LEASE_DATA
• 2
DHCP4_CLIENT_FQDN_DATA
• 2
DHCP4_CLIENT_HOSTNAME_DATA
• 2
DHCP4_CLIENT_NAME_PROC_FAIL
• 2
DHCP4_DHCP4O6_RESPONSE_DATA
• 2
DHCP4_DHCP4O6_SUBNET_DATA
• 2
DHCP4_GENERATE_FQDN
• 2
DHCP4_QUERY_DATA
• 2
DHCP4_RECOVERED_STASHED_RELAY_AGENT_INFO
• 2
DHCP4_RESERVED_HOSTNAME_ASSIGNED
• 2
DHCP4_RESPONSE_DATA
• 2
DHCP4_RESPONSE_FQDN_DATA
• 2
DHCP4_RESPONSE_HOSTNAME_DATA
• 2
DHCP4_SUBNET_DATA
• 2
DHCP6_DDNS_FQDN_GENERATED
• 2
DHCP6_DHCP4O6_RESPONSE_DATA
• 2
DHCP6_LEASE_DATA
• 2
DHCP6_QUERY_DATA
• 2
DHCP6_RESPONSE_DATA
• 2
DHCP6_SUBNET_DATA
• 2
DHCPSRV_DDNS_TTL_TOO_LARGE
• 2
DHCPSRV_DDNS_TTL_TOO_SMALL
• 2
DHCPSRV_MEMFILE_LEASE_LOAD
• 2
DHCPSRV_QUEUE_NCR
• 2
DHCP_DDNS_AT_MAX_TRANSACTIONS
• 2
DHCP_DDNS_FWD_REQUEST_IGNORED
• 2
DHCP_DDNS_NO_ELIGIBLE_JOBS
• 2
DHCP_DDNS_QUEUE_MGR_QUEUE_RECEIVE
• 2
DHCP_DDNS_REQUEST_DROPPED
• 2
DHCP_DDNS_REV_REQUEST_IGNORED
• 2
EVAL_DEBUG_AND
• 2
EVAL_DEBUG_BRANCH
• 2
EVAL_DEBUG_CONCAT
• 2
EVAL_DEBUG_EQUAL
• 2
EVAL_DEBUG_HEXSTRING
• 2
EVAL_DEBUG_IFELSE_FALSE
• 2
EVAL_DEBUG_IFELSE_TRUE
• 2
EVAL_DEBUG_INT16TOTEXT
• 2
EVAL_DEBUG_INT32TOTEXT
• 2
EVAL_DEBUG_INT8TOTEXT
• 2
EVAL_DEBUG_IPADDRESS
• 2
EVAL_DEBUG_IPADDRESSTOTEXT
• 2
EVAL_DEBUG_LCASE
• 2
EVAL_DEBUG_MATCH
• 2
EVAL_DEBUG_MEMBER
• 2
EVAL_DEBUG_NOT
• 2
EVAL_DEBUG_OPTION
• 2
EVAL_DEBUG_OR
• 2
EVAL_DEBUG_PKT
• 2
EVAL_DEBUG_PKT4
• 2
EVAL_DEBUG_PKT6
• 2
EVAL_DEBUG_POP_AND_BRANCH_FALSE
• 2
EVAL_DEBUG_POP_OR_BRANCH_FALSE
• 2
EVAL_DEBUG_POP_OR_BRANCH_TRUE
• 2
EVAL_DEBUG_RELAY6
• 2
EVAL_DEBUG_RELAY6_RANGE
• 2
EVAL_DEBUG_SPLIT
• 2
EVAL_DEBUG_SPLIT_DELIM_EMPTY
• 2
EVAL_DEBUG_SPLIT_EMPTY
• 2
EVAL_DEBUG_SPLIT_FIELD_OUT_OF_RANGE
• 2
EVAL_DEBUG_STRING
• 2
EVAL_DEBUG_SUBSTRING
• 2
EVAL_DEBUG_SUBSTRING_EMPTY
• 2
EVAL_DEBUG_SUBSTRING_RANGE
• 2
EVAL_DEBUG_TOHEXSTRING
• 2
EVAL_DEBUG_UCASE
• 2
EVAL_DEBUG_UINT16TOTEXT
• 2
EVAL_DEBUG_UINT32TOTEXT
• 2
EVAL_DEBUG_UINT8TOTEXT
• 2
EVAL_DEBUG_VENDOR_CLASS_DATA
• 2
EVAL_DEBUG_VENDOR_CLASS_DATA_NOT_FOUND
• 2
EVAL_DEBUG_VENDOR_CLASS_ENTERPRISE_ID
• 2
EVAL_DEBUG_VENDOR_CLASS_ENTERPRISE_ID_MISMATCH
• 2
EVAL_DEBUG_VENDOR_CLASS_EXISTS
• 2
EVAL_DEBUG_VENDOR_CLASS_NO_OPTION
• 2
EVAL_DEBUG_VENDOR_ENTERPRISE_ID
• 2
EVAL_DEBUG_VENDOR_ENTERPRISE_ID_MISMATCH
• 2
EVAL_DEBUG_VENDOR_EXISTS
• 2
EVAL_DEBUG_VENDOR_NO_OPTION
• 2
HOOKS_ALL_CALLOUTS_DEREGISTERED
• 2
HOOKS_CALLOUT_CALLED
• 2
HOOKS_CALLOUT_DEREGISTERED
• 2
HOSTS_CFG_GET_ALL_ADDRESS4_HOST
• 2
HOSTS_CFG_GET_ALL_ADDRESS6_HOST
• 2
HOSTS_CFG_GET_ALL_HOST.IP • 2
HOSTS_CFG_GET_ALL_HOSTNAME_HOST
• 2
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID4_HOST
• 2
HOSTS_CFG_GET_ALL_HOSTNAME_SUBNET_ID6_HOST
• 2
HOSTS_CFG_GET_ALL_IDENTIFIER_HOST
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID4_HOST
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID6_HOST
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS4_HOST
• 2
HOSTS_CFG_GET_ALL_SUBNET_ID_ADDRESS6_HOST
• 2
HOSTS_CFG_GET_ONE_PREFIX_HOST
• 2
HOSTS_CFG_GET_ONE_PREFIX_NULL
• 2
HTTP_CLIENT_REQUEST_SEND_DETAILS
• 2
HTTP_DATA_RECEIVED
• 2
LIMITS_PACKET_WIIH_SUBNET_ID_RATE_NO_SUBNET
• 2
LIMITS_PACKET_WITH_CLIENT_CLASSES_RATE_LIMIT_HONORED
• 2
LIMITS_PACKET_WITH_SUBNET_ID_RATE_LIMIT_HONORED
• 2
NETCONF_CONFIG_CHANGED_DETAIL
• 2
NETCONF_GET_CONFIG
• 2
NETCONF_SET_CONFIG
• 2
NETCONF_UPDATE_CONFIG
• 2
NETCONF_VALIDATE_CONFIG
• 2
TCP_DATA_RECEIVED
• 2
TCP_DATA_SENT
168u
پیام‌های چاپ‌شده در debuglevel 70
0.0
• 2
ASIODNS_FETCH_COMPLETED
168u
"مثال‌های پیکربندی (CONFIGURATION EXAMPLES)"
این مجموعه‌ای از مثال‌های پیکربندی موجود در doc/examples در کدهای منبع Kea نسخهٔ 3.2.0 است.
ddns
ddns/all-keys-netconf.json
0.0
3.5
// هشدار: این پیکربندی نمونه برای استفاده در محیط عملیاتی در نظر گرفته نشده است.
// کارساز DHCP-DDNS در Kea ممکن است این پیکربندی را رد کند زیرا ممکن است
// شامل پارامترهای پیکربندی ناسازگار با یکدیگر (mutually exclusive) باشد.
//
// هدف اصلی این فایل نمونه ارائهٔ فهرستی جامع از پارامترهای پشتیبانی‌شده
// توسط کارساز Kea DHCP-DDNS به همراه شرح مختصری از هر پارامتر است.
//
// این نسخهٔ پایدار برای YANG استفاده می‌شود زیرا نمی‌خواهیم هر بار که کلیدواژه‌ای
// به نحو (syntax) افزوده می‌شود، کد و مدل‌ها را به‌روزرسانی کنیم.
{
// پیکربندی کارساز Kea DHCP-DDNS از اینجا آغاز می‌شود.
"DhcpDdns": {
// پارامترهای عمومی
// آدرس IP که D2 در آن به درخواست‌های به‌روزرسانی گوش می‌دهد.
// پیش‌فرض 127.0.0.1 است.
"ip-address": "127.0.0.1",
// درگاهی که D2 روی آن به درخواست‌های به‌روزرسانی گوش می‌دهد.
// پیش‌فرض 53001 است.
"port": 53001,
// حداکثر زمانی که منتظر پاسخ یک کارساز DNS خواهیم ماند.
// واحد بر حسب میلی‌ثانیه، پیش‌فرض 100ms است.
"dns-server-timeout" : 100,
// پروتکل مورداستفاده برای Name Change Requests از یک کارساز Kea DHCP.
// در حال حاضر فقط 'UDP' پشتیبانی می‌شود.
"ncr-protocol": "UDP",
// قالب مورداستفاده برای Name Change Requests از یک کارساز Kea DHCP.
// در حال حاضر فقط 'JSON' پشتیبانی می‌شود.
"ncr-format": "JSON",
// پارامترهای پیکربندی سوکت کنترل فرمان برای کارساز Kea DHCP-DDNS.
"control-socket": {
// مکان فایل سوکت دامنهٔ یونیکس (UNIX domain socket) که کارساز DHCP-DDNS
// برای دریافت فرمان‌های کنترلی از مدیر محلی کارساز استفاده می‌کند.
"socket-name": "kea-ddns-ctrl-socket",
// نوع سوکت کنترلی مورداستفاده توسط کارساز Kea DHCP-DDNS.
// سوکت 'unix' در حال حاضر تنها نوع پشتیبانی‌شده است.
"socket-type": "unix"
},
// فهرست کتابخانه‌های hook و پارامترهای پیکربندی خاص آن‌ها
// که باید توسط کارساز Kea DHCP-DDNS بارگذاری شوند.
"hooks-libraries": [
{
// مکان کتابخانهٔ hook برای بارگذاری.
"library": "ddns-server-commands.so",
// پارامترهای پیکربندی خاص کتابخانهٔ hook.
"parameters": { }
}
],
// بخش Forward DDNS (DNS پویا).
"forward-ddns": {
// فهرست دامنه‌های DDNS.
"ddns-domains": [
{
// نام زون (الزامی).
"name": "example.com.",
// نام کلید TSIG مورداستفاده برای محافظت از به‌روزرسانی‌های DNS
// برای نام‌های موجود در دامنه.
"key-name": "d2.md5.key",
// فهرست کارسازهای DNS که به‌روزرسانی‌های DNS به آن‌ها ارسال می‌شود.
"dns-servers": [
{
// آدرس IP کارساز DNS (الزامی).
"ip-address": "2001:db8:1::10",
// درگاه UDP کارساز DNS. پیش‌فرض 53 (سرویس DNS) است.
"port": 7802,
// نام کلید TSIG مورداستفاده برای محافظت از به‌روزرسانی‌های DNS
// ارسال‌شده به کارساز DNS.
"key-name": "d2.sha1.key"
}
]
}
]
},
// بخش Reverse DDNS (DNS معکوس پویا).
"reverse-ddns": {
// فهرست دامنه‌های DDNS.
"ddns-domains": [
{
// نام زون (الزامی).
"name": "2.0.192.in-addr.arpa.",
// نام کلید TSIG مورداستفاده برای محافظت از به‌روزرسانی‌های DNS
// برای نام‌های موجود در دامنه.
"key-name": "d2.sha1.key",
// فهرست کارسازهای DNS که به‌روزرسانی‌های DNS به آن‌ها ارسال می‌شود.
"dns-servers": [
{
// آدرس IP کارساز DNS (الزامی).
"ip-address": "172.16.1.1",
// درگاه UDP کارساز DNS. پیش‌فرض 53 (سرویس DNS) است.
"port": 5301,
// نام کلید TSIG مورداستفاده برای محافظت از به‌روزرسانی‌های DNS
// ارسال‌شده به کارساز DNS.
"key-name": "d2.md5.key"
}
]
}
]
},
// فهرست کلیدهای TSIG مورداستفاده برای محافظت از به‌روزرسانی‌های DNS.
"tsig-keys": [
{
// نام کلید TSIG (الزامی).
"name": "d2.md5.key",
// الگوریتم کلید TSIG (الزامی).
// مقدار باید یک نام الگوریتم معتبر باشد، مانند
// HMAC-MD5, HMAC-SHA1, HMAC-SHA224, ...
"algorithm": "HMAC-MD5",
// تعداد بیت‌ها در دایجست (digest). پیش‌فرض 0 است که به معنای
// استفاده از تمام بیت‌های ارائه‌شده توسط الگوریتم است. مقادیر بسیار کوتاه
// (بسته به الگوریتم) رد می‌شوند.
"digest-bits": 0,
// کلید مخفی کلید TSIG (الزامی) در قالب base-64.
"secret": "LSWXnfkKZjdPJI5QxlpnfQ=="
}
],
// فهرست لاگرهای مورداستفاده توسط کارسازهایی که از این فایل پیکربندی استفاده می‌کنند.
"loggers": [
{
// سطح دیباگ، مقداری بین 0..99. هرچه مقدار بزرگ‌تر باشد
// لاگ دیباگ با جزئیات بیشتری خواهد بود.
"debuglevel": 99,
// نام لاگر.
"name": "kea-dhcp-ddns",
// چگونگی خروجی لاگ را پیکربندی می‌کند.
"output-options": [
{
// مشخص می‌کند آیا لاگ باید در فایل فلاش (flush) شود یا خیر.
"flush": true,
// حداکثر اندازهٔ فایل را قبل از چرخش (rotation) مشخص می‌کند.
"maxsize": 10240000,
// حداکثر تعداد فایل‌های چرخش‌یافته برای نگه‌داری را مشخص می‌کند.
"maxver": 1,
// مقصد ثبت لاگ را مشخص می‌کند.
"output": "stdout",
// محتوای مدخل لاگ را مشخص می‌کند
"pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// شدت لاگ‌برداری را مشخص می‌کند، یعنی "ERROR"، "WARN"، "INFO"، "DEBUG".
"severity": "INFO"
}
],
// برای کاربرد user-contextها مثال sample1 را ببینید.
"user-context": { }
}
}
168u
0.0
3.5
// هشدار: این پیکربندی نمونه برای استفاده در محیط عملیاتی در نظر گرفته نشده است.
// سرور Kea DHCP-DDNS ممکن است این پیکربندی را رد کند زیرا ممکن است
// شامل پارامترهای پیکربندی ناسازگار با یکدیگر (مانعة‌الجمع) باشد.
//
// هدف اصلی این فایل نمونه، ارائه فهرستی جامع از پارامترهای پشتیبانی‌شده
// توسط سرور Kea DHCP-DDNS به همراه توضیح مختصری از هر پارامتر است.
//
// این نسخه فعلی باید به‌روز باشد، یعنی کلیدواژه‌های جدید باید هم‌زمان
// با مشخصات تجزیه‌کننده (parser) به این فایل اضافه شوند.
{
// پیکربندی سرور Kea DHCP-DDNS از اینجا آغاز می‌شود.
"DhcpDdns": {
// پارامترهای سراسری
// نشانی IP که D2 برای درخواست‌های به‌روزرسانی روی آن گوش می‌دهد.
// پیش‌فرض 127.0.0.1 است.
"ip-address": "127.0.0.1",
// درگاهی که D2 برای درخواست‌های به‌روزرسانی روی آن گوش می‌دهد.
// پیش‌فرض 53001 است.
"port": 53001,
// بیشینه زمانی که منتظر پاسخ سرور DNS می‌مانیم.
// واحد آن میلی‌ثانیه است، پیش‌فرض 100ms است.
"dns-server-timeout" : 100,
// پروتکل مورد استفاده برای Name Change Requests از یک سرور Kea DHCP.
// در حال حاضر فقط 'UDP' پشتیبانی می‌شود.
"ncr-protocol": "UDP",
// قالب مورد استفاده برای Name Change Requests از یک سرور Kea DHCP.
// در حال حاضر فقط 'JSON' پشتیبانی می‌شود.
"ncr-format": "JSON",
// پارامترهای پیکربندی سوکت کنترل فرمان برای سرور Kea DHCP-DDNS.
"control-sockets": [
{
// نوع سوکت کنترل استفاده‌شده توسط سرور Kea DHCP-DDNS.
// باید unix، http یا https باشد.
"socket-type": "unix",
// مکان فایل سوکت دامنه یونیکس (UNIX domain socket) که سرور
// DHCP-DDNS برای دریافت فرمان‌های کنترلی از مدیر محلی سرور
// استفاده می‌کند.
"socket-name": "kea-ddns-ctrl-socket"
},
{
// نوع سوکت کنترل استفاده‌شده توسط سرور Kea DHCP-DDNS.
// باید unix، http یا https باشد.
"socket-type": "https",
// نشانی سوکت HTTPS که سرور Kea DHCP-DDNS باید برای پرس‌وجوهای
// ورودی روی آن گوش دهد.
"socket-address": "127.0.0.1",
// درگاه سوکت HTTPS که سرور Kea DHCP-DDNS باید برای پرس‌وجوهای
// ورودی روی آن گوش دهد.
"socket-port": 8053,
// لنگر اعتماد TLS (مرجع صدور گواهی یا CA). این مورد یک نام
// فایل یا مسیر دایرکتوری است. همراه با سایر پارامترهای TLS
// فقط برای سوکت کنترل نوع https معنادار است.
"trust-anchor": "my-ca",
// نام فایل گواهی سرور TLS.
"cert-file": "my-cert",
// نام فایل کلید خصوصی سرور TLS.
"key-file": "my-key",
// پرچم الزام گواهی‌های کلاینت TLS. مقدار پیش‌فرض true
// است و به معنای الزام گواهی کلاینت است. مقدار false به این
// معنی است که اختیاری هستند.
"cert-required": true,
// احراز هویت اختیاری.
"authentication": {
// نوع احراز هویت الزامی. تنها مقدار پشتیبانی‌شده
// basic برای احراز هویت پایه HTTP است.
"type": "basic",
// قلمرو (realm) احراز هویت پایه HTTP یک پارامتر اختیاری
// است. پیش‌فرض آن
// "kea-dhcp-ddns-server" است.
"realm": "kea-dhcp-ddns-server",
// از این پارامتر اختیاری می‌توان برای تعیین یک پیشوند مشترک
// برای فایل‌های مدیریت اعتبارنامه‌های کلاینت استفاده کرد.
"directory": "/usr/local/share/kea/kea-creds",
// این فهرست شناسه‌های کاربری و گذرواژه‌های مورد استفاده برای
// احراز هویت پایه HTTP را مشخص می‌کند. در صورت خالی بودن یا
// عدم وجود، هر کلاینتی مجاز شمرده می‌شود.
"clients": [
// این مورد یک کلاینت مجاز را مشخص می‌کند.
{
// شناسه کاربری نباید خالی باشد یا نویسه
// ':' را در بر داشته باشد. این یک پارامتر الزامی است.
"user": "admin",
// اگر گذرواژه مشخص نشود، یک گذرواژه خالی
// استفاده می‌شود.
"password": "1234"
},
// این مورد یک کلاینت پنهان را مشخص می‌کند.
{
// شناسه کاربری محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenu است.
"user-file": "hiddenu",
// گذرواژه محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenp است.
"password-file": "hiddenp"
},
// این مورد یک کلاینت پنهان را با استفاده از یک راز در یک فایل
// مشخص می‌کند.
{
// این راز محتوای فایل
// /usr/local/share/kea/kea-creds/hiddens است که باید
// در قالب <user-id>:<password> باشد.
"password-file": "hiddens"
}
]
}
}
],
// فهرست کتابخانه‌های قلاب (hook) و پارامترهای پیکربندی خاص آن‌ها
// که باید توسط سرور Kea DHCP-DDNS بارگذاری شوند.
"hooks-libraries": [
{
// مکان کتابخانه قلاب جهت بارگذاری.
"library": "ddns-server-commands.so",
// پارامترهای پیکربندی مختص کتابخانه قلاب.
"parameters": { }
}
],
// سرور DDNS مستقیم (Forward DDNS / Dynamic DNS).
"forward-ddns": {
// فهرست دامنه‌های DDNS.
"ddns-domains": [
{
// نام ناحیه (الزامی).
"name": "example.com.",
// نام کلید TSIG استفاده‌شده برای محافظت از به‌روزرسانی‌های DNS
// برای نام‌های موجود در دامنه.
"key-name": "d2.md5.key",
// فهرست سرورهای DNS که به‌روزرسانی‌های DNS به آن‌ها ارسال می‌شود.
"dns-servers": [
{
// نشانی IP سرور DNS (الزامی).
"ip-address": "2001:db8:1::10",
// درگاه UDP سرور DNS. پیش‌فرض 53 (سرویس DNS) است.
"port": 7802,
// نام کلید TSIG استفاده‌شده برای محافظت از به‌روزرسانی‌های DNS
// ارسال‌شده به سرور DNS.
"key-name": "d2.sha1.key"
}
]
}
]
},
// سرور DDNS معکوس (Reverse DDNS / Dynamic DNS).
"reverse-ddns": {
// فهرست دامنه‌های DDNS.
"ddns-domains": [
{
// نام ناحیه (الزامی).
"name": "2.0.192.in-addr.arpa.",
// نام کلید TSIG استفاده‌شده برای محافظت از به‌روزرسانی‌های DNS
// برای نام‌های موجود در دامنه.
"key-name": "d2.sha1.key",
// فهرست سرورهای DNS که به‌روزرسانی‌های DNS به آن‌ها ارسال می‌شود.
"dns-servers": [
{
// نشانی IP سرور DNS (الزامی).
"ip-address": "172.16.1.1",
// درگاه UDP سرور DNS. پیش‌فرض 53 (سرویس DNS) است.
"port": 5301,
// نام کلید TSIG استفاده‌شده برای محافظت از به‌روزرسانی‌های DNS
"key-name": "d2.md5.key"
}
]
}
]
},
// فهرست کلیدهای TSIG استفاده‌شده برای محافظت از به‌روزرسانی‌های DNS.
"tsig-keys": [
{
// نام کلید TSIG (الزامی).
"name": "d2.md5.key",
// الگوریتم کلید TSIG (الزامی).
// این مقدار باید یک نام الگوریتم معتبر باشد، به عنوان مثال:
// HMAC-MD5, HMAC-SHA1, HMAC-SHA224, ...
"algorithm": "HMAC-MD5",
// تعداد بیت‌ها در دایجست (digest). پیش‌فرض 0 است که به معنای
// استفاده از تمام بیت‌های ارائه‌شده توسط الگوریتم است. مقادیر بیش از حد کوتاه
// (بسته به الگوریتم) رد می‌شوند.
"digest-bits": 0,
// رمز (secret) کلید TSIG (الزامی) در قالب base-64.
"secret": "LSWXnfkKZjdPJI5QxlpnfQ=="
},
{
"name": "d2.sha1.key",
"algorithm": "HMAC-SHA1",
// یک جایگزین برای secret: مشخص کردن فایلی که رمز در آن
// یافت می‌شود؛ یعنی رمز، محتوای فایل است.
"secret-file": "/usr/local/share/kea/d2-sha1-secret"
}
],
// فهرست ثبت‌کننده‌های وقایع (loggers) مورد استفاده توسط سرورهایی که از این فایل پیکربندی استفاده می‌کنند.
"loggers": [
{
// سطح اشکال‌زدایی (Debug level)، مقداری بین 0..99. هرچه مقدار
// بزرگ‌تر باشد، گزارش اشکال‌زدایی با جزئیات بیشتری خواهد بود.
"debuglevel": 99,
// نام ثبت‌کننده وقایع (logger).
"name": "kea-dhcp-ddns",
// چگونگی خروجی گزارش وقایع را پیکربندی می‌کند.
"output-options": [
{
// مشخص می‌کند که آیا گزارش باید بلافاصله روی فایل تخلیه (flush) شود یا خیر.
"flush": true,
// بیشینه اندازه فایل قبل از چرخش (rotate) فایل را مشخص می‌کند.
"maxsize": 10240000,
// بیشینه تعداد فایل‌های چرخیده نگه‌داری‌شده را مشخص می‌کند.
"maxver": 1,
// مقصد ثبت وقایع را مشخص می‌کند.
"output": "stdout",
// محتوای مدخل ثبت وقایع را مشخص می‌کند.
"pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// سطح اهمیت ثبت وقایع را مشخص می‌کند؛ یعنی "ERROR"، "WARN"، "INFO"، "DEBUG".
"severity": "INFO"
}
],
// برای استفاده از user-contexts به مثال sample1 نگاه کنید.
"user-context": { }
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای D2، پردازشگر DHCP-DDNS در Kea است.
// این فایل از کامنت‌های تعبیه‌شده استفاده می‌کند که به‌جای حذف‌شدن در مرحله تحلیل لغوی،
// درون اشیاء پیکربندی در user-contextها گنجانده می‌شوند.
{
"DhcpDdns":
{
// حوزه سراسری
"comment": "A DHCP-DDNS server",
"ip-address": "127.0.0.1",
"port": 53001,
"dns-server-timeout" : 1000,
// در سوکت‌های کنترلی.
"control-sockets": [
{
"socket-type": "unix",
"socket-name": "kea-ddns-ctrl-socket",
"user-context": { "comment": "Indirect comment" }
},
{
"comment": "HTTP control socket",
"socket-type": "http",
"socket-address": "::1",
"socket-port": 8053,
// در احراز هویت
"authentication": {
"comment": "basic HTTP authentication",
"type": "basic",
// در کلاینت‌های احراز هویت پایه HTTP
"clients": [ {
"comment": "admin is authorized",
"user": "admin",
"password": "1234"
} ]
}
}
],
"forward-ddns":
{
"ddns-domains":
[
// در دامنه DDNS
{
"comment": "DdnsDomain for zone 'four.example.com.'",
"name": "four.example.com.",
"key-name": "d2.md5.key",
// در سرور DNS
"dns-servers":
[
{
"comment": "four.example.com. server",
"ip-address": "172.16.1.1"
}
]
}
]
},
// در کلید TSIG
"tsig-keys":
[
{
"comment": "four.example.com. key",
"name": "d2.md5.key",
"algorithm": "HMAC-MD5",
"secret": "LSWXnfkKZjdPJI5QxlpnfQ=="
}
],
// در لاگرها (loggers)
"loggers": [
{
"comment": "A logger",
"name": "kea-dhcp-ddns",
"severity": "info"
}
]
}
}
168u
168u
ddns/gss-tsig.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای D2، پردازشگر DHCP-DDNS در Kea است.
// این پیکربندی از کتابخانه قلاب (hook library) GSS-TSIG استفاده می‌کند.
{
"DhcpDdns": {
// پارامترهای زیر برای دریافت NCRها (NameChangeRequests) از سرور محلی
// Kea DHCP استفاده می‌شوند. اطمینان حاصل کنید که kea-dhcp4 و kea-dhcp6
// شما با این مقادیر مطابقت داشته باشند.
"ip-address": "127.0.0.1",
"port": 53001,
"dns-server-timeout" : 1000,
// زون مستقیم (Forward zone): secure.example.org. این زون از GSS-TSIG استفاده می‌کند.
// این زون توسط دو سرور DNS ارائه می‌شود که به درخواست‌های DDNS در 192.0.2.1
// و 192.0.2.2 گوش فرا می‌دهند.
"forward-ddns":
{
"ddns-domains":
[
// ‏DdnsDomain برای زون "secure.example.org."
{
"name": "secure.example.org.",
"comment": "DdnsDomain example",
"dns-servers":
[
{
// این سرور مدخلی در gss/servers دارد و
// بنابراین از GSS-TSIG استفاده خواهد کرد.
"ip-address": "192.0.2.1"
},
{
// این سرور نیز در آنجا مدخلی دارد، بنابراین آن هم
// از GSS-TSIG استفاده خواهد کرد.
"ip-address": "192.0.2.2",
"port": 5300
}
]
}
]
},
// زون معکوس (Reverse zone): می‌خواهیم زون معکوس "2.0.192.in-addr.arpa" را به‌روزرسانی کنیم.
"reverse-ddns":
{
"ddns-domains":
[
{
"name": "2.0.192.in-addr.arpa.",
"dns-servers":
[
{
// یک تعریف GSS-TSIG برای این سرور وجود دارد (ببینید:
// ‏DhcpDdns/gss-tsig/servers)، بنابراین از
// ‏Krb/GSS-TSIG استفاده خواهد کرد.
"ip-address": "192.0.2.1"
}
]
}
]
},
// قلاب (hook) مربوط به GSS-TSIG بارگذاری شده و پیکربندی آن در اینجا مشخص شده است.
"hooks-libraries": [
{
"library": "libddns_gss_tsig.so",
"parameters": {
// این بخش یکپارچه‌سازی با GSS-TSIG را هدایت می‌کند. هر سروری که در
// forward-ddns و/یا reverse-ddns ذکر شده، باید مدخلی در اینجا داشته
// باشد تا بتواند از مقادیر پیش‌فرض GSS-TSIG استفاده کند (اختیاری است،
// در صورت تعیین، برای تمام سرورهای GSS-TSIG اعمال می‌شوند مگر اینکه
// در سطح یک سرور خاص بازنویسی شده باشند).
"server-principal": "DNS/server.example.org@EXAMPLE.ORG",
"client-principal": "DHCP/admin.example.org@EXAMPLE.ORG",
// از هر دو مورد client-keytab و credentials-cache می‌توان برای
// ذخیره کلیدهای کلاینت استفاده کرد. از آنجا که حافظه موقت اعتبارنامه
// انعطاف‌پذیرتر است، استفاده از آن توصیه می‌شود. معمولاً استفاده هم‌زمان
// از هر دو در یک زمان ممکن است باعث ایجاد مشکل شود.
// "client-keytab": "FILE:/etc/dhcp.keytab", // فقط در بالاترین سطح
"credentials-cache": "FILE:/etc/ccache", // فقط در بالاترین سطح
"gss-replay-flag": true, // سرویس ضد بازپخش GSS
"gss-sequence-flag": false, // بدون سرویس توالی GSS
"tkey-lifetime": 3600, // ۱ ساعت
"rekey-interval": 2700, // ۴۵ دقیقه
"retry-interval": 120, // ۲ دقیقه
"tkey-protocol": "TCP",
"fallback": false,
// فهرست سرورهای با قابلیت GSS-TSIG
"servers": [
{
// سرور نخست (شناسایی الزامی است)
"id": "server1",
"domain-names": [ ], // در صورت عدم تعیین یا خالی بودن، با تمام
// دامنه‌هایی که خواهان استفاده از این جفت
// IP+port هستند مطابقت خواهد داشت
"ip-address": "192.0.2.1",
"port": 53,
"server-principal": "DNS/server1.example.org@EXAMPLE.ORG",
"client-principal": "DHCP/admin1.example.org@EXAMPLE.ORG",
"gss-replay-flag": false, // بدون سرویس ضد بازپخش GSS
"gss-sequence-flag": false, // بدون سرویس توالی GSS
"tkey-lifetime": 7200, // ۲ ساعت
"rekey-interval": 5400, // ۹۰ دقیقه
"retry-interval": 240, // ۴ دقیقه
"tkey-protocol": "TCP",
"fallback": true // اگر هیچ کلیدی در دسترس نبود، بازگشت به
// رفتار استاندارد (در مقایسه با صرف‌نظر از این سرور)
},
{
// سرور دوم (بیشتر پارامترها را ندارد چرا که از
// مقادیر پیش‌فرض تعیین‌شده در بالا استفاده می‌کنند)
"id": "server2",
"ip-address": "192.0.2.2",
"port": 5300
}
]
}
}
]
// پارامترهای اضافی مانند لاگ‌گیری (logging)، سوکت کنترلی و
// موارد دیگر به منظور وضوح بیشتر حذف شده‌اند.
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای D2، پردازشگر DHCP-DDNS در Kea است.
// این پیکربندی از به‌روزرسانی دو ناحیه Forward DNS با نام‌های "four.example.com" و
// "six.example.com"؛ و یک ناحیه Reverse DNS با نام "2.0.192.in-addr.arpa." پشتیبانی می‌کند.
{
// ------------------ DHCP-DDNS ---------------------
"DhcpDdns":
{
// -------------- پارامترهای سراسری ----------------
// D2 برای درخواست‌های به‌روزرسانی از کارگزارهای Kea DHCP روی 127.0.0.1
// در درگاه 53001 گوش فراخواهد داد. بیشینه زمانی که منتظر پاسخ یک
// کارگزار DNS خواهیم ماند 1000 میلی‌ثانیه است.
"ip-address": "127.0.0.1",
"port": 53001,
"dns-server-timeout" : 1000,
// یک ویژگی اضافی که نیاز به توضیح دارد user-context است.
// این ساختاری است که می‌توانید در دامنه سراسری، در ddns domain،
// dns server، tsig key و موارد دیگر تعریف کنید. این ساختار توسط
// Kea تجزیه می‌شود، اما مستقیماً استفاده نمی‌شود. هدف آن نگهداری هر چیزی
// است که مایل به قرار دادن آن هستید - یادداشت‌ها، عناوین اضافی، نام طبقه
// یا بخش و غیره.
// یک مدخل comment به یک user-context با ویژگی "comment"
// تبدیل می‌شود تا بتوانید یادداشت‌ها را درون خود پیکربندی درج کنید.
"user-context": { "version": 1 },
// ----------------- Control Socket (سوکت کنترلی) -----------------
"control-socket":
{
"socket-type": "unix",
"socket-name": "kea-ddns-ctrl-socket"
},
// ----------------- Hooks Libraries (کتابخانه‌های قلاب) -----------------
"hooks-libraries":
[
// فهرست کتابخانه‌های قلاب می‌تواند شامل بیش از یک کتابخانه باشد.
{
// تنها پارامتر ضروری نام فایل کتابخانه است.
"library": "ddns-server-commands.so",
// برخی کتابخانه‌ها ممکن است از پارامترها پشتیبانی کنند. دقت کنید
// که این بخش را با دقت وارد نمایید، زیرا کارگزار آن را اعتبارسنجی
// نمی‌کند (زیرا قالب آن مختص به هر کتابخانه است).
"parameters":
{
"param1": "foo"
}
}
],
// ----------------- Forward DDNS ------------------
// 1. ناحیه - "four.example.com."
// از TSIG استفاده می‌کند، نام کلید "d2.md5.key" است
// توسط یک کارگزار DNS ارائه می‌شود که به درخواست‌های DDNS روی
// 172.16.1.1 در درگاه پیش‌فرض 53 (درگاه استاندارد DNS) گوش می‌دهد
// 2. ناحیه - "six.example.com."
// از TSIG استفاده نمی‌کند.
// توسط یک کارگزار DNS روی "2001:db8:1::10" در درگاه 7802 ارائه می‌شود
"forward-ddns":
{
"ddns-domains":
[
// DdnsDomain برای ناحیه "four.example.com."
{
"comment": "DdnsDomain example",
"name": "four.example.com.",
"key-name": "d2.md5.key",
"dns-servers":
[
{
"ip-address": "172.16.1.1"
}
]
},
// DdnsDomain برای ناحیه "six.example.com."
{
"name": "six.example.com.",
"dns-servers":
[
{
"ip-address": "2001:db8:1::10",
"port": 7802
}
]
}
]
},
// ----------------- Reverse DDNS ------------------
// ما Reverse DNS را برای یک ناحیه "2.0.192.in-addr-arpa" به‌روزرسانی خواهیم کرد. این ناحیه
// از TSIG با کلید "d2.sha1.key" استفاده می‌کند و توسط دو کارگزار DNS ارائه می‌شود:
// یکی روی "172.16.1.1" در 53001 و دیگری روی "192.168.2.10" گوش می‌دهد.
"reverse-ddns":
{
"ddns-domains":
[
{
"name": "2.0.192.in-addr.arpa.",
"key-name": "d2.sha1.key",
"dns-servers":
[
{
"ip-address": "172.16.1.1",
"port": 53001
},
{
"ip-address": "192.168.2.10"
}
]
}
]
},
// ------------------ TSIG keys (کلیدهای TSIG) ---------------------
// هر کلید دارای یک نام، یک الگوریتم (HMAC-MD5، HMAC-SHA1، HMAC-SHA224...)
// و یک راز مشترک با کدگذاری base-64 است.
"tsig-keys":
[
{
"name": "d2.md5.key",
"algorithm": "HMAC-MD5",
"secret": "LSWXnfkKZjdPJI5QxlpnfQ=="
},
{
"name": "d2.sha1.key",
"algorithm": "HMAC-SHA1",
"secret": "hRrp29wzUv3uzSNRLlY68w=="
},
{
"name": "d2.sha256.key",
"algorithm": "HMAC-SHA256",
"secret-file": "/usr/local/share/kea/d2-sha256-secret"
},
{
"name": "d2.sha512.key",
"algorithm": "HMAC-SHA512",
"digest-bits": 256,
"secret": "/4wklkm04jeH4anx2MKGJLcya+ZLHldL5d6mK+4q6UXQP7KJ9mS2QG29hh0SJR4LA0ikxNJTUMvir42gLx6fGQ=="
}
],
// بخش زیر ثبت وقایع را پیکربندی می‌کند. فرض بر این است پیام‌هایی که دست‌کم
// سطح اطلاعاتی (info، warn، error و fatal) دارند باید در stdout ثبت شوند.
// همچنین یک الگوی ثبت وقایع سفارشی را مشخص می‌کند.
"loggers": [
{
"name": "kea-dhcp-ddns",
"output-options": [
{
"output": "stdout",
// علاوه بر خروجی معمول، چندین پارامتر دیگر نیز امکان‌پذیر است.
// پارامتر Flush تعیین می‌کند که آیا ثبت‌کننده وقایع خروجی را به یک فایل
// تخلیه کند یا خیر. Maxsize حداکثر اندازه فایل را پیش از چرخش
// فایل تعیین می‌کند. maxver حداکثر تعداد فایل‌های نگهداری‌شده
// در چرخش را مشخص می‌سازد.
"flush": true,
"maxsize": 204800,
"maxver": 4,
"pattern": "%d [%c/%i] %m\n"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این فایل می‌تواند به عنوان الگویی برای ایجاد پیکربندی JSON در
// DHCP-DDNS به کار رود.
// باید با یک آکولاد باز آغاز شود.
{
"DhcpDdns" :
{
// -------------- پارامترهای سراسری ----------------
// تمام پارامترهای سراسری دارای مقادیر پیش‌فرضی مطابق نمایش هستند. اگر این
// مقادیر رضایت‌بخش هستند، می‌توانید از آن‌ها صرف‌نظر کنید.
// "ip-address" : "127.0.0.1",
// "port" : 53001,
// "dns-server-timeout" : 100,
// "ncr-protocol" : "UDP"
// "ncr-format" : "JSON"
// ----------------- سوکت کنترلی -----------------
// "control-socket":
// {
// "socket-type": "unix",
// "socket-name": "kea-ddns-ctrl-socket"
// },
// ----------------- DDNS مستقیم ------------------
"forward-ddns" :
{
"ddns-domains" :
[
// {
// "name" : "<zone name 1>",
// "key-name" : "<key name>",
// "dns-servers" :
// [
// {
// "ip-address" : "<ip address>"
// ,"port" : 53
// }
// ,
// {
// سرور DNS بعدی برای این DdnsDomain
// }
// :
// ]
// }
// ,
// {
// DdnsDomain مستقیم بعدی
// }
// :
]
},
// ----------------- DDNS معکوس ------------------
"reverse-ddns" :
{
"ddns-domains" :
[
// {
// "name" : "<reverse zone name 1>",
// "key-name" : "<key name>",
// "dns-servers" :
// [
// {
// "ip-address" : "<ip address>"
// ,"port" : 53
// }
// ,
// {
// سرور DNS بعدی برای این DdnsDomain
// }
// :
// ]
// }
// ,
// {
// DdnsDomain معکوس بعدی
// }
// :
]
},
// ------------------ کلیدهای TSIG ---------------------
"tsig-keys" :
[
// {
// "name" : "<key name>",
// "algorithm" : "<algorithm name>",
// مقادیر معتبر برای algorithm عبارتند از: HMAC-MD5, HMAC-SHA1,
// HMAC-SHA224, HMAC-SHA256,
// HMAC-SHA384, HMAC-SHA512
// "digest-bits" : 256,
// حداقل طول کوتاه‌شده بر حسب بیت.
// پیش‌فرض 0 (به معنای ممنوع بودن کوتاه‌سازی است).
// "secret" : "1234" (مقدار رمز مشترک)
// }
// ,
// {
// کلید TSIG بعدی
// }
]
// ثبت وقایع
// ,"loggers":
// [
// {
// "name": "kea-dhcp-ddns",
// "severity": "info"
// }
// ]
}
// باید با یک آکولاد بسته پایان یابد.
}
168u
kea4/advanced.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این فایل برخی از قابلیت‌های پیشرفته‌تر را پوشش می‌دهد. این فایل ممکن است
// یکپارچه نباشد زیرا هدف اصلی آن نشان دادن قابلیت‌ها است. لزوماً قرار نیست
// استفاده هم‌زمان آن‌ها با یکدیگر منطقی باشد.
// تجزیه‌کننده جدید از ۳ سبک کامنت پشتیبانی می‌کند:
// این سبک ++C است.
# این سبک bash است.
/* این یک کامنت به سبک C است. */
/* کامنت به سبک C
می‌تواند چند خط
را در بر بگیرد */
{ "Dhcp4":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ],
// این گزینه مشخص می‌کند که Kea از چه نوع سوکتی استفاده می‌کند. در حال حاضر
// مقادیر پشتیبانی‌شده 'raw' (که پیش‌فرض است) و 'udp' هستند. سوکت raw این مزیت
// را دارد که همیشه همه ترافیک را دریافت می‌کند و این عیب را دارد که تمام قوانین
// دیوار آتش را دور می‌زند و اثر منفی اندکی بر کارایی دارد.
// اگر فقط ترافیک رله‌شده دارید، 'udp' عموماً بهتر است. سپس Kea
// یک سوکت عادی UDP باز می‌کند و هسته تمام پردازش‌های پشته Ethernet/IP
// را انجام می‌دهد.
"dhcp-socket-type": "udp",
// معمولاً کارساز DHCP پاسخ خود را از همان رابطی بازمی‌فرستد که
// پرس‌وجو از آن وارد شده است. این حالت پیش‌فرض است ("same-as-inbound").
// با این حال، گاهی اوقات این قابلیت مفید است که بسته به عنوان یک بسته عادی UDP
// ارسال شود و به هسته و جدول‌های مسیریابی اجازه داده شود که رابط درست را
// تعیین کنند ("use-routing"). این گزینه تنها هنگامی کار می‌کند
// که "dhcp-socket-type" روی "udp" تنظیم شده باشد و در غیر این صورت نادیده گرفته می‌شود.
"outbound-interface": "use-routing",
// این باعث می‌شود رابط‌ها در هر بار پیکربندی (مجدد) دوباره شناسایی شوند.
// به طور پیش‌فرض true است.
"re-detect": true
},
"sanity-checks": {
// این پارامتر تعیین می‌کند هنگامی که یک اجاره (lease) جدید در
// سیستم ظاهر می‌شود (یعنی یا در هنگام راه‌اندازی memfile از دیسک خوانده می‌شود یا
// از طریق دستورهای lease اضافه می‌شود) چه کاری انجام شود. پنج حالت پشتیبانی می‌شود:
// none - هیچ کاری انجام نده، آن‌ها را همان‌طور که هستند بپذیر
// warn - اگر مشکلی در subnet-id شناسایی شد، یک هشدار چاپ کن، اما
// در غیر این صورت اجاره را همان‌طور که هست بارگذاری کن. این مقدار پیش‌فرض است.
// fix - تلاش برای اصلاح اجاره با یافتن مقدار subnet-id مناسب.
// اگر زیرشبکه مناسبی نباشد، اجاره همان‌طور که هست بارگذاری می‌شود.
// fix-del - تلاش برای اصلاح اجاره با یافتن مقدار subnet-id
// مناسب. اگر زیرشبکه مناسبی نباشد، اجاره حذف می‌شود.
// del - حذف اجاره‌هایی که مقادیر subnet-id نادرست دارند.
"lease-checks": "fix-del"
},
// تعریف چاره آخر گزینه ۴۳ (Option 43) می‌تواند باعث شود پیام‌های باساختار درست
// رد شوند چون از مقدار ناسازگار "raw" استفاده می‌کنند،
// و سازندگان مختلف ممکن است زیرگزینه‌های متفاوتی را تعریف کنند.
// تعریف گزینه باید برای جلوگیری از این مشکلات اعمال شود،
// به عنوان نمونه با تعریف گزینه به صورت binary در دامنه سراسری.
// در client-classes این گزینه ممکن است طوری بازتعریف شود که حامل
// زیرگزینه‌های وابسته به سازنده باشد.
"option-def": [ {
"name": "vendor-encapsulated-options",
"code": 43,
"type": "binary"
} ],
// ما باید پایگاه داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن ۲۰۲۲، سه پس‌بند پایگاه داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه داده درون‌حافظه‌ای، Memfile.
// ما از memfile استفاده خواهیم کرد چون به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
// برای memfile، مهم است که همیشه lfc-interval مشخص شود، تا
// فایل اجاره بدون محدودیت رشد نکند و ساعتی یک‌بار پاک‌سازی شود.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// این یک سوکت کنترلی را تعریف می‌کند. در صورت تعریف، Kea یک سوکت UNIX باز کرده
// و به دستورهای ورودی گوش خواهد داد. برای دیدن فهرست دستورهای پشتیبانی‌شده،
// به بخش ۱۵ راهنمای کاربر Kea مراجعه کنید.
"control-socket": {
"socket-type": "unix",
"socket-name": "kea4-ctrl-socket"
},
// نشانی‌ها با طول عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
// به کلاینت گفته می‌شود که تمدید را پس از ۱۰۰۰ ثانیه آغاز کند. اگر کارساز
// در عرض ۲۰۰۰ ثانیه پس از اعطای اجاره پاسخ ندهد، کلاینت
// باید رویه REBIND را آغاز کند (تمدید اضطراری که امکان
// جابه‌جایی به یک کارساز دیگر را فراهم می‌کند).
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// استاندارد RFC6842 می‌گوید که کارساز باید گزینه client-id را بازتاب (echo) دهد.
// با این حال، برخی کلاینت‌های قدیمی‌تر از این پشتیبانی نکرده و وقتی
// client-id خود را دریافت می‌کنند دچار سردرگمی می‌شوند. Kea می‌تواند پشتیبانی از RFC6842 را غیرفعال کند.
"echo-client-id": false,
// برخی کلاینت‌ها از شناسه کلاینت پایدار استفاده نمی‌کنند، بلکه
// در هر بار بوت آن را تولید می‌کنند. این ممکن است باعث شود کلاینتی که
// مکرراً راه‌اندازی مجدد می‌شود چندین اجاره دریافت کند، که ممکن است
// مطلوب نباشد. از این رو، گاهی مدیران ترجیح می‌دهند به کارساز DHCPv4
// خود بگویند که مقدار client-id را به کلی نادیده بگیرد و منحصراً
// به نشانی MAC اتکا کند. این پارامتری است که به صورت سراسری تعریف می‌شود، اما
// می‌تواند در سطح زیرشبکه بازنویسی شود.
"match-client-id": true,
// به طور پیش‌فرض، Kea درخواست‌های کلاینت‌ها برای نشانی‌های IP ناشناخته را نادیده می‌گیرد،
// چرا که ممکن است کارسازهای DHCP غیرهمکار دیگری در همان شبکه وجود داشته باشند (RFC 2131).
// این پارامتر به صورت سراسری تعریف شده است، اما می‌تواند در سطح زیرشبکه بازنویسی شود
"authoritative": false,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل از
// مدخل‌های subnet و pool تشکیل شده است. یک قابلیت اضافی که نیاز به
// کمی توضیح دارد user-context است. این ساختاری است که می‌توانید
// در زیرشبکه‌ها، استخرها و موارد دیگر تعریف کنید. توسط Kea تجزیه می‌شود، اما
// مستقیماً استفاده نمی‌شود. هدف آن نگهداری هر چیزی است که ممکن است بخواهید
// در آنجا بگذارید - کامنت‌ها، نام‌گذاری‌های اضافی، نام طبقه یا بخش
// و غیره. این ساختارها در دسترس قلاب‌های Kea قرار خواهند گرفت.
// یک مدخل comment به یک user-context با ویژگی "comment" ترجمه می‌شود
// تا بتوانید کامنت‌ها را درون خود پیکربندی بگنجانید.
"subnet4": [
{
"pools": [ {
"pool": "192.0.2.1 - 192.0.2.200",
"user-context": { "info": "what a large pool" }
} ],
"id": 1,
"subnet": "192.0.2.0/24",
"user-context": {
"comment": "Our first subnet!"
}
// معادل با استفاده از تجزیه‌کننده هوشمند
// "comment": "Our first subnet!"
},
{
// مقدار match-client-id در این زیرشبکه خاص تغییر یافته است.
// این باعث می‌شود Kea مقادیر client-id را در این زیرشبکه نادیده بگیرد
// و منحصراً به نشانی‌های MAC اتکا کند.
"pools": [ { "pool": "192.0.3.100 - 192.0.3.200" } ],
"id": 2,
"subnet": "192.0.3.0/24",
"match-client-id": false
},
{
"pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ],
"id": 3,
"subnet": "192.0.4.0/24",
// گاهی اوقات ممکن است رله از یک نشانی IPv4 استفاده کند که
// با زیرشبکه مطابقت ندارد. این کار توصیه نمی‌شود، اما موارد
// معتبری وجود دارد که منطقی است. یک مورد زمانی است که
// یک زیرشبکه اشتراکی وجود دارد.
"relay": {
"ip-addresses": [ "192.168.1.1" ]
}
},
{
// مقدار authoritative در این زیرشبکه خاص تغییر کرده است.
// این امر باعث می‌شود Kea به درخواست‌ها برای نشانی‌های IP نامشخص
// با یک پیام DHCPNAK پاسخ دهد.
"pools": [ { "pool": "192.0.5.100 - 192.0.5.200" } ],
"id": 4,
"subnet": "192.0.5.0/24",
"authoritative": true
}
],
// موارد زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی با
// حداقل سطح اطلاعاتی (info، warn، error و fatal) باید
// در stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout",
// علاوه بر خروجی معمول، چندین پارامتر اضافی
// دیگر نیز امکان‌پذیر است. Flush تعیین می‌کند که آیا گزارش‌گیر
// خروجی را در یک فایل تخلیه می‌کند یا خیر. Maxsize حداکثر
// اندازه فایل را پیش از چرخش فایل تعیین می‌کند. maxver
// حداکثر تعداد فایل‌های چرخیده‌ای که نگهداری می‌شوند را
// مشخص می‌کند.
"flush": true,
"maxsize": 204800,
"maxver": 4,
// ما از pattern برای مشخص کردن چیدمان سفارشی پیام گزارش استفاده می‌کنیم
"pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// هشدار: این پیکربندی نمونه برای استفاده در محیط عملیاتی در نظر گرفته نشده است.
// کارگزار Kea DHCPv4 این پیکربندی را رد خواهد کرد زیرا حاوی پارامترهای
// پیکربندی ناسازگار با یکدیگر (مانعة‌الجمع) است.
//
// هدف اصلی این فایل نمونه، ارائه فهرستی جامع از پارامترهای پشتیبانی‌شده
// توسط کارگزار Kea DHCPv4 به همراه توضیح مختصری از هر پارامتر است.
//
// این نسخه پایدار برای YANG استفاده می‌شود، زیرا نمی‌خواهیم هر بار که
// یک کلمه کلیدی به نحو اضافه می‌شود، کد و مدل‌ها به‌روزرسانی شوند.
{
// پیکربندی کارگزار Kea DHCPv4 از اینجا آغاز می‌شود.
"Dhcp4": {
// پرچم سراسری برای انتخاب راهبرد تخصیص آدرس IP برای همه
// زیرشبکه‌ها. برای راهبرد تخصیص تصادفی از "random" استفاده کنید.
"allocator": "iterative",
// پرچم معتبر (authoritative) سراسری برای رسیدگی به درخواست‌های کلاینت‌ها
// برای آدرس‌های IP نامشخص (در صورت غیرفعال بودن نادیده گرفته می‌شود، در صورت فعال بودن NAK ارسال می‌شود).
"authoritative": false,
// نام bootfile سراسری برای تنظیم در فیلد 'file'.
"boot-file-name": "/dev/null",
// فهرست مرتب‌شده‌ای از کلاس‌های کلاینت مورد استفاده کارگزار DHCPv4.
"client-classes": [
{
// نام bootfile ویژه کلاس برای تنظیم در فیلد 'file'.
"boot-file-name": "/usr/local/share/kea/bootfile.efi",
// نام کلاس.
"name": "phones_server1",
// آدرس کارگزار بعدی ویژه کلاس برای استفاده در راه‌اندازی اولیه (bootstrap)، که
// در فیلد 'siaddr' تنظیم می‌شود.
"next-server": "10.2.3.4",
// فهرست گزینه‌های DHCPv4 ویژه کلاس.
"option-data": [],
// تعاریف گزینه‌های DHCPv4 ویژه کلاس، یعنی قالب‌های سفارشی
// مشخص‌شده برای گزینه‌های غیر استاندارد.
"option-def": [],
// نام میزبان اختیاری کارگزار ویژه کلاس، که در فیلد
// 'sname' تنظیم می‌شود.
"server-hostname": "",
// عبارت انتخاب کلاس. هنگامی که عبارت ارائه‌شده true ارزیابی شود،
// بسته DHCP به این کلاس اختصاص می‌یابد.
"test": "member('HA_server1')",
// طول‌عمر معتبر کلاس.
"valid-lifetime": 6000,
// حداقل طول‌عمر معتبر کلاس.
"min-valid-lifetime": 4000,
// حداکثر طول‌عمر معتبر کلاس.
"max-valid-lifetime": 8000,
// اگر بزرگ‌تر از صفر باشد، طول‌عمر اجاره‌هایی است که موقتاً در
// مرحله DISCOVER تخصیص می‌یابند. در صورت صفر بودن (پیش‌فرض)، در DISCOVER اجاره‌ای تخصیص داده نمی‌شود.
"offer-lifetime" : 65
},
{
// مقدار پیش‌فرض نام bootfile ویژه کلاس. یک نام خالی به این
// معنی است که نام bootfile مشخص نشده است.
"boot-file-name": "",
// نام کلاس دوم.
"name": "phones_server2",
// مقدار پیش‌فرض آدرس کارگزار بعدی ویژه کلاس. آدرس
// صفر IPv4 به این معنی است که مشخص نشده است.
"next-server": "0.0.0.0",
// فهرست گزینه‌های DHCPv4 ویژه کلاس.
"option-data": [],
// تعاریف گزینه‌های DHCPv4 ویژه کلاس، یعنی قالب‌های سفارشی
// مشخص‌شده برای گزینه‌های غیر استاندارد.
"option-def": [],
// نام میزبان اختیاری کارگزار ویژه کلاس، که در فیلد
// 'sname' تنظیم می‌شود.
"server-hostname": "",
// عبارت انتخاب کلاس. هنگامی که عبارت ارائه‌شده true ارزیابی شود،
// بسته DHCP به این کلاس اختصاص می‌یابد.
"test": "member('HA_server2')"
},
{
// نام کلاس سوم.
"name": "late",
// پرچم بولی که مشخص می‌کند آیا عبارت کلاس تنها زمانی ارزیابی شود
// که پیکربندی انتخاب‌شده (یعنی pool، subnet، shared-network)
// شامل این نام کلاس در فهرست "evaluate-additional-classes" خود باشد. مقدار
// پیش‌فرض false به این معنی است که عبارت آزمون کلاس باید
// همیشه ارزیابی شود.
"only-in-additional-list": true,
// عبارت انتخاب کلاس.
"test": "member('ALL')"
},
{
// نام کلاس چهارم.
"name": "my-template-class",
// پرچم کلاس الگو که حاوی عبارت مورد استفاده برای تولید نام‌ها برای تمام
// زیرکلاس‌های ایجادشده است. در این حالت، کلاس‌ها بر اساس شناسه کلاینت (client ID) نام‌گذاری می‌شوند.
"template-test": "substring(option[61].hex, 0, all)"
}
],
// پارامترهایی برای فعال‌سازی رفتارهای سازگار با کلاینت‌ها، رله‌ها،
// یا سایر کارگزاران معیوب یا ناسازگار با استاندارد
"compatibility": {
// نادیده گرفتن گزینه شناسه کارگزار DHCP در صورت تنظیم روی true.
// فعال کردن این گزینه باعث می‌شود Kea به جای رها کردن پرس‌وجو، هر
// درخواستی را حتی اگر آدرس موجود در گزینه متعلق به کارگزار دیگری
// باشد، بپذیرد. پیش‌فرض این گزینه پیکربندی false است،
// زیرا فعال کردن آن سازگاری با RFC را نقض می‌کند.
"ignore-dhcp-server-identifier": false,
// نادیده گرفتن زیرگزینه Link Selection در Relay Agent Information در صورت تنظیم
// روی true. فعال کردن این گزینه باعث می‌شود Kea به جای تلاش برای استفاده از زیرشبکه
// مشخص‌شده در زیرگزینه، از منطق معمول انتخاب زیرشبکه استفاده کند. این گزینه پیکربندی
// به‌طور پیش‌فرض false است، زیرا فعال کردن آن سازگاری با RFC را نقض می‌کند.
"ignore-rai-link-selection": false,
// تجزیه ملایم‌تر گزینه‌ها در مواردی که فیلدها را می‌توان به صورت
// قطعی استنتاج کرد، حتی اگر برخلاف RFC یا رویه معمول باشد.
"lenient-option-parsing": true,
// پرچم بولی که مشخص می‌کند آیا آدرس‌های 0. و 255. باید در زیرشبکه‌هایی با طول پیشوند
// ۲۴ یا کمتر، همیشه غیرقابل‌دسترس و اشغال‌شده در نظر گرفته شوند یا خیر. پیش‌فرض false است،
// زیرا این آدرس‌ها خاص نیستند؛ تنها اولین و آخرین آدرس‌ها خاص هستند.
"exclude-first-last-24": false
},
// پارامترهای پیکربندی سوکت کنترل فرمان برای کارگزار Kea DHCPv4.
"control-sockets": [
{
// نوع سوکت کنترل مورد استفاده توسط کارگزار Kea DHCPv4.
// باید unix، http یا https باشد.
"socket-type": "unix",
// مکان فایل سوکت دامنه یونیکس (UNIX domain socket) که کارگزار DHCPv4
// برای دریافت فرمان‌های کنترلی از مدیر محلی سرور استفاده می‌کند.
"socket-name": "kea4-ctrl-socket"
},
{
// نوع سوکت کنترل مورد استفاده توسط کارگزار Kea DHCPv4.
// باید unix، http یا https باشد.
"socket-type": "https",
// آدرس سوکت HTTPS که کارگزار Kea DHCPv4 باید برای پرس‌وجوهای
// ورودی روی آن گوش فرا دهد.
"socket-address": "127.0.0.1",
// درگاه سوکت HTTPS که کارگزار Kea DHCPv4 باید برای پرس‌وجوهای
// ورودی روی آن گوش فرا دهد. در صورت فعال‌سازی HA و چندنخی،
// درگاه 8000 توسط شنونده http کتابخانه قلاب HA استفاده می‌شود.
// هنگام استفاده از کتابخانه قلاب HA همراه با چندنخی، مطمئن شوید
// درگاهی که توسط شنونده اختصاصی استفاده می‌شود با درگاه مشخص‌شده
// در اینجا متفاوت باشد (مثلاً 8001). توجه داشته باشید که
// فرمان‌ها همچنان باید به سوکت کنترل ارسال شوند.
// شنونده اختصاصی صرفاً برای به‌روزرسانی‌های HA است.
"socket-port": 8004,
// لنگر اعتماد TLS (مرجع صدور گواهی یا CA). این یک
// نام فایل یا مسیر دایرکتوری است. همراه با سایر پارامترهای
// TLS تنها برای نوع سوکت کنترل https کاربرد دارد.
"trust-anchor": "my-ca",
// نام فایل گواهی سرور TLS.
"cert-file": "my-cert",
// نام فایل کلید خصوصی سرور TLS.
"key-file": "my-key",
// پرچم الزام گواهی‌های کلاینت TLS. پیش‌فرض true
// است و به معنای الزام گواهی‌های کلاینت است. مقدار false
// یعنی اختیاری هستند.
"cert-required": true,
// سرایندهای HTTP اضافی برای افزودن به پاسخ‌ها.
"http-headers":
[
{
// بافت کاربری (user context) اختیاری.
"user-context": { "comment": "HSTS header" },
// نام الزامی سرایند HTTP.
"name": "Strict-Transport-Security",
// مقدار الزامی سرایند HTTP.
"value": "max-age=31536000"
}
],
// احراز هویت اختیاری.
"authentication": {
// نوع الزامی احراز هویت. تنها مقدار
// پشتیبانی‌شده basic برای احراز هویت
// پایه HTTP است.
"type": "basic",
// یک پارامتر اختیاری قلمرو (realm) احراز هویت
// پایه HTTP است. پیش‌فرض آن
// "kea-dhcpv4-server" است.
"realm": "kea-dhcpv4-server",
// این پارامتر اختیاری می‌تواند برای تعیین یک پیشوند
// مشترک برای فایل‌های حاوی اطلاعات اعتباری کلاینت استفاده شود.
"directory": "/usr/local/share/kea/kea-creds",
// این فهرست شناسه‌های کاربری و گذرواژه‌های مورد استفاده برای
// احراز هویت پایه HTTP را مشخص می‌کند. در صورت خالی بودن
// یا عدم وجود، هر کلاینتی مجاز شمرده می‌شود.
"clients": [
// این بخش یک کلاینت مجاز را مشخص می‌کند.
{
// شناسه کاربری نباید خالی باشد یا
// حاوی نویسه ':' باشد. این یک
// پارامتر اجباری است.
"user": "admin",
// در صورت عدم تعیین گذرواژه، از یک گذرواژه
// خالی استفاده می‌شود.
"password": "1234"
},
// این بخش یک کلاینت مخفی را مشخص می‌کند.
{
// شناسه کاربری محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenu است.
"user-file": "hiddenu",
// گذرواژه محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenp است.
"password-file": "hiddenp"
},
// این بخش یک کلاینت مخفی را با استفاده از
// یک راز در یک فایل مشخص می‌کند.
{
// راز محتوای فایل
// /usr/local/share/kea/kea-creds/hiddens است که باید در
// قالب <user-id>:<password> باشد.
"password-file": "hiddens"
}
]
}
}
],
// پیشوندی را مشخص می‌کند که باید به FQDN تولیدشده کلاینت اضافه شود.
// ممکن است در سطوح سراسری، shared-network و زیرشبکه مشخص شود.
"ddns-generated-prefix": "myhost",
// پرچم بولی که مشخص می‌کند آیا سرور باید تمایل کلاینت DHCP برای
// به‌روزرسانی DNS توسط خودش را نادیده بگیرد یا خیر. با تنظیم این پرچم روی true،
// سرور به‌روزرسانی‌های DNS را برای هر دو داده مستقیم و
// معکوس DNS ارسال خواهد کرد. مقدار پیش‌فرض false است که نشان می‌دهد
// سرور در صورت درخواست، به‌روزرسانی DNS را به کلاینت واگذار
// خواهد کرد. این گزینه می‌تواند در سطوح سراسری، shared-network،
// و زیرشبکه مشخص شود.
"ddns-override-client-update": false,
// پرچم بولی که مشخص می‌کند آیا سرور باید تمایل کلاینت DHCP
// مبنی بر عدم به‌روزرسانی DNS را نادیده بگیرد یا خیر. با تنظیم این پارامتر
// روی true، سرور حتی در صورتی که کلاینت عدم به‌روزرسانی را درخواست کرده باشد،
// یک به‌روزرسانی DNS ارسال خواهد کرد. این گزینه می‌تواند در سطوح
// سراسری، shared-network و زیرشبکه مشخص شود.
"ddns-override-no-update": false,
// پسوندی که به نام جزئی ارسال‌شده به DNS پیوست می‌شود. مقدار
// پیش‌فرض یک رشته خالی است که نشان می‌دهد هیچ پسوندی
// پیوست نمی‌شود. این گزینه می‌تواند در سطوح سراسری،
// shared-network و زیرشبکه مشخص شود.
"ddns-qualifying-suffix": "",
// شمارشی که مشخص می‌کند آیا سرور باید نام میزبان یا FQDN کلاینت
// ارسال‌شده توسط کلاینت را رعایت کند یا این نام را جایگزین نماید.
// مقادیر پذیرفتنی عبارتند از: "never" (استفاده از نامی که
// کلاینت ارسال کرده)، "always" (جایگزینی نام ارسال‌شده توسط
// کلاینت)، "when-present" (جایگزینی نام ارسالی کلاینت،
// اما عدم تولید نام در صورتی که کلاینت نامی ارسال نکرده باشد)،
// "when-not-present" (تولید نام زمانی که کلاینت نامی ارسال
// نکرده باشد، در غیر این صورت حفظ نام ارسال‌شده توسط کلاینت).
// مقدار پیش‌فرض "never" است. این گزینه می‌تواند در سطوح
// سراسری، shared-network و زیرشبکه مشخص شود.
"ddns-replace-client-name": "never",
// پرچم بولی که به‌روزرسانی DDNS را فعال یا غیرفعال می‌کند. مقدار
// پیش‌فرض آن true است. این گزینه می‌تواند در سطوح سراسری، shared-
// network و زیرشبکه مشخص شود. این گزینه همراه با
// dhcp-ddns:enable-updates عمل می‌کند که برای فعال‌سازی اتصال
// به kea-dhcp-ddns باید true باشد.
"ddns-send-updates": true,
// پرچم بولی که وقتی true باشد، به سرور دستور می‌دهد همیشه
// هنگام تمدید اجاره‌ها، حتی اگر اطلاعات DNS تغییری نکرده باشد،
// DNS را به‌روزرسانی کند. رفتار پیش‌فرض سرور (یعنی وقتی پرچم false است)
// این است که فقط در صورت تغییر اطلاعات DNS، آن را به‌روزرسانی کند. این گزینه
// می‌تواند در سطوح سراسری، shared-network و زیرشبکه مشخص شود.
"ddns-update-on-renew": true,
// پرچم بولی که با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns ارسال
// می‌شود تا مشخص کند آیا حل تعارض به‌روزرسانی DNS مطابق آنچه در
// RFC 4703 شرح داده شده باید برای درخواست به‌روزرسانی داده‌شده به کار رود
// یا خیر. مقدار پیش‌فرض این پرچم true است. این گزینه می‌تواند در سطوح
// سراسری، shared-network و زیرشبکه مشخص شود.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیه این گزینه تنها برای سازگاری با نسخه‌های پیشین حفظ شده است.
// "ddns-use-conflict-resolution": true,
// شمارشی که با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns
// ارسال می‌شود تا حالت مورد استفاده برای حل تعارض‌ها هنگام انجام
// به‌روزرسانی‌های DDNS را مشخص کند. مقادیر پذیرفتنی عبارتند از:
// check-with-dhcid (شامل افزودن رکورد DHCID و بررسی آن رکورد
// از طریق تشخیص تعارض مطابق با RFC 4703)،
// no-check-with-dhcid (تشخیص تعارض را نادیده می‌گیرد اما هنگام
// ایجاد/به‌روزرسانی یک مدخل، یک رکورد DHCID می‌افزاید)،
// check-exists-with-dhcid (بررسی می‌کند که آیا رکورد DHCID موجود است
// یا خیر اما تطابق مقدار رکورد با به‌روزرسانی را تأیید نمی‌کند.
// همچنین رکورد DHCID را برای مدخل به‌روزرسانی می‌کند)،
// no-check-without-dhcid (تشخیص تعارض را نادیده می‌گیرد و هنگام
// ایجاد/به‌روزرسانی یک مدخل DDNS هیچ رکورد DHCID اضافه نمی‌کند).
// مقدار پیش‌فرض "check-with-dhcid" است. این گزینه می‌تواند در
// سطوح سراسری، shared-network و زیرشبکه مشخص شود.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// هنگامی که بزرگ‌تر از 0.0 باشد، درصدی از طول‌عمر اجاره است
// که برای DNS TTL استفاده می‌شود.
"ddns-ttl-percent": 0.75,
// هنگامی که بزرگ‌تر از 0 باشد، به عنوان DNS TTL استفاده خواهد شد. بر حسب ثانیه مشخص می‌شود.
// نمی‌توانید هر دو ddns-ttl و هر یک از گزینه‌های ddns-ttl-percent ،ddns-ttl-min یا
// ddns-ttl-max را با هم مشخص کنید. این موارد مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// هنگامی که بزرگ‌تر از 0 باشد، به عنوان حد پایین مقادیر محاسبه‌شده DNS TTL استفاده می‌شود.
// بر حسب ثانیه مشخص می‌شود.
"ddns-ttl-min": 24000,
// هنگامی که بزرگ‌تر از 0 باشد، به عنوان حد بالای مقادیر محاسبه‌شده DNS TTL استفاده می‌شود.
// بر حسب ثانیه مشخص می‌شود.
"ddns-ttl-max": 64000,
// زمان بر حسب ثانیه که مشخص می‌کند یک اجاره ردشده (declined) چه مدت باید
// از تخصیص‌های DHCP کنار گذاشته شود. مقدار پیش‌فرض 86400 (۲۴ ساعت) است.
"decline-probation-period": 86400,
// پیکربندی هدایت درخواست تغییر نام (NCR) برای کارگزار Kea DHCPv4.
// درخواست‌های NCR به ماژول Kea D2 ارسال می‌شوند تا پس از تخصیص
// اجاره‌های DHCP، سیستم DNS را به‌روزرسانی کند.
"dhcp-ddns": {
// پرچم بولی که مشخص می‌کند آیا کارگزار Kea DHCPv4 باید به
// kea-dhcp-ddns متصل شود یا خیر. این گزینه باید true باشد تا NCRها
// ایجاد شده و به kea-dhcp-ddns ارسال شوند. به‌طور پیش‌فرض، NCRها تولید نمی‌شوند.
"enable-updates": false,
// حداکثر تعداد NCRهایی را که در صف در انتظار ارسال
// به کارگزار Kea D2 قرار می‌گیرند مشخص می‌کند.
"max-queue-size": 1024,
// قالب بسته برای استفاده هنگام ارسال NCRها به کارگزار Kea D2.
// در حال حاضر، تنها قالب JSON پشتیبانی می‌شود.
"ncr-format": "JSON",
// پروتکل سوکت برای استفاده هنگام ارسال NCRها به D2. در حال حاضر،
// تنها UDP پشتیبانی می‌شود.
"ncr-protocol": "UDP",
// آدرس IP که کارگزار Kea DHCPv4 باید برای ارسال NCRها به D2
// از آن استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید یک آدرس مناسب را انتخاب کند.
"sender-ip": "0.0.0.0",
// شماره درگاهی که کارگزار Kea DHCPv4 باید برای ارسال NCRها
// به D2 از آن استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید یک درگاه مناسب را انتخاب کند.
"sender-port": 0,
// آدرس IP که D2 روی آن به NCRها گوش فرا می‌دهد.
"server-ip": "127.0.0.1",
// شماره درگاهی که D2 روی آن به NCRها گوش فرا می‌دهد.
"server-port": 53001
},
// اولین درگاه از دو درگاه متوالی سوکت‌های UDP مورد استفاده
// برای ارتباط بین کارگزارهای DHCPv6 و DHCPv4 را مشخص می‌کند.
// به RFC 7341 مراجعه کنید. (پیش‌فرض 0 - غیرفعال).
// در صورت فعال بودن، مثلاً از 786 استفاده کنید.
"dhcp4o6-port": 0,
// پرچم بولی که مشخص می‌کند آیا کارگزار Kea DHCPv4
// باید گزینه Client Identifier را در پاسخ‌های خود بازپس بفرستد یا خیر.
// مقدار پیش‌فرض true است که نشان می‌دهد در صورت قرار داشتن گزینه
// در درخواست کلاینت، باید بازگردانده شود. مقدار false
// به کارگزار دستور می‌دهد که برای سازگاری با مشخصات قدیمی‌تر
// DHCP که بیان می‌کردند Client Identifier نباید بازگردانده شود، این گزینه را ارسال نکند.
"echo-client-id": true,
// مجموعه‌ای از پارامترهای کارگزار Kea DHCPv4 که نحوه پردازش
// اجاره‌های منقضی‌شده DHCP توسط کارگزار را پیکربندی می‌کند.
"expired-leases-processing": {
// تعداد ثانیه‌ها از آخرین حذف اجاره‌های منقضی‌شده را مشخص می‌کند
// که پس از آن حذف بعدی باید رخ دهد.
// اگر هر دو گزینه "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" صفر نباشند، هنگامی که کلاینت پیام release
// ارسال می‌کند، اجاره به جای حذف شدن از حافظه اجاره‌ها،
// منقضی می‌شود.
"flush-reclaimed-timer-wait-time": 25,
// مدت‌زمان بر حسب ثانیه را برای نگهداری اجاره‌های منقضی‌شده
// در پایگاه‌داده اجاره‌ها مشخص می‌کند (وابستگی اجاره یا lease affinity).
// اگر هر دو گزینه "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" صفر نباشند، هنگامی که کلاینت پیام release
// ارسال می‌کند، اجاره به جای حذف شدن از حافظه اجاره‌ها،
// منقضی می‌شود.
"hold-reclaimed-time": 3600,
// حداکثر تعداد اجاره‌های منقضی‌شده‌ای را مشخص می‌کند که می‌توانند
// در یک تلاش برای پاک‌سازی اجاره‌های منقضی‌شده از پایگاه‌داده
// اجاره‌ها پردازش شوند. اگر اجاره‌های منقضی‌شده بیشتری وجود داشته
// باشد، در طول تلاش بعدی پاک‌سازی پردازش خواهند شد.
"max-reclaim-leases": 100,
// حداکثر زمان بر حسب میلی‌ثانیه را که یک تلاش برای پاک‌سازی
// اجاره‌های منقضی‌شده از پایگاه‌داده اجاره‌ها ممکن است طول بکشد، مشخص می‌کند.
"max-reclaim-time": 250,
// مدت‌زمان بر حسب ثانیه از آخرین تلاش برای پردازش اجاره‌های
// منقضی‌شده پیش از آغاز تلاش بعدی را مشخص می‌کند.
"reclaim-timer-wait-time": 10,
// حداکثر تعداد چرخه‌های پردازش اجاره‌های منقضی‌شده را مشخص می‌کند
// که منجر به پاک‌سازی کامل اجاره‌های منقضی‌شده از پایگاه‌داده اجاره‌ها
// نشده‌اند، که پس از آن یک پیام هشدار صادر می‌شود.
"unwarned-reclaim-cycles": 5
},
// فهرست کتابخانه‌های قلاب و پارامترهای پیکربندی اختصاصی آن‌ها
// که باید توسط کارگزار Kea DHCPv4 بارگذاری شوند.
"hooks-libraries": [
{
// مکان کتابخانه قلاب برای بارگذاری.
"library": "libdhcp_lease_cmds.so",
// پارامترهای پیکربندی اختصاصی کتابخانه قلاب.
"parameters": { }
},
{
// کتابخانه قلاب بک‌اند میزبان MySQL مورد نیاز برای ذخیره‌سازی میزبان.
"library": "libdhcp_mysql.so"
},
{
// کتابخانه قلاب بک‌اند میزبان PostgreSQL مورد نیاز برای ذخیره‌سازی میزبان.
"library": "libdhcp_pgsql.so"
}
],
// فهرست اطلاعات اعتباری دسترسی به منابع خارجی رزروهای IPv4،
"hosts-databases": [
{
// نام پایگاه‌داده برای اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژه پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 3306,
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "mysql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// حالت فقط‌خواندنی.
"readonly": false,
// مدخل‌های بعدی برای پشتیبانی از OpenSSL در MySQL هستند.
// لنگر اعتماد (trust anchor) یا همان فایل یا دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// فهرست الگوریتم‌های رمزنگاری (راهنمای دستور ciphers در OpenSSL را ببینید).
"cipher-list": "AES",
// زمان انتظار برای اتصال مجدد.
// این پارامتر تعیین می‌کند که Kea چه مدت قبل از تلاش مجدد برای
// اتصال منتظر بماند. بر حسب میلی‌ثانیه بیان می‌شود. مقدار پیش‌فرض 0
// (غیرفعال) برای MySQL و PostgreSQL است.
"reconnect-wait-time": 3000,
// حداکثر دفعات تلاش برای اتصال مجدد.
"max-reconnect-tries": 3,
// اقدامی که در صورت شکست بازیابی اتصال باید انجام شود.
// مقادیر پشتیبانی‌شده: stop-retry-exit، serve-retry-exit،
// serve-retry-continue
"on-fail": "stop-retry-exit",
// پرچمی که مشخص می‌کند آیا بازیابی پایگاه‌داده باید در هنگام راه‌اندازی
// کارگزار و رویدادهای بازپیکربندی مورد تلاش قرار گیرد یا خیر.
"retry-on-startup": false,
// مهلت زمانی برقراری اتصال به ثانیه.
"connect-timeout": 100,
// مهلت زمانی عملیات خواندن پایگاه‌داده به ثانیه.
"read-timeout": 120,
// مهلت زمانی عملیات نوشتن پایگاه‌داده به ثانیه.
"write-timeout": 180
},
{
// نام پایگاه‌داده برای اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژه پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 5432,
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "postgresql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// مهلت زمانی TCP کاربر هنگام ارتباط با پایگاه‌داده.
// بر حسب ثانیه مشخص می‌شود.
"tcp-user-timeout": 100,
// لنگر اعتماد (trust anchor) یا همان فایل یا دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// حالت SSL.
"ssl-mode": "verify-ca"
}
],
// فهرست انواع شناسه‌های رزرو میزبان که توسط کارگزار
// Kea DHCPv4 برای واکشی رزروهای ایستا برای کلاینت‌های
// DHCP استفاده می‌شود. به‌طور پیش‌فرض همه شناسه‌ها استفاده می‌شوند،
// به این معنی که کارگزار چندین پرس‌وجو به پایگاه‌داده ارسال می‌کند تا
// مشخص شود آیا رزروی برای یک کلاینت خاص وجود دارد یا خیر. اگر
// یک استقرار خاص تنها از یک زیرمجموعه استفاده می‌کند، مثلاً یک نوع شناسه،
// تنها آن شناسه باید در اینجا فهرست شود تا از پرس‌وجوهای
// غیرضروری به پایگاه‌داده جلوگیری شود.
"host-reservation-identifiers": [
"hw-address",
"duid",
"circuit-id",
"client-id",
"flex-id"
],
// پیکربندی رابط‌هایی را مشخص می‌کند که کارگزار Kea DHCPv4
// روی آن‌ها به پرس‌وجوهای DHCP گوش فرا می‌دهد.
"interfaces-config": {
// مشخص می‌کند که آیا سرور باید از سوکت‌های "udp" یا
// سوکت‌های "raw" برای گوش دادن به ترافیک DHCP استفاده کند. سوکت‌های
// "raw" زمانی مفید هستند که ترافیک مستقیم DHCP در حال
// دریافت باشد.
"dhcp-socket-type": "udp",
// فهرستی از رابط‌ها را مشخص می‌کند که کارگزار Kea DHCPv4
// باید روی آن‌ها به درخواست‌های DHCP گوش فرا دهد.
"interfaces": [
"eth0"
],
// شمارشی که مشخص می‌کند چه رابطی باید برای ارسال
// پاسخ‌های DHCP به کلاینت استفاده شود. مقدار پیش‌فرض
// "same-as-inbound" است که نشان می‌دهد پاسخ باید از طریق
// رابطی که پرس‌وجوی کلاینت روی آن دریافت شده ارسال شود.
// مقدار "use-routing" نشان می‌دهد که کارگزار Kea باید از جدول
// مسیریابی هسته برای یافتن یک رابط مناسب استفاده کند.
"outbound-interface": "same-as-inbound",
// پرچم بولی که مشخص می‌کند آیا رابط‌های موجود باید در هنگام
// بازپیکربندی کارگزار مجدداً شناسایی شوند یا خیر. مقدار پیش‌فرض
// true است که به این معنی است رابط‌ها همیشه مجدداً
// شناسایی می‌شوند.
"re-detect": true,
// Kea سعی می‌کند در حین مقداردهی اولیه به سوکت‌های سرویس متصل (bind) شود، اما ممکن
// است به دلیل باز بودن قبلی درگاه یا پیکربندی نادرست شکست بخورد. Kea می‌تواند
// این خطاها را نادیده گرفته و فقط آن‌ها را ثبت کند. این پرچم از شروع به کار
// کارگزار DHCP بدون اتصال همه سوکت‌ها جلوگیری می‌کند. در صورت عدم تعیین،
// مقدار پیش‌فرض آن false است.
"service-sockets-require-all": true,
// Kea سعی می‌کند در حین مقداردهی اولیه به سوکت‌های سرویس متصل شود. این
// گزینه مشخص می‌کند که چند بار تلاش مجدد برای اتصال به رابط انجام خواهد شد.
// مقدار پیش‌فرض 0 است، به این معنی که عملیات تکرار نخواهد شد.
"service-sockets-max-retries": 5,
// بازه زمانی بر حسب میلی‌ثانیه برای انتظار قبل از تلاش بعدی
// برای باز کردن مجدد سوکت سرویس.
"service-sockets-retry-wait-time": 5000
},
// پارامتر بولی که کنترل می‌کند آیا جستجوی زودهنگام رزروهای سراسری میزبان
// باید انجام شود یا خیر. این جستجو قبل از انتخاب زیرشبکه صورت می‌گیرد
// و هنگامی که یک رزرو سراسری با برخی کلاس‌های کلاینت یافت شود،
// مرحله دوم رده‌بندی را راه‌اندازی می‌کند. همچنین می‌تواند برای رها کردن
// پرس‌وجوها با استفاده از رزروهای میزبان به عنوان جدول تصمیم‌گیری
// نمایه‌شده با شناسه‌های رزرو به کار رود.
"early-global-reservations-lookup": true,
// پارامتر بولی که رفتار کارگزار DHCP را در رابطه با ایجاد رزروهای
// میزبان برای یک آدرس IP یکسان کنترل می‌کند. به‌طور پیش‌فرض
// این پرچم روی true تنظیم شده است که در این حالت سرور از ایجاد
// چندین رزرو میزبان برای یک آدرس IP یکسان جلوگیری می‌کند. هنگامی که
// این پارامتر روی false تنظیم شود، سرور اجازه ایجاد چندین رزرو
// برای یک آدرس IP یکسان را در یک زیرشبکه می‌دهد. این تنظیم در
// استقرارهایی مفید است که در آن‌ها یک میزبان ممکن است از طریق چندین رابط
// با کارگزار DHCP ارتباط برقرار کند و بسته به رابط انتخاب‌شده، یک آدرس MAC
// متفاوت (یا شناسه دیگر) برای شناسایی میزبان استفاده شود. توجه داشته باشید
// که برخی از بک‌اندهای میزبان از حالتی که چندین رزرو برای یک آدرس IP
// یکسان استفاده شود پشتیبانی نمی‌کنند. اگر این بک‌اندها در حال استفاده باشند
// و این تنظیم اعمال شود، یک خطای پیکربندی رخ خواهد داد. بک‌اندهای MySQL و
// PostgreSQL از این حالت پشتیبانی می‌کنند.
"ip-reservations-unique": true,
// پارامتر بولی که کنترل می‌کند آیا جستجوی رزروهای میزبان باید قبل از
// جستجوی اجاره انجام شود یا خیر. این پارامتر تنها زمانی تأثیر دارد که
// چندنخی غیرفعال باشد. هنگامی که چندنخی فعال باشد، جستجوی رزروهای
// میزبان همیشه ابتدا انجام می‌شود تا از قفل شدن منابع جستجوی اجاره
// جلوگیری شود.
"reservations-lookup-first": true,
// اطلاعات اعتباری برای دسترسی به پایگاه‌داده اجاره را مشخص می‌کند.
"lease-database": {
// پارامتر اختصاصی بک‌اند memfile که بازه زمانی بر حسب ثانیه را
// مشخص می‌کند که در آن فایل اجاره باید پاک‌سازی شود (مدخل‌های قدیمی
// اجاره حذف می‌شوند تا از رشد بی‌رویه فایل اجاره جلوگیری شود).
"lfc-interval": 3600,
// حداکثر تعداد خطاهای خواندن فایل اجاره مجاز قبل از این که
// بارگذاری فایل متوقف شود. پیش‌فرض 0 است (بدون محدودیت).
"max-row-errors": 100,
// نام فایل اجاره. در مورد پایگاه‌داده، نام پایگاه‌داده را
// مشخص می‌کند.
"name": "kea-leases4.csv",
// پارامتر اختصاصی memfile که مشخص می‌کند آیا اجاره‌ها باید
// روی حافظه پایدار (دیسک) ذخیره شوند یا خیر. مقدار true
// پیش‌فرض است و نشان می‌دهد که اجاره‌ها در حافظه پایدار
// ذخیره می‌شوند. این تنظیم باید در محیط عملیاتی استفاده شود.
// مقدار false تنها باید برای اهداف آزمایشی استفاده شود
// زیرا اجاره‌های ذخیره‌نشده با راه‌اندازی مجدد سرور Kea از بین می‌روند.
"persist": true,
// نوع بک‌اند پایگاه‌داده اجاره، یعنی "memfile"، "mysql" یا
// "postgresql".
"type": "memfile"
},
// مقدار بولی که مشخص می‌کند آیا کارگزار Kea DHCPv4 باید از مقدار شناسه
// کلاینت ارسال‌شده توسط کلاینت استفاده کند یا آن را نادیده بگیرد. مقدار پیش‌فرض
// true است که نشان می‌دهد کارگزار باید از شناسه کلاینت استفاده کند
// و این شناسه بر آدرس MAC کلاینت ارجحیت دارد. در استقرارهایی که
// آدرس MAC باید ارجحیت داشته باشد، این مقدار می‌تواند روی false تنظیم شود
// که در این حالت کلاینت‌ها با آدرس MAC شناسایی می‌شوند.
// این ویژگی به‌ویژه زمانی مفید است که کلاینت‌ها شناسه‌های یکتا تولید نمی‌کنند
// یا این شناسه‌ها پایدار نیستند، و غیره.
"match-client-id": false,
// مقدار سراسری آدرس کارگزار بعدی تنظیم‌شده در فیلد 'siaddr'.
// مقدار سراسری ممکن است در محدوده‌های پیکربندی سطح پایین‌تر
// بازنویسی (override) شود.
"next-server": "192.0.2.123",
// مقدار سراسری که تعداد بسته‌های کلاینت (مانند DHCPREQUESTها) را محدود
// می‌کند که می‌توانند در انتظار اتمام کار کتابخانه قلاب، قبل از
// ارسال پاسخ (مانند DHCPACK) به کلاینت متوقف (پارک) شوند. یک مثال
// رایج زمانی است که kea-dhcp4 یک DHCPREQUEST را متوقف می‌کند در حالی که
// به‌روزرسانی(های) اجاره را به همتایان HA خود ارسال می‌نماید. بسته پس از
// تأیید به‌روزرسانی(ها) از حالت توقف خارج می‌شود. این مقدار، تعداد بسته‌هایی را
// که می‌توانند در انتظار به‌روزرسانی‌ها نگه‌داشته شوند محدود می‌کند. در زمان ترافیک
// سنگین کلاینت‌ها، این مقدار می‌تواند مانع از تجمع بیش از حد به‌روزرسانی‌ها در kea-dhcp4 شود.
"parked-packet-limit": 256,
// فهرست گزینه‌های سراسری DHCP که کارگزار Kea DHCPv4 به
// کلاینت‌ها اختصاص می‌دهد.
"option-data": [
{
// پرچم بولی که مشخص می‌کند آیا گزینه داده‌شده همیشه
// در پاسخ ارسال شود یا تنها در صورت درخواست. مقدار
// پیش‌فرض false نشان می‌دهد که تنها در صورت درخواست
// ارسال می‌شود.
"always-send": false,
// یک فهرست اختیاری از کلاس‌هایی که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه صرف‌نظر از عضویت در کلاس اعمال خواهد شد.
"client-classes": [ "class1", "class2" ],
// کد گزینه. در صورت ارائه نام گزینه، الزامی نیست.
"code": 6,
// مقدار بولی که مشخص می‌کند آیا داده گزینه مشخص‌شده
// در فیلد "data" به صورت رشته‌ای از ارقام هگزادسیمال
// مشخص شده است یا در قالب CSV خوانا برای انسان.
"csv-format": true,
// داده گزینه برای ذخیره در بار مفید (payload) گزینه.
"data": "192.0.3.1, 192.0.3.2",
// نام گزینه. در صورت ارائه کد گزینه، الزامی نیست.
"name": "domain-name-servers",
// پرچم بولی که مشخص می‌کند آیا گزینه داده‌شده هرگز
// در پاسخ ارسال نشود. مقدار پیش‌فرض false نشان می‌دهد
// که در مواقع لزوم ارسال می‌شود. هنگامی که true باشد،
// گزینه بدون توجه به هر تنظیم دیگری ارسال نمی‌شود، یعنی
// یک پرچم قطعی و نهایی است.
"never-send": false,
// فضای گزینه. پیش‌فرض فضای گزینه "dhcp4" است که
// گزینه‌های سطح بالای DHCPv4 را گروه‌بندی می‌کند.
"space": "dhcp4"
}
],
// فهرست تعاریف گزینه‌های سراسری، یعنی قالب‌های گزینه، که کارگزار
// Kea DHCPv4 از آن‌ها استفاده می‌کند.
"option-def": [
{
// پرچم بولی که مشخص می‌کند آیا تعریف گزینه شامل
// آرایه‌ای از مقادیر از یک نوع است، مثلاً آرایه‌ای از آدرس‌های IPv4.
// مقدار پیش‌فرض false به این معنی است که گزینه شامل
// آرایه‌ای از مقادیر نیست.
"array": false,
// کد گزینه.
"code": 6,
// نام فضای گزینه‌ای را نگهداری می‌کند که توسط این گزینه کپسوله شده است.
// تمام گزینه‌های متعلق به این فضای گزینه به عنوان زیرگزینه‌های
// این گزینه ارسال خواهند شد. یک رشته خالی به این معنی است که این
// گزینه هیچ گزینه‌ای را کپسوله نمی‌کند.
"encapsulate": "",
// نام گزینه.
"name": "my-option",
// انواع فیلدهای درون گزینه را در صورتی که گزینه یک "record"
// باشد مشخص می‌کند ("type" را ببینید). در این مثال خاص،
// این گزینه شامل دو فیلد با طول‌های ۱ بایت و ۲ بایت است.
"record-types": "uint8, uint16",
// نام فضای گزینه‌ای که این گزینه به آن تعلق دارد.
"space": "my-space",
// نوع گزینه. تمام انواع ممکن در راهنمای مرجع
// مدیر سیستم Kea فهرست شده‌اند.
"type": "record"
}
],
// مقدار سراسری برای تایمر rebind، یعنی زمانی که کلاینت
// DHCP پس از آن در صورت عدم موفقیت در تمدید اجاره، وارد حالت rebind می‌شود.
"rebind-timer": 40,
// مقدار سراسری برای تایمر renew، یعنی زمانی که کلاینت
// DHCP پس از آن اجاره را تمدید می‌کند.
"renew-timer": 30,
// مقدار سراسری برای ذخیره اطلاعات گسترش‌یافته (مانند اطلاعات
// عامل رله) همراه با هر اجاره.
"store-extended-info": true,
// آمارها تعدادی نمونه به ازای هر نقطه مشاهده نگهداری می‌کنند.
// دو مقدار پیش‌فرض وجود دارد: حداکثر تعداد و حداکثر طول‌عمر.
// تنظیم حداکثر تعداد روی صفر آن را غیرفعال می‌کند.
"statistic-default-sample-count": 0,
// هنگامی که حداکثر تعداد 0 باشد، حداکثر طول‌عمر (به ثانیه) اعمال می‌شود.
"statistic-default-sample-age": 60,
// پارامترهای چندنخی (Multi-threading).
"multi-threading": {
// به‌طور پیش‌فرض، Kea در صورت پشتیبانی سخت‌افزار، بسته‌ها را روی چندین نخ پردازش می‌کند.
"enable-multi-threading": true,
// هنگامی که چندنخی فعال باشد، Kea بسته‌ها را روی تعدادی
// از نخ‌ها پردازش می‌کند که از طریق این گزینه قابل پیکربندی است. مقدار
// باید یک عدد صحیح مثبت باشد (0 یعنی تشخیص خودکار).
"thread-pool-size": 0,
// هنگامی که چندنخی فعال باشد، Kea بسته‌ها را از رابط خوانده
// و یک آیتم کاری به مخزن نخ‌ها اضافه می‌کند. این گزینه
// حداکثر تعداد مواردی را که می‌توانند در صف قرار گیرند پیکربندی می‌کند.
// مقدار باید یک عدد صحیح مثبت باشد (0 یعنی نامحدود).
"packet-queue-size": 0
},
// نحوه برخورد کارگزار Kea DHCPv4 با داده‌های نامعتبر
// دریافت‌شده از کلاینت را تعیین می‌کند.
"sanity-checks": {
// مشخص می‌کند که کارگزار Kea DHCPv4 هنگام خواندن داده‌های
// نامعتبر برای یک اجاره از فایل اجاره چگونه باید رفتار کند. مقادیر
// زیر پشتیبانی می‌شوند: "none" (عدم تلاش برای تصحیح اطلاعات
// اجاره)، "warn" (چاپ هشدار برای ناسازگاری‌های مربوط به subnet-id)،
// "fix" (تصحیح شناسه زیرشبکه با تلاش برای یافتن زیرشبکه مناسب)،
// "fix-del" (مشابه "fix" اما در صورت عدم یافتن زیرشبکه مناسب،
// اجاره را حذف می‌کند)، "del" (در صورتی که اجاره مقدار شناسه
// زیرشبکه نامعتبر داشته باشد، آن را حذف می‌کند).
"lease-checks": "warn",
// مشخص می‌کند که کارگزار Kea DHCPv4 در هنگام خوانده شدن اطلاعات گسترش‌یافته
// نامعتبر برای یک اجاره از فایل اجاره، یا برای ارتقا از قالب قدیمی
// چگونه باید رفتار کند. مقادیر زیر پشتیبانی می‌شوند: "none" (عدم تلاش
// برای تصحیح یا ارتقای اطلاعات گسترش‌یافته)، "fix" (رفع ناسازگاری‌های
// رایج و ارتقا از قالب قدیمی؛ این مقدار پیش‌فرض است)، "strict"
// (رفع ناسازگاری‌های دارای تأثیر بر Leasequery)،
// "pedantic" (اعمال قالب کامل کد Kea).
"extended-info-checks": "fix"
},
// فهرست شبکه‌های مشترک مورد استفاده توسط کارگزار Kea DHCPv4. شبکه‌های
// مشترک زیرشبکه‌ها را با یکدیگر گروه‌بندی می‌کنند.
"shared-networks": [
{
// پرچمی برای انتخاب راهبرد تخصیص آدرس IP برای همه
// زیرشبکه‌ها در این شبکه مشترک.
"allocator": "random",
// پرچم معتبر بودن (authoritative) در سطح shared-network.
"authoritative": false,
// نام bootfile در سطح shared-network.
"boot-file-name": "/dev/null",
// این شبکه مشترک را محدود می‌کند تا تنها به کلاینت‌هایی
// اجازه دهد که حداقل به یک کلاس در این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-override-client-update": false,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-override-no-update": false,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-qualifying-suffix": "",
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-replace-client-name": "never",
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-send-updates": true,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-update-on-renew": true,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیه این گزینه تنها برای سازگاری با نسخه‌های پیشین حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-percent": 0.65,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
// نمی‌توانید هر دو ddns-ttl و هر یک از گزینه‌های ddns-ttl-percent ،ddns-ttl-min یا
// ddns-ttl-max را با هم مشخص کنید. این موارد مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-min": 10000,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-max": 20000,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// مشخص می‌کند که این شبکه مشترک برای درخواست‌های
// دریافت‌شده روی یک رابط خاص انتخاب شده است.
"interface": "eth0",
// پرچم در سطح shared-network که مشخص می‌کند آیا باید از
// شناسه کلاینت برای شناسایی کلاینت‌ها استفاده شود یا خیر.
"match-client-id": true,
// نام شبکه مشترک.
"name": "my-secret-network",
// تعیین کارگزار بعدی در سطح shared-network
// برای ارسال در 'siaddr'.
"next-server": "192.0.2.123",
// اگر بزرگ‌تر از صفر باشد، طول‌عمر اجاره‌هایی است که موقتاً در
// مرحله DISCOVER تخصیص داده می‌شوند. در صورت صفر بودن (پیش‌فرض)، در DISCOVER اجاره‌ای تخصیص داده نمی‌شود.
"offer-lifetime" : 60,
// فهرست گزینه‌های DHCP اختصاصی شبکه مشترک.
"option-data": [],
// فهرست آدرس‌های رله IPv4 که این شبکه مشترک
// برای آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": []
},
// تایمر rebind در سطح shared-network.
"rebind-timer": 41,
// تایمر renew در سطح shared-network.
"renew-timer": 31,
// محاسبه تایمرهای T1 و T2 در سطح shared-network.
"calculate-tee-times": true,
// T1 = طول‌عمر معتبر * ۰٫۵.
"t1-percent": .5,
// T2 = طول‌عمر معتبر * ۰٫۷۵.
"t2-percent": .75,
// آستانه کش = طول‌عمر معتبر * ۰٫۲۵.
"cache-threshold": .25,
// حداکثر کش: هنگامی که زمان آخرین ارسال کلاینت
// به اندازه کافی نزدیک باشد، اجاره تمدید نمی‌شود و اجاره
// فعلی همان‌طور که «کش شده» بود بازگردانده می‌شود.
"cache-max-age": 1000,
// آستانه زمان اجاره انطباقی (1.0 به معنای غیرفعال است).
"adaptive-lease-time-threshold": 0.8,
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند همه آدرس‌های رزروشده
// خارج از استخر (out-of-pool) هستند یا خیر.
// در صورت false بودن reservations-in-subnet نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "subnet4" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// فهرست کلاس‌های کلاینت که باید هنگام انتخاب این شبکه
// مشترک برای تخصیص‌های کلاینت ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// غیرفعال کردن ذخیره اطلاعات گسترش‌یافته (مانند اطلاعات عامل
// رله) همراه با هر اجاره برای این شبکه مشترک.
"store-extended-info": false,
// نام میزبان کارگزار در سطح shared-network تنظیم‌شده در فیلد 'sname'.
"server-hostname": "",
// فهرست زیرشبکه‌های IPv4 متعلق به این شبکه مشترک.
"subnet4": [
{
// نام رابط که با نام رابط ورودی مطابقت داده می‌شود.
// در DHCPv4o6 استفاده می‌شود. RFC 7341 را ببینید.
"4o6-interface": "",
// مقدار گزینه شناسه رابط (Interface ID). RFC 7341 را ببینید.
"4o6-interface-id": "",
// پیشوند مطابقت‌داده‌شده با آدرس مبدأ. RFC 7341 را ببینید.
"4o6-subnet": "2001:db8:1:1::/64",
// پرچمی برای انتخاب راهبرد تخصیص آدرس IP برای
// زیرشبکه.
"allocator": "iterative",
// پرچم معتبر بودن (authoritative) در سطح زیرشبکه.
"authoritative": false,
// نام bootfile در سطح زیرشبکه، تنظیم‌شده در فیلد 'file'.
"boot-file-name": "",
// این زیرشبکه را محدود می‌کند تا تنها به کلاینت‌هایی اجازه دهد
// که حداقل به یکی از کلاس‌های این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-override-client-update": false,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-override-no-update": false,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-qualifying-suffix": "",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-replace-client-name": "never",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-send-updates": true,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-update-on-renew": true,
// مقدار در سطح shared-network. توضیحات را در سطح سراسری ببینید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیه این گزینه تنها برای سازگاری با نسخه‌های پیشین حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// "ddns-ttl-percent": 0.55,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// نمی‌توانید هر دو ddns-ttl و هر یک از گزینه‌های ddns-ttl-percent ،ddns-ttl-min یا
// ddns-ttl-max را با هم مشخص کنید. این موارد مانعة‌الجمع هستند.
"ddns-ttl": 500,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// "ddns-ttl-min": 10000,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// "ddns-ttl-max": 20000,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// شناسه یکتای زیرشبکه.
"id": 1,
// مشخص می‌کند که این زیرشبکه برای درخواست‌های دریافت‌شده
// روی یک رابط خاص انتخاب شده است.
"interface": "eth0",
// پرچم در سطح زیرشبکه که مشخص می‌کند آیا باید از شناسه کلاینت
// برای شناسایی کلاینت‌ها استفاده شود یا خیر.
"match-client-id": true,
// تعیین کارگزار بعدی در سطح زیرشبکه برای ارسال
// در 'siaddr'.
"next-server": "0.0.0.0",
// اگر بزرگ‌تر از صفر باشد، طول‌عمر اجاره‌هایی است که موقتاً در
// مرحله DISCOVER تخصیص داده می‌شوند. در صورت صفر بودن (پیش‌فرض)، در DISCOVER اجاره‌ای تخصیص داده نمی‌شود.
"offer-lifetime" : 60,
// فعال کردن ذخیره اطلاعات گسترش‌یافته (مانند اطلاعات عامل
// رله) همراه با هر اجاره برای این زیرشبکه.
"store-extended-info": true,
// فهرست گزینه‌های DHCP در سطح زیرشبکه.
"option-data": [
{
// پرچم بولی که مشخص می‌کند آیا گزینه خاص
// باید همیشه ارسال شود یا تنها در صورت درخواست.
"always-send": false,
// یک فهرست اختیاری از کلاس‌هایی که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه صرف‌نظر از عضویت در کلاس اعمال خواهد شد.
"client-classes": [],
// کد گزینه.
"code": 3,
// پرچم بولی که مشخص می‌کند آیا مقدار گزینه تعیین‌شده
// در "data" رشته‌ای از مقادیر هگزادسیمال است یا مقدار
// CSV خوانا برای انسان.
"csv-format": true,
// داده گزینه برای گنجانده شدن در بار مفید گزینه.
"data": "192.0.3.1",
// نام گزینه.
"name": "routers",
// پرچم بولی که مشخص می‌کند آیا گزینه داده‌شده هرگز
// در پاسخ ارسال نشود.
"never-send": false,
// فضای گزینه. مقدار پیش‌فرض "dhcp4" فضای
// گزینه سطح بالا را مشخص می‌کند.
"space": "dhcp4"
}
],
// فهرست استخرهای آدرس IP متعلق به زیرشبکه.
"pools": [
{
// این استخر را محدود می‌کند تا تنها به کلاینت‌هایی
// اجازه دهد که حداقل به یک کلاس در این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server1" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدوده آدرس مورد استفاده برای تخصیص کلاینت.
"pool": "192.1.0.1 - 192.1.0.200",
// فهرست کلاس‌های کلاینت که باید هنگام انتخاب این استخر
// برای تخصیص‌های کلاینت ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-generated-prefix": "mypool",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-override-client-update": false,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-override-no-update": false,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-qualifying-suffix": "pool.example.com.",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-replace-client-name": "always",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-send-updates": true,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-update-on-renew": false,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-percent": 0.55,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
// نمی‌توانید هر دو ddns-ttl و هر یک از گزینه‌های ddns-ttl-percent ،ddns-ttl-min یا
// ddns-ttl-max را با هم مشخص کنید. این موارد مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-min": 10000,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-max": 20000,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]"
},
{
// این استخر را محدود می‌کند تا تنها به کلاینت‌هایی
// اجازه دهد که حداقل به یک کلاس در این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server2" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدوده آدرس مورد استفاده برای تخصیص کلاینت.
"pool": "192.3.0.1 - 192.3.0.200",
// فهرست کلاس‌های کلاینت که باید هنگام انتخاب این استخر
// برای تخصیص‌های کلاینت ارزیابی شوند.
"evaluate-additional-classes": [],
// شناسه استخر که برای فعال‌سازی آمارها برای این استخر استفاده می‌شود.
// شناسه استخر نیازی ندارد درون زیرشبکه
// یا در میان زیرشبکه‌ها یکتا باشد.
// در صورت عدم پیکربندی، پیش‌فرض آن 0 است. آمارهای
// مربوط به این استخر با سایر آمارهای
// تمام استخرهای دیگر با شناسه استخر یکسان در این زیرشبکه ترکیب خواهد شد.
"pool-id": 1
}
],
// مقدار تایمر rebind در سطح زیرشبکه.
"rebind-timer": 40,
// فهرست آدرس‌های رله IPv4 که این زیرشبکه برای آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": [
"192.168.56.1"
]
},
// مقدار تایمر renew در سطح زیرشبکه.
"renew-timer": 30,
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند همه آدرس‌های
// رزروشده خارج از استخر هستند یا خیر.
// در صورت false بودن reservations-in-subnet نادیده گرفته می‌شود.
"reservations-out-of-pool": false,
// محاسبه تایمرهای T1 و T2 در سطح زیرشبکه.
"calculate-tee-times": true,
// T1 = طول‌عمر معتبر * ۰٫۵.
"t1-percent": .5,
// T2 = طول‌عمر معتبر * ۰٫۷۵.
"t2-percent": .75,
// آستانه کش = طول‌عمر معتبر * ۰٫۲۵.
"cache-threshold": .25,
// حداکثر کش در سطح زیرشبکه.
"cache-max-age": 1000,
// آستانه زمان اجاره انطباقی (1.0 به معنای غیرفعال است).
"adaptive-lease-time-threshold": 0.8,
// فهرست رزروهای ایستا IPv4 اختصاص‌یافته به کلاینت‌های متعلق
// به این زیرشبکه. برای یک مثال با جزئیات کامل، reservations.json را ببینید.
"reservations": [
{
// شناسه مورد استفاده برای تطبیق کلاینت. مقادیر پشتیبانی‌شده عبارتند از
// "hw-address"، "client-id"، "duid"، "circuit-id"، "flex-id".
"circuit-id": "01:11:22:33:44:55:66",
// آدرس IP رزروشده.
"ip-address": "192.0.2.204",
// نام میزبان.
"hostname": "foo.example.org",
// داده گزینه اختصاصی رزرو.
"option-data": [
{
// نام گزینه.
"name": "vivso-suboptions",
// داده گزینه.
"data": "4491"
}
]
}
],
// فهرست کلاس‌های کلاینت که باید هنگام انتخاب این زیرشبکه
// برای تخصیص‌های کلاینت ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// نام میزبان کارگزار در سطح زیرشبکه تنظیم‌شده در فیلد 'sname'.
"server-hostname": "",
// پیشوند زیرشبکه.
"subnet": "192.0.0.0/8",
// طول‌عمر معتبر (پیش‌فرض) در سطح زیرشبکه.
"valid-lifetime": 6000,
// حداقل طول‌عمر معتبر در سطح زیرشبکه.
"min-valid-lifetime": 4000,
// حداکثر طول‌عمر معتبر در سطح زیرشبکه.
"max-valid-lifetime": 8000
}
],
// طول‌عمر معتبر (پیش‌فرض) در سطح shared-network.
"valid-lifetime": 6001,
// حداقل طول‌عمر معتبر در سطح shared-network.
"min-valid-lifetime": 4001,
// حداکثر طول‌عمر معتبر در سطح shared-network.
"max-valid-lifetime": 8001
}
],
// نام میزبان سراسری سرور تنظیم‌شده در فیلد 'sname'.
"server-hostname": "",
// ذخیره گزینه‌های عامل (یا RAI) تا پرس‌وجوهای مستقیم به گونه‌ای
// رفتار کنند که گویی از طریق یک رله وارد شده‌اند.
"stash-agent-options": false,
// فهرست زیرشبکه‌های IPv4 که به هیچ شبکه مشترکی تعلق ندارند.
"subnet4": [],
// مقدار طول‌عمر معتبر سراسری.
"valid-lifetime": 6000,
// مقدار حداقل طول‌عمر معتبر سراسری.
"min-valid-lifetime": 4000,
// مقدار حداکثر طول‌عمر معتبر سراسری.
"max-valid-lifetime": 8000,
// رزروها (مثال‌ها در فایل‌های دیگر آورده شده‌اند).
"reservations": [],
// کنترل پیکربندی (در حال حاضر استفاده نمی‌شود، یعنی این نحو
// از قبل تعریف شده است اما ویژگی مربوطه پیاده‌سازی نشده است).
"config-control": {
// تنها مدخل پایگاه‌داده‌های پیکربندی تعریف شده است.
"config-databases": [
{
// نام پایگاه‌داده برای اتصال.
"name": "config",
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "mysql"
}
],
// بازه زمانی بین تلاش‌ها برای واکشی به‌روزرسانی‌های پیکربندی
// از طریق بک‌اندهای پیکربندی مورد استفاده.
"config-fetch-wait-time": 30
},
// برچسب کارگزار.
"server-tag": "my DHCPv4 server",
// پارامترهای کنترل صف DHCP.
"dhcp-queue-control": {
// فعال‌سازی صف اجباری است.
"enable-queue": true,
// نوع صف اجباری است.
"queue-type": "kea-ring4",
// ظرفیت اختیاری است.
"capacity": 64
},
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند همه آدرس‌های رزروشده
// خارج از استخر هستند یا خیر.
// در صورت false بودن reservations-in-subnet نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "shared-networks" و
// "subnet4" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// محاسبه سراسری تایمرهای T1 و T2.
"calculate-tee-times": true,
// T1 = طول‌عمر معتبر * ۰٫۵.
"t1-percent": .5,
// T2 = طول‌عمر معتبر * ۰٫۷۵.
"t2-percent": .75,
// آستانه کش = طول‌عمر معتبر * ۰٫۲۵.
"cache-threshold": .25,
// حداکثر کش سراسری.
"cache-max-age": 1000,
// آستانه زمان اجاره انطباقی (1.0 به معنای غیرفعال است).
"adaptive-lease-time-threshold": 0.8,
// رشته‌ای از صفر یا چند نویسه که با هر نویسه نامعتبر
// در نام میزبان یا FQDN کلاینت جایگزین می‌شود. مقدار پیش‌فرض
// یک رشته خالی است که باعث می‌شود نویسه‌های نامعتبر به جای
// جایگزینی، حذف شوند.
"hostname-char-replacement": "x",
// عبارت منظم توصیف‌کننده مجموعه نویسه‌های نامعتبر در
// نام میزبان یا FQDN کلاینت.
"hostname-char-set": "[^A-Za-z0-9.-]",
// فهرست ثبت‌کننده‌های وقایع (loggers) مورد استفاده توسط سرورهایی که از این فایل پیکربندی استفاده می‌کنند.
"loggers": [
{
// سطح اشکال‌زدایی، مقداری بین 0..99. هرچه مقدار بزرگ‌تر باشد،
// گزارش اشکال‌زدایی با جزئیات بیشتری خواهد بود.
"debuglevel": 99,
// نام ثبت‌کننده وقایع.
"name": "kea-dhcp4",
// نحوه خروجی دادن گزارش‌ها را پیکربندی می‌کند.
"output-options": [
{
// مشخص می‌کند که آیا گزارش باید فوراً در فایل نوشته (flush) شود یا خیر.
"flush": true,
// حداکثر اندازه فایل را پیش از چرخش (rotate) فایل مشخص می‌کند.
"maxsize": 10240000,
// حداکثر تعداد فایل‌های چرخیده‌شده برای نگهداری را مشخص می‌کند.
"maxver": 1,
// مقصد ثبت وقایع را مشخص می‌کند.
"output": "stdout",
// محتوای مدخل وقایع‌نگاری را مشخص می‌کند
"pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// شدت ثبت وقایع را مشخص می‌کند، یعنی "ERROR"، "WARN"، "INFO"، "DEBUG".
"severity": "INFO"
}
],
// اگر بزرگ‌تر از صفر باشد، طول‌عمر اجاره‌هایی است که موقتاً در
// مرحله DISCOVER تخصیص داده می‌شوند. در صورت صفر بودن (پیش‌فرض)، در DISCOVER اجاره‌ای تخصیص داده نمی‌شود.
"offer-lifetime" : 60,
// برای استفاده از بافت‌های کاربری (user-contexts) به مثال‌های پیشرفته نگاه کنید.
"user-context": { }
}
}
168u
0.0
3.5
// هشدار: این پیکربندی نمونه برای استفاده در محیط عملیاتی در نظر گرفته نشده است.
// کارگزار Kea DHCPv4 این پیکربندی را رد خواهد کرد زیرا شامل
// پارامترهای پیکربندی ناسازگار با یکدیگر (مانعة‌الجمع) است.
//
// هدف اصلی این فایل نمونه، ارائهٔ فهرستی جامع از
// پارامترهای پشتیبانی‌شده توسط کارگزار Kea DHCPv4 به همراه شرحی مختصر
// از هر پارامتر است.
//
// این نسخهٔ کنونی باید به‌روز باشد، بدین معنا که واژه‌های کلیدی جدید باید
// هم‌زمان با مشخصات تجزیه‌کننده به این فایل افزوده شوند.
{
// پیکربندی کارگزار Kea DHCPv4 از اینجا آغاز می‌شود.
"Dhcp4": {
// پرچم سراسری انتخاب راهبرد تخصیص نشانی IP برای همهٔ
// زیرشبکه‌ها. برای یک راهبرد تخصیص تصادفی از "random" استفاده کنید.
"allocator": "iterative",
// پرچم سراسری معتبر (authoritative) برای رسیدگی به درخواست‌های کلاینت‌ها برای
// نشانی‌های IP ناشناخته (اگر غیرفعال باشد نادیده گرفته می‌شود، اگر فعال باشد NAK ارسال می‌شود).
"authoritative": false,
// نام فایل راه‌اندازی (bootfile) سراسری که باید در فیلد 'file' تنظیم شود.
"boot-file-name": "/dev/null",
// فهرست مرتب‌شده‌ای از کلاس‌های کلاینت که توسط کارگزار DHCPv4 استفاده می‌شود.
"client-classes": [
{
// نام فایل راه‌اندازی (bootfile) مخصوص کلاس که در فیلد 'file' تنظیم می‌شود.
"boot-file-name": "/usr/local/share/kea/bootfile.efi",
// نام کلاس.
"name": "phones_server1",
// نشانی کارگزار بعدی مخصوص کلاس برای استفاده در bootstrap که
// در فیلد 'siaddr' تنظیم می‌شود.
"next-server": "10.2.3.4",
// فهرست گزینه‌های DHCPv4 مخصوص کلاس.
"option-data": [],
// تعاریف گزینه‌های DHCPv4 مخصوص کلاس، یعنی قالب‌های سفارشی
// مشخص‌شده برای گزینه‌های غیر استاندارد.
"option-def": [],
// نام میزبان اختیاری کارگزار مخصوص کلاس که در
// فیلد 'sname' تنظیم می‌شود.
"server-hostname": "",
// عبارت انتخاب کلاس. هنگامی که عبارت داده‌شده درست (true) ارزیابی شود،
// بستهٔ DHCP به این کلاس اختصاص می‌یابد.
"test": "member('HA_server1')",
// مدت‌زمان اعتبار کلاس.
"valid-lifetime": 6000,
// حداقل مدت‌زمان اعتبار کلاس.
"min-valid-lifetime": 4000,
// حداکثر مدت‌زمان اعتبار کلاس.
"max-valid-lifetime": 8000,
// اگر بزرگ‌تر از صفر باشد، مدت‌زمان اعتبار اجاره‌هایی است که موقتاً
// در DISCOVER تخصیص می‌یابند. وقتی صفر باشد (پیش‌فرض)، اجاره‌ها در DISCOVER تخصیص داده نمی‌شوند.
"offer-lifetime" : 65
},
{
// مقدار پیش‌فرض نام فایل راه‌اندازی مخصوص کلاس. یک نام خالی
// به معنای مشخص نشدن نام فایل راه‌اندازی است.
"boot-file-name": "",
// نام کلاس دوم.
"name": "phones_server2",
// مقدار پیش‌فرض نشانی کارگزار بعدی مخصوص کلاس. نشانی
// IPv4 صفر به این معناست که مشخص نشده است.
"next-server": "0.0.0.0",
// فهرست گزینه‌های DHCPv4 مخصوص کلاس.
"option-data": [],
// تعاریف گزینه‌های DHCPv4 مخصوص کلاس، یعنی قالب‌های سفارشی
// مشخص‌شده برای گزینه‌های غیر استاندارد.
"option-def": [],
// نام میزبان اختیاری کارگزار مخصوص کلاس که در
// فیلد 'sname' تنظیم می‌شود.
"server-hostname": "",
// عبارت انتخاب کلاس. هنگامی که عبارت داده‌شده درست ارزیابی شود،
// بستهٔ DHCP به این کلاس اختصاص می‌یابد.
"test": "member('HA_server2')"
},
{
// نام کلاس سوم.
"name": "late",
// پرچم بولی که مشخص می‌کند آیا عبارت کلاس تنها زمانی ارزیابی شود
// که پیکربندی انتخاب‌شده (یعنی pool، subnet، shared-network)
// شامل این نام کلاس در فهرست "evaluate-additional-classes" خود باشد یا خیر. مقدار
// پیش‌فرض false به این معناست که عبارت آزمون کلاس همیشه باید
// ارزیابی شود.
"only-in-additional-list": true,
// عبارت انتخاب کلاس.
"test": "member('ALL')"
},
{
// نام کلاس چهارم.
"name": "my-template-class",
// پرچم کلاس الگو که حاوی عبارتی است که برای تولید نام همهٔ زیرکلاس‌های
// ایجادشده استفاده می‌شود. در این حالت، کلاس‌ها بر اساس شناسهٔ کلاینت نام‌گذاری می‌شوند.
"template-test": "substring(option[61].hex, 0, all)"
}
],
// پارامترهایی برای فعال‌سازی رفتارهای سازگار با کلاینت‌ها، بازپخش‌کننده‌ها (relays)
// یا سایر عامل‌های ناسازگار یا معیوب
"compatibility": {
// نادیده گرفتن گزینهٔ DHCP Server Identifier در صورت تنظیم روی true.
// فعال‌سازی این مورد باعث می‌شود Kea به‌جای دور انداختن، هر پرس‌وجویی را بپذیرد،
// حتی اگر نشانی موجود در گزینه متعلق به کارگزار دیگری باشد.
// مقدار پیش‌فرض این گزینه false است، زیرا فعال‌سازی آن با RFC ناسازگار است.
"ignore-dhcp-server-identifier": false,
// نادیده گرفتن زیرگزینهٔ Relay Agent Information Link Selection در صورت
// تنظیم روی true. فعال‌سازی این مورد باعث می‌شود Kea به‌جای تلاش برای استفاده
// از زیرشبکهٔ مشخص‌شده در زیرگزینه، از منطق عادی انتخاب زیرشبکه
// استفاده کند. این گزینه به‌طور پیش‌فرض false است، زیرا فعال‌سازی آن با RFC ناسازگار است.
"ignore-rai-link-selection": false,
// تجزیهٔ آسان‌گیرانه‌تر گزینه‌ها در جایی که فیلدها را می‌توان به‌طور قطعی
// استنتاج کرد، حتی اگر مغایر با RFC یا روال معمول باشد.
"lenient-option-parsing": true,
// پرچم بولی که نشان می‌دهد آیا نشانی‌های 0. و 255. در زیرشبکه‌هایی
// با طول پیشوند 24 یا کمتر، باید هرگز آزاد در نظر گرفته نشوند یا خیر.
// پیش‌فرض false است، زیرا این نشانی‌ها خاص نیستند؛ فقط نشانی‌های نخستین و واپسین خاص هستند.
"exclude-first-last-24": false
},
// پارامترهای پیکربندی سوکت کنترل فرمان برای کارگزار Kea DHCPv4.
"control-sockets": [
{
// نوع سوکت کنترل استفاده‌شده توسط کارگزار Kea DHCPv4.
// باید unix، http یا https باشد.
"socket-type": "unix",
// مکان فایل سوکت دامنهٔ یونیکس که کارگزار DHCPv4
// برای دریافت فرمان‌های کنترلی از مدیر کارگزار محلی استفاده می‌کند.
"socket-name": "kea4-ctrl-socket"
},
{
// نوع سوکت کنترل استفاده‌شده توسط کارگزار Kea DHCPv4.
// باید unix، http یا https باشد.
"socket-type": "https",
// نشانی سوکت HTTPS که کارگزار Kea DHCPv4 باید برای
// پرس‌وجوهای ورودی به آن گوش فرا دهد.
"socket-address": "127.0.0.1",
// درگاه سوکت HTTPS که کارگزار Kea DHCPv4 باید برای
// پرس‌وجوهای ورودی به آن گوش فرا دهد. در صورت فعال‌سازی HA
// و چندنخی، درگاه 8000 توسط شنوندهٔ http کتابخانهٔ قلاب HA
// استفاده می‌شود. هنگام استفاده از کتابخانهٔ قلاب HA با چندنخی
// برای کارکرد صحیح، مطمئن شوید درگاه استفاده‌شده توسط شنوندهٔ اختصاصی
// متفاوت از درگاه مشخص‌شده در اینجا باشد (مثلاً 8001). توجه داشته باشید
// که فرمان‌ها همچنان باید به یک سوکت کنترل ارسال شوند.
// شنوندهٔ اختصاصی منحصراً برای به‌روزرسانی‌های HA است.
"socket-port": 8004,
// لنگر اعتماد TLS (مرجع صدور گواهی یا CA). این یک
// نام فایل یا مسیر دایرکتوری است. همراه با سایر پارامترهای TLS
// تنها برای نوع سوکت کنترل https معنا دارد.
"trust-anchor": "my-ca",
// نام فایل گواهی کارگزار TLS.
"cert-file": "my-cert",
// نام فایل کلید خصوصی کارگزار TLS.
"key-file": "my-key",
// پرچم الزام گواهی‌های کلاینت در TLS. پیش‌فرض true
// است و به معنای الزام گواهی‌های کلاینت است. مقدار false
// به معنای اختیاری بودن آن‌هاست.
"cert-required": true,
// هدرهای اضافی HTTP برای افزودن به پاسخ‌ها.
"http-headers":
[
{
// بافت اختیاری کاربر.
"user-context": { "comment": "HSTS header" },
// نام الزامی هدر HTTP.
"name": "Strict-Transport-Security",
// مقدار الزامی هدر HTTP.
"value": "max-age=31536000"
}
],
// احراز هویت اختیاری.
"authentication": {
// نوع احراز هویت الزامی. تنها مقدار پشتیبانی‌شده
// برای احراز هویت پایهٔ HTTP مقدار basic است.
"type": "basic",
// یک پارامتر اختیاری قلمرو (realm) احراز هویت
// پایهٔ HTTP است. پیش‌فرض آن
// "kea-dhcpv4-server" است.
"realm": "kea-dhcpv4-server",
// از این پارامتر اختیاری می‌توان برای تعیین یک پیشوند مشترک
// برای فایل‌های مدیریت اعتبارنامه‌های کلاینت استفاده کرد.
"directory": "/usr/local/share/kea/kea-creds",
// این فهرست شناسه‌های کاربری و گذرواژه‌های مورد استفاده
// برای احراز هویت پایهٔ HTTP را مشخص می‌کند. در صورت خالی بودن
// یا وجود نداشتن، هر کلاینتی مجاز شمرده می‌شود.
"clients": [
// این مورد یک کلاینت مجاز را مشخص می‌کند.
{
// شناسهٔ کاربری نباید خالی باشد یا
// حاوی نویسهٔ ':' باشد. این یک
// پارامتر الزامی است.
"user": "admin",
// اگر گذرواژه مشخص نشود یک گذرواژهٔ
// خالی استفاده می‌شود.
"password": "1234"
},
// این مورد یک کلاینت مخفی را مشخص می‌کند.
{
// شناسهٔ کاربری محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenu است.
"user-file": "hiddenu",
// گذرواژه محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenp است.
"password-file": "hiddenp"
},
// این مورد یک کلاینت مخفی را با استفاده از یک
// راز در یک فایل مشخص می‌کند.
{
// راز محتوای فایل
// /usr/local/share/kea/kea-creds/hiddens است که باید در
// قالب <user-id>:<password> باشد.
"password-file": "hiddens"
}
]
}
}
],
// پیشوندی را مشخص می‌کند که باید به FQDN کلاینت تولیدشده اضافه شود.
// ممکن است در سطوح سراسری، shared-network و subnet مشخص شود.
"ddns-generated-prefix": "myhost",
// پرچم بولی که مشخص می‌کند آیا کارگزار باید تمایل کلاینت DHCP
// برای به‌روزرسانی DNS توسط خودش را نادیده بگیرد یا خیر. با تنظیم این پرچم روی true،
// کارگزار به‌روزرسانی‌های DNS را برای هر دو داده‌های مستقیم و
// معکوس DNS ارسال می‌کند. مقدار پیش‌فرض false است که نشان می‌دهد
// کارگزار در صورت درخواست، به‌روزرسانی DNS را به کلاینت واگذار می‌کند.
// این پارامتر را می‌توان در سطوح سراسری، shared-network
// و subnet مشخص کرد.
"ddns-override-client-update": false,
// پرچم بولی که نشان می‌دهد آیا کارگزار باید خواستهٔ کلاینت DHCP
// مبنی بر عدم به‌روزرسانی DNS را لغو کند یا خیر. با تنظیم این پارامتر
// روی true، کارگزار حتی زمانی که کلاینت درخواست عدم به‌روزرسانی داده باشد،
// به‌روزرسانی DNS را ارسال می‌کند. این پارامتر را می‌توان در سطوح
// سراسری، shared-network و subnet مشخص کرد.
"ddns-override-no-update": false,
// پسوندی که به نام ناقص ارسال‌شده به DNS افزوده می‌شود.
// مقدار پیش‌فرض یک رشتهٔ خالی است که نشان می‌دهد هیچ
// پسوندی افزوده نمی‌شود. می‌توان آن را در سطوح سراسری،
// shared-network و subnet مشخص کرد.
"ddns-qualifying-suffix": "",
// مقداری شمارشی که مشخص می‌کند آیا کارگزار باید نام میزبان یا
// Client FQDN ارسال‌شده توسط کلاینت را بپذیرد یا این نام را
// جایگزین کند. مقادیر قابل قبول عبارتند از: "never" (استفاده از
// نامی که کلاینت فرستاده)، "always" (جایگزینی نامی که
// کلاینت فرستاده)، "when-present" (جایگزینی نام فرستاده‌شده توسط کلاینت،
// اما در صورتی که کلاینت نامی نفرستاد نامی تولید نشود)، "when-not-present" (تولید
// نام در صورتی که کلاینت نامی نفرستاد، در غیر این صورت حفظ نام
// ارسال‌شده توسط کلاینت). مقدار پیش‌فرض "never" است. می‌توان آن را در
// سطوح سراسری، shared-network و subnet تعیین کرد.
"ddns-replace-client-name": "never",
// پرچم بولی که به‌روزرسانی DDNS را فعال یا غیرفعال می‌کند.
// پیش‌فرض آن true است. می‌تواند در سطوح سراسری، shared-
// network و subnet تعیین شود. این گزینه در ارتباط با
// dhcp-ddns:enable-updates عمل می‌کند که باید برای فعال‌سازی اتصالات
// به kea-dhcp-ddns مقدار true داشته باشد.
"ddns-send-updates": true,
// پرچم بولی که اگر true باشد به کارگزار دستور می‌دهد که همیشه
// هنگام تمدید اجاره‌ها، حتی اگر اطلاعات DNS تغییر نکرده باشد،
// DNS را به‌روز کند. رفتار پیش‌فرض کارگزار (یعنی مقدار پرچم false است)
// این است که فقط در صورت تغییر اطلاعات DNS، آن را به‌روزرسانی کند. این مورد
// را می‌توان در سطوح سراسری، shared-network و subnet تعیین کرد.
"ddns-update-on-renew": true,
// پرچم بولی که با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns ارسال می‌شود
// تا نشان دهد آیا باید از حل اختلاف به‌روزرسانی DNS طبق RFC 4703
// برای درخواست به‌روزرسانی مشخص‌شده استفاده شود یا خیر. مقدار پیش‌فرض این پرچم true است.
// این مورد را می‌توان در سطوح سراسری، shared-network و subnet تعیین کرد.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیهٔ آن صرفاً برای سازگاری عقبرو حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقداری شمارشی که همراه با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns ارسال
// می‌شود تا حالت مورد استفاده برای حل اختلاف‌ها را در حین انجام به‌روزرسانی‌های
// DDNS مشخص کند. مقادیر قابل قبول عبارتند از:
// check-with-dhcid (شامل افزودن رکورد DHCID و بررسی
// آن رکورد از طریق تشخیص تداخل طبق RFC 4703)،
// no-check-with-dhcid (تشخیص تداخل را نادیده می‌گیرد اما هنگام
// ایجاد/به‌روزرسانی ورودی یک رکورد DHCID اضافه می‌کند)،
// check-exists-with-dhcid (بررسی می‌کند که آیا رکورد DHCID موجود است
// اما تطابق مقدار رکورد با به‌روزرسانی را وارسی نمی‌کند. این حالت همچنین رکورد DHCID را برای ورودی به‌روز می‌کند)،
// no-check-without-dhcid (تشخیص تداخل را نادیده می‌گیرد و هنگام
// ایجاد/به‌روزرسانی ورودی DDNS رکورد DHCID اضافه نخواهد کرد).
// مقدار پیش‌فرض "check-with-dhcid" است. می‌توان آن را در
// سطوح سراسری، shared-network و subnet تعیین کرد.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// اگر بزرگ‌تر از 0.0 باشد، درصدی از مدت‌زمان اعتبار اجاره است
// که برای TTL در DNS استفاده می‌شود.
"ddns-ttl-percent": 0.75,
// اگر بزرگ‌تر از 0 باشد، به عنوان TTL در DNS استفاده خواهد شد. برحسب ثانیه مشخص می‌شود.
// نمی‌توانید هم ddns-ttl و هم هر یک از ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را مشخص کنید. آن‌ها مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// اگر بزرگ‌تر از 0 باشد، به عنوان کران پایین برای مقادیر محاسبه‌شدهٔ TTL در DNS استفاده می‌شود.
// برحسب ثانیه مشخص می‌شود.
"ddns-ttl-min": 24000,
// اگر بزرگ‌تر از 0 باشد، به عنوان کران بالا برای مقادیر محاسبه‌شدهٔ TTL در DNS استفاده می‌شود.
// برحسب ثانیه مشخص می‌شود.
"ddns-ttl-max": 64000,
// زمان برحسب ثانیه که مشخص می‌کند چه مدت یک اجارهٔ ردشده باید
// از تخصیص‌های DHCP کنار گذاشته شود. مقدار پیش‌فرض 86400 (24 ساعت) است.
"decline-probation-period": 86400,
// پیکربندی ارسال درخواست تغییر نام (NCR) برای کارگزار Kea DHCPv4.
// درخواست‌های NCR به ماژول Kea D2 فرستاده می‌شوند تا DNS پس از تخصیص
// اجاره‌های DHCP به‌روزرسانی شود.
"dhcp-ddns": {
// پرچم بولی که نشان می‌دهد آیا کارگزار Kea DHCPv4 باید به
// kea-dhcp-ddns متصل شود یا خیر. این گزینه برای ایجاد و ارسال NCRها
// به kea-dhcp-ddns باید true باشد. به‌طور پیش‌فرض، NCRها تولید نمی‌شوند.
"enable-updates": false,
// حداکثر تعداد NCRها را برای قرارگیری در صف در انتظار ارسال
// به کارگزار Kea D2 مشخص می‌کند.
"max-queue-size": 1024,
// قالب بسته‌ای که باید هنگام ارسال NCRها به کارگزار Kea D2 استفاده شود.
// در حال حاضر فقط قالب JSON پشتیبانی می‌شود.
"ncr-format": "JSON",
// پروتکل سوکت برای استفاده هنگام ارسال NCRها به D2. در حال حاضر
// فقط UDP پشتیبانی می‌شود.
"ncr-protocol": "UDP",
// نشانی IP که کارگزار Kea DHCPv4 باید برای ارسال
// NCRها به D2 استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید یک نشانی مناسب انتخاب کند.
"sender-ip": "0.0.0.0",
// شماره درگاهی که کارگزار Kea DHCPv4 باید برای ارسال
// NCRها به D2 استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید درگاه مناسبی را انتخاب کند.
"sender-port": 0,
// نشانی IP که D2 روی آن برای دریافت NCRها گوش فرا می‌دهد.
"server-ip": "127.0.0.1",
// شماره درگاهی که D2 روی آن به NCRها گوش می‌دهد.
"server-port": 53001
},
// نخستین درگاه از دو درگاه متوالی سوکت‌های UDP مورد استفاده
// برای ارتباط بین کارگزارهای DHCPv6 و DHCPv4 را مشخص می‌کند.
// استاندارد RFC 7341 را ببینید (پیش‌فرض روی 0 - غیرفعال).
// در صورت فعال‌سازی، مثلاً از 786 استفاده کنید.
"dhcp4o6-port": 0,
// پرچم بولی که مشخص می‌کند آیا کارگزار Kea DHCPv4
// باید گزینهٔ Client Identifier را در پاسخ‌های خود بازگرداند یا خیر.
// مقدار پیش‌فرض true است که نشان می‌دهد در صورت درج آن توسط کلاینت،
// این گزینه باید بازگردانده شود. مقدار false به کارگزار دستور می‌دهد
// برای سازگاری عقبرو با مشخصات قدیمی‌تر DHCP (که بیان می‌کردند Client Identifier نباید
// بازگردانده شود) این گزینه را ارسال نکند.
"echo-client-id": true,
// مجموعه‌ای از پارامترهای کارگزار Kea DHCPv4 که نحوهٔ پردازش
// اجاره‌های منقضی‌شدهٔ DHCP توسط کارگزار را پیکربندی می‌کند.
"expired-leases-processing": {
// تعداد ثانیه‌ها پس از آخرین حذف اجاره‌های منقضی‌شده را مشخص می‌کند
// که باید حذف بعدی در آن زمان رخ دهد.
// اگر هر دوی "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" صفر نباشند، هنگامی که کلاینت یک پیام release
// ارسال می‌کند، اجاره منقضی می‌شود به‌جای اینکه از
// ذخیره‌ساز اجاره حذف گردد.
"flush-reclaimed-timer-wait-time": 25,
// مدت‌زمان برحسب ثانیه را برای نگهداری اجاره‌های منقضی‌شده
// در پایگاه‌دادهٔ اجاره (lease affinity) مشخص می‌کند.
// اگر هر دوی "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" صفر نباشند، وقتی کلاینت یک پیام release
// می‌فرستد، اجاره منقضی می‌شود به‌جای اینکه از
// ذخیره‌ساز اجاره حذف گردد.
"hold-reclaimed-time": 3600,
// حداکثر تعداد اجاره‌های منقضی‌شده‌ای را مشخص می‌کند که می‌توانند
// در یک تلاش واحد برای پاک‌سازی اجاره‌های منقضی از
// پایگاه‌دادهٔ اجاره پردازش شوند. اگر اجاره‌های منقضی بیشتری
// وجود داشته باشد، در تلاش بعدی پاک‌سازی پردازش خواهند شد.
"max-reclaim-leases": 100,
// حداکثر زمان برحسب میلی‌ثانیه را مشخص می‌کند که یک تلاش منفرد
// برای پاک‌سازی اجاره‌های منقضی از پایگاه‌دادهٔ اجاره می‌تواند طول بکشد.
"max-reclaim-time": 250,
// مدت‌زمان برحسب ثانیه از آخرین تلاش برای پردازش اجاره‌های
// منقضی را پیش از آغاز تلاش بعدی مشخص می‌کند.
"reclaim-timer-wait-time": 10,
// حداکثر تعداد چرخه‌های پردازش اجاره‌های منقضی‌شده را مشخص می‌کند
// که منجر به پاک‌سازی کامل اجاره‌های منقضی از پایگاه‌دادهٔ
// اجاره نشدند و پس از آن پیام هشداری صادر می‌شود.
"unwarned-reclaim-cycles": 5
},
// فهرست کتابخانه‌های قلاب و پارامترهای پیکربندی خاص آن‌ها
// برای بارگذاری توسط کارگزار Kea DHCPv4.
"hooks-libraries": [
{
// مکان کتابخانهٔ قلاب جهت بارگذاری.
"library": "libdhcp_lease_cmds.so",
// پارامترهای پیکربندی مخصوص کتابخانهٔ قلاب.
"parameters": { }
},
{
// کتابخانهٔ قلاب backend میزبان MySQL مورد نیاز برای ذخیره‌سازی میزبان.
"library": "libdhcp_mysql.so"
},
{
// کتابخانهٔ قلاب backend میزبان PostgreSQL مورد نیاز برای ذخیره‌سازی میزبان.
"library": "libdhcp_pgsql.so"
}
],
// فهرست اعتبارنامه‌های دسترسی به منابع خارجی رزروهای IPv4،
"hosts-databases": [
{
// نام پایگاه‌داده برای اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژهٔ پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 3306,
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "mysql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// حالت فقط‌خواندنی.
"readonly": false,
// ورودی‌های بعدی برای پشتیبانی OpenSSL در MySQL هستند.
// لنگر اعتماد یا همان فایل یا دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// فهرست رمزها (راهنمای دستور ciphers در OpenSSL را ببینید).
"cipher-list": "AES",
// زمان انتظار اتصال مجدد.
// این پارامتر تعیین می‌کند که Kea چقدر قبل از تلاش برای
// اتصال مجدد منتظر بماند. برحسب میلی‌ثانیه بیان می‌شود. پیش‌فرض 0
// (غیرفعال) برای MySQL و PostgreSQL است.
"reconnect-wait-time": 3000,
// حداکثر دفعات تلاش مجدد برای اتصال.
"max-reconnect-tries": 3,
// اقدامی که هنگام شکست بازیابی اتصال انجام می‌شود.
// مقادیر پشتیبانی‌شده: stop-retry-exit، serve-retry-exit،
// serve-retry-continue
"on-fail": "stop-retry-exit",
// پرچمی که مشخص می‌کند آیا بازیابی پایگاه‌داده باید در هنگام
// راه‌اندازی کارگزار و در رویدادهای پیکربندی مجدد تلاش شود یا خیر.
"retry-on-startup": false,
// مهلت زمانی برقراری اتصال برحسب ثانیه.
"connect-timeout": 100,
// مهلت زمانی عملیات خواندن پایگاه‌داده برحسب ثانیه.
"read-timeout": 120,
// مهلت زمانی عملیات نوشتن پایگاه‌داده برحسب ثانیه.
"write-timeout": 180
},
{
// نام پایگاه‌داده برای اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژهٔ پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 5432,
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "postgresql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// مهلت زمانی کاربر TCP در هنگام ارتباط با پایگاه‌داده.
// برحسب ثانیه مشخص می‌شود.
"tcp-user-timeout": 100,
// لنگر اعتماد یا همان فایل یا دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// حالت SSL.
"ssl-mode": "verify-ca"
}
],
// فهرست انواع شناسه‌های رزرو میزبان که توسط کارگزار Kea DHCPv4
// برای واکشی رزروهای ایستا برای کلاینت‌های DHCP استفاده می‌شود.
// به‌طور پیش‌فرض همهٔ شناسه‌ها استفاده می‌شوند، به این معنی که کارگزار
// پرس‌وجوهای متعددی به پایگاه‌داده ارسال می‌کند تا دریابد آیا رزروی برای
// یک کلاینت خاص وجود دارد یا خیر. اگر یک استقرار خاص تنها از یک زیرمجموعه،
// مثلاً یک نوع شناسه استفاده می‌کند، این شناسه باید فقط در اینجا فهرست شود
// تا از پرس‌وجوهای غیرضروری به پایگاه‌داده جلوگیری شود.
"host-reservation-identifiers": [
"hw-address",
"duid",
"circuit-id",
"client-id",
"flex-id"
],
// پیکربندی رابط‌هایی را مشخص می‌کند که کارگزار Kea DHCPv4 روی آن‌ها
// به درخواست‌های DHCP گوش فرا می‌دهد.
"interfaces-config": {
// مشخص می‌کند که آیا کارگزار باید از سوکت‌های "udp" یا سوکت‌های
// "raw" برای گوش دادن به ترافیک DHCP استفاده کند. سوکت‌های
// "raw" زمانی مفید هستند که ترافیک مستقیم DHCP
// دریافت می‌شود.
"dhcp-socket-type": "udp",
// فهرستی از رابط‌هایی را مشخص می‌کند که کارگزار Kea DHCPv4
// باید روی آن‌ها به درخواست‌های DHCP گوش فرا دهد.
"interfaces": [
"eth0"
],
// مقداری شمارشی که نشان می‌دهد کدام رابط باید برای
// ارسال پاسخ‌های DHCP به کلاینت استفاده شود. مقدار پیش‌فرض
// "same-as-inbound" است که نشان می‌دهد پاسخ باید از طریق رابطی
// که پرس‌وجوی کلاینت در آن دریافت شده ارسال شود. مقدار "use-routing"
// نشان می‌دهد که کارگزار Kea باید از جدول مسیریابی هسته برای یافتن
// رابط مناسب استفاده کند.
"outbound-interface": "same-as-inbound",
// پرچم بولی که مشخص می‌کند آیا رابط‌های موجود باید پس از پیکربندی
// مجدد کارگزار دوباره شناسایی شوند یا خیر. مقدار پیش‌فرض true است،
// به این معنی که رابط‌ها همیشه دوباره شناسایی می‌شوند.
"re-detect": true,
// Kea سعی می‌کند سوکت‌های سرویس را در هنگام مقداردهی اولیه متصل کند،
// اما ممکن است به دلیل باز بودن قبلی درگاه یا یک پیکربندی نادرست با شکست مواجه شود. Kea می‌تواند
// این خطاها را نادیده گرفته و فقط آن‌ها را ثبت کند. این پرچم از راه‌اندازی کارگزار DHCP
// بدون اتصال همهٔ سوکت‌ها جلوگیری می‌کند. در صورت عدم تعیین،
// مقدار پیش‌فرض آن false است.
"service-sockets-require-all": true,
// Kea در زمان مقداردهی اولیه سعی می‌کند سوکت‌های سرویس را متصل کند. این
// گزینه تعداد دفعات تلاش مجدد برای اتصال به رابط را مشخص می‌کند.
// مقدار پیش‌فرض 0 است، به این معنی که عملیات تکرار نخواهد شد.
"service-sockets-max-retries": 5,
// فاصلهٔ زمانی برحسب میلی‌ثانیه برای انتظار پیش از تلاش بعدی
// جهت باز کردن مجدد سوکت سرویس.
"service-sockets-retry-wait-time": 5000
},
// پارامتر بولی که کنترل می‌کند آیا جستجوی زودهنگام رزروهای سراسری
// میزبان باید انجام شود یا خیر. این جستجو پیش از انتخاب زیرشبکه رخ می‌دهد
// و هنگامی که یک رزرو سراسری با برخی کلاس‌های کلاینت یافت شود، یک
// دسته‌بندی فاز دوم را آغاز می‌کند. همچنین می‌توان از آن برای نادیده گرفتن
// پرس‌وجوها با استفاده از رزروهای میزبان به عنوان جدول تصمیم‌گیری نمایه‌شده
// بر اساس شناسه‌های رزرو استفاده کرد.
"early-global-reservations-lookup": true,
// پارامتر بولی که رفتار کارگزار DHCP را در رابطه با ایجاد رزروهای
// میزبان برای یک نشانی IP یکسان کنترل می‌کند. به‌طور پیش‌فرض
// این پرچم روی true تنظیم شده است که در این صورت کارگزار از ایجاد چندین
// رزرو میزبان برای یک نشانی IP یکسان جلوگیری می‌کند. هنگامی که این پارامتر
// روی false تنظیم شود، کارگزار اجازهٔ ایجاد چندین رزرو برای یک نشانی IP یکسان
// را در یک زیرشبکه می‌دهد. این تنظیم در استقرارهایی مفید است که در آن ممکن است
// یک میزبان مشخص از طریق چندین رابط با کارگزار DHCP ارتباط برقرار کند و بسته
// به رابط انتخابی، یک نشانی MAC متفاوت (یا شناسهٔ دیگر) برای شناسایی میزبان
// استفاده شود. توجه داشته باشید که برخی از backendهای میزبان از حالتی که در آن
// چندین رزرو برای یک نشانی IP یکسان استفاده می‌شود پشتیبانی نمی‌کنند. اگر از این
// backendها استفاده شود و این تنظیم اعمال گردد، خطای پیکربندی رخ خواهد داد.
// backendهای MySQL و PostgreSQL از این حالت پشتیبانی می‌کنند.
"ip-reservations-unique": true,
// پارامتر بولی که کنترل می‌کند آیا جستجوی رزروهای میزبان باید قبل از
// جستجوی اجاره انجام شود یا خیر. این پارامتر فقط زمانی تأثیر دارد که چندنخی
// غیرفعال باشد. هنگامی که چندنخی فعال است، جستجوی رزروهای میزبان همیشه ابتدا
// انجام می‌شود تا از قفل شدن منابع در جستجوی اجاره جلوگیری شود.
"reservations-lookup-first": true,
// اعتبارنامه‌های دسترسی به پایگاه‌دادهٔ اجاره را مشخص می‌کند.
"lease-database": {
// پارامتر مخصوص backend بنام memfile که فاصلهٔ زمانی برحسب
// ثانیه را مشخص می‌کند که در آن فایل اجاره باید پاک‌سازی شود (ورودی‌های اجارهٔ
// منسوخ حذف می‌شوند تا از رشد بی‌رویهٔ فایل اجاره جلوگیری شود).
"lfc-interval": 3600,
// حداکثر تعداد خطاهای خواندن فایل اجاره که مجاز است پیش از آنکه بارگذاری
// فایل متوقف شود. پیش‌فرض 0 است (بدون محدودیت).
"max-row-errors": 100,
// نام فایل اجاره. در مورد پایگاه‌داده، نام پایگاه‌داده را
// مشخص می‌کند.
"name": "kea-leases4.csv",
// پارامتر مخصوص memfile که نشان می‌دهد آیا اجاره‌ها باید روی
// ذخیره‌ساز پایدار (دیسک) ذخیره شوند یا خیر. مقدار true پیش‌فرض
// است و نشان می‌دهد که اجاره‌ها در ذخیره‌ساز پایدار ذخیره می‌شوند.
// این تنظیم باید در محیط عملیاتی استفاده شود. مقدار false فقط باید
// برای اهداف آزمایشی استفاده شود زیرا اجاره‌های ذخیره‌نشده پس از
// راه‌اندازی مجدد کارگزار Kea از بین خواهند رفت.
"persist": true,
// نوع backend پایگاه‌دادهٔ اجاره، یعنی "memfile"، "mysql" یا
// "postgresql".
"type": "memfile"
},
// مقدار بولی که نشان می‌دهد آیا کارگزار Kea DHCPv4 باید از مقدار شناسهٔ کلاینت
// ارسال‌شده توسط کلاینت استفاده کند یا آن را نادیده بگیرد. مقدار پیش‌فرض true است
// که نشان می‌دهد کارگزار باید از شناسهٔ کلاینت استفاده کند و این شناسه نسبت به
// نشانی MAC کلاینت اولویت دارد. در استقرارهایی که نشانی MAC باید اولویت داشته باشد،
// این مقدار را می‌توان روی false تنظیم کرد که در این صورت کلاینت‌ها با نشانی MAC
// شناسایی می‌شوند. این مورد به‌ویژه زمانی مفید است که کلاینت‌ها شناسه‌های یکتا
// تولید نمی‌کنند یا این شناسه‌ها پایدار نیستند، و غیره.
"match-client-id": false,
// مقدار سراسری نشانی کارگزار بعدی که در فیلد 'siaddr' تنظیم می‌شود.
// مقدار سراسری ممکن است در محدوده‌های پیکربندی سطوح پایین‌تر
// بازنویسی شود.
"next-server": "192.0.2.123",
// مقدار سراسری که تعداد بسته‌های کلاینت (مثلاً DHCPREQUESTها) را محدود
// می‌کند که ممکن است در حین انتظار برای تکمیل کار کتابخانهٔ قلاب، پیش از ارسال پاسخ
// (مثلاً DHCPACK) به کلاینت متوقف شوند. یک نمونهٔ بارز زمانی است که kea-dhcp4
// یک DHCPREQUEST را پارک می‌کند در حالی که به‌روزرسانی(های) اجاره را به همتایان HA خود ارسال می‌کند.
// پس از تأیید به‌روزرسانی(ها)، بسته از حالت توقف خارج می‌شود.
// این مقدار تعداد بسته‌هایی را که می‌توانند در انتظار به‌روزرسانی‌ها باقی بمانند
// محدود می‌کند. در زمان ترافیک سنگین کلاینت‌ها، این مقدار می‌تواند مانع از تجمع بیش از حد
// به‌روزرسانی‌های معوق در kea-dhcp4 شود.
"parked-packet-limit": 256,
// فهرست گزینه‌های سراسری DHCP که کارگزار Kea DHCPv4 به
// کلاینت‌ها اختصاص می‌دهد.
"option-data": [
{
// پرچم بولی که نشان می‌دهد آیا گزینهٔ داده‌شده همیشه
// در پاسخ ارسال شود یا تنها در صورت درخواست. مقدار پیش‌فرض
// false نشان می‌دهد که تنها در صورت درخواست ارسال می‌شود.
"always-send": false,
// فهرستی اختیاری از کلاس‌ها که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه بدون در نظر گرفتن عضویت در کلاس اعمال می‌شود.
"client-classes": [ "class1", "class2" ],
// کد گزینه. در صورت ارائهٔ نام گزینه الزامی نیست.
"code": 6,
// مقدار بولی که نشان می‌دهد داده‌های گزینهٔ مشخص‌شده در فیلد "data"
// به صورت یک رشته از ارقام شانزده‌شانزدهی مشخص شده است یا در قالب CSV خوانا برای انسان.
"csv-format": true,
// داده‌های گزینه که باید در بار مفید گزینه ذخیره شوند.
"data": "192.0.3.1, 192.0.3.2",
// نام گزینه. در صورت ارائهٔ کد گزینه الزامی نیست.
"name": "domain-name-servers",
// پرچم بولی که نشان می‌دهد آیا گزینهٔ داده‌شده هرگز
// در پاسخ ارسال نشود یا خیر. مقدار پیش‌فرض false نشان می‌دهد
// که در صورت نیاز ارسال می‌شود. وقتی true باشد، گزینه صرف‌نظر از هر تنظیم دیگری
// ارسال نمی‌شود، یعنی یک پرچم نهایی است.
"never-send": false,
// فضای گزینه. پیش‌فرض، فضای گزینهٔ "dhcp4" است که
// گزینه‌های سطح بالای DHCPv4 را گروه‌بندی می‌کند.
"space": "dhcp4"
}
],
// فهرست تعاریف گزینه‌های سراسری، یعنی قالب‌های گزینه‌ای که
// کارگزار Kea DHCPv4 از آن‌ها استفاده می‌کند.
"option-def": [
{
// پرچم بولی که نشان می‌دهد آیا تعریف گزینه شامل آرایه‌ای از
// مقادیر با نوع مشخص است، مانند آرایه‌ای از نشانی‌های IPv4.
// مقدار پیش‌فرض false به این معنی است که گزینه شامل
// آرایه‌ای از مقادیر نیست.
"array": false,
// کد گزینه.
"code": 6,
// نام فضای گزینه‌ای را که توسط این گزینه کپسوله‌سازی شده نگه می‌دارد.
// همهٔ گزینه‌های متعلق به این فضای گزینه به عنوان زیرگزینه‌های
// این گزینه ارسال خواهند شد. یک رشتهٔ خالی به این معناست که
// این گزینه هیچ گزینه‌ای را کپسوله‌سازی نمی‌کند.
"encapsulate": "",
// نام گزینه.
"name": "my-option",
// در صورتی که گزینه از نوع "record" باشد (به "type" نگاه کنید)،
// انواع فیلدهای درون گزینه را مشخص می‌کند. در این مثال خاص،
// این گزینه شامل دو فیلد با طول‌های ۱ بایت و ۲ بایت است.
"record-types": "uint8, uint16",
// نام فضای گزینه‌ای که این گزینه به آن تعلق دارد.
"space": "my-space",
// نوع گزینه. همهٔ انواع ممکن در راهنمای مرجع
// مدیر Kea فهرست شده‌اند.
"type": "record"
}
],
// مقدار سراسری برای زمان‌سنج rebind، یعنی زمانی که پس از آن کلاینت
// DHCP در صورت عدم موفقیت در تمدید اجاره، وارد حالت rebind می‌شود.
"rebind-timer": 40,
// مقدار سراسری برای زمان‌سنج renew، یعنی زمانی که پس از آن
// کلاینت DHCP اجاره را تمدید می‌کند.
"renew-timer": 30,
// مقدار سراسری برای ذخیرهٔ اطلاعات گسترش‌یافته (مثلاً اطلاعات عامل
// بازپخش) همراه با هر اجاره.
"store-extended-info": true,
// آمارها نمونه‌هایی را در هر نقطهٔ مشاهده نگه می‌دارند.
// دو مقدار پیش‌فرض وجود دارد: حداکثر تعداد و حداکثر طول عمر.
// تنظیم حداکثر تعداد روی صفر آن را غیرفعال می‌کند.
"statistic-default-sample-count": 0,
// هنگامی که حداکثر تعداد 0 است، حداکثر طول عمر (برحسب ثانیه) اعمال می‌شود.
"statistic-default-sample-age": 60,
// پارامترهای چندنخی.
"multi-threading": {
// به‌طور پیش‌فرض، اگر سخت‌افزار اجازه دهد، Kea بسته‌ها را روی چندین نخ پردازش می‌کند.
"enable-multi-threading": true,
// هنگامی که چندنخی فعال باشد، Kea بسته‌ها را روی تعدادی نخ پردازش می‌کند
// که از طریق این گزینه قابل تنظیم است. مقدار باید یک عدد صحیح مثبت باشد
// (0 به معنی تشخیص خودکار است).
"thread-pool-size": 0,
// هنگامی که چندنخی فعال باشد، Kea بسته‌ها را از رابط می‌خواند
// و یک مورد کاری به استخر نخ‌ها اضافه می‌کند. این گزینه حداکثر تعداد
// مواردی را که می‌توان در صف قرار داد پیکربندی می‌کند.
// مقدار باید یک عدد صحیح مثبت باشد (0 یعنی نامحدود).
"packet-queue-size": 0
},
// نحوهٔ برخورد کارگزار Kea DHCPv4 با داده‌های نامعتبر
// دریافت شده از کلاینت را تعیین می‌کند.
"sanity-checks": {
// مشخص می‌کند که کارگزار Kea DHCPv4 در هنگام خواندن داده‌های نامعتبر
// برای یک اجاره از فایل اجاره چگونه باید رفتار کند. مقادیر زیر
// پشتیبانی می‌شوند: "none" (تلاشی برای تصحیح اطلاعات اجاره نکن)،
// "warn" (چاپ یک هشدار برای ناسازگاری‌های مربوط به subnet-id)،
// "fix" (تصحیح شناسهٔ زیرشبکه با تلاش برای یافتن زیرشبکهٔ مناسب)،
// "fix-del" (مشابه "fix" اما اگر زیرشبکهٔ مناسبی یافت نشد اجاره حذف شود)،
// "del" (حذف اجاره در صورتی که اجاره دارای مقدار شناسهٔ زیرشبکهٔ نامعتبر باشد).
"lease-checks": "warn",
// نحوهٔ رفتار کارگزار Kea DHCPv4 در هنگام خواندن اطلاعات گسترش‌یافتهٔ
// نامعتبر برای یک اجاره از فایل اجاره یا ارتقا از قالب قدیمی را مشخص می‌کند.
// مقادیر زیر پشتیبانی می‌شوند: "none" (تلاشی برای تصحیح یا ارتقای
// اطلاعات گسترش‌یافته نکن)، "fix" (اصلاح ناسازگاری‌های رایج و
// ارتقا از قالب قدیمی؛ این مقدار پیش‌فرض است)، "strict"
// (اصلاح ناسازگاری‌های دارای تأثیر بر Leasequery)،
// "pedantic" (اعمال قالب کامل کد Kea).
"extended-info-checks": "fix"
},
// فهرست شبکه‌های مشترک استفاده‌شده توسط کارگزار Kea DHCPv4.
// شبکه‌های مشترک زیرشبکه‌ها را با هم گروه‌بندی می‌کنند.
"shared-networks": [
{
// پرچمی برای انتخاب یک راهبرد تخصیص نشانی IP برای همهٔ
// زیرشبکه‌ها در این شبکهٔ مشترک.
"allocator": "random",
// پرچم معتبر در سطح شبکهٔ مشترک.
"authoritative": false,
// نام فایل راه‌اندازی در سطح شبکهٔ مشترک.
"boot-file-name": "/dev/null",
// این شبکهٔ مشترک را محدود می‌کند تا تنها به کلاینت‌هایی اجازه دهد
// که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه شود، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-override-client-update": false,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-override-no-update": false,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-qualifying-suffix": "",
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-replace-client-name": "never",
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-send-updates": true,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-update-on-renew": true,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیهٔ آن صرفاً برای سازگاری عقبرو حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-ttl-percent": 0.65,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
// نمی‌توانید هم ddns-ttl و هم هر یک از ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را مشخص کنید. آن‌ها مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-ttl-min": 10000,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"ddns-ttl-max": 20000,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// مشخص می‌کند که این شبکهٔ مشترک برای درخواست‌های دریافت شده
// روی یک رابط خاص انتخاب شده است.
"interface": "eth0",
// پرچم در سطح شبکهٔ مشترک که مشخص می‌کند آیا شناسهٔ کلاینت
// باید برای شناسایی کلاینت‌ها استفاده شود یا خیر.
"match-client-id": true,
// نام شبکهٔ مشترک.
"name": "my-secret-network",
// مشخصات کارگزار بعدی در سطح شبکهٔ مشترک جهت
// ارسال در 'siaddr'.
"next-server": "192.0.2.123",
// اگر بزرگ‌تر از صفر باشد، مدت‌زمان اعتبار اجاره‌هایی است که موقتاً
// در DISCOVER تخصیص می‌یابند. وقتی صفر باشد (پیش‌فرض)، اجاره‌ها در DISCOVER تخصیص داده نمی‌شوند.
"offer-lifetime" : 60,
// فهرست گزینه‌های DHCP مخصوص شبکهٔ مشترک.
"option-data": [],
// فهرست نشانی‌های بازپخش IPv4 که این شبکهٔ مشترک برای
// آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": []
},
// زمان‌سنج rebind در سطح شبکهٔ مشترک.
"rebind-timer": 41,
// زمان‌سنج renew در سطح شبکهٔ مشترک.
"renew-timer": 31,
// محاسبهٔ زمان‌سنج‌های T1 و T2 در سطح شبکهٔ مشترک.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانهٔ حافظهٔ پنهان = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر حافظهٔ پنهان: زمانی که زمان آخرین ارسال کلاینت به اندازهٔ کافی
// نزدیک باشد، اجاره تمدید نمی‌شود و اجارهٔ فعلی به صورت "cached" بازگردانده می‌شود.
"cache-max-age": 1000,
// آستانهٔ زمان اجارهٔ تطبیقی (1.0 غیرفعال است).
"adaptive-lease-time-threshold": 0.8,
// مشخص می‌کند که آیا کارگزار باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارگزار باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارگزار می‌تواند فرض کند همهٔ نشانی‌های رزروشده
// خارج از استخر هستند یا خیر.
// هنگامی که reservations-in-subnet برابر با false باشد نادیده گرفته می‌شود.
// در صورت مشخص شدن، به سطوح "subnet4" به ارث می‌رسد.
"reservations-out-of-pool": false,
// فهرست کلاس‌های کلاینت که باید در هنگام انتخاب این شبکهٔ مشترک
// برای تخصیص به کلاینت ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// خاموش کردن ذخیرهٔ اطلاعات گسترش‌یافته (مانند اطلاعات عامل بازپخش)
// همراه با هر اجاره برای این شبکهٔ مشترک.
"store-extended-info": false,
// نام میزبان کارگزار در سطح شبکهٔ مشترک که در فیلد 'sname' تنظیم می‌شود.
"server-hostname": "",
// فهرست زیرشبکه‌های IPv4 متعلق به این شبکهٔ مشترک.
"subnet4": [
{
// نام رابط تطبیق‌داده‌شده با نام رابط ورودی.
// استفاده‌شده در DHCPv4o6. استاندارد RFC 7341 را ببینید.
"4o6-interface": "",
// مقدار گزینهٔ شناسهٔ رابط. استاندارد RFC 7341 را ببینید.
"4o6-interface-id": "",
// پیشوند تطبیق‌داده‌شده با نشانی مبدأ. استاندارد RFC 7341 را ببینید.
"4o6-subnet": "2001:db8:1:1::/64",
// پرچمی برای انتخاب یک راهبرد تخصیص نشانی IP برای
// این زیرشبکه.
"allocator": "iterative",
// پرچم معتبر در سطح زیرشبکه.
"authoritative": false,
// نام فایل راه‌اندازی در سطح زیرشبکه، تنظیم‌شده در فیلد 'file'.
"boot-file-name": "",
// این زیرشبکه را محدود می‌کند تا تنها به کلاینت‌هایی اجازه دهد
// که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه شود، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-override-client-update": false,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-override-no-update": false,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-qualifying-suffix": "",
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-replace-client-name": "never",
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-send-updates": true,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-update-on-renew": true,
// مقدار در سطح شبکهٔ مشترک. توضیحات در سطح سراسری را ببینید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیهٔ آن صرفاً برای سازگاری عقبرو حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
// "ddns-ttl-percent": 0.55,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
// نمی‌توانید هم ddns-ttl و هم هر یک از ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را مشخص کنید. آن‌ها مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
// "ddns-ttl-min": 10000,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
// "ddns-ttl-max": 20000,
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح زیرشبکه. توضیحات در سطح سراسری را ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// شناسهٔ یکتای زیرشبکه.
"id": 1,
// مشخص می‌کند که این زیرشبکه برای درخواست‌های دریافت شده
// روی یک رابط خاص انتخاب شده است.
"interface": "eth0",
// پرچم در سطح زیرشبکه که مشخص می‌کند آیا شناسهٔ کلاینت
// باید برای شناسایی کلاینت‌ها استفاده شود یا خیر.
"match-client-id": true,
// مشخصات کارگزار بعدی در سطح زیرشبکه جهت ارسال
// در 'siaddr'.
"next-server": "0.0.0.0",
// اگر بزرگ‌تر از صفر باشد، مدت‌زمان اعتبار اجاره‌هایی است که موقتاً
// در DISCOVER تخصیص می‌یابند. وقتی صفر باشد (پیش‌فرض)، اجاره‌ها در DISCOVER تخصیص داده نمی‌شوند.
"offer-lifetime" : 60,
// روشن کردن ذخیرهٔ اطلاعات گسترش‌یافته (مانند اطلاعات عامل
// بازپخش) همراه با هر اجاره برای این زیرشبکه.
"store-extended-info": true,
// فهرست گزینه‌های DHCP در سطح زیرشبکه.
"option-data": [
{
// پرچم بولی که نشان می‌دهد آیا گزینهٔ خاص باید همیشه
// ارسال شود یا فقط در صورت درخواست ارسال گردد.
"always-send": false,
// فهرستی اختیاری از کلاس‌ها که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه بدون در نظر گرفتن عضویت در کلاس اعمال می‌شود.
"client-classes": [],
// کد گزینه.
"code": 3,
// پرچم بولی که نشان می‌دهد آیا مقدار گزینهٔ مشخص‌شده
// در "data" رشته‌ای از مقادیر شانزده‌شانزدهی است یا مقدار خوانا برای انسان
// در قالب CSV.
"csv-format": true,
// داده‌های گزینه که باید در بار مفید گزینه گنجانده شوند.
"data": "192.0.3.1",
// نام گزینه.
"name": "routers",
// پرچم بولی که نشان می‌دهد آیا گزینهٔ داده‌شده هرگز
// در پاسخ ارسال نشود یا خیر.
"never-send": false,
// فضای گزینه. مقدار پیش‌فرض "dhcp4" نشان‌دهندهٔ
// فضای گزینهٔ سطح بالا است.
"space": "dhcp4"
}
],
// فهرست استخرهای نشانی IP متعلق به زیرشبکه.
"pools": [
{
// این استخر را محدود می‌کند تا تنها به کلاینت‌هایی اجازه دهد
// که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه شود، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server1" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدودهٔ نشانی‌های استفاده‌شده برای تخصیص به کلاینت.
"pool": "192.1.0.1 - 192.1.0.200",
// فهرست کلاس‌های کلاینت که باید در هنگام انتخاب این استخر
// برای تخصیص به کلاینت ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-generated-prefix": "mypool",
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-override-client-update": false,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-override-no-update": false,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-qualifying-suffix": "pool.example.com.",
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-replace-client-name": "always",
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-send-updates": true,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-update-on-renew": false,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-ttl-percent": 0.55,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
// نمی‌توانید هم ddns-ttl و هم هر یک از ddns-ttl-percent،
// ddns-ttl-min یا ddns-ttl-max را مشخص کنید. آن‌ها مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-ttl-min": 10000,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"ddns-ttl-max": 20000,
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح استخر. توضیحات در سطح سراسری را ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]"
},
{
// این استخر را محدود می‌کند تا تنها به کلاینت‌هایی اجازه دهد
// که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه شود، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server2" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدودهٔ نشانی‌های استفاده‌شده برای تخصیص به کلاینت.
"pool": "192.3.0.1 - 192.3.0.200",
// فهرست کلاس‌های کلاینت که باید در هنگام انتخاب این استخر
// برای تخصیص به کلاینت ارزیابی شوند.
"evaluate-additional-classes": [],
// شناسهٔ استخر که برای فعال‌سازی آمارها برای این استخر استفاده می‌شود.
// شناسهٔ استخر نیازی نیست در درون زیرشبکه یا در میان زیرشبکه‌ها
// یکتا باشد. اگر پیکربندی نشود، پیش‌فرض آن 0 است. آمارهای
// مربوط به این استخر با سایر آمارهای همهٔ استخرهای دیگر با همان
// شناسهٔ استخر در این زیرشبکه ترکیب خواهد شد.
"pool-id": 1
}
],
// مقدار زمان‌سنج rebind در سطح زیرشبکه.
"rebind-timer": 40,
// فهرست نشانی‌های بازپخش IPv4 که این زیرشبکه برای آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": [
"192.168.56.1"
]
},
// مقدار زمان‌سنج renew در سطح زیرشبکه.
"renew-timer": 30,
// مشخص می‌کند که آیا کارگزار باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارگزار باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارگزار می‌تواند فرض کند همهٔ نشانی‌های
// رزروشده خارج از استخر هستند یا خیر.
// هنگامی که reservations-in-subnet برابر با false باشد نادیده گرفته می‌شود.
"reservations-out-of-pool": false,
// محاسبهٔ زمان‌سنج‌های T1 و T2 در سطح زیرشبکه.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانهٔ حافظهٔ پنهان = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر حافظهٔ پنهان در سطح زیرشبکه.
"cache-max-age": 1000,
// آستانهٔ زمان اجارهٔ تطبیقی (1.0 غیرفعال است).
"adaptive-lease-time-threshold": 0.8,
// فهرست رزروهای ایستای IPv4 اختصاص‌یافته به کلاینت‌های متعلق
// به این زیرشبکه. برای یک مثال دقیق، reservations.json را ببینید.
"reservations": [
{
// شناسهٔ استفاده‌شده برای مطابقت کلاینت. مقادیر پشتیبانی‌شده عبارتند از:
// "hw-address"، "client-id"، "duid"، "circuit-id"، "flex-id".
"circuit-id": "01:11:22:33:44:55:66",
// نشانی IP رزروشده.
"ip-address": "192.0.2.204",
// نام میزبان.
"hostname": "foo.example.org",
// داده‌های گزینهٔ مخصوص رزرو.
"option-data": [
{
// نام گزینه.
"name": "vivso-suboptions",
// داده‌های گزینه.
"data": "4491"
}
]
}
],
// فهرست کلاس‌های کلاینت که باید در هنگام انتخاب این زیرشبکه
// برای تخصیص به کلاینت ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// نام میزبان کارگزار در سطح زیرشبکه که در فیلد 'sname' تنظیم می‌شود.
"server-hostname": "",
// پیشوند زیرشبکه.
"subnet": "192.0.0.0/8",
// مدت‌زمان اعتبار (پیش‌فرض) در سطح زیرشبکه.
"valid-lifetime": 6000,
// حداقل مدت‌زمان اعتبار در سطح زیرشبکه.
"min-valid-lifetime": 4000,
// حداکثر مدت‌زمان اعتبار در سطح زیرشبکه.
"max-valid-lifetime": 8000
}
],
// مدت‌زمان اعتبار (پیش‌فرض) در سطح شبکهٔ مشترک.
"valid-lifetime": 6001,
// حداقل مدت‌زمان اعتبار در سطح شبکهٔ مشترک.
"min-valid-lifetime": 4001,
// حداکثر مدت‌زمان اعتبار در سطح شبکهٔ مشترک.
"max-valid-lifetime": 8001
}
],
// نام میزبان سراسری کارگزار که در فیلد 'sname' تنظیم می‌شود.
"server-hostname": "",
// پنهان‌سازی گزینه‌های عامل (یا همان RAI) تا پرس‌وجوهای مستقیم
// از طریق یک بازپخش به نظر برسند.
"stash-agent-options": false,
// فهرست زیرشبکه‌های IPv4 که به هیچ شبکهٔ مشترکی تعلق ندارند.
"subnet4": [],
// مقدار سراسری مدت‌زمان اعتبار.
"valid-lifetime": 6000,
// مقدار سراسری حداقل مدت‌زمان اعتبار.
"min-valid-lifetime": 4000,
// مقدار سراسری حداکثر مدت‌زمان اعتبار.
"max-valid-lifetime": 8000,
// رزروها (مثال‌ها در فایل‌های دیگر هستند).
"reservations": [],
// کنترل پیکربندی (در حال حاضر استفاده نمی‌شود، یعنی این نحو
// از قبل تعریف شده اما ویژگی متناظر آن پیاده‌سازی نشده است).
"config-control": {
// تنها ورودی پایگاه‌های دادهٔ پیکربندی تعریف شده است.
"config-databases": [
{
// نام پایگاه‌داده برای اتصال.
"name": "config",
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "mysql"
}
],
// فاصلهٔ زمانی میان تلاش‌ها برای واکشی به‌روزرسانی‌های پیکربندی
// از طریق backendهای پیکربندی استفاده‌شده.
"config-fetch-wait-time": 30
},
// برچسب کارگزار.
"server-tag": "my DHCPv4 server",
// پارامترهای کنترل صف DHCP.
"dhcp-queue-control": {
// فعال‌سازی صف الزامی است.
"enable-queue": true,
// نوع صف الزامی است.
"queue-type": "kea-ring4",
// گنجایش اختیاری است.
"capacity": 64
},
// مشخص می‌کند که آیا کارگزار باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارگزار باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارگزار می‌تواند فرض کند همهٔ نشانی‌های رزروشده
// خارج از استخر هستند یا خیر.
// هنگامی که reservations-in-subnet برابر با false باشد نادیده گرفته می‌شود.
// در صورت مشخص شدن، به سطوح "shared-networks" و
// "subnet4" به ارث می‌رسد.
"reservations-out-of-pool": false,
// محاسبهٔ سراسری زمان‌سنج‌های T1 و T2.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانهٔ حافظهٔ پنهان = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر حافظهٔ پنهان سراسری.
"cache-max-age": 1000,
// آستانهٔ زمان اجارهٔ تطبیقی (1.0 غیرفعال است).
"adaptive-lease-time-threshold": 0.8,
// رشته‌ای از صفر یا چند نویسه که هر نویسهٔ نامعتبر
// در نام میزبان یا Client FQDN با آن جایگزین می‌شود. مقدار پیش‌فرض
// یک رشتهٔ خالی است که باعث می‌شود نویسه‌های نامعتبر به‌جای
// جایگزینی، حذف شوند.
"hostname-char-replacement": "x",
// عبارت باقاعده‌ای که مجموعه نویسه‌های نامعتبر در
// نام میزبان یا Client FQDN را توصیف می‌کند.
"hostname-char-set": "[^A-Za-z0-9.-]",
// فهرست ثبت‌کننده‌های وقایع که توسط کارگزارهای استفاده‌کننده از این فایل پیکربندی استفاده می‌شوند.
"loggers": [
{
// سطح اشکال‌زدایی، مقداری بین 0..99. هرچه مقدار بزرگ‌تر باشد،
// گزارش اشکال‌زدایی دقیق‌تر خواهد بود.
"debuglevel": 99,
// نام ثبت‌کننده.
"name": "kea-dhcp4",
// نحوهٔ خروجی گزارش وقایع را پیکربندی می‌کند.
"output-options": [
{
// تعیین می‌کند که آیا گزارش باید در یک فایل تخلیه شود یا خیر.
"flush": true,
// حداکثر اندازهٔ فایل را قبل از چرخش فایل مشخص می‌کند.
"maxsize": 10240000,
// حداکثر تعداد فایل‌های چرخانده‌شده برای نگهداری را مشخص می‌کند.
"maxver": 1,
// مقصد ثبت وقایع را مشخص می‌کند.
"output": "stdout",
// محتوای ورودی گزارش را مشخص می‌کند.
"pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// شدت ثبت وقایع را مشخص می‌کند، یعنی "ERROR"، "WARN"، "INFO"، "DEBUG".
"severity": "INFO"
}
],
// اگر بزرگ‌تر از صفر باشد، مدت‌زمان اعتبار اجاره‌هایی است که موقتاً
// در DISCOVER تخصیص می‌یابند. وقتی صفر باشد (پیش‌فرض)، اجاره‌ها در DISCOVER تخصیص داده نمی‌شوند.
"offer-lifetime" : 60,
// برای استفاده از بافت‌های کاربر به مثال‌های پیشرفته نگاه کنید.
"user-context": { }
}
}
168u
0.0
3.5
// این فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea شامل موارد زیر است:
//
// - داده‌ها برای تمام گزینه‌های استاندارد
// - تعاریف گزینه‌های سفارشی در سطح سراسری به همراه برخی داده‌های گزینه
// مرتبط
// - داده‌های گزینه سفارشی با فضاهای نام استانداردشده گزینه غیر از "dhcp4"
// - فضاهای گزینه سفارشی
// - مثال‌هایی از تعبیه گزینه (option embedding)
//
// به خواننده اکیداً توصیه می‌شود نگاهی به قالب‌های گزینه
// مستندشده در Kea ARM بیندازد:
// https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?highlight=list%20of%20standard%20dhcpv4#id2
{
"Dhcp4": {
/*
داده‌ها برای تمامی تعاریف گزینه‌های استاندارد
*/
// داده‌های گزینه که به صورت سراسری تعریف شده‌اند
"option-data": [
/*
Code Len Time Offset
+-----+-----+-----+-----+-----+-----+
| 2 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: int32
{
"code": 2,
"data": "-25200",
"name": "time-offset"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 3,
"data": "192.0.2.2, 192.0.2.3",
"name": "routers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 4,
"data": "192.0.2.4, 192.0.2.5",
"name": "time-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 5,
"data": "192.0.2.6, 192.0.2.7",
"name": "name-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 6,
"data": "192.0.2.8, 192.0.2.9",
"name": "domain-name-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 7,
"data": "192.0.2.10, 192.0.2.11",
"name": "log-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 8,
"data": "192.0.2.12, 192.0.2.13",
"name": "cookie-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 9,
"data": "192.0.2.14, 192.0.2.15",
"name": "lpr-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 10,
"data": "192.0.2.16, 192.0.2.17",
"name": "impress-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 11,
"data": "192.0.2.18, 192.0.2.19",
"name": "resource-location-servers"
},
/*
Code Len File Size
+-----+-----+-----+-----+
| 13 | 2 | l1 | l2 |
+-----+-----+-----+-----+
*/
// نوع: uint16
{
"code": 13,
"data": "1024",
"name": "boot-size"
},
/*
Code Len Dump File Pathname
+-----+-----+-----+-----+-----+-----+---
| 14 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 14,
"data": "/etc/crash-dump.img",
"name": "merit-dump"
},
/*
Code Len Domain Name
+-----+-----+-----+-----+-----+-----+--
| 15 | n | d1 | d2 | d3 | d4 | ...
+-----+-----+-----+-----+-----+-----+--
*/
// نوع: FQDN
{
"code": 15,
"data": "my.example.org",
"name": "domain-name"
},
/*
Code Len Swap Server Address
+-----+-----+-----+-----+-----+-----+
| 16 | n | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: IPv4 address
{
"code": 16,
"data": "192.0.2.20",
"name": "swap-server"
},
/*
Code Len Root Disk Pathname
+-----+-----+-----+-----+-----+-----+---
| 17 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 17,
"data": "/path/to/root",
"name": "root-path"
},
/*
Code Len Extensions Pathname
+-----+-----+-----+-----+-----+-----+---
| 18 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 18,
"data": "/path/to/extensions",
"name": "extensions-path"
},
/*
Code Len Value
+-----+-----+-----+
| 19 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 19,
"data": "true",
"name": "ip-forwarding"
},
/*
Code Len Value
+-----+-----+-----+
| 20 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 20,
"data": "true",
"name": "non-local-source-routing"
},
/*
Code Len Address 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Address 2 Mask 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 21,
"data": "10.229.0.128, 255.255.255.128, 10.27.129.0, 255.255.255.0",
"name": "policy-filter"
},
/*
Code Len Size
+-----+-----+-----+-----+
| 22 | 2 | s1 | s2 |
+-----+-----+-----+-----+
*/
// نوع: uint16
{
"code": 22,
"data": "2048",
"name": "max-dgram-reassembly"
},
/*
Code Len TTL
+-----+-----+-----+
| 23 | 1 | ttl |
+-----+-----+-----+
*/
// نوع: uint8
{
"code": 23,
"data": "248",
"name": "default-ip-ttl"
},
/*
Code Len Timeout
+-----+-----+-----+-----+-----+-----+
| 24 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: uint32
{
"code": 24,
"data": "131072",
"name": "path-mtu-aging-timeout"
},
/*
Code Len Size 1 Size 2
+-----+-----+-----+-----+-----+---
| 25 | n | s1 | s2 | s1 | s2 | ...
+-----+-----+-----+-----+-----+---
*/
// نوع: آرایه‌ای از {uint16}
{
"code": 25,
"data": "3072, 4096",
"name": "path-mtu-plateau-table"
},
/*
Code Len MTU
+-----+-----+-----+-----+
| 26 | 2 | m1 | m2 |
+-----+-----+-----+-----+
*/
// نوع: uint16
{
"code": 26,
"data": "5120",
"name": "interface-mtu"
},
/*
Code Len Value
+-----+-----+-----+
| 27 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 27,
"data": "true",
"name": "all-subnets-local"
},
/*
Code Len Broadcast Address
+-----+-----+-----+-----+-----+-----+
| 28 | 4 | b1 | b2 | b3 | b4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: IPv4 address
{
"code": 28,
"data": "192.0.2.255",
"name": "broadcast-address"
},
/*
Code Len Value
+-----+-----+-----+
| 29 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 29,
"data": "true",
"name": "perform-mask-discovery"
},
/*
Code Len Value
+-----+-----+-----+
| 30 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 30,
"data": "true",
"name": "mask-supplier"
},
/*
Code Len Value
+-----+-----+-----+
| 31 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 31,
"data": "true",
"name": "router-discovery"
},
/*
Code Len Address
+-----+-----+-----+-----+-----+-----+
| 32 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: IPv4 address
{
"code": 32,
"data": "192.0.2.23",
"name": "router-solicitation-address"
},
/*
Code Len Destination 1 Router 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Destination 2 Router 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 33,
"data": "192.0.2.24, 192.0.2.25",
"name": "static-routes"
},
/*
Code Len Value
+-----+-----+-----+
| 34 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 34,
"data": "true",
"name": "trailer-encapsulation"
},
/*
Code Len Time
+-----+-----+-----+-----+-----+-----+
| 35 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: uint32
{
"code": 35,
"data": "196608",
"name": "arp-cache-timeout"
},
/*
Code Len Value
+-----+-----+-----+
| 36 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 36,
"data": "true",
"name": "ieee802-3-encapsulation"
},
/*
Code Len TTL
+-----+-----+-----+
| 37 | 1 | n |
+-----+-----+-----+
*/
// نوع: uint8
{
"code": 37,
"data": "124",
"name": "default-tcp-ttl"
},
/*
Code Len Time
+-----+-----+-----+-----+-----+
| 38 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+
*/
// نوع: uint32
{
"code": 38,
"data": "262144",
"name": "tcp-keepalive-interval"
},
/*
Code Len Value
+-----+-----+-----+
| 39 | 1 | 0/1 |
+-----+-----+-----+
*/
// نوع: boolean
{
"code": 39,
"data": "true",
"name": "tcp-keepalive-garbage"
},
/*
Code Len NIS Domain Name
+-----+-----+-----+-----+-----+-----+---
| 40 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 40,
"data": "nis.example.org",
"name": "nis-domain"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 41,
"data": "192.0.2.26, 192.0.2.27",
"name": "nis-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 42,
"data": "192.0.2.28, 192.0.2.29",
"name": "ntp-servers"
},
/*
Code Len Vendor-specific information
+-----+-----+-----+-----+---
| 43 | n | i1 | i2 | ...
+-----+-----+-----+-----+---
Code Len Data item Code Len Data item Code
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
*/
// نوع: empty
{
"code": 43,
"name": "vendor-encapsulated-options"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
| 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 44,
"data": "192.0.2.30, 192.0.2.31",
"name": "netbios-name-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
| 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 45,
"data": "192.0.2.32, 192.0.2.33",
"name": "netbios-dd-server"
},
/*
Value Node Type
----- ---------
0x1 B-node
0x2 P-node
0x4 M-node
0x8 H-node
Code Len Node Type
+-----+-----+-----------+
| 46 | 1 | see above |
+-----+-----+-----------+
*/
// نوع: uint8
{
"code": 46,
"data": "0x1",
"name": "netbios-node-type"
},
/*
Code Len NetBIOS Scope
+-----+-----+-----+-----+-----+-----+----
| 47 | n | s1 | s2 | s3 | s4 | ...
+-----+-----+-----+-----+-----+-----+----
*/
// نوع: string
{
"code": 47,
"data": "scope42",
"name": "netbios-scope"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 48,
"data": "192.0.2.34, 192.0.2.35",
"name": "font-servers"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 49,
"data": "192.0.2.36, 192.0.2.37",
"name": "x-display-manager"
},
/*
مقدار مفهوم
----- --------
1 فیلد 'file' برای نگهداری گزینه‌ها استفاده می‌شود
2 فیلد 'sname' برای نگهداری گزینه‌ها استفاده می‌شود
3 هر دو فیلد برای نگهداری گزینه‌ها استفاده می‌شوند
Code Len Value
+-----+-----+-----+
| 52 | 1 |1/2/3|
+-----+-----+-----+
*/
// نوع: uint8
{
"code": 52,
"data": "3",
"name": "dhcp-option-overload"
},
/*
Code Len Address
+-----+-----+-----+-----+-----+-----+
| 54 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: IPv4 address
{
"code": 54,
"data": "192.0.2.39",
"name": "dhcp-server-identifier"
},
/*
Code Len Text
+-----+-----+-----+-----+---
| 56 | n | c1 | c2 | ...
+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 56,
"data": "Error: here is a DHCPNAK!",
"name": "dhcp-message"
},
/*
Code Len Length
+-----+-----+-----+-----+
| 57 | 2 | l1 | l2 |
+-----+-----+-----+-----+
*/
// نوع: uint16
{
"code": 57,
"data": "1536",
"name": "dhcp-max-message-size"
},
/*
Code Len Vendor class Identifier
+-----+-----+-----+-----+---
| 60 | n | i1 | i2 | ...
+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 60,
"data": "ISC",
"name": "vendor-class-identifier"
},
/*
Code Len NetWare/IP Domain Name
+-----+-----+------+------+------+-----
| 62 | n | c1 | c2 | c3 | ...
+-----+-----+------+------+------+-----
*/
// نوع: string
{
"code": 62,
"data": "nwip.example.org",
"name": "nwip-domain-name"
},
/*
Code Len NetWare/IP General Info
+-----+-----+----+----+
| 63 | 11 | 2 | 0 |
+-----+-----+----+----+
NWIP_EXIST_IN_OPTIONS_AREA (length 0)
+----+----+----+
| 5 | 1 | 1 |
+----+----+----+
NSQ_BROADCAST_SERVER (length 1)
value is YES
+----+----+------------+
| 7 | 4 | IP address |
+----+----+------------+
NEAREST_NWIP_SERVER (length 4)
value is IP address of server
*/
// نوع: binary
{
"code": 63,
"data": "1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "nwip-suboptions"
},
/*
Code Len NIS Client Domain Name
+-----+-----+-----+-----+-----+-----+---
| 64 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 64,
"data": "nisplus.example.org",
"name": "nisplus-domain-name"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: IPv4 address
{
"code": 65,
"data": "192.0.2.40",
"name": "nisplus-servers"
},
/*
Code Len TFTP server
+-----+-----+-----+-----+-----+---
| 66 | n | c1 | c2 | c3 | ...
+-----+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 66,
"data": "tftp.example.org",
"name": "tftp-server-name"
},
/*
Code Len Bootfile name
+-----+-----+-----+-----+-----+---
| 67 | n | c1 | c2 | c3 | ...
+-----+-----+-----+-----+-----+---
*/
// نوع: string
{
"code": 67,
"data": "boot-file.img",
"name": "boot-file-name"
},
/*
Code Len Home Agent Addresses (zero or more)
+-----+-----+-----+-----+-----+-----+--
| 68 | n | a1 | a2 | a3 | a4 | ...
+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 68,
"data": "192.0.2.41, 192.0.2.42",
"name": "mobile-ip-home-agent"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 69,
"data": "192.0.2.43, 192.0.2.44",
"name": "smtp-server"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 70,
"data": "192.0.2.45, 192.0.2.46",
"name": "pop-server"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 71,
"data": "192.0.2.47, 192.0.2.48",
"name": "nntp-server"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 72,
"data": "192.0.2.49, 192.0.2.50",
"name": "www-server"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 73,
"data": "192.0.2.51, 192.0.2.52",
"name": "finger-server"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 74,
"data": "192.0.2.53, 192.0.2.54",
"name": "irc-server"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 75,
"data": "192.0.2.55, 192.0.2.56",
"name": "streettalk-server"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 76,
"data": "192.0.2.57, 192.0.2.58",
"name": "streettalk-directory-assistance-server"
},
/*
Code Len Value
+-----+-----+--------------------- . . . --+
| 77 | N | User Class Data ('Len' octets) |
+-----+-----+--------------------- . . . --+
*/
// نوع: binary
{
"code": 77,
"data": "1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "user-class"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code = 78 | Length | Mandatory | a1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a2 | a3 | a4 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*/
// نوع: boolean، آرایه‌ای از {IPv4 address}
{
"code": 78,
"data": "true, 192.0.2.59, 192.0.2.60",
"name": "slp-directory-agent"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code = 79 | Length | Mandatory | <Scope List>...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*/
// نوع: boolean، string
{
"code": 79,
"data": "true, slp-scope",
"name": "slp-service-scope"
},
// کد گزینه 80 در Kea تعریف نشده است.
// کد گزینه 83 در Kea تعریف نشده است.
// کد گزینه 84 تخصیص نیافته است.
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--
| 85 | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | a4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 85,
"data": "192.0.2.61, 192.0.2.62",
"name": "nds-servers"
},
/*
Code Len NDS Tree Name
+----+----+----+----+----+----+--
| 86 | n | c1 | c2 | c3 | c4 | ...
+----+----+----+----+----+----+--
*/
// نوع: string
{
"code": 86,
"data": "my-tree",
"name": "nds-tree-name"
},
/*
Code Len Initial NDS Context
+----+----+----+----+----+----+--
| 87 | n | c1 | c2 | c3 | c4 | ...
+----+----+----+----+----+----+--
*/
// نوع: string
{
"code": 87,
"data": "context",
"name": "nds-context"
},
/*
Code Len FQDN(s) of BCMCS Controller
+-----+-----+-----+-----+-----+-----+-----+--
| 88 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: FQDN
{
"code": 88,
"data": "bcms-controller.example.org",
"name": "bcms-controller-names"
},
/*
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+--
| 89 | n | a1 | a2 | a3 | a4 | a1 | ...
+-----+-----+-----+-----+-----+-----+-----+--
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 89,
"data": "192.0.2.63",
"name": "bcms-controller-address"
},
/*
Code Len 16-bit Type
+----+-----+-----+-----+
| 93 | n | n1 | n2 |
+----+-----+-----+-----+
*/
// نوع: آرایه‌ای از uint16
{
"code": 93,
"data": "6144, 7168",
"name": "client-system"
},
/*
Code Len Type Major Minor
+----+-----+----+-----+-----+
| 94 | 3 | t | M | m |
+----+-----+----+-----+-----+
*/
// نوع: uint8، uint8، uint8
{
"code": 94,
"data": "0, 1, 0",
"name": "client-ndi"
},
// کد گزینه 95 پشتیبانی نمی‌شود.
// کد گزینه 96 تخصیص نیافته است.
/*
Code Len Type Machine Identifier
+----+-----+----+-----+ . . . +-----+
| 97 | n | t | | . . . | |
+----+-----+----+-----+ . . . +-----+
*/
// نوع: uint8، binary
{
"code": 97,
"data": "0, 1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "uuid-guid"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | URL list
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code 98
Length طول فیلد داده (یعنی فهرست URL) بر حسب
بایت.
URL list فهرستی از یک یا چند URL که با نویسه فاصله
اسکی (0x20) از هم جدا شده‌اند.
*/
// نوع: string
{
"code": 98,
"data": "uap1.example.org uap2.example.org",
"name": "uap-servers"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GEOCONF_CIVIC | N | what | country |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | civic address elements ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code GEOCONF_CIVIC: کد این گزینه DHCP برابر 99 است.
N: طول این گزینه متغیر است. حداقل طول 3
بایت است.
what: عنصر 'what' توصیف می‌کند که مدخل DHCP به کدام مکان
اشاره دارد. در حال حاضر، سه حالت تعریف شده است: مکان
کارساز DHCP (مقدار 0)، مکان عنصر شبکه‌ای که تصور
می‌شود نزدیک‌ترین به کلاینت باشد (مقدار 1)، یا مکان
کلاینت (مقدار 2). گزینه (2) باید (SHOULD) استفاده شود،
اما ممکن است مشخص نباشد. گزینه‌های (0) و (1) نباید (SHOULD NOT)
استفاده شوند مگر اینکه مشخص باشد کلاینت DHCP در مجاورت فیزیکی
نزدیک به کارساز یا عنصر شبکه قرار دارد.
country code: کد کشور دو حرفی ISO 3166 با حروف بزرگ
ASCII، مانند DE یا US. (آدرس‌های مدنی همیشه شامل تعیین
کشور هستند، که پیشنهاددهنده استفاده از یک فیلد با قالب ثابت
برای صرفه‌جویی در فضا است.)
civic address elements: صفر یا تعداد بیشتری عنصر شامل آدرس
مدنی و/یا پستی، با قالبی که در زیر شرح داده شده است
(بخش 3.3).
*/
// نوع: binary
{
"code": 99,
"data": "1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "geoconf-civic"
},
/*
PCode Len TZ-POSIX String
+-----+-----+------------------------------+
| 100 | N | IEEE 1003.1 String |
+-----+-----+------------------------------+
*/
// نوع: string
{
"code": 100,
// در گزینه‌های رشته‌ای که در مقادیر خود ویرگول دارند، باید
// آن را با نویسه گریز مشخص کرد (یعنی قبل از هر ویرگول دو بک‌اسلش قرار گیرد).
// دلیل آن این است که ویرگول‌ها برای جداسازی فیلدها در گزینه‌های
// مرکب رزرو شده‌اند. در عین حال، باید با مشخصات JSON که
// اجازه "\," را نمی‌دهد، سازگار باشیم. بنابراین، نمادگذاری
// کمی نامعمول دو بک‌اسلش مورد نیاز است.
// مقداری که روی شبکه ارسال می‌شود:
// EST5EDT4,M3.2.0/02:00,M11.1.0/02:00
"data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00",
"name": "pcode"
},
/*
TCode Len TZ-Database String
+-----+-----+------------------------------+
| 101 | N | Reference to the TZ Database |
+-----+-----+------------------------------+
*/
// نوع: string
{
"code": 101,
"data": "Europe/Zurich",
"name": "tcode"
},
// کدهای گزینه 102-107 تخصیص نیافته‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: شناسه ۸ بیتی کد گزینه IPv6-Only Preferred به صورتی که
توسط IANA تخصیص داده شده است: 108. کلاینت این کد را در
فهرست Parameter Request در پیام‌های DHCPDISCOVER و DHCPREQUEST طبق
توضیحات بخش 3.2 قرار می‌دهد.
Length: عدد صحیح بدون علامت ۸ بیتی. طول گزینه، بدون در نظر گرفتن
فیلدهای Code و Length. کارساز باید (MUST) فیلد طول را برابر
4 قرار دهد. کلاینت اگر مقدار فیلد طول برابر 4 نباشد، باید (MUST)
گزینه IPv6-Only Preferred را نادیده بگیرد.
Value: عدد صحیح بدون علامت ۳۲ بیتی. تعداد ثانیه‌هایی که کلاینت باید
DHCPv4 را غیرفعال کند (متغیر پیکربندی V6ONLY_WAIT).
اگر استخر کارساز صراحتاً با یک تایمر V6ONLY_WAIT پیکربندی شده باشد،
کارساز باید فیلد را روی آن مقدار پیکربندی‌شده تنظیم کند. در غیر این صورت،
کارساز باید آن را صفر قرار دهد. کلاینت باید این فیلد را طبق
توضیحات بخش 3.2 پردازش کند.
*/
// نوع: uint32
{
"code": 108,
"data": "3600",
"name": "v6-only-preferred"
},
// کدهای گزینه 109-111 تخصیص نیافته‌اند.
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 112,
"data": "192.0.2.63, 192.0.2.64",
"name": "netinfo-server-address"
},
// نوع: string
{
"code": 113,
"data": "server1",
"name": "netinfo-server-tag"
},
// نوع: string
{
"code": 114,
"data": "https://default.example.org",
"name": "v4-captive-portal"
},
// کد گزینه 115 تخصیص نیافته است.
/*
Code Len Value
+-----+-----+-----+
| 116 | 1 | a |
+-----+-----+-----+
*/
// نوع: uint8
{
"code": 116,
"data": "1",
"name": "auto-config"
},
/*
Code Length Name Service Search Order in Sequence
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 117 | Len | ns1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ns2 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*/
// نوع: آرایه‌ای از {uint16}
{
"code": 117,
"data": "6, 41, 44, 65",
"name": "name-service-search"
},
/*
Code Len IPv4 Address
+-----+-----+-----+-----+-----+-----+
| 118 | 4 | A1 | A2 | A3 | A4 |
+-----+-----+-----+-----+-----+-----+
*/
// نوع: IPv4 address
{
"code": 118,
"data": "192.0.2.65",
"name": "subnet-selection"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 119 | Len | Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*/
// نوع: آرایه‌ای از {FQDN}
{
"code": 119,
"data": "example.com, example.org",
"name": "domain-search"
},
// کد گزینه 120 در Kea تعریف نشده است.
/*
Code Len Destination 1 Router 1
+-----+---+----+-----+----+----+----+----+----+
| 121 | n | d1 | ... | dN | r1 | r2 | r3 | r4 |
+-----+---+----+-----+----+----+----+----+----+
Destination 2 Router 2
+----+-----+----+----+----+----+----+
| d1 | ... | dN | r1 | r2 | r3 | r4 |
+----+-----+----+----+----+----+----+
Destination 1...N توصیف‌کننده‌های مقصد - شماره زیرشبکه IP و
ماسک زیرشبکه یک مقصد مشخص را با استفاده از
یک کدگذاری فشرده توصیف می‌کنند. این کدگذاری
شامل یک بایت است که طول ماسک زیرشبکه را
توصیف می‌کند، و به دنبال آن تمام بایت‌های
بااهمیت شماره زیرشبکه می‌آیند.
Router 1...N آدرس IP روتری که باید برای رسیدن به آن مقصد
استفاده شود.
*/
// نوع: internal
{
"code": 121,
// لطفاً به نمادگذاری مناسب استفاده‌شده توجه فرمایید:
// subnet1 - router1 IP addr, subnet2 - router2 IP addr, ..., subnetN - routerN IP addr
"data": "10.229.0.128/25 - 10.229.0.1, 10.198.122.47/32 - 10.198.122.1",
"name": "classless-static-route"
},
// کدهای گزینه 122-123 در Kea تعریف نشده‌اند.
/*
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ |
/ vendor-class-data1 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ | |
/ vendor-class-data2 / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
option-code OPTION_V-I_VENDOR_CLASS (124)
option-len طول کل تمام داده‌های گزینه بعدی بر حسب
بایت
enterprise-numberN شماره ۳۲ بیتی سازمانی سازنده طبق ثبت در
IANA [3]
data-lenN طول فیلد vendor-class-data
vendor-class-dataN جزئیات پیکربندی سخت‌افزاری میزبانی که
کلاینت روی آن اجرا می‌شود، یا سازگاری با
کنسرسیوم صنعتی
*/
// نوع: uint32، binary
{
"code": 124,
"data": "4491, 0f BA AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "vivco-suboptions"
},
/*
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ option-data1 |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ option-data2 | |
/ / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
option-code OPTION_V-I_VENDOR_OPTS (125)
option-len طول کل تمام داده‌های گزینه بعدی بر حسب
بایت
enterprise-numberN شماره ۳۲ بیتی سازمانی ثبت‌شده سازنده
طبق ثبت در IANA [3]
data-lenN طول فیلد option-data
option-dataN گزینه‌های مختص سازنده، که در زیر توضیح داده شده است
*/
// نوع: uint32
{
"code": 125,
"data": "4491",
"name": "vivso-suboptions"
},
// کدهای گزینه 126-127 تخصیص نیافته‌اند.
// کدهای گزینه 128-135 در Kea تعریف نشده‌اند.
/*
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PAA IPv4 Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
شکل 1: گزینه DHCPv4 مربوط به PAA
option-code: OPTION_PANA_AGENT (136).
option-length: طول فیلد 'options' بر حسب بایت؛
باید مضربی از چهار (4) باشد.
PAA IPv4 Address: آدرس IPv4 یک PAA برای استفاده کلاینت.
عوامل PAA به ترتیب اولویت برای استفاده توسط
کلاینت فهرست شده‌اند.
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 136,
"data": "192.0.2.66, 192.0.2.67",
"name": "pana-agent"
},
/*
Code Len LoST Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+----
| 137 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+----
*/
// نوع: FQDN
{
"code": 137,
"data": "lost.example.org",
"name": "v4-lost"
},
/*
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AC IPv4 Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_CAPWAP_AC_V4 (138)
option-length: طول فیلد 'options' بر حسب بایت؛ باید
مضربی از چهار (4) باشد.
AC IPv4 Address: آدرس IPv4 یک CAPWAP AC که WTP می‌تواند استفاده کند.
کنترل‌کننده‌های AC به ترتیب اولویت برای استفاده توسط WTP فهرست شده‌اند
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 138,
"data": "192.0.2.68, 192.0.2.69",
"name": "capwap-ac-v4"
},
// کدهای گزینه 139-140 در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 141 | Len | Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*/
// نوع: آرایه‌ای از {FQDN}
{
"code": 141,
"data": "example.com, example.org",
"name": "sip-ua-cs-domains"
},
// کد گزینه 142 در Kea تعریف نشده است.
/*
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code (143) | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. .
. bootstrap-server-list (variable length) .
. .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
option-code: OPTION_V4_SZTP_REDIRECT (143)
option-length: طول گزینه بر حسب بایت.
bootstrap-server-list: فهرستی از کارسازها برای کلاینت جهت
تلاش برای برقراری ارتباط، به منظور دریافت داده‌های راه‌اندازی
اولیه بیشتر. هر مدخل URI در bootstrap-server-list به
صورت زیر ساختاربندی شده است:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-length | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
uri-length: به طول ۲ بایت؛ طول داده‌های URI را مشخص می‌کند.
URI: شناسه URI مربوط به کارساز راه‌اندازی اولیه SZTP.
*/
// نوع: آرایه‌ای از {tuple}
{
"code": 143,
"data": "https://sztp1.example.com:8443, https://sztp2.example.com:8444",
"name": "v4-sztp-redirect"
},
// کدهای گزینه 144-145 در Kea تعریف نشده‌اند.
// نوع: uint8، IPv4 address، IPv4 address، آرایه‌ای از {FQDN}
{
"code": 146,
"data": "1, 192.0.2.70, 192.0.2.71, example.com, example.org",
"name": "rdnss-selection"
},
// کدهای گزینه 147-158 در Kea تعریف نشده‌اند.
// نوع: uint8، PSID
{
"code": 159,
"data": "2, 3/4",
"name": "v4-portparams"
},
// کدهای گزینه 160-161 تخصیص نیافته‌اند.
/*
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V4_DNR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DNR Instance Data #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
. ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional
~ DNR Instance Data #n ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
DNR Instance Data Format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNR Instance Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADN Length | |
+-+-+-+-+-+-+-+-+ |
~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | |
+-+-+-+-+-+-+-+-+ |
~ IPv4 Address(es) ~
| +-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ |
~Service Parameters (SvcParams) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code: OPTION_V4_DNR (162).
Length: نشان‌دهنده طول داده‌های محصور بر حسب بایت است.
DNR Instance Data: شامل داده‌های پیکربندی یک تحلیل‌گر رمزگذاری‌شده
DNS است. هنگامی که چندین تحلیل‌گر رمزگذاری‌شده DNS قرار است گنجانده شوند،
فیلد "DNR Instance Data" تکرار می‌شود.
DNR Instance Data Length: طول تمام داده‌های بعدی بر حسب بایت.
این فیلد زمانی که فقط یک ADN برای یک نمونه DNR ارائه شده باشد،
روی ('ADN Length' + 3) تنظیم می‌شود.
Service Priority: اولویت این نمونه در مقایسه با سایر
نمونه‌های DNR. این عدد صحیح ۱۶ بیتی بدون علامت مطابق با قواعد
مشخص‌شده در بخش 2.4.1 از [RFC9460] تفسیر می‌شود.
ADN Length: طول authentication-domain-name بر حسب بایت.
authentication-domain-name (variable length): نام دامنه احراز هویت
تحلیل‌گر رمزگذاری‌شده DNS. این فیلد مطابق با بخش 10 از
[RFC9915] قالب‌بندی می‌شود.
Addr Length: طول آدرس‌های IPv4 گنجانده‌شده بر حسب بایت. در صورت
وجود، باید مضربی از 4 باشد.
IPv4 Address(es) (variable length): نشان‌دهنده یک یا چند آدرس IPv4
برای دسترسی به تحلیل‌گر رمزگذاری‌شده DNS. هر دو نوع آدرس IPv4 خصوصی
و عمومی می‌توانند در این فیلد گنجانده شوند.
Service Parameters (SvcParams) (variable length): مجموعه‌ای از پارامترهای
سرویس را مشخص می‌کند که طبق قواعد بخش 2.2 از [RFC9460]
کدگذاری می‌شوند. طول این فیلد برابر است با:
('DNR Instance Data Length' - 4 - 'ADN Length' - 'Addr Length')).
توجه داشته باشید که فیلدهای "Addr Length"، "IPv4 Address(es)" و
"Service Parameters (SvcParams)" در صورت استفاده از حالت فقط-ADN وجود ندارند.
*/
// نوع: internal
{
// گزینه DNR ممکن است با استفاده از نمادگذاری مناسب پیکربندی شود. نمونه‌های DNR باید با نویسه خط لوله "|" از هم جدا شوند.
// برای هر نمونه DNR باید فیلدهایی که با ویرگول جدا شده‌اند ارائه شوند:
// - اولویت سرویس (اجباری)،
// - نام ADN (اجباری)،
// - آدرس(های) IP (اختیاری - اگر بیش از یکی باشد - باید با فاصله جدا شوند)
// - پارامترهای SvcParams (اختیاری - اگر بیش از یکی باشد - باید با فاصله جدا شوند؛
// برای ارائه بیش از یک alpn-id آن‌ها را با ویرگولی که با دو بک‌اسلش گریز داده شده است،
// مانند مثال زیر، از هم جدا کنید).
// نکته: هر زمان که لازم باشد نویسه خط لوله "|" به عنوان چیزی غیر از جداکننده استفاده شود،
// باید مانند ویرگول‌های گریز داده شده در فهرست alpn-ids، با دو بک‌اسلش گریز داده شود.
// بر اساس این پیکربندی، Kea گزینه را طبق RFC9463 کدگذاری خواهد کرد.
"code": 162,
"name": "v4-dnr",
"data": "1, resolver.example., 10.2.3.4 10.0.4.5, alpn=dot\\,doq\\,h2\\,h3 dohpath=/q{?dns} | 2, resolver.example., 10.0.5.6, alpn=dot port=8530 | 3, fooexp.resolver.example."
},
// کدهای گزینه 163-209 تخصیص نیافته‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_6RD | option-length | IPv4MaskLen | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address(es) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_6RD (212)
option-length طول گزینه DHCP بر حسب بایت (۲۲ بایت
با یک آدرس IPv4 رله مرزی یا BR).
IPv4MaskLen تعداد بیت‌های با مرتبه بالا که در تمام آدرس‌های
IPv4 مربوط به CE در یک دامنه 6rd معین یکسان هستند.
این مقدار می‌تواند هر مقداری بین 0 تا 32 باشد.
هر مقداری بزرگتر از 32 نامعتبر است.
6rdPrefixLen طول پیشوند IPv6 مربوط به پیشوند IPv6 ارائه‌دهنده سرویس
(SP) در 6rd بر حسب تعداد بیت. به منظور بررسی محدوده
توسط پردازش گزینه DHCP، حاصل‌جمع
(32 - IPv4MaskLen) + 6rdPrefixLen باید (MUST) کمتر
یا مساوی 128 باشد.
6rdBRIPv4Address یک یا چند آدرس IPv4 از رله(های) مرزی 6rd
(Border Relay) برای یک دامنه 6rd معین.
6rdPrefix پیشوند IPv6 ارائه‌دهنده سرویس در 6rd که به عنوان یک
آدرس IPv6 شانزده بایتی نمایش داده می‌شود. بیت‌های موجود
در پیشوند پس از تعداد بیت‌های 6rdPrefixlen رزرو شده‌اند
و فرستنده باید (MUST) آن‌ها را با صفر مقداردهی اولیه کرده و
گیرنده باید آن‌ها را نادیده بگیرد.
*/
// نوع: uint8، uint8، IPv6 address، آرایه‌ای از {IPv4 address}
{
"code": 212,
"data": "24, 96, 2001:db8::f001, 192.0.2.72, 192.0.2.73",
"name": "option-6rd"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Access Network Domain Name .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name (cont.) .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_V4_ACCESS_DOMAIN (213).
option-length: طول کل گزینه نام دامنه شبکه دسترسی
بر حسب بایت.
option-value: نام دامنه مرتبط با شبکه دسترسی،
کدگذاری‌شده طبق توضیحات بخش 3.1.
*/
// نوع: FQDN
{
"code": 213,
"data": "example.org",
"name": "v4-access-domain"
},
// کدهای گزینه 214-219 تخصیص نیافته‌اند.
// کدهای گزینه 220-221 در Kea تعریف نشده‌اند.
// کدهای گزینه 222-254 تخصیص نیافته‌اند.
/*
داده‌های گزینه سفارشی
*/
// برای تعاریف، "option-def" را در زیر ببینید.
{
"code": 1,
"name": "my-empty-option",
"space": "my-fancy-space"
},
{
"code": 224,
"data": "192.0.2.74, 3/4, 1, example.org, string",
"name": "my-lengthy-option",
"space": "my-fancy-space"
},
{
"code": 254,
"data": "127, 32767, 2147483647, 255, 65535, 4294967295, 192.0.2.75, 3/4, 1, example.org, string",
"name": "my-fancy-option",
"space": "my-fancy-space"
},
{
"code": 232,
"name": "my-encapsulating-option",
"space": "my-encapsulating-space"
}
],
/*
تعاریف گزینه‌های سفارشی
*/
// برای kea-dhcp4، تعاریف گزینه‌های سفارشی می‌توانند سراسری یا در یک کلاس
// کلاینت باشند.
"option-def": [
// فضای گزینه جدید امکان داشتن مجموعه‌ای جدید از کدهای گزینه را فراهم می‌کند.
// یک گزینه خالی نیازی به "data" در "option-data" ندارد.
// حضور آن باید برای راه‌اندازی رفتار سفارشی کافی باشد.
{
"array": false,
"code": 1,
"encapsulate": "",
"name": "my-empty-option",
"record-types": "",
"space": "my-fancy-space",
"type": "empty"
},
// یک نوع سفارشی دارای "type" تنظیم‌شده روی "record" است و تمام انواع داده (که
// باید بیش از یکی باشند، در غیر این صورت بهتر است مستقیماً از خود نوع استفاده کنید)
// در "record-types" مشخص می‌شوند. اگر "string" بخشی از آن‌ها باشد،
// باید آخرین مورد باشد.
{
"array": false,
"code": 224,
"encapsulate": "",
"name": "my-lengthy-option",
"record-types": "ipv4-address, psid, tuple, fqdn, string",
"space": "my-fancy-space",
"type": "record"
},
// شامل آرایه‌هایی از همه انواع به جز رشته‌ها، زیرا آرایه‌ای از رشته‌ها
// یک تعریف گزینه معتبر نیست.
{
"array": true,
"code": 254,
"encapsulate": "",
"name": "my-fancy-option",
"record-types": "int8, int16, int32, uint8, uint16, uint32, ipv4-address, psid, tuple, fqdn",
"space": "my-fancy-space",
"type": "record"
},
// می‌توان از یک فضای کپسوله‌ساز منفرد استفاده کرد. گزینه‌ای حاوی هر
// گزینه‌ای از فضای مذکور، اکنون با موفقیت توسط Kea باز خواهد شد.
{
"array": false,
"code": 232,
"encapsulate": "my-fancy-space",
"name": "my-encapsulating-option",
"record-types": "",
"space": "my-encapsulating-space",
"type": "empty"
}
],
"subnet4": [
/*
داده‌های گزینه DOCSIS3
*/
// سرآیندها همان‌طور که در CL-SP-CANN-DHCP-Reg-I16-200715 تعریف شده‌اند هستند.
// مقدار "space" باید صراحتاً به صورت "docsis3-v4" تعریف شود
{
"option-data": [
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CL_V4OPTION_ORO| option-len | req-opt-code-1| req-opt-code-2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code CL_V4OPTION_ORO (1).
option-len تعداد گزینه‌های درخواستی.
req-opt-code-n کد گزینه برای یک گزینه درخواست‌شده توسط کلاینت.
*/
// نوع: آرایه‌ای از {uint8}
{
"code": 1,
"data": "32, 42",
"name": "oro",
"space": "docsis3-v4"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option code | option-len | IPv4 address of TFTP server 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address of server 1 (cont.) | IPv4 address of TFTP server 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address of server 2 (cont.) | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. ... | IPv4 address of TFTP server n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address of server n (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option code CL_VV4OPTION_TFTP_SERVERS (2)
option len تعداد بایت‌ها برای آدرس‌های IPv4 کارساز TFTP (به میزان 4*n برای
n کارساز)
*/
// نوع: آرایه‌ای از {IPv4 address}
{
"code": 2,
"data": "192.0.2.76, 192.0.2.77",
"name": "tftp-servers",
"space": "docsis3-v4"
}
],
"id": 1,
"subnet": "192.0.2.0/24"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv4 در Kea است.
// این یک سناریوی پایه‌ای با یک زیرشبکه IPv4 پیکربندی‌شده است. این سناریو نشان
// می‌دهد که چگونه Kea را برای استفاده از backendهای مختلف جهت ذخیره‌سازی اجاره‌ها پیکربندی کنید:
// - memfile
// - MySQL
// - PostgreSQL
{ "Dhcp4":
{
// به Kea اعلام شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید نوع اجاره را مشخص کنیم. دقیقاً یک بخش lease-database
// باید وجود داشته باشد. مطمئن شوید که تنها یکی را از حالت کامنت خارج می‌کنید.
// ۱. backend از نوع memfile. اطلاعات اجاره‌ها در یک فایل متنی ساده CSV ذخیره خواهند شد.
// این ساده‌ترین backend برای استفاده است زیرا به هیچ وابستگی یا سرویس در حال اجرای
// اضافه‌ای نیاز ندارد.
// "lease-database": {
// "type": "memfile",
// "persist": true,
// "lfc-interval": 3600
// },
// ۲. backend از نوع MySQL. اجاره‌ها در پایگاه‌داده MySQL ذخیره خواهند شد. مطمئن شوید
// که فعال، در حال اجرا و به درستی مقداردهی اولیه شده است. برای جزئیات در مورد نحوه
// مقداردهی اولیه پایگاه‌داده، مستندات kea-admin را ببینید. تنها پارامترهای کاملاً
// مورد نیاز، type و name هستند. اگر سایر پارامترها مشخص نشوند، Kea فرض خواهد کرد
// که پایگاه‌داده روی localhost در دسترس است، برای اتصال نیازی به کاربر و گذرواژه نیست و
// مهلت زمانی ۵ ثانیه است. Kea برای استفاده از این backend باید با گزینه "-D mysql";
// کامپایل شده باشد.
// "lease-database": {
// "type": "mysql",
// "name": "keatest",
// "host": "localhost",
// "port": 3306,
// "user": "keatest",
// "password": "1234",
// "reconnect-wait-time": 3000, // بیان‌شده بر حسب میلی‌ثانیه
// "max-reconnect-tries": 3,
// "on-fail": "stop-retry-exit",
// "retry-on-startup": false,
// "connect-timeout": 3
// },
// از زمان Kea.2.7.4، کتابخانه قلاب libdhcp_mysql.so باید بارگذاری شود تا
// اجاره‌ها در backend پایگاه‌داده اجاره MySQL ذخیره شوند.
// مکان کتابخانه قلاب backend اجاره را مشخص کنید.
// {
// // کتابخانه قلاب backend اجاره MySQL که برای ذخیره‌سازی اجاره‌ها مورد نیاز است.
// "library": "libdhcp_mysql.so"
// },
// ۳. backend از نوع PostgreSQL. اجاره‌ها در پایگاه‌داده PostgreSQL ذخیره خواهند شد. مطمئن
// شوید که فعال، در حال اجرا و به درستی مقداردهی اولیه شده است. برای جزئیات در مورد
// نحوه مقداردهی اولیه پایگاه‌داده، مستندات kea-admin را ببینید. تنها پارامترهای کاملاً
// مورد نیاز، type و name هستند. اگر سایر پارامترها مشخص نشوند، Kea فرض خواهد کرد
// که پایگاه‌داده روی localhost در دسترس است، برای اتصال نیازی به کاربر و گذرواژه نیست و
// مهلت زمانی ۵ ثانیه است. Kea برای استفاده از این backend باید با گزینه "-D postgresql";
// کامپایل شده باشد.
// "lease-database": {
// "type": "postgresql",
// "name": "keatest",
// "host": "localhost",
// "port": 5432,
// "user": "keatest",
// "password": "1234",
// "reconnect-wait-time": 3000, // بیان‌شده بر حسب میلی‌ثانیه
// "max-reconnect-tries": 3,
// "on-fail": "stop-retry-exit",
// "retry-on-startup": false,
// "connect-timeout": 3
// },
// از زمان Kea.2.7.4، کتابخانه قلاب libdhcp_pgsql.so باید بارگذاری شود تا
// اجاره‌ها در backend پایگاه‌داده اجاره PostgreSQL ذخیره شوند.
// مکان کتابخانه قلاب backend اجاره را مشخص کنید.
// {
// // کتابخانه قلاب backend اجاره PostgreSQL که برای ذخیره‌سازی اجاره‌ها مورد نیاز است.
// "library": "libdhcp_pgsql.so"
// },
// نشانی‌ها با طول عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// زمان‌سنج‌های تجدید (renew) و اتصال مجدد (rebind) کامنت شده‌اند. این بدان معناست
// که گزینه‌های ۵۸ و ۵۹ به کلاینت ارسال نخواهند شد. در این حالت بر عهده کلاینت
// است که مقادیر تایمر را بر اساس RFC2131 انتخاب کند. برای ارسال این گزینه‌ها
// به کلاینت، زمان‌سنج‌ها را از حالت کامنت خارج کنید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. ما در اینجا تنها یک زیرشبکه داریم.
// به Kea اعلام می‌کنیم که این زیرشبکه مستقیماً از طریق رابط محلی در دسترس است.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id":1 ,
"subnet": "192.0.2.0/24",
"interface": "eth0"
}
],
// بخش زیر ثبت رویدادها (logging) را پیکربندی می‌کند. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// هدف این مثال، نمایش نحوه دسته‌بندی کلاینت‌ها است.
{ "Dhcp4":
{
// به Kea گفته شده است تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// بیایید از ساده‌ترین بک‌اند یعنی memfile استفاده کرده و مقادیر معقولی را
// برای زمان‌سنج‌ها به کار ببریم. آن‌ها ارتباطی با نمایش دسته‌بندی ندارند.
"lease-database": { "type": "memfile" },
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
// این فهرست چندین کلاس را تعریف می‌کند که بسته‌های ورودی می‌توانند به آن‌ها تخصیص یابند.
// یک بسته می‌تواند متعلق به صفر یا چند کلاس باشد.
"client-classes": [
// کلاس نخست تلاش می‌کند کل آدرس سخت‌افزاری را با یک مقدار خاص تطبیق دهد.
// تمام بسته‌های ورودی با آن آدرس MAC مقدار ویژه‌ای از گزینه را دریافت خواهند کرد.
// اگر میزبان‌های زیادی وجود دارند که نیازمند رفتار ویژه هستند، استفاده از رزروهای
// میزبان بسیار بهتر است. با این حال، ترفند زدن با آدرس‌های MAC ممکن است در برخی
// موارد مفید باشد؛ مثلاً با تطبیق OUI با مقادیر شناخته‌شده می‌توان سازندگان خاصی را شناسایی کرد.
{
"name": "special_snowflake",
"test": "pkt4.mac == 0x010203040506",
"option-data": [{
"name": "domain-name-servers",
"data": "127.0.0.1"
}]
},
// بیایید تمام پیام‌های ورودی DISCOVER (نوع پیام ۱) را در یک کلاس مجزا
// دسته‌بندی کنیم.
{
"name": "discovers",
"test": "pkt4.msgtype == 1"
},
// انتظار می‌رود کلاینت‌ها فیلد transaction-id را روی یک مقدار تصادفی تنظیم کنند.
// کلاینت‌هایی که آن را با 0 ارسال می‌کنند به احتمال زیاد معیوب هستند. بیایید آن‌ها
// را به همین شکل علامت‌گذاری کنیم.
{
"name": "broken",
"test": "pkt4.transid == 0"
},
// بیایید تلفن‌های VoIP را انتخاب کنیم. آن‌هایی که شناسه کلاس خود را به عنوان
// Aastra ارسال می‌کنند، باید متعلق به کلاس VoIP باشند. برای فهرستی از تمام گزینه‌ها،
// نشانی www.iana.org/assignments/bootp-dhcp-parameters را ببینید.
// در این کلاس خاص، می‌خواهیم مقادیر مشخصی از برخی فیلدهای DHCPv4 را
// تنظیم کنیم. اگر بسته ورودی با آزمون مطابقت داشته باشد، آن فیلدها در
// پاسخ‌های خروجی تنظیم خواهند شد.
// گزینه ۴۳ برای کپسوله‌سازی زیرگزینه در فضای aastra تعریف شده است.
{
"name": "VoIP",
"test": "substring(option[60].hex,0,6) == 'Aastra'",
"next-server": "192.0.2.254",
"server-hostname": "hal9000",
"boot-file-name": "/dev/null",
"option-def": [ {
"name": "vendor-encapsulated-options",
"code": 43,
"type": "empty",
"encapsulate": "aastra" } ]
}
],
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. برای برخی زیرشبکه‌ها کلاسی را تعریف کردیم
// که در آن زیرشبکه مجاز است. در صورت عدم تعیین، همه مجاز هستند. هنگامی
// که یک کلاس مشخص می‌شود، فقط بسته‌های متعلق به آن کلاس برای آن
// زیرشبکه مجاز خواهند بود.
"subnet4": [
// این مورد فقط برای دستگاه‌های VoIP است.
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"client-classes": [ "VoIP" ],
"interface": "eth0"
},
// این مورد هیچ client-class مشخصی ندارد، بنابراین همه مجاز
// به ورود هستند. هرچند، قوانین معمول انتخاب زیرشبکه همچنان اعمال می‌شوند.
// همچنین یک رزرو کلاس ایستا برای کلاینتی با آدرس MAC معادل
// 1a:1b:1c:1d:1e:1f وجود دارد. این کلاینت همواره به این کلاس
// اختصاص داده خواهد شد.
{
"pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ],
"id": 2,
"subnet": "192.0.3.0/24",
"reservations": [
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"client-classes": [ "VoIP" ]
} ],
"interface": "eth0"
},
// فهرست زیر یک زیرشبکه با استخرها را تعریف می‌کند. برای برخی استخرها
// کلاسی را تعریف کردیم که در آن استخر مجاز است. در صورت عدم تعیین،
// همه مجاز هستند. وقتی کلاسی مشخص شود، تنها بسته‌های متعلق
// به آن کلاس برای آن استخر مجاز خواهند بود.
{
"pools": [
// این مورد فقط برای دستگاه‌های VoIP است.
{
"pool": "192.0.4.1 - 192.0.4.200",
"client-classes": [ "VoIP" ]
},
// این مورد هیچ client-class مشخصی ندارد،
// بنابراین همه مجاز به ورود هستند.
{
"pool": "192.0.5.1 - 192.0.5.200"
} ],
"subnet": "192.0.4.0/23",
"id": 3,
"interface": "eth1"
}
],
// بخش زیر ثبت وقایع را پیکربندی می‌کند. فرض می‌شود که پیام‌هایی با حداقل
// سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv4 در Kea است.
// هدف این مثال، نمایش نحوه دسته‌بندی کلاینت‌ها با استفاده
// از قابلیت‌های پیشرفته است.
{ "Dhcp4":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// بیایید از ساده‌ترین بک‌اند یعنی memfile و مقادیر معقولی برای
// تایمرها استفاده کنیم. آن‌ها تاثیری در نمایش دسته‌بندی ندارند.
"lease-database": { "type": "memfile" },
"renew-timer": 1000,
"rebind-timer": 2000,
"valid-lifetime": 4000,
// این فهرست چندین کلاس را تعریف می‌کند که بسته‌های دریافتی می‌توانند به آن‌ها تخصیص یابند.
// یک بسته می‌تواند به صفر یا چند کلاس تعلق داشته باشد.
"client-classes": [
// این کلاس توسط زیرشبکه دوم در فهرست 'evaluate-additional-classes' گنجانده شده است،
// بنابراین 'only-in-additional-list' فعال است. این امر تضمین می‌کند که این کلاس
// تنها در صورت انتخاب زیرشبکه دوم ارزیابی خواهد شد. عبارت آزمایش مقدار true را برمی‌گرداند.
// توجه داشته باشید که وابستگی به کلاس VoIP امکان‌پذیر نیست زیرا هنوز
// تعریف نشده است.
{
"name": "second_subnet",
"only-in-additional-list": true,
"test": "member('ALL')",
"option-data": [{
"name": "domain-name-servers",
"data": "127.0.0.1"
}]
},
// بیایید تمام بسته‌های ورودی DISCOVER (نوع پیام ۱) را در یک کلاس
// جداگانه دسته‌بندی کنیم.
{
"name": "discovers",
"test": "pkt4.msgtype == 1"
},
// کلاینت‌ها باید فیلد transaction-id را روی یک مقدار تصادفی تنظیم کنند.
// کلاینت‌هایی که آن را با 0 ارسال می‌کنند به احتمال زیاد معیوب هستند. بیایید
// آن‌ها را به همین عنوان علامت‌گذاری کنیم.
{
"name": "broken",
"test": "pkt4.transid == 0"
},
// بیایید تلفن‌های VoIP را انتخاب کنیم. مواردی که شناسه کلاس خود را
// به عنوان Aastra ارسال می‌کنند، باید متعلق به کلاس VoIP باشند. برای فهرستی از تمام گزینه‌ها،
// به www.iana.org/assignments/bootp-dhcp-parameters مراجعه کنید.
// در این کلاس خاص، می‌خواهیم مقادیر مشخصی از برخی فیلدهای
// DHCPv4 را تنظیم کنیم. اگر بسته ورودی با آزمایش مطابقت داشته باشد،
// آن فیلدها در پاسخ‌های خروجی تنظیم خواهند شد.
// گزینه 43 برای کپسوله‌سازی زیرگزینه در فضای aastra تعریف شده است.
{
"name": "VoIP",
"test": "substring(option[60].hex,0,6) == 'Aastra'",
"next-server": "192.0.2.254",
"server-hostname": "hal9000",
"boot-file-name": "/dev/null",
"option-def": [ {
"name": "vendor-encapsulated-options",
"code": 43,
"type": "empty",
"encapsulate": "aastra" } ]
},
// هم یک تلفن VoIP (از طریق ارزیابی یا رزرو میزبان) و هم دارای یک رزرو
// میزبان است.
{
"name": "VoIP_host",
"test": "member('VoIP') and member('KNOWN')",
"server-hostname": "hal9001"
}
],
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. برای برخی زیرشبکه‌ها کلاسی را تعریف
// کرده‌ایم که در آن زیرشبکه مجاز است. در صورت عدم تعیین،
// همه مجاز هستند. هنگامی که یک کلاس مشخص می‌شود، تنها بسته‌های متعلق
// به آن کلاس برای آن زیرشبکه مجاز خواهند بود.
"subnet4": [
{
// این مورد فقط برای دستگاه‌های VoIP است.
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"client-classes": [ "VoIP" ],
"interface": "eth0"
},
// این مورد هیچ client-class مشخص‌شده‌ای ندارد، بنابراین همه
// مجاز هستند. با این حال، قوانین عادی انتخاب زیرشبکه همچنان اعمال می‌شوند.
// همچنین یک رزرو کلاس ایستا برای کلاینتی با آدرس مک
// 1a:1b:1c:1d:1e:1f وجود دارد. این کلاینت همیشه
// به این کلاس تخصیص خواهد یافت.
{
"pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ],
"id": 2,
"subnet": "192.0.3.0/24",
"reservations": [
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"client-classes": [ "VoIP" ]
} ],
"interface": "eth0",
"evaluate-additional-classes": [ "second_subnet" ]
},
// فهرست زیر یک زیرشبکه با استخرها را تعریف می‌کند. برای برخی استخرها
// کلاسی را مشخص کرده‌ایم که در آن استخر مجاز است. در صورت عدم تعیین،
// همه مجاز هستند. هنگامی که یک کلاس مشخص می‌شود، تنها بسته‌های متعلق
// به آن کلاس برای آن استخر مجاز خواهند بود.
{
"pools": [
{
// این مورد فقط برای دستگاه‌های VoIP است.
"pool": "192.0.4.1 - 192.0.4.200",
"client-classes": [ "VoIP" ]
},
// این مورد هیچ client-class مشخص‌شده‌ای ندارد، بنابراین همه
// مجاز هستند.
{
"pool": "192.0.5.1 - 192.0.5.200"
} ],
"id": 3,
"subnet": "192.0.4.0/23",
"interface": "eth1"
},
// این زیرشبکه به دو استخر برای کلاینت‌های ناشناخته و شناخته‌شده
// (یعنی دارای رزرو) تقسیم شده است. کلاس‌های توکار KNOWN و
// UNKNOWN در هنگام جستجوی رزرو میزبان تنظیم یا عدم‌تنظیم می‌شوند (اگر
// مقداری بازگردد KNOWN و اگر چیزی نیابد UNKNOWN) و کلاس‌های
// کلاینت وابسته به آن ارزیابی می‌شوند.
// این فرآیند پس از انتخاب زیرشبکه و پیش از تخصیص آدرس از
// استخرها رخ می‌دهد.
{
"pools": [
{
"pool": "192.0.8.100 - 192.0.8.200",
"client-classes": [ "UNKNOWN" ]
},
{
"pool": "192.0.9.100 - 192.0.9.200",
"client-classes": [ "KNOWN" ]
}
],
"id": 4,
"subnet": "192.0.8.0/23",
"reservations": [
{ "hw-address": "00:00:00:11:22:33", "hostname": "h1" },
{ "hw-address": "00:00:00:44:55:66", "hostname": "h4" },
{ "hw-address": "00:00:00:77:88:99", "hostname": "h7" },
{ "hw-address": "00:00:00:aa:bb:cc", "hostname": "ha" }
]
}
],
// بخش زیر پیکربندی گزارش‌گیری را انجام می‌دهد. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این فایل از کامنت‌های توکار (یعنی مواردی که در شیءهای پیکربندی گنجانده شده
// و در تحلیل لغوی حذف نمی‌شوند) استفاده می‌کند.
{ "Dhcp4":
{
// حوزه سراسری
"comment": "یک کارساز DHCPv4",
// در پیکربندی واسط
"interfaces-config": {
"comment": "استفاده از نویسه عمومی",
"interfaces": [ "*" ] },
// در تعاریف گزینه
"option-def": [ {
"comment": "یک تعریف گزینه",
"name": "foo",
"code": 100,
"type": "ipv4-address",
"space": "isc"
} ],
// در داده‌های گزینه
"option-data": [ {
"comment": "تنظیم مقدار گزینه",
"name": "dhcp-message",
"data": "ABCDEF0105",
"csv-format": false
} ],
// در کلاس‌های کلاینت
"client-classes": [
{
"comment": "تطابق با همه",
"name": "all",
"test": "'' == ''"
},
// البته کامنت‌ها اختیاری هستند
{
"name": "none"
},
// می‌توان یک کامنت و یک user-context مشخص کرد
{
"comment": "یک کامنت",
"name": "both",
"user-context": {
"version": 1
}
}
],
// در سوکت‌های کنترلی.
"control-sockets": [
{
"socket-type": "unix",
"socket-name": "kea4-ctrl-socket",
"user-context": { "comment": "کامنت غیرمستقیم" }
},
{
"comment": "سوکت کنترلی HTTP",
"socket-type": "http",
"socket-address": "::1",
"socket-port": 8004,
// در احراز هویت
"authentication": {
"comment": "احراز هویت پایه HTTP",
"type": "basic",
// در کلاینت‌های احراز هویت پایه HTTP
"clients": [ {
"user": "admin",
"password": "1234"
} ]
}
}
],
// در شبکه‌های مشترک
"shared-networks": [ {
"comment": "یک شبکه مشترک",
"name": "foo",
// در زیرشبکه‌ها
"subnet4": [
{
"comment": "یک زیرشبکه",
"subnet": "192.0.1.0/24",
"id": 100,
// در استخرها
"pools": [
{
"comment": "یک استخر",
"pool": "192.0.1.1-192.0.1.10"
}
],
// در رزروهای میزبان
"reservations": [
{
"comment": "یک رزرو میزبان",
"hw-address": "AA:BB:CC:DD:EE:FF",
"hostname": "foo.example.com",
// مجدداً در یک داده گزینه
"option-data": [ {
"comment": "یک گزینه در یک رزرو",
"name": "domain-name",
"data": "example.com"
} ]
}
]
}
]
} ],
// در dhcp ddns
"dhcp-ddns": {
"comment": "بدون DNS پویا",
"enable-updates": false
},
// در لاگرها
"loggers": [ {
"comment": "یک لاگر",
"name": "kea-dhcp4"
} ]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای سرور DHCPv4 در Kea است.
// این فایل نحوه فعال‌سازی Kea Configuration Backend با استفاده از MySQL را نشان می‌دهد.
// این پیکربندی نیازمند در دسترس بودن کتابخانه libdhcp_mysql.so و
// به صورت اختیاری کتابخانه قلاب libdhcp_cb_cmds.so است.
{ "Dhcp4":
{
// برچسب سرور (server tag) را برای configuration backend تنظیم می‌کند. این نمونه
// server1 نام‌گذاری خواهد شد. هر عنصر پیکربندی که برای
// "all" یا "server1" قابل اعمال باشد توسط این نمونه استفاده خواهد شد.
"server-tag": "server1",
// به Kea اعلام شده است که فقط روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// استفاده از بک‌اند پایگاه داده اجاره memfile.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// این پارامتر نحوه دسترسی سرور به پایگاه داده پیکربندی را کنترل می‌کند.
// در حال حاضر تنها دو نوع پایگاه داده در دسترس است - "mysql" و
// "postgresql".
// استفاده از "mysql" مستلزم بارگذاری کتابخانه قلاب libdhcp_mysql.so است.
// در صورت استفاده از "postgresql"، بارگذاری کتابخانه قلاب libdhcp_pgsql.so
// الزامی است.
"config-control": {
// فهرستی از بک‌اندهای پایگاه داده برای اتصال. در حال حاضر، این مقدار
// به یک بک‌اند منفرد محدود است.
"config-databases": [
{
"type": "mysql",
"reconnect-wait-time": 3000, // بیان‌شده به میلی‌ثانیه
"max-reconnect-tries": 3,
"name": "kea",
"user": "kea",
"password": "1234",
"host": "localhost",
"port": 3306
}
],
// دوره‌های زمانی بررسی پایگاه داده توسط سرور برای به‌روزرسانی‌های
// پیکربندی را کنترل می‌کند. تنظیم زیر بدین معناست که شناسایی و واکشی
// تغییرات پیکربندی توسط سرور تا حدود 20 ثانیه زمان خواهد برد.
"config-fetch-wait-time": 20
},
// این بخش یک سوکت کنترلی تعریف می‌کند. در صورت تعریف، Kea یک سوکت UNIX باز کرده
// و به دستورهای دریافتی گوش می‌دهد. برای جزئیات به بخش ۱۷ از
// Kea ARM مراجعه کنید.
"control-socket": {
"socket-type": "unix",
"socket-name": "kea4-ctrl-socket"
},
// کتابخانه‌های قلاب (hooks) که configuration backend را فعال می‌کنند بارگذاری می‌شوند.
"hooks-libraries": [
// کتابخانه libdhcp_mysql.so برای استفاده از MySQL Configuration
// Backend مورد نیاز است.
{
"library": "libdhcp_mysql.so"
}
// در صورت استفاده از PostgreSQL Configuration Backend، کتابخانه "libdhcp_pgsql.so"
// مورد نیاز است.
// {
// "library": "libdhcp_pgsql.so"
// }
// کتابخانه libdhcp_cb_cmds.so اختیاری است. این کتابخانه امکان مدیریت
// پیکربندی را در پایگاه داده فراهم می‌کند. اگر این کتابخانه بارگذاری نشود،
// پیکربندی می‌تواند مستقیماً با استفاده از ابزارهای موجودی که
// مستقیماً با پایگاه داده MySQL کار می‌کنند مدیریت شود.
// ,{
// "library": "libdhcp_cb_cmds.so"
// }
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی با
// حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند. در غیر این صورت، می‌توانید stderr، نام یک فایل
// یا 'syslog' را مشخص کنید که پیام‌های خروجی را از طریق syslog ذخیره می‌کند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
168u
kea4/dhcpv4-over-dhcpv6.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای سرور DHCPv4 مربوط به
// آزمایش‌های DHCPv4-over-DHCPv6 در Kea است.
{
// پیکربندی DHCPv4
"Dhcp4":
{
"interfaces-config": {
"interfaces": [ "eth0" ]
},
"lease-database": {
"type": "memfile",
"name": "kea-leases4.csv",
"lfc-interval": 3600
},
"valid-lifetime": 4000,
"subnet4": [
{
"id": 100,
"subnet": "10.10.10.0/24",
// پیشوند "4o6-" قبل از "interface" در اینجا فراموش نشود!
"4o6-interface": "eth0",
"4o6-subnet": "2001:db8:1:1::/64",
"pools": [ { "pool": "10.10.10.100 - 10.10.10.199" } ] }
],
// این گزینه پشتیبانی از DHCPv4-over-DHCPv6 را فعال می‌کند
"dhcp4o6-port": 786,
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "kea-dhcp4.log"
}
],
"severity": "DEBUG",
"debuglevel": 0
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این فایل نحوهٔ پیکربندی رزروهای سراسری میزبان را نشان می‌دهد.
// رزروهای سراسری با هیچ زیرشبکه‌ای مرتبط نیستند. آن‌ها صرف‌نظر از
// زیرشبکه‌ای که کلاینت DHCP به آن تعلق دارد تخصیص می‌یابند.
// رزروهای سراسری با استفاده از همان انواع شناسه‌های میزبان مربوط به
// رزروهای ویژهٔ زیرشبکه به کلاینت‌های DHCP تخصیص داده می‌شوند. این فایل
// شامل چندین مثال از رزروهای میزبان با استفاده از انواع شناسه‌های
// مختلف، مانند مک‌آدرس (MAC address)، شناسهٔ کلاینت و غیره است.
{ "Dhcp4":
{
// به Kea اعلام شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌دادهٔ مورد استفاده برای ذخیرهٔ اجاره‌ها را مشخص کنیم. تا ژوئن
// ۲۰۲۲، از سه پس‌بند پایگاه‌داده پشتیبانی می‌شود: MySQL ،PostgreSQL و
// پایگاه‌دادهٔ درون‌حافظه‌ای Memfile. ما از memfile استفاده خواهیم کرد زیرا
// به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// نشانی‌ها با طول‌عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// زمان‌سنج‌های renew و rebind کامنت شده‌اند. این بدان معناست که گزینه‌های
// ۵۸ و ۵۹ به کلاینت ارسال نخواهند شد. در این حالت انتخاب مقادیر زمان‌سنج
// مطابق با RFC2131 بر عهدهٔ کلاینت خواهد بود. برای ارسال این گزینه‌ها به کلاینت،
// زمان‌سنج‌ها را از حالت کامنت خارج کنید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// سامانهٔ Kea از رزروها بر اساس چندین نوع شناسهٔ مختلف پشتیبانی می‌کند:
// hw-address (نشانی سخت‌افزاری/MAC کلاینت)، duid (شناسهٔ DUID درج‌شده توسط
// کلاینت)، client-id (شناسهٔ کلاینت درج‌شده توسط کلاینت)، circuit-id
// (شناسهٔ مدار درج‌شده توسط عامل رله) و flex-id (شناسهٔ انعطاف‌پذیر
// موجود در صورت بارگذاری کتابخانهٔ قلاب flex_id). هنگامی که از Kea خواسته
// شود، می‌تواند تمام این انواع شناسه‌ها را بررسی کند، اما این کار مستلزم یک جست‌وجوی
// سنگین در پایگاه‌داده است. بنابراین از دیدگاه کارایی سودمند است که تنها از
// انواعی از رزرو استفاده شود که واقعاً در یک شبکهٔ مشخص به کار می‌روند.
// مثال زیر از دیدگاه کارایی بهینه نیست، اما قابلیت‌های رزرو میزبان را به
// خوبی نمایش می‌دهد. لطفاً از حداقل مجموعهٔ انواع شناسه‌های مورد استفاده در شبکهٔ خود استفاده کنید.
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid",
"client-id", "flex-id" ],
// این دستورالعمل به Kea اعلام می‌کند که رزروها سراسری هستند. توجه داشته باشید
// که این مورد می‌تواند در سطح shared network و/یا subnet نیز مشخص شود.
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را جست‌وجو کند یا خیر.
"reservations-global": true,
// مشخص می‌کند که آیا کارساز باید رزروهای درون زیرشبکه را جست‌وجو کند یا خیر.
"reservations-in-subnet": false,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام نشانی‌های رزروشده
// خارج از استخر (out-of-pool) هستند یا خیر.
// در صورتی که reservations-in-subnet برابر با false باشد، نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "shared-networks" و "subnet4" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// تعریف چندین رزرو سراسری میزبان.
"reservations": [
// این یک رزرو برای یک نشانی سخت‌افزاری/MAC مشخص است. این یک رزرو
// بسیار ساده است: فقط یک نشانی و نه چیز دیگر.
// توجه داشته باشید که رزرو نشانی‌ها در دامنهٔ سراسری توصیه نمی‌شود اما همچنان مجاز است:
// از آنجا که پیوند بین رزرو و زیرشبکه را از بین می‌برد، می‌تواند منجر به قرار گرفتن
// کلاینت در زیرشبکه‌ای متفاوت از زیرشبکه‌ای که نشانی به آن تعلق دارد شود.
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"ip-address": "192.0.2.201"
},
// این یک رزرو برای یک client-id مشخص است. همچنین نشان می‌دهد که این
// کلاینت یک hostname رزروشده دریافت خواهد کرد. یک hostname می‌تواند
// برای هر نوع شناسه‌ای تعریف شود، نه فقط client-id. مشخص کردن حداقل
// یک hostname یا یک نشانی الزامی است.
{
"client-id": "01:11:22:33:44:55:66",
"hostname": "special-snowflake"
},
// رزرو سوم بر اساس DUID است. این رزرو همچنین مقادیر گزینه‌های خاصی را برای
// این کلاینت به‌خصوص تعریف می‌کند. اگر گزینهٔ domain-name-servers در سطح سراسری،
// زیرشبکه یا کلاس تعریف شده بود، مقادیر اختصاصی میزبان برای این کلاینت خاص DHCP
// اولویت خواهند داشت.
{
"duid": "01:02:03:04:05",
"ip-address": "192.0.2.203",
"option-data": [ {
"name": "domain-name-servers",
"data": "10.1.1.202,10.1.1.203"
} ]
},
// رزرو چهارم بر اساس circuit-id است. این گزینه‌ای است که توسط عامل رله
// که بسته را از کلاینت به کارساز هدایت می‌کند، درج شده است.
// در این مثال گزینه‌های ویژهٔ سازنده (vendor specific) نیز به میزبان اختصاص یافته است.
{
"circuit-id": "01:11:22:33:44:55:66",
"ip-address": "192.0.2.204",
"option-data": [
{
"name": "vivso-suboptions",
"data": "4491"
},
{
"name": "tftp-servers",
"space": "vendor-4491",
"data": "10.1.1.202,10.1.1.203"
}
]
},
// این رزرو برای کلاینتی است که نیاز به تنظیم فیلدهای خاصی از DHCPv4 دارد.
// سه فیلد پشتیبانی‌شده عبارتند از next-server و server-hostname و
// boot-file-name
{
"client-id": "01:0a:0b:0c:0d:0e:0f",
"ip-address": "192.0.2.205",
"next-server": "192.0.2.1",
"server-hostname": "hal9000",
"boot-file-name": "/dev/null"
},
// این رزرو از یک شناسهٔ انعطاف‌پذیر (flexible identifier) استفاده می‌کند. به جای
// اتکا به یک فیلد خاص، مدیر سیستم می‌تواند عبارتی مشابه آنچه برای دسته‌بندی کلاینت
// استفاده می‌شود تعریف کند،
// مانند substring(relay[0].option[17],0,6). سپس بر اساس مقدار آن
// عبارت برای بستهٔ ورودی، رزرو مطابقت داده می‌شود. عبارت را می‌توان به صورت
// هگزادسیمال یا متن ساده با استفاده از علامت‌های نقل‌قول تکی مشخص کرد.
// نکته: برای کارکرد شناسهٔ انعطاف‌پذیر، بارگذاری کتابخانهٔ قلاب flex_id
// الزامی است.
{
"flex-id": "'s0mEVaLue'",
"ip-address": "192.0.2.206"
}
],
// تعریف یک زیرشبکه.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"interface": "eth0"
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی با
// دست‌کم سطح اطلاعاتی (info ،warn ،error و fatal) باید در stdout
// ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک پیکربندی نمونه از سرور Kea DHCPv4 است. این پیکربندی از کتابخانه
// قلاب High Availability و کتابخانه قلاب Lease Commands برای فعال‌سازی
// قابلیت High Availability برای سرور DHCP استفاده می‌کند. توجه داشته باشید
// که تقریباً دقیقاً همین پیکربندی باید روی سرور دوم (partner) استفاده شود.
// تنها تفاوت این است که "this-server-name" باید روی آن سرور دیگر
// برابر با "server2" تنظیم شود. همچنین، پیکربندی رابط و مکان فایل‌های
// مربوط به TLS به تنظیمات شبکه و پیکربندی آن ماشین خاص بستگی دارد.
//
// سرورهایی که از این پیکربندی استفاده می‌کنند در حالت load balancing کار می‌کنند.
{
// پیکربندی DHCPv4 از اینجا شروع می‌شود.
"Dhcp4": {
// نام‌های رابط‌های شبکه خود را برای شنود اضافه کنید.
"interfaces-config": {
// سرور DHCPv4 روی این رابط شنود می‌کند.
"interfaces": [ "eth0" ]
},
// پارامترهای Multi-threading.
"multi-threading": {
// به‌طور پیش‌فرض، اگر سخت‌افزار اجازه دهد Kea بسته‌ها را روی چندین نخ پردازش می‌کند.
"enable-multi-threading": true,
// هنگامی که چندنخی فعال باشد، Kea بسته‌ها را روی تعدادی نخ پردازش می‌کند
// که از طریق این گزینه قابل‌پیکربندی است.
"thread-pool-size": 4,
// هنگامی که چندنخی فعال است، Kea بسته‌ها را از رابط می‌خواند و
// یک مورد کاری را به استخر نخ‌ها اضافه می‌کند. این گزینه
// بیشینه تعداد مواردی را که می‌توانند صف‌بندی شوند پیکربندی می‌کند.
"packet-queue-size": 64
},
// از بک‌اند پایگاه داده اجاره Memfile برای ذخیره اجاره‌ها در یک فایل CSV استفاده کنید.
// بسته به نحوه کامپایل Kea، ممکن است از پایگاه‌های داده SQL نیز پشتیبانی کند
// (MySQL و/یا PostgreSQL). آن بک‌آندهای پایگاه داده به پارامترهای بیشتری
// مانند name ،host و احتمالاً user و password نیاز دارند.
// مثال‌های اختصاصی برای هر بک‌اند وجود دارد. برای جزئیات به بخش 7.2.2
// "Lease Storage" مراجعه کنید.
"lease-database": {
// بک‌اند Memfile ساده‌ترین و آسان‌ترین بک‌اند برای استفاده است. این یک [پایگاه داده] درون‌حافظه‌ای
"type": "memfile"
},
// کلاس‌های کلاینت، استخرهای آدرس را با سرورهای خاصی که در ارائه
// High Availability مشارکت دارند مرتبط می‌کنند.
"client-classes": [
// کلاس phones
{
"name": "phones",
"test": "substring(option[60].hex,0,6) == 'Aastra'"
},
// لپ‌تاپ‌ها همه چیز به جز تلفن‌ها هستند.
{
"name": "laptops",
"test": "not member('phones')"
},
// برخی از تلفن‌ها توسط server1 مدیریت خواهند شد. این که آیا HA_server1
// یا HA_server2 به کلاینت اختصاص یابد، به عهده load balancing
// انجام‌شده توسط کتابخانه قلاب HA است.
{
"name": "phones_server1",
"test": "member('phones') and member('HA_server1')"
},
// برخی از تلفن‌ها توسط server2 مدیریت خواهند شد.
{
"name": "phones_server2",
"test": "member('phones') and member('HA_server2')"
},
// برخی از لپ‌تاپ‌ها توسط server1 مدیریت خواهند شد.
{
"name": "laptops_server1",
"test": "member('laptops') and member('HA_server1')"
},
// برخی از لپ‌تاپ‌ها توسط server2 مدیریت خواهند شد.
{
"name": "laptops_server2",
"test": "member('laptops') and member('HA_server2')"
}
],
// قابلیت HA نیازمند بارگذاری دو کتابخانه قلاب است: libdhcp_lease_cmds.so و
// libdhcp_ha.so. اولی به‌روزرسانی‌های ورودی اجاره را از همتایان HA مدیریت می‌کند.
// دومی قابلیت دسترسی‌پذیری بالا را برای Kea پیاده‌سازی می‌کند.
"hooks-libraries": [
// کتابخانه lease_cmds باید بارگذاری شود زیرا HA از آن برای تحویل
// به‌روزرسانی‌های اجاره به سرور و همچنین همگام‌سازی پایگاه داده اجاره
// پس از خرابی استفاده می‌کند.
{
"library": "libdhcp_lease_cmds.so",
"parameters": { }
},
{
// کتابخانه قلاب HA باید بارگذاری شود.
"library": "libdhcp_ha.so",
"parameters": {
// پیکربندی High Availability برای کتابخانه قلاب HA مشخص می‌شود.
// هر سرور باید پیکربندی HA یکسانی داشته باشد، به جز پارامتر
// "this-server-name".
"high-availability": [ {
// این پارامتر به این نمونه سرور اشاره می‌کند. همتایان HA مربوطه
// باید این پارامتر را روی نام‌های خود تنظیم کنند.
"this-server-name": "server1",
// حالت HA روی load-balancing تنظیم شده است. در این حالت، سرورهای
// فعال ترافیک را به اشتراک می‌گذارند (50/50).
"mode": "load-balancing",
// در صورتی که هیچ دستور کنترلی دیگری ارسال نشود، ضربان قلب (Heartbeat)
// باید هر 10 ثانیه یک‌بار فرستاده شود.
"heartbeat-delay": 10000,
// بیشینه زمان برای پاسخ شریک به یک ضربان قلب، که پس از آن
// تشخیص خرابی آغاز می‌شود. این مقدار بر حسب میلی‌ثانیه مشخص می‌شود.
"max-response-delay": 60000,
// پارامترهای زیر نحوه تشخیص خرابی شریک توسط سرور را کنترل می‌کنند.
// تاخیر ACK آستانه‌ای را برای فیلد 'secs' در discovers دریافتی
// تعیین می‌کند. این مقدار بر حسب میلی‌ثانیه مشخص می‌شود.
"max-ack-delay": 5000,
// این گزینه تعداد کلاینت‌هایی را مشخص می‌کند که پیام‌هایی به شریک
// ارسال می‌کنند اما به نظر می‌رسد هیچ پاسخی دریافت نمی‌کنند.
"max-unacked-clients": 5,
// این گزینه بیشینه مهلت زمانی (بر حسب میلی‌ثانیه) را برای سرور جهت
// تکمیل همگام‌سازی مشخص می‌کند. اگر استقرار بزرگی دارید (ده‌ها یا
// صدها هزار کلاینت)، ممکن است نیاز باشد آن را بیشتر افزایش دهید.
// مقدار پیش‌فرض 60000 میلی‌ثانیه (60 ثانیه) است.
"sync-timeout": 60000,
// برای جلوگیری از افت کارایی زمانی که سرور Kea در حال پردازش بسته‌ها روی
// چندین نخ است، ماژول High Availability باید چندنخی فعال داشته باشد.
"multi-threading": {
// فعال‌سازی High Availability برای بهره‌مندی از چندنخی. پیش‌فرض: true.
"enable-multi-threading": true,
// هنگام اجرا در حالت MT، شنونده اختصاصی برای مدیریت به‌روزرسانی‌های اجاره استفاده می‌شود.
"http-dedicated-listener": true,
// تعداد نخ‌های مورد استفاده برای مدیریت درخواست‌های ورودی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد نخ‌هایی استفاده کند
// که هسته Kea برای چندنخی DHCP استفاده می‌کند.
"http-listener-threads": 0,
// تعداد نخ‌های مورد استفاده برای مدیریت درخواست‌های خروجی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد نخ‌هایی استفاده کند
// که هسته Kea برای چندنخی DHCP استفاده می‌کند.
"http-client-threads": 0
},
"peers": [
// این پیکربندیِ این نمونه سرور است.
{
"name": "server1",
// این گزینه URL این نمونه سرور را مشخص می‌کند.
"url": "http://192.168.56.33:8005/",
// تکیه‌گاه اعتماد (Trust anchor) معروف به فایل یا پوشه مرجع گواهی (CA).
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی کلاینت.
"cert-file": "/usr/lib/kea/server1_cert.pem",
// نام فایل کلید خصوصی.
"key-file": "/usr/lib/kea/server1_key.pem",
// گواهی‌های کلاینت الزامی بوده و تایید می‌شوند.
"require-client-certs": true,
// این سرور primary است. سرور دیگر باید
// secondary باشد.
"role": "primary"
},
// این پیکربندی همتای HA است.
{
"name": "server2",
// نشانی URL را مشخص می‌کند که کانال کنترلی
// شریک در آن قابل دسترس است.
"url": "http://192.168.56.66:8005/",
// تکیه‌گاه اعتماد (Trust anchor) معروف به فایل یا پوشه مرجع گواهی (CA).
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی کلاینت.
"cert-file": "/usr/lib/kea/server2_cert.pem",
// نام فایل کلید خصوصی.
"key-file": "/usr/lib/kea/server2_key.pem",
// گواهی‌های کلاینت الزامی بوده و تایید می‌شوند.
"require-client-certs": true,
// شریک، secondary است. این سرور primary است.
"role": "secondary"
}
]
} ]
}
}
],
// این مثال شامل تعریف یک زیرشبکه تکی است.
"subnet4": [
{
// شناسه زیرشبکه.
"id": 1,
// پیشوند زیرشبکه.
"subnet": "192.0.3.0/24",
// مشخص کردن چهار استخر آدرس.
"pools": [
{
"pool": "192.0.3.100 - 192.0.3.125",
"client-classes": [ "phones_server1" ]
},
{
"pool": "192.0.3.126 - 192.0.3.150",
"client-classes": [ "laptops_server1" ]
},
{
"pool": "192.0.3.200 - 192.0.3.225",
"client-classes": [ "phones_server2" ]
},
{
"pool": "192.0.3.226 - 192.0.3.250",
"client-classes": [ "laptops_server2" ]
}
],
// این‌ها گزینه‌های مخصوص زیرشبکه هستند. در بیشتر موارد،
// باید دست‌کم گزینه routers را تعریف کنید، زیرا بدون این
// گزینه، کلاینت‌های شما قادر به دسترسی به درگاه پیش‌فرض خود
// نبوده و اتصال به اینترنت نخواهند داشت.
"option-data": [
{
// برای هر زیرشبکه IPv4 به احتمال زیاد باید دست‌کم
// یک مسیریاب مشخص کنید.
"name": "routers",
"data": "192.0.3.1"
}
],
// این زیرشبکه برای پرس‌وجوهای ارسالی از آدرس IP زیر
// انتخاب خواهد شد.
"relay": { "ip-addresses": [ "192.168.56.1" ] }
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌ها با
// دست‌کم سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند. همچنین، می‌توانید stderr، یک نام فایل یا
// 'syslog' را اینجا مشخص کنید که پیام‌های خروجی را از طریق syslog ذخیره می‌کند.
"loggers": [
{
// این بخش بر kea-dhcp4 اثر می‌گذارد، که ثبت‌کننده پایه برای مؤلفه
// DHCPv4 است. این بخش به سرور DHCPv4 می‌گوید که تمام پیام‌های گزارش
// (با سطح اهمیت INFO یا بالاتر) را در یک فایل بنویسد.
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 0
},
{
// این بخش پیکربندی ثبت‌کننده اختصاصی کتابخانه قلاب HA را
// مشخص می‌کند.
"name": "kea-dhcp4.ha-hooks",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 99
}
]
}
}
168u
0.0
3.5
// این یک پیکربندی نمونه از سرور Kea DHCPv4 است. این پیکربندی از کتابخانه
// قلاب High Availability و کتابخانه قلاب Lease Commands برای فعال‌سازی
// قابلیت دسترسی‌پذیری بالا (High Availability) در سرور DHCP استفاده می‌کند.
// توجه داشته باشید که تقریباً دقیقاً همین پیکربندی باید در سرور دوم (همتا/partner)
// نیز استفاده شود. تنها تفاوت این است که "this-server-name" در آن سرور
// دیگر باید روی "server1" تنظیم شود. همچنین، پیکربندی رابط به تنظیمات
// شبکه آن ماشین خاص بستگی دارد.
//
// سرورهایی که از این پیکربندی استفاده می‌کنند در حالت توازن بار (load balancing) کار می‌کنند.
{
// پیکربندی DHCPv4 از اینجا آغاز می‌شود.
"Dhcp4": {
// نام‌های رابط‌های شبکه خود را برای شنود اضافه کنید.
"interfaces-config": {
// سرور DHCPv4 روی این رابط شنود می‌کند.
"interfaces": [ "eth0" ]
},
// پارامترهای چندریسمانی (Multi-threading).
"multi-threading": {
// به‌طور پیش‌فرض، Kea در صورت پشتیبانی سخت‌افزار، بسته‌ها را روی چندین ریسمان پردازش می‌کند.
"enable-multi-threading": true,
// هنگامی که چندریسمانی فعال باشد، Kea بسته‌ها را روی تعدادی ریسمان
// پردازش می‌کند که از طریق این گزینه قابل‌پیکربندی است.
"thread-pool-size": 4,
// هنگامی که چندریسمانی فعال باشد، Kea بسته‌ها را از رابط می‌خواند
// و یک مورد کاری به استخر ریسمان‌ها می‌افزاید. این گزینه
// بیشینه تعداد مواردی را که می‌توان در صف قرار داد پیکربندی می‌کند.
"packet-queue-size": 64
},
// استفاده از پشتیبان پایگاه‌داده اجاره Memfile برای ذخیره اجاره‌ها در یک فایل CSV.
// بسته به نحوه کامپایل Kea، ممکن است از پایگاه‌های داده SQL
// (مانند MySQL و/یا PostgreSQL) نیز پشتیبانی کند. این پشتیبان‌های پایگاه‌داده به پارامترهای
// بیشتری مانند name، host و احتمالاً user و password نیاز دارند.
// نمونه‌های اختصاصی برای هر پشتیبان وجود دارد. برای جزئیات به بخش 7.2.2 "Lease
// Storage" مراجعه کنید.
"lease-database": {
// پشتیبان Memfile ساده‌ترین و راحت‌ترین گزینه برای استفاده است. این یک پشتیبان درون‌حافظه‌ای
"type": "memfile"
},
// کلاس‌های کلاینت، استخرهای آدرس را با سرورهای خاصی که در ارائه
// High Availability مشارکت دارند مرتبط می‌کنند.
"client-classes": [
// کلاس phones
{
"name": "phones",
"test": "substring(option[60].hex,0,6) == 'Aastra'"
},
// لپ‌تاپ‌ها همه چیز هستند به جز تلفن‌ها.
{
"name": "laptops",
"test": "not member('phones')"
},
// برخی از تلفن‌ها توسط server1 مدیریت خواهند شد. این که HA_server1
// یا HA_server2 به کلاینت اختصاص یابد، مربوط به توازن بار
// (load balancing) انجام‌شده توسط کتابخانه قلاب HA است.
{
"name": "phones_server1",
"test": "member('phones') and member('HA_server1')"
},
// برخی از تلفن‌ها توسط server2 مدیریت خواهند شد.
{
"name": "phones_server2",
"test": "member('phones') and member('HA_server2')"
},
// برخی از لپ‌تاپ‌ها توسط server1 مدیریت خواهند شد.
{
"name": "laptops_server1",
"test": "member('laptops') and member('HA_server1')"
},
// برخی از لپ‌تاپ‌ها توسط server2 مدیریت خواهند شد.
{
"name": "laptops_server2",
"test": "member('laptops') and member('HA_server2')"
}
],
// قابلیت HA نیازمند بارگذاری دو کتابخانه قلاب است: libdhcp_lease_cmds.so و
// libdhcp_ha.so. اولی به‌روزرسانی‌های دریافتی اجاره را از همتایان HA مدیریت می‌کند.
// دومی قابلیت دسترسی‌پذیری بالا را برای Kea پیاده‌سازی می‌کند.
"hooks-libraries": [
// کتابخانه lease_cmds باید بارگذاری شود زیرا HA از آن برای تحویل
// به‌روزرسانی‌های اجاره به سرور و همچنین همگام‌سازی پایگاه‌داده
// اجاره پس از خرابی استفاده می‌کند.
{
"library": "libdhcp_lease_cmds.so",
"parameters": { }
},
{
// کتابخانه قلاب HA باید بارگذاری شود.
"library": "libdhcp_ha.so",
"parameters": {
// پیکربندی High Availability برای کتابخانه قلاب HA مشخص شده است.
// هر سرور باید پیکربندی HA یکسانی داشته باشد، به جز
// پارامتر "this-server-name".
"high-availability": [ {
// این پارامتر به این نمونه سرور اشاره می‌کند. همتایان مربوطه
// HA باید این پارامتر را روی نام‌های خود تنظیم کنند.
"this-server-name": "server2",
// حالت HA روی load-balancing تنظیم شده است. در این حالت، سرورهای
// فعال ترافیک را به اشتراک می‌گذارند (50/50).
"mode": "load-balancing",
// در صورتی که هیچ دستور کنترلی دیگری منتقل نشود، ضربان قلب (heartbeat)
// باید هر ۱۰ ثانیه یک بار ارسال شود.
"heartbeat-delay": 10000,
// حداکثر زمان برای پاسخ شریک به ضربان قلب، که پس از آن
// تشخیص خرابی آغاز می‌شود. این مقدار به میلی‌ثانیه مشخص شده است.
"max-response-delay": 60000,
// پارامترهای زیر نحوه تشخیص خرابی شریک توسط سرور را کنترل می‌کنند.
// تأخیر ACK آستانه را برای فیلد 'secs' در پیام‌های discover
// دریافتی تنظیم می‌کند. این مقدار به میلی‌ثانیه مشخص شده است.
"max-ack-delay": 5000,
// این پارامتر تعداد کلاینت‌هایی را مشخص می‌کند که به شریک
// پیام ارسال می‌کنند اما به نظر می‌رسد پاسخی دریافت نمی‌کنند.
"max-unacked-clients": 5,
// این پارامتر بیشینه مهلت زمانی (به میلی‌ثانیه) را برای تکمیل همگام‌سازی توسط
// سرور مشخص می‌کند. اگر استقرار بزرگی دارید (چندین ده یا صدها
// هزار کلاینت)، ممکن است نیاز به افزایش بیشتر آن داشته باشید.
// مقدار پیش‌فرض 60000ms (۶۰ ثانیه) است.
"sync-timeout": 60000,
// برای جلوگیری از افت کارایی در زمانی که سرور Kea بسته‌ها را
// روی چندین ریسمان پردازش می‌کند، ماژول High Availability باید
// قابلیت چندریسمانی را فعال کرده باشد.
"multi-threading": {
// فعال‌سازی High Availability برای بهره‌مندی از چندریسمانی. پیش‌فرض: true.
"enable-multi-threading": true,
// هنگام اجرا در حالت MT، از شنونده اختصاصی برای مدیریت
// به‌روزرسانی‌های اجاره استفاده می‌شود.
"http-dedicated-listener": true,
// تعداد ریسمان‌های مورد استفاده برای رسیدگی به درخواست‌های ورودی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسمانی استفاده کند
// که هسته Kea برای چندریسمانی DHCP استفاده می‌کند.
"http-listener-threads": 0,
// تعداد ریسمان‌های مورد استفاده برای رسیدگی به درخواست‌های خروجی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسمانی استفاده کند
// که هسته Kea برای چندریسمانی DHCP استفاده می‌کند.
"http-client-threads": 0
},
"peers": [
// این پیکربندی همتای HA است.
{
"name": "server1",
// نشانی URL را مشخص می‌کند که کانال کنترلی
// شریک روی آن در دسترس است.
"url": "http://192.168.56.33:8005/",
// شریک، اولیه (primary) است. این سرور ثانویه (secondary) است.
"role": "primary"
},
// این پیکربندی این نمونه سرور است.
{
"name": "server2",
// این گزینه نشانی URL این نمونه سرور را مشخص می‌کند.
"url": "http://192.168.56.66:8005/",
// این سرور ثانویه است. سرور دیگر باید
// اولیه باشد.
"role": "secondary"
}
]
} ]
}
}
],
// این نمونه شامل اعلان یک زیرشبکه تکی است.
"subnet4": [
{
// شناسه زیرشبکه.
"id": 1,
// پیشوند زیرشبکه.
"subnet": "192.0.3.0/24",
// تعیین چهار استخر آدرس.
"pools": [
{
"pool": "192.0.3.100 - 192.0.3.125",
"client-classes": [ "phones_server1" ]
},
{
"pool": "192.0.3.126 - 192.0.3.150",
"client-classes": [ "laptops_server1" ]
},
{
"pool": "192.0.3.200 - 192.0.3.225",
"client-classes": [ "phones_server2" ]
},
{
"pool": "192.0.3.226 - 192.0.3.250",
"client-classes": [ "laptops_server2" ]
}
],
// این‌ها گزینه‌های ویژه‌ی زیرشبکه هستند. در بیشتر موارد،
// باید دست‌کم گزینه routers را تعریف کنید، زیرا بدون این
// گزینه، کلاینت‌های شما قادر به دسترسی به دروازه پیش‌فرض خود
// نبوده و اتصال اینترنت نخواهند داشت.
"option-data": [
{
// برای هر زیرشبکه IPv4 به احتمال زیاد باید دست‌کم
// یک مسیریاب مشخص کنید.
"name": "routers",
"data": "192.0.3.1"
}
],
// این زیرشبکه برای پرس‌وجوهایی که از آدرس IP زیر می‌آیند
// انتخاب خواهد شد.
"relay": { "ip-addresses": [ "192.168.56.1" ] }
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌های با
// دست‌کم سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند. در غیر این صورت، می‌توانید stderr، نام یک فایل
// یا 'syslog' را مشخص کنید که پیام‌های خروجی را از طریق syslog ذخیره می‌کند.
"loggers": [
{
// این بخش بر kea-dhcp4 تأثیر می‌گذارد که گزارش‌گیر پایه برای مؤلفه
// DHCPv4 است. این بخش به سرور DHCPv4 می‌گوید که تمام پیام‌های گزارش را
// (با سطح بحرانی INFO یا بیشتر) در یک فایل بنویسد.
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 0
},
{
// این بخش پیکربندی گزارش‌گیر مخصوص کتابخانه قلاب HA را
// مشخص می‌کند.
"name": "kea-dhcp4.ha-hooks",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 99
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است
// که پیکربندی کتابخانه‌های قلاب RADIUS و Host Cache را شرح می‌دهد.
//
// این فایل برای استفاده به‌صورت مستقیم در نظر گرفته نشده است. بلکه تلاش می‌کند برخی از
// پارامترهای موجود را نمایش دهد.
//
// برای استفاده از این فایل پیکربندی، باید هر دو قلاب RADIUS و
// Host Cache را داشته باشید.
//
// کلاینت‌ها یک نام شراب (گزینه AOP با کد 250) دریافت می‌کنند که به قرمز و سفید تقسیم می‌شوند.
// برندهای گران‌قیمت دارای یک مدخل میزبان هستند، یعنی یک نشانی رزرو شده.
//
// نام‌ها
//
// brouilly (قرمز)
// chablis (سفید)
// chambertin (قرمز، گران‌قیمت)
// chinon (قرمز)
// chiroubles (قرمز)
// condrieu (سفید)
// cornas (قرمز)
// corton (قرمز)
// fleurie (قرمز)
// givry (قرمز)
// margaux (قرمز، گران‌قیمت)
// meursault (سفید)
// montrachet (سفید، گران‌قیمت)
// morgon (قرمز)
// muscadet (سفید)
// petrus (قرمز، گران‌قیمت)
// riesling (سفید)
// romanee (قرمز، گران‌قیمت)
// sylvaner (سفید)
// yquem (سفید، گران‌قیمت)
//
// فضای نشانی 192.0.2.0/24 است، با 10-99 برای قرمزها و 110-199 برای سفیدها.
//
// رزروها در اینجا به سبک Kea/JSON آورده شده‌اند اما باید
// در پیکربندی کارساز RADIUS قرار گیرند:
//
// {
// "flex-id": "'chambertin'",
// "ip-address": "192.0.2.10"
// },
// {
// "flex-id": "'margaux'",
// "ip-address": "192.0.2.11"
// },
// {
// "flex-id": "'petrus'",
// "ip-address": "192.0.2.12"
// },
// {
// "flex-id": "'romanee'",
// "ip-address": "192.0.2.13"
// },
// {
// "flex-id": "'montrachet'",
// "ip-address": "192.0.2.110"
// },
// {
// "flex-id": "'yquem'",
// "ip-address": "192.0.2.111"
// }
//
{"Dhcp4":
{
// به Kea گفته می‌شود که فقط روی رابط‌های مشخصی شنود کند.
"interfaces-config": {
// احتمالاً باید رابط‌های شبکه خود را در اینجا فهرست کنید (مانند "eth1961")
"interfaces": [ "eth1961" ]
},
// برپاسازی فضای ذخیره‌سازی برای اجاره‌ها (leases).
"lease-database": {
"type": "memfile"
},
// توجه کنید که هیچ hosts-databaseای تعریف نشده است. کتابخانه‌های RADIUS و Host Cache
// آن‌ها را به‌طور پویا ایجاد خواهند کرد.
// از آنجا که RADIUS از رزروهای flex-id استفاده می‌کند، Kea را فقط به استفاده از flex-id محدود کنید.
"host-reservation-identifiers": [ "flex-id" ],
// تعریف گزینه AOP.
"option-def": [ {
"name": "AOP",
"code": 250,
"type": "string" } ],
// تعریف کلاس‌های کلاینت قرمز و سفید.
// اگر تعریف نشوند ممکن است هشدارهای کاذب دریافت کنیم.
"client-classes": [
{ "name": "red" },
{ "name": "white" } ],
// تعریف یک زیرشبکه.
"subnet4": [ {
// تنظیم شناسه زیرشبکه (یا همان پورت RADIUS NAS).
"id": 14,
"subnet": "192.0.2.0/24",
"interface": "eth1961",
"pools": [
{
// استخر قرمز (10-19 برای رزروها هستند)
"pool": "192.0.2.20-192.0.2.99",
"client-classes": [ "red" ]
},
{
// استخر سفید (110-119 برای رزروها هستند)
"pool": "192.0.2.120-192.0.2.199",
"client-classes": [ "white" ]
}
// توجه داشته باشید که هیچ استخری برای استفاده همگان در دسترس نیست. این نکته
// مهمی است. بدین معنی که برای دریافت نشانی، کلاینت باید متعلق به کلاس قرمز،
// کلاس سفید بوده و یا نشانی رزرو شده داشته باشد.
]
} ],
// برپاسازی کتابخانه‌های قلاب.
"hooks-libraries": [
{
// بارگذاری کتابخانه قلاب flex-id.
"library": "libdhcp_flex_id.so",
"parameters": {
// دریافت شناسه از گزینه AOP.
"identifier-expression": "option[250].text",
// جایگزینی شناسه کلاینت در پرس‌وجوها با flex-id.
// در حال حاضر توسط کد دسترسی الزامی است.
// برای حسابرسی نیز لازم است زیرا به شناسه اجاره هم تبدیل می‌شود.
"replace-client-id": true
}
},
{
// بارگذاری کتابخانه قلاب host cache. این کتابخانه برای کتابخانه RADIUS
// مورد نیاز است تا مشخصه‌ها را از مرحله احراز هویت برای استفاده بعدی
// در حسابرسی نگه دارد.
"library": "libdhcp_host_cache.so"
},
{
// بارگذاری کتابخانه قلاب RADIUS.
"library": "libdhcp_radius.so",
"parameters": {
// در صورت عدم استفاده از RFC 4361
// "extract-duid": false,
// در صورت وجود زیرشبکه‌های دارای تداخل
// "reselect-subnet-pool": true,
// حذف نوع 0 اضافه شده توسط flex-id
"client-id-pop0": true,
// شناسه flex قابل چاپ باشد (برای پیکربندی کارساز RADIUS بسیار ساده‌تر است)
// بدون این گزینه، به صورت هگزادسیمال خواهد بود...
"client-id-printable": true,
// استفاده از flex-id.
"identifier-type4": "flex-id",
// پیکربندی یک کارساز دسترسی (یا همان احراز هویت/مجوزدهی).
"access": {
// این بخش فهرست کارسازهای دسترسی را آغاز می‌کند
"servers": [
{
// این‌ها پارامترهای اولین (و تنها) کارساز دسترسی هستند
"name": "127.0.0.1",
"port": 1812,
"secret": "1234"
}
// کارسازهای دسترسی دیگر را می‌توان در اینجا مشخص کرد
],
// این بخش فهرستی از مشخصه‌های اضافی را تعریف می‌کند که Kea در Access-Request
// به هر کارساز دسترسی ارسال خواهد کرد.
"attributes": [
{
// این مشخصه با نام شناسایی می‌شود (باید در فرهنگ لغت موجود باشد)
// و دارای مقدار ایستا است (یعنی مقدار یکسانی برای هر بسته به تمام
// کارسازها ارسال خواهد شد)
"name": "Password",
"data": "mysecretpassword"
},
{
// همچنین امکان تعیین یک مشخصه با استفاده از نوع آن به جای نام وجود دارد.
// نوع 77 همان Connect-Info است. مقدار با استفاده از hex مشخص شده است.
// مجدداً، این یک مقدار ایستا است. این مقدار برای هر بسته و برای هر
// کارساز یکسان ارسال خواهد شد.
"type": 77,
"raw": "65666a6a71"
},
{
// این مثال نشان می‌دهد چگونه می‌توان از یک عبارت برای ارسال مقدار
// پویا استفاده کرد. عبارت (بخش ۱۳ را ببینید) ممکن است هر مقداری را از
// بسته ورودی یا حتی فراداده آن (مثلاً رابطی که بسته از آن دریافت شده است)
// دریافت کند
"name": "Configuration-Token",
"expr": "pkt.iface"
}
] // پایان مشخصه‌ها
},
// پیکربندی یک کارساز حسابرسی.
"accounting": {
"servers": [ {
"name": "127.0.0.1",
"port": 1813,
"secret": "1234"
}
]
}
}
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است که از
// کتابخانه قلاب کنترل دسترسی بر پایه نقش (RBAC) استفاده می‌کند. این پیکربندی از سناریوی
// پایه‌ای یک زیرشبکه IPv4 پیکربندی‌شده با مقادیر پیش‌فرض برای تمام پارامترها استفاده می‌کند.
{"Dhcp4":
{
// به Kea اعلام شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// راه‌اندازی فضای ذخیره‌سازی برای اجاره‌ها.
"lease-database": {
"type": "memfile"
},
"valid-lifetime": 1800,
// تعریف یک زیرشبکه منفرد.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"interface": "eth0"
}
],
// سوکت‌های کنترلی.
"control-sockets": [
{
"socket-type": "https",
"socket-address": "127.0.0.1",
"socket-port": 8000,
"trust-anchor": "my-ca",
"cert-file": "my-cert",
"key-file": "my-key",
"cert-required": true
}
],
// قلاب‌ها را اینجا اضافه کنید.
"hooks-libraries": [
{
"library": "libdhcp_rbac.so",
"parameters": {
// این بخش کتابخانه قلاب RBAC را پیکربندی می‌کند.
// پارامترهای اجباری.
"assign-role-method": "cert-subject",
"api-files": "/opt/share/kea/api",
// پارامترهای اختیاری.
"require-tls": true,
"commands": [
{
"name": "my-command",
"access": "read",
"hook": "my-hook"
} ],
"access-control-lists": [
{
"my-none": { "not": "ALL" }
},{
"another-none": { "and": [ "ALL", "NONE" ] }
},{
"my-read": { "access": "read" }
} ],
"roles": [
{
"name": "kea-client",
"accept-commands":
{
"commands": [ "list-commands", "status-get" ]
},
"reject-commands": "NONE",
"other-commands": "reject",
"list-match-first": "accept",
"response-filters": [ "list-commands" ]
},{
"name": "admin",
"accept-commands": "ALL",
"reject-commands":
{
"hook": "cb_cmds"
},
"list-match-first": "reject"
} ],
"default-role":
{
"accept-commands": "NONE",
"reject-commands": "ALL"
},
"unknown-role":
{
"accept-commands": "READ",
"reject-commands": "WRITE"
}
}
}
]
}
}
168u
168u
kea4/hooks.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است که
// نحوه پیکربندی کتابخانه‌های قلاب را نمایش می‌دهد. این پیکربندی از سناریوی
// پایه‌ای یک زیرشبکه IPv4 پیکربندی‌شده با مقادیر پیش‌فرض برای تمام پارامترها استفاده می‌کند.
{"Dhcp4":
{
// به Kea اعلام شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// راه‌اندازی فضای ذخیره‌سازی برای اجاره‌ها.
"lease-database": {
"type": "memfile"
},
"valid-lifetime": 1800,
// تعریف یک زیرشبکه منفرد.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"interface": "eth0"
}
],
// راه‌اندازی کتابخانه‌های قلاب. برای این مثال، فرض می‌کنیم که دو کتابخانه
// به نام‌های "security" و "charging" بارگذاری شده‌اند. توجه داشته باشید که ترتیب مهم است:
// ابتدا "security" مشخص شده است، بنابراین اگر هر دو کتابخانه یک تابع قلاب را
// برای یک قلاب معین ارائه دهند، تابع موجود در "security" پیش از تابع موجود در
// "charging" فراخوانی خواهد شد.
"hooks-libraries": [
{
"library": "security.so"
},
{
"library": "charging.so",
"parameters": {
"path": "/var/log/kea",
"base-name": "kea-forensic6"
}
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv4 در Kea است.
// این فایل پارامترهای کنترل‌کننده پردازش اجاره‌های منقضی‌شده،
// یا همان بازپس‌گیری اجاره‌ها (leases reclamation) را فراهم می‌کند.
{ "Dhcp4":
{
// به Kea اعلام شده است که فقط روی واسط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن 2022، سه بک‌اند پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده می‌کنیم زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
// توجه داشته باشید که ما حداکثر تعداد خطاهای خواندن ردیف را روی 100 تنظیم می‌کنیم،
// (پیش‌فرض 0 است، به معنی نامحدود).
"lease-database": {
"type": "memfile",
"lfc-interval": 3600,
"max-row-errors": 100
},
// پارامترهای زیر پردازش اجاره‌های منقضی‌شده را کنترل می‌کنند. اجاره‌های
// منقضی‌شده به‌طور دوره‌ای مطابق با پارامتر "reclaim-timer-wait-time"
// بازپس‌گرفته خواهند شد. اجاره‌های بازپس‌گرفته‌شده برای تسهیل وابستگی اجاره
// (lease affinity) به مدت 1800 ثانیه در پایگاه‌داده نگه داشته می‌شوند. پس از این
// دوره، اجاره‌ها حذف خواهند شد. بسامد حذف توسط پارامتر
// "flush-reclaimed-timer-wait-time" کنترل می‌شود. روال بازپس‌گیری اجاره
// در یک اجرای تکی، حداکثر 500 اجاره را پردازش خواهد کرد یا حداکثر 100 میلی‌ثانیه
// طول خواهد کشید. اگر پس از 10 تلاش همچنان اجاره‌های بازپس‌گرفته‌نشده‌ای باقی مانده
// باشد، یک پیام هشدار صادر می‌شود.
// اگر هر دو پارامتر "flush-reclaimed-timer-wait-time" و "hold-reclaimed-time"
// مخالف 0 باشند، وقتی کلاینت پیام release ارسال کند، اجاره به جای حذف شدن از
// فضای ذخیره‌سازی اجاره‌ها، منقضی می‌شود.
"expired-leases-processing": {
"reclaim-timer-wait-time": 5,
"hold-reclaimed-time": 1800,
"flush-reclaimed-timer-wait-time": 10,
"max-reclaim-leases": 500,
"max-reclaim-time": 100,
"unwarned-reclaim-cycles": 10
},
// نشانی‌ها با طول عمر 4000 ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. ما اینجا تنها یک زیرشبکه
// داریم. به Kea می‌گوییم که این زیرشبکه مستقیماً روی واسط محلی در دسترس است.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"interface": "eth0"
}
],
// بخش زیر گزارش‌گیری (logging) را پیکربندی می‌کند. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout
// ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
168u
kea4/multiple-options.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv4 در Kea است.
// این فایل پیکربندی ساده گزینه‌ها را برای یک زیرشبکه نشان می‌دهد.
{ "Dhcp4":
{
// به Kea اعلام شده است که فقط روی واسط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن 2022، سه بک‌اند پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده می‌کنیم زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile"
},
// نشانی‌ها با طول عمر 4000 ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// زمان‌سنج‌های تجدید (renew) و پیوند مجدد (rebind) کامنت شده‌اند. این بدان معناست
// که گزینه‌های 58 و 59 به کلاینت ارسال نخواهند شد. در این حالت انتخاب مقادیر زمان‌سنج
// طبق RFC2131 بر عهده کلاینت است. برای ارسال این گزینه‌ها به کلاینت، زمان‌سنج‌ها را از
// حالت کامنت خارج کنید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// تعریف یک زیرشبکه. چند گزینه DHCP وجود دارد که به کلاینت‌های متصل
// به این زیرشبکه بازگردانده می‌شوند. دو گزینه اول با نام مشخص شده‌اند.
// گزینه سوم با کد گزینه (option code) مشخص شده است.
// یک استخر نشانی درون این زیرشبکه تعریف شده است. مقدار اختصاصی
// استخر برای گزینه domain-name-servers برای این استخر تعریف شده است.
"subnet4": [
{
"id": 1,
"subnet": "192.0.2.0/24",
"option-data": [
// هنگام تعیین گزینه‌ها، معمولاً باید یکی از (name یا code) و data را
// مشخص کنید. مشخصات کامل گزینه شامل name، code، space، csv-format و data است.
// مقدار پیش‌فرض space برابر "dhcp4" است که معمولاً درست است، مگر اینکه از
// گزینه‌های کپسوله‌شده استفاده کنید. مقدار پیش‌فرض csv-format برابر "true" است، بنابراین
// این نیز درست است، مگر اینکه بخواهید کل مقدار گزینه را به‌صورت یک رشته هگزادسیمال طولانی
// مشخص کنید. برای نمونه، برای تعیین domain-name-servers می‌توانید این کار را انجام دهید:
// {
// "name": "domain-name-servers",
// "code": 6,
// "csv-format": true,
// "space": "dhcp4",
// "data": "192.0.2.1, 192.0.2.2"
// }
// اما نوشتن آن طولانی است، بنابراین در عوض انجام این کار آسان‌تر است:
{
"name": "domain-name-servers",
"data": "192.0.2.1, 192.0.2.2"
},
// توجه داشته باشید که Kea برخی از گزینه‌ها را خود به خود فراهم می‌کند.
// به‌ویژه:
// - زمان اجاره نشانی IP (گزینه 51) توسط پارامتر valid-lifetime
// کنترل می‌شود، بنابراین نیازی نیست آن را به عنوان یک گزینه مشخص کنید.
// - ماسک زیرشبکه (گزینه 1) به‌طور خودکار از پارامتر subnet
// مشخص‌شده برای هر مدخل "subnet4" محاسبه می‌شود.
// - پارامتر renewal-timer (گزینه 58) از پارامتر renew-timer
// محاسبه می‌شود.
// - زمان‌سنج rebind (گزینه 59) از پارامتر rebind-timer
// محاسبه می‌شود.
// برای هر زیرشبکه IPv4 احتمالاً باید حداقل یک روتر (router)
// مشخص کنید.
{
"name": "routers",
"data": "192.0.2.1"
},
// معمولاً افراد ترجیح می‌دهند گزینه‌ها را با نام‌هایشان ارجاع دهند،
// تا نیازی به حفظ کردن شماره کدها نداشته باشند.
// با این حال، برخی تمایل دارند از مقادیر عددی استفاده کنند. برای
// نمونه، گزینه "domain-name" از کد گزینه 15 استفاده می‌کند، بنابراین
// می‌توانید با هر یک از
// "name": "domain-name" یا "code": 15 به آن ارجاع دهید.
{
"code": 15,
"data": "example.org"
},
// گزینه Domain search نیز یک گزینه پرکاربرد است. این گزینه به کلاینت
// می‌گوید که برای تحلیل نام‌ها در دامنه‌های مشخص‌شده تلاش کند. برای
// نمونه، برای تحلیل نام "foo" ابتدا به‌صورت
// foo.mydomain.example.com تلاش می‌شود و در صورت ناموفق بودن،
// به‌صورت foo.example.com بررسی خواهد شد.
{
"name": "domain-search",
"data": "mydomain.example.com, example.com"
},
// گزینه‌ها را می‌توان با قالب هگزادسیمال نیز مشخص کرد.
// در صورت امکان باید از این کار خودداری شود، زیرا توانایی Kea برای
// اعتبارسنجی صحت مقادیر هنگام استفاده از مقادیر هگز محدود است.
{
"name": "broadcast-address",
"csv-format": false,
"data": "ffff8000"
},
// گزینه‌های رشته‌ای که در مقدار خود کاما دارند باید گریز داده شوند
// (یعنی قبل از هر کاما دو بک‌اسلش قرار گیرد).
// این به این دلیل است که کاما برای جداسازی فیلدها در گزینه‌های ترکیبی
// رزرو شده است. در عین حال، باید با مشخصات JSON که "\," را مجاز
// نمی‌داند مطابقت داشته باشیم. بنابراین نمادگذاری تا حدی نامعمول
// با دو بک‌اسلش مورد نیاز است.
// توالی‌های گریز مجاز در JSON عبارتند از \ به همراه یکی از نویسه‌های "\/bfnrt
// یا \u به همراه 4 عدد هگزادسیمال (در حال حاضر Kea
// تنها از نقاط کدی \u0000 تا \u00ff پشتیبانی می‌کند).
// پردازش CSV صرفاً '\\' را به '\' و '\,' را به ','
// ترجمه می‌کند، بنابراین به عنوان مثال '\x' به '\x' تبدیل می‌شود. اما
// از آنجا که روی یک مقدار رشته‌ای JSON عمل می‌کند، هر یک از این نویسه‌های '\'
// در ورودی JSON باید دو برابر (تکرار) شوند.
{
"name": "boot-file-name",
"data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00"
},
// گزینه‌هایی که مقادیر عدد صحیح می‌گیرند را می‌توان در قالب ده‌دهی (dec)
// یا شانزده‌شانزدهی (hex) مشخص کرد. قالب هگز می‌تواند ساده (مانند abcd)
// یا با پیشوند 0x (مانند 0xabcd) باشد.
{
"name": "default-ip-ttl",
"data": "0xf0"
},
// به جز چند استثنا، گزینه‌ها تنها زمانی به پاسخ اضافه می‌شوند که
// کلاینت آنها را درخواست کند. پرچم always-send باید برای
// اجبار به ارسال یک گزینه خاص استفاده شود.
{
"name": "vendor-class-identifier",
"data": "isc",
"always-send": true
}
],
// اکنون استخرها را تعریف می‌کنیم. دو استخر در اینجا وجود دارد.
"pools": [ {
// این استخر اول است. مورد خاصی در اینجا نیست، صرفاً یک بازه
// از نشانی‌ها است.
"pool": "192.0.2.10 - 192.0.2.100"
}, {
// این استخر دوم جالب‌تر است. هر کس که نشانی‌ای از این استخر
// دریافت کند، در صورت درخواست پیکربندی کارگزارهای DNS، این مقدار
// خاص گزینه را نیز دریافت خواهد کرد. این مقدار، به دلیل خاص‌تر بودن،
// بر هر مقداری که در سطح سراسری (global) یا زیرشبکه تعیین شده باشد اولویت دارد.
"pool": "192.0.2.101 - 192.0.2.200",
"option-data": [
{
"name": "domain-name-servers",
"data": "192.0.2.3, 192.0.2.4"
}
]
} ]
} ],
// بخش زیر گزارش‌گیری (logging) را پیکربندی می‌کند. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout
// ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این فایل شامل پیکربندی پس‌دانه پایگاه‌داده میزبان MySQL است که برای
// بازیابی نشانی‌های رزرو شده، نام‌های میزبان، فیلدهای پیام DHCPv4
// و گزینه‌های DHCP از پایگاه‌داده MySQL استفاده می‌شود.
{ "Dhcp4":
{
// به Kea اعلام شده است که فقط روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها (leases) را مشخص کنیم. از
// ژوئن ۲۰۲۲، از سه پس‌دانه پایگاه‌داده پشتیبانی می‌شود: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده می‌کنیم زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// نشانی‌ها با طول‌عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// زمان‌سنج‌های تجدید (renew) و پیوند مجدد (rebind) کامنت شده‌اند. این بدان معناست که گزینه‌های
// ۵۸ و ۵۹ به کلاینت ارسال نخواهند شد. در این حالت انتخاب مقادیر زمان‌سنج بر عهده
// کلاینت طبق RFC2131 خواهد بود. برای ارسال این گزینه‌ها به کلاینت، کامنت
// زمان‌سنج‌ها را بردارید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// ‏Kea از رزروها بر اساس چندین نوع مختلف از شناسه‌ها پشتیبانی می‌کند:
// ‏hw-address (نشانی سخت‌افزاری/MAC کلاینت)، duid
// ‏(DUID درج‌شده توسط کلاینت)، client-id (شناسه کلاینت درج‌شده
// توسط کلاینت) و circuit-id (شناسه مدار درج‌شده توسط کارگزار
// رله). در صورت تنظیم، Kea می‌تواند همه آن انواع شناسه را بررسی کند، اما این
// کار مستلزم یک جستجوی هزینه‌بر در پایگاه‌داده است. بنابراین از دیدگاه کارایی،
// بهتر است فقط از انواع رزروی که واقعاً در یک شبکه استفاده می‌شوند، بهره برد.
// مثال زیر از دیدگاه کارایی بهینه نیست، اما به خوبی
// قابلیت‌های رزرو میزبان را نشان می‌دهد. لطفاً از حداقل مجموعه
// انواع شناسه‌های مورد استفاده در شبکه خود استفاده کنید.
"host-reservation-identifiers":
[ "circuit-id", "hw-address", "duid", "client-id" ],
// اتصال به پایگاه‌داده نگه‌دارنده رزروهای میزبان را مشخص کنید. گزینه type
// مشخص می‌کند که از پایگاه‌داده MySQL استفاده می‌شود. user و password اطلاعات
// ورود مورد استفاده برای اتصال به پایگاه‌داده هستند. host و name موقعیت
// میزبانی که نمونه پایگاه‌داده روی آن اجرا می‌شود و نام پایگاه‌داده مورد استفاده
// را مشخص می‌کنند. کارساز هنگام پردازش یک بسته ابتدا بررسی می‌کند که آیا رزروی
// برای این کلاینت در فهرست رزروها در زیرشبکه (فایل پیکربندی) مشخص شده است یا خیر.
// اگر رزروی در آنجا وجود نداشته باشد، کارساز تلاش خواهد کرد رزروها را
// از این پایگاه‌داده بازیابی کند.
"hosts-database": {
"type": "mysql",
"reconnect-wait-time": 3000, // برحسب میلی‌ثانیه
"max-reconnect-tries": 3,
"name": "keatest",
"user": "keatest",
"password": "1234",
"host": "localhost",
"port": 3306,
"trust-anchor": "my-ca",
"cert-file": "my-cert",
"key-file": "my-key",
"cipher-list": "AES"
},
// از نسخه Kea.2.7.4، کتابخانه قلاب libdhcp_mysql.so باید بارگیری شود تا
// بتوان رزروهای میزبان را در پس‌دانه پایگاه‌داده میزبان MySQL ذخیره کرد.
// موقعیت کتابخانه قلاب پس‌دانه میزبان را مشخص کنید.
"hooks-libraries": [
{
// کتابخانه قلاب پس‌دانه میزبان MySQL مورد نیاز برای ذخیره‌سازی میزبان.
"library": "libdhcp_mysql.so"
}
],
// تعریف یک زیرشبکه با یک استخر تک از نشانی‌های پویا. نشانی‌ها از
// این استخر به کلاینت‌هایی تخصیص می‌یابند که رزروی در پایگاه‌داده
// ندارند. شناسه زیرشبکه برابر ۱ است. اگر این زیرشبکه برای
// کلاینت انتخاب شود، این شناسه برای جستجوی رزروها
// درون پایگاه‌داده استفاده خواهد شد.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"interface": "eth0",
"id": 1
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض می‌شود که پیام‌ها با حداقل
// سطح اطلاعاتی (info، warn، error و fatal) باید
// در stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این پیکربندی شامل تنظیمات پس‌دسته پایگاه‌داده میزبان PostgreSQL است که برای
// بازیابی نشانی‌های رزرو شده، نام‌های میزبان، فیلدهای پیام DHCPv4
// و گزینه‌های DHCP از پایگاه‌داده PostgreSQL استفاده می‌شود.
{ "Dhcp4":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. از
// ژوئن ۲۰۲۲، سه پس‌دسته پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد چون به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile"
},
// نشانی‌ها با طول‌عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// زمان‌سنج‌های تجدید (renew) و اتصال مجدد (rebind) کامنت شده‌اند. این بدان معناست که گزینه‌های
// ۵۸ و ۵۹ به کلاینت ارسال نخواهند شد. در این حالت بر عهده کلاینت است
// که مقادیر زمان‌سنج را بر اساس RFC2131 انتخاب کند. برای ارسال این گزینه‌ها
// به کلاینت، کامنت زمان‌سنج‌ها را بردارید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// کارساز Kea از رزروها بر پایه چندین نوع شناسه گوناگون پشتیبانی می‌کند:
// hw-address (نشانی سخت‌افزاری/MAC کلاینت)، duid
// (شناسه DUID درج شده توسط کلاینت)، client-id (شناسه کلاینت درج شده
// توسط کلاینت) و circuit-id (شناسه مدار درج شده توسط کارگزار رله).
// در صورت تنظیم، Kea می‌تواند همه این انواع شناسه را بررسی کند،
// اما این کار مستلزم جست‌وجوی هزینه‌بر در پایگاه‌داده است. بنابراین،
// از دیدگاه کارایی بهتر است تنها از انواعی از رزرو استفاده شود
// که واقعاً در شبکه مربوطه استفاده می‌شوند.
// مثال زیر از دیدگاه کارایی بهینه نیست، اما به خوبی قابلیت‌های
// رزرو میزبان را نشان می‌دهد. لطفاً حداقل مجموعه از انواع شناسه‌های مورد نیاز
// در شبکه خود را به کار ببرید.
"host-reservation-identifiers":
[ "circuit-id", "hw-address", "duid", "client-id" ],
// مشخص کردن اتصال به پایگاه‌داده نگه‌دارنده رزروهای میزبان. پارامتر type
// مشخص می‌کند که از پایگاه‌داده PostgreSQL استفاده می‌شود. user و password اطلاعات کاربری
// مورد استفاده برای اتصال به پایگاه‌داده هستند. host و name مکان میزبانی
// که نمونه پایگاه‌داده روی آن در حال اجراست و نام پایگاه‌داده مورد استفاده را مشخص می‌کنند.
// کارساز هنگام پردازش یک بسته، ابتدا بررسی می‌کند که آیا رزروی برای این کلاینت در فهرست
// رزروهای درون زیرشبکه (فایل پیکربندی) مشخص شده است یا خیر. اگر رزروی در آنجا وجود نداشته باشد،
// کارساز تلاش خواهد کرد تا رزروها را از این پایگاه‌داده بازیابی کند.
// مشخصات پایگاه‌داده می‌تواند برای سازگاری با نسخه‌های پیشین درون یک مدخل hosts-database قرار گیرد
// یا اینکه در فهرست hosts-databases فهرست شود.
"hosts-databases": [
{
"type": "postgresql",
"reconnect-wait-time": 3000, // بر حسب میلی‌ثانیه
"max-reconnect-tries": 3,
"name": "keatest",
"user": "keatest",
"password": "1234",
"host": "localhost"
}
],
// از نسخه Kea 2.7.4 به بعد، کتابخانه قلاب libdhcp_pgsql.so باید بارگیری شود
// تا بتوان رزروهای میزبان را در پس‌دسته پایگاه‌داده میزبان PostgreSQL ذخیره کرد.
// مکان کتابخانه قلاب پس‌دسته میزبان را مشخص کنید.
"hooks-libraries": [
{
// کتابخانه قلاب پس‌دسته میزبان PostgreSQL مورد نیاز برای ذخیره‌سازی میزبان.
"library": "libdhcp_pgsql.so"
}
],
// تعریف یک زیرشبکه با یک استخر تک از نشانی‌های پویا. نشانی‌ها از
// این استخر به کلاینت‌هایی اختصاص می‌یابند که در پایگاه‌داده رزروی ندارند.
// شناسه زیرشبکه برابر ۱ است. اگر این زیرشبکه برای کلاینت انتخاب شود،
// از این شناسه زیرشبکه برای جست‌وجوی رزروها در پایگاه‌داده استفاده خواهد شد.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"interface": "eth0",
"id": 1
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض می‌شود که پیام‌های دارای
// حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
168u
kea4/reservations.json
0.0
3.5
// این یک پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// شامل یک زیرشبکه است که در آن دو رزرو نشانی ایستا برای کلاینت‌های شناسایی‌شده
// با نشانی‌های MAC وجود دارد.
{ "Dhcp4":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. از آوریل
// ۲۰۲۲، سه پس‌دسته پایگاه‌داده پشتیبانی می‌شوند: MySQL، PostgreSQL و
// پایگاه‌داده درون‌حافظه‌ای Memfile. ما از memfile استفاده خواهیم کرد چون
// به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// نشانی‌ها با طول‌عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// زمان‌سنج‌های تجدید (renew) و اتصال مجدد (rebind) کامنت شده‌اند. این بدان معناست که گزینه‌های
// ۵۸ و ۵۹ به کلاینت ارسال نخواهند شد. در این حالت بر عهده کلاینت است
// که مقادیر زمان‌سنج را بر اساس RFC2131 انتخاب کند. برای ارسال این گزینه‌ها
// به کلاینت، کامنت زمان‌سنج‌ها را بردارید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// کارساز Kea از رزروها بر پایه چندین نوع شناسه گوناگون پشتیبانی می‌کند:
// hw-address (نشانی سخت‌افزاری/MAC کلاینت)، duid (شناسه DUID درج شده توسط
// کلاینت)، client-id (شناسه کلاینت درج شده توسط کلاینت)، circuit-id
// (شناسه مدار درج شده توسط کارگزار رله) و flex-id (شناسه انعطاف‌پذیر
// موجود در صورت بارگیری کتابخانه قلاب flex_id). در صورت تنظیم، Kea می‌تواند
// همه این انواع شناسه را بررسی کند، اما این کار مستلزم جست‌وجوی هزینه‌بر
// در پایگاه‌داده است. بنابراین، از دیدگاه کارایی بهتر است تنها از انواعی از رزرو
// استفاده شود که واقعاً در شبکه مربوطه استفاده می‌شوند.
// مثال زیر از دیدگاه کارایی بهینه نیست، اما به خوبی قابلیت‌های
// رزرو میزبان را نشان می‌دهد. لطفاً حداقل مجموعه از انواع شناسه‌های مورد نیاز
// در شبکه خود را به کار ببرید.
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid",
"client-id", "flex-id" ],
// تعریف یک زیرشبکه با چهار رزرو. برخی از رزروها متعلق به استخر پویا هستند.
// کارساز Kea توانایی مدیریت این حالت را دارد، اما از دیدگاه کارایی توصیه نمی‌شود،
// زیرا Kea نه تنها باید آزاد بودن یک نشانی مشخص را بررسی کند، بلکه باید رزرو بودن
// آن را نیز بررسی نماید. برای جلوگیری از این بررسی، می‌توان "reservations-out-of-pool"
// را برابر true قرار داد، علاوه بر "reservations-in-subnet" که آن نیز باید برابر true
// باشد. اگر یک زیرشبکه اصلاً هیچ رزروی نداشته باشد، با قرار دادن "reservations-in-subnet"
// روی false می‌توان جست‌وجوی رزرو را به‌طور کامل نادیده گرفت.
// توجه داشته باشید که رزرو دوم برای نشانی‌ای است که در محدوده استخر
// نشانی‌های تخصیص‌یافته به صورت پویا قرار دارد. کارساز این نشانی را از این استخر مستثنی
// خواهد کرد و آن را تنها به کلاینتی که برای آن رزرو دارد اختصاص می‌دهد.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"interface": "eth0",
// این دستور به Kea اعلام می‌کند که رزروها ممکن است هم درون‌استخر (in-pool)
// و هم خارج‌از‌استخر (out-of-pool) انجام شوند. برای بهبود کارایی، می‌توانید تمام رزروها
// را به خارج از استخر پویا منتقل کرده و "reservations-out-of-pool" را برابر true قرار دهید.
// در این صورت Kea هنگام تخصیص اجاره‌ها از استخر پویا، می‌تواند از جست‌وجوی
// رزروهای میزبان صرف‌نظر کند.
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را جست‌وجو کند یا خیر.
// پیش‌فرض false است.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون زیرشبکه را جست‌وجو کند یا خیر.
// پیش‌فرض true است.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام نشانی‌های رزروشده خارج‌از‌استخر
// هستند یا خیر. پیش‌فرض false است.
// در صورت false بودن reservations-in-subnet نادیده گرفته می‌شود.
// در صورت تعیین، در سطوح "shared-networks" و
// "subnet4" به ارث برده می‌شود.
"reservations-out-of-pool": false,
"reservations": [
// این رزروی برای یک نشانی سخت‌افزاری/MAC مشخص است. این یک رزرو بسیار
// ساده است: تنها یک نشانی و نه چیز دیگر.
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"ip-address": "192.0.2.201"
},
// این رزروی برای یک client-id مشخص است. همچنین نشان می‌دهد
// که این کلاینت یک نام میزبان رزروشده دریافت خواهد کرد. نام میزبان را می‌توان
// برای هر نوع شناسه‌ای تعریف کرد، نه فقط client-id.
{
"client-id": "01:11:22:33:44:55:66",
"ip-address": "192.0.2.202",
"hostname": "special-snowflake"
},
// رزرو سوم بر پایه DUID است. این رزرو همچنین مقادیر گزینه ویژه‌ای را
// برای این کلاینت خاص تعریف می‌کند. اگر گزینه domain-name-servers در سطح سراسری،
// زیرشبکه یا کلاس تعریف شده باشد، مقادیر ویژه این میزبان اولویت خواهند داشت.
{
"duid": "01:02:03:04:05",
"ip-address": "192.0.2.203",
"option-data": [ {
"name": "domain-name-servers",
"data": "10.1.1.202,10.1.1.203"
} ]
},
// رزرو چهارم بر پایه circuit-id است. این گزینه‌ای است که توسط کارگزار رله
// که بسته را از کلاینت به کارساز بازمی‌فرستد درج می‌شود.
// در این مثال به میزبان گزینه‌های ویژه شرکت سازنده نیز اختصاص داده شده است.
{
"circuit-id": "01:11:22:33:44:55:66",
"ip-address": "192.0.2.204",
"option-data": [
{
"name": "vivso-suboptions",
"data": "4491"
},
{
"name": "tftp-servers",
"space": "vendor-4491",
"data": "10.1.1.202,10.1.1.203"
}
]
},
// این رزرو برای کلاینتی است که نیاز به تنظیم فیلدهای مشخصی از DHCPv4 دارد.
// سه فیلد پشتیبانی‌شده عبارتند از next-server، server-hostname و
// boot-file-name
{
"client-id": "01:0a:0b:0c:0d:0e:0f",
"ip-address": "192.0.2.205",
"next-server": "192.0.2.1",
"server-hostname": "hal9000",
"boot-file-name": "/dev/null"
},
// این رزرو از شناسه انعطاف‌پذیر استفاده می‌کند. مدیر سیستم به جای اتکا
// به فیلدی مشخص، می‌تواند عبارتی مشابه آنچه برای رده‌بندی کلاینت به کار می‌رود
// تعریف کند، به عنوان مثال: substring(relay[0].option[17],0,6). سپس، بر اساس مقدار
// آن عبارت برای بسته ورودی، رزرو تطبیق داده می‌شود.
// عبارت می‌تواند به صورت هگزادسیمال یا متن ساده با استفاده از نقل‌قول تکی
// مشخص شود.
// نکته: شناسه انعطاف‌پذیر برای کارکرد نیازمند بارگیری کتابخانه قلاب flex_id
// است.
{
"flex-id": "'s0mEVaLue'",
"ip-address": "192.0.2.206"
}
]
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض می‌شود که پیام‌های دارای
// حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این سناریویی پایه‌ای با سه زیرشبکه IPv4 پیکربندی‌شده است. در هر
// زیرشبکه، یک استخر کوچک‌تر از آدرس‌های پویا وجود دارد.
{ "Dhcp4":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن ۲۰۲۲، سه پسانه پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده می‌کنیم زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile"
},
// آدرس‌ها با طول عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
// به کلاینت گفته می‌شود که پس از ۱۰۰۰ ثانیه تمدید را آغاز کند. اگر کارساز
// تا ۲۰۰۰ ثانیه پس از اعطای اجاره پاسخ ندهد، کلاینت باید
// فرآیند REBIND (تمدید اضطراری که امکان جابه‌جایی به یک
// کارساز دیگر را فراهم می‌کند) را آغاز کند.
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// استاندارد RFC6842 بیان می‌کند که کارساز باید گزینه client-id را بازتاب (echo) دهد.
// با این حال، برخی کلاینت‌های قدیمی‌تر از این پشتیبانی نمی‌کنند و زمانی
// که client-id خود را دریافت می‌کنند سردرگم می‌شوند. Kea می‌تواند پشتیبانی از RFC6842 را غیرفعال کند.
"echo-client-id": false,
// برخی کلاینت‌ها از شناسه کلاینت پایدار استفاده نمی‌کنند، بلکه آن را هنگام
// هر راه‌اندازی تولید می‌کنند. این امر ممکن است باعث شود کلاینتی که مکرراً راه‌اندازی می‌شود
// چندین اجاره دریافت کند، که ممکن است مطلوب نباشد. از این رو، گاهی مدیران
// ترجیح می‌دهند به کارساز DHCPv4 خود بگویند که مقدار client-id را کاملاً نادیده بگیرد
// و منحصراً به آدرس MAC اتکا کند. این پارامتری است که به‌صورت
// سراسری تعریف می‌شود، اما می‌تواند در سطح زیرشبکه بازنویسی شود.
"match-client-id": true,
// به‌طور پیش‌فرض، Kea درخواست‌های کلاینت‌ها برای آدرس‌های IP نامشخص را نادیده می‌گیرد،
// زیرا کارسازهای DHCP غیرهمکار دیگری ممکن است در همان
// شبکه حضور داشته باشند (RFC 2131). این پارامتر به‌صورت سراسری تعریف می‌شود، اما می‌تواند
// در سطح زیرشبکه بازنویسی شود
"authoritative": false,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// مدخل‌های subnet و pool است.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24"
},
{
// این زیرشبکه خاص مقدار match-client-id تغییریافته دارد.
"pools": [ { "pool": "192.0.3.100 - 192.0.3.200" } ],
"id": 2,
"subnet": "192.0.3.0/24",
"match-client-id": false
},
{
"pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ],
"id": 3,
"subnet": "192.0.4.0/24"
} ],
// بخش زیر ثبت وقایع را پیکربندی می‌کند. فرض بر این است که پیام‌هایی با
// حداقل سطح اطلاعاتی (info،‏ warn،‏ error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
168u
kea4/shared-network.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این فایل ویژگی پیشرفته‌ای به نام شبکه اشتراکی (shared network) را نشان می‌دهد. معمولاً برای
// هر پیوند فیزیکی، یک زیرشبکه IPv4 وجود دارد که انتظار می‌رود کارساز
// آن را مدیریت کند. با این حال، در برخی موارد نیاز است که زیرشبکه‌های بیشتری
// در همان مکان فیزیکی پیکربندی شوند. رایج‌ترین مورد مصرف زمانی است که یک زیرشبکه
// موجود فراتر از فرضیات اولیه خود رشد کرده و آدرس‌های آن تمام شده است،
// بنابراین مدیر سیستم باید زیرشبکه دیگری را بر روی زیرشبکه موجود اضافه کند.
{
"Dhcp4": {
// مانند هر پیکربندی دیگری، باید نام‌های رابط را به Kea اعلام کنید
// تا به ترافیک ورودی گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// همچنین باید مشخص کنید که اطلاعات اجاره در کجا ذخیره شود.
// پسانه memfile ساده‌ترین راه‌اندازی را دارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// تعریف شبکه‌های اشتراکی از اینجا آغاز می‌شود. shared-networks می‌تواند
// شامل فهرستی از شبکه‌های اشتراکی باشد. پارامترهای بسیاری وجود دارند
// که می‌توان در اینجا مشخص کرد، بنابراین این مثال ممکن است در ابتدا
// گیج‌کننده به نظر برسد، اما تنها پارامتر اجباری برای هر شبکه
// اشتراکی name است. این نام باید یکتا باشد. معمولاً هر شبکه
// اشتراکی برای کارکرد درست به حداقل دو زیرشبکه نیاز دارد،
// اما اگر واقعاً بخواهید، می‌توانید یک شبکه اشتراکی تقلیل‌یافته تعریف
// کنید که ۱ یا حتی ۰ زیرشبکه دارد. این کار هنگام مهاجرت بین
// زیرشبکه‌های عادی و شبکه‌های اشتراکی یا هنگام اشکال‌زدایی یک مشکل
// می‌تواند مفید باشد. استفاده از ۱ زیرشبکه در هر شبکه اشتراکی توصیه
// نمی‌شود، زیرا بار پردازشی اضافی برای شبکه‌های اشتراکی وجود دارد.
"shared-networks": [
{
// نام شبکه اشتراکی. این می‌تواند یک رشته دلخواه باشد
// و باید در میان تمام شبکه‌های اشتراکی یکتا باشد.
"name": "frog",
// در صورتی که شبکه اشتراکی مستقیماً از کارساز قابل دسترس باشد،
// می‌توانید نام رابط را مشخص کنید.
"interface": "eth1",
// شما می‌توانید پارامترهای بسیاری را که در محدوده زیرشبکه مجاز هستند در
// اینجا مشخص کنید. قرار دادن آن‌ها در اینجا در صورتی که برای تمام زیرشبکه‌های
// این شبکه اشتراکی اعمال شوند مفید است. احتمالاً رایج‌ترین پارامتر
// در اینجا مقادیر گزینه‌های تعریف‌شده با option-data خواهد بود.
"match-client-id": false,
"option-data": [ ],
"rebind-timer": 150,
"authoritative": true,
// اگر تمام ترافیک ورودی از آن شبکه اشتراکی از طریق یک رله (relay)
// قابل دسترس باشد و آن رله همواره از همان آدرس IP استفاده کند،
// می‌توانید آدرس آن رله را در اینجا مشخص کنید. از آنجا که این مثال یک شبکه اشتراکی
// با دسترسی مستقیم را نشان می‌دهد، ما در اینجا 0.0.0.0 قرار می‌دهیم.
// بهتر است محدوده relay کلاً نادیده گرفته شود، اما برای
// مقاصد نمایشی در اینجا باقی مانده است.
"relay": {
"ip-addresses": [ "0.0.0.0" ]
},
// مقادیر تایمر می‌توانند در اینجا بازنویسی شوند.
"renew-timer": 100,
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام آدرس‌های رزروشده
// خارج از استخر (out-of-pool) هستند یا خیر.
// در صورتی که reservations-in-subnet برابر false باشد نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "subnet4" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// این بخش فهرستی از زیرشبکه‌های مجاز در این شبکه اشتراکی را آغاز می‌کند.
// در مثال ما، دو زیرشبکه وجود دارد.
"subnet4": [
{
"id": 1,
"match-client-id": true,
"next-server": "0.0.0.0",
"server-hostname": "",
"boot-file-name": "",
"option-data": [ ],
"pools": [ ],
"rebind-timer": 20,
// در صورتی که رله شما از آدرس‌های IP متفاوتی برای هر
// زیرشبکه استفاده می‌کند، می‌توانید مقدار به ارث‌رسیده از
// shared-network را در اینجا بازنویسی کنید.
"relay": {
"ip-addresses": [ "0.0.0.0" ]
},
"renew-timer": 10,
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام آدرس‌های رزروشده
// خارج از استخر هستند یا خیر.
// در صورتی که reservations-in-subnet برابر false باشد نادیده گرفته می‌شود.
"reservations-out-of-pool": false,
"subnet": "10.0.0.0/8",
"valid-lifetime": 30
},
{
"id": 2,
"match-client-id": true,
"next-server": "0.0.0.0",
"server-hostname": "",
"boot-file-name": "",
"option-data": [ ],
"pools": [ ],
"rebind-timer": 20,
"renew-timer": 10,
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام آدرس‌های رزروشده
// خارج از استخر هستند یا خیر.
// در صورتی که reservations-in-subnet برابر false باشد نادیده گرفته می‌شود.
"reservations-out-of-pool": false,
"subnet": "192.0.2.0/24",
"valid-lifetime": 30
}
],
"valid-lifetime": 200
} ], // پایان shared-networks
// این احتمال وجود دارد که در شبکه خود ترکیبی از زیرشبکه‌های عادی و
// «ساده» و شبکه‌های اشتراکی داشته باشید. ترکیب آن‌ها در یک فایل
// پیکربندی یکسان کاملاً معتبر است.
// این یک زیرشبکه عادی است. بخشی از هیچ shared-network نیست.
"subnet4": [
{
"pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ],
"subnet": "192.0.3.0/24",
"interface": "eth0",
"id": 3
}
]
} // پایان Dhcp4
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این یک سناریوی پایه با یک زیرشبکه IPv4 پیکربندی‌شده است. این زیرشبکه
// شامل یک استخر واحد از آدرس‌های تخصیص‌یافته به‌صورت پویا است.
{ "Dhcp4":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها (leases) را مشخص کنیم. از
// ژوئن ۲۰۲۲، سه پس‌بند پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// آدرس‌ها با طول عمر ۴۰۰۰ ثانیه تخصیص داده خواهند شد.
"valid-lifetime": 4000,
// زمان‌سنج‌های renew و rebind کامنت شده‌اند. این بدان معناست که گزینه‌های
// ۵۸ و ۵۹ به کلاینت ارسال نخواهند شد. در این حالت، انتخاب مقادیر زمان‌سنج طبق RFC2131
// بر عهده کلاینت است. برای ارسال این گزینه‌ها به کلاینت، زمان‌سنج‌ها را از حالت
// کامنت خارج کنید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. در اینجا تنها یک زیرشبکه
// داریم. به Kea اعلام می‌کنیم که مستقیماً روی رابط محلی در دسترس است.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"interface": "eth0"
}
],
// پیکربندی زیر مربوط به گزارش‌گیری (logging) است. فرض بر این است که پیام‌هایی با حداقل
// سطح اطلاعاتی (info، warn، error و fatal) باید در stdout ثبت
// شوند. همچنین، می‌توانید stderr، نام یک فایل، یا 'syslog' را مشخص کنید
// که پیام‌های خروجی را از طریق syslog ذخیره می‌کند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
168u
kea4/vendor-specific.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// هدف از این مثال، نمایش نحوه پیکربندی اطلاعات ویژه سازنده
// (Vendor Specific Information کد ۴۳) بخش ۸.۴ از RFC 2132 است.
{
"Dhcp4": {
"option-def": [
{
// دو گزینه‌ای که قصد داریم به عنوان زیرگزینه در گزینه ۴۳ بگنجانیم
// باید در سطح سراسری تعریف شوند
"array": false,
"code": 2,
"name": "vlanid",
// زیرگزینه‌ها باید فضای (space) پیکربندی‌شده داشته باشند و نمی‌توانند با 'vendor-' شروع شوند
// در غیر این صورت به جای گزینه ۴۳ در گزینه ۱۲۵ گنجانده خواهند شد
"space": "339",
"type": "uint32"
},
{
"array": false,
"code": 3,
"name": "dls",
"space": "339",
"type": "string"
}
],
"client-classes": [
{
// Kea به دسته‌بندی بر اساس گزینه ۶۰ نیاز دارد؛ می‌توانید از این الگو برای نام استفاده کنید:
// VENDOR_CLASS_ + محتوای گزینه ۶۰ (در این صورت به پارامتر test نیازی نیست)
// یا از هر نام دلخواهی استفاده کرده و پارامتر "test" را متناسب با آن اضافه کنید؛ مانند:
// "test": "substring(option[60].hex,0,9) == 'partial-content-of-option-60'"
"name": "VENDOR_CLASS_339",
"option-def": [
{
// گزینه Vendor-specific باید در سطح کلاس تعریف شود؛ اگر قصد ارسال یک مقدار منفرد
// را داریم، نوع آن را متناسب با آن تعریف کنید. اگر این گزینه باید سایر زیرگزینه‌ها را در بر
// بگیرد، پارامتر "space" باید با زیرگزینه‌های گنجانده‌شده یکسان باشد
// و "type" روی empty تنظیم شود
"code": 43,
// با استفاده از دستورالعمل "encapsulate"، به Kea گفته می‌شود که گزینه‌ها را از
// فضای نام "339" در بر بگیرد. ما پیش‌تر چند مورد از این گزینه‌ها را تعریف کرده‌ایم.
// بدین ترتیب، زیرگزینه‌ها به این گزینه ۴۳ متصل (پیوست) می‌شوند.
"encapsulate": "339",
"name": "vendor-encapsulated-options",
"type": "empty"
}
],
"option-data": [
{
// گزینه vendor-encapsulated-options و گزینه تعریف‌شده در سطح سراسری نیز
// باید با پارامترهای "data" مناسب در فهرست "option-data" پیکربندی شوند.
// از آنجا که Kea تنها گزینه‌هایی را ارسال می‌کند که کلاینت درخواست کرده باشد، و روشی
// برای درخواست زیرگزینه‌ها وجود ندارد، پارامتر "always-send" با مقدار
// تنظیم‌شده روی true نیز باید در تمام زیرگزینه‌های سفارشی گنجانده شود
"name": "vendor-encapsulated-options"
},
{
"always-send": true,
"data": "123",
"name": "vlanid",
"space": "339"
},
{
"always-send": true,
"data": "sdlp://192.0.2.11:18443",
"name": "dls",
"space": "339"
}
]
}
],
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": ["eth0"]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها (leases) را مشخص کنیم.
"lease-database": {
"type": "memfile"
},
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. در اینجا تنها یک زیرشبکه
// داریم. به Kea اعلام می‌کنیم که مستقیماً روی رابط محلی در دسترس است.
"subnet4": [
{
"interface": "eth0",
"pools": [
{
"pool": "192.0.2.50-192.0.2.50"
}
],
"subnet": "192.0.2.0/24",
"id": 1
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// هدف این مثال نمایش نحوه پیکربندی گزینه
// Vendor-Identifying Vendor-specific Information
// (کد 125) RFC 3925 است
{
"Dhcp4": {
// اگر بخواهیم زیرگزینه‌ها را در گزینه 125 ارسال کنیم، ابتدا باید
// در سطح سراسری تعریف شوند
"option-def": [
{
"array": false,
"code": 2,
"name": "vlanid",
// در مورد زیرگزینه‌های گزینه 125، فضا باید با پیشوند "vendor-" شروع شود
// در این مورد، "vendor-" + شناسه سازنده از گزینه 60 ارسال‌شده توسط کلاینت است
// مقدار 339 مربوط به Siemens Industry Inc است.
"space": "vendor-339",
"type": "uint32"
},
{
"array": false,
"code": 3,
"name": "dls",
"space": "vendor-339",
"type": "string"
}
],
"client-classes": [
{
// برنامه Kea به طبقه‌بندی بر اساس گزینه 60 نیاز دارد؛ می‌توانید از نام:
// VENDOR_CLASS_ + محتوای گزینه 60 استفاده کنید (که در این صورت پارامتر test لازم نیست)
// یا از هر نام دلخواهی استفاده کرده و پارامتر "test" را بر این اساس اضافه کنید، مثلاً:
// "test": "substring(option[60].hex,0,9) == 'partial-content-of-option-60'"
"name": "VENDOR_CLASS_339",
"option-data": [
{
// در فهرست "option-data" باید گزینه 125 را با پارامتر data برابر با
// vendor-id مورد انتظارمان پیکربندی کنیم، همچنین این به Kea می‌گوید که کدام فضای سازنده را
// در زیرگزینه‌ها کپسوله‌سازی کند.
"data": "339",
"name": "vivso-suboptions"
},
{
// و علاوه بر این باید تمام زیرگزینه‌های از پیش تعریف‌شده را با پارامتر "space"
// یکسان با option-def پیکربندی کنیم.
// از آنجا که Kea تنها گزینه‌هایی را ارسال می‌کند که کلاینت درخواست داده است، و راهی
// برای درخواست زیرگزینه‌ها وجود ندارد، پارامتر "always-send" با مقدار تنظیم‌شده
// روی true نیز باید در تمام زیرگزینه‌های سفارشی گنجانده شود.
"always-send": true,
"data": "123",
"name": "vlanid",
"space": "vendor-339"
},
{
"always-send": true,
"data": "sdlp://192.0.2.11:18443",
"name": "dls",
"space": "vendor-339"
}
]
}
],
// به Kea دستور داده شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [
"eth0"
]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها مشخص شود.
"lease-database": {
"type": "memfile"
},
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. در اینجا تنها یک زیرشبکه
// داریم. به Kea اعلام می‌کنیم که مستقیماً از طریق رابط محلی در دسترس است.
"subnet4": [
{
"id": 1,
"interface": "eth0",
"pools": [
{
"pool": "192.0.2.50-192.0.2.50"
}
],
"subnet": "192.0.2.0/24"
}
]
}
}
168u
168u
kea4/with-ddns.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این یک سناریوی پایه‌ای با یک زیرشبکه IPv4 پیکربندی‌شده و با DDNS
// فعال است.
{ "Dhcp4":
{
// به Kea دستور داده شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها مشخص شود. تا
// ژوئن 2022، از سه زیرساخت پایگاه‌داده پشتیبانی می‌شود: MySQL ،PostgreSQL
// و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// نشانی‌ها با طول عمر 4000 ثانیه اختصاص خواهند یافت.
"valid-lifetime": 4000,
// زمان‌سنج‌های تجدید (renew) و اتصال مجدد (rebind) کامنت شده‌اند. این بدان معناست که گزینه‌های
// 58 و 59 به کلاینت ارسال نخواهند شد. در این صورت، انتخاب مقادیر زمان‌سنج مطابق با RFC2131
// بر عهده کلاینت است. برای ارسال این گزینه‌ها به کلاینت، زمان‌سنج‌ها را از حالت کامنت
// خارج کنید.
// "renew-timer": 1000,
// "rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. در اینجا تنها یک زیرشبکه
// داریم. به Kea اعلام می‌کنیم که مستقیماً از طریق رابط محلی در دسترس است.
"subnet4": [
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"subnet": "192.0.2.0/24",
"interface": "eth0",
"id": 1
}
],
// فعال‌سازی ارتباط با kea-dhcp-ddns
// (برای به‌روزرسانی‌های پویای DNS لازم است)
"dhcp-ddns" : {
"enable-updates" : true,
"server-ip" : "192.0.2.0",
"server-port" : 3432,
"sender-ip" : "192.0.2.1",
"sender-port" : 3433,
"max-queue-size" : 2048,
"ncr-protocol" : "UDP",
"ncr-format" : "JSON"
},
// فعال‌سازی به‌روزرسانی‌های DDNS و پیکربندی رفتار به‌روزرسانی DDNS
"ddns-send-updates" : true,
"ddns-override-no-update" : true,
"ddns-override-client-update" : true,
"ddns-replace-client-name" : "when-present",
"ddns-generated-prefix" : "test.prefix",
"ddns-qualifying-suffix" : "test.suffix.",
"ddns-update-on-renew" : false,
"ddns-conflict-resolution-mode": "check-with-dhcid",
"ddns-ttl-percent" : 0.75,
"hostname-char-set": "[^A-Za-z0-9.-]",
"hostname-char-replacement": "x",
// بخش زیر ثبت وقایع (logging) را پیکربندی می‌کند. فرض می‌شود که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}
168u
kea6/advanced.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea است.
// این پیکربندی تلاش می‌کند برخی از قابلیت‌های پیشرفته‌تر را نمایش دهد.
// از نظر توپولوژی، این یک سناریوی پایه با یک زیرشبکه IPv6 پیکربندی‌شده است.
// فرض بر این است که یک زیرشبکه (2001:db8:1::/64) به طور مستقیم
// روی رابط eth0 در دسترس است.
//
// قابلیت‌های زیر در اینجا به نمایش گذاشته شده‌اند:
// ۱. پیکربندی منابع آدرس سخت‌افزاری/MAC در DHCPv6
// ۲. گزینه‌های ارائه‌شده توسط رله (RSOO) - برخی رله‌ها ممکن است گزینه‌هایی را با این
// هدف درج کنند که کارگزار آن‌ها را در پیام‌های ارسالی به کلاینت قرار دهد.
// ۳. سوکت کنترلی (Control socket). Kea می‌تواند سوکتی باز کرده و به فرمان‌های
// ورودی گوش فرا دهد.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط شبکه eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ],
// این گزینه باعث می‌شود رابط‌ها در هر بار پیکربندی (مجدد) دوباره شناسایی شوند.
// به طور پیش‌فرض روی true تنظیم شده است.
"re-detect": true
},
// ما باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها (leases) را مشخص کنیم. تا
// ژوئن ۲۰۲۲، سه پیشانه پایگاه‌داده پشتیبانی می‌شوند: MySQL ،PostgreSQL
// و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد زیرا نیازی به راه‌اندازی اولیه ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"sanity-checks": {
// این پارامتر تعیین می‌کند هنگام مواجهه با یک اجاره جدید در سیستم چه کاری انجام
// شود (یعنی در زمان راه‌اندازی memfile از دیسک خوانده شود یا از طریق فرمان‌های
// lease اضافه شود). پنج حالت پشتیبانی می‌شود:
// none - هیچ کاری نکن، آن‌ها را همان‌گونه که هستند بپذیر
// warn - در صورت تشخیص مشکلات subnet-id، یک هشدار چاپ کن، اما در غیر
// این صورت اجاره را همان‌طور بارگذاری کن. این مقدار پیش‌فرض است.
// fix - تلاش برای اصلاح اجاره با یافتن مقدار subnet-id مناسب.
// اگر زیرشبکه مناسبی وجود نداشته باشد، اجاره همان‌طور بارگذاری می‌شود.
// fix-del - تلاش برای اصلاح اجاره با یافتن مقدار subnet-id مناسب.
// اگر زیرشبکه مناسبی یافت نشود، اجاره حذف می‌شود.
// del - حذف اجاره‌هایی که مقادیر subnet-id نادرست دارند.
"lease-checks": "fix-del"
},
// نسخه 0.9.1 برنامه Kea پشتیبانی از آدرس‌های MAC/سخت‌افزاری را در DHCPv6 معرفی کرد.
// هیچ روش واحد و قابل اعتمادی برای دریافت اطلاعات آدرس MAC در DHCPv6 وجود ندارد.
// نرم‌افزار Kea از چندین روش پشتیبانی می‌کند. بسته به پیکربندی شبکه شما، برخی روش‌ها
// ممکن است به بقیه ترجیح داده شوند، از این رو این پارامتر پیکربندی وجود دارد.
// 'mac-sources' فهرستی از روش‌هاست. مقادیر مجاز عبارتند از:
// any، raw، duid، ipv6-link-local، client-link-addr-option، rfc6939 (که
// یک نام مستعار برای client-link-addr-option است)، remote-id، rfc4649 (که یک
// نام مستعار برای remote-id است)، subscriber-id، rfc4580 (که یک نام مستعار برای
// subscriber-id است) و docsis.
// توجه داشته باشید که ترتیب اهمیت دارد. روش‌ها یک‌به‌یک به همان ترتیب تعیین‌شده
// بررسی می‌شوند تا آدرس سخت‌افزاری به دست آید. اگر تفاوتی ندارد که کدام روش استفاده
// شود، استفاده از 'any' اندکی سریع‌تر از فهرست کردن همه آن‌هاست.
// اگر mac-sources مشخص نشده باشد، مقدار پیش‌فرض 'any' استفاده می‌شود.
"mac-sources": [ "client-link-addr-option", "duid", "ipv6-link-local" ],
// استاندارد RFC6422 سازوکاری موسوم به relay-supplied options option را تعریف
// می‌کند. عامل رله می‌تواند گزینه‌های خاصی را درج کند که در صورت وجود معیارهای
// مشخص، کارگزار آن‌ها را به کلاینت منعکس کند (echo back). یک شرط این است که گزینه
// باید RSOO-enabled باشد (یعنی اجازه انعکاس داشته باشد). آیانا فهرستی از این گزینه‌ها
// را در اینجا نگهداری می‌کند:
// http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied
// با این حال، امکان اجازه به کارگزار برای انعکاس گزینه‌های اضافی وجود دارد.
// این مدخل گزینه‌های 110، 120 و 130 را به عنوان RSOO-enabled علامت‌گذاری می‌کند.
"relay-supplied-options": [ "110", "120", "130" ],
// این مورد یک سوکت کنترلی را تعریف می‌کند. در صورت تعریف، Kea یک سوکت UNIX
// باز کرده و به فرمان‌های دریافتی گوش می‌دهد. برای فهرست فرمان‌های پشتیبانی‌شده،
// بخش ۱۵ از راهنمای کاربر Kea را ببینید.
"control-socket": {
"socket-type": "unix",
"socket-name": "kea6-ctrl-socket"
},
// آدرس‌ها با طول عمر ترجیحی (preferred) و معتبر (valid) به ترتیب با مقادیر
// ۳۰۰۰ و ۴۰۰۰ ثانیه تخصیص داده می‌شوند. به کلاینت گفته می‌شود که پس از ۱۰۰۰ ثانیه
// تمدید را آغاز کند. اگر کارگزار پس از ۲۰۰۰ ثانیه از زمان واگذاری اجاره پاسخی
// ندهد، کلاینت باید روال REBIND را آغاز کند (تمدید اضطراری که امکان تغییر
// کارگزار به یک کارگزار دیگر را فراهم می‌کند).
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل از ورودی‌های subnet
// و pool تشکیل شده است. به user-context استفاده‌شده در سراسر تعاریف دقت کنید.
// این داده‌ها مستقیماً توسط Kea استفاده نمی‌شوند، بلکه فقط تجزیه شده و در ساختارهای
// مناسب ذخیره می‌گردند. تا زمانی که ساختار یک JSON معتبر باشد و با یک نگاشت (map)
// شروع شود (یعنی درون کروشه‌های فرفری محصور باشد)، هر چیزی را می‌توانید در
// user-context قرار دهید.
// یک ورودی کامنت به یک user-context دارای ویژگی "comment" ترجمه می‌شود،
// بنابراین می‌توانید یادداشت‌ها را درون خود پیکربندی درج کنید.
"subnet6": [
{
"pools": [
{
"pool": "2001:db8:1::/80",
// این user context اختصاصی برای این استخر (pool) خاص است. می‌توانید از آن
// برای توصیف استخر استفاده کنید. فقط به خاطر داشته باشید که این ساختار مستقیماً
// توسط خود Kea استفاده نخواهد شد؛ بلکه در دسترس قلاب‌ها (hooks) قرار می‌گیرد
// تا در صورت نیاز از آن استفاده کنند.
"user-context": { "department": "engineering" }
}],
// در اینجا user-context برای کل زیرشبکه آمده است.
"user-context": { "comment": "Floor one, west wing" },
// معادل با استفاده از تجزیه‌کننده هوشمند
// "comment": "Floor one, west wing",
// این بخش استخرهای تفویض پیشوند (PD - prefix delegation) را تعریف می‌کند.
// در این حالت ما فقط یک استخر داریم که شامل پیشوندهای /64 تفویض‌شده از یک
// استخر بزرگ /48 است. هر پیشوند تفویض‌شده شامل گزینه excluded-prefix خواهد بود.
"pd-pools": [
{
"prefix": "2001:db8:abcd::",
"prefix-len": 48,
"delegated-len": 64,
"excluded-prefix": "2001:db8:abcd:0:1234::",
"excluded-prefix-len": 80,
// یک user-context دیگر برای این استخر PD. باز هم تا زمانی که یک JSON معتبر
// باشد و با یک نگاشت آغاز شود، می‌توانید هر داده‌ای را در آن قرار دهید.
"user-context": {
"purpose": "For CPE devices"
}
}
], // پایان استخرها
"id": 1,
"subnet": "2001:db8:1::/64",
"interface": "eth0",
// گاهی رله ممکن است از یک نشانی IPv6 نامتعارف استفاده کند که با زیرشبکه مطابقت
// ندارد. این کار توصیه نمی‌شود، اما در مواردی منطقی و مجاز است. یک مورد زمانی
// است که رله فقط نشانی link-local دارد و مورد دیگر در سناریوی زیرشبکه اشتراکی است.
"relay": {
"ip-addresses": [ "3000::1" ]
}
}
],
// بخش زیر گزارش‌گیری (logging) را پیکربندی می‌کند. فرض بر این است که پیام‌هایی
// حداقل با سطح اطلاع‌رسانی (info، warn، error و fatal) باید در stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout",
// علاوه بر خروجی معمولی، چندین پارامتر دیگر نیز امکان‌پذیر است. Flush تعیین
// می‌کند که آیا لاگر خروجی را سریعاً به فایل تخلیه کند یا خیر. Maxsize حداکثر
// اندازه فایل را پیش از چرخش (rotation) تعیین می‌کند. maxver
// حداکثر تعداد فایل‌های چرخیده‌شده‌ای را که نگهداری می‌شوند مشخص
// می‌سازد.
"flush": true,
"maxsize": 204800,
"maxver": 4,
// ما از pattern برای مشخص کردن قالب سفارشی پیام‌های گزارش استفاده می‌کنیم
"pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// هشدار: این پیکربندی نمونه برای استفاده در محیط عملیاتی در نظر گرفته نشده است.
// کارگزار Kea DHCPv6 این پیکربندی را رد خواهد کرد زیرا شامل پارامترهای
// پیکربندی ناسازگار با یکدیگر (مانعة‌الجمع) است.
//
// هدف اصلی این فایل نمونه، ارائه فهرستی جامع از پارامترهای پشتیبانی‌شده
// توسط کارگزار Kea DHCPv6 به همراه توضیح مختصری از هر پارامتر است.
//
// این نسخه پایدار برای YANG استفاده می‌شود، زیرا نمی‌خواهیم با هر بار
// افزودن یک کلیدواژه به نحو، کدها و مدل‌ها به‌روزرسانی شوند.
{
// پیکربندی کارگزار Kea DHCPv6 از اینجا آغاز می‌شود.
"Dhcp6": {
// پرچم سراسری جهت انتخاب راهبرد تخصیص آدرس IP برای همه
// زیرشبکه‌ها.
"allocator": "iterative",
// پرچم سراسری برای فعال یا غیرفعال کردن ثبت آدرس کلاینت
// از طریق بسته‌های ADDR-REG-INFORM (RFC 9686 را ببینید). پیش‌فرض آن true است.
"allow-address-registration": true,
// پرچم سراسری جهت انتخاب راهبرد تخصیص پیشوند واگذارشده (delegated prefix)
// برای همه زیرشبکه‌ها.
"pd-allocator": "random",
// فهرست مرتب‌شده‌ای از کلاس‌های کلاینت مورد استفاده کارگزار DHCPv6.
"client-classes": [
{
// نام کلاس.
"name": "phones_server1",
// فهرست گزینه‌های DHCPv6 ویژه کلاس.
"option-data": [],
// عبارت انتخاب کلاس. بسته DHCP زمانی به این کلاس
// اختصاص داده می‌شود که مقدار عبارت داده‌شده true ارزیابی شود.
"test": "member('HA_server1')",
// مدت اعتبار کلاس.
"valid-lifetime": 6000,
// حداقل مدت اعتبار کلاس.
"min-valid-lifetime": 4000,
// حداکثر مدت اعتبار کلاس.
"max-valid-lifetime": 8000,
// مدت ترجیحی کلاس.
"preferred-lifetime": 7000,
// حداقل مدت ترجیحی کلاس.
"min-preferred-lifetime": 5000,
// حداکثر مدت ترجیحی کلاس.
"max-preferred-lifetime": 9000
},
{
// نام کلاس دوم.
"name": "phones_server2",
// فهرست گزینه‌های DHCPv6 ویژه کلاس.
"option-data": [],
// عبارت انتخاب کلاس. بسته DHCP زمانی به این کلاس
// اختصاص داده می‌شود که مقدار عبارت داده‌شده true ارزیابی شود.
"test": "member('HA_server2')"
},
{
// نام کلاس سوم.
"name": "late",
// پرچم بولی که مشخص می‌کند آیا عبارت کلاس فقط در صورت نیاز به کلاس ارزیابی
// شود یا خیر؛ برای مثال، پیکربندی استخر آدرس انتخاب‌شده شامل نام این کلاس
// در فهرست "evaluate-additional-classes" باشد. مقدار پیش‌فرض false به این معنی
// است که عبارت آزمون کلاس باید همیشه ارزیابی شود.
"only-in-additional-list": true,
// عبارت انتخاب کلاس.
"test": "member('ALL')"
},
{
// نام کلاس چهارم.
"name": "my-template-class",
// پرچم کلاس الگو که حاوی عبارت مورد استفاده برای تولید نام تمام زیرکلاس‌های
// ایجادشده است. در این حالت، کلاس‌ها بر اساس شناسه کلاینت (client ID) نام‌گذاری می‌شوند.
"template-test": "substring(option[1].hex, 0, all)"
}
],
// پارامترهایی برای فعال‌سازی رفتارهای سازگار با کلاینت‌ها،
// رله‌ها یا سایر عامل‌های دارای نقص یا ناسازگار با استاندارد
"compatibility": {
// تجزیه ملایم‌تر گزینه‌ها در جایی که فیلدها می‌توانند به طور قطعی
// استنتاج شوند، حتی اگر بر خلاف RFC یا رویه معمول باشد.
"lenient-option-parsing": true
},
// پارامترهای پیکربندی سوکت کنترل فرمان برای کارگزار Kea DHCPv6.
"control-sockets": [
{
// نوع سوکت کنترل مورد استفاده کارگزار Kea DHCPv6.
// باید unix، http یا https باشد.
"socket-type": "unix",
// مکان فایل سوکت دامنه‌ای یونیکس (UNIX domain socket) که
// کارگزار DHCPv6 برای دریافت فرمان‌های کنترلی از مدیر محلی
// سرور استفاده می‌کند.
"socket-name": "kea6-ctrl-socket"
},
{
// نوع سوکت کنترل مورد استفاده کارگزار Kea DHCPv6.
// باید unix، http یا https باشد.
"socket-type": "https",
// آدرس سوکت HTTPS که کارگزار Kea DHCPv6 باید برای پرس‌وجوهای
// ورودی روی آن شنود کند.
"socket-address": "::1",
// درگاه سوکت HTTPS که کارگزار Kea DHCPv6 باید برای پرس‌وجوهای
// ورودی روی آن شنود کند. در صورت فعال‌سازی پایداری بالا (HA)
// و چندنخی، درگاه 8000 توسط شنونده http کتابخانه قلاب HA
// استفاده می‌شود. هنگام استفاده از کتابخانه قلاب HA همراه با چندنخی
// برای عملکرد صحیح، مطمئن شوید درگاه استفاده‌شده توسط شنونده اختصاصی
// با درگاه مشخص‌شده در اینجا متفاوت باشد (مثلاً 8001). توجه داشته باشید
// که فرمان‌ها همچنان باید به یک سوکت کنترل ارسال شوند. شنونده
// اختصاصی منحصراً برای به‌روزرسانی‌های HA است.
"socket-port": 8006,
// لنگر اعتماد TLS (مرجع صدور گواهی یا CA). این یک نام فایل
// یا مسیر دایرکتوری است. تنها برای سوکت کنترل از نوع https
// همراه با سایر پارامترهای TLS کاربرد دارد.
"trust-anchor": "my-ca",
// نام فایل گواهی سرور TLS.
"cert-file": "my-cert",
// نام فایل کلید خصوصی سرور TLS.
"key-file": "my-key",
// پرچم الزام گواهی‌های کلاینت TLS. پیش‌فرض true است
// و به معنای الزام به وجود گواهی‌های کلاینت است.
// مقدار false اختیاری بودن آن‌ها را می‌رساند.
"cert-required": true,
// هدرهای اضافی HTTP جهت افزودن به پاسخ‌ها.
"http-headers":
[
{
// بافتار اختیاری کاربر (user context).
"user-context": { "comment": "HSTS header" },
// نام الزامی هدر HTTP.
"name": "Strict-Transport-Security",
// مقدار الزامی هدر HTTP.
"value": "max-age=31536000"
}
],
// احراز هویت اختیاری.
"authentication": {
// نوع الزامی احراز هویت. تنها مقدار پشتیبانی‌شده
// basic برای احراز هویت پایه HTTP است.
"type": "basic",
// یک پارامتر اختیاری، قلمرو (realm) احراز هویت پایه
// HTTP است. پیش‌فرض آن
// "kea-dhcpv6-server" است.
"realm": "kea-dhcpv6-server",
// از این پارامتر اختیاری می‌توان برای تعیین یک پیشوند مشترک
// برای فایل‌های مدیریت اعتبارنامه‌های کلاینت استفاده کرد.
"directory": "/usr/local/share/kea/kea-creds",
// این فهرست شناسه‌های کاربری و گذرواژه‌های مورد استفاده
// برای احراز هویت پایه HTTP را مشخص می‌کند. اگر خالی باشد
// یا وجود نداشته باشد، هر کلاینتی مجاز شمرده می‌شود.
"clients": [
// این مورد یک کلاینت مجاز را مشخص می‌کند.
{
// شناسه کاربر نباید خالی باشد یا شامل
// نویسه ':' باشد. این یک پارامتر
// اجباری است.
"user": "admin",
// اگر گذرواژه مشخص نشود، از گذرواژه
// خالی استفاده می‌شود.
"password": "1234"
},
// این مورد یک کلاینت مخفی را مشخص می‌کند.
{
// شناسه کاربر محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenu است.
"user-file": "hiddenu",
// گذرواژه محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenp است.
"password-file": "hiddenp"
},
// این مورد یک کلاینت مخفی را با استفاده از یک
// راز در یک فایل مشخص می‌کند.
{
// راز، محتوای فایل
// /usr/local/share/kea/kea-creds/hiddens است که باید در
// قالب <user-id>:<password> باشد.
"password-file": "hiddens"
}
]
}
}
],
// پیشوندی را برای الحاق به ابتدای Client FQDN تولیدشده مشخص می‌کند.
// می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-generated-prefix": "myhost",
// پرچم بولی که مشخص می‌کند آیا سرور باید تمایل کلاینت DHCP برای
// به‌روزرسانی DNS توسط خودش را نادیده بگیرد یا خیر. با تنظیم این پرچم روی true،
// سرور به‌روزرسانی‌های DNS را برای هر دو داده‌های DNS مستقیم و
// معکوس ارسال خواهد کرد. مقدار پیش‌فرض false است که نشان می‌دهد
// سرور در صورت درخواست، به‌روزرسانی DNS را به کلاینت واگذار می‌کند.
// می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-override-client-update": false,
// پرچم بولی که مشخص می‌کند آیا سرور باید تمایل کلاینت DHCP مبنی بر
// عدم به‌روزرسانی DNS را لغو کند یا خیر. با تنظیم این پارامتر روی
// true، سرور حتی زمانی که کلاینت درخواست عدم به‌روزرسانی داده باشد نیز
// به‌روزرسانی DNS را ارسال می‌کند. می‌تواند در سطوح سراسری،
// shared-network و subnet تعیین شود.
"ddns-override-no-update": false,
// پسوندی که به نام جزئی ارسال‌شده به DNS ملحق می‌شود. مقدار پیش‌فرض
// یک رشته خالی است که نشان می‌دهد هیچ پسوندی الحاق نمی‌شود. می‌تواند در
// سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-qualifying-suffix": "",
// شمارشی که مشخص می‌کند آیا سرور باید نام میزبان یا Client FQDN
// ارسال‌شده توسط کلاینت را رعایت کند یا آن را جایگزین نماید.
// مقادیر مجاز عبارتند از: "never" (استفاده از نام ارسالی کلاینت)،
// "always" (جایگزینی نام ارسالی کلاینت)، "when-present" (جایگزینی
// نام ارسالی کلاینت، اما عدم تولید نام در صورتی که کلاینت نامی ارسال
// نکرده باشد)، "when-not-present" (تولید نام زمانی که کلاینت نامی
// ارسال نکرده باشد، در غیر این صورت حفظ نام ارسالی کلاینت).
// مقدار پیش‌فرض "never" است. می‌تواند در سطوح سراسری،
// shared-network و subnet تعیین شود.
"ddns-replace-client-name": "never",
// پرچم بولی که به‌روزرسانی DDNS را فعال یا غیرفعال می‌کند. مقدار
// پیش‌فرض آن true است. می‌تواند در سطوح سراسری، shared-
// network و subnet تعیین شود. این گزینه در ارتباط با
// dhcp-ddns:enable-updates کار می‌کند که برای برقراری اتصال به
// kea-dhcp-ddns باید روی true باشد.
"ddns-send-updates": true,
// پرچم بولی که در صورت true بودن، به سرور دستور می‌دهد هنگام تمدید اجاره‌ها
// همیشه DNS را به‌روزرسانی کند، حتی اگر اطلاعات DNS تغییری نکرده باشد.
// رفتار پیش‌فرض سرور (یعنی false بودن پرچم) به‌روزرسانی DNS صرفاً در
// صورت تغییر اطلاعات DNS است. می‌تواند در سطوح سراسری،
// shared-network و subnet تعیین شود.
"ddns-update-on-renew": true,
// پرچم بولی که همراه با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns
// ارسال می‌شود تا مشخص کند آیا حل تعارض به‌روزرسانی DNS طبق
// RFC 4703 باید برای درخواست داده‌شده به کار رود یا خیر. مقدار پیش‌فرض
// برای این پرچم true است. می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیه آن صرفاً جهت سازگاری رو به عقب حفظ شده است.
// "ddns-use-conflict-resolution": true,
// شمارشی که همراه با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns
// ارسال می‌شود تا حالت مورد استفاده برای حل تعارض‌ها حین انجام به‌روزرسانی‌های
// DDNS را مشخص کند. مقادیر مجاز عبارتند از:
// check-with-dhcid (شامل افزودن رکورد DHCID و بررسی آن رکورد از طریق تشخیص تعارض طبق RFC 4703)،
// no-check-with-dhcid (تشخیص تعارض را نادیده می‌گیرد اما هنگام ایجاد/به‌روزرسانی ورودی یک رکورد DHCID اضافه می‌کند)،
// check-exists-with-dhcid (وجود رکورد DHCID موجود را بررسی می‌کند اما تطابق مقدار رکورد با به‌روزرسانی را بررسی نمی‌کند.
// این حالت همچنین رکورد DHCID را برای ورودی به‌روزرسانی می‌کند)،
// no-check-without-dhcid (تشخیص تعارض را نادیده می‌گیرد و هنگام ایجاد/به‌روزرسانی ورودی DDNS رکورد DHCID اضافه نمی‌کند).
// مقدار پیش‌فرض "check-with-dhcid" است. می‌تواند در سطوح سراسری،
// shared-network و subnet تعیین شود.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// در صورت بزرگ‌تر بودن از 0.0، درصدی از طول عمر اجاره است
// که برای DNS TTL استفاده می‌شود.
"ddns-ttl-percent": 0.75,
// در صورت بزرگ‌تر بودن از 0، به عنوان DNS TTL استفاده خواهد شد. بر حسب ثانیه مشخص می‌شود.
// نمی‌توان هم ddns-ttl و هم هر یک از ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را مشخص کرد. آن‌ها مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// در صورت بزرگ‌تر بودن از 0، به عنوان کران پایین مقادیر محاسبه‌شده DNS TTL استفاده می‌شود.
// بر حسب ثانیه مشخص می‌شود.
"ddns-ttl-min": 24000,
// در صورت بزرگ‌تر بودن از 0، به عنوان کران بالای مقادیر محاسبه‌شده DNS TTL استفاده می‌شود.
// بر حسب ثانیه مشخص می‌شود.
"ddns-ttl-max": 64000,
// مدت‌زمان بر حسب ثانیه که مشخص می‌کند یک اجاره ردشده تا چه مدت باید
// از تخصیص‌های DHCP مستثنی شود. مقدار پیش‌فرض 24 ساعت است.
"decline-probation-period": 86400,
// پیکربندی ارسال درخواست‌های تغییر نام (NCR) برای کارگزار Kea DHCPv6.
// درخواست‌های NCR پس از تخصیص اجاره‌های DHCP، برای به‌روزرسانی DNS به ماژول
// Kea D2 ارسال می‌شوند.
"dhcp-ddns": {
// پرچم بولی که مشخص می‌کند آیا کارگزار Kea DHCPv6 باید به
// kea-dhcp-ddns متصل شود یا خیر. برای ایجاد و ارسال NCRها
// به kea-dhcp-ddns، این مقدار باید true باشد. به طور پیش‌فرض، NCRها تولید نمی‌شوند.
"enable-updates": false,
// حداکثر تعداد NCRهایی که در صف در انتظار ارسال
// به سرور Kea D2 قرار می‌گیرند را مشخص می‌کند.
"max-queue-size": 1024,
// قالب بسته مورد استفاده هنگام ارسال NCRها به سرور Kea D2.
// در حال حاضر فقط قالب JSON پشتیبانی می‌شود.
"ncr-format": "JSON",
// پروتکل سوکت برای ارسال NCRها به D2. در حال حاضر
// فقط UDP پشتیبانی می‌شود.
"ncr-protocol": "UDP",
// آدرس IP که کارگزار Kea DHCPv6 باید برای ارسال NCRها
// به D2 استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید یک آدرس مناسب را انتخاب کند.
"sender-ip": "::1",
// شماره درگاهی که کارگزار Kea DHCPv6 باید برای ارسال NCRها
// به D2 استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید یک درگاه مناسب را انتخاب کند.
"sender-port": 0,
// آدرس IP که D2 برای دریافت NCRها روی آن شنود می‌کند.
"server-ip": "::1",
// شماره درگاهی که D2 برای دریافت NCRها روی آن شنود می‌کند.
"server-port": 53001
},
// اولین مورد از دو درگاه متوالی سوکت‌های UDP مورد استفاده
// برای ارتباط بین کارگزارهای DHCPv6 و DHCPv4 را مشخص می‌کند.
// RFC 7341 را ببینید (پیش‌فرض 0 - غیرفعال).
// در صورت فعال بودن، مثلاً از 786 استفاده کنید.
"dhcp4o6-port": 0,
// مجموعه‌ای از پارامترهای کارگزار Kea DHCPv6 که نحوه
// پردازش اجاره‌های منقضی‌شده DHCP را توسط سرور پیکربندی می‌کنند.
"expired-leases-processing": {
// تعداد ثانیه‌ها از زمان آخرین حذف اجاره‌های منقضی‌شده
// را مشخص می‌کند که پس از آن حذف بعدی باید رخ دهد.
// اگر هر دو مقدار "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" غیر صفر باشند، هنگامی که کلاینت یک پیام
// release ارسال می‌کند، اجاره به جای حذف از فضای ذخیره اجاره،
// منقضی می‌شود.
"flush-reclaimed-timer-wait-time": 25,
// مدت‌زمان بر حسب ثانیه جهت نگهداری اجاره‌های منقضی‌شده
// در پایگاه‌داده اجاره (وابستگی اجاره یا lease affinity).
// اگر هر دو مقدار "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" غیر صفر باشند، هنگامی که کلاینت یک پیام
// release ارسال می‌کند، اجاره به جای حذف از فضای ذخیره اجاره،
// منقضی می‌شود.
"hold-reclaimed-time": 3600,
// حداکثر تعداد اجاره‌های منقضی‌شده قابل پردازش در یک
// تلاش منفرد برای پاکسازی اجاره‌های منقضی‌شده از پایگاه‌داده
// اجاره را مشخص می‌کند. اگر اجاره‌های منقضی بیشتری وجود داشته باشد،
// در تلاش پاکسازی بعدی پردازش خواهند شد.
"max-reclaim-leases": 100,
// حداکثر زمان بر حسب میلی‌ثانیه که یک تلاش منفرد برای
// پاکسازی اجاره‌های منقضی‌شده از پایگاه‌داده اجاره ممکن است طول بکشد.
"max-reclaim-time": 250,
// مدت‌زمان بر حسب ثانیه از زمان آخرین تلاش برای پردازش
// اجاره‌های منقضی‌شده قبل از آغاز تلاش بعدی.
"reclaim-timer-wait-time": 10,
// حداکثر تعداد چرخه‌های پردازش اجاره منقضی‌شده که منجر به
// پاکسازی کامل اجاره‌های منقضی از پایگاه‌داده اجاره نشده‌اند؛
// پس از این تعداد، یک پیام هشدار صادر می‌شود.
"unwarned-reclaim-cycles": 5
},
// فهرست کتابخانه‌های قلاب (hook libraries) و پارامترهای پیکربندی خاص
// آن‌ها جهت بارگذاری توسط کارگزار Kea DHCPv4.
"hooks-libraries": [
{
// مکان کتابخانه قلاب جهت بارگذاری.
"library": "libdhcp_lease_cmds.so",
// پارامترهای پیکربندی خاص کتابخانه قلاب.
"parameters": { }
},
{
// کتابخانه قلاب backend میزبان MySQL که برای ذخیره‌سازی میزبان لازم است.
"library": "libdhcp_mysql.so"
},
{
// کتابخانه قلاب backend میزبان PostgreSQL که برای ذخیره‌سازی میزبان لازم است.
"library": "libdhcp_pgsql.so"
}
],
// فهرست اعتبارنامه‌های دسترسی به منابع خارجی رزروهای IPv6،
"hosts-databases": [
{
// نام پایگاه‌داده جهت اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژه پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 3306,
// نوع پایگاه‌داده، مثلاً "mysql" یا "postgresql".
"type": "mysql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// حالت فقط‌خواندنی.
"readonly": false,
// ورودی‌های بعدی برای پشتیبانی OpenSSL در MySQL هستند.
// لنگر اعتماد یا همان فایل یا دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// فهرست رمزها (راهنمای دستور ciphers در OpenSSL را ببینید).
"cipher-list": "AES",
// زمان انتظار برای اتصال مجدد.
// این پارامتر مشخص می‌کند Kea قبل از تلاش برای اتصال مجدد چه مدت
// منتظر بماند. بر حسب میلی‌ثانیه. پیش‌فرض برای MySQL
// و PostgreSQL برابر 0 (غیرفعال) است.
"reconnect-wait-time": 3000,
// حداکثر دفعات تلاش مجدد برای اتصال.
"max-reconnect-tries": 3,
// اقدامی که هنگام شکست بازیابی اتصال انجام می‌شود.
// مقادیر پشتیبانی‌شده: stop-retry-exit، serve-retry-exit،
// serve-retry-continue
"on-fail": "stop-retry-exit",
// پرچمی که مشخص می‌کند آیا بازیابی پایگاه‌داده باید در راه‌اندازی
// سرور و در رویدادهای بازپیکربندی تلاش شود یا خیر.
"retry-on-startup": false,
// مهلت زمانی برقراری اتصال بر حسب ثانیه.
"connect-timeout": 100,
// مهلت زمانی عملیات خواندن پایگاه‌داده بر حسب ثانیه.
"read-timeout": 120,
// مهلت زمانی عملیات نوشتن پایگاه‌داده بر حسب ثانیه.
"write-timeout": 180
},
{
// نام پایگاه‌داده جهت اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژه پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 5432,
// نوع پایگاه‌داده، مثلاً "mysql" یا "postgresql".
"type": "postgresql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// مهلت زمانی کاربری TCP حین ارتباط با پایگاه‌داده.
// بر حسب ثانیه مشخص می‌شود.
"tcp-user-timeout": 100,
// لنگر اعتماد یا همان فایل یا دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// حالت SSL.
"ssl-mode": "verify-ca"
}
],
// فهرست انواع شناسه‌های رزرو میزبان مورد استفاده توسط
// کارگزار Kea DHCPv6 برای واکشی رزروهای ایستا برای
// کلاینت‌های DHCP. به طور پیش‌فرض تمام شناسه‌ها استفاده می‌شوند،
// به این معنی که سرور چندین پرس‌وجو به پایگاه‌داده ارسال می‌کند تا متوجه
// شود آیا رزروی برای کلاینت خاص وجود دارد یا خیر. اگر یک استقرار خاص
// تنها از یک زیرمجموعه استفاده می‌کند (مثلاً یک نوع شناسه)،
// این شناسه فقط باید در اینجا فهرست شود تا از پرس‌وجوهای
// غیرضروری به پایگاه‌داده جلوگیری شود.
"host-reservation-identifiers": [
"hw-address",
"duid",
"flex-id"
],
// پیکربندی رابط‌هایی که کارگزار Kea DHCPv6 برای
// پرس‌وجوهای DHCP روی آن‌ها شنود می‌کند را مشخص می‌نماید.
"interfaces-config": {
// فهرستی از رابط‌ها را مشخص می‌کند که کارگزار Kea DHCPv6
// باید روی آن‌ها به درخواست‌های DHCP گوش فرا دهد.
"interfaces": [
"eth0"
],
// پرچم بولی که مشخص می‌کند آیا رابط‌های در دسترس باید
// هنگام بازپیکربندی سرور دوباره شناسایی شوند یا خیر. مقدار پیش‌فرض
// true است، به این معنی که رابط‌ها همیشه
// دوباره شناسایی می‌شوند.
"re-detect": true,
// سرور Kea هنگام مقداردهی اولیه تلاش می‌کند سوکت‌های سرویس را متصل (bind) کند،
// اما ممکن است به دلیل باز بودن قبلی درگاه یا پیکربندی نادرست با شکست مواجه شود. Kea می‌تواند
// این خطاها را نادیده گرفته و فقط آن‌ها را ثبت کند. این پرچم مانع از شروع
// کارگزار DHCP بدون اتصال موفق همه سوکت‌ها می‌شود. در صورت عدم تعیین،
// مقدار پیش‌فرض false است.
"service-sockets-require-all": true,
// سرور Kea هنگام مقداردهی اولیه تلاش می‌کند سوکت‌های سرویس را متصل کند. این
// گزینه مشخص می‌کند که اتصال به رابط چند بار دوباره تلاش شود.
// مقدار پیش‌فرض 0 است، به این معنی که عملیات تکرار
// نخواهد شد.
"service-sockets-max-retries": 5,
// بازه زمانی بر حسب میلی‌ثانیه برای انتظار قبل از تلاش بعدی جهت
// باز کردن مجدد یک سوکت سرویس.
"service-sockets-retry-wait-time": 5000
},
// پارامتر بولی که کنترل می‌کند آیا جستجوی زودهنگام رزروهای میزبان
// سراسری انجام شود یا خیر. این جستجو قبل از انتخاب زیرشبکه انجام
// می‌شود و هنگامی که یک رزرو سراسری با برخی از کلاس‌های کلاینت یافت شود،
// مرحله دوم طبقه‌بندی را فعال می‌کند. همچنین می‌تواند برای دور انداختن
// پرس‌وجوها با استفاده از رزروهای میزبان به عنوان یک جدول تصمیم‌گیری
// فهرست‌شده با شناسه‌های رزرو به کار رود.
"early-global-reservations-lookup": true,
// پارامتر بولی که رفتار کارگزار DHCP را در رابطه با ایجاد رزروهای
// میزبان برای آدرس IP یا پیشوند واگذارشده یکسان کنترل می‌کند. به طور
// پیش‌فرض این پرچم روی true تنظیم شده که در این حالت سرور از ایجاد چندین
// رزرو میزبان برای یک آدرس IP یا پیشوند واگذارشده یکسان جلوگیری می‌کند.
// وقتی این پارامتر روی false تنظیم شود، سرور اجازه ایجاد چندین رزرو برای
// آدرس IP یا پیشوند واگذارشده یکسان را در یک زیرشبکه می‌دهد. این تنظیم در
// استقرارهایی مفید است که در آن‌ها یک میزبان ممکن است از طریق چندین رابط با
// کارگزار DHCP ارتباط برقرار کند و بسته به رابط انتخابی، آدرس MAC مختلف
// (یا شناسه دیگر) برای شناسایی میزبان استفاده شود.
// توجه داشته باشید که برخی از backendهای میزبان از حالتی که در آن چندین
// رزرو برای یک آدرس IP یا پیشوند واگذارشده یکسان استفاده می‌شود پشتیبانی نمی‌کنند.
// اگر این backendها در حال استفاده باشند و این تنظیم اعمال شود، خطای
// پیکربندی رخ خواهد داد. backendهای MySQL و PostgreSQL از این حالت
// پشتیبانی می‌کنند.
"ip-reservations-unique": true,
// پارامتر بولی که کنترل می‌کند آیا جستجوی رزروهای میزبان باید قبل از
// جستجوی اجاره انجام شود یا خیر. این پارامتر تنها زمانی مؤثر است
// که چندنخی غیرفعال باشد. هنگامی که چندنخی فعال باشد،
// جستجوی رزروهای میزبان همیشه ابتدا انجام می‌شود تا از قفل شدن منابع
// هنگام جستجوی اجاره جلوگیری گردد.
"reservations-lookup-first": true,
// اطلاعات هویتی جهت دسترسی به پایگاه‌داده اجاره را مشخص می‌کند.
"lease-database": {
// پارامتر ویژه backend از نوع memfile که بازه زمانی بر حسب ثانیه را
// مشخص می‌کند که در آن فایل اجاره باید پاکسازی شود (ورودی‌های اجاره
// منسوخ حذف می‌شوند تا از رشد بی‌رویه فایل اجاره جلوگیری شود).
"lfc-interval": 3600,
// حداکثر تعداد خطاهای خواندن فایل اجاره که قبل از انصراف
// از بارگذاری فایل مجاز است. پیش‌فرض 0 (بدون محدودیت).
"max-row-errors": 100,
// نام فایل اجاره. در مورد پایگاه‌داده، نام پایگاه‌داده را
// مشخص می‌کند.
"name": "kea-leases6.csv",
// پارامتر ویژه memfile که مشخص می‌کند آیا اجاره‌ها باید روی فضای
// ذخیره‌سازی دائمی (دیسک) ذخیره شوند یا خیر. مقدار true پیش‌فرض
// است و نشان می‌دهد که اجاره‌ها در فضای ذخیره‌سازی دائمی ذخیره
// می‌شوند. این تنظیم باید در محیط عملیاتی استفاده شود.
// مقدار false صرفاً باید برای اهداف آزمایشی استفاده شود زیرا
// اجاره‌های ذخیره‌نشده با راه‌اندازی مجدد سرور Kea از دست خواهند رفت.
"persist": true,
// نوع backend پایگاه‌داده اجاره، یعنی "memfile"، "mysql" یا
// "postgresql".
"type": "memfile"
},
// فهرستی از پارامترها که مشخص می‌کند چگونه می‌توان آدرس MAC کلاینت را
// از پرس‌وجوی DHCP استنتاج کرد. مقادیر پشتیبانی‌شده در راهنمای
// مرجع مدیران Kea فهرست شده‌اند.
"mac-sources": [ "duid" ],
// فهرست گزینه‌های سراسری DHCP که کارگزار Kea DHCPv6 به کلاینت‌ها
// اختصاص می‌دهد.
"option-data": [
{
// پرچم بولی که مشخص می‌کند آیا گزینه داده‌شده همیشه در پاسخ
// ارسال شود یا تنها در صورت درخواست. مقدار پیش‌فرض false
// نشان می‌دهد که تنها در صورت درخواست ارسال می‌شود.
"always-send": false,
// فهرستی اختیاری از کلاس‌هایی که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه صرف‌نظر از عضویت در کلاس اعمال می‌شود.
"client-classes": [ "class1", "class2" ],
// کد گزینه. در صورت ارائه نام گزینه، نیازی به
// این فیلد نیست.
"code": 23,
// مقدار بولی که مشخص می‌کند آیا داده‌های گزینه مشخص‌شده در
// فیلد "data" به صورت رشته‌ای از ارقام هگزادسیمال است
// یا در قالب CSV خوانا برای انسان.
"csv-format": true,
// داده‌های گزینه جهت ذخیره در بخش بار داده (payload) گزینه.
"data": "2001:db8:2::45, 2001:db8:2::100",
// نام گزینه. در صورت ارائه کد گزینه، نیازی به
// این فیلد نیست.
"name": "dns-servers",
// پرچم بولی که مشخص می‌کند آیا گزینه داده‌شده هرگز در پاسخ
// ارسال نشود. مقدار پیش‌فرض false نشان می‌دهد که در صورت لزوم
// ارسال می‌شود. در صورت true بودن، گزینه علیرغم هر تنظیم دیگری
// ارسال نخواهد شد، یعنی یک پرچم قطعی و نهایی است.
"never-send": false,
// فضای گزینه. پیش‌فرض فضای گزینه "dhcp6" است که
// گزینه‌های سطح بالای DHCPv6 را دسته‌بندی می‌کند.
"space": "dhcp6"
}
],
// فهرستی از تعاریف سراسری گزینه، یعنی قالب‌های گزینه، که کارگزار
// Kea DHCPv6 از آن‌ها استفاده می‌کند.
"option-def": [
{
// پرچم بولی که مشخص می‌کند آیا تعریف گزینه شامل آرایه‌ای از
// مقادیر از یک نوع است (مثلاً آرایه‌ای از آدرس‌های IPv6) یا خیر.
// مقدار پیش‌فرض false به این معنی است که گزینه شامل آرایه‌ای
// از مقادیر نیست.
"array": false,
// کد گزینه.
"code": 6,
// حاوی نام فضای گزینه‌ای است که توسط این گزینه کپسوله‌سازی می‌شود.
// تمام گزینه‌های متعلق به این فضای گزینه به عنوان زیرگزینه‌های این گزینه
// ارسال خواهند شد. یک رشته خالی به این معنی است که این گزینه
// هیچ گزینه‌ای را کپسوله‌سازی نمی‌کند.
"encapsulate": "",
// نام گزینه.
"name": "my-option",
// انواع فیلدهای درون گزینه را در صورتی که گزینه به صورت "record"
// تعریف شده باشد مشخص می‌کند (به "type" مراجعه کنید). در این مثال
// خاص، این گزینه شامل دو فیلد با طول‌های ۱ بایت و ۲ بایت است.
"record-types": "uint8, uint16",
// نام فضای گزینه‌ای که این گزینه به آن تعلق دارد.
"space": "my-space",
// نوع گزینه. تمام انواع ممکن در راهنمای مرجع مدیران
// Kea فهرست شده‌اند.
"type": "record"
}
],
// مقدار سراسری که تعداد بسته‌های کلاینت (مانند REQUESTها، RENEWها...)
// را که ممکن است حین انتظار برای تکمیل کار کتابخانه قلاب قبل از ارسال
// پاسخ (مانند REPLY) به کلاینت متوقف (park) شوند، محدود می‌کند. یک مثال معمول زمانی
// است که kea-dhcp6 یک REQUEST را متوقف می‌کند در حالی که به‌روزرسانی(های) اجاره را به
// همتایان HA خود ارسال می‌نماید. پس از تایید به‌روزرسانی(ها)، بسته از حالت توقف خارج می‌شود.
// این مقدار تعداد بسته‌هایی را که می‌توانند در انتظار به‌روزرسانی‌ها نگهداری شوند محدود می‌کند.
// در زمان ترافیک سنگین کلاینت‌ها، این مقدار می‌تواند از ایجاد انباشت جبران‌ناپذیر به‌روزرسانی‌ها
// در kea-dhcp6 جلوگیری کند.
"parked-packet-limit": 256,
// مقدار سراسری (پیش‌فرض) مدت ترجیحی.
"preferred-lifetime": 50,
// حداقل مقدار سراسری مدت ترجیحی.
"min-preferred-lifetime": 40,
// حداکثر مقدار سراسری مدت ترجیحی.
"max-preferred-lifetime": 60,
// مقدار سراسری برای زمان‌سنج پیوند مجدد (rebind timer)، یعنی زمانی که
// پس از آن کلاینت DHCP در صورت عدم موفقیت در تمدید اجاره، وارد حالت پیوند مجدد می‌شود.
"rebind-timer": 40,
// فهرست کدهای گزینه‌های ارائه‌شده توسط رله. RFC 6422 را ببینید.
"relay-supplied-options": [ "110", "120", "130" ],
// مقدار سراسری برای زمان‌سنج تمدید (renew timer)، یعنی زمانی که
// پس از آن کلاینت DHCP اجاره را تمدید می‌کند.
"renew-timer": 30,
// مقدار سراسری برای ذخیره اطلاعات گسترش‌یافته (مانند اطلاعات عامل
// رله) همراه با هر اجاره.
"store-extended-info": true,
// آمارها نمونه‌هایی را برای هر نقطه مشاهده نگهداری می‌کنند.
// دو مقدار پیش‌فرض وجود دارد: حداکثر تعداد و حداکثر طول عمر.
// تنظیم حداکثر تعداد روی صفر آن را غیرفعال می‌کند.
"statistic-default-sample-count": 0,
// هنگامی که حداکثر تعداد 0 باشد، حداکثر طول عمر (بر حسب ثانیه) اعمال می‌شود.
"statistic-default-sample-age": 60,
// پارامترهای چندنخی.
"multi-threading": {
// به طور پیش‌فرض، اگر سخت‌افزار اجازه دهد، Kea بسته‌ها را روی چندین نخ پردازش می‌کند.
"enable-multi-threading": true,
// هنگام فعال بودن چندنخی، Kea بسته‌ها را روی تعداد مشخصی نخ پردازش می‌کند
// که از طریق این گزینه قابل پیکربندی است. مقدار باید یک عدد
// صحیح مثبت باشد (0 یعنی تشخیص خودکار).
"thread-pool-size": 0,
// هنگام فعال بودن چندنخی، Kea بسته‌ها را از رابط می‌خواند و یک مورد
// کاری را به مخزن نخ‌ها اضافه می‌کند. این گزینه حداکثر تعداد
// مواردی را که می‌توان در صف قرار داد پیکربندی می‌کند.
// مقدار باید یک عدد صحیح مثبت باشد (0 یعنی نامحدود).
"packet-queue-size": 0
},
// مشخص می‌کند که کارگزار Kea DHCPv6 چگونه باید با داده‌های
// نامعتبر دریافت شده از کلاینت برخورد کند.
"sanity-checks": {
// مشخص می‌کند که کارگزار Kea DHCPv6 در صورت خوانده شدن داده‌های نامعتبر
// برای یک اجاره از فایل اجاره چگونه باید رفتار کند. مقادیر زیر پشتیبانی
// می‌شوند: "none" (تلاشی برای اصلاح اطلاعات اجاره نکن)،
// "warn" (چاپ هشدار برای ناسازگاری‌های مربوط به subnet-id)،
// "fix" (اصلاح شناسه زیرشبکه با تلاش برای یافتن زیرشبکه مناسب)،
// "fix-del" (مشابه "fix"، اما در صورت عدم یافتن زیرشبکه مناسب، اجاره حذف شود)،
// "del" (حذف اجاره در صورتی که اجاره دارای مقدار شناسه زیرشبکه
// نامعتبر باشد).
"lease-checks": "warn",
// مشخص می‌کند که کارگزار Kea DHCPv4 هنگام خواندن اطلاعات
// گسترش‌یافته نامعتبر برای یک اجاره از فایل اجاره چگونه رفتار کند، یا
// اینکه آیا ارتقا از قالب قدیمی صورت گیرد یا خیر. مقادیر زیر
// پشتیبانی می‌شوند: "none" (تلاشی برای اصلاح یا ارتقای
// اطلاعات گسترش‌یافته نکن)، "fix" (رفع ناسازگاری‌های رایج و
// ارتقا از قالب قدیمی؛ این مقدار پیش‌فرض است)، "strict"
// (رفع ناسازگاری‌های دارای تاثیر بر Leasequery)،
// "pedantic" (اعمال قالب کامل کد Kea).
"extended-info-checks": "fix"
},
// شناسه DUID سفارشی مورد استفاده توسط کارگزار DHCPv6.
"server-id": {
// نوع DUID. مقادیر ممکن عبارتند از "LLT"، "EN" و "LL".
"type": "EN",
// شناسه سازمانی مورد استفاده برای duid نوع "EN".
"enterprise-id": 2495,
// بخش شناسه مربوط به DUID.
"identifier": "0123456789",
// پرچم بولی که مشخص می‌کند آیا DUID باید روی دیسک
// ذخیره پایدار بماند یا خیر.
"persist": false
},
// فهرست شبکه‌های اشتراکی مورد استفاده کارگزار Kea DHCPv6. شبکه‌های
// اشتراکی، زیرشبکه‌ها را با هم گروه‌بندی می‌کنند.
"shared-networks": [
{
// پرچمی جهت انتخاب راهبرد تخصیص آدرس IP برای همه
// زیرشبکه‌ها در این شبکه اشتراکی.
"allocator": "random",
// پرچمی جهت انتخاب راهبرد تخصیص پیشوند واگذارشده برای
// همه زیرشبکه‌ها در این شبکه اشتراکی.
"pd-allocator": "iterative",
// این شبکه اشتراکی را محدود می‌کند تا فقط به کلاینت‌هایی اجازه دهد
// که حداقل به یکی از کلاس‌های این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-override-client-update": false,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-override-no-update": false,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-qualifying-suffix": "",
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-replace-client-name": "never",
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-send-updates": true,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-update-on-renew": true,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیه آن صرفاً جهت سازگاری رو به عقب حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-ttl-percent": 0.65,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
// نمی‌توان هم ddns-ttl و هم هر یک از ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را مشخص کرد. آن‌ها مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-ttl-min": 10000,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-ttl-max": 20000,
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"hostname-char-replacement": "x",
// مقدار در سطح شبکه اشتراکی. به توضیحات در سطح سراسری مراجعه کنید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// مشخص می‌کند که این شبکه اشتراکی برای
// درخواست‌های دریافتی روی یک رابط خاص انتخاب شود.
"interface": "eth0",
// محتوای گزینه interface-id را مشخص می‌کند که توسط
// رله‌ها برای شناسایی رابطی روی رله که پاسخ به آن
// ارسال می‌شود، استفاده می‌گردد.
"interface-id": "",
// نام شبکه اشتراکی.
"name": "my-secret-network",
// فهرست گزینه‌های DHCP ویژه شبکه اشتراکی.
"option-data": [],
// مدت ترجیحی (پیش‌فرض) ویژه شبکه اشتراکی.
"preferred-lifetime": 2000,
// حداقل مدت ترجیحی ویژه شبکه اشتراکی.
"min-preferred-lifetime": 1500,
// حداکثر مدت ترجیحی ویژه شبکه اشتراکی.
"max-preferred-lifetime": 2500,
// پرچم بولی که مشخص می‌کند آیا سرور می‌تواند به یک
// پیام Solicit حاوی گزینه Rapid Commit با
// پیام Reply پاسخ دهد یا خیر (DHCPv6 rapid commit را ببینید).
"rapid-commit": false,
// فهرست آدرس‌های رله IPv6 که این شبکه
// اشتراکی برای آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": []
},
// زمان‌سنج پیوند مجدد در سطح شبکه اشتراکی.
"rebind-timer": 41,
// زمان‌سنج تمدید در سطح شبکه اشتراکی.
"renew-timer": 31,
// محاسبه زمان‌سنج‌های T1 و T2 در سطح شبکه اشتراکی.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانه حافظه موقت (cache threshold) = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر کش: هنگامی که زمان آخرین ارسال کلاینت به اندازه
// کافی نزدیک باشد، اجاره تمدید نمی‌شود و اجاره فعلی
// همان‌طور که "کَش شده بود" بازگردانده می‌شود.
"cache-max-age": 1000,
// آستانه تطبیقی زمان اجاره (1.0 یعنی غیرفعال).
"adaptive-lease-time-threshold": 0.8,
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون‌زیرشبکه‌ای را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند تمام آدرس‌های رزروشده
// خارج از استخر (out-of-pool) هستند یا خیر.
// در صورت false بودن reservations-in-subnet نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این شبکه اشتراکی
// برای تخصیص کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// خاموش کردن ذخیره‌سازی اطلاعات گسترش‌یافته (مانند اطلاعات عامل
// رله) همراه با هر اجاره برای این شبکه اشتراکی.
"store-extended-info": false,
// فهرست زیرشبکه‌های IPv6 متعلق به این شبکه اشتراکی.
"subnet6": [
{
// پرچمی جهت انتخاب راهبرد تخصیص آدرس IP برای
// این زیرشبکه.
"allocator": "iterative",
// پرچمی جهت انتخاب راهبرد تخصیص پیشوند واگذارشده
// برای این زیرشبکه.
"pd-allocator": "iterative",
// این زیرشبکه را محدود می‌کند تا فقط به کلاینت‌هایی اجازه دهد
// که حداقل به یکی از کلاس‌های این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-override-client-update": false,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-override-no-update": false,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-qualifying-suffix": "",
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-replace-client-name": "never",
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-send-updates": true,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-update-on-renew": true,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیه آن صرفاً جهت سازگاری رو به عقب حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
// "ddns-ttl-percent": 0.55,
// "ddns-ttl": 0,
// نمی‌توان هم ddns-ttl و هم هر یک از ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را مشخص کرد. آن‌ها مانعة‌الجمع هستند.
"ddns-ttl": 500,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
// "ddns-ttl-min": 10000,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
// "ddns-ttl-max": 20000,
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"hostname-char-replacement": "x",
// مقدار در سطح زیرشبکه. به توضیحات در سطح سراسری مراجعه کنید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// شناسه یکتای زیرشبکه.
"id": 1,
// مشخص می‌کند که این زیرشبکه برای درخواست‌های دریافتی
// روی یک رابط خاص انتخاب شود.
"interface": "eth0",
// محتوای گزینه interface-id را مشخص می‌کند که توسط
// رله‌ها برای شناسایی رابطی روی رله که پاسخ به آن
// ارسال می‌شود، استفاده می‌گردد.
"interface-id": "",
// روشن کردن ذخیره‌سازی اطلاعات گسترش‌یافته (مانند اطلاعات عامل
// رله) همراه با هر اجاره برای این زیرشبکه.
"store-extended-info": true,
// فهرست گزینه‌های DHCP در سطح زیرشبکه.
"option-data": [
{
// پرچم بولی که مشخص می‌کند آیا این گزینه خاص
// باید همیشه ارسال شود یا تنها در صورت درخواست.
"always-send": false,
// فهرستی اختیاری از کلاس‌هایی که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه صرف‌نظر از عضویت در کلاس اعمال می‌شود.
"client-classes": [],
// کد گزینه.
"code": 7,
// پرچم بولی که مشخص می‌کند آیا مقدار گزینه تعیین‌شده
// در "data" رشته‌ای از مقادیر هگزادسیمال است یا مقدار
// انسان‌خوانای CSV.
"csv-format": false,
// داده‌های گزینه جهت گنجانده شدن در بار داده گزینه.
"data": "0xf0",
// نام گزینه.
"name": "preference",
// پرچم بولی که مشخص می‌کند آیا گزینه داده‌شده هرگز
// در پاسخ ارسال نشود.
"never-send": false,
// فضای گزینه. مقدار پیش‌فرض "dhcp6" فضای گزینه
// سطح بالا را مشخص می‌کند.
"space": "dhcp6"
}
],
// فهرست استخرهایی که پیشوندهای واگذارشده از آن‌ها به
// کلاینت‌ها اختصاص می‌یابد.
"pd-pools": [
{
// این زیرشبکه استخر پیشوند را محدود می‌کند تا فقط به کلاینت‌هایی
// اجازه دهد که حداقل به یکی از کلاس‌های این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server1" ],
// طول پیشوندهای واگذارشده به کلاینت‌ها.
"delegated-len": 64,
// پیشوند (آدرس) مستثنی‌شده از تخصیص به کلاینت‌ها.
"excluded-prefix": "2001:db8:1::",
// پیشوند (طول) مستثنی‌شده از تخصیص به کلاینت‌ها.
"excluded-prefix-len": 72,
// فهرست گزینه‌های DHCP در سطح استخر پیشوند.
"option-data": [],
// محدوده پیشوند (آدرس) مورد استفاده برای تخصیص به کلاینت‌ها.
"prefix": "2001:db8:1::",
// محدوده پیشوند (طول) مورد استفاده برای تخصیص به کلاینت‌ها.
"prefix-len": 48,
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این استخر
// پیشوند برای تخصیص کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [],
// شناسه pd-pool مورد استفاده برای فعال‌سازی آمارها برای این pd-pool.
// شناسه pd-pool نیازی نیست درون زیرشبکه یا در میان زیرشبکه‌ها
// یکتا باشد. اگر پیکربندی نشده باشد، پیش‌فرض آن 0 است.
// آمارهای مربوط به این pd-pool با سایر آمارهای تمام
// pd-poolهای دیگر با همان شناسه pd-pool در این زیرشبکه ترکیب خواهد شد.
"pool-id": 1
},
{
// طول پیشوندهای واگذارشده به کلاینت‌ها.
"delegated-len": 64,
// محدوده پیشوند (آدرس) مورد استفاده برای تخصیص به کلاینت‌ها.
"prefix": "2001:db8:2::",
// محدوده پیشوند (طول) مورد استفاده برای تخصیص به کلاینت‌ها.
"prefix-len": 48
}
],
// فهرست استخرهای آدرس IP متعلق به زیرشبکه.
"pools": [
{
// این استخر زیرشبکه را محدود می‌کند تا فقط به کلاینت‌هایی
// اجازه دهد که حداقل به یکی از کلاس‌های این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server1" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدوده آدرس مورد استفاده برای تخصیص به کلاینت‌ها.
"pool": "2001:db8:0:1::/64",
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این استخر برای تخصیص
// کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-generated-prefix": "mypool",
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-override-client-update": false,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-override-no-update": false,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-qualifying-suffix": "pool.example.com.",
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-replace-client-name": "always",
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-send-updates": true,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-update-on-renew": false,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-ttl-percent": 0.55,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
// نمی‌توانید هم ddns-ttl و هم هر یک از ddns-ttl-percent،
// ddns-ttl-min یا ddns-ttl-max را مشخص کنید. آن‌ها مانعة‌الجمع هستند.
// "ddns-ttl": 500,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-ttl-min": 10000,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"ddns-ttl-max": 20000,
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"hostname-char-replacement": "x",
// مقدار در سطح استخر. به توضیحات در سطح سراسری مراجعه کنید.
"hostname-char-set": "[^A-Za-z0-9.-]"
},
{
// این استخر زیرشبکه را محدود می‌کند تا فقط به کلاینت‌هایی
// اجازه دهد که حداقل به یکی از کلاس‌های این فهرست تعلق دارند. در صورت حذف
// یا ارائه یک فهرست خالی، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server2" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدوده آدرس مورد استفاده برای تخصیص به کلاینت‌ها.
"pool": "2001:db8:0:3::/64",
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این استخر برای تخصیص
// کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [],
// شناسه استخر که برای فعال‌سازی آمارها برای این استخر استفاده می‌شود.
// شناسه استخر نیازی نیست در داخل زیرشبکه یا بین زیرشبکه‌ها
// یکتا باشد. اگر پیکربندی نشده باشد، پیش‌فرض 0 است.
// آمارهای مربوط به این استخر با سایر آمارهای تمام
// استخرهای دیگر با همان شناسه استخر در این زیرشبکه ترکیب می‌شود.
"pool-id": 1
}
],
// مدت ترجیحی (پیش‌فرض) ویژه زیرشبکه.
"preferred-lifetime": 2000,
// حداقل مدت ترجیحی ویژه زیرشبکه.
"min-preferred-lifetime": 1500,
// حداکثر مدت ترجیحی ویژه زیرشبکه.
"max-preferred-lifetime": 2500,
// پرچم بولی که مشخص می‌کند آیا سرور می‌تواند به یک
// پیام Solicit حاوی گزینه Rapid Commit با
// پیام Reply پاسخ دهد یا خیر (DHCPv6 rapid commit را ببینید).
"rapid-commit": false,
// مقدار زمان‌سنج پیوند مجدد در سطح زیرشبکه.
"rebind-timer": 40,
// فهرست آدرس‌های رله IPv6 که این زیرشبکه برای آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": [
"2001:db8:0:f::1"
]
},
// زمان‌سنج تمدید در سطح زیرشبکه.
"renew-timer": 30,
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون‌زیرشبکه‌ای را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند تمام آدرس‌های
// رزروشده خارج از استخر هستند یا خیر.
// در صورت false بودن reservations-in-subnet نادیده گرفته می‌شود.
"reservations-out-of-pool": false,
// محاسبه زمان‌سنج‌های T1 و T2 در سطح زیرشبکه.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانه حافظه موقت (cache threshold) = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر کش در سطح زیرشبکه.
"cache-max-age": 1000,
// آستانه تطبیقی زمان اجاره (1.0 یعنی غیرفعال).
"adaptive-lease-time-threshold": 0.8,
// فهرست رزروهای ایستای IPv6 اختصاص‌یافته به کلاینت‌های متعلق
// به این زیرشبکه. برای یک مثال دقیق، reservations.json را ببینید.
"reservations": [
{
// شناسه مورد استفاده برای تطبیق کلاینت. مقادیر پشتیبانی‌شده عبارتند از
// "duid"، "hw-address" و "flex-id".
"duid": "01:02:03:04:05:06:07:08:09:0A",
// فهرست آدرس‌های IPv6 رزروشده.
"ip-addresses": [ "2001:db8:1:cafe::1" ],
// فهرست پیشوندهای IPv6 رزروشده.
"prefixes": [ "2001:db8:2:abcd::/64" ],
// فهرست پیشوندهای IPv6 مستثنی‌شده.
"excluded-prefixes": [ "2001:db8:2:abcd:1::/80" ],
// نام میزبان رزروشده.
"hostname": "foo.example.com",
// داده‌های گزینه ویژه رزرو.
"option-data": [
{
// نام گزینه.
"name": "vendor-opts",
// مقدار گزینه.
"data": "4491"
}
]
}
],
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این زیرشبکه برای
// تخصیص کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// پیشوند زیرشبکه.
"subnet": "2001:db8::/32",
// مدت اعتبار (پیش‌فرض) در سطح زیرشبکه.
"valid-lifetime": 6000,
// حداقل مدت اعتبار در سطح زیرشبکه.
"min-valid-lifetime": 4000,
// حداکثر مدت اعتبار در سطح زیرشبکه.
"max-valid-lifetime": 8000
}
],
// مدت اعتبار (پیش‌فرض) در سطح شبکه اشتراکی.
"valid-lifetime": 6001,
// حداقل مدت اعتبار در سطح شبکه اشتراکی.
"min-valid-lifetime": 4001,
// حداکثر مدت اعتبار در سطح شبکه اشتراکی.
"max-valid-lifetime": 8001
}
],
// فهرست زیرشبکه‌های IPv6 که به هیچ شبکه اشتراکی تعلق ندارند.
"subnet6": [],
// مقدار سراسری مدت اعتبار.
"valid-lifetime": 6000,
// حداقل مقدار سراسری مدت اعتبار.
"min-valid-lifetime": 4000,
// حداکثر مقدار سراسری مدت اعتبار.
"max-valid-lifetime": 8000,
// رزروها (نمونه‌ها در فایل‌های دیگر هستند).
"reservations": [],
// کنترل پیکربندی (در حال حاضر استفاده نمی‌شود، یعنی این نحو
// از پیش تعریف شده اما قابلیت مربوط به آن پیاده‌سازی نشده است).
"config-control": {
// فقط ورودی پایگاه‌داده‌های پیکربندی تعریف شده است.
"config-databases": [
{
// نام پایگاه‌داده جهت اتصال.
"name": "config",
// نوع پایگاه‌داده، مثلاً "mysql" یا "postgresql".
"type": "mysql"
}
],
// بازه زمانی میان تلاش‌ها برای واکشی به‌روزرسانی‌های
// پیکربندی از طریق backendهای پیکربندی استفاده‌شده.
"config-fetch-wait-time": 30
},
// برچسب سرور.
"server-tag": "my DHCPv6 server",
// پارامترهای کنترل صف DHCP.
"dhcp-queue-control": {
// فعال‌سازی صف اجباری است.
"enable-queue": true,
// نوع صف اجباری است.
"queue-type": "kea-ring6",
// ظرفیت اختیاری است.
"capacity": 64
},
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون‌زیرشبکه‌ای را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند تمام آدرس‌های رزروشده
// خارج از استخر هستند یا خیر.
// در صورت false بودن reservations-in-subnet نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "shared-networks" و
// "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// محاسبه زمان‌سنج‌های T1 و T2 در سطح سراسری.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانه حافظه موقت (cache threshold) = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر کش در سطح سراسری.
"cache-max-age": 1000,
// آستانه تطبیقی زمان اجاره (1.0 یعنی غیرفعال)
"adaptive-lease-time-threshold": 0.8,
// رشته‌ای از صفر یا چند نویسه که با هر نویسه نامعتبر
// در Client FQDN جایگزین می‌شود. مقدار پیش‌فرض
// یک رشته خالی است که باعث می‌شود نویسه‌های نامعتبر به جای
// جایگزینی، حذف شوند.
"hostname-char-replacement": "x",
// عبارت باقاعده توصیف‌کننده مجموعه نویسه‌های نامعتبر در
// Client FQDN.
"hostname-char-set": "[^A-Za-z0-9.-]",
// فهرست گزارش‌گیرهای (loggers) مورد استفاده سرورهایی که از این فایل پیکربندی استفاده می‌کنند.
"loggers": [
{
// سطح اشکال‌زدایی (debug level)، مقداری بین 0..99. هر چه مقدار بزرگ‌تر
// باشد، لاگ اشکال‌زدایی جزئیات بیشتری دارد.
"debuglevel": 99,
// نام گزارش‌گیر.
"name": "kea-dhcp6",
// نحوه خروجی دادن لاگ را پیکربندی می‌کند.
"output-options": [
{
// مشخص می‌کند که آیا لاگ باید بی‌درنگ در فایل تخلیه (flush) شود یا خیر.
"flush": true,
// حداکثر اندازه فایل قبل از چرخش فایل را مشخص می‌کند.
"maxsize": 10240000,
// حداکثر تعداد فایل‌های چرخیده نگهداری‌شده را مشخص می‌کند.
"maxver": 1,
// مقصد ثبت گزارش را مشخص می‌کند.
"output": "stdout",
// محتوای ورودی لاگ را مشخص می‌کند
"pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// شدت ثبت گزارش را مشخص می‌کند، یعنی "ERROR"، "WARN"، "INFO"، "DEBUG".
"severity": "INFO"
}
],
// برای استفاده از user-contexts به مثال‌های پیشرفته نگاه کنید.
"user-context": { }
}
}
168u
0.0
3.5
// هشدار: این پیکربندی نمونه برای استفاده در محیط عملیاتی نیست.
// کارگزار Kea DHCPv6 این پیکربندی را نخواهد پذیرفت زیرا حاوی
// پارامترهای پیکربندی متقابلاً ناسازگار است.
//
// هدف اصلی این فایل نمونه، ارائهٔ فهرستی جامع از پارامترهای
// پشتیبانی‌شده توسط کارگزار Kea DHCPv6 به همراه توضیحی کوتاه
// دربارهٔ هر پارامتر است.
//
// نسخهٔ فعلی باید به‌روز باشد، یعنی کلمات کلیدی جدید باید
// هم‌زمان با مشخصات تجزیه‌کننده به این فایل اضافه شوند.
{
// پیکربندی کارگزار Kea DHCPv6 از اینجا آغاز می‌شود.
"Dhcp6": {
// پرچم سراسری برای انتخاب راهبرد تخصیص نشانی IP برای همهٔ
// زیرشبکه‌ها.
"allocator": "iterative",
// پرچم سراسری که ثبت نشانی کلاینت را از طریق بسته‌های
// ADDR-REG-INFORM فعال یا غیرفعال می‌کند (RFC 9686 را ببینید). پیش‌فرض آن true است.
"allow-address-registration": true,
// پرچم سراسری برای انتخاب راهبرد تخصیص پیشوند واگذارشده
// برای همهٔ زیرشبکه‌ها.
"pd-allocator": "random",
// فهرست مرتب‌شده‌ای از کلاس‌های کلاینت که توسط کارگزار DHCPv6 استفاده می‌شود.
"client-classes": [
{
// نام کلاس.
"name": "phones_server1",
// فهرست گزینه‌های DHCPv6 ویژهٔ کلاس.
"option-data": [],
// عبارت انتخاب کلاس. هنگامی که مقدار عبارت داده‌شده true
// ارزیابی شود، بستهٔ DHCP به این کلاس اختصاص می‌یابد.
"test": "member('HA_server1')",
// طول‌عمر معتبر کلاس.
"valid-lifetime": 6000,
// حداقل طول‌عمر معتبر کلاس.
"min-valid-lifetime": 4000,
// حداکثر طول‌عمر معتبر کلاس.
"max-valid-lifetime": 8000,
// طول‌عمر ترجیحی کلاس.
"preferred-lifetime": 7000,
// حداقل طول‌عمر ترجیحی کلاس.
"min-preferred-lifetime": 5000,
// حداکثر طول‌عمر ترجیحی کلاس.
"max-preferred-lifetime": 9000
},
{
// نام کلاس دوم.
"name": "phones_server2",
// فهرست گزینه‌های DHCPv6 ویژهٔ کلاس.
"option-data": [],
// عبارت انتخاب کلاس. هنگامی که مقدار عبارت داده‌شده true
// ارزیابی شود، بستهٔ DHCP به این کلاس اختصاص می‌یابد.
"test": "member('HA_server2')"
},
{
// نام کلاس سوم.
"name": "late",
// پرچم بولی که مشخص می‌کند آیا عبارت کلاس فقط در صورت نیاز
// ارزیابی شود یا خیر؛ برای مثال، زمانی که پیکربندی استخر نشانیِ انتخاب‌شده،
// این نام کلاس را در فهرست "evaluate-additional-classes" خود شامل شود.
// مقدار پیش‌فرض false بدان معناست که عبارت آزمون کلاس باید
// همیشه ارزیابی شود.
"only-in-additional-list": true,
// عبارت انتخاب کلاس.
"test": "member('ALL')"
},
{
// نام کلاس چهارم.
"name": "my-template-class",
// پرچم کلاس الگو که حاوی عبارتی برای تولید نام تمام
// زیرکلاس‌های ایجادشده است. در این حالت، کلاس‌ها بر اساس شناسهٔ کلاینت نام‌گذاری می‌شوند.
"template-test": "substring(option[1].hex, 0, all)"
}
],
// پارامترهایی برای فعال‌سازی رفتارهای سازگار با کلاینت‌ها،
// رله‌ها یا سایر عامل‌های ناسازگار یا معیوب
"compatibility": {
// تجزیهٔ آسان‌گیرانه‌تر گزینه‌ها در جایی که فیلدها را می‌توان به طور قطعی
// استنتاج کرد، حتی اگر خلاف RFC یا رویهٔ معمول باشد.
"lenient-option-parsing": true
},
// پارامترهای پیکربندی سوکت کنترل فرمان برای کارگزار Kea DHCPv6.
"control-sockets": [
{
// نوع سوکت کنترلی که توسط کارگزار Kea DHCPv6 استفاده می‌شود.
// باید unix، http یا https باشد.
"socket-type": "unix",
// مکان فایل سوکت دامنهٔ یونیکس که کارگزار DHCPv6 برای دریافت فرمان‌های
// کنترلی از مدیر محلی سرور استفاده می‌کند.
"socket-name": "kea6-ctrl-socket"
},
{
// نوع سوکت کنترلی که توسط کارگزار Kea DHCPv6 استفاده می‌شود.
// باید unix، http یا https باشد.
"socket-type": "https",
// نشانی سوکت HTTPS که کارگزار Kea DHCPv6 باید برای
// پرس‌وجوهای ورودی روی آن گوش فرا دهد.
"socket-address": "::1",
// درگاه سوکت HTTPS که کارگزار Kea DHCPv6 باید برای
// پرس‌وجوهای ورودی روی آن گوش فرا دهد. در صورت فعال‌سازی HA و
// چندنخی، درگاه 8000 توسط شنوندهٔ http کتابخانهٔ قلاب HA استفاده می‌شود.
// هنگام استفاده از کتابخانهٔ قلاب HA با چندنخی، مطمئن شوید
// درگاهی که توسط شنوندهٔ اختصاصی استفاده می‌شود با درگاه مشخص‌شده در اینجا
// متفاوت است (مثلاً 8001). توجه داشته باشید که فرمان‌ها همچنان
// باید به یک سوکت کنترل ارسال شوند. شنوندهٔ اختصاصی
// صرفاً برای به‌روزرسانی‌های HA است.
"socket-port": 8006,
// مرجع اعتماد TLS (مرجع صدور گواهی یا CA). این مقدار نام فایل یا
// مسیر یک دایرکتوری است. همراه با سایر پارامترهای TLS
// فقط برای سوکت کنترلی از نوع https معنادار است.
"trust-anchor": "my-ca",
// نام فایل گواهی سرور TLS.
"cert-file": "my-cert",
// نام فایل کلید خصوصی سرور TLS.
"key-file": "my-key",
// پرچم الزام گواهی کلاینت در TLS. پیش‌فرض true است
// و به معنای الزام گواهی‌های کلاینت است. مقدار false
// به معنای اختیاری بودن آن‌هاست.
"cert-required": true,
// سرآیندهای اضافی HTTP برای افزودن به پاسخ‌ها.
"http-headers":
[
{
// بافت کاربری اختیاری.
"user-context": { "comment": "HSTS header" },
// نام سرآیند الزامی HTTP.
"name": "Strict-Transport-Security",
// مقدار سرآیند الزامی HTTP.
"value": "max-age=31536000"
}
],
// احراز هویت اختیاری.
"authentication": {
// نوع احراز هویت الزامی. تنها مقدار پشتیبانی‌شده
// basic برای احراز هویت پایه‌ای HTTP است.
"type": "basic",
// پارامتر اختیاری قلمرو (realm) احراز هویت پایه‌ای HTTP است.
// پیش‌فرض آن "kea-dhcpv6-server" است.
"realm": "kea-dhcpv6-server",
// از این پارامتر اختیاری می‌توان برای تعیین یک پیشوند مشترک برای
// فایل‌های حاوی اعتبارنامه‌های کلاینت استفاده کرد.
"directory": "/usr/local/share/kea/kea-creds",
// این فهرست شناسه‌های کاربری و گذرواژه‌ها را برای استفاده در
// احراز هویت پایه‌ای HTTP مشخص می‌کند. در صورت خالی بودن یا عدم حضور،
// هر کلاینتی مجاز شمرده می‌شود.
"clients": [
// این گزینه یک کلاینت مجاز را مشخص می‌کند.
{
// شناسهٔ کاربر نباید خالی باشد یا حاوی نویسهٔ ':' باشد.
// این یک پارامتر اجباری است.
"user": "admin",
// در صورت مشخص نشدن گذرواژه، از گذرواژهٔ
// خالی استفاده می‌شود.
"password": "1234"
},
// این گزینه یک کلاینت پنهان را مشخص می‌کند.
{
// شناسهٔ کاربر محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenu است.
"user-file": "hiddenu",
// گذرواژه محتوای فایل
// /usr/local/share/kea/kea-creds/hiddenp است.
"password-file": "hiddenp"
},
// این گزینه یک کلاینت پنهان را با استفاده از
// یک راز درون فایل مشخص می‌کند.
{
// راز، محتوای فایل /usr/local/share/kea/kea-creds/hiddens
// است که باید در قالب <user-id>:<password> باشد.
"password-file": "hiddens"
}
]
}
}
],
// پیشوندی را برای الحاق به ابتدای FQDN تولیدشدهٔ کلاینت مشخص می‌کند.
// این مقدار می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-generated-prefix": "myhost",
// پرچم بولی که مشخص می‌کند آیا سرور باید خواستهٔ کلاینت DHCP را برای
// به‌روزرسانی مستقل DNS نادیده بگیرد یا خیر. با تنظیم این پرچم روی true،
// سرور به‌روزرسانی‌های DNS را برای هر دو دادهٔ رفت و برگشت
// ارسال می‌کند. مقدار پیش‌فرض false است که نشان می‌دهد سرور
// در صورت درخواست، به‌روزرسانی DNS را به کلاینت واگذار می‌کند.
// این مقدار می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-override-client-update": false,
// پرچم بولی که مشخص می‌کند آیا سرور باید بر تمایل کلاینت DHCP مبنی بر
// عدم به‌روزرسانی DNS اولویت داشته باشد یا خیر. با تنظیم این پارامتر روی true،
// سرور حتی زمانی که کلاینت درخواست عدم به‌روزرسانی داده باشد نیز به‌روزرسانی DNS
// را ارسال خواهد کرد. این مقدار می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-override-no-update": false,
// پسوندی که به انتهای نام ناقص ارسال‌شده به DNS اضافه می‌شود. مقدار
// پیش‌فرض یک رشتهٔ خالی است که نشان می‌دهد هیچ پسوندی اضافه نمی‌شود.
// این مقدار می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-qualifying-suffix": "",
// شمارشی که مشخص می‌کند آیا سرور باید به hostname یا Client FQDN ارسال‌شده
// توسط کلاینت احترام بگذارد یا این نام را جایگزین کند. مقادیر پذیرفته‌شده
// عبارتند از: "never" (استفاده از نام ارسالی کلاینت)، "always" (جایگزینی
// نام ارسالی کلاینت)، "when-present" (جایگزینی نام ارسالی کلاینت، اما عدم
// تولید نام در صورتی که کلاینت نامی ارسال نکرده باشد)، "when-not-present"
// (تولید نام هنگامی که کلاینت نامی ارسال نکرده باشد، در غیر این صورت
// حفظ نام ارسالی کلاینت). مقدار پیش‌فرض "never" است. این مقدار می‌تواند
// در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-replace-client-name": "never",
// پرچم بولی که به‌روزرسانی DDNS را فعال یا غیرفعال می‌کند. پیش‌فرض
// آن true است. می‌تواند در سطوح سراسری، shared-network
// و subnet تعیین شود. این گزینه همراه با dhcp-ddns:enable-updates
// کار می‌کند که برای فعال‌سازی اتصال به kea-dhcp-ddns باید true باشد.
"ddns-send-updates": true,
// پرچم بولی که در صورت true بودن، به سرور دستور می‌دهد همیشه هنگام تمدید
// اجاره‌ها، DNS را به‌روز کند، حتی اگر اطلاعات DNS تغییری نکرده باشد.
// رفتار پیش‌فرض سرور (یعنی false بودن پرچم) این است که فقط در صورت
// تغییر اطلاعات DNS، آن را به‌روزرسانی کند. می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-update-on-renew": true,
// پرچم بولی که با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns
// ارسال می‌شود تا مشخص کند آیا حل تعارض به‌روزرسانی DNS طبق RFC 4703
// باید برای درخواست به‌روزرسانی مربوطه اعمال شود یا خیر. مقدار پیش‌فرض این پرچم true است.
// می‌تواند در سطوح سراسری، shared-network و subnet تعیین شود.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیهٔ آن صرفاً برای سازگاری عقبرو حفظ شده است.
// "ddns-use-conflict-resolution": true,
// شمارشی که همراه با هر درخواست به‌روزرسانی DDNS به kea-dhcp-ddns ارسال می‌شود
// تا حالت مورد استفاده برای حل تعارض‌ها هنگام انجام به‌روزرسانی‌های DDNS را مشخص کند.
// مقادیر پذیرفته‌شده عبارتند از:
// check-with-dhcid (شامل افزودن رکورد DHCID و بررسی آن رکورد از طریق تشخیص تعارض مطابق RFC 4703)،
// no-check-with-dhcid (نادیده گرفتن تشخیص تعارض اما افزودن رکورد DHCID هنگام ایجاد/به‌روزرسانی یک مدخل)،
// check-exists-with-dhcid (بررسی وجود یک رکورد DHCID موجود بدون بررسی تطابق مقدار رکورد با به‌روزرسانی.
// این حالت همچنین رکورد DHCID را برای مدخل به‌روز می‌کند)،
// no-check-without-dhcid (نادیده گرفتن تشخیص تعارض و عدم افزودن رکورد DHCID هنگام ایجاد/به‌روزرسانی مدخل DDNS).
// مقدار پیش‌فرض "check-with-dhcid" است. این مقدار می‌تواند
// در سطوح سراسری، shared-network و subnet تعیین شود.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// در صورتی که بزرگ‌تر از 0.0 باشد، درصدی از طول‌عمر اجاره است
// که برای TTL در DNS استفاده می‌شود.
"ddns-ttl-percent": 0.75,
// در صورتی که بزرگ‌تر از 0 باشد، به عنوان TTL در DNS استفاده خواهد شد. بر حسب ثانیه مشخص می‌شود.
// نمی‌توان هم‌زمان ddns-ttl و هر یک از مقادیر ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را تعیین کرد. آن‌ها متقابلاً ناسازگار هستند.
// "ddns-ttl": 500,
// در صورتی که بزرگ‌تر از 0 باشد، به عنوان کران پایین برای مقادیر محاسبه‌شدهٔ TTL در DNS استفاده می‌شود.
// بر حسب ثانیه مشخص می‌شود.
"ddns-ttl-min": 24000,
// در صورتی که بزرگ‌تر از 0 باشد، به عنوان کران بالا برای مقادیر محاسبه‌شدهٔ TTL در DNS استفاده می‌شود.
// بر حسب ثانیه مشخص می‌شود.
"ddns-ttl-max": 64000,
// زمان بر حسب ثانیه که مشخص می‌کند یک اجارهٔ ردشده چه مدت باید
// از تخصیص‌های DHCP مستثنی شود. مقدار پیش‌فرض ۲۴ ساعت است.
"decline-probation-period": 86400,
// پیکربندی ارسال درخواست تغییر نام (NCR) برای کارگزار Kea DHCPv6.
// درخواست‌های NCR پس از تخصیص اجاره‌های DHCP برای به‌روزرسانی DNS
// به ماژول Kea D2 ارسال می‌شوند.
"dhcp-ddns": {
// پرچم بولی که مشخص می‌کند آیا کارگزار Kea DHCPv6 باید به
// kea-dhcp-ddns متصل شود یا خیر. این مقدار برای ایجاد و ارسال
// NCRها به kea-dhcp-ddns باید true باشد. به طور پیش‌فرض، NCRها تولید نمی‌شوند.
"enable-updates": false,
// حداکثر تعداد NCRهایی که در صف انتظار برای ارسال
// به کارگزار Kea D2 قرار می‌گیرند را مشخص می‌کند.
"max-queue-size": 1024,
// قالب بسته‌ای که هنگام ارسال NCRها به کارگزار Kea D2 استفاده می‌شود.
// در حال حاضر، فقط قالب JSON پشتیبانی می‌شود.
"ncr-format": "JSON",
// پروتکل سوکت مورد استفاده هنگام ارسال NCRها به D2. در حال حاضر،
// فقط UDP پشتیبانی می‌شود.
"ncr-protocol": "UDP",
// نشانی IP که کارگزار Kea DHCPv6 باید برای ارسال NCRها به D2
// استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید یک نشانی مناسب را انتخاب کند.
"sender-ip": "::1",
// شماره درگاهی که کارگزار Kea DHCPv6 باید برای ارسال NCRها به D2
// استفاده کند. مقدار پیش‌فرض صفر نشان می‌دهد که Kea
// باید یک درگاه مناسب را انتخاب کند.
"sender-port": 0,
// نشانی IP که D2 روی آن به NCRها گوش می‌دهد.
"server-ip": "::1",
// شماره درگاهی که D2 روی آن به NCRها گوش می‌دهد.
"server-port": 53001
},
// اولین درگاه از دو درگاه متوالی سوکت‌های UDP مورد استفاده برای ارتباط
// بین کارگزارهای DHCPv6 و DHCPv4 را مشخص می‌کند. RFC 7341 را ببینید.
// (پیش‌فرض 0 - غیرفعال).
// در صورت فعال بودن، مثلاً از 786 استفاده کنید.
"dhcp4o6-port": 0,
// مجموعه‌ای از پارامترهای کارگزار Kea DHCPv6 که نحوهٔ پردازش
// اجاره‌های منقضی‌شدهٔ DHCP توسط کارگزار را پیکربندی می‌کند.
"expired-leases-processing": {
// تعداد ثانیه‌های گذشته از آخرین حذف اجاره‌های منقضی‌شده را مشخص می‌کند
// که پس از آن باید حذف بعدی رخ دهد.
// اگر هر دو مقدار "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" غیر صفر باشند، هنگامی که کلاینت پیام آزادسازی
// ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره،
// منقضی می‌شود.
"flush-reclaimed-timer-wait-time": 25,
// مدت‌زمان بر حسب ثانیه برای نگه‌داشتن اجاره‌های منقضی‌شده
// در پایگاه‌دادهٔ اجاره (همبستگی اجاره) را مشخص می‌کند.
// اگر هر دو مقدار "flush-reclaimed-timer-wait-time" و
// "hold-reclaimed-time" غیر صفر باشند، هنگامی که کلاینت پیام آزادسازی
// ارسال می‌کند، اجاره به جای حذف شدن از فضای ذخیره‌سازی اجاره،
// منقضی می‌شود.
"hold-reclaimed-time": 3600,
// حداکثر تعداد اجاره‌های منقضی‌شده‌ای که می‌توان در یک تلاش برای
// پاک‌سازی از پایگاه‌دادهٔ اجاره پردازش کرد را مشخص می‌کند. اگر اجاره‌های
// منقضی‌شدهٔ بیشتری وجود داشته باشد، در تلاش بعدی پاک‌سازی
// پردازش خواهند شد.
"max-reclaim-leases": 100,
// حداکثر زمانی بر حسب میلی‌ثانیه که یک تلاش واحد برای پاک‌سازی
// اجاره‌های منقضی‌شده از پایگاه‌دادهٔ اجاره می‌تواند طول بکشد را مشخص می‌کند.
"max-reclaim-time": 250,
// مدت‌زمان بر حسب ثانیه از آخرین تلاش برای پردازش اجاره‌های منقضی‌شده
// پیش از آغاز تلاش بعدی را مشخص می‌کند.
"reclaim-timer-wait-time": 10,
// حداکثر تعداد چرخه‌های پردازش اجاره‌های منقضی‌شده که منجر به
// پاک‌سازی کامل از پایگاه‌دادهٔ اجاره نشده‌اند را مشخص می‌کند
// که پس از آن یک پیام هشدار صادر می‌شود.
"unwarned-reclaim-cycles": 5
},
// فهرست کتابخانه‌های قلاب و پارامترهای پیکربندی خاص آن‌ها
// که باید توسط کارگزار Kea DHCPv4 بارگیری شوند.
"hooks-libraries": [
{
// مکان کتابخانهٔ قلاب که باید بارگیری شود.
"library": "libdhcp_lease_cmds.so",
// پارامترهای پیکربندی ویژهٔ کتابخانهٔ قلاب.
"parameters": { }
},
{
// کتابخانهٔ قلاب پسانهٔ میزبان MySQL که برای ذخیره‌سازی میزبان مورد نیاز است.
"library": "libdhcp_mysql.so"
},
{
// کتابخانهٔ قلاب پسانهٔ میزبان PostgreSQL که برای ذخیره‌سازی میزبان مورد نیاز است.
"library": "libdhcp_pgsql.so"
}
],
// فهرست اعتبارنامه‌های دسترسی به منابع خارجی رزروهای IPv6،
"hosts-databases": [
{
// نام پایگاه‌داده برای اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژهٔ پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 3306,
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "mysql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// حالت فقط‌خواندنی.
"readonly": false,
// مدخل‌های بعدی برای پشتیبانی از OpenSSL در MySQL هستند.
// مرجع اعتماد یا همان فایل یا دایرکتوری مرجع صدور گواهی.
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// فهرست رمزها (راهنمای دستور ciphers در OpenSSL را ببینید).
"cipher-list": "AES",
// زمان انتظار برای اتصال مجدد.
// این پارامتر مشخص می‌کند که Kea قبل از تلاش برای اتصال مجدد چه مدت منتظر بماند.
// بر حسب میلی‌ثانیه بیان می‌شود. مقدار پیش‌فرض برای MySQL و PostgreSQL
// برابر 0 (غیرفعال) است.
"reconnect-wait-time": 3000,
// حداکثر دفعات تلاش برای اتصال مجدد.
"max-reconnect-tries": 3,
// اقدامی که هنگام شکست بازیابی اتصال انجام می‌شود.
// مقادیر پشتیبانی‌شده: stop-retry-exit، serve-retry-exit،
// serve-retry-continue
"on-fail": "stop-retry-exit",
// پرچمی که مشخص می‌کند آیا باید هنگام راه‌اندازی سرور
// و رویدادهای پیکربندی مجدد، بازیابی پایگاه‌داده انجام شود یا خیر.
"retry-on-startup": false,
// مهلت زمانی اتصال بر حسب ثانیه.
"connect-timeout": 100,
// مهلت زمانی عملیات خواندن پایگاه‌داده بر حسب ثانیه.
"read-timeout": 120,
// مهلت زمانی عملیات نوشتن پایگاه‌داده بر حسب ثانیه.
"write-timeout": 180
},
{
// نام پایگاه‌داده برای اتصال.
"name": "keatest",
// میزبانی که پایگاه‌داده روی آن قرار دارد.
"host": "localhost",
// گذرواژهٔ پایگاه‌داده.
"password": "1234",
// درگاهی که پایگاه‌داده روی آن در دسترس است.
"port": 5432,
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "postgresql",
// نام کاربری مورد استفاده برای دسترسی به پایگاه‌داده.
"user": "keatest",
// مهلت زمانی کاربر TCP هنگام برقراری ارتباط با پایگاه‌داده.
// بر حسب ثانیه مشخص می‌شود.
"tcp-user-timeout": 100,
// مرجع اعتماد یا همان فایل یا دایرکتوری مرجع صدور گواهی.
"trust-anchor": "my-ca",
// نام فایل گواهی کلاینت.
"cert-file": "my-cert",
// نام فایل کلید خصوصی.
"key-file": "my-key",
// حالت SSL.
"ssl-mode": "verify-ca"
}
],
// فهرست انواع شناسه‌های رزرو میزبان که توسط کارگزار Kea DHCPv6
// برای واکشی رزروهای ایستا برای کلاینت‌های DHCP استفاده می‌شود.
// به طور پیش‌فرض از تمام شناسه‌ها استفاده می‌شود، به این معنی که سرور
// برای بررسی وجود رزرو برای یک کلاینت خاص، چندین پرس‌وجو
// به پایگاه‌داده ارسال می‌کند. اگر در یک استقرار خاص تنها از یک زیرمجموعه
// (مثلاً یک نوع شناسه) استفاده می‌شود، برای جلوگیری از پرس‌وجوهای غیرضروری به پایگاه‌داده،
// فقط باید همان شناسه در اینجا ذکر شود.
"host-reservation-identifiers": [
"hw-address",
"duid",
"flex-id"
],
// پیکربندی رابط‌هایی را مشخص می‌کند که کارگزار Kea DHCPv6
// روی آن‌ها به پرس‌وجوهای DHCP گوش می‌دهد.
"interfaces-config": {
// فهرستی از رابط‌ها را مشخص می‌کند که کارگزار Kea DHCPv6
// باید روی آن‌ها به درخواست‌های DHCP گوش دهد.
"interfaces": [
"eth0"
],
// پرچم بولی که مشخص می‌کند آیا رابط‌های موجود باید در هنگام
// پیکربندی مجدد سرور دوباره شناسایی شوند یا خیر. مقدار پیش‌فرض
// true است، به این معنی که رابط‌ها همیشه دوباره شناسایی می‌شوند.
"re-detect": true,
// Kea در حین مقداردهی اولیه سعی می‌کند سوکت‌های سرویس را متصل کند،
// اما ممکن است به دلیل باز بودن قبلی یک درگاه یا پیکربندی نادرست با شکست مواجه شود.
// Kea می‌تواند این خطاها را نادیده بگیرد و فقط ثبت کند. این پرچم
// از شروع به کار کارگزار DHCP بدون اتصال موفقیت‌آمیز تمام سوکت‌ها جلوگیری می‌کند.
// در صورت عدم تعیین، پیش‌فرض false است.
"service-sockets-require-all": true,
// Kea در حین مقداردهی اولیه سعی می‌کند سوکت‌های سرویس را متصل کند. این
// گزینه مشخص می‌کند که تلاش برای اتصال به رابط چند بار تکرار خواهد شد.
// مقدار پیش‌فرض 0 است، به این معنی که عملیات تکرار نخواهد شد.
"service-sockets-max-retries": 5,
// بازهٔ زمانی بر حسب میلی‌ثانیه برای انتظار پیش از تلاش بعدی جهت
// باز کردن مجدد یک سوکت سرویس.
"service-sockets-retry-wait-time": 5000
},
// پارامتر بولی که کنترل می‌کند آیا جستجوی زودهنگام رزروهای سراسری میزبان
// باید انجام شود یا خیر. این جستجو قبل از انتخاب زیرشبکه انجام می‌شود
// و هنگامی که یک رزرو سراسری با برخی کلاس‌های کلاینت یافت شود،
// فاز دوم دسته‌بندی را فعال می‌کند. همچنین می‌توان از آن برای رد کردن
// پرس‌وجوها با استفاده از رزروهای میزبان به عنوان جدول تصمیم‌گیری
// نمایه‌شده با شناسه‌های رزرو استفاده کرد.
"early-global-reservations-lookup": true,
// پارامتر بولی که رفتار کارگزار DHCP را در رابطه با ایجاد رزروهای میزبان
// برای یک نشانی IP یا پیشوند واگذارشدهٔ یکسان کنترل می‌کند. به طور پیش‌فرض این پرچم
// روی true تنظیم شده است که در این حالت، سرور از ایجاد چندین رزرو میزبان
// برای یک نشانی IP یا پیشوند واگذارشده یکسان جلوگیری می‌کند. وقتی این پارامتر
// روی false تنظیم شود، سرور اجازهٔ ایجاد چندین رزرو برای یک نشانی IP یا
// پیشوند واگذارشده یکسان را درون یک زیرشبکه می‌دهد. این تنظیم در استقرارهایی مفید است
// که در آن‌ها ممکن است یک میزبان مشخص از طریق چندین رابط با کارگزار DHCP ارتباط برقرار کند
// و بسته به رابط انتخاب‌شده، از نشانی‌های MAC (یا شناسه‌های دیگر) متفاوتی
// برای شناسایی میزبان استفاده شود. توجه داشته باشید که برخی از پسانه‌های میزبان از حالتی
// که چندین رزرو برای یک نشانی IP یا پیشوند واگذارشده یکسان استفاده می‌شود پشتیبانی نمی‌کنند.
// اگر از این پسانه‌ها استفاده شود و این تنظیم اعمال گردد، خطای پیکربندی رخ خواهد داد.
// پسانه‌های MySQL و PostgreSQL از این حالت پشتیبانی می‌کنند.
"ip-reservations-unique": true,
// پارامتر بولی که کنترل می‌کند آیا جستجوی رزروهای میزبان باید پیش از
// جستجوی اجاره انجام شود یا خیر. این پارامتر فقط زمانی اثر دارد که
// چندنخی غیرفعال باشد. هنگامی که چندنخی فعال است، جستجوی رزروهای
// میزبان همیشه ابتدا انجام می‌شود تا از قفل شدن منابع هنگام جستجوی اجاره جلوگیری گردد.
"reservations-lookup-first": true,
// اعتبارنامه‌های دسترسی به پایگاه‌دادهٔ اجاره را مشخص می‌کند.
"lease-database": {
// پارامتر ویژهٔ پسانهٔ memfile که بازهٔ زمانی بر حسب ثانیه را مشخص می‌کند
// که در آن فایل اجاره باید پاک‌سازی شود (مدخل‌های اجارهٔ منسوخ حذف می‌شوند
// تا از رشد بی‌رویه و بی‌نهایت فایل اجاره جلوگیری شود).
"lfc-interval": 3600,
// حداکثر تعداد خطاهای مجاز خواندن فایل اجاره پیش از لغو بارگیری فایل.
// پیش‌فرض 0 است (بدون محدودیت).
"max-row-errors": 100,
// نام فایل اجاره. در صورت استفاده از پایگاه‌داده، نام
// پایگاه‌داده را مشخص می‌کند.
"name": "kea-leases6.csv",
// پارامتر ویژهٔ memfile که مشخص می‌کند آیا اجاره‌ها باید روی فضای
// ذخیره‌سازی دائمی (دیسک) ذخیره شوند یا خیر. مقدار true پیش‌فرض
// است و نشان می‌دهد که اجاره‌ها در فضای ذخیره‌سازی دائمی ذخیره می‌شوند.
// این تنظیم باید در محیط عملیاتی استفاده شود. مقدار false فقط باید
// برای اهداف آزمایشی استفاده شود زیرا اجاره‌های ذخیره‌نشده پس از راه‌اندازی مجدد کارگزار Kea از بین خواهند رفت.
"persist": true,
// نوع پسانهٔ پایگاه‌دادهٔ اجاره، یعنی "memfile"، "mysql" یا
// "postgresql".
"type": "memfile"
},
// فهرستی از پارامترها که مشخص می‌کنند چگونه نشانی MAC کلاینت را می‌توان
// از پرس‌وجوی DHCP استنتاج کرد. مقادیر پشتیبانی‌شده در «راهنمای مرجع
// مدیر سیستم Kea» فهرست شده‌اند.
"mac-sources": [ "duid" ],
// فهرستی از گزینه‌های سراسری DHCP که کارگزار Kea DHCPv6 به
// کلاینت‌ها اختصاص می‌دهد.
"option-data": [
{
// پرچم بولی که مشخص می‌کند آیا گزینهٔ داده‌شده همیشه در پاسخ
// ارسال شود یا تنها در صورت درخواست. مقدار پیش‌فرض false
// نشان می‌دهد که تنها در صورت درخواست ارسال می‌شود.
"always-send": false,
// فهرستی اختیاری از کلاس‌هایی که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های موجود در این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه فارغ از عضویت در کلاس اعمال خواهد شد.
"client-classes": [ "class1", "class2" ],
// کد گزینه. در صورت ارائهٔ نام گزینه، الزامی
// نیست.
"code": 23,
// مقدار بولی که مشخص می‌کند آیا داده‌های گزینهٔ مشخص‌شده
// در فیلد "data" به صورت رشته‌ای از ارقام هگزادسیمال مشخص شده است
// یا در قالب CSV خوانا برای انسان.
"csv-format": true,
// داده‌های گزینه برای ذخیره در بدنهٔ گزینه.
"data": "2001:db8:2::45, 2001:db8:2::100",
// نام گزینه. در صورت ارائهٔ کد گزینه، الزامی
// نیست.
"name": "dns-servers",
// پرچم بولی که مشخص می‌کند آیا گزینهٔ داده‌شده هرگز در پاسخ
// ارسال نشود یا خیر. مقدار پیش‌فرض false نشان می‌دهد که زمانی که
// باید، ارسال می‌شود. در صورت true بودن، گزینه صرف‌نظر از هر تنظیم دیگری
// ارسال نمی‌شود؛ یعنی یک پرچم قطعی و نهایی است.
"never-send": false,
// فضای گزینه. مقدار پیش‌فرض فضای گزینهٔ "dhcp6" است
// که گزینه‌های سطح‌بالای DHCPv6 را گروه‌بندی می‌کند.
"space": "dhcp6"
}
],
// فهرستی از تعاریف گزینه‌های سراسری، یعنی قالب‌های گزینه‌ها، که
// کارگزار Kea DHCPv6 از آن‌ها استفاده می‌کند.
"option-def": [
{
// پرچم بولی که مشخص می‌کند آیا تعریف گزینه شامل آرایه‌ای از
// مقادیر یک نوع خاص است یا خیر، مثلاً آرایه‌ای از نشانی‌های IPv6.
// مقدار پیش‌فرض false به این معنی است که گزینه شامل آرایه‌ای از مقادیر نیست.
"array": false,
// کد گزینه.
"code": 6,
// نام فضای گزینه‌ای را که توسط این گزینه کپسوله‌سازی شده است نگه می‌دارد.
// تمام گزینه‌های متعلق به این فضای گزینه به عنوان زیرگزینه‌های این گزینه
// ارسال خواهند شد. یک رشتهٔ خالی به این معنی است که این گزینه هیچ گزینه‌ای را
// کپسوله نمی‌کند.
"encapsulate": "",
// نام گزینه.
"name": "my-option",
// انواع فیلدهای درون گزینه را در صورتی که گزینه یک "record" باشد
// مشخص می‌کند ("type" را ببینید). در این مثال خاص این گزینه
// شامل دو فیلد به طول ۱ بایت و ۲ بایت است.
"record-types": "uint8, uint16",
// نام فضای گزینه‌ای که این گزینه به آن تعلق دارد.
"space": "my-space",
// نوع گزینه. تمام انواع ممکن در «راهنمای مرجع مدیر سیستم Kea»
// فهرست شده‌اند.
"type": "record"
}
],
// مقدار سراسری که تعداد بسته‌های کلاینت (مانند REQUESTها، RENEWها و...)
// را که ممکن است در انتظار تکمیل کار کتابخانهٔ قلاب، پیش از ارسال پاسخ
// (مانند REPLY) به کلاینت متوقف شوند، محدود می‌کند. یک مثال متداول زمانی است
// که kea-dhcp6 یک REQUEST را متوقف می‌کند در حالی که به‌روزرسانی(های) اجاره را به
// همتایان HA خود ارسال می‌کند. بسته پس از تأیید به‌روزرسانی(ها) از حالت توقف خارج می‌شود.
// این مقدار، تعداد بسته‌هایی را که می‌توان در انتظار به‌روزرسانی‌ها نگه داشت،
// محدود می‌کند. در زمان ترافیک سنگین کلاینت، این مقدار می‌تواند مانع از انباشت
// بیش از حد و حل‌نشدنی به‌روزرسانی‌ها در kea-dhcp6 شود.
"parked-packet-limit": 256,
// مقدار سراسری (پیش‌فرض) طول‌عمر ترجیحی.
"preferred-lifetime": 50,
// حداقل مقدار سراسری طول‌عمر ترجیحی.
"min-preferred-lifetime": 40,
// حداکثر مقدار سراسری طول‌عمر ترجیحی.
"max-preferred-lifetime": 60,
// مقدار سراسری تایمر پیوند مجدد، یعنی زمانی که پس از آن
// کلاینت DHCP در صورت عدم موفقیت در تمدید اجاره، وارد وضعیت rebind می‌شود.
"rebind-timer": 40,
// فهرست کدهای گزینه‌های ارائه‌شده توسط رله. RFC 6422 را ببینید.
"relay-supplied-options": [ "110", "120", "130" ],
// مقدار سراسری تایمر تمدید، یعنی زمانی که پس از آن
// کلاینت DHCP اجاره را تمدید می‌کند.
"renew-timer": 30,
// مقدار سراسری برای ذخیرهٔ اطلاعات تکمیلی (مانند اطلاعات عامل
// رله) به همراه هر اجاره.
"store-extended-info": true,
// آمارها نمونه‌هایی را به ازای هر نقطهٔ مشاهده نگه‌داری می‌کنند.
// دو مقدار پیش‌فرض وجود دارد: حداکثر تعداد و حداکثر سن.
// تنظیم حداکثر تعداد روی صفر، آن را غیرفعال می‌کند.
"statistic-default-sample-count": 0,
// هنگامی که حداکثر تعداد 0 باشد، حداکثر سن (بر حسب ثانیه) اعمال می‌شود.
"statistic-default-sample-age": 60,
// پارامترهای چندنخی.
"multi-threading": {
// به طور پیش‌فرض، در صورتی که سخت‌افزار اجازه دهد، Kea بسته‌ها را روی چندین نخ پردازش می‌کند.
"enable-multi-threading": true,
// هنگامی که چندنخی فعال است، Kea بسته‌ها را روی تعدادی نخ که از طریق این گزینه
// قابل پیکربندی است، پردازش خواهد کرد. مقدار باید یک عدد صحیح مثبت باشد
// (0 یعنی تشخیص خودکار).
"thread-pool-size": 0,
// هنگامی که چندنخی فعال است، Kea بسته‌ها را از رابط می‌خواند و یک مورد کاری را
// به مخزن نخ‌ها اضافه می‌کند. این گزینه حداکثر تعداد مواردی را که می‌توان
// در صف قرار داد پیکربندی می‌کند. مقدار باید یک عدد صحیح مثبت باشد (0 یعنی نامحدود).
"packet-queue-size": 0
},
// تعیین می‌کند که کارگزار Kea DHCPv6 چگونه باید با داده‌های
// نامعتبر دریافت شده از کلاینت برخورد کند.
"sanity-checks": {
// مشخص می‌کند که کارگزار Kea DHCPv6 هنگامی که داده‌های نامعتبر برای یک اجاره
// از فایل اجاره خوانده می‌شود، چگونه باید رفتار کند. مقادیر زیر پشتیبانی می‌شوند:
// "none" (تلاشی برای تصحیح اطلاعات اجاره انجام نده)،
// "warn" (چاپ یک هشدار برای ناهماهنگی‌های مربوط به subnet-id)،
// "fix" (تصحیح شناسهٔ زیرشبکه با تلاش برای یافتن زیرشبکهٔ مناسب)،
// "fix-del" (مشابه "fix" اما حذف اجاره در صورت پیدا نشدن زیرشبکهٔ مناسب)،
// "del" (حذف اجاره در صورتی که اجاره دارای مقدار شناسهٔ زیرشبکهٔ نامعتبر باشد).
"lease-checks": "warn",
// مشخص می‌کند که کارگزار Kea DHCPv4 هنگامی که اطلاعات تکمیلی نامعتبر
// برای یک اجاره از فایل اجاره خوانده می‌شود، یا در هنگام ارتقا از قالب قدیمی،
// چگونه باید رفتار کند. مقادیر زیر پشتیبانی می‌شوند:
// "none" (تلاشی برای تصحیح یا ارتقای اطلاعات تکمیلی انجام نده)،
// "fix" (اصلاح ناهماهنگی‌های معمول و ارتقا از قالب قدیمی؛ این مقدار پیش‌فرض است)،
// "strict" (اصلاح ناهماهنگی‌های موثر بر Leasequery)،
// "pedantic" (اعمال کامل قالب کد Kea).
"extended-info-checks": "fix"
},
// مقدار DUID سفارشی مورد استفاده توسط کارگزار DHCPv6.
"server-id": {
// نوع DUID. مقادیر ممکن عبارتند از "LLT"، "EN" و "LL".
"type": "EN",
// شناسهٔ سازمانی مورد استفاده برای DUID از نوع "EN".
"enterprise-id": 2495,
// بخش شناسهٔ DUID.
"identifier": "0123456789",
// پرچم بولی که مشخص می‌کند آیا DUID باید روی دیسک
// ذخیره شود یا خیر.
"persist": false
},
// فهرست شبکه‌های اشتراکی مورد استفاده توسط کارگزار Kea DHCPv6. شبکه‌های
// اشتراکی، زیرشبکه‌ها را با هم گروه‌بندی می‌کنند.
"shared-networks": [
{
// پرچمی برای انتخاب راهبرد تخصیص نشانی IP برای همهٔ
// زیرشبکه‌ها در این شبکهٔ اشتراکی.
"allocator": "random",
// پرچمی برای انتخاب راهبرد تخصیص پیشوند واگذارشده برای
// همهٔ زیرشبکه‌ها در این شبکهٔ اشتراکی.
"pd-allocator": "iterative",
// این شبکهٔ اشتراکی را محدود می‌کند تا فقط به کلاینت‌هایی
// اجازه دهد که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند.
// اگر حذف شود یا یک فهرست خالی ارائه گردد، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-override-client-update": false,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-override-no-update": false,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-qualifying-suffix": "",
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-replace-client-name": "never",
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-send-updates": true,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-update-on-renew": true,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیهٔ آن صرفاً برای سازگاری عقبرو حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-percent": 0.65,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
// نمی‌توان هم‌زمان ddns-ttl و هر یک از مقادیر ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را تعیین کرد. آن‌ها متقابلاً ناسازگار هستند.
// "ddns-ttl": 500,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-min": 10000,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-max": 20000,
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح شبکهٔ اشتراکی. توضیحات را در سطح سراسری ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// مشخص می‌کند که این شبکهٔ اشتراکی برای درخواست‌های دریافت‌شده
// روی یک رابط خاص انتخاب می‌شود.
"interface": "eth0",
// محتوای گزینهٔ interface-id را مشخص می‌کند که توسط رله‌ها
// برای شناسایی رابطی روی رله که پاسخ به آن ارسال می‌شود،
// استفاده می‌گردد.
"interface-id": "",
// نام شبکهٔ اشتراکی.
"name": "my-secret-network",
// فهرست گزینه‌های DHCP ویژهٔ شبکهٔ اشتراکی.
"option-data": [],
// طول‌عمر ترجیحی (پیش‌فرض) ویژهٔ شبکهٔ اشتراکی.
"preferred-lifetime": 2000,
// حداقل طول‌عمر ترجیحی ویژهٔ شبکهٔ اشتراکی.
"min-preferred-lifetime": 1500,
// حداکثر طول‌عمر ترجیحی ویژهٔ شبکهٔ اشتراکی.
"max-preferred-lifetime": 2500,
// پرچم بولی که مشخص می‌کند آیا سرور می‌تواند به یک پیام Solicit
// حاوی گزینهٔ Rapid Commit با یک پیام Reply پاسخ دهد یا خیر
// (DHCPv6 rapid commit را ببینید).
"rapid-commit": false,
// فهرست نشانی‌های رلهٔ IPv6 که این شبکهٔ
// اشتراکی برای آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": []
},
// تایمر rebind در سطح شبکهٔ اشتراکی.
"rebind-timer": 41,
// تایمر renew در سطح شبکهٔ اشتراکی.
"renew-timer": 31,
// محاسبهٔ تایمرهای T1 و T2 در سطح شبکهٔ اشتراکی.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانهٔ حافظهٔ پنهان = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر حافظهٔ پنهان: هنگامی که زمان آخرین ارسال کلاینت به اندازهٔ
// کافی نزدیک باشد، اجاره تمدید نمی‌شود و اجارهٔ فعلی به صورت
// پنهان‌شده ("cached") برگردانده می‌شود.
"cache-max-age": 1000,
// آستانهٔ زمان اجارهٔ تطبیقی (1.0 یعنی غیرفعال).
"adaptive-lease-time-threshold": 0.8,
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون‌زیرشبکه‌ای را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند همهٔ نشانی‌های رزروشده
// خارج از استخر هستند یا خیر.
// هنگامی که reservations-in-subnet برابر false باشد نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این شبکهٔ اشتراکی
// برای تخصیص‌های کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// خاموش کردن ذخیره‌سازی اطلاعات تکمیلی (مانند اطلاعات عامل
// رله) به همراه هر اجاره برای این شبکهٔ اشتراکی.
"store-extended-info": false,
// فهرست زیرشبکه‌های IPv6 متعلق به این شبکهٔ اشتراکی.
"subnet6": [
{
// پرچمی برای انتخاب راهبرد تخصیص نشانی IP برای
// زیرشبکه.
"allocator": "iterative",
// پرچمی برای انتخاب راهبرد تخصیص پیشوند واگذارشده
// برای زیرشبکه.
"pd-allocator": "iterative",
// این زیرشبکه را محدود می‌کند تا فقط به کلاینت‌هایی اجازه دهد
// که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه گردد، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [],
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-generated-prefix": "myhost",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-override-client-update": false,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-override-no-update": false,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-qualifying-suffix": "",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-replace-client-name": "never",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-send-updates": true,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-update-on-renew": true,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// این فیلد با ddns-conflict-resolution-mode جایگزین شده است.
// تجزیهٔ آن صرفاً برای سازگاری عقبرو حفظ شده است.
// "ddns-use-conflict-resolution": true,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// "ddns-ttl-percent": 0.55,
// "ddns-ttl": 0,
// نمی‌توان هم‌زمان ddns-ttl و هر یک از مقادیر ddns-ttl-percent، ddns-ttl-min یا
// ddns-ttl-max را تعیین کرد. آن‌ها متقابلاً ناسازگار هستند.
"ddns-ttl": 500,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// "ddns-ttl-min": 10000,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
// "ddns-ttl-max": 20000,
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح زیرشبکه. توضیحات را در سطح سراسری ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]",
// شناسهٔ یکتای زیرشبکه.
"id": 1,
// مشخص می‌کند که این زیرشبکه برای درخواست‌های دریافت‌شده
// روی یک رابط خاص انتخاب می‌شود.
"interface": "eth0",
// محتوای گزینهٔ interface-id را مشخص می‌کند که توسط رله‌ها
// برای شناسایی رابطی روی رله که پاسخ به آن ارسال می‌شود،
// استفاده می‌گردد.
"interface-id": "",
// روشن کردن ذخیره‌سازی اطلاعات تکمیلی (مانند اطلاعات عامل
// رله) به همراه هر اجاره برای این زیرشبکه.
"store-extended-info": true,
// فهرست گزینه‌های DHCP در سطح زیرشبکه.
"option-data": [
{
// پرچم بولی که مشخص می‌کند آیا گزینهٔ خاص باید همیشه
// ارسال شود یا تنها در صورت درخواست.
"always-send": false,
// فهرستی اختیاری از کلاس‌هایی که این گزینه برای آن‌ها اعمال می‌شود.
// اگر کلاینت با هر یک از کلاس‌های موجود در این فهرست مطابقت داشته باشد،
// گزینه اعمال خواهد شد. اگر فهرست خالی باشد یا حذف شود،
// این گزینه فارغ از عضویت در کلاس اعمال خواهد شد.
"client-classes": [],
// کد گزینه.
"code": 7,
// پرچم بولی که مشخص می‌کند آیا مقدار گزینهٔ مشخص‌شده
// در "data" رشته‌ای از مقادیر هگزادسیمال است یا مقدار
// CSV خوانا برای انسان.
"csv-format": false,
// داده‌های گزینه برای قرار گرفتن در بدنهٔ گزینه.
"data": "0xf0",
// نام گزینه.
"name": "preference",
// پرچم بولی که مشخص می‌کند آیا گزینهٔ داده‌شده هرگز
// در پاسخ ارسال نشود یا خیر.
"never-send": false,
// فضای گزینه. مقدار پیش‌فرض "dhcp6" نشان‌دهندهٔ
// فضای گزینهٔ سطح بالا است.
"space": "dhcp6"
}
],
// فهرست استخرهایی که پیشوندهای واگذارشده از آن‌ها به
// کلاینت‌ها تخصیص داده می‌شود.
"pd-pools": [
{
// این استخر پیشوند زیرشبکه را محدود می‌کند تا تنها به کلاینت‌هایی
// اجازه دهد که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه گردد، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server1" ],
// طول پیشوندهای واگذارشده به کلاینت‌ها.
"delegated-len": 64,
// پیشوند (نشانی) مستثنی‌شده از تخصیص‌های کلاینت.
"excluded-prefix": "2001:db8:1::",
// پیشوند (طول) مستثنی‌شده از تخصیص‌های کلاینت.
"excluded-prefix-len": 72,
// فهرست گزینه‌های DHCP در سطح استخر پیشوند.
"option-data": [],
// محدودهٔ پیشوند (نشانی) مورد استفاده برای تخصیص‌های کلاینت.
"prefix": "2001:db8:1::",
// محدودهٔ پیشوند (طول) مورد استفاده برای تخصیص‌های کلاینت.
"prefix-len": 48,
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این استخر
// پیشوند برای تخصیص‌های کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [],
// شناسهٔ PD-pool مورد استفاده برای فعال‌سازی آمارها برای این pd-pool.
// شناسهٔ pd-pool نیازی نیست درون زیرشبکه یا در میان زیرشبکه‌ها یکتا باشد.
// در صورت پیکربندی نشدن، پیش‌فرض آن 0 است. آمارهای
// مربوط به این pd-pool با سایر آمارهای همهٔ pd-poolهای دیگر با همان
// شناسه در این زیرشبکه ترکیب خواهد شد.
"pool-id": 1
},
{
// طول پیشوندهای واگذارشده به کلاینت‌ها.
"delegated-len": 64,
// محدودهٔ پیشوند (نشانی) مورد استفاده برای تخصیص‌های کلاینت.
"prefix": "2001:db8:2::",
// محدودهٔ پیشوند (طول) مورد استفاده برای تخصیص‌های کلاینت.
"prefix-len": 48
}
],
// فهرست استخرهای نشانی IP متعلق به زیرشبکه.
"pools": [
{
// این استخر زیرشبکه را محدود می‌کند تا فقط به کلاینت‌هایی
// اجازه دهد که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه گردد، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server1" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدودهٔ نشانی مورد استفاده برای تخصیص‌های کلاینت.
"pool": "2001:db8:0:1::/64",
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این استخر برای تخصیص‌های
// کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-generated-prefix": "mypool",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-override-client-update": false,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-override-no-update": false,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-qualifying-suffix": "pool.example.com.",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-replace-client-name": "always",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-send-updates": true,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-update-on-renew": false,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-conflict-resolution-mode": "check-with-dhcid",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-percent": 0.55,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
// نمی‌توانید هم‌زمان ddns-ttl و هر یک از مقادیر ddns-ttl-percent،
// ddns-ttl-min یا ddns-ttl-max را تعیین کنید. آن‌ها متقابلاً ناسازگار هستند.
// "ddns-ttl": 500,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-min": 10000,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"ddns-ttl-max": 20000,
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"hostname-char-replacement": "x",
// مقدار در سطح استخر. توضیحات را در سطح سراسری ببینید.
"hostname-char-set": "[^A-Za-z0-9.-]"
},
{
// این استخر زیرشبکه را محدود می‌کند تا فقط به کلاینت‌هایی
// اجازه دهد که دست‌کم به یکی از کلاس‌های این فهرست تعلق دارند. اگر حذف شود
// یا یک فهرست خالی ارائه گردد، هیچ محدودیتی اعمال نمی‌شود.
"client-classes": [ "phones_server2" ],
// فهرست گزینه‌های DHCP در سطح استخر.
"option-data": [],
// محدودهٔ نشانی مورد استفاده برای تخصیص‌های کلاینت.
"pool": "2001:db8:0:3::/64",
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این استخر برای تخصیص‌های
// کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [],
// شناسهٔ استخر برای فعال‌سازی آمارها برای این استخر.
// شناسهٔ استخر نیازی نیست درون زیرشبکه یا در میان زیرشبکه‌ها یکتا باشد.
// در صورت پیکربندی نشدن، پیش‌فرض آن 0 است. آمارهای
// مربوط به این استخر با سایر آمارهای همهٔ استخرهای دیگر با همان
// شناسه در این زیرشبکه ترکیب خواهد شد.
"pool-id": 1
}
],
// طول‌عمر ترجیحی (پیش‌فرض) ویژهٔ زیرشبکه.
"preferred-lifetime": 2000,
// حداقل طول‌عمر ترجیحی ویژهٔ زیرشبکه.
"min-preferred-lifetime": 1500,
// حداکثر طول‌عمر ترجیحی ویژهٔ زیرشبکه.
"max-preferred-lifetime": 2500,
// پرچم بولی که مشخص می‌کند آیا سرور می‌تواند به یک پیام Solicit
// حاوی گزینهٔ Rapid Commit با یک پیام Reply پاسخ دهد یا خیر
// (DHCPv6 rapid commit را ببینید).
"rapid-commit": false,
// مقدار تایمر rebind در سطح زیرشبکه.
"rebind-timer": 40,
// فهرست نشانی‌های رلهٔ IPv6 که این زیرشبکه برای آن‌ها انتخاب می‌شود.
"relay": {
"ip-addresses": [
"2001:db8:0:f::1"
]
},
// تایمر renew در سطح زیرشبکه.
"renew-timer": 30,
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون‌زیرشبکه‌ای را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند تمام نشانی‌های
// رزروشده خارج از استخر هستند یا خیر.
// هنگامی که reservations-in-subnet برابر false باشد نادیده گرفته می‌شود.
"reservations-out-of-pool": false,
// محاسبهٔ تایمرهای T1 و T2 در سطح زیرشبکه.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانهٔ حافظهٔ پنهان = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر حافظهٔ پنهان در سطح زیرشبکه.
"cache-max-age": 1000,
// آستانهٔ زمان اجارهٔ تطبیقی (1.0 یعنی غیرفعال).
"adaptive-lease-time-threshold": 0.8,
// فهرست رزروهای ایستای IPv6 اختصاص‌یافته به کلاینت‌های متعلق
// به این زیرشبکه. برای یک مثال تفصیلی، reservations.json را ببینید.
"reservations": [
{
// شناسهٔ مورد استفاده برای تطبیق کلاینت. مقادیر پشتیبانی‌شده عبارتند از
// "duid"، "hw-address" و "flex-id".
"duid": "01:02:03:04:05:06:07:08:09:0A",
// فهرست نشانی‌های IPv6 رزروشده.
"ip-addresses": [ "2001:db8:1:cafe::1" ],
// فهرست پیشوندهای IPv6 رزروشده.
"prefixes": [ "2001:db8:2:abcd::/64" ],
// فهرست پیشوندهای IPv6 مستثنی‌شده.
"excluded-prefixes": [ "2001:db8:2:abcd:1::/80" ],
// نام میزبان رزروشده.
"hostname": "foo.example.com",
// داده‌های گزینهٔ ویژهٔ رزرو.
"option-data": [
{
// نام گزینه.
"name": "vendor-opts",
// مقدار گزینه.
"data": "4491"
}
]
}
],
// فهرست کلاس‌های کلاینتی که هنگام انتخاب این زیرشبکه
// برای تخصیص‌های کلاینت باید ارزیابی شوند.
"evaluate-additional-classes": [ "late" ],
// پیشوند زیرشبکه.
"subnet": "2001:db8::/32",
// طول‌عمر معتبر (پیش‌فرض) در سطح زیرشبکه.
"valid-lifetime": 6000,
// حداقل طول‌عمر معتبر در سطح زیرشبکه.
"min-valid-lifetime": 4000,
// حداکثر طول‌عمر معتبر در سطح زیرشبکه.
"max-valid-lifetime": 8000
}
],
// طول‌عمر معتبر (پیش‌فرض) در سطح شبکهٔ اشتراکی.
"valid-lifetime": 6001,
// حداقل طول‌عمر معتبر در سطح شبکهٔ اشتراکی.
"min-valid-lifetime": 4001,
// حداکثر طول‌عمر معتبر در سطح شبکهٔ اشتراکی.
"max-valid-lifetime": 8001
}
],
// فهرست زیرشبکه‌های IPv6 که به هیچ شبکهٔ اشتراکی تعلق ندارند.
"subnet6": [],
// مقدار سراسری طول‌عمر معتبر.
"valid-lifetime": 6000,
// حداقل مقدار سراسری طول‌عمر معتبر.
"min-valid-lifetime": 4000,
// حداکثر مقدار سراسری طول‌عمر معتبر.
"max-valid-lifetime": 8000,
// رزروها (مثال‌ها در فایل‌های دیگر موجود است).
"reservations": [],
// کنترل پیکربندی (در حال حاضر استفاده نمی‌شود، یعنی این نحو
// از پیش تعریف شده اما قابلیت مربوط به آن پیاده‌سازی نشده است).
"config-control": {
// فقط مدخل پایگاه‌های دادهٔ پیکربندی تعریف شده است.
"config-databases": [
{
// نام پایگاه‌داده برای اتصال.
"name": "config",
// نوع پایگاه‌داده، مثلاً "mysql"، "postgresql".
"type": "mysql"
}
],
// بازهٔ زمانی بین تلاش‌ها برای واکشی به‌روزرسانی‌های پیکربندی
// از طریق پسانه‌های پیکربندی مورد استفاده.
"config-fetch-wait-time": 30
},
// برچسب سرور.
"server-tag": "my DHCPv6 server",
// پارامترهای کنترل صف DHCP.
"dhcp-queue-control": {
// فعال‌سازی صف اجباری است.
"enable-queue": true,
// نوع صف اجباری است.
"queue-type": "kea-ring6",
// ظرفیت اختیاری است.
"capacity": 64
},
// مشخص می‌کند که آیا سرور باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا سرور باید رزروهای درون‌زیرشبکه‌ای را جستجو کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا سرور می‌تواند فرض کند همهٔ نشانی‌های رزروشده
// خارج از استخر هستند یا خیر.
// هنگامی که reservations-in-subnet برابر false باشد نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "shared-networks" و
// "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// محاسبهٔ سراسری تایمرهای T1 و T2.
"calculate-tee-times": true,
// T1 = valid lifetime * .5.
"t1-percent": .5,
// T2 = valid lifetime * .75.
"t2-percent": .75,
// آستانهٔ حافظهٔ پنهان = valid lifetime * .25.
"cache-threshold": .25,
// حداکثر حافظهٔ پنهان سراسری.
"cache-max-age": 1000,
// آستانهٔ زمان اجارهٔ تطبیقی (1.0 یعنی غیرفعال)
"adaptive-lease-time-threshold": 0.8,
// رشته‌ای از صفر یا چند نویسه که با هر نویسهٔ نامعتبر در
// Client FQDN جایگزین می‌شود. مقدار پیش‌فرض یک رشتهٔ خالی
// است که باعث می‌شود نویسه‌های نامعتبر به جای جایگزینی، حذف شوند.
"hostname-char-replacement": "x",
// عبارت باقاعده توصیف‌کنندهٔ مجموعه نویسه‌های نامعتبر در
// Client FQDN.
"hostname-char-set": "[^A-Za-z0-9.-]",
// فهرست ثبت‌کننده‌های وقایع مورد استفاده توسط سرورهایی که از این فایل پیکربندی استفاده می‌کنند.
"loggers": [
{
// سطح اشکال‌زدایی، مقداری بین 0..99. هر چه مقدار بزرگ‌تر باشد،
// گزارش اشکال‌زدایی دقیق‌تر خواهد بود.
"debuglevel": 99,
// نام ثبت‌کنندهٔ وقایع.
"name": "kea-dhcp6",
// نحوهٔ ارسال گزارش وقایع به خروجی را پیکربندی می‌کند.
"output-options": [
{
// مشخص می‌کند که آیا گزارش وقایع باید فوراً روی فایل تخلیه شود یا خیر.
"flush": true,
// حداکثر اندازهٔ فایل را قبل از چرخش فایل مشخص می‌کند.
"maxsize": 10240000,
// حداکثر تعداد فایل‌های چرخش‌یافته برای نگه‌داری را مشخص می‌کند.
"maxver": 1,
// مقصد ثبت وقایع را مشخص می‌کند.
"output": "stdout",
// محتوای مدخل گزارش وقایع را مشخص می‌کند.
"pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// سطح حساسیت ثبت وقایع را مشخص می‌کند، یعنی "ERROR"، "WARN"، "INFO"، "DEBUG".
"severity": "INFO"
}
],
// برای کاربرد user-contexts به مثال‌های پیشرفته نگاه کنید.
"user-context": { }
}
}
168u
0.0
3.5
// این فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea شامل موارد زیر است:
//
// - داده‌ها برای تمام گزینه‌های استاندارد
// - تعاریف گزینه‌های سفارشی در سطح سراسری همراه با برخی داده‌های گزینه مرتبط
// - داده‌های گزینه سفارشی با فضاهای گزینه استانداردشده به جز "dhcp6"
// - فضاهای گزینه سفارشی
// - مثال‌های جاسازی گزینه
// - داده‌های گزینه DOCSIS3
//
// اکیداً به خواننده توصیه می‌شود به ساختارهای گزینه مستندشده در Kea ARM نگاهی بیندازد:
// https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html?highlight=option%20definitions#dhcp6-std-options-list
//
// گزینه‌های دیگر نیازمند منطق خاصی هستند که هنوز پیاده‌سازی نشده است. آنها با
// این عبارت مشخص شده‌اند:
// "Note: special logic not implemented"
{
"Dhcp6": {
/*
داده‌ها برای تمام تعاریف گزینه استاندارد
*/
// داده‌های گزینه تعریف‌شده به صورت سراسری
"option-data": [
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value |
+-+-+-+-+-+-+-+-+
option-code OPTION_PREFERENCE (7).
option-len 1.
pref-value مقدار preference برای کارگزار در این پیام.
*/
// نوع: uint8
{
"code": 7,
"data": "0xf0",
"name": "preference"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_UNICAST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_UNICAST (12).
option-len 16.
server-address نشانی IP که کلاینت باید پیام‌های ارسالی با
unicast را به آن ارسال کند.
***نکته***: این گزینه توسط RFC9915 منسوخ شده است.
*/
// نوع: IPv6 address
{
"code": 12,
"data": "2001:db8::2",
"name": "unicast"
},
/*
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. option-data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_VENDOR_OPTS (17)
option-len ۴ + طول فیلد option-data
enterprise-number شماره ثبت‌شده سازنده (Enterprise Number) به گونه‌ای که
در IANA [6] ثبت شده است.
option-data یک شیء مات (opaque) به طول option-len بایت،
تفسیرشده توسط کد مختص سازنده در کلاینت‌ها
و کارگزارها
*/
// نوع: uint32
// گزینه‌های سازنده استاندارد نیستند و مختص هر سازنده‌اند.
// سازندگان با enterprise number شناسایی می‌شوند که گاهی vendor-id
// یا enterprise-id نیز نامیده می‌شود. برای مثال، CableLabs که گزینه‌های
// DOCSIS را مشخص کرده از 4491 استفاده می‌کند. برخی سازندگان سازوکارهای
// خود را دارند. مثلاً زیرگزینه ۱ سازنده DOCSIS معادل ORO برای گزینه‌های
// عادی DHCPv6 است. معمولاً چندین زیرگزینه سازنده در آن تعریف می‌شود.
// بخش ARM را ببینید:
// https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#dhcpv6-vendor-specific-options
{
"code": 17,
"data": "4294967295",
"name": "vendor-opts"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_ACCEPT | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_ACCEPT (20).
option-len 0.
*/
// نوع: empty
{
"code": 20,
"name": "reconf-accept"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIP_SERVER_D | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIP Server Domain Name List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SIP Server Domain Name List: نام‌های دامنه کارگزارهای پراکسی خروجی SIP
برای استفاده کلاینت. نام‌های دامنه همان‌طور که در بخش ۸
("Representation and use of domain names") از مشخصات DHCPv6 [1]
تعیین شده، کدگذاری می‌شوند.
*/
// نوع: array of {FQDN}
{
"code": 21,
"data": "sip1.server.net, sip2.server.net",
"name": "sip-server-dns"
},
/*
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIP_SERVER_A | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SIP server (IP address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SIP server (IP address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_SIP_SERVER_A (22)
option-length: طول فیلد 'options' به بایت؛ باید مضربی از ۱۶ باشد.
SIP server: نشانی IPv6 یک کارگزار SIP برای استفاده کلاینت.
کارگزارها به ترتیب اولویت برای استفاده کلاینت فهرست
شده‌اند.
*/
// نوع: array of {IPv6 address}
{
"code": 22,
"data": "2001:db8::3, 2001:db8::4",
"name": "sip-server-addr"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DNS_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DNS_SERVERS (23)
option-len: طول فهرست کارگزارهای نام بازگشتی DNS به بایت؛
باید مضربی از ۱۶ باشد
DNS-recursive-name-server: نشانی IPv6 کارگزار نام بازگشتی DNS
*/
// نوع: array of {IPv6 address}
{
"code": 23,
"data": "2001:db8::5, 2001:db8::6",
"name": "dns-servers"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DOMAIN_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| searchlist |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DOMAIN_LIST (24)
option-len: طول فیلد 'searchlist' به بایت
searchlist: مشخصات فهرست نام‌های دامنه در Domain Search List
*/
// نوع: array of {FQDN}
{
"code": 24,
"data": "example.com, example.org",
"name": "domain-search"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NIS_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NIS server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NIS server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NIS_SERVERS (27)
option-len: طول فیلدهای 'NIS server' به بایت؛ باید مضربی
از ۱۶ باشد
NIS server: نشانی IPv6 کارگزار NIS
*/
// نوع: array of {IPv6 address}
{
"code": 27,
"data": "2001:db8::7, 2001:db8::8",
"name": "nis-servers"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NISP_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NIS+ server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NIS+ server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NISP_SERVERS (28)
option-len: طول فیلدهای 'NIS+ server' به بایت؛ باید مضربی
از ۱۶ باشد
NIS+ server: نشانی IPv6 کارگزار NIS+
*/
// نوع: array of {IPv6 address}
{
"code": 28,
"data": "2001:db8::9, 2001:db8::10",
"name": "nisp-servers"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NIS_DOMAIN_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nis-domain-name |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NIS_DOMAIN_NAME (29)
option-len: طول فیلد 'nis-domain-name' به بایت
nis-domain-name: نام دامنه NIS برای کلاینت
*/
// نوع: array of {FQDN}
{
"code": 29,
"data": "nis1.example.org, nis2.example.org",
"name": "nis-domain-name"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NISP_DOMAIN_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nisp-domain-name |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NISP_DOMAIN_NAME (30)
option-len: طول فیلد 'nisp-domain-name' به بایت
nisp-domain-name: نام دامنه NIS+ برای کلاینت
*/
// نوع: array of {FQDN}
{
"code": 30,
"data": "nisp1.example.org, nisp2.example.org",
"name": "nisp-domain-name"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SNTP_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SNTP server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SNTP server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_SNTP_SERVERS (31)
option-len: طول فیلدهای 'SNTP server' به بایت؛ باید
مضربی از ۱۶ باشد
SNTP server: نشانی IPv6 کارگزار SNTP
*/
// نوع: array of {IPv6 address}
{
"code": 31,
"data": "2001:db8::11, 2001:db8::12",
"name": "sntp-servers"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OPTION_INFORMATION_REFRESH_TIME| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_INFORMATION_REFRESH_TIME (32).
option-len 4.
information-refresh-time مدت زمان نسبت به زمان جاری، بیان‌شده بر
حسب ثانیه. یک فیلد ۴ بایتی شامل یک عدد صحیح
بدون علامت.
*/
// نوع: uint32
{
"code": 32,
"data": "3600",
"name": "information-refresh-time"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_BCMCS_SERVER_D | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCMCS Control Server Domain Name List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_BCMCS_SERVER_D (33).
option-length: طول فیلد 'BCMCS Control Server Domain Name List'
به بایت؛ متغیر.
BCMCS Control Server Domain Name List: قالب یکسان با بخش ۴.۱
(به جز فیلدهای Code و Len).
*/
// نوع: array of {FQDN}
{
"code": 33,
"data": "bcmcs1.example.org, bcmcs2.example.org",
"name": "bcmcs-server-dns"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_BCMCS_SERVER_A | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| BCMCS Control server-1 address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| BCMCS Control server-2 address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_BCMCS_SERVER_A (34).
option-length: طول فیلد 'BCMCS Control Server IPv6 address'
به بایت؛ متغیر.
*/
// نوع: array of {IPv6 address}
{
"code": 34,
"data": "2001:db8::13, 2001:db8::14",
"name": "bcmcs-server-addr"
},
// کد گزینه ۳۵ تخصیص داده نشده است.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_GEOCONF_CIVIC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| what | country code | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. civic address elements .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_GEOCONF_CIVIC (36)
option-len: طول Countrycode، عنصر 'what' و عناصر civic address به بایت.
what: عنصر 'what' توصیف می‌کند که مدخل DHCP به کدام مکان اشاره
دارد. در حال حاضر، سه گزینه تعریف شده است: مکان کارگزار DHCP
(مقدار ۰)، مکان عنصر شبکه‌ای که گمان می‌رود نزدیک‌ترین به کلاینت باشد
(مقدار ۱)، یا مکان کلاینت (مقدار ۲). گزینه (۲) «بایستی» استفاده شود،
اما ممکن است مشخص نباشد. گزینه‌های (۰) و (۱) «نبایستی» استفاده شوند
مگر اینکه مشخص باشد کلاینت DHCP در نزدیکی فیزیکی کارگزار یا عنصر شبکه
قرار دارد.
country code: کد کشور دو حرفی ISO 3166 با حروف بزرگ ASCII،
مانند DE یا US. (نشانی‌های مدنی همیشه شامل تعیین کشور هستند، که
پیشنهاددهنده استفاده از یک فیلد با قالب ثابت برای صرفه‌جویی در فضا است.)
civic address elements: صفر یا چند عنصر تشکیل‌دهنده نشانی مدنی
و/یا پستی، با قالبی که در زیر شرح داده شده است
(بخش ۳.۳).
*/
// نوع: uint8, uint16, array of {binary}
{
"code": 36,
// 0x5553 همان "US" در UTF-8 است
"data": "0, 0x5553, 15 9D, A3 FF",
"name": "geoconf-civic"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_REMOTE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. remote-id .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_REMOTE_ID (37)
option-len ۴ + طول فیلد remote-id به بایت.
حداقل option-len برابر با ۵ بایت است.
enterprise-number شماره ثبت‌شده سازنده (Enterprise Number) به گونه‌ای که
در IANA [5] ثبت شده است.
remote-id مقدار مات (opaque) برای remote-id.
*/
// نوع: uint32, binary
{
"code": 37,
"data": "4294967295, 1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "remote-id"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_FQDN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | |
+-+-+-+-+-+-+-+-+ |
. .
. domain-name .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_FQDN (39)
option-len ۱ + طول domain name
flags بیت‌های پرچم استفاده‌شده میان کلاینت و کارگزار
جهت مذاکره بر سر اینکه چه کسی کدام به‌روزرسانی‌ها
را انجام دهد
domain-name نام دامنه جزئی یا کاملاً مشخص‌شده (FQDN)
(با طول option-len - 1)
*/
// نوع: uint8, FQDN
{
"code": 39,
"data": "224, client.example.org",
"name": "client-fqdn"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ PAA IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_PANA_AGENT (40).
option-length: طول فیلد 'options' به بایت؛ «باید»
مضربی از شانزده (۱۶) باشد.
PAA IPv6 Address: نشانی IPv6 مربوط به PAA برای استفاده کلاینت.
‏PAAها به ترتیب اولویت برای استفاده توسط
کلاینت فهرست شده‌اند.
*/
// نوع: array of {IPv6 address}
{
"code": 40,
"data": "2001:db8::15, 2001:db8::16",
"name": "pana-agent"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NEW_POSIX_TIMEZONE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TZ POSIX String |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NEW_POSIX_TIMEZONE(41)
option-length: تعداد بایت‌های نمایه رشته TZ POSIX شرح داده‌شده
در زیر.
*/
// نوع: string
{
"code": 41,
// گزینه‌های رشته‌ای که در مقادیر خود ویرگول دارند باید گریز داده شوند
// (یعنی قبل از هر ویرگول دو بک‌اسلش قرار می‌گیرد). دلیل آن این است که
// ویرگول‌ها برای جداسازی فیلدها در گزینه‌های مرکب رزرو شده‌اند. در عین
// حال، باید با مشخصات JSON که "\," را مجاز نمی‌داند سازگار
// باشیم. بنابراین علامت‌گذاری تا حدودی غیرمعمول دو بک‌اسلش مورد نیاز
// است. مقداری که از طریق شبکه ارسال می‌شود عبارت است از:
// EST5EDT4,M3.2.0/02:00,M11.1.0/02:00
"data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00",
"name": "new-posix-timezone"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NEW_TZDB_TIMEZONE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TZ Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NEW_TZDB_TIMEZONE(42)
option-length: تعداد بایت‌های نمایه رشته TZ Database شرح داده‌شده
در زیر.
*/
// نوع: string
{
"code": 42,
"data": "Europe/Zurich",
"name": "new-tzdb-timezone"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ERO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ERO (43).
option-len ۲ * تعداد گزینه‌های درخواستی.
requested-option-code-n کد گزینه برای یک گزینه درخواست‌شده توسط
عامل رله (relay agent).
*/
// نوع: array of {uint16}
{
"code": 43,
"data": "16, 32, 42",
"name": "ero"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_QUERY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| query-type | |
+-+-+-+-+-+-+-+-+ |
| |
| link-address |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | .
+-+-+-+-+-+-+-+-+ .
. query-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_QUERY (44)
option-len ۱۷ + طول فیلد query-options.
link-address یک نشانی سراسری که توسط کارگزار برای شناسایی پیوندی
که پرس‌وجو به آن اعمال می‌شود استفاده خواهد شد، یا
0::0 اگر مشخص نشده باشد.
query-type پرس‌وجوی درخواست‌شده (زیر را ببینید).
query-options گزینه‌های مربوط به پرس‌وجو.
*/
// Note: special logic not implemented
// نوع: uint8, IPv6 address
{
"code": 44,
"data": "1, 2001:db8::17",
"name": "lq-query"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. client-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_DATA (45)
option-len طول، به بایت، از فیلد کپسوله‌شده client-options.
client-options گزینه‌های مرتبط با این کلاینت.
*/
// Note: special logic not implemented
// نوع: empty
{
"code": 45,
"name": "client-data"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLT_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client-last-transaction-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLT_TIME (46)
option-len 4
client-last-transaction-time
تعداد ثانیه‌ها از آخرین باری که کارگزار با کلاینت
(روی آن پیوند) ارتباط برقرار کرده است.
*/
// Note: special logic not implemented
// نوع: uint32
{
"code": 46,
"data": "600",
"name": "clt-time"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_RELAY_DATA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| peer-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DHCP-relay-message |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_RELAY_DATA (47)
option-len ۱۶ + طول DHCP-relay-message.
peer-address نشانی عامل رله‌ای که پیام رله‌شده توسط کارگزار از
آن دریافت شده است.
DHCP-relay-message
آخرین پیام رله‌شده کامل، به استثنای پیام کلاینت
OPTION_RELAY_MSG، دریافت‌شده توسط کارگزار.
*/
// Note: special logic not implemented
// نوع: IPv6 address, binary
{
"code": 47,
"data": "2001:db8::18, 1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "lq-relay-data"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LQ_CLIENT_LINK | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_LQ_CLIENT_LINK (48)
option-len طول فهرست پیوندها به بایت؛ باید مضربی
از ۱۶ باشد.
link-address یک نشانی سراسری که توسط کارگزار برای شناسایی پیوندی
که کلاینت در آن واقع شده استفاده می‌شود.
*/
// Note: special logic not implemented
// نوع: array of {IPv6 address}
{
"code": 48,
"data": "2001:db8::19, 2001:db8::20",
"name": "lq-client-link"
},
// کدهای گزینه ۴۹-۵۰ در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_LOST | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LoST Server Domain Name |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_V6_LOST (51)
option-length: طول فیلد 'LoST Server Domain Name'
به بایت؛ متغیر.
LoST Server Domain Name: نام دامنه کارگزار LoST برای
استفاده کلاینت.
*/
// نوع: FQDN
{
"code": 51,
"data": "lost.example.org",
"name": "v6-lost"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AC IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_CAPWAP_AC_V6 (52)
option-length: طول فیلد 'options' به بایت؛ «باید» مضربی
از شانزده (۱۶) باشد.
AC IPv6 Address: نشانی IPv6 یک CAPWAP AC که WTP می‌تواند استفاده
کند. ACها به ترتیب اولویت برای استفاده توسط WTP فهرست شده‌اند.
*/
// نوع: array of {IPv6 address}
{
"code": 52,
"data": "2001:db8::21, 2001:db8::22",
"name": "capwap-ac-v6"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RELAY_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DUID .
. (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RELAY_ID.
option-len طول DUID به بایت.
DUID شناسه DUID برای عامل رله.
*/
// نوع: binary
{
"code": 53,
"data": "1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "relay-id"
},
// کدهای گزینه ۵۴-۵۶ در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_ACCESS_DOMAIN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Network Domain Name .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_V6_ACCESS_DOMAIN (57).
option-length: طول کل گزینه نام دامنه شبکه دسترسی به بایت.
option-value: نام دامنه مرتبط با شبکه دسترسی، کدگذاری‌شده
همان‌طور که در بخش ۳.۱ توصیف شده است.
*/
// نوع: FQDN
{
"code": 57,
"data": "v6-access.example.org",
"name": "v6-access-domain"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIP_UA_CS_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| searchlist |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SIP_UA_CS_LIST (58)
option-len طول فیلد 'searchlist' به بایت
searchlist مشخصات فهرست نام‌های دامنه در SIP User Agent
Configuration Service Domains
*/
// نوع: array of {FQDN}
{
"code": 58,
"data": "sip-ua1.example.org, sip-ua1.example.org",
"name": "sip-ua-cs-list"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_URL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. boot-file-url (variable length) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPT_BOOTFILE_URL (59).
option-len طول boot-file-url به بایت.
boot-file-url این رشته URL فایل راه‌اندازی است. این رشته «باید»
با STD 66 [RFC3986] مطابقت داشته باشد. رشته به
NUL ختم نمی‌شود.
*/
// نوع: string
{
"code": 59,
"data": "https://boot.example.org/pxe/os.img",
"name": "bootfile-url"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_PARAM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. <multiple Parameters> .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPT_BOOTFILE_PARAM (60).
option-len طول گزینه Boot File Parameters به بایت
(بدون احتساب اندازه فیلدهای option-code و
option-len).
param-len 1...n یک عدد صحیح ۱۶ بیتی است که طول پارامتر بعدی
را به بایت مشخص می‌کند (بدون احتساب فیلد
parameter-length).
parameter 1...n این رشته‌های UTF-8 پارامترهای مورد نیاز برای
راه‌اندازی هستند، مثلاً پارامترهای هسته. رشته‌ها
به NUL ختم نمی‌شوند.
*/
// نوع: array of {tuple}
{
"code": 60,
"data": "root=/dev/sda2, quiet, splash",
"name": "bootfile-param"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_ARCH_TYPE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. architecture-types (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_ARCH_TYPE (61).
option-len طول فیلد "architecture-types" به بایت.
«باید» یک عدد زوج بزرگتر از صفر باشد. برای جزئیات
بخش ۲.۱ از [RFC4578] را ببینید.
architecture-types فهرستی از یک یا چند نوع معماری، همان‌طور که در
بخش ۲.۱ از [RFC4578] مشخص شده است. هر شناسه نوع
معماری در این فهرست یک مقدار ۱۶ بیتی است که
محیط زمان اجرای پیش از راه‌اندازی دستگاه کلاینت را
توصیف می‌کند. فهرستی از مقادیر معتبر توسط IANA
نگهداری می‌شود (بخش ۶ را ببینید).
*/
// نوع: array of {uint16}
{
"code": 61,
"data": "1, 3, 5, 7",
"name": "client-arch-type"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NII | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Major | Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_NII (62).
option-len 3
Type همان‌طور که در بخش ۲.۲ از [RFC4578] مشخص شده است.
Major همان‌طور که در بخش ۲.۲ از [RFC4578] مشخص شده است.
Minor همان‌طور که در بخش ۲.۲ از [RFC4578] مشخص شده است.
*/
// نوع: uint8, uint8, array of {uint8}
{
"code": 62,
"data": "1, 2, 11, 13",
"name": "nii"
},
// کد گزینه ۶۳ در Kea تعریف نشده است.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| OPTION_AFTR_NAME: 64 | option-len |
+-------------------------------+-------------------------------+
| |
| tunnel-endpoint-name (FQDN) |
| |
+---------------------------------------------------------------+
option-len: طول فیلد tunnel-endpoint-name به بایت.
tunnel-endpoint-name: یک نام دامنه کاملاً مشخص‌شده (FQDN) از نقطه
پایانی تونل AFTR
*/
// نوع: FQDN
{
"code": 64,
"data": "aftr.example.org",
"name": "aftr-name"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ERP_LOCAL_DOMAIN_NAME| option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| erp-local-domain-name...
+-+-+-+-+-+-+-+-+-+-+-+-+-
option code
OPTION_ERP_LOCAL_DOMAIN_NAME (65)
option-length
طول فیلد erp-local-domain-name به بایت
erp-local-domain-name
این فیلد شامل نام دامنه محلی ERP است و «باید» همان‌طور که در بخش ۸
از RFC 3315 [RFC3315] مشخص شده کدگذاری شود. توجه داشته باشید که این
کدگذاری استفاده از نام‌های دامنه بین‌المللی‌شده را امکان‌پذیر می‌سازد،
اما فقط به عنوان مجموعه‌ای از A-labelها [RFC5890].
*/
// نوع: FQDN
{
"code": 65,
"data": "erp-local.example.org",
"name": "erp-local-domain-name"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RSOO | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options...
+-+-+-+-+-+-+-+-+-+-+-+
OPTION_RSOO
کد گزینه‌های ارائه‌شده توسط رله (Relay-Supplied Options code) (66).
option-length
طول RSOO.
options
یک یا چند گزینه DHCPv6.
*/
// نوع: empty
{
"code": 66,
"name": "rsoo"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PD_EXCLUDE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-len | IPv6 subnet ID (1 to 16 octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
گزینه استثنای پیشوند (Prefix Exclude Option)
o option-code: OPTION_PD_EXCLUDE (67).
o option-len: ۱ + طول IPv6 subnet ID به بایت. مقدار معتبر
برای option-len بین ۲ و ۱۷ است.
o prefix-len: طول پیشوند مستثنی‌شده بر حسب بیت. مقدار
prefix-len «باید» بین 'OPTION_IAPREFIX prefix-length'+1 و
۱۲۸ باشد.
o IPv6 subnet ID: یک شناسه زیرشبکه IPv6 با طول متغیر تا ۱۲۸ بیت.
*/
// نوع: binary
{
"code": 67,
"data": "2001:db8:1:1::/64",
"name": "pd-exclude"
},
// کدهای گزینه ۶۸-۷۳ در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RDNSS_SELECTION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |prf| |
+-+-+-+-+-+-+-+-+ Domains and networks |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_RDNSS_SELECTION (74)
option-len: طول گزینه به بایت
DNS-recursive-name-server: نشانی IPv6 مربوط به RDNSS
Reserved: فیلد رزروشده برای آینده. «باید» روی صفر تنظیم شود و
«باید» هنگام دریافت نادیده گرفته شود.
prf: اولویت RDNSS:
01 بالا (High)
00 متوسط (Medium)
11 پایین (Low)
10 رزروشده (Reserved)
مقدار اولویت رزروشده (10) «نباید» ارسال شود. هنگام دریافت،
مقدار رزروشده «باید» به عنوان اولویت متوسط (00) در نظر گرفته شود.
*/
// نوع: IPv6 address, uint8, array of {FQDN}
{
"code": 74,
"data": "2001:db8::23, 01, example.com, example.org",
"name": "rdnss-selection"
},
// کدهای گزینه ۷۵-۷۸ در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_LINKLAYER_ADDR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer type (16 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| link-layer address (variable length) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_CLIENT_LINKLAYER_ADDR (79)
option-length: ۲ + طول نشانی link-layer
link-layer type: نوع نشانی لایه پیوند کلاینت. نوع link-layer
«باید» یک نوع سخت‌افزار معتبر تخصیص‌یافته توسط
IANA باشد، همان‌طور که در [RFC0826] توصیف شده است
link-layer address: نشانی لایه پیوند کلاینت
*/
// نوع: binary
{
"code": 79,
"data": "1A BB AD AB BA D0 00 00 00 00 00 00 00 00 CA FE",
"name": "client-linklayer-addr"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LINK_ADDRESS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_LINK_ADDRESS (80)
option-len: ۱۶ (بایت)
link-address: یک نشانی IPv6 که توسط کارگزار برای شناسایی پیوندی
که کلاینت در آن واقع شده استفاده می‌شود.
*/
// نوع: IPv6 address
{
"code": 80,
"data": "2001:db8::24",
"name": "link-address"
},
// کد گزینه ۸۱ در Kea تعریف نشده است.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SOL_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOL_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_SOL_MAX_RT (82).
option-len 4.
SOL_MAX_RT value مقدار جایگزین برای SOL_MAX_RT بر حسب ثانیه؛
«باید» در این محدوده باشد: 60 <= "value" <= 86400
(۱ روز). یک فیلد ۴ بایتی حاوی یک عدد صحیح
بدون علامت.
*/
// نوع: uint32
{
"code": 82,
"data": "420",
"name": "solmax-rt"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INF_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INF_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
تصویر ۳۹: قالب گزینه INF_MAX_RT
option-code OPTION_INF_MAX_RT (83).
option-len 4.
INF_MAX_RT value مقدار جایگزین برای INF_MAX_RT بر حسب ثانیه؛
«باید» در این محدوده باشد: 60 <= "value" <= 86400
(۱ روز). یک فیلد ۴ بایتی حاوی یک عدد صحیح
بدون علامت.
*/
// نوع: uint32
{
"code": 83,
"data": "2220",
"name": "inf-max-rt"
},
// کدهای گزینه ۸۴-۸۶ در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. IPv6 Address(es) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_DHCP4_O_DHCP6_SERVER (88).
option-len: طول نشانی(های) IPv6 حمل‌شده توسط گزینه،
یعنی مضربی از ۱۶ بایت. حداقل طول این گزینه ۰ است.
IPv6 Address: صفر یا چند نشانی IPv6 از کارگزار(های) DHCP 4o6.
*/
// نوع: array of {IPv6 address}
{
"code": 88,
"data": "2001:db8::25, 2001:db8::26",
"name": "dhcp4o6-server-addr"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | ea-len | prefix4-len | ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (continued) | prefix6-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipv6-prefix |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. S46_RULE-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_S46_RULE (89)
o option-length: طول گزینه، بدون احتساب فیلدهای option-code و
option-length، با احتساب طول همه گزینه‌های کپسوله‌شده؛
بیان‌شده به بایت.
o flags: با طول ۸ بیت؛ حامل پرچم‌های قابل اعمال بر قانون.
معانی بیت‌های خاص در تصویر ۲ توضیح داده شده است.
o ea-len: با طول ۸ بیت؛ طول بیتی Embedded Address (EA) را
مشخص می‌کند. مقادیر مجاز بین ۰ تا ۴۸ است.
o prefix4-len: با طول ۸ بیت؛ طول پیشوند Rule IPv4 prefix
مشخص‌شده در فیلد ipv4-prefix را بیان می‌کند. مقادیر مجاز
بین ۰ تا ۳۲ است.
o ipv4-prefix: یک فیلد ۳۲ بیتی با طول ثابت که پیشوند IPv4 را
برای قانون S46 مشخص می‌کند. بیت‌های موجود در پیشوند پس از تعداد
بیت‌های prefix4-len رزرو هستند و «باید» توسط ارسال‌کننده با صفر
مقداردهی اولیه شده و توسط گیرنده نادیده گرفته شوند.
o prefix6-len: با طول ۸ بیت؛ طول پیشوند Rule IPv6 prefix
مشخص‌شده در فیلد ipv6-prefix را بیان می‌کند. مقادیر مجاز
بین ۰ تا ۱۲۸ است.
o ipv6-prefix: یک فیلد با طول متغیر که پیشوند دامنه IPv6 را
برای قانون S46 مشخص می‌کند. این فیلد هنگامی که prefix6-len
به طور مساوی بر ۸ بخش‌پذیر نباشد، از سمت راست با بیت‌های صفر
تا نزدیک‌ترین مرز بایت پر (pad) می‌شود.
o S46_RULE-options: یک فیلد با طول متغیر که ممکن است حاوی صفر یا
چند گزینه باشد که پارامترهای اضافی را برای این قانون S46 تعیین
می‌کنند. این سند یک نمونه از چنین گزینه‌ای را مشخص می‌کند:
OPTION_S46_PORTPARAMS.
*/
// نوع: uint8, uint8, IPv4 address, IPv6 prefix
{
"code": 89,
"data": "1, 0, 24, 192.0.2.0, 2001:db8:1::/64",
"name": "s46-rule",
"space": "s46-cont-mape-options"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_BR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| br-ipv6-address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_S46_BR (90)
o option-length: 16
o br-ipv6-address: یک فیلد ۱۶ بایتی با طول ثابت که نشانی IPv6 را
برای S46 BR مشخص می‌کند.
*/
// نوع: IPv6 address
{
"code": 90,
"data": "2001:db8::27",
"name": "s46-br",
"space": "s46-cont-mape-options"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_DMR | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dmr-prefix6-len| dmr-ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_S46_DMR (91)
o option-length: ۱ + طول dmr-ipv6-prefix مشخص‌شده به بایت.
o dmr-prefix6-len: با طول ۸ بیت؛ طول ماسک بیتی پیشوند IPv6
مشخص‌شده در فیلد dmr-ipv6-prefix را بیان می‌کند. مقادیر مجاز
بین ۰ تا ۱۲۸ است.
o dmr-ipv6-prefix: یک فیلد با طول متغیر که پیشوند یا نشانی IPv6 را
برای BR مشخص می‌کند. هنگامی که dmr-prefix6-len بر ۸ بخش‌پذیر
نباشد، این فیلد از سمت راست تا نزدیک‌ترین مرز بایت با صفر پر می‌شود.
*/
// نوع: IPv6 prefix
{
"code": 91,
"data": "2001:db8:cafe::/64",
"name": "s46-dmr",
"space": "s46-cont-mapt-options"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_V4V6BIND | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipv4-address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|bindprefix6-len| bind-ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. S46_V4V6BIND-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_S46_V4V6BIND (92)
o option-length: طول گزینه، بدون احتساب فیلدهای option-code و
option-length، با احتساب طول همه گزینه‌های کپسوله‌شده؛
بیان‌شده به بایت.
o ipv4-address: یک فیلد ۴ بایتی با طول ثابت که یک نشانی IPv4 را
مشخص می‌کند.
o bindprefix6-len: با طول ۸ بیت؛ طول ماسک بیتی پیشوند IPv6
مشخص‌شده در فیلد bind-ipv6-prefix را بیان می‌کند. مقادیر مجاز
بین ۰ تا ۱۲۸ است.
o bind-ipv6-prefix: یک فیلد با طول متغیر که پیشوند یا نشانی IPv6 را
برای S46 CE مشخص می‌کند. هنگامی که bindprefix6-len بر ۸ بخش‌پذیر
نباشد، این فیلد از سمت راست تا نزدیک‌ترین مرز بایت با صفر پر می‌شود.
o S46_V4V6BIND-options: یک فیلد با طول متغیر که ممکن است حاوی صفر
یا چند گزینه باشد که پارامترهای اضافی را تعیین می‌کنند. این سند یک
نمونه از چنین گزینه‌ای را مشخص می‌کند: OPTION_S46_PORTPARAMS.
*/
// نوع: IPv4 address, IPv6 prefix
{
"code": 92,
"data": "192.0.2.78, 2001:db8:1:cafe::/64",
"name": "s46-v4v6bind",
"space": "s46-cont-lw-options"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_PORTPARAMS | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset | PSID-len | PSID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_S46_PORTPARAMS (93)
o option-length: 4
o offset: مقدار آفست Port Set Identifier (PSID). با طول ۸ بیت؛
مقدار عددی را برای بیت‌های آفست/محدوده درگاه مستثنی‌شده
الگوریتم S46 (بیت‌های a)، طبق بخش ۵.۱ از [RFC7597] مشخص می‌کند.
مقادیر مجاز بین ۰ تا ۱۵ هستند. مقادیر پیش‌فرض برای این فیلد مختص
سازوکار softwire در حال پیاده‌سازی بوده و در سند مشخصات مربوطه
تعریف شده‌اند.
o PSID-len: با طول ۸ بیت؛ تعداد بیت‌های باارزش در فیلد PSID را مشخص
می‌کند (که به عنوان 'k' نیز شناخته می‌شود). وقتی روی ۰ تنظیم شود،
فیلد PSID نادیده گرفته می‌شود. پس از اولین بیت‌های 'a'، تعداد k
بیت در شماره درگاه وجود دارد که مقدار PSID را نشان می‌دهد. در نتیجه،
نسبت اشتراک‌گذاری نشانی برابر با 2^k خواهد بود.
o PSID: با طول ۱۶ بیت. مقدار PSID به صورت الگوریتمی مجموعه‌ای از
درگاه‌های تخصیص‌یافته به یک CE را مشخص می‌کند. اولین k بیت در سمت
چپ این فیلد حاوی مقدار باینری PSID است. بیت‌های باقی‌مانده
(16 - k) در سمت راست، صفرهای پرکننده (padding) هستند.
*/
// نوع: uint8, PSID
{
"code": 93,
"data": "2, 3/4",
"name": "s46-portparams",
"space": "s46-rule-options"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_CONT_MAPE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. encapsulated-options (variable length) .
. .
+---------------------------------------------------------------+
o option-code: OPTION_S46_CONT_MAPE (94)
o option-length: طول گزینه‌های کپسوله‌شده، بیان‌شده به بایت.
o encapsulated-options: گزینه‌های مرتبط با این دامنه
Softwire46 MAP-E.
*/
// نوع: empty
{
"code": 94,
"name": "s46-cont-mape",
"space": "dhcp6"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_CONT_MAPT | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. encapsulated-options (variable length) .
. .
+---------------------------------------------------------------+
o option-code: OPTION_S46_CONT_MAPT (95)
o option-length: طول گزینه‌های کپسوله‌شده، بیان‌شده به بایت.
o encapsulated-options: گزینه‌های مرتبط با این دامنه
Softwire46 MAP-T.
*/
// نوع: empty
{
"code": 95,
"name": "s46-cont-mapt",
"space": "dhcp6"
},
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_CONT_LW | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ encapsulated-options (variable length) .
. .
+---------------------------------------------------------------+
o option-code: OPTION_S46_CONT_LW (96)
o option-length: طول گزینه‌های کپسوله‌شده، بیان‌شده به بایت.
o encapsulated-options: گزینه‌های مرتبط با این دامنه
Softwire46 Lightweight 4over6.
*/
// نوع: empty
{
"code": 96,
"name": "s46-cont-lw",
"space": "dhcp6"
},
// کدهای گزینه ۹۷-۱۰۲ در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: گزینه Captive-Portal DHCPv6 (103) (دو بایت).
o option-len: طول URI به بایت.
o URI: شناسه تماس (URI) برای پورتال دریافت دسترسی (captive portal)
که کاربر باید به آن متصل شود (کدگذاری‌شده طبق قواعد در [RFC3986]).
*/
// نوع: string
{
"code": 103,
"data": "https://example.org/captive-portal",
"name": "v6-captive-portal"
},
// کدهای گزینه ۱۰۴-۱۱۱ در Kea تعریف نشده‌اند.
// کد گزینه ۱۱۲ تخصیص داده نشده است.
// کدهای گزینه ۱۱۳-۱۳۴ در Kea تعریف نشده‌اند.
/*
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code (136) | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. bootstrap-server-list (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_V6_SZTP_REDIRECT (136)
option-length: طول گزینه به بایت.
bootstrap-server-list: فهرستی از کارگزارها برای تلاش کلاینت
جهت برقراری تماس، به منظور به دست آوردن داده‌های راه‌اندازی اولیه
بیشتر. هر مدخل URI در bootstrap-server-list به شکل زیر ساختاربندی
شده است:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-length | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
uri-length: با طول ۲ بایت؛ طول داده‌های URI را مشخص می‌کند.
URI: شناسه URI مربوط به کارگزار راه‌اندازی اولیه SZTP.
*/
// نوع: array of {tuple}
{
"code": 136,
"data": "https://sztp1.example.com:8443, https://sztp2.example.com:8444",
"name": "v6-sztp-redirect"
},
// کدهای گزینه ۱۳۷-۱۴۲ تخصیص داده نشده‌اند.
/*
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
. .
+---------------------------------------------------------------+
Option Code
OPTION-IPv6_Address-ANDSF (143)
Length
طول (به بایت) گزینه بدون احتساب فیلدهای 'Option Code' و
'Length'؛ فیلد 'Length' روی 16N تنظیم می‌شود که N تعداد
نشانی‌های IPv6 حمل‌شده در گزینه است
IP Address
نشانی(های) IPv6 مربوط به کارگزار(های) ANDSF
*/
// نوع: IPv6 address
{
"code": 143,
"data": "2001:db8::28",
"name": "ipv6-address-andsf"
},
/*
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-code | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Priority | ADN Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ipv6-address(es) ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option-code: OPTION_V6_DNR (144)
Option-length: طول داده‌های محصور به بایت. طول گزینه
برابر با ('ADN Length' + 4) است اگر فقط یک ADN در گزینه
گنجانده شده باشد.
Service Priority: اولویت این نمونه OPTION_V6_DNR در مقایسه
با سایر نمونه‌ها. این عدد صحیح بدون علامت ۱۶ بیتی طبق قواعد
مشخص‌شده در بخش ۲.۴.۱ از [RFC9460] تفسیر می‌شود.
ADN Length: طول فیلد authentication-domain-name به بایت.
authentication-domain-name (variable length): یک نام دامنه کاملاً
مشخص‌شده (FQDN) از تحلیل‌گر رمزگذاری‌شده DNS. این فیلد همان‌طور که
در بخش ۱۰ از [RFC9915] مشخص شده قالب‌بندی می‌شود.
Addr Length: طول نشانی‌های IPv6 محصور به بایت. در صورت
حضور، «باید» مضربی از ۱۶ باشد.
ipv6-address(es) (variable length): یک یا چند نشانی IPv6 را برای
دسترسی به تحلیل‌گر رمزگذاری‌شده DNS مشخص می‌کند. یک نشانی می‌تواند
link-local، ‏ULA یا GUA باشد.
Service Parameters (SvcParams) (variable length): مجموعه‌ای از
پارامترهای سرویس را مشخص می‌کند که طبق قواعد بخش ۲.۲ از [RFC9460]
کدگذاری می‌شوند.
*/
// نوع: internal
{
// گزینه DNR ممکن است با استفاده از علامت‌گذاری مناسب پیکربندی شود. فیلدهای جداشده با ویرگول باید ارائه شوند:
// - اولویت سرویس (service priority) (اجباری)،
// - شناسه ADN (اجباری)،
// - نشانی(های) IP (اختیاری - در صورت بیش از یک مورد - باید با فاصله جدا شوند)
// - پارامترهای SvcParams (اختیاری - در صورت بیش از یک مورد - باید با فاصله جدا شوند؛
// برای ارائه بیش از یک alpn-id آن‌ها را با ویرگول گریز داده‌شده با دو بک‌اسلش مانند
// مثال زیر جدا کنید).
// بر اساس این پیکربندی، Kea گزینه را طبق RFC9463 کدگذاری خواهد کرد.
"code": 144,
"name": "v6-dnr",
"data": "100, resolver.example., 2001:db8::1 2001:db8::2, alpn=dot\\,h2\\,h3 port=8530 dohpath=/dns-query{?dns}"
},
// کدهای گزینه ۱۴۵-۶۵۵۳۵ تخصیص داده نشده‌اند.
/*
داده‌های گزینه سفارشی
*/
// برای تعاریف، بخش "option-def" در زیر را ببینید.
{
"code": 111,
"data": "88, 96, 64",
"name": "s46-priority"
},
{
"code": 1,
"name": "my-empty-option",
"space": "my-fancy-space"
},
{
"code": 222,
"data": "2001:db8::29, 2001:db8::/64, 3/4, 1, example.org, string",
"name": "my-lengthy-option",
"space": "my-fancy-space"
},
{
"code": 65432,
"data": "127, 32767, 2147483647, 255, 65535, 4294967295, 192.0.2.79, 2001:db8::30, 2001:db8::/64, 3/4, 1, example.org, string",
"name": "my-fancy-option",
"space": "my-fancy-space"
},
{
"code": 12321,
"name": "my-encapsulating-option",
"space": "my-encapsulating-space"
}
],
/*
تعاریف گزینه سفارشی
*/
// برای kea-dhcp6، تعاریف گزینه‌های سفارشی همیشه سراسری هستند. حتی وقتی
// داده‌های گزینه‌های مذکور سپس در سطح زیرشبکه پیکربندی شوند.
"option-def": [
// درون فضای پیش‌فرض. کدها نباید با سایر تعاریف گزینه استاندارد/سفارشی
// تداخل داشته باشند.
// گزینه‌ای از یک RFC واقعی (8026) که در میان تعاریف استاندارد پیاده‌سازی
// نشده است. این گزینه به عنوان آرایه‌ای از اعداد صحیح ۱۶ بیتی ساختاربندی
// شده است، بنابراین "array" روی true و "type" روی "uint16" تنظیم می‌شود.
{
"array": true,
"code": 111,
"encapsulate": "",
"name": "s46-priority",
"record-types": "",
"space": "dhcp6",
"type": "uint16"
},
// فضای گزینه جدید امکان استفاده از مجموعه‌ای جدید از کدهای گزینه را فراهم می‌کند.
// یک گزینه خالی نیازی به "data" در "option-data" ندارد. وجود
// آن برای فعال‌سازی رفتار سفارشی کافی خواهد بود.
{
"array": false,
"code": 1,
"encapsulate": "",
"name": "my-empty-option",
"record-types": "",
"space": "my-fancy-space",
"type": "empty"
},
// در یک نوع سفارشی، "type" روی "record" تنظیم می‌شود و تمام انواع داده (که باید
// بیش از ۱ مورد باشند، در غیر این صورت بهتر است مستقیماً از نوع استفاده کنید)
// در "record-types" مشخص می‌شوند. اگر "string" بخشی از آن‌ها باشد، باید
// آخرین مورد باشد.
{
"array": false,
"code": 222,
"encapsulate": "",
"name": "my-lengthy-option",
"record-types": "ipv6-address, ipv6-prefix, psid, tuple, fqdn, string",
"space": "my-fancy-space",
"type": "record"
},
// شامل آرایه‌هایی از همه انواع به جز رشته‌ها، زیرا آرایه‌ای از رشته‌ها
// یک تعریف گزینه معتبر نیست.
{
"array": true,
"code": 65432,
"encapsulate": "",
"name": "my-fancy-option",
"record-types": "int8, int16, int32, uint8, uint16, uint32, ipv4-address, ipv6-address, ipv6-prefix.SS kea6/backends.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این یک سناریوی پایه‌ای با یک زیرشبکهٔ IPv6 پیکربندی‌شده است. این مثال نشان می‌دهد
// که چگونه Kea را برای استفاده از بک‌اندهای مختلف جهت ذخیرهٔ اجاره‌ها پیکربندی کنید:
// - memfile
// - MySQL
// - PostgreSQL
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید نوع اجاره را مشخص کنیم. دقیقاً یک بخش lease-database
// باید وجود داشته باشد. اطمینان حاصل کنید که فقط یکی را از حالت کامنت خارج می‌کنید.
// 1. بک‌اند memfile. اطلاعات اجاره‌ها در یک فایل متنی سادهٔ CSV ذخیره خواهد شد.
// این ساده‌ترین بک‌اند برای استفاده است زیرا به هیچ وابستگی اضافی
// یا سرویس در حال اجرایی نیاز ندارد.
"lease-database": {
"type": "memfile",
"persist": true,
"lfc-interval": 3600
},
// 2. بک‌اند MySQL. اجاره‌ها در پایگاه‌دادهٔ MySQL ذخیره خواهند شد. اطمینان حاصل
// کنید که فعال، در حال اجرا و به‌درستی مقداردهی اولیه شده است. برای جزئیات در مورد
// نحوهٔ مقداردهی اولیهٔ پایگاه‌داده به مستندات kea-admin مراجعه کنید. تنها پارامترهایی که
// الزاماً مورد نیاز هستند type و name می‌باشند. اگر پارامترهای دیگر مشخص نشوند،
// Kea فرض می‌کند پایگاه‌داده روی localhost در دسترس است، نام کاربری و
// گذرواژه برای اتصال لازم نیست و مهلت زمانی برابر با 5 ثانیه است.
// برای استفاده از این بک‌اند، Kea باید با گزینهٔ "-D mysql"; کامپایل شده باشد.
// "lease-database": {
// "type": "mysql",
// "name": "keatest",
// "host": "localhost",
// "port": 3306,
// "user": "keatest",
// "password": "1234",
// "reconnect-wait-time": 3000, // بیان‌شده به میلی‌ثانیه
// "max-reconnect-tries": 3,
// "on-fail": "stop-retry-exit",
// "retry-on-startup": false,
// "connect-timeout": 3
// },
// از نسخهٔ Kea.2.7.4 به بعد، کتابخانهٔ هوک libdhcp_mysql.so باید بارگذاری شود تا
// اجاره‌ها در بک‌اند پایگاه‌دادهٔ اجارهٔ MySQL ذخیره شوند.
// مکان کتابخانهٔ هوک بک‌اند اجاره را مشخص کنید.
// {
// // کتابخانهٔ هوک بک‌اند اجارهٔ MySQL که برای ذخیره‌سازی اجاره‌ها لازم است.
// "library": "libdhcp_mysql.so"
// },
// 3. بک‌اند PostgreSQL. اجاره‌ها در پایگاه‌دادهٔ PostgreSQL ذخیره خواهند شد. اطمینان
// حاصل کنید که فعال، در حال اجرا و به‌درستی مقداردهی اولیه شده است. برای جزئیات در مورد
// نحوهٔ مقداردهی اولیهٔ پایگاه‌داده به مستندات kea-admin مراجعه کنید. تنها پارامترهایی که
// الزاماً مورد نیاز هستند type و name می‌باشند. اگر پارامترهای دیگر مشخص نشوند،
// Kea فرض می‌کند پایگاه‌داده روی localhost در دسترس است، نام کاربری و
// گذرواژه برای اتصال لازم نیست و مهلت زمانی برابر با 5 ثانیه است.
// برای استفاده از این بک‌اند، Kea باید با گزینهٔ "-D postgresql"; کامپایل شده باشد.
// "lease-database": {
// "type": "postgresql",
// "name": "keatest",
// "host": "localhost",
// "port": 5432,
// "user": "keatest",
// "password": "1234",
// "reconnect-wait-time": 3000, // بیان‌شده به میلی‌ثانیه
// "max-reconnect-tries": 3,
// "on-fail": "stop-retry-exit",
// "retry-on-startup": false,
// "connect-timeout": 3
// },
// از نسخهٔ Kea.2.7.4 به بعد، کتابخانهٔ هوک libdhcp_pgsql.so باید بارگذاری شود تا
// اجاره‌ها در بک‌اند پایگاه‌دادهٔ اجارهٔ PostgreSQL ذخیره شوند.
// مکان کتابخانهٔ هوک بک‌اند اجاره را مشخص کنید.
// {
// // کتابخانهٔ هوک بک‌اند اجارهٔ PostgreSQL که برای ذخیره‌سازی اجاره‌ها لازم است.
// "library": "libdhcp_pgsql.so"
// },
// آدرس‌ها با طول‌عمرهای ترجیحی (preferred) و معتبر (valid) که به ترتیب
// 3000 و 4000 هستند اختصاص داده خواهند شد. به کلاینت گفته می‌شود که پس از
// 1000 ثانیه تمدید را آغاز کند. اگر کارساز پس از 2000 ثانیه از زمان اعطای
// اجاره پاسخی نداد، کلاینت باید روال REBIND (تمدید اضطراری که
// امکان جابه‌جایی به یک کارساز دیگر را فراهم می‌کند) را آغاز کند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// مدخل‌های subnet و pool است.
"subnet6": [
{
"pools": [ { "pool": "2001:db8:1::/80" } ],
"id": 1,
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// بخش زیر ثبت وقایع (logging) را پیکربندی می‌کند. فرض می‌شود که پیام‌هایی با
// حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// هدف این مثال نمایش نحوه دسته‌بندی کلاینت‌ها است.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// بیایید از ساده‌ترین بک‌اند یعنی memfile و مقادیر معقولی
// برای تایمرها استفاده کنیم. آن‌ها ارتباطی با نمایش دسته‌بندی ندارند.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
// این فهرست چندین کلاس را تعریف می‌کند که بسته‌های ورودی می‌توانند به آن‌ها اختصاص یابند.
// یک بسته می‌تواند متعلق به صفر یا چند کلاس باشد.
"client-classes": [
// کلاس نخست تلاش می‌کند تمام بسته‌های ورودی از رابط eth0 را تطبیق دهد.
{
"name": "lab",
"test": "pkt.iface == 'eth0'",
"option-data": [{
"name": "dns-servers",
"data": "2001:db8::1"
}]
},
// بیایید تمام پیام‌های ورودی RENEW (نوع پیام 5) را در یک کلاس مجزا
// دسته‌بندی کنیم.
{
"name": "renews",
"test": "pkt6.msgtype == 5"
},
// بیایید مودم‌های کابلی را انتخاب کنیم. در این مثال ساده فرض می‌کنیم اگر دستگاه
// یک گزینه سازنده با enterprise-id برابر با 4491 ارسال کند،
// یک مودم کابلی است.
{
"name": "cable-modems",
"test": "vendor.enterprise == 4491"
}
],
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// مدخل‌های subnet و pool است.
"subnet6": [
{
"id": 1,
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"client-classes": [ "cable-modems" ],
"interface": "eth0"
},
// زیرشبکه زیر شامل یک رزرو کلاس برای کلاینتی با شناسه
// DUID 01:02:03:04:05:0A:0B:0C:0D:0E است. این کلاینت همواره به
// این کلاس اختصاص داده خواهد شد.
{
"id": 2,
"pools": [ { "pool": "2001:db8:2::/80" } ],
"subnet": "2001:db8:2::/64",
"reservations": [
{
"duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
"client-classes": [ "cable-modems" ]
} ],
"interface": "eth0"
},
// زیرشبکه زیر شامل یک استخر با محدودیت کلاسی است: تنها
// کلاینت‌هایی که متعلق به این کلاس هستند مجاز به استفاده از این استخر می‌باشند.
{
"id": 3,
"pools": [
{
"pool": "2001:db8:4::/80",
"client-classes": [ "cable-modems" ]
} ],
"subnet": "2001:db8:4::/64",
"interface": "eth1"
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌ها حداقل با
// سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// هدف این نمونه نمایش چگونگی طبقه‌بندی کلاینت‌ها است.
{ "Dhcp6":
{
// به Kea دستور داده شده است که فقط روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// بیایید از ساده‌ترین بک‌اند استفاده کنیم: memfile و چند مقدار معقول
// برای زمان‌سنج‌ها در نظر بگیریم. آن‌ها در نمایش طبقه‌بندی نقشی ندارند.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
// این فهرست چندین کلاس را تعریف می‌کند که بسته‌های دریافتی می‌توانند به آن‌ها منتسب شوند.
// یک بسته می‌تواند عضو صفر یا چند کلاس باشد.
"client-classes": [
// این کلاس توسط زیرشبکه دوم در فهرست 'evaluate-additional-classes' آن گنجانده شده،
// بنابراین 'only-in-additional-list' فعال است. این تضمین می‌کند کلاس تنها
// در صورتی ارزیابی شود که زیرشبکه دوم انتخاب گردد. عبارت آزمون true برمی‌گرداند.
// توجه داشته باشید که وابستگی به کلاس cable-modems امکان‌پذیر نیست زیرا
// هنوز تعریف نشده است.
{
"name": "second_subnet",
"only-in-additional-list": true,
"test": "member('ALL')",
"option-data": [{
"name": "dns-servers",
"data": "2001:db8::1"
}]
},
// بیایید تمام پیام‌های RENEW دریافتی (نوع پیام ۵) را در یک کلاس مجزا
// طبقه‌بندی کنیم.
{
"name": "renews",
"test": "pkt6.msgtype == 5"
},
// بیایید مودم‌های کابلی را انتخاب کنیم. در این مثال ساده فرض می‌کنیم دستگاه در صورتی
// یک مودم کابلی است که یک گزینه سازنده با enterprise-id برابر با
// 4491 ارسال کند.
{
"name": "cable-modems",
"test": "vendor.enterprise == 4491"
},
// هم یک مودم کابلی باشد (از طریق ارزیابی یا رزرو میزبان) و هم دارای یک رزرو
// میزبان باشد.
{
"name": "cable-modem-hosts",
"test": "member('cable-modems') and member('KNOWN')"
}
],
// فهرست زیر، زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل ورودی‌های
// subnet و pool است.
"subnet6": [
{
"id": 1,
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"client-classes": [ "cable-modems" ],
"interface": "eth0"
},
// زیرشبکه زیر شامل رزرو کلاس برای کلاینتی با مشخصه
// DUID 01:02:03:04:05:0A:0B:0C:0D:0E است. این کلاینت همواره به این کلاس
// منتسب خواهد شد.
{
"id": 2,
"pools": [ { "pool": "2001:db8:2::/80" } ],
"subnet": "2001:db8:2::/64",
"reservations": [
{
"duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
"client-classes": [ "cable-modems" ]
} ],
"interface": "eth0",
"evaluate-additional-classes": [ "second_subnet" ]
},
// زیرشبکه زیر شامل یک استخر با قید کلاسی است: فقط کلاینت‌هایی که
// به این کلاس تعلق دارند مجاز به استفاده از این استخر هستند.
{
"id": 3,
"pools": [
{
"pool": "2001:db8:4::/80",
"client-classes": [ "cable-modems" ]
} ],
"subnet": "2001:db8:4::/64",
"interface": "eth1"
},
// این زیرشبکه برای کلاینت‌های ناشناخته (unknown) و شناخته‌شده (known)
// (یعنی کلاینت‌هایی که رزرو دارند) به دو استخر تقسیم شده است. کلاس‌های درونی KNOWN و
// UNKNOWN در زمان جستجوی رزرو میزبان مقداردهی می‌شوند (اگر موردی یافت شود KNOWN،
// و اگر چیزی یافت نشود UNKNOWN) و کلاس‌های کلاینت وابسته به آن ارزیابی می‌گردند.
// این مرحله پس از انتخاب زیرشبکه و پیش از تخصیص نشانی از استخرها رخ می‌دهد.
{
"id": 4,
"pools": [
{
"pool": "2001:db8:8::/64",
"client-classes": [ "UNKNOWN" ]
},
{
"pool": "2001:db8:9::/64",
"client-classes": [ "KNOWN" ]
}
],
"subnet": "2001:db8:8::/46",
"reservations": [
{ "hw-address": "00:00:00:11:22:33", "hostname": "h1" },
{ "hw-address": "00:00:00:44:55:66", "hostname": "h4" },
{ "hw-address": "00:00:00:77:88:99", "hostname": "h7" },
{ "hw-address": "00:00:00:aa:bb:cc", "hostname": "ha" }
]
}
],
// پیکربندی زیر مربوط به گزارش‌گیری است. فرض بر این است که پیام‌هایی حداقل
// با سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این فایل از کامنت‌های تعبیه‌شده (یعنی مواردی که در اشیاء پیکربندی گنجانده
// شده و در مرحله تحلیل واژگانی حذف نمی‌گردند) استفاده می‌کند.
{ "Dhcp6":
{
// دامنه سراسری
"comment": "یک کارساز DHCPv6",
// در پیکربندی رابط
"interfaces-config": {
"comment": "استفاده از نویسه عمومی (wildcard)",
"interfaces": [ "*" ] },
// در تعاریف گزینه‌ها
"option-def": [ {
"comment": "یک تعریف گزینه",
"name": "foo",
"code": 100,
"type": "ipv6-address",
"space": "isc"
} ],
// در داده‌های گزینه
"option-data": [ {
"comment": "تنظیم مقدار گزینه",
"name": "subscriber-id",
"data": "ABCDEF0105",
"csv-format": false
} ],
// در کلاس‌های کلاینت
"client-classes": [
{
"comment": "تطابق با همه",
"name": "all",
"test": "'' == ''"
},
// البته کامنت‌ها اختیاری هستند
{
"name": "none"
},
// می‌توان یک کامنت و یک user-context مشخص کرد
{
"comment": "یک کامنت",
"name": "both",
"user-context": {
"version": 1
}
}
],
// در سوکت‌های کنترلی
"control-sockets": [
{
"socket-type": "unix",
"socket-name": "kea6-ctrl-socket",
"user-context": { "comment": "کامنت غیرمستقیم" }
},
{
"comment": "سوکت کنترلی HTTP",
"socket-type": "http",
"socket-address": "127.0.0.1",
"socket-port": 8006,
// در احراز هویت
"authentication": {
"comment": "احراز هویت پایه HTTP",
"type": "basic",
// در کلاینت‌های احراز هویت پایه HTTP
"clients": [ {
"user": "admin",
"password": "1234"
} ]
}
}
],
// در شبکه‌های اشتراکی
"shared-networks": [ {
"comment": "یک شبکه اشتراکی",
"name": "foo",
// در زیرشبکه‌ها
"subnet6": [
{
"comment": "یک زیرشبکه",
"subnet": "2001:db1::/64",
"id": 100,
// در استخرها
"pools": [
{
"comment": "یک استخر",
"pool": "2001:db1::/64"
}
],
// در استخرهای پیشوند
"pd-pools": [
{
"comment": "یک استخر پیشوند",
"prefix": "2001:db2::",
"prefix-len": 48,
"delegated-len": 64
}
],
// در رزروهای میزبان
"reservations": [
{
"comment": "یک رزرو میزبان",
"hw-address": "AA:BB:CC:DD:EE:FF",
"hostname": "foo.example.com",
// مجدداً در داده‌های گزینه
"option-data": [ {
"comment": "یک گزینه در رزرو",
"name": "domain-search",
"data": "example.com"
} ]
}
]
}
]
} ],
// در dhcp ddns
"dhcp-ddns": {
"comment": "بدون DNS پویا",
"enable-updates": false
},
// در ثبت‌کننده‌ها
"loggers": [ {
"comment": "یک ثبت‌کننده",
"name": "kea-dhcp6"
} ]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv4 در Kea است.
// این پرونده نحوهٔ فعال‌سازی Configuration Backend در Kea را با استفاده از MySQL نشان می‌دهد.
// این مورد نیازمند در دسترس بودن کتابخانهٔ libdhcp_mysql.so و
// به صورت اختیاری کتابخانهٔ قلاب libdhcp_cb_cmds.so است.
{ "Dhcp6":
{
// برچسب کارساز را برای backend پیکربندی تنظیم کنید. این نمونه
// server2 نامیده خواهد شد. هر بخش از پیکربندی که برای
// "all" یا "server2" قابل اعمال باشد توسط این نمونه استفاده خواهد شد.
"server-tag": "server2",
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// استفاده از backend پایگاه‌دادهٔ اجارهٔ memfile.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// این پارامتر نحوهٔ دسترسی کارساز به پایگاه‌دادهٔ پیکربندی را کنترل می‌کند.
// در حال حاضر فقط دو نوع پایگاه‌داده در دسترس است - "mysql" و
// "postgresql".
// استفاده از "mysql" نیازمند بارگذاری کتابخانهٔ قلاب libdhcp_mysql.so است.
// در صورت استفاده از "postgresql"، بارگذاری کتابخانهٔ قلاب libdhcp_pgsql.so
// الزامی است.
"config-control": {
// فهرستی از backendهای پایگاه‌داده برای اتصال. در حال حاضر به یک
// backend محدود است.
"config-databases": [
{
"type": "mysql",
"reconnect-wait-time": 3000, // بر حسب میلی‌ثانیه
"max-reconnect-tries": 3,
"name": "kea",
"user": "kea",
"password": "1234",
"host": "localhost",
"port": 3306
}
],
// کنترل می‌کند که کارساز هر چند وقت یک‌بار برای به‌روزرسانی‌های
// پیکربندی از پایگاه‌داده بازپرسی کند. تنظیم زیر نشان می‌دهد که
// کشف و دریافت تغییرات پیکربندی توسط کارساز حداکثر
// حدود ۲۰ ثانیه طول خواهد کشید.
"config-fetch-wait-time": 20
},
// این مورد یک سوکت کنترلی تعریف می‌کند. در صورت تعریف، Kea یک سوکت UNIX
// باز کرده و به دستورهای دریافتی گوش می‌دهد. برای جزئیات به بخش ۱۷
// راهنمای مرجع سرپرست Kea (ARM) مراجعه کنید.
"control-socket": {
"socket-type": "unix",
"socket-name": "kea6-ctrl-socket"
},
// کتابخانه‌های قلابی که Configuration Backend را فعال می‌کنند بارگذاری شده‌اند.
"hooks-libraries": [
// کتابخانهٔ libdhcp_mysql.so برای استفاده از Configuration Backend
// مربوط به MySQL مورد نیاز است.
{
"library": "libdhcp_mysql.so"
}
// در صورت استفاده از Configuration Backend مربوط به PostgreSQL، کتابخانهٔ "libdhcp_pgsql.so"
// مورد نیاز است.
// {
// "library": "libdhcp_pgsql.so"
// }
// کتابخانهٔ libdhcp_cb_cmds.so اختیاری است. این کتابخانه امکان مدیریت
// پیکربندی در پایگاه‌داده را فراهم می‌کند. اگر این کتابخانه بارگذاری نشود،
// پیکربندی را می‌توان مستقیماً با استفاده از ابزارهای موجود که مستقیماً با
// پایگاه‌دادهٔ MySQL کار می‌کنند مدیریت کرد.
// ,{
// "library": "libdhcp_cb_cmds.so"
// }
],
// بخش زیر ثبت وقایع (logging) را پیکربندی می‌کند. فرض بر این است پیام‌هایی با
// حداقل سطح اطلاعاتی (info،‏ warn،‏ error و fatal) باید در
// stdout ثبت شوند. در غیر این صورت، می‌توانید stderr، نام یک فایل
// یا 'syslog' را مشخص کنید، که پیام‌های خروجی را از طریق syslog ذخیره خواهد کرد.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
168u
kea6/dhcpv4-over-dhcpv6.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 جهت
// آزمایش‌های DHCPv4-over-DHCPv6 در Kea است.
{
// پیکربندی DHCPv6
"Dhcp6":
{
"interfaces-config": {
// فعال‌سازی تک‌پخشی (unicast)
"interfaces": [ "eth0/2001:db8:1::1" ]
},
"lease-database": {
"type": "memfile",
"name": "kea-leases6.csv"
},
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"subnet6": [
{ "id": 1,
"subnet": "2001:db8:1:1::/64",
"interface": "eth0",
"pools": [ { "pool": "2001:db8:1:1::1:0/112" } ] }
],
// این مورد پشتیبانی از DHCPv4-over-DHCPv6 را فعال می‌کند
"dhcp4o6-port": 786,
// مورد نیاز برای کلاینت‌های DHCPv4-over-DHCPv6
"option-data": [
{ "name": "dhcp4o6-server-addr",
"code": 88,
"space": "dhcp6",
"csv-format": true,
// نشانی کارساز را در اینجا قرار دهید
"data": "2001:db8:1:1::1" }
],
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "kea-dhcp6.log"
}
],
"severity": "DEBUG",
"debuglevel": 0
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea است.
// این فایل نحوه پیکربندی Kea را برای استفاده از DUID-LLT با برخی
// مقادیر مشخص‌شده به صورت صریح نمایش می‌دهد.
{ "Dhcp6":
{
// پیکربندی شناسه کارگزار (DUID-LLT). مقدار هگزادسیمال شناسه
// به عنوان مؤلفه نشانی لایه پیوند DUID استفاده خواهد شد.
// نوع لایه پیوند ethernet خواهد بود. مقدار time روی 0 تنظیم شده است
// که نشان می‌دهد کارگزار باید این مقدار را تولید کند، یعنی از
// زمان فعلی استفاده کند. توجه داشته باشید که مهاجرت از این پیکربندی
// به DUID-EN یا DUID-LL آسان است. این کار مستلزم تغییر مقدار "type"
// به ترتیب به "EN" یا "LL" است. مقدار "identifier" شامل
// یک شناسه با طول متغیر DUID-EN یا نشانی لایه پیوند DUID-LL خواهد بود.
// مقادیر "time" و "htype" برای DUID-EN نادیده گرفته می‌شوند.
// اگر کسی بخواهد از یک enterprise-id غیرپیش‌فرض برای DUID-EN استفاده کند،
// پارامتر "enterprise-id" باید اضافه شود. توجه داشته باشید که هنگام
// مشخص کردن نگاشت "server-id" تنها پارامتر "type" اجباری است.
"server-id": {
"type": "LLT",
"identifier": "12C4D5AF870C",
"time": 0,
"htype": 1
},
// به Kea دستور داده شده است که فقط روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. از
// ژوئن ۲۰۲۲، سه پس‌بند پایگاه داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// نشانی‌ها با طول عمر ترجیحی (preferred) و معتبر (valid)
// به ترتیب ۳۰۰۰ و ۴۰۰۰ اختصاص خواهند یافت. به کلاینت اعلام می‌شود که پس از
// 1000 ثانیه تمدید را آغاز کند. اگر کارگزار پس از ۲۰۰۰ ثانیه از زمان
// اعطای اجاره پاسخ ندهد، کلاینت باید روال REBIND (تمدید اضطراری که
// امکان جابه‌جایی به یک کارگزار دیگر را می‌دهد) را شروع کند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل از
// مدخل‌های subnet و pool تشکیل شده است.
"subnet6": [
{
"id": 1,
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی با حداقل
// سطح اطلاعاتی (info، warn، error) در stdout ثبت خواهند شد.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
168u
kea6/global-reservations.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea است.
// این فایل نحوه پیکربندی رزروهای سراسری میزبان را نشان می‌دهد.
// رزروهای سراسری با هیچ زیرشبکه‌ای مرتبط نیستند. آن‌ها صرف‌نظر از
// زیرشبکه‌ای که کلاینت DHCP به آن تعلق دارد، اختصاص می‌یابند.
// رزروهای سراسری با استفاده از همان انواع شناسه میزبان که در رزروهای خاصِ زیرشبکه
// به کار می‌روند، به کلاینت‌های DHCP اختصاص داده می‌شوند. این فایل شامل چندین
// نمونه از رزرو میزبان با استفاده از انواع شناسه‌های مختلف، مانند DUID، نشانی MAC و غیره است.
{ "Dhcp6":
{
// به Kea دستور داده شده است که فقط روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. از
// ژوئن ۲۰۲۲، سه پس‌بند پایگاه داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// این موارد بسیار ابتدایی هستند و ارتباطی با رزروها ندارند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// سامانه Kea از سه نوع شناسه در DHCPv6 پشتیبانی می‌کند: hw-address (نشانی
// سخت‌افزاری/MAC کلاینت)، duid (شناسه DUID درج‌شده توسط کلاینت) و flex-id
// (شناسه انعطاف‌پذیر موجود در زمان بارگذاری کتابخانه قلاب flex_id). در صورت
// تعیین، Kea می‌تواند هر یک از این انواع شناسه را بررسی کند، اما انجام این کار
// نیازمند جستجوی پرهزینه در پایگاه داده است. بنابراین از دیدگاه کارایی، مفید است
// که تنها از انواع رزروی استفاده شود که عملاً در شبکه مربوطه به کار می‌روند.
"host-reservation-identifiers": [ "duid", "hw-address", "flex-id" ],
// این دستور به Kea اعلام می‌کند که رزروها سراسری هستند. توجه داشته باشید که این
// مقدار می‌تواند در سطح shared network و/یا subnet نیز مشخص شود.
// مشخص می‌کند که آیا کارگزار باید رزروهای سراسری را جستجو کند یا خیر.
"reservations-global": true,
// مشخص می‌کند که آیا کارگزار باید رزروهای درون زیرشبکه را جستجو کند یا خیر.
"reservations-in-subnet": false,
// مشخص می‌کند که آیا کارگزار می‌تواند فرض کند که همه نشانی‌های رزروشده
// خارج از استخر هستند یا خیر.
// در صورتی که reservations-in-subnet برابر با false باشد، نادیده گرفته می‌شود.
// در صورت تعیین، توسط سطوح "shared-networks" و "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// تعریف چندین رزرو سراسری میزبان.
"reservations": [
// این یک رزرو ساده میزبان است. میزبانی که DUID آن با مقدار
// مشخص‌شده مطابقت داشته باشد، نشانی 2001:db8:1::100 را دریافت خواهد کرد.
// توجه داشته باشید که رزرو نشانی‌ها در دامنه سراسری توصیه نمی‌شود اما مجاز است:
// از آنجا که پیوند میان رزرو و زیرشبکه را قطع می‌کند، می‌تواند باعث شود
// کلاینت در زیرشبکه‌ای غیر از زیرشبکه نشانی خود قرار گیرد.
{
"duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
"ip-addresses": [ "2001:db8:1::100" ]
},
// این مورد شبیه به مورد قبلی است، با این تفاوت که این بار رزرو بر اساس
// نشانی سخت‌افزاری/MAC انجام می‌شود. کارگزار تمام تلاش خود را برای استخراج
// نشانی سخت‌افزاری/MAC از بسته‌های دریافتی به کار می‌گیرد (برای جزئیات به
// دستور 'mac-sources' مراجعه کنید). این رزرو به خصوص همچنین دو گزینه
// اضافی را برای این کلاینت تعیین می‌کند. اگر گزینه‌هایی با کد یکسان در دامنه
// سراسری، زیرشبکه یا کلاس مشخص شده باشند، مقادیر تعریف‌شده در سطح میزبان
// برای این کلاینت خاص DHCP اولویت خواهند داشت.
{
"hw-address": "00:01:02:03:04:05",
"ip-addresses": [ "2001:db8:1::101" ],
"option-data": [
{
"name": "dns-servers",
"data": "3000:1::234"
},
{
"name": "nis-servers",
"data": "3000:1::234"
}
],
"client-classes": [ "special_snowflake", "office" ]
},
// این یک رزرو کمی پیشرفته‌تر است. کلاینت با DUID مشخص‌شده، یک
// نشانی رزروشده، یک پیشوند رزروشده و یک نام میزبان دریافت خواهد کرد.
// حداقل یکی از این سه مورد باید در رزرو تعیین شود.
// در نهایت، این رزرو شامل گزینه‌های ویژه شرکت سازنده برای CableLabs است
// که از enterprise-id 4491 استفاده می‌کند. این مقادیر خاص فقط به کلاینتی
// بازگردانده می‌شوند که DUID آن با این رزرو مطابقت داشته باشد.
{
"duid": "01:02:03:04:05:06:07:08:09:0A",
"ip-addresses": [ "2001:db8:1:cafe::1" ],
"prefixes": [ "2001:db8:2:abcd::/64" ],
"hostname": "foo.example.com",
"option-data": [
{
"name": "vendor-opts",
"data": "4491"
},
{
"name": "tftp-servers",
"space": "vendor-4491",
"data": "3000:1::234"
}
]
},
// این رزرو از شناسه انعطاف‌پذیر استفاده می‌کند. مدیر سیستم
// به جای تکیه بر یک فیلد خاص، می‌تواند عبارتی مشابه آنچه برای دسته‌بندی کلاینت‌ها
// استفاده می‌شود تعریف کند، مانند substring(relay[0].option[17],0,6). سپس
// بر اساس مقدار آن عبارت برای بسته ورودی، رزرو مطابقت داده می‌شود.
// عبارت می‌تواند به صورت هگز یا متن ساده با استفاده از نقل‌قول تکی
// مشخص شود.
// نکته: شناسه انعطاف‌پذیر برای کارکرد به بارگذاری کتابخانه قلاب flex_id
// نیاز دارد.
{
"flex-id": "'somevalue'",
"ip-addresses": [ "2001:db8:1:cafe::2" ]
}
],
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. تعاریف زیرشبکه، استخرها و رابط‌ها
// مشابه سناریوی عادی است.
"subnet6": [
{
"id": 1,
"subnet": "2001:db8::/47",
"pools": [ { "pool": "2001:db8::/64" } ],
"pd-pools": [
{
"prefix": "2001:db8:1:8000::",
"prefix-len": 56,
"delegated-len": 64
}
],
"interface": "eth0"
}
],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی با
// حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک پیکربندی نمونه از کارگزار Kea DHCPv6 است. این پیکربندی از کتابخانه
// قلاب High Availability و کتابخانه قلاب Lease Commands برای فعال‌سازی
// قابلیت دسترسی‌پذیری بالا (HA) برای کارگزار DHCP استفاده می‌کند. توجه داشته باشید
// که تقریباً دقیقاً همین پیکربندی باید در کارگزار دوم (شریک) استفاده شود.
// تنها تفاوت این است که "this-server-name" در آن کارگزار دیگر باید روی
// "server2" تنظیم شود. همچنین، پیکربندی رابط و مکان فایل‌های مربوط به
// TLS به تنظیمات شبکه و پیکربندی آن دستگاه خاص بستگی دارد.
//
// کارگزارهایی که از این پیکربندی استفاده می‌کنند در حالت hot standby کار می‌کنند.
{
// پیکربندی DHCPv6 از اینجا شروع می‌شود.
"Dhcp6": {
// نام‌های رابط‌های شبکه خود را برای شنود اضافه کنید.
"interfaces-config": {
// کارگزار DHCPv6 روی این رابط شنود می‌کند.
"interfaces": [ "eth0" ]
},
// استفاده از پسانه پایگاه‌داده اجاره Memfile برای ذخیره اجاره‌ها در یک فایل CSV.
// بسته به نحوه کامپایل Kea، ممکن است از پایگاه‌های داده SQL نیز پشتیبانی کند
// (MySQL و/یا PostgreSQL). آن پسانه‌های پایگاه‌داده به پارامترهای بیشتری مانند
// name، host و احتمالاً user و password نیاز دارند.
// برای هر پسانه مثال‌های اختصاصی وجود دارد. برای جزئیات به بخش 7.2.2
// "Lease Storage" مراجعه کنید.
"lease-database": {
// Memfile ساده‌ترین و آسان‌ترین پسانه برای استفاده است. این یک پسانه درون‌حافظه‌ای است
"type": "memfile"
},
// قابلیت HA نیازمند بارگذاری دو کتابخانه قلاب است: libdhcp_lease_cmds.so و
// libdhcp_ha.so. اولی به‌روزرسانی‌های ورودی اجاره از همتایان HA را مدیریت می‌کند.
// دومی قابلیت دسترسی‌پذیری بالا را برای Kea پیاده‌سازی می‌کند.
"hooks-libraries": [
// کتابخانه lease_cmds باید بارگذاری شود زیرا HA از آن برای تحویل
// به‌روزرسانی‌های اجاره به کارگزار و همچنین همگام‌سازی پایگاه‌داده
// اجاره پس از خرابی استفاده می‌کند.
{
"library": "libdhcp_lease_cmds.so",
"parameters": { }
},
{
// کتابخانه قلاب HA باید بارگذاری شود.
"library": "libdhcp_ha.so",
"parameters": {
// پیکربندی دسترسی‌پذیری بالا برای کتابخانه قلاب HA مشخص شده است.
// هر کارگزار باید پیکربندی HA یکسانی داشته باشد، به جز
// پارامتر "this-server-name".
"high-availability": [ {
// این پارامتر به این نمونه کارگزار اشاره دارد. همتایان HA
// مربوطه باید این پارامتر را روی نام‌های خودشان تنظیم کنند.
"this-server-name": "server1",
// حالت HA روی hot-standby تنظیم شده است. این کارگزار به‌روزرسانی‌های
// اجاره را از سرور اصلی دریافت خواهد کرد. سرور اصلی به تمام
// پرس‌وجوهای DHCP پاسخ خواهد داد.
"mode": "hot-standby",
// اگر هیچ دستور کنترلی دیگری ارسال نشود، ضربان قلب (heartbeat)
// باید هر ۱۰ ثانیه فرستاده شود.
"heartbeat-delay": 10000,
// حداکثر زمان برای پاسخ شریک به ضربان قلب، که پس از آن
// تشخیص خرابی آغاز می‌شود. این مقدار به میلی‌ثانیه مشخص می‌شود.
"max-response-delay": 60000,
// پارامترهای زیر نحوه تشخیص خرابی شریک توسط کارگزار را کنترل
// می‌کنند. تاخیر ACK آستانه را برای فیلد 'secs' پیام‌های کشف
// دریافت‌شده تنظیم می‌کند. این مقدار به میلی‌ثانیه مشخص می‌شود.
"max-ack-delay": 5000,
// این پارامتر تعداد کلاینت‌هایی را مشخص می‌کند که پیام‌هایی
// به شریک ارسال می‌کنند اما به نظر می‌رسد پاسخی دریافت نمی‌کنند.
"max-unacked-clients": 5,
// مرجع اعتماد (trust anchor) یا همان فایل یا دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی کلاینت.
"cert-file": "/usr/lib/kea/server_cert.pem",
// نام فایل کلید خصوصی.
"key-file": "/usr/lib/kea/server_key.pem",
// گواهی‌های کلاینت الزامی هستند و تایید اعتبار می‌شوند.
"require-client-certs": true,
"peers": [
// این پیکربندیِ این نمونه کارگزار است.
{
"name": "server1",
// این پارامتر نشانی URL این نمونه کارگزار را مشخص می‌کند.
"url": "http://192.168.56.33:8007",
// این کارگزار primary (اصلی) است. کارگزار دیگر باید
// standby (آماده‌به‌خدمت) باشد.
"role": "primary"
},
// این پیکربندی همتای HA است.
{
"name": "server2",
// نشانی URL را مشخص می‌کند که کانال کنترلی شریک
// روی آن در دسترس است.
"url": "http://192.168.56.66:8007",
// شریک standby است. این کارگزار primary است.
"role": "standby"
}
]
} ]
}
}
],
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// ورودی‌های subnet و pool است.
"subnet6": [
{
"id": 1,
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::100 - 2001:db8:1::250"
}
],
"interface": "eth0"
}
],
// بخش زیر ثبت گزارش را پیکربندی می‌کند. فرض می‌شود که پیام‌هایی با حداقل
// سطح اطلاعاتی (info، warn، error و fatal) باید در stdout ثبت شوند.
// به عنوان روش جایگزین، می‌توانید stderr، یک نام فایل یا 'syslog' را
// در اینجا مشخص کنید که پیام‌های خروجی را از طریق syslog ذخیره می‌کند.
"loggers": [
{
// این بخش بر kea-dhcp6 اثر می‌گذارد که گزارش‌گر پایه برای مولفه
// DHCPv6 است. این بخش به کارگزار DHCPv6 می‌گوید که همه پیام‌های
// گزارش (با سطح اهمیت INFO یا بیشتر) را در یک فایل بنویسد.
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 0
},
{
// این بخش پیکربندی گزارش‌گر مخصوص کتابخانه قلاب HA را مشخص می‌کند.
"name": "kea-dhcp6.ha-hooks",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 99
}
]
}
}
168u
0.0
3.5
// این یک پیکربندی نمونه از کارساز Kea DHCPv6 است. این پیکربندی از کتابخانه
// قلاب دسترسی‌پذیری بالا (High Availability) و کتابخانه قلاب دستورات اجاره
// (Lease Commands) برای فعال‌سازی قابلیت دسترسی‌پذیری بالا برای کارساز DHCP استفاده می‌کند.
// توجه داشته باشید که تقریباً دقیقاً همین پیکربندی باید در کارساز دوم (همتا/partner)
// استفاده شود. تنها تفاوت این است که "this-server-name" روی آن کارساز دیگر
// باید روی "server1" تنظیم شود. همچنین، پیکربندی رابط به تنظیمات شبکه ماشین
// مربوطه بستگی دارد.
//
// کارسازهایی که از این پیکربندی استفاده می‌کنند در حالت hot standby کار می‌کنند.
{
// پیکربندی DHCPv6 از اینجا آغاز می‌شود.
"Dhcp6": {
// نام‌های رابط‌های شبکه خود را برای گوش فرا دادن اضافه کنید.
"interfaces-config": {
// کارساز DHCPv6 روی این رابط گوش فرا می‌دهد.
"interfaces": [ "eth0" ]
},
// برای ذخیره اجاره‌ها در یک فایل CSV از backend پایگاه‌داده اجاره Memfile استفاده کنید.
// بسته به نحوه کامپایل Kea، ممکن است از پایگاه‌های داده SQL نیز پشتیبانی کند
// (MySQL و/یا PostgreSQL). این backendهای پایگاه‌داده به پارامترهای بیشتری
// نیاز دارند، مانند name،‏ host و احتمالاً user و password.
// مثال‌های اختصاصی برای هر backend وجود دارد. برای جزئیات به بخش 7.2.2 "Lease
// Storage" مراجعه کنید.
"lease-database": {
// ‏Memfile ساده‌ترین و آسان‌ترین backend برای استفاده است. این یک [پایگاه‌داده] درون‌حافظه‌ای است
"type": "memfile"
},
// قابلیت HA نیازمند بارگذاری دو کتابخانه قلاب است: libdhcp_lease_cmds.so و
// libdhcp_ha.so. اولی به‌روزرسانی‌های دریافتی اجاره را از همتایان HA مدیریت می‌کند.
// دومی قابلیت دسترسی‌پذیری بالا را برای Kea پیاده‌سازی می‌کند.
"hooks-libraries": [
// کتابخانه lease_cmds باید بارگذاری شود زیرا HA از آن برای تحویل
// به‌روزرسانی‌های اجاره به کارساز و همچنین همگام‌سازی پایگاه‌داده اجاره
// پس از خرابی استفاده می‌کند.
{
"library": "libdhcp_lease_cmds.so",
"parameters": { }
},
{
// کتابخانه قلاب HA باید بارگذاری شود.
"library": "libdhcp_ha.so",
"parameters": {
// پیکربندی دسترسی‌پذیری بالا برای کتابخانه قلاب HA مشخص شده است.
// هر کارساز باید پیکربندی HA یکسانی داشته باشد، به جز
// پارامتر "this-server-name".
"high-availability": [ {
// این پارامتر به این نمونه کارساز اشاره می‌کند. همتایان HA
// مربوطه باید این پارامتر را روی نام‌های خود تنظیم کرده باشند.
"this-server-name": "server2",
// حالت HA روی hot-standby تنظیم شده است. این کارساز به‌روزرسانی‌های
// اجاره را از primary دریافت خواهد کرد. کارساز primary به تمامی
// پرس‌وجوهای DHCP پاسخ خواهد داد.
"mode": "hot-standby",
// در صورت عدم انتقال دستورات کنترلی دیگر، ضربان قلب (heartbeat)
// باید هر ۱۰ ثانیه یک‌بار ارسال شود.
"heartbeat-delay": 10000,
// حداکثر زمان برای پاسخ شریک به ضربان قلب، که پس از آن
// تشخیص خرابی آغاز می‌شود. این مقدار به میلی‌ثانیه مشخص شده است.
"max-response-delay": 60000,
// پارامترهای زیر نحوه تشخیص خرابی شریک توسط کارساز را کنترل
// می‌کنند. تأخیر ACK آستانه را برای فیلد 'secs' از discoverهای
// دریافتی تنظیم می‌کند. این مقدار به میلی‌ثانیه مشخص شده است.
"max-ack-delay": 5000,
// این پارامتر تعداد کلاینت‌هایی را مشخص می‌کند که به شریک پیام
// ارسال می‌کنند اما به نظر می‌رسد پاسخی دریافت نمی‌کنند.
"max-unacked-clients": 5,
"peers": [
// این پیکربندی همتای HA است.
{
"name": "server1",
// نشانی URL را مشخص می‌کند که از طریق آن می‌توان به کانال
// کنترلی شریک دسترسی پیدا کرد.
"url": "http://192.168.56.33:8007/",
// شریک primary است. این کارساز standby است.
"role": "primary"
},
// این پیکربندی نمونه این کارساز است.
{
"name": "server2",
// این مقدار نشانی URL مربوط به نمونه این کارساز را مشخص می‌کند.
"url": "http://192.168.56.66:8007/",
// این کارساز standby است. کارساز دیگر باید
// primary باشد.
"role": "standby"
}
]
} ]
}
}
],
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل از
// مدخل‌های subnet و pool تشکیل شده است.
"subnet6": [
{
"id": 1,
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::100 - 2001:db8:1::250"
}
],
"interface": "eth0"
}
],
// بخش زیر ثبت وقایع را پیکربندی می‌کند. فرض بر این است که پیام‌ها حداقل
// در سطح اطلاعاتی (info،‏ warn،‏ error و fatal) باید در stdout ثبت شوند.
// به عنوان جایگزین، می‌توانید در اینجا stderr، یک نام فایل یا 'syslog'
// را مشخص کنید که پیام‌های خروجی را از طریق syslog ذخیره می‌کند.
"loggers": [
{
// این بخش بر kea-dhcp6 که ثبت‌کننده وقایع پایه برای مؤلفه DHCPv6
// است تأثیر می‌گذارد. این بخش به کارساز DHCPv6 می‌گوید تا تمام پیام‌های
// ثبت وقایع (با سطح اهمیت INFO یا بالاتر) را در یک فایل بنویسد.
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 0
},
{
// این بخش پیکربندی ثبت‌کننده وقایع اختصاصی کتابخانه قلاب HA
// را مشخص می‌کند.
"name": "kea-dhcp6.ha-hooks",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO",
"debuglevel": 99
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea با استفاده از
// کتابخانه قلاب کنترل دسترسی بر پایه نقش (RBAC) است. این پیکربندی از سناریوی پایه
// یک زیرشبکه IPv6 که با مقادیر پیش‌فرض برای همه پارامترها پیکربندی شده، استفاده می‌کند.
{"Dhcp6":
{
// به Kea اعلام شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// راه‌اندازی فضای ذخیره‌سازی برای اجاره‌ها (leases).
"lease-database": {
"type": "memfile"
},
// تنظیم مقادیر برای زمان‌سنج‌های اجباری
"renew-timer": 900,
"rebind-timer": 1200,
"preferred-lifetime": 1800,
"valid-lifetime": 2700,
// تعریف یک زیرشبکه تکی.
"subnet6": [
{
"id": 1,
"pools": [
{
"pool": "2001:db8:1::/80",
"user-context": { "charging": true }
} ],
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// سوکت‌های کنترلی.
"control-sockets": [
{
"socket-type": "https",
"socket-address": "::1",
"socket-port": 8000,
"trust-anchor": "my-ca",
"cert-file": "my-cert",
"key-file": "my-key",
"cert-required": true
}
],
// افزودن قلاب‌ها (hooks) در اینجا.
"hooks-libraries": [
{
"library": "libdhcp_rbac.so",
"parameters": {
// این بخش کتابخانه قلاب RBAC را پیکربندی می‌کند.
// پارامترهای اجباری.
"assign-role-method": "cert-subject",
"api-files": "/opt/share/kea/api",
// پارامترهای اختیاری.
"require-tls": true,
"commands": [
{
"name": "my-command",
"access": "read",
"hook": "my-hook"
} ],
"access-control-lists": [
{
"my-none": { "not": "ALL" }
},{
"another-none": { "and": [ "ALL", "NONE" ] }
},{
"my-read": { "access": "read" }
} ],
"roles": [
{
"name": "kea-client",
"accept-commands":
{
"commands": [ "list-commands", "status-get" ]
},
"reject-commands": "NONE",
"other-commands": "reject",
"list-match-first": "accept",
"response-filters": [ "list-commands" ]
},{
"name": "admin",
"accept-commands": "ALL",
"reject-commands":
{
"hook": "cb_cmds"
},
"list-match-first": "reject"
} ],
"default-role":
{
"accept-commands": "NONE",
"reject-commands": "ALL"
},
"unknown-role":
{
"accept-commands": "READ",
"reject-commands": "WRITE"
}
}
}
]
}
}
168u
168u
kea6/hooks.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است که
// نحوه پیکربندی کتابخانه‌های قلاب را نشان می‌دهد. این پیکربندی از سناریوی پایه
// یک زیرشبکه IPv6 که با مقادیر پیش‌فرض برای همه پارامترها پیکربندی شده، استفاده می‌کند.
{"Dhcp6":
{
// به Kea اعلام شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// راه‌اندازی فضای ذخیره‌سازی برای اجاره‌ها (leases).
"lease-database": {
"type": "memfile"
},
// تنظیم مقادیر برای زمان‌سنج‌های اجباری
"renew-timer": 900,
"rebind-timer": 1200,
"preferred-lifetime": 1800,
"valid-lifetime": 2700,
// تعریف یک زیرشبکه تکی.
"subnet6": [
{
"id": 1,
"pools": [
{
"pool": "2001:db8:1::/80",
"user-context": { "charging": true }
} ],
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// راه‌اندازی کتابخانه‌های قلاب. برای این مثال، فرض می‌کنیم دو کتابخانه به نام‌های
// "security" و "charging" بارگذاری شده‌اند. توجه داشته باشید که ترتیب مهم است:
// ابتدا "security" مشخص شده است، بنابراین اگر هر دو کتابخانه یک تابع قلاب
// برای یک قلاب مشخص ارائه دهند، تابع موجود در "security" پیش از تابع موجود در
// "charging" فراخوانی خواهد شد.
"hooks-libraries": [
{
"library": "security.so"
},
{
"library": "charging.so",
"parameters": {
"path": "/var/log/kea",
"base-name": "kea-forensic6"
}
}
]
}
}
168u
0.0
3.5
// این یک پیکربندی نمونه برای بوت iPXE در Kea6 است.
{
"Dhcp6": {
// بخش اجباری پیکربندی که رابط‌هایی را فهرست می‌کند که
// Kea روی آن‌ها به ترافیک ورودی گوش خواهد داد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// دو کلاس از نمونه ISC-DHCP مهاجرت داده شده‌اند:
// if exists dhcp6.client-arch-type and
// option dhcp6.client-arch-type = 00:07 {
// option dhcp6.bootfile-url "http://[2001:db8::1]/ipxe.efi";
// } else if exists dhcp6.user-class and
// substring(option dhcp6.user-class, 2, 4) = "iPXE" {
// option dhcp6.bootfile-url "http://[2001:db8::1]/ubuntu.cfg";
// }
// در مثال نشان‌داده‌شده در زیر، اگر بسته ورودی شامل گزینه user class
// حاوی "iPXE" باشد، مقدار http://[2001:db8::1]/ubuntu.cfg
// را دریافت می‌کند و اگر گزینه نوع معماری کلاینت برابر با 7 باشد،
// مقدار http://[2001:db8::1]/ipxe.efi را دریافت خواهد کرد.
// اگر بسته ورودی شامل هر دوی این گزینه‌ها با مقادیر منطبق باشد، به کلاس
// "a-ipxe" اختصاص می‌یابد زیرا نخستین کلاس منطبق بوده است. اگر می‌خواهید
// آن ترتیب را تغییر دهید، نام‌های کلاس‌ها باید ترتیب الفبایی متفاوتی
// داشته باشند. در Kea 1.3.0 (و نسخه‌های پیشین) از ترتیب الفبایی در
// دسته‌بندی استفاده می‌شود. توجه داشته باشید که این مورد در نسخه‌های بعدی
// باید تغییر کند، برای نمونه جهت حفظ ترتیب تعریف.
"client-classes": [
{
"name": "a-ipxe",
// گزینه user-class (کد 15) یک آرایه از تاپل‌ها است
// بنابراین باید از طول (عنصر اول تاپل) صرف‌نظر کنیم
"test": "substring(option[15].hex, 2, 4) == 'iPXE'",
"option-data": [
{
"space": "dhcp6",
"name": "bootfile-url",
"code": 59,
"data": "http://[2001:db8::1]/ubuntu.cfg"
}
]
},
{
"name": "b-efi",
// لطفاً برای تحمیل "else"، افزودن یک
// not a-ipxe را در اینجا در نظر بگیرید؟
"test": "option[61].hex == 0x0007",
"option-data": [
{
"space": "dhcp6",
"name": "bootfile-url",
"code": 59,
"data": "http://[2001:db8::1]/ipxe.efi"
}
]
}
],
"subnet6": [
{
"id": 1,
"subnet": "2001:db8::/64"
}
]
}
}
168u
168u
kea6/leases-expiration.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این فایل پارامترهای کنترل پردازش اجاره‌های منقضی‌شده،
// معروف به بازپس‌گیری اجاره‌ها (leases reclamation) را ارائه می‌دهد.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن 2022، سه پسانه پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده می‌کنیم زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
// توجه کنید که حداکثر تعداد خطاهای خواندن ردیف را روی 100 تنظیم می‌کنیم،
// (پیش‌فرض 0 است، به معنای نامحدود).
"lease-database": {
"type": "memfile",
"lfc-interval": 3600,
"max-row-errors": 100
},
// پارامترهای زیر پردازش اجاره‌های منقضی‌شده را کنترل می‌کنند. اجاره‌های
// منقضی‌شده به صورت دوره‌ای بر اساس پارامتر "reclaim-timer-wait-time"
// بازپس‌گرفته می‌شوند. اجاره‌های بازپس‌گرفته‌شده برای تسهیل قرابت اجاره
// (lease affinity) به مدت 1800 ثانیه در پایگاه‌داده نگهداری خواهند شد. پس از این
// دوره، اجاره‌ها حذف خواهند شد. بسامد حذف توسط پارامتر
// "flush-reclaimed-timer-wait-time" کنترل می‌شود. روال بازپس‌گیری اجاره
// در طول یک بار اجرا، حداکثر 500 اجاره را پردازش می‌کند یا حداکثر
// 100 میلی‌ثانیه به طول می‌انجامد. اگر پس از 10 تلاش همچنان اجاره‌های
// بازپس‌گرفته‌نشده‌ای باقی مانده باشد، یک پیام هشدار صادر می‌شود.
// اگر هر دو پارامتر "flush-reclaimed-timer-wait-time" و "hold-reclaimed-time"
// غیر از 0 باشند، هنگامی که کلاینت یک پیام release می‌فرستد، اجاره به جای
// حذف شدن از فضای ذخیره‌سازی اجاره، منقضی می‌شود.
"expired-leases-processing": {
"reclaim-timer-wait-time": 5,
"hold-reclaimed-time": 1800,
"flush-reclaimed-timer-wait-time": 10,
"max-reclaim-leases": 500,
"max-reclaim-time": 100,
"unwarned-reclaim-cycles": 10
},
// نشانی‌ها به ترتیب با طول‌عمرهای ترجیحی و معتبر برابر با
// 3000 و 4000 تخصیص می‌یابند. به کلاینت گفته می‌شود که تجدید
// را پس از 1000 ثانیه آغاز کند. اگر کارساز پس از گذشت 2000 ثانیه از
// اعطای اجاره پاسخ ندهد، کلاینت باید روال REBIND را آغاز کند
// (تجدید اضطراری که امکان جابه‌جایی به یک کارساز دیگر را فراهم می‌کند).
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل از
// مدخل‌های subnet و pool تشکیل شده است.
"subnet6": [
{
"id": 1,
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// موارد زیر ثبت وقایع را پیکربندی می‌کنند. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این فایل، پیکربندی ساده گزینه‌ها برای یک زیرشبکه را نشان می‌دهد.
{ "Dhcp6":
{
// به Kea اعلام شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا تاریخ
// ژوئن ۲۰۲۲، سه پسانه پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد، چرا که نیازی به هیچ راه‌اندازی اولیه‌ای ندارد.
"lease-database": {
"type": "memfile"
},
// نشانی‌ها با طول‌عمرهای ترجیحی و معتبر که به ترتیب ۳۰۰۰ و ۴۰۰۰
// ثانیه هستند تخصیص داده می‌شوند. به کارگیر گفته می‌شود که پس از ۱۰۰۰
// ثانیه تمدید را آغاز کند. اگر کارساز پس از گذشت ۲۰۰۰ ثانیه از اعطای اجاره
// پاسخ ندهد، کارگیر باید فرایند REBIND (تمدید اضطراری که امکان تعویض
// به یک کارساز دیگر را فراهم می‌کند) را آغاز کند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// تعریف یک زیرشبکه. چندین گزینه DHCP به کارگیرهای متصل به این زیرشبکه
// برگردانده می‌شود. نخستین گزینه با نام مشخص شده است.
// گزینه دوم با کد مشخص شده است. دو استخر نشانی در این زیرشبکه
// تعریف شده است. مقدار ویژه استخر برای گزینه 12 برای این استخر تعریف
// شده است: 2001:db8:1::1 - 2001:db8:1::100. کارگیرهایی که نشانی را
// از این استخر به دست می‌آورند، گزینه 12 با مقدار 3001:cafe::21 به آن‌ها
// اختصاص می‌یابد. کارگیرهای متعلق به این زیرشبکه که نشانی را از استخر دیگر
// دریافت می‌کنند یا کارگیرهایی که پیکربندی بدون‌حالت (stateless) را به دست می‌آورند،
// مقدار ویژه زیرشبکه گزینه 12، یعنی 2001:db8:1:0:ff00::1 به آن‌ها اختصاص می‌یابد.
// در DHCPv6، زیرشبکه‌ها می‌توانند استخرهای تفویض پیشوند نیز داشته باشند؛
// بنابراین یک pd-pools با option-data نیز تعریف شده است.
"subnet6": [
{
// به این صورت مقادیر گزینه‌ها برای این زیرشبکه خاص تعریف می‌شوند.
"option-data": [
// هنگام تعیین گزینه‌ها، معمولاً باید یکی از (name یا code) و data را مشخص کنید.
// مشخصات کامل گزینه شامل name، code، space، csv-format و data است.
// مقدار پیش‌فرض space برابر "dhcp6" است که معمولاً درست است، مگر اینکه از
// گزینه‌های کپسوله‌شده استفاده کنید. csv-format به‌طور پیش‌فرض برابر "true" است،
// پس این نیز درست است، مگر اینکه بخواهید کل مقدار گزینه را به‌صورت یک رشته هگز
// طولانی مشخص کنید. به عنوان مثال، برای تعیین domain-name-servers می‌توانید
// این کار را انجام دهید:
// {
// "name": "dns-servers",
// "code": 23,
// "csv-format": true,
// "space": "dhcp6",
// "data": "2001:db8:2::45, 2001:db8:2::100"
// }
// اما نوشتن آن طولانی است، بنابراین ساده‌تر است که به جای آن این کار را بکنید:
{
"name": "dns-servers",
"data": "2001:db8:2::45, 2001:db8:2::100"
},
// معمولاً افراد ترجیح می‌دهند با نام‌ها به گزینه‌ها ارجاع دهند تا
// نیازی به حفظ کردن شماره کدها نداشته باشند. با این حال، برخی ترجیح می‌دهند
// از مقادیر عددی استفاده کنند. برای مثال، DHCPv6 می‌تواند در صورت وجود یک گزینه اضافی،
// به‌صورت اختیاری از ارتباط تک‌پخشی (unicast) با کارساز استفاده کند. گزینه
// "unicast" از کد گزینه 12 استفاده می‌کند، بنابراین می‌توانید با
// "name": "unicast" یا "code": 12 به آن ارجاع دهید.
{
"code": 12,
"data": "2001:db8:1:0:ff00::1"
},
// گزینه‌ها را می‌توان در قالب شانزده‌شانزدهی (hexadecimal) نیز تعیین کرد.
// در صورت امکان باید از این کار پرهیز شود، چرا که توانایی Kea برای
// اعتبارسنجی درستی مقادیر هنگام استفاده از مقادیر هگز محدود است.
{
"name": "sntp-servers",
"csv-format": false,
"data": "20010db8000000000000000000000001"
},
// گزینه‌های رشته‌ای که در مقادیر خود دارای ویرگول (کاما) هستند، باید آن را
// گریز دهند (یعنی قبل از هر ویرگول دو بک‌اسلش قرار گیرد).
// دلیل آن این است که ویرگول‌ها برای جداسازی فیلدها در گزینه‌های مرکب رزرو شده‌اند.
// هم‌زمان، ما باید با استاندارد JSON که "\," را مجاز نمی‌داند، سازگار باشیم.
// بنابراین نشانه‌گذاری اندکی نامتعارف دو بک‌اسلش لازم است.
// گریزهای مجاز JSON شامل \ هستند که بعد از آن نویسه "\/bfnrt می‌آید
// یا \u که بعد از آن ۴ رقم شانزده‌شانزدهی قرار می‌گیرد (در حال حاضر Kea
// فقط از نقاط کد \u0000 تا \u00ff پشتیبانی می‌کند).
// پردازش CSV فقط '\\' را به '\' و '\,' را به ','
// تبدیل می‌کند؛ مثلاً '\x' به '\x' تبدیل می‌شود. اما
// از آنجا که روی یک مقدار رشته‌ای JSON عمل می‌کند، هر یک از این
// نویسه‌های '\' باید در ورودی JSON دو بار تکرار شوند.
{
"name": "new-posix-timezone",
"data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00"
},
// گزینه‌هایی که مقادیر صحیح می‌پذیرند را می‌توان در قالب ده‌دهی (dec)
// یا هگز (hex) تعیین کرد. قالب هگز می‌تواند ساده (مانند abcd)
// یا با پیشوند 0x (مانند 0xabcd) باشد.
{
"name": "preference",
"data": "0xf0"
},
// تعداد کمی از گزینه‌ها در چندتایی‌های (طول، رشته) کدگذاری می‌شوند
// که می‌توان آن‌ها را تنها با استفاده از رشته‌ها تعریف کرد، زیرا
// پردازش CSV طول‌ها را محاسبه می‌کند.
{
"name": "bootfile-param",
"data": "root=/dev/sda2, quiet, splash"
},
// به جز چند استثنا، گزینه‌ها تنها هنگامی به پاسخ اضافه می‌شوند که
// کارگیر آن‌ها را درخواست کند. پرچم always-send باید برای اجباری
// کردن یک گزینه خاص استفاده شود.
{
"name": "pana-agent",
"data": "2001:db8:2::123",
"always-send": true
}
],
"pools": [
{
"pool": "2001:db8:1::1 - 2001:db8:1::100",
"option-data": [
{
"code": 12,
"data": "3001:cafe::21"
}
]
},
{
"pool": "2001:db8:1::500 - 2001:db8:1::1000"
}
],
"pd-pools": [
{
"prefix": "2001:2b8:2::",
"prefix-len": 56,
"delegated-len": 64,
"option-data": [
{
"code": 12,
"data": "3001:cafe::12"
}
]
}
],
"id": 1,
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// بخش زیر پیکربندی ثبت رویدادها (logging) است. فرض بر این است که پیام‌هایی
// با دست‌کم سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این فایل شامل پیکربندی backend پایگاه‌داده میزبان MySQL است که برای
// بازیابی نشانی‌های رزرو شده، نام‌های میزبان، فیلدهای پیام DHCPv4
// و گزینه‌های DHCP از پایگاه‌داده MySQL استفاده می‌شود.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرادهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن ۲۰۲۲، سه backend پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده می‌کنیم زیرا نیازی به راه‌اندازی اولیه ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// این‌ها موارد بسیار پایه‌ای هستند و ارتباطی با رزروها ندارند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// نرم‌افزار Kea از دو نوع شناسه در DHCPv6 پشتیبانی می‌کند: hw-address
// (نشانی سخت‌افزاری/MAC کلاینت) و duid (شناسه DUID درج‌شده توسط
// کلاینت). در صورت تعیین، Kea می‌تواند هر یک از این نوع شناسه‌ها را
// بررسی کند، اما این کار مستلزم جست‌وجوی هزینه‌بر در پایگاه‌داده است. بنابراین
// از دیدگاه کارایی، بهتر است تنها از نوع رزروهایی استفاده شود که واقعاً در یک شبکه مشخص به کار می‌روند.
"host-reservation-identifiers": [ "duid", "hw-address" ],
// مشخص کردن اتصال به پایگاه‌داده نگه‌دارنده رزروهای میزبان. مقدار type
// مشخص می‌کند که از پایگاه‌داده MySQL استفاده می‌شود. user و password اطلاعات
// اعتبارسنجی مورد استفاده برای اتصال به پایگاه‌داده هستند. host و name مکان
// میزبانی که نمونه پایگاه‌داده روی آن در حال اجرا است و نام پایگاه‌داده مورد استفاده
// را تعیین می‌کنند. کارساز هنگام پردازش یک بسته، ابتدا بررسی می‌کند که آیا در
// فهرست رزروها درون زیرشبکه (فایل پیکربندی) رزروی برای این کلاینت مشخص شده است
// یا خیر. اگر رزروی در آن‌جا نباشد، کارساز تلاش می‌کند تا رزروها را از این پایگاه‌داده بازیابی کند.
"hosts-database": {
"type": "mysql",
"reconnect-wait-time": 3000, // بر حسب میلی‌ثانیه
"max-reconnect-tries": 3,
"name": "keatest",
"user": "keatest",
"password": "1234",
"host": "localhost",
"port": 3306,
"readonly": true,
"trust-anchor": "my-ca",
"cert-file": "my-cert",
"key-file": "my-key",
"cipher-list": "AES"
},
// از نسخه Kea.2.7.4 به بعد، برای ذخیره رزروهای میزبان در MySQL Host Database Backend،
// کتابخانه قلاب libdhcp_mysql.so باید بارگیری شود.
// مکان کتابخانه قلاب backend میزبان را مشخص کنید.
"hooks-libraries": [
{
// کتابخانه قلاب backend میزبان MySQL که برای ذخیره‌سازی میزبان لازم است.
"library": "libdhcp_mysql.so"
}
],
// تعریف یک زیرشبکه با یک استخر از نشانی‌های پویا و یک استخر از پیشوندهای
// پویا. نشانی‌ها و پیشوندها از این استخرها به کلاینت‌هایی که رزروی در
// پایگاه‌داده ندارند تخصیص داده خواهد شد. شناسه زیرشبکه برابر با 1 است.
// اگر این زیرشبکه برای کلاینت انتخاب شود، از شناسه این زیرشبکه برای
// جست‌وجوی رزروها در پایگاه‌داده استفاده می‌شود.
"subnet6": [
{
"subnet": "2001:db8:1::/48",
"pools": [ { "pool": "2001:db8:1::/80" } ],
"pd-pools": [
{
"prefix": "2001:db8:1:8000::",
"prefix-len": 56,
"delegated-len": 64
}
],
"interface": "eth0",
"id": 1
}
],
// بخش زیر پیکربندی ثبت گزارش‌ها (logging) است. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout
// ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
168u
kea6/pgsql-reservations.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این فایل شامل پیکربندی backend پایگاه‌داده میزبان PostgreSQL است که برای
// بازیابی نشانی‌های رزرو شده، نام‌های میزبان، فیلدهای پیام DHCPv4
// و گزینه‌های DHCP از پایگاه‌داده PostgreSQL استفاده می‌شود.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرادهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن ۲۰۲۲، سه backend پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده می‌کنیم زیرا نیازی به راه‌اندازی اولیه ندارد.
"lease-database": {
"type": "memfile"
},
// این‌ها موارد بسیار پایه‌ای هستند و ارتباطی با رزروها ندارند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// نرم‌افزار Kea از دو نوع شناسه در DHCPv6 پشتیبانی می‌کند: hw-address
// (نشانی سخت‌افزاری/MAC کلاینت) و duid (شناسه DUID درج‌شده توسط
// کلاینت). در صورت تعیین، Kea می‌تواند هر یک از این نوع شناسه‌ها را
// بررسی کند، اما این کار مستلزم جست‌وجوی هزینه‌بر در پایگاه‌داده است. بنابراین
// از دیدگاه کارایی، بهتر است تنها از نوع رزروهایی استفاده شود که واقعاً در یک شبکه مشخص به کار می‌روند.
"host-reservation-identifiers": [ "duid", "hw-address" ],
// مشخص کردن اتصال به پایگاه‌داده نگه‌دارنده رزروهای میزبان. مقدار type
// مشخص می‌کند که از پایگاه‌داده PostgreSQL استفاده می‌شود. user و password اطلاعات
// اعتبارسنجی مورد استفاده برای اتصال به پایگاه‌داده هستند. host و name مکان
// میزبانی که نمونه پایگاه‌داده روی آن در حال اجرا است و نام پایگاه‌داده مورد استفاده
// را تعیین می‌کنند. کارساز هنگام پردازش یک بسته، ابتدا بررسی می‌کند که آیا در
// فهرست رزروها درون زیرشبکه (فایل پیکربندی) رزروی برای این کلاینت مشخص شده است
// یا خیر. اگر رزروی در آن‌جا نباشد، کارساز تلاش می‌کند تا رزروها را از این پایگاه‌داده بازیابی کند.
// مشخصات پایگاه‌داده برای سازگاری با نسخه‌های پیشین می‌تواند درون یک مدخل hosts-database
// قرار گیرد یا در فهرست hosts-databases آورده شود.
"hosts-databases": [
{
"type": "postgresql",
"reconnect-wait-time": 3000, // بر حسب میلی‌ثانیه
"max-reconnect-tries": 3,
"name": "keatest",
"user": "keatest",
"password": "1234",
"host": "localhost"
}
],
// از نسخه Kea.2.7.4 به بعد، برای ذخیره رزروهای میزبان در PostgreSQL Host Database Backend،
// کتابخانه قلاب libdhcp_pgsql.so باید بارگیری شود.
// مکان کتابخانه قلاب backend میزبان را مشخص کنید.
"hooks-libraries": [
{
// کتابخانه قلاب backend میزبان PostgreSQL که برای ذخیره‌سازی میزبان لازم است.
"library": "libdhcp_pgsql.so"
}
],
// تعریف یک زیرشبکه با یک استخر از نشانی‌های پویا و یک استخر از پیشوندهای
// پویا. نشانی‌ها و پیشوندها از این استخرها به کلاینت‌هایی که رزروی در
// پایگاه‌داده ندارند تخصیص داده خواهد شد. شناسه زیرشبکه برابر با 1 است.
// اگر این زیرشبکه برای کلاینت انتخاب شود، از شناسه این زیرشبکه برای
// جست‌وجوی رزروها در پایگاه‌داده استفاده می‌شود.
"subnet6": [
{
"subnet": "2001:db8:1::/48",
"pools": [ { "pool": "2001:db8:1::/80" } ],
"pd-pools": [
{
"prefix": "2001:db8:1:8000::",
"prefix-len": 56,
"delegated-len": 64
}
],
"interface": "eth0",
"id": 1
}
],
// بخش زیر پیکربندی ثبت گزارش‌ها را انجام می‌دهد. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout
// ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است
// که نحوه انجام رزروهای میزبان را نشان می‌دهد. فرض بر این است
// که یک زیرشبکه (2001:db8:1::/64) مستقیماً روی رابط eth0 در دسترس
// است. برای تعدادی از میزبان‌ها، ترکیب‌های گوناگونی از نشانی‌ها
// و پیشوندها رزرو شده است.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. تا
// ژوئن ۲۰۲۲، از سه پیشانه پایگاه‌داده پشتیبانی می‌شود: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای، Memfile.
// ما از memfile استفاده خواهیم کرد زیرا نیازی به راه‌اندازی اولیه ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// این‌ها مواردی کاملاً ساده و پایه‌ای هستند و ارتباطی با رزروها ندارند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// کارساز Kea از سه نوع شناسه در DHCPv6 پشتیبانی می‌کند: hw-address (نشانی
// سخت‌افزاری/MAC کلاینت)، duid (شناسه DUID درج‌شده توسط کلاینت) و flex-id
// (شناسه انعطاف‌پذیر موجود هنگام بارگذاری کتابخانه قلاب flex_id). در صورت
// تنظیم، Kea می‌تواند هر یک از این انواع شناسه را بررسی کند، اما این کار مستلزم
// جست‌وجوی پرهزینه‌ای در پایگاه‌داده است. بنابراین از دیدگاه کارایی سودمند است که
// تنها از انواع رزروی استفاده شود که واقعاً در شبکه مورد نظر به کار می‌روند.
"host-reservation-identifiers": [ "duid", "hw-address", "flex-id" ],
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. تعاریف زیرشبکه، استخرها و رابط‌ها
// مشابه سناریوی عادی و بدون رزرو میزبان هستند؛ دست‌کم
// مدخل‌های زیرشبکه و استخر.
"subnet6": [
{
"id": 1,
"subnet": "2001:db8:1::/48",
// این دستورالعمل به Kea می‌گوید که رزروها می‌توانند هم درون‌استخر
// و هم خارج‌ازاستخر انجام شوند. برای بهبود کارایی، می‌توانید همه رزروها
// را به خارج از استخر پویا منتقل کرده و "reservations-out-of-pool" را روی true تنظیم کنید.
// در این صورت Kea هنگام تخصیص اجاره‌ها از استخر پویا، قادر خواهد بود
// از جست‌وجوی رزروهای میزبان صرف‌نظر کند.
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را جست‌وجو کند یا خیر.
// پیش‌فرض: false.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون‌زیرشبکه را جست‌وجو کند یا خیر.
// پیش‌فرض: true.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند همه نشانی‌های رزروشده
// خارج‌ازاستخر هستند یا خیر. پیش‌فرض: false.
// هنگامی که reservations-in-subnet برابر با false باشد نادیده گرفته می‌شود.
// در صورت تعیین، در سطوح "shared-networks" و
// "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
"pools": [ { "pool": "2001:db8:1::/120" } ],
"pd-pools": [
{
"prefix": "2001:db8:1:8000::",
"prefix-len": 56,
"delegated-len": 64
}
],
"interface": "eth0",
// رزروهای میزبان. تعریف چندین رزرو؛ توجه داشته باشید که
// همه آن‌ها در محدوده استخر نشانی‌های تخصیص‌یافته به صورت پویا
// قرار دارند. کارساز این نشانی‌ها را از این استخر مستثنی کرده
// و آن‌ها را تنها به کلاینتی که رزروی برای آن‌ها دارد اختصاص می‌دهد.
"reservations": [
// این یک رزرو میزبان ساده است. میزبانی با DUID منطبق بر
// مقدار مشخص‌شده، نشانی 2001:db8:1::100 را دریافت خواهد کرد.
{
"duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
"ip-addresses": [ "2001:db8:1::100" ]
},
// این مورد مشابه مورد قبلی است، اما این بار رزرو بر اساس
// نشانی سخت‌افزاری/MAC انجام می‌شود. کارساز نهایت تلاش خود را برای
// استخراج نشانی سخت‌افزاری/MAC از بسته‌های دریافتی انجام می‌دهد (برای جزئیات
// به دستورالعمل 'mac-sources' مراجعه کنید). این رزرو خاص همچنین دو گزینه
// اضافی را برای ارائه به این کلاینت مشخص می‌کند. در صورتی که گزینه‌هایی
// با همان کد در دامنه سراسری، زیرشبکه یا کلاس مشخص شده باشند، مقادیر
// تعریف‌شده در سطح میزبان اولویت دارند.
{
"hw-address": "00:01:02:03:04:05",
"ip-addresses": [ "2001:db8:1::101" ],
"option-data": [
{
"name": "dns-servers",
"data": "3000:1::234"
},
{
"name": "nis-servers",
"data": "3000:1::234"
} ],
"client-classes": [ "special_snowflake", "office" ]
},
// این یک رزرو تا حدی پیشرفته‌تر است. کلاینت با DUID مشخص‌شده
// یک نشانی رزروشده، یک پیشوند رزروشده و یک نام میزبان دریافت خواهد کرد.
// این رزرو برای نشانی‌ای است که در استخر پویا قرار ندارد.
// در نهایت، این رزرو شامل گزینه‌های خاص فروشنده برای CableLabs است که
// از enterprise-id 4491 استفاده می‌کند. این مقادیر خاص تنها
// به کلاینتی تحویل داده می‌شوند که DUID آن با این رزرو مطابقت داشته باشد.
{
"duid": "01:02:03:04:05:06:07:08:09:0A",
"ip-addresses": [ "2001:db8:1:cafe::1" ],
"prefixes": [ "2001:db8:2:abcd::/64" ],
"hostname": "foo.example.com",
"option-data": [ {
"name": "vendor-opts",
"data": "4491"
},
{
"name": "tftp-servers",
"space": "vendor-4491",
"data": "3000:1::234"
} ]
},
// این رزرو از شناسه انعطاف‌پذیر استفاده می‌کند. به جای اتکا به یک فیلد
// خاص، مدیر سیستم می‌تواند عبارتی شبیه به آنچه در رده‌بندی کلاینت‌ها استفاده می‌شود
// تعریف کند؛ مانند:
// substring(relay[0].option[17],0,6). سپس بر اساس مقدار آن
// عبارت برای بسته دریافتی، رزرو مطابقت داده می‌شود.
// عبارت می‌تواند به صورت هگزادسیمال یا به صورت متن ساده با استفاده از
// علامت‌های نقل‌قول تکی مشخص شود.
// نکته: شناسه انعطاف‌پذیر برای کار کردن نیاز به بارگذاری
// کتابخانه قلاب flex_id دارد.
{
"flex-id": "'somevalue'",
"ip-addresses": [ "2001:db8:1:cafe::2" ]
}
]
}
],
// بخش زیر وقایع‌نگاری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در
// خروجی استاندارد (stdout) ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این یک سناریوی پایه با چهار زیرشبکه IPv6 پیکربندی‌شده است. در هر
// زیرشبکه، یک استخر کوچک‌تر از نشانی‌های پویا وجود دارد.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// باید پایگاه‌داده مورد استفاده برای ذخیره اجاره‌ها مشخص شود. تا
// ژوئن ۲۰۲۲، از سه پسانه پایگاه‌داده پشتیبانی می‌شود: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد چون نیازی به راه‌اندازی اولیه ندارد.
"lease-database": {
"type": "memfile"
},
// نشانی‌ها با طول‌عمرهای ترجیحی و معتبر به ترتیب با مقادیر 3000 و
// 4000 اختصاص داده می‌شوند. به کلاینت گفته می‌شود که تمدید را
// پس از 1000 ثانیه آغاز کند. اگر کارساز پس از 2000 ثانیه از زمان
// اعطای اجاره پاسخی نداد، کلاینت باید فرایند REBIND (تمدید اضطراری
// که امکان تغییر به کارساز دیگری را می‌دهد) را آغاز کند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه دست‌کم از مدخل‌های
// subnet و pool تشکیل شده است.
"subnet6": [
{ "pools": [ { "pool": "2001:db8:1::/80" } ],
"id": 1, "subnet": "2001:db8:1::/64" },
{ "pools": [ { "pool": "2001:db8:2::/80" } ],
"id": 2, "subnet": "2001:db8:2::/64" },
{ "pools": [ { "pool": "2001:db8:3::/80" } ],
"id": 3, "subnet": "2001:db8:3::/64" },
{ "pools": [ { "pool": "2001:db8:4::/80" } ],
"id": 4, "subnet": "2001:db8:4::/64" } ],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. در نظر می‌گیرد که پیام‌هایی با
// دست‌کم سطح اطلاعاتی (info، warn، error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
168u
kea6/shared-network.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارساز DHCPv6 در Kea است.
// این نمونه یک قابلیت پیشرفته به نام شبکه اشتراکی (shared network) را نشان می‌دهد.
// معمولاً برای هر پیوند فیزیکی، یک زیرشبکه IPv6 وجود دارد که انتظار می‌رود کارساز
// آن را مدیریت کند. با این حال، در برخی موارد نیاز است که زیرشبکه‌های بیشتری در همان
// موقعیت فیزیکی پیکربندی شوند. این ممکن است عجیب به نظر برسد، زیرا انتظار نمی‌رود
// آدرس‌های IPv6 تمام شوند. با این حال، به دلیل فضای آدرس‌دهی وسیع، برخی پیاده‌سازی‌ها
// طرح‌های آدرس‌دهی گوناگون را می‌آزمایند و بعداً متوجه می‌شوند که طرح اولیه بهترین نبوده
// و راهی برای مهاجرت به طرحی دیگر لازم است.
{
"Dhcp6": {
// به Kea گفته شده است که تنها روی رابط eth0 شنود کند.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// همچنین باید مشخص کنید که اطلاعات اجاره در کجا ذخیره شود.
// memfile پسانه‌ای است که راه‌اندازی آن از همه ساده‌تر است.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// به احتمال زیاد در شبکه خود ترکیبی از زیرشبکه‌های عادی («ساده»)
// و شبکه‌های اشتراکی خواهید داشت. ترکیب کردن آن‌ها در همان فایل
// پیکربندی کاملاً مجاز است.
// این یک زیرشبکه عادی است و بخشی از هیچ shared-network ای نیست.
"subnet6": [
{
"id": 1,
"pools": [ { "pool": "2001:db8:2::/80" } ],
"subnet": "2001:db8:2::/64",
"interface": "eth0"
}
],
// تعریف شبکه‌های اشتراکی از اینجا آغاز می‌شود. shared-networks می‌تواند
// شامل فهرستی از شبکه‌های اشتراکی باشد. پارامترهای متعددی وجود دارد
// که می‌توان در اینجا مشخص کرد، بنابراین این مثال ممکن است در ابتدا پیچیده
// به نظر برسد، اما تنها پارامتر اجباری برای هر شبکه اشتراکی name است.
// این نام باید یکتا باشد. معمولاً هر شبکه اشتراکی برای کارکردن نیاز به
// دست‌کم دو زیرشبکه دارد، اما اگر واقعاً بخواهید، می‌توانید یک شبکه اشتراکی
// تقلیل‌یافته با ۱ یا حتی ۰ زیرشبکه تعریف کنید. این قابلیت می‌تواند هنگام مهاجرت
// میان زیرشبکه‌های عادی و شبکه‌های اشتراکی یا هنگام اشکال‌زدایی یک مشکل
// مفید باشد. استفاده از ۱ زیرشبکه برای هر شبکه اشتراکی توصیه نمی‌شود، زیرا
// بار پردازشی اضافه برای شبکه‌های اشتراکی وجود دارد.
"shared-networks": [
{
"interface": "eth1",
// همانند زیرشبکه‌های عادی، تعریف هم‌زمان interface و interface-id
// ممنوع است. این به این دلیل است که پارامتر interface رابط شبکه فیزیکی
// را برای پیوندهای محلی در دسترس نشان می‌دهد و interface-id مقادیر درج‌شده
// توسط رله‌ها (relays) را مشخص می‌کند که فقط برای ترافیک دوردست استفاده
// می‌شوند. یک شبکه اشتراکی نمی‌تواند هم مستقیم و هم رله‌شده باشد.
// "interface-id": "content of the option",
// سایر پارامترهای تعریف‌شده در اینجا توسط زیرشبکه‌ها
// به ارث برده می‌شوند.
"name": "frog",
"option-data": [ ],
"preferred-lifetime": 200,
"rapid-commit": true,
"rebind-timer": 150,
"relay": {
"ip-addresses": [ "2001:db8::1" ]
},
"renew-timer": 100,
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را بررسی کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون‌زیرشبکه‌ای را بررسی کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام نشانی‌های رزروشده
// خارج از استخر (out-of-pool) هستند یا خیر.
// در صورتی که reservations-in-subnet نادرست (false) باشد نادیده گرفته می‌شود.
// در صورت تعیین، در سطوح "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
// فهرست زیرشبکه‌های متعلق به این shared-network خاص
// از اینجا آغاز می‌شود.
"subnet6": [
// این زیرشبکه نخست است.
{
"preferred-lifetime": 30,
"rapid-commit": false,
"rebind-timer": 20,
// بازنویسی برخی از مقادیر در اینجا امکان‌پذیر است.
"relay": {
"ip-addresses": [ "2001:db8:1::123" ]
},
"renew-timer": 10,
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را بررسی کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون‌زیرشبکه‌ای را بررسی کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام نشانی‌های رزروشده
// خارج از استخر (out-of-pool) هستند یا خیر.
// در صورتی که reservations-in-subnet نادرست (false) باشد نادیده گرفته می‌شود.
// در صورت تعیین، در سطوح "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
"id": 2,
"subnet": "2001:db8:1::/64",
"pools": [ { "pool": "2001:db8:1:0:abcd::/80" } ],
"valid-lifetime": 40
},
// این زیرشبکه دوم است.
{
"preferred-lifetime": 30,
"pools": [ { "pool": "3000:db8::/64" } ],
"rapid-commit": false,
"rebind-timer": 20,
"relay": {
"ip-addresses": [ "3000::1" ]
},
"renew-timer": 10,
// مشخص می‌کند که آیا کارساز باید رزروهای سراسری را بررسی کند یا خیر.
"reservations-global": false,
// مشخص می‌کند که آیا کارساز باید رزروهای درون‌زیرشبکه‌ای را بررسی کند یا خیر.
"reservations-in-subnet": true,
// مشخص می‌کند که آیا کارساز می‌تواند فرض کند تمام نشانی‌های رزروشده
// خارج از استخر (out-of-pool) هستند یا خیر.
// در صورتی که reservations-in-subnet نادرست (false) باشد نادیده گرفته می‌شود.
// در صورت تعیین، در سطوح "subnet6" به ارث برده می‌شود.
"reservations-out-of-pool": false,
"id": 3,
"subnet": "3000::/16",
"valid-lifetime": 40
}
],
"valid-lifetime": 300
} ]
}
}
168u
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea است.
// این یک سناریوی پایه‌ای با یک زیرشبکهٔ IPv6 پیکربندی‌شده است. فرض
// بر این است که یک زیرشبکه (2001:db8:1::/64) مستقیماً روی
// رابط eth0 در دسترس است.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه‌داده مورد استفاده برای ذخیرهٔ اجاره‌ها را مشخص کنیم. تا
// ژوئن 2022، سه پس‌بند پایگاه‌داده پشتیبانی می‌شوند: MySQL،
// PostgreSQL و پایگاه‌داده درون‌حافظه‌ای Memfile.
// ما از memfile استفاده خواهیم کرد زیرا به هیچ راه‌اندازی اولیه‌ای نیاز ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// نشانی‌ها به ترتیب با طول‌عمرهای ترجیحی و معتبر 3000 و 4000 تخصیص
// داده می‌شوند. به کلاینت گفته می‌شود که تجدید اجاره را پس از 1000 ثانیه
// آغاز کند. اگر کارگزار پس از 2000 ثانیه از زمان اعطای اجاره پاسخ نداد،
// کلاینت باید روال REBIND (تجدید اضطراری که امکان جابه‌جایی به کارگزار
// دیگری را فراهم می‌سازد) را آغاز نماید.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// مدخل‌های subnet و pool است.
"subnet6": [
{
"id": 1,
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// بخش زیر ثبت وقایع را پیکربندی می‌کند. فرض بر این است که پیام‌هایی با
// حداقل سطح اطلاعاتی (info، warn، error و fatal) باید در stdout ثبت
// شوند. در غیر این صورت، می‌توانید در اینجا stderr، نام یک فایل یا
// 'syslog' را مشخص کنید که پیام‌های خروجی را از طریق syslog ذخیره می‌کند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
168u
kea6/softwire46.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea است.
// این فایل نشان می‌دهد کاربر چگونه می‌تواند مقادیر گزینه‌های Softwire
// تعریف‌شده در RFC 7598 را برای معماری Lightweight 4over6 مشخص کند.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// بیایید از پس‌بند Memfile برای ذخیرهٔ اجاره‌ها استفاده کنیم.
"lease-database": {
"type": "memfile"
},
// نشانی‌ها به ترتیب با طول‌عمرهای ترجیحی و معتبر 3000 و 4000 تخصیص
// داده می‌شوند. به کلاینت گفته می‌شود که تجدید اجاره را پس از 1000 ثانیه
// آغاز کند. اگر کارگزار پس از 2000 ثانیه از زمان اعطای اجاره پاسخ نداد،
// کلاینت باید روال REBIND (تجدید اضطراری که امکان جابه‌جایی به کارگزار
// دیگری را فراهم می‌سازد) را آغاز نماید.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// مدخل‌های subnet و pool است.
"subnet6": [
{
"id": 1,
"pools": [ { "pool": "2001:db8:1::/80" } ],
"subnet": "2001:db8:1::/64",
"interface": "eth0",
// گزینه MAP-E Container را برای میزبان‌های متصل به این زیرشبکه بگنجانید.
"option-data": [
{
"name": "s46-cont-mape"
}
],
// ارسال گزینه‌های softwire مخصوص میزبان.
"reservations": [
{
"duid": "01:02:03:04:05:06:07:08:09:0A",
"option-data": [
// این دو گزینه در MAP-E Container گنجانده خواهند شد
{
"space": "s46-cont-mape-options",
"name": "s46-rule",
"data": "1, 0, 24, 192.0.2.0, 2001:db8:1::/64"
},
{
"space": "s46-cont-mape-options",
"name": "s46-br",
"data": "2001:db8:cafe::1"
},
// این گزینه در گزینه S46 Rule گنجانده خواهد شد. این گزینه شامل
// مقدار PSID/طول PSID در قالبی کاربرپسند است. طول PSID تعداد
// بیت‌هایی را مشخص می‌کند که PSID روی آن‌ها کدگذاری می‌شود. مقدار
// PSID برابر 3 چهارمین مقداری است که روی این 4 بیت کدگذاری شده است: "0011b".
{
"space": "s46-rule-options",
"name": "s46-portparams",
"data": "0, 3/4"
}
]
}
]
}
],
// بخش زیر ثبت وقایع را پیکربندی می‌کند. Kea همهٔ پیام‌های اشکال‌زدایی
// را در فایل /var/log/kea/kea-debug.log ثبت خواهد کرد.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "/var/log/kea/kea-debug.log"
}
],
"debuglevel": 99,
"severity": "DEBUG"
}
]
}
}
168u
0.0
3.5
// یک پیکربندی بی‌وضعیت (stateless) بسیار ساده که اطلاعات کارگزارهای DNS را
// بدون در نظر گرفتن نقطه اتصال، در اختیار همه کلاینت‌ها قرار می‌دهد.
//
// همچنین می‌توان گزینه‌ها را بر مبنای هر زیرشبکه، دقیقاً به همان روش
// حالت باوضعیت (stateful) مشخص کرد.
//
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// این فهرست گزینه‌هایی است که به تمام کلاینت‌های متقاضی اعطا خواهد شد.
"option-data": [ {
"name": "dns-servers",
"data": "2001:db8::1, 2001:db8::2"
} ],
// در Kea 0.9.1 تعیین lease-database اجباری است، حتی اگر استفاده نشود.
// در حالت بی‌وضعیت، تنها گزینه‌ها اعطا می‌شوند، نه نشانی‌ها یا
// پیشوندها؛ بنابراین هیچ اجاره‌ای وجود نخواهد داشت (مگر اینکه حالت‌های
// بی‌وضعیت و باوضعیت هم‌زمان استفاده شوند).
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
}
}
}
168u
168u
kea6/tee-times.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea است.
// این یک سناریوی پایه‌ای با سه زیرشبکه IPv6 است که از روش‌های
// متفاوتی برای تعیین مقادیر T1 و T2 استفاده می‌کنند.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. از
// ژوئن ۲۰۲۲، از سه زیرساخت پایگاه داده پشتیبانی می‌شود: MySQL،
// PostgreSQL و پایگاه داده درون‌حافظه‌ای، Memfile.
// ما از memfile استفاده خواهیم کرد زیرا نیازی به هیچ راه‌اندازی اولیه‌ای ندارد.
"lease-database": {
"type": "memfile"
},
// نشانی‌ها با طول‌عمرهای ترجیحی و معتبر تخصیص داده می‌شوند که به ترتیب
// ۳۰۰۰ و ۴۰۰۰ هستند. به طور پیش‌فرض calculate-tee-times برابر با true است
// با مقادیر .5 و .8 به ترتیب برای t1-percent و t2-percent.
// از آنجا که برخی از زیرشبکه‌های ما از مقادیر محاسبه‌شده استفاده خواهند کرد،
// نباید مقادیر سراسری را برای renew-timer و rebind-timer مشخص کنیم.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
// فهرست زیر، زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// مدخل‌های subnet و pool است.
"subnet6": [
{
// این زیرشبکه از محاسبات پیش‌فرض استفاده می‌کند
"id": 1,
"subnet": "2001:db8:1::/64",
"pools": [ { "pool": "2001:db8:1::/80" } ]
},
{
// این زیرشبکه از مقادیر صریح استفاده خواهد کرد. مقادیر
// صریح بر محاسبات اولویت دارند.
"id": 2,
"subnet": "2001:db8:2::/64",
"pools": [ { "pool": "2001:db8:2::/80" } ],
"renew-timer": 1000,
"rebind-timer": 2000
},
{
// این زیرشبکه از درصدهای سفارشی استفاده خواهد کرد
"id": 3,
"subnet": "2001:db8:3::/64",
"pools": [ { "pool": "2001:db8:3::/80" } ],
"t1-percent": .45,
"t2-percent": .7
}],
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info،‏ warn،‏ error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
168u
kea6/with-ddns.json
0.0
3.5
// این یک فایل پیکربندی نمونه برای کارگزار DHCPv6 در Kea است.
// این یک سناریوی پایه‌ای با یک زیرشبکه IPv6 پیکربندی‌شده است. فرض
// بر این است که یک زیرشبکه (2001:db8:1::/64) به طور مستقیم
// روی رابط eth0 در دسترس است.
{ "Dhcp6":
{
// به Kea گفته شده است که تنها روی رابط eth0 گوش فرا دهد.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// ما باید پایگاه داده مورد استفاده برای ذخیره اجاره‌ها را مشخص کنیم. از
// ژوئن ۲۰۲۲، از سه زیرساخت پایگاه داده پشتیبانی می‌شود: MySQL،
// PostgreSQL و پایگاه داده درون‌حافظه‌ای، Memfile.
// ما از memfile استفاده خواهیم کرد زیرا نیازی به هیچ راه‌اندازی اولیه‌ای ندارد.
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
// نشانی‌ها با طول‌عمرهای ترجیحی و معتبر تخصیص داده می‌شوند که به ترتیب
// ۳۰۰۰ و ۴۰۰۰ هستند. به کلاینت گفته می‌شود که تمدید را پس از ۱۰۰۰ ثانیه
// آغاز کند. اگر کارگزار پس از ۲۰۰۰ ثانیه از زمان اعطای اجاره پاسخی ندهد،
// کلاینت باید فرایند REBIND (تمدید اضطراری که امکان جابه‌جایی به یک کارگزار
// دیگر را فراهم می‌کند) را شروع کند.
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
// فهرست زیر، زیرشبکه‌ها را تعریف می‌کند. هر زیرشبکه حداقل شامل
// مدخل‌های subnet و pool است.
"subnet6": [
{
"pools": [ { "pool": "2001:db8:1::/80" } ],
"id": 1,
"subnet": "2001:db8:1::/64",
"interface": "eth0"
}
],
// فعال‌سازی ارتباط با kea-dhcp-ddns
// (برای به‌روزرسانی‌های پویای DNS الزامی است)
"dhcp-ddns" : {
"enable-updates" : true,
"server-ip" : "3001::1",
"server-port" : 3432,
"sender-ip" : "3001::2",
"sender-port" : 3433,
"max-queue-size" : 2048,
"ncr-protocol" : "UDP",
"ncr-format" : "JSON"
},
// فعال‌سازی به‌روزرسانی‌های DDNS و پیکربندی رفتار به‌روزرسانی DDNS
"ddns-send-updates" : true,
"ddns-override-no-update" : true,
"ddns-override-client-update" : true,
"ddns-replace-client-name" : "when-present",
"ddns-generated-prefix" : "test.prefix",
"ddns-qualifying-suffix" : "test.suffix.",
"ddns-update-on-renew" : false,
"ddns-conflict-resolution-mode": "check-with-dhcid",
"ddns-ttl-percent" : 0.75,
"hostname-char-set": "[^A-Za-z0-9.-]",
"hostname-char-replacement": "x",
// بخش زیر گزارش‌گیری را پیکربندی می‌کند. فرض بر این است که پیام‌هایی
// با حداقل سطح اطلاعاتی (info،‏ warn،‏ error و fatal) باید در
// stdout ثبت شوند.
"loggers": [
{
"name": "kea-dhcp6",
"output-options": [
{
"output": "stdout"
}
],
"debuglevel": 0,
"severity": "INFO"
}
]
}
}
168u
netconf/comments.json
0.0
3.5
// این یک نمونه پیکربندی برای Netconf است.
// این پیکربندی از کامنت‌های تعبیه‌شده (یعنی مواردی که در اشیاء پیکربندی گنجانده می‌شوند
// و در تحلیل لغوی حذف نمی‌گردند) استفاده می‌کند.
{
"Netconf":
{
// حوزه سراسری
"comment": "The Netconf Agent",
// در کارسازها
"managed-servers":
{
"dhcp4":
{
"comment": "the model is mandatory",
"model": "kea-dhcp4-server",
// در سوکت کنترلی.
"control-socket":
{
"comment": "using unix/local socket",
"socket-type": "unix",
"socket-name": "kea4-ctrl-socket"
}
}
},
// در ثبت‌کننده‌ها (loggers)
"loggers": [
{
"comment": "A logger",
"name": "kea-netconf"
}
]
}
}
168u
168u
netconf/kea-dhcp6-operations
netconf/kea-dhcp6-operations/boot.json
0.0
3.5
{
"Dhcp6": {
"control-socket": {
"socket-type": "unix",
"socket-name": "kea6-ctrl-socket"
}
}
}
168u
168u
netconf/kea-dhcp6-operations/netconf.json
0.0
3.5
{
"Netconf":
{
"managed-servers":
{
"dhcp6":
{
"control-socket":
{
"socket-type": "unix",
"socket-name": "kea6-ctrl-socket"
}
}
},
"loggers":
[
{
"name": "kea-netconf",
"output-options":
[
{
"output": "stderr"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
168u
168u
netconf/simple-dhcp4.json
0.0
3.5
// این یک پیکربندی نمونه ساده برای Netconf است که پیکربندی
// DHCPv4 را مدیریت می‌کند. این مثال تنها رابط YANG را برای
// کارساز DHCPv4 فراهم می‌کند.
{
"Netconf":
{
// سه پرچم netconf را کنترل می‌کنند (مقادیر پیش‌فرض true هستند):
// - پرچم "boot-update" در مورد بارگیری پیکربندی YANG هنگام
// راه‌اندازی netconf.
// - پرچم "subscribe-changes" در مورد اشتراک در اعلان‌ها
// هنگام تغییر ماژول YANG در حال اجرا.
// - پرچم "validate-changes" امکان اعتبارسنجی تغییرات را فراهم یا غیرفعال می‌کند.
"boot-update": true,
"subscribe-changes": true,
"validate-changes": true,
// این نگاشت نحوه مدیریت هر کارساز را مشخص می‌کند:
// مدل YANG مورد استفاده و کانال کنترلی.
"managed-servers":
{
// نحوه ارتباط Netconf با کارساز DHCPv4 به این صورت است.
"dhcp4":
{
// در نهایت، kea-netconf قادر به مدیریت چندین مدل خواهد بود.
// با این حال، در حال حاضر تنها انتخاب برای کارساز DHCPv4
// مدل kea-dhcp4-server است.
"model": "kea-dhcp4-server",
// این سه پرچم کنترلی می‌توانند در این حوزه نیز تعریف شوند
// و بر مقادیر سراسری و پیش‌فرض اولویت دارند.
// پرچم boot-update تعیین می‌کند که آیا پیکربندی اولیه باید در طول
// راه‌اندازی kea-netconf از netconf دریافت شود یا خیر.
// تقریباً همیشه می‌خواهید این مقدار را روی yes تنظیم کنید.
"boot-update": true,
// این پرچم کنترل می‌کند که آیا دیمن kea-netconf باید در هرگونه
// تغییراتی مشترک شود یا خیر. در صورت تنظیم روی true، دیمن kea-netconf
// ابزار sysrepo را زیر نظر گرفته و هر تغییری را که از طریق کلاینت‌های
// netconf یا sysrepocfg ایجاد شود اعمال می‌کند.
"subscribe-changes": true,
// این پارامتر مشخص می‌کند که آیا kea-netconf تلاش خواهد کرد تا صحت
// پیکربندی آتی NETCONF را اعتبارسنجی کند یا خیر. این اعتبارسنجی
// با فراخوانی config-test انجام می‌شود. بسته به پاسخ Kea،
// پیکربندی جدید پذیرفته یا رد می‌شود.
"validate-changes": false,
// در حال حاضر سه نوع کانال کنترلی پشتیبانی می‌شوند:
// - مقدار "stdout" که پیکربندی را در خروجی استاندارد چاپ می‌کند
// (این حالت عمدتاً برای اهداف آزمایشی است، اما می‌توانید از یک اسکریپت
// ساده مانند curl یا socat برای انتقال آن اطلاعات به کارساز استفاده کنید).
// - مقدار "unix" که از کانال کنترلی محلی پشتیبانی‌شده توسط کارسازهای
// "dhcp4" و "dhcp6" استفاده می‌کند (پشتیبانی از "d2" در نسخه Kea 1.5 ارائه خواهد شد).
// - مقدار "http" (هنوز پشتیبانی نمی‌شود؟).
"control-socket":
{
"socket-type": "unix",
"socket-name": "kea4-ctrl-socket"
},
// نوشتن یادداشت اختیاری است. می‌توانید یادداشت‌های خود را در اینجا قرار دهید.
"comment": "Kea DHCPv4 server serving network on floor 13"
}
},
// ابزار Netconf قادر است کتابخانه‌های قلاب (hook) را برای گسترش عملکرد خود بارگیری کند.
// کارکرد اصلی آن امکان افزودن دستورهای جدید است.
// برای بارگیری یک کتابخانه قلاب، این بخش را از حالت کامنت خارج کنید.
// "hooks-libraries": [
// // فهرست کتابخانه‌های قلاب می‌تواند حاوی بیش از یک کتابخانه باشد.
// {
// // تنها پارامتر ضروری نام فایل کتابخانه است.
// "library": "netconf-commands.so",
// // برخی کتابخانه‌ها ممکن است از پارامترها پشتیبانی کنند. دقت کنید
// // که این بخش را با دقت بنویسید، زیرا کارساز آن را اعتبارسنجی
// // نمی‌کند (چون قالب آن مختص به همان کتابخانه است).
// "parameters": {
// "param1": "foo"
// }
// }
// ]
// همانند سایر مؤلفه‌های Kea، ابزار Netconf نیز از ثبت وقایع استفاده می‌کند.
"loggers": [
{
"name": "kea-netconf",
"output-options": [
{
// "output": "/var/log/kea/kea-netconf.log",
"output": "stdout",
// علاوه بر خروجی معمول، چندین پارامتر دیگر نیز امکان‌پذیر است.
// پارامتر flush مشخص می‌کند که آیا ثبت‌کننده، خروجی را بلافاصله
// در فایل تخلیه کند یا خیر. پارامتر maxsize حداکثر حجم فایل
// را پیش از چرخش فایل مشخص می‌کند. پارامتر maxver حداکثر
// تعداد فایل‌های چرخیده‌شده‌ای را که نگهداری می‌شوند مشخص
// می‌کند.
"flush": true,
"maxsize": 204800,
"maxver": 4,
// از pattern برای مشخص کردن چیدمان سفارشی پیام‌های وقایع استفاده می‌کنیم
"pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// می‌توانید شدت وقایع (severity) را به DEBUG،‏ INFO،‏ WARN،‏ ERROR یا
// CRIT تغییر دهید. برای سطح DEBUG، می‌توانید مقدار debuglevel
// را نیز مشخص کنید (۰-۹۹، مقدار بیشتر = گزارش مفصل‌تر). تمام پیکربندی‌ها
// در سطح DEBUG/55 ثبت می‌شوند.
"severity": "INFO",
"debuglevel": 0
}
]
}
}
168u
0.0
3.5
// این یک مثال ساده از پیکربندی برای Netconf است که پیکربندی
// DHCPv6 را مدیریت می‌کند. این مثال تنها رابط YANG را برای
// سرور DHCPv6 فراهم می‌کند.
{
"Netconf":
{
// سه پرچم، netconf را کنترل می‌کنند (مقادیر پیش‌فرض true هستند):
// - "boot-update" درباره بارگذاری پیکربندی YANG هنگام
// راه‌اندازی netconf.
// - "subscribe-changes" درباره اشتراک در اعلان‌ها هنگام
// تغییر ماژول در حال اجرای YANG.
// - "validate-changes" امکان اعتبارسنجی یا عدم اعتبارسنجی تغییرات را فراهم می‌کند.
"boot-update": true,
"subscribe-changes": true,
"validate-changes": true,
// این نگاشت نحوه مدیریت هر سرور را مشخص می‌کند:
// مدل YANG مورد استفاده و کانال کنترلی.
"managed-servers":
{
// روش برقراری ارتباط Netconf با سرور DHCPv6 به این صورت است.
"dhcp6":
{
// در نهایت kea-netconf قادر به مدیریت چندین مدل خواهد بود.
// با این حال، در حال حاضر گزینه‌های موجود برای سرور
// DHCPv6 مدل‌های kea-dhcp6-server و
// ietf-dhcpv6-server هستند، اما فقط اولی قابل استفاده است.
"model": "kea-dhcp6-server",
// این سه پرچم کنترلی می‌توانند در این محدوده نیز تعریف شوند
// و بر مقادیر سراسری و پیش‌فرض اولویت دارند.
// پرچم boot-update تعیین می‌کند که آیا پیکربندی اولیه باید
// هنگام راه‌اندازی kea-netconf از netconf بازیابی شود یا خیر.
// تقریباً همیشه می‌خواهید این مقدار را روی yes تنظیم کنید.
"boot-update": true,
// این پرچم کنترل می‌کند که آیا دیمن kea-netconf باید در هرگونه
// تغییری مشترک شود یا خیر. اگر روی true تنظیم شود، kea-netconf
// مخزن sysrepo را زیر نظر می‌گیرد و هر تغییری را که چه توسط کلاینت‌های
// netconf و چه توسط sysrepocfg اعمال شود، دریافت خواهد کرد.
"subscribe-changes": true,
// این پارامتر مشخص می‌کند که آیا kea-netconf تلاش خواهد کرد تا صحت
// پیکربندی NETCONF پیش‌رو را بررسی کند یا خیر. اعتبارسنجی با
// فراخوانی config-test انجام می‌شود. بسته به پاسخ Kea،
// پیکربندی جدید پذیرفته یا رد می‌شود.
"validate-changes": false,
// در حال حاضر سه نوع کانال کنترلی پشتیبانی می‌شود:
// - "stdout" که پیکربندی را در خروجی استاندارد می‌نویسد (این حالت
// عمدتاً برای اهداف آزمایشی است، اما می‌توانید از اسکریپتی ساده
// (مانند curl یا socat) برای ارسال آن اطلاعات به سرور استفاده کنید.
// - "unix" که از کانال کنترلی محلی پشتیبانی‌شده توسط
// سرورهای "dhcp4" و "dhcp6" استفاده می‌کند (پشتیبانی از "d2" در Kea 1.5 ارائه می‌شود)
// - "http" (هنوز پشتیبانی نمی‌شود؟).
"control-socket":
{
"socket-type": "unix",
"socket-name": "kea6-ctrl-socket"
},
// کامنت اختیاری است. می‌توانید یادداشت‌هایی را اینجا بنویسید.
"comment": "Kea DHCPv6 server serving network on floor 13"
}
},
// ابزار Netconf قادر به بارگذاری کتابخانه‌های قلاب (hook) است که عملکرد آن را گسترش می‌دهند.
// کارکرد اصلی، قابلیت افزودن دستورهای جدید است.
// برای بارگذاری یک کتابخانه قلاب، این بخش را از حالت توضیح خارج کنید.
// "hooks-libraries": [
// // فهرست کتابخانه‌های قلاب می‌تواند شامل بیش از یک کتابخانه باشد.
// {
// // تنها پارامتر لازم، نام فایل کتابخانه است.
// "library": "netconf-commands.so",
// // برخی کتابخانه‌ها ممکن است از پارامترها پشتیبانی کنند. دقت کنید
// // که این بخش را با احتیاط تایپ کنید، زیرا سرور آن را اعتبارسنجی نمی‌کند
// // (چون قالب آن مختص به هر کتابخانه است).
// "parameters": {
// "param1": "foo"
// }
// }
// ]
// مشابه سایر مؤلفه‌های Kea، ابزار Netconf نیز از سیستم ثبت وقایع استفاده می‌کند.
"loggers": [
{
"name": "kea-netconf",
"output-options": [
{
// "output": "/var/log/kea/kea-netconf.log",
"output": "stdout",
// علاوه بر خروجی معمول، چندین پارامتر اضافی دیگر نیز امکان‌پذیر است.
// Flush تعیین می‌کند که آیا ثبت‌کننده خروجی را در فایل تخلیه (flush)
// می‌کند یا خیر. Maxsize حداکثر اندازه فایل را پیش از چرخش (rotation)
// مشخص می‌کند. maxver حداکثر تعداد فایل‌های چرخیده نگهداری‌شده
// را مشخص می‌کند.
"flush": true,
"maxsize": 204800,
"maxver": 4,
// ما از pattern برای مشخص کردن الگوی سفارشی پیام گزارش استفاده می‌کنیم
"pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
}
],
// می‌توانید شدت (severity) را به DEBUG،‏ INFO،‏ WARN،‏ ERROR یا
// CRIT تغییر دهید. برای سطح DEBUG، می‌توانید علاوه بر این debuglevel
// را نیز مشخص کنید (0-99، مقدار بالاتر = با جزئیات بیشتر). تمام پیکربندی‌ها
// در DEBUG/55 ثبت می‌شوند.
"severity": "INFO",
"debuglevel": 0
}
]
}
}
168u
بخش‌های زیر شامل قالب‌های پیکربندی برای انواع خاصی از استقرار هستند. فایل‌های پیکربندی نمونه در سورس‌کد Kea، در دایرکتوری doc/examples نیز در دسترس هستند.
"قالب: شبکه خانگی یک کاربر حرفه‌ای (Template: Home Network of a Power User)"
در ادامه قالب‌هایی برای کمک به پیکربندی شبکه خانگی یک کاربر حرفه‌ای آورده شده است؛ این قالب‌ها همچنین ممکن است برای یک دفتر کار کوچک مناسب باشند. این قالب‌ها فرضیات زیر را در نظر می‌گیرند:
0.0
• 2
مدیر سیستم می‌خواهد از یک کلاس /24 منفرد از آدرس‌های IPv4 استفاده کند.
• 2
قابلیت دسترسی‌پذیری بالا (HA) مورد نیاز است، بنابراین دو سرور DHCP وجود دارد.
• 2
تعداد انگشت‌شماری دستگاه وجود دارد و برخی از آن‌ها (مانند یک چاپگر یا NAS) به آدرس‌های ایستا یا گزینه‌های اضافی نیاز دارند.
• 2
مدیر سیستم نمی‌خواهد درگیر مدیریت پایگاه‌داده شود.
• 2
راه‌اندازی برای حداقل نگهداری تا بدون نیاز به نگهداری بهینه‌سازی شده است.
• 2
عملکرد و کارایی مسئله‌ای نیست؛ صدها پرس‌وجو در ثانیه مورد انتظار نیست.
• 2
از IPv6 استفاده نمی‌شود.
• 2
به‌روزرسانی‌های DNS توسط Kea انجام نخواهد شد.
168u
راه‌اندازی منطقی شامل دو میزبان است که هر کدام یک سرور Kea DHCPv4 را اجرا می‌کنند. هر سرور به‌عنوان یک شریک از جفت HA عمل می‌کند.
0.0
3.5
+-host-1-+ +-host-2-+
| | | |
| DHCPv4 ========= DHCPv4 | ===== - HTTP connection
| | | |
+--------+ +--------+
168u
168u
سرورهای روی host-1 و host-2 هر دو به پورت 8000 گوش می‌دهند.
"ملاحظات استقرار (Deployment Considerations)"
انتظار نمی‌رود این راه‌اندازی کارایی بسیار بالایی داشته باشد. بیشتر سخت‌افزارهای معمولی کافی خواهند بود؛ برای مثال Kea با موفقیت روی پلتفرم‌های Raspberry Pi مستقر شده است. اگر روی یک ماشین مجازی (VM) اجرا می‌شود، ۲ گیگابایت رم با یک هسته CPU باید کافی باشد. اوبونتو LTS انتخابی است که راه‌اندازی آن آسان و نگهداری آن اندک است؛ با این حال، هر سیستم‌عامل لینوکس یا FreeBSD مناسب است. سیستم‌های کم‌تر محبوب، مانند OpenBSD یا NetBSD نیز در اصل باید کار کنند، اما به‌طور منظم آزمایش نمی‌شوند.
در این مثال، دو میزبان در حال اجرای Kea وجود دارند:
0.0
• 2
192.168.1.2 - سرور اصلی HA (فعال، تمام ترافیک را مدیریت می‌کند)
• 2
192.168.1.3 - سرور ثانویه HA (غیرفعال، آماده برای تحویل گرفتن وظایف در صورت خرابی سرور اصلی)
168u
شبکه 192.168.1.0/24 است. فرض بر این است که 192.168.1.1 روتر پیش‌فرض است.
کل زیرشبکه به استخرهای پویا و ایستا تقسیم شده است:
0.0
• 2
192.168.1.100 - 192.168.1.199 - این استخر پویا است. هنگامی که دستگاه‌های جدید در شبکه ظاهر می‌شوند، آدرس‌های پویا از این استخر به آن‌ها اختصاص می‌یابد.
• 2
رزروها خارج از این محدوده پویا انجام می‌شوند (بسته به ترجیح آدرس‌دهی، 192.168.1.1-192.168.1.99 یا 192.168.1.200-192.168.1.254).
168u
برای استقرار این راه‌اندازی، مراحل زیر را انجام دهید:
0.0
1. 3
سرور DHCPv4 را روی host-1 نصب کنید و فایل پیکربندی را در مکان‌های معمول آن کپی نمایید. این مسیر معمولاً در لینوکس /etc/kea و در FreeBSD برابر /usr/local/etc/kea است، و فایل به‌طور معمول kea-dhcp4.conf نام دارد. لطفاً برای هر سیستم خاص به اسکریپت‌های راه‌اندازی رجوع کنید.
2. 3
موارد زیر را برای مطابقت با راه‌اندازی محلی تغییر دهید:
3.0
• 2
نام رابطی که Kea باید روی آن گوش دهد (interfaces در interfaces-config).
• 2
نام رابطی که برای دسترسی به زیرشبکه استفاده می‌شود (interface در subnet4).
• 2
آدرس‌دهی، در صورتی که از چیزی غیر از 192.168.1.0/24 استفاده می‌کنید. مطمئن شوید که پیکربندی آدرس و پورت کنترلی (socket-address و socket-port) با پیکربندی HA (url در hook-libraries/parameters/high-availability/peers) مطابقت دارد.
• 2
گزینه روتر، برای مطابقت با شبکه واقعی.
• 2
گزینه DNS، برای مطابقت با شبکه واقعی.
168u
3. 3
اگر از فایروال استفاده می‌کنید، مطمئن شوید که host-1 می‌تواند به host-2 دسترسی داشته باشد. یک راه آسان برای اطمینان از این موضوع، تلاش برای دریافت پیکربندی host-2 از host-1 است:
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://192.168.1.3:8000/
پیکربندی در حال اجرای DHCPv4 باید در قالب JSON بازگردانده شود.
4. 3
با تکرار مرحله ۳ از host-2 با استفاده از آدرس IP و پورت مربوط به host-1، بررسی کنید که ارتباط بین میزبان‌ها در جهت معکوس نیز کار می‌کند (host-2 می‌تواند به host-1 متصل شود).
5. 3
سرور DHCPv4 را طبق مراحل ۱ و ۲ روی host-2 نصب کنید. فایل پیکربندی سرور آماده‌به‌خدمت بسیار شبیه به فایل سرور اصلی است، به‌جز تعریف فیلد this-server-name (و احتمالاً نام‌های رابط).
168u
"توسعه‌های احتمالی (Possible Extensions)"
این پیکربندی نمونه پایه‌ای اما کاربردی است. پس از راه‌اندازی و اجرا، مدیران سیستم ممکن است مایل باشند تغییرات زیر را مد نظر قرار دهند:
0.0
• 2
اگر یک سرور DNS محلی وجود دارد، به‌روزرسانی‌های DNS را می‌توان از طریق Kea پیکربندی کرد. این کار نیازمند اجرای یک سرور به‌روزرسانی DHCP-DDNS (kea-dhcp-ddns) است. برای جزئیات به Overview <#dhcp-ddns-overview> مراجعه کنید.
• 2
برای اجرای DHCP با حفظ وضعیت (Stateful) برای IPv6، یک سرور kea-dhcp6 لازم است. پیکربندی آن بسیار شبیه به kea-dhcp4 است، اما تفاوت‌های قابل توجهی وجود دارد: دروازه پیش‌فرض از طریق پروتکل DHCPv6 پیکربندی نمی‌شود، بلکه از طریق اعلان‌های روتر ارسال‌شده توسط روتر محلی تنظیم می‌شود. همچنین مفهوم تفویض پیشوند در DHCPv6، در DHCPv4 وجود ندارد. برای جزئیات به The DHCPv6 Server <#dhcp6> مراجعه کنید.
• 2
برای گسترش شبکه محلی، افزودن پایگاه‌داده MySQL یا PostgreSQL یک راهکار محبوب است. کاربران می‌توانند اجاره‌ها، رزروهای میزبان و حتی بخش عمده‌ای از پیکربندی را در پایگاه‌داده ذخیره کنند. به Kea Database Administration <#admin> و پارامترهای lease-database، hosts-database و config-control در The DHCPv4 Server <#dhcp4> مراجعه کنید.
• 2
برای ارائه بینش بیشتر در مورد نحوه عملکرد سرور DHCP، واسط برنامه‌نویسی RESTful در Kea می‌تواند بسیاری از آمار زمان اجرا را پرس‌وجو کند یا حتی پیکربندی را در حین زمان اجرا تغییر دهد. کاربران همچنین می‌توانند استقرار Stork را که یک داشبورد با توسعه سریع برای Kea است، مد نظر قرار دهند. برای اطلاعات بیشتر به Monitoring Kea With Stork <#stork> مراجعه کنید.
• 2
همه کاربران Kea باید Kea Security <#security>: را بخوانند تا با مصالحه‌های مختلف بین راحتی استفاده و امنیت در Kea آشنا شوند.
168u
ممکن است مقداری تنظیم این قالب‌ها برای مطابقت با نیازهای خاص سیستم ضروری باشد: حداقل، خطوط برجسته شده با رنگ زرد باید برای مطابقت با استقرار واقعی تنظیم شوند.
فایل پیکربندی DHCPv4 برای Server1:
0.0
3.5
// This is an example configuration of the Kea DHCPv4 server 1:
//
// - uses High Availability hook library and Lease Commands hook library
// to enable High Availability function for the DHCP server. This config
// file is for the primary (the active) server.
// - uses memfile, which stores lease data in a local CSV file
// - it assumes a single /24 addressing over a link that is directly reachable
// (no DHCP relays)
// - there is a handful of IP reservations
//
// It is expected to run with a standby (the passive) server, which has a very similar
// configuration. The only difference is that "this-server-name" must be set to "server2" on the
// other server. Also, the interface configuration depends on the network settings of the
// particular machine.
{
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// The DHCPv4 server listens on this interface. When changing this to
// the actual name of your interface, make sure to also update the
// interface parameter in the subnet definition below.
"interfaces": [ "enp0s8" ]
},
// Control socket is required for communication with the
// DHCP server. High Availability requires HTTP/HTTPS control sockets
// to be configured because lease updates are sent over the RESTful
// API between the HA peers.
"control-socket": {
"socket-type": "http",
// We need to specify where the agent should listen to incoming HTTP
// queries.
"socket-address": "192.168.1.2",
// This specifies the port the server will listen on.
"socket-port": 8000
},
// Use Memfile lease database backend to store leases in a CSV file.
// Depending on how Kea was compiled, it may also support SQL databases
// (MySQL and/or PostgreSQL). Those database backends require more
// parameters, like name, host and possibly user and password.
// There are dedicated examples for each backend. See Section 7.2.2 "Lease
// Storage" for details.
"lease-database": {
// Memfile is the simplest and easiest backend to use. It's an in-memory
// database with data being written to a CSV file. It is very similar to
// what ISC DHCP does.
"type": "memfile"
},
// Let's configure some global parameters. The home network is not very dynamic
// and there's no shortage of addresses, so no need to recycle aggressively.
"valid-lifetime": 43200, // leases will be valid for 12h
"renew-timer": 21600, // clients should renew every 6h
"rebind-timer": 32400, // clients should start looking for other servers after 9h
// Kea will clean up its database of expired leases once per hour. However, it
// will keep the leases in expired state for 2 days. This greatly increases the
// chances for returning devices to get the same address again. To guarantee that,
// use host reservation.
// If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are
// not 0, when the client sends a release message the lease is expired
// instead of being deleted from lease storage.
"expired-leases-processing": {
"reclaim-timer-wait-time": 3600,
"hold-reclaimed-time": 172800,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
},
// Multi-threading parameters.
"multi-threading": {
// By default, Kea processes packets on multiple threads if the hardware
// permits. This example uses single-threaded configuration.
"enable-multi-threading": false,
// When multi-threading is enabled, Kea will process packets on a
// number of multiple threads configurable through this option. The
// value must be a positive integer (0 means auto-detect).
"thread-pool-size": 0,
// When multi-threading is enabled, Kea will read packets from the
// interface and append a working item to the thread pool. This
// option configures the maximum number of items that can be queued.
// The value must be a positive integer (0 means unlimited).
"packet-queue-size": 0
},
// HA requires two hook libraries to be loaded: libdhcp_lease_cmds.so and
// libdhcp_ha.so. The former handles incoming lease updates from the HA peers.
// The latter implements high availability feature for Kea. Note the library name
// should be the same, but the path is OS specific.
"hooks-libraries": [
// The lease_cmds library must be loaded because HA makes use of it to
// deliver lease updates to the server as well as synchronize the
// lease database after failure.
{
"library": "libdhcp_lease_cmds.so"
},
{
// The HA hook library should be loaded.
"library": "libdhcp_ha.so",
"parameters": {
// Each server should have the same HA configuration, except for the
// "this-server-name" parameter.
"high-availability": [ {
// This parameter points to this server instance. The respective
// HA peers must have this parameter set to their own names.
"this-server-name": "server1",
// The HA mode is set to hot-standby. In this mode, the active server handles
// all the traffic. The standby takes over if the primary becomes unavailable.
"mode": "hot-standby",
// Heartbeat is to be sent every 10 seconds if no other control
// commands are transmitted.
"heartbeat-delay": 10000,
// Maximum time for partner's response to a heartbeat, after which
// failure detection is started. This is specified in milliseconds.
// If we don't hear from the partner in 60 seconds, it's time to
// start worrying.
"max-response-delay": 60000,
// The following parameters control how the server detects the
// partner's failure. The ACK delay sets the threshold for the
// 'secs' field of the received discovers. This is specified in
// milliseconds.
"max-ack-delay": 5000,
// This specifies the number of clients which send messages to
// the partner but appear to not receive any response.
"max-unacked-clients": 5,
// This specifies the maximum timeout (in milliseconds) for the server
// to complete sync. If you have a large deployment (high tens or
// hundreds of thousands of clients), you may need to increase it
// further. The default value is 60000ms (60 seconds).
"sync-timeout": 60000,
// Multi-threading parameters.
"multi-threading": {
// By default, Kea processes packets on multiple threads if the hardware
// permits. This example uses single-threaded configuration.
"enable-multi-threading": false,
"http-dedicated-listener": false,
"http-listener-threads": 0,
"http-client-threads": 0
},
"peers": [
// This is the configuration of this server instance.
{
"name": "server1",
// This specifies the URL of this server instance.
// The "control-socket" is needed for the High Availability
// with single-threading, and the "socket-address" and
// "socket-port" must be set to the corresponding values.
"url": "http://192.168.1.2:8000/",
// This server is primary. The other one must be
// secondary.
"role": "primary"
},
// This is the configuration of the secondary server.
{
"name": "server2",
// Specifies the URL on which the partner's control
// channel can be reached.
// The "control-socket" is needed for the High Availability
// with single-threading, and the "socket-address" and
// "socket-port" must be set to the corresponding values.
"url": "http://192.168.1.3:8000/",
// The other server is secondary. This one must be
// primary.
"role": "standby"
}
]
} ]
}
}
],
// This example contains a single subnet declaration.
"subnet4": [
{
// Subnet prefix.
"subnet": "192.168.1.0/24",
// There are no relays in this network, so we need to tell Kea that this subnet
// is reachable directly via the specified interface.
"interface": "enp0s8",
// Specify a dynamic address pool.
"pools": [
{
"pool": "192.168.1.100-192.168.1.199"
}
],
// These are options that are subnet specific. In most cases, you need to define at
// least routers option, as without this option your clients will not be able to reach
// their default gateway and will not have Internet connectivity. If you have many
// subnets and they share the same options (e.g. DNS servers typically is the same
// everywhere), you may define options at the global scope, so you don't repeat them
// for every network.
"option-data": [
{
// For each IPv4 subnet you typically need to specify at least one router.
"name": "routers",
"data": "192.168.1.1"
},
{
// Using cloudflare or Quad9 is a reasonable option. Change this
// to your own DNS servers is you have them. Another popular
// choice is 8.8.8.8, owned by Google. Using third party DNS
// service raises some privacy concerns.
"name": "domain-name-servers",
"data": "1.1.1.1,9.9.9.9"
}
],
// Some devices should get a static address. Since the .100 - .199 range is dynamic,
// let's use the lower address space for this. There are many ways how reservation
// can be defined, but using MAC address (hw-address) is by far the most popular one.
// You can use client-id, duid and even custom defined flex-id that may use whatever
// parts of the packet you want to use as identifiers. Also, there are many more things
// you can specify in addition to just an IP address: extra options, next-server, hostname,
// assign device to client classes etc. See the Kea ARM, Section 8.3 for details.
// The reservations are subnet specific.
"reservations": [
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"ip-address": "192.168.1.10"
},
{
"client-id": "01:11:22:33:44:55:66",
"ip-address": "192.168.1.11"
}
]
}
],
// Logging configuration starts here.
"loggers": [
{
// This section affects kea-dhcp4, which is the base logger for DHCPv4 component. It tells
// DHCPv4 server to write all log messages (on severity INFO or higher) to a file. The file
// will be rotated once it grows to 2MB and up to 4 files will be kept. The debuglevel
// (range 0 to 99) is used only when logging on DEBUG level.
"name": "kea-dhcp4",
"output-options": [
{
"output": "/var/log/kea/kea-dhcp4.log",
"maxsize": 2048000,
"maxver": 4
}
],
"severity": "INFO",
"debuglevel": 0
}
]
}
}
168u
168u
فایل پیکربندی DHCPv4 برای Server2:
0.0
3.5
// This is an example configuration of the Kea DHCPv4 server 2:
//
// - uses High Availability hook library and Lease Commands hook library
// to enable High Availability function for the DHCP server. This config
// file is for the primary (the active) server.
// - uses memfile, which stores lease data in a local CSV file
// - it assumes a single /24 addressing over a link that is directly reachable
// (no DHCP relays)
// - there is a handful of IP reservations
//
// It is expected to run with a primary (the active) server, which has a very similar
// configuration. The only difference is that "this-server-name" must be set to "server2" on the
// other server. Also, the interface configuration depends on the network settings of the
// particular machine.
{
"Dhcp4": {
// Add names of your network interfaces to listen on.
"interfaces-config": {
// The DHCPv4 server listens on this interface. When changing this to
// the actual name of your interface, make sure to also update the
// interface parameter in the subnet definition below.
"interfaces": [ "enp0s8" ]
},
// Control socket is required for communication with the
// DHCP server. High Availability requires HTTP/HTTPS control sockets
// to be configured because lease updates are sent over the RESTful
// API between the HA peers.
"control-socket": {
"socket-type": "http",
// We need to specify where the agent should listen to incoming HTTP
// queries.
"socket-address": "192.168.1.3",
// This specifies the port the server will listen on.
"socket-port": 8000
},
// Use Memfile lease database backend to store leases in a CSV file.
// Depending on how Kea was compiled, it may also support SQL databases
// (MySQL and/or PostgreSQL). Those database backends require more
// parameters, like name, host and possibly user and password.
// There are dedicated examples for each backend. See Section 7.2.2 "Lease
// Storage" for details.
"lease-database": {
// Memfile is the simplest and easiest backend to use. It's an in-memory
// database with data being written to a CSV file. It is very similar to
// what ISC DHCP does.
"type": "memfile"
},
// Let's configure some global parameters. The home network is not very dynamic
// and there's no shortage of addresses, so no need to recycle aggressively.
"valid-lifetime": 43200, // leases will be valid for 12h
"renew-timer": 21600, // clients should renew every 6h
"rebind-timer": 32400, // clients should start looking for other servers after 9h
// Kea will clean up its database of expired leases once per hour. However, it
// will keep the leases in expired state for 2 days. This greatly increases the
// chances for returning devices to get the same address again. To guarantee that,
// use host reservation.
// If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are
// not 0, when the client sends a release message the lease is expired
// instead of being deleted from lease storage.
"expired-leases-processing": {
"reclaim-timer-wait-time": 3600,
"hold-reclaimed-time": 172800,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
},
// Multi-threading parameters.
"multi-threading": {
// By default, Kea processes packets on multiple threads if the hardware
// permits. This example uses single-threaded configuration.
"enable-multi-threading": false,
// When multi-threading is enabled, Kea will process packets on a
// number of multiple threads configurable through this option. The
// value must be a positive integer (0 means auto-detect).
"thread-pool-size": 0,
// When multi-threading is enabled, Kea will read packets from the
// interface and append a working item to the thread pool. This
// option configures the maximum number of items that can be queued.
// The value must be a positive integer (0 means unlimited).
"packet-queue-size": 0
},
// HA requires two hook libraries to be loaded: libdhcp_lease_cmds.so and
// libdhcp_ha.so. The former handles incoming lease updates from the HA peers.
// The latter implements high availability feature for Kea. Note the library name
// should be the same, but the path is OS specific.
"hooks-libraries": [
// The lease_cmds library must be loaded because HA makes use of it to
// deliver lease updates to the server as well as synchronize the
// lease database after failure.
{
"library": "libdhcp_lease_cmds.so"
},
{
// The HA hook library should be loaded.
"library": "libdhcp_ha.so",
"parameters": {
// Each server should have the same HA configuration, except for the
// "this-server-name" parameter.
"high-availability": [ {
// This parameter points to this server instance. The respective
// HA peers must have this parameter set to their own names.
"this-server-name": "server2",
// The HA mode is set to hot-standby. In this mode, the active server handles
// all the traffic. The standby takes over if the primary becomes unavailable.
"mode": "hot-standby",
// Heartbeat is to be sent every 10 seconds if no other control
// commands are transmitted.
"heartbeat-delay": 10000,
// Maximum time for partner's response to a heartbeat, after which
// failure detection is started. This is specified in milliseconds.
// If we don't hear from the partner in 60 seconds, it's time to
// start worrying.
"max-response-delay": 60000,
// The following parameters control how the server detects the
// partner's failure. The ACK delay sets the threshold for the
// 'secs' field of the received discovers. This is specified in
// milliseconds.
"max-ack-delay": 5000,
// This specifies the number of clients which send messages to
// the partner but appear to not receive any response.
"max-unacked-clients": 5,
// This specifies the maximum timeout (in milliseconds) for the server
// to complete sync. If you have a large deployment (high tens or
// hundreds of thousands of clients), you may need to increase it
// further. The default value is 60000ms (60 seconds).
"sync-timeout": 60000,
// Multi-threading parameters.
"multi-threading": {
// By default, Kea processes packets on multiple threads if the hardware
// permits. This example uses single-threaded configuration.
"enable-multi-threading": false,
"http-dedicated-listener": false,
"http-listener-threads": 0,
"http-client-threads": 0
},
"peers": [
// This is the configuration of the primary server.
{
"name": "server1",
// Specifies the URL on which the partner's control
// channel can be reached.
// The "control-socket" is needed for the High Availability
// with single-threading, and the "socket-address" and
// "socket-port" must be set to the corresponding values.
"url": "http://192.168.1.2:8000/",
// The other server is primary. This one must be
// secondary.
"role": "primary"
},
// This is the configuration of this server instance.
{
"name": "server2",
// This specifies the URL of this server instance.
// The "control-socket" is needed for the High Availability
// with single-threading, and the "socket-address" and
// "socket-port" must be set to the corresponding values.
"url": "http://192.168.1.3:8000/",
// This server is secondary. The other one must be
// primary.
"role": "standby"
}
]
} ]
}
}
],
// This example contains a single subnet declaration.
"subnet4": [
{
// Subnet prefix.
"subnet": "192.168.1.0/24",
// There are no relays in this network, so we need to tell Kea that this subnet
// is reachable directly via the specified interface.
"interface": "enp0s8",
// Specify a dynamic address pool.
"pools": [
{
"pool": "192.168.1.100-192.168.1.199"
}
],
// These are options that are subnet specific. In most cases, you need to define at
// least routers option, as without this option your clients will not be able to reach
// their default gateway and will not have Internet connectivity. If you have many
// subnets and they share the same options (e.g. DNS servers typically is the same
// everywhere), you may define options at the global scope, so you don't repeat them
// for every network.
"option-data": [
{
// For each IPv4 subnet you typically need to specify at least one router.
"name": "routers",
"data": "192.168.1.1"
},
{
// Using cloudflare or Quad9 is a reasonable option. Change this
// to your own DNS servers is you have them. Another popular
// choice is 8.8.8.8, owned by Google. Using third party DNS
// service raises some privacy concerns.
"name": "domain-name-servers",
"data": "1.1.1.1,9.9.9.9"
}
],
// Some devices should get a static address. Since the .100 - .199 range is dynamic,
// let's use the lower address space for this. There are many ways how reservation
// can be defined, but using MAC address (hw-address) is by far the most popular one.
// You can use client-id, duid and even custom defined flex-id that may use whatever
// parts of the packet you want to use as identifiers. Also, there are many more things
// you can specify in addition to just an IP address: extra options, next-server, hostname,
// assign device to client classes etc. See the Kea ARM, Section 8.3 for details.
// The reservations are subnet specific.
"reservations": [
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"ip-address": "192.168.1.10"
},
{
"client-id": "01:11:22:33:44:55:66",
"ip-address": "192.168.1.11"
}
]
}
],
// Logging configuration starts here.
"loggers": [
{
// This section affects kea-dhcp4, which is the base logger for DHCPv4 component. It tells
// DHCPv4 server to write all log messages (on severity INFO or higher) to a file. The file
// will be rotated once it grows to 2MB and up to 4 files will be kept. The debuglevel
// (range 0 to 99) is used only when logging on DEBUG level.
"name": "kea-dhcp4",
"output-options": [
{
"output": "/var/log/kea/kea-dhcp4.log",
"maxsize": 2048000,
"maxver": 4
}
],
"severity": "INFO",
"debuglevel": 0
}
]
}
}
168u
در زیر الگوهایی برای کمک به پیکربندی یک سرور امن Kea DHCP به همراه چندریسمانی (multi-threading) آورده شده است. این الگوها مفروضات زیر را در نظر می‌گیرند:
0.0
• 2
مدیر سیستم می‌خواهد قابلیت دسترسی‌پذیری بالا (HA) را با چندریسمانی (multi-threading) راه‌اندازی کند.
• 2
ماشین‌های اجراکننده Kea با چندریسمانی دست‌کم چهار هسته پردازنده (CPU) دارند.
• 2
ارتباط با کارگزار همتا (peer) با استفاده از TLS امن شده است.
168u
ساختار منطقی شامل دو میزبان است که هرکدام یک سرور Kea DHCPv4 را اجرا می‌کنند.
در ساختار چندریسمانی، سوکت‌های کنترلی الزامی نیستند، زیرا سرور از شنونده HTTP
اختصاصی خود برای برقراری ارتباط با همتا استفاده می‌کند. با این حال، هنوز می‌توان از
سوکت‌های کنترلی HTTPS برای رسیدگی به دستورات کاربر استفاده کرد.
0.0
3.5
+-host-1-+ +-host-2-+
| | | |
| DHCPv4 ========= DHCPv4 | ===== - اتصال HTTPS
| | | |
+--------+ +--------+
168u
168u
سرورها روی host-1 و host-2 هر دو روی درگاه 8001 گوش می‌دهند، و شنونده اختصاصی HTTP سرور
از درگاه 8000 استفاده می‌کند. سرورهای DHCP از طریق این شنونده اختصاصی HTTP با یکدیگر
ارتباط برقرار می‌کنند که فقط دستورات به‌روزرسانی اجاره (lease-update) را به سرور همتا ارسال می‌کند.
ملاحظات استقرار (Deployment Considerations)
انتظار نمی‌رود این ساختار به طور خودکار مقیاس‌پذیر شود. این مثال از چهار ریسمان (thread) برای
پردازش ترافیک DHCP، چهار ریسمان برای گوش دادن و مدیریت درخواست‌های HTTP همتای HA،
و چهار ریسمان برای ارسال به‌روزرسانی‌های اجاره به همتای HA استفاده می‌کند. صف ریسمان مورد استفاده برای
ذخیره درخواست‌های دریافتی DHCP روی 64 تنظیم شده است، اما برای تعیین مقادیر مناسب جهت دستیابی به
بهترین کارایی در ساختار استقرار، آزمایش‌ها و محک‌زنی‌های (benchmarks) دقیق لازم است.
در این مثال، دو میزبان وجود دارند که Kea را اجرا می‌کنند:
0.0
• 2
192.168.1.2 - سرور اصلی HA (فعال/active، تمام ترافیک را مدیریت می‌کند)
• 2
192.168.1.3 - سرور ثانویه HA (غیرفعال/passive، آماده برای در دست گرفتن کنترل در صورت خرابی سرور اصلی)
168u
شبکه 192.168.1.0/24 است. فرض می‌شود که 192.168.1.1 مسیریاب پیش‌فرض (default router) است.
کل زیرشبکه به استخرهای پویا (dynamic pools) تقسیم شده است:
0.0
• 2
192.168.1.100 - 192.168.1.199 - این استخر پویا است. هنگامی که دستگاه‌های جدید در شبکه ظاهر می‌شوند،
نشانی‌های پویایی از این استخر به آن‌ها تخصیص می‌یابد.
168u
برای استقرار این ساختار، مراحل ارائه‌شده در بخش راه‌اندازی خانگی کاربر پیشرفته را با تمایزهای زیر دنبال کنید:
0.0
1. 3
موارد زیر را متناسب با پیکربندی محلی تغییر دهید:
3.0
• 2
مسیرهای trust-anchor، cert-file و key-file باید روی مقادیر متناظر
با ماشین استقرار تنظیم شوند.
• 2
در صورت استفاده از شبکه‌ای غیر از 192.168.1.0/24، آدرس‌دهی باید به‌روزرسانی شود.
اطمینان حاصل کنید که پیکربندی نشانی و درگاه سوکت کنترلی
(socket-address و socket-port) با پیکربندی HA
(url در hook-libraries/parameters/high-availability/peers) متفاوت باشد.
سوکت کنترلی HTTP فقط برای مدیریت دستورات مدیریتی به کار می‌رود،
زیرا ماژول HA به‌روزرسانی‌های اجاره را با استفاده از شنونده اختصاصی HTTP به همتا ارسال می‌کند.
168u
2. 3
با بررسی لاگ‌های Kea، ارتباط بین همتاهای HA را راستی‌آزمایی کنید.
3. 3
با تکرار مرحله ۳ از مبدا host-2 با استفاده از نشانی IP و درگاه host-1، بررسی کنید که
ارتباط بین میزبان‌ها در جهت معکوس نیز کار می‌کند (host-2 بتواند به host-1 متصل شود).
4. 3
نرم‌افزار DHCPv4 را همانند مراحل ۱ و ۲ روی host-2 نصب کنید. فایل پیکربندی سرور
آماده‌به‌کار (standby) به‌جز تعریف فیلد this-server-name (و احتمالاً نام رابط‌های شبکه)،
بسیار شبیه به فایل سرور اصلی است.
168u
توسعه‌های احتمالی (Possible Extensions)
این پیکربندی نمونه ساده اما کاربردی است. پس از راه‌اندازی و اجرا، ممکن است مدیران سیستم
بخواهند تغییرات زیر را در نظر بگیرند:
0.0
• 2
در صورت استفاده از پایگاه‌داده، امکان پیکربندی TLS برای backend پایگاه‌داده نیز وجود دارد (برای
اجاره، میزبان، بک‌اند پیکربندی یا لاگ‌گیری جرم‌یابی). برای اطلاعات بیشتر بخش اتصال پایگاه‌داده <#database-connectivity>
را ببینید.
168u
ممکن است برای تطبیق این الگوها با نیازهای خاص سیستم، به مقداری تنظیم نیاز باشد:
دست‌کم، خطوط برجسته‌شده باید متناسب با استقرار واقعی تنظیم شوند.
فایل پیکربندی DHCPv4 برای Server1:
0.0
3.5
// این یک پیکربندی نمونه برای سرور ۱ Kea DHCPv4 است:
//
// - برای فعال کردن قابلیت دسترسی‌پذیری بالا (HA) در سرور DHCP، از کتابخانه‌های قلاب
// High Availability و Lease Commands استفاده می‌کند. این فایل پیکربندی
// برای سرور اصلی (فعال/active) است.
// - از memfile استفاده می‌کند که اطلاعات اجاره را در یک فایل CSV محلی ذخیره می‌نماید
// - فرض را بر یک آدرس‌دهی تک /24 روی پیوندی می‌گذارد که مستقیماً در دسترس است
// (بدون رله‌های DHCP)
// - شامل تعداد اندکی رزرو IP است
//
// انتظار می‌رود این سرور در کنار یک سرور آماده‌به‌کار (غیرفعال/passive) که پیکربندی بسیار مشابهی
// دارد اجرا شود. تنها تفاوت این است که "this-server-name" در سرور دیگر باید روی "server2"
// تنظیم شود. همچنین پیکربندی رابط و مکان فایل‌های مربوط به TLS به تنظیمات شبکه
// و پیکربندی آن ماشین خاص بستگی دارد.
{
"Dhcp4": {
// نام‌های رابط‌های شبکه خود را برای گوش دادن اضافه کنید.
"interfaces-config": {
// سرور DHCPv4 روی این رابط گوش می‌دهد. در صورت تغییر این مقدار به
// نام واقعی رابط خود، حتماً پارامتر interface را در تعریف زیرشبکه در زیر
// نیز به‌روزرسانی کنید.
"interfaces": [ "enp0s8" ]
},
// سوکت کنترلی برای برقراری ارتباط با سرور DHCP الزامی است.
// دسترسی‌پذیری بالا (HA) به پیکربندی سوکت‌های کنترلی HTTP/HTTPS نیاز دارد
// زیرا به‌روزرسانی‌های اجاره از طریق RESTful API بین همتاهای HA
// ارسال می‌شوند.
"control-socket": {
"socket-type": "https",
// باید مشخص کنیم که سرور در کجا باید به پرس‌وجوهای ورودی HTTP
// گوش دهد.
"socket-address": "192.168.1.2",
// این درگاهی را مشخص می‌کند که سرور روی آن گوش خواهد داد.
// در صورت فعال‌سازی HA و چندریسمانی، درگاه 8000 توسط شنونده http
// کتابخانه قلاب HA استفاده می‌شود. هنگام استفاده از کتابخانه قلاب HA با
// چندریسمانی، اطمینان حاصل کنید که درگاه استفاده‌شده توسط شنونده اختصاصی
// با درگاه سرور متفاوت باشد (مثلاً 8001). توجه داشته باشید که دستورات
// همچنان باید به سوکت کنترلی ارسال شوند.
// شنونده اختصاصی صرفاً برای به‌روزرسانی‌های HA است.
"socket-port": 8001,
// لنگر اعتماد TLS (مرجع صدور گواهی یا CA). این یک نام فایل یا
// (فقط برای OpenSSL) مسیر دایرکتوری است.
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی سرور TLS.
"cert-file": "/usr/lib/kea/ca1_cert.pem",
// نام فایل کلید خصوصی سرور TLS.
"key-file": "/usr/lib/kea/ca1_key.pem",
// پرچم الزام گواهی‌های کلاینت در TLS.
"cert-required": true
},
// پارامترهای چندریسمانی (Multi-threading).
"multi-threading": {
// به طور پیش‌فرض، در صورتی که سخت‌افزار اجازه دهد، Kea بسته‌ها را روی چندین ریسمان پردازش می‌کند.
"enable-multi-threading": true,
// هنگامی که چندریسمانی فعال باشد، Kea بسته‌ها را روی تعدادی ریسمان
// که از طریق این گزینه قابل پیکربندی است پردازش می‌کند.
// مقدار باید یک عدد صحیح مثبت باشد (0 یعنی تشخیص خودکار).
"thread-pool-size": 4,
// هنگامی که چندریسمانی فعال باشد، Kea بسته‌ها را از رابط می‌خواند
// و یک مورد کاری به استخر ریسمان‌ها می‌افزاید. این گزینه حداکثر
// تعداد مواردی را که می‌توانند صف‌بندی شوند پیکربندی می‌کند.
// مقدار باید یک عدد صحیح مثبت باشد (0 یعنی نامحدود).
"packet-queue-size": 64
},
// از بک‌اند پایگاه‌داده اجاره Memfile برای ذخیره اجاره‌ها در یک فایل CSV استفاده کنید.
// بسته به نحوه کامپایل شدن Kea، ممکن است از پایگاه‌های داده SQL
// (مانند MySQL و/یا PostgreSQL) نیز پشتیبانی کند. آن بک‌اندهای پایگاه‌داده نیازمند
// پارامترهای بیشتری مانند name ،host و احتمالاً user و password هستند.
// مثال‌های اختصاصی برای هر بک‌اند وجود دارد. برای جزئیات به بخش 7.2.2 "Lease
// Storage" مراجعه کنید.
"lease-database": {
// بک‌اند Memfile ساده‌ترین بک‌اند برای استفاده است. این یک پایگاه‌داده درون‌حافظه‌ای
// با قابلیت نوشتن داده‌ها در یک فایل CSV است. این رفتار بسیار شبیه به
// عملکرد ISC DHCP است.
"type": "memfile"
},
// بیایید چند پارامتر عمومی را پیکربندی کنیم. شبکه خانگی خیلی پویا نیست
// و کمبود نشانی وجود ندارد، بنابراین نیازی به بازیافت تهاجمی نیست.
"valid-lifetime": 43200, // اجاره‌ها به مدت ۱۲ ساعت معتبر خواهند بود
"renew-timer": 21600, // کلاینت‌ها باید هر ۶ ساعت تمدید کنند
"rebind-timer": 32400, // کلاینت‌ها پس از ۹ ساعت باید جستجو برای سرورهای دیگر را آغاز کنند
// نرم‌افزار Kea پایگاه‌داده اجاره‌های منقضی‌شده خود را یک بار در ساعت پاکسازی می‌کند.
// با این حال، اجاره‌ها را به مدت ۲ روز در وضعیت منقضی نگه می‌دارد. این کار شانس
// دریافت مجدد همان نشانی را توسط دستگاه‌های بازگشتی بسیار افزایش می‌دهد. برای ضمانت آن،
// از رزرو میزبان استفاده کنید.
// اگر هر دو مقدار "flush-reclaimed-timer-wait-time" و "hold-reclaimed-time"
// برابر با 0 نباشند، هنگامی که کلاینت یک پیام release ارسال می‌کند، اجاره به جای حذف
// از محل ذخیره اجاره، منقضی می‌شود.
"expired-leases-processing": {
"reclaim-timer-wait-time": 3600,
"hold-reclaimed-time": 172800,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
},
// قابلیت HA نیازمند بارگذاری دو کتابخانه قلاب است: libdhcp_lease_cmds.so و
// libdhcp_ha.so. اولی به‌روزرسانی‌های دریافتی اجاره را از همتاهای HA مدیریت می‌کند.
// دومی قابلیت دسترسی‌پذیری بالا را برای Kea پیاده‌سازی می‌کند. توجه داشته باشید که نام
// کتابخانه باید یکسان باشد، اما مسیر آن وابسته به سیستم‌عامل است.
"hooks-libraries": [
// کتابخانه lease_cmds باید بارگذاری شود زیرا HA از آن برای تحویل
// به‌روزرسانی‌های اجاره به سرور و همچنین همگام‌سازی پایگاه‌داده
// اجاره پس از خرابی استفاده می‌کند.
{
"library": "libdhcp_lease_cmds.so"
},
{
// کتابخانه قلاب HA باید بارگذاری شود.
"library": "libdhcp_ha.so",
"parameters": {
// هر سرور باید پیکربندی HA یکسانی داشته باشد، به جز
// پارامتر "this-server-name".
"high-availability": [ {
// این پارامتر به این نمونه سرور اشاره دارد. همتاهای مربوطه
// در HA باید این پارامتر را روی نام‌های خود تنظیم کنند.
"this-server-name": "server1",
// حالت HA روی hot-standby تنظیم شده است. در این حالت، سرور فعال
// تمام ترافیک را مدیریت می‌کند. در صورت عدم دسترسی سرور اصلی، سرور آماده‌به‌کار کنترل را در دست می‌گیرد.
"mode": "hot-standby",
// در صورتی که هیچ دستور کنترلی دیگری ارسال نشود، ضربان قلب
// باید هر ۱۰ ثانیه یک‌بار فرستاده شود.
"heartbeat-delay": 10000,
// حداکثر زمان برای پاسخ شریک به ضربان قلب، که پس از آن
// تشخیص خرابی آغاز می‌شود. این مقدار بر حسب میلی‌ثانیه مشخص شده است.
// اگر تا ۶۰ ثانیه پاسخی از شریک دریافت نکنیم، زمان
// نگران شدن فرا رسیده است.
"max-response-delay": 60000,
// پارامترهای زیر نحوه تشخیص خرابی شریک توسط سرور را کنترل
// می‌کنند. تاخیر ACK آستانه را برای فیلد 'secs' در discoverهای
// دریافتی تعیین می‌کند. این مقدار بر حسب میلی‌ثانیه مشخص شده است.
"max-ack-delay": 5000,
// این پارامتر تعداد کلاینت‌هایی را مشخص می‌کند که پیام‌هایی به
// شریک ارسال می‌کنند اما به نظر می‌رسد هیچ پاسخی دریافت نمی‌کنند.
"max-unacked-clients": 5,
// این پارامتر حداکثر مهلت زمانی (بر حسب میلی‌ثانیه) را برای تکمیل
// همگام‌سازی توسط سرور مشخص می‌کند. اگر استقرار بزرگی دارید (چند ده یا
// چند صد هزار کلاینت)، ممکن است نیاز به افزایش آن داشته باشید.
// مقدار پیش‌فرض 60000 میلی‌ثانیه (۶۰ ثانیه) است.
"sync-timeout": 60000,
// پارامترهای چندریسمانی.
// برای جلوگیری از افت کارایی هنگامی که سرور Kea بسته‌ها را
// روی چندین ریسمان پردازش می‌کند، ماژول دسترسی‌پذیری بالا (HA)
// باید قابلیت چندریسمانی را فعال داشته باشد.
"multi-threading": {
// فعال‌سازی دسترسی‌پذیری بالا برای بهره‌مندی از چندریسمانی. پیش‌فرض: true.
"enable-multi-threading": true,
// هنگام اجرا در حالت MT (چندریسمانی)، شنونده اختصاصی برای مدیریت
// به‌روزرسانی‌های اجاره استفاده می‌شود.
"http-dedicated-listener": true,
// تعداد ریسمان‌های مورد استفاده برای مدیریت درخواست‌های ورودی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسمانی استفاده کند
// که هسته Kea برای چندریسمانی DHCP استفاده می‌کند.
"http-listener-threads": 0,
// تعداد ریسمان‌های مورد استفاده برای مدیریت درخواست‌های خروجی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسمانی استفاده کند
// که هسته Kea برای چندریسمانی DHCP استفاده می‌کند.
"http-client-threads": 0
},
"peers": [
// این پیکربندی مربوط به این نمونه سرور است.
{
"name": "server1",
// این مقدار نشانی URL شنونده اختصاصی HTTP این سرور را مشخص می‌کند.
// مقدار "control-socket" برای دسترسی‌پذیری بالا با
// چندریسمانی الزامی نیست، اما در صورت استفاده، باید از مقادیر متفاوتی
// برای "socket-address" و "socket-port" استفاده کند.
"url": "http://192.168.1.2:8005/",
// لنگر اعتماد یا فایل/دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی کلاینت.
"cert-file": "/usr/lib/kea/server1_cert.pem",
// نام فایل کلید خصوصی.
"key-file": "/usr/lib/kea/server1_key.pem",
// گواهی‌های کلاینت الزامی بوده و اعتبارسنجی می‌شوند.
"require-client-certs": true,
// این سرور اصلی (primary) است. سرور دیگر باید
// ثانویه باشد.
"role": "primary"
},
// این پیکربندی مربوط به سرور ثانویه است.
{
"name": "server2",
// این مقدار نشانی URL شنونده اختصاصی HTTP سرور دیگر را مشخص می‌کند.
// مقدار "control-socket" برای دسترسی‌پذیری بالا با
// چندریسمانی الزامی نیست، اما در صورت استفاده، باید از مقادیر متفاوتی
// برای "socket-address" و "socket-port" استفاده کند.
"url": "http://192.168.1.3:8005/",
// لنگر اعتماد یا فایل/دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی کلاینت.
"cert-file": "/usr/lib/kea/server2_cert.pem",
// نام فایل کلید خصوصی.
"key-file": "/usr/lib/kea/server2_key.pem",
// گواهی‌های کلاینت الزامی بوده و اعتبارسنجی می‌شوند.
"require-client-certs": true,
// سرور دیگر ثانویه است. این یکی باید
// اصلی باشد.
"role": "standby"
}
]
} ]
}
}
],
// این مثال شامل تعریف یک زیرشبکه تکی است.
"subnet4": [
{
// پیشوند زیرشبکه.
"subnet": "192.168.1.0/24",
// هیچ رله‌ای در این شبکه وجود ندارد، بنابراین باید به Kea اعلام کنیم که این زیرشبکه
// مستقیماً از طریق رابط مشخص‌شده در دسترس است.
"interface": "enp0s8",
// یک استخر نشانی پویا مشخص کنید.
"pools": [
{
"pool": "192.168.1.100-192.168.1.199"
}
]
}
],
// پیکربندی لاگ‌گیری از اینجا شروع می‌شود.
"loggers": [
{
// این بخش بر kea-dhcp4 اثر می‌گذارد که لاگر پایه برای مؤلفه DHCPv4 است. این بخش به
// سرور DHCPv4 می‌گوید که تمام پیام‌های لاگ (با شدت INFO یا بالاتر) را در یک فایل بنویسد. فایل
// به محض رسیدن به اندازه 2MB چرخش داده خواهد شد و حداکثر ۴ فایل نگه داشته می‌شود. مقدار debuglevel
// (محدوده 0 تا 99) فقط هنگام لاگ‌گیری در سطح DEBUG استفاده می‌شود.
"name": "kea-dhcp4",
"output-options": [
{
"output": "/var/log/kea/kea-dhcp4.log",
"maxsize": 2048000,
"maxver": 4
}
],
"severity": "INFO",
"debuglevel": 0
}
]
}
}
168u
168u
فایل پیکربندی DHCPv4 برای Server2:
0.0
3.5
// این یک پیکربندی نمونه برای سرور ۲ Kea DHCPv4 است:
//
// - برای فعال کردن قابلیت دسترسی‌پذیری بالا (HA) در سرور DHCP، از کتابخانه‌های قلاب
// High Availability و Lease Commands استفاده می‌کند. این فایل پیکربندی
// برای سرور ثانویه (آماده‌به‌کار/standby) است.
// - از memfile استفاده می‌کند که اطلاعات اجاره را در یک فایل CSV محلی ذخیره می‌نماید
// - فرض را بر یک آدرس‌دهی تک /24 روی پیوندی می‌گذارد که مستقیماً در دسترس است
// (بدون رله‌های DHCP)
// - شامل تعداد اندکی رزرو IP است
//
// انتظار می‌رود این سرور در کنار یک سرور اصلی (فعال/active) که پیکربندی بسیار مشابهی
// دارد اجرا شود. تنها تفاوت این است که "this-server-name" در سرور دیگر باید روی "server2"
// تنظیم شود. همچنین پیکربندی رابط و مکان فایل‌های مربوط به TLS به تنظیمات شبکه
// و پیکربندی آن ماشین خاص بستگی دارد.
{
"Dhcp4": {
// نام‌های رابط‌های شبکه خود را برای گوش دادن اضافه کنید.
"interfaces-config": {
// سرور DHCPv4 روی این رابط گوش می‌دهد. در صورت تغییر این مقدار به
// نام واقعی رابط خود، حتماً پارامتر interface را در تعریف زیرشبکه در زیر
// نیز به‌روزرسانی کنید.
"interfaces": [ "enp0s8" ]
},
// سوکت کنترلی برای برقراری ارتباط با سرور DHCP الزامی است.
// دسترسی‌پذیری بالا (HA) به پیکربندی سوکت‌های کنترلی HTTP/HTTPS نیاز دارد
// زیرا به‌روزرسانی‌های اجاره از طریق RESTful API بین همتاهای HA
// ارسال می‌شوند.
"control-socket": {
"socket-type": "https",
// باید مشخص کنیم که سرور در کجا باید به پرس‌وجوهای ورودی HTTP
// گوش دهد.
"socket-address": "192.168.1.3",
// این درگاهی را مشخص می‌کند که سرور روی آن گوش خواهد داد.
// در صورت فعال‌سازی HA و چندریسمانی، درگاه 8000 توسط شنونده http
// کتابخانه قلاب HA استفاده می‌شود. هنگام استفاده از کتابخانه قلاب HA با
// چندریسمانی، اطمینان حاصل کنید که درگاه استفاده‌شده توسط شنونده اختصاصی
// با درگاه سرور متفاوت باشد (مثلاً 8001). توجه داشته باشید که دستورات
// همچنان باید به سوکت کنترلی ارسال شوند.
// شنونده اختصاصی صرفاً برای به‌روزرسانی‌های HA است.
"socket-port": 8001,
// لنگر اعتماد TLS (مرجع صدور گواهی یا CA). این یک نام فایل یا
// (فقط برای OpenSSL) مسیر دایرکتوری است.
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی سرور TLS.
"cert-file": "/usr/lib/kea/ca2_cert.pem",
// نام فایل کلید خصوصی سرور TLS.
"key-file": "/usr/lib/kea/ca2_key.pem",
// پرچم الزام گواهی‌های کلاینت در TLS.
"cert-required": true
},
// پارامترهای چندریسمانی (Multi-threading).
"multi-threading": {
// به طور پیش‌فرض، در صورتی که سخت‌افزار اجازه دهد، Kea بسته‌ها را روی چندین ریسمان پردازش می‌کند.
"enable-multi-threading": true,
// هنگامی که چندریسمانی فعال باشد، Kea بسته‌ها را روی تعدادی ریسمان
// که از طریق این گزینه قابل پیکربندی است پردازش می‌کند.
// مقدار باید یک عدد صحیح مثبت باشد (0 یعنی تشخیص خودکار).
"thread-pool-size": 4,
// هنگامی که چندریسمانی فعال باشد، Kea بسته‌ها را از رابط می‌خواند
// و یک مورد کاری به استخر ریسمان‌ها می‌افزاید. این گزینه حداکثر
// تعداد مواردی را که می‌توانند صف‌بندی شوند پیکربندی می‌کند.
// مقدار باید یک عدد صحیح مثبت باشد (0 یعنی نامحدود).
"packet-queue-size": 64
},
// از بک‌اند پایگاه‌داده اجاره Memfile برای ذخیره اجاره‌ها در یک فایل CSV استفاده کنید.
// بسته به نحوه کامپایل شدن Kea، ممکن است از پایگاه‌های داده SQL
// (مانند MySQL و/یا PostgreSQL) نیز پشتیبانی کند. آن بک‌اندهای پایگاه‌داده نیازمند
// پارامترهای بیشتری مانند name ،host و احتمالاً user و password هستند.
// مثال‌های اختصاصی برای هر بک‌اند وجود دارد. برای جزئیات به بخش 7.2.2 "Lease
// Storage" مراجعه کنید.
"lease-database": {
// بک‌اند Memfile ساده‌ترین بک‌اند برای استفاده است. این یک پایگاه‌داده درون‌حافظه‌ای
// با قابلیت نوشتن داده‌ها در یک فایل CSV است. این رفتار بسیار شبیه به
// عملکرد ISC DHCP است.
"type": "memfile"
},
// بیایید چند پارامتر عمومی را پیکربندی کنیم. شبکه خانگی خیلی پویا نیست
// و کمبود نشانی وجود ندارد، بنابراین نیازی به بازیافت تهاجمی نیست.
"valid-lifetime": 43200, // اجاره‌ها به مدت ۱۲ ساعت معتبر خواهند بود
"renew-timer": 21600, // کلاینت‌ها باید هر ۶ ساعت تمدید کنند
"rebind-timer": 32400, // کلاینت‌ها پس از ۹ ساعت باید جستجو برای سرورهای دیگر را آغاز کنند
// نرم‌افزار Kea پایگاه‌داده اجاره‌های منقضی‌شده خود را یک بار در ساعت پاکسازی می‌کند.
// با این حال، اجاره‌ها را به مدت ۲ روز در وضعیت منقضی نگه می‌دارد. این کار شانس
// دریافت مجدد همان نشانی را توسط دستگاه‌های بازگشتی بسیار افزایش می‌دهد. برای ضمانت آن،
// از رزرو میزبان استفاده کنید.
// اگر هر دو مقدار "flush-reclaimed-timer-wait-time" و "hold-reclaimed-time"
// برابر با 0 نباشند، هنگامی که کلاینت یک پیام release ارسال می‌کند، اجاره به جای حذف
// از محل ذخیره اجاره، منقضی می‌شود.
"expired-leases-processing": {
"reclaim-timer-wait-time": 3600,
"hold-reclaimed-time": 172800,
"max-reclaim-leases": 0,
"max-reclaim-time": 0
},
// قابلیت HA نیازمند بارگذاری دو کتابخانه قلاب است: libdhcp_lease_cmds.so و
// libdhcp_ha.so. اولی به‌روزرسانی‌های دریافتی اجاره را از همتاهای HA مدیریت می‌کند.
// دومی قابلیت دسترسی‌پذیری بالا را برای Kea پیاده‌سازی می‌کند. توجه داشته باشید که نام
// کتابخانه باید یکسان باشد، اما مسیر آن وابسته به سیستم‌عامل است.
"hooks-libraries": [
// کتابخانه lease_cmds باید بارگذاری شود زیرا HA از آن برای تحویل
// به‌روزرسانی‌های اجاره به سرور و همچنین همگام‌سازی پایگاه‌داده
// اجاره پس از خرابی استفاده می‌کند.
{
"library": "libdhcp_lease_cmds.so"
},
{
// کتابخانه قلاب HA باید بارگذاری شود.
"library": "libdhcp_ha.so",
"parameters": {
// هر سرور باید پیکربندی HA یکسانی داشته باشد، به جز
// پارامتر "this-server-name".
"high-availability": [ {
// این پارامتر به این نمونه سرور اشاره دارد. همتاهای مربوطه
// در HA باید این پارامتر را روی نام‌های خود تنظیم کنند.
"this-server-name": "server2",
// حالت HA روی hot-standby تنظیم شده است. در این حالت، سرور فعال
// تمام ترافیک را مدیریت می‌کند. در صورت عدم دسترسی سرور اصلی، سرور آماده‌به‌کار کنترل را در دست می‌گیرد.
"mode": "hot-standby",
// در صورتی که هیچ دستور کنترلی دیگری ارسال نشود، ضربان قلب
// باید هر ۱۰ ثانیه یک‌بار فرستاده شود.
"heartbeat-delay": 10000,
// حداکثر زمان برای پاسخ شریک به ضربان قلب، که پس از آن
// تشخیص خرابی آغاز می‌شود. این مقدار بر حسب میلی‌ثانیه مشخص شده است.
// اگر تا ۶۰ ثانیه پاسخی از شریک دریافت نکنیم، زمان
// نگران شدن فرا رسیده است.
"max-response-delay": 60000,
// پارامترهای زیر نحوه تشخیص خرابی شریک توسط سرور را کنترل
// می‌کنند. تاخیر ACK آستانه را برای فیلد 'secs' در discoverهای
// دریافتی تعیین می‌کند. این مقدار بر حسب میلی‌ثانیه مشخص شده است.
"max-ack-delay": 5000,
// این پارامتر تعداد کلاینت‌هایی را مشخص می‌کند که پیام‌هایی به
// شریک ارسال می‌کنند اما به نظر می‌رسد هیچ پاسخی دریافت نمی‌کنند.
"max-unacked-clients": 5,
// این پارامتر حداکثر مهلت زمانی (بر حسب میلی‌ثانیه) را برای تکمیل
// همگام‌سازی توسط سرور مشخص می‌کند. اگر استقرار بزرگی دارید (چند ده یا
// چند صد هزار کلاینت)، ممکن است نیاز به افزایش آن داشته باشید.
// مقدار پیش‌فرض 60000 میلی‌ثانیه (۶۰ ثانیه) است.
"sync-timeout": 60000,
// پارامترهای چندریسمانی.
// برای جلوگیری از افت کارایی هنگامی که سرور Kea بسته‌ها را
// روی چندین ریسمان پردازش می‌کند، ماژول دسترسی‌پذیری بالا (HA)
// باید قابلیت چندریسمانی را فعال داشته باشد.
"multi-threading": {
// فعال‌سازی دسترسی‌پذیری بالا برای بهره‌مندی از چندریسمانی. پیش‌فرض: true.
"enable-multi-threading": true,
// هنگام اجرا در حالت MT (چندریسمانی)، شنونده اختصاصی برای مدیریت
// به‌روزرسانی‌های اجاره استفاده می‌شود.
"http-dedicated-listener": true,
// تعداد ریسمان‌های مورد استفاده برای مدیریت درخواست‌های ورودی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسمانی استفاده کند
// که هسته Kea برای چندریسمانی DHCP استفاده می‌کند.
"http-listener-threads": 0,
// تعداد ریسمان‌های مورد استفاده برای مدیریت درخواست‌های خروجی.
// مقدار 0 به سرور دستور می‌دهد از همان تعداد ریسمانی استفاده کند
// که هسته Kea برای چندریسمانی DHCP استفاده می‌کند.
"http-client-threads": 0
},
"peers": [
// این پیکربندی مربوط به سرور اصلی است.
{
"name": "server1",
// این مقدار نشانی URL شنونده اختصاصی HTTP سرور دیگر را مشخص می‌کند.
// مقدار "control-socket" برای دسترسی‌پذیری بالا با
// چندریسمانی الزامی نیست، اما در صورت استفاده، باید از مقادیر متفاوتی
// برای "socket-address" و "socket-port" استفاده کند.
"url": "http://192.168.1.2:8005/",
// لنگر اعتماد یا فایل/دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی کلاینت.
"cert-file": "/usr/lib/kea/server1_cert.pem",
// نام فایل کلید خصوصی.
"key-file": "/usr/lib/kea/server1_key.pem",
// گواهی‌های کلاینت الزامی بوده و اعتبارسنجی می‌شوند.
"require-client-certs": true,
// سرور دیگر اصلی است. این یکی باید
// ثانویه باشد.
"role": "primary"
},
// این پیکربندی مربوط به این نمونه سرور است.
{
"name": "server2",
// این مقدار نشانی URL شنونده اختصاصی HTTP این سرور را مشخص می‌کند.
// مقدار "control-socket" برای دسترسی‌پذیری بالا با
// چندریسمانی الزامی نیست، اما در صورت استفاده، باید از مقادیر متفاوتی
// برای "socket-address" و "socket-port" استفاده کند.
"url": "http://192.168.1.3:8005/",
// لنگر اعتماد یا فایل/دایرکتوری مرجع صدور گواهی (CA).
"trust-anchor": "/usr/lib/kea/CA.pem",
// نام فایل گواهی کلاینت.
"cert-file": "/usr/lib/kea/server2_cert.pem",
// نام فایل کلید خصوصی.
"key-file": "/usr/lib/kea/server2_key.pem",
// گواهی‌های کلاینت الزامی بوده و اعتبارسنجی می‌شوند.
"require-client-certs": true,
// این سرور ثانویه است. دیگری باید
// اصلی باشد.
"role": "standby"
}
]
} ]
}
}
],
// این مثال شامل تعریف یک زیرشبکه تکی است.
"subnet4": [
{
// پیشوند زیرشبکه.
"subnet": "192.168.1.0/24",
// هیچ رله‌ای در این شبکه وجود ندارد، بنابراین باید به Kea اعلام کنیم که این زیرشبکه
// مستقیماً از طریق رابط مشخص‌شده در دسترس است.
"interface": "enp0s8",
// یک استخر نشانی پویا مشخص کنید.
"pools": [
{
"pool": "192.168.1.100-192.168.1.199"
}
]
}
],
// پیکربندی لاگ‌گیری از اینجا شروع می‌شود.
"loggers": [
{
// این بخش بر kea-dhcp4 اثر می‌گذارد که لاگر پایه برای مؤلفه DHCPv4 است. این بخش به
// سرور DHCPv4 می‌گوید که تمام پیام‌های لاگ (با شدت INFO یا بالاتر) را در یک فایل بنویسد. فایل
// به محض رسیدن به اندازه 2MB چرخش داده خواهد شد و حداکثر ۴ فایل نگه داشته می‌شود. مقدار debuglevel
// (محدوده 0 تا 99) فقط هنگام لاگ‌گیری در سطح DEBUG استفاده می‌شود.
"name": "kea-dhcp4",
"output-options": [
{
"output": "/var/log/kea/kea-dhcp4.log",
"maxsize": 2048000,
"maxver": 4
}
],
"severity": "INFO",
"debuglevel": 0
}
]
}
}
168u
این نمودارهای جریان، پیاده‌سازی سرور DHCPv4 در Kea را شرح می‌دهند و ممکن است برای مدیران سیستم مفید باشند. برای طراحی پیکربندی‌ای که منجر به دریافت نشانی‌ها و گزینه‌های مد نظر توسط کلاینت‌ها شود، درک توالی گام‌های پردازش درخواست اهمیت دارد. برای نمونه، Kea برای یافتن یک نشانی مناسب به جستجو و پیمایش می‌پردازد و نخستین نشانی دردسترس را به طور مشروط می‌پذیرد، بنابراین ترتیبی که نشانی‌ها ارزیابی می‌شوند حائز اهمیت است.
همچنین درک منطق پردازش Kea مفید است زیرا انتخاب‌های پیکربندی وجود دارند که می‌توانند فرآیند را بسیار کارآمدتر کنند. Kea بسیار انعطاف‌پذیر است، بنابراین می‌توان آن را برای موارد کاربرد بسیار گوناگون و در محیط‌های مختلف به کار برد. در محیطی که توان عملیاتی (throughput) و کارایی در اولویت هستند، مدیر سیستم می‌تواند برخی از مراحل پردازش را محدود کند. برای مثال، این امکان وجود دارد که تعداد شناسه‌های کلاینت متفاوتی را که Kea هنگام جستجو برای یک رزرو میزبان (host reservation) ارزیابی می‌کند محدود کرد، یا حتی از مرحله بررسی رزروهای میزبان صرف‌نظر نمود.
این نمودارها بر جنبه‌هایی از پردازش Kea تمرکز دارند که برای راهبران بیشترین فایده را خواهند داشت. نمودارها پردازش درخواست DHCPv4 را نشان می‌دهند، اما بیشتر این منطق به طور یکسان برای DHCPv6 نیز اعمال می‌شود. در ادامه عنوان هر نمودار، شماره نسخه Kea آمده است. رفتار Kea در طول زمان تکامل یافته است و این نمودارها رفتار سیستم را بر اساس نسخه مشخص‌شده Kea مستند می‌کنند. این نمودارها در درخت منبع Kea در قالب‌های UML (کد منبع)، PNG و SVG ارائه شده‌اند.
"حلقه اصلی (Main Loop)"
حلقه اصلی بین هر دو سرور DHCPv4 و DHCPv6 مشترک است.
0.0
2.5
[image]
حلقه اصلی سرور DHCP.UNINDENT
168u
"پردازش بسته DHCPv4 (DHCPv4 Packet Processing)"
پردازش بسته DHCPv4 نوع پیام DHCP را ارزیابی می‌کند: Discover، Request، Release، Decline یا Inform. این نمودار جریان کلی و سطح‌بالای پردازش یک بسته ورودی DHCP کلاینت را از زمان دریافت تا پاسخ سرور نشان می‌دهد.
0.0
2.5
[image]
پردازش بسته DHCPv4.UNINDENT
168u
"پردازش DHCPREQUEST (DHCPREQUEST Processing)"
نمودارهای زیر بر پردازش DHCPREQUEST تمرکز دارند. این نمودار نمایی کلی از فرآیند را ارائه می‌دهد، از انتخاب زیرشبکه گرفته تا بررسی رزروهای میزبان و ارزیابی کلاس‌های کلاینت. در نهایت، پیش از تأیید اجاره، گزینه‌ها ارزیابی شده و به پیام اضافه می‌شوند.
0.0
2.5
[image]
پردازش DHCPREQUEST.UNINDENT
168u
"انتخاب زیرشبکه DHCPv4 (DHCPv4 Subnet Selection)"
انتخاب زیرشبکه فرآیند گزینش زیرشبکه‌ای است که از نظر توپولوژی برای کلاینت مناسب باشد. هنگامی که زیرشبکه انتخاب‌شده عضوی از یک شبکه اشتراکی (shared network) باشد، کل شبکه اشتراکی انتخاب می‌شود. در حین انتخاب زیرشبکه، ممکن است کلاس کلاینت در طول پیمایش زیرشبکه‌ها بیش از یک بار بررسی شود تا مشخص گردد آیا در زیرشبکه انتخاب‌شده مجاز است یا خیر.
0.0
2.5
[image]
انتخاب زیرشبکه DHCPv4.UNINDENT
168u
"حالت خاص راه‌اندازی دوگانه در DHCPv4 (DHCPv4 Special Case of Double-Booting)"
پس از انتخاب زیرشبکه و پیش از تخصیص اجاره، سرور DHCPv4 حالت خاص کلاینت‌هایی را که با یک ایمیج ارائه‌شده توسط PXE boot یا bootp مجدداً راه‌اندازی می‌شوند مدیریت می‌کند. کادر Lease Request در ادامه بسط داده شده است.
0.0
2.5
[image]
تخصیص اجاره DHCPv4.UNINDENT
168u
"تخصیص اجاره در DHCPv4 (DHCPv4 Lease Allocation)"
نخستین نمودار زیر، جزئیات پردازش درخواست کلاینت را به تصویر می‌کشد و تمدید یک اجاره موجود، انتساب یک اجاره رزروشده و تخصیص یک اجاره رزرو‌نشده را نشان می‌دهد.
0.0
2.5
[image]
تخصیص اجاره DHCPREQUEST.UNINDENT
168u
نمودار دوم الگوریتم مورد استفاده برای اعتبارسنجی یک اجاره درخواستی یا انتخاب یک نشانی جدید جهت پیشنهاد را نشان می‌دهد. سمت راست نمودار نشان می‌دهد که چگونه یک نشانی جدید انتخاب می‌شود، هنگامی که یک اجاره جدید مورد نیاز است و کلاینت نه نشانی درخواستی دارد و نه رزرو. زمانی که یک اجاره جدید مورد نیاز است و Kea روی استخرها و زیرشبکه‌ها پیمایش می‌کند، کار خود را با زیرشبکه انتخاب‌شده در فرآیند انتخاب زیرشبکه در بالا آغاز می‌نماید.
0.0
2.5
[image]
الگوریتم requestLease4.UNINDENT
168u
نکته:
0.0
3.5
نشانی‌های ردشده (Declined) در آمار نشانی‌های تخصیص‌یافته لحاظ می‌شوند،
بنابراین معادله assigned + free = total برقرار است.
168u
168u
"وضعیت‌های اجاره (Lease States)"
این نمودار وضعیت‌های مختلف اجاره را نشان می‌دهد، از جمله وضعیت free که در آن هیچ شیء اجاره‌ای وجود ندارد.
0.0
2.5
[image]
وضعیت‌های اجاره.UNINDENT
168u
"بررسی رزروهای میزبان (Checking for Host Reservations)"
موتور تخصیص پس از انتخاب یک زیرشبکه، رزروهای میزبان را بررسی می‌کند. نمودار زیر جزئیات آن عملیات را نشان می‌دهد. انتخاب زیرشبکه بر اساس توپولوژی شبکه انجام می‌شود. رزروهای میزبان در وهله نخست برای انتساب گزینه‌ها هستند، و گزینه‌ها پس از انتخاب زیرشبکه ارزیابی می‌شوند. با این حال، اگر کلاس‌های کلاینت در رزرو میزبان اضافه شده باشند، آن‌ها نیز در یک بررسی دیگر در برابر زیرشبکه انتخاب‌شده ارزیابی می‌شوند. Kea شامل چندین گزینه برای صرف‌نظر از بررسی رزروهای میزبان است، که در صورت عدم استفاده از رزروها، می‌تواند این فرآیند را بسیار کارآمدتر کند.
نکته:
0.0
3.5
برای یافتن یک اجاره آزاد، موتور تخصیص کار خود را با ارزیابی آخرین زیرشبکه استفاده‌شده آغاز می‌کند.
زیرشبکه فعلی به تاریخچه پرس‌وجوهای قبلی بستگی دارد.
168u
168u
0.0
2.5
[image]
ارزیابی رزرو میزبان.UNINDENT
168u
"ساخت فهرست گزینه‌ها (Building the Options List)"
0.0
پیش از ارسال پاسخ، گزینه‌ها اضافه می‌شوند:
7.0
• 2
ارزیابی کلاس‌های کلاینت مورد نیاز
• 2
ساخت فهرست گزینه‌های پیکربندی‌شده
• 2
الحاق گزینه‌های درخواستی
• 2
الحاق گزینه‌های سازنده درخواستی
• 2
الحاق گزینه‌های پایه
168u
168u
0.0
2.5
[image]
الگوریتم buildCfgOptionList (ساخت فهرست گزینه‌های پیکربندی‌شده).UNINDENT
168u
0.0
2.5
[image]
الگوریتم appendRequestedOptions (الحاق گزینه‌های درخواستی).UNINDENT
168u
0.0
2.5
[image]
الگوریتم appendRequestedVendorOptions (الحاق گزینه‌های سازنده درخواستی).UNINDENT
0.0
2.5
[تصویر]
168u
168u
گردش‌های کاری RADIUS برای تخصیص اجاره
0.0
2.5
[تصویر]
168u
168u
"ساختار فایل پیکربندی KEA (KEA CONFIGURATION FILE SYNTAX (BNF))"
Kea از چندین دیمن (daemon) تشکیل شده است که هر یک ساختار پیکربندی خاص خود را دارند. بخش‌های زیر
ساختار کاملی از تمام پارامترهای ممکن را به شکل فرم باکوس-نائور (BNF) ارائه می‌دهند.
برای اطلاعات بیشتر، این مقاله ویکی‌پدیا درباره BNF به نشانی https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form را
ببینید.
گرامر BNF برای DHCPv4
این گرامر از dhcp4_parser.yy تولید شده است. برای جزئیات بیشتر بخش The DHCPv4 Server <#dhcp4> را ببینید.
0.0
3.5
Grammar
$accept ::= start EOF
start ::= TOPLEVEL_JSON sub_json
start ::= TOPLEVEL_DHCP4 syntax_map
start ::= SUB_DHCP4 sub_dhcp4
start ::= SUB_INTERFACES4 sub_interfaces4
start ::= SUB_SUBNET4 sub_subnet4
start ::= SUB_POOL4 sub_pool4
start ::= SUB_RESERVATION sub_reservation
start ::= SUB_OPTION_DEFS sub_option_def_list
start ::= SUB_OPTION_DEF sub_option_def
start ::= SUB_OPTION_DATA sub_option_data
start ::= SUB_HOOKS_LIBRARY sub_hooks_library
start ::= SUB_DHCP_DDNS sub_dhcp_ddns
start ::= SUB_CONFIG_CONTROL sub_config_control
value ::= INTEGER
| FLOAT
| BOOLEAN
| STRING
| NULL
| map2
| list_generic
sub_json ::= value
map2 ::= "{" map_content "}"
map_value ::= map2
map_content ::=
| not_empty_map
not_empty_map ::= STRING ":" value
| not_empty_map "," STRING ":" value
| not_empty_map ","
list_generic ::= "[" list_content "]"
list_content ::=
| not_empty_list
not_empty_list ::= value
| not_empty_list "," value
| not_empty_list ","
list_strings ::= "[" list_strings_content "]"
list_strings_content ::=
| not_empty_list_strings
not_empty_list_strings ::= STRING
| not_empty_list_strings "," STRING
| not_empty_list_strings ","
unknown_map_entry ::= STRING ":"
syntax_map ::= "{" global_object "}"
global_object ::= "Dhcp4" ":" "{" global_params "}"
| global_object_comma
global_object_comma ::= global_object ","
sub_dhcp4 ::= "{" global_params "}"
global_params ::= global_param
| global_params "," global_param
| global_params ","
global_param ::= valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| renew_timer
| rebind_timer
| decline_probation_period
| subnet4_list
| shared_networks
| interfaces_config
| lease_database
| hosts_database
| hosts_databases
| host_reservation_identifiers
| client_classes
| option_def_list
| option_data_list
| hooks_libraries
| expired_leases_processing
| dhcp4o6_port
| control_socket
| control_sockets
| dhcp_queue_control
| dhcp_ddns
| echo_client_id
| match_client_id
| authoritative
| next_server
| server_hostname
| boot_file_name
| user_context
| comment
| sanity_checks
| reservations
| config_control
| server_tag
| reservations_global
| reservations_in_subnet
| reservations_out_of_pool
| calculate_tee_times
| t1_percent
| t2_percent
| cache_threshold
| cache_max_age
| adaptive_lease_time_threshold
| loggers
| hostname_char_set
| hostname_char_replacement
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_use_conflict_resolution
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| store_extended_info
| statistic_default_sample_count
| statistic_default_sample_age
| dhcp_multi_threading
| early_global_reservations_lookup
| ip_reservations_unique
| reservations_lookup_first
| compatibility
| parked_packet_limit
| allocator
| offer_lifetime
| stash_agent_options
| unknown_map_entry
valid_lifetime ::= "valid-lifetime" ":" INTEGER
min_valid_lifetime ::= "min-valid-lifetime" ":" INTEGER
max_valid_lifetime ::= "max-valid-lifetime" ":" INTEGER
renew_timer ::= "renew-timer" ":" INTEGER
rebind_timer ::= "rebind-timer" ":" INTEGER
calculate_tee_times ::= "calculate-tee-times" ":" BOOLEAN
t1_percent ::= "t1-percent" ":" FLOAT
t2_percent ::= "t2-percent" ":" FLOAT
cache_threshold ::= "cache-threshold" ":" FLOAT
cache_max_age ::= "cache-max-age" ":" INTEGER
adaptive_lease_time_threshold ::= "adaptive-lease-time-threshold" ":" FLOAT
decline_probation_period ::= "decline-probation-period" ":" INTEGER
server_tag ::= "server-tag" ":" STRING
parked_packet_limit ::= "parked-packet-limit" ":" INTEGER
allocator ::= "allocator" ":" STRING
echo_client_id ::= "echo-client-id" ":" BOOLEAN
match_client_id ::= "match-client-id" ":" BOOLEAN
authoritative ::= "authoritative" ":" BOOLEAN
ddns_send_updates ::= "ddns-send-updates" ":" BOOLEAN
ddns_override_no_update ::= "ddns-override-no-update" ":" BOOLEAN
ddns_override_client_update ::= "ddns-override-client-update" ":" BOOLEAN
ddns_replace_client_name ::= "ddns-replace-client-name" ":" ddns_replace_client_name_value
ddns_replace_client_name_value ::= "when-present"
| "never"
| "always"
| "when-not-present"
| BOOLEAN
ddns_generated_prefix ::= "ddns-generated-prefix" ":" STRING
ddns_qualifying_suffix ::= "ddns-qualifying-suffix" ":" STRING
ddns_update_on_renew ::= "ddns-update-on-renew" ":" BOOLEAN
ddns_use_conflict_resolution ::= "ddns-use-conflict-resolution" ":" BOOLEAN
ddns_conflict_resolution_mode ::= "ddns-conflict-resolution-mode" ":" ddns_conflict_resolution_mode_value
ddns_conflict_resolution_mode_value ::= "check-with-dhcid"
| "no-check-with-dhcid"
| "check-exists-with-dhcid"
| "no-check-without-dhcid"
ddns_ttl_percent ::= "ddns-ttl-percent" ":" FLOAT
ddns_ttl ::= "ddns-ttl" ":" INTEGER
ddns_ttl_min ::= "ddns-ttl-min" ":" INTEGER
ddns_ttl_max ::= "ddns-ttl-max" ":" INTEGER
hostname_char_set ::= "hostname-char-set" ":" STRING
hostname_char_replacement ::= "hostname-char-replacement" ":" STRING
store_extended_info ::= "store-extended-info" ":" BOOLEAN
statistic_default_sample_count ::= "statistic-default-sample-count" ":" INTEGER
statistic_default_sample_age ::= "statistic-default-sample-age" ":" INTEGER
early_global_reservations_lookup ::= "early-global-reservations-lookup" ":" BOOLEAN
ip_reservations_unique ::= "ip-reservations-unique" ":" BOOLEAN
reservations_lookup_first ::= "reservations-lookup-first" ":" BOOLEAN
offer_lifetime ::= "offer-lifetime" ":" INTEGER
stash_agent_options ::= "stash-agent-options" ":" BOOLEAN
interfaces_config ::= "interfaces-config" ":" "{" interfaces_config_params "}"
interfaces_config_params ::= interfaces_config_param
| interfaces_config_params "," interfaces_config_param
| interfaces_config_params ","
interfaces_config_param ::= interfaces_list
| dhcp_socket_type
| outbound_interface
| re_detect
| service_sockets_require_all
| service_sockets_retry_wait_time
| service_sockets_max_retries
| user_context
| comment
| unknown_map_entry
sub_interfaces4 ::= "{" interfaces_config_params "}"
interfaces_list ::= "interfaces" ":" list_strings
dhcp_socket_type ::= "dhcp-socket-type" ":" socket_type
socket_type ::= "raw"
| "udp"
outbound_interface ::= "outbound-interface" ":" outbound_interface_value
outbound_interface_value ::= "same-as-inbound"
| "use-routing"
re_detect ::= "re-detect" ":" BOOLEAN
service_sockets_require_all ::= "service-sockets-require-all" ":" BOOLEAN
service_sockets_retry_wait_time ::= "service-sockets-retry-wait-time" ":" INTEGER
service_sockets_max_retries ::= "service-sockets-max-retries" ":" INTEGER
lease_database ::= "lease-database" ":" "{" database_map_params "}"
sanity_checks ::= "sanity-checks" ":" "{" sanity_checks_params "}"
sanity_checks_params ::= sanity_checks_param
| sanity_checks_params "," sanity_checks_param
| sanity_checks_params ","
sanity_checks_param ::= lease_checks
| extended_info_checks
lease_checks ::= "lease-checks" ":" STRING
extended_info_checks ::= "extended-info-checks" ":" STRING
hosts_database ::= "hosts-database" ":" "{" database_map_params "}"
hosts_databases ::= "hosts-databases" ":" "[" database_list "]"
database_list ::=
| not_empty_database_list
not_empty_database_list ::= database
| not_empty_database_list "," database
| not_empty_database_list ","
database ::= "{" database_map_params "}"
database_map_params ::= database_map_param
| database_map_params "," database_map_param
| database_map_params ","
database_map_param ::= database_type
| user
| password
| host
| port
| name
| persist
| lfc_interval
| readonly
| connect_timeout
| read_timeout
| write_timeout
| tcp_user_timeout
| max_reconnect_tries
| reconnect_wait_time
| on_fail
| retry_on_startup
| max_row_errors
| trust_anchor
| cert_file
| key_file
| ssl_mode
| cipher_list
| unknown_map_entry
database_type ::= "type" ":" STRING
user ::= "user" ":" STRING
password ::= "password" ":" STRING
host ::= "host" ":" STRING
port ::= "port" ":" INTEGER
name ::= "name" ":" STRING
persist ::= "persist" ":" BOOLEAN
lfc_interval ::= "lfc-interval" ":" INTEGER
readonly ::= "readonly" ":" BOOLEAN
connect_timeout ::= "connect-timeout" ":" INTEGER
read_timeout ::= "read-timeout" ":" INTEGER
write_timeout ::= "write-timeout" ":" INTEGER
tcp_user_timeout ::= "tcp-user-timeout" ":" INTEGER
max_reconnect_tries ::= "max-reconnect-tries" ":" INTEGER
reconnect_wait_time ::= "reconnect-wait-time" ":" INTEGER
on_fail ::= "on-fail" ":" on_fail_mode
on_fail_mode ::= "stop-retry-exit"
| "serve-retry-exit"
| "serve-retry-continue"
retry_on_startup ::= "retry-on-startup" ":" BOOLEAN
max_row_errors ::= "max-row-errors" ":" INTEGER
trust_anchor ::= "trust-anchor" ":" STRING
cert_file ::= "cert-file" ":" STRING
key_file ::= "key-file" ":" STRING
ssl_mode ::= "ssl-mode" ":" ssl_mode
| "disable"
| "prefer"
| "require"
| "verify-ca"
| "verify-full"
cipher_list ::= "cipher-list" ":" STRING
host_reservation_identifiers ::= "host-reservation-identifiers" ":" "[" host_reservation_identifiers_list "]"
host_reservation_identifiers_list ::= host_reservation_identifier
| host_reservation_identifiers_list "," host_reservation_identifier
| host_reservation_identifiers_list ","
host_reservation_identifier ::= duid_id
| hw_address_id
| circuit_id
| client_id
| flex_id
duid_id ::= "duid"
hw_address_id ::= "hw-address"
circuit_id ::= "circuit-id"
client_id ::= "client-id"
flex_id ::= "flex-id"
dhcp_multi_threading ::= "multi-threading" ":" "{" multi_threading_params "}"
multi_threading_params ::= multi_threading_param
| multi_threading_params "," multi_threading_param
| multi_threading_params ","
multi_threading_param ::= enable_multi_threading
| thread_pool_size
| packet_queue_size
| user_context
| comment
| unknown_map_entry
enable_multi_threading ::= "enable-multi-threading" ":" BOOLEAN
thread_pool_size ::= "thread-pool-size" ":" INTEGER
packet_queue_size ::= "packet-queue-size" ":" INTEGER
hooks_libraries ::= "hooks-libraries" ":" "[" hooks_libraries_list "]"
hooks_libraries_list ::=
| not_empty_hooks_libraries_list
not_empty_hooks_libraries_list ::= hooks_library
| not_empty_hooks_libraries_list "," hooks_library
| not_empty_hooks_libraries_list ","
hooks_library ::= "{" hooks_params "}"
sub_hooks_library ::= "{" hooks_params "}"
hooks_params ::= hooks_param
| hooks_params "," hooks_param
| hooks_params ","
| unknown_map_entry
hooks_param ::= library
| parameters
library ::= "library" ":" STRING
parameters ::= "parameters" ":" map_value
expired_leases_processing ::= "expired-leases-processing" ":" "{" expired_leases_params "}"
expired_leases_params ::= expired_leases_param
| expired_leases_params "," expired_leases_param
| expired_leases_params ","
expired_leases_param ::= reclaim_timer_wait_time
| flush_reclaimed_timer_wait_time
| hold_reclaimed_time
| max_reclaim_leases
| max_reclaim_time
| unwarned_reclaim_cycles
reclaim_timer_wait_time ::= "reclaim-timer-wait-time" ":" INTEGER
flush_reclaimed_timer_wait_time ::= "flush-reclaimed-timer-wait-time" ":" INTEGER
hold_reclaimed_time ::= "hold-reclaimed-time" ":" INTEGER
max_reclaim_leases ::= "max-reclaim-leases" ":" INTEGER
max_reclaim_time ::= "max-reclaim-time" ":" INTEGER
unwarned_reclaim_cycles ::= "unwarned-reclaim-cycles" ":" INTEGER
subnet4_list ::= "subnet4" ":" "[" subnet4_list_content "]"
subnet4_list_content ::=
| not_empty_subnet4_list
not_empty_subnet4_list ::= subnet4
| not_empty_subnet4_list "," subnet4
| not_empty_subnet4_list ","
subnet4 ::= "{" subnet4_params "}"
sub_subnet4 ::= "{" subnet4_params "}"
subnet4_params ::= subnet4_param
| subnet4_params "," subnet4_param
| subnet4_params ","
subnet4_param ::= valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| renew_timer
| rebind_timer
| option_data_list
| pools_list
| subnet
| interface
| id
| client_class
| network_client_classes
| require_client_classes
| evaluate_additional_classes
| reservations
| reservations_global
| reservations_in_subnet
| reservations_out_of_pool
| relay
| match_client_id
| authoritative
| next_server
| server_hostname
| boot_file_name
| subnet_4o6_interface
| subnet_4o6_interface_id
| subnet_4o6_subnet
| user_context
| comment
| calculate_tee_times
| t1_percent
| t2_percent
| cache_threshold
| cache_max_age
| adaptive_lease_time_threshold
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_use_conflict_resolution
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| hostname_char_set
| hostname_char_replacement
| store_extended_info
| allocator
| offer_lifetime
| unknown_map_entry
subnet ::= "subnet" ":" STRING
subnet_4o6_interface ::= "4o6-interface" ":" STRING
subnet_4o6_interface_id ::= "4o6-interface-id" ":" STRING
subnet_4o6_subnet ::= "4o6-subnet" ":" STRING
interface ::= "interface" ":" STRING
client_class ::= "client-class" ":" STRING
network_client_classes ::= "client-classes" ":" list_strings
require_client_classes ::= "require-client-classes" ":" list_strings
evaluate_additional_classes ::= "evaluate-additional-classes" ":" list_strings
reservations_global ::= "reservations-global" ":" BOOLEAN
reservations_in_subnet ::= "reservations-in-subnet" ":" BOOLEAN
reservations_out_of_pool ::= "reservations-out-of-pool" ":" BOOLEAN
id ::= "id" ":" INTEGER
shared_networks ::= "shared-networks" ":" "[" shared_networks_content "]"
shared_networks_content ::=
| shared_networks_list
shared_networks_list ::= shared_network
| shared_networks_list "," shared_network
| shared_networks_list ","
shared_network ::= "{" shared_network_params "}"
shared_network_params ::= shared_network_param
| shared_network_params "," shared_network_param
| shared_network_params ","
shared_network_param ::= name
| subnet4_list
| interface
| renew_timer
| rebind_timer
| option_data_list
| match_client_id
| authoritative
| next_server
| server_hostname
| boot_file_name
| relay
| reservations_global
| reservations_in_subnet
| reservations_out_of_pool
| client_class
| network_client_classes
| require_client_classes
| evaluate_additional_classes
| valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| user_context
| comment
| calculate_tee_times
| t1_percent
| t2_percent
| cache_threshold
| cache_max_age
| adaptive_lease_time_threshold
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_use_conflict_resolution
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| hostname_char_set
| hostname_char_replacement
| store_extended_info
| allocator
| offer_lifetime
| unknown_map_entry
option_def_list ::= "option-def" ":" "[" option_def_list_content "]"
sub_option_def_list ::= "{" option_def_list "}"
option_def_list_content ::=
| not_empty_option_def_list
not_empty_option_def_list ::= option_def_entry
| not_empty_option_def_list "," option_def_entry
| not_empty_option_def_list ","
option_def_entry ::= "{" option_def_params "}"
sub_option_def ::= "{" option_def_params "}"
option_def_params ::=
| not_empty_option_def_params
not_empty_option_def_params ::= option_def_param
| not_empty_option_def_params "," option_def_param
| not_empty_option_def_params ","
option_def_param ::= option_def_name
| option_def_code
| option_def_type
| option_def_record_types
| option_def_space
| option_def_encapsulate
| option_def_array
| user_context
| comment
| unknown_map_entry
option_def_name ::= name
code ::= "code" ":" INTEGER
option_def_code ::= code
option_def_type ::= "type" ":" STRING
option_def_record_types ::= "record-types" ":" STRING
space ::= "space" ":" STRING
option_def_space ::= space
option_def_encapsulate ::= "encapsulate" ":" STRING
option_def_array ::= "array" ":" BOOLEAN
option_data_list ::= "option-data" ":" "[" option_data_list_content "]"
option_data_list_content ::=
| not_empty_option_data_list
not_empty_option_data_list ::= option_data_entry
| not_empty_option_data_list "," option_data_entry
| not_empty_option_data_list ","
option_data_entry ::= "{" option_data_params "}"
sub_option_data ::= "{" option_data_params "}"
option_data_params ::=
| not_empty_option_data_params
not_empty_option_data_params ::= option_data_param
| not_empty_option_data_params "," option_data_param
| not_empty_option_data_params ","
option_data_param ::= option_data_name
| option_data_data
| option_data_code
| option_data_space
| option_data_csv_format
| option_data_always_send
| option_data_never_send
| user_context
| comment
| option_data_client_classes
| unknown_map_entry
option_data_name ::= name
option_data_data ::= "data" ":" STRING
option_data_code ::= code
option_data_space ::= space
option_data_csv_format ::= "csv-format" ":" BOOLEAN
option_data_always_send ::= "always-send" ":" BOOLEAN
option_data_never_send ::= "never-send" ":" BOOLEAN
option_data_client_classes ::= "client-classes" ":" list_strings
pools_list ::= "pools" ":" "[" pools_list_content "]"
pools_list_content ::=
| not_empty_pools_list
not_empty_pools_list ::= pool_list_entry
| not_empty_pools_list "," pool_list_entry
| not_empty_pools_list ","
pool_list_entry ::= "{" pool_params "}"
sub_pool4 ::= "{" pool_params "}"
pool_params ::= pool_param
| pool_params "," pool_param
| pool_params ","
pool_param ::= pool_entry
| pool_id
| option_data_list
| client_class
| network_client_classes
| require_client_classes
| evaluate_additional_classes
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| hostname_char_set
| hostname_char_replacement
| user_context
| comment
| unknown_map_entry
pool_entry ::= "pool" ":" STRING
pool_id ::= "pool-id" ":" INTEGER
user_context ::= "user-context" ":" map_value
comment ::= "comment" ":" STRING
reservations ::= "reservations" ":" "[" reservations_list "]"
reservations_list ::=
| not_empty_reservations_list
not_empty_reservations_list ::= reservation
| not_empty_reservations_list "," reservation
| not_empty_reservations_list ","
reservation ::= "{" reservation_params "}"
sub_reservation ::= "{" reservation_params "}"
reservation_params ::=
| not_empty_reservation_params
not_empty_reservation_params ::= reservation_param
| not_empty_reservation_params "," reservation_param
| not_empty_reservation_params ","
reservation_param ::= duid
| reservation_client_classes
| client_id_value
| circuit_id_value
| flex_id_value
| ip_address
| hw_address
| hostname
| option_data_list
| next_server
| server_hostname
| boot_file_name
| user_context
| comment
| unknown_map_entry
next_server ::= "next-server" ":" STRING
server_hostname ::= "server-hostname" ":" STRING
boot_file_name ::= "boot-file-name" ":" STRING
ip_address ::= "ip-address" ":" STRING
duid ::= "duid" ":" STRING
hw_address ::= "hw-address" ":" STRING
client_id_value ::= "client-id" ":" STRING
circuit_id_value ::= "circuit-id" ":" STRING
flex_id_value ::= "flex-id" ":" STRING
hostname ::= "hostname" ":" STRING
reservation_client_classes ::= "client-classes" ":" list_strings
relay ::= "relay" ":" "{" relay_map "}"
relay_map ::= ip_addresses
ip_addresses ::= "ip-addresses" ":" list_strings
client_classes ::= "client-classes" ":" "[" client_classes_list "]"
client_classes_list ::=
| not_empty_classes_list
not_empty_classes_list ::= client_class_entry
| not_empty_classes_list "," client_class_entry
| not_empty_classes_list ","
client_class_entry ::= "{" client_class_params "}"
client_class_params ::=
| not_empty_client_class_params
not_empty_client_class_params ::= client_class_param
| not_empty_client_class_params "," client_class_param
| not_empty_client_class_params ","
client_class_param ::= client_class_name
| client_class_test
| client_class_template_test
| only_if_required
| only_in_additional_list
| option_def_list
| option_data_list
| next_server
| server_hostname
| boot_file_name
| user_context
| comment
| unknown_map_entry
| valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| offer_lifetime
client_class_name ::= name
client_class_test ::= "test" ":" STRING
client_class_template_test ::= "template-test" ":" STRING
only_if_required ::= "only-if-required" ":" BOOLEAN
only_in_additional_list ::= "only-in-additional-list" ":" BOOLEAN
dhcp4o6_port ::= "dhcp4o6-port" ":" INTEGER
control_socket ::= "control-socket" ":" "{" control_socket_params "}"
control_sockets ::= "control-sockets" ":" "[" control_socket_list "]"
control_socket_list ::=
| not_empty_control_socket_list
not_empty_control_socket_list ::= control_socket_entry
| not_empty_control_socket_list "," control_socket_entry
| not_empty_control_socket_list ","
control_socket_entry ::= "{" control_socket_params "}"
control_socket_params ::= control_socket_param
| control_socket_params "," control_socket_param
| control_socket_params ","
control_socket_param ::= control_socket_type
| control_socket_name
| control_socket_address
| control_socket_port
| authentication
| trust_anchor
| cert_file
| key_file
| cert_required
| http_headers
| user_context
| comment
| unknown_map_entry
control_socket_type ::= "socket-type" ":" control_socket_type_value
control_socket_type_value ::= "unix"
| "http"
| "https"
control_socket_name ::= "socket-name" ":" STRING
control_socket_address ::= "socket-address" ":" STRING
control_socket_port ::= "socket-port" ":" INTEGER
cert_required ::= "cert-required" ":" BOOLEAN
http_headers ::= "http-headers" ":" "[" http_header_list "]"
http_header_list ::=
| not_empty_http_header_list
not_empty_http_header_list ::= http_header
| not_empty_http_header_list "," http_header
| not_empty_http_header_list ","
http_header ::= "{" http_header_params "}"
http_header_params ::= http_header_param
| http_header_params "," http_header_param
| http_header_params ","
http_header_param ::= name
| header_value
| user_context
| comment
| unknown_map_entry
header_value ::= "value" ":" STRING
authentication ::= "authentication" ":" "{" auth_params "}"
auth_params ::= auth_param
| auth_params "," auth_param
| auth_params ","
auth_param ::= auth_type
| realm
| directory
| clients
| comment
| user_context
| unknown_map_entry
auth_type ::= "type" ":" auth_type_value
auth_type_value ::= "basic"
realm ::= "realm" ":" STRING
directory ::= "directory" ":" STRING
clients ::= "clients" ":" "[" clients_list "]"
clients_list ::=
| not_empty_clients_list
not_empty_clients_list ::= basic_auth
| not_empty_clients_list "," basic_auth
| not_empty_clients_list ","
basic_auth ::= "{" clients_params "}"
clients_params ::= clients_param
| clients_params "," clients_param
| clients_params ","
clients_param ::= user
| user_file
| password
| password_file
| user_context
| comment
| unknown_map_entry
user_file ::= "user-file" ":" STRING
password_file ::= "password-file" ":" STRING
dhcp_queue_control ::= "dhcp-queue-control" ":" "{" queue_control_params "}"
queue_control_params ::= queue_control_param
| queue_control_params "," queue_control_param
| queue_control_params ","
queue_control_param ::= enable_queue
| queue_type
| capacity
| user_context
| comment
| arbitrary_map_entry
enable_queue ::= "enable-queue" ":" BOOLEAN
queue_type ::= "queue-type" ":" STRING
capacity ::= "capacity" ":" INTEGER
arbitrary_map_entry ::= STRING ":" value
dhcp_ddns ::= "dhcp-ddns" ":" "{" dhcp_ddns_params "}"
sub_dhcp_ddns ::= "{" dhcp_ddns_params "}"
dhcp_ddns_params ::= dhcp_ddns_param
| dhcp_ddns_params "," dhcp_ddns_param
| dhcp_ddns_params ","
dhcp_ddns_param ::= enable_updates
| server_ip
| server_port
| sender_ip
| sender_port
| max_queue_size
| ncr_protocol
| ncr_format
| user_context
| comment
| unknown_map_entry
enable_updates ::= "enable-updates" ":" BOOLEAN
server_ip ::= "server-ip" ":" STRING
server_port ::= "server-port" ":" INTEGER
sender_ip ::= "sender-ip" ":" STRING
sender_port ::= "sender-port" ":" INTEGER
max_queue_size ::= "max-queue-size" ":" INTEGER
ncr_protocol ::= "ncr-protocol" ":" ncr_protocol_value
ncr_protocol_value ::= "udp"
| "tcp"
ncr_format ::= "ncr-format" ":" "JSON"
config_control ::= "config-control" ":" "{" config_control_params "}"
sub_config_control ::= "{" config_control_params "}"
config_control_params ::= config_control_param
| config_control_params "," config_control_param
| config_control_params ","
config_control_param ::= config_databases
| config_fetch_wait_time
config_databases ::= "config-databases" ":" "[" database_list "]"
config_fetch_wait_time ::= "config-fetch-wait-time" ":" INTEGER
loggers ::= "loggers" ":" "[" loggers_entries "]"
loggers_entries ::= logger_entry
| loggers_entries "," logger_entry
| loggers_entries ","
logger_entry ::= "{" logger_params "}"
logger_params ::= logger_param
| logger_params "," logger_param
| logger_params ","
logger_param ::= name
| output_options_list
| debuglevel
| severity
| user_context
| comment
| unknown_map_entry
debuglevel ::= "debuglevel" ":" INTEGER
severity ::= "severity" ":" STRING
output_options_list ::= "output-options" ":" "[" output_options_list_content "]"
output_options_list_content ::= output_entry
| output_options_list_content "," output_entry
| output_options_list_content ","
output_entry ::= "{" output_params_list "}"
output_params_list ::= output_params
| output_params_list "," output_params
| output_params_list ","
output_params ::= output
| flush
| maxsize
| maxver
| pattern
output ::= "output" ":" STRING
flush ::= "flush" ":" BOOLEAN
maxsize ::= "maxsize" ":" INTEGER
maxver ::= "maxver" ":" INTEGER
pattern ::= "pattern" ":" STRING
compatibility ::= "compatibility" ":" "{" compatibility_params "}"
compatibility_params ::= compatibility_param
| compatibility_params "," compatibility_param
| compatibility_params ","
compatibility_param ::= lenient_option_parsing
| ignore_dhcp_server_identifier
| ignore_rai_link_selection
| exclude_first_last_24
| unknown_map_entry
lenient_option_parsing ::= "lenient-option-parsing" ":" BOOLEAN
ignore_dhcp_server_identifier ::= "ignore-dhcp-server-identifier" ":" BOOLEAN
ignore_rai_link_selection ::= "ignore-rai-link-selection" ":" BOOLEAN
exclude_first_last_24 ::= "exclude-first-last-24" ":" BOOLEAN
168u
این دستور زبان از dhcp6_parser.yy تولید شده است. برای جزئیات بیشتر «The DHCPv6 Server» <#dhcp6> را ببینید.
0.0
3.5
Grammar
$accept ::= start EOF
start ::= TOPLEVEL_JSON sub_json
start ::= TOPLEVEL_DHCP6 syntax_map
start ::= SUB_DHCP6 sub_dhcp6
start ::= SUB_INTERFACES6 sub_interfaces6
start ::= SUB_SUBNET6 sub_subnet6
start ::= SUB_POOL6 sub_pool6
start ::= SUB_PD_POOL sub_pd_pool
start ::= SUB_RESERVATION sub_reservation
start ::= SUB_OPTION_DEFS sub_option_def_list
start ::= SUB_OPTION_DEF sub_option_def
start ::= SUB_OPTION_DATA sub_option_data
start ::= SUB_HOOKS_LIBRARY sub_hooks_library
start ::= SUB_DHCP_DDNS sub_dhcp_ddns
start ::= SUB_CONFIG_CONTROL sub_config_control
value ::= INTEGER
| FLOAT
| BOOLEAN
| STRING
| NULL
| map2
| list_generic
sub_json ::= value
map2 ::= "{" map_content "}"
map_value ::= map2
map_content ::=
| not_empty_map
not_empty_map ::= STRING ":" value
| not_empty_map "," STRING ":" value
| not_empty_map ","
list_generic ::= "[" list_content "]"
list_content ::=
| not_empty_list
not_empty_list ::= value
| not_empty_list "," value
| not_empty_list ","
list_strings ::= "[" list_strings_content "]"
list_strings_content ::=
| not_empty_list_strings
not_empty_list_strings ::= STRING
| not_empty_list_strings "," STRING
| not_empty_list_strings ","
unknown_map_entry ::= STRING ":"
syntax_map ::= "{" global_object "}"
global_object ::= "Dhcp6" ":" "{" global_params "}"
| global_object_comma
global_object_comma ::= global_object ","
sub_dhcp6 ::= "{" global_params "}"
global_params ::= global_param
| global_params "," global_param
| global_params ","
global_param ::= data_directory
| preferred_lifetime
| min_preferred_lifetime
| max_preferred_lifetime
| valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| renew_timer
| rebind_timer
| decline_probation_period
| subnet6_list
| shared_networks
| interfaces_config
| lease_database
| hosts_database
| hosts_databases
| mac_sources
| relay_supplied_options
| host_reservation_identifiers
| client_classes
| option_def_list
| option_data_list
| hooks_libraries
| expired_leases_processing
| server_id
| dhcp4o6_port
| control_socket
| control_sockets
| dhcp_queue_control
| dhcp_ddns
| user_context
| comment
| sanity_checks
| reservations
| config_control
| server_tag
| reservations_global
| reservations_in_subnet
| reservations_out_of_pool
| calculate_tee_times
| t1_percent
| t2_percent
| cache_threshold
| cache_max_age
| adaptive_lease_time_threshold
| loggers
| hostname_char_set
| hostname_char_replacement
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_use_conflict_resolution
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| store_extended_info
| statistic_default_sample_count
| statistic_default_sample_age
| dhcp_multi_threading
| early_global_reservations_lookup
| ip_reservations_unique
| reservations_lookup_first
| allow_address_registration
| compatibility
| parked_packet_limit
| allocator
| pd_allocator
| unknown_map_entry
data_directory ::= "data-directory" ":" STRING
preferred_lifetime ::= "preferred-lifetime" ":" INTEGER
min_preferred_lifetime ::= "min-preferred-lifetime" ":" INTEGER
max_preferred_lifetime ::= "max-preferred-lifetime" ":" INTEGER
valid_lifetime ::= "valid-lifetime" ":" INTEGER
min_valid_lifetime ::= "min-valid-lifetime" ":" INTEGER
max_valid_lifetime ::= "max-valid-lifetime" ":" INTEGER
renew_timer ::= "renew-timer" ":" INTEGER
rebind_timer ::= "rebind-timer" ":" INTEGER
calculate_tee_times ::= "calculate-tee-times" ":" BOOLEAN
t1_percent ::= "t1-percent" ":" FLOAT
t2_percent ::= "t2-percent" ":" FLOAT
cache_threshold ::= "cache-threshold" ":" FLOAT
cache_max_age ::= "cache-max-age" ":" INTEGER
adaptive_lease_time_threshold ::= "adaptive-lease-time-threshold" ":" FLOAT
decline_probation_period ::= "decline-probation-period" ":" INTEGER
ddns_send_updates ::= "ddns-send-updates" ":" BOOLEAN
ddns_override_no_update ::= "ddns-override-no-update" ":" BOOLEAN
ddns_override_client_update ::= "ddns-override-client-update" ":" BOOLEAN
ddns_replace_client_name ::= "ddns-replace-client-name" ":" ddns_replace_client_name_value
ddns_replace_client_name_value ::= "when-present"
| "never"
| "always"
| "when-not-present"
| BOOLEAN
ddns_generated_prefix ::= "ddns-generated-prefix" ":" STRING
ddns_qualifying_suffix ::= "ddns-qualifying-suffix" ":" STRING
ddns_update_on_renew ::= "ddns-update-on-renew" ":" BOOLEAN
ddns_use_conflict_resolution ::= "ddns-use-conflict-resolution" ":" BOOLEAN
ddns_conflict_resolution_mode ::= "ddns-conflict-resolution-mode" ":" ddns_conflict_resolution_mode_value
ddns_conflict_resolution_mode_value ::= "check-with-dhcid"
| "no-check-with-dhcid"
| "check-exists-with-dhcid"
| "no-check-without-dhcid"
ddns_ttl_percent ::= "ddns-ttl-percent" ":" FLOAT
ddns_ttl ::= "ddns-ttl" ":" INTEGER
ddns_ttl_min ::= "ddns-ttl-min" ":" INTEGER
ddns_ttl_max ::= "ddns-ttl-max" ":" INTEGER
hostname_char_set ::= "hostname-char-set" ":" STRING
hostname_char_replacement ::= "hostname-char-replacement" ":" STRING
store_extended_info ::= "store-extended-info" ":" BOOLEAN
statistic_default_sample_count ::= "statistic-default-sample-count" ":" INTEGER
statistic_default_sample_age ::= "statistic-default-sample-age" ":" INTEGER
server_tag ::= "server-tag" ":" STRING
parked_packet_limit ::= "parked-packet-limit" ":" INTEGER
allocator ::= "allocator" ":" STRING
pd_allocator ::= "pd-allocator" ":" STRING
early_global_reservations_lookup ::= "early-global-reservations-lookup" ":" BOOLEAN
ip_reservations_unique ::= "ip-reservations-unique" ":" BOOLEAN
reservations_lookup_first ::= "reservations-lookup-first" ":" BOOLEAN
allow_address_registration ::= "allow-address-registration" ":" BOOLEAN
interfaces_config ::= "interfaces-config" ":" "{" interfaces_config_params "}"
sub_interfaces6 ::= "{" interfaces_config_params "}"
interfaces_config_params ::= interfaces_config_param
| interfaces_config_params "," interfaces_config_param
| interfaces_config_params ","
interfaces_config_param ::= interfaces_list
| re_detect
| service_sockets_require_all
| service_sockets_retry_wait_time
| service_sockets_max_retries
| user_context
| comment
| unknown_map_entry
interfaces_list ::= "interfaces" ":" list_strings
re_detect ::= "re-detect" ":" BOOLEAN
service_sockets_require_all ::= "service-sockets-require-all" ":" BOOLEAN
service_sockets_retry_wait_time ::= "service-sockets-retry-wait-time" ":" INTEGER
service_sockets_max_retries ::= "service-sockets-max-retries" ":" INTEGER
lease_database ::= "lease-database" ":" "{" database_map_params "}"
hosts_database ::= "hosts-database" ":" "{" database_map_params "}"
hosts_databases ::= "hosts-databases" ":" "[" database_list "]"
database_list ::=
| not_empty_database_list
not_empty_database_list ::= database
| not_empty_database_list "," database
| not_empty_database_list ","
database ::= "{" database_map_params "}"
database_map_params ::= database_map_param
| database_map_params "," database_map_param
| database_map_params ","
database_map_param ::= database_type
| user
| password
| host
| port
| name
| persist
| lfc_interval
| readonly
| connect_timeout
| read_timeout
| write_timeout
| tcp_user_timeout
| max_reconnect_tries
| reconnect_wait_time
| on_fail
| retry_on_startup
| max_row_errors
| trust_anchor
| cert_file
| key_file
| ssl_mode
| cipher_list
| unknown_map_entry
database_type ::= "type" ":" STRING
user ::= "user" ":" STRING
password ::= "password" ":" STRING
host ::= "host" ":" STRING
port ::= "port" ":" INTEGER
name ::= "name" ":" STRING
persist ::= "persist" ":" BOOLEAN
lfc_interval ::= "lfc-interval" ":" INTEGER
readonly ::= "readonly" ":" BOOLEAN
connect_timeout ::= "connect-timeout" ":" INTEGER
read_timeout ::= "read-timeout" ":" INTEGER
write_timeout ::= "write-timeout" ":" INTEGER
tcp_user_timeout ::= "tcp-user-timeout" ":" INTEGER
reconnect_wait_time ::= "reconnect-wait-time" ":" INTEGER
on_fail ::= "on-fail" ":" on_fail_mode
on_fail_mode ::= "stop-retry-exit"
| "serve-retry-exit"
| "serve-retry-continue"
retry_on_startup ::= "retry-on-startup" ":" BOOLEAN
max_row_errors ::= "max-row-errors" ":" INTEGER
max_reconnect_tries ::= "max-reconnect-tries" ":" INTEGER
trust_anchor ::= "trust-anchor" ":" STRING
cert_file ::= "cert-file" ":" STRING
key_file ::= "key-file" ":" STRING
ssl_mode ::= "ssl-mode" ":" ssl_mode
| "disable"
| "prefer"
| "require"
| "verify-ca"
| "verify-full"
cipher_list ::= "cipher-list" ":" STRING
sanity_checks ::= "sanity-checks" ":" "{" sanity_checks_params "}"
sanity_checks_params ::= sanity_checks_param
| sanity_checks_params "," sanity_checks_param
| sanity_checks_params ","
sanity_checks_param ::= lease_checks
| extended_info_checks
lease_checks ::= "lease-checks" ":" STRING
extended_info_checks ::= "extended-info-checks" ":" STRING
mac_sources ::= "mac-sources" ":" "[" mac_sources_list "]"
mac_sources_list ::= mac_sources_value
| mac_sources_list "," mac_sources_value
| mac_sources_list ","
mac_sources_value ::= duid_id
| string_id
duid_id ::= "duid"
string_id ::= STRING
host_reservation_identifiers ::= "host-reservation-identifiers" ":" "[" host_reservation_identifiers_list "]"
host_reservation_identifiers_list ::= host_reservation_identifier
| host_reservation_identifiers_list "," host_reservation_identifier
| host_reservation_identifiers_list ","
host_reservation_identifier ::= duid_id
| hw_address_id
| flex_id
hw_address_id ::= "hw-address"
flex_id ::= "flex-id"
relay_supplied_options ::= "relay-supplied-options" ":" "[" list_content "]"
dhcp_multi_threading ::= "multi-threading" ":" "{" multi_threading_params "}"
multi_threading_params ::= multi_threading_param
| multi_threading_params "," multi_threading_param
| multi_threading_params ","
multi_threading_param ::= enable_multi_threading
| thread_pool_size
| packet_queue_size
| user_context
| comment
| unknown_map_entry
enable_multi_threading ::= "enable-multi-threading" ":" BOOLEAN
thread_pool_size ::= "thread-pool-size" ":" INTEGER
packet_queue_size ::= "packet-queue-size" ":" INTEGER
hooks_libraries ::= "hooks-libraries" ":" "[" hooks_libraries_list "]"
hooks_libraries_list ::=
| not_empty_hooks_libraries_list
not_empty_hooks_libraries_list ::= hooks_library
| not_empty_hooks_libraries_list "," hooks_library
| not_empty_hooks_libraries_list ","
hooks_library ::= "{" hooks_params "}"
sub_hooks_library ::= "{" hooks_params "}"
hooks_params ::= hooks_param
| hooks_params "," hooks_param
| hooks_params ","
| unknown_map_entry
hooks_param ::= library
| parameters
library ::= "library" ":" STRING
parameters ::= "parameters" ":" map_value
expired_leases_processing ::= "expired-leases-processing" ":" "{" expired_leases_params "}"
expired_leases_params ::= expired_leases_param
| expired_leases_params "," expired_leases_param
| expired_leases_params ","
expired_leases_param ::= reclaim_timer_wait_time
| flush_reclaimed_timer_wait_time
| hold_reclaimed_time
| max_reclaim_leases
| max_reclaim_time
| unwarned_reclaim_cycles
reclaim_timer_wait_time ::= "reclaim-timer-wait-time" ":" INTEGER
flush_reclaimed_timer_wait_time ::= "flush-reclaimed-timer-wait-time" ":" INTEGER
hold_reclaimed_time ::= "hold-reclaimed-time" ":" INTEGER
max_reclaim_leases ::= "max-reclaim-leases" ":" INTEGER
max_reclaim_time ::= "max-reclaim-time" ":" INTEGER
unwarned_reclaim_cycles ::= "unwarned-reclaim-cycles" ":" INTEGER
subnet6_list ::= "subnet6" ":" "[" subnet6_list_content "]"
subnet6_list_content ::=
| not_empty_subnet6_list
not_empty_subnet6_list ::= subnet6
| not_empty_subnet6_list "," subnet6
| not_empty_subnet6_list ","
subnet6 ::= "{" subnet6_params "}"
sub_subnet6 ::= "{" subnet6_params "}"
subnet6_params ::= subnet6_param
| subnet6_params "," subnet6_param
| subnet6_params ","
subnet6_param ::= preferred_lifetime
| min_preferred_lifetime
| max_preferred_lifetime
| valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| renew_timer
| rebind_timer
| option_data_list
| pools_list
| pd_pools_list
| subnet
| interface
| interface_id
| id
| rapid_commit
| client_class
| network_client_classes
| require_client_classes
| evaluate_additional_classes
| reservations
| reservations_global
| reservations_in_subnet
| reservations_out_of_pool
| relay
| user_context
| comment
| calculate_tee_times
| t1_percent
| t2_percent
| cache_threshold
| cache_max_age
| adaptive_lease_time_threshold
| hostname_char_set
| hostname_char_replacement
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_use_conflict_resolution
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| store_extended_info
| allocator
| pd_allocator
| unknown_map_entry
subnet ::= "subnet" ":" STRING
interface ::= "interface" ":" STRING
interface_id ::= "interface-id" ":" STRING
client_class ::= "client-class" ":" STRING
network_client_classes ::= "client-classes" ":" list_strings
require_client_classes ::= "require-client-classes" ":" list_strings
evaluate_additional_classes ::= "evaluate-additional-classes" ":" list_strings
reservations_global ::= "reservations-global" ":" BOOLEAN
reservations_in_subnet ::= "reservations-in-subnet" ":" BOOLEAN
reservations_out_of_pool ::= "reservations-out-of-pool" ":" BOOLEAN
id ::= "id" ":" INTEGER
rapid_commit ::= "rapid-commit" ":" BOOLEAN
shared_networks ::= "shared-networks" ":" "[" shared_networks_content "]"
shared_networks_content ::=
| shared_networks_list
shared_networks_list ::= shared_network
| shared_networks_list "," shared_network
| shared_networks_list ","
shared_network ::= "{" shared_network_params "}"
shared_network_params ::= shared_network_param
| shared_network_params "," shared_network_param
| shared_network_params ","
shared_network_param ::= name
| subnet6_list
| interface
| interface_id
| renew_timer
| rebind_timer
| option_data_list
| relay
| reservations_global
| reservations_in_subnet
| reservations_out_of_pool
| client_class
| network_client_classes
| require_client_classes
| evaluate_additional_classes
| preferred_lifetime
| min_preferred_lifetime
| max_preferred_lifetime
| rapid_commit
| valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| user_context
| comment
| calculate_tee_times
| t1_percent
| t2_percent
| cache_threshold
| cache_max_age
| adaptive_lease_time_threshold
| hostname_char_set
| hostname_char_replacement
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_use_conflict_resolution
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| store_extended_info
| allocator
| pd_allocator
| unknown_map_entry
option_def_list ::= "option-def" ":" "[" option_def_list_content "]"
sub_option_def_list ::= "{" option_def_list "}"
option_def_list_content ::=
| not_empty_option_def_list
not_empty_option_def_list ::= option_def_entry
| not_empty_option_def_list "," option_def_entry
| not_empty_option_def_list ","
option_def_entry ::= "{" option_def_params "}"
sub_option_def ::= "{" option_def_params "}"
option_def_params ::=
| not_empty_option_def_params
not_empty_option_def_params ::= option_def_param
| not_empty_option_def_params "," option_def_param
| not_empty_option_def_params ","
option_def_param ::= option_def_name
| option_def_code
| option_def_type
| option_def_record_types
| option_def_space
| option_def_encapsulate
| option_def_array
| user_context
| comment
| unknown_map_entry
option_def_name ::= name
code ::= "code" ":" INTEGER
option_def_code ::= code
option_def_type ::= "type" ":" STRING
option_def_record_types ::= "record-types" ":" STRING
space ::= "space" ":" STRING
option_def_space ::= space
option_def_encapsulate ::= "encapsulate" ":" STRING
option_def_array ::= "array" ":" BOOLEAN
option_data_list ::= "option-data" ":" "[" option_data_list_content "]"
option_data_list_content ::=
| not_empty_option_data_list
not_empty_option_data_list ::= option_data_entry
| not_empty_option_data_list "," option_data_entry
| not_empty_option_data_list ","
option_data_entry ::= "{" option_data_params "}"
sub_option_data ::= "{" option_data_params "}"
option_data_params ::=
| not_empty_option_data_params
not_empty_option_data_params ::= option_data_param
| not_empty_option_data_params "," option_data_param
| not_empty_option_data_params ","
option_data_param ::= option_data_name
| option_data_data
| option_data_code
| option_data_space
| option_data_csv_format
| option_data_always_send
| option_data_never_send
| user_context
| comment
| option_data_client_classes
| unknown_map_entry
option_data_name ::= name
option_data_data ::= "data" ":" STRING
option_data_code ::= code
option_data_space ::= space
option_data_csv_format ::= "csv-format" ":" BOOLEAN
option_data_always_send ::= "always-send" ":" BOOLEAN
option_data_never_send ::= "never-send" ":" BOOLEAN
option_data_client_classes ::= "client-classes" ":" list_strings
pools_list ::= "pools" ":" "[" pools_list_content "]"
pools_list_content ::=
| not_empty_pools_list
not_empty_pools_list ::= pool_list_entry
| not_empty_pools_list "," pool_list_entry
| not_empty_pools_list ","
pool_list_entry ::= "{" pool_params "}"
sub_pool6 ::= "{" pool_params "}"
pool_params ::= pool_param
| pool_params "," pool_param
| pool_params ","
pool_param ::= pool_entry
| pool_id
| option_data_list
| client_class
| network_client_classes
| require_client_classes
| evaluate_additional_classes
| ddns_send_updates
| ddns_override_no_update
| ddns_override_client_update
| ddns_replace_client_name
| ddns_generated_prefix
| ddns_qualifying_suffix
| ddns_update_on_renew
| ddns_conflict_resolution_mode
| ddns_ttl_percent
| ddns_ttl
| ddns_ttl_min
| ddns_ttl_max
| hostname_char_set
| hostname_char_replacement
| user_context
| comment
| unknown_map_entry
pool_entry ::= "pool" ":" STRING
pool_id ::= "pool-id" ":" INTEGER
user_context ::= "user-context" ":" map_value
comment ::= "comment" ":" STRING
pd_pools_list ::= "pd-pools" ":" "[" pd_pools_list_content "]"
pd_pools_list_content ::=
| not_empty_pd_pools_list
not_empty_pd_pools_list ::= pd_pool_entry
| not_empty_pd_pools_list "," pd_pool_entry
| not_empty_pd_pools_list ","
pd_pool_entry ::= "{" pd_pool_params "}"
sub_pd_pool ::= "{" pd_pool_params "}"
pd_pool_params ::= pd_pool_param
| pd_pool_params "," pd_pool_param
| pd_pool_params ","
pd_pool_param ::= pd_prefix
| pd_prefix_len
| pd_delegated_len
| pool_id
| option_data_list
| client_class
| network_client_classes
| require_client_classes
| evaluate_additional_classes
| excluded_prefix
| excluded_prefix_len
| user_context
| comment
| unknown_map_entry
pd_prefix ::= "prefix" ":" STRING
pd_prefix_len ::= "prefix-len" ":" INTEGER
excluded_prefix ::= "excluded-prefix" ":" STRING
excluded_prefix_len ::= "excluded-prefix-len" ":" INTEGER
pd_delegated_len ::= "delegated-len" ":" INTEGER
reservations ::= "reservations" ":" "[" reservations_list "]"
reservations_list ::=
| not_empty_reservations_list
not_empty_reservations_list ::= reservation
| not_empty_reservations_list "," reservation
| not_empty_reservations_list ","
reservation ::= "{" reservation_params "}"
sub_reservation ::= "{" reservation_params "}"
reservation_params ::=
| not_empty_reservation_params
not_empty_reservation_params ::= reservation_param
| not_empty_reservation_params "," reservation_param
| not_empty_reservation_params ","
reservation_param ::= duid
| reservation_client_classes
| ip_addresses
| prefixes
| excluded_prefixes
| hw_address
| hostname
| flex_id_value
| option_data_list
| user_context
| comment
| unknown_map_entry
ip_addresses ::= "ip-addresses" ":" list_strings
prefixes ::= "prefixes" ":" list_strings
excluded_prefixes ::= "excluded-prefixes" ":" list_strings
duid ::= "duid" ":" STRING
hw_address ::= "hw-address" ":" STRING
hostname ::= "hostname" ":" STRING
flex_id_value ::= "flex-id" ":" STRING
reservation_client_classes ::= "client-classes" ":" list_strings
relay ::= "relay" ":" "{" relay_map "}"
relay_map ::= ip_addresses
client_classes ::= "client-classes" ":" "[" client_classes_list "]"
client_classes_list ::=
| not_empty_classes_list
not_empty_classes_list ::= client_class_entry
| not_empty_classes_list "," client_class_entry
| not_empty_classes_list ","
client_class_entry ::= "{" client_class_params "}"
client_class_params ::=
| not_empty_client_class_params
not_empty_client_class_params ::= client_class_param
| not_empty_client_class_params "," client_class_param
| not_empty_client_class_params ","
client_class_param ::= client_class_name
| client_class_test
| client_class_template_test
| only_if_required
| only_in_additional_list
| option_data_list
| user_context
| comment
| preferred_lifetime
| min_preferred_lifetime
| max_preferred_lifetime
| valid_lifetime
| min_valid_lifetime
| max_valid_lifetime
| unknown_map_entry
client_class_name ::= name
client_class_test ::= "test" ":" STRING
client_class_template_test ::= "template-test" ":" STRING
only_if_required ::= "only-if-required" ":" BOOLEAN
only_in_additional_list ::= "only-in-additional-list" ":" BOOLEAN
server_id ::= "server-id" ":" "{" server_id_params "}"
server_id_params ::= server_id_param
| server_id_params "," server_id_param
| server_id_params ","
server_id_param ::= server_id_type
| identifier
| time
| htype
| enterprise_id
| persist
| user_context
| comment
| unknown_map_entry
server_id_type ::= "type" ":" duid_type
duid_type ::= "LLT"
| "EN"
| "LL"
htype ::= "htype" ":" INTEGER
identifier ::= "identifier" ":" STRING
time ::= "time" ":" INTEGER
enterprise_id ::= "enterprise-id" ":" INTEGER
dhcp4o6_port ::= "dhcp4o6-port" ":" INTEGER
control_socket ::= "control-socket" ":" "{" control_socket_params "}"
control_sockets ::= "control-sockets" ":" "[" control_socket_list "]"
control_socket_list ::=
| not_empty_control_socket_list
not_empty_control_socket_list ::= control_socket_entry
| not_empty_control_socket_list "," control_socket_entry
| not_empty_control_socket_list ","
control_socket_entry ::= "{" control_socket_params "}"
control_socket_params ::= control_socket_param
| control_socket_params "," control_socket_param
| control_socket_params ","
control_socket_param ::= control_socket_type
| control_socket_name
| control_socket_address
| control_socket_port
| authentication
| trust_anchor
| cert_file
| key_file
| cert_required
| http_headers
| user_context
| comment
| unknown_map_entry
control_socket_type ::= "socket-type" ":" control_socket_type_value
control_socket_type_value ::= "unix"
| "http"
| "https"
control_socket_name ::= "socket-name" ":" STRING
control_socket_address ::= "socket-address" ":" STRING
control_socket_port ::= "socket-port" ":" INTEGER
cert_required ::= "cert-required" ":" BOOLEAN
http_headers ::= "http-headers" ":" "[" http_header_list "]"
http_header_list ::=
| not_empty_http_header_list
not_empty_http_header_list ::= http_header
| not_empty_http_header_list "," http_header
| not_empty_http_header_list ","
http_header ::= "{" http_header_params "}"
http_header_params ::= http_header_param
| http_header_params "," http_header_param
| http_header_params ","
http_header_param ::= name
| header_value
| user_context
| comment
| unknown_map_entry
header_value ::= "value" ":" STRING
authentication ::= "authentication" ":" "{" auth_params "}"
auth_params ::= auth_param
| auth_params "," auth_param
| auth_params ","
auth_param ::= auth_type
| realm
| directory
| clients
| comment
| user_context
| unknown_map_entry
auth_type ::= "type" ":" auth_type_value
auth_type_value ::= "basic"
realm ::= "realm" ":" STRING
directory ::= "directory" ":" STRING
clients ::= "clients" ":" "[" clients_list "]"
clients_list ::=
| not_empty_clients_list
not_empty_clients_list ::= basic_auth
| not_empty_clients_list "," basic_auth
| not_empty_clients_list ","
basic_auth ::= "{" clients_params "}"
clients_params ::= clients_param
| clients_params "," clients_param
| clients_params ","
clients_param ::= user
| user_file
| password
| password_file
| user_context
| comment
| unknown_map_entry
user_file ::= "user-file" ":" STRING
password_file ::= "password-file" ":" STRING
dhcp_queue_control ::= "dhcp-queue-control" ":" "{" queue_control_params "}"
queue_control_params ::= queue_control_param
| queue_control_params "," queue_control_param
| queue_control_params ","
queue_control_param ::= enable_queue
| queue_type
| capacity
| user_context
| comment
| arbitrary_map_entry
enable_queue ::= "enable-queue" ":" BOOLEAN
queue_type ::= "queue-type" ":" STRING
capacity ::= "capacity" ":" INTEGER
arbitrary_map_entry ::= STRING ":" value
dhcp_ddns ::= "dhcp-ddns" ":" "{" dhcp_ddns_params "}"
sub_dhcp_ddns ::= "{" dhcp_ddns_params "}"
dhcp_ddns_params ::= dhcp_ddns_param
| dhcp_ddns_params "," dhcp_ddns_param
| dhcp_ddns_params ","
dhcp_ddns_param ::= enable_updates
| server_ip
| server_port
| sender_ip
| sender_port
| max_queue_size
| ncr_protocol
| ncr_format
| user_context
| comment
| unknown_map_entry
enable_updates ::= "enable-updates" ":" BOOLEAN
server_ip ::= "server-ip" ":" STRING
server_port ::= "server-port" ":" INTEGER
sender_ip ::= "sender-ip" ":" STRING
sender_port ::= "sender-port" ":" INTEGER
max_queue_size ::= "max-queue-size" ":" INTEGER
ncr_protocol ::= "ncr-protocol" ":" ncr_protocol_value
ncr_protocol_value ::= "UDP"
| "TCP"
ncr_format ::= "ncr-format" ":" "JSON"
config_control ::= "config-control" ":" "{" config_control_params "}"
sub_config_control ::= "{" config_control_params "}"
config_control_params ::= config_control_param
| config_control_params "," config_control_param
| config_control_params ","
config_control_param ::= config_databases
| config_fetch_wait_time
config_databases ::= "config-databases" ":" "[" database_list "]"
config_fetch_wait_time ::= "config-fetch-wait-time" ":" INTEGER
loggers ::= "loggers" ":" "[" loggers_entries "]"
loggers_entries ::= logger_entry
| loggers_entries "," logger_entry
| loggers_entries ","
logger_entry ::= "{" logger_params "}"
logger_params ::= logger_param
| logger_params "," logger_param
| logger_params ","
logger_param ::= name
| output_options_list
| debuglevel
| severity
| user_context
| comment
| unknown_map_entry
debuglevel ::= "debuglevel" ":" INTEGER
severity ::= "severity" ":" STRING
output_options_list ::= "output-options" ":" "[" output_options_list_content "]"
output_options_list_content ::= output_entry
| output_options_list_content "," output_entry
| output_options_list_content ","
output_entry ::= "{" output_params_list "}"
output_params_list ::= output_params
| output_params_list "," output_params
| output_params_list ","
output_params ::= output
| flush
| maxsize
| maxver
| pattern
output ::= "output" ":" STRING
flush ::= "flush" ":" BOOLEAN
maxsize ::= "maxsize" ":" INTEGER
maxver ::= "maxver" ":" INTEGER
pattern ::= "pattern" ":" STRING
compatibility ::= "compatibility" ":" "{" compatibility_params "}"
compatibility_params ::= compatibility_param
| compatibility_params "," compatibility_param
| compatibility_params ","
compatibility_param ::= lenient_option_parsing
| unknown_map_entry
lenient_option_parsing ::= "lenient-option-parsing" ":" BOOLEAN
168u
این گرامر از d2_parser.yy تولید شده است. برای جزئیات بیشتر The DHCP-DDNS Server <#dhcp-ddns-server> را ببینید.
0.0
3.5
Grammar
$accept ::= start EOF
start ::= TOPLEVEL_JSON sub_json
start ::= TOPLEVEL_DHCPDDNS syntax_map
start ::= SUB_DHCPDDNS sub_dhcpddns
start ::= SUB_TSIG_KEY sub_tsig_key
start ::= SUB_TSIG_KEYS sub_tsig_keys
start ::= SUB_DDNS_DOMAIN sub_ddns_domain
start ::= SUB_DDNS_DOMAINS sub_ddns_domains
start ::= SUB_DNS_SERVER sub_dns_server
start ::= SUB_DNS_SERVERS sub_dns_servers
start ::= SUB_HOOKS_LIBRARY sub_hooks_library
value ::= INTEGER
| FLOAT
| BOOLEAN
| STRING
| NULL
| map2
| list_generic
sub_json ::= value
map2 ::= "{" map_content "}"
map_value ::= map2
map_content ::=
| not_empty_map
not_empty_map ::= STRING ":" value
| not_empty_map "," STRING ":" value
| not_empty_map ","
list_generic ::= "[" list_content "]"
list_content ::=
| not_empty_list
not_empty_list ::= value
| not_empty_list "," value
| not_empty_list ","
unknown_map_entry ::= STRING ":"
syntax_map ::= "{" global_object "}"
global_object ::= "DhcpDdns" ":" "{" dhcpddns_params "}"
| global_object_comma
global_object_comma ::= global_object ","
sub_dhcpddns ::= "{" dhcpddns_params "}"
dhcpddns_params ::= dhcpddns_param
| dhcpddns_params "," dhcpddns_param
| dhcpddns_params ","
dhcpddns_param ::= ip_address
| port
| dns_server_timeout
| ncr_protocol
| ncr_format
| forward_ddns
| reverse_ddns
| tsig_keys
| control_socket
| control_sockets
| hooks_libraries
| loggers
| user_context
| comment
| unknown_map_entry
ip_address ::= "ip-address" ":" STRING
port ::= "port" ":" INTEGER
dns_server_timeout ::= "dns-server-timeout" ":" INTEGER
ncr_protocol ::= "ncr-protocol" ":" ncr_protocol_value
ncr_protocol_value ::= "UDP"
| "TCP"
ncr_format ::= "ncr-format" ":" "JSON"
user_context ::= "user-context" ":" map_value
comment ::= "comment" ":" STRING
forward_ddns ::= "forward-ddns" ":" "{" ddns_mgr_params "}"
reverse_ddns ::= "reverse-ddns" ":" "{" ddns_mgr_params "}"
ddns_mgr_params ::=
| not_empty_ddns_mgr_params
not_empty_ddns_mgr_params ::= ddns_mgr_param
| ddns_mgr_params "," ddns_mgr_param
| ddns_mgr_params ","
ddns_mgr_param ::= ddns_domains
| unknown_map_entry
ddns_domains ::= "ddns-domains" ":" "[" ddns_domain_list "]"
sub_ddns_domains ::= "[" ddns_domain_list "]"
ddns_domain_list ::=
| not_empty_ddns_domain_list
not_empty_ddns_domain_list ::= ddns_domain
| not_empty_ddns_domain_list "," ddns_domain
| not_empty_ddns_domain_list ","
ddns_domain ::= "{" ddns_domain_params "}"
sub_ddns_domain ::= "{" ddns_domain_params "}"
ddns_domain_params ::= ddns_domain_param
| ddns_domain_params "," ddns_domain_param
| ddns_domain_params ","
ddns_domain_param ::= ddns_domain_name
| ddns_key_name
| dns_servers
| user_context
| comment
| unknown_map_entry
ddns_domain_name ::= "name" ":" STRING
ddns_key_name ::= "key-name" ":" STRING
dns_servers ::= "dns-servers" ":" "[" dns_server_list "]"
sub_dns_servers ::= "[" dns_server_list "]"
dns_server_list ::= dns_server
| dns_server_list "," dns_server
| dns_server_list ","
dns_server ::= "{" dns_server_params "}"
sub_dns_server ::= "{" dns_server_params "}"
dns_server_params ::= dns_server_param
| dns_server_params "," dns_server_param
| dns_server_params ","
dns_server_param ::= dns_server_hostname
| dns_server_ip_address
| dns_server_port
| ddns_key_name
| user_context
| comment
| unknown_map_entry
dns_server_hostname ::= "hostname" ":" STRING
dns_server_ip_address ::= "ip-address" ":" STRING
dns_server_port ::= "port" ":" INTEGER
tsig_keys ::= "tsig-keys" ":" "[" tsig_keys_list "]"
sub_tsig_keys ::= "[" tsig_keys_list "]"
tsig_keys_list ::=
| not_empty_tsig_keys_list
not_empty_tsig_keys_list ::= tsig_key
| not_empty_tsig_keys_list "," tsig_key
| not_empty_tsig_keys_list ","
tsig_key ::= "{" tsig_key_params "}"
sub_tsig_key ::= "{" tsig_key_params "}"
tsig_key_params ::= tsig_key_param
| tsig_key_params "," tsig_key_param
| tsig_key_params ","
tsig_key_param ::= tsig_key_name
| tsig_key_algorithm
| tsig_key_digest_bits
| tsig_key_secret
| tsig_key_secret_file
| user_context
| comment
| unknown_map_entry
tsig_key_name ::= "name" ":" STRING
tsig_key_algorithm ::= "algorithm" ":" STRING
tsig_key_digest_bits ::= "digest-bits" ":" INTEGER
tsig_key_secret ::= "secret" ":" STRING
tsig_key_secret_file ::= "secret-file" ":" STRING
control_socket ::= "control-socket" ":" "{" control_socket_params "}"
control_sockets ::= "control-sockets" ":" "[" control_socket_list "]"
control_socket_list ::=
| not_empty_control_socket_list
not_empty_control_socket_list ::= control_socket_entry
| not_empty_control_socket_list "," control_socket_entry
| not_empty_control_socket_list ","
control_socket_entry ::= "{" control_socket_params "}"
control_socket_params ::= control_socket_param
| control_socket_params "," control_socket_param
| control_socket_params ","
control_socket_param ::= control_socket_type
| control_socket_name
| control_socket_address
| control_socket_port
| authentication
| trust_anchor
| cert_file
| key_file
| cert_required
| user_context
| comment
| unknown_map_entry
control_socket_type ::= "socket-type" ":" control_socket_type_value
control_socket_type_value ::= "unix"
| "http"
| "https"
control_socket_name ::= "socket-name" ":" STRING
control_socket_address ::= "socket-address" ":" STRING
control_socket_port ::= "socket-port" ":" INTEGER
trust_anchor ::= "trust-anchor" ":" STRING
cert_file ::= "cert-file" ":" STRING
key_file ::= "key-file" ":" STRING
cert_required ::= "cert-required" ":" BOOLEAN
authentication ::= "authentication" ":" "{" auth_params "}"
auth_params ::= auth_param
| auth_params "," auth_param
| auth_params ","
auth_param ::= auth_type
| realm
| directory
| clients
| comment
| user_context
| unknown_map_entry
auth_type ::= "type" ":" auth_type_value
auth_type_value ::= "basic"
realm ::= "realm" ":" STRING
directory ::= "directory" ":" STRING
clients ::= "clients" ":" "[" clients_list "]"
clients_list ::=
| not_empty_clients_list
not_empty_clients_list ::= basic_auth
| not_empty_clients_list "," basic_auth
| not_empty_clients_list ","
basic_auth ::= "{" clients_params "}"
clients_params ::= clients_param
| clients_params "," clients_param
| clients_params ","
clients_param ::= user
| user_file
| password
| password_file
| user_context
| comment
| unknown_map_entry
user ::= "user" ":" STRING
user_file ::= "user-file" ":" STRING
password ::= "password" ":" STRING
password_file ::= "password-file" ":" STRING
hooks_libraries ::= "hooks-libraries" ":" "[" hooks_libraries_list "]"
hooks_libraries_list ::=
| not_empty_hooks_libraries_list
not_empty_hooks_libraries_list ::= hooks_library
| not_empty_hooks_libraries_list "," hooks_library
| not_empty_hooks_libraries_list ","
hooks_library ::= "{" hooks_params "}"
sub_hooks_library ::= "{" hooks_params "}"
hooks_params ::= hooks_param
| hooks_params "," hooks_param
| hooks_params ","
| unknown_map_entry
hooks_param ::= library
| parameters
library ::= "library" ":" STRING
parameters ::= "parameters" ":" map_value
loggers ::= "loggers" ":" "[" loggers_entries "]"
loggers_entries ::= logger_entry
| loggers_entries "," logger_entry
| loggers_entries ","
logger_entry ::= "{" logger_params "}"
logger_params ::= logger_param
| logger_params "," logger_param
| logger_params ","
logger_param ::= name
| output_options_list
| debuglevel
| severity
| user_context
| comment
| unknown_map_entry
name ::= "name" ":" STRING
debuglevel ::= "debuglevel" ":" INTEGER
severity ::= "severity" ":" STRING
output_options_list ::= "output-options" ":" "[" output_options_list_content "]"
output_options_list_content ::= output_entry
| output_options_list_content "," output_entry
| output_options_list_content ","
output_entry ::= "{" output_params_list "}"
output_params_list ::= output_params
| output_params_list "," output_params
| output_params_list ","
output_params ::= output
| flush
| maxsize
| maxver
| pattern
output ::= "output" ":" STRING
flush ::= "flush" ":" BOOLEAN
maxsize ::= "maxsize" ":" INTEGER
maxver ::= "maxver" ":" INTEGER
pattern ::= "pattern" ":" STRING
168u
این گرامر از netconf_parser.yy تولید شده است. برای جزئیات بیشتر به YANG/NETCONF <#netconf> مراجعه کنید.
0.0
3.5
Grammar
$accept ::= start EOF
start ::= START_JSON json
start ::= START_NETCONF netconf_syntax_map
start ::= START_SUB_NETCONF sub_netconf
sub_netconf ::= "{" global_params "}"
json ::= value
value ::= INTEGER
| FLOAT
| BOOLEAN
| STRING
| NULL
| map
| list_generic
map ::= "{" map_content "}"
map_value ::= map
map_content ::=
| not_empty_map
not_empty_map ::= STRING ":" value
| not_empty_map "," STRING ":" value
| not_empty_map ","
list_generic ::= "[" list_content "]"
list_content ::=
| not_empty_list
not_empty_list ::= value
| not_empty_list "," value
| not_empty_list ","
unknown_map_entry ::= STRING ":"
netconf_syntax_map ::= "{" global_object "}"
global_object ::= "Netconf" ":" "{" global_params "}"
| global_object_comma
global_object_comma ::= global_object ","
global_params ::=
| not_empty_global_params
not_empty_global_params ::= global_param
| not_empty_global_params "," global_param
| not_empty_global_params ","
global_param ::= boot_update
| subscribe_changes
| validate_changes
| managed_servers
| hooks_libraries
| loggers
| user_context
| comment
| unknown_map_entry
boot_update ::= "boot-update" ":" BOOLEAN
subscribe_changes ::= "subscribe-changes" ":" BOOLEAN
validate_changes ::= "validate-changes" ":" BOOLEAN
user_context ::= "user-context" ":" map_value
comment ::= "comment" ":" STRING
hooks_libraries ::= "hooks-libraries" ":" "[" hooks_libraries_list "]"
hooks_libraries_list ::=
| not_empty_hooks_libraries_list
not_empty_hooks_libraries_list ::= hooks_library
| not_empty_hooks_libraries_list "," hooks_library
| not_empty_hooks_libraries_list ","
hooks_library ::= "{" hooks_params "}"
hooks_params ::= hooks_param
| hooks_params "," hooks_param
| hooks_params ","
| unknown_map_entry
hooks_param ::= library
| parameters
library ::= "library" ":" STRING
parameters ::= "parameters" ":" map_value
managed_servers ::= "managed-servers" ":" "{" servers_entries "}"
servers_entries ::=
| not_empty_servers_entries
not_empty_servers_entries ::= server_entry
| not_empty_servers_entries "," server_entry
| not_empty_servers_entries ","
server_entry ::= dhcp4_server
| dhcp6_server
| d2_server
| unknown_map_entry
dhcp4_server ::= "dhcp4" ":" "{" managed_server_params "}"
dhcp6_server ::= "dhcp6" ":" "{" managed_server_params "}"
d2_server ::= "d2" ":" "{" managed_server_params "}"
managed_server_params ::= managed_server_param
| managed_server_params "," managed_server_param
| managed_server_params ","
managed_server_param ::= model
| boot_update
| subscribe_changes
| validate_changes
| control_socket
| user_context
| comment
| unknown_map_entry
model ::= "model" ":" STRING
control_socket ::= "control-socket" ":" "{" control_socket_params "}"
control_socket_params ::= control_socket_param
| control_socket_params "," control_socket_param
| control_socket_params ","
control_socket_param ::= socket_type
| socket_name
| socket_url
| user_context
| comment
| unknown_map_entry
socket_type ::= "socket-type" ":" socket_type_value
socket_type_value ::= "unix"
| "http"
| "stdout"
socket_name ::= "socket-name" ":" STRING
socket_url ::= "socket-url" ":" STRING
loggers ::= "loggers" ":" "[" loggers_entries "]"
loggers_entries ::= logger_entry
| loggers_entries "," logger_entry
| loggers_entries ","
logger_entry ::= "{" logger_params "}"
logger_params ::= logger_param
| logger_params "," logger_param
| logger_params ","
logger_param ::= name
| output_options_list
| debuglevel
| severity
| user_context
| comment
| unknown_map_entry
name ::= "name" ":" STRING
debuglevel ::= "debuglevel" ":" INTEGER
severity ::= "severity" ":" STRING
output_options_list ::= "output-options" ":" "[" output_options_list_content "]"
output_options_list_content ::= output_entry
| output_options_list_content "," output_entry
| output_options_list_content ","
output_entry ::= "{" output_params_list "}"
output_params_list ::= output_params
| output_params_list "," output_params
| output_params_list ","
output_params ::= output
| flush
| maxsize
| maxver
| pattern
output ::= "output" ":" STRING
flush ::= "flush" ":" BOOLEAN
maxsize ::= "maxsize" ":" INTEGER
maxver ::= "maxver" ":" INTEGER
pattern ::= "pattern" ":" STRING
168u
پروژه Kea یک پروژه متن‌باز است که توسط Internet Systems Consortium, Inc، یک سازمان غیرانتفاعی 501(c)3 طراحی، توسعه یافته و نگهداری می‌شود. بودجه ISC عمدتاً از طریق درآمدهای حاصل از اشتراک‌های پشتیبانی برای نرم‌افزارهای متن‌باز تأمین می‌شود و ما همه کاربران حرفه‌ای را تشویق می‌کنیم که این گزینه را در نظر بگیرند. برای اطلاعات بیشتر، https://www.isc.org/support را مشاهده کنید.
ما از تمامی سازمان‌ها و افرادی که در تحقق Kea یاری رسانده‌اند سپاسگزاری می‌کنیم. شرکت Comcast https://www.comcast.com و Comcast Innovation Fund پشتیبانی عمده‌ای را برای توسعه ماژول‌های DHCPv4، DHCPv6 و DDNS نرم‌افزار Kea فراهم کردند. همچنین Mozilla هزینه کارهای اولیه روی RESTful API را از طریق یک جایزه MOSS تأمین مالی نمود.
نرم‌افزار Kea در ابتدا به عنوان مجموعه‌ای از برنامه‌ها در چارچوب BIND 10 پیاده‌سازی شد. از حامیان مالی مؤسس پروژه BIND 10 سپاسگزاری می‌کنیم: Afilias https://www.afilias.info،
IIS.SE https://www.iis.se،
Nominet https://www.nominet.uk،
SIDN https://www.sidn.nl، JPRS https://jprs.co.jp
و CIRA https://cira.ca؛ و همچنین حامیان مالی دیگر:
AFNIC https://www.afnic.fr،
CNNIC https://www.cnnic.net.cn، CZ.NIC https://www.nic.cz،
DENIC eG https://www.denic.de،
Google https://www.google.com، RIPE
NCC https://www.ripe.net، Registro.br https://registro.br،
.nz Registry Services https://nzrs.net.nz، و Technical Center
of Internet https://www.tcinet.ru.
"نویسندگان (AUTHORS)"
Internet Systems Consortium
"کپی‌رایت و تکثیر (COPYRIGHT)"
2019-2026, Internet Systems Consortium
July 9, 2026 3.2.0