Outposts 机架网络故障排除清单 - AWS Outposts
与 Outpost 网络设备的连接与 AWS 区域连接的 AWS Direct Connect 公有虚拟接口与 AWS 区域连接的 AWS Direct Connect 私有虚拟接口与 AWS 区域的 ISP 公共互联网连接Outposts 位于两个防火墙设备后面

Outposts 机架网络故障排除清单

利用这份核对清单来帮助对 DOWN 状态的服务链路进行故障排除。

虚拟 LAN。

与 Outpost 网络设备的连接

检查连接到 Outpost 网络设备的客户本地网络设备上的 BGP 对等互连状态。如果 BGP 对等互连状态为 DOWN，请按照以下步骤操作：

  1. 从客户设备上 ping Outpost 网络设备上的远程对等 IP 地址。您可以在设备的 BGP 配置中找到对等 IP 地址。还可以参阅安装时提供给您的 网络就绪性核对清单。

  2. 如果 ping 失败，请检查物理连接并确保连接状态为 UP。

    1. 确认客户本地网络设备的 LACP 状态。

    2. 检查设备上的接口状态。如果状态为 UP，请跳到第 3 步。

    3. 检查客户的本地网络设备，并确认光纤模块工作正常。

    4. 更换有问题的光纤，并确保指示灯 (Tx/Rx) 在可接受的范围内。

  3. 如果 ping 成功，请检查客户的本地网络设备，并确保以下 BGP 配置正确无误。

    1. 确认本地自治系统号（客户 ASN）配置正确无误。

    2. 确认远程自治系统号（Outpost ASN）配置正确无误。

    3. 确认接口 IP 和远程对等 IP 地址配置正确无误。

    4. 确认通告和接收的路由正确无误。

  4. 如果您的 BGP 会话在活动状态和连接状态之间抖动，请确认客户本地网络设备上的 TCP 端口 179 和其他相关的临时端口均未被阻止。

  5. 如果需要进一步排除故障，请在客户的本地网络设备上检查以下几项：

    1. BGP 和 TCP 调试日志

    2. BGP 日志

    3. 数据包捕获

  6. 如果问题仍然存在，请执行从 Outpost 连接的路由器到 Outpost 网络设备对等 IP 地址的 MTR/traceroute/数据包捕获。根据您的企业支持计划，将测试结果共享给 AWS 支持。

如果客户本地网络设备和 Outpost 网络设备之间的 BGP 对等互连状态为 UP，但服务链路仍然是 DOWN 状态，您可以通过检查客户本地网络设备上的以下设备来进一步排除故障。根据服务链路链接的预配置方式，参考以下核对清单之一。

与 AWS 区域连接的 AWS Direct Connect 公有虚拟接口

使用公有虚拟接口实现服务链路连接时，请参考以下核对清单对与 AWS Direct Connect 连接的边缘路由器进行故障排除。

  1. 确认直接与 Outpost 网络设备连接的设备是通过 BGP 接收服务链路 IP 地址范围的。

    1. 确认通过 BGP 从您的设备接收的路由。

    2. 检查服务链路虚拟路由和转发实例 (VRF) 的路由表。路由表应该显示正在使用 IP 地址范围。

  2. 为确保区域连接，请检查路由表中的服务链路 VRF。它应该包括 AWS 公有 IP 地址范围或默认路由。

  3. 如果您未在服务链路 VRF 中收到 AWS 公有 IP 地址范围，请检查以下各项。

    1. 从边缘路由器或 AWS Management Console 检查 AWS Direct Connect 链路状态。

    2. 如果物理链路是 UP，请从边缘路由器检查 BGP 对等互连状态。

    3. 如果 BGP 对等互连状态为 DOWN，则 ping 对等 AWS IP 地址并检查边缘路由器中的 BGP 配置。有关更多信息，请参阅 AWS Direct Connect 用户指南中的 AWS Direct Connect 故障排除和 AWS 控制台中我的虚拟接口 BGP 状态为已中断。我应该怎么办？。

    4. 如果 BGP 已建立，但您在 VRF 中看不到默认路由或 AWS 公有 IP 地址范围，请根据您的企业支持计划与 AWS 支持联系。

  4. 如果您有本地防火墙，请检查以下各项。

    1. 确认网络防火墙中允许使用服务链路连接所需要的端口。对端口 443 运行 traceroute 或使用任何其他网络故障排除工具，确认通过防火墙和您的网络设备的连接。您需要在防火墙策略中为服务链路连接配置以下端口。

      • TCP 协议 — 源端口：TCP 1025-65535；目标端口：443。

      • UDP 协议 — 源端口：TCP 1025-65535；目标端口：443。

    2. 如果为状态防火墙，请确保出站规则允许从 Outpost 的服务链路 IP 地址范围到 AWS 公有 IP 地址范围。有关更多信息，请参阅 AWS Outposts 与 AWS 区域的连接。

    3. 如果防火墙不是有状态的，请确保也允许入站流（从 AWS 公有 IP 地址范围到服务链路 IP 地址范围）。

    4. 如果您在防火墙中配置了虚拟路由器，请确保为 Outpost 和 AWS 区域之间的流量配置了适当的路由。

  5. 如果您在本地网络中配置了 NAT 以将 Outpost 的服务链路 IP 地址范围转换为您自己的公有 IP 地址，请检查以下各项。

    1. 确认 NAT 设备没有过载，并且有可用端口可以分配给新会话。

    2. 确认 NAT 设备已正确配置了地址转换。

  6. 如果问题仍然存在，请执行从边缘路由器到 AWS Direct Connect 对等 IP 地址的 MTR/traceroute/数据包捕获。根据您的企业支持计划，将测试结果共享给 AWS 支持。

与 AWS 区域连接的 AWS Direct Connect 私有虚拟接口

使用私有虚拟接口实现服务链路连接时，请参考以下核对清单对与 AWS Direct Connect 连接的边缘路由器进行故障排除。

  1. 如果 Outposts 机架和 AWS 区域之间的连接使用 AWS Outposts 私有连接功能，请检查以下各项。

    1. 从边缘路由器 ping 远程对等 AWS IP 地址，并确认 BGP 对等互连状态。

    2. 确保您的服务链路端点 VPC 和本地安装的 Outpost 之间的 AWS Direct Connect 私有虚拟接口上的 BGP 对等互连为 UP。有关更多信息，请参阅 AWS Direct Connect 用户指南中的 AWS Direct Connect 故障排除和 AWS 控制台中我的虚拟接口 BGP 状态为已中断。我应该怎么办？，以及如何通过 Direct Connect 解决 BGP 连接问题？。

    3. AWS Direct Connect 私有虚拟接口是与您所选 AWS Direct Connect 位置上边缘路由器进行的私有连接，它使用了 BGP 交换路由。您的私有虚拟私有云 (VPC) CIDR 范围将通过此 BGP 会话通告到边缘路由器。同样，Outpost 服务链路的 IP 地址范围也将通过 BGP 从边缘路由器通告到该区域。

    4. 确认与 VPC 中的服务链路私有端点关联的网络 ACL 允许相关的流量。有关更多信息，请参阅 网络就绪性核对清单。

    5. 如果您有本地防火墙，请确保防火墙制定了相应的出站规则，来允许服务链路 IP 地址范围以及位于 VPC 或 VPC CIDR 中的 Outpost 服务端点（网络接口 IP 地址）。确保 TCP 1025-65535 和 UDP 443 端口未被阻止。有关更多信息，请参阅AWS Outposts 私有连接简介。

    6. 如果防火墙不是有状态的，请确保防火墙制定了相应的规则和策略，允许从 VPC 中的 Outpost 服务端点到 Outpost 的入站流量。

  2. 如果您的本地网络中有 100 多个网络，则可以在私有虚拟接口上通过 BGP 会话将默认路由通告到 AWS。如果您不想通告默认路由，请通过汇总路由来使通告的路由数少于 100。

  3. 如果问题仍然存在，请执行从边缘路由器到 AWS Direct Connect 对等 IP 地址的 MTR/traceroute/数据包捕获。根据您的企业支持计划，将测试结果共享给 AWS 支持。

与 AWS 区域的 ISP 公共互联网连接

使用公共互联网实现服务链路连接时，请参考以下核对清单对通过 ISP 连接的边缘路由器进行故障排除。

  • 确认互联网链路已连通。

  • 确认可以从通过 ISP 连接的边缘设备访问公共服务器。

如果无法通过 ISP 链路访问互联网或公共服务器，请完成以下步骤。

  1. 检查与 ISP 路由器的 BGP 对等互连状态是否是已建立。

    1. 确认 BGP 没有抖动。

    2. 确认 BGP 正在接收并通告来自 ISP 的必要路由。

  2. 如果是静态路由配置，请检查边缘设备上的默认路由配置是否正确。

  3. 确认您是否可以使用其他 ISP 连接来连入互联网。

  4. 如果问题仍然存在，请在边缘路由器上执行 MTR/traceroute/数据包捕获。将结果分享给 ISP 的技术支持团队，以便进一步排除故障。

如果无法通过 ISP 链路访问互联网和公共服务器，请完成以下步骤。

  1. 确认是否可以从边缘设备访问您在 Outpost 主区域中的任何可公开访问的 EC2 实例或负载均衡器。您可以使用 ping 或 telnet 来确认连接，然后使用 traceroute 来确认网络路径。

  2. 如果您使用 VRF 来分隔网络中的流量，请确认服务链路 VRF 是否有路由或策略可以定向传入和传出 ISP（互联网）和 VRF 的流量。请参阅以下检查点。

    1. 与 ISP 连接的边缘路由器。检查边缘路由器的 ISP VRF 路由表，以确认服务链路 IP 地址范围是否存在。

    2. 与 Outpost 连接的客户本地网络设备。检查 VRF 的配置，以确保正确配置了服务链路 VRF 和 ISP VRF 之间连接所需的路由和策略。通常，从 ISP VRF 向服务链路 VRF 发送一条默认路由，来用于传输到互联网的流量。

    3. 如果您在连接到 Outpost 的路由器中配置了基于来源的路由，请确认配置是否正确。

  3. 确保对本地防火墙进行了配置，以允许从 Outpost 服务链路 IP 地址范围到公有 AWS IP 地址范围的出站连接（TCP 1025-65535 和 UDP 443 端口）。如果防火墙不是有状态的，请确保还配置了与 Outpost 的入站连接。

  4. 确保在本地网络中配置 NAT，以将 Outpost 的服务链路 IP 地址范围转换为公有 IP 地址。此外，也请确认以下各项。

    1. NAT 设备没有过载，并且有可用端口可以分配给新会话。

    2. NAT 设备已正确配置了地址转换。

如果问题仍然存在，请执行 MTR/traceroute/数据包捕获。

  • 如果结果显示数据包在本地网络中丢失或被阻止，请联系您的网络或技术团队以获取更多指导。

  • 如果结果显示数据包在 ISP 的网络中丢失或被阻止，则请与 ISP 的技术支持团队联系。

  • 如果结果未显示任何问题，请收集所有测试的结果（例如 MTR、telnet、traceroute、数据包捕获和 BGP 日志），然后根据您的企业支持计划来联系 AWS 支持部门。

Outposts 位于两个防火墙设备后面

如果将 Outpost 放在一对高可用性同步防火墙或两个独立防火墙后面，可能会出现服务链路的非对称路由。这意味着入站流量可以通过防火墙 1，而出站流量则通过防火墙 2。使用以下清单来识别服务链路的潜在非对称路由，尤其是在以前正常运行的情况下。

  • 核实企业网络的路由设置最近是否有任何更改或正在进行的维护，这些更改或维护可能导致服务链路通过防火墙的非对称路由。

    • 使用防火墙流量图检查是否有与服务链路问题起始时间一致的流量模式变化。

    • 检查是否存在部分防火墙故障或防火墙对分裂的情况，这些情况可能导致防火墙之间不再同步连接表。

    • 检查企业网络中是否存在与服务链路问题起始时间一致的链路中断或最近的路由更改（OSPF/ISIS/EIGRP 指标更改、BGP 路由映射更改）。

  • 如果您使用公共互联网连接作为通往主区域的服务链路，则服务提供商的维护可能会导致服务链路通过防火墙进行非对称路由。

    • 检查通往 ISP 的链路的流量图，查看是否有与服务链路问题起始时间一致的流量模式变化。

  • 如果您使用 AWS Direct Connect 连接作为服务链路，则 AWS 计划维护可能会触发服务链路的非对称路由。

    • 检查是否有 AWS Direct Connect 服务的计划维护通知。

    • 请注意，如果您有冗余的 AWS Direct Connect 服务，则可以在维护条件下主动测试 Outposts 服务链路在每条可能的网络路径上的路由。这使您可以测试某项 AWS Direct Connect 服务的中断是否会导致服务链路的非对称路由。端到端网络连接的 AWS Direct Connect 部分的弹性可以通过 AWS Direct Connect Resiliency with Resiliency Toolkit 进行测试。有关更多信息，请参阅测试 AWS Direct Connect Resiliency with Resiliency Toolkit – 失效转移测试。

在完成前面的检查清单并确定服务链路的非对称路由可能是根本原因后，您可以采取一些进一步的措施：

  • 通过恢复任何企业网络变更或等待提供商完成计划维护，恢复对称路由。

  • 登录一个或两个防火墙，从命令行清除所有流的所有流状态信息（如果防火墙供应商支持）。

  • 暂时过滤掉通过其中一个防火墙的 BGP 公告，或关闭一个防火墙上的接口，以强制通过另一个防火墙进行对称路由。

  • 依次重启每个防火墙，以消除防火墙内存中服务链路流量流态跟踪的潜在损坏。

  • 要求防火墙供应商验证或放宽对源于端口 443 并以端口 443 为目标的 UDP 连接的 UDP 流状态的跟踪。