Supported services and infrastructures - BlueCat Integrity - 9.3.0

Attention: A known issue exists with the configuration of replication between v9.3.x and v9.4.x BlueCat Address Manager for Azure virtual appliances and on-site Address Manager appliances. For more information and workaround steps, refer to KI-025544 on the BlueCat Customer Care portal.

Attention: Configuring DHCP service on a BlueCat DNS for Azure virtual appliance

If you are configuring DHCP service on your BlueCat DNS for Azure virtual appliance, the DHCP traffic to the BlueCat DNS for Azure virtual appliance must be Unicast from a DHCP IP helper or relay outside of Azure.

The BlueCat DNS for Azure virtual appliance cannot provide DHCP to any Azure Virtual Machines within the Azure Virtual Network (VNet) where it resides, as this is handled automatically by Azure for hosts. The BlueCat DNS for Azure virtual appliance can provide Unicast DHCP as a service to hosts external to the VNet.

The IP helper or DHCP relay that is forwarding DHCP traffic to Azure must use port UDP/67. UDP traffic from port 67 is supported by Azure VNets. Verify with your DHCP relay vendor that port UDP/67 is used, as some DHCP relay implementations use port UDP/68 as the source port and Azure VNets do not support Unicast DHCP traffic from source port 68 to destination port 67.

Limitations with Azure Virtual Networks and DHCP services provided by Azure

Azure VNets do not support Unicast DHCP traffic from client port UDP/68 to server port UDP/67, affecting interactions between the DHCP client and DHCP server when a client has an IP address assigned.

When an address is first allocated to a DHCP client, the client does not know the IP address of the DHCP server and uses a broadcast to send the DHCP request. The local DHCP relay receives the broadcast traffic and handles all communication with the DHCP server using port UDP/67. Azure processes this request normally.

Once a DHCP client has configured an address temporarily assigned by DHCP, it moves to the BOUND state. The client records the lease expiration time and two additional times, T1 and T2.

At time T1, the client moves to RENEWING state and sends a request to the DHCP server using Unicast to extend its lease. The request uses source port 68 and will not be forwarded by the Azure VNet, resulting in the DHCP client not receiving a response. The client attempts one retry because it still has a valid lease. At time T2, the client moves to REBINDING state and attempts to contact any DHCP server to renew its lease. The client broadcasts this request and it is forwarded by the DHCP relay. The request uses source port 67, and will be forwarded and received by the DHCP server. The DHCP server responds to the client with the new lease.

Times T1 and T2 are configurable on the DHCP server and are passed to the DHCP client using options. The default value for T1 is 1/2 the lease time and the default value for T2 is 7/8 the lease time.

For more information on limitations with Azure Virtual Networks and DHCP service, refer to https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-faq#can-i-deploy-a-dhcp-server-in-a-vnet.

For more information on the DHCP configuration parameters, refer to https://datatracker.ietf.org/doc/html/rfc2131#section-4.4.5.