Hewlett Packard Enterprise Development LP

Anil Raj

Anoop Govindan Nair

Venkatavaradhan Devarajan

Tathagata Nandy

Celestian K Sebastian

Srijith Ponnappan

Madhusoodhana Chari Sesha

Saumya Dikshit

Subramanian Muthukumar

Subin Cyriac Mathew

Haris Palapra

Tamil Esai Somu

Priyam De

Sasikumar Balasubramanian

Kedar Laxman Kurtkoti

Keshava Ayanur

Prasanth Gopinathan Nair Saraswathy Amma

Abhisht Joshi

Sinchana Kallesara Mruthyunjaya

Chakradhara Rao Gollakota

Renjith Vijayan

Jagdev Singh

Sarvotham Prasad R

A Keshava

A system for facilitating efficient multicast programming in a switch is provided. During operation, the system can parse a multicast data structure that can map an ingress interface, a source, and a multicast group to a set of egress interfaces. Based on the data structure, the system can generate a cache that can map an egress interface to an ingress interface indicated in the data structure. Upon receiving a join request via a first interface, the system can look up the first interface in the cache. If the first interface matches a cache entry, the system can identify an ingress interface from the cache entry. The system can then program, in the data structure, a route entry with the first interface as an egress interface and the ingress interface. Subsequently, if a multicast data packet matches the route entry, the system can forward the packet via the first interface.

Efficient programming of multicast routes in forwarding hardware

One aspect can provide a system and method for tunnel-based multicasting. During operation, a source-side designated router (DR) coupled to a source device of a multicast group can broadcast a service-advertisement packet and receive a response packet from a client-side DR coupled to one or more client devices within the multicast group. The source-side DR can determine an address of the client-side DR based on the received response packet and establish a hardware-based communication tunnel between the source-side DR and the client-side DR using the address of the client-side DR. Establishing the hardware-based communication tunnel can include using hardware logic units to encapsulate multicast data packets originating from the source device. The source-side DR can further send, over the hardware-based communication tunnel, multicast data packets originating from the source device to the client-side DR, which forwards the multicast data packets to the client devices within the multicast group.

Hardware offload of multicast control plane functions

A first switch in a network is provided. During operation, the first switch can receive traffic associated with a virtual network address allocated to the first switch and a second switch. The first and second switches can provide high availability to each other. If a layer-3 static multicast route is received at the first switch for a multicast group, the first switch can configure the static multicast route in the control plane. The first switch can determine that a set of conversion conditions are satisfied for the static multicast route. The set of conversion conditions can be applicable to a respective switch associated with the virtual network address. If the set of conversion conditions is satisfied, the first switch can generate a set of layer-2 entries for the multicast group from the static multicast route and program the forwarding hardware to include the set of layer-2 entries.

Programmable multicast routes on a virtual gateway switch

A system for facilitating efficient multicast traffic management for service discovery is provided. During operation, the system can identify a set of multicast entries associated with a multicast flow in a multicast forwarding data structure of a switch. A respective entry of the data structure can indicate how a corresponding multicast packet is forwarded. If a subset of the multicast entries shares one or more network parameters, the system can compress the subset of the multicast entries based on the shared network parameters to generate a generic entry. The generic entry can then replace the subset of the multicast entries in the data structure. Subsequently, the system can determine a multicast forwarding role of the switch and filter one or more types of multicast control messages based on the multicast forwarding role. Here, the multicast control messages can be directed to the multicast entry.

Efficient multicast control traffic management for service discovery

Examples disclosed herein relate to a system comprising a request transmitter to transmit a plurality of transaction requests from a first daemon to a central database, wherein the first daemon belongs to a plurality of daemons using the central database to communicate with each other to perform networking related functions. The system may include a baseline determiner to determine a baseline response time for receiving a response to the plurality of transaction requests, a transaction request transmitter to transmit a transaction request, belonging to the plurality of daemons, to the central database and a transaction requester determiner to determine that the central database is processing more requests that it can handle. The system may include a delay time generator to generate a delay time for a subsequent transaction request to the central database and a subsequent request transmitter to transmit the subsequent transaction request to central database.

Rate adaptive transactions

A system related to black hole filtering is provided. The system can allow a dynamic routing protocol on a network device to determine whether a route learned by the dynamic routing protocol is a black hole route. The route may be learned through another source. In response to a determination that the route is the black hole route, the dynamic routing protocol may generate a routing update that indicates the route as the black hole route. The dynamic routing protocol may then advertise the routing update to each neighbor network device.

Black hole filtering

Examples disclosed herein relate to a method comprising detecting, by a bi-directional forwarding detection (BFD) protocol, a link failure of a link associated with a network device on a network. The method may include notifying, by the BFD protocol, a routing protocol and a hardware plugin about the link failure and identifying, by the routing protocol, an updated route for the network that does not include the network device. The method may also include deleting, by the hardware plugin, any routes programmed into a forwarding information base (FIB) including the first network device upon receiving the notification from the BFD protocol and installing, by the hardware plugin, the updated route into the FIB to be used for forwarding network traffic on the network.

Route updating using a BFD protocol

Examples include determining a first hop for a preferred route from a networking device to a destination device, calculating a cumulative cost for the preferred route based on a cost of the first hop and an original cost of the preferred route, determining whether a secondary route is available, and, in response to a determination that the secondary route is available, determining a first hop in the secondary route. Examples also include determining a cost of the first hop in the secondary route, determining a new route from the networking device to the destination computing device based on the cumulative cost of the preferred route and the cost of the first hop in the secondary route, and entering the new route into a forwarding data structure of the networking device.

Route selection using cumulative cost

One embodiment can provide a method and system for synchronizing MTU in a WAN edge with router redundancy. During operation, the system may determine a set of interfaces associated with a network device among a plurality of network devices coupled via inter-switch links. The system can determine a set of layer-3 MTU values corresponding to the set of network interfaces and can determine a highest layer-3 MTU value based on the set of determined layer-3 MTU values. The system can synchronize, via the inter-switch links, the highest layer-3 MTU value, resulting in a set of highest layer-3 MTU values at the network device. The system can determine, based on the set of highest layer-3 MTU values, a global highest layer-3 MTU value. The system can derive a layer-2 MTU value based on the global highest layer-3 MTU value and can configure a respective inter-switch link with the layer-2 MTU value.

System and method for performing synchronization of maximum transmission unit with router redundancy

Implementations of the disclosure are directed to using a distributed ledger network to synchronize configuration changes across a network of servers that provide authentication, authorization, and accounting (AAA). In some implementations, a method includes: receiving, at a first server that provides AAA of users that access a network, a user request to update a configuration of a database of the first server, the database including authentication credentials for users that access the network, in response to receiving the user request, transmitting a transaction to the distributed ledger network for validation, the transaction comprising a request by the first server for each server of the distributed ledger network to update their respective database configuration in accordance with the user request; and after the transaction is validated by the distributed ledger network, the first server updating its database configuration in response to receiving the update comprising the validation of the transaction.

Synchronizing radius server databases using distributed ledger network

A method for use in exiting a portion of a node from an Internet Protocol, Layer 3 network includes: preparing the network for the portion to exit prior to the exit, including: notifying a set of peer nodes of the portion's exit; and rerouting traffic in the network away from the portion to the set of peer nodes; exiting the portion from the network once the traffic is rerouted; and reintroducing the exited portion to the network, including: notifying the peer nodes of the portion's reintroduction; and rerouting at least some of the traffic through the re-introduced portion.

Hitless maintenance of a L3 network

A method for use in a network, including: receiving network traffic at a redundant gateway device established according to a redundant gateway protocol; forwarding known unicast traffic received at the redundant gateway device from the redundant gateway device to a tunnel endpoint through a tunnel established according to a tunneling protocol; forwarding broadcast, unknown unicast, and multicast traffic to the tunnel endpoint through the tunnel if the redundant gateway device is a master gateway under the redundant gateway protocol; and dropping the broadcast, unknown unicast, and multicast traffic if the redundant gateway device is a backup gateway under the redundant gateway protocol.

Achieving L2 tunnel reduncancy and L3 load balancing

Examples disclosed herein relate to management of default route advertisement by an Area Border Router in an OSPF network. In an example, an ABR in an OSPF network may determine whether a pre-condition for the ABR to advertise a default route to a stub area is met. In response to a determination that the pre-condition for the ABR to advertise the default route to the stub area is met, the ABR may advertise the default route to an adjacent router in the stub area.

Managing default route advertisements by an area border router in an open shortest path first network

Examples disclosed herein relate to a method comprising receiving, at a first switch, a bidirectional forwarding detection packet, wherein the first switch and a second switch are part of a virtualized switch and each switch in the virtualized switch has a same Media Access Control (MAC) address, determining, at the first switch, that a destination MAC address included in the bidirectional forwarding detection packet is not owned by the first switch, determining, at the first switch, that the destination MAC address is owned by the second switch and bridging, from the first switch, the bidirectional forwarding detection packet to the second switch that owns the MAC address.

Supporting BFD packets in a virtualized switch environment

In some examples, a first router establishes a fault detection session between the first router connected to a routing area and an outside router assigned a forwarding address, the outside router located outside the routing area, and the forwarding address used by a second router of the routing area to send a data packet to the outside router. The first router detects, in the fault detection session, a fault associated with the outside router, and in response to detecting the fault associated with the outside router in the fault detection session, provides an indication to the routing area that the forwarding address is no longer accessible.

Growing community of inventors

Bengaluru, India

Anil Raj