BTW- it works fine when b0 bridge type is NOT netdev and port is not accessed via DPDK. Something in the userspace data path may be broken?
On 2/12/15, 9:16 AM, "David Evans" <[email protected]> wrote: >Hi Pravin, > >Thank you for helping out. > >As you saw below from ofproto/trace, the b0 bridge Datapath Actions says >it sends out gre packets with a header src .102 dest .101 destination >But the packet captured on the receiving host¹s ethernet port is as >follows (GRE header in tact from 2F) but the outer MAC & IP are 00... > >00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 >00 00 00 00 00 00 40 2F 46 9F C0 A8 38 66 C0 A8 >38 65 00 00 65 58 00 00 04 04 12 34 00 00 04 56 >78 90 08 00 45 00 01 EE 00 00 00 00 40 FF A6 B9 >C0 A8 A8 05 C0 A8 A8 01 > >Trying to trace this through: > >1) How did the Datapath Actions on b0 work out the src ip? > > >2) What is supposed to happen to the packet when it leaves the first >bridge b0? >How does it get to b1? I am guessing linux host routing? > >3) Could B1 be corrupting the header for some reason? > >4� other possible factors ( netdev bridge? - DPDK ports? linux stack arp >cache issue?) > >I can ping both directions between 102 & 101 across the wire. So that >connection is good. > > > > > > >default_hugepagesz=2M hugepagesz=2M hugepages=2048 > >On 2/11/15, 6:55 PM, "Pravin Shelar" <[email protected]> wrote: > >>On Tue, Feb 10, 2015 at 1:52 PM, David Evans <[email protected]> >>wrote: >>> Hi OVS, >>> >>> I have 3.18 kernel containing ip_gre & Ovs 2.3.90 & Dpdk 1.7.1 >>> >>Userspace tunneling does not need ip_gre module, tunneling is handled >>in userspace. >> >>> I find that the outer ip & mac are not populated ??? The ofproto/trace >>> output thinks that the gre output will have the right src/dest on the >>>outer >>> but then it¹s gone� >>> >>What do you mean by "its gone"? Can you post tcpdump for ping test? >> >> >>> a bug? >>> am I missing some setup? >>> Wrong kernel ip_gre? >>> >>> Originating GRE: >>> ovs-vsctl add-br b0 -- set bridge b0 datapath_type=netdev >>> ovs-vsctl add-port b0 gre0 -- set Interface gre0 type=gre >>> options:remote_ip=192.168.56.101 >>> ovs-vsctl add-port b0 dpdk0 -- set Interface dpdk0 type=dpdk >>> >>> Output Bridge: >>> ovs-vsctl add-br b1 -- set bridge b1 datapath_type=netdev >>> ovs-vsctl add-port b1 dpdk1 -- set Interface dpdk1 type=dpdk >>> ifconfig b1 192.168.56.102 netmask 255.255.255.0 >>> >>> Set up flows: >>> ovs-ofctl del-flows b0 >>> ovs-ofctl del-flows b1 >>> -force traffic to gre from dpdk0 >>> ovs-ofctl add-flow b0 in_port=2,action=output:1 >>> ovs-ofctl add-flow b0 in_port=1,action=output:0 >>> -force traffic from b1 to output >>> ovs-ofctl add-flow b1 in_port=LOCAL,action=output:1 >>> ovs-ofctl add-flow b1 in_port=1,action=output:LOCAL >>> >>> A ofproto/trace says >>> >>> ovs-appctl ofproto/trace b0 in_port=1,dl_dst=00:e0:ed:52:97:cd >>> Bridge: b0 >>> Flow: >>> >>>in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:e0:ed:52:97 >>>: >>>cd,dl_type=0x0000 >>> >>> Rule: table=0 cookie=0 in_port=1 >>> OpenFlow actions=output:2 >>> >>> Final flow: >>> >>>in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:e0:ed:52:97 >>>: >>>cd,dl_type=0x0000 >>> Megaflow: recirc_id=0,in_port=1,dl_type=0x0000 >>> Datapath actions: >>> >>>tnl_push(tnl_port(5),header(size=38,type=3,eth(dst=00:00:04:04:12:34,src >>>= >>>00:e0:ed:52:97:cb,dl_type=0x0800),ipv4(src=192.168.56.102,dst=192.168.56 >>>. >>>101,proto=47,tos=0,ttl=64,frag=0x40),gre((flags=0x0,proto=0x6558))),out_ >>>p >>>ort(2)) >>> >>> >>> Regards, >>> >>> Dave >>> >>> _______________________________________________ >>> discuss mailing list >>> [email protected] >>> http://openvswitch.org/mailman/listinfo/discuss >>> > >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
