DHCP

The DHCP view presents the scaffolds associated with configuring the DHCP server and DHCP relay features of the rXg.

The rXg integrates a fully featured DHCP server capable of meeting the needs of nearly any imaginable environment. By default, the rXg DHCP server responds to all DHCP requests on the LAN with a temporary address assignment from within a pool. This behavior may be modified and augmented via the scaffolds presented on this view to deliver a broad spectrum of possible responses.

To enable the rXg integrated DHCP server, the operator must create a DHCP pool that falls within the CIDR of an address that is on the LAN of the rXg. An address is considered to be on the LAN of the rXg if the address is associated with an Ethernet interface , VLAN or is the destination in a static route.

The CIDR of the address from which the pool draws IP addresses from automatically determines the DHCP server listening interface as well as the subnet mask and default route that is presented to the client.

For example, given an rXg that has the following addresses :

• Ethernet Interface en1: 192.168.5.1 / 24
• VLAN 3800: 172.16.16.1 / 22 If a DHCP pool for with a range of 192.168.5.100 to 192.168.5.200 is created, the rXg integrated DHCP server will listen on en1 for DHCP requests in the native VLAN and respond with:
• IP address in range 192.168.5.100 to 192.168.5.200
• subnet mask 255.255.255.0
• default gateway 192.168.5.1 Similarly, if a pool with a range of 172.16.23.1 to 172.16.28.255 is created, then DHCP requests present on VLAN 3800 will see a response of:
• IP address in range 172.16.23.1 to 172.16.28.255
• subnet mask 255.255.240.0
• default gateway 172.16.16.1

Many networks combine DHCP assigned addresses with manually assigned static addresses. Use the pools scaffold to control the range of addresses issued by the rXg. It is extremely important to ensure that network administrators manually configure statically assigned addresses correctly to prevent overlap. It is also suggested that VLANs be used for L2 segregation of machines with statically assigned addresses from those pulling from DHCP in order to prevent IP address collisions. Alternatively, the network operator may choose to use DHCP fixed hosts in lieu of statically assigned addresses to achieve the same goal.

In most networks, there are some devices which should obtain the same IP address every time a request is made. A common occurrence of this is when a Static IP has been configured for a device that is using DHCP. To ensure connectivity, the BiNAT'ed device must have a static IP address or must be established as a fixed host. It is important to make sure that fixed hosts are assigned IP addresses that are outside of the ranges specified by the pools

Two, non-overlapping pools may also be configured for the same Ethernet interface or VLAN. Given the example rXg network address configuration above, 172.16.23.1 to 172.16.28.1 and 172.16.20.1 to 172.16.22.255 may both be configured as pools simultaneously. By default, requests originating from VLAN 3800 will draw addresses from both pools. This behavior is usually modified through the use of classes and match rules.

Match rules may be used to differentiate between requests originating from the same physical or logical media. For example, match rules may be used to associate devices presenting DHCP client identifiers containing a specific prefix with a class. Another common use of match rules is to place all devices presenting a MAC address from a specific vendor into a class.

A class may be used to determine the pool from which the requesting device acquires an address. This is useful for IP-based policy management as certain devices may be placed into specific ranges of IP addresses which can have different policies associated with them. In addition, different pools may have different DHCP options. For example, pools may have different maximum lease times, DNS servers, default routes, etc.

If there is a LAN CIDR block configured on the rXg for which there is no pool , the rXg may also be configured as a DHCP relay server. This feature enables a DHCP proxy server on the rXg that forwards DHCP requests originating from the associated Ethernet interface or VLAN to an external DHCP server.

Pools

An entry in the DHCP Pools scaffold configures a pool of IP addresses that are to be offered to end-user devices requesting an IP address.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The start IP and end IP fields define the range of addresses to be offered by this pool. The pool of offered addresses must fall within the range of an IP network configured on an interface and must not include the address(es) consumed by the rXg or the broadcast address. For example, if the 192.168.5.1/24 IP network is configured on the LAN, the maximum allowable range is from the start IP of 192.168.5.2 to the end IP of 192.168.5.254.

It is critically important to be very precise when entering these values to prevent IP address conflicts. Some of the many things to keep in mind include:

• Devices with statically assigned IP addresses must not use addresses within the DHCP pool range.
• IP address reservations (specified in the fixed hosts scaffold) must not be in the pool.
• The pool ranges must be large enough to accommodate the end-user population.

The Reserved options let you specify addresses you wish to reserve either at the begining of each subnet in the pool via the First field or at the end of the subnet via the Last field. For example a network address consisting of 32 /24 subnets (x.x.0.1/24 - x.x.31.1/24 (32)) setting the First field to 4 would reserve x.x.0.2 - x.x.0.5 in the first subnet and .2 - .5 in each subsequent subnet. Setting the Last field to 4 would reserve x.x.0.251 - x.x.0.254 in the first subnet and 251 - 254 in each subsequent subnet. The Router field can change the gateway IP in each subnet. Incremented from the network address, where 1 is the first usable IP address (e.g. x.x.x.1/24). Decremented from the last usable address, where -1 means the last host address (e.g. x.x.x.254/24).

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The option group and class fields link this DHCP pool with options and configuration rules. For example, the WINS server DHCP option can be transmitted to only those end-users running Window through the use of the option group and class fields.

Fixed Hosts

An entry in the Fixed Hosts scaffold reserves an IP address for a particular device. When a device with the MAC address specified in this record requests network configuration via DHCP, the specified IP address is offered. This mechanism is often used as an alternative to manually assigning static IP addresses to devices.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The IP field contains the IP address to be reserved for this device. It is critically important that the reserved IP be outside of any pools specified in the pools scaffold.

The MAC field contains the MAC address of the device that this reservation is being held for.

The hostname field is an optional parameter that, if specified, will cause the DHCP server to deliver a client identifier to the device via a DHCP option.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The option group links this reservation with a set of DHCP options that control additional information that may be delivered to the device beyond IP address, hostname, subnet mask and gateway. For example, an option group may be used to specify alternative DNS servers for the device specified in this reservation.

Option Groups

An entry in the option groups scaffold links one or more options to devices that are offered addresses from a pool or set of fixed hosts. When an option is linked, the specified payload will be delivered as part of the DHCP response offered to a requesting device. The use of option groups to link options to pools and fixed hosts maximizes the flexible reuse of configuration options.

The global check box links the associated options with all DHCP responses. Only a single option group can have the global field checked. Furthermore, the global checkbox should be used in exclusion to linking any specific pools and fixed hosts and vice versa.

The authoritative check box indicates whether or not the DHCP server should be authoritative for the network(s) its attached to. An authoritative DHCP server will assume that the configuration information about a given network segment is known to be correct and authoritative, and thus will send DHCPNAK messages to misconfigured clients. Operators setting up DHCP servers for their networks should usually have this checked to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time. For certain cluster deployment configurations it is necessary to put the server in non authoritative mode. For example, when two or more cluster nodes are performing the role of the DHCP server on the same network. This is so that the nodes do not NAK each others lease assignments.

The BOOTP check box allows or denies address assignment from the related pool(s) for BOOTP clients.

The options field specifies the members of the options scaffold that will be linked to the targets specified in this option groups record.

The pools and fixed hosts fields specify targets for receiving the DHCP configuration options specified by the options fields.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Options

An entry in the options scaffold establishes a key-value pair that can be appended to any DHCP response via an option group.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The standard option field specifies the DHCP option that is to be defined by this record. The purpose of the vast majority of the DHCP options is easily derived by the name. The set of all available standard DHCP options is defined by IETF RFC 2132. The custom option field enables the operator to deploy DHCP options that are not part of IETF RFC 2132.

The name makes the purpose of the option self evident in many cases. Here are some common required use cases:

routersWhen the rXg integrated DHCP server is responding to requests originating from a network that is L2 connected to the rXg, the DHCP server automatically populates the response with a next hop router specified as the rXg. However, if the rXg integrated DHCP server is responding to requests on a network that is L3 connected behind a router, the routers option must be specified. In general, it is not possible to automatically determine the IP address of the next hop router that faces the clients being served DHCP, hence the requirement for manual specification.tftp-server-nameCertain forms of customer premises equipment require BOOTP or TFTP provisioning (e.g., DOCSIS cable modems or WiMAX subscriber terminals). To accommodate this, the rXg incorporates a TFTP server and supports the delivery of DHCP responses with the requisite options. The value of the tftp-server-name option should be the IP address of the rXg that is closest to the end-user.

The value is the value that will be used when the key-value pair is appended to the DHCP request. For example, if max-lease-time is chosen as the option name for a record, the option value should be set to the maximum number of seconds that a DHCP lease can be used by a end-user device.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The option group field determines which DHCP responses will contain the key-value option pair configured in this record.

The following DHCP client options are currently supported:

The following DHCP server options are currently supported:

Custom DHCP Options

The vast majority of client devices require only basic DHCP in order to achieve network connectivity. Some operators may choose to use standard DHCP options that are defined in IETF RFC 2132 to deliver specific additional configuration. Standard DHCP options may be configured via the DHCP Options scaffold. Between basic DHCP and standard options almost all client devices will get everything they need. Infrastructure devices are a different story.

In some cases certain kinds of devices may require configuration to be delivered via non-standard DHCP options. This usually applies to thin, headless infrastructure devices that depend on a central controller or server such as VoIP handsets, VoD set top boxes, wireless access points, etc. Specialized infrastructure devices. Custom DHCP Options are usually used to deliver bootstrap configuration information such as the IP address and filestore location of initial bootstrap configuration.

The Custom DHCP Options scaffold enables operators to configure the rXg to deliver DHCP options that are not defined byIETF RFC 2132. Each record in the Custom DHCP Option scaffold adds an option to the custom option drop down list in the DHCP Options scaffold. The payload ( value ) to be delivered to the device is configured in the DHCP Options scaffold.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The type , array and code fields enable the operator to define the headers in the DHCP option that is to being defined. When the array checkbox is enabled, the option will be defined as an array of the type designated. The values of the corresponding DHCP Options should be entered in comma separated format. DHCP vendor-specific option 43 as well as DHCP site-specific option codes between 128 to 254 may be configured to be delivered by the rXg. The exception to this is option 121, classless-static-routes. Static routes may be provided to clients by creating a custom DHCP option and specifying the type as an array of unsigned integer 8, and a code of 121. The value of the corresponding DHCP Option record may be 24,192,168,99,10,10,10,1, 24,172,16,32,10,10,10,2. This would provide a route to 192.168.99.0/24 via 10.10.10.1 and a route to 172.16.32.0/24 via 10.10.10.2. Refer to IETF RFC 3442 for more information.

If the operator desires to deliver payloads via vendor-specific DHCP option 43 then the type should be set to vendor-specific. In this case the code field should be configured to be the DHCP option sub-code that is desired. The settings of the type to vendor-specific implicitly defines the format of the payload to be hex. The payload that is configured by the value field in associated the DHCP Option will be automatically converted to hex from ASCII before being encoded into the option packet.

If the operator sets the type to anything other than vendor-specific then the code represents the site-specific DHCP option that must be between 128 and 254. This limitation is due to the fact that IETF RFC 2132 has already defined DHCP option codes from 0 to 127. The exception to this is the classless-static-routes option, code 121.

The payload of the Custom DHCP Option is defined in the option field of the DHCP Options scaffold and must fall within the range of acceptable possibilities for the given type.

Classes

An entry in the classes scaffold links one or more match rules to devices that are offered addresses from pools. When a match rule is linked, the specifications in the match rule are used to determine membership of the class.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

Classes are used to differentiate groups of clients based on matching a substring transmitted as part of the DHCP request or the MAC address of the requesting device. If two pools are created within the network address range associated with a single interface (e.g., 192.168.5.100-150 and 192.168.5.151-200), classes can then be used to populate devices into one of the two ranges based on the request. For example, all requesting devices presenting a dhcp-client-identifier with a well known predefined prefix can be put into the first pool while all others into the second pool. This alleviates the need to collect and enter the MAC addresses of all devices in a group as fixed hosts in order to place them into a pool.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The pools fields specifies the pool to place devices into that meet the criteria of the match rules specified by this class.

The match rules field links this class with the match rules that will determine membership.

Match Rules

An entry in the match rules scaffold creates a criteria for selecting DHCP requests to be a member of a class.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The negate field configure the way the match rule specified by this record behaves. If negate is checked, a DHCP request is considered to be part of a class if it does not meet criteria specified by this match rule.

The logic field controls the way multiple match rules belonging to the same class behave. A setting of andrequires that all criteria be met. Conversely, a setting of orallows a request to become part of a class if only one of the match rule criteria is met.

The option substring , substring offset and substring length fields control the matching criteria specified in the option value field. If option substring is unchecked, the data in the option value field must exactly match the payload of the DHCP option in the request in order for the request to be considered a match by this match rule. Inversely, if option substring is checked, the substring offset and substring length fields can be used to make a request considered a match if only a portion of the data in option value matches what is presented in the DHCP request. The values that are matched in the option substring are inclusive of the specified boundaries.

The option name and option value are the criteria that determine whether or not a request is a match for this rule. If a DHCP request contains a DHCP option name-value pair matching the data entered into option name and option value , then the DHCP request is considered a match for this rule.

For example, let us consider the case where the RGN distribution infrastructure is DOCSIS cable and composed of Motorola SURFboard cable modems with MAC prefix 00:0A:28, In order to simplify administration, the operator wishes to give all of the cable modems addresses in the 192.168.10.0/24 block and serve 172.16.16.0/24 to the end-users. To accomplish this, the operator would need to configure both DHCP pools and then associate the 172.16.16.0/24 pool with a class that has a match rule configured with:

• option substring - checked
• substring offset - 1
• substring length - 3
• option name - hardware
• option value - 000A28 At first glance, this would seem to be incorrect because we want to match the zeroth through the second byte of the MAC address inclusive. However, the hardware field has the Ethernet prepended onto the MAC address as the zeroth byte. Therefore the actual MAC address is the first to the seventh of the _hardware_field.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The class field specifies the class for which this matching rule should be used to determine membership.

Relay Servers

An entry in the Relay Servers scaffold enables the DHCP relay feature for the specified interface. DHCP relay allows an rXg to proxy DHCP requests to an upstream DHCP server rather than managing a DHCP pool locally. DHCP relay cannot be used in conjunction with the DHCP server (pools and fixed hosts).

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The server IP field configures the IP address of the upstream DHCP server that will respond to the proxy DHCP requests.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The interfaces and VLANs fields specify the local physical and logical interfaces to proxy DHCP requests to the server specified by server IP.