Traceflow Drop Reason KB: NO_GATEWAY_CIDR_FOUND

Products

• VMware NSX

Issue/Introduction

• A VM in a VPC subnet under a TGW with a distributed VLAN connection is experiencing north-to-south connectivity issues.
• When using traceflow to inject a packet from the VM's vNIC, the result shows a drop observation with the reason NO_GATEWAY_CIDR_FOUND.
• The possible traceflow UI outputs can be:
  

 

• The possible traceflow observations API (invoke API GET https://<manager-ip>/polcy/api/v1/infra/traceflows/<traceflow-id>/observations) outputs can be:
  {
    "resource_type" : "TraceflowObservationDroppedLogical",
    "sequence_no" : 0,
    "transport_node_id" : "<TRANSPORT_NODE_ID>",
    "transport_node_name" : "<TRANSPORT_NODE_NAME>",
    "transport_node_type" : "ESX",
    "timestamp" : 1766989510952,
    "timestamp_micro" : 1766989510952973,
    "component_type" : "LR",
    "component_sub_type" : "LR_DTGW",
    "component_name" : "Default Transit Gateway",
    "reason" : "NO_GATEWAY_CIDR_FOUND"
}

Environment

VCF 9.1 or above

Cause

• There is no gateway address for the distributed VLAN connection with a CIDR that matches the CIDR of the source network.
• For example, the source IP of the VM trying to communicate with the external network is 10.11.0.#, but the configured gateway address of the distributed VLAN connection for the associated Transit Gateway is 10.10.0.#/16.
• Obviously, the source IP 10.11.0.# is not within the 10.10.0.#/16 CIDR range, which is why the packet is dropped.

Resolution

• In this case, the source IP 10.11.0.# needs to be reachable by the external network, so the gateway IP should be in the same network as this source IP.
• A possible fix is to add a new distributed VLAN connection, or update the existing distributed VLAN connection on the current TGW, so that the CIDR of the external gateway includes the source IP range (e.g., 10.11.0.#/16).
• For sure, users need to ensure the new added gateway address is valid and reachable.
• Here are the specific steps to check the distributed VLAN connection from the UI perspective:
  
  i) Get the specific TGW name from the traceflow UI result output. E.g., "Default Transit Gateway ".
  
     

        ii) Navigate to the distributed VLAN connection configuration with the mismatched gateway address, and then either update it to the correct address or add a new distributed VLAN connection with the correct gateway address
 
           

• Here are the specific steps to check the distributed VLAN connection from the API perspective:

1. Get the TGW name and path from the traceflow observation with component_type "LR_DTGW".
2. Get the distributed VLAN connection path from the API "GET https://<manager-ip>/policy/api/v1/<transit-gateway-path>/attachments".
3. Check the distributed VLAN connection configuration from the API "GET https://<manager-ip>/policy/api/v1/infra/distributed-vlan-connections/<distributed-vlan-connection-id>".

Additional Information

Refer the document below for more information about how the Transit Gateway (TGW) will connect to networks outside of NSX and which services will be available on it.

https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/advanced-network-management/administration-guide/virtual-private-cloud-in-nsx/external-connections.html