学习
实践
活动
专区
工具
TVP
写文章
专栏首页Tungsten Fabric中文社区TF虚拟网络流量排错:在正确的时刻使用正确的工具
原创

TF虚拟网络流量排错:在正确的时刻使用正确的工具

我们总是希望一切都能如期进行。不过残酷的现实是,大多数时候,总会出现问题。

在排除网络故障时,第一个碰到的问题总是这个——“流量在哪里?”

事情变得有点“复杂”

对于虚拟网络来说,也依然如此!即使是在Tungsten Fabric集群内部,按理说,我们在故障排除环节的第一步,也会进行某种流量嗅探或流量识别。

那么……和传统的物理网络有什么不同呢?从概念上讲,没有什么不同……但是,在实践当中,事情会更复杂一些。我们所说的复杂,并不是指难以理解无从下手。所谓复杂,是指有更多的变数在起作用,但这并不一定意味着故障排除会非常难。相反,从另一个角度来看,这意味着我们可以使用更多的工具来更好地了解网络中发生的事情。

回到Tungsten Fabric集群,或者说是一般的虚拟环境,我们的目标是检查/监控进出某个虚拟机的流量。与传统的物理设备相比,如前所述,环境更加复杂。有了物理设备,就像有了一台一体化设备。但当移动到虚拟环境时,一体化设备就不存在了!你有物理服务器(计算)和连接到DC架构的NIC,你有管理程序,最后,你有虚拟机。虚拟机的流量会经过所有这些层次。在每个层次,都有工具可以用来检查/监控流量。这就是我说的“更复杂的场景”的意思,但也是为什么说,从另一个角度来看,这意味着有很多有用的武器可以满足我们的需求。

因此,了解在每个层面可以使用哪些工具是很重要的。我们必须掌握复杂性,并利用它!

让我们用一个例子来解决这个问题。例如有一个IP为192.168.10.3的虚拟机(VM1),这个虚拟机运行在compute1上。在compute2上,有另一个IP为192.168.10.4的虚拟机(VM2)。让我们从VM1 ping到VM2:

$ ping 192.168.10.4
PING 192.168.10.4 (192.168.10.4): 56 data bytes
64 bytes from 192.168.10.4: seq=0 ttl=64 time=44.812 ms
64 bytes from 192.168.10.4: seq=1 ttl=64 time=32.076 ms
64 bytes from 192.168.10.4: seq=2 ttl=64 time=6.418 ms
^C
--- 192.168.10.4 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 6.418/27.768/44.812 ms
$

Ping成功了!现在,我们要做的是识别和监控这些流量。

三个层次,三套工具

首先,正如之前预想的那样,我们必须掌握复杂性。在处理Tungsten Fabric集群时,我们可以识别3个层次:VNF,hypervisor和vRouter。

现在来看一下整个流程。

在VNF层面,我们拥有VNF提供的所有工具,可能有类似tcpdum的命令,或者如果VNF是一个防火墙,有一些东西可以查看流表内容。由于这个级别取决于厂商/VNF,这里不打算详细介绍。

再来看看vRouter。vRouter是Tungsten Fabric解决方案的核心,它提供并管理计算节点内部的所有虚拟网络。此外,它还提供了一系列不错的工具,可以用来了解集群内的流量是如何流动的。

要访问这套工具,首先要访问vRouter容器,通过连接到计算节点并使用知名的docker命令来实现。

[root@compute1 ~]# docker ps | grep vrouter
c1f441949cb5        hub.juniper.net/contrail/contrail-vrouter-agent:1911.31       "/entrypoint.sh /usr…"   8 days ago          Up 8 days                               vrouter_vrouter-agent_1
4333e1b1cf92        hub.juniper.net/contrail/contrail-nodemgr:1911.31             "/entrypoint.sh /bin…"   8 days ago          Up 8 days                               vrouter_nodemgr_1
[root@compute1 ~]# docker exec -it vrouter_vrouter-agent_1 bash
(vrouter-agent)[root@compute1 /]$

一旦我们进行到这里,就可以开始寻找流量了。

首先,确定VM的虚拟机接口(vif)。通过使用“vif”实用程序,匹配端口IP地址(192.168.10.3)来实现:

(vrouter-agent)[root@compute1 /]$ vif --list | grep -B 1 -A 1 192.168.10.3
vif0/3      OS: tapcae84676-cb NH: 33
            Type:Virtual HWaddr:00:00:5e:00:01:00 IPaddr:192.168.10.3
            Vrf:2 Mcast Vrf:2 Flags:PL3L2DEr QOS:-1 Ref:6

在这里,我们学到了很多有用的东西。

接口属于Vrf 2,这是一种路由表索引。虚拟接口索引是3(vif0/3)。最后,对应的tap接口是tapcae84676-cb。

下一个工具,我们可以使用rt。记住,我们要ping的是地址为192.168.10.4的远程虚拟机。

(vrouter-agent)[root@compute1 /]$ rt --get 192.168.10.4/32 --vrf 2
Match 192.168.10.4/32 in vRouter inet4 table 0/2/unicast

Flags: L=Label Valid, P=Proxy ARP, T=Trap ARP, F=Flood ARP
vRouter inet4 routing table 0/2/unicast
Destination           PPL        Flags        Label         Nexthop    Stitched MAC(Index)
192.168.10.4/32         0           LP         23             20        2:e7:fd:ee:27:78(148824)

上面的输出结果告诉我们流量将被发送到下一跳20。此外,它还说到将使用标签23。这表明,为了到达目的地,流量将不得不离开计算节点,并被封装成一个MPLSoUDP(或MPLSoGRE)包。这个标签就是将要推送的服务标签。

我们来检查下一跳:

(vrouter-agent)[root@compute1 /]$ nh --get 20
Id:20         Type:Tunnel         Fmly: AF_INET  Rid:0  Ref_cnt:6          Vrf:0
              Flags:Valid, MPLSoUDP, Etree Root,
              Oif:0 Len:14 Data:56 68 ac c3 28 02 56 68 ac c3 28 04 08 00
              Sip:192.168.200.3 Dip:192.168.200.4

正如想象的那样,下一跳是一个MPLSoUDP隧道,将流量从compute1(vhost0地址192.168.200.3)发送到compute2(vhost0地址192.168.200.4)。

请注意输出中的“Vrf:0”字段,这告诉我们,流量将通过VRF 0发送出去(如前所述,VM在VRF 2中)。Vrf 0是“fabric network”,连接计算节点和underlay的网络。此外,发送到下一跳20的流量将通过接口0(Oif 0)发送到Vrf 0(如前所述)。Oif 0是连接计算和底层的物理接口接口:

(vrouter-agent)[root@compute1 /]$ vif --get 0
Vrouter Interface Table
vif0/0      OS: ens3f1 (Speed 1000, Duplex 1) NH: 4
            Type:Physical HWaddr:56:68:ac:c3:28:04 IPaddr:0.0.0.0
            Vrf:0 Mcast Vrf:65535 Flags:TcL3L2VpEr QOS:-1 Ref:7
            RX packets:738213  bytes:47096090 errors:0
            TX packets:808295  bytes:42533041 errors:0
            Drops:30

这是vhost0所在的接口。Oif 0会“看到”封装的数据包。

综上所述,我们的虚拟机的流量属于VRF 2,在这个VRF里面,发生了查找(lookup)动作。在那里,通过Oif 0接口(物理接口),流量将被封装成MPLSoUDP数据包,然后发送到另一个计算节点。

下一个有用的工具,是“流(flow)”。vRouter默认是基于流的(可以通过将vmis设置为数据包模式来选择性地禁用每个vmi的流模式)。

让我们根据目的地来匹配流量:

(vrouter-agent)[root@compute1 /]$ flow --match 192.168.10.4
Listing flows matching ([192.168.10.4]:*)

    Index                Source:Port/Destination:Port                      Proto(V)
-----------------------------------------------------------------------------------
   512500518060       192.168.10.3:49409                                  1 (2)
                         192.168.10.4:0
(Gen: 1, K(nh):33, Action:F, Flags:, QOS:-1, S(nh):33,  Stats:4/392,  SPort 54199,
 TTL 0, Sinfo 3.0.0.0)

   518060512500       192.168.10.4:49409                                  1 (2)
                         192.168.10.3:0
(Gen: 1, K(nh):33, Action:F, Flags:, QOS:-1, S(nh):20,  Stats:4/392,  SPort 65513,
 TTL 0, Sinfo 192.168.200.4)

到目前为止,我们只看到了控制面信息:接口索引、路由表、下一跳。

这是第一次确认流量真的在虚拟机之间流动。

我们有2个流,因为每个流都是单向的。

这个输出有这么多信息!流量是流动的,因为Action被设置为F,也就是转发。

我们还知道,流量是ICMP,因为proto等于1。Proto旁边有“(V)”。这代表了VRF id,不出意外的话,它等于2!

最后,看到K(NH)和S(NH):这些是Key和Source(RPF)的下一跳。下一跳20我们已经看到了。此外,我们还看到下一跳33,它指向我们的本地虚拟机(vif 3):

(vrouter-agent)[root@compute1 /]$ nh --get 33 | grep Oif
              EncapFmly:0806 Oif:3 Len:14

我们可以从vRouter内部使用的东西就到这里了。

最后,我们进入到hypervisor层。我所说的“hypervisor层”指的是虚拟机和外界之间的那个中间层。这是虚拟机接口与物理网卡连接的地方。在这个层面我们能做的主要是嗅探流量。

先退出vRouter容器。

当使用vif时,我们能够定位到与该端口相关的tap接口“tapcae84676-cb”。

可以使用标准的tcpdump:

[root@compute1 ~]# tcpdump -i tapcae84676-cb -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tapcae84676-cb, link-type EN10MB (Ethernet), capture size 262144 bytes
09:24:55.082119 IP 192.168.10.3 > 192.168.10.4: ICMP echo request, id 49409, seq 688, length 64
09:24:55.107621 IP 192.168.10.4 > 192.168.10.3: ICMP echo reply, id 49409, seq 688, length 64
09:24:56.082344 IP 192.168.10.3 > 192.168.10.4: ICMP echo request, id 49409, seq 689, length 64
09:24:56.092153 IP 192.168.10.4 > 192.168.10.3: ICMP echo reply, id 49409, seq 689, length 64
^C
4 packets captured
10 packets received by filter
0 packets dropped by kernel

是的,这里就是我们的流量。

其次,可以直接在物理接口上嗅探流量。这里,我们将看到封装的流量。

在这个接口上,我们可能会看到许多不同类型的流量:到计算节点2的流量,到其它计算节点的流量,到控制节点的流量。此外,并非所有的流量都是MPLSoUDP。我们可以有VXLAN(L2虚拟化)流量或普通IP流量(XMPP)。出于这个原因,适当地过滤流量可能是有用的。

MPLSoUDP的流量可以通过6635端口过滤udp流量来缩小范围;VXLAN可以通过设置4789端口过滤udp流量。此外,我们还可以在目的主机IP上进行过滤,如之前学习的使用“rt”和“nh”,流量被发送到192.168.200.4:

[root@compute1 ~]# tcpdump -i ens3f1 -nn udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3f1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:33:24.394590 IP 192.168.200.3.54199 > 192.168.200.4.6635: UDP, length 102
09:33:24.395915 IP 192.168.200.4.56128 > 192.168.200.3.6635: UDP, length 102
09:33:25.395362 IP 192.168.200.3.54199 > 192.168.200.4.6635: UDP, length 102
09:33:25.398488 IP 192.168.200.4.56128 > 192.168.200.3.6635: UDP, length 102
09:33:26.395541 IP 192.168.200.3.54199 > 192.168.200.4.6635: UDP, length 102
09:33:26.399384 IP 192.168.200.4.56128 > 192.168.200.3.6635: UDP, length 102
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

正如你所看到的,我们在这些计算节点之间有双向的MPLSoUDP流量。无论如何,还不能确定这真的是我们的流量。为了确定这一点,我们可以将捕获到的数据保存到一个文件中,然后用wireshark打开,wireshark能够解码MPLSoUDP。

根据配置的封装优先级,可能VXLAN是用于计算到计算的流量。事实上,VXLAN是VN内部流量的默认选择,除非MPLSoUDP被配置在优先级列表中的第一位(无论如何,现在这并不重要……)。

我们只能说,我们必须期望处理不同类型的overlay流量。

其实VXLAN更方便用户使用,因为tcpdump可以显示内部数据包的内容:

[root@compute1 ~]# tcpdump -i ens3f1 -nn udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3f1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:36:24.478515 IP 192.168.200.3.54199 > 192.168.200.4.4789: VXLAN, flags [I] (0x08), vni 5
IP 192.168.10.3 > 192.168.10.4: ICMP echo request, id 49409, seq 1377, length 64
09:36:24.479659 IP 192.168.200.4.56128 > 192.168.200.3.4789: VXLAN, flags [I] (0x08), vni 5
IP 192.168.10.4 > 192.168.10.3: ICMP echo reply, id 49409, seq 1377, length 64
09:36:25.478920 IP 192.168.200.3.54199 > 192.168.200.4.4789: VXLAN, flags [I] (0x08), vni 5
IP 192.168.10.3 > 192.168.10.4: ICMP echo request, id 49409, seq 1378, length 64
09:36:25.480214 IP 192.168.200.4.56128 > 192.168.200.3.4789: VXLAN, flags [I] (0x08), vni 5
IP 192.168.10.4 > 192.168.10.3: ICMP echo reply, id 49409, seq 1378, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
[root@compute1 ~]#

在这里,我们可以看到实际的VM ICMP数据包。这样就可以确定是否为我们的流量。

只要我们的计算节点是在内核模式下,使用tcpdump就是可能的。如果我们有一个dpdk vRouter,那么就不能在主机上使用tcpdump,因为dpdk会“吃掉接口”,使它们对内核不可见(tcpdump在内核可见的接口上工作)。在这种情况下,hypervisor层消失了,我们必须依靠vRouter层。

一旦我们进入vRouter容器,一个至今没有见过的工具就成了基础:vifdump。Vifdump就像tcpdump一样,只是它工作在DPDK接口上,只能在vRouter容器内部运行。

要嗅探一个虚拟机接口:

vifdump -i vif0/3 -nn icmp

要嗅探一个物理接口:

vifdump -i vif0/0

总结

就是这样!让我们总结一下所有的可能性——

在VNF层面,使用厂商/VNF特定的工具。

在vRouter层面(工具要在vRouter容器内运行):

  • vif,列出虚拟接口
  • nh,了解流量计算一个特定的nexth-hop索引是在哪里发送的
  • flow,查看vRouter上的活动流量
  • rt,查看vRouter路由表内部

在hypervisor层面,使用tcpdump来嗅探虚拟接口和物理接口上的数据包。

最后,如果节点是DPDK节点,那么主机级的tcpdump就没有用了,用vRouter容器里面运行的“vifdump”代替。

现在没有秘密了吧?一句话,在正确的层面上使用正确的工具~


作者:Umberto Manferdini 译者:TF编译组 原文链接: https://iosonounrouter.wordpress.com/2020/04/13/troubleshooting-contrail-vms-traffic-the-right-tool-at-the-right-moment/

原创声明,本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

登录 后参与评论
0 条评论

相关文章

  • 程序员必备!网络排错思路总结

    为什么要先讲必备条件?因为这里所讲的网络排错并不仅仅是停留在某一个小小命令的使用上,而是一套系统的方法,如果没有这些条件,真的不能保证下面聊的这些可以听得懂,并...

    民工哥
  • 有了这篇网络排错思路大总结/我帮了不少女同事~

    TCP/IP 协议栈里面的协议就显得十分重要了,比如 DNS、TCP、UDP、IP、ICMP、ARP,这些最基本的应该得知道吧,我们不需要像《TCP/IP 协议...

    入门笔记
  • Tungsten Fabric如何编排

    OpenStack是虚拟机和容器的领先的开源编排系统。Tungsten Fabric提供了Neutron网络服务的实现,并提供了许多附加功能。

    Tungsten Fabric
  • 网络排错大盘点

    为什么要先讲必备条件?因为这里所讲的网络排错并不仅仅是停留在某一个小小命令的使用上,而是一套系统的方法,如果没有这些条件,我真的不能保证下面讲的这些你可以听得懂...

    杰哥的IT之旅
  • 超好用的k8s中pod诊断工具:kubectl-debug

    容器技术的一个最佳实践是构建尽可能精简的容器镜像。但这一实践却会给排查问题带来麻烦:精简后的容器中普遍缺失常用的排障工具,部分容器里甚至没有 shell (比如...

    没有故事的陈师傅
  • 如何应对云网络中存在的问题与挑战(附DeepFlow白皮书下载链接)

    在全球数字化转型的浪潮下,“上云”已成为企业数字化转型的主流选择,在赋能业务创新、弹性服务的同时,新场景给网络运维、网络运营、网络安全等方面也带来了全新的挑战。...

    SDNLAB
  • 使用Pycharm运行TensorFlow,Virtualenv安装TensorFlow「建议收藏」

    TensorFlow可以在Virtualenv虚拟环境下安装,也可以在Anaconda虚拟环境下安装,当然也可以在Docker环境下安装。具体的安装在TF官网上...

    全栈程序员站长
  • 运维不仅仅是 Linux,居然还要知道这么多?

    运维不仅仅是懂Linux就行,因为还有一大部分的Windows运维,向windows运维人员致敬。 当然我们这篇文章不是说运维除了懂Linux,还要懂Windo...

    码云Gitee
  • 什么是网络可视化?

    在由于数据量不断增加和网络安全问题日益严重,网络安全和监控至关重要,因此,全面的网络可见性对于大多数企业而言都是必需的。尽管需求不断增长,但许多公司仍未实现其网...

    虹科网络可视化与安全
  • 一站式查看网络流量的完整解决方案

    互联网服务提供商(ISP)面临着用户增长带来的极端带宽使用的问题。虽然这对商业来说是件好事,但挑战在于确保带宽的有效利用。很多时候,客户会抱怨“网络很慢”,实际...

    虹科网络可视化与安全
  • [AI安全论文] 20.RAID19 基于Android移动设备的互联网流量中的位置数据泄漏分析(译文)

    先祝大家五一节快乐。前一篇介绍了USENIXSec21恶意代码分析的经典论文——DeepReflect,它通过二进制重构发现恶意功能。这篇文章将带来RAID 2...

    Eastmount
  • Kubeflow 部署采坑记录

    Kubeflow 是在 K8S 集群上跑机器学习任务的工具集,提供了 Tensorflow, Pytorch 等等机器/深度学习的计算框架,同时构建容器工作流 ...

    runzhliu
  • tensorflow安装教程

    tensorflow是谷歌开源的人工智能库,有最完善的生态支持。是进行人工智能领域开发和科研的必备工具。本文在windows10下,借助anacondaAnac...

    震八方紫面昆仑侠
  • Tungsten Fabric架构vRouter的部署选项

    Tungsten Fabric项目是一个开源项目协议,它基于标准协议开发,并且提供网络虚拟化和网络安全所必需的所有组件。项目的组件包括:SDN控制器,虚拟路由器...

    Tungsten Fabric
  • 【转】腾讯云 API 3.0实践分享(下)

    原文地址:https://cloud.tencent.com/developer/article/1155254

    None-xiaomi
  • Linux服务器性能评估与优化(四)--网络

    之前文章《Linux服务器性能评估与优化(一)》太长,阅读不方便,因此拆分成系列博文:

    黄规速
  • 有效监控网络流量的五个步骤

    监控网络流量虽然不足为奇,但监视大型企业级组织中的网络流量与家庭或家庭办公室的方式大不相同。大多数大型公司都有各种域,例如WAN,SD-WAN,数据中心,AWS...

    虹科网络可视化与安全
  • U盘引导安装黑群晖DSM6

    黑群晖系统其实是指在普通电脑运行Synology DSM系统, 事实上在普通PC电脑上安装黑群晖(Synology DSM)也非常方便, 现在把教程简单写一下。

    cnlixs

扫码关注腾讯云开发者

领取腾讯云代金券