On Mon, 18 Apr 2016 06:57:22 -0300, Thadeu Lima de Souza Cascardo wrote: > I don't see how this address the case when the user adds a vxlan interface > created by the system. Like: > > ip link add vxlan_sys_4789 type vxlan id 10 remote 192.168.123.1 dstport 4789 > ovs-vsctl add-port br0 vxlan_sys_4789 > > Its driver would be vxlan. That goes to vxlan0 too.
Yes but that's a fundamental problem that cannot be solved. There's no way an interface created by the user can be *reliably* distinguished from an interface automatically created by ovs, whatever approach you choose. Anything that ovs does with the interface, the user can do, too. The only exception is adding the interface to ovs bridge - that can't be done with 'ip'. Thus, if you disallow adding of vxlan interfaces (i.e. 'ovs-vsctl add-port br0 iface' where 'iface' is an already created interface that is of vxlan type), then and only then you can be sure that the interfaces connected to the kernel datapath were automatically created by ovs. > But... wait a minute. We don't support adding devices name as vxlan_sys*. Such > names are reserved. I think that means we could probably rely on the names. They are not. You can easily create an interface named vxlan_sys_4789 by 'ip link add'. > That should be taken care of. We would get EINVAL, and that's why I return > EOPNOTSUPP if that's the case. Then, the code falls back to the compat mode. We would not get EINVAL. The interface will be created, netlink will return success but the interface won't be in the metadata mode. The same applies to all other configuration, e.g. VXLAN-GPE. The netlink command will succeed, the interface will be created but it won't be GPE. It sucks completely, it's a big gap in netlink design but all my attempts to solve this were rejected upstream. Jiri _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
