Too many Erigon P2P Connections, it made the P2P service hard to maintain

[brilliant-lx]

System information

Geth version: geth v1.1.21. // It is irrelevant to Geth version
OS & Version: Linux

Expected behavior

The P2P connection should be at a reasonable level, better not reach the up limit, defined by MaxPeers

Actual behavior

MaxPeers has been set to 3500, but the P2P connection reached the up limit very soon.
I dump the peers list, found 2 weird things:
1.Erigon client takes ~2/3 of the peers;

"name": "erigon/v2.32.0/linux-amd64/go1.18.7",
...

2.Erigon client would keep tens of p2p connections with same IP address.
Attach the log of admin.peers
admin_peers_1.log

Here is some screenshot from the log:

Steps to reproduce the behavior

You should setup an public bsc node, let many other peers connect to you. And you can observe the connected peer list.
But may not easy to reproduce in you device, since we have famous P2P nodes, which is much likely to be connected.

Backtrace

NA

When submitting logs: please submit them as text and not screenshots.

[wellgamer789]

They are almost all "fake nodes", they don't send anything, they just consume and receive

It's been more than 4 months that I've noticed that their number is very high, in any region of the planet they will only connect to you if you are using the "official build"

And that "Erigon" is a name that the guy put, they are not really Erigon nodes

[fbit]

Just an idea:

Wouldn't it be possible to create a patch/fix so that only one or two peers with the same remoteAddress (IP) are accepted at the same time? This way those evil nodes wouldn't be able to spam and block other nodes.... well unless they deploy on hundreds of servers with different IP addresses.

[brilliant-lx]

Just an idea:
Wouldn't it be possible to create a patch/fix so that only one or two peers with the same remoteAddress (IP) are accepted at the same time? This way those evil nodes wouldn't be able to spam and block other nodes.... well unless they deploy on hundreds of servers with different IP addresses.

thank you for you advice, we have applied it in some of the P2P nodes, may consider to raise a formal patch to limit the Max connection number per IP.

[MatusKysel]

I was looking into that and those Erigon nodes are useless mostly because they are not running bsc chain at all. A lot of them are eth nodes or other networks. Limiting IPs is partial solution, but there is PR #1320
that should solve issue with all of those non-bsc peers

[kaber2]

I was looking into that and those Erigon nodes are useless mostly because they are not running bsc chain at all. A lot of them are eth nodes or other networks. Limiting IPs is partial solution, but there is PR #1320 that should solve issue with all of those non-bsc peers

Just a datapoint regarding PR #1320 - I installed it on one of my nodes for testing, the ratio of these fake peers to real peers is still at around 2:1, as it was before.

[MatusKysel]

I was looking into that and those Erigon nodes are useless mostly because they are not running bsc chain at all. A lot of them are eth nodes or other networks. Limiting IPs is partial solution, but there is PR #1320 that should solve issue with all of those non-bsc peers

Just a datapoint regarding PR #1320 - I installed it on one of my nodes for testing, the ratio of these fake peers to real peers is still at around 2:1, as it was before.

could you provide logs of those peer, especially enodes so I could connect to them and debug but it

[kaber2]

I was looking into that and those Erigon nodes are useless mostly because they are not running bsc chain at all. A lot of them are eth nodes or other networks. Limiting IPs is partial solution, but there is PR #1320 that should solve issue with all of those non-bsc peers

Just a datapoint regarding PR #1320 - I installed it on one of my nodes for testing, the ratio of these fake peers to real peers is still at around 2:1, as it was before.

could you provide logs of those peer, especially enodes so I could connect to them and debug but it

I will try to collect some, will take a day or two though.

Just to make sure there's no misunderstanding. I'm not saying that the patch doesn't work, just that it doesn't help for the fake peers. As far as I could see, all of them were incoming connections, so unaffected by your patch.

[fbit]

Is there any news on this? I also applied PR #1320 and indeed there are fewer erigon nodes in the peer list now. However, there are still some and also a lot of other peers with same remote IP addresses (but with "geth" clients) which I think are fake nodes, too.
As stated by @kaber2 , maybe it would be neccessary to also apply a filter on incoming connections.

[fbit]

geth_peers.txt

Here is the peer list of one of our nodes, sorted by remote IP.

[mbwmbw1337]

What is the command you're using to dump the peers I want to try from my nodes as well.