Differences

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

--- infoblox_uddi:dhcp [2026/01/21 07:49] – created bstafford
+++ infoblox_uddi:dhcp [2026/03/25 00:09] (current) – [Split Scope] bstafford
@@ Line 1: / Line 1: @@
-====== BloxOne DHCP ======
+====== NIOS-X DHCP ======
 If you set the DHCP servers at a subnet level, an ''subsequent'' ranges you create in the subnet will allow you to just inherit the associated OPH. However, any existing ranges in the subnet will not allow any "use subnet OPH" option. For any existing ranges in the subnet, you will need to recreate them if you want them to inherit the subnets OPH assignment values.
-DHCP Fingerprint : Fingerbank (Akamai) > Fing.
+For Advanced Active/Passive DHCP the lease DB is manged differently so it can be shared. It is shared via BloxOne CSP so the two DHCP servers don't have to talk to each other (although they do for heartbeats). Only ever do Kia Active/Passive if both devices are in the same VLAN. Because active has to stream updates immediately to passive (not Lazy Update). MS Delay between devices - Multiply by four and then how many of those you can fit into a second. That is how many LPS you can service in Active/Passive HA.
-For Advanced Active/Passive DHCP the lease DB is manged differntly so it can be shared. It is shared via BloxOne CSP so the two DHCP servers don't have to talk to each other (although they do for heartbeats). Only ever do Kia Active/Passive if both devices are in the same VLAN. Because active has to stream updates immediatly to passive (not Lazy Update). MS Delay between devices - Multiply by four and then how many of those you can fit into a second. That is how many LPS you can service in Active/Passive HA.
 ===== Performance =====
 Because in Active/Passive the two nodes of NIOS-X need to sync with each other before issuing a lease, the latency between the two devices has a massive impact on how many leases the devices can issue per second.
@@ Line 22: / Line 20: @@
 ===== Split Brain =====
 If you have active/passive and both servers are running but the communication link between them fails, DHCP "should" still function. Both servers will see the packets from the client, even if they can't talk to each other. They will know if the other is providing addresses. That said, there's likely to be conflicts BUT the client should do a RARP if the address is in use because one of the servers successfully issued a license.
+===== Rouge DHCP Servers =====
+DHCP protocol itself can’t solve rogue servers. ISC’s own guidance is [[https://kb.isc.org/docs/aa-00573|here]].
+Clients generally cannot distinguish an authorized DHCP server from an unauthorized one based solely on DHCP protocol behavior. As a result, there is essentially no remedy for this threat in the DHCP protocol.
+So if your threat model is “someone plugs in a cheap router and it starts answering DHCP on an access port,” the real control is:
+  * DHCP snooping / trusted ports
+  * Port security / 802.1X / NAC
+  * VLAN segmentation / access controls
+What Kea (not necessarily NIOS-X at this point in time) can do is to tighten control of “who gets served”
+While Kea can’t prevent another server from responding to clients, it can help you enforce that Kea only serves the traffic you intend:
+Kea supports DHCPv4 Option 82 (Relay Agent Information Option).
+In many enterprise designs, you combine:
+  * Relays that insert Option 82, and
+  * Kea client classes that match on Option 82 values,
+  * plus DROP for anything that doesn’t match
+That gives you “Kea only answers requests that come through my trusted relay/switch insertion,” which helps prevent unauthorized clients/segments from successfully using your Kea server.
+But it still does not stop a rogue DHCP server from answering those clients unless the switch blocks the rogue server’s offers.
+===== Starvation Attacks =====
+(For Kea, not NIOS-X yet)
+for DHCP starvation and DECLINE loops, Kea’s best built-in mitigations are:
+  * Client classification + DROP (hard-block bad patterns)
+  * Limits hook (libdhcp_limits.so) for rate limiting and lease limiting (contain flood impact)
+  * Backlog guardrail (parked-packet-limit) to avoid getting swamped
+Two key realities to keep in mind
+  * Rate limiting can’t stop pool exhaustion by many spoofed MACs by itself; it mainly protects server responsiveness and buys time.
+  * If you want the strongest starvation/rogue resilience at the edge, the network control is still DHCP snooping / port security (outside Kea).
+A “good default” policy for exposed subnets (guest / access edge)
+  * Per-subnet rate limit (limits hook) to cap how much traffic can consume CPU.
+  * Per-class rate limit for “unknown/untrusted” clients (especially if you can match on relay info / expected options).
+  * Set a reasonable parked-packet-limit so floods don’t turn into runaway backlog.
+===== DNS Suffix =====
+  * DHCP Option 15 – Domain Name
+    * Defines the client’s primary DNS domain name
+    * Historically used as the system’s default domain
+    * On many systems, it becomes:
+      * The device’s DNS suffix
+      * The first entry in the DNS search list (if no Option 119 is provided)
+      *
+  * DHCP Option 119 – Domain Search List
+    * Explicitly defines the DNS suffix search list
+    * Supports multiple domains
+    * If present, it typically overrides Option 15 for search list purposes
+===== Ping Before Offer =====
+  * Ping Before Offer - applies across entire tenant and set in Global DHCP Configuration.
+  * Can configure timeout (default = 100ms) and number of pings (default = 1)
+  * e.g. 1000ms + 3 Ping = Client will not get Offer for 3 seconds.
+  * This does not impact the overall LPS capability of the machine as different leases are handled in parallel.
+  * Ping check information is only available in the logs at DEBUG level (i.e. does not get sent up to Infoblox Portal). Only INFO and above gets sent to Infoblox Portal.
+  * If DHCP server gets a ping response, Infoblox Portal marks the IP as ABANDONED.
+===== Split Scope =====
+  * General use case for Split Scope is IPv6 and also Microsoft Migration.
+  * Infoblox manages DHCP on other vendors like Versa networks and which only support split scopes (or vendors like Microsoft which support split scope and can be managed by Universal DDI) - so Universal DDI must support Split Scopes.
+  * With IPv6 you can divide a /64 into two /65 subnets
+  * Split Scope has no lease sharing or heatbeat so it is simpler.
+  * DDNS Expirations can be an issue for Fixed Address objects in Split Ranges.
+  * Both servers in split scope will get any fixed address object in that range.
+  * You cannot adjust the split. It is always 50/50. Possibly off by 1. If Exclusion ranges block a large section of one half of the range, that server will only serve the bits it can. The system doesn't consider exclusion ranges when dividing the range into 50/50. Basically, don't put lots of exclusion ranges in.
+  * Don't convert split range to Active/Passive. (Until such a time as UDDI can copy leases to server)
+  * Resizing pool (e.g. 100-120) can also cause confusion because PartA doing 1-50 and PartB doing 51-100 is now PartA doing 1-60 and PartB doing 61 - 120
+  * When you REPLACE a box, the new one will get the old leases from portal.
+  * If client got lease from ServerA and then ServerA fails, when client comes back for IP. If client has "Authoritative turned on" ServerB would reply with NACK. Without "Authoritative" turned on; wait for lease expiration or T2. You gain simplicity but sacrifice T1 renewal by peer. Authoritative basically says the server knows all the leases that should be on the subnet. With Split Ranges... we don't; by definition we only know half.