As you might remember from our last post within our DCNM 11 series, we discussed provisioning underlay for VXLAN EVPN fabric using fabric builder in DCNM 11. Today, we’re continuing the discussion by featuring how Cisco’s Data Center Network Manager (DCNM) empowers IT to move at the increasing speed businesses require, giving IT departments complete automation, extensive visibility, and consistent operations for their data center. DCNM is the network management platform for all NX-OS-enabled deployments, spanning new fabric architectures, IP Fabric for Media, and storage networking deployments for the Cisco Nexus-powered data center.
Why DCNM 11?
With its advanced features, Cisco’s DCNM 11 supports the management of interfaces individually at a per device level, a fabric level, or a data center level. This is done either via the GUI or equivalent REST APIs. While many tools provide just about every possible permutation for interface configuration, DCNM 11 comes with best practice interface policy templates that will serve the most common deployment scenarios. For more sophisticated use-cases, the interface policy templates within DCNM can be easily customized to meet the user’s specific needs. In addition, the following interface-related operations are also available:
- Create/Edit/Delete of logical interfaces like vPCs, Port-Channels, Loopbacks, Sub-interfaces
- Attach Networks and VRFs to interfaces using one click
- Configuration Straight-Through (ST) and Active-Active (AA) FEX
- Interface operations like admin down/up and show commands using templates
- Configuration of Routed, Access, Trunk Interfaces
- View history for each interface – who did what, when at an interface level
- Check compliance status for every interface
- Configuration of breakout interfaces
- Interface statistics on per interface or per link basis
- Per Interface neighbor discovery using LLDP/CDP
How it works
Interface of Switches discovered by DCNM can be seen by navigating to Control -> Fabrics -> Interfaces. The scope selector allows you to filter the list of interfaces at a Data Center level or at a per fabric level. Various filtering options are available, including the ability to modify interface configuration in bulk. The global interface view provides a combination of information that is configured via the DCNM as well as operational information based run time state.
![](https://storage.googleapis.com/blogs-images/ciscoblogs/1/5d309a13bb8e0.png)
![](https://storage.googleapis.com/blogs-images/ciscoblogs/1/5d309a41d92ca.png)
Per switch level interface management can be done via Fabric Builder with a simple right click sub-menu selection.
![](https://storage.googleapis.com/blogs-images/ciscoblogs/1/5d309a6786a4f.png)
Typically, there are two types of interfaces: network interfaces that represent a inter-switch link or ISL, and host facing interfaces that are typically attached to end points (servers, appliances etc.). An ISL or a link may be further classified as a intra-fabric or inter-fabric link. Intra-fabric links are between devices that are part of the same fabric, while inter-fabric links are typically used for external connectivity out of a fabric. DCNM allows users to pre-provision inter and intra fabric physical and logical links using link policy templates. A link policy template in turn references child interface policy templates, one each for either end of the link.
DCNM then gathers and populates interface level statistics in the health dashboard. Interface and per link statistics – including transmit/receive byte/packet counters, error counters, and more – are available for archival and perusal. Daily or weekly reports may also be generated for interface statistics.
![](https://storage.googleapis.com/blogs-images/ciscoblogs/1/5d309a91cd980.png)
![](https://storage.googleapis.com/blogs-images/ciscoblogs/1/5d309ae4da6e1.png)
![](https://storage.googleapis.com/blogs-images/ciscoblogs/1/5d309b1302728.png)
Interface or link up/down events result in trap notifications that in turn can be used to trigger alarms based on user configured policies. In general, for brownfield deployments, DCNM always preserves the switch and corresponding interface level configuration. DCNM learns the configuration of not only the physical but also the logical interfaces that are present on the switch. Resources such as port-channel IDs, loopback IDs, ip addresses, etc. are also marked as used in the DCNM resource manager. Subsequently, existing interfaces can be edited or new interfaces can be incrementally provisioned via the DCNM for continuous operation.
DCNM features configuration compliance that keeps track of the expected-config/intent defined by the user and the running configuration on the switches at all times. Any drift from the interface intent, including changes made out-of-band, marks the interface, and hence the switch, as ‘OUT-OF-SYNC’. Remediation is suggested by generating a set of pending configuration that will mutate the current running configuration to the current expected configuration (intent) on execution. This brings the interface, and hence the switch, back ‘IN-SYNC’. DCNM’s own resource manager keeps track of all interface configurations, and mutations are backed up at all times for a future rollback.
![](https://storage.googleapis.com/blogs-images/ciscoblogs/1/5d309dda8d0eb.png)
great writeup on the DCNM interface capabilities…
Great interface thank you very much !