Saucepan

User Tools

Site Tools

Trace:
infoblox_nios:dhcp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
infoblox_nios:dhcp [2025/01/19 19:19] – [DHCP Authoritative] bstaffordinfoblox_nios:dhcp [2026/03/24 21:22] (current) – [Performance] bstafford
Line 1: Line 1:
 ====== NIOS DHCP ====== ====== NIOS DHCP ======
 For DHCP starvation prevention, the most common recommendation is to control/prevent it at the switch fabric layer. For DHCP starvation prevention, the most common recommendation is to control/prevent it at the switch fabric layer.
 +
 +The "Disable for DHCP" option in Networks is useful when you are in the process of setting up the DHCP server. Clear this after you have configured the server and are ready to have it serve DHCP for this network.
  
 ===== Ports ===== ===== Ports =====
Line 16: Line 18:
   * Datasheet figures for DHCP LPS are based on full DORA with no ping before offer or DDNS.   * 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.   * Reporting of actual LPS being served is based on ACKs to cover renews.
 +
 +===== Moving Leases =====
 +If you update a subnet to use a different DHCP server, the existing leases will not move until they renew. If the server that issued the lease is no longer valid (because you forced it over to member2) than it shouldn't respond at the T1 timer, and should renew on the new server when it sends a discover at the T2 timer. 
 + 
 +If the servers are in a failover pair and you are changing the balancing, you have to wait until the MCLT expires to take effect.
  
 ===== DHCP Hub-Spoke ===== ===== DHCP Hub-Spoke =====
Line 25: Line 32:
  
 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. 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.
 +===== DNS Config =====
 +To try and spread DNS load more evenly between two members, update the two DHCP members in the FO at a member level. On the first member, set the DNS assignment to "DNS Server 1 & DNS Server 2". On the second member, set the DNS assignment to "DNS Server 2 & DNS Server 1". So long as you don't override this at a network or range level, this means that clients using DHCP server 1 will get DNS servers in one order and clients using the DHCP server 2 will get DNS servers in the opposite order. 
  
 ===== Failover Associations ===== ===== Failover Associations =====
Line 30: Line 39:
  
 Never rename an active failover assocation. It will trigger a recover/recover. Move all the ranges to single member then delete and recreat the FO and move all ranges to the new FO. Never rename an active failover assocation. It will trigger a recover/recover. Move all the ranges to single member then delete and recreat the FO and move all ranges to the new FO.
 +
 +===== High Availability =====
 +HA should be used on at least one of the two members of a FO. Ideally, use HA on both because if a member goes down (HA makes this unlikly) then the other issues leases on MCLT.
 ===== Active-Active ===== ===== Active-Active =====
 A DHCP fixed address in an active/active range will only apply on the box that has that part of the active/active range. A DHCP fixed address in an active/active range will only apply on the box that has that part of the active/active range.
Line 35: Line 47:
 So with active/active DHCP, you should define the DHCP fixed address twice - once for each DHCP servers part of the range. So with active/active DHCP, you should define the DHCP fixed address twice - once for each DHCP servers part of the range.
 ===== VLAN Sub-Interfaces and DHCP ===== ===== VLAN Sub-Interfaces and DHCP =====
-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)+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). e.g. ''f1:04:0a:7d:be:96'' instead of ''f1040a7dbe96''
  
 +===== Option 43 =====
 +When configuring Option 43 (Vendor encapsulated options - string) for DHCP, you must enter the value with colons between the data
 ===== Binding States ===== ===== Binding States =====
   * Free: The lease is available for clients to use.   * Free: The lease is available for clients to use.
   * Active: The lease is currently in use by a DHCP client.   * Active: The lease is currently in use by a DHCP client.
-  * Static: The lease is a fixed address lease.+  * Static: The lease is a fixed address lease. (enable under Grid DHCP Properties, General, Advanced)
   * Expired: The lease was in use, but the DHCP client never renewed it, so it is no longer valid.   * 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.   * 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.   * 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.   * Backup: Lease belongs to the secondary peer in a DHCP fail over relationship.
 +
 +
 +===== Fixed Address Lease =====
 +Under Grid DHCP Properties, General, Advanced.
 +Fixed Address Lease. Without this feature enabled, there is no logging of leases assigned to fixed addresses and they cannot be tracked.
 ===== Primary VS Secondary ===== ===== Primary VS Secondary =====
 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. 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.
Line 50: Line 69:
 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. 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.
  
 +===== Partner Down =====
 +From [[https://community.infoblox.com/discussion/comment/34210#Comment_34210|here]].
 +
 +The scenario here is where member A is currently in the PARTNER-DOWN state, and member B, which is a replacement (and therefore has no historical knowledge of communications with A) is newly starting up.  In that situation, member A should remain in PARTNER-DOWN while member B goes through RECOVER, RECOVER-WAIT, and RECOVER-DONE.
 +
 +To lay it out in greater detail, after going through STARTUP and seeing that member A is in PARTNER-DOWN state, member B will go into RECOVER state, during which it will not serve clients, and will request information from member A.  Once member B gets the final update message from member A (UPDDONE), it will transition to RECOVER-WAIT.   Member B will remain in RECOVER-WAIT for the MCLT duration, after which it will transition to RECOVER-DONE.  When member B reaches RECOVER-DONE and sees that member A is in PARTNER-DOWN, member B will then transition to the NORMAL state, and member A, seeing its peer has transitioned to NORMAL state will also transition to NORMAL.
 +
 +
 +So, as an administrator, what is your course of action?  The answer is DON’T DO ANYTHING (not even a service restart), let the system sort itself out, you can just monitor the progress.  As long as member A remains in PARTNER-DOWN and member B goes through the RECOVERY process (including RECOVER-WAIT and RECOVER-DONE), it is working just as designed.  In almost every instance I can recall when things went wrong leading to a total DHCP outage, it was because of an action taken by an administrator.
 +As administrators, the natural response to the system continuing to show a red indication of status is that some action must be taken in order to get back to green, and that is where people get into trouble.  The waiting is the hardest part, but it is absolutely the best course of action in this scenario.  If for some strange reason things don’t get back to Normal on their own after the MCLT, don’t do anything until you contact Infoblox support, and then follow their guidance exactly.  
 +
 +
 +
 +
 +
 +Let's say that I had a DHCP failover association between member A and member B, then let's say that member B became down for some reason and I put member A in a partner down state.
 +
 +Next, I manage to get an RMA appliance to replace the failed member B, and the new member B comes up online and discovers that its peer "member A" is in partner down state.
 +
 +My question is: What happens next?
 +
 +Does the new member B go into a rover state while member A stays in partner down state and continues to grant leases.
 +
 +Or
 +
 +Do both go into a rover state, which constitue a service failover? If this is the case, how do we avoid this?
 ===== Known Clients ===== ===== Known Clients =====
  
Line 88: Line 133:
 In [[https://community.infoblox.com/t5/nios-dns-dhcp-ipam/performance-impact-of-dhcp-lease-scavenging/td-p/23619|this community article]] we hear that enabling DHCP scavenging saw CPU load increase from 10% to about 30% for about 3 minutes.  In [[https://community.infoblox.com/t5/nios-dns-dhcp-ipam/performance-impact-of-dhcp-lease-scavenging/td-p/23619|this community article]] we hear that enabling DHCP scavenging saw CPU load increase from 10% to about 30% for about 3 minutes. 
  
 +Enabling "Scavenge free and backup leases" only includes Free and Backup. It does not include Expired, Abandoned or Released entries.
  
 +While you can clean up Expired/Abandoned/Released with a script, there is a valid reason for those leases to be in that state, running the script does not fix the root cause. If the root cause has been addressed, then the script can clean up a lot of objects that would otherwise persist forever.
 +
 +
 +Since NIOS 8.4 where the hidden CLI command ''delete leases''. Don't run without talking to support first. This command should be used carefully, it can generate a LOT of writes to the database, it has a "dryrun" option to show the impacted leases before running it, and dhcp should be shut down while it is being run to ensure all abandoned leases are actually deleted.
 ===== DHCP Abandoned ===== ===== DHCP Abandoned =====
  
Line 154: Line 204:
 The new behaviour is for DHCP filters to use AND logic. The new behaviour is for DHCP filters to use AND logic.
  
 +
 +For DHCP, you can use Option 77 (User Class Identifier). This allows you to define a "string" ID on the client (windows or Linux) and this will be passed onto DCHP server during request. The DHCP server can then use that in a DCHP Option filter to ensure only clients presenting that ID will get issued a lease. The use case would be where you have a subnet and range that needs to issue IP's normally but a specific sub-set should only be issued to a specific group of servers (e.g. Database servers). You would create a range for that use case and apply the option filter. Why would you want to do this? Possibly for creating known firewall rules.
 +===== DHCP Version =====
 +NIOS uses ISC DHCP. NIOS-X uses Kea.
 +
 +The following is from NIOS 9.0.7
 +
 +For NIOS, the version of ISC DHCP is printed to syslog when the DHCP service is restarted
 +  * daemon
 +  * INFO
 +  * validate_dhcpd
 +  * Internet Systems Consortium DHCP Server 4.3.3-P1
 ===== Troubleshooting ===== ===== Troubleshooting =====
 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 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
infoblox_nios/dhcp.1737314380.txt.gz · Last modified: by bstafford