vyos/vyos-documentation
1
0
Fork 0
mirror of https://github.com/vyos/vyos-documentation.git synced 2025-11-03 04:12:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

dhcp: use proper indent on description inside failover section

Browse Source
This commit is contained in:
Christian Poessinger 2020-01-04 16:20:22 +01:00
parent 389f5fb8e5
commit 811129e2e3
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/services/dhcp.rst
View File

@ -83,24 +83,24 @@ explicitly by the following statements.
A generic `<name>` referencing this sync service.
.. note:: `<name>` must be identical on both sides!
.. note:: `<name>` must be identical on both sides!
.. cfgcmd:: set service dhcp-server shared-network-name <name> subnet <subnet> failover status <primary | secondary>
The primary and secondary statements determines whether the server is primary
or secondary.
.. note:: In order for the primary and the secondary DHCP server to keep
their lease tables in sync, they must be able to reach each other on TCP
port 647. If you have firewall rules in effect, adjust them accordingly.
.. note:: In order for the primary and the secondary DHCP server to keep
their lease tables in sync, they must be able to reach each other on TCP
port 647. If you have firewall rules in effect, adjust them accordingly.
.. hint:: The dialogue between failover partners is neither encrypted nor
authenticated. Since most DHCP servers exist within an organisation's own
secure Intranet, this would be an unnecessary overhead. However, if you have
DHCP failover peers whose communications traverse insecure networks, then we
recommend that you consider the use of VPN tunneling between them to ensure
that the failover partnership is immune to disruption (accidental or
otherwise) via third parties.
.. hint:: The dialogue between failover partners is neither encrypted nor
authenticated. Since most DHCP servers exist within an organisation's own
secure Intranet, this would be an unnecessary overhead. However, if you have
DHCP failover peers whose communications traverse insecure networks, then we
recommend that you consider the use of VPN tunneling between them to ensure
that the failover partnership is immune to disruption (accidental or
otherwise) via third parties.
Example
^^^^^^^