All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Let's Talk About BGP!
Before I get into it, I ask that you please keep this conversation on topic.
We're having internal discussions about how to best implement BGP sessions and wanted to get some feedback on why one option is better than the other.
Option 1: BGP session directly from the customer's server, all announcements performed by the customer. ASN validation performed manually, no IP spoofing allowed.
Option 2: All announcements for IPs and ASNs performed on our router and announced IPs routed to customer servers. No IP spoofing allowed.
My opinion:
Option 1 upfront sounds like the more flexible approach from the customer's point of view, but routing announced IPs to servers will be a complex task.
Option 2 is what I'm leaning toward. Having all announcements for both IPs and ASNs directly on our router and then routed to 1 or more servers, but maybe some extensive options such as anycast support?
Your feedback is greatly appreciated. Please choose "Option 1" or "Option 2" and provide a detailed explanation on your preference.
Comments
Option 1 for customers who want to optimize their network.
I'm announcing the same subnets in multiple locations, so that I can pick a route dynamically.
Option 2 for customers who just want to use IPs in a single location.
Thanks for the feedback.
Assuming that we can offer anycast for option 2 (announced on our router) and route to a server within that specific data center, would this not be sufficient to offset option #1?
I'm concerned that with option #1 (BGP session) customers with multiple servers will have a nightmare routing to their servers.
Ideally - you do both. Both options cover different use cases.
Say - a VPS provider wants the IPs under their ASN and IPs in a private vlan spanned across all their machines. Or on the other hand - someone who wants to control the BGP session manually and bring it up/down when needed.
Option 2 with an API or mechanism in your panel for customers to activate / deactivate their announcements.
Unless you provide full tables, communities, or allow prepending, I don't see any benefit to the customer running their own BGP session other than the ability to start / stop the announcement at will.
Offering both options is the best choice, I think it's totally different for different clients.
Option 1, clients just want to have their own IP range and nothing more.
Option 2, a client who wants to announce their own ranges, have full routing on a virtualized router, be able to choose which provider to send traffic through (you can provide communities for that) much more flexibility.
BuyVM would let the customer announce both the /48 (or shorter prefix) and more specific routes (up to /128).
Option 1 is honestly more appealing from the customer's side as they could do whatever they want at ease without needing to scream at the customer support.
However, Option 2 might be easier for the customer and the provider (like if im the customer i will 100% down your network somehow) and you can easily route the IPs.
Option 1
Option 2
@MrRadic
I think you will end up with both.
option 1 - is for a more advanced users that want to announce their subnets thru you, so they will need a "router" to do that and at least 1 VLAN for transport to their servers.
option 2 - is for those having a subnet in your infrastructure and do not want the hassle of BGP and so on, just to be able to use their ip's on a vlan you gave them directly.
Both are correct, and honestly, I would recommend you to do both. I do not see option 1 or 2 being more easy on you, the provider.
I personally like option 1.
I would also use a separate router, let's call it r-customer-bgp, and I would set up filteres here, then a iBGP to my core to announce the customers subnets to upstream.
In this case, I do not have to mangle around with VLANS + QOS + filters on CORE Router.
Option 2 can be in the r-customer-bgp router also.
Thanks for everyone's feedback! This is really helpful.
i only talk about sex.
Do not reinvent the wheel - option #1 BYOIP aka customers' IPs announced from your ASN, option #2 BYOAS aka customer have full control over BGP and annoucement
You only talk about pants.
Wooa If you were a professor I'm sure you would find many assistants.
This is the only "real" BGP option. Many customers will want access to the routes you see for a variety of reasons. It also allows customers to be able to control their routes directly (i.e., more specifics, withdrawals, tags).
This creates a large time-sink on you (or your employees).
Overall, there is no way I would accept option 2.. I need to control and change my announcements when I need to.
Everything we offer is fully automated. You would be able to do it via the panel and API.
Both options is most likely ideal if you can do it.
Some people want one yet others want the other we have found.
No one will be 100% happy either way haha even if you gave them free money.
This is certainly your prerogative, but speaking from the perspective of customers who interface with dozens of providers, having to maintain yet another interface to hosting providers's custom API only the provider has control over is not that appealing. BGP ops already have a handful of well-known control plane interfaces to systems and BGP software. Trade-offs. Best of luck whatever you do.
ASN / IP announcement at your core and private vlans for IP pooling across multiple servers.
We do both. Depending on the clients needs.
But I'm with @host_c on this one. If can don't do it on your core. So that way if something breaks it doesn't take the whole network with it.
You haven't been too flexible with some stuff but I admire your growth. Let me know if you'd like to discuss what the hosting market needs.
To quote myself, this is what VPS providers would seek.
This is what we have Crunchbits and Worldstream do for us, and why we had to pass on ReliableSite in the past despite wanting to order a handful of servers at one point.
ASN / IP announcement downstream of you with a private vlan for IP pooling between servers in a single location would be rad.
Start a new thread or pm me.
Thanks, this makes sense.
There's an API called Pathvector.
Why reinventing another API?
Not reinventing anything here, but there's something you be said about having full control of your code. This is a different topic though
@sh97 your time bro.