Re: [ovs-discuss] interface mac setting

[Ben Pfaff]

On Tue, Apr 24, 2018 at 10:55:36AM +0800, Tonghao Zhang wrote:
> One question, why now ovs can only set the mac of internal interface,
> for example:
> 
> ovs-vsctl set Interface p1 type=internal mac=\"00:11:22:33:44:55\"
> ovs-vsctl get Interface p1 mac_in_use
> 
> And the doc about 'mac' is not explained, why we cannot set it for
> other type interface. So it's a bug?

It's more like a bug in the documentation.  Please feel free to submit
an update.

The reasoning here is that the OVS database isn't a good place to set
things for which OVS is not the source of truth.  Suppose someone comes
along and runs "ifconfig" or "ip" to change the MAC address.  In that
case, the OVS database is then out-of-date.  Should OVS then immediately
set the MAC address back to what's in the database?  It's not good for
OVS to start fights like that.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Query regarding packet_in reason sent from OvS for “Table-miss” rule.

[Ben Pfaff]

On Tue, Apr 24, 2018 at 04:48:19AM +, Rohith Basavaraja wrote:
> Hi,
> 
> Currently in OvS if we hit "Table-miss" rules (associated with Controller 
> action) then we send
> PACKET_IN message to controller with reason as OFPR_NO_MATCH.
> 
> “Table-miss” rule is one whose priority is 0 and its catch all rule.
> 
> But if we hit same "Table-miss" rule after executing group entry we will send 
> the reason as
> OFPR_ACTION (for OF1.3 and below) and OFPR_GROUP (for OF1.4 and above).
> 
> This is because once we execute group entry we set ctx->in_group and later 
> when we hit the
> "Table-miss" rule, Since ctx->in_group  is set we send reason as OFPR_ACTION 
> (for OF1.3) and
> OFPR_GROUP (for OF1.4 and above).
> 
> Since in the packet_in message we are sending the table-id of the 
> corresponding “Table-miss” rule
> Shouldn’t we send the reason for packet-in as OFPR_NO_MATCH ( the reason 
> appropriate to the
> Corresponding rule?)
> 
> For eg: for the following pipeline we will send the reason as OFPR_ACTION 
> even if we hit
> The “Table-miss” rule.
> 
> cookie=0x800, duration=761.189s, table=0, n_packets=1401, n_bytes=67954, 
> priority=4,in_port=9,vlan_tci=0x/0x1fff 
> actions=write_metadata:0x678700/0xff01,goto_table:17
> 
> cookie=0x681, duration=768.848s, table=17, n_packets=1418, n_bytes=68776, 
> priority=10,metadata=0x678700/0xff00 
> actions=write_metadata:0xe0678700/0xfffe,goto_table:60
> 
> cookie=0x680, duration=24944.312s, table=60, n_packets=58244, 
> n_bytes=2519520, priority=0 actions=resubmit(,17)
> cookie=0x804, duration=785.733s, table=17, n_packets=1450, n_bytes=69724, 
> priority=10,metadata=0xe0678700/0xff00 
> actions=write_metadata:0x67871d4d00/0xfffe,goto_table:43
> 
> cookie=0x822002d, duration=24960.795s, table=43, n_packets=53097, 
> n_bytes=2230074, priority=100,arp,arp_op=1 actions=group:6000
> group_id=6000,type=all,bucket=actions=CONTROLLER:65535,bucket=actions=resubmit(,48),bucket=actions=resubmit(,81)
> 
> cookie=0x850, duration=24977.323s, table=48, n_packets=58309, 
> n_bytes=2522634, priority=0 actions=resubmit(,49),resubmit(,50)
> 
> cookie=0x805, duration=24984.679s, table=50, n_packets=6, n_bytes=264, 
> priority=0 
> actions=CONTROLLER:65535,learn(table=49,hard_timeout=10,priority=0,cookie=0x860,NXM_OF_ETH_SRC[],load:0x1->NXM_NX_REG4[0..7]),goto_table:51
> (Note that Table50 entry is a “Table-miss” rule).
> 
> Currently we are sending table_id as 50 and packet_in reason as OFPR_ACTION.
> Shouldn’t we send packet_in reason as OFPR_NO_MATCH in this case?

This seems like a reasonable argument.  Would you mind submitting a
patch (and including a test)?

Thanks,

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

Re: [ovs-discuss] Can I add a manual bonded interface as a ovs port ?

[Ben Pfaff]

On Fri, Apr 27, 2018 at 11:44:46AM +0800, netsurfed wrote:
> There is a "balance-alb" bond0 in my linux host, like this:
> 
> 
> Can I add this as a port to ovs bridge? like this:
> ovs-vsctl add-br ovsbr0
> ovs-vsctl add-port ovsbr0 bond0
> 
> 
> I know ovs can create bond using "ovs-vsctl add-bond BRIDGE PORT IFACE...". 
> However, that requires removing the original bond first. I don't want to do 
> that.

Usually it works fine to add a Linux bond to an OVS bridge.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS VXLAN local_ip does not seem to function - Bug

[Ben Pfaff]

Greg, if you have a moment, would you mind taking a look at this
sometime?  I am curious why there would be a difference between GRE and
VXLAN here.

Marcus, 2.5.2 is pretty old, even within the 2.5.x branch.  I don't,
however, see a commit that obviously would fix it within that branch.
Still, if you have a chance, you might try the latest master, or 2.9.0,
to see if it behaves the same way.

Thanks,

Ben.

On Thu, Apr 26, 2018 at 01:17:44PM +, Padgett, Marcus wrote:
> I have an issue with OVS VXLAN and using the local_ip option for the 
> interface.  Some of the IP addresses have been changed in the email since I 
> don't know exactly who sees this.
> 
> What you did that make the problem appear.
> Using a server with two interfaces with two default routes, I want to build a 
> VXLAN tunnel over each link to a destination switch.  I am utilizing iptables 
> to mark and ip rules to re-direct the traffic for the second tunnel out the 
> correct interface.  I have built the VXLAN tunnel in OVS trying to use the 
> "local_ip" option.
> EXAMPLE:
> sudo ovs-vsctl add-port ovs-br1 tun1 -- set Interface tun1 type=vxlan 
> options:remote_ip=172.17.253.1 options:key=testflow2 
> options:local_ip=172.16.253.16
> 
> What you expected to happen.
> I expected the VXLAN tunnel to be sent using the specified source 
> IP address of 172.16.253.16 out the correct interface.
> 
> What actually happened.
> The VXLAN tunnel exits the correct interface based on my routing 
> rules, however was formed utilizing the other interface's IP address 
> (172.16.252.108).
> EXAMPLE:
> 08:24:42.779236 IP 172.16.252.108.57418 > 172.17.253.1.4789: VXLAN, flags [I] 
> (0x08), vni 0
> LLDP, length 79
> 08:24:42.779437 IP 172.16.252.108.34566 > 172.17.253.1.4789: VXLAN, flags [I] 
> (0x08), vni 0
> 02:eb:86:0d:38:74 (oui Unknown) > Broadcast, ethertype Unknown (0x8942), 
> length 93:
> 0x:  0207 0486 e5fb d3da 4204 0502  000e  B...
> 0x0010:  0602 0078 fe12 a423 0501 4f4e 4f53 2044  ...x...#..ONOS.D
> 0x0020:  6973 636f 7665 7279 fe17 a423 0502 6f66  iscovery...#..of
> 0x0030:  3a30 3030 3038 3665 3566 6264 3364 6134  :86e5fbd3da4
> 0x0040:  3208 0a75 6370 652d 7475 6e2d 3200 002..tun1..
> 
> The Open vSwitch version number (as output by ovs-vswitchd --version).
> ovs-vswitchd (Open vSwitch) 2.5.2
> Compiled Oct 17 2017 16:38:57
> 
> The kernel version on which Open vSwitch is running (from /proc/version) and 
> the distribution and version number of your OS (e.g. "Centos 5.0").
> Linux version 4.4.0-87-generic (buildd@lcy01-31) (gcc version 
> 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #110-Ubuntu SMP Tue Jul 18 
> 12:55:35 UTC 2017
> 
> The output of ovs-dpctl show.
> system@ovs-system:
> lookups: hit:191881 missed:5814 lost:0
> flows: 4
> masks: hit:471168 total:4 hit/pkt:2.38
> port 0: ovs-system (internal)
> port 1: ovs-br1 (internal)
> port 2: vxlan_sys_4789 (vxlan)
> port 3: ovs-lan (internal)
> port 4: k8s-br (internal)
> port 5: mirror-br (internal)
> port 6: ens6
> port 7: wan2 (internal)
> 
> Any other information that you think might be relevant.
> Everything works fine when building with GRE instead of VXLAN, all the same 
> routing and firewall rules.  The rules are not matching any protocol specific 
> parameters, just matching on destination IP address to mark the traffic.
> 
> Thank you,
> Marcus Padgett
> Sr Engineer - Service Architecture | Windstream
> marcus.padg...@windstream.com
> 
> This email message and any attachments are for the sole use of the intended 
> recipient(s). Any unauthorized review, use, disclosure or distribution is 
> prohibited. If you are not the intended recipient, please contact the sender 
> by reply email and destroy all copies of the original message and 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] Questions about modified ofproto.c

[Ben Pfaff]

Please don't drop the mailing list.

On Thu, Apr 26, 2018 at 12:12:58AM +0800, 林志仁 wrote:
> 2018-04-26 0:02 GMT+08:00 Ben Pfaff <b...@ovn.org>:
> 
> > On Mon, Apr 23, 2018 at 10:56:19PM +0800, 林志仁 wrote:
> > >  I modified ofproto.c   "handle_flow_stats_request"   function.  I added
> > a
> > > while loop to check the flow table every 2 seconds.
> > >
> > > I want to ask "handle_openflow_"  can handle other request, like packet -
> > > in?
> >
> > If you make handle_flow_stats_request() block, then nothing else will
> > get handled.
> >
> 
> If i want to  "handle_flow_stats_request"   function while loop to check
> the flow table every 2 seconds  and ovs also can handle other request
> Do you have any suggested modifications or directions?

I'd suggest having the controller submit a flow stats request every 2
seconds.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN vm on vlan network using geneve tunnel for external traffic

[Ben Pfaff]

On Fri, Apr 13, 2018 at 09:22:44PM -0400, Russell Bryant wrote:
> On Fri, Apr 13, 2018 at 9:01 PM, Russell Bryant <russ...@ovn.org> wrote:
> > On Fri, Apr 13, 2018 at 5:27 PM, Ben Pfaff <b...@ovn.org> wrote:
> >> On Wed, Apr 11, 2018 at 07:44:25PM +0530, Anil Venkata wrote:
> >>> vm created on a vlan tenant network is using geneve tunnel(between compute
> >>> and gateway nodes) to reach external network. Because of this, we need to
> >>> consider tunnelling overhead while assigning MTU for vlan network. Can we
> >>> improve OVN to avoid tunnelling in this case.
> >>
> >> When OVN tunnels packets, the tunnel metadata includes information on
> >> the logical network, logical input port, and logical output port.  The
> >> logical input port is only used for egress ACLs, so it could be omitted
> >> if egress ACLs are constrained not to match on the logical input port.
> >> The logical network and logical output port are still needed, though, so
> >> to encode that in a VLAN they would have to add up to 12 bits or less.
> >> That's pretty constraining.  Do you have some idea for how to do it?
> >
> > I don't think ACLs are a factor here because it's actually the logical
> > router pipeline forwarded the packet over a tunnel.  The only logical
> > switches involved are VLAN networks (a switch with a localnet port).
> >
> > The unexpected behavior here is that despite using all VLAN networks,
> > a Geneve tunnel is used when the packet is sent to the L3 gateway node
> > that's doing SNAT.  Note that the type of router configured here is
> > the hybrid-type, where routing is fully distributed in all cases
> > except when NAT is required, then it gets redirected to a central
> > point.  That redirect is what we're seeing here.
> >
> > I've thought of two ways out of this:
> >
> > 1) In this scenario, if you really don't want any tunneling in use,
> > configure a fully centralized router instead.  The downside is that
> > East-West routing will be centralized, as well.
> >
> > 2) Use two routers.  ls1 (VLAN) with all ports for VMs <-> distributed
> > east-west router <-> ls2 (VLAN) used just to interconnect the routers
> > <-> centralized router for SNAT.  The downside here is that you still
> > lose the ability to bind floating IPs directly to compute nodes like
> > today.
> >
> > 3) Figure out a way for OVN to do this redirect to the gateway host
> > over a VLAN network.  I suspect this isn't trivial and honestly
> > haven't spent the time to figure out what it would take, but this does
> > seem like the ideal behavior.
> >
> > --
> > Russell Bryant
> 
> After an internal conversation on this topic, I wrote the following
> doc to summarize what was observed and to capture ideas for next
> steps:
> 
> https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit?usp=sharing

I wonder whether this should be added to the OVN FAQ I starting writing
earlier today:
https://patchwork.ozlabs.org/patch/898868/
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Questions about creating new controller request and switching reply

[Ben Pfaff]

Please don't drop the mailing list.

OVS is multithreaded.  It does handle multiple requests at a time.

On Tue, Apr 17, 2018 at 02:45:43AM +0800, 林志仁 wrote:
> Thanks for your feedback. Yes, i want to create  flow entry statistics
> triggers.
> 
> In "ofproto.c", " ofproto set threads()" means that ovs can handle multiple
> requests at the same time?
> 
> 
> 
> 2018-04-17 2:16 GMT+08:00 Ben Pfaff <b...@ovn.org>:
> 
> > On Tue, Apr 17, 2018 at 01:53:15AM +0800, 林志仁 wrote:
> > > I want to create a request. When the switch receives this request, it
> > will
> > > continuously monitor the flow table until the flow table has an
> > exception.
> > > For example, one flow has a large number of packets count in few seconds,
> > > then switch will send reply to controller.
> >
> > OpenFlow 1.5 defines flow entry statistics triggers that might allow you
> > to get what you want.  Open vSwitch does not yet support statistics
> > triggers, but I am sure that we would accept a reasonable
> > implementation.
> >
> > > In the monitoring time, switch can also handle other controller request?,
> > > like flow status request or port status request
> >
> > That sounds like a quality of implementation issue.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS sends ARP request to the controller also broadcasts ARP request

[Ben Pfaff]

The way you describe the problem confuses me.  As I read your
description, when OVS processes an ICMP packet, it forwards an ARP
packet to the controller.  OVS processes one packet at a time in an
almost-stateless way, so this is not really possible: as OVS processing
an ICMP packet, it only chooses how to deal with that ICMP packet; it
cannot easily influence the processing of ARP packets.

On Sat, Apr 14, 2018 at 01:50:12PM -0400, Sh j wrote:
> Thank you very much for your helpful explanation.
> 
> 
> I have another question.
> 
> When a ping packet is generated from node1 to node3 (the mentioned
> topology), in the next step, OVS1 is supposed to check its own flow table
> to see if there are any flow rules for this ICMP(IP) packet, and since the
> default flow rules installed by the controller tells that send the packet
> to the controller, the next packet_in message should include ICMP message.
> 
> But instead of that OVS1 forwards ARP request in the packet_in message. I
> am confused about this part. When I trace the packet, the action is sending
> to the controller. But somehow OVS1 skips this ICMP messages and goes to
> the ARP.  I suppose sending ARP happens when nodes know they are in one-hop
> neighbors. But in this case, nodes do not know the flow rules (routing path
> and next hop) and have to send packet_in (ICMP) to the controller. I do not
> know why these ARP are generating.
> 
> I am using CORE emulator to emulate this network. So I think I should check
> the Linux Kernel.  Could you let me know if you have any suggestion about
> the configuration?
> 
> Thank you
> 
> On Tue, Apr 10, 2018 at 6:27 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > I think there's some confusion here.  OVS doesn't originate ARP
> > requests.  It only forwards ARP requests generated by some other
> > software, such as the Linux kernel.  If you don't want OVS to pass ARP
> > requests to the controller via packet_in, then you can either configure
> > the software that generates them not to do so, or you can configure OVS
> > (via the controller) to forward them without generating a packet_in.
> >
> > On Tue, Apr 10, 2018 at 05:54:36PM -0400, Sh j wrote:
> > > Thank you. I fixed the problem through the flow table installed by ONOS
> > and
> > > I do not see ARP broadcasts anymore.
> > >
> > >
> > >
> > >
> > > I have another question about packet_in messages to the controller.
> > Before
> > > that, I will explain about my topology. I asked related questions before
> > > but I still have a problem.
> > >
> > >
> > > Usually, in the topology, OVS connected to hosts and they help hosts to
> > > communicate with each other. I prefer not to have any host and all nodes
> > in
> > > my network acts as forwarding elements (running OVS) (especially in case
> > of
> > > wireless networks, it is easier to add mobility to nodes without hosts).
> > >
> > > After having this topology (OVS1--OVS2---OVS3), with the following
> > > configuration:
> > >
> > > OVS1(eth0) --- (eth0)OVS2
> > >
> > > ovs-vsctl add-br brx
> > > ovs-vsctl add-port brx ethx
> > > ip addr flush dev ethx
> > > ip addr add 10.0.0.x/16 dev brx
> > > ip link set brx up
> > >
> > >
> > > when 10.0.0.1 (br1) pings 10.0.0.2(br2), node1 sends a packet_in
> > > message(ICMP) to the controller(ONOS).
> > >
> > > But, when 10.0.0.1(br1) pings 10.0.0.3(br3), node1 sends a packet_in
> > > message(ARP) to the controller.
> > > While I do not except this ARP request to the controller. I am expecting
> > > ICMP message as a packet_in to the controller in the first place, after
> > > that based on the packet_out, node1 is supposed to send the ARP request
> > for
> > > the next hop. I do not know why OVS sends this ARP requests.
> > >
> > >  In this case, which part of the network needs to change? should I change
> > > the configuration of OVS and how?
> > >
> > > Thank you in advance
> > >
> > >
> > >
> > >
> > > On Tue, Apr 10, 2018 at 4:27 PM, Ben Pfaff <b...@ovn.org> wrote:
> > >
> > > > On Mon, Apr 09, 2018 at 01:09:37PM -0400, Sh j wrote:
> > > > > Hello,
> > > > >
> > > > > I have the following topology:
> > > > >
> > > > > host1 openvswitch1 openvswitch2host2
> > > > >
> > > > > and both openvswitches are connected to the ONOS controller.
> > > > >
> > > > > The problem is that when host1 ping host2, openvswitch1 sends the ARP
> > > > > request as a packet_in to the controller, Also, it broadcasts the ARP
> > > > > request so that openvswitch2 receives this broadcast.
> > > > >
> > > > > Do you have any suggestion how to avoid this ARP broadcast?
> > > >
> > > > I would guess that ONOS can control this behavior through the flow
> > > > table.
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Questions about creating new controller request and switching reply

[Ben Pfaff]

On Tue, Apr 17, 2018 at 01:53:15AM +0800, 林志仁 wrote:
> I want to create a request. When the switch receives this request, it will
> continuously monitor the flow table until the flow table has an exception.
> For example, one flow has a large number of packets count in few seconds,
> then switch will send reply to controller.

OpenFlow 1.5 defines flow entry statistics triggers that might allow you
to get what you want.  Open vSwitch does not yet support statistics
triggers, but I am sure that we would accept a reasonable
implementation.

> In the monitoring time, switch can also handle other controller request?,
> like flow status request or port status request

That sounds like a quality of implementation issue.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Questions about creating new controller request and switching reply

[Ben Pfaff]

On Sun, Apr 15, 2018 at 08:35:23PM +0800, 林志仁 wrote:
> I want to create a request. When the switch receives this request, it will
> continuously monitor the flow table until it has the behavior I set, 

What kind of behavior do you mean?

> and it will send a reply to the controller.
> 
> Would like to ask this monitoring time, switch can also accept other
> controller request?

I don't understand the question yet.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN vm on vlan network using geneve tunnel for external traffic

[Ben Pfaff]

On Wed, Apr 11, 2018 at 07:44:25PM +0530, Anil Venkata wrote:
> vm created on a vlan tenant network is using geneve tunnel(between compute
> and gateway nodes) to reach external network. Because of this, we need to
> consider tunnelling overhead while assigning MTU for vlan network. Can we
> improve OVN to avoid tunnelling in this case.

When OVN tunnels packets, the tunnel metadata includes information on
the logical network, logical input port, and logical output port.  The
logical input port is only used for egress ACLs, so it could be omitted
if egress ACLs are constrained not to match on the logical input port.
The logical network and logical output port are still needed, though, so
to encode that in a VLAN they would have to add up to 12 bits or less.
That's pretty constraining.  Do you have some idea for how to do it?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVN meetup at VMware, May 15

[Ben Pfaff]

In the OVN meeting this week, we discussed doing an in-person meetup of
OVN developers and other interested people on May 15.  I volunteered to
host at VMware.  I suggest 2pm to 4pm.

If you're interested in attending, please reply to me or to the thread.
If people want to attend remotely, we can conference them in, so please
also let me know if you'd like to attend that way.

We also need to schedule speakers or discussion,  If you'd like to speak
about something, or hear about something, or propose a topic, please
speak up.

Thanks,

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

Re: [ovs-discuss] [openvswitch 2.9.90] Unable to use literal in nested output of learn action

[Ben Pfaff]

On Wed, Apr 11, 2018 at 08:14:07PM -0400, Flavio Fernandes wrote:
> 
> 
> > On Apr 7, 2018, at 1:53 PM, Ben Pfaff <b...@ovn.org> wrote:
> > 
> > On Fri, Apr 06, 2018 at 04:18:31PM -0400, Flavio Fernandes wrote:
> >> Dear OVS Gurus:
> >> 
> >> I came across something simple and silly, which is making me think it is 
> >> actually a bug.
> >> 
> >> In a nutshell, I'm trying to use a literal with the action output nested 
> >> in a learn().
> >> If I use a fancier (and more common) notation:
> >> 
> >>   output:NXM_OF_IN_PORT[]
> >> 
> >> that works fine. However, if I try to use a literal such as:
> >> 
> >>   output:2
> >> 
> >> I get:
> >> 
> >>   ovs-ofctl: 2: unknown field `2'
> > 
> > The learn action simply can't do that.  (I think that the ovs-ofctl
> > manpage does not suggest that it can.)
> 
> 
> Yes, I should have read it more carefully. It was an incorrect assumption on 
> my part
> that the nested output action was the same as action outside learn. I am a 
> better
> educated now. ;) Thanks for that clarification, Ben.

Well, it's a reasonable question.  Maybe the manpage should be clearer
that the actions supported within learn are very limited.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-vswitchd high CPU when there is no load

[Ben Pfaff]

One of the OVS-DPDK maintainers will have to speak up about the flow
control messages.  I don't know.

Do you see log messages reporting high CPU usage?  That would ordinarily
be the case, if threads other than the PMD threads are using excessive
CPU.

"top" and other tools can show CPU usage by thread, and OVS gives its
threads helpful names.  Which threads are using high CPU?

On Sun, Apr 08, 2018 at 10:15:11AM +0300, michael me wrote:
> Hi Ben,
> 
> Thank you so much for your reply.
> here below are some of the log from ovs-vswitchd.
> 
> 2018-04-08T09:52:34.897Z|00333|dpdk|WARN|Failed to enable flow control on
> device 0
> 2018-04-08T09:52:34.897Z|00334|dpdk|WARN|Failed to enable flow control on
> device 1
> 2018-04-08T09:52:35.025Z|00335|dpdk|WARN|Failed to enable flow control on
> device 0
> 2018-04-08T09:52:35.025Z|00336|dpdk|WARN|Failed to enable flow control on
> device 1
> 2018-04-08T09:52:36.370Z|00337|rconn|INFO|br-int<->tcp:127.0.0.1:6633:
> connected
> 2018-04-08T09:52:36.370Z|00338|rconn|INFO|br-eth1<->tcp:127.0.0.1:6633:
> connected
> 2018-04-08T09:52:36.370Z|00339|rconn|INFO|br-eth2<->tcp:127.0.0.1:6633:
> connected
> 2018-04-08T09:52:37.102Z|00340|dpdk|WARN|Failed to enable flow control on
> device 0
> 2018-04-08T09:52:37.102Z|00341|dpdk|WARN|Failed to enable flow control on
> device 1
> 2018-04-08T09:52:37.225Z|00342|dpdk|WARN|Failed to enable flow control on
> device 0
> 2018-04-08T09:52:37.225Z|00343|dpdk|WARN|Failed to enable flow control on
> device 1
> 2018-04-08T09:52:37.298Z|00344|dpdk|WARN|Failed to enable flow control on
> device 0
> 2018-04-08T09:52:37.298Z|00345|dpdk|WARN|Failed to enable flow control on
> device 1
> 2018-04-08T09:52:37.426Z|00346|dpdk|WARN|Failed to enable flow control on
> device 0
> 2018-04-08T09:52:37.426Z|00347|dpdk|WARN|Failed to enable flow control on
> device 1
> 2018-04-08T09:52:47.041Z|00348|connmgr|INFO|br-int<->tcp:127.0.0.1:6633: 7
> flow_mods in the 7 s starting 10 s ago (7 adds)
> 2018-04-08T09:52:47.245Z|00349|connmgr|INFO|br-eth1<->tcp:127.0.0.1:6633: 3
> flow_mods in the 7 s starting 10 s ago (3 adds)
> 2018-04-08T09:52:47.444Z|00350|connmgr|INFO|br-eth2<->tcp:127.0.0.1:6633: 3
> flow_mods in the 7 s starting 10 s ago (3 adds)
> 
> is the  "Failed to enable flow control on device" related to my high CPU
> load?
> Just to be clear, i do get traffic through though performance is not great
> so it does make sense that there is an issue with the flow, though i don't
> know how to verify this.
> 
> Below are the flows that i could find:
> root@dpdkApt:/# ovs-ofctl dump-flows br-int
> NXST_FLOW reply (xid=0x4):
>  cookie=0xb6de486b197e713c, duration=640.295s, table=0, n_packets=0,
> n_bytes=0, idle_age=802, priority=3,in_port=3,vlan_tci=0x/0x1fff
> actions=mod_vlan_vid:2,NORMAL
>  cookie=0xb6de486b197e713c, duration=640.188s, table=0, n_packets=0,
> n_bytes=0, idle_age=801, priority=3,in_port=4,vlan_tci=0x/0x1fff
> actions=mod_vlan_vid:3,NORMAL
>  cookie=0xb6de486b197e713c, duration=647.450s, table=0, n_packets=0,
> n_bytes=0, idle_age=911, priority=2,in_port=3 actions=drop
>  cookie=0xb6de486b197e713c, duration=647.251s, table=0, n_packets=0,
> n_bytes=0, idle_age=910, priority=2,in_port=4 actions=drop
>  cookie=0xb6de486b197e713c, duration=647.670s, table=0, n_packets=947,
> n_bytes=39930, idle_age=0, priority=0 actions=NORMAL
>  cookie=0xb6de486b197e713c, duration=647.675s, table=23, n_packets=0,
> n_bytes=0, idle_age=911, priority=0 actions=drop
>  cookie=0xb6de486b197e713c, duration=647.667s, table=24, n_packets=0,
> n_bytes=0, idle_age=911, priority=0 actions=drop
> 
> root@dpdkApt:/# ovs-ofctl dump-flows br-eth1
> NXST_FLOW reply (xid=0x4):
>  cookie=0x990e120f393a065e, duration=645.802s, table=0, n_packets=4,
> n_bytes=198, idle_age=776, priority=4,in_port=1,dl_vlan=2
> actions=strip_vlan,NORMAL
>  cookie=0x990e120f393a065e, duration=652.940s, table=0, n_packets=950,
> n_bytes=40026, idle_age=0, priority=2,in_port=1 actions=drop
>  cookie=0x990e120f393a065e, duration=652.967s, table=0, n_packets=0,
> n_bytes=0, idle_age=916, priority=0 actions=NORMAL
> 
> root@dpdkApt:/# ovs-ofctl dump-flows br-eth2
> NXST_FLOW reply (xid=0x4):
>  cookie=0xb5b43b868c9fcb5f, duration=671.350s, table=0, n_packets=4,
> n_bytes=198, idle_age=800, priority=4,in_port=2,dl_vlan=3
> actions=strip_vlan,NORMAL
>  cookie=0xb5b43b868c9fcb5f, duration=678.397s, table=0, n_packets=977,
> n_bytes=41160, idle_age=2, priority=2,in_port=2 actions=drop
>  cookie=0xb5b43b868c9fcb5f, duration=678.424s, table=0, n_packets=0,
> n_bytes=0, idle_age=941, priority=0 actions=NORMAL
> 
> Do you see anything that is wrong with my setup?
> I would g

Re: [ovs-discuss] [openvswitch 2.9.0] run subsets of tests (to stop Travis timeouts)

[Ben Pfaff]

On Sun, Apr 08, 2018 at 12:56:40PM +0100, Stuart Cardall wrote:
> Hello,
> 
> Travis has a global timeout of 50 minutes per job & ovs takes just over
> 5 minutes to build + 52 minutes for unit tests:
> 
> https://github.com/alpinelinux/aports/pull/3928
> 
> Is there a way to run the tests in sections or perhaps run a smaller
> subset suitable for Travis ?

Usually our own build+check runs on travis finish in ~45 minutes or so.
Do you have an idea why they might run slower on Alpine?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS sends ARP request to the controller also broadcasts ARP request

[Ben Pfaff]

That's true, generally speaking, but ovs-ofctl might have a few missing
features.  If you find any omissions, please report them.

On Tue, Apr 10, 2018 at 10:39:32PM +, Michael Williams wrote:
> Can every command that OvS recognizes from a controller also be done via the 
> Linux command line?
> 
> 
> 
> -Original Message-
> From: ovs-discuss-boun...@openvswitch.org 
> <ovs-discuss-boun...@openvswitch.org> On Behalf Of Ben Pfaff
> Sent: Tuesday, April 10, 2018 18:28
> To: Sh j <segu...@gmail.com>
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] OVS sends ARP request to the controller also 
> broadcasts ARP request
> 
> I think there's some confusion here.  OVS doesn't originate ARP requests.  It 
> only forwards ARP requests generated by some other software, such as the 
> Linux kernel.  If you don't want OVS to pass ARP requests to the controller 
> via packet_in, then you can either configure the software that generates them 
> not to do so, or you can configure OVS (via the controller) to forward them 
> without generating a packet_in.
> 
> On Tue, Apr 10, 2018 at 05:54:36PM -0400, Sh j wrote:
> > Thank you. I fixed the problem through the flow table installed by 
> > ONOS and I do not see ARP broadcasts anymore.
> > 
> > 
> > 
> > 
> > I have another question about packet_in messages to the controller. 
> > Before that, I will explain about my topology. I asked related 
> > questions before but I still have a problem.
> > 
> > 
> > Usually, in the topology, OVS connected to hosts and they help hosts 
> > to communicate with each other. I prefer not to have any host and all 
> > nodes in my network acts as forwarding elements (running OVS) 
> > (especially in case of wireless networks, it is easier to add mobility to 
> > nodes without hosts).
> > 
> > After having this topology (OVS1--OVS2---OVS3), with the following
> > configuration:
> > 
> > OVS1(eth0) --- (eth0)OVS2
> > 
> > ovs-vsctl add-br brx
> > ovs-vsctl add-port brx ethx
> > ip addr flush dev ethx
> > ip addr add 10.0.0.x/16 dev brx
> > ip link set brx up
> > 
> > 
> > when 10.0.0.1 (br1) pings 10.0.0.2(br2), node1 sends a packet_in
> > message(ICMP) to the controller(ONOS).
> > 
> > But, when 10.0.0.1(br1) pings 10.0.0.3(br3), node1 sends a packet_in
> > message(ARP) to the controller.
> > While I do not except this ARP request to the controller. I am 
> > expecting ICMP message as a packet_in to the controller in the first 
> > place, after that based on the packet_out, node1 is supposed to send 
> > the ARP request for the next hop. I do not know why OVS sends this ARP 
> > requests.
> > 
> >  In this case, which part of the network needs to change? should I 
> > change the configuration of OVS and how?
> > 
> > Thank you in advance
> > 
> > 
> > 
> > 
> > On Tue, Apr 10, 2018 at 4:27 PM, Ben Pfaff <b...@ovn.org> wrote:
> > 
> > > On Mon, Apr 09, 2018 at 01:09:37PM -0400, Sh j wrote:
> > > > Hello,
> > > >
> > > > I have the following topology:
> > > >
> > > > host1 openvswitch1 openvswitch2host2
> > > >
> > > > and both openvswitches are connected to the ONOS controller.
> > > >
> > > > The problem is that when host1 ping host2, openvswitch1 sends the 
> > > > ARP request as a packet_in to the controller, Also, it broadcasts 
> > > > the ARP request so that openvswitch2 receives this broadcast.
> > > >
> > > > Do you have any suggestion how to avoid this ARP broadcast?
> > >
> > > I would guess that ONOS can control this behavior through the flow 
> > > table.
> > >
> ___
> 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] OVS sends ARP request to the controller also broadcasts ARP request

[Ben Pfaff]

I think there's some confusion here.  OVS doesn't originate ARP
requests.  It only forwards ARP requests generated by some other
software, such as the Linux kernel.  If you don't want OVS to pass ARP
requests to the controller via packet_in, then you can either configure
the software that generates them not to do so, or you can configure OVS
(via the controller) to forward them without generating a packet_in.

On Tue, Apr 10, 2018 at 05:54:36PM -0400, Sh j wrote:
> Thank you. I fixed the problem through the flow table installed by ONOS and
> I do not see ARP broadcasts anymore.
> 
> 
> 
> 
> I have another question about packet_in messages to the controller. Before
> that, I will explain about my topology. I asked related questions before
> but I still have a problem.
> 
> 
> Usually, in the topology, OVS connected to hosts and they help hosts to
> communicate with each other. I prefer not to have any host and all nodes in
> my network acts as forwarding elements (running OVS) (especially in case of
> wireless networks, it is easier to add mobility to nodes without hosts).
> 
> After having this topology (OVS1--OVS2---OVS3), with the following
> configuration:
> 
> OVS1(eth0) --- (eth0)OVS2
> 
> ovs-vsctl add-br brx
> ovs-vsctl add-port brx ethx
> ip addr flush dev ethx
> ip addr add 10.0.0.x/16 dev brx
> ip link set brx up
> 
> 
> when 10.0.0.1 (br1) pings 10.0.0.2(br2), node1 sends a packet_in
> message(ICMP) to the controller(ONOS).
> 
> But, when 10.0.0.1(br1) pings 10.0.0.3(br3), node1 sends a packet_in
> message(ARP) to the controller.
> While I do not except this ARP request to the controller. I am expecting
> ICMP message as a packet_in to the controller in the first place, after
> that based on the packet_out, node1 is supposed to send the ARP request for
> the next hop. I do not know why OVS sends this ARP requests.
> 
>  In this case, which part of the network needs to change? should I change
> the configuration of OVS and how?
> 
> Thank you in advance
> 
> 
> 
> 
> On Tue, Apr 10, 2018 at 4:27 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Mon, Apr 09, 2018 at 01:09:37PM -0400, Sh j wrote:
> > > Hello,
> > >
> > > I have the following topology:
> > >
> > > host1 openvswitch1 openvswitch2host2
> > >
> > > and both openvswitches are connected to the ONOS controller.
> > >
> > > The problem is that when host1 ping host2, openvswitch1 sends the ARP
> > > request as a packet_in to the controller, Also, it broadcasts the ARP
> > > request so that openvswitch2 receives this broadcast.
> > >
> > > Do you have any suggestion how to avoid this ARP broadcast?
> >
> > I would guess that ONOS can control this behavior through the flow
> > table.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS sends ARP request to the controller also broadcasts ARP request

[Ben Pfaff]

On Mon, Apr 09, 2018 at 01:09:37PM -0400, Sh j wrote:
> Hello,
> 
> I have the following topology:
> 
> host1 openvswitch1 openvswitch2host2
> 
> and both openvswitches are connected to the ONOS controller.
> 
> The problem is that when host1 ping host2, openvswitch1 sends the ARP
> request as a packet_in to the controller, Also, it broadcasts the ARP
> request so that openvswitch2 receives this broadcast.
> 
> Do you have any suggestion how to avoid this ARP broadcast?

I would guess that ONOS can control this behavior through the flow
table.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Ben Pfaff]

On Sun, Apr 08, 2018 at 04:34:16PM +, Vishal Deep Ajmera wrote:
> Hi,
> 
> We are trying to setup Neighbor Solicitation Responder using OpenFlow 
> pipeline in OVS however it seems some of the fields in Neighbor Advertisement 
> Message Format cannot be set using OpenFlow set actions. Following is the 
> frame format of NA message:
> 
> 0   1   2   3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Type  | Code  |  Checksum |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |R|S|O| Reserved|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   |
>   +   +
>   |   |
>   +   Target Address  +
>   |   |
>   +   +
>   |   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Options ...
>   +-+-+-+-+-+-+-+-+-+-+-+-
> 
> 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.

> Also, is there a way to recalculate the checksum and write it to
> checksum field when we set the Target Address?

Whenever OVS changes any field, it updates the associated checksum.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.9.90] Unable to use literal in nested output of learn action

[Ben Pfaff]

On Fri, Apr 06, 2018 at 04:18:31PM -0400, Flavio Fernandes wrote:
> Dear OVS Gurus:
> 
> I came across something simple and silly, which is making me think it is 
> actually a bug.
> 
> In a nutshell, I'm trying to use a literal with the action output nested in a 
> learn().
> If I use a fancier (and more common) notation:
> 
>output:NXM_OF_IN_PORT[]
> 
> that works fine. However, if I try to use a literal such as:
> 
>output:2
> 
> I get:
> 
>ovs-ofctl: 2: unknown field `2'

The learn action simply can't do that.  (I think that the ovs-ofctl
manpage does not suggest that it can.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.9.90] Unable to use literal in nested output of learn action

[Ben Pfaff]

The binary encoding of the "learn" action just doesn't support an
"output to immediate" action, so some kind of different approach is
needed.

On Fri, Apr 06, 2018 at 05:57:14PM -0400, Flavio Fernandes wrote:
> 
> Heh, after sending that msg, I did a little digging in the code [1] and doc 
> and it seems clear that
> integer literals are just not supported as a value for the output action name.
> 
> I imagine that in order to handle that, that code section would need to be 
> extended to perform
> a "parse_int_string(value,...)" and etc.
> 
> All in all, I convinced myself that this is a FAD. One can easily load a 
> literal
> integer into a REG and use that as output [2] anyways. So, that is plenty 
> good.
> 
> Thanks and sorry for the noise,
> 
> -- flaviof
> 
> 
> [1]: 
> https://github.com/openvswitch/ovs/blob/a045e4b03d7603572ae0d503762c52dc40bf6f23/lib/learn.c#L371
> 
> [2]: load:0x1->NXM_NX_REG1[] ... output:NXM_NX_REG1[]
> 
> 
> 
> > On Apr 6, 2018, at 4:18 PM, Flavio Fernandes  wrote:
> > 
> > Dear OVS Gurus:
> > 
> > I came across something simple and silly, which is making me think it is 
> > actually a bug.
> > 
> > In a nutshell, I'm trying to use a literal with the action output nested in 
> > a learn().
> > If I use a fancier (and more common) notation:
> > 
> >   output:NXM_OF_IN_PORT[]
> > 
> > that works fine. However, if I try to use a literal such as:
> > 
> >   output:2
> > 
> > I get:
> > 
> >   ovs-ofctl: 2: unknown field `2'
> > 
> > 
> > Here is a set of steps I use from a sandbox session:
> > 
> >   $ ./boot.sh ; ./configure ; make -j4 ; \
> > make sandbox
> > 
> >   $ ovs-vsctl add-br br0 \
> > -- add-port br0 p1 -- set interface p1 ofport_request=1 \
> > -- add-port br0 p2 -- set interface p2 ofport_request=2 \
> > -- set Bridge br0 fail-mode=secure
> > 
> >   # this works just fine
> >   $ ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, 
> > hard_timeout=600, \
> > in_port=1, \
> > NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
> > output:NXM_OF_IN_PORT[]), \
> > resubmit(,1)"
> > 
> >   $ ovs-ofctl add-flow br0 "table=1 priority=0 actions=flood"
> > 
> >   $ ovs-ofctl -OOpenFlow13 --names --no-stat dump-flows br0
> > reset_counts 
> > actions=learn(table=1,hard_timeout=600,in_port=p1,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],output:NXM_OF_IN_PORT[]),resubmit(,1)
> > table=1, reset_counts priority=0 actions=FLOOD
> > 
> >   # very similar to the learn action done above, except I'm attempting to 
> > hard code an output value
> >   $ ovs-ofctl add-flow br0 "table=0 actions=learn(table=1, 
> > hard_timeout=600, \
> > in_port=2, \
> > NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \
> > output:2), \
> > resubmit(,1)"
> >   ovs-ofctl: 2: unknown field `2'
> > 
> >   $ echo $?
> >   1
> > 
> > I also played a little bit with the parser test to reproduce this behavior. 
> > See below.
> > 
> > So... bug or FAD? If you think BUG, I can dig a little more to learn what 
> > is going on.
> > It has been a while, so chances are that most of you will have this fixed 
> > before I manage
> > to blink. :)
> > 
> > Best,
> > 
> > -- flaviof
> > 
> > 
> > 
> > 
> > $ make check TESTSUITEFLAGS=--list 2>/dev/null | grep -m1 -i learn
> > 454: learn.at:3 learning action - parsing and formatting
> > 
> > 
> > $ git diff
> > diff --git a/tests/learn.at b/tests/learn.at
> > index 5f1d6df..eaf1147 100644
> > --- a/tests/learn.at
> > +++ b/tests/learn.at
> > @@ -7,6 +7,7 @@ actions=learn(send_flow_rem)
> > actions=learn(delete_learned)
> > actions=learn(send_flow_rem,delete_learned)
> > actions=learn(NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], 
> > output:NXM_OF_IN_PORT[], load:10->NXM_NX_REG0[5..10])
> > +actions=learn(NXM_OF_VLAN_TCI[0..11], NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], 
> > output:99)
> > actions=learn(table=1,idle_timeout=10, hard_timeout=20, fin_idle_timeout=5, 
> > fin_hard_timeout=10, priority=10, cookie=0xfedcba9876543210, 
> > in_port=99,eth_dst=eth_src,load:in_port->reg1[16..31])
> > actions=learn(limit=4096)
> > actions=learn(limit=4096,result_dst=reg0[0])
> > 
> > 
> > $ make check TESTSUITEFLAGS='454'
> > ...
> > 454: learning action - parsing and formattingFAILED (learn.at:15)
> 



> ___
> 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] OVS 2.9.0: priority=0 actions=CONTROLLER flow counts but doesn't output packets to the controller

[Ben Pfaff]

On Tue, Mar 06, 2018 at 11:20:40AM -0800, Ben Pfaff wrote:
> On Tue, Mar 06, 2018 at 06:54:30AM +, Josh Bailey via discuss wrote:
> > Hoping I'm missing something obvious!
> > 
> > I have a flow like this:
> > 
> > $ grep CONTROLLER sab-dump-flows.log
> >  cookie=0x5adc15c0, duration=63.446s, table=3, n_packets=60, n_bytes=3436,
> > priority=0 actions=CONTROLLER:96
> > 
> > I can cause packets to match it, but no packets are output ot the
> > controller.
> > 
> > faucet@faucet:/var/tmp/faucet-tests-1KL3eg/FaucetUntaggedTestZeroPriorityFlowsTest-test_untagged$
> > tshark -l -n -Q -d tcp.port==40649,openflow -O openflow_v4 -Y
> > "openflow_v4.packet_in.total_len>0" -r fa*cap|wc -l
> > 0
> > 
> > If I specify any priority other than 0, it works (packets are output to
> > controller via packet in messages).
> > 
> > Is there something special about priority=0 flows and the CONTROLLER action?
> 
> Yes, in fact OpenFlow specifies special cases for priority=0 flows that
> match no fields.  It calls these "table-miss" flows, see e.g. section
> 5.4 in OpenFlow 1.5.1.  Open vSwitch has some explicit special-case code
> for dealing with them.
> 
> I can't think of a particular reason why this special case would make a
> difference for you.  Maybe there is a bug.  Do you have a way for us to
> reproduce it?
> 
> Did you try "ofproto/trace"?  Maybe it will show a reason why the packet
> is not sent to the controller.
> 
> (I'm at a conference this week, so my schedule is weird.)

I wonder whether you figured out anything here and whether you have any
more of a bug report for us.  Happy to help, if so.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Is there an option to disable metadata propagation on patch ports?

[Ben Pfaff]

Yes.

On Fri, Apr 06, 2018 at 12:49:21PM +0200, Alan Kayahan wrote:
> Thanks Ben. So then the flow struct, along with its members excluding
> metadata, tunnel and regs propagate, correct?
> 
> 
> 2018-04-05 21:30 GMT+02:00 Ben Pfaff <b...@ovn.org>:
> 
> > compose_output_action__(), in ofproto/ofproto-dpif-xlate.c, clears
> > metadata for patch port traversals in the block that begins "if
> > (xport->peer)", with this code:
> >
> > flow->metadata = htonll(0);
> > memset(>tunnel, 0, sizeof flow->tunnel);
> > memset(flow->regs, 0, sizeof flow->regs);
> >
> >
> > On Thu, Apr 05, 2018 at 08:52:31PM +0200, Alan Kayahan wrote:
> > > Thatis my question and theory :) How can I see that? Can you point me
> > > to the code where such decision is taken?
> > >
> > > 2018-04-05 20:39 GMT+02:00 Ben Pfaff <b...@ovn.org>:
> > >
> > > > What metadata is propagating?
> > > >
> > > > On Thu, Apr 05, 2018 at 08:14:51PM +0200, Alan Kayahan wrote:
> > > > > I introduced a new 32bit field in flow.h to match on. A push_header
> > > > action
> > > > > appends a header, which contains TLVs, to the packet and sets this
> > field
> > > > > for the first time. An increment action sets this field to a value
> > that
> > > > > resides in the first TLV, if increment action is called again, the
> > field
> > > > is
> > > > > set to the value in the second TLV and so on.
> > > > >
> > > > > I have a chain of br0-br1-br2 connected via patch ports. In br0 flow
> > rule
> > > > > calls push_header and out to br1. In br1, the flow rule matches on
> > the
> > > > port
> > > > > connected to br0, plus match on the 32bit field.The action for this
> > rule
> > > > is
> > > > > increment, then out to br2. Just like br1, br2 matches on the port
> > from
> > > > br1
> > > > > plus the match on the 32bit field for the value in the TLV.
> > > > >
> > > > > Everything works well until br2. But the match on the field for the
> > value
> > > > > in the TLV doesn't work. If I remove the match on the field at br2
> > and
> > > > just
> > > > > use in_port and redirect the traffic to packet hex printer, I do see
> > that
> > > > > the value in the TLV has been set correctly at the offset of this
> > 32bit
> > > > > field.
> > > > >
> > > > > The increment action depends on the iteration of TLVs in the header
> > at
> > > > each
> > > > > packet, therefore is at datapath and can not update the flow
> > context. So
> > > > if
> > > > > the flow metadata is propagating (which seems to be the only
> > > > explanation),
> > > > > the new field is set to the old value, which is the culprit. Perhaps
> > a
> > > > > better approach is to create an own context just like nat, iterate
> > the
> > > > TLVs
> > > > > and populate the context with all available values when push_header
> > is
> > > > > first called, then redesign the increment action so that it just
> > pops the
> > > > > next value from the context and emits the data-plane action.
> > Eliminates
> > > > > TLVs iteration per packet at the dataplane.
> > > > >
> > > > > But just to save the day, do you have a trick to stop this
> > propagation?
> > > > Or
> > > > > do you think the problem might be something else?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > 2018-04-05 19:41 GMT+02:00 Ben Pfaff <b...@ovn.org>:
> > > > >
> > > > > > On Thu, Apr 05, 2018 at 07:31:35PM +0200, Alan Kayahan wrote:
> > > > > > > OVS patch ports allow the propagation of the metadata (e.g. flow
> > > > context)
> > > > > > > across the connected switches.
> > > > > > >
> > > > > > > Is there an option to disable the metadata propagation feature? I
> > > > need
> > > > > > this
> > > > > > > for my research to benchmark certain behavior. Or patch ports
> > become
> > > > > > > nothing but veth pairs when this feature is disabled?
> > > > > >
> > > > > > Patch ports zero out most metadata.  What additional metadata do
> > you
> > > > > > want them to clear?
> > > > > >
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Is there an option to disable metadata propagation on patch ports?

[Ben Pfaff]

compose_output_action__(), in ofproto/ofproto-dpif-xlate.c, clears
metadata for patch port traversals in the block that begins "if
(xport->peer)", with this code:

flow->metadata = htonll(0);
memset(>tunnel, 0, sizeof flow->tunnel);
memset(flow->regs, 0, sizeof flow->regs);


On Thu, Apr 05, 2018 at 08:52:31PM +0200, Alan Kayahan wrote:
> Thatis my question and theory :) How can I see that? Can you point me
> to the code where such decision is taken?
> 
> 2018-04-05 20:39 GMT+02:00 Ben Pfaff <b...@ovn.org>:
> 
> > What metadata is propagating?
> >
> > On Thu, Apr 05, 2018 at 08:14:51PM +0200, Alan Kayahan wrote:
> > > I introduced a new 32bit field in flow.h to match on. A push_header
> > action
> > > appends a header, which contains TLVs, to the packet and sets this field
> > > for the first time. An increment action sets this field to a value that
> > > resides in the first TLV, if increment action is called again, the field
> > is
> > > set to the value in the second TLV and so on.
> > >
> > > I have a chain of br0-br1-br2 connected via patch ports. In br0 flow rule
> > > calls push_header and out to br1. In br1, the flow rule matches on the
> > port
> > > connected to br0, plus match on the 32bit field.The action for this rule
> > is
> > > increment, then out to br2. Just like br1, br2 matches on the port from
> > br1
> > > plus the match on the 32bit field for the value in the TLV.
> > >
> > > Everything works well until br2. But the match on the field for the value
> > > in the TLV doesn't work. If I remove the match on the field at br2 and
> > just
> > > use in_port and redirect the traffic to packet hex printer, I do see that
> > > the value in the TLV has been set correctly at the offset of this 32bit
> > > field.
> > >
> > > The increment action depends on the iteration of TLVs in the header at
> > each
> > > packet, therefore is at datapath and can not update the flow context. So
> > if
> > > the flow metadata is propagating (which seems to be the only
> > explanation),
> > > the new field is set to the old value, which is the culprit. Perhaps a
> > > better approach is to create an own context just like nat, iterate the
> > TLVs
> > > and populate the context with all available values when push_header is
> > > first called, then redesign the increment action so that it just pops the
> > > next value from the context and emits the data-plane action. Eliminates
> > > TLVs iteration per packet at the dataplane.
> > >
> > > But just to save the day, do you have a trick to stop this propagation?
> > Or
> > > do you think the problem might be something else?
> > >
> > > Thanks!
> > >
> > > 2018-04-05 19:41 GMT+02:00 Ben Pfaff <b...@ovn.org>:
> > >
> > > > On Thu, Apr 05, 2018 at 07:31:35PM +0200, Alan Kayahan wrote:
> > > > > OVS patch ports allow the propagation of the metadata (e.g. flow
> > context)
> > > > > across the connected switches.
> > > > >
> > > > > Is there an option to disable the metadata propagation feature? I
> > need
> > > > this
> > > > > for my research to benchmark certain behavior. Or patch ports become
> > > > > nothing but veth pairs when this feature is disabled?
> > > >
> > > > Patch ports zero out most metadata.  What additional metadata do you
> > > > want them to clear?
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Is there an option to disable metadata propagation on patch ports?

[Ben Pfaff]

What metadata is propagating?

On Thu, Apr 05, 2018 at 08:14:51PM +0200, Alan Kayahan wrote:
> I introduced a new 32bit field in flow.h to match on. A push_header action
> appends a header, which contains TLVs, to the packet and sets this field
> for the first time. An increment action sets this field to a value that
> resides in the first TLV, if increment action is called again, the field is
> set to the value in the second TLV and so on.
> 
> I have a chain of br0-br1-br2 connected via patch ports. In br0 flow rule
> calls push_header and out to br1. In br1, the flow rule matches on the port
> connected to br0, plus match on the 32bit field.The action for this rule is
> increment, then out to br2. Just like br1, br2 matches on the port from br1
> plus the match on the 32bit field for the value in the TLV.
> 
> Everything works well until br2. But the match on the field for the value
> in the TLV doesn't work. If I remove the match on the field at br2 and just
> use in_port and redirect the traffic to packet hex printer, I do see that
> the value in the TLV has been set correctly at the offset of this 32bit
> field.
> 
> The increment action depends on the iteration of TLVs in the header at each
> packet, therefore is at datapath and can not update the flow context. So if
> the flow metadata is propagating (which seems to be the only explanation),
> the new field is set to the old value, which is the culprit. Perhaps a
> better approach is to create an own context just like nat, iterate the TLVs
> and populate the context with all available values when push_header is
> first called, then redesign the increment action so that it just pops the
> next value from the context and emits the data-plane action. Eliminates
> TLVs iteration per packet at the dataplane.
> 
> But just to save the day, do you have a trick to stop this propagation? Or
> do you think the problem might be something else?
> 
> Thanks!
> 
> 2018-04-05 19:41 GMT+02:00 Ben Pfaff <b...@ovn.org>:
> 
> > On Thu, Apr 05, 2018 at 07:31:35PM +0200, Alan Kayahan wrote:
> > > OVS patch ports allow the propagation of the metadata (e.g. flow context)
> > > across the connected switches.
> > >
> > > Is there an option to disable the metadata propagation feature? I need
> > this
> > > for my research to benchmark certain behavior. Or patch ports become
> > > nothing but veth pairs when this feature is disabled?
> >
> > Patch ports zero out most metadata.  What additional metadata do you
> > want them to clear?
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Is there an option to disable metadata propagation on patch ports?

[Ben Pfaff]

On Thu, Apr 05, 2018 at 07:31:35PM +0200, Alan Kayahan wrote:
> OVS patch ports allow the propagation of the metadata (e.g. flow context)
> across the connected switches.
> 
> Is there an option to disable the metadata propagation feature? I need this
> for my research to benchmark certain behavior. Or patch ports become
> nothing but veth pairs when this feature is disabled?

Patch ports zero out most metadata.  What additional metadata do you
want them to clear?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] raft ovsdb clustering

[Ben Pfaff]

Oh, I see, from reading further in the thread, that this was indeed a
misunderstanding.  Well, in any case that new option to ovs-sandbox can
be useful.

On Wed, Apr 04, 2018 at 04:00:20PM -0700, Ben Pfaff wrote:
> I would like to support cluster-wide locks.  They require extra work and
> they require new OVSDB JSON-RPC protocol design (because locks are
> currently per-server, not per-database).  I do not currently have a
> schedule for designing and implementing them.
> 
> However, I am surprised that this is an issue for northd.  For a
> clustered database, ovn-northd always connects to the cluster leader.
> There is at most one leader in the cluster at a given time, so as long
> as ovn-northd obtains a lock on the leader, this should ensure that only
> one ovn-northd is active at a time.  There could be brief races, in
> which two ovn-northds believe that they have the lock, but they should
> not persist.
> 
> You see different behavior, so there is a bug or a misunderstanding.
> I don't see the same misbehavior, though, when I do a similar test in
> the sandbox.  If you apply the patches I just posted:
> https://patchwork.ozlabs.org/patch/895184/
> https://patchwork.ozlabs.org/patch/895185/
> then you can try it out with:
> make sandbox SANDBOXFLAGS='--ovn --sbdb-model=clustered --n-northds=3'
> 
> On Wed, Mar 21, 2018 at 01:12:48PM -0700, aginwala wrote:
> > :) The only thing is while using pacemaker, if the node that pacemaker if
> > pointing to is down, all the active/standby northd nodes have to be updated
> > to new node from the cluster. But will dig in more to see what else I can
> > find.
> > 
> > @Ben: Any suggestions further?
> > 
> > 
> > Regards,
> > 
> > On Wed, Mar 21, 2018 at 10:22 AM, Han Zhou <zhou...@gmail.com> wrote:
> > 
> > >
> > >
> > > On Wed, Mar 21, 2018 at 9:49 AM, aginwala <aginw...@asu.edu> wrote:
> > >
> > >> Thanks Numan:
> > >>
> > >> Yup agree with the locking part. For now; yes I am running northd on one
> > >> node. I might right a script to monitor northd  in cluster so that if the
> > >> node where it's running goes down, script can spin up northd on one other
> > >> active nodes as a dirty hack.
> > >>
> > >> The "dirty hack" is pacemaker :)
> > >
> > >
> > >> Sure, will await for the inputs from Ben too on this and see how complex
> > >> would it be to roll out this feature.
> > >>
> > >>
> > >> Regards,
> > >>
> > >>
> > >> On Wed, Mar 21, 2018 at 5:43 AM, Numan Siddique <nusid...@redhat.com>
> > >> wrote:
> > >>
> > >>> Hi Aliasgar,
> > >>>
> > >>> ovsdb-server maintains locks per each connection and not across the db.
> > >>> A workaround for you now would be to configure all the ovn-northd 
> > >>> instances
> > >>> to connect to one ovsdb-server if you want to have active/standy.
> > >>>
> > >>> Probably Ben can answer if there is a plan to support ovsdb locks across
> > >>> the db. We also need this support in networking-ovn as it also uses 
> > >>> ovsdb
> > >>> locks.
> > >>>
> > >>> Thanks
> > >>> Numan
> > >>>
> > >>>
> > >>> On Wed, Mar 21, 2018 at 1:40 PM, aginwala <aginw...@asu.edu> wrote:
> > >>>
> > >>>> Hi Numan:
> > >>>>
> > >>>> Just figured out that ovn-northd is running as active on all 3 nodes
> > >>>> instead of one active instance as I continued to test further which 
> > >>>> results
> > >>>> in db errors as per logs.
> > >>>>
> > >>>>
> > >>>> # on node 3, I run ovn-nbctl ls-add ls2 ; it populates below logs in
> > >>>> ovn-north
> > >>>> 2018-03-21T06:01:59.442Z|7|ovsdb_idl|WARN|transaction error:
> > >>>> {"details":"Transaction causes multiple rows in \"Datapath_Binding\" 
> > >>>> table
> > >>>> to have identical values (1) for index on column \"tunnel_key\".  First
> > >>>> row, with UUID 8c5d9342-2b90-4229-8ea1-001a733a915c, was inserted by
> > >>>> this transaction.  Second row, with UUID 
> > >>>> 8e06f919-4cc7-4ffc-9a79-20ce6663b683,
> > >>>>

Re: [ovs-discuss] raft ovsdb clustering

[Ben Pfaff]

I would like to support cluster-wide locks.  They require extra work and
they require new OVSDB JSON-RPC protocol design (because locks are
currently per-server, not per-database).  I do not currently have a
schedule for designing and implementing them.

However, I am surprised that this is an issue for northd.  For a
clustered database, ovn-northd always connects to the cluster leader.
There is at most one leader in the cluster at a given time, so as long
as ovn-northd obtains a lock on the leader, this should ensure that only
one ovn-northd is active at a time.  There could be brief races, in
which two ovn-northds believe that they have the lock, but they should
not persist.

You see different behavior, so there is a bug or a misunderstanding.
I don't see the same misbehavior, though, when I do a similar test in
the sandbox.  If you apply the patches I just posted:
https://patchwork.ozlabs.org/patch/895184/
https://patchwork.ozlabs.org/patch/895185/
then you can try it out with:
make sandbox SANDBOXFLAGS='--ovn --sbdb-model=clustered --n-northds=3'

On Wed, Mar 21, 2018 at 01:12:48PM -0700, aginwala wrote:
> :) The only thing is while using pacemaker, if the node that pacemaker if
> pointing to is down, all the active/standby northd nodes have to be updated
> to new node from the cluster. But will dig in more to see what else I can
> find.
> 
> @Ben: Any suggestions further?
> 
> 
> Regards,
> 
> On Wed, Mar 21, 2018 at 10:22 AM, Han Zhou  wrote:
> 
> >
> >
> > On Wed, Mar 21, 2018 at 9:49 AM, aginwala  wrote:
> >
> >> Thanks Numan:
> >>
> >> Yup agree with the locking part. For now; yes I am running northd on one
> >> node. I might right a script to monitor northd  in cluster so that if the
> >> node where it's running goes down, script can spin up northd on one other
> >> active nodes as a dirty hack.
> >>
> >> The "dirty hack" is pacemaker :)
> >
> >
> >> Sure, will await for the inputs from Ben too on this and see how complex
> >> would it be to roll out this feature.
> >>
> >>
> >> Regards,
> >>
> >>
> >> On Wed, Mar 21, 2018 at 5:43 AM, Numan Siddique 
> >> wrote:
> >>
> >>> Hi Aliasgar,
> >>>
> >>> ovsdb-server maintains locks per each connection and not across the db.
> >>> A workaround for you now would be to configure all the ovn-northd 
> >>> instances
> >>> to connect to one ovsdb-server if you want to have active/standy.
> >>>
> >>> Probably Ben can answer if there is a plan to support ovsdb locks across
> >>> the db. We also need this support in networking-ovn as it also uses ovsdb
> >>> locks.
> >>>
> >>> Thanks
> >>> Numan
> >>>
> >>>
> >>> On Wed, Mar 21, 2018 at 1:40 PM, aginwala  wrote:
> >>>
>  Hi Numan:
> 
>  Just figured out that ovn-northd is running as active on all 3 nodes
>  instead of one active instance as I continued to test further which 
>  results
>  in db errors as per logs.
> 
> 
>  # on node 3, I run ovn-nbctl ls-add ls2 ; it populates below logs in
>  ovn-north
>  2018-03-21T06:01:59.442Z|7|ovsdb_idl|WARN|transaction error:
>  {"details":"Transaction causes multiple rows in \"Datapath_Binding\" 
>  table
>  to have identical values (1) for index on column \"tunnel_key\".  First
>  row, with UUID 8c5d9342-2b90-4229-8ea1-001a733a915c, was inserted by
>  this transaction.  Second row, with UUID 
>  8e06f919-4cc7-4ffc-9a79-20ce6663b683,
>  existed in the database before this transaction and was not modified by 
>  the
>  transaction.","error":"constraint violation"}
> 
>  In southbound datapath list, 2 duplicate records gets created for same
>  switch.
> 
>  # ovn-sbctl list Datapath
>  _uuid   : b270ae30-3458-445f-95d2-b14e8ebddd01
>  external_ids: 
>  {logical-switch="4d6674e3-ff9f-4f38-b050-0fa9bec9e34d",
>  name="ls2"}
>  tunnel_key  : 2
> 
>  _uuid   : 8e06f919-4cc7-4ffc-9a79-20ce6663b683
>  external_ids: 
>  {logical-switch="4d6674e3-ff9f-4f38-b050-0fa9bec9e34d",
>  name="ls2"}
>  tunnel_key  : 1
> 
> 
> 
>  # on nodes 1 and 2 where northd is running, it gives below error:
>  2018-03-21T06:01:59.437Z|8|ovsdb_idl|WARN|transaction error:
>  {"details":"cannot delete Datapath_Binding row
>  8e06f919-4cc7-4ffc-9a79-20ce6663b683 because of 17 remaining
>  reference(s)","error":"referential integrity violation"}
> 
>  As per commit message, for northd I re-tried setting --ovnnb-db="tcp:
>  10.169.125.152:6641,tcp:10.169.125.131:6641,tcp:10.148.181.162:6641"
>  and --ovnsb-db="tcp:10.169.125.152:6642,tcp:10.169.125.131:6642,tcp:
>  10.148.181.162:6642" and it did not help either.
> 
>  There is no issue if I keep running only one instance of northd on any
>  of these 3 nodes. Hence, wanted to know is there 

Re: [ovs-discuss] Write to arbitrary packet location in OVS

[Ben Pfaff]

On Wed, Apr 04, 2018 at 06:51:05AM +, Vishal Deep Ajmera wrote:
> Is there a way in OVS today, wherein we can set OpenFlow pipeline
> actions to write (copy) from a register to arbitrary location in the
> packet. The start offset for read (from register) & write (to packet)
> along with size of data can be set as part of action.

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

Re: [ovs-discuss] ovs-vswitchd high CPU when there is no load

[Ben Pfaff]

On Wed, Apr 04, 2018 at 06:19:32PM +0300, michael me wrote:
> The setup i am working with is ovs-dpdk and i have a the PMD mask on core
> 1, but i see that the service of ovs-vswitchd is almost at 100% both on
> core zero and one.
> in the setup i have an openstack VM running and it is pinned to core two.

OVS normally logs some helpful messages when it uses excessive CPU.  Can
you check the log for those?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs open issues

[Ben Pfaff]

On Wed, Apr 04, 2018 at 07:40:56PM +0530, Rajasekhar Pulluru wrote:
> Hi,
> I would like to contribute to ovs. Is there a bug-tracker to see the
> current list of open issues in ovs?
> As per this page http://docs.openvswitch.org/en/latest/internals/bugs/
> bugs can be reported by sending email to b...@openvswitch.org. But, I
> don't find a way to subscribe to this list
> (https://mail.openvswitch.org/mailman/listinfo). Are the bugs reported
> to closed group?

b...@openvswitch.org is just an alias for the ovs-discuss list.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.9.0] testsuite: 787 1011 1932 1933 1934 1935 1936 1937 1941 1943 failed

[Ben Pfaff]

On Sun, Apr 01, 2018 at 11:17:55PM +0100, Stuart Cardall wrote:
> The majority of the failures were due to Busybox's diff. With the patch
> & _without_ diffutils:

Thanks for testing.

I sent a patch that skips those tests if "normal" diff is unavailable:
https://patchwork.ozlabs.org/patch/894329/

I don't have time to investigate the final test failure right now, since
it seems that it would require some experimentation on Alpine Linux.
Maybe someone else has time to check it out.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.9.0] testsuite: 787 1011 1932 1933 1934 1935 1936 1937 1941 1943 failed

[Ben Pfaff]

On Sun, Mar 25, 2018 at 10:30:44PM +0100, Stuart Cardall wrote:
> Test results for 2.9.0 under Alpine Linux (fails mainly from the
> ovsdb-server replication sections).
> 
> Anything I can do to help test - please let me know.

Thanks for the report.

The failure of test 787 is hard to explain.  I don't have a good idea on
that one.  Sometimes, some of our tests have intermittent failures due
to timing, which is undesirable but difficult to eliminate.  It doesn't
look like that should be one of those, though.

1011 was just a bug in the testsuite.  I sent out a patch:
https://patchwork.ozlabs.org/patch/894033/

I believe that the remaining tests fail because busybox "diff" is not
POSIX compliant.  To verify that, would you mind installing GNU
diffutils and rerunning those tests?  If that fixes the problem, then we
will have to decide whether it is better to document GNU diffutils as a
dependency for running the tests, or to skip those tests if diff is
incompatible, or to modify the testsuite to cope with noncompliant diff.

Thanks,

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

Re: [ovs-discuss] Controller to Switch distance (milli-second) limits

[Ben Pfaff]

On Sun, Apr 01, 2018 at 08:45:05AM -0400, ravimalhot . wrote:
> I am working on a topology where the Controller is separated from its OVS
> instances by over 30 milliseconds.  I imagine that the performance of the
> Controller will begin to degrade as its distance to OVS instances increases
> since the Controller will be waiting longer and that would consume more
> resources on the Controller. I spend some time searching this topic but did
> not find anything. Can someone point me to an indepth discussion of this
> topic?

I don't know of an in-depth discussion.  I'll point out, though, that
the architecture of the controller makes a great difference.  If the
controller is reactive, that is, if it sets up flows in reaction to
traffic (received via packet-ins), then it will be affected much more by
the RTT to the switch than if it is proactive.

> Also, I am new to this mailing list. I tried to look in the archives first
> and I did not see an easy way to search them -- the archives are available
> as downloadable text files (one file per month).  I would have to download
> the files and then search through them individually. Am I missing an easier
> way to search?

You can use Google or another search engine to search, if you specify
"site:openvswitch.org".  Works quite well.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.9.0] testsuite: 2419 failed

[Ben Pfaff]

On Fri, Mar 16, 2018 at 03:13:35PM +0100, Timothy Redaelli wrote:
> Hi,
> I found that this test (ptap - recirculate after packet_type change)
> fails (both on 2.9.0 and master), on Linux, if you have a tun device on
> your system (in my case it was an OpenVPN VPN).
> 
> Simple way to replicate it:
> 
> # ip tuntap add mode tun tun0
> # ip addr add dev tun0 10.8.0.10
> %  make check TESTSUITEFLAGS="-d -v 2419" # or 2429 on current master
> 
> I tried to figure out by myself why this happens, but I failed.

Thanks for the report.

I sent out a 2-patch series to fix the problem:
https://patchwork.ozlabs.org/patch/893899/
https://patchwork.ozlabs.org/patch/893898/

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

Re: [ovs-discuss] ovs-git list

[Ben Pfaff]

On Mon, Mar 26, 2018 at 05:06:52PM -0500, Mark Michelson wrote:
> I'm subscribed to the ovs-git list but have not received any new messages on
> that list since 24 March (commit f70b61d3 log: Add async commit support.).
> The archives appear to stop there as well. Is there an issue with the list?

I don't see any problems with the setup at Github to direct emails to
the list, or in the Mailman configuration.  I do see that there have
been several emails on the list since then, including some from my
commits today, so I guess that if there was a problem then it was
intermittent.

(I don't subscribe to ovs-git myself.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] queue length of switch's output port

[Ben Pfaff]

On Thu, Mar 22, 2018 at 11:08:17AM +0100, Maiass Zaher wrote:
> is there a way to check the length of switches' port queue, and if there
> isn't an obvious way for that, could you please provide any guidance about
> how can a one propose new functions into source code ovs switch.

I don't know of a way to check a queue length in the Linux kernel.  I
guess that you would have to add a feature to the Linux netdev core to
do this.

(I'd be pleased to find out that there is already an interface.  If we
are lucky, someone will step forward to correct me.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] SELECT groups - hash

[Ben Pfaff]

I don't think we support this in pre-OF1.5.

On Sat, Mar 24, 2018 at 11:57:57PM +0100, Slavica Tomovic wrote:
> I forgot to mention that I use Floodlight controller. Can I achieve what
> you suggested with the controller that does not support OF1.5?
> 
> BR,
> Slavica
> 
> 
> 2018-03-24 23:30 GMT+01:00 Slavica Tomovic <slavicat...@gmail.com>:
> 
> > Thank Ben.
> >
> > Can you help me with the syntax? I tried this:
> >
> > ovs-ofctl  mod-group s11 group_id=24, type=select, selection_method=hash
> >
> > However, I am getting an error the mod-group command takes at most two
> > arguments.
> > I am using OVS 2.5.2.
> >
> > Also, how should I specify the fields? In the documentation, I found
> > this:
> >
> > fields(field[=mask]...)
> >
> > Does this mean that I should specify the fields like this: fields(nw_src 
> > nw_dst udp..)?
> >
> >
> > Thanks in advance,
> > Slavica
> >
> > 2018-03-24 19:10 GMT+01:00 Ben Pfaff <b...@ovn.org>:
> >
> >> On Sat, Mar 24, 2018 at 06:45:50PM +0100, Slavica Tomovic wrote:
> >> >  Hi,
> >> >
> >> > I am using SELECT Group tables for load balancing purposes in OpenFlow
> >> > network. However, I found that OVS by default performs hashing only on
> >> IP
> >> > addresses, MAC addresses, VLAN IDs, TCP ports and EthType fields. Is it
> >> > possible to change this and use a hash function that depends on UDP
> >> port?
> >> >
> >> > I have read these posts:
> >> > https://mail.openvswitch.org/pipermail/ovs-discuss/2016-July
> >> /041934.html
> >> > https://mail.openvswitch.org/pipermail/ovs-dev/2015-March/214529.html
> >> >
> >> > and according to them I need to do this by implementing a logic for
> >> > creation of group properties structure on SDN controller. Can I avoid
> >> this
> >> > somehow and configure OVS switches with some command to perform hashing
> >> on
> >> > UDP ports?
> >>
> >> It sounds like you just need to use ovs-ofctl to configure the behavior
> >> you want.  Did you read the "Group Syntax" section in the manpage?  You
> >> want to specify the "fields" parameter.
> >>
> >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-ofctl memory consumption is large compared to flow bundle size [formatting correction]

[Ben Pfaff]

On Mon, Mar 12, 2018 at 03:47:16PM -0400, Michael Ben-Ami via discuss wrote:
> We found that when we add a flow bundle of about 25MB of textual flows,
> ovs-ofctl ballooned in resident memory to around 563MB. Similarly for a
> bundle about half the size at 12.4MB, ovs-ofctl hit 285MB.

I have a branch in my "reviews" repository that should fix this:
https://github.com/blp/ovs-reviews/tree/memory

It's not quite ready to post for formal review (the commit messages need
work and it probably leaks some memory), but if you have a minute to
test it out, please do consider it.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Turn bridge into a HUB

[Ben Pfaff]

On Mon, Mar 19, 2018 at 07:58:40PM +, Luiz Angelo Daros de Luca wrote:
> Hello,
> 
> I have a physical port receives traffic from mirrored ports in a physical
> (core) switch. I would like to pass these packets to multiple VMs (xen),
> replicating vlan tags when existing.
> 
> With linux bridges, I set aging to 0 and, as it does not understand vlan
> tags, everything works. Now I want to setup the same situation with ovs.
> I'm still a newbie with ovs.
> 
> Xen uses the /etc/xen/scripts/vif-openvswitch that allows me to specify tag
> and trunk argument when a vm port is added (not much besides that). As I
> might receive multiple vlans, I would like to not list all of them.
> 
> I saw that flood_vlans might be useful. I simply need to flood all traffic
> from the physical port on every other port but the physical one,
> replicating vlan tags.

You could set this up with flood_vlans, but you would have to list the
vlans.  ovs-vsctl supports ranges, so you could probably do this easily,
e.g.:
ovs-vsctl set bridge br0 flood_vlans=1-4095

Another way to do this would be to add flows or to use a controller to
add flows.  All you really need is a high-priority flow that does normal
processing for your "regular vlan" and another one that falls back to
flooding, e.g.:

priority=5, vlan_vid=1234, actions=normal
priority=4, actions=flood
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Controller recognizes bridges as hosts!!!

[Ben Pfaff]

It sounds like this is a controller configuration problem.  If you want
the controller to behave differently, then I guess you should configure
it differently.

On Mon, Mar 19, 2018 at 01:21:06PM -0400, Sh j wrote:
> Thank you for your reply.
> 
> The problem is that if I do not assign IP addresses to bridges, these two
> OVSs can not ping each other.
> There are some papers that they use OVSs to connect each other without any
> hosts connected to them (wmSDN).
> In that case, is it possible to configure OVS to avoid the controller to
> recognize IP addresses assigned to bridges as hosts?
> 
> The main problem is that in the mentioned topology the packet_in
> messages to the controller will be different between when we have hosts
> connected to OVSs and when there is no host.
> 
> When the controller considers the IP addresses as host, and node1 running
> OVS1(10.0.0.1) ping node2 running OVS2(10.0.0.2), OVS1 sends ARP request to
> the controller as packet_in. But in case we do not have any host, OVS1 is
> supposed to send  ICMP messages as packet_in to the controller and then
> broadcast ARP to get the MAC address of node2(running OVS2).
> I want to have the second the scenario. Could you help me with
> this configuration?
> 
> Thank you
> 
> 
> 
> 
> On Sun, Mar 18, 2018 at 8:31 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Sat, Mar 17, 2018 at 08:11:48PM -0400, Sh j wrote:
> > > Hello everyone,
> > >
> > > I configured two OVSs as follows,
> > >
> > > OVS1(eth0) --- (eth0)OVS2
> > >
> > > ovs-vsctl add-br brx
> > > ovs-vsctl add-port brx ethx
> > > ip addr flush dev ethx
> > > ip addr add 10.0.0.x/16 dev brx
> > > ip link set brx up
> > >
> > > Then I set them to connect to a controller as follows,
> > > ovs-vsctl set-controller brx tcp:
> > >
> > >
> > > When I check the discovered topology in the controller, 10.0.0.X
> > addresses
> > > are recognized as hosts connected to OVSs and the MAC address of the OVSs
> > > are considered as MAC address for hosts.
> > >
> > > However, in this case, I do not want to have any hosts, I just want to
> > > configure OVSs to see how they can forward packets between themselves.
> > >
> > > Could you help me with this issue?
> >
> > If you don't want the bridges to have IP addresses, then don't assign
> > them any.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Controller recognizes bridges as hosts!!!

[Ben Pfaff]

On Sat, Mar 17, 2018 at 08:11:48PM -0400, Sh j wrote:
> Hello everyone,
> 
> I configured two OVSs as follows,
> 
> OVS1(eth0) --- (eth0)OVS2
> 
> ovs-vsctl add-br brx
> ovs-vsctl add-port brx ethx
> ip addr flush dev ethx
> ip addr add 10.0.0.x/16 dev brx
> ip link set brx up
> 
> Then I set them to connect to a controller as follows,
> ovs-vsctl set-controller brx tcp:
> 
> 
> When I check the discovered topology in the controller, 10.0.0.X addresses
> are recognized as hosts connected to OVSs and the MAC address of the OVSs
> are considered as MAC address for hosts.
> 
> However, in this case, I do not want to have any hosts, I just want to
> configure OVSs to see how they can forward packets between themselves.
> 
> Could you help me with this issue?

If you don't want the bridges to have IP addresses, then don't assign
them any.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ping loss of first packet with OVN l3 logical router.

[Ben Pfaff]

The issue is just the lack of packet buffering.  To fix it, we need to
implement packet buffering somehow.

On Sat, Mar 17, 2018 at 08:15:17AM +0800, Guoshuai Li wrote:
> What about add an incomplete(only ip, no mac) Mac_binding when configuring
> the route's nexthop?
> 
> Similar to the linux system：
> # arp -n
> 10.157.0.253 (incomplete) eth0
> 
> Then ovn-controller sends an arp request for this？
> 
> When this icmp is sent, the arp has already been requested.
> 
> >It's currently part of the design but it's not great for users, so it'd
> >be nice to fix it someday and I'd be pleased to hear proposals if anyone
> >wants to work on this.
> 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ping loss of first packet with OVN l3 logical router.

[Ben Pfaff]

It's currently part of the design but it's not great for users, so it'd
be nice to fix it someday and I'd be pleased to hear proposals if anyone
wants to work on this.

On Fri, Mar 16, 2018 at 04:39:35PM +0530, Numan Siddique wrote:
> Hi Jai,
> 
> This is by design. For any IP packet which goes through the logical router
> pipeline, if OVN doesn't know the mac of next hop, it learns it by
> generating an ARP request packet replacing the original IP packet. That's
> the reason why the first ping is always dropped.
> 
> You can run "ovn-sbctl list mac_binding" and see the list of mac learnings.
> 
> Thanks
> Numan
> 
> 
> On Fri, Mar 16, 2018 at 4:17 PM, Jai Singh Rana  wrote:
> 
> > Hi All,
> >
> > I have configured OVN L3 logical router for external traffic with 3
> > host native ovs/ovn setup.When pinging from VM to external network for
> > the first time after bringing up ovn l3 router , there is ping loss of
> > first packet. Afterwards everything works fine even if pinging after
> > some interval and no packet loss is observed.
> >
> > If anyone observed this issue before or has any suggestions to rectify
> > this, it will be very helpful. I am using ovs-2.8.90.
> >
> > Setup topology, configurations and logs are as in following link:
> >
> > https://pastebin.com/RuTErpw2
> >
> > -Jai
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> >

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

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

Re: [ovs-discuss] Discrepancy between ofproto/trace output and dpctl dump-flows output

[Ben Pfaff]

I finally fixed this upstream in Git, and the fix will be in the next
releases on the 2.8 and 2.9 branches.

On Thu, Dec 07, 2017 at 06:06:22AM +, Amar Padmanabhan wrote:
> Yup thanks we are unblocked!
> - Amar
> 
> On 12/6/17, 12:36 PM, "Ben Pfaff" <b...@ovn.org> wrote:
> 
> OK.
> 
> In the meantime, you can add "eth()" to the flows you're tracing to get
> the expected results.
> 
> On Wed, Dec 06, 2017 at 07:02:42PM +, Amar Padmanabhan wrote:
> > Thanks Ben for taking a look,
>     > Regards,
> > - Amar
> > 
> > On 12/6/17, 10:17 AM, "Ben Pfaff" <b...@ovn.org> wrote:
> > 
> > On Wed, Dec 06, 2017 at 05:58:41AM +, Amar Padmanabhan wrote:
> > > We are debugging a setup and are seeing something that we are 
> finding it hard to explain.
> > > 
> > > 1 - Here is the ovs-dpctl dump-flows output.
> > > 
> recirc_id(0),in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no),
>  packets:550, bytes:53900, used:0.364s, 
> actions:userspace(pid=3276048382,slow_path(controller))
> > 
> > OK, the above datapath flow just says that packets in this flow 
> have to
> > be handled in the userspace slow path because 
> > 
> > > 2 - We are now trying to trace this flow and are not seeing the 
> output to controller flow getting hit in the trace.
> > > sudo ovs-appctl ofproto/trace 
> "in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > > Flow: 
> packet_type=(1,0x800),in_port=32770,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > > bridge("gtp_br0")
> > > -
> > > 0. priority 0 resubmit(,1)
> > > 1. in_port=32770, priority 10 set_field:0->metadata resubmit(,2)
> > > 2. priority 0 resubmit(,3)
> > > 3. No match. drop Final flow: unchanged Megaflow: 
> recirc_id=0,packet_type=(1,0x800),in_port=32770,nw_frag=no Datapath actions: 
> drop ---> Why isn’t the output to controller flow getting hit?
> > > 
> > > 
> > > 3 - We are also seeing the flow counts go up for the output to 
> controller flow per the ofctl dump-flows output (pasting relevant flows)
> > > 
> > > NXST_FLOW reply (xid=0x4): cookie=0x0, duration=1482.245s, 
> table=0, n_packets=1408, n_bytes=148464, idle_age=1, priority=0 
> actions=resubmit(,1)
> > > cookie=0x0, duration=1482.244s, table=1, n_packets=1283, 
> n_bytes=123662, idle_age=1, priority=10,in_port=32770 
> actions=set_field:0->metadata,resubmit(,2)
> > > cookie=0x0, duration=1482.244s, table=2, n_packets=1247, 
> n_bytes=122150, idle_age=1, priority=0 actions=resubmit(,3)
> > > cookie=0x0, duration=1482.245s, table=3, n_packets=1245, 
> n_bytes=122010, idle_age=1, priority=0,ip,metadata=0,nw_dst=192.168.128.0/24 
> actions=CONTROLLER:65535 ---> Notice that this is getting hit as well
> > 
> > OK, I spent a few minutes to mock up your environment (thanks for 
> all
> > the details!) and experiment.  It looks like the problem is 
> actually a
> > mismatch between the formatting and parsing code for datapath 
> flows.  If
> > I run:
> > 
> > ovs-appctl ofproto/trace 
> "in_port(3),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > 
> > that is, add "eth()" to the datapath flow, then I get the expected
> > results:
> > 
> > $ ovs-appctl ofproto/trace 
> "in_port(1),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > Flow: 
> ip,in_port=32770,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > 
> > bridge("br0")
> > -
> >  0. priority 0
> > resubmit(,1)
> >  1. in_port=32770, priority 10
> > load:0->OXM_OF_METADATA[]
> > resubmit(,2)
> >  2. priority 0
> > resubmit(,3)
> >  3. ip,metadata=0,nw_dst=192.168.128.0/24, priority 0
> > CONTROLLER:65535
> > 
> > Final flow: unchanged
> >  

Re: [ovs-discuss] ovn-controller periodically reporting status

[Ben Pfaff]

On Tue, Mar 13, 2018 at 05:46:41PM +0530, Anil Venkata wrote:
> In Openstack neutron reference implementation, all agents will be
> periodically reporting their status to neutron server. Similarly in
> Openstack OVN based deployment, we want ovn-controller to periodically
> report its status to neutron server.

What kind of monitoring do you need?  If it's just a matter of finding
out that the controllers are still alive, then the existing "nb_cfg"
column in Chassis can suffice.  When neutron wants to check on the
controllers, it can increment nb_cfg in NB_Global and then see which
controllers update nb_cfg in Chassis in response.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs route refresh problem

[Ben Pfaff]

On Thu, Mar 01, 2018 at 10:21:38AM -0800, Ben Pfaff wrote:
> On Fri, Feb 23, 2018 at 03:30:59AM +, Yinpeijun wrote:
> > 
> > >>On Sun, Feb 11, 2018 at 07:27:34AM +, Yinpeijun wrote:
> > >> Hi all
> > >> Recently , I run a test two VM commulication with 
> > >> vxlan and ovs+dpdk networking(ovs2.7.2). when I add 200 virtual device 
> > >> on the physical service  of the commulicate vm then check the ping 
> > >> result,  there  is  loss packet statistics. Then I use vlan and ovs+dpdk 
> > >> networking, do the same thing , there is no loss packets statistics.
> > >> I read the source code and add some log to confirm the 
> > >> problem,  the final problem I think is unreasonable routing refresh,  
> > >> in route_table_rest function delete all items before readding, so in the 
> > >> middle of the interval  ovs_router_lookup  can not find the route then 
> > >> cause packet drop.  So I think the implementation need to optimize, Any 
> > >> advice on how to optimize it?
> > 
> > >I don't fully understand your use case.  However, if you're not using 
> > >DPDK, then OVS isn't doing routing in userspace so this is probably not 
> > >the problem.
> > 
> > Thank you for your replay, the test case just for reproduce the problem. 
> > The actual  scene is to create or migrate virtual machines in openstack 
> > env. Correspondence will be created linux bridge
> > and other virtual device.
> > 
> > There is also have problem in netdev dataptah without dpdk.  vxlan tunnel 
> > need route in userspace and ovs maintain the route table as follow:
> > ovs-appctl ovs/route/show
> > Route Table:
> > Cached: x.xx.1.10/32 dev eth0 SRC x.xx.1.10
> > Cached: 10.0.0.10/32 dev brcps SRC 10.0.0.10
> > Cached: 127.0.0.1/32 dev lo SRC 127.0.0.1
> > 
> > So when I create virtual device trigger ovs refresh the route then affect 
> > the already existing virtual machine communication.
> 
> This is the same datapath, really, it's just that most people use it
> with DPDK, and so the solution would be the same.
> 
> I think that the problem you're talking about can be fixed by holding
> the mutex in route_table_reset() across the entire update, instead of
> just for each individual operation on the routing table.  Does that make
> sense?

I sent a patch.  Will you test it?
https://patchwork.ozlabs.org/patch/884064/

Thanks,

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

Re: [ovs-discuss] OVN load balancing on same subnet failing

[Ben Pfaff]

On Fri, Mar 02, 2018 at 09:40:07AM -0800, Guru Shetty wrote:
> On 1 March 2018 at 21:09, Anil Venkata  wrote:
> 
> >
> >
> > On Fri, Mar 2, 2018 at 7:23 AM, Guru Shetty  wrote:
> >
> >>
> >>
> >> On 27 February 2018 at 03:13, Anil Venkata 
> >> wrote:
> >>
> >>> For example, I have a 10.1.0.0/24 network and a load balancer is added
> >>> to it with 10.1.0.10 as VIP and 10.1.0.2(MAC 50:54:00:00:00:01),
> >>> 10.1.0.3(MAC 50:54:00:00:00:02) as members.
> >>> ovn-nbctl  create load_balancer vips:10.1.0.10="10.1.0.2,10.1.0.3"
> >>>
> >>
> >> We currently need the VIP to be in a different subnet. You should connect
> >> switch it to a dummy logical router (or connect it to a external router).
> >> Since a VIP is in a different subnet, it sends an ARP for logical router IP
> >> and then things will work.
> >>
> >>
> >
> > Thanks Guru. Any reason for introducing this constraint(i.e VIP to be in a
> > different subnet)? Can we address this limitation?
> >
> 
> It was just easy to implement with the constraint. You will need a ARP
> responder for the VIP. And now, you will have to specify the mac address
> for each VIP in the schema. So that is a bit of work - but not hard.

Do we document the constraint?  If we do not, then that would be
helpful.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Including bfd status for tunnel endpoints on ovs-vsctl show

[Ben Pfaff]

Seems reasonable to me, feel free to submit a patch.

On Fri, Mar 09, 2018 at 05:43:00PM +, Miguel Angel Ajo Pelayo wrote:
> Ok, I have modified it to just show bfd_status, for rexample, in a 3
> controller + 1 compute
> environment, with a router and a vm on the compute:
> 
> [heat-admin@overcloud-controller-2 ovs]$ sudo utilities/ovs-vsctl show
> a4cf68a7-07e9-4ed4-a317-016cb610c821
> Bridge br-int
> fail_mode: secure
> Port "ovn-7e8b8a-0"
> Interface "ovn-7e8b8a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.5"}
> bfd_status: {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> Port "ovn-0c37dd-0"
> Interface "ovn-0c37dd-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.7"}
> bfd_status: {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> Port br-int
> Interface br-int
> type: internal
> Port "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
> Interface
> "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
> type: patch
> options:
> {peer="patch-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4-to-br-int"}
> Port "ovn-9f2335-0"
> Interface "ovn-9f2335-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.11"}
> bfd_status: {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> Bridge br-ex
> fail_mode: standalone
> Port br-ex
> Interface br-ex
> ...
> 
> 
> if I admin disable that single router with " neutron router-update router1
> --admin-state-up false"
> (the bfd should be disabled all around because it's not necessary, and
> ovs-vswitchd takes care
> of clearing up bfd_status):
> 
> [heat-admin@overcloud-controller-2 ovs]$ sudo utilities/ovs-vsctl show
> a4cf68a7-07e9-4ed4-a317-016cb610c821
> Bridge br-int
> fail_mode: secure
> Port "ovn-7e8b8a-0"
> Interface "ovn-7e8b8a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.5"}
> Port "ovn-0c37dd-0"
> Interface "ovn-0c37dd-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.7"}
> Port br-int
> Interface br-int
> type: internal
> Port "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
> Interface
> "patch-br-int-to-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4"
> type: patch
> options:
> {peer="patch-provnet-b47ffac1-1704-4e97-85ef-f4fb478e18c4-to-br-int"}
> Port "ovn-9f2335-0"
> Interface "ovn-9f2335-0"
>         type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.11"}
> Bridge br-ex
> fail_mode: standalone
> ...
> 
> 
> 
> 
> On Fri, Mar 9, 2018 at 9:32 AM Miguel Angel Ajo Pelayo <majop...@redhat.com>
> wrote:
> 
> > Thank you Ben, I'll finish it, test it properly and submit the patch.
> >
> > I don't know if it makes any sense to add a filter where the dictionary
> > has only a key "enabled" and it's "false",
> > or it's really not worth it. I'll check out how it looks with a real
> > deployment and get back here with the results.
> >
> > On Thu, Mar 8, 2018 at 7:12 PM Ben Pfaff <b...@ovn.org> wrote:
> >
> >> On Thu, Mar 08, 2018 at 04:43:50PM +, Miguel Angel Ajo Pelayo wrote:
> >> > Ok, looking at the code, it seems like we may only need to do this?
> >> >
> >> > diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
> >> > index 21fa18d..2ac60bf 100644
> >> > --- a/utilities/ovs-vsctl.c
> >> > +++ b/util

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Ben Pfaff]

I guess I wouldn't object.

On Thu, Mar 08, 2018 at 10:11:11PM +0100, Daniel Alvarez Sanchez wrote:
> Thanks Ben and Mark. I'd be okay with 2x.
> Don't you think that apart from that it can still be good to compact after
> a
> certain amount of time (like 1 day) if the number of transactions is > 0
> regardless of the size?
> 
> On Thu, Mar 8, 2018 at 10:00 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > It would be trivial to change 4x to 2x.  4x was just the suggestion in
> > the Raft thesis.  If 2x would make everyone a little more comfortable,
> > let's make that change.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] The discrepancy in the Monitor request composition.

[Ben Pfaff]

No.  A JSON object can have any number of members.

On Thu, Mar 08, 2018 at 11:06:21AM -0800, Anil Jangam wrote:
> Thanks Ben for clarification. So it means one Monitor request can request
> for only one Table monitoring, correct?
> 
> On Thu, Mar 8, 2018 at 10:36 AM, Ben Pfaff <b...@ovn.org> wrote:
> 
> >  is a JSON object.  A JSON object maps from keys to
> > values, so we only need one.
> >
> > Your specification for  is wrong because it says that
> > it is a JSON array.  It is not.
> >
> > On Wed, Mar 07, 2018 at 09:32:06PM -0800, Anil Jangam wrote:
> > > Hello Ben,
> > >
> > > I have one more observation. I request you to please read it carefully.
> > If
> > > we go by the current monitor method definition, there can be only
> > > 
> > > in one monitor RPC method. If it is expected to have only one
> > > 
> > > i.e. one table and an array of , then the current
> > > specification is good.
> > >
> > > o  "method": "monitor"
> > >
> > > o  "params": [, , ]
> > >
> > > o  "id": 
> > >
> > >
> > > However, if it is possible to specify multiple table monitoring in one
> > RPC
> > > method, IMHO the above syntax would change as below.
> > >
> > >
> > > o  "method": "monitor"
> > >
> > > o  "params": [, , *]
> > >
> > > o  "id": 
> > >
> > >
> > > For completeness, I am also specifying the syntax for .
> > >
> > > monitor-requests : [, *]
> > >
> > >
> > > Let me know if this would be correct or if you think otherwise.
> > >
> > > /anil.
> > >
> > >
> > >
> > > On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff <b...@ovn.org> wrote:
> > >
> > > > Ah, OK, you're saying that there's a missing [] around the
> > > > .  This goes back to a change that we made to the
> > > > ovsdb-server protocol a long time ago to allow multiple
> > > >  objects instead of just a single one.  ovsdb-server
> > > > still supports this form.  You can see this documented in
> > > > Documentation/ref/ovsdb-server.7.rst:
> > > >
> > > > For backward compatibility, ``ovsdb-server`` currently permits a
> > single
> > > >  to be used instead of an array; it is treated as
> > a
> > > > single-element array.  Future versions of ``ovsdb-server`` might
> > > > remove this
> > > > compatibility feature.
> > > >
> > > > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> > > >
> > > > Anyway, that's easy enough, so I sent a patch:
> > > > https://patchwork.ozlabs.org/patch/882710/
> > > >
> > > > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > > > Hello Ben,
> > > > >
> > > > > The  object maps the name of the table to be
> > monitored
> > > > >
> > > > > to an array of  objects. Each  is
> > an
> > > > >
> > > > > object with the following members:
> > > > >
> > > > >"columns": [*]optional
> > > > >
> > > > >"select": optional
> > > > >
> > > > >
> > > > >
> > > > > As the  maps the table name to be monitored to an
> > array
> > > > > of , my interpretation of it is as "Table Name <-->
> > > > Array
> > > > > of "
> > > > >
> > > > > I am giving an example message is given below.
> > > > >
> > > > > {
> > > > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > > > >   "method": "monitor",
> > > > >   "params": [
> > > > > "hardware_vtep",
> > > > > "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > > > {
> > > > >   "Physical_Locator": [
> > > > > {
> > > > >   "columns": [
> > > > > "dst_ip",
> > > > > "encapsulation_type",
> > > > > "_uuid"
> > > > > 

Re: [ovs-discuss] The discrepancy in the Monitor request composition.

[Ben Pfaff]

 is a JSON object.  A JSON object maps from keys to
values, so we only need one.

Your specification for  is wrong because it says that
it is a JSON array.  It is not.

On Wed, Mar 07, 2018 at 09:32:06PM -0800, Anil Jangam wrote:
> Hello Ben,
> 
> I have one more observation. I request you to please read it carefully. If
> we go by the current monitor method definition, there can be only
> 
> in one monitor RPC method. If it is expected to have only one
> 
> i.e. one table and an array of , then the current
> specification is good.
> 
> o  "method": "monitor"
> 
> o  "params": [, , ]
> 
> o  "id": 
> 
> 
> However, if it is possible to specify multiple table monitoring in one RPC
> method, IMHO the above syntax would change as below.
> 
> 
> o  "method": "monitor"
> 
> o  "params": [, , *]
> 
> o  "id": 
> 
> 
> For completeness, I am also specifying the syntax for .
> 
> monitor-requests : [, *]
> 
> 
> Let me know if this would be correct or if you think otherwise.
> 
> /anil.
> 
> 
> 
> On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > Ah, OK, you're saying that there's a missing [] around the
> > .  This goes back to a change that we made to the
> > ovsdb-server protocol a long time ago to allow multiple
> >  objects instead of just a single one.  ovsdb-server
> > still supports this form.  You can see this documented in
> > Documentation/ref/ovsdb-server.7.rst:
> >
> > For backward compatibility, ``ovsdb-server`` currently permits a single
> >  to be used instead of an array; it is treated as a
> > single-element array.  Future versions of ``ovsdb-server`` might
> > remove this
> > compatibility feature.
> >
> > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> >
> > Anyway, that's easy enough, so I sent a patch:
> > https://patchwork.ozlabs.org/patch/882710/
> >
> > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > Hello Ben,
> > >
> > > The  object maps the name of the table to be monitored
> > >
> > > to an array of  objects. Each  is an
> > >
> > > object with the following members:
> > >
> > >"columns": [*]optional
> > >
> > >"select": optional
> > >
> > >
> > >
> > > As the  maps the table name to be monitored to an array
> > > of , my interpretation of it is as "Table Name <-->
> > Array
> > > of "
> > >
> > > I am giving an example message is given below.
> > >
> > > {
> > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > >   "method": "monitor",
> > >   "params": [
> > > "hardware_vtep",
> > > "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > {
> > >   "Physical_Locator": [
> > > {
> > >   "columns": [
> > > "dst_ip",
> > > "encapsulation_type",
> > > "_uuid"
> > >   ],
> > >   "select": {
> > > "initial": true,
> > > "insert": true,
> > > "delete": true,
> > > "modify": true
> > >   }
> > > },
> > > {
> > >   "columns": [
> > > "_uuid",
> > > "locators"
> > >   ],
> > >   "select": {
> > > "initial": true,
> > > "insert": true,
> > > "delete": true,
> > > "modify": true
> > >   }
> > > }
> > >   ]
> > > }
> > >   ]
> > > }
> > >
> > >
> > > /anil.
> > >
> > >
> > >
> > > On Tue, Mar 6, 2018 at 11:30 AM, Ben Pfaff <b...@ovn.org> wrote:
> > >
> > > > On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> > > > > Hi,
> > > > >
> > > > > The RFC7047 states below about the Monitor request.
> > > > >
> > > > > The request object ha

Re: [ovs-discuss] Including bfd status for tunnel endpoints on ovs-vsctl show

[Ben Pfaff]

On Thu, Mar 08, 2018 at 04:43:50PM +, Miguel Angel Ajo Pelayo wrote:
> Ok, looking at the code, it seems like we may only need to do this?
> 
> diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
> index 21fa18d..2ac60bf 100644
> --- a/utilities/ovs-vsctl.c
> +++ b/utilities/ovs-vsctl.c
> @@ -1018,7 +1018,9 @@ static struct cmd_show_table cmd_show_tables[] = {
>   _interface_col_name,
>   {_interface_col_type,
>_interface_col_options,
> -  _interface_col_error},
> +  _interface_col_error,
> +  _interface_col_bfd,
> +  _interface_col_bfd_status},
>   {NULL, NULL, NULL}
>  },

Yes, you also need to increase the size of columns[] in cmd_show_table:

diff --git a/lib/db-ctl-base.h b/lib/db-ctl-base.h
index eb444270535b..5d8532a7bde2 100644
--- a/lib/db-ctl-base.h
+++ b/lib/db-ctl-base.h
@@ -197,7 +197,7 @@ struct weak_ref_table {
 struct cmd_show_table {
 const struct ovsdb_idl_table_class *table;
 const struct ovsdb_idl_column *name_column;
-const struct ovsdb_idl_column *columns[3]; /* Seems like a good number. */
+const struct ovsdb_idl_column *columns[5]; /* Seems like a good number. */
 const struct weak_ref_table wref_table;
 };
 
> But that would render something like:
> 
> 
> [heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
> 5f35518a-ab34-49a4-a227-e487e251b7e3
> Manager "ptcp:6640:127.0.0.1"
> is_connected: true
> Bridge br-int
> fail_mode: secure
> Port "ovn-14d60a-0"
> Interface "ovn-14d60a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.16.0.12"}
> bfd: {enable="true"}
> bfd_status: {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> 
> 
> I'm partly guessing here based on what I see around lib/db-ctl-base.c and
> doing a little bit of debugging.
> 
> @Ben is there any way of filtering out those columns when
> bfd:enabled="false" or not set ?

It appears that that's already what happens, at least for the "not set"
case.  I doubt there are many controllers that explicitly set enable to
false.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] Passive openflow proxy

[Ben Pfaff]

On Thu, Mar 08, 2018 at 07:51:23PM +0800, Xiao Liang wrote:
> In my experience, one thing I feel inconvenient is that some switches
> don't support controller-initiated connections. It would be helpful
> for testing and debugging if ovs-ofctl could be used.
> I'd propose an openflow proxy which is responsible for accepting and
> maintaining connections from switches, opening sockets for controllers
> to connect, and proxy messages between them. So that openflow tools
> like ovs-ofctl can operate on these switches.
> Another approach might be adding a "passive mode" to ovs-ofctl, which
> listens for connections, and opens an interactive shell to run
> commands.

I guess that this is a problem with non-OVS switches?  OVS does support
controller-initiated connections.

The proxy that you describe is going to be difficult to write because to
be most useful it would have to multiplex multiple connections into a
single connection.  OpenFlow connections are not stateless, so it would
have to figure out how to effectively partition the desires of multiple
clients into a single session.  I haven't thought through all the
necessary logic, but it would not be trivial.

I think that the ovs-ofctl passive mode that you describe is similar in
practice to writing a proxy: probably, it would internally start a proxy
and then allow the user to access it.  It might be easiest to actually
implement it as a mode for the proxy that starts a subshell.

I think that this is a worthy project, for someone for whom support for
non-OVS switches is important, and I'd encourage a motivated developer
to work on it.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] The discrepancy in the Monitor request composition.

[Ben Pfaff]

No.  The "Reported-by:" tag is really just a kind of "thank-you".
Thanks again.

On Wed, Mar 07, 2018 at 02:50:32PM -0800, Anil Jangam wrote:
> Thanks you Ben! I saw the other patch email as well. Since it is says that
> "reported-by" me, do I have any further action item on me?
> 
> /anil.
> 
> 
> On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > Ah, OK, you're saying that there's a missing [] around the
> > .  This goes back to a change that we made to the
> > ovsdb-server protocol a long time ago to allow multiple
> >  objects instead of just a single one.  ovsdb-server
> > still supports this form.  You can see this documented in
> > Documentation/ref/ovsdb-server.7.rst:
> >
> > For backward compatibility, ``ovsdb-server`` currently permits a single
> >  to be used instead of an array; it is treated as a
> > single-element array.  Future versions of ``ovsdb-server`` might
> > remove this
> > compatibility feature.
> >
> > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> >
> > Anyway, that's easy enough, so I sent a patch:
> > https://patchwork.ozlabs.org/patch/882710/
> >
> > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > Hello Ben,
> > >
> > > The  object maps the name of the table to be monitored
> > >
> > > to an array of  objects. Each  is an
> > >
> > > object with the following members:
> > >
> > >"columns": [*]optional
> > >
> > >"select": optional
> > >
> > >
> > >
> > > As the  maps the table name to be monitored to an array
> > > of , my interpretation of it is as "Table Name <-->
> > Array
> > > of "
> > >
> > > I am giving an example message is given below.
> > >
> > > {
> > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > >   "method": "monitor",
> > >   "params": [
> > > "hardware_vtep",
> > > "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > {
> > >   "Physical_Locator": [
> > > {
> > >   "columns": [
> > > "dst_ip",
> > > "encapsulation_type",
> > > "_uuid"
> > >   ],
> > >   "select": {
> > > "initial": true,
> > > "insert": true,
> > > "delete": true,
> > > "modify": true
> > >   }
> > > },
> > > {
> > >   "columns": [
> > > "_uuid",
> > > "locators"
> > >   ],
> > >   "select": {
> > > "initial": true,
> > > "insert": true,
> > > "delete": true,
> > > "modify": true
> > >   }
> > > }
> > >   ]
> > > }
> > >   ]
> > > }
> > >
> > >
> > > /anil.
> > >
> > >
> > >
> > > On Tue, Mar 6, 2018 at 11:30 AM, Ben Pfaff <b...@ovn.org> wrote:
> > >
> > > > On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> > > > > Hi,
> > > > >
> > > > > The RFC7047 states below about the Monitor request.
> > > > >
> > > > > The request object has the
> > > > >
> > > > >following members:
> > > > >
> > > > >o  "method": "monitor"
> > > > >
> > > > >o  "params": [, , ]
> > > > >
> > > > >o  "id": 
> > > > >
> > > > >
> > > > > The  parameter is used to match subsequent update
> > > > >
> > > > > notifications (see below) to this request.
> > > > >
> > > > >
> > > > > The  object maps the name of the table to be
> > monitored
> > > > >
> > > > > to an array of  objects. Each  is
> > an
> > > > >
> > &

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Ben Pfaff]

OK.

I guess we need to investigate this issue from the basics.

On Wed, Mar 07, 2018 at 09:02:02PM +0100, Daniel Alvarez Sanchez wrote:
> With OVS 2.8 branch it never shrank when I started to delete the ports since
> the DB sizes didn't grow, which makes sense to me. The conditions weren't
> met for further compaction.
> See attached image.
> 
> NB:
> 2018-03-07T18:25:49.269Z|9|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
> compacting database online (647.317 seconds old, 436 transactions, 10505382
> bytes)
> 2018-03-07T18:35:51.414Z|00012|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
> compacting database online (602.089 seconds old, 431 transactions, 29551917
> bytes)
> 2018-03-07T18:45:52.263Z|00015|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
> compacting database online (600.563 seconds old, 463 transactions, 52843231
> bytes)
> 2018-03-07T18:55:53.810Z|00016|ovsdb_file|INFO|/opt/stack/data/ovs/ovnnb_db.db:
> compacting database online (601.128 seconds old, 365 transactions, 57618931
> bytes)
> 
> 
> SB:
> 2018-03-07T18:33:24.927Z|9|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
> compacting database online (1102.840 seconds old, 775 transactions,
> 10505486 bytes)
> 2018-03-07T18:43:27.569Z|00012|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
> compacting database online (602.394 seconds old, 445 transactions, 15293972
> bytes)
> 2018-03-07T18:53:31.664Z|00015|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
> compacting database online (603.605 seconds old, 385 transactions, 19282371
> bytes)
> 2018-03-07T19:03:42.116Z|00031|ovsdb_file|INFO|/opt/stack/data/ovs/ovnsb_db.db:
> compacting database online (607.542 seconds old, 371 transactions, 23538784
> bytes)
> 
> 
> 
> 
> On Wed, Mar 7, 2018 at 7:18 PM, Daniel Alvarez Sanchez <dalva...@redhat.com>
> wrote:
> 
> > No worries, I just triggered the test now running OVS compiled out of
> > 2.8 branch (2.8.3). I'll post the results and investigate too.
> >
> > I have just sent a patch to fix the timing issue we can see in the traces I
> > posted. I applied it and it works, I believe it's good to fix as it gives
> > us
> > an idea of how frequent the compact is, and also to backport if you
> > agree with it.
> >
> > Thanks!
> >
> > On Wed, Mar 7, 2018 at 7:13 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> >> OK, thanks.
> >>
> >> If this is a lot of trouble, let me know and I'll investigate directly
> >> instead of on the basis of a suspected regression.
> >>
> >> On Wed, Mar 07, 2018 at 07:06:50PM +0100, Daniel Alvarez Sanchez wrote:
> >> > All right, I'll repeat it with code in branch-2.8.
> >> > Will post the results once the test finishes.
> >> > Daniel
> >> >
> >> > On Wed, Mar 7, 2018 at 7:03 PM, Ben Pfaff <b...@ovn.org> wrote:
> >> >
> >> > > On Wed, Mar 07, 2018 at 05:53:15PM +0100, Daniel Alvarez Sanchez
> >> wrote:
> >> > > > Repeated the test with 1000 ports this time. See attached image.
> >> > > > For some reason, the sizes grow while deleting the ports (the
> >> > > > deletion task starts at around x=2500). The weird thing is why
> >> > > > they keep growing and the online compact doesn't work as when
> >> > > > I do it through ovs-appctl tool.
> >> > > >
> >> > > > I suspect this is a bug and eventually it will grow and grow unless
> >> > > > we manually compact the db.
> >> > >
> >> > > Would you mind trying out an older ovsdb-server, for example the one
> >> > > from OVS 2.8?  Some of the logic in ovsdb-server around compaction
> >> > > changed in OVS 2.9, so it would be nice to know whether this was a
> >> > > regression or an existing bug.
> >> > >
> >>
> >
> >


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

Re: [ovs-discuss] Problem on OpenVSwitch 2.9

[Ben Pfaff]

On Wed, Mar 07, 2018 at 11:47:48AM +0100, woz woz wrote:
> Dear support,
> I’m testing OpenVSwitch version 2.9. on my infrastructure using CentOS7,
> but I’m having any problem, below my config:
> I have 4 servers with the public IP address, e.g.
> A-> 1.1.1.1
> B-> 2.2.2.2
> C-> 3.3.3.3
> D-> 4.4.4.4
> between these servers I've configured a VXLAN tunnel, in this way :
> the server named A has a VXLAN tunnel with C and D
> the server named B has a VXLAN tunnel with C and D
> the servers named C and D obviously have a tunnel with A and B
> I executed this kind of configuration because I would like to have a
> redundancy between the servers A and B , e.g if A goes down I migrate all
> the services on B and the servers C and D can continue to work without any
> problem.
> But I have the following messages on the /var/log/message :
> "kernel: openvswitch: ovs: recursion limit reached on datapath ovs-system,
> probable configuration error”
> 
> I 've read articles related to this kind of problem and I played also with
> the STP protocol in order to avoid a possible loop but I don't understand
> if I can use this configuration or I have to find another solution.

This message wouldn't be caused by a loop among servers but some kind of
configuration problem on an individual server.  When you see this
message, what is in the kernel flow table ("ovs-dpctl dump-flows") and
what ports are configured ("ovs-dpctl show")?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] openvswitch userspace mode can not use iperf send packet，whatever tcp and udp

[Ben Pfaff]

On Tue, Mar 06, 2018 at 09:22:48AM +0800, ♂漢唐峻傑♀ wrote:
> ovs userspace mode how to install in centos7, datapath-type=netdev ，
> What does “netdev” stand for?

"network device"

> as well as with the meter table relation

I don't understand this question.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] tap ports...

[Ben Pfaff]

On Mon, Mar 05, 2018 at 10:31:30PM -0700, Grant Taylor via discuss wrote:
> Can OVS create tap ports like OpenVPN or KVM (Qemu) or User Mode Linux use?
> I.e. an Ethernet interface inside OVS and a socket that applications can
> glom onto and use.
> 
> I think I can create the tap interfaces manually (via tunctl or ip tuntap…)
> and then add them to a bridge.  However I feel like this is unnecessary and
> may very well be something that OVS can do without the separate devices.
> 
> Hence my question if OVS can create (internal) tap interfaces, much the same
> way that it can create (internal) vEth (like) interfaces.

Q: I created a tap device tap0, configured an IP address on it, and added it to
a bridge, like this::

$ tunctl -t tap0
$ ip addr add 192.168.0.123/24 dev tap0
$ ip link set tap0 up
$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 tap0

I expected that I could then use this IP address to contact other hosts on the
network, but it doesn't work.  Why not?

A: The short answer is that this is a misuse of a "tap" device.  Use an
"internal" device implemented by Open vSwitch, which works differently and
is designed for this use.  To solve this problem with an internal device,
instead run::

$ ovs-vsctl add-br br0
$ ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal
$ ip addr add 192.168.0.123/24 dev int0
$ ip link set int0 up

Even more simply, you can take advantage of the internal port that every
bridge has under the name of the bridge::

$ ovs-vsctl add-br br0
$ ip addr add 192.168.0.123/24 dev br0
$ ip link set br0 up

In more detail, a "tap" device is an interface between the Linux (or BSD)
network stack and a user program that opens it as a socket.  When the "tap"
device transmits a packet, it appears in the socket opened by the userspace
program.  Conversely, when the userspace program writes to the "tap"
socket, the kernel TCP/IP stack processes the packet as if it had been
received by the "tap" device.

Consider the configuration above.  Given this configuration, if you "ping"
an IP address in the 192.168.0.x subnet, the Linux kernel routing stack
will transmit an ARP on the tap0 device.  Open vSwitch userspace treats
"tap" devices just like any other network device; that is, it doesn't open
them as "tap" sockets.  That means that the ARP packet will simply get
dropped.

You might wonder why the Open vSwitch kernel module doesn't intercept the
ARP packet and bridge it.  After all, Open vSwitch intercepts packets on
other devices.  The answer is that Open vSwitch only intercepts *received*
packets, but this is a packet being transmitted.  The same thing happens
for all other types of network devices, except for Open vSwitch "internal"
ports.  If you, for example, add a physical Ethernet port to an OVS bridge,
configure an IP address on a physical Ethernet port, and then issue a
"ping" to an address in that subnet, the same thing happens: an ARP gets
transmitted on the physical Ethernet port and Open vSwitch never sees it.
(You should not do that, as documented at the beginning of this section.)

It can make sense to add a "tap" device to an Open vSwitch bridge, if some
userspace program (other than Open vSwitch) has opened the tap socket.
This is the case, for example, if the "tap" device was created by KVM (or
QEMU) to simulate a virtual NIC.  In such a case, when OVS bridges a packet
to the "tap" device, the kernel forwards that packet to KVM in userspace,
which passes it along to the VM, and in the other direction, when the VM
sends a packet, KVM writes it to the "tap" socket, which causes OVS to
receive it and bridge it to the other OVS ports.  Please note that in such
a case no IP address is configured on the "tap" device (there is normally
an IP address configured in the virtual NIC inside the VM, but this is not
visible to the host Linux kernel or to Open vSwitch).

There is one special case in which Open vSwitch does directly read and
write "tap" sockets.  This is an implementation detail of the Open vSwitch
userspace switch, which implements its "internal" ports as Linux (or BSD)
"tap" sockets.  In such a userspace switch, OVS receives packets sent on
the "tap" device used to implement an "internal" port by reading the
associated "tap" socket, and bridges them to the rest of the switch.  In
the other direction, OVS transmits packets bridged to the "internal" port
by writing them to the "tap" socket, causing them to be processed by the
kernel TCP/IP stack as if they had been received on the "tap" device.
Users should not need to be concerned with this implementation detail.

Open vSwitch has a network device type called "tap".  This is intended only
for implementing "internal" ports in the OVS 

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Ben Pfaff]

OK, thanks.

If this is a lot of trouble, let me know and I'll investigate directly
instead of on the basis of a suspected regression.

On Wed, Mar 07, 2018 at 07:06:50PM +0100, Daniel Alvarez Sanchez wrote:
> All right, I'll repeat it with code in branch-2.8.
> Will post the results once the test finishes.
> Daniel
> 
> On Wed, Mar 7, 2018 at 7:03 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > On Wed, Mar 07, 2018 at 05:53:15PM +0100, Daniel Alvarez Sanchez wrote:
> > > Repeated the test with 1000 ports this time. See attached image.
> > > For some reason, the sizes grow while deleting the ports (the
> > > deletion task starts at around x=2500). The weird thing is why
> > > they keep growing and the online compact doesn't work as when
> > > I do it through ovs-appctl tool.
> > >
> > > I suspect this is a bug and eventually it will grow and grow unless
> > > we manually compact the db.
> >
> > Would you mind trying out an older ovsdb-server, for example the one
> > from OVS 2.8?  Some of the logic in ovsdb-server around compaction
> > changed in OVS 2.9, so it would be nice to know whether this was a
> > regression or an existing bug.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN Database sizes - Auto compact feature

[Ben Pfaff]

On Wed, Mar 07, 2018 at 05:53:15PM +0100, Daniel Alvarez Sanchez wrote:
> Repeated the test with 1000 ports this time. See attached image.
> For some reason, the sizes grow while deleting the ports (the
> deletion task starts at around x=2500). The weird thing is why
> they keep growing and the online compact doesn't work as when
> I do it through ovs-appctl tool.
> 
> I suspect this is a bug and eventually it will grow and grow unless
> we manually compact the db.

Would you mind trying out an older ovsdb-server, for example the one
from OVS 2.8?  Some of the logic in ovsdb-server around compaction
changed in OVS 2.9, so it would be nice to know whether this was a
regression or an existing bug.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] The discrepancy in the Monitor request composition.

[Ben Pfaff]

On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> Hi,
> 
> The RFC7047 states below about the Monitor request.
> 
> The request object has the
> 
>following members:
> 
>o  "method": "monitor"
> 
>o  "params": [, , ]
> 
>o  "id": 
> 
> 
> The  parameter is used to match subsequent update
> 
> notifications (see below) to this request.
> 
> 
> The  object maps the name of the table to be monitored
> 
> to an array of  objects. Each  is an
> 
> object with the following members:
> 
>"columns": [*]optional
> 
>"select": optional
> 
> The columns, if present, define the columns within the table to be monitored.
> 
>  is an object with the following members:
> 
>"initial":   optional
> 
>"insert":optional
> 
>"delete":optional
> 
>"modify":optional
> 
> The contents of this object specify how the columns or table are to be
> monitored,
> 
> as explained in more detail below.
> 
> 
> However, when I look at some of the legitimate samples of the Monitor
> requests, they are encoded as below.
> 
> {
>   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
>   "method": "monitor",
>   "params": [
> "hardware_vtep",
> "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> {
>   "Physical_Locator": {
> "columns": [
>   "dst_ip",
>   "encapsulation_type",
>   "_uuid"
> ],
> "select": {
>   "initial": true,
>   "insert": true,
>   "delete": true,
>   "modify": true
> }
>   },
>   "Physical_Locator_Set": {
> "columns": [
>   "_uuid",
>   "locators"
> ],
> "select": {
>   "initial": true,
>   "insert": true,
>   "delete": true,
>   "modify": true
> }
>   }
> }
>   ]
> }
> 
> 
> 
> If we go by the RFC encoding rules, "params" contains the
> , which maps the "Table name" to an array of
>  object. So IMHO, the table names comes only once in the
> message. Correct?

Yes.  That's what I see above.  The table names are Physical_Locator and
Physical_Locator_Set, and each of them is mentioned once.
In the  object "Physical_Locator" is mapped to:

   {
 "columns": [
   "dst_ip",
   "encapsulation_type",
   "_uuid"
 ],
 "select": {
   "initial": true,
   "insert": true,
   "delete": true,
   "modify": true
 }
   }

and similarly for "Physical_Locator_Set".

> Also, it is explicitly mentioned that (as below) and it does NOT contain
> the "Table name" in it.
> 
> 
> Each  is an
> 
> object with the following members:
> 
>"columns": [*]optional
> 
>"select": optional
> 
> 
> However, in the message payload that I have, shows the tuple, which
> contains "Table : Columns : Select". This list of  constitute
> the  as per the RFC definition.
> 
> I see this as the discrepancy between the RFC definition and how the
> message is actually sent by the controller.

I don't understand what discrepancy you see.  Can you show an example,
for example by providing how you think the above example should actually
be encoded?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.9.0: priority=0 actions=CONTROLLER flow counts but doesn't output packets to the controller

[Ben Pfaff]

On Tue, Mar 06, 2018 at 06:54:30AM +, Josh Bailey via discuss wrote:
> Hoping I'm missing something obvious!
> 
> I have a flow like this:
> 
> $ grep CONTROLLER sab-dump-flows.log
>  cookie=0x5adc15c0, duration=63.446s, table=3, n_packets=60, n_bytes=3436,
> priority=0 actions=CONTROLLER:96
> 
> I can cause packets to match it, but no packets are output ot the
> controller.
> 
> faucet@faucet:/var/tmp/faucet-tests-1KL3eg/FaucetUntaggedTestZeroPriorityFlowsTest-test_untagged$
> tshark -l -n -Q -d tcp.port==40649,openflow -O openflow_v4 -Y
> "openflow_v4.packet_in.total_len>0" -r fa*cap|wc -l
> 0
> 
> If I specify any priority other than 0, it works (packets are output to
> controller via packet in messages).
> 
> Is there something special about priority=0 flows and the CONTROLLER action?

Yes, in fact OpenFlow specifies special cases for priority=0 flows that
match no fields.  It calls these "table-miss" flows, see e.g. section
5.4 in OpenFlow 1.5.1.  Open vSwitch has some explicit special-case code
for dealing with them.

I can't think of a particular reason why this special case would make a
difference for you.  Maybe there is a bug.  Do you have a way for us to
reproduce it?

Did you try "ofproto/trace"?  Maybe it will show a reason why the packet
is not sent to the controller.

(I'm at a conference this week, so my schedule is weird.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] mtu_request

[Ben Pfaff]

On Sat, Mar 03, 2018 at 08:32:17AM -0500, Chris Boley wrote:
> OVS:
> foo@VMHOST:~$ sudo ovs-vsctl show
> 126a4b57-4837-42a9-95d6-d818b35e95bd
>Bridge "vbridge0"
>Port "vnet0"
>tag: 2
>Interface "vnet0"
>Port "vbond0"
>Interface "eth2"
>Interface "eth1"
>Port "vbridge0"
>Interface "vbridge0"
>type: internal
>ovs_version: "2.5.2"
> 
> I've tried changing MTU parameters on my internal vbridge0 interface:
> 
> sudo ovs-vsctl set interface vbridge0 mtu=1520
> 
> This command runs, but does nothing to the MTU of my internal bridge
> interface.
> 
> There's supposed to be a separate command:
> ovs-vsctl set int vbridge0 mtu_request=1520

mtu_request was introduced in OVS 2.6.0 but you are using 2.5.2.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] bond control syntax

[Ben Pfaff]

On Sun, Mar 04, 2018 at 12:34:53PM -0500, Chris Boley wrote:
> Hi,
> I worked on this more and found that this worked. If anyone is actually
> interested.
> 
> sudo touch /etc/network/if-up.d/vbond0_tune
> sudo nano /etc/network/if-up.d/vbond0_tune
> 
> ##Pasted this in###
> 
> ovs-vsctl set port vbond0 other_config:lacp-system-priority=50
> other_config:bond-rebalance-interval=5000 other_config:
> bond-detect-mode=miimon other_config:bond-miimon-interval=100
> other_config:bond_updelay=200 other_config:bond_downdelay=200
> exit
> 
> ##save file and exit##
> 
> sudo chmod a+x /etc/network/if-up.d/vbond0_tune
> 
> modify interfaces file to look this way:
> allow-vbridge0 vbond0
> iface vbond0 inet manual
>ovs_bridge vbridge0
>ovs_type OVSBond
>ovs_bonds eth1 eth2
>ovs_options bond_mode=balance-slb lacp=active
>post-up /etc/network/if-up.d/vbond0_tune
> 
> After that I could run:
> foo@VMHOST:~$ sudo ovs-vsctl list port vbond0
> 
> And I could see all the "other_options"
> 
> The ovs-appctl bond/show vbond0 isn't really reflecting my up and down
> delay. I'm not sure though if that's because the Cisco Switch ports are
> taking priority or what's going on.

bond_updelay and bond_downdelay are columns rather than keys within
other_config, so you should be able to just remove "other_config:" from
those settings to make them work.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ARP request in openvswitch

[Ben Pfaff]

On Thu, Mar 01, 2018 at 12:27:07PM -0500, Myra Sh wrote:
> Is there any configuration for openvswitch to tells that how to send an ARP
> request?
> 
> In some cases, when openvswitch is not a neighbor of another openvswitch,
> instead of sending the request to the controller, broadcast ARP request and
> it is not correct. (in wireless networks)
> 
> Do you know how I can configure openvswitch for this kind of ARP requests?

Open vSwitch doesn't do ARP requests of its own, normally.  It only
switches them.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs route refresh problem

[Ben Pfaff]

On Fri, Feb 23, 2018 at 03:30:59AM +, Yinpeijun wrote:
> 
> >>On Sun, Feb 11, 2018 at 07:27:34AM +, Yinpeijun wrote:
> >> Hi all
> >> Recently , I run a test two VM commulication with 
> >> vxlan and ovs+dpdk networking(ovs2.7.2). when I add 200 virtual device 
> >> on the physical service  of the commulicate vm then check the ping result, 
> >>  there  is  loss packet statistics. Then I use vlan and ovs+dpdk 
> >> networking, do the same thing , there is no loss packets statistics.
> >> I read the source code and add some log to confirm the 
> >> problem,  the final problem I think is unreasonable routing refresh,  
> >> in route_table_rest function delete all items before readding, so in the 
> >> middle of the interval  ovs_router_lookup  can not find the route then 
> >> cause packet drop.  So I think the implementation need to optimize, Any 
> >> advice on how to optimize it?
> 
> >I don't fully understand your use case.  However, if you're not using DPDK, 
> >then OVS isn't doing routing in userspace so this is probably not the 
> >problem.
> 
> Thank you for your replay, the test case just for reproduce the problem. The 
> actual  scene is to create or migrate virtual machines in openstack env. 
> Correspondence will be created linux bridge
> and other virtual device.
> 
> There is also have problem in netdev dataptah without dpdk.  vxlan tunnel 
> need route in userspace and ovs maintain the route table as follow:
> ovs-appctl ovs/route/show
> Route Table:
> Cached: x.xx.1.10/32 dev eth0 SRC x.xx.1.10
> Cached: 10.0.0.10/32 dev brcps SRC 10.0.0.10
> Cached: 127.0.0.1/32 dev lo SRC 127.0.0.1
> 
> So when I create virtual device trigger ovs refresh the route then affect the 
> already existing virtual machine communication.

This is the same datapath, really, it's just that most people use it
with DPDK, and so the solution would be the same.

I think that the problem you're talking about can be fixed by holding
the mutex in route_table_reset() across the entire update, instead of
just for each individual operation on the routing table.  Does that make
sense?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Starting up Inband controller

[Ben Pfaff]

On Thu, Mar 01, 2018 at 02:16:39PM +, Soliman Awad Alshra´a Abdullah TU 
Ilmenau wrote:
> Hello everyone,
> 
> 
> I am trying to build my topology with In-band controller, So I started 
> running some available script
> 
>  On the one hand, I have no problem when I use these instructions on
> 
>  
> http://tocai.dia.uniroma3.it/compunet-wiki/index.php/In-band_control_with_Open_vSwitch
> 
> (sudo mn --topo linear,5 --switch ovsk,inband=True, 
> --controller=remote,ip=10.0.0.3)
> 
>  when I check the disable-in-band="true" by
> ( sudo ovs-vsctl --columns=other_config list bridge | grep "disable-in-band")
> 
> I get nothing as it is expected, and I can run the topology well.  (pingall)
> 
> 
> On the other hand, when I use the other topologies in (for example)
> 
>  https://techandtrains.com/2013/10/05/in-band-controller-with-mininet-p art-2/
> or
> https://github.com/hmd1st/mn_test/blob/master/inband_delay_link.py
> 
> I check the disable-in-band="true"
> I get  -->   other_config: {datapath-id="0001", 
> disable-in-band="true"}
> 
> OVS switches does not seem to try to connect to Ryu's host and I can't do 
> ping betwwen all hosts.
> my ovs is 2.0.2 which support Of 1.0 as default  so I uses  simple_switch.py 
> as a controller as well sa I upgraded my ovs and tried to use the suitable 
> controller( simple_switch_13.py ),  but nothing happens.
> >
> I know my problem might be simple, but I have no idea why I cannot start up 
> the controller well.
> 
> please, Could you guide me to my problem !

Well, in general, you can't expect an in-band controller to work if you
disable in-band controllers.

But OVS 2.0 is over 4 years old and you can't really expect us to
support it anyway.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [OVN] Python IDL: handling modify operations in update2 notifications is slow

[Ben Pfaff]

On Tue, Feb 27, 2018 at 03:56:40PM +0100, Daniel Alvarez Sanchez wrote:
> Hi all,
> 
> When working on the performance of the OVN OpenStack integration and
> following up this thread [0].
> 
> I went a bit deeper trying to find out the root cause of the linear growth.
> It happens that during the processing of the update2 messages, when there's
> a 'modify' operation, the data is converted to JSON [1] and then we build a
> Row from this JSON [2].
> 
> This seems pretty useless and, since the JSON document is not used anywhere
> else, I just avoided that conversion. This conversion takes longer as the
> number of elements in the row increases, which is the case of adding a new
> address to the Address_Set table or adding new ACLs to the acl column in
> Logical_Switch. This have a big impact at scale and it can be easily fixed.
> 
> After removing the extra conversions (I'll be submitting the patch in a
> while), the time for creating ports from OpenStack remains almost constant
> regardless of the amount of ports in the system as you can see in the
> attached image and further in this blogpost [3] and it's cut down
> considerably.

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

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Fri, Feb 23, 2018 at 03:51:28PM -0800, Han Zhou wrote:
> On Fri, Feb 23, 2018 at 2:17 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote:
> > > On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff <b...@ovn.org> wrote:
> > > >
> > > > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez
> wrote:
> > > > > @Han, I can try rebase the patch if you want but that was
> > > > > basically renaming the Address_Set table and from Ben's
> > > > > comment, it may be better to keep the name. Not sure,
> > > > > however, how we can proceed to address Lucas' points in
> > > > > this thread.
> > > >
> > > > I wouldn't rename the table.  It sounds like the priority should be to
> > > > add support for sets of port names.  I thought that there was already
> a
> > > > patch for that to be rebased, but maybe I misunderstood.
> > >
> > > I feel it is better to add a new table for port group explicitly, and
> the
> > > column type can be a set of weak reference to Logical_Switch_Port.
> > > The benefits are:
> > > - Better data integrity: deleting a lport automatically deletes from the
> > > port group
> > > - No confusion about the type of records in a single table
> > > - Existing Address_Set mechanism will continue to be supported without
> any
> > > change
> > > - Furthermore, the race condition issue brought up by Lucas can be
> solved
> > > by supporting port-group in IP address match condition in
> ovn-controller,
> > > so that all addresses in the lports are used just like how AddressSet is
> > > used today. And there is no need for Neutron networking-ovn to use
> > > AddressSet any more. Since addresses are deduced from lports, the
> ordering
> > > of deleting/adding doesn't matter any more.
> > >
> > > How does this sound?
> >
> > Will we want sets of Logical_Router_Ports later?
> At least I don't see any use case in Neutron for router ports since
> Security Group is only for VIF ports.
> 
> There is another tricky point I see while working on implementation. In
> Neutron, SG can be applied to ports across different networks, but in OVN
> lports works only on its own datapath, so in ovn-controller we need to be
> able to pickup related ports from the port-group when translating lflows
> for each datapath. I hope this is not an issue. Otherwise, Neutron plugin
> will have to divide the group of ports into sub-groups according to the
> lswitch they belong to, which would be a pain.

I think that we can make ovn-controller gracefully tolerate that.

Let's try this implementation.  I'm not excited about having a new table
for this purpose, but it sounds like the advantages may be worthwhile.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Cannot change vxlan egress (source) ports

[Ben Pfaff]

On Fri, Feb 16, 2018 at 12:50:57AM -0300, José Miguel Guzmán wrote:
> Hello
> 
> I need to change the range of source ports for VXLAN tunnels.
> 
> Although I tried with set dst_port to 2000
> # ovs-vsctl add-port br-ovs vxlan3 -- set interface vxlan3 type=vxlan
> options:remote_ip=192.168.111.203 options:dst_port=2
> 
> and egress port range to 2-20001
> # ovs-appctl tnl/egress_port_range 2 20001
> # ovs-appctl tnl/egress_port_range
> Tunnel UDP source port range: 2-20001

tnl/egress_port_range only influences the behavior of the DPDK-based
tunnel implementation in OVS.  If you're using the kernel implementation
of tunneling, it will have no effect.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] invalid Ethertype 0 in flow key

[Ben Pfaff]

This is an unusual problem that I haven't seen reported by others.  Is
there anything special about your machine, your kernel, your build,
etc.?

Whether you specify dst_port should not make a difference.  This is
implemented at a low level, so I don't know why it would change the
behavior you see.

On Sat, Feb 17, 2018 at 04:20:36AM +0500, Jamshaid Faisal wrote:
> hmm i got some more info actually
> if i use options:dst_port=x  in vxlan setup command above, i dont get
> those errors in log. It means i have to use dst_port
> however i read this in documents
> 
> "By default, Open vSwitch will use the assigned IANA port for VXLAN, which
> is 4789"
> 
> Whats really going on there, VXLAN works without specifying dst_port but
> with these errors in log.
> so should i use dst_port ?
> 
> On Sat, Feb 17, 2018 at 4:08 AM, Jamshaid Faisal  wrote:
> 
> > I got some more details, Here is exactly how to get it on a clean install
> >
> > rm -rf /etc/openvswitch/conf.db
> > service openvswitch restart
> > ovs-vsctl add-br mybridge
> > ovs-vsctl --may-exist add-port mybridge myport -- set interface myport
> > type=vxlan options:remote_ip=10.1.1.1
> >
> > And there you go, i start getting below lines in /var/log/messages
> >
> > ovs-vswitchd: ovs|1|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|2|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|3|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|4|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> > ovs-vswitchd: ovs|5|odp_util(revalidator18)|ERR|invalid Ethertype 0
> > in flow key
> >
> > What i am doing wrong?
> >
> > On Tue, Feb 13, 2018 at 1:10 AM, Jamshaid Faisal 
> > wrote:
> >
> >> Hello
> >>
> >> Lately i have seen a lot of below messages in log (/var/log/messages). It
> >> is happening no matter which OVS version i use. Below log is from ovs 2.7.2
> >>
> >>
> >> ===
> >> Feb 12 12:03:21 SGP1-1-10 ovs-vswitchd: 
> >> ovs|00135|odp_util(revalidator72)|ERR|Dropped
> >> 27 log messages in last 58 seconds (most recently, 3 seconds ago) due to
> >> excessive rate
> >> Feb 12 12:03:21 SGP1-1-10 ovs-vswitchd: 
> >> ovs|00136|odp_util(revalidator72)|ERR|invalid
> >> Ethertype 0 in flow key
> >> ===
> >>
> >>
> >> They even happens with minimum config without vxlan etc.
> >> I am using XEN and its hot-plug script vif-openvsiwtch. Openvswitch is
> >> compiled with default options.
> >>
> >> What does these messages really mean?
> >>
> >> I dont see any functional issues, VMs have network, VXLAN also works
> >> fine,  But why lot of above messages in log ?
> >>
> >> Please help.
> >>
> >> Regards
> >>
> >>
> >

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

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

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote:
> On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez wrote:
> > > @Han, I can try rebase the patch if you want but that was
> > > basically renaming the Address_Set table and from Ben's
> > > comment, it may be better to keep the name. Not sure,
> > > however, how we can proceed to address Lucas' points in
> > > this thread.
> >
> > I wouldn't rename the table.  It sounds like the priority should be to
> > add support for sets of port names.  I thought that there was already a
> > patch for that to be rebased, but maybe I misunderstood.
> 
> I feel it is better to add a new table for port group explicitly, and the
> column type can be a set of weak reference to Logical_Switch_Port.
> The benefits are:
> - Better data integrity: deleting a lport automatically deletes from the
> port group
> - No confusion about the type of records in a single table
> - Existing Address_Set mechanism will continue to be supported without any
> change
> - Furthermore, the race condition issue brought up by Lucas can be solved
> by supporting port-group in IP address match condition in ovn-controller,
> so that all addresses in the lports are used just like how AddressSet is
> used today. And there is no need for Neutron networking-ovn to use
> AddressSet any more. Since addresses are deduced from lports, the ordering
> of deleting/adding doesn't matter any more.
> 
> How does this sound?

Will we want sets of Logical_Router_Ports later?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Is a new field in flow.h necessary for matching on a custom v6 extension header?

[Ben Pfaff]

Ultimately, I expect a P4-based solution, in which the controller
supplies a P4 program that extracts the fields that it is interested in.
This is my big project for OVS 2.10.  (I don't know how successful I'll
be yet.)

On Fri, Feb 23, 2018 at 12:37:40AM +0100, Alan Kayahan wrote:
> I understand that there must be a construct in the struct flow, and
> introducing a new be32 will save the day for me. However looking at this
> from a broader perspective, say matching on the fields of any v6 extension
> header made into the OF specification, neither adding individual fields nor
> adding every v6 extension header into the struct flow looks elegant to me.
> What do you think?
> 
> 2018-02-21 17:10 GMT+01:00 Ben Pfaff <b...@ovn.org>:
> 
> > On Mon, Feb 19, 2018 at 06:15:30PM +0100, Alan Kayahan wrote:
> > > I have a custom v6 extension header, in which I would like to perform an
> > > LPM match on only one 32bit field.
> > >
> > > Since an extension header is technically not a new field, do I still need
> > > to introduce anything in the struct flow?
> >
> > Without anything in struct flow, how do you propose to match on it?
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez wrote:
> @Han, I can try rebase the patch if you want but that was
> basically renaming the Address_Set table and from Ben's
> comment, it may be better to keep the name. Not sure,
> however, how we can proceed to address Lucas' points in
> this thread.

I wouldn't rename the table.  It sounds like the priority should be to
add support for sets of port names.  I thought that there was already a
patch for that to be rebased, but maybe I misunderstood.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS doesn't apply action in packet_out message

[Ben Pfaff]

On Mon, Feb 19, 2018 at 06:31:20PM -0500, S hj wrote:
> I have some OVSs connected to ONOS controller.
> OVS1---OVS2OVS3
> 
> when OVS1 wants to send packets to OVS3, OVS2 sends packet_in messages to
> the controller including ARP message and ONOS sends packet_out messages
> contain OFPP_FLOOD as an action.
> 
> However, OVS2 doesn't flood the flow toward the OVS3.
> Is there any way to find out why OVS2 by receiving the packet_out,
> doesn't apply the action on the flow?

You could use "ofproto/trace-packet-out" as described in
ovs-vswitchd(8).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] dcsp band

[Ben Pfaff]

On Fri, Feb 16, 2018 at 04:51:27PM +0100, Mohamed Taj Eddine HAMZA wrote:
> I can t use the DSCP remark band with meter, I got an error saying
> BAD_BAND!! , is there any solution ? I will be grateful if you help
> me,

Only "drop" meters are supported.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Thu, Feb 15, 2018 at 01:38:04PM -0800, Han Zhou wrote:
> On Thu, Feb 15, 2018 at 12:56 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > On Thu, Feb 15, 2018 at 06:50:15PM +, Lucas Alvares Gomes wrote:
> > > Hi all,
> > >
> > > We currently have a problem with Address_Set in networking-ovn (and
> > > potentially other technologies using OVN as backend) which *maybe*
> > > could be fixed together with this idea of a new "port set" (a.k.a
> > > macro set).
> > >
> > > The problem is bit tricky but it shows as a race condition between
> > > creating and deleting ports in Neutron. That is, deleting a port in
> > > Neutron will result in the IP address of that port to be removed from
> > > an address set, but at the same time, if another request to create a
> > > port overtaking the same IP address of the port being deleted is
> > > issued, depending on which order things are committed it could result
> > > in the address set to not contain the new port IP address.
> > >
> > > Here's a bug ticket describing the problem in more detail:
> > > https://bugs.launchpad.net/networking-ovn/+bug/1611852
> > >
> > > The reason why it happens is because we don't have a direct
> > > relationship between the addresses in an address set and the ports
> > > that those addresses belongs to. So, if we create this relation we
> > > might end up having both ports and addresses present in the
> > > Address_Set table which then can be used to fix both of our problems.
> >
> > It seems very odd to me that Neutron can commit things out of order.  If
> > the OVSDB schema for Address_Set were slightly different, this would
> > even be a constraint violation that would cause the create operation to
> > fail if it were executed before the delete operation.  I wouldn't be
> > surprised if other operations could be reordered in a way that would
> > cause such a failure.  I'll be disappointed if we solve this specific
> > problem and then multiple other examples of the same general problem
> > appear.
> >
> > Here is the best idea that has come to my mind so far: use key-value
> > pairs in the "external-ids" column to indicate which port owns which
> > address.  At time of port insertion, Neutron add the key; at time of
> > port deletion it only removes an address if the deleted port owned it.
> > (This is doable in an atomic fashion with the existing OVSDB protocol,
> > or at least it is possible to abort the transaction if the deleted port
> > does not own it.)
> >
> The external-ids approach would require going through the whole
> external-ids list to see if there is any other owners for the same address
> when we are trying to delete one, which may be inefficient. Also it seems
> to introduce too much redundant data, since we are repeating the addresses
> in external-ids.

I don't think that this argument about inefficiency is likely to be
true; it's simply an in-memory search.  I find the latter argument more
persuasive, since redundancy often indicates weakness in a design.

> > > Here's some ideas:
> > >
> > > # 1. A new map column
> > >
> > > We could add a "map" type column called "ports" in the Address_Set
> > > table that would look like this in the database:
> > >
> > > "Address_Set": {
> > >   "ports": {"port-1-name": {"ipv4_addresses": [...],
> > >  "ipv6_addresses": [...}}
> > >   ...
> > > }
> >
> > This particular solution seems to me like it solves a very specific
> > problem.  I'd rather solve a more general problem if we can.
> >
> > > # 2: Add a new way to populate the address set:
> > >
> > > Instead of directly populating the addresses in an address set where
> > > the port relationship isn't clear, we could add two list of ports
> > > references (one for each IP version) and have the addresses
> > > automatically populated.
> > >
> > > For example:
> > >
> > > "Address_Set": {
> > >   "columns": {
> > > "ipv4_ports": {"type": {"key": {"type": "uuid",
> > > "refTable": "Logical_Switch_Port",
> > > "refType": "weak"},
> > > "min": 0,
> > >   

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Thu, Feb 15, 2018 at 06:50:15PM +, Lucas Alvares Gomes wrote:
> Hi all,
> 
> We currently have a problem with Address_Set in networking-ovn (and
> potentially other technologies using OVN as backend) which *maybe*
> could be fixed together with this idea of a new "port set" (a.k.a
> macro set).
> 
> The problem is bit tricky but it shows as a race condition between
> creating and deleting ports in Neutron. That is, deleting a port in
> Neutron will result in the IP address of that port to be removed from
> an address set, but at the same time, if another request to create a
> port overtaking the same IP address of the port being deleted is
> issued, depending on which order things are committed it could result
> in the address set to not contain the new port IP address.
> 
> Here's a bug ticket describing the problem in more detail:
> https://bugs.launchpad.net/networking-ovn/+bug/1611852
> 
> The reason why it happens is because we don't have a direct
> relationship between the addresses in an address set and the ports
> that those addresses belongs to. So, if we create this relation we
> might end up having both ports and addresses present in the
> Address_Set table which then can be used to fix both of our problems.

It seems very odd to me that Neutron can commit things out of order.  If
the OVSDB schema for Address_Set were slightly different, this would
even be a constraint violation that would cause the create operation to
fail if it were executed before the delete operation.  I wouldn't be
surprised if other operations could be reordered in a way that would
cause such a failure.  I'll be disappointed if we solve this specific
problem and then multiple other examples of the same general problem
appear.

Here is the best idea that has come to my mind so far: use key-value
pairs in the "external-ids" column to indicate which port owns which
address.  At time of port insertion, Neutron add the key; at time of
port deletion it only removes an address if the deleted port owned it.
(This is doable in an atomic fashion with the existing OVSDB protocol,
or at least it is possible to abort the transaction if the deleted port
does not own it.)

> Here's some ideas:
> 
> # 1. A new map column
> 
> We could add a "map" type column called "ports" in the Address_Set
> table that would look like this in the database:
> 
> "Address_Set": {
>   "ports": {"port-1-name": {"ipv4_addresses": [...],
>  "ipv6_addresses": [...}}
>   ...
> }

This particular solution seems to me like it solves a very specific
problem.  I'd rather solve a more general problem if we can.

> # 2: Add a new way to populate the address set:
> 
> Instead of directly populating the addresses in an address set where
> the port relationship isn't clear, we could add two list of ports
> references (one for each IP version) and have the addresses
> automatically populated.
> 
> For example:
> 
> "Address_Set": {
>   "columns": {
> "ipv4_ports": {"type": {"key": {"type": "uuid",
> "refTable": "Logical_Switch_Port",
> "refType": "weak"},
> "min": 0,
> "max": "unlimited"}}
> "ipv6_ports": {"type": {"key": {"type": "uuid",
> "refTable": "Logical_Switch_Port",
> "refType": "weak"},
> "min": 0,
> "max": "unlimited"}}
>  ...
> }
> 
> The problem here is that we would pull all addresses from those ports
> into the address set.
> 
> The good part is that since it's a weak reference, deleting a port
> would automatically remove it from the address set.

This is creative and I appreciate it.  It also seems very specific to
this particular problem.

> # 3: Allow duplicated addresses in the list
> 
> If the above options sounds too complicated, maybe we could keep the
> idea of this email of creating a "Macro_Set" that could be used for
> both ports and addresses types [0]. But, when the type is set to
> "address" we could allow duplicated items in the list of elements that
> way we won't have a problem if one transaction removes one duplicated
> element in the list.
> 
> [0] https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html

I am closer to being comfortable with this solution.  The specific
solution cannot work because OVSDB doesn't support duplicates in its
"set" types.

We could extend the current Address_Set to resemble this solution by
removing the constraint that the address set's name be unique and making
ovn-northd and ovn-controller merge addresses from rows with duplicate
names.  Neutron could use the "external-ids" column to track which port
owns which row.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OF Metering in ovsswitch

[Ben Pfaff]

On Thu, Feb 15, 2018 at 04:21:03PM +0530, AKSHAYA BALAN wrote:
> We are trying to explore openflow metering in openvswitch. Most of the
> available links in internet figured that metering is not supported in ovs.
> But ovs-ofctl have add-meter command. Kindly guide us on how we can use it
> 
> We are using ovs switch version 2.5 and openflow version from 10 to 13.
> When we tried to use this add-meter command,  we got some error related to
> openflow version , which is attached with this mail.

The FAQ says:

Q: Does Open vSwitch support OpenFlow meters?

A: Since version 2.0, Open vSwitch has OpenFlow protocol support for
OpenFlow meters.  Currently, only the userspace datapath implements
meters.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs route refresh problem

[Ben Pfaff]

On Sun, Feb 11, 2018 at 07:27:34AM +, Yinpeijun wrote:
> Hi all
> Recently , I run a test two VM commulication with vxlan and 
> ovs+dpdk networking(ovs2.7.2). when I add 200 virtual device on the physical 
> service  of
> the commulicate vm then check the ping result,  there  is  loss packet 
> statistics. Then I use vlan and ovs+dpdk networking, do the same thing , 
> there is no loss
> packets statistics.
> I read the source code and add some log to confirm the 
> problem,  the final problem I think is unreasonable routing refresh,  in 
> route_table_rest function
> delete all items before readding, so in the middle of the interval  
> ovs_router_lookup  can not find the route then cause packet drop.  So I think 
> the implementation
> need to optimize, Any advice on how to optimize it?

I don't fully understand your use case.  However, if you're not using
DPDK, then OVS isn't doing routing in userspace so this is probably not
the problem.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Thu, Feb 15, 2018 at 12:36:35AM +0100, Daniel Alvarez Sanchez wrote:
> If we would have the Port_Set we could simply write the match part as
> "outport == $security_group1 && ip4 && ip4.src == 0.0.0.0/0 && tcp &&
> tcp.dst == 22"
> and reduce the number of ACLs to 1 per security group rule instead of 1 per
> security
> group rule per port as it is right now. As you can see, we're referencing
> the relevant security group rule in the CMS through the
> neutron:security_group_rule_id
> key in the external_ids column so we would reduce all ACLs which correspond
> to
> the same SG rule to just 1.

OK, that matches up with what Han says.  Han is going to rebase the
"port set" patches, so I think we'll have a solution for this soon after
that.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Wed, Feb 14, 2018 at 03:45:21PM -0800, Han Zhou wrote:
> On Wed, Feb 14, 2018 at 3:39 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > On Wed, Feb 14, 2018 at 03:29:34PM -0800, Han Zhou wrote:
> > > On Wed, Feb 14, 2018 at 3:08 PM, Ben Pfaff <b...@ovn.org> wrote:
> > > >
> > > > On Wed, Feb 14, 2018 at 02:25:56PM -0800, Han Zhou wrote:
> > > > > On Wed, Feb 14, 2018 at 1:40 PM, Ben Pfaff <b...@ovn.org> wrote:
> > > > > >
> > > > > > On Wed, Feb 14, 2018 at 12:34:19PM -0800, Han Zhou wrote:
> > > > > > > I remember there was a patch for ACL group in OVN, so that
> instead
> > > of
> > > > > R*P
> > > > > > > rows we will have only R + P rows, but didn't see it went
> through.
> > > > > >
> > > > > > I don't remember that.  Any chance you could point me to it?
> > > > >
> > > > > Yes, I found it:
> > > > >
> > > > >
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html
> > > > >
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/321165.html
> > > > >
> > > > > And I made a mistake in my previous text. It is about port group,
> which
> > > is
> > > > > what we need here, rather than ACL group.
> > > >
> > > > I guess what I'd like to see is an example of the problem that we're
> > > > trying to solve here: what does a typical ACL row for a security group
> > > > look like, and what parts of the row differ between its instance for
> one
> > > > port and another port?
> > >
> > > An ACL for a Neutron SG rule: ingress tcp dport=22, is something like:
> > > to-lport 1000 "outport==\"\" && ip4 && tcp &&
> > > tcp.dst==22" allow-related
> > >
> > > All ports bound to the same SG will have an ACL like this, and the only
> > > difference between one port and another is the  part.
> >
> > Well, then it's really easy to merge all of them if we accept Zong's
> > patches above or something similar.  I had no idea!
> >
> > Is anyone willing to rebase those patches against current master?  I had
> > some feedback on them that wasn't ever addressed (and I'd probably have
> > a little more), which is the only reason that they weren't committed as
> > far as I can tell.
> 
> Cool. I'd be happy to rebase them, probably next week.

Thanks.

I think that we shouldn't change the name of the table, by the way.
Address_Set is somewhat of a misnomer once we allow sets of ports, but
it's good enough and changing table names is a pain.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Wed, Feb 14, 2018 at 03:29:34PM -0800, Han Zhou wrote:
> On Wed, Feb 14, 2018 at 3:08 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > On Wed, Feb 14, 2018 at 02:25:56PM -0800, Han Zhou wrote:
> > > On Wed, Feb 14, 2018 at 1:40 PM, Ben Pfaff <b...@ovn.org> wrote:
> > > >
> > > > On Wed, Feb 14, 2018 at 12:34:19PM -0800, Han Zhou wrote:
> > > > > I remember there was a patch for ACL group in OVN, so that instead
> of
> > > R*P
> > > > > rows we will have only R + P rows, but didn't see it went through.
> > > >
> > > > I don't remember that.  Any chance you could point me to it?
> > >
> > > Yes, I found it:
> > >
> > > https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html
> > > https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/321165.html
> > >
> > > And I made a mistake in my previous text. It is about port group, which
> is
> > > what we need here, rather than ACL group.
> >
> > I guess what I'd like to see is an example of the problem that we're
> > trying to solve here: what does a typical ACL row for a security group
> > look like, and what parts of the row differ between its instance for one
> > port and another port?
> 
> An ACL for a Neutron SG rule: ingress tcp dport=22, is something like:
> to-lport 1000 "outport==\"\" && ip4 && tcp &&
> tcp.dst==22" allow-related
> 
> All ports bound to the same SG will have an ACL like this, and the only
> difference between one port and another is the  part.

Well, then it's really easy to merge all of them if we accept Zong's
patches above or something similar.  I had no idea!

Is anyone willing to rebase those patches against current master?  I had
some feedback on them that wasn't ever addressed (and I'd probably have
a little more), which is the only reason that they weren't committed as
far as I can tell.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Wed, Feb 14, 2018 at 02:25:56PM -0800, Han Zhou wrote:
> On Wed, Feb 14, 2018 at 1:40 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > On Wed, Feb 14, 2018 at 12:34:19PM -0800, Han Zhou wrote:
> > > I remember there was a patch for ACL group in OVN, so that instead of
> R*P
> > > rows we will have only R + P rows, but didn't see it went through.
> >
> > I don't remember that.  Any chance you could point me to it?
> 
> Yes, I found it:
> 
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/321165.html
> 
> And I made a mistake in my previous text. It is about port group, which is
> what we need here, rather than ACL group.

I guess what I'd like to see is an example of the problem that we're
trying to solve here: what does a typical ACL row for a security group
look like, and what parts of the row differ between its instance for one
port and another port?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Wed, Feb 14, 2018 at 12:34:19PM -0800, Han Zhou wrote:
> I remember there was a patch for ACL group in OVN, so that instead of R*P
> rows we will have only R + P rows, but didn't see it went through.

I don't remember that.  Any chance you could point me to it?

> Is this also a good use case of conjuncture?

Maybe, but that happens at a different level of the system.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Wed, Feb 14, 2018 at 11:27:11AM +0100, Daniel Alvarez Sanchez wrote:
> Thanks for your inputs. I need to look more carefully into the patch you
> submitted but it looks like, at least, we'll be reducing the number of
> calls to Datum.__cmp__ which should be good.

Thanks.  Please do take a look.  It's a micro-optimization but maybe
it'll help?

> I probably didn't explain it very well. Right now we have N processes
> for Neutron server (in every node). Each of those opens a connection
> to NB db and they subscribe to updates from certain tables. Each time
> a change happens, ovsdb-server will send N update2 messages that has
> to be processed in this "expensive" way by each of those N
> processes. My proposal (yet to be refined) would be to now open N+1
> connections to ovsdb-server and only subscribe to notifications from 1
> of those. So every time a new change happens, ovsdb-server will send 1
> update2 message. This message will be processed (using Py IDL as we do
> now) and once processed, send it (mcast maybe?) to the rest N
> processes. This msg could be simply a Python object serialized and
> we'd be saving all this Datum, Atom, etc. processing by doing it just
> once.

OK.  It's an optimization that does the work in one place rather than N
places, so definitely a win from a CPU cost point of view, but it trades
performance for increased complexity.  It sounds like performance is
really important so maybe the increased complexity is a fair trade.

We might also be able to improve performance by using native code for
some of the work.  Were these tests done with the native code JSON
parser that comes with OVS?  It is dramatically faster than the Python
code.

> On Tue, Feb 13, 2018 at 8:32 PM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > Can you sketch the rows that are being inserted or modified when a port
> > is added?  I would expect something like this as a minimum:
> >
> > * Insert one Logical_Switch_Port row.
> >
> > * Add pointer to Logical_Switch_Port to ports column in one row
> >   in Logical_Switch.
> >
> > In addition it sounds like currently we're seeing:
> >
> > * Add one ACL row per security group rule.
> >
> > * Add pointers to ACL rows to acls column in one row in
> >   Logical_Switch.
> >
> This is what happens when we create a port in OpenStack (without
> binding it) which belongs to a SG which allows ICMP and SSH traffic
> and drops the rest [0]
> 
> Basically, you were right and only thing missing was adding the new
> address to the Address_Set table.

OK.

It sounds like the real scaling problem here is that for R security
group rules and P ports, we have R*P rows in the ACL table.  Is that
correct?  Should we aim to solve that problem?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

[Ben Pfaff]

On Tue, Feb 13, 2018 at 12:39:56PM +0100, Daniel Alvarez Sanchez wrote:
> Hi folks,
> 
> As we're doing some performance tests in OpenStack using OVN,
> we noticed that as we keep creating ports, the time for creating a
> single port increases. Also, ovn-northd CPU consumption is quite
> high (see [0] which shows the CPU consumption when creating
> 1000 ports and deleting them. Last part where CPU is at 100% is
> when all the ports get deleted).
> 
> With 500 ports in the same Logical Switch, I did some profiling
> of OpenStack neutron-server adding 10 more ports to that Logical
> Switch. Currently, neutron-server spawns different API workers
> (separate processes) which open connections to OVN NB so every
> time an update message is sent from ovsdb-server it'll be processed
> by all of them.
> 
> In my profiling, I used GreenletProfiler in all those processes to produce
> a trace file and then merged all of them together to aggregate the
> results. In those tests I used OVS master branch compiled it with
> shared libraries to make use of the JSON C parser. Still, I've seen
> that most of the time's been spent in the following two modules:
> 
> - python/ovs/db/data.py:  33%
> - uuid.py:  21%
> 
> For the data.py module, this is the usage (self time):
> 
> Atom.__lt__   16.25% 8283 calls
> from_json:118  6.18%   406935 calls
> Atom.__hash__  3.48%  1623832 calls
> from_json:328  2.01% 5040 calls
> 
> While for the uuid module:
> 
> UUID.__cmp__   12.84%  3570975 calls
> UUID.__init__   4.06%   362541 calls
> UUID.__hash__   2.96% 1800 calls
> UUID.__str__1.03%   355016 calls
> 
> Most of the calls to Atom.__lt__ come from
> BaseOvnIdl.__process_update2(idl.py)
> -> BaseOvnIdl.__row_update(idl.py) -> Datum.__cmp__(data.py) ->
> Atom.__cmp__(data.py).

I don't know Python well enough to whether these are "real" or correct
optimizations, but the following strike me as possible low-hanging fruit
micro-optimizations:

diff --git a/python/ovs/db/data.py b/python/ovs/db/data.py
index 9e57595f7513..dc816f64708f 100644
--- a/python/ovs/db/data.py
+++ b/python/ovs/db/data.py
@@ -76,12 +76,12 @@ class Atom(object):
 def __eq__(self, other):
 if not isinstance(other, Atom) or self.type != other.type:
 return NotImplemented
-return True if self.value == other.value else False
+return self.value == other.value
 
 def __lt__(self, other):
 if not isinstance(other, Atom) or self.type != other.type:
 return NotImplemented
-return True if self.value < other.value else False
+return self.value < other.value
 
 def __cmp__(self, other):
 if not isinstance(other, Atom) or self.type != other.type:

We could also reduce the number of calls to Datum.__cmp__ by recognizing
that if we've already found one change we don't have to do any more
comparisons, something like this:

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index 60548bcf50b6..2e550adfdf1c 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -447,6 +447,7 @@ class Idl(object):
 raise error.Error(" is not an object",
   table_updates)
 
+changed = False
 for table_name, table_update in six.iteritems(table_updates):
 table = self.tables.get(table_name)
 if not table:
@@ -472,8 +473,8 @@ class Idl(object):
   % (table_name, uuid_string))
 
 if version == OVSDB_UPDATE2:
-if self.__process_update2(table, uuid, row_update):
-self.change_seqno += 1
+changed = self.__process_update2(table, uuid, row_update,
+ changed)
 continue
 
 parser = ovs.db.parser.Parser(row_update, "row-update")
@@ -485,12 +486,12 @@ class Idl(object):
 raise error.Error(' missing "old" and '
   '"new" members', row_update)
 
-if self.__process_update(table, uuid, old, new):
-self.change_seqno += 1
+changed = self.__process_update(table, uuid, old, new, changed)
+if changed:
+self.change_seqno += 1
 
-def __process_update2(self, table, uuid, row_update):
+def __process_update2(self, table, uuid, row_update, changed):
 row = table.rows.get(uuid)
-changed = False
 if "delete" in row_update:
 if row:
 del table.rows[uuid]
@@ -511,9 +512,8 @@ class Idl(object):
 else:
 row_update = row_update['initial']
 self.__add_default(table, row_update)
-if self.__row_update(table, row, row_update):
-changed = True
-self.notify(ROW_CREATE, row)
+changed = self.__row_update(table, row, row_update, 

Re: [ovs-discuss] A bug on openswitch

[Ben Pfaff]

Please trace the actual flow that shows up in dump-flows.

On Wed, Feb 07, 2018 at 09:16:34AM +0800, a* wrote:
> Using ofproto/trace tracking, the feedback datapath port is correct, but the 
> port that is forwarded in ovs-dpctl is wrong.
> 
> 
> ofproto/trace
> Datapath actions: 
> set(eth(src=00:00:00:00:00:00,dst=00:0b:82:a6:45:50)),set(ipv4(src=0.0.0.0/128.0.0.0,dst=192.168.1.129)),set(tcp(src=0,dst=8080)),1
> The datapath actions output to datapath port 1.
> ovs-dpctl dump-flows
> recirc_id(0),in_port(4),eth(src=78:02:f8:29:cb:58,dst=00:0b:82:92:21:db),eth_type(0x0800),ipv4(src=192.168.1.64/255.255.255.192,dst=203.100.92.31,proto=6,frag=no),tcp(src=59765,dst=80),
>  packets:4, bytes:296, used:3.980s, flags:S, 
> actions:set(eth(src=78:02:f8:29:cb:58,dst=00:0b:82:a6:45:50)),set(ipv4(src=192.168.1.64/255.255.255.192,dst=192.168.1.129)),set(tcp(src=59765,dst=8080)),2
> The datapath actions output to datapath port 2.
> 
> 
> 
> Now can you understand what the problem is?
> 
> 
> --
> 
> 
> 博学之，审问之，慎思之，明辨之，笃行之。
> 
> Albert Xie
> 
> 
> 
> At 2018-02-07 01:39:51, "Ben Pfaff" <b...@ovn.org> wrote:
> >I don't see the problem.  The datapath actions output to datapath port
> >1, which is br-lan0_zone0, e.g. LOCAL.
> >
> >On Tue, Feb 06, 2018 at 09:24:36AM +0800, a* wrote:
> >> ovs-appctl ofproto/trace br-lan0_zone0 "in_port=2,tcp,tp_dst=80" -generate
> >> 
> >> 
> >> Bridge: br-lan0_zone0
> >> Flow: 
> >> tcp,in_port=2,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=80,tcp_flags=0
> >> 
> >> 
> >> Rule: table=0 cookie=0x1 priority=3,tcp,in_port=2,tp_dst=80
> >> OpenFlow 
> >> actions=learn(table=0,idle_timeout=60,hard_timeout=120,priority=100,in_port=LOCAL,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],eth_type=0x800,nw_proto=6,tcp_src=8080,NXM_OF_TCP_DST[]=NXM_OF_TCP_SRC[],load:NXM_OF_IP_DST[]->NXM_OF_IP_SRC[],load:NXM_OF_ETH_DST[]->NXM_OF_ETH_SRC[],load:NXM_OF_TCP_DST[]->NXM_OF_TCP_SRC[],output:NXM_OF_IN_PORT[]),mod_dl_dst:00:0b:82:a6:45:50,mod_nw_dst:192.168.1.129,mod_tp_dst:8080,LOCAL
> >> 
> >> 
> >> Final flow: 
> >> tcp,in_port=2,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:0b:82:a6:45:50,nw_src=0.0.0.0,nw_dst=192.168.1.129,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=8080,tcp_flags=0
> >> Megaflow: 
> >> recirc_id=0,tcp,in_port=2,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0/1,nw_dst=0.0.0.0,nw_frag=no,tp_src=0,tp_dst=80
> >> Datapath actions: 
> >> set(eth(src=00:00:00:00:00:00,dst=00:0b:82:a6:45:50)),set(ipv4(src=0.0.0.0/128.0.0.0,dst=192.168.1.129)),set(tcp(src=0,dst=8080)),1
> >> 
> >> 
> >> This problem is accidental, but the frequency is relatively high. I 
> >> tracked this problem, but I could not know where the flow was modified.
> >> I saw a problem in the OVS discussion group, about the mismatch of 
> >> behavior when using lxia to 
> >> test.(https://mail.openvswitch.org/pipermail/ovs-discuss/2017-April/044130.html)
> >> It looks like a similar problem. I think there may be some logical errors 
> >> inside the OVS. I believe that in your environment, as long as patient 
> >> testing, it is easy to reappear.
> >> Please take it seriously, and I want to know how this problem comes into 
> >> being.
> >> 
> >> 
> >> --
> >> 
> >> 
> >> 博学之，审问之，慎思之，明辨之，笃行之。
> >> 
> >> Albert Xie
> >> 
> >> 
> >> 
> >> At 2018-02-06 01:04:16, "Ben Pfaff" <b...@ovn.org> wrote:
> >> >I suggest using ofproto/trace to figure it out.  See ovs-vswitchd(8) for
> >> >details.
> >> >
> >> >On Sat, Feb 03, 2018 at 07:42:10PM +0800, a* wrote:
> >> >> Hi,all
> >> >> 
> >> >> 
> >> >> I recently found a bug about OVS, which was supposed to be sent to 
> >> >> local but was sent to eth0!
> >> >> Can you tell me why? I need help, thank you very much.
> >> >> 
> >> >> 
> >> >> recirc_id(0),in_port(4),eth(src=78:02:f8:29:cb:58,dst=00:0b:82:92:21:db),eth_type(0x0800),ipv4(src=192.168.1.64/255.255.255.192,dst=203.100.92.31,proto=6,frag=no),tcp(src=59765,dst=80),
> >> >>  packets:4, bytes:296, used:3.980s, flags:S, 
> >> >> actions:set(eth(src=78:02:f8:29:cb:58,dst=00:0b:82:a6:45:50)),set(ipv4(src=192.168.1.64/255.255.255.192,dst=192.168.1.12

Re: [ovs-discuss] Have to write whole path for using utilities

[Ben Pfaff]

On Wed, Feb 07, 2018 at 02:27:20PM +0800, Attitude Killer wrote:
> I cloned ovs from github. When I use this command "ovsdb-tool create
> /usr/local/etc/openvswitch/conf.db \  vswitchd/vswitch.ovsschema"
> 
> I get an error saying :* "The program 'ovsdb-tool' is currently not
> installed. You can install it by typing:*
> *sudo apt install openvswitch-switch"*
> 
> 
> Installing openvswitch-switch via apt installs 2.5 version of ovs whereas I
> want to use 2.8.1.
> 
> I make it work by writing the whole path to the ovsdb folder and also the
> same happens with using utilities. For example:
> 
> *$ /home/att/ovs/utilities/ovs-vsctl --version*
> 
> Please help me with the solution of this problem.

It sounds like you didn't install OVS.  The installation instructions
are in Documentation/intro/install/general.rst.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] A bug on openswitch

[Ben Pfaff]

I don't see the problem.  The datapath actions output to datapath port
1, which is br-lan0_zone0, e.g. LOCAL.

On Tue, Feb 06, 2018 at 09:24:36AM +0800, a* wrote:
> ovs-appctl ofproto/trace br-lan0_zone0 "in_port=2,tcp,tp_dst=80" -generate
> 
> 
> Bridge: br-lan0_zone0
> Flow: 
> tcp,in_port=2,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=80,tcp_flags=0
> 
> 
> Rule: table=0 cookie=0x1 priority=3,tcp,in_port=2,tp_dst=80
> OpenFlow 
> actions=learn(table=0,idle_timeout=60,hard_timeout=120,priority=100,in_port=LOCAL,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],eth_type=0x800,nw_proto=6,tcp_src=8080,NXM_OF_TCP_DST[]=NXM_OF_TCP_SRC[],load:NXM_OF_IP_DST[]->NXM_OF_IP_SRC[],load:NXM_OF_ETH_DST[]->NXM_OF_ETH_SRC[],load:NXM_OF_TCP_DST[]->NXM_OF_TCP_SRC[],output:NXM_OF_IN_PORT[]),mod_dl_dst:00:0b:82:a6:45:50,mod_nw_dst:192.168.1.129,mod_tp_dst:8080,LOCAL
> 
> 
> Final flow: 
> tcp,in_port=2,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:0b:82:a6:45:50,nw_src=0.0.0.0,nw_dst=192.168.1.129,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=8080,tcp_flags=0
> Megaflow: 
> recirc_id=0,tcp,in_port=2,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0/1,nw_dst=0.0.0.0,nw_frag=no,tp_src=0,tp_dst=80
> Datapath actions: 
> set(eth(src=00:00:00:00:00:00,dst=00:0b:82:a6:45:50)),set(ipv4(src=0.0.0.0/128.0.0.0,dst=192.168.1.129)),set(tcp(src=0,dst=8080)),1
> 
> 
> This problem is accidental, but the frequency is relatively high. I tracked 
> this problem, but I could not know where the flow was modified.
> I saw a problem in the OVS discussion group, about the mismatch of behavior 
> when using lxia to 
> test.(https://mail.openvswitch.org/pipermail/ovs-discuss/2017-April/044130.html)
> It looks like a similar problem. I think there may be some logical errors 
> inside the OVS. I believe that in your environment, as long as patient 
> testing, it is easy to reappear.
> Please take it seriously, and I want to know how this problem comes into 
> being.
> 
> 
> --
> 
> 
> 博学之，审问之，慎思之，明辨之，笃行之。
> 
> Albert Xie
> 
> 
> 
> At 2018-02-06 01:04:16, "Ben Pfaff" <b...@ovn.org> wrote:
> >I suggest using ofproto/trace to figure it out.  See ovs-vswitchd(8) for
> >details.
> >
> >On Sat, Feb 03, 2018 at 07:42:10PM +0800, a* wrote:
> >> Hi,all
> >> 
> >> 
> >> I recently found a bug about OVS, which was supposed to be sent to local 
> >> but was sent to eth0!
> >> Can you tell me why? I need help, thank you very much.
> >> 
> >> 
> >> recirc_id(0),in_port(4),eth(src=78:02:f8:29:cb:58,dst=00:0b:82:92:21:db),eth_type(0x0800),ipv4(src=192.168.1.64/255.255.255.192,dst=203.100.92.31,proto=6,frag=no),tcp(src=59765,dst=80),
> >>  packets:4, bytes:296, used:3.980s, flags:S, 
> >> actions:set(eth(src=78:02:f8:29:cb:58,dst=00:0b:82:a6:45:50)),set(ipv4(src=192.168.1.64/255.255.255.192,dst=192.168.1.129)),set(tcp(src=59765,dst=8080)),2
> >> 
> >> 
> >> system@ovs-system:
> >> lookups: hit:4226 missed:543 lost:0
> >> flows: 14
> >> masks: hit:22261 total:8 hit/pkt:4.67
> >> port 0: ovs-system (internal)
> >> port 1: br-lan0_zone0 (internal)
> >> port 2: eth0
> >> port 3: ath0
> >> port 4: ath1
> >> 
> >> 
> >> 
> >> 
> >> cookie=0x1, duration=444.585s, table=0, n_packets=1224, n_bytes=232770, 
> >> idle_age=24, priority=3,tcp,in_port=2,tp_dst=80 
> >> actions=learn(table=0,idle_timeout=60,hard_timeout=120,priority=100,in_port=LOCAL,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],eth_type=0x800,nw_proto=6,tcp_src=8080,NXM_OF_TCP_DST[]=NXM_OF_TCP_SRC[],load:NXM_OF_IP_DST[]->NXM_OF_IP_SRC[],load:NXM_OF_ETH_DST[]->NXM_OF_ETH_SRC[],load:NXM_OF_TCP_DST[]->NXM_OF_TCP_SRC[],output:NXM_OF_IN_PORT[]),mod_dl_dst:00:0b:82:a6:45:50,mod_nw_dst:192.168.1.129,mod_tp_dst:8080,LOCAL
> >> 
> >> 
> >> OFPT_FEATURES_REPLY (xid=0x2): dpid:000b82a64550
> >> n_tables:254, n_buffers:256
> >> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
> >> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
> >> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
> >>  1(ath0): addr:00:0b:82:a6:45:51
> >>  config: 0
> >>  state:  0
> >>  speed: 0 Mbps now, 0 Mbps max
> >>  2(ath1): addr:00:0b:82:a6:45:52
> >>  config: 0
> >>  state:  0
> >&

Re: [ovs-discuss] [OVN][RFC] ovn-northd simple optimization converting uuid from string

[Ben Pfaff]

On Sat, Feb 03, 2018 at 09:10:16AM +0100, Daniel Alvarez Sanchez wrote:
> Thanks Ben,
> 
> 
> On Sat, Feb 3, 2018 at 12:16 AM, Ben Pfaff <b...@ovn.org> wrote:
> 
> > Nice finding!
> >
> > I don't think it's necessary to inline this into the header file to get
> > the speedup, since its caller along the uuid_from_string() call chain is
> > in the same file as hexit_value().
> >
> I did this because hexit_value() is called also from scan_int(), which is
> called by ovs_scan(). The former was called around > 20K times in my
> run. But it's also in util.c so that's fine :)

Fair enough, thanks!
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] A bug on openswitch

[Ben Pfaff]

I suggest using ofproto/trace to figure it out.  See ovs-vswitchd(8) for
details.

On Sat, Feb 03, 2018 at 07:42:10PM +0800, a* wrote:
> Hi,all
> 
> 
> I recently found a bug about OVS, which was supposed to be sent to local but 
> was sent to eth0!
> Can you tell me why? I need help, thank you very much.
> 
> 
> recirc_id(0),in_port(4),eth(src=78:02:f8:29:cb:58,dst=00:0b:82:92:21:db),eth_type(0x0800),ipv4(src=192.168.1.64/255.255.255.192,dst=203.100.92.31,proto=6,frag=no),tcp(src=59765,dst=80),
>  packets:4, bytes:296, used:3.980s, flags:S, 
> actions:set(eth(src=78:02:f8:29:cb:58,dst=00:0b:82:a6:45:50)),set(ipv4(src=192.168.1.64/255.255.255.192,dst=192.168.1.129)),set(tcp(src=59765,dst=8080)),2
> 
> 
> system@ovs-system:
> lookups: hit:4226 missed:543 lost:0
> flows: 14
> masks: hit:22261 total:8 hit/pkt:4.67
> port 0: ovs-system (internal)
> port 1: br-lan0_zone0 (internal)
> port 2: eth0
> port 3: ath0
> port 4: ath1
> 
> 
> 
> 
> cookie=0x1, duration=444.585s, table=0, n_packets=1224, n_bytes=232770, 
> idle_age=24, priority=3,tcp,in_port=2,tp_dst=80 
> actions=learn(table=0,idle_timeout=60,hard_timeout=120,priority=100,in_port=LOCAL,NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],eth_type=0x800,nw_proto=6,tcp_src=8080,NXM_OF_TCP_DST[]=NXM_OF_TCP_SRC[],load:NXM_OF_IP_DST[]->NXM_OF_IP_SRC[],load:NXM_OF_ETH_DST[]->NXM_OF_ETH_SRC[],load:NXM_OF_TCP_DST[]->NXM_OF_TCP_SRC[],output:NXM_OF_IN_PORT[]),mod_dl_dst:00:0b:82:a6:45:50,mod_nw_dst:192.168.1.129,mod_tp_dst:8080,LOCAL
> 
> 
> OFPT_FEATURES_REPLY (xid=0x2): dpid:000b82a64550
> n_tables:254, n_buffers:256
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>  1(ath0): addr:00:0b:82:a6:45:51
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  2(ath1): addr:00:0b:82:a6:45:52
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
>  101(eth0): addr:00:0b:82:a6:45:50
>  config: 0
>  state:  0
>  current:COPPER AUTO_NEG
>  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER FIBER 
> AUTO_NEG AUTO_PAUSE AUTO_PAUSE_ASYM
>  speed: 0 Mbps now, 0 Mbps max
>  LOCAL(br-lan0_zone0): addr:00:0b:82:a6:45:50
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
> 
> 
> --
> 
> 
> 博学之，审问之，慎思之，明辨之，笃行之。
> 
> Albert Xie

> ___
> 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][RFC] ovn-northd simple optimization converting uuid from string

[Ben Pfaff]

Nice finding!

I don't think it's necessary to inline this into the header file to get
the speedup, since its caller along the uuid_from_string() call chain is
in the same file as hexit_value().

I sent out a patch that does something similar:
https://patchwork.ozlabs.org/patch/868826/

On Fri, Feb 02, 2018 at 07:24:59PM +0100, Daniel Alvarez Sanchez wrote:
> Hi folks,
> 
> While running rally in OpenStack we found out that ovn-northd was
> at 100% CPU most of the time. It doesn't have to be necessarily
> a problem but I wanted to do a simple profiling by running a rally task
> which creates a network (Logical Switch) and creates 6 ports on it,
> repeating the whole operation 1000 times. The ports are networks
> are also deleted.
> 
> I used master branch and compiled it with -O1:
> 
> CFLAGS="-O1 -g" ./configure --prefix=/usr/local/
> --with-linux=/usr/lib/modules/`ls /usr/lib/modules/ | tail -n 1`/build
> 
> gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
> 
> What I saw is that ~ 15% of the execution time was spent in
> uuid_from_string() function in util/uuid.c module which calls hexits_value()
> which ends up calling hexit_value(). This last function gets called >1M
> times.
> 
> I thought that it was worth to inline hexit_value() and use a lookup table
> instead the switch/case [0] so I did it (find the patch below) and the gain
> is
> that instead of a 14%, uuid_from_string() now takes a 9% of the total
> execution time. See [1].
> 
> [0]
> https://github.com/openvswitch/ovs/blob/79feb3b0de83932c6cbf761d70051330db4d07f7/lib/util.c#L844
> [1] https://imgur.com/a/3gzDF
> 
> Patch:
> Note that we could make the table smaller to optimize the data cache usage
> but then we would have to accommodate the argument and include extra
> checks.
> 
> 
> ---
> 
> diff --git a/lib/util.c b/lib/util.c
> index a4d22df0c..a24472690 100644
> --- a/lib/util.c
> +++ b/lib/util.c
> @@ -839,38 +839,6 @@ str_to_double(const char *s, double *d)
>  }
>  }
> 
> -/* Returns the value of 'c' as a hexadecimal digit. */
> -int
> -hexit_value(int c)
> -{
> -switch (c) {
> -case '0': case '1': case '2': case '3': case '4':
> -case '5': case '6': case '7': case '8': case '9':
> -return c - '0';
> -
> -case 'a': case 'A':
> -return 0xa;
> -
> -case 'b': case 'B':
> -return 0xb;
> -
> -case 'c': case 'C':
> -return 0xc;
> -
> -case 'd': case 'D':
> -return 0xd;
> -
> -case 'e': case 'E':
> -return 0xe;
> -
> -case 'f': case 'F':
> -return 0xf;
> -
> -default:
> -return -1;
> -}
> -}
> -
>  /* Returns the integer value of the 'n' hexadecimal digits starting at
> 's', or
>   * UINTMAX_MAX if one of those "digits" is not really a hex digit.  Sets
> '*ok'
>   * to true if the conversion succeeds or to false if a non-hex digit is
> diff --git a/lib/util.h b/lib/util.h
> index b6639b8b8..f41e2a030 100644
> --- a/lib/util.h
> +++ b/lib/util.h
> @@ -217,7 +217,28 @@ bool ovs_scan_len(const char *s, int *n, const char
> *format, ...);
> 
>  bool str_to_double(const char *, double *);
> 
> -int hexit_value(int c);
> +
> +static const char hextable[] = {
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1, 0,1,2,3,4,5,6,7,8,9,-1,-1,-1,-1,-1,-1,-1,10,11,12,13,14,15,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,10,11,12,13,14,15,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,
> +-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
> +};
> +
> +/* Returns the value of 'c' as a hexadecimal digit. */
> +static inline int
> +hexit_value(int c)
> +{
> +return hextable[c & 0xff];
> +}
> +
>  uintmax_t hexits_value(const char *s, size_t n, bool *ok);
> 
>  int parse_int_string(const char *s, uint8_t *valuep, int field_width,
> 
> 
> ---

> ___
> 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] Running ovs-appctl to trace packet

[Ben Pfaff]

On Fri, Feb 02, 2018 at 10:29:24AM -0500, Myra Sh wrote:
> Hello,
> 
> I want to use the same idea as the following link:
> 
> https://techandtrains.com/2014/02/08/running-open-vswitch-in-network-namespace/
> 
> 
> But I still have a problem to trace packets. Is there any other way to
> trace packets in OVS?

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

Re: [ovs-discuss] 答复: conn_key_hash change hash arithmetic

[Ben Pfaff]

Darrell, any comment on this?  + and ^ are both valid choices of
operator here and it's a little odd that one would be better than the
other.

On Thu, Dec 14, 2017 at 08:25:30AM +, liucheng (J) wrote:
> 
> 
> 发件人: liucheng (J)
> 发送时间: 2017年12月13日 18:01
> 收件人: 'ovs-discuss@openvswitch.org'
> 主题: [ovs-discuss]conn_key_hash change hash arithmetic
> 
> Hello all,
> I run a test with the user conntrack. And I found if I only change the udp 
> port, then the hash with function “conn_key_hash” is not balance.
> I change the hmap num(ct->buckets) to 4096 and ct->n_conn_limit to 
> 30,000,000. And I print the num of the nodes contained in the hmap’s bucket.
> As an example, a result looks like below. Most bucket is empty, and some 
> bucket contain hundreds of nodes;
> ~hmap 4095 count 4310 mask 4095~~~
> buket 488 content 367 node
> buket 1077 content 514 node
> buket 1118 content 281 node
> buket 1261 content 423 node
> buket 1280 content 268 node
> buket 1603 content 319 node
> buket 1724 content 352 node
> buket 2676 content 155 node
> buket 2993 content 471 node
> buket 3028 content 325 node
> buket 3836 content 355 node
> buket 4060 content 480 node
> 
> Then I change the code in conn_key_hash as the patch. And test result is the 
> max nodes in one bucket is 12.
> The num of the bucket contained only one node is 5000542.
> The num of the bucket contained only two node is 4337097.
> The num of the bucket contained only three node is 2588535.
> The num of the bucket contained only four node is 1196063.
> The num of the bucket contained only five node is 460865.
> The num of the bucket contained only six node is 155936.
> The num of the bucket contained only seven node is 48727.
> Most buckets contain few nodes.
> 
> 
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index 6d078f5..3edf809 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -2034,7 +2034,7 @@ conn_key_hash(const struct conn_key *key, uint32_t 
> basis)
>  hdst = ct_endpoint_hash_add(hdst, >dst);
> 
>  /* Even if source and destination are swapped the hash will be the same. 
> */
> -hash = hsrc ^ hdst;
> +hash = hsrc + hdst;
> 
>  /* Hash the rest of the key(L3 and L4 types and zone). */
>  hash = hash_words((uint32_t *) (>dst + 1),
> 

> ___
> 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] Running ovs-appctl to trace packet

[Ben Pfaff]

Oh, and why are you running multiple instances of OVS?  It's unusual.

On Thu, Feb 01, 2018 at 09:22:31AM -0800, Ben Pfaff wrote:
> The rundir for OVS and for ovs-appctl should match.  You can do that by
> defining OVS_RUNDIR in the environment for each one, otherwise you end
> up having to give full paths.
> 
> On Thu, Feb 01, 2018 at 11:09:42AM -0500, Myra Sh wrote:
> > Thank you for your reply.
> > 
> > I tried:
> >  OVS_RUNDIR=$(pwd)
> > exportOVS_RUNDIR
> > in all nodes.
> > 
> > 
> > After that,when I run for example: *"ovs-appctl  ofproto/trace br1
> > in_port=1"* on bridge1, I receive the following message:
> > 
> > *WARN|failed to connect to .../n1.conf/ovs-vswitchd.50.ctl*
> > 
> > 
> > 
> > there is no ovs-vswitch.50.ctl in $(pwd) directory.
> > 
> > I found *ovs-vswitchd.50.ctl* in */usr/local/var/run/openvswitch/ *directory
> > and after that:
> > 
> > *ovs-appctl  -t  /usr/local/var/run/openvswitch/ ovs-vswitchd.50.ctl
> > bridge/dump-flows br1 *
> > 
> > result:
> > 
> > *unknown bridge*
> > *ovs-appctl: /usr/local/var/run/openvswitch/ ovs-vswitchd.50.ctl :server
> > returend an error*
> > 
> > 
> > 
> > the mentioned command only works on a specific bridge(br3).
> > 
> > 
> > So I guess I should try to find the correct  ovs-vswitchd.*.ctl for each
> > bridge but it's not reasonable when I have several OVSs.
> > 
> > Do you have any suggestion in this case?
> > 
> > Is there any other way to trace the packets in OVS?
> > 
> > 
> > 
> > 
> > 
> > On Wed, Jan 31, 2018 at 4:15 PM, Ben Pfaff <b...@ovn.org> wrote:
> > 
> > > On Wed, Jan 31, 2018 at 02:53:25PM -0500, Myra Sh wrote:
> > > > Hello,
> > > >
> > > > I run several instances of OVS and I am using the following command and
> > > > path to configure them:
> > > >
> > > > ovs-vsctl --db=unix:$(pwd)/db.sock add-br br0
> > > >
> > > > The problem in having several instances is that when I want to run
> > > > "ovs-appctl ..." to trace packets, I have to define a path or target for
> > > > this command.
> > > >
> > > > Do you have any suggestion that how I can define this target path for
> > > each
> > > > OVS in the mentioned scenario?
> > > >
> > > > Should I check for any ovs-vswitch.*.ctl file and put that in the target
> > > > part?
> > >
> > > It sounds like you should run something like "OVS_RUNDIR=$(pwd); export
> > > OVS_RUNDIR".
> > >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Running ovs-appctl to trace packet

[Ben Pfaff]

On Wed, Jan 31, 2018 at 02:53:25PM -0500, Myra Sh wrote:
> Hello,
> 
> I run several instances of OVS and I am using the following command and
> path to configure them:
> 
> ovs-vsctl --db=unix:$(pwd)/db.sock add-br br0
> 
> The problem in having several instances is that when I want to run
> "ovs-appctl ..." to trace packets, I have to define a path or target for
> this command.
> 
> Do you have any suggestion that how I can define this target path for each
> OVS in the mentioned scenario?
> 
> Should I check for any ovs-vswitch.*.ctl file and put that in the target
> part?

It sounds like you should run something like "OVS_RUNDIR=$(pwd); export
OVS_RUNDIR".
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Open vSwitch selected as ACM SOSR Software Systems Award Winner for 2018

[Ben Pfaff]

Yesterday, the ACM SOSR awards committee announced that it was granting
Open vSwitch its second annual Software Systems Award, which is given to
recognize the development of a software system that has had a
significant impact on SDN research, implementations, and tools.  The
award comes along with a small cash prize (which will be directed toward
OVS community benefit) and an invited talk at SOSR in Los Angeles on
March 28-29.

There is a one-line announcement of the award selection at
https://conferences.sigcomm.org/sosr/2018/index.html and more
information about the award itself at
https://conferences.sigcomm.org/sosr/2018/award.html.

Thanks to everyone for your support and contributions to Open vSwitch
over the years!  OVS has come to be a major force in industry and
academia and we could have not done it without all the great people in
our community.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Why no-flood is not supported in later openflow versions?

[Ben Pfaff]

On Mon, Jan 29, 2018 at 11:52:34AM +0800, Jianfeng Tan wrote:
> >On Sun, Jan 28, 2018 at 11:39:29PM +0800, Jianfeng Tan wrote:
> >> Hi,
> >>
> >> In the openflow, we set no-flood PodMod operation through openflow 1.0;
> for
> >> later openflow versions, no-flood is dropped.
> >> We can refer to below two macro definitions.
> >>
> >> #define OFPPC10_ALL (OFPPC_PORT_DOWN | OFPPC10_NO_STP |
> OFPPC_NO_RECV |
> >> \
> >>  OFPPC10_NO_RECV_STP | OFPPC10_NO_FLOOD |
> >> OFPPC_NO_FWD | \
> >>  OFPPC_NO_PACKET_IN)
> >>
> >> #define OFPPC11_ALL \
> >> (OFPPC_PORT_DOWN | OFPPC_NO_RECV | OFPPC_NO_FWD |
> >> OFPPC_NO_PACKET_IN)
> >>
> >> Would like to know why no-flood is not one of the common flags? Or do we
> >> have any other BKM to supersede such port config?
> >
> >The OpenFlow 1.1 and later specifications don't have a "no flood" bit.
> 
> Thank you for the reply.
> 
> We also notice that it's the OpenFlow protocol (later version) does not
> support
> this bit. But we wonder why it's removed from the protocol? It's useless? Or
> we have an alternative to cover this.

I wasn't involved in the standardization of OpenFlow 1.1, but I'd guess
that groups were intended to replace this feature.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss