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 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

  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.首次启动和运行指南

  1. TF组件的七种“武器”
  2. 编排器集成
  3. 关于安装的那些事（上）
  4. 关于安装的那些事（下）
  5. 主流监控系统工具的集成
  6. 开始第二天的工作

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

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

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