Troubleshooting DHCPv4 failover in NIOS (3530)

Scenario

DHCP Failover has been configured for the network 172.31.101.0/24. However, clients are not receiving leases. Please troubleshoot and fix. You may use these commands to help you on the VM testing-linux:

To enable DHCP on testing-linux: sudo set-network-dhcp
sudo password: infoblox
To clear DHCP leases on testing-linux: sudo clear-dhcp-leases

Estimate Completion Time

25 to 30 minutes

Credentials

Description	Username	Password	URL or IP
Grid Manager UI	admin	infoblox	https://10.100.0.100/

Requirements

Administrative access to the Grid

Course References

3012: DHCP Troubleshooting Methodology
3019: Explaining DHCPv4 Failover
3020: Troubleshooting DHCPv4 Failover in NIOS

Lab Initiation

Access jump-desktop

Once the lab is deployed, you can access the virtual machines required to complete this lab activity. To initiate the lab, click on the jump-desktop tile and login to the Linux UI:

Username: training

Password: infoblox

Initiate lab

To initiate the lab, double-click the Launch Lab icon on the Desktop.

Choose the lab number from the list and click OK.

After clicking OK, you will see a pop-up message with a brief description of the lab task. If the description looks correct, click Yes to continue lab initiation.

Lab initiation will take a couple of minutes to finish.

Once complete, you will see another pop-up message with the login credentials and the URL for the Grid Manager’s User Interface. Note that the credentials may differ from those from prior labs.

Tasks

Task 1: Troubleshooting DHCP failover configuration

Check DHCP and DHCP Failover configuration to understand why clients are not receiving leases as expected.

Task 2: Identifying which member granted lease

Locate lease information in the UI to identify the member that provided lease to client after troubleshooting.

Solutions

Task 1 Solution: Troubleshooting DHCP failover configuration

Use the set-network-dhcp command, then look through syslog messages on both ibns1 and ibns2.

We will notice many messages indicate there are no free leases on the 172.31.101.0/24 subnet.

The GM UI shows the subnet has 0% utilization (Data Management → DHCP → Networks →172.31.101.0/24)

However, look closely, the range is disabled (grayed out).

Another way to clearly see the problem is to look at the member configuration. Choose either ibns1 or ibns2, view its DHCP configuration file, and we will see this:

CODE

subnet 172.31.101.0 netmask 255.255.255.0 {

}

The subnet is defined, but there is no configuration in it. This indicates there are no ranges configured. Go to Data Management → DHCP → Network →172.31.101.0/24 and enable the range, then we will see the configuration update:

CODE

subnet 172.31.101.0 netmask 255.255.255.0 {
	pool {
		failover peer "M1-M2(1687163233p)";
		deny dynamic bootp clients;
		infoblox-range 172.31.101.250 172.31.101.253;
		range 172.31.101.250 172.31.101.253;
	}
}

Testing-linux should now be able to receive a DHCP lease.

Task 2 Solution: Identifying which member granted lease

Navigate to Data Management → DHCP → Leases → Current Leases, and we should see two lease files with the identical IP address. This is normal with DHCP Failover, for each lease, there are 2 lease files, one for each peer.

Highlight either one of the lease files and click View Lease Details.

Another way to tell is by looking at the syslog messages on both DHCP members. On the member that handed out the DHCP, we will see the normal DORA transaction; on the other member/peer, we will see DHCPREQUEST message ending with lease owned by peer.