Tor Relay Deployment Dilemma: Handle BGP yourself or have it done upstream to announce your own AS?
I'm currently evaluating the best approach for having my AS announced with my owned (not rented) IPv4 addresses, and I've observed that hosting providers have different preferences for handling BGP sessions. For example, one provider requires that the BGP session be managed on the same server running the Tor relays, while another handles the announcement with my AS entirely on their side. This inconsistency makes it challenging to determine the most effective approach. I'm seeking guidance on the following points (or others you think are helpful): - When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible? - When required to manage BGP myself: - To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing? - Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them? - Are there best practices for route filtering or failover management? - What are your experiences regarding the compute and memory requirements for these configurations? - What are some preferred monitoring solutions? bgpmon.net doesn't seem free... Helpful read and suggestions at the end from this 6 year old article from nusenu, but couldn't find too much beyond this: https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijacking... I'm already using ROA and RPKI via ARIN for each /24 and limit max length to /24 to help as well. "The Tor exit fraction located in /24 prefixes is much higher than the guard capacity. So hijacks against exit capacity might be harder than attacks against guard capacity." - Seems also good to have /24 prefixes for guards, not just exits. Thanks!
Hej,
When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible?
Depends on how much interest you have in BGP and what the upstream charges for managed BGP.
To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing?
If you are single homed, receiving full v4 and v6 tables is imho a waste of cpu cyles. I'd go for receiving v4 and v6 default routes. But playing around with BGP would totally justify full tables :)
Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them?
For multi-homed you'd need two different upstream providers. Your transit is hopefully multi-homed anyway and depending on their BGP community traffic engineering capabilties you can traffic engineer yourself quite a lot apart from using as-path prepends and MED. https://www.noction.com/blog/bgp-community-based-traffic-engineering
Are there best practices for route filtering or failover management?
If you only receive default routes you save yourself the trouble for elaborated filtering. Otherwise take a look here: https://bgpfilterguide.nlnog.net/
What are your experiences regarding the compute and memory requirements for these configurations?
memory for a full table is a couple of 100 MB. CPU cycles depend on the amount of route changes and the filtering you do. All in all it is not very resource heavy compared to tor traffic forwarding and crypto stuff.
What are some preferred monitoring solutions? bgpmon.net doesn't seem free...
you could host https://github.com/nttgin/BGPalerter yourself (it is using ripe ris as data source) https://packetvis.com/ is a hosted bgpalerter for free relatively newish: https://bgpwatch.cgtf.net/ you could ask bgp.tools for a free account have fun!
Great guidance that was very helpful! For me, the answer to this question, "Handle BGP yourself or have it done upstream for AS announcements" was to have upstream handle, but most (3/4) wouldn't and required that I handle. Some updates: Have 4 IPv4 /24 address ranges being announced for Tor relays. 1 provider preferred to handle everything themselves, i.e. announcing my IP address range with my AS, and routing the IPs to the server. 2 providers insisted I announce my AS and IP address range from the same server I host the Tor relays from. 1 provider was flexible and allowed me to announce my AS and IP address range from my router outside their network. https://metrics.torproject.org/rs.html#search/as:AS36849 One set of relays just switched AS and IP so they don't have guard flags back yet, takes a few days. Among the 3 providers who had me handle the announcement: 2 of them were fine sending me the default route 1 provider insisted on sending me the full table of ~970k routes The 2 providers where they required me to handle BGP announcements on same server running Tor relays, I'm using FRR on Ubuntu and have from 128 threads with 768GB to 192 threads with 1,000GB RAM so don't expect hardware capacity issues. The 1 provider allowing me to handle from a router, is running Opnsense 25.4 (with FRR) on 16 threads and 64GB RAM with no issues. 1 provider gave a community prefix I can use in my announcement to blackhole, as needed. All the upstream providers ended up waiving reoccurring BGP charges. Some required negotiation and others only required a one time setup fee, most was $50. Since BGP configurations have some nuance, I've posted mine publicly for others to reference (were "vibe" coded with GPT o4-mini-high): https://github.com/1aeo/TorBGPConfigs/ Also summarized everything into a blog post, including the common questions I had to ask to gather the right details to configure BGP. These were helpful because the support people weren't always familiar with BGP and often passed these along to the network engineering to get the information I needed. Without these questions, a few providers were only giving partial and inconsistent information which I couldn't use and delayed successful BGP peering by days or weeks. https://1aeo.com/blog/bgp-configs-for-tor-relay-servers.html I've freely subscribed to these two services which are great at sending notifications when something changes in the BGP announcements: https://bgpwatch.cgtf.net/ and https://packetvis.com/ They both caught when one of the hosting providers accidentally started announcing somebody else's IPv4 range under my AS so I could ask them to remove the mistake. Hope that helps others who want to manage their own BGP sessions to announce their own AS for their own IP address ranges! On Monday, April 7th, 2025 at 11:34 PM, Fran via tor-relays <tor-relays@lists.torproject.org> wrote:
Hej,
When given the option: Should I manage the BGP session myself, or is it preferable to delegate it to the upstream provider whenever possible?
Depends on how much interest you have in BGP and what the upstream charges for managed BGP.
To conserve CPU/RAM resources for Tor, is it advisable to only use a default route (0.0.0.0/24) rather than a full routing table, relying on the upstream provider for full routing?
If you are single homed, receiving full v4 and v6 tables is imho a waste of cpu cyles. I'd go for receiving v4 and v6 default routes.
But playing around with BGP would totally justify full tables :)
Under what circumstances should I implement multi-homed strategies myself versus allowing the upstream provider to manage them?
For multi-homed you'd need two different upstream providers.
Your transit is hopefully multi-homed anyway and depending on their BGP community traffic engineering capabilties you can traffic engineer yourself quite a lot apart from using as-path prepends and MED.
https://www.noction.com/blog/bgp-community-based-traffic-engineering
Are there best practices for route filtering or failover management?
If you only receive default routes you save yourself the trouble for elaborated filtering.
Otherwise take a look here: https://bgpfilterguide.nlnog.net/
What are your experiences regarding the compute and memory requirements for these configurations?
memory for a full table is a couple of 100 MB. CPU cycles depend on the amount of route changes and the filtering you do. All in all it is not very resource heavy compared to tor traffic forwarding and crypto stuff.
What are some preferred monitoring solutions? bgpmon.net doesn't seem free...
you could host https://github.com/nttgin/BGPalerter yourself (it is using ripe ris as data source)
https://packetvis.com/ is a hosted bgpalerter for free
relatively newish: https://bgpwatch.cgtf.net/
you could ask bgp.tools for a free account
have fun! _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
participants (2)
-
Fran -
Tor at 1AEO