Aviatrix Traffic Engineering Capabilities with Static, BGP, Cloud Native and SD Routing

Aviatrix Controller (AVX-CTRL) provider rich set of options and knobs when it comes traffic engineering, resiliency and high availability.

Aviatrix Controller runs and understands various routing stacks. With this knowledge it builds and maintain robust control and data plane (you can think of it as an overlay). It has global knowledge of the entire network in multi-cloud or single cloud deployments.

AVX-CTRL make use of various core routing stacks depending on the use-case and requirements. Following is just an example of where various routing stacks are being invoked. They all work in conjunction of each other. And in most of the cases are coupled with other services such as API calls and cloud native queuing services.

1. Static:
   Static routes are being programmed in VPC/VNET depending on the requirement
2. BGP:
   BGP is programmed when connecting to on-prem routers/firewalls/etc.
3. Software Defined (SD Routing):
   AVX-CTRL builds the software defined routing overlay using Aviatrix Transit and Spoke gateways
4. Cloud Native:
   AVX-CTRL controls and manages the routing for Cloud Native construsts such as AWS-TGW, Azure VNET, GCP VPC routes and Azure virtualWAN.

Following are some of the examples

Aviatrix Transit Gateway Traffic Engineering Options

AVX-TR-GW <--> AVX-TR-GW: BGP AS_PATH Prepend

Aviatrix Transit GW peering allows the on-prem learned routes to be propagated to the Transit peering routes along with the AS_PATH information.

This is build into the control plane and does not requires any additional configuration.

On-Prem --> AVX-TR-GW: AS_PATH for Next Hop Decision

This feature enhances the next hop routing decision when the Aviatrix Transit Gateway makes routing decisions.

With this enhancement, by default the Aviatrix Transit Gateway selects the shortest AS_PATH length as the preferred routes when same route is being advertised from on-prem.

If on-prem (remote site) advertises the same routes (CIDRs) with the same AS_PATH lengths, the Aviatrix Transit Gateway routes based on ECMP.

This is build into the control plane and does not requires any additional configuration.

AVX-TR-GW --> On-Prem: Prepend AS_PATH

You can insert BGP AS_PATH on the AVX-TR-GW's customize the BGP AP_PATH field when it advertises to VGW or peer devices.

For example, enter 65458, 65478 in the input field, these ASNs will appear to the on-prem (remote end).

If you don’t configure this field, AVX-TR-GW only advertises its own ASN.

AVX-TR-GW --> On-Prem: Selective BGP Advertised CIDRs

By default, Aviatrix Transit GW advertises individual Spoke VPC CIDRs to VGW. One can override this behavior by manually entering the intended CIDR list to advertise to VGW.

This feature is critical to limit the total number of routes carried by VGW (maximum is 100)

AVX-TR-GW --> On-Prem: Advertise Transit VPC Network CIDR(s)

By default, AVX-TR-GW does not advertise Transit VPC CIDRs

When this feature is enabled, AVX-TR-GW advertises the Transit VPC CIDR to VGW. The AVX-CTRL programs the 3 RFC1918 routes in the AWS route table to point to the AVX-TR-GW. It also programs the learned routes from VGW into the AWS Transit VPC route table.

AVX-TR-GW <--> AVX-TR-GW: Exclude Network CIDRs

Excluded Network CIDRs is an optional field. When the field is empty, AVX-TR-GW propagates all learned routes from both Spoke VPCs and on-prem across the transit peering.

Using this filter option prevents the overlapped CIDRs from being propagated to the other AVX-TR-GW.

The diagram below illustrates how Excluded Network CIDRs can be used in a two region deployment. In this case, 10.20.0.0/16 appears on both sides as VPC CIDR. To allow Transit Peering to proceed, configure on both AVX-TR-GW to excluded network CIDRs with 10.20.0.0/16.

 

 

 

To exclude multiple CIDR ranges, input a list of CIDRs separated by comma.

Route Approval

Aviatrix Transit Gateway dynamically learns BGP routes from remote site, these learned routes are reported to the AVX-Controller which in turn programs route entries to Spoke VPCs route table. For more details take a look at the following link

https://docs.aviatrix.com/HowTos/transit_approval.html#encrypted-transit-approval

Edge Segmentation

Edge Segmentation allows you to specify the edge segments on Aviatrix Transit GW, and which AWS Security Domain each of these segments can communicate with.

https://community.aviatrix.com/t/g9hh9fk/what-is-aviatrix-edge-segmentation

AWS Transit Gateway (TGW) Traffic Engineering Options

Update VPC CIDR

If a new spoke VPC CIDR is added/deleted or a new VPC route is added/deleted, clicking this option updates VPC attachments without having to detach the VPC first.

Update VPC CIDR automatically makes routing adjustment when there is VPC CIDR change, for example, a new VPC CIDR has been added to the VPC. It also makes routing adjustment when a new route table is added or deleted.

VPC --> AWS-TGW: Spoke VPC Customized Routes

This is very powerful traffic engineering option and allows customized summary routes to be programmed in the attached VPC route table. This feature helps overcome AWS  100 routes per VPC limitation.

By default, RFC 1918 summarized routes and learned non RFC 1918 specific routes are dynamically programmed into each Spoke VPC’s route table. This feature allows enterprises to statically program specific routes whose target is TGW.

When this feature is enabled, Controller will not program RFC1918 routes in the VPC route table. Also all dynamically learned routes by the AWS-TGW are not programmed into the Spoke VPC route tables.

Enterprises then need to make sure that AWS-TGW then has the route that can take the traffic to proper destination else traffic will be blackholed

 

 

 

When you customize the Spoke VPC route entries, no learned routes are programmed into the VPC route table. If you wish no route to be programmed by Aviatrix Controller, enter 0.0.0.0/32.

 

Following screen shots shows the default behavior without this feature enabled.

 

 

 

VPC --> AWS-TGW: Spoke VPC Advertised Routes

By default, spoke VPC advertises its local VPC CIDR to TGW route table. Following picture shows the default behavior where the VPC local route (10.27.0.0/16) was advertised to AWS-TGW

 

This powerful feature allows spoke VPC to advertise a different network CIDR to TGW.

This avoid potential overlapping CIDRs in the environment. For example there are environments where all spoke VPCs have one identical CIDR. Attaching these Spoke VPCs to a TGW will result in error. For example, spoke VPC CIDR 10.27.0.0/16 is common across all Spoke VPCs. By using this feature, the spoke VPConly advertises 10.100.59.0/24 and suppress or filter 10.27.0.0/16 at the VPC level.

 

Disable Spoke VPC Local Route Propagation

When selected, the local spoke VPC CIDR is not propagated to the TGW route table.

Exclude AWS-TGW Connection

AWS-TGW has a some limitations where it does not preserve BGP attributes for the routes it learns from on-prem. This feature excludes the advertisement of certain AWS-TGW attachment (DXGW and VPN) to the AVX-TR-GW.

Consider the following scenario where two AWS-TGWs in two different regions are peered using the AVX-TR-GWs. Here the on-prem site-1 and site-2 are advertising the same CIDR (10.0.0.0/8) with different AS_PATH value to prefer one route vs another.

 

Since AWS-TGW does not preserve any BGP attributes, by the time it reaches to the AVX-TR-GW, both routes are identical. In order to prevent routing loop, the AVX-TR-GW will reject the peering.

To solve the problem configure both AVX-TR-GWs to exclude 10.0.0.0/8. With this configuration, Site-1 still accesses Prod-1/Prod-2 and Dev-1/Dev-2 via the local regional AWS-TGW and Site-2 accesses Prod-3/Prod-4 and Dev-3/Dev-4 via its local regional AWS-TGW.

AWS-TGW Audit Routes

Audit Routes verify route correctness by scanning the attachment’s VPC route table, its attached TGW route table and connected TGW route tables. Use this to detect missing routes deleted by mistake or through programming errors.

References

For more details, check the following docs.

https://docs.aviatrix.com/HowTos/transit_gateway_peering.html#default-route-propagation-behavior

https://docs.aviatrix.com/HowTos/UCC_Release_Notes.html#id3

https://docs.aviatrix.com/HowTos/transitvpc_workflow.html#prepend-as-path

https://docs.aviatrix.com/HowTos/transit_gateway_peering.html#excluded-network-cidrs