Cisco IOS software modularization for Cisco Catalyst 6500 series (1)

Introduction

Today's network devices must provide the longest normal running time to serve the traffic of key tasks such as voice, video, and data applications. Although high reliability is generally provided by redundant systems at the core and distribution layers, given that a single network device is generally a single fault point of the connected terminal device, making them more permanent has become the most important task for the WAN edge of the wiring room, data center access and enterprise network. The Metro Ethernet Access Network meets the strict requirements of SLA signed with the customer. In addition, because enterprises rely on network applications, network operators and administrators need high reliability.

The Cisco Catalyst 6500 series, modular with Cisco IOS software, has enhanced its evolutionary software infrastructure to minimize downtime and improve operational efficiency. By running the modular Cisco IOS subsystem as an independent process, this innovation minimizes unplanned downtime with self-recoverable processes and upgrades ISSU using software running the subsystem) software changes are simplified, and automatic policy control at the process level is implemented by integrating the embedded event manager EEM.

Cisco IOS software modularization for the Cisco Catalyst 6500 Series

Cisco IOS is designed to meet the most stringent IP service and control plane scalability requirements of developing networks. Cisco IOS software consists of hundreds of subsystems, each of which defines a certain component of a technology and runs in shared memory to achieve the highest software forwarding performance.

The Catalyst 6500 series provides hardware-based forwarding through ASIC on PFC or DFC. The control plane feature of the Catalyst 6500 series runs on a dedicated CPU Of The MSFC network.

• Control Plane → manage traffic control, such as route protocol updates and traffic management.
  
• Data plane → responsible for the actual group forwarding through ASIC.

Figure 1. The Cisco IOS software modular architecture shows the separation of the Cisco Catalyst 6500 series control and data plane, as well as independent processes

A completely independent data plane ensures that, even if the control plane is interrupted, the traffic can be forwarded continuously as long as the smart features of the software are sufficient to program the hardware for uninterrupted operation. With the redundancy of the Cisco Catalyst 6500 Series Switch management engine, the Catalyst 6500 series continuous forwarding NSF in the event of a hardware failure in the master switch Management Engine) and stateful switching SSO) the feature still provides a continuous data forwarding plane. The requirements for fault isolation and separation control and data plane lead to OS-level focus changes. Note that changes or problems in the control plane software should not affect data plane forwarding.

The Cisco IOS software is modularized to combine subsystems into independent processes, enhancing the memory architecture of Cisco IOS software and providing process-level fault isolation and subsystem ISSU functions. These improvements are provided in Cisco IOS software for the Catalyst 6500 series Supervisor Engine 720 and Supervisor Engine 32, while retaining a wealth of features and operating environments familiar to network operators. Cisco IOS software modularization will first be available in a Cisco IOS 12.2 (18) SXF version. The operator will be able to choose from a large number of images with or without software modularization. Cisco retains parallel images without the modularization of IOS software before the images with Cisco IOS software are fully functional with the Cisco IOS software version currently used in the Catalyst 6500 series.

Operation consistency

Although software modularization has brought a lot of improvements to Cisco IOS software on the Catalyst 6500 series, there is no need to make any changes from the operational perspective. Command line interface (CLI), SNMP, system logs, and other management interfaces are still the same as before. To support new features, new commands and show commands in the execution and configuration modes are added. Software Release and reconstruction are the same as before, but support for subsystem patches is added.

Protected memory

In the memory architecture supported by software modularization, the process uses protected address space. Each process and its related subsystems "run" in an independent memory space. Subsystems of the same process can communicate with each other directly, while processes can only communicate with each other using IPC) to transmit information. With this mode, there will be no memory corruption and multiple processes. The communication between the neutron System of the same process can be carried out directly, thus providing consistent control plane performance.

Fault Suppression

The advantage of protected memory space is that the reliability is improved because problems in one process do not affect other parts of the system. For example, if a low-key system process fails or fails as expected, the key functions required by the continuous forwarding Group will not be affected. Specifically, if the UDP process fails, only the characteristics of UDP must be affected.

Process restorability

The modular process is built on Protected memory space and fault suppression, and can now be restarted separately. To test or process a non-responsive process, you can use a CLI command to manually restart the process. In this way, you can quickly recover from temporary errors without interrupting group forwarding.

Manual restart of processes is very important, and continuous check of the Process status is also crucial. An integrated high-reliability subsystem can continuously check the Process status and track the number of restarts of a process at a specified interval to complete this task. This high-reliability subsystem can be recovered from various faults as soon as possible by restarting the process. If the system cannot be restored after the process is restarted, the high-reliability subsystem will take high-level actions, such as switching the management engine or restarting the system.

Because each process has its own protected environment, status checkpoint information can be provided as needed. The checkpoint architecture can retain this information during process restart or failover. The high-reliability subsystem uses this information during process restart to achieve stateful recovery. When a process IS restarted, it uses the checkpoint information, such as the status of the intermediate system-intermediate system [IS-IS] routing protocol information, to restore the process as soon as possible. The checkpoint information is provided only during the first restart of a process in a specific period of time to ensure that the checkpoint status information itself does not cause errors.