SOLVED: Node Red running on a device with 2 IP connections

Can someone who has worked with this please tell me if there is something which can be configured in the settings.js file where i can have node red work on the 2 IP addresses which are connected to my pi?

I have a custom board which allows 2 connections on the PI by assigning 2 IPs.
I need to know what can i do to ensure that node red is running as long as one of the 2 ports have an active connection.


Node-RED utilises all ports by default.

You don't need anything special just because there are 2 ports. Node-RED doesn't care.

So it comes down to how do you detect if any client is connected.

For that, do you mean the Editor, Dashboard, http-in/out, uibuilder, ....? If everything, it is probably easiest to do a netstat or similar shell command to see how many active connections the Node-RED process currently has.

I used the wrong terminology. Sorry. Let me rephrase what i meant :slight_smile:

I have 2 IP Cat6 cables coming onto my board which houses the raspberry pi. Now when the pi boots up, and i do ifconfig, here is what i have.

NOTE: Only 1 Network is connected physically. Both IPs are set to static. So the IP addresses are & (1.15 isn't showing up since i have not physically connected it)

My question is if i connect my second IP cable physically, how can i make sure that the node red service which was running initially on IP is seamlessly now working on when 1.10 is unplugged?

Hope this is clear :stuck_out_tongue:

You can simply ping the address to see which if is active. But to check whether Node-RED is alive on that IF, you could run a request. If I remember rightly, the admin API provides a /ping url? check the api docs. Otherwise just do a request against a simple admin api get url for both IP addresses and catch the one that fails.

I have been re-reading it for a while and im a little clueless on what i should do :frowning:
I don't believe theres a method that provides the ping you were referring to

What did you mean by run a request?

I came across this post here

This one talks about making a static IP against uiHost.
Is it possible for me to have 2 IP's here or am i going completely off track with this train of thought?

This is a quite interesting question. You are close to find out the answer as you already have the environment ready for testing. What happens when you initiate Node-RED with both ethernet cables connected to your board (both interfaces up at the same time) ? Can you access the editor with both addresses ? Unless my mistake you did not state that this configuration is not working. Now, when you disconnect one of the cables what happens ? Are you still able to reach Node-RED via the interface that remained up ?

What i have noticed is that when the pi is boot up with 2 IPs there is an issue with Node red starting since it is confused where to start.
When i have eth0 plugged in, it comes up. No issues. After a bit, when i plug in eth1, another instance of NR is running on eth1 as well.

I can access the NR editor on both IP:1880 end points. But when my eth0 is unplugged, eth1 NR is running, but my MQTT flow on both don't behave identical. When eth0 goes down, mqtt on eth1 isn't doing what its expected to do.

In such case perhaps you will have to change the troubleshooting focus to MQTT. It would help to understand if you lose ip connectivity from your board to the MQTT server when you change ethernet cables. Do you see the status indicator in the MQTT node going from green to red (disconnected) when you change cables ? How is the "Connect automatically" check box in the configuration dialog of the MQTT node ?

Sadly, since i am working on the raspberry pi zero, i can't really see the NR editor on local host. I am running on a custom board and if i hook a hdmi cable to the pi, the current supply is not enough to the pi and the pi keeps rebooting.

What i can see is that the MQTT nodes are connected on the second IP and when i (for example: move a node and redeploy) comms is established with my MQTT broker on the second Pi and everything is working well.

I don't know how to make this happen automatically.

This is my MQTT node setting on both my main IP and redundant IP

OK you are not really doing this the right way and are asking to give intermittent issues which will vary depending on what other equipment you have in your environment.

What is the Cat5/6 cable connecting to - i assume it is a single switch ?

You immediate problem is that devices are going to populate their ARP table which lists MAC addresses and matches them to IP Addresses.

In the case of the PI clone - it thinks that MAC address XYZ with IP Address ABC lives on interface Eth0, when you plug in the 2nd interface into the PI - and have it connected to the same IP Subnet you will get different results depending on what devices are involved (the permutations are large and endless !)

Your best bet to achieve what i believe you want (which is a failover in the event that the primary ethernet card fails or the connection is lost) is to setup the cards in a failover configuration on the PI.

Note that various modes of bonding require different levels of support from the switch they are attached to - to work correctly

If that is not what you are trying to achieve then please explain a bit further what the end result is you would like


Thanks for your reply. I did read through this. What i did see is that 1 have node-red available on both the IP addresses. If network 1 fails, i need to hit deploy on the node red running on the second IP to get node red started on the 2nd network.

Is there a command line command which will allow me to restart the flow?
This will solve my issue

What is important if both ip's are in a subnet that can reach the broker.

If you only want to reach the broker through one interface use an IP route.

If you want to reach the broker through both interfaces make sure that both interfaces can reach the mqtt broker on the same IP. (Or do something with a DNS resolve solution).

Good luck!

Depends on how you are running Node-RED. If you are running it via systemd, it is easy, sudo systemctl restart node-red (or whatever your node-red service name is called). If not, there are other ways.

I think you are mixing up your terminology here.

When you say if "network 1 fails" what does this mean ?? - do you mean the card fails in the Node red machine, or the cable breaks, or the switch it is connected to fails ?

I am not really sure what you are trying to achieve here at the end of the day


When i say network 1 fails, i mean i pull the network cable out to simulate a network failure on port 1 of the board which has 2 RJ45s.

i think i managed to get this working with the command "node red flows.json".
This is as good as hitting the deploy button on the node red editor which then starts my node red communication on network 2

Yes but as soon as you close your terminal session to the box that will close down NR. Assuming you are talking RPi/Linux

I am still not understanding what failures you are trying to guard against - if the port fails on the box (which is pretty unlikely) why would you not have just put in place the seamless solution of some form of trunking that i listed above to enable automatic failover ?


Hi Craig, it is possible - though these days not terribly likely in most networks - for a specific network segment or even a network card on a device to fail. If you want high levels of resilience, it isn't unreasonable to create 2 network connections.

However, usually, you would configure the network resilience at the OS level so that the OS itself is able to use both networks and then you don't really need to worry about Node-RED which, by default listens on all networks unless you've configured it otherwise.

THe one issue you might get is having the two networks on different subnets. If that is the case and you lose access to one of them, any active users are likely to need to reload any active pages.

You should also have local DNS set up so that you aren't forcing users to know the IP addresses. The DNS can have two routes for a single address which means that client traffic will use the secondary IP if the primary isn't responding.