This document describes the software features for the HP A Series products and guides you through the
software configuration procedures. These configuration guides also provide configuration examples to
help you apply software features to different network scenarios.
This documentation is intended for network planners, field technical support and servicing engineers,
and network administrators working with the HP A Series products.
Part number: 5998-1712
Software version: Release 2208
Document version: 5W100-20110530
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.
Introduction to multicast ···················································································································································· 1
Comparison of information transmission techniques ···························································································· 1
Features of multicast ················································································································································· 3
Common notations in multicast ······························································································································· 4
Advantages and applications of multicast ············································································································· 4
Multicast models ································································································································································ 5
Multicast architecture ························································································································································ 5
Introduction to the multi-instance concept ··········································································································· 12
Multi-instance application in multicast ················································································································ 12
Principle of IGMP snooping ································································································································· 14
Basic concepts in IGMP snooping ······················································································································· 15
How IGMP snooping works ································································································································· 16
Disabling a port from becoming a dynamic router port ··················································································· 26
Configuring IGMP snooping querier ··························································································································· 26
Configuring a source IP address for the IGMP messages sent by the proxy ·················································· 29
Configuring an IGMP snooping policy ························································································································ 30
Configuring a multicast group filter ····················································································································· 30
Configuring multicast source port filtering ·········································································································· 31
Configuring the function of dropping unknown multicast data ········································································ 31
Configuring the maximum number of multicast groups that a port can join··················································· 32
iii
Configuring multicast group replacement ··········································································································· 33
Configuring 802.1p precedence for IGMP messages ······················································································ 34
Configuring a multicast user control policy ········································································································ 35
Displaying and maintaining IGMP snooping ·············································································································· 36
IGMP snooping configuration examples ····················································································································· 36
Group policy and simulated joining configuration example ············································································ 36
Static port configuration example ······················································································································· 39
IGMP snooping querier configuration example ································································································· 42
IGMP snooping proxying configuration example ······························································································ 44
Multicast source and user control policy configuration example ····································································· 47
Troubleshooting IGMP snooping configuration ·········································································································· 52
Layer 2 multicast forwarding cannot function ···································································································· 52
Configured multicast group policy fails to take effect ······················································································· 53
Appendix (available only on the A5500 EI) ··············································································································· 53
Processing of multicast protocol messages ········································································································· 53
Configuring user port attributes ··························································································································· 58
Multicast data fails to reach receivers ················································································································ 83
IGMP configuration (available only on the A5500 EI) ··························································································· 84
Introduction to IGMPv1 ········································································································································· 84
Enhancements in IGMPv2 ···································································································································· 86
Enhancements in IGMPv3 ···································································································································· 86
Configuring a multicast group filter ····················································································································· 93
Configuring the maximum number of multicast groups that an interface can join ········································ 94
Adjusting IGMP performance ······································································································································· 94
Configuring an RP ··············································································································································· 133
Configuring a BSR ··············································································································································· 135
Configuring an RP ··············································································································································· 145
Configuring a BSR ··············································································································································· 147
Configuring the SSM group range ···················································································································· 155
Configuring PIM common features ····························································································································· 155
PIM common feature configuration task list ······································································································ 155
Configuring a multicast data filter ····················································································································· 156
Configuring a hello message filter ···················································································································· 157
PIM-DM configuration example ························································································································· 162
PIM-SM non-scoped zone configuration example ··························································································· 166
PIM-SM admin-scope zone configuration example ························································································· 171
BIDIR-PIM configuration example ······················································································································ 177
PIM-SSM configuration example ······················································································································· 182
Troubleshooting PIM configuration ···························································································································· 185
Failure of building a multicast distribution tree correctly ················································································ 185
Multicast data abnormally terminated on an intermediate router ·································································· 186
RPs unable to join SPT in PIM-SM ······················································································································ 187
RPT establishment failure or source registration failure in PIM-SM ································································ 187
MSDP configuration (available only on the A5500 EI) ························································································ 189
Introduction to MSDP ··················································································································································· 189
How MSDP works ··············································································································································· 189
Configuring an MSDP mesh group ··················································································································· 198
Configuring MSDP peer connection control ····································································································· 198
Configuring SA messages related parameters ········································································································· 199
Anycast RP configuration ···································································································································· 211
SA message filtering configuration ··················································································································· 215
Troubleshooting MSDP ················································································································································ 218
MSDP peers stay in down state ························································································································· 218
No SA entries in the switch’s SA cache ············································································································ 219
Inter-RP communication faults in Anycast RP application ················································································ 219
MBGP configuration (available only on the A5500 EI) ······················································································· 220
Configuring the default local preference ·········································································································· 227
Configuring the MED attribute ··························································································································· 227
Configuring the Next Hop attribute ··················································································································· 228
Configuring the AS-PATH attribute ···················································································································· 228
Tuning and optimizing MBGP networks ···················································································································· 229
Enabling the MBGP ORF capability ·················································································································· 230
Configuring the maximum number of MBGP routes for load balancing ······················································· 231
Configuring a large scale MBGP network ················································································································ 232
Configuring IPv4 MBGP peer groups ··············································································································· 232
Configuring MBGP community ·························································································································· 232
Configuring an MBGP route reflector ··············································································································· 233
Displaying and maintaining MBGP ··························································································································· 234
Clearing MBGP information ······························································································································· 235
vii
MBGP configuration example ···································································································································· 236
Introduction to MLD snooping ···························································································································· 240
Basic concepts in MLD snooping ······················································································································· 241
How MLD snooping works ································································································································· 242
Disabling a port from becoming a dynamic router port ················································································· 251
Configuring MLD snooping querier ··························································································································· 252
Configuring a source IPv6 address for the MLD messages sent by the proxy ·············································· 255
Configuring an MLD snooping policy ························································································································ 255
Configuring an IPv6 multicast group filter ········································································································ 255
Configuring IPv6 multicast source port filtering ······························································································· 256
Configuring the function of dropping unknown IPv6 multicast data ······························································ 257
Configuring the maximum number of multicast groups that a port can join················································· 258
Configuring IPv6 multicast group replacement ································································································ 258
Configuring 802.1p precedence for MLD messages ······················································································ 259
Configuring an IPv6 multicast user control policy ···························································································· 260
Displaying and maintaining MLD snooping ·············································································································· 261
MLD snooping configuration examples ····················································································································· 262
IPv6 group policy and simulated joining configuration example ·································································· 262
Static port configuration example ····················································································································· 264
MLD snooping querier configuration example ································································································· 268
MLD snooping proxying configuration example ······························································································ 269
IPv6 multicast source and user control policy configuration example ··························································· 272
Troubleshooting MLD snooping ·································································································································· 277
Layer 2 multicast forwarding cannot function ·································································································· 277
Configured IPv6 multicast group policy fails to take effect ············································································· 278
Appendix (available only on the A5500 EI) ············································································································· 278
Processing of IPv6 multicast protocol messages······························································································· 278
Configuring user port attributes ························································································································· 283
How MLDv1 works ·············································································································································· 300
How MLDv2 works ·············································································································································· 302
Configuring the MLD version ····························································································································· 309
Configuring an ipv6 multicast group filter ········································································································ 310
Configuring the maximum number of IPv6 multicast groups that an interface can join ······························ 311
Adjusting MLD performance ······································································································································· 311
Configuring an RP ··············································································································································· 349
Configuring a BSR ··············································································································································· 351
Configuring an RP ··············································································································································· 359
Configuring a BSR ··············································································································································· 362
Configuring the IPv6 SSM group range ··········································································································· 368
Configuring IPv6 PIM common features ···················································································································· 368
IPv6 PIM common feature configuration task list ····························································································· 369
Configuring an IPv6 multicast data filter ·········································································································· 369
Configuring a hello message filter ···················································································································· 370
Failure to build a multicast distribution tree correctly ······················································································ 403
IPv6 multicast data abnormally terminated on an intermediate router ·························································· 404
RPs unable to join SPT in IPv6 PIM-SM ············································································································· 404
RPT establishment failure or source registration failure in IPv6 PIM-SM ························································ 405
IPv6 MBGP configuration (available only on the A5500 EI) ··············································································· 406
Configuring an IPv6 MBGP peer ······················································································································· 407
Configuring a preferred value for routes from a peer/peer group ······························································· 408
Controlling route distribution and reception ············································································································· 408
Injecting a local IPv6 MBGP route ····················································································································· 408
Configuring the default local preference ·········································································································· 412
Configuring the MED attribute ··························································································································· 413
Configuring the NEXT_HOP attribute ················································································································ 413
Configuring the AS_PATH attribute ··················································································································· 414
Tuning and optimizing IPv6 MBGP networks············································································································ 414
Enabling the IPv6 MBGP ORF capability ········································································································· 415
Configuring the maximum number of equal-cost routes for load-balancing ················································· 417
Configuring a large scale IPv6 MBGP network ········································································································ 417
Clearing IPv6 MBGP information ······················································································································ 421
IPv6 MBGP configuration example ···························································································································· 421
Support and other resources ·································································································································· 424
Contacting HP ······························································································································································ 424
Subscription service ············································································································································ 424
Related information ······················································································································································ 424
Index ········································································································································································ 427
xii
Multicast overview
NOTE:
This document focuses on the IP multicast technology and device operations. Unless otherwise stated,
the term
multicast
Introduction to multicast
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, realtime video conferencing, and
other bandwidth-critical and time-critical information services.
Comparison of information transmission techniques
in this document refers to IP multicast.
Unicast
In unicast transmission, the information source must send a separate copy of information to each host
that needs the information.
Figure 1Unicast 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.
1
Broadcast
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 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 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 information is replicated
only on nodes where the trees branch.
2
Figure 3 Multicast transmission
The multicast source sends only one copy of the information to a multicast group. In Figure 3, 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 remarkably add to 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.
Features of multicast
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
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 An analogy between TV 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 via 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)—Indicates a 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)—Indicates a 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.
NOTE:
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.
For more information about the concepts RPT and SPT, see the chapters “PIM configuration”
PIM configuration.”
Advantages and applications of multicast
Advantages of multicast
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.
Applications of multicast
The multicast technique has the following applications:
• Multimedia and streaming applications, such as web TV, web radio, and realtime video/audio
conferencing
4
and “IPv6
• Communication for training and cooperative operations, such as distance learning and
telemedicine
• Data warehouse and financial applications, such as stock quotes
• Any other point-to-multipoint applications 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).
ASM model
In the ASM model, any sender can send information to a multicast group as a multicast source, and
numbers of receivers can join a multicast group (identified by a group address) and can obtain multicast
information addressed to that multicast group. In this model, receivers do not determine 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. To a receiver, not all
multicast sources are valid: 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 questions:
• 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.
5
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.
Multicast addresses
Network-layer multicast addresses—namely, multicast IP addresses—enable 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
1. IPv4 multicast addresses
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
224.0.0.0 to 224.0.0.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 lists common permanent group addresses. A packet
destined for an address in this block will not be 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
224.0.1.0 to 238.255.255.255
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.
NOTE:
The membership of a group is dynamic. Hosts can join or leave multicast groups at any time.
“Glop” is a mechanism for assigning multicast addresses between different autonomous systems
(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
The following describes the fields of an IPv6 multicast address:
• 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.
Figure 5 Format of the Flags field
Table 4 Description on the bits of the Flags field
Bit Descri
0 Reserved, set to 0
tion
• When set to 0, it indicates that this address is an IPv6 multicast address without an
R
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.
7
Bit Description
g
• When set to 0, it indicates that this address is an IPv6 multicast address not based on
P
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 address permanently-
T
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 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—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
When a unicast IP packet is transmitted over Ethernet, the destination MAC address is the MAC address
of the receiver. When a multicast packet is transmitted over Ethernet, the destination address is a
multicast MAC address because the packet is directed to a group formed by a number of receivers,
rather than to one specific receiver.
1. 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 least-significant 23 bits are the least-significant 23 bits of a multicast IPv4 address.
8
Figure 6 IPv4-to-MAC address mapping
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.
2. IPv6 multicast MAC addresses
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
Multicast protocols
NOTE:
Generally,
protocols are Layer 3 multicast protocols, which include IGMP, MLD, PIM, IPv6 PIM, MSDP, MBGP,
and IPv6 MBGP.
multicast protocols are Layer 2 multicast protocols, which include IGMP snooping, MLD snooping,
multicast VLAN, and IPv6 multicast VLAN.
IGMP snooping, IGMP, multicast VLAN, PIM, MSDP, and MBGP are for IPv4. MLD snooping, MLD,
IPv6 multicast VLAN, IPv6 PIM, and IPv6 MBGP are for IPv6.
Layer 3 multicast
Layer 2 multicast refers to
refers to IP multicast working at the network layer. The related multicast
IP multicast working at the data link layer. The related
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 related
chapters.
9
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
1. Multicast group management protocols
Typically, the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery Protocol (MLD)
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.
2. 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, namely, a multicast distribution tree.
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 includes the dense mode—often called “PIM-DM”, and
sparse mode—often called “PIM-SM.”
• An inter-domain multicast routing protocol delivers multicast information between two ASs. Mature
solutions include Multicast Source Discovery Protocol (MSDP) and Multicast Border Gateway
Protocol (MBGP). MSDP propagates multicast source information among different ASs, and 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 positions of the multicast sources, 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, multicast VLAN, and IPv6 multicast
VLAN.
10
Figure 9 Positions of Layer 2 multicast protocols
Source
ReceiverReceiver
IPv4/IPv6 multicast packets
1.IGMP snooping and MLD snooping
Multicast VLAN
/IPv6 Multicast VLAN
IGMP Snooping
/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.
2. 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 needs to 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 only one copy of the multicast data to
the multicast VLAN or IPv6 multicast VLAN on the Layer 2 device. This approach avoids waste of
network bandwidth and extra burden on the Layer 3 device.
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 received on one incoming interface 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, 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.
NOTE:
For more information about the RPF mechanism, see the chapters “Multicast routing and forwarding
configuration” and “IPv6 multicast routing and forwarding configuration.”
11
Multi-instance multicast
Multi-instance multicast refers to multicast in virtual private networks (VPNs).
Introduction to the multi-instance concept
VPN networks must be isolated from one another and from the public network.
Figure 10 Networking diagram for VPN
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
As shown in Figure 10, VPN A and VPN B separately access the public network through PE devices. The
devices in the network are as follows:
• The P device belongs to the public network. The CE devices belong to their respective VPNs. Each
CE device serves its own network and maintains only one set of forwarding mechanism.
• The PE devices connect to the public network and the VPN networks at the same time. Each PE
device must strictly distinguish the information for different networks, and must maintain a separate
forwarding mechanism for each network. On a PE device, a set of software and hardware that
serves the same network forms an instance. Multiple instances exist on a PE device at the same
time, and an instance resides on different PE devices.
Multi-instance application in multicast
With multi-instance multicast enabled, a PE can do the following operations:
• Maintain a set of independent multicast forwarding mechanisms for each instance, including
various multicast protocols, a list of PIM neighbors, and a multicast routing table per instance. Each
instance searches its own forwarding table or routing table to forward multicast data.
• Guarantee the isolation between different VPN instances.
12
• Implement information exchange and data conversion between the public network and VPN
instances.
NOTE:
Only one set of unified multicast service runs on a non-PE device. It is called a “public network.”
The configuration made in VPN instance view takes effect only on the VPN instance interface. An
interface that does not belong to any VPN instance is called a “public network interface.”
13
IGMP snooping configuration
IGMP snooping overview
IGMP snooping is a multicast constraining mechanism that runs on Layer 2 devices to manage and
control multicast groups.
Principle of IGMP snooping
By analyzing received IGMP messages, a Layer 2 switch that runs IGMP snooping establishes mappings
between ports and multicast MAC addresses, and forwards multicast data based on these mappings.
When IGMP snooping is not running on the switch, multicast packets are flooded to all devices at Layer
2. When IGMP snooping runs on the switch, multicast packets for known multicast groups are multicast
to the receivers, rather than being broadcast to all hosts, at Layer 2.
Figure 11 Before and after IGMP snooping is enabled on the Layer 2 device
Source
Multicast packet transmission
without IGMP Snooping
Host A
Receiver
Host B
Multicast packets
Multicast router
Layer 2 switch
Host C
Receiver
Multicast packet transmission
when IGMP Snooping runs
Source
Host A
Receiver
Host B
Multicast router
Layer 2 switch
Host C
Receiver
IGMP snooping forwards multicast data to only the receivers that require the data at Layer 2. It has the
following advantages:
• Facilitating the implementation of per-host accounting
14
Basic concepts in IGMP snooping
IGMP snooping related ports
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—also called “multicast group members.”
Figure 12IGMP snooping related ports
Router ASwitch A
GE1/0/1GE1/0/2
GE1/0/3
GE1/0/1
Source
Switch B
Router port
Member port
Multicast packets
Receiver
GE1/0/2
Host C
Host D
Receiver
Host A
Host B
IGMP snooping involves the following ports:
• Router port—A router port is a port on a Layer 2 switch that leads toward a Layer 3 multicast
device—DR or IGMP querier. In Figure 12, G
igabitEthernet 1/0/1 of Switch A and
GigabitEthernet 1/0/1 of Switch B are router ports. Each switch registers all its local router ports in
its router port list.
• Member port—A member port is a port on a Layer 2 switch that leads toward multicast group
members. 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. Each switch registers all the member ports
on the local device in its IGMP snooping forwarding table.
NOTE:
Whenever mentioned in this document, a router port is a port on the switch that leads the switch to a
Layer 3 multicast device, rather than a port on a router.
Unless otherwise specified, router/member ports mentioned in this document include static and
dynamic ports.
An IGMP-snooping-enabled switch deems that all its ports on which IGMP general queries with the
source IP address other than 0.0.0.0 or PIM hello messages are received are dynamic router ports.
For more information about PIM hello messages, see the chapter “PIM configuration.”
15
piry
g
Aging timers for dynamic ports in IGMP snooping and related messages and actions
Timer Description
For each dynamic router
Dynamic router port
aging timer
Dynamic member port
aging timer
port, the switch sets a
timer initialized to the
dynamic router port
aging time.
When a port
dynamically joins a
multicast group, the
switch sets a timer for
the port, which is
initialized to the
dynamic member port
aging time.
NOTE:
The port aging mechanism of IGMP snooping works only for dynamic ports; a static port will never a
out.
How IGMP snooping works
Message before
ex
IGMP general query of
which the source
address is not 0.0.0.0
or PIM hello
IGMP membership
report
Action after expiry
The switch removes this
port from its router port
list.
The switch removes this
port from the IGMP
snooping forwarding
table.
e
A switch that runs IGMP snooping performs different actions when it receives different IGMP messages.
CAUTION:
The description about adding or deleting a port in this section is only for a dynamic port. Static ports
can be added or deleted only through the specific configurations. For more information, see
“Configuring static ports.”
When receiving a general query
The IGMP querier periodically sends IGMP general queries to all hosts and routers—224.0.0.1—on the
local subnet to determine whether active multicast group members exist on the subnet.
After receiving an IGMP general query, the switch forwards it through all ports in the VLAN (except the
port that received the query). The switch also performs the following judgment:
• If the port that received the query is a dynamic router port that exists in its router port list, the switch
resets the aging timer for this dynamic router port.
• If the port is not a dynamic router port that exists in its router port list, the switch adds it into its
router port list and sets an aging timer for this dynamic router port.
When receiving a membership report
A host sends an IGMP report to the IGMP querier in the following circumstances:
• If the host is already a member of a multicast group, the host responds with an IGMP report after
receiving an IGMP query.
• If the host wants to join a multicast group, the host sends an IGMP report to the IGMP querier to
announce that it is interested in the multicast information addressed to that group.
16
A
NOTE:
After receiving an IGMP report, the switch forwards it through all the router ports in the VLAN, resolves
the address of the reported multicast group. The switch also performs the following judgment:
• If no entry in the forwarding table exists for the reported group, the switch creates an entry, adds
the port as a dynamic member port to the outgoing port list, and starts a member port aging timer
for that port.
• If an entry in the forwarding table exists for the reported group but the port is not included in the
outgoing port list for that group, the switch adds the port as a dynamic member port to the
outgoing port list and starts an aging timer for that port.
• If an entry in the forwarding table exists for the reported group and the port is included in the
outgoing port list, which means that this port is already a dynamic member port, the switch resets
the aging timer for that port.
switch does not forward an IGMP report through a non-router port. The reason is that if the switch
forwards a report message through a member port, all the attached hosts that are monitoring the
reported multicast address suppress their own reports after receiving this report according to the IGMP
report suppression mechanism. This prevents the switch from determining whether the reported
multicast group still has active members attached to that port. For more information about the IGMP
report suppression mechanism, see the chapter “IGMP configuration.”
When receiving a leave message
When an IGMPv1 host leaves a multicast group, the host does not send an IGMP leave message, so the
switch cannot determine immediately that the host has left the multicast group. However, as the host
stops sending IGMP reports as soon as it leaves a multicast group, the switch deletes the forwarding
entry for the dynamic member port that corresponds to the host from the forwarding table when its aging
timer expires.
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
determines whether an entry in the forwarding table exists for the group address in the message, and, if
one exists, whether the outgoing port list contains the port.
• If the entry in the forwarding table does not exist or if the outgoing port list does not contain the
port, the switch discards the IGMP leave message instead of forwarding it to any port.
• If the entry in the forwarding table exists and the outgoing port list contains the port, the switch
forwards the leave message to all router ports in the native VLAN. Because the switch cannot
determine whether any other hosts attached to the port are still monitoring that group address, the
switch does not immediately remove the port from the outgoing port list of the entry in the
forwarding table for that group. Instead, it resets the aging timer for the port.
After receiving the IGMP leave message from a host, the IGMP querier resolves the multicast group
address in the message and sends an IGMP group-specific query to that 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 for that multicast group. The switch
also performs the following judgment on the port that received the IGMP leave message:
• If the port (a dynamic member port supposed) receives any IGMP report in response to the group-
specific query before its aging timer expires, it indicates that a host attached to the port is receiving
or expecting to receive multicast data for that multicast group. The switch resets the aging timer of
the port.
17
g
• If the port receives no IGMP report in response to the group-specific query before its aging timer
expires, it indicates that no hosts attached to the port are still monitoring that group address. The
switch removes the port from the outgoing port list of the entry in the forwarding table for that
multicast group when the aging timer expires.
IGMP snooping proxying
The IGMP snooping proxying function on an edge device reduces the number of IGMP reports and
leave messages sent to its upstream device. The device configured with IGMP snooping proxying is
called “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 take effect on it. For more information
about the IGMP report suppression mechanism for hosts, see the chapter “IGMP configuration.”
Figure 13 Network diagram for IGMP snooping proxying
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.
Table 6 IGMP message processing on an IGMP snooping proxy
IGMP messa
General query
Group-specific query
e Actions
When receiving an IGMP general query, the proxy forwards it to all
ports but the receiving port. In addition, the proxy generates a report
according to the group memberships it maintains and sends the report
out all router ports.
In response to the IGMP group-specific query for a certain multicast
group, the proxy sends the report to the group out all router ports if
the forwarding entry for the group still contains a member port.
18
Loading...
+ 406 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.