[ovs-discuss] ovs-vtep - import error
Hello, after compiling (gcc) openvswitch-2.11.1 on ubuntu mate 18.04 LTS, at step 6 of "How to use VTEP Emulator" the command (from /usr/local/share/openvswitch/scripts): ./ovs-vtep . fails with error message: *Traceback (most recent call last):* * File "./ovs-vtep", line 26, in * * import ovs.daemon* *ImportError: No module named ovs.daemon* thanks in advance Massimiliano Bavelloni ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] VLAN Tag Match
On Sun, Aug 18, 2019 at 08:39:56PM +0530, V Sai Surya Laxman Rao Bellala wrote: > Does Openvswitch version 2.5 allows to perform VLAN Tag matching? Yes. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Meter tables
On Mon, Aug 19, 2019 at 10:45:07AM +0530, V Sai Surya Laxman Rao Bellala wrote: > Can anyone explain what are the advantages of meter tables? They allow you to use meters. Probably that is not your real question, but I don't know what your real question is. What do you really want to know? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Building OvS with clang 32bit - shared and not shared libraries
OVS doesn't do anything special when it comes to arithmetic. I haven't heard of Clang having trouble with this before. You should probably make sure that these kinds of arithmetic operations work OK in trivial test cases with "clang -m32". On Mon, Aug 19, 2019 at 09:09:49AM +, Sirvys, Andrius wrote: > Had a go at your suggestion, however exact same issue. > Included the full failure. > > lib/.libs/libopenvswitch.a(rconn.o): In function `llsat_mul': > rconn.c:(.text+0x3c0): undefined reference to `__mulodi4' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > Makefile:4623: recipe for target 'utilities/ovs-testcontroller' failed > make[2]: *** [utilities/ovs-testcontroller] Error 1 > make[2]: *** Waiting for unfinished jobs > lib/.libs/libopenvswitch.a(rconn.o): In function `llsat_mul': > rconn.c:(.text+0x3c0): undefined reference to `__mulodi4' > lib/.libs/libopenvswitch.a(rconn.o): In function `llsat_mul': > rconn.c:(.text+0x3c0): undefined reference to `__mulodi4' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > Makefile:4341: recipe for target 'ovn/controller/ovn-controller' failed > make[2]: *** [ovn/controller/ovn-controller] Error 1 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > Makefile:4653: recipe for target 'vswitchd/ovs-vswitchd' failed > make[2]: *** [vswitchd/ovs-vswitchd] Error 1 > tests/test-util.o: In function `llsat_mul': > test-util.c:(.text+0xd3f0): undefined reference to `__mulodi4' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > Makefile:4543: recipe for target 'tests/ovstest' failed > make[2]: *** [tests/ovstest] Error 1 > make[2]: Leaving directory '/root/ovsClang' > Makefile:6058: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '/root/ovsClang' > Makefile:3625: recipe for target 'all' failed > make: *** [all] Error 2 > > > Thanks again. > > > -Original Message- > > From: Ben Pfaff [mailto:b...@ovn.org] > > Sent: Friday, August 16, 2019 8:25 PM > > To: Sirvys, Andrius > > Cc: ovs-discuss@openvswitch.org > > Subject: Re: [ovs-discuss] Building OvS with clang 32bit - shared and not > > shared > > libraries > > > > On Tue, Aug 06, 2019 at 04:06:53PM +, Sirvys, Andrius wrote: > > > Hi. > > > > > > I'm trying to build 32 bit OvS using clang. It's on Ubuntu 18.04 LTS > > > I'm on commit a8f005cf26fd16f77133d67fe4b205409fc444db (HEAD -> > > > master, origin/master, origin/HEAD) > > > Author: John Hurley > > > Date: Tue Jul 30 12:05:17 2019 +0100 > > > > > > > > > The configuration I'm using is > > >./configure CC=clang --enable-Werror > > > --enable-ssl/--disable-ssl > > > make -j CFLAGS=-m32 > > > > > > > > > No matter if I build with shared libraries enabled or disabled I keep > > > running into > > the same issue > > > lib/.libs/libopenvswitch.a(rconn.o): In function `llsat_mul': > > > rconn.c:(.text+0x3c0): undefined reference to `__mulodi4' > > > > > > I'm thinking it could possibly be that this 32bit build is trying to link > > > with some > > 64bit library? Not exactly sure what's going on. > > > Would appreciate any advice or pointers on where to go or how to fix this. > > > > It's probably a bad idea to add CFLAGS that change the architecture after > > running "configure". Try adding CFLAGS=-m32 to the configure command line > > instead. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OpenVswitch
Not sure what steps you used to compile and install 2.11. Use `export OVS_RUNDIR="/var/run/openvswitch" and then try vsctl commands. On Wed, Aug 21, 2019 at 2:43 AM V Sai Surya Laxman Rao Bellala < laxmanraobell...@gmail.com> wrote: > Hello all, > > Can anyone help me in solving this Bug? > I installed OVS-2.11 latest version and when i am adding the bridge to the > openvswitch.I am getting the below error. > > *ovs-vsctl: unix://var/run/openvswitch/db.sock: database connection failed > (No such file or directory* > > Please help me in solving this problem > > Regards > Laxman > ___ > 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] [OVN] Aging mechanism for MAC_Binding table
On Tue, Aug 20, 2019 at 06:11:12PM -0700, Han Zhou wrote: > On Tue, Aug 20, 2019 at 4:57 PM Ben Pfaff wrote: > > > > Let me see if I'm following this correctly. This is what currently > > happens: > > > > - HV1 needs a MAC address for an IP so it broadcasts an ARP request. > > > > - The port with the IP address, on HV2, causes the MAC_Binding to be > > inserted. > > > > - Every ovn-controller inserts an OF flow for the binding. HV1 and > > perhaps other ovn-controllers use this flow to populate the MAC > > address for subsequent packets destined to the IP address in question. > > > > This proposal augments that with: > > > > - After a while, the binding goes idle and isn't used. The > > ovn-controllers gradually notice this and delete their OF flows for > > it. > > > > - HV3 eventually needs the binding again. It broadcasts an ARP request. > > > > - The port with the IP address causes the MAC_Binding to be inserted. > > This might still be on HV2 if the port hasn't moved, or it might be on > > HV4 if it has. > > > > Is that what you mean? It might work OK. > > > > Please do update the lifetime description in ovn-sb(5) under the > > MAC_Binding table regardless of what you implement. > > > > Thanks, > > > > Ben. > > > > On Tue, Aug 20, 2019 at 09:03:57AM +0200, Daniel Alvarez Sanchez wrote: > > > Hi folks, > > > > > > Reviving this thread as we're seeing this more and more problematic. > > > Combining the ideas mentioned up thread, Dumitru, Numan, Lucas and I > > > had some internal discussion where we came up with a possible approach > > > and we'd love to get feedback from you: > > > > > > - Local ovn-controller will always insert an OF rule per MAC_Binding > > > entry to match on src_ip + src_mac that will be sampled with a meter > > > to ovn-controller. > > > - When ovn-controller sees that one entry has not been hit "for a > > > while", it'll delete the OpenFlow rule in table 65 that fills the > > > eth.dst field with the MAC_Binding info. > > I assume the rules in table 65 can be "extended" for this purpose, instead > of adding extra rules for this. > > > > - This will result in further ARP requests from the instance(s) that > > > will refresh the MAC_Binding entries in the database. > > > > > > This could make troubleshooting a bit harder so at some point it'll be > > > great to have a mechanism in OVS where we could disable a flow instead > > > of deleting it. This way, one can tell that the flows in table 65 have > > > been disabled due to the aging mechanism in the local node. > > Sorry that I didn't understand this. Why do you want the flow being > disabled instead of deleted? I think if we want to avoid stale entries, we > do want to delete them, so that the stale data doesn't occupy the space in > flow table, neither in SB DB. It may be ok to add debug log for deleting a > aged entry in ovn-controller, for trouble shooting purpose? > > > > > > > Thoughts? Is there any performance consideration regarding the extra > > > flows and meters? > > Are you proposing shared meters or one meter per mac-binding? If it is per > mac-binding, I would be worried about the scalability considering that we > may have >10k of mac-bindings. Or should I be worried? Maybe Justin and Ben > can comment on the meter scalability. If it is a concern, I would suggest > the feature be configurable (i.e. enable/disable), so that it can be > enabled in environments where aging is required but number of mac-bindings > are not very high. That *is* a lot of meters. I'd suggest at least testing to make sure that it scales. I don't recall enough about the implementation to guess. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [OVN] Aging mechanism for MAC_Binding table
On Wed, Aug 21, 2019 at 3:11 AM Han Zhou wrote: > > > > On Tue, Aug 20, 2019 at 4:57 PM Ben Pfaff wrote: > > > > Let me see if I'm following this correctly. This is what currently > > happens: > > > > - HV1 needs a MAC address for an IP so it broadcasts an ARP request. > > > > - The port with the IP address, on HV2, causes the MAC_Binding to be > > inserted. > > > > - Every ovn-controller inserts an OF flow for the binding. HV1 and > > perhaps other ovn-controllers use this flow to populate the MAC > > address for subsequent packets destined to the IP address in question. > > > > This proposal augments that with: > > > > - After a while, the binding goes idle and isn't used. The > > ovn-controllers gradually notice this and delete their OF flows for > > it. > > > > - HV3 eventually needs the binding again. It broadcasts an ARP request. > > > > - The port with the IP address causes the MAC_Binding to be inserted. > > This might still be on HV2 if the port hasn't moved, or it might be on > > HV4 if it has. > > > > Is that what you mean? It might work OK. Yes, that's it. At some point we can look into enhancing this using the SB DB and if all ovn-controllers decided to ignore a particular MAC_Binding entry, then we can remove it from the DB from ovn-northd (or some other mechanism). > > > > Please do update the lifetime description in ovn-sb(5) under the > > MAC_Binding table regardless of what you implement. > > > > Thanks, > > > > Ben. > > > > On Tue, Aug 20, 2019 at 09:03:57AM +0200, Daniel Alvarez Sanchez wrote: > > > Hi folks, > > > > > > Reviving this thread as we're seeing this more and more problematic. > > > Combining the ideas mentioned up thread, Dumitru, Numan, Lucas and I > > > had some internal discussion where we came up with a possible approach > > > and we'd love to get feedback from you: > > > > > > - Local ovn-controller will always insert an OF rule per MAC_Binding > > > entry to match on src_ip + src_mac that will be sampled with a meter > > > to ovn-controller. > > > - When ovn-controller sees that one entry has not been hit "for a > > > while", it'll delete the OpenFlow rule in table 65 that fills the > > > eth.dst field with the MAC_Binding info. > > I assume the rules in table 65 can be "extended" for this purpose, instead of > adding extra rules for this. > > > > - This will result in further ARP requests from the instance(s) that > > > will refresh the MAC_Binding entries in the database. > > > > > > This could make troubleshooting a bit harder so at some point it'll be > > > great to have a mechanism in OVS where we could disable a flow instead > > > of deleting it. This way, one can tell that the flows in table 65 have > > > been disabled due to the aging mechanism in the local node. > > Sorry that I didn't understand this. Why do you want the flow being disabled > instead of deleted? I think if we want to avoid stale entries, we do want to > delete them, so that the stale data doesn't occupy the space in flow table, > neither in SB DB. It may be ok to add debug log for deleting a aged entry in > ovn-controller, for trouble shooting purpose? We can use traces as well, yes :) > > > > > > > Thoughts? Is there any performance consideration regarding the extra > > > flows and meters? > > Are you proposing shared meters or one meter per mac-binding? If it is per > mac-binding, I would be worried about the scalability considering that we may > have >10k of mac-bindings. Or should I be worried? Maybe Justin and Ben can > comment on the meter scalability. If it is a concern, I would suggest the > feature be configurable (i.e. enable/disable), so that it can be enabled in > environments where aging is required but number of mac-bindings are not very > high. I was talking about one meter per mac-binding but I'll defer the answer to others, as I don't know much about meters. I'm not a big fan of configuration options but unless we have a clear view on this, it makes sense to me to have a knob for the 'aging'. > > > > > > > Thanks a lot! > > > Daniel > > > > > > > > > On Tue, Jul 9, 2019 at 7:19 AM Ben Pfaff wrote: > > > > > > > > On Mon, Jul 08, 2019 at 06:19:23PM -0700, Han Zhou wrote: > > > > > On Thu, Jun 27, 2019 at 6:44 AM Ben Pfaff wrote: > > > > > > > > > > > > On Tue, Jun 25, 2019 at 01:05:21PM +0200, Daniel Alvarez Sanchez > > > > > > wrote: > > > > > > > Lately we've been trying to solve certain issues related to stale > > > > > > > entries in the MAC_Binding table (e.g. [0]). On the other hand, > > > > > > > for > > > > > > > the OpenStack + Octavia (Load Balancing service) use case, we see > > > > > > > that > > > > > > > a reused VIP can be as well affected by stale entries in this > > > > > > > table > > > > > > > due to the fact that it's never bound to a VIF so ovn-controller > > > > > > > won't > > > > > > > claim it and send the GARPs to update the neighbors. > > > > > > > > > > > > > > I'm not sure if other scenarios may suffer
Re: [ovs-discuss] Is there any document about nicira externtion
Many thanks. I will check that. The "nxm_packet_in_2" packet_in format contains userdata field. It could be used to save arp or dhcp data corresponded to the host in the flow. Then the controller do not need to constructor these caches. It's used in ovn. Ashish Varma 于2019年8月21日周三 上午12:46写道： > I have attempted to write a document explaining the Nicira extension which > is still a v1 patch for review. > > https://patchwork.ozlabs.org/patch/1145870/ > > Nicira extensions were added in the early days of OVS during early > OpenFlow versions and a lot of those extensions made it to standard > OpenFlow specifications. > packet_in message is supported in OpenFlow 1.3. Any specific reason to use > nxm_packet_in_2? > > Below is an example of OpenFlow 1.0 Nicira Vendor message 'Flow Mod' with > 'NXM' or Nicira Extensible Match fields generated using: > ovs-ofctl add-flow br1 "table=10, priority=100, cookie=0x0102030405060708 > ip, sctp, sctp_dst=9, actions=drop" > > This is an example to show how NXM is encoded. > > OVS NXM fields are described at > http://www.openvswitch.org/support/dist-docs/ovs-fields.7.txt > > 0x010x040x000x480x000x000x000x0a > 0x000x000x230x200x000x000x000x0d > 0x010x020x030x040x050x060x070x08 > 0x0a0x000x000x000x000x000x000x64 > 0xff0xff0xff0xff0xff0xff0x000x00 > 0x000x110x000x000x000x000x000x00 > 0x000x000x060x020x080x000x000x00 > 0x0c0x010x840x800x000x240x020x00 > 0x090x000x000x000x000x000x000x00 > > > // ofp_header with Version=1, Message Type=4 (Vendor) > 0x010x040x000x480x000x000x000x0a > > // Vendor id = 0x2320 Subtype = 0x00 0x0d (Where are these defined > ??) > 0x000x000x230x200x000x000x000x0d > > // Cookie > 0x010x020x030x040x050x060x070x08 > > // Command = 0x0a 0x00 (table-id=0x0a,command=add(0x00)) idle_time = 0 > hard_time = 0 priority = 100 > 0x0a0x000x000x000x000x000x000x64 > > // buffer_id = 0x out_port = OFPP_NONE(0x) flags = 0 > 0xff0xff0xff0xff0xff0xff0x000x00 > > // match_len = 0x11 padding= 0x > 0x000x110x000x000x000x000x000x00 > > // OFPXMC12_NXM_0 (nxm_vendor 0x) > nxm_field+hm=0x06,nxm_field=0x03,hm=0 nxm_length=0x02 value=0x0800 > (ethernet) > 0x000x000x060x020x080x00 > > // OFPXMC12_NXM_0 (nxm_vendor 0x) > nxm_field+hm=0x0c,nxm_field=0x06,hm=0 nxm_length=0x01 value=0x84 (sctp) > 0x000x000x0c0x010x84 > > // OFPXMC_OPENFLOW_BASIC (0x8000) nxm_field+hm=0x24,nxm_field=0x12,hm=0 > nxm_length=0x02 value=0x09 (sctp_dst_port) > 0x800x000x240x020x000x09 > > // padding 7 bytes of 0s > 0x000x000x000x000x000x000x00 > > > > Thanks, > Ashish > > On Tue, Aug 20, 2019 at 3:45 AM kai xi fan wrote: > >> Thanks. >> I have read the following file. >> https://github.com/openvswitch/ovs/blob/master/include/openflow/nicira >> -ext.h >> But it's too simple to understand. For example, nicira extension use >> properties in "nxm packet_in_2" packet in format. But there is no such >> openflow message format in detail. >> I have to tcpdump the openflow packet to understand it. >> May be there is a official document about this ? >> >> Numan Siddique 于2019年8月20日周二 下午3:37写道： >> >>> >>> >>> On Tue, Aug 20, 2019 at 7:35 AM kai xi fan wrote: >>> I am writing a controller to control ovs through openflow protocol. I found that when I dump flows from ovs using ovs-ofctl. It shows me so many fields prefixed with "NXM". And we plan to use "nxm packet_in_2" format. It also needs nicira extensions. So if the controller wants to communicate with ovs using openflow 1.3, I have to deal with nicira extensions. But I could not found any document about its format and the corresponding openflow message format. Could any one help me ? >>> >>> I think you can find useful information here - >>> https://github.com/openvswitch/ovs/blob/master/include/openflow/nicira-ext.h >>> >>> Thanks >>> Numan >>> >>> thanks. ___ 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 >> > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
