• Deploy a Transit VPC with vEOS using IGW (Public IP)

 
 
Print Friendly, PDF & Email

Deploy a Transit VPC with vEOS using IGW (Public IP)

fanyang@arista.com

 

This document focuses on the steps to build a Transit VPC solution using Internet Gateway (IGW) vs. VPC peering. There are certain advantages to use IGW as transport. This eliminate the limits on how many VPC peering can be created and gives customer a larger scale deployment. It also enables spoke VPCs to communicate with each other directly with one hop, which can potentially save data cost. Besides, even it’s public ip to public ip communication, if both IPs belong to AWS, AWS will route the traffic through their backbone, not via Internet. For example, if two vEOS routers use public ip to communicate, the data rides over AWS backbone.

 

The whole setup can be brought up using AWS CloudFormation (CFN) templates, along with CVP configlet. Before we dive into the deployment steps, let’s take a look on what the end goal looks like (Diagram 1).

 

Diagram 1: Transit VPC Topology

In above diagram, a transitive network is created by having one transit vpc and one spoke vpc. Let’s list the components in each VPC. The ip range is used for example, the template gives options for customer to choose during deployment.

  • Transit VPC
    • Transit VPC
    • Two subnets (subnet 1, subnet 2, in different Availability Zones)
    • One IGW
    • Two vEOSs (in different Availability Zones), with one interface. vEOS1 in subnet1, vEOS2 in subnet2.
  •  Spoke VPC
    • Spoke VPC
    • Four subnets (public subnet 1, public subnet 2, private subnet 1, private subnet 2, in different Availability Zones)
    • One IGW
    • Two vEOSs (in different Availability Zones), with two interfaces.
      • vEOS1 in public subnet 1 and private subnet 1.
      • vEOS2 in public subnet 2 and private subnet 2.
      • vEOS1 and vEOS2 are configured as HA pair. They work as active and active mode.
      • vEOS1 is active for private subnet 1, standby for private subnet 2.
      • vEOS2 is active for private subnet 2, standby for private subnet 1.
    • Three Route tables.
      • Public route table associated with two public subnets.
      • Private route table 1 associated with private subnet 1.
      • Private route table 2 associated with private subnet 2.
    • vEOS is being configured as gateway for VMs deployed in private subnets.
    • vEOS1 is gateway for private subnet 1
    • vEOS2 is gateway for private subnet 2
  • CVP
    • vEOSs in both transit VPC and spoke VPC send telemetry data to CVP
    • CVP uses configlet to build IPSEC tunnels between vEOSs in transit VPC and spoke VPC

Prerequisites

  • Resources (CFN templates, CVP configlets) used in this guide can be downloaded from here.
  • CVP needs to have a public IP. It needs to access the vEOS’s public ip for management. If there is a firewall between CVP and internet, the firewall rule needs to be correctly configured to allow traffic between CVP and vEOS Routers.

Diagram 2: A closer look at spoke VPC

 

Once you understand the whole setup, let’s go through the steps to deploy this solution. CNF templates can be found in this link. There are two templates being used, one is transitvpc.json which deploys a transit vpc with components listed above, the other is spokevpc.json which deploys a spoke vpc with components listed above. Typically, you only need to deploy one transit VPC for a region. You can deploy multiple spoke VPCs by repeatedly deploying spoke template.

 

Deploy Transit VPC

 

Download transitvpc.json from here.

 

Login to your AWS environment, use cloud formation page to deploy the template. You need to fill out below information and click “Next”.

  • Stack Name: the name of the stack being deployed by this template
  • CVPAddr: the public ip address of CVP. vEOS will stream telemetry data to CVP
  • CVPusername: the username CVP will use to configure vEOS. This username/password should exist on CVP already.
  • CVPPassword: the password CVP will use to configure vEOS. This username/password should exist on CVP already.
  • KeyName: ec2 ssh-key that is used to login vEOS. Select from drop-down list.
  • TPublicSn1: transit VPC subnet 1 CIDR.
  • TPublicSn2: transit VPC subnet 2 CIDR
  • TPubSubnet1AZ: subnet 1’s AZ. vEOS1 will be deployed in this AZ.
  • TPubSubnet1AZ: subnet 2’s AZ. vEOS2 will be deployed in this AZ.
  • TVpcCidr: transit VPC CIDR
  • vEOS AMI: input the public vEOS AMI. AMI varies by region (The example uses vEOS in Singapore region)
  • vEOSInstanceType: the instance type vEOS runs on. Bigger instance type gives better performance.

 

Nothing needs to be filled or selected in this page, just click “Next”.

 

Review the configuration and click “Create”.

 

Then it will tell you the creation is in progress.

 

In about 5 mins, the status will change to create_complete.

 

Now, switch to EC2 page and you can see the two Transit VPC vEOSs created.

The vEOS will take another 3 mins to boot up. When it changes to 2/2, it means it’s up and running.

 

Now if we go to CVP portal, you can see two devices (Transit-vRouter-1, Transit-vRouter-2) are found in inventory page, and they are streaming back telemetry information.

 

Let’s proceed to deploy spoke VPC.

 

Deploy Spoke VPC

Download spokevpc.json from here.

 

Login to your AWS environment, use cloud formation page to deploy the template. You need to fill out below information and click “Next”.

  • Stack Name: the name of the stack being deployed by this template
  • CVPAddr: the public ip address of CVP. vEOS will stream telemetry data to CVP
  • CVPusername: the username CVP will use to configure vEOS. This username/password should exist on CVP already.
  • CVPPassword: the password CVP will use to configure vEOS. This username/password should exist on CVP already.
  • KeyName: ec2 ssh-key that is used to login vEOS. Select from drop-down list.
  • SPrivateSn1: private subnet 1 CIDR.
  • SPrivateSn2: private subnet 2 CIDR.
  • SPublicSn1: public subnet 1 CIDR.
  • SPublicSn2: public subnet 2 CIDR.
  • TPubSubnet1AZ: subnet 1’s AZ. vEOS1 will be deployed in this AZ.
  • TPubSubnet1AZ: subnet 2’s AZ. vEOS2 will be deployed in this AZ.
  • SVpcCidr: spoke VPC CIDR
  • vEOS AMI: input the public vEOS AMI. AMI varies by region (The example uses vEOS in Singapore region)
  • vEOSHAProfile: IAM profile that vEOS uses to update AWS route table in case of failover.
  • vEOSInstanceType: the instance type vEOS runs on. Bigger instance type gives better performance.

 

Nothing needs to be filled or selected in this page, just click “Next”.

 

Review the configuration and click “Create”.

 

Then it will tell you the creation is in progress.

 

In about 5 mins, the status will change to create_complete.

 

Now, switch to EC2 page and you can see the two Spoke VPC vEOSs created. The vEOS will take another 3 mins to boot up. When it changes to 2/2, it means it’s up and running.

 

 

Now if we go to CVP portal, you can see two devices (Spoke-vRouter-1, Spoke-vRouter-2) are found in inventory page, and they are streaming back telemetry information.

 

You can also login to Spoke vEOS to see the high availability configuration is being correctly configured.

 

On AWS VPC, you can see the AWS route table is also being correctly configured.

Private Route Table 1

Private Route Table 2

 

Now we successfully deployed a transit vpc (with two vEOS routers), a spoke vpc (with two vEOS routers in HA mode) without any manual configuration. We also verified that all four vEOS routers are streaming data back to CVP. You can continue to deploy more spoke vpcs by repeat the steps. Next, we will demonstrate how to manage these vEOS routers, and how to build an IPSEC overlay, still without any CLI configurations.

 

Manage vEOS using CVP

Note down all vEOS router’s public ip addresses which will be used in later step.

 

Go to CVP page, click “registering existing device”

 

Put all four public IPs and click “register”, please ignore the previous two i added.

 

Then you should be able to see four devices are successfully registered, the screenshot shows six devices (because of two existing devices, please ignore them).

 

 

Now go to “Network Provisioning” page on CVP, you will see four devices under “undefined” container.

 

You can create a “vEOS-multicloud” container, or use any container you like. Move all four vEOS devices under this container to use configlet.

 

Now let’s use configlet to configure a tunnel between transit-vRouter-1 and spoke-vRouter-2. You can repeat the steps to configure the rest tunnels between transit vRouter and spoke vRouter depends on what kind of network you want to build.

 

Note: Before using configlet to configure vEOS, please make sure the correct licenses (throughput and IPSEC) are installed on vEOS. You can follow the guide here to install the license.

 

Download the configlet script from here. Go to “Configlets” page and upload the scripts to CVP. Essentially, you will need to use two configlets to build the tunnel

  • IPSEC Tunnel on Hub: it creates ipsec tunnel as responder
  • IPSEC Tunnel on Spoke: it creates ipsec tunnel as initiator

 

Then switch back to the “Network Provisioning” page. Let’s start with transit-vRouter-1 first.

Select the “IPSEC Tunnel on Hub” configlet, input the parameters required. Click “generate”.

Parameters

  • Tunnel ID: tunnel number
  • Tunnel IP: ip address configured under the tunnel
  • Tunnel Mask: network mask configured under the tunnel
  • Tunnel Src: ip address on local router (private ip address of eth1 on transit-vRouter-1, since vEOS only sees its private ip in AWS, IGW will do the NAT)
  • Tunnel Destination: ip address on remote router (public ip address of spoke-vRouter-1)
  • Tunnel Local ID: public ip of local router. this is used to identify the IPSEC session.

 

 

Then Click “validate”

 

Now you can see the configurations that will pushed to vEOS in CVP. You will note the IPSEC IKE, SA, Profile configurations, along with the tunnel configuration. Click “save”

 

Let’s configure spoke-vEOS-1 using the same step, but choose a different configlet which is “IPSEC Tunnel on Spoke”. Put the parameters and click “generate”

Parameters

  • Tunnel ID: tunnel number
  • Tunnel IP: ip address configured under the tunnel
  • Tunnel Mask: network mask configured under the tunnel
  • Tunnel Src: ip address on local router (private ip address of eth1 on spoke-vRouter-1, since vEOS only sees its private ip in AWS, IGW will do the NAT)
  • Tunnel Destination: ip address on remote router (public ip address of transit-vRouter-1)
  • Tunnel Local ID: public ip of local router. this is used to identify the IPSEC session.

 

Then click “validate”.

 

Now you can see the configurations that will pushed to vEOS in CVP. You will note the IPSEC IKE, SA, Profile configurations, along with the tunnel configuration. Click “save”

 

Now both tasks (ipsec on transit-vRouter-1, ipsec on spoke-vRouter-1) are submitted, go to “task” page and “execute” these two tasks. You will be able to see that configurations are pushed to both routers and IPSEC tunnel is up.

 

Then you can enable routing protocols like BGP to advertise the connectivity. You can also continue to deploy more IPSEC tunnels by repeating the above steps.

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: