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

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

AWS 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 支持计划与 Support 共享测试结果。

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

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

使用公共虚拟接口进行服务链路连接 AWS Direct Connect 时，使用以下清单对与之连接的边缘路由器进行故障排除。

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

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

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

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

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

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

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

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

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

  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 支持计划与 Support 共享测试结果。

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

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

  1. 如果 Outpost 机架和 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 支持计划与 Support 共享测试结果。

与 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 地址范围到公有 IP 地址范围的出站连接（TCP 1025-65535 和 UDP 443 端口）。 AWS 如果防火墙不是有状态的，请确保还配置了与 Outpost 的入站连接。

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

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

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

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

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

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

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

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

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

  • 验证公司网络的路由设置最近是否有任何更改或持续维护，这些更改或维护可能导致服务链路通过防火墙进行非对称路由。

    • 使用防火墙流量图表来检查流量模式的变化，这些变化是否与服务链接问题开始时一致。

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

    • 检查公司网络中是否出现链路中断或最近的路由更改（OSPF/ISIS/EIGRP 指标更改、BGP 路由映射更改），这些更改与服务链路问题的开始一致。

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

    • 查看流量图表中是否有指向您的 ISP 的链接，以了解与服务链接问题开始时相应的流量模式变化。

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

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

    • 请注意，如果您有冗余 AWS Direct Connect 服务，则可以在维护条件下主动测试 Outposts 服务链接在每条可能的网络路径上的路由。这使您可以测试某项服务的中断是否会导致 AWS Direct Connect 服务链路的非对称路由。 end-to-end 网络连接 AWS Direct Connect 部分的弹性可以通过 “弹性与 AWS Direct Connect 弹性” 工具包进行测试。有关更多信息，请参阅使用 AWS Direct Connect 弹性工具包测试弹性-故障转移测试。

在仔细阅读了前面的清单并确定了服务链路的非对称路由可能是根本原因之后，您可以采取许多进一步的措施：

  • 恢复对称路由，方法是恢复对称路由，方法是恢复对称路由，方法是恢复对称路由。

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

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

  • 依次重新启动每个防火墙，以消除防火墙内存中服务链路流量的流量状态跟踪中可能出现的损坏。

  • 请您的防火墙供应商验证或放松对源自端口 443 且目的地为端口 443 的 UDP 连接的 UDP 流状态的跟踪。