Appendix A: Component Details - Transit Network VPC (Cisco CSR)

Appendix A: Component Details

VGW Poller

An Amazon CloudWatch rule invokes the VGW Poller Lambda function every minute. The VGW Poller is configured to iterate through each AWS Region of a customer’s account, searching for appropriately tagged spoke VGWs (transitvpc:spoke = true by default) that do not have existing VPN connections to the transit VPC. Once a spoke VGW is identified, the function creates corresponding customer gateways (if required) and VPN connections to each CSR. After creating VPN connections, the function retrieves the VPN configuration and saves it to an Amazon S3 bucket. The following diagram describes the VGW Poller logic in more detail.

                VGW Poller connecting spoke VPCs to the transit network

Figure 3: VGW Poller logic

Similar logic is used to remove spoke VPCs from the transit VPC, however the VGW Poller function looks for connected spoke VGWs that either do not have the spoke VPC tag (it was removed) or that have a spoke VPC tag without the expected tag value (true by default). For example, by default, deleting the transitvpc:spoke tag or changing its value to <blank>, false, or any other value (besides true) will result in the VGW Poller removing the spoke VPC from the transit network.

Cisco Configurator

The Cisco Configurator is an AWS Lambda function that is invoked by Amazon S3 Put events to the solution’s S3 bucket. After the VGW Poller function writes new VPN connection details to the S3 bucket, the Cisco Configurator function parses the VPN connection information and generates the necessary config files to establish or remove VPN connections to spoke VPCs. It then pushes the configuration to the CSR instances using SSH. The following diagram describes the Cisco Configurator logic in more detail.

                Applying the Cisco configuration onto the CSR instances

Figure 4: Cisco Configurator logic

BGP and Failover

As soon as the Cisco configuration is applied onto the CSR instances, the VPN tunnels come up and Border Gateway Protocol (BGP) neighbor relationships are established.

                Establishing VPN tunnels and BGP relationships

Figure 5: BGP relationships

By default, the transit VPC CSR instances will be deployed in an active/active configuration with each spoke VPC receiving equal cost routes. Customers can apply the preferred VPN endpoint tag on each spoke’s VGW, on a spoke-by-spoke basis, to configure the CSR instances in an active/standby configuration. By default, the preferred VPN endpoint tag name (key) is transitvpc:preferred-path, which accepts the following values.

Value Description
none or <blank> If a VGW does not have a preferred VPN endpoint tag, or has one with a value that is blank or set to ‘none’, then both CSR instances are viewed as equal and each spoke VPC will independently choose to send traffic through either CSR instance.
CSR1 The transit VPC will configure CSR1 as the preferred route by this spoke VGW. AS path prepending will be used to make CSR1 a more attractive route than CSR2.
CSR2 The transit VPC will configure CSR2 as the preferred route by this spoke VGW. AS path prepending will be used to make CSR2 a more attractive route than CSR1.