Hewlett Packard Enterprise Development LP

Tathagata Nandy

Chethan Chavadibagilu Radhakrishnabhat

Venkatavaradhan Devarajan

Subramanian Muthukumar

Anil Raj

Vinayak Joshi

Guru Gurram Janardhan

Priyam De

Balaji Sankaran

Rajib Majila

Vijay Kannan

Chethan Chavadibagilu Radhakrishna Bhat

Nilay Tripathi

Madhusoodhana Chari Sesha

Saumya Dikshit

David Corrales Lopez

Nitin Singla

Yashavantha Nagaraju Naguvanahalli

Praveen Kumar Arora

Abhishek Srivastava

Tamil Esai Somu

Mithun Kumar Halder

Utkarsh Srivastava

Saheli Ganguly

Gopalakrishna Tellapalli

Sarita Patra

Prasad Moola Mangalam

Chakradhara Rao Gollakota

Viswanath Reddy Bayapureddy

Thomas Samuel

Subramanian Muthumukar

A multicast tracing system for a network is provided. During operation, the system can identify, at a network device in the network, a join request and a data packet of a multicast group received at the network device. The system can determine respective timestamps indicating the arrival and departure of the join request and the data packet. The system can then determine, based on the timestamps, at least a local latency incurred by the data packet at the network device and a network latency incurred by the data packet in the network. Subsequently, the system can receive a multicast trace (mtrace) request for the multicast group. The system can incorporate the local latency and the network latency into the mtrace request. Upon identifying an upstream network device in a multicast path associated with the multicast group, the system can forward the mtrace request to the upstream network device.

Enhanced multicast tracing with latency detection

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 programmed network device and corresponding method are provided for rebuilding a multicast state upon experiencing a failure in a network using a protocol independent multicast (PIM) protocol. The method includes receiving updates to an outgoing list (Olist) for a given multicast route (mroute) at the network component and updating a PIM cache Olist in the network component with the received updates. During a state of recovering from the failure, the method includes determining whether the PIM cache Olist matches a centralized database Olist located in a centralized database. When a match is found, the method includes publishing an mroute state from the PIM cache to the centralized database.

Nonstop forwarding for routed multicast traffic

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 providing fast multicast convergence for Precision Time Protocol (PTP) at a switch is provided. During operation, the system can receive a multicast control message based on a multicast protocol used for PTP from a respective neighbor switch. The multicast control message can indicate neighbor information associated with the multicast protocol. The system can then determine a role associated with the PTP for a remote switch from the control message. Upon receiving a register message for a multicast group associated with the PTP, the system can determine whether a multicast path from the switch to a PTP source includes a device with a role of a boundary clock (BC) of PTP. If the multicast path includes a device with a role of a BC, the system can send a gratuitous register-stop message for the multicast group toward the PTP source in absence of a native path.

Fast multicast convergence for time synchronization in a network

A first network device in a network is provided. During operation, the first network device can elect the first network device as a designated forwarder (DF) of multicast traffic in a subnet for a Rendezvous Point (RP) of a multicast group. Here, the first network device can operate in conjunction with a second network device as a virtual gateway device of the subnet. The second network device can be elected as another DF for the RP. The first network device can determine whether the first network device is elected as a forwarding device based on a selection parameter. Upon determining that the first network device is elected as the forwarding device, the first network device can program, in the forwarding hardware, a forwarding entry for forwarding the multicast traffic. The first network device can then forward multicast traffic associated with the multicast group based on the forwarding entry.

Efficiently forwarding bidirectional multicast traffic at a virtual gateway device

In an example, a network device may receive, from a client device, a multicast query for a service advertised by a host device connected to another network device. The network device is configured as a first Virtual tunnel endpoint (VTEP) and the other network device is configured as a second VTEP in an overlay network. The network device may determine whether a host name, of the host device, corresponding to the service name in the multicast query is present in a resource record. In response to determining that the host name is present in the resource record, the network device may identify, from the resource record, an overlay network path corresponding to the host name. The network device may encapsulate the multicast query based on an overlay encapsulation protocol implemented at the first VTEP and route, the encapsulated multicast query, via the overlay network path, to the host device.

Service discovery across tunnel endpoints in overlays

A system for efficient multicast control packet forwarding is provided. During operation, the system can maintain a first tunnel between a first switch and a second switch in an overlay tunnel fabric. The encapsulation of a packet sent via the overlay tunnel fabric is initiated and terminated within the overlay tunnel fabric. The system can maintain a second tunnel between the first switch and a third switch, which can be in an external network that excludes the first and second switches. The switch can distinguish the first and second tunnels as intra-fabric and inter-fabric tunnels, respectively. Upon receiving a multicast control packet via the first tunnel, the system can identify the second tunnel as the inter-fabric tunnel and forward the multicast control packet via the second tunnel. Here, a respective multicast control packet received from the first tunnel can be precluded from being forwarded on intra-fabric tunnels.

Efficient multicast packet forwarding in a distributed tunnel fabric

During operation, a layer-3 (L3) router can receive a trace query to trace multicast paths associated with a multicast group. In response to detecting a layer-2 (L2) switch coupled to the L3 router, the L3 router can construct a request packet and send the request packet to the coupled L2 switch. The request packet comprises a first data block indicating that the request packet is an L2 multicast trace request, thereby causing the L2 switch to propagate the request packet to downstream L2 switches until the request packet reaches a last-hop L2 switch. The L3 router can receive, from the last-hop L2 switch, a reply packet responsive to the L2 multicast trace request, the reply packet comprising one or more data blocks, with each data block comprising information about an L2 switch or client device present on a traversed multicast path for the multicast group.

Multicast datapath tracing in layer-2 networks

A system for enforcement of a set of segmentation policies at a gateway switch of a network is provided. Here, the segmentation policies can indicate which other roles are allowed to communicate with a respective role, which can indicate a set of privileges in the network. During operation, the switch can receive a first message associated with a join request for a multicast group from a host. The switch can also receive a second message comprising data from a source of the multicast group. The first and second messages can indicate first and second roles, respectively, of the host and source. Based on the first and second roles and a corresponding segmentation policy, the system can determine whether the host is allowed to receive the data from the source. If not allowed, the system can prevent the second message from being forwarded to the host from the gateway switch.

Multicast traffic segmentation in an overlay network

Examples disclosed herein relate to a method for defining an ingress access policy at an ingress network device based on instructions from an egress network device. The egress network device receives data packets directed to a first entity from a second entity connected to an ingress network device. Each data packet transmitted includes a source role tag corresponding to the second entity. At the egress network device, the data packets may be dropped based on the enforcement of an egress access policy. When the number of data packets that are being dropped increases beyond a pre-defined threshold, the egress network device transmits a command to the ingress network device instructing the ingress network device to create a restriction on the transmission of subsequent data packets. The command is transmitted in a Border Gateway Protocol (BGP) Flow Specification (FlowSpec) route.

Enabling restriction on transmission of data packets at ingress network device

A system for multicast traffic management in an overlay tunnel fabric is provided. The system can operate a first switch and a second switch of the fabric as part of a virtual switch. The virtual switch can operate as a gateway for the fabric. The system can efficiently deploy a rendezvous point (RP) for a multicast group at the first switch. During operation, the system can determine whether to synchronize a registration packet associated with the multicast group with the second switch based on a type of a first ingress connection associated with the registration packet. The system can then determine whether to receive subsequent registration packets for the multicast group based on the type of the first ingress connection and reception of a join request for the multicast group. The type of a respective connection indicates whether the connection includes an overlay tunnel.

Multicast rendezvous point deployment in a virtual gateway of a distributed tunnel fabric

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

In an example, a wired network device receives a first join message originating from a client device associated with a first wireless access point (WAP) connected to another wired network device in a broadcast domain. An entry corresponding to the client device is created in a remote receiver record of the wired network device. In response to the client device transitioning from the first WAP to a second WAP connected to the wired network device, it is determined that the client device is locally connected to the wired network device. Intention of the client device to receive multicast traffic is identified. A second join message directed to the network address of the multicast group and distributed in the broadcast domain. A traffic flow path for the multicast traffic via the wired network device and the second WAP to the client device is configured.

Growing community of inventors

Bengaluru, India

Tathagata Nandy