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中也可以直接看到它。

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 V M-CFG. Er ror : 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

Tungsten Fabric入門寶典系列文章——

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

Tungsten Fabric入門寶典丨8個典型故障及排查Tips

TF元件的七種“武器”

相關文章