On accessing the APIC, we are presented with the login page. It can take a few minutes for the system to fully initialize before we can log in.
Figure 12
Once we have successfully logged in, we are shown the System
page. We have the main menu at the top, and each menu item has a submenu.
Here, we can see the System
menu, with its submenu showing Quickstart
, Dashboard
, Controllers
, Faults
, and Config Zones
:
Figure 13
The system page shows us the health of the system, separated into the overall system health and nodes and tenants with under 99% health. Faults counts are listed on the right-hand side, by domain, and by type. We can see the controller status in the bottom right-hand corner.
Figure 14
Moving on to the Controllers
submenu we can see the screen from the previous section.
Figure 15
We have one controller (apic1
); its IP address is 10.0.0.1
, it is in service and available, and the health state is Fully Fit
. If we click on any of the column headings, we can sort them by ascending or descending order, which is useful if you have a large number of controllers.
Figure 16
We can see the interfaces present on our controller (apic1
) from the Interfaces
menu on the left-hand side:
Figure 17
We can keep track of how much storage we have used from the Storage
menu option, and again, this is sortable by clicking on the column heading:
Figure 18
You will notice that the screen flickers every few seconds as it refreshes.
Also, in this section, we can see stats on our NTP servers, our fans and power supply units, and the equipment sensors (which in the simulator are all empty). Under Processes
, we can see how much memory we are currently using from the Stats
option:
Figure 19
We can also check on the CPU usage from the same window:
Figure 20
We can also see current and historical faults and events from the Processes
menu.
The last menu option under Controllers
is Controller Policies
, where we can set policies for exporting diagnostic information. We will look at this in the troubleshooting section.
The final two options are Faults
, in which we can see a couple of examples and Config Zones
.
Figure 21
We do not have any zones, but we can create one from the drop-down menu. Configuration zones allow us to subdivide our ACI fabric, meaning that we can make configuration changes to one zone at a time, reducing the chances of an error affecting the entire fabric. Note that if you get access to the Cisco Devnet sandbox environment, the Config Zones
option is unavailable. Devnet is a great place to learn the developer side of Cisco's products as well as getting access to hands-on labs and virtual and hardware-based sandbox environments. The virtual ones are fairly limited, but available all the time. The physical rack equipment offers the full range of functionality but does get booked up months in advance. You can find more about Devnet by going to the Devnet site: https://developer.cisco.com/site/devnet/home/index.gsp.
The Tenant
s
tab shows us all our tenants. We have three preconfigured (common
, infra
, and mgmt
):
Figure 22
If we select a tenant and go through the options, we can see the application profiles assigned to it, the networking configuration, layer 4-layer 7 service parameters, and all of the policies. We will go through these in greater detail in the next chapter when we set up some tenants.
This is where we will create new tenants.
From the Fabric
menu, in the Inventory
submenu, we can see our topology:
Figure 23
If we expand the pod out, we can see all of our leaf and spine nodes:
Figure 24
Going through these, we can see our interfaces, routing tables, processes, pools, and rules. One thing to note here is that we have many more routing options with a leaf node than we do with a spine node:
Figure 25
Under the Fabric Membership
option, we have a list of our leaf and spine nodes, which shows us the serial numbers, ID, name, model, role, and assigned IP address. It also gives us the certificate information, so we know that SSL is healthy and IFM can function.
Figure 26
The last three options in this menu are for the nodes we may be having issues with, whether they are currently unmanaged, unreachable, or disabled and decommissioned.
The other options in the Fabric
submenu are our policies. Here, we can set up callhome policies, monitoring, troubleshooting, spanning tree and VPC policies, whether we want to have CDP turned off or on, and various layer-2 policies. Many of these options have three options; take LLDP for example. We have an option for LLDP-OFF
(disabled), LLDP-ON
(enabled), and default (Receive State is enabled, and Transmit State is enabled). Similarly, for CDP we have CDP-OFF
(disabled), CDP-ON
(enabled), and default (where the Admin State is Disabled
).
Under the VM Networking
menu is where we would start connecting ACI into our third-party vendors. The default options are Microsoft
, OpenStack
, and VMWare
.
Figure 27
L4-L7 Services
allows us to further extend our ACI fabric with additional third-party solutions. This is performed through the addition of packages, which we can import from the Packages
submenu's Quick Start
option. This is something we will look at in a later chapter.
Figure 28
Under the Admin
menu is where we configure AAA (Authentication, Authorization, and Accounting). Here, we can set up RBAC and also connect to authentication providers, such as LDAP; for example, Microsoft Active Directory, RADIUS, or TACACS+. We can also set up PKI to use certificate chains.
We can create maintenance schedules, either one-off tasks or regular ones. We can configure our log retention policies, upgrade our firmware, and configure callhome (after setting up the policies in the Fabric
menu), SNMP, and Syslog. The Admin
menu is also where we would perform configuration rollbacks and the importing of configuration files and exporting of technical support files.
Figure 29
The final menu option is Operations
. This is where will can perform most of our troubleshooting, should the need arise. From here, we find endpoints and look at the traffic path, along with any faults along the path. We can perform a traceroute as well to check the data plane. This is something we will look at in Chapter 9, Troubleshooting ACI.
We can also check out usage with the Capacity Dashboard
, create Optimizer configuration templates, track our endpoints, and even look at a traffic map.
Figure 30
For now, though, it’s time to start configuring!