<xref linkend="cql-database-create"/>).
<screen>
"Dhcp4": { "lease-database": { <userinput>"name": "<replaceable>database-name</replaceable>" </userinput>, ... }, ... }
+</screen>
+ For Cassandra:
+<screen>
+"Dhcp4": { "lease-database": { <userinput>"keyspace": "<replaceable>database-name</replaceable>" </userinput>, ... }, ... }
</screen>
If the database is located on a different system to the DHCPv4 server, the
database host name must also be specified. (It should be noted that this
configuration may have a severe impact on server performance.):
<screen>
-"Dhcp4": { "lease-database": { <userinput>"host": <replaceable>remote-host-name</replaceable></userinput>, ... }, ... }
+"Dhcp4": { "lease-database": { <userinput>"host": "<replaceable>remote-host-name</replaceable>"</userinput>, ... }, ... }
+</screen>
+ For Cassandra, multiple contact points can be provided:
+<screen>
+"Dhcp4": { "lease-database": { <userinput>"contact_points": "<replaceable>remote-host-name[, ...] </replaceable>"</userinput>, ... }, ... }
</screen>
The usual state of affairs will be to have the database on the same machine as
the DHCPv4 server. In this case, set the value to the empty string:
<screen>
"Dhcp4": { "lease-database": { <userinput>"host" : ""</userinput>, ... }, ... }
+</screen>
+ For Cassandra:
+<screen>
+"Dhcp4": { "lease-database": { <userinput>"contact_points": ""</userinput>, ... }, ... }
</screen>
Should the database be located on a different system, you may need to specify a longer interval
for the connection timeout:
Cassandra (CQL).</para>
</section>
-
<section id="reservations4-tuning">
<title>Fine Tuning DHCPv4 Host Reservation</title>
src/lib/dhcpsrv/cfg_host_operations.cc -->
</para>
-
-
-
</section>
</section>
or <xref linkend="cql-database-create"/>).
<screen>
"Dhcp6": { "lease-database": { <userinput>"name": "<replaceable>database-name</replaceable>" </userinput>, ... }, ... }
+</screen>
+ For Cassandra:
+<screen>
+"Dhcp6": { "lease-database": { <userinput>"keyspace": "<replaceable>database-name</replaceable>" </userinput>, ... }, ... }
</screen>
If the database is located on a different system to the DHCPv6 server, the
database host name must also be specified. (It should be noted that this
configuration may have a severe impact on server performance.):
<screen>
-"Dhcp6": { "lease-database": { <userinput>"host": <replaceable>remote-host-name</replaceable></userinput>, ... }, ... }
+"Dhcp6": { "lease-database": { <userinput>"host": "<replaceable>remote-host-name</replaceable>"</userinput>, ... }, ... }
+</screen>
+ For Cassandra, multiple contact points can be provided:
+<screen>
+"Dhcp6": { "lease-database": { <userinput>"contact_points": "<replaceable>remote-host-name[, ...]</replaceable>" </userinput>, ... }, ... }
</screen>
The usual state of affairs will be to have the database on the same machine as
the DHCPv6 server. In this case, set the value to the empty string:
<screen>
"Dhcp6": { "lease-database": { <userinput>"host" : ""</userinput>, ... }, ... }
+</screen>
+ For Cassandra:
+<screen>
+"Dhcp6": { "lease-database": { <userinput>"contact_points": ""</userinput>, ... }, ... }
</screen>
Should the database be located on a different system, you may need to specify a longer interval
for the connection timeout:
</section>
-
<section id="dhcp6-interface-selection">
<title>Interface Selection</title>
<para>The DHCPv6 server has to be configured to listen on specific network
<xref linkend="dhcp6-option-data-defaults"/>.
</para>
-
<para>
It is possible to override options on a per-subnet basis. If
clients connected to most of your subnets are expected to get the
no means to validate the format at the moment.
</para>
-
<para>
<table frame="all" id="dhcp6-std-options-list">
<title>List of Standard DHCPv6 Options</title>
</itemizedlist>
</para>
-
<section id="dhcpv6-d2-io-config">
<title>DHCP-DDNS Server Connectivity</title>
<para>
<xref linkend="command-shutdown" />, respectively.</para>
</section>
-
<section>
<title>User context in IPv6 pools</title>
<para>