Abstract: A method for transmitting a packet vector across compute nodes implementing a packet processing graph on a vector packet processor is disclosed. The method includes determining that a packet vector processed by a previous graph node in a first compute node is ready to be processed by a next graph node in a second compute node. The packet vector includes a plurality of data packets and the previous and next graph nodes are graph nodes of a packet processing graph implemented as a directed acyclic graph (“DAG”) that extends across the first and second compute nodes. The first and second compute nodes each run an instance of a vector packet processor. The method includes transmitting the packet vector from the first compute node to the second compute node using remote direct memory access (“RDMA”).

Abstract: A method for a VXLAN extension header for segment routing includes receiving a data packet at a node of a data pathway between an ingress node and an egress node. The data packet includes a tunneling protocol header followed by a segment routing header ahead of a payload and the segment routing header includes a list of identifiers of nodes in the data pathway. The method includes processing the segment routing header to address the data packet to be transmitted to a next node listed in the segment routing header and to update a pointer in the segment routing header, and transmitting the data packet to a next node based on the address of the next node.

Abstract: Capturing data packets for analysis using a virtual machine including receiving, at an analyzer virtual machine, an encapsulated packet for analysis, wherein the encapsulated packet comprises a monitoring metadata header and a data packet with a data packet header; stripping the monitoring metadata header from the encapsulated packet to obtain a de-encapsulated packet comprising the data packet with the data packet header; and directing, based on the data packet header, the de-encapsulated packet to a virtual network interface associated with a packet capture application within the analyzer virtual machine.

Abstract: Transferring files in accordance with a data communications protocol includes: receiving, by a server from a client, a read request for a file, where the read request specifies a filename of the file, a message digest algorithm, and a key, where the key includes a result of applying the message digest algorithm to the file as stored on the client; generating, by the server, a local key including applying the message digest algorithm to a file currently stored on the server and having the filename; and if the local key matches the key specified in the read request, closing, by the server, a connection to the client with success without sending the requested file.

Abstract: Devices and methods for determining and indicating a source of power based on a characteristic of received power are disclosed. According to an aspect, a device includes a power line interface configured to receive power from multiple power lines. The device also includes a comparator module configured to compare one or more characteristics of the received power from the plurality of power lines. The comparator module is also configured to determine whether the received power on the power lines are from the same source based on the comparison. Further, the device includes a user interface configured to indicate whether the received power on the power lines are from the same source based on the determination.

Abstract: An apparatus for optical link fault management includes a processor in a network device with an optical adapter of an optical link, and a memory that stores program code. The program code is executable by the processor to store state parameters from the optical adapter in a data log, input the state parameters from the data log into a failure prediction model, and generate, using the failure prediction model, a probability of failure of the optical adapter based on current state parameters from the data log. In response to the probability of failure reaching a failure threshold, the program code is executable by the processor to decrease data traffic in the optical link and to send an alert comprising the probability of failure. The failure threshold includes a probability of failure indicative of impending failure of the optical adapter.

Abstract: An apparatus for optical link fault management includes a processor in a network device with an optical adapter of an optical link, and a memory that stores program code. The program code is executable by the processor to store state parameters from the optical adapter in a data log, input the state parameters from the data log into a failure prediction model, and generate, using the failure prediction model, a probability of failure of the optical adapter based on current state parameters from the data log. In response to the probability of failure reaching a failure threshold, the program code is executable by the processor to decrease data traffic in the optical link and to send an alert comprising the probability of failure. The failure threshold includes a probability of failure indicative of impending failure of the optical adapter.

Abstract: Capturing data packets for analysis using a virtual machine including receiving, at an analyzer virtual machine, an encapsulated packet for analysis, wherein the encapsulated packet comprises a monitoring metadata header and a data packet with a data packet header; stripping the monitoring metadata header from the encapsulated packet to obtain a de-encapsulated packet comprising the data packet with the data packet header; and directing, based on the data packet header, the de-encapsulated packet to a virtual network interface associated with a packet capture application within the analyzer virtual machine.

Abstract: Hardware of a network switching device supports quantized congestion notification (QCN) to notify senders of network packets received at the network switching device that the network switching device is experiencing congestion. The hardware is instead programmed to notify a processor of the network switching device of the congestion at an egress queue of the network switching device. The processor receives a congestion notification message (CNM) from the hardware that the hardware has detected the congestion at the egress queue. Responsive to receiving the CNM from the hardware, the processor detects a microburst of the network packets at the egress queue of the network switching device.

Abstract: Hardware of a network switching device supports quantized congestion notification (QCN) to notify senders of network packets received at the network switching device that the network switching device is experiencing congestion. The hardware is instead programmed to notify a processor of the network switching device of the congestion at an egress queue of the network switching device. The processor receives a congestion notification message (CNM) from the hardware that the hardware has detected the congestion at the egress queue. Responsive to receiving the CNM from the hardware, the processor detects a microburst of the network packets at the egress queue of the network switching device.