A transit VPC is a pretty common networking pattern in an AWS environment. Transit VPCs can limit the number of peering connections required to connect all your VPCs by switching from a mesh topology of peers to a hub and spoke method with transit. While transit VPCs offer some nice features, it also requires a bit more management overhead since you need to manage your own routers. Cisco makes the deployment of transit routers very easy but sometimes you need to make some changes to the routers after they’re deployed like if you need to resize them. Also, sometimes bad things happen and those routers can be destroyed by accident. This post shows how you can resize your Cisco CSRs and/or restore an old configuration from snapshot.

Transit VPC Setup

This post assumes that you’ve already gotten your Transit VPC and AWS environment setup and created. As you can see from my screenshot below, I’ve got a pair of Cisco CSRs up and running in my AWS environment. I’ve also got an EC2 instance in two different VPCs which are connected together though the transit network and subsequently these CSRs. These instances are setup to ping each other just to ensure connectivity exists between the two hosts.

In preparation for the upgrade to a larger EC2 instance type, I’m going to create an image of one of my CSRs that will be upgraded. I’m doing this manually and only once, but it might be a good idea to build in an image process on a regular schedule as a device backup solution.

If you’re going the manual route, select your CSR in the EC2 console and the click Actions –> Image –> Create Image.

Give the Image a name and description. Then click the “Create Image” button.

After a few minutes you’ll see that your image has been created which should be visible in your images link in the EC2 portal.

Before we do anything else destructive, take a look at your elastic IP Addresses in the “Elastic IPs” link in the EC2 console. Pay attention to which EIP is associated with the router that is to be upgraded. We’ll need this information later.

Create new CSR

We’re ready to build a new CSR from the image we created in the previous section. This could be to do our upgrade, or to recover from some sort of catastrophic configuration change. Navigate to the images where we created our CSR image. Select the image and click Actions –> Launch to create a new EC2 instance from the snapshot. At this point the EC2 Launch wizard will start. Select the instance size that you prefer as well as names, security groups etc. For this demo I’ve selected an c4.xlarge to show that the size can be altered from the default c4.large sizing.

Once the images are launched, go back into your Elastic IPs portal and disassociate the old EIP with the CSR that was deleted, shutoff or broken. You can do this by selecting the EIP and going to Actions –> Disassociate address.

A window will open asking you to confirm where you’ll click the “Disassociate address” button.

Now select that EIP again and go to Actions –> Associate address so that we can attach that EIP to the new instance that we created from the image.

In the window that opens select the instance radio button and then select your new CSR from the instance drop down. Then select the private IP Address of the CSR that should get the new association. When you’re done click the “Associate” button.

When done you’ll get a confirmation window. Click the “Close” button.

Results

Now that the EIP has been re-associated to our new CSR we should be able to use our Transit connections again with both CSRs. In the EC2 instance portal of my transit account I can now see my original Transit CSRs (one of them stopped which Is the one we replaced) as well as the CSR that I created from image. Notice that there are two CSRs running and the restored CSR is a larger size than the originals.

As I hop over to one of my spoke VPCs with my test EC2 instances running (and pinging each other) I can navigate to the VPNs. There I see that I have two VPNs available and are routing packets through my transit VPC.

As I went through this process I saw a small drop in connectivity. Also, in case you’re wondering I powered off the remaining CSR from the initial configuration to ensure that traffic was flowing through the transit and across the new router that was deployed.

Summary

This scenario showed that you can restore your Cisco CSRs used for transitive routing by snapshotting and restoring an image. This process can be used not only for Cisco CSRs but for any types of instances that are deployed in AWS. Maybe its an EC2 instance running a webapp, or maybe its a Palo Alto transit setup. In any case, this process should work to help you manage your EC2 instances. Thanks for reading.