Establishing Multiple External Connectivity using Aviatrix Site-2-Cloud (S2C)

The premises of this design is to establish a backup path using the internet to protect application flows that still leverage on-prem and or customers seating on a main campus accessing apps living on the cloud:

As I don’t have a DX circuit I’m going to use a Site-to-Site VPN to simulate it and Site-2-Cloud from the AVX transit gateways will provide backup to the DX connection.

Primary Configuration

The primary connection uses DX and there are a few supported scenarios to integrate it with Aviatrix. I’m going to leverage private interfaces and connect it to a VGW on the same region as my AVX transit:

Once the VPN Gateway is created, we attach it to the transit hub:

From the Multi-cloud Transit External menu we connect to the remote branch device (a CSR1000v running on an Equinix Metal server):

Checking the VPN connections:

Checking on the remote side:

tunnels are up
bgp peers are connected and exchanging routes

AWS advertises 172.16.0.0/16 (AVX transit) using different metrics 100 and 200 respectively.

The next step is to build an overlay between the AVX transit gateways and the remote device but forcing it through the previously created tunnel (as it is supposed to work as a DX connection):

A static route helps the AVX transit gateways to reach out to private interface of the remote device:

Enable route propagation on the VGW would also satisfy the need but it would bring other prefixes to the VPC route table (we can always filter what we will advertise from on-prem).

Limiting the number of routes received

On the on-prem router we can create a prefix list to limit the routes advertised towards the AWS VGW:

ip prefix-list router-to-vgw seq 10 permit 192.168.11.1/32

The prefix-list is then used on the BGP peer:

router bgp 361XX
bgp log-neighbor-changes
bgp graceful-restart
neighbor 169.254.161.193 remote-as 64512
neighbor 169.254.161.193 ebgp-multihop 255
neighbor 169.254.161.193 update-source Tunnel1
neighbor 169.254.231.253 remote-as 64512
neighbor 169.254.231.253 ebgp-multihop 255
neighbor 169.254.231.253 update-source Tunnel2
!
address-family ipv4
network 192.168.100.0
redistribute connected
neighbor 169.254.161.193 activate
neighbor 169.254.161.193 prefix-list router-to-vgw out
neighbor 169.254.231.253 activate
neighbor 169.254.231.253 prefix-list router-to-vgw out
maximum-paths 4
exit-address-family

On the AWS side we can check if only the prefix-list is learned:

Site-2-Cloud configuration using private network addresses

I’m using a GRE tunnel in this case. Real life scenario we could also go with IPSec depending on the security requirements for data in transit. After downloading and applying the config:

Tunnels 101 and 102 are up. Those are GRE tunnels using private IP addresses:

At this point we have connectivity between on-prem and the Aviatrix fabric using a “private” circuit.

Secondary Configuration

The secondary connection leverages the internet running BGP on top of a pair of IPSec tunnels:

We can download the configuration from the Site-2-Cloud menu:

Applying the config to the remote device:

Traffic “Engineering”

My spoke (10.3.0.0/24) is reachable through four paths:

2 GRE tunnels
2 IPSEC tunnels

There are a few parameters under Multi Cloud Transit -> Advanced Config that allows us to customize the BGP process that runs on the AVX gateways:

Manual Advertise Routes: allows to manually advertise routes to each BGP connection.

Preserve AS Path: This field is applicable to both Gateway Manual BGP Advertised Network List and Connection Manual BGP Advertised Network List. When disabled, behavior defaults to the AS path being stripped during BGP route advertisements from transit or spoke gateways to neighbors. When enabled, AS Path is preserved.

Gateway AS Path Prepend: we can insert BGP AS_PATH on the Aviatrix Transit Gateway to customize the BGP AP_PATH field when it advertises to peer devices.