Differences

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

--- infoblox:hardware [2025/08/24 17:35] – [Advantages of Hardware] bstafford
+++ infoblox:hardware [2026/03/19 22:55] (current) – [NIOS PSU SKU] bstafford
@@ Line 5: / Line 5: @@
 [[infoblox_nios:support#rma|Data on hardware RMA]]
-[[https://support.infoblox.com/s/article/2896|Hardware Swap]]
+[[infoblox_nios:misc#disk|Disk Partition Size]]
+[[https://support.infoblox.com/s/article/Infoblox-hardware-replacement-swaps-for-NIOS-or-NetMRI-configurations|Hardware Swap]]
+[[https://community.infoblox.com/kb/articles/288-nios-hardware-replacement-swaps-for-ha-and-grid-configurations|Hardware HA Swap]]
 ===== Datasheets =====
@@ Line 132: / Line 136: @@
 These are suitable for TE-1405 and TE-2205, TE-906, TE-1506, TE-1606, TE-2306 and TE-4106 hardware.
+NOTE: Although you can technical remove a PSU from a TE-1405 or TE-2205 appliance and use it in an X6 appliance, you should not do this for a long term. Although they are the same SKU, more recent productions of the PSU have a higher MTBF span and these should be used rather than older X5 PSUs. You cannot mix AC/DC.
+NOTE: Officially, the dual PSU TE-906-2AC is NOT hot swappable.
 NOTE: When ordering the TE-1506 hardware with dual PSU, the TE-1506 will ship with one PSU and the second PSU will be shipped in a separate package. The second PSU will need to be unboxed and installed into the TE-1506 chassis by the end user.
+NOTE: You can use X5 PSU in X6 hardware. However, the warranty will stay with the X5 PSU if it has been used for sometime. It is recommend to buy new PSU with new hardware as PSU has shelf life of about 2 years due to the components inside the PSU aging. You cannot mix the AC/DC PSU within the same chassis.
 ==== NIOS PSU Power Draw ====
@@ Line 197: / Line 208: @@
 Infoblox announced that the EOS date for B105 is 31 Oct 2024. B105 only comes with 1 year warranty so that means all B105 will be out-of-hardware support on 31 Oct 2025.
+Possibly
+  * 4-core Intel Celeron Intel Celeron J1900 @2GHz (4 core, 4 threads)
+  * 8GB RAM
+  * 64GB Disk
 ==== B212 ====
@@ Line 219: / Line 235: @@
   * Dell VEP-1425
   * Dell VEP-1485
+Dell VEP Rack Mount Kit data [[https://www.dell.com/support/manuals/en-uk/dell-emc-networking-vep1445-vep1485/vep1405-technology-guide-rev-a03/chassis-mounting?guid=guid-ad6f30ab-19c1-480b-adee-efe3e23bda2c&lang=en-us|here]] and SKU is [[https://www.dell.com/support/manuals/en-uk/dell-emc-networking-vep1445-vep1485/vep1405-technology-guide-rev-a03/rack-mount-kit?guid=guid-37ee1c6f-87c2-4f6b-8ce2-e85140c80a49&lang=en-us|770-BCZE]].
   * Infoblox Deployment Guide for Dell VEP [[https://docs.infoblox.com/space/BloxOneInfrastructure/204538971|Dell VEP here]].
@@ Line 227: / Line 245: @@
 **VEP1425 (210-AREH)** (Has WiFi and Bluetooth. Avoid for Infoblox)
-  * 4-core
+  * 4-core (Intel Atom C3558) (4 core, 4 threads)
   * 8 GB DDR4
   * 16 GB eMMC
@@ Line 242: / Line 260: @@
 **VEP1425N (210-BCBE)**
-  * 4-core
+  * 4-core (Intel Atom C3558)
   * 8 GB DDR4
   * 16 GB eMMC
@@ Line 256: / Line 274: @@
 **VEP1485 (210-AWIQ)** (Has WiFi and Bluetooth but also 64GB RAM and extra 2TB SSD)
-  * 16-core
+  * 16-core (Intel Atom C3958)
   * 64 GB DDR4
   * 16 GB eMMC
@@ Line 270: / Line 288: @@
 **VEP1485N (210-BCBB)**
-  * 16-core
+  * 16-core (Intel Atom C3958)
   * 32 GB DDR4
   * 16 GB eMMC
@@ Line 372: / Line 390: @@
   * Infoblox team at customer had direct access to the appliances independently of other IT teams (hypervisor, storage,etc). This can often be useful where the Infoblox is run by a third party partner organization to the end user and runs it in their own DC.
   * Infoblox team at customer can RMA a faulty appliance rather than engage the internal hypervisor team to redeploy the VM. This might sound strange but in some very large enterprise environments where multiple third parties are responsible for systems liken networks, security, storage, etc, something as simple as a VM rebuild can be tedious.
-  * Avoids a chicken/egg situation were a crashed storage systems needs DNS in order to boot but the DNS server is a VM that is offline because the storage system crashed (true story - this caused one Infoblox customer to revert their migration to fully virtual Infoblox). In another case when the storage systems came back online, VM's couldn't start because VCenter couldn't resolve the hosts. The main question is this, "If I power off ALL my equipment in the DC, can I power it all back on or will the fact that the DNS server (and possibly DHCP server) is virtualization prevent the hypervisor system (looking at you VMware) from booting?". ESXi & VCenter (Vcloud director) needs to do forward and reverse lookups to boot. If you are going to virtualize everything, make sure you can boot everything from a full "power off" globally.
+  * Avoids a chicken/egg situation were a crashed storage systems needs DNS in order to boot but the DNS server is a VM that is offline because the storage system crashed (true story - this caused one Infoblox customer to revert their migration to a fully virtual Infoblox deployment all the way back to a physical deployment). In another case when the storage systems came back online, VM's couldn't start because VCenter couldn't resolve the hosts. The main question is this, "If I power off ALL my equipment in the DC, can I power it all back on or will the fact that the DNS server (and possibly DHCP server) is virtualization prevent the hypervisor system (looking at you VMware) from booting?". ESXi & VCenter (Vcloud director) needs to do forward and reverse lookups to boot. If you are going to virtualize everything, make sure you can boot everything from a full "power off" globally.
   * Allows services to be run on segments of the network that security will not permit VM's to be run. For example, some organizations will not allow guest DNS/DHCP to be run on VM's that are running inside the corporate VM environment.
   * Allows services to be run where there is no hypervisor capacity. For example, a large but remote office that has not VM capacity. You can deploy hardware appliances or deploy a Hypervisor stack and then virtual Infoblox's. This second option would give you VM's but also extra infrastructure to manage and more software to patch and keep secure.
@@ Line 382: / Line 400: @@
 ====Challenges with Hardware====
 As a side note; a common time for PSU to fail is at reboot of appliance due to temporary surge of power at boot.
+**NOTE**: the "challenges" below are not necessarily problems or challenges to everyone. In some cases they can be viewed as beneficial. The main point of the list below is to give you things to consider around processes. Make sure you have a plan for every eventuality. Consider high-availabily for member deployment and also consider "on-site spare" if you have deployed in a region that does not have next-day delivery.
   * Hardware is an additional capital expenditure. In addition to the capital cost of the hardware itself, there is also the operational cost of the hardware support contact (separate to the software subscription).
-  * If a failure of virtual appliance, it can be much easier to get console access via the hypervisor than on hardware (depending on whether console access has been setup on hardware. This also assumes Infoblox team have been given access to hypervisor). This also means actions like forcing a reboot, etc can be much easier. With hardware on remote sites, getting console access can be difficult. Especially in high security data centers when the Infoblox team themselves may not be permitted access and may have to arrange for authorized "local hands" to access the hardware unit and be talked through getting console access.
+  * If a failure of virtual appliance, it can be much easier to get console access via the hypervisor than on failed/failing hardware (depending on whether console access has been setup on hardware. This also assumes Infoblox team have been given access to hypervisor). This also means actions like forcing a reboot, etc can be much easier. With hardware on remote sites, getting console access can be difficult. Especially in high security data centers when the Infoblox team themselves may not be permitted access and may have to arrange for authorized "local hands" to access the hardware unit and be talked through getting console access.
   * If an appliance failure occurs, a VM can just be redeployed (assuming a well functioning hypervisor team). Hardware needs to be RMA'd. This can be really easy but can also be time consuming and frustrating depending on the environment. The larger the enterprise and the more global the network, the more issues you can run into. RMA means
     - Support will require end user to verify need for RMA using console connection. Depending on the environment (think highly secure remote DC), this can present a challenge to the customer. (This is normal across most vendors).
-    - Once Support have authorized the RMA, the depot must process it and this is where "Next Business Day" can frustrate the customer. N
+    - Once Support have authorized the RMA, the depot must process it and this is where "Next Business Day" can frustrate the customer.
-    - BD means next business day after the depot has shipped the hardware. However, in order to ship hardware, Depot must receive the RMA order before 15:00 local time and depot don't work public holidays, etc.
+    - NBD means next business day after the depot has shipped the hardware. However, in order to ship hardware, Depot must receive the RMA order before 15:00 local time and depot don't work public holidays, etc.
     - Before the RMA order goes to depot, support must run some verification that the appliance is dead which requires some local diagnostic. Problem is, if the costumer has an environment that makes it difficult to get this data, the RMA order may be delays.
     - For example, customer does a reboot on Friday night and the box doesn't come back, customer can't get someone on sight properly until Tuesday because of a bank holiday Monday. Once local hands help support show RMA is needed, support issue RMA but after 15:00 local time. RMA gets picked up on Wed for a Thursday delivery. Thus the box failed on Friday and RMA arrived the following Thursday (while falling inside the "NBD" t&c)
     - In very rare cases, an RMA may be delayed because of an administrative issue (e.g. shipping paperwork, trade regulation changes, etc)
-    - Finally, customer may not provide full data to Infoblox around shipping numbers to quote when hardware arrives at data center. This can result in the RMA being rejected and requiring a reschedule of the appliance.
+    - Finally, customer may not provide full data to Infoblox around shipping numbers/access codes to provide when hardware arrives at data center. This can result in the RMA being rejected and requiring a reschedule of the appliance.
-  * TE-906 doesn't have RAID. TE-1506 doesn't have RAID. TE-1606 has RAID-1. TE-2306 and TE-4106 have RAID-10. All models support dual PSU. TE-906 must have dual PSU specified at purchase and the TE-1506 must have the second PSU added during or after purchase.
+  * TE-906 doesn't have RAID. TE-1506 doesn't have RAID. TE-1606 has RAID-1. TE-2306 and TE-4106 have RAID-10. All models support dual PSU. TE-906 must have dual PSU specified at purchase and the TE-1506 must have the second PSU added during or after purchase. Technically the TE-906-2AC hardware is dual PSU but NOT hot-swappable.
   * B1-212 hardware has single SSD and single PSU.
   * Capital expense of hardware and on going support cost (operational cost) of hardware in addition to the cost of the NIOS software. Further more, with a virtual NIOS appliance (e.g. TE-926), if you want to upgrade you can just pay the difference between that and the higher model you want (e.g. TE-1516). However, if you have hardware, not only do you need to pay the delta, you must also buy new hardware (e.g. TE-1506 hardware for TE-1516 software).