[Node Operator Question] Node consistently lagging behind by 2 hours #289
Replies: 3 comments 2 replies
-
you didn't run in snap sync(which means p2p) |
Beta Was this translation helpful? Give feedback.
-
If you use an advanced firewall/routing system you should set --p2p.advertise.ip on op-node as you have stated. I am not sure about this, but I think you may need to recheck your NAT translation/firewall rules. Also, you may need to set If it's working correctly, you should see |
Beta Was this translation helpful? Give feedback.
-
Maybe you should check your network and firewall |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Are you running the most up to date node software?
Did you check the documentation?
Did you check for duplicate questions?
Issue Description
Issue
Hi team, my node is unable to catch up with the latest block, consistently lagging behind by 2 hours. I suspect it's likely due to a P2P issue. Does GETH require exposing its own P2P for data synchronization?
Thinking
Our deployment environment is within k8s, with connectivity to the internet, but via NAT translation. Therefore, I suspect the issue is due to insufficient peers.
I attempted to call the geth peer RPC, which showed 0 peers. After consulting some documentation, it seems that the synchronization of OP-geth does not rely on GETH's P2P, is that correct? It appears to entirely rely on the OP-node's P2P.
I tried calling the RPC of opnode. Result 9 peers but found no inbound peers.
In light of this, I believe I should expose the P2P port and declare my public IP address. It seems that setting my NAT'd IP address in OP-NODE is required:
--p2p.advertise.ip value
Protocol Description
Version
op-geth: v1.101308.2
op-node: v1.7.1
op-geth args
op-node args
Node Logs
No response
Additional Information
No response
Feedback
No response
Beta Was this translation helpful? Give feedback.
All reactions