This section describes requirements and guidelines for the Nexus Dashboard cluster regardless of the deployment type.

General deployment guidelines and restrictions

• Deploying a 4-cluster node, where the cluster consists of:

  • 3 virtual nodes (data), and

  • 1 standby node

  is not a supported configuration. Redeploy this cluster without the standby node. If one of the nodes in the cluster fails, reinstall a new node and navigate to Admin > System Status > Nodes, then click Actions > Re-Register to add the reinstalled node back into the cluster.

• Deploying virtual Nexus Dashboard VMs on remote storage is unsupported and may lead to unexpected behavior.

Domain Name System (DNS) and Network Time Protocol (NTP)

The Nexus Dashboard nodes require valid DNS and NTP servers for all deployments and upgrades.

Lack of valid DNS connectivity (such as if using an unreachable or a placeholder IP address) can prevent the system from deploying or upgrading successfully, as well as impact regular services functionality.

Note	Nexus Dashboard acts as both a DNS client and resolver. It uses an internal Core DNS server which acts as DNS resolver for internal services. It also acts as a DNS client to reach external hosts within the intranet or the Internet, hence it requires an external DNS server to be configured.

The following guidelines apply for DNS:

• For external DNS servers, both TCP and UDP traffic must be allowed. See Communication ports for LAN deployments and Communication ports for SAN deployments for more information.

• Nexus Dashboard does not support DNS servers with wildcard records.

Nexus Dashboard also supports NTP authentication using symmetrical keys. If you want to enable NTP authentication, you will need to provide the following information during cluster configuration:

• NTP Key–A cryptographic key that is used to authenticate the NTP traffic between the Nexus Dashboard and the NTP server(s). You will define the NTP servers in the following step, and multiple NTP servers can use the same NTP key.

• Key ID–Each NTP key must be assigned a unique key ID, which is used to identify the appropriate key to use when verifying the NTP packet.

• Auth Type–This release supports MD5, SHA, and AES128CMAC authentication types.

The following guidelines apply when enabling NTP authentication:

• For symmetrical authentication, any key you want to use must be configured the same on both your NTP server and Nexus Dashboard.

  The ID, authentication type, and the key/passphrase itself must match and be trusted on both your NTP server and Nexus Dashboard.

• Multiple servers can use the same key.

  In this case the key must only be configured once on Nexus Dashboard, then assigned to multiple servers.

• Both Nexus Dashboard and the NTP servers can have multiple keys as long as key IDs are unique.

• This release supports SHA1, MD5, and AES128CMAC authentication/encoding types for NTP keys.

  Note	We recommend using AES128CMAC due to its higher security.

• When adding NTP keys in Nexus Dashboard, you must tag them as trusted; untrusted keys will fail authentication.

  This option allows you to easily disable a specific key in Nexus Dashboard if the key becomes compromised.

• You can choose to tag some NTP servers as preferred in Nexus Dashboard.

  NTP clients can estimate the "quality" of an NTP server over time by taking into account RTT, time response variance, and other variables. Preferred servers will have higher priority when choosing a primary server.

• If you are using an NTP server running ntpd, we recommend version 4.2.8p12 at a minimum.

• The following restrictions apply to all NTP keys:

  • The maximum key length for SHA1 and MD5 keys is 40 characters, while the maximum length for AES128 keys is 32 characters.

  • Keys that are shorter than 20 characters can contain any ASCII character excluding '#' and spaces. Keys that are over 20 characters in length must be in hexadecimal format.

  • Keys IDs must be in the 1-65535 range.

  • If you configure keys for any one NTP server, you must also configure the keys for all other servers.

Enabling and configuring NTP authentication is described as part of the deployment steps in the later sections.

IPv4 and IPv6 support

Nexus Dashboard supports pure IPv4, pure IPv6, or dual stack IPv4/IPv6 configurations for the cluster nodes and services.

When defining an IP address configuration, the following guidelines apply:

• All nodes and networks in the cluster must have a uniform IP configuration, either pure IPv4, pure IPv6, or dual stack IPv4/IPv6.

• If you deploy the cluster in pure IPv4 mode and want to switch to dual stack IPv4/IPv6 or pure IPv6, you must redeploy the cluster.

• For dual stack configurations:

  • The data, management, app, and service networks must be in dual stack mode.

    Mixed configurations, such as IPv4 data network and dual stack management network, are not supported.

  • For IPv6-based Nexus Dashboard deployments, the CIMCs of all physical servers must also have IPv6 addresses.

  • You can configure either IPv4 or IPv6 addresses for the nodes' management network during initial node bring up, but you must provide both types of IP addresses during the cluster bootstrap workflow.

    Management IP addresses are used to log in to the nodes for the first time to initiate cluster bootstrap process.

  • Kubernetes internal core services will start in IPv4 mode.

  • DNS will serve and forward both IPv4 and IPv6 requests.

  • VXLAN overlay for peer connectivity will use data network's IPv4 addresses.

    Both IPv4 and IPv6 packets are encapsulated within the VXLAN's IPv4 packets.

  • The GUI will be accessible on both IPv4 and IPv6 management network addresses, provided both are configured.

• For pure IPv6 configurations:

  • Pure IPv6 mode is supported for physical and virtual form factors only.

    Clusters deployed through the vND deployment process on AWS public cloud do not support pure IPv6 or dual stack mode.

  • You must provide IPv6 management network addresses when initially configuring the nodes.

    After the nodes are up, these IP addresses are used to log in to the GUI and continue cluster bootstrap process.

  • You must provide IPv6 CIDRs for the internal app and service networks described above.

  • You must provide IPv6 addresses and gateways for the data and management networks described above.

  • All internal services will start in IPv6 mode.

  • VXLAN overlay for peer connectivity will use data network's IPv6 addresses.

    IPv6 packets are encapsulated within the VXLAN's IPv6 packets.

  • All internal services will use IPv6 addresses.

  • IPv6 addresses are required for physical servers' CIMCs.

Necessary URLs for certain connections

There are certain URLs that Nexus Dashboard must reach that are necessary for these connections:

• Cisco Intersight: Connecting your Nexus Dashboard cluster to Cisco Intersight has these benefits:

  • Automatic meta data updates that certain features can use to provide updated data

  • TAC log collection and uploads

• Connecting to Smart Licensing

• Pulling energy management stats from electricity maps

These are the URLs that Nexus Dashboard must reach for these connections and why:

These network prerequisites apply for LAN deployments:

• All new Nexus Dashboard deployments must have the management network and data network in different subnets.

• Interfaces on both data and management networks can be either Layer 2 or Layer 3 adjacent. For data network Layer 3 adjacency, you must configure BGP during the bootstrap process. Management network interfaces do not support the BGP protocol. If different Nexus Dashboard nodes are deployed with management addresses in different subnets, those will simply be routed to one other.

• You must use persistent data IP addresses to bring up the cluster, so you must allocate a certain number of persistent IP addresses depending on your configuration.

  • If your cluster has 1 node, allocate 3 persistent IP addresses.

  • If your cluster has 3 or more nodes, allocate 5 persistent IP addresses.

  • If you configure dual stack IPv4 and IPv6, then add the same number of persistent IP addresses for IPv6 (in other words, 5 IPv4 and 5 IPv6 persistent IP addresses if you configure dual stack).

  For more information about persistent IP addresses, see Nexus Dashboard persistent IP addresses. You must allocate the minimum required persistent IP addresses during the bootstrap process. You can allocate additional persistent IP addresses after the cluster is deployed using the External Service Pools configuration in the GUI.

• The pod profile policy is dynamically configured based on the number of nodes that you deploy.

Nexus Dashboard uses TLS or mTLS with encryption to protect data privacy and integrity while in transit.

This table lists the management network communication ports for LAN deployments, where in the Direction column:

• In means toward the cluster

• Out means from the cluster toward the fabric or outside world

This table lists the data network communication ports for LAN deployments, where in the Direction column:

• In means toward the cluster

• Out means from the cluster toward the fabric or outside world

These network prerequisites apply for SAN deployments:

• You can deploy SAN fabrics in Nexus Dashboard using the same subnets for the data network.

• Interfaces on both data and management networks can be either Layer 2 or Layer 3 adjacent. For data network Layer 3 adjacency, you must configure BGP during the bootstrap process. BGP does not support management network Layer 3 adjacency.

• You must allocate some number of persistent IP addresses depending on your configuration.

  • If your cluster has 1 node, allocate 2 persistent IP addresses. If you will use SAN Insights, allocate a total of 3 persistent IP addresses.

  • If your cluster has 3 nodes, allocate 2 persistent IP addresses. If you will use SAN Insights, allocate a total of 5 persistent IP addresses.

  For more information about persistent IP addresses, see Nexus Dashboard persistent IP addresses. You must allocate the minimum required persistent IP addresses during the bootstrap process. You can allocate additional persistent IP addresses after the cluster is deployed using the External Service Pools configuration in the GUI.

  The management interfaces must be in the same subnet.

Nexus Dashboard uses TLS or mTLS with encryption to protect data privacy and integrity while in transit.

This table lists the management network communication ports for SAN deployments.

This table lists the data network communication ports for SAN deployments.

This table lists the ports that the Nexus Dashboard SAN deployments on single-node clusters require.

Persistent IP addresses, also known as external service IP addresses, are IP addresses that are used for various controller and telemetry functions within the Nexus Dashboard cluster. The word “persistent” is used because while the service may move between different Nexus Dashboard nodes in the event of a node or pod failure, the IP address for the service being referred by the switches in the fabric is preserved. This ensures that no configuration updates to the switches are needed in case of a Nexus Dashboard-related failure event. Persistent IP addresses can be programmed in both the management and data subnets depending on the features deployed.

Persistent IP address updates in release 4.1.1

This section provides information on the changes in Nexus Dashboard release 4.1.1 for the persistent IP addresses. It also explains how to make certain updates in the number of persistent IP addresses before proceeding to upgrade to Nexus Dashboard release 4.1.1.

• Reduction of number of IP addresses needed

  Starting with release 4.1.1, some services that needed exclusive IP addresses in previous Nexus Dashboard releases were merged with others. For example, on a per Nexus Dashboard node basis, software telemetry, flow telemetry and IPFM telemetry collectors on the data network have been merged in such a way that one IP address per collector service is sufficient to serve all three functions.

• LAN Device Connectivity

  You can set the type of LAN device connectivity (Data or Management) under Admin > System Settings > Fabric management > Advanced settings > Admin > LAN Device Management Connectivity.

  Prior to release 4.1.1, the default setting for LAN Device connectivity was Management. Beginning with release 4.1.1, this default has been changed to Data. However, when upgrading from Nexus Dashboard release 3.2.x to 4.1.1, any user-configured setting for LAN device connectivity is preserved.

• Layer-3 Persistent IP Support for Telemetry

  Starting with Nexus Dashboard release 4.1.1, telemetry-collector-X persistent IPs are supported in layer-3 adjacent Nexus Dashboard clusters. See below for Layer 3 BGP deployment details.

The number of persistent IP addresses and how they are mapped to services has changed in Nexus Dashboard release 4.1.1. The following services consume persistent IP addresses on Nexus Dashboard:

• Telemetry collector-x: There is a requirement for 1 persistent IP address for a 1-node cluster, or 3 persistent IP addresses for a 3-node or larger cluster, on the data network.

• SNMP trap and syslog receiver: 1 persistent IP address on the data network if the LAN device connectivity type is set to Data or 1 persistent IP address on the management network if the LAN device connectivity type is set to Management.

• Switch bootstrap service (POAP/PnP): 1 persistent IP address on the data network if the LAN device connectivity type is set to Data or 1 persistent IP address on the management network if the LAN device connectivity type is set to Management.

• (Optional) Endpoint Locator (EPL): 1 persistent IP address on the data network for each fabric where EPL is enabled. The EPL feature can be enabled for up to 4 fabrics in a given Nexus Dashboard cluster.

• (Optional) IPFM (IP Fabric for Media) telemetry collector-x: If LAN device connectivity is set to Data, then no additional persistent IPs are required. However if LAN device connectivity type is set to Management, there is a requirement for 1 persistent IP address for a 1-node cluster, or 3 persistent IP addresses for a 3-node or larger cluster, on the management network.

For an IPv4-only Nexus Dashboard cluster deployment, each service listed above will consume 1 persistent IPv4 address. For a pure IPv6-only Nexus Dashboard cluster deployment, each service will consume 1 persistent IPv6 address. For a dual-stack Nexus Dashboard cluster deployment, each service needing a persistent IP will consume an IPv4 address and an IPv6 address.

Fresh installation or upgrade

The total number of persistent IP addresses that you will need won't necessarily change based on whether you are performing a fresh installation or an upgrade. In addition, for a fresh installation of Nexus Dashboard (greenfield deployment), you must configure persistent IP addresses only on the data network. You can change the LAN device connectivity type from Data to Management after the cluster installation is complete.

As mentioned earlier, there is a change in the default setting in Nexus Dashboard 4.1.1 compared to previous Nexus Dashboard releases. In Nexus Dashboard 4.1.1, the default LAN Device Management Connectivity is set to Data, while in earlier releases it was set to Management. As part of the effort towards delivering the unified Nexus Dashboard, the goal is to make the recommended best practice deployment as easy as possible. The reachability from Nexus Dashboard to and from switches is recommended to be over the Nexus Dashboard data interface. The Nexus Dashboard management interface should primarily be used for UI/API access and reachability for AAA, DNS, Proxy, NTP, Intersight, and so on. Finally, note that the connectivity setting set by the user is preserved when doing an inline upgrade from Nexus Dashboard release 3.2.x to Nexus Dashboard release 4.1.1.

Additional considerations to keep in mind

Along with the factors listed above, there are several additional considerations that you should keep in mind regarding persistent IP addresses:

• Nexus Dashboard deployment mode:

  • Layer 2: Here the Nexus Dashboard nodes within the cluster are layer-2 adjacent. This means that all Nexus Dashboard nodes share the same management and data subnet respectively. Persistent IP addresses need to be on the same network as the data network or management network.

  • Layer 3 BGP: In this mode, the Nexus Dashboard nodes within the cluster are layer-3 adjacent. In other words, unique management and data subnets are associated with each Nexus Dashboard node in the cluster. There needs to be IP reachability between the nodes to form the cluster. Persistent IP addresses cannot be from a subnet that belongs to any of the Nexus Dashboard nodes’ Data or Management interface subnets. In this case, LAN Device Management Connectivity must be set to Data and cannot be changed.

Determining the total number of persistent IP addresses that you will need

All the factors listed above come into play when you are trying to determine the total number of persistent IP addresses that you will need and which network they come from. Make sure you review you final Nexus Dashboard deployment configuration to verify that you have enough persistent IP addresses in the proper subnet range for your deployment, and that you have additional persistent IP addresses if necessary, depending on the type of LAN device connectivity that you set and for services that you might enable, such as Endpoint Locator (EPL).

Following is an example scenario that demonstrates how persistent IP addresses are used:

Fresh installation:

First, at cluster bringup, you will need a certain number of persistent IP addresses on the data network, based on the cluster size, as mentioned earlier:

• 1-node cluster, with physical or virtual nodes: Minimum of 3 persistent IP addresses needed on the data network

• 3-node or larger cluster, with physical or virtual nodes: Minimum of 5 persistent IP addresses needed on the data network

After bootstrapping, you may need to add additional persistent IP addresses as needed, depending on these scenarios:

• If you leave the LAN device connectivity type set to Data, you won't need any additional persistent IP addresses unless you enable the Endpoint Locator (EPL) feature, which requires 1 additional persistent IP address on the data network per fabric where EPL is enabled.

• If you change the LAN device connectivity type from Data to Management:

  • You will need 2 additional persistent IP addresses on the management network for Syslog/SNMP trap and switch bootstrap functionality.

  • (Optional) If you want to enable Endpoint Locator (EPL), you will need 1 persistent IP address on the data network per fabric where EPL is enabled.

  • (Optional) If you want IP Fabric for Media (IPFM) fabrics, you will need 1 persistent IP address for a 1-node cluster, or 3 persistent IP addresses for a 3-node or larger cluster, on the management network.

Upgrade:

Now assume that you want to upgrade from Nexus Dashboard 3.2.x to 4.1.1. The number of persistent IP addresses that you will need in Nexus Dashboard 4.1.1 will vary, depending on the services that you were running and how they were configured on Nexus Dashboard 3.2.x, and the size of your cluster in Nexus Dashboard 4.1.1. Note that the LAN Device Management Connectivity that you set in the Nexus Dashboard 3.2.x release is preserved as-is when performing an inline upgrade to the Nexus Dashboard 4.1.1 release.

• If you had only NDFC running in your Nexus Dashboard 3.2.x system, and

  • If you had Data set as the type of LAN device connectivity in Nexus Dashboard 3.2.x, and

    • You have a 1-node cluster that you want to upgrade to Nexus Dashboard 4.1.1, then you'll need 3 persistent IP addresses on the data network.

    • You have a 3-node or larger cluster that you want to upgrade to Nexus Dashboard 4.1.1, then you'll need 5 persistent IP addresses on the data network.

  • If you had Management set as the type of LAN device connectivity in Nexus Dashboard 3.2.x, and

    • You have a 1-node cluster that you want to upgrade to in Nexus Dashboard 4.1.1, then you would already have either 2 or 3 persistent IP addresses (additional IP is required if IPFM/PTP feature was enabled) in the management network. In addition, you will need 1 persistent IP address in the data network, otherwise the upgrade to 4.1.1 will fail during the pre-upgrade validation step.

    • You have a 3-node or larger cluster that you want to upgrade to in Nexus Dashboard 4.1.1, then you would already have either 2 or 5 persistent IP addresses (3 additional IPs are required if IPFM/PTP feature was enabled) in the management network. You will need to configure 3 persistent IP addresses in the data network; only then will the upgrade to 4.1.1 proceed.

• If you had only NDI running in your Nexus Dashboard 3.2.x system, and

  • You have a 1-node cluster that you want to upgrade to Nexus Dashboard 4.1.1, then you would already have configured 4 persistent IP addresses in the data network. After the upgrade to 4.1.1, only 3 persistent IP addresses will be in use. The remaining can be reclaimed.

  • You have a 3-node or larger cluster that you want to upgrade to Nexus Dashboard 4.1.1, then you would already have configured 8 persistent IP addresses in the data network and 2 additional data IPs for support of standalone NX-OS deployments. After the upgrade to 4.1.1, only 5 of these data IP addresses will be in use. The remaining can be reclaimed.

• If you had only NDO running in your Nexus Dashboard 3.2.x system, then you did not have any persistent IP addresses in your Nexus Dashboard 3.2.x system. When you upgrade to Nexus Dashboard 4.1.1, if you have a 3-node cluster that you want to upgrade to Nexus Dashboard 4.1.1, then you'll need 5 persistent IP addresses on the data network before the upgrade can proceed.

• If you had an NDO and NDI deployment mode in your Nexus Dashboard 3.2.x system, and you have a 3-node or larger cluster that you want to upgrade to Nexus Dashboard 4.1.1, then you would already have configured 8 persistent IP addresses in the data network. After the upgrade to 4.1.1, only 5 of these data persistent IP addresses will be in use. The remaining persistent IP addresses can be reclaimed.

• If you had only NDFC and NDI deployment mode in your Nexus Dashboard 3.2.x system, and you have a 3-node or larger physical ND cluster that you want to upgrade to Nexus Dashboard 4.1.1, then there were two options based on the LAN Device Management Connectivity setting:

  • If you had Management set as the type of LAN device connectivity in Nexus Dashboard 3.2.x, you would already have configured 8 persistent IP addresses in the data network for NDI and 2 persistent IP addresses in the management network for NDFC. After the upgrade to 4.1.1, the 2 persistent IP addresses in the management subnet will be used along with only 3 of the data persistent IP addresses. The remaining persistent IP addresses can be reclaimed.

  • If you had Data set as the type of LAN device connectivity in Nexus Dashboard 3.2.x, you would already have configured 8 persistent IP addresses in the data network for NDI and 2 additional data persistent IP addresses for NDFC. After the upgrade to 4.1.1, only 5 of these data persistent IP addresses will be in use. The remaining persistent IP addresses can be reclaimed.

Note	EPL persistent IP address requirements remain the same in release 4.1.1 as they were in release 3.2.x.

Connectivity between the nodes is required on both networks with additional round trip time (RTT) requirements, as listed in this table.

These sections describe how to connect your Nexus Dashboard cluster nodes to the management and data networks and how to connect the cluster to your fabrics. For more information on configuring the fabric to enable the in-band telemetry functions, see the following documents:

• Getting Your Cisco ACI Fabrics Ready for Cisco Nexus Dashboard Insights

• Getting NDFC Network Sites Ready for Nexus Dashboard Insights

For on-premises APIC or NX-OS fabrics, you can connect the Nexus Dashboard cluster in one of these ways:

• The Nexus Dashboard cluster connected to the fabric using a Layer 3 network.

• The Nexus Dashboard nodes connected to the leaf switches as typical hosts.

Connecting using an external Layer 3 network

We recommend connecting the Nexus Dashboard cluster to the fabrics using an external Layer 3 network as it does not tie the cluster to any one fabric and the same communication paths can be establish to all fabrics. Specific connectivity depends on the type of applications deployed in the Nexus Dashboard:

• If you are using orchestration to manage Cisco ACI fabrics, you can establish connectivity from either the data interface or the management interface to either the in-band or out-of-band (OOB) interface of each fabric's APIC or both.

  If the fabric connectivity is from the Nexus Dashboard's management interface, you must configure specific static routes or ensure that the management interface is part of the same IP subnet of the APIC interfaces.

• If you are using telemetry, you must establish connectivity from the data interface to the in-band network of each fabric and of the APIC.

If you plan to connect the cluster across a Layer 3 network, keep the following in mind:

• For ACI fabrics, you must configure an L3Out and the external EPG for Cisco Nexus Dashboard data network connectivity in the management tenant.

  Configuring external connectivity in an ACI fabric is described in the Cisco APIC Layer 3 Networking Configuration Guide.

• If you specify a VLAN ID for your data interface during setup of the cluster, the host port must be configured as trunk allowing that VLAN.

  However, in most common deployments, you can leave the VLAN ID empty and configure the host port in access mode.

The following two figures show two distinct network connectivity scenarios when connecting the Nexus Dashboard cluster to the fabrics using a Layer 3 network, where the first figure shows a mix of ACI and NX-OS fabrics, and the second figure shows only ACI fabrics.

Connecting nodes directly to leaf switches

You can also connect the Nexus Dashboard cluster directly to one of the fabrics. This provides easy connectivity between the cluster and in-band management of the fabric, but ties the cluster to the specific fabric and requires reachability to other fabrics to be established through external connectivity. This also makes the cluster dependent on the specific fabric so issues within the fabric may impact Nexus Dashboard connectivity. Like in the previous example, connectivity depends on the type of applications deployed in the Nexus Dashboard:

• If you are using orchestration to manage Cisco ACI fabrics, you can establish connectivity from either the data interface or the management interface to either the in-band or out-of-band (OOB) interface of each fabric's APIC or both.

  If the fabric connectivity is from the Nexus Dashboard's management interface, you must configure specific static routes or ensure that the management interface is part of the same IP subnet of the APIC interfaces.

• If you are using telemetry, you can establish connectivity from the data interface to the in-band or out-of-band (OOB) interface of each fabric. However, you must add the route if you establish connectivity from the data interface to the out-of-band interface.

  For ACI fabrics, the data interface IP subnet connects to an EPG/ or bridge domain in the fabric and must have a contract established to the local in-band EPG in the management tenant. We recommend deploying the Nexus Dashboard in the management tenant and in-band VRF. Connectivity to other fabrics is established using an L3Out.

If you plan to connect the cluster directly to the leaf switches, keep the following in mind:

• If deploying in VMware ESX or Linux KVM, the host must be connected to the fabric using trunk port.

• If you specify a VLAN ID for your data network during setup of the cluster, the Nexus Dashboard interface and the port on the connected network device must be configured as trunk.

  However, in most cases we recommend not assigning a VLAN to the data network, in which case you must configure the ports in access mode.

• For configurations on the APIC side, following are recommended configurations:

  • We recommend configuring the bridge domain, subnet, and endpoint group (EPG) for Cisco Nexus Dashboard connectivity in management tenant.

    Because the Nexus Dashboard requires connectivity to the in-band EPG in the in-band VRF, creating the EPG in the management tenant means no route leaking is required.

  • You must create a contract between the fabric's in-band management EPG and Cisco Nexus Dashboard EPG.

  • If several fabrics are monitored with apps on the Nexus Dashboard cluster, L3Out with default route or specific route to other ACI fabric in-band EPG must be provisioned and a contract must be established between the cluster EPG and the L3Out's external EPG.

The following figures show two distinct network connectivity scenarios when connecting the Nexus Dashboard cluster directly to the fabrics' leaf switches. The primary purpose of each depends on the type of application you may be running in your Nexus Dashboard.

The following graphics show these types of connections:

• Connecting directly to ACI fabric

• Connecting directly to NX-OS fabric

• Connecting directly to ACI and NX-OS fabrics