DHCP Options and Selective Traffic Processing

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]).

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.

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

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.

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 DHCP 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.

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.

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
• Processing Order and Actions
• Benefits of DHCP Relay Forward-Only Action

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 1. 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 1: DHCPv4 and DHCPv6 Option Order