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: A system receives a request for data stored in an OVSDB database server, wherein the request comprises a JSON RPC request. In response to the request, the system initiates a proxy session by: creating a first communication session between the requesting entity and a proxy daemon, wherein the request indicates a first version corresponding to the first communication session; and creating a second communication session between the proxy daemon and the database server, wherein the second communication session is associated with a second version corresponding to a model used by the database server. The system determines that the first version does not match the second version. The system extracts, from the request, a JSON RPC method and determines that the method requires translation. The system performs, based on the first and second version, translation of a payload of the request, and sends the translated payload to the database server.

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: The disclosure provides a method for determining a configuration mismatch between a first device and a second device. During operation, a first device receives a plurality of Unidirectional Link Detection (UDLD) protocol messages from a second device. The first device is configured with a first interval configuration value corresponding to a frequency which the first device sends the UDLD protocol messages to the second device. The first device determines a second interval configuration value of the second device, which corresponds to a frequency which the second device sends the UDLD protocol messages to the first device. The first device determines that there is a configuration mismatch between the first device and the second device, and creates a log entry for the configuration mismatch, the log entry including the first and second interval configuration values.

Abstract: A system receives a request for data stored in an OVSDB database server, wherein the request comprises a JSON RPC request. In response to the request, the system initiates a proxy session by: creating a first communication session between the requesting entity and a proxy daemon, wherein the request indicates a first version corresponding to the first communication session; and creating a second communication session between the proxy daemon and the database server, wherein the second communication session is associated with a second version corresponding to a model used by the database server. The system determines that the first version does not match the second version. The system extracts, from the request, a JSON RPC method and determines that the method requires translation. The system performs, based on the first and second version, translation of a payload of the request, and sends the translated payload to the database server.

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: Examples include receiving a first multicast packet, determining a first flow for the first multicast packet based on a multicast protocol, and storing the first flow in a routing table. The first flow comprises a first source and a first group and the routing table comprises a second flow with a second source and the first group. Additionally, examples include programming the first flow into a hardware memory resource and programming a summary flow into the hardware memory resource. The hardware memory resource comprises the second flow and the summary flow comprises a wild character that matches the first source and the second source.

Abstract: A method and system of failure detection in a computer network, including pre-programming a number of processors of a multi-processor networked system coupled with remote systems via a network, each of the processors configured to run a BFD module. One processor may be assigned to be an active BFD server to establish sessions between the multi-processor networked system and the remote systems to detect link faults between the multi-processor networked system and the remote systems. Other processors may be assigned as dormant BFD clients. If a link or a processor running the active BFD server fails, one of the dormant BFD clients is selected to become an active BFD server. The BFD server may be dynamically replaced with a dormant client based on predetermined criteria without failure of the BFD server.

Abstract: Examples include receiving a first multicast packet, determining a first flow for the first multicast packet based on a multicast protocol, and storing the first flow in a routing table. The first flow comprises a first source and a first group and the routing table comprises a second flow with a second source and the first group. Additionally, examples include programming the first flow into a hardware memory resource and programming a summary flow into the hardware memory resource. The hardware memory resource comprises the second flow and the summary flow comprises a wild character that matches the first source and the second source.

Abstract: Examples disclosed herein relate to a method comprising receiving a control packet originating from a originating network device. The control packet may have a control MAC address identifying the originating network device and the control packet is used for determining a traffic loop in a network including the first network device and the originating network device. The method may include determining, by the first network device, whether the control MAC address of the control packet matches a MAC address of the first network device. Wit is determined that the control MAC address of the control packet matches a MAC address of the first network device, the method may include determining that the match is indicative of the loop and blocking a port of the first network device that the control packet arrived on without blocking any other ports on the first network device.

Abstract: Examples disclosed herein relate to a method comprising receiving requesting, at a first network device, a Bidirectional Forwarding Detection session with a second network device, determining, by the first network device, that the BFD session is for single hop data and determining, by the first network device, that the BFD session is over a network tunnel from the first network device to the second network device. The method may include initiating the BFD session between the first and second network devices, wherein the BFD session is shared between multiple clients requesting BFD sessions on a network tunnel, but is not shared not between tunneled and non-tunneled sessions between the multiple clients. The method may include transmitting, the single hop data to the second network device via the network tunnel, wherein the network tunnel traverses a multiple hop network path and disabling echo packets for the BFD session.

Abstract: Examples disclosed herein relate to a method comprising receiving a bidirectional forwarding detection (BFD) packet originating from a first network device, wherein the first linked network device and a second linked network device are part of a link aggregation group running a BFD session. The method may include transmitting, from the first linked network device, a BFD synchronization packet to the second linked network device and receiving, at the second linked network device, the BFD synchronization packet, wherein a time-to-live (TTL) value of the BFD synchronization packet is lower than a BFD TTL supported by the BFD session. The method may also include determining that the BFD synchronization packet is a BFD single-hop packet coming from a VLANs using the active forwarding mode and determining not to discard the BFD synchronization packet.

Abstract: Examples disclosed herein relate to a method comprising receiving requesting, at a first network device, a Bidirectional Forwarding Detection session with a second network device, determining, by the first network device, that the BFD session is for single hop data and determining, by the first network device, that the BFD session is over a network tunnel from the first network device to the second network device. The method may include initiating the BFD session between the first and second network devices, wherein the BFD session is shared between multiple clients requesting BFD sessions on a network tunnel, but is not shared not between tunneled and non-tunneled sessions between the multiple clients. The method may include transmitting, the single hop data to the second network device via the network tunnel, wherein the network tunnel traverses a multiple hop network path and disabling echo packets for the BFD session.

Abstract: A method and system of failure detection in a computer network, including pre-programming a number of processors of a multi-processor networked system coupled with remote systems via a network, each of the processors configured to run a BFD module. One processor may be assigned to be an active BFD server to establish sessions between the multi-processor networked system and the remote systems to detect link faults between the multi-processor networked system and the remote systems. Other processors may be assigned as dormant BFD clients. If a link or a processor running the active BFD server fails, one of the dormant BFD clients is selected to become an active BFD server. The BFD server may be dynamically replaced with a dormant client based on predetermined criteria without failure of the BFD server.

Abstract: A network infrastructure device supporting communications on one or more network segments is provided, The network infrastructure device may perform an auto-mode detection for an appropriate unidirectional link detection (UDLD) protocol to be used between network neighbors of the network infrastructure device. The auto-mode detection may include a detection phase to detect a UDLD mode available within a network segment (e.g., supported by a pair of neighboring devices). A first UDLD mode from a set of supported UDLD modes for the network infrastructure device may be sent to neighboring devices; responses may be analyzed; and based on responses (or lack thereof) a mode may be selected, or other supported modes may be attempted, After negotiation, via the detection phase, and operational phase may be entered. A resultant network may have a network infrastructure device that concurrently supports different UDLD modes for different neighboring devices where each was automatically negotiated.

Abstract: Examples disclosed herein relate to a method comprising receiving a bidirectional forwarding detection (BFD) packet originating from a first network device, wherein the first linked network device and a second linked network device are part of a link aggregation group running a BFD session. The method may include transmitting, from the first linked network device, a BFD synchronization packet to the second linked network device and receiving, at the second linked network device, the BFD synchronization packet, wherein a time-to-live (TTL) value of the BFD synchronization packet is lower than a BFD TTL supported by the BFD session. The method may also include determining that the BFD synchronization packet is a BFD single-hop packet coming from a VLANs using the active forwarding mode and determining not to discard the BFD synchronization packet.

Abstract: An access point is to provide a wireless beacon packet via a wireless communication. The wireless beacon packet is to include an event notification in response to an indication of a need for the event notification.

Abstract: An access point is to provide a wireless beacon packet via a wireless communication. The wireless beacon packet is to include an event notification in response to an indication of a need for the event notification.

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 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.