[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-relays] Re: Consensus frequently reports relay down, despite relay passing traffic



"Is the relay still useful to the network? I am seeing traffic pass through it without issue."
Yes, useful, as long as traffic passes through. Appears that is happening as the relay is reporting bandwidth, 39.67 Mbit/s.
How useful or is there a more useful approach? Up to you.

The issue seems to be more related to at least 8 and sometimes 9 of the 9 voting directory authorities lack of ability to keep a reliable connection via ORPort probes (roughly hourly) with your relay. Reported via "Stable MTBF", also reflected in Guard and HSDir WFU. Attached screenshot.

Relay uptime is also an issue, less than a day, but that's more under relay operator direct control.

Source: https://metrics.1aeo.com/relay/E21B4A2C2852298186C0EA7E2F900EF03AE38D69/
Consensus details: https://metrics.1aeo.com/relay/E21B4A2C2852298186C0EA7E2F900EF03AE38D69/#consensus-evaluation


"The other locations I can migrate to are Kazan
(KAZ1, looking glass 176.32.33.241), St. Petersburg (LED1, looking glass 194.87.196.227), and two DCs in Moscow (MOW1 and MOW2, LG 45.140.169.150 and 195.133.10.134, respectively)."

Very hard to predict! One approach is get the cheapest instance possible in each location and setup a relay in each location and watch how they scale traffic. Keep the best one and cancel the other ones. Can then scale up the best one as you prefer.


"I am concerned that it is harming the network by breaking the assumption that every relay can reach every other relay. But then again, I don't know how many relays it is unable to reach."

Better to run a relay than to not run a relay.
These are relative trade-offs. Assuming all else equal:
A relay that can reach part of the network is better than no relay. A relay that can reach all of the network is better than a relay that can reach part of the network.
There are many factors that influence the contributions of a relay to Tor, i.e. bandwidth, geographic location, diversity of providers, upstream, location, etc.



On Friday, December 26th, 2025 at 2:41 AM, forest-relay-contact--- via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> wrote:

> 

> 

> Hello.
> 

> Roger Dingledine wrote:
> 

> > Since this is a Russian router we are talking about, one possibility
> > is that they are censoring the public Tor relay IP addresses, but
> > doing it only sometimes, or on some routes (which could look like
> > sometimes as the routes change).
> 

> 

> Is the relay still useful to the network? I am seeing traffic pass
> through it without issue. I could ask the host to move it to one of four
> other locations in Russia. I chose Novosibirsk (OVB1) because it is near
> mainland China and I figure it would be helpful to improve geographic
> diversity, especially with routes to China (Novosibirsk is as far away
> from Europe as possible). The other locations I can migrate to are Kazan
> (KAZ1, looking glass 176.32.33.241), St. Petersburg (LED1, looking glass
> 194.87.196.227), and two DCs in Moscow (MOW1 and MOW2, LG 45.140.169.150
> and 195.133.10.134, respectively). Their online ping test shows that all
> authorities are accessible from all of their locations, at least now.
> 

> On a related note, I do have a relay in Hungary which has connectivity
> issues with several of my other relays (4 out of 31). It passes a fair
> bit of traffic regularly and has no issues with connecting to any of the
> authorities. Would it be appropriate for me to try to ping every relay
> in the consensus to try to map its connectivity? I am concerned that it
> is harming the network by breaking the assumption that every relay can
> reach every other relay. But then again, I don't know how many relays it
> is unable to reach.
> 

> Regards,
> forest

Attachment: image.png
Description: PNG image

Attachment: publickey - tor@1aeo.com - 0x9288289B.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx