An introduction to the GUI

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

System menu

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.

Tenants menu

The Tenants 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.

Fabric menu

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).

VM Networking

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

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

Admin

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

Operations

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!