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

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

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

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

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

Abstract: Port synchronization is provided for multicast on an Ethernet segment (ES) in which a device (CE) is multihomed to at least two devices (PE1 and PE2) of a VLAN.

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

Abstract: Port synchronization is provided for multicast on an Ethernet segment (ES) in which a device (CE) is multihomed to at least two devices (PE1 and PE2) of a VLAN.

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

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

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

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

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

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

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

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

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

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

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

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