PRE-BUILD VALIDATION OF DISTRIBUTED DISAGGREGATED WHITE BOX ROUTING SYSTEMS

Methods, computer-readable media, and systems for performing pre-build validation of distributed disaggregated white box routing systems are disclosed. One method includes connecting, via a physical network connection, to a distributed, disaggregated white box routing system comprising a plurality of hardware components connected by a plurality of cable connections and a plurality of interfaces, executing a software program simulating a network operating system of a network operator, analyzing, while the software program is executing and the distributed, disaggregated white box routing system is connected via the physical network connection, the plurality of hardware components, the plurality of cable connections, and the plurality of interfaces, determining that an error is detected in at least one of: the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system, and generating a report showing at least one of: a location or a nature of the error.

The present disclosure relates generally to network architecture, and relates more particularly to devices, non-transitory computer-readable media, and methods for performing pre-build validation of distributed disaggregated white box routing systems.

BACKGROUND

White box networking provides the ability to deploy generic (i.e., non-proprietary), commodity off-the-shelf switches or routers with an independent network operating system (NOS) that drives Layer 2 and Layer 3 intelligence. White box switches and routers with independent NOSs can offer significant benefits in terms of cost and operational flexibility. For instance, white box routing systems can be deployed at cell tower locations in order to bring more flexible compute power to the network edge, where more and more data processing is expected to occur. Autonomous vehicles, augmented reality applications, and other low-latency applications that require mobility will rely on servers placed closer to the network endpoints rather than in remote data centers.

Distributed disaggregated white box routing systems can be very large in size, with over one hundred physical components (white boxes) being interconnected by hundreds of fiber optic connections.

SUMMARY

The present disclosure broadly discloses methods, computer-readable media, and systems for performing pre-build validation of distributed disaggregated white box routing systems. In one example, a method performed by a processing system including at least one processor includes connecting, via a physical network connection, to a distributed, disaggregated white box routing system comprising a plurality of hardware components connected by a plurality of cable connections and a plurality of interfaces, executing a software program simulating a network operating system of a network operator, analyzing, while the software program is executing and the distributed, disaggregated white box routing system is connected via the physical network connection, the plurality of hardware components, the plurality of cable connections, and the plurality of interfaces, determining that an error is detected in at least one of: the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system, and generating a report showing at least one of: a location or a nature of the error.

In another example, a non-transitory computer-readable medium may store instructions which, when executed by a processing system including at least one processor, wherein the processing system being connected, via a physical network connection, to a distributed, disaggregated white box routing system comprising a plurality of hardware components connected by a plurality of cable connections and a plurality of interfaces, cause the processing system to perform operations. The operations may include executing a software program simulating a network operating system of a network operator, analyzing, while the software program is executing and the distributed, disaggregated white box routing system is connected via the physical network connection, the plurality of hardware components, the plurality of cable connections, and the plurality of interfaces, determining that an error is detected in at least one of: the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system, and generating a report showing at least one of: a location or a nature of the error.

In another example, a device may include a processing system including at least one processor, wherein the processing system being connected, via a physical network connection, to a distributed, disaggregated white box routing system comprising a plurality of hardware components connected by a plurality of cable connections and a plurality of interfaces, and a non-transitory computer-readable medium storing instructions which, when executed by the processing system, cause the processing system to perform operations. The operations may include executing a software program simulating a network operating system of a network operator, analyzing, while the software program is executing and the distributed, disaggregated white box routing system is connected via the physical network connection, the plurality of hardware components, the plurality of cable connections, and the plurality of interfaces, determining that an error is detected in at least one of: the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system, and generating a report showing at least one of: a location or a nature of the error.

To facilitate understanding, similar reference numerals have been used, where possible, to designate elements that are common to the figures.

DETAILED DESCRIPTION

The present disclosure broadly discloses methods, computer-readable media, and systems for performing pre-build validation of distributed disaggregated white box routing systems. White box networking provides the ability to deploy generic (i.e., non-proprietary), commodity off-the-shelf switches or routers with an independent network operating system (NOS) that drives Layer 2 and Layer 3 intelligence. White box switches and routers with independent NOSs can offer significant benefits in terms of cost and operational flexibility. For instance, white box routing systems can be deployed at cell tower locations in order to bring more flexible compute power to the network edge, where more and more data processing is expected to occur. Autonomous vehicles, augmented reality applications, and other low-latency applications that require mobility will rely on servers placed closer to the network endpoints rather than in remote data centers.

Distributed disaggregated white box routing systems can be very large in size, with over one hundred physical components (white boxes) being interconnected by hundreds of fiber optic connections. As such, one of the biggest challenges in constructing a distributed disaggregated white box routing system is ensuring the integrity of the fiber optic interconnection links. During a typical deployment, after the physical installation of the system is completed, technicians will download the NOS into the system management modules, which in turn distribute the NOS to all system components and attempt to spin up the routing system. It is common during this phase to discover issues with the optical fibers, optical interfaces, and/or physical components which were not discoverable during the physical installation, because such issues are not apparent until the NOS is loaded.

During a conventional roll out of a distributed disaggregated white box routing system, errors in physical installation may cause an average delay of approximately twenty installation days once the equipment verification testing (EVT) phase has started. Since a typical installation day may cost approximately $2,500, a delay of this magnitude may cost a network operator as much as $50,000. For a typical Tier 2 or Tier 3 network operator that may deploy fifty or more of such routing systems per year, this translates into approximately $2.5 million. For Tier 1 network operators, the costs may be exponentially higher.

Examples of the present disclosure provide an air-gapped, hardened portable computing device (e.g., a laptop or tablet computer) that simulates a network operator's control and management network in order to monitor the fiber optic interconnection links of a distributed disaggregated white box routing system while the routing system is under construction (e.g., being cabled), without violating network security and integrity. This disclosed approach enables temporary on-site loading of NOS software and associated firmware packages prior to network interconnection. With the NOS software loaded, the routing system can discover and validate the internal cabling and allow technicians to see the connectivity in near-real time. Once the routing system is fully connected and all interconnections have been validated, the temporary NOS can be removed, leaving the routing system in a state that is ready to connect to the network operator's actual control and management network following routine, secure turn-up guidelines.

By detecting errors in the physical installations prior to the start of formal EVT, a network operator may be able to significantly reduce the number of installation days lost and therefore minimize the costs associated with such losses to tens of thousands of dollars, as opposed to millions, over the span of a year. These and other aspects of the present disclosure are discussed in greater detail below in connection with the examples ofFIGS.1-3.

To further aid in understanding the present disclosure,FIG.1illustrates an example system100in which examples of the present disclosure for performing pre-build validation of distributed disaggregated white box routing systems may operate. The system100may include any one or more types of communication networks, such as a traditional circuit switched network (e.g., a public switched telephone network (PSTN)) or a packet network such as an Internet Protocol (IP) network (e.g., an IP Multimedia Subsystem (IMS) network), an asynchronous transfer mode (ATM) network, a wired network, a wireless network, and/or a cellular network (e.g., 2G-5G, a long term evolution (LTE) network, and the like) related to the current disclosure. It should be noted that an IP network is broadly defined as a network that uses Internet Protocol to exchange data packets. Additional example IP networks include Voice over IP (VOIP) networks, Service over IP (SoIP) networks, the World Wide Web, and the like.

In one example, the system100may comprise a core network102. The core network102may be in communication with one or more access networks120and122, and with the Internet124. In one example, the core network102may functionally comprise a fixed mobile convergence (FMC) network, e.g., an IP Multimedia Subsystem (IMS) network. In addition, the core network102may functionally comprise a telephony network, e.g., an Internet Protocol/Multi-Protocol Label Switching (IP/MPLS) backbone network utilizing Session Initiation Protocol (SIP) for circuit-switched and Voice over Internet Protocol (VOIP) telephony services. In one example, the core network102may include at least one application server (AS)104, a database (DB)106, and a plurality of edge routers128-130. For ease of illustration, various additional elements of the core network102are omitted fromFIG.1.

In one example, the access networks120and122may comprise Digital Subscriber Line (DSL) networks, public switched telephone network (PSTN) access networks, broadband cable access networks, Local Area Networks (LANs), wireless access networks (e.g., an IEEE 802.11/Wi-Fi network and the like), cellular access networks, 3rd party networks, and the like. For example, the operator of the core network102may provide a cable television service, an IPTV service, or any other types of telecommunication services to subscribers via access networks120and122. In one example, the access networks120and122may comprise different types of access networks, may comprise the same type of access network, or some access networks may be the same type of access network and other may be different types of access networks. In one example, the core network102may be operated by a telecommunication network service provider (e.g., an Internet service provider, or a service provider who provides Internet services in addition to other telecommunication services). The core network102and the access networks120and122may be operated by different service providers, the same service provider or a combination thereof, or the access networks120and/or122may be operated by entities having core businesses that are not related to telecommunications services, e.g., corporate, governmental, or educational institution LANs, and the like.

In one example, the access network120may be in communication with one or more user endpoint devices (UEs)108and110. Similarly, the access network122may be in communication with one or more user endpoint devices112and114. The access networks120and122may transmit and receive communications between the user endpoint devices108,110,112, and114, between the user endpoint devices108,110,112, and114, the server(s)126, the AS104, other components of the core network102, devices reachable via the Internet in general, and so forth. In one example, each of the user endpoint devices108,110,112, and114may comprise any single device or combination of devices that may comprise a user endpoint device, such as computing system300depicted inFIG.3, and may be configured as described below. For example, the user endpoint devices108,110,112, and114may each comprise a mobile device, a cellular smart phone, a gaming console, a set top box, a laptop computer, a tablet computer, a desktop computer, an autonomous vehicle, an extended reality (XR) device, an application server, a bank or cluster of such devices, and the like.

The AS104may cooperate with a software client running on one or more of the user endpoint devices108,110,112, and114to provide one or more services to the user endpoint devices108,110,112, and114. For instance, the AS104may host an application that provides streaming media (e.g., streaming video or music) services, that provides an extended reality (e.g., virtual reality, mixed reality, augmented reality, and or the like) video game or other application, or provides another service. Providing the service may, in some examples, involve retrieving data (e.g., video files, audio files, or the like) from the DB106.

In one example, one or more of the servers126and one or more of the databases (DBs)132may be accessible to user endpoint devices108,110,112, and114and to the AS104via Internet124in general. The server(s)126and DBs132may operate in a manner similar to the AS104and DB106, as described in further detail below.

In one example, the DB106may comprise a physical storage device integrated with the AS104(e.g., a database server or a file server), or attached or coupled to the AS104, in accordance with the present disclosure. In one example, the AS104may load instructions into a memory, or one or more distributed memory units, and execute instructions for providing a service to user endpoint devices108,110,112, and114.

In one example, one or more of the edge routers128and130may comprise a distributed, disaggregated routing system. Taking edge router128as an example, the distributed, disaggregated white box routing system may comprise a plurality of hardware components connected by a plurality of cable connections and a plurality of interfaces. In one example, the plurality of hardware components may comprise a plurality of generic (i.e., not proprietary), off-the-shelf modules. These modules may include one or more of: network cloud packet forwarder (NCP) modules, network cloud fabric (NCF) modules, network cloud controller (NCC) modules, or network configuration management (NCM) modules.

As discussed above, one of the biggest challenges in constructing a distributed disaggregated white box routing system is ensuring the integrity of the fiber optic interconnection links. In one example, a portable computing system116(e.g., a laptop computer, a tablet computer, or the like) may be connected to the distributed, disaggregated routing system via a physical network connection118. The portable computing system116may comprise a single-purpose tool that performs a single function, i.e., to run a software program that simulates a network operator's disaggregated NOS (or dNOS). The basic input/output system (BIOS) settings and configurations of the portable computing device116may be configured to disable access to all other functions of the portable computing device116(i.e., such that running the software program that simulates the dNOS is the only function the portable computing device116is capable of performing without being reconfigured). For instance, WiFi and Bluetooth may be disabled, as well as wake-on local area network (LAN), camera, global positioning system (GPS), secure boot mode, and other ancillary equipment. This ensures that the physical network connection118between the portable computing device116and the distributed, disaggregated white box routing system is secure and not vulnerable to outside threats. The internal Ethernet port of the portable computing device116may remain enabled.

Moreover, the BIOS settings and configurations of the portable computing device116may be configured to impose specific guidelines on a human technician for connecting the portable computing device116to the distributed, disaggregated white box routing system. For instance, the BIOS settings and configurations may be configured to guide the technician in making the physical (e.g., wired) network connections between the portable computing device116and the distributed, disaggregated white box routing system. In other words, the BIOS settings and configurations may be configured to instruct the technician as to which ports of the portable computing device116and which ports of the distributed, disaggregated white box routing system should be connected by which wired connections. One example method for performing pre-build validation of distributed disaggregated white box routing systems, such as may be performed by the portable computing device116once properly connected to the distributed, disaggregated white box routing system, is described in greater detail below in connection withFIG.2.

In one example, the physical network connection118illustrated inFIG.1represents a plurality of individual cabled connections, one or more of which may include a switch. For instance, in one example, the integrated lights-out (ILO) and management (MGT) ports 0 and 1 of an NCC module of the distributed, disaggregated white box routing system may be disconnected from other switches. Dynamic host configuration protocol (DHCP) may be turned off on the NCC module, and a static IP address maybe set up for the NCC's iLO ports via universal serial bus (USB) ports on the NCC to a monitor and keyboard of the portable computing device116. A static IP address may also be set up for the NCC's MGT port 0 via Terminal on the portable computing device116. The integrated lights-out (ILO) and management (MGT) ports 0 and 1 of an NCC module may then be connected to the portable computing device116via an Ethernet switch.

It should be noted that the system100has been simplified. Thus, those skilled in the art will realize that the system100may be implemented in a different form than that which is illustrated inFIG.1, or may be expanded by including additional endpoint devices, access networks, network elements, application servers, etc. without altering the scope of the present disclosure. In addition, system100may be altered to omit various elements, substitute elements for devices that perform the same or similar functions, combine elements that are illustrated as separate devices, and/or implement network elements as functions that are spread across several devices that operate collectively as the respective network elements.

For example, the system100may include other network elements (not shown) such as border elements, routers, switches, policy servers, security devices, gateways, a content distribution network (CDN) and the like. For example, portions of the core network102, access networks120and122, and/or Internet124may comprise a content distribution network (CDN) having ingest servers, edge servers, and the like. Similarly, although only two access networks,120and122are shown, in other examples, access networks120and/or122may each comprise a plurality of different access networks that may interface with the core network102independently or in a chained manner. For example, UE devices108,110,112, and114may communicate with the core network102via different access networks, user endpoint devices110and112may communicate with the core network102via different access networks, and so forth. Thus, these and other modifications are all contemplated within the scope of the present disclosure.

FIG.2illustrates a flowchart of an example method200for performing pre-build validation of distributed disaggregated white box routing systems, in accordance with the present disclosure. In one example, steps, functions and/or operations of the method200may be performed by a device as illustrated inFIG.1, e.g., a portable computing device116or any one or more components thereof. In another example, the steps, functions, or operations of method200may be performed by a computing device or system300, and/or a processing system302as described in connection withFIG.3below. For instance, the computing device300may represent at least a portion of portable computing device116in accordance with the present disclosure. For illustrative purposes, the method200is described in greater detail below in connection with an example performed by a processing system, such as processing system302.

The method200begins in step202and proceeds to step204. In step204, the processing system may connect, via a physical network connection, to a distributed, disaggregated white box routing system comprising a plurality of hardware components connected by a plurality of cable connections and a plurality of interfaces.

In one example, the processing system is part of an air-gapped, hardened portable computing device (e.g., a laptop computer, a tablet computer, or the like). In one example, the portable computing device comprises a single-purpose tool that performs a single function, i.e., to run a software program that simulates a network operator's disaggregated NOS (or dNOS). The basic input/output (BIOS) settings and configurations of the portable computing device may be configured to disable access to all other functions of the portable computing device (i.e., such that running the software program that simulates the dNOS is the only function the portable computing device is capable of performing without being reconfigured). This ensures that the connections between the processing system and the distributed, disaggregated white box routing system are secure and not vulnerable to outside threats.

Moreover, the BIOS settings and configurations of the portable computing device may be configured to impose specific guidelines on a human technician for connecting the processing system to the distributed, disaggregated white box routing system. For instance, the BIOS settings and configurations may be configured to guide the technician in making the physical (e.g., wired) network connections between the portable computing device and the distributed, disaggregated white box routing system. In other words, the BIOS settings and configurations may be configured to instruct the technician as to which ports of the portable computing device and which ports of the distributed, disaggregated white box routing system should be connected by which wired connections.

As discussed above, the distributed, disaggregated white box routing system comprises a plurality of hardware components connected by a plurality of cable connections and a plurality of interfaces. In one example, the plurality of hardware components may comprise a plurality of generic (i.e., not proprietary), off-the-shelf modules. These modules may include one or more of: network cloud packet forwarder (NCP) modules, network cloud fabric (NCF) modules, network cloud controller (NCC) modules, or network configuration management (NCM) modules. The plurality of cable connections may comprise fiber optic connections, and the plurality of interfaces may comprise optical interfaces.

In step206, the processing system may execute a software program simulating a network operating system (NOS) of a network operator. As discussed above, the portable computing device of which the processing system is a part may be configured to perform a single function, i.e., to run the software program that simulates the dNOS. Once the processing system is properly connected to the distributed, disaggregated white box routing system, the processing system may run the software program. Running the software program will cause a proxy dNOS to be distributed to the plurality of hardware components. In one example, running the software program may replicate what is referred to as a “call home” operation. In one example, it may take up to two hours to load the dNOS to the distributed, disaggregated white box routing system.

In step208, the processing system may analyze the plurality of hardware components, the plurality of cable connections, and/or the plurality of interfaces while the software program is executing and the processing system is connected to the distributed, disaggregated white box routing system.

For instance, while the software program is executing, the processing system may be able to determine whether there are any errors in any of the cable connections of the plurality of cable connections (e.g., whether any cable connections of the plurality of cable connections are connected to the wrong hardware component of the plurality of hardware components and/or to the wrong port of one of the hardware components of the plurality of hardware components). In one example, if there are any errors in any of the cable connections, the proxy dNOS may fail to be properly distributed to some hardware components of the plurality of hardware components.

The processing system may also be able to determine whether any of the hardware components of the plurality of hardware components are running outdated firmware and/or operating systems, and whether any backplane interconnections are defective or unresponsive.

In step210, the processing system may determine whether any errors are detected in the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system. For instance, an error in the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components may be detected in accordance with the analysis performed in step208.

If the processing system concludes in step210that an error has been detected in at least one of: the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system, then the method200may proceed to step212.

In step212, the processing system may generate a report showing the location(s) and/or nature(s) of the error(s). In one example, the report may identify, for instance, a specific cable connection of the plurality of cable connections that is improperly connected. The report may identify the ports to which the specific cable connection is connected, and may indicate which of these ports is incorrectly connected to the specific cable connection. In a further example, the report may specify the correct port(s) to which the specific cable connection should be connected, so that a technician may resolve the error.

The report may also identify, for instance, a specific hardware component of the plurality of hardware components that is running outdated firmware and/or outdated operating system, and may indicate the firmware and/or operating system that the specific hardware component should be running. In a further example, the report may identify a specific backplane interconnection that is determined to be defective or unresponsive, and may flag the backplane interconnection for replacement of cables and/or optics.

Once the report has been generated, the method200may return to step206, and the processing system may repeat one or more of steps206-210as described above in order to determine whether any errors remain in the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system. For instance, even though the report may have provided the technician with the information to correctly connect a specific cable connection, the technician may still have improperly connected the specific cable connection. Thus, by repeating steps206-210, the processing system can verify that any recommended actions for resolving detected errors have been properly carried out.

In one example, any errors on the NCF and NCP modules may cause visible indicators on the NCF and NCP modules to appear. For instance, a red light emitting diode (LED) may illuminate on an NCF or NCP module that is malfunctioning, running out of date firmware or an out of date operating system or that is improperly connected. Alternatively, no light may illuminate on the NCF or NCP module (where the lack of illuminated indicator indicates an error). In some examples, a green LED may illuminate on a BCF or NCP module whose operation and connections have been validated.

If, on the other hand, the processing system concludes in step210that no errors have been detected in any of the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system, then the method200may proceed to step214.

In step214, the processing system may generate an indication, e.g., a report indicating that the distributed, disaggregated white box routing system is properly connected.

In one example, step214may occur after one or more iterations of steps206-212. For instance, as discussed above, errors may be detected in the plurality of cable connections, the plurality of interfaces, or the plurality of hardware components of the distributed, disaggregated white box routing system, and the processing system may guide a technician in resolving those errors. Repeating steps206-210may ensure that any attempts to resolve the errors were properly carried out. Thus, when the processing system generates the report indicating that the distributed, disaggregated white box routing system is properly connected, this indicates that any errors that were previously detected by prior iterations of steps206-212have been resolved.

Once the processing system has generated a report indicating that the distributed, disaggregated white box routing system is properly connected, the method200may end in step216. Once the method200ends, the portable computing system may be disconnected from the distributed, disaggregated white box routing system, and the network operator's dNOS may be downloaded into the system management modules of the distributed, disaggregated white box routing system for distribution to the plurality of hardware components and for subsequent EVT, system verification testing (SVT), and/or network validation testing (NVT).

Thus, examples of the present disclosure provide an air-gapped, hardened portable computing device (e.g., a laptop or tablet computer) that simulates a network operator's control and management network in order to monitor the fiber optic interconnection links of a distributed disaggregated white box routing system while the routing system is under construction (e.g., being cabled), without violating network security and integrity. This disclosed approach enables temporary on-site loading of NOS software and associated firmware packages prior to network interconnection. With the NOS software loaded, the routing system can discover and validate the internal cabling and allow technicians to see the connectivity in near-real time. Once the routing system is fully connected and all interconnections have been validated, the temporary NOS can be removed, leaving the routing system in a state that is ready to connect to the network operator's actual control and management network following routine, secure turn-up guidelines.

By detecting errors in the physical installations prior to the start of formal EVT, a network operator may be able to significantly reduce the number of installation days lost and therefore minimize the costs associated with such losses to tens of thousands of dollars, as opposed to millions, over the span of a year.

It should be noted that the method200may be expanded to include additional steps or may be modified to include additional operations with respect to the steps outlined above. In addition, although not specifically specified, one or more steps, functions, or operations of the method200may include a storing, displaying, and/or outputting step as required for a particular application. In other words, any data, records, fields, and/or intermediate results discussed in the method can be stored, displayed, and/or outputted either on the device executing the method or to another device, as required for a particular application. Furthermore, steps, blocks, functions or operations inFIG.2that recite a determining operation or involve a decision do not necessarily require that both branches of the determining operation be practiced. In other words, one of the branches of the determining operation can be deemed as an optional step. Furthermore, steps, blocks, functions or operations of the above described method can be combined, separated, and/or performed in a different order from that described above, without departing from the examples of the present disclosure.

FIG.3depicts a high-level block diagram of a computing device or processing system specifically programmed to perform the functions described herein. As depicted inFIG.3, the processing system300comprises one or more hardware processor elements302(e.g., a central processing unit (CPU), a microprocessor, or a multi-core processor), a memory304(e.g., random access memory (RAM) and/or read only memory (ROM)), a module305for performing pre-build validation of distributed disaggregated white box routing systems, and various input/output devices306(e.g., storage devices, including but not limited to, a tape drive, a floppy drive, a hard disk drive or a compact disk drive, a receiver, a transmitter, a speaker, a display, a speech synthesizer, an output port, an input port and a user input device (such as a keyboard, a keypad, a mouse, a microphone and the like)). Although only one processor element is shown, it should be noted that the computing device may employ a plurality of processor elements. Furthermore, although only one computing device is shown in the figure, if the method200as discussed above is implemented in a distributed or parallel manner for a particular illustrative example, i.e., the steps of the above method200or the entire method200is implemented across multiple or parallel computing devices, e.g., a processing system, then the computing device of this figure is intended to represent each of those multiple computing devices.

Furthermore, one or more hardware processors can be utilized in supporting a virtualized or shared computing environment. The virtualized computing environment may support one or more virtual machines representing computers, servers, or other computing devices. In such virtualized virtual machines, hardware components such as hardware processors and computer-readable storage devices may be virtualized or logically represented. The hardware processor302can also be configured or programmed to cause other devices to perform one or more operations as discussed above. In other words, the hardware processor302may serve the function of a central controller directing other devices to perform the one or more operations as discussed above.

It should be noted that the present disclosure can be implemented in software and/or in a combination of software and hardware, e.g., using application specific integrated circuits (ASIC), a programmable gate array (PGA) including a Field PGA, or a state machine deployed on a hardware device, a computing device or any other hardware equivalents, e.g., computer readable instructions pertaining to the method discussed above can be used to configure a hardware processor to perform the steps, functions and/or operations of the above disclosed method200. In one example, instructions and data for the present module or process305for performing pre-build validation of distributed disaggregated white box routing systems (e.g., a software program comprising computer-executable instructions) can be loaded into memory304and executed by hardware processor element302to implement the steps, functions, or operations as discussed above in connection with the illustrative method200. Furthermore, when a hardware processor executes instructions to perform “operations,” this could include the hardware processor performing the operations directly and/or facilitating, directing, or cooperating with another hardware device or component (e.g., a co-processor and the like) to perform the operations.

While various examples have been described above, it should be understood that they have been presented by way of illustration only, and not a limitation. Thus, the breadth and scope of any aspect of the present disclosure should not be limited by any of the above-described examples, but should be defined only in accordance with the following claims and their equivalents.