Questions on IPFS LAN DHT and Local Peer Discovery

Help
, ,
1

My Private IPFS Setup
All the below nodes use a custom (private) swarm key.

Container A - Removed all the default bootstrap nodes, and added the Container A itself as the bootstrap node.
Container B - Removed all the default bootstrap nodes, and added the Container A as the bootstrap node.
Container C - Removed all the default bootstrap nodes. Did not add Container A as bootstrap node.

Observation: By running “ipfs swarm peers”, I’m able to confirm that all the three nodes are connected to each other in the swarm.

Questions

  1. (Just confirming) Is C connecting to A and B via the LAN DHT ?
  2. (Just confirming) Is A connecting to B via LAN DHT or WAN DHT ?
  3. Is there any way to see in “ipfs swarm peers” whether a peer is a LAN DHT peer or WAN DHT peer ?
  4. My understanding is that LAN DHT uses some form of local peer discovery, which broadcasts messages in the lan network and tries to find peers. Is this correct?
  5. Is there any way to disable LAN DHT in my ipfs nodes ?
2

For Question 4 and 5, I’ve found the answer - Disable MDNS in the config

Links:

3

via the LAN DHT ?

This is wrong terminology. Peers are not connected “via WAN/LAN DHT”. Nodes open connections and DHT is a service that runs on top of those connections.

Whether those connections between peers are via LAN or WAN is something that ipfs swarm peers should tell (by looking at the IP).

MDNS may have facilitated auto-discovery or LAN peers, but disabling it does not mean that those peers will never end up connected on the LAN interfaces, as they usually advertise and exchange those addresses too.

I would like to know why you want to disable LAN DHT though, as I cannot think of a good reason to do so.

4

Firstly, thanks for all the clarifications :smiley:

This is wrong terminology. Peers are not connected “via WAN/LAN DHT”.

Yes, I agree. My mistake - I used the terminology very loosely.

Nodes open connections and DHT is a service that runs on top of those connections.

Nodes need to know which multiaddr to open connections to, right ?
Here’s my understanding - pls correct me if I’m wrong.
So,

  • Nodes open connections and DHT runs on top of those connections.
  • Among other things, DHT provides the information of what nodes are in the network (Peer Records), so that we can connect to them.

This chicken-and-egg problem is solved by having bootstrap nodes (and also by Local Discovery via MDNS)

Whether those connections between peers are via LAN or WAN is something that ipfs swarm peers should tell (by looking at the IP).

Got it. Only in my case, the docker containers were running in a private network and had private ip addresses (172.17.0.2, 172.17.0.3, 172.17.0.4), so I could not tell anything by looking at the IP address. But I realize that that’s purely because of my test setup.

MDNS may have facilitated auto-discovery or LAN peers, but disabling it does not mean that those peers will never end up connected on the LAN interfaces, as they usually advertise and exchange those addresses too.

I’m slightly confused by the term “advertise”. Are you referring to this part - https://docs.ipfs.io/concepts/dht/#qualification

So even if I have MDNS disabled, when I connect to a peer (say the bootstrap node itself), will I also receive it’s LAN interface address?
But if the peer is a public machine (and is actually not part of my LAN), then this would be useless information right?
Is this why public ipfs nodes are recommended to run on server profile, so that they dont advertise their LAN interface address?

I would like to know why you want to disable LAN DHT though, as I cannot think of a good reason to do so.

One reason was curiosity :smiley:
Another reason was because I was running a private IPFS (for testing some stuff), and was slightly shocked to see Container C connecting to Container A. I realized later yesterday that that won’t happen if Container C had a different swarm key, and that there is no need to disable MDNS for this. Tested this as well, and it worked like a charm.

5

Yeah, ipfs id usually reports LAN addresses and I think those are sent to other nodes or put on the DHT (can check with ipfs id <peer_id_from_othernode>, because I’m not 100% this is still the behaviour. They are useful for other LAN peers :man_shrugging: . And yeah, one of the things the server profile does is to not let IPFS scan the whole LAN looking for other peers.