Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

DHCP Options and Selective Traffic Processing

DHCP Options and Selective Traffic Processing Overview

Subscriber management enables you to provide selective traffic processing based on information that is provided in the DHCP and DHCPv6 options string included in the traffic. Starting in Junos OS Release 15.1, the selective traffic processing feature lets you manage multivendor networks with the extended DHCP and DHCPv6 relay agent. You can enable the extended DHCP and DHCPv6 relay agent to compare option-specific strings received in DHCP client packets against a list of ASCII or hexadecimal strings that you configure on the router. The selective traffic processing feature allows you to identify traffic based on the option in the DHCP client packets, filter the traffic, and specify the action that the DHCP relay takes for the traffic. You can use DHCP options 60 and 77 and DHCPv6 options 15 and 16 to identify client traffic. You configure the action the router takes for the selected traffic, such as forwarding the traffic to a specific DHCP server, or dropping the traffic. DHCP relay agent selective traffic processing also allows you to specify a default action, which the router uses when no other action satisfies the configuration.

Using selective traffic processing is helpful in network environments where DHCP clients access services that are provided by multiple vendors and by multiple DHCP servers. For example, a DHCP client might gain Internet access from a particular DHCP server provided by one vendor, and access an IPTV service from a different DHCP server owned by a second vendor. Using the option-specific information in the DHCP client packets enables DHCP relay agent to differentiate between the two servers and to take the correct action for the subscriber.

You might also use selective processing to distinguish between services to different DHCP subscribers on the same interface. For example, a household might include two IP devices that obtain their IP addresses from the service provider’s DHCP server. The service provider might want to bind one of the devices to the incoming interface, sharing that address with other households. At the same time the service provider might want the second device to have its own filter and CoS capabilities. For this second device, the service provider can use selective processing to create a dynamic IP demux interface.

You can configure selective processing support globally or for a named group of interfaces. You can also configure the support for the extended DHCP relay agent on a per logical system and per routing instance basis.

To configure selective processing, you specify the DHCP or DHCPv6 option attribute that identifies the traffic, the match criteria used to filter the traffic, and the action to perform with the filtered traffic.

You can use the following DHCP options to selectively process client traffic:

  • DHCPv4 option 60 (Vendor Class Identifier)

  • DHCPv4 option 77 (User Class Identifier)

  • DHCPv6 option 15 (User Class Option)

  • DHCPv6 option 16 (Vendor Class Option)

You can configure exact match or partial match criteria to filter client traffic, and specify either the ascii option (to define a nonempty ASCII string of 1 through 255 alphanumeric characters) or the hexadecimal option (to define a hexadecimal string of 1 through 255 hexadecimal characters [0 through 9, a through f, and A through F]).

Best Practice:

Because of the format of DHCP option 77 and DHCPv6 option 16, we recommend you configure hexadecimal matching only with these two options instead of ASCII matching.

You can configure an unlimited number of match strings. If you configure a string as both exact match (equals) and a partial match (starts-with) criteria, the exact match takes precedence. Wildcard characters are not supported in exact match or partial match strings.

Use the following match criteria to filter client traffic:

  • equals—Your specified string is an exact match to the option string in client traffic.

  • starts-with—Your specified string is a subset of the option string in client traffic, starting with the left-most character. For example, your configuration of the string “test” is a subset of “test123” in the client’s option string, and matches the starts-with criteria.

  • default-action—The option string in client traffic does not satisfy any match criteria, or no match criteria are configured.

    Note:

    The default-action is optional. If the match criteria are not satisfied or not configured and there is no default-action configured, DHCP relay processes the traffic in the normal manner.

You can specify the following actions for the filtered client traffic:

  • drop—Discard the traffic.

  • forward-only—Forward the traffic, without creating a new subscriber session.

    Note:

    When you use the forward-only action, the only configured overrides operation supported is the trust-option-82 option. DHCP relay agent ignores all other overrides options that are configured.

  • local-server-group—Forward the traffic to the specified group of DHCP local servers that provides the requested client service. This option is not supported for DHCPv6 relay agent.

  • relay-server-group—Forward the traffic to the specified group of DHCP servers that provides the requested client service.

Using DHCP Option Information to Selectively Process DHCP Client Traffic

Starting in Junos OS Release 15.1, you can configure the DHCP relay agent to selectively process client traffic. Selective processing uses DHCP or DHCPv6 option information to identify, filter, and process client traffic. To configure DHCPv6 support you use the procedure at the [edit forwarding-options dhcp-relay dhcpv6] hierarchy level.

To configure DHCP relay agent to use option information to selectively process DHCP client traffic:

  1. Specify that you want to configure DHCP relay agent support.
  2. Specify that you want to use the DHCP option feature to selectively process incoming DHCP traffic.
  3. Specify the DHCP or DHCPv6 option number DHCP relay uses to identify and process the client traffic. You can specify options 60 and 77 for DHCP relay agent, and options 15 and 16 for DHCPv6 relay agent.

    For example, to identify traffic that has DHCP option 60 information:

  4. (Optional) Configure the default action that DHCP relay uses when the incoming client traffic does not satisfy any configured match or partial match criteria.

    For example, to configure DHCP relay to drop traffic by default:

  5. (Optional) Configure an exact match condition that filters the client traffic and specifies the associated action for DHCP relay agent to take.

    For example, to select traffic that has an option 60 ASCII string of video25, and then forward that traffic to a named local server group:

  6. (Optional) Configure a partial match condition that filters the client traffic and specifies the associated action.

    For example, to select traffic that has an option 60 hexadecimal string that starts with 766964656F (left to right), and then forward that traffic without creating a new session:

Displaying a Count of DHCP Packets That Are Dropped or Forwarded During Selective Processing That Is Based on DHCP Option Strings

To display the number of DHCP or DHCPv6 client packets that are dropped or forwarded during selective processing, use the following operational commands:

Example: Configuring DHCP Relay Agent Selective Traffic Processing Based on DHCP Option Strings

This example shows how to configure DHCP relay agent to use DHCP option strings to selectively identify, filter, and process client traffic.

Requirements

This example uses the following hardware and software components:

  • MX Series 5G Universal Routing Platforms or EX Series Switches

Before you configure DHCP relay agent selective processing support, be sure you:

Overview

In this example, you configure DHCP relay agent to use DHCP option strings in client packets to selectively identify, filter, and process client traffic. To configure selective processing, you perform the following procedures:

  1. Identify the client traffic—Specify the DHCP option that DHCP relay agent uses to identify the client traffic you want to process. The option you specify matches the option in the client traffic.

  2. Configure a default action—Specify the default processing action, which DHCP relay uses for identified client traffic that does not satisfy any configured match criteria.

  3. Create match filters and associate an action with each filter—Specify match criteria that filter the client traffic. The criteria can be an exact match or a partial match with the option string in the client traffic. Associate a processing action with each match criterion.

Configuration

To configure DHCP relay agent selective processing based on DHCP option information, perform these tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the command into the CLI at the [edit] hierarchy level.

Configuring DHCP Relay Agent To Selectively Process Client Traffic Based on DHCP Option Strings

Step-by-Step Procedure

To configure DHCP relay selective processing:

  1. Specify that you want to configure DHCP relay agent support.

  2. Specify the DHCP option that DHCP relay agent uses to identify incoming client traffic.

  3. Configure a default action, which DHCP relay agent uses when the incoming client traffic does not satisfy any configured match criteria.

  4. Configure an exact match condition and associated action that DHCP relay uses to process the identified client traffic.

  5. Configure a second exact match condition and associated action that DHCP relay uses to process client traffic.

  6. Configure a partial match criteria and associated action that DHCP relay uses to process client traffic.

Results

From configuration mode, confirm the results of your configuration by issuing the show statement at the [edit forwarding-options] hierarchy level. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To verify the status of DHCP relay agent selective traffic processing, perform this task:

Verifying the Status of DHCP Relay Agent Selective Traffic Processing

Purpose

Verify the DHCP relay agent selective traffic processing status.

Action

Display statistics for DHCP relay agent.

Meaning

The Packets forwarded field in the show dhcp relay statistics command output displays the number of client packets that have been forwarded as a result of the selective traffic processing configuration. In this example, the output indicates the total number of packets that DHCP relay agent has forwarded, as well as a breakdown for the number of BOOTREQUEST and BOOTREPLY packets forwarded.

Example: Configuring DHCP and DHCPv6 Relay Agent Group-Level Selective Traffic Processing

This example shows how to configure named interface group-based support for DHCPv6 relay agent selective processing, which uses DHCP option strings to identify, filter, and process client traffic.

This example describes DHCPv6 relay agent configuration—you can configure the related procedure for DHCP relay agent groups at the [edit forwarding-options dhcp-relay] hierarchy level. DHCPv6 selective processing supports DHCPv6 options 15 and 16. DHCP selective processing supports option 60 (MX Series routers only) and option 77.

Requirements

This example uses the following hardware and software components:

  • MX Series 5G Universal Routing Platforms or PTX Series Packet Transport Routers

Before you configure DHCPv6 relay agent selective processing support, be sure you:

Overview

In this example, you configure group-level DHCPv6 relay agent named interface support for selective processing of client packets based on DHCPv6 option strings. To configure selective processing, you perform the following procedures:

  1. Identify the client traffic—Specify the DHCPv6 option that DHCPv6 relay agent uses to identify the client traffic you want to process. The DHCPv6 option you specify matches the option in the client traffic.

  2. Configure the default action—Specify the default processing action, which DHCPv6 relay uses for identified client traffic that does not satisfy any configured match criteria.

  3. Create match filters and associate an action with each filter—Specify match criteria that filters the client traffic. The criteria can be an exact match or a partial match with the DHCPv6 option string in the client traffic. Associate a processing action with each match criteria.

Configuration

To configure group-level DHCPv6 relay agent selective processing based on DHCPv6 option information, perform these tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them in a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the command into the CLI at the [edit] hierarchy level. The quick configuration assumes that the named interface group and the DHCP server groups have been previously configured.

Configuring a DHCPv6 Relay Agent Named Interface Group To Selectively Process Client Traffic Based on DHCPv6 Option Strings

Step-by-Step Procedure

This procedure assumes that you have previously created the named interface group and the DHCPv6 server groups. To configure DHCPv6 relay group-level selective processing:

  1. Specify that you want to configure DHCPv6 relay agent support.

  2. Specify that you want to configure group-level DHCPv6 relay agent support.

  3. Specify the DHCPv6 option number that DHCPv6 relay agent uses to identify incoming client traffic.

  4. Configure the default action, which DHCPv6 relay agent uses when the incoming client traffic does not satisfy any configured match criteria.

  5. Configure an exact match condition and associated action that DHCPv6 relay uses to process the identified client traffic.

  6. Configure a second exact match condition and associated action that DHCPv6 relay uses to process client traffic.

  7. Configure a partial match criteria and associated action that DHCPv6 relay uses to process client traffic.

Results

From configuration mode, confirm the results of your configuration by issuing the show statement at the [edit forwarding-options dhcp] hierarchy level. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To verify the status of DHCPv6 relay agent selective traffic processing, perform this task:

Verifying the Status of DHCPv6 Relay Agent Selective Traffic Processing

Purpose

Verify the DHCPv6 relay agent selective traffic processing status.

Action

Display statistics for DHCPv6 relay agent.

Meaning

The Packets forwarded field in the show dhcpv6 relay statistics command output displays the number of client packets that have been forwarded as a result of the selective traffic processing configuration. In this example, the output indicates the total number of packets that DHCPv6 relay agent has forwarded, as well as a breakdown for the number of FWD REQUEST and FWD REPLY packets forwarded.

DHCP Message Exchange Between DHCP Clients and DHCP Server in Different VRFs

In some service provider networks, the service network in which the DHCP server resides is isolated from the actual subscriber network. This separation of the service and subscriber networks can sometimes introduce potential security issues, such as route leaking.

Starting in Junos OS Release 14.2, you can use the DHCP relay agent to provide additional security when exchanging DHCP messages between different virtual routing and forwarding instances (VRFs). The DHCP relay agent can ensure that there is no direct routing between the client VRF and the DHCP server VRF, and that only acceptable DHCP packets are relayed across the two VRFs. Subscriber management supports the cross-VRF message exchange for both DHCP and DHCPv6 packets.

To exchange DHCP messages between different VRFs, you must enable both the server-side and the client-side of the DHCP relay agent to recognize and forward acceptable traffic based on DHCP option information in the packets. The message exchange uses the following DHPP options to identify the traffic to be relayed.

  • Agent Circuit ID (DHCP option 82 suboption 1) for DHCPv4 packets

  • Relay Agent Interface-ID (DHCPv6 option 18) for DHCPv6 packets

Statistics for DHCP packets using the cross-VRF message exchange are counted in the client VRF.

The following list describe how DHCP relay agent exchanges messages between the DHCP clients and DHCP server in different VRFs:

  • Packets from DHCP client to DHCP server—DHCP relay agent receives the DHCP packet from the client in the client VRF, and then inserts the appropriate DHCP option 82 suboption 1 or DHCPv6 option 18 attribute into the packet. The relay agent then forwards the packet to the DHCP server in the server’s VRF.

  • Packets from DHCP server to DHCP client—DHCP relay agent receives the DHCP reply message from the DHCP server in the server VRF. The relay agent derives the client’s interface, including VRF, from the DHCP option 82 suboption 1 or DHCPv6 option 18 attribute in the packet in the DHCP server VRF. The relay agent then forwards the reply message to the DHCP client in the client’s VRF.

Configuring DHCP Message Exchange Between DHCP Server and Clients in Different Virtual Routing Instances

Starting in Junos OS Release 14.2, you can configure DHCP relay agent to provide additional security when exchanging DHCP messages between a DHCP server and DHCP clients that reside in different virtual routing and forwarding instances (VRFs).

You can configure DHCP relay agent to provide additional security when exchanging DHCP messages between a DHCP server and DHCP clients that reside in different virtual routing instances. This type of configuration is for a stateless DHCP relay connection between a DHCP server and a DHCP client, when the DHCP server resides in a network that must be isolated from the client network.

A stateless DHCP relay agent does not maintain dynamic state information about the DHCP clients and does not maintain a static route for the traffic to flow between the client and server routing instances.

To enable the DHCP message exchange between the two VRFs, you configure each side of the DHCP relay to recognize and forward acceptable traffic based on the DHCP option information in the packets. The acceptable traffic is identified by either the Agent Circuit ID (DHCP option 82 suboption 1) for DHCPv4 packets or the Relay Agent Interface-ID (DHCPv6 option 18) for DHCPv6 packets.

The following list provides an overview of the tasks required to create the DHCP message exchange between the different VRFs:

  • Client-side support—Configure the DHCP relay agent forward-only statement to specify the VRF location of the DHCP server, to which the DHCP relay agent forwards the client packets with the appropriate DHCP option information. The forward-only statement ensures that DHCP relay agent does not create a new session or perform any other subscriber management operations (such as creating dynamic interfaces or maintaining leases).

    You can optionally configure a specific logical system and routing instance for the server VRF. If you do not specify a logical system or routing instance, then DHCP uses the local logical system and routing instance from which the configuration is added.

  • Server-side support—Configure the DHCP relay agent forward-only-replies statement so the DHCP relay agent forwards the reply packets that have the appropriate DHCP option information. This statement also ensures that DHCP relay agent does not create a new session or perform any other subscriber management operations.

    Note:

    You do not need to configure the forward-only-replies statement if the DHCP client and DHCP server reside in the same logical system/routing instance.

  • DHCP local server support—Configure the DHCP local server to support option 82 information in DHCP NAK and forcerenew messages. By default, the two message types do not support option 82.

  • Additional support—Ensure that the following required support is configured:

    • Proxy ARP support must be enabled on the server-facing interface in the DHCP server VRF so that the DHCP relay agent can receive and respond to the ARP requests for clients and the client-facing interface in the DHCP server VRF.

    • Routes must be available to receive the DHCP packets from the DHCP server in the server VRF for the clients reachable in the client VRF.

The following procedures describe the configuration tasks for creating the DHCP message exchange between the DHCP server and clients in different VRFs.

Client-Side Support

To configure support on the client side of the DHCP relay agent:

  1. Enable DHCP relay agent configuration.
  2. Specify the DHCP server VRF to which the DHCP relay agent forwards the packets from the DHCP client. DHCP relay agent forwards the acceptable packets that have the appropriate DHCP option information, but does not perform any additional subscriber management operations. You can configure the forward-only statement globally or for a named group of interfaces, and for DHCPv4 or DHCPv6. You can specify the current, default, or a specific logical system or routing instance for the server VRF.

    The following example configures the forward-only statement globally for DHCPv4, and specifies the default logical system and routing instance:

Note:

For local DHCPv4 clients, the DHCP relay agent adds the Agent Circuit ID option. However, if the Agent Circuit ID option is already present in the packet, you must ensure that the DHCP server supports the option 82 Vendor-Specific Information suboption (suboption 9).

If the forward-only statement is configured at the [edit forwarding-options dhcp-relay relay-option] hierarchy level, then that relay-option action takes precedence over the configuration of the forward-only statement for the DHCP cross-VRF message exchange.

Server-Side Support

To configure the cross-VRF message exchange support on the server side of the DHCP relay:

Note:

You do not need to configure the forward-only-replies statement if the DHCP client and DHCP server reside in the same logical system/routing instance.

  1. Enable DHCP relay agent configuration.
  2. Configure the DHCP relay agent to forward the DHCP packets from the DHCP server VRF to the client. DHCP relay agent only forwards the packets, and does not perform any additional subscriber management operations. You can configure the forward-only-replies statement globally for DHCPv4 and DHCPv6.

    The following example configures the forward-only-replies statement globally for DHCPv4.

DHCP Local Server Support

To configure the DHCP local server to support option 82 information in NAK and forcerenew messages; the cross-VRF message exchange feature uses the option 82 or DHCPv6 option 18 information to determine the client VRF:

  1. Enable DHCP local server configuration.
  2. Specify that you want to configure an override option.
  3. Configure DHCP local server to override the default behavior and support option 82 information in DHCP NAK and forcerenew messages. You can configure the override action globally, for a group of interfaces, or for a specific interface.

DHCP-Initiated Service Change Based on Remote ID

Subscriber management enables you to update a DHCP client’s current service through the use of the client’s remote ID (Agent Remote ID). The remote ID can be in option 82, suboption 2 for DHCPv4 clients, or option 37 for DHCPv6 clients.

When a DHCP client is initially established, DHCP preserves the client’s incoming remote ID in the DHCP client database. When receiving a rebind or renew message for that client, DHCP compares the client’s initial remote ID to the remote ID in the DHCP renew or rebind message. If the two remote IDs do not match, DHCP local server tears down the existing binding and sends a NAK message (or logical NAK for DHCPv6), which causes the client to initiate a reconnect sequence. When the client reconnects, the DHCP local server activates the new service, which is encoded within the new Agent Remote ID string.

You can configure the router to support the remote ID service change feature globally or for a specific group, and you can configure the support on DHCP local server and DHCP relay agent.

In a dual-stack environment, the DHCP-initiated service change feature requires that a client’s DHCPv4 and DHCPv6 sessions reside over the same VLAN (1:1 mapping) and that the Agent Remote ID strings for the two sessions are identical. The dual-stack support also requires that the same dynamic client profile is applied to both the DHCPv4 and DHCPv6 networks, to ensure remote ID consistency between the two networks. When DHCP detects a remote ID mismatch in one session of the dual stack, DHCP tears down that session. The incoming remote ID is then compared to the other session of the dual stack, and if there is a mismatch, that other session is torn down gracefully.

During the graceful teardown process, if the other session is currently in the bound state, that session then transitions to the deferred delete state. The deferred delete state allows the session that detected the change to be reestablished immediately with the new service plan, while enabling the router to gracefully tear down the other session by sending NAK messages in response to the subsequent renew and rebind messages.

As part of the DHCP-initiated service change feature, AAA can set a session’s client profile. AAA obtains the client profile from the remote-ID, and writes the profile into the session database. A client profile that AAA writes into the database always takes precedence over any local DHCP configuration.

A change in the Agent Remote ID can also initiate a service change during reauthentication. You cannot configure both the remote-id-mismatch statement and the reauthenticate statement at the global level, [edit system services dhcp-local-server]. However, DHCP precedence rules do permit you to configure both statements when they are at different levels. For example, you can configure reauthenticate at the global level and remote-id-mismatch for DHCPv6 at the [edit system services dhcp-local-server dhcpv6] hierarchy level or for a specific group at the [edit system services dhcp-local-server group name] hierarchy level, and so on.

Benefits of DHCP-Initiated Service Change Based on Remote ID

  • Enables DHCP server or relay agent to update the client’s service when based on the remote ID when the client remote ID changes and does not match the previously stored agent remote ID. In a dual-stack environment, enables the DHCP server or relay agent to help ensure the remote ID consistency between sessions of the dual stack.

Configuring DHCP-Initiated Service Change Based on Remote ID

This topic describes how to configure support for DHCP-initiated service change on the DHCP local server and the DHCP relay agent.

Configuring DHCP local server

You can configure support for DHCP-initiated service change for DHCP local server and DHCPv6 local server globally, or for a named group of interfaces.

To configure DHCP local server to support DHCP-initiated service change for a named group:

  1. Before starting the configuration for the DHCP-initiated service change feature, ensure that the DHCP or DHCPv6 relay agent is configured to override the default behavior and send a release message to the DHCP server when a remote ID mismatch occurs. This configuration is required because the relay agent cannot directly tear down client bindings; the release packet signals the DHCP server to tear down the original binding.
  2. Specify that you want to configure DHCP local server.
  3. Specify the named group that you want to configure.
  4. Specify that, for the named group, DHCP local server matches the initial and new client remote IDs, and then performs the disconnect action when a mismatch occurs.

    When a mismatch occurs, DHCP local server tears down the existing binding and sends a NAK message to the client, which initiates the client reconnect sequence. The new service, which is encoded in the Agent Remote ID string, is then activated when the client reconnects.

Configuring DHCP relay agent

You can configure support for DHCP-initiated service change for DHCP relay agent and DHCPv6 relay agent globally, or for a named group of interfaces.

The following example shows the steps to configure DHCPv6 relay agent to support DHCP-initiated service change on a global basis.

  1. Before starting the configuration for the DHCP-initiated service change feature, ensure that the DHCPv6 relay agent is configured to override the default behavior and send a release message to the DHCP server when a remote ID mismatch occurs. This configuration is required because the relay agent cannot directly tear down client bindings; the release packet signals the DHCP server to tear down the original binding.

  2. Specify that you want to configure DHCP relay agent.

  3. Specify that you want to configure DHCPv6 relay agent.

  4. Specify that DHCPv6 relay agent matches the initial and new client remote IDs, and then performs the disconnect action when a mismatch occurs.

    When a mismatch occurs, DHCPv6 relay agent sends the release message to the DHCPv6 local server and a logical NAK message (a reply packet with a 0 lifetime) to the client. The server then tears down the existing binding, and the client initiates the reconnect sequence. The new service, which is encoded in the Agent Remote ID string, is activated when the client reconnects.

DHCPv4 and DHCPv6 Forward-Only Action for Relay Traffic with Unknown DHCP Server Address

The DHCP relay agent entry, which can be created on a DHCPv4 or DHCPv6 server, is useful for authentication, authorization, accounting, applying filtering, ensuring quality of service (QoS) on the client, and processing of options specified in the packet. The creation of the relay agent or client entry involves participation of the jdhcpd process memory resources, session database resources, authentication procedure, accounting, dynamic profile instantiation, dynamic interface creation, firewall, class-of-service (CoS)-association, and more. Customer networks can contain non-customer controlled bindings for which they might not want these relay agent entry functionalities. When a customer's network has such traffic, creation of relay agent entries—which is related to client entry creation—unnecessarily utilizes resources and can also result in wrong association of profiles, because in the current network scenario, all the traffic received from a specific interface is forwarded, without processing any destination address.

Starting in Junos OS Release 17.4R1, a forward-only configuration can be enabled on the broadband network gateway (BNG) device for non-customer traffic along with unknown DHCP server address. The configuration of the forward-only statement, along with the new DHCP options—option-54 for DHCPv4 and option-2 for DHCPv6, avoids the creation of the DHCP relay agent entry on the BNG and ensures that traffic is forwarded to the specified destination address.

With these configurations, administrators are able to determine to which servers the clients are bound; which of the clients need to have a relay client entry created and dynamic profile and policies applied, and so on; and for whom (non-customer) the forward-only configuration is enabled.

The two new configuration statements—options-54 and options-2—are introduced for processing destination addresses.

Processing of DHCPv4 and DHCPv6 Destination Addresses

Administrators can configure the forward-only statement to avoid the creation of non-customer client entries. The jdhcpd process compares the server identifier (option-54 for DHCPv4 and option-2 for DHCPv6) with or without destination address in the incoming packet along with the configured server address. If the server identifier and configured server address match, the action is to only forward without creating the client entry.

On nonpassive relay, configuration of the server-match statement means implicit enabling of the delay-authentication statement for the clients for which the server-match statement is processed. You can also configure options 60 and 77 (for DHCPv4) or options 15 and 16 (for DHCPv6) optionally together with associated processing. Configuration of these options also includes the specification of the order in which they are processed. If these options are not configured, the default order is 60, 77 for DHCPv4 and 15, 16 for DHCPv6.

Note:

DHCPv6 option-16 data as defined in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6), comprises a 4-byte enterprise number and the variable length vendor-class data. The enterprise number is a number registered by the vendor with IANA. As such, it is anticipated that configuring an ASCII match in conjunction with option-16 relay-option match might not work because the enterprise number must coincide with the value of a printable ASCII character.

A similar restriction exists for DHCPv4 option-77 statement because the option-77 data might be subdivided to include suboptions and sublengths. Because of this, configuring an ASCII match with option-77 relay-option match might not work.

On nonpassive relay, if a request packet is received in the rebind phase and the corresponding relay entry is not present, then you need to first configure the bind-on-request statement, following which the relay entry is created and the packet is forwarded. After an acknowledgment is received, the jdhcpd process verifies the source address (with or without option 54 for DHCPv4 and option 2 for DHCPv6) within the server-match configuration. If the verification results in a stateless entry, then the relay entry is deleted.

The administrator can specify the DHCP unique identifier (DUID) with or without the address of a server. The jdhcpd process first processes address statements and then the DUID statements. If the same server address is specified in address statements and the DUID statement, then it is the administrator’s responsibility to specify the same action for both address and the DUID statements.

On both passive and nonpassive relays, if the received packet contains a relay forward header and the destination address is multicast or a link-local address, then the packet is forwarded without any further processing.

Note:

For both DHCPv4 and DHCPv6 subscribers, the relay-option and server-match statements are at the same hierarchy and have the same priority.

Processing Order and Actions

Relay options and server match processing are mutually exclusive. Although they are at the same hierarchy and have the same priority, for implementation purpose, you process relay options followed by server match.

Following are the DHCPv4 relay option processing actions:

  • drop—Discard when there is a match.

  • forward-only—Forward without client services, when there is a match.

  • local-server-group—Name of DHCP local server group when there is a match.

  • relay-server-group—Name of DHCP relay server group when there is a match.

Following are the DHCPv6 relay option processing actions:

  • drop—Discard when there is a match.

  • forward-only—Forward without client services, when there is a match.

  • relay-server-group—Name of DHCP relay server group when there is a match.

Note:

The DHCPv6 server match for IPv6 address is available in passive relay only.

The default and configurable option orders are processed as shown in Figure 9. If you need the option order to be reversed (either DHCPv4 or DHCPv6), then configure option-order 77,66 statement for DHCPv4 or option-order 16,15 statement for DHCPv6 at the [edit forwarding-options dhcp-relay relay-option] hierarchy level.

Figure 9: DHCPv4 and DHCPv6 Option OrderDHCPv4 and DHCPv6 Option Order

Benefits of DHCP Relay Forward-Only Action

  • Reduces the unnecessary consumption of resources for non-customer controlled bindings that do not need the relay agent entries made when client entries are created.

Release History Table
Release
Description
15.1
Starting in Junos OS Release 15.1, the selective traffic processing feature lets you manage multivendor networks with the extended DHCP and DHCPv6 relay agent.
15.1
Starting in Junos OS Release 15.1, you can configure the DHCP relay agent to selectively process client traffic.
14.2
Starting in Junos OS Release 14.2, you can use the DHCP relay agent to provide additional security when exchanging DHCP messages between different virtual routing and forwarding instances (VRFs).
14.2
Starting in Junos OS Release 14.2, you can configure DHCP relay agent to provide additional security when exchanging DHCP messages between a DHCP server and DHCP clients that reside in different virtual routing and forwarding instances (VRFs).