# Bind to multiple interfaces for redundancy failover

**URL:** <https://forum.inductiveautomation.com/t/bind-to-multiple-interfaces-for-redundancy-failover/97623>\
**Category:** Ignition\
**Tags:** redundancy\
**Created:** [October 22, 2024, 4:28pm UTC](https://forum.inductiveautomation.com/t/bind-to-multiple-interfaces-for-redundancy-failover/97623 "2024-10-22T16:28:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jules\_Lalu](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@Jules\_Lalu](https://forum.inductiveautomation.com/u/Jules_Lalu)\
**Post date:** [October 22, 2024, 4:28pm UTC](https://forum.inductiveautomation.com/t/bind-to-multiple-interfaces-for-redundancy-failover/97623/1 "2024-10-22T16:28:12Z")

</div>

Hi,

We are using a redundant Ignition setup with a master and backup.  
Each Ignition instance has 2 network interfaces. We would like to fail over to the backup instance if one of the 2 network interfaces is unreachable on the main, but currently the failover happens only when the first network interface of the main is down.  
We have seen that there was a parameter in Redundancy -\> Network settings called "Network Bind Interface", however specifying both ip adresses of our interfaces with syntax "123.456.789.012,123.456.789.013" does not seem to work.

Is there a way to make this work ? Or at least a workaround ?

Thank you in advance for your help.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [October 22, 2024, 4:35pm UTC](https://forum.inductiveautomation.com/t/bind-to-multiple-interfaces-for-redundancy-failover/97623/2 "2024-10-22T16:35:55Z")

</div>

> [@Jules\_Lalu](#):
>
> We are using a redundant Ignition setup with a master and backup.  
> Each Ignition instance has 2 network interfaces.

Not a good plan.

See my answer here for a similar question:

> [@Architecture for Distributed Control Center](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/9):
>
> Ignition redundancy is both latency sensitive and subject to split brain syndrome. If the comms goes down between sites, both servers will end up active and therefore numerous properties start to diverge. So let me amend my answer to: Ignition redundant servers must be installed on a common LAN with a robust network layout (preferably multi-path, like RTSP), such that any loss of comms also results in loss of comms to all clients and all devices and all databases. (Trunk port for multiple VL…

Related discussion:

> [@Client connections to server with multiple NICs](https://forum.inductiveautomation.com/t/client-connections-to-server-with-multiple-nics/90473/4):
>
> That is a design error. The redundant gateway needs to be on the exact same networks as the primary gateway. And both primary and redundant gateways need to be set to use their names as their public addresses. If you are connecting remotely, put entries in your own /etc/hosts file with the appropriate names if you cannot make your local DNS provide them. (In most cases, there should not be a redundancy network. It can lead to "split brain" situations.)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [October 22, 2024, 4:36pm UTC](https://forum.inductiveautomation.com/t/bind-to-multiple-interfaces-for-redundancy-failover/97623/3 "2024-10-22T16:36:47Z")

</div>

This is the key requirement:

> [@Architecture for Distributed Control Center](https://forum.inductiveautomation.com/t/architecture-for-distributed-control-center/85104/9):
>
> any loss of comms also results in loss of comms to all clients and all devices and all databases

Also, all clients should target main and backup servers via DNS name, not IP address, and the gateways should be publicly advertising their DNS names.
