Transit VPC Network - CSR1000v vs. Aviatrix

Introduction

This document depicts a typical deployment of CSR1000v on AWS in a Global Transit VPC architecture. The limitations encountered on this architecture are explained in a series of videos. I hope this document helps you understand the advantages of Aviatrix over the CSR1000v Solution.

The setup

To setup this demonstration we have followed the AWS Cisco-Based Transit network VPC. document. The AWS document runs a cloudformation script that deploys all the necessary CSR1000v Instances and Lambdas function to aid with the provisioning of new Spoke VPCs and route configurations.

Transit network VPC

This video shows the Transit VPC resulting of running the AWS Cisco-Based Transit network VPC.

Oregon Spoke VPC

This video shows how the Oregon spoke has been configured to work with CSR1000v Transit VPC..

Virginia Spoke VPC

This video shows how the Virginia spoke has been configured to work with CSR1000v Transit VPC.. Feel free to skip as it mirrors Oregon’s setup, main difference are the subnets.

Troubleshoot #1 - Troubleshooting route propagation

This video shows how to enable route propagation. Route propagation is a step that is not documented but it is essential to make the Transit Architecture work. This video will save you a few hours of googling around to figure out why your transit VPC deployment is not working right off the box. In contrast the Aviatrix solution does not require any manual intervention, we will show how to create connectivity using Aviatrix in the next video.

Troubleshoot #1 - Troubleshooting route propagation using Aviatrix

(Or lack of thereof)

This video shows how to deploy gateways and create peering tunnels using Aviatrix Controller. Notice that Aviatrix install the necessary routes on the AWS Routing tables, without any need for manual interaction.

Ohio Spoke VPC

This video shows the introduction of a third VPC, which by “mistake” utilizes the same ip range as the Virginia VPC.

Troubleshooting #2 - “Making sense of the routing”

Now that the Ohio VPC has been created and it’s not working due that it is using the same ip range as Virginia VPC. In this video we try to troubleshoot by trying to make sense of the routing tables both in the CSR1000v and the AWS side. Quickly we find that this is not an easy task nor it’s scalable.

Troubleshooting #3 - IP overlap

This video shows the worst case scenario: a wrongfully configured Spoke VPC taking over the ip range of a shared services VPC, bringing the whole network and it’s services offline.