Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding Multicast VLAN Registration

 

Multicast VLAN registration (MVR) enables more efficient distribution of IPTV multicast streams across an Ethernet ring-based Layer 2 network.

In a standard Layer 2 network, a multicast stream received on one VLAN is never distributed to interfaces outside that VLAN. If hosts in multiple VLANs request the same multicast stream, a separate copy of that multicast stream is distributed to each requesting VLAN.

When you configure MVR, you create a multicast VLAN (MVLAN) that becomes the only VLAN over which IPTV multicast traffic flows throughout the Layer 2 network. Devices with MVR enabled selectively forward IPTV multicast traffic from interfaces on the MVLAN (source interfaces) to hosts that are connected to interfaces that are not part of the MVLAN that you designate as MVR receiver ports. MVR receiver ports can receive traffic from a port on the MVLAN but cannot send traffic onto the MVLAN, and those ports remain in their own VLANs for bandwidth and security reasons.

Benefits of Multicast VLAN Registration

  • Reduces the bandwidth required to distribute IPTV multicast streams by eliminating duplication of multicast streams from the same source to interested receivers on different VLANs.

How MVR Works

MVR operates similarly to and in conjunction with Internet Group Management Protocol (IGMP) snooping. Both MVR and IGMP snooping monitor IGMP join and leave messages and build forwarding tables based on the media access control (MAC) addresses of the hosts sending those IGMP messages. Whereas IGMP snooping operates within a given VLAN to regulate multicast traffic, MVR can operate with hosts on different VLANs in a Layer 2 network to selectively deliver IPTV multicast traffic to any requesting hosts. This reduces the bandwidth needed to forward the traffic.

Note

MVR is supported on VLANs running IGMP version 2 (IGMPv2) only.

MVR Basics

MVR is not enabled by default on devices that support MVR. You explicitly configure an MVLAN and assign a range of multicast group addresses to it. That VLAN carries MVLAN traffic for the configured multicast groups. You then configure other VLANs to be MVR receiver VLANs that receive multicast streams from the MVLAN. When MVR is configured on a device, the device receives only one copy of each MVR multicast stream, and then replicates the stream only to the hosts that want to receive it, while forwarding all other types of multicast traffic without modification.

You can configure multiple MVLANs on a device, but they must have disjoint multicast group subnets. An MVR receiver VLAN can be associated with more than one MVLAN on the device.

MVR does not support MVLANs or MVR receiver VLANs on a private VLAN (PVLAN).

On non-ELS switches, the MVR receiver ports comprise all the interfaces that exist on any of the MVR receiver VLANs.

On ELS switches, the MVR receiver ports are all the interfaces on the MVR receiver VLANs except the multicast router ports; an interface can be configured in both an MVR receiver VLAN and its MVLAN only if it is configured as a multicast router port in both VLANs. ELS EX Series switches support MVR as follows:

  • Starting in Junos OS Release 18.3R1, EX4300 switches and Virtual Chassis support MVR. You can configure up to 10 MVLANs on these devices.

  • Starting in Junos OS Release 18.4R1, EX2300 and EX3400 switches and Virtual Chassis support MVR. You can configure up to 5 MVLANs on these devices.

  • Starting in Junos OS Release 19.4R1, EX4300 multigigabit model (EX4300-48MP) switches and Virtual Chassis support MVR. You can configure up to 10 MVLANs on these devices.

Note

MVR has some configuration and operational differences on EX Series switches that use the Enhanced Layer 2 Software (ELS) configuration style compared to MVR on switches that do not support ELS. Where applicable, the following sections explain these differences.

MVR Modes

MVR can operate in two modes: MVR transparent mode and MVR proxy mode. Both modes enable MVR to forward only one copy of a multicast stream to the Layer 2 network. However, the main difference between the two modes is in how the device sends IGMP reports upstream to the multicast router. The device essentially handles IGMP queries the same way in either mode.

You configure MVR modes differently on non-ELS and ELS switches. Also, on ELS switches, you can associate an MVLAN with some MVR receiver VLANs operating in proxy mode and others operating in transparent mode if you have multicast requirements for both modes in your network.

MVR Transparent Mode

Transparent mode is the default mode when you configure an MVR receiver VLAN, also called a data-forwarding receiver VLAN.

Note

On ELS switches, you can explicitly configure transparent mode, although it is also the default setting if you don’t configure an MVR receiver mode.

In MVR transparent mode, the device handles IGMP packets destined for both the multicast source VLAN and multicast receiver VLANs similarly to the way that it handles them when MVR is not being used. Without MVR, when a host on a VLAN sends IGMP join and leave messages, the device forwards the messages to all multicast router interfaces in the VLAN. Similarly, when a VLAN receives IGMP queries from its multicast router interfaces, it forwards the queries to all interfaces in the VLAN.

With MVR in transparent mode, the device handles IGMP reports and queries as follows:

  • Receives IGMP join and leave messages on MVR receiver VLAN interfaces and forwards them to the multicast router ports on the MVR receiver VLAN.

  • Forwards IGMP queries on the MVR receiver VLAN to all MVR receiver ports.

  • Forwards IGMP queries received on the MVLAN only to the MVR receiver ports that are in receiver VLANs associated with that MVLAN, even though those ports might not be on the MVLAN itself.

Note

Devices in transparent mode only send IGMP reports in the context of the MVR receiver VLAN. In other words, if MVR receiver ports receive an IGMP query from an upstream multicast router on the MVLAN, they only send replies on the MVR receiver VLAN multicast router ports. The upstream router (that sent the queries on the MVLAN) does not receive the replies and does not forward any traffic, so to solve this problem, you must configure static membership. As a result, we recommend that you use MVR proxy mode instead of transparent mode on the device that is closest to the upstream multicast router. See MVR Proxy Mode.

If a host on a multicast receiver port in the MVR receiver VLAN joins a group, the device adds the appropriate bridging entry on the MVLAN for that group. When the device receives traffic on the MVLAN for that group, it forwards the traffic on that port tagged with the MVLAN tag (even though the port is not in the MVLAN). Likewise, if a host on a multicast receiver port on the MVR receiver VLAN leaves a group, the device deletes the matching bridging entry, and the MVLAN stops forwarding that group’s MVR traffic on that port.

When in transparent mode, by default, the device installs bridging entries only on the MVLAN that is the source for the group address, so if the device receives MVR receiver VLAN traffic for that group, the device would not forward the traffic to receiver ports on the MVR receiver VLAN that sent the join message for that group. The device only forwards traffic to MVR receiver interfaces on the MVLAN. To enable MVR receiver VLAN ports to receive traffic forwarded on the MVR receiver VLAN, you can configure the install option at the [edit protocols igmp-snooping vlans vlan-name data-forwarding receiver] hierarchy level so the device also installs the bridging entries on the MVR receiver VLAN.

MVR Proxy Mode

When you configure MVR in proxy mode, the device acts as an IGMP proxy to the multicast router for MVR group membership requests received on MVR receiver VLANs. That means the device forwards IGMP reports from hosts on MVR receiver VLANs in the context of the MVLAN. and only forwards them to the multicast router ports on the MVLAN. The multicast router receives IGMP reports only on the MVLAN for those MVR receiver hosts.

The device handles IGMP queries in the same way as in transparent mode:

  • Forwards IGMP queries received on the MVR receiver VLAN to all MVR receiver ports.

  • Forwards IGMP queries received on the MVLAN only to the MVR receiver ports that are in receiver VLANs belonging to that MVLAN, even though those ports might not be on the MVLAN itself.

In proxy mode, for multicast group memberships established in the context of the MVLAN, the device installs bridging entries only on the MVLAN and forwards incoming MVLAN traffic to hosts on the MVR receiver VLANs subscribed to those groups. Proxy mode doesn’t support the install option that enables the device to also install bridging entries on the MVR receiver VLANs. As a result, when the device receives traffic on an MVR receiver VLAN, it does not forward the traffic to the hosts on the MVR receiver VLAN because the device does not have bridging entries for those MVR receiver ports on the MVR receiver VLANs.

Proxy Mode on Non-ELS Switches

On non-ELS switches, you configure MVR proxy mode on an MVLAN using the proxy statement at the [edit protocols igmp-snooping vlan vlan-name] hierarchy level along with other IGMP snooping configuration options.

Note

On non-ELS switches, this proxy configuration statement only supports MVR proxy mode configuration. General IGMP snooping proxy operation is not supported.

When this option is enabled on non-ELS switches, the device acts as an IGMP proxy for any MVR groups sourced by the MVLAN in both the upstream and downstream directions. In the downstream direction, the device acts as the querier for those multicast groups in the MVR receiver VLANs. In the upstream direction, the device originates the IGMP reports and leave messages, and answers IGMP queries from multicast routers. Configuring this proxy option on an MVLAN automatically enables MVR proxy operation for all MVR receiver VLANs associated with the MVLAN.

Proxy Mode on ELS Switches

On ELS switches, you configure MVR proxy mode on the MVR receiver VLANs. You can configure MVR proxy mode separately from IGMP snooping proxy mode, as follows:

  • IGMP snooping proxy mode—You can use the proxy statement at the [edit protocols igmp-snooping vlan vlan-name] hierarchy level on ELS switches to enable IGMP proxy operation with or without MVR configuration. When you configure this option for a VLAN without configuring MVR, the device acts as an IGMP proxy to the multicast router for ports in that VLAN. When you configure this option on an MVLAN, the device acts as an IGMP proxy between the multicast router and hosts in any associated MVR receiver VLANs.

    Note

    You configure this proxy mode on the MVLAN only, not on MVR receiver VLANs.

  • MVR proxy mode—On ELS switches, you configure MVR proxy mode on an MVR receiver VLAN (rather than on the MVLAN), using the proxy option at the [edit igmp-snooping vlan vlan-name data-forwarding receiver mode] hierarchy level, when you associate the MVR receiver VLAN with an MVLAN. An ELS switch operating in MVR proxy mode for an MVR receiver VLAN acts as an IGMP proxy for that MVR receiver VLAN to the multicast router in the context of the MVLAN.

MVR VLAN Tag Translation

When you configure MVR, the device sends multicast traffic and IGMP queries packets downstream to hosts in the context of the MVLAN by default. The MVLAN tag is included for VLAN-tagged traffic egressing on trunk ports, while traffic egressing on access ports is untagged.

On ELS EX Series switches that support MVR, for VLANs with trunk ports and hosts on a multicast receiver VLAN that expect traffic in the context of that receiver VLAN, you can configure the device to translate the MVLAN tags into the multicast receiver VLAN tags. See the translate option at the [edit protocols igmp-snooping vlans vlan-name data-forwarding receiver] hierarchy level.

Recommended MVR Configurations in the Access Layer on ELS Switches

Based on the access layer topology of your network, the following sections describe recommended ways you should configure MVR on devices in the access layer to smoothly deliver a single multicast stream to subscribed hosts in multiple VLANs.

Note

These sections apply to EX Series switches running Junos OS with the Enhanced Layer 2 Software (ELS) configuration style only.

MVR in a Single-Tier Access Layer Topology

Figure 1 shows a device in a single-tier access layer topology. The device is connected to a multicast router in the upstream direction (INTF-1), with host trunk or access ports in the downstream direction connected to multicast receivers in two different VLANs (v10 on INTF-2 and v20 on INTF-3).

Figure 1: MVR in a Single-Tier Access Layer Topology
MVR in a Single-Tier
Access Layer Topology

Without MVR, the upstream interface (INTF-1) acts as a multicast router interface to the upstream router and a trunk port in both VLANs. In this configuration, the upstream router would require two integrated routing and bridging (IRB) interfaces to send two copies of the multicast stream to the device, which then would forward the traffic to the receivers on the two different VLANs on INTF-2 and INTF-3.

With MVR configured as indicated in Figure 1, the multicast stream can be sent to receivers in different VLANs in the context of a single MVLAN, and the upstream router only requires one downstream IRB interface on which to send one MVLAN stream to the device.

For MVR to operate smoothly in this topology, we recommend you set up the following elements on the single–tier device as illustrated in Figure 1:

  • An MVLAN with the device’s upstream multicast router interface configured as a trunk port and a multicast router interface in the MVLAN. This upstream interface was already a trunk port and a multicast router port for the receiver VLANs that will be associated with the MVLAN.

    Figure 1 shows an MVLAN configured on the device, and the upstream interface INTF-1 configured previously as a trunk port and multicast router port in v10 and v20, is subsequently added as a trunk and multicast router port in the MVLAN as well.

  • MVR receiver VLANs associated with the MVLAN.

    In Figure 1, the device is connected to Host 1 on VLAN v10 (using trunk interface INTF-2) and Host 2 on v20 (using access interface INTF-3). VLANs v10 and v20 use INTF-1 as a trunk port and multicast router port in the upstream direction. These VLANs become MVR receiver VLANs for the MVLAN, with INTF-1 also added as a trunk port and multicast router port in the MVLAN.

  • MVR running in proxy mode on the device, so the device processes MVR receiver VLAN IGMP group memberships in the context of the MVLAN. The upstream router sends only one multicast stream on the MVLAN downstream to the device, which is forwarded to hosts on the MVR receiver VLANs that are subscribed to the multicast groups sourced by the MVLAN.

    The device in Figure 1 is configured in proxy mode and establishes group memberships on the MVLAN for hosts on MVR receiver VLANs v10 and v20. The upstream router in the figure sends only one multicast stream on the MVLAN through INTF-1 to the device, which forwards the traffic to subscribed hosts on MVR receiver VLANs v10 and v20.

  • MVR receiver VLAN tag translation enabled on receiver VLANs that have hosts on trunk ports, so those hosts receive the multicast traffic in the context of their receiver VLANs. Hosts reached by way of access ports receive untagged multicast packets (and don’t need MVR VLAN tag translation).

    In Figure 1, the device has translation enabled on v10 and substitutes the v10 VLAN tag for the mvlan VLAN tag when forwarding the multicast stream on trunk interface INTF-2. The device does not have translation enabled on v20, and forwards untagged multicast packets on access port INTF-3.

MVR in a Multiple-Tier Access Layer Topology

Figure 2 shows devices in a two-tier access layer topology. The upper or upstream device is connected to the multicast router in the upstream direction (INTF-1) and to a second device downstream (INTF-2). The lower or downstream device connects to the upstream device (INTF-3), and uses trunk or access ports in the downstream direction to connect to multicast receivers in two different VLANs (v10 on INTF-4 and v20 on INTF-5).

Figure 2: MVR in a Multiple-Tier Access Layer Topology
MVR in a Multiple-Tier
Access Layer Topology

Without MVR, similar to the single-tier access layer topology, the upper device connects to the upstream multicast router using a multicast router interface that is also a trunk port in both receiver VLANs. The two layers of devices are connected with trunk ports in the receiver VLANs. The lower device has trunk or access ports in the receiver VLANs connected to the multicast receiver hosts. In this configuration, the upstream router must duplicate the multicast stream and use two IRB interfaces to send copies of the same data to the two VLANs. The upstream device also sends duplicate streams downstream for receivers on the two VLANs.

With MVR configured as shown in Figure 2, the multicast stream can be sent to receivers in different VLANs in the context of a single MVLAN from the upstream router and through the multiple tiers in the access layer.

For MVR to operate smoothly in this topology, we recommend to set up the following elements on the different tiers of devices in the access layer, as illustrated in Figure 2:

  • An MVLAN configured on the devices in all tiers in the access layer. The device in the uppermost tier connects to the upstream multicast router with a multicast router interface and a trunk port in the MVLAN. This upstream interface was already a trunk port and a multicast router port for the receiver VLANs that will be associated with the MVLAN.

    Figure 2 shows an MVLAN configured on all tiers of devices. The upper-tier device is connected to the multicast router using interface INTF-1, configured previously as a trunk port and multicast router port in v10 and v20, and subsequently added to the configuration as a trunk and multicast router port in the MVLAN as well.

  • MVR receiver VLANs associated with the MVLAN on the devices in all tiers in the access layer.

    In Figure 2, the lower-tier device is connected to Host 1 on VLAN v10 (using trunk interface INTF-4) and Host 2 on v20 (using access interface INTF-5). VLANs v10 and v20 use INTF-3 as a trunk port and multicast router port in the upstream direction to the upper-tier device. The upper device connects to the lower device using INTF-2 as a trunk port in the downstream direction to send IGMP queries and forward multicast traffic on v10 and v20. VLANs v10 and v20 are then configured as MVR receiver VLANs for the MVLAN, with INTF-3 also added as a trunk port and multicast router port in the MVLAN. VLANs v10 and v20 are also configured on the upper-tier device as MVR receiver VLANs for the MVLAN.

  • MVR running in proxy mode on the device in the uppermost tier for the MVR receiver VLANs, so the device acts as a proxy to the multicast router for group membership requests received on the MVR receiver VLANs. The upstream router sends only one multicast stream on the MVLAN downstream to the device.

    In Figure 2, the upper-tier device is configured in proxy mode and establishes group memberships on the MVLAN for hosts on MVR receiver VLANs v10 and v20. The upstream router in the figure sends only one multicast stream on the MVLAN, which reaches the upper device through INTF-1. The upper device forwards the stream to the devices in the lower tiers using INTF-2.

  • No MVR receiver VLAN tag translation enabled on MVLAN traffic egressing from upper-tier devices. Devices in the intermediate tiers should forward MVLAN traffic downstream in the context of the MVLAN, tagged with the MVLAN tag.

    The upper device in the figure does not have translation enabled for either receiver VLAN v10 or v20 for the interface INTF-2 that connects to the lower-tier device.

  • MVR running in transparent mode on the devices in the lower tiers of the access layer. The lower devices send IGMP reports upstream in the context of the receiver VLANs because they are operating in transparent mode, and install bridging entries for the MVLAN only, by default, or with the install option configured, for both the MVLAN and the MVR receiver VLANs. The uppermost device is running in proxy mode and installs bridging entries for the MVLAN only. The upstream router sends only one multicast stream on the MVLAN downstream toward the receivers, and the traffic is forwarded to the MVR receiver VLANs in the context of the MVLAN, with VLAN tag translation if the translate option is enabled (described next).

    In Figure 2, the lower device is connected to the upper device with INTF-3 as a trunk port and the multicast router port for receiver VLANs v10 and v20. To enable MVR on the lower-tier device, the two MVR receiver VLANs are configured in MVR transparent mode, and INTF-3 is additionally configured to be a trunk port and multicast router port for the MVLAN.

  • MVR receiver VLAN tag translation enabled on receiver VLANs on lower-tier devices that have hosts on trunk ports, so those hosts receive the multicast traffic in the context of their receiver VLANs. Hosts reached by way of access ports receive untagged packets, so no VLAN tag translation is needed in that case.

    In Figure 2, the device has translation enabled on v10 and substitutes the v10 receiver VLAN tag for mvlan’s VLAN tag when forwarding the multicast stream on trunk interface INTF-4. The device does not have translation enabled on v20, and forwards untagged multicast packets on access port INTF-5.

Release History Table
Release
Description
Starting in Junos OS Release 19.4R1, EX4300 multigigabit model (EX4300-48MP) switches and Virtual Chassis support MVR. You can configure up to 10 MVLANs on these devices.
Starting in Junos OS Release 18.4R1, EX2300 and EX3400 switches and Virtual Chassis support MVR. You can configure up to 5 MVLANs on these devices.
Starting in Junos OS Release 18.3R1, EX4300 switches and Virtual Chassis support MVR. You can configure up to 10 MVLANs on these devices.