Enterprise products and services are set forth in the express warranty statements acco mpanying such
products and services. Nothing herein should be construe d as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions co ntained herein.
Confidential computer software. V alid license from Hewlett Packard Enterprise required for possession, use, or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and T e chnical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard
Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise
website.
Acknowledgments
Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the
United States and other countries.
Microsoft® and Windows® are trademarks of the Microsoft group of companies.
Adobe® and Acrobat® are trademarks of Adobe Systems In corporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
Information transmission techniques ·········································································································· 1
Multicast features ······································································································································· 3
Common notations in multicast ·················································································································· 4
Disabling a port from becoming a dynamic router port ············································································ 24
Configuring an IGMP snooping querier ············································································································ 25
Configuring the source IP addresses for the IGMP messages sent by the proxy ···································· 28
Configuring IGMP snooping policies ················································································································ 28
Setting the maximum number of multicast groups that a port can join ···················································· 31
Enabling multicast group replacement ····································································································· 32
Setting the 802.1p precedence for IGMP messages ··············································································· 33
Configuring a multicast user control policy ······························································································· 33
Enabling the IGMP snooping host tracking function ················································································ 34
Setting the DSCP value for IGMP messages ··························································································· 34
Displaying and maintaining IGMP snooping ···································································································· 35
IGMP snooping configuration examples ·········································································································· 35
i
Group policy and simulated joining configuration example (in a VLAN) ·················································· 36
Static port configuration example (in a VLAN) ························································································· 38
IGMP snooping querier configuration example ························································································ 41
IGMP snooping proxying configuration example ······················································································ 43
Multicast source and user control policy configuration example ······························································ 46
Troubleshooting IGMP snooping ····················································································································· 50
Layer 2 multicast forwarding cannot function ··························································································· 50
Configured multicast group policy fails to take effect ··············································································· 51
Appendix ·························································································································································· 51
Processing of multicast protocol messages ····························································································· 51
Configuring user port attributes ················································································································ 62
Configuring multicast VLAN ports ············································································································ 63
Setting the maximum number of forwarding entries for multicast VLANs ························································ 64
Displaying and maintaining a multicast VLAN ································································································· 64
Multicast VLAN configuration examples ·········································································································· 64
Sub-VLAN-based multicast VLAN configuration example ······································································· 64
Port-based multicast VLAN configuration example ·················································································· 68
Configuring multicast routing and forwarding ················································ 72
Configuring a multicast routing policy ······································································································ 79
Configuring a multicast forwarding range ································································································· 80
Configuring the multicast forwarding table size ························································································ 80
Tracing a multicast path ··························································································································· 81
Enabling multicast optimization ················································································································ 81
Displaying and maintaining multicast routing and forwarding ·········································································· 82
Multicast routing and forwarding configuration examples ················································································ 83
RPF route change configuration example ································································································ 83
RPF route creation configuration example ······························································································· 85
Multicast forwarding over a GRE tunnel ··································································································· 87
Troubleshooting multicast routing and forwarding ··························································································· 91
Configuring an interface as a static member interface ··········································································· 100
Configuring a multicast group filter ········································································································· 101
Setting the maximum number of multicast groups that an interface can join ········································· 101
Adjusting IGMP performance ························································································································· 101
Enabling the IGMP host tracking function ······························································································ 105
Setting the DSCP value for IGMP messages ························································································· 106
Configuring IGMP SSM mapping ··················································································································· 106
Configuring an RP ·································································································································· 139
Configuring a BSR ································································································································· 141
Configuring an RP ·································································································································· 150
Configuring a BSR ································································································································· 152
Configuring the SSM group range ·········································································································· 158
Configuring common PIM features ················································································································ 159
Configuration task list ····························································································································· 159
Configuring PIM to work with BFD ········································································································· 164
Setting the DSCP value for PIM messages ··························································································· 165
Displaying and maintaining PIM ····················································································································· 165
PIM configuration examples ··························································································································· 167
PIM-DM configuration example ·············································································································· 167
PIM-SM non-scoped zone configuration example ················································································· 170
PIM-SM admin-scope zone configuration example ················································································ 175
BIDIR-PIM configuration example ·········································································································· 181
PIM-SSM configuration example ············································································································ 186
Troubleshooting PIM ······································································································································ 188
A multicast distribution tree cannot be built correctly ············································································· 188
Multicast data abnormally terminated on an intermediate router ··························································· 189
RPs cannot join SPT in PIM-SM ············································································································ 190
RPT establishment failure or source registration failure in PIM-SM ······················································· 190
Enabling the MBGP ORF capability ······································································································· 234
Configuring the maximum number of MBGP ECMP routes ··································································· 235
Configuring a large scale MBGP network ······································································································ 235
Clearing MBGP information ··················································································································· 239
MBGP configuration example ························································································································ 239
Configuring multicast VPN (available only on the HPE 5800) ····················· 243
Protocols and standards ························································································································ 250
v
How MD-VPN works ······································································································································ 250
Configuring BGP MDT peers or peer groups ························································································· 264
Configuring a BGP MDT route reflector ································································································· 264
Specifying the source IP address for multicast across VPNs ········································································ 265
Disabling a port from becoming a dynamic router port ·········································································· 315
Configuring an MLD snooping querier ··········································································································· 315
Configuring the source IPv6 addresses for the MLD messages sent by the proxy ································ 318
Configuring an MLD snooping policy ············································································································· 319
Setting the maximum number of multicast groups that a port can join ·················································· 321
Enabling IPv6 multicast group replacement ··························································································· 322
Setting the 802.1p precedence for MLD messages ··············································································· 323
Configuring an IPv6 multicast user control policy ·················································································· 323
Enabling the MLD snooping host tracking function ················································································ 324
Setting the DSCP value for MLD messages ·························································································· 325
Displaying and maintaining MLD snooping ···································································································· 325
MLD snooping configuration examples ·········································································································· 326
IPv6 group policy and simulated joining configuration example (in a VLAN) ········································· 326
Static port configuration example (in a VLAN) ······················································································· 328
MLD snooping querier configuration example (in a VLAN) ···································································· 331
MLD snooping proxying configuration example (in a VLAN) ·································································· 333
IPv6 multicast source and user control policy configuration example (in a VLAN) ································ 336
Troubleshooting MLD snooping ····················································································································· 341
Layer 2 multicast forwarding cannot function ························································································· 341
Configured IPv6 multicast group policy fails to take effect ····································································· 341
Appendix ························································································································································ 342
Processing of IPv6 multicast protocol messages ··················································································· 342
Configuring the MLD version ·················································································································· 383
Configuring an interface as a static member interface ··········································································· 383
Configuring an IPv6 multicast group filter ······························································································ 384
Setting the maximum number of IPv6 multicast groups that an interface can join ································· 384
Adjusting MLD performance ·························································································································· 385
Enabling the MLD host tracking function ································································································ 389
Setting the DSCP value for MLD messages ·························································································· 389
Configuring MLD SSM mapping ···················································································································· 389
Configuring an RP ·································································································································· 422
Configuring a BSR ································································································································· 424
Configuring an RP ·································································································································· 431
Configuring a BSR ································································································································· 433
Configuring the IPv6 SSM group range ································································································· 439
Configuring common IPv6 PIM features ········································································································ 440
Configuration task list ····························································································································· 440
Configuring an IPv6 MBGP peer ············································································································ 479
Configuring a preferred value for routes from a peer or a peer group ··················································· 479
Controlling route distribution and reception ··································································································· 480
Enabling the IPv6 MBGP ORF capability ······························································································· 487
Configuring the maximum number of ECMP routes ··············································································· 488
Configuring a large scale IPv6 MBGP network ······························································································ 488
Remote support ······································································································································ 498
Index ··········································································································· 499
x
Multicast overview
As a technique that coexists with unicast and broadcast, the multicast technique effectively
addresses the issue of point-to-multipoint data transmission. By enabling high-efficiency
point-to-multipoint data transmission over a network, multicast greatly saves network bandwidth and
reduces network load.
Using multicast technology, a network operator can easily provide bandwidth-critical and time-critical
information services. These services include live webcasting, Web TV, distance learning,
telemedicine, Web radio, and real-time video conferencing.
Unless otherwise stated, the term "multicast" in this document refers to IP multicast.
Information transmission techniques
The information transmission techniques include unicast, broadcast, and multicast.
Unicast
In unicast transmission, the information source must send a separate copy of information to each
host that needs the information.
Figure 1 Unicast transmission
Host A
Receiver
Host B
Source
Host C
Receiver
Host D
IP network
Packets for Host B
Packets for Host D
Packets for Host E
Receiver
Host E
In Figure 1, assume that Host B, Host D and Host E need the information. A separate transmission
channel must be established from the information source to each of these hosts.
In unicast transmission, the traffic transmitted over the network is proportional to the number of hosts
that need the information. If a large number of hosts need the information, the information source
must send a separate copy of the same information to each of these hosts. Sending many copies
can place a tremendous pressure on the information source and the network bandwidth.
Unicast is not suitable for batch transmission of information.
1
Broadcast
In broadcast transmission, the information source sends information to all hosts on the subnet, even
if some hosts do not need the information.
Figure 2 Broadcast transmission
Multicast
In Figure 2, assume that only Host B, Host D, and Host E need the information. If the information is
broadcast to the subnet, Host A and Host C also receive it. In addition to information security issues,
broadcasting to hosts that do not need the information also causes traffic flooding on the same
subnet.
Broadcast is disadvantageous in transmitting data to specific hosts. Moreover, broadcast
transmission is a significant waste of network resources.
Unicast and broadcast techniques cannot provide point-to-multipoint data transmissions with the
minimum network consumption.
Multicast transmission can solve this problem. When some hosts on the network need multicast
information, the information sender, or multicast source, sends only one copy of the information.
Multicast distribution trees are built through multicast routing protocols, and the packets are
replicated only on nodes where the trees branch.
2
Figure 3 Multicast transmission
As shown in Figure 3, the multicast source sends only one copy of the information to a multicast
group. Host B, Host D and Host E, which are receivers of the information, must join the multicast
group. The routers on the network duplicate and forward the information based on the distribution of
the group members. Finally, the information is correctly delivered to Host B, Host D, and Host E.
To summarize, multicast has the following advantages:
• Advantages over unicast—Multicast traffic is replicated and distributed until it flows to the
farthest-possible node from the source. The increase of receiver hosts will not remarkably
increase the load of the source or the usage of network resources
• Advantages over broadcast—Multicast data is sent only to the receivers that need it. This
reasonably uses network bandwidth and enhances network security. In addition, multicast data
is not confined to the same subnet.
Multicast features
Multicast transmission has the following features:
•A multicast group is a multicast receiver set identified by an IP multicast address. Hosts join a
multicast group to become members of the multicast group before they can receive the
multicast data addressed to that multicast group. Typically, a multicast source does not need to
join a multicast group.
•An information sender is called a "multicast source." A multicast source can send data to
multiple multicast groups at the same time. Multiple multicast sources can send data to the
same multicast group at the same time.
•All hosts that have joined a multicast group become members of the multicast group. The group
memberships are dynamic. Hosts can join or leave multicast groups at any time. Multicast
groups are not subject to geographic restrictions.
•Routers or Layer 3 switches that support Layer 3 multicast are called "multicast routers" or
"Layer 3 multicast devices." In addition to providing the multicast routing function, a multicast
router can also manage multicast group memberships on stub subnets with attached group
members. A multicast router itself can be a multicast group member.
For a better understanding of the multicast concept, you can compare multicast transmission to the
transmission of TV programs as shown in Table 1.
3
Table 1 Comparing TV program transmission and multicast transmission
TV transmission Multicast transmission
A TV station transmits a TV program through a
channel.
A user tunes the TV set to the channel. A receiver joins the multicast group.
The user starts to watch the TV program
transmitted by the TV station through the
channel.
The user turns off the TV set or tunes to another
channel.
Common notations in multicast
The following notations are commonly used in multicast transmission:
• (*, G)—Rendezvous point tree (RPT), or a multicast packet that any multicast source sends to
multicast group G. Here, the asterisk represents any multicast source, and "G" represents a
specific multicast group.
• (S, G)—Shortest path tree (SPT), or a multicast packet that multicast source S sends to
multicast group G. Here, "S" represents a specific multicast source, and "G" represents a
specific multicast group.
For more information about the concepts RPT and SPT, see "Configuring PIM" and "Configuring
IPv6 PIM."
A multicast source sends multicast data to a multicast
group.
The receiver starts to receive the multicast data that the
source is sending to the multicast group.
The receiver leaves the multicast group or joins another
group.
Multicast advantages and applications
Multicast advantages
Advantages of the multicast technique include the following:
• Enhanced efficiency—Reduces the processor load of information source servers and network
devices.
• Optimal performance—Reduces redundant traffic.
• Distributed application—Enables point-to-multipoint applications at the price of minimum
network resources.
Multicast applications
The scenarios in which the multicast technique can be effectively applied are:
•Multimedia and streaming applications, such as Web TV, Web radio, and real-time video/audio
conferencing
•Communication for training and cooperative operations, such as distance learning and
telemedicine
• Data warehouse and financial applications (stock quotes)
• Any other point-to-multipoint application for data distribution
Multicast models
Based on how the receivers treat the multicast sources, the multicast models include any-source
multicast (ASM), source-filtered multicast (SFM), and source-specific multicast (SSM).
4
ASM model
In the ASM model, any sender can send information to a multicast group as a multicast source.
Receivers can join a multicast group (identified by a group address) and obtain multicast information
addressed to that multicast group. In this model, receivers do not know the positions of the multicast
sources in advance. However, they can join or leave the multicast group at any time.
SFM model
The SFM model is derived from the ASM model. To a sender, the two models appear to have the
same multicast membership architecture.
The SFM model functionally extends the ASM model. The upper-layer software examines the source
address of received multicast packets and permits or denies multicast traffic from specific sources.
Therefore, receivers can receive the multicast data from only part of the multicast sources. To a
receiver, not all multicast sources are valid because they are filtered.
SSM model
Users might be interested in the multicast data from only certain multicast sources. The SSM model
provides a transmission service that enables users to specify the multicast sources that they are
interested in at the client side.
In the SSM model, receivers have already determined the locations of the multicast sources. This is
the main difference between the SSM model and the ASM model. In addition, a different multicast
address range than the ASM/SFM model is used in the SSM model. Dedicated multicast forwarding
paths are established between receivers and the specified multicast sources.
Multicast architecture
IP multicast addresses the following issues:
• Where should the multicast source transmit information to? (Multicast addressing.)
• What receivers exist on the network? (Host registration.)
• Where is the multicast source that provides data to the receivers? (Multicast source discovery.)
• How should information be transmitted to the receivers? (Multicast routing.)
IP multicast is an end-to-end service. The multicast architecture involves the following parts:
• Addressing mechanism—A multicast source sends information to a group of receivers
through a multicast address.
• Host registration—Receiver hosts can join and leave multicast groups dynamically. This
mechanism is the basis for management of group memberships.
• Multicast routing—A multicast distribution tree (a forwarding path tree for multicast data on the
network) is constructed for delivering multicast data from a multicast source to receivers.
• Multicast applications—A software system that supports multicast applications, such as video
conferencing, must be installed on multicast sources and receiver hosts. The TCP/IP stack
must support reception and transmission of multicast data.
Multicast addresses
Network-layer multicast addresses (multicast IP addresses) enables communication between
multicast sources and multicast group members. In addition, a technique must be available to map
multicast IP addresses to link-layer multicast MAC addresses.
IP multicast addresses
•IPv4 multicast addresses:
5
Internet Assigned Numbers Authority (IANA) assigned the Class D address space (224.0.0.0 to
239.255.255.255) for IPv4 multicast.
Table 2 Class D IP address blocks and description
Address block Description
Reserved permanent group addresses. The IP address 224.0.0.0
is reserved. Other IP addresses can be used by routing protocols
and for topology searching, protocol maintenance, and so
224.0.0.0 to 224.0.0.255
224.0.1.0 to 238.255.255.255
239.0.0.0 to 239.255.255.255
NOTE:
on. Table 3 lists common permanent group addresses. A packet
destined for an address in this block is not forwarded beyond the
local subnet regardless of the Time to Live (TTL) value in the IP
header.
Globally scoped group addresses. This block includes the
following types of designated group addresses:
• 232.0.0.0/8—SSM group addresses.
• 233.0.0.0/8—Glop group addresses.
Administratively scoped multicast addresses. These addresses
are considered locally unique rather than globally unique, and can
be reused in domains administered by different organizations
without causing conflicts. For more information, see RFC 2365.
"Glop" is a mechanism for assigning multicast addresses between different ASs. By filling an AS
number into the middle two bytes of 233.0.0.0, you get 255 multicast addresses for that AS. For
more information, see RFC 2770.
Table 3 Some reserved multicast addresses
Address Description
224.0.0.1 All systems on this subnet, including hosts and routers.
224.0.0.2 All multicast routers on this subnet.
224.0.0.3 Unassigned.
224.0.0.4 DVMRP routers.
224.0.0.5 OSPF routers.
224.0.0.6 OSPF designated routers and backup designated routers.
224.0.0.7 Shared Tree (ST) routers.
224.0.0.8 ST hosts.
224.0.0.9 RIPv2 routers.
224.0.0.11 Mobile agents.
224.0.0.12 DHCP server/relay agent.
224.0.0.13 All Protocol Independent Multicast (PIM) routers.
•IPv6 multicast addresses:
Figure 4 IPv6 multicast format
The following describes the fields of an IPv6 multicast address as shown in Figure 4:
{0xFF—The most significant eight bits are 11111111, which indicates that this address is an
IPv6 multicast address.
{Flags—The Flags field contains four bits as shown in Figure 5 and described in Table 4.
Figure 5 Flags field format
Table 4 Flags field description
Bit Description
0 Reserved, set to 0.
•When set to 0, it indicates that this address is an IPv6
multicast address without an embedded RP address.
R
•When set to 1, it indicates that this address is an IPv6
multicast address with an embedded RP address. (The P
and T bits must also be set to 1.)
•When set to 0, it indicates that this address is an IPv6
multicast address not based on a unicast prefix.
P
•When set to 1, it indicates that this address is an IPv6
multicast address based on a unicast prefix. (The T bit must
also be set to 1.)
•When set to 0, it indicates that this address is an IPv6
T
multicast address permanently-assigned by IANA.
•When set to 1, it indicates that this address is a transient, or
dynamically assigned IPv6 multicast address.
{Scope—The Scope field contains four bits, which indicate the scope of the IPv6
internetwork for which the multicast traffic is intended. Table 5 d
escribes the values of the
Scope field.
Table 5 Values of the Scope field
Value Meaning
0, F Reserved.
1 Interface-local scope.
2 Link-local scope.
3 Subnet-local scope.
4 Admin-local scope.
5 Site-local scope.
7
Value Meaning
6, 7, 9 through D Unassigned.
8 Organization-local scope.
E Global scope.
{Group ID—The Group ID field contains 112 bits. It uniquely identifies an IPv6 multicast
group in the scope that the Scope field defines.
Ethernet multicast MAC addresses
A multicast MAC address identifies a group of receivers at the data link layer.
•IPv4 multicast MAC addresses:
As defined by IANA, the most significant 24 bits of an IPv4 multicast MAC address are
0x01005E. Bit 25 is 0, and the other 23 bits are the least significant 23 bits of a multicast IPv4
address.
Figure 6 IPv4-to-MAC address mapping
As shown in Figure 6, the most significant four bits of a multicast IPv4 address are 1110, which
indicates that this address is a multicast address. Only 23 bits of the remaining 28 bits are
mapped to a MAC address, so five bits of the multicast IPv4 address are lost. As a result, 32
multicast IPv4 addresses map to the same IPv4 multicast MAC address. Therefore, in Layer 2
multicast forwarding, a switch might receive some multicast data destined for other IPv4
multicast groups. The upper layer must filter such redundant data.
•IPv6 multicast MAC addresses:
As shown in Figure 7, the
most significant 16 bits of an IPv6 multicast MAC address are 0x3333.
The least significant 32 bits are the least significant 32 bits of a multicast IPv6 address.
Figure 7 An example of IPv6-to-MAC address mapping
8
Multicast protocols
Multicast protocols include the following categories:
•Layer 3 and Layer 2 multicast protocols:
{Layer 3 multicast refers to IP multicast operating at the network layer.
This section provides only general descriptions about applications and functions of the Layer 2 and
Layer 3 multicast protocols in a network. For more information about these protocols, see the related
chapters.
Layer 3 multicast protocols
Layer 3 multicast protocols include multicast group management protocols and multicast routing
protocols.
Figure 8 Positions of Layer 3 multicast protocols
•Multicast group management protocols:
Typically, the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery
(MLD) protocol is used between hosts and Layer 3 multicast devices that directly connect to the
hosts. These protocols define the mechanism of establishing and maintaining group
memberships between hosts and Layer 3 multicast devices.
•Multicast routing protocols:
A multicast routing protocol runs on Layer 3 multicast devices to establish and maintain
multicast routes and forward multicast packets correctly and efficiently. Multicast routes
constitute loop-free data transmission paths from a data source to multiple receivers, that is, a
multicast distribution tree.
9
In the ASM model, multicast routes include intra-domain routes and inter-domain routes.
distribution trees within an AS to deliver multicast data to receivers. Among a variety of
mature intra-domain multicast routing protocols, Protocol Independent Multicast (PIM) is
most widely used. Based on the forwarding mechanism, PIM has dense mode (often
referred to as "PIM-DM") and sparse mode (often referred to as "PIM-SM").
{An inter-domain multicast routing protocol is used for delivery of multicast information
between two ASs. So far, mature solutions include Multicast Source Discovery Protocol
(MSDP) and Multicast Border Gateway Protocol (MBGP). MSDP propagates multicast
source information among different ASs. MBGP is an extension of the Multiprotocol Border
Gateway Protocol (MP-BGP) for exchanging multicast routing information among different
ASs.
For the SSM model, multicast routes are not divided into intra-domain routes and inter-domain
routes. Because receivers know the position of the multicast source, channels established
through PIM-SM are sufficient for the transport of multicast information.
Layer 2 multicast protocols
Layer 2 multicast protocols include IGMP snooping, MLD snooping, PIM snooping, IPv6 PIM
snooping, multicast VLAN, and IPv6 multicast VLAN.
Figure 9 Positions of Layer 2 multicast protocols
•IGMP snooping and MLD snooping:
IGMP snooping and MLD snooping are multicast constraining mechanisms that run on Layer 2
devices. They manage and control multicast groups by monitoring and analyzing IGMP or MLD
messages exchanged between the hosts and Layer 3 multicast devices. This effectively
controls the flooding of multicast data in a Layer 2 network.
•PIM snooping and IPv6 PIM snooping:
PIM snooping and IPv6 PIM snooping run on Layer 2 devices. They determine which ports are
interested in multicast data by analyzing the received IPv6 PIM messages. Then, they add the
ports to a multicast forwarding entry. In this way, multicast data can be forwarded to only the
ports that are interested in the data.
•Multicast VLAN and IPv6 multicast VLAN:
In the traditional multicast-on-demand mode, when users in different VLANs on a Layer 2
device need multicast information, the upstream Layer 3 device must forward a separate copy
of the multicast data to each VLAN of the Layer 2 device. When the multicast VLAN or IPv6
multicast VLAN feature is enabled on the Layer 2 device, the Layer 3 multicast device sends
10
only one copy of multicast to the multicast VLAN or IPv6 multicast VLAN on the Layer 2 device.
This approach avoids wasting network bandwidth and placing an extra burden on the Layer 3
device.
Multicast packet forwarding mechanism
In a multicast model, receiver hosts of a multicast group are usually located at different positions of
the network. They are identified by the same multicast group address. To deliver multicast packets to
these receivers, a multicast source encapsulates the multicast data in an IP packet with the multicast
group address as the destination address. Multicast routers on the forwarding paths usually need to
forward multicast packets that an incoming interface receives through multiple outgoing interfaces.
Compared with a unicast model, a multicast model is more complex in the following aspects:
•To ensure multicast packet transmission in the network, different routing tables are used to
guide multicast forwarding. These routing tables include unicast routing tables and multicast
routing tables (for example, the MBGP routing table) specially provided for multicast.
•To process the same multicast information from different peers received on different interfaces,
the multicast device performs a reverse path forwarding (RPF) check on each multicast packet.
The result of the RPF check determines whether the packet is forwarded or discarded. The RPF
check mechanism is the basis for most multicast routing protocols to implement multicast
forwarding.
For more information about the RPF mechanism, see "Configuring multicast routing and forwarding"
and "Configuring IPv6 multicast routing and forwarding."
Multicast support for VPNs
Multicast support for VPNs refers to multicast applied in virtual private networks (VPNs).
Introduction to VPN instances
VPNs must be isolated from one another and from the public network. As shown in Figure 10, VPN A
and VPN B separately access the public network through PE devices.
11
Figure 10 VPN networking diagram
VPN A
CE a2
CE b3
VPN BVPN B
CE a3
PE 3
VPN A
CE b1
CE a1
VPN A
CE b2
PE 1
PE 2
P
Public network
•The provider (P) device belongs to the public network. The customer edge (CE) devices belong
to their respective VPNs. Each CE device serves its own VPN and maintains only one set of
forwarding mechanisms.
•The provider edge (PE) devices connect to the public network and the VPNs. Each PE device
must strictly distinguish the information for different networks, and maintain a separate
forwarding mechanism for each network. On a PE device, a set of software and hardware that
serve the same network forms an instance. Multiple instances can exist on the same PE device,
and an instance can reside on different PE devices. On a PE device, the instance for the public
network is called the public network instance, and those for VPNs are called VPN instances.
Multicast application in VPNs
A PE device that supports multicast for VPNs does the following operations:
•Maintains an independent set of multicast forwarding mechanisms for each VPN, including the
multicast protocols, PIM neighbor information, and multicast routing table. In a VPN, the device
forwards multicast data based on the forwarding table or routing table for that VPN.
• Implements the isolation between different VPNs.
• Implements information exchange and data conversion between the public network and VPN
instances.
Multicast VPN implements multicast on MPLS L3VPN networks. As shown in Figure 10, when a
multicast source in VPN A sends a multicast stream to a multicast group, only the receivers that
belong to both the multicast group and VPN A can receive the multicast stream. The multicast data is
multicast both in VPN A and on the public network.
12
Configuring IGMP snooping
This chapter describes IGMP snooping, how to configure IGMP snooping, configuration examples,
troubleshooting methods, and an appendix about processing multicast protocol messages.
Overview
IGMP snooping is a multicast constraining mechanism that runs on Layer 2 devices to manage and
control multicast groups.
By analyzing received IGMP messages, an IGMP snooping-enabled Layer 2 device establishes
mappings between ports and multicast MAC addresses, and forwards multicast data based on these
mappings.
As shown in Figure 11, without IGMP
to all devices at Layer 2. With IGMP snooping enabled, the Layer 2 switch forwards multicast
packets destined for known multicast groups are multicast to only the receivers that require the
multicast data at Layer 2. This feature improves bandwidth efficiency, enhances multicast security,
and helps per-host accounting for multicast users.
Figure 11 Before and after IGMP snooping is enabled on the Layer 2 device
snooping enabled, the Layer 2 switch floods multicast packets
IGMP snooping basic concepts
This section describes the basic concepts involved in IGMP snooping.
IGMP snooping related ports
As shown in Figure 12, Router A connects to the multicast source, IGMP snooping runs on Switch A
and Switch B, and Host A and Host C are receiver hosts as members of a multicast group.
13
Figure 12 IGMP snooping related ports
The following describes the ports involved in IGMP snooping:
routers (DRs) and IGMP queriers. In Figure 12, Gig
abitEthernet 1/0/1 of Switch A and
GigabitEthernet 1/0/1 of Switch B are router ports. The switch registers all its router ports in its
router port list.
Do not confuse the "router port" in IGMP snooping with the "routed interface" commonly known
as the "Layer 3 interface." The router port in IGMP snooping is the Layer 2 interface.
• Member port—Multicast receiver-side port. In Figure 12, GigabitEthern
et 1/0/2 and
GigabitEthernet 1/0/3 of Switch A and GigabitEthernet 1/0/2 of Switch B are member ports. The
switch registers all its member ports in its IGMP snooping forwarding table.
Unless otherwise specified, router ports and member ports in this document include both static and
dynamic router ports and member ports.
NOTE:
An IGMP snooping-enabled switch deems that all its ports that receive IGMP general queries with
the source IP address other than 0.0.0.0 or that receive PIM hello messages are dynamic router
ports. For more information about PIM hello messages, see "Configuring PIM."
Aging timers for dynamic ports in IGMP snooping and related messages and actions
Timer Description
When a port receives an
expected message, the
Dynamic router port
aging timer
Dynamic member port
aging timer
switch starts an aging
timer for the port. When
the timer expires, the
dynamic router port ages
out.
When a port dynamically
joins a multicast group,
the switch starts an
aging timer for the port.
When the timer expires,
the dynamic member
Expected message
before expiration
IGMP general query of
which the source
address is not 0.0.0.0 or
PIM hello.
IGMP membership
report.
Action after
expiration
The switch removes this
port from its router port
list.
The switch removes this
port from the IGMP
snooping forwarding
table.
14
Timer Description
port ages out.
NOTE:
In IGMP snooping, only dynamic ports age out. Static ports never age out.
How IGMP snooping operates
An IGMP snooping-enabled switch performs different actions when it receives different IGMP
messages.
In this section, the involved ports are dynamic ports. For information about how to configure and
remove static ports, see "Configuring static ports."
When receiving a general query
To check for the existence of multicast group members, the IGMP querier periodically sends IGMP
general queries to all hosts and routers on the local subnet. All these hosts and routers are
indentified by the multicast address 224.0.0.1.
After receiving an IGMP general query, the switch forwards it to all ports in the VLAN, except the port
that received the query. The switch also performs one of the following actions:
•If the receiving port is a dynamic router port in the router port list, restarts the aging timer for the
port.
•If the receiving port is not in the router port list, adds it into the router port list as a dynamic
router port. It also starts an aging timer for the port.
Expected message
before expiration
Action after
expiration
When receiving a membership report
A host sends an IGMP report to the IGMP querier for the following purposes:
• If the host has been a member of a multicast group, responds to the query with an IGMP report.
• Applies for joining a multicast group.
After receiving an IGMP report, the switch forwards it through all router ports in the VLAN. it also
resolves the address of the reported multicast group, and looks up the multicast forwarding table for
a matching entry:
•If no match is found, the Layer 2 device creates a forwarding entry for the group with the
receiving port as an outing interface. It also marks the receiving port as a dynamic member port
and starts an aging timer for the port.
•If a match is found but the receiving port is not in the forwarding entry, the Layer 2 device adds
the port as an outgoing interface to the entry. It also marks the port as a dynamic member port
and starts an aging timer for the port.
•If a match is found and the receiving port is in the forwarding entry, the Layer 2 device restarts
the aging timer for the port.
A switch does not forward an IGMP report through a non-router port because of IGMP report
suppression mechanism. Assuming the switch forwards a report message through a member port,
all attached member receivers will receive the report and suppress their own reports. This makes the
switch unable to know whether the reported multicast group still has active members attached to that
port. For more information about the IGMP report suppression mechanism, see "Configuring IGMP."
When receiving a leave message
An IGMPv1 host does not send any leave messages when it leaves a multicast group. Therefore, the
Layer 2 device cannot immediately update the status of the port that connects to the receiver host. In
this case, when the aging timer for the multicast group on the port expires, the Layer 2 device
15
removes the port from the associated forwarding entry. For a static member port, this mechanism
does not take effect.
When an IGMPv2 or IGMPv3 host leaves a multicast group, the host sends an IGMP leave message
to the multicast router.
When the switch receives an IGMP leave message on a dynamic member port, the switch first
examines whether a forwarding entry matches the group address in the message:.
• If no match is found. the switch directly discards the IGMP leave message.
• If a match is found but the receiving port is not in the forwarding entry, the switch directly
discards the IGMP leave message.
•If a match is found and the receiving port is in the forwarding entry, the switch forwards the
leave message to all router ports in the VLAN. Without knowing whether any other attached
hosts are still listening to that group, the switch does not immediately remove the port from the
forwarding entry. Instead, it restarts the aging timer for the port.
After receiving the IGMP leave message, the IGMP querier resolves the multicast group address in
the message. Then, it sends an IGMP group-specific query to the multicast group through the port
that received the leave message.
After receiving the IGMP group-specific query, the switch forwards the query through all its router
ports in the VLAN and all member ports of the multicast group. Then, the switch waits for the
responding IGMP reports from the directly connected hosts to check for the existence of members
for the multicast group. For the port that receives the leave message (assuming that it is a dynamic
member port), the Layer 2 device also performs one of the following actions:
•If the port receives an IGMP report before the aging timer expires, the switch restarts the aging
timer for the port.
•If the port does not receive an IGMP report when the aging timer expires, the switch removes
the port from the forwarding entry for the multicast group.
IGMP snooping proxying
You can configure the IGMP snooping proxying function on an edge device to reduce the number of
IGMP reports and leave messages sent to its upstream device. The device configured with IGMP
snooping proxying is called an IGMP snooping proxy. It is a host from the perspective of its upstream
device.
NOTE:
Even though an IGMP snooping proxy is a host from the perspective of its upstream device, the
IGMP membership report suppression mechanism for hosts does not affect it. For more information
about the IGMP report suppression mechanism for hosts, see "Configuring IGMP."
16
Figure 13 Network diagram
IP network
Proxy & Querier
Switch A
Host A
Receiver
Host B
IGMP Querier
Router A
Query from Router A
Report from Switch A
Query from Switch A
Report from Host
Host C
Receiver
As shown in Figure 13, Switch A works as an IGMP snooping proxy. As a host from the perspective of
the querier Router A, Switch A represents its attached hosts to send membership reports and leave
messages to Router A. Tab le 6 lists th
e IGMP messages and their processing on an IGMP snooping
proxy.
Table 6 IGMP message processing on an IGMP snooping proxy
IGMP messageActions
When receiving an IGMP general query, the proxy forwards it to all ports except the port
General query
that receive the query. In addition, the proxy generates a report according to the group
membership that it maintains and sends the report out of all router ports.
Group-specific
query
Report
Leave
In response to the IGMP group-specific query for a certain multicast group, the proxy
sends the report to the group out of all router ports if the forwarding entry for the group
still contains a member port.
After receiving a report for a multicast group, the proxy looks up the multicast
forwarding table for a matching forwarding entry.
•If a match is found and the matching entry contains the receiving port as a dynamic
member port, the proxy restarts the aging timer for the port.
•If a match is found but the matching entry does not contain the receiving port, the
proxy adds the port to the forwarding entry. It also marks the port as a dynamic
member port and starts an aging timer for the port.
•If no match is found, the proxy creates a forwarding entry for the multicast group
with the receiving port as an outgoing interface. It also marks the port as a dynamic
member port and starts an aging timer for the port.
In response to an IGMP leave message for a multicast group, the proxy sends a
group-specific query out of the receiving port. After making sure that no member port is
contained in the forwarding entry for the multicast group, the proxy sends a leave
message to the group out of all router ports.
17
Protocols and standards
RFC 4541, Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
IGMP snooping configuration task list
For the configuration tasks in this section, the following rules apply:
•The configurations made in IGMP-snooping view are effective for all VLANs. The configuration
made in VLAN view are effective for only the current VLAN. For a given VLAN, a configuration
made in IGMP-snooping view is effective only if you do not make the same configuration in
VLAN view.
•The configurations made in IGMP-snooping view are effective for all ports. The configurations
made in Layer 2 Ethernet interface view or Layer 2 aggregate interface view are effective for
only the current port. The configurations made in port group view are effective for all ports in
only the current port group. For a given port, a configuration made in IGMP-snooping view is
effective only if you do not make the same configuration in Layer 2 Ethernet interface view,
Layer 2 aggregate interface view, or port group view.
•The IGMP snooping configurations made on Layer 2 aggregate interfaces do not interfere with
the configurations made on member ports. In addition, the configurations made on Layer 2
aggregate interfaces do not take part in aggregation calculations. The configurations made on a
member port of the aggregate group will take effect after the port leaves the aggregate group.
Task Remarks
uired.
Optional.
Optional.
Optional.
Configuring basic IGMP
snooping functions
Configuring IGMP snooping
port functions
Configuring an IGMP snooping
querier
Configuring IGMP snooping
proxying
Enabling IGMP snooping Req
Specifying the version of IGMP snooping Optional.
Setting the maximum number of IGMP snooping
forwarding entries
Configuring static multicast MAC address entries Optional.
Setting aging timers for dynamic ports Optional.
Configuring static ports Optional.
Configuring a port as a simulated member host Optional.