Cisco Technology, Inc.

Anand Kumar Singh

Swaminathan Narayanan

Venkatesh Srinivasan

Natarajan Manthiramoorthy

Ambrish Niranjan Mehta

Anulekha Chodey

Roshan Lal

Rishi Chhibber

Padmanab Pathikonda

Mankamana Prasad Mishra

Peter Psenak

Francesco Meo

Nataraj Batchu

Ann Roshini Paul

Techniques are described for an adaptive CoPP that can adapt and change based on actual network control traffic rather than static CoPP rates. An aggressive CoPP can protect the CPU (route processor) of a network device, e.g., routers and switches, but may also penalize convergence and performance. An adaptive CoPP may protect CPU as well as boost convergence and performance parameters. In particular, traffic between two sites may be managed by proactively changing the thresholds of lower CoS traffic based on the CoPP utilization of various protocol/BPDU class traffic, thereby improving data plane convergence and application performance in scaled environments.

Adaptive control plane policing

Aspects of the present disclosure are directed to dynamically adjusting control plane policing throughput of low (or lower) priority control plane traffic to permit higher throughput. The drop rate for low or lower priority control plane traffic can be determined to be above a threshold value. The processor utilization can be determined to be operating under normal utilization (or at a utilization within a threshold utilization value). The control plane policing for control plane traffic for the low or lower class of service can be increased (or decreased) to permit lower class of service control traffic to be transmitted using higher class of service resources without adjusting the priority levels for the lower class of service control traffic.

Adapting control plane policing parameters dynamically

Multicast error detection and recovery may be provided. A join request for a multicast stream may be sent from a first network node to a second network node. The join request may be sent over a first link of a plurality of links between the first network node and the second network node. A redirect message indicating that the second network node cannot accommodate the join request may be received by the first network node from the second network node. In response to receiving the redirect message, the join request for the multicast stream may not be sent on a second link of the plurality of links by the first network node to the second network node. And in response to receiving the redirect message, an alternate upstream network node may be determined by the first network node to send the join request for the multicast stream to.

Multicast error detection and recovery

In one illustrative example, an IP network media data router includes a spine and leaf switch architecture operative to provide IP multicast delivery of media data from source devices to receiver devices without the overhead communication with a controller. The architecture can include K spine switches, K sets of L leaf switches, M data links between each leaf switch, and a plurality of bidirectional data ports connected to each leaf switch for a guaranteed non-blocking IP multicast delivery of data. A deterministic hash function a used on both the first hop router and the last hop router to ensure the same spine node is selected for flow stitching. Accordingly, without the extra communication with a centralized controller, the right spine for establishing a multicast flow can be chosen using the deterministic hash function and the distributed resource information stored on each node.

Methods and apparatuses for non-blocking IP multicast delivery of media data in a multi-spine network

Systems, methods, and non-transitory computer-readable storage media for detecting network loops. In some embodiments, a system can identify a network path having multiple hops associated with respective nodes which are configured in a forwarding mode. The system can traverse the network path to identify, for each node from the respective nodes, a respective next hop. Based on the respective next hop for each node, the system can determine whether two or more nodes from the respective nodes have a same respective next hop. When the two or more nodes have the same respective next hop, the system can determine that the network path has a network loop.

Detecting and preventing network loops

Systems, methods, and non-transitory computer-readable storage media for detecting network loops. In some embodiments, a system can identify a port that is in a blocking state. The blocking state can be for dropping one or more types of packets and preventing the port from forwarding the one or more types of packets. The system can determine a number of packets transmitted through the port by a hardware layer on the system and a number of control packets transmitted through the port by a software layer on the system. The system can determine whether the number of packets is greater than the number of control packets. When the number of packets is greater than the number of control packets, the system can determine that the blocking state has failed to prevent the port from forwarding the one or more types of packets.

Systems, methods, and computer-readable storage media for detecting network loops. A system can identify, for each virtual tunnel endpoint (VTEP) from multiple VTEPs in a network, respective media access control address data including the respective local interface media access control addresses of the respective VTEP and respective media access control addresses learned by the respective VTEP. The system can determine whether the VTEPs are running spanning tree protocol (STP), and whether a media access control address learned by a first VTEP matches a respective local interface media access control address of a second VTEP. The system can detect a loop when the media access control address learned by the first VTEP matches the respective local interface media access control address of the second VTEP. The system can also detect a loop when the VTEPs are running STP and the first and second VTEPs see the same STP root bridge.

Systems, methods, and computer-readable media for preventing man-in-the-middle attacks within network, without the need to maintain trusted/un-trusted port listings on each network device. The solutions disclosed herein leverage a host database which can be present on controllers, thereby providing a centralized database instead of a per-node DHCP binding database. Systems configured according to this disclosure (1) use a flood list only for ARP packets received from the controller; and (2) unicast ARP packets to the controller before communicating the packets to other VTEPs.

Technologies for preventing man-in-the-middle attacks in software defined networks

Mechanisms for switch upgrades using remote containers. An example system can export, to a server, a state of software processes associated with a first software container at the system. The system can generate a lightweight software container configured to forward traffic associated with the first software container to a second software container at the server, generated based on the state. The system can perform a switchover between the first software container and lightweight software container. The switchover can enable the lightweight software container to forward, to the second container, traffic associated with the first software container. The system can generate a fourth software container based on a snapshot of the second software container, and perform another switchover between the lightweight software container and fourth software container. The switchover can include enabling the fourth software container to handle traffic associated with the first software container, and disabling the lightweight software container.

Growing community of inventors

San Jose, CA, United States of America

Anand Kumar Singh