pgsql-reservations.json 3.5 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697
  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
  27. // identifiers: hw-address (hardware/MAC address of the client), duid
  28. // (DUID inserted by the client), client-id (client identifier inserted
  29. // by the client) and circuit-id (circuit identifier inserted by the
  30. // relay agent). When told to do so, Kea can check for all of those
  31. // identifier types, but it takes a costly database lookup to do so. It
  32. // is therefore useful from a performance perspective to use only the
  33. // reservation types that are actually used in a given network.
  34. // The example below is not optimal from a performance perspective, but it
  35. // nicely showcases the host reservation capabilities. Please use the minimum
  36. // set of identifier types used in your network.
  37. "host-reservation-identifiers":
  38. [ "circuit-id", "hw-address", "duid", "client-id" ],
  39. // Specify connection to the database holding host reservations. The type
  40. // specifies that the PostgreSQL database is used. user and password are the
  41. // credentials used to connect to the database. host and name specify
  42. // location of the host where the database instance is running, and the
  43. // name of the database to use. The server processing a packet will first
  44. // check if there are any reservations specified for this client in the
  45. // reservations list, within the subnet (configuration file). If there are
  46. // no reservations there, the server will try to retrieve reservations
  47. // from this database.
  48. "hosts-database": {
  49. "type": "postgresql",
  50. "name": "kea",
  51. "user": "kea",
  52. "password": "kea",
  53. "host": "localhost"
  54. },
  55. // Define a subnet with a single pool of dynamic addresses. Addresses from
  56. // this pool will be assigned to clients which don't have reservations in the
  57. // database. Subnet identifier is equal to 1. If this subnet is selected for
  58. // the client, this subnet id will be used to search for the reservations
  59. // within the database.
  60. "subnet4": [
  61. {
  62. "pools": [ { "pool": "192.0.2.10 - 192.0.2.200" } ],
  63. "subnet": "192.0.2.0/24",
  64. "interface": "ethX",
  65. "id": 1
  66. }
  67. ]
  68. },
  69. // The following configures logging. It assumes that messages with at
  70. // least informational level (info, warn, error and fatal) should be
  71. // logged to stdout.
  72. "Logging": {
  73. "loggers": [
  74. {
  75. "name": "kea-dhcp4",
  76. "output_options": [
  77. {
  78. "output": "stdout"
  79. }
  80. ],
  81. "severity": "INFO"
  82. }
  83. ]
  84. }
  85. }