[ovs-discuss] openvswitch tap device drop the packets

张伟 zhangwqh at 126.com
Sat Nov 22 02:03:27 UTC 2014


Actually our group used openstack. Every Virtual machine has a virtual device. Finally we want to make it work in virtualized environment. So I simulated to create a tap device and make the application send packets on tap device(simulate the packets send out from the virtual machine). However, when I create a tap device using tunctl and attach it to bridge. The tap device directly drops the packets. I do not know why and want to know the reason. This is why I post this message. 







At 2014-11-22 06:46:32, "Ben Pfaff" <blp at nicira.com> wrote:
>I'm not sure why you're using a tap device here at all, or even an
>internal device.
>When you create a bridge and want an IP address on it, the easiest way to get
>one is to configure it on the bridge port, e.g.:
>    ovs-vsctl add-br br0
>    ifconfig br0 192.168.0.1
>
>On Thu, Nov 20, 2014 at 6:39 PM, 张伟 <zhangwqh at 126.com> wrote:
>> Before I have tried this. Since the packets are directlty dropped from tap
>> device(using tunctl command to create. This is my confused question-when I
>> use ovs-vsctl add-port bridge-name device-name -- set Interface device-name
>> type=internal. it works), the packets and bytes statistical information do
>> not been updated in the flow table.
>>
>>
>>
>>
>>
>>
>> At 2014-11-21 08:14:23, "nwy" <seamus.na at gmail.com> wrote:
>>
>> You can try to dump kernel flows by using ovs-dpctl dump-flows. Then track
>> the flow to see where it actually goes and what actions have been applied to
>> the flow
>>
>> On Nov 21, 2014 2:16 AM, Alex Wang <alexw at nicira.com> wrote:
>>
>> Sorry for the delayed reply,
>>
>> I'm able to reproduce the issue, will investigate further and reply back~
>>
>> Which version of ovs did you use?
>>
>> Thanks,
>> Alex Wang,
>>
>> On Wed, Nov 19, 2014 at 5:43 PM, 张伟 <zhangwqh at 126.com> wrote:
>>>
>>> Hi all,
>>>
>>> I have a question for the tap device attached to openvswitch bridge.
>>> My aim is to send the packets  from tap device of physical machine
>>> A(physical IP:10.48.24.63) to tap device of physical machine B(physical
>>> IP:10.48.24.67) with vxlan setting.
>>> What I did is
>>> 1)Physical machine A (physical IP:10.48.24.63)
>>> step1: create a tap device and make it up
>>> #create tap device
>>> tunctl -t tap0
>>> ifconfig tap0 192.168.5.63 up
>>>
>>> step2: create bridge, vxlan device and attach tap device
>>> #create bridge and add ports
>>> ovs-vsctl add-br ovs-br0
>>> ovs-vsctl add-port ovs-br0 tap0
>>> ovs-vsctl add-port ovs-br0 vxlan0 -- set interface vxlan0 type=vxlan
>>> options:local_ip=10.48.24.63  options:remote_ip=10.48.24.67 options:key=flow
>>>
>>> step3:
>>> #check port id in ovs bridge
>>> ovs-ofctl show ovs-br0
>>>
>>> step4:
>>> #add flow entry from tap device to vxlan device and from vxlan device to
>>> tap device
>>> ovs-ofctl add-flow ovs-br0 "in_port=1, actions=output:2" outgoing
>>> ovs-ofctl add-flow ovs-br0 "in_port=2, actions=output:1" incoming
>>>
>>> On physical machine B, I did the similar operations. The tap device in
>>> physical machine B is 192.168.5.67
>>>
>>> When I ping the tap device 192.168.5.67 of physical machine B from
>>> physical machine A,
>>> ping 192.168.5.67
>>> I found that tap device droped alll of the packets on physical machine A.
>>> I did not know why. Can somebody give me some advice? The following is the
>>> output on my physical machine A. the ports statistical information, flow
>>> entries, the port id in openvswitch.
>>> ovs-ofctl dump-ports ovs-br0(ports statistical information)
>>> OFPST_PORT reply (xid=0x2): 3 ports
>>>   port  1: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0
>>>            tx pkts=0, bytes=0, drop=8124, errs=0, coll=0
>>>   port  4: rx pkts=0, bytes=0, drop=0, errs=0, frame=0, over=0, crc=0
>>>            tx pkts=0, bytes=0, drop=0, errs=0, coll=0
>>>   port LOCAL: rx pkts=6, bytes=468, drop=0, errs=0, frame=0, over=0, crc=0
>>>            tx pkts=0, bytes=0, drop=0, errs=0, coll=0
>>>
>>> ovs-ofctl dump-flows ovs-br0(flow entries)
>>> NXST_FLOW reply (xid=0x4):
>>>  cookie=0x0, duration=50903.320s, table=0, n_packets=0, n_bytes=0,
>>> idle_age=50903, priority=2,in_port=1,dl_dst=ce:82:4a:f4:2d:f3
>>> actions=output:4
>>>  cookie=0x0, duration=71137.959s, table=0, n_packets=5, n_bytes=378,
>>> idle_age=65534, hard_age=65534, priority=0 actions=NORMAL
>>>  cookie=0x0, duration=1544.792s, table=0, n_packets=0, n_bytes=0,
>>> idle_age=1544, priority=2,in_port=4 actions=output:1
>>>
>>> ovs-ofctl show ovs-br0(port information)
>>> OFPT_FEATURES_REPLY (xid=0x2): dpid:0000eafeac000142
>>> n_tables:254, n_buffers:256
>>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>>> actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST
>>> SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
>>>  1(tap0): addr:46:f1:26:89:45:88
>>>      config:     0
>>>      state:      0
>>>      current:    10MB-FD COPPER
>>>      speed: 10 Mbps now, 0 Mbps max
>>>  4(vxlan0): addr:0a:25:64:47:8b:f9
>>>      config:     0
>>>      state:      0
>>>      speed: 0 Mbps now, 0 Mbps max
>>>  LOCAL(ovs-br0): addr:ea:fe:ac:00:01:42
>>>      config:     0
>>>      state:      0
>>>      speed: 0 Mbps now, 0 Mbps max
>>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>>
>>>
>>>
>>> _______________________________________________
>>> discuss mailing list
>>> discuss at openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/discuss
>>>
>>
>>
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>
>
>
>-- 
>"I don't normally do acked-by's.  I think it's my way of avoiding
>getting blamed when it all blows up."               Andrew Morton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20141122/f02803cc/attachment-0002.html>


More information about the discuss mailing list