Need Help, while creating private ipfs network, nodes are unable to automatically discover each other

Help
1

Can nodes in private network discover other nodes as long as they are connected to the same bootstrap nodes ??

Here’s my setup :

i have two ipfs peers running on aws which will be acting as my default bootstrap list of peers. (I have given both instances all trafic access)
ip’s : 35.x.x.x, 18.x.x.x

Now, i have two peers who want to connect to the network, For both of these peers, i have the same bootstrap list
ip’s 202.x.x.x, 13.x.x.x

i first connected those two aws instances by doing bootstrap add on itself and on other instance:
Then, from 202.x.x.x, peer,
i added peer 35.x.x.x, the other peer 18.x.x.x got automatically connected in the swarm
so both 35.x.x.x and 18.x.x.x are in the swarm list (as shown below)

Then from 13.x.x.x
i added peer 35.x.x.x, the other peer 18.x.x.x got automatically connected in the swarm
so both 35.x.x.x and 18.x.x.x are in the swarm list (as shown below)

I am unable to see 202.x.x.x in the swarm list of 13.x.x.x?
similar result for other peer as well,
Unable to see 13.x.x.x in 202.x.x.x swarm peers list

In aws instances,
the swarm peers got updated on both automatically i.e. on both instances there were all three in the list :
Here’s the swarm list of all four :

for 35.x.x.x:
ipfs swarm peers :
/ip4/13.57.42.38/tcp/4001/ipfs/QmdWGvbcd1MqCVbhLsfeafHQtAv9hs7bPjkjB4Ynnj556A
/ip4/18.144.10.0/tcp/4001/ipfs/QmX69CqLJUx1DeGCz9dtq3rJD2VW3ExEtA3vx492Ztdu1U
/ip4/202.131.123.110/tcp/4001/ipfs/QmfQuUjG38bEakdf6Q1rxeX2tqis1DQFZfym9DYPFeLaoH

for 18.x.x.x
ipfs swarm peers
/ip4/13.57.42.38/tcp/4001/ipfs/QmdWGvbcd1MqCVbhLsfeafHQtAv9hs7bPjkjB4Ynnj556A
/ip4/202.131.123.110/tcp/4001/ipfs/QmfQuUjG38bEakdf6Q1rxeX2tqis1DQFZfym9DYPFeLaoH
/ip4/35.154.130.223/tcp/4001/ipfs/QmPhRnBxiaKzZbWneR7kQQW1TkfcLdiy3TAg1L6y9BSN32

for 202.x.x.x
ipfs swarm peers
/ip4/18.144.10.0/tcp/4001/ipfs/QmX69CqLJUx1DeGCz9dtq3rJD2VW3ExEtA3vx492Ztdu1U
/ip4/35.154.130.223/tcp/4001/ipfs/QmPhRnBxiaKzZbWneR7kQQW1TkfcLdiy3TAg1L6y9BSN32

for 13.x.x.x
ipfs swarm peers
/ip4/18.144.10.0/tcp/4001/ipfs/QmX69CqLJUx1DeGCz9dtq3rJD2VW3ExEtA3vx492Ztdu1U
/ip4/35.154.130.223/tcp/4001/ipfs/QmPhRnBxiaKzZbWneR7kQQW1TkfcLdiy3TAg1L6y9BSN32

Also i have done port forwarding in 202.x.x.x, 4001 port is unblocked in this network,
is there anything else i need to add in the firewall.
and i have allowed all traffic on 13.x.x.x

2

Can someone please have a look at it, letme know if you want more information

3

Are you sure that 13 and 202 can connect to each other directly? What happens if you try to connect 13 and 202 manually using ipfs swarm connect?

If the manual connection isn’t successful, you might want to take a look at AutoRelay.

4

Thanks leerspace, for replying,
Yes i double checked it, they can connect to each other manually using
ipfs swarm connect
my ipfs version is 0.4.20
should i now try AutoRelay as well, is that needed ? and
To apply AutoRelay, do i need to change my ipfs version to : 0.4.19-dev ?

5

No; that’s just the first version it was available in. So it’s also in v0.4.20 (though v0.4.21 was just released and might be worth trying in case the behavior during bootstrapping changes).

I wouldn’t expect it to make a difference though since you said the nodes can connect directly to each other (or they can in at least one direction).

I would think so, but I’m not 100% sure if peers just frantically try to connect to as many other peers as possible until they hit the LowWater mark.

I think a good test of whether this is a problem would be to add a piece of content only to 13, then try to retrieve it from 202. If you can, then they can find and connect to each other when retrieving content.

6

Gotcha, i can access data from 13, when i add it to 202 .
But, According to my project requirement, I still want to see peers in the swarm list, how can solve this now?
Thanks in advance though.

7

If they can connect to each other as needed, why do they need to always have active connections to each other?

If this is a requirement, an immediate workaround would be to configure 13 to connect to 202 (or vice versa) using ipfs swarm connect. My understanding is that manual connections done this way should be treated somewhat specially and not closed when inactive.

8

check ipfs id to see the Addresses part that will show you what addresses your nodes are advertising.

Even if you enabled port forwarding in a peer, it may be that it cannot be contacted because other peers do not know that it is available under that port (it’s not advertised and if anything they will try contacting the NAT connection outgoing port instead). If they have static IPs, you can manually advertise an ip/port by putting it in the configuration (Announce section). Once your peers are announcing they’re right addresses from the get-go, the bootstrap process should end up in everyone discovering and connecting to everyone (given the small size of the network).