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

Tungsten Fabric入门宝典系列文章，来自技术大牛倾囊相授的实践经验，由TF中文社区为您编译呈现，旨在帮助新手深入理解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 showcurl control-ip:8083/Snh_ShowRouteReq
ist.py ctr route neicurl control-ip:8083/Snh_BgpNeighborReq
ist.py vr intfcurl vrouter-ip:8085/Snh_ItfReq
ist.py vr vrfcurl vrouter-ip:8085/Snh_VrfListReq
ist.py vr route -v vrf-idcurl vrouter-ip:8085/Snh_Inet4UcRouteReq?vrf_index=vrf-id

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

ist.py ctr ifmap tablecurl control-ip:8083/Snh_IFMapNodeTableListShowReq
ist.py ctr ifmap table virtual-networkcurl control-ip:8083/Snh_IFMapTableShowReq?table_name=virtual-networkist.py ctr ifmap clientcurl control-ip:8083/Snh_IFMapPerClientLinksShowReq
ist.py ctr ifmap nodecurl control-ip:8083/Snh_IFMapLinkTableShowReq
ist.py ctr ifmap linkcurl control-ip:8083/Snh_IFMapNodeShowReqist.py vr ifmapcurl vrouter-ip:8085/Snh_ShowIFMapAgentReq

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

ist.py vr uvecurl vrouter-ip:8085/Snh_SandeshUVETypesReq
ist.py vr uve VrouterStatsAgentcurl vrouter-ip:8085/Snh_SandeshUVECacheReq?x=VrouterStatsAgentist.py ctr tracecurl control-ip:8083/Snh_SandeshTraceBufferListRequest
ist.py ctr trace BgpTraceBufcurl control-ip:8083/Snh_SandeshTraceRequest?x=BgpTraceBuf
ist.py vr tracecurl vrouter-ip:8085/Snh_SandeshTraceBufferListRequest
ist.py vr trace Flowcurl 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信息创建。

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

controller节点上的contrail-status
config-api, control需要处于“活动”状态
contrail-kube-manager节点上的contrail-status处于“活动”状态
此进程将从kube-apiserver检索信息，并在config-api上创建pod /负载均衡器等
vrouter节点上的contrail-status
vrouter-agent需要处于“活动”状态
如果使用独立的kubernetes yaml，则在vrouter注册和vrouter-agent重新启动之间的竞争条件方面存在已知限制。重新启动control可能会解决此问题。

 # docker restart control_control_1

如果一切都很好，

/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

Tungsten Fabric入门宝典系列文章——
1.首次启动和运行指南
2. TF组件的七种“武器”
3. 编排器集成
4.关于安装的那些事（上）
5.关于安装的那些事（下）
6.主流监控系统工具的集成
7.开始第二天的工作

Tungsten Fabric 架构解析系列文章——
第一篇：TF主要特点和用例
第二篇：TF怎么运作
第三篇：详解vRouter体系结构
第四篇：TF的服务链
第五篇：vRouter的部署选项
第六篇：TF如何收集、分析、部署？
第七篇：TF如何编排
第八篇：TF支持API一览
第九篇：TF如何连接到物理网络
第十篇：TF基于应用程序的安全策略