Cisco Cloud Services Router (CSR) 1000v - Transit Network VPC - BYOL
As part of Cisco's Cloud connect portfolio, the Bring Your Own License (BYOL) for the Transit Network VPC solution of the Cisco Cloud Services Router (CSR1000V) delivers the maximum performance for virtual enterprise-class networking services in the AWS cloud. The transit VPC serves as a global network... See more
Great
Doing my 6th AWS CSR1Kv deployment and we have never had any problems with these. These have been soft of set it and forget it.
- Leave a Comment |
- View Comments
Good routers, garbage solution
The Cisco CSR1000v is a very good router. However, there are many differences between running a virtual router on your own infrastructure vs running a virtual router on Amazon's infrastructure. Amazon and Cisco have attempted to obfuscate these differences and a ton of limitations that go along with them by selling a packaged Transit VPC solution. In my opinion, the solution, in its current form, is garbage. To understand the reasons for my opinion on this, you must understand what's going on under the hood with this solution and its complexities.
First and foremost, the automation that AWS engineers have written to make the Transit VPC automatically add and remove spoke VPCs is a mess. This is because of two reasons. First, AWS does not natively support transitive VPC routing. The name of the solution, 'Transit VPC', is very misleading. Second, the automation interacts with the CSR instances via raw SSH sessions and Cisco IOS-XE CLI commands.
AWS does not allow you to use a VPC as a transit network between two VPCs not directly connected with each other (A-B-C). The same goes for traffic sourced externally from your on-premise network. Therefore, it is not possible to utilize VPC peering connections between your CSR routers and your spoke VPCs. The 'Transit VPC' solution works by functioning as an overlay network. The connectivity between the CSRs and spoke VPCs is achieved by provisioning AWS VPC VPN connections with dynamic eBGP routing. This alone makes the solution very expensive. Each spoke VPC connected brings up two VPC VPN connections (1 per CSR, with two redundant tunnels per VPN). The VPNs are charged by the hour and the network transfer is treated as 'Internet' for billing, even within a region. For traffic going from one spoke to another via the Transit VPC, you are charged for this traffic twice. The configuration parameters from these VPN connections are parsed by the Lambda functions and used to generate CLI commands to create or delete VRFs, crypto keyrings, and Tunnel interfaces on the CSR instances. Check out the code for this on Github. It's very clunky.
I recently deployed a few Transit VPCs on my network. However, I decided not to use the AWS provided automation. I didn't want AWS to be logging into my routers and running config commands automatically when triggered by events completely external to the routers (VPC tagging). I'm pretty sure the automation wouldn't even work with TACACS AAA because it relies on PKI. Instead, I used Terraform to set up the AWS side resources (VPC, route tables, EC2 instances, etc.), and created a Jinja2 template and some Python functions to parse AWS VPC VPN XML files and generate configuration TXT files that I can then use myself (whether by hand or via on-prem automation) to configure the CSR side VPN and routing configuration.
There's a ton of things that AWS could do to make the 'Transit VPC' solution magnitudes better than it is currently. The biggest improvement they could make is to allow transitive routing so that VPC VPNs w/ VGWs aren't needed at all. Replacing the VPNs with native VPC peering would make the solution 10x simpler and at least 2x cheaper than it is now. Another big improvement they could make is replacing the CLI interaction with the CSRs by using REST API calls instead.
