DHCP Reservations on a Cisco RV320

The Cisco RV320 router lets you bind a MAC address to an IP address. Normally you would think that would reserve the address for assignment via DHCP, but the documentation states very clearly on p. 49, “Binding does not assign an IP address to a device.”

The documentation is wrong.

A determined support rep tested and confirmed that the MAC-to-IP binding does in fact tell the router which IP to assign. I thought I had seen that fail in the field (a printer wouldn’t pull the expected IP address), but in my own testing today with router firmware v1.1.1.06 (2013-12-06) and running Wireshark on the mirror port, I saw the router use the MAC-to-IP binding for DHCP every time.

DHCP Reservation Behavior

Note There are two checkboxes on the DHCP > IP & MAC Binding page:  “Block MAC address on the list with wrong IP address” and “Block MAC address not on the list”. I left both of them unchecked.

The good news is, if a MAC address is added to IP & MAC Binding list, DHCP will assign the specified IP to that MAC address.

Normally I would reserve an address outside of the dynamically-assigned range of addresses, but I wanted to see what would happen if it was within that range.

• If the IP address is outside the DHCP IP range on DHCP Setup page (.100 – .149 by default), e.g. the IP ends in .15, the device is not listed on the DHCP Status page (or anywhere else). It’s like a ghost device attached to the router—there is no way to know it is there.
• If the IP address is within the DHCP IP range on DHCP Setup page), e.g. the IP ends in .140, the device is listed on the DHCP Status page with a Client Host Name of "static-host" and a Rule Name corresponding to the Name assigned under IP & MAC Binding.  However if there are two devices in the range, only one is listed. So there’s no point in reserving IPs, say, at the high end of the dynamic range—only one will be listed anyway.

DHCP Conversations

Here is how the DHCP reservations looked in Wireshark.

Windows 7 Computer Conversation

0.0.0.0      DHCP Request
192.168.x.1  DHCP NAK
0.0.0.0      DHCP Discover
192.168.x.1  DHCP Offer
0.0.0.0      DHCP Request
192.168.x.1  DHCP ACK
192.168.x.15 DHCP Inform

Brother MFC Conversation

0.0.0.0      DHCP Request
0.0.0.0      DHCP Request
0.0.0.0      DHCP Request
0.0.0.0      DHCP Discover
192.168.x.1  DHCP Offer
0.0.0.0      DHCP Request
192.168.x.1  DHCP ACK

Note that the Brother does not send back a DHCP Inform packet. However, the printer still shows up in the DHCP Status list and, if the IP is in the dynamic range, in the DHCP Status list.

Logging

I had hoped that DHCP lease assignment and expiry would be shown in the log. I turned on all logging options. Once, I saw a "kernel" event like this: 

  add new : cnd[3] learn mac [0-1b-a9-f3-4d-ac], ip[192.168.x.101], idx[ac]. 
 
But that didn’t happen on each DCHP re-assignment.  Maybe it’s only logged the first time that MAC is seen? In any case, DCHP lease events are kept secret.

Enhancements Needed

It’s good that DHCP reservations do work. But several enhancements are needed:

1. The DHCP list must show all devices to which DHCP assigns an address, whether reserved or not. Actually, there should be a full device list, showing all connected devices, whether they received a DHCP lease or are using a static IP assigned at the device.

2. The DHCP list should support easily adding a device to the MAC-to-IP binding list, perhaps with a hyperlink.

3. There should be a “DHCP” option in the log options that allows listing DHCP assignments and expirations.

4. The help and documentation must be updated to explain how all this works.

Update October 14, 2014

I discovered another DHCP bug in the RV320 over the weekend. After restarting the router and after after multiple devices re-connected using previous DHCP leases, the DHCP Status tables shows that nothing is connected. No static IPs, no dynamic IPs, nothing:

A day later, once the DHCP leases started renewing, the devices began to re-appear in the list.

After a restart, DHCP Status needs to be refreshed as devices re-connect.