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

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

AWS Outposts 机架网络故障排除清单

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

虚拟LANs。

与 Outpost 网络设备的连接

检查连接到 Out BGP post 网络设备的客户本地网络设备的对等互连状态。如果对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. 确认远程自治系统编号（OutpostASN）配置正确。

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

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

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

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

    1. BGP和TCP调试日志

    2. BGP日志

    3. 数据包捕获

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

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

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

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

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

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

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

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

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

    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已建立，但您在中看不到默认路由或 AWS 公有 IP 地址范围VRF，请使用您的企业 AWS 支持计划与 Support 联系。

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

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

      • TCP协议 — 源端口：TCP1025-65535，目标端口：443。

      • UDP协议 — 源端口：TCP1025-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. 如果问题仍然存在，请执行MTR从边缘路由器到 AWS Direct Connect 对等 IP 地址的/traceroute/数据包捕获。使用您的企业 AWS 支持计划与 Support 共享测试结果。

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

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

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

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

    2. 确保通过服务链接端点VPC和本地安装的 Out BGP post 之间的 AWS Direct Connect 私有虚拟接口进行对视。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. 确认与您的服务链接私有端点ACLs关联的网络VPC允许相关流量。有关更多信息，请参阅 网络就绪性核对清单。

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

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

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

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

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

使用公共互联网进行服务链路连接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. 如果您使用VRFs分隔网络中的流量，请确认服务链接VRF具有将流量定向进出ISP（互联网）的路由或策略，以及VRF。请参阅以下检查点。

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

    2. 与 Outpost 连接的客户本地网络设备。检查的配置，VRFs并确保服务链路与之间连接所需的路由VRF和策略配置ISPVRF正确。通常，默认路由从服务链接发送ISPVRF到互联网VRF的流量。

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

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

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

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

    2. NAT设备已正确配置为执行地址转换。

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

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

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

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

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

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

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

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

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

    • 检查公司网络中是否存在与服务链路问题开始时出现的链路关闭或最近的路由更改（OSPFISIS//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流量状态的跟踪。