1keepalived.conf(5) Keepalived Configuration's Manual keepalived.conf(5)
2
3
4
6 keepalived.conf - configuration file for Keepalived
7
9 This documentation MUST be considered as THE exhaustive source of in‐
10 formation in order to configure Keepalived. This documenation is sup‐
11 ported and maintained by Keepalived Core-Team.
12
14 keepalived.conf is the configuration file which describes all the
15 Keepalived keywords. Keywords are placed in hierarchies of blocks and
16 subblocks, each layer being delimited by '{' and '}' pairs.
17
18 Comments start with '#' or '!' to the end of the line and can start
19 anywhere in a line.
20
21 The keyword 'include' and variants allow inclusion of other configura‐
22 tion files from within the main configuration file, or from subse‐
23 quently included files.
24
25 The format of the include directive is:
26
27 include FILENAME
28
29 FILENAME can be a fully qualified or relative pathname, and can include
30 wildcards, including csh style brace expressions such as
31 "{foo/{,cat,dog},bar}" if glob() supports them.
32
33 After opening an included file, the current directory is set to the di‐
34 rectory of the file itself, so any relative paths included from a file
35 are relative to the directory of the including file itself.
36
37 The include variants add additional include checks to the current in‐
38 clude_check level (see below) The variants are:
39 includer FILENAME - same as include_check readable
40 includem FILENAME - same as include_check match
41 includew FILENAME - same as include_check wildcard_match
42 includeb FILENAME - same as include_check brace_match
43 includea FILENAME - all include_check checks
44
45 NOTE: If the libc glob() function does not support GLOB_ALTDIRFUNC
46 (e.g. Musl libc as on Alpine Linux etc.), then only includea, includer
47 and includew of the above options will work.
48
49 Why do we want to allow errors? Suppose a configuration has optional
50 files in /etc/keepalived/conf.d, then include_/etc/keepalived/conf.d/*
51 could be specified, but it should not error if there are no files in
52 the directory; in this case includer should be used. Otherwise it is
53 sensible to use includea.
54
55 include handling will not work with if the include line uses condi‐
56 tional configuration or parameter substitution, since the detection of
57 the include keywords is done before the processing on conditional con‐
58 figuration and parameter substitution.
59
60 The basic include keyword is retained for backward compatibility, since
61 it does not produce config errors if files could not be opened etc.
62
64 <BOOL> is one of on|off|true|false|yes|no
65 <TIMER> is a time value in seconds, including fractional seconds, e.g.
66 2.71828 or 3; resolution of timer is micro-seconds.
67
69 There are three classes of scripts can be configured to be executed.
70
71 (a) Notify scripts that are run when a vrrp instance or vrrp group
72 changes state, or a virtual server quorum changes between up and down.
73
74 (b) vrrp tracking scripts that will cause vrrp instances to go down it
75 they exit a non-zero exist status, or if a weight is specified will add
76 or subtract the weight to/from the priority of that vrrp instance.
77
78 (c) LVS checker misc scripts that will cause a real server to be con‐
79 figured down if they exit with a non-zero status.
80
81 By default the scripts will be executed by user keepalived_script if
82 that user exists, or if not by root, but for each script the user/group
83 under which it is to be executed can be specified.
84
85 There are significant security implications if scripts are executed
86 with root privileges, especially if the scripts themselves are modifi‐
87 able or replaceable by a non root user. Consequently, security checks
88 are made at startup to ensure that if a script is executed by root,
89 then it cannot be modified or replaced by a non root user.
90
91 All scripts should be written so that they will terminate on receipt of
92 a SIGTERM signal. Scripts will be sent SIGTERM if their parent termi‐
93 nates, or it is a script that keepalived is awaiting its exit status
94 and it has run for too long.
95
97 Quoted strings are specified between " or ' characters and strings are
98 delimited by whitespace. In the examples below the ´ characters are not
99 part of the strings and should not be specified:
100
101 ´abcd" efg h jkl "mnop´
102
103 will be the single string:
104
105 ´abcd efg h jkl mnop´
106
107 whereas:
108
109 ´abcd "efg h jkl" mnop´
110
111 will be the three strings:
112
113 ´abcd´, ´efg h jkl´ and ´mnop´
114
115 i.e. the " and ' characters are removed and any intervening whitespace is retained.
116
117 Quoted strings can also have escaped characters, like the shell. \a, \b, \E, \f,
118 \n, \r, \t, \v, \nnn and \xXX (where nnn is up to 3 octal digits, and XX is any
119 sequence of hex digits) and \cC (which produces the control version of
120 character C) are all supported. \C for any other character C is just
121 treated as an escaped version of character C, so \\ is a \ character and
122 \" will be a " character, but it won't start or terminate a quoted string.
123
124 For specifying scripts with parameters, unquoted spaces will separate the parameters.
125 If it is required for a parameter to contain a space, it should be enclosed in single
126 quotes (').
127
128
130 Traditionally the configuration file parser has not been one of the
131 strengths of keepalived. Lot of efforts have been put to correct this
132 even if this is not the primal goal of the project.
133
135 Keepalived configuration file is articulated around a set of configura‐
136 tion blocks. Each block is focusing and targetting a specific daemon
137 family feature. These features are:
138
139 GLOBAL CONFIGURATION
140
141 BFD CONFIGURATION
142
143 VRRPD CONFIGURATION
144
145 LVS CONFIGURATION
146
148 contains subblocks of Global definitions, Linkbeat interfaces, Inter‐
149 face up/down transition delays, Static track groups, Static addresses,
150 Static routes, and Static rules
151
153 # Following are global daemon facilities for running
154 # keepalived in a separate network namespace:
155 # --
156 # Set the network namespace to run in.
157 # The directory /run/keepalived will be created as an
158 # unshared mount point, for example for pid files.
159 # syslog entries will have _NAME appended to the ident.
160 # Note: the namespace cannot be changed on a configuration reload.
161 net_namespace NAME
162
163 # Add the IPVS configuration in the specified net namespace. It allows to easily
164 # split the VIP traffic on a given namespace and keep the healthchecks traffic
165 # in another namespace. If NAME is not specified, then the default namespace
166 # will be used.
167 net_namespace_ipvs NAME
168
169 # ipsets wasn't network namespace aware until Linux 3.13, and so
170 # if running with an earlier version of the kernel, by default
171 # use of ipsets is disabled if using a namespace and vrrp_ipsets
172 # has not been specified. This options overrides the default and
173 # allows ipsets to be used with a namespace on kernels prior to 3.13.
174 namespace_with_ipsets
175
176 # If multiple instances of keepalived are run in the same namespace,
177 # this will create pid files with NAME as part of the file names,
178 # in /run/keepalived.
179 # Note: the instance name cannot be changed on a configuration reload
180 instance NAME
181
182 # Create pid files in /run/keepalived
183 use_pid_dir
184
185 # Poll to detect media link failure using ETHTOOL, MII or ioctl interface
186 # otherwise uses netlink interface.
187 linkbeat_use_polling
188
189 # Time for main process to allow for child processes to exit on termination
190 # in seconds. This can be needed for very large configurations.
191 # (default: 5)
192 child_wait_time SECS
193
194 Note: All processes/scripts run by keepalived are run with parent death signal set
195 to SIGTERM. All such processes/scripts should either not change the action for
196 SIGTERM, or ensure that the process/script terminates once SIGTERM is received,
197 possibly following any cleanup actions needed.
198
199 # Global definitions configuration block
200 global_defs {
201 # In order to ensure that all processes read exactly the same configuration,
202 # while the config is first read it is written, by default, to a memory based
203 # file (or to an anonymous file in /tmp/ if memfd_create() is not supported).
204 # If your configuration is very large, you may not want the copy to be
205 # held in memory, in which case specifing the tmp_config_directory causes the
206 # configuration to be written to an anonymous file on the filesystem on which
207 # the specified directory resides, which must be writeable by keepalived.
208 # This setting cannot be changed on a reload, and it should be specified as
209 # early as possible in the configuration.
210 tmp_config_directory DIRECTORY
211
212 # config_save_dir causes keepalived to save configuration state and
213 # configuration files before and after each reload. This is used for debugging
214 # purposes if there appear to be problems related to repeated reloads.
215 # The directory will be created if it does not exist, but all parent
216 # directories must exist.
217 config_save_dir DIRECTORY
218
219 # Set the process names of the keepalived processes to the default values:
220 # keepalived, keepalived_vrrp, keepalived_ipvs, keepalived_bfd
221 process_names
222
223 # Specify the individual process names
224 process_name NAME
225 vrrp_process_name NAME
226 checker_process_name NAME
227 bfd_process_name NAME
228
229 # The startup and shutdown scripts are run once, when keepalived starts
230 # before any child processes are run, and when keepalived stops after
231 # all child processes have terminated, respectively.
232 # The original motivation for adding this feature was that although
233 # keepalived can setup IPVS configuration using firewall marks, there
234 # was no mechanism for adding configuration to set the firewall marks
235 # (or for removing it afterwards).
236 # This feature can also be used to setup the iptables framework required
237 # if using iptables (see vrrp_iptables option below), modify interface
238 # settings, or anything else that can be done from a script or program.
239 # Only one startup script and one shutdown script can be specified.
240 # The timeouts (in seconds default 10 seconds) are the time allowed for
241 # scripts to run; if the timeout expires the scripts will be killed (this
242 # is to stop keepalived hanging waiting for the scripts to terminate).
243 startup_script SCRIPT_NAME [username [groupname]]
244 startup_script_timeout SECONDS # range [1,1000]
245 shutdown_script SCRIPT_NAME [username [groupname]]
246 shutdown_script_timeout SECONDS # range [1,1000]
247
248 # Set of email To: notify
249 notification_email {
250 admin@example1.com
251 ...
252 }
253
254 # email from address that will be in the header
255 # (default: keepalived@<local host name>)
256 notification_email_from admin@example.com
257
258 # Remote SMTP server used to send notification email.
259 # IP address or domain name with optional port number.
260 # (default port number: 25)
261 smtp_server 127.0.0.1 [<PORT>]
262
263 # Name to use in HELO messages.
264 # (default: local host name)
265 smtp_helo_name <STRING>
266
267 # SMTP server connection timeout in seconds.
268 smtp_connect_timeout 30
269
270 # Sets default state for all smtp_alerts
271 smtp_alert <BOOL>
272
273 # Sets default state for vrrp smtp_alerts
274 smtp_alert_vrrp <BOOL>
275
276 # Sets default state for checker smtp_alerts
277 smtp_alert_checker <BOOL>
278
279 # Logs every failed real server check in syslog
280 # (nevertheless, SMTP alert is only sent when all retry checks failed
281 # and real server transitions to DOWN state)
282 checker_log_all_failures <BOOL>
283
284 # Don't send smtp alerts for fault conditions
285 no_email_faults
286
287 # String identifying the machine (doesn't have to be hostname).
288 # (default: local host name)
289 router_id <STRING>
290
291 # Multicast Group to use for IPv4 VRRP adverts
292 # Defaults to the RFC5798 IANA assigned VRRP multicast address 224.0.0.18
293 # which You typically do not want to change.
294 vrrp_mcast_group4 224.0.0.18
295
296 # Multicast Group to use for IPv6 VRRP adverts
297 # (default: ff02::12)
298 vrrp_mcast_group6 ff02::12
299
300 # sets the default interface for static addresses.
301 # (default: eth0)
302 default_interface p33p1.3
303
304 # The sync daemon as provided by the IPVS kernel code only supports
305 # one master and one backup daemon instance at a time to synchronize
306 # the IPVS connection table.
307 # See ipvsadm(8) man page for more details of the sync daemon.
308 # Parameters are binding interface, and optional:
309 # inst VRRP_INSTANCE (inst can be omitted for backward compatibility)
310 # syncid (0 to 255) for lvs syncd, default is the VRID of vrrp instance,
311 # or 0 if no vrrp instance
312 # maxlen (1..65507) maximum packet length (limit is mtu - 20 - 8)
313 # port (1..65535) UDP port number to use, default 8848
314 # ttl (1..255)
315 # group - multicast group address(IPv4 or IPv6), default 224.0.0.81
316 # If VRRP_INSTANCE is not specified, both the master and backup sync daemons
317 # will be run as long as keepalived is running, otherwise the sync daemon
318 # master/backup state tracks the state of the specified vrrp instance: if
319 # the vrrp instance is in master state, only the master sync daemon will run,
320 # if the vrrp instance is not master, only the backup sync daemon will run.
321 # NOTE: maxlen, port, ttl and group are only available on Linux 4.3 or later.
322 # See kernel source doc/Documentation/networking/ipvs-sysctl.txt for details of
323 # parameters controlling IPVS and the sync daemon.
324 # /proc/net/ip_vs* provide some details about the state of IPVS.
325 lvs_sync_daemon <INTERFACE> [[inst] <VRRP_INSTANCE>] [id <SYNC_ID>] \
326 [maxlen <LEN>] [port <PORT>] [ttl <TTL>] [group <IP ADDR>]
327
328 # lvs_timeouts specifies the tcp, tcp_fin and udp connection tracking timeouts
329 # in seconds. At least one value must be specified; not setting a value leaves
330 # it unchanged from when keepalived started.
331 lvs_timeouts [tcp SECS] [tcpfin SECS] [udp SECS]
332
333 # flush any existing LVS configuration at startup
334 lvs_flush
335
336 # flush remaining LVS configuration at shutdown (for large configurations
337 # this is much faster than the default approach of deleting each RS and
338 # each VS individually).
339 # If VS is specified, remove each keepalived managed virtual
340 # server without explicitly removing the real servers (the kernel will
341 # remove them).
342 lvs_flush_on_stop [VS]
343
344 # delay for second set of gratuitous ARPs after transition to MASTER.
345 # in seconds, 0 for no second set.
346 # (default: 5)
347 vrrp_garp_master_delay 10
348
349 # number of gratuitous ARP messages to send at a time after
350 # transition to MASTER.
351 # (default: 5)
352 vrrp_garp_master_repeat 1
353
354 # delay for second set of gratuitous ARPs after lower priority
355 # advert received when MASTER.
356 # (default: vrrp_garp_master_delay)
357 vrrp_garp_lower_prio_delay 10
358
359 # Default value for vrrp down_timer_adverts.
360 vrrp_down_timer_adverts [1:100]
361
362 # number of gratuitous ARP messages to send at a time after
363 # lower priority advert received when MASTER.
364 # (default: vrrp_garp_master_repeat)
365 vrrp_garp_lower_prio_repeat 1
366
367 # minimum time interval for refreshing gratuitous ARPs while MASTER.
368 # in seconds (resolution seconds).
369 # (default: 0 (no refreshing))
370 vrrp_garp_master_refresh 60
371
372 # number of gratuitous ARP messages to send at a time while MASTER
373 # (default: 1)
374 vrrp_garp_master_refresh_repeat 2
375
376 # Delay between gratuitous ARP messages sent on an interface
377 # decimal, seconds (resolution usecs).
378 # (default: 0)
379 vrrp_garp_interval 0.001
380
381 # Delay between unsolicited NA messages sent on an interface
382 # decimal, seconds (resolution usecs).
383 # (default: 0)
384 vrrp_gna_interval 0.000001
385
386 # By default keepalived sends 5 gratuitions ARP/NA messages at a
387 # time, and after transitioning to MASTER sends a second block of
388 # 5 messages 5 seconds later.
389 # With modern switches this is unnecessary, so setting vrrp_min_garp
390 # causes only one ARP/NA message to be sent, with no repeat 5 seconds
391 # later.
392 vrrp_min_garp [<BOOL>]
393
394 # The following option causes periodic GARP/NA messages to be sent on
395 # interfaces of VIPs/eVIPs that are not the interface of the VRRP
396 # instance, in order to ensure that switch MAC caches are maintained
397 # (specified in seconds).
398 # Many switches have a default cache timeout of 300 seconds, and so
399 # a garp repeat rate of 1/3rd of that would be sensible. The maximum
400 # permitted value is 1 day (86400 seconds);
401 # By default, it will only send on VMAC interfaces; specifying all
402 # will cause it to send GARP/NA on each interface used by the VRRP instance.
403 vrrp_garp_extra_if [all] 100
404
405 # If a lower priority advert is received, don't send another advert.
406 # This causes adherence to the RFCs. Defaults to false, unless
407 # strict_mode is set.
408 vrrp_lower_prio_no_advert [<BOOL>]
409
410 # If we are master and receive a higher priority advert, send an advert
411 # (which will be lower priority than the other master), before we
412 # transition to backup. This means that if the other master has
413 # garp_lower_priority_repeat set, it will resend garp messages.
414 # This is to get around the problem of their having been two simultaneous
415 # masters, and the last GARP messages seen were from us.
416 vrrp_higher_prio_send_advert [<BOOL>]
417
418 # Set the default VRRP version to use
419 # (default: 2, but IPv6 instances will use version 3)
420 vrrp_version <2 or 3>
421
422 # See vrrp_instance description of V3_checksum_as_V2
423 v3_checksum_as_v2 [<BOOL>]
424
425 # keepalived uses a firewall (either nftables or iptables) for two purposes:
426 # i) To implement no_accept mode
427 # ii) To stop IGMP/MLD/Router-Solicit packets being sent on VMAC interfaces,
428 # and to move IGMP/MLD messages onto the underlying interface.
429 # If both vrrp_iptables and vrrp_nftables are specified, keepalived will use
430 # nftables and not iptables. Similarly, if the iptables command is generating
431 # nftables configuration, or there is no iptables command installed,
432 # keepalived will use nftables rather than iptables.
433 # If neither vrrp_nftables or vrrp_iptables are specified but VMACs are in use
434 # or no_accept is specified, keepalived will use nftables if it is available.
435
436 # Use nftables as the firewall.
437 # TABLENAME must not exist, and must be different for each
438 # instance of keepalived running in the same network namespace.
439 # Default tablename is keepalived, and priority is -1.
440 # keepalived will create base chains in the table.
441 # counters means counters are added to the rules (primarily for
442 # debugging purposes).
443 # ifindex means create IPv6 link local sets using ifindex rather
444 # than ifnames. This is the default unless the vrrp_instance has
445 # set dont_track_primary. The alternative is to use interface names
446 # as part of the set key, but the nft utility prior to v0.8.3 will
447 # then not output interface names properly.
448 nftables [TABLENAME]
449 nftables_priority PRIORITY
450 nftables_counters
451 nftables_ifindex
452
453 # Similarly for IPVS iptables - used for setting fwmarks for virtual
454 # server groups. keepalived will allocate a fwmark for each virtual
455 # server group, so that only one virtual server for each group needs
456 # to be configured in IPVS, by using a fwmark, and nftables will be
457 # used to set the fwmark for each of the virtual server
458 # address/protocol/port combinations specified.
459 # nftables_ipvs_start_fwmark specifies the first fwmark for keepalived
460 # to use (default 1000). This will be incremented for each subsequent
461 # virtual server group.
462 nftables_ipvs [TABLENAME]
463 nftables_ipvs_priority PRIORITY
464 nftables_ipvs_start_fwmark NUMBER
465
466 # Use iptables as the firewall.
467 # Note: it is necessary for the specified chain to exist in
468 # the iptables and/or ip6tables configuration, and for the chain
469 # to be called from an appropriate point in the iptables configuration.
470 # It will probably be necessary to have this filtering after accepting
471 # any ESTABLISHED,RELATED packets, because IPv4 might select the VIP as
472 # the source address for outgoing connections.
473 # Note: although the default chains that are used are INPUT and OUTPUT,
474 # since those are the only chains that will always exist, it is not safe
475 # or sensible to use those chains and specific chains should be created
476 # and called from appropriate points in the iptables configuration. The
477 # chains used for keepalived should not be used for any other purpose, and
478 # should have no rules configured, other than the rules that keepalived
479 # manages.
480 # A startup_script (see above) can be used to create the chains and to
481 # add rules to call them. A shutdown_script can be used to remove the
482 # iptables configuration added by the startup_script.
483 # Note2: If using ipsets, the iptables VIP rules are appended to the end
484 # of the specified chains; if not using ipsets, the VIP rules are inserted
485 # at the beginning of the chains. Any IGMP rules are always appended to
486 # the end of the chains.
487 # (default: INPUT)
488 vrrp_iptables keepalived
489
490 # or for outbound filtering as well
491 # Note, outbound filtering won't work with IPv4, since the VIP can be
492 # selected as the source address for an outgoing connection. With IPv6
493 # this is unlikely since the addresses are deprecated.
494 vrrp_iptables keepalived_in keepalived_out
495
496 # or to to use default chains (INPUT and OUTPUT)
497 vrrp_iptables
498
499 # Keepalived may have the option to use ipsets in conjunction with
500 # iptables. If so, then the ipset names can be specified, defaults
501 # as below. If no names are specified, ipsets will not be used,
502 # otherwise any omitted names will be constructed by adding "_if"
503 # and/or "6" and _igmp/_mld to previously specified names.
504 vrrp_ipsets [keepalived [keepalived6 [keepalived_if6 [keepalived_igmp [keepalived_mld]]]]]
505
506 # An alternative to moving IGMP messages from VMACs to their parent interfaces
507 # is to disable them altogether in the kernel by setting
508 # igmp_link_local_mcast_reports false.
509 # This stops IGMP join etc messages for 224.0.0.0/24, since they should
510 # always be forwarded to all interfaces (see RFC4541).
511 # This is available from Linux 4.3 onwards.
512 disable_local_igmp
513
514 # The following enables checking that when in unicast mode, the
515 # source address of a VRRP packet is one of our unicast peers.
516 vrrp_check_unicast_src
517
518 # Checking all the addresses in a received VRRP advert can be time
519 # consuming. Setting this flag means the check won't be carried out
520 # if the advert is from the same master router as the previous advert
521 # received.
522 # (default: don't skip)
523 vrrp_skip_check_adv_addr
524
525 # Enforce strict VRRP protocol compliance. This currently includes
526 # enforcing the following. Please note that other checks may be
527 # added in the future if they are found to be missing:
528 # 0 VIPs not allowed
529 # unicast peers not allowed
530 # IPv6 addresses not allowed in VRRP version 2
531 # First IPv6 VIP is link local
532 # State MASTER can be configured if and only if priority is 255
533 # Authentication is not supported
534 # Preempt delay is not supported
535 # Accept mode cannot be set for VRRPv2
536 # If accept/no accept is not specified, accept is set if priority
537 # is 255 aand cleared otherwise
538 # Gratuitous ARP repeats cannot be enabled
539 # Cannot clear lower_prio_no_advert
540 # Cannot set higher_prio_send_advert
541 # Cannot use vmac_xmit_base
542 # Cannot have no VIPs with VRRPv3
543 vrrp_strict
544
545 # Send vrrp instance priority notifications on notify FIFOs.
546 vrrp_notify_priority_changes <BOOL>
547
548 # The following options can be used if vrrp, checker or bfd processes
549 # are timing out. This can be seen by a backup vrrp instance becoming
550 # master even when the master is still running, because the master or
551 # backup system is too busy to process vrrp packets.
552 # --
553 # keepalived can, if it detects that it is not running sufficiently
554 # soon after a timer should expire, increase its priority, first
555 # of all switching to realtime scheduling, and if that is not
556 # sufficient, it will then increase its realtime priority by one each
557 # time it detects a further delay in running. If the event that realtime
558 # scheduling is enabled, RLIMIT_RTTIME will be set, using the values for
559 # {bfd,checker,vrrp}_rlimit_rttime (see below). These values may need
560 # to be increased for slower processors.
561 # --
562 # To limit the maximum increased automatic priority, specify the following
563 # (0 doesn't use automatic priority increases, and is the default. -1 disables
564 # the warning message at startup). Omitting the priority sets the maximum value.
565 max_auto_priority [<-1 to 99>] # 99 is really sched_get_priority_max(SCHED_RR)
566
567 # Minimum delay in microseconds after timer expires before keeplalived is
568 # scheduled after which the process priority will be auto incremented
569 # (default is 1000000 usecs (1 second), maximum is 10000000 (10 seconds))
570 min_auto_priority_delay <delay in usecs>
571
572 # Set the vrrp child process priority (Negative values increase priority)
573 vrrp_priority <-20 to 19>
574
575 # Set the checker child process priority
576 checker_priority <-20 to 19>
577
578 # Set the BFD child process priority
579 bfd_priority <-20 to 19>
580
581 # Set the vrrp child process non swappable
582 vrrp_no_swap
583
584 # Set the checker child process non swappable
585 checker_no_swap
586
587 # Set the BFD child process non swappable
588 bfd_no_swap
589
590 # The following options can be used to force vrrp, checker and bfd
591 # processes to run on a restricted CPU set.
592 # You can either bind processes to a single CPU or define a set of
593 # cpu. In that last case Linux kernel will be restricted to that cpu
594 # set during scheduling. Forcing process binding to single CPU can
595 # increase performances on heavy loaded box.
596 # INTEGER following configuration keyword are representing cpu_id
597 # as shown in /proc/cpuinfo on line "processor:"
598 # --
599 # Set CPU Affinity for the vrrp child process
600 vrrp_cpu_affinity <INTEGER> [<INTERGER>]...[<INTEGER>]
601
602 # Set CPU Affinity for the checker child process
603 checker_cpu_affinity <INTEGER> [<INTERGER>]...[<INTEGER>]
604
605 # Set CPU Affinity for the bfd child process
606 bfd_cpu_affinity <INTEGER> [<INTERGER>]...[<INTEGER>]
607
608 # Set the vrrp child process to use real-time scheduling
609 # at the specified priority
610 vrrp_rt_priority <1..99>
611
612 # Set the checker child process to use real-time scheduling
613 # at the specified priority
614 checker_rt_priority <1..99>
615
616 # Set the BFD child process to use real-time scheduling
617 # at the specified priority
618 bfd_rt_priority <1..99>
619
620 # Set the limit on CPU time between blocking system calls,
621 # in microseconds
622 # (default: 10000)
623 vrrp_rlimit_rttime >=2
624 checker_rlimit_rttime >=2
625 bfd_rlimit_rttime >=2
626
627 # If Keepalived has been build with SNMP support, the following
628 # keywords are available.
629 # Note: Keepalived, checker and RFC support can be individually
630 # enabled/disabled
631 # --
632 # Specify socket to use for connecting to SNMP master agent
633 # (see source module keepalived/vrrp/vrrp_snmp.c for more details)
634 # (default: unix:/var/agentx/master)
635 snmp_socket udp:1.2.3.4:705
636
637 # enable SNMP handling of vrrp element of KEEPALIVED MIB
638 enable_snmp_vrrp
639
640 # enable SNMP handling of checker element of KEEPALIVED MIB
641 enable_snmp_checker
642
643 # enable SNMP handling of RFC2787 and RFC6527 VRRP MIBs
644 enable_snmp_rfc
645
646 # enable SNMP handling of RFC2787 VRRP MIB
647 enable_snmp_rfcv2
648
649 # enable SNMP handling of RFC6527 VRRP MIB
650 enable_snmp_rfcv3
651
652 # enable SNMP traps
653 enable_traps
654
655 # If Keepalived has been build with DBus support, the following
656 # keywords are available.
657 # --
658 # Enable the DBus interface
659 enable_dbus
660
661 # Name of DBus service
662 # Useful if you want to run multiple keepalived processes with DBus enabled
663 # (default: org.keepalived.Vrrp1)
664 dbus_service_name SERVICE_NAME
665
666 # Specify the default username/groupname to run scripts under.
667 # If this option is not specified, the user defaults to keepalived_script
668 # if that user exists, otherwise the uid/gid under which keepalived is running.
669 # If groupname is not specified, it defaults to the user's group.
670 script_user username [groupname]
671
672 # Don't run scripts configured to be run as root if any part of the path
673 # is writable by a non-root user. Also, enforce the default script_user is
674 # keepalived_script, and don't default to the user under which keepalived
675 # is running (usually root).
676 enable_script_security
677
678 # Rather than using notify scripts, specifying a fifo allows more
679 # efficient processing of notify events, and guarantees that they
680 # will be delivered in the correct sequence.
681 # NOTE: the FIFO names must all be different
682 # --
683 # FIFO to write notify events to
684 # See vrrp_notify_fifo and lvs_notify_fifo for format of output
685 # For further details, see the description under vrrp_sync_group.
686 # see doc/samples/sample_notify_fifo.sh for sample usage.
687 notify_fifo FIFO_NAME [username [groupname]]
688
689 # script to be run by keepalived to process notify events
690 # The FIFO name will be passed to the script as the last parameter
691 notify_fifo_script STRING|QUOTED_STRING [username [groupname]]
692
693 # FIFO to write vrrp notify events to.
694 # The string written will be a line of the form: INSTANCE "VI_1" MASTER 100
695 # and will be terminated with a new line character.
696 # For further details of the output, see the description under vrrp_sync_group
697 # and doc/samples/sample_notify_fifo.sh for sample usage.
698 vrrp_notify_fifo FIFO_NAME [username [groupname]]
699
700 # script to be run by keepalived to process vrrp notify events
701 # The FIFO name will be passed to the script as the last parameter
702 vrrp_notify_fifo_script STRING|QUOTED_STRING [username [groupname]]
703
704 # FIFO to write notify healthchecker events to
705 # The string written will be a line of the form:
706 # VS [192.168.201.15]:tcp:80 {UP|DOWN}
707 # RS [1.2.3.4]:tcp:80 [192.168.201.15]:tcp:80 {UP|DOWN}
708 # and will be terminated with a new line character.
709 lvs_notify_fifo FIFO_NAME [username [groupname]]
710
711 # script to be run by keepalived to process healthchecher notify events
712 # The FIFO name will be passed to the script as the last parameter
713 lvs_notify_fifo_script STRING|QUOTED_STRING [username [groupname]]
714
715 # By default, when keepalived reloads the vrrp instance and sync group states
716 # are not written to the relevant FIFOs. Setting this option will cause the
717 # states to be sent to the FIFO(s) when keepalived reloads.
718 fifo_write_vrrp_states_on_reload
719
720 # Allow configuration to include interfaces that don't exist at startup.
721 # This allows keepalived to work with interfaces that may be deleted and restored
722 # and also allows virtual and static routes and rules on VMAC interfaces.
723 # allow_if_changes allows an interface to be deleted and recreated with a
724 # different type or underlying interface, eg changing from vlan to macvlan
725 # or changing a macvlan from eth1 to eth2. This is predominantly used for
726 # reporting duplicate VRID errors at startup if allow_if_changes is not set.
727 dynamic_interfaces [allow_if_changes]
728
729 # The following options are only needed for large configurations, where either
730 # keepalived creates a large number of interface, or the system has a large
731 # number of interface. These options only need using if
732 # "Netlink: Receive buffer overrun" messages are seen in the system logs.
733 # If the buffer size needed exceeds the value in /proc/sys/net/core/rmem_max
734 # the corresponding force option will need to be set.
735 # --
736 # Set netlink receive buffer size. This is useful for
737 # very large configurations where a large number of interfaces exist, and
738 # the initial read of the interfaces on the system causes a netlink buffer
739 # overrun.
740 vrrp_netlink_cmd_rcv_bufs BYTES
741 vrrp_netlink_cmd_rcv_bufs_force <BOOL>
742 vrrp_netlink_monitor_rcv_bufs BYTES
743 vrrp_netlink_monitor_rcv_bufs_force <BOOL>
744
745 # The vrrp netlink command and monitor socket the checker command and
746 # and monitor socket and process monitor buffer sizes can be independently set.
747 # The force flag means to use SO_RCVBUFFORCE, so that the buffer size
748 # can exceed /proc/sys/net/core/rmem_max.
749 lvs_netlink_cmd_rcv_bufs BYTES
750 lvs_netlink_cmd_rcv_bufs_force <BOOL>
751 lvs_netlink_monitor_rcv_bufs BYTES
752 lvs_netlink_monitor_rcv_bufs_force <BOOL>
753
754 # As a guide for process_monitor_rcv_bufs for 1400 processes terminating
755 # simultaneously, 212992 (the default on some systems) is insufficient, whereas
756 # 500000 is sufficient.
757 process_monitor_rcv_bufs BYTES
758 process_monitor_rcv_bufs_force <BOOL>
759
760 # When a socket is opened, the kernel configures the max rx buffer size for
761 # the socket to /proc/sys/net/core/rmem_default. On some systems this can be
762 # very large, and even generally this can be much larger than necessary.
763 # This isn't a problem so long as keepalived is reading all queued data from
764 # it's sockets, but if rmem_default was set sufficiently large, and if for
765 # some reason keepalived stopped reading, it could consume all system memory.
766 # The vrrp_rx_bufs_policy allows configuring of the rx bufs size when the
767 # sockets are opened. If the policy is MTU, the rx buf size is configured
768 # to the total of interface's MTU * vrrp_rx_bufs_multiplier for each vrrp
769 # instance using the socket. Likewise, if the policy is ADVERT, then it is
770 # the total of each vrrp instances advert packet size * multiplier.
771 # (default: use system default)
772 vrrp_rx_bufs_policy [MTU|ADVERT|NUMBER]
773
774 # (default: 3)
775 vrrp_rx_bufs_multiplier NUMBER
776
777 # Send notifies at startup for real servers that are starting up
778 rs_init_notifies
779
780 # Don't send an email every time a real server checker changes state;
781 # only send email when a real server is added or removed
782 no_checker_emails
783
784 # The umask to use for creating files. The number can be specified in hex, octal
785 # or decimal. BITS are I{R|W|X}{USR|GRP|OTH}, e.g. IRGRP, separated by '|'s.
786 # IRWX{U|G|O} can also be specified.
787 # The default umask is IXUSR | IRWXG | IRWXO. This option cannot override the
788 # command-line option.
789 umask [NUMBER|BITS]
790
791 # On some systems when bond interfaces are created, they can start passing traffic
792 # and then have a several second gap when they stop passing traffic inbound. This
793 # can mean that if keepalived is started at boot time, i.e. at the same time as
794 # bond interfaces are being created, keepalived doesn't receive adverts and hence
795 # can become master despite an instance with higher priority sending adverts.
796 # This option specifies a delay in seconds before vrrp instances start up after
797 # keepalived starts,
798 vrrp_startup_delay 5.5
799
800 # The following will cause logging of receipt of VRRP adverts for VRIDs not configured
801 # on the interface on which they are received.
802 log_unknown_vrids
803
804 # Specify the prefix for generated VMAC names (default "vrrp")
805 vmac_prefix STRING
806
807 # Specify the prefix for generated VMAC names for VIPs which use a VMAC but are not
808 # on the VRRP instance's interface (default vmac_prefix value)
809 vmac_addr_prefix STRING
810
811 # Specify random seed for ${_RANDOM}, to make configurations repeatable (default
812 # is to use a seed based on the time, so that each time a different configuration
813 # will be generated).
814 random_seed UNSIGNED_INT
815
816 # If a configuration reload is attempted with an updated configuration file that has
817 # errors, keepalived may terminate, and possibly enter a loop indefinitely restarting
818 # and terminating. If reload_check_config is set, then keepalived will attempt to
819 # validate the configuration before initiating a reload, and only initiate the reload
820 # if the configuration is valid.
821 reload_check_config [LOG_FILE]
822
823 # Treat any missing include file as an error. The OPTIONS can be any combination of
824 # readable - error if a match is not a readable file
825 # match - error if no file matches (unless wildcard specified)
826 # wildcard_match - error if no file matches (even if wildcard specified)
827 # brace_match - error if a brace expansion does not match a file
828 # Note: match, wildcard_match and brace_match include the readable check.
829 # The setting of include_check is saved when a new include file is opened, and restored
830 # when the file is closed. This means that the include_check setting when reading a
831 # file cannot be changed by a subsequently included file. To change the setting for all
832 # included files, include_check should be set at the beginning of the configuration file
833 # specified in the command line (default /etc/keepalived/keepalived.conf).
834 # Note2: If the libc glob() function does not support GLOB_ALTDIRFUNC (e.g. Musl libc as
835 # on Alpine Linux etc.), then only readable and wildcard_match of the above options will work.
836 # It is possible to add or remove individual settings; '+' means add the following
837 # checks, '-' means remove the following checks. For example
838 # include_check +match -wildcard_match
839 # adds the requirement that there is a matching file, and removes the requirement for
840 # wildcard matches.
841 # If no option is specified, it is the same as specifying all options.
842 include_check [OPTIONS]
843
844 # reload_time_file allows a reload of keepalived to be scheduled in the future. This is
845 # particularly useful if there is a master keepalived and one or more backup keepalived
846 # instances and the new configuration is incompatible with the previous configuration,
847 # e.g. adding or removing VIPs which would cause adverts to be rejected.
848 # All the instances can be scheduled to reload at the same time, thereby ensuring that
849 # no mismatching adverts are received by the backup instances.
850 # The configuration specifies a file which keepalived will monitor. The first line of
851 # the file must contain a valid time or date/time exactly in the formats specified below.
852 # When keepalived starts up, it reads the file if it exists, and schedules a reload at
853 # the specified time. If the file does not exist, then when it is subsequently created
854 # a reload will be scheduled. If the file is updated, the reload time will be modified
855 # accordingly. If the file is deleted, the reload is cancelled.
856 # Normally when the reload occurs the specified file is deleted, since the reload has
857 # been done; if the file included a date then the reload will be in the past and so
858 # ignored. However, if there is no date, then if the file were reread following the
859 # reload, a reload would be scheduled for 24 hours time. In order to stop this, the
860 # file is deleted (unlinked) by default. If reload_repeat is specified, then the
861 # file is not deleted, and if the file contains a time only with no date, then
862 # keepalived will keep reloading at that time every day until the file is removed or
863 # modified.
864 # If the directory containing the file does not exist at startup/reload, or if the
865 # directory is removed or renamed, then no future scheduled reloads will occur until
866 # a manual (SIGHUP) reload is done or keepalived restarts.
867 # The permitted formats of the entry in the timer file are precisely:
868 # HH:MM:SS
869 # YY-MM-DD HH:MM:SS
870 # YYYY-MM-DD HH:MM:SS
871 # each with an optional 'Z' at the end.
872 # There must be no leading or trailing whitespace, and only one space between the date
873 # and the time.
874 # If there is a 'Z' at the end of the time, the time is parsed as UTC, otherwise the
875 # time is the localtime for the environment in which keepalived is running. If the
876 # systems which are being reloaded are in different timezones, it is probably safer to
877 # use UTC.
878 # If using local time with daylight savings, beware that some times don't exist and
879 # some times are duplicated and hence ambiguous.
880 reload_time_file ABSOLUTE-PATHNAME-OF-FILE
881 reload_repeat
882
883 # Some users frequently update their configurations and reload keepalived. reload_file
884 # provides a mechanism that allows the configuration update processes not to update the
885 # configuration files while keepalived is reading them.
886 # The reload file will be created by keepalived before it starts reading configuration
887 # files, unless the file exists. If the file already exists, it will be truncated. Once
888 # keepalived has completed reading the files it will remove the reload file.
889 # If reload_file with no file name is specified, the default filename keepalived.reload
890 # in the PID directory will be used.
891 # The best way to use the reload file is for the configuration update process to touch
892 # the reload file before it signals keepalived to reload, and then wait for the file
893 # to be deleted, which indicates that keepalived has finished reading the config files.
894 # When keepalived starts reading the configuration files, since it truncates the reload
895 # file, if update process creates the reload_file with non-zero size, it can detect
896 # the reloading starting by the reload_file becoming zero length.
897 reload_file [ABSOLUTE-PATHNAME-OF-FILE]
898
899 # Sending SIGUSR1 to keepalived causes it to dump its data structures
900 # for debugging purposes, although some users use this feature and
901 # process the output. Please note that the format of the .data files
902 # produced is not guaranteed to maintain backward compatibility.
903 # The standard file names are keepalived_parent.data, keepalived.data,
904 # keepalived_check.data and keepalived_bfd.data. This causes a problem
905 # if more than one keepalived instance is running on a system.
906 # In order to alleviate this, enabling data_use_instance includes the
907 # instance name and network namespace in the file name of the .data files.
908 data_use_instance [<BOOL>]
909
910 # json_version 2 puts the VRRP data in a named array and adds
911 # track_process details. Default is version 1.
912 json_version {1|2}
913 }
914
916 The linkbeat_interfaces block allows specifying which interfaces should
917 use polling via MII, Ethtool or ioctl status rather than rely on
918 netlink status updates. This allows more granular control of global
919 definition linkbeat_use_polling.
920
921 This option is preferred over the deprecated use of
922 linkbeat_use_polling in a vrrp_instance block, since the latter only
923 allows using linkbeat on the interface of the vrrp_instance itself,
924 whereas track_interface and virtual_ipaddresses and virtual_iproutes
925 may require monitoring other interfaces, which may need to use linkbeat
926 polling.
927
928 The default polling type to use is MII, unless that isn't supported in
929 which case ETHTOOL is used, and if that isn't supported then ioctl
930 polling. The preferred type of polling to use can be specified with MII
931 or ETHTOOL or IOCTL after the interface name, but if that type isn't
932 supported, a supported type will be used.
933
934 The syntax for linkbeat_interfaces is:
935 linkbeat_interfaces {
936 eth2
937 enp2s0 ETHTOOL
938 }
939
941 Static track groups are used to allow vrrp instances to track static
942 addresses, routes and rules. If a static address/route/rule specifies a
943 track group, then if the address/route/rule is deleted and cannot be
944 restored, the vrrp instance will transition to fault state.
945
946 The syntax for a track group is:
947 track_group GROUP1 {
948 group {
949 VI_1
950 VI_2
951 }
952 }
953
955 Keepalived can configure static addresses, routes, and rules. These ad‐
956 dresses, routes and rules are NOT moved by vrrpd, they stay on the ma‐
957 chine. If you already have IPs and routes on your machines and your
958 machines can ping each other, you don't need this section. The syntax
959 for rules and routes is the same as for ip rule add/ip route add (ex‐
960 cept shortened option names are not supported due to ambiguities). The
961 track_group specification refers to a named track_group which lists the
962 vrrp instances which will track the address, i.e. if the address is
963 deleted the vrrp instances will transition to backup.
964
965 NOTE: since rules without preferences can be added in different orders
966 due to vrrp instances transitioning from master to backup etc, rules
967 need to have a preference. If a preference is not specified, keepalived
968 will assign one, but it will probably not be what you want.
969
970 The syntax is the same for virtual addresses and virtual routes. If no
971 dev element is specified, it defaults to default_interface (default
972 eth0). Note: the broadcast address may be specified as '-' or '+' to
973 clear or set the host bits of the address.
974
975 If a route or rule could apply to either IPv4 or IPv6 it will default
976 to IPv4. To force a route/rule to be IPv6, add the keyword "inet6".
977
978 By default keepalived prepends routes (the kernel's default) which adds
979 the route before any matching routes (this is the same behaviour as the
980 (undocumented) as the 'ip route add' command, which only adds the route
981 if there is no matching route. If 'append' is specified, the behaviour
982 is the same as the 'ip route append' command, i.e. the route is added
983 after any matching route. Note: the rules for whether a route matches
984 differ between IPv4 and IPv6; for example specifying a different proto
985 means a matching route can be prepended/appended for IPv4 but not for
986 IPv6. If in doubt, test it using the 'ip route add/prepend/append' com‐
987 mands.
988
989 static_ipaddress {
990 <IPADDR>[/<MASK>] [brd <IPADDR>] [dev <STRING>] [scope <SCOPE>]
991 [label <LABEL>] [peer <IPADDR>] [home]
992 [-nodad] [mngtmpaddr] [noprefixroute]
993 [autojoin] [track_group GROUP] [preferred_lft nn|forever]
994 192.168.1.1/24 dev eth0 scope global
995 ...
996 }
997
998 static_routes {
999 192.168.2.0/24 via 192.168.1.100 dev eth0 track_group GROUP1
1000
1001 192.168.100.0/24 table 6909 nexthop via 192.168.101.1 dev wlan0
1002 onlink weight 1 nexthop via 192.168.101.2
1003 dev wlan0 onlink weight 2
1004
1005 192.168.200.0/24 dev p33p1.2 table 6909 tos 0x04 protocol bird
1006 scope link priority 12 mtu 1000 hoplimit 100
1007 advmss 101 rtt 102 rttvar 103 reordering 104
1008 window 105 cwnd 106 ssthresh lock 107 realms
1009 PQA/0x14 rto_min 108 initcwnd 109 initrwnd 110
1010 vrf blue features ecn add
1011
1012 2001:470:69e9:1:2::4 dev p33p1.2 table 6909 tos 0x04 protocol
1013 bird scope link priority 12 mtu 1000
1014 hoplimit 100 advmss 101 rtt 102 rttvar 103
1015 reordering 104 window 105 cwnd 106 ssthresh
1016 lock 107 rto_min 108 initcwnd 109 append
1017 initrwnd 110 features ecn fastopen_no_cookie 1
1018 ...
1019 }
1020
1021 static_rules {
1022 from 192.168.2.0/24 table 1 track_group GROUP1
1023
1024 to 192.168.2.0/24 table 1
1025
1026 from 192.168.28.0/24 to 192.168.29.0/26 table small iif p33p1
1027 oif wlan0 tos 22 fwmark 24/12
1028 preference 39 realms 30/20 goto 40
1029
1030 to 1:2:3:4:5:6:7:0/112 from 7:6:5:4:3:2::/96 table 6908
1031 uidrange 10000-19999
1032
1033 to 1:2:3:4:6:6:7:0/112 from 8:6:5:4:3:2::/96 l3mdev protocol 12
1034 ip_proto UDP sport 10-20 dport 20-30
1035 ...
1036 }
1037
1039 Adds a file to be monitored. The file will be read whenever it is modi‐
1040 fied. The value in the file will be recorded for all VRRP instances,
1041 sync groups and real servers which monitor it. Note that the file will
1042 only be read if at least one VRRP instance, sync group or real server
1043 monitors it.
1044
1045 A value will be read as a number in text from the file. If the weight
1046 configured against the track_file is 0, a non-zero value in the file
1047 will be treated as a failure status, and a zero value will be treated
1048 as an OK status, otherwise the value will be multiplied by the weight
1049 configured in the track_file statement.
1050
1051 For VRRP instances, if the result is less than -253 anything monitoring
1052 the script will transition to the fault state (the weight can be 254 to
1053 allow for a negative value being read from the file).
1054
1055 If the vrrp instance or sync group is not the address owner and the re‐
1056 sult is between -253 and 253, the result will be added to the initial
1057 priority of the VRRP instance (a negative value will reduce the prior‐
1058 ity), although the effective priority will be limited to the range
1059 [1,254]. Likewise for real servers.
1060
1061 If a vrrp instance using a track_file is a member of a sync group, un‐
1062 less sync_group_tracking_weight is set on the group weight 0 must be
1063 set. Likewise, if the vrrp instance is the address owner, weight 0
1064 must also be set.
1065
1066 For real servers monitoring the file, the limits of values read from
1067 the track file are 2147483648 to -2147483648. The value, once multi‐
1068 plied by the weight, will be added to the real server's IPVS weight. If
1069 the result is <= than 2147483648 then the checker will be in the FAULT
1070 state.
1071
1072 NOTE: weights for track_file for real servers are not fully implemented
1073 yet. In particular allowing weight 0, handling negative calculated val‐
1074 ues and reloading.
1075
1076 The syntax for track file is:
1077
1078 track_file <STRING> { # vrrp_track_file is a deprecated synonym
1079 # file to track (weight defaults to 1)
1080 file <QUOTED_STRING>
1081
1082 # optional default weight
1083 weight <-2147483647..2147483647> [reverse]
1084
1085 # create the file and/or initialise the value
1086 # This causes VALUE (default 0) to be written to
1087 # the specified file at startup if the file doesn't
1088 # exist, unless overwrite is specified in which case
1089 # any existing file contents will be overwritten with
1090 # the specified value.
1091 init_file [VALUE] [overwrite]
1092 }
1093
1095 The configuration block looks like:
1096
1097 vrrp_track_process <STRING> {
1098 # process to monitor (with optional parameters)
1099 # A quoted string is treated as a single element, so if the first item
1100 # after the process keyword is quoted, that will be the command name.
1101 # For example:
1102 # process "/tmp/a b" param1 "param 2"
1103 # would mean a process named '/tmp/a b' (quotes removed) with 2 parameters
1104 # 'param1' and 'param 2'.
1105 process <STRING>|<QUOTED_STRING> [<STRING>|<QUOTED_STRING> ...]
1106
1107 # If matching parameters, this specifies a partial match (i.e. the first
1108 # n parameters match exactly), or an initial match, i.e. the last
1109 # parameter may be longer that the parameter configured.
1110 # To specify that a command must have no parameters, don't specify
1111 # any parameters, but specify param_match.
1112 param_match {initial|partial}
1113
1114 # default weight (default is 1). For description of reverse, see track_process.
1115 # 'weight 0 reverse' will cause the vrrp instance to be down when the
1116 # quorum is up, and vice versa.
1117 weight <-254..254> [reverse]
1118
1119 # minimum number of processes for success
1120 quorum NUM
1121
1122 # maximum number of processes for success. For example, setting
1123 # this to 1 would cause a failure if two instances of the process
1124 # were running (but beware forks - see fork_delay below).
1125 # Setting this to 0 would mean failure if the matching process were
1126 # running at all.
1127 quorum_max NUM
1128
1129 # time to delay after process quorum gained after fork before
1130 # consider process up (in fractions of second)
1131 # This is to avoid up/down bounce for fork/exec
1132 fork_delay SECS
1133
1134 # time to delay after process quorum lost before
1135 # consider process down (in fractions of second)
1136 # This is to avoid down/up bounce after terminate/parent refork.
1137 terminate_delay SECS
1138
1139 # this sets fork_delay and terminate_delay
1140 delay SECS
1141
1142 # Normally process string is matched against the process name,
1143 # as shown on the Name: line in /proc/PID/status, unless
1144 # parameters are specified.
1145 # This option forces matching the full command line
1146 full_command
1147 }
1148
1149 To avoid having to frequently run a track_script to monitor the exis‐
1150 tance of processes (often haproxy or nginx), vrrp_track_process can
1151 monitor whether other processes are running.
1152
1153 One difference from pgrep is track_process doesn't do a regular expres‐
1154 sion match of the command string, but does an exact match. 'pgrep ssh'
1155 will match an sshd process, this track_process will not (it is equiva‐
1156 lent to pgrep "^ssh$").
1157
1158 If full_command is used (equivalent to pgrep -f), /proc/PID/cmdline is
1159 used, but any updates to cmdline will not be detected (a process
1160 shouldn't normally change it, although it is possible with great care,
1161 for example systemd).
1162
1163 Prior to Linux v3.2 track_process will not support detection of changes
1164 to a process name, since the kernel did not notify changes of process
1165 name prior to 3.2. Most processes do not change their process name,
1166 but, for example, firefox forks processes that change their process
1167 name to "Web Content". The process name referred to here is the con‐
1168 tents of /proc/PID/comm.
1169
1170 Quorum is the number of matching processes that must be run for an OK
1171 status.
1172
1173 Delay might be useful if it anticipated that a process may be reloaded
1174 (stopped and restarted), and it isn't desired to down and up a vrrp in‐
1175 stance.
1176
1177 A positive weight means that an OK status will add <weight> to the pri‐
1178 ority of all VRRP instances which monitor it. On the opposite, a nega‐
1179 tive weight will be subtracted from the initial priority in case of in‐
1180 sufficient processes.
1181
1182 If the vrrp instance or sync group is not the address owner and the re‐
1183 sult is between -253 and 253, the result will be added to the initial
1184 priority of the VRRP instance (a negative value will reduce the prior‐
1185 ity), although the effective priority will be limited to the range
1186 [1,254].
1187
1188 If a vrrp instance using a track_process is a member of a sync group,
1189 unless sync_group_tracking_weight is set on the group weight 0 must be
1190 set. Likewise, if the vrrp instance is the address owner, weight 0
1191 must also be set.
1192
1193 Rational for not using pgrep/pidof/killall and the likes:
1194
1195 Every time pgrep or its equivalent is run, it iterates though the
1196 /proc/[1-9][0-9]* directories, and opens the status and cmdline pseudo
1197 files in each directory. The cmdline pseudo file is mapped to the
1198 process's address space, and so if that part of the process is swapped
1199 out, it will have to be fetched from the swap space. pgrep etc also
1200 include zombie processes whereas keepalived does not, since they aren't
1201 running.
1202
1203 This implementation only iterates though /proc/[1-9][0-9]*/ directories
1204 at start up, and it won't even read the cmdline pseudo files if
1205 'full_command' is not specified for any of the vrrp_track_process en‐
1206 tries. After startup, it uses the process_events kernel <-> userspace
1207 connector to receive notification of process changes. If full_command
1208 is specified for any track_process instance, the cmdline pseudo file
1209 will have to be read upon notification of the creation of the new
1210 process, but at that time it is very unlikely that it will have already
1211 been swapped out.
1212
1213 On a busy system with a high number of process creations/terminations,
1214 using a track_script with pgrep/pidof/killall may be more efficient,
1215 although those processes are inefficient compared to the minimum that
1216 keepalived needs.
1217
1218 Using pgrep etc on a system that is swapping can have a significant
1219 detrimental impact on the performance of the system, due to having to
1220 fetch swapped memory from the swap space, thereby causing additional
1221 swapping.
1222
1224 This is an implementation of RFC5880 (Bidirectional forwarding detec‐
1225 tion), and this can be configured to work between 2 keepalived in‐
1226 stances, but using unweighted track_bfds between a master/backup pair
1227 of VRRP instances means that the VRRP instance will only be able to
1228 come up if both VRRP instance are running, which somewhat defeats the
1229 purpose of VRRP.
1230
1231 This implementation has been tested with OpenBFDD (available at
1232 https://github.com/dyninc/OpenBFDD).
1233
1234 The syntax for bfd instance is :
1235
1236 bfd_instance <STRING> {
1237 # BFD Neighbor IP (synonym neighbour_ip)
1238 neighbor_ip <IP ADDRESS>
1239
1240 # Source IP to use (optional, except in order to ensure that the
1241 # local port is valid, it is required)
1242 source_ip <IP ADDRESS>
1243
1244 # Required min RX interval, in ms (resolution is micro-seconds e.g. 3.312)
1245 # (default is 10 ms)
1246 min_rx <DECIMAL>
1247
1248 # Desired min TX interval, in ms (resolution is micro-seconds)
1249 # (default is 10 ms)
1250 min_tx <DECIMAL>
1251
1252 # Desired idle TX interval, in ms (resolution is micro-seconds)
1253 # (default is 1000 ms)
1254 idle_tx <DECIMAL>
1255
1256 # Number of missed packets after
1257 # which the session is declared down
1258 # (default is 5)
1259 multiplier <INTEGER>
1260
1261 # Operate in passive mode (default is active)
1262 passive
1263
1264 # outgoing IPv4 ttl to use (default 255)
1265 ttl <INTEGER>
1266
1267 # outgoing IPv6 hoplimit to use (default 64)
1268 hoplimit <INTEGER>
1269
1270 # maximum reduction of ttl/hoplimit
1271 # in received packet (default 0)
1272 # (255 disables hop count checking)
1273 max_hops <INTEGER>
1274
1275 # RFC 5883 specifies port 4784 must be used for multihop bfd, rather than
1276 # port 3784. Specifying multihop enables that option, but if multiple hops
1277 # are in use, then max_hops (see above) will also need to be configured.
1278 multihop [<BOOL>]
1279
1280 # Default tracking weight
1281 # Normally, positive weights are added to the vrrp instance priority when
1282 # the bfd instance is up, negative weights reduce the priority when it is down.
1283 # However, if reverse is specified, the priority is decreased when up and
1284 # increased when down. 'weight 0 reverse' will cause the vrrp instance to be down
1285 # when the bfd instance is up, and vice versa.
1286 weight <-253:253> [reverse]
1287
1288 # Normally bfd event notifications are sent to both the VRRP and checker processes.
1289 # Specifying vrrp or checker will cause event notifications for this bfd_instance
1290 # only to be sent to the specified process
1291 vrrp
1292 checker
1293 }
1294
1296 contains subblocks of VRRP script(s), VRRP synchronization group(s),
1297 VRRP gratuitous ARP and unsolicited neighbour advert delay group(s) and
1298 VRRP instance(s)
1299
1301 The script will be executed periodically, every <interval> seconds. Its
1302 exit code will be recorded for all VRRP instances which monitor it.
1303 Note that the script will only be executed if at least one VRRP in‐
1304 stance monitors it.
1305
1306 The default weight equals 0, which means that any VRRP instance moni‐
1307 toring the script will transition to the fault state after <fall> con‐
1308 secutive failures of the script. After that, <rise> consecutive suc‐
1309 cesses will cause VRRP instances to leave the fault state, unless they
1310 are also in the fault state due to other scripts or interfaces that
1311 they are tracking.
1312
1313 A positive weight means that <rise> successes will add <weight> to the
1314 priority of all VRRP instances which monitor it. On the opposite, a
1315 negative weight will be subtracted from the initial priority in case of
1316 <fall> failures.
1317
1318 The syntax for the vrrp script is:
1319
1320 # Adds a script to be executed periodically. Its exit code will be
1321 # recorded for all VRRP instances and sync groups which are monitoring it.
1322 vrrp_script <SCRIPT_NAME> {
1323 # path of the script to execute
1324 script <STRING>|<QUOTED-STRING>
1325
1326 # seconds between script invocations, (default: 1 second)
1327 interval <INTEGER>
1328
1329 # seconds after which script is considered to have failed
1330 timeout <INTEGER>
1331
1332 # adjust priority by this weight, (default: 0)
1333 # For description of reverse, see track_script.
1334 # 'weight 0 reverse' will cause the vrrp instance to be down when the
1335 # script is up, and vice versa.
1336 weight <INTEGER:-253..253> [reverse]
1337
1338 # required number of successes for OK transition
1339 rise <INTEGER>
1340
1341 # required number of successes for KO transition
1342 fall <INTEGER>
1343
1344 # user/group names to run script under.
1345 # group default to group of user
1346 user USERNAME [GROUPNAME]
1347
1348 # assume script initially is in failed state
1349 init_fail
1350 }
1351
1353 VRRP Sync Group is an extension to VRRP protocol. The main goal is to
1354 define a bundle of VRRP instance to get synchronized together so that
1355 transition of one instance will be reflected to others group members.
1356
1357 In addition there is an enhanced notify feature for fine state transi‐
1358 tion catching.
1359
1360 You can also define multiple track policy in order to force state tran‐
1361 sition according to a third party event such as interface, scripts,
1362 file, BFD.
1363
1364 Important: for a SYNC group to run reliably, it is vital that all in‐
1365 stances in the group are MASTER or that they are all either BACKUP or
1366 FAULT. A situation where some instances have higher priority on machine
1367 A and others have higher priority on machine B will lead to constant
1368 re-elections. For this reason, when instances are grouped, any track
1369 scripts/files configured against member VRRP instances must have their
1370 tracking weights unset (i.e. equal to zero). Any trackers with a non-
1371 zero priority will be ignored.
1372
1373 The syntax for vrrp_sync_group is :
1374
1375 vrrp_sync_group <STRING> {
1376 group {
1377 # name of the vrrp_instance (see below)
1378 # Set of VRRP_Instance string
1379 <STRING>
1380 <STRING>
1381 ...
1382 }
1383
1384 # Synchronization group tracking interface, script, file & bfd will
1385 # update the status/priority of all VRRP instances which are members
1386 # of the sync group.
1387 # 'weight 0 reverse' will cause the vrrp instance to be down when the
1388 # interface is up, and vice versa.
1389 track_interface {
1390 eth0
1391 eth1
1392 eth2 weight <-253..253> [reverse]
1393 ...
1394 }
1395
1396 # add a tracking script to the sync group (<SCRIPT_NAME> is the name
1397 # of the vrrp_script entry) go to FAULT state if any of these go down
1398 # if unweighted.
1399 # reverse causes the direction of the adjustment of the priority to be reversed.
1400 track_script {
1401 <SCRIPT_NAME>
1402 <SCRIPT_NAME> weight <-253..253> [reverse|noreverse]
1403 }
1404
1405 # Files whose state we monitor, value is added to effective priority.
1406 # <STRING> is the name of a track_file
1407 # weight defaults to weight configured in track_file
1408 track_file {
1409 <STRING>
1410 <STRING> weight <-254..254> [reverse|noreverse]
1411 ...
1412 }
1413
1414 # Process to monitor, weight is added to effective priority.
1415 # <STRING> is the name of a vrrp_track_process
1416 # weight defaults to weight configured in vrrp_track_process.
1417 # See vrrp_instance track_process for description of weight.
1418 track_process {
1419 <STRING>
1420 <STRING> weight <-254..254> [reverse|noreverse]
1421 ...
1422 }
1423
1424 # BFD instances we monitor, value is added to effective priority.
1425 # <STRING> is the name of a BFD instance
1426 track_bfd {
1427 <STRING>
1428 <STRING>
1429 <STRING> weight <INTEGER: -253..253> [reverse|noreverse]
1430 ...
1431 }
1432
1433 # notify scripts and alerts are optional
1434 #
1435 # filenames of scripts to run on transitions can be unquoted (if
1436 # just filename) or quoted (if it has parameters)
1437 # The username and groupname specify the user and group
1438 # under which the scripts should be run. If username is
1439 # specified, the group defaults to the group of the user.
1440 # If username is not specified, they default to the
1441 # global script_user and script_group
1442
1443 # to MASTER transition
1444 notify_master /path/to_master.sh [username [groupname]]
1445
1446 # to BACKUP transition
1447 notify_backup /path/to_backup.sh [username [groupname]]
1448
1449 # FAULT transition
1450 notify_fault "/path/fault.sh VG_1" [username [groupname]]
1451
1452 # executed when stopping vrrp
1453 notify_stop <STRING>|<QUOTED-STRING> [username [groupname]]
1454
1455 # notify_deleted causes DELETED to be sent to notifies rather
1456 # than the default FAULT after a vrrp instance is deleted during a
1457 # reload. If a script is specified, that script will be executed
1458 # as well.
1459 notify_deleted [<STRING>|<QUOTED-STRING> [username [groupname]]]
1460
1461 # for ANY state transition.
1462 # "notify" script is called AFTER the notify_* script(s) and
1463 # is executed with 4 additional arguments after the configured
1464 # arguments provided by Keepalived:
1465 # $(n-3) = "GROUP"|"INSTANCE"
1466 # $(n-2) = name of the group or instance
1467 # $(n-1) = target state of transition (stop only applies to instances)
1468 # ("MASTER"|"BACKUP"|"FAULT"|"STOP"|"DELETED")
1469 # $(n) = priority value
1470 # $(n-3) and $(n-1) are ALWAYS sent in uppercase, and the possible
1471 # strings sent are the same ones listed above
1472 # ("GROUP"/"INSTANCE", "MASTER"/"BACKUP"/"FAULT"/"STOP"/"DELETED")
1473 # (note: DELETED is only applicable to instances)
1474 notify <STRING>|<QUOTED-STRING> [username [groupname]]
1475
1476 # The notify fifo output is the same as the last 4 parameters for the "notify"
1477 # script, with the addition of "MASTER_RX_LOWER_PRI" instead of state for an
1478 # instance, and also "MASTER_PRIORITY" and "BACKUP_PRIORITY" if the priority
1479 # changes and notify_priority_changes is configured.
1480 # MASTER_RX_LOWER_PRI is used if a master needs to set some external state, such
1481 # as setting a secondary IP address when using Amazon AWS; if another keepalived
1482 # has transitioned to master due to a communications break, the lower priority
1483 # instance will have taken over the secondary IP address, and the proper master
1484 # needs to be able to restore it.
1485
1486 # Send FIFO notifies for vrrp priority changes
1487 notify_priority_changes <BOOL>
1488
1489 # Send email notification during state transition,
1490 # using addresses in global_defs above (default no,
1491 # unless global smtp_alert/smtp_alert_vrrp set)
1492 smtp_alert <BOOL>
1493
1494 # DEPRECATED. Use track_interface, track_script and
1495 # track_file on vrrp_sync_groups instead.
1496 global_tracking
1497
1498 # allow sync groups to use differing weights.
1499 # This probably WON'T WORK, but is a replacement for
1500 # global_tracking in case different weights were used
1501 # across different vrrp instances in the same sync group.
1502 sync_group_tracking_weight
1503 }
1504
1506 specifies the setting of delays between sending gratuitous ARPs and un‐
1507 solicited neighbour advertisements. This is intended for when an up‐
1508 stream switch is unable to handle being flooded with ARPs/NAs.
1509
1510 Use interface when the limits apply on the single physical interface.
1511 Use interfaces when a group of interfaces are linked to the same switch
1512 and the limits apply to the switch as a whole.
1513
1514 Note: Only one of interface or interfaces should be used per block.
1515
1516 If the global vrrp_garp_interval and/or vrrp_gna_interval are set, any
1517 interfaces that aren't specified in a garp_group will inherit the
1518 global settings.
1519
1520 The syntax for garp_group is :
1521
1522 garp_group {
1523 # Sets the interval between Gratuitous ARP (in seconds, resolution microseconds)
1524 garp_interval <DECIMAL>
1525
1526 # Sets the default interval between unsolicited NA (in seconds, resolution microseconds)
1527 gna_interval <DECIMAL>
1528
1529 # The physical interface to which the intervals apply
1530 interface <STRING>
1531
1532 # A list of interfaces across which the delays are aggregated.
1533 interfaces {
1534 <STRING>
1535 <STRING>
1536 ...
1537 }
1538 }
1539
1541 A VRRP Instance is the VRRP protocol key feature. It defines and con‐
1542 figures VRRP behaviour to run on a specific interface. Each VRRP In‐
1543 stance is related to a unique interface.
1544
1545 The syntax for vrrp_instance is :
1546
1547 vrrp_instance <STRING> {
1548 # Initial state, MASTER|BACKUP
1549 # If the priority is 255, then the instance will transition immediately
1550 # to MASTER if state MASTER is specified; otherwise the instance will
1551 # wait between 3 and 4 advert intervals before it can transition,
1552 # depending on the priority.
1553 state MASTER
1554
1555 # interface for inside_network, bound by vrrp.
1556 # Note: if using unicasting, the interface can be omitted as long
1557 # as the unicast addresses are not IPv6 link local addresses (this is
1558 # necessary, for example, if using asymmetric routing).
1559 # If the interface is omitted, then all VIPs and eVIPs should specify
1560 # the interface they are to be configured on, otherwise they will be
1561 # added to the default interface.
1562 interface eth0
1563
1564 # If using unicasting without specifying an interface, the VRF to operate
1565 # in can be specified.
1566 vrf VRF_IF
1567
1568 # Use VRRP Virtual MAC (macvlan).
1569 # The macvlan will be created on the configured interface for
1570 # the VRRP instance, and the VIPs, and eVIPs of the matching address
1571 # family, which do not specify a different interface will be configured
1572 # on the macvlan.
1573 # The VRRP adverts will also be sent and received on the macvlan
1574 # interface, unless vmac_xmit_base is configured.
1575 # NOTE: If sysctl net.ipv4.conf.all.rp_filter is set,
1576 # and this vrrp_instance is an IPv4 instance, using
1577 # this option will cause the individual interfaces to be
1578 # updated to the greater of their current setting, and
1579 # all.rp_filter, as will default.rp_filter, and all.rp_filter
1580 # will be set to 0.
1581 # The original settings are restored on termination.
1582 # NOTE 2: If using use_vmac with unicast peers,
1583 # vmac_xmit_base must be set.
1584 # The MAC address can be specified with only 5 octets, in which case
1585 # the virtual_router_id will be used as the last octet.
1586 use_vmac [<VMAC_INTERFACE_NAME>] [MAC_ADDRESS]
1587
1588 # use_vmac_addr is used to create VMAC (macvlan) interfaces for
1589 # each interface that is used by a VIP or eVIP where the interface
1590 # is not the same as the interface on which the VRRP instance is
1591 # configured or the eVIP's address family does not match the VRRP
1592 # instance's. Alternatively, use_vmac can be specified against each
1593 # VIP/eVIP that specifies an interface (dev).
1594 # NOTE: if use_vmac is specfied and an eVIP is not the same address
1595 # family as the vrrp instance, unless use_vmac_addr is specified, or
1596 # use_vmac is specified for the eVIP, the eVIP will be configured on
1597 # the vrrp instance's VMAC, which will have the wrong MAC address for
1598 # the address family of the eVIP.
1599 use_vmac_addr
1600
1601 # Send/Recv VRRP messages from base interface instead of
1602 # VMAC interface
1603 vmac_xmit_base
1604
1605 # Use IPVLAN interface. keepalived will create a mode L2
1606 # ipvlan interface on top of the specified interface.
1607 # For IPv4 instances, an IP address is required, for IPv6
1608 # the address is optional, in which case the link local
1609 # address will be used.
1610 # The mode flags default to bridge. NOTE: the mode flags must be the
1611 # same for all ipvlans on the same underlying interface.
1612 # It is safer to configure an interface name, in case keepalived crashes
1613 # and restarts, in which case it can more reliably find a previously
1614 # created interface.
1615 use_ipvlan [<INTERFACE_NAME>] [IP_ADDRESS] [bridge|private|vepa]
1616
1617 # force instance to use IPv6 (this option is deprecated since
1618 # the virtual ip addresses determine whether IPv4 or IPv6 is used).
1619 native_ipv6
1620
1621 # Ignore VRRP interface faults (default unset).
1622 # Note: when using IPv6, setting the interface administratively down, e.g.
1623 # 'ip link set IF down' will by default cause all IPv6 addresses to be
1624 # deleted from the interface, and consequently the VRRP instance will
1625 # go to fault state due to the addresses being deleted. Setting sysctl
1626 # net.ipv6.conf.IF.keep_addr_on_down to 1 will allow non link-local addresses
1627 # to remain when the interface is downed.
1628 dont_track_primary
1629
1630 # optional, monitor these as well.
1631 # go to FAULT state if any of these go down if unweighted.
1632 # When a weight is specified in track_interface, instead of setting the vrrp
1633 # instance to the FAULT state in case of failure, its priority will be
1634 # increased by the weight when the interface is up (for positive weights),
1635 # or decreased by the weight's absolute value when the interface is down
1636 # (for negative weights), unless reverse is specified, in which case the
1637 # direction of adjustment of the priority is reversed.
1638 # The weight must be comprised between -253 and +253 inclusive.
1639 # 0 is the default behaviour which means that a failure implies a
1640 # FAULT state. The common practice is to use positive weights to count a
1641 # limited number of good services so that the server with the highest count
1642 # becomes master. Negative weights are better to count unexpected failures
1643 # among a high number of interfaces, as it will not saturate even with high
1644 # number of interfaces. Use reverse to increase priority if an interfaces is down
1645 track_interface {
1646 eth0
1647 eth1
1648 eth2 weight <-253..253> [reverse]
1649 ...
1650 }
1651
1652 # add a tracking script to the interface
1653 # (<SCRIPT_NAME> is the name of the vrrp_track_script entry)
1654 # The same principle as track_interface can be applied to track_script entries,
1655 # except that an unspecified weight means that the default weight declared in
1656 # the script will be used (which itself defaults to 0).
1657 # reverse causes the direction of the adjustment of the priority to be reversed.
1658 track_script {
1659 <SCRIPT_NAME>
1660 <SCRIPT_NAME> weight <-253..253> [reverse|no_reverse]
1661 }
1662
1663 # Files whose state we monitor, value is added to effective priority.
1664 # <STRING> is the name of a track_file
1665 track_file {
1666 <STRING>
1667 <STRING>
1668 <STRING> weight <-254..254> [reverse|noreverse]
1669 ...
1670 }
1671
1672 # Positive weights are added/subtracted when the process is running,
1673 # negative weights are subtracted/added when the not running.
1674 # If reverse is specified, the addition/subtraction is reversed.
1675 # <STRING> is the name of a vrrp_track_process
1676 # weight defaults to weight configured in vrrp_track_process
1677 track_process {
1678 <STRING>
1679 <STRING> weight <-254..254> [reverse|noreverse]
1680 ...
1681 }
1682
1683 # BFD instances we monitor, value is added to effective priority,
1684 # unless reverse is specified, when the value is subtracted.
1685 # Positive weights are add/subtracted when the bfd instance is up,
1686 # negative weights are subtracted/added when the bfd instance is down.
1687 # <STRING> is the name of a BFD instance
1688 track_bfd {
1689 <STRING>
1690 <STRING>
1691 <STRING> weight <INTEGER: -253..253> [reverse|noreverse]
1692 ...
1693 }
1694
1695 # default IP for binding vrrpd is the primary IP
1696 # on interface. If you want to hide the location of vrrpd,
1697 # use this IP as src_addr for multicast or unicast vrrp
1698 # packets. (since it's multicast, vrrpd will get the reply
1699 # packet no matter what src_addr is used).
1700 # optional
1701 mcast_src_ip <IPADDR>
1702 unicast_src_ip <IPADDR>
1703
1704 # specify an alternative multicast address to use as the destination
1705 # of VRRP adverts and for listening for adverts. Note, if you are using
1706 # multiple VRRP instances with VMACs and different multicast addresses
1707 # and the same VRID, you will have to specify alternative MAC addresses
1708 # for at least all but one of the VMACs.
1709 # IPv6 multicast addresses must be link-local, i.e. start ffX2:
1710 # Using different multicast addresses with IPv6 on the same interface without
1711 # using VMACs is only supported if the kernel supports IPV6_MULTICAST_ALL
1712 # (from Linux v4.20).
1713 mcast_dst_ip <MULTICAST_IPADDR>
1714
1715 # if the configured src_ip doesn't exist or is removed put the
1716 # instance into fault state
1717 track_src_ip
1718
1719 # VRRP version to run on interface
1720 # default is global parameter vrrp_version, but IPv6 instances will
1721 # always use version 3.
1722 version <2 or 3>
1723
1724 # The following enables checking that when in unicast mode, the
1725 # source address of a VRRP packet is one of our unicast peers.
1726 check_unicast_src
1727
1728 # Do not send VRRP adverts over a VRRP multicast group.
1729 # Instead it sends adverts to the following list of
1730 # ip addresses using unicast. It can be cool to use
1731 # the VRRP FSM and features in a networking
1732 # environment where multicast is not supported!
1733 # IP addresses specified can be IPv4 as well as IPv6.
1734 # If min_ttl and/or max_ttl are specified, the TTL/hop limit
1735 # of any received packet is checked against the specified
1736 # TTL range, and is discarded if it is outside the range.
1737 # Specifying min_ttl or max_ttl turns on check_unicast_src.
1738 unicast_peer {
1739 <IPADDR> [min_ttl {0..255}] [max_ttl {0..255}]
1740 ...
1741 }
1742
1743 # It is not possible to operate in unicast mode without any peers.
1744 # Until v2.2.4 keepalived would silently operate in multicast mode
1745 # if no peers were specified but a unicast keyword had been specified.
1746 # Using this keywork stops defaulting to multicast if no peers are
1747 # specified and puts the VRRP instance into fault state.
1748 unicast_fault_no_peer
1749
1750 # Specify the unicast TTL/HLIM for sending unicast adverts
1751 unicast_ttl {0..255}
1752
1753 # The checksum calculation when using VRRPv3 changed after v1.3.6.
1754 # The reason for the change is that keepalived was calculating the
1755 # checksum using the multicast address even when it was using
1756 # unicast, whereas the checksum should be calculated using the
1757 # actual address that is in the IPv4 header.
1758 # Setting this flag forces the old checksum algorithm to be used
1759 # to maintain backward compatibility, although keepalived will
1760 # attempt to maintain compatibility anyway if it sees an old
1761 # version checksum. Specifying never will turn off auto detection
1762 # of old checksums. [This option may not be enabled - check output
1763 # of `keepalived -v` for OLD_CHKSUM_COMPAT.]
1764 old_unicast_checksum [never]
1765
1766 # Some manufacturers (e.g. Cisco) interpret RFC5798 5.2.8 as applying
1767 # only to IPv6, since the pseudo-header in RFC2460 is specified only
1768 # for IPv6. Keepalived by default uses a pseudo-header for VRRPv3 IPv4
1769 # as well. Setting this option turns off including the pseudo-header
1770 # in the checksum calculation for VRRPv3 IPv4.
1771 v3_checksum_as_v2 [<BOOL>]
1772
1773 # interface specific settings, same as global parameters.
1774 # default to global parameters
1775 garp_master_delay 10
1776 garp_master_repeat 1
1777 garp_lower_prio_delay 10
1778 garp_lower_prio_repeat 1
1779 garp_master_refresh 60
1780 garp_master_refresh_repeat 2
1781 garp_extra_if [all] 100 # specifying 0 disables feature
1782
1783 # The VRRP RFCs state that the master down timer is 3 advert intervals plus
1784 # a skew time. Setting down_timer_adverts means the master down timer will be
1785 # down_timer_adverts advert intervals.
1786 # The default is 3, to conform with the VRRP RFCs. Setting this to any other
1787 # value is a deviation from the VRRP protocol. All virtual routers for a given
1788 # VRRP instance MUST use the same value.
1789 down_timer_adverts [1-100]
1790
1791 # Some users experience "thread_timer_expired" log messages. These are caused
1792 # by the kernel not scheduling keepalived quickly enough after a timer expired,
1793 # which is always due to insufficient CPU resources being available (if running
1794 # keepalived in a VM it could be due to the VM itself not being scheduled), or
1795 # keepalived not being run at a high enough priority (see realtime scheduling
1796 # options above).
1797 # If nopreempt is configured and another instance has become master, then there
1798 # are circumstances where this instance is required not to resume as master, but
1799 # rather transition to backup.
1800 # If using this option (and nopreempt is configured), keepalived will calculate
1801 # whether another instance may have taken over (based on the advert interval and
1802 # the highest priority of the other instances - default 254 unless specified with
1803 # this option), and if that time has expired since the last advert has been sent,
1804 # the VRRP instance will revert to backup state (remember to include and track_script
1805 # etc. weights when calculating the highest priority of other instances).
1806 thread_timer_expired [HIGHEST_PRIORITY_OF_OTHER_INSTANCES]
1807
1808 # If keepalived is late running by more than 2 advert intervals for a VRRP instance,
1809 # it is possible that another instance has taken over as master.
1810 # If a lower priority advert is received, don't send another advert.
1811 # This causes adherence to the RFCs (defaults to global
1812 # vrrp_lower_priority_dont_send_advert).
1813 lower_prio_no_advert [<BOOL>]
1814
1815 # If we are master and receive a higher priority advert, send an advert
1816 # (which will be lower priority than the other master), before we transition
1817 # to backup. This means that if the other master has garp_lower_prio_repeat
1818 # set, it will resend garp messages. This is to get around the problem of
1819 # their having been two simultaneous masters, and the last GARP
1820 # messages seen were from us.
1821 higher_prio_send_advert [<BOOL>]
1822
1823 # arbitrary unique number from 1 to 255
1824 # used to differentiate multiple instances of vrrpd
1825 # running on the same network interface and address
1826 # family and multicast/unicast (and hence same socket).
1827 # Note: using the same virtual_router_id with the same
1828 # address family on different interfaces has been known
1829 # to cause problems with some network switches; if you
1830 # are experiencing problems with using the same
1831 # virtual_router_id on different interfaces, but the problems
1832 # are resolved by not duplicating virtual_router_ids, your
1833 # network switches are probably not functioning correctly.
1834 #
1835 # Whilst in general it is important not to duplicate a
1836 # virtual_router_id on the same network interface, there is a
1837 # special case when using unicasting if the unicast peers for
1838 # the vrrp instances with duplicated virtual_router_ids on the
1839 # network interface do not overlap, in which case virtual_router_ids
1840 # can be duplicated.
1841 # It is also possible to duplicate virtual_router_ids on an
1842 # interface with multicasting if different multicast addresses
1843 # are used (see mcast_dst_ip).
1844 virtual_router_id 51
1845
1846 # for electing MASTER, highest priority wins.
1847 # The valid range of values for priority is [1-255], with priority
1848 # 255 meaning "address owner".
1849 # To be MASTER, it is recommended to make this 50 more than on
1850 # other machines. All systems should have different priorities
1851 # in order to make behaviour deterministic. If you want to stop
1852 # a higher priority instance taking over as master when it starts,
1853 # configure no_preempt rather than using equal priorities.
1854 # If no_accept is configured (or vrrp_strict # which also sets
1855 # no_accept mode), then unless the vrrp_instance has priority 255,
1856 # the system will not receive packets addressed to the # VIPs/eVIPs,
1857 # and the VIPs/eVIPs can only be used for routeing purposes.
1858 # Further, if an instance has priority 255 configured, the priority cannot
1859 # be reduced by track_scripts, track_process etc, and likewise
1860 # track_scripts etc cannot increase the priority to 255 if the configured
1861 # priority is not 255.
1862 priority 100
1863
1864 # VRRP Advert interval in seconds (e.g. 0.92) (use default)
1865 advert_int 1
1866
1867 # Note: authentication was removed from the VRRPv2 specification by
1868 # RFC3768 in 2004.
1869 # Use of this option is non-compliant and can cause problems; avoid
1870 # using if possible, except when using unicast, where it can be helpful.
1871 authentication {
1872 # PASS|AH
1873 # PASS - Simple password (suggested)
1874 # AH - IPSEC (not recommended))
1875 auth_type PASS
1876
1877 # Password for accessing vrrpd.
1878 # should be the same on all machines.
1879 # Only the first eight (8) characters are used.
1880 auth_pass 1234
1881 }
1882
1883 # addresses add|del on change to MASTER, to BACKUP.
1884 # With the same entries on other machines,
1885 # the opposite transition will be occurring.
1886 # For virtual_ipaddress, virtual_ipaddress_excluded,
1887 # virtual_routes and virtual_rules most of the options
1888 # match the options of the command ip address/route/rule add.
1889 # The track_group option only applies to static addresses/routes/rules.
1890 # no_track is specific to keepalived and means that the
1891 # vrrp_instance will not transition out of master state
1892 # if the address/route/rule is deleted and the address/route/rule
1893 # will not be reinstated until the vrrp instance next transitions
1894 # to master.
1895 # <LABEL>: is optional and creates a name for the alias.
1896 For compatibility with "ifconfig", it should
1897 be of the form <realdev>:<anytext>, for example
1898 eth0:1 for an alias on eth0.
1899 # <SCOPE>: ("site"|"link"|"host"|"nowhere"|"global")
1900 # preferred_lft is set to 0 to deprecate IPv6 addresses (this is the
1901 # default if the address mask is /128). Use "preferred_lft forever"
1902 # to specify that a /128 address should not be deprecated.
1903 # NOTE: care needs to be taken if dev is specified for an address and
1904 # your network uses MAC learning switches. The VRRP protocol ensures
1905 # that the source MAC address of the interface sending adverts is
1906 # maintained in the MAC cache of switches; however by default this
1907 # will not work for the MACs of any VIPs/eVIPs that are configured on
1908 # different interfaces from the interface on which the VRRP instance is
1909 # configured, since the interface, especially if it is a VMAC interface,
1910 # will only send using the MAC address of the interface in response to
1911 # ARP requests. This may mean that the interface MAC addresses may
1912 # time out in the MAC caches of switches. In order to avoid this, use
1913 # the garp_extra_if or garp_extra_if_vmac options to send periodic
1914 # GARP/ND messages on those interfaces.
1915 virtual_ipaddress {
1916 <IPADDR>[/<MASK>] [brd <IPADDR>] [dev <STRING>] [use_vmac] [scope <SCOPE>]
1917 [label <LABEL>] [peer <IPADDR>] [home]
1918 [-nodad] [mngtmpaddr] [noprefixroute]
1919 [autojoin] [no_track] [preferred_lft nn|forever]
1920 192.168.200.17/24 dev eth1
1921 192.168.200.18/24 dev eth2 label eth2:1
1922 }
1923
1924 # VRRP IP excluded from VRRP optional.
1925 # For cases with large numbers (eg 200) of IPs
1926 # on the same interface. To decrease the number
1927 # of addresses sent in adverts, you can exclude
1928 # most IPs from adverts.
1929 # The IPs are add|del as for virtual_ipaddress.
1930 # Can also be used if you want to be able to add
1931 # a mixture of IPv4 and IPv6 addresses, since all
1932 # addresses in virtual_ipaddress must be of the
1933 # same family.
1934 virtual_ipaddress_excluded {
1935 <IPADDR>[/<MASK>] [brd <IPADDR>] [dev <STRING>] [scope <SCOPE>]
1936 [label <LABEL>] [peer <IPADDR>] [home]
1937 [-nodad] [mngtmpaddr] [noprefixroute]
1938 [autojoin] [no_track]
1939 <IPADDR>[/<MASK>] ...
1940 ...
1941 }
1942
1943 # Specifying no virtual IP addresses is generally a configuration error
1944 # and VRRP version 3 explicitly states that the minimum number of addresses
1945 # is 1. Consequently keepalived warns if no VIPs are configured.
1946 # There are, however, circumstances when it is useful to have no VIPs, for
1947 # example when cloud servers, e.g. AWS, where floating IP addresses are
1948 # managed administratively, and are not configured on the cloud virtual
1949 # server. Specifying no_virtual_ipaddress supresses warnings for no VIPs,
1950 # and allows VRRPv3 to be used with no VIPs.
1951 # WARNING - when using this with VRRPv3 it causes a protocol violation and
1952 # may not work with other VRRP implementations.
1953 no_virtual_ipaddress
1954
1955 # Set the promote_secondaries flag on the interface to stop other
1956 # addresses in the same CIDR being removed when 1 of them is removed
1957 # For example if 10.1.1.2/24 and 10.1.1.3/24 are both configured on an
1958 # interface, and one is removed, unless promote_secondaries is set on
1959 # the interface the other address will also be removed.
1960 promote_secondaries
1961
1962 # routes add|del when changing to MASTER, to BACKUP.
1963 # See static_routes for more details
1964 virtual_routes {
1965 # src <IPADDR> [to] <IPADDR>/<MASK> via|gw <IPADDR>
1966 # [or <IPADDR>] dev <STRING> scope <SCOPE> table <TABLE>
1967 src 192.168.100.1 to 192.168.109.0/24 via 192.168.200.254 dev eth1
1968 192.168.110.0/24 via 192.168.200.254 dev eth1
1969 192.168.111.0/24 dev eth2 no_track
1970 192.168.112.0/24 via 192.168.100.254
1971 192.168.113.0/24 via 192.168.200.254 or 192.168.100.254 dev eth1
1972 blackhole 192.168.114.0/24
1973 0.0.0.0/0 gw 192.168.0.1 table 100 # To set a default gateway into table 100.
1974 }
1975
1976 # rules add|del when changing to MASTER, to BACKUP
1977 # See static_rules for more details
1978 virtual_rules {
1979 from 192.168.2.0/24 table 1
1980 to 192.168.2.0/24 table 1 no_track
1981 }
1982
1983 # VRRPv3 has an Accept Mode to allow the virtual router when not the
1984 # address owner to receive packets addressed to a VIP. This is the default
1985 # setting unless strict mode is set. As an extension, this also works for
1986 # VRRPv2 (RFC 3768 doesn't define an accept mode).
1987 # --
1988 # Accept packets to non address-owner
1989 accept
1990
1991 # Drop packets to non address-owner.
1992 no_accept
1993
1994 # A higher priority VRRP instance will normally preempt a lower priority instance
1995 # when it comes online. "nopreempt" stops the higher priority machine taking
1996 # over the master role, and allows the lower priority machine to remain as
1997 # master.
1998 # NOTE: For this to work, the initial state must not be MASTER.
1999 # --
2000 nopreempt
2001
2002 # for backwards compatibility
2003 preempt
2004
2005 # Seconds of delay until preemption after getting the advertisement timeout
2006 # at startup or when seeing a lower priority master.
2007 #
2008 # Since it is a delay, it cannot speed up taking over as master.
2009 # "preempt_delay" specifies the time in seconds to delay preempting compared
2010 # to if "preempt_delay" is not specified. Advertisement timeout is
2011 # 3 * advert_int + skew_time. Skew_time is defined by RFC3768 and RFC5798.
2012 #
2013 # So if "advert_int" is 1, and priority is 128, the instance would normally
2014 # wait 3.5 seconds before taking over as master. If "preempt_delay 2" is
2015 # specified, then the delay before taking over as master would be approximately
2016 # 5.5 seconds.
2017 #
2018 # (if not disabled by "nopreempt").
2019 # Range: 0 (default) to 1000 (e.g. 4.12)
2020 # NOTE: For this to work, the initial state must not be MASTER.
2021 preempt_delay 300 # waits 5 minutes
2022
2023 # See description of global vrrp_skip_check_adv_addr, which
2024 # sets the default value. Defaults to vrrp_skip_check_adv_addr
2025 skip_check_adv_addr [on|off|true|false|yes|no]
2026
2027 # See description of global vrrp_strict
2028 # If strict_mode is not specified, it takes the value of vrrp_strict.
2029 # If strict_mode without a parameter is specified, it defaults to on.
2030 strict_mode [on|off|true|false|yes|no]
2031
2032 # Debug level, not implemented yet.
2033 # LEVEL is a number in the range 0 to 4
2034 debug <LEVEL>
2035
2036 # notify scripts, alert as above
2037 notify_master <STRING>|<QUOTED-STRING> [username [groupname]]
2038 notify_backup <STRING>|<QUOTED-STRING> [username [groupname]]
2039 notify_fault <STRING>|<QUOTED-STRING> [username [groupname]]
2040 # executed when stopping vrrp
2041 notify_stop <STRING>|<QUOTED-STRING> [username [groupname]]
2042 notify <STRING>|<QUOTED-STRING> [username [groupname]]
2043
2044 # The notify_master_rx_lower_pri script is executed if a master
2045 # receives an advert with priority lower than the master's priority.
2046 notify_master_rx_lower_pri <STRING>|<QUOTED-STRING> [username [groupname]]
2047
2048 # Send vrrp instance priority notifications on notify FIFOs.
2049 notify_priority_changes <BOOL>
2050
2051 # Send SMTP alerts
2052 smtp_alert <BOOL>
2053
2054 # Set socket receive buffer size (see global_defs
2055 # vrrp_rx_bufs_policy for explanation)
2056 kernel_rx_buf_size
2057
2058 # Set use of linkbeat for the interface of this VRRP instance. This option is
2059 # deprecated - use linkbeat_interfaces block instead.
2060 linkbeat_use_polling
2061 }
2062
2064 If an interface that is being used (or tracked) by a VRRP instance
2065 goes to down state,
2066 the VRRP instance(s) will, by default, immediately transition to
2067 FAULT state, and when
2068 all relevant interfaces are back up again the VRRP instance(s) will
2069 immediately transition
2070 to BACKUP state.
2071
2072 This can cause problems if interfaces are bouncing, and so delays
2073 can be specified
2074 between the interface state change and the transition to
2075 FAULT/BACKUP state. If the
2076 interface returns to its original state before the delay expires,
2077 no associated VRRP
2078 instance state transition will occur.
2079
2080 interface_up_down_delays {
2081 ifname down_delay [up_delay]
2082 ifname2 down_delay [up_delay]
2083 ...
2084 }
2085
2086 The delays are specified in seconds, with a resolution of microseconds, e.g. a delay of
2087 0.00001 means 10 usecs. A delay of 0 means no delay in state change. The maximum delay
2088 that can be specified is 255 seconds.
2089
2090 If up_delay is omitted, it is set to be the same as the down delay.
2091
2092 The delay on an interface must be less than two (or more precisely one less than
2093 down_timer_adverts (default 3)) times the advert interval of any VRRP instance
2094 using that interface (otherwise a backup instance, while not receiving adverts
2095 may time out and become master before this instance transitions to FAULT state).
2096 Consequently the up/down delays can be dynamically reduced if another instance is
2097 master with a shorter advert interval.
2098
2099 If the VRRP instance is using a VMAC, it will inherit the up/down debounce delays of
2100 its parent interface.
2101
2103 contains subblocks of Virtual server group(s) and Virtual server(s)
2104
2105 The subblocks contain arguments for configuring Linux IPVS (LVS) fea‐
2106 ture. Knowledge of ipvsadm(8) will be helpful here. Configuring LVS is
2107 achieved by defining virtual server groups, virtual servers and option‐
2108 ally SSL configuration. Every virtual server defines a set of real
2109 servers, you can attach healthcheckers to each real server. Keepalived
2110 will then lead LVS operation by dynamically maintaining topology.
2111
2112 For details of what configuration combinations are valid, see the
2113 ipvsadm(8) man page.
2114
2115 Note: Where an option can be configured for a virtual server, real
2116 server, and possibly checker, the virtual server setting is the default
2117 for real servers, and the real server setting is the default for check‐
2118 ers.
2119
2120 Note: Tunnelled real/sorry servers can differ from the address family
2121 of the virtual server and non tunnelled real/sorry servers, which all
2122 have to be the same. If a virtual server uses a fwmark, and all the
2123 real/sorry servers are tunnelled, the address family of the virtual
2124 server will be the same as the address family of the real/sorry servers
2125 if they are all the same, otherwise it will default to IPv4 (use
2126 ip_family inet6 to override this).
2127
2128 Note: The port for the virtual server can only be omitted if the vir‐
2129 tual service is persistent.
2130
2132 This feature offers a way to simplify your configuration by factorizing
2133 virtual server definitions. If you need to define a bunch of virtual
2134 servers with exactly the same real server topology then this feature
2135 will make your configuration much more readable, optimize the duplica‐
2136 tion of IPVS virtual servers if nftables_ipvs is used, and will opti‐
2137 mize healthchecking task by only spawning one healthchecker where mul‐
2138 tiple virtual servers declaration would spawn a dedicated healthchecker
2139 for every real server which will waste system resources.
2140
2141 Any combination of IP addresses, IP address ranges and firewall marks
2142 can be used, provided that the family of the IP addresses of the vir‐
2143 tual server group match the IP address family of all the real servers
2144 of any virtual server using the virtual server group. The one exception
2145 to this is that the virtual server group can be configured with both
2146 IPv4 and IPv6 addresses and fwmarks provided that all the real servers
2147 (and sorry servers) of all virtual servers using the virtual server
2148 group use tunnel forwarding; if fwmarks are specified in this case, the
2149 address family must be specified (the one exception to this is if the
2150 virtual server group has no IP addresses (i.e. fwmarks only) and all
2151 the real/sorry servers are tunnelled, it will default to IPv4; it is
2152 not good practice to rely on this and the address families of the fw‐
2153 marks should be configured). Use of this option is intended for very
2154 large LVSs, but note, this can create a huge number of virtual servers
2155 unless nftables_ipvs is used. The use of nftables_ipvs is stringly rec‐
2156 ommended due to the very significant optimisations and efficiencies it
2157 provides.
2158
2159 NOTE: do not configure more than one TCP, one UDP and one SCTP virtual
2160 server with the same IP address family using the same virtual server
2161 group (or to put it another way do not have two virtual servers with
2162 the same protocol and address family using the same virtual server
2163 group); if all the real servers are tunnelled, then you must not have
2164 both IPv4 and IPv6 virtual servers with the same protocol.
2165
2166 The syntax for virtual_server_group is :
2167
2168 virtual_server_group <STRING> {
2169 # Virtual IP Address and Port
2170 <IPADDR> [<PORT>]
2171 <IPADDR> [<PORT>]
2172 ...
2173 # <IPADDR RANGE> is any of the following forms (or their IPv6 equivalents)
2174 # XXX.YYY.ZZZ.WWW-VVV eg 192.168.200.1-10 (includes both .1 and .10)
2175 # AAA.BBB.CCC.DDD-EEE.FFF.GGG.HHH eg 192.168.200.250-192.168.201.10
2176 # III.JJJ.KKK.LLL/nn eg 192.168.202.8/29
2177 <IPADDR RANGE> [<PORT>] # VIP range [VPORT]
2178 <IPADDR RANGE> [<PORT>]
2179 ...
2180 # Firewall Mark (fwmark)
2181 # inet/inet6 should only be specified for virtual server groups
2182 # where all real servers of the virtual servers are tunnelled.
2183 fwmark <INTEGER>
2184 fwmark <INTEGER> [inet|inet6]
2185 ...
2186 }
2187
2189 A virtual_server can be a declaration of one of <IPADDR> [<PORT>] , fw‐
2190 mark <INTEGER> or group <STRING>
2191
2192 The syntax for virtual_server is :
2193
2194 virtual_server <IPADDR> [<PORT>] |
2195 virtual_server fwmark <INTEGER> |
2196 virtual_server group <STRING> {
2197 # LVS scheduler
2198 lvs_sched rr|wrr|lc|wlc|lblc|sh|mh|dh|fo|ovf|lblcr|sed|nq|twos
2199
2200 # Enable flag-1 for scheduler (-b flag-1 in ipvsadm)
2201 flag-1
2202 # Enable flag-2 for scheduler (-b flag-2 in ipvsadm)
2203 flag-2
2204 # Enable flag-3 for scheduler (-b flag-3 in ipvsadm)
2205 flag-3
2206 # Enable sh-port for sh scheduler (-b sh-port in ipvsadm)
2207 sh-port
2208 # Enable sh-fallback for sh scheduler (-b sh-fallback in ipvsadm)
2209 sh-fallback
2210 # Enable mh-port for mh scheduler (-b mh-port in ipvsadm)
2211 mh-port
2212 # Enable mh-fallback for mh scheduler (-b mh-fallback in ipvsadm)
2213 mh-fallback
2214 # Enable One-Packet-Scheduling for UDP (-o in ipvsadm)
2215 ops
2216
2217 # Override default LVS forwarding method (default is NAT).
2218 # Default tunnel type is ipip. Since Linux 5.2 the GUE tunnel type can
2219 # be specified. If using GUE, a port number is required. Since Linux 5.3
2220 # if the tunnel type is GUE, the checksum option can also be specified.
2221 # Since Linux 5.3, GRE tunnel type is also supported, but without the
2222 # remcsum option.
2223 lvs_method NAT|DR
2224 or
2225 lvs_method TUN [type {ipip|gue port NUM|gre} [nocsum|csum|remcsum]]
2226 # LVS persistence engine name (currently only sip supported)
2227 persistence_engine <STRING>
2228 # LVS persistence timeout in seconds, default 6 minutes
2229 persistence_timeout [<INTEGER>]
2230 # LVS granularity mask (-M in ipvsadm)
2231 persistence_granularity <NETMASK>
2232 # L4 protocol
2233 protocol TCP|UDP|SCTP
2234 # If VS IP address is not set,
2235 # suspend healthchecker's activity
2236 ha_suspend
2237
2238 # Send email notification during quorum up/down transition,
2239 # using addresses in global_defs above (default no,
2240 # unless global smtp_alert/smtp_alert_checker set)
2241 smtp_alert <BOOL>
2242
2243 # Default VirtualHost string for HTTP_GET or SSL_GET
2244 # eg virtualhost www.firewall.loc
2245 # Overridden by virtualhost config of real server or checker
2246 virtualhost <STRING>
2247
2248 # snmp_name is a text string that is returned as part of the snmp
2249 # data for this virtual server. It can be used to help identify the
2250 # virtual server when parsing SNMP output.
2251 snmp_name <STRING>
2252
2253 # On daemon startup assume that all RSs are down
2254 # and healthchecks failed. This helps to prevent
2255 # false positives on startup. Alpha mode is
2256 # disabled by default.
2257 alpha
2258
2259 # On daemon shutdown consider quorum and RS
2260 # down notifiers for execution, where appropriate.
2261 # Omega mode is disabled by default.
2262 omega
2263
2264 # Minimum total weight of all live servers in
2265 # the pool necessary to operate VS with no
2266 # quality regression. Defaults to 1.
2267 quorum <INTEGER>
2268
2269 # Tolerate this much weight units compared to the
2270 # nominal quorum, when considering quorum gain
2271 # or loss. A flap dampener. Defaults to 0.
2272 hysteresis <INTEGER>
2273
2274 # Script to execute when quorum is gained.
2275 quorum_up <STRING>|<QUOTED-STRING> [username [groupname]]
2276
2277 # Script to execute when quorum is lost.
2278 quorum_down <STRING>|<QUOTED-STRING> [username [groupname]]
2279
2280 # IP family for a fwmark service (only needed if all real servers are tunnelled
2281 # and persistence_granularity is not specified). Defaults to inet if not specified.
2282 ip_family inet|inet6
2283
2284 # setup realserver(s)
2285
2286 # RS to add to LVS topology when the quorum isn't achieved.
2287 # If a sorry server is configured, all real servers will
2288 # be brought down when the quorum is not achieved and be
2289 # replaced with the sorry server.
2290 sorry_server <IPADDR> [<PORT>]
2291 # applies inhibit_on_failure behaviour to the sorry_server
2292 sorry_server_inhibit
2293 # Sorry server LVS forwarding method. Default is the virtual
2294 # server's default.
2295 # For details of tunnel type, see virtual_server details.
2296 sorry_server_lvs_method NAT|DR
2297 or
2298 sorry_server_lvs_method TUN [type {ipip|gue port NUM|gre} [nocsum|csum|remcsum]]
2299
2300 # Optional connection timeout in seconds.
2301 # The default is 5 seconds
2302 connect_timeout <TIMER>
2303
2304 # Retry count to make additional checks if check
2305 # of an alive server fails. Default: 1 unless specified below
2306 retry <INTEGER>
2307
2308 # delay before retry after failure. Defaults to delay_loop for DNS_CHECK,
2309 # 3 seconds for HTTP_GET and SSL_GET, and 1 second otherwise.
2310 delay_before_retry <TIMER>
2311
2312 # Optional random delay to start the initial check
2313 # for maximum N seconds.
2314 # Useful to scatter multiple simultaneous
2315 # checks to the same RS. Enabled by default, with
2316 # the maximum at delay_loop. Specify 0 to disable
2317 warmup <TIMER>
2318
2319 # delay timer for checker polling (60 seconds if not specified)
2320 delay_loop <TIMER>
2321
2322 # Set weight to 0 when healthchecker detects failure
2323 inhibit_on_failure
2324
2325 # one entry for each realserver
2326 real_server <IPADDR> [<PORT>] {
2327 # relative weight to use, default: 1
2328 weight <INTEGER>
2329 # LVS forwarding method
2330 # For details of tunnel type, see virtual_server details. The default
2331 # setting is taken from the virtual_server's setting.
2332 lvs_method NAT|DR
2333 or
2334 lvs_method TUN [type {ipip|gue port NUM|gre} [nocsum|csum|remcsum]]
2335
2336 # Script to execute when healthchecker
2337 # considers service as up.
2338 notify_up <STRING>|<QUOTED-STRING> [username [groupname]]
2339 # Script to execute when healthchecker
2340 # considers service as down.
2341 notify_down <STRING>|<QUOTED-STRING> [username [groupname]]
2342
2343 # maximum number of connections to server
2344 uthreshold <INTEGER>
2345 # minimum number of connections to server
2346 lthreshold <INTEGER>
2347
2348 # Send email notification during state transition,
2349 # using addresses in global_defs above (default yes,
2350 # unless global smtp_alert/smtp_alert_checker set)
2351 smtp_alert <BOOL>
2352
2353 # Default VirtualHost string for HTTP_GET or SSL_GET
2354 # eg virtualhost www.firewall.loc
2355 # Overridden by virtualhost config of a checker
2356 virtualhost <STRING>
2357
2358 # snmp_name is a text string that is returned as part of the snmp
2359 # data for this real server. It can be used to help identify the
2360 # real server when parsing SNMP output.
2361 snmp_name <STRING>
2362
2363 alpha <BOOL> # see above
2364 connect_timeout <TIMER> # see above
2365 retry <INTEGER> # see above
2366 delay_before_retry <TIMER> # see above
2367 warmup <TIMER> # see above
2368 delay_loop <TIMER> # see above
2369 inhibit_on_failure <BOOL> # see above
2370
2371 # healthcheckers. Can be multiple of each type
2372 # HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|DNS_CHECK|MISC_CHECK|BFD_CHECK|UDP_CHECK|PING_CHECK|FILE_CHECK
2373
2374 # All checkers have the following options, except MISC_CHECK which only
2375 # has options alpha onwards, and BFD_CHECK and FILE_CHECK which have none
2376 # of the standard options:
2377 CHECKER_TYPE {
2378 # ======== generic connection options
2379 # Optional IP address to connect to.
2380 # The default is the realserver IP
2381 connect_ip <IPADDR>
2382
2383 # Optional port to connect to
2384 # The default is the realserver port
2385 connect_port <PORT>
2386
2387 # Optional address to use to
2388 # originate the connection
2389 bindto <IPADDR>
2390
2391 # Optional interface to use; needed if
2392 # the bindto address is IPv6 link local
2393 bind_if <IFNAME>
2394
2395 # Optional source port to
2396 # originate the connection from
2397 bind_port <PORT>
2398
2399 # Optional fwmark to mark all outgoing
2400 # checker packets with
2401 fwmark <INTEGER>
2402
2403 alpha <BOOL> # see above
2404 connect_timeout <TIMER> # see above
2405 retry <INTEGER> # see above
2406 delay_before_retry <TIMER> # see above
2407 warmup <TIMER> # see above
2408 delay_loop <TIMER> # see above
2409 log_all_failures <BOOL> # log all failures when checker up
2410 }
2411
2412 # The following options are additional checker specific
2413
2414 # HTTP and SSL healthcheckers
2415 HTTP_GET|SSL_GET {
2416 # HTTP protocol version, one of 1.0, 1.0C, 1.1
2417 # Protocol version 1.0C means version 1.0 with the addition
2418 # of a "Connection: close" line, which is included in
2419 # version 1.1 by default.
2420 http_protocol <PROTOCOL>
2421 # When alpha mode is set, or when recovering from a failure,
2422 # each URL is checked, with a delay of <delay_loop> between
2423 # each check. if there were 20 URLs, and the <delay_loop> were
2424 # 3 seconds, it would take 1 minute before the RS would come up
2425 # following startup, or recovery from a failure. Setting
2426 # fast_recovery removes the delay, both at start up and after
2427 # recovery from a failure, meaning that the RS will come up
2428 # once all the URLs have been checked, with no delay between
2429 # checking each URL.
2430 fast_recovery [<BOOL>]
2431 # An url to test
2432 # can have multiple entries here
2433 url {
2434 #eg path / , or path /mrtg2/
2435 path <STRING>
2436 # healthcheck needs digest
2437 # or status_code and digest
2438 # Digest computed with genhash
2439 # eg digest 9b3a0c85a887a256d6939da88aabd8cd
2440 digest <STRING>
2441 # status code returned in the HTTP header
2442 # eg status_code 200 or status_code 200-299 400-499 503 505
2443 # Default is 200-299
2444 status_code <INTEGER|RANGE> [<INTEGER|RANGE>] ...
2445 # VirtualHost string. eg virtualhost www.firewall.loc
2446 # If not set, uses virtualhost from real or virtual server
2447 virtualhost <STRING>
2448 # Regular expression to search returned data against.
2449 # A failure to match causes the check to fail.
2450 regex <STRING>
2451 # Reverse the sense of the match, so a match of the
2452 # returned text causes the check to fail.
2453 regex_no_match
2454 # Space separated list of options for regex.
2455 # See man pcre2api for a description of the options.
2456 # The following option are supported:
2457 # allow_empty_class alt_bsux auto_callout caseless
2458 # dollar_endonly dotall dupnames extended firstline
2459 # match_unset_backref multiline never_ucp never_utf
2460 # no_auto_capture no_auto_possess no_dotstar_anchor
2461 # no_start_optimize ucp ungreedy utf never_backslash_c
2462 # alt_circumflex alt_verbnames use_offset_limit
2463 regex_options <OPTIONS>
2464 # For complicated regular expressions a larger stack
2465 # may be needed, and this allows the start and maximum
2466 # sizes in bytes to be specified. For more details see
2467 # the documentation for pcre2_jit_stack_create()
2468 regex_stack <START> <MAX>
2469 # The minimum offset into the returned data to start
2470 # checking for the regex pattern match. This can save
2471 # processing time if the returned data is large.
2472 regex_min_offset <OFFSET>
2473 # The maximum offset into the returned data for the
2474 # start of the subject match.
2475 regex_max_offset <OFFSET>
2476 # SSL_GET only - see SSL_GET below for description
2477 tls_compliant
2478 }
2479 }
2480
2481 SSL_GET {
2482 # when provided, send Server Name Indicator during SSL handshake
2483 enable_sni
2484 # Comply with TLS protocol - send close_notify alert
2485 # (see SSL_set_quiet_shutdown(3) man page)
2486 tls_compliant
2487 }
2488
2489 # TCP healthchecker
2490 TCP_CHECK {
2491 # No additional options
2492 }
2493
2494 # SMTP healthchecker
2495 SMTP_CHECK {
2496 # Optional string to use for the SMTP HELO request
2497 helo_name <STRING>|<QUOTED-STRING>
2498 }
2499
2500 # DNS healthchecker. Uses UDP protocol.
2501 DNS_CHECK {
2502 # The retry default is 3.
2503
2504 # DNS query type
2505 # A|NS|CNAME|SOA|MX|TXT|AAAA
2506 # The default is SOA
2507 type <STRING>
2508
2509 # Domain name to use for the DNS query
2510 # The default is . (dot)
2511 name <STRING>
2512 }
2513
2514 # MISC healthchecker, run a program
2515 MISC_CHECK {
2516 # The retry default is 0.
2517
2518 # External script or program
2519 misc_path <STRING>|<QUOTED-STRING>
2520 # Script execution timeout
2521 misc_timeout <INTEGER>
2522
2523 # If misc_dynamic is set, the exit code from healthchecker
2524 # is used to dynamically adjust the weight as follows:
2525 # exit status 0: svc check success, weight
2526 # unchanged.
2527 # exit status 1: svc check failed.
2528 # exit status 2-255: svc check success,
2529 # then the RS weight is increased by
2530 # (exit status - 2 - rs configured weight).
2531 # An exit status of 10 will set the RS weight to 10. If
2532 # the exit status subsequently changes to 20, the RS
2533 # weight will become 20.
2534 # If there is only one MISC_CHECK and no FILE_CHECKers
2535 # the effect is to set the RS weight to two less than
2536 # the exit status.
2537 # (for example: an exit status of 255 would set
2538 # weight to 253 if no other MISC_CHECKers or
2539 # FILE_CHECKers where configured on the RS)
2540 misc_dynamic
2541
2542 # Specify the username/groupname that the script should
2543 # be run under.
2544 # If GROUPNAME is not specified, the group of the user
2545 # is used
2546 user USERNAME [GROUPNAME]
2547 }
2548
2549 # BFD instance name to check
2550 BFD_CHECK {
2551 name <STRING>
2552 }
2553
2554 # PING healthchecker
2555 # Note: using this checker may cause /proc/sys/net/ipv4/ping_group_range to be
2556 # updated to allow root to use an IPPROTO_ICMP socket.
2557 PING_CHECK {
2558 # No additional options
2559 }
2560
2561 # UDP healthchecker
2562 # Note: for this checker to work properly, it relies on ICMP error messages such as
2563 # HOST_UNREACH, NET_UNREACH, PORT_UNREACH. HOST_UNREACH relies on ARP requests
2564 # timing out, and so connect_timeout should be long enough to allow for this (e.g.
2565 # at least 4 seconds).
2566 # If payload is specified, the HEX_STR will be sent as the UDP data, otherwise a
2567 # random payload will be sent.
2568 # If require_reply is specified, the received data length is checked to ensure that it
2569 # lies between min_reply_length and max_reply_length.
2570 # If require_reply without a hex string is specified, udp reply data must be received
2571 # but the data content is not checked.
2572 # If a require_reply HEX_STR is specified, the reply data will be checked against the
2573 # HEX_STR, which must match up to the minimum of the received data length and the length
2574 # of the require_reply HEX_STR.
2575 # The format of HEX_STR is quite free format, for example:
2576 # Ab12f 3 456 546443123
2577 # would be interpreted as:
2578 # AB 12 0F 03 45 06 54 64 43 12 03
2579 # For the require_reply HEX_STR, a character can be specified as X or x, in which case
2580 # the value of those 4 bits in the reply is ignored. This allows, for example, for
2581 # some form of counter or otherwise.
2582 # It may be that you will want to use PING_CHECK to the same server as well.
2583 UDP_CHECK {
2584 payload <HEX_STR>
2585 require_reply [<HEX_STR>] # Require a reply packet for check to be successful
2586 min_reply_length <INT> # default 0
2587 max_reply_length <INT> # default is 255
2588 }
2589
2590 # File checker
2591 # This reads and monitors the contents of a file, where STRING is the name specified
2592 # in the track_file configuration block (see above).
2593 FILE_CHECK {
2594 track_file <STRING>
2595
2596 # If dynamic is set, the value from the file is used
2597 # to dynamically adjust the weight by adding the weight
2598 # to the quorum and the LVS weight
2599 dynamic
2600
2601 # The weight multiplier to apply to the value read from the file
2602 weight <-2147483647..2147483647> [reverse]
2603 }
2604 }
2605 }
2606
2607 # Parameters used for SSL_GET check.
2608 # If none of the parameters are specified, the SSL context
2609 # will be auto generated.
2610 SSL {
2611 # Password
2612 password <STRING>
2613 # CA file
2614 ca <STRING>
2615 # Certificate file
2616 certificate <STRING>
2617 # Key file
2618 key <STRING>
2619 }
2620
2622 Configuration parser has been extended to support advanced features
2623 such as conditional configuration and parameter substitution. These
2624 features are very useful for any scripted environment where configura‐
2625 tion templates are generated (datacenters).
2626
2628 The config-id defaults to the first part of the node name as returned
2629 by uname, and can be overridden with the -i or --config-id command line
2630 option.
2631
2632 Any configuration line starting with '@' is a conditional configuration
2633 line. The word immediately following (i.e. without any space) the '@'
2634 character is compared against the config-id, and if they don't match,
2635 the configuration line is ignored.
2636
2637 Alternatively, '@^' is a negative comparison, so if the word immedi‐
2638 ately following does NOT match the config-id, the configuration line IS
2639 included.
2640
2641 The purpose of this is to allow a single configuration file to be used
2642 for multiple systems, where the only differences are likely to be the
2643 router_id, vrrp instance priorities, and possibly interface names and
2644 unicast addresses.
2645
2646 For example:
2647
2648 global_defs {
2649 @main router_id main_router
2650 @backup router_id backup_router
2651 }
2652 ...
2653 vrrp_instance VRRP {
2654 ...
2655 @main unicast_src_ip 1.2.3.4
2656 @backup unicast_src_ip 1.2.3.5
2657 @backup2 unicast_src_ip 1.2.3.6
2658 unicast_peer {
2659 @^main 1.2.3.4
2660 @^backup 1.2.3.5
2661 @^backup2 1.2.3.6
2662 }
2663 ...
2664 }
2665
2666 If keepalived is invoked with -i main, then the router_id will be set
2667 to main_router, if invoked with -i backup, then backup_router, if not
2668 invoked with -i, or with -i anything else, then the router_id will not
2669 be set. The unicast peers for main will be 1.2.3.5 and 1.2.3.6.
2670
2672 Substitutable parameters can be specified. The format for defining a
2673 parameter is:
2674
2675 $PARAMETER=VALUE
2676
2677 where there must be no space before the '=' and only whitespace may
2678 preceed to '$'. Empty values are allowed.
2679
2680 Parameter names can be made up of any combination of A-Za-z0-9 and _,
2681 but cannot start with a digit. Parameter names starting with an under‐
2682 score should be considered reserved names that keepalived will define
2683 for various pre-defined options.
2684
2685 After a parameter is defined, any occurrence of $PARAMETER followed by
2686 whitespace, or any occurrence of ${PARAMETER} (which need not be fol‐
2687 lowed by whitespace) will be replaced by VALUE.
2688
2689 Replacement is recursive, so that if a parameter value itself includes
2690 a replaceable parameter, then after the first substitution, the parame‐
2691 ter in the value will then be replaced; the substitution is done at re‐
2692 placement time and not at definition time, so for example:
2693
2694 $ADDRESS_BASE=10.2.${ADDRESS_BASE_SUB}
2695 $ADDRESS_BASE_SUB=0
2696 ${ADDRESS_BASE}.100/32
2697 $ADDRESS_BASE_SUB=10
2698 ${ADDRESS_BASE}.100/32
2699
2700 will produce:
2701 10.2.0.100/32
2702 10.2.10.100/32
2703
2704 Note in the above examples the use of both ADDRESS_BASE and AD‐
2705 DRESS_BASE_SUB required braces ({}) since the parameters were not fol‐
2706 lowed by whitespace (after the first substitution which produced
2707 10.2.${ADDRESS_BASE_SUB}.100/32 the parameter is still not followed by
2708 whitespace).
2709
2710 If a parameter is not defined, it will not be replaced at all, so for
2711 example ${UNDEF_PARAMETER} will remain in the configuration if it is
2712 undefined; this means that existing configuration that contains a '$'
2713 character (for example in a script definition) will not be changed so
2714 long as no new parameter definitions are added to the configuration.
2715
2716 Parameter substitution works in conjunction with conditional configura‐
2717 tion. For example:
2718
2719 @main $PRIORITY=240
2720 @backup $PRIORITY=200
2721 ...
2722 vrrp_instance VI_0 {
2723 priority $PRIORITY
2724 }
2725
2726 will produce:
2727 ...
2728 vrrp_instance VI_0 {
2729 priority 240
2730 }
2731 if the config_id is main.
2732
2733 $IF_MAIN=@main
2734 $IF_MAIN priority 240
2735
2736 will produce:
2737 priority 240
2738 if the config_id is main and nothing if the config_id is not main,
2739 although why anyone would want to use this rather than simply the
2740 following is not known (but still possible):
2741 @main priority 240
2742
2743 Multiline definitions are also supported, but when used there must be
2744 nothing on the line after the parameter name. A multiline definition is
2745 specified by ending each line except the last with a '\' character.
2746
2747 Example:
2748 $INSTANCE= \
2749 vrrp_instance VI_${NUM} { \
2750 interface eth0.${NUM} \
2751 use_vmac vrrp${NUM}.1 \
2752 virtual_router_id 1 \
2753 @high priority 130 \
2754 @low priority 120 \
2755 advert_int 1 \
2756 virtual_ipaddress { \
2757 10.0.${NUM}.254/24 \
2758 } \
2759 track_script { \
2760 offset_instance_${NUM} \
2761 } \
2762 }
2763
2764 $NUM=0
2765 $INSTANCE
2766
2767 $NUM=1
2768 $INSTANCE
2769
2770 The use of multiline definitions can be nested.
2771
2772 Example:
2773 $RS= \
2774 real_server 192.168.${VS_NUM}.${RS_NUM} 80 { \
2775 weight 1 \
2776 inhibit_on_failure \
2777 smtp_alert \
2778 MISC_CHECK { \
2779 misc_path "${_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" \
2780 } \
2781
2782 MISC_CHECK { \
2783 misc_path "${_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" \
2784 } \
2785
2786 notify_up "${_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" \
2787
2788 notify_down "${_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" \
2789
2790 }
2791
2792 $VS= \
2793 virtual_server 10.0.${VS_NUM}.4 80 { \
2794 quorum 2 \
2795 quorum_up "${_PWD}/scripts/notify.sh VS_notify.${INST} UP 10.0.${VS_NUM}.4:80" \
2796 quorum_down "${_PWD}/scripts/notify.sh VS_notify.${INST} DOWN 10.0.${VS_NUM}.4:80" \
2797 $RS_NUM=1 \
2798 $RS \
2799 $RS_NUM=2 \
2800 $RS \
2801 $RS_NUM=3 \
2802 $RS \
2803 }
2804
2805 $VS_NUM=0
2806 $ALPHA=alpha
2807 $VS
2808
2809 $VS_NUM=1
2810 $ALPHA=
2811 $VS
2812
2813 The above will create 2 virtual servers, each with 3 real servers
2814
2816 The following definitions are pre-defined:
2817
2818 ${_PWD} : The directory of the current configuration file (this can be
2819 changed if using the include directive).
2820 ${_INSTANCE} : The instance name (as defined by the -i option, defaults
2821 to hostname).
2822 ${_RANDOM [MIN [MAX]]} : This is replaced by a random integer in the
2823 range [MIN, MAX], where MIN and MAX are optional non-negative integers.
2824 Defaults are MIN=0 and MAX=32767.
2825 ${_HASH} : This is replaced by a '#' character, which would otherwise
2826 start a comment
2827 ${_BANG} : This is replaced by a '!' character, which would otherwise
2828 start a comment
2829
2830 Additional pre-defined definitions will be added as their need is iden‐
2831 tified. It will normally be quite straightforward to add additional
2832 pre-defined definitions, so if you need one, or have a good idea for
2833 one, then raise an issue at https://github.com/acassen/keepalived/is‐
2834 sues requesting it.
2835
2837 A line starting ~SEQ(var, start, step, end) will cause the remainder of
2838 the line to be processed multiple times, with the variable $var set
2839 initially to start, and then $var will be incremented by step repeat‐
2840 edly, terminating when it is greater than end. step may be omitted, in
2841 which case it defaults to 1 or -1, depending on whether end is greater
2842 or less than start. start may also be omitted, in which case it de‐
2843 faults to 1 if end > 0 or -1 if end < 0. ~SEQx(...) is the same as
2844 ~SEQ(...), except the variable $var will for formatted in hexadecimal,
2845 which would be useful for IPv6 addresses.
2846
2847 Note: At the moment it is necessary to use different variables for the
2848 ~SEQ block from any previously defined variable, including one used as
2849 the variable in a previous ~SEQ block. This may change in the future,
2850 so do not rely on a ~SEQ block variable being defined after the end of
2851 the block.
2852
2853 Examples:
2854
2855 ~SEQ(SUBNET, 0, 3) ip_address 10.0.${SUBNET}.1
2856
2857 would produce:
2858 ip_address 10.0.0.1
2859 ip_address 10.0.1.1
2860 ip_address 10.0.2.1
2861 ip_address 10.0.3.1
2862
2863 and
2864 ~SEQx(SUBNET, 144, 16, 192) ip_address fe80::20:${SUBNET}:1
2865 or better
2866 ~SEQx(SUBNET, 0x90, 0x10, 0xc0) ip_address fe80::20:${SUBNET}:1
2867
2868 would produce:
2869 ip_address fe80::20:90:1
2870 ip_address fe80::20:a0:1
2871 ip_address fe80::20:b0:1
2872 ip_address fe80::20:c0:1
2873
2874 Another example:
2875
2876 virtual_ipaddress {
2877 ~SEQx(AD2, 0x90, 0x10, 0xc0) ~SEQx(AD1, 0x12, -1, 0x0c) fe81::10:${AD2}:${AD1}
2878 }
2879
2880 There can be multiple ~SEQ elements on a line, so for example:
2881
2882 $VI4= \
2883 track_file offset_instance_4.${IF}.${NUM}.${ID} { \
2884 file "${_PWD}/679/track_files/4.${IF}.${NUM}.${ID}" \
2885 weight -100 \
2886 } \
2887 vrrp_instance vrrp4.${IF}.${NUM}.${ID} { \
2888 interface bond${IF}.${NUM} \
2889 use_vmac vrrp4.${IF}.${NUM}.${ID} \
2890 virtual_router_id ${ID} \
2891 priority 130 \
2892 virtual_ipaddress { \
2893 10.${IF}.${NUM}.${ID}/24 \
2894 } \
2895 track_file { \
2896 offset_instance_4.${IF}.${NUM}.${ID} \
2897 } \
2898 }
2899
2900 ~SEQ(IF,0,7) ~SEQ(NUM,0,31) ~SEQ(ID,1,254) $VI4
2901
2902 will produce 65024 vrrp instances with names from vrrp4.0.0.1 through to
2903 vrrp4.7.31.254.
2904
2906 List blocks are similar to sequence blocks, except that the values to
2907 substitute into the variable are listed in the ~LST specification.
2908
2909 A line starting ~LST(var, val1, val2, val3) will cause the remainder of
2910 the line to be processed multiple times, with the variable $var set
2911 initially to val1, and then val2, and finally val3. Any number of val‐
2912 ues can be specified, as long as at least one value is (although only
2913 one value would be pointless).
2914
2915 If it is desired to substitute more than one variable at a time, the
2916 variables and values need to be enclosed in {...} blocks. For example:
2917
2918 ~LST({IP, IP1}, {10,1},{20,4},{5,6},{12,8}) 192.168.${IP}.${IP1}
2919
2920 would first set IP=10 and IP1=1, then IP=20 and IP1=4, etc, and pro‐
2921 duces:
2922
2923 192.168.10.1
2924 192.168.20.4
2925 192.168.5.6
2926 192.168.12.8
2927
2928 List blocks can be nested, so:
2929
2930 ~LST(IP, 1, 2, 3, 4) ~LST(IP1, 5,6,7) 192.169.${IP}.${IP1}
2931
2932 produces:
2933 192.169.1.5
2934 192.169.1.6
2935 192.169.1.7
2936 192.169.2.5
2937 192.169.2.6
2938 192.169.2.7
2939 192.169.3.5
2940 192.169.3.6
2941 192.169.3.7
2942 192.169.4.5
2943 192.169.4.6
2944 192.169.4.7
2945
2946 Finally, list blocks and sequence blocks can be combined, so:
2947
2948 ~LST({IP, IP1}, {10,1},{20,4},{5,6},{12,8}) ~SEQ(IP2,168,2,172)
2949 192.${IP2}.${IP}.${IP1}
2950
2951 produces:
2952
2953 192.168.10.1
2954 192.170.10.1
2955 192.172.10.1
2956 192.168.20.4
2957 192.170.20.4
2958 192.172.20.4
2959 192.168.5.6
2960 192.170.5.6
2961 192.172.5.6
2962 192.168.12.8
2963 192.170.12.8
2964 192.172.12.8
2965
2967 It has been identified that if proxy_arp and proxy_arp_pvlan are en‐
2968 abled on an interface that has VIPs or eVIPs configured on it, it can
2969 cause incorrect replies to ARP requests due to the proxy replying to
2970 the ARP request as well as the keepalived host. Both need to be set to
2971 0 to function properly.
2972
2974 Initial by Joseph Mack. Extensive updates by Alexandre Cassen & Quentin
2975 Armitage.
2976
2978 ipvsadm(8), ip --help.
2979
2980
2981
2982Keepalived 2023-04-01 keepalived.conf(5)