For DHCP starvation prevention, the most common recommendation is to control/prevent it at the switch fabric layer.

Server listens on UDP-67 T1: (direct renewal)

• UDP 68 > 67 DHCP Client to DHCP Server (throttled by Azure)
• UDP 67 > 68 DHCP Server to DHCP Client (return traffic) (blocked by Azure)

T2 Timer: (and initial

• UDP 67 > 67 DHCP Relay to DHCP Server (client to relay is broadcast)
• UDP 68 > 68 DHCP Server to DHCP Relay (client to relay is broadcast)

• Datasheet figures for DHCP LPS are based on full DORA with no ping before offer or DDNS.
• Reporting of actual LPS being served is based on ACKs to cover renews.

A DHCP server can only be primary for a single DHCP Failover association. So you need to make each failover association have a separate primary. I.e. hub-spoke where every spoke is the primary.

NIOS GUI has a feature where you can set load balancing data. Never touch this. Ever. It is a feature that is in ISC DHCP and is something you should never edit from equal split (50/50).

Realistically, the only other options that make any sense are 100/0 or 0/100. However, if you do this, all you are changing is the algorithm used to decide which member responds to which MAC address. The DHCP range is still shared between the two members 50/50 and that means any re-balancing will move from the 100 member to the 0 member (on a 100/0 or 0/100 configuration). This will cause a major outage.

Don't try and change the members assigned to a DHCP failover association. Messing with the FO will very likely end up in a recover/recover state which means no leases are issued.

A DHCP fixed address in an active/active range will only apply on the box that has that part of the active/active range.

So with active/active DHCP, you should define the DHCP fixed address twice - once for each DHCP servers part of the range.

DHCP only works on the primary interface in NIOS. It won't run on tagged sub-interfaces (that is for DNS/NTP/Network Discovery only)

• Free: The lease is available for clients to use.
• Active: The lease is currently in use by a DHCP client.
• Static: The lease is a fixed address lease.
• Expired: The lease was in use, but the DHCP client never renewed it, so it is no longer valid.
• Released: The DHCP client returned the lease to the appliance.
• Abandoned: The appliance cannot lease this IP address because the appliance received a response when pinging the address.
• Backup: Lease belongs to the secondary peer in a DHCP fail over relationship.

If you have a DHCP Fail-over Association (FOA), one member will be “primary” and the other “secondary”. For users, it makes no difference which is which assuming that the admin is following best-practice and using balanced distribution for the FOA. MAC address hash is used to determine which server responds.

The only difference is which member handles pool rebalancing and when you get into states of RECOVER the Primary initiates the Binding updates to create a single authoritative lease table for them to share so they can move back to NORMAL. So it is important to the state engine but not really the user/admin.

DHCP ISC has a setting for “Known/Unknown” clients.

Edit Range > IPv4 DHCP Options > Advanced > Allow/Deny Clients.

The problem happens when you tick BOTH boxes. Some clients get allowed.

When importing from Microsoft, it is possible that both are enabled.

NOTE: The existence of DHCP lease history in NIOS (Data Management > DHCP > Leases > Lease History) is legacy. It pre-dates the reporting server. DHCP lease history required all DHCP members to forward lease data to a designated member. Back in the day, the recommendation was to dedicate a member to receive the logs. However, these days it is better to just use the reporting server as there is no good reason to keep doing it the old way.

The only thing the legacy system gives you that reporting won't is that it shows the data in the “Lease History” tab. However, you can get all of the same data from the reporting dashboard for DHCP Lease History, and it is far more useful. Also, the “lease history” tab is limited by count (100k) whereas the reporting server is not limited by a specific count, it depends on the indexing capacity and storage you give it, so it can be much longer.

The DHCP lease history log holds a maximum of 100,000 entries. After that maximum is reached, the appliance begins deleting entries, starting with the oldest. To archive DHCP lease history logs, you can export them and save them as CSV (comma separated variables) files. You do not need to export the entire log. You can selectively export a section of the log, such as the lease events for a single day.

As a conservative approach to archiving DHCP lease data, Infoblox recommends exporting the log on a daily basis, perhaps through API (application programming interface) scripting. By exporting the daily log entries every day over a certain period of time and then opening the exported files with a spreadsheet program, you can see the number of entries for each day. You can then estimate how often you need to export the log to ensure that you save all of the entries before the log fills up (at 100,000 entries). As a result, you might discover that you need to export the log more or less frequently than once a day to archive all the records.

For RFC3397 (DHCP option 119) that allows for DNS Suffix list, you can specify up to 1023 characters in NIOS.

NOTE: Remember, DNS suffix lists are not great. Ideally, avoid where possible and use no more than 5. They increase the load on DNS recursive resolver and also slow down endpoint machines which much try hostname queries repeatedly before concluding that a name cannot be resolved.

e.g.

"example.com", "domain.com", "hello.com"

"example.com","domain.com","hello.com"

In the lab I can get up to 442 characters before the Windows VM stops displaying (and stopped using) the suffix list provided by the NIOS appliance.

If DHCP scavenging is not enabled, it should be, and it definitely can reduce the lease count. If scavenging is not enabled, leases remain in the database even after they have expired.

When DHCP server checks IP with ping before handing IP out, if IP responds to ping from DHCP server, it is marked as abandoned by the DHCP server. Actually that state arises from when either,

• the server pings the address before assignment
• the IP doesn't respond to ping, so we give the client an in-use IP at which point virtually every DHCP client will ARP for the address. If it sees the IP in use already, the DHCP client sends a DECLINE to the DHCP server and teh DHCP server puts that address into ABANDONED state.

Leases in state Abandoned do get tried again, but only after we have run the addresses a few times looking for Free. This has an order where it looks for

• State Free w/ with your mac (i.e. you had it a long time ago)
• State Free with no mac (i.e. no one had it every according to the records)
• FREE and some other mac (i.e. someone had it a long time ago but it is free now)

Only after that would it go to abandoned and it would still ping again before giving it out, so when it responds to ping it would just be marked abandoned again.

DHCP lives inside BOOTP and as far as I know Infoblox should not have BOOTP giving out abandoned leases. BOOTP doesn't know the concept of abandoned as far as I recall. Things like gateway even vrrp/HSRP addresses should absolutely have an IP reservation. Sadly the old school MS recommendations were to put everything in the range and then exclude.

It is an optional configuration to mark DHCP server as authoritative and and training says to always tick it. we have the ability to unselected the option because ISC DHCP says it is a configurable options but, for all practical purposes, we should always enable when NIOS the the main DHCP server. See note)

HOWEVER, you might find yourself in a migration event where you want to untick 'is authoratative'.

In NIOS DHCP there is an option to “Update DNS on DHCP renewal”.

In general, leave this disabled because it generates a lot of extra DDNS updates on the DNS Primary and ZRQ transactions (data replication between members) on the GM. DDNS updates which are high-priority messages that can disrupt recursion (which is why hidden primaries are important) and GM for ZRQ transactions.

The feature does exist for a few certain use cases:

# (The main use case) When Infoblox is the DHCP server and Microsoft is the authoritative DNS (because MS uses time of last dynamic update as its sole scavenging parameter)
# During transitions from non-Infoblox DNS systems to Infoblox DNS to get the devices to register in the Infoblox.WHen needed for this use case, enable only for a short while during migration (1/2 lease time).
# (Not a good use case) Multi-interface clients that need accurate DDNS registration. If you have clients that have both wired and wireless interfaces, because the MAC address differs, you need to use # check-only for your TXT Record handling and have update on renew enabled, but ONLY on the subnets where it is needed, don't turn it on at a Grid level in this scenario. For this scenario, be sure it is actually necessary.  There are cases where the registration of the client name matters, but it is usually more in the heads of the administrators than it is an actual technical requirement. This isn't a fix, it hides the issue by causing another. Quite a debatable point.

Problems with this feature:

# When enabled some customers can start to see issues with the Grid replication queue (ZRQ  transactions). e.g. a single device (e.g. rouge VoIP phone) on the network spewing out DHCP renewals may severely impact the Grid/replication queue in some cases.

When a Windows box is shutdown, it sends a DHCP Release message to the DHCP server. This can cause issues if the Windows box is a server and you are rebooting it because this may cause the DHCP server to delete the DDNS record for the server.

There is a registry key to disable this action ReleaseOnShutdown.

Documentation here.

Better guide here

PS c:\> Get-WmiObject -Query "Select Description,GUID from Win32_Networkadapter"|Select-Object Description,GUID
Description                                 GUID
-----------                                 ----
Intel(R) 82579LM Gigabit Network Connection {0694A535-03B4-4F63-A9C0-44565C8A881D}

Then add the following Registry Key ReleaseOnShutdown =0

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{0694A535-03B4-4F63-A9C0-44565C8A881D} /v ReleaseOnShutdown /t REG_DWORD /d 0 /f

Possible other values are:

• 1 - Always release the lease
• 2 - Release or leave the lease depending of option 2 from the Server

As of NIOS 8.6.2 there is a CLI comand set dhcp_filter_behavior old/new.

The old behaviour is for DHCP filters to use OR logic.

The new behaviour is for DHCP filters to use AND logic.

If you have DHCP in US and EMEA in FO, if emea site can't route to US but the source IP hash means the USA site should issue the lease, the client won't get the IP and the only way to fix this is to fix the network connectity from the EMEA site to the US