Because MVR is primarily targeted for IPTV and similar applications, a
basic deployment for that application is shown Basic MVR Deployment. In the figure, an IPTV server is connected through a router to a
network of switches. Switch 1 has three customer VLANs, Vlan2, Vlan3, and Vlan4. The
multicast streams are delivered through the network core (Metro Ethernets), which often
use a ring topology and some kind of redundant protection to provide high availability.
For example, McastVlan forms a ring through switches Switch1 through Switch4. The link
from Switch2 to Switch4 is shown as blocked, as it would be if some form of protection
(such as EAPS) is used.
Without MVR, there are two ways to distribute multicast streams
in this topology:
Extend subscriber VLANs (Vlan2,
Vlan3, and Vlan4) to the network core, by tagging the ports connecting the
Configure all VLANS with an IP address and run PIM or DVMRP
on each switch.
There are problems with both of these approaches. In the first
approach, multiple copies of the same stream (IPTV channel) would
be transmitted in the core, wasting bandwidth. In the second approach,
all switches in the network core would have to be Layer 3 multicast
aware, and would have to run a multicast protocol. Typical network
cores are Layer 2 only.
MVR provides a simple solution to this problem If McastVlan in Switch1 is
configured with MVR, it leaks the traffic into the local subscriber VLANs that contain
hosts that request the traffic. For simple cases, perform these configuration steps:
Configure MVR on McastVlan.
Configure an IP address and enable IGMP and IGMP
snooping on the subscriber VLANs (by default IGMP and IGMP snooping are enabled
on Extreme Networks switches).
For all the multicast streams (IPTV channels), configure
static IGMP snooping membership on the router on McastVlan.
Enable MVR on the switches in the network.
MVR works best with IGMPv1 and IGMPv2. We recommend that
you do not use MVR with IGMPv3.
The strategy above conserves bandwidth in the core and does not
require running PIM on the subscriber switches.
In this topology, a host (for example, a cable box or desktop
PC) joins a channel through an IGMP join message. Switch1 snoops
this message and adds the virtual port to the corresponding cache's
egress list. This is possible because an MVR enabled VLAN can leak
traffic to any other VLAN. When the user switches to another channel,
the host sends an IGMP leave for the old channel and a join for
the new channel. The corresponding virtual port is removed from
the cache for the old channel and is added to the cache for the
As discussed in Static and Dynamic MVR, McastVlan also proxies IGMP joins learned on
other VLANs to the router. On an MVR network it is not mandatory to have a router to
serve the multicast stream. All that is required is to have a designated IGMP querier on
McastVlan. The IPTV server can also be directly connected to McastVlan.