The NetManage Application Programming Interface is implemented on a Remote Procedure Call (RPC) library. This abstraction allows the client making the call to be physically remote from the device implementing the interface.
The distributed design is intended to provide management framework scalability that allows large numbers of switches in the datacenter to be managed as a single, collaborative entity.
The NetManage Protocol is implemented in compliance with the SunRPC IETF standard and is specified with an IDL (Interface Definition Language) that allows for additional services to be added and existing services to be modified easily.
Although SunRPC is a client-server architecture, the Application (client) and the Switch (server) contain both RPC client and RPC server components. This allows for events such as link status and power failure to be delivered to the application asynchronously.
The NetManage API allows for applications to listen for such events or choose to ignore them.
The NM API Server implements the NetManage application programming interface at the target. The server implements a generic framework that supports dynamically loadable plug-ins for Vendor Silicon SDK (chipset support), network protocols, and management extensions such as SNMP.
The NMF API Server is customized through XML files that are read and parsed when the server is started. There are three types of customization: Device, Protocol, and Network.
|Device||Specifies the number and type of Vendor SDK Drivers that are installed in the switch. An NM Device Driver is a loadable library that exports the NM Device Interface.|
|Protocols||Specifies the set of protocol drivers that are loaded when the server is started. An NM Protocol Driver is a loadable library that exports the NM Protocol Interface.|
|Network||The network configuration specifies a set of parameters and values that collectively define the configuration of the switch. For example, the VLAN, LAG, and Port configurations that were last saved.|
A NetManage client application writes to the NetManage API /Class Library (hereafter NMAPI) to query and modify the configuration of a switch. The NMAPI is implemented as shown in the figure. The NMAPI is essentially a wrapper that sits on a Adapter Layer. The purpose of the Adapter Layer is to detect requests that are directed at local switch silicon and route them directly to the local NM API Server. Requests that are intended for a remote switch are directed to the RPC Client Layer where they are ultimately XDR encoded (marshalled) into SunRPC protocol messages and sent on the network to a remote peer.
This approach avoids the SunRPC overhead for requests that are intended for the local switch silicon (localhost).
Referring back to the Server Side figure the localhost bypass implemented by the Adapter Layer corresponds to the Extensions API shown in that figure.
This is a very powerful abstraction that allows protocols, firewalls and other applications to be written without regard to where they may be run. A Server Extension can be written once and then deployed without modification as the performance requirements and hardware implementation require.
The NetManage server supports persistent configuration that will survive a power failure or switch reboot. Persistent configuration information is stored as an XML format file locally on the switch. A name of the configuration file to restore when the server is started is specified by an environment variable.
The NetManage API nmf_cfg_save and nmf_cfg_restoreare provided to allow the client to save and restore configurations to a file name on the switch. The root of the filesystem accessible through this path string is specified by the NMF_CONFIG_PATH environment variable. This restricts the area of the switch accessible by the application for storing and retrieving configuration information.
The NetManage toolkit also provides an XML parser that can be used by the client application for building and parsing configuration files for application specific data.