Categories Massive MIMO

Management Information Tree – Cisco Operating Cisco ACI

Management Information Tree

All the physical and logical components that comprise the Application-Centric Infrastructure fabric are represented in a hierarchical management information model (MIM), also referred to as the MIT. Each node in the tree represents an MO or group of objects that contains its administrative state and its operational state.

The hierarchical structure starts at the top (root) and contains parent and child nodes. Each node in this tree is an MO, and each object in the ACI fabric has a unique distinguished name (DN) that describes the object and its place in the tree. MOs are abstractions of the fabric resources. An MO can represent a physical object, such as a switch or adapter, or a logical object, such as a policy or fault.

Configuration policies make up the majority of the policies in the system and describe the configurations of different ACI fabric components. Policies determine how the system behaves under specific circumstances. Certain MOs are not created by users but are automatically created by the fabric (for example, power supply objects and fan objects). By invoking the API, you can read and write objects to the MIM.

The information model is centrally stored as a logical model by the APIC, while each switch node contains a complete copy as a concrete model. When a user creates a policy in the APIC that represents a configuration, the APIC updates the logical model. The APIC then performs the intermediate step of creating a fully elaborated policy from the user policy and then pushes the policy into all the switch nodes where the concrete model is updated. The models are managed by multiple data management engine (DME) processes that run in the fabric. When a user or process initiates an administrative change to a fabric component (for example, when you apply a profile to a switch), the DME first applies that change to the information model and then applies the change to the actual managed endpoint. This approach is called a model-driven framework.

Figure 9-12 shows the branch diagram of a leaf switch port that starts at the top root of the ACI fabric MIT and follows a hierarchy that is composed of a chassis with two-line module slots, with a line module in slot 2.

  

Figure 9-12 ACI Fabric MIT Branch Diagram of a Leaf Switch Port

You can identify and access a specific object by its distinguished name (DN) or by its relative name (RN), depending on the current location in the MIT. The RN identifies an object from its siblings within the context of its parent object.

The DN enables you to unambiguously identify a specific target object. The DN consists of a series of RNs:

dn = {rn}/{rn}/{rn}/{rn}…

For example, following DN contains RNs, as shown in Table 9-1:

Click here to view code image

<dn = “sys/ch/lcslot-1/lc/fabport-1″/>

Table 9-1 Relative Names Example

Relative Name

Class

Description

sys

top:System

Top level of this system

ch

eqpt:Ch

Hardware chassis container

lcslot-1

eqpt:LCSlot

Line module slot 1

lc

eqpt:LC

Line (I/O) module

fabport-1

eqpt:FabP

Fabric-facing external I/O port 1

Because of the hierarchical nature of the tree and the attribute system used to identify object classes, the tree can be queried in several ways for obtaining managed object information. Queries can be performed on an object itself through its distinguished name, on a class of objects such as a switch chassis, or on the tree level to discover all members of an object:

  • Tree-level query: Tree-level queries return the referenced object and its child objects. This approach is useful for discovering the components of a larger system.
  • Class-level query: Class-level queries return all the objects of a given class. This approach is useful for discovering all the objects of a certain type that are available in the MIT.
  • Object-level query: In an object-level query, a distinguished name is used to return a specific object.

Figure 9-13 illustrates different query levels. The two tree-level queries discover the cards and ports of a given switch chassis. The class-level query used is Cards, which returns all the objects of type Cards. The two object-level queries used are for Node 1 in Chassis 2 and for Node 1 in Chassis 1 in Card 1 in Port 2.

  

Figure 9-13 Different Query Levels

For all MIT queries, an administrator can optionally return the entire subtree or a partial subtree. Additionally, the role-based access control (RBAC) mechanism in the system dictates which objects are returned; only the objects that the user has rights to view will ever be returned.

Leave a Reply

Your email address will not be published. Required fields are marked *