2

我正在玩 sdn 的东西，我的测试配置是：在一个 VM 中的 openwswitch 与其他 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

客户端可以到达服务器，反之亦然，因为所有数据包都传递到 ovs 上的每个端口，我可以看到数据包通过 ovs 中的端口 1 和端口 2，观察以下输出：

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 接口上都看到了数据包（再次查看转储端口），它们是 ovs 上的端口……有什么诀窍？当然，：

sudo ovs-ofctl snoop ovsbr0

仅显示 ovs 和真实控制器之间的 openflow 数据包，但在“假”控制器的情况下保持沉默。

然后我终于研究了“隐藏”的流程：

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 的正常行为吗？例如 - 当控制器刹车或无法访问时 - ovs 进入哑桥模式？为什么隐藏流，而不是普通流？

4

0 回答 0