Tungsten Fabric入门宝典丨8个典型故障及排查Tips

Tungsten Fabric

修改于 2020-06-05 17:34:34

7090

修改于 2020-06-05 17:34:34

文章被收录于专栏：Tungsten Fabric中文社区 Tungsten Fabric中文社区Tungsten Fabric中文社区

Tungsten Fabric入门宝典系列文章，来自技术大牛倾囊相授的实践经验，由TF中文社区为您编译呈现，旨在帮助新手深入理解TF的运行、安装、集成、调试等全流程。如果您有相关经验或疑问，欢迎与我们互动，并与社区极客们进一步交流。更多TF技术文章，请点击公号底部按钮＞学习＞文章合集。

作者：Tatsuya Naganawa 译者：TF编译组

在使用vRouter时，可能会出现某些情况，使得路由无法正常工作。

我收集了最常见的问题和步骤来研究vRouter的路由行为。

有两种方法可以解决问题，一是查看相关配置的详细信息，二是查看控制平面和vRouter的操作状态。

对于前者来说，最有用的是contrail-api-cli，而对于后者，最有用的是ist.py（特别是对于remote-debug而言），下面我使用这种格式进行描述。

注意：如果没有这些工具，你还可以使用curl来达到此目的。

例如，当需要以下命令时，

source /etc/kolla/kolla_toolbox/admin-openrc.sh
contrail-api-cli --host x.x.x.x ls -l virtual-network
contrail-api-cli --host x.x.x.x cat virtual-network/xxxx-xxxx-xxxx-xxxx

下述的命令将收集相同的信息。

source /etc/kolla/kolla_toolbox/admin-openrc.sh
openstack token issue
curl -H 'x-auth-token: tokenid' x.x.x.x:8082/virtual-networks
curl -H 'x-auth-token: tokenid' x.x.x.x:8082/virtual-network/xxxx-xxxx-xxxx-xxxx

同样，ist.py也可以用各种curl命令替换。以下是最常见情况中的curl命令。（cli更令人难忘）

ist.py ctr route show
   curl control-ip:8083/Snh_ShowRouteReq
ist.py ctr route nei
   curl control-ip:8083/Snh_BgpNeighborReq
ist.py vr intf
   curl vrouter-ip:8085/Snh_ItfReq
ist.py vr vrf
   curl vrouter-ip:8085/Snh_VrfListReq
ist.py vr route -v vrf-id
   curl vrouter-ip:8085/Snh_Inet4UcRouteReq?vrf_index=vrf-id

此外，ifmap信息（与vRouter的设备配置类似，例如接口、vrf、虚拟机等）对于查看配置内容也很有用。

可以通过以下的命令查看：

ist.py ctr ifmap table
   curl control-ip:8083/Snh_IFMapNodeTableListShowReq
ist.py ctr ifmap table virtual-network
   curl control-ip:8083/Snh_IFMapTableShowReq?table_name=virtual-network

ist.py ctr ifmap client
   curl control-ip:8083/Snh_IFMapPerClientLinksShowReq
ist.py ctr ifmap node
   curl control-ip:8083/Snh_IFMapLinkTableShowReq
ist.py ctr ifmap link
   curl control-ip:8083/Snh_IFMapNodeShowReq

ist.py vr ifmap
   curl vrouter-ip:8085/Snh_ShowIFMapAgentReq

注意：使用ist.py时，每个目标都有两个通用属性uve和trace。这些也可以用于进行详细的状态检查。

ist.py vr uve
 curl vrouter-ip:8085/Snh_SandeshUVETypesReq
ist.py vr uve VrouterStatsAgent
 curl vrouter-ip:8085/Snh_SandeshUVECacheReq?x=VrouterStatsAgent

ist.py ctr trace
 curl control-ip:8083/Snh_SandeshTraceBufferListRequest
ist.py ctr trace BgpTraceBuf
 curl control-ip:8083/Snh_SandeshTraceRequest?x=BgpTraceBuf
ist.py vr trace
 curl vrouter-ip:8085/Snh_SandeshTraceBufferListRequest
ist.py vr trace Flow
 curl vrouter-ip:8085/Snh_SandeshTraceRequest?x=Flow

UVE（用户可见实体）是Tungsten Fabric每个组件都会使用的一种度量标准，通常可以从analytics/uves API中看到。在每个组件的introspect中也可以直接看到它。

https://tungsten.io/operational-state-in-the-opencontrail-system-uve-user-visible-entities-through-analytics-api/

Trace是每个组件的跟踪日志，存储在每个进程的内存中。通过使用此选项，可以转储该trace的内存。

x. 一些VM-to-VM的报文无法到达其它节点

要对此进行排查，首先需要搞清楚这是控制平面问题还是数据平面问题。对于控制平面问题，以下命令将是最有用的。

 # ist.py ctr route show
 # ist.py vr intf
 # ist.py vr vrf
 # ist.py vr route -v (vrf id)

如果路由看起来是好的，则可以先利用tcpdump查看报文是否到达了目标vrouter。

 # tcpdump -i any -nn udp port 6635 or udp port 4789 or proto gre or icmp # for physical NIC
 # tcpdump -i any -nn icmp # for tap device

当报文到达目标vRouter后，请检查

# flow -l

以查看它是否被flow动作所丢弃。

例如，动作: D(Policy), D(SG)表示已被网络策略（network-policy）或安全组（security-group）丢弃。要进一步查看flow动作，以下命令将有所帮助。

# ist.py vr intf -f text
 # ist.py vr acl

注意：要查看报文丢弃的原因，dropstats命令可能包含更多信息。

 # watch -n 1 'dropstats | grep -v -w 0'
 # watch -n 1 'vif --get 0 --get-drop-stats'
 # watch -n 1 'vif --get n --get-drop-stats' (n is vif id)
 # ping -i 0.2 overlay-ip # this can be used to see specific dropstats counter is incrementing because of that packets

x. 无法从外部节点访问VM

使用以下命令

# flow -l

以查看此报文的flow动作。

如果动作是D(SG)，则它是被安全组（security-group）丢弃，因此需要进行更改以允许外部访问（openstack ingress规则的默认设置是仅允许VM-to-VM的访问）。

x. kubernetes service / ingress无法启动，带有浮动IP的SNAT无法正常工作

由于这些是由svc-monitor设置的，因此可以首先检查

 # tail -f /var/log/contrail/contrail-svc-monitor.log

以查看是否能看到一些错误。

一种情况是日志中有“No vRouter is availale”，所以这些服务无法被启动。由于某种原因，从vRouter到analytics-api的NodeStatus导致了“非功能性”（Non-Functional），因此需要从vRouter端进行调查。

如果svc-monitor正常运行，则需要调查负载均衡器对象的行为。

当使用服务时，它将添加ecmp路由以到达应用程序，因此这些命令可用于调查控制平面（VM-to-VM路由步骤相同）。

 # ist.py ctr route show
 # ist.py vr route -v (vrf-id)

使用ingress或SNAT时，它将在vRouter容器的linux命名空间内启动haproxy进程。要调查详细信息，你可以尝试使用这些命令，以查看那些名称。

 # docker exec -it vrouter-agent bash
   # ip netns
   # ip netns exec vrouter-xxx ip -o a
   # ip netns exec vrouter-xxx ip route
   # ip netns exec vrouter-xxx iptables -L -n -v -t nat
 # tail -f /var/log/messages # haproxy log is logged

由于ingress service和SNAT也使用vRouter路由，因此这些命令还有助于查看这些service的前缀是否已导出到vRouter的路由表。

 # ist.py ctr route show
 # ist.py vr vrf
 # ist.py vr route -v (vrf-id)

x. 服务链无法正常工作

服务链的使用将更改vRouter路由表，因此首先可以使用以下命令查看路由实例是否已成功创建，以及ServiceChain路由是否已正确导入。

 # ist.py ctr route summary
 # ist.py ctr route show
 # ist.py ctr route show -p ServiceChain
 # ist.py ctr sc

如果控制平面运行良好，则需要以与VM-to-VM流量相同的方式调查数据平面行为（安全组也可以阻止服务链流量，因此也请从外部流量检查服务链的情况）。

 # tcpdump -i any -nn udp port 6635 or udp port 4789 or proto gre or icmp
 # ist.py vr intf
 # ist.py vr vrf
 # ist.py vr route -v (vrf-id)
 # flow -l

x. 分布式SNAT不能很好地工作

该功能由vRouter上的ACL实现，因此要研究此功能，以下的命令很有用。

 # ist.py vr intf -f text

如果icmp正常运行，而tcp / udp无法正常运行，请检查端口列表。

x. cni返回Poll VM-CFG 404错误

在kubernetes部署中，cni有时会返回此错误，并且不会将IP分配给pod。（这在诸如以kubectl描述pod的各个地方都可以看到）

networkPlugin cni failed to set up pod "coredns-5644d7b6d9-p8fkk_kube-system" network: Failed in Poll VM-CFG. Error : Failed in PollVM. Error : Failed HTTP Get operation. Return code 404

此消息是通用错误的描述，会由多种原因引起。

在内部创建pod时，cni尝试从vrouter-agent接收其IP，后者又利用XMPP从control进程中接收该IP。

基于virtual-machine-interface信息，该信息由kube-manager从kube-apiserver信息创建。

因此，要解决此问题，需要完成几个步骤。

1. controller节点上的contrail-status

config-api, control需要处于“活动”状态

2. contrail-kube-manager节点上的contrail-status处于“活动”状态

此进程将从kube-apiserver检索信息，并在config-api上创建pod /负载均衡器等

3. vrouter节点上的contrail-status

vrouter-agent需要处于“活动”状态

4. 如果使用独立的kubernetes yaml，则在vrouter注册和vrouter-agent重新启动之间的竞争条件方面存在已知限制。重新启动control可能会解决此问题。

 # docker restart control_control_1

5. 如果一切都很好，

/var/log/contrail/contrail-kube-manager.log
/var/log/contrail/api-zk.log
/var/log/contrail/contrail-vrouter-agent.log
/var/log/contrail/cni/opencontrail.log <- cni log

这几项需要进一步调查……

根本原因可能是xmpp问题、underlay问题、/etc/hosts问题等等

x. 磁盘已满

如果磁盘大小为50GB，则安装后一周左右可能就会占满。发生这种情况时，需要删除analytics数据，并需要重新启动analytics数据库。

[check analytics db size]
du -smx /var/lib/docker/volumes/analytics_database_analytics_cassandra/_data/ContrailAnalyticsCql

[if it is large, remove by this]
rm -rf /var/lib/docker/volumes/analytics_database_analytics_cassandra/_data/ContrailAnalyticsCql
docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml down
docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml up -d

为避免将来出现此问题，可以使用此knob。

echo 'ANALYTICS_STATISTICS_TTL=2' >> /etc/contrail/common_analytics.env
docker-compose -f /etc/contrail/analytics/docker-compose.yaml down
docker-compose -f /etc/contrail/analytics/docker-compose.yaml up -d

x. analytics cassandra状态检测到关闭

如果在contrail-status中看到此错误，则表明analytics cassandra运行不正常。

== Contrail database ==
nodemgr: initializing (Cassandra state detected DOWN.)

如果设置了JVM_EXTRA_OPTS: "-Xms128m -Xmx1g"，则最有可能的原因是Java的OutOfMemory错误，因此可以将其更新为类似。

JVM_EXTRA_OPTS: "-Xms128m -Xmx2g"

在/etc/contrail/common.env中，并可以重新启动analytics数据库。

docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml down
docker-compose -f /etc/contrail/analytics_database/docker-compose.yaml up -d

·END·

Tungsten Fabric入门宝典系列文章——

Tungsten Fabric 架构解析系列文章——