IP Encyclopedia > MD-CLI

What Is MD-CLI?

The Model-Driven Command Line Interface (MD-CLI) is a YANG-based CLI that is oriented to machine-machine and human-machine interaction. Compared with the traditional CLI, the MD-CLI features simple configuration logic, easy machine parsing, and low learning cost.

Contents

What Are CLI and MD-CLI?

CLI: A Tool for Interaction with Devices

The command line interface (CLI) is a common tool for users to interact with devices. It is widely used in scenarios such as new service provisioning and routine O&M. After the system displays the command line prompt for a login user, it indicates that the user has entered the CLI. The system provides a series of commands for users to interact with the device. The CLI is similar to the graphical user interface (GUI) in the Windows operating system, except that the CLI is in text format, while the GUI is in visual format. Currently, network devices support two types of CLIs: traditional CLI and MD-CLI.

MD-CLI: A YANG-based CLI

Because traditional CLIs use different data models, similar functions on different devices require different command lines to be used. The core concept of MD-CLI is to use a YANG model as the data modeling language. The MD-CLI provides a method for users to access YANG model nodes through directories. After learning the node hierarchy in the YANG model, users can automatically deduce the corresponding MD-CLI operation command lines, and vice versa.

Why Do We Need MD-CLI?

As networks develop rapidly, the number of network devices increases exponentially. At the same time, more and more device vendors and network device types emerge, increasing the complexity involved in network management. In the cloud-based network era, network devices are undergoing significant transformation in terms of management and O&M, that is, from human-machine management of a single NE to automatic machine-machine management of the entire network. As a typical human-machine interface, the traditional CLI is mainly used for interaction between people and devices. Before Simple Network Management Protocol (SNMP) emerged, traditional CLI scripting was the main method for automatic network management. However, the traditional CLI lacks unified command languages and employs the unstructured output mode, making CLI script maintenance difficult and costly. In this context, SNMP — a standard network management protocol — has become widely used on TCP/IP networks. But SNMP-related issues, such as low configuration efficiency and incompatibility with the transaction mechanism, have gradually become prominent. To address these issues, multiple network configuration protocols based on the YANG model have emerged, including Network Configuration Protocol (NETCONF) and Representational State Transfer Configuration Protocol (RESTCONF). With these protocols, users can manage and maintain devices in batches through a controller-based web client or application. In this mode of network device management, the traditional CLI is used for single-device configuration, and the network configuration protocols are used for automatic management. Put differently, the CLI is used as the human-machine interface, and the network configuration protocols are used as the machine-machine interface.

As the network scale increases sharply, both human-machine and machine-machine interfaces are indispensable for network management. Is there a tool that can be used for both human-machine and machine-machine interaction? Yes: MD-CLI is a next-generation interaction mode that features both capabilities. Like NETCONF and RESTCONF, the MD-CLI also uses the YANG model as the data modeling language. The YANG model defines the hierarchical structure of data, enabling machines to effectively identify and parse O&M data. This means that the MD-CLI can also be used in network automation scenarios. As a machine-machine interface, the MD-CLI provides a method for users to access YANG model nodes through directories. It is more readable than network configuration protocols that focus on machine-machine interaction and enables users to manage and maintain devices in batches without using upper-layer applications. And as a human-machine interface, the MD-CLI provides only a few basic operation commands. Users who are familiar with the YANG model can directly use the MD-CLI to perform single-point configuration on the device.

The MD-CLI is a convenient tool for both users and developers. For users, it eliminates the need to learn multiple sets of CLIs for different devices from different vendors — instead, users only need to learn the YANG model. And, more importantly, once users are familiar with the YANG structure, they can flexibly select a suitable YANG-based service interaction mode from multiple such modes if available according to their usage scenario. For developers, the MD-CLI reduces the workload required to develop different CLI models, thereby allowing developers to focus exclusively on YANG development.

YANG-based interaction modes

What Are the Advantages of MD-CLI over Traditional CLI?

Advantage 1: Simplified Configuration Logic

When executing a command, the traditional CLI checks the dependencies between command operation objects. As such, users need to strictly follow the sequence of dependencies between commands during configuration.

Dependency check of the traditional CLI

MD-CLI dependency verification is performed in the commit phase, instead of in the configuration phase. Users only need to ensure that the configuration dependencies meet requirements when committing configurations. During the editing phase/process, users do not need to strictly comply with the dependency logic between services.

Dependency check of the MD-CLI

Advantage 2: Lower Learning Cost

In network management scenarios, users need to learn the traditional CLI to perform single-point configuration on devices as required. To complete the configuration, users usually need to read related manuals to check whether the functions and command forms of different vendors and devices are different. As the network scale increases, they also need to learn the YANG model to implement automatic management. This not only means that beginners need to learn both the traditional CLI and YANG model, but also prolongs the learning process and increases the learning cost.

Requirement resolution with the traditional CLI

If the MD-CLI is used, users focus only on different YANG structures of devices. After learning about the YANG model structure and MD-CLI basic operation commands, users can export MD-CLI operation commands and configure the device. If automatic management is required, the MD-CLI enables users to compile scripts for batch management of multiple devices. Because there is no need to learn the traditional CLI command format or identify the differences between command formats of different vendors, the MD-CLI reduces the learning cost.

Requirement resolution with the MD-CLI

Advantage 3: Good for Machine Parsing

The traditional CLI is mainly used for human-machine interaction and focuses on human readability. It differs significantly from vendor to vendor because there is no unified syntax convention for the CLI. And although the output of the traditional CLI is in plain text so that people can read and understand it, such output cannot be easily parsed by machines. The command output is unstructured, containing tables in some cases but character strings in other cases. In addition, there is no unified standard to parse the command output, unless the output of each command is adapted. However, adapting such output will significantly increase the O&M management cost, and the complexity affects the stability of applications. The following example shows the command output of the traditional CLI displaying statistics about sent and received packets with different lengths on a specified interface.

<HUAWEI> system-view
[HUAWEI] display interface statistics 100ge 1/0/1 verbose
         PacketLength(Bytes)      Send(packets)       Receive(packets)
         1~64                     0                   1 
         65~127                   183703              109222
         128~255                  0                   0
         256~511                  12251               12249
         512~1023                 0                   0
         1024~1518                0                   0
         1519~9216                0                   0

The output of the MD-CLI is in JSON format and complies with the definition and related standards of YANG, facilitating parsing and processing of machines. Structured information can be parsed by automation tools in a unified manner. At the content layer, the YANG model is used, overcoming the lack of a human-machine interface. The following example shows the command output of the MD-CLI displaying the configuration in the candidate database in the current view.

[*(ex)ADMIN@HUAWEI]/ifm/interfaces/interface[name="MEth0/0/0"]
MDCLI> display this candidate
{
  "name": "MEth0/0/0",
  "class": "main-interface",
  "type": "MEth",
  "number": "0/0/0",
  "description": "To deviceB MEth0/0/0",
  "admin-status": "up",
  "link-protocol": "ethernet",
  "router-type": "broadcast",
  "clear-ip-df": false,
  "link-up-down-trap-enable": true,
  "statistic-enable": true,
  "statistic-mode": "interface-based",
  "mtu": 1500,
  "spread-mtu-flag": false,
  "vrf-name": "_public_",
  "l2-mode-enable": false,
  "huawei-ip:ipv4": {
    "addresses": {
      "address": [
        {
          "ip": "10.1.1.255",
          "mask": "255.255.254.0",
  ---- More ----

How Do MD-CLI Commands Map to YANG Nodes?

YANG Model

The MD-CLI commands are generated based on the YANG model supported by a device. The main node types of the YANG model are as follows:

Container node: It is used to group related nodes into a subtree. A container node has only child nodes and no value. It may contain any number and any type of child nodes (including container, leaf, leaf-list, and list nodes).
Leaf node: It contains simple data such as an integer or a character string. A leaf node contains one value for a particular type and no child nodes.
Leaf-list node: It is a set of leaf nodes with exactly one value of a particular type per leaf.
List node: It defines a sequence of list entries. Each entry is similar to a structure or record instance, and is uniquely identified by the values of its key leaf nodes (key values). A list node can define multiple key leaf nodes and may contain any number and any type of child nodes (such as leaf, list, and container nodes).
RPC node: An RPC node can define the operations at the top layer of the model, including the operation name, input parameters, and output parameters.

During MD-CLI configuration, you can check the YANG tree structure supported by a specified path to determine the data hierarchy and facilitate MD-CLI configuration operations. For example, check the YANG tree in the ifm/interfaces/interface directory. In the YANG tree structure, the node names defined in the YANG file are displayed on the left, and the description of the data types of the leaf/leaf-list node is displayed on the right. If a node has a default value, this value is included in angle brackets (<>) following the data type. In this example, the default value of statistic-mode is interface-based.

[ADMIN@HUAWEI]
MDCLI> tree ifm/interfaces/interface
module: huawei-ifm
+--rw ifm
   +--rw interfaces
      +--rw interface* [name]
         +--rw name                                             huawei-pub-type:if-name
         +--rw class?                                           class-type
         +--rw type?                                            port-type
         +--rw parent-name?                                     -> /huawei-ifm:ifm/interfaces/interface/name
         +--rw number?                                          string
         +--rw description?                                     string
         +--rw admin-status?                                    port-status
         +--rw link-protocol?                                   link-protocol
         +--rw router-type?                                     router-type
         +--rw clear-ip-df?                                     boolean <false>
         +--rw link-up-down-trap-enable?                        boolean <true>
         +--rw statistic-enable?                                boolean
         +--rw statistic-mode?                                  statistic-mode <interface-based>
         +--rw (bandwidth-type)?
         |  +--:(bandwidth-mbps)
         |  |  +--rw bandwidth?   uint32
         |  +--:(bandwidth-kbps)
         |     +--rw ban   uint32
         +--rw mtu?                                             uint32
  ---- More ----

Mapping Between MD-CLI Commands and YANG Model Nodes

The following describes the mappings between MD-CLI commands and the container, leaf, leaf-list, list, and RPC nodes of the YANG model.

The container node in the YANG model is mapped to the MD-CLI node view. The name of the container node corresponds to that of the MD-CLI node view. Because a container node is a set of related nodes, it has only child nodes and no value.
Take huawei-arp.yang as an example. In the YANG tree structure, the arp and speed-limits nodes are both container nodes.
```
module: huawei-arp
+--rw arp
   +--rw speed-limits
```
On the MD-CLI, the arp and speed-limits nodes are mapped to node views.
```
[ADMIN@HUAWEI]
MDCLI> arp

[ADMIN@HUAWEI]/arp
MDCLI> speed-limits

[ADMIN@HUAWEI]/arp/speed-limits
MDCLI> 
```
You can specify the names of container nodes of different levels in batches to directly access the view corresponding to the target container node.
```
[ADMIN@HUAWEI]
MDCLI> arp speed-limits

[ADMIN@HUAWEI]/arp/speed-limits
MDCLI> 
```
Leaf and leaf-list nodes in the YANG model are mapped to MD-CLI operation objects, with the node names being the names of the operation objects. A leaf-list node is a set of leaf nodes with exactly one value of a particular type per leaf. You can enter an object name and parameter value to modify the configuration, or run the remove <object name> command to delete the configuration.
Take huawei-arp.yang as an example. In the YANG tree structure, strict-learn-enable, l2topo-detect-enable, and rate-trap-interval are all leaf nodes.
```
module: huawei-arp
+--rw arp
   +--rw global
      +--rw strict-learn-enable?      boolean
      +--rw l2topo-detect-enable?     boolean
      +--rw rate-trap-interval?       uint32
```
On the MD-CLI, strict-learn-enable, l2topo-detect-enable, and rate-trap-interval are mapped to MD-CLI operation objects. You can run the remove <object name> command to delete the configuration.
```
[*(ex)ADMIN@HUAWEI]/arp/global
MDCLI> strict-learn-enable false

[*(ex)ADMIN@HUAWEI]/arp/global
MDCLI> remove rate-trap-interval
```
You can enter multiple operation objects and values in one MD-CLI command line.
```
[*(ex)ADMIN@HUAWEI]/arp/global
MDCLI> strict-learn-enable false l2topo-detect-enable true
```
The list node in the YANG model is also mapped to an MD-CLI node view. A list node defines a sequence of list entries. Each entry is similar to a structure or a record instance, and is uniquely identified by the values of its key leaf nodes. Unlike the container node, the list node (in the list view) requires you to specify all the related key values of the list node in addition to the name of the list node.
Take huawei-arp.yang as an example. In the YANG tree structure, the speed-limits node is a list node, and the corresponding key values are slot-id, suppress-type, and ip-type.
```
module: huawei-arp
+--rw arp
   +--rw speed-limits
      +--rw speed-limit* [slot-id suppress-type ip-type] #Three key nodes of the speed-limit node.
         +--rw slot-id           string
         +--rw suppress-type     suppress-type
         +--rw ip-type           suppress-ip-type
         +--rw suppress-value    uint32
```
On the MD-CLI, the speed-limit node is mapped to the MD-CLI node view. To enter the MD-CLI node view, you need to specify slot-id, suppress-type, and ip-type.
```
[ADMIN@HUAWEI]/arp/speed-limits
MDCLI> speed-limit slot-id 1 suppress-type arp ip-type src-ip

[ADMIN@HUAWEI]/arp/speed-limits/speed-limit[slot-id="1"][suppress-type="arp"][ip-type="src-ip"]
MDCLI>
```
If a list node is nested in a container node, you can specify both the container and list nodes to enter the list node view.
```
[ADMIN@HUAWEI]
MDCLI> arp speed-limit slot-id 1 suppress-type arp ip-type src-ip

[ADMIN@HUAWEI]/arp/speed-limits/speed-limit[slot-id="1"][suppress-type="arp"][ip-type="src-ip"]
MDCLI>
```
The RPC node in the YANG model is a maintenance node, through which you can perform maintenance operations. Similar to the container and list nodes, the RPC node has its name mapped to that of the MD-CLI node view.
Take huawei-file-operation.yang as an example. In the YANG tree structure, copy-file is an RPC node.
```
module: huawei-file-operation
+---x copy-file
   +---- input
      +---w src-file-name    leafref
      +---w des-file-name    string
```
On the MD-CLI, the copy-file node is mapped to an MD-CLI node view. You can enter the name of an RPC node to enter the RPC view and then perform maintenance operations, for example, copying files.
```
[ADMIN@HUAWEI]
MDCLI> copy-file

[(x)ADMIN@HUAWEI]/copy-file
MDCLI> src-file-name file-1.txt des-file-name file-2.txt

[(x)ADMIN@HUAWEI]/copy-file
MDCLI> emit
```

Example of Mapping Between huawei-arp.yang Nodes and MD-CLI Commands

As shown in the preceding information, the hierarchy of the YANG tree is expressed through the view hierarchy on the MD-CLI. The following example shows the mapping between YANG nodes and MD-CLI commands. On the MD-CLI command list on the right, indentation indicates the nesting relationship between MD-CLI views, text in bold indicates the MD-CLI view names and operation object commands, and text in italics indicates related command parameters (including specific parameter types).

YANG tree structure                                                MD-CLI command list
module: huawei-arp
+--rw arp  ----------------------------------------------------------> arp
   +--rw global ----------------------------------------------------->     global
   |  +--rw strict-learn-enable?      boolean ----------------------->         strict-learn-enable boolean
   |  +--rw l2topo-detect-enable?     boolean ----------------------->         l2topo-detect-enable boolean
   |  +--rw rate-trap-interval?       uint32 ------------------------>         rate-trap-interval uint32
   |  +--rw passive-learn-enable?     boolean ----------------------->         passive-learn-enable boolean
   |  +--rw topo-detect-disable?      boolean ----------------------->         topo-detect-disable boolean
   |  +--rw con-send-enable?          boolean ----------------------->         con-send-enable boolean
   |  +--rw con-send-maxnum?          uint16 ------------------------>         con-send-maxnum uint16
   |  +--rw gratuitous-drop?          boolean ----------------------->         gratuitous-drop boolean
   |  +--rw vlanif-expiretime?        uint32 ------------------------>         vlanif-expiretime uint32
   |  +--rw host-conflict-period?     uint16 ------------------------>         host-conflict-period uint16
   |  +--rw host-conflict-threshold?  uint16 ------------------------>         host-conflict-threshold uint16
   |  +--rw broadcast-max-num?        uint16 ------------------------>         broadcast-max-num uint16
   +--rw speed-limits ----------------------------------------------->      speed-limits
   |  +--rw speed-limit* [slot-id suppress-type ip-type] ------------>         speed-limit slot-id string suppress-type type ip-type ip-type
   |     +--rw slot-id           string                                
   |     +--rw suppress-type     suppress-type                
   |     +--rw ip-type           suppress-ip-type              
   |     +--rw suppress-value    uint32 ----------------------------->            suppress-value uint32
   +--rw static-arps ------------------------------------------------>      static-arps        
      +--rw static-arp* [ip-addr ni-name] --------------------------->         static-arp ip-addr ipv4-address ni-name string
         +--rw ip-addr     ipv4-address-no-zone          
         +--rw ni-name     leafref                      
         +--rw mac-addr    mac-address  ----------------------------->            mac-addr mac-address
         +--rw vlan-id?    uint16 ----------------------------------->            vlan-id uint16

References

1MD-CLI Configuration (CloudEngine Data Center Switches)

2What Is YANG?

About This Topic

Author： Liu Feiyang
Updated on： 2024-02-27
Views： 2914
Average rating：