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.
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): GitHub - 1aeo/TorBGPConfigs: BGP Configuration Files for Tor Relay Servers
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.
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.
BGP community-based traffic engineering | Noction
> 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 GitHub - nttgin/BGPalerter: BGP and RPKI monitoring tool. Pre-configured for real-time detection of visibility loss, RPKI invalid announcements, hijacks, ROA misconfiguration, and more. 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
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org