Hi, First post here so hopefully post is displayed correctly 
I recently setup a 2nd relay for my pool “FLOW”. All seems to work fine. Both relays appears connected, tx are increasing, pool.vet show no issues… However when doing peer analysis in gLiveView from my block producer the new relay is always “unreachable” in the “IN” section (ref. picture below). I cannot see that I have done any different in setting up my two relays. Anyone know why the relay is marked as “unreachable” and/or is this a problem?
Hi!
Right now I dont know how the RTT (round trip time) is calculated - my guess is with ping…
can you ping your relay IP address from BP node?
Yes ping gives this result:
64 bytes from x.x.x.x: icmp_seq=3 ttl=56 time=31.4 ms
Press info [I] in glive and read the infos
Cheers,
1 Like
Ahh, thanks. Then I understand that ICMP is disabled in the new relay while not so in the 1st relay and that “unreachable” notion for the “In” peers is unproblematic
"For incoming connections, only ICMP ping is used as remote │
│ peer port is unknown. It’s not uncommon to see many │
│ unreachable peers for incoming connections as it’s a good │
│ security practice to disable ICMP in firewall. "
1 Like
For information to others that might experience the same issue:
After a bit of research I found that the “unreachable” notion is caused by the following line under “# ok icmp codes for INPUT”:
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP
in the file that can be read/edited by this command:
sudo nano /etc/ufw/before.rules
but as the info says it is a good security practice to keep it like this
2 Likes