WB1 8.33 Catalyst Multicast VLAN Registration

8.33 Catalyst Multicast VLAN Registration

• Configure SW1 so that multicast traffic sent by R1 on VLAN 146 is
received by R5 on VLAN 58.
• Use the configuration that allows R1 to dynamically tracking sources in
other VLANs.

------------------------------

Multicast VLAN registration (MVR) is a special type of multicast traffic delivery
suited to the access layer of metro Ethernet networks, especially for ring
topologies. In these networks, it is common to allocate a VLAN based on a
network’s geographic region. In this configuration, when you send a video
multicast feed to receivers on multiple VLANs, the feed will be replicated for
every VLAN across the ring topology, causing bandwidth over-utilization.

MVR uses a single dedicated VLAN across the whole ring to deliver a multicast
feed to all receivers. The actual receivers reside in different VLANs, but the
switches intercept their IGMP Join requests and pull the multicast feed from the
MVR VLAN to the receiver VLAN. Thus, MVR allows multicast traffic to cross
VLAN boundaries based on client IGMP reports. This function is similar to IGMP
snooping, but the two work independently. You can have both features enable on
the switch, but MVR will only inspect IGMP reports for groups explicitly
configured to be supported by MVR.

There are two modes for the MVR feature: dynamic and compatible. Before we
look into the differences, notice that that MVR and multicast routing are mutually
exclusive. When MVR is enabled, the switch performs like a Layer 2 device with
respect to multicast traffic, and multicast-routing should remain disabled.
However, the switch still inspects IGMP messages and may forward them to the
port where a multicast router is connected or not. Back to the modes - the first
mode is called dynamic. This mode allows the multicast router connected to the
switch ring to listen to the IGMP messages and dynamically create respective
mroute states. That is, IGMP join messages from the clients are forwarded to the
multicast source port, allowing the broadcast of unneeded channels to be
stopped. The other mode, called compatible (the default in switches), inspects
the IGMP messages but does not forward them to multicast router ports. This
was the default mode of operation of the MVR feature in 3500XL switches. If you
use compatible mode, make sure you configured static IGMP joins on the
multicast router to feed the multicast streams down. The default mode assumes
that the source constantly sends down all multicast channels, and does not
process client IGMP joins.

Configure MVR by follow the steps below:

Step 1:
Enable MVR globally using the commands mvr and mvr group <mcastgroup>
<count>. This will enable the MVR feature for the particular group or
for the number of groups specified by the <count> argument and starting at
<mcast-group> address. Note that you cannot have more than 256 address
configured for MVR, and they should never alias. Here aliasing means that two
multicast IP addresses map to the same multicast MAC address (see the
previous task). For example addresses 228.1.1.1 and 230.1.1.1 would alias to
the same MAC address and would be rejected.

Step 2:
Define the MVR VLAN – this is the VLAN that will span multiple switches and
carry the actual multicast traffic feed. This VLAN should be allowed on all trunks
to permit multicast delivery. The command is mvr vlan <vlan-id>. You may
also define the MVR mode by using the command mvr {dynamic|compatible}

Step 3:
Configure the source and receiver interfaces, using the interface-mode command
mvr type {source|receiver}. Additionally, you may configure ports for
immediate leave, using the command mvr immediate. When this command is
enabled, any single IGMP Leave would cause the switch to prune the port from
receiving multicast feeds. This is good for the ports that have only one host
connected.

Step 4:
Optionally, configure static group joins using the command mvr vlan <vlanid>
group <ip-address> on receiver ports. This is similar to the static join
command configured ona router, but it allows pulling multicast traffic from the
MVR VLAN. Another optional command is mvr querytime <1/10 of
second>. This command is similar to the igmp query-max-response-time
configured on routers. The switch passively listens to IGMP general
queries sent from multicast routers, and then starts the querytime timer,
waiting for client replies. If no replies are received during the interval, the switch
prunes the port from the list of output ports for the group.

Notice that you cannot configure trunk ports as MVR receivers.

SW1:
no ip multicast-routing distributed
mvr
mvr vlan 146
mvr group 239.1.1.100
mvr mode dynamic
!
interface FastEthernet 0/1
mvr type source
!
interface FastEthernet 0/5
mvr type receiver

---------------------------------------------

Check the MVR settings on SW1. Since the mode is dynamic, R1 should receive
IGMP Joins from R5.

Rack1SW1#show mvr
MVR Running: TRUE
MVR multicast VLAN: 146
MVR Max Multicast Groups: 256
MVR Current multicast groups: 1
MVR Global query response time: 5 (tenths of sec)
MVR Mode: dynamic
Rack1SW1#

Rack1SW1#show mvr interface
Port      Type       Status           Immediate Leave
----      ----       ------           ---------------
Fa1/0/1   SOURCE     ACTIVE/UP        DISABLED 
Fa1/0/5   RECEIVER   ACTIVE/UP        DISABLED 
Rack1SW1#

Rack1SW1#show mvr members
MVR Group IP    Status          Members
------------    ------          -------
239.001.001.100 ACTIVE          Fa1/0/1(d)
Rack1SW1#

在R5上啟動Multicast，將Fa0/0加入239.1.1.100的group中

R5:
ip multicast-routing
interface FastEthernet 0/0
 ip pim dense-mode
 ip igmp join-group 239.1.1.100

Rack1SW1#show mvr members
MVR Group IP    Status          Members
------------    ------          -------
239.001.001.100 ACTIVE          Fa1/0/1(d), Fa1/0/5(d)
Rack1SW1#

Rack1R1#show ip igmp groups
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
239.1.1.100      FastEthernet0/0          00:26:18  00:02:49  155.1.58.5     
224.0.1.40       FastEthernet0/0          00:26:28  00:02:21  155.1.146.6    
Rack1R1#

Now source the multicast feed from R1 and check that R5 actually receives the
multicast packets by using the appropriate debug command. Notice that you will
need to disable multicast route caching on R5 for this to work.

Rack1R1#ping 239.1.1.100 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.1.1.100, timeout is 2 seconds:
...

Rack1R5#debug ip mpacket
IP multicast packets debugging is on
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=89, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=90, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP
Rack1R5#
IP(0): s=155.1.146.1 (FastEthernet0/0) d=239.1.1.100 id=91, ttl=253,
prot=1, len=114(100), RPF lookup failed for source or RP