I run a bitcoind that is available on two external IPs at the same time. You need to forward your port 8333 on both external connections on the router to the machine running bitcoind in your internal network. Plus you need some rule/process for determining which outgoing connections go out via which interface.
If both connections are alive at the same time you should appear to the world as to separate nodes on your two external ips. If you only turn on the secondary ip when the first fails you would have some time for the existing nodes to go stale. I think it's 90mins. Of course your outbound connections should refresh sooner but old connections may sit there for 90mins before formally closed.
Also from the point of view of bitcoin your external ip has changed. You need to probably implement this PR for it to work well, otherwise it may never advertise the new external ip:
https://github.com/bitcoin/bitcoin/pull/5161
Also see https://github.com/bitcoin/bitcoin/issues/48
In my case I do not need ot advertise the second ip so it's not an issue.
Topic: Running bitcoind across multiple connections (Read 1053 times)
The connection switching is done at the router; nothing changes on the actual machine (the primary/backup internet connection is for the entire network).
Sounds like your "router" is actually a "NAT gateway/router". Get a better one doing a proper maintenance of the NAT state which will close all the stale NAT entries and send proper ICMP responses (edit: or TCP RST) to your machine.So if the primary internet connection goes down, a secondary backup connection automatically kicks in.
What do you mean by "automatically kicks in"?I've seen many multihomed machines with incorrectly set up routing tables that continue to send packets via if1 with the source address of if0. With correctly set up routing the ICMP no-route replies take care of closing stale if0 sockets.
The connection switching is done at the router; nothing changes on the actual machine (the primary/backup internet connection is for the entire network).
So if the primary internet connection goes down, a secondary backup connection automatically kicks in.
What do you mean by "automatically kicks in"?I've seen many multihomed machines with incorrectly set up routing tables that continue to send packets via if1 with the source address of if0. With correctly set up routing the ICMP no-route replies take care of closing stale if0 sockets.
I have bitcoind setup with a fallback connection on the network.
So if the primary internet connection goes down, a secondary backup connection automatically kicks in.
The problem is that when the connection/IP is changed all existing peer connections hang and take really long time to connect to different peers.
Possible solutions:
- Is there a way to set a peer ping timeout? So that if a peer takes longer than say 10seconds it is replaced
- Is there a way to force bitcoind to reconnect/replace all new peer connections?
I'm guessing many of the existing peers are already tied up with the primary connection IP, so potentially do not have any free spots for the new IP, so probably would need to find new peers.
So if the primary internet connection goes down, a secondary backup connection automatically kicks in.
The problem is that when the connection/IP is changed all existing peer connections hang and take really long time to connect to different peers.
Possible solutions:
- Is there a way to set a peer ping timeout? So that if a peer takes longer than say 10seconds it is replaced
- Is there a way to force bitcoind to reconnect/replace all new peer connections?
I'm guessing many of the existing peers are already tied up with the primary connection IP, so potentially do not have any free spots for the new IP, so probably would need to find new peers.
Jump to: