About BGP Connections and Settings

The following configuration settings applies to BGP-enabled Spoke and Transit gateways.

All of these options are configured in the Aviatrix Controller on the Multi-Cloud Transit > Advanced Config page.

Local AS Number

The Local AS Number changes the Aviatrix Transit Gateway ASN number before you set up Aviatrix Transit Gateway connection configurations.

Gateway Manual BGP Advertised CIDR List

The Gateway Manual BGP Advertised CIDR option is only applicable to Transit gateways established by Transit Network workflow.

By default, Aviatrix Transit gateway advertises individual Spoke VPC/VNet CIDRs to VGW. You can override that 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).

Connection Manual BGP Advertised CIDR List

Manual Advertise Routes per BGP Connection expands the existing gateway based manual advertising routes feature to apply it to each BGP connection. One use case is to have better route advertising control for each remote BGP peer.

To enable this option, see

To disable the option, leave the field blank and click Save.

Gateway AS Path Prepend

You can insert BGP AS_PATH on the Aviatrix Transit Gateway to customize the BGP AP_PATH field when it advertises to VGW or peer devices. For example, if you enter 65458, 65478 in the input field, these ASN will appear to the remote end.

This configuration applies to all BGP peers of the Aviatrix Transit Gateway.

If you don’t configure this field, Transit gateway only advertises its own ASN.

To enable this option, see Enable Preserve AS Path.

Connection AS Path Prepend

Customize AS Path Prepend by specifying AS PATH for each BGP connection. This feature applies to any dynamic connection and Transit Gateway peering connections on a selected Aviatrix Transit Gateway.

Preserve AS Path

Preserve As Path option 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. Gateways will not advertise manual BGP advertised CIDRs if the CIDRs are no longer in the best route DB.

To enable this option, see Enable Preserve AS Path.

Active-Standby

The Active-Standby option provides the flexibility on Aviatrix Transit gateways and Aviatrix BGP Spoke gateways to connect to on-prem with only one active tunnel and the other one as backup.

Active-Standby Mode supports ActiveMesh 2.0 only.

The use case is a deployment scenario where on-prem device such as firewall does not support asymmetric routing on two tunnels. When Active-Standby mode is enabled, it applies to both BGP and Static Remote Route Based External Device Connections and for each connection, only one tunnel is active in forwarding traffic at any given time.

This feature can only be applied to non-HA remote devices in the External Device section.

Click Active-Standby mode to set it to Enabled.

Preemptive or Non-Preemptive Mode

If you enable Active-Standby mode, you can also select Preemptive or Non-preemptive options to determine the network’s behavior when the primary gateway goes down and the network switches to the standby gateway.

  • In Preemptive mode, when the primary gateway for a connection is back up, the network automatically switches back to using that primary gateway.

  • In Non-preemptive mode, the network continues to use the standby gateway even after the primary gateway is up again, until you initiate a manual switchover using the Switchover button.

If you enable Preemptive mode, the Switchover button is grayed out and unclickable because in Preemptive mode, there is no need for a manual switchover back to the primary gateway.

BGP ECMP

The BGP ECMP option allows to enable Equal Cost Multi Path (ECMP) routing for the next hop. For the Aviatrix Transit Gateway next hop routing decision process, see ActiveMesh 2.0

To enable this option, see Enable BGP ECMP.

BGP Polling Time (seconds)

Use BGP Polling Time option to change the default polling time. The range is 10 seconds to 50 seconds.

Aviatrix Transit Gateways report its BGP routes to the Controller periodically. By default, the periodic timer is 50 seconds. This polling time affects BGP route change convergence time.

BGP Hold Time (seconds)

Use the BGP Hold Time option to manually set the BGP holding time for your Aviatrix transit gateway. The hold time specifies how long a router waits for incoming BGP messages before it assumes the neighbor is dead.

The Aviatrix Transit Gateway hold time is bound to the Aviatrix keep alive message time, which is always 1/3 of the hold time. By default, the Hold Time is 180 seconds, and the Keep Alive time is 60 seconds. The supported Hold Time range is 12 to 180 seconds. If the remote site has a shorter hold time, the shorter hold time is used for the gateway.

Site2Cloud RX Balancing

This option is only available for Aviatrix Transit Gateways deployed in AWS on C5 and C5n instance types (except for c5.large and c5n.large).

The Site2Cloud RX Balancing option can increase forwarding throughput on Aviatrix Transit gateways for BGP-over-GRE External Device traffic (a.k.a. Site2Cloud or S2C GRE tunnels), in these situations:

  • On certain topologies that require high throughput, with External Devices that limit the number of GRE tunnels.

  • Where maintaining a high number of GRE tunnels increases operational burden.

If enabled, this option ensures that the Aviatrix Transit Gateway(s) are configured to maximize RX capacity and distribute ingress GRE tunnel load to all available vCPUs. This is mainly an alternative to building a large number of GRE tunnels, but a greater number of tunnels will be needed if the External Device imposes per-tunnel rate limits. A brief (sub-second) period of packet loss may affect the gateway when this setting is enabled or disabled.

To maximize the forwarding throughput increase enabled by this setting, consider the following:

  • The number of vCPUs provisioned for the Aviatrix Transit Gateway(s) should be significantly higher than the number of GRE tunnels (for example, four GRE tunnels to a 16 vCPUs c5n.4xlarge instance).

  • High Performance Encryption (HPE) should be enabled between Aviatrix Transit Gateways.

  • BGP ECMP should be enabled, to ensure load balancing of return traffic over multiple tunnels.