Error 403 Forbidden or MappingException during VNA Plugin Poll for vManage

Products

Network Observability Virtual Network Assurance CA Performance Management

Issue/Introduction

The VNA Plugin Poll Status shows as Failed in DX NetOps Portal:

VNA Plugin Poll Status fails with 403 Forbidden errors or MappingException when attempting to retrieve alarms or control connection data from vManage. This occurs even after upgrading VNA and vManage to compatible versions.․․․․‌‍‍‍‍‌‍‍

ERROR MESSAGE: "status code = 403, reason phrase = Forbidden, body = Access forbidden: role not allowed" "MappingException: sets leftId: null, and crashes the mapping process" "400 Bad Request on SLA classes"

SYMPTOMS:

VNA fails to receive responses for vManage alarm queries.
Control connection alarms appear in Spectrum but fail in CAPM.
VNA logs show MappingException with null IDs for specific devices.
Curl commands return HTML login pages for Microsoft Entra ID instead of JSON data.

CONTEXT: This issue occurs during automated VNA polling of vManage APIs, specifically when querying global alarms or SLA data across multiple resource groups.

IMPACT: VNA fails to monitor SD-WAN control connections and alarms, preventing visibility into network status and user impact.

Environment

VNA Version: 25.4.5
vManage Version: 20.12.5.3
Plugin: Viptela (SD-WAN)
Integration: Microsoft Entra ID (formerly Azure AD)

Cause

The issue is caused by a vManage configuration where the VNA service account lacks "Global" Resource Group permissions. When VNA performs a global query, vManage rejects it with a 403 error because the user is only authorized for a subset of devices.

Resolution

The VNA Gateway considers only authentication failures. If it observes a critical failure in any of the VNA Gateway plug-ins, the overall status of the VNA Gateway shows as "Failed".

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/performance-management/25-4/administrating/view-the-health-of-the-system.html

VManage engineer enabled permissions at the interface level.

Additional Information

How to enable the Viptela plugin engine in debug mode along with Groovy debug.

Turn on Engine debug on VNA:

1) Navigate to the following directory on the VNA host:
cd /opt/CA/VNA/wildfly/bin

2) Run this syntax below:
./jboss-cli.sh

3) In the jboss-cli (command line) run this syntaxt to connect:

connect

4) In the jboss-cli (command line) run this syntaxt to enable the Viptela plugin engine in debug mode:

/subsystem=logging/logger=VIPTELA_PLUGIN:write-attribute(name=level,value=DEBUG)

5) To quit type:

quit

Enable Groovy Debug:

1) Navigate to the following directory on the VNA host:

cd /opt/CA/VNA/collector/<Viptela_ENGINE_ID>/repository/TIM-INF/groovy/scripts/

2) Make a backup of the existing ViptelaHttpFunction.groovy file:

cp ViptelaHttpFunction.groovy ViptelaHttpFunction.groovy.original

3) Edit the ViptelaHttpFunction.groovy file and locate this row:

return new JsonSlurper().parseText( responseBody );

4) Add the following parameter before the row located in step 3.

logger.info( responseBody )
return new JsonSlurper().parseText( responseBody );

5) Save the file.

No need to restart any service.

Let it run for 45 minutes in debug mode.

Collect the following logging for Support:

The folders generated via the logging noted in Step 2 above.
All logs from the /opt/CA/VNA/wildfly/standalone directory.
All logs and folders under the /opt/CA/VNA/collector/Engine_UUID/tmp directory.

Disable Groovy Debug:

1) Navigate to the following directory on the VNA host:

cd /opt/CA/VNA/collector/<Viptela_ENGINE_ID>/repository/TIM-INF/groovy/scripts/

2) Edit the ViptelaHttpFunction.groovy file and locate this row:

logger.info( responseBody )

4) Remove the line located in step 2.