Object Model

The acitoolkit object model is divided into 3 sub-areas

  • Application Topology Object Model
  • Interface Object Model
  • Physical Topology Object Model

Application Topology

The acitoolkit defines the fabric configuration using a set of policies that describes the application logical topology.

The following diagram shows the full logical topology diagram autogenerated from the source code.

// ACI Toolkit Class Hierarchy
digraph "ACI Toolkit Class Hierarchy" {
    node [color=lightblue2 style=filled]
    edge [arrowhead=none]
    LogicalModel [label=LogicalModel]
    Tenant [label=Tenant]
    ContractSubject [label=ContractSubject]
    OutputTerminal [label=OutputTerminal]
    EPG [label=EPG]
    IPEndpoint [label=IPEndpoint]
    Filter [label=Filter]
    AppProfile [label=AppProfile]
    OutsideL3 [label=OutsideL3]
    Tag [label=Tag]
    AttributeCriterion [label=AttributeCriterion]
    Taboo [label=Taboo]
    Endpoint [label=Endpoint]
    OutsideEPG [label=OutsideEPG]
    Contract [label=Contract]
    FilterEntry [label=FilterEntry]
    BridgeDomain [label=BridgeDomain]
    Subnet [label=Subnet]
    OutsideL2 [label=OutsideL2]
    OutsideL2EPG [label=OutsideL2EPG]
    ContractInterface [label=ContractInterface]
    Context [label=Context]
    OutsideNetwork [label=OutsideNetwork]
    InputTerminal [label=InputTerminal]
    AnyEPG [label=AnyEPG]
            LogicalModel -> Tenant
            ContractSubject -> OutputTerminal
            EPG -> IPEndpoint
            ContractSubject -> Filter
            AppProfile -> EPG
            OutsideL3 -> Tag
            EPG -> AttributeCriterion
            Taboo -> ContractSubject
            EPG -> Endpoint
            OutsideEPG -> Tag
            Contract -> FilterEntry
            BridgeDomain -> Subnet
            OutsideL2 -> OutsideL2EPG
            Tenant -> ContractInterface
            Contract -> ContractSubject
            Context -> Tag
            OutsideEPG -> OutsideNetwork
            BridgeDomain -> Tag
            Tenant -> Filter
            Tenant -> Tag
            Filter -> Tag
            Tenant -> Taboo
            ContractSubject -> InputTerminal
            OutsideL3 -> OutsideEPG
            EPG -> Tag
            Taboo -> FilterEntry
            Context -> AnyEPG
            OutsideL2 -> Tag
            Tenant -> AppProfile
            Tenant -> OutsideL3
            Filter -> FilterEntry
            Tenant -> Contract
            Tenant -> OutsideL2
            Tenant -> Context
            Contract -> Tag
            Tenant -> BridgeDomain
}

Some of the key classes are shown and described below with the remainder described in the API Reference.

_images/apptopo.png

Tenant is the root class within the acitoolkit object model hierarchy. All of the application topology configuration occurs within a Tenant.

AppProfile is the Application Profile class. It contains the configuration for a given application.

EPG is the Endpoint Group class. This is the object for defining configuration that is applied when endpoints connect to the fabric.

Context is the class representing an L3 namespace (roughly, a traditional VRF in Cisco terminology).

BridgeDomain is the class representing an L2 forwarding domain (roughly, a traditional VLAN). It is associated with a single Context.

Subnet is the class representing an L3 subnet. It is associated with a single BridgeDomain.

OutsideEPG is the class representing an EPG that connects to the world outside the fabric. This is where routing protocols such as OSPF are enabled.

Contracts define the application network services being provided and consumed by EPGs. EPGs may provide and consume many contracts.

Taboos define the application network services that can never be provided or consumed by EPGs.

FilterEntry contained within either a Contract or a Taboo. Defines the traffic profile that the Contract or Taboo applies.

Interface Object Model

Interfaces provide the linkage between the application logical topology and the underlying physical network topology. The Interface set of classes are connected through a series of attachment relationships as shown in the class diagram below.

_images/interfacemodel.png

Interface class represents the Physical Interfaces. These are the objects that link the logical topology with the physical world. These objects represent the access ports on the leaf switches. These are the interfaces that the endpoints will physically attach.

PortChannel class represents the logical aggregated ethernet port formed by Link Aggregation. This is done by creating a PortChannel instance and attaching one or more Interface instances to it. When interfaces belonging to 2 separate switches are assigned to the same PortChannel, this is referred to as a VPC or Virtual Port Channel. In the acitoolkit, VPCs are also represented by the PortChannel class.

L2Interface class represents the logical L2 network attachment on an Ethernet interface. In this case, the Ethernet interface could be an Interface class instance or PortChannel class instance as both are considered representations of link layer Ethernet interfaces.

Multiple logical L2 network attachments can occur on the same Ethernet interface. When this occurs, the L2Interface instances must use different encapsulation identifiers and/or different encapsulation types. The valid encapsulation types are:

  • VLAN
  • VXLAN
  • NVGRE

L3Interface class represents the logical L3 network attachment on an L2Interface. The L3Interface instance is where the IP address resides.

OSPFInterface class represents the logical router interface that routes from the L3Interface instance. It contains the OSPF-specific interface configuration.

Physical Topology

The acitoolkit defines the network topology using a set of objects that represent each of the components of the topology.

These objects are connected in a hierarchy according to the following diagrams.

// ACI Toolkit Class Hierarchy
digraph "ACI Toolkit Class Hierarchy" {
    node [color=lightblue2 style=filled]
    edge [arrowhead=none]
    PhysicalModel [label=PhysicalModel]
    Pod [label=Pod]
    ExternalSwitch [label=ExternalSwitch]
    Link [label=Link]
    "Node " [label="Node "]
    Powersupply [label=Powersupply]
    Linecard [label=Linecard]
    Interface [label=Interface]
    Supervisorcard [label=Supervisorcard]
    Fantray [label=Fantray]
    Fan [label=Fan]
    Systemcontroller [label=Systemcontroller]
            PhysicalModel -> Pod
            Pod -> ExternalSwitch
            Pod -> Link
            Pod -> "Node "
            "Node " -> Powersupply
            Linecard -> Interface
            "Node " -> Linecard
            "Node " -> Supervisorcard
            "Node " -> Fantray
            Fantray -> Fan
            "Node " -> Systemcontroller
} _images/objectModelTop.png

The acitoolkit.aciphysobject.Node object is used to represent both switches and controllers. Which kind of acitoolkit.aciphysobject.Node can be determined by looking at the role, Node.role, attribute. Switches are Nodes with the role of ‘leaf’ or ‘spine’ and controllers are Nodes with the role of ‘controller’. Switches are composed slightly different from controllers as shown in the following diagram.

_images/objectModelSwitch.png _images/objectModelController.png

Pod is the class for a physical Pod. acitoolkit.aciphysobject.Pod conatins of all the switches, links, and controllers that connected in the simple leaf-spine fat tree topology of the ACI fabric. It does not include the end-points or other devices that are attached to the ACI fabric.

Node is the class used to represent switches and controllers. What role the acitoolkit.aciphysobject.Node plays in the fabric can be determined by looking at the role attribute.

Link is the class representing links in the fabric. acitoolkit.aciphysobject.Link includes links between leaf and spine switches as well as links from leaf switches to controllers. Each link has two ends, the first and second end, in no particular order. This class has methods for retrieving the Switch, Linecard and Interface for each of the ends of the link.

Supervisorcard is the class representing the supervisor card in a switch. acitoolkit.aciphysobject.Supervisorcard would only be a child of a Node that has the role of ‘leaf’ or ‘spine’. Each switch will have a supervisor including fixed configuration switches that may not have a obviously physically separate module that is a supervisor. The supervisor is where the primary software of the switch runs.

Linecard is the class representing a linecard in a switch. The acitoolkit.aciphysobject.Linecard is where all of the physical interfaces or ports are attached. In modular switches, the linecard is physically obvious, but even fixed configuration switches have a linecard where all the interfaces, ports, reside. A specific linecard in a switch is identified by its slot_id attribute. The slot_id of a linecard in a fixed configuration switch is always ‘1’.

Powersupply acitoolkit.aciphysobject.Powersupply is the class representing a power supply in a node.

Fantray acitoolkit.aciphysobject.Fantray is the class representing a fan tray in a node

Systemcontroller acitoolkit.aciphysobject.Systemcontroller is the class representing a system contoller of an APIC controller. This is the motherboard of the controller and is a good place to understand the version of software that is running in the controller.

Interface acitoolkit.acitoolkit.Interface described above.