pgsql-reservations.json 3.5 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
  1. // This is an example configuration file for the DHCPv4 server in Kea.
  2. // It contains configuration of the PostgreSQL host database backend, used
  3. // to retrieve reserved addresses, host names, DHCPv4 message fields
  4. // and DHCP options from PostgreSQL database.
  5. { "Dhcp4":
  6. {
  7. // Kea is told to listen on ethX interface only.
  8. "interfaces-config": {
  9. "interfaces": [ "ethX" ]
  10. },
  11. // We need to specify the the database used to store leases. As of
  12. // September 2016, four database backends are supported: MySQL,
  13. // PostgreSQL, Cassandra, and the in-memory database, Memfile.
  14. // We'll use memfile because it doesn't require any prior set up.
  15. "lease-database": {
  16. "type": "memfile"
  17. },
  18. // Addresses will be assigned with a lifetime of 4000 seconds.
  19. "valid-lifetime": 4000,
  20. // Renew and rebind timers are commented out. This implies that options
  21. // 58 and 59 will not be sent to the client. In this case it is up to
  22. // the client to pick the timer values according to RFC2131. Uncomment the
  23. // timers to send these options to the client.
  24. // "renew-timer": 1000,
  25. // "rebind-timer": 2000,
  26. // Kea supports reservations by several different types of identifiers:
  27. // hw-address (hardware/MAC address of the client), duid (DUID inserted by the
  28. // client), client-id (client identifier inserted by the client) and circuit-id
  29. // (circuit identifier inserted by the relay agent). When told to do so, Kea can
  30. // check for all of those identifier types, but it takes a costly database lookup
  31. // to do so. It is therefore useful from a performance perspective to use only
  32. // the reservation types that are actually used in a given network.
  33. // The example below is not optimal from a performance perspective, but it
  34. // nicely showcases the host reservation capabilities. Please use the minimum
  35. // set of identifier types used in your network.
  36. "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
  37. // Specify connection to the database holding host reservations. The type
  38. // specifies that the PostgreSQL database is used. user and password are the
  39. // credentials used to connect to the database. host and name specify
  40. // location of the host where the database instance is running, and the
  41. // name of the database to use. The server processing a packet will first
  42. // check if there are any reservations specified for this client in the
  43. // reservations list, within the subnet (configuration file). If there are
  44. // no reservations there, the server will try to retrieve reservations
  45. // from this database.
  46. "hosts-database": {
  47. "type": "postgresql",
  48. "name": "kea",
  49. "user": "kea",
  50. "password": "kea",
  51. "host": "localhost"
  52. },
  53. // Define a subnet with a single pool of dynamic addresses. Addresses from
  54. // this pool will be assigned to clients which don't have reservations in the
  55. // database. Subnet identifier is equal to 1. If this subnet is selected for
  56. // the client, this subnet id will be used to search for the reservations
  57. // within the database.
  58. "subnet4": [
  59. {
  60. "pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ],
  61. "subnet": "192.0.2.0/24",
  62. "interface": "ethX",
  63. "id": 1
  64. }
  65. ]
  66. },
  67. // The following configures logging. It assumes that messages with at least
  68. // informational level (info, warn, error and fatal) should be logged to stdout.
  69. "Logging": {
  70. "loggers": [
  71. {
  72. "name": "kea-dhcp4",
  73. "output_options": [
  74. {
  75. "output": "stdout"
  76. }
  77. ],
  78. "severity": "INFO"
  79. }
  80. ]
  81. }
  82. }