[ovs-dev] Issue about "action=normal" in OVS-DPDK
Michael Qiu
08005325 at 163.com
Tue Oct 25 02:43:37 UTC 2016
在 2016/10/25 1:16, Daniele Di Proietto 写道:
>
>
>
>
> On 24/10/2016 00:31, "Michael Qiu" <08005325 at 163.com> wrote:
>
>> Hi, all
>>
>>
>> When I self-compiled the OVS-2.6 from commit:
>>
>> commit 7a0f907b2393626dac1387617355990eab69aef7
>> Author: Justin Pettit <jpettit at ovn.org>
>> Date: Tue Sep 27 10:13:42 2016 -0700
>>
>> Set release date for 2.6.0.
>>
>> Signed-off-by: Justin Pettit <jpettit at ovn.org>
>> Acked-by: Ben Pfaff <blp at ovn.org>
>>
>> I found that when I using "action=normal", the fdb table will never
>> learn the mac addr in the packets from the patch port, is it a bug?
>>
>>
>> This issue lead other problems, all packets to patch port will flooding
>> to all ports with the same vlan in the bridge, and I see lots of packet
>> copy.
>>
>>
>> See below:
>>
>>
>> # ovs-ofctl show br-int
>> OFPT_FEATURES_REPLY (xid=0x2): dpid:000072fe77bb5849
>> n_tables:254, n_buffers:256
>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
>> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>> 1(vhuffc5b772-c6): addr:00:00:00:00:00:00
>> config: 0
>> state: LINK_DOWN
>> speed: 0 Mbps now, 0 Mbps max
>> 2(patch-tun): addr:7a:85:c5:7d:2f:da
>> config: 0
>> state: 0
>> speed: 0 Mbps now, 0 Mbps max
>> 3(vhu88dab7aa-ae): addr:00:00:00:00:00:00
>> config: 0
>> state: LINK_DOWN
>> speed: 0 Mbps now, 0 Mbps max
>> 8(vhu29e6e817-63): addr:00:00:00:00:00:00
>> config: 0
>> state: 0
>> speed: 0 Mbps now, 0 Mbps max
>> LOCAL(br-int): addr:72:fe:77:bb:58:49
>> config: PORT_DOWN
>> state: LINK_DOWN
>> current: 10MB-FD COPPER
>> speed: 10 Mbps now, 0 Mbps max
>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>
>>
>> # ovs-ofctl show br-tun
>> OFPT_FEATURES_REPLY (xid=0x2): dpid:00007e58c1f5b141
>> n_tables:254, n_buffers:256
>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
>> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>> 1(patch-int): addr:56:36:bb:1e:ec:c7
>> config: 0
>> state: 0
>> speed: 0 Mbps now, 0 Mbps max
>> 5(vxlan-c0a8c80b): addr:26:e9:2b:31:62:8b
>> config: 0
>> state: 0
>> speed: 0 Mbps now, 0 Mbps max
>> 6(vxlan-c0a8c80c): addr:2a:07:0e:84:fd:8e
>> config: 0
>> state: 0
>> speed: 0 Mbps now, 0 Mbps max
>> LOCAL(br-tun): addr:7e:58:c1:f5:b1:41
>> config: PORT_DOWN
>> state: LINK_DOWN
>> current: 10MB-FD COPPER
>> speed: 10 Mbps now, 0 Mbps max
>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>
>>
>>
>> # ovs-vsctl show
>> 57863254-3c79-4dc7-a6a0-277eb8c741f4
>> Bridge br-dpdk
>> Port br-dpdk
>> Interface br-dpdk
>> type: internal
>> Port "dpdk0"
>> Interface "dpdk0"
>> type: dpdk
>> Bridge br-int
>> fail_mode: secure
>> Port patch-tun
>> Interface patch-tun
>> type: patch
>> options: {peer=patch-int}
>> Port "vhu29e6e817-63"
>> tag: 1
>> Interface "vhu29e6e817-63"
>> type: dpdkvhostuser
>> Port "vhuffc5b772-c6"
>> tag: 2
>> Interface "vhuffc5b772-c6"
>> type: dpdkvhostuser
>> Port "vhu88dab7aa-ae"
>> tag: 1
>> Interface "vhu88dab7aa-ae"
>> type: dpdkvhostuser
>> Port br-int
>> Interface br-int
>> type: internal
>>
>> Bridge br-tun
>> fail_mode: secure
>> Port br-tun
>> Interface br-tun
>> type: internal
>> Port "vxlan-c0a8c80b"
>> Interface "vxlan-c0a8c80b"
>> type: vxlan
>> options: {df_default="true", in_key=flow,
>> local_ip="192.168.200.14", out_key=flow, remote_ip="192.168.200.11"}
>> Port "vxlan-c0a8c80c"
>> Interface "vxlan-c0a8c80c"
>> type: vxlan
>> options: {df_default="true", in_key=flow,
>> local_ip="192.168.200.14", out_key=flow, remote_ip="192.168.200.12"}
>> Port patch-int
>> Interface patch-int
>> type: patch
>> options: {peer=patch-tun}
>> ovs_version: "2.6.0"
>>
>>
>> Flow Table：
>>
>> br-int:
>>
>> ovs-ofctl add-flow br-int "in_port=2,action=output:8"
> I suspect that the above flow is preventing the mac learning from happening.
>
> If you output directly to a specific port, OVS will not perform any mac learning.
>
> Could you maybe try with normal action here, instead of outputting directly to port 8?
Yes, I've tried to do that, and seen the mac from patch port shown in
fdb table, but the VM will never received the arp reply packet, don't
know why. Maybe because local VM is in vlan 1(tag 1), but patch port
does not has a vlan ID.
Then I changed the flow table to:
ovs-ofctl add-flow br-int "nw_dst=10.0.0.218,action=output:8"
IP: 10.0.0.218 is local VM IP. The guest could receive the arp packets,
but fdb table will only have one entry with local VM, remote VM's mac
does not exist.
So if using flow rules, the l2 switch will never learn the mac right?
Don't know why patch port using "normal" action will block the arp packets
>
>> ovs-ofctl add-flow br-int "in_port=8,action=output:normal"
>>
>>
>> br-tun
>>
>> ovs-ofctl add-flow br-tun
>> "in_port=1,action=set_tunnel:0x46,strip_vlan,output:6"
>>
>> ovs-ofctl add-flow br-tun "in_port=6,action=output:1"
>>
>>
>> VM using port 8(vhu29e6e817-63) as vhost-user port:
>>
>> (creat hugepage first)
>>
>> /usr/libexec/qemu-kvm -machine pc,accel=kvm,usb=off -cpu host -m 2048
>> -smp 2,sockets=2,cores=1,threads=1 -drive
>> file=/var/lib/nova/instances/_base/0fc2479281ab0a4ca901b7981122a180f843b2bf
>> -chardev socket,id=charnet0,path=/var/run/openvswitch/vhu29e6e817-63
>> -netdev type=vhost-user,id=hostnet0,chardev=charnet0 -device
>> virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:61:23:ed,bus=pci.0,addr=0x3
>> -object
>> memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu,share=yes,size=2147483648,host-nodes=0,policy=bind
>> -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 -vnc 0.0.0.0:0 -k en-us
>> -device cirrus-vga,id=video0,bus=pci.0,addr=0x2
>>
>>
>> In VM ping another VM in other hosts, which using native OVS.
>>
>> Then find in OVS-DPDK:
>>
>> # ovs-appctl fdb/show br-int
>> port VLAN MAC Age
>> 8 1 fa:16:3e:61:23:ed 1
>>
>>
>> In OVS(another host, port 4 is patch port.):
>>
>> ovs-appctl fdb/show br-int
>> port VLAN MAC Age
>> 6 2 fa:16:3e:09:9d:bc 0
>> 4 2 fa:16:3e:61:23:ed 0
>>
>>
>> This issue will cause packets flooding in br-int.
>>
>> Any sulotions?
>>
>>
>> --
>> Thanks,
>> Michael
>>
>>
--
Thanks,
Michael
More information about the dev
mailing list