Abstract: In an example, a network switch may receive a join request, for a multicast group indicated by an overlay multicast address, from a remote network switch. The network switch may be coupled to a source host device and the remote network switch may be coupled to a receiver host device of the multicast group. The network switch and the remote network switch may be configured as virtual endpoints in an overlay network deployed over an underlay network. The network switch may map the overlay multicast address to an underlay multicast address and the remote network switch may join the multicast group represented by the underlay multicast address. The network switch may receive multicast (traffic for the multicast group from the source host device and encapsulate the multicast traffic with a destination address identical to the underlay multicast address. The network switch may then forward the multicast traffic to the multicast group via the underlay network based on the destination address.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: One aspect of the instant application facilitates reduction of multicast group join latency. During operation, the system can receive, at a network device, a first multicast group leave packet corresponding to a first multicast group. In response to receiving a first multicast group leave packet from an IPTV client, the system can simulate a second multicast group join on behalf of the IPTV client by updating, based on a predictive model, at least an entry in a table maintained in hardware with a next likely multicast group that the IPTV client is likely to join; and sending a simulated second multicast group join packet for initiating an IPTV stream associated with the next likely multicast group. In response to receiving an actual second multicast group join packet from the IPTV client, the system can facilitate the IPTV stream to the IPTV client, thereby reducing multicast group join latency.

Abstract: A system for multicast packet management in a first switch in an overlay tunnel fabric is provided. The system can operate the first switch as part of a virtual switch in conjunction with a second switch of the fabric. The virtual switch can operate as a gateway for the fabric. During operation, the system can receive a join request for a multicast group. The system can then determine whether to forward the join request to the second switch based on a type of a first ingress connection of the join request. Upon receiving a data packet for the multicast group, the system can determine how to forward the data packet based on respective types of a second ingress connection and an egress connection of the data packet. The type of a respective connection can indicate whether the connection includes an overlay tunnel.

Abstract: A system that can facilitate multicast forwarding via overlay multicast tunnels in a network is provided. The system can operate as a tunnel endpoint and form a first overlay tunnel with a peer tunnel endpoint. During operation, the system can receive a join request for a multicast group via the first overlay tunnel. The system can identify a local port of the system associated with the multicast group indicated by the join request. The system can then include the first overlay tunnel in a set of forwarding tunnels for multicast traffic of the multicast group based on the join request. Subsequently, the system can forward the multicast traffic of the multicast group received from a local port via the set of forwarding tunnels, thereby limiting forwarding of the multicast traffic to tunnel endpoints associated with the multicast group.

Abstract: One aspect of the instant application facilitates reduction of multicast group join latency. During operation, the system can receive, at a network device, a first multicast group leave packet corresponding to a first multicast group. In response to receiving a first multicast group leave packet from an IPTV client, the system can simulate a second multicast group join on behalf of the IPTV client by updating, based on a predictive model, at least an entry in a table maintained in hardware with a next likely multicast group that the IPTV client is likely to join; and sending a simulated second multicast group join packet for initiating an IPTV stream associated with the next likely multicast group. In response to receiving an actual second multicast group join packet from the IPTV client, the system can facilitate the IPTV stream to the IPTV client, thereby reducing multicast group join latency.

Abstract: 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.

Abstract: 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.

Abstract: A system for multicast packet management in a first switch in an overlay tunnel fabric is provided. The system can operate the first switch as part of a virtual switch in conjunction with a second switch of the fabric. The virtual switch can operate as a gateway for the fabric. During operation, the system can receive a join request for a multicast group. The system can then determine whether to forward the join request to the second switch based on a type of a first ingress connection of the join request. Upon receiving a data packet for the multicast group, the system can determine how to forward the data packet based on respective types of a second ingress connection and an egress connection of the data packet. The type of a respective connection can indicate whether the connection includes an overlay tunnel.

Abstract: Some examples relate to selection of a rendezvous point in an IP multicast network managing multicast group traffic. An example includes transmitting, from a controller in a cloud computing system, messages to a source device and a host device in an IP multicast-capable network, which may include two peer network devices that are virtualized to function as one virtual device. Based on the response to the messages, the controller may determine that the source device is present in OSI layer 3 and the host device is present in OSI layer 2. The controller may determine that the peer network are located downstream in relation to the determined layer of the source device. The controller may select a non-peer network device as a rendezvous point in the IP multicast-capable network. Further to the selection, the controller may synchronize an active-active configuration between the peer network devices.

Abstract: Examples include receiving a first multicast packet, determining a first flow for the first multicast packet based on a multicast protocol, and storing the first flow in a routing table. The first flow comprises a first source and a first group and the routing table comprises a second flow with a second source and the first group. Additionally, examples include programming the first flow into a hardware memory resource and programming a summary flow into the hardware memory resource. The hardware memory resource comprises the second flow and the summary flow comprises a wild character that matches the first source and the second source.

Abstract: 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.

Abstract: Systems are methods are described for predicting and forecasting a resource utilization on network device, particularly for handling multicast flows, by monitoring past resource consumption patterns. A system can include a plurality of multicast clients coupled to a network; and a network device coupled to the network. The network device may be a switch or a router that directs multicast traffic to the plurality of multicast clients. The network device can include a flow prediction controller that determines one or more real-time predictions relating to a demand of the network based on an analysis of an artificial intelligence (AI) forecasting model, such as an Autoregressive Integrated Moving Average (ARIMA) model. Also, the network device can include a resource optimizer that performs a resource management action that optimizes the resources of the network device based on the one or more real-time predictions of the demand of the network and a policy.

Abstract: A network device may send, to a Dynamic Host Configuration Protocol (DHCP) server, a request for an Internet Protocol version 6 (IPv6) address to be assigned to a management port of the network device, wherein IPv6 is disabled at the network device, and may receive a message that includes information associated with a network management system (NMS) and IPv6 configuration information for enabling IPv6 processing on the management port. In response to receiving the IPv6 configuration information, the network device may enable IPv6 processing on the management port of the network device and may register with the NMS based at least in part on the information associated with the NMS. The network device may, in response to receiving one or more configuration commands sent from the NMS to the management port of the network device, configure the network device according to the one or more configuration commands.

Abstract: The present disclosure relates a system and a method of identifying network faults residing in an underlay network. A network device initiating fault analysis sends a query message through a tunnel interface present in an overlay network configured over an underlay network. While an upstream interface is a network tunnel having a first end and a second end, a unicast path from the first end to the second end of the network tunnel is traced using a network route analysis function. Reachability of a destination device present on the second end of the network tunnel is identified. An output of the network route analysis function is appended with an output of a multicast network connectivity determining function to produce an appended result that is shared with the network device initiating fault analysis.

Abstract: Some examples relate to selection of a rendezvous point in an IP multicast network managing multicast group traffic. An example includes transmitting, from a controller in a cloud computing system, messages to a source device and a host device in an IP multicast-capable network, which may include two peer network devices that are virtualized to function as one virtual device. Based on the response to the messages, the controller may determine that the source device is present in OSI layer 3 and the host device is present in OSI layer 2. The controller may determine that the peer network are located downstream in relation to the determined layer of the source device. The controller may select a non-peer network device as a rendezvous point in the IP multicast-capable network. Further to the selection, the controller may synchronize an active-active configuration between the peer network devices.

Abstract: Methods for directly mapping attributes from controllers connected to a switch are provided. Multicast protocols are combined with policy management and applied to systems with multiple host and source devices. Unnecessary data packets are dropped, while only necessary data packets are forwarded. These methods decrease the amount of resources needed to process requests received during multicasting, provide enhanced security options, and further integrate networking solutions.