We have a new AS and a new relay is running, technical help appeciated

Support Relay Operator
1

In this November, we finally get to run a new AS (autonomous system): AS63806 (MENHERA), and a new Tor relay on it!

In Japan I live, Tor relays are very rare. I wanted to run a fast Tor relay when it became possible.

We founded a new nonprofit incorporated in Japan in January 2023, which as one of its goals promotes online privacy. Doing research, education, advocation or any independent activities, are done best with a self-controlled independent network. And so with running Tor relays.

So we applied for a new ASN at JPNIC, and as soon as we got one, we set up BGP with a few trustworthy transit providers.

Our transit providers do not bother with what we use our network for, as long as it is lawful and non-profit—mainly because the IP ranges used are ours.

Now we have a new independent network where consuming as much as 100Mbits/s worth of bandwidth 24/7, at multiple locations, is OK.

And now with a running Tor relay, I would like to know how to run a fast Tor relay best. We are running a relay on Ubuntu with the tor repository.

We did the following:

  • Ensure IPv6 connectivity

  • Use a fast VM dedicated to Tor (64GB of memory, 12 CPUs, 12th gen Intel)

  • Assign more ports for Tor

net.ipv4.ip_local_port_range=15000 64000
  • Disable UFW/stateful firewalls and just block outbound port 25 at the edge router

We also want to increase our backbone bandwidth.

Is there anything I did not mention, that helps us run a fast relay?

Open question: Does running an exit relay make our other IP addresses less usable for other activities, like sending emails?

3 Likes
2

This is overkill.
2-3 GB of RAM and 1-2 CPU cores should be enough to saturate 100Mbits/s connection.

What is usually done to utilize resources better - is launching several relays at the same machine - single Tor process can’t use all CPU cores effectively.
But with 100Mbits/s of bandwidth single relay should be enough I think. Maybe 2, but not more.

Probably you know it, but I will say it anyway: you won’t see full bandwidth utilization right away. Relay needs 1-2 months to have its Consensus Weight calculated correctly.

1 Like
3

Thanks for the information.

That can be overkill, but as we are using a shared memory/CPU configuration, assigning this much resources to the Tor VM should not harm. Anyway, we will rethink of the quota on next reboot.

And, since this one relay should be enough for the site, we are thinking of running our second Tor relay at a physically different site with different connections available (within the same AS). Anyway, I will go patient and wait for the first relay to be more actively used, before planning a second relay.

One concern is that since our network is physically in Japan, the majority of Tor network is very far and that can make our relays appear to be slow. We are also far from being a well-connected Tier-1-ish backbone. Our physical layer is 1Gbps, and on benchmarking the numbers are as high as a few hundreds of megabits per second, but accessing any networks without a IXP connection/peering at Tokyo/Osaka is much slower.

1 Like
4

Your fears are sadly true. Tor consensus weights are lower in Asia, because you are measuring with another relay most likely in Europe and therefore appear slower. And since you can’t obviously cross Russia or China, very less both, your traffic has to cross the Pacific, the US, and then the Atlantic. Which means a low consensus weight.

For instance, South Korea has some of the best broadband in the world, yet their relays are slow, whereas a similar connection in Sweden or Switzerland means a fast relay.

A big reason for this is expensive transit in Asia, where people find it cost-prohibitive to host in Asia if not their home, along with the “workaholic” Asian cultures which prevent people from even having hobbies like running Tor relays, they’re so consumed in work and nothing else. My parents are from India, and I can confirm many Asian cultures are very much this.

1 Like
5

Japanese people around me tend to say: “I have nothing to hide. Tor is for criminals. I do not want to use Tor to risk spotted using Tor by police, for example.”

Despite the fact that Japanese government is part of a big Western surveilance network, people here are likely to trust their own government, and they only fears when they find the services they use are associated with countries they dislike, e.g. China, Russia, or South Korea (South Korea is a “Western” country, but many Japanese people dislike it).

I think it is difficult to make Tor more common in East Asia without changing this “atmosphere”. As a privacy-promoting nonprofit, we must do something to improve this situation.

1 Like
6

Our Tor relay suddenly observed an excessive growth in traffic (without any meaningful changes in consensus weights) up to 120Mbits/s, and in our backbone BGP routes flapping began to occur. Network congestion caused by Tor relay seems to cause high rates of dropped packets, and BGP instability might have been caused by that.

Anything I can do to avoid breaking BGP with Tor?

7

Maybe DDoS attack happened.

You can try to limit amount of used bandwidth with setting like this:
RelayBandwidthRate 6 MBytes
RelayBandwidthBurst 8 MBytes

1 Like
8

I noticed unbalanced in/out load on Metrics charts for your relay.
Same happened for my relay as well.
In my case, attack stopped after 1 day.
Most likely, it will be the same for your relay.
(Which means it probably already stopped)

By the way, attackers boosted “Observed bandwidth” for your relay, which means it will gain correct “Consensus Weight” sooner.

1 Like