Product Id: 28925157
Description: Cisco Application Policy Infrastructure Controller Leaf - License - 1 switch (48 ports)
Mfr Part #: ACI-N9K-48X=
The Cisco Application Policy Infrastructure Controller (APIC) is a distributed system implemented as a cluster of controllers. The Cisco APIC provides a single point of control, a central API, a central repository of global data, and a repository of policy data for the Cisco Application Centric Infrastructure (ACI). Cisco ACI is conceptualized as a distributed overlay system with external endpoint connections controlled and grouped through policies. Physically, Cisco ACI is a high-speed, multipath leaf and spine (bipartite graph) fabric.
The Cisco APIC is a unified point of policy-driven configuration. The primary function of the Cisco APIC is to provide policy authority and policy resolution mechanisms for the Cisco ACI and devices attached to Cisco ACI. Automation is provided as a direct result of policy resolution and of rendering its effects onto the Cisco ACI fabric.
The Cisco APIC communicates in the infrastructure VLAN (in-band) with the Cisco ACI spine and leaf nodes to distribute policies to the points of attachment (Cisco leaf) and provide a number of key administrative functions to the Cisco ACI. The Cisco APIC is not directly involved in data plane forwarding, so a complete failure or disconnection of all Cisco APIC elements in a cluster will not result in any loss of existing datacenter functionality.
In general, policies are distributed to nodes as needed upon endpoint attachment or by an administrative static binding. You can, however, specify "resolutional immediacy", which regulates when policies are delivered into Cisco nodes. "Prefetch" or early resolution is one of the modes. The most scalable mode is the "just-in-time mode", in which policies are delivered to nodes just in time upon detection of the attachment. Attachment detection is based on analysis of various triggers available to the Cisco APIC.
A central Cisco APIC concept is to express application networking needs as an extension of application-level metadata through a set of policies and requirements that are automatically applied to the network infrastructure. The Cisco APIC policy model allows specification of network policy in an application- and workload-centric way. It describes sets of endpoints with identical network and semantic behaviors as endpoint groups. Policies are specified per interaction among such endpoint groups.
- Application centric network policies
- Data model-based declarative provisioning
- Application, topology monitoring, and troubleshooting
- Third-party integration (layer 4 through 7 services, storage, computing, WAN)
- Image management
- Cisco ACI inventory and configuration
- Implementation on a distributed framework across a cluster of appliances
- Scalable and flexible
A single Cisco APIC cluster supports over 1 million Cisco ACI endpoints, more than 200,000 ports, and more than 64,000 tenants and provides centralized access to Cisco ACI information through a number of interfaces, including an object-oriented RESTful API with XML and JSON bindings, a modernized user-extensible command-line interface (CLI), and a GUI. All methods are based on a model of equal access to internal information. Furthermore, Cisco APIC clusters are fully extensible to computing and storage management.
- Cisco APIC is not another NMS
The Cisco APIC is a network policy control system. However, it is not a network element management system and should not be mistaken for a manager of managers. Instead, it is designed to extend the manageability innovations of the Cisco ACI Fabric OS platform by augmenting it with a policy-based configuration model and providing end-to-end Cisco ACI global visibility. Cisco has cultivated a broad ecosystem of partners to work with the Cisco APIC and provide important functions.
- Virtual Cisco ACI context: securing tenants
A tenant is a logical container or a folder for application policies. It can represent an actual tenant, an organization, or a domain or can just be used for the convenience of organizing information. A normal tenant represents a unit of isolation from a policy perspective, but it does not represent a private network. A special tenant named "common" has sharable policies that can be used by all tenants. A context is a representation of a private layer 3 namespace or layer 3 network. It is a unit of isolation in the Cisco ACI framework. A tenant can rely on several contexts. Contexts can be declared within a tenant (contained by the tenant) or can be in the "common" tenant. This approach enables us to provide both multiple private Layer 3 networks per tenant and shared layer 3 networks used by multiple tenants. This way, we do not dictate a specific rigidly constrained tenancy model. The endpoint policy specifies a common Cisco ACI behavior for all endpoints defined within a given virtual Cisco ACI context.
- Endpoints and policy control
The Cisco ACI is conceptualized as a distributed overlay system with external endpoint connections controlled and grouped through policies. The central concept here is to group endpoints (EPs) with identical semantics into endpoint groups (EPGs) and then write policies that regulate how such groups can interact with each other. These policies provide rules for connectivity, visibility (access control), and isolation of the endpoints. The Cisco APIC's primary responsibility is distributing, tracking, and updating such policies to corresponding Cisco ACI nodes as client endpoint connectivity to the Cisco ACI is established, changed, or removed.
- Endpoint group contracts
The Cisco APIC policy model defines EPG "contracts" between EPGs that control the various parameters between application tiers such as connectivity, visibility, service insertion, packet quality of service (QoS), etc. A contract allows a user to specify rules and policies for groups of physical or virtual endpoints without understanding any specific identifiers or even who is providing the service or who is consuming it, regardless of the physical location of the devices. This abstraction of specificity makes the Cisco policy model truly object oriented and highly flexible. Each contract consists of a filtering construct, which is a list of one or more classifiers (IP address, TCP/UDP ports, etc. ), and an action construct that dictates how the matching traffic is handled.