The goal for MVR is to limit the multicast traffic in the core Layer 2 network to only the designated multicast VLAN (Virtual LAN). If the backbone Layer 2 port is tagged with multiple VLANs, as shown in Multiple VLANs in the Core Network, a set of rules is needed to restrict the multicast streams to only one VLAN in the core.
The core network has 2 more VLANs, vc1 and vc2, to provide other services. With MVR, multicast traffic should be confined to McastVlan, and should not be forwarded to vc1 and vc2. It should be noted that MVR is configured only on the ingress VLAN (McastVlan). MVR is not configured on any other VLANs.
In the same way as the IGMP (Internet Group Management Protocol) snooping forwarding rules, the multicast stream is forwarded onto member ports and router ports on the VLAN. For a stream received on MVR enabled ports, this rule is extended to extend membership and router ports to all other VLANs. This rule works well on the topology in Multiple VLANs in the Core Network. However, in a tagged core topology, this rule forwards traffic onto VLANs, such as vc1 and vc2, on ports PC1 and PC2. This results in multiple copies of same stream on the core network, thus reintroducing the problem that MVR was intended to solve.
To avoid multiple copies of the same stream, MVR forwards traffic with some special restrictions. MVR traffic is not forwarded to another VLAN unless a host is detected on the port. On the ingress MVR VLAN, packets are not duplicated to ports belonging to MVR VLANs. This is to prevent duplicate multicast traffic streams on ingress ports. Streams belonging to static MVR groups are always forwarded on MVR VLANs so that any host can join such channels immediately. However, dynamic groups are streamed from the server only if some host is interested in them. A command is provided to receive traffic on a port which is excluded by MVR. However, regular IGMP rules still apply to these ports, so the ports must have a router connected or an IGMP host to receive the stream.
These rules are to prevent multicast packets from leaking into an undesired virtual port, such as p2 on VLAN pc2 in Multiple VLANs in the Core Network. These rules also allow that, in most topologies, MVR can be deployed with minimal configuration. However, unlike EAPS (Extreme Automatic Protection Switching) and STP (Spanning Tree Protocol), MVR is not intended to be a Layer 2 protocol to solve packet looping problems. Since multicast packets leak across VLANs, one can misconfigure and end up with a multicast storm. MVR does not attempt to solve such problems.
Note
If a port is blocked by Layer 2 protocols, that port is removed from the egress list of the cache. This is done dynamically per the port state.For most situations, you do not need to manually configure ports to receive the MVR multicast streams. But if one of the forwarding rules denies forwarding to a port that requires the streams, you can manually receive the MVR multicast streams by using the following command:
configure mvr vlan vlan_name add receiver port port-list