When beginning the configuration phase of implementation, it helps to break the task down into components. Based on the problem statement and objectives of the deployment, we can identify the core focus areas:
- VRF definitions and initial interface configuration
- Base crypto configuration
- Connectivity between the CSR instances
- Connectivity between the CSRs in AWS and our HQ network / the customer network
- NAT configuration
- Routing
Of course, these don’t have to be accomplished in this order, but it’s close enough. Once the basics are working, we can work out the finer points such as security, routing policies, and redundancy. Let’s get started with VRF definitions and initial interface configurations. This document will assume some familiarity with AWS, so I won’t go into the details of that. One task that will be required in AWS is to disable the Source/Destination check on the interfaces attached to the CSR1000.
For this deployment, we decided to break up the routing tables into Virtual Routing and Forwarding (VRF) instances. There will be 5 VRFs per router:
- INET (we’ll use this for the front-door VRF or fvrf)
- HUB (routes exchanged between the CSR instances)
- VPN (IPsec tunnel routes to our corporate HQ and the customer site)
- PRIVATE (private VPC subnet)
- PUBLIC (public VPC subnet)
This article will cover the VRF / interface configuration as well as the base crypto configuration.