Abstract: A device may receive information identifying a set of tasks to be executed by a microservices application that includes a plurality of microservices. The device may determine an execution time of the set of tasks based on a set of parameters and a model. The set of parameters may include a first parameter that identifies a first number of instances of a first microservice of the plurality of microservices, and a second parameter that identifies a second number of instances of a second microservice of the plurality of microservices. The device may compare the execution time and a threshold. The threshold may be associated with a service level agreement. The device may selectively adjust the first number of instances or the second number of instances based on comparing the execution time and the threshold.

Abstract: A device may identify a plurality of first values associated with network traffic of a label-switched path of a plurality of label-switched paths. The device may determine an adjustment policy based on the plurality of first values. The adjustment policy may include one or more factors associated with a plurality of second values. The plurality of second values may be determined based on the plurality of first values. The device may implement the adjustment policy in association with the label-switched path. A bandwidth reservation of the label-switched path may be adjusted based on the adjustment policy. The adjustment policy may be implemented for fewer than all of the plurality of label-switched paths.

Abstract: A node may receive a network topology message that identifies a first association of a first segment identifier (SID), relating to a loosely routed segment of a network, and an address of a first terminal interface associated with the loosely routed segment, or a second association of a second SID, relating to a strictly routed segment of the network, and an address of a second terminal interface associated with the strictly routed segment. The node may generate an entry in a segment translation table based on the first association or the second association. The node may route, according to the segment translation table, an internet protocol (IP) payload packet that has been encapsulated using an IPv6 transport header that has been extended with a compressed routing header of variable length.

Abstract: A network device ensures availability of content destination devices, and may receive a request to install a filter, and the request may include information identifying a set of content destination devices capable of receiving packets that match the filter, and priority values indicating priorities by which the set of content destination devices are to receive the packets. The network device may receive status indications indicating availabilities associated with the set of content destination devices, and may receive a packet destined for an endpoint device. The network device may generate a copy of the packet, and may determine that a packet feature matches the filter. The network device may select a particular content destination device, from the set of content destination devices, based on the priority values and the status indications, and may cause the copy of the packet to be forwarded to the particular content destination device.

Abstract: A network device may receive, from a transmitting network device, a packet, wherein the packet includes a first outer internet protocol (IP) header, a Generic Routing Encapsulation (GRE) header, a second outer IP header, an Encapsulating Security Payload (ESP) header, and an inner packet, wherein the inner packet is encapsulated by the ESP header, the ESP header is encapsulated by the second outer IP header, the second outer IP header is encapsulated by the GRE header, and the GRE header is encapsulated by the first outer IP header. The network device may decapsulate the packet to remove the first outer IP header and the GRE header from the packet. The network device may decrypt, after decapsulating the packet, the packet to identify the inner packet. The network device may cause one or more actions associated with the inner packet to be performed.

Abstract: This disclosure describes techniques that include selecting a member port of an aggregation bundle by evaluating utilization of paths, within a router, to member ports of an aggregation bundle. In one example, this disclosure describes a method that includes receiving network data to be output through an aggregation bundle having a plurality of member ports; identifying local member ports; identifying non-local member ports, each of the non-local member ports being reachable from the receiving line card over a path through the switch fabric to a different one of the plurality of line cards; identifying available non-local member ports by determining, for each non-local member port, whether the path through the switch fabric has low utilization; and selecting a member port by applying a hashing algorithm to a group that includes each of the identified available non-local member ports.

Abstract: Disclosed embodiments utilize a layer three and/or layer four protocol to collect physical layer properties along a multi-hop network path between a source node and a destination node. The use of a layer three or layer four protocol provides an ability to span multiple links or networks between the source node and destination node, while also collecting the physical layer properties. Once physical layer properties along a network path can be understood, decisions relating to the configuration of the network path and/or whether to communicate via the network path are improved.

Abstract: An auto-discovery route reflector (auto-discovery-RR) may obtain a route from an originating network device and may update a data structure to include at least some information contained in the route. The auto-discovery-RR may identify, based on the data structure, a plurality of target network devices, wherein the plurality of target network devices includes at least one route reflector (RR) and at least one route reflector client (RR-client). The auto-discovery-RR may send the route to the plurality of target network devices to facilitate establishment of a connection between the originating network device and at least one target network device of the plurality of target network devices.

Abstract: A device may receive a first telemetry data entry associated with an attribute and store a record associated with the first telemetry data entry, wherein the record identifies a first context value associated with the attribute. The device may log a first timestamp of the first telemetry data entry in a lookup table, wherein the lookup table includes a mapping of the attribute to the first context value and to the first timestamp. The device may receive a second telemetry data entry associated with the attribute and may determine, from the mapping, that the second telemetry data entry is associated with a second context value that is different from the first context value. The device may determine whether a second timestamp, of the second telemetry data entry, is before the first timestamp. The device may perform an action based on whether the second timestamp is before the first timestamp.

Abstract: A network device may receive, from a collector device, a request for telemetry data associated with service interfaces and counters of the network device. The network device may determine, based on the request, a first quantity of the service interfaces and a second quantity of the counters. The network device may determine a first time interval to send delta values of the telemetry data associated with the service interfaces and the counters, and a second time interval to send absolute values of the telemetry data, based on the first time interval, the first quantity of the service interfaces, and the second quantity of the counters. The network device may provide, to the collector device, the absolute values of the telemetry data based on the second time interval and may provide, to the collector device, the delta values of the telemetry data based on the first time interval.

Abstract: A device may generate a display of a firewall policy management GUI. The device may generate a display in the firewall policy management GUI of a list of existing firewall policies and a firewall policy interface that is adjacent to the list of existing firewall policies in a same view of the firewall policy management GUI. The device may generate a display in the firewall policy management GUI of at least one of a plurality of candidate sources for a new firewall policy, a plurality of candidate destinations for the new firewall policy, or a plurality of candidate security configurations for the new firewall policy. The device may display, in the firewall policy interface, at least one of a first column that includes two or more sources, a second column that includes two or more destinations, or a third column that includes two or more security configurations.

Abstract: An example network device includes memory, a communication unit, and processing circuitry coupled to the memory and the communication unit. The processing circuitry is configured to receive first samples of flows from an interface of another network device sampled at a first sampling rate and determine a first parameter based on the first samples. The processing circuitry is configured to receive second samples of flows from the interface sampled at a second sampling rate, wherein the second sampling rate is different than the first sampling rate and determine a second parameter based on the second samples. The processing circuitry is configured to determine a third sampling rate based on the first parameter and the second parameter, control the communication unit to transmit a signal indicative of the third sampling rate to the another network device; and receive third samples of flows from the interface sampled at the third sampling rate.

Abstract: Management of network devices using network aware diagnosis techniques. An example method to monitor a network includes constructing, by a controller device that manages a plurality of network devices, a deployed graph model comprising a plurality of models representative of services operating on the network devices within the network. The method also includes receiving an alert, by the controller device, that a service operating on one of the network devices is experiencing a failure. Additionally, the method includes traversing, by the controller device, modeled dependencies within the deployed graph model to perform root cause analysis of the service that is experiencing the failure to determine a resource-level event causing the failure. The method includes. based on the traversing, providing, by the controller device, a report indicating the root cause of the failure.

Abstract: In some embodiments, an apparatus includes a switch fabric having at least a first switch stage and a second switch stage, an edge device operatively coupled to the switch fabric and a management module. The edge device is configured to send a first portion of a data stream to the switch fabric such that the first portion of the data stream is received at a queue of the second switch stage of the switch fabric via the first switch stage of the switch fabric. The management module is configured to send a flow control signal configured to trigger the edge device to suspend transmission of a second portion of the data stream when a congestion level of the queue of the second switch stage of the switch fabric satisfies a condition in response to the first portion of the data stream being received at the queue.

Abstract: Techniques are described for inter-domain segment routing using transport endpoint segments. A transport endpoint segment provisioned on a router within a domain represents any intra-domain tunnel originated at the router and having reachability to an indicated endpoint within the same domain. The provisioning router advertises a transport endpoint segment identifier (TESID) for the transport endpoint segment to other routers or a controller for use in segment routing. The TESID for the transport endpoint segment remains constant regardless of which intra-domain tunnel is bound to the transport endpoint segment. The provisioning router dynamically binds the transport endpoint segment to at least one intra-domain tunnel, and any changes to the bound intra-domain tunnel are updated locally at the provisioning router. In this way, an inter-domain segment routing tunnel may be constructed as a list TESIDs that are not affected by intra-domain tunnel changes.

Abstract: A disclosed method may include (1) querying, in connection with a monitoring service, a network device for device-specific data that identifies features of the network device, (2) determining, based at least in part on the device-specific data, identities of a set of ports on the network device, (3) identifying, based at least in part on the device-specific data one or more port-specific data objects corresponding to the set of ports, (4) dynamically creating, based at least in part on the device-specific data, a device-visualization interface of the network device by (A) generating a graphical chassis widget that illustrates a logical view of the set of ports and (B) generating a graphical table that illustrates the port-specific data objects, and then (5) providing, in connection with the monitoring service, the device-visualization interface for presentation on a computing device. Various other systems and methods are also disclosed.

Abstract: An example virtual router includes a plurality of logical cores (“lcores”), where each lcore comprises a CPU core or hardware thread. The virtual router is configured to determine a latency profile, select, based at least in part on the latency profile, a packet processing mode from the plurality of packet processing modes. In response to a determination that the packet processing mode comprises the run-to-completion mode, an lcore of the plurality of lcores is configured to: read a network packet from a device queue, process the network packet to determine a destination virtual device for the network packet, the destination virtual device having a plurality of interface queues, and insert the network packet into an interface queue of the plurality of interface queues.

Abstract: A disclosed method may include (1) receiving a packet at a tunnel driver in kernel space on a routing engine of a network device, (2) identifying, at the tunnel driver, metadata of the packet that indicates whether at least one firewall filter had already been correctly applied to the packet before the packet arrived at the tunnel driver, (3) determining, based at least in part on the metadata of the packet, that the firewall filter had not been correctly applied to the packet before the packet arrived at the tunnel driver, and then in response to determining that the firewall filter had not been correctly applied to the packet, (4) invoking at least one firewall filter hook that applies at least one firewall rule on the packet before the packet is allowed to exit kernel space on the routing engine. Various other apparatuses, systems, and methods are also disclosed.

Abstract: Disclosed are methods for detecting misconfigured VLANs. In some embodiments, traffic on a VLAN across multiple access points is categorized. Traffic on the VLAN at a single access point is then also categorized. The categorization of the VLAN traffic at the single access point can be in response to, for example, communication errors or other conditions. The two categorizations are then compared to determine if the VLAN traffic at the AP is consistent with the VLAN traffic across a network (e.g., an enterprise network). If the VLAN traffic at the AP is generally consistent with that across the network, this may indicate that a downstream network component, such as a switch or router, is misconfigured. Thus, some embodiments programmatically reconfigure the downstream component to forward traffic for the VLAN.

Abstract: An access point, which is a Power over Ethernet (PoE) Powered Device (PD) measures input voltage and input current. The access point determines a power requirement of the access point based on the measured current, measured voltage, and information about power requirements of access point components or devices coupled to the access point a power requirement of the access point. The access point communicates the determined power request to a power sourcing equipment (PSE), e.g., a network switch. In some embodiments, the access point further communicates one of: measured input current and measured input voltage to the PSE. The PSE uses the information received from the access point, e.g., power request and power measurements to determine an amount of power to be granted to the access point. If the access point does not receive the requested power level the access point selects internal components and/or external devices to de-power.