2

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

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.

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.

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

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

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like2 Follow
  • 2 Likes
  • 3 wk agoLast active
  • 141Views
  • 2 Following