3.1.2. Key features¶
The key features of the CLI are:
Command line¶
The CLI comes with traditional features, such as completion, history and
contextual help. It relies on a YANG data model that users browse as they would
browse a file system, for example, /
jumps to the root of the configuration,
..
moves one level up. Relative and absolute paths can be used to refer to
configuration data, making browsing very efficient.
NETCONF API¶
The management system embeds a NETCONF server which can be configured to accept external connections from a NETCONF client. It supports all the required protocol operations to read and write the configuration: <get>, <get-config>, <edit-config>, <copy-config> and so on.
The CLI is actually a client that connects locally to this NETCONF server.
Clear separation between configuration and state data¶
At the root of the data model, there are two trees: config
and state
. The
items in config
represent the target configuration, while the ones in state
represent the actual state of the system. As a result, state
generally
includes the items in config
, plus additional runtime information, such as
the statistics, or the IP addresses obtained through DHCP for example.
Multiple logical VRF¶
The management system splits the device into VRFs. Each VRF has its own
set of IP addresses, routing tables, firewall rules, and other network-related
resources. The configuration of most networking services occurs inside a VRF
context. The default VRF is called main
and will always exist on the system,
even if it is not present in the configuration. Some services such as SSH or
NETCONF are launched by default in this VRF.
VRFs rely on the Linux network namespaces feature (netns). This kind of container may be used in future releases to define limits in term of CPU resource or memory.
Compatibility with Day-1 configuration¶
Cloud-init is embedded in the Virtual Service Router for Day-1 configuration, that is, the initial configuration of the Virtual Service Router to enable basic console access. By default, cloud-init starts a DHCP client on the first interface and enables a SSH server on it. It can be customized to configure a specific interface, use a static IP address, create users, provision SSH keys, etc.
The management engine is compatible with cloud-init Day-1 configuration, as it does not touch the network services (SSH, DNS, DHCP, etc.) as long as there is no configuration statement for them. When a configuration statement is present, it takes precedence over any existing configuration coming from cloud-init. Finally, a known service like SSH will be recognized and will not be restarted if it is not necessary.