SSP: Publishing Large Configurations and Retry Behavior.

Products

• VMware vDefend Firewall
• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

Publishing a large security configuration from SSP involves pushing groups (Infrastructure, Environment, Application, and App-tier) and security policies to NSX Manager.

Understanding the internal sequencing and retry behavior is important when working with configurations containing many VMs and tags.

Environment

SSP 5.2

Cause

Concurrent Publishing of Groups and Security Policies

Publishing of groups and security policies can trigger and process simultaneously. Each group and each security policy generates its own Kafka message that is dispatched and consumed independently by the app-discovery publication consumers. The dispatch of each payload from SSP to NSX Manager happens separately per entity.

There is no enforced ordering between the groups publishing process and the security policies publishing process. Both pipelines run in parallel once a publish action (individual or publish-all) is initiated.

Dependent Group Realization Check Before Security Policy Dispatch

Although there is no imposed ordering, SSP performs one additional safety check before actually dispatching a security policy payload to NSX Manager: dependent group realization validation.

Before pushing a security policy, SSP inspects all groups referenced in the policy's rules (sources, destinations, and scopes). It checks whether each referenced group has reached PUBLISH_SUCCESS status. If any dependent group has not been successfully published (i.e., is not yet realized on NSX Manager), SSP considers the dependent group unrealized and defers the security policy.

Retry Behavior on Unrealized Group Dependency

When dependent groups are not yet realized on NSX Manager, the publisher waits and re-attempts publishing the security policy with a progressive back-off interval. The wait time between retries is computed as:

This results in the following wait intervals per retry band:

1 – 5	5 seconds
6 – 10	10 seconds
11 – 15	15 seconds
16 – 20	20 seconds
21 – 25	25 seconds

 

A maximum of 25 re-attempts are allowed (RETRY_LIMIT = 25). Once all retry attempts are exhausted, the security policy's publish status is permanently set to PUBLISH_FAILED with the failure reason:

Retries exhausted, limit : 25

A security policy may observe upto 375 seconds of wait time (25 retrys = 5*5 + 5*10 + 5*15 + 5*20 + 5*25) before resulting to PUBLISH_FAILED state.

Resolution

User Action on Publish Failure Due to Exhausted Retries

In scenarios where security policies fail with the exhausted-retries failure reason, the recommended course of action is:

1. Verify that the corresponding groups are realized on NSX Manager — check the group publish status in SSP and confirm NSX realization from the NSX Manager side.
2. Re-publish the failed security policies individually once groups are confirmed as realized, or perform a Publish All operation.

A Publish All operation re-executes the full publish pipeline — all groups (expect groups in IN_PROGRESS or SUCCESS state) and all non-successfully-published security policies are re-queued. This can result in:

• Publish success — if the dependent groups are now realized.
• Publish failure — if groups are still not realized and the 25-attempt window is exhausted again.

 

This issue is internally tracked through #3714727.