PDF

Limitations with mixing the user interfaces

Updated: April 15, 2026

Want to summarize with AI?

Log in

Outlines limitations and considerations when mixing different Cisco APIC user interfaces for configuration management.

Because Cisco APIC supports multiple user interfaces (UIs) for configuration, the potential exists for unintended interactions when you create a configuration with one UI and later modify the configuration with another UI. For example, configurations done through the NX-OS-style CLI are rendered in the Cisco APIC GUI. They can be seen, but sometimes might not be editable in the GUI. Similarly, changes made in the Cisco APIC GUI can be seen in the NX-OS-style CLI, but might only partially work.

Limitation with mixing the NX-OS-style CLI and the Cisco APIC GUI when you configure per-interface

When you configure per-interface, configurations you perform in the Cisco APIC GUI might only partially work in the NX-OS-style CLI.

For example, say that you configure a switch port in the GUI at Tenants > tenant-name > Application Profiles > application-profile-name > Application EPGs > EPG-name > Static Ports > Deploy Static EPG on PC, VPC, or Interface. When you use the show running-config command in the NX-OS style CLI, you receive output such as:

  leaf 102      
  interface ethernet 1/15       
  switchport trunk allowed vlan 201 tenant t1 application ap1 epg ep1       
   exit     
   exit

If you use these commands to configure a static port in the NX-OS style CLI, the following error occurs:

apic1(config)# leaf 102
apic1(config-leaf)# interface ethernet 1/15 
apic1(config-leaf-if)# switchport trunk allowed vlan 201 tenant t1 application ap1 epg ep1 
No vlan-domain associated to node 102 interface ethernet1/15 encap vlan-201

This occurs because the CLI has validations that are not performed by the APIC GUI. For the commands from the show running-config command to function in the NX-OS CLI, a vlan-domain must have been previously configured. The order of configuration is not enforced in the GUI.

Layer 3 external connectivity configuration modes

When you configure Layer 3 external connectivity with the APIC NX-OS style CLI, you have the choice of two modes:

  • Implicit mode: A simpler mode that is not compatible with the Cisco APIC GUI nor the REST API.

  • Named (or Explicit) mode: Compatible with the Cisco APIC GUI and the REST API.

In either case, the configuration should be considered read-only in the incompatible UI.

In both modes, the configuration settings are defined within an internal container object, the "Layer 3 Outside" (or "L3Out"), which is an instance of the l3extOut class in the API. The main difference between the two modes is in the naming of this container object instance:

  • Implicit mode: The naming of the container is implicit and does not appear in the CLI commands. The CLI creates and maintains these objects internally.

  • Named mode: You provide the naming of the container. CLI commands in the named mode have an additional l3Out field. To configure the named L3Out correctly and avoid faults, you must understand the API object model for external Layer 3 configuration.

Note

Except for the procedures in the Configuring Layer 3 External Connectivity Using the Named Mode section, this guide describes implicit mode procedures.

Guidelines and limitations for the layer 3 external connectivity configuration modes

The following guidelines and limitations apply to the Layer 3 external connectivity configuration modes:

  • Using implicit mode and named mode together: In the same Cisco APIC instance, you can use both modes together for configuring Layer 3 external connectivity. However, the Layer 3 external connectivity configuration for a given combination of tenant, VRF instance, and leaf switch can be done only through one mode.

  • Use one mode for a tenant VRF instance that is deployed for Layer 3 external connectivity: For a given tenant VRF instance, the policy domain where the external EPG can be placed can be in either the named mode or in the implicit mode. The recommended configuration method is to use only one mode for a given tenant VRF instance combination across all the nodes where the given tenant VRF instance is deployed for Layer 3 external connectivity. The modes can be different across different tenants or different VRF instances and no restrictions apply.

  • Configurations might be validated against inconsistencies: In some cases, an incoming configuration to a Cisco APIC cluster will be validated against inconsistencies, where the validations involve externally-visible configurations (northbound traffic through the L3Outs). An invalid configuration error message will appear for those situations where the configuration is invalid.

  • Supported configuration modes for external Layer 3 features: The external Layer 3 features are supported in both configuration modes, with the following exception: route peering and route health injection (RHI) with a Layer 4 to Layer 7 service appliance is supported only in the named mode. Use the named mode across all border leaf switches for the tenant VRF instance where route-peering is involved.

  • L3Outs created using the implicit mode CLI are read-only in the GUI: Layer 3 external network objects (also known as an L3Out) created using the implicit mode CLI procedures are identified by names starting with "_ui_" and are marked as read-only in the GUI.

  • L3Outs created using the implicit mode CLI can become unmodifiable in the CLI if modified using the REST API: The CLI partitions L3Outs by function, such as interfaces, protocols, route map, and EPG. Modifying an L3Out's configuration using the REST API can break this structure, preventing you from modifying the L3Out using the CLI.

To remove the unmodifiable L3Outs, see the Troubleshooting Unwanted _ui_ Objects section in the Cisco APIC Troubleshooting Guide.