> On 9 Jun 2017, at 16:05, Scott Bennett <bennett@xxxxxxx> wrote: > >> My relays have multiple IP addresses on a single WAN interface. They all use >> OutboundBindAddress to separate OR and Dir traffic from outbound traffic. And >> they make up about 1% of Tor guard/middle bandwidth. > > So, although the traffic is not separated on that machine, you use the > source addresses to allow a router to separate the traffic as it leaves your > network? Or is it indeed separated on that machine via routing table entries? The traffic goes out the same interface. I don't know or control what happens to it after that. >> ... >>> Also, clients don't give up after something like that, but >>> rather continue to try more circuits, so the end user may experience a short >>> delay, but won't actually go unserved in such cases. >> >> What actually happens depends on a number of factors: >> * whether the other relay has successfully connected to your relay, >> * whether both relays think the connection is canonical, >> * whether either relay has a large exponential backoff on retries. * how many alternate destinations are available to clients For example, if your relay is an introduction point for a hidden service with very few introduction points (there is a known bug that causes this), clients may not be able to reach the service, because they will give up after the first try. >> So in some cases, clients will be unable to connect to your exit via some s/exit/guard or middle/ > Although I allow exits to a small list of places, my relay does not > allow general exiting in a manner that would qualify it for an Exit flag > on its entry in the consensus, so in that sense, there is no exit here. >> middle relays. s/middle/middle or guard/ >> This reduces your exit traffic, s/exit/guard and middle/ >> and also reduces the number of >> different circuit paths available to clients. (Using a wide variety of paths >> is one of the building blocks of Tor's anonymity.) > > My daily exit traffic is ordinarily zero. Non-zero days are so rare as > not to be worth calculating their frequency. I no longer remember the last > time I saw one, but many versions of tor have come and gone since then. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays