Abstract: A system for facilitating efficient port reconfiguration at a switch is provided. During operation, the system can identify a target port of the switch for reconfiguration based on one or more reconfiguration parameters indicating how a set of logical ports are generated from the target port. The system can disable the target port at the control plane of the switch, which disables features provided to the target port from the control plane. The control plane can provide a set of features supported by the switch at a port-level granularity for facilitating operations of the switch. The system can then configure the forwarding hardware based on the reconfiguration parameters to accommodate the set of logical ports. When the reconfiguration of the target port is complete, the system can enable a respective logical port at the control plane, which enables one or more features for the logical port from the control plane.

Abstract: One aspect of the present technology can provide a system for facilitating in-service software upgrade (ISSU) for a switch in a virtual switching stack. During operation, the system can initiate ISSU that facilitate uninterrupted traffic flow. The system can upgrade a first set of daemons of the switch that manage operations of the switch. The system can also upgrade a database stored on the switch. The database can store operational information of the switch. The system can further upgrade a second set of daemons of the switch that configure forwarding information on the forwarding hardware of the switch and facilitate data-plane operations for the switch. The forwarding information configured on the forwarding hardware can remain unchanged during the upgrade. The system can configure the upgraded second set of daemons to obtain control-plane information from a standby switch of a conductor switch of the virtual switching stack.

Abstract: One aspect of the present technology can provide a system for facilitating in-service software upgrade (ISSU) for a switch in a virtual switching stack. During operation, the system can initiate ISSU that facilitate uninterrupted traffic flow. The system can upgrade a first set of daemons of the switch that manage operations of the switch. The system can also upgrade a database stored on the switch. The database can store operational information of the switch. The system can further upgrade a second set of daemons of the switch that configure forwarding information on the forwarding hardware of the switch and facilitate data-plane operations for the switch. The forwarding information configured on the forwarding hardware can remain unchanged during the upgrade. The system can configure the upgraded second set of daemons to obtain control-plane information from a standby switch of a conductor switch of the virtual switching stack.

Abstract: A system for facilitating efficient port reconfiguration at a switch is provided. During operation, the system can identify a target port of the switch for reconfiguration based on one or more reconfiguration parameters indicating how a set of logical ports are generated from the target port. The system can disable the target port at the control plane of the switch, which disables features provided to the target port from the control plane. The control plane can provide a set of features supported by the switch at a port-level granularity for facilitating operations of the switch. The system can then configure the forwarding hardware based on the reconfiguration parameters to accommodate the set of logical ports. When the reconfiguration of the target port is complete, the system can enable a respective logical port at the control plane, which enables one or more features for the logical port from the control plane.

Abstract: A system for facilitating efficient port reconfiguration at a switch is provided. During operation, the system can identify a target port of the switch for reconfiguration based on one or more reconfiguration parameters indicating how a set of logical ports are generated from the target port. The system can disable the target port at the control plane of the switch, which disables features provided to the target port from the control plane. The control plane can provide a set of features supported by the switch at a port-level granularity for facilitating operations of the switch. The system can then configure the forwarding hardware based on the reconfiguration parameters to accommodate the set of logical ports. When the reconfiguration of the target port is complete, the system can enable a respective logical port at the control plane, which enables one or more features for the logical port from the control plane.

Abstract: Systems and methods are provided for in-service software upgrades using centralize database versioning and migrations. The systems and methods described herein can intercept protocol messages between a client and a network device and run a first control plane comprising an origin state database and a plurality of un-migrated services. The system can generate a target state data model, wherein an origin state data model associated with the origin state database migrates to the target state data model, and copy the origin state database. The system can migrate second control plane software to the target state database and operate un-migrated services in accordance with the first control plane software and the copied origin state database while operating migrated services in accordance with the second control plane software and the target state database.

Abstract: During operation, the system receives a request, via a REST API, for data stored in a database which uses a schema associated with a current version, wherein the request indicates a version of the REST API. Responsive to determining that the indicated version is a prior version of the REST API which does not correspond to the current version of the database schema, the system: dispatches the request to a translation proxy; applies rules which converts the request to indicate an updated REST API version corresponding to the current version of the schema; obtains results from the database based on the converted request and the applied rules; and returns the results, wherein the prior version of the REST API comprises an old version and wherein the current version of the schema comprises a new version, which enables functionality from the new version to work with the old version.

Abstract: A system for performing in-service software upgrade on a network device is provided. In response to a software-upgrade command, the system generates an upgrade database based on a state database storing both a data-plane state and a control-plane state associated with the network device. The network device is managed by a management unit comprising a data-plane-management sub-unit and a control-plane sub-unit, and the upgrade database stores at least the data-plane state to allow the data-plane-management sub-unit to operate based on the upgrade database. The system separately upgrades the data-plane-management sub-unit and the control-plane sub-unit, without interrupting services provided by the network device. The system monitors the state database and the upgrade database to detect an event associated with the network device. In response to determining a triggering condition being met, the system performs an action to prevent a network outage or error.

Abstract: During operation, the system receives a request, via a REST API, for data stored in a database which uses a schema associated with a current version, wherein the request indicates a version of the REST API. Responsive to determining that the indicated version is a prior version of the REST API which does not correspond to the current version of the database schema, the system: dispatches the request to a translation proxy; applies rules which converts the request to indicate an updated REST API version corresponding to the current version of the schema; obtains results from the database based on the converted request and the applied rules; and returns the results, wherein the prior version of the REST API comprises an old version and wherein the current version of the schema comprises a new version, which enables functionality from the new version to work with the old version.

Abstract: Systems, methods, and computer-readable media are disclosed for performing a hitless upgrade of executable code in the absence of an orchestrator or other upgrade manager. A mechanism is disclosed that utilizes containers to update software functionality, features, or the like without interrupting a service provided by a container and without relying on an orchestrator or other upgrade manager to coordinate the upgrade process. State information indicative of a current state of module(s) within a container is maintained in an external data store such as a state database. A hand-off from a current container to a new container that updates module code/functionality of the current container can be initiated upon determining that a state metric calculated by the old container at a future timestamp matches a state metric independently calculated by the new container at the same timestamp.

Abstract: Examples disclosed herein relate to a method comprising determining, by a control state machine running on a control module, a state for a plurality of modules communicatively coupled to the control module, wherein each module has a corresponding state machine that publishes state information into a centralized database. The method may include publishing, by the control state machine, the target state for each module in the plurality of modules, into the centralized database, wherein each target state is associated with a set of actions to enable the module to achieve the target state. The method may also include determining, by the control state machine, that each module in the plurality of modules has published its new state to the database and initializing, by the control state machine, a process related to at least one module in the plurality of modules.

Abstract: Examples herein disclose preventing multiple radios from simultaneously scanning a same channel. The examples identify a first scan time associated with the multiple radios and determine a second scan time based on the first scan time. The examples prevent the multiple radios from simultaneously scanning the same channel through a coordination of channel scanning of each of the multiple radios based on the second scan time.

Abstract: Examples herein disclose preventing multiple radios from simultaneously scanning a same channel. The examples identify a first scan time associated with the multiple radios and determine a second scan time based on the first scan time. The examples prevent the multiple radios from simultaneously scanning the same channel through a coordination of channel scanning of each of the multiple radios based on the second scan time.

Abstract: A network controller sends a request to a device for radio frequency (RF) environment data. The request is receive via a network interface of the device that includes at least one of a wired interface and a wireless interface. Responsive to the request, the device initiates a RF scan to collect the environment data. The collected RF environment data is transmitted to the network controller via the network interface.

Abstract: A dynamic name of a device within a network may be generated by accessing information related to the device; accessing information related to a remote, neighbor device; generating a dynamic name of the device based on the accessed information related to the device and the accessed information related to the remote, neighbor device; and storing the generated dynamic name of the device. Alternatively, a topology map of devices within a network may be generated where a central controller may access, from memory, a dynamic name of controlled devices, the dynamic name of the controlled devices including information related to remote, neighbor devices of the controlled devices. The topology map may include dynamic names of the controlled devices.

Abstract: A method for management of sampled traffic data is described herein. For each network device of a plurality of network devices, one or more data sources of the network device is determined. Each of the one or more data sources is associated with a local identifier. A sampler proxy receives a sampling configuration from a data collector, The sampling configuration includes a selection of a data source of a network device of the plurality of network devices. The selected data source is identified by a global identifier. The sampling configuration is translated to a local sampling configuration and is provided to the selected data source.

Abstract: A dynamic name of a device within a network may be generated by accessing information related to the device; accessing information related to a remote, neighbor device; generating a dynamic name of the device based on the accessed information related to the device and the accessed information related to the remote, neighbor device; and storing the generated dynamic name of the device. Alternatively, a topology map of devices within a network may be generated where a central controller may access, from memory, a dynamic name of controlled devices, the dynamic name of the controlled devices including information related to remote, neighbor devices of the controlled devices. The topology map may include dynamic names of the controlled devices.