Deploying an NSX Edge cluster from SDDC manager fails in the step "Failed to validate the BGP Route Distribution result for edge node with ID <UUID>"
search cancel

Deploying an NSX Edge cluster from SDDC manager fails in the step "Failed to validate the BGP Route Distribution result for edge node with ID <UUID>"

book

Article ID: 444931

calendar_today

Updated On:

Products

VMware NSX VMware SDDC Manager / VCF Installer

Issue/Introduction

When attempting to deploy or expand an NSX Edge cluster from the SDDC Manager interface, the automated workflow fails. The task pauses and generates an error alert indicating that route validation has failed for the newly deployed edge nodes.

The following specific execution error is caught during the task cycle:

Verify BGP Route Distribution Failed - Failed to validate the BGP Route Distribution result for edge node with ID ########-####-####-#################

Environment

VMware NSX 
VMware SDDC Manager

Cause

As a routine health and configuration validation check within the VCF edge deployment workflow, the system verifies whether the newly established BGP peerings are actively learning and advertising prefixes into the NSX architecture.

This failure occurs if the Tier-0 (T0) gateway has not successfully learned any active routing tables or prefixes from the upstream northbound peer routing switches (such as Top-of-Rack/TOR switches).

You can verify the exact state of the routing table by performing the following steps:

  1. Log directly into the command-line interface (CLI) of the specific edge node tied to the failing Tier-0 gateway.

  2. Navigate into the Tier-0 Service Router (SR) VRF context.

  3. Execute the routing query command:

vcf-example-edge01(tier0_sr[1])> get route bgp

Flags: t0c - Tier0-Connected, t0s - Tier0-Static, b - BGP, o - OSPF
t0n - Tier0-NAT, t1s - Tier1-Static, t1c - Tier1-Connected,
t1n: Tier1-NAT, t1l: Tier1-LB VIP, t1ls: Tier1-LB SNAT,
t1d: Tier1-DNS FORWARDER, t1ipsec: Tier1-IPSec, isr: Inter-SR,
ivs: Inter-VRF-Static, > - selected route, * - FIB route

Total number of routes: 2

isr> * ###.##.##.##/## [200/0] via x.x.x.x, inter-sr-272, 4d02h54m
isr> * ###.###.##.##/## [200/0] via ###.###.#.###, inter-sr-272, 4d02h54m

 

If the environment is experiencing this issue, the output will only display routes containing an isr flag. This flag signifies that paths are only being learned internally via Inter-SR routing mechanisms rather than externally over the expected BGP control plane. A healthy, validated routing entry must instead display a proceeding b tag to show it is successfully learned from an active external BGP neighbor, for example:

b  > * 0.0.0.0/0 [20/0] via ###.###.###.###, uplink-273, 01w3d00h

Resolution

If you are expecting routes to be advertised, then review the BGP configurations of the BGP neighbor that you have configured in SDDC to ensure you are advertising routes in to NSX.

If you are not advertising routes in to NSX purposefully as it is a new environment or you are routing via static routes then please set some routes temporarily to be advertised from the TOR while the workflow completes, these can then be removed once the cluster is deployed. Once advertised simply resume the task within SDDC.

If you believe you have encountered this issue and are unable to complete the workflow after reviewing the above, please open a support case with Broadcom Support and refer to this KB article.
For more information, see Creating and managing Broadcom support cases.