Patent Publication Number: US-2020304368-A1

Title: Accessing processing devices of a network device

Description:
BACKGROUND 
     A network device may be a device (e.g., a computing device, an electronic device etc.) capable of communicating data with other devices through a wired or wireless connection or set of connections. For example, a network device may receive data from a first device (e.g., a computing device, a switch, a router, etc.) and may forward the data to a second device (e.g., a computing device, a switch, a router, etc.). A network device may include various types of hardware that may be used to transmit and/or receive data. For example, a network device may include line cards and each line card may include one or more processing devices (e.g., application specific integrated circuits, field programmable gate arrays, processors, central processing units, forwarding engines, etc.) to transmit and/or receive data (e.g., network packets). 
     SUMMARY 
     In some implementations, a method is provided. The method includes receiving, by an agent of a first container of a network device from a second container of the network device, a request for a forwarding engine of the network device to perform an operation. The first container and the second container are located on a control plane of the network device. The first container comprises a set of drivers to support multiple types of forwarding engines. The first container further comprises an operating system. The method also includes providing the request to the operating system. The operating system uses a first driver of the set of drivers to communicate with the forwarding engine. The method further includes performing the operation requested by the second container. The method further includes providing a result of the operation to the second container in response to determining that the result should be provided to the second container. 
     In some implementations, a network device is provided. The network device includes a memory configured to store a first container and a second container. The network device also includes a processing device coupled to the memory. The processing device may receive a request for a forwarding engine of the network device to perform an operation. The first container and the second container are located on a control plane of the network device. The first container comprises a set of drivers to support multiple types of forwarding engines. The first container further comprises an operating system. The processing device may also provide the request to the operating system. The operating system uses a first driver of the set of drivers to communicate with the forwarding engine. The processing device may further perform the operation requested by the second container. The processing device may further provide a result of the operation to the second container in response to determining that the result should be provided to the second container. 
     In some implementations, a non-transitory machine-readable medium having executable instructions to cause one or more processing devices to perform a method is provided. The method includes receiving, by an agent of a first container of a network device from a second container of the network device, a request for a forwarding engine of the network device to perform an operation. The first container and the second container are located on a control plane of the network device. The first container comprises a set of drivers to support multiple types of forwarding engines. The first container further comprises an operating system. The method also includes providing the request to the operating system. The operating system uses a first driver of the set of drivers to communicate with the forwarding engine. The method further includes performing the operation requested by the second container. The method further includes providing a result of the operation to the second container in response to determining that the result should be provided to the second container. 
     Other aspects and advantages of the embodiments will become apparent from the following detailed description taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the described embodiments. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The described embodiments and the advantages thereof may best be understood by reference to the following description taken in conjunction with the accompanying drawings. These drawings in no way limit any changes in form and detail that may be made to the described embodiments by one skilled in the art without departing from the spirit and scope of the described embodiments. 
         FIG. 1  is a block diagram illustrating an example of a network device, in accordance with some embodiments. 
         FIG. 2  is a block diagram illustrating an example of a network device, in accordance with some embodiments. 
         FIG. 3  is a block diagram illustrating an example of a network device, in accordance with some embodiments. 
         FIG. 4A  is a flow diagram of a method of accessing processing devices in a data plane of network device, in accordance with some embodiments. 
         FIG. 4B  is a flow diagram of a method of accessing one or more network stacks, in accordance with some embodiments. 
         FIG. 5  shows an example a computing device, in accordance with some embodiments. 
         FIG. 6  is a block diagram of one embodiment of an exemplary network device, in accordance with some embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     As discussed above, a network device may be a device (e.g., a computing device, an electronic device, etc.) that may communicate data with other devices (e.g., may receive data from a first device and may forward the data to a second device. A network device may include a control plane and a data plane. A control plane may process control information and write configuration data used to manage and/or configure the data plane. The control plane may also perform control management updates and/or respond with control message responses (e.g., routing decisions, protocol updates, traffic resolutions, etc.). The data plane receives, processes, and forwards network data based on the configuration data, as discussed in more detail below. 
     Specific drivers or libraries may be used to access, communicate with, and/or manage the processing devices used in a data plane. Thus, a user (e.g., a network administrator) should generally have knowledge of the types of processing devices (e.g., the type of ASICs, FPGAs, forwarding engines, etc.) that are used in the data plane. Tracking and managing the different libraries/drivers that are used may be a difficult, cumbersome, and/or inefficient process for the user. The embodiments, implementations, and examples, described herein allow a network device to access, communicate with, manage, and/or perform operations using processing devices more quickly and/or efficiently. The network device includes a primary or host operating system. The primary or host operating system may not include the drivers and/or libraries that may be used to access, communicate with, manage, and/or perform operations using the processing devices in the data plane. The network device also includes a second standalone or complete operating system. Because the second operating system is a standalone or complete operating system, the second operating system may include multiple types of drivers and/or libraries that may be used to access, communicate with, manage, and/or perform operations using the processing devices in the data plane. The network device may use the drivers and/or libraries of the second operating system to access, communicate with, manage, and/or perform operations using processing devices. 
       FIG. 1  is a block diagram of one embodiment of a network device  100  that includes a control plane  104  and a data plane  102 . Network device  100  may be any type of device that can communicate network data with another device (e.g., a personal computer, laptop, server, mobile device, a phone, a smartphone, a personal gaming device, another network device, switch, router, hub, bridge, gateway, etc.). For example the network device  100  may receive data from a first device and may forward the data to another device, and vice versa. In one embodiment, network device  100  may be a device that hosts one or more containers and/or virtual machines, as discussed below. In other embodiments, network device  100  may be a virtual machine or a container. 
     In one embodiment, the data plane  102  receives, processes, and forwards network data using various configuration data (e.g., packet forwarding (routing, switching, or another type of packet forwarding), security, quality of service (QoS), and other network traffic processing information). For example, for each received packet of the network traffic, the data plane  102  determines a destination address of that packet, looks up the requisite information for that destination in one or more memories of data plane  102 , and forwards the packet out the proper outgoing interface. The data plane  102  includes multiple data processing elements  106 A through  106 C that can each receive, process, and/or forward network traffic. A data processing element may also be referred to as a line card of network device  100 . In one embodiment, each data processing element  106 A through  106 C includes a forwarding engine (FE)  112 A through  112 C and ports  115 A through  112 C, respectively. FEs  112 A through  112 C may be processing devices that may receive packets on a port and/or transmit the packets to one or more other ports (e.g., forward the packets to one or more other ports). Examples of FEs  112 A through  112 C include, but are not limited to, application specific integrated circuits (ASICs), field programmable gate arrays (FPGA), processors, multi-core processors, central processing units (CPUs), circuitry, and/or other types of processing logic. 
     In one embodiment, control plane  104  includes processing device  108  (e.g., a central processing unit (CPU), a processor, a multi-core processor, a processing core, etc.) and memory  114 . As discussed herein, processing device  108  may be referred to as a control plane processor of network device  100 . Control plane  104  is used to process control information for control plane  104  and/or data plane  102 , and write configuration data for forwarding engines  112 A-C in the data processing elements  106 A through  106 C. The information processed by control plane  104  includes, for example, control plane data corresponding to a plurality of different classes of control plane traffic, such as routing protocol messages, routing table messages, routing decisions messages, route update messages, unresolved traffic messages, L2 protocol messages, link aggregation control protocol messages, link layer state updates messages (e.g., spanning tree messages), link state update messages (e.g., link aggregation control protocol messages for a link aggregation group, bidirectional forwarding detection messages, etc.), exception packets that cannot be dealt with in hardware (e.g., router alerts, transmission time interval messages, maximum transmission size exceeded messages, etc.), program messages (e.g., packets from a controller instructing the programming of a network device), messages for routing table misses, time control messages (e.g., precision time protocol messages), messages for packets marked as being of interest for snooping (e.g., access control list logging and port mirroring messages), messages used to collect traffic diagnostics, address resolution messages (ARP) requests and replies, neighbor solicitation requests and replies, general communication to the control plane of the networking device, etc. Control plane  104  processes the control plane network data to perform control management updates and/or respond with control message responses (e.g., routing decisions, protocol updates, traffic resolutions, etc.). 
     In one embodiment, memory  114  includes operating system (OS)  118  that may be executed by processing device  108 . For example, OS  118  may include various computing processes, computing services, threads, etc., that may be executed by processing device  108 . Memory  114  also includes container  120 . Container  120  may be an isolated set of resources allocated to executing an application, software, service, process, and/or operating system independent from other applications, software, and/or processes. Container  120  may share the kernel, libraries, and binaries of OS  118  (which may be referred to as a host OS) with other containers that are on network device  100 . A container engine (not illustrated in the figures) may allow different containers to share the host OS (e.g., the OS kernel, binaries, libraries, etc.). For example, the container engine may multiplex the binaries and/or libraries of the host OS between multiple containers. The container engine may also facilitate interactions between the container and the resources of the computing device. The container engine may also be used to create, remove, and manage containers. In one embodiment, the container engine may be component of OS  118 . In another embodiment, container engine may run on top of OS  118 , or may run directly on hardware without the use of OS  118 . OS  118  may not include the drivers and/or libraries that may be used to access, communicate with, manage, and/or perform operations using the processing devices in the data plane. 
     In one embodiment, applications  130  execute various aspects of the functionality of control plane  104 . For example, one application  130  may be used for quality of service, access control lists management (or other types of security), policy service, etc. Other examples of operations that may be performed by application  130  may include a fan control, a light emitting diode control, a temperature sensing, database services, management service(s), operations to support networking protocols (e.g., spanning tree protocol (STP), routing protocols (e.g., such as routing information protocol (RIP), border gateway protocol (BGP), open shortest path first (OSPF), intermediate system-intermediate system (IS-IS), interior gateway routing protocol (IGRP), enhanced IGRP (EIGRP), protocol independent multicast (PIM), distance vector multicast routing protocol (DVMRP), and any/or other type or unicast or multicast routing protocol), Multiprotocol Label Switching (MPLS), and/or other types of networking protocols), network flow management applications (e.g., openflow, directflow), process manager, and/or other types of functionality of the network device  100 . 
     In one embodiment, for each received unit of network data (e.g., a packet), the data plane  102  determines a destination address for the network data, looks up the requisite information for that destination in one or more tables stored in the data plane, and forwards the data out the proper outgoing interface, for example, one of the data processing elements  106 A-C. In one embodiment, each data processing elements  106 A-C includes one or more forwarding engines (FE(s))  112 A-C and ports  115 A-C, respectively. Each forwarding engine  112 A-C forwards data for network device  100 , such as performing routing, switching, or other types of network forwarding or processing. 
     In some embodiments, users may want the software of control plane  104  to be independent of the hardware what is used in network device  100  (e.g., may want the software of control plane  104  to be hardware agnostic). For example, the software of control plane  104  (e.g., OS  118 , applications  130 , etc.) should be able to perform various functions, operations, actions, etc., regardless of the hardware that is used in data plane  102 . Different line cards with different FEs may be used in the data plane and users may want the software of control plane  104  to be able to perform the same functions, operations, actions, etc., using the different line cards and/or the different FEs. 
     Control plane  104  (e.g., software of control plane  104  such as applications  130 ) may communicate with the FEs  112 A through  112 C to perform the various functions, operations, actions, etc. For example, an application  130  may set the internet protocol (IP) address of one or more ports  115 A through  115 C. In another example, application  130  may request the value of a configuration setting or parameter of the data plane (e.g., may request the IP address of a network interface). As illustrated in  FIG. 1 , container  120  includes a library  121 . The library  121  may be used by to access FEs  112 A through  112 C. For example, the library  121  may include application programming interfaces (APIs), function calls, routings, remote procedure calls (RPCs), etc., that may be used by application  130  and/or control plane  104  to access and/or communicate with one or more of the FEs  112 A through  112 C. Library  121  may be provided by a vendor or manufacturer of the hardware (e.g., FE  112 A, a line card, etc.) used in data plane  102   
     Because specific drivers or libraries are used to access, communicate with, and/or manage FEs  112 A through  112 C, a user should generally have knowledge of the type of FEs that are used in data plane  102  (e.g., the design, architecture, make, model, etc., of the FEs). If new FEs are added to network device  100 , new libraries or drivers should be added to container  120  to allow control plane  104  to access, communicate with, and/or manage FEs  112 A through  112 C. This may be a cumbersome and time consuming process for a user (e.g., a network administrator). In addition, it may be difficult for the user to determine all of the different types of FEs that may be used in data plane  102  and load the libraries/drivers for those different types of FEs, into the container  120 . 
       FIG. 2  is a block diagram illustrating an example network device  200 , in accordance with some embodiments. Network device  200  includes control plane  204  and data plane  102 . As discussed above, data plane  102  receives, processes, and forwards network data using various configuration data. Data plane  102  includes FEs  112 A through  112 C. FEs  112 A through  112 C may be processing devices such as ASICs, FPGAs, CPUs, etc., that may receive, process, and/or forward network data between ports of the network device  200 . FEs  112 A through  112 C may be part of data processing elements (e.g., line cards) as discussed above. 
     Control plane  204  includes a processing device  108 , Control plane  204  is used to process control information for the control plane  204  and/or data plane  102 , and write configuration data for forwarding engines  112 A through  112 C. For example, control plane  204  processes the control plane network data to perform control management updates and/or respond with control message responses (e.g., routing decisions, protocol updates, traffic resolutions, etc.). Control plane  204  includes a memory  114 . Examples of memory  114  may include non-volatile memory (e.g., memory which retains data even if the memory loses power), such as a flash memory, a hard disk, a disk drive, a flash chip, and/or may include volatile memory (e.g., a memory that does not retain data if the memory loses power), such as a random access memory (RAM). The memory includes applications  130 , container  120 , and container  250 . As discussed above, applications  130  may execute various aspects of the functionality of control plane  204 . For example, an application  130  may process address resolution protocol (ARP) messages or packets (e.g., may respond to ARP resolution requests). In some embodiments, one or more of applications  130  may execute within one or more additional containers (e.g., other containers in addition to container  120  and container  250 ). 
     Container  120  includes library  221 . Library  221  may provide an interface and/or functions to allow applications  130  to communicate with and/or access FEs  112 A through  112 C. For example, first application  130  may use library  221  to communicate with FE  112 A, to request FE  112 A to perform an operation or action, etc. Library  221  may provide an API, a set of functions, a set of procedures, etc., as discussed above. Library  221  may receive a request from an application  130  (or some other module, software, application, etc. of control plane  204 ) to have one or more of FEs  112 A through  112 C perform an operation and/or access/communicate with one or more of FEs  112 A through  112 C. For example, library  221  may receive a request to update a routing table used by one or more of FEs  112 A through  112 C. As discussed above, library  121  (of  FIG. 1 ) included a driver that would be used to access one or more of FEs  112 A through  112 C. The driver may be specific to a type of FE. Thus, in order to allow network device  200  to support different types of FEs (e.g., different makes and models of FEs), a user would either develop drivers and/or libraries for different types of FEs, or obtain drivers and/or libraries from different vendors. This is a cumbersome process and may also result in more effort on the part of the user to determine all of the different types of FEs that may be used, and to obtain drivers/libraries for those different types of FEs. 
     In one embodiment, library  221  may not include drivers or libraries for different types of FEs. Instead, when library  221  receives a request to access/communicate with an FE or to have an FE perform an operation, library  221  may redirect, forward, transmit, provide, etc., that request to container  250 . As illustrated in  FIG. 2 , container  250  includes OS  251 . In one embodiment, OS  251  may be a complete or standalone operating system that is capable of executing on network device  200  and/or another computing/network device. For example, OS  251  may include various services, processes, modules, etc., that may be able to perform various control plane functions, network forwarding functions, and/or may be able to communicate with various different types of hardware, if OS  251  were to be used as the primary operating system for a computing/network device. OS  251  includes drivers  252 . Driver  252  may be an application or program that operates or controls a device, such as a hardware device. Driver  252  may also allow other devices, other processes, services, modules, etc., to communicate with the device. 
     In one embodiment, because OS  251  is a complete/standalone operating system, OS  251  may inherently include drivers  252  to allow OS  251  (and other applications, processes, services, etc.) to control, operate, and/or communicate with various different types of devices or hardware. In one embodiment, drivers  252  may allow OS  251  to communicate with various types of forwarding engines (e.g., various types of ASICs, FPGAs, CPUs, processing devices, etc.). For example, different types of forwarding engines may be forwarding engines that are manufactured or sold by different vendors (e.g., different companies). In another example, different types of forwarding engines may be different models or different lines of forwarding engines from the same manufacturer or vendor. Thus, drivers  252  may allow OS  251  (and other applications, processes, services, etc.) to control, operate, and/or communicate with forwarding engines that are from various different vendors and/or with various different models of forwarding engines from the same vendor. This allows network device  200  to have simple function calls, APIs, procedures, etc., within library  221 , rather than including a driver for a particular type of FE. Because OS  251  may inherently include various drivers  252 , the library  221  is able to rely on OS  251  to provide appropriate drivers or libraries that may be used to communicate/access FEs  112 A through  112 C. 
     In one embodiment, agent  254  may determine the type of FEs  112 A through  112 C. For example, agent  254  may determine the make, model, or other identifying information (e.g., a serial number, a part number, etc.) for the FEs  112 A through  112 C. Agent  254  may identify the appropriate driver  252  to use when accessing/communicating with FEs  112 A through  112 C, based on the type of FEs  112 A through  112 C. For example, agent  254  may identify driver  252  that is used to access or communicate with a specific make and model number of FEs. In one embodiment, agent  254  may determine the type of FEs  112 A through  112 C by accessing configuration data, settings, or parameters stored in control plane  204 . For example, agent  254  may access a configuration file that may indicate the type of FEs  112 A through  112 C. In another embodiment agent  254  may query FEs  112 A through  112 C to determine their type. For example, agent  254  may transmit a message to FEs  112 A through  112 C to request information (e.g., serial number, model number, etc.) that may be used to determine the type of FEs  112 A through  112 C. 
     OS  251  also includes an agent  254 . Agent  254  may be a process, program, service, application, etc., that is executing within container  250 . Thus, agent  254  may be referred to as a process or an operating system process. Although agent  254  is illustrated as part of OS  251 , the agent may be separate from OS  251  in other embodiments. For example, agent  254  may be a separate application executing within container  250 . As discussed above, library  221  may provide a request to access/communicate with one or more FEs  112 A through  112 C or a request to have one or more FEs  112 A through  112 C perform an operation, to container  250 . This request may be received by OS  251  and/or agent  254 . For example, library  221  may include an API, function, etc., that transmit the request to OS  251  and/or agent  254 . 
     In one embodiment, agent  254  may translate the request received from  221  into a format that may be used or recognized by OS  251 . For example, agent  254  may change the order of parameters in a function call, convert a parameter to a different format (e.g., convert timestamp formats, convert an IPv4 address to an IPv6 address, etc.), etc. The format may be based on one or more processes  253  of OS  251  that may be used to access/communicate with FEs  112 A through  112 C or to perform operations using FE  112 A through  112 C. For example, a process  253  (e.g., an operating system process, a service, another agent, etc.) may be used to create a virtual local area network (VLAN) using FE  112 A. Process  253  may expect different types of data in different formats than other processes in OS  251 . The agent  254  may determine that the request is for process  253  and may translate the request (e.g., translate a command, a parameter, etc.) to a format recognized or used by process  253 . Agent  254  may then provide the request (e.g., the translated request) to the process  253 . In another embodiment, library  221  may translate the request prior to providing the request to agent  254 . 
     In one embodiment, process  253  may perform an operation on one or more FEs  112 A through  112 C or using one or more FEs  112 A through  112 C. For example, process  253  may instruct FE  112 A to add an entry in a route table (e.g., a routing table, a forwarding table, etc.) used by FE  112 A. In another example, process  253  may instruct FE  112 B to change an IP address of an interface (e.g., a network interface, a port, etc.) that is managed by FE  112 B. The process  253  may use a driver  252  for FEs  112 A through  112 C to communicate, access, or perform operations on/using FEs  112 A through  112 C. Process  253  may perform various types of operations on/using FEs  112 A through  112 C. In one embodiment, process  253  may use FE  112 A to set a configuration setting or a parameter of the data plane  102 . For example, process  253  may set the IP address of a network interface in the data plane  102 . In another example, process  253  may use FE  112 A to get the value a configuration setting or a parameter of the data plane  102 . For example, process  253  may request the IP address of a network interface in the data plane  102 , from FE  112 A. Examples of operations that may be performed on and/or using the FEs  112 A through  112 C include, but are not limited to, adding a VLAN, deleting a VLAN, setting an IP address for an interface, adding an IP route, deleting an IP rout, configuration the IP address of a port, adding an ARP entry, deleting an ARP entry, setting quality of service parameters, getting an IP rout, getting a VLAN (e.g., a VLAN ID), getting a current state of a link or port, getting a MAC address of a port, and getting statistics associated with a port (e.g., number of packets transmitted/received, number of dropped packets, etc.). 
     In one embodiment, agent  254  may determine whether a result of the operation should be provided to container  120  and/or library  221 . For example, the request received from library  221  may indicate whether library  221  is expecting a result for the operation. If agent  254  determines a result of the operation should be provided to container  120  and/or library  221 , agent  254  may transmit a message indicating the result of the operation to container  120  and/or library  221 . For example, the operation requested by library  221  may be a request to determine the IP address for a port. Agent  254  may determine that the IP address for the port should be provided to library  221  and may transmit a message with the IP address for the port to library  221 . In another example, the operation requested by library  221  may be a request for FE  112 A to set a configuration parameter to a particular value (e.g., set an IP address of a port to a particular IP address). Agent  254  may determine that library  221  is waiting for a confirmation that the configuration parameter was set to the particular value and may transmit data (e.g., a number, an alphanumeric value, etc.) indicating whether the configuration parameter was set to the particular value. 
     In one embodiment, agent  254  may determine whether one or more of FEs  112 A through  112 C has detected an event that may have occurred in the data plane  102 . For example, agent  254  may determine FE  112 A has detected that a port (e.g., a link or a network interface) that is managed by FE  112 A, is no longer operational (e.g., a link or interface has gone down). Agent  254  may determine one of more of FEs  112 A through  112 C has detected an event in various ways. For example, agent  254  may receive a message from one or more of FEs  112 A through  112 C indicating that an event has occurred. The message may also provide additional information about the event. For example, the message may indicate what event has occurred and may indicate other information associated with the event. In another example, agent  254  may detect an interrupt (e.g., a signal, a hardware interrupt, a software interrupt, etc.) generated by one or more of FEs  112 A through  112 C. The interrupt may indicate that an event has occurred and may also provide additional information about the event. 
     In one embodiment, the processes  253  of the OS  251  may perform functions, actions, and/or operations of control plane  204 . For example, process  253  may respond to ARP requests. In another example, process  253  may create VLANs or virtual extensible LANS (VXLANs). The OS  251  may perform these functions, actions, and/or operations in conjunction with OS  118 . For example, OS  118  may allow OS  251  to perform certain control plane functions while OS  118  performs other control plane functions. Because OS  251  is a standalone or complete operating system, OS  251  may provide functions, features, operations, etc., that may be used and/or leveraged by network device  200 . For example, rather than implementing an ARP process or an application  130  to process ARP messages, OS  118  may use the a process  253  (e.g., an ARP process of OS  251 ) to process the ARP messages. 
     As discussed above, control plane  104  (e.g., software of control plane  104  such as applications  130 ) may communicate with the FEs  112 A through  112 C to perform the various functions, operations, actions, etc. Users may want the software of control plane  104  to be independent of the hardware what is used in network device  100  (e.g., may want the software of control plane  104  to be hardware agnostic). However, because specific drivers or libraries are used to access, communicate with, and/or manage FEs  112 A through  112 C, the task of managing, installing, and configuring the libraries or drivers may be time consuming and/or difficult for the user. If new types of FEs are added to network device  100 , new libraries or drivers should be added to container  120  to allow control plane  104  to access, communicate with, and/or manage FEs  112 A through  112 C. This may be a cumbersome and time consuming process for a user, such as a network administrator. In addition, it may be difficult for the user to determine all of the different types of FEs that may be used in data plane  102  and load the libraries/drivers for those different types of FEs, into container  120 . 
     Because OS  251  is a standalone or complete operation system, OS  251  may inherently include multiple drivers  252  that may be used to access, communicate with, manage, and/or perform operations using many different types of processing devices in the data plane. This allows network device  200  to use OS  251  to manage the drivers and/or libraries that may be used to access FEs  112 A through  112 C. This may simplify the task of managing all of the different types of drivers and/or libraries, which was previously performed by the user. In addition, this allows the network device  200  to have simple function calls, APIs, procedures, etc., within library  221 , rather than including a driver for a particular type of FE. Furthermore, as OS  251  is updated (e.g., new patches or releases of OS  251  are provided), OS  251  may obtain new drivers and/or libraries that may be used for new devices (e.g., new types of FEs). Many OSes have an update process (e.g., automatic updates) that the user may execute. This may allow network device  200  to more easily manage and/or support new types of FEs by updating OS  251 . 
       FIG. 3  is a block diagram illustrating an example network device  200 , in accordance with some embodiments. Network device  300  includes a control plane  204  and a data plane (not illustrated in  FIG. 3 ). As discussed above, a data plane (e.g., data plane  102  illustrated in  FIGS. 1 and 2 ) receives, processes, and forwards network data using various configuration data. A data plane may include one or more FEs (e.g., FEs  112 A through  112 C illustrated in  FIGS. 1 and 2 ). Control plane  204  includes a processing device  108 , Control plane  204  is used to process control information for the control plane  204  and/or data plane  102 , and write configuration data for forwarding engines  112 A through  112 C. For example, control plane  204  processes the control plane network data to perform control management updates and/or respond with control message responses (e.g., routing decisions, protocol updates, traffic resolutions, etc.). Control plane  204  includes a memory  114  (e.g., one or more of flash memory, RAM, etc.). The memory includes applications  130 , container  120 , and container  250 . As discussed above, applications  130  may execute various aspects of the functionality of control plane  204 . 
     As illustrated in  FIG. 3 , container  120  is located within network namespace  351  and container  250  is located within network namespace  361 . Generally, a namespace may be a partition, division, grouping, etc., of resources of an operating system (e.g., kernel resource), such as OS  118 . This allows different processes, services, applications, programs, etc., that are operating on a device to have access to different sets of resources. There may be multiple types of namespaces (e.g., a mount namespace, a process ID (PID) namespace, a user ID namespace, etc.). One type of namespace may be a network namespace (e.g., network namespace  351  and network namespace  361 ). A network namespace may include its own network stack. For example, network namespace  351  includes network stack  353  and network namespace  361  includes network stack  363 . Each of network stack  353  and network stack  363  may include a set of IP addresses, routing tables, socket listings, firewall, and various other network related resources. 
     In one embodiment, network namespace  351  may be separate from network namespace  361 . Thus, network stack  352  is separate from network  363 . This may allow applications, programs, processes, services, OSes, etc., within container  120  to modify network stack  353  (e.g., to add a new route in a routing table) without affecting network stack  363 . This may allow applications, programs, processes, services, OSes, etc., within container  250  to modify network stack  363  (e.g., to add a new route in a routing table) without affecting network stack  353 . 
     As discussed above, although the control plane includes OS  118  (as the primary OS), the container  250  also includes OS  251 . OS  251  may be a complete or standalone OS. Because OS  251  is a complete or standalone OS, OS  251  includes drivers  252  and processes  253  (e.g., operating system processes). In addition, because OS  251  is a complete or standalone OS, processes  253  may expect to be able to modify a network stack when executing or operating. For example, a process  253  may modify an IP route table, an ARP table, etc., because the OS  251  generally expects to have access to the network stack when OS  251  operates as a primary OS. However, because OS  118  may be the primary OS for network device  300 , processes  253  of OS  251  should not modify the network stack (e.g., network stack  353 ) used by OS  118 . By including container  250  in a separate network namespace  361 , processes  253  and/or OS  251  may continue to operate as normal and modify network stack  363 . Because network stack  363  is part of network namespace  361 , processes  253  and/or OS  251  may modify network stack  363  without affecting other network stacks used by the network device  300 . For example, process  253  and/or OS  251  may modify network stack  363  without affecting network stack  353 , which may be the primary network stack used to configure and/or manage network resources of network device  300 . In some embodiments, network stack  353  and/or network stack  363  may be located within one or more containers. For example, network stack  353  may be located within container  120  and network stack  363  may be located within container  250 . 
     In one embodiment, agent  254  may be allowed to make certain modifications to network stack  353 . For example, agent  254  may be allowed to create an interface, such as kernel interface, in network stack  353 . The interface may correspond with a network interface (e.g., a network interface, a port, etc.). Agent  254  may communicate with container  120  and/or library  221  to determine what type of operations and/or modifications to the network stack  353  the agent is allowed to perform. For example, agent  254  may request permission and making a modification to network stack  353  and library  221  may grant agent  254  to make the modification. In another example, agent  254  may receive a list of operations/modifications from library  221 . In another embodiment, agent  254  may also be allowed to transmit and/or receive data via the data plane. For example, agent  254  may be allowed to receive a packet via the data plane and/or network stack  353  and may forward the data to the container  120  or the OS  118 . 
       FIG. 4A  is a flow diagram of a method  400  of accessing processing devices, such as forwarding engines, in a data plane of network device, in accordance with some embodiments. Method  400  may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, a processor, a processing device, a central processing unit (CPU), a system-on-chip (SoC), etc.), software (e.g., instructions running/executing on a processing device), firmware (e.g., microcode), or a combination thereof. In some embodiments, method  400  may be performed by a network device (e.g., network device  200  and  300  illustrated in  FIGS. 2 and 3 ), an agent (e.g., agent  254  illustrated in  FIGS. 2 and 3 ), and/or a processing device (e.g., processing device  108  illustrated in  FIGS. 2 and 3 ). It should be appreciated that the actions of method  400  in  FIG. 4A  can be performed in differing orders, groupings, or subsets than shown in  FIG. 4A , for various purposes or user preferences. 
     Method  400  begins at block  405  where the agent identifies the type of the forwarding engines (e.g., processing devices, ASICs, etc.) used in a data plane of the network device. For example, the agent may query the forwarding engines to determine their make and/or model numbers. In another example, the agent may access a configuration file to determine the type of the forwarding engines. At block  410 , the agent may identify the driver (or multiple drivers) that may be used to access, manage, communicate with, and/or perform operations on the processing device. For example, the agent may access a table that correlates different types of forwarding engines with different drivers. 
     At block  415 , the agent may receive a request for a forwarding engine to perform an operation. For example, the agent may receive a request to access a forwarding engine and read the value of a configuration setting used by the forwarding engine. The request may be received by an agent of a first container, as discussed above. The request may originate from a library of a second container, as discussed above. At block  420 , the agent may provide the request to an operating system of the first container. As discussed above, the operation system may include various drivers that are used to access the forwarding engines. The operating system may perform the requested operation using the driver identified in block  410 . In some embodiments, blocks  405  and  410  may be performed after blocks  415  and/or  420 . For example, after receiving the request for the forwarding engine to perform an operation, the agent may identify the type of forwarding engines and may identify a driver for the forwarding engines. 
     At block  430 , the agent may determine if a result of the operation should be provided to the library and/or second container. For example, the agent may analyze the operation that was requested and determine whether the operation should return a result (e.g., return a value of a configuration parameter, return a value indicating success/failure, etc.). If result should be provided to the library and/or second container, the method  400  may transmit a message indicating the result, to the library and/or second container at block  435 . 
     As discussed above, specific drivers or libraries are used to access, communicate with, and/or manage processing device. The primary host OS of the network device may not include the drivers and/or libraries. This results in additional work and time on part of the user to manage the different drivers that may be used by different types of processing devices. For example, if new processing devices are added to network device, new libraries or drivers should be added to allow control plane to access, communicate with, and/or manage the new processing devices. By using a separate, standalone or complete operation system, the network device may use the drivers and/or libraries included in the standalone OS to access, communicate with, manage, and/or perform operations using many different types of processing devices in the data plane. This may simplify the task of managing all of the different types of drivers and/or libraries, which was previously performed by the user. In addition, this allows simpler function calls, APIs, procedures, etc., to be used, rather than including a driver for a particular type of processing device. Furthermore, as the standalone OS is updated (e.g., new patches or releases are provided), the standalone OS may obtain new drivers and/or libraries that may be used for new devices (e.g., new types of FEs). 
       FIG. 4B  is a flow diagram of a method  450  of accessing one or more network stacks, in accordance with some embodiments. Method  450  may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, a processor, a processing device, a central processing unit (CPU), a system-on-chip (SoC), etc.), software (e.g., instructions running/executing on a processing device), firmware (e.g., microcode), or a combination thereof. In some embodiments, method  450  may be performed by a network device (e.g., network device  200  and  300  illustrated in  FIGS. 2 and 3 ), an agent (e.g., agent  254  illustrated in  FIGS. 2 and 3 ), an OA (e.g., OS  251  illustrated in  FIGS. 2 and 3 ), and/or a processing device (e.g., processing device  108  illustrated in  FIGS. 2 and 3 ). It should be appreciated that the actions of method  450  in  FIG. 4B  can be performed in differing orders, groupings, or subsets than shown in  FIG. 4B , for various purposes or user preferences. As discussed a network device may include two network namespaces. Each network namespace may include its own network stack. The first network stack in the first network namespace may a primary network stack used by the network device. 
     Method  450  begins at block  455  where the agent and/or OS determines whether a modification to the primary network stack. For example, if the modification to the network stack is to add a new interface (e.g., a kernel interface), the agent and/or OS may be allowed to make that modification to the primary network stack. The agent and/or OS may access a table, a configuration file, configuration settings, parameters, etc., to determine which modifications and/or types of modifications (or operations) are allowed on the primary network stack. If the modification is allowed, the agent and/or OS may modify and/or access the primary network stack at block  480 . If the modification is not allowed, the agent and/or OS may modify and/or access a second network stack in the second namespace at block  465 . 
       FIG. 5  shows an example computing device  500 , in accordance with some embodiments. For example, the computing device  500  may be implemented including a network device  100  as shown in  FIG. 1 . Note that while  FIG. 5  illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components as such details are not germane to the present invention. It will also be appreciated that network computers and other data processing systems or other consumer electronic devices, which have fewer components or perhaps more components, may also be used with the present invention. 
     As shown in  FIG. 5 , the computing device  500 , which is a form of a data processing system, includes a bus  503  which is coupled to a microprocessor(s)  505  and a ROM (Read Only Memory)  507  and volatile RAM  509  and a non-volatile memory  511 . The microprocessor  505  may retrieve the instructions from the memories  507 ,  509 ,  511  and execute the instructions to perform operations described above. The bus  503  interconnects these various components together and also interconnects these components  505 ,  507 ,  509 , and  511  to a display controller and display device  517  and to peripheral devices such as input/output (I/O) devices which may be mice, keyboards, modems, network interfaces, printers and other devices which are well known in the art. In one embodiment, the computing device  500  includes a plurality of network interfaces of the same or different type (e.g., Ethernet copper interface, Ethernet fiber interfaces, wireless, and/or other types of network interfaces). In this embodiment, the computing device  500  can include a forwarding engine to forward network data received on one interface out another interface. 
     Typically, the input/output devices  515  are coupled to the system through input/output controllers  513 . The volatile RAM (Random Access Memory)  509  is typically implemented as dynamic RAM (DRAM), which requires power continually in order to refresh or maintain the data in the memory. 
     The mass storage  511  is typically a magnetic hard drive or a magnetic optical drive or an optical drive or a DVD ROM/RAM or a flash memory or other types of memory systems, which maintains data (e.g., large amounts of data) even after power is removed from the system. Typically, the mass storage  511  will also be a random access memory although this is not required. While  FIG. 5  shows that the mass storage  511  is a local device coupled directly to the rest of the components in the data processing system, it will be appreciated that the present invention may utilize a non-volatile memory which is remote from the system, such as a network storage device which is coupled to the data processing system through a network interface such as a modem, an Ethernet interface or a wireless network. The bus  503  may include one or more buses connected to each other through various bridges, controllers and/or adapters as is well known in the art. 
       FIG. 6  is a block diagram of one embodiment of exemplary network device  600 , in accordance with some embodiments. In  FIG. 6 , the midplane  606  couples to the line cards  602 A-N and controller cards  604 A-B. The midplane  606  may also be referred to as a fabric. While in one embodiment, the controller cards  604 A-B control the processing of the traffic by the line cards  602 A-N, in alternate embodiments, the controller cards  604 A-B, perform the same and/or different functions (e.g., updating a software image on the network device, etc.). In one embodiment, the line cards  602 A-N process and forward traffic according to the network policies received from the controller cards  604 A-B. In one embodiment, the controller cards  604 A-B may include containers, operating systems, and/or agents, as discussed above. It should be understood that the architecture of network device  600  illustrated in  FIG. 6  is exemplary, and different combinations of cards may be used in other embodiments. 
     Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract”) instructions into processor specific instructions (e.g., an abstract execution environment such as a “process virtual machine” (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.), and/or, electronic circuitry disposed on a semiconductor chip (e.g., “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code. 
     Detailed illustrative embodiments are disclosed herein. However, specific functional details disclosed herein are merely representative for purposes of describing embodiments. Embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein. It should be appreciated that descriptions of direction and orientation are for convenience of interpretation, and the apparatus is not limited as to orientation with respect to gravity. In other words, the apparatus could be mounted upside down, right side up, diagonally, vertically, horizontally, etc., and the descriptions of direction and orientation are relative to portions of the apparatus itself, and not absolute. 
     It should be understood that although the terms first, second, etc. may be used herein to describe various steps or calculations, these steps or calculations should not be limited by these terms. These terms are only used to distinguish one step or calculation from another. For example, a first calculation could be termed a second calculation, and, similarly, a second step could be termed a first step, without departing from the scope of this disclosure. As used herein, the term “and/or” and the “/” symbol includes any and all combinations of one or more of the associated listed items. 
     As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “includes”, and/or “including”, when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Therefore, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. 
     It should also be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two blocks in a figure shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved. 
     With the above embodiments in mind, it should be understood that the embodiments might employ various computer-implemented operations involving data stored in computer systems. These operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing. Any of the operations described herein that form part of the embodiments are useful machine operations. The embodiments also relate to a device or an apparatus for performing these operations. The apparatus can be specially constructed for the required purpose, or the apparatus can be a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general-purpose machines can be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations. 
     A module, an application, a layer, an agent or other method-operable entity could be implemented as hardware, firmware, or a processor executing software, or combinations thereof. It should be appreciated that, where a software-based embodiment is disclosed herein, the software can be embodied in a physical machine such as a controller. For example, a controller could include a first module and a second module. A controller could be configured to perform various actions, e.g., of a method, an application, a layer or an agent. 
     The embodiments can also be embodied as computer readable code on a tangible non-transitory computer readable medium. The computer readable medium is any data storage device that can store data, which can be thereafter read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion. Embodiments described herein may be practiced with various computer system configurations including hand-held devices, tablets, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The embodiments can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wire-based or wireless network. 
     Although the method operations were described in a specific order, it should be understood that other operations may be performed in between described operations, described operations may be adjusted so that they occur at slightly different times or the described operations may be distributed in a system which allows the occurrence of the processing operations at various intervals associated with the processing. 
     Various units, circuits, or other components may be described or claimed as “configured to” or “configurable to” perform a task or tasks. In such contexts, the phrase “configured to” or “configurable to” is used to connote structure by indicating that the units/circuits/components include structure (e.g., circuitry) that performs the task or tasks during operation. As such, the unit/circuit/component can be said to be configured to perform the task, or configurable to perform the task, even when the specified unit/circuit/component is not currently operational (e.g., is not on). The units/circuits/components used with the “configured to” or “configurable to” language include hardware—for example, circuits, memory storing program instructions executable to implement the operation, etc. Reciting that a unit/circuit/component is “configured to” perform one or more tasks, or is “configurable to” perform one or more tasks, is expressly intended not to invoke 35 U.S.C. 112, sixth paragraph, for that unit/circuit/component. Additionally, “configured to” or “configurable to” can include generic structure (e.g., generic circuitry) that is manipulated by software and/or firmware (e.g., an FPGA or a general-purpose processor executing software) to operate in manner that is capable of performing the task(s) at issue. “Configured to” may also include adapting a manufacturing process (e.g., a semiconductor fabrication facility) to fabricate devices (e.g., integrated circuits) that are adapted to implement or perform one or more tasks. “Configurable to” is expressly intended not to apply to blank media, an unprogrammed processor or unprogrammed generic computer, or an unprogrammed programmable logic device, programmable gate array, or other unprogrammed device, unless accompanied by programmed media that confers the ability to the unprogrammed device to be configured to perform the disclosed function(s). 
     The foregoing description, for the purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the embodiments and its practical applications, to thereby enable others skilled in the art to best utilize the embodiments and various modifications as may be suited to the particular use contemplated. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.