classify.json 3.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101
  1. # This is an example configuration file for the DHCPv4 server in Kea.
  2. # The purpose of this example is to showcase how clients can be classified.
  3. { "Dhcp4": {
  4. # Kea is told to listen on ethX interface only.
  5. "interfaces-config": {
  6. "interfaces": [ "ethX" ]
  7. },
  8. # Let's use the simplest backend: memfile and use some reasonable values
  9. # for timers. They are of no concern for the classification demonstration.
  10. "lease-database": { "type": "memfile" },
  11. "renew-timer": 1000,
  12. "rebind-timer": 2000,
  13. "valid-lifetime": 4000,
  14. # This list defines several classes that incoming packets can be assigned to.
  15. # One packet can belong to zero or more classes.
  16. "client-classes": [
  17. # The first class attempts to match the whole hardware address to a specific
  18. # value. All incoming packets with that MAC address will get a special
  19. # value of the option. If there are many hosts that require special
  20. # treatment, it is much better to use host reservations. However, doing
  21. # tricks with MAC addresses may prove useful in some cases, e.g.
  22. # by matching OUI to known values we can detect certain vendors.
  23. {
  24. "name": "special_snowflake",
  25. "test": "pkt4.mac == 0x010203040506",
  26. "option-data": [{
  27. "name": "domain-name-servers",
  28. "data": "127.0.0.1"
  29. }]
  30. },
  31. # Let's classify all incoming DISCOVER (message type 1) to a separate
  32. # class.
  33. {
  34. "name": "discovers",
  35. "test": "pkt4.msgtype == 1"
  36. },
  37. # Clients are supposed to set the transaction-id field to a random value.
  38. # Clients that send it with 0 are most likely broken. Let's mark them
  39. # as such.
  40. {
  41. "name": "broken",
  42. "test": "pkt4.transid == 0"
  43. },
  44. # Let's pick VoIP phones. Those that send their class identifiers
  45. # as Aastra, should belong to VoIP class. For a list of all options,
  46. # see www.iana.org/assignments/bootp-dhcp-parameters/
  47. {
  48. "name": "VoIP",
  49. "test": "substring(option[60].hex,0,6) == 'Aastra'"
  50. },
  51. ],
  52. # The following list defines subnets. For some subnets we defined
  53. # a class that is allowed in that subnet. If not specified,
  54. # everyone is allowed. When a class is specified, only packets belonging
  55. # to that class are allowed for that subnet.
  56. "subnet4": [
  57. {
  58. # This one is for VoIP devices only.
  59. "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
  60. "subnet": "192.0.2.0/24",
  61. "client-class": "VoIP",
  62. "interface": "ethX"
  63. },
  64. # This one doesn't have any client-class specified, so everyone
  65. # is allowed in. The normal subnet selection rules still apply,
  66. # though.
  67. {
  68. "pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ],
  69. "subnet": "192.0.3.0/24",
  70. "interface": "ethX"
  71. }
  72. ]
  73. },
  74. # The following configures logging. It assumes that messages with at least
  75. # informational level (info, warn, error) will will be logged to stdout.
  76. "Logging": {
  77. "loggers": [
  78. {
  79. "name": "kea-dhcp4",
  80. "output_options": [
  81. {
  82. "output": "stdout"
  83. }
  84. ],
  85. "severity": "INFO"
  86. }
  87. ]
  88. }
  89. }