网络问题排查

本页详细介绍了如何排查常见网络问题。

网络引导问题排查

本部分展示了在完成网络引导启动流程时可能会遇到的一些常见错误。

配置生成错误

为了完成网络安装，网络配置文件会安装在引导加载程序机器上。如果您遇到配置生成错误，请检查位于 /root/cellcfg 的 YAML 文件，找到失败的交换机配置。

引导在阶段 1 ping 处停滞

如果网络启动过程在阶段 1 ping 处停滞，请按以下步骤查找问题：

从引导日志中获取生成的交换机配置位置：/tmp/network-bootstrap/ID
通过查看具有 IP 地址的交换机配置文件，找到停滞的交换机。
登录交换机并检查操作日志。

引导在阶段 2 ping 处停滞

如果网络引导过程在第 2 阶段 ping 处停滞，请按以下步骤查找问题：

从引导日志中获取生成的交换机配置位置：/tmp/network-bootstrap/ID
通过查看具有管理 IP 地址的交换机配置文件，找到停滞的交换机。
检查管理交换机配置，以发现管理网络中可能存在的任何访问问题。

网络第 2 天协调问题排查

概览

在交换机协调期间，GDC 使用 Cisco NX-OS 提供的配置替换功能，将交换机中的运行配置替换为全新的配置。配置替换操作在内部执行的步骤如下：

计算当前正在运行的配置与用户提供的配置之间的差异。
生成一个补丁文件，其中包含运行配置与输入配置之间的差异。
对补丁文件执行语义验证。
应用补丁文件。
通过将运行配置与输入配置进行比较，验证补丁文件是否已正确添加。否则，将恢复为之前的配置
系统会启动一个计时器，在该计时器结束之前，必须运行命令“configure replace commit”，否则系统会恢复为旧配置。

之前的每个步骤都可能会失败，但最常发生在第 3 步、第 4 步和第 1 步。以下是一些可用于排查配置替换错误的技巧。

常见问题排查步骤

检查开关的总体状态

在根管理员服务器中运行 kubectl describe aggswitch/mb-ab-aggsw01 -n gpc-system（将开关名称替换为所需的开关名称）

如果上次配置替换失败，根管理员集群中的交换机 Kubernetes 对象会在对象说明中显示执行和验证日志。

检查上次配置替换操作的状态

在交换机控制台中运行 show config-replace status：

状态会提供以下信息

总体状态，例如“完成”“失败”等。
配置替换是否已提交或正在等待提交。
上次配置替换操作的开始时间和结束时间

检查上次配置替换操作应用了哪些配置

在 Switch 控制台中运行 show config-replace log exec。

配置替换执行日志显示了在应用由配置替换操作确定为补丁配置的配置（即运行配置与输入配置之间的差异）时生成的日志。

请注意，这些日志有时会包含错误，但配置替换操作会忽略这些错误，因此这些错误不会导致整个配置替换失败。 除非错误是“执行补丁”部分中执行日志的最后一行，否则它很可能不是配置替换失败的原因。

检查上次配置替换操作的验证是否成功

在 Switch 控制台中运行 show config-replace log verify。

在配置替换执行步骤之后，配置替换操作会将交换机的新运行配置与输入配置进行比较。这些配置需要保持一致。如果未执行，则配置替换失败，并将配置回滚到之前的配置。

验证日志包含两个部分。

Configuration To Be Added Missing in Running-config：此列表显示了输入配置中存在但新运行配置中不存在的配置
Configuration To Be Removed Present in Running-config：此列表列出了新运行配置中存在但输入配置中不存在的配置

检查交换机上运行的所有命令

在交换机控制台中运行 show accounting log start-time 2022 Sep 13 20:00:00（将开始时间替换为所需的开始时间）

会计日志会显示在交换机上运行的每个命令。这些日志有助于了解通过 NXAPI 或手动在交换机上运行了哪些命令。这些信息还可以让您了解每次配置替换操作的具体运行时间以及运行次数。

检查已向交换机发出了哪些 NX-API 调用以及从何处发出的

在 Switch 控制台中运行 show nxapi-server logs

NX-API 日志显示与对交换机进行的 NXAPI 调用相关的日志。由于我们的自动化堆栈会出于多种原因（包括运行配置替换）向交换机发出 NXAPI 调用，因此此功能有助于查看发出了哪些 NXAPI 调用以及这些调用来自何处。

互连问题排查

互连 API 概览

Interconnect API 用于为 GDC 数据中心单元配置外部连接。互连有 3 种

数据中心互连 (DCI)：通过数据平面边界 Leaf 交换机从一个 GDC 数据中心互连到另一个 GDC 数据中心。
客户对等互连 (CPI)：通过数据平面边界叶交换机从 GDC 数据中心到 ORG 网络的互连。
网络运营中心 (NOC)：通过数据平面边界叶交换机和管理聚合交换机，从 GDC 数据中心互连到网络运营中心。

存在以下 API 对象：

InterconnectLink：此 API 对象定义了连接到外部交换机的物理端口。
InterconnectAttachment：此 API 对象定义了配置的 InterconnectLink 之上的附件。每个附件中包含的信息定义了以下内容：
1. 互连类型
2. BGP 信息
3. VLAN ID 信息
4. 已配置的路由政策
RoutePolicy：此 API 对象用于对与互联 BGP 对等体共享路由所用的政策进行建模。

问题排查

验证 InterconnectLink 和 InterconnectAttachment 状态

InterconnectLink 和 InterconnectAttachment API 对象会公开大量信息，这些信息有助于了解当前状态。

InterconnectLink：对于连接到外部交换机的每个物理端口，系统会公开以下信息。
1. Up：端口是处于启动状态还是关闭状态。
2. DownReason：端口关闭的原因。
InterconnectAttachment：系统会针对配置的每个互联网络连接公开以下信息。
1. BGPStatus：BGP 会话的状态，例如“Up”或“Down”。
2. UpTime：BGP 会话上次启动的时间戳。
3. PrefixCounters：显示前缀总数 Received、Sent 和 Withdrawn 的计数器。

验证路由政策

RoutePolicy 定义了前缀列表以及要采取的操作，例如“允许”或“拒绝”。列出与 InterconnectAttachment 资源关联的所有路由政策，以验证 IP 地址是否属于有效的 RoutePolicy。

验证防火墙上边界 Leaf 交换机上的 BGP 路由前缀/流量

互连数据路径还会经过两个 PANW 防火墙：入侵检测和防御系统 (IDPS) 防火墙和外围防火墙。即使路由前缀是从 BGP 会话中获知的，防火墙也可能会将其丢弃。

验证各种 `VRFs` 上获知的路由前缀

外部流量在汇总交换机上遍历多个 VRF，因为它会通过不同的防火墙。检查通过这些 VRF 获知的 BGP 路由前缀是否指向防火墙丢弃的路由前缀/流量。

所有外部流量都会根据边界叶交换机上流量的源集群或目标集群放入外部 VRF *-external-vrf 中。示例：root-external-vrf 的流量的来源或目的地为根管理员集群。

流量通过 IDPS 防火墙后，会被放入以下互连 VRF 之一：

oc-vrf
dci-vrf
cp-vrf

对于发往 NOC 的流量，在到达 octransit-vrf 之前，还有一个额外的边界防火墙。

登录到边界 Leaf 交换机，然后使用以下命令显示在各种 VRF 上学习到的路由前缀：

show bgp vrf <vrf_name> all

其中，vrf_name 可以是任何 VRF。

ANG BGP 问题排查

集群 kubeconfig 文件

确保您具有以下 KUBECONFIG_FILE 值，以便检查对象：

ROOT_ADMIN_KUBECONFIG：根管理员集群的 kubeconfig 文件。
ORG_ADMIN_KUBECONFIG：组织管理员集群的 kubeconfig 文件。
ORG_SYSTEM_KUBECONFIG：组织系统集群的 kubeconfig 文件。
ORG_USER_KUBECONFIG：组织用户集群的 kubeconfig 文件。

集群卡在预配状态

验证 NodePool 对象是否已准备就绪。
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get nodepools -A
```
如果节点池对象未创建或未就绪，请检查 NodePoolClaim 和节点连接。

验证 ClusterBGPPeer 对象是否已准备就绪。

验证是否已为 flat-ip-bgp-x、lb-bgp-x 和 node-x 创建 ClusterBGPPeer 对象：

kubectl --kubeconfig KUBECONFIG_FILE \
    get clusterbgppeers -A
...
ORG_NAME-system-cluster   flat-ip-bgp-peer-0                   16h
ORG_NAME-system-cluster   lb-bgp-peer-0                        21h
ORG_NAME-system-cluster   node-10.251.100.10-peer-10.0.224.0   21h

如果未创建对象，请检查 NetworkGatewayGroup 和 BGPPeer 对象。

验证 BGPSession 是否已启动。
```
kubectl --kubeconfig KUBECONFIG_FILE \
    get bgpsessions -A
```
如果 BGP 会话未启动，请参阅 BGP 会话未建立。

BGP 会话未建立

检查了 `TORSwitchInternal` 中的 `EBGPNeighbor`

检查 ClusterBGPRouter 以获取每个接口的对等 TOR 交换机。

ORG_NAME ClusterBGPRouter 的接口用于对等连接 ORG_NAME 的所有集群。

 apiVersion: network.private.gdc.goog/v1alpha1
 kind: ClusterBGPRouter
 metadata:
 labels:
     clusterbgpreconciler.system.private.gdc.goog/overlay-network: external
 name: external-vrf-cluster-bgp-router
 namespace: ORG_NAME
 spec:
 clusterASN: 64513
 interfaces:
 - ip: 10.0.252.48
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw01
 - ip: 10.0.252.49
   switchMetadata:
   rackName: alatl14-aa
   switchRef:
       kind: TORSwitch
       name: alatl14-aa-torsw02
 networkASN: 65014

对于每个 TORSwitchInternal，检查 spec.ebgpNeighbors 以查看是否已配置所有 ClusterBGPPeer 对象。

在 TOR 交换机上调试 BGP 会话

通过 SSH 连接到对等 TOR 交换机之一。

验证 ORG_NAME 的 ANG BGP 邻居：

> sh run bgp
router bgp 65014
...
  vrf ORG_NAME-external-vrf
    ...
    neighbor 10.251.100.3
      inherit peer ANG
      update-source loopback200
    neighbor 10.251.100.4
      inherit peer ANG
      update-source loopback200
    ...
  vrf ORG_NAME-internal-vrf
    ...
    neighbor 172.20.128.5
      inherit peer ANG
      update-source loopback100
    neighbor 172.20.128.6
      inherit peer ANG
      update-source loopback100
  ...

检查 BGP 会话状态：

> sh bgp ses vrf ORG_NAME-external-vrf
> sh bgp ses vrf ORG_NAME-internal-vrf

查看 BGP 日志：

> debug ip bgp all
> no debug ip bgp all (disable log mode)

使用 bash 移动调试：

> run bash
> sudo tcpdmp -i any port 179 -vvv

网络问题排查 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。