> I think that what's happening is that when build_tunnel_send()
> serializes the ODP action for push_tunnel, it doesn't update the
> 'flow' to reflect the new encapsulated state of the packet. Then, when
> calling apply_nested_clone_actions() it performs lookup in the second
> bridge using the unmodified flow, ie as though it hasn't been
> encapsulated at all. If, for instance, on the underlay bridge you
> match on the tunnel protocol type or port and attempt to forward such
> packets directly to the external interface then have a default drop
> for packets that don't match, you'll see the traffic get dropped. The
> resulting datapath flows can end up generating a set of actions with
> "clone(drop),push_tnl(...)", which also seems wrong.
>
> William and I have been looking at this a bit, but it'd be good if you
> had a chance to look too. I think that William is working on a simpler
> test case to reproduce. For reference if you are not familiar with
> "make check-system-userspace" tests, there is some documentation
> available below---the system-traffic.at tests are the same for 'make
> check-kernel' and 'make check-system-userspace'.
>
> http://docs.openvswitch.org/en/latest/topics/testing/#datapath-testing
>
> Cheers,
> Joe
Hi Joe,
Thank you for the notification! I've observed the faulty behavior when the
packet is sent out on a patch port after a tunnel header was pushed. I have a
script to setup a simple tunneling scenario on a single host for testing.
The attached script creates and connects two namespaces (ns1, ns2) over a
userspace tunnel like below.
# GRE tunneling test setup
192.168.10.10
| +-------------+ +-------------+
| | | | | 192.168.10.20
ns1 <-->o br-in1 | | br-in2 | |
| | | o<--> ns2
+------o------+ +------o------+
gre1 gre2
10.0.0.1 LOCAL 20.0.0.2 LOCAL
(10.0.0.2) +-----------o-+ (20.0.0.1) +-----------o-+
| | | |
| br-p1 | | br-p2 |
| | | |
+------o------+ +------o------+
patch1/veth1 | | patch2/veth2
+--------------------------------+
If I use veth ports for the tunnel, then ping between ns1 and ns2 does work
fine.
> ./setup_tunnel.sh
> ip netns exec ns1 ping 192.168.10.20 -c 1
PING 192.168.10.20 (192.168.10.20) 56(84) bytes of data.
64 bytes from 192.168.10.20: icmp_seq=1 ttl=64 time=1.31 ms
--- 192.168.10.20 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.312/1.312/1.312/0.000 ms
If I create patch ports instead of the veth ones (passing 'patch-port' as arg
to the script), then ping does not work anymore. I can see the
"clone(drop),push_tnl(...)" datapath flow as you mentioned before.
> ./setup_tunnel.sh patch-port
> ip netns exec ns1 ping 192.168.10.20 -c 1
PING 192.168.10.20 (192.168.10.20) 56(84) bytes of data.
--- 192.168.10.20 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
I've been working on a fix, but have not found a proper solution yet.
Best regards,
Zoltan
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
