目录
1. 解决的问题需求
当vm互访不通时,不知道是哪天流表出问题,可以通过 ovs提供的工具模拟虚拟机实例发出的数据包来跟踪数据包经过的流表路径。
2. 使用方法
(一)解决的问题需求
我们在使用ovs的时候,通常会遇到虚拟机发出的数据包出现通信不通的情况,而不知道是ovs的哪条流表导致的。此时我们可以通过ovs-appctl ofproto/trace 来跟踪虚拟机发出来的数据包经过的pipeline 路径。
(二)使用方法
命令行语法:
ovs-appctl ofproto/trace {[dp_name] odp_flow | bridge br_flow} [OPTIONS...] [-generate|packet]
eg:
ovs-appctl ofproto/trace br-int "in_port=24,dl_src=00:10:3e:f6:26:6b,dl_dst=00:10:3e:38:41:a1,dl_type=2048,nw_src=192.168.1.8,nw_dst=192.168.155.200,nw_proto=6,tp_src=45578,tp_dst=20048" --generate
使用ovs-appctl ofproto/trace 命令行有两种使用方法:
1. 直接使用命令,后接报文信息
ovs-appctl ofproto/trace br-int in_port=3,dl_src=fa:16:3e:fd:59:5c,dl_dst=fa:16:3e:ee:ff:ff
2. 使用命令后接数据包二进制信息
有时我们可能不知道报文的内容,但我们想某个port发出的包经过的pipeline。那么就可以使用这种方法。
首先,使用tcpdump 抓取port的一个报文,如
发包:
抓包:
使用ovs-pcap将抓包文件打印出来,输出16进制的数据:
使用ovs-appctl ofproto/trace 跟踪数据包经过的ovs pipeline:
ovs-appctl ofproto/trace br-int in_port=3 "fa163eeefffffa163efd595c080045000054f586400040016a67c0a80a030808080808009d51544e0001d9693562000000002fc0090000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637"
(三)总结
上述两种方法都可以在ovs上跟踪某个数据包经过的pipeline,第一种方法适合已知报文内容,或在报文内容输入较少的情况下使用(因为可以不用输入太多参数,能偷懒就偷懒使用第二种方法);第二种方法适合trace时包内容太多,且能够精确匹配数据包内容特征进行trace。