2
0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-29 04:57:52 +00:00
kea/doc/examples/kea4/classify.json
Thomas Markwalder b4ca3bdd20 [#3582] Update kea-dhcp6 parsing and UTs
/doc/examples/kea4/all-keys.json
/doc/examples/kea4/classify.json
/doc/examples/kea4/classify2.json
/doc/examples/kea4/ha-load-balancing-server1-mt-with-tls.json
/doc/examples/kea4/ha-load-balancing-server1-mt-with-tls.json
/doc/examples/kea4/ha-load-balancing-server2-mt.json
/doc/examples/kea4/ha-load-balancing-server2-mt.json
/doc/examples/kea4/hooks-radius.json
/doc/examples/kea6/all-keys.json

/src/bin/dhcp4/tests/config_parser_unittest.cc
    TEST_F(Dhcp4ParserTest, deprecatedClientClassesCheck) - new test

/src/bin/dhcp4/tests/get_config_unittest.cc
    updated

/src/bin/dhcp6/dhcp6_lexer.ll
/src/bin/dhcp6/dhcp6_parser.yy
    added support for client-classes

/src/bin/dhcp6/tests/config_parser_unittest.cc
    updated
    TEST_F(Dhcp6ParserTest, sharedNetworksDeriveClientClass) - removed obsolete test
    TEST_F(Dhcp6ParserTest, deprecatedClientClassesCheck) - new test

/src/bin/dhcp6/tests/get_config_unittest.cc
/src/bin/dhcp6/tests/host_unittest.cc
/src/bin/dhcp6/tests/shared_network_unittest.cc
    updated

src/lib/dhcpsrv/parsers/simple_parser6.cc
    Corrected globals
2024-11-26 17:19:56 +00:00

148 lines
4.6 KiB
JSON

// 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 eth0 interface only.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
// 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 a specific
// value. All incoming packets with that MAC address will get a 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 values 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 the 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/.
// In this particular class, we want to set specific values
// of certain DHCPv4 fields. If the incoming packet matches the
// test, those fields will be set in outgoing responses.
// The option 43 is defined to encapsulate suboption in the aastra space.
{
"name": "VoIP",
"test": "substring(option[60].hex,0,6) == 'Aastra'",
"next-server": "192.0.2.254",
"server-hostname": "hal9000",
"boot-file-name": "/dev/null",
"option-def": [ {
"name": "vendor-encapsulated-options",
"code": 43,
"type": "empty",
"encapsulate": "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 a class is specified, only packets belonging
// to that class are allowed for that subnet.
"subnet4": [
// This one is for VoIP devices only.
{
"pools": [ { "pool": "192.0.2.1 - 192.0.2.200" } ],
"id": 1,
"subnet": "192.0.2.0/24",
"client-classes": [ "VoIP" ],
"interface": "eth0"
},
// This one doesn't have any client-class specified, so everyone
// is allowed in. The normal subnet selection rules still apply,
// though. There is also a static class reservation for a client
// using MAC address 1a:1b:1c:1d:1e:1f. This client will always
// be assigned to this class.
{
"pools": [ { "pool": "192.0.3.1 - 192.0.3.200" } ],
"id": 2,
"subnet": "192.0.3.0/24",
"reservations": [
{
"hw-address": "1a:1b:1c:1d:1e:1f",
"client-classes": [ "VoIP" ]
} ],
"interface": "eth0"
},
// The following list defines a subnet with pools. For some pools
// we defined a class that is allowed in that pool. If not specified
// everyone is allowed. When a class is specified, only packets belonging
// to that class are allowed for that pool.
{
"pools": [
// This one is for VoIP devices only.
{
"pool": "192.0.4.1 - 192.0.4.200",
"client-classes": [ "VoIP" ]
},
// This one doesn't have any client-class specified,
// so everyone is allowed in.
{
"pool": "192.0.5.1 - 192.0.5.200"
} ],
"subnet": "192.0.4.0/23",
"id": 3,
"interface": "eth1"
}
],
// The following configures logging. It assumes that messages with at
// least informational level (info, warn, error and fatal) should be
// logged to stdout.
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [
{
"output": "stdout"
}
],
"severity": "INFO"
}
]
}
}