The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
IOS process invocation
By stretch | Friday, November 14, 2008 at 8:35 a.m. UTC
Often we network engineers take for granted the relative simplicity of Cisco routers. The packaging of IOS in a single, static executable loaded at boot time seems a far cry from the complexity of modern operating systems, with their lengthy installation processes and complex configurations. Yet, Cisco's Internetwork Operating System, is in fact an operating system.
I was explicitly reminded of this fact back when I read Inside Cisco IOS Software Architecture. Although growing rather dated, the book still offers an invaluable perspective to the inner workings of IOS and many of its platform-specific functions. However, I feel one attribute in particular really drives home the similarity between IOS and a "normal" operating system like Linux or Microsoft Windows: process creation.
On a 3725 running IOS 12.4(9)T1 and a default configuration, 239 independent processes are running in the background:
Router# show processes CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process 1 Cwe 6003A2CC 0 4 0 5496/6000 0 Chunk Manager 2 Csp 60C39168 4 352 11 2532/3000 0 Load Meter 3 Mwe 62EDBBE8 0 1 0 5536/6000 0 chkpt message ha 4 Mwe 62AC8E6C 0 1 023388/24000 0 EDDRI_MAIN 5 Lst 60037544 2888 269 10736 5228/6000 0 Check heaps 6 Cwe 6003FD80 0 1 0 5500/6000 0 Pool Manager ... 233 Mwe 617C7450 0 2 0 8376/9000 0 EEM Policy Direc 234 Lwe 61A884F8 4 10 40011508/12000 0 Syslog 235 Mwe 626F5218 0 88 0 5512/6000 0 IP SLA MPLSLM Pr 236 Mwe 62BE3C7C 0 1 0 5512/6000 0 VPDN Scal 238 Lwe 617F88EC 4 61 65 5320/6000 0 CEF Scanner 239 Mwe 62E23FD0 48 5 9600 7324/8000 0 crypto sw pk pro
You'd think that all these would cover every function for which you might a router, but you'd be wrong. These are merely the default processes, which manage things like memory allocation, interprocess communication, system logging, and so on. When you enable additional features, additional processes are spawned to handle the added functionality. Consider enabling EIGRP for example:
Router# show processes | include EIGRP Router# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)# router eigrp 123 Router(config-router)# net 10.0.0.0 Router(config-router)# ^Z Router# show processes | include EIGRP 232 Mwe 61B08A7C 4 1 4000 8388/9000 0 IP-EIGRP Router 237 Mwe 61B08C6C 0 3 0 7776/9000 0 IP-EIGRP: PDM 240 Mwe 616CD734 0 3 0 5000/6000 0 IP-EIGRP: HELLO
To support EIGRP routing, three new processes are invoked, as seen above. A list of some of the most common process names is available here. Just like on a server or workstation, processes are (usually) terminated when no longer needed:
Router(config)# no router eigrp 123 Router(config)# ^Z Router# show processes | include EIGRP Router#
Posted in Random
Comments
November 14, 2008 at 10:43 a.m. UTC
But IOS is not an evolved operating system. It's a single executable that can be compared with a single process on a unix system. There is no real kernel that allocates resources for individual processes and maintains a seperation between them. This means that the cisco-processes can read and write in eachothers memory locations, something that in current-day OS design is regarded as very bad. There are also many watchdogs running that monitor all kind of variables that could go wrong in Cisco IOS, something that a current operating system as Linux or Windows would have problems with.
IOS XR and IOS XE are improvements, but a real example of good network OS design is JunOS.
November 17, 2008 at 11:05 a.m. UTC
Unfortunately, Cisco did not implement an Unix equivalent "kill" command to end excessive processes. I had run into an issue once trying to generate RSA keys on a Cisco router. The CPU utilization went to 100%, with nearly all of it being the key generation process, which seems plausible but it stayed that high for around 10 minutes. I wanted desperately to kill the process, especially since I had not requested any downtime to perform the maintenance. Unfortunately, all I could do was sit and watch as the router tanked...
November 20, 2008 at 4:21 p.m. UTC
Great little article. Especially like the "show processes | include xxxx" tip. Lets you quickly query what processes are running if you know the keyword