Juniper Networks, Inc.

Vikram Nagarajan

Robert W Kebler

Kapil Arora

Princy T Elizabeth

Anish Peter

Soumyodeep Joarder

Wen Lin

Sunil Kumar Malali

Vinod Kumar N

Sanoj Kadavil Vivekanandan

Sunil Kumar

SelvaKumar Sivaraj

Himanshu Agarwal

Ramesh Kandula

Ragupathi J

John E Drake

Nitin Singh

Michal Styszynski

Dinesh Sivaraj

Naveen Ashik

Muniyappan Suruttaiyan

Zhaohui Zhang

Eric C Rosen

Abhishek Asthana

Bharath RadhaKrishna Bhat

Sachin S Natu

Levinh Hoang

Raj Chetan Boddireddy

Suraj Kumar

Goutham Patil R

Jayakumar Ramalingam

Anupam Kumar Singh

Balaji Palanisamy

In some implementations, a first network device that hosts a bridge domain (BD) may receive inter-subnet multicast traffic associated with the BD. The BD may forward, using a supplemental bridge domain (SBD) interface of the first network device, and via an SBD, a first copy of the inter-subnet multicast traffic to a second network device that hosts the BD. The first network device may forward, using the SBD interface and via the SBD, a second copy of the inter-subnet multicast traffic to a third network device that does not host the BD. The first network device may forward, using an integrated routing and bridging (IRB) interface of the first network device associated with the BD, a third copy of the inter-subnet multicast traffic to a fourth network device that hosts the BD (e.g., when the fourth network device is a multihoming peer of the first network device).

Inter-subnet multicast traffic forwarding using supplemental bridge domain (SBD)

A controller device receives, from a plurality of assisted replication network devices, respective utilization information associated with the plurality of assisted replication network devices. The controller device generates, based on the respective utilization information associated with the plurality of assisted replication network devices, load balancing information for a network device associated with two or more assisted replication network devices of the plurality of assisted replication network devices, and sends, to the network device, the load balancing information. The network selects, based on the load balancing information, a particular assisted replication network device of the two or more assisted replication network devices. The network device receives a traffic flow that is to be multicast and sends the traffic flow to the particular assisted replication network device, wherein sending the traffic flow to the particular assisted replication network device permits the particular assisted replication network device to multicast the traffic flow.

Load balancing of assisted replication network devices

An example egress network device includes at least one computer processor and a memory. The memory includes instructions that cause the at least one computer processor to receive messages from each of a plurality of ingress network devices. Each message specifies a multicast source as an anycast address that belongs to two or more sources, a multicast group, and a customer site identifier that uniquely identifies a customer network device via which the anycast address is reachable. The instructions cause the at least one computer processor to select, based on the customer site identifiers, one of the plurality of ingress network devices to which to send a multicast join message of a plurality of multicast join messages for the multicast source and multicast group. The instructions cause the at least one computer processor to send the multicast join message to the selected one of the plurality of ingress network devices.

Upstream multicast hop (UMH) extensions for anycast deployments

The techniques describe example network systems providing core-facing designated forwarder (DF) election to forward multicast traffic into an EVPN of a core network. For example, a first PE device of a plurality of PE devices participating in an EVPN comprises one or more processors operably coupled to a memory, wherein the one or more processors are configured to: determine that a first multicast traffic flow has started for the first PE device; in response, send a source-active (SA) route to indicate the first multicast traffic flow has started for the first PE device; receive, from a second PE device, a second SA route that indicates that a second multicast traffic flow has started for the second PE device; and perform an election of a core-facing DF from among the first PE device and second PE device, wherein the core-facing DF is configured to forward the multicast traffic into the EVPN.

EVPN multicast ingress forwarder election using source-active route

In general, techniques are described for enabling a network of network devices (or 'nodes') to provide redundant multicast streams from redundant multicast sources to an egress network node. In some examples, the egress network node (or a controller for the network) computes maximally redundant trees (MRTs) from the egress network node to a virtual proxy node virtually added to the network topology by the egress network node for redundant multicast sources of redundant multicast streams.

Maximally redundant trees to redundant multicast source nodes for multicast protection

A device may store first information regarding a first pseudowire connection with a first device, wherein the first pseudowire connection provides access to an Ethernet virtual private network (EVPN) to communicate with a host device. The device may store second information regarding a second pseudowire connection with a second device, wherein the second pseudowire connection provides access to the EVPN to communicate with the host device. The device may receive a message that includes a configuration identifier and identify the configuration identifier. The device may change a first characteristic of the first pseudowire connection based on the configuration identifier. The device may change a second characteristic of the second pseudowire connection based on the configuration identifier. The device may receive data from the host device based on changing the first characteristic of the first pseudowire connection and changing the second characteristic of the second pseudowire connection.

Coordinating pseudowire connection characteristics and multi-homed provider edge device capabtilities

Techniques are described for facilitating node protection for Broadcast, unknown Unicast, and Multicast (BUM) traffic for a multi-homed node failure. For example, each VTEP (e.g., PE device) may advertise a protected VTEP address that indicates an IP address of a remote PE device that is to be protected in the event of a node failure. In the event a multi-homed PE device fails, the ingress PE device sends a BUM packet including the protected VTEP address for the failed node. When an egress PE device receives the BUM packet, the egress PE device determines whether the BUM packet includes the protected VTEP address and whether the egress PE device is operating as a backup designated forwarder (DF). If the BUM packet includes the protected VTEP address and the egress PE device is a backup DF, the egress PE device forwards the BUM traffic to the ESI.

Node protection for bum traffic for multi-homed node failure

An example network device includes memory configured to store packet data and processor circuitry coupled to the memory. The processing circuitry is configured to determine that a first host device has moved from a first access network of an Ethernet virtual private network (EVPN) associated with the first PE router to a second access network of the EVPN, wherein the first host device is interested in receiving traffic of a first multicast group. The processing circuitry is configured to determine whether any other host device on the first access network of the network device is interested in receiving traffic of the first multicast group. Based on no other host device on the first access network of the network device being interested in receiving multicast traffic of the first multicast group, the processing circuitry is configured to delete state associated with the first multicast group.

Internet group management protocol host mobility in ethernet virtual private network multicast networks

The techniques describe example network systems for adaptively determining whether to perform ingress replication or assisted replication of a multicast flow based on classification of the multicast flow. For example, a provider edge (PE) device of a plurality of PE devices participating in an EVPN comprises one or more processors operably coupled to a memory, wherein the one or more processors are configured to: receive a multicast traffic flow, determine a classification of the multicast traffic flow, and perform, based at least in part on the classification of the multicast traffic flow, one of: ingress replication of the multicast traffic flow or assisted replication of the multicast traffic flow.

Replication mode selection for EVPN multicast

This disclosure describes techniques for improved multicasting of source VLAN multicast traffic. For example, a method includes receiving, by a switch device within a data center of a leaf and spine network, multicast traffic from a multicast source; sending, by the switch device and to a border device within the data center that is communicatively coupled to a multicast rendezvous point external to the data center, a source-active routing message to indicate that the switch device is receiving multicast traffic from the multicast source; receiving, by the switch device and from the border device, a response routing message including an extended community that indicates whether there are any interested multicast receivers; and configuring, by the switch device, a forwarding engine of the switch device based on the extended community.

Source-active community for improved multicasting

In general, techniques are described for providing control plane-based OISM forwarding. For example, network devices may configure two types of next hops for a multicast group. For example, the next hops may include an L2-switched next hop and an L3-routed next hop. The L2-switched next hop specifies the one or more other PE devices as a next hop for multicast traffic for the multicast group that is received on an access-facing interface of the PE device and switched on a source Virtual Local Area Network (VLAN). The L3-routed next hop specifies a list (e.g., either an empty list or specifying incapable Integrated Routing and Bridging (IRB) devices) as a next hop for multicast traffic for the multicast group that is received over an EVPN core on a core-facing interface of the PE device and locally routed from the source VLAN to a listener VLAN.

Control plane-based EVPN optimized inter-subnet multicast (OISM) forwarding

Port synchronization is provided for multicast on an Ethernet segment (ES) in which a device (CE) is multihomed to at least two devices (PEand PE) of a VLAN. Such example embodiments may do so by providing computer-implemented method for use in a first device belonging to an Ethernet virtual private network (EVPN) and an Ethernet segment (ES), the ES including a second device and a third device, the second device also belonging to the EVPN, the third device being multihomed to the first device and the second device via the ES, and the first and second devices having snooping enabled for multicast group messages, the computer-implemented method comprising: (a) detecting, on a first interface of the first device, from the third device via the ES, a multicast query message, wherein the multicast query message is not detected by the second device via the ES; (b) marking the first interface of the first device as a multicast router port; (c) generating a message identifying the ES and including information encoding that the multicast query message was detected on the ES; and (d) sending, via the EVPN, the message generated to the second device so that the second device will mark an interface, on the ES, with the third device, as a multicast router port.

Synchronizing multicast router capability towards ethernet virtual private network (EVPN) multi-homed protocol independent multicast (PIM) device

Techniques are described for multicast flow prioritization in protocol independent multicast (PIM) networks with multicast flow limits. According to the disclosed techniques, once a router has reached its multicast flow limit, the router may preempt an installed lower priority multicast flow with a newly requested higher priority multicast flow. For example, if a maximum number of multicast flows are installed on the router, then, upon receiving a PIM join for a higher priority flow as compared to the installed flows, the router replaces one of the installed lower priority flows with the received higher priority flow. Furthermore, according to the disclosed techniques, priority values for multicast flows are consistent across a PIM domain and each of the routers within the PIM domain is configured to use the priority values to select a higher priority flow over a lower priority flow.

Multicast flow prioritization

Techniques are described for facilitating node protection for Broadcast, unknown Unicast, and Multicast (BUM) traffic for a multi-homed node failure. For example, multi-homed provider edge (PE) devices each advertise egress node protection labels to an ingress PE device. In the event one of the multi-homed PE devices fails, the ingress PE device sends a BUM packet including the egress node protection labels for the failed node. When an egress PE device receives the BUM packet, the egress PE device determines whether the BUM packet includes the egress node protection labels and whether the egress PE device is operating as a backup designated forwarder (DF) on an Ethernet segment identifier (ESI) for which the failed node was the DF. If the BUM packet includes the egress node protection labels and the egress PE device is operating as a backup DF, the egress PE device forwards the BUM traffic to the ESI.

A device may receive a plurality of traffic flows to be provided to a set of destination devices. The device may process the plurality of traffic flows to identify respective sets of attributes associated with the plurality of traffic flows. The device may assign one of a plurality of traffic forwarding techniques, to a first traffic flow, of the plurality of traffic flows, based on the respective sets of attributes associated with the plurality of traffic flows. The device may provide the plurality of traffic flows to the set of destination devices. The device may determine that a condition, of a set of conditions associated with the plurality of traffic flows, has been satisfied in association with providing the plurality of traffic flows to the set of destination devices. The device may perform a set of actions after determining that the condition has been satisfied.

Growing community of inventors

Bengaluru, India

Vikram Nagarajan