Downloading MAC address table for a VLAN-backed NSX-T segment throws an error "CCP: null.. (Error code: 500255)"
search cancel

Downloading MAC address table for a VLAN-backed NSX-T segment throws an error "CCP: null.. (Error code: 500255)"

book

Article ID: 322038

calendar_today

Updated On:

Products

VMware NSX Networking

Issue/Introduction

This informational KB explains about an expected behaviour of the product.

Symptoms:
+ When trying to download MAC address table for a VLAN-backed NSX-T Segment (both in cases when the segment is empty and non-empty) from NSX-T UI over the 'Central Control Plane' component, it throws an error as below,

image.png

+ The same observation can be seen when trying to perform the same over the API as well.
ex:
GET https://<nsx-mngr>/policy/api/v1/infra/segments/VLAN-Test-Segment/mac-table?format=csv

o/p:
{
    "error_code": 500255,
    "module_name": "Policy",
    "error_message": "Runtime API failed with error: Failed to fetch MAC or VTEP table of logical switch 200330e7-ca6c-49ac-adc8-651c7235f464 from CCP: null.."
}

+ A similar observation can be seen for an Overlay-backed NSX-T segment which is 'empty' (no VMs nor any gateway logical-switch-ports are connected on the segment).

Environment

VMware NSX 4.1.0
VMware NSX-T

Cause

+ For VLAN-backed NSX-T segments, there are no MAC address table or VTEP table(only applicable for Overlay segments) that gets maintained on the transport nodes. This we can verify by running the below cmd in a host where we have VMs connected on a VLAN-backed NSX-T segment.
ex:
esx-04.corp.local> get logical-switch 200330e7-ca6c-49ac-adc8-651c7235f464 mac-table
Fri Nov 03 2023 UTC 02:52:27.091
% VLAN backed logical switch not supported
+ Hence when we try to download the MAC address table for such segment from CCP component of the NSX-T Managers, which in turn tries to fetch the data from the transport nodes only. As the returned value is empty in this case the CCP returns the error.
+ The same logic applies to a empty Overlay NSX-T segment as well.

Resolution

+ As explained in the "cause" section, this is an expected behaviour of the product.
+ From NSX 4.1.1 onwards the error message has been modified a bit to provide more context on why the error is thrown (i.e. "NOT_FOUND") instead of the generic error we can see in the "Symptoms" section.
Ex:
"error_message": "CCP replied with error NOT_FOUND, for MAC or VTEP table of logical switch 200330e7-ca6c-49ac-adc8-651c7235f464."

Workaround:
N/A

Additional Information

Impact/Risks:
N/A