]>
Commit | Line | Data |
---|---|---|
b58ab00f QY |
1 | .. _vrrp: |
2 | ||
3 | **** | |
4 | VRRP | |
5 | **** | |
6 | ||
7 | :abbr:`VRRP` stands for Virtual Router Redundancy Protocol. This protocol is | |
8 | used to allow multiple backup routers on the same segment to take over | |
9 | operation of each others' IP addresses if the primary router fails. This is | |
10 | typically used to provide fault-tolerant gateways to hosts on the segment. | |
11 | ||
12 | FRR implements VRRPv2 (:rfc:`3768`) and VRRPv3 (:rfc:`5798`). For VRRPv2, no | |
13 | authentication methods are supported; these are deprecated in the VRRPv2 | |
14 | specification as they do not provide any additional security over the base | |
15 | protocol. | |
16 | ||
17 | .. note:: | |
18 | ||
19 | - VRRP is supported on Linux 5.1+ | |
20 | - VRRP does not implement Accept_Mode | |
21 | ||
22 | .. _vrrp-starting: | |
23 | ||
24 | Starting VRRP | |
25 | ============= | |
26 | ||
27 | The configuration file for *vrrpd* is :file:`vrrpd.conf`. The typical location | |
28 | of :file:`vrrpd.conf` is |INSTALL_PREFIX_ETC|/vrrpd.conf. | |
29 | ||
30 | If using integrated config, then :file:`vrrpd.conf` need not be present and | |
31 | :file:`frr.conf` is read instead. | |
32 | ||
33 | .. program:: vrrpd | |
34 | ||
35 | :abbr:`VRRP` supports all the common FRR daemon start options which are | |
36 | documented elsewhere. | |
37 | ||
38 | .. _vrrp-protocol-overview: | |
39 | ||
40 | Protocol Overview | |
41 | ================= | |
42 | ||
43 | From :rfc:`5798`: | |
44 | ||
45 | VRRP specifies an election protocol that dynamically assigns responsibility | |
46 | for a virtual router to one of the VRRP routers on a LAN. The VRRP router | |
47 | controlling the IPv4 or IPv6 address(es) associated with a virtual router is | |
48 | called the Master, and it forwards packets sent to these IPv4 or IPv6 | |
49 | addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 | |
50 | addresses, and VRRP Backup routers infer the address family of the virtual | |
51 | addresses being carried based on the transport protocol. Within a VRRP | |
52 | router, the virtual routers in each of the IPv4 and IPv6 address families | |
53 | are a domain unto themselves and do not overlap. The election process | |
54 | provides dynamic failover in the forwarding responsibility should the Master | |
55 | become unavailable. For IPv4, the advantage gained from using VRRP is a | |
56 | higher-availability default path without requiring configuration of dynamic | |
57 | routing or router discovery protocols on every end-host. For IPv6, the | |
58 | advantage gained from using VRRP for IPv6 is a quicker switchover to Backup | |
59 | routers than can be obtained with standard IPv6 Neighbor Discovery | |
60 | mechanisms. | |
61 | ||
62 | VRRP accomplishes these goals primarily by using a virtual MAC address shared | |
63 | between the physical routers participating in a VRRP virtual router. This | |
64 | reduces churn in the neighbor tables of hosts and downstream switches and makes | |
65 | router failover theoretically transparent to these devices. | |
66 | ||
67 | FRR implements the election protocol and handles changing the operating system | |
68 | interface configuration in response to protocol state changes. | |
69 | ||
70 | As a consequence of the shared virtual MAC requirement, VRRP is currently | |
71 | supported only on Linux, as Linux is the only operating system that provides | |
72 | the necessary features in its network stack to make implementing this protocol | |
73 | feasible. | |
74 | ||
75 | When a VRRP router is acting as the Master router, FRR allows the interface(s) | |
76 | with the backed-up IP addresses to remain up and functional. When the router | |
77 | transitions to Backup state, these interfaces are set into ``protodown`` mode. | |
78 | This is an interface mode that is functionally equivalent to ``NO-CARRIER``. | |
79 | Physical drivers typically use this state indication to drop traffic on an | |
80 | interface. In the case of VRRP, the interfaces in question are macvlan devices, | |
81 | which are virtual interfaces. Since the IP addresses managed by VRRP are on | |
82 | these interfaces, this has the same effect as removing these addresses from the | |
83 | interface, but is implemented as a state flag. | |
84 | ||
85 | .. _vrrp-configuration: | |
86 | ||
87 | Configuring VRRP | |
88 | ================ | |
89 | ||
90 | VRRP is configured on a per-interface basis, with some global defaults | |
91 | accessible outside the interface context. | |
92 | ||
93 | .. _vrrp-system-configuration: | |
94 | ||
95 | System Configuration | |
96 | -------------------- | |
97 | ||
98 | FRR's VRRP implementation uses Linux macvlan devices to to implement the shared | |
99 | virtual MAC feature of the protocol. Currently, it does not create those system | |
100 | interfaces - they must be configured outside of FRR before VRRP can be enabled | |
101 | on them. | |
102 | ||
103 | Each interface on which VRRP will be enabled must have at least one macvlan | |
104 | device configured with the virtual MAC and placed in the proper operation mode. | |
105 | The addresses backed up by VRRP are assigned to these interfaces. | |
106 | ||
107 | Suppose you have an interface ``eth0`` with the following configuration: | |
108 | ||
109 | .. code-block:: console | |
110 | ||
7456e5b3 | 111 | $ ip addr show eth0 |
b58ab00f QY |
112 | 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 |
113 | link/ether 02:17:45:00:aa:aa brd ff:ff:ff:ff:ff:ff | |
114 | inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0 | |
115 | valid_lft 72532sec preferred_lft 72532sec | |
b58ab00f QY |
116 | inet6 fe80::17:45ff:fe00:aaaa/64 scope link |
117 | valid_lft forever preferred_lft forever | |
118 | ||
803a4db6 GN |
119 | Suppose that the IPv4 and IPv6 addresses you want to back up are ``10.0.2.16`` |
120 | and ``2001:db8::370:7334``, and that they will be managed by the virtual router | |
121 | with id ``5``. A macvlan device with the appropriate MAC address must be created | |
122 | before VRRP can begin to operate. | |
b58ab00f QY |
123 | |
124 | If you are using ``ifupdown2``, the configuration is as follows: | |
125 | ||
126 | .. code-block:: console | |
127 | ||
128 | iface eth0 | |
129 | ... | |
130 | vrrp 5 10.0.2.16/24 2001:0db8::0370:7334/64 | |
131 | ||
132 | Applying this configuration with ``ifreload -a`` will create the appropriate | |
133 | macvlan device. If you are using ``iproute2``, the equivalent configuration is: | |
134 | ||
135 | .. code-block:: console | |
136 | ||
137 | ip link add vrrp4-2-1 link eth0 addrgenmode random type macvlan mode bridge | |
138 | ip link set dev vrrp4-2-1 address 00:00:5e:00:01:05 | |
139 | ip addr add 10.0.2.16/24 dev vrrp4-2-1 | |
140 | ip link set dev vrrp4-2-1 up | |
141 | ||
142 | ip link add vrrp6-2-1 link eth0 addrgenmode random type macvlan mode bridge | |
143 | ip link set dev vrrp4-2-1 address 00:00:5e:00:02:05 | |
144 | ip addr add 2001:db8::370:7334/64 dev vrrp6-2-1 | |
145 | ip link set dev vrrp6-2-1 up | |
146 | ||
147 | In either case, the created interfaces will look like this: | |
148 | ||
149 | .. code-block:: console | |
150 | ||
151 | $ ip addr show vrrp4-2-1 | |
152 | 5: vrrp4-2-1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 | |
153 | link/ether 00:00:5e:00:01:05 brd ff:ff:ff:ff:ff:ff | |
154 | inet 10.0.2.16/24 scope global vrrp4-2-1 | |
155 | valid_lft forever preferred_lft forever | |
156 | inet6 fe80::dc56:d11a:e69d:ea72/64 scope link stable-privacy | |
157 | valid_lft forever preferred_lft forever | |
158 | ||
159 | $ ip addr show vrrp6-2-1 | |
160 | 8: vrrp6-2-1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 | |
161 | link/ether 00:00:5e:00:02:05 brd ff:ff:ff:ff:ff:ff | |
162 | inet6 2001:db8::370:7334/64 scope global | |
163 | valid_lft forever preferred_lft forever | |
164 | inet6 fe80::f8b7:c9dd:a1e8:9844/64 scope link stable-privacy | |
165 | valid_lft forever preferred_lft forever | |
166 | ||
167 | Using ``vrrp4-2-1`` as an example, a few things to note about this interface: | |
168 | ||
169 | - It is slaved to ``eth0``; any packets transmitted on this interface will | |
170 | egress via ``eth0`` | |
171 | - Its MAC address is set to the VRRP IPv4 virtual MAC specified by the RFC for | |
172 | :abbr:`VRID (Virtual Router ID)` ``5`` | |
99650006 GN |
173 | - The :abbr:`VIP (Virtual IP)` address ``10.0.2.16`` must not be present on |
174 | the parent interface ``eth0``. | |
b58ab00f QY |
175 | - The link local address on the interface is not derived from the interface |
176 | MAC | |
177 | ||
178 | First to note is that packets transmitted on this interface will egress via | |
179 | ``eth0``, but with their Ethernet source MAC set to the VRRP virtual MAC. This | |
180 | is how FRR's VRRP implementation accomplishes the virtual MAC requirement on | |
181 | real hardware. | |
182 | ||
183 | Ingress traffic is a more complicated matter. Macvlan devices have multiple | |
184 | operating modes that change how ingress traffic is handled. Of relevance to | |
185 | FRR's implementation are the ``bridge`` and ``private`` modes. In ``private`` | |
186 | mode, any ingress traffic on ``eth0`` (in our example) with a source MAC | |
187 | address equal to the MAC address on any of ``eth0``'s macvlan devices will be | |
188 | placed *only* on that macvlan device. This curious behavior is undesirable, | |
189 | since FRR's implementation of VRRP needs to be able to receive advertisements | |
190 | from neighbors while in Backup mode - i.e., while its macvlan devices are in | |
191 | ``protodown on``. If the macvlan devices are instead set to ``bridge`` mode, | |
192 | all ingress traffic shows up on all interfaces - including ``eth0`` - | |
193 | regardless of source MAC or any other factor. Consequently, macvlans used by | |
194 | FRR for VRRP must be set to ``bridge`` mode or the protocol will not function | |
195 | correctly. | |
196 | ||
197 | As for the MAC address assigned to this interface, the last byte of the address | |
198 | holds the :abbr:`VRID (Virtual Router Identifier)`, in this case ``0x05``. The | |
199 | second to last byte is ``0x01``, as specified by the RFC for IPv4 operation. | |
200 | The IPv6 MAC address is be identical except that the second to last byte is | |
201 | defined to be ``0x02``. Two things to note from this arrangement: | |
202 | ||
203 | 1. There can only be up to 255 unique Virtual Routers on an interface (only 1 | |
204 | byte is available for the VRID) | |
205 | 2. IPv4 and IPv6 addresses must be assigned to different macvlan devices, | |
206 | because they have different MAC addresses | |
207 | ||
208 | Finally, take note of the generated IPv6 link local address on the interface. | |
209 | For interfaces on which VRRP will operate in IPv6 mode, this link local | |
210 | *cannot* be derived using the usual EUI-64 method. This is because VRRP | |
211 | advertisements are sent from the link local address of this interface, and VRRP | |
212 | uses the source address of received advertisements as part of its election | |
213 | algorithm. If the IPv6 link local of a router is equivalent to the IPv6 link | |
214 | local in a received advertisement, this can cause both routers to assume the | |
215 | Master role (very bad). ``ifupdown`` knows to set the ``addrgenmode`` of the | |
216 | interface properly, but when using ``iproute2`` to create the macvlan devices, | |
217 | you must be careful to manually specify ``addrgenmode random``. | |
218 | ||
219 | A brief note on the Backup state | |
220 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
221 | ||
222 | It is worth noting here that an alternate choice for the implementation of the | |
223 | Backup state, such as removing all the IP addresses assigned to the macvlan | |
224 | device or deleting their local routes instead of setting the device into | |
225 | ``protodown on``, would allow the protocol to function regardless of whether | |
226 | the macvlan device(s) are set to ``private`` or ``bridge`` mode. Indeed, the | |
227 | strange behavior of the kernel macvlan driver in ``private`` mode, whereby it | |
228 | performs what may be thought of as a sort of interface-level layer 2 "NAT" | |
229 | based on source MAC, can be traced back to a patch clearly designed to | |
230 | accommodate a VRRP implementation from a different vendor. However, the | |
231 | ``protodown`` based implementation allows for a configuration model in which | |
232 | FRR does not dynamically manage the addresses assigned on a system, but instead | |
233 | just manages interface state. Such a scenario was in mind when this protocol | |
234 | implementation was initially built, which is why the other choices are not | |
235 | currently present. Since support for placing macvlan devices into ``protodown`` | |
236 | was not added to Linux until version 5.1, this also explains the relatively | |
237 | restrictive kernel versioning requirement. | |
238 | ||
239 | In the future other methods of implementing Backup state may be added along | |
240 | with a configuration knob to choose between them. | |
241 | ||
242 | .. _vrrp-interface-configuration: | |
243 | ||
244 | Interface Configuration | |
245 | ----------------------- | |
246 | ||
247 | Continuing with the example from the previous section, we assume the macvlan | |
248 | interfaces have been properly configured with the proper MAC addresses and the | |
249 | IPvX addresses assigned. | |
250 | ||
251 | In FRR, a possible VRRPv3 configuration for this interface is: | |
252 | ||
253 | .. code-block:: frr | |
254 | ||
255 | interface eth0 | |
256 | vrrp 5 version 3 | |
257 | vrrp 5 priority 200 | |
258 | vrrp 5 advertisement-interval 1500 | |
259 | vrrp 5 ip 10.0.2.16 | |
260 | vrrp 5 ipv6 2001:0db8::0370:7334 | |
261 | ||
262 | VRRP will activate as soon as the first IPvX address configuration line is | |
263 | encountered. If you do not want this behavior, use the :clicmd:`vrrp (1-255) | |
264 | shutdown` command, and apply the ``no`` form when you are ready to activate | |
265 | VRRP. | |
266 | ||
267 | At this point executing ``show vrrp`` will display the following: | |
268 | ||
269 | .. code-block:: console | |
270 | ||
271 | ubuntu-bionic# show vrrp | |
272 | ||
273 | Virtual Router ID 5 | |
274 | Protocol Version 3 | |
275 | Autoconfigured Yes | |
276 | Shutdown No | |
277 | Interface eth0 | |
278 | VRRP interface (v4) vrrp4-2-5 | |
279 | VRRP interface (v6) vrrp6-2-5 | |
280 | Primary IP (v4) 10.0.2.15 | |
281 | Primary IP (v6) fe80::9b91:7155:bf6a:d386 | |
282 | Virtual MAC (v4) 00:00:5e:00:01:05 | |
283 | Virtual MAC (v6) 00:00:5e:00:02:05 | |
284 | Status (v4) Master | |
285 | Status (v6) Master | |
286 | Priority 200 | |
287 | Effective Priority (v4) 200 | |
288 | Effective Priority (v6) 200 | |
289 | Preempt Mode Yes | |
290 | Accept Mode Yes | |
291 | Advertisement Interval 1500 ms | |
292 | Master Advertisement Interval (v4) 1000 ms | |
293 | Master Advertisement Interval (v6) 1000 ms | |
294 | Advertisements Tx (v4) 14 | |
295 | Advertisements Tx (v6) 14 | |
296 | Advertisements Rx (v4) 0 | |
297 | Advertisements Rx (v6) 0 | |
298 | Gratuitous ARP Tx (v4) 1 | |
299 | Neigh. Adverts Tx (v6) 1 | |
300 | State transitions (v4) 2 | |
301 | State transitions (v6) 2 | |
302 | Skew Time (v4) 210 ms | |
303 | Skew Time (v6) 210 ms | |
304 | Master Down Interval (v4) 3210 ms | |
305 | Master Down Interval (v6) 3210 ms | |
306 | IPv4 Addresses 1 | |
307 | .................................. 10.0.2.16 | |
308 | IPv6 Addresses 1 | |
309 | .................................. 2001:db8::370:7334 | |
310 | ||
311 | At this point, VRRP has sent gratuitous ARP requests for the IPv4 address, | |
312 | Unsolicited Neighbor Advertisements for the IPv6 address, and has asked Zebra | |
313 | to send Router Advertisements on its behalf. It is also transmitting VRRPv3 | |
314 | advertisements on the macvlan interfaces. | |
315 | ||
316 | The Primary IP fields are of some interest, as the behavior may be | |
317 | counterintuitive. These fields show the source address used for VRRP | |
318 | advertisements. Although VRRPv3 advertisements are always transmitted on the | |
319 | macvlan interfaces, in the IPv4 case the source address is set to the primary | |
320 | IPv4 address on the base interface, ``eth0`` in this case. This is a protocol | |
321 | requirement, and IPv4 VRRP will not function unless the base interface has an | |
322 | IPv4 address assigned. In the IPv6 case the link local of the macvlan interface | |
323 | is used. | |
324 | ||
325 | If any misconfiguration errors are detected, VRRP for the misconfigured address | |
326 | family will not come up and the configuration issue will be logged to FRR's | |
327 | configured logging destination. | |
328 | ||
329 | Per the RFC, IPv4 and IPv6 virtual routers are independent of each other. For | |
330 | instance, it is possible for the IPv4 router to be in Backup state while the | |
331 | IPv6 router is in Master state; or for either to be completely inoperative | |
332 | while the other is operative, etc. Instances sharing the same base interface | |
333 | and VRID are shown together in the show output for conceptual convenience. | |
334 | ||
335 | To complete your VRRP deployment, configure other routers on the segment with | |
336 | the exact same system and FRR configuration as shown above. Provided each | |
337 | router receives the others' VRRP advertisements, the Master election protocol | |
338 | will run, one Master will be elected, and the other routers will place their | |
339 | macvlan interfaces into ``protodown on`` until Master fails or priority values | |
340 | are changed to favor another router. | |
341 | ||
342 | Switching the protocol version to VRRPv2 is accomplished simply by changing | |
343 | ``version 3`` to ``version 2`` in the VRID configuration line. Note that VRRPv2 | |
344 | does not support IPv6, so any IPv6 configuration will be rejected by FRR when | |
345 | using VRRPv2. | |
346 | ||
347 | .. note:: | |
348 | ||
349 | All VRRP routers initially start in Backup state, and wait for the | |
350 | calculated Master Down Interval to pass before they assume Master status. | |
351 | This prevents downstream neighbor table churn if another router is already | |
352 | Master with higher priority, meaning this box will ultimately assume Backup | |
353 | status once the first advertisement is received. However, if the calculated | |
354 | Master Down Interval is high and this router is configured such that it will | |
355 | ultimately assume Master status, then it will take a while for this to | |
356 | happen. This is a known issue. | |
357 | ||
358 | ||
359 | All interface configuration commands are documented below. | |
360 | ||
361 | .. index:: [no] vrrp (1-255) [version (2-3)] | |
362 | .. clicmd:: [no] vrrp (1-255) [version (2-3)] | |
363 | ||
364 | Create a VRRP router with the specified VRID on the interface. Optionally | |
365 | specify the protocol version. If the protocol version is not specified, the | |
366 | default is VRRPv3. | |
367 | ||
368 | .. index:: [no] vrrp (1-255) advertisement-interval (10-40950) | |
369 | .. clicmd:: [no] vrrp (1-255) advertisement-interval (10-40950) | |
370 | ||
371 | Set the advertisement interval. This is the interval at which VRRP | |
372 | advertisements will be sent. Values are given in milliseconds, but must be | |
373 | multiples of 10, as VRRP itself uses centiseconds. | |
374 | ||
375 | .. index:: [no] vrrp (1-255) ip A.B.C.D | |
376 | .. clicmd:: [no] vrrp (1-255) ip A.B.C.D | |
377 | ||
378 | Add an IPv4 address to the router. This address must already be configured | |
379 | on the appropriate macvlan device. Adding an IP address to the router will | |
380 | implicitly activate the router; see :clicmd:`[no] vrrp (1-255) shutdown` to | |
381 | override this behavior. | |
382 | ||
383 | .. index:: [no] vrrp (1-255) ipv6 X:X::X:X | |
384 | .. clicmd:: [no] vrrp (1-255) ipv6 X:X::X:X | |
385 | ||
386 | Add an IPv6 address to the router. This address must already be configured | |
387 | on the appropriate macvlan device. Adding an IP address to the router will | |
388 | implicitly activate the router; see :clicmd:`[no] vrrp (1-255) shutdown` to | |
389 | override this behavior. | |
390 | ||
391 | This command will fail if the protocol version is set to VRRPv2, as VRRPv2 | |
392 | does not support IPv6. | |
393 | ||
394 | .. index:: [no] vrrp (1-255) preempt | |
395 | .. clicmd:: [no] vrrp (1-255) preempt | |
396 | ||
397 | Toggle preempt mode. When enabled, preemption allows Backup routers with | |
398 | higher priority to take over Master status from the existing Master. Enabled | |
399 | by default. | |
400 | ||
401 | .. index:: [no] vrrp (1-255) priority (1-254) | |
402 | .. clicmd:: [no] vrrp (1-255) priority (1-254) | |
403 | ||
404 | Set the router priority. The router with the highest priority is elected as | |
405 | the Master. If all routers in the VRRP virtual router are configured with | |
406 | the same priority, the router with the highest primary IP address is elected | |
407 | as the Master. Priority value 255 is reserved for the acting Master router. | |
408 | ||
409 | .. index:: [no] vrrp (1-255) shutdown | |
410 | .. clicmd:: [no] vrrp (1-255) shutdown | |
411 | ||
412 | Place the router into administrative shutdown. VRRP will not activate for | |
413 | this router until this command is removed with the ``no`` form. | |
414 | ||
415 | .. _vrrp-global-configuration: | |
416 | ||
417 | Global Configuration | |
418 | -------------------- | |
419 | ||
420 | Show commands, global defaults and debugging configuration commands. | |
421 | ||
422 | .. index:: show vrrp [interface INTERFACE] [(1-255)] [json] | |
423 | .. clicmd:: show vrrp [interface INTERFACE] [(1-255)] [json] | |
424 | ||
425 | Shows VRRP status for some or all configured VRRP routers. Specifying an | |
426 | interface will only show routers configured on that interface. Specifying a | |
427 | VRID will only show routers with that VRID. Specifying ``json`` will dump | |
428 | each router state in a JSON array. | |
429 | ||
7456e5b3 GN |
430 | .. index:: [no] debug vrrp [{protocol|autoconfigure|packets|sockets|ndisc|arp|zebra}] |
431 | .. clicmd:: [no] debug vrrp [{protocol|autoconfigure|packets|sockets|ndisc|arp|zebra}] | |
b58ab00f | 432 | |
7456e5b3 GN |
433 | Toggle debugging logs for VRRP components. |
434 | If no component is specified, debugging for all components are turned on/off. | |
b58ab00f QY |
435 | |
436 | protocol | |
437 | Logs state changes, election protocol decisions, and interface status | |
438 | changes. | |
439 | ||
440 | autoconfigure | |
441 | Logs actions taken by the autoconfiguration procedures. See | |
442 | :ref:`vrrp-autoconfiguration`. | |
443 | ||
444 | packets | |
445 | Logs details of ingress and egress packets. Includes packet decodes and | |
446 | hex dumps. | |
447 | ||
448 | sockets | |
449 | Logs details of socket configuration and initialization. | |
450 | ||
451 | ndisc | |
452 | Logs actions taken by the Neighbor Discovery component of VRRP. | |
453 | ||
454 | arp | |
455 | Logs actions taken by the ARP component of VRRP. | |
456 | ||
457 | zebra | |
458 | Logs communications with Zebra. | |
459 | ||
460 | .. index:: [no] vrrp default <advertisement-interval (1-4096)|preempt|priority (1-254)|shutdown> | |
461 | .. clicmd:: [no] vrrp default <advertisement-interval (1-4096)|preempt|priority (1-254)|shutdown> | |
462 | ||
463 | Configure defaults for new VRRP routers. These values will not affect | |
464 | already configured VRRP routers, but will be applied to newly configured | |
465 | ones. | |
466 | ||
467 | .. _vrrp-autoconfiguration: | |
468 | ||
469 | Autoconfiguration | |
470 | ----------------- | |
471 | ||
472 | In light of the complicated configuration required on the base system before | |
473 | VRRP can be enabled, FRR has the ability to automatically configure VRRP | |
474 | sessions by inspecting the interfaces present on the system. Since it is quite | |
475 | unlikely that macvlan devices with VRRP virtual MACs will exist on systems not | |
476 | using VRRP, this can be a convenient shortcut to automatically generate FRR | |
477 | configuration. | |
478 | ||
479 | After configuring the interfaces as described in | |
480 | :ref:`vrrp-system-configuration`, and configuring any defaults you may want, | |
481 | execute the following command: | |
482 | ||
483 | .. index:: [no] vrrp autoconfigure [version (2-3)] | |
484 | .. clicmd:: [no] vrrp autoconfigure [version (2-3)] | |
485 | ||
486 | Generates VRRP configuration based on the interface configuration on the | |
7456e5b3 GN |
487 | base system. If the protocol version is not specified, the default is VRRPv3. |
488 | Any existing interfaces that are configured properly for VRRP - | |
b58ab00f QY |
489 | i.e. have the correct MAC address, link local address (when required), IPv4 |
490 | and IPv6 addresses - are used to create a VRRP router on their parent | |
491 | interfaces, with VRRP IPvX addresses taken from the addresses assigned to | |
492 | the macvlan devices. The generated configuration appears in the output of | |
493 | ``show run``, which can then be modified as needed and written to the config | |
494 | file. The ``version`` parameter controls the protocol version; if using | |
495 | VRRPv2, keep in mind that IPv6 is not supported and will not be configured. | |
496 | ||
497 | The following configuration is then generated for you: | |
498 | ||
499 | .. code-block:: frr | |
500 | ||
501 | interface eth0 | |
502 | vrrp 5 | |
503 | vrrp 5 ip 10.0.2.16 | |
504 | vrrp 5 ipv6 2001:db8::370:7334 | |
505 | ||
506 | VRRP is automatically activated. Global defaults, if set, are applied. | |
507 | ||
508 | You can then edit this configuration with **vtysh** as needed, and commit it by | |
509 | writing to the configuration file. |