Cisco Open NX-OS is object-oriented, and everything within the model is represented as an object. Objects store the configuration or operational state for Open NX-OS features associated with the data model. Within the model, objects can be created in reference to other objects. References may be among various networking constructs, such as interfaces and VLANs, as well as relationships between these components. Trunked VLAN interfaces represent an example of related, hierarchical objects.

The following section outlines how MOs are defined in Open NX-OS during the software development process.

MO Definition

Open NX-OS software developers define models for various classes in an XML format, and use a modeling schema with various tags to denote specific attributes of the class. This relationship is defined prior to compile-time and is enforced during run time. However, it is only the relationship that we create when defining the model and properties of each MO.

Class model definition

Copy<model>  
   <package name="aggregate">  
        <objects>  
            <! Section1 >  
            <mo name="SystemTable"  
                concrete="yes"  
                label="System Table"  
                read-access="access-protocol-util">  
  <! List of other properties>  
            </mo>  
            <rn mo="SystemTable">  
                <item prefix="systemTable"/>  
            </rn>  
            <contains parent="top:System"  
                      child="SystemTable"  
            />  
 
            <mo name="ControllerTable"  
                concrete="yes"  
                label="Controller Table"  
                read-access="access-protocol-util"  
                >  
            </mo>  
            <rn mo="ControllerTable">  
                <item prefix="controllerTable"/>  
            </rn>  
            <contains parent="SystemTable"  
                      child="ControllerTable"  
                      />  
                      
            <mo name="ControllerEntry"  
                concrete="yes"  
                label="Controller Entry"  
                read-access="access-protocol-util"  
                >  
                <! Section2 >  
                <property name="id"  
                          type="scalar:Uint32"  
                          owner="management"  
                          mod="implicit"  
                          label="Controller ID"  
                          />  
            
            <rn mo="ControllerEntry">  
               <item prefix="controller" property="id" />  
            </rn>  
            <! Section3 >  
            <contains parent="ControllerTable"  
                      child="ControllerEntry"  
                      />  
            <! Section4 >  
            <chunk target="ControllerEntry"  
                   owner="vlanmgr"  
                   type="primary"  
                   />  

MO Properties

On a Cisco Nexus switch, the configuration and/or operational state of the network can be stored in the MO as properties of the MO. Some properties can be used to store configuration state, such as enabled/disabled state and attributes of protocols, while other properties can be used to store operational state, such as statistics, faults, events, and audit trails.

Properties within MOs will have an attribute.

Copy  propertyname="attribute"  

Values can be expressed in terms of regular expressions, etc. Thus, one can actually specify that a certain property can have a string as its value only if that string matches a particular regular expression. All type/regex checking is done prior to creating an MO and storing the value as one of its properties.

MO property definition

Copy<property name="speed"
            type="Speed"
            owner="management"
            mod="implicit"
            label="Speed"
            />

MO Grouping

Each class is part of a package, and the definition of the class includes the package name. Each class has a mo name that identifies the class. References to an MO in the current package can be made by directly specifying the name of the MO. Any reference to an MO in a different file/package will have to prefix the reference with the package name of the MO being referred. Any reference from an external package to the controllerTable MO, in the Class model definition example above, should be formatted as aggregate: controllerTable, where controllerTable is the class name and aggregate is the namespace qualifier. This ensures you are using the right class while referencing it in some other package.

MO Inheritance

Each object within the data model is an instance of its associated class. The objects in the model can use the concept of inheritance, which allows for new objects to take on properties from existing, more abstracted base objects. For example, a physical interface can be a data port or a management port; however, both of these still have the same basic properties, so they can inherit from a single interface base class. Rather than redefine the same properties many times, inheritance can be used to define them in one base class, and then customize them for a specific child class.

A class can be defined as a purely abstract class by setting the concrete=yes/no attribute to concrete=no. Such classes are purely abstract - no objects of the class can be instantiated. Other non-abstract, concrete MO can reference the abstract MO as a “super class” and inherit the class properties.

Parent-Child Inheritance Relationship in Open NX-OS Data Model

Access Control

An important attribute of the MO is its access control attribute, defined by access=admin/user. This basically denotes the access privileges for the specific MO and determines which user-access-role is allowed to access and modify this particular MO. This ability to specify per-MO permissions enables a programmability model with granular access control to meet the security requirements of the infrastructure.