Opened 10 years ago

Closed 2 years ago

#1263 closed defect (worksforme)

ICMP and DNS problems under load

Reported by: grumpy3 Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: 0.2.1.22
Severity: Normal Keywords: tor-relay
Cc: grumpy3, Sebastian, arma, phobos Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

OS: gentoo linux up to date

File Edit Options Buffers Tools Help
when Tor does not run, the OS and the network is running as
expected. When Tor runs with 256kBps and 512kBps burst, after
about 15minutes after the available bw to Tor is fully used, some
network capabilities of the system are degraded:

  • ping -f 8.8.8.8 reports more than 70% of packet loss
  • traceroutes don't finish (stars for every nodes)
  • DNS requests (w/ dig) fail to query _any_ DNS server 9 times over 10

All that is fully functional when Tor is not running.

Moreover, with that setup, Tor reports the following lines in the
logs:

00:39:26 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:39:26 [WARN] eventdns: All nameservers have failed
00:33:25 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:33:25 [WARN] eventdns: All nameservers have failed
00:32:59 [NOTICE] eventdns: Nameserver 8.8.4.4 is back up
00:32:59 [WARN] eventdns: All nameservers have failed
00:29:54 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:29:54 [WARN] eventdns: All nameservers have failed
00:26:43 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:26:42 [WARN] eventdns: All nameservers have failed

load of the system is near 0, there is no memory problems.

If I set the available bw to Tor to 2MBps, Tor uses only about
400kBps. I have no logs like above, and the dig command can reach
the servers 9 times over 10. The traceroute command also perform
nearly as well as without Tor.

I can't assess right now if the ISP has kind of traffic
filtering. Checks about that are ongoing.

[Automatically added by flyspray2trac: Operating System: Other Linux]

Child Tickets

Change History (9)

comment:1 Changed 10 years ago by grumpy3

libevent 1.4.13

comment:2 Changed 10 years ago by Sebastian

At first, I thought that maybe the log entries were caused because when a Tor
relay is overloaded, we rate-limit dns requests and then time out. But that
doesn't explain why dig would fail (DNSPort is not used, according to irc
discussions...)

comment:3 Changed 10 years ago by arma

What's happening is that Tor is filling your upstream pipe. At this point
packets collide and get dropped, and everything starts to degrade -- both
your Tor traffic and your other traffic.

You should set your Tor's rate limit to slightly smaller than your available
bandwidth.

(These instructions get messy when your upstream bandwidth varies
based on what else is happening in your neighborhood, like happens on cable
modem. Bleah.)

If you are on Linux and can get fancy, see #6 at
https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment
for some QoS instructions.

comment:4 Changed 10 years ago by Sebastian

But this doesn't indicate why everything works when Tor is allowed an
even greater bandwidth consumption

comment:5 Changed 10 years ago by grumpy3

I don't think Tor is filling my upstream pipe as 1) when it is running, I still get some impressive results with iperf and another machine outside my network and 2) I (should) have way more upstream bandwidth than what I'm allocating to Tor.

I would be happy to provide you with some other data, if requested

comment:6 Changed 9 years ago by nickm

Description: modified (diff)
Milestone: Tor: unspecified

comment:7 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:8 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:9 Changed 2 years ago by nickm

Cc: grumpy3,Sebastian,arma,phobosgrumpy3, Sebastian, arma, phobos
Resolution: Noneworksforme
Severity: Normal
Status: newclosed

Whatever this issue was, it is probably not relevant to our network performance 7 years later

Note: See TracTickets for help on using tickets.