Juniper Networks, Inc.

Princy T Elizabeth

Vikram Nagarajan

Kapil Arora

Wen Lin

Robert W Kebler

SelvaKumar Sivaraj

Soumyodeep Joarder

Ramesh Kandula

Ragupathi J

Zhaohui Zhang

Muniyappan Suruttaiyan

John E Drake

Eric C Rosen

Michal Styszynski

Himanshu Agarwal

Levinh Hoang

Naveen Ashik

Xiangrong Cai

Anupam Kumar Singh

Balaji Palanisamy

Suraj Kumar

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

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

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

Dynamically providing traffic via various packet forwarding techniques

In some examples, a method includes receiving, by a first provider edge (PE) device of a layer 3 network, configuration data configuring the PE device to provide, via an Ethernet segment with an edge device, active-active multi-homing layer 2 (L2) virtual bridge connectivity to the edge device using an Ethernet Virtual Private Network (EVPN) instance; receiving, by the first PE device, a multicast Join message for multicast traffic, the multicast Join message identifying a second PE device that also participates in the EVPN instance; processing, by the first PE device, the multicast Join message to generate multicast forwarding state; and forwarding, by the first PE device based at least on the multicast forwarding state, the multicast traffic.

Multicast join message processing by multi-homing devices in an ethernet VPN

In general, the disclosure describes techniques for communicating multicast group leave requests between two or more load-balanced, multi-homed PE routers included in an Ethernet Virtual Private Network (EVPN). The techniques of the disclosure enable the two or more PE routers to synchronize IGMP state and routing information amongst one another to ensure that the one of the multi-homed PE routers elected as the designated forwarder (DF) ceases forwarding the multicast group traffic to the CE router, even if it is not the PE router that receives the IGMP leave request.

Communicating IGMP leave requests between load-balanced, multi-homed provider-edge routers in an ethernet virtual private network

In general, techniques are described for load-balancing responsibility for forwarding of multicast traffic into an active-active Ethernet segment between two or more multi-homed provider edge (PE) routers in an Ethernet Virtual Private Network (EVPN). In one example, a PE router may receive an Internet Group Management Protocol (IGMP) join report for a multicast group. The PE router may send join synch routes used to synchronize the join report for the multicast group across the Ethernet segment. The PE router may deterministically determine whether the PE router is configured to be an elected multicast forwarder for one of a plurality of multicast groups. If the PE router is elected a multicast forwarder, the PE router may configure a forwarding state of the PE router to ignore a designated forwarder calculation and to forward the multicast traffic into the Ethernet segment regardless of whether the PE router is a designated forwarder.

Multicast load balancing in multihoming EVPN networks

Techniques are disclosed for handling withdrawals of Border Gateway Protocol (BGP) join synch routes used to synchronize multicast group join requests. In one example, a first provider edge (PE) router of a plurality of PE routers on an Ethernet segment of an Ethernet Virtual Private Network (EVPN) receives, from a second PE router, a withdrawal of a BGP join synch route. In response, the first PE router determines whether a disruption event or a multicast state timeout event at the second PE router caused the withdrawal. If the disruption event caused the withdrawal, the first PE router retains a multicast state for the multicast group and forwards multicast traffic for the multicast group to a customer edge (CE) router multi-homed to the plurality of the PE routers. If the multicast state timeout event caused the withdrawal, the first PE router deletes the multicast state and stops forwarding the multicast traffic.

Synchronizing multicast state between multi-homed routers in an Ethernet virtual private network

Techniques are described for operating a network switch device associated with a virtual layer two (L2) network instance according to a protocol independent multicast (PIM) relay mode. The PIM relay mode enables the network switch device to receive a PIM control message, i.e., a PIM join and/or prune request, for a multicast group on a downstream port of the network switch device associated with a virtual L2 network instance, determine an upstream neighbor port of the network switch device associated with the instance, and relay the PIM control message on the upstream neighbor port of the network switch device without flooding the PIM control message on all ports of the switch device associated with the instance. In the PIM relay mode, the network switch device avoids triggering join suppression in downstream PIM neighbor devices with receivers, and avoids maintaining upstream states and setting a PIM periodic message timer.

Growing community of inventors

Bengaluru, India

Princy T Elizabeth