Arista vEOS, Руководство по настройке

Страница: 15 / 128

The two vEOS Routers in the diagram above are configured with the Cloud HA feature as HA peers. The Cloud
HA on the vEOS routers would establish a BFD peering session between the two devices through ethernet or
tunnel interfaces.
When BFD connectivity loss is detected by the active vEOS router, the existing routes in the backup route table
in the cloud would be updated through cloud-specific API to use the active vEOS router as the next-hop. For
example, if vEOS 2 detected BFD connectivity loss with its peer, vEOS 2 would update the routes in Route
Table 1 so traffic from hosts in Subnet 1 and Subnet 2 for vEOS 1 would be forwarded to next-hop ID or IP
owned by vEOS 2. Traffic from the hosts in availability zone 1 would first be forwarded to the corresponding
subnet gateways in the cloud. After that, the subnet gateways in the cloud would forward the traffic toward the
new next-hop interface ID or IP that exist on vEOS 2. When vEOS 2 received the traffic, it would forward the
traffic on according to its routing table.
What about traffic going toward the hosts in availability zone 1 while connectivity to vEOS 1 is down? When
connectivity to vEOS 1 is down, hosts behind Subnet 1 and Subnet 2 become unreachable to the other part of
the network (routes being withdrawn by routing protocols like BGP). Since Subnet 1 and Subnet 2 are not
directly connected to vEOS 2, a routing strategy for the two subnets as "backup" on vEOS 2 is to be considered
as part of your network design. A typical design would be to use static routes for the subnets connected to the
peer vEOS router and point them toward the cloud subnet gateways of the active vEOS router (for example,
static route for peer subnet 10.1.1.0/24 would be configured on the active vEOS router as ip route10.1.1.0/24
10.2.1.1 255 where 10.2.1.1 is the gateway/next-hop for one of the ethernet interfaces) with a high administrative
distance value (least preferred). The static routes would be redistributed or advertised when the original routes
with better administrative distance are withdrawn or removed by dynamic routing protocol (such as BGP).
When BFD peering session is restored to UP state upon recovery, each active vEOS router would restore its
locally controlled route table entries (per user configuration) to point to itself as primary gateway again.
Cloud HA Configuration
This example configuration is based on the Cloud HA implementation diagram. The point of reference of the
configuration is the vEOS Router instance vEOS 1 in the Gateway Virtual Network.
Note: Starting from Release 4.20.6, the Cloud HA configuration is only available through the CLI. The
JSON file from the previous vEOS version is deprecated. You must convert the JSON configuration to
CLI configuration after upgrading from any previous vEOS version. For information regarding the
conversion of the JSON configuration to CLI configuration, go to:
JSON-Based Cloud High Availability
Configurations and Equivalent CLI Configurations on page 20.
Cloud HA Modes
The Cloud HA related configurations are divided into three separate configuration modes:
• Cloud Proxy - For proxy related configuration such as http and https.
• Cloud Provider - For cloud provider specific configuration such as region, credential, and proxy name.
• Cloud High-Availability - For configurations such as route, next-hop, BFD source interface, and peer.
The example includes specific configurations for various aspects of the Cloud HA implementation that are
configured prior to implementation. The specific configurations are:
• Configuring the Cloud Proxy on page 16
• Configuring the Cloud Provider on page 16
• Configuring Cloud High Availability on page 18
15
Cloud High Availability