排除路由故障

 

上一次修改主题： 2006-03-15

本主题讨论了可能导致 Microsoft® Exchange 组织中的路由中断的一些常见情形。其中包括下列主题：

• 使用 WinRoute
  此部分说明了 WinRoute 工具在解决路由问题中的作用。
• 常见的链接状态问题
  此部分说明了由于路由组之间的连接断开、路由组主服务器存在冲突、路由组被删除、连接器被标记为不可用以及连接振荡而导致的问题，并说明了如何解决这些问题。
• 链路状态传播被中断
  此部分说明了将路由组桥头服务器从 Exchange Server 5.5 服务器更改为 Exchange 2000 Server 或 Exchange Server 2003 桥头服务器，然后将该桥头服务器重新更改为 Exchange 5.5 服务器时会出现的问题。

使用 WinRoute

WinRoute 是 Exchange 2003 中的一个工具，用于确定路由主服务器已知的路由拓扑和链接状态路由信息。当在 Exchange 2000 和 Exchange 2003 邮件环境中解决路由问题时，应首先使用这一工具。该工具连接到 Exchange 2000 服务器或 Exchange 2003 服务器上的链接状态端口 - TCP 端口 691，并提取组织的链接状态信息。该信息是一系列 GUID，WinRoute 将这些 GUID 与 Microsoft Active Directory® 目录服务中的对象以及连接器和桥头服务器匹配，然后以可读的格式呈现这些 GUID。

注意：
WinRoute 工具和用户文档可从 Downloads for Exchange Server 2003 网站（英文）获取。建议下载该工具并在组织中的所有 Exchange 2000 和 Exchange 2003 服务器上使用它。应使用下载得到的这个工具，而不是随 Exchange 2000 提供的 WinRoute 工具。

常见的链接状态问题

在路由组内部，Exchange 使用 TCP 端口 691 在路由组主服务器与其路由组成员之间，传递链接状态和路由信息更新。在两个路由组之间，两个路由组桥头服务器使用 X-LINK2STATE 动作交换链接状态信息，方法是比较含有两个路由组桥头链接状态信息的摘要（即 Orginfo 数据包中的加密数字签名）。这些摘要之间的差异会导致两个服务器之间使用 SMTP 端口 25 交换链接状态信息。

路由组主服务器根据路由组内的服务器所了解到的更改来调整链接状态，并从 Active Directory 中检索更新。如果路由组主服务器不可用，则路由组中的所有服务器都将继续使用它们与路由组主服务器失去联系时所持有的同一信息运行。

当路由组主服务器再次变为可用时，它将从标记为不可用的所有服务器和连接器开始，重建链接状态信息。然后，路由组主服务器将查找所有不可用的服务器，以更新路由组内的成员。

此部分讨论了下列链接状态问题，并说明了推荐的解决方案：

• 路由组成员与主服务器之间的连接断开
• 路由组主服务器之间存在冲突
• 删除路由组而导致的问题
• 连接器未标记为“down”
• 连接振荡

路由组成员与主服务器之间的连接断开

当路由组成员无法连接到路由组主服务器时，WinRoute 会在路由组成员旁边标记红色的 X 以指明这一情况。

通过执行下列步骤可以解决这些问题：

• 确保路由组中所有受影响的服务器上的 Microsoft Exchange Routing Engine 服务 (RESvc) 都已启动，并且处于受控状态。如果路由引擎服务处于不稳定状态，则路由组成员可能无法连接到路由组主服务器。应首先调查任何不稳定服务的根源。

• 通过启动与受影响的服务器和主节点的 691 端口的 telnet 会话，确认 691 端口未被防火墙禁用。您应该会看到一个表示活动状态的 Microsoft Routing Engine 标志。

• 从命令行中，键入下列命令：

  netstat -a -n 
  

  输出应显示连接到主节点的 691 端口的所有路由组成员和主服务器本身，如下所示：

  TCP    127.0.0.1:691          127.0.0.1:691         ESTABLISHED
  

• 检查事件查看器应用程序日志，以查找指出未能使用计算机帐户（域\服务器名）通过身份验证的所有事件。监视下列传输事件：

  • 当成员服务器未能通过其路由组主服务器的身份验证时记录的事件 ID 961。
  • 当客户端节点未能通过路由服务 (RESvc) 的身份验证时记录的事件 ID 962。
  • 当客户端路由节点成功地通过路由引擎服务的身份验证时记录的事件 ID 996。
  • 当路由组成员成功地通过其路由组主服务器的身份验证时记录的事件 ID 995。

• 通过检查受影响的服务器的网络地址属性中的 ncacn_ip_tcp 值，确认受影响的服务器能够生成身份验证过程中使用的 ServicePrincipalName (SPN)。这是通过使用诸如 LDP (ldp.exe) 或 ADSI Edit (adsiEdit.msc) 等目录访问工具来完成的。
  路由组中的成员必须与路由组主服务器进行相互身份验证才能连接。为此，它们使用 Exchange 服务器的网络地址属性中的 ncacn_ip_tcp 值并通过调用 DsClientMakeSpnForTargetServer 来为主节点生成 SPN。然后路由组成员可以使用 Kerberos 进行身份验证。请确保该值是完全限定的域名 (FQDN)，而不是 NetBIOS 名称或 Internet 协议地址。重新启动 Exchange Routing Engine 服务。

• 确认域计算机帐户密码未过期。

• 如果路由组的成员跨多个域，应确保问题不是由于 DNS 配置错误而导致的子域或根域问题而引起。

• 检查限制权限或安全性的任何非 Microsoft 应用程序或组策略对象。

• 将路由组中的另一台服务器配置为路由组主服务器。此方法是一种中间解决方案。重新指定路由组主服务器角色可以在问题解决之前缓解问题所带来的影响。

• 如果路由组主服务器或任何路由组成员缺少 SendAs 权限，则 WinRoute 会将该服务器显示为 Am I connected to the Master?:NO。请确认此服务器或它所属的组未明确拒绝路由组主服务器上的 SendAs 权限。

路由组主服务器之间存在冲突

路由组中安装的第一台服务器自动被指定为主节点或路由组主服务器。安装其他服务器后，可以将另一台服务器指定为路由组主服务器。

任何时候，都应该只有一台服务器被自身以及其他服务器识别为主服务器。此配置是通过算法（路由组中必须有 (N/2) +1 台服务器同意并认可该主服务器）来强制实现的。N 表示路由组中的服务器数。随后，成员节点向主节点发送链接状态 ATTACH 数据。

有时，会有两台或更多的服务器将另一台服务器错认为路由组主服务器。例如，如果在未选择另一个主节点的情况下移动或删除了路由组主服务器，则 msExchRoutingMasterDN（Active Directory 中指定路由组主服务器的属性）可能会指向已删除的服务器，因为属性未链接上。

此外，如果原来的路由组主服务器拒绝放弃主服务器角色，或者带欺骗性质的节点继续向原来的路由组主服务器发送链接状态 ATTACH 信息，则也会发生这种情况。在 Exchange 2003 中，如果 msExchRoutingMasterDN 指向已删除的对象，则主节点会放弃其主服务器的角色，并关闭主服务器角色。

通过执行下列步骤可以解决这些问题：

• 在端口 691 上检查路由组内部的正常链接状态传播。请确认防火墙或 SMTP 筛选器未阻止通信。
• 确认没有 Exchange 服务停止运行。
• 通过使用 Windows 资源工具包中提供的 Active Directory 复制监视工具 (Replmon.exe) 来检查 Active Directory 复制延迟。
• 检查网络问题和延迟。
• 检查已删除的路由组主服务器或服务器是否不再存在。如果是，则会在事件查看器的应用程序日志中记录传输事件 958，以指出路由组主服务器不再存在。通过使用诸如 LDP (ldp.exe) 或 ADSI Edit (adsiEdit.msc) 等目录访问工具来确认此信息。

删除路由组而导致的问题

在由于服务器已移出或者其他原因而导致路由组被删除后，WinRoute 会为对象显示文本“object_not_found_in_DS”。

Exchange 服务器维护的仍然是引用这些对象的链路状态表，但是当路由引擎服务初始化并检查 Active Directory 以查找相关的对象时，在 Active Directory 中找不到这些对象。

Exchange 路由无法自动将已删除的路由组及其成员（即：服务器和连接器）从链路状态表中删除。事实上，路由将已删除的路由组与现有的正在工作的路由组同等对待。在极偶尔的情况下，已删除的路由组会导致路由工作不正常，以及出现邮件循环。已删除的路由组会严重地影响有 Exchange 5.5 站点加入的 Exchange 2003 组织的拓扑。

此外，这些已删除的路由组对象会大大增加链路状态表的大小，从而增加交换链接状态信息而导致的网络通信量。

最后，如果个人通讯簿 (PAB) 或脱机通讯簿 (OAB) 具有与已删除的路由组匹配的 legacyExchange 域名，则已删除的路由组对象会导致将发送给 PAB 或 OAB 中不存在用户的邮件添加到目标不可达的邮件队列。在两天的默认超时后，通过未送达报告 (NDR) 将该邮件退回发件人。如果没有已删除的路由组对象，则发送给不存在用户的邮件将通过 NDR 立即退回发件人，而不是首先将其添加到队列中。

要解决这一问题，应首先确认用来在服务器上查看路由信息的帐户拥有足够的权限。如果可能，应通过使用系统帐户和 AT 交互式命令来登录到 WinRoute。缺少足够的读取权限会导致 WinRoute 中出现错误的 object_not_found_in_DS 消息。

可以通过使用下列方法之一将已删除的路由组从链接状态信息中清除。

• 同时关闭组织中的所有服务器，以刷新路由缓存信息，并清除已删除的路由组和连接器。
• 同时关闭组织中的所有 Exchange 服务器上的所有 Exchange 和 Windows Management Instrumentation (WMI) 服务。

通过使用 Remonitor.exe 减小已删除路由组占用的大小并将路由组标记为已删除，也可以解决此问题。

Remonitor.exe 是一种可以将自定义路由数据包置入 Exchange 组织的工具。自定义数据包是已删除路由组数据包的修改版本。此修改版本没有服务器条目或连接器条目，这样就大大减小了路由组对象的大小。此外，此版本消除了因连接器条目中的路由组已被删除而导致路由出现故障或延迟的可能性。由于该工具置入了没有连接器条目的已修改数据包，因此不可能存在其中的路由组已被删除的连接器条目。最后，Remonitor.exe 更新已修改路由组的版本号，以便无法将服务器条目或连接条目添加到这个已删除的路由组。

有关详细说明，请参阅如何在注入模式中以本地系统帐户运行 Remonitor.exe。

运行 Remonitor.exe 后，路由数据包不再包含任何服务器成员或连接器。此时路由组地址以关键字 deleted 开头。此外，递增了路由组对象的版本号。

连接器未标记为“Down”

在某些情况下，连接器的链接状态可能标记为“up”，而它实际上不可用或者应标记为“down”。在下列情况下，路由不将连接器的链接状态标记为 down。

• 连接器使用 DNS 将邮件路由到地址空间中的域（例如，使用 DNS 的 SMTP 连接器）。
• Exchange 5.5 或自定义 EDK（Exchange 开发工具包）连接器，因为它们不使用链接状态路由。
• 将任意本地桥头服务器指定为本地桥头的路由组连接器。创建路由组时，可以通过单击“任何本地服务器都可以通过此连接器发送邮件”将任意本地桥头服务器指定为本地桥头。
• 其中某个桥头服务器为 Exchange 5.5 服务器的路由组连接器。

其他异常情形还包括：

• 在路由组内部，中继邮件未能防止路由组内部出现邮件传输代理 (MTA) 循环。
• 连接器配置了智能主机，而该智能主机最近刚刚变更。

要使路由将连接器标记为 down，所有源桥头服务器都必须关闭，且状态为 VS_CONN_NOT_AVAILABLE 或 VS_CONN_NOT_STARTED。可以通过使用 WinRoute 来检查该状态。

连接振荡

不可靠网络中状态在“up”和“down”之间来回变换的连接器会导致服务器之间的链接状态更新过于频繁。这些变换会导致在 Exchange 内部频繁地重新计算路由，从而增加了成本。此时，在事件查看器中会频繁地记录事件 ID 4005，并显示“重置路由”文本。Exchange 2003 在检测到连接器的状态频繁变化时，会在一个轮询间隔（服务器监视状态变化的时间段）内将状态继续标记为 up，从而降低了变化的频率。但是，如果这些变化是在不同的轮询时间段内发生的，则振荡连接仍然会产生链接状态通信。Exchange 2003 服务器的默认状态延迟更改间隔为 10 分钟。

Exchange 路由选择最佳路径，并找到邮件的下一跃点服务器，然后将此“下一跃点”服务器的名称提供给队列。最佳路径是根据开销、邮件类型和限制等变量来选择的。由于连接器的状态出现振荡，因此 Exchange 不得不反复地重新计算最佳路径（此过程涉及到 Active Directory 查询和性能开销）。

当 Exchange 队列将链接故障通知给连接器上的桥头服务器时，路由将此信息中继给路由组主服务器。路由组主服务器抑制此信息达 10 分钟，以防止连接器的状态发生波动。如果路由将连接器标记为 down，则此变化会传播到组织中的所有 Exchange 服务器，其中包括最初发生故障的服务器。此通知称为重置路由，从 CPU 使用率的角度来衡量，这是一个非常昂贵的过程。邮件不再在连接器上排队，并且路由必须产生新的传递路径。当将连接器标记为 up 时，同样会发生上述过程。

在下列情况下，连接会发生振荡：

• 网络问题（这可以从网络跟踪中看出来）。
• 由于非 Microsoft 应用程序在 X.400 或 SMTP 协议级别所引起的干扰，导致从底层的协议服务（SMTP 和 MTA）回调链接状态通知响应。在这种情况下，只有通过网络监视跟踪才能发现问题。此外，还可以使用 Microsoft 产品支持服务提供的 remonitor.exe 工具。

可以在监视模式下使用“网络监视器 (Netmon.exe)”或 remonitor.exe 工具来找到并解决导致连接发生振荡的根源。此外，如果振荡连接导致过多的传播通信，则可以在解决根本原因之前，抑制链路状态更改的传播。

有关详细说明，请参阅如何抑制服务器上的链接状态信息。

有关抑制链接状态通信的详细信息，请参阅高级路由配置中的“抑制连接器的链接状态通信”。

链路状态传播被中断

Exchange 5.5 服务器不使用链接状态信息，而依靠网关地址路由表 (GWART) 来路由邮件。在混合模式组织中，Exchange 2000 和更高版本识别这一限制并直接从 Active Directory 中读取 Exchange 5.5 服务器的配置。因此，Exchange 2000 和 Exchange 2003 服务器预计 Exchange 5.5 服务器不与其交换链接状态信息。

当 Exchange 路由组中的 Exchange 5.5 桥头服务器升级到 Exchange 2000 或 Exchange 2003 服务器并被指定为桥头服务器之后，开始参与链接状态信息交换，并且主版本号不再为零。Exchange 2000 和 Exchange 2003 服务器使用链路状态表中的版本号来比较链路状态表，并确保服务器具有关于链接状态的最新信息。主版本号为零意味着服务器未参与链接状态信息交换，或者从未交换过链接状态信息。所有纯 Exchange 5.5 站点的版本号都为零，因为它们不交换链接状态信息。在服务器升级到 Exchange 2000 或 Exchange 2003 服务器之后，开始参与链接状态信息交换，并增大主版本号。因此，其他路由组中的桥头服务器预计新升级的服务器会将其路由组中的链接状态变化通知给它们。

如果现在将某一台 Exchange 5.5 服务器指定为该路由组的桥头服务器，则可能会出现问题。其他服务器仍然预计 Exchange 5.5 桥头服务器（即以前的 Exchange 2000 或 Exchange 2003 桥头服务器）参与链接状态传播，并等待该服务器向它们提供更新后的链接状态信息。但是，由于该服务器已回复到 Exchange 5.5，因此不再拥有链路状态表。这样，该路由组现在成为了孤立的路由组，不参与组织中的动态链接状态更新。

在如图 11.4 所示的情形下，这一孤立的路由组会导致问题。具体地说，由于 Exchange 5.5 桥头服务器以前是 Exchange 2000 或 Exchange 2003 桥头服务器，因此其他服务器期望它参与链接状态传播。下图中的 Exchange 5.5 Internet 邮件连接器和 Exchange 2003 SMTP 连接器均使用一台智能主机来向 Internet 路由邮件。该智能主机不可用，因此 Exchange 2003 桥头服务器将通过其 SMTP 连接器的路由标记为不可用。但是，由于该桥头服务器预计 Exchange 5.5 服务器会发送有关其路由组和连接器的链接状态信息，因此它假定通过 Internet 邮件连接器的路由可用，并尝试通过该路由传递邮件。出现一次失败后，Exchange 2003 服务器检测到可能存在循环，而不尝试通过该路由传递邮件。

如果将阻止链路状态传播的防火墙添加到系统，则链路状态传播也会中断。例如，在一个路由组内需要端口 25 和 691，而在路由组之间需要端口 25。此外，防火墙不得阻止扩展简单邮件传输协议 (ESMTP) 命令 X-LINK2STATE。

为解决此问题，可以采用如下解决方案：

• 将 Exchange 5.5 桥头服务器升级到 Exchange 2000 或 Exchange 2003 服务器，或者使用另一台 Exchange 2000 或 Exchange 2003 服务器再次发送该路由组的链接状态信息。其中的每一种方法都是首选解决方案，也是最简单的解决方案。
• 若要将未连接的路由组重置为链路状态主版本号 0，请同时关闭组织中的所有 Exchange 服务器，再重新启动所有 Exchange 服务器。
• 配置防火墙以便不阻止链接状态传播。

有关独立或分离的路由组以及主版本号的详细信息，请参阅 Microsoft 知识库文章 842026“Routing status information is not propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003（英文）”。