The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
To verify the overall health of your system, monitor control plane resources on a regular basis.
Monitoring system resources allows you to detect potential problems before they happen, thus avoiding outages. The following are show the advantages of regular monitoring:
The following sections contain a high-level overview of the control plane:
The major components in the control plane are:
Distributed Control Plane Architecture
Cisco ASR 1000 Series Routers have a distributed control plane architecture. A separate control processor is embedded on each major component in the control plane, as shown in Figure 2-1:
The RP manages and maintains the control plane using a dedicated Gigabit Ethernet out-of-band channel (EOBC). The internal EOBC is used to continuously exchange system state information among the different major components. For example, in the event of a failure condition, a switchover event occurs and the standby RP and ESP are immediately ready to assume the data forwarding functions or the control plane functions for the failed component.
The inter-integrated circuit (I2C) monitors the health of hardware components. The Enhanced SerDes Interconnect (ESI) is a set of serial links that are the data path links on the midplane connecting the RP, SIPs, and standby ESPs to the active ESP.
Figure 2-1 Cisco ASR 1000 Series Routers Control Plane Architecture
The control plane processors perform the following functions:
The control plane processors run Cisco IOS XE software, which is an operating system that consists of a Linux-based kernel and a common set of operating system-level utility programs. It is a distributed software architecture that moves many operating system responsibilities out of the IOS process.
In this architecture, IOS runs as one of many Linux processes while allowing other Linux processes to share responsibility for running the router. IOS runs as a user process on the RP. Hardware-specific components have been removed from the IOS process and are handled by separate middleware processes in Cisco IOS XE software. If a hardware-specific issue is discovered, the middleware process can be modified without touching the IOS process.
Figure 2-2 shows the main components of the Cisco IOS XE software architecture. This modular architecture increases network resiliency by distributing operating responsibility among separate processes. The architecture also allows for better allocation of memory so the router can run more efficiently.
All of the Cisco IOS XE software modules run in their own protective memory spaces, which facilitates fault containment. Any software outages of an individual software module are localized to that particular module. All other software processes continue to operate. For example, for each SPA, a separate driver process is executed on the SIP, even if multiple SPAs of the same type are present. Because each SPA driver runs in its own protective memory, failure or upgrade of an individual driver is localized to the affected SPA.
Figure 2-2 Cisco IOS XE Software Architecture
Using the Linux architecture, Cisco IOS XE provides the following benefits:
The following sections discuss monitoring memory and CPU from the perspective of the IOS process and from the perspective of the overall control plane:
For information about memory and CPU utilization from within the IOS process, use the show memory command and the show process cpu command. Note that these commands provide a representation of memory and CPU utilization from the perspective of the IOS process only; they do not include information for resources on the entire route processor. For example, show memory on an RP2 with 8 GB of RAM running a single IOS process shows the following memory usage:
For the dual-core RP2, the show process cpu command reports a single IOS CPU utilization average using both processors:
For information about control plane memory and CPU utilization on each control processor, use the show platform software status control-processor brief command (summary view) or the show platform software status control-processor command (detailed view).
All control processors should show a status of Healthy. Other possible status values are Warning and Critical. Warning indicates that the router is operational but that the operating level should be reviewed. Critical implies that the router is near failure.
If you see a status of Warning or Critical, take the following actions:
The following sections describe the fields in show platform software status control-processor command output.
Load average represents the process queue or process contention for CPU resources. For example, on a single-core processor, an instantaneous load of 7 would mean that seven processes are ready to run, one of which is currently running. On a dual-core processor, a load of 7 would represent seven processes are ready to run, two of which are currently running.
Memory utilization is represented by the following fields:
CPU utilization is an indication of the percentage of time the CPU is busy and is represented by the following fields:
The following are examples of the show platform software status control-processor command.
For more information about the topics discussed in this chapter, see the following documents:
|
|
---|---|
Cisco IOS Master Command List, All Releases Command Lookup Tool (Requires Cisco.com user ID and password) |