- play_arrow Features Common to EVPN-VXLAN, EVPN-MPLS, and EVPN-VPWS
- play_arrow Configuring Interfaces
- play_arrow MAC Address Features with EVPN Networks
- play_arrow Configuring Routing Instances for EVPN
- Configuring EVPN Routing Instances
- Configuring EVPN Routing Instances on EX9200 Switches
- MAC-VRF Routing Instance Type Overview
- EVPN Type 5 Route with VXLAN Encapsulation for EVPN-VXLAN
- EVPN Type 5 Route with MPLS encapsulation for EVPN-MPLS
- Understanding EVPN Pure Type 5 Routes
- Seamless VXLAN Stitching with Symmetric EVPN Type 2 Routes using Data Center Interconnect
- Symmetric Integrated Routing and Bridging with EVPN Type 2 Routes in EVPN-VXLAN Fabrics
- EVPN Type 2 and Type 5 Route Coexistence with EVPN-VXLAN
- Ingress Virtual Machine Traffic Optimization
- Tracing EVPN Traffic and Operations
- Migrating From BGP VPLS to EVPN Overview
- Configuring EVPN over Transport Class Tunnels
- Example: Configuring EVPN-VPWS over Transport Class Tunnels
- play_arrow Configuring Route Targets
- play_arrow Routing Policies for EVPN
- play_arrow Layer 3 Gateways with Integrated Routing and Bridging for EVPN Overlays
- play_arrow EVPN Multihoming
- EVPN Multihoming Overview
- EVPN Multihoming Designated Forwarder Election
- Understanding Automatically Generated ESIs in EVPN Networks
- Easy EVPN LAG (EZ-LAG) Configuration
- Configuring EVPN Active-Standby Multihoming to a Single PE Device
- Configuring EVPN-MPLS Active-Standby Multihoming
- Example: Configuring Basic EVPN-MPLS Active-Standby Multihoming
- Example: Configuring EVPN-MPLS Active-Standby Multihoming
- Example: Configuring Basic EVPN Active-Active Multihoming
- Example: Configuring EVPN Active-Active Multihoming
- Example: Configuring LACP for EVPN Active-Active Multihoming
- Example: Configuring LACP for EVPN VXLAN Active-Active Multihoming
- Example: Configuring an ESI on a Logical Interface With EVPN-MPLS Multihoming
- Configuring Dynamic List Next Hop
- play_arrow Link States and Network Isolation Conditions in EVPN Networks
- play_arrow EVPN Proxy ARP and ARP Suppression, and NDP and NDP Suppression
- play_arrow Configuring DHCP Relay Agents
- play_arrow High Availability in EVPN
- play_arrow Monitoring EVPN Networks
- play_arrow Layer 2 Control Protocol Transparency
-
- play_arrow EVPN-MPLS
- play_arrow Overview
- play_arrow Convergence in an EVPN MPLS Network
- play_arrow Pseudowire Termination at an EVPN
- play_arrow Configuring the Distribution of Routes
- Configuring an IGP on the PE and P Routers on EX9200 Switches
- Configuring IBGP Sessions Between PE Routers in VPNs on EX9200 Switches
- Configuring a Signaling Protocol and LSPs for VPNs on EX9200 Switches
- Configuring Entropy Labels
- Configuring Control Word for EVPN-MPLS
- Understanding P2MPs LSP for the EVPN Inclusive Provider Tunnel
- Configuring Bud Node Support
- play_arrow Configuring VLAN Services and Virtual Switch Support
- play_arrow Configuring Integrated Bridging and Routing
- EVPN with IRB Solution Overview
- An EVPN with IRB Solution on EX9200 Switches Overview
- Anycast Gateways
- Configuring EVPN with IRB Solution
- Configuring an EVPN with IRB Solution on EX9200 Switches
- Example: Configuring EVPN with IRB Solution
- Example: Configuring an EVPN with IRB Solution on EX9200 Switches
- play_arrow Configuring IGMP or MLD Snooping with EVPN-MPLS
-
- play_arrow EVPN E-LAN Services
- play_arrow EVPN-VPWS
- play_arrow Configuring VPWS Service with EVPN Mechanisms
- Overview of VPWS with EVPN Signaling Mechanisms
- Control word for EVPN-VPWS
- Overview of Flexible Cross-Connect Support on VPWS with EVPN
- Overview of Headend Termination for EVPN VPWS for Business Services
- Configuring VPWS with EVPN Signaling Mechanisms
- Example: Configuring VPWS with EVPN Signaling Mechanisms
- FAT Flow Labels in EVPN-VPWS Routing Instances
- Configuring EVPN-VPWS over SRv6
- Configuring Micro-SIDs in EVPN-VPWS
-
- play_arrow EVPN-ETREE
- play_arrow Overview
- play_arrow Configuring EVPN-ETREE
-
- play_arrow Using EVPN for Interconnection
- play_arrow Interconnecting VXLAN Data Centers With EVPN
- play_arrow Interconnecting EVPN-VXLAN Data Centers Through an EVPN-MPLS WAN
- play_arrow Extending a Junos Fusion Enterprise Using EVPN-MPLS
-
- play_arrow PBB-EVPN
- play_arrow Configuring PBB-EVPN Integration
- play_arrow Configuring MAC Pinning for PBB-EVPNs
-
- play_arrow EVPN Standards
- play_arrow Supported EVPN Standards
-
- play_arrow VXLAN-Only Features
- play_arrow Flexible VXLAN Tunnels
- play_arrow Static VXLAN
-
- play_arrow Configuration Statements and Operational Commands
Multicast Support in EVPN-VXLAN Overlay Networks
This topic describes the following multicast feature, which is supported in an EVPN-VXLAN overlay network:
Inter-VLAN Multicast Forwarding Modes for EVPN-VXLAN Overlay Networks
We support a few different multicast forwarding modes based on the type of EVPN-VXLAN architecture you have in your network:
Centrally-routed multicast mode (local-remote forwarding mode)
Edge-routed multicast mode (local-only forwarding mode)
Optimized intersubnet multicast (OISM) mode (combines aspects of local-remote and local-only forwarding modes)
This topic introduces the centrally-routed (local-remote) and edge-routed (local-only) multicast forwarding modes and how they work. For full details on OISM operation and configuration, including regular OISM and enhanced OISM modes, see Optimized Intersubnet Multicast in EVPN Networks.
- Centrally-routed Multicast Mode Support
- Edge-routed Multicast Mode and OISM Support
- Benefits of Inter-VLAN Multicast Forwarding Modes
- Supported EVPN-VXLAN Architectures and Inter-VLAN Multicast Forwarding Modes
- Understanding Multicast Traffic Flows in a Centrally-Routed Bridging Overlay
- Understanding Multicast Traffic Flows in an Edge-Routed Bridging Overlay
- Differences Between Inter-VLAN Multicast Forwarding Modes
Centrally-routed Multicast Mode Support
Starting with Junos OS Release 17.3R3, the QFX10000 line of switches support the centrally-routed mode for inter-VLAN multicast forwarding of IPv4 traffic in an EVPN-VXLAN network. You use this mode with a centrally-routed bridging (CRB) overlay network.
QFX5120 switches support IGMP snooping as leaf devices in multihomed EVPN-VXLAN fabrics in centrally-routed multicast mode starting with the indicated Junos OS releases below. QFX10000 switches serve as spine devices that perform the Layer 3 multicast routing in the centrally-routed bridging (CRB) model.
QFX5120-48Y—Junos OS Release 18.4R2 (although not supported in releases 19.1R1 and 19.1R2)
QFX5120-32C—Junos OS Release 19.1R1
QFX5120-48T—Junos OS Release 20.2R1
QFX5120-48YM—Junos OS Release 20.4R1
Starting with Junos OS Release 20.4R1, QFX5110, QFX5120, and the QFX10000 line of switches support the centrally-routed forwarding mode with MLDv1, MLDv2, and MLD snooping for IPv6 intra-VLAN and IPv6 inter-VLAN multicast traffic in an EVPN-VXLAN overlay network.
Edge-routed Multicast Mode and OISM Support
Starting with Junos OS Release 17.3R3, the QFX10000 line of switches support the edge-routed mode for inter-VLAN multicast forwarding of IPv4 traffic in an EVPN-VXLAN overlay network. You use this mode with an edge-routed bridging (ERB) overlay fabric.
Starting with Junos OS Release 21.2R1, we introduce the OISM routing and forwarding mode for ERB overlay EVPN-VXLAN fabrics on QFX5110, QFX5120, and QFX10002 switches support. The OISM mode enables the leaf devices in the network to efficiently handle multicast traffic routing with an ERB overlay for sources and receivers that are outside of the EVPN network. OISM also scales much better than the original edge-routed multicast mode. As a result, we recommend using OISM for multicast in ERB overlay networks.
Benefits of Inter-VLAN Multicast Forwarding Modes
The configuration statement enables you to choose the inter-VLAN multicast forwarding mode that suits the architecture of your EVPN-VXLAN overlay network.
Supported EVPN-VXLAN Architectures and Inter-VLAN Multicast Forwarding Modes
We support the following modes of inter-VLAN multicast forwarding:
EVPN-VXLAN CRB overlays (EVPN-VXLAN networks with a two-layer IP fabric) support central routing and forwarding of multicast traffic at the spine layer using a local-remote model. CRB overlay networks have a layer of Layer 3 spine devices and another layer of Layer 2 leaf devices. You configure all spine devices with IRB interfaces that route the multicast packets from one VLAN to another. One spine device is elected to handle the inter-VLAN routing for the network.
In this mode, you configure the devices in the fabric with the
irb local-remote
option at the[edit forwarding-options multicast-replication evpn]
hierarchy. (See multicast-replication.)EVPN-VXLAN ERB overlays (EVPN-VXLAN networks with a collapsed IP fabric) support multicast traffic routing and forwarding at the leaf layer using either a local-only model or the OISM model. ERB overlay networks have leaf devices with IRB interfaces that handle multicast routing at Layer 3 and multicast forwarding at Layer 2. The leaf devices essentially act as spine-leaf devices. This fabric model usually has a layer of spine devices acting only as IP transit devices in the fabric, which we commonly refer to as lean spines. All of the leaf devices handle routing multicast packets from one VLAN to another.
You configure supported leaf devices in the ERB fabric with either the
irb local-only
option orirb oism
option at the[edit forwarding-options multicast-replication evpn]
hierarchy. (See multicast-replication.)Note:This topic describes the local-only model.
See Optimized Intersubnet Multicast in EVPN Networks for full details on OISM configuration and operation.
For centrally-routed bridging overlays, you can simply retain the default setting,
irb local-remote
, at the [edit forwarding-options
multicast-replication evpn]
hierarchy level on all spine devices. For
edge-routed bridging overlays, you must explicitly specify the irb
local-only
or irb oism
option on all leaf devices.
We do not recommend specifying the local-remote
option on some
QFX10000 switches and the local-only
option on the other
QFX10000 switches in either of the overlay networks. Doing so might cause the
QFX10000 switches to forward the inter-VLAN multicast traffic
inconsistently.
Understanding Multicast Traffic Flows in a Centrally-Routed Bridging Overlay
This section describes the multicast traffic flows in a centrally-routed bridging overlay.
The network shown in Figure 1 includes the following devices.
![Centrally-Routed Bridging Overlay](../concept/../../images/g300000.png)
Two QFX10000 switches that function as Layer 3 spine devices, on which the following key features are configured:
Centrally-routed (
local-remote
) multicast forwarding mode.Protocol Independent Multicast (PIM). By virtue of PIM hello messages, Spine 1 is elected as the PIM designated router (PIM DR).
VLANs A and B.
Note:For inter-VLAN multicast forwarding to work properly in this scenario, you must configure all VLANs on each spine device.
IRB interfaces associated with VLANs A and B.
Four QFX5100 switches that function as Layer 2 leaf devices, on which VLANs A and B are configured are follows:
Leafs 1 and 3 are configured with VLAN A only.
Leaf 2 is configured with VLAN B only.
Leaf 4 is configured with VLANs A and B.
A multicast source and various receivers.
When the multicast source shown in Figure 1 sends a packet from VLAN A, the following flows occur:
Flow 1: Intra-VLAN traffic—Based on the ingress replication mechanism, Leaf 1 replicates and switches the packet to all spine and other leaf devices. Leafs 3 and 4, on which VLAN A is configured, receive and forward the packet to the connected multicast receivers.
Flow 2: Inter-VLAN traffic—Upon receipt of the packet from Leaf 1 as described in flow 1, Spine 1, which is the PIM DR, takes the following action:
Routes the packet over the IRB interface associated with VLAN B.
Based on the ingress replication mechanism, replicates and forwards the packet to the other spine and the leaf devices.
Leafs 2 and 4, on which VLAN B is configured, receive and forward the packet to the connected multicast receivers.
Understanding Multicast Traffic Flows in an Edge-Routed Bridging Overlay
This section describes the multicast traffic flow in an edge-routed bridging overlay.
The network shown in Figure 2 includes the following devices.
![Edge-Routed Bridging Overlay](../concept/../../images/g300001.png)
Four QFX10002 switches that function as Layer 3 and Layer 2 spine-leaf devices, on which the following key features are configured:
Edge-routed (
local-only
) multicast forwarding mode.PIM. To support the edge-routed mode of multicast forwarding, each spine-leaf device must act as the PIM DR for each VLAN. To enable a spine-leaf device to elect itself as the PIM DR, for each IRB interface, specify the
distributed-dr
configuration statement at the[edit protocols pim interface interface-name]
hierarchy.VLANs A and B.
Note:For inter-VLAN multicast forwarding to work properly in this scenario, you must configure all VLANs on each spine-leaf device.
IRB interfaces associated with VLANs A and B.
A multicast source and various receivers.
When the multicast source shown in Figure 2 sends a packet from VLAN A, the following flows occur:
Flow 1: Intra-VLAN traffic—Based on the ingress replication mechanism, Spine-Leaf 1 replicates and switches the packet to the other spine-leaf devices. The spine-leaf devices forward the packet to VLAN A. Further, Spine-Leafs 2 and 3 forward the packet to VLAN A receivers.
Flow 2: Inter-VLAN traffic—Upon receipt of the packet from Spine-Leaf 1 as described in flow 1, the spine-leaf devices route the packet over the IRB interface associated with VLAN B. Further, Spine-Leafs 2 and 4 forward the packet to the VLAN B receivers.
Differences Between Inter-VLAN Multicast Forwarding Modes
There is an important difference between the centrally-routed and edge-routed modes.
With centrally-routed mode, for each VLAN, the spine device elected as the PIM-DR must replicate and send the packet to the other devices in the network. Keep in mind that the additional instances of replication consume bandwidth, and if many VLANs are configured, can potentially flood the EVPN core with multicast packets.
With edge-routed mode with the local-only model, the first spine-leaf device to receive a multicast packet replicates and sends the packet to the other spine-leaf devices. Upon receipt of the packet, the other spine-leaf devices route the packet to each VLAN and send the packet to access-side interfaces that handle traffic for the multicast receivers. In other words, the spine-leaf devices do not replicate the packet and send the packet out of the EVPN core-facing interfaces, which prevents excessive bandwidth consumption and congestion in the EVPN core.
The OISM model uses local routing, similar to the local-only model, to minimize multicast traffic flow in the EVPN core. However, with OISM, the leaf devices can also efficiently handle multicast traffic flow from sources outside the fabric to receivers within the fabric. OISM similarly enables multicast sources inside the fabric to send traffic to multicast receivers outside the fabric. See Optimized Intersubnet Multicast in EVPN Networks for details on OISM configuration and operation.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.