第9章 广播和本地组播(IGMP和MLD)
9.1 引言
第2章中我们提到有4种IP地址：单播(unicast)、任播(anycast)、组播(multicast)
和广播(broadcast）。IPv4可以使用所有这些地址，而IPv6可以使用除了最后一种形式的所有其他形式的地址。在本章中，我们讨论广播和组播更多的细节，包括链路层地址如何有效地用于从一台计算机向其他几台计算机发送组播或广播流量。我们也查看互联网组管理协议(IGMP) [RFC3376]和IPv6组播侦听发现(MLD) [RFC3810]协议,它们用来通知IPv4和IPv6组播路由器子网中哪些组播地址在使用中。本章(或本书)中,我们没有涉及的一个主题是在诸如全球互联网的广域网中，组播路由是如何实现的。目前，组播在企业和本地网络中的使用超过在广域网中的使用。尽管我们在本章中讨论的这些协议是为了完全理解广域组播，但是广域路由协议比较复杂，而且会使解释本地局域网的情况不必要地复杂化。对探索这些问题感兴趣的读者可以参考[EGW02]。
广播和组播为应用程序提供了两种服务：数据分组交付至多个目的地，通过客户端请求/发现服务器。
- 交付至多个目的地。有许多应用程序将信息交付至多个收件方,例如,互动式会议、邮件或新闻分发至多个收件方。没有广播或组播,这些类型的服务往往倾向于使用现在的TCP (将一个单独的副本交付至每一个目的地，这是非常低效的)。
- 通过客户端请求服务器。使用广播或组播,应用程序可以向一个服务器发送一个请求，而不用知道任何特定服务器的IP地址。当本地网络环境的信息了解得很少时，这种功能在配置过程中非常有用。例如，一台笔记本电脑可能需要使用DHCP，获取它的初始IP地址，找到其最近的路由器(见第6章)。
虽然广播和组播都可以提供这些重要的功能,但是相对于广播来说,组播一般情况下是
更可取的,因为组播只涉及那些支持或使用特定服务或协议的系统,而广播却不是。因此，一个广播请求会影响在广播范围内所有可以到达的主机,而组播只影响那些可能对该请求有兴趣的主机。当我们探讨广播和组播的详细情况后,这些概念将变得更加清晰。现在，请记住，在广播的更高开销和简单性以及组播的效率改善和更多的复杂性之间存在一种平衡。
广播自出现以来，就一直受到IPv4协议的支持，而随着[RFC1112]的出版，组播被添
加进来。IPv6支持组播但不支持广播。一般来说,只有使用UDP传输协议(第10章)的用
户应用程序利用广播和组播,此时应用程序发送单个报文到多个收件方才是有意义的o。TCP是一个面向连接的协议,这意味着两台主机(由IP地址指定)和每台主机上的一个进程(由端口号指定)之间的一个连接。TCP可以使用单播和任播地址(回想一下，任播地址可以像单播地址一样)，但是不能使用广播或组播地址。
9.2 广播
广播是指将报文发送到网络中的所有可能的接收者。在原理上,这是简单的：路由器简单地将它接收到的任意报文副本转离(forward out)除报文到达的接口以外的每个接日。当有多个主机连接到同一个本地局域网时，事情就稍微有点复杂了。在这种情况下，链路层的特点可以使得广播在某种程度上更高效。
考虑在诸如以太网的网络上的一组主机，这种网络在链路层上支持广播。每个以太网帧包含源和目的MAC地址(48位值)。通常情况下，每个IP分组被指定到一个单一的主机，所以使用单播寻址，目的地的唯一MAC地址使用ARP或IPv6ND来确定。当一个帧以这种方式被发送到一个单播目的地时，任意两个主机之间的通信不会打扰网络上的任何其他主机。对于交换以太网来说，这些都是在交换机和网桥中的站点缓存中发现的地址类型(见第3章)。然而，有些时候，一个主机要向网络(或VLAN)上的每个其他主机发送一个帧一这称为广播（broadcast）。
9.2.1 使用广播地址
在一个以太网或类似网络中，组播MAC地址中高位字节的低序位打开。以十六进制表
示，这看起来像01:00:00:00:00:00。我们可以认为以太网广播地址ff:ff:ff:ff:ff:ff是以太网组播地址的一种特殊情况。从第2章中可以回忆到，在IPv4中，每个子网都有一个本地定向子网广播地址，它是通过将地址中的主机部分全部置1形成的，特殊地址255.255.255.255对应于本地网络(也称为“有限”)广播。
9.2.2 发送广播数据报
一般来说，使用广播的应用程序使用UDP协议(或ICMPv4协议)。然后凋用一组将普通API来发送流量。唯一例外的是，当调用API时。一些操作系统会使用一个特殊的标点
(SO_BROADCAST)，以表示该应用程序确实打算发送广播数据报。到有限广播地址传出流量的处理方式是特定于操作系统的。大多数系统都选取一个单一的具有广播功能的接口来发送这样的流量。
具体细节参考课本
9.3 组播
为了减少在广播中涉及的开销，可以只向那些对它感兴趣的接收方发送流量。这被称为组播(multicasting)。从根本上说，通过发送方指明接收方，或是通过接收方独立地指明它们的兴趣，就可以完成这项工作。然后网络只负责向预期的/感兴趣的收件方来发送流量。实现组播比广播更具挑战性，因为组播状态(multicast state) (信息)必须由主机和路由器来保持，以说明哪些接收方对哪类流量有兴趣。在组播TCP/IP模型中，接收方通过指明组播地址和可选源列表来表明它们对希望接收的流量的兴趣。这个信息作为主机和路由器中的软状态(soft state) (见第4章)来维持，这意味着它必须定期更新或是超时删除。当这发生时，组播流量的交付要么停止，要么恢复为广播。
广播的低效不仅体现在广域网中，此时它们是极其严重的，同时也体现在局域网和企业网络中。在相同LAN或VLAN上可以到达的每个主机必须处理广播分组。IP组播提供了一个更有效的方式以执行相同类型的任务。如果正确地使用IP组播，只有那些在通信中参与或感兴趣的主机需要处理相关的分组，流量只会被承载于它将被使用的链路上，并且只有任意组播数据报的一个副本被承载于任意的这样的链路上。为了使组播工作，希望参与通信的应用程序需要一种机制来发布其意愿的协议实现。然后主机软件可以安排接收与应用程序的条件相匹配的分组。
IP组播在诸如以太网的链路层网络中，起初使用一种基于组寻址工作方式的设计。在这种方法中，每个站点选择它愿意接收流量的组地址，而不考虑发送方。因为对于发送方的身份是不敏感的，所以这种方法有时也被称为任源组播(ASM)。由于IP组播已经演化了，另一种代替方式已经研究出来，它对于发送方的身份是敏感的,被称为特定源组播(SSM)[RFC4607] ，它允许终端站点明确地包含或排除从一组特定发送方发送到一个组播组的流量。
9.3.1 将IP组播地址转换为802 MAC/以太网地址
当我们想要发送组播流量时,什么样的目的地MAC地址应该放置于链路层帧中呢？理想的情况下，我们不必使用协议报文来确定适当的MAC地址，相反，可以只是简单地将一个IP组播地址直接映射到一些对应的MAC地址。
为了了解这是如何完成的，我们会专注于IEEE 802网络，特别是以太网和WiFi。这些网络代表了使用IP组播的最常见的网络类型。首先，我们将讨论与IPv4相关的映射如何进行，然后转移到在IPv6中使用的略有不同的方法。
为了在链路层网络中有效地承载IP组播，在IP层和链路层帧的数据分组和地址之间应该有一个一对一的映射。IANA拥有IEEE组织唯一标识符(以下简称OUI，或非正式称为以太网地址前缀) 00:00:5e。 有了它，IANA就被赋予权限去使用以01:00:5e开始的组(组播) MAC地址以及以00:00:5e开始的单播地址。该前缀被用作以太网地址的高序24位，这意味着此块包括范围在00:00:5e:00:00:00到00:00:5e:ff:ff:ff的单播地址，以及范围在01:00:5e:00:00:00到01:00:5e:ff:ff:ff的组播地址。除了IANA的其他组织也拥有地址块，但只有IANA将其空间的一部分用于支持IP组播。
IANA分配一半的组地址块用于识别IEEE 802 LAN上的IPv4组播流量。这意味着，对应到IPv4组播的以太网地址范围为01:00:5e:00:00:00到01:00:5e:7f:ff:ff。
IPV4地址到它们对应的IEEE 802形式的链路层地址的映射如下图所示。
第二章表示，所有的IPv4组播地址都被包含在从224.0.0.0到239.255.255.255的地址空间中(以前称为D类地址空间)。所有这样的地址在高序位共享一个共同的4位序列1110。因此,有32-4=28位可用来编码整个空间,即2^28=268435456个组播IPv4地址(也称为组ID)。对于IPv4, IANA的政策是分配一半的组地址用于支持IPv4组播,这意味着所有的268435 456个组播组ID需要被映射到只包含2^23 = 8 388 608个唯一条目的链路层地址空间。因此,映射是非唯一的(nonunique)。即多个IPv4组ID被映射到相同MAC层组地址。具体来说, 228/223= 25 = 32个不同的IPv4组播组ID被映射到每个组。
对于IPv6，16位的OUI十六进制前缀是33:33。这意味着，IPv6地址的最后32位可以用来形成链路层地址。因此，任何以相同的32位结束的地址映射到相同的MAC地址(见图9-3)。由于所有的IPv6组播地址以ff开始，随后的8位用于标志和范围信息，这就留下128- 16= 112位用于表示2112个组。因此，MAC层地址的32位可用来编码这些组，可能有多达2112/2^32 = 280个组映射到相同的MAC地址!
9.3.3 发送组播数据报
当发送任意的IP数据分组时，必须决定使用哪个地址和接口。对于IPv6来说尤其如此，因为IPv6中每个接口有多个地址被认为是正常的。为了帮助确定这一点，我们可
以看一下目前主机中的转发表。在Windows或Linux操作系统中，都可以使用netstat命令。通过IP数据报的匹配转发规则确定。
9.3.4 接受组播数据报
组播的基本是在主机给定的接口上进程加入(joining)或离开( leaving)一个或多个组
播组的概念。 (我们使用术语进程(process)代表由操作系统执行的程序，往往代表一个用户。)在一个给定接口上的组播组的成员资格是动态的，它随进程加入或离开组而改变。除了加入或离开组，如果进程希望指定它希望收听或排除的源，就需要额外的方法。这些是支持组播的主机上的任意API的必需部分。组的成员资格与接口相关，因此我们使用限定词“接口”。一个进程可以在多个接口上加入同一组，也可以加人同一接口上的多个，或是其中的任意组合。
具体细节参看课本
9.3.5 主机地址过滤
为了了解操作系统进程如何为程序已加人的组播组接收组播数据报,回忆第3章,每当
一个帧因可能会被接收而交给过滤器(例如,通过一个网桥或交换机)时，过滤(filtering)
就在每个主机的网络接日卡(NIC)上发生。下图说明了这是如何发生的
在一个典型的交换式以太网环境中，广播和组播帧沿着在交换机之间形成的一棵生成树在VLAN中的所有段被复制。这样的帧被交付至每台主机上的NIC，它将会检查帧的正确性(使用CRC)，并且决定是否接收该帧，并将其交付给设备驱动程序和网络协议栈。通常情况下, NIC只接收目的地址是接口的硬件地址或广播地址的那些帧。然而，当涉及组播帧时，情况就更加复杂了。
NIC往往有两类。一类执行基于组播硬件地址的散列（hash）值的过滤，主机软件可以表达对该硬件地址的兴趣，这意味着由于散列（hash）冲突，一些不需要的帧总是可以通过。另一类侦听组播地址的一张有限表，这意味着，如果主机需要接收超过表中能够容纳的更多的组播地址的帧， NIC将进人一种“组播混杂”模式,在这种情况下，所有的组播流量将会交给主机软件。因此，两种类型的接口需要设备驱动程序或高层软件执行检查，以确定接收到的帧是否真的需要。虽然接口进行完善的组播过滤(基于48位的硬件地址)，但是由于从组播IPv4或IPv6地址到48位的硬件地址的映射不是唯一的，高层过滤还是必需的。尽管存在不完美的地址映射和硬件过滤，组播仍然比广播更高效。
对于支持多条目地址表的NIC来说，将每个接收到的帧的目的地址与该表比较，如果在表中发现该地址，该帧由设备驱动程序接收和处理。此表的条目由设备驱动程序软件和协议栈的其他层(如IPv4和IPv6的实现)联合管理。实现这种类型过滤器的另一种方法是对目的地址使用散列函数，形成一个到(较小的)二元向量的索引。当向量中被索引的条目包含一个1位时，对应的地址被视为可以接受，并进一步处理该帧。这种做法可以节省NIC的内存，但因为在散列函数中的冲突，一些不应该接收的帧可能被认为是可以接受的。然而，这不是一个致命的问题，因为栈中较高层也执行过滤，并且当帧不应该被丢弃时，没有帧被丢弃(即，不存在漏报，但有可能存在误报)。
然后,设备驱动程序将该帧传递到下一层，例如，如果帧类型指定一个IP数据报,则为IP层。基于源和目的IP地址，IP进行更多的过滤，如果一切没有问题，它将该数据报向上传递到下一层(如TCP或UDP)。每次UDP从IP收到一个数据报，它执行基于目的端口号的过滤，有时也基于源端口号。如果当前没有进程正在使用该目的端口，数据报就被丢弃，并生成一个ICMPv4或ICMPv6端口不可达报文。(TCP基于它的端口号执行类似的过滤。)如果UDP数据报存在校验和错误,，UDP默默丢弃它。
研究组播寻址特征背后的主要动机之一是避免广播的开销。考虑一个设计为使用UDP
广播的应用程序。如果网络(或VLAN)中有50台主机，但只有20台参与该应用，每当20台主机中的一台发送一个UDP广播时，在UDP数据报被丢弃之前，它要一路向上直至UDP层，其他30台非参与主机不得不处理该广播。该UDP数据报被这30台主机丢弃，因为目的端口号没有在使用。组播的目的就是减少对该应用没有兴趣的主机的负担。使用组播，一台主机明确地加入一个或多个组播组。如果可能的话，NIC被告知主机属于哪个组播组，并且只有那些与IP层组播组相关联的组播帧被允许通过NIC中的过滤器。这一机制所提供的就是使主机上的开销更小，作为代价，需要在管理组播地址和组成员中添加额外的复杂性。
9.4 互联网组管理协议和组播侦听发现协议
到目前为止，我们已经从主机的角度讨论了组播数据报如何传输、过滤和接收。当组播数据报在广域网或是在跨越多个子网的企业中转发时，我们要求,组播路由(multicast routing)应该由一个或多个组播路由器启动。这种情况更加复杂,因为为了合理地安排要交付的组播流量，组播路由器需要了解哪些主机对什么组播组感兴趣。它们也执行一个特定的程序，称为反向路径转发(RPF)检查。此过程在到达的组播数据报的源地址上进行路由查找。只有当路由的传出接口与数据报到达的接口相匹配时，数据报才转发。RPF检查对于避免组播回路来说是非常重要的。组播路由在很大程度上是独立于由IP路由器提供的传统的单播路由的。然而，一些组播路由的功能需要IPv6ND协议(见第8章)来正常地操作。
两个主要的协议用于允许组播路由器了解附近的主机感兴趣的组：IPv4使用的互联网组管理协议(IGMP)和IPv6使用的组播侦听发现(MLD)协议。两者都由支持组播的主机和路由器使用，并且协议非常相似。这些协议让LAN (VLAN)上的组播路由器知道哪些主机当前属于哪些组播组。路由器需要此信息，这样它们知道哪些组播数据报转发到哪些接口。在大多数情况下，组播路由器只要求知道至少一个侦听主机通过一个特定接口是可达的，因为链路层组播寻址(假设它支持)允许组播路由器发送链路层组播帧，这些帧将被所有的感兴趣的侦听方接收。这允许一个组播路由器完成其工作，而不用记录每个接口上的单个主机，它们可能只对特定组的组播流量感兴趣。
IGMP版本1是第一个广泛使用的IGMP版本。版本2添加了更迅速地离开组(也被MLDvl支持)的能力。IGMPv3和MLDv2添加了选择组播流量源的能力，并要求部署SSM。然而IGMP是IPv4使用的一个单独的协议，而MLD是ICMPv6(见第8章)的真正的一部分。
下图显示了IPv4 (IPv6)具有组播功能的路由器如何使用IGMP (MLD)。这样的路由器关注于确定在它的每个连接的接口上有哪些感兴趣的组播组。这些路由器需要此信息，以避免简单地从每个接口广播出所有的流量。
在上图中，我们可以看到IGMP (MLD)查询是如何通过组播路由器发送的。这些被
发送到所有主机组播地址224.0.0.1（IGMP），或所有节点链路范围组播地址ff02::1 ( MLD)，并且被实现IP组播的每台主机处理(请参见9.4.2节中的特例, “特殊的”查询)。成员资格报告报文由组成员发送以响应查询，但是也可能从一些主机以一种主动提供的方式来发送，这些主机希望通知组播路由器它们的组成员资格和/或对特定源的兴趣已经改变了。IGMPv3报告发送到具有IGMPv3功能的组播路由器地址224.0.0.22。MLDv2报告被发送到相应的MLDv2侦听IPv6组播地址ff02::16。需要注意的是，当组播路由器加入组播组时，组播路由器本身也作为成员。
IGMP和MLD的封装如图9-7所示。与ICMP类似，IGMP被认为是IP层的一部分。还和ICMP类似的是，IGMP报文也在IPv4数据报中传输。不像我们已经看到的其他协议，IGMP使用一个固定的为1的TTL值，所以数据分组仅限于本地子网。IGMP数据分组也使用IPv4路由器警告选项，并使用6位值0x30的DS字段来代表网间控制(CS6,参见第5
章)。在IPv6中，MLD是ICMPv6的一部分，但MLD的功能和IGMP的几乎是相同的，所以我们在此描述它(在第8章中，当描述ICMPv6时，我们简单地描述了它的报文格式)。它的封装使用了IPv6的逐跳扩展头部以保持路由器警告选项。在许多情况下，源列表是空的。
IGMP和MLD定义了两组协议处理规则：由组成员的主机执行的和由组播路由器执行
的。一般来说，成员主机(我们将其称为“组成员”)的工作是自发地报告对组播组和源的兴趣改变，以及响应定期的查询。组播路由器发送查询，以确定连接链路上的对于任意组或是特定的组播组和源是否有兴趣。路由器也与广域组播协议(如PIM-SM和BIDIR-PIM)交互，将所需的流量带给有兴趣的主机或禁止流量流向不感兴趣的主机。
9.4.1 组成员的IGMP和MLD处理(“组成员部分”)
IGMP和MLD组成员的部分被设计为允许主机指定它们对什么样的组有兴趣，以及从
特定源发送的流量是否应该接受或过滤掉。这是通过向一个或多个连接到同一子网的组播路由器(和参与主机)发送报告完成的。报告可以作为接收查询的结果发送，或是因为接收状态(例如，一个应用程序加入或离开某个组)的本地改变而自发地(即主动提供)发送。
IGMP的格式如下图所示
每个组记录中包含一个类型、主题组的地址,以及要包含或是排除的源地址列表。此
外，还支持包括辅助数据，但此功能在IGMPv3中没有使用。MLD使用相同的值。源列表涉及了包舍(include)或排除(exclude)模式。在包含模式中，在列表中的源是流量应该被接收的唯一的源。在排除模式中，在列表中的源是应该被过滤掉的(所有其他的是允许的)。离开一个组可以表示为使用没有源的包含模式过滤器，一个组的简单加入（即对所有源）可以表示为使用没有源的排除模式滤波器。注意，当使用SSM时，类型Ox02和Ox04不能使用，因为对于任意组，只有一个单一源是假定的。
上表中类型细节参考课本
当接收到一个查询时,组成员没有立即回应。相反，它们设置一个随机的(有界限的)计时器来决定何时响应。在此期间，进程可能会改变它们的组/源兴趣。任何这样的变化可以在计时器到期前一起处理来触发报告。这样一来，一旦计时器到期，多个组的状态可以更容易地被合并成一个单一的报告，节省了开销。
用于IGMP的源地址是发送接口的主要或首选的IPv4地址。对于MLD，源地址是本地链路IPv6地址。当主机在启动并尝试确定它自己的IPv6地址时，会同时出现一个问题。在此期间，它选择一个潜在的IPv6地址来使用并执行重复地址检测(DAD)过程(见第6章)，以确定是否有任何其他的系统已经使用这个地址。因为DAD涉及组播，一些源地址必须被分配为传出MLD报文。 [RFC3590]解决了这个问题，它允许未指定的地址(::)在配置过程中被用来作为MLD流量的源IPv6地址。
9.4.2 组播路由器的IGMP和MLD处理( “组播路由器部分”)
在IGMP和MLD中，组播路由器的工作是为每个组播组、接口和源列表确定是否至少有一个组成员目前在接收相应的流量。这是通过发送查询，以及基于成员发送的报告，建立描述成员存在性的状态来完成的。此状态是软状态，这意味着，如果没有被刷新，在经过一个确定的时间后，它会被清除。为了建立这种状态，组播路由器发送IGMPv3查询，其形式如下图所示
组播地址长度是32位，最大响应代码(Max Resp Code)字段是8位，最大响应代码字段编码查询的接收方在发送报告之前应该延迟的最大时间量，对于128以下的值以
100ms为单位编码。
查询中的其余字段包括跨越整个报文的互联网式的校验和、主题组的地址、源列表，以及我们在第8章中讨论MLD时定义的S、 QRV和QQIC字段。当组播路由器希望了解所有组播组的兴趣时，组地址(Group Address)字段被设置为0 (这样的查询被称为“一般查询”）。s和QRv字段用于容错和报告重传，QQIC字段是Querier’s Query Interval Code的缩写。这个值是以秒为单位查询发送周期，并使用和最大响应代码字段相同的方法进行编码。
有三种查询报文的变体可以由组播路由器发送：一般查询(general query),特定组查询(group specific query)，特定组和源查询( group-and-source-specific-query）。第一种形式被组播路由器用于更新任意组播组的信息，对于这样的查询，组列表是空的。特定组查询与一般查询类似，但对于识别的组是特定的。最后一类本质上是一个包含一组源的特定组查询。特定的查询被发送到主题组的目的IP地址，与之形成对照，一般查询被发送到所有系统的组播地址(对于IPv4 )或IPv6中的链路范围内的所有节点组播地址(ff02::1 )。
组成员发送特定查询响应状态变化报告，以证明它适用于路由器采取一些措施(例如，在构造一个过滤器之前，确保没有兴趣仍然在特定的组中)。当接收过滤器模式改变记录或源列表改变记录时，组播路由器安排增加新的流量源，并且能够过滤掉来自特定源的流量。在组播路由器准备开始过滤前面正流动的流量时，它首先使用特定组查询以及特定组和源查询。如果这些查询没有引起任何报告，路由器开始过滤相应的流量。因为这种变化可以显著地影响组播流量的流动，状态变化报告和特定查询被重传。
9.4.4 轻量级IGMPv3和MLDv2
正如我们已经看到的那样,主机维护对它们的应用和系统软件感兴趣的组播组的过滤器状态。对于IGMPv3或MLDv2,它们也维护被排除或包含的源列表。为了了解什么流量需要被转发到链路上以便有兴趣的主机收到，组播路由器维护类似的状态。反过来也是如此，一个组播路由器可以停止转发在每个接收方的排除列表中的主机发送的组播流量。实践经验证明，应用程序很少需要屏蔽特定源，并且支持此功能也比较复杂。然而，主机往往希望包含一个与一个组相关联的特定源，尤其是当SSM在使用时。因此，简化版的IGMPv3和MLDv2已在[RFC5790]中定义，分别称为轻量级IGMPv3 ( IJW-1GMPv3 )和轻量级MLDv2(LW-MLDv2 ) 。
LW-1GMPv3和LW￣MLDv2是其正本的子集。它们支持ASM和SSM,并使用与IGMPv3和MLDv2兼容的报文格式，但它们缺少特定阻塞源的功能。相反，唯一支持的排除模式是没有列出源的情况，它对应于所有版本的IGMP或MLD中的传统的组加人(例如，与图9-13中一样)。对于组播路由器，这意味着唯一需要的状态是记录哪些组感兴趣，以及哪些源感兴趣。它不需要记录任何不期望的单个源。
9.4.5 IGMP和MLD健壮性
对于IGMP和MLD协议的健壮性和可靠性有两个主要的问题。IGMP或MLD的失效，或更一般的组播，可以导致不需要的组播流量的分配，或没有能力交付期望的组播流量。由IGMP和MLD处理的失败类型包含组播路由器的失效和协议报文的丢失。
通过允许多个组播路由器在同一链路上运行，可以处理组播路由器潜在的失效故障。正如前面提到的，在这样的配置中，具有最小IP地址的路由器被选为“查询器”。查询器负责发送一般和特定查询来确定该子网中主机的当前状态。其他(非查询器)路由器监控协议报文，因为它们也是组成员或组播混杂侦听器，并且假如当前查询器失效了，不同的路由器能够作为查询器介入。为了使其正常工作，所有连接到相同链路的组播路由器需要协调它们的查询、响应和它们的一些配置信息(主要是计时器)。
多个组播路由器实现的第一种类型的协调是查询器选举( querier election)。每个组播路由器可以侦听其他的查询。当一个组播路由器启动时，它认为自已是查询器，并发送一般查询以确定在子网中哪些组是活跃的。当一个路由器收到另一个路由器的组播查询时，它比较源IP地址和它自已的。如果在所接收的查询中的源IP地址小于它自已的，接收路由器进入备用模式。因此，具有最小IP地址的路由器被认为是获胜者，并成为单一的查询器，负责向它连接的子网中发送查询。备用的路由器设置计时器，如果它们在一个指定的时间(称为其他查询器出现( other-querier-present)计时器)内没有看到更多的查询，它们再次成为查询器。
查询组播路由器定期发送一般查询，以确定哪些组和主机是同一个子网的主机感兴趣的。这些查询被发送的频率由查询器的查询间隔、可配置计时器参数决定。当多个组播路由器在同一子网中运行时，当前查询器的时间间隔被所有其他路由器接受。在这种方式中，如果当前查询器失效，到替代组播路由器的切换不会干扰定期查询速率。
有理由相信，一个组(或源)不再感兴趣的组播路由器发送一个特定的优先查询以停止相应组播流量的转发(或通知组播路由协议)。这些查询以不同于一般查询的时间间隔(称为最后成员查询时间(Last Member Query Time, LMQT)发送。LMQT通常比查询间隔要小(短)，并管理离开延迟。当多个组播路由器在同一个子网运行时，可能同时出现一个问题，主机希望离开组(或丢弃源)，并且协议信息会丢失。
为了帮助防止丢失协议报文，有些报文被重传多次(由QRv查询器鲁棒性变量决定)。QRV值在包含于查询中的QRV字段中编码，非查询路由器采用查询器的QRV作为自已的。如果查询器发生改变，这再次帮助保持了稳定性。重传中保护的报文类型包括状态改变报告和特定查询。其他报文(当前状态报告)通常不会导致转发状态的变化，而是只涉及通过调整计时器刷新软状态，所以使用重传无法保护它们。当重传发生时，报告的重传间隔在0和一个称为主动报告间隔( Unsolicited Report Interval)的可配置参数之间随机选择，查询的重传间隔是周期性的(基于LMQT的间隔)。预计更容易出现丢失的链路(如无线链路)，可能需要以生成额外的流量为代价，增加鲁棒性变量以增强分组丢失的健壮性。
当处理特定查询时，为了帮助组播路由器保持同步，查询报文中S位字段表明路由器
端(计时器)处理应被抑制。当一个特定的查询由查询器发送时，应该安排一个重传次数(QRV)。在发送的第一个查询中，S位字段被清除。基于重传或这种查询的接收，组播路由器会为随后的重传降低它的计时器到LMQT。此时，感兴趣的主机提供一个报告，指出它对一个组或源的持续的兴趣，这是可能的。如果没有报文丢失，该报告使每个组播路由器重置它的计时器为普通值，并保持不变。然而，预定的重传不会被放弃。相反，特定查询的重传被发送时，S位字段被设置，这将导致接收路由器不会降低它们的计时器到LMQT。
在收到表示有兴趣的报告之后，仍保持查询重传的原因，是为了使跨越所有组播路由器的组的超时时间是一致的。然后，S位字段的目的是为了让特定的查询被(重新)发送，也为了避免降低计时器到LMQT，因为一个表示兴趣的合法的报告可能已经被接受了，即使它或初始查询被非查询器路由器丢失了。没有这种能力，重传的特定查询会导致非查询器路由器不正确地降低它们的计时器(因为已经收到一个表明兴趣的合法报告)。
9.4.6 IGMP和MLD计数器和变量
IGMP和MLD是软状态的协议,它们也处理路由器的失效、协议报文的丢失以及与早
期协议版本的互操作性。很多设备是基于触发状态改变和协议动作的计时器来启用这些功能的。书中表9-3总结了IGMP和MLD使用的所有的配置参数和状态变量。
9.4.7 IGMP和MLD探听
IGMP和MLD管理路由器之间IP组播流量的流动。为了进一步优化流量流动,对于第
2层交换机(即通常不会处理第3层IGMP或MLD报文)来说,通过查看在第3层的信息了解它对特定的组播流量流动是否有兴趣,这是可能的。该功能通过称为IGMP (MLD)探听(snooping) [RFC4541]的交换机特征指明,并且被很多交换机供应商支持。没有IGMP探听,交换机通常沿着所有交换机形成的生成树的所有分支广播它来发送链路层流量。这是一种浪费,如我们前面描述的原因。IGMP (MLD)感知的(有时也把IGMP探听称为IGS)交换机监控主机和组播路由器之间的IGMP (MLD)流量，并且能记录哪些端口需要哪些特定的组播流动，这和组播路由器的做法很相似。这样做能够实质地影响在一个交换网络中正在被承载的不需要的组播流量的数量。