No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
Multicast overview ···················································································································································· 1
Multicast features ······················································································································································ 3
Common notations in multicast ······························································································································· 4
IGMP support for VPNs ········································································································································ 20
Protocols and standards ······································································································································· 20
IGMP configuration task list ·········································································································································· 20
Configuring basic IGMP functions ······························································································································· 21
Specifying the IGMP version ································································································································ 22
Configuring an interface as a static member interface ····················································································· 22
Configuring a multicast group filter ····················································································································· 23
Setting the maximum number of multicast groups that an interface can join ················································· 23
Adjusting IGMP performance ······································································································································· 24
Relationship among PIM protocols ······················································································································ 55
PIM support for VPNs ············································································································································ 56
Protocols and standards ······································································································································· 56
Configuring PIM-DM ······················································································································································ 56
Configuring an RP ················································································································································· 62
Configuring a BSR ················································································································································· 64
Configuring an RP ················································································································································· 73
Configuring a BSR ················································································································································· 75
Configuring the SSM group range ······················································································································ 81
Configuring common PIM features ······························································································································· 82
Configuration task list ··········································································································································· 82
Configuring a multicast data filter ······················································································································· 83
Configuring a hello message filter ······················································································································ 83
PIM-DM configuration example ··························································································································· 89
PIM-SM non-scoped zone configuration example ····························································································· 92
PIM-SM admin-scoped zone configuration example ························································································· 98
BIDIR-PIM configuration example ······················································································································· 104
PIM-SSM configuration example ························································································································ 108
Troubleshooting PIM ···················································································································································· 111
A multicast distribution tree cannot be built correctly ······················································································ 111
Multicast data abnormally terminated on an intermediate router ·································································· 112
RPs cannot join SPT in PIM-SM ·························································································································· 113
RPT establishment failure or source registration failure in PIM-SM ································································ 114
Configuring multicast routing and forwarding ······································································································ 115
Configuring a multicast routing policy ·············································································································· 122
Configuring a multicast forwarding range ······································································································· 123
Configuring the multicast forwarding table size ······························································································ 123
Tracing a multicast path ····································································································································· 124
Displaying and maintaining multicast routing and forwarding ··············································································· 125
Configuration examples ·············································································································································· 126
Changing an RPF route ······································································································································· 126
Creating an RPF route ········································································································································· 128
Multicast forwarding over GRE tunnels ············································································································· 130
Troubleshooting multicast routing and forwarding ··································································································· 133
Multicast data fails to reach receivers··············································································································· 134
Basic concepts in IGMP snooping ····················································································································· 135
How IGMP snooping works ······························································································································· 137
Specifying the version of IGMP snooping ········································································································ 141
Configuring IGMP snooping port functions ··············································································································· 142
Disabling a port from becoming a dynamic router port ················································································· 145
Configuring IGMP snooping querier ························································································································· 146
Configuring the source IP addresses for the IGMP messages sent by the proxy ·········································· 149
Configuring IGMP snooping policies ························································································································· 149
Configuring a multicast group filter ··················································································································· 149
Configuring multicast source port filtering ········································································································ 150
Enabling dropping unknown multicast data ····································································································· 151
Setting the maximum number of multicast groups that a port can join ························································· 153
Enabling multicast group replacement ·············································································································· 153
Setting the 802.1p precedence for IGMP messages ······················································································ 154
Enabling the IGMP snooping host tracking function ······················································································· 155
Displaying and maintaining IGMP snooping ············································································································ 155
IGMP snooping configuration examples ··················································································································· 156
Group policy and simulated joining configuration example ·········································································· 156
Static port configuration example ····················································································································· 158
IGMP snooping querier configuration example ······························································································· 161
How MSDP works ··············································································································································· 168
MSDP support for VPNs ······································································································································ 173
Protocols and standards ····································································································································· 173
MSDP configuration task list ······································································································································· 174
Configuring basic MSDP functions ····························································································································· 174
Configuring an MSDP mesh group ··················································································································· 176
Configuring MSDP peer connection control ····································································································· 177
Configuring SA message related parameters ··········································································································· 178
Inter-AS multicast configuration by leveraging static RPF peers ····································································· 186
Anycast RP configuration ···································································································································· 191
SA message filtering configuration ···················································································································· 195
Troubleshooting MSDP ················································································································································ 199
MSDP peers stay in down state ························································································································· 199
No SA entries exist in the router's SA cache ··································································································· 199
No SA entries exist in the router's SA cache ··································································································· 200
Configuring the default local preference ·········································································································· 208
Configuring the MED attribute ··························································································································· 209
Configuring the NEXT_HOP attribute ················································································································ 209
Enabling the MBGP ORF capability ·················································································································· 212
Configuring the maximum number of MBGP routes for load balancing ······················································· 213
Configuring a large scale MBGP network ················································································································ 213
Configuring MBGP community ·························································································································· 214
Configuring an MBGP route reflector ··············································································································· 215
Displaying and maintaining MBGP ··························································································································· 216
Protocols and standards ····································································································································· 227
How MD-VPN works ···················································································································································· 227
A share-MDT cannot be established ·················································································································· 266
An MVRF cannot be created ······························································································································ 267
How MLDv1 works ·············································································································································· 268
How MLDv2 works ·············································································································································· 270
Configuring the MLD version ····························································································································· 277
Configuring an IPv6 multicast group filter ········································································································ 278
Setting the maximum number of IPv6 multicast groups that an interface can join ······································· 278
Adjusting MLD performance ······································································································································· 279
Configuring an RP ··············································································································································· 316
Configuring a BSR ··············································································································································· 319
Configuring an RP ··············································································································································· 326
Configuring a BSR ··············································································································································· 328
Configuring the IPv6 SSM group range ··········································································································· 334
Configuring common IPv6 PIM features ···················································································································· 334
Configuration task list ········································································································································· 335
Configuring an IPv6 multicast data filter ··········································································································· 335
Configuring a hello message filter ···················································································································· 336
Configuring IPv6 PIM to work with BFD ············································································································ 340
Displaying and maintaining IPv6 PIM ························································································································ 341
A multicast distribution tree cannot be built correctly ······················································································ 370
IPv6 multicast data is abnormally terminated on an intermediate router ······················································ 371
RPs cannot join the SPT in IPv6 PIM-SM ············································································································ 372
RPT cannot be established or a source cannot register in IPv6 PIM-SM ························································ 372
Configuring IPv6 multicast routing and forwarding ····························································································· 374
Configuring an IPv6 multicast routing policy ··································································································· 377
Configuring an IPv6 multicast forwarding range ····························································································· 378
Configuring the IPv6 multicast forwarding table size ······················································································ 379
Displaying and maintaining IPv6 multicast routing and forwarding ······································································ 380
IPv6 multicast forwarding over GRE tunnel configuration example ········································································ 381
Troubleshooting abnormal termination of IPv6 multicast data ······································································· 384
How MLD snooping works ································································································································· 388
Specifying the version of MLD snooping ·········································································································· 392
Configuring MLD snooping port functions ················································································································· 393
Disabling a port from becoming a dynamic router port ················································································· 396
Configuring MLD snooping querier ··························································································································· 397
Configuring the source IPv6 addresses for the MLD messages sent by the proxy ······································· 399
Configuring an MLD snooping policy ························································································································ 400
Configuring an IPv6 multicast group filter ········································································································ 400
Configuring IPv6 multicast source port filtering ······························································································· 401
Enabling dropping unknown IPv6 multicast data ···························································································· 402
Setting the maximum number of multicast groups that a port can join ························································· 403
Enabling IPv6 multicast group replacement ····································································································· 404
Setting the 802.1p precedence for MLD messages ························································································ 405
Enabling the MLD snooping host tracking function ························································································· 406
Displaying and maintaining MLD snooping ·············································································································· 406
MLD snooping configuration examples ····················································································································· 407
IPv6 group policy and simulated joining configuration example ·································································· 407
Static port configuration example ····················································································································· 409
MLD snooping querier configuration example ································································································· 413
Layer 2 multicast forwarding cannot function ·································································································· 417
Configured IPv6 multicast group policy fails to take effect ············································································· 417
Appendix ······································································································································································ 418
Processing of IPv6 multicast protocol messages ······························································································· 418
Configuring an IPv6 MBGP peer ······················································································································· 420
Configuring a preferred value for routes from a peer or a peer group ························································ 420
Controlling route distribution and reception ············································································································· 421
Injecting a local IPv6 MBGP route ····················································································································· 421
Configuring the default local preference ·········································································································· 425
Configuring the MED attribute ··························································································································· 425
Configuring the NEXT_HOP attribute ················································································································ 426
Enabling the IPv6 MBGP ORF capability ········································································································· 428
Configuring the maximum number of equal-cost routes for load-balancing ················································· 429
Configuring a large scale IPv6 MBGP network ········································································································ 430
Support and other resources ·································································································································· 437
Contacting HP ······························································································································································ 437
Subscription service ············································································································································ 437
Related information ······················································································································································ 437
Index ········································································································································································ 440
x
Multicast overview
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.
By using multicast technology, a network operator can easily provide new value-added services, such as
live webcasting, Web TV, distance learning, telemedicine, Web radio, real-time video conferencing, and
other bandwidth-critical and time-critical information services.
Unless otherwise stated, the term "multicast" in this document refers to IP multicast.
Multicast overview
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
Source
IP network
Packets for Host B
Packets for Host D
Packets for Host E
Host A
Receiver
Host B
Host C
Receiver
Host D
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
1
Broadcast
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.
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—Because multicast traffic flows to the farthest-possible node from the
source before it is replicated and distributed, an increase in the number of hosts does not increase
the load of the source or the usage of network resources.
•Advantages over broadcast—Because multicast data is sent only to the receivers that need it,
multicast uses network bandwidth reasonably and enhances network security. In addition, data
broadcast is confined to the same subnet, but multicast is not.
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, and 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
3
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.
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
The multicast technique has the following advantages:
•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.
The multicast technique can be use for the following applications:
• 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
4
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).
•ASM model—In the ASM model, any sender can send information to a multicast group as a
multicast source, and 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 checks 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. Because
not all multicast sources are valid to receivers, 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.
The main difference between the SSM model and the ASM model is that in the SSM model,
receivers have already determined the locations of the multicast sources by some other means. In
addition, the SSM model uses a multicast address range that is different from that of the ASM/SFM
model, and 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 will provide 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:
1.Addressing mechanism—A multicast source sends information to a group of receivers through a
multicast address.
2.Host registration—Receiver hosts can join and leave multicast groups dynamically. This
mechanism is the basis for management of group memberships.
3.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.
4.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.
5
Multicast addresses
Network-layer multicast addresses (namely, 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.
The membership of a group is dynamic. Hosts can join or leave multicast groups at any time.
IP multicast addresses
• IPv4 multicast addresses:
The IANA assigns 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
224.0.0.0 to 224.0.0.255
224.0.1.0 to 238.255.255.255
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 on. Table 3
ommon permanent group addresses. A packet destined for an
lists c
address in this block will not be forwarded beyond the local subnet
regardless of the 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
239.0.0.0 to 239.255.255.255
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 ST routers.
224.0.0.8 ST hosts.
224.0.0.9 RIPv2 routers.
224.0.0.11 Mobile agents.
6
Address Description
p
224.0.0.12 DHCP server/relay agent.
224.0.0.13 All PIM routers.
224.0.0.14 RSVP encapsulation.
224.0.0.15 All CBT routers.
224.0.0.16 SBM.
224.0.0.17 All SBMs.
224.0.0.18 VRRP.
• IPv6 multicast addresses:
Figure 4 IPv6 multicast format
The following describes the fields of an IPv6 multicast address, as shown in Figure 4:
{0xFF—Contains the most significant eight bits 11111111, which indicates that this address is an
IPv6 multicast address.
{ Flags—Contains four bits, as shown in Figure 5 and described in Table 4.
Figure 5 Flags field format
Table 4 Flags field description
Bit Descri
0 Reserved, set to 0.
tion
• When set to 0, it indicates that this address is an IPv6 multicast
R
address without an embedded RP address.
• 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
P
address not based on a unicast prefix.
• 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 multicast
T
address permanently-assigned by IANA.
• When set to 1, it indicates that this address is a transient, or
dynamically assigned IPv6 multicast address.
7
{Scope—Contains four bits, which indicate the scope of the IPv6 internetwork for which the
g
multicast traffic is intended. Table 5 de
Table 5 Values of the Scope field
Value Meanin
0, F Reserved.
1 Interface-local scope.
2 Link-local scope.
3 Subnet-local scope.
4 Admin-local scope.
5 Site-local scope.
6, 7, 9 through D Unassigned.
8 Organization-local scope.
E Global scope.
{Group ID—Contains 112 bits. It uniquely identifies an IPv6 multicast group in the scope that the
Scope field defines.
Ethernet multicast MAC addresses
scribes the values of the Scope field.
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
means 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 m
ost 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.
8
Figure 7 An example of IPv6-to-MAC address mapping
Multicast protocols
Multicast protocols include the following categories:
• Layer 3 and Layer 2 multicast protocols:
{ Layer 3 multicast refers to IP multicast working 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.
9
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 (namely, a multicast distribution tree) from a data source to multiple
receivers.
In the ASM model, multicast routes include intra-domain routes and inter-domain routes.
{ An intra-domain multicast routing protocol discovers multicast sources and builds multicast
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, and IPv6 PIM
snooping.
10
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, effectively controlling 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, and add the ports to a
multicast forwarding entry to make sure multicast data can be forwarded to only the ports that are
interested in the data.
Multicast packet forwarding mechanism
In a multicast model, a multicast source sends information to the host group identified by the multicast
group address in the destination address field of IP multicast packets. To deliver multicast packets to
receivers located at different positions of the network, multicast routers on the forwarding paths usually
need to forward multicast packets that an incoming interface receives to 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, unicast routing tables or multicast routing
tables (for example, the MBGP routing table) specially provided for multicast must be used as
guidance for multicast forwarding.
• To process the same multicast information from different peers received on different interfaces of the
same device, every multicast packet undergoes a reverse path forwarding (RPF) check on the
incoming interface. The result of the RPF check determines whether the packet will be 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."
11
Multicast support for VPNs
Multicast support for VPNs refers to multicast applied in VPNs.
Multicast support for VPNs is not available in IPv6 networks.
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.
Figure 10 VPN networking diagram
VPN A
CE a2
CE b1
CE a1
VPN A
CE b2
PE 1
PE 2
P
Public network
CE b3
VPN BVPN B
CE a3
PE 3
VPN A
•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.
12
• Implements information exchange and data conversion between the public network and VPN
instances.
As shown in Figure 10, w
hen 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.
13
Configuring IGMP
Overview
As a TCP/IP protocol responsible for IP multicast group member management, the IGMP is used by IP
hosts and adjacent multicast routers to establish and maintain their multicast group memberships.
IGMP versions
• IGMPv1 (documented in RFC 1112 )
• IGMPv2 (documented in RFC 2236)
• IGMPv3 (documented in RFC 3376)
All IGMP versions support the ASM model. In addition to the ASM model, IGMPv3 can directly
implement the SSM model. IGMPv1 and IGMPv2 must work with the IGMP SSM mapping function to
implement the SSM model. For more information about the ASM and SSM models, see "Multicast
overview."
IGMPv1 overview
IGMPv1 manages multicast group memberships based on the query and response mechanism.
All multicast routers on the same subnet can get IGMP membership report messages (often called
"reports") from hosts, but the subnet needs only one router to act as the IGMP querier to send IGMP
query messages (often called "queries"). The querier election mechanism determines which router acts
as the IGMP querier on the subnet.
In IGMPv1, the designated router (DR) elected by the working multicast routing protocol (such as PIM)
serves as the IGMP querier. For more information about DR, see "Configuring PIM."
14
Figure 11 IGMP queries and reports
As shown in Figure 11, assume that Host B and Host C are interested in multicast data addressed to
multicast group G1, and Host A is interested in multicast data addressed to G2. The following process
describes how the hosts join the multicast groups and how the IGMP querier (Router B in the figure)
maintains the multicast group memberships:
1. The hosts send unsolicited IGMP reports to the addresses of the multicast groups that they want to
join, without having to wait for the IGMP queries from the IGMP querier.
2. The IGMP querier periodically multicasts IGMP queries (with the destination address of 224.0.0.1)
to all hosts and routers on the local subnet.
3. After receiving a query message, Host B or Host C (the delay timer of whichever expires first) sends
an IGMP report to the multicast group address of G1, to announce its membership for G1. Assume
that Host B sends the report message. After receiving the report from Host B, Host C (which is on
the same subnet as Host B) suppresses its own report for G1, because the IGMP routers (Router A
and Router B) have already known that at least one host on the local subnet is interested in G1. This
IGMP report suppression mechanism helps reduce traffic on the local subnet.
4. At the same time, because Host A is interested in G2, it sends a report to the multicast group
address of G2.
5. Through the query/report process, the IGMP routers determine that members of G1 and G2 are
attached to the local subnet, and the multicast routing protocol (PIM, for example) that is running
on the routers generates (*, G1) and (*, G2) multicast forwarding entries. These entries will be the
basis for subsequent multicast forwarding, where asterisk represents any multicast source.
6. When the multicast data addressed to G1 or G2 reaches an IGMP router, because the (*, G1) and
(*, G2) multicast forwarding entries exist on the IGMP router, the router forwards the multicast
data to the local subnet, and then the receivers on the subnet receive the data.
IGMPv1 does not specifically define a leave group message (often called a "leave message.") When an
IGMPv1 host is leaving a multicast group, it stops sending reports to the address of the multicast group
that it listened to. If no member exists in a multicast group on the subnet, the IGMP router will not receive
any report addressed to that multicast group. In this case, the router will delete the multicast forwarding
entries for that multicast group after a period of time.
15
IGMPv2 overview
Compared with IGMPv1, IGMPv2 has introduced a querier election mechanism and a leave-group
mechanism.
Querier election mechanism
In IGMPv1, the DR elected by the Layer 3 multicast routing protocol (such as PIM) serves as the querier
among multiple routers on the same subnet.
IGMPv2 introduced an independent querier election mechanism. The querier election process is as
follows:
1. Initially, every IGMPv2 router assumes itself as the querier and sends IGMP general query
messages (often called "general queries") to all hosts and routers on the local subnet. The
destination address is 224.0.0.1.
2. After receiving a general query, every IGMPv2 router compares the source IP address of the query
message with its own interface address. After comparison, the router with the lowest IP address
wins the querier election and all other IGMPv2 routers become non-queriers.
3. All the non-queriers start a timer, known as "other querier present timer". If a router receives an
IGMP query from the querier before the timer expires, it resets this timer. Otherwise, it assumes the
querier to have timed out and initiates a new querier election process.
"Leave group" mechanism
In IGMPv1, when a host leaves a multicast group, it does not send any notification to the multicast router.
The multicast router relies on the host response timeout timer to determine whether a group has members.
This adds to the leave latency.
In IGMPv2, when a host leaves a multicast group, the following steps occur:
1. This host sends a leave message to all routers on the local subnet. The destination address is
224.0.0.2.
2. After receiving the leave message, the querier sends a configurable number of group-specific
queries to the group that the host is leaving. The destination address field and group address field
of the message are both filled with the address of the multicast group that is being queried.
3. One of the remaining members (if any on the subnet) of the group that is being queried should
send a membership report within the maximum response time set in the query messages.
4. If the querier receives a membership report for the group within the maximum response time, it will
maintain the memberships of the group. Otherwise, the querier will assume that no hosts on the
subnet are still interested in multicast traffic to that group and will stop maintaining the
memberships of the group.
IGMPv3 overview
IGMPv3 is based on and is compatible with IGMPv1 and IGMPv2. It provides hosts with enhanced
control capabilities and provides enhancements of query and report messages.
Enhancements in control capability of hosts
IGMPv3 introduced two source filtering modes (Include and Exclude). These modes allow a host to join
a designated multicast group and to choose whether to receive or reject multicast data from a designated
multicast source. When a host joins a multicast group, one of the following occurs:
• If it expects to receive multicast data from specific sources like S1, S2, …, it sends a report with the
Filter-Mode denoted as "Include Sources (S1, S2, …)."
16
• If it expects to reject multicast data from specific sources like S1, S2, …, it sends a report with the
Filter-Mode denoted as "Exclude Sources (S1, S2, …)."
As shown in Figure 12,
the network comprises two multicast sources, Source 1 (S1) and Source 2 (S2),
both of which can send multicast data to multicast group G. Host B is interested in the multicast data that
Source 1 sends to G but not in the data from Source 2.
Figure 12 Flow paths of source-and-group-specific multicast traffic
In IGMPv1 or IGMPv2, Host B cannot select multicast sources when it joins multicast group G. Therefore,
multicast streams from both Source 1 and Source 2 will flow to Host B whether or not it needs them.
When IGMPv3 runs between the hosts and routers, Host B can explicitly express that it needs to receive
the multicast data that Source 1 sends to multicast group G (denoted as (S1, G)), rather than the multicast
data that Source 2 sends to multicast group G (denoted as (S2, G)). Only multicast data from Source 1
is delivered to Host B.
Enhancements in query and report capabilities
1. Query message carrying the source addresses:
IGMPv3 supports not only general queries (feature of IGMPv1) and group-specific queries (feature
of IGMPv2), but also group-and-source-specific queries.
{ A general query does not carry a group address or a source address.
{ A group-specific query carries a group address, but no source address.
{ A group-and-source-specific query carries a group address and one or more source addresses.
2. Reports containing multiple group records:
Unlike an IGMPv1 or IGMPv2 report message, an IGMPv3 report message is destined to
224.0.0.22 and contains one or more group records. Each group record contains a multicast
group address and a multicast source address list.
Group records include the following categories:
{IS_IN—The source filtering mode is Include. The report sender requests the multicast data from
only the sources defined in the specified multicast source list.
{IS_EX—The source filtering mode is Exclude. The report sender requests the multicast data from
any sources but those defined in the specified multicast source list.
{ TO_IN—The filtering mode has changed from Exclude to Include.
{ TO_EX—The filtering mode has changed from Include to Exclude.
17
{ALLOW—The Source Address fields in this group record contain a list of the additional sources
that the system wants to obtain data from, for packets sent to the specified multicast address. If
the change was to an Include source list, these sources are the addresses that were added to the
list. If the change was to an Exclude source list, these sources are the addresses that were
deleted from the list.
{BLOCK—The Source Address fields in this group record contain a list of the sources that the
system no longer wants to obtain data from, for packets sent to the specified multicast address.
If the change was to an Include source list, these sources are the addresses that were deleted
from the list. If the change was to an Exclude source list, these sources are the addresses that
were added to the list.
IGMP SSM mapping
The IGMP SSM mapping feature enables you to configure static IGMP SSM mappings on the last-hop
router to provide SSM support for receiver hosts that are running IGMPv1 or IGMPv2. The SSM model
assumes that the last-hop router has identified the desired multicast sources when receivers join multicast
groups.
• When a host that is running IGMPv3 joins a multicast group, it can explicitly specify one or more
multicast sources in its IGMPv3 report.
• A host that is running IGM Pv1 or I GMPv2, however, cannot specify multicast source addresses in its
report. In this case, you must configure the IGMP SSM mapping feature to translate the (*, G)
information in the IGMPv1 or IGMPv2 report into (G, INCLUDE, (S1, S2...)) information.
Figure 13 IGMP SSM mapping
As shown in Figure 13, on an SSM network, Host A, Host B, and Host C run IGMPv1, IGMPv2, and
IGMPv3, respectively. To provide SSM service for all the hosts if IGMPv3 is not available on Host A and
Host B, you must configure the IGMP SSM mapping feature on Router A.
With the IGMP SSM mapping feat ure configu red, when Router A rec eives an IGMP v1 or IGM Pv2 repor t,
it checks the multicast group address G carried in the message and does the following:
• If G is not in the SSM group range, Router A cannot provide the SSM service but can provide the
ASM service.
• If G is in the SSM group range but no IGMP SSM mappings that correspond to the multicast group
G have bee n co nfig ured on Ro uter A, Ro uter A cannot provide SSM service and drops the message.
18
Loading...
+ 419 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.