# Ipfs config Peering.Peers modification and effect?

**URL:** <https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119>\
**Category:** Uncategorized\
**Created:** [September 4, 2021, 11:11pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119 "2021-09-04T23:11:35Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![qo-op](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/qo-op/32/1773_2.png) [@qo-op](https://discuss.ipfs.tech/u/qo-op)\
**Post date:** [September 4, 2021, 11:11pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/1 "2021-09-04T23:11:35Z")

</div>

I recently discovered Peering.Peers config

> <https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#peering>

I would like to use it to enhance swarm connectivity quality.  
I cannot succeed using ipfs config --json to change it with a jq prepared file?  
Does the effect is needing daemon restart or it is reloaded automatically?

Does anyone already uses this parameter?

Thanks for your help

---

<div class="post-metadata">

**Author:** ![ylempereur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ylempereur/32/5528_2.png) [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)\
**Post date:** [September 9, 2021, 12:10am UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/2 "2021-09-09T00:10:35Z")

</div>

I use it to keep my laptop and my desktop connected whenever they are both up, it works great. The first thing you need to know is that you need to control both sides and that both need to have peering entries pointing at each other. Never have one sided peering, it only leads to grief. Second, yes, you need to restart after changing the config file for the changes to take effect. Third, here is what it looks like on one of my nodes (I redacted the ID):

```auto
"Peering": {
	"Peers": [
		{
			"Addrs": [],
			"ID": "12D3KooW..."
		}
	]
},

```

You don’t need to enter addresses if your node is able to connect to the network, it will use the network to look up the addresses for that node (which is key for my laptop, as its address depends on where I am connecting from, which changes). Of course, at least one of the two nodes needs to be able to dial the other, or it will never work. Again, make sure that both ends of a peering agreement are configured.

---

<div class="post-metadata">

**Author:** ![thomasfreedman](https://avatars.discourse-cdn.com/v4/letter/t/9de0a6/32.png) [@thomasfreedman](https://discuss.ipfs.tech/u/thomasfreedman)\
**Post date:** [February 5, 2022, 7:31pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/3 "2022-02-05T19:31:44Z")

</div>

Why do both sides need to have a peering section?

I run servers at datacenters and many other IPFS nodes have a peering/peers config file section to point to those datacenters. One side is transient like in your example the other side not.

It makes sense for transient nodes to have a peering section, not so useful for the datacenters (tho they do, and point to each other NOT any transient nodes).

I thought the peering section would get around the need to use the DHT to determine routing and for nodes listed in the peering section of the config file would provide essentially direct routing.

When I initialize a new (transient) node I add the peerIDs for the datacenters then start the new IPFS instance. It definitely doesn’t act like a direct routing path!

---

<div class="post-metadata">

**Author:** ![ylempereur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ylempereur/32/5528_2.png) [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)\
**Post date:** [February 5, 2022, 9:23pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/4 "2022-02-05T21:23:00Z")

</div>

Peering is a relationship. A one-sided relationship is called stalking. All jokes aside, here is an excerpt from the docs:

Peering can be asymmetric or symmetric:

- When symmetric, the connection will be protected by both nodes and will likely  
be vary stable.
- When asymmetric, only one node (the node that configured peering) will protect  
the connection and attempt to re-connect to the peered node on disconnect. If  
the peered node is under heavy load and/or has a low connection limit, the  
connection may flap repeatedly. Be careful when asymmetrically peering to not  
overload peers.

[Peering](https://docs.ipfs.io/how-to/configure-node/#peering)

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [February 6, 2022, 12:28pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/5 "2022-02-06T12:28:32Z")

</div>

> [@ylempereur](#):
>
> The first thing you need to know is that you need to control both sides and that both need to have peering entries

That false btw.  
You can peer with someone that doesn’t peer with you.  
It is still better for both sides to peer together because then the connection will be stable.

The difference is that if the peering is **non** -reciprocal the other peer (the one who havn’t added to it’s peering table) will close the connection from time to time because it thinks it is useless.  
Then the peered node will reopen the connection right after.

---

<div class="post-metadata">

**Author:** ![ylempereur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ylempereur/32/5528_2.png) [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)\
**Post date:** [February 6, 2022, 3:58pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/6 "2022-02-06T15:58:39Z")

</div>

I’m not saying you can _never_ use asymmetric peering, I’m saying that, if your goal is to do it with a well known public server, **don’t**! Please see my other post on the matter, which goes into more details as to why it should **not** be encouraged:

[Peering with a well known server](https://discuss.ipfs.tech/t/why-so-long-to-connect-with-known-peers/13372/4)

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [February 6, 2022, 4:07pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/7 "2022-02-06T16:07:09Z")

</div>

Ok so in the end we agree. 🙂  
It’s just that to me “_`you need`_” sounds like this is an absolute requirement and if you don’t do symetric peering then it wont work.

---

<div class="post-metadata">

**Author:** ![ylempereur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ylempereur/32/5528_2.png) [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)\
**Post date:** [February 6, 2022, 4:14pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/8 "2022-02-06T16:14:57Z")

</div>

Yeah, I agree. I worded it that way on purpose though, hoping that it would discourage some from peering with public servers. Anyway, I later pasted from the docs, which clearly state what the exact situation is, and what the potential downside is.

---

<div class="post-metadata">

**Author:** ![thomasfreedman](https://avatars.discourse-cdn.com/v4/letter/t/9de0a6/32.png) [@thomasfreedman](https://discuss.ipfs.tech/u/thomasfreedman)\
**Post date:** [February 14, 2022, 8:17pm UTC](https://discuss.ipfs.tech/t/ipfs-config-peering-peers-modification-and-effect/12119/9 "2022-02-14T20:17:16Z")

</div>

I’m grateful for the discussion. I came away with the impression “if you don’t do symetric peering then it wont work”.

I used the term “public server”, but it will only be public to those I share the connection info with; there is no public gateway like [gateway.ipfs.io](http://gateway.ipfs.io) is, no proxied interface to port 8080.

My plan stands as sound then and I will continue using the peering/peers section in the config file.

This discussion provides one reason that new nodes can’t ping or connect to my main servers (they’re too busy to respond), but that seems unlikely.

On slightly older nodes I can connect & get files with minimal delay, so I am still at a loss as to why new nodes timeout waiting for a connection to my main servers.

I know there’s a significant bandwidth hit when a new IPFS node is brought online, but that spike should be well past 24 hrs later.
