我正在玩sdn的东西，我的测试配置是：openwswitch在VM中连接了2个其他VM（所有在VirtualBox中运行Ubuntu 14.04）：
vagrant@ovs:~$ sudo ovs-vsctl show
8c1ee033-7bf1-4640-9019-67dd3482f96c
Bridge "ovsbr0"
Controller "tcp:192.168.100.200:6633"
Port "eth4"
Interface "eth4"
Port "ovsbr0"
Interface "ovsbr0"
type: internal
Port "eth3"
Interface "eth3"
VM1: openvswitch
eth3 eth4
/ \
/ \
/ \
VM2:client VM3:server
最近我偶然发现了一个奇怪的OVS行为 . 因此，一旦ovs启动，它就会以'哑桥'模式工作，也就是说，它配置了一个流程：
vagrant@ovs:~$ sudo ovs-ofctl dump-flows ovsbr0
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=4.676s, table=0, n_packets=10, n_bytes=904, idle_age=1, priority=0 actions=NORMAL
客户端可以到达服务器，反之亦然，因为所有数据包都传递到ov上的每个端口，我可以看到数据包在ovs中的througg port1和port2，观察输出：
watch sudo ovs-ofctl dump-ports ovsbr0
然后我删除流量：
vagrant@ovs:~$ sudo ovs-ofctl del-flows ovsbr0
vagrant@ovs:~$ sudo ovs-ofctl dump-flows ovsbr0
NXST_FLOW reply (xid=0x4):
这打破了客户端和服务器之间的连接，正如预期的那样，现在我只看到一个端口的rx队列中的数据包（客户端连接的端口，以及发送ping的地方）然后我连接一个控制器：
vagrant@ovs:~$ sudo ovs-vsctl set-controller ovsbr0 tcp:192.168.100.200
vagrant@ovs:~$ sudo ovs-vsctl get-controller ovsbr0
tcp:192.168.100.200
它提供新流和连接恢复：
vagrant@ovs:~$ sudo ovs-ofctl dump-flows ovsbr0
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=0.032s, table=0, n_packets=1, n_bytes=98, idle_timeout=10, hard_timeout=30, idle_age=0, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=08:00:27:f7:10:9a,dl_dst=08:00:27:14:2a:ea,nw_src=192.168.101.151,nw_dst=192.168.102.152,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:1
cookie=0x0, duration=0.026s, table=0, n_packets=1, n_bytes=98, idle_timeout=10, hard_timeout=30, idle_age=0, priority=65535,icmp,in_port=1,vlan_tci=0x0000,dl_src=08:00:27:14:2a:ea,dl_dst=08:00:27:f7:10:9a,nw_src=192.168.102.152,nw_dst=192.168.101.151,nw_tos=0,icmp_type=0,icmp_code=0 actions=output:2
因此，事实是，如果我尝试连接具有错误IP或端口的控制器，则连接也会恢复...尽管给定地址没有控制器：
vagrant@ovs:~$ sudo ovs-vsctl set-controller ovsbr0 tcp:192.168.100.500
vagrant@ovs:~$ sudo ovs-vsctl get-controller ovsbr0
tcp:192.168.100.500
vagrant@ovs:~$ sudo ovs-ofctl dump-flows ovsbr0
NXST_FLOW reply (xid=0x4):
此外，没有流量没有......但是我看到了eth3和eth4接口上的数据包（再次查看 dump-ports ），它们是ovs上的端口......这是什么诀窍？原因是：
sudo ovs-ofctl snoop ovsbr0
仅显示ovs和真实控制器之间的开放流数据包，但在“假”控制器的情况下保持静音 .
然后我终于研究了“隐藏”流程：
sudo ovs-appctl bridge/dump-flows ovsbr0 Wed Aug 24 12:46:31 2016
duration=79s, priority=180008, n_packets=0, n_bytes=0, priority=180008,tcp,nw_src=192.168.100.208,tp_src=6633,actions=NORMAL
duration=79s, priority=180000, n_packets=0, n_bytes=0, priority=180000,udp,in_port=LOCAL,dl_src=08:00:27:16:78:8c,tp_src=68,tp_dst=67,actions=NORMAL
duration=79s, priority=180006, n_packets=0, n_bytes=0, priority=180006,arp,arp_spa=192.168.100.208,arp_op=1,actions=NORMAL
duration=79s, priority=180002, n_packets=0, n_bytes=0, priority=180002,arp,dl_src=08:00:27:16:78:8c,arp_op=1,actions=NORMAL
duration=79s, priority=180004, n_packets=0, n_bytes=0, priority=180004,arp,dl_src=52:54:00:12:35:02,arp_op=1,actions=NORMAL
duration=79s, priority=180003, n_packets=0, n_bytes=0, priority=180003,arp,dl_dst=52:54:00:12:35:02,arp_op=2,actions=NORMAL
duration=79s, priority=180001, n_packets=0, n_bytes=0, priority=180001,arp,dl_dst=08:00:27:16:78:8c,arp_op=2,actions=NORMAL
duration=79s, priority=15790320, n_packets=162, n_bytes=15648, priority=15790320,actions=NORMAL
duration=79s, priority=180005, n_packets=0, n_bytes=0, priority=180005,arp,arp_tpa=192.168.100.208,arp_op=2,actions=NORMAL
duration=79s, priority=180007, n_packets=0, n_bytes=0, priority=180007,tcp,nw_dst=192.168.100.208,tp_dst=6633,actions=NORMAL
table_id=254, duration=5442s, priority=0, n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop
table_id=254, duration=5442s, priority=0, n_packets=773, n_bytes=57528, priority=0,reg0=0x1,actions=controller(reason=no_match)
table_id=254, duration=5442s, priority=0, n_packets=0, n_bytes=0, priority=0,reg0=0x2,actions=drop
我看到了流量： priority=15790320, n_packets=162, n_bytes=15648, priority=15790320,actions=NORMAL 这就是所有混乱的原因 .
问题是 - 它是ovs的正常行为吗？例如 - 当控制器制动或无法到达时 - ov进入哑桥模式？为什么隐藏的流量，而不是普通的流量？