On Thu, Aug 9, 2018 at 2:02 PM, Yifeng Sun <pkusunyif...@gmail.com> wrote:
> Yes, exactly. > > Thanks, > Yifeng > > On Thu, Aug 9, 2018 at 1:13 PM, William Tu <u9012...@gmail.com> wrote: > >> >> >> On Thu, Aug 9, 2018 at 12:52 PM, Yifeng Sun <pkusunyif...@gmail.com> >> wrote: >> >>> The above packet hex is supposed to be generated by linux native tunnel. >>> But since native tunnel conflicts with openvswitch kernel module, so we >>> don't add native tunnel but just send simulated packets to OVS. >>> >>> The ERSPAN implementation of OVS is still tested on br0 and br-underlay. >>> In this test, br0 actually generate ERSPAN packets, which are captured >>> on p0 >>> through tcpdump. >>> >>> >> I see, thanks! >> So the hex packet is actually an incoming ERSPAN packet to br-underlay. >> As a result, it triggers OVS's ERSPAN tunnel decap as well as encap, >> when we see it in tcpdump. >> >> Regards, >> William >> >> >> >>> >>> On Thu, Aug 9, 2018 at 12:09 PM, William Tu <u9012...@gmail.com> wrote: >>> >>>> >>>> >>>> On Wed, Aug 8, 2018 at 11:32 AM, Yifeng Sun <pkusunyif...@gmail.com> >>>> wrote: >>>> >>>>> Introduce a new test that doesn't setup native erspan v2 tunnels but >>>>> sends >>>>> simulated raw packets. >>>>> This test is supposed to only run for kernel version from 4.4.x to >>>>> 4.15.x. >>>>> >>>>> Signed-off-by: Yifeng Sun <pkusunyif...@gmail.com> >>>>> >>>> thanks. Acked-by: William Tu <u9012...@gmail.com> > --- >>>>> tests/system-traffic.at | 44 ++++++++++++++++++++++++++++++ >>>>> ++++++++++++++ >>>>> 1 file changed, 44 insertions(+) >>>>> >>>>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at >>>>> index 44669f8..64b37df 100644 >>>>> --- a/tests/system-traffic.at >>>>> +++ b/tests/system-traffic.at >>>>> @@ -670,6 +670,50 @@ AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "IP >>>>> 172.31.1.100 > 172.31.1.1: GRE >>>>> OVS_TRAFFIC_VSWITCHD_STOP >>>>> AT_CLEANUP >>>>> >>>>> +AT_SETUP([datapath - ping over erspan v2 tunnel by simulated packets]) >>>>> +OVS_CHECK_KERNEL(4, 4, 15) >>>>> + >>>>> +OVS_TRAFFIC_VSWITCHD_START() >>>>> +AT_CHECK([ovs-vsctl -- set bridge br0 other-config:hwaddr=\"f2:ff:00 >>>>> :00:00:01\"]) >>>>> +ADD_BR([br-underlay], [set bridge br-underlay >>>>> other-config:hwaddr=\"f2:ff:00:00:00:02\"]) >>>>> + >>>>> +AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"]) >>>>> +AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"]) >>>>> + >>>>> +ADD_NAMESPACES(at_ns0) >>>>> + >>>>> +dnl Set up underlay link from host into the namespace using veth pair. >>>>> +ADD_VETH(p0, at_ns0, br-underlay, "172.31.1.1/24", f2:ff:00:00:00:03) >>>>> +AT_CHECK([ip addr add dev br-underlay "172.31.1.100/24"]) >>>>> +AT_CHECK([ip link set dev br-underlay up]) >>>>> + >>>>> +dnl Set up tunnel endpoints on OVS outside the namespace and simulate >>>>> a native >>>>> +dnl linux device inside the namespace. >>>>> +ADD_OVS_TUNNEL([erspan], [br0], [at_erspan0], [172.31.1.1], [ >>>>> 10.1.1.100/24], [options:key=1 options:erspan_ver=2 >>>>> options:erspan_dir=1 options:erspan_hwid=0x7]) >>>>> + >>>>> +ip netns exec at_ns0 tcpdump -U -i p0 -w p0.pcap & >>>>> +sleep 1 >>>>> + >>>>> +dnl First, check the underlay >>>>> +NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 172.31.1.100 | >>>>> FORMAT_PING], [0], [dnl >>>>> +3 packets transmitted, 3 received, 0% packet loss, time 0ms >>>>> +]) >>>>> + >>>>> +dnl Okay, send raw arp request and icmp echo request. >>>>> +ovs-ofctl -O OpenFlow13 packet-out br-underlay "in_port=1 >>>>> packet=f2ff00000002f2ff00000003080045000052373d4000402fa89ca >>>>> c1f0101ac1f0164100088be00000006200000016f54b41700008078fffff >>>>> ffffffff2ff0000000408060001080006040001f2ff000000040a0101010000000000000a010164 >>>>> actions=normal" >>>>> + >>>>> +sleep 1 >>>>> +AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "0806 0001 0800 0604 >>>>> 0002 f2ff 0000" 2>&1 1>/dev/null]) >>>>> +AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "0a01 0164 f2ff 0000 >>>>> 0004 0a01 0101" 2>&1 1>/dev/null]) >>>>> + >>>>> +ovs-ofctl -O OpenFlow13 packet-out br-underlay "in_port=1 >>>>> packet=f2ff00000002f2ff0000000308004500009287e14000402f57b8a >>>>> c1f0101ac1f0164100088be0000000520000001144cd5a400008078f2ff0 >>>>> 0000001f2ff0000000408004500005c38d640004001eb640a0101010a010 >>>>> 16408005e57585f0001df6c6b5b0000000045bc050000000000101112131 >>>>> 415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f >>>>> actions=normal" >>>>> >>>> >>>> The above packet hex is already encapsulated with ERSPAN >>>> (https://www.gasmi.net/hpd/ can help decode) >>>> So this packet does not exercise the ERSPAN implementation in OVS. >>>> >>>> Can we generate packet from br0 instead of br-underlay? >>>> >>>> Thanks >>>> William >>>> >>>> >>>>> + >>>>> +sleep 1 >>>>> +AT_CHECK([tcpdump -xx -r p0.pcap 2>&1 | egrep "IP 172.31.1.100 > >>>>> 172.31.1.1: GREv0, .* length 126" 2>&1 1>/dev/null]) >>>>> + >>>>> +OVS_TRAFFIC_VSWITCHD_STOP >>>>> +AT_CLEANUP >>>>> + >>>>> AT_SETUP([datapath - clone action]) >>>>> OVS_TRAFFIC_VSWITCHD_START() >>>>> >>>>> -- >>>>> 2.7.4 >>>>> >>>>> _______________________________________________ >>>>> dev mailing list >>>>> d...@openvswitch.org >>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >>>>> >>>> >>>> >>> >> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev