Cisco Multi-Site Orchestrator (MSO) and DCNM integration enables you to perform Layer-2 or Layer-3 extension of overlay Networks or VRFs between multiple VXLAN-EVPN fabrics that are managed by different DCNM controllers. This compliments the Multi-Site Domain (MSD) functionality already present in DCNM that supports VXLAN EVPN Multi-Site capability between multiple fabrics that are part of a single DCNM controller.

You can onboard all of your DCNM fabrics into the Nexus Dashboard (ND) by providing login credentials for the DCNM controllers that manage them all in a single, centralized location. Once onboarded, the ND makes these fabrics automatically available to MSO as individual sites. The appropriate sites can be converted from unmanaged to managed in the MSO, followed by setting up of the baseline infrastructure connectivity between the sites for VXLAN EVPN Multi-Site underlay/overlay EVPN peering. Subsequently, overlay networks/vrfs can then be provisioned and managed from the MSO for all the managed sites thereby offering a single point of management/provisioning.

Overall, Cisco DCNM and MSO integration enable you to manage VXLAN EVPN-based NX-OS fabrics as well as the fabrics that are already part of a DCNM Multi-Site domain (MSD), establish connectivity across fabrics, configure overlay Layer-2/Layer-3 stretch within and between sites, and scale out existing DCNM deployments.

For more information refer to Cisco Multi-Site Orchestrator Release Notes, Release 3.2(1).

Cisco Nexus Dashboard (ND) provides a common platform for deploying Cisco Data Center applications. Nexus Dashboard supports the Cisco Day-2 Operations apps, which provide real-time analytics, visibility, and assurance for policy and infrastructure, and the Cisco Multi-Site Orchestrator (MSO) application, which provides a single pane of glass view into managing multiple Cisco DCNM fabrics. ND supports onboarding of Cisco DCNM and APIC sites. Site onboarding entails providing the DCNM hostname or IP address followed by the admin level access credentials. Using this information, ND pulls all the existing fabrics from that DCNM and allows the user to onboard one or more fabrics onto the ND. Each (DCNM, fabric) combination maps to a unique ND Site. All onboarded sites on the ND are made available to all applications that run on top of ND such as MSO.

When ND nodes are deployed for MSO/DCNM environments, the ND computes in a given ND cluster must all be layer-2 adjacent. In other words, the management interface of all nodes must be in one IP subnet and the data interface in a different IP subnet.

For more information, refer to Cisco Nexus Dashboard Release Notes, Release 2.0.1.

DCNM now supports configuration provisioning of N overlay networks to M interfaces with a single click. One can select multiple host-facing interfaces and associate them with an Interface Group (IG). Specifically, you can create an interface group for physical Ethernet interfaces, Layer-2 port-channels, or vPCs. You can then associate multiple overlay networks with this IG that in turn automatically attaches those overlay networks to all the interfaces that are part of the IG. Subsequently, any membership change of interfaces to IGs or networks to IGs results in automatic percolation of the appropriate overlay network attachment/detachment state automatically to the respective interfaces. IGs have fabric local scope.

From Cisco DCNM Release 11.5(1), two new RBAC roles device-upg-admin and access-admin roles are introduced. A user with role device-upg-admin will only be allowed to perform device upgrade/downgrade, RPM/SMU installation, and EPLD upgrade. The user won’t be able to perform any other write operations on the DCNM or the switches. A user with role access-admin will only be able to make configuration changes to host or server-facing ports typically tied to the Interface Manager workflows. They won’t be able to make any changes to the underlay or within the fabric builder.

You can now sync-up interface configurations from the switches back up to the DCNM so that the intent in DCNM is appropriately updated. This feature is supported for Easy Fabrics, and External or LAN_Classic fabrics. The interface sync up knob can be enabled on a per switch basis. vPC pairs are detected and the corresponding vPC domain configuration is automatically learned. You can use the host_port_resync policy for this purpose.

You can use the CloudSec Operational View tab in DCNM to check the operational status of the CloudSec sessions if CloudSec is enabled on the MSD fabric.

MACsec is supported in the Easy Fabric and eBGP Fabric on intra-fabric links. You need to enable MACsec on the fabric and on each required intra-fabric link to configure MACsec. There is also an operational view enabled for MACsec.

From Release 11.5(1), Cisco DCNM allows you to import or discover switches with inband connectivity for External and LAN Classic fabrics. To enable this functionality, select Inband Mgmt check box on Fabric Settings. When this knob is enabled, the fabric supports switch discovery/import over the DCNM inband interface (eth2), in addition to the switches that can be discovered or onboarded via their mgmt0 interfaces. Note that inband POAP is not supported.

You can restore configuration for a Cisco Nexus switch in external and LAN classic fabrics from the Cisco DCNM Web UI. The information you restore at switch-level is extracted from the fabric-level backups. The switch-level restoration does not restore fabric-level intents and other configurations applied using the fabric settings. Only switch-level intents are restored.

From Cisco DCNM Release 11.5(1), DCNM supports EPLD golden upgrade as well. When you perform the EPLD upgrade, you have an option to choose the golden or primary region of the Nexus 9000 Series switches. You can view the EPLD golden upgrade notifications in the Events window. From the homepage of the Cisco DCNM Web UI, choose Monitor > Switch > Events.

The following enhancements are introduced in DCNM Release 11.5(1):

• You can specify an arbitrary network, that has not been defined in the top-down configuration, as a source or destination network in the service policy. This helps in streamlining policy enforcement for north-south traffic.

• Layer 4-Layer 7 Service pushes static routes on all VTEPs, including service leaf switches, where the VRF being referenced in the static route is attached. This expedites service node failover with static routes.

• The one-arm Virtual Network Function is supported.

• Layer 4-Layer 7 Service REST APIs are accessible via DCNM packaged REST API Swagger documentation.

• Bulk attachment, detachment, preview, and deployment of route peering and service policies is supported and they are limited up to 10 route peerings or 10 service policies only.

• Audit History feature displays the logs for changes made to service nodes, route peering, and service policies.

The Brownfield import in DCNM supports the simplified NX-OS VXLAN EVPN configuration CLIs.

OpenStack plugin application is provided by DCNM that helps you to monitor OpenStack Clusters. You can get visibility with respect to the physical network connectivity and virtualized workloads, and debug VM networking-specific issues within the context of the data center.

This is a preview feature in Cisco DCNM Release 11.5(1). We recommend that you do not deploy this feature in production environments.

The Precision Time Protocol (PTP) is a time synchronization protocol for nodes that are distributed across the network. On a local area network, it achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. In DCNM, PTP Monitoring can be installed as an application. This PTP monitoring application, which can be previously installed in Media Controller deployment can now be installed in LAN Fabric deployment as a preview feature. We recommend that you do not deploy this feature in production environments.

Cisco DCNM allows you to modify few network parameters from the Web UI. Modifying these overwrite the previously configured parameters. Choose Cisco DCNM Web UI > Admin > DCNM Server > Customization > Network Preferences to modify the DNS, NTP, and addition or removal of static routes over the out-of-band (eth1) and inband (eth2) interfaces.

You can trigger scheduled DCNM backups from the Cisco DCNM Web UI. Based on the schedule that has been set up, at the appropriate time, the appropriate DCNM backup will be triggered. This is supported on both Cisco DCNM Standalone and Native HA deployments. The history and status of the triggered backups is available on the GUI. Backups can be scheduled for local as well as remote destinations. The maximum number of backups you can save is 10.

Multicast NAT translation of UDP stream is supported on the DCNM IPFM mode. You can apply NAT for the incoming traffic (ingress), or on the egress link or interface. The scope of ingress NAT is entire switch, whereas egress NAT is for a specific interface. The same switch can have both ingress and egress NAT. However, it can’t be on the same flow for a given switch.

You can configure an interface to allot a dedicated percentage of bandwidth to unicast traffic. The remaining percentage is automatically reserved for multicast traffic.

When you launch Cisco DCNM SAN and SAN OVA/ISO deployment, the Summary Dashboard is displayed. The intent of the Summary dashboard is to enable network and storage administrators to focus on particular areas of concern around the health and performance of data center switching.

You can add offline members to device alias zone for SAN and IVR zoning.

You can rename individual members or all members in the enclosures at a single instance. Choose Dashboard on Cisco DCNM Web UI, to rename Storage and Host Enclosures.

Three new dashlets, namely, Top FICON Host Ports, Top FICON Control Unit Ports, and Top FCIP ISL are introduced in Release 11.5(1).

• For SAN OVA/ISO deployments

  • DCNM on VM supports 40K ITLs/ITNs.

  • DCNM on Cisco Nexus Dashboard supports 60K ITLs/ITNs.

• For SAN Linux deployment, DCNM supports 20K ITLs/ITNs.

Software Maintenance Update to address Log4j2 vulnerability

Cisco DCNM Release 11.5(1) provides Software Maintenance Update (SMU) to address CVE‐2021‐45046 and CVE‐2021‐44228 issue. Note that CVE-2021-45105 has a lower severity and not used in DCNM with default configuration, therefore it is not addressed here.

For more information, refer to Installing Software Maintenance Update for log4j2 Vulnerability chapter in Cisco DCNM Installation Guide for your deployment type.

From Release 11.5(1), Cisco DCNM provides an appmgr command to set up authentication via TACACS+ server for all ssh access as well. Note that DCNM GUI has always supported remote authentication via TACACS+, LDAP, and RADIUS. Once the appmgr related configuration has been set up, any ssh access to the DCNM first will be redirected to the configured TACACS+ server to determine if access is allowed. In case of success, access is granted. When the TACACS+ servers are not reachable, the system reverts to local authentication.

Along with IPv4 firewalls, DCNM now supports IPv6 firewalls.