Airgap synchronization (agctl sync) fails when attempting to reach vmwaresaas.jfrog.io.
Symptoms include:
Synchronization Failure: The sync process fails with 404 Not Found Not Found or Connection Refused errors in the logs.
Upstream Synchronization issues: The Airgap Server is unable to retrieve net-new TKG versions, OS templates, or Photon security patches because the source repository has been decommissioned.
Operational Impact:
There is no production impact to Lifecycle Management (LCM) operations on both existing workloads or the platform. Operations relying on artifacts currently stored in the local Airgap registry will continue to function normally.
Patching remains operational via packages.broadcom.com and manual import into the Airgap Server using the standard Bundle Import Procedure.
TCA: 2.3, 3.0, 3.1, 3.1.1, 3.2 (including all version-related patches)
TCA Airgap Server: 2.3, 3.0, 3.1, 3.1.1, 3.2
The legacy repository (vmwaresaas.jfrog.io) is planned to be decommissioned on February 6th 2026.
Hardcoded Configuration: Airgap Server 3.2 and earlier utilize hardcoded references to this retired URL, causing upstream connections to fail.
Repository Migration: All software artifacts have been migrated to packages.broadcom.com to implement enhanced security measures for sensitive repository data.
Network Prerequisite: Ensure corporate firewalls or proxies allow the Airgap Server to reach packages.broadcom.com on TCP Port 443.
Upgrade Airgap Server: Upgrade the appliance to version 3.3.0 or higher. This updates the internal sync engine to use the Broadcom repository.
Define Target Version: Post-upgrade, update the configuration (e.g., user-inputs.yml) to define the specific TCA versions you wish to synchronize (backward compatible with 2.3+).
Note: A full sync is optional if TCA-M and TCA-CP are at version 3.2 or higher; a metadata-only sync is sufficient to restore connectivity.
| Question | Answer |
| Is there an immediate operational impact? | No. Airgap environments host artifacts locally. Existing clusters and CNFs continue to function normally since they do not rely on external repositories once deployed. |
| Will my ability to scale or manage existing clusters be affected? | No. Current clusters operate normally. Since Airgap managers rely on local metadata, scaling and LCM operations for already-synchronized builds remain fully functional. |
| Do I need to upgrade the Airgap Server immediately? | No. An urgent upgrade is not required if your environment already contains the artifacts needed for current operations. Plan the upgrade to Airgap Server 3.3 or higher within your next maintenance cycle to restore the ability to sync new artifacts. |
| What if I need a new artifact now or cannot upgrade yet? | If you cannot upgrade now, you can manually import data via the Bundle Import Procedure.(Local ISO/Bundle upload) to bypass the need for an internet sync. |
| Is Airgap Server 3.3 compatible with my current TCA Manager? | Yes. Airgap 3.3/3.4 is backward compatible with TCA versions 2.3 through 3.2, allowing you to upgrade the sync engine without changing your manager version. |
| Can I change the FQDN or Certificates during the Airgap Server upgrade? | No. Do not change the Appliance FQDN or Certificates. Changing these will break the "Trusted" status across all connected TCA Manager and Control Plane endpoints. |
| Are there proactive network steps I should take before the upgrade? | Yes. Ensure your firewalls or proxies allow the Airgap Server access to packages.broadcom.com on Port 443 so the first sync post-upgrade succeeds. |