reservations.json 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161
  1. // This is an example configuration file for the DHCPv4 server in Kea.
  2. // It contains one subnet in which there are two static address reservations
  3. // for the clients identified by the MAC addresses.
  4. { "Dhcp4":
  5. {
  6. // Kea is told to listen on ethX interface only.
  7. "interfaces-config": {
  8. "interfaces": [ "ethX" ]
  9. },
  10. // We need to specify the the database used to store leases. As of September
  11. // 2016, four database backends are supported: MySQL, PostgreSQL, Cassandra, and
  12. // the in-memory database, Memfile. We'll use memfile because it doesn't
  13. // require any prior set up.
  14. "lease-database": {
  15. "type": "memfile",
  16. "lfc-interval": 3600
  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), circuit-id
  29. // (circuit identifier inserted by the relay agent) and flex-id (flexible
  30. // identifier available when flex_id hook library is loaded). When told to do
  31. // so, Kea can check for all of those identifier types, but it takes a costly
  32. // database lookup to do so. It is therefore useful from a performance
  33. // perspective to use only the reservation types that are actually used in a
  34. // given network.
  35. // The example below is not optimal from a performance perspective, but it
  36. // nicely showcases the host reservation capabilities. Please use the minimum
  37. // set of identifier types used in your network.
  38. "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid",
  39. "client-id", "flex-id" ],
  40. // Define a subnet with four reservations. Some of the reservations belong
  41. // to the dynamic pool. Kea is able to handle this case, but it is not
  42. // recommended from a performance perspective, as Kea would not only need to
  43. // check if a given address is free, but also whether it is reserved.
  44. // To avoid this check, one can change reservation-mode to out-of-pool, rather
  45. // than 'all'. If a subnet does not have reservations at all, the reservation
  46. // lookup can be skipped altogether (reservation-mode is set to 'disabled').
  47. // Note that the second reservation is for an address which is within the
  48. // range of the pool of the dynamically allocated address. The server will
  49. // exclude this address from this pool and only assign it to the client which
  50. // has a reservation for it.
  51. "subnet4": [
  52. {
  53. "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
  54. "subnet": "192.0.2.0/24",
  55. "interface": "eth0",
  56. "reservation-mode": "out-of-pool",
  57. "reservations": [
  58. // This is a reservation for a specific hardware/MAC address. It's a very
  59. // simple reservation: just an address and nothing else.
  60. {
  61. "hw-address": "1a:1b:1c:1d:1e:1f",
  62. "ip-address": "192.0.2.201"
  63. },
  64. // This is a reservation for a specific client-id. It also shows
  65. // the this client will get a reserved hostname. A hostname can be defined
  66. // for any identifier type, not just client-id.
  67. {
  68. "client-id": "01:11:22:33:44:55:66",
  69. "ip-address": "192.0.2.202",
  70. "hostname": "special-snowflake"
  71. },
  72. // The third reservation is based on DUID. This reservation also
  73. // defines special option values for this particular client. If
  74. // the domain-name-servers option would have been defined on a global,
  75. // subnet or class level, the host specific values take preference.
  76. {
  77. "duid": "01:02:03:04:05",
  78. "ip-address": "192.0.2.203",
  79. "option-data": [ {
  80. "name": "domain-name-servers",
  81. "data": "10.1.1.202,10.1.1.203"
  82. } ]
  83. },
  84. // The fourth reservation is based on circuit-id. This is an option inserted
  85. // by the relay agent that forwards the packet from client to the server.
  86. // In this example the host is also assigned vendor specific options.
  87. {
  88. "client-id": "01:11:22:33:44:55:66",
  89. "ip-address": "192.0.2.204",
  90. "option-data": [
  91. {
  92. "name": "vivso-suboptions",
  93. "data": "4491"
  94. },
  95. {
  96. "name": "tftp-servers",
  97. "space": "vendor-4491",
  98. "data": "10.1.1.202,10.1.1.203"
  99. }
  100. ]
  101. },
  102. // This reservation is for a client that needs specific DHCPv4 fields to be
  103. // set. Three supported fields are next-server, server-hostname and
  104. // boot-file-name
  105. {
  106. "client-id": "01:0a:0b:0c:0d:0e:0f",
  107. "ip-address": "192.0.2.205",
  108. "next-server": "192.0.2.1",
  109. "server-hostname": "hal9000",
  110. "boot-file-name": "/dev/null"
  111. },
  112. // This reservation is using flexible identifier. Instead of relying
  113. // on specific field, sysadmin can define an expression similar to what
  114. // is used for client classification,
  115. // e.g. substring(relay[0].option[17],0,6). Then, based on the value of
  116. // that expression for incoming packet, the reservation is matched.
  117. // Expression can be specified either as hex or plain text using single
  118. // quotes.
  119. // Note: flexible identifier requires flex_id hook library to be
  120. // loaded to work.
  121. {
  122. "flex-id": "s0mEVaLue",
  123. "ip-address": "192.0.2.206"
  124. }
  125. ]
  126. }
  127. ]
  128. },
  129. // The following configures logging. It assumes that messages with at
  130. // least informational level (info, warn, error and fatal) should be
  131. // logged to stdout.
  132. "Logging": {
  133. "loggers": [
  134. {
  135. "name": "kea-dhcp4",
  136. "output_options": [
  137. {
  138. "output": "stdout"
  139. }
  140. ],
  141. "severity": "INFO"
  142. }
  143. ]
  144. }
  145. }