◄
►

Configuring Amazon Web Services

VeloCloud supports Amazon Web Services (AWS) configuration in Non SD-WAN Destination.

Configure the Amazon Web Services (AWS) as follows:
  1. Obtain Public IP, Inside IP, and PSK details from the Amazon Web Services website.
  2. Enter the details you obtained from the AWS website into the Non SD-WAN Network Service in the Orchestrator.

Configure Edge for Amazon Web Services (AWS) Transit Gateway (TGW) Connect Service

VeloCloud Edges typically deploy in a Transit VPC on Amazon Web Services (AWS). AWS introduced the support for AWS TGW (Transit Gateway) Connect Service for SD-WAN appliances to connect to the Transit Gateway. VeloCloud Edge now has a feature (BGP over GRE support on LAN), which enables support on the VeloCloud Edge to use the AWS TGW Connect Service for connectivity to the AWS Transit Gateway.

For the AWS TGW Connect Service, the Edge provisioned in the Transit VPC needs to use the LAN (routed, non-WAN) interface to set up the GRE tunnel.

Amazon Web Services (AWS) Configuration Procedure

  1. In the AWS portal, provision an AWS Transit Gateway for a particular region. This same region must have the Transit VPC, where the VeloCloud Edge is provisioned.
    Figure 1. Displaying the AWS Configuration

    Check for the Transit Gateway CIDR block to be configured. An IP from this block is used for the GRE endpoint on the AWS TGW. The Amazon ASN is used later in the BGP configuration on the VeloCloud Edge.

    Figure 2. Displaying the Transit Gateway CIDR Block Information
  2. Create a VPC Attachment for the Transit VPC specifying the Subnets where the LAN interface of the Edge or EI resides.
    Figure 3. Creating the Transit Gateway Attachment
    After creating the VPC Attachment, the state, Available, displays in the State column.
    Figure 4. Displaying the VPC Attachment
  3. Create a Connect Attachment using the VPC Attachment.
    Figure 5. Creating the Connect Attachment
    After creating the Connect Attachment, the state, Available, displays in the State column.
  4. Create a Connect peer, which translates to a GRE Tunnel. Specify the following parameters: the Transit Gateway GRE Address, the Peer GRE Address, the BGP Inside CIDR block, and the Peer ASN. The BGP Inside CIDR block and the Peer ASN must match the configuration on the VeloCloud Edge.
    Figure 6. Creating the Connect Peer
    The example displays the following configuration:
    • 172.43.0.24 is the GRE Outside IP address on the AWS TGW, this IP is allocated from the Transit Gateway CIDR block.
    • 10.1.1.30 is the GRE Outside IP address on the VeloCloud Edge.
    • 169.254.31.0/29 is the Inside CIDR Block. The addresses from this block are used for the BGP neighbor.
    • 169.254.31.1 is the IP address on the VeloCloud Edge.
    • 169.254.31.2 and 169.254.31.3 are addresses used for the BGP on the AWS TGW.
    • 64512 is the BGP ASN configured on the AWS TGW.
    • 65000 is the BGP ASN configured on the VeloCloud Edge.
    Figure 7. Displaying the Configuration
    The VPC Resource Map for the Transit VPC lists the LAN side subnet with the Route table.
    Figure 8. Displaying VPC Resource Map
  5. In the Transit VPC route table, add a route for the TGW CIDR block with Target or Next Hop as the VPC Attachment. For example, 172.43.0.0/24 is the AWS TGW CIDR block.
    Figure 9. Adding a Route for the TGW CIDR Block
  6. In the same route table, verify that the LAN EI subnet has an explicit Subnet association.
    Figure 10. Verifying the LAN Subnet

VeloCloud Edge Cloud Orchestrator Configuration Procedure

  1. On the VeloCloud Edge Cloud Orchestrator, go to Network Services > Non SD-WAN Destinations via Edge and configure the GRE Tunnel with the AWS Transit Gateway Connect.
    Figure 11. Configuring the VeloCloud Edge Device
    When configuring the GRE Tunnel with the AWS Transit Gateway Connect service, see the following important notes:
    • The only Tunnel Mode parameter that can be configured is Active/Active.
    • There are no Keepalive mechanisms for the GRE tunnel with the AWS Transit Gateway Service.
    • BGP will be configured by default for the GRE tunnels. BGP Keepalive(s) are used for the BGP neighbor status.
    • The Edge does not support ECMP across multiple tunnels. Therefore, only one GRE Tunnel will be used for egress Traffic.
    • The Tunnel Source interface must have a default gateway configured for the feature to work.
  2. Under Profile, enable Cloud VPN, enable Non SD-WAN Destination via Edge, and choose NSD.
    Figure 12. Configuring Cloud VPN
  3. Under the Edge configuration in the Non SD-WAN Destinations via Edge, select the configured NSD.
    Figure 13. Selecting the Configured NSD
  4. For the specific NSD, configure the GRE tunnel parameters by selecting the + sign. Configure the following:
    • Tunnel Source as the LAN interface
    • Tunnel Source IP as the IP address configured on the LAN interface, if specified dynamically use Remote Diagnostics > Interface Stats to obtain the IP address
    • TGW ASN
    • The Primary Tunnel parameters can be configured by providing the Destination IP, the IP address provided on the TGW Connect Peer
    • The Internal Network/Mask must be the same as specified in the TGW Connect Peer Inside configuration.
    • The Secondary Tunnel parameters can be configured for the Destination IP and Internal Network/Mask.
    Figure 14. Adding the AWS TGW Connect Tunnel

    BGP will be enabled by default for this feature. The Local ASN field pre-populates. The Non SD-WAN via Edge configuration displays.

    Figure 15. Displaying the Non SD-WAN via Edge Configuration
  5. The configuration automatically creates the BGP configuration for the Neighbors. Each GRE Tunnel configuration towards the AWS Transit Gateway will automatically be created for two BGP Neighbors with information regarding the Link Name, Neighbor IP, Tunnel Type, and ASN.
    Figure 16. Displaying NSD Neighbors

    In Additional Options, the eBGP Max Hop is configured as 2, as this is a requirement for the TGW Connect Service. The additional parameters that are populated are Keepalive and Hold Timer based off the recommendation provided by AWS. The BGP Local IP is also pre-populated. These parameters cannot be modified.

    Figure 17. Adding Additional Options
    • Two NSD BGP Neighbors will be automatically added.
    • The Additional Options field will be modified for Max-Hop, Local IP, Keep Alive, and Hold Timer values.
  6. For the GRE tunnel endpoint, configure a static route on the VeloCloud Edge which specifies the Next-Hop to specify the Subnet Default Gateway and Interface as the LAN interface.
    Figure 18. Configuring the Static Route

Obtain Amazon Web Services Configuration Details

Describes how to obtain Amazon Web Services configuration details.
  1. From Amazon's Web Services, create VPC and VPN Connections. Refer to the instructions in Amazon's documentation.
  2. Make note of the Gateways associated with the enterprise account in the Orchestrator that might be needed to create a virtual private gateway in the Amazon Web Services.
  3. Make a note of the Public IP, Inside IP and PSK details associated with the Virtual Private Gateway. You need to enter this information in the Orchestrator when you create a Non SD-WAN Destination.

Configuring a Non SD-WAN Destination

 

After you obtain Public IP, Inside IP, and PSK information from the Amazon Web Services (AWS) website, you can configure a Non SD-WAN Destination.

To configure a Non SD-WAN Destination through a Gateway, see one of the following:
To configure a Non SD-WAN Destination through an Edge, see one of the following:

AWS Cloud WAN CNE Connect using Tunnel-less BGP

AWS has announced Tunnel-less Connect on Cloud WAN. This document describes AWS components and how to configure AWS and VeloCloud SD-WAN.

AWS Cloud WAN CNE Connect uses a Tunnel-less BGP capability provides a simpler way to build a global SD-WAN network using AWS backbone as a middle-mile transport network. With this capability, VeloCloud SD-WAN appliances can natively peer with an AWS Cloud WAN using Border Gateway Protocol (BGP) without requiring tunneling protocols like IPSec or GRE. This simplifies the integration an SD-WAN into an AWS cloud and allows the ability to leverage the high bandwidth AWS backbone for branch-to-branch connectivity across different geographic regions. This feature also supports in-built network segmentation, and enables the building of a secure SD-WAN at a global scale.

Typically, VeloCloud SD-WAN Virtual Edges (vEdges) deploy into an AWS Transport VPC. This Transport VPC may then peer with other VPCs, TGWs, or in this case, a CNE (Cloud Network Edge) in the Cloud WAN backbone to achieve connectivity with resources in AWS.

For Cloud WAN CNE Connect, the vEdges provisioned in the Transport VPC uses the LAN-facing routed and non-WAN interface to establish native L3 unencapsulated BGP peering with the CNE.

AWS Components

AWS requires the following components:
  • Cloud WAN Core Network
  • Policy definition
  • Core Network Edge (CNE)
  • Transport VPC
  • VPC Attachment
  • Connect Attachment

This assumes that you have other resources in other AWS VPCs using VPC peering to CNEs in the Core Network. If not, you must define the Core Network and CNEs and create the attachments to your existing workload VPCs.

AWS Configuration

  1. Use the following Arista online documentation to create vEdges in an AWS VPC:
    1. Virtual Edge Deployment Guide
    2. VeloCloud SD-WAN AWS CloudFormation Template- Green Field
    3. VeloCloud SD-WAN AWS CloudFormation Template- Brown Field
  2. On the AWS console, use the AWS Network Manager to create a Global Network, if one does not already exist in the AWS deployment.
    Figure 19. Create Global Network
  3. Create a Policy version.
    1. A Policy version defines and configures the key details of the solution:
      Figure 20. Create Policy Version
    2. Enter the BGP ASN ranges used by the CNEs:
      Figure 21. BGP ASN Ranges
    3. In the global Inside CIDR blocks field, define the respective CDR blocks for the CNEs.
      Figure 22. Adding CIDR Blocks
    4. Search for Edge locations and review the list of specific AWS AZ to place the CNE.
      Figure 23. Search for Edge Locations
      Note: The ASN and Inside CIDR Blocks for each Edge location uses the defined range defined for the Global Network.
    5. Search for Segments. Define logical segments using tags. Tag VPCs and Subnets to define segment membership. In this example, the format uses Key=Segment and Value=SDWAN.
      Figure 24. Defining Segments
      Note: Use the value defined in the policy.
    6. VCP and Connect Attachments specify the Segments used as well as the criteria for the Segments. In the example, a tag-value condition defines membership in the SD-WAN segment. The key-value pair uses the Condition values and must be present in VPCs and subnets in order to become Segment members.
      Figure 25. Configuring Attachment Policies
  4. Use one of the following types of attachments:
    • VPC Attachments
    • Connect Attachments
    1. VPC Attachments- Each SD-WAN Transport VPC has a VPC attachment to the CNE. Specify at least one subnet within the VPC when creating the VPC attachment. In the example, the CNE with the location, us-west-1 AZ peers with the SD-WAN Transport VPC private VLAN subnet. Also define a key-value pair for the Segment membership.
      Figure 26. Creating an Attachment

      If configured correctly, the Attachment displays the configuration details including SDWAN as the Segment and the Attachment policy rule number.

    2. Configure the Connect Attachment for Tunnel-less (No encapsulation) and specify an existing VPC Attachment as the Transport Attachment ID.
      Figure 27. Creating a Connect Attachment
      Figure 28. Tags

      If configured correctly, the Attachment displays membership in the SDWAN Segment. It also displays the Attachment policy rule number and NO-ENCAP as the Connect protocol.

      Figure 29. Displaying the Configured Policy
  5. Create Connect Peers in the Connect Attachment and define the SD-WAN vEdge BGP peerings in terms of the ASN and peer IP address.
    Figure 30. Creating Connect Peers
    Once configured, the AWS console provides two Core Network BGP peer IP addresses to use on the SD-WAN BGP neighborship and selects them randomly from the Inside CIDR range configuration.
    Figure 30. Connect Peer Settings

Configuring VeloCloud SD-WAN

Configure BGP neighbors to connect with the two IP addresses provided by the AWS Cloud WAN in Connect Peers. The IP addresses originate from the Inside CIDR range defined in the policy, and requires creating static routes on the Edge to point to the CNE neighbor IPs using the LAN-side routed interface.
Note: Each Connect peer receives different BGP Core Network Peer IP address and in turn, Static Routes and BGP Neighbors receive different configurations.
  1. Configure Static Route Settings.
    Figure 32. Configuring Static Routes
  2. When creating the BGP Neighbors, set the Max-Hop to two or more in the Additional Options column.
    Figure 33. Configuring Additional Hops
  3. Use Monitor > Routing > BGP Edge Neighbor State to verify that the BGP peer relationship has established with the configured Neighbor IP addresses.
    Figure 34. Configuring Routing