DHCP client

A host on an IP network can use BOOTP or DHCP to obtain its IP address from a BOOTP or DHCP server. To obtain the address, the client sends a BOOTP or DHCP request.

The request is a subnet directed broadcast and is addressed to UDP port 67. A limited IP broadcast is addressed to IP address and is not forwarded by the Ruckus Layer 3 switch or other IP routers. When the BOOTP or DHCP client and server are on the same network, the server receives the broadcast request and replies to the client. However, when the client and server are on different networks, the server does not receive the client request, because the Layer 3 switch does not forward the request.

You can configure the Layer 3 switch to forward BOOTP or DHCP requests. To do so, configure a helper address on the interface that receives the client requests, and specify the BOOTP or DHCP server IP address as the address you are helping the BOOTP or DHCP requests to reach. Refer to Configuring an IP helper address. Instead of the server IP address, you can specify the subnet directed broadcast address of the IP subnet the server is in.

The DHCP client supports the dynamic IP address allocation method, where an IP address is assigned to a client for a limited period of time (or until the client explicitly relinquishes the address). Permanent IP address allocation to the hosts and statically assigned IP addresses are not supported.

Ruckus devices support a DHCP client on physical ports, LAG ports, Virtual Ethernet ports, and Control Bridge (CB) ports (802.1BR-enabled). The DHCP client is not supported on tunnel ports, stacking ports when stacking is enabled, or PE ports in 802.1BR-enabled Ruckus devices.

On a Layer 3 device, DHCP over a Virtual Ethernet port is supported only for the default Virtual Ethernet port. The DHCP client is disabled on other VIrtual Ethernet ports.
On a Layer 3 device, DHCP client support for PE ports on 802.1BR-enabled Ruckus devices includes the ability to participate in the initial DHCP IP discovery phase to create a default Virtual Ethernet port. However, because PE ports are considered Layer 2 switching ports, they cannot be assigned an IP address. Refer to "Default Virtual Ethernet port creation" in this document for more information.

The DHCP client is enabled by default at bootup on all Ruckus devices.

DHCP over default Virtual Ethernet port (Layer 3 devices)

The following enhancements mimic the behavior of a Layer 2 device when it is running the Layer 3 image:
  • The ICX device is managed even during cable movement from one in-band interface port to another.
  • Network devices that are connected downstream through an ICX device are managed no matter what ports are connected, as long as the downstream ports belong to the default Virtual Ethernet port.
  • Using DHCP, acquiring IP or upgrade configuration is zero-touch.
  • By default, the ICX device allows traffic to pass across all ports (reachability).
  • A single MAC adress per system is used for IP discovery, which allows the same IP address to be used all the time.

Default Virtual Ethernet port creation (Layer 3 devices)

DHCP server is reachable through a physical port, and, if option 43 VSI is configured on the DHCP server, DHCP server exchange option 43 Vendor Specific Info (VSI), “Create default VE” [not case sensitive], is sent through a DHCPACK message. A Ruckus device configured as a DHCP client matches the VSI string and creates the default Virtual Ethernet port.
To create a Virtual Ethernet port, at least one port must be a member of the default VLAN of the device.

If Virtual Ethernet port creation is successful, the IP address that is acquired through the physical port is released, and an IP address will be re-acquired through the default Virtual Ethernet port.

The index of the default Virtual Ethernet port is the first available index. For example, on a device with no startup configuration, the default Virtual Ethernet port will have an index of 1.

If default Virtual Ethernet port creation fails, the IP address acquired will be assigned to the physical interface port or ports connecting the DHCP server if the connecting ports are Layer 3 ports.

Possible Reasons for Failure of Virtual Ethernet Port creation. The member ports of the default VLAN are queried to check for certain configured items. If any of the items are found, default Virtual Ethernet creation fails without other conditions being checked. These configured items result in failure:
  • IP routing
  • vrf
  • ip policy
  • route-only
  • rpf-mode
  • ip-mac

DHCP client in continuous discovery mode (Layer 2 and Layer 3 devices)

Beginning with release 08.0.61, the DHCP-client discovery process starts automatically when the system boots up and runs in a continuous manner.

DHCP Discovery is attempted 5 times based on the exponential back-off algorithm, as per RFC 2131. Retries occur at these intervals: x+4 seconds, where x is the starting system time, x+8 seconds, x+16 seconds, x+32 seconds, and x+64 seconds. After the DHCP client reaches the maximum retransmission delay of 64 seconds, it waits 2 seconds and then restarts the discovery process. The five-interval cycle repeats continuously.
Discovery intervals may vary by +1 or -1 seconds, depending on system performance.

DHCP client as a new device

When the DHCP client device boots up without an IP address with the Layer 2 switch software version, the client initiates DHCP discovery, which is a subnet-directed broadcast. Refer to "DHCP client in continuous discovery mode" for more information.

The DHCP discovery broadcast is received by the DHCP servers present in the network. There are three possible responses to this message:

  • No response
  • Single response
  • More than one response
If the client does not receive a DHCP server response, there is a possibility that the client could be disabled on the device. If the client receives a response from the server (refer to "DORA process"), the client starts the DHCP request and obtains the IP address lease. If the client receives a response from more than one server, the client acknowledges the first response received, which is the default behavior.
The DORA process is the standard Discover, Offer, Request, Acknowledge process used by DHCP to allocate IP addresses dynamically to clients through a lease period. Refer to the following graphic for a description of the ICX implementation.

In the Layer 3 software image, when the DHCP client device boots up without any IP address, the client initiates the DHCP discovery on all ports. DHCP discovery packets are sent from all DHCP client-eligible ports in the device. The default discovery mechanism is similar to the switch version.

The following flowchart illustrates this discovery mechanism.

Figure 1  DHCP client device bootup with no IP address

DHCP client behavior after reboot

If the DHCP client device reboots with a previously obtained IP address, the DHCP client sends the DHCP request packet, which is a subnet-directed broadcast packet from all the operationally up ports of the device. Once the DHCP server responds positively to the request, the previously obtained IP address is leased seamlessly. If the DHCP server responds in the negative, the previously obtained IP address will be released, and the DHCP process restarts.

If the software version is Layer 3, when the DHCP client comes up after a reboot with a previously obtained IP address, the DHCP client sends the DHCP request packets only on the ports where the DHCP client was enabled previously on the device.