├
|
![[V]](styles/eye.gif) |
pol:Obj Represents a generic policy object. |
|
├
|
|
pol:Def Represents self-contained policy document. |
|
|
├
|
|
aaa:AuthRealm An authentication realm provides authentication to verify the identity of an entity (person or device) accessing fabric devices. The authentication is based on the user ID and password combination provided by the entity trying to access the fabric. Authentication can be performed locally, using the local lookup database, or by remote, using one or more RADIUS or TACACS+ servers. |
|
|
├
|
|
aaa:Definition The AAA policy definition. This is an abstract class and cannot be instantiated. |
|
|
|
├
|
|
aaa:ADomainRef This object is generated and used only by internal processes. |
|
|
|
|
├
|
|
aaa:DomainRef A reference to the domain that the parent object belongs to. |
|
|
|
|
├
|
|
aaa:IDomainRef This object is generated and used only by internal processes. |
|
|
|
├
|
|
aaa:AProvider An abstract class that is the superclass for the Radius/Tacacs/Ldap provider classes. |
|
|
|
|
├
|
|
aaa:LdapProvider An LDAP provider is a remote server supporting the LDAP protocol that will be used for authentication. |
|
|
|
|
├
|
|
aaa:RadiusProvider A RADIUS provider is a remote server supporting the RADIUS protocol that will be used for authentication. |
|
|
|
|
├
|
|
aaa:TacacsPlusProvider A TACACS+ provider is a remote server supporting the TACACS+ protocol that will be used for authentication. |
|
|
|
├
|
|
aaa:ARbacRule This is generated and used only by internal processes. |
|
|
|
|
├
|
|
aaa:IPRbacRule IPRbacRule mos are created under aaaRbacEp as a side-effect of the creation of PRbacRule under fv:Tenant |
|
|
|
|
├
|
|
aaa:IRbacRule This is generated and used only by internal processes. |
|
|
|
|
├
|
|
aaa:RbacRule A role based access control (RBAC) rule allows users from a security domain to read the subtree starting at a specific object. |
|
|
|
├
|
|
aaa:Banner An abstract class that contains login banners and cannot be instantiated. |
|
|
|
|
├
|
|
aaa:PreLoginBanner A GUI banner is the informational banner to be displayed before user login authentication. |
|
|
|
├
|
|
aaa:Config The generic security authentication configuration. This is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
aaa:AuthMethod The generic security authentication method.
This is an abstract class and cannot be instantiated. |
|
|
|
|
|
├
|
|
aaa:DefaultAuth The default authentication configuration for all login methods. |
|
|
|
├
|
|
aaa:Domain An AAA domain is the AAA security method for processing authentication requests. |
|
|
|
├
|
|
aaa:Ep The base class for an AAA endpoint is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
aaa:LdapEp The global security management properties for LDAP endpoints
and LDAP provider groups. |
|
|
|
|
├
|
|
aaa:RadiusEp The RADIUS endpoint policy is the global security management properties for RADIUS endpoints
and RADIUS provider groups. |
|
|
|
|
├
|
|
aaa:TacacsPlusEp The TACACS+ endpoint policy is the global security management properties for TACACS+ endpoints
and TACACS+ provider groups. |
|
|
|
├
|
|
aaa:FailedLogin MO to record each failed login for a user. Records both domain and username,
so that remote users are also taken care |
|
|
|
├
|
|
aaa:LdapGroupMapRule
The MO represents an LDAP Group Map Rule
The actual Map consisting of Domains and Roles
|
|
|
|
├
|
|
aaa:LoginDomain An AAA login domain for authentication and authorization. The AAA configuration can be configured per domain. |
|
|
|
├
|
|
aaa:ProviderGroup A provider group is a set of providers that will be used by the system during the authentication process. During authentication, all the providers within a
provider group are tried in order. If all of the configured servers are unavailable or unreachable, the system manager automatically falls back to the local
authentication method using the local username and password. |
|
|
|
|
├
|
|
aaa:LdapProviderGroup An LDAP provider group is a group of remote servers supporting the LDAP protocol for authentication. |
|
|
|
|
├
|
|
aaa:RadiusProviderGroup A RADIUS provider group is a group of remote
servers supporting the RADIUS protocol for authentication. |
|
|
|
|
├
|
|
aaa:TacacsPlusProviderGroup A TACACS+ provider group is a group of remote servers supporting the TACACS+ protocol for authentication. |
|
|
|
├
|
|
aaa:PwdProfile The password profile contains the information about password constraints that apply to all local users. |
|
|
|
├
|
|
aaa:RbacEp This is generated and used only by internal processes. |
|
|
|
├
|
|
aaa:Realm The AAA realm is the security method for processing authentication and authorization requests. The realm allows the protected resources on the associated server to be partitioned into a set of protection spaces, each with its own authentication authorization database. This is an abstract class and cannot be instantiated. |
|
|
|
├
|
|
aaa:Role An AAA role is a set of attributes and privileges that describe what a user is authorized to perform. |
|
|
|
├
|
|
aaa:SshAuth A user's public key in PEM format used for certificate-based login. |
|
|
|
├
|
|
aaa:SystemUser The base class for a system user.
This is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
aaa:User A locally-authenticated user account. |
|
|
|
├
|
|
aaa:UserCert An AAA user certificate in X.509 format. This certificate is the
RSA public key used for certificate-based REST API calls. |
|
|
|
├
|
|
aaa:UserData This object is managed internally and should not be modified by the user. |
|
|
|
├
|
|
aaa:UserEp A user endpoint is a local user. A user is assigned a role determines the user's privileges, and belongs to a security domain, which determines the user's scope of control |
|
|
├
|
|
cap:Def A base class for capabilities. |
|
|
|
├
|
|
eqptcap:AMfgDef The manufacturing-related properties such as PID and SKU. |
|
|
|
|
├
|
|
eqptcap:MfgDef The manufacturing-related properties such as PID and SKU. |
|
|
|
|
├
|
|
eqptcap:SfpMfgDef The small form-factor pluggable transceiver (SFP) manufacturing-related properties. |
|
|
|
├
|
|
cloud:DomP SHIV TODO: Need to find a propert Super class SHASHANK TODO: Need to add other roles/access besides admin |
|
|
├
|
|
cloud:AL3TunnelIfP IPSec tunnel running on the NIC. The outer tunnel desination address is
on-prem IPN router's public address. The tunnel source address is parent
interface's primary address. |
|
|
|
├
|
|
cloud:AProvGC Abstract Provider resource policy for garbage collection |
|
|
|
|
├
|
|
cloud:ProvGC Provider resource policy for garbage collection |
|
|
|
|
├
|
|
cloud:ProvGCDef Provider resource policy for garbage collection Resolved model object |
|
|
|
├
|
|
cloud:IntegrationMode Policy that indicate how is cAPIC managing the provider (Managed Identity / Credential )
Setting backup=no since this policy will contains the VM identity ID, that will be different
for any new cAPIC VM. The policy will be autmatically created on cAPIC bringup with the correct ID |
|
|
|
├
|
|
cloud:SelectedEP Cloud Selected Endpoint, to explicitly indicate the endpoint
to be included in one EPG. |
|
|
├
|
|
cloud:CtxHolder Mo that will be used to pull
cloudCtxProfileDef from PM to cPE |
|
|
├
|
|
cloud:DefCont Container for all the cloud:DefCont, under top, to
have them neatly organized |
|
|
├
|
|
cloud:EPSelectorSubnetDef Cloud EP Selector Subnet Def, resolved MO created
per selector with IP as the only keyword in the match
expresssion |
|
|
├
|
|
comm:Pol The communication policy contains the service configuration for various services. |
|
|
├
|
|
comp:AccessP An abstract base class for policies related to access credentials. |
|
|
|
|
├
|
|
vmm:UsrAccP The user account profile is used to access a VM provider account. |
|
|
├
|
|
condition:RetP The condition log record retention policy specifies the maximum number of log records to be retained and the maximum number of log records to be deleted in a 30-second period. |
|
|
|
├
|
|
aaa:ARetP The audit log retention policy specifies the maximum number of audit log records to be retained and the maximum number of audit log records to be deleted in a 30-second period. Note that this is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
aaa:CtrlrRetP The controller audit log retention policy specifies the maximum number of controller audit log records to be
retained and the maximum number of controller audit log records to
be deleted in a 30-second period. |
|
|
|
|
├
|
|
aaa:SwRetP The switch AAA audit log retention policy specifies the maximum number of AAA audit log records to be retained and the maximum number of AAA audit log records to be deleted in a 30-second period. |
|
|
|
├
|
|
event:ARetP The event record retention policy, which specifies the maximum number of event history records to be retained on the node or controller and the maximum number of event history records to be deleted in a 30-second period. Note that this is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
event:CtrlrRetP The controller event record retention policy, which
specifies the maximum number of controller event records to be
retained and the maximum number of controller event records to
be deleted in a 30-second period. |
|
|
|
|
├
|
|
event:SwRetP The switch event retention policy specifies the maximum number of event records to be retained and the maximum number of
event records to be deleted in a 30-second period. |
|
|
|
├
|
|
fault:ARetP The fault record retention policy specifies the maximum number of fault history records to be retained on the node or controller and the maximum number of fault history records to be deleted in a 30-second period. Note that this is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
fault:CtrlrRetP The controller fault record retention policy specifies the maximum number of controller fault records to be
retained and the maximum number of controller fault records to
be deleted in a 30-second period. |
|
|
|
|
├
|
|
fault:SwRetP Specifies the maximum number of fault records to be retained and the maximum number of fault records to be deleted in a 30-second period. These settings can be changed either by creating a custom policy or editing the default policy. |
|
|
|
├
|
|
health:ARetP The health score history record retention policy, which specifies the maximum health score history record count to delete in a 30-second period. Note that this is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
health:CtrlrRetP The controller health score history record retention policy, which specifies the maximum number of controller health score history
records to be retained and the maximum number of controller health score history records to be deleted in a 30-second period. |
|
|
|
|
├
|
|
health:SwRetP The switch health retention policy specifies the maximum number of health score history records to be retained and the maximum
number of health score history records to be deleted in a 30-second period. |
|
|
├
|
|
configpush:ForcePush MO used to force the re-configuration.
scopeDn is the root of the subtree to re-configure.
|
|
|
├
|
|
copp:AProfile Abstract class for all the profiles for CoPP that can be applied at the node level |
|
|
├
|
|
datetime:APol The date time policy is based on international time zones and a defined NTP server. Before configuring a date and time policy under a domain group, this policy must first be created. Policies under the Domain Groups root were already created by the system and ready to configure. |
|
|
|
├
|
|
datetime:Pol The date time policy is based on international time zones and a defined NTP server. Before configuring a date and time policy under a domain group, this policy must first be created. Policies under the Domain Groups root were already created by the system and ready to configure. |
|
|
├
|
|
datetime:Format The date/time format policy defines the time-zone for the entire fabric. |
|
|
├
|
|
dbg:Ftriage ****************** MOs ********************* Ftriage MO |
|
|
|
├
|
|
dbgac:Filter The filter properties of the client-defined end point attached to the network. |
|
|
|
|
|
├
|
|
dbgac:EpgToEp The endpoint group-to-endpoint atomic counter policy detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues. |
|
|
|
|
|
├
|
|
dbgac:EpgToEpg The endpoint group-to-endpoint group atomic counter policy detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues. |
|
|
|
|
|
├
|
|
dbgac:EpgToIp The endpoint group-to-IP atomic counter policy detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues |
|
|
|
|
├
|
|
dbgac:ToEpgCmn The abstract object with a destination endpoint group. |
|
|
|
|
|
├
|
|
dbgac:EpToEpg The endpoint-to-endpoint group atomic counter policy detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues. |
|
|
|
|
|
├
|
|
dbgac:IpToEpg The IP-to-endpoint group atomic counter policy detects drops and misrouting in the fabric and enables quick debugging and isolation of application connectivity issues. |
|
|
|
|
├
|
|
dbgac:EpToAny The endpoint-to-any atomic counter policy which detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues. |
|
|
|
|
├
|
|
dbgac:EpToEp The endpoint-to-endpoint atomic counter policy detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues. |
|
|
|
|
├
|
|
dbgac:EpToExt The endpoint-to-external IP address atomic counter policy detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues. |
|
|
|
├
|
|
dbgac:IpToIp IP Addr to IP policy Defn. Used for an
external host identified by its IP address to
another IP address
|
|
|
|
├
|
|
dbgac:TenantSpaceCmnDef The tenant space common definition. This atomic counter managed object is used internally for managing Epg/Epp source
and destination policies. |
|
|
|
├
|
|
dbgac:ToEpCmn The abstract object for atomic counter with a destination endpoint. |
|
|
|
|
├
|
|
dbgac:AnyToEp Atomic counters detect drops and misrouting in the fabric enables quick debugging and isolation of application connectivity issues. |
|
|
|
|
├
|
|
dbgac:ExtToEp The external host-to-endpoint atomic counter policy detects drops and misrouting in the fabric to enable quick debugging and isolation of application connectivity issues. |
|
|
├
|
|
dhcp:OptionPol The DHCP option policy, which defines lease duration, gateway routers, and other configuration parameters in what are called DHCP options. Every DHCP server must have one or more policies defined for it. The policies are especially useful if you have multiple scopes because you only need to define a policy once and apply it to the multiple scopes. You can define named policies with specific option definitions or you can use system defaults.
Note... |
|
|
|
|
├
|
|
eqptdiagp:LeTsBtEcc The diagnostic test set for leaf fabric nodes to run at bootup on extended chassis cards (FEXes). |
|
|
|
|
├
|
|
eqptdiagp:LeTsBtLc The diagnostic test set for leaf fabric nodes to run at bootup on line cards (I/O cards). |
|
|
|
|
├
|
|
eqptdiagp:LeTsBtSc The diagnostic test set for leaf fabric nodes to run at bootup on supervisor cards. |
|
|
|
|
|
├
|
|
eqptdiagp:TsBtLeafP The diagnostic test set for leaf fabric ports to run at bootup on line cards (I/O cards). |
|
|
|
|
├
|
|
eqptdiagp:SpTsBtLc The diagnostic test set to run at bootup on spine line cards (I/O cards). |
|
|
|
|
├
|
|
eqptdiagp:SpTsBtScc The diagnostic test set to run at bootup on spine system controller cards. |
|
|
|
|
|
|
|
├
|
|
eqptdiagp:LeTsOdEcc The diagnostic test set for leaf fabric nodes to run on extended chassis cards (FEXes). |
|
|
|
|
|
|
|
├
|
|
eqptdiagp:LeTsOdLc The diagnostic on-demand test set for leaf fabric nodes to run on line cards (I/O cards). |
|
|
|
|
|
|
|
├
|
|
eqptdiagp:SpTsOdLc The diagnostic on-demand test set to run on spine line cards (I/O cards). |
|
|
|
|
|
|
|
├
|
|
eqptdiagp:LeTsOdSc The diagnostic on-demand test set for leaf fabric nodes to run on supervisor cards. |
|
|
|
|
|
|
|
├
|
|
eqptdiagp:SpTsOdSc The diagnostic on-demand test set for leaf fabric nodes to run on spine supervisor cards. |
|
|
|
|
|
|
├
|
|
eqptdiagp:SysCTsOd The on-demand abstract diagnostic policy for system controller cards. |
|
|
|
|
|
|
|
├
|
|
eqptdiagp:SpTsOdScc The diagnostic on-demand test set to run on spine system controller cards. |
|
|
|
|
├
|
|
eqptdiagp:LeTsHlEcc The diagnostic test set for leaf fabric nodes to run on extended chassis cards (FEXes). |
|
|
|
|
├
|
|
eqptdiagp:LeTsHlLc The diagnostic ongoing health test set for leaf fabric nodes to run on line cards (I/O cards). |
|
|
|
|
├
|
|
eqptdiagp:LeTsHlSc The ongoing diagnostic health test set for leaf fabric nodes to run on supervisor cards. |
|
|
|
|
├
|
|
eqptdiagp:SpTsHlFc The ongoing diagnostic health test set to run at bootup on spine fabric cards. |
|
|
|
|
├
|
|
eqptdiagp:SpTsHlLc The ongoing diagnostic health test set to run at bootup on spine line cards (I/O cards). |
|
|
|
|
├
|
|
eqptdiagp:SpTsHlSc The ongoing diagnostic health test set to run at bootup on spine supervisor cards. |
|
|
|
|
├
|
|
eqptdiagp:SpTsHlScc The ongoing diagnostic health test set to run at bootup on spine system controller cards. |
|
|
|
|
├
|
|
infra:OSpineS Override Spine Selector
@@@ Its not configurable because theres no spine policy group in infra. |
|
|
|
|
|
├
|
|
fabric:LeCardPGrp A leaf card policy group enables you to apply policies to a group of leaf cards. |
|
|
|
|
|
├
|
|
fabric:SpCardPGrp A spine card policy group enables you to apply policies to a group of spine cards. |
|
|
|
|
|
├
|
|
fabric:LeNodePGrp A leaf node policy group enables you to apply policies to a group of leaf nodes. |
|
|
|
|
|
├
|
|
fabric:SpNodePGrp A spine node policy group enables you to apply policies to a group of spine nodes. |
|
|
|
|
|
|
├
|
|
fabric:LePortPGrp The leaf port policy group enables you to apply policies to a group of leaf ports. |
|
|
|
|
|
├
|
|
fabric:SpAPortPGrp A base class for a spine port policy group. This is used for specifying policies to be applied to the spine ports consuming this policy group. |
|
|
|
|
|
|
├
|
|
fabric:SpPortPGrp A spine port policy group enables you to apply policies to a group of spine ports. |
|
|
|
|
├
|
|
fabric:CtrlrPGrp The controller policy group enables you to apply policies to a group of controllers. |
|
|
|
|
├
|
|
fabric:PodPGrp A POD policy group enables you to apply policies to the leaf nodes that are part of this POD. |
|
|
|
|
|
|
|
|
├
|
|
infra:AccBndlGrp The bundle interface group enables you to specify the interface policy you want to use. |
|
|
|
|
|
|
|
├
|
|
infra:AccPortGrp The interface policy group enables you to specify the interface policies you want to use. |
|
|
|
|
|
├
|
|
infra:AccBndlSubgrp The access bundle subgroup enables you to specify (override) a different LACP member policy name for some of the interfaces that are part of an access bundle group. |
|
|
|
|
├
|
|
infra:AccCardPGrp The module policy group enables you to specify the module policies you want to use. |
|
|
|
|
├
|
|
infra:AccNodePGrp The node policy group enables you to specify the node policies you want to use. |
|
|
|
|
├
|
|
fabric:CardP The template used for deploying card fabric configuration. |
|
|
|
|
|
├
|
|
fabric:LeCardP The leaf card profile is a template used for deploying the card fabric configuration on a leaf. |
|
|
|
|
|
├
|
|
fabric:SpCardP A spine card profile is used for deploying the card configuration on the spine. |
|
|
|
|
├
|
|
fabric:CtrlrP The controller profile. This object represents the template used for deploying controller-level configuration. |
|
|
|
|
├
|
|
fabric:NodeP The node profile. This is the template used for deploying node fabric configuration. |
|
|
|
|
|
├
|
|
fabric:LeafP The leaf profile is a template used for deploying the leaf fabric configuration. It contains leaf selectors and associates to card and port profiles. |
|
|
|
|
|
├
|
|
fabric:SpineP The spine profile is a template used for deploying the leaf fabric configuration. It contains spine selectors and associates to card and port profiles. |
|
|
|
|
├
|
|
fabric:PodP A POD profile. This is a template used for deploying POD level configuration. |
|
|
|
|
|
├
|
|
fabric:LePortP The leaf fabric port profile contains leaf port selectors that can associate with their respective policy groups. |
|
|
|
|
|
├
|
|
fabric:SpPortP A spine port profile contains leaf port selectors that can associate with their respective policy groups. |
|
|
|
|
├
|
|
infra:ANodeP Node Profile: It represents the template used for deploying node
fabric configuration |
|
|
|
|
|
├
|
|
infra:NodeP The node profile enables you to specify which nodes (Example: a leaf) to configure. |
|
|
|
|
|
├
|
|
infra:SpineP Spine Profile Spine Access Policy: It represents the template used for deploying node
access configuration (ex. Configuration for connecting hypervisor, Fex, External
network ) |
|
|
|
|
├
|
|
infra:AccCardP The module profile enables you to specify the modules you want to configure. |
|
|
|
|
├
|
|
infra:AttEntityP The attached entity profile provides a template to deploy hypervisor policies on a large set of leaf ports. This also provides the association of a Virtual Machine Management (VMM) domain and the physical network infrastructure. |
|
|
|
|
├
|
|
infra:FexP The FEX profile enables you to configure FEX interfaces. |
|
|
|
|
├
|
|
infra:FuncP The hypervisor management function provides the policies used for hypervisor management and connectivity. For example, an endpoint group and encap VLAN. |
|
|
|
|
├
|
|
infra:PodP Pod Profile: It represents the template used for deploying POD
level configuration |
|
|
|
|
|
├
|
|
infra:AccPortP The interface profile enables you to specify the interface you want to configure. |
|
|
|
├
|
|
fabric:ProtPol The VPC protection policy is a container of VPC protection groups; it enables you to select a pairing type for creating the protection groups |
|
|
|
|
|
├
|
|
fabric:SpCardS A card selector. This is a range of cards on the spine. |
|
|
|
|
├
|
|
infra:CardS The module selector enables you to select the modules to configure and the configuration method. |
|
|
|
|
├
|
|
fabric:ANodeS An abstraction of the fabric node and access node selectors. |
|
|
|
|
|
|
├
|
|
condition:NodePolGrp The node policy group is a group of nodes to which Fault, Event, Audit, or Health record retention policies can be applied. |
|
|
|
|
|
|
├
|
|
firmware:FwGrp A firmware group is a set of nodes to which a firmware policy may be applied. |
|
|
|
|
|
|
├
|
|
maint:MaintGrp The maintenance group is a set of nodes to which a maintenance policy may be applied. The maintenance policy determines the pre-defined action to take when there is a disruptive change made to the service profile associated with the node group. |
|
|
|
|
|
|
├
|
|
telemetry:FlowServerGrp
Telemtry Flow Server Group. A set of nodes to which a telemetry filter policy
may be applied.
|
|
|
|
|
|
|
├
|
|
fabric:LeafS The leaf selector. This enables you to select all or a range of leaves. |
|
|
|
|
|
|
├
|
|
fabric:SpineS The spine selector. This enables you to select all or a range of spines. |
|
|
|
|
|
|
├
|
|
infra:ConnNodeS The connectivity selector is used for grouping ports between the FEX and the host (such as hypervisor). |
|
|
|
|
|
|
|
├
|
|
infrazone:NodeGrp Infrastructure Zone Node Group: Used for listing member nodes of the zone |
|
|
|
|
|
|
|
├
|
|
mgmt:NodeGrp The managed node group captures the set of nodes that will participate in the management network. All the nodes, a range of nodes, or a specific node can be selected to participate in a given managed node group. |
|
|
|
|
|
|
|
├
|
|
infra:LeafS The leaf selector enables you to select the interface to configure. |
|
|
|
|
|
|
├
|
|
condition:PodPolGrp
A set of PODs to which a set of Fault/Event/Audit/Health policies
may be applied.
|
|
|
|
|
|
|
├
|
|
firmware:PodFwGrp
POD Firmware Group. A set of PODS to which a firmware policy
may be applied.
|
|
|
|
|
|
|
├
|
|
maint:PodMaintGrp
POD Maintenance Group. A set of PODs to which a maintenance policy
may be applied.
|
|
|
|
|
|
├
|
|
fabric:PodS The POD selector enables you to select all or a range of PODs. |
|
|
|
|
├
|
|
fabric:APortS An abstraction of the fabric port selector and access port selector. |
|
|
|
|
|
|
├
|
|
fabric:LFPortS The leaf fabric port selector. This object enables you to specify leaf fabric ports with your leaf fabric port profile. |
|
|
|
|
|
|
├
|
|
fabric:SFPortS The spine fabric port selector. This enables you to specify spine fabric ports with your spine fabric port profile. |
|
|
|
|
|
├
|
|
infra:PortS An abstraction of access interface selectors. |
|
|
|
|
|
|
├
|
|
infra:ConnFexS The Connectivity FEX selector is used for grouping ports between the FEX and the host (such as a hypervisor). |
|
|
|
|
|
|
├
|
|
infra:HConnPortS The host connectivity port selector is used for grouping ports between the node and the host (such as hypervisor). |
|
|
|
|
|
|
├
|
|
infra:HPortS The Host Port Selector is used for grouping ports between the node and the host (such as hypervisor). |
|
|
|
|
|
|
├
|
|
infra:SHPortS Spine Host/Access Port Selector. This selector is used for applying infrastructure
policies on selected ports |
|
|
|
|
├
|
|
fabric:CtrlrS The fabric controller group is made up of a core and a tech support export policy. |
|
|
|
├
|
|
hvs:ExtPol The extended policies, which are common policies for VM interfaces. For example, when implementing VMware, this represents the distributed virtual port group. |
|
|
├
|
|
fabric:ExtPol The configuration of the extended fabric equipment, such as FEX. |
|
|
├
|
|
fabric:GlbEpListenPol Global Ep listen policy: if enabled, we listen to all
untagged end point on all leaf ports |
|
|
├
|
|
fabric:MaintPol The maintenance policy. This is used for listing blacklisted or inactive devices. |
|
|
|
├
|
|
fabric:OOServicePol The service policy. This is used for listing equipment under maintenance. |
|
|
├
|
|
fabric:ProtChainP A node proxy IP profile. This is an implicit profile used for managing spine proxy IP addresses. |
|
|
|
|
├
|
|
fabric:HIfPol The host interface policy specifies the layer 1 parameters of host facing ports. |
|
|
|
|
|
├
|
|
bgp:PeerPfxPol The peer prefix policy defines how many prefixes can be received from a neighbor and the action to take when the number of allowed prefixes is exceeded. This feature is commonly used for external BGP peers, but can also be applied to internal BGP peers. |
|
|
|
|
├
|
|
coop:Pol The COOP policy contains groups of Oracles nodes and COOP repositories. |
|
|
|
|
|
|
├
|
|
rtdmc:ABDPol Abstraction of Bridge-Domain Level Multicast policy |
|
|
|
|
|
|
├
|
|
fv:EpRetPol The endpoint retention policy provides the parameters for the lifecycle of the endpoints. |
|
|
|
|
|
├
|
|
igmp:ASnoopPol Restricts flooding of multicast traffic by sending multicast traffic only to the bridge domains that are subscribed to a particular multicast group. |
|
|
|
|
|
|
├
|
|
igmp:SnoopDef The process of listening to Internet Group Management Protocol (IGMP) network traffic. The feature allows a network switch to listen in on the IGMP conversation between hosts and routers. By listening to these conversations the switch maintains a map of which links need which IP multicast streams. |
|
|
|
|
|
|
├
|
|
igmp:SnoopPol The IGMP snooping policy streamlines multicast traffic handling for VLANs. By examining (snooping) IGMP membership report messages from interested hosts, multicast traffic is limited to the subset of VLAN interfaces on which the hosts reside. |
|
|
|
|
|
|
├
|
|
mld:SnoopDef The process of listening to Multicast Listener Discovery (MLD) network traffic. The feature allows a network switch to listen in on the IGMP conversation between hosts and routers. By listening to these conversations the switch maintains a map of which links need which IP multicast streams. |
|
|
|
|
|
|
├
|
|
mld:SnoopPol The MLD snooping policy streamlines multicast traffic handling for VLANs. By examining (snooping) MLD membership report messages from interested hosts, multicast traffic is limited to the subset of VLAN interfaces on which the hosts reside. |
|
|
|
|
|
|
|
├
|
|
bgp:CtxDef An internal object for the BGP context-level policy definition. |
|
|
|
|
|
|
|
├
|
|
bgp:CtxPol The BGP timers policy uses timers to control periodic activities such as the frequency keepalive messages that are sent to its peer, the amount of time the system waits to declare a peer dead after keepalive messages stop being received, and the amount of time before restarting a dead peer. The BGP timer policy enables you to specify the intervals for the periodic activities and supplies two options for graceful restart control: the graceful rest... |
|
|
|
|
|
|
├
|
|
eigrp:ACtxAfPol The abstraction of the context-level EIGRP policy, which contains the configuration for an address family on a context on the node. The EIGRP policy is configured under the tenant protocol policies and can be applied to one or more contexts (private domains) under the tenant. The EIGRP context policy can be enabled on a context through a relation in the context per address family. If there is no relation to a given address family, or the EIGRP c... |
|
|
|
|
|
|
|
├
|
|
eigrp:CtxAfPol An EIGRP context policy can be applied on one or more contexts under the tenant. EIGRP context policies can be enabled on a context through a relation in the context per address family. If there is no relation to a given address family such as IPv6 or the EIGRP context policy mentioned in the relation doesn't exist, then the default context policy created under Tenant Common will be used for that address family. |
|
|
|
|
|
|
├
|
|
ipmc:ACtxPol Abstraction of Context-level Routed Multicast policy |
|
|
|
|
|
|
|
├
|
|
ospf:CtxDefAf The context-level OSPF definition per address family. |
|
|
|
|
|
|
|
├
|
|
ospf:CtxPol The context-level OSPF timer policy provides the Hello timer and Dead timer intervals configuration. |
|
|
|
|
|
|
├
|
|
rtdmc:ACtxPol Abstraction of Context-level Routed Multicast policy |
|
|
|
|
|
├
|
|
isis:DomPol The domain policy is used to configure IS-IS domain specific properties. |
|
|
|
|
|
├
|
|
stormctrl:IfPol The storm control interface policy. A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. You can use the traffic storm control feature to prevent disruptions on ports by a broadcast, multicast, or unknown unicast traffic storm on physical interfaces. |
|
|
|
|
|
├
|
|
cdp:AIfPol The CDP Interface Policy parameters. CDP is primarily used to obtain protocol addresses of neighboring devices and discover the platform of those devices. CDP can also be used to display information about the interfaces your router uses. CDP is media- and protocol-independent, and runs on all Cisco-manufactured equipment including routers, bridges, access servers, and switches. |
|
|
|
|
|
|
├
|
|
cdp:IfPol The CDP interface policy, which is primarily used to obtain protocol addresses of neighboring devices and discover the platform of those devices. CDP can also be used to display information about the interfaces your router uses. CDP is media- and protocol-independent, and runs on all Cisco-manufactured equipment including routers, bridges, access servers, and switches. |
|
|
|
|
|
├
|
|
copp:IfPol Per interface per protocol CoPP policy |
|
|
|
|
|
├
|
|
dwdm:AOptChnlIfPol Abstract class for all the profiles for DWDM C optic channel that can be applied |
|
|
|
|
|
|
├
|
|
dwdm:IfPol DWDM policy that can be applied at interface level |
|
|
|
|
|
|
├
|
|
lacp:LagPol The PortChannel policy enables you to bundle several physical ports together to form a single port channel. LACP enables a node to negotiate an automatic bundling of links by sending LACP packets to the peer node. |
|
|
|
|
|
├
|
|
lacp:IfPol The PortChannel interface policy defines a common configuration that will apply to one or more LACP interfaces. |
|
|
|
|
|
├
|
|
lldp:AIfPol A summary of the interface policy. We recommend you include information about where and when the policy should be used. The abstraction can be up to 128 characters. |
|
|
|
|
|
|
├
|
|
lldp:IfPol The LLDP interface policy, which defines a common configuration that will apply to one or more LLDP interfaces. LLDP uses the logical link control (LLC) services to transmit and receive information to and from other LLDP agents. |
|
|
|
|
|
|
|
├
|
|
netflow:ExporterPolDef Define the Netflow Exporter Policy MO which contains
internal information needed to program the leaf |
|
|
|
|
|
|
├
|
|
netflow:MonitorPolDef Define the Netflow Monitor Policy MO which contains
internal information needed to program the leaf |
|
|
|
|
|
|
├
|
|
netflow:RecordPolDef Define the Netflow Record Policy MO which contains
internal information needed to program the leaf |
|
|
|
|
|
├
|
|
qos:ADppPol Define a Data Plane Policing policy. User is supposed
to use this in scenarios where the incoming traffic need
to be policed to certain levels |
|
|
|
|
|
|
├
|
|
qos:DppPol Define a Data Plane Policing policy. User is supposed
to use this in scenarios where the incoming traffic need
to be policed to certain levels |
|
|
|
|
|
|
├
|
|
qos:DppPolDef Define the Data Plane Policing MO which contains
internal information needed to program the leaf |
|
|
|
|
|
├
|
|
stp:AIfPol An abstraction of an spanning-tree protocol interface policy. This is applicable to leaf ports and n1000v distributed virtual switches. Extended chassis ports have BPDU guard filter enabled by default. |
|
|
|
|
|
|
├
|
|
stp:IfPol The Spanning-Tree Protocol (STP) interface policy defines a common configuration that will apply to one or more interfaces.
STP prevents loops from being formed when the interfaces are interconnected via multiple paths. Spanning-Tree Protocol implements the 802.1D IEEE algorithm by exchanging BPDU messages with other switches to detect loops, and then removes the loop by shutting down selected bridge interfaces. This algorithm guarantees that th... |
|
|
|
|
|
|
├
|
|
stp:IfPolDef The read-only copy of the spanning-tree protocol interface policy. |
|
|
|
|
|
├
|
|
arp:AIfPol This object holds arp information that is operated at a
interface level |
|
|
|
|
|
├
|
|
bfd:AIfPol Interface-level bfd abstraction policy |
|
|
|
|
|
├
|
|
eigrp:IfPol The EIGRP interface policy, which defines a common configuration that will apply to one or more EIGRP interfaces. |
|
|
|
|
|
├
|
|
nd:AIfPol The neighbor discovery interface policy defines a common configuration that will apply to one or more neighbor discovery interfaces. |
|
|
|
|
|
|
├
|
|
nd:IfPol The neighbor discovery interface policy defines a common configuration that will apply to one or more neighbor discovery interfaces. |
|
|
|
|
|
|
├
|
|
nd:IfPolDef The read only copy of the neighbor discovery interface policy. |
|
|
|
|
|
├
|
|
nd:APfxPol The neighbor discovery prefix policy. |
|
|
|
|
|
|
├
|
|
nd:PfxPol The neighbor discovery prefix policy. |
|
|
|
|
|
|
├
|
|
nd:PfxPolDef The neighbor discovery prefix policy definition. |
|
|
|
|
|
├
|
|
ospf:IfPol The OSPF interface-level policy information. |
|
|
|
|
|
|
├
|
|
pim:IfPol Interface-level PIM-SM (sparse mode) policy. |
|
|
|
|
|
├
|
|
dns:Prof The DNS instance information. |
|
|
|
|
|
├
|
|
dns:Profile The DNS profile defines a set of DNS providers and can be deployed to a switch for tenant contexts. To deploy a DNS profile on a switch, the appropriate label has to be defined for the context deployed on switch. |
|
|
|
|
|
├
|
|
edr:ErrDisRecoverPol The error disabled recovery policy specifies the policy for re-enabling a port that was disabled due to one or more pre-defined error conditions. |
|
|
|
|
|
├
|
|
ep:LoopProtectP The endpoint loop protection policy specifies how loops detected by frequent mac moves are handled. |
|
|
|
|
|
|
├
|
|
l2:InstPol The Layer 2 instance policy is used for configuring fabric-wide layer 2 settings. Currently, this policy contains only fabric MTU and management MTU configuration. |
|
|
|
|
|
├
|
|
span:ADest The abstraction of an SPAN destination. The SPAN destination is where network traffic is sent for analysis by a network analyzer. A SPAN destination can be local or remote (ERSPAN). When you create a traffic monitoring session, you must select a SPAN source and a SPAN destination. The type of session (Tenant, Access, or Fabric) determines the allowed types of SPAN sources and destinations. The destination can be either a port or an endpoint group... |
|
|
|
|
|
|
├
|
|
span:AVDest The abstraction of a VSPAN destination. The VSPAN destination is where network traffic is sent for analysis by a network analyzer. A VSPAN destination can be local or remote (VERSPAN). When you create a traffic monitoring session, you must select a VSPAN source and a VSPAN destination. The type of session (Tenant, Access, or Fabric) determines the allowed types of VSPAN sources and destinations. The destination can be either a port or an endpoint... |
|
|
|
|
|
|
|
├
|
|
span:VDest The VSPAN destination is where network traffic is sent for analysis by a network analyzer. A VSPAN destination can be local or remote (VERSPAN). When you create a traffic monitoring session, you must select a VSPAN source and a VSPAN destination. The type of session (tenant, access, or fabric) determines the allowed types of VSPAN sources and destinations. The destination can be either a port or an endpoint group. If the destination is a port, it... |
|
|
|
|
|
|
|
├
|
|
span:VDestDef The VLAN-based SPAN (VSPAN) destination definition. |
|
|
|
|
|
|
├
|
|
span:Dest The SPAN destination is where network traffic is sent for analysis by a network analyzer. A SPAN destination can be local or remote (ERSPAN). When you create a traffic monitoring session, you must select a SPAN source and a SPAN destination. The type of session (Tenant, Access, or Fabric) determines the allowed types of SPAN sources and destinations. The destination can be either a port or an endpoint group. If the destination is a port, it shoul... |
|
|
|
|
|
├
|
|
span:ASrcGrp The abstraction of a SPAN source group. The SPAN source group can contain a group of SPAN sources, which is where network traffic is sampled. A SPAN source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (Access SPAN), a Layer 2 bridge domain, or a Layer 3 context (Fabric SPAN). When you create a traffic monitoring session, you must select a SPAN source group and a SPAN destination. The type of session (Tenan... |
|
|
|
|
|
|
├
|
|
span:SrcGrp The SPAN source group can contain a group of SPAN sources. A SPAN source is where network traffic is sampled. A SPAN source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (access SPAN), a Layer 2 bridge domain, or a Layer 3 context (Fabric SPAN). When you create a traffic monitoring session, you must select a SPAN source group and a SPAN destination. The type of session (Tenant, Access, or Fabric) determines... |
|
|
|
|
|
|
├
|
|
span:SrcGrpDef The SPAN source group definitions. The SPAN source is where traffic is sampled. A SPAN source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (access SPAN), a Layer 2 bridge domain, or a Layer 3 context (fabric SPAN). When you create a traffic monitoring session, you must select a SPAN source and a SPAN destination. The type of session (Tenant, Access or fabric) determines the allowed types of SPAN sources an... |
|
|
|
|
|
├
|
|
span:AVDestGrp The abstraction of a VSPAN destination group. The VSPAN destination group can contain a group of VSPAN destinations. A VSPAN destination is where network traffic is sent for analysis by a network analyzer. A VSPAN destination can be local or remote (VERSPAN). When you create a traffic monitoring session, you must select a VSPAN source and a VSPAN destination. The type of session (Tenant, Access, or Fabric) determines the allowed types of VSPAN so... |
|
|
|
|
|
|
├
|
|
span:VDestGrp The VSPAN destination group contains a group of VSPAN destinations. A VSPAN destination is where network traffic is sent for analysis by a network analyzer. A VSPAN destination can be local or remote (VERSPAN). When you create a traffic monitoring session, you must select a VSPAN source and a VSPAN destination. The type of session (tenant, access, or fabric) determines the allowed types of VSPAN sources and destinations. The destination can be ei... |
|
|
|
|
|
|
├
|
|
span:VDestGrpDef VSPAN destination group used for configuring VSPAN source group definitions. |
|
|
|
|
|
├
|
|
span:AVSrcGrp The abstraction of a VSPAN source group. The VSPAN source group can contain a group of VSPAN sources. A VSPAN source is where network traffic is sampled. A VSPAN source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (Access VSPAN), a Layer 2 bridge domain, or a Layer 3 context (Fabric VSPAN). When you create a traffic monitoring session, you must select a VSPAN source group and a VSPAN destination. The type ... |
|
|
|
|
|
|
├
|
|
span:VSrcGrp The VSPAN source group can contain a group of VSPAN sources. A VSPAN source is where network traffic is sampled. A VSPAN source can be an endpoint group (EPG), one or more ports; or port traffic filtered by an EPG (access VSPAN), a Layer 2 bridge domain, or a Layer 3 context (fabric VSPAN). When you create a traffic monitoring session, you must select a VSPAN source group and a VSPAN destination. The type of session (tenant, access, or fabric) de... |
|
|
|
|
|
├
|
|
span:DestGrp The SPAN destination group contains a group of SPAN destinations. A SPAN destination is where network traffic is sent for analysis by a network analyzer. A SPAN destination can be local or remote (ERSPAN). When you create a traffic monitoring session, you must select a SPAN source and a SPAN destination. The type of session (Tenant, Access, or Fabric) determines the allowed types of SPAN sources and destinations. The destination can be either a p... |
|
|
|
|
|
├
|
|
span:SpanProv The SPAN destination provider is used for configuring SPAN destination provider parameters. |
|
|
|
|
|
├
|
|
span:VSpanProv The VSPAN destination provider is used for configuring VSPAN destination provider parameters. |
|
|
|
|
|
├
|
|
stp:InstPol The spanning Tree Protocol (STP) instance policy, which enables you to set the bridge protocol data unit (BPDU) guard policy or filter. BDPUs are packets that run the STP protocol. The specification for STP is IEEE 802.1D. The main purpose of STP is to ensure that you do not create loops when you have redundant paths in your network. Loops are deadly to a network. |
|
|
|
|
|
├
|
|
vpc:InstPol The node-level vPC domain policy, which is used to specify a vPC domain and is applied to both vPC peer devices, the vPC peer keepalive link, the vPC peer link, and all the PortChannels in the vPC domain connected to the downstream device. You can have only one vPC domain ID on each device. |
|
|
|
|
|
├
|
|
bgp:InstPol The BGP Instance level policy is used to configure MP-BGP policies inside the fabric. |
|
|
|
|
|
├
|
|
dhcp:ARelayP The abstract DHCP Relay profile, which is used for configuring relay parameters per bridge domain (BD). |
|
|
|
|
|
|
├
|
|
dhcp:RelayP The DHCP relay profile, with one or more helper addresses in it, configures a DHCP relay agent for forwarding DHCP packets to a remote server. |
|
|
|
|
|
├
|
|
psu:InstPol The power redundancy policy is for all power supply units on the fabric nodes (leaves and spines) that are consuming the power supply policy through their respective selector profile policy. |
|
|
|
├
|
|
lbp:Pol The load balancing policy options for balancing traffic among the available uplink ports. Static hash load balancing is the traditional load balancing mechanism used in networks where each flow is allocated to an uplink based on a hash of its 5-tuple. This load balancing gives a distribution of flows across the available links that is roughly even. Usually, with a large number of flows, the even distribution of flows results in an even distributi... |
|
|
|
├
|
|
fc:AllocEncapCont Represents the container object used for managing Fibre Channel Encap Block |
|
|
├
|
|
fc:APinningLbl Fiber Channel Pinning Label. Its used for pinning host interfaces to uplink interfaces. This label should match with the name of a fc:PinningP configured this tenant or tenant-commmon. Once this label is configured under a fv:RsFcPathAtt, that host interface will get pinned to the uplink interfaces specified in the Pinning profile. |
|
|
├
|
|
fc:APinningP Abstract Fiber Channel Pinning Profile. Its used for pinning host interfaces to uplink interfaces. |
|
|
|
├
|
|
fc:PinningP Fiber Channel Pinning Profile. Its used for pinning host interfaces to uplink interfaces. |
|
|
|
├
|
|
fc:PinningPDef Fiber Channel Pinning Profile Definition. Its used for pinning host interfaces to uplink interfaces. |
|
|
├
|
|
fc:ResPolCont Container for resolved Fiber Channel policies in node |
|
|
├
|
|
firmware:AFwP The firmware policy specifies the desired firmware version. |
|
|
|
├
|
|
firmware:FwP The firmware specification policy for a node. |
|
|
├
|
|
firmware:RepoP The firmware repository population and maintenance information. |
|
|
├
|
|
fmcast:SystemGIPoPol Used for enabling usage of configured system GIPo in the fabric (includes all the PODs).
@@@ In previous releases system GIPo was hardcoded and was not usable for Multipod scenarios.
@@@ In Congo, PE/APIC changes were done for configuring new system GIPo value but NXOS changes
@@@ were slipped out of Congo. Now we are introducing this knob to start using configured system
@@@ ... |
|
|
├
|
|
fv:AESgSelDefCont Abstract Container to hold the Selector Definition objects for an ESg |
|
|
|
├
|
|
fv:FabricExtConnPDef Site Connectivity Profile Definition
@@@ PE will pull FabricExtConnPDef. An Outside pushed to spine will pull it. |
|
|
├
|
|
fv:AIntersiteConnP Abstract Class Container for Connectivity Information for MultiSite deployments |
|
|
|
├
|
|
fv:IntersiteConnP Container for Unicast Connectivity Information for MultiSite deployments |
|
|
├
|
|
fv:AIntersiteConnPDef Abstract Class Container Def for Connectivity Information for MultiSite deployments |
|
|
├
|
|
fv:APathAtt An abstraction of the path the endpoint group configuration will be deployed on. |
|
|
|
├
|
|
fv:ExtStPathAtt The path the endpoint group configuration will be deployed on. |
|
|
|
├
|
|
fv:StPathAtt The path the endpoint group configuration is deployed on. |
|
|
|
├
|
|
fv:VNodeAtt Represent a Path on whom the EPG configuration
will be deployed.
It represents Virtual Node Attachment. If only this type of attachement is
present under an EpP then the EpP will not get instrumented on that node.
But together with VNodeAtt if any other type of PathAtt is present then EpP
will get instrumented as usual |
|
|
|
├
|
|
fv:PathEpDef The node and interface, or a group of interfaces, that the endpoint group is deployed on. This is an internal object used for tracking static endpoint group deployment. |
|
|
├
|
|
fv:AVip Abstraction of Virtual IP address |
|
|
├
|
|
fv:AccP The bridge domain (BD) access profile. When created over a BD, contracts are not enforced for the BD, and the encap will be applied to all endpoint groups on this BD. |
|
|
├
|
|
fv:BDHolder The bridge domain (BD) holder contains bridge domain related information. For example, in a same shared service scenario, when a context is
deployed on a node, the PE needs to get all subnets of all the associated BDs. In this case, the private Layer 3 network context contains DNs of all associated BDs,
and with that info, the node pulls down the corresponding bridge domain holders of each of the associated BDs. The bridge domain holder contai... |
|
|
├
|
|
fv:ConnInstrPol Every endpoint group should have a relation set to its bridge domain. If not set by the user, then the relation is set to the default Bridge Domain and the Connectivity Instrumentation Policy determines whether or not traffic will be allowed to flow to/from that EPG. This applies to all EPGs regardless of use (VMM, baremetal, L2ext, L3ext). There is also a relation from the Bridge Domain to the VRF. If this is not set by the user, then the defaul... |
|
|
├
|
|
fv:EPgCont An endpoint group container is an internal object that represents endpoint groups. |
|
|
|
├
|
|
fv:AEPgCont An abstract container class for endpoint groups. This is an abstract class and cannot be instantiated |
|
|
|
├
|
|
fv:EPgDef An internal object that represents endpoint groups is used for deployment. |
|
|
|
|
├
|
|
fv:AEPgDef Abstract representation of an endpoint group definition. |
|
|
|
|
|
├
|
|
dhcp:ProvDhcp Internal object that points to the provider details of a DHCP relay profile. |
|
|
|
|
|
├
|
|
fv:AEpP Abstract representation of an endpoint profile. |
|
|
|
|
|
|
├
|
|
fv:AREpP Abstract representation of the resolvable endpoint profile. This is an abstract class and cannot be instantiated. |
|
|
|
|
|
|
|
├
|
|
fv:AMgmtEpP Abstract representation of the management endpoint policy for a fabric node management endpoint group. This is an abstract class and cannot be instantiated. |
|
|
|
|
|
|
|
|
├
|
|
fv:InBEpP An in-band management endpoint profile for a fabric node management endpoint group. |
|
|
|
|
|
|
|
|
├
|
|
fv:InstPEpP Instance Profile Management EpP for the Fabric Node Management EPG. This EpP is created per external management entity instance profile (InstP EPg). |
|
|
|
|
|
|
|
|
├
|
|
fv:OoBEpP An out-of-band management endpoint profile for a fabric node management endpoint group. |
|
|
|
|
|
|
|
├
|
|
fv:ExtEpP Abstraction of a profile created for an endpoint connected to an external router or switch. |
|
|
|
|
|
|
|
|
├
|
|
fv:BrEpP The bridge endpoint profile represents L2 outside present under a tenant. |
|
|
|
|
|
|
|
|
├
|
|
fv:RtdEpP A target relation to an L3 routed outside present under a tenant. |
|
|
|
|
|
|
|
├
|
|
fv:SvcEpP Abstract representation of a service endpoint profile, such as an endpoint profile created per node in the service graph. |
|
|
|
|
|
├
|
|
span:ADestSummary The abstraction of a SPAN destination information summary, which is used for configuring the SPAN destination information summary. |
|
|
|
|
|
|
├
|
|
span:AEpgSummary The abstraction of a SPAN destination endpoint group (EPG) summary, which stores EPG information for SPAN. |
|
|
|
|
|
├
|
|
vz:ACtrctEpgDef An endpoint group associated with a contract can be provider or consumer. |
|
|
|
|
|
|
├
|
|
vz:ToEPg The destination endpoint group. |
|
|
|
|
├
|
|
fv:ProtEPg An endpoint group associated with a taboo policy in a given context. This is an internal object. |
|
|
|
|
├
|
|
vz:FromEPg The endpoint group that traffic originates from. |
|
|
├
|
|
fv:EpCP A container to hold criterion definition objects for an endpoint group. |
|
|
├
|
|
fv:PolDeliveryStatus Status of policy deployment indicates if APIC has delivered/is delivering policy to node - Policy to node cannot be delivered (node is a spine). |
|
|
├
|
|
fv:PolMod A bridge domain policy modifier that can override the desired state of the bridge domain. |
|
|
├
|
|
fv:RemotePolHolder A container existing on each node to efficiently download policies to the node. For example: filters, bridge domain, and taboo policies. This is an internal object. |
|
|
├
|
|
fv:RtdEpPInfoCont A container for target relations that point to a Layer 3 routed outside and present under a tenant. |
|
|
├
|
|
fv:RtdEpPInfoHolder A container for target relations to a Layer 3 routed outside and present under a tenant. |
|
|
├
|
|
fv:SlaDef IPSLA Policy Definition
@@@ PE will pull IPSLA Def Mo |
|
|
├
|
|
fv:UnkMacUcastActMod This is the bridge domain (BD) Policy Modifier for UnkMacUcastAct. In special cases, the BD Policy Modifier can override the desired state of BD. |
|
|
├
|
|
geo:Site The geographical site of the fabric node. |
|
|
├
|
|
health:EvalP The health score evaluation policy indicates the severity of the fault in percentages. |
|
|
├
|
|
health:LevelsP The severity of a health score, such as healthy, fair, or poor. |
|
|
├
|
|
iacl:AProfile Abstract class for all the profiles for CoPP Prefilters that can be applied at the node level |
|
|
├
|
|
infrazone:ZoneP Infrastructure Zoning Profile: This profile can be used for carving out policy deployment zones in the fabric. With zones, user can push policies to different zones at different times to prevent or minimize fabric downtime |
|
|
├
|
|
l3ext:RtdCtxDefRef Mo that will be attached to retrieve the DN of the
RtdCtxDef that should be downloaded on the leaf in
order to program the leaf |
|
|
├
|
|
l3ext:RtdOutDefRef Reference to the Routed Out Definition associated with this RtdEpP.
Existence of this mo under RtdEpP is also used as an indicator that
the RtdEpP is version 2 (i.e. pruned) RtdEpP.
|
|
|
|
├
|
|
leak:RouteCont This MO is created under the "from fvCtxDef" with a reference to
the "from fvCtxDef" and contain the list of routes to be leaked
when using Shared Services and ESg. |
|
|
|
├
|
|
leak:RouteFromToCont This MO is created under the leakContDef and describe the route
leak for each To/From CtxDef pair.
When the leakTo configuration is created, the to CtxDef might not
have been created/configured yet. This Mo holds the information
until the correspondent CtxDef is created |
|
|
├
|
|
leak:ContDef Resolved Route leak model section This MO is created for each Shard and hold the RouteFromToCont
information that need to be configured |
|
|
├
|
|
mock:Counter This is generated and used only by internal processes |
|
|
├
|
|
mock:MockRoot This is generated and used only by internal processes |
|
|
├
|
|
mock:Stats This is generated and used only by internal processes |
|
|
├
|
|
mon:Pol The base monitoring policy model. |
|
|
|
├
|
|
mon:CommonPol The monitoring policy model for the common semantic scope, which is used when there is no corresponding policy under the more specific infra or tenant scopes. In such cases, these policies are used throughout the fabric except for objects attached to their own specific policies. |
|
|
|
├
|
|
mon:EPGPol Creates a container for monitoring policies associated with the tenant. This allows you to apply tenant-specific policies related to Stats Collection, Stats Export, Callhome/SNMP/Syslog, Event Severities, Fault Severities, and Fault Lifecycles. |
|
|
|
├
|
|
mon:FabricPol Creates a policy which acts as a container for associated fabric monitoring policies. These can include policies related to Event/Fault severity, the Fault lifecycle, and other such monitoring policies. |
|
|
|
├
|
|
mon:InfraPol Creates a policy which acts as a container for associated fabric monitoring policies. These can include policies related to Event/Fault severity, the Fault lifecycle, and other such monitoring policies. |
|
|
├
|
|
netflow:ExporterPolHolder Mo that will be attached to retrieve the DN of the
NetflowExporterPolDef that should be downloaded on the leaf in
order to program the leaf |
|
|
├
|
|
netflow:MonitorPolHolder Mo that will be attached to retrieve the DN of the
NetflowMonitorPolDef that should be downloaded on the leaf in
order to program the leaf |
|
|
├
|
|
pki:Definition This is an abstract class and cannot be instantiated. |
|
|
|
├
|
|
pki:CsyncElement The file pattern, the type of pattern (include or exclude), and the symbolic name of the pattern. |
|
|
|
├
|
|
pki:Ep The PKI configuration, which includes key rings and certificate authority (CA) credentials. Components of the PKI are used to establish secure communications between two devices. |
|
|
|
├
|
|
pki:FabricIssuedSSLCertificate
Object representing x509 certificates issued by the APIC for a node in the Fabric
This object is implicitly created and cannot be deleted or exported in the configuration
|
|
|
|
├
|
|
pki:FabricNodeSSLCertificate
Object representing a Cisco issued x509 certificate for a node in the Fabric
This object is implicitly created and cannot be deleted or exported in the configuration
|
|
|
|
├
|
|
pki:Item This is an abstract class and cannot be instantiated. |
|
|
|
|
├
|
|
pki:KeyRing A keyring to create and hold an SSL certificate. The SSL certificate contains the public RSA key and signed identity information of a PKI device. The PKI device holds a pair of RSA encryption keys, one kept private and one made public, stored in an internal key ring. The keyring certificate merges into the PKI device keyring to create a trusted relationship. |
|
|
|
|
├
|
|
pki:TP A trustpoint (certificate authority/CA), which issues and validates (signs) digital certificates. When participating in secure communications using the public key infrastructure (PKI), a participant can verify the identity of the other party through the CA that signed the other party's public key. |
|
|
|
├
|
|
pki:WebTokenData The cryptographic data used for generating and verifying web tokens. |
|
|
|
|
|
├
|
|
infra:ProfileIssues Infrastructure Profile Configuration Issues. The delegatable class is infra:Profile, which should be a super
class of all infra profiles such as Attachable Profile, Node Profile, Port Profile, Function Profile, etc. |
|
|
|
|
├
|
|
fabric:OosPathIssues An object used for reporting configuration issues related to port out-of-service policy. |
|
|
|
├
|
|
fv:AConfIssues The configuration issues found during the endpoint profile instrumentation in the node. This is an abstract class and cannot be instantiated. |
|
|
|
|
|
├
|
|
fv:CompIssues The compute configuration issues for each endpoint profile. |
|
|
|
|
|
├
|
|
fv:NwIssues The network configuration issues for each endpoint profile. |
|
|
|
|
|
├
|
|
fv:StorageIssues Represents the storage configuration issues for each endpoint profile. |
|
|
├
|
|
pol:ConsElem Represents a policy consumption qualifier element. |
|
|
|
├
|
|
pol:If Represents an interface exposed or consumed by a policy. |
|
|
|
|
├
|
|
pol:ProvIf Represents a function or service provider interface. |
|
|
|
|
├
|
|
vz:AIf The abstraction of an interface. A contract interface and bundle interface inherits from this class. |
|
|
|
|
|
├
|
|
vz:CPIf A contract interface is used as a contract consumption interface when
a consumer consumes the contract by associating it to a consumption interface
provided by the provider in the consumer's domain. A consumer can associate
with the contract consumption interface when it is provided by the provider in the consumer's
domain.
Note that a contract consumption interface represents one or more subjects defined under the
contract. By associating... |
|
|
|
├
|
|
pol:Lbl Represents a policy label. |
|
|
|
|
├
|
|
dhcp:ALbl The identification of the DHCP provider. If the owner is the tenant, then the label is matched with the
DHCP label present under the bridge domain (BD). If the owner is the infra, then the label is matched with the DHCP label
present under the infra (and associated with the node). If n providers match the label, then all of them get configured as relay. |
|
|
|
|
|
├
|
|
dhcp:Lbl A DHCP relay label contains a name for the label, the scope, and a DHCP option policy. The scope is the owner of the relay server and the DHCP option policy supplies DHCP clients with configuration parameters such as domain, nameserver, and subnet router addresses. |
|
|
|
|
|
├
|
|
dns:Lbl The network domain name label. Labels enable classifying which objects can and cannot communicate with one another. |
|
|
|
|
├
|
|
extnw:ALIfP An abstract logical interface profile. This object defines the characteristics that will be applied to resources that match with the profile name. |
|
|
|
|
|
├
|
|
l2ext:AIfP The abstraction of an interface profile. |
|
|
|
|
|
|
├
|
|
l2ext:LIfP The logical interface profile defines a common configuration that can be applied to one or more interfaces. |
|
|
|
|
|
|
├
|
|
l2ext:LIfPDef The interface identifiers attached to the node profile. |
|
|
|
|
|
├
|
|
l3ext:AIfP An abstract interface profile. This encapsulates common behavior / configuration that will apply to one or more L3 external interfaces. |
|
|
|
|
|
|
├
|
|
l3ext:LIfP The logical interface profile, which defines a common configuration that can be applied to one or more interfaces. |
|
|
|
|
|
|
├
|
|
l3ext:LIfPDef The interface identifiers attached to the node profile. |
|
|
|
|
|
├
|
|
l2ext:ALNodeP An abstract logical node profile. This defines the characteristics to be applied to resources that match with the profile name. |
|
|
|
|
|
|
├
|
|
l2ext:LNodeP The logical node profile defines a common configuration that can be applied to one or more leaf nodes. |
|
|
|
|
|
|
├
|
|
l2ext:LNodePDef The logical node profile definition. This defines the characteristics to be applied to resources that match with the profile name. |
|
|
|
|
|
├
|
|
l3ext:AConsLbl Represents Abstraction of Logical Outside Profile Consumer Label. Defines the characteristics that
will be applied to Layer3 Outside that matches with the label name |
|
|
|
|
|
|
├
|
|
l3ext:ConsLbl Represents Logical Outside Profile Consumer Label. Defines the characteristics that
will be applied to Layer3 Outside that matches with the label name |
|
|
|
|
|
|
├
|
|
l3ext:ConsLblDef Represents Logical Outside Profile Consumer Label Definition. Defines the characteristics that
will be applied to Layer3 Outside that matches with the label name |
|
|
|
|
|
├
|
|
l3ext:ALNodeP An abstract logical node profile. This defines the characteristics to be applied to resources that match with the profile name. |
|
|
|
|
|
|
├
|
|
l3ext:LNodeP The logical node profile defines a common configuration that can be applied to one or more leaf nodes. |
|
|
|
|
|
|
├
|
|
l3ext:LNodePDef The logical node profile definition. This defines the characteristics to be applied to resources that match with the profile name. |
|
|
|
|
|
├
|
|
rtctrl:LNodeP The node classification criteria for the route control context. |
|
|
|
|
├
|
|
infra:Lbl The tenant or provider characteristics of the port. |
|
|
|
|
|
├
|
|
infra:IfLblDef The tenant/provider's external connection characteristics of the port. |
|
|
|
|
|
├
|
|
infra:NodeLblDef The tenant or provider's external connection characteristics of the port. |
|
|
|
|
├
|
|
l3ext:AProvLbl Represents Abstraction of Logical Outside Profile Provider Label. Defines the characteristics that
will be applied to Layer3 Outside that matches with the label name |
|
|
|
|
|
├
|
|
l3ext:ProvLbl Represents Logical Outside Profile Provider Label. Defines the characteristics that
will be applied to Layer3 Outside that matches with the label name |
|
|
|
|
|
├
|
|
l3ext:ProvLblDef Represents Logical Outside Profile Label Definition. Defines the characteristics that
will be applied to Layer3 Outside that matches with the label name |
|
|
|
|
|
├
|
|
vsvc:AConsLbl This is generated and used only by internal processes. |
|
|
|
|
├
|
|
pol:ProvLbl Represents a function or service provider label. |
|
|
|
|
|
├
|
|
span:SpanLbl The SPAN label is used for SPAN label parameters. |
|
|
|
|
├
|
|
vz:ALbl The labels for filtering subjects. |
|
|
|
|
|
|
|
├
|
|
vz:ProvSubjLblDef A provider subject label definition. A subject label is used as a classification criteria for subjects being consumed/provided by the endpoint groups (EPGs) participating in the contract. The label identifies a subject being consumed by a consumer. It can be parented by 2 different methods. The first method is the relation between the consumer EPG and the contract that is used for filtering the subjects. A label should match either the subject na... |
|
|
|
|
|
|
├
|
|
vz:ConsSubjLbl A consumer subject label. In general, a subject label is used as a classification criteria for subjects being consumed/provided by the endpoint groups (EPGs) participating in the contract. The label identifies a subject being consumed by a consumer. It can be parented by 2 different methods. The first method is the relation between the consumer EPG and the contract that is used for filtering the subjects. A label should match either the subject n... |
|
|
|
|
|
|
├
|
|
vz:ProvLbl A label used by a provider for specifying its identity. The parent can be either the provider endpoint group or the relation between the provider endpoint group and a contract. A consumer with no label will consume from all the providers of the contract regardless of the provider label. A consumer with a specific label can only consume from providers matching the label. |
|
|
|
|
|
|
├
|
|
vz:ProvSubjLbl A subject label is used as classification criteria for subjects being consumed/provided by the endpoint groups (EPGs) participating in the contract. The label identifies a subject being provided by a provider. It can be parented by 2 different methods. The first method is the relation between the provider EPG and the contract that is used for filtering the subjects. A label should match either the subject name or the label present under the subje... |
|
|
|
|
|
├
|
|
vz:ALblDef An abstraction of a label definition. |
|
|
|
|
|
├
|
|
vz:ConsCtrctLbl A consumer contract label. A contract label can be parented by the relation between an endpoint group (EPG) and security group. The EPG is associated with a group and lists all contracts it provides out of the group, as well as, optionally, contracts that it chooses to consume. If no consumption contracts are indicated, all contracts are consumed. If no provider contracts are identified, the EPG provides no contracts out of this group. |
|
|
|
|
|
├
|
|
vz:ConsLbl A label used by consumers to filter the providers. The label can be parented as follows:
By the consumer endpoint group.
By the relation between the consumer endpoint group and contract.
By the relation between the contract interface and contract.
By the relation between the consumer endpoint group and contract interface.
A consumer with no label will consume from all the providers of the contract with no labels. A consumer with a specific label... |
|
|
|
|
|
├
|
|
vz:ProvCtrctLbl A label identifying a contract. A contract label can be parented by the relation between an endpoint group (EPG) and security group. The EPG is associated with a group and lists all contracts it provides out of the group, as well as, optionally, contracts that it chooses to consume. If no consumption contracts are indicated, all contracts are consumed. If no provider contracts are identified, the EPG provides no contracts out of this group. |
|
|
├
|
|
pol:DefRoot Represents the policy definition's subtree root. |
|
|
|
├
|
|
fv:Def An abstraction of the fabric virtualization policy definition. |
|
|
|
|
|
|
├
|
|
fv:AACrtrn Abstraction of Classifier used for Virtual Devices |
|
|
|
|
|
|
|
├
|
|
fv:ACrtrn An abstraction of the classifier used for virtual devices. |
|
|
|
|
├
|
|
fv:Attr The attributes in the criterion. |
|
|
|
|
|
|
|
├
|
|
fv:ProtoAttr The Layer 4 protocol attributes in the criterion. |
|
|
|
|
|
|
├
|
|
fv:AVmAttr The virtual attributes in the criterion. |
|
|
|
|
|
|
|
├
|
|
fv:VmAttr The virtual attributes in the criterion. |
|
|
|
|
├
|
|
fv:Dom A virtual fabric domain. |
|
|
|
|
|
|
├
|
|
fv:ABD An abstract representation of a private layer 2 network context that belongs to a specific tenant or context, or is shared. This is an abstract class and cannot be instantiated. |
|
|
|
|
|
|
|
├
|
|
fv:ABDPol Abstract representation of a bridge domain policy. |
|
|
|
|
|
|
|
|
├
|
|
fv:BD A bridge domain is a unique layer 2 forwarding domain that contains one or more subnets. Each bridge domain must be linked to a context. |
|
|
|
|
|
|
|
├
|
|
fv:BDDef A private layer 2 network context that belongs to a specific tenant or context, or is shared. |
|
|
|
|
|
|
├
|
|
fv:ACtx A private L3 network context belonging to a specific tenant. |
|
|
|
|
|
|
|
├
|
|
fv:Ctx The private layer 3 network context that belongs to a specific tenant or is shared. |
|
|
|
|
|
|
|
├
|
|
fv:CtxDef A private L3 network context belonging to a specific tenant. This is an internal representation of the context. |
|
|
|
|
├
|
|
fv:Np An abstraction representing a set of requirements a group of entities has on the virtualizable fabric. |
|
|
|
|
|
├
|
|
extnw:Out An abstraction of a policy controlling connectivity to outside such as another fabric or WAN. |
|
|
|
|
|
|
├
|
|
l2ext:Out The L2 outside policy controls connectivity to the outside. |
|
|
|
|
|
|
├
|
|
l3ext:Out The L3 outside policy controls connectivity to the outside. |
|
|
|
|
|
├
|
|
fv:Ap The application profile is a set of requirements that an application instance has on the virtualizable fabric. The policy regulates connectivity and visibility among endpoints within the scope of the policy. |
|
|
|
|
|
├
|
|
fv:Up A set of requirements for datacenter utility functions on virtualized fabric. |
|
|
|
|
|
|
|
├
|
|
fabric:InfrP An abstraction of the fabric infrastructure-level policy for either fabric internal or external behaviors |
|
|
|
|
|
|
|
|
├
|
|
fabric:InfrExP An abstraction of the set of rules pertaining to external fabric behavior |
|
|
|
|
|
|
|
|
|
├
|
|
infra:ExP An abstraction of an external profile. |
|
|
|
|
|
|
|
|
|
|
├
|
|
infra:ClP The infrastructure client profile object. |
|
|
|
|
|
|
|
|
├
|
|
fabric:InfrFP A set of rules pertaining to internal fabric behavior. |
|
|
|
|
|
|
|
|
├
|
|
mgmt:MgmtP The in-band and out-of-band management endpoint groups consists of switches (leaves/spines) and APICs.
Each node in the group is assigned an IP address that is dynamically allocated from the address pool associated with the corresponding
in-band or out-of-band management zone. |
|
|
|
|
|
├
|
|
infra:AIpP An abstraction of a resolvable infrastructure profile. |
|
|
|
|
|
|
├
|
|
infra:IpP A resolvable hypervisor infrastructure profile. |
|
|
|
|
|
├
|
|
mgmt:ExtMgmtEntity The external entity management. The external entities (hosts) can communicate with nodes that are part of the out-of-band (OOB)
management endpoint group. To enable this communication, hosts are connected to the OOB management port of the nodes. |
|
|
|
├
|
|
test:Rule An abstract class for a test rule. |
|
|
├
|
|
pol:Ns Represents a policy namespace. |
|
|
|
|
├
|
|
fvns:AddrInst The IP address namespace/IP address range contains unicast and multicast address blocks. |
|
|
|
|
├
|
|
fvns:McastAddrInstP The multicast address namespace policy defines the multicast IP address ranges.
These addresses can be used for various purposes, such as VxLAN encapsulation. |
|
|
|
├
|
|
fvns:AInstP The namespace policy is used for managing the Encap (VXLAN, NVGRE, VLAN) ranges. |
|
|
|
|
|
├
|
|
fvns:VlanInstP The VLAN range namespace policy defines for ID ranges used for VLAN encapsulation. |
|
|
|
|
|
├
|
|
fvns:VxlanInstP The VxLAN range namespace policy defines for ID ranges used for VLAN encapsulation |
|
|
|
|
├
|
|
stp:EncapInstDef The spanning-tree protocol encap instance profile definition. The segment IDs calculated using this profile are for spanning tree BPDU flooding within the fabric. It is implicitly managed by the IFC. |
|
|
├
|
|
pool:Pool An abstraction of a shared resource pool. |
|
|
├
|
|
qos:ADppPolHolder Mo that will be attached to retrieve the DN of the
qosDppPolDef that should be downloaded on the leaf in
order to program the leaf |
|
|
├
|
|
qos:Class The QoS classification traffic descriptor and specifications are used to categorize a packet within a specific group and making the packet accessible for QoS handling in the network. |
|
|
├
|
|
qos:CustomPol The custom QoS policy enables different levels of service to be assigned to network traffic, including specifications for the Differentiated Services Code Point (DSCP) value(s), and the 802.1p Dot1p priority. |
|
|
├
|
|
qos:CustomPolDef The definition class for a custom QOS policy. Note that this is an internal object. |
|
|
├
|
|
qos:DppPolDefCont Container for all the qos:DppPolDef, under top, to
have them neatly organized |
|
|
├
|
|
qos:InstPol A QOS instance policy, which is a container for QOS class objects. |
|
|
├
|
|
rtctrl:Profile The route control profile specifies policies for external networks. The layer 3 networks outside the fabric, and reachable by a Tenant's applications, route to external networks. |
|
|
├
|
|
snmp:APol An abstract representation of a policy. A profile contains site info and general protocol config parameters
(such as version and traps vs. informs). |
|
|
|
├
|
|
snmp:Inst A container for each SNMP instance. |
|
|
|
├
|
|
snmp:Pol The SNMP policy enables you to monitor client group, v3 user, and/or community SNMP policies.
SNMP is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network. |
|
|
├
|
|
span:ASrc The abstraction of an SPAN source. The SPAN source is where traffic is sampled. A source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (Access SPAN), a Layer 2 bridge domain, or a Layer 3 context (Fabric SPAN). When you create a traffic monitoring session, you must select a SPAN source and a SPAN destination. The type of session (Tenant, Access or fabric) determines the allowed types of SPAN sources and de... |
|
|
|
├
|
|
span:AVSrc The abstraction of a VSPAN source. The VSPAN source is where traffic is sampled. A VSPAN source can an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (Access VSPAN), a Layer 2 bridge domain, or a Layer 3 context (Fabric VSPAN). When you create a traffic monitoring session, you must select a VSPAN source and a VSPAN destination. The type of session (Tenant, Access or fabric) determines the allowed types of span sources... |
|
|
|
|
├
|
|
span:VSrc The VSPAN source, which is where traffic is sampled. A VSPAN source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (Access VSPAN), a Layer 2 bridge domain, or a Layer 3 context (Fabric VSPAN). When you create a traffic monitoring session, you must select a VSPAN source and a VSPAN destination. The type of session (Tenant, Access, or Fabric) determines the allowed types of VSPAN sources and destinations. The ... |
|
|
|
|
├
|
|
span:VSrcDef The VSPAN VSrcDef is used for VSPAN source definitions. |
|
|
|
├
|
|
span:Src The SPAN or ERSPAN source is where traffic is sampled. A source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (access SPAN), a Layer 2 bridge domain, or a Layer 3 context (fabric SPAN). When you create a traffic monitoring session, you must select a source and a destination. The type of session (tenant, access, or fabric) determines the allowed types of sources and destinations. The destination can be eithe... |
|
|
|
├
|
|
span:SrcDef The SPAN source definitions. The SPAN source is where traffic is sampled. A SPAN source can be an endpoint group (EPG), one or more ports, or port traffic filtered by an EPG (Access SPAN), a Layer 2 bridge domain, or a Layer 3 context (Fabric SPAN). When you create a traffic monitoring session, you must select a SPAN source and a SPAN destination. The type of session (tenant, access or fabric) determines the allowed types of SPAN sources and dest... |
|
|
├
|
|
statspref:Cont This objects hold information on stats preferences for various features |
|
|
|
├
|
|
stp:AllocEncapBlkDef The spanning-tree protocol encap block definition for allocated IDs and the base segment ID used for the range. These segment IDs are used for spanning tree BPDU flooding within the fabric. It is implicitly managed by the IFC. |
|
|
|
├
|
|
stp:UnAllocEncapBlkDef The spanning-tree protocol encap block definition for un-allocated IDs and the base Segment ID used for the range. These segment IDs are used for spanning tree BPDU flooding within the fabric. It is implicitly managed by the IFC. |
|
|
├
|
|
stp:AEncapCont An abstraction of a container for managing the spanning tree flooding segment ID range. |
|
|
|
├
|
|
stp:AllocEncapCont A container for managing the spanning tree flooding segment ID range. |
|
|
|
├
|
|
svccore:NodePol The core collection policy contains the system or component failure information. You can configure the policy to export a copy of the core file to a location on an external TFTP server as soon as the core file is created. |
|
|
├
|
|
sysmgrp:Def Abstract class for all QoS policy definitions. |
|
|
|
|
|
├
|
|
cloud:EPSelectorDef Cloud Endpoint Selector, to decide which endpointss belong
to the EPGs based on several parameters, different
selectors will be considered as OR |
|
|
|
|
|
├
|
|
cloud:ExtEPSelectorDef Cloud Endpoint Selector, to decide which endpointss belong
to the EPGs based on several parameters, different
selectors will be considered as OR |
|
|
|
|
├
|
|
cloud:EPSelector Cloud Endpoint Selector, to decide which endpointss belong
to the EPGs based on several parameters, different
selectors will be considered as OR |
|
|
|
|
├
|
|
cloud:ExtEPSelector Cloud Endpoint Selector, to decide which endpointss belong
to the EPGs based on several parameters, different
selectors will be considered as OR |
|
|
|
├
|
|
cloud:AEPgSelector EPG Selector to correlate the cloudEPg with the corresponding fvAEPg from which it can inherit all the security policies. This is optional |
|
|
|
├
|
|
fv:AEPSelector ######## MO-S ######## Base Class for ESg Endpoint Selectors to classify
endpoints that belong to a VRF-scope useg |
|
|
|
|
├
|
|
fv:EPSelector Endpoint Security Group Selector, to decide which endpoints belong
to the useg based on selector matching. Logical OR is
used across EPSelectors within a useg |
|
|
|
|
├
|
|
fv:EPSelectorDef Endpoint Security Group Selector, to decide which endpoints belong
to the useg based on selector matching. Logical OR is
used across EPSelectors within a useg |
|
|
|
├
|
|
traceroutep:TrEp The traceroute source is the endpoint source information of the traceroute connected to ToR. |
|
|
|
├
|
|
traceroutep:TrExtEp Traceroute an External IP address from an End Point learned as being connected to ToR |
|
|
|
├
|
|
traceroutep:TrNode The traceroute for a ToR node allows you to determine the path a packet takes to get to a destination from a given source by returning the sequence of hops the packet traversed. |
|
|
├
|
|
trig:Inst An abstraction of a generalized system trigger. |
|
|
├
|
|
trig:SchedP The scheduler policy enables you to schedule a recurring or one-time window for the execution of a task. Multiple scheduler policies can be created for the same time period. |
|
|
|
├
|
|
trig:SingleTriggerable A triggerable object that can be triggered only once for each instance of a scheduler window. |
|
|
|
|
├
|
|
callhome:InvTrig When you manually trigger an inventory alert group message and do not specify a destination profile name, a message is sent to all active profiles that have either a normal or periodic subscription to the specified alert group. |
|
|
|
|
├
|
|
dbgexp:TechSupTrig This object is managed internally and should not be modified by the user. |
|
|
|
|
├
|
|
maint:MaintTrig Triggerable object on which the scheduler triggers a callback for maintenance. |
|
|
|
├
|
|
trig:Test An internal object for testing if an object can be triggered. |
|
|
|
|
├
|
|
vns:AbsFuncConn An abstract function node connector is used to map a service graph interface with the device interface. |
|
|
|
├
|
|
vns:AbsConnection An abstract connection connects two abstract connectors. These connections can either be between two abstract nodes or between an abstract node and an abstract terminal node. |
|
|
├
|
|
vns:AGraph A service graph is an ordered set of function nodes between a set of terminals, which identifies a set of network service functions that are required by an application. Service functions within a graph are automatically provisioned on a service device that is based on an application's requirements. |
|
|
|
├
|
|
vns:AbsGraph The abstract graph is made up of abstract nodes and used to define the traffic flow through a service function such as load balancing, SSL offload, and firewall. Abstract nodes are comprised of service nodes such as a service node balancer (SLB) or firewall (FW), abstract term nodes (the nodes that are connected to endpoint groups), and connections. |
|
|
|
├
|
|
vns:GraphInst The instance of a service graph. All instance objects are implicit. |
|
|
|
|
|
├
|
|
vns:NodeInst An instance of a function node. A service graph consists of multiple function nodes.. |
|
|
|
|
|
├
|
|
vns:NodeInstDef An instance of the service node. This is an internal object. |
|
|
|
|
├
|
|
vns:AbsNode An abstract node represents a service node such as a server load balancer (SLB) or firewall (FW). An abstract node is contained in an abstract graph. |
|
|
|
|
├
|
|
vns:AbsTermNode An abstract terminal node. Abstract terminal nodes are typically attached to the endpoint groups, and are connected to the abstract graph (AbsGraph) through an abstract connection (AbsConnection). |
|
|
|
├
|
|
vns:StsVNode A VNode. Holds the resources allocated to render a node instance on a specific Cdev. |
|
|
|
├
|
|
vns:VNodeDef The virtual node definition. This object is used internally. |
|
|
├
|
|
vns:AbsDevCfg A shared configuration for a logical device in the L4-L7 device cluster. This configuration can be shared across multiple logical devices. |
|
|
├
|
|
vns:AbsFuncCfg The configuration for a function. This configuration can be shared across multiple functions. |
|
|
├
|
|
vns:AbsFuncProf An abstract function profile includes the abstract device configuration, the abstract group configuration, and the abstract function configuration. These are analogous to the function configuration, group configuration, and device configuration within a device. |
|
|
├
|
|
vns:AbsGrpCfg The shared configuration for a function group. This configuration can be shared across multiple logical groups. |
|
|
├
|
|
vns:BDDef A bridge domain definition for tracking allocated bridge domains. This is an internally used object. |
|
|
├
|
|
vns:CfgDef GraphInst contains a copy of the per logical device shared configuration. |
|
|
|
├
|
|
vns:DevCfgInst GraphInst contains a copy of the per logical device shared configuration. |
|
|
├
|
|
vns:EPgDef An object used to track allocated endpoint groups. This object is used internally. |
|
|
├
|
|
vns:SvcGraphVersion The version of the entire service graph model. This is validated against the device script APIC model version. This number is of the form x.y, where x represents the major version number and y represents the minor version number of the service graph model. Guidelines: 1. The minor version is increased whenever a backward compatible change is made. This could include adding new properties or managed objects in the service graph model. It is expect... |
|
|
├
|
|
vz:ACollection The abstraction of a contract collection. A collection can be a single contract, a collection of all contracts associated with a bundle, or a collection of all contracts associated with a group. |
|
|
|
├
|
|
vz:ACtrct An abstraction of a resolvable contract. |
|
|
|
|
├
|
|
vz:ABrCP An abstraction of a binary contract profile. |
|
|
|
|
|
├
|
|
vz:BrCP A contract is a logical container for the subjects which relate to the filters that govern the rules for communication between endpoint groups (EPGs). Without a contract, the default forwarding policy is to not allow any communication between EPGs but all communication within an EPG is allowed. |
|
|
|
|
|
├
|
|
vz:OOBBrCP An out-of-band binary contract profile can only be provided by an out-of-band endpoint group and can only be consumed by the external prefix set. A regular endpoint group cannot provide or consume an out-of-band contract profile. |
|
|
|
|
├
|
|
vz:Taboo A Taboo contract provides a way for an endpoint group to specify the subjects on which communication is not allowed. |
|
|
├
|
|
vz:ACollectionDef An abstraction of a collection definition. A collection is a contract |
|
|
├
|
|
vz:AContDef An abstraction of a container definition. |
|
|
|
├
|
|
vz:DirAssDef A direct association definition for a collection. A collection is a contract. |
|
|
├
|
|
vz:AFilterable An abstraction of a filter object. The filter object is a filter. |
|
|
|
|
├
|
|
actrl:Flt The filter rules identifying a group of filter entries. |
|
|
|
|
├
|
|
vz:AFilter An abstraction of a filter. A filter is a group of resolvable filter entries. Each filter entry is a combination of network traffic classification properties. Note that this relation is an internal object. |
|
|
|
|
|
├
|
|
vz:Filter A filter policy is a group of resolvable filter entries. Each filter entry is a combination of network traffic classification properties. |
|
