Differences

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

--- infoblox_nios:high_availability [2025/09/22 08:47] – [Proximity] bstafford
+++ infoblox_nios:high_availability [2025/12/15 15:30] (current) – bstafford
@@ Line 6: / Line 6: @@
 General blog article [[https://blogs.infoblox.com/company/power-of-three-for-low-cost-ha-business-continuity/|here]] on using a standalone appliance and a HA pair.
+===== Changing HA Pair Types =====
+Cutting over from HA physical to HA virtual. When I cut the passive to vNIOS, it did not change the Member Type to Virtual NIOS. After I cut the second member of the HA pair, the Member Type changed to Virtual NIOS without intervention.
 ===== DFP =====
 When using DFP, NIOS uses the LAN1 port to establish DoT on TCP-443 to Infoblox Anycast. This is true EVEN IF THE NIOS is HA. NIOS will not use the HA VIP for TCP-443. However, any plaintext queries will come from the HA VIP.
@@ Line 32: / Line 34: @@
 e.g. examples of fibre cuts.
   * 2025-09-21 [[https://www.nbcdfw.com/news/local/dfw-love-field-airport-delays-cancellations-cable-lines-friday-american-southwest/3921370/|Texas Airports Impacted]]
+As per [[https://docs.infoblox.com/space/nios90/1432819381/Planning+for+an+HA+Pair|Infoblox Documentation]] ... Infoblox uses VRRP advertisements for the active and passive HA design. Therefore, all HA pairs must be located **in the same location** connected to the highly available switching infrastructure. Any other deployment is not supported without a written agreement with Infoblox. Contact Infoblox Technical Support for more information about other deployment support.
 ===== HA Failover on DNS Nameservers =====
@@ Line 46: / Line 50: @@
 e.g. If LAN1 is for production and LAN2 is for OOB network, if LAN2 on the active node fails, there is no failover and the OOB network looses access to services on LAN2.
 ===== NSX =====
-At least one customer got NIOS HA working on NSX 4.11.
+The only time I saw a customer deploy NIOS HA on NSX, they had to bypass NSX and expose the VM to ESXi directly because they couldn't get "Forged Transmits" enabled on NSX 4.11.
-  * port group is on NSX "Segment" and that doesn't have option for forgest transits.
+  * port group is on NSX "Segment" and that doesn't have option for forgesd transits.
   * "MAC address changes" are allowed in NSX but called "MAC address learning"
-  * "Forged transmits" not allowd on NSX but the customer NSX team found a way
+  * "Forged transmits" not allowed on NSX so the customer had to get the VM's working directly with ESXi.
 Without "Forged Transmits", everything would work for a minute and then stop for four hours