On Mon, 15 Aug 2016 12:58:09 +0300, a...@vadai.me wrote: > On Mon, Aug 15, 2016 at 12:50:39PM +0300, Shmulik Ladkani wrote: > > On Mon, 15 Aug 2016 12:08:04 +0300, a...@vadai.me wrote: > > > > > > Any objection to the following? > > > > > > # ENCAP rule > > > tc filter add dev $ETH protocol ip parent ffff: prio 10 \ > > > flower ip_proto 1 \ > > > action set_tunnel_key src_ip 11.11.0.1 dst_ip 11.11.0.2 key_id > > > 11 dst_port 4789 \ > > > > Ability to control few tun_flags (e.g. TUNNEL_CSUM, TUNNEL_DONT_FRAGMENT) > > might be useful too. > > I guess it should be added when needed. Currenly I don't have a use case > for that.
Sure. > > > # DECAP rule > > > tc filter add dev $VXLAN protocol ip parent ffff: prio 10 \ > > > flower \ > > > enc_src_ip 11.11.0.2 enc_dst_ip 11.11.0.1 enc_key_id 11 > > > \ > > > ip_proto 1 \ > > > > You might want to match the tunnel's udp port as well, for symmetry. > > actually, now that you raise it, the udp port is already an attribute of > the vxlan device. So I think it should be ommitted in both encap and > decap. Selecting the udp port will be done when creating the vxlan > device. Sounds better. Manual port override can be added if needed.
