Re: [ovs-discuss] VPP in Ubuntu 18.04.3 VM

[Justin Pettit]

I suspect you’re more likely to get a response on a VPP mailing list instead of 
an OVS one.

--Justin


> On Apr 6, 2020, at 10:05 AM, Giridharan, Ganesan  wrote:
> 
> 
> Good morning. This is my first post here looking for some guidance on 
> building a certain type of test environment. I will try to concise it as much 
> as possible.
>  
> VPP in a Ubuntu 18.04 VM
>  
> Configure VPP with either “dpdk” vhost mode or native VPP mode. Does not 
> really matter for my testbed.
> Start a container running “testpmd” in “txonly” mode. I basically use this to 
> send packets to VPP bridge.
> Start a container running a dpdk application that just picks up packet from 
> rte_eth_rx_burst() and dumps it in the log.
> Both containers use “virtio-user” as “vdev” to connect to VPP’s “vhost” 
> sockets.
> Both interfaces are placed on a single bridge.
>  
> Case-1: Using DPDK vhost
> I am not seeing any packets sent by “testpmd” on this bridge.
> I have set “pcap trace rx intfc VHostEthernet1, think rx on this would be tx 
> on “testpmd”.
> I am not observing any packet indication.
>  
> Case-2: Using VPP native vhost
> Enable pcap trace on VirtualEthernet0/0/1
> Start testpmd to send packets.
> Packet indication is received on container-2.
> But all frames are NULL ( i.e contents are all zero ). But the length 
> indicates some data.
>  
> Thanks
> --GG
>  
>  
>  
> 
> 
> Notice: This e-mail together with any attachments may contain information of 
> Ribbon Communications Inc. that is confidential and/or proprietary for the 
> sole use of the intended recipient. Any review, disclosure, reliance or 
> distribution by others or forwarding without express permission is strictly 
> prohibited. If you are not the intended recipient, please notify the sender 
> immediately and then delete all copies, including any attachments.
> ___
> 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 charter

[Justin Pettit]

I looked through the charter, and it looks reasonable to me.  My only question 
was what the Series Agreement is.  That isn't in the OVS Charter, and it's not 
obvious to me what it is.

We should probably have the OVS and OVN TSCs each vote on the OVN charter.

--Justin


> On Jan 16, 2020, at 4:18 PM, Ben Pfaff  wrote:
> 
> There was some question in the OVN meeting last week (and in the
> conference at the end of last year) regarding whether OVN had been
> chartered and, if so, where was the charter.
> 
> I went through my email archive and, in the end, I was not entirely
> sure.  I emailed Mike Dolan at Linux Foundation to check and he helped
> me out quickly with a reference to the email where it was finalized and
> a copy of the final charter.  The new LF Collaborative Project was
> created on Nov. 4.  I'm attaching its charter to this email.
> 
> Some may feel that steps were skipped in the process.  I think that you
> are right about that.  Some of that is my fault.  I apologize.  However,
> the question is now, what should we do about it?  Are there significant
> changes that we want to make to the charter and, if some, what are they?
> 
> Thanks,
> 
> Ben.
> 

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] UDP datagram size effect at flow table hitting

[Justin Pettit]

> On Sep 11, 2019, at 7:04 AM, 병욱이  wrote:
> 
> I did a small experiment with ONOS 3.0.5, OVS 2.0.2(OF 1.0), mininet 2.3.0d5
> 
> I found when making flow rule about L4 port, hitting flow table
> doesn't work properly.
> 
> For example, about UDP flow, ip_src=10.0.0.3, ip_dst=10.0.0.2, udp_dst=5
> 
>   1)  cookie=0x4cef7faa8a, duration=332.717s, table=0, n_packets=8974,
>n_bytes=557090858, idle_age=153, priority=65050,ip,nw_dst=10.0.0.2
>actions=output:4
> 
>2) cookie=0x4c951b3b33, duration=332.636s, table=0, n_packets=10,
>
> n_bytes=460,idle_age=168,priority=65111,udp,nw_src=10.0.0.3,nw_dst=10.0.0.2,
>tp_dst=5 actions=output:3
> 
> Although the flow rule 2 have higher priority and more match field,
> the flow rule 2 was hit.
> 
> When doing trouble shooting, I found the UDP datagram size affect the result.
> 
> For 63kBytes datagram, the flow rule 1 is hit.
> 
> However for 1500Bytes datagram, the flow rule 2 is hit.
> 
> I think the datagram size degrade the match of OVS but I don't know exactly

63KB is pretty big for a datagram.  Is it getting fragmented?  If so, only the 
first fragment contains the UDP information.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch 2.12.0 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.12.0:

http://openvswitch.org/releases/openvswitch-2.12.0.tar.gz

A few other feature highlights of 2.12.0 include:

- OpenFlow 1.5 required features are available and is now enabled by default.

- Support for match and set IPv6 ND options type and reserved fields.

- IPv4 and IPv6 fragmentation support for userspace conntrack.

- Linux kernel support up to 5.0.

- Experimental support for Linux AF_XDP mode.

- OVN support for Policy-Based Routing (PBR), IGMP Snooping and Querier, and 
IPAM improvements.

- And many others.  See the full change log here:

http://openvswitch.org/releases/NEWS-2.12.0

Please note that the OVS 2.12 series will be the last to include OVN as part of 
the distribution.  Future development of OVN is occurring outside of OVS in its 
own project:

https://github.com/ovn-org

Enjoy!

--The Open vSwitch Team   

   
Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] 2.11.3, 2.10.4, 2.9.6, 2.8.8, 2.7.10, 2.6.7, and 2.5.9 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce a number of bug fix releases:

 http://openvswitch.org/releases/openvswitch-2.11.3.tar.gz

 http://openvswitch.org/releases/openvswitch-2.10.4.tar.gz

 http://openvswitch.org/releases/openvswitch-2.9.6.tar.gz

 http://openvswitch.org/releases/openvswitch-2.8.8.tar.gz

 http://openvswitch.org/releases/openvswitch-2.7.10.tar.gz

 http://openvswitch.org/releases/openvswitch-2.6.7.tar.gz

 http://openvswitch.org/releases/openvswitch-2.5.9.tar.gz

--The Open vSwitch Team 


Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Query on DEC_ttl action implementation in datapath

[Justin Pettit]

I understand.  This has been discussed previously on the mailing list.  You are 
welcome to submit a patch upstream to provide that capability, but I suspect 
you will get some resistance--especially from the Linux kernel community.

--Justin


> On Aug 27, 2019, at 11:25 PM, bindiya Kurle  wrote:
> 
> Hi Justin,
> 
> Thanks for the clarification. I agree to your point ,but consider a use-case 
> if I have routing decision only based on destination ip then as per current 
> implementation, ovs will add 2 flows (in data path)for packets coming from 
> different source and if the TTL happens to be different for them .This will 
> reduce number of flows that can be supported with ovs. If decrement TTL  was 
> done in kernel ,it would have ended in adding one flow only.
> 
> Regards,
> Bindiya
> 
> Regards,
> Bindiya
> 
> On Tue, Aug 27, 2019 at 9:48 PM Justin Pettit  wrote:
> I think it was considered cleaner from an ABI perspective, since it doesn't 
> require another action, since "set" was already supported.  In practice, I 
> don't think it's a problem, since usually a TTL decrement is associated with 
> a routing decision, and TTLs tend to be fairly static between two hosts.
> 
> --Justin
> 
> 
> > On Aug 27, 2019, at 1:11 AM, bindiya Kurle  wrote:
> > 
> > hi ,
> > I have a question related to dec_ttl action implemented in datapath.
> > when  dec_ttl action is configured in OVS following action get added in 
> > datapath.
> > 
> > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), 
> > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3,
> > 
> > if packet comes with different TTL on same port then one more action get 
> > added in datapath.
> > for ex:
> > recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), 
> > packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3,  
> > 
> > Could someone please explain why dec_ttl is implemeted as a set action  
> > rather than dec_ttl action.
> > 
> > 
> > I mean , why for different ttl one more rule get added rather than  just 
> > adding it as  following as done in userspace
> > 
> > recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3, 
> > bytes:294, used:0.737s, actions:dec_ttl,2 
> > 
> > Regards,
> > Bindiya
> > ___
> > 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] MTU / Fragmentation / VXLAN

[Justin Pettit]

> On Aug 25, 2019, at 9:38 PM, Heim, Dennis  wrote:
> 
> I have an issue with SIP phones registered to a Cisco Call Manager Express 
> (CME).
>  
> Network Layout:
> Phone->Physical Switch->OvS(A)VXLAN Overlay-OvS(B)—CME.
>  
> When the packet reaches  OvS(A) the sip (invite) packet for the phone call is 
> in tact (packet 51).
>  
> 
>  
> However, when I look at traces on OvS(B), I do not see that SIP invite. 
> Interesting enough, the SIP registration message arrives as the phone is 
> registered with the CME.

Are you sure that Packet 51 is the one that requires fragmentation?  According 
to your screenshot, it looks like the packet is 114 bytes.  1500 bytes is the 
most common MTU and a VXLAN encapsulation overhead is probably around 40 bytes, 
so there should be plenty of room for it.

The ICMP "fragmentation needed" error message would normally contain the first 
64 bytes or so of the packet that needs fragmenting.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Query on DEC_ttl action implementation in datapath

[Justin Pettit]

I think it was considered cleaner from an ABI perspective, since it doesn't 
require another action, since "set" was already supported.  In practice, I 
don't think it's a problem, since usually a TTL decrement is associated with a 
routing decision, and TTLs tend to be fairly static between two hosts.

--Justin


> On Aug 27, 2019, at 1:11 AM, bindiya Kurle  wrote:
> 
> hi ,
> I have a question related to dec_ttl action implemented in datapath.
> when  dec_ttl action is configured in OVS following action get added in 
> datapath.
> 
> recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), 
> packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3,
> 
> if packet comes with different TTL on same port then one more action get 
> added in datapath.
> for ex:
> recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), 
> packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3,  
> 
> Could someone please explain why dec_ttl is implemeted as a set action  
> rather than dec_ttl action.
> 
> 
> I mean , why for different ttl one more rule get added rather than  just 
> adding it as  following as done in userspace
> 
> recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3, 
> bytes:294, used:0.737s, actions:dec_ttl,2 
> 
> Regards,
> Bindiya
> ___
> 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] Meter tables

[Justin Pettit]

Full meter support was added in OVS 2.10.

--Justin


> On Aug 10, 2019, at 1:52 AM, V Sai Surya Laxman Rao Bellala 
>  wrote:
> 
> Hello all,
> Does Openvswitch support meter tables?
> If it supports, which version of openvswitch supports that.
> 
> 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] Zero-Copy in the upcall

[Justin Pettit]

> On Jul 31, 2019, at 1:14 PM, Adel Belkhiri  wrote:
> 
> Hey all,
> 
> In the recent versions of Openvswitch, whenever a packet is received and 
> doesn't match any flow within the datapath, it is zero-copied  to the 
> userspace. 
> 
> Does that mean the whole packet is zero-copied or only the data part of its 
> skb structure ?

Working from memory, I'm fairly certain it's the entire packet, since there's 
no queuing mechanism in the kernel datapath.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OFPACT_DEC_TTL in kernel space

[Justin Pettit]

> On Jun 25, 2019, at 2:02 PM, Sagar A  wrote:
> 
>> Is there a particular use-case that requires decrement?
>> 
> I have rule which wants to match on 'dst_ip' only. Since, code is touching 
> 'ttl', it becomes a match condition. For flows with same 'dst_ip' and 
> different ttls, result in different flows instead of having only one flow 
> with 'dst_ip' as match condition. Any suggestion to solve the problem?

You are directly calling the kernel datapath interface and not using 
ovs-vswitchd?  If you're using ovs-vswitchd, it will take care of matching the 
TTL for you when it pushes the flow down to the kernel.  If not, then you'd 
need to propose changes to the kernel.  I don't know whether they would accept 
such a patch without a compelling reason, since there's arguably a more 
flexible (although less efficient in some cases) mechanism already in place.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OFPACT_DEC_TTL in kernel space

[Justin Pettit]

We try to implement the minimum interface that we can in the kernel.  Usually 
the TTL doesn't change across a flow, so matching on a particular TTL value and 
setting a new value isn't a problem.  Plus, it allows us flexibility to stack 
multiple OpenFlow decrements (useful for logical routers, for example) to 
become a single modify action in the kernel.

Is there a particular use-case that requires decrement?

--Justin


> On Jun 24, 2019, at 5:06 PM, Sagar A  wrote:
> 
> Hello,
> 
> I see that there is an action OFPACT_DEC_TTL in user space, but not in kernel 
> space for OVS. Is there a reason why kernel space action is not implemented? 
> If one has to implement the kernel space action OFPACT_DEC_TTL, what will be 
> the approach? The reason I want to have kernel space action OFPACT_DEC_TTL is 
> that to avoid 'ttl' as the match condition in flow.
> 
> Thank you.
> ___
> 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] Typo in ovn-nbctl.8.xml

[Justin Pettit]

Thanks for the report.  I pushed a fix to master:

https://github.com/openvswitch/ovs/commit/4e59513cd3c

--Justin


> On Jun 1, 2019, at 6:14 AM, Pekka Järvinen  wrote:
> 
> Hello,
> 
> There's a typo in ovn-nbctl.8.xml man page.
> 
> lsp-get-dhcpv4-optoins
> 
> -- 
> Pekka Järvinen
> ___
> 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] The logical of QoS and meter in OVN

[Justin Pettit]

I'm not sure I understand the question.  There are many references to meters in 
the OVS/OVN code in 2.10.

--Justin


> On May 22, 2019, at 5:24 PM, taoyunupt  wrote:
> 
> Hi,justin,
> I have confusion about the fulfillment of QoS in OVN（2.10）.  I 
> can find ‘max_rate’ in options of 'port_binding',and the code goes to method 
> ‘’setup_qos‘’,which in binding.c
>  
>I do not find any code about 'meter',which is the tool of QoSin 
> OVN/OVS(2.10). So I hope you could give me some explanation of the logical of 
> QoS in OVN.
>  
> 
> 
> Best regards,
> yunxiang

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to get the flow data of OVN logical port, such as in and out bytes?

[Justin Pettit]

I don't believe we pull those out separately, but you might be able to get 
rough estimates if you look at the appropriate ingress and egress OpenFlow 
counters.

--Justin


> On May 14, 2019, at 9:32 PM, Qiang Zhuo  wrote:
> 
> hello:
> How to get the flow data of OVN logical port, such as in and out bytes?
>   
>   Qiang.zhuo
> 
> ___
> 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] Incremental processing patches

[Justin Pettit]

Hi, Daniel.  I don't think this is a bad approach.  However, at the moment, 
Han's work is with ovn-controller and ddlog is with ovn-northd.  We've talked 
about using ddlog in ovn-controller, but there's been no work in that direction 
yet.  At this point, I think Han's patches should be evaluated on their own 
merits and not held back for ddlog.  (Unless someone is looking to run with it. 
 :-) )

--Justin


> On May 7, 2019, at 9:04 AM, Daniel Alvarez Sanchez  
> wrote:
> 
> Hi folks,
> 
> After some conversations with Han (thanks for your time and great
> talk!) at the Open Infrastructure Summit in Denver last week, here I
> go with this - somehow crazy - idea.
> 
> Since DDlog approach for incremental processing is not going to happen
> soon and Han's reported his patches to be working quite well and seem
> to be production ready (please correct me if I'm wrong Han), would it
> be possible to somehow enable those and then drop it after DDlog is in
> a good shape?
> 
> Han keeps rebasing them [0] and I know we could use them but I think
> that the whole OVN project would get better adoption if we could have
> them in place in the main repo. The main downside is its complexity
> but I wonder if we can live with it until DDlog becomes a reality.
> 
> Apologies in advance if this is just a terrible idea since I'm not
> fully aware of what this exactly involves in terms of technical
> complexity and feasibility. I believe that it'll make DDlog harder as
> it'll have to deal with both approaches at the same time but looks
> like the performance benefits are huge so worth to at least consider
> it?
> 
> Thanks a lot!
> Daniel
> 
> [0] https://github.com/hzhou8/ovs/tree/ip12_rebased_mar29
> ___
> 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] What does “require user space processing” mean for missed packets in ovs-dpctl show output?

[Justin Pettit]

> On May 2, 2019, at 1:05 PM, Daniel H  wrote:
> 
> In the manual of ovs-dpctl it says:
>  
> [...]
> "missed" displays the number of packets not matching any existing flow and 
> require user space processing.
> "lost" displays number of packets destined for user space process but 
> subsequently dropped before reaching userspace.
> [...]
> 
> Questions:
> What exactly is meant by "require user space processing"?
> As I see a lot of packets (43777102357, looks like every 3rd packet) with the 
> tag "missed", I'd like to understand what happens with those packets exactly?

It means that the kernel module needs to be told what to do with the packet by 
ovs-vswitchd.  Most of the complicated processing logic is in ovs-vswitchd, and 
the datapath is essentially a cache of recently seen traffic.  That "missed" 
count is usually for new flows for which there's no entry in the datapath yet.  
However, there are cases that require userspace processing (e.g., L2 learning).

I agree that that ratio isn't very good.  It looks like that machine is running 
a version of OVS that could be over five years old.  What version of OVS is it 
running?  Is it using a version that includes megaflows?  Is ovs-vswitch and 
the OVS kernel module the same version?

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openvswitch-2.3.90 tarball

[Justin Pettit]

> On Apr 23, 2019, at 9:29 AM, MikeB  wrote:
> 
> I came across an old codebase that originated with 2.3.90 and I'm
> trying to create a diff of all the changes that have been made to the
> original.

The ".90" indicates that the code came from the master branch between the 2.3 
and 2.4 releases.  It's impossible to know at which commit your code base is 
based on.   If you want to try to narrow it down, you could look at the commits 
between when the version in "configure.ac" changed from 2.3.90 to 2.4.0--but 
I'm sure there will be quite a few of them.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] 2.11.1, 2.10.2, 2.9.5, 2.8.7, 2.7.9, 2.6.6, and 2.5.8 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce a number of bug fix releases:

  http://openvswitch.org/releases/openvswitch-2.11.1.tar.gz

  http://openvswitch.org/releases/openvswitch-2.10.2.tar.gz

  http://openvswitch.org/releases/openvswitch-2.9.5.tar.gz

  http://openvswitch.org/releases/openvswitch-2.8.7.tar.gz

  http://openvswitch.org/releases/openvswitch-2.7.9.tar.gz

  http://openvswitch.org/releases/openvswitch-2.6.6.tar.gz

  http://openvswitch.org/releases/openvswitch-2.5.8.tar.gz

--The Open vSwitch Team 


Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Latest maintenace release not announced or available for download

[Justin Pettit]

> On Mar 25, 2019, at 5:10 AM, Jaime Caamaño Ruiz  wrote:
> 
> Hello
> 
> In the meantime, two related questions:
> 
> - Would github releases be safe to use? For exmaple
> 
> https://github.com/openvswitch/ovs/archive/v2.5.7.tar.gz
> 
> - Is 2.5.7 going to replace 2.5.6 as LTS release?

As I mentioned in a separate message, I plan to do a new release tomorrow, so 
I'd just hold off for 2.5.8.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Latest maintenace release not announced or available for download

[Justin Pettit]

Someone had wanted to get a bug fix in, so it just ended up being a soft 
release.  I plan to do a new release tomorrow with new versions of all our 
supported branches.

--Justin


> On Mar 19, 2019, at 10:15 AM, Ben Pfaff  wrote:
> 
> Justin, you had some information on this, can you follow up?
> 
> On Tue, Mar 19, 2019 at 11:41:03AM +0100, Jaime Caamaño Ruiz wrote:
>> Missing 2.9.4, 2.8.6, 2.7.8, 2.6.5, 2.5.7.
>> 
>> I don't know if they can actually be considered released and I guess
>> that's what I am really asking. I do see them in the relases section in
>> github.
>> 
>> BR
>> Jaime.
>> 
>> 
>> -Original Message-
>> From: Ben Pfaff 
>> To: jcaam...@suse.de
>> Cc: ovs-discuss@openvswitch.org
>> Subject: Re: [ovs-discuss] Latest maintenace release not announced or
>> available for download
>> Date: Mon, 18 Mar 2019 13:22:43 -0700
>> 
>> On Mon, Mar 18, 2019 at 12:09:07PM +0100, Jaime Caamaño Ruiz wrote:
>>> Is there any reason why the latest maintenance releases have not been
>>> announced yet and are not available for download at the usual URL
>>> 
>>> https://www.openvswitch.org/releases/
>> 
>> What versions are missing?
>> 

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Maximum Number of Access Control List Entries

[Justin Pettit]

> On Mar 21, 2019, at 3:56 AM, Michael Dilmore  wrote:
> 
> Hi guys, 
> 
> Does anyone know if there is a hard limit on the number of ACL entries 
> OpenFlow can manage at once? 
> 
> I'm dealing with over 100 and this is likely to grow in future. I'm wondering 
> whether this might cause issues as my security policies become more complex. 

The only limit is the memory on your host.  I've worked on systems that have 
hundreds of thousands of flows, and OVS was fine.  The rule of thumb we use is 
1-2kb of memory per flow.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Open vSwitch 2.11.0 Available

[Justin Pettit]

Whoops.  It should be fixed now.  Thanks, Edouard!

--Justin


> On Feb 28, 2019, at 12:26 AM, Madko  wrote:
> 
> Hi Justin,
> 
> http://openvswitch.org/releases/NEWS-2.11.0 is a 404 (as all previous NEWS 
> release pages). Is that normal ?
> 
> Best regards,
> Edouard
> 
> Le jeu. 28 févr. 2019 à 07:57, Justin Pettit  a écrit :
> The Open vSwitch team is pleased to announce the release of Open vSwitch 
> 2.11.0:
> 
>  http://openvswitch.org/releases/openvswitch-2.11.0.tar.gz
> 
> A few other feature highlights of 2.11.0 include:
> 
> - OVN support for encrypted tunnels between hypervisors.
> 
> - Improved IPAM support in OVN.
> 
> - New OpenFlow feature support.
> 
> - Support for DPDK 18.11.
> 
> - Linux kernel support up to 4.18.
> 
> - And many others.  See the full change log here:
> 
>http://openvswitch.org/releases/NEWS-2.11.0
> 
> Enjoy!
> 
> --The Open vSwitch Team   
> 
>    
> Open vSwitch is a production quality, multilayer open source virtual switch. 
> It is designed to enable massive network automation through programmatic 
> extension, while still supporting standard management interfaces. Open 
> vSwitch can operate both as a soft switch running within the hypervisor, and 
> as the control stack for switching silicon. It has been ported to multiple 
> virtualization platforms and switching chipsets.
> 
> 
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> 
> 
> -- 
> Edouard Bourguignon

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch 2.11.0 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.11.0:

 http://openvswitch.org/releases/openvswitch-2.11.0.tar.gz

A few other feature highlights of 2.11.0 include:

- OVN support for encrypted tunnels between hypervisors.

- Improved IPAM support in OVN.

- New OpenFlow feature support.

- Support for DPDK 18.11.

- Linux kernel support up to 4.18.

- And many others.  See the full change log here:

   http://openvswitch.org/releases/NEWS-2.11.0

Enjoy!

--The Open vSwitch Team   

   
Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Insert flows from file

[Justin Pettit]

I'd recommend looking at the "add-flows" command in ovs-ofctl.

--Justin


> On Feb 11, 2019, at 11:01 AM, George Papathanail  
> wrote:
> 
> Hello, I wondering how can I insert flows on switches with ovs-ofctl command,
> from a bash script file that I wrote.
> 
> Thanks 
> George
> ___
> 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] which kernel module patch could repair the support of meter

[Justin Pettit]

I don't know off the top of my head.  I'd recommend running "git blame" on the 
tip of Linus's tree and figuring out which patches are necessary to add 
support.  My recollection is that they mostly went in as a single patch, so it 
should be pretty easy to find the appropriate patches.

--Justin


> On Jan 28, 2019, at 5:29 PM, taoyunupt  wrote:
> 
> The distribution version of OS of mime is CentOS Linux release 7.5.1804 
> (Core),and the kernel version is 3.10.0-862.14.4.el7.x86_64.   I plan to 
> merge the meters patch to the 3.10.0-862 kernel of CentOS7.5. 
> Where is the function patch address?  Do you have some suggestions？ 
> 
> Regards,
> yunxiang
> 
> 
> 
> 
> 
> 
> At 2019-01-29 02:49:59, "Justin Pettit"  wrote:
> >I'd have to look at the history, but the feature wouldn't have been added to 
> >OVN unless it was supported by OVS.  Currently, we expect OVN to work with 
> >the same version number of OVS.  (Although, I expect you could use a newer 
> >version of OVS and an older OVN.)  We plan to break that requirement so that 
> >each OVS and OVN can use different version going forward, but we're not 
> >there yet.
> >
> >--Justin
> >
> >
> >> On Jan 28, 2019, at 3:15 AM, taoyunupt  wrote:
> >> 
> >> Hello,justin
> >>Forgive me!  I have another question. As OVN use meters to 
> >> implement  QoS and meters was added from ovs2.10, how the ovn(<2.10) 
> >> support QoS?
> >> 
> >> 
> >> 
> >> Regards,
> >> Yunxiang
> >> 
> >> 
> >> At 2019-01-28 15:43:24, "Justin Pettit"  wrote:
> >> >Sorry, I was thinking of another system that used OVS's tc instead of 
> >> >meters to implement basic QoS.  OVN does use meters to implement most 
> >> >modes of QoS.  If you don't want to use meters, you could try looking at 
> >> >the "qos_max_rate" and "qos_burst" options in the ovn-nb man page, but I 
> >> >don't have any experience using them.
> >> >
> >> >--Justin
> >> >
> >> >
> >> >> On Jan 27, 2019, at 11:26 PM, taoyunupt  wrote:
> >> >> 
> >> >> The method build_qos in  /ovn/northd/ovn-northd.c is as fellows,in the 
> >> >> end of the method,it  adds logical flow by the code of
> >> >> ovn_lflow_add(lflows, od, stage,qos->priority,qos->match, 
> >> >> ds_cstr(_action));
> >> >> 
> >> >> Does this mean the meter table is the only way for ovn to add Qos?
> >> >> 
> >> >>   
> >> >> 
> >> >> build_qos(struct ovn_datapath *od, struct hmap *lflows) {
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_MARK, 0, "1", "next;");
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_MARK, 0, "1", "next;");
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_METER, 0, "1", "next;");
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_METER, 0, "1", "next;");
> >> >> 
> >> >> for (size_t i = 0; i < od->nbs->n_qos_rules; i++) {
> >> >> struct nbrec_qos *qos = od->nbs->qos_rules[i];
> >> >> bool ingress = !strcmp(qos->direction, "from-lport") ? true 
> >> >> :false;
> >> >> enum ovn_stage stage = ingress ? S_SWITCH_IN_QOS_MARK : 
> >> >> S_SWITCH_OUT_QOS_MARK;
> >> >> int64_t rate = 0;
> >> >> int64_t burst = 0;
> >> >> 
> >> >> for (size_t j = 0; j < qos->n_action; j++) {
> >> >> if (!strcmp(qos->key_action[j], "dscp")) {
> >> >> struct ds dscp_action = DS_EMPTY_INITIALIZER;
> >> >> 
> >> >> ds_put_format(_action, "ip.dscp = %"PRId64"; 
> >> >> next;",
> >> >>   qos->value_action[j]);
> >> >> ovn_lflow_add(lflows, od, stage,
> >> >>   qos->priority,
> >> >>   qos->match, ds_cstr(_action));
> >> >> ds_destroy(_action);
> >> >> }
> >> >> }
> >> >> 
> >> >> for (size_t n = 0; n < qos->n

Re: [ovs-discuss] which kernel module patch could repair the support of meter

[Justin Pettit]

I'm afraid that I don't understand the question.  Are you asking how you'd 
backport meter support for an older kernel?  If so, you'd need to talk to the 
Centos/Red Hat maintainers.

--Justin


> On Jan 28, 2019, at 5:29 PM, taoyunupt  wrote:
> 
> The distribution version of OS of mime is CentOS Linux release 7.5.1804 
> (Core),and the kernel version is 3.10.0-862.14.4.el7.x86_64.   I plan to 
> merge the meters patch to the 3.10.0-862 kernel of CentOS7.5. 
> Where is the function patch address?  Do you have some suggestions？ 
> 
> Regards,
> yunxiang
> 
> 
> 
> 
> 
> 
> At 2019-01-29 02:49:59, "Justin Pettit"  wrote:
> >I'd have to look at the history, but the feature wouldn't have been added to 
> >OVN unless it was supported by OVS.  Currently, we expect OVN to work with 
> >the same version number of OVS.  (Although, I expect you could use a newer 
> >version of OVS and an older OVN.)  We plan to break that requirement so that 
> >each OVS and OVN can use different version going forward, but we're not 
> >there yet.
> >
> >--Justin
> >
> >
> >> On Jan 28, 2019, at 3:15 AM, taoyunupt  wrote:
> >> 
> >> Hello,justin
> >>Forgive me!  I have another question. As OVN use meters to 
> >> implement  QoS and meters was added from ovs2.10, how the ovn(<2.10) 
> >> support QoS?
> >> 
> >> 
> >> 
> >> Regards,
> >> Yunxiang
> >> 
> >> 
> >> At 2019-01-28 15:43:24, "Justin Pettit"  wrote:
> >> >Sorry, I was thinking of another system that used OVS's tc instead of 
> >> >meters to implement basic QoS.  OVN does use meters to implement most 
> >> >modes of QoS.  If you don't want to use meters, you could try looking at 
> >> >the "qos_max_rate" and "qos_burst" options in the ovn-nb man page, but I 
> >> >don't have any experience using them.
> >> >
> >> >--Justin
> >> >
> >> >
> >> >> On Jan 27, 2019, at 11:26 PM, taoyunupt  wrote:
> >> >> 
> >> >> The method build_qos in  /ovn/northd/ovn-northd.c is as fellows,in the 
> >> >> end of the method,it  adds logical flow by the code of
> >> >> ovn_lflow_add(lflows, od, stage,qos->priority,qos->match, 
> >> >> ds_cstr(_action));
> >> >> 
> >> >> Does this mean the meter table is the only way for ovn to add Qos?
> >> >> 
> >> >>   
> >> >> 
> >> >> build_qos(struct ovn_datapath *od, struct hmap *lflows) {
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_MARK, 0, "1", "next;");
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_MARK, 0, "1", "next;");
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_METER, 0, "1", "next;");
> >> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_METER, 0, "1", "next;");
> >> >> 
> >> >> for (size_t i = 0; i < od->nbs->n_qos_rules; i++) {
> >> >> struct nbrec_qos *qos = od->nbs->qos_rules[i];
> >> >> bool ingress = !strcmp(qos->direction, "from-lport") ? true 
> >> >> :false;
> >> >> enum ovn_stage stage = ingress ? S_SWITCH_IN_QOS_MARK : 
> >> >> S_SWITCH_OUT_QOS_MARK;
> >> >> int64_t rate = 0;
> >> >> int64_t burst = 0;
> >> >> 
> >> >> for (size_t j = 0; j < qos->n_action; j++) {
> >> >> if (!strcmp(qos->key_action[j], "dscp")) {
> >> >> struct ds dscp_action = DS_EMPTY_INITIALIZER;
> >> >> 
> >> >> ds_put_format(_action, "ip.dscp = %"PRId64"; 
> >> >> next;",
> >> >>   qos->value_action[j]);
> >> >> ovn_lflow_add(lflows, od, stage,
> >> >>   qos->priority,
> >> >>   qos->match, ds_cstr(_action));
> >> >> ds_destroy(_action);
> >> >> }
> >> >> }
> >> >> 
> >> >> for (size_t n = 0; n < qos->n_bandwidth; n++) {
> >> >> if (!strcmp(qos->key_bandwidth[n], "rate")) {

Re: [ovs-discuss] [HELP] Question about linux kernel version supported by OVS 2.10.1

[Justin Pettit]

Red Hat backports a number of features to their kernels.  The references there 
are for the upstream kernel, which I suspect are correct.

--Justin


> On Jan 28, 2019, at 5:06 PM, txfh2007 via discuss 
>  wrote:
> 
> Hi everyone:
>I have found the table of ovs feature && Linux upstream in release.rst. 
> From this chart we could found some ovs feature need higher linux kernel 
> version. But my linux kernel is redhat 3.10, and I have found some feature in 
> the list also worked well, such as connection tracking && tunnel-Geneve. 
>so my question is, should we  update the linux kernel version listed in 
> chart to fullfill all ovs 2.10.1 feature?
>= == == = ===
>Feature   Linux upstream Linux OVS tree Userspace Hyper-V
>= == == = ===
>NAT   4.6YESYes   NO
>Connection tracking   4.3YESPARTIAL   PARTIAL
>Tunnel - LISP NO YESNONO
>Tunnel - STT  NO YESNOYES
>Tunnel - GRE  3.11   YESYES   YES
>Tunnel - VXLAN3.12   YESYES   YES
>Tunnel - Geneve   3.18   YESYES   YES
>Tunnel - GRE-IPv6 NO NO YES   NO
>Tunnel - VXLAN-IPv6   4.3YESYES   NO
>Tunnel - Geneve-IPv6  4.4YESYES   NO
>QoS - PolicingYESYESYES   NO
>QoS - Shaping YESYESNONO
>sFlow YESYESYES   NO
>IPFIX 3.10   YESYES   NO
>Set actionYESYESYES   PARTIAL
>NIC Bonding   YESYESYES   YES
>Multiple VTEPsYESYESYES   YES
>Meters4.15   YESYES   NO
>= == == = ===
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] which kernel module patch could repair the support of meter

[Justin Pettit]

I'd have to look at the history, but the feature wouldn't have been added to 
OVN unless it was supported by OVS.  Currently, we expect OVN to work with the 
same version number of OVS.  (Although, I expect you could use a newer version 
of OVS and an older OVN.)  We plan to break that requirement so that each OVS 
and OVN can use different version going forward, but we're not there yet.

--Justin


> On Jan 28, 2019, at 3:15 AM, taoyunupt  wrote:
> 
> Hello,justin
>Forgive me!  I have another question. As OVN use meters to 
> implement  QoS and meters was added from ovs2.10, how the ovn(<2.10) support 
> QoS?
> 
> 
> 
> Regards,
> Yunxiang
> 
> 
> At 2019-01-28 15:43:24, "Justin Pettit"  wrote:
> >Sorry, I was thinking of another system that used OVS's tc instead of meters 
> >to implement basic QoS.  OVN does use meters to implement most modes of QoS. 
> > If you don't want to use meters, you could try looking at the 
> >"qos_max_rate" and "qos_burst" options in the ovn-nb man page, but I don't 
> >have any experience using them.
> >
> >--Justin
> >
> >
> >> On Jan 27, 2019, at 11:26 PM, taoyunupt  wrote:
> >> 
> >> The method build_qos in  /ovn/northd/ovn-northd.c is as fellows,in the end 
> >> of the method,it  adds logical flow by the code of
> >> ovn_lflow_add(lflows, od, stage,qos->priority,qos->match, 
> >> ds_cstr(_action));
> >> 
> >> Does this mean the meter table is the only way for ovn to add Qos?
> >> 
> >>   
> >> 
> >> build_qos(struct ovn_datapath *od, struct hmap *lflows) {
> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_MARK, 0, "1", "next;");
> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_MARK, 0, "1", "next;");
> >> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_METER, 0, "1", "next;");
> >> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_METER, 0, "1", "next;");
> >> 
> >> for (size_t i = 0; i < od->nbs->n_qos_rules; i++) {
> >> struct nbrec_qos *qos = od->nbs->qos_rules[i];
> >> bool ingress = !strcmp(qos->direction, "from-lport") ? true :false;
> >> enum ovn_stage stage = ingress ? S_SWITCH_IN_QOS_MARK : 
> >> S_SWITCH_OUT_QOS_MARK;
> >> int64_t rate = 0;
> >> int64_t burst = 0;
> >> 
> >> for (size_t j = 0; j < qos->n_action; j++) {
> >> if (!strcmp(qos->key_action[j], "dscp")) {
> >> struct ds dscp_action = DS_EMPTY_INITIALIZER;
> >> 
> >> ds_put_format(_action, "ip.dscp = %"PRId64"; next;",
> >>   qos->value_action[j]);
> >> ovn_lflow_add(lflows, od, stage,
> >>   qos->priority,
> >>   qos->match, ds_cstr(_action));
> >> ds_destroy(_action);
> >> }
> >> }
> >> 
> >> for (size_t n = 0; n < qos->n_bandwidth; n++) {
> >> if (!strcmp(qos->key_bandwidth[n], "rate")) {
> >> rate = qos->value_bandwidth[n];
> >> } else if (!strcmp(qos->key_bandwidth[n], "burst")) {
> >> burst = qos->value_bandwidth[n];
> >> }
> >> }
> >> if (rate) {
> >> struct ds meter_action = DS_EMPTY_INITIALIZER;
> >> stage = ingress ? S_SWITCH_IN_QOS_METER : 
> >> S_SWITCH_OUT_QOS_METER;
> >> if (burst) {
> >> ds_put_format(_action,
> >>       "set_meter(%"PRId64", %"PRId64"); next;",
> >>   rate, burst);
> >> } else {
> >> ds_put_format(_action,
> >>   "set_meter(%"PRId64"); next;",
> >>   rate);
> >> }
> >> 
> >> /* Ingress and Egress QoS Meter Table.
> >>  *
> >>  * We limit the bandwidth of this flow by adding a meter table.
> >>  */
> >> ovn_lflow_add(lflows, od, stage,
> >>   qos->priority,
> >>  

Re: [ovs-discuss] which kernel module patch could repair the support of meter

[Justin Pettit]

Sorry, I was thinking of another system that used OVS's tc instead of meters to 
implement basic QoS.  OVN does use meters to implement most modes of QoS.  If 
you don't want to use meters, you could try looking at the "qos_max_rate" and 
"qos_burst" options in the ovn-nb man page, but I don't have any experience 
using them.

--Justin


> On Jan 27, 2019, at 11:26 PM, taoyunupt  wrote:
> 
> The method build_qos in  /ovn/northd/ovn-northd.c is as fellows,in the end of 
> the method,it  adds logical flow by the code of
> ovn_lflow_add(lflows, od, stage,qos->priority,qos->match, 
> ds_cstr(_action));
> 
> Does this mean the meter table is the only way for ovn to add Qos?
> 
>   
> 
> build_qos(struct ovn_datapath *od, struct hmap *lflows) {
> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_MARK, 0, "1", "next;");
> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_MARK, 0, "1", "next;");
> ovn_lflow_add(lflows, od, S_SWITCH_IN_QOS_METER, 0, "1", "next;");
> ovn_lflow_add(lflows, od, S_SWITCH_OUT_QOS_METER, 0, "1", "next;");
> 
> for (size_t i = 0; i < od->nbs->n_qos_rules; i++) {
> struct nbrec_qos *qos = od->nbs->qos_rules[i];
> bool ingress = !strcmp(qos->direction, "from-lport") ? true :false;
> enum ovn_stage stage = ingress ? S_SWITCH_IN_QOS_MARK : 
> S_SWITCH_OUT_QOS_MARK;
> int64_t rate = 0;
> int64_t burst = 0;
> 
> for (size_t j = 0; j < qos->n_action; j++) {
> if (!strcmp(qos->key_action[j], "dscp")) {
> struct ds dscp_action = DS_EMPTY_INITIALIZER;
> 
> ds_put_format(_action, "ip.dscp = %"PRId64"; next;",
>   qos->value_action[j]);
> ovn_lflow_add(lflows, od, stage,
>   qos->priority,
>   qos->match, ds_cstr(_action));
> ds_destroy(_action);
> }
> }
> 
> for (size_t n = 0; n < qos->n_bandwidth; n++) {
> if (!strcmp(qos->key_bandwidth[n], "rate")) {
> rate = qos->value_bandwidth[n];
> } else if (!strcmp(qos->key_bandwidth[n], "burst")) {
> burst = qos->value_bandwidth[n];
> }
> }
> if (rate) {
> struct ds meter_action = DS_EMPTY_INITIALIZER;
> stage = ingress ? S_SWITCH_IN_QOS_METER : S_SWITCH_OUT_QOS_METER;
> if (burst) {
> ds_put_format(_action,
>   "set_meter(%"PRId64", %"PRId64"); next;",
>   rate, burst);
> } else {
> ds_put_format(_action,
>   "set_meter(%"PRId64"); next;",
>   rate);
>     }
> 
> /* Ingress and Egress QoS Meter Table.
>  *
>  * We limit the bandwidth of this flow by adding a meter table.
>  */
> ovn_lflow_add(lflows, od, stage,
>   qos->priority,
>   qos->match, ds_cstr(_action));
> ds_destroy(_action);
> }
> }
> }
> 
> 
> 
> 
> 
> At 2019-01-28 15:15:51, "Justin Pettit"  wrote:
> >QoS is most likely using the kernel's built-in traffic-shaping algorithms in 
> >tc.  Those should work the same on all supported kernels.
> >
> >--Justin
> >
> >
> >> On Jan 27, 2019, at 11:10 PM, taoyunupt  wrote:
> >> 
> >> 
> >> Thanks justin,
> >> 
> >> My environment is OVS for the OVN/openstack.I also want to know ,if i must 
> >> use meter for the  openstack/ovn feature 'Qos'.Does any other methods to 
> >> achive this?
> >> 
> >> Regards,
> >> Yunxiang
> >> 
> >> 
> >> 
> >> 
> >> 
> >> At 2019-01-28 14:58:19, "Justin Pettit"  wrote:
> >> >This is the patch:
> >> >
> >> >  http://patchwork.ozlabs.org/patch/950513/
> >> >
> >> >I think it was only broken in kernels 4.15, 4.16, and 4.17.  I expect 
> >> >that 4.20 will be fine.
> >> >
> >> >--Justin
> >> >
> >> >
> >> >> On Jan 27, 2019, at 10:16 PM, taoyunupt  wrote:
> >> >> 
> >> >> Hello,justin,
> &

Re: [ovs-discuss] which kernel module patch could repair the support of meter

[Justin Pettit]

QoS is most likely using the kernel's built-in traffic-shaping algorithms in 
tc.  Those should work the same on all supported kernels.

--Justin


> On Jan 27, 2019, at 11:10 PM, taoyunupt  wrote:
> 
> 
> Thanks justin,
> 
> My environment is OVS for the OVN/openstack.I also want to know ,if i must 
> use meter for the  openstack/ovn feature 'Qos'.Does any other methods to 
> achive this?
> 
> Regards,
> Yunxiang
> 
> 
> 
> 
> 
> At 2019-01-28 14:58:19, "Justin Pettit"  wrote:
> >This is the patch:
> >
> > http://patchwork.ozlabs.org/patch/950513/
> >
> >I think it was only broken in kernels 4.15, 4.16, and 4.17.  I expect that 
> >4.20 will be fine.
> >
> >--Justin
> >
> >
> >> On Jan 27, 2019, at 10:16 PM, taoyunupt  wrote:
> >> 
> >> Hello,justin,
> >>  I  met a supporting problem of meter of OVS 2.10. I found a mail 
> >> from you,after searching the internet.The address of this mail is 
> >> "https://www.mail-archive.com/ovs-discuss@openvswitch.org/msg04180.html;
> >>  The kernel version of  "4.20.5-1.el7.elrepo.x86_64" goes well 
> >> with meter table of ovs,but I want to know how to fit the  maintained 
> >> older kernels.
> >>  If i want to use ovs with maintained older kernels,which patch 
> >> you metioned in the mail, should i import ?
> >> 
> >> 
> >> 
> >> 
> >> Regards,
> >> yunxiang
> >> 
> >> ___
> >> 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] which kernel module patch could repair the support of meter

[Justin Pettit]

This is the patch:

http://patchwork.ozlabs.org/patch/950513/

I think it was only broken in kernels 4.15, 4.16, and 4.17.  I expect that 4.20 
will be fine.

--Justin


> On Jan 27, 2019, at 10:16 PM, taoyunupt  wrote:
> 
> Hello,justin,
>  I  met a supporting problem of meter of OVS 2.10. I found a mail 
> from you,after searching the internet.The address of this mail is 
> "https://www.mail-archive.com/ovs-discuss@openvswitch.org/msg04180.html;
>  The kernel version of  "4.20.5-1.el7.elrepo.x86_64" goes well with 
> meter table of ovs,but I want to know how to fit the  maintained older 
> kernels.
>  If i want to use ovs with maintained older kernels,which patch you 
> metioned in the mail, should i import ?
> 
> 
> 
> 
> Regards,
> yunxiang
> 
> ___
> 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] Cannot Add Meter in OVS 2.10.2

[Justin Pettit]

You’ll need to consult your distro’s documentation about how to load an 
out-of-tree kernel module.  There’s usually plenty of examples available online.

--Justin


> On Jan 9, 2019, at 10:41 PM, Ramzah Rehman  wrote:
> 
> I made sure while building that I use the module that was built from OVS 
> sources by creating a config file as shown in Building section here: 
> http://docs.openvswitch.org/en/latest/intro/install/general/ 
> 
> What else should I do to use the module from OVS sources? 
> 
> 
>> On Thu, Jan 10, 2019 at 11:33 AM Justin Pettit  wrote:
>> That’s the version of ovs-vswitchd—the userspace daemon that talks with the 
>> kernel datapath.
>> 
>> --Justin
>> 
>> 
>>> On Jan 9, 2019, at 10:17 PM, Ramzah Rehman  wrote:
>>> 
>>> Alright. But I can find ovs-vswitchd version like this:
>>> 
>>>  ovs-vswitchd --version
>>> ovs-vswitchd (Open vSwitch) 2.10.90
>>> 
>>> Does this mean something?
>>> 
>>> 
>>>> On Thu, Jan 10, 2019 at 2:33 AM Justin Pettit  wrote:
>>>> 
>>>> > On Jan 8, 2019, at 5:48 AM, Ramzah Rehman  wrote:
>>>> > 
>>>> > ovs-vsctl list bridge br0
>>>> > 
>>>> > _uuid   : bd776aad-3a88-4d38-a7a2-6be57723f04b
>>>> > auto_attach : []
>>>> > controller  : []
>>>> > datapath_id : "ae6a77bd384d"
>>>> > datapath_type   : ""
>>>> > datapath_version: ""
>>>> 
>>>> I think this is indicating that you're not using the just-built OVS kernel 
>>>> module.  The Linux built-in OVS kernel module doesn't return a version, 
>>>> but the one built from OVS sources would indicate the version number of 
>>>> OVS that you built.
>>>> 
>>>> --Justin
>>>> 
>>>> 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Cannot Add Meter in OVS 2.10.2

[Justin Pettit]

That’s the version of ovs-vswitchd—the userspace daemon that talks with the 
kernel datapath.

--Justin


> On Jan 9, 2019, at 10:17 PM, Ramzah Rehman  wrote:
> 
> Alright. But I can find ovs-vswitchd version like this:
> 
>  ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 2.10.90
> 
> Does this mean something?
> 
> 
>> On Thu, Jan 10, 2019 at 2:33 AM Justin Pettit  wrote:
>> 
>> > On Jan 8, 2019, at 5:48 AM, Ramzah Rehman  wrote:
>> > 
>> > ovs-vsctl list bridge br0
>> > 
>> > _uuid   : bd776aad-3a88-4d38-a7a2-6be57723f04b
>> > auto_attach : []
>> > controller  : []
>> > datapath_id : "ae6a77bd384d"
>> > datapath_type   : ""
>> > datapath_version: ""
>> 
>> I think this is indicating that you're not using the just-built OVS kernel 
>> module.  The Linux built-in OVS kernel module doesn't return a version, but 
>> the one built from OVS sources would indicate the version number of OVS that 
>> you built.
>> 
>> --Justin
>> 
>> 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Cannot Add Meter in OVS 2.10.2

[Justin Pettit]

> On Jan 8, 2019, at 5:48 AM, Ramzah Rehman  wrote:
> 
> ovs-vsctl list bridge br0
> 
> _uuid   : bd776aad-3a88-4d38-a7a2-6be57723f04b
> auto_attach : []
> controller  : []
> datapath_id : "ae6a77bd384d"
> datapath_type   : ""
> datapath_version: ""

I think this is indicating that you're not using the just-built OVS kernel 
module.  The Linux built-in OVS kernel module doesn't return a version, but the 
one built from OVS sources would indicate the version number of OVS that you 
built.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Bitmask

[Justin Pettit]

I'm not sure that I entirely understand what you're trying to accomplish, but 
you can match and modify both the MAC addresses and TTL fields using ovs-ofctl, 
 OVS doesn't support arbitrary math on fields (unless you count decrementing 
the TTL), however, if you have a limited range, you could just use a number of 
hard-coded flows that match on a particular value and then modify it 
appropriately.

I'm not sure if that's helpful or not...

--Justin


> On Jan 7, 2019, at 9:45 AM, George Papathanail  
> wrote:
> 
> I have instantiate a topology in Mininet with 2hosts and 3 switches.
> I have to encode the output ports of the switches on packet header in order 
> to reduce the state of the switches.
> 
> For example if the output ports are 3 , 5 , 4 the mac is 03:05:04:00:00:00. 
> (if i understand well).
> The second step is to create a pointer that show to the next hop output port.
> 
> I'm trying to implement this.
> 
> 
> 
> 
> P.S I' m new to the openflow and sdn
> 
> Thank you
> 
>  
> 
>   Απαλλαγμένο από ιούς. www.avast.com
> 
> Στις Δευ, 7 Ιαν 2019 στις 7:23 μ.μ., ο/η Justin Pettit  
> έγραψε:
> 
> > On Jan 7, 2019, at 7:36 AM, George Papathanail  
> > wrote:
> > 
> > Is it possible to generate a pointer with ovs-ofctl command?
> 
> What do you mean?
> 
> --Justin
> 
> 
> 

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Cannot Add Meter in OVS 2.10.2

[Justin Pettit]

(Please don't drop the list.)

If you are using the OVS kernel module that ships with a 4.15 kernel, I would 
expect there to be a problem.  (I would also expect there to be a message 
logged from that probe.)  However, if you use the kernel module that ships with 
OVS (regardless of the kernel it's compiled against), I would expect it to work.

--Justin


> On Dec 28, 2018, at 12:09 PM, Ramzah Rehman  wrote:
> 
> I don't get " the kernel module has broken implementation error". 
> 
> I'm using the kernel module that's part of ovs 2.10. are you implying that 
> using kernel module of ovs 2.10 would not lead to meter error when I try to 
> add meter in kernel datapath?
> 
> On Sat, Dec 29, 2018, 12:57 AM Justin Pettit  I think meters are broken up to kernel 4.18.0, which is when this patch was 
> added:
> 
> https://github.com/torvalds/linux/commit/25432eba9cd
> 
> This commit probes for that condition in ovs-vswitchd:
> 
> https://github.com/openvswitch/ovs/commit/92d0d515d6
> 
> Do you see "The kernel module has a broken meter implementation." in your 
> ovs-vswitchd logs?
> 
> I will see if I can get that fix applied to 4.15, 4.16, and 4.17 branches in 
> the upstream kernel.  In the meantime, you should be able to use the kernel 
> module that's included as part of OVS 2.10.
> 
> --Justin
> 
> 
> > On Dec 28, 2018, at 12:55 AM, Ramzah Rehman  wrote:
> > 
> > Here is the log error when I try to add a meter:
> > #ovs-ofctl -O OpenFlow15 add-meter br0 
> > meter=100,kbps,band=type=drop,rate=30
> > 
> > Error in ovs-vswitchd.log:
> > 2018-12-28T08:52:06.462Z|00653|connmgr|INFO|br0<->unix#224: sending 
> > OFPMMFC_INVALID_METER error reply to OFPT_METER_MOD message
> > 
> > The kernel verion I updated to is:
> > #uname -a
> > Linux ubuntu 4.15.1-041501-generic #201802031831 SMP Sat Feb 3 18:32:13 UTC 
> > 2018 x86_64 x86_64 x86_64 GNU/Linux
> > 
> > Could it be that that updating kernel to a supported version i.e. 4.15.1 
> > does not work?
> > 
> > 
> > Best Regards,
> > Ramzah Rehman
> > 
> > 
> > On Thu, Dec 27, 2018 at 8:44 PM Ben Pfaff  wrote:
> > Check the OVS log for a message that mentions meters.
> > 
> > On Thu, Dec 27, 2018 at 08:30:54PM +0500, Ramzah Rehman wrote:
> > > I have Ubuntu 14.04.5 with kernel version 4.4. I updated kernel version to
> > > 4.15.1 which supports kernel datapaths.
> > > 
> > >  I don't want to use DPDK since I don't have DPDK compatible network 
> > > cards.
> > > 
> > > On Thu, Dec 27, 2018, 8:24 PM Ben Pfaff  > > 
> > > > On Thu, Dec 27, 2018 at 12:02:50PM +0500, Ramzah Rehman wrote:
> > > > > It is mentioned in FAQ of QoS that "Open vSwitch 2.10 has implemented
> > > > > meters in the Linux kernel datapath "  which means we can use meters 
> > > > > in
> > > > > kernel datapath. However, when I try to add meter, I get
> > > > > OFPMMFC_INVALID_METER error. This is what I did.
> > > > >
> > > > > #ovs-vsctl add-br br0
> > > > > #ovs-vsctl set bridge br0
> > > > >
> > > > protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15
> > > > > #ovs-ofctl -O OpenFlow15 add-meter br0
> > > > > meter=100,kbps,band=type=drop,rate=30
> > > > > OFPT_ERROR (OF1.3) (xid=0x2): OFPMMFC_INVALID_METER
> > > > > OFPT_METER_MOD (OF1.3) (xid=0x2): ADD meter=100 kbps bands=
> > > > > type=drop rate=30
> > > > >
> > > > > Please let me what I am doing wrong.
> > > >
> > > > Probably the kernel module you're using doesn't support meters.
> > > >
> > > > > One important thing to mention here is that when I set the type of
> > > > > switch to netdev like this:
> > > > >
> > > > > #ovs-vsctl set bridge br0 datapath_type=netdev
> > > > >
> > > > > I can add meters without any error. What's the reason?
> > > >
> > > > Each datapath has its own meter implementation, so when you switch
> > > > datapaths you get different behavior.
> > > >
> > > > > There's one problem with this as well, I cannot achieve throughput
> > > > > more than 500Mbps on 1Gbps link once I set the datapath type to
> > > > > netdev.
> > > >
> > > > Probably you should use DPDK if you want high performance from the
> > > > userspace datapath.
> > > >
> > ___
> > 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] Cannot Add Meter in OVS 2.10.2

[Justin Pettit]

I think meters are broken up to kernel 4.18.0, which is when this patch was 
added:

https://github.com/torvalds/linux/commit/25432eba9cd

This commit probes for that condition in ovs-vswitchd:

https://github.com/openvswitch/ovs/commit/92d0d515d6

Do you see "The kernel module has a broken meter implementation." in your 
ovs-vswitchd logs?

I will see if I can get that fix applied to 4.15, 4.16, and 4.17 branches in 
the upstream kernel.  In the meantime, you should be able to use the kernel 
module that's included as part of OVS 2.10.

--Justin


> On Dec 28, 2018, at 12:55 AM, Ramzah Rehman  wrote:
> 
> Here is the log error when I try to add a meter:
> #ovs-ofctl -O OpenFlow15 add-meter br0 
> meter=100,kbps,band=type=drop,rate=30
> 
> Error in ovs-vswitchd.log:
> 2018-12-28T08:52:06.462Z|00653|connmgr|INFO|br0<->unix#224: sending 
> OFPMMFC_INVALID_METER error reply to OFPT_METER_MOD message
> 
> The kernel verion I updated to is:
> #uname -a
> Linux ubuntu 4.15.1-041501-generic #201802031831 SMP Sat Feb 3 18:32:13 UTC 
> 2018 x86_64 x86_64 x86_64 GNU/Linux
> 
> Could it be that that updating kernel to a supported version i.e. 4.15.1 does 
> not work?
> 
> 
> Best Regards,
> Ramzah Rehman
> 
> 
> On Thu, Dec 27, 2018 at 8:44 PM Ben Pfaff  wrote:
> Check the OVS log for a message that mentions meters.
> 
> On Thu, Dec 27, 2018 at 08:30:54PM +0500, Ramzah Rehman wrote:
> > I have Ubuntu 14.04.5 with kernel version 4.4. I updated kernel version to
> > 4.15.1 which supports kernel datapaths.
> > 
> >  I don't want to use DPDK since I don't have DPDK compatible network cards.
> > 
> > On Thu, Dec 27, 2018, 8:24 PM Ben Pfaff  > 
> > > On Thu, Dec 27, 2018 at 12:02:50PM +0500, Ramzah Rehman wrote:
> > > > It is mentioned in FAQ of QoS that "Open vSwitch 2.10 has implemented
> > > > meters in the Linux kernel datapath "  which means we can use meters in
> > > > kernel datapath. However, when I try to add meter, I get
> > > > OFPMMFC_INVALID_METER error. This is what I did.
> > > >
> > > > #ovs-vsctl add-br br0
> > > > #ovs-vsctl set bridge br0
> > > >
> > > protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15
> > > > #ovs-ofctl -O OpenFlow15 add-meter br0
> > > > meter=100,kbps,band=type=drop,rate=30
> > > > OFPT_ERROR (OF1.3) (xid=0x2): OFPMMFC_INVALID_METER
> > > > OFPT_METER_MOD (OF1.3) (xid=0x2): ADD meter=100 kbps bands=
> > > > type=drop rate=30
> > > >
> > > > Please let me what I am doing wrong.
> > >
> > > Probably the kernel module you're using doesn't support meters.
> > >
> > > > One important thing to mention here is that when I set the type of
> > > > switch to netdev like this:
> > > >
> > > > #ovs-vsctl set bridge br0 datapath_type=netdev
> > > >
> > > > I can add meters without any error. What's the reason?
> > >
> > > Each datapath has its own meter implementation, so when you switch
> > > datapaths you get different behavior.
> > >
> > > > There's one problem with this as well, I cannot achieve throughput
> > > > more than 500Mbps on 1Gbps link once I set the datapath type to
> > > > netdev.
> > >
> > > Probably you should use DPDK if you want high performance from the
> > > userspace datapath.
> > >
> ___
> 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] Issues in "meter" action in OpenFlow

[Justin Pettit]

> On Dec 12, 2018, at 12:32 AM, Ramzah Rehman  wrote:
> 
> I have tested meter action in OpenFLow. I have drawn following conclusions:
> 
>   • TCP
>   • Conclusion: meter works fine for low rate-limiting values 
> (till ~100Mbps). However, for higher values, the expected bandwidth is 
> relatively very low.   
>   • UDP:
>   • Conclusion: meter action not supported for UDP
> 
> Please let me know Why I am seeing this behavior with TCP traffic? Is it 
> expected? If so, How can I get expected bandwidth equal to the rate I specify 
> in OpenFlow meter?

TCP throughput has a tendency to act erratically to packets dropping, so it can 
be hard to exactly tune throughput.  You might try configuring different burst 
sizes at different rates to see if that helps.  However, if you need to 
rate-limit TCP, you're probably better off using the QoS configuration with 
traffic shaping, since that will delay packets instead of dropping them.  Some 
of this is discussed in the FAQ:

http://docs.openvswitch.org/en/latest/faq/qos/

I would recommend using HTB for less than 100Mbps and HFSC for less than 1Gbps. 
 Anything above that will likely have poor performance due to the overhead of 
performing QoS in software.

> Also, does meter action work for UDP traffic?

Yes, I would expect it to work.  It should perform more predictably than TCP.

How did you configure the flows?  Are you using the kernel or userspace 
datapath?  If you're using the kernel, what kernel version are you using?  
There are a few kernel versions that have issues due to a bug in the upstream 
kernel.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] RFC: incremental computation for OVN with DDlog

[Justin Pettit]

> On Nov 13, 2018, at 5:25 PM, Russell Bryant  wrote:
> 
> I think this is implied based on the description of how ovn-northd
> would work, but do you expect to make a completely seamless drop-in
> replacement (aside from build-time and run-time dependencies?  All
> parameters would be identical, no new configuration, and requiring
> zero change to integrations project like ovn-kubernetes or the
> OpenStack OVN integration?

Correct.  There will be no external interface changes.  (Other than new runtime 
flags to indicate whether the C- or DDlog-based version should be used, of 
course.)  It will be invisible to the existing integrations.

At least for the 2.11 release, there won't even be a requirement to build the 
DDlog components at all.  The ovn-northd integration I've been doing checks to 
see whether DDlog and its dependencies exist, and if they don't, the DDlog 
hooks are #if'd out.

> In terms of "proven in practice", OVN is at a stage where it's being
> used in production, so ideally we set a very high bar for a switchover
> like this.  It sounds like you're planning for that by enabling
> implementations to work in parallel instead of forcing a hard cutover
> early.  I would hope for something like multiple releases of a new
> implementation in experimental state, allowing plenty of time for
> testing in realistic, larger scale environments, and relying on
> reports of significant successes before a cutover.

Yes, there's not any rush in terms of cutting over other than not maintaining 
two different versions, so we'll make sure it's right.  (The DDlog code should 
actually be easier to maintain than the C-based version.*)  What we've talked 
about doing is to provide an option to allow DDlog to run in parallel and 
report any differences between what it generated and what the C code did.  In 
fact, when DDlog is built, I'm thinking that we'll run the unit tests in this 
mode, so that we should be able to catch any drifts early.  I'm hoping that 
people will try this mode out with actual workloads and report any issues they 
see.  

--Justin


* Below is an (admittedly) cherry-picked example of meter synchronization that 
was added to ovn-northd in OVS 2.10.

You can look at the current status of the ovn-northd DDlog implementation here:


https://github.com/ryzhyk/differential-datalog/blob/northd/test/ovn/ovn_northd.dl

I think this represents most of ovn-northd other than the DNS tables, which 
should be straight-forward, and logical flows, which we've just started adding.

-=-=-=-=- DDlog Version -=-=-=-=-

/* Meter_Band table */
for (mb in nb.Meter_Band) {
sb.Out_Meter_Band(.uuid_name = uuid2str(mb._uuid),
  .action = mb.action,
  .rate = mb.rate,
  .burst_size = mb.burst_size)
}

/* Meter table */
for (meter in nb.Meter) {
sb.Out_Meter(.name = meter.name,
 .unit = meter.unit,
 .bands = set_map_uuid2str(meter.bands))
}


-=-=-=-=- C Version -=-=-=-=-

struct band_entry {
int64_t rate;
int64_t burst_size;
const char *action;
};

static int
band_cmp(const void *band1_, const void *band2_)
{
const struct band_entry *band1p = band1_;
const struct band_entry *band2p = band2_;

if (band1p->rate != band2p->rate) {
return band1p->rate > band2p->rate ? -1 : 1;
} else if (band1p->burst_size != band2p->burst_size) {
return band1p->burst_size > band2p->burst_size ? -1 : 1;
} else {
return strcmp(band1p->action, band2p->action);
}
}

static bool
bands_need_update(const struct nbrec_meter *nb_meter,
  const struct sbrec_meter *sb_meter)
{
if (nb_meter->n_bands != sb_meter->n_bands) {
return true;
}

/* A single band is the most common scenario, so speed up that
 * check. */
if (nb_meter->n_bands == 1) {
struct nbrec_meter_band *nb_band = nb_meter->bands[0];
struct sbrec_meter_band *sb_band = sb_meter->bands[0];

return !(nb_band->rate == sb_band->rate
 && nb_band->burst_size == sb_band->burst_size
 && !strcmp(sb_band->action, nb_band->action));
}

/* Place the Northbound entries in sorted order. */
struct band_entry *nb_bands;
nb_bands = xmalloc(sizeof *nb_bands * nb_meter->n_bands);
for (size_t i = 0; i < nb_meter->n_bands; i++) {
struct nbrec_meter_band *nb_band = nb_meter->bands[i];

nb_bands[i].rate = nb_band->rate;
nb_bands[i].burst_size = nb_band->burst_size;
nb_bands[i].action = nb_band->action;
}
qsort(nb_bands, nb_meter->n_bands, sizeof *nb_bands, band_cmp);

/* Place the Southbound entries in sorted order. */
struct band_entry *sb_bands;
sb_bands = xmalloc(sizeof *sb_bands * sb_meter->n_bands);
for (size_t i = 0; i < sb_meter->n_bands; i++) {
struct sbrec_meter_band *sb_band = sb_meter->bands[i];

sb_bands[i].rate = sb_band->rate;

[ovs-discuss] Open vSwitch 2.10.1, 2.9.3, 2.8.5, 2.7.7, 2.6.4, and 2.5.6 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce a number of bug fix releases:

  http://openvswitch.org/releases/openvswitch-2.10.1.tar.gz

  http://openvswitch.org/releases/openvswitch-2.9.3.tar.gz

  http://openvswitch.org/releases/openvswitch-2.8.5.tar.gz

  http://openvswitch.org/releases/openvswitch-2.7.7.tar.gz

  http://openvswitch.org/releases/openvswitch-2.6.4.tar.gz

  http://openvswitch.org/releases/openvswitch-2.5.6.tar.gz

--The Open vSwitch Team 


Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Megaflow effectiveness problem

[Justin Pettit]

> On Sep 28, 2018, at 9:35 AM, Han Zhou  wrote:
> 
> On Wed, Sep 26, 2018 at 11:07 PM Justin Pettit  wrote:
> >
> > Hi, Han.  I'm still trying to come up with a mechanism I like, but in the 
> > meantime, can you try applying this patch and re-running your trace?  This 
> > should provide a better indication of what's causing that field to be 
> > un-wildcarded.
> >
> > Thanks,
> >
> > --Justin
> >
> >
> Thanks Justin for helping. I haven't used the patch yet since it causes 
> ovs-vswitchd crash in test case "ovn -- 3 HVs, 3 LS, 3 lports/LS, 1 LR".

That's embarrassing.  Can you try the attached patch?

> However, I believe I found the cause of the problem - it is enabling BFD (for 
> GW HA) that causes the un-wildcarding of the UDP flows. BFD uses UDP (port 
> 3784).
> 
> E.g. 
> recirc_id(0),tunnel(tun_id=0x0,src=10.169.108.123,dst=10.169.98.204,flags(-df+csum+key)),in_port(1),eth(),eth_type(0x0800),ipv4(proto=17,frag=no),udp(dst=3784),
>  packets:476, bytes:31416, used:0.068s, 
> actions:userspace(pid=3497583927,slow_path(bfd))
> 
> There is no user space flows for udp because BFD is handled implicitly 
> without specific open flow rules, but it impacts the megaflow wildcarding. I 
> verified this in my local test env by enabling BFD and then doing hping3 -2 
> ... to generate UDP packets destined to same IP but different udp ports, and 
> seeing the un-wildcarded flows in datapath, exactly like the example I 
> provided before. The problem disappears if BFD is not enabled (i.e. when 
> there is only one GW without HA).
> 
> Justin, do you have any thoughts on how to solve this problem? (I am not 
> familiar with this part of OVS, need more study)

Ben and I chatted about it, and we're surprised that the entire port is 
un-wildcarded, as opposed to a couple bits.  If you can try using the attached 
patch, it might help us track down the issue.

> For the patch that traces the un-wildcarding, I think it is still going to be 
> very useful for trouble-shooting such problems in the future. Please let me 
> know when you fix it and I can test with current use case.

Thanks!  I'll keep working on a cleaner version.

--Justin




new_wildcards_v2.diff
Description: Binary data



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Megaflow effectiveness problem

[Justin Pettit]

Hi, Han.  I'm still trying to come up with a mechanism I like, but in the 
meantime, can you try applying this patch and re-running your trace?  This 
should provide a better indication of what's causing that field to be 
un-wildcarded.

Thanks,

--Justin




new_wildcards.diff
Description: Binary data



> On Sep 6, 2018, at 7:07 PM, Han Zhou  wrote:
> 
> As mentioned in today's OVN meeting, I observed a problem regarding megaflow 
> effectiveness. Now I have more details but really need help from folks here. 
> Originally I thought it is due to the way OVN is programming the flows, but 
> now I even wonder it could be a problem in OVS (or my misunderstanding about 
> OVS).
> 
> In this OVN setup I observed unreasonably high flow-miss rate on chassis 
> nodes, especially the gateway nodes. Then with ovs-dpctl dump-flows I saw 
> many udp flows installed for same match conditions expect the udp dst port, 
> i.e. only the udp(dst=x) part is different. This would cause UDP sessions 
> latency, since in this scenario most of those udp packets are short lived 
> flows and all processed in slowpath. However I didn't see such problem for 
> TCP.
> 
> At first I suspected the dhcp port related flows in port-security stage could 
> cause the megaflow always have the udp port in the match condition, but it 
> turns out this is not the case because the dhcp flows matches the specific 
> broadcast IP and 0.0.0.0 only. I confirmed this by debugging on the gateway 
> node - there is no udp related flows installed at all in gateway node 
> userspace because port-security is not relevant for gateway node, and there 
> is no flow with tp_dst in match condition either. I verified by ovs-ofctl 
> dump-flows br-int | grep udp. i.e., below commands returns no result:
> 
> # ovs-ofctl dump-flows br-int | grep udp
> # ovs-ofctl dump-flows br-int | grep tp_dst
> # ovs-ofctl dump-flows br-int | grep tp_src
> 
> So could anyone explain what could cause so many megaflows installed in 
> datapath, each with specific udp dst port?
> 
> Please find the example flows and trace, ovn-detrace output here:
> https://gist.github.com/hzhou8/763e18c209aab40e7f3d6bd0690cea6f
> 
> Thanks,
> Han
> 
> ___
> 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] Creating system data path OVS in virtual machines

[Justin Pettit]

> On Sep 18, 2018, at 8:11 PM, karthik karra  wrote:
> 
> Hi All,
> 
> I am not able to create a system data path OVS on virtual machines running on 
> open stack. I am facing this error ovs-vsctl: Error detected while setting up 
> ‘br0’.
> 
> What could be the reason ?

It could be many things.  The ovs-vswitchd.log should contain some logging 
information.

> How two OVS interact on virtual machines? Will it be through GRE or VxLAN 
> tunneling OR Are there any more means to achieve the communication ?

You have many options; it depends on what you want to accomplish.  If you want 
to use private addresses between them, you probably want to use tunnels (GRE, 
VxLAN, Geneve) or VLANs.  In terms of management, you could write fairly simple 
OpenFlow flows or, if you need to create a much larger topology, use something 
like OVN.  I believe there are many examples on the Internet of using both 
approaches with OVS.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.10.0+2018.08.28+git.e0cea85314+ds2] testsuite: 975 2347 2482 2483 2633 failed

[Justin Pettit]

> On Sep 3, 2018, at 2:25 AM, Thomas Goirand  wrote:
> 
>> Does it consistently fail for you?
> 
> It's very deterministically failing indeed.

Thank you for the information.  I understand the nature of the issue, but I'm 
still thinking about the best way to address it.  In the test, we send three 
sets of 100 packets.  One of the sets drops packets at a rate of 10 per second, 
one at a rate of 5 per second, and one not at all.  On my computer, it takes 
roughly 0.67 seconds to send those 300 packets.  It appears that your computer 
takes over 15 seconds, which means that the 10 per second meter isn't hitting 
at all, and all packets are getting through.  The test was intended to allow 
some flexibility in run-time, but not that extreme.

I hope to have a fix out for it tomorrow, though.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.10.0+2018.08.28+git.e0cea85314+ds2] testsuite: 975 2347 2482 2483 2633 failed

[Justin Pettit]

> On Sep 1, 2018, at 3:52 PM, Ben Pfaff  wrote:
> 
> On Sat, Sep 01, 2018 at 01:23:32PM -0700, Justin Pettit wrote:
>> 
>>> On Sep 1, 2018, at 12:21 PM, Thomas Goirand  wrote:
>>> 
>>> 
>>> The only one failure:
>>> 
>>> 2633: ovn -- ACL rate-limited logging FAILED (ovn.at:6516)
>> 
>> My guess if that this is meter-related. Can you send the ovs-vswitchd.log 
>> and testsuite.log so I can take a look?
> 
> It probably hasn't changed from what he sent the first time around.

Yes, "testsuite.log" was in the original message, so I don't need that.  
Thomas, can you send me "ovs-vswitchd.log" and "ovn-controller.log"?  Does it 
consistently fail for you?

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.10.0+2018.08.28+git.e0cea85314+ds2] testsuite: 975 2347 2482 2483 2633 failed

[Justin Pettit]

> On Sep 1, 2018, at 12:21 PM, Thomas Goirand  wrote:
> 
> 
> The only one failure:
> 
> 2633: ovn -- ACL rate-limited logging FAILED (ovn.at:6516)

My guess if that this is meter-related. Can you send the ovs-vswitchd.log and 
testsuite.log so I can take a look?

Thanks,

—Justin



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch 2.10.0 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.10.0:

  http://openvswitch.org/releases/openvswitch-2.10.0.tar.gz

A few other feature highlights of 2.10.0 include:

 - ERSPAN support.

 - ovs-vswitchd and utilities support DNS names for OpenFlow and OVSDB remotes.

 - Added ability to rate-limit controller actions.

 - Linux kernel support for connection track table limits.

 - Linux kernel support for meters.

 - Linux kernel support up to 4.15.

 - OVN: Implemented TCP reset and ICMP unreachable actions for ACLs.

 - OVN: Added ACL message rate-limiting.

 - And many others.  See the full change log here:

http://openvswitch.org/releases/NEWS-2.10.0

Enjoy!

--The Open vSwitch Team   

   
Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] The kernel module does not support meters

[Justin Pettit]

Right, the OVS out-of-tree kernel module (the one that ships with OVS) doesn't 
support kernels greater than 4.14 yet.  When OVS 2.10 ships, the plan is to 
include support for at least kernel 4.15.

The Linux kernel includes an OVS kernel module, which always works with 
whatever Linux kernel it ships with.  However, it will only include whatever 
OVS features were included at the time of that kernel release.  We maintain the 
out-of-tree kernel module so that we can introduce new features to those older 
kernels.  Maintaining this backwards compatibility in the out-of-tree kernel 
module can be fairly complex at times, which is why it sometimes lags behind 
the latest kernel releases.

--Justin


> On Aug 6, 2018, at 11:36 PM, Vikas Kumar  wrote:
> 
> Thanks for your reply Justin, 
> I had Linux kernel 4.15 version earlier, but when i was trying to configure 
> the ovs master version, in that case i was getting some other error.
> please see below my previous conversation, 
> 
> 
> Vikas Kumar 
> Aug 2 (5 days ago)
> 
> to bugs
> hi Team,
> i am using ubuntu 16.0. i am trying to configure the ovs source code, but i 
> am getting the below error message. please help me on this
> 
> configure: error: Linux kernel in /lib/modules/4.15.0-29-generic/build is 
> version 4.15.18, but version newer than 4.14.x is not supported (please refer 
> to the FAQ for advice)
> 
> Regards
> vikash
> 
> Darrell Ball 
> Aug 2 (5 days ago)
> 
> to me, bugs
> Means your kernel has been upgraded to 4.15 in your Xenial environment (check 
> uname –r)
>  
> Latest OVS release supports up to 4.14
>  
> http://docs.openvswitch.org/en/latest/faq/releases/
> Second question.
>  
>  
> From:  on behalf of Vikas Kumar 
> 
> Date: Thursday, August 2, 2018 at 2:08 AM
> To: "b...@openvswitch.org" 
> Subject: [ovs-discuss] Bug in configuring of Ovs
> 
> Actually i want to dump the ovs flows for my investigation.
> 
> Thanks 
> Vikash
> 
> On Tue, Aug 7, 2018 at 2:17 PM, Justin Pettit  wrote:
> 
> > On Aug 6, 2018, at 8:49 PM, Vikas Kumar  wrote:
> > 
> > hi Team,
> > kindly help me on this, when i am typing sudo ovs-dpctl dump-flows command, 
> > i am getting the below error
> > |1|dpif_netlink|INFO|The kernel module does not support meters.
> > 
> > I am using the below ubuntu version:
> > 
> > 4.14.13-041413-generic
> 
> Meters were introduced to the Linux kernel in 4.15, so earlier versions don't 
> support them.  Unfortunately, all the released upstream kernels have a bug in 
> them that prevents meters from being used properly.  A patch was recently 
> accepted upstream, which means that new releases (including maintained older 
> kernels) should receive the fix.
> 
> The OVS 2.10 out-of-tree kernel module will contain meters on all supported 
> kernels.
> 
> All of that said, unless you need meters, you can just ignore that message; 
> it's just informational.
> 
> --Justin
> 
> 
> 

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] The kernel module does not support meters

[Justin Pettit]

> On Aug 6, 2018, at 8:49 PM, Vikas Kumar  wrote:
> 
> hi Team,
> kindly help me on this, when i am typing sudo ovs-dpctl dump-flows command, i 
> am getting the below error
> |1|dpif_netlink|INFO|The kernel module does not support meters.
> 
> I am using the below ubuntu version:
> 
> 4.14.13-041413-generic

Meters were introduced to the Linux kernel in 4.15, so earlier versions don't 
support them.  Unfortunately, all the released upstream kernels have a bug in 
them that prevents meters from being used properly.  A patch was recently 
accepted upstream, which means that new releases (including maintained older 
kernels) should receive the fix.

The OVS 2.10 out-of-tree kernel module will contain meters on all supported 
kernels.

All of that said, unless you need meters, you can just ignore that message; 
it's just informational.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding ovs metering behaviour

[Justin Pettit]

> On Jul 11, 2018, at 11:06 PM, NITIN ANAND  wrote:
> 
> I am using metering feature in ovs-dpdk.
> I added meter using below command.
> "ovs-ofctl -Oopenflow13 add-meter br-int meter=1,kbps,band=type=drop,rate=100"
> And i added flows as below -
> "ovs-ofctl -OOpenFlow13 add-flow br-int 
> priority=1,table=0,in_port=vhue24dfb5e-d1,dl_type=0x0800,actions=meter:1,goto_table:1"
> "ovs-ofctl -OOpenFlow13 add-flow br-int 
> priority=1,table=1,in_port=vhue24dfb5e-d1,dl_type=0x0800,actions=output=vhuff4faf96-f8"
>  
> My intention to have above 2 flow is -
> 1)do metering in table 0 after flow criteria match
> 2)Then do extra processing as needed in table 1 (not depicted in above flow 
> add command).
>  
> But the behaviour i observed in testing with traffic is .. All packets are 
> being hit in table 1 and table 0. Though final rate at which the packets are 
> comign out of port "vhuff4faf96-f8"  is 100Kbps correctly.
> So from the stats it looks like, all packets hit table 1 and then metering 
> was applied.
> My expection was to get only upto 100kbps traffic in table 1, not the entire 
> input traffic. i.e metering has to be applied instantly. 
>  
> Please clarify whether its bug in ovs-dpdk or its expected behaviour 
> currenlty ?

This is expected behavior due to OVS's architecture.  OVS will take the first 
packet from a flow and run it through the flow table to generate a megaflow 
entry, which will then be placed in a cache that sits in front of the full 
table.  Future packets that look similar to the packet will hit the megaflow 
entry instead of going through the full table.  (This speeds up the performance 
significantly over sending every packet through the entire flow table.)  This 
design means that something like metering will be applied after the packet has 
run through the entire flow table.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch 2.9.2, 2.8.4, 2.7.6, and 2.6.3 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce a number of bug fix releases:

   http://openvswitch.org/releases/openvswitch-2.9.2.tar.gz

   http://openvswitch.org/releases/openvswitch-2.8.4.tar.gz

   http://openvswitch.org/releases/openvswitch-2.7.6.tar.gz

   http://openvswitch.org/releases/openvswitch-2.6.3.tar.gz

The most serious issue addressed in these releases were DPDK build issues 
introduced in the previous release.

--The Open vSwitch Team 


Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-ofctl mod-port doesn't work with ports in network namespaces

[Justin Pettit]

> On May 11, 2018, at 3:00 AM, Jakub Libosvar  wrote:
> 
> Hi all,
> it seems I hit a bug when trying to implement a fix in OpenStack Neutron
> that uses heavily network namespaces with OVS internal ports in them.
> 
> Ports attached to OVS bridge that are placed in network namespace can't
> have their status changed using 'ovs-ofctl mod-port' command.
> 
> Steps to reproduce:
> 
> ovs-vsctl add-br test-br
> ovs-vsctl add-port test-br test-port -- set Interface test-port
> type=internal
> ip net a test-ns
> ip l s test-port netns test-ns
> ovs-ofctl mod-port test-br test-port up
> 
> -- check that port is still down
> ip net e test-ns ip l sh test-port
>test-port:  <--- port is still DOWN

I think this is expected behavior.  You're moving the port into a different 
namespace from ovs-vswitchd, so the port doesn't actually exist in its view 
anymore.  (You probably don't get interface counters either and it won't show 
up in utilities like ifconfig.)  However, ovs-vswitchd still has a handle to 
the interface so that it can send and receive traffic.  The advantage is that 
you get much better performance than something like veths, but you do get some 
weirdness like this, since its sort of breaking the namespace model.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Justin Pettit]

> On May 2, 2018, at 2:50 AM, Vishal Deep Ajmera 
>  wrote:
> 
>> Zak is working on that feature; I expect patches will hit the mailing list 
>> in the next week or two.
>> 
>> Hi Justin,
>> 
>> As part of this feature, will it also enable us to rewrite the options 
>> tlv:type field from SLL (1) to TLL (2) Or may be a set-field option to 
>> rewrite these fields in Options TLV. This will help in supporting multicast 
>> solicitations.

I believe you should already be able to set the SLL and TLL options.  Does that 
not work for you?

> In case you have an RFC patch ready for this feature, can you please post it 
> ? We can help in reviewing and testing it.

Zak said he should be posting it this week.  We always appreciate help 
reviewing and testing code.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS as a destination

[Justin Pettit]

> On May 2, 2018, at 8:40 AM, Sh j  wrote:
> 
> For example, if an OVS receives a ICMP_reply and it is the destination of 
> this ICMP_reply, it does not need to send a packet_in to the controller. 
> So I want to install some flow rules or configure OVS to not send packet_in 
> messages in this case.
> 
> I am using ONOS as a controller. The problem is that when the OVS connects to 
> the controller, all flow rules added manually are disappeared. 
> 
> Is there any way to force OVS to keep some kind of flow rules and connecting 
> to the controller does not affect that?

It sounds like your controller is deleting the flows, not OVS itself.  I think 
you'll need to make your controller not do that for the manually added flows.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenVswitch on a host with only one cellular modemconnected to internet

[Justin Pettit]

> On Apr 30, 2018, at 7:59 PM, EMANUEL FERNANDO MONTOYA GOMEZ 
>  wrote:
> 
> I am working in a project on which I want to have a couple of hosts that has 
> 2 ethernet interfaces and 1 cellular modem, but only the cellular modem has 
> internet access.
> I haven't been able to make them connect to controller.
> When I try using the ethernet interfaces it works perfectly, but I need to 
> make it work using the cellular one.
> I use nmcli to connect to cellular APN and it works (when not using 
> openvswitch)
> I appreciate any suggestion you may give on this topic. I haven't found 
> information on this specific subject.

I'm not familiar with this particular use-case.  However, as long as the 
cellular APN shows up as a Linux system device and delivers Ethernet frames, I 
don't know why it wouldn't work; OVS doesn't really care what kind of interface 
is attached.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg IPv6 Neighbor Advertisement Message fields

[Justin Pettit]

> On Apr 8, 2018, at 9:55 AM, Ben Pfaff  wrote:
> 
> On Sun, Apr 08, 2018 at 04:34:16PM +, Vishal Deep Ajmera wrote:
>> 
>> In the above message, fields R (Router flag), S (Solicited flag) and O
>> (Override flag) cannot be set. Is my understanding correct ?
> 
> Yes.
> 
> It would be reasonable to be able to match and set these, so I imagine
> that we would accept patches to enable that.

Zak is working on that feature; I expect patches will hit the mailing list in 
the next week or two.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] (no subject)

[Justin Pettit]

> On Mar 22, 2018, at 12:21 AM, Roja Guru  wrote:
> 
> hellowhat is the OVS maximum number of flow entries 

There is no hard limit--only the amount of memory on your system.  The rule of 
thumb we use is roughly 1KB per OpenFlow rule, but that can obviously vary a 
lot depending on the matches and actions defined.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Way to get average time spent

[Justin Pettit]

Greg (cc'd) could probably provide you a better answer, but I suspect the perf 
tool is a good place to start.

--Justin


> On Mar 12, 2018, at 3:24 AM, Krish  wrote:
> 
> Hi users,
> 
> I need to get the average time spent in packet extraction then in first level 
> cache , second level cache. I don't know the way to measure that.
> 
> Can anyone please help me pointing to right direction?
> I think, I need to modify some code. Please guide me if I am right or wrong.
> 
> 
> Looking forward for a response from someone.
> 
> 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

Re: [ovs-discuss] bond-rebalance-interval

[Justin Pettit]

It should work.  How are you setting it?

--Justin


> On Mar 8, 2018, at 5:57 PM, Chris Boley  wrote:
> 
> bond-rebalance-interval=1
> 
> If I set this option to any other setting such as 5000 for example it always 
> shows 1 on the output of an sudo ovs-vsctl list port vbond0 command.
> 
> My version is 2.5.2. Is this rebalance interval negotiated between the Cisco 
> etherchannel that I am peering with happens to depend on what the peer is 
> willing to do or am I missing something?
> 
> Thank you,
> CB
> 
> ___
> 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

[ovs-discuss] Open vSwitch 2.9.0 and 2.8.2 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.9.0:

 http://openvswitch.org/releases/openvswitch-2.9.0.tar.gz

A few other feature highlights of 2.9.0 include:

 - No longer slow-path traffic that is sent to a controller.

 - The DPDK version of OVS adds support for DPDK v17.11 and vHost IOMMU.

 - OVN adds support to send IPv6 Router Advertisement packets in response to
   the IPv6 Router Solicitation packets from VIF ports.

 - NSH support in the Linux kernel datapath.

 - Support for Linux kernels up to 4.13.

 - And many others.  See the full change log here:

 http://openvswitch.org/releases/NEWS-2.9.0

In addition to the 2.9.0 release, we've also released 2.8.2:

 http://openvswitch.org/releases/openvswitch-2.8.2.tar.gz

This release contains bug fixes for 2.8.1 as well as updating NSH support to 
the latest IETF draft.

We plan to release 2.9.1 in the near future that will add support for clustered 
OVSDB using the Raft consensus algorithm.  This will be particularly useful for 
OVN, since it will allow multiple instances of the database to be run to 
provide better performance and reliability.

Enjoy!

--The Open vSwitch Team   

   
Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.9 [kernel 4.13]

[Justin Pettit]

> On Feb 19, 2018, at 7:18 AM, Avi Cohen (A)  wrote:
> 
> My kernel is 4.13 and according 
> http://docs.openvswitch.org/en/latest/faq/releases/ the only ovs compatible 
> is 2.9. but I cannot find it ..

It should be released today or tomorrow.

--Justin



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] flow ID in OVS switch

[Justin Pettit]

OVS supports associating a 64-bit "cookie" with each flow.  The actions to 
delete and modify flows support matching flow cookies with an arbitrary 
bitmask. I haven't used RYU, so I don't know whether exposes that amount of 
flexibility.

--Justin


> On Feb 8, 2018, at 6:08 PM, Taha Khan  wrote:
> 
> Hi,
> 
> Is there any unique (flow ID or name) to differentiate between flows on a 
> particular OVS switch?
> In my application I need to take actions on particular flow entries and not 
> all of them, it would be helpful if there is something like this.
> I am using RYU as controller. 
> 
> Thanks!
> Taha 
> 
> ___
> 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] Block outgoing packets on a specific port

[Justin Pettit]

> On Jan 18, 2018, at 3:27 PM, Ajit Warrier  wrote:
> 
> Our OVS runs a broadcast app that sends UDP packets out on br0. Currently as 
> expected, these packets go out of all interfaces in br0. I would like to 
> force it such that these packets do NOT go out of a specific interface, but 
> still goes out of the other interfaces.
> 
> I tried using open flow as below:
> 
> /tmp/ovs-ofctl add-flow br0 dl_type=0x800,nw_proto=17,tp_dst=699,actions=drop
> 
> What I am missing is a way to specify the egress port. Is this possible ?

The only thing that comes to mind is to enumerate the ports it should go to, 
and then it will be implicitly dropped to that port.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Blocking traffic between 2 ports

[Justin Pettit]

> On Dec 12, 2017, at 7:27 AM, Pradeep K.S  wrote:
> 
> Hi,
> 
> I want to restrict traffic between 2 ports, is there any direct way of 
> achieving that in OVS ?
> 
> I can do that by adding multiple flows(block destination mac, redirecting 
> broadcast/multicast traffic to uplink, and add flows for flood during unicast 
> mac resolution).
> 
> Any pointers would be helpful.

I'm not sure what you're asking.  It shouldn't be too hard to write the types 
of flows you've described below, and it should be pretty easy to find examples 
on line and in the documentation.  If you're looking for a place to start, you 
may want to look at the ovs-ofctl man page.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Programming flows to bond port

[Justin Pettit]

As Ben mentioned, unfortunately, bonds don't have OpenFlow port number.  
Depending on what you want to do, you may be able to get similar results with 
either the "group" functionality or the "bundle" action (note this is the OVS 
bundle action and not OpenFlow bundle transaction semantics--they're both 
described in the ovs-ofctl man page).

--Justin


> On Dec 4, 2017, at 6:12 AM, Pradeep K.S  wrote:
> 
> I have a created bond interface, with multiple slaves. I want to program flows
> such that packets arriving on port X -> should be directed to bond port  But 
> the
> problem is bond port doesn't have ofportid, how to program such a flow using 
> ovs-ofctl
> 
> I tried setting bond_fake_iface, still I don't get  ofportid to program 
> ovs-ofctl flows.
> 
> -- 
> Thanks and Regards,
> Pradeep.K.S.
> ___
> 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] Max number of tables and flows can be configured in OVS

[Justin Pettit]

> On Oct 2, 2017, at 8:43 PM, BALL SUN  wrote:
> 
> Hi
> 
> is there anyone know is there any limitation on the number of tables
> and flows can be configured in OVS?

As defined in OpenFlow, there's a limit of 256 user-accessible tables.  There 
is no limit on the number of flows beyond memory available on the system; you 
can place limits if that's desired, though.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch 2.8.1, 2.7.3, and 2.5.4 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.8.1:

   http://openvswitch.org/releases/openvswitch-2.8.1.tar.gz

As well as the release of Open vSwitch 2.7.3:

   http://openvswitch.org/releases/openvswitch-2.7.3.tar.gz

These releases contain bug fixes and minor improvements to the 2.8 and 2.7 
release branches, respectively.

In addition to the 2.8.1 and 2.7.3 release, we've also released 2.5.4 from our 
LTS branch, which contains fixes for 2.5.3:

   http://openvswitch.org/releases/openvswitch-2.5.4.tar.gz

--The Open vSwitch Team 


Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Compatible DPDK version for 2.4.0 OVS

[Justin Pettit]

According to the FAQ, the version is DPDK 2.0:

http://docs.openvswitch.org/en/latest/faq/releases/

If that's incorrect, we should update the FAQ.

i agree with Ben, though, that's it's probably best to use OVS 2.8.

Thanks,

--Justin


> On Sep 11, 2017, at 7:57 AM, Avi Cohen (A)  wrote:
> 
> dpdk-2.1.0.
>  
> From: ovs-discuss-boun...@openvswitch.org 
> [mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Ranjith Kumar D
> Sent: Monday, 11 September, 2017 5:48 PM
> To: disc...@openvswitch.org
> Subject: [ovs-discuss] Compatible DPDK version for 2.4.0 OVS
>  
> Hi,
>  
> I am using DPDK 2.0 for OVS 2.4.0  and DPDK library linking is failing while 
> configuring OVS. Is there any specific version of DPDK I should use for 2.4.0 
> OVS ?
>  
> Regards,
> Ranjith
> ___
> 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

[ovs-discuss] Open vSwitch 2.8.0 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.8.0:

 http://openvswitch.org/releases/openvswitch-2.8.0.tar.gz

A few other feature highlights of 2.8.0 include:

- Support for multiple VLANs (802.1ad or "QinQ"), including a new 
"dot1q-tunnel" port VLAN mode

- Added NAT support for userspace datapath

- New vxlan tunnel extension "gpe" to support VXLAN-GPE tunnels

- New support for non-Ethernet (L3) payloads in GRE and VXLAN-GPE

- All features required by OpenFlow 1.4 are now implemented

- Support for ovsdb-server role-based access control (RBAC)

- Experimental NSH (Network Service Header) support in userspace datapath

- Experimental support for hardware offloading

- Support for Linux kernels up to 4.12

- OVN:

 * Built-in DNS support for OVN

 * IPAM can assign IPv6 addresses

 * OVSDB RBAC support to reduce impact of compromised hypervisors

 * Support for ACL logging

- And many others.  See the full change log here:

 http://openvswitch.org/releases/NEWS-2.8.0

Enjoy!

--The Open vSwitch Team   

   
Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [Super TIME SENSITIVE] Setting QOS for OVS Swtiches

[Justin Pettit]

> On Aug 21, 2017, at 5:28 AM, Fahmy Sherif Alaa Salaheldin 
>  wrote:
> 
> Good Afternoon,
> 
> I am trying to use Mininet together with OVS and a RYU controller to emulate 
> a simple network.
> 
> I was wondering if some could tell me IF it is possible to set queues/qos 
> through linux tc and then they would show up in the commands:
> 
> sh ovs-vsctl list Qos
> sh ovs-vsctl list Queue
> 
> What I am doing now is for instance,
> 
> tc qdisc add dev s2-eth5 rot handle 1: drr 
> 
> then add two sub classes (what I want as my queues)
> 
> tc class add dev s2-eth5 parent 1: classid 1:1 drr quantum 100
> tc class add dev s2-eth5 parent 1: classid 1:2 drr quantum 200
> 
> then because I know it is necessary I add a filter that basically let's 
> everything pass through it, 
> 
> tc filter add dev eth0 protocol ip parent 1: prio 1 u32 
> 
> But nothing shows in my queues/qos tables.. I am a beginner and I apologize 
> if this is trivial but any thoughts?
> My goal is to create one QOS per port that has 2-3 queues that are served in 
> a Deficit Round Robin (DRR) Fashion!!

OVS uses the tc subsystem in the opposite direction that you're suggesting.  
Those ovs-vsctl commands modify fields in a database. ovs-vswitchd takes that 
configuration and makes tc calls to configure qos on Linux.  If you call tc 
directly, OVS will not read your changes back and update the configuration 
database.

If OVS does not provide the configuration knobs you want, you can directly call 
tc and skip the ovs-vsctl configuration entirely.  I would be careful if you do 
both, though, since you're likely to get a broken configuration if both you and 
ovs-vswitchd are modifying tc.

If you think your configuration is generally useful, you could propose changes 
to OVS to support what you're suggesting.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Adding a new action (port statistics)

[Justin Pettit]

> On Aug 20, 2017, at 10:10 AM, Rahul Sharma  wrote:
> 
> Hi everyone,
> 
> I am new here, so in case this has already been answered, or it's not the 
> appropriate place to ask, kindly let me know.
> 
> I am trying to add a custom action to openflow by making some code changes in 
> the OVS. The action which would send port statistics to the controller on 
> receipt of a particular matching packet. Would the proper procedure to add 
> such an action be documented somewhere, as it would make things quite easier 
> for me.

The implementation would vary depending on which datapath you're targeting, but 
the general answer is that there is not such documentation.  What you may want 
to do is look for when such a feature was introduced in the past and look at 
the commit to see what changes were made.

Good luck!

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Hashing to megaflow entry

[Justin Pettit]

> On Aug 21, 2017, at 8:19 AM, Sara Gittlin  wrote:
> 
> One more - I did not see in the article that if a match is found in
> megaflow cache - then a microflow is generated to be installed in the
> microflow cache to improve performance for subsequnce packets

An exact-match cache (microflow cache) is an implementation of the datapath.  
The userspace and out-of-tree OVS Linux kernel module that ships as part of OVS 
contain an exact-match cache that's managed by the datapath.  The upstream OVS 
kernel module that ships with the Linux kernel was rejected by the Linux 
upstream community, so it does not contain one.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Hashing to megaflow entry

[Justin Pettit]

> On Aug 16, 2017, at 11:56 PM, Sara Gittlin  wrote:
> 
> Hi,
> Suppose we support megaflows, How the hashing is performed in the
> kernel module ?
> when packet arrives how do we know 'beforehand' to mask key fields in
> order to hit the megaflow entry ?

If you haven't done so already, I'd highly recommend looking at our NSDI paper 
that answers many of your questions:


https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf

I hope you find it helpful.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 802.1ad (QinQ) Support

[Justin Pettit]

> On Jul 27, 2017, at 6:00 AM, Eric Garver  wrote:
> 
> On Thu, Jul 27, 2017 at 02:25:46PM +0530, Sudhanshu Gupta wrote:
>> Thanks Eric, for replying.
>> 
>> Is there any tentative date for release of OVS 2.8?
> 
> I don't think there is a set date, but I believe the branch for 2.8 is
> due to be created "soon".

I'm hoping that we branch this week.  The official plan is to release 2.8 in 
August.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openflow with openwrt

[Justin Pettit]

> On Jul 27, 2017, at 8:32 AM, Mohamed Ibrahem via discuss 
>  wrote:
> 
>> hello guys,
>> i have a problem with router tplink wr841N , i have installed openwrt to
>> install openflow and get the following message when starting the openflow
>> /etc/init.d.openflow/ start
>> appears, 
>> / sbin / ofup: line1: ofdatapath: not found no need for further
>> configuration out-of-band control 
>> / sbin / ofup: line4: ofprotocol: not found
> 
> can any one help me to solve this problem??

I don't think you're running Open vSwitch.  I have heard of people running Open 
vSwitch on OpenWrt, though.

--Justin




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch 2.7.2 and 2.5.3 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.7.2:

   http://openvswitch.org/releases/openvswitch-2.7.2.tar.gz

This release contains bug fixes and minor improvements for 2.7.1.  Due to an 
issue introduced in the previous release, it is highly recommended that users 
of 2.7.1 upgrade.

In addition to the 2.7.2 release, we've also released 2.5.3 from our LTS 
branch, which contains fixes for 2.5.2:

   http://openvswitch.org/releases/openvswitch-2.5.3.tar.gz

--The Open vSwitch Team 


Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Throughput losses with HP Switch

[Justin Pettit]

I don't think this is the right forum for this question, since it doesn't seem 
related to OVS.  However, if I were to speculate, my guess is that the 
forwarding ASIC doesn't support modifying the ToS bits, so the packets are 
being forwarded to the management CPU to handle these packets.  You could 
probably get more definitive answers from an HP forum.

Good luck.

--Justin


> On Jul 12, 2017, at 11:01 PM, Chaitanya Kumar  
> wrote:
> 
> Hi
>   We are working on a research project that involves HP OpenFlow-enabled 
> switch (HP 3500 yl). We are facing some issues with performance particularly 
> when operating the switch in "OpenFlow" mode. The switch is controlled via a 
> desktop running the Ryu controller.
> The rules on the switch match packets based on the fields supported by 
> OpenFlow. Further, the switch also modifies a certain IP header field (in 
> this case the ToS bits) for packets that match the rules and are hence 
> forwarded. 
> 
> More precisely, the rules match the ToS bits of the packet and change them to 
> a different value before forwarding them to a chosen host. 
> 
> However, in the process, the forwarded packets achieve a throughput of no 
> more than 700kbps, while the source and destination hosts have 100 Mbit/s 
> Ethernet ports. 
> If we disable "OpenFlow" mode and use it as it is then we achieve a full 
> throughput of 100Mbit/s (the Ethernet link speeds of the client and server 
> hosts). The end-to-end throughput was measured using 
> iperf. 
> 
> Could someone shed some light on the reason for this drastic performance 
> degradation? (all the switch does is match packets whose ToS value is (say,) 
> 0x28 and replaces it with 0x40 before forwarding them to the right 
> destination)
> Also, is there an alternative switch that someone has used successfully for 
> similar things?
> 
> A figure showing our experiment scenario is given below, for reference.
> 
> 
> 
> Thanks,
> Chaitanya
> 
> ___
> 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] Information on Bugs in OVS v2.3.x

[Justin Pettit]

> On Jul 11, 2017, at 8:55 AM, Anand Nande  wrote:
> 
> Hello list,
> 
> I need information/list of all the bugs that were present in v2.3.x. 
> 
> status of the bugs can be anything (CLOSED,WONTFIX,OPEN ..etc.)
> 
> Is there a way I can pull this info down from any source? 

We don't have a central bug tracker.  You could look at the OVS github branch 
"branch-2.3" to see what's been fixed, but there's not an easy way to determine 
all issues that have been raised through various mailing lists.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch 2.7.1 Available

[Justin Pettit]

The Open vSwitch team is pleased to announce the release of Open vSwitch 2.7.1:

   http://openvswitch.org/releases/openvswitch-2.7.1.tar.gz

This release contains bug fixes and minor improvements for 2.7.0.

--The Open vSwitch Team 


Open vSwitch is a production quality, multilayer open source virtual switch. It 
is designed to enable massive network automation through programmatic 
extension, while still supporting standard management interfaces. Open vSwitch 
can operate both as a soft switch running within the hypervisor, and as the 
control stack for switching silicon. It has been ported to multiple 
virtualization platforms and switching chipsets.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] connecting switches

[Justin Pettit]

> On Jun 16, 2017, at 6:19 PM, Bruce Hartpence  wrote:
> 
> Hello all - I am working on a use case for ovs with multiple hypervisors. I 
> am using ODL Carbon for the controller and can get all OVS instances to 
> appear in DLUX but I am missing the boat on interconnecting the switches 
> themselves. So, VMs on the different hypervisors cannot communicate. The 
> documentation suggests that patch interfaces can be used to handle this but 
> it appears to be for bridge instances on the same OVS VM. 

Yes, patch ports are just used to connect bridge instances on the same 
hypervisor.  You'll want to use tunnels to connect between hypervisors.  You 
should be able to find plenty of tutorials online.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openflow-discuss] Why do port numbers continue to change when I configure ovs with openstack?

[Justin Pettit]

> On Jun 7, 2017, at 7:59 AM, Nam Bong Ha  wrote:
> 
> Hi, all :)
> 
> 
> Why do port numbers continue to change when I configure ovs with openstack?
> 
>  
> 
> I want to fix the port number of the int-br-wan of br-int(bridge)
> 
>  
> 
> However, the port number of int-br-wan continues to increase (55 ... 58 ... 
> 60 ... 62 ... 1070)
> 
>  
> 
> I tried the following command but it was useless.
> 
> $ ovs-vsctl - set Interface int-br-wan ofport_request = 19
> 
>  
> 
> I used openstack to configure the environment as follows.
> 
> openvswitch v2.0.2

-- Please don't cross-post. --

According to the documentation:

  ofport_request: optional integer, in range 1 to 65,279
 Requested OpenFlow port number for this interface.

 A client should ideally set this  column’s  value  in  the  same
 database  transaction that it uses to create the interface. Open
 vSwitch version 2.1 and later will honor a later request  for  a
 specific  port  number,  althuogh  it  might  confuse  some con‐
 trollers: OpenFlow does not have a way to announce a port number
 change,  so  Open  vSwitch represents it over OpenFlow as a port
 deletion followed immediately by a port addition.

 If ofport_request is set or changed to some other  port’s  auto‐
 matically  assigned port number, Open vSwitch chooses a new port
 number for the latter port.

You didn't set it in the same transaction.  It should stick after a reboot, but 
it's unclear what you're doing exactly.  If you want to make it work the first 
time, I'd make sure that it's done in the same transaction that created the 
port and that another port doesn't already have the same OpenFlow port number.

---Justin




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] UDP Packets not forwarded by OVS

[Justin Pettit]

> On May 17, 2017, at 7:02 AM, Advith Nagappa  wrote:
> 
> I have created two namespaces ns1 and ns2 and attached them to the ovs-tap 
> ports (using veth pairs).
> 
> I am able to send TCP and ICMP packets between the two namespaces. 
> eg: ip netns exec ns1 traceroute -I 10.1.1.1  && ip netns exec ns1 traceroute 
> -T 10.1.1.1.1
> 
> but doing the same with UDP fails (doesn't find hops)
> ip netns exec ns1 traceroute 10.1.1.1
> 
> 
> I have disabled iptables and ufw (firewall). 
> 
> Also, if i add a rule for UDP specifically:
> ovs-ofctl add-flow br0  
> priority=,dl_type=0x0800,nw_proto=17,nw_dst=10.1.1.1,tp_dst=9877,actions=NORMAL,
> 
> i see that this rule is hit.(packet count increases in dump-flows), but 
> forwarding is not done.
> 
> Has anyone gone through a similar issue and come out with new wisdom to 
> share? Would be be very helpful..

That sounds very strange, and I don't see how OVS could be at fault.  You could 
dump the datapath flows to make sure that they're in fact forwarding the 
packets.  If they are, then it's almost certainly outside of OVS.  Have you 
checked to make sure that there are no firewall rules or other issues in the 
namespaces?  You may want to run tcpdump in various spots to see where the 
packets are getting dropped.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Ping Drop Problem

[Justin Pettit]

It's in the FAQ, ovs-vsctl man page, ovs-vswitchd.conf.db man page, and 
probably other places.

--Justin


> On May 26, 2017, at 10:06 AM, Gale Price <gpr...@lenovo.com> wrote:
> 
> No I do not... 
> Where do I turn it off?
> 
> 
> Gale (Dean) Price
> Lead Admin - Remote Services Lab
> Lab Infrastructure Services & Support
> 8001 Development Drive Morrisville, NC 27560
> Lenovo USA
> Ph: 919-237-8421
> 297-8421
> gpr...@lenovo.com
>  
> 
> Lenovo.com 
> Twitter | Facebook | Instagram | Blogs | Forums
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Justin Pettit [mailto:jpet...@ovn.org] 
> Sent: Friday, May 26, 2017 1:00 PM
> To: Gale Price
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] Ping Drop Problem
> 
> It looks like you're having STP (spanning tree) issues.  Are the OVS 
> instances running in the VMs?  I'm wondering if your shutting down those VMs 
> is causing STP to get confused, since there are various time outs for state 
> changes in STP.  Do you need to run STP?
> 
> --Justin
> 
> 
>> On May 26, 2017, at 7:09 AM, Gale Price <gpr...@lenovo.com> wrote:
>> 
>> Well tcpdump didn’t really give me any relevant info.
>> 
>> But in testing some of the VM's I noticed that one of my older VM's did not 
>> cause a Ping drop system wide when shutdown.
>> 
>> But my newer VM's does cause it when shutdown... 
>> 
>> Here is my ovs-vswitchd.log when the newer vm is shutdown.
>> 
>> It takes about 5-6 pings to get from "Dropped" to "topology", once the 
>> topology changes the system wide pings start back up.
>> 
>> 2017-05-26T13:50:10.819Z|01271|ofproto|WARN|ovsbr1: cannot get STP 
>> status on nonexistent port 106
>> 2017-05-26T13:50:10.819Z|01272|ofproto|WARN|ovsbr1: cannot get RSTP 
>> status on nonexistent port 106 
>> 2017-05-26T13:50:10.823Z|01273|netdev_linux|WARN|ethtool command 
>> ETHTOOL_GDRVINFO on network device vnet33 failed: No such device 
>> 2017-05-26T13:50:10.825Z|01274|netdev_linux|WARN|ethtool command 
>> ETHTOOL_GSET on network device vnet33 failed: No such device
>> 2017-05-26T13:50:10.830Z|01275|netdev_linux|INFO|ioctl(SIOCGIFHWADDR) 
>> on vnet33 device failed: No such device
>> 2017-05-26T13:50:10.832Z|01276|netdev_linux|WARN|ioctl(SIOCGIFINDEX) 
>> on vnet33 device failed: No such device 
>> 2017-05-26T13:50:41.892Z|01277|stp|INFO|Dropped 14 log messages in 
>> last 373 seconds (most recently, 317 seconds ago) due to excessive 
>> rate
>> 2017-05-26T13:50:41.892Z|01278|stp|INFO|ovsbr1: detected topology change.
>> 2017-05-26T13:50:41.892Z|01279|stp|INFO|ovsbr1: detected topology change.
>> 2017-05-26T13:50:41.892Z|01280|stp|INFO|ovsbr1: detected topology change.
>> 2017-05-26T13:50:41.892Z|01281|stp|INFO|ovsbr1: detected topology change.
>> 2017-05-26T13:50:41.892Z|01282|stp|INFO|ovsbr1: detected topology change.
>> 
>> My messages log at the time of the shutdown:
>> 
>> May 26 09:59:46 rslcluster-node3 NetworkManager[1986]:   
>> (vnet33): enslaved to non-master-type device ovs-system; ignoring May 
>> 26 10:00:00 rslcluster-node3 journal: Received unexpected event 1 May 
>> 26 10:00:00 rslcluster-node3 kernel: [3174306.304707] device vnet33 
>> left promiscuous mode May 26 10:00:00 rslcluster-node3 kernel: device 
>> vnet33 left promiscuous mode May 26 10:00:01 rslcluster-node3 journal: 
>> internal error: End of file from monitor May 26 10:00:01 rslcluster-node3 
>> ovs-vsctl: ovs|1|vsctl|INFO|Called as ovs-vsctl --timeout=5 -- 
>> --if-exists del-port vnet33 May 26 10:00:01 rslcluster-node3 dbus[1954]: 
>> [system] Activating via systemd: service name='org.freedesktop.machine1' 
>> unit='dbus-org.freedesktop.machine1.service'
>> May 26 10:00:01 rslcluster-node3 dbus[1954]: [system] Successfully activated 
>> service 'org.freedesktop.machine1'
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-x.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: New machine qemu-.
>> May 26 10:00:01 rslcluster-node3 systemd-machined: N

Re: [ovs-discuss] Ping Drop Problem

[Justin Pettit]

Well, it's hard to know, since your description doesn't describe your topology, 
configuration, etc.  That said, I guess I would start with tcpdump or flow 
counts to see where packets appear to be getting dropped and why.

--Justin


> On May 25, 2017, at 6:03 PM, Gale Price <gpr...@lenovo.com> wrote:
> 
> Where would you suggest I start looking?
> 
> Sent from my iPhone
> 
>> On May 25, 2017, at 8:39 PM, Justin Pettit <jpet...@ovn.org> wrote:
>> 
>> 
>>> On May 25, 2017, at 11:11 AM, Gale Price <gpr...@lenovo.com> wrote:
>>> 
>>> I am using ovs on a Fedora 20 KVM Host with 6 defined vlans
>>> 
>>> I am having a problem where when I stop any VM I lose connectivity to all 
>>> other VM’s for about 6-7 Pings.
>>> Then everything starts working again.
>>> 
>>> Anyone see this or know a remedy for it?
>> 
>> That sounds odd.  I think you'll need to do a bit more debugging before 
>> anyone can help you.
>> 
>> --Justin
>> 
>> 

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Ping Drop Problem

[Justin Pettit]

> On May 25, 2017, at 11:11 AM, Gale Price  wrote:
> 
> I am using ovs on a Fedora 20 KVM Host with 6 defined vlans
>  
> I am having a problem where when I stop any VM I lose connectivity to all 
> other VM’s for about 6-7 Pings.
> Then everything starts working again.
>  
> Anyone see this or know a remedy for it?

That sounds odd.  I think you'll need to do a bit more debugging before anyone 
can help you.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK in OpenStack network node

[Justin Pettit]

> On May 25, 2017, at 2:08 PM, Пономарёв Вадим  wrote:
> 
> Hi all.
> 
> I am setting up a network node for the OpenStack cluster (mitaka) in the 
> classic scenario with OpenvSwitch 
> (https://docs.openstack.org/liberty/networking-guide/scenario-classic-ovs.html#openstack-services-network-node).
>  On the network node a neutron is launched. The neutron controls the OpenFlow 
> and creates separate namespaces for routers and dhcp servers. The basic 
> scheme with standard network card drivers and OVS kernel space datapath has a 
> low performance (300k pps with small packets). So now I'm trying to set up a 
> OVS-DPDK scheme. Test network node configuration:
> 
> ...
> Questions:
> 1. The reason for such packet loss is that the namespace of the router works 
> through kernel space and OVS copy packets?
> 2. Is there support for another type of interface that can be assigned to the 
> router in its namespace?
> 3. And the theoretical question: does such a scheme have a right to life? Or 
> are there better options for this task?

I'm not an expert on OpenStack, but I'll throw out a couple things, and others 
should feel free to jump in.  The "classic scenario" creates logical routers by 
using network namespaces in the kernel.  I suspect some of the slowdown you're 
seeing in both OVS-kernel may be from bouncing that traffic through those 
namespaces.  The speed benefits of OVS-DPDK comes from bypassing the kernel, 
but if you use the "classic scenario", those packets are probably making 
multiple trips to and from the kernel.

There could be other issues going on, but have you looked at OVN?  It programs 
OVS in such a way that logical routers don't go through namespaces, but instead 
writes very efficient OVS flows.  So the performance will likely be 
better--both with OVS-kernel and with OVS-DPDK.  OVN hasn't reach complete 
feature parity with the "classic scenario", but it's getting close.  If it has 
the features you need, you may get better performance with OVS-kernel and 
OVS-DPDK.

Hope that helps!

--Justin




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] about

[Justin Pettit]

> On Apr 18, 2017, at 6:59 PM, qintao (F)  wrote:
> 
>  
>  
> Dear all ,
>  we create a bridge “br1” with the type of netdev .And the version of the 
> ovs is 2.5.0. Then we run the command “ovs-vsctl set int br1 lldp:enable=true 
> “ to make the interface br1 enable the function lldp.After that ,we delete 
> the bridge br1 ,we found the the process “ovs-vswitchd” has been lost.
> ”

Thanks for the report.  There are a couple of releases in the 2.5.x series 
since 2.5.0.  Are you able to reproduce the same issue with 2.5.2?

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] MPLS issue in OVS

[Justin Pettit]

I know very little about the MPLS integration, but I have one thing that might 
be worth checking.  Are you using the OVS kernel module that came with OVS 
2.6.1 or the one that comes with Linux 4.2?  Linux 4.2 came out a year before 
OVS 2.6, and 2.6 introduced MPLS TTL.  It looks like the kernel datapath is 
rejecting the attempt to add that flow, so I'd make sure that you're using the 
kernel datapath that came with the OVS release.

--Justin


> On Apr 5, 2017, at 2:29 AM, f 62  wrote:
> 
> This is the log of ovs-vswitchd:
> 
> 2017-04-05T05:45:45.944Z|00205|dpif(handler14)|WARN|system@ovs-system: failed 
> to put[create] (Invalid argument) ufid:d62cd3db-17dd-488f-99bc-9da8b7e59c24 
> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(10),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd),eth_type(0x0800),ipv4(src=51.0.0.4,dst=51.0.0.13,proto=6,tos=0/0xfc,ttl=64,frag=no),tcp(src=48250,dst=80),tcp_flags(0/0),
>  
> actions:set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:48:cd:9e)),set(tunnel(tun_id=0x49,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),9,set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd)),pop_mpls(eth_type=0x800),push_mpls(label=510,tc=0,ttl=254,bos=1,eth_type=0x8847),9
> 2017-04-05T05:45:45.944Z|00206|dpif(handler14)|WARN|system@ovs-system: 
> execute 
> set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:48:cd:9e)),set(tunnel(tun_id=0x49,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),9,set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd)),pop_mpls(eth_type=0x800),push_mpls(label=510,tc=0,ttl=254,bos=1,eth_type=0x8847),9
>  failed (Invalid argument) on packet 
> tcp,vlan_tci=0x,dl_src=fa:16:3e:7f:19:13,dl_dst=fa:16:3e:78:13:cd,nw_src=51.0.0.4,nw_dst=51.0.0.13,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=48250,tp_dst=80,tcp_flags=syn
>  tcp_csum:91ac
>  mtu 0
> 2017-04-05T05:45:53.952Z|00207|dpif(handler14)|WARN|system@ovs-system: failed 
> to put[create] (Invalid argument) ufid:d62cd3db-17dd-488f-99bc-9da8b7e59c24 
> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(10),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd),eth_type(0x0800),ipv4(src=51.0.0.4,dst=51.0.0.13,proto=6,tos=0/0xfc,ttl=64,frag=no),tcp(src=48250,dst=80),tcp_flags(0/0),
>  
> actions:set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:48:cd:9e)),set(tunnel(tun_id=0x49,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),9,set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd)),pop_mpls(eth_type=0x800),push_mpls(label=510,tc=0,ttl=254,bos=1,eth_type=0x8847),9
> 2017-04-05T05:45:53.952Z|00208|dpif(handler14)|WARN|system@ovs-system: 
> execute 
> set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:48:cd:9e)),set(tunnel(tun_id=0x49,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),9,set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd)),pop_mpls(eth_type=0x800),push_mpls(label=510,tc=0,ttl=254,bos=1,eth_type=0x8847),9
>  failed (Invalid argument) on packet 
> tcp,vlan_tci=0x,dl_src=fa:16:3e:7f:19:13,dl_dst=fa:16:3e:78:13:cd,nw_src=51.0.0.4,nw_dst=51.0.0.13,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=48250,tp_dst=80,tcp_flags=syn
>  tcp_csum:89da
>  mtu 0
> 2017-04-05T05:46:09.984Z|00209|dpif(handler14)|WARN|system@ovs-system: failed 
> to put[create] (Invalid argument) ufid:d62cd3db-17dd-488f-99bc-9da8b7e59c24 
> recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(10),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd),eth_type(0x0800),ipv4(src=51.0.0.4,dst=51.0.0.13,proto=6,tos=0/0xfc,ttl=64,frag=no),tcp(src=48250,dst=80),tcp_flags(0/0),
>  
> actions:set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:48:cd:9e)),set(tunnel(tun_id=0x49,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),9,set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd)),pop_mpls(eth_type=0x800),push_mpls(label=510,tc=0,ttl=254,bos=1,eth_type=0x8847),9
> 2017-04-05T05:46:09.984Z|00210|dpif(handler14)|WARN|system@ovs-system: 
> execute 
> set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:48:cd:9e)),set(tunnel(tun_id=0x49,src=192.168.2.91,dst=192.168.2.177,ttl=64,flags(df|key))),push_mpls(label=511,tc=0,ttl=255,bos=1,eth_type=0x8847),9,set(eth(src=fa:16:3e:7f:19:13,dst=fa:16:3e:78:13:cd)),pop_mpls(eth_type=0x800),push_mpls(label=510,tc=0,ttl=254,bos=1,eth_type=0x8847),9
>  failed (Invalid argument) on packet 
> tcp,vlan_tci=0x,dl_src=fa:16:3e:7f:19:13,dl_dst=fa:16:3e:78:13:cd,nw_src=51.0.0.4,nw_dst=51.0.0.13,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=48250,tp_dst=80,tcp_flags=syn
>  tcp_csum:7a32
>  mtu 0
> 
> 
> 
> On Wed, Apr 5, 2017 at 10:28 AM, f 62  wrote:
> 

Re: [ovs-discuss] Centralizing OVS-DPDK Blogs

[Justin Pettit]

> On Mar 28, 2017, at 4:15 AM, Stokes, Ian  wrote:
> 
> Hi All,
> 
> There are a number of useful blogs maintained by Intel for OVS-DPDK. These 
> range from simple 'how-to' articles for specific feature to more technical 
> deep dives of how features work under the hood.
> 
> Currently these blogs are hosted on the Intel Developer Zone (and will 
> continue to be), but there have been suggestions that it could be useful to 
> expose them in a more central manner to OVS users.
> 
> This could include one or more of the following
> 
> 1. Expand existing OVS docs with blog content.
> 2. Adding the blogs to the OVS cookbook.
> 3. Creating a news feed for OVS using something like the Planet feed reader 
> for the OVS webpage. (http://www.planetplanet.org/)
> 
> This issue was raised at the OVS-DPDK community meeting and it was decided to 
> kick off a community discussion for more input before taking action.
> 
> Do people feel centralizing OVS-DPDK content to the OVS project would be 
> useful or is the status quo preferred?

Thanks for bringing this up.  For basic documentation, I think it makes sense 
to expand the existing docs where appropriate.

We've talked about adding some cookbook-like documentation for OVN.  It would 
be nice to use the same mechanism for both.  In the past, we've hosted 
cookbooks on the main OVS website, but they weren't regularly updated, and sort 
of fell into disrepair.  A good path forward might be to introduce them into 
the OVS repo, since they're now displayed nicely through Read the Docs 
(https://readthedocs.org).

I'd be curious to get others' opinions--especially Ben and Stephen since they 
were so involved in the last documentation overhaul.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] VM-VM-VM communication via OVS

[Justin Pettit]

> On Mar 28, 2017, at 3:48 AM, Advith Nagappa  wrote:
> 
> Hello All,
> 
> Is it possible to link 2 guest VMS, via another guest VM using OVS bridge?
> 
> Is anyone aware of any resource/doc covering this scenario?

I don't understand the deployment scenario that you're describing.  However, 
OVS can connect VMs in arbitrary topologies.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Kernel vs User mode switch

[Justin Pettit]

> On Mar 26, 2017, at 5:33 PM, Michael Williams  wrote:
> 
> What are the advantages of running the kernel verses  the user mode switch?

I assume you're specifically asking about running DPDK in userspace.  There are 
certain traffic patterns that can be significantly faster by bypassing the 
kernel and handling directly in userspace.  But, by bypassing the kernel, you 
miss out on the functionality provided by the kernel, so those must be 
recreated.  Some examples include:

- QoS
- Connection tracking (for firewalls) and NAT
- An IP stack (for tunnel termination)
- Some NIC offloads

Those features are being added, but not all of them are complete yet, so if you 
need a particular functionality, you may need to check whether it has all the 
features you need.

In the case of DPDK, there can be restrictions on the CPUs and NICs that are 
supported.  Also, for optimal performance, DPDK typically uses dedicated cores, 
but there's options to run in an interrupt-driven model.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] nd_target match intermittently not hitting

[Justin Pettit]

> On Mar 22, 2017, at 2:54 PM, Michael Ben-Ami via discuss 
>  wrote:
> 
> We have a flow that looks like this:
> 
> priority=1030,icmp6,in_port=4,icmp_type=135,nd_target=::1:d0::1105:3000/124
>  actions=resubmit(,25)
> 
> When neighbor solicitations come in on port 4 (ethernet interface), we can 
> see them in tcpdump as having the correct nd_target, yet the flow's n_byte, 
> and n_packet counters don't increase, and we confirm the packet falls to a 
> lower priority matching flow (that drops). However, if we remove the 
> nd_target field from the match, the solicitation hits the flow as expected, 
> every time.
> 
> As another wrinkle, while receiving continuous neighbor solicitations, we 
> simply re-add the above flow in a loop, like "while true; do ovs-ofctl 
> add-flow...; done". And without fail, the flow will suddenly instantly be hit 
> (n_byte and n_packet counters increase, VM actually receives solicitation), 
> with no change at all on what's been coming in on the data plane, and no 
> change to the content of the flow set as a whole.

Strange.  You might try running "ovs-dpctl dump-flows" in a loop and see if an 
appropriate flow is being pushed to the kernel datapath and getting hit.  The 
behavior you've described makes me wonder if re-adding the flow is causing the 
packet to execute in userspace, which is properly handling the packet, and then 
a kernel flow is pushed down that no longer works.

> For a similar wrinkle, we can also make the flow hit by simply repeatedly 
> running tcpdump on the interface multiple times. Like if port 4 is eth1, 
> we'll just do "tcpdump -enni eth1" multiple times, and the solicitation will 
> be successfully received by VM, counters increase, etc.

That just sounds odd.  I can't imagine why that would matter.

> Any ideas on why this may be? It's seems like a race condition somewhere that 
> is relevant to matching on nd_target.
> 
> Other info:
> 
> # ovs-ofctl --version
> ovs-ofctl (Open vSwitch) 2.5.0

I haven't looked to see if this kind of issue has been addressed, but is there 
a reason you're not running something more recent?  The 2.5 series is now at 
2.5.2.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] how does tos/dscp mechanism work on ovs?

[Justin Pettit]

OVS doesn't automatically do anything with those fields itself.  If you want to 
do that, you can configure queues and then write flows that match on those 
fields and output to a particular queue.

--Justin


> On Mar 18, 2017, at 6:21 AM, Big Strong  wrote:
> 
> TOS/DSCP is used to set the priority of IP packets, OVS supports setting of 
> these fields. However, as TOS/DSCP are features of IP layer, I'm wondering if 
> OVS can deal with it? I mean the packets are outputted according to the 
> priority of their TOS/DSCP bits when there is congestion at the specified out 
> port.
> ___
> 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] How does OVS learns the remote MACs

[Justin Pettit]

> On Mar 16, 2017, at 11:49 PM, Chris Mantis  wrote:
> 
> Hello,
> 
> In case of VxLAN configuration on OVS, how does it learn the remote MACs? 
> 
> The local macs are typically learned when a data packet is sent out over an 
> interface, How does it learn the remote MAC?

OVS supports VxLAN as a tunnel encapsulation, but doesn't natively support the 
control path.  I don't think it would be that difficult to write flows that 
implement the control path in OVS, though.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Ip grouping in openflow rule

[Justin Pettit]

> On Feb 20, 2017, at 12:46 AM, Tugrul Erdogan  
> wrote:
> 
> Hi all,
> 
> I am working on Centos 7 with OVS. I have simple flow rules as stated below:
> 
> ovs-ofctl add-flow  ovs-brext  "ip, nw_dst=10.3.4.6, actions=drop"
> ovs-ofctl add-flow  ovs-brext  "ip, nw_dst=172.16.0.6, actions=drop"
> 
> I want to group the destinations IP addresses in a structure ( like
> netfilter:ipset ) so I can drop many of the IP addresses from
> different subnets with one flow rule. I have searched this type of
> structure in man page of ovs-ctl and ovs-ofctl but I could not find.
> 
> I want take your suggestions about IP grouping structure in flow rules.

As Ben mentioned, there's no such grouping mechanism using ovs-ofctl.  Those 
tools are stateless, and OVS would normally expect that sort of state to be 
maintained by a controller.  There is support for such groups in OVN (which 
acts as a controller), but that might be overkill for your application if you 
don't need full-blown network virtualization.

I have thought about how using just the southbound components of OVN could make 
a more convenient method of programming OVS.  I should do a talk around that at 
some point, because I think the OVN logical flows are better in a lot of ways 
than straight OpenFlow.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] License of the OvS logo

[Justin Pettit]

Thanks for doing that, David.  I can't help with German, but the English 
Wikipedia article on Open vSwitch could use some updating.  If you wanted to do 
any editing on that, I'd be happy to lend a hand.  I just don't have any 
experience working on Wikipedia.

--Justin


> On Feb 5, 2017, at 2:40 AM, David Rabel  wrote:
> 
> Hi together,
> 
> I hope I am at the right place for my question. If not, please let me know.
> 
> I want to write a Wikipedia article about Open vSwitch for the German
> Wikipedia. And of course I would like to include the official logo. But
> this is only possible if the logo is released under an appropriate license.
> 
> So my question is: What is the license of the official OvS logo?
> 
> Regards,
>  David
> 
> ___
> 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] VXLAN support in OVS 2.5.0

[Justin Pettit]

Assuming that you're running on Linux, you could try setting up network 
namespaces. 

--Justin


> On Jan 12, 2017, at 6:36 PM, Raymond Burkholder  wrote:
> 
> Try running VirtualBox, and build two guests with shared networking.   That 
> will get you an appropriate simulation of computer to computer vxlan 
> mechanisms.
>  
> From: ovs-discuss-boun...@openvswitch.org 
> [mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Shravan S K
> Sent: Thursday, January 12, 2017 22:34
> To: Scott Lowe 
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] VXLAN support in OVS 2.5.0
>  
> Because of lack of hardware, I'm trying a vxlan setup on a single computer.
> 
> On 13-Jan-2017 04:47, "Scott Lowe"  wrote:
> Please don't drop the list.
> 
> Before we go down that path, can you help me understand what you're
> trying to achieve by building a VXLAN tunnel between two VMs on the same
> host?
> 
> 
> 
> On 01/12/2017 10:15 AM, Shravan S K wrote:
> > I am not sure how to do the config for what you said.
> > Can you please explain how to configure the setup that you're suggesting ?
> >
> > Shravan
> >
> > On 12 January 2017 at 02:17, Scott Lowe  > > wrote:
> >
> > On 01/11/2017 03:54 AM, Shravan S K wrote:
> > > Like this?
> > > vm01---|
> > > |--vm03
> > >
> > > 
> > br1(vxlanport1)br-int1=br-int2--(vxlanport2)br2
> > > vm02---|
> > > |---vm04
> > >
> > > What is the need for the bridges br-int1 and br-int2? Why is it not
> > > possible without them(as the topology shown earlier in this thread)?
> >
> >
> > [SL] No, I don't think this is the configuration you'd want to use. The
> > "br-int" bridges aren't strictly required; you could use br1 and br2.
> > The trick here---as you're trying to create a VXLAN tunnel within a
> > host---would be that you'll need 2 IP endpoints (one for each end of the
> > tunnel), and you'd need each bridge with a VXLAN port to be associated
> > with one of those IP endpoints.
> >
> > As I said, though, I haven't tested a configuration like this. Further,
> > to be honest, I'm not really sure what you're trying to accomplish with
> > such a configuration.
> >
> >
> > > Shravan
> > >
> > > On 11 January 2017 at 11:59, Scott Lowe  > 
> > > >> 
> > wrote:
> > >
> > > Please see my response inline, prefixed with [SL].
> > >
> > >
> > > On 01/10/2017 09:50 PM, Shravan S K wrote:
> > >> I am asking if that can be done on a single physical host having
> > >> OVS. Say, as mininet creates bridges which act as switches. Can
> > >> vxlan be setup using Mininet?
> > >
> > >
> > > [SL] I don't know if it's possible for Mininet to set up VXLAN;
> > > that's a question best asked on a Mininet-related forum.
> > >
> > > As for whether it can be done on a single host, I suppose if you were
> > > to use 2 separate bridges for physical connectivity along with 2
> > > separate bridges for the tunnels, it might work. I've never tried it,
> > > though, so this is just conjecture.
> > >
> > >
> > >> Shravan
> > >>
> > >> On 10 January 2017 at 23:33, Scott Lowe  > 
> > >
> > >>  >   >  > >>
> > >> Please see my response below.
> > >>
> > >>
> > >> On 01/10/2017 02:26 AM, Shravan S K wrote:
> > >>> Is it possible to create a VXLAN setup using just bridges created
> > >>> by OVS? (using ovs-vsctl to create these bridges,ports and vxlan
> > >>> config)
> > >>>
> > >>> vm01---| |--vm03
> > >>>   br1---br2
> > >>> vm02---| |---vm04
> > >>
> > >>
> > >> Yes, this is possible. On each hypervisor where OVS is running and
> > >> where you have VMs you'd like to connect over VXLAN tunnels, create
> > >> a bridge ("br-tun", for example). Create and configure a VXLAN port
> > >> appropriately on br-tun on each hypervisor, and then connect your
> > >> VMs. You should be good to go. My website has an example of doing
> > >> this with GRE; VXLAN should be nearly identical.
> > >>
> > >> Hope this helps,
> >
> >
> > --
> > Scott
> >
> >
> >
> 
> 
> -- 
> This message has been scanned for 

Re: [ovs-discuss] general question about synchronization in ovs

[Justin Pettit]

The code is pretty well documented.  I'd recommend looking through the code 
(e.g., lib/classifier.h) and looking for words like "thread" and "rcu".

--Justin


> On Dec 15, 2016, at 12:59 PM, Yuxin Ren <r...@gwmail.gwu.edu> wrote:
> 
> Yes,  I am learning the code now.
> But I do not know which code provide synchronization around the shared
> data structure.
> 
> Could you give me some guidance?
> 
> Thank you very much!
> Yuxin
> 
> On Thu, Dec 15, 2016 at 3:54 PM, Justin Pettit <jpet...@ovn.org> wrote:
>> 
>>> On Dec 15, 2016, at 7:54 AM, Yuxin Ren <r...@gwmail.gwu.edu> wrote:
>>> 
>>> Hi,
>>> 
>>> I am a beginner to OVS.
>>> I have some basic questions about OVS.
>>> 
>>> Is it a multiple threads application?
>>> If so, what data structures are shared by multiple threads?
>>> What synchronization technique is used to protect shared data structures?
>> 
>> Yes, it's multithreaded.  Have you tried looking at the code?
>> 
>> --Justin
>> 
>> 

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] general question about synchronization in ovs

[Justin Pettit]

> On Dec 15, 2016, at 7:54 AM, Yuxin Ren  wrote:
> 
> Hi,
> 
> I am a beginner to OVS.
> I have some basic questions about OVS.
> 
> Is it a multiple threads application?
> If so, what data structures are shared by multiple threads?
> What synchronization technique is used to protect shared data structures?

Yes, it's multithreaded.  Have you tried looking at the code?

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss