Abstract: A network device may receive a message. The network device may determine that the message includes return information indicating a path to an initial device that generated the message. The network device may modify the message by adding an upstream device identifier, wherein the upstream device identifier identifies a device from which the message is received. The network device may modify the message by adding an indication of whether the initial device is reachable by the network device using a segment identifier. The network device may provide the modified message to a downstream device.

Abstract: A device may utilize a point-to-point protocol over Ethernet (PPPoE) and a point-to-point protocol (PPP) to register the device with a core network, and may establish a first packet data unit (PDU) session with the core network based on the PPPoE and the PPP. The device may configure the first PDU session, based on the PPPoE and the PPP, to provide a first service, and may generate first keep alive messages to maintain the first PDU session. The device may establish a second PDU session with the core network based on the PPPoE and the PPP, and may configure the second PDU session based on the PPPoE and the PPP, where the second PDU session is configured to provide a second service that is different than the first service. The device may generate second keep alive messages to maintain the second PDU session.

Abstract: A label switch router (LSR) in a label-switched path (LSP) may receive, from an ingress edge LSR, a Multi-Protocol Label Switching (MPLS) echo request, where the LSP includes a tunnel having details that are hidden by a Nil Forward Equivalency Class (FEC). The LSR may determine whether the LSR is an egress node for the tunnel in the LSP based at least in part on one or more labels in the MPLS echo request. The LSR may, in response to determining that the LSR is the egress node for the tunnel in the LSP, send an MPLS echo reply that indicates the LSR as being the egress node for the tunnel in the LSP.

Abstract: In radio-frequency (RF) devices integrated on semiconductor-on-insulator (e.g., silicon-based) substrates, RF losses may be reduced by increasing the resistivity of the semiconductor device layer in the vicinity of (e.g., underneath and/or in whole or in part surrounding) the metallization structures of the RF device, such as, e.g., transmission lines, contacts, or bonding pads. Increased resistivity can be achieved, e.g., by ion-implantation, or by patterning the device layer to create disconnected semiconductor islands.

Abstract: This disclosure describes techniques for analyzing information generated as a result of monitoring resources within computing environments. In one example, this disclosure describes a method that includes observing a plurality of alerts generated in response to monitoring resources associated with a plurality of connected elements within a network; determining a plurality of occurrence counts; determining a plurality of concurrent occurrence counts, wherein each of the plurality of concurrent occurrence counts represents a count of concurrent occurrences of two or more of the alerts in the set of historical alerts; and identifying one or more root cause alerts, wherein the one or more root cause alerts are determined based on the plurality of occurrence counts and the plurality of the concurrent occurrence counts, and wherein the one or more root cause alerts are a subset of the plurality of alerts.

Abstract: An orchestrator component, of a host device, may establish a connection to a bridge associated with the host device, where multiple virtual machines are executing on the host device. The orchestrator component may provide, to one or more of the multiple virtual machines, a notification about the bridge associated with the host device, where the notification is to permit the one or more of the multiple virtual machines to connect to the bridge. The orchestrator component may obtain one or more dynamic parameters relating to the host device, and may provide the one or more dynamic parameters for transmission to the one or more of the multiple virtual machines via the bridge to permit the one or more of the multiple virtual machines to receive and process the one or more dynamic parameters.

Abstract: A network device may receive, from a first network, a network packet of a first network packet type that encapsulates a fragment of a second network packet of a second network packet type, where the network packet is part of a flow of a plurality of network packets of the first network packet type that encapsulates fragments of the second network packet, and where the network packet includes a flow label that indicates a source port for the second network packet. The network device may perform an anti-spoof check on the fragment of the second network packet based at least in part on the source port for the second network packet that is indicated by the flow label of the network packet. The network device may, based on the fragment passing the anti-spoof check, forward the fragment of the second network packet to a second network.

Abstract: A network device may receive convergence prioritization data identifying one or more handling configurations for border gateway protocol update messages. The network device may assign a plurality of table priority values to a respective plurality of border gateway protocol tables associated with a respective plurality of entities based on parameters included in the convergence prioritization data. The network device may assign a plurality of queue priority values to a respective plurality of queues of the plurality of border gateway protocol tables based on the convergence prioritization data. The network device may create one or more border gateway protocol update messages based on the plurality of queue priority values and based on traversing the plurality of border gateway protocol tables using the plurality of table priority values. The network device may provide the one or more border gateway protocol update messages to one or more other network devices.

Abstract: A controller device manages a plurality of network devices. The controller device includes one or more processing units implemented in circuitry and configured to maintain a graph data structure representing device level configuration schemas for the plurality of network devices, the graph data structure including trie nodes for every first device level configuration schema element for a first model of a version of network device of the plurality of network devices; obtain corresponding second device level configuration schema elements based on a path for a second model of the version of the network device; determine a deviation between the second device level configuration schema element and the first device level configuration schema; and update the trie node to add a branch to a node representing the second device level configuration schema element.

Abstract: A network device includes one or more processors configured to use a fat flow rule that specifies at least one of a mask to be applied to source Internet protocol (IP) addresses or to destination IP addresses, or that source ports or destination ports are to be ignored. The one or more processors may further be configured to receive packets having different source or destination IP addresses and/or different source or destination ports, and nevertheless assign the packets to the same fat flow according to the fat flow rule, e.g., by masking the source or destination IP addresses and/or ignoring the source or destination ports of the packets. In this manner, the network device may aggregate two or more different flows into a single fat flow.

Abstract: A device may identify a plurality of files for a multi-file malware analysis. The device may execute the plurality of files in a malware testing environment. The device may monitor the malware testing environment for behavior indicative of malware. The device may detect the behavior indicative of malware. The device may perform a first multi-file malware analysis or a second multi-file malware analysis based on detecting the behavior indicative of malware. The first multi-file malware analysis may include a partitioning technique that partitions the plurality of files into two or more segments of files to identify a file, included in the plurality of files, that includes malware. The second multi-file malware analysis may include a scoring technique that modifies a plurality of malware scores, corresponding to the plurality of files, to identify the file, included in the plurality of files, that includes malware.

Abstract: In general, this disclosure describes a network device that checks consistency between routing objects in a routing information base (RIB), a forwarding information base (FIB), and packet forwarding engine (PFE) forwarding tables. A method includes generating a marker that causes a routing protocol daemon, a control plane kernel, and PFEs of a network device to calculate zonal checksums for a plurality of zones using consistency values for each routing object within a RIB, a FIB, and corresponding forwarding tables respectively. The method includes performing a consistency check on the RIB, the FIB, and the forwarding tables to determine whether the routing objects in each of the RIB, the FIB, and the forwarding tables are consistent with each other. The method includes, when the RIB, the FIB, and the forwarding tables are not consistent, performing an action related to at least one of RIB, the FIB, or the forwarding tables.

Abstract: In general, various aspects of the techniques described in this disclosure provide time synchronization for encrypted traffic in a computer network. In one example, the disclosure describes an apparatus, such as a network device, having a control unit for a network device in a computerized network having a topology of network devices; and a forwarding unit operative to determine a release time for sending a synchronization packet in accordance with a time synchronization protocol; modify the synchronization packet to include a release timestamp specifying the release time; sending a time value via sideband data associated with the synchronization packet, wherein the time value is based on the release time specified by the release timestamp; and schedule transmission of the synchronization packet for a time corresponding to the time value in the sideband data, the synchronization packet to be transmitted to a destination network device.

Abstract: This disclosure describes techniques relating to assigning unique segment identifiers (SIDs) in a segment routing network. In one example, this disclosure describes a method that includes receiving, by a computing system and from a node on a network, a request to allocate a segment identifier for use in a segment routing network; allocating, by the computing system and from a block of addresses, an assigned segment identifier; responding to the request by outputting, by the computing system and over the network to the node, information about the assigned segment identifier; and maintaining the assigned segment identifier.

Abstract: In general, techniques are described for creating a flexible services-based pipeline for firewall filter processing. A network device may be configured to perform the techniques. In one example, a method includes receiving, by a network device, data defining a plurality of firewall filter processing services, the data defining an order in which to apply services of the plurality of firewall filter processing services to firewall filters; configuring, by the network device and based on the received data, an execution engine pipeline to include the plurality of firewall filter processing services in the defined order; prior to programming a received firewall filter to hardware of the network device for filtering network traffic, processing the firewall filter by the execution engine pipeline to produce a processed firewall filter; and programming, by the network device, the processed firewall filter to the hardware for filtering the network traffic.

Abstract: A device may obtain information concerning a potential network and may process the information concerning the potential network to determine a plurality of configuration parameters associated with the potential network. The device may determine, based on the plurality of configuration parameters, at least one network configuration profile. The device may generate, based on the at least one network configuration profile, a network configuration test plan and may cause one or more network devices to be tested according to the network configuration test plan.

Abstract: A sourceless co-packaged optical-electrical chip can include a plurality of different optical transceivers, each of which can transmit to an external destination or internal components. Each of the transceivers can be configured for a different modulation format, such as different pulse amplitude, phase shift key, and quadrature amplitude modulation formats. Different light sources provide light for processing by the transceivers, where the light source and transceivers can be configured for different applications (e.g., different distances) and data rates. An optical coupler can combine the light for the different transceivers for input into the sourceless co-packaged optical-electrical chip via a polarization maintaining media (e.g., polarization maintaining few mode fiber and polarization maintaining single mode fiber), where another coupler operates in splitting mode to separate the different channels of light for the different transceivers according to different co-packaged configurations.

Abstract: A disclosed method may include (1) receiving, at an IPFIX collector, a IPFIX message from an IPFIX exporter implemented on a remote device, (2) identifying, within the IPFIX message, a data set exported by the IPFIX exporter implemented on the remote device, (3) identifying, within the IPFIX message, a data-level indicator that indicates whether the data set is (A) a primary data set observed by an observation domain implemented on the remote device or (B) a secondary data set derived by an observation cloud implemented on the remote device, (4) identifying, at the IPFIX collector, a database that corresponds to the data-level indicator identified within the IPFIX message, (5) storing the data set in the database in accordance with the data-level indicator, and then (6) performing an action based at least in part on the data set stored in the database. Various other systems and methods are also disclosed.

Abstract: The disclosed apparatus may include (1) an FRU that (A) is designed to mate with a backplane of a telecommunications system and (B) facilitates communication among computing devices within a network and (2) at least one multi-bar ejector that (A) is coupled to the FRU, (B) fastens to a housing of the telecommunications system to enable the FRU to mate with the backplane of the telecommunications system, and (C) includes a spring coupled to at least one bar of the multi-bar ejector that, when the multi-bar ejector is fastened to the housing of the telecommunications system, applies a force on the FRU that pushes the FRU toward the backplane of the telecommunications system. Various other apparatuses, systems, and methods are also disclosed.

Abstract: Techniques are described for providing a controller to configure, within a given namespace, a virtual network for a pod and an application service address for an application service to enable access to the pod. For example, the controller may configure in each namespace a virtual network for a logically-related group of one or more containers (“pod”) and application service address for an application service that is an abstraction which defines a logical set of pods and a policy by which to access the pods (e.g., load balancing). Techniques are also described for providing a controller to configure controller configures the service chain by configuring the left interface of a service node with a virtual routing and forwarding instance (VRF) identifying the pod of a first namespace and the right interface of the service node with a VRF identifying the application service of a second namespace.