Why is the Aviatrix Global Transit solution a better choice over Cisco CSR?

Cisco CSR transit VPC solution is formed by a pair of virtual routers, CSR 1000v, in a transit VPC and a VGW in the spoke VPC. The VGW has two VPN connections, each terminated to a CSR with a preferred path set for a CSR. Each VPN connection has two IPsec tunnels. Since there is no cloud management for the solution, the deployment is launched via cloudformation templates. The subsequent changes are handled by AWS lambda in conjunction with configurations on a S3 bucket. The changes include:

1. Add/remove a spoke VPC
2. Change bandwidth tier
3. Add additional account

In this document, we will assess the solution differences based on primarily the operational aspects. The Aviatrix global transit solution is presented to address concerns or shortcomings. The CSR solution references have more design and operation details for your reference.

On-boarding and Deployment

A cloudformation template (transit-vpc-primary-account.template) is used to onboard an account and deploy a pair of CSRs in a VPC. Additional accounts can be added by a separate cloudformation template (transit-vpc-second-account.template). The automation is supported by python scripts running in lambda functions. As an admin, you don’t have visibility of these at all. You have to track the cloudformation stack for each operation explicitly, otherwise you may mistakenly mess up the stacks and tagging of VGWs which will negatively impact the network service.

The Aviatrix solution provides a controller to onboard multiple accounts seamlessly. A list of accounts are visible from the GUI. The GUI provides a workflow wizard to set up and to modify the transit network with few simple clicks. You can use the controller to build and manage multiple transit networks for multiple accounts with clearly defined access controls. This can become quite challenging with the CSR solution without the multi-account management capability.

The Aviatrix Terraform Provider can be used to automate the on-boarding and to deploy and to change the network with your backend integration. This becomes important when the CICD devops process is increasingly adopted. The CSR fix-up approach is a one-time implementation to address the lack of cloud management support from CSR software that was built more than two decades ago. The Aviatrix secure networking platform was built natively for the cloud from day one. It can be integrated with modern IT backend environments for seamless automation support.

Network Architecture

Inter spoke VPC connectivity is allowed by default with the CSR transit solution. However, the inter spoke VPC connectivity is not always required since the scope and role of the VPCs will be different in most deployments. Some level of segmentation is required for security reasons. The AWS native VPC peering can be used for selective spoke VPCs which need the inter VPC connectivity. The use of AWS peering can help reduce the CSR traffic load and reduce the solution cost. The latency is added up when the extra hop is added for the inter spoke VPC traffic. This latency may negatively impact performance for certain types of applications.

The CSR solution can add a lots of route entries in the spoke VPC route table when the number of spoke VPCs is large. The route table limit will be a limiting factor for this solution. In order to block the default connectivity setup, a network engineer has to instrument complex BGP route policy on both CSRs. If a full mesh connectivity is required for all spoke VPCs, the CSR solution serves that requirement well.

The HA is supported by dual VPN connections between a VGW and a pair of CSRs. The CSR has to direct the VGW to use a preferred path via a BGP configuration. When the preferred path fails, the traffic is switched to the second path. The connectivity traceability becomes challenging as the number of VPCs increases.

On the other hand, Aviatrix solution won’t allow the inter spoke VPC connectivity at the transit VPC. The main connectivity path is from the spoke VPC to the connected VGW where it can be connected to a corporate data center via a Direct Connect link. The required inter spoke VPC connectivity can be supported with the data center routing design if the traffic volume is low and latency is not a concern. Otherwise, AWS native VPC unencrypted peering can be used free of charge within a region @ 10 Gbps throughput. The AWS inter region peering is encrypted and can support more than 4 Gbps throughput with extra data transfer cost. However, a direct Aviatrix encrypted peering can be built between the spoke VPCs in a region to meet security and compliance requirements.

The Aviatrix solution HA is supported by a pair of running gateway instances between the spoke VPC and transit VPC. Only a peering connection is active for the traffic. Another peering connection is in hot standby mode. The traffic is switched to the backup peering connection if the active connection is lost. The status of the peering connection is visible on the Aviatrix controller GUI. A force switchover action can be performed on an active peering connection in a troubleshooting operation.

Post-deployment Maintenance

The CSR solution needs a skilled network engineer who fully understands the router’s CLIs and debugging facility. This can add up to extra OPEX budget. Any changes to the router is beyond the capacity of most cloud admins. The manual changes applied to the router may bring down the network completely – just from a simple typo. For instance, when there is a connectivity issue, the network engineer has to be called to ssh to the router immediately. Without a centralized controller with visibility, the admin has to surf different AWS consoles associated with different accounts and regions. For instance, the admin may need to collect VPC/network interface flow logs to track down a potential fault point from different accounts and regions. The process will be tedious and manual.

With Aviatrix’s secure networking platform, the admin can navigate the controller console to see if there is a detected fault in the network. The Controller provides diagnostic pages to check BGP info such as routes, neighbors, paths, etc. and debug BGP update, event, etc. The admin can collect information before opening a ticket with a network engineer. The admin can use the Controller’s troubleshooting diagnostics to ping, traceroute, and packet capture for the network engineer. A best practice for the connectivity ticket can be established from facilities described in Aviatrix doc site. The Aviatrix EC2 FlightPath is a very handy tool for the admin, even for a network engineer to quickly visualize cloud networking info like route table, subnets, and security groups from any two instances/gateways in the connectivity path. Together with effective tools provided, the service can be restored faster from an outage.

When a software upgrade is required for new features, bug fixes, or security patches in production, it will just require a few clicks on the Controller GUI shown below. The admin will need to follow the upgrade document to upgrade CSR software. The inline software upgrade is supported by Aviatrix solution, but not CSR’s. The admin definitely wants the software upgrade in the production to be streamlined and hitless without a fire drill outside of a maintenance window.

Conclusion

Aviatrix’s secure networking platform provides more operational support for the admin, not to mention the technical advantages. As an admin, Aviatrix global transit solution will make your life easier and OPEX much more efficient. It is a better choice over the Cisco CSR solution for most deployments given the operational issues discussed here.