Creating Fabrics and Fabric Groups, Release 4.3.1

Object name-length limits and automatic name shortening

When Nexus Dashboard generates the migration plan, each ESG, security association (contract clone), and Nexus Dashboard contract name is checked against a maximum length. Because Nexus Dashboard adds a tenant prefix to imported objects, the prefix consumes part of the budget for some object types. Generated names that would exceed the limit are shortened automatically, which allows for the analysis to succeed without manual intervention.

The migration plan applies the following limits:

Shortened ndContractName: Each cloned ESG contract carries two related names in the migration plan:

Nexus Dashboard seeds ndContractName from the original ACI contract name. If that name would exceed the effective Nexus Dashboard-contract budget, Nexus Dashboard shortens it by preserving the leading portion of the original, truncating the middle, and appending a deterministic 4-character hash of the full original name. The hash makes the shortening reproducible — a given source contract always produces the same shortened name — and prevents collisions when two original contracts share the same leading characters. Any prefix or suffix configured for ESG contract naming during the Create the migration record and APIC snapshot steps is preserved in the shortened result.

Verifying a shortened name: To identify the source of a shortened ndContractName, read the cloneFromDn field of the same contract clone entry in the migration plan; it preserves the full distinguished name of the original ACI contract even after shortening. Final names — shortened or not — also appear in the Map EPGs to ESGs and Review ESG contracts steps and in the Bulk edit YAML downloaded during analysis, so you can confirm them before proceeding to Conversion. If you edit a name in the Bulk edit YAML, keep it within the maximums listed above; otherwise, Nexus Dashboard re-shortens the value or rejects the upload during validation.

Inter-VRF global contracts and automatic scope expansion

If an endpoint group (EPG) or external EPG in one of the selected VRFs consumes or provides an inter-VRF global contract, the corresponding provider or consumer may reside in a VRF that you did not choose. Converting only one side of that relationship would leave broken contract references in the resulting ESG-based configuration, so Nexus Dashboard treats the selection as incomplete.

Before the migration plan is generated, Nexus Dashboard analyzes inter-VRF contract relationships across the in-scope tenants. If one side of an inter-VRF global contract is missing from your selection, Nexus Dashboard automatically adds the missing VRF or VRFs to the selection so that all VRFs that participate in the same contract are migrated together. The Select tenants/VRFs step then updates the VRF list to show both the VRFs that you originally selected and the VRFs that were added automatically.

Review the updated VRF list, including any VRFs that Nexus Dashboard added automatically, before you continue.

TCAM utilization and conversion mode

The migration workflow uses each leaf node’s policy TCAM utilization — measured by APIC as a 5-minute moving average — to choose between two conversion modes and, when utilization is too high, to block the conversion entirely. The check is applied per leaf node. A VRF inherits the highest TCAM band of any leaf node on which it is deployed, and the conversion mode is then selected globally from the worst band of any VRF included in the conversion scope.

TCAM utilization is sampled during the Analysis phase so that warning and critical conditions are visible before you reach the Conversion phase, and the same check is repeated in the Conversion phase before deployment so that recent changes in TCAM utilization are not missed.

For detailed information about TCAM-related migration behavior in the underlying ESG Migration Assistant process, see the Cisco APIC Security Configuration Guide, Release 6.2(x).

To review TCAM information in Nexus Dashboard:

Because the underlying APIC measurement is a 5-minute average, transient TCAM spikes may not be reflected immediately, and TCAM that you free up on a node is not reflected in the workflow’s view until the next 5-minute sample is published.

Deleting a migration

Use Delete migration when you want to permanently remove a migration record and the per-migration state that Nexus Dashboard tracks. Delete is appropriate for migration records that were created in error, that you no longer intend to run, or that you have completed and verified and no longer need for audit purposes.

Delete operates on the migration record, not on the migrated configuration. It does not undo any ESG, contract, or selector changes that Conversion has already applied to APIC, and it does not restore the APIC fabric to an earlier configuration. If you want to revert the APIC fabric, perform a snapshot rollback before you delete the migration. After a successful delete, the migration cannot be recovered, and the rollback snapshots associated with that migration are no longer reachable from Nexus Dashboard. See About snapshot rollback for more information.

What delete affects: When delete completes successfully, Nexus Dashboard performs the following on the migration record and its associated artifacts, in this order:

When a delete is allowed or rejected: Delete is rejected when an operation is currently in progress for the migration record — for example, analysis, deployment, cleanup, or rollback. Wait for the operation to complete or fail before you delete. A migration record in any other state, including pending, successful, and failed, can be deleted.

Force delete: A force option is available for every migration scenario, but is necessary for migration records that are stuck in the in-progress state because of an earlier helper or APIC failure. Force delete bypasses the in-progress check and removes the migration record in the same way as a normal delete. Use force delete only when you are certain that no operation is actively running for the migration, because deleting a record while an operation is genuinely in flight can leave the APIC fabric in a partial state. After a force delete, verify the APIC fabric state against the most recent successful snapshot for that migration; if one exists, reconcile any differences manually or by means of a separate rollback.

How to delete a migration: To delete a migration:

Nexus Dashboard performs the snapshot, record, and artifact cleanup described above and displays the result. The delete action is also recorded in the Nexus Dashboard audit log under the migration’s name and fabric.

What is preserved or deleted: Tenants, VRFs, ESGs, contracts, contract clones, selectors, and any other APIC objects created or modified by the migration remain in place after the migration record is deleted. The same applies to objects that were not part of the migration scope. Delete only removes Nexus Dashboard’s record of the migration workflow itself.

Restriction of one active migration per VRF

Each VRF on an ACI fabric can be a member of at most one migration that has not yet reached the successful terminal state. While a migration is still pending, in progress, or failed, the VRFs assigned to it remain reserved for that migration, and Nexus Dashboard prevents the same VRF from being included in any other migration on the same fabric. The reservation is released only in these conditions:

The constraint is enforced per fabric. A VRF with the same tenant name and VRF name on a different ACI fabric is a different VRF for migration purposes and is not affected.

Nexus Dashboard checks for VRF conflicts in two places during Phase 1: Analysis:

Resolving a VRF conflict: When a conflict is reported, choose one of the following actions on the migration that currently owns the conflicting VRFs:

After the conflict is resolved on the other migration, retry the Select tenants/VRFs step, or, when the conflict was triggered by auto-expansion, retry analysis. Nexus Dashboard rechecks the constraint each time and proceeds when the conflict has cleared.

About snapshot rollback

Snapshot rollback is available as part of the migration lifecycle. Use rollback when you need to return the migration to a previously captured state after a migration step has been performed.

During the migration workflow, APIC snapshots are created at key stages such as Analysis, Conversion, and Cleanup. These snapshots provide recovery points that you can use if you need to revert changes after reviewing the migration outcome or after identifying an issue during a maintenance window.

Preserve the snapshot created at the beginning of each phase until you have verified the results of that phase. If a problem is identified during conversion or cleanup, use the APIC built-in configuration rollback capability to return to the appropriate snapshot before continuing with additional migration actions.

For detailed information about rollback behavior and verification guidance for the underlying ESG Migration Assistant process, see the Cisco APIC Security Configuration Guide, Release 6.2(x).

Snapshot rollback returns both sides of the migration to a previously captured point in a single action:

Use rollback when, after reviewing the outcome of a migration step, you decide to revert that step before continuing. Because rollback affects the APIC fabric as well as the migration record, perform it during a maintenance window when possible.

Snapshots that are eligible as rollback targets: During the migration workflow, Nexus Dashboard creates three APIC configuration snapshots, one at the start of each phase. The snapshot is the rollback point for that phase:

When rollback is allowed: Rollback can be started from the migration record only when all of the following are true:

When any of these conditions is not met, Nexus Dashboard rejects the rollback request and the migration record state is left unchanged.

If a period of time has passed between the point that you went through a migration workflow and the point when you decide to perform a rollback, be aware of any changes that might have been made on the APIC side in that timeframe before performing a rollback. For example, if snapshots were taken during a particular migration workflow, and then you decide to perform a rollback at a later date using a snapshot from that earlier migration workflow, verify that changes have not been made on the APIC side during that timeframe because you might lose any configurations that were made in that timeframe when you perform the rollback.

How to perform a rollback: To perform a rollback:

Nexus Dashboard lists the rollback snapshots that exist for that phase; select the snapshot to use. Nexus Dashboard then performs the APIC configuration restore and, when it completes successfully, applies the migration-record reset for that phase.

Rollback runs as a single operation on the migration record. While it is running, the record is marked in progress and no other phase action can be started against it.

What happens after a successful rollback: When rollback succeeds:

What happens if rollback fails: If the APIC configuration restore does not succeed, Nexus Dashboard marks the migration record as failed and records the error returned by APIC. The migration record’s current phase is left at its pre-rollback value so that you can inspect the prior state. To recover, address the underlying APIC condition reported in the error, then either retry the rollback to the same target phase or open the migration record and use Resume to continue from the pre-rollback phase. Snapshots and migration-record data are not deleted on a failed rollback.

Per-fabric restriction on operations that actively modify the ACI fabric

In addition to the per-VRF restriction described in Restriction of one active migration per VRF, Nexus Dashboard enforces a per-fabric restriction on operations that actively modify the ACI fabric. For a given ACI fabric, at most one migration on that fabric can have any of the following operations in progress at the same time:

The restriction applies even when the migrations have non-overlapping tenant and VRF scopes because each of these operations changes the APIC fabric state that is shared across migration records.

The restriction does not apply to Phase 1: Analysis. Multiple migrations on the same fabric can run Analysis simultaneously, subject to the per-VRF restriction. The restriction also does not apply to snapshot creation, plan editing, or any other read-only step in the workflow.

Nexus Dashboard checks the restriction immediately before it starts a deploy, cleanup, or rollback. If another migration on the same fabric already has one of those operations in progress:

Wait for the in-progress operation to finish or fail before you retry the rejected operation. If you need to stop the in-progress operation rather than wait for it, complete or roll back that migration first, then retry.

The restriction is per-fabric. A migration on a different ACI fabric is not affected, and operations on different fabrics can proceed concurrently.

Examples of Bulk edit YAML files

At a certain point in the Phase 1: Analysis stage of the EPG-to-ESG migration workflow, you will be given the option to Bulk edit the migration plan as a YAML file. Following are examples of Bulk edit YAML files for your reference.

vrfs:
    - vrf: uni/tn-foo/ctx-vrf-1
      esgs:
        - name: ESG_foo_ap-1_1
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-1
            - uni/tn-foo/ap-ap-1/epg-epg-3
          prov:
            - uni/tn-foo/brc-ct-1
          cons: []
        - name: ESG_foo_ap-1_2
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-2
            - uni/tn-foo/ap-ap-1/epg-epg-4
          prov: []
          cons:
            - uni/tn-foo/brc-ct-1
        - name: ESG_foo_ap-1_3
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-5
            - uni/tn-foo/ap-ap-1/epg-epg-7
          prov:
            - uni/tn-foo/brc-ct-2
          cons: []
        - name: ESG_foo_ap-1_4
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-6
            - uni/tn-foo/ap-ap-1/epg-epg-8
          prov: []
          cons:
            - uni/tn-foo/brc-ct-2
      leakInternalSubnets: []
      leakExternalPrefixes: []
contractClones:
    - cloneName: ct-1_e_1
      cloneFromDn: uni/tn-foo/brc-ct-1
      ndContractName: ct-1
      providerESG: uni/tn-foo/ap-ap-1/esg-ESG_foo_ap-1_1
      consumerESG: uni/tn-foo/ap-ap-1/esg-ESG_foo_ap-1_2
    - cloneName: ct-2_e_1
      cloneFromDn: uni/tn-foo/brc-ct-2
      ndContractName: ct-2
      providerESG: uni/tn-foo/ap-ap-1/esg-ESG_foo_ap-1_3
      consumerESG: uni/tn-foo/ap-ap-1/esg-ESG_foo_ap-1_4
contractIfClones: []

vrfs:
    - vrf: uni/tn-foo/ctx-vrf-1
      esgs:
        - name: esg-1
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-1
          prov:
            - uni/tn-foo/brc-ct-1
          cons: []
        - name: esg-2
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-2
          prov: []
          cons:
            - uni/tn-foo/brc-ct-1
        - name: esg-3
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-3
          prov:
            - uni/tn-foo/brc-ct-1
          cons: []
        - name: esg-4
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-4
          prov: []
          cons:
            - uni/tn-foo/brc-ct-1
        - name: esg-5
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-5
          prov:
            - uni/tn-foo/brc-ct-2
          cons: []
        - name: esg-6
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-6
          prov: []
          cons:
            - uni/tn-foo/brc-ct-2
        - name: esg-7
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-7
          prov:
            - uni/tn-foo/brc-ct-2
          cons: []
        - name: esg-8
          applicationProfile: ap-1
          epgs:
            - uni/tn-foo/ap-ap-1/epg-epg-8
          prov: []
          cons:
            - uni/tn-foo/brc-ct-2
      leakInternalSubnets: []
      leakExternalPrefixes: []
contractClones:
    - cloneName: ct-1_e_1
      cloneFromDn: uni/tn-foo/brc-ct-1
      ndContractName: ct-1
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-1
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-2
    - cloneName: ct-1_e_2
      cloneFromDn: uni/tn-foo/brc-ct-1
      ndContractName: ct-1
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-1
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-4
    - cloneName: ct-1_e_3
      cloneFromDn: uni/tn-foo/brc-ct-1
      ndContractName: ct-1
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-3
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-2
    - cloneName: ct-1_e_4
      cloneFromDn: uni/tn-foo/brc-ct-1
      ndContractName: ct-1
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-3
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-4
    - cloneName: ct-2_e_1
      cloneFromDn: uni/tn-foo/brc-ct-2
      ndContractName: ct-2
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-7
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-6
    - cloneName: ct-2_e_2
      cloneFromDn: uni/tn-foo/brc-ct-2
      ndContractName: ct-2
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-7
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-8
    - cloneName: ct-2_e_3
      cloneFromDn: uni/tn-foo/brc-ct-2
      ndContractName: ct-2
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-5
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-6
    - cloneName: ct-2_e_4
      cloneFromDn: uni/tn-foo/brc-ct-2
      ndContractName: ct-2
      providerESG: uni/tn-foo/ap-ap-1/esg-esg-5
      consumerESG: uni/tn-foo/ap-ap-1/esg-esg-8
contractIfClones: []

vrfs:
    - vrf: uni/tn-tn-apic-94-11/ctx-vrf-1
      esgs:
        - name: esg-1
          applicationProfile: ap-1
          epgs:
            - uni/tn-tn-apic-94-11/ap-ap-1/epg-epg-1
          prov:
            - uni/tn-tn-apic-94-11/brc-ct-icmp
            - uni/tn-tn-apic-94-11/brc-ct-web
          cons: []
      leakInternalSubnets: []
      leakExternalPrefixes: []
    - vrf: uni/tn-tn-apic-94-11/ctx-vrf-2
      esgs:
        - name: esg-2
          applicationProfile: ap-1
          epgs:
            - uni/tn-tn-apic-94-11/ap-ap-1/epg-epg-2
          prov:
            - uni/tn-tn-apic-94-11/brc-ct-https
          cons:
            - uni/tn-tn-apic-94-11/brc-ct-web
      leakInternalSubnets: []
      leakExternalPrefixes: []
    - vrf: uni/tn-tn-apic-94-11/ctx-vrf-3
      esgs:
        - name: esg-3
          applicationProfile: ap-1
          epgs:
            - uni/tn-tn-apic-94-11/ap-ap-1/epg-epg-3
          prov: []
          cons:
            - uni/tn-tn-apic-94-11/brc-ct-https
            - uni/tn-tn-apic-94-11/brc-ct-icmp
      leakInternalSubnets: []
      leakExternalPrefixes: []
contractClones:
    - cloneName: ct-https_e_1
      cloneFromDn: uni/tn-tn-apic-94-11/brc-ct-https
      ndContractName: ct-https
      providerESG: uni/tn-tn-apic-94-11/ap-ap-1/esg-esg-2
      consumerESG: uni/tn-tn-apic-94-11/ap-ap-1/esg-esg-3
    - cloneName: ct-icmp_e_1
      cloneFromDn: uni/tn-tn-apic-94-11/brc-ct-icmp
      ndContractName: ct-icmp
      providerESG: uni/tn-tn-apic-94-11/ap-ap-1/esg-esg-1
      consumerESG: uni/tn-tn-apic-94-11/ap-ap-1/esg-esg-3
    - cloneName: ct-web_e_1
      cloneFromDn: uni/tn-tn-apic-94-11/brc-ct-web
      ndContractName: ct-web
      providerESG: uni/tn-tn-apic-94-11/ap-ap-1/esg-esg-1
      consumerESG: uni/tn-tn-apic-94-11/ap-ap-1/esg-esg-2
contractIfClones: []

vrfs:
    - vrf: uni/tn-coke/ctx-vrf-coke-2
      esgs:
        - name: ESG_instp-vrf-coke-2
          applicationProfile: l3out-vrf-coke-2
          epgs:
            - uni/tn-coke/out-l3out-vrf-coke-2/instP-instp-vrf-coke-2
          externalSubnets:
            - ip: 0.0.0.0/16
              scope: private
          prov:
            - uni/tn-coke/brc-ctr-new
          cons: []
      leakInternalSubnets: []
      leakExternalPrefixes: []
    - vrf: uni/tn-coke/ctx-vrf-coke
      esgs:
        - name: esg-coke-2
          applicationProfile: anp-coke
          preExisting: true
          epgs: []
          prov: []
          cons: []
      leakInternalSubnets: []
      leakExternalPrefixes: []
contractClones:
    - cloneName: ctr-new_e_1
      cloneFromDn: uni/tn-coke/brc-ctr-new
      ndContractName: ctr-new
      providerESG: uni/tn-coke/ap-l3out-vrf-coke-2/esg-ESG_instp-vrf-coke-2
      consumerESG: uni/tn-coke/ap-anp-coke/esg-esg-coke-2
contractIfClones: []

Understanding ACI fabric configurations that are skipped during the import process

When you start the process of importing tenant policies from ACI, as described in Import tenant policies from ACI into Nexus Dashboard, certain policies might not be compatible with Nexus Dashboard. In those situations, Nexus Dashboard skips those policies during the import process and imports only the supported policies. When this happens, a message is displayed with this information:

These are examples of situations where an ACI fabric configuration might be skipped during the import process:

EPG-to-ESG migration phases in Nexus Dashboard

The EPG-to-ESG migration workflow is available in ACI fabrics that are members of the VXLAN-ACI fabric group under Segmentation and security > EPG to ESG migration. Nexus Dashboard uses a phased workflow so that you can review the migration scope, validate the proposed changes, and proceed in a controlled manner.

The workflow is organized into three phases:

Tenant policy import is not part of the ESG Migration Assistant phase flow. Treat it as a separate post-migration task after you have completed and verified the migration workflow.

Complete migration verification and any required rollback decisions before you begin tenant policy import.

These phases describe the guided migration workflow in Nexus Dashboard. Additional lifecycle actions, such as resume and snapshot rollback, are available from the migration context outside the phase sequence.

Phase 1: Analysis

Use the Analysis phase to create the migration record, capture the initial APIC state, choose the migration strategy, and review the proposed EPG-to-ESG mappings and ESG contract relationships before proceeding to the Conversion phase. Only analysis is performed at this phase; there is no change of configurations on the member ACI fabric in this phase.

During analysis, Nexus Dashboard generates the migration plan used by the later phases. Review this plan carefully before conversion so that the resulting ESG groupings and contract relationships match the intended security policy model.

Phase 2: Conversion

Use the Phase 2: Conversion phase to apply the reviewed migration plan, create the pre-conversion snapshot, review the proposed ESG and contract changes, deploy the configuration, monitor progress, and review the summary before proceeding to the Cleanup phase. This phase applies the configuration changes to the ACI fabric and may be disruptive, so we recommend that you perform this phase during a maintenance window to minimize issues with any potential disruptions.

Before conversion begins, preserve a rollback point by creating the pre-conversion snapshot. During this phase, Nexus Dashboard validates the reviewed migration plan, applies the ESG-based configuration, and reports status for the conversion workflow.

Create the pre-conversion snapshot to preserve the current APIC state before active ESG-based changes are applied. Keep this snapshot available until you have verified the conversion results.

Phase 3: Cleanup

Use the Cleanup phase to review the obsolete legacy policy artifacts identified after conversion, perform the cleanup actions, and review the final summary to complete the migration workflow.

Cleanup removes legacy EPG-based policy artifacts that are no longer needed after the ESG-based configuration is in place. Even after cleanup is complete, snapshot rollback may still be available from the migration context when rollback conditions are met.