In-service upgrade of kernel loadable modules

• US 10,289,398 B2
• Filed: 09/26/2015
• Issued: 05/14/2019
• Est. Priority Date: 09/26/2015
• Status: Active Grant

• Current Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Original Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Inventors: Veereshwara, Srinivas, Pandian, Senthilkumar, Singh, Akshya Kumar, Arakali, Ravinandan
• Primary Examiner(s): Sough, S.
• Assistant Examiner(s): Wang, Ben C
• Application Number:
  US14/866,952
• Publication Number:
  US 20170090897A1
• Time in Patent Office: 1,326 Days
• CPC Class Codes: G06F 8/61 Installation
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57
• CPC Class Codes: G06F 8/656 while running
• CPC Class Codes: G06F 8/71 Version control security arrangements therefor G06F21/57; Configuration management
• CPC Class Codes: H04L 67/34 involving the movement of software or configuration parameters network booting or remote initial program loading [RIPL] G06F9/4416

Abstract

In one embodiment, a method includes creating an active container and a standby container for a single supervisor of an operating system at a network device, instantiating instances for active Kernel Loadable Modules (KLMs) for servicing the active container, instantiating instances for standby KLMs for servicing the standby container, wherein one or more of the standby KLMs comprise upgraded versions of the active KLMs, and switching over from the active container to the standby container to perform an in-service upgrade of the KLMs for the operating system. An apparatus and logic are also disclosed herein.

Claims

1. A method comprising:

creating an active container and a standby container for a single supervisor of an operating system at a network device;

instantiating instances for active Kernel Loadable Modules (KLMs) for servicing said active container;

instantiating instances for standby KLMs for servicing said standby container, wherein one or more of said standby KLMs comprise upgraded versions of said active KLMs;

automatically generating a prefix identifier inserted into active and standby KLM names to prevent symbol clashes between said active KLMs and said standby KLMs; and

switching over from said active container to said standby container to perform an in-service upgrade of said active KLMs for the operating system at the network device.

2. The method of claim 1 wherein the operating system comprises an active kernel name space associated with said active KLMs and a standby kernel name space associated with said standby KLMs.

3. The method of claim 1 wherein said prefix identifier is inserted into said active and standby KLM names to distinguish between said active KLMs and said standby KLMs.

4. The method of claim 1 wherein said standby container communicates with said active container over a virtual Ethernet link to obtain current running state of said active container.

5. The method of claim 1 further comprising changing said active container to a standby container after switching over from said active container to said standby container.

6. The method of claim 1 further comprising restarting a linecard container with a new version of linecard KLMs after switching to said standby container.

7. An apparatus comprising:

a host operating system comprising an active kernel name space associated with an active container and a standby kernel name space associated with a standby container, said active and standby containers defining a single supervisor for the host operating system; and

a processor operable to instantiate instances for active Kernel Loadable Modules (KLMs) for servicing said active container, instantiate instances for standby KLMs for servicing said standby container, wherein one or more of said standby KLMs comprise upgraded versions of said active KLMs, automatically generate a prefix identifier inserted into active and standby KLM names to prevent symbol clashes between said active KLMs and said standby KLMs, and switch over from said active container to said standby container to perform an in-service upgrade of said active KLMs for the host operating system.

8. The apparatus of claim 7 wherein the processor inserts said prefix identifier into said active and standby KLM names to distinguish between said active KLMs and said standby KLMs.

9. The apparatus of claim 7 wherein said standby container communicates with said active container over a virtual Ethernet link to obtain current running state of said active container.

10. The apparatus of claim 7 wherein said active container is changed to a standby container after switching over from said active container to said standby container.

11. The apparatus of claim 7 further comprising memory for storing two KLM code versions, one for said active KLMs and one for said standby KLMs.

12. Logic encoded on one or more non-transitory computer readable media for execution and when executed operable to:

create an active container and a standby container for a single supervisor of an operating system at a network device;

instantiate instances for active Kernel Loadable Modules (KLMs) for servicing said active container;

instantiate instances for standby KLMs for servicing said standby container, wherein one or more of said standby KLMs comprise upgraded versions of said active KLMs;

automatically generate a prefix identifier inserted into active and standby KLM names to prevent symbol clashes between said active KLMs and said standby KLMs; and

switchover from said active container to said standby container to perform an in-service upgrade of said active KLMs for the operating system.

13. The logic of claim 12 wherein the operating system comprises an active kernel name space associated with said active KLMs and a standby kernel name space associated with said standby KLMs.

14. The logic of claim 12 wherein said prefix identifier is inserted into said active and standby KLM names to distinguish between said active KLMs and said standby KLMs.

15. The logic of claim 12 wherein said standby container communicates with said active container over a virtual Ethernet link to obtain current running state of said active container.

16. The logic of claim 12 when executed operable to change said active container to a standby container after switching over from said active container to said standby container.

17. The logic of claim 12 when executed operable to restart a linecard container with new version of linecard KLMs after switching to said standby container.