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" <[email protected]> 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, 张伟 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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, 张伟 <[email protected]> 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 >>> [email protected] >>> http://openvswitch.org/mailman/listinfo/discuss >>> >> >> >> >> >> _______________________________________________ >> discuss mailing list >> [email protected] >> 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
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
