|
@@ -0,0 +1,101 @@
|
|
|
+# This is an example configuration file for the DHCPv4 server in Kea.
|
|
|
+# The purpose of this example is to showcase how clients can be classified.
|
|
|
+
|
|
|
+{ "Dhcp4": {
|
|
|
+
|
|
|
+# Kea is told to listen on ethX interface only.
|
|
|
+ "interfaces-config": {
|
|
|
+ "interfaces": [ "ethX" ]
|
|
|
+ },
|
|
|
+
|
|
|
+# Let's use the simplest backend: memfile and use some reasonable values
|
|
|
+# for timers. They are of no concern for the classification demonstration.
|
|
|
+ "lease-database": { "type": "memfile" },
|
|
|
+ "renew-timer": 1000,
|
|
|
+ "rebind-timer": 2000,
|
|
|
+ "valid-lifetime": 4000,
|
|
|
+
|
|
|
+# This list defines several classes that incoming packets can be assigned to.
|
|
|
+# One packet can belong to zero or more classes.
|
|
|
+ "client-classes": [
|
|
|
+
|
|
|
+# The first class attempts to match the whole hardware address to specific
|
|
|
+# value. All incoming packets with that MAC address will get special
|
|
|
+# value of the option. If there are many hosts that require special
|
|
|
+# treatment, it is much better to use host reservations. However, doing
|
|
|
+# tricks with MAC addresses may prove useful in some cases, e.g.
|
|
|
+# by matching OUI to known value we can detect certain vendors.
|
|
|
+ {
|
|
|
+ "name": "special_snowflake",
|
|
|
+ "test": "pkt4.mac == 0x010203040506",
|
|
|
+ "option-data": [{
|
|
|
+ "name": "domain-name-servers",
|
|
|
+ "data": "127.0.0.1"
|
|
|
+ }]
|
|
|
+ },
|
|
|
+
|
|
|
+# Let's classify all incoming DISCOVER (message type 1) to a separate
|
|
|
+# class.
|
|
|
+ {
|
|
|
+ "name": "discovers",
|
|
|
+ "test": "pkt4.msgtype == 1"
|
|
|
+ },
|
|
|
+
|
|
|
+# Clients are supposed to set transaction-id field to a random value.
|
|
|
+# Clients that send it with 0 are most likely broken. Let's mark them
|
|
|
+# as such.
|
|
|
+ {
|
|
|
+ "name": "broken",
|
|
|
+ "test": "pkt4.transid == 0"
|
|
|
+ },
|
|
|
+
|
|
|
+# Let's pick VoIP phones. Those that send their class identifiers
|
|
|
+# as Aastra, should belong to VoIP class. For a list of all options,
|
|
|
+# see www.iana.org/assignments/bootp-dhcp-parameters/
|
|
|
+ {
|
|
|
+ "name": "VoIP",
|
|
|
+ "test": "substring(option[60].hex,0,6) == 'Aastra'"
|
|
|
+ },
|
|
|
+
|
|
|
+ ],
|
|
|
+
|
|
|
+# The following list defines subnets. For some subnets we defined
|
|
|
+# a class that is allowed in that subnet. If not specified,
|
|
|
+# everyone is allowed. When it is specified, only packets belonging
|
|
|
+# to that class are allowed for a given subnet.
|
|
|
+ "subnet4": [
|
|
|
+ {
|
|
|
+# This one is for VoIP devices only.
|
|
|
+ "pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
|
|
|
+ "subnet": "192.0.2.0/24",
|
|
|
+ "client-class": "VoIP",
|
|
|
+ "interface": "ethX"
|
|
|
+ },
|
|
|
+# This one doesn't have any client-class specified, so everyone
|
|
|
+# is allowed in. The normal subnet selection rules still apply,
|
|
|
+# though.
|
|
|
+ {
|
|
|
+ "pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ],
|
|
|
+ "subnet": "192.0.3.0/24",
|
|
|
+ "interface": "ethX"
|
|
|
+ }
|
|
|
+ ]
|
|
|
+},
|
|
|
+
|
|
|
+# The following configures logging. It assumes that messages with at least
|
|
|
+# informational level (info, warn, error) will will be logged to stdout.
|
|
|
+"Logging": {
|
|
|
+ "loggers": [
|
|
|
+ {
|
|
|
+ "name": "kea-dhcp4",
|
|
|
+ "output_options": [
|
|
|
+ {
|
|
|
+ "output": "stdout"
|
|
|
+ }
|
|
|
+ ],
|
|
|
+ "severity": "INFO"
|
|
|
+ }
|
|
|
+ ]
|
|
|
+}
|
|
|
+
|
|
|
+}
|