summaryrefslogtreecommitdiffstats
path: root/raddb/policy.d/dhcp
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--raddb/policy.d/dhcp327
1 files changed, 327 insertions, 0 deletions
diff --git a/raddb/policy.d/dhcp b/raddb/policy.d/dhcp
new file mode 100644
index 0000000..1752acb
--- /dev/null
+++ b/raddb/policy.d/dhcp
@@ -0,0 +1,327 @@
+# Assign common DHCP reply packet options
+dhcp_common {
+ # The contents here are invented. Change them!
+ update reply {
+ &DHCP-Domain-Name-Server = 127.0.0.1
+ &DHCP-Domain-Name-Server += 127.0.0.2
+ &DHCP-Subnet-Mask = 255.255.255.0
+ &DHCP-Router-Address = 192.0.2.1
+ &DHCP-Broadcast-Address = 192.0.2.255
+ &DHCP-IP-Address-Lease-Time = 7200
+ &DHCP-DHCP-Server-Identifier = &control:DHCP-DHCP-Server-Identifier
+ }
+}
+
+# Lookup DHCP group based options. This policy allows for membership
+# of multiple groups so can cover the ISC concepts of "group" and "class"
+# To use this enable the "dhcp_files" module
+#dhcp_group_options {
+# foreach &request:DHCP-Group-Name {
+# dhcp_set_group_options
+# }
+#}
+
+# Policy to override DHCP-Network-Subnet
+#
+# Some networks have a "shared-network" or "multinet" configuration (as
+# defined by some other DHCP servers) in which multiple IP subnets may
+# co-exist in a single Layer 2 network (or VLAN).
+#
+# In enterprise environments this is often for the purpose of providing loose
+# segregation between classes of devices such as local network-attached
+# storage or IP telephony. There are valid reasons why each of the subnets is
+# not seperately VLANed, such as to enable the use of ICMP redirects to avoid
+# hairpinning of cross-subnet traffic via a gateway.
+#
+# In ISP environments this is a common configuration for edge networks whose
+# access is provided by DOCSIS cable modems that share a VLAN with the devices
+# they provide a service to but are seperately addressed.
+#
+# Where it is necessary to force the selection of a particular subnet for a
+# device, multiple pools must be configured for each subnet and referenced
+# with unique identifiers in the *network-specific* section of
+# mods-config/files/dhcp.
+#
+# By default DHCP-Network-Subnet is populated such that it normally
+# refers to the Layer 2 network from which the DHCP query originates - we
+# cannot know the intended subnet for the device without additional input to
+# the policy.
+#
+# Override DHCP-Network-Subnet to be an address within the desired
+# network to force selection of a particular address pool and/or network
+# parameters.
+#
+# Note: If each subnet within a network is equally valid for the DHCP requests
+# originating from that network then you do not need to call this policy,
+# rather look at the examples concerning dhcp_subnet in
+# mods-config/files/dhcp instead, which use a single pool containing addresses
+# from all subnets then set the correct subnet-specific options based on the
+# randomly assigned IP address.
+#
+#dhcp_override_network {
+# if (&DHCP-Vendor-Class-Identifier && &DHCP-Vendor-Class-Identifier == "SIP100")
+# update request {
+# DHCP-Network-Subnet := 10.10.0.0
+# }
+# }
+#}
+
+
+# Policy that calls the files instance of the same name after first making
+# DHCP-Network-Subnet specific to the allocated IP address of the client.
+#dhcp_subnet {
+# update {
+# &DHCP-Network-Subnet := "%{%{reply:DHCP-Your-IP-Address}:-%{DHCP-Client-IP-Address}}"
+# }
+#
+# # Call the dhcp_subnet instance of the files module
+# dhcp_subnet
+#}
+
+# Assign compatibility data to request for sqlippool for DHCP Request
+dhcp_sqlippool_request {
+
+ #
+ # During initial address selection (DORA) the REQUEST is broadcast and
+ # requested-ip must be provided. We revoke any active offers for addresses
+ # not matching the requested-ip, i.e. those made by other servers when
+ # processing the DISCOVER.
+ #
+ # If there is only a single server then this optimisation can be disabled.
+ #
+ if (&DHCP-Requested-IP-Address) {
+ update request {
+ &Acct-Status-Type := Start
+ }
+ dhcp_sqlippool.accounting
+ }
+
+ # Extend an existing offer or active lease
+ update request {
+ &Acct-Status-Type := Alive
+ }
+ dhcp_sqlippool.accounting {
+ notfound = return
+ }
+
+ update reply {
+ &DHCP-Your-IP-Address := "%{%{DHCP-Requested-IP-Address}:-%{DHCP-Client-IP-Address}}"
+ }
+
+}
+
+# Assign compatibility data to request for sqlippool for DHCP Release
+dhcp_sqlippool_release {
+
+ # Do some minor hacks to the request so that it looks
+ # like a RADIUS Accounting Stop request to the SQL IP Pool module.
+ update request {
+ &Acct-Status-Type = Stop
+ }
+
+ # Call the actual module in accounting context
+ dhcp_sqlippool.accounting
+
+}
+
+# Assign compatibility data to request for sqlippool for DHCP Decline
+dhcp_sqlippool_decline {
+
+ # Do a minor hack to the request so that it looks
+ # like a RADIUS Accounting Off request to the SQL IP Pool module.
+ update request {
+ &Acct-Status-Type = Accounting-Off
+ }
+
+ # Call the actual module in accounting context
+ dhcp_sqlippool.accounting
+
+}
+
+# Example policy for fetching option data from SQL
+dhcp_policy_sql {
+
+ #
+ # Network-specific options
+ #
+
+ #
+ # We want to lookup the Layer 2 network specific DHCP options to
+ # include in the reply. For this we need a stable identifier for the
+ # network from which the request is originating (based on
+ # DHCP-Network-Subnet) which can be used as the lookup key
+ # (DHCP-SQL-Option-Identifier) for the network options.
+ #
+ # Here we fabricate an example for the purpose of placing all
+ # configuration elements into SQL. We use a PostgreSQL query that
+ # returns the network identifier in the row containing the smallest
+ # enclosing CIDR, which assumes a schema such as the following:
+ #
+ # CREATE TABLE fr_network_to_identifier (network CIDR, network_id TEXT)
+ #
+ # Note: An rlm_files based lookup of the network_identifier (as per
+ # the examples in the dhcp virtual server) may be preferable to an ad
+ # hoc SQL query assuming that the network topology does not change
+ # frequently.
+ #
+# update control {
+# &control:Tmp-String-0 := "%{dhcp_sql:SELECT network_id \
+# FROM fr_network_to_identifier \
+# WHERE '%{DHCP-Network-Subnet}'::inet << network \
+# ORDER BY MASKLEN(network) DESC LIMIT 1;}"
+# }
+
+ #
+ # Use the network identifer to lookup the options specific to the
+ # originating network, using "network" context. Common network
+ # settings can be placed into a group and shared, with individual
+ # networks mapped to one or more option groups.
+ #
+ # - Place network-specific options in the dhcpreply table with
+ # "context = 'network'".
+ # - Add "Fall-Through := Yes" to the network options in the dhcpreply
+ # table to trigger group lookups for the network, which are
+ # disabled by default.
+ # - Place "identifier = <network_id>, groupname = <group>,
+ # priority = <priority>, context = 'network'" in the dhcpgroup
+ # table to map a network to a shared set of network options.
+ # - Place group-specific options in the dhcpgroupreply table with
+ # "context = 'network'".
+ #
+ # Note: In "shared-network" or "multinet" topologies you can instead
+ # just set all of the network options once in the subnet-specific
+ # options (after obtaining an IP address), below.
+ #
+# update control {
+# &DHCP-SQL-Option-Context := "network"
+# &DHCP-SQL-Option-Identifier := &control:Tmp-String-0
+# }
+# dhcp_sql.authorize
+
+
+ #
+ # Allocate IPs from the DHCP pool in SQL.
+ #
+ # Here we simply reuse the network_id (obtained previously) as the
+ # Pool-Name.
+ #
+# update control {
+# &Pool-Name := &control:Tmp-String-0
+# }
+# dhcp_sqlippool
+
+
+ #
+ # Subnet-specific options
+ #
+
+ #
+ # In "shared-network" or "multinet" topologies (in which a Layer 2
+ # network has a single pool that contains addresses from multiple
+ # subnets) it is necessary to set subnet-specific options based on the
+ # address that has just been allocated.
+ #
+ # Again, for this we need to derive a stable identifier for the subnet
+ # to which the IP address we are issuing belongs that will serve as a
+ # lookup key for the network options.
+ #
+ # Continuing our previous example, we can use a PostgreSQL query to
+ # find the subnet identifer in the row with the closest enclosing
+ # CIDR, which assumes a schema such as the following:
+ #
+ # CREATE TABLE fr_subnet_to_identifier (subnet CIDR, subnet_id TEXT)
+ #
+ # Note: An rlm_files based lookup of the subnet_identifier (as per the
+ # examples in the dhcp virtual server) is preferable to an ad hoc SQL
+ # query assuming that the network topology does not change frequently.
+ #
+# update control {
+# &control:Tmp-String-0 := "%{dhcp_sql:SELECT subnet_id \
+# FROM fr_subnet_to_identifier \
+# WHERE '%{reply:DHCP-Your-IP-Address}'::inet << subnet \
+# ORDER BY MASKLEN(subnet) DESC LIMIT 1;}"
+# }
+
+ #
+ # Use the subnet identifer to lookup the options specific to the
+ # subnet for the IP we are allocating, using "subnet" context. Common
+ # subnet settings can be placed into a group and shared, with
+ # individual subnets mapped to one or more option groups.
+ #
+ # - Place subnet-specific options in the dhcpreply table with
+ # "context = 'subnet'".
+ # - Add "Fall-Through := Yes" to the subnet options in the dhcpreply
+ # table to trigger group lookups for the subnet, which are
+ # disabled by default.
+ # - Place "identifier = <subnet_id>, groupname = <group>,
+ # priority = <priority>, context = 'subnet'" in the dhcpgroup
+ # table to map a subnet to a shared set of subnet options.
+ # - Place group-specific options in the dhcpgroupreply table with
+ # "context = 'subnet'".
+ #
+# update control {
+# &DHCP-SQL-Option-Context := "subnet"
+# &DHCP-SQL-Option-Identifier := &control:Tmp-String-0
+# }
+# dhcp_sql.authorize
+
+
+ #
+ # Host-specific and group-specific options
+ #
+
+ # "Groups" conventionally differentiate devices based on manual
+ # groupings using a device-specific identifier such as the MAC
+ # address.
+ #
+ # - Place host-specific options in the dhcpreply table with
+ # "context = 'group'".
+ # - Add "Fall-Through := Yes" to the device options in the dhcpreply
+ # table to trigger group lookups, which are disabled by default.
+ # - Place "identifier = <MAC-Address>, groupname = <group>,
+ # priority = <priority>, context='group'" in the dhcpgroup table
+ # to map a device to its groups.
+ # - Place group-specific options in the dhcpgroupreply table with
+ # "context = 'group'".
+ #
+# update control {
+# &DHCP-SQL-Option-Context := "group"
+# &DHCP-SQL-Option-Identifier := &request:DHCP-Client-Hardware-Address
+# }
+# dhcp_sql.authorize
+
+
+ #
+ # Class/subclass-specific options
+ #
+
+ #
+ # "Classes" conventionally differentiate devices based on all or part
+ # of one or more DHCP request options, or any combination of
+ # information that is available in the request or has already looked
+ # up from some datastore.
+ #
+ # Create multiple instances of the following block, one for each
+ # class. Differentiate between classes by setting
+ # DHCP-SQL-Option-Context uniquely.
+ #
+ # - Place "subclass"-specific options (i.e. each member of a class)
+ # in the dhcpreply table with "context = <class-name>".
+ # - For class-level options common to every member of a class,
+ # either:
+ # - Duplicate the options for each member of the subclass.
+ # or:
+ # - Add "Fall-Through := Yes" to each members options to trigger
+ # group lookups, which are disabled by default.
+ # - Map each member of the class to a group in the dhcpgroup
+ # table with context = '<class-name>';
+ # - Create the corresponding class in the dhcpgroupreply table
+ # with "context = '<class-name>'".
+ #
+# update control {
+# &DHCP-SQL-Option-Context := "class-vci-substring"
+# &DHCP-SQL-Option-Identifier := "%{substring %{request:DHCP-Vendor-Class-Identifier} 5 4}"
+# }
+# dhcp_sql.authorize
+
+}