Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow
On Fri, Feb 23, 2018 at 2:17 PM, Ben Pfaff wrote: > > On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote: > > On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff wrote: > > > > > > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez wrote: > > > > @Han, I can try rebase the patch if you want but that was > > > > basically renaming the Address_Set table and from Ben's > > > > comment, it may be better to keep the name. Not sure, > > > > however, how we can proceed to address Lucas' points in > > > > this thread. > > > > > > I wouldn't rename the table. It sounds like the priority should be to > > > add support for sets of port names. I thought that there was already a > > > patch for that to be rebased, but maybe I misunderstood. > > > > I feel it is better to add a new table for port group explicitly, and the > > column type can be a set of weak reference to Logical_Switch_Port. > > The benefits are: > > - Better data integrity: deleting a lport automatically deletes from the > > port group > > - No confusion about the type of records in a single table > > - Existing Address_Set mechanism will continue to be supported without any > > change > > - Furthermore, the race condition issue brought up by Lucas can be solved > > by supporting port-group in IP address match condition in ovn-controller, > > so that all addresses in the lports are used just like how AddressSet is > > used today. And there is no need for Neutron networking-ovn to use > > AddressSet any more. Since addresses are deduced from lports, the ordering > > of deleting/adding doesn't matter any more. > > > > How does this sound? > > Will we want sets of Logical_Router_Ports later? At least I don't see any use case in Neutron for router ports since Security Group is only for VIF ports. There is another tricky point I see while working on implementation. In Neutron, SG can be applied to ports across different networks, but in OVN lports works only on its own datapath, so in ovn-controller we need to be able to pickup related ports from the port-group when translating lflows for each datapath. I hope this is not an issue. Otherwise, Neutron plugin will have to divide the group of ports into sub-groups according to the lswitch they belong to, which would be a pain. Thanks, Han ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Cannot change vxlan egress (source) ports
On Fri, Feb 16, 2018 at 12:50:57AM -0300, José Miguel Guzmán wrote: > Hello > > I need to change the range of source ports for VXLAN tunnels. > > Although I tried with set dst_port to 2000 > # ovs-vsctl add-port br-ovs vxlan3 -- set interface vxlan3 type=vxlan > options:remote_ip=192.168.111.203 options:dst_port=2 > > and egress port range to 2-20001 > # ovs-appctl tnl/egress_port_range 2 20001 > # ovs-appctl tnl/egress_port_range > Tunnel UDP source port range: 2-20001 tnl/egress_port_range only influences the behavior of the DPDK-based tunnel implementation in OVS. If you're using the kernel implementation of tunneling, it will have no effect. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] invalid Ethertype 0 in flow key
This is an unusual problem that I haven't seen reported by others. Is there anything special about your machine, your kernel, your build, etc.? Whether you specify dst_port should not make a difference. This is implemented at a low level, so I don't know why it would change the behavior you see. On Sat, Feb 17, 2018 at 04:20:36AM +0500, Jamshaid Faisal wrote: > hmm i got some more info actually > if i use options:dst_port=x in vxlan setup command above, i dont get > those errors in log. It means i have to use dst_port > however i read this in documents > > "By default, Open vSwitch will use the assigned IANA port for VXLAN, which > is 4789" > > Whats really going on there, VXLAN works without specifying dst_port but > with these errors in log. > so should i use dst_port ? > > On Sat, Feb 17, 2018 at 4:08 AM, Jamshaid Faisal wrote: > > > I got some more details, Here is exactly how to get it on a clean install > > > > rm -rf /etc/openvswitch/conf.db > > service openvswitch restart > > ovs-vsctl add-br mybridge > > ovs-vsctl --may-exist add-port mybridge myport -- set interface myport > > type=vxlan options:remote_ip=10.1.1.1 > > > > And there you go, i start getting below lines in /var/log/messages > > > > ovs-vswitchd: ovs|1|odp_util(revalidator18)|ERR|invalid Ethertype 0 > > in flow key > > ovs-vswitchd: ovs|2|odp_util(revalidator18)|ERR|invalid Ethertype 0 > > in flow key > > ovs-vswitchd: ovs|3|odp_util(revalidator18)|ERR|invalid Ethertype 0 > > in flow key > > ovs-vswitchd: ovs|4|odp_util(revalidator18)|ERR|invalid Ethertype 0 > > in flow key > > ovs-vswitchd: ovs|5|odp_util(revalidator18)|ERR|invalid Ethertype 0 > > in flow key > > > > What i am doing wrong? > > > > On Tue, Feb 13, 2018 at 1:10 AM, Jamshaid Faisal > > wrote: > > > >> Hello > >> > >> Lately i have seen a lot of below messages in log (/var/log/messages). It > >> is happening no matter which OVS version i use. Below log is from ovs 2.7.2 > >> > >> > >> === > >> Feb 12 12:03:21 SGP1-1-10 ovs-vswitchd: > >> ovs|00135|odp_util(revalidator72)|ERR|Dropped > >> 27 log messages in last 58 seconds (most recently, 3 seconds ago) due to > >> excessive rate > >> Feb 12 12:03:21 SGP1-1-10 ovs-vswitchd: > >> ovs|00136|odp_util(revalidator72)|ERR|invalid > >> Ethertype 0 in flow key > >> === > >> > >> > >> They even happens with minimum config without vxlan etc. > >> I am using XEN and its hot-plug script vif-openvsiwtch. Openvswitch is > >> compiled with default options. > >> > >> What does these messages really mean? > >> > >> I dont see any functional issues, VMs have network, VXLAN also works > >> fine, But why lot of above messages in log ? > >> > >> Please help. > >> > >> Regards > >> > >> > > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow
On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote: > On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff wrote: > > > > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez wrote: > > > @Han, I can try rebase the patch if you want but that was > > > basically renaming the Address_Set table and from Ben's > > > comment, it may be better to keep the name. Not sure, > > > however, how we can proceed to address Lucas' points in > > > this thread. > > > > I wouldn't rename the table. It sounds like the priority should be to > > add support for sets of port names. I thought that there was already a > > patch for that to be rebased, but maybe I misunderstood. > > I feel it is better to add a new table for port group explicitly, and the > column type can be a set of weak reference to Logical_Switch_Port. > The benefits are: > - Better data integrity: deleting a lport automatically deletes from the > port group > - No confusion about the type of records in a single table > - Existing Address_Set mechanism will continue to be supported without any > change > - Furthermore, the race condition issue brought up by Lucas can be solved > by supporting port-group in IP address match condition in ovn-controller, > so that all addresses in the lports are used just like how AddressSet is > used today. And there is no need for Neutron networking-ovn to use > AddressSet any more. Since addresses are deduced from lports, the ordering > of deleting/adding doesn't matter any more. > > How does this sound? Will we want sets of Logical_Router_Ports later? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] ERROR: No build ID note found in
Encountered the following error when building RPM for RHEL. Tarball: http://openvswitch.org/releases/openvswitch-2.9.0.tar.gz $ rpmbuild -bb rhel/openvswitch.spec ... libtool: warning: remember to run 'libtool --finish /usr/lib64' /usr/bin/mkdir -p '/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin' /bin/sh ./libtool --mode=install /usr/bin/install -c utilities/ovs-appctl utilities/ovs-testcontroller utilities/ovs-dpctl utilities/ovs-ofctl utilities/ovs-vsctl ovsdb/ovsdb-tool ovsdb/ovsdb-client vtep/vtep-ctl ovn/controller/ovn-controller ovn/controller-vtep/ovn-controller-vtep ovn/northd/ovn-northd ovn/utilities/ovn-nbctl ovn/utilities/ovn-sbctl ovn/utilities/ovn-trace '/home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c utilities/.libs/ovs-appctl /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-appctl libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c utilities/.libs/ovs-testcontroller /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-testcontroller libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c utilities/.libs/ovs-dpctl /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-dpctl libtool: warning: 'ofproto/libofproto.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c utilities/.libs/ovs-ofctl /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-ofctl libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c utilities/.libs/ovs-vsctl /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovs-vsctl libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c ovsdb/.libs/ovsdb-tool /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovsdb-tool libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c ovsdb/.libs/ovsdb-client /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovsdb-client libtool: warning: 'vtep/libvtep.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c vtep/.libs/vtep-ctl /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/vtep-ctl libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c ovn/controller/.libs/ovn-controller /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-controller libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: warning: 'vtep/libvtep.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c ovn/controller-vtep/.libs/ovn-controller-vtep /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-controller-vtep libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64' libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c ovn/northd/.libs/ovn-northd /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-northd libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64' libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c ovn/utilities/.libs/ovn-nbctl /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-nbctl libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64' libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed in '/usr/lib64' libtool: install: /usr/bin/install -c ovn/utilities/.libs/ovn-sbctl /home/greenpau/rpmbuild/BUILDROOT/openvswitch-2.9.0-1.x86_64/usr/bin/ovn-sbctl libtool: warning: 'ovn/lib/libovn.la' has not been installed in '/usr/lib64' libtool: warning: 'ovsdb/libovsdb.la' has not been installed in '/usr/lib64' libtool: warning: 'lib/libopenvswitch.la' has not been installed
Re: [ovs-discuss] Is a new field in flow.h necessary for matching on a custom v6 extension header?
Ultimately, I expect a P4-based solution, in which the controller supplies a P4 program that extracts the fields that it is interested in. This is my big project for OVS 2.10. (I don't know how successful I'll be yet.) On Fri, Feb 23, 2018 at 12:37:40AM +0100, Alan Kayahan wrote: > I understand that there must be a construct in the struct flow, and > introducing a new be32 will save the day for me. However looking at this > from a broader perspective, say matching on the fields of any v6 extension > header made into the OF specification, neither adding individual fields nor > adding every v6 extension header into the struct flow looks elegant to me. > What do you think? > > 2018-02-21 17:10 GMT+01:00 Ben Pfaff : > > > On Mon, Feb 19, 2018 at 06:15:30PM +0100, Alan Kayahan wrote: > > > I have a custom v6 extension header, in which I would like to perform an > > > LPM match on only one 32bit field. > > > > > > Since an extension header is technically not a new field, do I still need > > > to introduce anything in the struct flow? > > > > Without anything in struct flow, how do you propose to match on it? > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss