Deploying an NSX Edge cluster from SDDC manager fails in the step "Verify BGP Route Distribution".

Products

• VMware SDDC Manager
• VMware NSX

Issue/Introduction

• When attempting to deploy or expand an edge cluster from SDDC manager it fails on the step "Verify BGP Route Distribution".
• The failed task will present in SDDC similar to the below value:

Description: Verify BGP Route Distribution

Progress Messages: Failed to validate the BGP Route Distribution result for edge node with ID <Edge UUID>

Reference Token: <Unique Token Value>

• SDDC domain manager log (/var/log/vmware/vcf/domainmanager/domainmanager.log) will show logs similar to the below:

 ERROR [vcf_dm,<UUID>] [c.v.e.s.o.model.error.ErrorFactory,dm-exec-12]  [<Unique token value from above GUI error>] FAILED_TO_VALIDATE_BGP_ROUTE_DISTRIBUTION_RESULT Failed to validate the BGP Route Distribution result for edge node with ID <Edge UUID>
com.vmware.evo.sddc.orchestrator.exceptions.OrchTaskException: Failed to validate the BGP Route Distribution result for edge node with ID <Edge UUID>

• Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

 

Environment

VMware Cloud Foundation
VMware NSX
VMware NSX-T Data Center

Cause

As part of the validation of configuration within the VCF workflow it is checked if BGP peerings that have been configured are advertising routes via BGP into NSX. This is a normal and expected process and this error will occur if none have been learnt from the northbound peer. This can be checked by logging into the edge node of the T0 being deployed and then checking the routes being learnt by running get route bgp from within the t0 SR VRF.

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> * 192.168.32.44/32 [200/0] via 169.254.0.130, inter-sr-272, 4d02h54m
isr> * 192.168.32.50/32 [200/0] via 169.254.0.130, inter-sr-272, 4d02h54m

The above example shows a problematic example where the only routes have an isr label, meaning they are learnt via Inter-SR and not via bgp. An example of a valid route would be as below, note the proceeding b indicating it is learnt via BGP:

b  > * 0.0.0.0/0 [20/0] via 192.168.133.254, 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.