How Does Aviatrix Global Transit Solution Differ from the CSR Solution?
Founder and CTO, Aviatrix
January 14, 2018
The Aviatrix AWS Global Transit Solution has been published on the AWS Answer page as a partner solution. Since then we are often asked by customers why they should consider the Aviatrix solution, and for that matter, why they should consider Aviatrix over all other virtual appliance-based solutions. This article tries to answer some of the questions.
1. Who should use the Aviatrix solution?
If you are not a CCIE with domain expertise in VRF, BGP and IPSEC, you should not consider the CSR-based solution. While the CloudFormation and Lambda scripts make it easy to set up, you wouldn’t know what to do when the network goes down, or to prove the network is not the problem when a developer complains about connectivity issues for her apps.
If you are a CCIE but have not managed a large-scale network with potentially hundreds of BGP sessions, you should not consider the CSR-based solution. Since each Spoke VPC to Transit VPC runs an independent BGP session, there could be hundreds of BGP sessions. Managing hundreds of BGP sessions is like managing a mini ISP handicapped, because the other side of every BGP session is a black box (the VGW in every Spoke VPC runs BGP that no one can see).
If you are the superstar CCIE who can do everything but like to be able to take vacations and have a normal life, you should not consider the CSR-based solution. Chances are you are the only person in your organization who has the capability to manage and support this solution. The entire network uptime will be on you.
If you are not comfortable with programming but need customization, you should not consider the CSR-based solution, because the entire solution is written in python.
By the way, this is true for all virtual appliance vendors out there that mimic the CSR solution.
If you are not a super hero, which means you’re like the rest of us, you should consider the Aviatrix solution.
Using the Aviatrix Transit VPC solution, you are going to have a very different experience. The Aviatrix solution has a central controller with a web console that provides an easy to use and manage transit solution. No BGP runs in any Spoke VPC gateway. In the cloud, it is all software-defined networking (SDN), just like how AWS does it for intraregion peering and interregion peering. If you know how to build an AWS VPC and configure AWS peering, your skill is good enough to operate the Aviatrix controller.
Here is a diagram of the Global Transit Network with Aviatrix.
2. Network segmentation consideration
This is about security. Since BGP runs in every VPC in the CSR-based solution, there is default connectivity established among all Spoke VPCs. These Spoke VPCs are most likely owned by different organizations and are never supposed to talk to each other. Realize you just built something with the blast radius of the entire cloud network. Note that 99% of data breaches come from one weakness in the datacenter design: lack of network segmentation. Why should you build something like that in the cloud?
Because Aviatrix uses SDN in the cloud, a Spoke VPC can communicate only with a Transit VPC to on-prem. Spoke and Spoke have no connectivity by default, unless you specify it, at which time, you can choose to use AWS native peering or Aviatrix encrypted peering.
3. Connectivity efficiency consideration
This is about not having a performance bottleneck. With BGP running in every VPC in the CSR-based solution, Spoke to Spoke traffic by default is routed through the Transit. Your Transit hub is the performance bottleneck. In addition, you pay twice the egress charge. You really should distribute the traffic and leverage native AWS peering as much as possible for Spoke to Spoke traffic. Of course you can go to the AWS console to build that, but Aviatrix does it better by integrating the native AWS peering into the controller.
4. AWS limitation consideration
The AWS VPC comes with multiple limits. For example, each route table in a VPC has a maximum of 100 route entries for static and dynamic routes, which implies you cannot have many VPCs, after taking into consideration the route list propagated from on-prem. Special handling of the route entry limit is needed to overcome that. That special handling is not in the CSR-based solution. Aviatrix’s Designated Gateway feature allows you to scale beyond the AWS route limit.
5. Has Aviatrix product been proven in the field?
We are a Cisco shop; the entire engineering team came from Cisco with years of networking development experience. We abstract the complexity of networking so you don’t have to know the nuts and bolts. The Aviatrix product has been in production for over 3 years in companies of all sizes. Recently at re:Invent 2017, Aviatrix was selected as one of the two inaugural partners for the newly established AWS Network Competency in the connectivity category.
I hope this covers a few bases. There are certainly other areas, such as visibility, troubleshooting, logging and monitoring, to consider. I encourage you to find out more at our website and our Doc site.
Comments are closed for this post.