A single ace device can be partitioned into multiple virtual appliance each managed as independent ace using rolr based access control RBAC. You can assign specific resources thru resource class to each virtual entity thru admin context. By default, the ACE initially provides you an Admin context, with the ability to define up to five user contexts. (With additional licenses, you can define up to 20 contexts.)
The virtualized environment is divided into objects called contexts. Each context behaves like an independent ACE with its own policies, interfaces, domains, server farms, real servers, and administrators. Each context also has its own management VLAN that you can access using Telnet or Secure Shell (SSH).
As the global administrator (Admin), you can configure and manage all contexts through the Admin context, which contains the basic settings for each virtual device or context. When you log in to the ACE using the console, Telnet, or SSH, you are authenticated in the Admin context.
The Admin context is similar to other contexts. The difference is that when you log in to the Admin context (for example, using SSH), you have full system administrator access to the entire ACE and all contexts and objects within it. The Admin context provides access to network-wide resources, for example, a syslog server or context configuration server. All global commands for the ACE settings, contexts, resource classes, and so on, are available only in the Admin context.
Each context, including the Admin context, has its own configuration file and local user database that are stored in the local disk partition on the flash disk or that can be downloaded from a File Transfer Protocol (FTP), Trivial File Transfer Protocol (TFTP), or HTTP(S) server. The startup-config for each context is stored as the startup configuration file on the flash disk"
Then, as you can see the ACE appliance or module can have multiple instances which will act just like another physical ACE but of course in case, it is virtual. Context can be seen as a " virtual ACE" which is able to load balance traffic, configure server farms, etc just how you can do it on the Admin context.
If you go through the documentation, you will see you may require to allocate the vlans and resources which you need for the new context which you are creating at that point.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...