.TH keepalived.conf 5 2026-07-05 "Keepalived" "Keepalived Configuration's Manual"
.SH "نام (NAME)"
keepalived.conf \- پرونده پیکربندی keepalived
.br
.PP
.SH "یادداشت: (Note:)"
این مستندات باید به عنوان منبع جامع و مرجع اطلاعات برای پیکربندی Keepalived در نظر گرفته شود. این مستندات توسط تیم اصلی Keepalived پشتیبانی و نگهداری می‌شود.
.PP
.SH "توضیحات (DESCRIPTION)"
پرونده \fBkeepalived.conf\fR پرونده پیکربندی است که تمام کلیدواژه‌های Keepalived را شرح می‌دهد. کلیدواژه‌ها در سلسله‌مراتبی از بلوک‌ها و زیربلوک‌ها قرار می‌گیرند که هر لایه با جفت‌های '{' و '}' مشخص می‌شود.
.PP
توضیحات با '#' یا '!' تا انتهای خط آغاز می‌شوند و می‌توانند از هر کجای خط شروع شوند.
.PP
کلیدواژه 'include' و گونه‌های آن امکان گنجاندن پرونده‌های پیکربندی دیگر را از درون پرونده پیکربندی اصلی یا از پرونده‌های گنجانده‌شده بعدی فراهم می‌کنند.
.PP
قالب دستور include به شرح زیر است:

\fBinclude\fR FILENAME
.PP
مقدار FILENAME می‌تواند یک مسیر کامل یا نسبی باشد و شامل نویسه‌های عام (wildcard)، از جمله عبارات کروشه‌ای سبک csh مانند "{foo/{,cat,dog},bar}" در صورت پشتیبانی glob() باشد.
.PP
پس از باز کردن یک پرونده گنجانده‌شده، دایرکتوری جاری به دایرکتوری خود آن پرونده تنظیم می‌شود؛ بنابراین هر مسیر نسبی گنجانده‌شده از یک پرونده، نسبت به دایرکتوری خود همان پرونده در نظر گرفته می‌شود.

گونه‌های include بررسی‌های بیشتری را به سطح include_check جاری اضافه می‌کنند (زیر را ببینید)
گونه‌ها عبارتند از:
.br
\fBincluder\fR FILENAME \- همانند include_check readable
.br
\fBincludem\fR FILENAME \- همانند include_check match
.br
\fBincludew\fR FILENAME \- همانند include_check wildcard_match
.br
\fBincludeb\fR FILENAME \- همانند include_check brace_match
.br
\fBincludea\fR FILENAME \- تمام بررسی‌های include_check
.PP
نکته: اگر تابع glob() در libc از GLOB_ALTDIRFUNC پشتیبانی نکند (مانند Musl libc در Alpine Linux و غیره)، تنها گزینه‌های includea، includer و includew از میان موارد بالا کار خواهند کرد.
.PP
چرا می‌خواهیم خطاها مجاز باشند؟ فرض کنید یک پیکربندی دارای پرونده‌های اختیاری در /etc/keepalived/conf.d باشد، در این صورت می‌توان \fIinclude_/etc/keepalived/conf.d/*\fR را مشخص کرد، اما اگر پرونده‌ای در دایرکتوری وجود نداشته باشد نباید خطایی رخ دهد؛ در چنین حالتی باید از \fIincluder\fR استفاده شود. در غیر این صورت، استفاده از \fIincludea\fR منطقی است.

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

کلیدواژه پایه‌ای \fIinclude\fR برای سازگاری با گذشته حفظ شده است، زیرا در صورت عدم امکان باز کردن پرونده‌ها و موارد مشابه، خطای پیکربندی ایجاد نمی‌کند.
.PP
.SH "نحو پارامترها (PARAMETER SYNTAX)"
\fB<BOOL>\fR
یکی از مقادیر on|off|true|false|yes|no است.
.br
\fB<TIMER>\fR
یک مقدار زمانی بر حسب ثانیه است، شامل بخش اعشاری ثانیه، مانند 2.71828 یا 3؛ دقت زمان‌سنج بر حسب میکروثانیه است.
.SH "اسکریپت‌ها (SCRIPTS)"
سه دسته از اسکریپت‌ها را می‌توان برای اجرا پیکربندی کرد.

(a) اسکریپت‌های اعلان (Notify) که هنگام تغییر وضعیت یک نمونه vrrp یا گروه vrrp، یا تغییر حد نصاب (quorum) یک سرور مجازی بین بالا (up) و پایین (down) اجرا می‌شوند.

(b) اسکریپت‌های ردیابی vrrp (vrrp tracking scripts) که در صورت خروج با وضعیت غیر صفر، باعث پایین رفتن (down) نمونه‌های vrrp می‌شوند، یا اگر یک وزن (weight) مشخص شده باشد، آن وزن را به اولویت (priority) آن نمونه vrrp اضافه یا از آن کم می‌کنند.

(c) اسکریپت‌های متفرقه بررسی‌کننده LVS (LVS checker misc scripts) که در صورت خروج با وضعیتی غیر صفر، باعث می‌شوند وضعیت سرور واقعی (real server) به صورت پایین (down) پیکربندی شود.

به‌طور پیش‌فرض، اسکریپت‌ها توسط کاربر keepalived_script (در صورت وجود این کاربر) اجرا می‌شوند، وگرنه توسط root اجرا خواهند شد؛ اما برای هر اسکریپت می‌توان کاربر/گروهی (user/group) را که باید تحت آن اجرا شود مشخص کرد.

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

همه اسکریپت‌ها باید به گونه‌ای نوشته شوند که با دریافت سیگنال SIGTERM خاتمه یابند. در صورتی که فرایند والد خاتمه یابد، یا اسکریپتی باشد که keepalived منتظر وضعیت خروج آن است و بیش از حد طول کشیده باشد، سیگنال SIGTERM به اسکریپت ارسال خواهد شد.
.PP
.SH "رشته‌های نقل‌قول‌شده (Quoted strings)"
رشته‌های نقل‌قول‌شده بین نویسه‌های " یا ' مشخص می‌شوند و رشته‌ها با فاصله‌های سفید (whitespace) از یکدیگر جدا می‌شوند. در مثال‌های زیر نویسه‌های \' بخشی از رشته‌ها نیستند و نباید درج شوند:

.nf
.RS
\'abcd" efg h jkl "mnop\'
.RE

.fi
تبدیل به رشته تکی زیر خواهد شد:

.nf
.RS
\'abcd efg h jkl mnop\'
.RE

در حالی که:

.nf
.RS
\'abcd "efg h jkl" mnop\'
.RE
.fi

تبدیل به این سه رشته خواهد شد:

.nf
.RS
\'abcd\', \'efg h jkl\' and \'mnop\'
.RE

بدین معنی که نویسه‌های " و ' حذف شده و هرگونه فاصله سفید بین آن‌ها حفظ می‌شود.
.PP
رشته‌های نقل‌قول‌شده همچنین می‌توانند مانند شل شامل نویسه‌های گریز (escaped characters) باشند. موارد \\a، \\b، \\E، \\f، \\n، \\r، \\t، \\v، \\nnn و \\xXX (که در آن nnn حداکثر ۳ رقم هشت‌هشتی، و XX حداکثر دو رقم شانزده‌شانزدهی است) و \\cC (که نسخه کنترلی نویسه C را تولید می‌کند) همگی پشتیبانی می‌شوند. \\C برای هر نویسه دیگر C صرفاً به عنوان نسخه گریزخورده نویسه C در نظر گرفته می‌شود، بنابراین \\\\ یک نویسه \\ است و \\" یک نویسه " خواهد بود، اما رشته نقل‌قول‌شده را شروع یا تمام نمی‌کند.
.PP
برای مشخص کردن اسکریپت‌ها با پارامترها، فاصله‌های بدون نقل‌قول پارامترها را از هم جدا می‌کنند. اگر لازم باشد که یک پارامتر حاوی فاصله باشد، باید در نقل‌قول تکی (') محصور شود. برای نمونه

.nf
.RS
$SG_NAME=SG1
$INST=low
$USER=user
notify_master "/etc/keepalived/notify_event.sh ' spaces\\\\x20f\\x69le ' '\\"s p a c e \\"' ${SG_NAME}.$INST master" $USER group
.RE

.fi
اسکریپت notify_master با مسیر /etc/keepalived/notify_event.sh را مشخص می‌کند که با کاربر:گروه user:group و با پارامترهای زیر اجرا خواهد شد:

.nf
.RS
\' spaces\\x20file \', \'"s p a c e "\', \'SG1.low\' and \'master\'
.RE

.fi
.PP
.SH "تجزیه‌کننده پیکربندی (CONFIGURATION PARSER)"
به‌طور سنتی تجزیه‌کننده پرونده پیکربندی یکی از نقاط قوت keepalived نبوده است. تلاش‌های زیادی برای اصلاح این موضوع انجام شده است، حتی اگر این هدف اصلی پروژه نباشد.
.SH "سلسله‌مراتب سطح بالا (TOP HIERARCHY)"
.PP
پرونده پیکربندی Keepalived حول مجموعه‌ای از بلوک‌های پیکربندی سازمان‌یافته است. هر بلوک بر روی ویژگی مشخصی از خانواده دیمن‌ها تمرکز و هدف‌گذاری دارد. این ویژگی‌ها عبارتند از:
.PP
\fBGLOBAL CONFIGURATION\fR
.PP
\fBBFD CONFIGURATION\fR
.PP
\fBVRRPD CONFIGURATION\fR
.PP
\fBLVS CONFIGURATION\fR
.SH "پیکربندی عمومی (GLOBAL CONFIGURATION)"
شامل زیربلوک‌های زیر است:
\fBGlobal definitions،
Linkbeat interfaces،
Interface up/down transition delays،
Static track groups،
Static addresses،
Static routes\fR
و
\fBStatic rules\fR
.PP
.SH "تعاریف عمومی (Global definitions)"
.PP
.nf
# موارد زیر امکانات عمومی دیمن برای اجرای keepalived
# در یک network namespace جداگانه هستند:
# --
# تنظیم network namespace برای اجرا در آن.
# شاخه /run/keepalived به عنوان یک نقطه اتصال unshared ایجاد خواهد شد،
# برای نمونه برای پرونده‌های pid.
# شناسه‌های syslog مقدار NAME_ را در انتهای نام شناسه خواهند داشت.
# نکته: namespace هنگام بارگذاری مجدد پیکربندی (reload) قابل تغییر نیست.
\fBnet_namespace \fRNAME

# افزودن پیکربندی IPVS در net namespace مشخص‌شده. این گزینه امکان تفکیک آسان
# ترافیک VIP روی یک namespace مشخص و نگه‌داشتن ترافیک healthchecks در
# namespace دیگر را فراهم می‌کند. اگر NAME مشخص نشود، از namespace پیش‌فرض
# استفاده خواهد شد.
\fBnet_namespace_ipvs \fRNAME

# قابلیت ipsets تا لینوکس 3.13 از network namespace آگاه نبود، بنابراین
# در صورت اجرا با نسخه قدیمی‌تر هسته، در صورت استفاده از یک namespace و
# مشخص نشدن vrrp_ipsets، استفاده از ipsets به‌طور پیش‌فرض غیرفعال است.
# این گزینه مقدار پیش‌فرض را لغو کرده و اجازه می‌دهد ipsets با یک namespace
# در هسته‌های قبل از 3.13 استفاده شود.
\fBnamespace_with_ipsets\fR

# اگر چندین نمونه از keepalived در همان namespace اجرا شوند،
# این گزینه پرونده‌های pid را با NAME به عنوان بخشی از نام پرونده،
# در /run/keepalived ایجاد می‌کند.
# نکته: نام نمونه هنگام بارگذاری مجدد پیکربندی قابل تغییر نیست
\fBinstance \fRNAME

# ایجاد پرونده‌های pid در /run/keepalived
\fBuse_pid_dir\fR

# نظرسنجی (Poll) برای تشخیص خرابی پیوند رسانه با استفاده از رابط ETHTOOL، MII یا ioctl؛
# در غیر این صورت از رابط netlink استفاده می‌کند.
\fBlinkbeat_use_polling\fR

# مدت‌زمان به ثانیه برای فرایند اصلی جهت مهلت دادن به خروج فرایندهای فرزند هنگام خاتمه.
# این مقدار ممکن است برای پیکربندی‌های بسیار بزرگ لازم باشد.
# (پیش‌فرض: 5)
\fBchild_wait_time \fRSECS

یادداشت: تمامی فرایندها/اسکریپت‌های اجراشده توسط keepalived با سیگنال مرگ والد تنظیم‌شده روی
SIGTERM اجرا می‌شوند. تمامی این فرایندها/اسکریپت‌ها یا نباید کنش مربوط به SIGTERM را تغییر دهند،
یا باید اطمینان حاصل کنند که فرایند/اسکریپت پس از دریافت SIGTERM، احتمالاً پس از انجام هرگونه
عملیات پاکسازی لازم، خاتمه می‌یابد.

# بلوک پیکربندی تعاریف عمومی
\fBglobal_defs \fR{
    # به منظور اطمینان از اینکه همه فرایندها دقیقاً همان پیکربندی یکسان را می‌خوانند،
    # هنگام خواندن اولیه پیکربندی، به‌طور پیش‌فرض در یک پرونده مبتنی بر حافظه نوشته می‌شود
    # (یا در صورت عدم پشتیبانی از ()memfd_create در یک پرونده ناشناس در /tmp/).
    # اگر پیکربندی شما بسیار بزرگ است، ممکن است نخواهید نسخه کپی در حافظه نگه‌داری شود؛
    # در این حالت، مشخص کردن \fItmp_config_directory\fR باعث می‌شود پیکربندی در یک پرونده ناشناس
    # روی سیستم‌فایلی که شاخه مشخص‌شده در آن قرار دارد نوشته شود، که باید توسط keepalived قابل نوشتن باشد.
    # این تنظیم در reload قابل تغییر نیست و باید تا حد امکان در ابتدای پیکربندی مشخص شود.
    \fBtmp_config_directory\fR DIRECTORY

    # گزینه config_save_dir باعث می‌شود keepalived وضعیت پیکربندی و پرونده‌های پیکربندی را
    # قبل و بعد از هر reload ذخیره کند. این برای مقاصد اشکال‌زدایی در صورت وجود مشکلات
    # مربوط به reloadهای مکرر استفاده می‌شود. شاخه در صورت عدم وجود ایجاد خواهد شد،
    # اما تمامی شاخه‌های والد باید از قبل وجود داشته باشند.
    \fBconfig_save_dir\fR DIRECTORY

    # تنظیم نام فرایندهای keepalived به مقادیر پیش‌فرض:
    #   keepalived, keepalived_vrrp, keepalived_ipvs, keepalived_bfd
    \fBprocess_names\fR

    # تعیین نام‌های تکی فرایندها
    \fBprocess_name\fR NAME
    \fBvrrp_process_name\fR NAME
    \fBchecker_process_name\fR NAME
    \fBbfd_process_name\fR NAME

    # برنامه keepalived به‌طور پیش‌فرض مسیرهای اسکریپت را برای حذف پیوندهای نمادین (symlinks) حل می‌کند.
    # برای نگه‌داشتن symlinkها در نام مسیرها، use_symlink_paths را مشخص کنید.
    \fBuse_symlink_paths \fR[<BOOL>]

    # اسکریپت‌های startup و shutdown به ترتیب یک بار هنگام شروع keepalived قبل از اجرای هرگونه
    # فرایند فرزند، و هنگام توقف keepalived پس از خاتمه همه فرایندهای فرزند اجرا می‌شوند.
    # انگیزه اصلی افزودن این ویژگی این بود که گرچه keepalived می‌تواند پیکربندی IPVS را با استفاده از
    # نشانه‌های فایروال (firewall marks) راه‌اندازی کند، هیچ سازوکاری برای افزودن پیکربندی جهت تنظیم
    # نشانه‌های فایروال (یا حذف آن پس از آن) وجود نداشت.
    # این ویژگی همچنین می‌تواند برای راه‌اندازی ساختار iptables مورد نیاز در صورت استفاده از iptables
    # (گزینه vrrp_iptables زیر را ببینید)، تغییر تنظیمات رابط، یا هر کار دیگری که از طریق یک اسکریپت یا برنامه
    # قابل انجام باشد، استفاده شود.
    # تنها یک اسکریپت startup و یک اسکریپت shutdown می‌تواند مشخص شود.
    # مهلت‌های زمانی (بر حسب ثانیه، پیش‌فرض 10 ثانیه) زمان مجاز برای اجرای اسکریپت‌ها هستند؛
    # اگر مهلت زمانی به پایان برسد، اسکریپت‌ها متوقف (kill) خواهند شد (این برای جلوگیری از معلق ماندن keepalived
    # در انتظار خاتمه اسکریپت‌ها است).
    \fBstartup_script\fR SCRIPT_NAME [username [groupname]]
    \fBstartup_script_timeout\fR SECONDS    # بازه [1,1000]
    \fBshutdown_script\fR SCRIPT_NAME [username [groupname]]
    \fBshutdown_script_timeout\fR SECONDS   # بازه [1,1000]

    # مجموعه‌ای از نشانی‌های ایمیل مقصد (:To) برای اطلاع‌رسانی. برای گنجاندن نام نمایشی،
    # کل نشانی ایمیل باید درون علامت نقل‌قول دوتایی (") قرار گیرد.
    \fBnotification_email \fR{
        admin@example1.com "My admin <admin@example2.com>"
        ...
    }

    # نشانی فرستنده ایمیل (from) که در سرآیند قرار خواهد گرفت (برای گنجاندن نام نمایشی
    # توضیح بالا را ببینید).
    # (پیش‌فرض: keepalived@local_host_name)
    \fBnotification_email_from \fRadmin@example.com

    # کارگزار دوردست SMTP مورد استفاده برای ارسال ایمیل اطلاع‌رسانی.
    # نشانی IP یا نام دامنه با شماره درگاه اختیاری.
    # (شماره درگاه پیش‌فرض: 25)
    \fBsmtp_server \fR127.0.0.1 [<PORT>]

    # نام مورد استفاده در پیام‌های HELO.
    # (پیش‌فرض: نام میزبان محلی)
    \fBsmtp_helo_name \fR<STRING>

    # مهلت زمانی اتصال به کارگزار SMTP بر حسب ثانیه.
    \fBsmtp_connect_timeout \fR30

    # تنظیم وضعیت پیش‌فرض برای همه smtp_alertها
    \fBsmtp_alert \fR<BOOL>

    # تنظیم وضعیت پیش‌فرض برای smtp_alertهای vrrp
    \fBsmtp_alert_vrrp \fR<BOOL>

    # تنظیم وضعیت پیش‌فرض برای smtp_alertهای checker
    \fBsmtp_alert_checker \fR<BOOL>

    # ثبت هر بررسی ناموفق real server در syslog
    # (با این حال، هشدار SMTP تنها زمانی ارسال می‌شود که تمام بررسی‌های مجدد ناموفق باشند
    # و real server به وضعیت DOWN تغییر حالت دهد)
    \fBchecker_log_all_failures \fR<BOOL>

    # عدم ارسال هشدارهای smtp برای شرایط خطا (fault)
    \fBno_email_faults\fR

    # رشته شناسایی دستگاه (نیازی نیست نام میزبان باشد).
    # (پیش‌فرض: نام میزبان محلی)
    \fBrouter_id \fR<STRING>

    # گروه چندپخشی (Multicast Group) مورد استفاده برای اعلان‌های IPv4 VRRP
    # پیش‌فرض آن نشانی چندپخشی VRRP تخصیص‌یافته توسط RFC5798 IANA یعنی 224.0.0.18 است
    # که معمولاً نمی‌خواهید آن را تغییر دهید.
    \fBvrrp_mcast_group4 \fR224.0.0.18

    # گروه چندپخشی مورد استفاده برای اعلان‌های IPv6 VRRP
    # (پیش‌فرض: ff02::12)
    \fBvrrp_mcast_group6 \fRff02::12

    # تنظیم رابط پیش‌فرض برای نشانی‌های ایستا.
    # (پیش‌فرض: eth0)
    \fBdefault_interface \fRp33p1.3

    # دیمن همگام‌سازی همان‌طور که توسط کد هسته IPVS ارائه شده، در هر لحظه تنها از یک نمونه
    # دیمن master و یک نمونه دیمن backup برای همگام‌سازی جدول اتصالات IPVS پشتیبانی می‌کند.
    # برای جزئیات بیشتر درباره دیمن همگام‌سازی، صفحه راهنمای ipvsadm(8) را ببینید.
    # پارامترها عبارتند از رابط متصل‌شونده، و موارد اختیاری:
    #  inst VRRP_INSTANCE (برای سازگاری با گذشته می‌توان inst را حذف کرد)
    #  syncid (از 0 تا 255) برای lvs syncd، پیش‌فرض VRID نمونه vrrp است،
    #    یا در صورت عدم وجود نمونه vrrp مقدار 0
    #  maxlen (از 1 تا 65507) حداکثر طول بسته (محدودیت mtu - 20 - 8 است)
    #  port (از 1 تا 65535) شماره درگاه UDP مورد استفاده، پیش‌فرض 8848
    #  ttl (از 1 تا 255)
    #  group - نشانی گروه چندپخشی (IPv4 یا IPv6)، پیش‌فرض 224.0.0.81
    # اگر VRRP_INSTANCE مشخص نشود، تا زمانی که keepalived در حال اجرا است هر دو دیمن همگام‌سازی
    # master و backup اجرا خواهند شد، در غیر این صورت وضعیت master/backup دیمن همگام‌سازی
    # وضعیت نمونه vrrp مشخص‌شده را ردیابی می‌کند: اگر نمونه vrrp در وضعیت master باشد،
    # تنها دیمن همگام‌سازی master اجرا خواهد شد، و اگر نمونه vrrp در وضعیت master نباشد،
    # تنها دیمن همگام‌سازی backup اجرا خواهد شد.
    # نکته: maxlen، port، ttl و group تنها در لینوکس 4.3 یا جدیدتر در دسترس هستند.
    # برای جزئیات پارامترهای کنترل‌کننده IPVS و دیمن همگام‌سازی، مستندات سورس هسته
    # doc/Documentation/networking/ipvs-sysctl.txt را ببینید.
    # مسیر *proc/net/ip_vs/ جزئیاتی درباره وضعیت IPVS ارائه می‌دهد.
    \fBlvs_sync_daemon \fR<INTERFACE> [[inst] <VRRP_INSTANCE>] [id <SYNC_ID>] \e
                    [maxlen <LEN>] [port <PORT>] [ttl <TTL>] [group <IP ADDR>]

    # گزینه lvs_timeouts مهلت‌های زمانی ردیابی اتصال tcp، tcp_fin و udp را
    # بر حسب ثانیه مشخص می‌کند. حداقل یک مقدار باید مشخص شود؛ مشخص نکردن مقدار، آن را
    # نسبت به زمان شروع keepalived بدون تغییر باقی می‌گذارد.
    \fBlvs_timeouts\fR [tcp SECS] [tcpfin SECS] [udp SECS]

    # پاکسازی (flush) هرگونه پیکربندی موجود LVS در هنگام راه‌اندازی
    \fBlvs_flush\fR

    # پاکسازی پیکربندی باقی‌مانده LVS هنگام متوقف شدن (برای پیکربندی‌های بزرگ
    # این روش بسیار سریع‌تر از رویکرد پیش‌فرض حذف تک‌تک RSها و VSها است).
    # اگر VS مشخص شود، هر سرور مجازی تحت مدیریت keepalived بدون حذف صریح
    # real serverها حذف می‌شود (هسته آن‌ها را حذف خواهد کرد).
    \fBlvs_flush_on_stop [VS]\fR

    # تعداد پیام‌های ARP بی‌دلیل (gratuitous ARP) برای ارسال در یک نوبت پس از
    # انتقال به MASTER.
    # (پیش‌فرض: 5)
    \fBvrrp_garp_master_repeat \fR1

    # تأخیر برای دسته دوم ARPهای بی‌دلیل پس از انتقال به MASTER.
    # بر حسب ثانیه، 0 برای عدم ارسال دسته دوم.
    # (پیش‌فرض: 5)
    \fBvrrp_garp_master_delay \fR10

    # تعداد پیام‌های ARP بی‌دلیل برای ارسال در یک نوبت پس از
    # دریافت اعلان با اولویت پایین‌تر در وضعیت MASTER.
    # (پیش‌فرض: vrrp_garp_master_repeat)
    \fBvrrp_garp_lower_prio_repeat \fR1

    # تأخیر برای دسته دوم ARPهای بی‌دلیل پس از دریافت اعلان با اولویت
    # پایین‌تر در وضعیت MASTER.
    # (پیش‌فرض: vrrp_garp_master_delay)
    \fBvrrp_garp_lower_prio_delay \fR10

    # حداقل فاصله زمانی برای تازه‌سازی ARPهای بی‌دلیل در وضعیت MASTER.
    # بر حسب ثانیه (دقت بر حسب ثانیه).
    # (پیش‌فرض: 0 (بدون تازه‌سازی))
    \fBvrrp_garp_master_refresh \fR60

    # تعداد پیام‌های ARP بی‌دلیل برای ارسال در هر نوبت در وضعیت MASTER
    # (پیش‌فرض: 1)
    \fBvrrp_garp_master_refresh_repeat \fR2

    # تأخیر بین پیام‌های ARP بی‌دلیل ارسالی روی یک رابط
    # اعشاری، بر حسب ثانیه (دقت میکروثانیه).
    # (پیش‌فرض: 0)
    \fBvrrp_garp_interval \fR0.001

    # تأخیر بین پیام‌های اعلان همسایه ناخواسته (unsolicited NA) ارسالی روی یک رابط
    # اعشاری، بر حسب ثانیه (دقت میکروثانیه).
    # (پیش‌فرض: 0)
    \fBvrrp_gna_interval \fR0.000001

    # به‌طور پیش‌فرض keepalived تعداد 5 پیام ARP/NA بی‌دلیل را در یک نوبت ارسال می‌کند،
    # و پس از انتقال به MASTER، بلوک دوم حاوی 5 پیام را 5 ثانیه بعد ارسال می‌نماید.
    # با سوئیچ‌های امروزی این کار غیرضروری است، بنابراین تنظیم vrrp_min_garp
    # باعث می‌شود تنها یک پیام ARP/NA ارسال شود، بدون تکرار 5 ثانیه بعد.
    \fBvrrp_min_garp \fR[<BOOL>]

    # گزینه زیر باعث ارسال دوره‌ای پیام‌های GARP/NA روی رابط‌های مربوط به VIPها/eVIPهایی می‌شود
    # که رابط نمونه VRRP نیستند، تا از به‌روز ماندن حافظه موقت MAC سوئیچ‌ها اطمینان حاصل شود
    # (مشخص‌شده بر حسب ثانیه).
    # بسیاری از سوئیچ‌ها دارای مهلت زمانی پیش‌فرض 300 ثانیه برای حافظه موقت هستند، بنابراین
    # نرخ تکرار garp معادل یک‌سوم آن منطقی خواهد بود. حداکثر مقدار مجاز 1 روز (86400 ثانیه) است؛
    # به‌طور پیش‌فرض، فقط روی رابط‌های VMAC ارسال می‌شود؛ مشخص کردن \fBall\fR
    # باعث ارسال GARP/NA روی هر رابط مورد استفاده توسط نمونه VRRP خواهد شد.
    \fBvrrp_garp_extra_if [all] \fR100

    # مقدار پیش‌فرض برای down_timer_adverts در vrrp.
    \fBvrrp_down_timer_adverts \fR[1:100]

    # در صورت دریافت اعلان با اولویت پایین‌تر، اعلان دیگری ارسال نشود.
    # این باعث پیروی از RFCهای قبل از RFC9568 می‌شود.
    # پیش‌فرض false است، مگر اینکه strict_mode تنظیم شده باشد.
    \fBvrrp_lower_prio_no_advert \fR[<BOOL>]

    # اگر master باشیم و اعلانی با اولویت بالاتر دریافت کنیم، قبل از انتقال به backup،
    # یک اعلان (که اولویت آن کمتر از master دیگر خواهد بود) ارسال می‌کنیم. بدین معنا که اگر master دیگر
    # گزینه garp_lower_priority_repeat را تنظیم کرده باشد، پیام‌های garp را مجدداً ارسال خواهد کرد.
    # این برای دور زدن مشکل وجود دو master هم‌زمان و مشاهده آخرین پیام‌های GARP از سوی ما است.
    \fBvrrp_higher_prio_send_advert \fR[<BOOL>]

    # تعیین نسخه پیش‌فرض VRRP برای استفاده
    # (پیش‌فرض: 2، اما نمونه‌های IPv6 از نسخه 3 استفاده خواهند کرد)
    \fBvrrp_version \fR<2 or 3>

    # توضیحات V3_checksum_as_V2 در vrrp_instance را ببینید
    \fBv3_checksum_as_v2\fR [<BOOL>]

    # برنامه keepalived از یک فایروال (nftables یا iptables) برای دو منظور استفاده می‌کند:
    #  1) پیاده‌سازی حالت no_accept
    #  2) متوقف کردن ارسال بسته‌های IGMP/MLD/Router-Solicit روی رابط‌های VMAC،
    #     و انتقال پیام‌های IGMP/MLD به رابط زیرین (underlying).
    # اگر هر دو گزینه vrrp_iptables و vrrp_nftables مشخص شوند، keepalived از nftables استفاده می‌کند و نه iptables.
    # به همین ترتیب، اگر دستور iptables در حال تولید پیکربندی nftables باشد، یا هیچ دستور iptables نصب نشده باشد،
    # keepalived به جای iptables از nftables استفاده خواهد کرد.
    # اگر هیچ‌یک از vrrp_nftables یا vrrp_iptables مشخص نشده باشند اما VMACها در حال استفاده باشند
    # یا no_accept مشخص شده باشد، keepalived در صورت در دسترس بودن از nftables استفاده خواهد کرد.

    # استفاده از nftables به عنوان فایروال.
    #   TABLENAME نباید وجود داشته باشد، و باید برای هر نمونه از keepalived
    #   که در همان network namespace اجرا می‌شود متفاوت باشد.
    #   نام جدول پیش‌فرض keepalived و اولویت 1- است.
    #   برنامه keepalived زنجیره‌های پایه را در جدول ایجاد خواهد کرد.
    #   گزینه counters به این معناست که شمارنده‌ها به قوانین اضافه می‌شوند (عمدتاً برای اهداف اشکال‌زدایی).
    #   گزینه ifindex یعنی ایجاد مجموعه‌های IPv6 link local با استفاده از ifindex به جای ifnames.
    #   این حالت پیش‌فرض است مگر اینکه vrrp_instance گزینه dont_track_primary را تنظیم کرده باشد.
    #   راهکار جایگزین استفاده از نام رابط‌ها به عنوان بخشی از کلید مجموعه است، اما ابزار nft قبل از
    #   نسخه v0.8.3 در این حالت نام رابط‌ها را به‌درستی خروجی نمی‌دهد.
    \fBnftables \fR[TABLENAME]
    \fBnftables_priority \fRPRIORITY
    \fBnftables_counters\fR
    \fBnftables_ifindex\fR

    # به همین ترتیب برای IPVS iptables - مورد استفاده برای تنظیم fwmarkها برای گروه‌های
    # سرور مجازی. برنامه keepalived برای هر گروه سرور مجازی یک fwmark اختصاص می‌دهد، به طوری که
    # تنها یک سرور مجازی برای هر گروه نیاز به پیکربندی در IPVS داشته باشد (با استفاده از fwmark)،
    # و از nftables برای تنظیم fwmark به ازای هر یک از ترکیب‌های نشانی/پروتکل/درگاه مشخص‌شده
    # سرور مجازی استفاده خواهد شد.
    # گزینه nftables_ipvs_start_fwmark اولین fwmark را برای استفاده keepalived
    # مشخص می‌کند (پیش‌فرض 1000). این مقدار برای هر گروه سرور مجازی بعدی افزایش می‌یابد.
    \fBnftables_ipvs \fR[TABLENAME]
    \fBnftables_ipvs_priority \fRPRIORITY
    \fBnftables_ipvs_start_fwmark \fRNUMBER

    # استفاده از iptables به عنوان فایروال.
    # نکته: لازم است زنجیره مشخص‌شده در پیکربندی iptables و/یا ip6tables وجود داشته باشد،
    # و این زنجیره از یک نقطه مناسب در پیکربندی iptables فراخوانی شود.
    # احتمالاً لازم خواهد بود که این فیلترگذاری پس از پذیرش هرگونه بسته ESTABLISHED,RELATED انجام شود،
    # زیرا ممکن است IPv4 نشانی VIP را به عنوان نشانی مبدأ برای اتصالات خروجی انتخاب کند.
    # نکته: اگرچه زنجیره‌های پیش‌فرض مورد استفاده INPUT و OUTPUT هستند، از آنجا که این‌ها تنها
    # زنجیره‌هایی هستند که همیشه وجود دارند، استفاده از این زنجیره‌ها ایمن یا منطقی نیست و
    # زنجیره‌های اختصاصی باید ایجاد شده و از نقاط مناسب در پیکربندی iptables فراخوانی شوند.
    # زنجیره‌های مورد استفاده برای keepalived نباید برای هیچ منظور دیگری استفاده شوند، و
    # نباید هیچ قانونی به جز قوانینی که keepalived مدیریت می‌کند روی آن‌ها پیکربندی شده باشد.
    # یک startup_script (بالا را ببینید) می‌تواند برای ایجاد زنجیره‌ها و افزودن قوانین جهت فراخوانی آن‌ها
    # استفاده شود. یک shutdown_script می‌تواند برای حذف پیکربندی iptables اضافه‌شده توسط startup_script استفاده شود.
    # نکته 2: در صورت استفاده از ipsets، قوانین VIP مربوط به iptables به انتهای زنجیره‌های مشخص‌شده
    # اضافه می‌شوند؛ در صورت عدم استفاده از ipsets، قوانین VIP در ابتدای زنجیره‌ها درج می‌شوند.
    # تمام قوانین IGMP همیشه به انتهای زنجیره‌ها اضافه می‌شوند.
    # (پیش‌فرض: INPUT)
    \fBvrrp_iptables \fRkeepalived

    # یا برای فیلترگذاری خروجی نیز
    # توجه: فیلترگذاری خروجی با IPv4 کار نخواهد کرد، زیرا VIP می‌تواند به عنوان نشانی مبدأ
    # برای یک اتصال خروجی انتخاب شود. در IPv6 این موضوع بعید است زیرا نشانی‌ها منسوخ (deprecated) هستند.
    \fBvrrp_iptables \fRkeepalived_in keepalived_out

    # یا برای استفاده از زنجیره‌های پیش‌فرض (INPUT و OUTPUT)
    \fBvrrp_iptables\fR

    # برنامه Keepalived ممکن است امکان استفاده از ipsets در کنار iptables را داشته باشد.
    # در این صورت، نام‌های ipset می‌توانند مشخص شوند، پیش‌فرض‌ها به شرح زیر هستند.
    # اگر نامی مشخص نشود، از ipsets استفاده نخواهد شد، در غیر این صورت هر نام حذف‌شده
    # با افزودن "if_" و/یا "6" و igmp/_mld/_nd_ به نام‌های مشخص‌شده قبلی ساخته خواهد شد.
    \fBvrrp_ipsets \fR[keepalived [keepalived6 [keepalived_if6 [keepalived_igmp [keepalived_mld [keepalived_vmac_nd]]]]]]

    # یک راهکار جایگزین برای انتقال پیام‌های IGMP از VMACها به رابط‌های والد آن‌ها،
    # غیرفعال کردن کامل آن‌ها در هسته با تنظیم igmp_link_local_mcast_reports به false است.
    # این کار پیام‌های IGMP join و غیره را برای 224.0.0.0/24 متوقف می‌کند، زیرا آن‌ها باید
    # همیشه به همه رابط‌ها هدایت (forward) شوند (RFC4541 را ببینید).
    # این قابلیت از لینوکس 4.3 به بعد در دسترس است.
    disable_local_igmp

    # گزینه زیر بررسی این موضوع را فعال می‌کند که در حالت unicast، نشانی مبدأ
    # یک بسته VRRP یکی از unicast peerهای ما باشد.
    \fBvrrp_check_unicast_src\fR

    # بررسی تمام نشانی‌ها در یک اعلان دریافتی VRRP می‌تواند زمان‌بر باشد.
    # تنظیم این پرچم به این معنی است که اگر اعلان از همان مسیریاب master که اعلان قبلی
    # را فرستاده بود دریافت شده باشد، این بررسی انجام نخواهد شد.
    # (پیش‌فرض: نادیده نگرفتن)
    \fBvrrp_skip_check_adv_addr\fR

    # اعمال انطباق دقیق با پروتکل VRRP. این مورد در حال حاضر شامل اعمال موارد زیر است.
    # لطفاً توجه داشته باشید که در صورت یافتن موارد دیگر در آینده، ممکن است بررسی‌های دیگری نیز اضافه شوند:
    #   تعداد 0 VIP مجاز نیست
    #   unicast peerها مجاز نیستند
    #   نشانی‌های IPv6 در نسخه 2 VRRP مجاز نیستند
    #   اولین VIP در IPv6 باید link local باشد
    #   وضعیت MASTER تنها و تنها زمانی قابل پیکربندی است که اولویت 255 باشد
    #   احراز هویت پشتیبانی نمی‌شود
    #   تأخیر Preempt پشتیبانی نمی‌شود
    #   حالت Accept برای VRRPv2 قابل تنظیم نیست
    #   اگر accept/no accept مشخص نشده باشد، در صورت اولویت 255 مقدار accept تنظیم شده
    #    و در غیر این صورت پاک می‌شود
    #   تکرارهای ARP بی‌دلیل نمی‌توانند فعال شوند
    #   امکان پاک کردن lower_prio_no_advert وجود ندارد
    #   امکان تنظیم higher_prio_send_advert وجود ندارد
    #   امکان استفاده از vmac_xmit_base وجود ندارد
    #   عدم وجود VIP در VRRPv3 مجاز نیست
    #   اگر اولویت 255 باشد، اعلان‌های دریافتی نادیده گرفته می‌شوند
    \fBvrrp_strict\fR

    # ارسال اعلان‌های اولویت نمونه vrrp روی FIFOهای notify.
    \fBvrrp_notify_priority_changes\fR <BOOL>

    # گزینه‌های زیر زمانی می‌توانند استفاده شوند که فرایندهای vrrp، checker یا bfd
    # با پایان مهلت زمانی (timeout) مواجه می‌شوند. این موضوع را می‌توان از تبدیل شدن
    # یک نمونه vrrp پشتیبان (backup) به master مشاهده کرد، حتی زمانی که master همچنان در حال اجرا است،
    # زیرا سیستم master یا backup برای پردازش بسته‌های vrrp بیش از حد مشغول است.
    # --
    # برنامه keepalived می‌تواند در صورتی که تشخیص دهد به اندازه کافی پس از سررسید زمان‌سنج
    # اجرا نشده است، اولویت خود را افزایش دهد؛ ابتدا با تغییر به زمان‌بندی realtime،
    # و اگر این کافی نباشد، هر بار که تأخیر بیشتری در اجرا تشخیص دهد، اولویت realtime خود را یکی افزایش می‌دهد.
    # اگر رویدادی پیش آید که realtime
# زمان‌بندی فعال باشد، RLIMIT_RTTIME با استفاده از مقادیر
    # {bfd,checker,vrrp}_rlimit_rttime (زیر را ببینید) تنظیم خواهد شد. ممکن است لازم باشد
    # این مقادیر برای پردازنده‌های کُندتر افزایش یابند.
    # --
    # برای محدود کردن بیشینه افزایش اولویت خودکار، موارد زیر را مشخص کنید
    # (0 از افزایش خودکار اولویت استفاده نمی‌کند و پیش‌فرض است. -1 پیام
    # هشدار هنگام راه‌اندازی را غیرفعال می‌کند). حذف اولویت، بیشینه مقدار را تنظیم می‌کند.
    \fBmax_auto_priority\fR [<-1 to 99>]  # 99 در واقع همان sched_get_priority_max(SCHED_RR) است

    # کمینه تأخیر به میکروثانیه پس از انقضای تایمر پیش از آنکه keepalived
    # زمان‌بندی شود، که پس از آن اولویت فرایند به‌طور خودکار افزایش می‌یابد
    # (پیش‌فرض 1000000 میکروثانیه (۱ ثانیه)، بیشینه 10000000 (۱۰ ثانیه) است)
    \fBmin_auto_priority_delay\fR <delay in usecs>

    # تنظیم اولویت فرایند فرزند vrrp (مقادیر منفی اولویت را افزایش می‌دهند)
    \fBvrrp_priority \fR<-20 to 19>

    # تنظیم اولویت فرایند فرزند checker
    \fBchecker_priority \fR<-20 to 19>

    # تنظیم اولویت فرایند فرزند BFD
    \fBbfd_priority \fR<-20 to 19>

    # غیرقابل swap کردن فرایند فرزند vrrp در حافظه
    \fBvrrp_no_swap\fR

    # غیرقابل swap کردن فرایند فرزند checker در حافظه
    \fBchecker_no_swap\fR

    # غیرقابل swap کردن فرایند فرزند BFD در حافظه
    \fBbfd_no_swap\fR

    # از گزینه‌های زیر می‌توان برای اجبار فرایندهای vrrp، checker و bfd
    # به اجرا روی یک مجموعه محدود از پردازنده‌ها استفاده کرد.
    # می‌توانید فرایندها را به یک CPU واحد مقید کنید یا مجموعه‌ای از
    # CPUها را تعریف نمایید. در حالت آخر، هسته لینوکس در طول زمان‌بندی
    # به همان مجموعه CPU محدود خواهد شد. اجبار به وابستگی فرایند به یک CPU واحد
    # می‌تواند کارایی را در سیستم‌های تحت بار سنگین افزایش دهد.
    # مقدار INTEGER پس از کلیدواژه پیکربندی، نشان‌دهنده cpu_id است
    # همان‌گونه که در پرونده /proc/cpuinfo در خط "processor:" نمایش داده می‌شود
    # --
    # تنظیم وابستگی پردازنده (CPU Affinity) برای فرایند فرزند vrrp
    \fBvrrp_cpu_affinity\fR <INTEGER> [<INTERGER>]...[<INTEGER>]

    # تنظیم وابستگی پردازنده (CPU Affinity) برای فرایند فرزند checker
    \fBchecker_cpu_affinity\fR <INTEGER> [<INTERGER>]...[<INTEGER>]

    # تنظیم وابستگی پردازنده (CPU Affinity) برای فرایند فرزند bfd
    \fBbfd_cpu_affinity\fR <INTEGER> [<INTERGER>]...[<INTEGER>]

    # تنظیم فرایند فرزند vrrp برای استفاده از زمان‌بندی بی‌درنگ (real-time)
    # در اولویت مشخص‌شده
    \fBvrrp_rt_priority \fR<1..99>

    # تنظیم فرایند فرزند checker برای استفاده از زمان‌بندی بی‌درنگ (real-time)
    # در اولویت مشخص‌شده
    \fBchecker_rt_priority \fR<1..99>

    # تنظیم فرایند فرزند BFD برای استفاده از زمان‌بندی بی‌درنگ (real-time)
    # در اولویت مشخص‌شده
    \fBbfd_rt_priority \fR<1..99>

    # تنظیم محدودیت زمان CPU بین فراخوان‌های سیستمی مسدودکننده،
    # به میکروثانیه
    # (پیش‌فرض: 10000)
    \fBvrrp_rlimit_rttime \fR>=2
    \fBchecker_rlimit_rttime \fR>=2
    \fBbfd_rlimit_rttime \fR>=2

    # اگر Keepalived با پشتیبانی از SNMP کامپایل شده باشد، کلیدواژه‌های
    # زیر در دسترس خواهند بود.
    # نکته: پشتیبانی از Keepalived، checker و RFC را می‌توان به‌صورت جداگانه
    # فعال/غیرفعال کرد
    # --
    # مشخص کردن سوکت مورد استفاده برای اتصال به عامل اصلی (master agent) پروتکل SNMP
    # (برای جزئیات بیشتر به ماژول مبدأ keepalived/vrrp/vrrp_snmp.c مراجعه کنید)
    # (پیش‌فرض: unix:/var/agentx/master)
    \fBsnmp_socket \fRudp:1.2.3.4:705

    # فعال‌سازی پردازش SNMP برای عنصر vrrp در KEEPALIVED MIB
    \fBenable_snmp_vrrp\fR

    # فعال‌سازی پردازش SNMP برای عنصر checker در KEEPALIVED MIB
    \fBenable_snmp_checker\fR

    # فعال‌سازی پردازش SNMP برای MIBهای VRRP مربوط به RFC2787 و RFC6527
    \fBenable_snmp_rfc\fR

    # فعال‌سازی پردازش SNMP برای MIB مربوط به RFC2787 VRRP
    \fBenable_snmp_rfcv2\fR

    # فعال‌سازی پردازش SNMP برای MIB مربوط به RFC6527 VRRP
    \fBenable_snmp_rfcv3\fR

    # فعال‌سازی تله‌های (traps) پروتکل SNMP
    \fBenable_traps\fR

    # هنگام ارسال درخواست‌های SNMP، فرایند checker تنها در صورتی آمار سرور
    # مجازی و واقعی را از هسته به‌روزرسانی می‌کند که آخرین زمان خواندن آمار
    # برای آن سرور مجازی، بیش از این بازه پیکربندی‌شده (به ثانیه) باشد. بازه
    # پیش‌فرض ۵ ثانیه است، و دامنه معتبر از 0.001 (۱ میلی‌ثانیه) تا ۳۰ ثانیه می‌باشد.
    \fBsnmp_vs_stats_update_interval\fR <TIMER>

    # مشابه snmp_vs_stats_update_interval اما برای سرورهای واقعی. آمار مربوط به
    # سرورهای واقعی تنها در صورتی خوانده می‌شود که یک درخواست SNMP برای آمار سرور
    # واقعی وجود داشته باشد.
    \fBsnmp_rs_stats_update_interval\fR <TIMER>

    # اگر Keepalived با پشتیبانی از DBus کامپایل شده باشد، کلیدواژه‌های
    # زیر در دسترس خواهند بود.
    # --
    # فعال‌سازی رابط DBus
    \fBenable_dbus\fR

    # نام سرویس DBus
    # زمانی کاربرد دارد که بخواهید چندین فرایند keepalived را با DBus فعال اجرا کنید
    # (پیش‌فرض: org.keepalived.Vrrp1)
    \fBdbus_service_name \fRSERVICE_NAME

    # رشته مورد استفاده برای مسیر DBus هنگامی که نمونه VRRP هیچ رابطی پیکربندی نکرده باشد
    # زمانی کاربرد دارد که سیستم شما رابطی به نام "none" داشته باشد!
    # (پیش‌فرض: "none")
    \fBdbus_no_interface_name \fRNAME

    # مشخص کردن username/groupname پیش‌فرض برای اجرای اسکریپت‌ها تحت آن.
    # اگر این گزینه مشخص نشود، کاربر به keepalived_script پیش‌فرض می‌شود
    # در صورتی که آن کاربر وجود داشته باشد، در غیر این صورت بر اساس uid/gid که keepalived تحت آن اجرا می‌شود.
    # اگر groupname مشخص نشود، به گروه پیش‌فرض آن کاربر تنظیم می‌شود.
    \fBscript_user \fRusername [groupname]

    # عدم اجرای اسکریپت‌های پیکربندی‌شده برای اجرا تحت root در صورتی که هر بخشی از مسیر
    # توسط کاربری غیر از root قابل نوشتن باشد. همچنین اجبار می‌کند که script_user پیش‌فرض
    # همان keepalived_script باشد، و به کاربری که keepalived تحت آن در حال اجراست (معمولاً root)
    # تغییر نیابد.
    \fBenable_script_security\fR

    # به جای استفاده از اسکریپت‌های notify، مشخص کردن یک fifo امکان پردازش
    # کارآمدتر رویدادهای notify را فراهم کرده و تضمین می‌کند که آنها
    # با توالی صحیح تحویل داده خواهند شد.
    # نکته: نام‌های FIFO همگی باید یکتا باشند
    # --
    # FIFO برای نوشتن رویدادهای notify در آن
    # برای قالب خروجی vrrp_notify_fifo و lvs_notify_fifo را ببینید
    # برای جزئیات بیشتر، توضیحات زیر بخش vrrp_sync_group را ببینید.
    # برای نمونه کاربرد doc/samples/sample_notify_fifo.sh را ببینید.
    \fBnotify_fifo \fRFIFO_NAME [username [groupname]]

    # اسکریپتی که توسط keepalived برای پردازش رویدادهای notify اجرا می‌شود
    # نام FIFO به عنوان آخرین پارامتر به اسکریپت ارسال خواهد شد
    \fBnotify_fifo_script \fRSTRING|QUOTED-STRING [username [groupname]]

    # FIFO برای نوشتن رویدادهای notify مربوط به vrrp در آن.
    # رشته نوشته‌شده خطی به این شکل خواهد بود: INSTANCE "VI_1" MASTER 100
    # و با یک نویسه خط جدید خاتمه می‌یابد.
    # برای جزئیات بیشتر خروجی، توضیحات زیر vrrp_sync_group
    # و doc/samples/sample_notify_fifo.sh را برای نمونه کاربرد ببینید.
    \fBvrrp_notify_fifo \fRFIFO_NAME [username [groupname]]

    # اسکریپتی که توسط keepalived برای پردازش رویدادهای notify مربوط به vrrp اجرا می‌شود
    # نام FIFO به عنوان آخرین پارامتر به اسکریپت ارسال خواهد شد
    \fBvrrp_notify_fifo_script \fRSTRING|QUOTED-STRING [username [groupname]]

    # FIFO برای نوشتن رویدادهای notify مربوط به healthchecker در آن
    # رشته نوشته‌شده خطی به این شکل خواهد بود:
    # VS [192.168.201.15]:tcp:80 {UP|DOWN}
    # RS [1.2.3.4]:tcp:80 [192.168.201.15]:tcp:80 {UP|DOWN}
    # و با یک نویسه خط جدید خاتمه می‌یابد.
    \fBlvs_notify_fifo \fRFIFO_NAME [username [groupname]]

    # اسکریپتی که توسط keepalived برای پردازش رویدادهای notify مربوط به healthchecker اجرا می‌شود
    # نام FIFO به عنوان آخرین پارامتر به اسکریپت ارسال خواهد شد
    \fBlvs_notify_fifo_script \fRSTRING|QUOTED-STRING [username [groupname]]

    # به‌طور پیش‌فرض، هنگام بارگذاری مجدد (reload) keepalived، وضعیت‌های نمونه vrrp و گروه همگام‌سازی
    # در FIFOهای مربوطه نوشته نمی‌شوند. تنظیم این گزینه باعث می‌شود که هنگام
    # بارگذاری مجدد keepalived، وضعیت‌ها به FIFO(ها) ارسال شوند.
    \fBfifo_write_vrrp_states_on_reload\fR

    # اجازه به پیکربندی برای شامل شدن رابط‌هایی که هنگام راه‌اندازی وجود ندارند.
    # این قابلیت به keepalived اجازه می‌دهد با رابط‌هایی که ممکن است حذف و بازیابی شوند
    # کار کند و همچنین مسیرها و قوانین مجازی و ایستا را روی رابط‌های VMAC ممکن می‌سازد.
    # allow_if_changes اجازه می‌دهد یک رابط حذف شده و با نوع یا رابط زیربنایی متفاوتی
    # بازسازی شود، مثلاً تغییر از vlan به macvlan یا تغییر macvlan از eth1 به eth2. این گزینه
    # در صورت تنظیم نشدن allow_if_changes عمدتاً برای گزارش خطاهای تکراری VRID در راه‌اندازی استفاده می‌شود.
    \fBdynamic_interfaces [allow_if_changes]\fR

    # گزینه‌های زیر تنها برای پیکربندی‌های بزرگ لازم هستند، جایی که یا
    # keepalived تعداد زیادی رابط ایجاد می‌کند، یا سیستم تعداد زیادی
    # رابط دارد. این گزینه‌ها تنها در صورتی نیاز به استفاده دارند که پیام‌های
    # "Netlink: Receive buffer overrun" در گزارش‌های سیستم ثبت شوند.
    # اگر اندازه بافر مورد نیاز از مقدار موجود در /proc/sys/net/core/rmem_max فراتر رود
    #  لازم است گزینه force مربوطه تنظیم شود.
    # --
    # تنظیم اندازه بافر دریافت netlink. این گزینه برای
    # پیکربندی‌های بسیار بزرگ مفید است که در آن تعداد زیادی رابط وجود دارد و
    # خواندن اولیه رابط‌ها در سیستم باعث سرریز بافر netlink می‌شود.
    \fBvrrp_netlink_cmd_rcv_bufs \fRBYTES
    \fBvrrp_netlink_cmd_rcv_bufs_force \fR<BOOL>
    \fBvrrp_netlink_monitor_rcv_bufs \fRBYTES
    \fBvrrp_netlink_monitor_rcv_bufs_force \fR<BOOL>

    # اندازه‌های بافر سوکت دستور و پایش netlink مربوط به vrrp، سوکت دستور
    # و پایش checker و بافر پایش فرایند می‌توانند به‌طور مستقل تنظیم شوند.
    # پرچم force به معنای استفاده از SO_RCVBUFFORCE است، تا اندازه بافر
    # بتواند از /proc/sys/net/core/rmem_max فراتر رود.
    \fBlvs_netlink_cmd_rcv_bufs \fRBYTES
    \fBlvs_netlink_cmd_rcv_bufs_force \fR<BOOL>
    \fBlvs_netlink_monitor_rcv_bufs \fRBYTES
    \fBlvs_netlink_monitor_rcv_bufs_force \fR<BOOL>

    # به عنوان راهنما برای process_monitor_rcv_bufs در شرایطی که ۱۴۰۰ فرایند به‌طور همزمان
    # خاتمه می‌یابند، مقدار 212992 (پیش‌فرض در برخی سیستم‌ها) ناکافی است، در حالی که
    # مقدار 500000 کافی خواهد بود.
    \fBprocess_monitor_rcv_bufs \fRBYTES
    \fBprocess_monitor_rcv_bufs_force \fR<BOOL>

    # هنگام باز شدن یک سوکت، هسته بیشینه اندازه بافر rx برای سوکت را روی
    # مقدار /proc/sys/net/core/rmem_default پیکربندی می‌کند. در برخی سیستم‌ها این مقدار
    # می‌تواند بسیار بزرگ باشد، و حتی به‌طور کلی می‌تواند بسیار بزرگتر از حد نیاز باشد.
    # این موضوع تا زمانی که keepalived تمام داده‌های صف‌بندی‌شده را از سوکت‌هایش می‌خواند
    # مشکلی ایجاد نمی‌کند، اما اگر rmem_default به اندازه کافی بزرگ تنظیم شده باشد و بنا به
    # دلایلی keepalived خواندن را متوقف کند، می‌تواند تمام حافظه سیستم را مصرف نماید.
    # گزینه vrrp_rx_bufs_policy امکان پیکربندی اندازه بافرهای rx را هنگام باز شدن
    # سوکت‌ها فراهم می‌سازد. اگر خط‌مشی روی MTU باشد، اندازه بافر rx روی حاصل‌ضرب
    # مقدار MTU رابط * vrrp_rx_bufs_multiplier برای هر نمونه vrrp استفاده‌کننده
    # از سوکت تنظیم می‌شود. به همین ترتیب، اگر خط‌مشی روی ADVERT باشد، برابر با مجموع
    # اندازه بسته advert هر نمونه vrrp * multiplier خواهد بود.
    # (پیش‌فرض: استفاده از پیش‌فرض سیستم)
    \fBvrrp_rx_bufs_policy \fR[MTU|ADVERT|NUMBER]

    # (پیش‌فرض: 3)
    \fBvrrp_rx_bufs_multiplier \fRNUMBER

    # ارسال اعلان‌ها هنگام راه‌اندازی برای سرورهای واقعی که در حال بالا آمدن هستند
    \fBrs_init_notifies\fR

    # عدم ارسال ایمیل در هر بار تغییر وضعیت بررسی‌کننده (checker) سرور واقعی؛
    # تنها هنگام اضافه یا حذف شدن یک سرور واقعی ایمیل ارسال شود
    \fBno_checker_emails\fR

    # مقدار umask برای استفاده هنگام ایجاد پرونده‌ها. عدد را می‌توان به صورت هگزادسیمال، هشت‌هشتی (octal)
    #   یا ده‌دهی (decimal) مشخص کرد. BITS به صورت I{R|W|X}{USR|GRP|OTH}، مثلاً IRGRP هستند که با '|' جدا می‌شوند.
    #   همچنین می‌توان IRWX{U|G|O} را مشخص کرد.
    #   مقدار پیش‌فرض umask برابر IXUSR | IRWXG | IRWXO است. این گزینه نمی‌تواند گزینه
    #   خط فرمان را لغو کند.
    \fBumask \fR[NUMBER|BITS]

    # در برخی سیستم‌ها هنگام ایجاد رابط‌های bond، ممکن است آنها شروع به عبور ترافیک کنند
    # و سپس وقفه‌ای چند ثانیه‌ای رخ دهد که عبور ترافیک ورودی متوقف می‌شود. این می‌تواند
    # به این معنی باشد که اگر keepalived در زمان بوت راه‌اندازی شود، یعنی همزمان با ایجاد
    # رابط‌های bond، اعلان‌ها (adverts) را دریافت نکرده و با وجود نمونه‌ای با اولویت بالاتر
    # که اعلان ارسال می‌کند، به master تبدیل شود.
    # این گزینه یک تأخیر به ثانیه پیش از راه‌اندازی نمونه‌های vrrp پس از شروع keepalived مشخص می‌کند.
    # همچنین \fBvrrp_delay_after_boot\fR در زیر را ببینید.
    \fBvrrp_startup_delay \fR5.5

    # احتمالاً یک جایگزین بهتر برای \fBvrrp_startup_delay \fR استفاده از
    # \fBvrrp_delay_after_boot\fB است. این امر تضمین می‌کند که راه‌اندازی نمونه‌های vrrp
    # حداقل تا تعداد ثانیه‌های مشخص‌شده پس از بوت سیستم به تأخیر بیفتد. بنابراین،
    # هنگامی که keepalived در زمان بوت راه‌اندازی می‌شود، می‌تواند شروع نمونه‌های VRRP را
    # تا سپری شدن زمان مشخص‌شده به تأخیر بیندازد، اما اگر keepalived متوقف و دوباره راه‌اندازی شود
    # هیچ تأخیری نخواهد داشت. keepalived از تأخیر طولانی‌تر بین
    # \fBvrrp_startup_delay\fR و \fBvrrp_delay_after_boot\fR استفاده خواهد کرد.
    \fBvrrp_delay_after_boot \fR15.23

    # مورد زیر باعث ثبت گزارش دریافت اعلان‌های VRRP برای VRIDهایی می‌شود که روی رابطی
    # که اعلان از آن دریافت شده پیکربندی نشده‌اند.
    \fBlog_unknown_vrids\fR

    # مشخص کردن پیشوند برای نام‌های تولیدشده VMAC (پیش‌فرض "vrrp")
    \fBvmac_prefix \fRSTRING

    # مشخص کردن پیشوند برای نام‌های تولیدشده VMAC برای VIPهایی که از VMAC استفاده می‌کنند اما روی
    # رابط نمونه VRRP نیستند (مقدار پیش‌فرض vmac_prefix)
    \fBvmac_addr_prefix \fRSTRING

    # مشخص کردن مقدار بذر تصادفی (random seed) برای ${_RANDOM} جهت تکرارپذیر کردن پیکربندی‌ها (پیش‌فرض
    # استفاده از بذری بر پایه زمان است، تا هر بار پیکربندی متفاوتی
    # تولید شود).
    \fBrandom_seed \fRUNSIGNED_INT

    # اگر تلاش برای بارگذاری مجدد پیکربندی با یک پرونده پیکربندی به‌روزشده دارای خطا
    # انجام شود، ممکن است keepalived متوقف شده و احتمالاً وارد یک حلقه بی‌پایان راه‌اندازی مجدد
    # و خاتمه شود. اگر reload_check_config تنظیم شده باشد، keepalived پیش از آغاز بارگذاری مجدد،
    # تلاش می‌کند پیکربندی را اعتبارسنجی کند و تنها در صورتی بارگذاری مجدد را آغاز می‌کند
    # که پیکربندی معتبر باشد.
    \fBreload_check_config \fR[LOG_FILE]

    # برخورد با هر پرونده include یافت‌نشده به عنوان خطا. OPTIONS می‌تواند هر ترکیبی از موارد زیر باشد:
    #   readable	- خطا در صورتی که مورد منطبق، یک پرونده قابل خواندن نباشد
    #   match		- خطا در صورتی که هیچ پرونده‌ای منطبق نشود (مگر اینکه نویسه عام مشخص شده باشد)
    #   wildcard_match	- خطا در صورتی که هیچ پرونده‌ای منطبق نشود (حتی اگر نویسه عام مشخص شده باشد)
    #   brace_match	- خطا در صورتی که بسط آکولاد (brace expansion) با پرونده‌ای منطبق نشود
    # نکته: match، wildcard_match و brace_match شامل بررسی readable نیز هستند.
    # تنظیم include_check هنگام باز شدن یک پرونده include جدید ذخیره شده و پس از بسته شدن پرونده
    # بازیابی می‌شود. این بدان معناست که تنظیم include_check هنگام خواندن یک پرونده نمی‌تواند توسط
    # پرونده includeشده بعدی تغییر کند. برای تغییر این تنظیم برای تمامی پرونده‌های includeشده،
    # include_check باید در ابتدای پرونده پیکربندی مشخص‌شده در خط فرمان (پیش‌فرض /etc/keepalived/keepalived.conf) تنظیم شود.
    # نکته ۲: اگر تابع glob() در libc از GLOB_ALTDIRFUNC پشتیبانی نکند (مانند Musl libc در
    # Alpine Linux و غیره)، تنها گزینه‌های readable و wildcard_match از موارد بالا کار خواهند کرد.
    # امکان افزودن یا حذف تنظیمات فردی وجود دارد؛ '+' به معنای افزودن بررسی‌های بعدی و
    # '-' به معنای حذف بررسی‌های بعدی است. به عنوان مثال:
    #   \fIinclude_check +match -wildcard_match\fR
    # الزام وجود یک پرونده منطبق را اضافه کرده و الزام تطابق‌های wildcard را حذف می‌کند.
    # اگر هیچ گزینه‌ای مشخص نشود، معادل با مشخص کردن تمام گزینه‌ها است.
    \fBinclude_check \fR[OPTIONS]

    # reload_time_file امکان زمان‌بندی بارگذاری مجدد keepalived در آینده را فراهم می‌سازد. این قابلیت
    # به‌ویژه زمانی مفید است که یک سرور اصلی (master) keepalived و یک یا چند نمونه پشتیبان (backup) وجود دارند
    # و پیکربندی جدید با پیکربندی قبلی ناسازگار است، مثلاً افزودن یا حذف VIPها که باعث رد شدن اعلان‌ها می‌شود.
    # می‌توان تمامی نمونه‌ها را برای بارگذاری مجدد در یک زمان مشخص زمان‌بندی کرد، و بدین ترتیب تضمین نمود که
    # هیچ اعلان نامنطبقی توسط نمونه‌های پشتیبان دریافت نمی‌شود.
    # پیکربندی پرونده‌ای را مشخص می‌کند که keepalived آن را پایش خواهد کرد. خط اول
    # پرونده باید شامل زمان یا تاریخ/زمان معتبر دقیقاً در قالب‌های مشخص‌شده زیر باشد.
    # هنگامی که keepalived راه‌اندازی می‌شود، در صورت وجود پرونده آن را می‌خواند و یک بارگذاری مجدد را
    # در زمان مشخص‌شده زمان‌بندی می‌کند. اگر پرونده وجود نداشته باشد، پس از ایجاد بعدی آن
    # یک بارگذاری مجدد زمان‌بندی خواهد شد. اگر پرونده به‌روزرسانی شود، زمان بارگذاری مجدد نیز بر همان اساس
    # اصلاح می‌شود. در صورت حذف پرونده، بارگذاری مجدد لغو می‌گردد.
    # به‌طور معمول با رخ دادن بارگذاری مجدد، پرونده مشخص‌شده حذف می‌شود، زیرا بارگذاری مجدد
    # انجام شده است؛ اگر پرونده شامل تاریخ بود، بارگذاری مجدد در گذشته قرار می‌گیرد و نادیده گرفته می‌شود.
    # با این حال، اگر تاریخی وجود نداشته باشد، در صورت خواندن مجدد پرونده پس از بارگذاری مجدد،
    # یک بارگذاری مجدد برای ۲۴ ساعت بعد زمان‌بندی خواهد شد. به منظور جلوگیری از این امر،
    # پرونده به‌طور پیش‌فرض حذف (unlink) می‌شود. اگر reload_repeat مشخص شده باشد، پرونده
    # حذف نمی‌شود، و اگر پرونده تنها شامل زمان بدون تاریخ باشد، keepalived هر روز در همان زمان
    # به بارگذاری مجدد ادامه می‌دهد تا زمانی که پرونده حذف یا اصلاح شود.
    # اگر دایرکتوری حاوی پرونده در زمان راه‌اندازی/بارگذاری مجدد وجود نداشته باشد، یا اگر دایرکتوری
    # حذف یا تغییر نام داده شود، هیچ بارگذاری مجدد زمان‌بندی‌شده‌ای در آینده رخ نخواهد داد تا زمانی که
    # یک بارگذاری مجدد دستی (SIGHUP) انجام شود یا keepalived دوباره راه‌اندازی گردد.
    # قالب‌های مجاز برای ورودی در پرونده زمان‌سنج دقیقاً عبارتند از:
    #   HH:MM:SS
    #   YY-MM-DD HH:MM:SS
    #   YYYY-MM-DD HH:MM:SS
    # هرکدام با یک 'Z' اختیاری در انتها.
    # نباید هیچ فاصله خالی (whitespace) در ابتدا یا انتها وجود داشته باشد، و تنها یک فاصله بین تاریخ
    # و زمان مجاز است.
    # اگر یک 'Z' در انتهای زمان وجود داشته باشد، زمان به عنوان UTC پردازش می‌شود، در غیر این صورت
    # زمان همان زمان محلی (localtime) برای محیطی است که keepalived در آن اجرا می‌شود. اگر سیستم‌هایی
    # که بارگذاری مجدد می‌شوند در منطقه‌های زمانی متفاوتی قرار دارند، احتمالاً استفاده از UTC امن‌تر است.
    # در صورت استفاده از زمان محلی با ساعت تابستانی (daylight savings)، توجه داشته باشید که برخی زمان‌ها وجود ندارند
    # و برخی زمان‌ها تکرار می‌شوند و بنابراین مبهم هستند.
    \fBreload_time_file\fR ABSOLUTE-PATHNAME-OF-FILE
    \fBreload_repeat\fR

    # برخی کاربران مرتباً پیکربندی‌های خود را به‌روزرسانی کرده و keepalived را مجدداً بارگذاری می‌کنند. reload_file
    # مکانیزمی فراهم می‌کند که به فرایندهای به‌روزرسانی پیکربندی اجازه می‌دهد پرونده‌های پیکربندی را
    # در حین خوانده شدن توسط keepalived به‌روزرسانی نکنند.
    # پرونده reload پیش از شروع خواندن پرونده‌های پیکربندی توسط keepalived ایجاد می‌شود،
    # مگر اینکه پرونده از قبل وجود داشته باشد. اگر پرونده وجود داشته باشد، خالی (truncated) خواهد شد. هنگامی که
    # keepalived خواندن پرونده‌ها را به پایان برساند، پرونده reload را حذف خواهد کرد.
    # اگر reload_file بدون نام پرونده مشخص شود، نام پرونده پیش‌فرض keepalived.reload
    # در دایرکتوری PID استفاده خواهد شد.
    # بهترین روش برای استفاده از پرونده reload این است که فرایند به‌روزرسانی پیکربندی، پرونده reload را
    # پیش از ارسال سیگنال reload به keepalived لمس (touch) کند، و سپس منتظر بماند تا پرونده
    # حذف شود، که نشان می‌دهد خواندن پرونده‌های پیکربندی توسط keepalived به پایان رسیده است.
    # هنگامی که keepalived شروع به خواندن پرونده‌های پیکربندی می‌کند، از آنجا که پرونده reload را خالی می‌کند،
    # اگر فرایند به‌روزرسانی پرونده reload_file را با اندازه غیرصفر ایجاد کرده باشد، می‌تواند شروع بارگذاری مجدد
    # را از صفر شدن طول reload_file تشخیص دهد.
    \fBreload_file\fR [ABSOLUTE-PATHNAME-OF-FILE]

    # ارسال SIGUSR1 به keepalived باعث می‌شود ساختارهای داده خود را برای
    # اهداف اشکال‌زدایی تخلیه (dump) کند، هرچند برخی کاربران از این ویژگی استفاده کرده
    # و خروجی را پردازش می‌کنند. لطفاً توجه داشته باشید که قالب پرونده‌های .data تولیدشده
    # سازگاری عقبروی را تضمین نمی‌کند.
    # نام‌های پیش‌فرض پرونده‌ها keepalived_parent.data، keepalived.data،
    # keepalived_check.data و keepalived_bfd.data هستند. این امر در صورتی که بیش از یک
    # نمونه keepalived روی سیستم در حال اجرا باشد مشکل ایجاد می‌کند.
    # برای برطرف کردن این مشکل، فعال کردن data_use_instance نام نمونه و فضای نام شبکه (network namespace)
    # را در نام پرونده‌های .data لحاظ می‌کند.
    # این موضوع برای SIGUSR2 جهت خروجی آمارها نیز اعمال می‌شود.
    \fBdata_use_instance \fR[<BOOL>]

    # اگر پرونده‌های تولیدشده توسط SIGUSR1 و SIGUSR2 روی فضای ذخیره‌سازی کُند باشند، نوشتن روی
    # آنها ممکن است باعث مسدود شدن فرایندهای keepalived شود. این گزینه امکان مشخص کردن
    # مکانی که پرونده‌ها باید در آن نوشته شوند را می‌دهد، و در حالت ایده‌آل باید یک tmpfs باشد تا
    # یک دیسک فیزیکی، و قطعاً نباید فضای ذخیره‌سازی متصل به شبکه یا سایر ذخیره‌سازهایی باشد که
    # می‌توانند بیش از چند میکروثانیه فرایند را مسدود کنند.
    # اگر path با یک / پایان یابد به عنوان یک دایرکتوری در نظر گرفته می‌شود و نام‌های معمولی پرونده‌ها
    # در آن دایرکتوری استفاده خواهند شد، در غیر این صورت به عنوان نام کامل مسیر پرونده‌ای که باید نوشته شود
    # استفاده خواهد شد. توجه داشته باشید که \fBdata_use_instance\fR نیز ممکن است نام پرونده را تغییر دهد.
    # برای پرونده‌های وضعیت، اینها نام‌های الگو هستند و برای فرایند checker پسوند "_checker"،
    # برای فرایند BFD پسوند "_bfd" و برای فرایند والد پسوند "_parent" اضافه خواهد شد.
    \fBstate_file_location \fRpath
    \fBstats_file_location \fRpath
    \fBjson_file_location \fRpath

    # مقدار json_version 2 داده‌های VRRP را در یک آرایه نام‌گذاری‌شده قرار می‌دهد و
    # جزئیات track_process را اضافه می‌کند. پیش‌فرض نسخه 1 است.
    \fBjson_version \fR{1|2}

    # ابزار iproute می‌تواند از دو دایرکتوری برای پرونده‌های پیکربندی خود استفاده کند، که پرونده‌های موجود در
    # /etc/iproute2 بر پرونده‌های /usr/share/iproute2 اولویت دارند.
    # ابزار ip (بسته‌ای که قابلیت ip route را فراهم می‌کند) گزینه‌های configure برای
    # مکان این دایرکتوری‌ها دارد. بخش configure در keepalived تلاش خواهد کرد مکان‌ها را یا از
    # صفحه راهنمای ip-route یا از خود ابزار ip پیدا کند. در صورتی که نتواند این کار را انجام دهد،
    # ممکن است لازم باشد مکان‌ها در اینجا مشخص شوند.
    \fBiproute_usr_dir \fRpath
    \fBiproute_etc_dir \fRpath
}
.fi
.SH "رابط‌های Linkbeat (Linkbeat interfaces)"
.PP
بلوک linkbeat_interfaces امکان تعیین این را فراهم می‌کند که کدام رابط‌ها به جای اتکا به به‌روزرسانی‌های وضعیت netlink، باید از نظرسنجی (polling) از طریق وضعیت MII، Ethtool یا ioctl استفاده کنند. این امر امکان کنترل دقیق‌تری بر تعریف عمومی \fBlinkbeat_use_polling\fR ایجاد می‌کند.
.PP
این گزینه بر استفاده منسوخ‌شده از \fBlinkbeat_use_polling\fR در بلوک vrrp_instance ترجیح داده می‌شود، زیرا روش دوم تنها اجازه استفاده از linkbeat را روی رابط خودِ vrrp_instance می‌دهد، در حالی که \fRtrack_interface\fR، virtual_ipaddresses و virtual_iproutes ممکن است نیازمند پایش رابط‌های دیگری باشند که شاید به استفاده از نظرسنجی linkbeat نیاز داشته باشند.
.PP
نوع نظرسنجی پیش‌فرض MII است، مگر اینکه پشتیبانی نشود که در این صورت از ETHTOOL استفاده می‌شود، و اگر آن هم پشتیبانی نشود از نظرسنجی ioctl استفاده خواهد شد. نوع نظرسنجی ترجیحی می‌تواند با MII یا ETHTOOL یا IOCTL پس از نام رابط مشخص شود، اما اگر آن نوع پشتیبانی نشود، از نوعی که پشتیبانی می‌شود استفاده خواهد شد.
.PP
نحو linkbeat_interfaces به شرح زیر است:
.nf
    \fBlinkbeat_interfaces\fR {
        eth2
        enp2s0 ETHTOOL
    }
.fi
.SH "گروه‌های ردیابی ایستا (Static track groups)"
.PP
گروه‌های ردیابی ایستا برای مجاز ساختن نمونه‌های vrrp به ردیابی نشانی‌ها، مسیرها و قوانین ایستا استفاده می‌شوند. اگر یک نشانی/مسیر/قانون ایستا یک track group مشخص کند، در صورتی که آن نشانی/مسیر/قانون حذف شده و امکان بازیابی آن وجود نداشته باشد، نمونه vrrp به وضعیت fault منتقل خواهد شد.
.PP
نحو یک track group به شرح زیر است:
.nf
    \fBtrack_group \fRGROUP1 {
        \fBgroup \fR{
            VI_1
            VI_2
        }
    }
.fi
.SH "مسیرها/نشانی‌ها/قوانین ایستا (Static routes/addresses/rules)"
.PP
نرم‌افزار Keepalived می‌تواند نشانی‌ها، مسیرها و قوانین ایستا را پیکربندی کند. این نشانی‌ها، مسیرها و قوانین توسط vrrpd منتقل
\fBNOT\fR
(نمی‌شوند) و روی ماشین باقی می‌مانند.
اگر از پیش روی ماشین‌های خود IPها و مسیرها را دارید و ماشین‌های شما می‌توانند یکدیگر را ping کنند، به این بخش نیازی ندارید.
نحو قوانین و مسیرها همانند ip rule add/ip route add است (به جز اینکه نام‌های کوتاه شده گزینه‌ها به دلیل ابهامات پشتیبانی نمی‌شوند).
مشخصه track_group به یک track_group نام‌گذاری‌شده اشاره دارد که نمونه‌های vrrp ردیابی‌کننده نشانی را فهرست می‌کند، بدین معنا که اگر نشانی حذف شود، نمونه‌های vrrp به وضعیت backup منتقل خواهند شد.

یادداشت: از آنجا که قوانین بدون اولویت (preference) ممکن است به دلیل انتقال نمونه‌های vrrp از master به backup و غیره با ترتیب‌های متفاوتی اضافه شوند، قوانین باید دارای یک preference باشند. اگر یک preference مشخص نشود، keepalived یکی اختصاص می‌دهد، اما احتمالاً مطابق خواسته شما نخواهد بود.
.PP
نحو برای نشانی‌های مجازی و مسیرهای مجازی یکسان است. اگر هیچ عنصر dev مشخص نشود، به default_interface (پیش‌فرض eth0) تنظیم می‌شود.
یادداشت: نشانی broadcast ممکن است به صورت '-' یا '+' برای پاک کردن یا تنظیم بیت‌های میزبان نشانی مشخص شود.
.PP
اگر یک مسیر یا قانون بتواند هم بر IPv4 و هم بر IPv6 اعمال شود، به صورت پیش‌فرض IPv4 در نظر گرفته می‌شود. برای اجبار یک مسیر/قانون به IPv6 بودن، کلیدواژه "inet6" را اضافه کنید.
.PP
به طور پیش‌فرض keepalived مسیرها را در ابتدا درج می‌کند (prepend، پیش‌فرض هسته) که مسیر را پیش از هر مسیر منطبق دیگری اضافه می‌کند (این رفتار مشابه فرمان (مستند نشده) 'ip route prepend' است). اگر 'add' مشخص شود، رفتار مشابه فرمان 'ip route add' خواهد بود، که مسیر را تنها در صورتی که مسیر منطبقی وجود نداشته باشد اضافه می‌کند. اگر 'append' مشخص شود، رفتار مشابه فرمان 'ip route append' خواهد بود، یعنی مسیر پس از هر مسیر منطبق اضافه می‌شود.
یادداشت: قوانین مربوط به تطابق یک مسیر بین IPv4 و IPv6 تفاوت دارد؛ به عنوان مثال مشخص کردن یک proto متفاوت به این معنی است که یک مسیر منطبق می‌تواند برای IPv4 درج/الحاق شود اما برای IPv6 نه. در صورت تردید، آن را با استفاده از فرمان‌های 'ip route add/prepend/append' آزمایش کنید.
.PP
.nf
    \fBstatic_ipaddress \fR{
        <IPADDR>[/<MASK>] [brd <IPADDR>] [dev <STRING>] [scope <SCOPE>]
                          [label <LABEL>] [peer <IPADDR>] [home]
                          [-nodad] [mngtmpaddr] [noprefixroute]
                          [autojoin] [track_group GROUP] [preferred_lft nn|forever]
        192.168.1.1/24 dev eth0 scope global
        ...
    }
.fi
.PP
.nf
    \fBstatic_routes \fR{
        192.168.2.0/24 via 192.168.1.100 dev eth0 track_group GROUP1

        192.168.100.0/24 table 6909 nexthop via 192.168.101.1 dev wlan0
                         onlink weight 1 nexthop via 192.168.101.2
                         dev wlan0 onlink weight 2

        192.168.200.0/24 dev p33p1.2 table 6909 tos 0x04 protocol bird
                         scope link priority 12 mtu 1000 hoplimit 100
                         advmss 101 rtt 102 rttvar 103 reordering 104
                         window 105 cwnd 106 ssthresh lock 107 realms
                         PQA/0x14 rto_min 108 initcwnd 109 initrwnd 110
                         vrf blue features ecn add

        2001:470:69e9:1:2::4 dev p33p1.2 table 6909 tos 0x04 protocol
                             bird scope link priority 12 mtu 1000
                             hoplimit 100 advmss 101 rtt 102 rttvar 103
                             reordering 104 window 105 cwnd 106 ssthresh
                             lock 107 rto_min 108 initcwnd 109 append
                             initrwnd 110 features ecn fastopen_no_cookie 1
        ...
    }
.fi
.PP
.nf
    \fBstatic_rules \fR{
        from 192.168.2.0/24 table 1 track_group GROUP1

        to 192.168.2.0/24 table 1

        from 192.168.28.0/24 to 192.168.29.0/26 table small iif p33p1
                             oif wlan0 tos 22 fwmark 24/12
                             preference 39 realms 30/20 goto 40

        to 1:2:3:4:5:6:7:0/112 from 7:6:5:4:3:2::/96 table 6908
                               uidrange 10000-19999

        to 1:2:3:4:6:6:7:0/112 from 8:6:5:4:3:2::/96 l3mdev protocol 12
                               ip_proto UDP sport 10-20 dport 20-30
        ...
    }
.fi
.PP
.SH "پرونده‌های ردیابی (Track files)"
.PP
پرونده‌ای را برای پایش اضافه می‌کند. پرونده هر زمان که تغییر کند خوانده خواهد شد. مقدار درون پرونده برای تمام نمونه‌های VRRP، گروه‌های همگام‌سازی و سرورهای واقعی که آن را پایش می‌کنند ثبت خواهد شد.
توجه داشته باشید که پرونده تنها در صورتی خوانده می‌شود که حداقل یک نمونه VRRP، گروه همگام‌سازی یا سرور واقعی آن را پایش کند.

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

برای نمونه‌های VRRP، اگر نتیجه کمتر از -253 باشد، هر چیزی که اسکریپت را پایش می‌کند به وضعیت fault منتقل می‌شود (وزن می‌تواند 254 باشد تا خواندن یک مقدار منفی از پرونده مجاز شود).

اگر نمونه vrrp یا گروه همگام‌سازی مالک نشانی نباشد و نتیجه بین -253 و 253 باشد، نتیجه به اولویت اولیه نمونه VRRP اضافه خواهد شد (یک مقدار منفی اولویت را کاهش می‌دهد)، هرچند اولویت مؤثر به محدوده [1,254] محدود خواهد بود. همین امر برای سرورهای واقعی نیز صادق است.

اگر یک نمونه vrrp که از یک track_file استفاده می‌کند عضو یک گروه همگام‌سازی باشد، مگر اینکه sync_group_tracking_weight روی گروه تنظیم شده باشد، وزن 0 باید تنظیم شود. به همین ترتیب، اگر نمونه vrrp مالک نشانی باشد، وزن 0 نیز باید تنظیم گردد.

برای سرورهای واقعی که پرونده را پایش می‌کنند، محدوده مقادیر خوانده‌شده از پرونده ردیابی 2147483648 تا -2147483648 است. مقدار پس از ضرب در وزن، به وزن IPVS سرور واقعی اضافه خواهد شد. اگر نتیجه کوچکتر یا مساوی 2147483648 باشد، در این صورت بررسی‌کننده در وضعیت FAULT قرار خواهد گرفت.

یادداشت: وزن‌ها برای track_file در سرورهای واقعی هنوز به طور کامل پیاده‌سازی نشده‌اند. به ویژه اجازه دادن به وزن 0، مدیریت مقادیر محاسبه‌شده منفی و بازخوانی (reloading).
.PP
.nf
نحو پرونده ردیابی به شرح زیر است:

\fBtrack_file \fR<STRING> {	# عبارت vrrp_track_file یک مترادف منسوخ‌شده است
    # پرونده مورد ردیابی (وزن پیش‌فرض 1 است)
    \fBfile \fR<QUOTED-STRING>

    # وزن پیش‌فرض اختیاری
    \fBweight \fR<-2147483647..2147483647> [reverse]

    # ایجاد پرونده و/یا مقداردهی اولیه مقدار
    # این باعث می‌شود که در زمان راه‌اندازی در صورت عدم وجود پرونده،
    # مقدار VALUE (پیش‌فرض 0) در پرونده مشخص‌شده نوشته شود،
    # مگر اینکه overwrite مشخص شده باشد که در این صورت هرگونه
    # محتوای موجود پرونده با مقدار مشخص‌شده بازنویسی خواهد شد.
    \fBinit_file \fR[VALUE] [overwrite]
}
.fi
.PP
.SH "فرایندهای ردیابی VRRP (VRRP track processes)"
.PP
.nf
بلوک پیکربندی به این شکل است:

    \fBvrrp_track_process\fR <STRING> {
        # فرایند برای پایش (با پارامترهای اختیاری)
        # یک رشته نقل‌قول‌شده به عنوان یک عنصر واحد در نظر گرفته می‌شود، بنابراین اگر اولین مورد
        # پس از کلیدواژه process نقل‌قول شده باشد، آن نام فرمان خواهد بود.
        # به عنوان مثال:
        #  process "/tmp/a b" param1 "param 2"
        # به معنای فرایندی به نام '/tmp/a b' (بدون علامت‌های نقل‌قول) با ۲ پارامتر
        #  'param1' و 'param 2' خواهد بود.
        \fBprocess\fR <STRING>|<QUOTED-STRING> [<STRING>|<QUOTED-STRING> ...]

        # در صورت تطبیق پارامترها، این گزینه تطبیق جزئی (یعنی n پارامتر اول
        #   دقیقاً مطابقت دارند) یا تطبیق اولیه (یعنی پارامتر آخر ممکن است
        #   طولانی‌تر از پارامتر پیکربندی‌شده باشد) را مشخص می‌کند.
        # برای مشخص کردن اینکه یک فرمان نباید هیچ پارامتری داشته باشد، هیچ
        #   پارامتری را مشخص نکنید، اما param_match را مشخص نمایید.
        param_match {initial|partial}

        # وزن پیش‌فرض (پیش‌فرض 0 است). برای توضیحات reverse، به track_process مراجعه کنید.
        # مقدار 'weight 0 reverse' باعث می‌شود نمونه vrrp در زمان بالا بودن
        #   حد نصاب (quorum) پایین بیاید، و بالعکس.
	# یک وزن غیر صفر اولویت VRRP نمونه VRRP ردیابی‌کننده را تنظیم می‌کند،
	#   در حالی که یک وزن 0 باعث می‌شود نمونه VRRP در صورت شکست فرایند
	#   ردیابی‌شده وارد وضعیت FAULT شود (برای تأثیر "reverse" به بالا مراجعه کنید).
        \fBweight\fR <-254..254> [reverse]

        # حداقل تعداد فرایندها برای موفقیت (پیش‌فرض 1)
        \fBquorum\fR NUM

        # حداکثر تعداد فرایندها برای موفقیت. برای مثال، تنظیم این مقدار
        #   روی 1 در صورت اجرای دو نمونه از فرایند باعث شکست خواهد شد
        #   (اما مراقب forkها باشید - به fork_delay در زیر مراجعه کنید).
        #   تنظیم این مقدار روی 0 به معنای شکست در صورت اجرای هرگونه
        #   فرایند منطبق است.
	#   پیش‌فرض نامحدود است.
        \fBquorum_max\fR NUM

        # زمان تأخیر پس از کسب حد نصاب فرایند پس از fork پیش از
        #   بالا در نظر گرفتن فرایند (به کسری از ثانیه)
        #   این برای جلوگیری از نوسان بالا/پایین شدن برای fork/exec است
        \fBfork_delay\fR SECS

        # زمان تأخیر پس از از دست رفتن حد نصاب فرایند پیش از
        #   پایین در نظر گرفتن فرایند (به کسری از ثانیه)
        #   این برای جلوگیری از نوسان پایین/بالا شدن پس از terminate/parent refork است.
        \fBterminate_delay\fR SECS

        # این fork_delay و terminate_delay را تنظیم می‌کند
        \fBdelay\fR SECS

        # به طور معمول رشته فرایند با نام فرایند مطابقت داده می‌شود،
        #   همان‌طور که در خط :Name در /proc/PID/status نشان داده شده است، مگر اینکه
        #   پارامترها مشخص شده باشند.
        #   این گزینه تطبیق خط فرمان کامل را اجباری می‌کند
        \fBfull_command\fR
    }
.fi
.PP
برای جلوگیری از نیاز به اجرای مکرر track_script جهت پایش وجود فرایندها (اغلب haproxy یا nginx)، دستور vrrp_track_process می‌تواند در حال اجرا بودن سایر فرایندها را پایش کند.
.PP
یک تفاوت با pgrep این است که track_process تطبیق عبارات باقاعده (regular expression) روی رشته فرمان انجام نمی‌دهد، بلکه تطبیق دقیق انجام می‌دهد. عبارت 'pgrep ssh' با فرایند sshd مطابقت خواهد داشت، اما این track_process تطابق نخواهد داشت (معادل pgrep "^ssh$" است).
.PP
اگر full_command استفاده شود (معادل pgrep -f)، پرونده /proc/PID/cmdline استفاده می‌شود، اما هرگونه به‌روزرسانی در cmdline تشخیص داده نخواهد شد (یک فرایند معمولاً نباید آن را تغییر دهد، اگرچه با دقت زیاد امکان‌پذیر است، به عنوان مثال systemd).
.PP
پیش از لینوکس نسخه 3.2، قابلیت track_process از تشخیص تغییرات نام فرایند پشتیبانی نمی‌کرد، زیرا هسته قبل از نسخه 3.2 تغییرات نام فرایند را اطلاع‌رسانی نمی‌کرد. بیشتر فرایندها نام فرایند خود را تغییر نمی‌دهند، اما برای مثال، firefox فرایندهایی را fork می‌کند که نام فرایند خود را به "Web Content" تغییر می‌دهند. نام فرایند اشاره‌شده در اینجا محتویات /proc/PID/comm است.
.PP
حد نصاب (Quorum) تعداد فرایندهای منطبقی است که برای وضعیت OK باید در حال اجرا باشند.
.PP
پارامتر Delay ممکن است زمانی مفید باشد که پیش‌بینی شود یک فرایند ممکن است بازخوانی (متوقف و دوباره راه‌اندازی) شود، و مطلوب نباشد که یک نمونه vrrp قطع و وصل (down و up) شود.
.PP
وزن مثبت به این معنی است که یک وضعیت OK مقدار <weight> را به اولویت تمام نمونه‌های VRRP که آن را پایش می‌کنند اضافه می‌کند. برعکس، در صورت ناکافی بودن فرایندها، وزن منفی از اولویت اولیه کسر خواهد شد.
.PP
اگر نمونه vrrp یا گروه همگام‌سازی مالک نشانی نباشد و نتیجه بین -253 و 253 باشد، نتیجه به اولویت اولیه نمونه VRRP اضافه خواهد شد (یک مقدار منفی اولویت را کاهش می‌دهد)، هرچند اولویت مؤثر به محدوده [1,254] محدود خواهد بود.
.PP
اگر یک نمونه vrrp که از یک track_process استفاده می‌کند عضو یک گروه همگام‌سازی باشد، مگر اینکه sync_group_tracking_weight روی گروه تنظیم شده باشد، وزن 0 باید تنظیم شود. به همین ترتیب، اگر نمونه vrrp مالک نشانی باشد، وزن 0 نیز باید تنظیم گردد.
.PP
دلایل عدم استفاده از pgrep/pidof/killall و موارد مشابه:
.PP
هر بار که pgrep یا معادل آن اجرا می‌شود، در دایرکتوری‌های /proc/[1-9][0-9]* پیمایش کرده و شبه‌پرونده‌های status و cmdline را در هر دایرکتوری باز می‌کند. شبه‌پرونده cmdline به فضای نشانی فرایند نگاشت شده است، بنابراین اگر آن بخش از فرایند به swap منتقل شده باشد، باید از فضای swap واکشی شود. همچنین pgrep و ابزارهای مشابه فرایندهای زامبی را نیز در بر می‌گیرند در حالی که keepalived این کار را نمی‌کند، زیرا آنها در حال اجرا نیستند.
.PP
این پیاده‌سازی تنها در زمان راه‌اندازی دایرکتوری‌های /proc/[1-9][0-9]*/ را پیمایش می‌کند، و در صورتی که 'full_command' برای هیچ‌یک از مدخل‌های vrrp_track_process مشخص نشده باشد، حتی شبه‌پرونده‌های cmdline را نیز نمی‌خواند. پس از راه‌اندازی، از رابط اتصال‌دهنده kernel <-> userspace مربوط به process_events برای دریافت اعلان تغییرات فرایند استفاده می‌کند. اگر full_command برای هر نمونه track_process مشخص شده باشد، شبه‌پرونده cmdline پس از اعلان ایجاد فرایند جدید باید خوانده شود، اما در آن زمان بسیار بعید است که از قبل به swap منتقل شده باشد.
.PP
در یک سیستم شلوغ با تعداد بالایی از ایجاد/خاتمه فرایندها، استفاده از یک track_script به همراه pgrep/pidof/killall ممکن است کارآمدتر باشد، هرچند آن فرایندها در مقایسه با حداقل چیزی که keepalived نیاز دارد ناکارآمد هستند.
.PP
استفاده از pgrep و ابزارهای مشابه روی سیستمی که در حال swapping است می‌تواند تأثیر منفی چشمگیری بر عملکرد سیستم داشته باشد، زیرا مجبور است حافظه منتقل‌شده به swap را از فضای swap واکشی کند و در نتیجه موجب swapping بیشتر شود.
.PP
.SH "پیکربندی BFD (BFD CONFIGURATION)"
.PP
این یک پیاده‌سازی از RFC5880 (تشخیص ارسال دوطرفه یا Bidirectional forwarding detection)
است و می‌تواند برای کار بین ۲ نمونه keepalived پیکربندی شود، اما استفاده از
track_bfdهای بدون وزن میان یک جفت نمونه VRRP از نوع master/backup بدین معنی است که
نمونه VRRP تنها زمانی قادر به بالا آمدن خواهد بود که هر دو نمونه VRRP در حال اجرا باشند،
که تا حدی هدف VRRP را نقض می‌کند.
.PP
این پیاده‌سازی با OpenBFDD (موجود در
https://github.com/dyninc/OpenBFDD) آزمایش شده است.
.PP
.nf
نحو برای bfd_instance به صورت زیر است:

\fBbfd_instance \fR<STRING> {
    # نشانی IP همسایه BFD (مترادف neighbour_ip)
    \fBneighbor_ip \fR<IP ADDRESS>

    # نشانی IP مبدأ مورد استفاده (اختیاری است، مگر برای اطمینان از معتبر
    # بودن درگاه محلی که در این صورت الزامی است)
    \fBsource_ip \fR<IP ADDRESS>

    # کمینه بازه زمانی RX مورد نیاز، برحسب میلی‌ثانیه (دقت به میکروثانیه است، مانند 3.312)
    # (پیش‌فرض 10 میلی‌ثانیه است)
    \fBmin_rx \fR<DECIMAL>

    # کمینه بازه زمانی TX مطلوب، برحسب میلی‌ثانیه (دقت به میکروثانیه است)
    # (پیش‌فرض 10 میلی‌ثانیه است)
    \fBmin_tx \fR<DECIMAL>

    # بازه زمانی مطلوب TX در حالت بیکار، برحسب میلی‌ثانیه (دقت به میکروثانیه است)
    # (پیش‌فرض 1000 میلی‌ثانیه است)
    \fBidle_tx \fR<DECIMAL>

    # تعداد بسته‌های از دست رفته که پس از آن
    # نشست غیرفعال (down) اعلام می‌شود
    # (پیش‌فرض 5 است)
    \fBmultiplier \fR<INTEGER>

    # اجرا در حالت passive (پیش‌فرض active است)
    \fBpassive\fR

    # مقدار ttl خروجی IPv4 برای استفاده (پیش‌فرض 255)
    \fBttl \fR<INTEGER>

    # مقدار hoplimit خروجی IPv6 برای استفاده (پیش‌فرض 64)
    \fBhoplimit \fR<INTEGER>

    # بیشینه کاهش ttl/hoplimit
    #  در بسته دریافتی (پیش‌فرض 0)
    #  (مقدار 255 بررسی تعداد جهش را غیرفعال می‌کند)
    \fBmax_hops \fR<INTEGER>

    # استاندارد RFC 5883 مشخص می‌کند که برای multihop bfd باید از درگاه 4784 استفاده شود، نه
    # درگاه 3784. مشخص کردن multihop این گزینه را فعال می‌کند، اما اگر چندین جهش
    # در حال استفاده است، آنگاه max_hops (بالا را ببینید) نیز باید پیکربندی شود.
    \fBmultihop\fR [<BOOL>]

    # وزن ردیابی پیش‌فرض
    # به طور معمول، هنگام فعال (up) بودن نمونه bfd، وزن‌های مثبت به اولویت نمونه vrrp اضافه
    # می‌شوند و وزن‌های منفی هنگام غیرفعال (down) بودن آن، اولویت را کاهش می‌دهند.
    # با این حال، اگر reverse مشخص شود، یک وزن مثبت هنگام فعال بودن اسکریپت اولویت را کاهش
    # داده و وزن منفی هنگام غیرفعال بودن اسکریپت اولویت را افزایش می‌دهد.
    # مقدار 'weight 0 reverse' باعث می‌شود که نمونه vrrp هنگام فعال بودن نمونه bfd، غیرفعال
    # شود و بالعکس.
    # Weight  Reverse  Script up   Script down
    #  +ve      No	prio +		-
    #  -ve	No	   -	     prio -
    #  +ve      Yes	prio -		-
    #  -ve	Yes	   -	     prio +
    \fBweight\fR <-253:253> [reverse]

    # به طور معمول اعلان‌های رویداد bfd به هر دو فرایند VRRP و checker ارسال می‌شوند.
    # تعیین vrrp یا checker باعث می‌شود اعلان‌های رویداد برای این bfd_instance
    # فقط به فرایند مشخص‌شده ارسال شوند
    \fBvrrp\fR
    \fBchecker\fR
}
.fi
.PP
.SH "پیکربندی VRRPD (VRRPD CONFIGURATION)"
شامل زیربلوک‌های زیر است:
\fBVRRP script(s)،
VRRP synchronization group(s)،
VRRP gratuitous ARP and unsolicited neighbour advert delay group(s)\fR
و
\fBVRRP instance(s)\fR
.PP
.SH "اسکریپت‌های VRRP (VRRP script(s))"
.PP
اسکریپت به صورت دوره‌ای، هر <interval> ثانیه یک‌بار اجرا خواهد شد. کد خروج
آن برای تمام نمونه‌های VRRP که آن را نظارت می‌کنند ثبت می‌شود.
توجه داشته باشید که اسکریپت تنها در صورتی اجرا خواهد شد که دست‌کم یک نمونه VRRP
آن را نظارت کند.

وزن پیش‌فرض برابر با 0 است، به این معنی که هر نمونه VRRP ناظر بر اسکریپت پس از
<fall> شکست متوالی اسکریپت، به وضعیت fault منتقل خواهد شد. پس از آن، <rise> موفقیت متوالی
باعث می‌شود نمونه‌های VRRP از وضعیت fault خارج شوند، مگر اینکه به دلیل اسکریپت‌ها یا رابط‌های
دیگری که ردیابی می‌کنند نیز در وضعیت fault باشند.

وزن مثبت بدین معناست که <rise> موفقیت، مقدار <weight> را به اولویت تمام نمونه‌های VRRP ناظر
بر آن اضافه خواهد کرد. در مقابل، در صورت <fall> شکست، یک وزن منفی از اولویت اولیه کم خواهد شد.
.PP
.nf
نحو اسکریپت vrrp به صورت زیر است:

# یک اسکریپت برای اجرای دوره‌ای اضافه می‌کند. کد خروج آن برای تمام
# نمونه‌های VRRP و گروه‌های همگام‌سازی ناظر بر آن ثبت خواهد شد.
\fBvrrp_script \fR<SCRIPT_NAME> {
    # مسیر اسکریپت برای اجرا
    \fBscript \fR<STRING>|<QUOTED-STRING>

    # ثانیه‌های بین فراخوانی‌های اسکریپت، (پیش‌فرض: 1 ثانیه، دقت میلی‌ثانیه)
    \fBinterval \fR<DECIMAL>

    # ثانیه‌هایی که پس از آن اسکریپت شکست‌خورده تلقی می‌شود (پیش‌فرض = interval، دقت میلی‌ثانیه)
    \fBtimeout \fR<DECIMAL>

    # تنظیم اولویت با این وزن، (پیش‌فرض: 0)
    # برای توضیحات مربوط به reverse، بخش track_script را ببینید.
    # مقدار 'weight 0 reverse' باعث می‌شود نمونه vrrp در زمان فعال بودن
    # اسکریپت غیرفعال شود و بالعکس.
    \fBweight \fR<INTEGER:-253..253> [reverse]

    # تعداد موفقیت‌های لازم برای انتقال به وضعیت OK
    \fBrise \fR<INTEGER>

    # تعداد شکست‌های لازم برای انتقال به وضعیت KO
    \fBfall \fR<INTEGER>

    # نام‌های کاربر/گروه برای اجرای اسکریپت با آن‌ها.
    #  پیش‌فرض گروه، گروه کاربر است
    \fBuser \fRUSERNAME [GROUPNAME]

    # فرض اینکه اسکریپت در ابتدا در وضعیت ناموفق است
    \fBinit_fail\fR
}
.fi
.SH "گروه‌های همگام‌سازی VRRP (VRRP synchronization group(s))"
.PP
گروه همگام‌سازی VRRP (یا VRRP Sync Group) افزونه‌ای برای پروتکل VRRP است. هدف اصلی تعریف دسته‌ای
از نمونه‌های VRRP برای همگام‌سازی با یکدیگر است، به طوری که انتقال وضعیت یک نمونه بر سایر اعضای گروه
منعکس شود.
.sp
علاوه بر این، یک ویژگی اطلاع‌رسانی (notify) پیشرفته برای رهگیری دقیق انتقال وضعیت وجود دارد.
.sp
همچنین می‌توانید چندین سیاست ردیابی تعریف کنید تا انتقال وضعیت بر اساس یک رویداد خارجی مانند
رابط، اسکریپت‌ها، پرونده یا BFD اعمال شود.
.sp
\fBمهم\fR: برای اجرای قابل اطمینان یک گروه SYNC، حیاتی است که تمام نمونه‌های درون
گروه MASTER باشند یا همگی در وضعیت BACKUP یا FAULT قرار داشته باشند. وضعیتی
که در آن برخی نمونه‌ها در ماشین A اولویت بالاتری دارند و برخی دیگر در ماشین B اولویت
بالاتری دارند منجر به انتخابات مجدد مداوم خواهد شد. به همین دلیل، هنگام گروه‌بندی نمونه‌ها،
تمام اسکریپت‌ها/پرونده‌های ردیابی که برای نمونه‌های عضو VRRP پیکربندی شده‌اند باید فاقد
وزن ردیابی باشند (یعنی برابر با صفر باشند). هر ردیاب با اولویت غیرصفر نادیده گرفته خواهد شد.
.PP
.nf
نحو vrrp_sync_group به صورت زیر است:

\fBvrrp_sync_group \fR<STRING> {
    \fBgroup \fR{
        # نام vrrp_instance (پایین را ببینید)
        # مجموعه‌ای از رشته‌های VRRP_Instance
        <STRING>
        <STRING>
        ...
    }

    # ردیابی رابط، اسکریپت، پرونده و bfd توسط گروه همگام‌سازی، وضعیت/اولویت تمام
    # نمونه‌های VRRP عضو گروه همگام‌سازی را به‌روزرسانی خواهد کرد.
    # مقدار 'weight 0 reverse' باعث می‌شود هنگام فعال بودن رابط، نمونه vrrp
    # غیرفعال شود و بالعکس.
    \fBtrack_interface \fR{
        eth0
        eth1
        eth2 weight <-253..253> [reverse]
        ...
    }

    # افزودن یک اسکریپت ردیابی به گروه همگام‌سازی (<SCRIPT_NAME> نام ورودی
    # vrrp_script است)؛ در صورت غیرفعال شدن هر یک از این‌ها در حالت بدون وزن، به وضعیت FAULT می‌رود.
    # گزینه reverse باعث معکوس شدن جهت تنظیم اولویت می‌شود.
    \fBtrack_script \fR{
        <SCRIPT_NAME>
        <SCRIPT_NAME> weight <-253..253> [reverse|noreverse]
    }

    # پرونده‌هایی که وضعیت آن‌ها را نظارت می‌کنیم، مقدار به اولویت مؤثر افزوده می‌شود.
    # <STRING> نام یک track_file است
    # مقدار پیش‌فرض weight بر اساس وزن پیکربندی‌شده در track_file تعیین می‌شود
    \fBtrack_file \fR{
        <STRING>
        <STRING> weight <-254..254> [reverse|noreverse]
        ...
    }

    # فرایند برای نظارت، مقدار weight به اولویت مؤثر اضافه می‌شود.
    # <STRING> نام یک vrrp_track_process است
    # مقدار پیش‌فرض weight بر اساس وزن پیکربندی‌شده در vrrp_track_process تعیین می‌شود.
    # برای شرح weight به track_process در vrrp_instance مراجعه کنید.
    \fBtrack_process \fR{
        <STRING>
        <STRING> weight <-254..254> [reverse|noreverse]
        ...
    }

    # نمونه‌های BFD که نظارت می‌کنیم، مقدار به اولویت مؤثر افزوده می‌شود.
    # <STRING> نام یک نمونه BFD است
    \fBtrack_bfd \fR{
        <STRING>
        <STRING>
        <STRING> weight <INTEGER: -253..253> [reverse|noreverse]
        ...
    }

    # اسکریپت‌های اطلاع‌رسانی و هشدارها اختیاری هستند
    #
    # نام پرونده‌های اسکریپت‌ها برای اجرا در زمان تغییر وضعیت می‌توانند بدون نقل‌قول باشند (اگر
    # فقط نام پرونده باشد) یا داخل نقل‌قول قرار گیرند (اگر پارامتر داشته باشد)
    # مقادیر username و groupname کاربر و گروهی را مشخص می‌کنند که
    # اسکریپت‌ها باید تحت آن اجرا شوند. اگر username مشخص شود،
    # گروه به طور پیش‌فرض به گروه کاربر تنظیم می‌شود.
    # اگر username مشخص نشود، پیش‌فرض آن‌ها به script_user و script_group
    # سراسری تنظیم خواهد شد

    # انتقال به وضعیت MASTER
    \fBnotify_master \fR/path/to_master.sh [username [groupname]]

    # انتقال به وضعیت BACKUP
    \fBnotify_backup \fR/path/to_backup.sh [username [groupname]]

    # انتقال به وضعیت FAULT
    \fBnotify_fault \fR"/path/fault.sh VG_1" [username [groupname]]

    # اجرا در هنگام متوقف کردن vrrp
    \fBnotify_stop \fR<STRING>|<QUOTED-STRING> [username [groupname]]

    # گزینه notify_deleted باعث می‌شود پس از حذف یک نمونه vrrp در زمان بارگذاری مجدد،
    # به جای FAULT پیش‌فرض، مقدار DELETED به اعلان‌ها ارسال شود.
    # اگر اسکریپتی مشخص شده باشد، آن اسکریپت نیز اجرا خواهد شد.
    \fBnotify_deleted [\fR<STRING>|<QUOTED-STRING> [username [groupname]]]

    # برای هرگونه انتقال وضعیت.
    # اسکریپت "notify" پس از اسکریپت(های) *notify_ فراخوانی می‌شود و
    # با ۴ آرگومان اضافی پس از آرگومان‌های پیکربندی‌شده توسط Keepalived
    # اجرا می‌گردد:
    #   $(n-3) = "GROUP"|"INSTANCE"
    #   $(n-2) = نام گروه یا نمونه
    #   $(n-1) = وضعیت هدف انتقال (stop فقط برای نمونه‌ها کاربرد دارد)
    #            ("MASTER"|"BACKUP"|"FAULT"|"STOP"|"DELETED")
    #   $(n)   = مقدار اولویت
    #   $(n-3) و $(n-1) همواره با حروف بزرگ ارسال می‌شوند و رشته‌های ممکن
    # ارسالی همان موارد فهرست‌شده در بالا هستند
    #   ("GROUP"/"INSTANCE", "MASTER"/"BACKUP"/"FAULT"/"STOP"/"DELETED")
    # (توجه: DELETED فقط برای نمونه‌ها کاربرد دارد)
    \fBnotify \fR<STRING>|<QUOTED-STRING> [username [groupname]]

    # خروجی fifo اعلان مانند ۴ پارامتر آخر اسکریپت "notify" است، به همراه افزودن
    # "MASTER_RX_LOWER_PRI" به جای وضعیت برای یک نمونه، و همچنین "MASTER_PRIORITY"
    # و "BACKUP_PRIORITY" در صورتی که اولویت تغییر کند و notify_priority_changes پیکربندی شده باشد.
    # مقدار MASTER_RX_LOWER_PRI زمانی استفاده می‌شود که یک master نیاز به تنظیم وضعیتی خارجی
    # داشته باشد، مانند تنظیم یک نشانی IP ثانویه هنگام استفاده از Amazon AWS؛ اگر یک keepalived دیگر
    # به دلیل قطعی ارتباط به master تبدیل شده باشد، نمونه با اولویت پایین‌تر نشانی IP ثانویه
    # را تصاحب خواهد کرد و master اصلی باید بتواند آن را بازیابی کند.

    # ارسال اعلان‌های FIFO برای تغییرات اولویت vrrp
    \fBnotify_priority_changes\fR <BOOL>

    # ارسال اعلان ایمیل در زمان تغییر وضعیت،
    # با استفاده از نشانی‌های موجود در global_defs در بالا (پیش‌فرض no است،
    # مگر اینکه smtp_alert/smtp_alert_vrrp سراسری تنظیم شده باشد)
    \fBsmtp_alert \fR<BOOL>

    # منسوخ شده است. به جای آن از track_interface، track_script و
    # track_file در vrrp_sync_groups استفاده کنید.
    \fBglobal_tracking\fR

    # اجازه به گروه‌های همگام‌سازی برای استفاده از وزن‌های متفاوت.
    # این احتمالاً کار نخواهد کرد، اما جایگزینی برای
    # global_tracking است در صورتی که وزن‌های متفاوتی در نمونه‌های
    # مختلف vrrp در همان گروه همگام‌سازی استفاده شده باشد.
    \fBsync_group_tracking_weight\fR
}
.fi
.SH "گروه‌های تأخیر اعلان همسایه ناخواسته و ARP بی‌دلیل VRRP (VRRP gratuitous ARP and unsolicited neighbour advert delay group(s))"
.PP
تنظیم تأخیر بین ارسال ARP‌های بی‌دلیل (gratuitous ARP)
و اعلان‌های همسایه ناخواسته (unsolicited neighbour advertisement) را مشخص می‌کند. این تنظیم برای زمانی
در نظر گرفته شده که سوییچ بالادست قادر به مدیریت هجوم بسته‌های ARP/NA نباشد.

هنگامی که محدودیت‌ها روی یک رابط فیزیکی اعمال می‌شوند از interface استفاده کنید.
هنگامی که گروهی از رابط‌ها به یک سوییچ متصل هستند و محدودیت‌ها بر کل سوییچ اعمال می‌شوند
از interfaces استفاده کنید.

\fBتوجه\fR: در هر بلوک فقط باید یکی از interface یا interfaces استفاده شود.

اگر vrrp_garp_interval یا vrrp_gna_interval سراسری تنظیم شده باشند، هر
رابطی که در garp_group مشخص نشده باشد، تنظیمات سراسری را بر مبنای هر رابط به ارث
خواهد برد.
.PP
.nf
نحو garp_group به صورت زیر است:

\fBgarp_group \fR{
    # تنظیم بازه زمانی بین ARPهای بی‌دلیل (برحسب ثانیه، دقت میکروثانیه)
    \fBgarp_interval \fR<DECIMAL>

    # تنظیم بازه زمانی پیش‌فرض بین NAهای ناخواسته (برحسب ثانیه، دقت میکروثانیه)
    \fBgna_interval \fR<DECIMAL>

    # رابط فیزیکی که بازه‌های زمانی بر آن اعمال می‌شوند
    \fBinterface \fR<STRING>

    # فهرستی از رابط‌ها که تأخیرها روی آن‌ها تجمیع می‌شوند.
    \fBinterfaces \fR{
        <STRING>
        <STRING>
        ...
    }
}
.fi
.SH "نمونه‌های VRRP (VRRP instance(s))"
.PP
یک VRRP Instance ویژگی کلیدی پروتکل VRRP است. این بخش رفتار VRRP را برای اجرا روی یک رابط مشخص، تعریف و پیکربندی می‌کند. هر VRRP Instance به یک رابط یکتا مرتبط است.
.PP
.nf
نحو برای vrrp_instance چنین است:

\fBvrrp_instance \fR<STRING> {
    # وضعیت اولیه، MASTER|BACKUP
    # اگر priority برابر ۲۵۵ باشد، در صورت تعیین state MASTER، نمونه بلافاصله
    # به MASTER تغییر وضعیت می‌دهد؛ در غیر این صورت نمونه بسته به priority
    # بین ۳ تا ۴ بازه advert منتظر می‌ماند تا بتواند تغییر وضعیت دهد.
    \fBstate \fRMASTER

    # رابط مربوط به inside_network، مقید شده توسط vrrp.
    # یادداشت: در صورت استفاده از unicasting، تا زمانی که نشانی‌های unicast نشانی‌های
    #   link local مربوط به IPv6 نباشند می‌توان از رابط صرف‌نظر کرد (برای نمونه در صورت
    #   استفاده از مسیریابی نامتقارن، این کار لازم است).
    #   اگر از رابط صرف‌نظر شود، تمام VIPها و eVIPها باید رابطی که باید رویش
    #   پیکربندی شوند را تعیین کنند، در غیر این صورت به رابط پیش‌فرض
    #   افزوده خواهند شد.
    \fBinterface \fReth0

    # در صورت استفاده از unicasting بدون تعیین یک رابط، می‌توان VRF مورد نظر
    # برای فعالیت در آن را تعیین کرد.
    \fBvrf \fR VRF_IF

    # استفاده از VRRP Virtual MAC (macvlan).
    # رابط macvlan روی رابط پیکربندی‌شده برای نمونه VRRP ساخته می‌شود، و VIPها و eVIPهای
    # خانواده نشانی مطابق که رابط متفاوتی را تعیین نکرده باشند روی
    # macvlan پیکربندی خواهند شد.
    # اعلان‌های VRRP نیز از طریق رابط macvlan ارسال و دریافت می‌شوند،
    # مگر اینکه vmac_xmit_base پیکربندی شده باشد.
    # \fBیادداشت\fR: اگر net.ipv4.conf.all.rp_filter در sysctl تنظیم شده باشد،
    # و این vrrp_instance یک نمونه IPv4 باشد، استفاده از این گزینه باعث
    # می‌شود تا رابط‌های جداگانه به مقدار بزرگ‌تر از میان تنظیم کنونی‌شان و
    # all.rp_filter به‌روزرسانی شوند، همان‌طور که default.rp_filter به‌روزرسانی می‌شود، و all.rp_filter
    # برابر با 0 تنظیم خواهد شد.
    # تنظیمات اصلی هنگام خاتمه بازیابی می‌شوند.
    # \fBیادداشت ۲\fR: در صورت استفاده از use_vmac با همتایان unicast،
    # باید vmac_xmit_base تنظیم شود.
    # نشانی MAC را می‌توان تنها با ۵ هشت‌بیت (octet) تعیین کرد که در این صورت
    # virtual_router_id به عنوان آخرین هشت‌بیت استفاده خواهد شد.
    # اگر \fBnetlink_notify_msg\fR تعیین شود، هنگامی که keepalived یک رابط macvlan ایجاد
    # می‌کند، ارسال یک پیام netlink را برای رابط پایه تحمیل خواهد کرد
    # چرا که هسته پیامی ارسال نمی‌کند، حتی اگر وضعیت بی‌قید (promiscuity) رابط
    # پایه به‌روزرسانی شده باشد.
    # به صورت پیش‌فرض VMAC در همان گروه پیوند رابط والد ایجاد می‌شود.
    # تعیین group GROUP_ID (که GROUP_ID در آن یک شماره گروه معتبر یا یک
    # نام در /etc/iproute2/group است) رابط را در گروه مشخص‌شده ایجاد می‌کند.
    # در صورتی که می‌خواهید از نام رابط "group" استفاده کنید، گزینه name قابل تعیین است.
    \fBuse_vmac \fR[[name] <VMAC_INTERFACE_NAME>] [MAC_ADDRESS] [netlink_notify_msg] [group GROUP_ID]

    # گزینه use_vmac_addr برای ایجاد رابط‌های VMAC (macvlan) برای
    # هر رابطی استفاده می‌شود که توسط یک VIP یا eVIP به کار رفته در حالی که
    # رابط با رابطی که نمونه VRRP روی آن پیکربندی شده یکسان نیست
    # یا خانواده نشانی eVIP با نمونه VRRP همخوانی ندارد. به عنوان روش جایگزین، می‌توان
    # use_vmac را برای هر VIP/eVIP که یک رابط (dev) را تعیین می‌کند مشخص کرد.
    # یادداشت: اگر use_vmac تعیین شود و یک eVIP از خانواده نشانی یکسانی با
    # نمونه vrrp نباشد، مگر اینکه use_vmac_addr تعیین شده باشد، یا
    # use_vmac برای eVIP مشخص شده باشد، eVIP روی VMAC نمونه vrrp پیکربندی
    # خواهد شد که نشانی MAC نادرستی برای خانواده نشانی eVIP خواهد داشت.
    \fBuse_vmac_addr\fR

    # ارسال/دریافت پیام‌های VRRP از رابط پایه به جای
    # رابط VMAC
    \fBvmac_xmit_base\fR

    # استفاده از رابط IPVLAN. برنامه keepalived یک رابط ipvlan در
    # حالت L2 روی رابط تعیین‌شده ایجاد خواهد کرد.
    # برای نمونه‌های IPv4 یک نشانی IP الزامی است، برای IPv6
    # نشانی اختیاری است که در آن حالت از نشانی link local
    # استفاده خواهد شد.
    # پرچم‌های حالت به صورت پیش‌فرض bridge هستند. یادداشت: پرچم‌های حالت باید برای
    # تمام ipvlanها روی یک رابط زیربنایی یکسان باشند.
    # پیکربندی یک نام رابط ایمن‌تر است، تا در صورت خرابی و راه‌اندازی
    # مجدد keepalived، بتواند با اطمینان بیشتری رابط ایجادشده قبلی
    # را بیابد.
    # اگر می‌خواهید از نامی استفاده کنید که باعث خطای تجزیه می‌شود (مانند "bridge")
    # می‌توان گزینه name را مشخص کرد.
    # برای توضیحات درباره گزینه group، بخش use_vmac را ببینید.
    \fBuse_ipvlan \fR[[name] <INTERFACE_NAME>] [IP_ADDRESS] [bridge|private|vepa] [group GROUP_ID]

    # اجبار نمونه به استفاده از IPv6 (این گزینه منسوخ شده است چرا که
    # نشانی‌های مجازی ip تعیین می‌کنند که IPv4 استفاده شود یا IPv6).
    \fBnative_ipv6\fR

    # نادیده‌گرفتن خطاهای رابط VRRP (پیش‌فرض تنظیم‌نشده).
    # یادداشت: هنگام استفاده از IPv6، غیرفعال‌سازی مدیریتی رابط، مثلاً
    #   'ip link set IF down' به طور پیش‌فرض موجب حذف تمام نشانی‌های IPv6
    #   از رابط می‌شود و در نتیجه نمونه VRRP به دلیل حذف نشانی‌ها
    #   به وضعیت fault می‌رود. تنظیم net.ipv6.conf.IF.keep_addr_on_down
    #   روی 1 در sysctl اجازه می‌دهد نشانی‌های غیر link-local هنگام خاموش شدن رابط
    #   باقی بمانند.
    \fBdont_track_primary\fR

    # اختیاری، این موارد را نیز نظارت می‌کند.
    # در صورت خرابی هر یک از این موارد و در صورت بی‌وزن بودن به وضعیت FAULT می‌رود.
    # هنگامی که وزنی در track_interface تعیین شود، به جای انتقال نمونه vrrp
    # به وضعیت FAULT در صورت بروز خطا، اولویت آن در هنگام بالا بودن رابط به اندازه
    # وزن افزایش می‌یابد (برای وزن‌های مثبت)، یا در هنگام پایین بودن رابط به اندازه
    # مقدار مطلق وزن کاهش می‌یابد (برای وزن‌های منفی)، مگر اینکه reverse تعیین شده باشد
    # که در این صورت جهت تنظیم اولویت برعکس می‌شود.
    # وزن باید مقداری بین -253 تا +253 شامل خود آن‌ها باشد.
    # مقدار 0 رفتار پیش‌فرض است که به این معنی است که خرابی به معنای وضعیت
    # FAULT است. روش معمول استفاده از وزن‌های مثبت برای شمارش تعداد محدودی
    # از سرویس‌های سالم است تا سروری با بالاترین شمارش، master شود.
    # وزن‌های منفی برای شمارش خرابی‌های غیرمنتظره در میان تعداد زیادی رابط بهتر هستند،
    # زیرا حتی با تعداد زیاد رابط‌ها نیز اشباع نمی‌شود. از reverse برای افزایش اولویت در صورت پایین بودن یک رابط استفاده کنید
    \fBtrack_interface \fR{
        eth0
        eth1
        eth2 weight <-253..253> [reverse]
         ...
    }

    # افزودن یک اسکریپت ردیابی به رابط
    # (<SCRIPT_NAME> نام مدخل vrrp_script است)
    # همان اصول track_interface را می‌توان برای مدخل‌های track_script نیز به کار برد،
    # به جز اینکه وزن تعیین‌نشده به این معنی است که وزن پیش‌فرض اعلان‌شده در
    # اسکریپت استفاده خواهد شد (که خود به صورت پیش‌فرض 0 است).
    # مقدار reverse باعث معکوس شدن جهت تنظیم اولویت می‌شود.
    \fBtrack_script \fR{
        <SCRIPT_NAME>
        <SCRIPT_NAME> weight <-253..253> [reverse|noreverse]
    }

    # پرونده‌هایی که وضعیت آن‌ها نظارت می‌شود، مقدار به اولویت مؤثر افزوده می‌شود.
    # <STRING> نام یک track_file است
    \fBtrack_file \fR{
        <STRING>
        <STRING>
        <STRING> weight <-254..254> [reverse|noreverse]
        ...
    }

    # وزن‌های مثبت هنگام در حال اجرا بودن فرایند اضافه/کم می‌شوند،
    # وزن‌های منفی هنگام عدم اجرا کم/اضافه می‌شوند.
    # اگر reverse تعیین شود، افزایش/کاهش معکوس می‌شود.
    # <STRING> نام یک vrrp_track_process است
    # مقدار weight به طور پیش‌فرض برابر با وزن پیکربندی‌شده در vrrp_track_process است
    \fBtrack_process \fR{
        <STRING>
        <STRING> weight <-254..254> [reverse|noreverse]
        ...
    }

    # نمونه‌های BFD که نظارت می‌کنیم، مقدار به اولویت مؤثر افزوده می‌شود،
    # مگر اینکه reverse تعیین شود که در این صورت مقدار کسر می‌شود.
    # وزن‌های مثبت هنگام بالا بودن نمونه bfd اضافه/کم می‌شوند،
    # وزن‌های منفی هنگام پایین بودن نمونه bfd کم/اضافه می‌شوند.
    # <STRING> نام یک نمونه BFD است
    \fBtrack_bfd \fR{
        <STRING>
        <STRING>
        <STRING> weight <INTEGER: -253..253> [reverse|noreverse]
        ...
    }

    # نشانی IP پیش‌فرض برای مقیدسازی vrrpd، نشانی IP اصلی
    # روی رابط است. اگر می‌خواهید مکان vrrpd را پنهان کنید،
    # از این IP به عنوان src_addr برای بسته‌های vrrp چندپخشی (multicast) یا
    # تک‌پخشی (unicast) استفاده کنید. (از آنجا که چندپخشی است، vrrpd بسته پاسخ را
    # بدون توجه به اینکه چه src_addrای استفاده شده دریافت خواهد کرد).
    # اختیاری
    \fBmcast_src_ip \fR<IPADDR>
    \fBunicast_src_ip \fR<IPADDR>

    # تعیین یک نشانی چندپخشی جایگزین برای استفاده به عنوان مقصد
    # اعلان‌های VRRP و برای گوش دادن به اعلان‌ها. توجه داشته باشید اگر از
    # چندین نمونه VRRP با VMACها و نشانی‌های چندپخشی متفاوت
    # و VRID یکسان استفاده می‌کنید، باید نشانی‌های MAC جایگزین را
    # حداقل برای همه به جز یکی از VMACها تعیین کنید.
    # نشانی‌های چندپخشی IPv6 باید link-local باشند، یعنی با :ffX2 شروع شوند
    # استفاده از نشانی‌های چندپخشی مختلف با IPv6 روی همان رابط بدون
    # استفاده از VMACها تنها در صورتی پشتیبانی می‌شود که هسته از IPV6_MULTICAST_ALL
    # پشتیبانی کند (از لینوکس نسخه v4.20).
    \fBmcast_dst_ip \fR<MULTICAST_IPADDR>

    # اگر src_ip پیکربندی‌شده وجود نداشته باشد یا حذف شود، نمونه را
    # در وضعیت fault قرار می‌دهد
    \fBtrack_src_ip\fR

    # نسخه VRRP برای اجرا روی رابط
    #  پیش‌فرض پارامتر سراسری vrrp_version است، اما نمونه‌های IPv6 همیشه
    #  از نسخه 3 استفاده خواهند کرد.
    \fBversion \fR<2 or 3>

    # گزینه زیر بررسی این مورد را فعال می‌کند که در حالت unicast،
    # نشانی مبدأ بسته VRRP یکی از همتایان unicast ما باشد.
    \fBcheck_unicast_src\fR

    # عدم ارسال اعلان‌های VRRP روی یک گروه چندپخشی VRRP.
    # در عوض اعلان‌ها را به فهرست زیر از
    # نشانی‌های ip با استفاده از unicast ارسال می‌کند. استفاده از
    # FSM و قابلیت‌های VRRP در محیط شبکه‌ای که
    # multicast در آن پشتیبانی نمی‌شود، می‌تواند جالب باشد!
    # نشانی‌های IP تعیین‌شده می‌توانند IPv4 و همچنین IPv6 باشند.
    # اگر min_ttl و/یا max_ttl تعیین شوند، TTL/حد جهش (hop limit)
    # هر بسته دریافت‌شده در برابر محدوده TTL مشخص‌شده بررسی می‌شود
    # و در صورت خارج بودن از محدوده دور ریخته می‌شود.
    # تعیین min_ttl یا max_ttl گزینه check_unicast_src را فعال می‌کند.
    \fBunicast_peer \fR{
        <IPADDR> [min_ttl {0..255}] [max_ttl {0..255}]
        ...
    }

    # امکان فعالیت در حالت unicast بدون هیچ همتایی وجود ندارد.
    # تا نسخه v2.2.4، keepalived در صورتی که هیچ همتایی تعیین نشده بود اما کلیدواژه
    # unicast مشخص شده بود، بدون اعلام در حالت multicast کار می‌کرد.
    # استفاده از این کلیدواژه پیش‌فرض شدن به multicast در صورت عدم تعیین
    # همتا را متوقف کرده و نمونه VRRP را در وضعیت fault قرار می‌دهد.
    \fBunicast_fault_no_peer\fR

    # تعیین TTL/HLIM تک‌پخشی برای ارسال اعلان‌های unicast
    \fBunicast_ttl\fR {0..255}

    # محاسبه چکسام (checksum) هنگام استفاده از VRRPv3 بعد از نسخه v1.3.6 تغییر کرد.
    #  دلیل تغییر این است که keepalived چکسام را حتی زمانی که از
    #  unicast استفاده می‌کرد با استفاده از نشانی multicast محاسبه می‌نمود، در حالی که
    #  چکسام باید با استفاده از نشانی واقعی موجود در سرایند IPv4
    #  محاسبه شود.
    #  تنظیم این پرچم استفاده از الگوریتم چکسام قدیمی را برای
    #  حفظ سازگاری عقبروی اجباری می‌کند، هرچند keepalived در صورت مشاهده
    #  چکسام نسخه قدیمی به هر حال تلاش می‌کند سازگاری را حفظ کند. تعیین never تشخیص خودکار
    #  چکسام‌های قدیمی را غیرفعال می‌کند. [این گزینه ممکن است فعال نباشد - خروجی
    #  `keepalived -v` را برای OLD_CHKSUM_COMPAT بررسی کنید.]
    \fBold_unicast_checksum \fR[never]

    # برخی تولیدکنندگان (مانند Cisco و Juniper)، بخش 5.2.8 از RFC5798 را
    #  صرفاً برای IPv6 تعبیر می‌کنند، چرا که شبه‌سرایند (pseudo-header) در RFC2460
    #  تنها برای IPv6 مشخص شده است، اگرچه بیشتر پیاده‌سازی‌های متن‌باز
    #  از جمله tcpdump/wireshark، شبه‌سرایند را برای IPv4 نیز لحاظ می‌کنند.
    #  برنامه Keepalived به طور پیش‌فرض برای VRRPv3 IPv4 نیز از شبه‌سرایند استفاده می‌کند.
    #  تنظیم این گزینه، گنجاندن شبه‌سرایند را در محاسبه چکسام
    #  برای VRRPv3 IPv4 غیرفعال می‌کند.
    # برای انطباق با RFC9568، این گزینه باید تنظیم شود.
    \fBv3_checksum_as_v2\fR [<BOOL>]

    # تنظیمات مختص رابط، همانند پارامترهای سراسری.
    # پیش‌فرض برابر پارامترهای سراسری است
    \fBgarp_master_delay \fR10
    \fBgarp_master_repeat \fR1
    \fBgarp_lower_prio_delay \fR10
    \fBgarp_lower_prio_repeat \fR1
    \fBgarp_master_refresh \fR60
    \fBgarp_master_refresh_repeat \fR2
    \fBgarp_extra_if [all] \fR100	# تعیین 0 این ویژگی را غیرفعال می‌کند

    # مستندات RFC مربوط به VRRP بیان می‌کنند که تایمر master down برابر ۳ بازه advert به علاوه
    # یک زمان انحراف (skew time) است. تنظیم down_timer_adverts به این معنی است که تایمر master down
    # برابر با down_timer_adverts بازه advert خواهد بود.
    # پیش‌فرض 3 است تا با RFCهای VRRP مطابقت داشته باشد. تنظیم این مورد روی هر مقدار دیگر،
    # انحراف از پروتکل VRRP محسوب می‌شود. تمام مسیریاب‌های مجازی برای یک نمونه
    # VRRP مفروض، باید (MUST) از مقدار یکسانی استفاده کنند.
    \fBdown_timer_adverts \fR[1-100]

    # برخی کاربران با پیام‌های گزارش "thread timer expired" مواجه می‌شوند. این پیام‌ها ناشی از این
    # است که هسته پس از انقضای یک تایمر، keepalived را به اندازه کافی سریع زمان‌بندی نمی‌کند،
    # که همیشه به دلیل عدم دسترسی به منابع کافی CPU است (اگر keepalived در یک
    # ماشین مجازی اجرا می‌شود ممکن است به دلیل عدم زمان‌بندی خود VM باشد)، یا
    # اجرا نشدن keepalived با اولویت به اندازه کافی بالا است (گزینه‌های زمان‌بندی realtime
    # در بالا را ببینید).
    # اگر nopreempt پیکربندی شده باشد و نمونه دیگری master شده باشد، شرایطی وجود
    # دارد که در آن لازم است این نمونه فعالیت را به عنوان master از سر نگیرد، بلکه
    # به backup تغییر وضعیت دهد.
    # در صورت استفاده از این گزینه (و پیکربندی nopreempt)، برنامه keepalived محاسبه خواهد کرد
    # که آیا ممکن است نمونه دیگری کنترل را به دست گرفته باشد یا خیر (بر اساس بازه advert و
    # بالاترین اولویت سایر نمونه‌ها - پیش‌فرض 254 مگر اینکه با این گزینه مشخص
    # شده باشد)، و اگر آن زمان از هنگام ارسال آخرین advert منقضی شده باشد،
    # نمونه VRRP به وضعیت backup بازمی‌گردد (به یاد داشته باشید که هنگام محاسبه بالاترین
    # اولویت سایر نمونه‌ها، هرگونه وزن track_script و غیره را لحاظ کنید).
    \fBtimer_expired_backup \fR[HIGHEST_PRIORITY_OF_OTHER_INSTANCES]

    # اگر اجرای keepalived برای یک نمونه VRRP بیش از ۲ بازه advert به تأخیر بیفتد،
    # این احتمال وجود دارد که نمونه دیگری به عنوان master کنترل را به دست گرفته باشد.
    # اگر یک advert با اولویت پایین‌تر دریافت شد، advert دیگری ارسال نکن.
    # این موجب پایبندی به RFCها می‌شود (به صورت پیش‌فرض برابر پارامتر سراسری
    # vrrp_lower_priority_dont_send_advert است).
    \fBlower_prio_no_advert \fR[<BOOL>]

    # اگر ما master باشیم و یک advert با اولویت بالاتر دریافت کنیم، پیش از تغییر وضعیت
    # به backup، یک advert ارسال کن (که اولویت کمتری نسبت به master دیگر خواهد داشت).
    # این بدان معنی است که اگر master دیگر garp_lower_prio_repeat را تنظیم
    # کرده باشد، پیام‌های garp را مجدداً ارسال خواهد کرد. این برای رفع مشکل
    # وجود دو master هم‌زمان است، زمانی که آخرین پیام‌های GARP
    # دیده‌شده از طرف ما بوده‌اند.
    \fBhigher_prio_send_advert \fR[<BOOL>]

    # عدد یکتای دلخواه از 1 تا 255
    # برای متمایز ساختن چندین نمونه از vrrpd استفاده می‌شود
# در حال اجرا روی رابط شبکه، خانواده نشانی و چندپخشی/تک‌پخشی یکسان
    # (و در نتیجه سوکت یکسان).
    # یادداشت: استفاده از virtual_router_id یکسان با خانواده نشانی یکسان
    # روی رابط‌های مختلف، در برخی سوئیچ‌های شبکه ایجاد مشکل کرده است؛
    # اگر با استفاده از virtual_router_id یکسان روی رابط‌های مختلف با مشکل
    # مواجه شدید و مشکل با تکراری نبودن virtual_router_idها برطرف شد،
    # احتمالاً سوئیچ‌های شبکه شما به درستی کار نمی‌کنند.
    #
    # در حالی که به طور کلی تکرار نکردن virtual_router_id روی رابط شبکه
    # یکسان مهم است، یک حالت استثنا هنگام استفاده از unicasting وجود دارد؛
    # اگر همتایان تک‌پخشی (unicast peers) برای نمونه‌های vrrp با
    # virtual_router_idهای تکراری روی رابط شبکه همپوشانی نداشته باشند،
    # می‌توان virtual_router_idها را تکرار کرد.
    # همچنین تکرار virtual_router_id روی یک رابط با multicasting در صورت
    # استفاده از نشانی‌های چندپخشی متفاوت امکان‌پذیر است (mcast_dst_ip را ببینید).
    \fBvirtual_router_id \fR51

    # برای انتخاب MASTER، بالاترین priority برنده می‌شود.
    # محدوده معتبر مقادیر priority بین [1-255] است، که در آن priority با
    # مقدار 255 به معنای «مالک نشانی» (address owner) است.
    # برای MASTER شدن، توصیه می‌شود این مقدار را 50 واحد بیشتر از سایر
    # ماشین‌ها قرار دهید. تمام سیستم‌ها باید اولویت‌های متفاوتی داشته باشند تا
    # رفتار معین و قطعی باشد. اگر می‌خواهید از در دست گرفتن نقش master توسط
    # نمونه‌ای با اولویت بالاتر هنگام راه‌اندازی جلوگیری کنید، به جای استفاده از اولویت‌های
    # برابر، no_preempt را پیکربندی کنید.
    # اگر no_accept پیکربندی شده باشد (یا vrrp_strict که حالت no_accept
    # را نیز تنظیم می‌کند)، سیستم بسته‌های ارسالی به VIPs/eVIPs را دریافت نخواهد کرد
    # مگر اینکه vrrp_instance دارای priority برابر 255 باشد،
    # و VIPs/eVIPs فقط می‌توانند برای مقاصد مسیریابی استفاده شوند.
    # علاوه بر این، اگر نمونه‌ای با priority برابر 255 پیکربندی شده باشد، اولویت آن
    # توسط track_scripts ،track_process و غیره قابل کاهش نیست، و به همین ترتیب
    # track_scripts و غیره در صورتی که اولویت پیکربندی‌شده 255 نباشد، نمی‌توانند
    # آن را به 255 افزایش دهند.
    \fBpriority \fR100

    # بازه زمانی VRRP Advert به ثانیه (مانند 0.92) (از مقدار پیش‌فرض استفاده کنید)
    \fBadvert_int \fR1

    # یادداشت: authentication توسط RFC3768 در سال 2004 از مشخصات VRRPv2 حذف شد.
    #   استفاده از این گزینه با استاندارد مطابقت ندارد و می‌تواند مشکلاتی ایجاد کند؛
    #   در صورت امکان از استفاده از آن خودداری کنید، به جز هنگام استفاده از unicast که می‌تواند مفید باشد.
    \fBauthentication \fR{
        # PASS|AH
        # PASS - گذرواژه ساده (پیشنهادی)
        # AH - پروتکل IPSEC (توصیه نمی‌شود)
        \fBauth_type \fRPASS

        # گذرواژه برای دسترسی به vrrpd.
        # باید در تمام ماشین‌ها یکسان باشد.
        # فقط هشت (8) نویسه اول استفاده می‌شود.
        \fBauth_pass \fR1234
    }

    # افزونه احراز اصالت (مختص keepalived). از advertها در برابر
    #   تزریق (injection) و بازپخش (replay) با استفاده از یک تریلر HMAC-SHA256
    #   و شماره توالی مبتنی بر زمان محافظت می‌کند. برای VRRPv2 و v3، IPv4 و
    #   IPv6، تک‌پخشی و چندپخشی کار می‌کند. به ویژه برای unicast مفید است که در آن
    #   بررسی TTL=255 اعمال نمی‌شود. با بلوک authentication بالا مانعة‌الجمع است.
    #   همه گره‌ها باید کلیدها را به اشتراک بگذارند و هنگامی که anti_replay روی
    #   time است، ساعت‌های خود را هماهنگ نگه دارند (NTP).
    \fBauth_hmac \fR{
        # یک کلید امضا، id از 1 تا 255، 32 تا 64 بایت. پیشوند :hex
        #   بایت‌های خام را حمل می‌کند، در غیر این صورت مقدار یک رشته ASCII است.
        #   از 32 بایت برای حاشیه امنیت پسا-کوانتومی استفاده کنید؛ یک جستجوی کوانتومی
        #   استحکام مؤثر کلید را نصف می‌کند.
        #   پیشوند :file مقدار را از یک پرونده می‌خواند و در نتیجه راز را خارج از
        #   پیکربندی نگه می‌دارد، برای نمونه یک اعتبارنامه systemd در
        #   file:${_ENV CREDENTIALS_DIRECTORY}/<name>
        #   (نمونه drop-in موجود در keepalived.service.d را ببینید).
        #   چندین کلید تعریف کنید تا چرخش کلید بدون قطعی امکان‌پذیر باشد.
        \fBkey \fR1 hex:000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
        \fBkey \fR2 file:/etc/keepalived/keys/vrrp10

        # شناسه کلید مورد استفاده هنگام ارسال. برای چرخش، آن را در بین گره‌ها جابه‌جا کنید.
        \fBactive_key \fR2

        # حالت ضد بازپخش: time|monotonic (پیش‌فرض time).
        #   حالت time یک پنجره زمانی تازگی را اعمال می‌کند و به ساعت‌های همگام نیاز دارد،
        #   حالت monotonic فقط به توالی‌های اکیداً صعودی نیاز دارد.
        \fBanti_replay \fRtime

        # پنجره تازگی به ثانیه، 1 تا 300 (فقط در حالت time).
        #   پیش‌فرض برابر با max(3 x advert_int, 5).
        \fBtime_window \fR5

        # enforce|permissive|receive-only (پیش‌فرض enforce). این دو حالت
        #   مهاجرت، advertهای بدون تریلر را نیز می‌پذیرند و حالت receive-only
        #   علاوه بر این هیچ تریلری ارسال نمی‌کند، بنابراین یک گروه قبل از اینکه
        #   کسی امضا کند به قابلیت اعتبارسنجی دست می‌یابد. در سه مرحله مستقر کنید:
        #   ابتدا receive-only سپس permissive و سپس enforce؛ هر مرحله بدون اختلال
        #   و بدون محدودیت زمانی است.
        \fBmode \fRenforce
    }

    # نشانی‌ها هنگام تغییر به MASTER اضافه و هنگام تغییر به BACKUP حذف می‌شوند (add|del).
    # با ورودی‌های یکسان در سایر ماشین‌ها،
    # انتقال معکوس رخ خواهد داد.
    # برای virtual_ipaddress ،virtual_ipaddress_excluded،
    #   virtual_routes و virtual_rules، بیشتر گزینه‌ها
    #   با گزینه‌های دستور ip address/route/rule add مطابقت دارند.
    #   گزینه track_group فقط برای نشانی‌ها/مسیرها/قوانین ایستا اعمال می‌شود.
    #   گزینه no_track مختص keepalived است و به این معنی است که
    #   در صورت حذف شدن نشانی/مسیر/قانون، vrrp_instance از وضعیت master خارج
    #   نخواهد شد و نشانی/مسیر/قانون تا زمانی که نمونه vrrp دفعه بعد به master
    #   تغییر وضعیت ندهد، مجدداً برقرار نخواهد شد.
    # <LABEL>: اختیاری است و یک نام برای نام مستعار (alias) ایجاد می‌کند.
               برای سازگاری با "ifconfig"، باید به صورت
               <realdev>:<anytext> باشد، برای نمونه
               eth0:1 برای یک نام مستعار روی eth0.
    # <SCOPE>: ("site"|"link"|"host"|"nowhere"|"global")
    # پارامتر preferred_lft برای منسوخ کردن نشانی‌های IPv6 روی 0 تنظیم می‌شود (اگر ماسک
    # نشانی 128/ باشد، این مقدار پیش‌فرض است). از "preferred_lft forever" استفاده کنید
    # تا مشخص شود یک نشانی 128/ نباید منسوخ شود.
    # نکته: در صورتی که dev برای یک نشانی مشخص شده باشد و شبکه شما از سوئیچ‌های
    # یادگیرنده MAC استفاده می‌کند، باید دقت شود. پروتکل VRRP تضمین می‌کند که
    # نشانی MAC مبدأ رابط ارسال‌کننده advert در حافظه موقت MAC سوئیچ‌ها نگهداری شود؛
    # با این حال، به طور پیش‌فرض این مورد برای MAC هر VIP/eVIP که روی رابط‌هایی متفاوت
    # از رابط پیکربندی‌شده نمونه VRRP تنظیم شده باشد کار نخواهد کرد، زیرا رابط، به ویژه اگر
    # یک رابط VMAC باشد، فقط با استفاده از نشانی MAC رابط در پاسخ به درخواست‌های ARP
    # ارسال خواهد کرد. این ممکن است به این معنی باشد که زمان نشانی‌های MAC رابط در
    # حافظه موقت MAC سوئیچ‌ها منقضی شود. برای جلوگیری از این امر، از گزینه‌های
    # garp_extra_if یا garp_extra_if_vmac برای ارسال دوره‌ای پیام‌های GARP/ND روی
    # آن رابط‌ها استفاده کنید.
    \fBvirtual_ipaddress \fR{
        <IPADDR>[/<MASK>] [brd <IPADDR>] [dev <STRING>] [use_vmac] [scope <SCOPE>]
                          [label <LABEL>] [peer <IPADDR>] [home]
                          [-nodad] [mngtmpaddr] [noprefixroute]
                          [autojoin] [no_track] [preferred_lft nn|forever]
        192.168.200.17/24 dev eth1
        192.168.200.18/24 dev eth2 label eth2:1
    }

    # مستثنی کردن IPهای VRRP از VRRP (اختیاری).
    # برای مواردی با تعداد زیاد IP (مانند 200)
    # روی یک رابط یکسان. برای کاهش تعداد
    # نشانی‌های ارسالی در advertها، می‌توانید بیشتر
    # IPها را از advertها مستثنی کنید.
    # این IPها مانند virtual_ipaddress اضافه یا حذف می‌شوند (add|del).
    # همچنین در صورتی که بخواهید ترکیبی از نشانی‌های IPv4
    # و IPv6 را اضافه کنید قابل استفاده است، زیرا تمام نشانی‌ها
    # در virtual_ipaddress باید از یک خانواده باشند.
    \fBvirtual_ipaddress_excluded \fR{
        <IPADDR>[/<MASK>] [brd <IPADDR>] [dev <STRING>] [scope <SCOPE>]
                          [label <LABEL>] [peer <IPADDR>] [home]
                          [-nodad] [mngtmpaddr] [noprefixroute]
                          [autojoin] [no_track]
        <IPADDR>[/<MASK>] ...
        ...
    }

    # مشخص نکردن نشانی‌های IP مجازی معمولاً یک خطای پیکربندی است
    # و نگارش 3 پروتکل VRRP صراحتاً بیان می‌کند که حداقل تعداد نشانی‌ها
    # 1 است. در نتیجه keepalived در صورت عدم پیکربندی VIP هشدار می‌دهد.
    # با این حال، شرایطی وجود دارد که در آن نداشتن VIP مفید است، برای
    # نمونه در سرورهای ابری مانند AWS که در آنها نشانی‌های IP شناور به صورت
    # مدیریتی اداره می‌شوند و روی سرور مجازی ابری پیکربندی نمی‌شوند.
    # مشخص کردن no_virtual_ipaddress هشدارهای مربوط به عدم وجود VIP را نادیده می‌گیرد
    # و اجازه می‌دهد از VRRPv3 بدون VIP استفاده شود.
    # هشدار - استفاده از این مورد همراه با VRRPv3 باعث نقض پروتکل می‌شود و
    # ممکن است با سایر پیاده‌سازی‌های VRRP کار نکند.
    \fBno_virtual_ipaddress\fR

    # تنظیم پرچم promote_secondaries روی رابط برای جلوگیری از حذف سایر
    # نشانی‌ها در همان CIDR هنگام حذف یکی از آنها.
    # برای مثال اگر 10.1.1.2/24 و 10.1.1.3/24 هر دو روی یک رابط پیکربندی
    # شده باشند و یکی از آنها حذف شود، مگر اینکه promote_secondaries روی
    # رابط تنظیم شده باشد، نشانی دیگر نیز حذف خواهد شد.
    \fBpromote_secondaries \fR

    # مسیرها هنگام تغییر به MASTER اضافه و هنگام تغییر به BACKUP حذف می‌شوند (add|del).
    # برای جزئیات بیشتر static_routes را ببینید
    \fBvirtual_routes \fR{
        # src <IPADDR> [to] <IPADDR>/<MASK> via|gw <IPADDR>
        #   [or <IPADDR>] dev <STRING> scope <SCOPE> table <TABLE>
        src 192.168.100.1 to 192.168.109.0/24 via 192.168.200.254 dev eth1
        192.168.110.0/24 via 192.168.200.254 dev eth1
        192.168.111.0/24 dev eth2 no_track
        192.168.112.0/24 via 192.168.100.254
        192.168.113.0/24 via 192.168.200.254 or 192.168.100.254 dev eth1
        blackhole 192.168.114.0/24
        0.0.0.0/0 gw 192.168.0.1 table 100  # برای تنظیم یک درگاه پیش‌فرض در table 100.
    }

    # قوانین هنگام تغییر به MASTER اضافه و هنگام تغییر به BACKUP حذف می‌شوند (add|del)
    # برای جزئیات بیشتر static_rules را ببینید
    \fBvirtual_rules \fR{
        from 192.168.2.0/24 table 1
        to 192.168.2.0/24 table 1 no_track
    }

    # پروتکل VRRPv3 دارای یک Accept Mode است که به مسیریاب مجازی اجازه می‌دهد در صورتی
    # که مالک نشانی نباشد، بسته‌های ارسالی به یک VIP را دریافت کند. این حالت پیش‌فرض
    # است مگر اینکه strict mode تنظیم شده باشد. به عنوان یک افزونه، این قابلیت برای
    # VRRPv2 نیز کار می‌کند (RFC 3768 حالت accept mode را تعریف نکرده است).
    # --
    # پذیرش بسته‌ها برای غیر مالک نشانی (non address-owner)
    \fBaccept\fR

    # دور انداختن بسته‌ها برای غیر مالک نشانی.
    \fBno_accept\fR

    # یک نمونه VRRP با اولویت بالاتر به طور معمول با برخط شدن، تقدم را از نمونه با اولویت پایین‌تر
    # می‌گیرد (preempt). گزینه "nopreempt" مانع از در دست گرفتن نقش master توسط ماشین با اولویت بالاتر
    # شده و اجازه می‌دهد ماشین با اولویت پایین‌تر به عنوان master باقی بماند.
    # نکته: برای کارکرد این قابلیت، وضعیت اولیه (state) نباید MASTER باشد.
    # --
    \fBnopreempt\fR

    # برای سازگاری با نسخه‌های پیشین
    \fBpreempt\fR

    # ثانیه‌های تأخیر تا پیش‌دستی (preemption) پس از پایان مهلت زمانی اعلان (advertisement timeout)
    # هنگام راه‌اندازی یا هنگام مشاهده یک master با اولویت پایین‌تر.
    #
    # از آنجا که این یک تأخیر است، نمی‌تواند تصاحب نقش master را سرعت ببخشد.
    # گزینه "preempt_delay" زمان تأخیر در پیش‌دستی را بر حسب ثانیه در مقایسه با حالتی
    # که "preempt_delay" مشخص نشده است تعیین می‌کند. مهلت زمانی اعلان برابر است با:
    # 3 * advert_int + skew_time. مقدار Skew_time توسط RFC3768 و RFC5798 تعریف شده است.
    #
    # بنابراین اگر "advert_int" برابر 1 و priority برابر 128 باشد، نمونه به طور معمول
    # 3.5 ثانیه قبل از در دست گرفتن نقش master صبر می‌کند. اگر "preempt_delay 2" مشخص
    # شده باشد، تأخیر قبل از master شدن تقریباً 5.5 ثانیه خواهد بود (اگر توسط "nopreempt"
    # غیرفعال نشده باشد).
    # محدوده: 0 (پیش‌فرض) تا 1000 (مانند 4.12)
    # نکته: برای کارکرد این قابلیت، وضعیت اولیه (state) نباید MASTER باشد.
    \fBpreempt_delay \fR300    # 5 دقیقه صبر می‌کند

    # توضیحات مربوط به گزینه سراسری vrrp_skip_check_adv_addr را ببینید که
    # مقدار پیش‌فرض را تعیین می‌کند. پیش‌فرض برابر با vrrp_skip_check_adv_addr است
    \fBskip_check_adv_addr \fR[<BOOL>]

    # توضیحات مربوط به گزینه سراسری vrrp_strict را ببینید
    # اگر strict_mode مشخص نشود، مقدار vrrp_strict را می‌گیرد.
    # اگر strict_mode بدون پارامتر مشخص شود، پیش‌فرض آن on است.
    \fBstrict_mode \fR[<BOOL>]

    # سطح اشکال‌زدایی (Debug level)، هنوز پیاده‌سازی نشده است.
    # مقدار LEVEL عددی در محدوده 0 تا 4 است
    \fBdebug \fR<LEVEL>

    # اسکریپت‌های notify، هشدار مانند بالا
    \fBnotify_master \fR<STRING>|<QUOTED-STRING> [username [groupname]]
    \fBnotify_backup \fR<STRING>|<QUOTED-STRING> [username [groupname]]
    \fBnotify_fault \fR<STRING>|<QUOTED-STRING> [username [groupname]]
    # هنگام متوقف کردن vrrp اجرا می‌شود
    \fBnotify_stop \fR<STRING>|<QUOTED-STRING> [username [groupname]]
    \fBnotify \fR<STRING>|<QUOTED-STRING> [username [groupname]]

    # اسکریپت notify_master_rx_lower_pri زمانی اجرا می‌شود که یک master
    #  اعلانی با اولویت کمتر از اولویت master دریافت کند.
    \fBnotify_master_rx_lower_pri \fR<STRING>|<QUOTED-STRING> [username [groupname]]

    # ارسال اعلان‌های اولویت نمونه vrrp روی FIFOهای notify.
    \fBnotify_priority_changes\fR <BOOL>

    # ارسال هشدارهای SMTP
    \fBsmtp_alert \fR<BOOL>

    # تنظیم اندازه بافر دریافت سوکت (برای توضیح،
    # vrrp_rx_bufs_policy در global_defs را ببینید)
    \fBkernel_rx_buf_size\fR

    # تنظیم استفاده از linkbeat برای رابط این نمونه VRRP. این گزینه
    # منسوخ شده است - به جای آن از بلوک linkbeat_interfaces استفاده کنید.
    \fBlinkbeat_use_polling\fR
}
.fi
.SH "حذف لرزش تغییر وضعیت بالا/پایین رابط (Interface up/down status change debouncing)"
.PP
    اگر رابطی که توسط یک نمونه VRRP استفاده (یا ردیابی) می‌شود به وضعیت down برود،
    نمونه(های) VRRP به طور پیش‌فرض بلافاصله به وضعیت FAULT منتقل می‌شوند، و هنگامی که
    تمام رابط‌های مربوطه مجدداً بالا بیایند (up شوند)، نمونه(های) VRRP بلافاصله به وضعیت
    BACKUP منتقل خواهند شد.

    این امر در صورت نوسان و قطعی و وصلی مکرر رابط‌ها (bouncing) می‌تواند مشکلاتی ایجاد کند،
    بنابراین می‌توان تأخیرهایی را بین تغییر وضعیت رابط و انتقال به وضعیت FAULT/BACKUP
    مشخص کرد. اگر رابط قبل از پایان مهلت تأخیر به وضعیت اولیه خود بازگردد، هیچ انتقال
    وضعیتی در نمونه VRRP مرتبط رخ نخواهد داد.
.PP
.nf
	interface_up_down_delays {
	    ifname down_delay [up_delay]
	    ifname2 down_delay [up_delay]
	    ...
	}
.PP
    تأخیرها بر حسب ثانیه و با دقت میکروثانیه مشخص می‌شوند، برای مثال تأخیر 0.00001
    به معنای 10 میکروثانیه است. مقدار تأخیر 0 به معنای عدم وجود تأخیر در تغییر وضعیت است.
    حداکثر تأخیری که می‌توان مشخص کرد 255 ثانیه است.

    اگر up_delay حذف شود، مقدار آن برابر با down_delay تنظیم می‌شود.

    مقدار down delay روی یک رابط باید کمتر از دو برابر (یا دقیق‌تر، یک واحد کمتر از
    down_timer_adverts با مقدار پیش‌فرض 3) بازه زمانی اعلان (advert interval) هر نمونه VRRP
    استفاده‌کننده از آن رابط باشد (در غیر این صورت یک نمونه backup در حالی که advert دریافت نمی‌کند،
    ممکن است مهلت زمانی‌اش تمام شده و قبل از اینکه این نمونه به وضعیت FAULT منتقل شود، به master تبدیل شود).
    در نتیجه، اگر نمونه دیگری با بازه advert کوتاه‌تر master باشد، تأخیرهای up/down می‌توانند به صورت پویا کاهش یابند.

    اگر نمونه VRRP از یک VMAC استفاده می‌کند، تأخیرهای حذف لرزش up/down رابط والد خود را به ارث خواهد برد.
.fi
.SH "پیکربندی LVS (LVS CONFIGURATION)"
شامل زیربلوک‌های
\fBVirtual server group(s)\fR
و
\fBVirtual server(s)\fR
است.
.PP
این زیربلوک‌ها شامل آرگومان‌هایی برای پیکربندی قابلیت IPVS (LVS) لینوکس هستند.
آشنایی با
.I ipvsadm(8)
در اینجا مفید خواهد بود. پیکربندی LVS با تعریف گروه‌های سرور مجازی، سرورهای مجازی و به صورت اختیاری پیکربندی SSL انجام می‌شود. هر سرور مجازی مجموعه‌ای از real serverها را تعریف می‌کند؛ شما می‌توانید بررسی‌کننده‌های سلامت (healthchecker) را به هر real server متصل کنید. سپس Keepalived با حفظ پویای توپولوژی، عملیات LVS را هدایت خواهد کرد.
.PP
برای آگاهی از جزئیات ترکیب‌های پیکربندی معتبر، صفحه راهنمای
.I ipvsadm(8)
را ببینید.
.PP
\fBیادداشت:\fR
در مواردی که یک گزینه می‌تواند برای virtual server، real server و احتمالاً checker پیکربندی شود، تنظیمات virtual server پیش‌فرض برای real serverها است، و تنظیمات real server پیش‌فرض برای checkerها خواهد بود.
.PP
\fBیادداشت:\fR
خانواده نشانی real/sorry serverهای تونل‌شده می‌تواند با خانواده نشانی virtual server و real/sorry serverهای غیرتونل‌شده تفاوت داشته باشد، که همگی آن‌ها باید یکسان باشند. اگر یک virtual server از fwmark استفاده کند، و همه real/sorry serverها تونل شده باشند، خانواده نشانی virtual server در صورت یکسان بودن همگی آن‌ها، با خانواده نشانی real/sorry serverها یکی خواهد بود؛ در غیر این صورت به طور پیش‌فرض روی IPv4 قرار می‌گیرد (از ip_family inet6 برای لغو این حالت استفاده کنید).
.PP
\fBیادداشت:\fR
پورت برای virtual server تنها در صورتی می‌تواند حذف شود که سرویس مجازی از نوع دائم (persistent) باشد.
.PP
.SH "گروه‌های سرور مجازی (Virtual server group(s))"
.PP
این ویژگی راهکاری را برای ساده‌سازی پیکربندی شما با فاکتورگیری از تعاریف virtual server ارائه می‌دهد. اگر نیاز دارید دسته‌ای از سرورهای مجازی را با توپولوژی real server کاملاً یکسان تعریف کنید، این قابلیت پیکربندی شما را بسیار خواناتر می‌کند، تکرار سرورهای مجازی IPVS را در صورت استفاده از \fInftables_ipvs\fR بهینه‌سازی می‌نماید و با ایجاد تنها یک healthchecker در جایی که اعلان چندین virtual server یک healthchecker اختصاصی برای هر real server ایجاد می‌کرد و منابع سیستم را هدر می‌داد، وظیفه بررسی سلامت را بهینه می‌کند.
.PP
هر ترکیبی از نشانی‌های IP، محدوده‌های نشانی IP و نشان‌های دیوارآتش (firewall marks) می‌تواند استفاده شود، به شرطی که خانواده نشانی‌های IP گروه سرور مجازی با خانواده نشانی IP تمام real serverهای هر virtual server که از آن گروه سرور مجازی استفاده می‌کند، مطابقت داشته باشد. تنها استثنا در این مورد این است که virtual server group می‌تواند با هر دو نشانی‌های IPv4 و IPv6 و fwmarkها پیکربندی شود، به شرطی که تمام real serverها (و sorry serverها) از تمام virtual serverهایی که از virtual server group استفاده می‌کنند، از فورواردینگ تونل (tunnel forwarding) استفاده نمایند؛ اگر در این حالت fwmarkها مشخص شده باشند، خانواده نشانی باید تعیین گردد (تنها استثنا برای این حالت زمانی است که virtual server group فاقد هرگونه نشانی IP باشد (یعنی فقط fwmarks) و همه real/sorry serverها تونل‌شده باشند که به طور پیش‌فرض روی IPv4 قرار می‌گیرد؛ اتکا به این روش مناسب نیست و خانواده نشانی fwmarkها باید پیکربندی شود).
استفاده از این گزینه برای LVSهای بسیار بزرگ در نظر گرفته شده است، اما توجه داشته باشید که این امر می‌تواند تعداد بسیار زیادی سرور مجازی ایجاد کند مگر اینکه از \fInftables_ipvs\fR استفاده شود. استفاده از \fInftables_ipvs\fR به دلیل بهینه‌سازی‌ها و کارایی‌های بسیار چشمگیری که ارائه می‌دهد به شدت توصیه می‌شود.

یادداشت: بیش از یک virtual server برای TCP، یک virtual server برای UDP و یک virtual server برای SCTP با خانواده نشانی IP یکسان با استفاده از یک virtual server group پیکربندی نکنید (یا به بیان دیگر، دو virtual server با پروتکل و خانواده نشانی یکسان که از یک virtual server group استفاده می‌کنند نداشته باشید)؛ اگر تمام real serverها تونل شده باشند، نباید هر دو سرور مجازی IPv4 و IPv6 را با یک پروتکل یکسان داشته باشید.
.PP
.nf
نحو برای virtual_server_group به شرح زیر است:

\fBvirtual_server_group \fR<STRING> {
    # نشانی IP مجازی و پورت
    <IPADDR> [<PORT>]
    <IPADDR> [<PORT>]
    ...
    # <IPADDR RANGE> به هر یک از اشکال زیر (یا معادل‌های IPv6 آن‌ها) است:
    # XXX.YYY.ZZZ.WWW-VVV مانند 192.168.200.1-10 (شامل هر دو 1. و 10.)
    # AAA.BBB.CCC.DDD-EEE.FFF.GGG.HHH مانند 192.168.200.250-192.168.201.10
    # III.JJJ.KKK.LLL/nn مانند 192.168.202.8/29
    <IPADDR RANGE> [<PORT>] # محدوده VIP [VPORT]
    <IPADDR RANGE> [<PORT>]
    ...
    # نشان دیوارآتش (fwmark)
    # inet/inet6 فقط باید برای virtual server groupهایی مشخص شود
    # که در آن‌ها تمام real serverهای سرورهای مجازی تونل شده باشند.
    \fBfwmark \fR<INTEGER>
    \fBfwmark \fR<INTEGER> [inet|inet6]
    ...
}
.fi
.SH "سرورهای مجازی (Virtual server(s))"
.PP
یک virtual_server می‌تواند اعلانی از یکی از موارد
\fB<IPADDR> [<PORT>]\fR
،
\fBfwmark <INTEGER>\fR
یا
\fBgroup <STRING>\fR
باشد.
.PP
.nf
نحو برای virtual_server به شرح زیر است:

\fBvirtual_server \fR<IPADDR> [<PORT>]  |
\fBvirtual_server fwmark \fR<INTEGER> |
\fBvirtual_server group \fR<STRING> {
    # زمان‌بند LVS
    \fBlvs_sched \fRrr|wrr|lc|wlc|lblc|sh|mh|dh|fo|ovf|lblcr|sed|nq|twos

    # فعال‌سازی flag-1 برای زمان‌بند (پرچم -b flag-1 در ipvsadm)
    \fBflag-1\fR
    # فعال‌سازی flag-2 برای زمان‌بند (پرچم -b flag-2 در ipvsadm)
    \fBflag-2\fR
    # فعال‌سازی flag-3 برای زمان‌بند (پرچم -b flag-3 در ipvsadm)
    \fBflag-3\fR
    # فعال‌سازی sh-port برای زمان‌بند sh (پرچم -b sh-port در ipvsadm)
    \fBsh-port\fR
    # فعال‌سازی sh-fallback برای زمان‌بند sh (پرچم -b sh-fallback در ipvsadm)
    \fBsh-fallback\fR
    # فعال‌سازی mh-port برای زمان‌بند mh (پرچم -b mh-port در ipvsadm)
    \fBmh-port\fR
    # فعال‌سازی mh-fallback برای زمان‌بند mh (پرچم -b mh-fallback در ipvsadm)
    \fBmh-fallback\fR
    # فعال‌سازی زمان‌بندی تک‌بسته‌ای برای UDP (پرچم -o در ipvsadm)
    \fBops\fR

    # بازنویسی روش فورواردینگ پیش‌فرض LVS (پیش‌فرض NAT است).
    # نوع تونل پیش‌فرض ipip است. از لینوکس 5.2 به بعد نوع تونل GUE می‌تواند
    # مشخص شود. در صورت استفاده از GUE، شماره پورت الزامی است. از لینوکس 5.3 به بعد
    # اگر نوع تونل GUE باشد، گزینه checksum نیز می‌تواند مشخص شود.
    # از لینوکس 5.3، نوع تونل GRE نیز پشتیبانی می‌شود، اما بدون
    # گزینه remcsum.
    \fBlvs_method \fRNAT|DR
    or
    \fBlvs_method \fRTUN [type {ipip|gue port NUM|gre} [nocsum|csum|remcsum]]
    # نام موتور پایایی (persistence) در LVS (در حال حاضر فقط sip پشتیبانی می‌شود)
    \fBpersistence_engine \fR<STRING>
    # مهلت زمانی پایایی LVS به ثانیه، پیش‌فرض ۶ دقیقه
    \fBpersistence_timeout \fR[<INTEGER>]
    # ماسک دانه‌بندی (granularity) در LVS (پرچم -M در ipvsadm)
    \fBpersistence_granularity \fR<NETMASK>
    # پروتکل لایه ۴
    \fBprotocol \fRTCP|UDP|SCTP
    # اگر نشانی IP سرور مجازی (VS) تنظیم نشده باشد،
    # فعالیت healthchecker معلق می‌شود
    \fBha_suspend\fR

    # ارسال اعلان ایمیلی هنگام تغییر وضعیت quorum up/down،
    # با استفاده از نشانی‌های موجود در global_defs در بالا (پیش‌فرض no،
    # مگر اینکه smtp_alert/smtp_alert_checker به صورت عمومی تنظیم شده باشد)
    \fBsmtp_alert \fR<BOOL>

    # رشته VirtualHost پیش‌فرض برای HTTP_GET یا SSL_GET
    # مانند virtualhost www.firewall.loc
    # با پیکربندی virtualhost در real server یا checker بازنویسی می‌شود
    \fBvirtualhost \fR<STRING>

    # گزینه snmp_name یک رشته متنی است که به عنوان بخشی از داده‌های snmp
    # برای این virtual server برگردانده می‌شود. این گزینه می‌تواند برای کمک به شناسایی
    # سرور مجازی هنگام تجزیه خروجی SNMP استفاده شود.
    \fBsnmp_name \fR<STRING>

    # هنگام راه‌اندازی دیمن فرض می‌شود همه RSها غیرفعال هستند
    # و بررسی‌های سلامت ناموفق بوده‌اند. این کار به جلوگیری از
    # هشدارهای نادرست (false positive) در راه‌اندازی کمک می‌کند. حالت Alpha
    # به طور پیش‌فرض غیرفعال است.
    \fBalpha\fR

    # هنگام خاموش شدن دیمن، اعلان‌کننده‌های quorum و RS down
    # را در صورت لزوم برای اجرا در نظر بگیر. حالت Omega
    # به طور پیش‌فرض غیرفعال است.
    \fBomega\fR

    # حداقل وزن کل همه سرورهای فعال در استخر
    # که برای کارکرد VS بدون افت کیفیت لازم است.
    # پیش‌فرض 1 است.
    \fBquorum \fR<INTEGER>

    # تحمل این مقدار واحد وزنی در مقایسه با quorum اسمی،
    # هنگام بررسی به‌دست آمدن یا از دست رفتن حد نصاب (quorum).
    # یک تعدیل‌کننده نوسان (flap dampener). پیش‌فرض 0 است.
    \fBhysteresis \fR<INTEGER>

    # اسکریپت برای اجرا هنگام به‌دست آمدن حد نصاب (quorum).
    \fBquorum_up \fR<STRING>|<QUOTED-STRING> [username [groupname]]

    # اسکریپت برای اجرا هنگام از دست رفتن حد نصاب (quorum).
    \fBquorum_down \fR<STRING>|<QUOTED-STRING> [username [groupname]]

    # خانواده IP برای سرویس fwmark (تنها در صورتی لازم است که همه real serverها تونل شده باشند
    # و persistence_granularity مشخص نشده باشد). در صورت عدم تعیین، پیش‌فرض inet است.
    \fBip_family \fRinet|inet6

    # راه‌اندازی realserver(ها)

    # سرور RS برای افزودن به توپولوژی LVS هنگامی که حد نصاب محقق نشده است.
    #  اگر یک sorry server پیکربندی شده باشد، در صورت عدم تحقق quorum همه real serverها
    #  پایین آورده شده و با sorry server
    #  جایگزین خواهند شد.
    \fBsorry_server \fR<IPADDR> [<PORT>]
    # رفتار inhibit_on_failure را روی sorry_server اعمال می‌کند.
    # احتمال بسیار کمی وجود دارد که بخواهید از این استفاده کنید، زیرا اگر
    # یک real server در دسترس داشته باشید، تقریباً به طور قطع می‌خواهید از آن
    # استفاده کنید.
    \fBsorry_server_inhibit\fR
    # روش فورواردینگ LVS برای sorry server. پیش‌فرض، مقدار پیش‌فرض
    #  virtual server است.
    # برای جزئیات نوع تونل، جزئیات virtual_server را ببینید.
    \fBsorry_server_lvs_method \fRNAT|DR
    or
    \fBsorry_server_lvs_method \fRTUN [type {ipip|gue port NUM|gre} [nocsum|csum|remcsum]]

    # مهلت زمانی اختیاری اتصال به ثانیه.
    # پیش‌فرض ۵ ثانیه است
    \fBconnect_timeout \fR<TIMER>

    # تعداد تلاش‌های مجدد برای انجام بررسی‌های اضافی در صورتی که بررسی
    # یک سرور زنده ناموفق باشد. پیش‌فرض: 1 مگر اینکه در زیر مشخص شده باشد
    \fBretry \fR<INTEGER>

    # تأخیر پیش از تلاش مجدد پس از شکست. پیش‌فرض delay_loop برای DNS_CHECK،
    # ۳ ثانیه برای HTTP_GET و SSL_GET، و در غیر این صورت ۱ ثانیه است.
    \fBdelay_before_retry \fR<TIMER>

    # تأخیر تصادفی اختیاری برای شروع بررسی اولیه
    # حداکثر تا N ثانیه.
    # برای توزیع چند بررسی همزمان
    # روی یک RS یکسان مفید است. به طور پیش‌فرض فعال است، با
    # حداکثر مقدار در delay_loop. مقدار 0 را برای غیرفعال‌سازی مشخص کنید
    \fBwarmup \fR<TIMER>

    # تایمر تأخیر برای نظرسنجی checker (در صورت عدم تعیین، ۶۰ ثانیه)
    \fBdelay_loop \fR<TIMER>

    # تنظیم وزن روی 0 هنگامی که healthchecker خرابی را تشخیص دهد
    \fBinhibit_on_failure\fR

    # یک مدخل برای هر realserver
    \fBreal_server \fR<IPADDR> [<PORT>] {
        # وزن نسبی برای استفاده، پیش‌فرض: 1
        \fBweight \fR<INTEGER>
        # روش فورواردینگ LVS
        # برای جزئیات نوع تونل، جزئیات virtual_server را ببینید. تنظیمات پیش‌فرض
        # از تنظیمات virtual_server گرفته می‌شود.
        \fBlvs_method \fRNAT|DR
        or
        \fBlvs_method \fRTUN [type {ipip|gue port NUM|gre} [nocsum|csum|remcsum]]

        # اسکریپت برای اجرا هنگامی که healthchecker
        # سرویس را به عنوان فعال (up) در نظر می‌گیرد.
        \fBnotify_up \fR<STRING>|<QUOTED-STRING> [username [groupname]]
        # اسکریپت برای اجرا هنگامی که healthchecker
        # سرویس را به عنوان غیرفعال (down) در نظر می‌گیرد.
        \fBnotify_down \fR<STRING>|<QUOTED-STRING> [username [groupname]]

        # حداکثر تعداد اتصالات به سرور
        \fButhreshold \fR<INTEGER>
        # حداقل تعداد اتصالات به سرور
        \fBlthreshold \fR<INTEGER>

        # ارسال اعلان ایمیلی در طول تغییر وضعیت،
        # با استفاده از نشانی‌های موجود در global_defs در بالا (پیش‌فرض yes،
        # مگر اینکه smtp_alert/smtp_alert_checker به صورت عمومی تنظیم شده باشد)
        \fBsmtp_alert \fR<BOOL>

        # رشته VirtualHost پیش‌فرض برای HTTP_GET یا SSL_GET
        # مانند virtualhost www.firewall.loc
        # با پیکربندی virtualhost در یک checker بازنویسی می‌شود
        \fBvirtualhost \fR<STRING>

	# گزینه snmp_name یک رشته متنی است که به عنوان بخشی از داده‌های snmp
	# برای این real server برگردانده می‌شود. می‌تواند برای کمک به شناسایی
	# real server هنگام تجزیه خروجی SNMP استفاده شود.
	\fBsnmp_name \fR<STRING>

        \fBalpha \fR<BOOL>                    # بالا را ببینید
        \fBconnect_timeout \fR<TIMER>         # بالا را ببینید
        \fBretry \fR<INTEGER>                 # بالا را ببینید
        \fBdelay_before_retry \fR<TIMER>      # بالا را ببینید
        \fBwarmup \fR<TIMER>                  # بالا را ببینید
        \fBdelay_loop \fR<TIMER>              # بالا را ببینید
        \fBinhibit_on_failure \fR<BOOL>       # بالا را ببینید

        # بررسی‌کننده‌های سلامت (healthcheckers). می‌تواند چند مورد از هر نوع باشد
        # HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|DNS_CHECK|MISC_CHECK|BFD_CHECK|UDP_CHECK|PING_CHECK|FILE_CHECK

        # همه checkerها گزینه‌های زیر را دارند، به جز MISC_CHECK که فقط
        # گزینه‌های alpha به بعد را دارد، و BFD_CHECK و FILE_CHECK که هیچ‌کدام
        # از گزینه‌های استاندارد را ندارند:
        CHECKER_TYPE {
            # ======== گزینه‌های عمومی اتصال
            # نشانی IP اختیاری برای اتصال.
# پیش‌فرض IP مربوط به realserver است
            \fBconnect_ip \fR<IPADDR>

            # درگاه اختیاری برای اتصال به آن
            # پیش‌فرض درگاه realserver است
            \fBconnect_port \fR<PORT>

            # نشانی اختیاری برای استفاده جهت
            # برقراری اتصال مبدأ
            \fBbindto \fR<IPADDR>

            # رابط اختیاری برای استفاده؛ در صورتی که نشانی bindto
            # از نوع IPv6 link local باشد مورد نیاز است
            \fBbind_if \fR<IFNAME>

            # درگاه مبدأ اختیاری برای
            # برقراری اتصال از آن
            \fBbind_port \fR<PORT>

            # یک fwmark اختیاری برای علامت‌گذاری تمام بسته‌های
            # خروجی بررسی‌کننده (checker)
            \fBfwmark \fR<INTEGER>

            \fBalpha \fR<BOOL>                    # بالا را ببینید
            \fBconnect_timeout \fR<TIMER>         # بالا را ببینید
            \fBretry \fR<INTEGER>                 # بالا را ببینید
            \fBdelay_before_retry \fR<TIMER>      # بالا را ببینید
            \fBwarmup \fR<TIMER>                  # بالا را ببینید
            \fBdelay_loop \fR<TIMER>              # بالا را ببینید
            \fBlog_all_failures \fR<BOOL>         # ثبت تمام خطاها هنگامی که checker بالا (up) است
        }

        # گزینه‌های زیر مختص بررسی‌کننده‌های اضافی هستند

        # بررسی‌کننده‌های سلامت HTTP و SSL
        \fBHTTP_GET|SSL_GET \fR{
            # نسخه پروتکل HTTP، یکی از 1.0، 1.0C، 1.1
            # نسخه پروتکل 1.0C به معنای نسخه 1.0 به همراه افزودن
            # یک خط "Connection: close" است، که به طور پیش‌فرض در
            # نسخه 1.1 گنجانده شده است.
            \fBhttp_protocol \fR<PROTOCOL>
            # هنگامی که حالت alpha تنظیم شده باشد، یا هنگام بازیابی از یک خرابی،
            # هر URL با تأخیر <delay_loop> بین هر بررسی
            # بررسی می‌شود. اگر ۲۰ تا URL وجود داشته باشد، و <delay_loop> برابر
            # ۳ ثانیه باشد، ۱ دقیقه طول می‌کشد تا RS پس از راه‌اندازی یا بازیابی
            # از خرابی بالا بیاید. تنظیم fast_recovery این تأخیر را
            # هم در زمان راه‌اندازی و هم پس از بازیابی از خرابی حذف می‌کند،
            # به این معنی که RS به محض بررسی تمام URLها و بدون هیچ تأخیری
            # بین بررسی هر URL بالا خواهد آمد.
            \fBfast_recovery \fR[<BOOL>]
            # یک URL برای آزمایش
            # می‌تواند شامل چندین مدخل در اینجا باشد
            \fBurl \fR{
                # به عنوان نمونه path / یا path /mrtg2/
                \fBpath \fR<STRING>
                # بررسی سلامت به digest یا
                # status_code و digest نیاز دارد
                # مقدار digest با genhash محاسبه می‌شود
                # به عنوان نمونه digest 9b3a0c85a887a256d6939da88aabd8cd
                \fBdigest \fR<STRING>
                # کد وضعیتی که در هدر HTTP بازگردانده می‌شود
                # به عنوان نمونه status_code 200 یا status_code 200-299 400-499 503 505
                # پیش‌فرض 200-299 است
                \fBstatus_code \fR<INTEGER|RANGE> [<INTEGER|RANGE>] ...
                # رشته VirtualHost. به عنوان نمونه virtualhost www.firewall.loc
                # در صورت عدم تنظیم، از virtualhost سرور real یا virtual استفاده می‌کند
                \fBvirtualhost \fR<STRING>
                # عبارت باقاعده (regex) برای جستجو در داده‌های بازگردانده شده.
                # عدم تطابق باعث ناموفق شدن بررسی می‌شود.
                \fBregex \fR<STRING>
                # معکوس کردن منطق تطابق، به طوری که تطابق متن
                # بازگردانده شده باعث ناموفق شدن بررسی شود.
                \fBregex_no_match\fR
                # فهرستی از گزینه‌های regex که با فاصله از هم جدا شده‌اند.
                #  برای توضیحات گزینه‌ها man pcre2api را ببینید.
                #  گزینه‌های زیر پشتیبانی می‌شوند:
                #   allow_empty_class alt_bsux auto_callout caseless
                #   dollar_endonly dotall dupnames extended firstline
                #   match_unset_backref multiline never_ucp never_utf
                #   no_auto_capture no_auto_possess no_dotstar_anchor
                #   no_start_optimize ucp ungreedy utf never_backslash_c
                #   alt_circumflex alt_verbnames use_offset_limit
                \fBregex_options \fR<OPTIONS>
                # برای عبارات باقاعده پیچیده ممکن است به پشته (stack) بزرگ‌تری
                #   نیاز باشد، و این امکان را می‌دهد که اندازه‌های اولیه و حداکثر
                #   به بایت مشخص شوند. برای جزئیات بیشتر به مستندات
                #   pcre2_jit_stack_create() مراجعه کنید
                \fBregex_stack \fR<START> <MAX>
                # حداقل آفست درون داده‌های بازگردانده شده برای شروع
                #   بررسی تطابق الگوی regex. در صورت بزرگ بودن داده‌های بازگردانده شده،
                #   این می‌تواند در زمان پردازش صرفه‌جویی کند.
                \fBregex_min_offset \fR<OFFSET>
                # حداکثر آفست درون داده‌های بازگردانده شده برای
                #   شروع تطابق مورد نظر.
                \fBregex_max_offset \fR<OFFSET>
		# فقط مختص SSL_GET - برای توضیحات به SSL_GET در زیر مراجعه کنید
		\fBtls_compliant\fR
            }
        }

        \fBSSL_GET \fR{
            # در صورت ارائه، Server Name Indicator (SNI) را هنگام دست‌تکانی SSL ارسال می‌کند
            \fBenable_sni\fR
	    # سازگاری با پروتکل TLS - ارسال هشدار close_notify
	    #   (صفحه راهنمای SSL_set_quiet_shutdown(3) را ببینید)
	    \fBtls_compliant\fR
        }

        # بررسی‌کننده سلامت TCP
        \fBTCP_CHECK \fR{
            # بدون گزینه‌های اضافی
        }

        # بررسی‌کننده سلامت SMTP
        \fBSMTP_CHECK \fR{
            # رشته اختیاری برای استفاده در درخواست SMTP HELO
            \fBhelo_name \fR<STRING>|<QUOTED-STRING>
        }

        # بررسی‌کننده سلامت DNS. از پروتکل UDP استفاده می‌کند.
        \fBDNS_CHECK \fR{
            # مقدار پیش‌فرض retry برابر ۳ است.

            # نوع پرس‌وجوی DNS
            #   A|NS|CNAME|SOA|MX|TXT|AAAA
            # پیش‌فرض SOA است
            \fBtype \fR<STRING>

            # نام دامنه برای استفاده در پرس‌وجوی DNS
            # پیش‌فرض . (نقطه) است
            \fBname \fR<STRING>
        }

        # بررسی‌کننده سلامت MISC، اجرای یک برنامه
        \fBMISC_CHECK \fR{
            # مقدار پیش‌فرض retry برابر ۰ است.

            # اسکریپت یا برنامه خارجی
            \fBmisc_path \fR<STRING>|<QUOTED-STRING>
            # مهلت زمانی اجرای اسکریپت
            \fBmisc_timeout \fR<INTEGER>

            # در صورت تنظیم misc_dynamic، کد خروج از بررسی‌کننده سلامت
            # برای تنظیم پویای وزن به صورت زیر استفاده می‌شود:
            #   وضعیت خروج ۰: بررسی سرویس موفقیت‌آمیز، وزن
            #     بدون تغییر.
            #   وضعیت خروج ۱: بررسی سرویس ناموفق بود.
            #   وضعیت خروج ۲-۲۵۵: بررسی سرویس موفقیت‌آمیز،
            #     سپس وزن RS به میزان
            #     (exit status - 2 - rs configured weight) افزایش می‌یابد.
            #     وضعیت خروج ۱۰ وزن RS را به ۱۰ تنظیم می‌کند. اگر
            #       وضعیت خروج متعاقباً به ۲۰ تغییر کند، وزن RS
            #       برابر ۲۰ خواهد شد.
            #     اگر فقط یک MISC_CHECK و بدون هیچ FILE_CHECKer باشد،
            #       اثر آن تنظیم وزن RS به دو واحد کمتر از
            #       وضعیت خروج است.
            #     (برای نمونه: وضعیت خروج ۲۵۵ وزن را به ۲۵۳ تنظیم می‌کند
            #       اگر هیچ MISC_CHECKer یا FILE_CHECKer دیگری روی
            #       آن RS پیکربندی نشده باشد)
            \fBmisc_dynamic\fR

            # نام کاربری/نام گروهی را که اسکریپت باید تحت آن
            #   اجرا شود مشخص کنید.
            # اگر GROUPNAME مشخص نشده باشد، از گروه کاربر
            #   استفاده می‌شود
            \fBuser \fRUSERNAME [GROUPNAME]
        }

        # نام نمونه BFD برای بررسی
        \fBBFD_CHECK \fR{
            \fBname \fR<STRING>
        }

        # بررسی‌کننده سلامت PING
        # نکته: استفاده از این بررسی‌کننده ممکن است باعث به‌روزرسانی /proc/sys/net/ipv4/ping_group_range
        # شود تا به root اجازه استفاده از سوکت IPPROTO_ICMP را بدهد.
        \fBPING_CHECK \fR{
            # بدون گزینه‌های اضافی
        }

        # بررسی‌کننده سلامت UDP
        # نکته: برای عملکرد صحیح این بررسی‌کننده، به پیام‌های خطای ICMP مانند
        #   HOST_UNREACH، NET_UNREACH، PORT_UNREACH متکی است. HOST_UNREACH به اتمام مهلت زمانی
        #   (timeout) درخواست‌های ARP متکی است، بنابراین connect_timeout باید به اندازه کافی برای این امر طولانی باشد (مثلاً
        #   حداقل ۴ ثانیه).
	# اگر payload مشخص شده باشد، مقدار HEX_STR به عنوان داده UDP ارسال می‌شود، در غیر این صورت یک
	# داده تصادفی (payload) ارسال خواهد شد.
	# اگر require_reply مشخص شده باشد، طول داده‌های دریافتی بررسی می‌شود تا اطمینان حاصل شود که
	# بین min_reply_length و max_reply_length قرار دارد.
	# اگر require_reply بدون یک رشته هگزادسیمال مشخص شده باشد، داده پاسخ UDP باید دریافت شود
	# اما محتوای داده بررسی نمی‌شود.
	# اگر مقدار HEX_STR برای require_reply مشخص شده باشد، داده پاسخ با
	# HEX_STR مقایسه می‌شود که باید تا حداقل طول داده‌های دریافتی و طول
	# HEX_STR مربوط به require_reply مطابقت داشته باشد.
	# قالب HEX_STR کاملاً آزاد است، برای نمونه:
	#   Ab12f 3 456 546443123
	# به صورت زیر تفسیر خواهد شد:
	#   AB 12 0F 03 45 06 54 64 43 12 03
	# برای HEX_STR در require_reply، یک نویسه می‌تواند به صورت X یا x مشخص شود که در این صورت
	# مقدار آن ۴ بیت در پاسخ نادیده گرفته می‌شود. این امر برای نمونه امکان استفاده از
	# نوعی شمارنده یا موارد مشابه را فراهم می‌کند.
        # ممکن است بخواهید هم‌زمان از PING_CHECK نیز برای همان سرور استفاده کنید.
        \fBUDP_CHECK \fR{
		\fBpayload\fR <HEX_STR>
	        \fBrequire_reply\fR [<HEX_STR>]	# برای موفقیت‌آمیز بودن بررسی به یک بسته پاسخ نیاز دارد
		min_reply_length <INT>		# پیش‌فرض 0
		max_reply_length <INT>		# پیش‌فرض 255 است
        }

        # بررسی‌کننده پرونده (File checker)
        # این بررسی‌کننده محتویات یک پرونده را می‌خواند و نظارت می‌کند، که در آن STRING نام مشخص‌شده
        # در بلوک پیکربندی track_file است (بالا را ببینید).
        \fBFILE_CHECK \fR{
            \fBtrack_file \fR<STRING>

            # اگر dynamic تنظیم شود، مقدار خوانده‌شده از پرونده برای تنظیم پویای وزن
            # از طریق افزودن وزن به quorum و وزن LVS استفاده می‌شود
            \fBdynamic\fR

            # ضریب وزنی که باید روی مقدار خوانده‌شده از پرونده اعمال شود
            \fBweight\fR <-2147483647..2147483647> [reverse]
        }
    }
}
.fi
.PP
.nf
# پارامترهای مورد استفاده برای بررسی SSL_GET.
# اگر هیچ‌یک از پارامترها مشخص نشده باشند، بافتار (context) مربوط به SSL
# به طور خودکار تولید خواهد شد.
\fBSSL \fR{
    # گذرواژه
    \fBpassword \fR<STRING>
    # پرونده CA
    \fBca \fR<STRING>
    # پرونده گواهی (Certificate)
    \fBcertificate \fR<STRING>
    # پرونده کلید (Key)
    \fBkey \fR<STRING>
}
.fi
.PP
.SH "پیکربندی پیشرفته (ADVANCED CONFIGURATION)"
.PP
تجزیه‌کننده پیکربندی برای پشتیبانی از قابلیت‌های پیشرفته‌ای مانند پیکربندی شرطی و جایگزینی پارامترها گسترش یافته است. این قابلیت‌ها برای هر محیط اسکریپت‌نویسی‌شده‌ای که در آن قالب‌های پیکربندی تولید می‌شوند (مراکز داده) بسیار کاربردی هستند.
.PP
.SH "پیکربندی شرطی و شناسه پیکربندی (Conditional configuration and configuration id)"
مقدار پیش‌فرض config-id بخش اول نام گره برگشتی توسط uname است و می‌تواند با گزینه خط فرمان \-i یا \-\-config\-id بازنویسی شود.
.PP
هر خط پیکربندی که با «@» شروع شود یک خط پیکربندی شرطی است. کلمه بلافاصله پس از نویسه «@» (یعنی بدون هیچ فاصله‌ای) با config-id مقایسه می‌شود، و در صورت عدم تطابق، خط پیکربندی نادیده گرفته می‌شود.
.PP
به طور متناوب، «@^» یک مقایسه منفی است، بنابراین اگر کلمه بلافاصله بعد از آن با config-id تطابق نداشته باشد، خط پیکربندی گنجانده می‌شود.
.PP
هدف از این کار امکان استفاده از یک پرونده پیکربندی واحد برای چندین سیستم است، که در آن تنها تفاوت‌های احتمالی router_id، اولویت‌های نمونه‌های vrrp، و احتمالاً نام رابط‌ها و نشانی‌های unicast هستند.
.PP
برای مثال:
.PP
.nf
    \fBglobal_defs \fR{
        @main   \fBrouter_id \fRmain_router
        @backup \fBrouter_id \fRbackup_router
    }
    ...
    \fBvrrp_instance \fRVRRP {
        ...
        @main    \fBunicast_src_ip \fR1.2.3.4
        @backup  \fBunicast_src_ip \fR1.2.3.5
        @backup2 \fBunicast_src_ip \fR1.2.3.6
        \fBunicast_peer \fR{
            @^main    1.2.3.4
            @^backup  1.2.3.5
            @^backup2 1.2.3.6
        }
        ...
    }
.fi
.PP
اگر keepalived با \-i main فراخوانی شود، router_id روی main_router تنظیم خواهد شد؛ اگر با \-i backup فراخوانی شود، روی backup_router تنظیم می‌شود؛ و اگر بدون \-i یا با هر مقدار دیگری برای \-i فراخوانی شود، router_id تنظیم نخواهد شد. همتایان unicast برای main برابر 1.2.3.5 و 1.2.3.6 خواهند بود.
.SH "جایگزینی پارامترها (Parameter substitution)"
پارامترهای قابل جایگزینی را می‌توان مشخص کرد. قالب تعریف یک پارامتر به این صورت است:
.PP
$PARAMETER=VALUE
.PP
که در آن نباید هیچ فاصله‌ای قبل از «=» وجود داشته باشد و تنها نویسه‌های فاصله خالی (whitespace) می‌توانند قبل از «$» قرار گیرند. مقادیر خالی مجاز هستند.

نام‌های پارامتر می‌توانند از هر ترکیبی از A-Za-z0-9 و _ تشکیل شوند، اما نمی‌توانند با یک رقم شروع شوند. نام‌های پارامتری که با زیرخط (underscore) شروع می‌شوند باید به عنوان نام‌های رزرو شده در نظر گرفته شوند که keepalived برای گزینه‌های مختلف از پیش تعریف‌شده تعریف می‌کند.

پس از تعریف یک پارامتر، هر بار وقوع $PARAMETER که پس از آن فاصله خالی باشد، یا هر بار وقوع ${PARAMETER} (که نیازی به قرار گرفتن فاصله خالی پس از آن نیست) با VALUE جایگزین خواهد شد.

جایگزینی به صورت بازگشتی است، بنابراین اگر مقدار یک پارامتر خود شامل یک پارامتر قابل جایگزینی باشد، پس از اولین جایگزینی، پارامتر موجود در مقدار نیز جایگزین خواهد شد؛ جایگزینی در زمان اعمال جایگزینی انجام می‌شود و نه در زمان تعریف، بنابراین به عنوان مثال:
.PP
.nf
    $ADDRESS_BASE=10.2.${ADDRESS_BASE_SUB}
    $ADDRESS_BASE_SUB=0
    ${ADDRESS_BASE}.100/32
    $ADDRESS_BASE_SUB=10
    ${ADDRESS_BASE}.100/32

    نتیجه زیر را تولید خواهد کرد:
        10.2.0.100/32
        10.2.10.100/32
.fi
.PP
توجه داشته باشید که در مثال‌های فوق، استفاده از هر دو پارامتر ADDRESS_BASE و ADDRESS_BASE_SUB نیازمند آکولاد ({}) بود زیرا پس از پارامترها فاصله خالی وجود نداشت (پس از اولین جایگزینی که 10.2.${ADDRESS_BASE_SUB}.100/32 را تولید کرد، پارامتر همچنان بدون فاصله خالی در ادامه است).

اگر پارامتری تعریف نشده باشد، اصلاً جایگزین نخواهد شد؛ بنابراین برای مثال ${UNDEF_PARAMETER} در صورت تعریف‌نشده بودن در پیکربندی باقی می‌ماند؛ این بدان معناست که پیکربندی موجود که حاوی نویسه «$» است (برای مثال در تعریف یک اسکریپت) تا زمانی که تعاریف پارامتر جدیدی به پیکربندی اضافه نشود، تغییر نخواهد کرد.

جایگزینی پارامترها در هماهنگی با پیکربندی شرطی کار می‌کند. برای مثال:
.PP
.nf
    @main $PRIORITY=240
    @backup $PRIORITY=200
    \fR...
    \fBvrrp_instance \fRVI_0 {
        \fBpriority \fR$PRIORITY
    }

    نتیجه زیر را تولید خواهد کرد:
        \fR...
        \fBvrrp_instance \fRVI_0 {
            \fBpriority \fR240
        }
        اگر config_id برابر main باشد.

    $IF_MAIN=@main
    $IF_MAIN \fBpriority \fR240

    نتیجه زیر را تولید خواهد کرد:
        \fBpriority \fR240
        اگر config_id برابر main باشد و در صورتی که config_id برابر main نباشد هیچ چیزی تولید نمی‌کند،
        اگرچه مشخص نیست چرا کسی بخواهد به جای حالت ساده زیر از این روش استفاده کند
        (اما همچنان ممکن است):
            @main \fBpriority \fR240
.fi
.PP
تعاریف چندخطی نیز پشتیبانی می‌شوند، اما هنگام استفاده از آنها نباید هیچ چیزی در خط بعد از نام پارامتر وجود داشته باشد. یک تعریف چندخطی با پایان دادن به هر خط به جز خط آخر با یک نویسه «\e» مشخص می‌شود.
.PP
مثال:
.nf
    $INSTANCE= \e
    \fBvrrp_instance \fRVI_${NUM} { \e
        \fBinterface \fReth0.${NUM} \e
        \fBuse_vmac \fRvrrp${NUM}.1 \e
        \fBvirtual_router_id \fR1 \e
        @high \fBpriority \fR130 \e
        @low \fBpriority \fR120 \e
        \fBadvert_int \fR1 \e
        \fBvirtual_ipaddress \fR{ \e
            10.0.${NUM}.254/24 \e
        } \e
        \fBtrack_script \fR{ \e
            offset_instance_${NUM} \e
        } \e
    }

    $NUM=0
    $INSTANCE

    $NUM=1
    $INSTANCE
.fi
.PP
استفاده از تعاریف چندخطی می‌تواند تودرتو باشد.
.PP
مثال:
.nf
    $RS= \e
    \fBreal_server \fR192.168.${VS_NUM}.${RS_NUM} 80 { \e
        \fBweight \fR1 \e
        \fBinhibit_on_failure\fR \e
        \fBsmtp_alert\fR \e
        \fBMISC_CHECK \fR{ \e
            \fBmisc_path \fR"${_PWD}/scripts/vs.sh RS_misc.${INST}.${VS_NUM}.${RS_NUM}.0 10.0.${VS_NUM}.4:80->192.168.${VS_NUM}.${RS_NUM}:80" \e
        } \e

        \fBMISC_CHECK \fR{ \e
            \fBmisc_path \fR"${_PWD}/scripts/vs.sh RS_misc.${INST}.${VS_NUM}.${RS_NUM}.1 10.0.${VS_NUM}.4:80->192.168.${VS_NUM}.${RS_NUM}:80" \e
        } \e

        \fBnotify_up \fR"${_PWD}/scripts/notify.sh RS_notify.${INST}.${VS_NUM}.${RS_NUM} UP 10.0.${VS_NUM}.4:80->192.168.${VS_NUM}.${RS_NUM}:80" \e

        \fBnotify_down \fR"${_PWD}/scripts/notify.sh RS_notify.${INST}.${VS_NUM}.${RS_NUM} DOWN 10.0.${VS_NUM}.4:80->192.168.${VS_NUM}.${RS_NUM}:80" \e

    }

    $VS= \e
    \fBvirtual_server \fR10.0.${VS_NUM}.4 80 { \e
        \fBquorum \fR2 \e
        \fBquorum_up \fR"${_PWD}/scripts/notify.sh VS_notify.${INST} UP 10.0.${VS_NUM}.4:80" \e
        \fBquorum_down \fR"${_PWD}/scripts/notify.sh VS_notify.${INST} DOWN 10.0.${VS_NUM}.4:80" \e
        $RS_NUM=1 \e
        $RS \e
        $RS_NUM=2 \e
        $RS \e
        $RS_NUM=3 \e
        $RS \e
    }

    $VS_NUM=0
    $ALPHA=alpha
    $VS

    $VS_NUM=1
    $ALPHA=
    $VS
.fi
.PP
مورد فوق ۲ سرور مجازی ایجاد می‌کند که هر کدام دارای ۳ سرور واقعی هستند
.SH "تعاریف از پیش تعریف‌شده (Pre-defined definitions)"
.PP
تعاریف زیر از پیش تعریف شده‌اند:
.sp
\fB${_PWD} : \fRشاخه پرونده پیکربندی فعلی (در صورت استفاده از دستور include می‌تواند تغییر کند).
.br
\fB${_INSTANCE} : \fRنام نمونه (همان‌طور که توسط گزینه \-i تعریف شده است، به طور پیش‌فرض hostname).
.br
\fB${_RANDOM [MIN [MAX]]} : \fRبا یک عدد صحیح تصادفی در محدوده [MIN, MAX] جایگزین می‌شود، که در آن MIN و MAX اعداد صحیح غیرمنفی اختیاری هستند. مقادیر پیش‌فرض MIN=0 و MAX=32767 هستند.
.br
\fB${_ENV ENV_VAR} : \fRبا مقدار متغیر محیطی $ENV_VAR جایگزین می‌شود.
.br
\fB${_HASH} : \fR با یک نویسه «#» جایگزین می‌شود که در غیر این صورت یک توضیح (comment) را آغاز می‌کرد
.br
\fB${_BANG} : \fR با یک نویسه «!» جایگزین می‌شود که در غیر این صورت یک توضیح را آغاز می‌کرد
.PP
تعاریف از پیش تعریف‌شده دیگری با شناسایی نیاز به آن‌ها اضافه خواهند شد. معمولاً افزودن تعاریف از پیش تعریف‌شده اضافی بسیار ساده خواهد بود، بنابراین اگر به موردی نیاز دارید یا ایده خوبی برای آن دارید، در https://github.com/acassen/keepalived/issues یک issue ثبت کرده و آن را درخواست کنید.
.SH "بلوک‌های توالی (Sequence blocks)"
.PP
یک خط که با \fB~SEQ(var, start, step, end)\fR شروع می‌شود باعث می‌شود ادامه خط چندین بار پردازش شود، به طوری که متغیر \fB$var\fR در ابتدا روی \fBstart\fR تنظیم شده و سپس \fB$var\fR به طور مکرر به اندازه \fBstep\fR افزایش می‌یابد و زمانی که از \fBend\fR بزرگتر شود خاتمه می‌یابد. \fBstep\fR می‌تواند حذف شود که در این صورت بسته به اینکه \fBend\fR بزرگتر یا کوچکتر از \fBstart\fR باشد، مقدار پیش‌فرض آن 1 یا \-1 خواهد بود. \fBstart\fR نیز می‌تواند حذف شود که در این صورت اگر \fBend\fR > 0 باشد به طور پیش‌فرض 1 و اگر \fBend\fR < 0 باشد برابر \-1 خواهد بود. ~SEQx(...) همانند ~SEQ(...) است، به جز اینکه متغیر $var در مبنای شانزده قالب‌بندی می‌شود که برای نشانی‌های IPv6 کاربردی خواهد بود.

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

مثال‌ها:
.PP
.nf
    ~SEQ(SUBNET, 0, 3) ip_address 10.0.${SUBNET}.1

    تولید خواهد کرد:
        ip_address 10.0.0.1
        ip_address 10.0.1.1
        ip_address 10.0.2.1
        ip_address 10.0.3.1

و
    ~SEQx(SUBNET, 144, 16, 192) ip_address fe80::20:${SUBNET}:1
  یا بهتر
    ~SEQx(SUBNET, 0x90, 0x10, 0xc0) ip_address fe80::20:${SUBNET}:1

    تولید خواهد کرد:
        ip_address fe80::20:90:1
        ip_address fe80::20:a0:1
        ip_address fe80::20:b0:1
        ip_address fe80::20:c0:1

   مثالی دیگر:

	virtual_ipaddress {
	    ~SEQx(AD2, 0x90, 0x10, 0xc0) ~SEQx(AD1, 0x12, -1, 0x0c) fe81::10:${AD2}:${AD1}
	}
.fi
.PP
می‌تواند چندین عنصر ~SEQ در یک خط وجود داشته باشد، بنابراین برای مثال:
.PP
.nf
    $VI4= \e
    \fBtrack_file \fRoffset_instance_4.${IF}.${NUM}.${ID} { \e
        \fBfile \fR"${_PWD}/679/track_files/4.${IF}.${NUM}.${ID}" \e
        \fBweight \fR-100 \e
    } \e
    \fBvrrp_instance \fRvrrp4.${IF}.${NUM}.${ID} { \e
        \fBinterface \fRbond${IF}.${NUM} \e
        \fBuse_vmac \fRvrrp4.${IF}.${NUM}.${ID} \e
        \fBvirtual_router_id \fR${ID} \e
        \fBpriority \fR130 \e
        \fBvirtual_ipaddress \fR{ \e
            10.${IF}.${NUM}.${ID}/24 \e
        } \e
        \fBtrack_file \fR{ \e
            offset_instance_4.${IF}.${NUM}.${ID} \e
        } \e
    }

    \fB~SEQ\fR(IF,0,7) \fB~SEQ\fR(NUM,0,31) \fB~SEQ\fR(ID,1,254) $VI4

    تعداد ۶۵۰۲۴ نمونه vrrp با نام‌هایی از vrrp4.0.0.1 تا
    vrrp4.7.31.254 تولید خواهد کرد.
.fi
.SH "بلوک‌های فهرست (List blocks)"
.PP
بلوک‌های فهرست مشابه بلوک‌های توالی هستند، با این تفاوت که مقادیر جایگزین‌شونده در متغیر در مشخصات ~LST فهرست می‌شوند.

یک خط که با \fB~LST(var, val1, val2, val3)\fR شروع می‌شود باعث می‌شود ادامه خط چندین بار پردازش شود، به طوری که متغیر \fB$var\fR ابتدا روی \fBval1\fR، سپس \fBval2\fR و در نهایت \fBval3\fR تنظیم می‌شود. هر تعداد مقداری را می‌توان مشخص کرد، مشروط بر اینکه حداقل یک مقدار وجود داشته باشد (اگرچه تنها یک مقدار بی‌معنی خواهد بود).

اگر نیاز باشد بیش از یک متغیر در یک زمان جایگزین شوند، متغیرها و مقادیر باید در بلوک‌های {...} قرار گیرند. برای مثال:

    ~LST({IP, IP1}, {10,1},{20,4},{5,6},{12,8}) 192.168.${IP}.${IP1}

ابتدا IP=10 و IP1=1، سپس IP=20 و IP1=4 و غیره را تنظیم کرده و نتیجه زیر را تولید می‌کند:

    192.168.10.1
    192.168.20.4
    192.168.5.6
    192.168.12.8

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

    ~LST(IP, 1, 2, 3, 4) ~LST(IP1, 5,6,7) 192.169.${IP}.${IP1}

تولید می‌کند:
    192.169.1.5
    192.169.1.6
    192.169.1.7
    192.169.2.5
    192.169.2.6
    192.169.2.7
    192.169.3.5
    192.169.3.6
    192.169.3.7
    192.169.4.5
    192.169.4.6
    192.169.4.7

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

    ~LST({IP, IP1}, {10,1},{20,4},{5,6},{12,8}) ~SEQ(IP2,168,2,172) 192.${IP2}.${IP}.${IP1}

تولید می‌کند:

    192.168.10.1
    192.170.10.1
    192.172.10.1
    192.168.20.4
    192.170.20.4
    192.172.20.4
    192.168.5.6
    192.170.5.6
    192.172.5.6
    192.168.12.8
    192.170.12.8
    192.172.12.8
.PP
.SH "تنظیمات هسته (KERNEL SETTINGS)"
مشخص شده است که اگر \fBproxy_arp\fR و \fBproxy_arp_pvlan\fR روی رابطی که VIPها یا eVIPها روی آن پیکربندی شده‌اند فعال باشند، می‌تواند به دلیل پاسخ‌دهی پراکسی به درخواست ARP علاوه بر میزبان keepalived، باعث ارسال پاسخ‌های نادرست به درخواست‌های ARP شود. هر دو باید روی 0 تنظیم شوند تا به درستی کار کنند.
.PP
.SH "نویسندگان (AUTHORS)"
.br
نسخه اولیه توسط Joseph Mack. به‌روزرسانی‌های گسترده توسط Alexandre Cassen و Quentin Armitage.
.SH "همچنین ببینید (SEE ALSO)"
ipvsadm(8), ip \-\-help.