Hewlett Packard Enterprise Development LP

Balaji Sankaran

Venkatavaradhan Devarajan

Tathagata Nandy

Krishna Mohan Elluru

Chivukula Koundinya

Vinay Kumar Vishwakarma

Sivakumar Murugan

Badrish Havaralu Rama Chandra Adiga

Vinayak Joshi

Chethan Chavadibagilu Radhakrishnabhat

Francisco José Rojas Fonseca

Vijay Kannan

Karthikeyan Ramachandran

Guru Gurram Janardhan

Suresh Rukmangathan

Gudiputi Suma Chowdary

Shantha Kumara

Bhupesh Bhargava

A network management system (NMS) for provisioning and managing an overlay network is provided. During operation, the NMS can determine that a loop associated with a media access control (MAC) address is detected in the network. The NMS can probe a first switch in the loop by instructing the first switch to observe the MAC address for a predetermined period. The NMS can receive a first message indicating a first set of ports of the first switch observing the MAC address. The NMS can probe an upstream switch reachable via each of the first set of ports by instructing the upstream switch to observe the MAC address for the predetermined period. Here, observing the MAC address at an upstream port of the upstream switch causes further upstream probing. Based on probing the switches in the loop, the NMS can determine one or more loop origination points (LOPs) for the loop.

Identifying loop-origination points in an overlay network

A network management service controls the flow of messages (e.g., management messages) with a credit-based system. The network management service may be a cloud-based network management service. A message credit quantity for a managed network device is calculated by the network management service based on multiple criteria. The message credit quantity is communicated to the managed network device. The managed network device limits its sending of management messages to the network management service based on its assigned quantity of message credits.

Credit-based network management service messaging

One aspect of the present technology can provide a system for facilitating in-service software upgrade (ISSU) for a switch in a virtual switching stack. During operation, the system can initiate ISSU that facilitate uninterrupted traffic flow. The system can upgrade a first set of daemons of the switch that manage operations of the switch. The system can also upgrade a database stored on the switch. The database can store operational information of the switch. The system can further upgrade a second set of daemons of the switch that configure forwarding information on the forwarding hardware of the switch and facilitate data-plane operations for the switch. The forwarding information configured on the forwarding hardware can remain unchanged during the upgrade. The system can configure the upgraded second set of daemons to obtain control-plane information from a standby switch of a conductor switch of the virtual switching stack.

In-service software upgrade in a virtual switching stack

A member switch of multiple connected switches receives a stack-discovery packet from a first coupled switch and, in response, generates and transmits a stack-discovery-response packet to the first coupled switch to allow the member switch to be discovered. The member switch receives stack-configuration information from a stack-control node and forwards the stack-discovery packet to a second coupled switch to facilitate discovery of the second coupled switch. The first coupled switch, the member switch, and the second coupled switch are coupled to each other according to a predetermined order, thereby facilitating an ordered discovery of the multiple connected switches. In response to receiving, from the stack-control node, a control packet, the member switch reboots based on the received stack-configuration information. The stack-configuration information comprises a stack-member identifier allocated, based on the predetermined order, by the stack-control mode to the member switch, thereby facilitating formation of an ordered stack.

Ordered stack formation with reduced manual intervention

Example approaches for authenticating a device are described. In an example, a category, from a plurality of categories, is identified for a device, based on data packets exchanged between the device and a network element. The category is indicative of operational capabilities of the device. Based on the category identified for the device, an authentication order for the device is determined. The authentication order is indicative of a sequence in which a set of authentication tests is to be executed for authentication of the device.

Device category based authentication

Examples herein are directed to centralized database based multicast converging. For instance, in various examples centralized database based multicast converging can include starting a restart timer having a value greater than a time to validate stored entries in a centralized database, sending data packets at least to hosts on the network corresponding to the stored entries in the centralized database to maintain service to the hosts while the restart timer is running, sending query packets to validate a host corresponding to an entry of the stored entries in the centralized database, and responsive to the restart timer expiring, sending data packets to a converged group of hosts including at least the validated host.

Centralized database based multicast converging

Examples disclosed herein relate to use of MACsec to encrypt tunnel data packets. In an example, a MACsec capable device may receive a data packet from a host device for tunneling to a controller. MACsec capable device may encapsulate the data packet with an encapsulation header to generate an encapsulated data packet. The encapsulation header may comprise a destination MAC address reserved for the controller. MACsec capable device may direct the encapsulated data packet to a MACsec engine. MACsec engine may encrypt the encapsulated data packet with the encryption key to generate an encrypted data packet. MACsec capable device may encapsulate the encrypted data packet with a first GRE header. MACsec capable device may send the encrypted data packet with the first GRE header to the controller via a GRE tunnel.

MACsec for encrypting tunnel data packets

Some examples relate to auto-configuration of a parameter related to a multicast protocol on a network device. In an example, a network device in a multicast network may identify the network topology of the multicast network. Upon identification, the network device may enable a multicast protocol on the network device based on the network topology of the multicast network. The network device may determine a network parameter related to the multicast network. In response to the determination, a multicast parameter related to the multicast protocol may be auto-configured on the network device.

Auto-configuring multicast protocol parameters

A system and device for determining authenticity of a client device transmitting a request to access a network that includes an authenticator to adjust authentication parameters for authentication requests to access a network from a client device, and access switches positioned within the authentication, each of the plurality of switches having an associated port for receiving the authentication requests. The authenticator monitors authentication requests received from the client device, determines whether a number of the monitored authentication requests that are failed authentication requests, and determines mobility of the client device during the monitored authentication requests. Authenticity of the client device is determined based on one of the determined number of failed authentication requests and the determined mobility of the client device.

Growing community of inventors

Bengaluru, India

Balaji Sankaran