diff mbox

[ovs-dev,3/5] check-kernel: 802.1ad: Add conntrack ping tests for CVLANs.

Message ID 1469728449-28857-4-git-send-email-e@erig.me
State Superseded
Headers show

Commit Message

Eric Garver July 28, 2016, 5:54 p.m. UTC
Signed-off-by: Eric Garver <e@erig.me>
---
 tests/system-traffic.at | 106 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 106 insertions(+)

Comments

Joe Stringer July 29, 2016, 6:30 p.m. UTC | #1
On 28 July 2016 at 10:54, Eric Garver <e@erig.me> wrote:
> Signed-off-by: Eric Garver <e@erig.me>

Can you describe your setup? (distro, kernel)

This particular test seems to fail for me with kernel 3.19.0-58
(ubuntu) and the out-of-tree module from OVS repo. It'd be nice to
narrow down to find out why. If you get some time to investigate, that
would be great but otherwise I'll put it on my queue and take a look
at some point.
Joe Stringer July 29, 2016, 6:34 p.m. UTC | #2
On 29 July 2016 at 11:30, Joe Stringer <joe@ovn.org> wrote:
> On 28 July 2016 at 10:54, Eric Garver <e@erig.me> wrote:
>> Signed-off-by: Eric Garver <e@erig.me>
>
> Can you describe your setup? (distro, kernel)
>
> This particular test seems to fail for me with kernel 3.19.0-58
> (ubuntu) and the out-of-tree module from OVS repo. It'd be nice to
> narrow down to find out why. If you get some time to investigate, that
> would be great but otherwise I'll put it on my queue and take a look
> at some point.

I should probably add that if you're testing with upstream linux and
everything is happy there then it's possible there's just a bug that
only exists in our backport (for example, because we didn't backport
an upstream fix yet).
Eric Garver July 29, 2016, 8:48 p.m. UTC | #3
On Fri, Jul 29, 2016 at 11:34:24AM -0700, Joe Stringer wrote:
> On 29 July 2016 at 11:30, Joe Stringer <joe@ovn.org> wrote:
> > On 28 July 2016 at 10:54, Eric Garver <e@erig.me> wrote:
> >> Signed-off-by: Eric Garver <e@erig.me>
> >
> > Can you describe your setup? (distro, kernel)

RHEL-7.2
Upstream kernel 4.7.0-rc7

> >
> > This particular test seems to fail for me with kernel 3.19.0-58
> > (ubuntu) and the out-of-tree module from OVS repo. It'd be nice to
> > narrow down to find out why. If you get some time to investigate, that
> > would be great but otherwise I'll put it on my queue and take a look
> > at some point.
> 
> I should probably add that if you're testing with upstream linux and
> everything is happy there then it's possible there's just a bug that
> only exists in our backport (for example, because we didn't backport
> an upstream fix yet).

I think I hinted at this in an earlier email.

My guess is that a kernel module _without_ 802.1ad will parse 0x8100 as
the ethertype. It doesn't know to parse an additional VLAN.
In this test the frames look like..

 [eth hdr | 802.1ad | 802.1q | 0x800 | IP header | ICMP]
                      ^^^^^^
                      Normally the position of the ethertype
                      for single tagged packets.

This is why the test should be skipped if 802.1ad support is not
present.

Actually, it is probably parsing _no_ VLAN and using 0x88a8 as the
ethertype. The current code looks for 0x8100 and only 0x8100. If it
finds something else it assumes that's the ethertype.
Joe Stringer July 29, 2016, 8:53 p.m. UTC | #4
On 29 July 2016 at 13:48, Eric Garver <e@erig.me> wrote:
> On Fri, Jul 29, 2016 at 11:34:24AM -0700, Joe Stringer wrote:
>> On 29 July 2016 at 11:30, Joe Stringer <joe@ovn.org> wrote:
>> > On 28 July 2016 at 10:54, Eric Garver <e@erig.me> wrote:
>> >> Signed-off-by: Eric Garver <e@erig.me>
>> >
>> > Can you describe your setup? (distro, kernel)
>
> RHEL-7.2
> Upstream kernel 4.7.0-rc7
>
>> >
>> > This particular test seems to fail for me with kernel 3.19.0-58
>> > (ubuntu) and the out-of-tree module from OVS repo. It'd be nice to
>> > narrow down to find out why. If you get some time to investigate, that
>> > would be great but otherwise I'll put it on my queue and take a look
>> > at some point.
>>
>> I should probably add that if you're testing with upstream linux and
>> everything is happy there then it's possible there's just a bug that
>> only exists in our backport (for example, because we didn't backport
>> an upstream fix yet).
>
> I think I hinted at this in an earlier email.
>
> My guess is that a kernel module _without_ 802.1ad will parse 0x8100 as
> the ethertype. It doesn't know to parse an additional VLAN.
> In this test the frames look like..
>
>  [eth hdr | 802.1ad | 802.1q | 0x800 | IP header | ICMP]
>                       ^^^^^^
>                       Normally the position of the ethertype
>                       for single tagged packets.
>
> This is why the test should be skipped if 802.1ad support is not
> present.
>
> Actually, it is probably parsing _no_ VLAN and using 0x88a8 as the
> ethertype. The current code looks for 0x8100 and only 0x8100. If it
> finds something else it assumes that's the ethertype.

OK great, the macro should handle this properly.
diff mbox

Patch

diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 4f72292e5490..817eca1d5fea 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -1747,6 +1747,56 @@  NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 10.2.2.2 | FORMAT_PING
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
+AT_SETUP([conntrack - IPv4 fragmentation + cvlan])
+CHECK_CONNTRACK()
+OVS_TRAFFIC_VSWITCHD_START()
+OVS_CHECK_8021AD()
+
+ADD_NAMESPACES(at_ns0, at_ns1)
+
+ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
+ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
+
+ADD_SVLAN(p0, at_ns0, 4094, "10.255.2.1/24")
+ADD_SVLAN(p1, at_ns1, 4094, "10.255.2.2/24")
+
+ADD_CVLAN(p0.4094, at_ns0, 100, "10.2.2.1/24")
+ADD_CVLAN(p1.4094, at_ns1, 100, "10.2.2.2/24")
+
+dnl Sending ping through conntrack
+AT_DATA([flows.txt], [dnl
+priority=1,action=drop
+priority=10,arp,action=normal
+priority=100,in_port=1,icmp,action=ct(commit,zone=9),2
+priority=100,in_port=2,ct_state=-trk,icmp,action=ct(table=0,zone=9)
+priority=100,in_port=2,ct_state=+trk+est-new,icmp,action=1
+])
+
+AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt])
+
+dnl Ipv4 fragmentation connectivity check.
+NS_CHECK_EXEC([at_ns0], [ping -s 1600 -q -c 3 -i 0.3 -w 2 10.2.2.2 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Ipv4 fragmentation connectivity check. (outer svlan)
+NS_CHECK_EXEC([at_ns0], [ping -s 1600 -q -c 3 -i 0.3 -w 2 10.255.2.2 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Ipv4 larger fragmentation connectivity check.
+NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 10.2.2.2 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Ipv4 larger fragmentation connectivity check. (outer svlan)
+NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 10.255.2.2 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+OVS_TRAFFIC_VSWITCHD_STOP
+AT_CLEANUP
+
 AT_SETUP([conntrack - IPv6 fragmentation])
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
@@ -1868,6 +1918,62 @@  NS_CHECK_EXEC([at_ns0], [ping6 -s 3200 -q -c 3 -i 0.3 -w 2 fc00:1::4 | FORMAT_PI
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
+AT_SETUP([conntrack - IPv6 fragmentation + cvlan])
+CHECK_CONNTRACK()
+OVS_TRAFFIC_VSWITCHD_START()
+OVS_CHECK_8021AD()
+
+ADD_NAMESPACES(at_ns0, at_ns1)
+
+ADD_VETH(p0, at_ns0, br0, "fc00::1/96")
+ADD_VETH(p1, at_ns1, br0, "fc00::2/96")
+
+ADD_SVLAN(p0, at_ns0, 4094, "fc00:ffff::3/96")
+ADD_SVLAN(p1, at_ns1, 4094, "fc00:ffff::4/96")
+
+ADD_CVLAN(p0.4094, at_ns0, 100, "fc00:1::3/96")
+ADD_CVLAN(p1.4094, at_ns1, 100, "fc00:1::4/96")
+
+dnl Sending ping through conntrack
+AT_DATA([flows.txt], [dnl
+priority=1,action=drop
+priority=10,in_port=1,ipv6,action=ct(commit,zone=9),2
+priority=10,in_port=2,ct_state=-trk,ipv6,action=ct(table=0,zone=9)
+priority=10,in_port=2,ct_state=+trk+est-new,ipv6,action=1
+priority=100,icmp6,icmp_type=135,action=normal
+priority=100,icmp6,icmp_type=136,action=normal
+])
+
+AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt])
+
+dnl Linux seems to take a little time to get its IPv6 stack in order. Without
+dnl waiting, we get occasional failures due to the following error:
+dnl "connect: Cannot assign requested address"
+OVS_WAIT_UNTIL([ip netns exec at_ns0 ping6 -c 1 fc00::2])
+
+dnl Ipv6 fragmentation connectivity check.
+NS_CHECK_EXEC([at_ns0], [ping6 -s 1600 -q -c 3 -i 0.3 -w 2 fc00:1::4 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Ipv6 fragmentation connectivity check. (outer svlan)
+NS_CHECK_EXEC([at_ns0], [ping6 -s 1600 -q -c 3 -i 0.3 -w 2 fc00:ffff::4 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Ipv6 larger fragmentation connectivity check.
+NS_CHECK_EXEC([at_ns0], [ping6 -s 3200 -q -c 3 -i 0.3 -w 2 fc00:1::4 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Ipv6 larger fragmentation connectivity check. (outer svlan)
+NS_CHECK_EXEC([at_ns0], [ping6 -s 3200 -q -c 3 -i 0.3 -w 2 fc00:ffff::4 | FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+OVS_TRAFFIC_VSWITCHD_STOP
+AT_CLEANUP
+
 AT_SETUP([conntrack - Fragmentation over vxlan])
 OVS_CHECK_VXLAN()
 CHECK_CONNTRACK()